코드 작성 속도가 문제라고 생각했다면, 더 큰 문제가 있는 것이다

(andrewmurphy.io)

9P by GN⁺ 13시간전 | ★ favorite | 댓글 2개

AI 코딩 도구가 개발 속도를 높인다고 하지만, 실제 병목은 코드 작성이 아닌 조직의 비효율적 프로세스에 있음
코드 생산량을 늘리면 리뷰 대기, 배포 지연, 불명확한 요구사항 등 비개발 단계의 정체가 심화되고, 실제 사이클 타임은 오히려 증가
Eli Goldratt의 제약 이론(Theory of Constraints) 에 따르면, 병목이 아닌 단계를 최적화하면 시스템이 빨라지는 것이 아니라 더 망가짐
AI가 생성한 코드를 작성자조차 완전히 이해하지 못하는 상황에서, 장애 대응 표면적은 넓어지고 시스템을 추론할 수 있는 인력은 줄어드는 구조적 위험 발생
경쟁 우위는 코드를 가장 빨리 쓰는 팀이 아니라, 무엇을 만들어야 하는지 파악하고 사용자 손에 전달하는 팀에 돌아감

잘못된 최적화의 시작

AI 코딩 어시스턴트 도입으로 코드 출력량이 40% 증가했다는 발표가 등장
- 그러나 “무엇을 향한 속도인지”에 대한 질문이 빠져 있음
이미 빠른 단계(코드 작성)에 자원을 투입하면 시스템 전체는 더 느려짐
- 병목이 아닌 부분을 가속하면 미완성 코드 재고가 쌓이고, 품질 저하와 혼란이 발생

병목이 아닌 곳을 최적화하면 시스템이 더 망가짐

1984년 Eli Goldratt가 쓴 소설 The Goal에서 제시한 제약 이론(Theory of Constraints) 의 핵심: 모든 시스템에는 정확히 하나의 병목이 존재하며, 전체 처리량은 그 병목의 처리량으로 결정됨
병목이 아닌 단계를 최적화하면 시스템이 빨라지지 않고, 미완성 작업의 재고만 쌓여 리드 타임 증가, 혼란, 품질 저하로 이어짐
비유적으로, A 스테이션이 위젯을 더 빨리 만들어도 병목인 B 스테이션 처리 속도가 그대로면 A와 B 사이에 미처리 위젯 더미만 쌓이는 것과 동일

"코드 산출량 3배"가 실제로 초래하는 상황

개발자들이 PR을 그 어느 때보다 빠르게 생산하지만, 리뷰어 수는 그대로이므로 PR이 리뷰 큐에 하루, 이틀, 일주일씩 대기
작성자는 이미 다음 AI 지원 기능으로 컨텍스트 스위칭한 상태라, 8일 전에 작성한 코드의 리뷰 코멘트에 대응할 때 해당 코드를 거의 기억하지 못함
리뷰가 너무 많아져서 제대로 읽지 않고 승인하는 러버스탬프 리뷰가 발생
CI가 45분 걸리고 flaky 테스트로 실패 후 재실행, 배포 파이프라인은 회의 중인 담당자의 수동 승인 대기, 기능이 스테이징에서 3일간 방치
개발자는 이미 2개 더 PR을 올린 상태로, WIP(Work In Progress) 가 급증하고 모두가 6개를 동시에 진행하면서 아무것도 완료되지 않음
코드는 더 많이 생산하면서 소프트웨어는 덜 출시하는 상황, 사이클 타임은 악화되었지만 대시보드는 생산성 40% 향상으로 표시
AI 생성 코드의 추가 위험: "작성한" 사람이 실제로 작성한 것이 아니라 프롬프트로 생성 후 대충 훑어본 수준이므로, 새벽 2시 프로덕션 장애 시 온콜 담당자도 프롬프트 작성자도 해당 코드를 설명할 수 없음
코드는 늘어나고 이해는 줄어드는 상황은 생산성 향상이 아니라 더 예쁜 대시보드가 달린 시한폭탄

실제 병목 1: 무엇을 만들어야 하는지 모름

