코딩 비용이 0에 수렴한 시대의 엔지니어링 원칙 — 에이전트와 함께 일하는 실전 패턴 완전 분석

들어가며: "vibe coding"이 아니다

2026년 2월 23일, Django 공동 창설자이자 Datasette 창시자인 Simon Willison이 새로운 가이드를 공개하였다.

제목은 "Agentic Engineering Patterns"이다(https://simonwillison.net/guides/agentic-engineering-patterns/).

 

클로드 코드, OpenAI Codex 같은 코딩 에이전트를 사용하는 전문 개발자를 위한 실전 패턴 모음집이다.

그는 두 가지 개념을 명확히 구분한다.

개념	정의	대상
Vibe coding	코드에 주의를 전혀 기울이지 않는 방식	주로 비개발자
Agentic engineering	전문 개발자가 에이전트로 기존 전문성을 증폭하는 방식	전문 소프트웨어 엔지니어

 

이 가이드는 후자를 위한 것이다.
코드를 몰라도 되는 방법이 아니라, 코드를 아는 사람이 에이전트를 최대한 활용하는 방법이다.

 

가이드 형식 자체도 흥미롭다.
1994년 Gang of Four의 "Design Patterns" 책에서 영감을 받아,
챕터 단위로 패턴을 지속 추가하는 살아있는 문서로 운영된다.
특정 시점에 동결되는 블로그 포스트가 아니라 계속 업데이트되는 가이드이다.

▲ Claude Code, OpenAI Codex 같은 코딩 에이전트는 코드를 생성할 뿐 아니라 직접 실행하고 반복할 수 있다

---

1. 코딩 비용이 0에 수렴했다 — 그런데 좋은 코드는?

Simon은 이 가이드에서 가장 중요한 전제를 명확히 제시한다.

"코드를 컴퓨터에 타이핑하는 비용이 극적으로 내려갔다.
그런데 좋은 코드를 전달하는 비용은 여전히 그보다 훨씬 높다."

 

그가 정의하는 "좋은 코드(good code)"의 기준은 다음 8가지이다.

1. 코드가 동작한다
   — 의도한 대로 버그 없이 작동한다
2. 동작함을 안다
   — 테스트 등으로 본인과 타인에게 증명되었다
3. 올바른 문제를 해결한다
   — 실제 필요한 문제를 풀고 있다
4. 에러를 우아하게 처리한다
   — 해피 패스만이 아닌 예외 상황까지 고려한다
5. 단순하고 최소한이다
   — 현재와 미래에 사람과 기계 모두 이해 가능하다
6. 테스트로 보호된다
   — 현재 동작을 증명하고 회귀를 방지한다
7. 적절히 문서화되었다
   — 코드 변경 시 문서도 함께 갱신된다
8. 미래 변경을 가능하게 한다
   — YAGNI 원칙을 지키면서도 불필요한 복잡성을 피한다
   (You Ain't Gonna Need It, 지금 당장 필요하지 않은 기능은 미리 구현하지 말라)

코딩 에이전트는 이 기준의 상당 부분을 도울 수 있다.
그러나 이 기준을 충족하는 좋은 코드를 만들 책임은 여전히 에이전트를 운전하는 개발자에게 있다.

사례: 제약 조건이 없으면 에이전트는 나쁜 코드를 생산한다>
Claude Code에 "결제 모듈을 완성해줘"라는 단 한 줄 프롬프트를 실행하였다.
에이전트는 2,000줄의 코드를 생성하였다.
코드는 컴파일되었고 기본 테스트를 통과하였다.
그러나 오류 처리가 빠져 있었고, 일부 엣지 케이스는 전혀 고려하지 않았으며, 기존 코드베이스의 패턴과 맞지 않았다.
"동작하는 코드"였지만 "좋은 코드"는 아니었다.
팀은 이후 명시적인 품질 기준을 프롬프트에 포함하는 방식으로 전환하였다.

---

2. 새로운 습관: 본능이 틀릴 때를 알아차려라

코딩 비용이 낮아진 환경에서 개발자에게 필요한 것은 새로운 습관이다.

Simon은 구체적인 제안을 한다.

"본능이 '만들지 마라, 시간이 아깝다'고 말할 때마다,
어떤 비동기 에이전트 세션에서 프롬프트를 실행해 봐라.
최악의 경우는 10분 후에 확인했더니 토큰 낭비였다는 것이다."

 

이 원칙이 중요한 이유는 우리의 모든 판단 기준이 "코드 작성이 비싸다"는 전제 위에 세워져 있기 때문이다.

 

기능의 가치가 개발 비용을 여러 배 상회해야 한다는 기존 계산법은 이제 다시 써야 한다.

 

병렬 에이전트 실행이 가능해지면서
한 명의 엔지니어가 동시에 구현, 리팩토링, 테스트, 문서화를 여러 장소에서 진행할 수 있게 되었다.
이는 기존의 어떤 인력 계획 공식도 무효로 만든다.

▲ 코딩 에이전트의 등장으로 단위 시간당 처리 가능한 작업량이 질적으로 변화하였다

---

3. 안티패턴: 리뷰 없는 코드를 동료에게 강요하지 마라

Simon은 에이전트 시대에 특히 흔하고 심각한
안티패턴(문제를 해결하려다 오히려 더 큰 문제를 야기하는 잘못된 관행이나 설계) 하나를 명시적으로 경고한다.

 

리뷰하지 않은 코드를 PR로 제출하는 것이다.

"에이전트가 생성한 수백 줄(혹은 수천 줄)의 코드를 직접 검증하지 않고 PR로 올리면,
당신은 실제 작업을 다른 사람에게 위임하는 것이다.
그들이 직접 에이전트에게 프롬프트를 했어도 되는데, 당신이 무슨 가치를 제공하는가?"

 

좋은 에이전트 엔지니어링 PR의 특성은 다음과 같다.

• 코드가 동작한다
  — 본인이 직접 확인하였다
• 크기가 작다
  — 리뷰어에게 과도한 인지 부담을 주지 않는다
• 맥락을 제공한다
  — 변경이 서비스하는 상위 목표를 설명한다
• PR 설명을 검증하였다
  — 에이전트가 작성한 PR 설명도 본인이 읽고 검증하였다
• 증거를 포함한다
  — 수동 테스트 방법, 구현 선택 이유, 스크린샷이나 영상 등

특히 마지막 항목이 실질적으로 중요하다.
에이전트는 설득력 있어 보이는 PR 설명을 능숙하게 작성한다.
그 설명을 리뷰어가 직접 읽도록 방치하는 것은 무례하다.

---

4. 이 가이드가 지금 중요한 이유

Simon Willison은 이 가이드를 "아직 업계 전체가 정답을 찾고 있는 과정"이라고 설명한다.
그 자신도 여전히 답을 찾고 있다.

 

그러나 이미 확인된 것이 있다.

코딩 에이전트는 코드 작성의 단가를 극적으로 낮췄다.

 

그런데 코드 작성 단가가 낮아진다고 해서 소프트웨어 품질이 자동으로 올라가지는 않는다.
에이전트가 빠르게 생성한 나쁜 코드도 여전히 나쁜 코드이다.

 

지금 필요한 것은 낮아진 비용의 혜택을 취하면서도 품질을 유지하는 새로운 습관과 패턴이다.

 

이 가이드는 그 질문에 답하기 위한 지속적인 시도이다.

Simon Willison은 Lenny's Newsletter 인터뷰에서 현재 자신의 코드 중 95%를 전화기에서 작성한다고 밝혔다.
에이전트가 실행을 처리하는 동안 그는 어디서든 방향을 지시하는 역할로 전환하였다.
이것이 에이전트 엔지니어링의 실제 모습이다.

---

마치며

코딩 에이전트의 등장은 소프트웨어 개발의 경제학을 바꿨다.
그러나 소프트웨어 품질의 본질은 바뀌지 않았다.

 

에이전트는 코드를 빠르게 생산하는 강력한 도구이지만,
그 코드가 올바른 문제를 올바르게 해결하는지 판단하는 능력은 여전히 사람의 몫이다.

 

Simon Willison의 가이드는 이 균형점을 찾는 실전 지도이다.
아직 완성된 답은 없지만, 지금 이 질문에 진지하게 답하고 있는 사람들이 다음 시대의 핵심 개발자가 된다.