소프트웨어 엔지니어는 이제 코드를 만드는 기계공이다

기계공이 재단사보다 가까워졌다

소프트웨어 엔지니어는 AI 엔지니어가 되는 게 아니다. 점점 더 싸고 풍부하게 만들어지는 기계 제작 소프트웨어를 다루는 소프트웨어 기계공이 되고 있다. 옷을 하나씩 손으로 만드는 재단사와 달리 기계공은 도구를 만들고 시제품을 검사한 뒤 대량 생산한다.

2025년 중반의 탭 자동완성은 장난감 같았다. 나는 거의 쓰지 않았고, 쓰는 동료보다 느리지도 않았다. 2025년에 한 달에 PR 약 60개를 병합했지만 AI는 거의 쓰지 않았다. 2025년 9월쯤 다른 엔지니어들과 함께 있을 때도 코드를 직접 쓰는 일을 그만둘 리 없다고 자신 있게 말했다. 코딩을 너무 좋아했기 때문이다.

그러다 Opus 4.5가 나왔고, 우연히 노트북도 바꾸게 됐다. 2026년 1월 말에야 손으로 코드 한 줄도 쓰지 않았다는 사실을 깨달았다. 사용하던 컴퓨터에는 IDE조차 설치하지 않았다. 2026년 1월 PostHog 모노레포에서 PR 62개를 병합했는데, 2025년의 어느 달과 대략 비슷한 수였다. 하지만 코드 한 줄도 직접 입력하지 않았다. 그러면서도 즐거웠다. 2025년 9월에 내가 그토록 틀렸다면, 지금은 얼마나 더 틀렸을지 생각하게 됐다.

내 업무 방식과 동료들의 업무 방식이 바뀌는 모습을 보며 공통점을 발견했다. 이제 우리는 주니어 엔지니어 팀을 이끄는 테크 리드가 됐고, 코드는 더 이상 우리만을 위한 것이 아니다. 문맥에 주의를 기울이는 일은 전보다 더 중요해졌다. 앞으로는 지속적 통합과 코드 리뷰도 달라질 것이며, 작업장을 위한 도구를 직접 만들게 될 것이다.

안전 요구사항이 엄격하거나 성능이 중요한 시스템을 다루는 사람들은 여전히 있다. 그런 시스템에서는 사고를 일으키기가 더 쉽고, 업무 방식도 상대적으로 덜 바뀌었다. 하지만 대다수 엔지니어의 일은 달라졌다. 맞춤형 소프트웨어를 만드는 재단사처럼 모든 코드 줄을 들여다보는 것만으로는 충분하지 않다. 이제 우리는 소프트웨어 기계공이다.

테크 리드의 일이 달라졌다

우리는 모두 로봇 주니어 엔지니어 팀을 이끄는 테크 리드가 됐다. 테크 리드는 팀의 방향을 정하고 팀의 습관을 다듬어 시간이 흐를수록 더 효율적으로 일하게 한다. 로봇 엔지니어에게는 호기심이 없으므로, 로봇 팀의 방향을 정하는 일은 우리 몫이다. 예전에는 더 나은 결과를 내기 위해 필요했다면, 이제는 로봇이 그 일을 하지 않기 때문에 필요하다. 인간이 가치를 더하는 역할 중 하나다.

켄트 벡(Kent Beck)은 ChatGPT를 처음 사용한 뒤 이렇게 말했다.

“내 기술의 90%가 지닌 가치가 0달러로 떨어졌다. 나머지 10%의 영향력은 1000배 커졌다. 다시 조정해야 한다.”

테크 리드는 원래 모든 코드를 읽고 검토하는 사람이 아니라 방향을 정하는 사람이었다. 의견이 갈릴 때 최종 판단을 내리고, 각 팀원의 일을 세부 사항에 빠져들지 않을 정도로 파악해 필요한 문맥을 공유한다.

이제 로봇을 상대로도 그렇게 한다. 처음에는 탭을 누를지 결정하고, 프롬프트와 문맥, 작업 환경을 정했다. PostHog에서는 그 일조차 점점 위임되고 있다. 예를 들어 몇몇 직원은 행동으로 옮기고 싶은 논의가 슬랙에 올라오면 Slack 에이전트에게 GitHub 이슈를 만들어 달라고 한다. 이슈는 자율 작업 도구가 처리하고, 결과로 만들어진 풀 리퀘스트에 요청자가 태그된다.

