작성자에서 리더로: 에이전트와 함께 일하며 달라지는 개발자의 역할

에이전트 덕분에 코드를 작성하는 비용은 크게 낮아졌습니다. 하지만 무엇을 만들어야 하는지 이해하고 결과를 확인하는 비용까지 낮아진 것은 아닙니다. 그래서 에이전트와 일할 때 가장 흥미로운 일은 코드를 쓰기 전과 후에 이뤄집니다. 누가 작업을 정하고, 결과가 좋은지 누가 판단하며, 어느 정도의 일을 에이전트에게 맡길지 결정하는 일입니다.

지난 2년간 발표된 연구와 보고서는 이 변화를 어떻게 설명할까요? 에이전트와 일하는 네 가지 방식, 작업에 맞는 방식의 선택, 그리고 "의도와 품질 기준"이라고 부르는 개념을 살펴보겠습니다. 후반부에는 개발자의 역할이 코드 작성보다 넓어지는 이유도 이야기합니다. 자료 기준은 2026년 9월입니다. 수치는 출처 링크와 함께 별도 블록에 넣었습니다. 연구 저자의 관점을 전할 때는 저자를 밝히고, 제 해석은 따로 표시합니다.

에이전트와 일하는 네 가지 방식

Microsoft의 재러드 스파타로는 2026년 5월 가장 이해하기 쉬운 틀을 제시했습니다. 사람과 AI가 일을 나누는 네 가지 방식을 설명합니다. 구조가 명확해서 개발자라면 도구와 함께 걸어온 자신의 길을 그 안에서 알아볼 수 있습니다.

단계가 높아질수록 직접 쓰는 코드는 줄고, 시작 전에 결정하고 끝난 뒤 확인하는 일은 늘어납니다. 작성자는 코드를 쓰면서 품질을 판단합니다. 디렉터는 코드가 만들어지는 과정을 보지 않으므로 중요한 요구사항을 시작 전에 전달하고 결과를 확인해야 합니다. 여기서는 오케스트레이터를 이름만 언급했습니다. 자체 도구가 필요한 별도의 큰 주제이므로, 앞의 세 방식이 익숙해진 뒤 살펴보면 좋습니다.

계단이 아니라 작업에 맞는 방식

이 틀을 계단처럼 읽기 쉽습니다. 처음에는 작성자였다가 오케스트레이터까지 성장하며, 높이 올라갈수록 좋다고 생각하는 식이죠. 하지만 스파타로는 정반대로 말합니다. 모든 작업을 네 번째 방식으로 바꾸는 것이 목표가 아닙니다. 각 작업 흐름에 알맞은 방식을 고르는 게 목표입니다.

실제로는 다음 네 가지 질문을 기준으로 고르면 됩니다.

• 목표가 얼마나 명확한가. 어떤 결과가 나와야 할지 아직 모른다면 작업 전체를 맡기기에는 이릅니다;
• 결과를 자동으로 검증할 수 있는가. 테스트가 잘 갖춰져 있으면 사람이 놓치더라도 검사가 오류를 잡아내므로 에이전트에게 더 맡길 수 있습니다;
• 오류의 대가가 얼마나 큰가. 안내 문구의 오타는 쉽게 고칠 수 있지만, 금액 계산 오류는 큰 손실로 이어질 수 있습니다;
• 작업이 반복되는가. 한 번뿐인 작업에는 별도 프로세스를 만들 필요가 없지만, 매주 하는 작업이라면 만들어 둘 만합니다.

구체적인 작업에 적용하면 다음과 같습니다.

제 생각에 이 수치는 기억해 둘 만합니다. 다수가 신중하다고 해서 뒤처지는 것은 아닙니다. 사람들은 오류의 대가를 따져 방식을 고르고, 그건 올바른 선택입니다. 오류의 비용이 큰 작업에서 편집자 방식으로 일한다고 해서 에이전트를 "충분히 활용하지 못하는" 것은 아닙니다.

