코드 작성은 절대 병목 지점이 아니었음

(ordep.dev)

9P by GN⁺ 16시간전 | ★ favorite | 댓글 1개

소프트웨어 개발에서 병목은 코드 작성이 아니라 코드 리뷰, 지식 이전, 테스트, 디버깅, 협업/소통 등 다양한 인간 중심 프로세스에서 발생함
LLM 덕분에 코드 생성 자체는 매우 쉬워졌지만, 오히려 이해, 검증, 신뢰에 드는 비용과 부담은 더욱 커짐
빠른 코드 생성은 리뷰어·통합자·유지보수 담당자에게 더 많은 부담을 주며, 팀 전체의 속도가 실제로 빨라지지 않음
코드 이해가 가장 어려운 부분이며, LLM이 코드를 생성해도 팀의 신뢰와 맥락 공유 없이는 품질이 보장되지 않음
LLM은 프로토타이핑·자동화엔 강력하지만, 신중한 설계·리뷰·공유 맥락 등 소프트웨어 개발의 기본을 대체하지 못함

코드 작성의 진짜 병목 지점

수년간 코드 작성 작업 자체는 소프트웨어 엔지니어링의 병목이 아니었음
실제 병목은 코드 리뷰, 멘토링과 페어 프로그래밍을 통한 지식 전달, 테스트, 디버깅, 협업·소통의 비용에서 발생
티켓 관리, 플래닝 회의, 애자일 미팅 등 복잡한 절차가 속도를 더 늦춤
품질 보장을 위한 이러한 과정들이 실제로는 코드 작성 자체보다 훨씬 많은 시간과 사고를 요구함
그러나 LLM 덕분에 동작하는 코드 생성 비용은 0에 수렴하고 있음
하지만 코드 이해, 테스트, 신뢰 확보 비용은 오히려 더 높아짐
초기 구현 속도는 빨라졌지만, 더 많은 코드가 리뷰/통합/유지보수 대상이 되어 부담 가중

LLM이 일의 본질을 바꾼다 – 제거하지는 않음

Claude 같은 LLM 툴은 초기 구현 속도를 높여주지만, 결국 더 많은 코드가 더 짧은 시간에 시스템에 유입되면서 리뷰와 유지보수 담당자에게 더 큰 부담을 줌
특히 다음 상황에서 이 부담이 심화됨
- 작성자가 본인이 등록한 코드를 충분히 이해하고 있는지 불확실함
- 생성된 코드가 익숙하지 않은 패턴이거나 기존 컨벤션을 위배함
- 경계 조건 및 의도치 않은 부작용이 명확히 드러나지 않음
이로 인해 코드 생산은 쉬워져도, 검증 난이도는 더 높아지고 결과적으로 팀 전체 속도를 높이지 못함
원래 개발자들 사이에는 “복사-붙여넣기 엔지니어링” 에 대한 농담이 있었지만, LLM으로 이 현상이 훨씬 증폭됨

코드 이해가 진짜 어려움

“코드의 가장 큰 비용은 작성이 아니라 이해임”

LLM 덕분에 코드 생산 자체는 빨라지지만, 동작을 추론하거나, 미묘한 버그를 찾거나, 장기 유지보수를 보장하는 작업은 결코 쉬워지지 않음
특히 리뷰어가 생성 코드와 직접 작성한 코드를 구분하지 못하거나, 선택한 풀이의 이유를 파악하기 어려울 때 더욱 어려워짐

팀은 여전히 신뢰와 공유 맥락에 의존함

소프트웨어 개발은 기본적으로 협업이 전제이며, 공유된 이해와 정렬(Alignment), 멘토링에 전적으로 의존함
코드가 논의 및 리뷰 속도보다 빠르게 생성될 때에는, 팀이 실제로는 품질을 확인하지 않았으면서도 품질이 이미 검증된 것처럼 착각하게 됨
이로 인해 리뷰어와 멘토의 심리적 부담이 커져 팀 전체의 속도가 새로운 방식으로 느려질 수 있음

LLM은 강력하지만 본질을 해결하지 못함

