개발기획자를 수렁에 빠뜨리는 7가지 착각

개발기획자를 수렁에 빠뜨리는 7가지 착각#

좋은 기획은 좋은 의도에서 출발한다.

사용자에게 더 편리한 기능을 제공하고 싶고, 경쟁 서비스보다 좋은 경험을 만들고 싶고, 개발 일정도 최대한 앞당기고 싶다. 그래서 회의에서는 이런 말들이 자연스럽게 나온다.

"이 정도는 간단하지 않을까요?"

"일단 만들어 놓고 나중에 고치면 되죠."

"사용자가 좋아할 것 같은데요."

"버튼 하나 추가하는 건데 얼마나 걸리겠어요?"

문제는 개발 프로젝트에서 좋은 의도와 낮은 비용은 전혀 같은 의미가 아니라는 것이다.

기획자가 문서에 추가한 한 줄의 요구사항은 개발자에게는 데이터 구조 변경이 될 수 있고, 화면에 추가한 버튼 하나는 API 수정과 권한 검증, 로그 처리, 테스트 코드, 운영 모니터링까지 요구할 수 있다.

겉으로는 단순해 보이는 기능 하나가 실제로는 여러 시스템을 움직이는 출발점인 것이다.

그래서 개발기획자가 반드시 가져야 할 질문은 하나다.

"좋은 기능인가?"가 아니라 "이 기능이 만들어내는 가치가 구현하고 유지하는 비용보다 큰가?"

이 장에서는 좋은 의도로 시작했지만 프로젝트를 수렁으로 끌고 가는 개발기획자의 일곱 가지 착각을 살펴본다.

그리고 각각의 착각에 보이지 않는 가격표를 붙여본다.

1.1 첫 번째 착각: 모호함은 소통의 여지다#

기획서에서 가장 위험한 문장은 의외로 짧다.

"적절하게 표시한다."

"필요한 경우 알림을 보낸다."

"관리자가 설정할 수 있도록 한다."

"기존 방식과 동일하게 처리한다."

작성한 사람에게는 충분히 이해되는 문장일 수 있다.

하지만 개발자는 질문해야 한다.

적절하다는 기준은 무엇인가?

알림은 언제 보내는가?

중복 알림은 허용하는가?

관리자는 누구인가?

설정값의 범위는 어디까지인가?

기존 방식이라는 것은 어느 화면의 어느 버전을 의미하는가?

질문에 답이 없다면 개발자는 결국 자신의 판단으로 빈칸을 채우게 된다.

모호함은 개발자의 자유가 아니다#

모호한 요구사항을 개발자에게 전달하면 개발자가 자유롭게 좋은 방향으로 구현할 것이라고 생각하기 쉽다.

실제 프로젝트에서는 반대 상황이 더 자주 발생한다.

개발자가 추측한다.

기획자가 결과를 확인한다.

생각했던 것과 다르다고 판단한다.

다시 요구사항을 설명한다.

코드를 수정한다.

테스트를 다시 한다.

관련 기능에서 문제가 발생한다.

다시 수정한다.

이렇게 처음에는 한두 문장이었던 모호함이 여러 사람의 시간을 소비하는 재작업 비용으로 변한다.

소프트웨어 개발에서 커뮤니케이션 부족과 요구사항 오해는 기술 부채와 재작업을 만들어내는 대표적인 원인으로 지적된다.

가격표: "일단 이렇게 해주세요"의 실제 비용#

모호함의 비용은 단순히 개발자가 코드를 다시 작성하는 시간만으로 계산해서는 안 된다.

다음처럼 보는 편이 현실적이다.

모호한 요구사항 비용
=
추가 분석 시간
+ 개발 재작업 시간
+ 재테스트 시간
+ 기획 재검토 시간
+ 배포 및 검증 시간
+ 일정 지연으로 인한 기회비용

예를 들어 개발자 두 명이 각각 반나절씩 수정하고, QA 담당자가 다시 테스트하고, 기획자가 결과를 검토해야 한다면 처음의 모호한 문장 하나가 이미 여러 사람의 하루를 소비한 것이다.