Claude Code에서는 이 선택을 직접 조정할 수 있습니다. Plan mode와 권한 규칙이 여러분이 설정하는 조절 장치 역할을 합니다. 오류 비용이 큰 작업이라면 에이전트가 수정 전에 계획부터 보여 주게 하고, 위험한 작업은 확인을 거치도록 설정하세요. 반복적인 작업에서는 에이전트가 더 많이 진행하게 둘 수 있습니다.

의도와 품질 기준

더 많은 일을 맡길수록 시작 전에 전달하는 내용이 중요해집니다. Microsoft 연구는 이렇게 설명합니다. 가장 효과적으로 AI를 활용하는 사람은 더 많이, 더 빠르게 하는 사람이 아니라 사람만 할 수 있는 일을 중심으로 자신의 가치를 만들어 가는 사람입니다. 바로 명확한 의도를 정하는 일, 즉 원하는 결과와 품질 기준을 설명하는 일, 그리고 사람과 AI가 일을 어떻게 나눌지 설계하는 일입니다.

개발에서는 이 개념을 이미 익숙한 말로 부릅니다. 의도는 무엇을 왜 해야 하는지 적은 명세입니다. 품질 기준은 인수 기준이자 Scrum에서 Definition of Done이라고 부르는 것입니다. 작업이 완료됐다고 판단할 조건의 목록입니다. 여기서는 이를 간단히 완료 기준이라고 부르겠습니다.

Agile 방식으로 에이전트를 만드는 Microsoft의 대니얼 엡스타인은 2026년 5월 19일 Agentic-Agile 시리즈 첫 글에서 이를 간단히 표현했습니다. "Every capability is an issue. Every issue has acceptance criteria." 모든 기능은 하나의 이슈이고, 모든 이슈에는 인수 기준이 있습니다.

작업 설명은 두 가지 관점으로 쓰면 편리합니다. 사람에게는 왜, 누구를 위한 작업인지 설명합니다. 에이전트에게는 무엇을 하고, 어떤 기준으로 확인하며, 무엇은 건드리지 말아야 하는지 적습니다. 아래는 같은 요청을 다듬기 전과 후로 보여 주는 학습 예시입니다. 두 번째 예시에서 첫 문단은 사람을 위한 설명이고 나머지는 에이전트를 위한 내용입니다.

수정 전:

지출을 CSV로 내보내는 기능을 제대로 만들어 줘.

수정 후:

목적: 회계 담당자가 매달 팀 지출을 자기 스프레드시트로
수동으로 옮깁니다. 한 시간이나 걸리고 금액 입력 오류도 생깁니다.

작업: 월별 지출 페이지에 "CSV로 내보내기" 버튼을 추가합니다.

완료 조건:
- 파일을 스프레드시트 프로그램에서 더블 클릭으로 열 수 있고, 한국어
  항목명이 인코딩을 수동 설정하지 않아도 올바르게 표시됩니다;
- 데이터 한 행은 지출 한 건이며, 첫 행에는 열 이름이 있습니다;
- 셀을 수정하지 않아도 수식으로 금액을 합산할 수 있습니다.

건드리지 말 것: 지출 저장 형식과 기존 목록 화면.
먼저 계획과 각 항목을 확인할 방법을 보여 주세요.

두 번째 요청에서는 에이전트가 추측할 일이 거의 없습니다. 무엇보다 결과를 비교할 기준이 있습니다. 세 항목은 몇 분이면 직접 확인할 수 있습니다. 첫 번째 요청의 "제대로"는 검증할 수 없습니다. 그냥 믿을 수밖에 없죠.

에이전트는 좋은 결과를 모릅니다

이제부터는 자료 자체보다 자료에서 제가 도출한 결론을 주로 다룹니다. 제 의견을 연구 결과처럼 말하지 않도록 먼저 밝혀 둡니다.

에이전트는 많은 일을 할 수 있습니다. 낯선 프로젝트를 읽고, 오류 원인을 찾고, 구현을 작성하고, 테스트를 실행하고, 무엇을 했는지 설명할 수 있습니다. 하지만 이 사용자와 이 비즈니스에 "잘했다"는 것이 무엇인지 스스로 판단할 수는 없습니다. 기준이 없으면 그럴듯한 보통의 선택지를 택하고 완성했다고 자신 있게 보고합니다. 코드는 깔끔해도 해결책은 여전히 틀릴 수 있습니다.

