AI 코딩 에이전트를 쓰기 시작한 뒤, 개발자의 일이 줄어들었다고 느끼지는 않는다. 대신 일이 이동했다.

기존의 개발 흐름은 비교적 익숙했다. 기획자가 기획서를 작성하면 개발자는 이를 코드로 옮긴다. 코드와 시스템을 검증하고, 다른 개발자와 연결해 다음 단계로 넘긴다. 각 역할은 분업되어 있고, 개발자는 주로 구현과 기술적 검증의 책임을 진다.

에이전트를 처음 쓸 때는 그 구조 안에서 코드 작성만 맡겼다. 반복적인 구현, 테스트 초안, 리팩터링처럼 경계가 비교적 분명한 일을 위임했다. 결과는 예상보다 빨랐다. 그런데 코드 생산 속도가 올라가자, 오히려 다른 병목이 더 선명하게 보이기 시작했다.

기획은 충분히 구체적인가? 이 요청은 왜 필요한가? 사용자는 어디에서 막히는가? 프론트엔드에서 이 흐름은 어떤 경험이 되어야 하는가? 지금 구현하기 쉬운 선택이 나중에도 서비스에 맞는가?

코드를 만드는 속도가 빨라진다고 해서, 이런 질문에 대한 답이 저절로 생기지는 않는다. 오히려 에이전트가 빨라질수록 개발자는 더 빨리 이 질문들 앞에 서게 된다.

그래서 나는 AI 시대의 개발자가 점점 설계자가 된다고 생각한다. 시스템을 설계하고, 서비스를 설계하고, 에이전트가 작은 일을 완성하도록 조율하는 사람 말이다.

구현이 빨라지면, 기획의 빈칸이 먼저 드러난다#

에이전트에게 기능 하나를 요청하는 일은 어렵지 않다. 화면을 만들고, API를 연결하고, 테스트까지 붙이는 데 걸리는 시간은 크게 줄었다.

문제는 에이전트가 요구사항을 구현할 수는 있어도, 그 요구사항이 정말 문제를 푸는지까지 알지는 못한다는 데 있다.

가령 기획서에 “예약 변경 버튼을 추가한다”라고 적혀 있다고 하자. 에이전트는 버튼, API 호출, 성공 메시지, 테스트를 빠르게 만들 수 있다. 하지만 개발자가 “왜 이 버튼이 필요한가?”라고 묻지 않으면, 더 중요한 사실을 놓칠 수 있다. 사용자가 원하는 것은 버튼 자체가 아니라, 변경 가능한 시간대를 미리 알고 불필요한 문의를 줄이는 것일 수 있다.

그렇다면 해결해야 할 것은 버튼 하나가 아니다. 예약 상세에서 가능한 선택지를 보여 주고, 변경할 수 없는 경우에는 이유와 다음 행동을 알려 주는 사용자 흐름이다.

에이전트는 두 번째 해결책도 구현할 수 있다. 그러나 무엇을 구현해야 하는지 다시 정의하는 일은 에이전트가 대신하지 않는다.

AI를 쓰면서 기획자와 대화하는 시간이 늘어나는 이유도 여기에 있다. 개발자는 더 이상 “기획서에 적힌 것을 구현하는 사람”으로만 남기 어렵다. 기획의 의도를 확인하고, 그 의도를 서비스 흐름과 데이터 구조와 작업 단위로 번역해야 한다.

“무엇을 만들까요?”보다 먼저 “왜 이게 필요하죠?”를 묻는 일이 개발의 중심으로 돌아온다.

프론트엔드까지 닿으면, 서비스 전체가 보이기 시작한다#

구현 속도가 빨라지면 프론트엔드와의 소통도 병목이 된다. 기획 의도를 이해하고, 화면을 만들고, 다시 피드백을 주고받는 과정이 코드 작성보다 오래 걸리기도 한다.

그래서 개발자는 점점 프론트 작업까지 직접 만지게 된다. 이것은 단순히 역할이 하나 더 늘어나는 문제가 아니다. 사용자가 실제로 만나는 경험을 직접 설계하게 되는 변화다.

그때부터 개발자는 API가 정상 응답하는지만 볼 수 없다.

  • 사용자는 처음 무엇을 보고, 무엇을 선택하는가?
  • 데이터가 없을 때는 무엇을 이해해야 하는가?
  • 오류가 나면 다음 행동을 알 수 있는가?
  • 성공한 뒤 사용자는 무엇을 기대하는가?
  • 이 흐름은 서비스가 해결하려는 문제와 맞는가?

이 질문에 답하려면 결국 도메인을 알아야 한다. 우리 서비스가 누구의 어떤 문제를 풀고 있는지, 그 문제를 푸는 과정에서 어떤 규칙과 예외가 있는지 이해해야 한다.

AI가 개발자를 도메인에서 멀어지게 하는 것이 아니다. 오히려 구현을 위임할 수 있게 될수록, 개발자가 도메인에 대해 얕게 알고 있을 여지는 줄어든다. 도메인을 이해하지 못하면 에이전트에게 무엇을 시킬지, 결과가 맞는지, 다음 작업을 어떻게 나눌지 판단할 수 없기 때문이다.

