AI가 코드의 60%를 쓴다면, 개발자와 매니저는 무엇을 해야 하나

AI 활용은 소프트웨어 개발에만 머무르지 않는다. 더 모틀리 풀이 공개한 2025년 4분기 실적 발표 녹취록에 따르면 에어비앤비의 자체 AI 지원 에이전트는 북미에서 고객 지원 이슈의 3분의 1을 해결했고, 문의 티켓의 거의 30%를 처리했다. 회사는 이를 전 세계와 음성 채널로 확대할 계획도 언급했다 . 같은 녹취록은 게스트의 여행 계획을 돕고 회사가 더 효율적으로 운영되도록 하는 더 넓은 ‘AI 네이티브’ 경험도 설명했다 .

개발자의 일은 사라지기보다 위로 올라간다

AI가 구현 코드의 상당 부분을 초안으로 만들 수 있다면, 개발자의 역할은 단순히 줄어드는 것이 아니라 성격이 바뀐다. 손으로 모든 줄을 입력하는 능력보다 좋은 소프트웨어가 만들어질 조건을 설계하는 능력이 중요해진다.

앞으로 더 중요해지는 역량은 다음에 가깝다.

• 문제 정의력. AI 도구는 목표, 제약 조건, 기대 동작, 필요한 맥락이 명확할수록 더 유용하다.
• 시스템 맥락 제공. 생성된 코드는 기존 코드베이스, 데이터 가정, 소유권 경계, 제품 요구사항 안에 맞아야 한다.
• 출력 검토 능력. 엔지니어는 여전히 코드를 읽고, 트레이드오프를 이해하고, 배포해도 안전한지 판단해야 한다.
• 엣지 케이스 테스트. 초안이 빨리 나와도 엄격한 테스트, 디버깅, 장애 상황에 대한 사고는 사라지지 않는다.
• 아키텍처 보호. 생성 코드가 늘수록 유지보수해야 할 코드도 늘 수 있다. 경계, 의존성, 장기적 단순성이 더 중요해진다.
• 운영 결과 책임. 안정성, 유지보수성, 사용자 영향에 대한 최종 책임은 여전히 사람과 팀에 남는다.

결국 ‘코드를 얼마나 많이 쳤는가’는 예전보다 약한 가치 지표가 된다. 더 중요한 것은 AI에게 무엇을 맡길지, 어떤 초안은 버릴지, 어디를 리팩터링할지, 애초에 만들지 말아야 할 것은 무엇인지 판단하는 능력이다.

리뷰와 판단이 더 비싼 기술이 된다

AI 보조 코딩은 첫 초안의 비용을 낮춘다. 그러면 역설적으로 좋은 초안과 위험한 초안을 구분하는 사람의 가치가 올라간다.

강한 엔지니어는 단순히 프롬프트를 넣고 결과를 받아들이는 사람이 아니다. 좋은 편집자이자 시스템 설계자이며 운영자에 가까워진다. 제품 의도와 구현이 맞는지, 숨은 가정을 깨뜨리지 않는지, 기존 아키텍처에 맞는지, 다른 팀이 나중에 유지보수할 수 있는지까지 확인해야 한다.

그래서 AI는 시니어 엔지니어의 판단을 덜 중요하게 만드는 것이 아니라 오히려 더 중요하게 만들 수 있다. 팀이 코드를 더 빨리 생산할 수 있다면, 병목은 ‘코드를 쓰는 속도’에서 ‘어떤 코드가 존재할 가치가 있는가를 결정하는 능력’으로 옮겨간다.

매니저도 기술에서 멀어지기 어렵다

체스키의 매니저 관련 발언은 60%라는 숫자만큼 의미가 크다. 에어비앤비에서는 매니저가 코딩하거나 AI 코딩 도구를 사용할 만큼 업무에 가까이 있어야 한다는 기대가 보고됐다 . People Matters가 전한 ‘순수 피플 매니저’ 경고도 같은 방향을 가리킨다 .

이 말이 모든 엔지니어링 매니저가 팀에서 가장 뛰어난 개인 기여자가 되어야 한다는 뜻은 아니다. 다만 기술적 문해력을 피하기는 훨씬 어려워졌다는 의미다.

