AI가 전문직의 일을 바꾸는 방식은 ‘누가 코드를 배울 것인가’보다 ‘누가 업무 시스템의 책임을 질 것인가’에 가깝다. 2026년 8월 23일 공개된 Engineerification은 수학자·디자이너·분석가·법률가가 저장소, 에이전트, 테스트, 자동화, 형식 명세, 피드백 루프를 업무에 들이는 장면을 묶어 설명한다.
원문이 붙인 이름은 ‘엔지니어화’다. 각 전문직이 소프트웨어 엔지니어가 된다는 뜻이 아니다. 전문가는 반복 업무의 결과물 하나하나를 직접 만드는 역할에서, 그 결과물을 만들어 내는 절차를 정의하고 감독하는 역할까지 맡게 된다. AI가 구현 부담을 낮출수록 이 변화는 더 빨리 찾아온다.
전문가는 왜 결과물보다 작업 흐름을 설계하게 되는가
전통적인 업무 단위는 보고서 한 편, 고객 한 명, 계약 한 건, 화면 한 장처럼 눈에 보이는 산출물이었다. 에이전트를 곁들이면 업무 단위가 달라진다. 계정 정보를 찾아 정리하고 연락 대상을 고르는 영업 업무는 신호 수집, 데이터 보강, 점수화, 행동 배정, 결과 측정으로 이어지는 흐름이 될 수 있다. 분석 업무도 쿼리와 대시보드에서 끝나지 않고, 버전 관리되는 변환 파이프라인·문서·테스트를 유지하는 일이 된다.
이때 전문지식은 사라지지 않는다. 오히려 어디에 입력을 연결할지, 어떤 규칙을 적용할지, 무엇을 성공으로 볼지 정하는 지점에 더 집중된다. 원문이 강조하듯 중요한 이동은 자연어에서 프로그래밍 언어로의 이동이 아니라, 한 번의 작업을 수행하는 데서 반복 수행할 과정을 만드는 데로의 이동이다.
AI에게 일을 맡길수록 사람이 정해야 하는 것은 무엇인가
에이전트에게 “이 일을 해 달라”고 말하는 것만으로는 업무 시스템이 되지 않는다. 시스템에는 입력의 범위, 쓸 수 있는 자료와 도구, 수정 가능한 권한, 완료 조건, 실패했을 때 멈출 지점이 필요하다. 코드 생성 에이전트가 이슈를 읽고 저장소를 탐색한 뒤 변경을 제안할 때도, 사람은 요구사항을 고치고 계획을 검토하며 테스트로 결과를 판단한다.
이 구조는 수학, 디자인, 영업, 법률처럼 코드가 중심이 아니었던 일에도 그대로 적용된다. 수학자는 수치 실험의 가정과 검증 방법을 정하고, 디자이너는 실제 화면에서 상태 변화와 접근성을 확인하며, 법률가는 분류 규칙 밖의 사건을 다시 살핀다. 구현은 AI가 상당 부분 처리할 수 있어도 입력·제약·검사·기록·예외 처리는 누군가가 명시해야 한다.
시스템이 좋아질수록 놓치기 쉬운 것은 무엇인가
시스템은 표현할 수 있는 것을 빠르고 일관되게 처리한다. 입력에는 형식이 필요하고, 성공에는 신호가 필요하며, 규칙은 실행 가능한 문장으로 바뀐다. 이 성질은 누락과 지연을 줄이는 데 유용하다. 동시에 시스템이 보지 못하는 것을 업무 밖으로 밀어낼 위험도 만든다.
원문은 형식적으로 맞는 수학 증명이 독자에게 왜 중요한지를 설명하지 못할 수 있고, 답장을 최적화한 영업 시스템이 측정하지 못하는 관계를 해칠 수 있다고 짚는다. 법률 분류기가 익숙한 사건을 빠르게 보내더라도 낯선 사안의 맥락을 알아채는 일은 별도다. 검증은 규칙을 통과했는지 알려 주지만, 그 규칙이 맞는 질문을 겨냥했는지는 판단하지 못한다.
전문직은 어디서부터 시스템으로 바꾸면 좋은가
처음부터 직무 전체를 파이프라인으로 만들 필요는 없다. 반복 빈도가 높고 결과를 비교하기 쉬운 한 흐름을 고르는 편이 낫다. 예를 들어 매주 같은 형식으로 들어오는 문의를 분류한다면, 먼저 입력 항목과 분류 기준을 적는다. 다음으로 자동 처리 결과를 사람이 다시 볼 표본과 반려 조건을 정한다. 마지막으로 잘못 분류된 사례를 기록해 규칙을 고친다. 이 순서라면 자동화의 속도와 책임 소재가 함께 남는다.
원문은 엔지니어화를 이처럼 반복 업무의 시스템을 설계하고 감독하는 일로 본다. AI 시대의 전문성은 산출물을 더 빨리 만드는 기술만으로 설명되지 않는다. 자기 분야의 의미를 잃지 않으면서, 그 일을 대신 수행하는 시스템의 입력과 경계, 검증 방법, 실패 이후의 조치를 결정하는 능력이 업무의 일부가 된다.
출처: Euge’s blog, “Engineerification” (2026-08-23)