코드를 만드는 비용이 낮아지면서 소프트웨어 엔지니어의 핵심 업무는 무엇을 만들고 어떻게 검토할지 판단하는 일이 됐다는 게 Swizec Teller의 주장이다. 그는 Plasmidsaurus에서 AI 에이전트를 활용해 개발 속도를 높인 경험을 바탕으로, 책임 문화와 코드 리뷰, 제품 부채 관리가 더 중요해졌다고 설명한다.
Teller는 21명 규모의 엔지니어링 조직에서 하루에도 여러 차례 배포하며, 매주 수백 건의 PR을 처리한다고 전한다. 전체 PR의 16%를 자동 승인하고 병합하고, 대규모 일괄 마이그레이션도 수행한다. 그는 자신이 작성하는 코드의 97%를 AI가 쓴다고 밝힌다. 이는 운영 장애가 큰 비용으로 이어질 수 있는 사업 환경에서도 이뤄진다고 설명한다.
빠른 배포에는 책임이 따라야 한다
Teller는 이런 방식이 가능한 바탕으로 높은 책임감과 자율성을 갖춘 조직 문화를 꼽는다. 코드를 어떻게 작성했는지가 아니라, 작성한 사람이 결과에 책임지는지가 중요하다는 설명이다. AI가 작성한 코드도 예외가 아니다.
“PR 병합 정책은 간단하다. 우리는 당신의 전화번호를 갖고 있다. AI로 코드를 작성해도 당신의 전화번호는 그대로다.” — Swizec Teller, 2026년 2월 3일
엔지니어는 프로덕션에 올린 시스템을 운영하고, 만든 기능이 실제 효과를 내도록 책임진다. 사용자와 대화하고 이해관계자가 일하는 모습을 관찰하는 것도 업무의 일부다. Teller는 조직이 아이디어를 거의 거절하지 않고 먼저 출시한 뒤 질문하는 방식을 선호한다고 말한다. 다만 초기 아이디어가 가능성을 보이면 구체화할 시간과 여유를 준다.
AI 에이전트가 바꾼 개발 방식
Teller가 Plasmidsaurus에 합류했을 때 AI 코딩 도구는 유용한 자동완성과 잦은 오류가 공존하는 수준이었다. 그는 익숙하지 않은 Flask와 SQLAlchemy 코드로 자신의 소프트웨어 개발 경험을 옮기는 데 AI를 활용했다. 특히 SQL 쿼리를 SQLAlchemy 코드로 바꾸는 작업이 유용했다고 회고한다.
2024년 말에는 AI에게 간단한 코드를 작성하도록 지시하는 ‘바이브 코딩’이 가능해졌지만, 당시에는 ChatGPT에 코드를 직접 붙여 넣는 식이라 작업 흐름이 매끄럽지 않았다. Teller는 데이터베이스 마이그레이션이나 관리용 스크립트처럼 작성은 번거롭지만 결과를 빠르게 확인할 수 있는 작업에 이를 활용했다. AI가 코드를 작성하도록 지도하는 방법도 소개했다.
그가 큰 전환점으로 꼽는 시기는 2025년 7월이다. Cursor의 백그라운드 에이전트로 작업 전체를 맡기고, 완료 후 PR과 스크린샷, 데모 영상을 검토한 뒤 댓글로 수정 사항을 전달할 수 있게 됐다. 에이전트가 일하는 모습을 계속 지켜보는 대신 다른 일에 시간을 쓸 수 있다는 점이 달라졌다.
늘어난 것은 주로 자잘한 개선 작업이다
Teller는 AI가 조직의 최우선 목표 달성 자체를 더 많이 보장하지는 않는다고 선을 긋는다. 다만 더 많은 시간을 들일 수 있어 기능이 완성도와 세부 측면에서 나아졌다고 말한다. 가장 큰 변화는 과거에는 우선순위에 밀렸을 버그와 기능 개선까지 처리할 수 있게 된 점이다.
그가 제시하는 엔지니어링 조직의 목표는 제품을 만들고 사업 운영의 효율성을 높이는 것이다. 고객이 늘면 반복 작업과 사소한 오류도 큰 부담이 된다. 따라서 이해관계자가 불편해하는 업무를 관찰하고, 에이전트에게 내부 도구나 대시보드를 만들게 하는 식으로 마찰을 줄일 수 있다. 반복해서 답하거나 수행하는 일이 있다면 간단한 프롬프트로 자동화하는 것도 방법이라고 설명한다.
이때 기능의 작동 모습을 스크린샷과 영상으로 받아 빠르게 확인할 수 있지만, 자족적인 기능이라면 초기에는 코드 품질보다 빠른 적용을 우선할 수 있다는 것이 Teller의 견해다. 이후 실제 사용 과정에서 발견한 문제를 개선해야 한다.
시작은 쉬워져도 마무리는 어렵다
에이전트에게 여러 작업을 동시에 맡기면 진행 중인 일이 쌓여 주된 업무에 집중하기 어려워질 수 있다. Teller는 간단한 요청과 버그 수정, 큰 작업을 연이어 맡기다 보면 하루가 끝날 무렵 초안 PR이 여러 개 열려 있고, 주요 우선순위는 거의 진척되지 않는 상황이 생긴다고 설명한다.
그가 권하는 대응은 핵심 우선순위를 지키고, 임시 요청에 쓸 하루 예산을 정한 뒤 나머지는 분류 작업으로 넘기는 것이다. 그가 속한 조직에서는 매 스프린트 우선순위 작업의 절반가량이 분류 과정을 거쳐 올라온다고 한다. 다만 문구나 색상처럼 간단한 수정까지 지나치게 오래 우선순위 판단에 붙들 필요는 없다고 덧붙인다.
Teller는 에이전트가 만든 코드도 직접 작동하는 모습을 확인해야 한다고 강조한다. 스크린샷과 안내 영상이 있어도 기본 사용 경로를 짧게 점검하면 출시 전 작은 사용성 문제를 찾을 수 있다는 설명이다.
검토와 제품 품질이 병목이 된다
코드를 빠르게 만들고 배포하기 쉬워지면서 검토가 병목이 됐다. 여기서 검토는 코드만 읽는 일을 뜻하지 않는다. 기능이 목적을 달성하는지, 다른 기능과 잘 어울리는지, 제품 전체가 일관성 있게 작동하는지도 확인해야 한다.
https://swizec.com/assets/Lots-of-ideas-lots-of-code-little-ship-eh4bhc-DS9rckqO.png
Teller는 기능을 계속 추가할 때 생기는 ‘제품 부채’를 경고한다. 사용자마다 불필요하다고 생각하는 기능이 다르므로, 개별 기능에 집중해 추가한 결과 제품 전체가 복잡해질 수 있다. 사용자는 기능마다 다른 학습 과정에 부담을 느끼고, 익숙한 옛 방식을 고수할 수도 있다. 기능이 늘어나면 유지보수해야 할 코드와 장애 가능성도 함께 쌓인다.
이를 줄이려면 사용자 경험을 처음부터 끝까지 검토하고, 효과가 없는 기능을 제거하며, 디자인 시스템과 컴포넌트 라이브러리를 만들어야 한다고 말한다. 엔지니어와 에이전트가 기본적인 상호작용 방식을 매번 새로 만들지 않도록 하는 것이다.
코드 품질은 에이전트 사용 비용에도 영향을 준다
Teller는 에이전트가 엔지니어링 조직의 규모를 크게 키우는 것처럼 기존 코드 품질을 증폭한다고 주장한다. 구조가 뒤엉킨 코드베이스에서는 에이전트도 그 복잡성을 이어받고, 모듈 간 책임과 규칙이 분명한 구조에서는 기존 패턴을 따르기 쉽다는 설명이다.
그는 한 실험에서 파일 구조를 개선하자 코딩 작업의 토큰 비용이 83% 줄었다고 소개한다. 에이전트가 변경을 위해 읽고 다루는 코드가 적고 구조를 쉽게 탐색할수록 토큰을 덜 쓰기 때문이다. Teller는 명확한 모듈과 계약, 적절한 추상화가 필요하며, 에이전트는 이런 구조를 스스로 잘 만드는 데 약하다고 말한다. 따라서 기존 패턴을 따르도록 지시하는 편이 낫다는 설명이다. ‘거대한 진흙 덩어리’ 코드의 문제는 이 글에서도 다룬다.
반복되는 리뷰 지적은 규칙으로 바꾼다
Teller는 시니어 엔지니어의 역할이 사람과 에이전트가 함께 소프트웨어를 만들 수 있는 사회·기술적 시스템을 구축하는 쪽으로 바뀌고 있다고 본다. 그는 몇 달 동안 매주 평균 40~50건의 코드 리뷰를 했으며, 자신의 GitHub 기여 절반가량이 코드 리뷰였다고 밝힌다.
그가 경험한 코드 리뷰 에이전트는 유용한 지적을 하기도 하지만, 관련성이 낮거나 아직 중요하지 않은 의견도 내놓는다. 제품의 핵심 기능인지, 소수만 쓰는 내부 기능인지와 같은 사업 맥락과 우선순위도 충분히 파악하지 못한다고 지적한다. 일반적인 모범 사례만으로는 팀의 아키텍처와 실제 사용자 요구를 판단하기 어렵다는 것이다.
반복해서 발견하는 문제는 에이전트용 문서와 자동화된 린터 규칙으로 바꿀 수 있다. 팀이 규칙을 담은 .md 파일을 갱신하면 이후 PR에서 에이전트가 그 지침을 따르도록 할 수 있다. 다만 에이전트는 규칙의 취지를 이해하지 못한 채 문자 그대로 적용할 수 있으므로, 지침을 신중하게 작성해야 한다고 말한다.
반복적인 리뷰 의견을 잡아내는 결정론적 린터를 만들고 CI와 커밋 훅에 추가하는 방법도 제안한다. Teller는 자사 기술 스택에서 수십 개의 맞춤형 린터를 운영하며, 검사가 모두 통과해야 사람이 코드를 병합할 수 있다고 전한다. 이런 규칙이 충분히 작동하면 위험이 낮은 코드에 자동 승인·병합을 적용할 수 있다는 설명이다.
Teller가 제시하는 변화의 핵심은 코드 작성 자체보다 문제를 고르고, 결과를 검토하고, 사용자가 원하는 효과를 내도록 끝까지 책임지는 일이 중요해졌다는 것이다. 그는 이를 “코드가 저렴해지면 판단이 일이 된다”는 말로 요약한다.
출처: Swizec Teller, 2026년 10월 8일
분류: 소프트웨어 엔지니어링 팀워크 경영 생산성 AI
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요