AI 동료와 일할수록 코딩보다 검증이 일이 된다
논문 『Human-AI Collaboration and the Transformation of Software Engineering Work』를 읽고
생성형 AI와 에이전트가 소프트웨어 일을 코드 작성량이 아니라 의도 지정, 검증, 통제, 책임의 문제로 바꾸고 있음을 업무설계 관점에서 읽는다.
제일 먼저 든 생각
AI 에이전트를 업무에 붙일 때 자꾸 “얼마나 빨리 만들어내는가”를 먼저 묻게 된다. 그런데 이 논문은 그 질문이 이미 조금 낡았다고 말한다. 코드가 빨리, 많이, 싸게 만들어지는 환경에서는 병목이 생산량에서 사라지는 것이 아니라 의도를 정확히 주고, 결과를 검증하고, 조직이 책임질 수 있게 묶는 일로 이동한다.
AI 코딩과 에이전트를 업무에 붙이면 사람의 일이 사라진다기보다 위치가 바뀐다. 코드를 직접 쓰는 시간은 줄어도, 의도를 지정하고 결과를 검증하며 책임 경계를 세우는 일이 더 커진다.
논문의 대상은 소프트웨어 엔지니어링이지만, 나는 이 문장을 거의 모든 지식노동에 옮겨 읽었다. 보고서 초안, 교육 설계, 평가 문항, 분석 코드, 대시보드 설명까지 AI가 “작성”을 맡기 시작하면 사람의 일은 덜 중요해지는 것이 아니라 다른 곳으로 이동한다. 이제 사람은 작업자가 아니라 작은 팀을 맡은 리더처럼, AI 산출물의 방향·품질·위험을 관리해야 한다.
코드 작성량보다 의도 지정, 검증, 통제 역량이 더 중요해지는 흐름으로 읽었다.
코드가 많아질수록 값어치가 옮겨간다
논문은 생성형 AI(Generative AI)와 에이전트형 AI(agentic AI)가 소프트웨어 개발을 “사람이 코드를 쓰는 활동”에서 “자율·반자율 시스템을 지시하고 검증하고 통제하는 활동”으로 바꾸고 있다고 정리한다. 특히 눈에 남은 부분은 다음 문장이다.
코드가 풍부해질수록, 소프트웨어 엔지니어의 지속적인 가치는 작성한 코드의 양이 아니라 의도 명세, 비판적 판단, 책임 있는 감독에 점점 더 놓인다.
“as code becomes abundant, the durable value of the software engineer increasingly resides in intent specification, critical judgment, and accountable oversight rather than in the sheer volume of code produced.”
이 말은 “개발자는 이제 프롬프트만 잘 쓰면 된다”는 단순한 주장과 다르다. 논문은 오히려 더 많은 역량을 요구한다. 문제 분해, 전략적 계획, 다중 에이전트 조율, 워크플로 설계, 보안 검토, 엣지 케이스 확인, 시스템 통합 판단 같은 능력이 함께 올라온다. AI가 산출물을 늘릴수록 사람에게 남는 일은 마지막 승인 버튼이 아니라, 무엇을 맡길 수 있고 어디서 반드시 멈춰 세워야 하는지 아는 일에 가깝다.
벤치마크 성능과 현장 신뢰 사이의 간격
논문이 조심스럽게 보는 지점도 중요하다. 에이전트가 코드 제출을 크게 늘릴 수는 있지만, 실제 오픈소스 현장에서는 사람 개발자의 기여보다 수용률이 낮거나 구조적 변경 폭이 작다는 연구 흐름을 함께 언급한다. 즉 “AI가 풀었다”와 “팀이 믿고 통합했다” 사이에는 거리가 있다.
이 간격은 개발 조직에만 있는 문제가 아니다. HRD에서 AI가 교육과정 초안을 만들었을 때, People Analytics에서 AI가 원인 가설을 냈을 때, 보고 자동화에서 AI가 설명 문장을 붙였을 때도 같은 질문이 생긴다.
- 이 산출물은 누가 검토했는가?
- 어떤 기준으로 통과시켰는가?
- 실패하면 어느 단계로 되돌아가는가?
- 다음 작업자가 이 판단의 근거를 추적할 수 있는가?
논문이 제안하는 역량 프레임은 기술 역량만이 아니라 인지적, 사회기술적, 거버넌스, 조직 역량을 함께 본다. 이 구성이 마음에 들었다. AI 업무설계에서 “툴 교육”만 하면 자꾸 사용법으로 좁아진다. 실제로 필요한 것은 도구 숙련과 함께 책임 구조를 설계하는 능력이다.
원문 첫 페이지. 논문은 소프트웨어 엔지니어링의 변화이지만, 지식노동 전반의 AI 역할 재설계 질문으로 확장해 읽을 수 있다.
내 일에 붙이면 먼저 바꿀 체크포인트
이 논문을 바로 조직에 적용한다면 “AI로 더 많이 만들자”보다 “검증 가능한 하이브리드 업무 단위”를 먼저 정의하고 싶다.
-
작업을 생산 단계와 검증 단계로 분리하기
AI가 초안을 만든다면, 사람의 검토는 감상평이 아니라 체크리스트여야 한다. 요구사항 충족, 근거 출처, 예외 조건, 보안·개인정보, 다음 작업 영향처럼 검토 항목을 명시해야 한다. -
프롬프트를 요청문이 아니라 실행 명세로 다루기
논문은 지시 설계(instruction design)를 실행 가능한 명세처럼 봐야 한다고 읽힌다. “보고서 써줘”가 아니라 목적, 독자, 제외할 내용, 검증 기준, 실패 시 멈출 조건을 함께 주는 방식이다. -
AI 산출물의 수용률을 지표로 보기
산출량만 세면 AI 도입은 성공처럼 보인다. 하지만 실제로는 검토 후 통과율, 수정 횟수, 재작업 원인, 사람 검토 시간, 사고·오류 유형을 같이 봐야 한다.
오늘 남기는 질문
다음 주 업무 중 하나를 골라, AI에게 맡긴 산출물마다 “생산 시간”이 아니라 검토 기준, 반려 사유, 최종 책임자를 남겨보면 어떨까. AI 동료가 늘어나는 조직에서 먼저 필요한 것은 더 큰 자동화가 아니라, 사람이 어디서 판단했는지 보이는 작은 운영 장부일 수 있다.
함께 읽을 노트
원문 정보
- 제목: Human-AI Collaboration and the Transformation of Software Engineering Work
- 저자: Mamdouh Alenezi
- 소속: Saudi Data and Artificial Intelligence (SDAIA), 논문 표기 기준
- 연도/게시일: 2026
- 게재/출처: arXiv
- arXiv: 2606.03394v1
- PDF: https://arxiv.org/pdf/2606.03394