책: 최고의 프로덕트는 무엇이 다른가

개요

책의 추천사를 쓰신 지인께서 선물주신 책으로 새로운 개념, 방법론을 많이 배울 수 있었다.

저자이신 유진호님 같은 분이 회사내에 계시면 크고 작은 하드/소프트 이슈들에 대한 중심을 잡아주실 것 같다.

책에서 배운 새로운 개념, 방법들

SSPP - p23

조직이나 프로젝트를 분석하거나 개선할 때 사용하는 네 가지 핵심 요소

1. Structure (구조) – 조직의 체계와 구성, 계층, 의사결정 방식. 예: 조직도, 책임 분담.
2. System (시스템) – 업무를 처리하는 데 사용되는 도구와 프로세스, 기술적 시스템. 예: IT 시스템, 워크플로우.
3. Procedure (절차) – 업무를 수행하기 위한 구체적인 단계와 규칙, 표준 운영 방식. 예: 매뉴얼, 가이드라인.
4. People (사람) – 해당 구조와 시스템, 절차를 실행하는 구성원들의 역량, 태도, 역할. 예: 팀원, 리더십, 조직문화.

이 네 요소는 서로 유기적으로 연결되어 있으며, 문제 해결이나 변화 관리 시 균형 있게 고려되어야 한다.

커네핀 프레임 워크 - p41

커네핀 프레임워크(Cynefin Framework)는 복잡한 상황에서 의사결정을 돕기 위해 개발된 사고 도구로, 상황의 본질을 파악하고 적절한 대응 방식을 선택하는 데 목적이 있다. 웨일스어인 “Cynefin”은 ‘서식지’, ‘맥락’을 의미한다.

이 프레임워크는 상황을 5가지 영역으로 구분하며, 소프트웨어 개발은 Complex 영역에 해당한다.

이미지 출처: https://aguayo.co/en/blog-aguayo-user-experience/cynefin-framework-guide-intelligent-ux-decisions/

1. 명확한 영역 (Obvious / Clear)
   • 특징: 원인과 결과가 명확하며, 모범 사례(Best Practice)가 존재한다.
   • 대응 방식: 감지(Sense) → 분류(Categorize) → 대응(Respond)
   • 예시: 청구서 발행, 정기 점검 등
2. 복합 영역 (Complicated)
   • 특징: 여러 해석이 가능하며 전문가의 분석이 필요한 영역. ‘좋은 해법’은 있지만 명확하지 않음.
   • 대응 방식: 감지(Sense) → 분석(Analyze) → 대응(Respond)
   • 예시: 의료 진단, 로켓 설계 등
3. 복잡계 영역 (Complex)
   • 특징: 원인과 결과의 관계가 사후에만 명확함. 실험과 학습을 통해 해법을 찾아야 함.
   • 대응 방식: 찔러보기*(Probe) → 느껴보기(Sense) → 반응하기(Respond)*
   • 예시: 혁신, 조직 문화 변화, 신제품 개발
4. 혼란 영역 (Chaotic)
   • 특징: 원인과 결과가 완전히 불분명. 즉각적인 행동이 필요.
   • 대응 방식: 행동(Act) → 감지(Sense) → 대응(Respond)
   • 예시: 재난 대응, 위기 상황
5. 무질서/혼동 영역 (Disorder / Confusion)
   • 특징: 위 네 가지 중 어떤 영역인지 모를 때. 적절한 프레임을 찾기 전까지는 각자 자신의 관점대로 대응함.
   • 대응 방식: 먼저 상황을 판단해 적절한 영역으로 분류해야 함.

EoA(Essence of Agility) - p77

관련 링크: https://yozm.wishket.com/magazine/detail/2177/

애자일은 불확실성이 높은 상황에서 효과적으로 대응하는 전략이다.

• Avoid big loss 큰 손실 피하기
  • Redundancy: 중복을 허용하기
  • Detect early: 문제를 빠르게 감지하기
  • Asymmetry: 비대칭성 확립하기(밑져야 본전 구조)
