오늘은 AI 시대에 개발 생산성을 어떻게 다시 봐야 하는지, 그리고 Microsoft가 실제로 쓰고 있는 EngThrive 프레임워크를 사례 중심으로 이야기해 보겠습니다. 저는 CoreAI의 Tim Bozarth입니다.
AI의 가치 제안
AI가 우리에게 주는 가치는 두 가지입니다. 하나는 우리 제품을 더 좋게 만드는 것이고, 다른 하나는 우리 자신, 즉 엔지니어링 조직을 더 강하게 만드는 것이죠. 오늘 초점은 바로 후자입니다.
오늘의 흐름
크게 세 부분으로 진행하겠습니다. 먼저 AI 시대의 생산성이 무엇인지, 다음으로 EngThrive 원칙, 그리고 마지막으로 실제 적용 사례를 보고 함께 이야기 나눠 보겠습니다.
먼저 근본적인 질문부터 짚어 보겠습니다. AI 시대에 '생산성이 높다'는 건 대체 무슨 뜻일까요?
코드를 얼마나 더 썼나?
모든 경영진이 한 번쯤 던지는 질문이 있죠. "AI로 우리 엔지니어들이 코드를 얼마나 더 많이 썼나?" 그런데 솔직히 이 질문의 답은 '글쎄요'입니다. 애초에 잘못된 질문이기 때문입니다.
시간은 어디에 쓰이나
엔지니어의 하루를 뜯어보면 실제로 코드를 짜는 시간은 일부일 뿐입니다. 설계, 검증, 운영, 소통에 훨씬 더 많은 시간이 들어가죠. 그래서 코드량만으로는 생산성을 말할 수 없습니다.
더 빠르게, 더 많은 가치
우리가 진짜로 원하는 건 코드를 더 많이 찍어내는 게 아니라, 더 많은 가치를 더 빠르게 만들어 내는 것입니다. 목표를 여기에 두면 측정 방식도 달라져야 합니다.
개발 루프의 변화
개발이 돌아가는 방식, 그 루프 자체가 바뀌고 있습니다. 우리가 코드를 다루는 방법이 근본부터 달라지고 있는 거죠.
세 번의 물결
변화는 세 물결로 옵니다. 처음엔 LLM에게 질문을 던졌고, 다음엔 에이전트에게 일을 맡겼죠. 그리고 지금 떠오르는 세 번째 물결은, 여러 에이전트로 이루어진 팀을 목표를 향해 지휘하는 단계입니다.
클래식 SDLC
기존의 소프트웨어 개발 수명주기, 이른바 클래식 SDLC를 떠올려 보겠습니다. 요구사항부터 배포까지 사람이 각 단계를 직접 밟아 나가는 방식이었죠.
클래식 SDLC, 다시 보기
이 흐름을 조금 더 들여다보면 각 단계마다 사람의 손이 촘촘하게 들어가 있습니다. 바로 여기가 AI가 개입하면서 크게 달라지는 지점입니다.
AI-Max SDLC
그래서 등장하는 게 AI를 최대한 끌어올린 AI-Max SDLC입니다. 반복적이고 정형화된 일은 AI가 맡고, 사람은 더 높은 판단에 집중하는 구조로 바뀝니다.
코드는 결과물, 입력이 아니다
여기서 관점을 완전히 뒤집어야 합니다. 이제 코드는 우리가 애써 넣는 입력이 아니라, 의도로부터 만들어지는 결과물에 가깝습니다. 이게 지평선 너머로 다가오는 변화입니다.
모델 역량은 균일하지 않다
다만 모델 능력이 모든 영역에서 똑같이 좋아지는 건 아닙니다. 코딩은 무섭게 발전하지만 시스템 설계나 검증, 운영, 그리고 이른바 '감각'은 개선이 더디죠. 그래서 사람의 역할이 그쪽으로 옮겨갑니다.
최고 팀의 모습도 바뀐다
결국 가장 높은 성과를 내는 팀의 모습 자체가 달라지고 있습니다. 손이 빠른 팀이 아니라, AI를 잘 지휘해 성과를 뽑아내는 팀이 앞서가게 되는 거죠.
바뀐 것과 바뀌지 않은 것
AI는 우리가 일하는 방식의 거의 모든 걸 바꿔 놓았습니다. 하지만 생산성을 어떻게 측정하느냐, 그 기준까지 바꾸지는 못합니다. 성과의 본질은 그대로입니다.
이제 우리가 이 문제를 어떻게 풀어가는지, EngThrive의 원칙들을 살펴보겠습니다.
훌륭한 일을 쉽고 빠르게
핵심 철학은 단순합니다. 훌륭한 일을 빠르고 쉽게 할 수 있게 만들자는 겁니다. 우리가 어떻게 일하는가, 그리고 무엇을 만들어 내는가, 이 두 축 모두에서요.
임팩트를 이해하는 세 축
그 임팩트를 이해하기 위해 세 가지를 봅니다. 얼마나 빠른가(Speed), 얼마나 수월한가(Ease), 그리고 결과물의 품질(Quality)이 어떤가입니다.
활동 vs 성과
여기서 가장 중요한 구분이 나옵니다. 바로 활동(Activity)과 성과(Outcome)를 헷갈리면 안 된다는 것입니다.
활동·산출·성과
지표는 세 층으로 나눠 볼 수 있습니다. AI 사용량이나 토큰 사용 같은 '어떻게 일했나(활동)', PR 수 같은 '무엇을 했나(산출)', 그리고 아이디어가 고객에게 닿는 시간 같은 '무엇을 이뤘나(성과)'입니다. 우리가 봐야 할 건 맨 마지막이죠.
토큰 맥싱의 함정
활동에만 매달리면 이른바 '토큰 맥싱(Token Maxing)'이 벌어집니다. 숫자는 화려하게 올라가는데 정작 만들어진 가치는 없는, 딱 피해야 할 상황이죠.
시스템을 측정하라
그리고 개인을 줄 세워 측정하는 게 아니라 시스템을 측정해야 합니다. 병목은 대부분 개인이 아니라 우리가 만든 프로세스에 있으니까요.
임팩트를 푸는 질문들
세 축을 실제 질문으로 바꿔 보면 이렇습니다. 아이디어가 고객 손에 닿기까지 몇 시간이 걸리나, 진짜 가치를 만드는 데 시간을 얼마나 쓰나, 그리고 결함과 회복력, 경험 같은 품질은 어떤가입니다.
핵심 EngThrive 지표
그래서 우리의 핵심 지표는 이렇게 정리됩니다. Speed는 Idea-to-Customer와 Time-To-Nth-PR, Ease는 Innovation Time과 Bad Developer Days, Quality는 PRs-Per-Incident와 사고 완화 시간, 그리고 전반적인 만족도인 NSAT까지 함께 봅니다.
지표가 있다, 그다음은?
자, 이제 지표는 갖췄습니다. 그런데 지표만 있다고 달라지진 않죠. 진짜 질문은 '그다음에 무엇을 하느냐'입니다.
운영 원칙
운영에는 세 가지 원칙이 있습니다. 병목을 찾아 이해하고 실제로 해결할 것, 개발자 경험에 대해 리더가 책임을 질 것, 그리고 점수표로 줄 세우지 말고 지속적인 개선을 함께 축하할 것입니다.
EngThrive 프로그램의 북극성
프로그램의 북극성은 명확합니다. 회사 전체에 일관된 개발자 경험 지표를 두고, 누구나 볼 수 있는 대시보드로 데이터를 열어 주고, 변화를 이끄는 업무 프로세스를 만들어 개선의 실마리를 계속 얻는 것입니다.
지금 시작하는 게 정답
성숙도를 끝까지 끌어올리는 건 분명 어려운 최적화 과제입니다. 하지만 초반에 얻을 수 있는 성과 구간이 분명히 있고, 무엇보다 시작하기에 지금보다 좋은 때는 없습니다.
이제 이론에서 현장으로 넘어가 보겠습니다. 데이터에서 인사이트로, 다시 행동으로, 그리고 임팩트로 이어지는 실제 사례들입니다.
CoreAI 집중 시간 이니셔티브
첫 번째 사례는 CoreAI에서 진행한 Focus Time, 집중 시간 이니셔티브입니다.
왜 집중 시간인가
개발자는 몰입 상태로 들어가려면 방해받지 않는 집중 시간이 필요합니다. 집중 시간이 늘면 생산성도, 만족도인 NSAT도 함께 올라가죠. 그래서 목표를 잡았습니다. 한 주의 대부분을 두 시간 이상 보호된 딥워크 블록으로 확보하자는 것이었습니다.
플라이휠 돌리기
플라이휠은 이렇게 돌리기 시작했습니다. 먼저 공유할 지표 하나를 정하고, 책임 소재가 분명한 역할을 나누고, 격주로 리뷰와 회고를 돌리고, 모든 대화를 EngThrive 데이터 위에서 나눴습니다.
집중 시간, 실제로 한 일
구체적으로는 회의를 예측 가능한 시간대로 묶어 큰 블록을 만들고, 아젠다 없는 회의를 없애 회의 위생을 개선했습니다. 또 'AM 싱크 / PM 씽크' 같은 규칙으로 딥워크 시간을 보호하고, 대시보드로 집중 시간이 낮은 팀을 찾아 코칭하며, 온콜 패턴 같은 구조적 원인까지 손댔습니다.
집중 시간, 얻어낸 성과
결과는 뚜렷했습니다. 개발자 한 명당 주 2.1시간의 집중 시간이 늘어 총 5만 5천 딥워크 시간을 확보했고, PR 속도는 13% 올라 개발자 약 350명분의 역량에 해당했습니다. Bad Developer Days는 25% 줄었고, 상태 보고 회의와 멀티태스킹도 함께 감소했죠.
왜 이 사례인가
이 사례를 고른 이유가 있습니다. 거창한 도구가 아니라, 데이터를 근거로 일하는 방식을 바꿨더니 실제 성과로 이어졌다는 걸 보여주기 때문입니다.
첫 PR까지의 시간
두 번째 사례는 Time to First Pull Request, 신규 입사자가 첫 PR을 올리기까지의 시간입니다.
무엇을, 왜 보나
이 지표는 새 엔지니어가 입사해서 첫 풀 리퀘스트를 완료하기까지 걸린 시간을 말합니다. 왜 중요하냐면, 더 빨리 코딩을 시작한 엔지니어일수록 장기적으로 더 좋은 성과를 내기 때문입니다.
첫 PR, 우리가 한 일
그래서 첫 주 온보딩 체크리스트에 AI 기반 'First Pull Request' 활동을 넣었습니다. PR 워크플로 문서를 개선하고, PR 완료 실습 영상을 만들고, 첫 PR 경험이 왜 중요한지 관리자 교육까지 함께 진행했습니다.
지표를 조작할 수 있지 않나?
여기서 당연히 이런 반론이 나옵니다. "그 지표, 그냥 아무 의미 없는 커밋 하나 올리면 게임할 수 있는 거 아니냐?" 아주 좋은 질문이죠. 데이터를 보면 답이 나옵니다.
데이터로 확인
실제 통계를 보면 그런 편법은 유의미한 영향을 주지 못합니다. 첫 PR을 빨리 낸 사람들은 이후에도 꾸준히 실질적인 기여로 이어졌거든요.
N번째 PR까지의 시간
그래서 한 걸음 더 나아가 Time to Nth PR도 봅니다. 놀랍게도 개발자가 10번째 PR에 이를 즈음이면, 그 사람이 앞으로 2년 뒤 어떤 엔지니어가 될지를 상당히 예측할 수 있습니다.
왜 이 사례인가
이 사례가 말해 주는 건, 겉보기엔 조작 가능해 보이는 지표라도 제대로 설계하고 데이터로 검증하면 진짜 신호를 준다는 것입니다.
핵심 정리
오늘의 핵심은 세 가지입니다. 활동이 아니라 성과를 보라, 개선을 이끌고 책임을 만드는 운영 리듬(RoB)을 세워라, 그리고 AI를 활용해 오래된 병목을 돌파하라는 것입니다.
더 알아보기
세션 상세 페이지에는 튜토리얼과 자료, 코드가 준비되어 있으니 꼭 활용해 보세요. 그리고 aka.ms/build/evals에 방문하거나 QR 코드를 스캔해서 설문에 참여해 주시면 큰 도움이 됩니다.
감사합니다
들어주셔서 감사합니다.