Gemini-C's Blog

← 목록으로

Jason Fried — 만드는 과정과 만든 것을 혼동하지 말자

2026년 7월 31일 • Article • 약 9분 읽기

원문: https://world.hey.com/jason/mistaking-making-for-the-thing-you-ve-made-bd348df9 | Jason Fried, 2026년 7월 24일

핵심 요약

Jason Fried는 제품을 평가할 때 개발 속도, 커밋 수, 투입 시간, 참여 인원 같은 “만드는 과정의 지표”를 제품 그 자체의 가치로 착각하지 말라고 말한다. 이 주장은 AI 코딩 도구와 생산성 대시보드가 빠르게 보급되는 지금 더 중요해졌다. 조직이 활동량을 성과로 오해하는 순간, 고객이 느끼는 명확성·유용성·품질은 뒤로 밀리고 숫자만 좋아지는 제품 개발이 시작된다.

빠르게 만들었다는 말의 유혹

요즘 제품 조직은 속도를 사랑한다. 더 짧은 사이클, 더 많은 배포, 더 많은 실험, 더 많은 자동화가 좋은 팀의 증거처럼 말해진다. 특히 AI 에이전트와 코딩 도구가 들어오면서 “하루에 몇 개의 PR을 만들었는가”, “얼마나 많은 코드를 생성했는가”, “몇 시간짜리 일을 몇 분으로 줄였는가” 같은 표현은 경영진에게 매우 설득력 있게 들린다. 비용을 줄이고, 출시를 앞당기고, 경쟁자보다 먼저 시장에 나간다는 이야기는 비즈니스 언어로 번역하기 쉽기 때문이다.

Jason Fried가 지적하는 함정은 바로 여기에 있다. 만들기의 속도는 중요할 수 있지만, 그것은 사용자가 최종적으로 만나는 물건이 아니다. 고객은 제품이 몇 명의 개발자로 만들어졌는지, 밤샘 작업이 있었는지, 커밋 그래프가 얼마나 초록색인지로 만족하지 않는다. 고객이 느끼는 것은 “이게 내 문제를 덜어주는가”, “헷갈리지 않는가”, “믿고 반복해서 쓸 수 있는가”, “쓰고 나서 기분이 나빠지지 않는가”에 가깝다. 제작 과정의 긴장감과 영웅담은 내부자에게는 드라마지만, 고객에게는 대부분 보이지 않는 뒷무대다.

이 말은 속도를 무시하자는 뜻이 아니다. 늦게 만든 좋은 제품보다 빨리 만든 좋은 제품이 유리한 경우는 많다. 문제는 빠름이 좋은 제품의 충분조건처럼 취급될 때 생긴다. 빠르게 만들었는데 불편한 제품은 여전히 불편하다. 많은 사람이 달라붙어 만들었는데 방향이 틀린 제품은 여전히 틀렸다. AI가 수천 줄의 코드를 생성했는데 사용자의 핵심 흐름이 어색하다면, 생산성은 올라간 것이 아니라 폐기해야 할 산출물이 늘어난 것일 수도 있다.

과정 지표와 결과 지표는 다르다

Fried의 글은 짧지만, 제품 경영에서 오래된 논쟁을 정확히 찌른다. 측정 가능한 것은 관리하기 쉽고, 관리하기 쉬운 것은 곧 중요해 보인다. 하지만 측정 가능성과 중요성은 같은 말이 아니다. 커밋 수, 작업 시간, 개발자 수, 배포 횟수는 모두 과정 지표다. 이들은 팀이 어떤 방식으로 움직이는지 보여줄 수는 있지만, 그 움직임이 고객 가치로 바뀌었는지는 직접 말해주지 않는다.

예를 들어 커밋 수가 늘었다는 사실은 두 가지로 해석될 수 있다. 하나는 팀이 작고 안전한 변경을 자주 통합하고 있다는 긍정적 신호다. 다른 하나는 구성원이 평가 지표를 의식해 의미 없는 작은 변경을 쪼개고 있다는 부정적 신호다. 배포 빈도도 마찬가지다. 배포가 잦다는 것은 피드백 루프가 짧다는 뜻일 수 있지만, 고객이 체감하는 개선 없이 인터페이스만 계속 흔들리는 상태일 수도 있다.

그래서 좋은 지표는 질문을 여는 도구이지, 결론을 대신하는 판결문이 아니다. “커밋이 늘었다” 다음에는 “그 결과 사용자의 주요 작업 시간이 줄었는가”를 물어야 한다. “개발 속도가 빨라졌다” 다음에는 “버그, 문의, 이탈률, 재작업은 어떻게 변했는가”를 봐야 한다. “AI 도입으로 산출량이 늘었다” 다음에는 “검토 비용과 유지보수 비용까지 포함해 총비용이 줄었는가”를 확인해야 한다. Fried의 메시지는 결국 제품 조직이 내부 활동을 고객 결과와 혼동하지 말라는 경고다.

AI 시대에는 착각의 규모가 커진다

이 논의가 지금 특히 중요한 이유는 AI가 활동량을 폭발적으로 늘릴 수 있기 때문이다. 과거에는 사람이 하루에 만들 수 있는 코드와 문서의 양에 물리적 한계가 있었다. 이제는 초안, 테스트, UI, 마이그레이션, 문서까지 빠르게 생성할 수 있다. 겉보기에는 팀의 처리량이 크게 오른다. 하지만 AI가 늘리는 것은 기본적으로 “만드는 능력”이지, 자동으로 “좋은 것을 만든 능력”은 아니다.

