“어떤 모델을 쓸까?”라고 묻는 대신 팀의 AI 공급망 (AI Supply Chain)을 개선하기 시작하세요 [Image Test B]

이번 주는 한 가지 사실을 명확히 보여주었습니다: AI 코딩 속도는 빨라졌지만, 이제 코드에 대한 신뢰가 진정한 병목 현상(bottleneck)이 되었습니다. Hook: 무서운 점은 더 이상 잘못된 코드가 아닙니다. 현재 소프트웨어 팀에서 가장 큰 AI 리스크는 잘못된 결과물(output)이 아니라, 잘못된 출처(provenance)입니다. 제가 아는 대부분의 시니어 개발자들은 PR(Pull Request)에서 불안정한 코드를 감지할 수 있습니다. 우리는 수년간 그 직관을 훈련해 왔습니다. 더 새롭고(그리고 더 고약한) 문제는 겉보기에는 괜찮아 보이고, 빠르게 배포되며, 소유권(ownership), 추적 가능성(traceability) 또는 보안 가정(security assumptions)을 조용히 깨뜨리는 코드입니다. 만약 여러분의 워크플로우가 여전히 AI를 “단순히 더 빠른 자동 완성(autocomplete)”으로 취급하고 있다면, 여러분은 잘못된 경계(perimeter)를 방어하고 있는 것입니다.

이번 주에 변화된 점 (그리고 이것이 단순한 노이즈가 아닌 이유): 이번 주에는 몇 가지 트렌드 신호가 중요한 방식으로 정렬되었습니다: Anthropic이 Stainless를 인수했는데, 이는 “모델 + API 라이프사이클(lifecycle)”이 두 개의 별개 도구가 아닌 하나의 제품 표면(product surface)이 되고 있다는 강력한 암시입니다. HN(Hacker News)의 한 리포지토리(repo) 관리자 이야기는 Git의 --author 플래그 전략을 사용하여 AI 봇 스팸을 차단하는 사례를 보여주었습니다. 화려하지는 않지만 매우 현실적인 문제입니다: 신원(identity)과 귀속(attribution)은 이제 활발한 공격 표면(attack surfaces)입니다. 로컬 우선(Local-first) 및 자기 제어형(self-controlled) 툴링이 계속해서 주목을 받고 있습니다 (예를 들어, Files.md의 견인력, M1에서의 Haiku 관련 논의 등). 이것은 향수가 아니라, 개발자들이 제어 평면(control planes)을 되찾아오는 과정입니다. 서로 다른 이야기들이지만 방향은 같습니다: 우리는 “AI가 코드를 쓸 수 있는가?”에서 “우리 시스템이 누가/무엇이 코드를 변경했는지, 왜 변경했는지, 그리고 어떤 가드레일(guardrails) 하에 변경했는지를 검증할 수 있는가?”로 이동하고 있습니다.

실제 팀에서 이것이 중요한 이유: 개인 프로젝트에서는 느낌대로 코딩(vibe-code)하고 복구할 수 있습니다. 하지만 팀에서는 모호함이 복리로 쌓입니다. 실제 배포 환경에서 제가 목격하고 있는 현상은 다음과 같습니다: PR 볼륨이 리뷰의 깊이보다 더 빠르게 증가합니다. 생성된 코드가 충분한 아키텍처 컨텍스트(architectural context) 없이 전달됩니다. 소유권이 모호해집니다: “어시스턴트가 작성했다”는 것은 책임 모델(accountability model)이 아닙니다. 보안 및 컴플라이언스(compliance) 팀은 영향 범위(blast radius)가 이미 커진 후에야 뒤늦게 투입됩니다. 고통스러운 부분은 이겁니다: 서류상으로는 속도(velocity)가 매우 좋아 보이지만, 단 한 번의 엉망인 사고로 인해 작업 중단(freeze)이 강제될 때까지는 말이죠. 그러고 나면 모두가 이것이 예측 불가능한 일이었다고 가장합니다. 하지만 그것은 예측 가능한 일이었습니다.

AI가 소프트웨어 엔지니어링의 제약 조건(constraints)을 제거한 것은 아닙니다. 단지 그 위치를 옮겼을 뿐입니다. 과거에는 코드를 생산하는 데 더 많은 시간을 썼다면, 이제는 코드가 존재할 가치가 있음을 증명하는 데 더 많은 시간을 쓰고 있습니다. 대부분의 사람들이 던지는 잘못된 질문은 “어떤 모델을 표준으로 삼아야 할까?”입니다. 이 질문이 무의미한 것은 아니지만, 더 이상 최우선 과제(first-order)는 아닙니다. 모델 선택도 중요합니다. 하지만 팀들은 워크플로 무결성(workflow integrity)에 대한 투자는 소홀히 하면서 모델의 지능(IQ)에만 과도하게 집중하고 있습니다. 취약한 워크플로에서 더 강력한 모델을 사용하는 것은 단지 더 높은 처리량(throughput)으로 모호함을 만들어낼 뿐입니다. 역발상적인 관점을 제시하자면, 대부분의 팀에게는 프로세스 품질을 업그레이드하는 것이 모델 품질을 업그레이드하는 것보다 더 나은 성과를 낼 것입니다. 영원히 그렇지는 않겠지만, 적어도 이번 분기에는 확실합니다. 만약 당신의 브랜치 전략(branch strategy)이 혼란스럽고, 리뷰 계약(review contract)이 모호하며, 커밋 식별(commit identity) 규칙이 느슨하다면, 모델의 성능 향상은 대부분 겉치레에 불과합니다.