리드는 자신이 맡은 시스템의 전반적인 품질을 살펴야 한다. 중요한 것은 PR 하나하나의 품질이 아니다. 팀원들이 서로의 PR을 검토할 수 있어야 한다. 리드의 책임은 시간이 흐르면서 유지되는 품질이다. 각 변경에서 선의로 내린 결정이 쌓이면 의도하지 않은 결과가 생길 수 있다. 그런 결과는 기대하지도 않았고 원하지도 않았던 방식으로 나타날 수 있다.

이를 위해 나는 정해진 시간마다 실행되는 에이전트인 Scouts를 사용해 왔다. 그중에는 복잡도 사냥꾼이 있다. 순환 복잡도를 확인하는데, 에이전트가 작성한 코드에서도 예외 처리가 복잡한 코드에 몰리는 현상을 봤기 때문이다. 이들은 코드를 분리하는 PR을 열며, 복잡도 점수만 낮추는 대신 우리가 코드를 나누는 방식을 기술한 스킬을 활용한다.

복잡도 사냥꾼은 변경분에서 주석이 차지하는 비율도 살핀다. 이 비율은 통제하기 전 2%에서 9% 이상으로 늘어난 적이 있다. 또 목록을 반환하는 API에서 다른 직렬 변환기를 써야 하는데 잊는 경우나, 데이터베이스를 설정하는 Django TestCase를 사용하면서 데이터베이스 조회는 하지 않는 테스트처럼 반복해서 발생한 버그 형태도 확인한다.

복잡도 사냥꾼은 최근 30일 동안 PR 47개를 병합했다. 대부분은 다른 에이전트가 검토했다. 소프트웨어 기계공의 역할은 PR을 직접 검토하지 않아도 안전한 환경을 만드는 것이다. 이 스카우트 하나가 한 달에 배포하는 PR 수는 2025년 내가 매달 처리하던 수와 거의 맞먹는다.

신뢰를 바탕으로 이끄는 일은 모델마다 무엇을 할 수 있는지 이해하고, 로봇 팀원에게 적절한 일을 맡기는 것을 뜻한다. 좋은 결과를 내도록 올바른 지침과 안전장치를 제공해야 한다. 로봇의 모든 코드 줄을 늘 확인하는 대신, 그 작업을 둘러싼 시스템을 신뢰해야 할 때도 있다. 어떤 일은 더 면밀히 살펴야 하고 어떤 일은 그럴 필요가 없는지 판단해야 한다. 배운 교훈이 팀의 습관에 반영되도록 절차를 마련하는 것도 중요하다.

나는 PostHog에서 AI가 본격적으로 확산되기 전 3년 동안의 PR 리뷰 기록으로 훈련한 리뷰 스킬을 사용한다. c2wiki.com에서 애자일 선언문을 쓰고 현대 소프트웨어 공학의 여러 방식에 영향을 준 사람들이 나눈 대화의 지혜를 반영한 스킬도 있다. 이런 스킬은 여러 모델에서 실행되며, 리뷰 결과는 자동으로 수정안을 보내는 프롬프트가 된다. 모든 과정이 끝난 뒤에야 내가 개입한다.

Prettier가 파일을 정리할 때 그 작업을 일일이 확인하지 않는 것처럼, 리뷰어 에이전트가 수행하는 개별 단계도 확인하지 않는다. 최종 결과만 본다. 일은 언제나 가장 적은 노력으로 가장 큰 가치를 내는 것이었다. 지금은 그 방식을 표현하는 방법이 달라졌다. 변화를 거부할 수도 있고, 불평을 멈추고 가치를 내보낼 수도 있다. 2025년의 나는 리뷰를 자동화에 맡기지 않았을 것이다. 2026년의 나는 그러지 않을 여유가 없다.

코드는 더 이상 우리를 위한 것이 아니다

로봇이 발전할수록 코드는 사람이 읽기 위한 것이 아니게 된다. 동료 투 하울룬드(Tue Haulund)는 이렇게 말했다.

“최초의 FORTRAN 컴파일러가 나왔을 때 한동안 엔지니어들은 결과로 나온 기계어를 읽으며 제대로 만들어졌는지 확인했을 것이다. 지금도 그렇게 하는 사람은 누구인가? 컴파일러 개발자뿐이다. 생성형 LLM이 코드를 만드는 경우도 그렇게 될 것이다. GCC가 출력한 어셈블리를 모두 읽고 이해하고 검증하지 않으면 진짜 엔지니어가 아니거나 일을 제대로 하지 않는다고 주장한다고 생각해 보라.”

