의사결정 문서가 이걸 해결합니다. ADR이든 RFC든 결정 로그든 이름은 중요하지 않습니다. 중요한 건 선택하는 그 순간에 배경과 선택지와 근거를 적어두는 일입니다. 올해 개발팀을 맡게 되면서 그 가치를 어느 때보다 실감하고 있습니다. 조직의 기억이 되느냐, 조직의 구전 설화가 되느냐의 갈림길이거든요.

공들일 가치가 있는 이유

#

가장 뻔한 보상은 같은 논쟁을 두 번 하지 않아도 된다는 겁니다. “API 버저닝 전략, 이미 정하지 않았나요?” 무엇을 왜 결정했는지 기록이 명확히 남아 있으면 결론 난 문제는 결론 난 채로 있고, 팀은 왔던 길을 되짚는 대신 실행에 에너지를 씁니다.

더 조용한 보상은 시간이 지나면서 드러납니다. 프로젝트는 몇 달, 몇 년씩 이어지고 사람은 들어오고 나가는데, 끝까지 남는 건 코드입니다. 문제는 코드가 “무엇을” 결정했는지는 알려줘도 “왜"는 절대 말해주지 않는다는 점이죠. 의사결정 문서는 그 추론을 보존합니다. 당시 존재했던 제약, 기각된 대안, 최종 판단을 내린 사람까지요. 새 팀원은 구전 설화 대신 맥락을 얻습니다. 팀을 넘나드는 결정은 결론만이 아니라 저울에 올랐던 요소까지 모두에게 보이니 진짜 동의를 얻기 쉬워집니다. 그리고 의사결정자와 기여자의 이름이 박히면, 후속 실행에도 확실한 주인이 생깁니다.

언제 쓰는가

#

모든 결정에 문서가 필요하진 않습니다. 저는 결정이 다음에 해당할 때 문서를 씁니다.

• 되돌리기 비싼 결정 — 기술 스택 선택(프레임워크, 데이터베이스, 클라우드 제공업체), 아키텍처 패턴(마이크로서비스 vs 모놀리스, 이벤트 기반 vs 요청-응답), 서드파티 벤더 선정, 보안·규정 준수 접근 방식
• 오래 남는 결정 — 외부 시스템이 의존하는 API 계약, 여러 서비스에 걸치는 데이터 모델, 확립된 패턴에 대한 파괴적 변경
• 팀을 가로지르는 결정 — 여러 팀이나 비기술 이해관계자의 동의가 필요한 것, 리소스 배분과 우선순위 판단
• 스파이크의 결론 — 타임박스 조사가 끝났다면, 발견과 결정이 증발하기 전에 문서로 남기기

반대로 쉽게 되돌릴 수 있는 결정, 팀 내부 구현 세부사항, 내 범위 밖에는 거의 영향이 없는 선택이라면 형식을 갖춘 문서는 건너뛰세요. 아무도 필요로 하지 않는 문서는 그냥 숙제일 뿐입니다.

라이프사이클

#

┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   초안      │ ──► │   리뷰      │ ──► │   승인      │ ──► │   구현      │
│   제안      │     │  피드백     │     │   수락      │     │   완료      │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘
                           │
                           ▼
                    ┌─────────────┐
                    │   거부/     │
                    │   대체      │
                    └─────────────┘

작성자가 문제와 후보 솔루션을 초안으로 정리하고, 이해관계자들이 리뷰합니다. 이 과정의 본전을 뽑는 곳이 리뷰 단계입니다. 가정을 따져 묻고 맹점이 드러나는 지점이니까요. 그다음 의사결정자(보통 기술 리드, 아키텍트, 프로덕트 오너)가 최종 판단을 내리고, 팀이 구현하며, 구현 중 현실 때문에 바뀐 부분이 있으면 문서도 갱신합니다. 리뷰에서 죽는 문서도 있고, 상황이 변해 나중에 대체되는 문서도 있습니다. 둘 다 분명하게 표시하세요. “승인됨” 상태로 낡아버린 문서는 다음에 그걸 발견할 사람에게 함정이 됩니다.

