수학자도, 변호사도 엔지니어처럼 일하기 시작했다

출처: Euge's blog (Eugenio)
원문: https://eug.github.io/posts/engineerification.html
작성자: 팔복소프트-김팔복

한눈에 보기

• 블로거 Euge가 여러 직군의 업무 방식이 엔지니어링을 닮아가는 현상을 engineerification(엔지니어화) 이라고 이름 붙였다.
• 브라질 수학연구소 IMPA의 수학자 대상 강연에서 Git 저장소, 코딩 에이전트 권한 관리, 테스트, Lean 증명 검증 같은 개발자 워크플로가 그대로 등장한 것이 출발점이다.
• 핵심은 모두가 코딩을 배운다는 게 아니라, 도메인 전문가가 "자기 일을 대신 수행하는 시스템"을 만들고 감독하는 책임을 지게 됐다는 것이다.
• 소프트웨어 개발 분야가 2024년에 자동완성에서 에이전트 위임으로 먼저 이 전환을 겪었고, 지금 GTM·데이터 분석·디자인·법무·기술문서 영역으로 같은 패턴이 번지고 있다.
• 저자는 역설도 짚는다. 에이전트가 엔지니어링 자체를 점점 잘하게 되는 바로 그 시점에, 모든 직군이 엔지니어처럼 되고 있다는 것이다.
• 시스템화에는 함정이 있다. 형식화되지 않는 것(맥락, 관계, 판단)을 시스템 바깥으로 밀어내고, 시스템이 세상보다 작다는 사실을 잊게 만든다.

배경

Claude Code, Codex 같은 코딩 에이전트는 이제 코드 자동완성 도구가 아니라 "작업을 통째로 맡기는" 도구로 쓰인다. 저장소를 탐색하고, 계획을 세우고, 코드를 고치고, 테스트로 검증받는 방식이다. 이 글은 그 워크플로가 개발자 바깥으로 퍼져나가는 현상을 다룬 에세이다. 제품 발표가 아니라 관찰과 질문이 중심이므로, 도입 가이드가 아니라 "우리 팀에 무슨 일이 벌어질지"를 미리 생각해보는 글로 읽으면 좋다.

주요 내용

수학 강연에서 나온 개발자 워크플로

저자가 본 IMPA의 LLM·수학 강연에서 연사들은 수학자들에게 이렇게 권했다. 프로젝트를 로컬 디렉터리와 저장소로 관리하고, 에이전트에 제한된 권한만 주고, 변경을 커밋하고, 지침 파일을 쓰고, 테스트를 돌리고, 형식 증명은 Lean으로 검증하라. 어떤 모델이 긴 세션에 유리한지, 왜 Overleaf 대신 로컬 환경으로 옮겨야 하는지까지 다뤘다. 소프트웨어 콘퍼런스가 아니라 수학 강연에서다.

저자가 주목한 건 "수학자도 컴퓨터를 쓴다"가 아니다. 수학 프로젝트 자체가 의존성, 권한, 실행 가능한 검증, 버전 이력, 그 안에서 움직이는 에이전트를 가진 소프트웨어 프로젝트의 형태로 바뀌고 있다는 점이다.

'엔지니어화'가 실제로 가리키는 것

저자가 말하는 엔지니어화는 "모두가 개발자가 된다"가 아니다. 코드는 에이전트가 숨겨줄 수 있다. 진짜 변화는 작업을 직접 하는 사람에서, 그 작업을 반복 수행하는 프로세스를 설계하고 감독하는 사람으로 옮겨가는 것이다.

그러면 질문의 종류가 바뀐다. 시스템에 어떤 정보가 들어가는가, 이상한 입력에는 어떻게 반응하는가, 결과가 맞는지 어떻게 아는가, 변경을 어떻게 리뷰하고 되돌리는가, 문제가 생기면 누가 책임지는가. 주제가 수학이든 영업이든 법무든, 이건 엔지니어링의 질문이다.

개발자가 먼저 겪은 전환

저자는 2024년을 눈에 보이는 변곡점으로 본다. 2024년 4월 발표된 GitHub Copilot Workspace는 이슈를 명세→계획→구현→테스트 사이클로 바꿨고, GitHub은 개발자를 "시스템 사고를 하는 사람"으로 묘사했다. SWE-agent, SWT-Bench 같은 연구, Aider의 Architect/Editor 워크플로도 같은 방향이었다. GitHub이 기업 개발조직 종사자 2,000명을 조사한 2024년 설문에서는 다수가 AI 생성 테스트를 적어도 가끔 쓴다고 답했다. 자동완성이 위임으로 바뀌면서, 테스트·명세·아키텍처가 개발자와 구현 사이의 인터페이스가 된 것이다.

