# 다가오는 루프 > Clean Markdown view of GeekNews topic #30799. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30799](https://news.hada.io/topic?id=30799) - GeekNews Markdown: [https://news.hada.io/topic/30799.md](https://news.hada.io/topic/30799.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-25T00:48:08+09:00 - Updated: 2026-06-25T00:48:08+09:00 - Original source: [lucumr.pocoo.org](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/) - Points: 1 - Comments: 1 ## Topic Body - 코딩 에이전트 바깥에서 작업 큐와 하네스가 반복을 관리하는 **하네스 레벨 루프**가 에이전트 엔지니어링의 새 중심 패턴으로 떠오르고 있음 - 모델이 오래 자율 실행될수록 강한 불변식보다 **국소적 방어**와 fallback을 덧붙이기 쉬워, 장기 유지 코드에서는 설계 이해와 통제가 흔들릴 수 있음 - 반대로 코드 포팅, 성능 실험, 보안 스캔, 연구처럼 결과를 검증하거나 버리기 쉬운 영역에서는 **기계적 반복**이 이미 강하게 작동함 - 공격자와 리포터가 루프를 돌리면 유지보수자도 triage, 재현, 대응에 기계를 써야 하는 압박을 받으며, curl 사례는 AI 생성 리포트가 만드는 부담을 보여줌 - 앞으로의 과제는 루프 사용 여부가 아니라, 그 안에서도 **인간의 판단**과 엔지니어링 규칙, 책임 있는 감독, 이해 가능한 아키텍처를 유지하는 것임 --- ### 코딩 에이전트 바깥에서 도는 루프 - 코딩 에이전트 내부에는 이미 모델이 도구를 호출하고, 결과를 반영하고, 파일을 읽고 수정하고, 테스트를 실행한 뒤 답을 내는 **에이전트 루프**가 있음 - 새롭게 두드러지는 패턴은 그 바깥의 **하네스 레벨 루프**임 - 작업이 큐에 들어감 - 기계가 작업을 집어 시도함 - 멈춘 뒤 하네스가 실제로 끝났는지 판단함 - 끝나지 않았다면 같은 세션에 메시지를 주입하거나, 수정된 컨텍스트로 새 세션을 시작하거나, 다른 기계에 작업을 넘김 - 이 바깥 루프는 모델이 보통 “끝났다”고 말할 지점 이후에도 작업을 계속 살아 있게 만듦 - 루프 자체는 새롭지 않지만, 최근 에이전트 엔지니어링과 Twitter 담론에서 더 자주 보이기 시작함 - [Pi](https://pi.dev/) 위에서도 이런 흐름이 일부 나타나며, Pi는 하네스이기 때문에 이런 실험의 중심에 놓임 ### 오래 유지할 코드에서 생기는 불편함 - 깊이 신경 쓰는 코드에는 아직 이 방식이 잘 맞지 않음 - 핵심은 **취향과 통제**임 - 배포하는 코드를 이해하고 싶음 - 압박 상황이나 다른 사람과의 논의에서, 먼저 기계에게 설명을 시키지 않고 시스템 동작을 설명할 수 있어야 함 - 현재로서는 코드 이해가 여전히 중요함 - 손을 떼고 생성된 코드, 특히 루프에서 나온 코드에는 반복되는 문제가 있음 - 너무 방어적임 - 너무 복잡함 - 국소적 추론에 머묾 - 강한 불변식을 피함 - 잘못된 상태를 불가능하게 만들기보다 fallback을 추가함 - 중복 코드와 나쁜 추상화를 만들고, 불명확한 설계를 더 많은 장치로 덮음 - Claude Code와 Fable 같은 조합은 한 문제를 30분 이상 끊기지 않고 작업할 수 있어, 이전보다 **human in the loop**가 줄어듦 - 현재 손을 뗀 하네스 방식의 코드 품질은 지난가을보다 더 나빠졌다고 느껴질 정도이며, 적어도 이 취향에서는 개선이 거의 보이지 않음 ### 루프가 모델의 습관을 증폭함 - 모델은 국소적 실패를 보면 국소적 방어를 추가하는 경향이 있음 - Andrej Karpathy는 모델들이 예외를 “치명적으로 두려워한다”고 [말한 바 있음](https://x.com/karpathy/status/1976082963382272334) - 중요한 불변식이 있는 시스템, 특히 영속 데이터 포맷이나 핵심 인프라에서는 “모든 malformed case를 처리”하는 방식이 올바른 수정이 아닐 수 있음 - 더 나은 방향은 malformed case를 표현할 수 없게 만들거나 처음부터 쓸 수 없게 만드는 것임 - LLM은 많은 수동 조향이 있어도 이런 코드를 자연스럽게 내놓기 어렵고, 불가능해진 오류까지 처리하려 할 수 있음 - 이 습관을 루프 뒤에 두면 문제가 **증폭**됨 - 각 반복이 작은 방어를 하나씩 더함 - 시스템은 더 견고해 보이지만 점점 이해하기 어려워짐 - 손을 더 뗄수록 이런 경향이 커짐 - 명확한 지침 없이 주니어에게 이런 도구를 주면 나쁜 실천을 학습시킬 수 있음 - 이유를 물으면 그럴듯하게 자기 선택을 변호할 수 있음 ### 루프가 잘 맞는 영역 - 루프 패턴은 이미 일부 영역에서 매우 잘 작동함 - **코드 포팅**은 대표적인 사례임 - [Bun 일부를 Zig에서 Rust로 옮기는 작업](https://ziggit.dev/t/bun-is-being-ported-from-zig-to-rust/15330) 같은 대규모 자동 포팅 사례가 있음 - MiniJinja를 Go로 포팅하는 데도 성공적으로 사용됨 - 성능 탐색에도 잘 맞음 - 기계가 실험을 시도함 - 벤치마크를 실행함 - 실패를 버림 - 계속 탐색함 - 보안 스캔과 거의 모든 종류의 연구에도 자연스럽게 맞음 - 복잡한 문제 공간을 탐색하고 결과를 보고하게 할 수 있음 - 반드시 오래 남을 코드를 커밋할 필요가 없음 - 성공적인 사례들의 공통점은 산출물이 오래 유지될 필요가 없거나, 기존 코드를 변환하거나, proof of concept·아이디어·발견·기계적 변환에 가깝다는 점임 - 하네스에 필요한 것은 완전히 객관적이거나 이진적인 신호가 아니라 다음 반복을 밀어줄 만큼 유용한 **신호**임 - 많은 성공 사례는 다른 LLM을 judge나 orchestrator로 씀 - 기계적 번역은 binary test case로 검증할 수도 있고, LLM으로 판단할 수도 있음 - Claude Code는 전체 실험 워크플로를 만들고 실행하는 데 점점 능숙해지고 있음 - 생성 코드가 지저분하더라도, 그것은 하네스의 판단 능력보다 모델의 문제에 더 가까움 ### 소프트웨어를 기계보다 유기체처럼 다루는 변화 - 지속될 코드를 같은 루프 방식으로 작성하는 것은 아직 편하지 않음 - 기존의 이상은 소프트웨어를 **결정적인 기계**처럼 이해하는 것에 가까웠음 - 한 층을 벗기면 더 깊이 이해할 수 있었음 - 비결정적으로 관찰되는 기계는 최적이라 보기 어려웠음 - 아키텍처는 더 많은 결정성으로 나아가는 것이 바람직했음 - 새 엔지니어도 복잡한 코드베이스를 탐색할 수 있게 만드는 것을 좋은 설계로 여김 - 잘 설계된 시스템에는 어디에 불변식이 있고, 어느 부분이 load-bearing이며, 어떤 변경이 안전한지 아는 엔지니어가 있었음 - 큰 소프트웨어는 이미 사람 머릿속에 다 들어가지 않으며, 분산 시스템은 의사가 증상을 보고 가설을 세우고 더 많은 테스트를 주문하듯 진단되는 면이 있음 - LLM은 이 방향을 더 빠르게 밀어붙임 - 프로덕션 이슈가 나면 기계가 로그를 읽음 - root cause를 제안함 - 패치를 올림 - 다른 기계가 리뷰하고, 때로는 인간 감독 없이 main에 반영함 - 이런 방식은 강력하고 매력적이지만, 사람은 시스템 전체를 예전과 같은 방식으로 이해하지 못할 수 있음 - 다루고, 모니터링하고, 안정화하지만 반드시 이해하지는 않음 - 모든 코드가 인간 저작을 필요로 하지는 않으며, 과거에도 더 나쁜 코드가 작성됐을 수 있음 ### 완전히 빠져나오기 어려운 압박 - 완전한 기계 주도 미래에서 **opt out**하기 어려울 수 있음 - 보안이 가장 명확한 사례임 - 자신이 루프로 소프트웨어를 만들지 않아도, 다른 사람은 그 소프트웨어를 대상으로 루프를 돌림 - 공격자는 기계를 계속 실행함 - 공격자가 아니더라도 보안 연구자가 자동화된 작업을 수행함 - 그 결과 실제 이슈와 노이즈가 함께 들어옴 - Daniel Stenberg의 curl 관련 [summer of bliss](https://daniel.haxx.se/blog/2026/06/15/curl-summer-of-bliss/)는 유지보수자가 이미 받는 압박을 보여줌 - curl의 핵심 개발에서 AI가 큰 역할을 하지는 않는 것으로 보임 - 그래도 유지보수자는 리포트에 압도되고 있으며, 그중 대부분은 AI 생성 리포트임 - 공격자와 리포터가 루프를 돌리면 방어자도 따라가야 함 - 반드시 직접 패치를 쓰기 위해서가 아닐 수 있음 - triage, 재현, 대응 압박 때문에 기계를 써야 할 수 있음 - 경쟁 압박도 비슷함 - 어떤 팀은 순수한 속도로 다른 팀보다 더 많이 만들 수 있음 - 작은 그룹이 기계를 잘 조율하면 프로젝트가 갑자기 빨라질 수 있음 - 어떤 스타트업은 예전에는 50명이 필요하던 일을 5명으로 할 수 있음 - 누군가는 제품을 대상으로 루프를 돌려 “다른 것처럼 만들라”고 시킬 수 있음 - 모든 소프트웨어가 똑같이 영향받지는 않음 - 일부 영역은 허술함을 벌하고 신뢰와 책임을 요구함 - 많은 소프트웨어에서는 속도, 빠른 실험, 넓은 커버리지가 매우 중요함 ### 루프가 만드는 새로운 의존성 - 루프가 만든 도구는 단순한 일회성 비용이 아니라 지속적인 **인지적 의존성**을 만들 수 있음 - 과거 소프트웨어 개발은 컴파일러처럼 비용이 드는 도구에 의존했지만, 지금의 도구는 계속 접근해야 하는 시스템에 가까움 - 코드베이스가 루프로 만들어지고, 루프로 리뷰되고, 루프로 패치되고, 루프로 유지된다면 같은 수준의 시스템 접근이 끊겼을 때 문제가 생김 - 무역 제한으로 가장 강력한 모델 접근이 사라질 수 있음 - 비용이 감당하기 어려워질 수 있음 - 팀이 기계 없이 코드를 이해하는 마지막 능력을 잃을 수 있음 - 사람에게 유지보수가 어려운 정도를 넘어, 기계 참여를 유지보수 모델의 일부로 전제하는 코드베이스가 생길 수 있음 - 이미 일부 변화가 보임 - 완전히 설명할 수 없는 코드를 merge하는 사람이 늘어남 - issue report나 채팅 논의를 기계가 제공한 컨텍스트로 보강하거나 재작성함 - 요약과 맥락화를 기계에 의존함 - LLM을 거쳐 대화하는 사람이 더 자주 보임 - 이것이 반드시 틀렸다고 단정할 수는 없지만, 기존 방식과는 큰 변화임 ### 앞으로 필요한 하네스와 도구 - 더 많은 루프를 조율하는 것만으로는 충분하지 않음 - 변경, 오케스트레이션, 에이전트를 더 잘 시각화해도 이해가 자동으로 회복되지는 않음 - 필요한 방향은 둘 중 하나임 - 인간을 다시 루프 안으로 충격적으로 끌어들이고, 루프의 변경을 장기적으로 읽을 수 있게 만드는 방법 - 점점 복잡해지는 시스템을 더 잘 조합하는 방법 - Pi에 대한 생각도 바뀌고 있음 - Pi는 조심스러웠고, 그 조심스러움은 좋음 - 모든 상호작용이 따라가기 어려운 기계 떼의 변경으로 변하는 미래는 원하지 않음 - Pi가 스스로 쓰는 소프트웨어 경쟁을 이기기 위해 유지보수 불가능한 혼란이 되는 것도 원하지 않음 - Pi가 이런 엔지니어링을 장려하는 것도 원하지 않음 - 그래도 Pi는 하네스이며, 하네스는 새로운 실험의 중심에 있음 - 코딩 작업 큐, 에이전트 오케스트레이션, subagent, durable session은 점점 더 중요해질 것임 - 루프를 맹목적으로 받아들이지 않는 사람도 실험을 시작해야 함 - 이 미래를 **경계 안에 두고 버틸 수 있게** 만들 방법을 이해해야 하기 때문임 ### 루프를 통제하는 문제 - 하네스 루프를 받아들이면, 일이 언제 끝났는지 하네스가 결정함 - 에이전트 루프에서는 모델이 결국 “done”이라고 말하고 사람이 리뷰함 - 그 전에도 보통 사람이 중간에 조향함 - 사람은 관여하고, 그 과정에서 배움 - 하네스가 운영하는 루프에서는 사람의 역할이 불명확해짐 - “done” 신호도 의미를 잃고 다른 기계가 판단할 메시지가 됨 - 사람의 역할은 메신저에 가까워질 수 있음 - 현재 이런 방식으로 만들어진 코드 상당수는 마음에 들지 않고, AI 지원으로 만들어진 소프트웨어와의 상호작용도 즐겁지 않음 - 루프는 강력하지만 책임을 점점 제거하고, 현재로서는 기계에 굴복하도록 부추기는 면이 있음 - 그럼에도 루프의 미래는 올 것으로 보임 - 아주 작은 팀이 불가능해 보이는 속도로 구축하는 사례가 이미 보임 - 코드베이스는 더 모호하고 혼란스러운 유기체처럼 변하고 있음 - 그런 코드베이스는 동시에 유용하고 지저분함 - 앞으로의 질문은 “루프를 돌릴 것인가”가 아니라 다음에 가까움 - 루프 속에서 판단을 포기하지 않는 방법 - 좋은 엔지니어링 규칙을 유지하는 방법 - 책임 있는 인간이 계속 감독할 수 있게 하는 방법 - 제정신을 유지할 수 있도록 코드 아키텍처를 다시 생각하는 방법 ## Comments ### Comment 60273 - Author: neo - Created: 2026-06-25T00:48:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48643180) - 루프는 미리 원하는 바를 충분히 이해하는 데 시간을 썼을 때 작동함. 전제는 **명확성**이고, 주니어 동료에게 넘길 수 있을 만큼 신중한 명세를 쓸 수 있을 정도여야 함 보통 그걸 이해하기까지는 망가진 엉성한 버전을 5~6번 거쳐야 함. 이 5~6번의 시행착오는 가속할 수 없고, 어떤 에이전트 기술도 인간 두뇌가 생각하는 시간을 피하게 해주지 못함. 그래서 대부분의 시간은 “내가 원하는 걸 모르겠다, 코드를 읽고 쓰고 만져봐야겠다”와 “이제 충분히 지나서 원하는 걸 아는 것 같다” 사이를 오가며 보냄. 스스로를 속이기 매우 쉽지만, 정말로 원하는 바를 알게 된 뒤에야 루프를 쓸 수 있음. 많은 사람이 에이전트로 앞질러 갈 수 있다고 생각하지만, **이해와 명확성**은 흉내 낼 수 없고 그 단계를 건너뛴 사람은 고통스러울 정도로 티가 남 - Codex에게 내 pi 세션을 모두 추출하는 도구를 만들게 했음. 프롬프트와 하위 에이전트 대화를 필터링해야 했고, 그다음 내가 만드는 패턴을 분석시켜 바깥쪽 **가이드 생성 프롬프트**의 흐름도로 바꿈 원하는 걸 오래 고민할 필요는 없었고, 그냥 그걸 하길 원했음. 결과는 아직 섞여 있고 섬세한 코드베이스를 맡길 정도로 신뢰하지는 않지만, 만들고 있는 게임에서는 확인에 쓰는 시간이 이전의 1/5로 줄었음. 꼭 좋은 일만은 아님. 시간을 덜 쓰면서 좋은 아이디어를 놓치고 있을 가능성이 큼. 다만 전에는 프롬프트가 기계적으로 `#now-do-this`, `#now-review-that`이 되었고 제안의 90%가 맞는 상태에서 정체돼 있었음. 이제는 “어려운 것부터 하고, 진행하면서 정리·리팩터링하라”와 첫 반환 뒤 “작업을 되돌아보라”를 자동으로 상기시켜 남은 문제를 털어놓게 한 뒤, 그걸 가이드 생성 프롬프트에 넣어 새 작업을 뿌리면 됨 - 망가진 버전 5~6개를 거쳐야 한다는 데 전적으로 동의함. 다만 내가 좋아하는 방식으로 대부분을 처리해준다고 믿을 수 있는 **하네스**(프롬프트 + 스킬 + 모델)를 찾고 나서는, 그 과정의 코딩·탐색 부분은 빨라졌음 반복은 빨라졌지만, 그 엉성한 버전들을 거치는 데 드는 노력은 거의 비슷함. 여전히 어떤 아이디어, 원칙, 설계가 해법에 맞는지, 다음에 뭘 시도할지 이해하고 내 정신 모델을 조정해야 하기 때문임. 결국 더 짧은 시간 안에 더 많은 정신적 노력을 쓰는 느낌이고, 코드 작성에서 조금 절약되는 정도임. 숙련되면 코드 타이핑 자체는 애초에 큰 비중이 아니었음. “그저” 프롬프트를 쓰고 코드를 읽는 것 같은데도 똑같이 지치거나, 압축된 반복 주기 때문에 더 지칠 때도 있음 - 이제 매일 이런 일을 겪고 있고, 낙담스럽고 걱정됨. 완전히 설명할 수 없는 코드를 더 많이 병합하는 이유는, 예전에는 코드 작성과 협업적 기술 계획으로 쌓던 **정신 모델**을 이제 코드 리뷰에 맡기고 있기 때문이라고 봄 코드 리뷰는 이 목적에 맞지 않음. 다만 교육학을 참고한 구조화된 연습을 코드 리뷰에 붙여서, 마찰과 이해 사이의 균형을 더 잘 맞출 수는 있다고 생각함. 이런 연습을 테스트해줄 도움을 찾고 있음 - 효과적으로 **코드 리뷰**하는 능력은 코드를 쓰는 것보다 훨씬 어려움. 변경이 시스템의 다른 부분에 어떤 영향을 주는지 좋은 지도가 없으면 사실상 도장 찍기 의식에 가까움 GitHub의 빈약한 PR UI도 도움이 안 됨. 직접 바뀌지 않았지만 영향을 받는 코드베이스 주변을 탐색해서 문제를 찾고 강조할 도구가 제한적임 - [https://pages.cs.wisc.edu/~remzi/Naur.pdf]() - 당신 제품이 뭔지 궁금함. 에이전트 무리가 인간 기준의 100배 수준으로 개발한 제품이 어떤지 꼭 보고 싶음. 굉장할 것 같음 - 이런 코드는 **보안 취약점**으로 가득한 경우가 많음. 해킹 위에 해킹을 쌓은 꼴이고, 1천 줄로 더 안정적으로 만들 수 있었던 일을 이상한 대체 경로로 가득한 10만 줄 코드로 끝내게 됨 잘못된 경계 조건을 대체 경로로 처리하기보다 불가능하게 만드는 시스템을 선호해야 한다는 원문의 말은 매우 중요함. 대체 경로 방식은 대체 경로 위에 또 대체 경로를 구현하게 만들고, 각 대체 경로는 코드량을 기하급수적으로 늘리며 어쩐지 항상 새 문제를 만듦. 거의 “시스템 설계의 일반 법칙”이라고 불러도 될 정도임. 대체 경로는 실패 위험을 낮추지만, 실패가 실제로 일어나면 더 복잡하고 해롭게 만듦. 소프트웨어 엔지니어로서는 AI가 만드는 새 코딩 환경이 마음에 듦. 빅테크가 나를 위한 무한한 일을 만들어줬기 때문임. 인간 개발자는 코드 실행의 핵심 구성 요소가 되었고, 때때로 반드시 발생할 거의 무한한 어려운 미처리 예외를 처리하기 위해 항상 대기해야 함. 이제 소프트웨어 엔지니어는 노동자라기보다, 대부분 책상에 앉아 커피를 마시다가 드물게 문제가 생기면 개입하는 **보안 요원**에 가까워짐 - 몇 달째 말해온 것과 이어짐. LLM은 **작업 완료**에는 뛰어나지만, 미감과 취향에는 약함 일에는 두 종류가 있음. 하나는 목표 지향 작업으로, 달성할 목표가 있고 거기에 이르는 방식은 별로 중요하지 않음. 보안이 완벽한 예임. 시스템을 익스플로잇하려면 익스플로잇이 아름다운지는 거의 신경 쓰지 않고, 그저 극비 핵 계획에 접근하고 싶을 뿐임. 연구도 비슷해서, “연구 품질” 코드는 AI 시대 이전부터 악명 높게 엉망이었음. 다른 하나는 **취향 지향 작업**임. 큰 코드베이스에 기능을 추가할 때 목표가 그 기능 추가라고 생각하지만, 실제로는 아닌 경우가 많음. 코드베이스가 앞으로의 변경을 잘 받아들이게 유지하는 것이 그 특정 기능보다 훨씬 중요하고, 여기에는 취향이 필요함. 유지보수성과 코드 품질은 동의어가 아니며, 코드 품질은 수단일 뿐이고 그 목적은 유지보수성임 - 많은 조직이 코드 품질과 유지보수성을 전혀 우선순위로 두지 않는 세계로 빠르게 이동 중임. Claude가 코드를 쓸 거라면 그 코드가 “유지보수 가능”하거나 “품질이 좋은지”가 중요할까? 아니라는 관점임. 작동하고 빠르면 된다는 식임 - LLM이 자연스럽게 잘못된 경우까지 처리하려 드는 문제는 많은 PR 리뷰에서 싸워온 부분임. 특히 이미 작성된 뒤에는 과도한 **널 검사**가 해롭다고 설득하기가 매우 어려움 더 나은 모델링, 그리고 합 타입을 허용하는 언어가 아니라면 이런 “산탄총 파싱”에 보편적으로 먹히는 반론을 아직 찾지 못했음. 어쩌면 정말 큰 문제가 아닐 수도 있음. 하지만 코드베이스를 실제로 읽고 리팩터링할 때는 이런 불필요한 검사를 관리하는 게 늘 답답했음. 일단 들어간 뒤에는 로깅이나 광범위한 조사를 먼저 추가하지 않고서는 안전하게 삭제하기 거의 불가능할 때도 있음 - 자주 통하는 논리는 선택값이 사실상 프로그램이 가질 수 있는 가능한 상태 공간을 **분기**시킨다는 것임. 상태 공간이 커질수록 코드를 추론하고 유지보수하기 어려워짐 이것이 바로 바람직하지 않은 상태를 표현 불가능하게 만든다는 말의 핵심이기도 함 - AI 코드 리뷰는 과도하고 망상적인 **방어적 편집증**을 부추김. 함수 깊숙한 곳에서 삼중 널 검사를 하는 건 기술적으로는 실제 위험일 수 있지만, 실제로는 그 함수를 호출하거나 호출할 수 있는 모든 함수에서 이미 널 검사를 했기 때문에 절대 도달해서는 안 되는 경우가 많고, 굳이 방어할 가치가 없을 수 있음 - 얼마나 불가능한 경우를 말하는지가 중요함. 나는 꽤 **방어적 프로그래밍**을 하는 편임 지금은 아무것도 이 함수에 음수를 보내지 않더라도, 미래의 코드 변경으로 그 가정이 깨지는 게 얼마나 어려울까? 명확한 오류가 최선이라고 늘 생각했음. 코드에 익숙하지 않은 사람도 입력의 유효 범위에 어떤 가정이 있는지 알 수 있고, 불가능한 이상치를 고려할 필요가 없어짐 - 내 병목은 **명세**에 있음. 에이전트 루프는 이제 나에게 덜 중요한 문제가 됨 만들고 싶은 것에 대한 명확한 이해를 얻고, Claude Code의 계획 모드에서 실행 가능한 명세를 쓰는 것을 목표로 전달하면, 에이전트가 구현에 들어갔을 때 대체로 매우 좋은 결과가 나옴. 하지만 효과적인 이 전략은 명세를 쓰는 부담을 나에게 크게 줌. 에이전트는 각 명세를 대개 훌륭히 처리하고 코드 리뷰 기반 후속 작업도 보통 2~3번이면 되지만, 곧 다시 명세가 필요한 단계로 돌아옴. 또 내가 자리를 비웠을 때 에이전트가 한 작업을 끝냈고 파일이 겹치지 않아 충돌이 없는 기존 명세를 시작할 수 있어도, 새 브랜치를 만들고 시작해도 된다는 걸 모름. 자기 전 “작업 X를 하고 완료·푸시한 뒤 작업 Y를 시작하라”고 말하곤 하지만 그 이상은 잘 안 됨. 종종 Y를 시작하다 질문이 생기고, 그 뒤 에이전트는 남은 시간 내내 멈춰 있음. 마지막 문제는 위와 결합된 의존성임. 예를 들어 오늘은 백그라운드 작업 처리기를 작성했는데, 당연히 이후 작업의 잡들은 그 시스템을 필요로 함. 이런 일이 꽤 자주 생김. 구현 중 결정된 세부사항을 반영하려면 명세 자체도 구현 후 갱신해야 함. 그래도 이제 바깥쪽 루프가 필요해지기 직전임. 관문은 거의 전적으로 명세 작성과 PR 리뷰에 있음. 그 관문이 중요하지 않은 곳에서는 에이전트가 계속 굴러가길 원함. 덧붙여, 우리에게는 나쁘더라도 LLM에게 더 좋은 도구를 쓰기 시작해야 한다고 강하게 믿음. 예를 들어 Rust는 컴파일러가 너무 엄격해서 나에게는 성가시지만, LLM에게는 훌륭함 - 바로 이런 방식이어야 함. 훌륭함. 지난 20년 동안 빨리 만들자는 흐름 속에서 축소돼온 시스템 엔지니어링의 가장 중요한 부분임 이제 만들기가 더 자동화됐으니, **명세와 시스템 설계**가 다시 중요한 선두 역할을 할 수 있음. 엔지니어링과 품질이 돌아올지도 모름 - 내 코딩 경험과도 맞고, AI가 아직 코딩을 해결하기까지 갈 길이 멀다고 몇 년간 말해온 기대와도 맞음. 프로그래밍의 어려운 부분은 키를 눌러 파일에 코드를 넣는 게 아니라, **문제를 이해**하고 깔끔하고 확장 가능한 좋은 해법을 떠올리는 것임 AI는 기술적으로 작동하는 괜찮은 해법을 만드는 데는 뛰어나지만, 해법에 대한 좋은 비전을 갖는 데는 꽤 약함. 아이디어를 주고받고 탐색하면서 이해를 높이는 데는 여전히 매우 유용하지만, LLM이 구현할 좋은 명세를 쓰는 일이 직접 코드를 쓰는 것보다 훨씬 쉽지는 않음 - 아래가 그 문제를 해결할 수 있음 [https://www.aihero.dev/skills-handoff]() `/handoff`는 내가 새로 가장 좋아하는 스킬임 [https://www.youtube.com/watch?v=dtAJ2dOd3ko]() - “매우 좋은 결과”를 어떻게 정의하는지가 궁금함. 성공의 정의에 **깔끔하고 유지보수 가능한 코드**가 포함되는가? 나는 계속 루프 안에 있어야 함. 내 코드는 수천 명의 사용자에게 배포되기 때문에, 어떤 문제든 증폭됨 - “명세 작성”이 프로그래밍의 **본질적 복잡성**임. 결국 은탄환은 없다는 말임 에이전트가 있든 없든, 천공카드든 인터프리터든, 끝내 프로그래밍은 프로그래밍임 - LLM의 가장 큰 코드 냄새는 “모든 잘못된 경우를 처리”하려고 하고, 이제는 불가능한 오류까지 처리하려 든다는 점임. 왜 그렇게 집착하는지 모르겠음 Python에서는 완전히 타입 검사되는 코드베이스에서, 해당 속성이 있다고 정의된 타입에 `hasattr` 검사를 붙이는 식으로 자주 나타남. 왜 이러는 걸까? 사전 학습 때문인지, 강화 학습 때문인지 궁금함. 후자라면 연구소들이 고쳐줬으면 함 - 아마 누락된 오류 처리보다 **불필요한 오류 처리** 쪽으로 실수하는 편을 택하기 때문일 것임. 학습에서 런타임 오류를 강하게 벌점 처리할 가능성이 큼 - 대부분은 **학습 데이터** 때문이라고 봄. 나도 “잘못된 상태를 표현 불가능하게 만들자” 팀임 HN에서는 이 얘기가 많이 나오지만, 오픈소스든 직장이든 내가 작성하지 않은 코드베이스가 이걸 정말 잘하는 걸 보면 아직도 놀람. 대부분의 프로그래머는 오류가 발생하지 않게 만들고 데이터가 그 사실을 반영하게 하기보다, 오류 메시지가 튀어나오는 지점에서 조각을 주워 고치는 식으로 생각함. “대부분”이라고 한 건 현재 AI에도 이런 사고방식 자체의 문제가 있다고 보기 때문임. 인간이 코드베이스를 마지막 단계에서 이해하는 수준, 즉 보장의 흐름을 전체적으로 이해하는 수준을 지금 AI에게 주기는 어려움. 원시 코드 수준에서는 이런 보장이 컨텍스트 창을 쉽게 터뜨릴 만큼 많은 코드에 걸쳐 있는 경우가 많음. 메모리식 파일로 요약하려 해도 문제가 있음. 보장에 대한 텍스트가 적혀 있다고 해서 AI가 올바른 정보를 꺼낸다는 뜻은 아니며, 인간도 코드만 읽고는 마찬가지임. AI에게 이런 이해를 주는 것이 “불가능”하다고는 말하지 않겠지만, 설령 이해하게 만들더라도 AI의 작업 방식은 그 이해에 자주 반대로 작동함. 내 해결책은 대체로 AI가 이걸 이해하길 포기하는 것이었음. 보통 사람들이 하듯 문제 해법을 프롬프트로 만들고, 나쁜 잘못된 상태를 표현 불가능하게 만들고 싶으면 필요한 리팩터링 과정을 AI에게 단계별로 시킴. 아주 작으면 직접 함. 맵/딕셔너리, 배열, 문자열, 정수로 가득한 코드를 더 철저히 타입화하도록 단계적으로 시키면 실제로 꽤 잘함. 아무리 자세히 써도 단일 프롬프트로 좋은 설계가 나오는 경우는 많지 않았음. 두 개의 별도 작업으로 다루는 편이 잘 맞음. 그리고 타입의 차이를 주의 깊게 봐야 함. AI는 `.JustSetItAndIgnoreAllThePreAndPostConditions(string)` 같은 메서드를 몰래 끼워 넣는 걸 좋아함. 현장에는 “오류 상태를 표현 불가능하게 만들도록 잘 구조화된 타입에 나중에 유지보수자가 와서 모든 걸 깨는 `JustEffingDoIt` 메서드를 추가한” 학습 데이터가 많을 것 같음. 가장 좋은 방어 중 하나는 이런 타입을 자체 파일에 두고, 추가된 모든 메서드를 쉽게 훑어보며 그런 짓을 하면 바로 잡는 것임. 문서에 하지 말라는 경고와 유지되는 사전·사후 조건을 잔뜩 적어봤지만 변화는 미미했음 - 학습 세트에 있는 코드베이스의 압도적 다수가 완전히 타입 검사되지 않았거나, 전혀 깨끗하지 않기 때문임. 혹은 Stack Overflow 조각들이라 기존 맥락이 없어서 널 검사가 유효하지 않다고 가정할 수 없는 것일 수도 있음 - 정말 공감함. 모든 dataclass에 `getattr`을 쓰는 건 기묘한 선택임 - 학습된 패턴과 맞기 때문임. AI는 코드를 이해하지 못함. 실제 **논리 흐름**을 추론할 수 없고, 패턴만 다룰 수 있음 - 코드는 정보 시스템에 대해 공유되고 쌓인 이해의 일부임 이런 루프가 우리 모두를 지속적으로 밀려오는 소프트웨어의 파도 속에서 움직이게 만든다면, 가장 높은 수준의 논리적 정보 시스템 설계에서는 결국 인간의 판단과 비즈니스 요구사항 균형이 전부가 됨. 회사나 시장의 특정 틈새에 맞추려면 모든 프로그래머가 비즈니스 분석가, 시장 조사자, 사업가가 되어야 함. 단, AI 도구가 잘 “덜컹거리지” 못하는 특정 틈새나, 보조금이 붙은 AI 토큰 시대가 끝나 이 모든 루프가 너무 비싸지는 경우는 예외임. 이는 전문가 시스템과 Symbolics Lisp 머신의 반복처럼 느껴짐. 잠깐 동안 우리가 마주친 사실은, 코드 자체가 무언가를 못 한다기보다 회사의 조직 구조가 결국 소프트웨어에 그대로 실리므로, 회사 조직을 바꿀 수 없다면 소프트웨어의 유연성에도 한계가 있다는 점이었음. 데이터 흐름도와 도메인 지식, 도메인 모델링, 보편 언어가 우리가 품질, 기능, 비기능 표준과 관례를 정하는 **메타언어**가 될 수 있음. “루프를 도는 clanker”들이 “완료”라고 말하기 전에 데이터·동작·성능 계약을 충족하게 만들어야 함. 이제 “완료”는 컴파일되는 코드, 빌드되는 코드, 배포되는 코드, 심지어 운영에 올라간 코드만을 뜻하지 않음. 사용자 요구, 운영자 요구, 유지보수자 요구를 모두 충족하는 코드여야 함. 그래서 쓰이는 언어는 우리 모두를 문법을 아는 사람보다 비즈니스 분석가와 소프트웨어 아키텍트에 더 가깝게 만들 수 있음. UML의 복수와 선언형·논리형 설계·BDD의 귀환일까? 오타 검사는 gemma4-12b로 했지만 메시지를 바꾸게 하지는 않았음 - 언제부터 내가 루프 안에 억지로 들어가 있지 않아도 되는지 계속 생각함. 개발자로서 코드 구조를 다듬고, 더 명확하게 만들고, 좋은 추상화를 생각하고, 모듈로 나누는 일을 정말 좋아함 거기서 즐거움을 느끼지만, 어느 순간 내가 제한 요인이 된다는 것도 이해함. 소프트웨어의 목적이 사람들에게 이익을 주는 것이라면, 코드가 어떻게 보이는지 여전히 신경 써야 할까? 지금은 답이 “그렇다”라고 생각하지만, 3년 뒤에는? 10년 뒤에는? - 소프트웨어가 계속 사람들에게 이익을 주길 원한다면, 답은 **그렇다**임 - 기술 외에는 별 의미를 느끼지 못하는 곳에 있다면 힘들 수 있음. 곧 더 충족감 있는 일로 향하는 **실존적 전환**이 올 것 같음. 순진한 생각일 수도 있고, 그냥 내가 나 자신에게 필요하다고 느끼는 것일 수도 있음 - 리팩터링은 언제든 에이전트에게 시킬 수 있음. 생각만 해도 지칠 만큼 큰 리팩터링도 해낼 수 있음 - 무언가가 판단을 많이 요구하고 “내가 깊이 아끼는 코드”라면, 여기서 말하는 방향에는 동의하기 어려움. 깊이 신경 쓰는 결정을 위임하려 하지 말아야 함 **에이전트 루프**와 하네스 루프라는 구분은 마음에 들지만, 미리 정확히 명세할 수 있는 것만 위임해야 함. 내 경우 대개 반복 가능한 작업, 예를 들어 “X를 어떻게 했는지 보고, Y에도 그렇게 해” 같은 것들이고, 이는 본질적으로 예측 가능한 일임. 내 판단이 빠지면 결국 내가 “아니”라고 할 일이라면, Armin이 말한 에이전트 루프 안에서 협업하는 쪽으로 내려와야 함. 그건 완전히 괜찮음. 빠르면서도 안전함. AI 코딩 도우미 이전에도 가끔 엄청나게 생산적인 엔지니어가 팀에 들어오곤 했음. 동료들은 “너희가 그걸 다 해낸 건 팀에 X가 있어서잖아!”라고 부러워했지만, 그런 사람을 곁에 두는 저주를 겪어보진 못한 것임. 완벽히 정렬돼 있지 않으면, 그들은 엄청난 속도로 잘못된 방향으로 달려감 - 깊이 신경 쓰는 결정을 위임하지 말아야 함. 아니면 그 결정을 넣을 **결정론적 방법**을 찾으면 됨 - 정확함. 고도로 숙련됐다고 생각하는 사람에게도 외주 주지 않을 일이라면, 왜 기계에 외주 주겠음? - 이게 실제로 무슨 뜻인지 모르겠음. 더 큰 그림을 암시하도록 설계된 것 같은 추상 개념을 늘어놓는 장황한 글일 뿐이고, 결국 AI가 코드를 써주게 하는 이야기임 앞으로 이렇게 되는 건가? 사실 우리는 생각의 리더가 아니라, AI 바보 무리를 정답 쪽으로 몰아가려는 유사 교사가 되어 가고 있는데, 여전히 사고의 리더처럼 보이려고 역할을 신비화해야 하는 건가? 그게 전부 **기술 허세**라는 걸 들키지 않으면서? - 이건 장황한 글도 아니고 추상적이지도 않음. 여기의 내용은 덜 감독되는 방식으로 “AI가 코드를 쓰게 하는 것”의 **2차 효과**에 관한 것임 글쓴이가 더 간결하게 다듬을 수는 있었겠지만, 현재 수준에서 독자가 내용을 이해하지 못한다고 해서 신비화가 일어나고 있다는 뜻은 아님 - AI 과대광고를 받아들이면 저렇게 떠들게 됨. Yegge는 더 심한 예임 - 소프트웨어 엔지니어링 분야가 둘로 갈라지고 있다고 확신함. 이것들은 실제 우려이고, **에이전트 루프**와 강한 AI 보조 작업 흐름을 써온 개발자에게는 말이 되는 일관된 논리임 나는 직장과 개인 프로젝트에서 원문이 말하는 바를 정확히 보고 있는데, 누군가는 이것을 “추상 개념을 늘어놓는 장황한 글”로 본다는 점이 무서움. 대다수가 지금 벌어지는 일을 전혀 모른다는 생각이 듦 - 예전 기술 블로그는 바로 실행 가능한 README 가이드처럼 읽혔음. 이 글은 읽으면서 “이 정보로 뭘 하라는 거지?”라는 생각이 들어 끝까지 못 읽었음 AI 분야에서 최신 최고 기술의 유통기한은 2주 정도임. Ralph Wiggum 루프를 따라잡지 못했는데, 이제는 시도하지 않길 잘했다고 느낌 [https://news.ycombinator.com/item?id=46682325]() - “실제로 무슨 뜻이냐”면, 더 많은 **토큰**을 쓰라는 뜻임