# 코드 작성은 이제 싸다 > Clean Markdown view of GeekNews topic #27027. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27027](https://news.hada.io/topic?id=27027) - GeekNews Markdown: [https://news.hada.io/topic/27027.md](https://news.hada.io/topic/27027.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-02-26T23:26:04+09:00 - Updated: 2026-02-26T23:26:04+09:00 - Original source: [simonwillison.net](https://simonwillison.net/guides/agentic-engineering-patterns/code-is-cheap/) - Points: 15 - Comments: 1 ## Summary **코드 작성 비용의 급감**이 개발 문화의 근본을 재편하고 있습니다. 과거에는 코드 생산이 비쌌기에 설계와 기획 중심의 효율적 개발이 중시되었지만, 이제 **코딩 에이전트**를 통해 한 명의 개발자가 여러 작업을 병렬로 수행할 수 있게 되었습니다. 그러나 ‘좋은 코드’를 만드는 일은 여전히 비싸며, 품질 판단과 책임은 인간 개발자에게 남아 있습니다. 이에 따라 조직과 개인 모두 새로운 **에이전트 기반 엔지니어링 습관**을 정립해야 하는 시점에 놓여 있습니다. 이 글은 **Agentic Engineering Patterns** 가이드의 첫 번째 장인 “Principles” 의 일부인데요. 매주 한 두 챕터씩 추가할 예정이라고 합니다. ## Topic Body - **코드 작성 비용이 급격히 낮아진 현실**이 엔지니어링 습관 전반을 흔들고 있음 - 과거에는 코드 생산이 고비용이었기에 **설계·추정·기획 중심의 효율적 개발 문화**가 형성되었음 - **코딩 에이전트**의 등장으로 한 명의 개발자가 동시에 여러 작업(구현, 리팩터링, 테스트, 문서화)을 수행할 수 있게 됨 - 그러나 **‘좋은 코드’** 를 만드는 일은 여전히 높은 품질 기준과 개발자의 판단이 요구됨 - 이에 따라 **새로운 개인·조직적 개발 습관**을 구축해야 하는 과제가 부상함 --- ### 코드 작성 비용의 변화 - 과거에는 수백 줄의 **깨끗하고 테스트된 코드**를 작성하는 데 하루 이상이 소요되었음 - 이로 인해 개발자들은 제한된 시간과 비용을 기준으로 기능의 가치와 우선순위를 평가함 - 프로젝트 설계, 일정 추정, 기능 기획 등은 모두 **‘코딩 시간의 효율적 사용’** 을 중심으로 이루어졌음 - **코딩 에이전트**의 도입으로 코드 입력 비용이 급격히 낮아지며 기존의 판단 기준이 흔들림 - 한 명의 엔지니어가 여러 에이전트를 병렬로 실행해 **동시다발적 개발 작업**을 수행할 수 있음 - 이 변화는 기존의 **시간 대비 가치 판단 구조**를 재검토하게 만듦 ### 여전히 비싼 ‘좋은 코드’ - 새로운 코드의 생산은 거의 무료에 가까워졌지만, **‘좋은 코드’** 를 만드는 일은 여전히 비용이 큼 - 좋은 코드의 조건은 다음과 같음 - **정확히 동작**하고, 버그 없이 목적을 달성함 - **검증 절차**를 거쳐 코드가 신뢰할 수 있음을 입증함 - **적절한 문제 해결**에 초점을 맞추며, 오류 상황을 예측 가능하게 처리함 - **단순하고 최소한의 구조**로 유지보수성과 이해도를 높임 - **테스트와 문서화**가 최신 상태로 유지되어야 함 - **미래 변경 가능성**을 고려하되 불필요한 복잡성을 추가하지 않음 - **접근성, 보안성, 확장성, 유지보수성** 등 비기능적 품질 속성을 충족함 - 코딩 에이전트는 이러한 과정의 일부를 지원하지만, **최종 품질 보증 책임은 개발자에게 있음** ### 새로운 개발 습관의 필요성 - **에이전트 기반 엔지니어링(agentic engineering)** 환경에서는 기존의 개발 습관이 더 이상 유효하지 않음 - 개인과 조직 모두 **새로운 업무 방식과 판단 기준**을 형성해야 함 - 현재 업계 전반에서 이러한 **최적 실천법(best practices)** 이 정립되는 중임 - 제안된 접근 방식은, “시간이 아깝다”고 느껴지는 순간에도 **비동기 에이전트 세션을 실행해 실험**해보는 것임 - 최악의 경우 10분 후 확인해 **토큰 낭비**로 끝날 뿐임 ### Agentic Engineering Patterns 가이드 내 위치 - 본 글은 **Agentic Engineering Patterns** 가이드의 첫 번째 장인 **“Principles”** 의 일부임 - 다음 장에서는 **코드 이해(Understanding code)** 주제로 **[Linear walkthroughs](https://simonwillison.net/guides/agentic-engineering-patterns/linear-walkthroughs/)** 가 이어짐 - 이후 **Testing and QA** 섹션에서는 **[Red/green TDD](https://simonwillison.net/guides/agentic-engineering-patterns/red-green-tdd/)**, **[First run the tests](https://simonwillison.net/guides/agentic-engineering-patterns/first-run-the-tests/)** 등의 주제가 다뤄짐 - 매 주 1~2 챕터씩 추가할 예정이며, 책과 비슷하지만 "가이드" 라는 형태로 구성 예정 ## Comments ### Comment 51967 - Author: neo - Created: 2026-02-26T23:26:04+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47125374) - “코드는 항상 비쌌다”는 표현이 맞는지 모르겠음 실제로 비싼 건 **코드 그 자체가 아니라 그 주변의 모든 과정**이었음 — 정확성 확보, 유지보수, 팀 간 조율, 장기 지원 등이 진짜 비용 요인이었음 테스트나 승인 절차를 과도하게 거치면 오히려 프로세스가 비용의 대부분을 차지하게 됨 LLM은 단기적으로 **작동하는 코드 생성 비용**을 크게 낮췄지만, 장기적으로는 유지보수·보안·테스트 부담이 커질 수도 있음 결국 진짜 변화가 일어났는지는 장기 데이터를 봐야 알 수 있음 - “비싼 건 코드 주변의 모든 것”이라는 말에 동의함 예전엔 몇백 줄의 코드조차 작성 비용이 컸음 2000년대식 SLOCount 도구([WebAssembly 버전](https://tools.simonwillison.net/sloccount))에 256줄의 JavaScript를 넣어보니 당시 기준으로 약 **$6,461**의 비용 추정이 나왔음 물론 그 수치는 재미로만 봐야 함 - 내 경험상 코딩뿐 아니라 **DevOps, 데이터 분석, 지원 업무** 등 모든 영역이 AI로 강화되었음 지금은 내가 직접 일하기보다 내 일을 관리하는 **자기 매니저**에 가까움 생산성은 예전보다 약 2.5배 정도 오른 느낌임 - 소프트웨어 개발 생명주기(SDLC)를 보면 코딩은 한 단계일 뿐임 요구사항 수집, 설계, 테스트, 배포, 유지보수가 여전히 필요하고, 대부분의 비용은 **유지보수 단계**에서 발생함 Amdahl의 법칙처럼 코딩 비용이 0에 가까워져도 다른 단계의 비용이 한계가 됨 - 진짜 비용 절감은 사용자가 “정말 원하는 것”을 정확히 아는 데서 나옴 문제는 그게 인간 본성상 어렵다는 점임 - 코드는 과거에도, 지금도, 앞으로도 비쌈 **정확성·유지보수성·성능** 같은 품질 요소는 경험을 통해서만 체득되는 숨은 비용임 - “코드는 항상 비쌌다”는 주장에 동의하지 않음 사실 코드는 ‘좋은 코드’를 쓰려 했기 때문에 비쌌던 것임 기준을 낮추면 생성된 코드는 빠르고 싸지만, **좋은 코드로 되돌리는 노력**은 여전히 동일함 에이전트 코딩을 옹호하려면 다른 논리로 접근해야 함 - 내 경험상 AI 에이전트를 쓸 때 오히려 **좋은 코드 확보**가 더 힘듦 직접 쓸 땐 각 줄의 이유를 이해하지만, AI가 만든 코드는 매 구문을 검증해야 함 최근 한 달간 대부분의 작업을 에이전트로 했는데, 인간이라면 만들지 않을 **엣지 케이스 버그**가 계속 나옴 결국 검토 비용이 커서 단기 이득이 사라짐 - “좋은 코드는 여전히 비용이 든다”고 조심스럽게 표현했음 다만 코딩 에이전트 덕분에 그 비용은 **훨씬 줄어듦** 세밀한 수정은 에이전트가 대신하므로 더 나은 품질의 코드를 빠르게 만들 수 있음 - 단순한 코드는 싸지만, **복잡한 코드는 여전히 비쌈** 복잡성은 누적되므로 처음 작성할 때 세심히 다루는 게 가장 저렴함 지금은 단기적 이득이 크지만, 장기적으로는 노이즈가 10배 늘어날 수도 있음 - **프로그래밍은 싸지만 소프트웨어 엔지니어링은 비쌈**이라는 말이 핵심임 - Ousterhout의 **전술적 vs 전략적 프로그래밍** 개념이 떠오름 LLM은 전술적 프로그래밍, 즉 빠른 기능 구현에 특화되어 있음 그래서 시스템 차원의 복잡성 관리가 더 중요해짐 - 코드 생성은 말하는 것만큼 싸지만, **가치 있는 결과로 바꾸는 기술**이 진짜 실력임 Agentic engineering은 결국 값싼 입력을 가치 있는 산출로 이끄는 기술임 - “값싼 입력을 가치 있는 결과로 이끄는 기술”에 완전히 동의함 Agentic engineering은 단순히 소프트웨어 작성이 아니라 **특정 문제를 빠르게 해결하는 도구 제작**임 하지만 문제 해결이 끝나면 AI 자체는 흥미롭지 않음 많은 사람들이 AI 자체를 목적으로 삼는데, 진짜 가치는 **문제 해결**에 있음 Alan Watts의 말처럼, 메시지를 받았으면 전화를 끊어야 함 - 굴착기가 생겼다고 아무 데나 구덩이를 파서 부자가 되는 건 아님 도구가 싸졌다고 가치가 자동으로 생기진 않음 - 실제로 코드를 타이핑하는 행위는 가치가 아님 **설계와 구조화 능력**이 진짜 가치임 - 같은 두뇌에서 나온 출력이라면, 세밀히 지시하든 운 좋게 한 번에 나오든 **품질은 비슷**함 결국 의사결정의 질이 핵심임 - 1억 달러를 모금했다고 해서 그 아이디어가 좋은 건 아님 자금 조달이 가치의 증거는 아님 - “코드는 항상 비쌌다”는 주장에 의문을 가짐 깨끗하고 테스트된 코드의 정의부터 모호함 테스트를 과도하게 하면 비용이 폭증하고, **조직적 승인 절차**도 큰 비용 요인임 LLM은 단기 비용을 줄이지만 장기 유지보수 비용은 늘어날 수 있음 - 코드는 항상 비쌌음 내가 인턴 시절 스타트업에서 싸게 일했지만, **장애·데이터 손상·기술 부채**가 쌓였음 겉보기엔 싸 보였지만 숨은 비용이 컸음 LLM 덕분에 지금은 품질 좋은 코드를 싸게 얻을 수 있는 듯하지만, 여전히 적응 중임 - 스타트업 입장에선 예전엔 제품을 내기 위해 **6개월 이상 개발자 고용**이 필요했음 지금은 v1을 만드는 건 싸지만, **성숙한 제품의 복잡한 결정**은 여전히 비쌈 - 소프트웨어의 경제적 가치는 **코드에 담긴 정보**에 있음 코드 작성은 그 정보를 매핑하는 과정일 뿐, 정보의 질이 진짜 가치를 결정함 빠르게 코드를 쓴다고 정보의 질이 좋아지지 않음 컨설팅에서 슬라이드를 빨리 만든다고 가치가 생기지 않는 것과 같음 - 이 개념은 최근 화두인 **인지 부채(cognitive debt)** 와 맞닿아 있음 구현 속도가 너무 빨라지면 개발자의 **정신적 모델이 코드와 어긋남** 관련 글: [Cognitive Debt by Simon Willison](https://simonwillison.net/tags/cognitive-debt/) - 나도 코딩 에이전트를 쓰면서 **정보와 코드의 매핑 품질**이 오히려 좋아진 경험이 있음 리팩터링을 빠르게 반복할 수 있었기 때문임 - 결국 병목은 **의도를 기계에 전달하는 과정**임 AI가 점점 더 맥락을 이해하게 되겠지만, 그만큼 인간의 판단을 포기해야 함 언젠가 기계가 완전히 의도를 파악하게 되면 인간은 루프 밖으로 밀려날 것임 - 모든 개발 방법론의 핵심은 **요구사항은 항상 변한다**는 사실임 그래서 좋은 코드는 “변경하기 쉬운 코드”임 지금의 LLM 에이전트가 그런 코드를 만드는지는 의문임 완전히 신뢰할 수 있을 때까지는 프로토타입 수준에 머물 것 같음 - 실제 병목은 코드 작성이 아니라 **의도를 명확히 전달하는 비용**임 명세가 불분명하면 테스트·가치 검증이 모두 어려워짐 - 인간 엔지니어도 100% 안전하게 수정하진 못함 테스트가 있어도 **약 70% 정도의 확신**만 있음 - 나는 LLM을 세밀히 관리하며 기능 수정과 버그 수정을 자주 시킴 직접 코딩보다 빠르고, 결과도 **유지보수 가능한 코드**로 나옴 - 나는 이미 모든 커밋을 **에이전트가 100% 생성**함 깨끗한 코드와 좋은 관행을 명시하면 충분히 유지보수 가능한 결과가 나옴 결국 **Garbage in, garbage out**임 - 하지만 어떤 사람은 LLM이 **데모 수준까진 좋지만, 작은 수정에도 무너진다**고 느낌 - 내가 쓴 글([The Final Bottleneck](https://lucumr.pocoo.org/2026/2/13/the-final-bottleneck/))에서 말했듯, 코드 작성 속도가 빨라졌지만 **그 이후 단계가 따라오지 못함** 단순히 습관이 아니라 **책임 구조·언어 설계·시스템 구조 전체**가 바뀌어야 함 - 모든 회사가 새로운 방식으로 일하긴 어려움 정말 생산성이 10배 오른다면 이미 **스타트업들이 시장을 뒤집었을 것**임 - LLM이 충분히 작고 싸지면, 앱에 내장되어 사용자별로 코드를 조정하는 시대가 올 것임 - “왜 그렇게 빨리 코드를 써야 하는가?”라는 의문도 있음 가능하다고 해서 반드시 해야 하는 건 아님 - 오픈소스 개발자들이 **비개발자도 빌더가 되는 시대**를 이끌어야 함 AI evals([measure-first-optimize-last](https://alexhans.github.io/posts/series/evals/measure-first-optimize-last.html), [ai-evals.io](https://ai-evals.io)) 같은 접근이 그 방향임 - “그 속도로 계속 배포해야 하나?” **기능 폭주**는 누구도 원하지 않음 - 코드 한 줄 한 줄이 **부채(liability)** 임 LLM이 코드를 쏟아내는 시대에, 그 부채가 폭증함 도구 자체는 나쁘지 않지만, **책임 없는 프로그램이 코드베이스를 재작성**하는 구조는 위험함 - 우리는 수십 년간 코드 배포에 **검증·리뷰·롤백 체계**를 쌓아왔음 “코드가 싸다”는 건 생성이 싸졌다는 뜻이지, **배포 승인 비용**은 여전히 큼 판단 단계를 생략하면 생산성 향상이 아니라 **통제 공백(control gap)** 이 생김 빠르다고 마스터키를 주는 건 위험함 - 작성도, 유지보수도 여전히 비쌈 어느 쪽이든 싸진 않음 - 나도 이 의견에 거의 전적으로 동의함 코드 작성은 싸졌지만, **검토와 검증 비용**은 여전히 큼 특히 수백만 줄짜리 모노레포에서는 테스트 가능성을 높이는 게 핵심임 이런 논의가 트위터의 과열된 분위기 속에서 균형을 잡아줘서 고맙게 느껴짐 - 나도 같은 관찰을 함 코드 churn은 쉬워졌지만, **품질 검증**이 새로운 도전이 됨 LLM이 만든 대량의 변경은 미묘한 실패를 낳고, 그 흐름은 멈추지 않음 - 코드는 싸지 않음 **토큰 비용**도 있고, 실제 비용 구조는 아직 불확실함 수익이 없는 스타트업들이 GPU 공급망을 독점하는 상황이라 데이터가 부족함 - **작성은 싸졌지만 유지보수는 동일**함 LOC가 늘수록 부채도 늘어남 생각에서 실행까지의 거리는 짧아졌지만, 여전히 코드 자체는 책임임 - 로컬 모델이 **비용의 하한선**을 보여줌 지금은 보조금 덕에 싸지만, 하드웨어·전력·인력 비용이 내려가면 더 싸질 수도 있음