컴파일러는 결정론적으로 작동하므로 이 사례가 에이전트 기반 작업과 완전히 같지는 않다. 그래도 기술이 변하면 기술을 대하는 우리의 행동도 바뀌어야 한다는 점을 보여준다.

이는 기술 수준에만 해당하지 않는다. 회사가 어느 정도 규모를 넘으면 모든 코드를 읽지 않는다. 다른 팀이 API를 만들면 통합 테스트를 일부 작성할 수는 있어도 API 코드를 읽지는 않는다. 의존성을 설치한 뒤 제대로 작동하는지 테스트하고 넘어간다.

코드를 만드는 비용이 낮아진 만큼 에이전트의 작업도 같은 방식으로 다뤄야 한다. 코드를 읽는 대신 제대로 작동하는지 확인한다. 우리를 보호하는 검증 관행을 강화해야 한다. 검증을 뒷받침하는 좋은 습관과 자동화는 시스템을 안전하게 바꾸는 속도를 높여 왔다. 소프트웨어를 만들고 바꾸는 속도가 빨라질수록 이런 기반은 더 중요해진다. 코드를 읽는 일은 검증의 일부였을 뿐이다. 사람이 원하는 영향과 필요한 검증 사이의 관계를 이해하도록 돕는 수단이었다.

문맥은 한 조직 안에서도 하나가 아니다. 전 동료 앤디 롱쇼(Andy Longshaw)는 “문제에는 문맥 안에서의 해결책이 있다”고 말하곤 했다. 테스트 주도 개발에서는 ‘기어를 바꿔 운전한다’는 표현을 쓰기도 한다. 지형과 조건에 맞는 기어를 고르듯 코드와 테스트를 작성하는 방법도 코드의 문맥에 따라 달라진다는 뜻이다.

고성능 시스템이나 안전이 중요한 시스템을 다루는 사람들은 로봇이 사람의 개입을 거의 받지 않고 시스템을 운영하도록 맡기기 어렵다. 나도 한 번은 PostHog의 데이터 수집 파이프라인을 바꾸다가 CPU 사용량을 늘린 적이 있다. 그 영향이 커지면서 몇 시간 동안 장애 대응 회의를 열고, 밀린 작업을 처리할 수 있도록 파이프라인을 안정화해야 했다.

이런 시스템에서는 변경을 적용하는 과정이 더 복잡하다. 배포를 여러 단계로 나누고, 새 코드가 적용되는 시점을 코드 배포와 분리해 안전하게 전개한다. 로봇 주니어 엔지니어가 이런 일을 하려면 아직 훨씬 더 세심한 지도가 필요하다.

그래도 이때 로봇은 도움을 줄 수 있다. 예를 들어 JS SDK 저장소에는 심각한 버그가 발생했던 코드 영역 목록이 있다. 변경이 그중 한 영역에 닿으면 자동으로 표시하고, 검증에서 문제가 발견될 경우 에이전트가 후속 작업을 더 깊이 수행하도록 가르치는 스킬을 적용한다. 조직이 가진 지식을 적극적으로 반영해 안전성을 높이는 방식이다.

CI의 검사 결과를 에이전트에게 다시 전달할 수도 있다. PR이 API와 데스크톱 앱을 동시에 바꿀 수 있다면 API 변경을 먼저 배포하거나 하위 호환성을 유지해야 한다고 알린다. 해결책이 명확하지 않은 경우가 아니라면 이 문제를 사람에게 넘길 필요는 없다.

다음 병목은 통합과 리뷰다

제약 이론에 따르면 시스템에는 다른 단계보다 느린 단계가 하나씩 있고, 그 단계가 전체 속도를 결정한다. 이를 제약 또는 병목이라고 한다. 엘리야후 골드랫 박사(Dr. Eliyahu Goldratt)의 책 『The Goal』에서 더 자세히 다룬다. 나는 게을러서 이 책의 그래픽 노블판을 추천한다.

로봇이 PR 작성을 빠르게 하면서 PostHog의 PR 수는 약 5배 늘었고 직원 수는 1.5배 늘었다. PR 작성이 더 이상 시스템에서 가장 느린 단계가 아닐 가능성이 높다. 다음 단계인 리뷰, 빌드, 테스트, 배포 중 하나가 새로운 병목이 된다.

