<div id="readability-page-1" class="page"><div>
  <h2>에이전틱 개발 시대, 비즈니스를 아는 개발자의 가치</h2>
  
  <p><span>2026년 03월 13일 작성</span></p><h2 id="tldr">TL;DR</h2>

<ul>
  <li>개발 진행상황을 별도 문서로 관리하는 방식은 과도기적이다. 코드 자체가 자신이 하는 일을 잘 설명하면 그것이 가장 좋은 컨텍스트다.</li>
  <li>에이전틱 개발이 발전할수록 비즈니스 프로세스와 코드의 일치율이 높아지기 좋은 환경이 되고 있다.</li>
  <li>에이전트에게 실행뿐 아니라 제안의 역할도 넘기고, 사람은 도메인과 조직을 고려한 판단을 하는 것이 앞으로의 역할이다.</li>
  <li>코더의 가치는 낮아지고, 비즈니스를 이해하는 개발자의 가치는 훨씬 높아질 것이다.</li>
</ul>

<h2 id="시작하며">시작하며</h2>

<p>베드락으로 클로드 코드를 쓸 수 있게 되면서 클로드 코드를 처음 써보고 있는데, 프로젝트 상태 관리에 GSD 라는 걸 많이 쓰고 있는 것 같다.</p>

<p>개인적으로는 TaskMaster 나 todo list 같은 세션 내의 작업 추적을 위한 도구와 달리, GSD 와 같이 문서를 통해 개발 진행상황에 대한 관리를 하는 것은 과도기적인 기술이라고 생각한다.</p>

<p>코드 자체가 자신이 무엇을 하는지 잘 설명하게끔 작성되어 있다면, 에이전트가 코드를 스스로 읽고 내용을 파악하는 것만으로도 충분히 안정적인 코드를 생성할 수 있다. 이전 글<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" rel="footnote">1</a></sup>에서 동적 컨텍스트는 휘발시키고 코드와 테스트만 남기자는 이야기를 했는데, 그 연장선에서 보면 코드 자체가 곧 가장 신뢰할 수 있는 컨텍스트인 셈이다. 별도의 요약문서는 업데이트 누락이 될 위험도 있고 디테일한 컨텍스트를 다 담고 있지도 않기 때문에 오히려 잘못된 코드를 생성하게 될 여지를 줄 수 있다. 토큰 측면에서도, 어차피 에이전트가 개발과정에서 수정 대상과 연관된 코드들을 읽게 되기 때문에, 큰 메리트가 없어보인다.</p>

<p>그렇다면 에이전트가 코드를 읽는 것만으로 비즈니스를 이해하게 하려면 어떻게 해야 할까?</p>

<h2 id="1-비즈니스-프로세스와-코드의-일치">1. 비즈니스 프로세스와 코드의 일치</h2>

<p>에이전트가 어떻게 하면 코드를 더 일관되게 작성하고 유지보수를 잘 하게 될지를 고민하다 보면 결국 도달하는 결론은 하나다. <strong>코드가 비즈니스와 자신이 하는 일을 잘 설명하고 있으면 그것이 가장 좋은 컨텍스트가 된다.</strong></p>

<p>요구사항 분석과 설계 측면에서, DDD(Domain-Driven Design)가 앞으로 더 중요해지지 않을까 생각한다. DDD 는 핵심가치 중 하나로 실제 비즈니스 프로세스가 코드에 반영되는 것을 장려하고 있기 때문이다. 유비쿼터스 언어로 도메인 전문가와 개발자가 같은 단어를 쓰고, 그 단어가 코드의 클래스명과 메서드명에 그대로 드러나는 것. 이것이 에이전트 시대에 더욱 빛을 발한다.</p>

