AI가 코드 65%를 짤 때, 팀이 잘해야 할 나머지 35%

AI가 코드 65%를 짤 때, 팀이 잘해야 할 나머지 35%

Snap의 인력 25% 감축이 드러낸 것은 AI의 위협이 아니라, 팀이 무엇을 소유해야 하는지에 대한 질문이다.

AI 코딩 팀 리빌딩 Snap AI 사례 Eval 파이프라인 Observability Claude Code AI-First 워크플로우 코드 품질
광고

Snap은 2026년 4월, 약 1,000명을 해고하고 300개 미충원 포지션을 닫았다. 전체 계획 인원의 약 25%가 사라진 셈이다. 같은 메모에서 Evan Spiegel은 AI가 신규 코드의 65% 이상을 생성하고 있다고 밝혔다. 주가는 7% 올랐다. 이 숫자 조합을 처음 보면 대부분 엉뚱한 결론으로 달린다. "AI가 개발자를 대체하고 있다"는 쪽으로. 하지만 그건 틀린 독해다.

"65% AI 작성"이 실제로 의미하는 것

키스트로크의 3분의 2가 사라졌다는 뜻이지, 엔지니어링 작업의 3분의 2가 사라졌다는 뜻이 아니다. Claude Code나 Cursor로 실제 작업해본 사람이라면 이 차이를 안다. AI는 CRUD 엔드포인트, 테스트 스캐폴딩, SDK 래퍼, 반복 마이그레이션 같은 "타이핑에 가까운 작업"에서 탁월하다. 문제는 그 다음이다. 어떤 SDK를 선택할지, 해당 마이그레이션이 부하 상황에서 안전한지, AI가 작성한 테스트가 올바른 이유로 통과하는지—이것들은 모델이 스스로 묻지 않는 질문들이다. Snap은 "타이피스트"가 필요한 자리를 줄인 것이다. 그 판단이 가능했던 이유는 AI가 타이핑을 대신하기 때문이다.

남은 35%가 실제로 돈을 버는 영역이다

Snap의 레이오프 메모가 나가는 동안에도 회사는 특정 포지션을 계속 채용했다. 시니어 엔지니어, 시스템 설계자, eval과 observability에 능숙한 인력이다. AI-First 전환 이후 살아남는 역할은 네 가지 작업으로 수렴된다.

첫째, Eval 설계. 유닛 테스트가 아니다. 마지막 200개 프로덕션 프롬프트 위에서 모델이 여전히 의도한 대로 동작하는지 검증하는 행동 평가다. 프롬프트가 바뀔 때마다, 모델이 업그레이드될 때마다 돌려야 한다. 이 eval 리그를 패닉 이후에야 만드는 팀이 너무 많다.

둘째, Observability 구축. 토큰 수, 레이턴시 퍼센타일, 툴 콜 트레이스, 리트리벌 리콜. 화요일 오후 3시에 AI 피처가 degradation을 일으켰다면, 어떤 모델·프롬프트 버전·리트리벌 인덱스·다운스트림 툴인지를 pivot 가능한 span으로 알 수 있어야 한다. 로그만 있는 팀과 span이 있는 팀은 장애 대응 속도가 다르다.

셋째, 멱등성(Idempotency) 설계. 모델은 재시도하고, 에이전트는 재시도하고, 사용자도 재시도한다. AI 핸들러가 중복 호출에 안전하지 않으면, 네트워크 블립 하나가 카드를 두 번 청구하거나 확인 이메일을 두 통 보낸다.

넷째, 코드 오너십 리뷰. 모델이 작성했어도 책임은 사람에게 있다. 리뷰어의 역할은 모델이 스스로 묻지 않은 질문을 묻는 것이다. 인자가 null이면 어떻게 되나, 스케일에서 어떻게 되나, 서드파티 API가 rate limit을 바꾸면 어떻게 되나.

도구 평가의 함정: 2주차 흥분을 믿지 말라

AI 코딩 어시스턴트 평가 프레임워크를 다룬 dev.to의 아티클은 파일럿 설계에서 대부분의 팀이 저지르는 실수를 정확하게 짚는다. 파일럿은 최소 8주가 필요하다. 1~2주차는 피크 흥분 구간이다. 3~6주차에 실제 코드베이스에서 도구의 한계가 드러난다. 7~8주차에야 정상 상태 가치가 보인다. 2주 파일럿은 구조적으로 과대평가를 낳는다.

측정 지표도 잘못 잡는 경우가 많다. suggestion acceptance rate는 허영 지표다. PR이 첫 리뷰에서 통과하는 비율, 배포 후 첫 달 인시던트 발생률, AI 생성 코드의 결함률—이것들이 실제 결정을 내릴 수 있는 지표다. 그리고 통제 그룹이 반드시 필요하다. AI 도구를 자원한 열정적인 팀원들과의 비교는 AI의 효과가 아니라 자원자 효과를 측정하는 것이다.

Cursor + Claude Code + Codex 스택: 언제 세 도구가 필요하고, 언제 극장인가

2026년 4월 한 주 동안 Cursor 3(코드명 Glass)가 병렬 에이전트 창을 출시했고, OpenAI는 Claude Code 내부에서 실행되는 Codex 플러그인을 공개했다. 일부 팀이 세 도구를 동시에 돌리기 시작했다. 이 스택이 실제로 작동하는 경우는 작업의 형태가 다를 때다.

  • 단일 심층 과제, 불명확한 범위, 1시간 이상 소요 → Claude Code
  • 3개 이상의 병렬 소규모 과제, 각각 명확한 범위 → Cursor 3 Agents Window
  • 단일 저복잡도 과제, 비용 최소화 → Codex CLI

세 도구가 극장이 되는 순간은 A 작업 결과에 B 작업이 의존하는데 병렬로 돌릴 때, 하나의 도구로 끝낼 수 있는 작업에 세 컨텍스트를 쌓을 때, 같은 머신에서 두 에이전트가 서로 다른 것을 기억하면서 동시에 과금될 때다. dev.to의 동일 작업 비교 테스트에서 세 도구 스택은 단일 도구 대비 비용이 더 들었고, 벽시계 시간도 더 걸렸으며, 추가 버그를 하나 만들었다.

팀 리빌딩의 실질적 시사점

Snap 메모가 진짜로 말하는 것은 이렇다. 이력서의 마지막 줄이 "React와 Node로 X 피처 구현"이라면, 그건 2022년 불릿이다. 모델이 그 일을 한다. 2026년 불릿은 다르게 읽힌다. "프롬프트 v23에서 9포인트 회귀를 프로덕션 전에 잡아낸 eval 파이프라인 소유

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요