다른 직군에서 반복되는 패턴

저자도 이 사례들의 성숙도가 제각각이고, 일부는 자사 도구를 홍보하려는 벤더의 서사임을 인정한다. 그래도 반복되는 구조는 같다. 산출물이 저장소가 되고, 절차가 워크플로가 되고, 규칙이 테스트가 된다.

시스템이 되는 순간의 함정

낙관적으로 보면, 문제에 가장 가까운 사람이 번역 계층 없이 직접 시스템을 고칠 수 있게 된다. 하지만 저자는 어두운 면도 짚는다. 시스템은 자신이 표현할 수 있는 것만 우대한다. 형식적으로 올바르지만 왜 중요한지 전달하지 못하는 증명, 답장률은 최적화하면서 측정 못 하는 관계를 망가뜨리는 영업 시스템, 알려진 유형은 잘 처리하지만 판단이 필요한 예외를 놓치는 법무 워크플로. 형식화에서 빠진 게 소음이면 괜찮지만, 그게 핵심이면 위험하다.

일시적 엔지니어라는 역설

AI가 구현 능력의 진입장벽을 낮추면 엔지니어링은 덜 중요해져야 할 텐데, 실제로는 엔지니어링 책임이 더 많은 직군으로 퍼지고 있다. 만들기가 싸지면 만들 것이 많아지고, 시스템이 많아지면 그 시스템의 동작을 결정할 사람도 많아지기 때문이다. 그런데 에이전트는 저장소 탐색, 테스트, 실패 대응, 자기 지침 개선까지 점점 잘하고 있다. 저자는 결론을 내리지 않고 묻는다. 우리는 엔지니어링이 지식노동의 미래라서 엔지니어가 되는 걸까, 아니면 언젠가 우리 일을 대신할 시스템과 우리 직업 사이의 임시 인터페이스라서일까.

팔복소프트 관점

• 국내 조직에 이 글이 특히 아픈 이유는 분업 구조 때문이다. 기획·디자인·개발이 명확히 나뉘고 요구사항이 문서로 "전달"되는 조직, 특히 SI 구조에서는 엔지니어화가 도구 문제가 아니라 권한과 책임의 재배치 문제가 된다. 현업이 에이전트로 직접 시스템을 만들기 시작하면, 그 시스템이 장애를 냈을 때 누가 운영 책임을 지는지부터 정리돼야 한다.
• 몇 년 전 노코드 열풍과 비교해볼 만하다. 노코드는 도구를 줬지만 책임 구조는 건드리지 않아 대부분 사이드 프로젝트에 머물렀다. 엔지니어화는 반대로 Git, 테스트, 리뷰라는 책임 장치를 함께 가져온다. 이게 이 흐름이 더 오래갈 것 같다고 보는 이유다.
• 개발팀 입장에서 현실적인 준비는 "비개발 직군 코딩 교육"이 아니라 플랫폼 제공이다. 권한이 제한된 에이전트 환경, 안전한 저장소 템플릿, 자동 검증 파이프라인을 개발팀이 깔아주고, 도메인 전문가가 그 위에서 움직이게 하는 쪽이 사고를 줄인다. 원문이 인용한 "게이트키퍼에서 배관공으로"의 방향과 같다.
• 아쉬운 점도 있다. 이 글은 관찰과 질문이 풍부한 대신 데이터가 얇다. 근거로 든 설문은 자기보고식 하나뿐이고, 사례 상당수가 벤더 자료다. 국내 팀이 이 글을 근거로 조직 개편을 정당화하는 건 성급하다. 방향을 읽는 글이지, 의사결정 근거 자료는 아니다.

정리

기억할 것은 하나다. 에이전트 시대의 경쟁력은 코딩 능력이 아니라, 자기 도메인의 일을 시스템으로 정의하고 그 시스템의 경계와 실패를 감독하는 능력으로 이동하고 있다. 다만 시스템이 표현하지 못하는 것, 즉 맥락과 판단이야말로 전문가가 마지막까지 붙들어야 할 부분이다. 그리고 이 역할조차 에이전트가 흡수할 수 있다는 저자의 물음은, 지금 워크플로를 재설계하는 모든 팀이 한 번쯤 스스로에게 던져볼 만하다.

• AI에이전트
• 엔지니어화
• 시스템사고
• ClaudeCode
• 일의미래