코딩 에이전트는 리서치와 데이터 업무를 아는 사람이 작은 도구를 직접 만들 수 있는 범위를 넓혔다. 파일을 읽고 표를 만드는 Python 코드를 처음부터 외우지 않아도 실행 가능한 초안을 얻는다. 결과가 업무 규칙에 맞는지 판단하려면 해당 분야의 정의와 예외를 알아야 한다.
Anthropic은 2025년 10월부터 2026년 4월까지 약 23만5천 명이 사용한 Claude Code 세션 약 40만 건을 개인정보 보호 방식으로 분석했다. 연구진은 작업 구성과 사람·에이전트의 결정, 검증 가능한 성공을 살폈다. 전형적인 세션에서 사람은 무엇을 만들지에 관한 계획 결정을 더 많이 했고 Claude는 구현 방법에 관한 실행 결정을 더 많이 했다.
도메인 전문성이 높은 사용자는 한 번의 지시로 더 많은 작업을 맡겼고 세션 성공률도 높았다. 전문가와 중간 숙련자의 격차는 크지 않았다는 결과도 함께 나왔다. 이 연구를 전문성의 필요 여부로 단순화하기보다 어떤 지식을 에이전트의 입력과 검증에 사용했는지 살펴볼 필요가 있다.
연구 결과가 말하지 않는 범위
분석 대상은 이미 Claude Code를 사용한 사람과 세션이다. 코딩 에이전트를 시도하지 않은 전체 노동자를 대표하지 않는다. 연구진이 사용한 성공은 사용자가 의도한 작업을 마쳤고 테스트 통과나 커밋 같은 증거가 있는지를 바탕으로 한다. 배포 후 유지보수성과 장기적인 사업 성과까지 측정한 값은 아니다.
소프트웨어 직군이 아닌 사용자도 코딩 작업에서 소프트웨어 엔지니어와 가까운 평균 성공률을 보였다는 결과는 흥미롭다. 각 직군의 표본과 작업 종류, 사용자의 자기선택을 고려해야 한다. 회계 전문가가 회계 자동화를 만든 세션과 처음 보는 네트워크 드라이버를 수정하는 세션은 요구하는 지식이 다르다.
내가 가져가는 결론은 좁다. 사용자가 업무의 입력과 예외, 완료 조건을 설명할 수 있으면 에이전트가 구현 결정을 더 많이 맡을 수 있다. 코딩 경험이 있어도 업무 정의를 잘못 이해하면 실행 가능한 오답을 만든다.
도메인 지식은 의심할 위치를 알려 준다
리서치 자동화에서 에이전트는 CSV를 읽고 교차표를 만들 수 있다. 리서처는 다음 판단을 내려야 한다.
- 결측값이 시스템 오류인지 응답자의 선택인지 구분한다.
- 가중치 적용 전후 가운데 보고 목적에 맞는 값을 고른다.
- 소수 표본 공개가 개인 식별 위험을 만드는지 본다.
- 같은 변수명이 조사 시점마다 같은 정의를 쓰는지 확인한다.
- 설문 문항의 변경이 시계열 비교를 깨뜨리는지 판단한다.
- 합계 차이가 반올림인지 중복 응답인지 찾는다.
전문가는 답을 외워 두기보다 결과가 이상할 때 볼 위치를 안다. 합계가 100%를 넘으면 다중 응답 문항인지 확인하고, 전월 대비 값이 급증하면 모집단과 필터가 바뀌었는지 살핀다. 이 순서를 에이전트에게 전달하면 오류 탐색 범위를 줄일 수 있다.
법률과 재무, 의료처럼 규정과 자격이 필요한 분야에서는 코딩 에이전트의 성공이 전문 검토를 대체하지 않는다. 도메인 전문가는 코드가 실행되는지와 별개로 결과를 사용할 수 있는 범위와 책임을 정한다.
암묵지를 네 종류의 파일로 꺼낸다
머릿속의 판단을 매 세션 설명하면 표현이 달라지고 일부 조건을 빠뜨린다. 나는 반복되는 지식을 다음 파일로 옮긴다.
glossary.md 용어, 단위, 허용된 동의어
examples/ 승인된 결과와 실패 사례
rules.yaml 임계값, 예외, 공개 제한
validators/ 테스트, 쿼리, 스키마 검사
용어집에는 정의의 출처와 적용 기간을 붙인다. “활성 고객”이 팀마다 다른 기간을 뜻하면 하나의 정의로 강제하지 않고 보고서별 별칭과 계산식을 기록한다.
예시 폴더에는 좋은 결과만 넣지 않는다. 틀린 표와 반려 이유를 함께 둔다. 에이전트는 정답 형식과 피해야 할 오류를 비교할 수 있다. 개인정보가 들어간 실제 사례는 익명화하거나 합성 데이터로 바꾼다.
규칙 파일은 사람이 승인한 업무 결정을 보관한다.
minimum_base_size: 30
percentage_tolerance: 0.2
small_cell_policy: suppress
required_dimensions:
- survey_wave
- population
validator는 규칙을 실행한다. 표본 수가 30 미만이면 경고하고, 백분율 합계가 허용 범위를 벗어나면 다중 응답 여부를 확인하도록 결과를 낸다. 검사 종료 코드가 다음 단계를 정한다.
한 작업을 에이전트가 읽을 수 있게 쓰는 법
“이 설문을 분석해 줘”라는 요청에는 분석 단위와 제외 조건이 없다. 나는 작업 요청에 다음 항목을 넣는다.
목적: 어떤 결정을 돕는 분석인가
입력: 파일, 스키마, 조사 시점과 모집단
정의: 지표 계산식과 허용된 값
예외: 결측, 중복, 소수 표본 처리
출력: 표와 차트, 근거 메모 형식
검증: 실행할 쿼리와 사람이 볼 표본
금지: 공개하면 안 되는 필드와 외부 전송
작업 목적이 달라지면 같은 데이터도 다른 결과를 낸다. 고객 이탈 원인을 찾는 분석과 경영진 보고용 추세 표는 필요한 세분화와 표현이 다르다. 목적을 먼저 적으면 에이전트가 모든 열을 무작정 차트로 만들지 않는다.
입력 스키마도 파일 이름만 주지 않는다. 각 열의 단위와 허용 값, 개인정보 여부를 붙인다. 검증 명령에는 예상 행 수와 고유 키, 기준 보고서의 값까지 넣을 수 있다.
오류 복구가 전문성을 드러낸다
Anthropic 연구는 도메인 전문가가 오류와 오해에서 더 잘 회복하는 경향을 보고했다. 실무에서도 첫 출력의 완성도보다 오류를 분류하고 다음 지시로 바꾸는 능력이 중요하다.
나는 오류를 다음 형식으로 기록한다.
관찰: 가중 백분율 합계가 104.7%
가능한 원인: 중복 응답 또는 분모 필터 불일치
확인: question_type과 denominator 쿼리
결과: 다중 응답 문항으로 확인
조치: 합계 100% 검사를 해당 문항 유형에서 제외
원인을 확인하기 전에 코드를 고치면 올바른 예외를 오류로 처리할 수 있다. 도메인 전문가는 가능한 원인을 좁히고 확인 순서를 정한다. 해결한 규칙은 validator와 사례 파일에 반영해 다음 세션이 같은 조사부터 반복하지 않게 한다.
코드 전문성과 역할을 나눈다
도메인 전문가가 만든 도구도 보안과 성능, 배포를 검토해야 한다. 작은 내부 스크립트가 고객 데이터를 외부 API로 보내거나 권한 없는 사용자가 파일을 열게 만들 수 있다. 작업 위험이 커지면 소프트웨어 전문가와 협업한다.
| 단계 | 도메인 전문가 | 소프트웨어 전문가 |
|---|---|---|
| 문제 정의 | 지표, 예외, 사용 맥락 | 기술 제약과 대안 |
| 구현 검토 | 결과의 업무 타당성 | 구조, 오류 처리, 보안 |
| 테스트 | 기준 데이터와 반례 | 자동화된 테스트와 CI |
| 배포 | 승인자와 사용자 범위 | 접근 제어와 모니터링 |
에이전트는 두 사람 사이의 번역 비용을 줄일 수 있다. 도메인 규칙을 테스트 초안으로 바꾸고, 코드 diff를 업무 영향으로 설명한다. 최종 판단은 각 분야의 담당자가 맡는다.
초급자의 학습 경로를 보존한다
에이전트가 자료 정리와 기본 코딩을 맡으면 초급자가 예외를 만날 기회가 줄어든다. 결과 승인만 시키면 무엇을 확인해야 하는지 배우기 어렵다.
학습 단계에서는 원자료 일부를 직접 처리한 뒤 AI 결과와 비교하게 한다. 차이를 발견하면 어느 정의와 규칙을 사용했는지 설명하게 한다. 에이전트가 만든 코드에서 테스트 하나를 직접 추가하고 실패를 재현하는 훈련도 쓸 수 있다.
평가 기준은 처리한 행 수에 두지 않는다. 오류를 발견한 근거와 질문의 질, 규칙을 문서화한 기록을 본다. 초급자가 만든 좋은 반례는 다음 프로젝트의 validator가 된다.
코딩 에이전트가 작성하는 코드의 양이 늘수록 사람은 사용 맥락과 완료 증거를 더 정확히 제공해야 한다. 도메인 전문성은 용어집과 사례, 규칙, 검증기로 외부화할 수 있다. 나는 에이전트의 첫 결과보다 어떤 예외를 잡았고 그 판단을 다음 실행에 어떻게 남겼는지로 작업 품질을 평가한다.