좋은 디자인은 타협을 숨기지 않고, 제대로 고르는 일이라는 글

• 글의 출발점은 ‘타협(compromise)’이라는 단어가 왜 이렇게 나쁜 말처럼 취급되냐는 질문임

  • 저자는 타협이 선도 악도 아니고, 매일 하는 의사결정이라고 봄
  • 우선순위를 정하고, 서로 충돌하는 욕구 사이에서 균형을 잡는 일이 곧 타협이라는 얘기임

• 제품이 ‘타협 없음’이라고 말하는 건 사실상 불가능함

  • 어떤 접근을 선택하는 순간, 자동으로 다른 접근은 선택하지 않는 셈임
  • 그래서 무타협 제품이라는 말은 멋있게 들릴 수는 있어도, 설계 현실을 설명하진 못함

• 저자는 타협을 tradeoff라는 말로 다시 설명함

  • tradeoff는 강점과 약점의 관계를 드러내는 단어임
  • 어떤 약점을 받아들이는 대신 어떤 강점을 얻는 구조임
  • 중요한 건 타협을 했느냐가 아니라, 어떤 타협을 골랐느냐임

• 좋은 디자인은 자기 약점을 감추지 않고, 의도적으로 선택한 약점을 갖고 있음

  • 한쪽으로 저울을 기울일수록 반대쪽은 약해짐
  • 그래도 괜찮음. 어려운 선택을 대신 해주는 게 디자이너와 제품팀의 역할이니까
  • 저자는 오히려 자신이 고른 타협을 자랑스러워해야 한다고 말함

• 저자가 좋아하는 제품은 대체로 opinionated함

  • 특정한 것을 훨씬 잘하기 위해, 다른 부분에서는 별로 좋지 않다는 걸 받아들임
  • 모두에게 매력적인 제품을 만드는 건 불가능함
  • 넓은 범위에서 두루 괜찮은 제품을 만들 수는 있지만, 그러면 특정 영역에서 예외적으로 뛰어나기는 어려움

• 개발자에게도 이 얘기는 그대로 들어맞음

  • 프레임워크는 자유도를 줄이는 대신 일관성과 생산성을 줌
  • 타입 시스템은 작성 비용과 러닝커브를 늘리는 대신 변경 안정성을 줌
  • 단순한 API는 고급 사용자의 세밀한 제어를 포기하는 대신 대부분의 사용자를 빠르게 성공시킴

• 결론은 간단함. 좋은 디자인은 타협이 없는 디자인이 아니라, 자기 audience에 맞는 타협을 제대로 고른 디자인임

  • 누구를 위한 제품인지 흐릿하면 tradeoff도 흐릿해짐
  • tradeoff가 흐릿하면 결과물은 보통 ‘다 괜찮은데 딱히 사랑받진 않는’ 쪽으로 감

---

기술 맥락

• 제품이나 개발 도구를 만들 때 타협이 중요한 이유는 리소스가 부족해서만은 아니에요. 사용자의 성공 경로를 짧게 만들려면 어떤 선택지는 일부러 막거나 어렵게 만들어야 하거든요.

• 예를 들어 opinionated framework는 설정 자유도를 줄이는 대신 팀 전체가 비슷한 방식으로 코드를 쓰게 해요. 이건 초반에는 답답해도, 규모가 커질수록 유지보수 비용을 줄이는 선택이 될 수 있어요.

• 반대로 범용성을 최우선으로 둔 도구는 많은 상황에 들어맞지만, 초보자가 뭘 골라야 할지 모르는 문제가 생겨요. 그래서 좋은 설계는 ‘가능한 모든 선택지’보다 ‘이 사용자가 지금 해야 할 선택’을 더 중요하게 봐요.

• 결국 이 글의 메시지는 UX에만 갇히지 않아요. API 설계, 아키텍처, 제품 전략 모두 어떤 약점을 감수해서 어떤 강점을 만들지 명시하는 일이 핵심이에요.