'AI가 코드를 짠다'는 말은 이제 선언이 아니라 전제다. 문제는 그 다음이다. 구현이 AI에게 넘어간 자리에서 개발자는 무엇을 소유하는가. Vladimir Panov가 dev.to에 공개한 AI-Native Software Delivery 프레임워크는 이 질문에 꽤 구체적으로 답한다. 핵심은 단순하다. 소유 대상이 코드에서 결과(result)로 이동한다.
전통적인 엔지니어링 조직은 구현 전문화를 중심으로 설계됐다. 프론트엔드 팀, 백엔드 팀, 인프라 팀, QA 팀. 이 구조가 만들어진 이유는 명확하다. 구현 복잡도가 깊은 전문화를 요구했기 때문이다. AI-Native 조직은 다른 축으로 설계된다. 수직적 기능 오너십, 실행 가능한 행동 보장, 수평적 거버넌스 역할. 조직의 무게중심이 '누가 이 코드를 만들었나'에서 '이 기능이 어떤 결과를 보장하는가'로 옮겨간다.
이 전환에서 가장 실질적인 개념이 Specification as Code다. 기존 Jira 티켓은 단편적이다. 로그인 기능을 도입한 티켓, MFA를 추가한 티켓, 세션 만료를 변경한 티켓이 흩어져 있고, 결국 현재 동작을 온전히 파악하려면 구현 코드까지 뒤져야 한다. Panov의 프레임워크에서 Story Spec은 이 파편화를 거부한다. Git에서 버전 관리되는 살아있는 명세로, 현재 동작·고객 기대·실행 가능한 검증이 하나의 문서에 공존한다. 스펙이 낡은 문서가 아니라 시스템의 실제 진실이 된다.
그러면 개발자는 무엇을 하는가. 프레임워크는 역할을 네 가지로 압축한다. 리뷰어, 오케스트레이터, 밸리데이터, 시스템 사상가. 구현을 직접 생산하는 비중은 줄어들고, 의도를 정의하고 결과를 검증하는 비중이 늘어난다. 특히 강조되는 것이 Behavioral Validation이다. AI가 생성한 코드를 얼마나 깊이 들여다보는가보다, 그 코드가 기대한 행동을 실제로 만들어내는가를 실행 가능한 형태로 증명하는 것이 핵심 안전장치가 된다. 품질 게이트가 구현 리뷰에서 행동 검증으로 이동하는 것이다.
이 맥락에서 Claude Code 다중 계정 관리 패턴이 흥미롭게 겹쳐진다. dev.to의 다른 글에서 Harinder Yuvraj가 소개한 direnv + CLAUDE_CONFIG_DIR 조합은 표면적으로는 계정 격리 팁처럼 보이지만, 실제로는 신뢰 경계(trust boundary)를 폴더 단위로 구조화하는 워크플로우 설계다. 개인 프로젝트, 회사 코드베이스, 프리랜서 클라이언트 작업이 하나의 전역 Claude 프로필에 뒤섞이면 MCP 툴 인증, GitHub org, Slack 워크스페이스가 의도치 않게 교차된다. ~/clients/acme/.envrc에 CLAUDE_CONFIG_DIR을 지정하면 그 하위 모든 레포가 Acme 컨텍스트 안에서만 AI를 실행한다. 오케스트레이터로서의 개발자가 신경 써야 할 것이 바로 이런 경계 설계다.
두 아이디어를 연결하면 AI-Native 워크플로우에서 개발자가 실질적으로 통제해야 하는 세 레이어가 보인다. 첫째, 명세 레이어: Story Spec을 코드처럼 작성하고 Git으로 진화시킨다. 둘째, 검증 레이어: 실행 가능한 E2E 행동 보장을 품질 게이트로 세운다. 셋째, 신뢰 경계 레이어: AI 에이전트가 실행되는 컨텍스트와 권한 범위를 명시적으로 설계한다. 이 세 레이어를 잡지 않으면 AI는 빠르게 움직이지만 팀이 통제하는 방향으로 움직이지 않는다.
현실적으로 냉정하게 보면, 이 전환의 학습 비용은 작지 않다. '스펙을 코드처럼 쓴다'는 것은 개념적으로는 단순하지만, 팀이 실제로 실행 가능한 행동 시나리오를 Story Spec으로 만들어내려면 제품 도메인 이해와 테스트 설계 역량이 동시에 필요하다. AI가 구현을 가속하는 만큼 명세와 검증을 설계하는 역량의 희소성이 올라간다. 역설적으로, AI-Native 조직일수록 도메인 깊이와 검증 설계력을 갖춘 개발자의 가치가 더 커진다.
팀 리빌딩 관점에서 이 프레임워크가 가리키는 방향은 하나다. 다음 채용 기준에서 '얼마나 빠르게 코드를 짜는가'보다 '얼마나 정확하게 결과를 정의하고 검증하는가'의 가중치를 높여야 한다. Specification as Code를 작성하고, Behavioral Validation을 설계하고, AI 에이전트의 신뢰 경계를 구조화하는 것—이 세 가지가 AI-Native 팀에서 개발자의 진짜 역할이다.