빠른 프로토타이핑, scaffold, 자동화에 LLM이 가치가 크지만 명확한 사고, 신중한 리뷰, 깊이 있는 설계의 필요성을 없애주진 않음
코드 작성 비용 자체는 하락했지만, 팀이 코드를 함께 이해하고 의미를 부여하는 비용은 변하지 않음
진짜 병목은 여전히 "이해와 협업"에 있음

▲

GN⁺ 16시간전 [-]

Hacker News 의견

경험 많은 멘토로서 야심은 크지만 아직 미숙한 인턴들을 지도하면서, 하루 만에 일주일, 혹은 이주일 분량의 코드를 쏟아내는 모습을 관찰한 경험담임. 하지만 내 일은 이전보다 오히려 더 어려워졌음. 코드 리뷰를 할 때, 인턴들은 자신이 작성한 코드에 대해 깊은 고민이 부족해 내 피드백이 잘 전달되지 않음. 단순한 버그나 사소한 문제는 거의 없어졌지만, 남은 문제들은 더 미묘하고 복잡한 것들이며, 설명하기도 훨씬 힘들어짐. 게다가 전에 본 적 없는 새로운 유형의 버그들이 등장함. 겉보기엔 멀쩡한 코드가 실제로는 전혀 동작하지 않기도 하고, 완성도가 있는 것처럼 보여도 기본적인 부분부터 망가져 있는 경우가 많음. LLM과 협업하는 주니어들은 오히려 단순하면서도 논의 가치가 있는 코드를 내놓기보다, 여러 측면에서 협업과 유지보수에 문제를 일으키는 복잡한 코드를 한 번에 완성된 것처럼 만들어내는 경향임. 결과적으로 PR 하나를 최종 품질까지 다듬는 전통적인 “점진적 개선” 방식이 제대로 작동하지 않는 느낌임. 피드백을 주면, 원래 PR을 고치기보다 아예 새로운 접근을 제시하기도 하는데—종종 또 다른 새로운 문제를 일으킴. 그래서 오히려 시니어들이 주니어보다 이 PR 하나에 훨씬 오랜 시간을 들이게 됨. 주니어 쪽에서는 본인이 매우 생산적이라고 느낄지 모르지만, 점점 시니어 리뷰어의 피드백이 예전만큼 따뜻하거나 격려하는 분위기가 아니게 되는 현상도 있음. 궁극적으로 많은 테스트 케이스를 필수로 요구했던 게 그나마 효과 있었는데, 이 테스트조차 비슷한 문제로 한계에 부딪침
- 이런 '완성도 있어 보이지만 전혀 동작하지 않는' 코드를 보고, 예전에 내가 겪었던 25만 달러 규모의 해외 소프트웨어 개발 프로젝트가 생각남. 사양서만 보면 모든 게 맞는 듯했지만 실제론 전혀 일관성 없는 시스템이었음. 사양서 해석에만 집착하고 상식적인 부분을 놓쳐서, 결국 전체 프로젝트를 바로 폐기했던 기억임. 이제 이런 일들이 LLM 덕분에 자동화, 무료화되고 있다는 사실이 인상적임
- 이런 문제에 완전히 공감함. 내 개인적인 경험으로도 LLM을 활용할 때 수천 줄의 코드를 아주 빠르게 만들 수 있긴 하지만, 진짜 어려운 일은 코드 리뷰, 버그 수정, 보안 취약점 점검, 리팩터링, 불필요한 코드 제거 등임. 결국은 직접 코딩하는 것이 더 생산적인 상황이 많았음. LLM은 자동 완성이나 간단한 조각 생산에만 쓰는 게 가장 현실적인 활용법임. 주니어가 LLM을 중간에 끼고 내가 또 전달해야 한다면 효율이 더 떨어질 것 같음. 현재 LLM으로 더 생산적이라고 느끼는 사람들은 실제로는 이런 중요한 작업을 아예 건너뛰거나 아예 신경 쓰지 않아서 그렇게 느끼는 것일 수도 있음. 실제로 제품 품질에 신경 쓰는 소수의 사람들만이 엄청난 코드량을 감당해야 하는 부담을 떠안게 됨. 이들이 불필요하게 까다로운 사람이라고 오해 받기도 하지만, 사실 사용자에게 최상의 제품을 전달하려는 진짜 주인공임. 개선 방안은 딱히 없고, 오히려 상황이 더 악화될 것으로 보임. LLM만 사용해서 훈련된 개발자들이 업계에 계속 유입되고, 도구를 만드는 회사들은 계속 과장된 마케팅을 일삼음. 결국 퀄리티 유지의 부담만 증가하는 구조임
- 시니어들이 PR 하나에 주니어보다 더 많은 노력을 쏟게 되는 'effort inversion' 현상을 나도 겪고 있음. 나의 경우엔 PR 작가들이 블로그 글이나 보도자료 작성에 AI를 활용하는데, 주제 전문가인 내가 결과물을 받으면 온갖 AI 환각과 오류를 바로잡느라 작업 시간이 3, 4배로 늘어남. 그들의 업무는 원래 나를 지원하는 건데, 이제 내가 그들을 도와야 하는 상황임. 심지어 AI 환각도 그때그때 다르니 매번 새로 고생함. 이런 현상을 임원에게도 이미 전달했는데, 이런 식이라면 PR 인력의 절반이 내년에 사라질 것 같음. 이메일을 복사해서 ChatGPT에 붙여넣고 다시 내게 보내주는 역할이 필요 없다면, 내가 직접 할 수 있음
- "리뷰 중 내가 한 피드백이 잘 전달되지 않았다"는 부분에 대해 더 자세한 설명을 해줄 수 있는지 궁금함. 비슷한 문제를 겪고 있어, 해결책이나 통찰이 있다면 공유 부탁임
- 내 생각을 더하면, 이전 세대는 리팩터링이나 유닛 테스트를 통해 소프트웨어 구조, 설계에 대한 깊은 이해를 자연스럽게 쌓았던 것임. 그런데 앞으로 LLM이 유닛 테스트까지 생성한다면 개발자는 "내가 뭘 필요로 하지?", "이걸 더 단순하게 할 방법이 뭐지?" 같은 자기 반성과 학습을 할 기회가 없어질 수도 있음. 내가 생각하는 '개발자', '엔지니어', '아키텍트' 차이는 바로 여기에 있음. LLM이나 'vibe coding'은 그런 방식의 마인드셋을 결코 길러주지 못함. Go처럼 문법 부담이 적은 언어에서는 이런 설계 미스가 리뷰에서 더 쉽게 드러남. Go의 유닛 테스트 구조가 코드 복잡성 진단에 유용함. 결국 우리는 더 나은 테스트/리뷰 방법이 필요함. 퍼즈 테스팅, 단위 테스트, 통합 테스트만으론 부족함. 코드의 분기문이 제대로 호출되고 있는지, 만족 조건이 성립되는지 논리적으로 확인해줄 수 있는 자동화된 테스트 프레임워크가 필요하다고 생각함
LLM 덕분에 소프트웨어 신규 도입 비용이 거의 0에 가까워지고 있지만, 그 코드를 깊이있게 이해하고 테스트하고 신뢰하는 비용은 그 어느 때보다 높아진 느낌임. 하지만 내 경험상 LLM이 만든 코드가, 이미 떠난 사람이 만들어놓고 제대로 질문조차 못하는 수많은 과거 코드나, 온라인에서 굴러다니는 코드와 비교해 그렇게 훨씬 나쁘다고 생각하지는 않음. 오히려 LLM은 테스트 코드를 작성하는데 인간처럼 귀찮아하지도 않고, 피곤해서 대충 넘어가는 일도 없음. 내 철학은 ‘모든 코드는 잠재적 부채’라는 전제에서 출발함. 그래서 그다지 코드 신뢰도에 대해 걱정하지 않음. 실제로 AI로 거대한 코드베이스를 만들어가며 충분히 동작시키기도 했음—단, 도메인이 검증 가능하고, 테스트와 반복이 많아야 가능함. 결론적으로 LLM 결과물로 코드 생산은 빨라졌으나, 코딩 자체의 지적 자극이 줄어든 느낌이라 내 뇌도 함께 나태해지는 느낌임. 오히려 요구사항 정의, 설계 등 앞단의 두뇌노동이 훨씬 중요한 시대로 넘어감
LLM 없이도 이미 업계는 "코드 부족"이 아니라, 시장 수요와 자본 한계로 인해 개발 속도에 한계가 있었던 상태임. 툴링이 너무 좋아져서 코딩 자체가 핵심이 아니게 된 것임. 초창기와는 완전히 달라진 환경임. Bill Gates가 10대 시절, 단순히 ‘코딩할 수 있는 능력’ 자체가 희소 자원이던 시절의 일화가 기억남. 회사가 급해서 16살짜리 Gates와 Paul Allen을 고용했고, 그들이 단순히 빨리 코드를 짠다는 이유만으로 신기해했다는 이야기임. 지금은 "무엇을 개발하고, 거기에 비즈니스가 성립하는가?"가 더 중요한 문제임
관련 영상
- 코딩이 병목이 아니었던 건 시장 수요 때문이라는 주장에 동의함. AI 붐 전에 Marc Andreessen도 "자본은 넘치지만 투자할 좋은 아이디어가 부족하다"고 말했음. 난 그 말이 현실을 잘 반영한다고 생각하지 않지만, 적어도 데이터상으론 그의 발언이 신빙성 있어 보임
- Bill Gates의 예전 일화처럼, 여전히 고품질의 코드를 짜고 깊이 이해하는 능력은 드문 자원임. 다만 예전과 다른 점은, 산업이 그 능력을 중요하게 여기지 않는 분위기임
- AI의 임팩트 분석 관점에서 보면, 우리는 효율성을 지나치게 과신하는 경향이 있음. 하지만 현실 경제는 그보다 훨씬 복잡한 구조로 병목이 발생함. 코드 생산량이 100배 늘어난다고 해도 실제 쓸모가 있는지는 불명확함
요즘 누군가의 경험담을 보면 너무 우울해보임. 주니어가 동작하지 않고, 직접 테스트/검증도 하지 않고, 간결하게 정제하지도 않은 거대한 코드 뭉치를, 문서나 주석, 설명도 없이 넘긴다면 이미 그 자체가 "LLM이 인간에 탑재된 버전"이라고 표현할 수 있음. 결국 중요한 것은 비판적 사고와 결과에 대한 책임 의식임. 오히려, LLM이 기존 주니어 소프트웨어 엔지니어보다 피드백에 충실히 반응할 가능성이 더 높다고 생각함
- 주니어가 LLM으로 짠 코드를 선배에게 리뷰 맡기는 현상을 LLM의 결점으로 보는 시각이 많지만, 나는 오히려 주니어 자체의 부족함을 드러낸 현상이라고 봄. 차라리 시니어가 직접 LLM을 활용하는 게 더 낫다고 생각함
나 역시 한때는 코드 작성이 병목이라고 여겼지만, 10년 동안 실제 어려운 건 기술을 비즈니스와 일치시키는 작업임을 깨달음. B2B나 SaaS처럼 고객마다 달라지는 복잡한 코드더미를 다루는 환경이라도, 기술이 비즈니스에 제대로 맞춰진다면 모든 게 순조로움. 요즘은 기술이 충분히 발전했으니, 이제 진짜 관건은 개발자의 ‘에고’와 고객 가치에 집중하는 자세임. 고객이 실제로 원하는 것, 거기에 돈을 낼지, 아예 웹 인터페이스가 필요한지도 고민해야 함. 개발자가 자기 만족을 위해 만드는 “캣토이 기능”이 클라우드 비용을 늘리는 진짜 원인임. 더욱 슬픈 사실은, 공격적인 인센티브나 스톡옵션, 연봉을 던져도 이 본질적 문제는 해결되지 않는다는 점임. 소프트웨어를 잘 만들고 싶다는 ‘사명감’이 있는 누군가, 꼭 한 명이라도 고객과 직접 소통하며 제대로 해보겠다는 의지가 있어야 함
조직에서 LLM이 진짜 도움이 됐던 순간은 내 개인 프로젝트나 사이드 프로젝트임. 작은 문제를 해결하기 위한 앱을 개발할 때, 시간이 부족해서 코드 작성이 실제로 큰 병목이 됨. 이런 프로젝트엔 LLM 활용도가 100%임
- 나도 백퍼 공감함. 하루 1~2시간 Claude code에 투자하면 주말이 끝나갈 때쯤 실사용 가능한 결과물 하나가 생김. 짧은 시간 투자로 아이디어 검증이나 실험이 쉬워짐. 이런 LLM 도구는 실제로 프로 조직에서도 엄청난 가치를 낸다고 생각함. 평소엔 시간이 부족해서 못 만들었던 각종 관리 도구나 자동화 시스템도 빠르게 프로토타이핑이 가능함. 동료가 DB 쿼리나 단순한 자동화가 필요하다면 Claude에 물어본 뒤 리뷰하고 바로 붙여넣기만 하면 됨. 이렇게 엔지니어가 아니라도 자기 영역의 반복 업무를 스스로 처리할 수 있도록 지원하는 게 내 프로젝트 mcp-front[0]의 목적이기도 함
  mcp-front 깃허브