그래서 좋은 기획자는 문장을 많이 쓰는 사람이 아니다.

다른 사람이 추측하지 않아도 되는 문장을 쓰는 사람이다.

1.2 두 번째 착각: 기술은 몰라도 기획은 할 수 있다#

기획자가 개발자처럼 코드를 작성할 필요는 없다.

데이터베이스 쿼리를 직접 작성하거나 네트워크 프로토콜을 구현할 필요도 없다.

하지만 그렇다고 기술을 몰라도 된다는 뜻은 아니다.

개발기획자에게 필요한 것은 구현 능력이 아니라 기술적 결과를 예상할 수 있는 이해력이다.

화면 하나 뒤에는 수많은 시스템이 있다#

사용자가 보는 것은 화면이다.

하지만 개발자는 그 뒤를 본다.

로그인 화면 하나에도 인증 시스템, 사용자 데이터베이스, 세션이나 토큰 처리, 보안 정책, 로그인 실패 처리, 비밀번호 초기화, 접근 로그 등이 연결될 수 있다.

기획자는 이렇게 생각할 수 있다.

"회원 등급만 하나 더 추가하면 되잖아요."

그러나 기존 시스템이 단순히 일반회원과 관리자만을 가정하고 만들어졌다면 새로운 등급 하나가 추가되는 순간 권한 체계 전체를 다시 검토해야 할 수도 있다.

화면 하나의 변경이 데이터베이스, API, 관리자 시스템, 통계, 알림, 외부 연동에 연쇄적으로 영향을 줄 수 있는 것이다.

기술을 알아야 하는 진짜 이유#

기획자가 기술을 공부해야 하는 목적은 개발자에게 명령하기 위해서가 아니다.

자신이 작성한 요구사항의 영향 범위를 이해하기 위해서다.

최소한 다음 정도는 이해하고 있는 것이 좋다.

프론트엔드와 백엔드가 어떻게 연결되는가
API는 어떤 역할을 하는가
데이터베이스 구조 변경이 왜 부담이 되는가
인증과 권한은 왜 단순한 화면 문제가 아닌가
외부 서비스 연동에는 어떤 장애 가능성이 있는가
캐시와 비동기 처리가 왜 필요한가
레거시 시스템 변경이 왜 어려운가
테스트와 배포 과정이 왜 필요한가

이 정도만 알아도 기획서의 품질은 크게 달라진다.

가격표: 레거시 시스템 위에 기능 하나 추가하기#

신규 시스템에서는 간단한 기능도 오래된 시스템에서는 비싸질 수 있다.

이를 레거시 할증이라고 생각해볼 수 있다.

기능 비용
=
신규 구현 비용
+ 기존 시스템 분석 비용
+ 호환성 대응 비용
+ 회귀 테스트 비용
+ 운영 위험 비용

그래서 같은 기능이라도 어떤 시스템에 넣느냐에 따라 가격은 전혀 달라진다.

기능의 크기만 보고 개발비를 판단하면 안 되는 이유다.

1.3 세 번째 착각: 기능은 많을수록 좋다#

기획회의에서 아이디어가 많이 나오는 것은 좋은 일이다.

문제는 좋은 아이디어를 모두 구현하려 할 때 시작된다.

즐겨찾기.

알림.

통계.

기능에는 반드시 유지비가 붙는다#

기능의 비용은 출시하면서 끝나지 않는다.

기능 하나를 추가하면 이후에도 계속 비용이 발생한다.

기능의 생애 비용
=
기획
+ 디자인
+ 개발
+ 테스트
+ 배포
+ 모니터링
+ 장애 대응
+ 고객 문의
+ 보안 대응
+ 유지보수
+ 향후 변경 대응

즉 기능 하나를 추가한다는 것은 개발비를 한 번 지불하는 것이 아니다.

그 기능이 존재하는 동안 계속 비용을 지불하겠다는 결정이다.

사용하지 않는 기능도 공짜가 아니다#

아무도 사용하지 않는 기능이라고 해서 비용이 사라지는 것도 아니다.

코드는 남는다.

테스트 대상에도 포함된다.

