구조조정 뉴스가 불편한 이유
Atlassian이 전 세계 인력의 10%인 1,600명을 해고했다. 그중 900명 이상이 소프트웨어 R&D 인력이었다. CEO Mike Cannon-Brookes는 이를 "AI 시대를 위한 올바른 결정"이라고 불렀다. 주가는 올랐다.
이 뉴스가 불편한 건 단순히 해고 규모 때문이 아니다. 이제 기업들이 AI를 생산성 도구가 아니라 인력 대체재로 명시적으로 선언하기 시작했다는 점이다. Block(구 Square)이 먼저 이 플레이북을 썼고, Atlassian이 뒤따랐다. 패턴이 굳어지고 있다.
그런데 같은 시기, 반대편에서 벌어진 일
같은 시기 OpenAI 내부 팀은 전혀 다른 실험을 했다. 빈 Git 리포지터리에서 시작해, 3명의 엔지니어가 수동으로 코드를 한 줄도 작성하지 않고 5개월 만에 100만 라인의 코드베이스와 1,500개의 PR을 처리했다. Codex 에이전트가 전부 생성했다. 엔지니어 1인당 하루 평균 3.5개 PR 병합. 팀이 7명으로 늘자 처리량은 오히려 증가했다.
dev.to에 소개된 Atlassian 사례와 GeekNews에 공유된 Harness 엔지니어링 사례를 나란히 놓으면, 표면적으로는 모순처럼 보인다. 한쪽은 "AI가 엔지니어를 대체한다"고 선언하고, 다른 쪽은 "엔지니어 3명이 수백 명 규모의 코드베이스를 운영한다"고 보고한다.
하지만 이 둘은 사실 같은 이야기다.
'대체'가 아니라 '레이어 이동'
내가 이 두 사례에서 읽는 신호는 이렇다. AI는 코딩 레이어에서 일하는 엔지니어를 줄이고 있다. 그리고 동시에 스캐폴딩 레이어에서 일하는 엔지니어를 필요로 하고 있다.
OpenAI 팀의 실험이 보여주는 건 놀라운 생산성만이 아니다. 에이전트가 실패했을 때 팀이 던진 질문이 핵심이다: "더 열심히 해"가 아니라 "어떤 도구와 추상화가 빠져 있는가?" 엔지니어의 일이 코드 작성에서 환경 설계, 의도 명시, 피드백 루프 구축으로 옮겨간 것이다.
Atlassian이 자른 건 코딩 레이어 인력이다. 그들이 앞으로 뽑을 건(혹은 AI로 대체할 수 없어서 남겨둬야 할 건) 스캐폴딩 레이어 인력이다. 이 구분을 못 보면, 뉴스는 그냥 해고 통계로만 읽힌다.
에이전트가 작동하는 조건
OpenAI 팀의 실험에서 가장 인상 깊었던 부분은 아키텍처 강제 적용이다. 그들은 Types → Config → Repo → Service → Runtime → UI 순서로 코드 흐름을 고정했고, 이 제약을 Codex가 생성한 커스텀 린터로 기계적으로 강제했다. 문서화가 부족하면 규칙을 코드로 승격했다.
이 수준의 아키텍처 규율은 보통 수백 명 규모 팀에서나 도입한다. 그런데 에이전트 중심 워크플로우에서는 초기 전제 조건이 된다. 왜냐하면 에이전트는 엄격한 경계와 예측 가능한 구조가 있는 환경에서만 안정적으로 작동하기 때문이다. 구조가 없으면 에이전트는 기존 코드베이스의 나쁜 패턴을 복제하고, 드리프트가 쌓이고, 엔트로피가 증가한다.
이걸 팀 리빌딩 관점으로 번역하면: 에이전트를 잘 쓰는 팀은 사실 아키텍처 설계를 더 잘하는 팀이다.
생산성 역설과 워크플로우 재설계
여기서 ActivTrak의 2026 State of the Workplace 보고서를 함께 봐야 한다. 443백만 시간의 작업 데이터, 16만 명 이상의 직원. 결과: AI 도구 도입 후 이메일 104% 증가, 집중 작업 하루 23분 감소. AI가 오히려 일을 늘린 것이다.
이유는 구조적이다. 기존 워크플로우에 AI를 삽입하면 단계가 줄어드는 게 아니라 검증 단계가 추가된다. AI 출력물마다 새로운 체크포인트가 생기고, 그 검증 비용이 원래 작업보다 비싸진다.
Atlassian의 베팅이 실패할 수 있는 지점이 바로 여기다. 1,600명을 줄이고 AI로 같은 산출물을 내겠다는 전략은, 워크플로우 자체를 에이전트 중심으로 재설계하지 않으면 오히려 남은 인력의 부담만 키운다. Amazon이 3만 명을 줄인 뒤 남은 직원들이 "반쪽짜리 AI 도구" 페티션에 서명한 것처럼.
테크 리드가 지금 해야 할 판단
AI-First 팀 리빌딩을 설계하는 입장에서 이 흐름을 보면, 지금 내려야 할 판단은 명확해진다.
첫째, 팀원의 역할을 코딩 레이어와 스캐폴딩 레이어로 구분해서 재정의해야 한다. 코딩 레이어는 에이전트가 빠르게 잠식한다. 스캐폴딩 레이어—환경 설계, 아키텍처 제약 설계, 피드백 루프 구축, 에이전트 컨텍스트 관리—는 오히려 더 중요해진다.
둘째, AGENTS.md 같은 컨텍스트 관리 설계를 지금 시작해야 한다. OpenAI 팀이 배운 교훈: 거대한 지침 파일은 오히려 에이전트를 망친다. 에이전트에게는 백과사전이 아니라 지도가 필요하다. 이 설계를 할 수 있는 사람이 팀에 있는가?
셋째, 워크플로우 재설계 없는 AI 도입은 Atlassian의 위험을 그대로 복제한다. 도구만 올리고 프로세스를 그대로 두면, 생산성이 오르는 게 아니라 검증 오버헤드가 쌓인다.
전망: 살아남는 엔지니어의 조건
Gartner는 2027년까지 코딩 직무의 40%가 AI로 증강되거나 대체될 것이라고 예측한다. 이 수치를 공포로 읽을 수도 있고, 기회로 읽을 수도 있다.
내가 보는 방향은 이렇다. 에이전트를 설계하는 사람과 에이전트에 대체되는 사람 사이의 간극은, 코딩 실력의 차이가 아니다. 에이전트가 안정적으로 작동할 수 있는 환경을 설계하는 능력, 아키텍처 제약을 기계적으로 강제하는 방법을 아는 능력, 실패를 디버깅이 아니라 시스템 설계 문제로 읽는 시각—이것들이 앞으로의 생존 조건이다.
OpenAI 팀의 실험이 아직 해결 못 한 것도 있다. 완전한 에이전트 생성 시스템에서 아키텍처 일관성이 수년에 걸쳐 어떻게 진화하는지는 미지수다. 모델 기능이 계속 향상되면 지금의 스캐폴딩 설계가 또 바뀔 수 있다.
하지만 한 가지는 확실하다. 소프트웨어 구축에는 여전히 규율이 필요하다. 그 규율이 코드에서 스캐폴딩으로 이동하고 있을 뿐이다. 그 이동을 먼저 이해하고 설계하는 팀이, Atlassian이 쌓아가는 AI 베팅에서 살아남는다.