AI 활용도가 높은 팀의 매니저는 적어도 다음을 할 수 있어야 한다.

• AI 도구가 잘하는 일과 못하는 일을 이해한다.
• 진행 상황만 묻는 대신 기술적 트레이드오프를 평가한다.
• 일정 추정, 설계, 생성 코드에 숨어 있는 약한 가정을 짚어낸다.
• 코드 리뷰, 테스트, 보안, 안정성에 대한 품질 기준을 명확히 세운다.
• 손으로 입력한 코드량이 아니라 출시된 가치와 시스템 건강도를 기준으로 팀을 평가한다.

물론 매니저의 역할에는 여전히 채용, 코칭, 우선순위 조정, 팀 건강 관리가 포함된다. 다만 에어비앤비가 보여주는 방향에서는 이런 책임이 기술과 도구에 대한 실질적 이해와 함께 놓인다.

압박받는 역할은 ‘개발자’가 아니라 ‘루틴 산출물 담당자’다

위험한 것은 소프트웨어 엔지니어라는 직함이나 매니저라는 직함 자체가 아니다. 위험한 것은 역할이 반복적 산출물에만 너무 좁게 묶여 있는 경우다.

특히 압박을 받기 쉬운 사람은 다음과 같다.

• 시스템 전체를 이해하지 못한 채 코드만 작성하는 사람
• AI가 만든 결과물을 충분히 검토하지 않고 받아들이는 사람
• 제품 가치보다 처리한 작업량으로만 기여를 설명하는 사람
• 기술적 실체를 이해하지 못한 채 조율만 하는 관리자
• 팀의 일상 도구가 되어가는 AI를 배우지 않으려는 사람

반대로 더 안전한 프로필은 판단력 있는 기술 운영자다. AI로 속도를 높이되 품질, 아키텍처, 결과에 대한 책임을 놓지 않는 사람이다.

지금 개발자와 매니저가 할 일

개발자에게 필요한 태도는 AI를 외면하는 것도, AI를 맹신하는 것도 아니다. AI 보조 개발을 능숙하게 하되 결과에 대한 책임은 사람이 가져가야 한다. 더 명확한 명세를 쓰고, 더 좋은 맥락을 제공하고, 변경 사항을 꼼꼼히 리뷰하고, 테스트 범위를 넓히고, 아키텍처·신뢰성·보안·제품 감각에 투자해야 한다.

매니저에게 필요한 실천은 현장에서 너무 멀어지지 않는 것이다. 도구를 직접 써봐야 장점과 한계를 이해할 수 있다. 설계와 리뷰 논의에 참여하고, 품질 기준을 명시하며, 팀을 ‘얼마나 많은 코드를 손으로 썼는가’가 아니라 ‘얼마나 지속 가능한 제품 결과를 냈는가’로 평가해야 한다.

단, 에어비앤비는 신호이지 시장 전체는 아니다

에어비앤비의 ‘거의 60%’ 수치는 에어비앤비라는 한 회사의 데이터 포인트다. 모든 소프트웨어 조직이 같은 단계에 도달했다는 업계 평균으로 읽어서는 안 된다.

체스키의 더 넓은 관점에도 속도와 인내가 함께 있다. 그는 2024년에 AI가 많은 사람이 생각하는 것보다 훨씬 더 세계를 바꿀 것이라고 말하면서도, 그 변화가 실현되기까지는 많은 사람이 예상하는 것보다 더 오래 걸릴 것이라고 했다 . 이 프레임이 지금의 변화에 적절하다. AI는 소프트웨어 일을 깊게 바꿀 수 있지만, 전환은 회사마다 고르지 않게 진행될 것이다.

결론은 간단하다. AI가 개발자와 매니저를 곧바로 대체한다기보다, 이들의 기여 단위를 바꾸고 있다. 개발자는 기계가 만든 코드를 지휘하고 검증하는 사람으로, 매니저는 AI를 매일 쓰는 팀을 이끌 수 있을 만큼 기술적으로 유창한 리더로 진화해야 한다. 에어비앤비 사례에서 보이는 지속 가능한 우위는 수작업 생산량이 아니라 판단, 책임, 그리고 AI 출력물을 신뢰할 수 있는 제품으로 바꾸는 능력이다 .