PM이 실제 사용자와 2개월간 대화하지 않은 상태에서, 요구사항이 Jira 티켓 3줄과 Figma 링크로 도착
엔지니어들이 하루에 50가지 마이크로 결정(동작, 엣지 케이스, 에러 처리)을 아무 명세 없이 추측으로 수행
한 팀이 영업 담당자가 Slack에서 전달한, 잠재 고객이 통화에서 아마 말했을 내용을 기반으로 6주간 기능을 개발했으나, 해당 잠재 고객은 구매하지 않았고 그 기능은 11명만 사용(그중 9명은 내부 QA)
코드 작성을 빠르게 하면 잘못된 것을 빠르게 만드는 속도만 증가, 추측을 자동화하는 것에 불과
병목은 문제에 대한 이해 자체이며, 더 빠른 타이핑으로는 해결 불가

실제 병목 2: 코드가 "완료"된 이후의 모든 것

대부분의 조직에서 코드 작성은 전체 여정의 약 20% 에 불과하고, 나머지 80%는 코드가 다양한 큐에서 대기하는 시간
코드 작성에 오후 하나가 걸린 기능이 프로덕션 도달까지 2개월 걸린 사례 존재
PR 리뷰, CI, 스테이징, QA, 보안 리뷰, 제품 승인, 배포 윈도우, 카나리 롤아웃 등 긴 핸드오프, 대기, 큐의 연쇄
대부분의 시간 동안 코드는 움직이지 않고, 누군가가 봐주기를, 파이프라인이 돌기를, 존재 허락을 받기를 기다리는 상태
더 빠르게 출시하려면 작업이 대기하는 지점을 찾아야 하며, 실제 작업 시간 대비 큐 대기 시간의 비율을 측정해야 함

실제 병목 3: 배포 신뢰의 악순환

테스트가 flaky하고 관측성이 엉망이며 카나리 프로세스를 아무도 신뢰하지 않는 상태에서, 팀들이 배포를 두려워함
두려움 때문에 변경사항을 더 큰 릴리스로 묶고, 이는 더 높은 리스크를 만들어 배포를 더 무섭게 만들고, 다시 더 크게 묶는 두려움의 악순환 형성
여기에 더 빠른 코드 산출을 더하면: 코드는 늘고 배포 문화는 그대로 두려운 상태이므로 배치는 더 커지고 릴리스 빈도는 더 낮아짐

실제 병목 4: 출시 후 피드백 부재

기능을 만들고 출시한 뒤, 제대로 된 분석도 없고 출시 후 사용자 인터뷰도 없고, 해당 기능이 문제를 실제로 해결했는지 확인하는 사람이 없음
다음 기능도 추측, 그다음도 추측, 제품 로드맵 전체가 피드백 없는 추측의 연속
더 빠른 코드 산출은 "만들고, 출시하고, 어깨 으쓱" 사이클을 더 빠르게 돌리는 것에 불과

실제 병목 5: 캘린더가 내력벽(load-bearing wall)

때로 병목은 기술적인 것이 아니라, 의사결정을 위한 회의, 한 달째 대화하지 않은 3개 팀 간의 API 계약 합의, 모든 중요 설계에 대한 단일 승인 지점인 아키텍트의 2주치 밀린 백로그
6주가 걸리는 분기별 계획 프로세스 때문에 긴급한 작업도 5주를 기다려야 시작 가능
기능이 출시되지 않은 이유가 "휴가 중인 사람과의 회의를 기다리고 있어서"인 상황도 실제로 존재
이것은 조정(coordination) 문제, 인간 문제, 정치적 문제이며, 코드 작성 속도와는 무관

대신 해야 할 것

