시니어 개발자가 자신의 전문성을 전달하지 못하는 이유 — 복잡도 관리 vs 불확실성 감소
목차
개요
시니어 개발자는 종종 자신이 가진 전문성을 비즈니스 측에 제대로 전달하지 못한다. 원인은 화술이 부족해서가 아니다. 시니어 개발자는 문제를 “복잡도 관리(complexity management)” 관점에서 정의하는 반면, 비즈니스 쪽은 “불확실성 감소(uncertainty reduction)” 관점에서 같은 문제를 본다. 같은 사안을 보는 두 개의 다른 문제 프레임이 충돌하며 소통의 단절이 발생한다.
원문은 “You can’t explain away someone else’s problem using your own problems.”라고 정리한다. 자기 문제로 상대의 문제를 설명하려 하면 통하지 않는다는 뜻이다.
두 종류의 시니어 개발자
저자는 시니어 개발자를 두 부류로 나눈다.
첫 번째는 “도구 중심” 시니어다. “이 회사는 X를 쓴다”, “HackerNews에서 이렇게 말한다” 같은 외부 출처를 인용하며 의견을 만든다.
두 번째는 “문제 회피형” 시니어다. “정말 그게 필요한가?”를 먼저 묻고, 복잡도 자체를 줄이려 한다. 저자가 들을 가치가 있다고 보는 전문성은 후자 쪽이다. 복잡도라는 단일한 괴물을 사냥하는 사람들이다.
경쟁하는 두 개의 비즈니스 루프
조직에서는 두 가지 운영 루프가 동시에 돌아간다. 이 둘은 둘 다 정당한 목표를 가지지만, 시간에 대한 인식이 정반대다.
Loop 1 — 불확실성 감소
마케팅, 세일즈, 프로덕트, 리더십이 운영하는 루프다. 시장 도달 속도와 빠른 피드백 사이클을 우선한다. 이들이 사냥하는 괴물은 불확실성이고, 해법은 속도다.
Loop 2 — 복잡도 관리
시니어 개발자가 운영하는 루프다. 안정성, 디버깅 가능성, 가르칠 수 있는 구조, 지속적인 고객 서비스 유지를 우선한다. 이들이 사냥하는 괴물은 복잡도이고, 해법은 조심스러운 절제다.
소통이 실패하는 지점
전형적인 실패 패턴은 다음과 같다. 비즈니스가 기능 요청을 가져온다. 시니어 개발자는 유지보수 비용, 이해 가능성 저하, 시스템 위험 같은 복잡도 경고로 반응한다. 비즈니스는 그 답이 자신의 문제(시장 검증 속도)를 다루지 않는다고 느낀다.
저자가 제안하는 다른 표현은 단순하다. “더 빠르게 시도할 다른 방법이 없을까?(Can we try something quicker?)”
이 문장은 세 가지를 동시에 한다.
| 효과 | 설명 |
|---|---|
| 비즈니스 목표 인정 | 속도가 진짜 목표라는 점을 받아준다 |
| 자원 재활용 제안 | 기존 시스템 활용을 권한다 |
| 불완전함 허용 | “try”라는 단어로 반복 개선을 전제한다 |
실전 예시로는 다음과 같은 것들이 거론된다.
- 자체 설문 시스템 대신 Google Forms 활용
- 본 기능 구현 전 UI 버튼만 먼저 붙여 수요 테스트
- 종합 분석 시스템 대신 단일 지표/차트 한 개로 시작
- 자원 재배치로 불필요한 신규 구축 회피
AI가 가져온 새로운 변수
AI는 이 균형을 흔든다. Loop 1의 속도는 가속한다. 반면 Loop 2의 안정성은 더 불안정해진다. 책임 소재가 모호한 코드가 시스템에 들어오면서 이해 가능성과 디버깅 가능성이 떨어진다. 시니어 개발자가 관리하려 했던 영역이 바로 그곳이다.
해법 — Speed/Scale 분리 모델
원문은 시스템을 두 개의 병렬 트랙으로 나누는 방식을 제안한다.
| 트랙 | 성격 | 인력 | 산출물 |
|---|---|---|---|
| Speed 버전 | 시장 테스트용 빠른 기능 | AI, 주니어, 비엔지니어 환영 | 거칠지만 동작하는 결과물 |
| Scale 버전 | 시니어가 안정화한 운영 시스템 | 시니어 중심 | 리뷰, 이해 가능성, 아키텍처 일관성 |
기능은 Speed에서 시제품 단계를 거친 뒤 Scale로 성숙한다. 이 구조의 장점은 셋이다.
- 비즈니스는 학습 속도를 잃지 않는다
- 시니어 개발자는 시스템 무결성을 지킬 수 있다
- “Speed 3일, Scale 6주” 같은 식으로 서로 다른 타임라인을 명확히 말할 수 있다
핵심 실패 패턴은 시니어 개발자가 자신을 “막는 사람(preventer)”으로 위치시키는 것이다. “이걸 짓지 마라”가 아니라 “이렇게 더 빠르게 지을 수 있다”가 되어야 한다. 역할은 작가가 아니라 편집자다. 품질 게이트를 통해 코드를 다듬는 사람이지, 진행을 막는 장벽이 아니다.
커뮤니티 반응
GeekNews 토픽 댓글에서는 같은 맥락의 보강 의견들이 이어진다.
- 전문성은 내적 멘탈 모델에서 발생하며 소통과 분리할 수 없다는 의견
- 지식은 어느 정도 전달되지만 깊이 내재화된 세계관은 전달이 잘 안 된다는 지적
- 100명짜리 CRUD SaaS와 CT 스캐너 펌웨어에서는 속도/안정성 절충점이 다르다는 도메인 의존성 지적
- 일단 Speed 버전이 나가면 조직은 계속 Speed만 요구하고, 리더십이 엔지니어링 함의를 이해하지 못하면 Scale 버전은 계속 밀린다는 현실 비판
- 가시적 기능 출시에 자신의 자리가 걸려 있는 의사결정자는 안정성 경고를 듣지 않으며, 인센티브 구조가 기술적 합리성을 압도한다는 비판
결론
문제는 시니어 개발자의 판단이 틀려서가 아니다. 판단을 전달하는 언어가 비즈니스의 문제 언어와 같지 않기 때문이다. 복잡도라는 단어를 일단 내려놓고, 상대의 문제(속도, 불확실성)를 인정한 뒤 더 가벼운 대안을 제시하는 쪽이 더 효과적이다. AI 도구가 Loop 1을 더 빠르게 만들어 줄수록, Loop 2를 지키는 사람의 언어 전환은 더 중요해진다.