<p>비즈니스 프로세스가 코드에 잘 반영되어 있으면, 에이전트에게 비즈니스 프로세스 변경점을 설명하는 것만으로도 코드에 대한 일관된 변경이 가능해진다. “주문 취소 시 환불 정책이 바뀌었다”고 말하면, 에이전트가 <code>OrderCancellation</code>, <code>RefundPolicy</code> 같은 도메인 객체를 찾아서 해당 로직만 정확히 수정할 수 있게 되는 것이다.</p>

<p>반대로 비즈니스 로직이 여기저기 흩어져 있거나, 코드의 네이밍이 비즈니스 용어와 괴리가 있으면, 에이전트는 문맥을 잘못 파악하고 엉뚱한 곳을 수정하거나 중복 로직을 만들어낸다. 결국 <strong>에이전틱 개발이 발전할수록, 비즈니스 프로세스와 코드의 일치율이 높아지기 좋은 환경이 되고 있고, 동시에 그 일치율이 높은 코드베이스가 에이전트를 더 잘 활용할 수 있는 기반이 된다.</strong></p>

<h2 id="2-에이전트가-제안하고-사람이-판단한다">2. 에이전트가 제안하고 사람이 판단한다</h2>

<p>에이전트를 사람이 제안한 작업을 실행하는 역할로만 쓰는 경우가 많다. 하지만 실행뿐 아니라 제안의 역할도 에이전트로 넘기고, 에이전트의 제안을 기반으로 피드백을 하면서 실행하다 보면 기대 이상의 결과를 볼 수 있다.</p>

<p>앞으로 사람이 에이전트보다 더 잘 알고 있게 되는 지식은 도메인 지식, 조직에 대한 운영 지식 정도일 것이다. 결국 좋은 개발자는 에이전트에게 충분한 도메인 정보를 전달하면서 에이전트가 3~4가지 제안을 하면 조직을 고려한 판단(팀의 수준, 비즈니스의 발전 방향 등)을 해주는 것이 사람의 역할이 되지 않을까 예상해본다.</p>

<p>이런 흐름에서 코딩 실력 자체의 가치는 계속 낮아진다. 에이전트가 코드를 작성하고, 리팩토링하고, 최적화까지 해주는 시대에 “코드를 잘 짜는 능력” 은 더 이상 희소하지 않다. 반면 <strong>비즈니스 도메인을 깊이 이해하고, 그 이해를 에이전트에게 정확히 전달할 수 있는 능력</strong>은 점점 더 희소해진다.</p>

<h2 id="3-실행-비용이-낮아지면서-달라진-것들">3. 실행 비용이 낮아지면서 달라진 것들</h2>

<p>최근 몇 년간 AI와 개발을 하면서 실행에 대한 비용이 꾸준히 낮아지고 있다. 그리고 그 덕분에 원래라면 하지 않을 것들에 대한 시간이 확보된 것을 체험하고 있다.</p>

<p>문서화, 리팩토링, 최적화 등이 평소에는 못하지만 AI 덕분에 가볍게 해볼 수 있게 된 대표적인 예이다. 그리고 이런 부분들은 코드 외적으로도 점점 더 확대되고 있다.</p>

<p>아이러니하게도, 실행 비용이 낮아질수록 더 중요해지는 것은 실행 자체가 아니라 <strong>무엇을 실행할지 결정하는 능력</strong>이다. 비즈니스에 대한 이해 없이 에이전트에게 “이거 만들어줘”라고 하면, 에이전트는 만들어준다. 하지만 그것이 비즈니스에 실제로 필요한 것인지, 우선순위가 맞는 것인지는 사람만이 판단할 수 있다.</p>

<h2 id="마치며">마치며</h2>

<p>에이전틱 개발이 발전할수록, 코더의 역할은 줄어들고 비즈니스를 이해하는 개발자의 가치는 훨씬 높아질 것이다.</p>

<p>코드가 비즈니스를 잘 설명하게 만드는 것, 에이전트에게 제안을 맡기고 도메인 관점에서 판단하는 것, 그리고 낮아진 실행 비용을 활용해 정말 중요한 문제에 시간을 쓰는 것. 이것들이 앞으로 개발자에게 요구되는 핵심 역량이 되어가고 있다.</p>

