AI 네이티브 엔지니어는 코드를 덜 쓰는 사람이 아니라 책임 경계를 설계하는 사람이다
논문 『From Determinism to Delegation: AI-Native Software Engineering and the Evolution of the Agentic Engineer』를 읽고
AI 에이전트가 코드를 쓰기 시작할 때 엔지니어의 일은 구현량보다 워크플로, 평가, 개입 조건, 책임 경계를 설계하는 쪽으로 이동한다는 논문을 업무 설계 관점에서 읽었다.
제일 먼저 든 생각
AI 에이전트 이야기를 할 때 가장 쉽게 빠지는 착각은 “이제 코드를 사람이 덜 쓰게 된다”는 식의 양적 변화다. 이 논문은 방향을 조금 다르게 잡는다. 일이 줄어드는가보다, 무엇을 일로 부를 것인가가 바뀐다는 쪽이다.
논문이 제안하는 이름은 Agentic Engineer다. 과장된 직함처럼 들릴 수 있지만, 핵심은 꽤 실무적이다. 에이전트가 계획하고, 도구를 호출하고, 여러 단계를 이어서 수행한다면 사람은 더 이상 함수 하나의 정답만 확인하지 않는다. 사람은 에이전트가 볼 수 있는 정보, 쓸 수 있는 도구, 실패했을 때 멈출 조건, 사람이 다시 들어갈 지점을 설계해야 한다.
논문이 말하는 전환은 “코드 작성 → 에이전트 워크플로 감독”에 가깝다. 이 그림은 그 전환을 업무 설계 관점으로 압축한 것이다.
함수가 아니라 워크플로가 작업 단위가 된다
논문은 전통적인 소프트웨어 엔지니어링의 기본 단위를 함수, 서비스, API, UI 컴포넌트 같은 결정론적 산출물로 본다. 입력이 있고, 기대 출력이 있으며, 테스트는 통과하거나 실패한다.
반면 에이전트형 시스템에서는 작업 단위가 감독되는 에이전트 워크플로(supervised agent workflow)로 이동한다. 여기서 설계 질문은 달라진다.
- 에이전트가 어떤 맥락을 볼 수 있는가
- 어떤 도구 호출을 허용할 것인가
- 어느 단계까지 스스로 수정하게 둘 것인가
- 어떤 출력은 사람이 검토해야 하는가
- 실패가 반복되면 어디서 멈출 것인가
업무 자동화에서도 그대로 적용된다. Power BI 리포트 초안을 만들게 하든, 평가 문항을 분류하게 하든, 회의록에서 후속 액션을 뽑게 하든, 중요한 것은 “프롬프트 하나”가 아니다. 입력-검색-판단-행동-검토-기록이 이어지는 작은 운영 환경이다.
정답 검사는 확률적 운영 판단으로 바뀐다
“작업 단위는 함수에서 감독되는 에이전트 워크플로로, 정답 모델은 이진 단언에서 불확실성 아래의 통계적 평가로, 책임 모델은 코드 저자성에서 결과 소유로 이동한다.”
Original: “the unit of work shifts from functions to supervised agent workflows, correctness shifts from binary assertions to statistical evaluation under uncertainty, and accountability shifts from code authorship to outcome ownership.”
이 문장이 마음에 남는 이유는, AI 업무 도입의 많은 실패가 바로 이 전환을 인정하지 않아서 생기기 때문이다. “맞았나 틀렸나”만으로는 부족한 일이 늘어난다. 에이전트가 94%의 성공률을 보일 때도 어떤 업무에서는 충분하고, 어떤 업무에서는 위험하다. 실패 한 번이 메일 오탈자인지, 고객 안내 오류인지, 평가 결과 왜곡인지에 따라 허용선이 달라진다.
그래서 논문은 정확성(correctness)을 지역적인 테스트가 아니라 과업 성공률, 충실성, 도구 사용 정확도, 환각 빈도 같은 평가 파이프라인으로 보아야 한다고 말한다. 이 조건에서 보여주는 것은 “에이전트가 똑똑해졌으니 맡기자”가 아니다. “맡길 수 있는 범위를 수치와 실패 비용으로 다시 정하자”에 가깝다.
책임은 작성자보다 운영 소유자에게 가까워진다
논문에서 더 중요한 대목은 책임(accountability)이다. 사람이 직접 코드를 쓸 때는 책임이 비교적 코드 작성자에게 붙는다. 하지만 에이전트가 여러 행동을 조합하면 책임은 산출물 하나가 아니라 운영 결과로 이동한다.
예를 들어 HRD 평가 자동화에서 AI가 학습자 답변을 요약하고 위험 신호를 표시한다고 하자. 문제가 생겼을 때 “모델이 그렇게 답했다”는 설명은 충분하지 않다. 누가 기준을 정했는지, 어떤 데이터가 들어갔는지, 어떤 임계값에서 사람이 개입했는지, 이력이 남았는지가 같이 책임의 일부가 된다.
이 관점은 Deciflow식 업무 설계에도 유용하다. 자동화의 주인을 “프롬프트를 만든 사람”으로 좁히지 말고, 워크플로의 관찰 지표와 중단 조건을 관리하는 사람으로 넓혀야 한다.
원문 첫 페이지. 이 논문은 실험 논문이라기보다 최근 연구 흐름을 종합해 AI 네이티브 소프트웨어 엔지니어링의 역할 변화를 정리한 포지션 페이퍼에 가깝다.
내 일에 붙이면 먼저 정해야 할 것
바로 큰 에이전트 플랫폼을 만들 필요는 없다. 오히려 작은 업무 하나를 놓고 다음 네 가지를 먼저 정하는 편이 낫다.
- 워크플로 단위: 자동화하려는 단위를 “문서 작성”이 아니라 “자료 수집 → 초안 → 검토 → 배포”처럼 쪼갠다.
- 평가 기준: 정답률 하나 대신 누락률, 재작업률, 검토 시간, 위험 오류를 같이 본다.
- 개입 조건: 어떤 점수·키워드·불확실성에서 사람이 반드시 들어갈지 정한다.
- 결과 소유: 에이전트 출력의 최종 책임자가 누구인지, 로그와 수정 이력을 어디에 남길지 정한다.
오늘의 작은 실험으로는 반복 보고서 초안 생성이 좋다. 에이전트에게 끝까지 맡기지 말고, 초안 생성 뒤 “근거 없는 주장”, “숫자 불일치”, “민감 표현”만 표시하게 만든다. 그런 다음 사람이 수정한 항목을 다음 평가 기준으로 되돌려 넣는다.
조심해서 읽을 점
이 논문은 새로운 역할을 설득력 있게 정리하지만, 특정 조직에서 실제 생산성이 얼마나 좋아지는지 직접 검증한 실험은 아니다. 따라서 “AI 네이티브 엔지니어가 미래 직무다”라고 단정하기보다, 에이전트형 업무를 설계할 때 필요한 책임·평가·감독의 언어를 제공한다고 읽는 편이 안전하다.
원문 정보
- 제목: From Determinism to Delegation: AI-Native Software Engineering and the Evolution of the Agentic Engineer
- 저자: Mamdouh Alenezi
- 연도/게시일: 2026
- 게재/출처: arXiv
- arXiv: 2606.28791v1
- PDF: https://arxiv.org/pdf/2606.28791