• Learn as you go 계속 배우면서 나아가기
  • Feedback & adapt: 피드백을 받고 재조정하면서 나아가기
  • Receiving new info: 새로운 정보 얻기
  • Many projects, sequential: 많은 프로젝트를 하는 것처럼 순차적으로 나아가기
• Achieve critical early with less effort 핵심적인 것을 일찍 적은 노력으로 성취하기
  • Piecemeal & center first: 가장 중요한 것을 먼저 하되 작은 단위로 쪼개서 진행하기
  • Work with stakeholders: 이해관계자와 함께 일하기
• Be flexible 유연하게 대처하기
  • High ground for change: 변화에 유리한 지점 선점하기
  • Real option: 선택의 옵션 만들어두기
  • Diversify: 외부 자극에 다양하게 대응하기
  • Slack: 여유 확보하기
  • Generative sequence: 생성적 순서대로 하기

하일마이어 질문 - p86

미국 국방부 DARPA(고등방위연구계획국)의 국장 조지 하일마이어(George H. Heilmeier) 가 제안한 것으로, 새로운 기술 개발이나 프로젝트 제안 시 핵심을 명확히 설명하도록 돕는 질문 목록이다. 연구나 개발을 시작하기 전에 반드시 답해야 할 본질적인 질문 리스트로 널리 사용된다.

정현석 생각: 프로젝트 시작시에 AI에게 하일마이어 질문에 대한 답을 함께 찾아보자고 하면 될듯 하다. :-)

1. 무엇을 하려고 하는가? → 핵심 목표를 한두 문장으로 명확하게 말할 수 있는가?
2. 현재는 어떻게 하고 있으며, 어떤 한계가 있는가? → 기존 방식의 문제점이나 한계를 파악했는가?
3. 당신의 접근 방식은 무엇이며, 왜 성공할 것이라 생각하는가? → 새롭고 차별화된 방법은 무엇이며, 근거는?
4. 이 일이 성공하면 누가 관심을 가질까? → 실현되었을 때 사회, 산업, 사용자가 어떤 혜택을 얻는가?
5. 이 프로젝트가 성공한다면 어떤 임팩트가 있을까? → 경제적·사회적 가치, 기술적 전환점 등 구체적 영향은?
6. 가능한 주요 위험 요소는 무엇인가? → 기술적, 실행적, 시장 리스크는 무엇이며, 어떻게 대응할 것인가?
7. 얼마의 비용이 들고, 얼마나 시간이 걸리는가? → 자원(인력, 장비), 예산, 기간 등을 구체적으로 추산했는가?
8. 성공을 어떻게 측정할 것인가? → 성공을 판단할 수 있는 기준과 지표는?
9. 중간 점검과 최종 결과는 어떤 모습이어야 하는가? → 각 단계별 마일스톤과 최종 산출물은 무엇인가?

마세라티 문제 - p99

마세라티 문제는 소프트웨어 개발에서 자주 등장하는 비현실적인 기대나 요구를 풍자적으로 표현한 개념이다.

“정작 차 살 돈은 없으면서, 마세라티의 모델이나 색상을 고르고 있다”는 비유의 본질은 지금 감당할 수 있는 수준을 넘어서는 화려한 기능이나 옵션에 집착하는 태도를 비판하는 것이다.

이런 상황은 보통 서비스의 핵심 기능도 구현되지 않았거나, 예산이나 리소스가 턱없이 부족한 단계에서 발생한다.

• 고객: 이왕이면 AI 기반 추천 기능도 넣자. 대시보드는 고급 시각화 라이브러리로 구현하자
• 개발자: 멋진 아키텍처나 최첨단 기술을 적용하자.