더 나은 질문은 이것입니다: “우리의 AI 워크플로에서 신뢰가 깨지는 지점은 어디인가?” 대신 이렇게 물으십시오: “정확히 어떤 핸드오프(handoffs) 단계에서 문맥이 부족한(low-context) AI 출력물이 높은 영향력을 가진 운영 리스크(production risk)가 될 수 있으며, 그러한 격차를 메울 가벼운 통제 수단(lightweight controls)은 무엇인가?”

그다음, 이번 스프린트(sprint)에 바로 적용할 수 있는 실무적인 플레이북(playbook)을 실행하십시오.

1. PR에 출처 계약(provenance contract) 추가하기
   모든 AI 지원 PR(Pull Request)에는 다음 사항이 포함되어야 합니다:

• 무엇이 생성되었는가 (파일 또는 모듈)
• 무엇이 인간에 의해 작성되었는가
• 어떤 체크(checks)가 실행되었는가
• 무엇이 아직 검증되지 않은 상태인가
  짧고 필수적으로 유지하십시오. 논문을 쓰는 것이 아니라 감사 추적(audit trail)을 만드는 것입니다.

2. 커밋 식별 위생(commit identity hygiene) 강제하기
   워크플로에서 봇의 노이즈나 불분명한 저자 식별이 발생할 가능성이 있다면, 지금 즉시 이를 차단하십시오:

• 가능한 경우 검증된 커밋 이메일/도메인을 요구하십시오
• 봇/서비스 저자에 대한 규칙을 정의하십시오
• CI에서 예상치 못한 저자 패턴을 거부하십시오
  HN(Hacker News)의 봇 스팸 사례는 당신에게 주는 경고입니다. 이제 출처 규명(attribution)은 보안 통제(security control)의 영역입니다.

3. AI 사용을 차선(lanes)으로 분리하기
   “AI가 도움을 줌”이라는 하나의 거대한 범주를 사용하지 마십시오. 다음 3가지 차선(lanes)을 만드십시오:

• 초안 작성(drafting): 스캐폴딩(scaffolding), 보일러플레이트(boilerplate), 테스트 시드 생성
• 변환(transforming): 리팩토링(refactors), 마이그레이션(migrations), 반복적인 편집
• 결정(deciding): 아키텍처, 보안 민감 로직, 데이터 계약(data contracts)
  3번 차선은 항상 인간 우선 리뷰를 거쳐야 합니다. 예외는 없습니다.

4. 생성 프롬프트뿐만 아니라 리뷰 프롬프트(review prompts)도 업그레이드하세요. 대부분의 팀은 생성 프롬프트(generation prompts)만 다듬고 리뷰 프롬프트는 무시합니다. AI 중심의 차이점(diffs)에 맞춰 조정된 리뷰어 체크리스트를 사용하세요: 이 변경 사항이 불변량(invariants)을 유지하는가? 명명 규칙(naming)이 도메인 언어(domain language)에서 벗어나지 않았는가? 엣지 케이스(edge cases)가 테스트되었는가, 아니면 해피 패스(happy path)만 테스트되었는가? 숨겨진 결합도(hidden coupling)가 증가했는가? 리뷰를 영웅적 개인의 역량이 아닌, 명시적인 시스템으로 취급하세요.

5. 워크플로의 건강 상태를 나타내는 지표 하나를 추적하세요. 하나를 선택하여 간단하게 시작하세요: PR 재오픈 비율(PR reopen rate), 머지(merge) 후 7일 이내의 핫픽스(hotfixes) 발생률, AI 지원 PR당 중간 리뷰 라운드 수(median review rounds per AI-assisted PR), 완전한 출처 정보(provenance)가 포함된 AI 지원 PR의 비율. 대시보드 제국을 건설하지 마세요. 정직한 지표 하나가 10개의 허영 지표(vanity charts)보다 낫습니다.

6. “인간의 판단 목록(human judgment list)”을 유지하세요. 코드베이스 내에서 AI가 단독으로 결정해서는 안 되는 결정 사항들을 문서화하세요: 인증 경계(auth boundaries), 결제 로직(billing logic), 파괴적인 마이그레이션(destructive migrations), 장애 대응 자동화 단계(incident automation steps). 이를 통해 PR 도중 발생하는 모호한 논쟁을 방지하고, 시니어 엔지니어들이 끊임없는 에스컬레이션(escalation) 지점이 되는 것을 막을 수 있습니다.

가슴에 남는 마지막 한 마디: AI가 소프트웨어 엔지니어링의 기본 원칙을 없앤 것이 아닙니다. 단지 그 기본 원칙이 매일 당신에게 청구서를 내밀게 만들었을 뿐입니다. 올해 승리하는 팀은 가장 화려한 모델을 가진 팀이 아니라, 프롬프트부터 프로덕션(production)에 이르기까지 가장 깨끗한 신뢰 파이프라인(trust pipeline)을 구축한 팀이 될 것입니다.