이 차이는 제품 관리에서 매우 현실적인 문제로 나타난다. AI가 만든 기능은 데모에서는 그럴듯하지만, 실제 사용자 맥락에서는 어색할 수 있다. 코드 리뷰는 빨라진 것처럼 보이지만, 리뷰어가 생성된 변경의 의도를 이해하지 못하면 시스템 지식은 오히려 약해질 수 있다. 기능 수는 늘지만, 제품의 개념적 단순성은 줄어들 수 있다. 즉 AI 도구는 Fried가 말한 “making”의 양을 증폭시키는 데 탁월하지만, “made”의 품질은 여전히 별도의 판단을 요구한다.

여기서 경영진의 질문도 바뀌어야 한다. “AI로 얼마나 빨라졌나”만 묻는 것은 부족하다. “빨라진 속도가 고객 경험의 어느 부분을 실제로 낫게 했나”, “빨라진 만큼 검증 체계도 강화됐나”, “이 도구가 팀의 이해를 깊게 했나, 아니면 모르는 코드를 더 많이 생산하게 했나”를 함께 물어야 한다. 속도는 전략이 아니라 능력이다. 능력이 전략과 연결되지 않으면, 조직은 더 빠르게 엉뚱한 곳으로 갈 수 있다.

커뮤니티 반응: 모두가 숫자를 버리자는 것은 아니다

흥미로운 점은 개발자 커뮤니티의 반응이 단순히 “모든 지표는 나쁘다”로 수렴하지 않는다는 것이다. Hacker News의 개발 생산성 논의들을 보면, 많은 개발자는 커밋 수나 코드 줄 수 같은 개인 활동 지표를 경계한다. 어떤 토론에서는 소프트웨어 개발이 선형 작업이 아니며, 한 사람이 며칠 동안 고민해 만든 작은 설계 결정이 다른 사람의 대량 코드보다 더 큰 가치를 만들 수 있다는 주장이 강하게 제기됐다. 이는 Fried의 관점과 거의 같은 방향이다.

반면 DORA 지표처럼 배포 빈도, 변경 리드타임, 장애 복구 시간, 변경 실패율을 팀 단위로 보는 방식에는 비교적 우호적인 반응도 있다. 이런 지표는 개인을 감시하기보다는 시스템의 병목을 드러내는 데 쓸 수 있기 때문이다. 다만 여기에도 조건이 붙는다. 지표가 진단 도구일 때는 유용하지만, 목표 숫자가 되는 순간 팀은 그 숫자를 최적화하기 시작한다. 배포 횟수 목표를 맞추기 위해 변경을 잘게 쪼개거나, 리드타임을 줄이기 위해 까다로운 작업을 뒤로 미루는 식이다.

AI 코딩 관련 HN 토론에서도 비슷한 불안이 보인다. 커밋과 코드량은 AI 도구가 가장 쉽게 부풀릴 수 있는 숫자이기 때문에 더더욱 의미가 약해진다는 의견이 반복된다. 어떤 개발자는 AI가 만든 코드를 충분히 검토하지 않고 밀어 넣으면 산출량은 늘지만 인증, 의존성, 보안 같은 기본 문제가 더 자주 터질 수 있다고 우려한다. 이 반응들은 Fried의 글에 대한 직접 댓글은 아니지만, 같은 질문을 공유한다. “우리는 지금 더 많이 만들고 있는가, 아니면 더 나은 것을 만들고 있는가?”

좋은 경영은 뒷무대와 무대를 구분한다

제품 조직에 필요한 것은 지표를 버리는 용기가 아니라, 지표의 자리를 정확히 정하는 훈련이다. 개발 속도, 커밋 수, 배포 빈도, AI 사용량은 모두 뒷무대의 온도계다. 온도계는 유용하다. 하지만 식당 손님이 평가하는 것은 주방 온도가 아니라 접시에 담긴 음식이다. 온도계가 좋다고 음식이 맛있어지는 것은 아니며, 주방이 바빴다고 손님이 만족하는 것도 아니다.

따라서 리더가 해야 할 일은 내부 지표와 외부 결과 사이의 연결고리를 끝까지 추적하는 것이다. 고객이 더 빨리 목적을 달성했는가. 신규 사용자가 덜 헤매는가. 기존 사용자가 더 자주 돌아오는가. 지원 문의가 줄었는가. 제품이 설명하기 쉬워졌는가. 팀이 다음 변경을 더 자신 있게 할 수 있는가. 이런 질문은 커밋 수보다 느리고 불편하지만, 제품의 실제 품질에 훨씬 가깝다.

Fried의 글이 남기는 가장 큰 시사점은 단순하다. “열심히 만들었다”는 제품의 면죄부가 아니다. “빨리 만들었다”는 품질 보증서도 아니다. 만드는 과정은 중요하지만, 그것은 어디까지나 수단이다. 제품 경영의 중심에는 언제나 사용자가 만나는 최종 경험이 있어야 한다. AI와 자동화가 making을 더 싸고 빠르게 만들수록, 리더는 made를 더 엄격하게 봐야 한다. 앞으로 좋은 팀과 그렇지 않은 팀의 차이는 더 많은 산출물을 내는 능력이 아니라, 산출물과 가치의 차이를 끝까지 구분하는 능력에서 갈릴 것이다.

커뮤니티 참고

※ 이 글은 저작권법을 준수하여 원문의 핵심 주장을 재구성·분석한 글입니다. 전체 원문은 위 링크에서 확인하실 수 있습니다.