YAGNI와도 비슷한 맥락이 있는데, YAGNI는 “나중에 필요할지도 몰라”라는 생각으로 미리 복잡한 기능이나 확장 구조를 구현해놓는 것에 대한 경고이다. 둘 다 공통적으로 ‘불필요한 걸 미리 만들지 말자’는 메시지를 담고 있지만, 마세라티 문제는 외부의 과한 기대(고객, 경영진 등)에, YAGNI는 내부의 과도한 설계 욕심(개발자 자신)에 초점을 맞춘다는 차이가 있다.

결국 중요한 건 지금 당장 필요한 것, 그리고 실제로 가치가 있는 것에 집중하는 것이다. 소프트웨어는 현실과 맞닿아 있을 때 가장 잘 작동한다.

테크스펙 - p147

책에서는 뱅크샐러드의 테크스펙 템플릿을 예시로 들어주고 있다.

테크 스펙(Tech Spec, Technical Specification)은 소프트웨어나 시스템 개발에서 기능, 구조, 제약 조건 등을 명확하게 정의한 문서이다. 개발자, 디자이너, 기획자, 이해관계자 간의 공통 이해를 돕기 위해 작성된다.

주요 내용에는 기능 요구사항, API 명세, 데이터 구조, 오류 처리 방식, 성능 요구 등이 포함된다. 스펙은 개발 전 단계에서 작성되지만, 개발 도중에도 변경되거나 보완될 수 있다. 잘 작성된 테크 스펙은 구현 방향을 정리해 주고, 나중에 발생할 수 있는 오해나 재작업을 줄이는 데 도움이 된다. 목적과 대상에 맞는 수준에서 명확하고 간결하게 작성하는 것이 중요하며, 협업을 전제로 하기 때문에 이해하기 쉬운 구조와 용어 선택도 필수적이다.

GDP(영국 정부의 Government Design Principles) - p162

이 원칙들은 공공의 신뢰, 디지털 접근성, 효율성, 지속가능성을 높이기 위해 만들어졌으며, 단순한 UI/UX 가이드가 아니라 공공철학에 기반한 설계 기준이라고 할 수 있다.

책에서는 당연한 질문이라고 생각지 말라고 한다. 미처 놓치는 부분이 없는지 하나하나 질문하고 확인하여야 한다.

1. Start with user needs 사용자의 실제 필요를 출발점으로 삼는다.
2. Do less 이미 존재하는 서비스를 중복하지 말고, 핵심에 집중한다.
3. Design with data 데이터를 기반으로 설계하고, 데이터로 검증한다.
4. Do the hard work to make it simple 단순하게 보이도록 설계하되, 그 과정은 어렵더라도 감수한다.
5. Iterate. Then iterate again. 한 번에 완벽을 목표하지 말고 반복적으로 개선한다.
6. This is for everyone 포괄성과 접근성을 보장하여 모든 국민을 위한 서비스가 되도록 한다.
7. Understand context 사용자가 처한 환경과 상황을 깊이 이해해야 한다.
8. Build digital services, not websites 단순한 웹사이트가 아니라 서비스 전체의 흐름을 설계한다.
9. Be consistent, not uniform 일관성은 유지하되, 모든 상황을 똑같이 적용하려고 하지 않는다.
10. Make things open: it makes things better 코드, 정책, 실패 사례 등 가능한 한 공개함으로써 공동 학습과 개선을 촉진한다.

Management by Objective and Self-Control - p196

경영학자 피터 드러커(Peter F. Drucker)가 제안한 개념으로, 조직 구성원 스스로가 목표에 책임을 지고 자율적으로 관리하는 방식을 강조한다.

1. Management by Objective (MBO)
   • 구성원 각자가 명확한 성과 목표(Objective)를 설정하고,
   • 상사와 합의를 통해 목표를 정의한 뒤,
   • 결과에 따라 평가하고 보상하는 성과 중심 관리방식이다.