- 솔직히 지금 내 커리어 상태에서는 일주일씩 쏟아붓기 어렵고, 오랜 노하우로 비기능 요구사항, 장기적 관점까지 항상 고려하고 있음. 테스트 같은 걸 건너뛴다 해도 결국엔 계속 고민할 일이 많음
Robert C. Martin의 "코드를 읽는 시간이 쓰는 시간보다 10배 이상 많다"는 명언이 떠오름
관련 인용구
- 안타깝게도 그의 클린 코드 스타일이 실제로는 맥락을 파편화시켜 의도가 더 파악하기 어려워지는 경우도 많음
- 더 나쁜 건, 오히려 작성 시간은 줄이면서 읽는 시간만 늘려서 전체 업무량이 줄지 않을 수도 있음
아무도 언급하지 않은 Joel Spolsky의 2000년 10월 2일 글을 소개함
Joel on Software: Painless Functional Specifications (2000)
진짜 병목은 코드가 아니라 기능명세(spec)임. 소프트웨어가 어떻게 동작해야 하는지, 영어, 다이어그램, 사용자 스토리 등 명확한 명세를 만드는 일이 더 중요함. 명세가 잘 잡혀 있다면, LLM도 충분히 훌륭한 솔루션·테스트·통합 테스트를 한 번에 만들어낼 수 있음. 너무 크다면, 명세는 마크다운 파일 하나로 관리할 것이 아니라 위키처럼 기능별로 쪼개 링크와 참조로 관리해야 함. 구현 난이도가 아니라, 명세에 얼마나 힘을 들였는지가 진짜 경쟁력임
필자는 저자 견해에 동의하지 않음. 대기업 관점에서는 코드가 병목이 아니겠지만, 스타트업 입장에서는 자원이 한정적이고 효율적인 플래닝이 더 중요했음. 즉, 실제로 제대로 동작하는 코드를 만드는 작업 자체가 가장 큰 병목이었던 경우도 많음. 결국 이런 논의에서는 "AI/LLM이 얼마나 유용한가"를 일반화할 수 없음. 어떤 팀에게는 코드가 병목이었고, 어떤 팀에게는 아니었음
- 내가 본 현장도 동일함. LLM은 소수의 뛰어난 소규모 개발팀에게 엄청난 레버리지를 줌. 뛰어난 인력이 있어야 LLM도 좋은 결과를 내고, 대규모 팀은 오히려 협업 비용이 너무 커 LLM 혜택이 적음. 원래 잘하던 소수 팀이 가장 많이 '슈퍼차지'되는 느낌임
모두 알다시피 LLM이 만들어내는 코드는 엉망인 경우가 많고, 리뷰조차 불가능함. 주니어가 제출하는 LLM 코드가 이상해서 이유를 물어보면 본인도 모르고, LLM이 만들었다고 답하는 상황임. 결국 이런 추세는 코드 유지보수에 ‘노이즈’와 ‘오버헤드’만 늘림. 만약 LLM 도입을 피할 수 없다면, 리뷰와 유지보수도 LLM에 맡길 수밖에 없음. 물론 결과는 더 복잡한 스파게티가 될 것임. 하지만 현실적으로 대다수 비즈니스에서는 품질이 딱히 중요하지 않은 경우가 대부분이고, LLM 코드가 대충 잘 동작하면 그걸로 족하다고 여김. 아니면 필요한 만큼 LLM을 계속 덧붙여서 결국 해결되는 수준이면 충분함

답변달기