보안 점검 대상에도 들어간다.

다른 기능을 변경할 때 영향을 받는지 확인해야 한다.

사용하지 않는 기능은 사용자에게 가치를 만들지는 못하면서 시스템의 복잡도만 높일 수 있다.

가격표: 기능 하나의 기회비용#

기능 A를 개발하는 동안 개발팀은 다른 일을 하지 못한다.

그래서 기능의 진짜 비용에는 반드시 포기한 선택지의 가치가 포함되어야 한다.

기능 A의 실제 비용
=
기능 A 개발 및 유지 비용
+ 같은 기간 하지 못한 기능 B의 가치
+ 미뤄진 버그 수정 비용
+ 기술 부채 증가 비용

좋은 기획자는 아이디어를 많이 추가하는 사람이 아니다.

무엇을 만들지 결정하는 동시에 무엇을 만들지 않을지를 결정하는 사람이다.

1.4 네 번째 착각: 기술 부채는 개발팀의 몫이다#

기술 부채라는 말을 들으면 흔히 복잡한 코드나 오래된 라이브러리를 떠올린다.

그래서 기술 부채를 개발자만의 문제라고 생각하기 쉽다.

하지만 기술 부채가 만들어지는 출발점에는 기획과 비즈니스 의사결정이 있는 경우도 많다.

"일단 이번 달에 오픈합시다."

"리팩터링은 다음에 하죠."

"테스트는 나중에 보강하면 안 될까요?"

"지금은 매출이 중요하니까 기능부터 넣읍시다."

각각의 결정에는 나름의 이유가 있다.

문제는 다음에 갚겠다고 결정한 비용이 실제로 관리되지 않을 때 발생한다.

기술 부채는 대출과 비슷하다#

일정을 맞추기 위해 단순한 구현을 선택하는 것 자체가 항상 나쁜 것은 아니다.

사업적으로 필요한 결정일 수도 있다.

문제는 부채의 존재를 기록하지 않는 것이다.

오늘 3일을 아끼기 위해 임시 구현을 선택했다면 다음과 같은 정보를 남겨야 한다.

무엇을 포기했는가
어떤 문제가 발생할 수 있는가
언제 다시 개선할 것인가
개선에 어느 정도의 비용이 예상되는가
개선하지 않았을 때 어떤 위험이 있는가

이것이 없다면 임시방편은 사실상 영구적인 구조가 된다.

Atlassian 역시 기술 부채를 빠른 해결책이나 품질보다 속도를 우선한 선택으로 인해 미래에 발생하는 비용으로 설명하며, 테스트 생략, 커뮤니케이션 문제, 급한 일정 등이 기술 부채를 쌓는 원인이 될 수 있다고 설명한다.

가격표: 오늘 아낀 하루는 정말 하루인가#

기술 부채의 비용을 무조건 몇 배라고 단정할 수는 없다.

프로젝트의 구조와 규모에 따라 크게 달라지기 때문이다.

대신 다음처럼 관리하는 것이 현실적이다.

기술 부채 비용
=
현재 절약한 개발 시간
대비
향후 반복적으로 증가하는 변경·테스트·장애 대응 시간

그리고 기술 부채가 발견되면 기능과 별개의 보이지 않는 업무로 숨겨놓지 말고 일반 업무와 함께 우선순위를 관리해야 한다.

실제로 최근의 소프트웨어 전달 성과 측정에서도 단순히 얼마나 자주 배포했는가만 보는 것이 아니라 변경으로 인한 실패와 예상하지 않았던 재작업까지 함께 살펴보는 방향이 강조되고 있다.

1.5 다섯 번째 착각: 기획은 언제든 바꿀 수 있다#

소프트웨어의 장점 중 하나는 변경할 수 있다는 것이다.

건물을 완성한 뒤 방 하나를 옮기는 것보다 프로그램의 버튼 위치를 변경하는 편이 쉬워 보인다.

여기에서 위험한 착각이 시작된다.

소프트웨어는 변경할 수 있지만 모든 변경이 싸다는 뜻은 아니다.

같은 한 줄의 변경도 시점에 따라 영향 범위가 다르다#

