매번 기술 선택 앞에서 멈추는 당신에게
새 프로젝트를 시작할 때마다 찾아오는 익숙한 고민이 있습니다. “데이터베이스는 뭘 쓰지?”, “프론트엔드는 React로 할까, 아니면 요즘 뜬다는 걸로 갈아탈까?”, “AI 도구는 어떤 걸 도입해야 우리 팀에 맞을까?” 2026년 여름 현재, 개발자가 선택할 수 있는 기술 옵션은 역대 최대치를 기록하고 있습니다. GitHub에는 매주 새 프레임워크가 별을 받고, AI 관련 서비스만 해도 수십 개가 치열하게 경쟁 중이죠.
선택지가 풍부한 건 분명 좋은 일입니다. 하지만 그 풍요가 오히려 결정을 가로막기도 합니다. 심리학에서 말하는 ‘선택의 역설(Paradox of Choice)’이 IT 기술 선택에도 정확히 적용됩니다. 선택지가 늘어날수록 결정에 대한 만족도는 떨어지고, 결정을 미루는 시간만 길어집니다. 그래서 많은 개발자와 IT 팀이 결국 “제일 유명한 걸로 하자” 또는 “팀장님이 좋다는 걸로”라는 비체계적인 방식에 기대게 됩니다.
이런 방식이 항상 나쁜 건 아닙니다. 작은 사이드 프로젝트나 되돌리기 쉬운 결정이라면 빠르게 감으로 골라도 괜찮습니다. 하지만 프로젝트 규모가 커지거나, 한번 선택하면 수개월 치 코드가 그 위에 쌓이는 핵심 기술일수록 이야기가 달라집니다. 이 글에서는 기술 선택을 ‘감’이 아닌 구조화된 의사결정 프레임워크로 접근하는 방법을 다룹니다. 그중에서도 실무에서 바로 쓸 수 있는 가중 평가 매트릭스(Weighted Scoring Matrix)를 중심으로, 다음번 기술 선택에서 후회를 줄이는 구체적인 단계를 안내하겠습니다.
왜 ‘감’으로 기술을 고르면 실패 확률이 높을까
먼저 왜 직관적인 기술 선택이 위험한지부터 짚어볼 필요가 있습니다. 경험 많은 시니어 개발자의 직관은 물론 가치가 있지만, 그 직관조차 여러 인지 편향(cognitive bias)의 영향을 받습니다. 기술 선택에서 흔히 나타나는 편향 네 가지를 살펴보겠습니다.
확증 편향: 이미 마음에 든 기술의 장점만 보인다
확증 편향(Confirmation Bias)은 의사결정에서 가장 흔하고 강력한 함정입니다. 어떤 기술에 호감을 느끼면, 무의식적으로 그 기술에 유리한 벤치마크, 블로그 글, 성공 사례만 찾게 됩니다. 반대로 단점이나 실패 사례는 “우리 경우는 다르지”라며 무시하게 되죠. 예를 들어, 이미 MongoDB에 마음이 끌렸다면 “스키마 유연성”이라는 장점에만 집중하고, 복잡한 조인 쿼리가 필요한 자신의 프로젝트 특성은 간과하기 쉽습니다. 체계적인 프레임워크는 모든 후보를 동일한 기준으로 평가하게 함으로써 이 편향을 줄여줍니다.
밴드왜건 효과: 유행이라고 좋은 건 아니다
“요즘 다들 쓴다더라”는 기술 선택에서 가장 위험한 논거 중 하나입니다. 밴드왜건 효과(Bandwagon Effect)는 많은 사람이 선택했다는 사실 자체가 판단 근거가 되는 현상입니다. 물론 활발한 커뮤니티와 풍부한 레퍼런스는 실질적 장점입니다. 하지만 “유행하는 기술”과 “우리 팀에 맞는 기술”은 전혀 다른 질문입니다. 2024년에 유행한 기술이 2026년에는 유지보수 부담이 된 사례를 한두 개쯤 떠올릴 수 있을 겁니다. 트렌드는 평가 기준 중 하나일 뿐이지, 유일한 기준이 되어서는 안 됩니다.
HiPPO 의사결정: 가장 높은 직급의 의견이 곧 결론
HiPPO(Highest Paid Person’s Opinion)는 조직에서 가장 직급이 높거나 영향력이 큰 사람의 의견이 곧 최종 결정이 되는 현상을 말합니다. CTO가 “우리 팀은 Go로 가자”고 하면 팀원들은 반론을 꺼내기 어렵습니다. 경험에서 나온 판단일 수도 있지만, 때로는 그 경험이 과거의 맥락에 묶여 있을 수도 있죠. 현재 팀의 기술 수준, 프로젝트의 실제 요구사항, 채용 시장의 변화 같은 현실적 요소가 무시될 위험이 있습니다. 의사결정 매트릭스는 논리와 데이터 기반의 대화를 가능하게 해서 직급에 상관없이 근거 있는 의견이 반영될 수 있게 돕습니다.
최신 편향: 새로운 것이 무조건 더 낫다는 착각
최신 편향(Recency Bias)은 최근에 접한 정보나 기술에 과도한 비중을 두는 경향입니다. 어제 컨퍼런스에서 인상적인 데모를 본 기술, 이번 주에 읽은 블로그에서 극찬한 라이브러리가 갑자기 최고의 후보처럼 느껴지죠. 하지만 매력적인 데모와 실제 프로덕션 환경에서의 안정성은 완전히 다른 문제입니다. 프레임워크를 사용하면 일시적인 인상이 아니라 지속적이고 측정 가능한 기준으로 기술을 평가하게 됩니다.
IT 의사결정에 쓸 수 있는 프레임워크 세 가지
그렇다면 어떤 프레임워크를 쓸 수 있을까요? 소프트웨어 엔지니어링과 프로덕트 매니지먼트 분야에서 검증된 세 가지 의사결정 도구를 소개합니다. 각각 적합한 상황이 다르므로, 자신의 상황에 맞는 도구를 골라 쓰면 됩니다.
1. 가중 평가 매트릭스 (Weighted Scoring Matrix)
가중 평가 매트릭스는 여러 후보를 동일한 평가 기준으로 비교할 때 가장 효과적인 도구입니다. 핵심 원리는 단순합니다. 평가 기준을 정하고, 각 기준의 중요도(가중치)를 설정한 뒤, 모든 후보에 동일한 척도로 점수를 매겨 가중 합산하는 것이죠.
이 방법의 가장 큰 장점은 투명성입니다. 왜 A 기술 대신 B를 골랐는지, 어떤 기준이 결정적이었는지가 숫자로 명확하게 남습니다. 팀원 간의 이견이 있을 때 “어떤 기준의 가중치를 다르게 보는가”로 논의를 좁힐 수 있어서, 감정적인 논쟁 대신 건설적인 대화가 가능해집니다.
적합한 상황은 이렇습니다.
- 데이터베이스, 클라우드 서비스, 프레임워크 등 2개 이상의 후보를 비교할 때
- 팀 내에서 의견이 갈릴 때 합의의 도구로 활용할 때
- 선택의 근거를 문서로 남겨야 할 때 (감사, 회고 등)
2. RICE 스코어링
RICE는 Reach(도달 범위), Impact(영향력), Confidence(확신도), Effort(노력)의 약자로, 원래 프로덕트 매니지먼트에서 기능 우선순위를 정하는 데 쓰이는 프레임워크입니다. 하지만 “어떤 기술을 먼저 도입할까?”라는 우선순위 결정에도 효과적으로 활용할 수 있습니다.
RICE 점수는 (Reach × Impact × Confidence) ÷ Effort로 계산합니다. 예를 들어, CI/CD 파이프라인 도입과 코드 리뷰 자동화 도구 도입 중 뭘 먼저 할지 고민이라면, 각각의 RICE 점수를 계산해 더 높은 쪽을 먼저 진행하는 식입니다.
다만 RICE는 “A냐 B냐”의 비교보다는 “무엇을 먼저 하느냐”의 순서 결정에 더 적합합니다. 기술 스택 자체를 고르는 상황보다는 여러 기술 이니셔티브의 실행 순서를 정할 때 빛을 발합니다.
3. ADR (Architecture Decision Records)
ADR(아키텍처 의사결정 기록)은 엄밀히 말해 의사결정 ‘도구’보다는 의사결정을 기록하고 공유하는 형식입니다. 하지만 ADR을 작성하는 과정 자체가 의사결정의 질을 높여주기 때문에 함께 소개합니다.
ADR은 보통 다음 구조를 따릅니다.
- 제목: 결정의 핵심을 한 줄로
- 상태: 제안됨 / 수락됨 / 폐기됨 / 대체됨
- 맥락: 이 결정이 필요한 배경
- 결정: 무엇을 선택했는가
- 결과: 이 결정으로 예상되는 장단점
ADR의 진짜 가치는 “6개월 뒤의 나”에게 보내는 편지 역할을 한다는 데 있습니다. 왜 그때 MySQL 대신 PostgreSQL을 골랐는지, 그 맥락을 기록해두면 나중에 상황이 바뀌었을 때 재평가의 출발점이 됩니다. 가중 평가 매트릭스로 결정을 내린 뒤, 그 과정과 결과를 ADR로 기록하는 것이 가장 이상적인 조합입니다.
언제 어떤 프레임워크를 쓸까
세 도구는 서로 경쟁 관계가 아니라 보완 관계입니다. 정리하면 이렇습니다.
- 후보 비교 (A vs B vs C) → 가중 평가 매트릭스
- 실행 순서 (뭘 먼저?) → RICE 스코어링
- 결정 기록 (왜 이걸?) → ADR
이 글에서는 가장 범용적이고 실전 활용도가 높은 가중 평가 매트릭스를 5단계로 나눠서 자세히 다루겠습니다.
가중 평가 매트릭스 5단계 실전 가이드
가중 평가 매트릭스의 원리는 간단하지만, 실제로 효과적으로 활용하려면 각 단계에서 주의할 점이 있습니다. 하나씩 살펴보겠습니다.
1단계: 평가 기준을 정의한다
첫 번째이자 가장 중요한 단계입니다. 어떤 기준으로 기술을 평가할지 정하는 것이죠. 평가 기준이 잘못되면 아무리 점수를 정교하게 매겨도 결과가 의미 없습니다.
IT 기술 선택에서 자주 쓰이는 평가 기준을 유형별로 정리하면 다음과 같습니다.
기술적 기준
- 성능: 처리 속도, 응답 시간, 동시 처리 능력
- 확장성: 사용자나 데이터가 늘었을 때 대응 가능한 정도
- 보안: 알려진 취약점, 보안 업데이트 주기, 인증/인가 지원
- 호환성: 기존 시스템, 기술 스택과의 통합 용이성
운영적 기준
- 유지보수 난이도: 디버깅, 모니터링, 업그레이드의 편의성
- 커뮤니티와 생태계: 라이브러리, 플러그인, 서드파티 도구의 풍부함
- 문서 품질: 공식 문서의 완성도, 튜토리얼 접근성
- 인력 확보: 해당 기술을 다룰 수 있는 개발자 채용 용이성
비즈니스 기준
- 비용: 라이선스, 인프라, 운영에 드는 총 비용(TCO)
- 학습 곡선: 팀이 생산성을 낼 때까지 걸리는 시간
- 벤더 종속(Lock-in) 위험: 나중에 다른 기술로 전환할 때의 비용
- 라이선스: 오픈소스 라이선스 조건이 프로젝트에 부합하는지
여기서 중요한 원칙이 하나 있습니다. 평가 기준은 5~7개로 제한하세요. 기준이 너무 많으면 오히려 의미 있는 차이가 희석됩니다. 10개 기준으로 평가하면 각 기준의 가중치가 평균 10%밖에 되지 않아서, 정말 중요한 요소의 영향력이 줄어듭니다. 프로젝트의 맥락에서 “이것 때문에 프로젝트가 성공하거나 실패한다”고 말할 수 있는 핵심 기준만 남기세요.
2단계: 가중치를 배분한다
기준을 정했으면 각 기준의 상대적 중요도를 수치로 표현합니다. 이것이 가중치(weight)입니다. 가중치의 합은 100%(또는 1.0)이 되게 맞추는 것이 일반적입니다.
가중치 배분에서 가장 흔한 실수는 “다 중요하니까 비슷하게 주자”입니다. 모든 기준에 동일한 가중치를 주면 가중 평가 매트릭스를 쓰는 의미가 사라집니다. 결국 단순 합산과 같아지니까요.
편향을 줄이면서 가중치를 정하는 실용적인 방법 두 가지를 추천합니다.
방법 1: 쌍대 비교(Pairwise Comparison)
모든 기준을 두 개씩 짝지어 “이 둘 중 뭐가 더 중요한가?”를 비교합니다. 5개 기준이면 총 10번의 비교를 하게 됩니다. 각 기준이 “이겼던” 횟수를 세서 비율로 변환하면 자연스러운 가중치가 나옵니다. 이 방법은 한 번에 모든 기준의 중요도를 직관적으로 판단하는 것보다 훨씬 일관된 결과를 만들어줍니다.
방법 2: 100점 배분법(Point Allocation)
100점을 기준들 사이에 자유롭게 나눠주는 방식입니다. 성능이 가장 중요하면 30점, 비용이 그 다음이면 25점, 학습 곡선에 20점… 하는 식이죠. 쌍대 비교보다 직관적이지만, 기준 수가 많으면 배분이 어려워지는 단점이 있습니다. 기준이 5개 이하일 때 추천하는 방법입니다.
팀으로 결정할 때는 각 팀원이 독립적으로 가중치를 매긴 뒤 평균을 내는 것이 좋습니다. 먼저 누군가의 가중치를 보여주면 앵커링 효과로 다른 사람의 판단이 끌려가거든요. 각자 적은 뒤 한꺼번에 공개하면 이 문제를 줄일 수 있습니다.
3단계: 후보 기술을 나열한다
비교할 기술 후보 목록을 만듭니다. 여기서도 몇 가지 원칙이 있습니다.
- 후보는 3~5개로 제한합니다. 7개 이상이면 비교 자체가 부담이 됩니다. 사전 조사를 통해 명백히 부적합한 후보는 먼저 걸러내세요.
- 같은 카테고리의 기술만 비교합니다. PostgreSQL과 Redis를 비교하는 건 의미가 없습니다. 둘은 해결하는 문제가 다르니까요. “관계형 데이터베이스 중에서” 또는 “인메모리 캐시 중에서”처럼 범위를 맞추세요.
- “현상 유지”도 후보에 넣으세요. 새 기술 도입을 검토하는 상황이라면 “지금 쓰는 기술을 계속 쓴다”는 선택지도 비교 대상에 포함해야 합니다. 이걸 빼면 ‘바꿔야 한다’는 전제가 무의식적으로 깔리게 됩니다.
4단계: 점수를 매긴다
각 후보 기술에 대해 모든 평가 기준별로 점수를 매깁니다. 보통 1~5점 또는 1~10점 척도를 사용합니다. 5점 척도를 추천하는데, 10점 척도는 6점과 7점의 차이를 설명하기 어려운 경우가 많아서 오히려 노이즈가 생깁니다.
점수 매기기에서 핵심적인 주의사항 세 가지입니다.
첫째, 척도의 의미를 미리 정의하세요. “3점이 뭘 뜻하는가”를 사전에 합의하지 않으면 사람마다 다른 기준으로 점수를 매기게 됩니다. 예를 들어 성능 기준의 경우 “1점: 벤치마크 하위 20%, 3점: 중간, 5점: 해당 카테고리 최상위”처럼 구체적인 앵커를 잡아두면 일관성이 올라갑니다.
둘째, 감이 아니라 근거를 기록하세요. “이 기술의 커뮤니티 활성도에 4점을 줬다”면, 그 근거가 뭔지 메모를 남겨야 합니다. GitHub 스타 수, Stack Overflow 질문 빈도, 공식 Discord/Slack 멤버 수 같은 객관적 지표가 있으면 더 좋습니다. 이 기록이 있어야 나중에 “왜 그때 이 점수를 줬지?”라는 의문에 답할 수 있습니다.
셋째, 독립 평가 후 합산하세요. 앞서 가중치 배분에서도 언급했지만, 팀 평가 시에는 반드시 각자 독립적으로 점수를 매긴 뒤 합산해야 합니다. 한 사람이 먼저 점수를 공개하면 나머지 사람의 판단이 그쪽으로 편향됩니다.
5단계: 가중 점수를 계산하고 민감도를 분석한다
각 기준의 점수에 해당 기준의 가중치를 곱한 뒤 합산하면 최종 가중 점수가 나옵니다. 가장 높은 점수를 받은 기술이 가중 평가 매트릭스가 추천하는 선택지입니다.
하지만 여기서 한 단계 더 나가야 합니다. 민감도 분석(Sensitivity Analysis)입니다. 이것은 “가중치나 점수가 조금 달라졌을 때 결과가 바뀌는가?”를 확인하는 작업입니다.
예를 들어, A 기술이 78점이고 B 기술이 76점이라면 사실상 무의미한 차이입니다. 이때 가장 가중치가 높은 기준의 점수를 1점씩 변동시켜 보세요. A와 B의 순위가 자주 뒤집힌다면 이 두 기술은 “매트릭스로는 구분이 안 되는 수준”이라는 뜻입니다. 이 경우에는 매트릭스 외의 요소, 예를 들어 팀의 기존 경험이나 기술적 친밀도 같은 정성적 요소로 최종 결정을 내리면 됩니다.
반대로, A 기술이 82점이고 B 기술이 65점이라면 가중치를 상당히 변경해도 순위가 뒤집히지 않습니다. 이런 경우가 매트릭스가 확실한 답을 주는 케이스이며, 자신 있게 A를 선택할 수 있습니다.
실전 예시: 사이드 프로젝트 데이터베이스 고르기
이론만으로는 와닿지 않을 수 있으니, 구체적인 예시를 하나 만들어 보겠습니다. 2026년 여름, 개인 사이드 프로젝트의 데이터베이스를 선택하는 상황을 가정해 봅니다.
프로젝트 배경: 개인 독서 기록 및 AI 기반 요약 관리 웹앱. 1인 개발, 사용자 수 초기 100명 이하, 배포는 클라우드(Vercel/Railway 등), 추후 확장 가능성은 열어둠.
후보 기술 4가지
- PostgreSQL: 오픈소스 관계형 DB의 대표. 풍부한 기능, 강력한 생태계.
- MySQL: 가장 오래되고 널리 쓰이는 관계형 DB. 단순하고 빠른 읽기 성능.
- SQLite: 파일 기반 경량 DB. 서버가 필요 없어 초기 비용 제로.
- Supabase: PostgreSQL 기반 BaaS(Backend as a Service). 인증, 스토리지, 실시간 구독까지 올인원.
평가 기준과 가중치 (100점 배분법 사용)
- 학습 곡선 (25%): 혼자 개발하므로 빠르게 익힐 수 있는 게 중요
- 비용 (25%): 사이드 프로젝트이므로 무료 또는 최저 비용 선호
- 확장성 (20%): 사용자가 늘어날 가능성에 대비
- 생태계/ORM 지원 (15%): 선호하는 언어/프레임워크와의 호환성
- 배포 편의성 (15%): 클라우드에 쉽게 올릴 수 있는지
점수 매기기 (1~5점, 근거 메모 포함)
학습 곡선에서 SQLite는 설정이 거의 없으므로 5점, Supabase는 대시보드가 직관적이므로 4점, PostgreSQL은 기능이 많은 만큼 초기 학습량도 있어서 3점, MySQL도 비슷하게 3점을 부여합니다.
비용에서 SQLite는 파일 기반이므로 서버 비용이 0원에 가까워 5점, PostgreSQL과 MySQL은 무료 티어가 있는 클라우드 호스팅(Neon, PlanetScale 등)을 쓰면 초기 무료이므로 4점, Supabase는 무료 티어가 넉넉하므로 4점을 줍니다.
확장성에서 PostgreSQL은 5점(수직·수평 확장 모두 강력), Supabase도 PostgreSQL 기반이라 4점, MySQL은 4점, SQLite는 동시 쓰기에 약해서 2점입니다.
생태계/ORM 지원에서 PostgreSQL은 거의 모든 ORM이 지원하므로 5점, MySQL도 5점, Supabase는 자체 클라이언트 + PostgreSQL ORM 가능이라 4점, SQLite는 대부분 ORM이 지원하나 일부 기능 제한으로 4점입니다.
배포 편의성에서 Supabase는 관리형 서비스라 5점, SQLite는 파일 복사만 하면 되니 4점이지만 클라우드 환경에서 영속 스토리지 이슈가 있어 3점으로 조정, PostgreSQL은 Neon이나 Railway로 원클릭 배포 가능하므로 4점, MySQL도 비슷하게 4점입니다.
가중 점수 계산
- PostgreSQL: (3×0.25) + (4×0.25) + (5×0.20) + (5×0.15) + (4×0.15) = 0.75 + 1.00 + 1.00 + 0.75 + 0.60 = 4.10
- Supabase: (4×0.25) + (4×0.25) + (4×0.20) + (4×0.15) + (5×0.15) = 1.00 + 1.00 + 0.80 + 0.60 + 0.75 = 4.15
- MySQL: (3×0.25) + (4×0.25) + (4×0.20) + (5×0.15) + (4×0.15) = 0.75 + 1.00 + 0.80 + 0.75 + 0.60 = 3.90
- SQLite: (5×0.25) + (5×0.25) + (2×0.20) + (4×0.15) + (3×0.15) = 1.25 + 1.25 + 0.40 + 0.60 + 0.45 = 3.95
결과 해석과 민감도 분석
Supabase가 4.15점으로 1위, PostgreSQL이 4.10점으로 근소한 2위입니다. 이 0.05점 차이는 의미 있을까요? 민감도 분석을 해봅시다. 학습 곡선의 가중치를 25%에서 15%로, 확장성을 20%에서 30%로 바꾸면 PostgreSQL이 역전합니다. 즉, 이 두 기술은 매트릭스만으로는 확실한 우열을 가리기 어려운 수준입니다.
이럴 때는 정성적 요소를 고려합니다. “PostgreSQL을 직접 다뤄보며 데이터베이스를 깊이 배우고 싶다”면 PostgreSQL, “빠르게 프로토타입을 만들고 인증·스토리지 같은 부가 기능도 편하게 쓰고 싶다”면 Supabase를 고르면 됩니다. 핵심은 두 기술 모두 합리적인 선택이라는 점을 매트릭스가 확인해줬다는 데 있습니다. 어느 쪽을 골라도 “완전히 잘못된 결정”은 아닌 것이죠.
반면 MySQL과 SQLite는 이 프로젝트 맥락에서는 상위 두 후보보다 약간 뒤처지는 것이 숫자로 드러났습니다. 감으로 “MySQL이 제일 안전하지 않을까?”라고 느꼈더라도, 실제 평가 기준에 비추면 이 프로젝트에는 최적이 아닐 수 있다는 판단이 가능해지는 겁니다.
의사결정 프레임워크를 쓸 때 빠지기 쉬운 함정 다섯 가지
가중 평가 매트릭스가 만능은 아닙니다. 도구를 잘못 쓰면 오히려 잘못된 결정에 “분석적으로 검증됨”이라는 가짜 권위를 씌우는 결과가 됩니다. 흔히 빠지는 함정 다섯 가지를 미리 알아두세요.
함정 1: 원하는 결과에 맞춰 가중치를 역설계한다
가장 위험한 함정입니다. 이미 마음속으로 고른 기술이 있고, 그 기술이 1등을 하도록 가중치를 조정하는 것이죠. 이렇게 되면 프레임워크는 편향을 감추는 도구로 전락합니다. 예방법은 간단합니다. 가중치를 먼저 정한 뒤에 점수를 매기세요. 가중치를 정할 때는 아직 후보 기술의 점수를 알면 안 됩니다. 순서가 생명입니다.
함정 2: 정량화할 수 없는 요소를 무시한다
매트릭스는 숫자로 표현되는 것에 강합니다. 하지만 기술 선택에는 “팀의 사기”, “기술적 호기심”, “개발자 경험(DX)의 즐거움” 같은 정성적 요소도 중요합니다. 이런 요소들을 아예 무시하면 숫자적으로는 최적이지만 팀이 쓰기 싫어하는 기술을 고르게 될 수 있습니다. 정성적 요소는 매트릭스 바깥에서 별도로 논의하되, 최종 결정에 반영하세요.
함정 3: 모든 결정에 매트릭스를 꺼낸다
로깅 라이브러리를 고르는 데 2시간짜리 가중 평가를 할 필요는 없습니다. 아마존 창업자 제프 베이조스의 “되돌릴 수 있는 결정(Type 2)”과 “되돌릴 수 없는 결정(Type 1)” 구분이 여기서 유용합니다. Type 2 결정(나중에 바꿀 수 있는 것)은 빠르게 감으로 내리고, Type 1 결정(바꾸려면 대규모 리팩토링이 필요한 것)에만 매트릭스를 투자하세요.
기술 선택에서 Type 1에 해당하는 것들은 이런 것입니다.
- 프로그래밍 언어 (전체 코드베이스 재작성 필요)
- 데이터베이스 엔진 (데이터 마이그레이션 비용 막대)
- 클라우드 공급자 (벤더 종속 위험)
- 핵심 프레임워크 (컨트롤러/모델/라우팅 전체 교체)
반면 Type 2에 해당하는 것들은 이렇습니다.
- HTTP 클라이언트 라이브러리 (인터페이스 래핑하면 교체 용이)
- 포매터/린터 (설정 파일 교체로 전환 가능)
- 테스트 프레임워크 (기존 테스트 대부분 재활용 가능)
- CSS 프레임워크 (컴포넌트 단위 점진 교체 가능)
함정 4: 평가 시점의 스냅샷만 보고 결정한다
기술 생태계는 빠르게 변합니다. 오늘 커뮤니티가 활발한 기술이 1년 뒤에도 그럴 거라는 보장은 없습니다. 매트릭스 점수를 매길 때 현재 상태뿐 아니라 추세(trend)도 함께 고려하세요. GitHub 스타의 절대 수보다 최근 6개월간의 증가율이 더 의미 있는 지표일 수 있습니다. 릴리스 주기, 주요 스폰서의 안정성, 핵심 메인테이너의 활동 빈도 같은 프로젝트 건강 지표를 함께 보면 미래 리스크를 줄일 수 있습니다.
함정 5: 결정을 기록하지 않는다
매트릭스를 열심히 만들어 놓고 스프레드시트를 그냥 닫아버리는 경우가 놀라울 정도로 많습니다. 6개월 뒤 “왜 이 기술을 골랐지?”라는 질문이 반드시 나옵니다. 앞서 소개한 ADR 형식으로 결정의 맥락, 매트릭스 결과, 최종 선택 이유를 기록해두세요. 미래의 자신이나 합류할 새 팀원에게 큰 도움이 됩니다.
결정 이후가 더 중요합니다
의사결정 프레임워크는 최적의 답을 보장하는 마법이 아닙니다. 불확실성 속에서 “합리적으로 방어 가능한 선택”을 도와주는 도구입니다. 완벽한 결정은 없습니다. 하지만 체계적으로 내린 결정에는 두 가지 분명한 이점이 있습니다.
첫째, 실행에 확신을 갖게 됩니다. “이유 있는 결정”이라는 자각은 이후 개발 과정에서 불필요한 의심과 번복을 줄여줍니다. “다른 걸 골랐어야 했나?”라는 생각이 떠올라도 매트릭스를 다시 꺼내 보면 됩니다. 상황이 진짜 바뀌었다면 그때 재평가하면 되고, 바뀌지 않았다면 원래 결정을 신뢰하면 됩니다.
둘째, 팀의 의사결정 역량이 축적됩니다. ADR로 기록된 결정들은 조직의 판단 이력이 됩니다. 새로운 기술 선택 상황이 왔을 때 과거 기록을 참고하면 같은 시행착오를 반복하지 않게 됩니다. 그리고 이런 프레임워크를 반복적으로 사용하면 팀 전체가 구조적으로 사고하는 습관을 기르게 됩니다.
이번 여름, 새 프로젝트를 시작하거나 기술 스택을 재검토할 계획이 있다면 스프레드시트를 하나 열어보세요. 기준 5개를 정하고, 가중치를 배분하고, 후보 3개에 점수를 매기는 데 30분이면 충분합니다. 그 30분이 앞으로 수개월간의 개발 방향을 결정하는 가장 가치 있는 투자가 될 수 있습니다. 감으로 고르는 시대는 지나갔습니다. 데이터와 구조로 기술을 선택하세요.
이미지는 Leonardo AI 로 생성되었습니다.
이미지는 Claude AI 로 생성되었습니다.