밸류 스트림 매핑: 기능 하나를 아이디어부터 프로덕션까지 추적하고, 각 단계의 소요 시간과 단계 사이 대기 시간을 기록할 것
사이클 타임 측정: 코드 줄 수, 머지된 PR 수, 스토리 포인트가 아니라 커밋부터 프로덕션까지 사용자가 사용하기까지의 시간을 측정해야 함
대기 상태 제거: PR 리뷰에 2일 걸리면 페어 프로그래밍, 작은 PR, 전담 리뷰 시간, 비동기 리뷰 규범 등으로 해결. 배포가 수동 승인을 기다리면 자동화하거나 최소한 Slack 버튼으로 전환
시작을 멈추고 완료에 집중: WIP 제한이 존재하는 이유가 있으며, 진행 중인 10개보다 완료된 3개가 나음. 진행 중인 모든 항목은 컨텍스트 스위칭 비용
실무자와 대화: 개발자들은 이미 병목이 어디인지 알고 있으며, 스탠드업에서 불만을 말하고 Slack에서 몇 달째 밈을 만들고 있음. 아무도 듣고 있지 않다고 생각했을 뿐

핵심 결론

VP가 "코드 산출량 40% 증가"를 발표하는 대신, "밸류 스트림 분석 결과 기능이 단계 사이에 평균 9일 대기 중이며, 이를 절반으로 줄이겠다"고 말했어야 함
경쟁 우위는 코드를 가장 빨리 쓰는 팀이 아니라, 무엇을 만들지 파악하고 만들어서 사용자 손에 전달하는 팀에 돌아감
병목은 키보드가 아님

소프트웨어장인 마렵다

GN⁺ 13시간전 [-]

Hacker News 의견들

우리 팀이 에이전트 기반 개발을 본격적으로 도입했을 때, 코딩 속도는 빨라지지만 리뷰 시간이 늘어날까 걱정했음
아직은 뚜렷한 변화가 없고, 모두가 새로운 워크플로우를 익히는 중이라 데이터가 충분하지 않음
하지만 빠른 코딩이 특히 유용한 경우들이 있음 — 아이디어 실험, 복잡한 반복 작업, 단순하지만 노동집약적인 구현, 해피 패스 이후의 엣지 케이스 처리 등
특히 기존 브랜치나 PR을 그대로 확장하는 경우에 에이전트가 매우 잘 작동함
가장 큰 생산성 향상은 에이전트가 코딩하는 동안 내가 다른 일을 할 수 있다는 점임. 예를 들어 PR 리뷰를 하고 돌아오면 결과물이 나와 있음
처음엔 회의적이었지만 지금은 조심스럽게 기대 중임. 10배 향상은 무리겠지만 2배 향상만 돼도 대단한 일임
- 나도 그 단계를 거쳤지만 결국 포기했음. 에이전트가 코딩하는 동안 다른 일을 하는 건 컨텍스트 전환이 너무 많아 오히려 집중력과 생산성을 해침
  이 방식은 실수 비용이 낮거나 변경 범위가 작을 때만 쓸 만함. 그렇지 않으면 품질과 만족도가 떨어지고 일정만 압축됨
  결국 병렬로 시간을 되찾는 게 아니라, 미루던 일을 조금 덜 미루게 되는 정도임
- 다른 회사의 경험을 엿볼 수 있어 흥미로웠음. 나도 대부분 동의함
  다만 에이전트가 코딩하는 동안 다른 일을 하는 건 이상한 피로감을 줌
  AI는 생산적이지만, 인간 장인으로서의 코딩과는 전혀 다른 종류의 노동임
- 대규모 리팩터링을 AI가 대신 해주면 매몰비용에 덜 얽매이게 됨
  직접 했다면 포기하기 어려웠을 리팩터링도, AI가 한 경우엔 “이건 별로였다”고 솔직히 판단하기 쉬움
- 에이전트가 코딩하는 동안 다른 일을 하는 건 끔찍하게 들림
  계속 멀티태스킹하면 번아웃이 빠르게 옴. 인간적인 요소가 논의에서 빠져 있는 게 아쉬움
  나는 항상 ‘최적화된 상태’로 일하고 싶지 않음
누군가 “문제를 이해하는 게 병목”이라 했는데, 나는 왜 빠른 타이핑이 문제 이해를 돕지 못하냐고 묻고 싶음
잘못된 걸 빨리 만들어보면 오히려 올바른 방향을 더 빨리 찾을 수도 있지 않겠음?
나는 종종 뭔가를 만들어보면서 내가 진짜 원하는 걸 깨닫곤 함. 프로토타입 제작이 싸질수록 이 경향은 더 강해짐
물론, 결국 “사용자와 더 이야기해야 한다”는 회고로 끝나긴 하지만, 그건 또 다른 문제임
- 하지만 고객은 실패를 무한히 참아주지 않음. 특히 B2B나 SaaS 환경에서는 피드백 루프가 매우 느림
  은행 같은 곳은 잘해야 일주일에 한 번 정도만 실험 가능함