에이전트는 작은 업무 사이클 안에서 배워야 한다#

에이전트를 잘 쓰는 방법은 처음부터 거대한 기능을 통째로 던지는 데 있지 않다. 반복되는 하나의 업무 사이클을 함께 완성해 보는 데 있다.

예를 들어 매월 엑셀 파일을 내려받아 데이터를 조합하고, 보고용 통계를 만든 뒤, 마케팅 팀이 원하는 양식으로 정리해서 전달하는 일이 있다고 하자.

처음에는 에이전트에게 데이터를 읽고 초안을 만들게 할 수 있다. 그다음에는 사람이 결과를 직접 만든 결과와 비교한다. 빠진 지표는 없는지, 계산 기준은 같은지, 팀이 실제로 쓰기 좋은 형식인지 확인한다. 몇 번 반복하면서 에이전트가 무엇을 잘하는지, 어디에서 맥락을 놓치는지, 사람이 암묵적으로 하던 판단은 무엇이었는지 드러난다.

프로젝트의 진척과 현황을 정리하는 일도 마찬가지다. 데이터를 모으고, 막힌 일을 분류하고, 다음 행동이 필요한 지점을 드러내는 한 사이클을 같이 돌려 볼 수 있다.

이 과정의 목적은 단순히 자동화를 만드는 것이 아니다. 에이전트와 함께 일하는 방식을 발견하는 것이다.

  • 어떤 원천 데이터를 봐야 하는가?
  • 어떤 지표는 항상 함께 봐야 하는가?
  • 어떤 예외는 사람이 판단해야 하는가?
  • 결과물의 독자는 무엇을 알아야 행동할 수 있는가?
  • 에이전트가 틀렸을 때, 어디서 쉽게 발견할 수 있는가?

작은 사이클을 여러 번 끝내면서, 개발자는 서비스와 조직의 실제 업무 흐름을 다시 배운다. 에이전트는 도구가 아니라 그 흐름 안에서 함께 일하는 실행 주체가 된다.

신뢰는 결과로 쌓되, 권한은 별도로 다뤄야 한다#

에이전트를 신뢰할 수 있는 기준은 단순하다.

첫째, 내가 직접 했을 때와 같은 결과를 반복해서 내는가.

둘째, 단순히 사람의 작업을 복제하는 것을 넘어, 내가 직접 했을 때 놓쳤을 문제점까지 찾아내는가.

이 두 가지가 확인되면 에이전트에게 더 많은 분석과 제안을 맡길 수 있다. 하지만 여기서 흔히 생기는 오해가 있다. 좋은 결과를 반복해서 낸다고 해서, 그 에이전트에게 운영 권한까지 줘도 된다는 뜻은 아니다.

우리의 데이터에 직접 접근해 수정하거나 입력하는 권한, 배포 권한, 실제 사용자에게 영향을 주는 권한은 별개다. 잘못된 한 번의 실행이 사용자와 시스템에 직접 영향을 줄 수 있기 때문이다.

그래서 에이전트는 변경을 제안할 수는 있어도, 실행은 사람이 승인해야 한다.

좋은 제안에는 최소한 다음이 들어가야 한다.

  • 왜 이 변경이 필요한가
  • 무엇이 어떻게 바뀌는가
  • 영향 범위는 어디까지인가
  • 지금 해야 하는 이유는 무엇인가
  • 실행 계획과 검증 방법은 무엇인가
  • 문제가 생겼을 때 어떻게 되돌릴 것인가

이 형식은 결재 문서가 아니다. 개발자가 판단할 수 있게 만드는 인터페이스다. 에이전트의 자율성을 제한하기 위한 장치이기도 하지만, 더 근본적으로는 우리가 무엇을 책임지고 있는지 드러내는 장치다.

개발자는 에이전트에게 일을 던지는 사람이 아니다#

에이전트를 잘 쓰는 개발자는 많은 프롬프트를 아는 사람이 아닐 것이다.

문제를 작게 나누고, 한 사이클이 끝나는 조건을 정의하고, 기획의 의도를 확인하고, 도메인 규칙을 이해하고, 시스템에 영향을 주는 권한을 분리하고, 반복된 실패를 다음번에는 막을 수 있는 규칙으로 남기는 사람일 것이다.

AI는 코드를 빠르게 만든다. 하지만 서비스가 무엇을 위해 존재하는지, 어떤 변경을 감당할 수 있는지, 사용자가 실제로 더 나아졌는지는 스스로 결정하지 못한다.

그래서 AI 시대의 개발자는 코드를 더 적게 쓸 수 있다. 그러나 더 큰 범위를 설계해야 한다.

시스템을 설계하고, 서비스를 설계하고, 에이전트가 안전하게 작은 일을 완성하도록 조율하는 것.

나는 그것이 앞으로 개발자의 중요한 일이 될 것이라고 생각한다.