AI 위임의 핵심 이슈: 어디까지 맡길 것인가
AI 코딩 도구를 팀에 붙이고 나면 반드시 마주치는 질문이 있다. "이 작업, AI한테 그냥 다 맡겨도 되나?" 이 질문에 제대로 답하지 못한 채 도구를 켜면, AI는 생산성 도구가 아니라 통제 불가능한 변수가 된다. 위임 범위를 설계한다는 건 단순히 AI 기능을 켜고 끄는 게 아니다. 어떤 행위는 AI가 자율적으로 수행하고, 어떤 행위는 반드시 사람의 확인을 거쳐야 하는지를 명시적으로 구조화하는 일이다.
맥락 해석: 두 가지 다른 접근이 말하는 것
최근 dev.to에서 주목할 만한 두 가지 사례가 이 질문에 서로 다른 각도로 답하고 있다.
첫 번째는 aitm 1.0이다. AI 터미널 도구인데, 설계 철학이 명확하다. "AI는 참여자이지 운전자가 아니다." 실제 구현을 보면 이 철학이 코드 수준으로 내려와 있다. AI는 list_files, read_file, get_terminal_history 같은 읽기 전용 도구는 자동으로 호출할 수 있다. 그러나 run_command—상태를 변경하는 모든 명령—는 반드시 사용자 확인을 통과해야 실행된다. 더 흥미로운 건 초기 설계에 "저위험 명령 자동 승인" 모드가 있었는데, 개발자가 직접 제거했다는 사실이다. 이유는 단 하나. "UX는 약간 나아졌지만, 통제하고 있다는 감각을 잃는 건 그 대가로 내줄 수 없었다."
보안 구현도 단순하지 않다. run_command 요청은 4개의 순차 게이트를 통과한다. L1은 rm -rf / 같은 하드코딩된 차단 패턴—사용자가 승인해도 막는다. L2는 휴리스틱 위험 점수화—명령이 루트 디렉토리를 건드리는지, 리다이렉션을 쓰는지 평가한다. L3는 프로젝트 스코프 검사—세션에 설정된 프로젝트 디렉토리 밖의 작업은 플래그 처리된다. L4는 명시적 사용자 확인 모달—자동 승인 경로는 코드 어디에도 없다. 이 게이트들이 Rust 레이어에서 실행된다는 점도 중요하다. JavaScript/React 레이어에서 우회할 수 없다.
두 번째는 마인드셋의 문제다. "ChatGPT를 선생님이 아니라 컴파일러처럼 쓰기 시작했다"는 글에서 개발자 Vasundhara는 AI 활용의 전환점을 이렇게 설명한다. 선생님 마인드셋에서는 AI에게 설명을 구하고, 솔루션을 복사하고, 답을 그냥 수용한다. 컴파일러 마인드셋에서는 내가 먼저 로직을 작성하고, AI는 그것을 검증하는 역할을 맡는다. 컴파일러가 코딩을 가르쳐 주지 않듯, AI도 정답을 주는 존재가 아니라 내 사고를 검증하는 도구로 포지셔닝하는 것이다.
시사점: 팀 레벨에서의 위임 설계
두 사례는 서로 다른 층위에서 같은 결론을 가리킨다. AI에게 위임할 범위는 명시적으로 설계되어야 한다. 개인 수준에서는 마인드셋의 문제고, 시스템 수준에서는 아키텍처의 문제다.
팀 레벨로 가져오면 이 설계는 세 가지 질문으로 구체화된다.
첫째, 읽기와 쓰기를 분리하고 있는가? aitm의 핵심 설계는 단순하다. 읽기는 AI 자율, 쓰기는 인간 승인. 이 구분을 팀의 AI 워크플로우에 명시적으로 적용했는가? 코드 생성은 제안, 커밋은 개발자 검토—이런 식의 경계가 실제로 프로세스에 박혀 있는가, 아니면 그냥 권고사항으로만 존재하는가.
둘째, 위험 수준에 따른 게이트가 있는가? L1~L4처럼 위험도를 단계화하고 각 단계마다 다른 처리 방식을 적용하는 구조가 팀 워크플로우에도 있어야 한다. 파일 읽기, 코드 생성, 테스트 실행, 프로덕션 배포—이 각각에 다른 승인 요건을 붙이는 게 자연스럽다.
셋째, 팀원들이 AI를 어떤 포지션으로 쓰고 있는가? "선생님 마인드셋"으로 AI를 쓰는 개발자는 AI가 내놓은 코드를 검증 없이 붙인다. "컴파일러 마인드셋"으로 쓰는 개발자는 자신의 설계를 먼저 짜고 AI에게 검증을 맡긴다. 팀 내에 이 두 유형이 섞여 있다면, AI가 생성한 코드의 품질 편차가 개인 역량 차이보다 훨씬 크게 나타날 수 있다.
전망: 위임 설계가 팀 역량이 되는 시대
aitm 개발자가 자동 승인 모드를 제거한 결정은 기술적 판단이기도 하지만 철학적 판단이기도 하다. "통제하고 있다는 감각"을 UX 편의보다 우선했다는 것—이건 AI 도구 설계에서 점점 중요해질 원칙이다. AI가 더 많은 것을 할 수 있게 될수록, 무엇을 맡기고 무엇은 사람이 쥐고 있을지를 명시적으로 정하는 능력이 팀의 핵심 경쟁력이 된다.
지금 당장 팀에 적용해볼 체크리스트는 간단하다. AI 도구가 자율적으로 수행하는 작업 목록을 뽑아보라. 그중 상태를 변경하는 작업이 있다면, 그게 명시적 승인 없이 실행되고 있는지 확인하라. 없다면 설계가 필요하다. 있는데 팀원들이 습관적으로 승인을 누르고 있다면, 그건 게이트가 있는 게 아니라 마찰만 추가된 것이다.
위임 범위 설계는 AI 도구를 도입한 다음 단계가 아니다. 도입과 동시에 해야 할 첫 번째 설계 작업이다.