저장소를 만들고, 에이전트에 권한을 정해 붙이고, 테스트를 돌려 결과를 확인한다. 지금까지 이건 개발자의 일이었습니다. 그런데 요즘은 수학자가 아침에 터미널을 열고 같은 일을 시작합니다.

블로거 Euge가 여러 분야의 전문가들이 점점 엔지니어처럼 일하는 모습을 관찰하고 남긴 글입니다. 저장소, 에이전트, 테스트, 자동화, 형식 명세, 피드백 루프. 서로 다른 직업들이 이런 워크플로를 닮아가고 있다는 것. 그는 이 변화를 engineerification, 우리말로 옮기면 ‘엔지니어화’라 부릅니다.

출처

• Engineerification – Euge’s blog

수학 프로젝트가 소프트웨어 프로젝트를 닮아간다

계기는 수학자를 위한 한 강연이었습니다. 브라질의 순수응용수학연구소에서 열린 LLM과 수학 특강인데, 강연이 놀랄 만큼 오래 터미널 이야기에 머물렀다고 하죠.

내용은 이렇습니다. 로컬 디렉토리에서 작업하고, 코딩 에이전트에 제한된 권한만 주고, 프로젝트를 저장소에 두고, 변경을 커밋하고, 지시 파일을 쓰고, 테스트를 돌리라는 것. 형식 증명을 검증하는 Lean 같은 도구도 등장했습니다. 발표자들은 Claude Code와 Codex를 직접 시연하고, 긴 작업에는 어떤 모델이 나은지까지 이야기했죠.

Euge가 주목한 건 도구를 하나 더 쓰게 됐다는 사실이 아닙니다. 일의 모양 자체가 바뀌었다는 점입니다. 수학 프로젝트가 의존성과 권한, 실행 가능한 검증, 버전 기록, 그리고 그 안에서 움직이는 에이전트를 갖춘 소프트웨어 프로젝트로 변하고 있었으니까요.

코딩을 배우는 게 아니라, 시스템에 책임지는 것

여기서 오해하기 쉽습니다. “결국 모두가 코딩을 배워야 한다는 얘기 아닌가.” Euge의 관찰은 그 반대에 가깝습니다.

핵심은 코딩 학습이 아니라, 도메인 전문가가 자기 일의 일부를 대신 수행하는 시스템에 책임을 지게 된다는 데 있습니다. 수학자가 파이썬 문법을 외우는 게 아니라, 에이전트가 짠 코드를 검토하고 그 결과를 신뢰할지 판단하는 사람이 되는 것입니다.

월요일 아침 풍경으로 옮기면 이렇습니다. 터미널을 열고, 저장소로 들어가고, 에이전트를 띄우고, 그것이 만든 변경을 살펴보고, 이 결과를 믿어도 되는지 결정한다. 큰 변화는 대개 이렇게 작은 일상의 습관으로 먼저 도착합니다.

개발자에게는 이미 도착한 풍경

개발자들은 이 변화의 앞 구간을 먼저 지나고 있습니다. 스콧 프릭셀은 지난 18개월을 이렇게 정리하죠. 탭 자동완성에서 에이전틱 코딩으로, 다시 에이전트를 관리하는 ‘하니스’로.

그가 도달한 결론은 “하니스가 핵심”이라는 것입니다. 어떤 모델을 쓰느냐는 점점 덜 중요해지고, 여러 모델을 어떤 구조로 엮어 부리느냐가 실력을 가른다는 뜻이죠. 그는 탐색, 계획, 실행, 비평, 공유라는 역할을 나눠 에이전트에 맡깁니다. 하나의 프롬프트에 모든 역할을 몰아넣으면 스스로 목표가 뒤엉키기 때문에, 역할마다 분리해 놓는 방식입니다.

개발자가 코드를 한 줄씩 쓰는 사람에서, 여러 에이전트가 도는 시스템을 설계하고 조율하는 사람으로 옮겨간 셈이죠. 위의 수학자가 향하는 곳과 같은 방향입니다.

엔지니어를 닮아가는 순간, 엔지니어링은 자동화된다

Euge가 붙인 마지막 한 겹이 묘합니다. 여러 직업이 엔지니어를 닮아가는 바로 그 시점에, 정작 엔지니어링 자체는 자동화되는 중이라는 것.

많은 사람이 시스템을 책임지는 관리자가 되어가는데, 그 관리 대상인 엔지니어링마저 에이전트가 상당 부분 해내게 될지 모릅니다. 엔지니어처럼 되어가는 흐름과 엔지니어링이 사라지는 흐름이 겹치는, 조금 이상한 국면인 겁니다.

이걸 내 자리에 대입해보면 질문은 하나로 모입니다. 내 분야의 일도 저장소와 에이전트와 검증 루프를 갖춘 ‘프로젝트’의 모양으로 바뀌고 있는가. 그렇다면 내가 새로 익힐 것은 그 분야의 코딩이 아니라, 나를 대신해 일하는 시스템을 점검하고 신뢰 여부를 판단하는 감각일지도 모릅니다.

참고자료

• The Harness Is the Thing – Scott Fryxell