읽을 만한 문서를 만드는 것들

#

애착이 가는 솔루션이 아니라 문제에서 시작하세요. 무엇을 해결하려는지, 왜 지금 중요한지, 아무것도 안 하면 어떻게 되는지. 문제에 대한 합의가 없는 상태에서 솔루션을 논쟁하는 건 연극일 뿐입니다.

그다음 진짜 선택지를 제시합니다. 강한 선호가 있어도 최소 2~3개의 대안을요. 각 옵션에는 간단한 설명, 장단점, 대략적인 공수 추정(티셔츠 사이즈면 충분합니다: S/M/L/XL), 그리고 리스크와 완화 방안을 답니다. 대안을 기록해 두는 것이야말로 미래의 독자가 “왜 승자가 이겼는지” 이해하는 방법입니다.

트레이드오프는 소리 내어 말하세요. “아키텍처의 순수함보다 시장 출시 속도를 택합니다.” “더 나은 확장성을 위해 운영 복잡도 증가를 감수합니다.” “순수 성능보다 개발자 경험을 우선합니다.” 이런 문장 하나가 분석 몇 페이지보다 미래의 독자에게 더 도움이 됩니다.

논의는 구체적인 것에 붙들어 매세요. 솔루션이 어떻게 구현될지 보여주는 코드 스니펫, 시스템 상호작용 다이어그램, 스파이크에서 만든 개념 증명 링크. 추상적인 논의에서는 추상적인 결정밖에 안 나옵니다.

마지막으로 기한입니다. 언제까지 결정해야 하는지, 누가 언제까지 의견을 내야 하는지, 결정이 미뤄지면 무엇이 막히는지. 기한 없는 결정은 영원히 떠다닙니다.

예시: 아키텍처 결정 기록(ADR)

#

의사결정 문서의 실전 예시입니다:

# ADR-001: API Authentication Strategy

**Status:** Accepted
**Date:** 2024-11-15
**Decision Maker:** Sarah Chen (Platform Architect)
**Contributors:** Backend Team, Security Team, Mobile Team

## Context

Our public API currently uses API keys for authentication. As we expand to
support third-party integrations and mobile apps, we need a more robust
authentication mechanism that supports:
- Token expiration and refresh
- Scoped permissions
- User-level authentication (not just service-level)

## Decision

We will implement OAuth 2.0 with JWT tokens for API authentication.

## Options Considered

### Option 1: OAuth 2.0 with JWT (Recommended)
**Description:** Industry-standard protocol with self-contained tokens

| Pros | Cons |
|------|------|
| Industry standard, well-documented | More complex initial implementation |
| Self-contained tokens reduce database lookups | Tokens cannot be revoked instantly |
| Broad library support | Requires refresh token management |

**Effort:** Medium (2-3 sprints)

### Option 2: Session-based Authentication
**Description:** Traditional server-side sessions with cookies

| Pros | Cons |
|------|------|
| Simple to implement | Not suitable for mobile apps |
| Easy to revoke sessions | Requires sticky sessions or shared session store |
| Familiar to most developers | Doesn't scale as well |

**Effort:** Small (1 sprint)

### Option 3: Custom Token System
**Description:** Build our own token-based authentication

| Pros | Cons |
|------|------|
| Fully customizable | Reinventing the wheel |
| No external dependencies | Security risks from custom implementation |

**Effort:** Large (4+ sprints)

## Consequences

- Mobile team can implement standard OAuth flows
- We'll need to set up a token refresh mechanism
- API documentation will need updates for OAuth flows
- Existing API key users will need a migration path (6-month deprecation)

## References

