에이전틱 코딩 좀 더 잘하기

새로운 병목, 구현이 아니라 검증

에이전틱 코딩

에이전틱 코딩(Agentic Coding)은 AI 에이전트가 코드 작성의 주체가 되는 개발 방식이다.
개발자가 직접 한 줄씩 코드를 타이핑하는(자동완성 보조를 받아) 대신, AI에게 의도와 맥락을 전달하고 AI가 코드를 생성한다.
개발자는 생성된 코드를 검토하고, 피드백을 주고, 방향을 조정한다.

새로운 병목

전통적인 개발에서 병목은 구현이었다. 구현코드/테스트코드를 구체적으로 어떻게 작성할지 생각하고, 타이핑하는데 시간이 걸렸다.
에이전틱 코딩에선 검증이 병목이다. 테스트, 코드리뷰는 물론 목적이 제대로 달성되었는지 확인하는 시간이 훨씬 오래걸린다.

루프 닫기, 검증

하루에 600개의 커밋을 머지하는, 이제 코드를 직접 작성하지 않는다고 하는 Peter Steinberger(OpenClaw 개발자)는 인터뷰에서 루프닫기(closing the loop)를 강조한다. 에이전트가 스스로 디버깅하고 테스트 할 수 있어야 한다. 에이전트에게 자신의 작업을 검증할 방법을 제공해야한다.

마찬가지로 하루에 20개 넘는 PR을 제출하고, AI가 자신의 코드 100%를 작성한다 ↗고 말한 Boris Cherny(Claude Code 개발자)도, X에 자신의 Claude Code 설정을 이야기하며 에이전트에게 검증(Verification)할 방법을 제공하고 피드백 루프를 갖게 하라고 조언한다.

에이전트가 엄청나게 빠르게 작성해준 구현코드를 내가 직접 테스트하고 에이전트에 오류리포트 해주다보면, 이건 뭐가 잘못되었다는 것을 스스로 알게된다.

검증 가능한 단위로 작업하기

에이전트가 만들어 준 코드를 믿으려면, 검증이 가능 해야한다. 빠르게 검증하고 부족한 부분을 피드백하면 결과물이 빠르게 답에 가까워진다.
에이전트가 스스로 검증할 수 있게 환경을 만들어준다면, 에이전트는 사람이 흉내낼 수 없는 속도로 검증하고 피드백한다. 루프가 닫힌다.

검증 가능한 단위를 생각할 때 나는 순수함수나 불변 객체를 떠올린다. 입력(현재 모습/데이터)과 출력(변화한 모습)을 명확히 정의하면, 에이전트는 그 사이를 채울 수 있다.
사이드이펙트가 없으면 입력과 출력만으로 동작을 완전히 설명할 수 있고, 그 순간 테스트의 목표가 명확해진다.
작업을 쪼갤 때도 “이 입력에 이 출력이 나와야 한다”처럼 관찰 가능한 규칙부터 정의한다. 규칙이 명확하면 에이전트가 테스트를 만들고 돌리는 비용이 급격히 줄어든다.
결국 검증 가능한 단위는 작은 기능이기도 하지만, 입력과 출력이 분명한 계약을 가진 조각이다.

Tell, Don't Ask, 멘토링 보다 코칭

에이전트를 더 잘쓰기 위해, 루프 닫기/검증 방법 제공을 위한 설계를 하게된다.
그러다 보면 객체지향의 오랜 격언인 Tell, Don't Ask. ↗ 를 생각하게 된다. Ask = 상태 알려줘, Tell = 행동 해줘.

절차적 코드는 정보를 얻은 뒤 결정을 내린다.

객체지향 코드는 객체에게 일을 하라고 말한다. - Alec Sharp, Smalltalk by Example

객체에게 무엇을 하길 원하는지 지시하고, 객체의 상태를 질문해서 그 결과로 직접 결정을 내린 뒤 다시 객체에게 무엇을 하라고 말하는 방식은 피해야 한다는 것이다.
루프 닫기/검증 방법 제공을 위한 설계는 객체지향의 철학과 맞닿아 있다고 생각한다. 기존에 객체지향 사고를 좋아했던 사람이라면 새롭게 배워야할 것은 적을 것 같다.

멘토링이 정답과 경험을 직접 전수하는 것이라면, 코칭은 상대가 스스로 답을 찾도록 질문하고 유도하는 것이다.
내가 에이전트에게 지시와 명령을 한다면, 에이전트는 내 지식만큼 결과물을 낸다. 내가 에이전트에게 목표와 방향성을 이야기한다면, 에이전트는 내 지식을 뛰어넘는 결과물을 낼 수 있다.

Claude가 말하는 LLM의 특징

Robert C. Martin의 트윗 ↗에서 Claude가 Clojure 코드를 다루는데 왜 어려움을 겪는지 알게되었다.

• 토큰 패턴매칭 모델 (다음에 올 말을 패턴으로 예측)
• 명시적 상태 추적 장치 없음 (숫자 셀 때 손가락을 안 쓰는 격)
• 중첩/의존관계가 깊으면 성능저하 (맥락을 잘 전달하지 않고 말하기)

Clojure는 괄호만으로 구조를 표현해서 패턴매칭에 쓸 힌트가 적고, 괄호 숫자를 셀 장치가 없어서 오류날 가능성이 높다.
여기에 더해 사용자가 알면 더 효과적으로 대화할 수 있는 LLM의 특징을 물었다.

• 최근 편향 (긴 대화에서 끝에 가까운 내용에 더 영향 받음)
• 중간 손실 (긴 입력의 가운데 놓치기 쉬움)
• 동의 편향 (sycophancy, 사용자말에 맞장구 치려는 경향)
• 흔한 답으로 수렴 (학습 데이터에 많은 패턴으로 끌려감)

작은 함수, 작은 커밋, 작은 PR, 짧은 피드백 루프.

사람한테도 LLM한테도 좋습니다. - Opus 4.5 thinking, Desktop Claude App