"좋은 결과"는 코드에 들어 있지 않습니다. 누가 결과를 사용할지, 그 사람에게 무엇이 중요한지, 어떤 오류를 용납할 수 없는지에 따라 달라집니다. 내보내기 예시에서 에이전트는 기술적으로는 올바르지만 회계 담당자가 열면 글자가 깨지는 CSV를 만들 수도 있습니다. 코드 관점에서는 맞아도 작업의 목적에는 맞지 않습니다.

결론은 간단합니다. 기준을 정하고 그에 따라 결과를 확인하는 일은 위임할 수 없습니다. 에이전트는 기준을 정리하도록 돕고, 추가 질문을 던지고, 검증 방법을 제안할 수 있습니다. 하지만 그 기준이 적절한지 결정하는 일은 여러분에게 남아 있습니다.

먼저 업무 흐름 이해하기

기준은 어디서 나올까요? 대부분 코드에서 나오지 않습니다. 업무 흐름에서 나옵니다. 누가 파일을 열고 다음에 무엇을 할지, 행 하나가 빠지거나 금액이 잘못 반올림되면 어떤 일이 생길지 살펴봐야 합니다.

"한국어 항목명이 인코딩을 수동 설정하지 않아도 올바르게 표시된다"는 조건은 CSV를 그렇게 작성하는 게 정석이라서 생긴 것이 아닙니다. 누군가 회계 담당자에게 파일을 어떻게 여는지 물어보고, 가져오기 마법사 없이 더블 클릭으로 연다는 걸 확인했기 때문입니다. 업무 흐름을 아는 개발자는 이 기준을 처음부터 적습니다. 모르는 개발자는 한 달 뒤 불만을 듣고서야 알게 됩니다.

기업들도 이런 변화를 알아차리고 역할을 재구성하고 있습니다.

반대되는 관점도 알아둘 필요가 있습니다. 예를 들어 컨설팅 회사 Converteo는 블로그에서 제품 관리자, 디자이너, AI product builder가 경쟁자가 아니라 서로 보완하는 역할이라고 설명합니다. 제품 관리자는 "왜"를, 디자이너는 사용자를, AI product builder는 아이디어를 빠르게 작동하는 프로토타입으로 만드는 일을 맡습니다. Converteo 역시 이 분야의 서비스를 판매합니다. 어느 한쪽에 손을 들어주지는 않겠습니다. 여러분이 기억할 실무적인 결론은 같습니다. 고객의 업무 흐름을 이해하는 개발자는 완벽하게 작성된 티켓만 기다리는 개발자보다 가치가 큽니다.

대화를 업무 도구로 활용하기

예전에는 soft skills를 기술 역량에 더하는 부가 요소로 여기는 경우가 많았습니다. 에이전트와 함께 일하게 되면서 이 인식이 달라지고 있습니다. 품질 기준은 저장소가 아니라 사람들의 머릿속에 있습니다. 대화를 통해서만 끌어낼 수 있죠.

실제로 업무에는 다음과 같은 일도 포함됩니다.

• 질문하기. "무엇을 만들까요?"보다 "결과를 어떻게 사용하실 건가요?"라고 물으면 더 정확한 답을 들을 수 있습니다;
• 구체적으로 확인하기. 예외 상황이 버그가 되기 전에 다시 물어보세요. 카테고리가 없는 지출은 어떻게 처리할까요?
• 기록하기. 대화로만 나눈 합의는 에이전트가 읽지 못하고 동료도 잊어버립니다;
• 범위 합의하기. 작업에 포함되는 것과 아닌 것을 정하고, "이것도 같이 고쳐 주세요"라는 요청에는 "별도 작업입니다"라고 말합니다;
• 절충안 설명하기. "기간 선택 없이 하루 만에 만들거나, 선택 기능을 넣어 사흘 안에 만들 수 있습니다"처럼 선택은 고객이 하더라도 대안은 여러분이 제시합니다.

