TL;DR

  • 코딩 에이전트는 모델보다 하네스의 설계와 설정에 문제가 있으며, 불필요한 인지 부담을 늘리고 좋은 마찰을 없애 코드 품질을 떨어뜨림.
  • 에이전트는 사용자에게 응답하거나 코드를 작성할 때 장황해 인지 부담을 유발하며, caveman, i-have-adhd, ponytail 같은 접근은 출력과 재작업 코드를 줄이는 일부 해결책임.
  • 주변 코드의 관례를 따르라는 지침은 사람이 지치고 에이전트는 지치지 않는다는 차이 때문에 저품질 코드가 코드베이스에 누적되는 자기 강화 피드백 루프를 만들 수 있음.
  • 에이전트는 훌륭한 개발자나 코더가 될 수 있지만, 맥락을 바탕으로 통계적으로 그럴듯한 출력을 만드는 모델이므로 엔지니어링의 절충과 장기적 결과를 판단하는 엔지니어를 대신할 수 없음.
  • 에이전트가 만드는 인지 부담, 기준 유지, 작업 방식과의 통합, 의사 결정의 문제를 각자의 작업 흐름에 맞게 살펴야 하며, 구체적인 해결책은 다음 편에서 다룰 예정임.

코딩 에이전트 하네스가 잘못 설계돼 있음

  • 코딩 에이전트는 기본 설정만으로는 제대로 작동하지 않음. 에이전트가 엉성한 코드를 만들지 못하게 하는 방법이나 코드 품질이 더는 중요하지 않다는 주장이 주된 대화 소재라면 분명 문제가 있음.
  • 학습 데이터에 평범하거나 나쁜 코드가 많고 대형 언어 모델(LLM)이 다음에 나올 가능성이 가장 높은 토큰을 예측한다는 점에 책임을 돌릴 수도 있음. 이런 지적은 사실이지만 사실상 해결하기 어렵고, LLM 사용에는 이런 문제를 완화하는 과정이 따름.
  • 문제의 핵심은 모델이 아니라 에이전트 하네스임. 에이전트형 코딩 하네스는 유용한 도구지만, 모두에게 대체로 맞도록 설정되고 기능이 과도하게 구축되며 출력과 속도에 치우쳐 실패하기 쉬운 조건을 만듦.
  • 지나치게 냉소적으로 보면 토큰을 더 쓰게 하려는 술책이라고 할 수도 있지만, 이는 AI가 우리 모두를 생산성 높은 10배 엔지니어로 만들고 새로운 생산성 황금기를 열 것이라는 통념, 즉 ‘기술 낙관주의자의 사고방식’에서 비롯된 결과라고 봄.
  • 이 문제를 이해하려면 마찰의 관점에서 살펴봐야 함. 마찰은 불필요한 노력이나 작업을 가로막는 불편을 뜻하지만, 맥락에 따라 좋은 마찰과 나쁜 마찰이 있으며 때로는 속도를 늦추는 것이 바람직함.
  • 하네스는 이 구분을 제대로 하지 못해 좋은 마찰을 없애는 한편 나쁜 마찰을 크게 늘림.

마찰이 소모를 낳음

  • 코드 읽기는 일반적인 글 읽기와 다른 뇌의 작동을 요구하며, 에이전트와 일하면 두 가지 사고 방식 사이를 계속 전환해야 함. 코드를 읽지 않는 경우는 일단 논의에서 제외함.
  • 에이전트가 사용자에게 응답하거나 코드를 작성할 때 지나치게 장황한 점도 나쁜 마찰이며, 상당한 인지 부담을 만듦.
  • 이를 해결하려는 접근으로 caveman, i-have-adhd, ponytail 등이 빠르게 등장함. 에이전트 출력을 읽기 쉽게 하고 다시 작업해야 할 코드의 양을 줄이는 올바른 방향이지만, 문제의 일부만 해결함.

엉성한 코드는 엉성한 코드를 낳음

  • Claude Code의 여러 시스템 프롬프트에는 Opus 5.5를 포함해 “주변 코드처럼 읽히는 코드를 작성하라. 주석의 밀도, 이름 짓기, 관용적 표현을 맞추라”는 지침이 있음. OpenCode 시스템 프롬프트의 ‘관례 따르기’ 항목에도 이에 해당하는 지침이 있음.
  • 사람은 지치지만 에이전트는 지치지 않으므로, 결국 기준에서 벗어난 코드가 들어감. 같은 일이 반복되면 저품질 코드 생성이 코드베이스에 내재되는 자기 강화 피드백 루프가 형성됨.
  • 코드베이스의 기준을 다시 높이는 비용이 지나치게 커지면, 코드를 아예 들여다보지 말아야 한다는 주장이 나오는 것도 놀랍지 않음.
  • 이를 해결하려고 에이전트에 더 많은 맥락과 사전 설계를 제공해 엔지니어처럼 만들자는 생각이 자연스럽게 뒤따름. 하지만 에이전트는 엔지니어가 아님.