- [OAuth 2.0 RFC 6749](https://tools.ietf.org/html/rfc6749)
- Internal spike document: [Authentication Options Spike](/spikes/auth-spike-2024)
- Security team review: SEC-2024-042

훔쳐 써도 되는 템플릿

#

이걸 출발점으로 삼고 팀에 맞게 덜어내세요.

문제 설명

#

어떤 문제를 해결하려고 하는가? 왜 중요한가? 아무것도 하지 않을 때의 비용은?

배경

#

맥락, 이력, 관련 세부사항을 제공합니다. 관련 문서, 이전 결정, 스파이크 결과에 대한 링크를 포함합니다.

제약사항

#

모든 솔루션이 준수해야 하는 제한이나 요구사항은 무엇인가?

• 예산 제약
• 타임라인 요구사항
• 기술적 제약 (기존 시스템, 스킬셋)
• 규정 준수 또는 보안 요구사항

검토한 솔루션

#

권장사항

#

권장하는 옵션을 명시하고 제약과 트레이드오프를 고려할 때 왜 최선의 선택인지 요약합니다.

결정

#

결정이 내려지면 최종 결정을 문서화합니다. 권장사항과 다르면 이유를 설명합니다.

결과

#

이 결정의 영향은 무엇인가? 필요한 후속 작업은 무엇인가?

액션 아이템

#

참조

#

관련 문서, 외부 리소스, 스파이크 결과, 이전 결정에 대한 링크.

습관으로 정착시키기

#

문서는 일관된 곳에 두세요. 저장소의 전용 폴더든 위키 공간이든 상관없지만, 찾을 수 없는 결정은 존재하지 않는 것과 같습니다. 그리고 가볍게 유지하세요. 쓰는 데 며칠 걸리는 문서는 애초에 쓰이지 않습니다. 코드 주석, 커밋 메시지, 풀 리퀘스트에서 문서를 참조해서 “왜"가 “무엇” 곁에 붙어 있게 하세요. 결정이 대체되면 옛 문서를 지우지 말고 대체됨으로 표시한 뒤 새 결정으로 링크를 겁니다. 역사가 곧 핵심이니까요. 그리고 회고에서 가끔 과거 결정을 돌아보세요. 어떤 결정이 버텨냈고, 어떤 건 지금이라면 다르게 할지.

실패 패턴도 그만큼 예측 가능합니다. 분석 마비에는 기한을 정하고 가진 정보로 결정하는 것이 답입니다. 대부분의 결정은 나중에 다시 볼 수 있으니까요. 의미 있는 비평이 한 번도 안 나오는 도장 찍기 리뷰는 가치 없이 절차만 더합니다. 쓰였는데 실행되지 않는 고아 문서는 문서가 없는 것보다 나쁩니다. 과한 디테일도 조심하세요. 문서가 다룰 것은 “왜"와 “무엇"이지 “어떻게"가 아닙니다. 구현 세부사항은 기술 명세서의 몫입니다. 그리고 이해관계자가 반대하면 그 반대도 기록하세요. 결정은 그대로 갈 수 있지만, 그 반론이야말로 1년 뒤 누군가에게 꼭 필요한 맥락입니다.

다음번 중요한 결정부터 시작해 보세요. 거칠어도 일단 쓰고, 프로세스는 굴리면서 다듬으면 됩니다. 누군가 ADR을 읽는 것만으로 “우리 왜 X를 골랐죠?” 회의가 사라질 때마다, 그만큼의 시간이 팀에게 돌아옵니다.

참고 자료

#

이 사이트의 관련 글:

• 애자일 소프트웨어 개발에서 스파이크 이해하기 - 큰 결정 전에 스파이크로 정보 모으기
• 회고: 피드백 루프의 힘 - 지속적 개선의 일부로 과거 결정 돌아보기
• API 계획 - 의사결정 문서의 사고방식을 API 설계에 적용하기
• 프로젝트 관리를 위한 GitHub - 의사결정 문서를 코드 옆에 두고 관리하기

외부 리소스:

• Documenting Architecture Decisions - Michael Nygard - ADR을 대중화한 원본 글
• ADR GitHub Organization - ADR을 위한 도구, 템플릿, 예시
• Design Docs at Google - Google의 설계 문서 접근법
• RFC Process at Rust - Rust 언어의 잘 정비된 RFC 프로세스
• Spotify’s Decision Record Template - Spotify가 ADR을 쓰는 시점에 대한 글

Alan이 회의를 포기한 이유

#

출발점은 누구에게나 익숙할 겁니다. 아무도 준비를 안 해오고, 시작은 늦어지고, 목소리 큰 사람이 옳든 그르든 결론을 가져갑니다. 한 시간 뒤엔 들어가기 전보다 머리가 더 복잡해져서 서랍에 진통제가 남아 있나 뒤적이게 되죠.

Alan도 처음엔 회의를 고쳐 보려 했습니다. 최대 15분, 명확한 안건, 반드시 결정 도출. 그래도 안 됐습니다. 논의는 삼천포로 빠지고, 무슨 얘기가 오갔는지 아무도 기억 못 하고, 결석자나 원격 근무자는 그냥 소외됐습니다. 그래서 통째로 글로 옮기기로 한 겁니다.

그들이 내세우는 효과는 수긍이 갑니다. 글을 쓰려면 멈춰서 생각할 수밖에 없으니 논의가 더 정교해지고 근거도 탄탄해집니다. 모든 게 기록으로 남아 어렴풋한 기억에 기댈 필요가 없고, 더 이상 웅변 대회도 아닙니다. 게다가 포럼이 전사에 공개되어 있으니, 마침 회의실에 있던 사람만이 아니라 누구든 논의에 낄 수 있습니다.

사내 포럼이 된 GitHub

#

그 포럼의 정체는 GitHub입니다. 원래 코드 리뷰용으로 만들어진 플랫폼을 Alan이 당당하게 용도 변경한 거죠. 세팅은 민망할 정도로 간단합니다.

1. GitHub 계정을 만든다.
2. 코드가 없는 비공개 저장소를 만든다(Alan의 저장소 이름은 “Topics”).
3. 대화를 분류할 라벨 체계를 만든다.
4. Issues 탭을 쓴다. 열린 이슈는 진행 중인 논의, 닫힌 이슈는 내려진 결정.

이들의 이슈는 17,000개를 넘었습니다. 열리지 않아도 됐던 회의가 그만큼이라는 뜻이고, 제가 가장 탐나는 부분은 이겁니다. 모든 결정이 “왜 그렇게 됐는지” 검색 가능한 역사로 남는다는 것. 옛날 결정에 이의를 제기하고 싶으면, 지난번엔 어떤 논거가 이겼는지부터 읽어볼 수 있습니다.

언제 이슈를 여는가

#

모든 결정이 이슈감은 아닙니다. 그들의 필터는 네 가지 질문입니다. 누가 영향을 받는가? 얼마나 되돌리기 쉬운가? 얼마나 급한가? 결정하려면 맥락이 더 필요한가?

대략, 영향이 크고 되돌리기 어려운 결정은 포럼으로 가고 나머지는 Slack에서 끝냅니다. 일방향/양방향 문이라는 구분도 씁니다. 일방향 결정(되돌리는 데 비용과 수고가 너무 큰 것, 예시로 든 건 요금 인상)은 풀코스로 글쓰기를 거치고, 양방향 결정(취소가 싸고 최악이라야 에너지 좀 잃는 것)에는 그런 격식이 필요 없습니다.

LOCI: 누가 무엇을 하나

#

모든 논의에는 LOCI 모델(Lead, Owner, Consulted, Informed)로 역할이 배정됩니다.

Lead는 결정의 성패에 책임을 지고, 결정의 배경이 팀에 제대로 이해되도록 합니다. 논의 초반에 자기가 어디까지 관여할지 밝혀 두고, 그다음엔 Owner를 믿고 팀의 결과물에 책임을 지되, 강하게 반대할 때만 목소리를 냅니다. 논의당 Lead는 한 명입니다.

Owner는 최종 결정을 내리고 프로젝트를 끌고 갑니다. 기여자들이 논의 내용을 알고 제때 의견을 내도록 챙기고, 문제를 조사하고, 이슈를 열고 닫고, 결정을 공유합니다. 혼자 못 넘는 벽에 부딪히면 Lead를 찾아갑니다. 결정당 Owner도 한 명입니다.

Consulted는 트레이드오프 판단에 의견이 정말로 필요한 사람들입니다. “덧붙일 게 없습니다” 한 줄이라도 제때 기여할 의무가 있고, 결정이 크게 잘못됐다고 판단하면 경보를 울리고 필요하면 Lead에게 에스컬레이션합니다. Alan은 이 그룹을 6명 정도로 제한합니다. 의견이 그보다 많아지면 일정이 밀리기 시작하기 때문입니다.

Informed는 대개 결정이 난 뒤에 통보만 받는 사람들입니다. 소통은 일방향이고 아무 기여도 기대되지 않습니다. 누구에게 알릴지는 영향 범위를 따져 Owner가 정합니다.

여기까지는 결정 하나 단위의 이야기입니다. 프로젝트 전체로 보면 저는 같은 내용을 프로젝트 커뮤니케이션 계획으로 한 번 정리해 둡니다. 누가 무엇을, 얼마나 자주, 누구에게서 전달받아야 하는지를 적은 표입니다.

이슈 해부도

#

모든 이슈는 같은 템플릿을 씁니다. 생각이 다듬어지는 건 물론이고, 주니어에게 문제를 쪼개는 법을 가르치는 교재 역할도 합니다.

• 범위(Scope) - 논의의 “왜”. 은근히 효과가 좋은 게 “이 이슈는 ~에 관한 것이 아닙니다"라는 한 줄입니다
• 맥락과 자료 - 과거 논의와 자료 링크
• LOCI - 누가 Lead, Owner, Consulted, Informed인지
• 마감일 - 기여 마감, 이슈 닫는 날, 해결책이 필요한 시점
• 해결책 제안 - 제안하는 답 하나, 또는 고를 수 있는 선택지 몇 개
• 질문 - 특정한 사람에게, 특정한 가정을 확인하거나 반박해 달라고 묻는 것. 이슈가 “바다에 던진 유리병 편지"가 되지 않게 하는 장치입니다

논의가 늘어지지 않게 하는 글쓰기 규칙

#

글로 하는 논쟁도 말로 하는 것 못지않게 질질 끌 수 있습니다. 그래서 규칙이 있습니다. 우선 간결하게. 그들은 부알로의 “잘 구상된 것은 명료하게 진술된다"를 인용합니다. 단순하게 못 쓴다면 아직 자기 주장에 확신이 없다는 뜻입니다. 그리고 쓰는 모든 글에 “So what?” 테스트를 겁니다. 내 코멘트의 함의가 자명하지 않다면 명시적으로 적어 주는 거죠.

Owner에게는 이슈를 연 뒤의 운영이 그만큼 중요합니다. 논의를 “백만 달러짜리 질문”, 즉 진짜 중요한 단 하나의 쟁점에 계속 조준시키고 디테일의 바다에서 표류하지 않게 합니다. 합의된 것과 아직 열려 있는 것을 주기적으로 정리해서 보여 줍니다. Slack 리마인더는 최후의 수단으로, 기여가 늦어졌거나 정말 급할 때만 씁니다.

Owner는 대화를 진전시키지 못하는 댓글을 숨기기도 합니다. 그리고 제목, 각주, 표, 키보드 단축키 같은 GitHub의 서식 기능은 전원이 능숙하게 다루는 게 전제입니다. 글에서는 내용만큼 형식도 힘을 발휘하니까요.

합의도 없고, 구경꾼도 없다

#

이 시스템이 “위원회식 결정"으로 전락하지 않게 막는 장치가 두 가지 있습니다.

첫째, Owner는 Alan의 표현으로 “계몽 전제군주"로서 결정합니다. 아이디어를 조사하고, 리스크를 재고, 동료에게 질문은 하지만, 합의를 구하지 않고 들은 걸 전부 반영할 의무도 없습니다. Alan은 “우리는 민주주의가 아니다"라고 잘라 말합니다. 전원이 주주이고, 회사의 이익이 팀이나 개인의 이익보다 앞선다는 거죠. 그렇다고 고립된 졸속 결정을 바라는 것도 아닙니다. Owner가 “이 베팅이 맞다"고 어느 정도 확신하면 결정하고, 다 같이 실행해 보고, 영향이 보이기 시작하면 되돌아보며 다음에 더 잘할 방법을 찾습니다.

둘째, 기여자 수를 관리합니다. 제프 베이조스의 “피자 두 판” 규칙은 비동기에서도 유효합니다. 사람이 많아질수록 한 사람 한 사람의 기여는 줄어듭니다. 6명을 넘기면 방관자 효과가 고개를 들고 참여의 질이 떨어진다고 합니다. 알림도 같은 철학을 따릅니다. 모든 구성원이 자기 GitHub 알림을 제대로 설정해 뒀다고(Settings에서 “Participating"과 “Watching"의 “Web and Mobile” 체크) 신뢰하고, 이슈의 Questions 섹션에서 태그는 최소한으로 답니다.

내가 가져갈 것

#

회의에서 있었던 일을 그 자리에 없던 사람에게 온전히 설명하기란 불가능합니다. 하지만 글로 남은 결정은 누구나 읽을 수 있죠. Alan 스스로도 이게 최선이자 유일한 시스템이라고 하진 않습니다. 그저 자기들에게 가장 잘 맞았을 뿐이라고요. 방해가 줄고, 방관자 효과가 옅어지고, 한 걸음 물러나 사실에 기반해 결정하게 됐다는 겁니다. 저도 우리 팀의 모든 결정을 GitHub 이슈로 옮길 생각까진 없지만, 아래 템플릿은 바로 우리 저장소에 넣을 겁니다.

바로 쓰는 GitHub 이슈 템플릿

#

포럼으로 쓰는 저장소에 이 파일을 .github/ISSUE_TEMPLATE/decision.md로 저장해 두면, 누가 새 이슈를 열 때마다 GitHub가 이 템플릿을 띄워 줍니다. 섹션 구성은 Alan의 것이고, LOCI 항목과 라벨은 제가 덧붙였습니다.

---
name: 의사결정
about: 결정을 제안하고 의견을 글로 모읍니다
title: "[결정] "
labels: decision
---

## 범위
- 이 이슈의 목표는 ...
- 이 이슈는 ...에 관한 것이 아닙니다

## 이 이슈를 여는 이유

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## 타임라인
- 기여 마감:
- 결정 기한:

## 맥락과 자료

## 제안

## 질문

GitHub Issues와 GitHub Projects, 뭘 써야 할까?

#

GitHub를 좀 더 넓게 프로젝트 관리에 쓸 생각이라면, 둘은 하는 일이 다르다는 걸 알아 두면 좋습니다. Issues는 논의를 담고, 닫히고 나면 결정을 담습니다. GitHub Projects는 하나 이상의 저장소에 흩어진 이슈들 위에 얹는 보드나 테이블로, 상태나 담당자, 마감일 같은 필드를 직접 만들어 붙일 수 있습니다. Alan 같은 의사결정 포럼이라면 라벨과 이슈 목록만으로 충분합니다. 열려 있는 결정을 한 화면에서 결정 기한순으로 보고 싶어질 때, 그리고 실제 개발 업무까지 같은 곳에서 관리하기 시작할 때 Project를 더하면 됩니다. 대부분의 팀이 결국 둘 다 쓰게 되는 게 바로 그 지점이죠.

사람들은 왜 그걸 갖고 싶어 할까요? 생각보다 이 질문을 자주 붙잡고 삽니다. 이 글을 처음 쓸 때 저는 사람들이 하루 종일 화장품 이야기를 나누는 플랫폼에서 일하고 있었는데, 거의 똑같은 두 제품 중 하나는 다들 탐내고 하나는 외면당하는 이유가 사실상 사업의 전부였습니다. 취향은 물론 개인적이지만, 그 밑에 깔린 패턴은 놀랄 만큼 일관됩니다.

디자이러빌리티, 실현 가능성, 사업성

#

이 세 가지 렌즈는 디자인 씽킹에서 나온 것이고, 지금은 제품 팀이 아이디어에 본격적으로 뛰어들기 전에 점검하는 흔한 방법이 됐습니다. 쓸모 있는 부분은 셋이 각자 다른 방식으로 실패한다는 점입니다. 만들 수 있고 사업성도 있는데 아무도 원하지 않는 제품은 스타트업의 전형적인 실패입니다. 잘 만들었고 가격도 합리적인데, 아무도 거들떠보지 않죠. 다들 원하는데 만들 수가 없거나 돈을 못 버는 제품은, 적어도 실패할 이유가 미리 보이기라도 합니다.

팀이 가장 자주 건너뛰는 게 디자이러빌리티입니다. 측정하기는 가장 어렵고, 당연히 있다고 가정하기는 가장 쉬우니까요. 팀원들은 이미 자기가 만드는 걸 원합니다. 그건 다른 사람들에 대해서는 아무것도 알려 주지 않습니다.

이 글의 나머지는 디자이러빌리티가 무엇으로 이루어지는지, 그리고 그걸 어떻게 확인하는지에 대한 이야기입니다.

일단 제 역할을 해야 하고, 계속 해야 한다

#

갖고 싶다는 마음은 대개 소박한 쓸모에서 출발합니다. 정말로 10분을 아껴 주는 주방 도구, 그냥 끊기지 않고 연결해 주는 스마트폰 같은 것들이요. 하지만 쓸모만으로는 “괜찮네” 정도에서 멈춥니다. 사람들이 진짜 탐내는 물건은 제 역할을 탁월하게 해내고, 그걸 오래 지속합니다. 구매품을 ‘지키고 싶은 소유물’로 바꾸는 건 품질과 내구성입니다. 클래식 카라든가, 주인보다 오래 사는 칼처럼요. 곧 망가질 것 같은 물건을 갈망하는 사람은 없습니다.

뭔가를 느끼게 해야 한다

#

미적인 매력은 우리가 인정하고 싶은 것보다 훨씬 세게 작용합니다. 스포츠카의 라인이나 잘 플레이팅된 요리는 이성이 끼어들기 전에 우리를 먼저 사로잡죠. 그리고 가장 강한 욕망은 감정에서 나옵니다. 기쁨, 향수, 소속감. 너덜너덜해진 어린 시절 장난감은 실용성 시험에서는 전부 낙제인데도 도저히 못 버립니다. 개인화도 같은 본능을 건드립니다. 나에게 맞춰진 물건은 기성품이 절대 줄 수 없는 ‘내 것’이라는 감각을 줍니다.

생각보다 많은 걸 남들이 정한다

#

갖고 싶은 마음의 일부는 사회적으로 만들어집니다. 트렌드, 주변의 인정, 문화적 규범이 우리의 욕망을 조용히 조종하죠. 희소성도 마찬가지입니다. 한정판, 희귀한 보석, 단 하나뿐인 물건. 희소하다는 건 “이걸 원하는 것만으로 작은 클럽에 속하게 된다"는 신호입니다. 그리고 평판이 이 모든 걸 증폭합니다. 호평 일색인 리뷰와 입소문은 그걸 원해도 안전하다는 확신을 주니까요. 그 화장품 플랫폼에서 저는 이 루프가 돌아가는 걸 하루도 빠짐없이 지켜봤습니다. 다들 좋아하는 리뷰어 한 명, 소량만 나온 제품 하나, 그리고 일주일 뒤면 품절이었죠.

그래도 계산은 맞아야 한다

#

가격이 욕망을 죽이지는 않습니다. 밑지는 거래라는 느낌이 죽이죠. 사람들은 럭셔리에는 기꺼이 웃돈을 내면서도, 힘들게 번 돈이 아깝다 싶은 것에서는 미련 없이 돌아섭니다. 그리고 요즘은 가치관도 같은 계산식 안에 들어왔습니다. 지속가능하게, 윤리적으로 만들어졌는지가 많은 사람들의 위시리스트 순위를 올리고 내립니다. 저도 그중 하나고요.

갖고 싶은 제품인지 검증하는 법

#

디자이러빌리티의 함정은 사람들에게 직접 물어봐서는 소용이 없다는 겁니다. “이거 쓰시겠어요?“라고 물으면 거의 모두가 예의 바르게 “네"라고 합니다. 네라고 하는 데는 아무 비용이 안 드니까요. 효과가 있는 테스트는 전부 시간, 돈, 이메일 주소, 습관 같은 걸 내놓으라고 요청하고, 사람들이 실제로 내놓는지 지켜보는 방식입니다.

미래가 아니라 과거를 물으세요. “이 문제를 마지막으로 겪었을 때 얘기를 해 주세요. 그때 어떻게 하셨어요?“라고 물으면 실제 행동이 나옵니다. 마지막으로 겪은 때를 아무도 기억 못 한다면, 그 문제는 해결책을 원할 만큼 아프지 않은 겁니다.

가짜 문(fake door)을 세우세요. 아직 존재하지 않는 무언가의 랜딩 페이지나 기존 제품 안의 버튼을 만들어 두고, 몇 명이 클릭해 들어오는지, 이메일을 남기는지 셉니다. 살짝 얌체 같은 느낌이 들지만, 이만큼 싸면서도 정직한 신호는 없습니다. 문 너머에서는 곧 나온다고 솔직하게 알려 주세요.

약속을 요청하세요. 대기자 명단은 약한 신호고, 사전 주문이나 예약금은 강한 신호입니다. 사람들은 아무거나 가입은 해도, 돈은 원하는 것에만 냅니다.

이미 쓰고 있는 제품이라면, 더 이상 못 쓰게 되면 기분이 어떨지 물어보세요. 제품 쪽에서 흔히 쓰는 경험칙으로, 사용자의 40% 정도가 “매우 실망할 것"이라고 답하면 사람들이 진짜 원하는 걸 만든 겁니다. 거친 지표이긴 하지만, 마음에 드냐고 묻는 것보다는 훨씬 낫습니다.

그리고 사람들이 하는 말보다 하는 행동을 보세요. 어떤 기능을 두 번째로 쓰는지, 알림이 없어도 다시 찾아오는 기능이 뭔지, 고장 났을 때 무엇에 대해 불평하는지. 여기서 불평은 과소평가되어 있습니다. 원하지도 않던 걸 잃었다고 불평하는 사람은 없으니까요.

하나로 모아 보면

#

이 요소들 중 어느 하나만으로 제품이 서지는 않습니다. 하지만 몇 가지가 겹치면, 그러니까 정말 쓸모 있고, 잘 만들어졌고, 보기 좋고, 약간 구하기 어렵고, 믿을 만한 사람들이 보증까지 해 준다면, 사람들이 줄 서는 물건이 됩니다. 나머지는 대부분 마케팅의 몫입니다.

정리하면

#

디자이러빌리티는 필요와 별개로 사람들이 무언가를 얼마나 원하는지입니다. 제품 관점에서는 실현 가능성, 사업성과 나란히 놓이는 “사람들이 이걸 원하는가?“라는 렌즈입니다. 오래가는 쓸모, 감정적이거나 미적인 끌림, 사회적 증거와 희소성, 그리고 합당하다고 느껴지는 가격에서 나옵니다. 써 보겠냐고 물어서는 찾을 수 없습니다. 실제로 뭔가를 내놓으라고 요청하고, 사람들이 어떻게 행동하는지 지켜보면서 검증하세요.