개발 시작 전에 문구를 바꾸는 것은 문서를 수정하면 끝날 수 있다.

하지만 개발이 진행된 이후 요구사항을 변경하면 이야기가 달라진다.

기획서를 수정한다.

화면 설계를 수정한다.

API를 수정한다.

데이터 모델을 수정한다.

코드를 다시 작성한다.

테스트 케이스를 수정한다.

이미 작성된 테스트를 다시 실행한다.

다른 기능에 영향이 없는지 확인한다.

배포 계획을 다시 검토한다.

변경 자체보다 변경으로 인해 다시 검증해야 하는 범위가 비용을 키우는 것이다.

"개발 중이니까 바꾸면 되잖아요"의 함정#

개발자는 코드를 변경할 수 있다.

하지만 이미 구현된 코드와 연결된 요소가 많을수록 변경 영향도는 커진다.

그래서 단순히 몇 줄을 수정하는 시간만 보고 변경 비용을 판단해서는 안 된다.

가격표: 변경 비용을 계산하는 현실적인 방법#

흔히 설계 단계보다 개발 단계, 출시 후 변경이 몇 배 또는 수십 배 비싸다는 식의 숫자가 인용된다.

하지만 모든 프로젝트에 동일하게 적용되는 고정된 배율은 없다.

ThinkX에서는 다음 방식으로 보는 것을 권한다.

변경 비용
=
기획 수정
+ 설계 수정
+ 기존 구현 폐기
+ 재개발
+ 회귀 테스트
+ 데이터 이전
+ 배포
+ 사용자 대응
+ 일정 지연

핵심은 숫자 몇 배가 아니다.

이미 연결된 시스템과 사람이 많아질수록 변경 범위가 커진다는 사실이다.

좋은 기획은 변경을 없애는 것이 아니라 비싼 변경을 늦게 발견하지 않는 것이다.

그래서 개발 전 프로토타입, 사용자 흐름 검증, 기술 검토가 중요하다.

1.6 여섯 번째 착각: 나의 감은 데이터보다 정확하다#

경험이 많은 기획자에게 감은 중요하다.

문제는 감을 검증하지 않는 순간이다.

"사용자들이 분명 좋아할 겁니다."

"이 정도 기능은 당연히 필요합니다."

"경쟁사에도 있으니까 우리도 있어야 합니다."

가장 위험한 것은 이런 판단이 틀렸을 때가 아니다.

틀렸는지조차 확인하지 않는 것이다.

경쟁사 기능이 있다는 것은 근거가 아니다#

경쟁사에 어떤 기능이 있다는 사실만으로 그 기능이 성공했다고 판단할 수 없다.

사용률을 알 수 없다.

개발비를 알 수 없다.

운영 비용도 알 수 없다.

회사가 없애고 싶지만 호환성 때문에 유지하고 있는 기능일 수도 있다.

경쟁사의 화면을 캡처해서 기획서에 붙이는 것은 쉽다.

하지만 그것은 사용자 요구를 증명하는 데이터가 아니다.

가격표: 검증하지 않은 확신#

검증 없이 기능을 개발하면 실패했을 때 기능 개발비 대부분을 이미 지출한 상태가 된다.

반대로 개발 전에 간단한 프로토타입이나 사용자 인터뷰, 로그 분석, 소규모 실험을 진행하면 비교적 작은 비용으로 가설을 확인할 수 있다.

실험 가치
=
본 개발 실패 시 손실 가능한 비용
-
실험에 필요한 비용

모든 기능에 A/B 테스트가 필요한 것은 아니다.

트래픽이 부족할 수도 있고 안전이나 규정 문제 때문에 실험이 적합하지 않은 경우도 있다.

하지만 최소한 다음 질문에는 답할 수 있어야 한다.

이 기능이 해결하는 사용자 문제는 무엇인가
어떤 행동이 개선되기를 기대하는가
성공 여부를 무엇으로 판단할 것인가
출시 후 어떤 데이터를 확인할 것인가
기대한 결과가 나오지 않으면 어떻게 할 것인가

