▲

코드 작성은 이제 싸다

 (simonwillison.net)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • 코드 작성 비용이 급격히 낮아진 현실이 엔지니어링 습관 전반을 흔들고 있음
  • 과거에는 코드 생산이 고비용이었기에 설계·추정·기획 중심의 효율적 개발 문화가 형성되었음
  • 코딩 에이전트의 등장으로 한 명의 개발자가 동시에 여러 작업(구현, 리팩터링, 테스트, 문서화)을 수행할 수 있게 됨
  • 그러나 ‘좋은 코드’ 를 만드는 일은 여전히 높은 품질 기준과 개발자의 판단이 요구됨
  • 이에 따라 새로운 개인·조직적 개발 습관을 구축해야 하는 과제가 부상함

코드 작성 비용의 변화

  • 과거에는 수백 줄의 깨끗하고 테스트된 코드를 작성하는 데 하루 이상이 소요되었음
    • 이로 인해 개발자들은 제한된 시간과 비용을 기준으로 기능의 가치와 우선순위를 평가함
    • 프로젝트 설계, 일정 추정, 기능 기획 등은 모두 ‘코딩 시간의 효율적 사용’ 을 중심으로 이루어졌음
  • 코딩 에이전트의 도입으로 코드 입력 비용이 급격히 낮아지며 기존의 판단 기준이 흔들림
    • 한 명의 엔지니어가 여러 에이전트를 병렬로 실행해 동시다발적 개발 작업을 수행할 수 있음
    • 이 변화는 기존의 시간 대비 가치 판단 구조를 재검토하게 만듦

여전히 비싼 ‘좋은 코드’

  • 새로운 코드의 생산은 거의 무료에 가까워졌지만, ‘좋은 코드’ 를 만드는 일은 여전히 비용이 큼
  • 좋은 코드의 조건은 다음과 같음
    • 정확히 동작하고, 버그 없이 목적을 달성함
    • 검증 절차를 거쳐 코드가 신뢰할 수 있음을 입증함
    • 적절한 문제 해결에 초점을 맞추며, 오류 상황을 예측 가능하게 처리함
    • 단순하고 최소한의 구조로 유지보수성과 이해도를 높임
    • 테스트와 문서화가 최신 상태로 유지되어야 함
    • 미래 변경 가능성을 고려하되 불필요한 복잡성을 추가하지 않음
    • 접근성, 보안성, 확장성, 유지보수성 등 비기능적 품질 속성을 충족함
  • 코딩 에이전트는 이러한 과정의 일부를 지원하지만, 최종 품질 보증 책임은 개발자에게 있음

새로운 개발 습관의 필요성

  • 에이전트 기반 엔지니어링(agentic engineering) 환경에서는 기존의 개발 습관이 더 이상 유효하지 않음
  • 개인과 조직 모두 새로운 업무 방식과 판단 기준을 형성해야 함
  • 현재 업계 전반에서 이러한 최적 실천법(best practices) 이 정립되는 중임
  • 제안된 접근 방식은, “시간이 아깝다”고 느껴지는 순간에도 비동기 에이전트 세션을 실행해 실험해보는 것임
    • 최악의 경우 10분 후 확인해 토큰 낭비로 끝날 뿐임