<p>별도의 요약 문서를 잘 쓰는 것보다, <strong>비즈니스가 코드에 그대로 녹아 있는 코드베이스를 만드는 것</strong>이 에이전트 시대에 가장 강력한 컨텍스트 엔지니어링이다.</p>

<hr>



</div></div>

Haandol

TL;DR
개발 진행상황을 별도 문서로 관리하는 방식은 과도기적이다. 코드 자체가 자신이 하는 일을 잘 설명하면 그것이 가장 좋은 컨텍스트다.
에이전틱 개발이 발전할수록 비즈니스 프로세스와 코드의 일치율이 높아지기 좋은 환경이 되고 있다.
에이전트에게 실행뿐 아니라 제안의 역할도 넘기고, 사람은 도메인과 조직을 고려한 판단을 하는 것이 앞으로의 역할이다.
코더의 가치는 낮아지고, 비즈니스를 이해하는 개발자의 가치는 훨씬 높아질 것이다.
시작하며
베드락으로 클로드 코드를 쓸 수 있게 되면서 클로드 코드를 처음 써보고 있는데, 프로젝트 상태 관리에 GSD 라는 걸 많이 쓰고 있는 것 같다.
개인적으로는 TaskMaster 나 todo list 같은 세션 내의 작업 추적을 위한 도구와 달리, GSD 와 같이 문서를 통해 개발 진행상황에 대한 관리를 하는 것은 과도기적인 기술이라고 생각한다.
코드 자체가 자신이 무엇을 하는지 잘 설명하게끔 작성되어 있다면, 에이전트가 코드를 스스로 읽고 내용을 파악하는 것만으로도 충분히 안정적인 코드를 생성할 수 있다. 이전 글1에서 동적 컨텍스트는 휘발시키고 코드와 테스트만 남기자는 이야기를 했는데, 그 연장선에서 보면 코드 자체가 곧 가장 신뢰할 수 있는 컨텍스트인 셈이다. 별도의 요약문서는 업데이트 누락이 될 위험도 있고 디테일한 컨텍스트를 다 담고 있지도 않기 때문에 오히려 잘못된 코드를 생성하게 될 여지를 줄 수 있다. 토큰 측면에서도, 어차피 에이전트가 개발과정에서 수정 대상과 연관된 코드들을 읽게 되기 때문에, 큰 메리트가 없어보인다.
그렇다면 에이전트가 코드를 읽는 것만으로 비즈니스를 이해하게 하려면 어떻게 해야 할까?
1. 비즈니스 프로세스와 코드의 일치
에이전트가 어떻게 하면 코드를 더 일관되게 작성하고 유지보수를 잘 하게 될지를 고민하다 보면 결국 도달하는 결론은 하나다. 코드가 비즈니스와 자신이 하는 일을 잘 설명하고 있으면 그것이 가장 좋은 컨텍스트가 된다.
요구사항 분석과 설계 측면에서, DDD(Domain-Driven Design)가 앞으로 더 중요해지지 않을까 생각한다. DDD 는 핵심가치 중 하나로 실제 비즈니스 프로세스가 코드에 반영되는 것을 장려하고 있기 때문이다. 유비쿼터스 언어로 도메인 전문가와 개발자가 같은 단어를 쓰고, 그 단어가 코드의 클래스명과 메서드명에 그대로 드러나는 것. 이것이 에이전트 시대에 더욱 빛을 발한다.
비즈니스 프로세스가 코드에 잘 반영되어 있으면, 에이전트에게 비즈니스 프로세스 변경점을 설명하는 것만으로도 코드에 대한 일관된 변경이 가능해진다. “주문 취소 시 환불 정책이 바뀌었다”고 말하면, 에이전트가 OrderCancellation, RefundPolicy 같은 도메인 객체를 찾아서 해당 로직만 정확히 수정할 수 있게 되는 것이다.
반대로 비즈니스 로직이 여기저기 흩어져 있거나, 코드의 네이밍이 비즈니스 용어와 괴리가 있으면, 에이전트는 문맥을 잘못 파악하고 엉뚱한 곳을 수정하거나 중복 로직을 만들어낸다. 결국 에이전틱 개발이 발전할수록, 비즈니스 프로세스와 코드의 일치율이 높아지기 좋은 환경이 되고 있고, 동시에 그 일치율이 높은 코드베이스가 에이전트를 더 잘 활용할 수 있는 기반이 된다.
2. 에이전트가 제안하고 사람이 판단한다
에이전트를 사람이 제안한 작업을 실행하는 역할로만 쓰는 경우가 많다. 하지만 실행뿐 아니라 제안의 역할도 에이전트로 넘기고, 에이전트의 제안을 기반으로 피드백을 하면서 실행하다 보면 기대 이상의 결과를 볼 수 있다.
앞으로 사람이 에이전트보다 더 잘 알고 있게 되는 지식은 도메인 지식, 조직에 대한 운영 지식 정도일 것이다. 결국 좋은 개발자는 에이전트에게 충분한 도메인 정보를 전달하면서 에이전트가 3~4가지 제안을 하면 조직을 고려한 판단(팀의 수준, 비즈니스의 발전 방향 등)을 해주는 것이 사람의 역할이 되지 않을까 예상해본다.
이런 흐름에서 코딩 실력 자체의 가치는 계속 낮아진다. 에이전트가 코드를 작성하고, 리팩토링하고, 최적화까지 해주는 시대에 “코드를 잘 짜는 능력” 은 더 이상 희소하지 않다. 반면 비즈니스 도메인을 깊이 이해하고, 그 이해를 에이전트에게 정확히 전달할 수 있는 능력은 점점 더 희소해진다.
3. 실행 비용이 낮아지면서 달라진 것들
최근 몇 년간 AI와 개발을 하면서 실행에 대한 비용이 꾸준히 낮아지고 있다. 그리고 그 덕분에 원래라면 하지 않을 것들에 대한 시간이 확보된 것을 체험하고 있다.
문서화, 리팩토링, 최적화 등이 평소에는 못하지만 AI 덕분에 가볍게 해볼 수 있게 된 대표적인 예이다. 그리고 이런 부분들은 코드 외적으로도 점점 더 확대되고 있다.
아이러니하게도, 실행 비용이 낮아질수록 더 중요해지는 것은 실행 자체가 아니라 무엇을 실행할지 결정하는 능력이다. 비즈니스에 대한 이해 없이 에이전트에게 “이거 만들어줘”라고 하면, 에이전트는 만들어준다. 하지만 그것이 비즈니스에 실제로 필요한 것인지, 우선순위가 맞는 것인지는 사람만이 판단할 수 있다.
마치며
에이전틱 개발이 발전할수록, 코더의 역할은 줄어들고 비즈니스를 이해하는 개발자의 가치는 훨씬 높아질 것이다.
코드가 비즈니스를 잘 설명하게 만드는 것, 에이전트에게 제안을 맡기고 도메인 관점에서 판단하는 것, 그리고 낮아진 실행 비용을 활용해 정말 중요한 문제에 시간을 쓰는 것. 이것들이 앞으로 개발자에게 요구되는 핵심 역량이 되어가고 있다.
별도의 요약 문서를 잘 쓰는 것보다, 비즈니스가 코드에 그대로 녹아 있는 코드베이스를 만드는 것이 에이전트 시대에 가장 강력한 컨텍스트 엔지니어링이다.
컨텍스트 엔지니어링 - 정적 컨텍스트와 동적 컨텍스트 ↩

에이전틱 개발 시대, 비즈니스를 아는 개발자의 가치

댓글