이제 ‘하지 않는 일’에 더 집중해야 한다. 예를 들어 불필요한 CI 단계를 줄이는 것이다. PostHog는 2026년 8월에 CI 실행 시간으로 46년을 썼다. 증가분을 감당해 준 depot.dev에 감사한다. 이 수치를 제한 없이 늘리는 것은 비용 측면에서도 지속 가능하지 않다. 9월에는 CI 실행 시간을 36년으로 줄였다. PR을 26% 더 병합하면서 CI 시간은 22% 감소했다. 하지 않은 일의 가치가 드러난 사례다.

이 분야에서는 소프트웨어 서비스와 도구가 성장할 것으로 예상한다. 코드 생성이 늘어나면서 생기는 병목을 해결할 새로운 방법이 필요하다. 각 에이전트 기반 PR을, 예전에는 PR 안의 각 커밋을 다루던 정도로 살펴볼 수 있도록 변경 사항을 보여주는 방법을 고민하고 있다.

다음으로 찾아야 할 것은 이 속도를 안전하게 유지하는 데 필요한 도구와 행동 방식이다. 물론 안전하게 만들 수 없을 가능성도 있다. 그런 경우에는 이미 진행 중인 작업이 너무 많을 때 새 PR이 시스템을 압도하지 않도록 유입을 제한해야 한다. 생산 라인에 관한 제약 이론은 가장 느린 지점의 처리량을 높이는 것뿐 아니라 시스템에 들어오는 작업도 통제해야 한다고 가르친다.

나는 모든 PR을 읽으라고 권한 적이 없다. 대신 팀원들이 판단할 수 있도록 안전장치를 마련하고 한발 물러나 그들이 일하게 했다. PostHog에는 추가 검토 없이 PR을 승인해도 안전한지 판단하는 규칙을 갖춘 StampHog라는 에이전트가 있다. 사람의 추가 개입 없이 PR을 승인할 수 있으며, PR의 약 30%가 StampHog의 승인을 받는다. 토큰 비용은 한 달에 약 910달러다. 다른 작업의 속도를 높이는 데 아주 좋은 비용이다.

StampHog는 오픈소스이므로 작동 방식을 볼 수 있다. 하지만 어떻게 부실한 코드를 마구 쏟아내지 않는다고 확신할 수 있을까? PostHog는 문제가 조금이라도 의심되면 PR을 빠르게 되돌린다. 2026년 1월에는 PR의 1.5%가 되돌려졌고, 2026년 8월에는 0.25%였다. 시스템 측정값과 사용자 피드백을 보면 속도를 내기 위해서만 서둘러 배포하는 것은 아니라고 확신한다.

간단히 승인하기 어려운 PR은 ReviewHog가 다룬다. ReviewHog는 심층 리뷰를 수행하며, 각자 만든 스킬을 리뷰에 추가할 수 있다. PostHog에서는 사람이 PR을 확인하기까지 보통 반나절이 걸린다. ReviewHog는 심층적이고 꼼꼼한 리뷰를 30분 만에 수행한다.

AGENTS.md가 에이전트를 실제로 이끄는지 확인하기 위해, 파일을 넣었을 때와 넣지 않았을 때 변경 결과를 평가한다. 여러 모델의 행동도 점수화해 추적한다. 사람이 작성한 과거 PR을 여러 모델이 다시 만들어 보게 한 뒤, 과거에 받아들여진 변경을 얼마나 잘 재현하는지도 평가한다.

작업장을 위한 도구를 만든다

기계공은 작업장에 필요한 도구를 한 번 쓰고 버릴 수 있게 싸게 만들기도 한다. 다시 만드는 비용도 낮기 때문이다. 따라서 어떤 시스템은 잠깐 쓰고 사라지고, 다른 시스템은 핵심 시스템이 될 수 있다. 코드를 만드는 비용이 낮아지면 사람들은 문제를 해결할 간단한 앱을 빠르게 만들 것이다. 어떤 것이 유용한지 조직이 알아내고, 임시 도구에서 핵심 도구로 발전시키는 능력이 중요해진다.

PostHog에서는 이미 사람들이 PR 리뷰 관리, 새로운 방식의 변경 사항 표시, 수십 개 PR에 걸친 CI와 리뷰 진행 관리, 심지어 제품 안에 Doom을 넣기 위한 브라우저용 wasm 배포에 쓸 앱을 만들고 있다. 이런 일은 본업을 대신하는 게 아니라 본업과 함께 이뤄진다.

