AI 시대, 모든 전문직은 어떻게 엔지니어처럼 일하게 되는가

AI가 코드를 대신 쓰는 시대에 가장 중요한 변화는 모든 사람이 개발자가 되는 일이 아니다. 자신의 일을 저장하고, 명세하고, 테스트하고, 다시 개선할 수 있는 작업 시스템으로 바꾸는 일이다.

TL;DR

Engineerification은 코딩 직군의 확장이 아니라 업무 방식의 구조화다.
저장소, 에이전트, 테스트, 형식 명세, 피드백 루프가 전문직의 공통 도구가 된다.
AI 유틸은 답변보다 재현 가능한 결과물과 수정 가능한 export를 제공해야 한다.

왜 지금 중요한가

생성형 AI는 초안을 만드는 비용을 빠르게 낮췄다. 이제 병목은 “만들 수 있는가”보다 “무엇이 좋은 결과인지 정의하고, 같은 품질을 반복할 수 있는가”로 이동한다.

GeekNews에 소개된 Engineerification은 이 변화를 전문직 전체의 업무 구조 변화로 묶어 설명한다. 수학자, 디자이너, 분석가, 법률가가 저장소와 테스트, 자동화와 명세를 활용한다는 관찰이다. 이는 모든 직업이 프로그래밍 직업이 된다는 뜻이 아니다. 업무가 작업 단위와 검증 단위를 갖게 된다는 뜻에 가깝다.

핵심 흐름

1. 전문성은 머릿속 지식에서 작업 표면으로 나온다

전문가는 오랫동안 경험과 판단을 머릿속에 축적해 왔다. 하지만 팀으로 반복하려면 그 판단이 입력, 기준, 예외, 결과물의 형태로 드러나야 한다.

저장소는 단순한 파일 보관함이 아니다. 현재 버전과 변경 이력을 알려주는 공용 기억이다. 명세는 “대충 좋은 결과”를 검사 가능한 조건으로 바꾼다.

2. 에이전트는 전문가를 대체하기보다 루프를 짧게 만든다

에이전트에게 업무 전체를 던지는 대신 작은 루프를 맡길 수 있다.

자료를 읽고 구조화한다.
정해진 기준으로 초안을 만든다.
테스트나 비교표로 실패를 드러낸다.
사람이 예외를 판단한다.
통과한 교정을 다음 작업의 규칙 후보로 남긴다.

이 구조에서 사람의 역할은 사라지지 않는다. 오히려 어떤 예외를 허용하고 어떤 기준을 승격할지 결정하는 일이 더 중요해진다.

3. 테스트는 개발자의 전유물이 아니다

디자이너라면 화면이 특정 폭에서 읽히는지, 분석가라면 숫자의 출처와 계산식이 맞는지, 법률가라면 조항과 적용 범위가 보존되는지 검사할 수 있다.

테스트는 반드시 코드일 필요가 없다. 체크리스트, 샘플 비교, 스키마 검증, 링크 검사, 사람의 승인 기록도 업무에 맞는 테스트가 될 수 있다.

실제 사례 / 신호

원문은 전문직 전반에서 저장소, 에이전트, 테스트, 자동화, 형식 명세, 피드백 루프가 결합되는 흐름을 Engineerification이라는 이름으로 제안한다. 여기서 중요한 것은 용어의 유행 여부가 아니라, 서로 다른 직군에서 비슷한 작업 도구가 반복된다는 점이다.

동시에 다른 도구 사례도 같은 방향을 보여준다. AI 자막 도구는 음성 인식만 제공하지 않고 정렬·편집·번역을 한 작업 표면에 묶는다. 로컬 LLM 개발자는 모델 이름보다 라우팅·튜닝·서빙 환경을 조합한다. 결과적으로 사용자는 AI의 “생성 능력”보다 자신의 작업이 어디까지 진행됐고 어떻게 수정되는지를 보게 된다.

실전 활용 팁: 반복 업무를 작업 표면으로 바꾸는 법

처음부터 거대한 지식 시스템을 만들 필요는 없다. 한 업무에 다음 다섯 필드만 먼저 붙인다.

input: 무엇을 받는가
contract: 통과한 결과는 무엇인가
steps: 어떤 순서로 처리하는가
test: 무엇을 확인하면 실패인가
export: 어디에 재사용할 수 있는가

예를 들어 블로그 초안이라면 원문 링크, 공개 구조, 출처 확인, 링크 검사, Markdown export가 계약이 된다. ERD 생성기라면 SQL 입력, 테이블·관계 규칙, 파싱 오류, 다이어그램과 SQL export가 계약이 된다.

핵심은 AI에게 결과를 한 번에 요구하지 않는 것이다. 중간 표현을 남기면 어디에서 판단이 틀렸는지 보이고, 다음 작업에서 그 기준을 재사용할 수 있다. 작은 업무 하나부터 시작한다.

바로 해볼 실험

이번 주에 반복 업무 하나를 골라 60분짜리 작업 표면으로 바꿔보자.

최근 결과물 3개를 모은다.
매번 사람이 확인한 기준을 5개 이하로 적는다.
에이전트에게 초안이 아니라 구조화된 중간 결과를 만들게 한다.
실패 사례를 테스트 fixture로 저장한다.
사람이 수정한 내용 중 반복되는 것만 규칙 후보로 올린다.
최종 결과를 다른 도구에서 열 수 있는 형식으로 export한다.

성공 기준은 자동화율이 아니다. 다음 사람이 같은 작업을 더 빨리 이해하고, 실패를 재현하며, 결과를 고칠 수 있는가다.

리스크 / 반론

모든 일을 형식화하면 창의성과 탐색이 줄어들 수 있다. 초기 아이디어나 연구처럼 정답이 없는 작업에는 테스트보다 관찰 기록이 적합할 수도 있다.

또한 원문이 말하는 Engineerification은 개념적 관찰이지 모든 전문직에 대한 성과 통계가 아니다. 저장소와 에이전트를 도입했다고 곧바로 생산성이 올라간다고 가정해서도 안 된다. 업무의 실제 실패 비용과 팀의 학습 속도로 검증해야 한다.

결론

AI 시대의 전문성은 AI에게 일을 시키는 능력만으로 결정되지 않는다. 일을 저장하고, 정의하고, 시험하고, 다시 쓸 수 있게 만드는 능력이 새로운 기본기가 된다.

가장 작은 다음 행동은 간단하다. 반복 업무 하나를 골라 input → contract → test → export 네 칸으로 적어보자. 그 순간부터 그 업무는 머릿속 노하우가 아니라 개선 가능한 시스템이 된다.

다음 업무를 시작하기 전에 세 가지만 물어보면 된다. 이 결과는 어떤 입력과 조건에서 나왔는가? 실패를 다시 재현할 수 있는가? 다른 사람이 수정하고 export할 수 있는가?