- AI는 이미 수없이 반복된 문제나, 대충 맞으면 되는 결과에는 강함
  하지만 대부분의 소프트웨어는 그렇지 않음. 코드를 쓰는 건 전체 일의 일부일 뿐임
  외과의가 단순히 ‘자르는 일’만 하는 게 아니듯, 엔지니어도 단순히 코드를 쓰는 게 전부가 아님
- “빠른 타이핑으로 문제를 빨리 이해할 수 있나?”라는 질문엔 이렇게 답하고 싶음 — “그럼 말을 빨리 하면 대화도 더 잘 이해되나?”
- 빠른 프로토타이핑이 유용할 때는 그 결과가 사용자나 요구사항과 직접 부딪힐 때임
  혼자서 코드만 다듬는다면, 그건 단지 더 큰 혼란을 만드는 것일 뿐임
  때로는 PM이나 고객과 한 시간 대화하는 게 훨씬 낫음
- “타이핑을 빨리 하면 문제를 빨리 이해할 수 있나?”에 대한 예시가 있다면 궁금함
지금의 LLM 열풍은 문제보다 솔루션이 먼저 나온 느낌임
진짜 속도를 높이려면 “무엇이 병목인가?”를 먼저 물어야 함
경영진이 AI 프레젠테이션을 보고 “이거 쓰면 빨라진다”라고 믿는 건 분위기 경영(vibe management) 에 불과함
- 하지만 내 30년 경험상, 개발은 단순히 코딩(#4 단계)이 아니라 비즈니스 이해, 설계, 테스트, 승인, 운영, 유지보수까지의 긴 과정임
  코딩은 그중 가장 노동집약적이고 자동화 가능한 부분임
  LLM은 이 부분을 상당히 덜어줄 수 있음. 특히 테스트 코드 작성 같은 건 AI가 잘함
인간 개발자는 여전히 코드에 대한 집착을 버리지 못하고 있음
사실 코드란 단지 해결책의 중간 표현(IR)에 불과함
GCC가 어셈블리로 변환할 때 내부 최적화를 신경 쓰지 않듯, 에이전트가 코드를 생성해도 우리는 결과의 정확성만 보면 됨
명확한 명세와 반복적인 검토 과정이 있다면, 인간이든 에이전트든 동일한 구현을 낼 수 있음
- 하지만 컴파일러는 결정론적으로 동작하고, 항상 같은 결과를 냄
  LLM은 그렇지 않음. 오해하거나 환각(hallucination) 을 일으킬 수 있음
  그래서 여전히 사람이 리뷰해야 함
- 고급 언어의 소스 코드는 형식 언어임. 자연어와는 다름
- 정말 그렇게 믿는다면, 차라리 직접 어셈블리로 변환하지 왜 중간 단계를 거치나?
- 실제로는 그렇게 단순하지 않음. 여러 번 리모델링된 집처럼, 코드베이스도 구조적 한계에 부딪힘
  에이전트가 잘못된 패턴을 선택하거나 기술 부채를 쌓는 경우가 많음
  언젠가 프로그래밍 언어 자체를 없앨 수도 있겠지만, 아직은 멀었음
- 고급 언어는 의미가 결정론적으로 유지되지만, 에이전트 코딩은 그렇지 않음
  의미가 확장되거나 압축되고, 심지어 사라지기도 함
많은 회사는 진짜로 좋은 코드를 원하지 않음
내부 평가는 “얼마나 많이 배포했는가”로 이뤄지고, 문제를 지적하면 “너무 세세하다”는 말을 듣게 됨
결국 내부 이해관계자들은 단지 ‘성공했다’는 명분을 원함
- 나는 좀 더 관대하게 보려 함. 회사는 좋은 코드를 원하지만, 속도와 품질의 트레이드오프를 고려함
  기술자는 그 위험을 설명할 책임이 있음
- 하지만 현실적으로는 사람들이 점점 덜 신경 쓰고 있음
  AI 도입 이후 품질 저하가 실제로 나타나고 있음
우리 회사는 PR 승인도 대충 하고, CI는 45분 걸리고, 배포는 며칠씩 지연됨
게다가 AI 사용도 금지되어 있음. 대부분 인간이 쓴 코드라고 하지만 의심스러움
이 글이 놓친 건 두 가지임 — (A) 에이전트 사용과 프로세스 최적화는 양립 가능하다는 점, (B) 어떤 티켓은 정말 코드가 병목이라는 점
결국 중요한 건 AI 여부가 아니라, 병목을 제거하는 프로세스 개선임
나는 1인 개발자임. 코딩 속도는 실제로 문제임. 다른 일에 쓸 시간을 빼앗기기 때문임
오늘 Claude Code를 설정했는데, 이제 구글링이나 테스트 작성에 시간을 덜 씀
생산성이 10배 오르진 않겠지만, 노동 절약 기술로서 충분히 가치 있음. 마치 식기세척기처럼
- 나도 비슷한 경험을 함. 예전엔 퇴근 후 새벽까지 구글링하고 테스트는 미루기 일쑤였음
  이제는 AI가 테스트까지 작성하고 엣지 케이스를 경고해줌
  완벽하진 않지만, 새 기능 출시 속도가 빨라지고 내 시간도 늘어남
  “AI를 믿을 수 없다”는 말은 마치 “컴파일러를 믿을 수 없다”는 말처럼 들림
  결국 인간이 방향을 제시하고, 프롬프트를 개선하며 함께 성장하는 과정임
- 제목이 말하는 건 “코딩이 주된 문제냐”는 것임
  스타트업이나 VC 환경에서는 코딩보다 비즈니스 문제 해결이 핵심임
  코드 생산량이 늘어도 시스템 전체의 결과가 좋아진다는 보장은 없음
- 나도 동의함. 여전히 코드를 한 줄씩 리뷰해야 함
  템플릿이나 코드 생성기처럼 속도는 빨라지지만, 요구사항 수집이 10배 빨라지지 않는 한 10배 생산성은 불가능함
- 이게 맞는 방향임
- 다만 식기세척기는 물과 에너지를 절약하지만, LLM은 그렇지 않음
  비유로 쓰기엔 조금 부적절함
AI가 사람이 잘 안 하는 실수를 저지르지 않게 하려면 어떻게 해야 할까?
사람은 코드를 단계별로 논리적으로 검토하지만, AI는 그렇지 않음
Amazon처럼 시니어 엔지니어가 리뷰하더라도, 리뷰는 모든 버그를 잡기 위한 과정이 아님
게다가 시니어일수록 회의가 많아 코드 맥락을 잘 모름. 이런 리뷰가 얼마나 효과적일까?
- 하지만 인간도 실수함. GitLab, S3, Knight Capital, MySpace 모두 대형 사고를 냈음
  인간이 완벽하다고 생각하는 건 착각임
  우리는 AI에게 인간보다 더 높은 기준을 요구하고 있음
  결국 중요한 건 QA 프로세스 강화임. 개발자에게 테스트를 맡기지 말아야 함
예전에 읽은 책 《The Goal》이 떠오름. 공정의 한 단계를 자동화하면, 그 다음 단계가 병목이 되는 현상임
소프트웨어도 마찬가지로, 코드 생성이 빨라져도 전체 프로세스가 따라오지 못하면 의미가 없음
결국 모든 것은 이윤 창출이라는 목표 아래에 있음. 코드 품질도 그 목표의 하위 개념일 뿐임
코드 작성 속도는 위험이 큰 상황에서는 병목이 아님
때로는 천천히 계획하고 결과를 숙고하는 게 더 낫음
예를 들어 AI 산업처럼 거대한 시스템을 너무 빠르게 구축하면, 잘못된 방향의 문명적 리스크를 초래할 수 있음
반면 주말에 혼자 만드는 작은 게임이라면 상관없음. 결국 리스크의 크기가 속도를 결정함

답변달기