# 디자인은 타협이다

> Clean Markdown view of GeekNews topic #31878. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31878](https://news.hada.io/topic?id=31878)
- GeekNews Markdown: [https://news.hada.io/topic/31878.md](https://news.hada.io/topic/31878.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-27T22:33:16+09:00
- Updated: 2026-07-27T22:33:16+09:00
- Original source: [stephango.com](https://stephango.com/design-is-compromise)
- Points: 1
- Comments: 1

## Topic Body

- 좋은 디자인은 경쟁하는 요구 사이에서 **올바른 타협**을 선택하는 일임
- 타협은 **의사결정과 우선순위 설정**이며, 하나를 선택하는 순간 다른 선택지는 자연스럽게 배제됨
- **트레이드오프**는 약점을 감수해 강점을 얻는 관계로, 한쪽에 무게를 둘수록 다른 쪽은 약해짐
- 뛰어난 제품은 무엇을 잘하지 않을지 명확히 정하고, 그 대가로 특정 영역에서 탁월해지는 **뚜렷한 관점**을 가짐
- 모든 사람과 기능을 두루 만족시키려 하면 어느 하나에서도 탁월하기 어려우므로, **대상 사용자**에게 맞는 타협이 필요함

---

### 타협은 디자인의 본질
- 타협은 좋거나 나쁜 것이 아니라 매일 수행하는 **의사결정과 우선순위 설정**임
- 경쟁하는 두 요구 사이에서 균형을 찾고, 어느 쪽이 더 중요한지 판단하는 과정임
- 제품에 “타협하지 않았다”거나 “타협이 없다”고 내세우는 것은 불가능함
  - 특정 접근법을 선택하는 순간 다른 선택지를 배제하게 됨
- 중요한 것은 타협의 존재 여부가 아니라 **어떤 타협을 선택했는지**임

### 강점과 약점을 함께 선택하는 제품
- **트레이드오프**는 약점과 강점의 관계를 드러냄
  - 하나의 약점을 받아들이는 대신 하나의 강점을 얻음
  - 한쪽에 더 무게를 둘수록 다른 부분은 약해짐
- 명확한 트레이드오프는 제품의 약점을 드러내지만, 이런 어려운 선택을 내리는 일 자체가 디자인의 역할임
- 뚜렷한 제품은 무엇을 잘하지 않을지 분명히 정하는 대신, 다른 영역에서 훨씬 뛰어난 성능을 추구함
- 모든 사람에게 호소하는 것은 불가능함
  - 폭넓은 기능에서 두루 좋은 제품을 목표로 하면 특정 영역에서는 탁월하지 않기로 선택하는 셈임
  - 대상 사용자에게 적절한 선택일 수 있지만, 이 역시 명백한 타협임
- **좋은 디자인**은 뚜렷한 입장을 바탕으로 대상 사용자에게 맞는 타협을 선택함

## Comments



### Comment 62478

- Author: neo
- Created: 2026-07-27T22:33:17+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=49059367) 
- 요즘은 디자이너뿐 아니라 많은 이들이 **타협을 나약함으로 판단**하지만, 원하는 것을 언제나 얻을 수는 없음  
  내 경력에서 타협하는 기술은 가장 가치 있는 역량 중 하나였고, 지금도 팀원과 현실적인 합의점을 찾는 데 쓰고 있음
  - 여기서는 의지 대결의 승패에만 초점을 맞추지만, **아이디어 자체가 충돌하거나 모순**될 수도 있음  
    매력적인 아이디어도 깊이 파고들면 제대로 정립되지 않은 경우가 많으므로, 혼자 설계하더라도 구현 가능한 시스템을 만들려면 검증되지 않은 아이디어와 타협해야 함
  - 오히려 반대로 봄. 설계 과정을 **타협이나 양보**라는 단어로 표현하는 순간 의지의 대결로 규정하게 됨  
    설계는 어포던스, 패턴, 제약 조건, 상충 관계를 다루며, 반드시 누군가와 논쟁하거나 충돌할 필요는 없음. 주어진 조건에서 최선의 설계를 찾는 방법은 하나뿐이 아니며, 합의를 구하는 과정도 의견끼리 싸움을 붙일 필요가 없음  
    피드백을 받자마자 맞서 싸워야 한다고 느낀다면, 문제는 설계보다 **갈등 중심의 사고방식**에 있을 수 있음
  - 그 노래는 [https://en.wikipedia.org/wiki/You_Can%27t_Always_Get_What_Yo...](https://en.wikipedia.org/wiki/You_Can%27t_Always_Get_What_You_Want)임
  - **타협은 양쪽 모두가 잃는 방식**이며, 원래는 중재자의 결정을 따르겠다는 두 당사자의 약속을 뜻했음  
    때로는 [https://meta.wikimedia.org/wiki/The_Wrong_Version](https://meta.wikimedia.org/wiki/The_Wrong_Version)이나 북아일랜드 평화 프로세스처럼 타협이 최선이자 필수이기도 함. 하지만 차이를 반씩 나누는 대신 양쪽이 함께 선호할 창의적인 해법을 찾는다면 모두가 이길 수 있으며, 둘을 모두 타협이라고 부르는 경우가 많음  
    문제를 창의적으로 풀어 상호 이익을 추구하자는 말에 반대표를 던지는 이유를 이해하기 어려움

- **타협은 디자이너 도구함의 마지막 수단**이어야 함. 먼저 풀려는 문제의 범위를 집요하게 좁히고 모든 가능성을 시험한 뒤, 정확한 해법이 없거나 시간이 다했을 때 선택해야 함  
  타협은 종종 문제 범위를 제대로 규정하지 못한 채, 애초에 풀 필요가 없던 문제를 일부만 해결한 결과가 됨. 다만 한 문제를 해결하는 대신 다른 문제를 포기한다는 의미에서는 상충 관계가 맞음
  - 내 경험은 다름. 모든 결정은 한 사용 사례나 원칙을 다른 것보다 우선함  
    각 결정에서 무엇이 중요하고 무엇을 제외해도 되는지 말할 **비전과 확신**이 있을 때 좋은 설계가 나옴
  - 타협의 정의에 따라 달라짐. 화면 크기, 로딩 시간, 평균 사용자의 집중 시간까지 타협이라 한다면 설계 전체가 **수많은 조건을 조율하는 작업**임  
    반면 경영진을 만족시키려고 떠다니는 광고 푸터를 하나 더 넣는 식의 타협만 뜻한다면 정말 마지막 수단이어야 함
  - 누군가에게 문제를 주면 해법을 찾을 수 있지만, **딜레마를 주면 타협**이 거의 불가피해짐

- 전제부터 동의하기 어려움. **타협과 상충 관계**는 동의어가 아님  
  타협의 반대는 일부를 소외시키더라도 의도한 이용자에게 더 정확히 맞추는 강한 결정을 내리는 것이며, 이는 오히려 훌륭할 수 있음
  - 모든 결정에는 인식하지 못하더라도 상충 관계가 있음  
    강한 결정을 피하는 것 역시 날카로운 차별화 대신 마음의 평화나 비소외를 택하는 결정이므로, 마냥 기다리기보다 **의도적으로 상충 관계를 선택**하라고 권함
  - 이는 의도한 이용자층이 명확하다는 전제에 의존하며, 이런 전제가 조사 과정에서 페르소나를 만들게 했음  
    하지만 특정 이용자층을 넘어 더 넓게 도달하고 소외를 줄여야 하는 설계도 많음. 요구 사항을 정확히 분석하기는 어렵고 사람들의 필요도 변하기 때문에, 좁은 대상을 위한 완벽한 제품이 오히려 형편없어지기도 함  
    특정 손 크기·모양과 동작에 맞춘 마우스는 대상 사용자에게조차 더 나빠지는 경우가 많음. 잡는 방식과 작업별 사용법을 바꿀 여유가 있는 제품이 더 편하며, 최고의 마우스는 대체로 관대하고 유연함. 특히 **Apple 트랙패드와 Kensington식 트랙볼**은 손 특성에 거의 구애받지 않음

- 제약 조건이 고정돼 있다면 여러 차원 중 상충 관계를 선택하게 되고, 그것이 타협임  
  하지만 제약 조건은 고정되지 않으며 최적화하거나 새로운 기법을 발견해 **요구 사항의 공간 자체를 바꿀 수 있음**. 더 나은 압축 알고리즘과 새롭고 빠른 칩이 새로운 연산을 가능하게 하듯, 더 노력하면 타협의 경계도 이동시킬 수 있음
  - 이론적으로는 맞지만 사업에서는 반대의 사고방식이 더 유용했음  
    목표와 충돌하지 않는 잠재적 제약은 실제 제약으로 취급해야 함. 이론상 X, Y, Z를 다시 만들 수 있더라도 이번 프로젝트에서 실제로 가능한 일을 봐야 하며, 나는 **사회적 제약까지 현실의 제약**으로 간주해 경영진에게 전달함

- Scott Jenson의 **The Simplicity Shift**를 읽고 삶의 전환점을 맞았음  
  모바일 UI가 매우 제한적이던 시절에 쓰인 책으로, 우선순위를 정하고 설계의 완성도를 유지하면서 사용 가능하고 비용도 감당할 수 있는 UI를 만드는 타협을 다룸. 다른 사람과 협업해 잘 작동하는 합의점을 찾는 방법도 많이 설명함  
  [https://jenson.org/The-Simplicity-Shift.pdf](https://jenson.org/The-Simplicity-Shift.pdf)는 짧은 PDF임

- 비원어민인 내게 **타협과 상충 관계**는 완전히 같지 않으며, 이 글에는 후자가 더 적합해 보임  
  상충 관계는 한 목표를 위한 설계가 다른 목표를 희생한다는 선택지 간 결합을 직접 드러내지만, 타협에는 그 의미가 명확히 담기지 않음

- **가치관은 어려운 결정을 내릴 때** 필요하며, 쉬운 결정만 한다면 필요하지 않음  
  하지만 가치들도 서로 충돌하므로 동시에 우선할 수 있는 것은 소수뿐임. 어려움을 겪는 직원을 배려한 결정은 이미 일정이 늦어진 고객이나 속도를 중시하는 가치에는 나쁠 수 있음

- 이것이 마케팅 표현을 겨냥한 것인지 더 넓은 문화 현상을 말하는 것인지 불분명함  
  목표를 달성하려고 실제로 하는 타협과, 고객의 목표에는 타협하지 않는다고 홍보하는 **대외적 표현**은 서로 다르므로 별문제로 보이지 않음

- 꼭 그렇지는 않음. 상위 수준의 설계는 계층화나 더 정교한 장치를 통해 양쪽의 이점을 보존하면서 겉으로 보이는 긴장과 대립을 해소하기도 함  
  편의성과 보안 중 하나를 골라 희석된 타협점을 찾는 것은 순진한 설계임. 사용자가 어느 한쪽을 선택하거나 약화할 필요가 없도록 편의성 위에 보안을 계층화하는 것이 좋은 설계이며, 훌륭한 기업은 **겉보기의 모순을 설계로 해소**해 왔음
  - 오늘날에는 두 사용 사례를 모두 잘 충족하는 해법도 **완벽한 타협**이라고 부르곤 함  
    타협의 어원이 양보에서 왔다는 사실과 별개로, 이는 언어적 선호의 차이에 가까워 보임
  - 때로는 좋은 설계에 **타협이 전혀 없어야 함**  
    `NO`라는 선택을 허용하지 않아 벌어진 결과를 보여주는 대표적인 예가 737 MAX 참사임

- 단어의 뜻을 계속 바꿔 사용해서 **글을 읽기 어려울 정도**임