데이터는 기획자의 감을 없애기 위한 것이 아니다.

좋은 감과 나쁜 감을 구분하기 위한 도구다.

1.7 일곱 번째 착각: 버그는 사소한 문제다#

기능 개발은 눈에 보인다.

새로운 화면이 만들어지고 새로운 기능이 추가된다.

반대로 버그 수정은 성과가 잘 보이지 않는다.

정상적으로 동작하도록 되돌리는 일이기 때문이다.

그래서 일정이 촉박해지면 종종 버그 수정이 뒤로 밀린다.

하지만 사용자 입장에서는 다르다.

버그는 개발팀의 목록에 적힌 하나의 티켓이 아니다.

서비스가 약속한 경험이 깨진 순간이다.

같은 버그라도 가격은 다르다#

텍스트가 한 픽셀 어긋나는 문제와 결제가 두 번 이루어지는 문제를 같은 버그로 취급해서는 안 된다.

버그의 비용은 다음 요소로 판단할 수 있다.

발생 빈도
영향을 받는 사용자 수
매출 영향
데이터 손상 가능성
보안 위험
고객 문의 증가
사용자 이탈 가능성
복구 난이도
브랜드 신뢰 영향

가격표: 버그 하나의 실제 비용#

버그 비용을 다음과 같이 생각해볼 수 있다.

버그 비용
=
장애 대응 비용
+ 개발 수정 비용
+ 재테스트 비용
+ 고객 지원 비용
+ 환불 및 보상 비용
+ 매출 손실
+ 사용자 이탈 비용
+ 신뢰 회복 비용

특히 운영 환경에서 발생한 문제 때문에 예정에 없던 수정 배포가 계속 늘어난다면 단순한 버그 숫자보다 더 중요한 신호일 수 있다.

DORA 역시 최근 소프트웨어 전달 안정성을 살펴볼 때 운영 장애를 일으킨 변경의 비율뿐 아니라, 사용자에게 영향을 주는 버그 때문에 계획에 없던 배포를 얼마나 수행했는지를 나타내는 배포 재작업률을 함께 활용하고 있다.

즉 좋은 개발 조직은 버그가 몇 개인지만 세지 않는다.

버그 때문에 얼마나 많은 계획된 일이 중단되고 있는가도 본다.

1.8 아이디어에는 반드시 가격표가 붙는다#

우리는 아이디어가 세상을 바꾼다고 배웠다.

절반은 맞다.

아이디어는 변화의 시작점이다.

하지만 아이디어 자체가 제품을 만들지는 않는다.

아이디어를 구현하려면 사람이 필요하다.

서버가 필요하다.

시간이 필요하다.

테스트가 필요하다.

운영이 필요하다.

그리고 무엇보다 다른 아이디어를 포기해야 한다.

그래서 개발기획에서 가장 위험한 문장은 이것일지도 모른다.

"좋은 아이디어니까 해봅시다."

좋다는 것만으로는 부족하다.

얼마나 좋은가.

누구에게 좋은가.

무엇을 개선하는가.

얼마를 써야 하는가.

그 돈과 시간으로 다른 것을 했을 때보다 가치가 높은가.

이 질문에 답할 수 있어야 비로소 아이디어가 프로젝트가 된다.

1.9 기획서는 설계도가 아니라 청구서다#

기획자는 흔히 기획서를 화면과 기능을 설명하는 문서라고 생각한다.

하지만 개발팀의 입장에서 보면 조금 다르다.

기획서에 적힌 요구사항은 결국 누군가의 시간을 사용한다.

버튼 하나를 추가한다.

개발 시간이 발생한다.

새로운 데이터를 저장한다.

데이터베이스와 API가 변경된다.

알림 기능을 추가한다.

외부 서비스 비용과 장애 대응 영역이 늘어난다.

관리자 기능을 추가한다.

권한 관리와 운영 업무가 발생한다.

따라서 기획서는 단순한 아이디어 문서가 아니다.

개발팀의 리소스를 사용하는 청구서이며 회사의 미래 운영비를 결정하는 문서다.

기획자가 추가한 요구사항에는 항상 가격표가 붙어 있다.