이 중 어느 것도 코드에 관한 역량은 아니지만, 모두 에이전트의 결과에 직접 영향을 줍니다. 결국 사람들과 나눈 대화의 질이 에이전트에게 전달하는 작업 설명의 질이 됩니다.

모두가 조금씩 CEO

모든 내용을 모아 보면 익숙한 모습이 드러납니다. 목표를 세우고, 기준을 정하고, 일을 나누고, 결과를 확인하고 책임지는 일은 리더의 역할입니다. 에이전트와 일하는 개발자는 작은 규모로나마 매일 이런 일을 합니다.

CEO 비유의 장점은 책임이 어디에 있는지 잘 보여 준다는 점입니다. CEO는 결과에 대한 책임을 제외하면 거의 모든 일을 위임할 수 있습니다. 에이전트도 마찬가지입니다. 에이전트가 회계 담당자의 스프레드시트를 망가뜨리는 내보내기 기능을 만들었다면 책임은 에이전트가 아니라 사람에게 있습니다.

이 비유가 뜻하지 않는 바도 짚어 두겠습니다. 직급이 올라간다는 뜻은 아니며, 에이전트 세 개를 실행했다고 리더가 되는 것도 아닙니다. 리더의 역량이 예전보다 이른 시기, 첫 직장부터 필요해질 수 있다는 뜻에 가깝습니다. 위험도 있습니다. 개발자는 오랫동안 직접 코드를 작성하며 성장해 왔는데, 이 경로가 달라지고 있습니다. 에이전트에게서 넘겨받는 코드를 이해하는 일은 여전히 필수입니다. 그렇지 않으면 검증이 "대충 작동하는 것 같다"에서 멈춥니다.

자료를 읽는 방법

위의 수치는 모두 AI 또는 관련 제품을 판매하는 기업이 발표했습니다. 그렇다고 거짓이라는 뜻은 아니지만, 염두에 둘 필요가 있습니다. 간단히 정리해 보겠습니다.

여기서 언급한 모든 비율은 특정 시점에 응답자들이 스스로 평가한 결과입니다. 실제로 일어난 일을 보여 주기보다 사람들이 무엇을 생각하고 기대하는지 보여 줍니다. Work Trend Index 2026의 저자들도 분석에서 발견한 관계는 통계적 연관성일 뿐, 인과 관계가 아니라고 분명히 밝힙니다.

AI와 업무에 관한 수치를 볼 때는 세 가지를 물어보면 좋습니다. 누가 연구 비용을 댔나요? 측정한 것은 의견, 기대, 실제 결과 중 무엇인가요? 누구에게 물었고, 그 사람들이 여러분과 비슷한가요? 답이 납득된다면 수치를 활용할 수 있습니다. 그렇지 않더라도 흥미로운 자료일 수는 있습니다. 다만 무게가 덜할 뿐입니다.

이 모든 것이 향하는 곳

앞에서 다룬 보고서의 언어는 Claude Code를 사용할 때 다음과 같은 구체적인 습관으로 이어집니다.

• 수정 전 계획 - 이것이 바로 의도입니다. 에이전트가 무엇을 어떻게 바꿀지 먼저 보여 달라고 한 뒤 여러분의 의도와 비교하세요;
• 요청에 인수 기준 명시 - 여러분의 완료 기준입니다. "제대로" 대신 검증할 수 있는 항목 두세 가지를 적으세요;
• 작업 모드와 권한 규칙 - 방식의 선택입니다. 오류 비용이 클수록 에이전트가 멈추고 확인을 자주 요청합니다;
• diff 확인과 정직한 검증 - 에이전트의 보고가 아니라 여러분의 기준으로 결과를 평가합니다;
• 간단한 결과 요약: 완료한 일, 확인 방법, 미확인 항목 - 에이전트에게 넘길 수 없는 결과에 대한 책임입니다.

자료 기준: 2026년 9월. 이 분야의 연구는 자주 발표되므로 수치는 결론보다 빠르게 오래된 정보가 됩니다.