AI 시대 개발자는 에이전트에 구현을 맡기는 능력과 함께, 무엇을 만들고 어떤 결과를 받아들일지 판단하는 능력을 길러야 합니다. 프로젝트의 맥락을 정리하고, 검증 가능한 계획을 세우고, 테스트와 리뷰로 결과를 확인하는 일이 그 출발점입니다. 이 과정에서 쌓이는 안목은 좋은 결과를 알아보고 그 이유를 설명할 수 있는 실무 역량입니다.
Microsoft의 Jay Parikh는 2026년 6월 2일 공개한 글에서 에이전트 중심 개발, 컨텍스트와 스킬, 계획, 프로토타입, 안목, 미뤄 둔 중요 업무, 테스트, 코드 리뷰, 개발 과정 전반의 변화, 코드의 교체 가능성을 제안했습니다. 이는 변화에 대응하는 실무 관점이며, 모든 조직의 생산성을 보장하는 법칙은 아닙니다. 아래는 이 제안을 다른 공식 개발 문서와 연결해 적용한 편집 가이드입니다.
AI 시대 개발자에게 에이전트 활용이 기본이라는 뜻
새 작업을 받으면 에이전트가 수행할 수 있는 범위부터 나눠 보세요. 이 글에서 에이전트는 목표를 받아 파일을 읽고, 코드를 수정하고, 명령을 실행하면서 작업을 이어 가는 AI 도구를 뜻합니다. 맡긴 결과를 판단하려면 사람이 먼저 작업 범위와 접근 권한, 완료 기준을 정해야 합니다.
가령 관리 화면에 ‘주문 목록을 표 파일로 내려받기’ 기능을 추가한다고 해보겠습니다. 기존 조회 코드 탐색, 수정안 작성, 테스트 실행은 에이전트가 맡을 수 있는 일입니다. 개발자는 누가 어떤 주문을 내려받을 수 있는지, 고객 연락처를 포함해도 되는지, 내려받은 파일로 사용자가 무슨 일을 하는지를 결정합니다. 파일 형식은 쉼표로 열을 구분하는 CSV로 정했다고 가정하겠습니다.
처음에는 영향 범위가 작고 성공 여부를 확인하기 쉬운 작업을 고르는 편을 권합니다. 요청도 ‘내보내기 기능을 만들어 줘’에서 끝내지 말고, 먼저 관련 코드와 권한 검사를 찾아 계획을 제시하도록 하세요. Claude Code 공식 문서도 탐색과 계획을 구현에서 분리하고, 에이전트가 스스로 실행할 수 있는 검증 기준을 제공하도록 권장합니다.
도입 효과는 체감만으로 판단하기 어렵습니다. METR는 2026년 2월 후속 연구에서 AI 사용의 생산성 효과를 추정할 때 참여자 선택과 작업 시간 측정 문제가 발생했다고 밝혔습니다. 팀에서는 작업 시작부터 리뷰 완료까지 걸린 시간, 수정 요청, 배포 후 문제를 함께 기록해 어떤 업무에 도움이 되는지 판단하는 편이 좋습니다.
컨텍스트와 스킬을 팀의 자산으로 남기기
에이전트가 알아야 할 배경과 반복해서 따라야 할 절차는 저장소에 남깁니다. 작업을 이해하는 데 필요한 코드·문서·제약 같은 배경 정보가 컨텍스트이고, 특정 업무의 지침·참고 자료·실행 도구를 재사용하도록 묶은 것이 스킬입니다. Anthropic의 Agent Skills도 지침과 스크립트, 자료를 폴더로 묶고 필요한 내용을 선택해 읽는 구조를 사용합니다.
| 구분 | 주문 CSV 내보내기 사례 |
|---|---|
| 컨텍스트 | 주문 데이터 구조, 접근 권한, 현재 조회 필터 |
| 스킬 | 내보내기 작업의 점검 순서와 검증 명령 |
| 이번 요청 | 현재 필터를 적용하고 허용된 열만 내보내기 |
예를 들어 에이전트가 다운로드 기능을 만들 때마다 권한 조건을 놓친다면, 채팅에서 지적한 뒤 끝내지 마세요. 어떤 사용자가 어떤 데이터를 볼 수 있는지 문서에 남기고, 다른 사용자의 주문이 섞이지 않는지 테스트로 확인하게 만듭니다. 스킬에는 적용할 작업, 읽을 문서, 실행할 검사, 실패했을 때 보고할 내용을 적습니다. 잘못된 절차가 반복되지 않도록 변경 내용은 사람이 확인해야 합니다.
문서는 현재 코드와 함께 관리합니다. 담당자와 수정 계기를 정하고, 쓰지 않는 규칙은 걷어 내세요. 모든 대화 기록을 계속 붙이기보다 지금 작업에 필요한 문서와 코드 위치를 알려 주는 방식이 낫습니다. 한 번에 다룰 수 있는 정보의 범위가 궁금하다면 컨텍스트 윈도우 설명을 함께 읽어 보세요.
계획과 프로토타입으로 무엇을 먼저 확인할까?
계획의 가치는 구현 전에 중요한 선택을 드러내는 데 있습니다. 이번 작업의 목표, 제외 범위, 지켜야 할 조건, 성공을 확인할 방법을 정하세요. 화면이나 사용 흐름에 대한 가정은 작동하는 시제품, 즉 프로토타입으로 확인하면 됩니다.
제품 요구사항을 정리한 문서인 PRD를 자세히 쓰기 전에, 지금 모르는 것이 무엇인지 구분해 보세요. 다운로드 버튼의 위치가 적절한지 모르겠다면 화면을 만들어 사용자가 찾는지 확인할 수 있습니다. 반면 어떤 고객 정보를 내보낼 수 있는지는 화면 실험 전에 정해야 할 조건입니다. 프로토타입으로 확인할 가정과 문서로 합의할 제약은 역할이 다릅니다.
주문 CSV 기능의 작업 계획은 다음처럼 시작할 수 있습니다. 아래는 실제 요구사항이 아닌 설명용 예시입니다.
목표: 운영 담당자가 현재 조회 중인 주문을 CSV로 내려받는다.
범위: 현재 필터와 정렬을 유지하고, 합의한 열만 포함한다.
제외: 예약 전송과 다른 파일 형식 지원은 이번에 만들지 않는다.
완료 기준: 권한 밖 주문이 포함되지 않고, 빈 결과와 다운로드 실패 상태가 구분된다.
검증: 권한·필터·출력 파일을 확인하고 실제 화면에서 내려받아 본다.
그다음 가상 주문 데이터로 화면과 파일을 만들어 운영 담당자에게 보여 주세요. 열 이름이나 정렬 순서가 실제 업무에 맞지 않는다는 피드백이 나오면 그 결정부터 갱신합니다. 구현 세부 사항을 미리 모두 확정하려 하기보다, 확인한 요구사항을 다음 작업의 기준으로 쌓는 방식입니다. 요청을 구체화하는 방법은 프롬프트 엔지니어링의 기본 원칙과도 연결됩니다.
테스트와 코드 리뷰가 개발 속도를 받쳐 주게 하려면
에이전트가 코드를 만든 뒤에는 요구사항을 만족한다는 증거가 필요합니다. 자동으로 확인할 조건은 테스트로 만들고, 사람의 리뷰는 제품 동작과 구조적 위험에 집중하도록 변경을 나누세요.
테스트는 안전장치입니다. 주문 CSV 기능이라면 파일이 생성되는지만 검사해서는 부족합니다. 다른 계정의 주문이 섞이지 않는지, 선택한 필터가 유지되는지, 쉼표나 줄바꿈이 든 값이 올바른 열에 남는지까지 확인해야 합니다. 예상 결과는 요구사항에서 정하고, 에이전트가 만든 코드에 맞춰 기대값을 바꾸지 않도록 검토하세요.
AWS의 에이전트 개발 아키텍처 가이드는 빠른 개별 로직 검사, 서비스 사이 약속을 확인하는 검사, 배포 환경에서 기본 동작을 확인하는 검사를 구분합니다. 로컬에서 빠르게 반복하더라도 실제 환경에서만 드러나는 설정과 권한 문제를 확인할 단계는 필요합니다.
코드 리뷰의 병목은 변경 범위부터 줄여 해결하세요. 코드 변경을 검토하고 합치는 요청인 PR에는 한 가지 목적을 담는 편이 좋습니다. CSV 기능을 추가하면서 관계없는 화면 개편까지 묶으면 검토자가 확인해야 할 가정이 늘어납니다. Google의 리뷰 지침도 작고 독립적인 변경이 더 빠르고 충실한 검토에 유리하다고 설명합니다.
에이전트에는 변경 요약, 빠진 검사 후보, 기존 규칙과의 충돌을 먼저 점검하게 할 수 있습니다. 사람에게는 해결하려는 문제, 실제로 바뀐 동작, 실행한 검증과 남은 위험을 전달하세요. 자동 리뷰의 통과 여부만 보고 합치기보다, 결과가 적절한지 확인할 근거를 함께 받는 운영을 권합니다.
미뤄 둔 운영 업무에도 에이전트 활용하기
새 기능을 만드는 데만 에이전트를 쓰지 말고, 반복되는 오류와 운영 부담을 줄이는 일에도 배정하세요. 계획·구현·검증·배포·운영 중 어디에 대기가 쌓이는지 보면 다음 개선 대상을 고를 수 있습니다.
주문 CSV 기능을 둘러싼 업무를 떠올려 보세요. 다운로드 실패가 자주 접수되지만 재현 조건이 정리되지 않았거나, 운영 담당자가 매번 파일을 손으로 고치고 있을 수 있습니다. 오류 기록의 공통 조건 정리와 재현 테스트 초안은 에이전트에 맡기고, 영향과 우선순위는 사람이 판단하는 방식으로 시작할 수 있습니다. 중요하지만 뒷전으로 밀린 일은 별도의 작업으로 등록해야 실제 개선으로 이어집니다.
코드 작성 이후도 살펴야 합니다. 테스트 실행이 느리면 피드백이 늦고, 검토 담당자가 불분명하면 변경이 쌓입니다. 배포 뒤 오류를 확인할 사람이 없으면 문제를 발견해도 대응이 늦어집니다. 팀 회의에서도 작성한 코드량과 함께 리뷰 대기, 반복 수정, 운영 문제를 다루세요. 에이전트 도입을 업무 전체의 개선으로 연결하기 위한 편집자의 제안입니다.
‘코드는 일회용’이라는 관점은 구현을 버릴 수 있어야 한다는 뜻으로 적용하세요. 검증된 요구사항과 테스트가 있다면 목적에 맞지 않는 구현을 교체하는 판단이 쉬워집니다. 다만 운영 중인 코드는 사용자 데이터, 외부 연동, 배포 절차와 연결돼 있습니다. 다시 생성할 수 있다는 이유만으로 전체 재작성을 선택하지 말고, 교체 범위와 되돌릴 방법을 먼저 정하세요.
결국 차이를 만드는 안목은 어떻게 기를까?
안목은 여러 결과 가운데 사용자에게 더 적합한 것을 고르고, 그 이유를 일관되게 설명하는 능력입니다. 구현을 빠르게 시도할 수 있을수록 무엇을 선택하고 무엇을 버릴지 판단하는 역량에 투자할 가치가 커집니다.
같은 CSV 기능에서도 보기 좋은 다운로드 버튼만으로 품질을 판단할 수는 없습니다. 필요한 열이 빠져 사용자가 다시 편집해야 하는지, 빈 결과를 실패로 오해하는지, 고객 정보가 불필요하게 노출되는지를 봐야 합니다. 미적인 취향뿐 아니라 업무 이해, 정확성, 접근성, 운영 부담까지 판단의 대상입니다.
안목을 기르려면 결과물에 대한 평가를 구체적인 이유로 남겨 보세요. ‘이 화면이 더 좋다’ 대신 ‘다운로드 가능 여부를 버튼 옆에서 알 수 있어 실패 후 재시도를 줄일 수 있다’처럼 설명합니다. 실제 사용자의 행동이 예상과 다르면 판단을 수정하세요. 마음에 드는 예시와 피하고 싶은 예시를 이유와 함께 모으면, 다음 계획과 스킬에 전달할 기준이 됩니다.
다음 작업에서는 미뤄 둔 문제 하나를 골라 완료 조건을 쓰고, 에이전트에 탐색과 구현을 맡긴 뒤 결과를 검증해 보세요. 작업이 끝나면 코드 외에 무엇을 남길지 결정합니다. 다음에도 유효할 요구사항, 실패를 잡아낼 테스트, 선택의 이유를 설명하는 기록이 쌓일수록 개발자의 판단을 팀이 재사용할 수 있습니다.
자주 묻는 질문
주니어 개발자는 코딩 공부를 줄이고 AI 도구만 익혀도 될까요?
코드를 읽고 원인을 추적하는 공부는 계속하는 편을 권합니다. 에이전트의 수정이 왜 맞는지 판단하려면 데이터 흐름, 자료구조, 네트워크, 데이터베이스, 테스트의 기본을 이해해야 합니다. 작은 기능의 동작을 먼저 예측하고 생성된 코드와 실행 결과를 비교하는 방식으로 AI 활용과 기본기 학습을 연결해 보세요.
스킬을 만들면 AI 모델이 우리 팀의 방식을 학습하나요?
스킬 파일을 만드는 것만으로 모델 자체가 추가 학습되지는 않습니다. 에이전트가 작업 중 참고할 지침과 자료, 실행 도구를 제공하는 방식입니다. 수정한 스킬이 다음 작업에 적용되는지는 사용하는 도구의 스킬 탐색·불러오기 방식에 따라 확인해야 합니다.
여러 에이전트를 동시에 쓰는 것부터 시작해야 하나요?
처음에는 하나의 에이전트로 작업 범위와 검증 방법을 익히는 편을 권합니다. 독립적으로 처리할 수 있는 일이 분명해졌을 때 병렬 작업을 시도하세요. 같은 파일이나 같은 설계 결정을 동시에 수정하는 작업은 결과를 합치는 부담까지 고려해야 합니다.
참고 자료
- Introducing Command Line, and the new rules for builders — Microsoft Command Line
- Best practices for Claude Code — Anthropic
- Equipping agents for the real world with Agent Skills — Anthropic
- Architecting for agentic AI development on AWS — Amazon Web Services
- Small CLs — Google Engineering Practices
- We are Changing our Developer Productivity Experiment Design — METR