AI 시대의 엔지니어 역할 변화: 코드 작성자에서 시스템 사고자로

AI 에이전트가 코드 작성, 테스트 생성, 문서 작성까지 맡는 환경에서 엔지니어의 역할은 달라지고 있다. 마이리얼트립 숙박프로덕트팀 신동빈 Product Engineer는 코드 생산량보다 무엇을 만들지, 어떤 기준으로 판단할지를 정하는 능력이 더 중요해졌다고 본다.

과거에는 엔지니어의 역량이 얼마나 빠르고 정확하게 코드를 작성하느냐에 집중됐다. 하지만 지금은 AI가 구현과 테스트, 버그 탐지까지 빠르게 수행하면서, 사람의 가치는 코드 자체보다 문제 정의, 판단, 정책 설정에서 드러난다.

기존 개발 방식에서는 AI가 도구였고, 사람은 그 결과를 검토하는 구조였다. 그러나 AI가 고도화되면서 개발부터 테스트, 검토, 수정까지를 하나의 자동화된 사이클로 묶을 수 있게 됐고, 사람은 초기 기준 설정과 최종 검토에 더 집중하게 된다.

동빈님이 강조하는 핵심 역할은 기준 설정자다. 엔지니어는 단순한 구현자가 아니라, 무엇을 만들고 어떤 품질을 요구할지 정하는 사람이며, 동시에 AI가 넘지 말아야 할 선을 정하는 게이트키퍼가 된다.

이 변화 속에서 주목받는 직군도 달라진다.

• Product Engineer: 구현보다 왜 만드는지, 무엇을 해결하는지에 집중한다.
• Staff+ Engineer: 기술만이 아니라 비판적 사고, 판단력, 경청, 공감, 커뮤니케이션으로 리더십을 발휘한다.
• Founding Engineer: 고객 대화, 제품 방향, 비즈니스 전략까지 다루며 코드는 수단이 된다.

시간 배분도 비효율적이다. 많은 엔지니어가 코드 작성에 **60–70%**를 쓰는 반면, 기준과 정책 수립에는 **10–15%**만 쓴다. 하지만 AI가 잘하는 영역은 코드와 테스트이고, 사람이 더 강한 영역은 기준과 정책이기 때문에, 중요한 곳에 더 많은 시간을 배분해야 한다고 본다.

문서화 역시 핵심 역량으로 부상한다. 기준은 머릿속에 있을 때는 자산이 아니며, 팀과 AI가 공유할 수 있는 문서로 남겨야 재사용 가능해진다. 이 문서는 단순한 주석이나 API 문서를 넘어, 비즈니스 맥락, 디자인 의도, 아키텍처 의사결정까지 포함해야 한다.

다만 “문서를 먼저 완벽하게 쓰고 구현하자”는 접근은 한계가 있다. 실제로 만들어봐야 드러나는 문제들이 있고, 그래서 필요한 것은 한 번에 완성하는 방식이 아니라 짧은 사이클로 문서와 구현을 함께 진화시키는 방식이다. 아는 만큼만 쓰고, 구현하면서 발견한 내용을 문서에 반영하는 반복이 필요하다.

초기에는 기능 요구사항만 생각하기 쉽지만, AI가 특히 약한 영역은 비기능 요구사항이다. 성능, 보안, 신뢰성, 운영 가능성 같은 요소는 코드 한 조각이 아니라 시스템 전체에서 결정되며, AI 생성 코드는 보안 취약점과 성능 이슈, 전달 안정성 문제를 더 자주 만들 수 있다는 점도 지적된다.

이에 따라 비기능 요구사항은 세 계층으로 다뤄야 한다.

• 예방: N+1 쿼리 금지, OWASP 준수 같은 규칙을 명세로 정의한다.
• 탐지: 부하 테스트, 보안 스캔, 아키텍처 검사를 자동화한다.
• 대응: 장애 대응, 용량 계획, 아키텍처 진화를 사람이 책임진다.

결국 엔지니어의 역할은 기준 설정자, 검증 설계자, 시스템 사고자, 명세 진화 관리자로 확장된다. AI 네이티브 개발의 핵심은 코드 생성을 자동화하는 데 있지 않고, 품질 판단을 인간과 기계 사이에 어떻게 분배할지 설계하는 데 있다.