Agentic Engineering Patterns 가이드 내 위치

  • 본 글은 Agentic Engineering Patterns 가이드의 첫 번째 장인 “Principles” 의 일부임
  • 다음 장에서는 코드 이해(Understanding code) 주제로 Linear walkthroughs 가 이어짐
  • 이후 Testing and QA 섹션에서는 Red/green TDD, First run the tests 등의 주제가 다뤄짐
  • 매 주 1~2 챕터씩 추가할 예정이며, 책과 비슷하지만 "가이드" 라는 형태로 구성 예정
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • “코드는 항상 비쌌다”는 표현이 맞는지 모르겠음
    실제로 비싼 건 코드 그 자체가 아니라 그 주변의 모든 과정이었음 — 정확성 확보, 유지보수, 팀 간 조율, 장기 지원 등이 진짜 비용 요인이었음
    테스트나 승인 절차를 과도하게 거치면 오히려 프로세스가 비용의 대부분을 차지하게 됨
    LLM은 단기적으로 작동하는 코드 생성 비용을 크게 낮췄지만, 장기적으로는 유지보수·보안·테스트 부담이 커질 수도 있음
    결국 진짜 변화가 일어났는지는 장기 데이터를 봐야 알 수 있음

    • “비싼 건 코드 주변의 모든 것”이라는 말에 동의함
      예전엔 몇백 줄의 코드조차 작성 비용이 컸음
      2000년대식 SLOCount 도구(WebAssembly 버전)에 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
    • 나도 코딩 에이전트를 쓰면서 정보와 코드의 매핑 품질이 오히려 좋아진 경험이 있음
      리팩터링을 빠르게 반복할 수 있었기 때문임
    • 결국 병목은 의도를 기계에 전달하는 과정임
      AI가 점점 더 맥락을 이해하게 되겠지만, 그만큼 인간의 판단을 포기해야 함
      언젠가 기계가 완전히 의도를 파악하게 되면 인간은 루프 밖으로 밀려날 것임

  • 모든 개발 방법론의 핵심은 요구사항은 항상 변한다는 사실임
    그래서 좋은 코드는 “변경하기 쉬운 코드”임
    지금의 LLM 에이전트가 그런 코드를 만드는지는 의문임
    완전히 신뢰할 수 있을 때까지는 프로토타입 수준에 머물 것 같음

    • 실제 병목은 코드 작성이 아니라 의도를 명확히 전달하는 비용임
      명세가 불분명하면 테스트·가치 검증이 모두 어려워짐
    • 인간 엔지니어도 100% 안전하게 수정하진 못함
      테스트가 있어도 약 70% 정도의 확신만 있음
    • 나는 LLM을 세밀히 관리하며 기능 수정과 버그 수정을 자주 시킴
      직접 코딩보다 빠르고, 결과도 유지보수 가능한 코드로 나옴
    • 나는 이미 모든 커밋을 에이전트가 100% 생성함
      깨끗한 코드와 좋은 관행을 명시하면 충분히 유지보수 가능한 결과가 나옴
      결국 Garbage in, garbage out임
    • 하지만 어떤 사람은 LLM이 데모 수준까진 좋지만, 작은 수정에도 무너진다고 느낌

  • 내가 쓴 글(The Final Bottleneck)에서 말했듯,
    코드 작성 속도가 빨라졌지만 그 이후 단계가 따라오지 못함
    단순히 습관이 아니라 책임 구조·언어 설계·시스템 구조 전체가 바뀌어야 함

    • 모든 회사가 새로운 방식으로 일하긴 어려움
      정말 생산성이 10배 오른다면 이미 스타트업들이 시장을 뒤집었을 것임
    • LLM이 충분히 작고 싸지면, 앱에 내장되어 사용자별로 코드를 조정하는 시대가 올 것임
    • “왜 그렇게 빨리 코드를 써야 하는가?”라는 의문도 있음
      가능하다고 해서 반드시 해야 하는 건 아님
    • 오픈소스 개발자들이 비개발자도 빌더가 되는 시대를 이끌어야 함
      AI evals(measure-first-optimize-last, ai-evals.io) 같은 접근이 그 방향임
    • “그 속도로 계속 배포해야 하나?”
      기능 폭주는 누구도 원하지 않음

  • 코드 한 줄 한 줄이 부채(liability) 임
    LLM이 코드를 쏟아내는 시대에, 그 부채가 폭증함
    도구 자체는 나쁘지 않지만, 책임 없는 프로그램이 코드베이스를 재작성하는 구조는 위험함

    • 우리는 수십 년간 코드 배포에 검증·리뷰·롤백 체계를 쌓아왔음
      “코드가 싸다”는 건 생성이 싸졌다는 뜻이지, 배포 승인 비용은 여전히 큼
      판단 단계를 생략하면 생산성 향상이 아니라 통제 공백(control gap) 이 생김
      빠르다고 마스터키를 주는 건 위험함
    • 작성도, 유지보수도 여전히 비쌈
      어느 쪽이든 싸진 않음

  • 나도 이 의견에 거의 전적으로 동의함
    코드 작성은 싸졌지만, 검토와 검증 비용은 여전히 큼
    특히 수백만 줄짜리 모노레포에서는 테스트 가능성을 높이는 게 핵심임
    이런 논의가 트위터의 과열된 분위기 속에서 균형을 잡아줘서 고맙게 느껴짐

    • 나도 같은 관찰을 함
      코드 churn은 쉬워졌지만, 품질 검증이 새로운 도전이 됨
      LLM이 만든 대량의 변경은 미묘한 실패를 낳고, 그 흐름은 멈추지 않음

  • 코드는 싸지 않음
    토큰 비용도 있고, 실제 비용 구조는 아직 불확실함
    수익이 없는 스타트업들이 GPU 공급망을 독점하는 상황이라 데이터가 부족함

    • 작성은 싸졌지만 유지보수는 동일함
      LOC가 늘수록 부채도 늘어남
      생각에서 실행까지의 거리는 짧아졌지만, 여전히 코드 자체는 책임임
    • 로컬 모델이 비용의 하한선을 보여줌
      지금은 보조금 덕에 싸지만, 하드웨어·전력·인력 비용이 내려가면 더 싸질 수도 있음
답변달기