AI 시대의 엔지니어 역할 변화: 코드 작성자에서 시스템 사고자로
PE Expert 지식 공유 — 마이리얼트립 숙박프로덕트팀 신동빈 Product Engineer
PE Expert 지식 공유 — 마이리얼트립 숙박프로덕트팀 신동빈 Product Engineer
PE Expert는 마이리얼트립이 그리는 ‘문제 종결자’ Product Engineer 중에서도, PE의 정의와 방향을 선도하며 조직 내 PE를 이끄는 역할을 맡고 있습니다.
2026년, 마이리얼트립 Product Engineer 사이에서는 흥미로운 논의가 이어지고 있습니다.
AI 에이전트가 코드를 작성하고, 테스트를 생성하고, 심지어 문서까지 만들어내는 시대. 그렇다면 엔지니어는 이제 무엇을 해야 할까요?
회원주문개발팀에서는 이미 한 달에 290건 이상의 커밋이 만들어지고, 그중 상당수는 AI 에이전트가 생성한 코드입니다. Vibe Coding에서 Harness Engineering까지, 개발 방법론 자체가 빠르게 진화하고 있습니다.
동빈님도 숙박프로덕트팀에서 이 변화를 직접 경험하면서 한 가지 확신을 갖게 됐다고 합니다. 엔지니어의 가치가 사라지는 것이 아니라, 그 가치가 발현되는 지점이 달라지고 있다는 것입니다.
코드를 잘 짜는 것이 전부였던 시절
엔지니어의 역량은 오랫동안 명확했습니다.
얼마나 빠르고 정확하게 코드를 작성하는가, 얼마나 복잡한 알고리즘을 구현할 수 있는가.
지금은 다릅니다. AI가 코드를 작성합니다. 테스트를 생성합니다. 버그를 찾아냅니다. 그것도 사람보다 빠르고, 지치지 않고, 점점 더 잘하고 있습니다.
그렇다면 엔지니어는 이제 무엇을 해야 할까요?
전통적 개발 방식의 균열
기존 조직에서 AI는 “도구”였습니다.
AI가 코드를 작성하면 사람이 검토하고, AI가 수정하고, 사람이 다시 검토하는 방식. 하지만 AI가 점점 잘하게 되면서, 개발부터 테스트, 검토, 수정까지 모든 과정을 하나의 자동화된 사이클로 묶을 수 있게 되었습니다. 사람의 개입은 초기 기준 설정과 최종 검토에만 필요해지고 있습니다.
엔지니어 역할 변화의 핵심: 기준 설정자
동빈님이 강조하는 핵심은 하나입니다.
코드를 작성하는 것이 엔지니어의 핵심 가치가 아니라는 것. 엔지니어는 이제 ‘기준 설정자’이자 ‘게이트키퍼’가 됩니다.
동빈님은 AI 시대에 엔지니어의 가치가 세 가지로 수렴한다고 봅니다. 코드 작성자는 문제 정의자로, 구현자는 가치 판단자로, 프로그래머는 정책 결정자로 역할이 이동하고 있습니다.
물론, “코딩 능력 없이 어떻게 문제를 제대로 정의하느냐”는 반론이 있습니다. 동빈님도 이 점을 인정합니다. 기술적 깊이는 여전히 필수입니다. 차이는 그 능력을 어디에 쓰느냐입니다.
AI가 구현을 담당하게 된 지금, 기술 역량의 가장 높은 쓸모는 “코드 작성”이 아니라 “무엇을 만들어야 하는지, 어떤 기준으로 판단해야 하는지”를 정의하는 데 있습니다.
AI 시대, 주목받는 엔지니어 직군
실리콘밸리를 비롯한 글로벌 IT 업계는 이 변화를 반영하고 있습니다. AI가 구현을 담당하게 되면서, 다음 직군들의 진가가 비로소 드러나고 있습니다.
Product Engineer
단순히 풀스택 개발을 하는 사람이 아닙니다. 기술 역량을 가지면서도, 사용자 관점과 비즈니스 관점에서 문제를 정의하고 해결책을 판단할 수 있는 사람입니다.
- Software Engineer: “어떻게 구현할 것인가”에 집중
- Product Engineer: “왜 만드는가, 무엇을 해결하는가”에 집중
Staff+ Engineer
Will Larson이 정의한 Staff+ Engineer는 관리자가 아닌 Individual Contributor이지만 리더십을 발휘합니다. 핵심 역량은 기술이 아닌 비판적 사고, 판단력, 경청, 공감, 커뮤니케이션입니다.
Founding Engineer
2025년 실리콘밸리에서 가장 수요가 높은 직군. 고객과 대화하고, 제품의 방향을 결정하고, 비즈니스 전략을 고민합니다. 코드는 그 수단일 뿐입니다.
지금 엔지니어들은 무엇에 시간을 쓰고 있는가
동빈님이 분석한 현재 엔지니어들의 시간 배분입니다. 대부분의 엔지니어는 코드 작성에 60–70%의 시간을 쓰고 있습니다. 테스트와 검증에 15–25%, 그리고 기준과 정책을 수립하는 데는 고작 10–15%만 투자합니다.
그런데 AI 역량으로 보면 정반대입니다. 코드 작성과 테스트는 AI가 잘하는 영역입니다. 반면 기준과 정책 수립은 AI가 아직 약한 영역이죠. 엔지니어가 진짜 가치를 발휘해야 할 곳에 가장 적은 시간을 쓰고 있는 셈입니다.
이상적으로는 기준과 정책 수립에 더 많은 시간을 투자하고, 코드 작성과 테스트는 AI에게 위임하는 방향으로 가야 합니다. 이것이 현재의 구조적 비효율입니다.
왜 문서화가 새로운 핵심 역량인가
동빈님은 문서화의 중요성을 강조합니다. 기준은 머릿속에 있을 때는 자산이 아닙니다. 팀과 AI가 공유할 수 있는 형태로 기록될 때 비로소 가치를 가집니다. 그것이 문서화입니다.
이 문서화는 기존의 “코드 주석”이나 “API 문서”가 아닙니다.
- 비즈니스 관점: A/B 테스트 전략, 유저 플로우와 페르소나, “왜 이 기능이 필요한가”에 대한 맥락
- 디자인 관점: 왜 이 버튼이 이 위치에 있는가, 특정 상황에서 색상/레이아웃이 다른 이유
- 아키텍처 관점: DDL과 데이터 모델 설계 의도, 트랜잭션 경계와 일관성 보장 전략, API 계약과 제약 조건
이 문서들이 없으면 세 가지 문제가 발생합니다.
- 컨텍스트 손실: 왜 이렇게 설계했는지가 사라집니다. 6개월 후 누구도 의도를 파악하기 어렵습니다.
- 재사용 불가: 판단의 근거가 없으면 비슷한 상황에서 처음부터 다시 고민합니다. 조직 지식이 축적되지 않습니다.
- AI 활용의 한계: 명확한 맥락과 기준이 없는 AI는 추측할 수밖에 없습니다.
“문서를 먼저 쓰자”의 함정
여기까지의 논리를 따라가면 자연스러운 결론이 나옵니다. 문서를 먼저 완벽하게 쓰고, AI가 구현하고, 사람이 검토하자. Gartner도 “Specification-Driven Development”를 전략 트렌드로 제시했고, 방향 자체는 맞습니다.
하지만 동빈님은 직접 적용해보면서 이 접근의 구조적 문제를 발견했다고 합니다. 이것은 이름만 다른 폭포수(Waterfall)라는 것입니다.
사람은 처음부터 모든 것을 계획해서 개발하지 않습니다. 만들어봐야 비로소 보이는 것들이 있습니다. “이 API 구조로는 프론트에서 쓰기 불편하겠는데”, “이 데이터 모델로는 쿼리가 너무 느리겠다” — 이것은 문서를 아무리 꼼꼼히 써도 사전에 알 수 없습니다.
Paul Graham이 “쓰기는 생각의 형태”라고 했는데, 코딩도 마찬가지로 생각의 형태입니다. 만들어보는 행위 자체가 문제를 더 깊이 이해하게 해줍니다.
그래서 동빈님이 도달한 현실적인 답은 이렇습니다. 한 번에 완벽한 문서를 쓰려 하지 말고, 사이클을 짧게 가져가지. 아는 만큼만 쓰고, AI가 구현하고, 놓친 부분이 드러나면 문서를 보강하고, 다시 구현합니다. 이 사이클을 짧게 여러 번 돌리면서 문서를 점진적으로 완성해가는 것입니다. 그리고 보강은 끝이 없기 때문에, 매 사이클마다 “이 정도면 충분한가?”를 판단하는 경계선이 필요합니다. 이 경계선을 정하는 것 자체가 엔지니어의 판단 영역입니다.
놓치기 쉬운 절반: 비기능 요구사항
동빈님이 스스로 인정하는 초기 사고의 맹점이 있습니다. 처음에는 기능 요구사항만 생각했다는 것입니다. “구매 버튼을 누르면 주문이 생성된다” 같은 것들이요.
하지만 AI가 정말 못하는 건 그 옆에 있었습니다. 성능, 보안, 신뢰성, 운영 가능성 — 비기능 요구사항입니다.
이것은 직관이 아니라 데이터가 보여주는 현실입니다. AI 생성 코드는 보안 취약점이 2.74배 많고(Veracode 2025), 성능 이슈가 1.42배 많고(CodeRabbit 2025), AI를 많이 쓴 팀일수록 전달 안정성이 오히려 떨어졌습니다(Google DORA 2024). IEEE Spectrum은 “조용한 실패”를 보고했는데, 코드가 기능적으로는 작동하는 것처럼 보이면서 안전 검사를 슬쩍 제거하는 패턴입니다. 기능 테스트로는 잡을 수 없습니다.
왜 이런 일이 벌어질까요? “구매 버튼 → 주문 생성”은 명세하고 테스트할 수 있습니다. 하지만 “동시 1만 사용자를 200ms 이내로 처리”는 DB, 네트워크, 캐싱, CDN 등 시스템 전체의 상호작용에서 나오는 속성입니다. 코드 한 조각을 잘 쓴다고 해결되지 않습니다.
동빈님은 비기능 요구사항을 세 계층으로 나눠서 다뤄야 한다고 제안합니다.
첫째, 예방
AI가 할 수 있는 것. N+1 쿼리 금지, OWASP 보안 패턴 준수 같은 규칙은 명세로 표현할 수 있고 AI가 따를 수 있습니다.
둘째, 탐지
도구가 해야 하는 것. 부하 테스트, 보안 스캔, 아키텍처 적합성 검사 같은 자동화된 게이트가 AI의 산출물을 검증합니다. Kent Beck이 경고한 것처럼, AI가 이 테스트 자체를 조작하지 못하게 하는 것이 핵심입니다.
셋째, 대응
사람이 반드시 해야 하는 것. 장애 대응, 용량 계획, 아키텍처 진화 결정. 프로덕션에서 실제 트래픽을 보면서만 할 수 있는 판단이며, AI가 근본적으로 참여할 수 없는 영역입니다.
이 세 계층은 순환합니다. 프로덕션에서 발견된 패턴이 새로운 예방 규칙과 탐지 테스트로 돌아옵니다.
기준 설정자를 넘어: 엔지니어의 확장된 역할
동빈님은 처음에 엔지니어의 미래 역할을 “기준 설정자”로 정의했습니다. 하지만 비기능 요구사항과 반복적 명세 진화를 고려하면서, 그 정의가 더 확장되었습니다.
기준 설정자. 무엇을 만들 것인가, 어떤 품질 수준을 목표로 할 것인가를 정합니다. 기능뿐 아니라 비기능 요구사항의 예방 규칙까지 포함합니다.
검증 설계자. AI가 넘어야 할 게이트를 설계합니다. AI가 수정할 수 없는 불변 검증 세트를 만드는 것이 핵심입니다.
시스템 사고자. 배포 이후의 세계를 책임집니다. 모니터링, 장애 대응, 용량 계획, 그리고 프로덕션에서 배운 것을 다시 예방 규칙으로 돌려보내는 학습 환류.
명세 진화 관리자. 문서와 구현이 함께 진화할 때, “지금 진실인 문서”를 항상 명확히 유지하고, 매 사이클 끝에 한 것과 안 한 것을 명시적으로 정리합니다.
엔지니어의 미래
동빈님은 패러다임이 전환되고 있다고 말합니다.
과거에 엔지니어는 코드 작성자였습니다. 현재는 코드 작성자이면서 동시에 AI 활용자이기도 합니다. 그리고 미래에는 기준 설정자, 검증 설계자, 시스템 사고자가 될 것입니다.
동빈님은 이 변화가 엔지니어의 쇠퇴가 아니라고 강조합니다. 진화입니다. 코드 작성이라는 반복적 작업에서 벗어나, 문제를 정의하고 트레이드오프를 판단하고 기준을 세우는 본질적 가치로 돌아가는 것입니다.
다만, 직접 부딪히면서 세 가지를 배웠다고 합니다. 완벽한 문서를 한 번에 쓸 수 없다는 것, 기능만 생각하면 절반을 놓친다는 것, 그리고 엔지니어의 역할은 기준 설정에서 끝나지 않고 검증과 운영과 명세의 진화까지 확장된다는 것.
동빈님은 이렇게 정리합니다. AI 네이티브 개발의 진정한 도전은 코드 생성을 자동화하는 것이 아닙니다. 품질에 대한 지속적 판단을 인간과 기계 사이에 어떻게 잘 분배할 것인가. 이것이 진짜 질문이고, 이 질문에 답하는 것이 앞으로 엔지니어의 일이라고요.
