처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.07.27 31

옵시디언 CEO가 말하는 '디자인은 타협이다' — 모두를 만족시키는 제품이 없는 이유

Hacker News 원문 보기
옵시디언 CEO가 말하는 '디자인은 타협이다' — 모두를 만족시키는 제품이 없는 이유

옵시디언(Obsidian)이라는 노트 앱 아시죠? 마크다운 파일 기반이라 개발자들 사이에서 특히 사랑받는 도구인데요. 이 옵시디언을 만드는 회사의 CEO 스테프 앙고(Steph Ango)가 "디자인은 타협이다(Design is compromise)"라는 에세이를 공개했어요. 분량은 짧지만, 제품을 만들어본 사람이라면 누구나 뜨끔할 이야기가 담겨 있어서 오늘은 이 글을 좀 깊게 풀어보려고 해요.

"완벽한 디자인"이라는 환상

앙고의 핵심 주장은 간단해요. 디자인이란 결국 여러 가치 중에서 무엇을 포기할지 선택하는 일이라는 거예요. 우리는 흔히 좋은 제품이 "모든 걸 잘하는 제품"이라고 생각하잖아요. 빠르면서 기능도 많고, 단순하면서 유연하고, 초보자에게 쉬우면서 전문가에게도 강력한 제품이요. 그런데 그런 제품은 애초에 존재할 수 없다는 거예요. 이 가치들이 서로 정면으로 충돌하기 때문이거든요.

구체적으로 볼게요. 기능을 하나 추가하면 그 기능이 필요했던 사람은 좋아하겠지만, 나머지 모든 사용자는 더 복잡해진 메뉴를 마주해야 해요. 설정 옵션을 늘리면 파워유저는 반기지만, 처음 온 사람은 뭘 골라야 할지 몰라서 이탈하죠. 성능을 극한으로 짜내면 코드 구조가 특수해져서 다음 기능을 붙이기 어려워지고요. 어느 쪽을 골라도 누군가는 손해를 봐요. 그래서 디자인의 진짜 질문은 "무엇을 잘할까"가 아니라 "무엇을 못해도 괜찮다고 선언할까"라는 거예요.

이게 뭐냐면, 결국 트레이드오프(trade-off) 이야기예요. 개발자에게 익숙한 개념이죠. 인덱스를 걸면 조회는 빨라지지만 쓰기는 느려지고, 캐시를 두면 응답은 빨라지지만 데이터 일관성 관리가 어려워지잖아요. 이 원리가 코드만이 아니라 제품의 모든 면, 그러니까 UI, 가격 정책, 기능 로드맵까지 관통한다고 보는 거예요.

옵시디언은 어떤 타협을 골랐을까요

이 철학이 실제 제품에 어떻게 반영됐는지 보면 더 흥미로워요. 옵시디언은 '앱보다 파일(File over app)'이라는 원칙으로 유명한데요. 노트를 자기네 서버의 데이터베이스가 아니라 사용자 컴퓨터의 평범한 마크다운 파일로 저장해요. 덕분에 회사가 사라져도 내 노트는 그대로 남고, 언제든 다른 도구로 갈아탈 수 있죠. 하지만 그 대가로 노션(Notion) 같은 경쟁 제품이 자랑하는 실시간 동시 편집은 구조적으로 어려워요. 이건 실수가 아니라 의도된 타협이에요. "협업 편의성보다 데이터 소유권이 중요하다"는 관점에 베팅한 거죠.

반대편 극단엔 노션이 있어요. 모든 걸 자체 데이터베이스에 넣는 대신 협업과 유연한 뷰를 얻었죠. 어느 쪽이 옳은 게 아니라, 서로 다른 타협을 골랐고 그래서 서로 다른 사용자를 만족시키는 거예요. 좋은 제품일수록 관점이 뚜렷한 이유가 여기 있어요. 모두를 만족시키려는 제품은 결국 아무도 열광하지 않는 제품이 되거든요.

사실 오래된 지혜이기도 해요

이런 생각은 소프트웨어 역사에서 계속 반복돼 왔어요. "한 가지 일만 잘하는 작은 프로그램을 조합하라"는 유닉스 철학이 그렇고, 리처드 가브리엘의 'Worse is Better', 그러니까 완벽하지만 복잡한 설계보다 단순하지만 불완전한 설계가 살아남는다는 관찰도 같은 맥락이에요. 베이스캠프를 만든 37signals가 "우리 제품은 소수 의견이다, 모두를 위한 게 아니다"라고 못 박는 것도 마찬가지고요. 앙고의 글은 이 오래된 지혜를 '타협'이라는 단어 하나로 다시 벼려낸 셈이에요.

우리 일에 어떻게 적용할까요

실무에 바로 가져갈 포인트가 몇 가지 있어요. 첫째, 기능 요청을 받았을 때 "추가하면 뭐가 좋아지나"만이 아니라 "추가하면 뭐가 나빠지나"를 함께 적어보세요. 비용이 없는 기능은 없거든요. 둘째, 아키텍처 결정을 내릴 때 선택지의 장점만이 아니라 감수하기로 한 단점까지 문서(ADR, 즉 아키텍처 결정 기록 같은 형태)로 남기세요. 나중에 "왜 이렇게 했지?"라는 질문에 답할 수 있는 팀이 강한 팀이에요. 셋째, 사이드 프로젝트를 한다면 "누구를 실망시킬지"를 먼저 정해보세요. 타깃이 아닌 사용자를 과감히 포기할수록 제품의 정체성은 또렷해져요.

정리하면, 디자인은 더하는 기술이 아니라 포기를 '선택'하는 기술이라는 거예요. 여러분 팀은 어떤가요? 지금 만들고 있는 제품이 누구를 실망시켜도 되는지 합의돼 있나요? 아니면 들어오는 요청을 다 받아주다가 정체성이 흐려지고 있진 않나요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

TTJ 코딩클래스 정규반

월급 외 수입,
코딩으로 만들 수 있습니다

17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.

144+실전 강의
17개수익 모델
4.9수강생 평점
정규반 자세히 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.