동료 톰 오워스(Tom Owers)는 Talyn을 만들었다. 그는 이 도구로 문맥 웨어하우스가 처리할 수 있는 데이터 출처를 늘리면서 자신이 만든 수백 개 PR을 관리한다. Talyn은 한 사람이 바이브 코딩으로 만든 앱으로 시작했지만 이제는 여러 사람이 사용하고 기여한다. 톰은 요청된 데이터 출처를 추적하고, 지원이 추가되면 사람들에게 자동으로 답하는 맞춤형 소프트웨어도 만들었다. 다른 사람들도 여러 관점으로 변경을 시각화하고 검토하는 앱을 만들었다. 개발자 경험 팀은 다른 사람의 작업을 막힌 상태에서 풀어줄 때 주의를 집중할 수 있도록 GitHub 알림을 묶고 우선순위를 정하는 앱을 만들었다.

맞춤형 시스템 대신 기계가 만든 시스템으로 전환하면 제품을 빠르게 다시 만들고 제공할 수 있다. 이는 민첩성과 숙련을 새롭게 표현하는 방식이며, 이전에는 더 적은 조직만 누릴 수 있었다. 이런 앱은 계속 발전할 수도 있고, 대체품에 영감을 주고 버려질 수도 있다. 만드는 비용이 낮아지면 새로운 가능성을 탐색하는 비용도 낮아진다.

데이터를 바탕으로 SQL 질의와 UI를 만드는 일도 예전에는 불가능했던 시간 안에 더 많은 사람이 할 수 있게 됐다. 내가 Co-op Digital에서 일할 때는 디자인 시스템 위에 콘텐츠 중심 웹사이트를 반복해서 만들 플랫폼을 마련하는 데 큰 팀이 수개월을 썼다. 이제는 몇 주나 몇 달이 아니라 며칠이나 몇 주가 걸릴 것으로 예상한다.

다만 이때도 병목은 디자인 시스템일 수 있다. Co-op의 문제 중 하나는 팀과 부서가 많아 시스템마다 모양과 동작, 느낌이 달랐다는 점이다. 그래서 그들의 디자인 시스템이 중요했다. 이런 작업은 여전히 어렵고 여전히 필수다.

SQL 질의를 만들기 쉬워진 만큼 잘못된 질의나 분석을 만드는 장벽도 낮아졌다. PostHog는 로봇이 판단할 때 의미를 찾을 수 있도록 ‘시맨틱 계층’을 구축해야 했다. 그렇지 않으면 “제품 X의 매출은 얼마인가?” 같은 미묘한 질문에 서로 다른 답이 나올 수 있다. 누구에게 어떤 질문을 할 수 있는지 제한하려는 게 아니라, 올바른 답을 낼 수 있는 도구를 마련하려는 것이다.

현재 사용하는 시스템 중 일부는 필요할 때 만들어지고 동작으로 검증한 뒤 쉽게 버리는 임시 도구가 될 것이다. 다른 시스템은 더 중요해지고, 변화 속도가 빨라지는 가운데 더 신중하게 만들고 검증해야 한다. 만들기 비용이 낮아질수록 디자인 시스템이나 보안 통제 같은 공통 기반은 안전하게 빠르게 일하는 능력을 뒷받침하므로 더 중요해진다.

엔지니어링의 역할도 바뀐다

엔지니어링 업무는 한 종류가 아니다. PostHog에도 성장, 제품, 데이터 수집, ClickHouse, 결제 등 다양한 책임을 맡은 팀이 있다. 따라서 어떤 팀에는 맞는 말이 다른 팀에는 전혀 맞지 않을 수 있다. 그래도 대부분의 엔지니어는 코드를 읽으려는 데서 벗어나 코드를 읽지 않아도 안전한 환경을 만드는 데 나서야 한다. 에이전트의 역량이 더는 나아지지 않더라도 소프트웨어 엔지니어의 일은 이미 달라졌다. 역량이 계속 개선되면 그 일은 완전히 바뀔 것이다.

이 변화가 불편하게 느껴질 수 있다. 하지만 선원이 날씨를 탓하지 않듯 ‘부실한 코드’를 불평하는 데 그쳐서는 안 된다. 사용할 수 있는 도구를 활용해 시스템을 개선해야 한다. 기계공처럼 일을 해내는 도구와 그 결과를 확인하는 검사를 만들어야 한다.