에이전틱 개발 시대, 비즈니스를 아는 개발자의 가치
TL;DR
- 업무 용어가 코드에 드러나면 에이전트가 수정 대상을 찾기 쉽다.
- 에이전트의 제안을 판단할 때 업무와 조직에 대한 지식이 중요하다.
- 실행 비용이 낮아질수록 무엇을 만들지 판단하는 능력이 중요해진다.
시작하며
베드락으로 클로드 코드를 쓸 수 있게 되면서 클로드 코드를 처음 써보고 있는데, 프로젝트 상태 관리에 GSD(Get Shit Done)라는 도구를 많이 쓰고 있는 것 같다. 요구사항과 계획, 현재 진행 상태를 문서로 남겨 다음 작업에서 읽게 하는 방식이다.1
개인적으로는 TaskMaster 나 todo list 같은 세션 내의 작업 추적을 위한 도구와 달리, GSD 와 같이 문서를 통해 개발 진행상황에 대한 관리를 하는 것은 과도기적인 기술이라고 생각한다.
코드가 자신이 무엇을 하는지 드러내면 에이전트가 현재 동작을 파악하는 데 도움이 된다. 이전 글2에서 임시 실행 기록은 정리하고 코드와 테스트를 남기자고 한 것도, 현재 상태를 그 결과물에서 다시 확인할 수 있기 때문이다.
별도의 요약문서는 업데이트가 빠지거나 필요한 세부 내용이 생략될 수 있다. 어차피 수정할 때 관련 코드를 읽어야 한다면, 요약문서를 계속 관리하는 비용이 그만한 가치가 있는지 보게 된다.
그렇다면 에이전트가 코드를 읽는 것만으로 비즈니스를 이해하게 하려면 어떻게 해야 할까?
1. 비즈니스 프로세스와 코드의 일치
에이전트가 수정할 코드를 찾으려면 요구사항에 나온 업무 용어와 코드의 이름을 연결할 수 있어야 한다. 코드가 어떤 업무를 처리하는지 드러날수록 그 연결이 쉬워진다.
요구사항 분석과 설계 측면에서, 업무의 개념과 규칙을 중심으로 소프트웨어를 설계하는 DDD(Domain-Driven Design)가 앞으로 더 중요해지지 않을까 생각한다. 현업 전문가와 개발자가 같은 단어를 쓰고 그 단어를 코드의 클래스명과 메서드명에도 사용하는 방식, 즉 유비쿼터스 언어가 에이전트에게도 업무와 코드를 연결하는 단서가 되기 때문이다.
예를 들어 “주문 취소 시 환불 정책이 바뀌었다”고 요청했을 때 OrderCancellation, RefundPolicy 같은 이름이 있으면 관련 로직을 찾는 단서가 된다. 그 객체와 연결된 코드를 읽고, 변경한 정책을 테스트로 확인하는 과정도 필요하다.
업무 로직이 여러 곳에 흩어져 있거나 이름이 업무 용어와 다르면, 에이전트는 관련 코드를 놓치거나 중복 로직을 만들 수 있다. 그래서 업무와 코드 사이의 연결을 분명히 하는 일이 에이전트와 개발할 때도 도움이 된다고 생각한다.
2. 에이전트가 제안하고 사람이 판단한다
에이전트를 사람이 제안한 작업을 실행하는 역할로만 쓰는 경우가 많다. 하지만 실행뿐 아니라 제안의 역할도 에이전트로 넘기고, 에이전트의 제안을 기반으로 피드백을 하면서 실행하다 보면 기대 이상의 결과를 볼 수 있다.
앞으로 사람이 에이전트보다 더 잘 알고 있게 되는 지식은 도메인 지식, 조직에 대한 운영 지식 정도일 것이다. 결국 좋은 개발자는 에이전트에게 충분한 도메인 정보를 전달하면서 에이전트가 3~4가지 제안을 하면 조직을 고려한 판단(팀의 수준, 비즈니스의 발전 방향 등)을 해주는 것이 사람의 역할이 되지 않을까 예상해본다.
에이전트가 구현과 리팩토링을 더 많이 맡을수록, 나는 무엇을 바꿀지 판단하는 일에 시간을 더 쓰게 될 것이라고 생각한다. 그때는 도메인과 조직의 사정을 이해하고, 그 판단을 에이전트에게 정확히 전달할 수 있어야 한다.
3. 실행 비용이 낮아지면서 달라진 것들
최근 몇 년간 AI와 개발을 하면서 실행에 대한 비용이 꾸준히 낮아지고 있다. 그리고 그 덕분에 원래라면 하지 않을 것들에 대한 시간이 확보된 것을 체험하고 있다.
문서화, 리팩토링, 최적화 등이 평소에는 못하지만 AI 덕분에 가볍게 해볼 수 있게 된 대표적인 예이다. 그리고 이런 부분들은 코드 외적으로도 점점 더 확대되고 있다.
실행 비용이 낮아져도 어떤 변경이 실제로 필요한지, 지금 우선해야 하는지는 정해야 한다. 에이전트의 제안을 받아보되 도메인과 조직의 상황에 맞는지 판단하는 데 사람의 지식을 쓰고 싶다.
마치며
AI 덕분에 평소 미뤄두던 문서화와 리팩토링을 시도할 여유가 생겼다. 그 시간을 업무 용어와 코드의 연결을 정리하는 데도 쓰고 싶다.
에이전트가 내놓은 변경을 판단할 때도 어떤 업무를 왜 바꾸는지부터 확인하려 한다. 실행할 수 있는 일이 많아질수록 그 판단에 필요한 도메인 지식이 더 중요해질 것이라고 생각한다.
-
GSD README — 요구사항, 계획과 상태를 문서로 유지해 세션 사이의 작업 맥락을 이어가는 도구. ↩