에이전트 설정만으로 엔지니어가 만들어지지는 않음

  • 코딩 에이전트가 망가지는 주된 이유는 에이전트를 엔지니어로 만들려 하기 때문임. 에이전트는 훌륭한 개발자나 코더가 될 수 있지만 훌륭한 엔지니어는 될 수 없음.
  • 훌륭한 엔지니어는 자신이 선택하는 절충을 이해하고 프로젝트의 지속적인 개발이 효과적으로 이뤄지도록 보장함. 반면 LLM은 맥락에 따라 통계적으로 그럴듯한 출력을 만들며, 그 출력이 낳을 결과와는 분리돼 있음. 따라서 충분한 맥락을 제공하더라도 엔지니어링 결정을 대신 내릴 수 없음.
  • 모든 문제에 훌륭한 엔지니어가 필요한 것은 아님. 어떤 문제는 어떻게 해결하든 계속 저렴하게 처리할 수 있고, 어떤 해결책은 어차피 일회용임. 어려운 점은 어떤 문제가 그런 경우인지 판단하는 것이므로, 작고 비용이 적게 드는 문제를 찾아 바이브 코딩을 시도할 수 있음.
  • 에이전트에게 소프트웨어 엔지니어링을 ‘수행’하고 ‘알도록’ 설정하면, 엔지니어링이 중요하지만 다른 곳에 맡길 수 있다고 말하는 셈임. 이를 믿기 어려움.
  • 이는 완전히 새로운 주장은 아님. 하향식 설계를 위한 여러 계획 기술과 작업 흐름을 도입해 엔지니어링을 미리 수행하려 해왔음. 의사 결정에 대한 책임이 여전히 우리에게 있음을 인정하는 올바른 방향이지만, 양쪽 모두에 또 다른 나쁜 마찰을 만든다고 봄.
  • 지도는 영토가 아님. 우리는 지도를 만들어 에이전트에 넘기고, 비용이 많이 드는 코드 검토를 거친 뒤에야 지도가 틀렸음을 깨달음. 그러고는 다음에는 충분한 세부 사항을 담겠다고 다짐하지만, 완벽한 지도가 있었다면 이미 코드를 작성했을 것이라는 점을 깨닫지 못함.
  • 에이전트가 사소한 문제를 과도하게 설계하는 한편 실제로 필요한 엔지니어링은 해내지 못하는 진퇴양난에 갇힌 것은 아님. 다만 해결책은 현재의 방식과 달라질 것임.

나만의 에이전트

  • 아주 최근까지 사용하던 하네스 설정에는 거의 신경 쓰지 않았으며, 저장소 수준의 AGENTS.md 파일만 사용함. 기본 설정을 오래 사용하면서 그 위에 쌓여 있는 근본적인 문제를 익힐 수 있었음.
  • 이 문제를 해결할 단 하나의 방법은 없다고 봄. 다행히 특별히 어려운 문제도 아니며 많은 노력이 필요한 것도 아님. 사람마다 다르므로 해결책은 서로 달라야 함.
  • 막막한 상태로 남겨두려는 것은 아님. 공통된 문제에는 공유되는 근본 해결책이 있지만, 실제 구현 방식은 사람마다 다름.
  • 그렇다면 무엇이 문제이며 어떤 질문을 해야 하는가?
  • 에이전트는 피할 수 있는 인지 부담을 늘리는 대신 출력량을 키우는 쪽으로 치우침. 작업 흐름에서 불필요한 인지 부담을 어디서 만드는가?
  • 에이전트는 완벽한 기준 유지를 기대하면서도 평균 수준으로 회귀함. 에이전트와 어떻게 협력해야 기준을 유지할 수 있는가?
  • 에이전트는 사용자와 작업 문제에 상관없이 모든 상황에 맞는 도구가 되려 함. 에이전트를 자연스러운 작업 방식에 더 밀접하게 통합하려면 어떻게 해야 하는가?
  • 에이전트는 코드를 잘 만들지만 대신 생각해주지는 못함. 에이전트 세션에 의사 결정을 어떻게 통합할 수 있는가?
  • 2부에서는 현재 효과를 보고 있는 구체적인 해결책을 공유할 예정임.