2. Self-Control (자기 통제)
   • 목표를 설정받고 지시를 기다리는 것이 아니라,
   • 구성원이 스스로 목표를 내면화하고,
   • 자기주도적으로 업무를 수행하고 조정하는 것을 말한다.

핵심주장

• “자율 없이는 책임도 없다.” (There can be no responsibility without self-control.)
• 조직은 상명하달로 움직이지 않고, 목표에 대한 공동의 이해와 자율적 실행으로 운영되어야 한다.
• 성과 중심의 관리란 단순히 성과 측정이 아니라, 성과에 대한 스스로의 책임감과 주도성을 기반으로 해야 한다.

Auftragstaktik(Mission-type tactics) - p210

책에서는 위임형 전술이라 표현하며 “특정 방법 보다는 임무의 결과에 중점을 두는 군사전술” 이라 말한다.

독일 군사 전통에서 유래하였으며, 상급자가 구체적인 지시 대신 의도와 목표만 제시하고, 하급자가 자율적으로 방법을 결정하여 실행하는 방식이다.

• ‘무엇을 해야 하는가(목표)’는 상급자가 정하고,
• ‘어떻게 할 것인가(방법)’는 현장 지휘관이 판단한다.
• 전술적 자유와 창의성을 중시하며, 상황에 따라 융통성 있게 판단할 수 있도록 한다.

주요 원칙은 다음과 같다. 핵심 단어는 자율성이라 하겠다.

1. 지휘관의 의도(Commander’s Intent) 전달이 가장 중요하다.
2. 수직적 복종보다 수평적 책임과 자율성을 강조한다.
3. 통신 두절, 상급자 부재 등 위기 상황에서도 임무 수행이 가능하다.
4. 실수를 두려워하지 않고, 주도적 행동을 장려한다.

밑줄들

“경영자가 약속 이행을 아무리 강하게 요구한다 해도 진정으로 원하는 것은 결과물 자체다.” ”팀 전체가 참여하여 설정한 목표를 추구한다면 결과물을 훨씬 더 쉽게 얻을 수 있다.” p5

프로그래밍 심리학 책에서 말하는개발 리더가 명심해야 할 두 가지

애자일 실천법 중에서 도입해서 '성과에 도움을 준 것들은 모두 고르세요'라는 질문이었습니다. (중략) 이 뜻은 바로 고객 참여가 제일 중요하다는 것입니다. p108, p109

애자일 실천법 중에서 프로젝트의 성공에 밀접한 실천 방법들은 결국 고객 참여와 관련이 컸다는 이야기. 그만큼 고객 참여가 중요하다는 것이다.

“그러므로 너희는 그들을 두려워하지 말아라. 덮어 둔 것이라고 해도 벗겨지지 않을 것이 없고, 숨긴 것이라 해도 알려지지 않을 것이 없다.” - 마태복음 10장 26절, p121

업계에 만연한 거짓들, 그리고 그 거짓들을 당연하게 생각하는 세태에 대해 개탄을 하며 성경 구절을 인용하였다. 재미있게도 유교 경전인 중용에도 유사한 말이 나온다. 막현호은(莫見乎隱), 막현호미(莫顯乎微) - 가장 잘 보이는 것은 숨겨진 것이며, 가장 잘 드러나는 것은 아주 사소한 것이다.

“그러니까 고객이 무리한 요구를 한다고 하지 말고 왜 이런 것을 요구했는지 다른 고객들은 어떻게 생각하는지도 같이 생각해봐야 합니다.” p140

특정 고객이 자신만을 위한 기능을 추가 요청했을 때 어떻게 대응해야 하는지에 대한 샌드버그 김상희님의 답변이다. 비폭력대화가 생각났다. 고객의 목소리는 어떠한 선입견이나 판단없이 경청하고 관찰(observe) 해야 한다.

“누구라도 조금의 옳은 것은 있다.” p206

간디의 발언. 마음에 와닿았다. 누구의 발언이건 선입견과 판단없이 들을 수 있어야 한다.