단지 기획서에 그 숫자가 보이지 않을 뿐이다.

1.10 몽상가에서 가치 평가자로#

초보 기획자는 묻는다.

"무엇을 더 넣을까요?"

숙련된 기획자는 묻는다.

"무엇을 빼야 할까요?"

더 나은 기획자는 한 단계 더 나아간다.

"이 기능에 투입되는 비용보다 더 큰 가치를 만들 수 있는가?"

여기서 기획자의 역할이 달라진다.

아이디어를 생산하는 사람이 아니라 한정된 자원을 어디에 사용할지 결정하는 사람이 된다.

이를 위해서는 기능 하나를 볼 때 최소한 다섯 가지를 함께 봐야 한다.

사용자 가치#

누구의 어떤 문제를 해결하는가.

비즈니스 가치#

매출, 비용 절감, 유지율, 전환율 등 어떤 결과에 연결되는가.

개발 비용#

얼마나 많은 설계와 구현이 필요한가.

운영 비용#

출시 이후 무엇을 계속 관리해야 하는가.

기회비용#

이것을 선택함으로써 무엇을 포기하는가.

좋은 기획은 아이디어의 숫자로 평가되지 않는다.

제한된 비용으로 얼마나 큰 가치를 만들었는가로 평가된다.

1.11 모든 요구사항에 가격표를 붙여라#

앞으로 기획서에 새로운 기능을 추가하기 전에 다음 질문을 던져보자.

이 기능은 어떤 문제를 해결하는가?
실제로 이 문제를 겪는 사용자가 있는가?
성공 여부를 무엇으로 판단할 것인가?
기존 시스템에서 얼마나 많은 영역이 변경되는가?
개발뿐 아니라 테스트와 운영 비용은 얼마나 되는가?
이 기능 때문에 미뤄지는 업무는 무엇인가?
기능을 제거하거나 더 단순하게 만들 수는 없는가?
지금 반드시 만들어야 하는가?
더 저렴하게 가설을 검증할 방법은 없는가?
출시 후 유지할 가치가 없다면 제거할 수 있는가?

이 질문에 제대로 답하지 못한다면 개발을 시작하기 전에 다시 생각할 필요가 있다.

기획에서 가장 비싼 실수는 나쁜 아이디어를 떠올리는 것이 아니다.

검증되지 않은 아이디어를 너무 빨리 개발하는 것이다.

1.12 마치며: 당신의 기획에는 얼마의 가격표가 붙어 있는가#

개발 프로젝트에는 공짜가 없다.

모호한 문장에도 가격이 있다.

급하게 결정한 일정에도 가격이 있다.

버튼 하나에도 가격이 있다.

사용하지 않는 기능에도 가격이 있다.

나중에 고치겠다는 약속에도 가격이 있다.

그리고 그 비용은 대부분 기획서를 작성하는 순간에는 보이지 않는다.

시간이 지나고 나서야 나타난다.

재작업으로 나타난다.

야근으로 나타난다.

장애로 나타난다.

유지보수 비용으로 나타난다.

놓쳐버린 다른 기회로 나타난다.

그래서 개발기획자가 가져야 할 가장 중요한 능력은 화려한 아이디어를 만들어내는 능력이 아니다.

보이지 않는 비용을 미리 보는 능력이다.

"이 기능을 넣으면 좋겠다"에서 멈추지 말자.

한 걸음 더 나아가자.

"이 기능은 얼마짜리인가?"

그리고 마지막으로 하나를 더 묻자.

"그 가격을 지불할 만큼 가치가 있는가?"

그 질문을 하기 시작하는 순간 기획서는 단순한 기능 목록에서 벗어난다.

아이디어는 투자안이 되고, 요구사항은 의사결정이 되며, 기획자는 아이디어를 전달하는 사람에서 제품의 가치를 평가하는 사람으로 바뀐다.

당신이 작성한 기획서에는 이미 가격표가 붙어 있다.

이제 해야 할 일은 그 가격을 보지 못한 척하지 않는 것이다.

개발기획자를 수렁에 빠뜨리는 7가지 착각