기능 공장: 출시량이 아니라 결과를 보는 팀

기능 공장이란

기능 공장(Feature Factory)은 기능을 만들어 내보내는 일 자체를 성과로 보는 팀이다. 공장처럼 컨베이어 벨트에 기능을 올리고, 출시하면 끝난다. 그 기능이 고객의 문제를 풀었는지, 사업 지표를 움직였는지는 아무도 확인하지 않는다.

문제는 출력(output)과 결과(outcome)를 혼동하는 데 있다.

기준	출력 중심 (기능 공장)	결과 중심
성공의 정의	기능을 출시했다	고객 행동·지표가 바뀌었다
로드맵	만들 기능 목록	풀 문제와 검증할 가설 목록
출시 이후	바로 다음 기능	데이터로 효과를 확인하고 조정
실패	숨기거나 넘어간다	학습 재료로 공유한다
개발자의 역할	스펙대로 구현	문제를 이해하고 해법을 함께 고른다

12가지 신호

영역	신호	무엇이 빠졌나
측정	1. 내가 한 일이 효과가 있었는지 모른다. 측정해도 일부만 본다	성과 지표와 공유
측정	5. 일이 사업·고객 만족 지표와 연결되지 않는다	핵심 지표와의 연결
측정	8. 출시 후 데이터로 돌아보지 않고 바로 다음 과제로 간다	사후 점검
학습	3. 효과 검토 없이 출시 자체를 축하한다	결과에 대한 축하
학습	4. 실패를 인정하지 않고, 데이터와 교훈을 쓰지 않는다	실패에서 배우기
학습	6. 과거 결정이 옳았는지, 목표 대비 어디쯤인지 점검하지 않는다	제품 회고
계획	7. 우선순위 매기기에 매달리고, 로드맵이 기능 목록이다	가설 검증과 조정의 여지
계획	2. 팀과 프로젝트가 자주 바뀌고, 한 사람이 여러 일을 동시에 진다	안정된 팀과 집중
흐름	9. 개발이 끝나면 손을 뗀다. 운영·고객·영업과 대화가 없다	피드백 순환
흐름	10. 실험 없이 큰 묶음으로 배포해 고객이 변화를 체감하지 못한다	작은 배치와 실험
가치	11. 계약을 따내려고 기능을 붙이지만 효과는 작고 복잡도만 는다	기능의 경제성 판단
가치	12. 새 기능만 주목받고 리팩터링·부채 해소는 보이지 않는다	제품 전체의 건강

벗어나는 법

1. 출시 전에 성공 기준을 정한다. 어떤 지표가 얼마나 움직이면 성공인지 먼저 적는다. 그래야 출시 뒤 돌아볼 기준이 생긴다.
2. 로드맵을 문제와 가설로 쓴다. 「검색 필터 추가」 대신 「원하는 상품을 찾지 못해 이탈하는 사용자를 줄인다」처럼 쓴다. 해법은 바뀔 수 있다.
3. 출시 뒤 정기 점검을 일정에 넣는다. 정해 둔 기간이 지나면 지표를 보고 유지·개선·제거를 결정한다. 효과 없는 기능을 지우는 것도 성과다.
4. 작게 자주 내보낸다. 실험 단위로 쪼개 배포하면 무엇이 효과였는지 가려낼 수 있다.
5. 개발자도 고객·운영 신호를 본다. 지원 문의, 사용 로그, 영업 피드백을 팀이 함께 읽는다.
6. 보이지 않는 일을 보이게 한다. 기술 부채 해소, 성능 개선도 지표(배포 시간, 장애 수)로 드러내 우선순위 경쟁에 올린다.

AI·챗봇 기능도 같은 잣대로

새로 붙인 AI·챗봇 기능은 "AI라서 좋다"는 인상만으로 가치를 인정받기 쉽다. 클릭률이나 대화량 같은 표면 지표가 높으면 효용이 증명됐다고 넘어가기도 한다. 이것이 출력을 결과로 착각하는 전형이다. AI 기능도 일반 기능과 똑같은 절차로 검증한다.

1. 가설을 세운다. 예: "체크리스트를 자연어로 만들게 하면 작성의 인지 부하가 준다."
2. 사용자 흐름의 각 단계를 지표로 정의해 수집한다. 진입 → 입력 → 완료 → 재사용처럼 단계마다 무엇이 얼마나 일어나는지 본다. 대화량 하나로 뭉뚱그리지 않는다.
3. 실제 사용자에게서 직접 피드백을 받아 가설을 검증하고 보완한다.

판단 기준은 "AI를 썼다"가 아니라 측정 가능한 사용자 가치가 실제로 움직였는가다.

정리

• 기능 공장은 출력을 결과로 착각한 팀이다.
• 측정·회고·사후 점검이 없으면 무엇이 효과였는지 배울 수 없다.
• 로드맵은 기능 목록이 아니라 풀 문제와 검증할 가설이어야 한다.
• 새 기능만큼 기술 부채 해소와 기능 제거도 성과로 다룬다.

팀의 속도는 내보낸 기능 수가 아니라 고객에 대해 배운 속도로 잰다.

관련 노트: 제품 중심 개발자, 기술 부채, 칸반과 린, 사용자 리서치