이번 달 내가 얻한 최고의 AI 생산성 성과는 코딩에서 나온 것이 아니었다

최근 나는 매주 월요일 아침에 내리는 나의 "엔지니어링 판단 (engineering judgment)" 중 상당 부분이 사실은 비용이 많이 드는 수동 재구성 작업이었다는 것을 깨달았다.

나쁜 판단은 아니었다. 단지 너무 많은 사무적인 업무 아래 묻혀 있었을 뿐이다.

나는 엔지니어링 인도 (engineering delivery) 과정에서 분위기를 읽는 법을 익히기 위해 수년간 시간을 보냈다.

문제점

팀을 관리해 본 경험이 있다면 아마 그 느낌을 알 것이다. 회고 (retro)를 하기 전부터 스프린트 (sprint)가 흔들리기 시작하는 것을 감지한다. 서류상으로는 팀이 "괜찮아" 보이지만, 그들이 과부하 상태라는 것을 알 수 있다. 하나의 리포지토리 (repo)가 여러 팀의 발목을 잡고 있고 아무도 직접적으로 말하지 않지만, 마찰을 느낄 수 있다.

문제는 이러한 종류의 직관이 영원히 확장될 수는 없다는 점이다.

하나의 팀과 가까이 있을 때는 효과적이다. 하지만 여러 팀, 여러 리포지토리, 여러 주간의 이력, 그리고 매주 월요일 아침마다 재구성할 시간이 없는 수많은 GitHub 이벤트들을 한꺼번에 살펴봐야 할 때는 상황이 엉망이 된다.

그게 바로 내 모습이었다.

매주 월요일마다, 나는 스프린트 상태를 수동으로 다시 구축하고 있었다.

GitHub Issues. PR 이력. 워크플로 (Workflow) 로그. 장애 (Incident) 노트. 누가 과부하 상태인가? 무엇이 누락되었는가? 어떤 PR이 오래되었는가 (stale)? 우리는 실제로 개선되고 있는가, 아니면 이번 주에 그저 우리 자신에게 듣기 좋은 이야기를 해주고 있는 것인가?

그것은 관리 업무처럼 보였다.

대부분 수동 컴파일 (manual compilation)이었다.

그 순간이 내가 AI에 대해 다르게 생각하기 시작한 시점이었다.

"AI가 나를 위해 코드를 더 많이 작성해 줄 수 있을까?"가 아니었다.

그보다는: 왜 나는 엔지니어링 관리 (engineering management)에서 가장 반복적인 부분을 여전히 수동으로 하고 있는가? 에 가까웠다.

그래서 나는 SprintSense를 만들었다.

무엇이 변했나

팀을 운영하는 에이전트 (agent)로서가 아니다. 관리자를 대체한다는 환상도 아니다. 그저 지루한 부분을 먼저 처리하는 시스템으로서 만들었다.

이 시스템은 GitHub Issues, PR, Actions, 그리고 장애 (incident) 데이터를 가져온다. 지표 (metrics)를 결정론적 (deterministically)으로 계산한다. 위험 경고를 표면화한다. 그런 다음 로컬 모델 (local model)이 요약본을 초안 작성한다.

그러면 나는 여전히 중요한 부분을 수행한다:

• 무엇이 실제로 중요한지 결정하기
• 도구가 알지 못하는 맥락 (context) 추가하기
• 어떤 조치를 취할지 선택하기

그 부분이 바로 AI 생산성에 대한 나의 생각을 바꾼 지점입니다.

가장 큰 이득은 코딩을 더 빠르게 하는 것이 아니었습니다.

그것은 월요일 보고 작업에 소요되던 약 4시간을 30분의 검토 및 판단 시간으로 전환한 것이었습니다.

이것은

Human-In-The-Loop (인간 참여형)이 실제로 위치한 곳

저는 주로 AI 제품 관련 강연에서 이 문구를 듣곤 했습니다. 종종 장식적인 표현처럼 느껴지기도 했습니다. 하지만 여기서는 이것이 운영 모델(operating model) 그 자체가 되었습니다.

Human-in-the-loop (인간 참여형)는 세 가지 지점에서 나타났습니다:

• 제가 규칙을 정의합니다: 무엇을 오래된 데이터(stale), 과부하(overloaded), 범위 확장(scope creep)으로 간주할지, 그리고 지표(metrics)의 범위를 어떻게 설정할지 결정합니다.
• 제가 요약을 검토합니다: 모델의 초안은 초안일 뿐, 결정이 아닙니다.
• 제가 결정을 내립니다: 에스컬레이션(escalate), 재조정(rebalance), 논의 또는 무시 여부를 결정합니다.

이것은 안전을 위한 세금(safety tax)이 아닙니다. 그것이 바로 업무입니다.

그리고 만약 당신이 관리 업무(management work)를 하고 있다면, 이것이 올바른 분업이라고 생각합니다.

이 프로젝트가 매우 명확하게 보여준 또 다른 사실은, 신뢰 아키텍처(trust architecture)가 소프트웨어 아키텍처(software architecture)만큼 중요하다는 점입니다.

이것이 직관만으로 하는 것보다 더 잘 확장된 이유

저는 이것이 감시(surveillance)로 변질되는 것을 원하지 않았습니다.

그래서 디렉터(director) 뷰는 집계 데이터(aggregate-only)로만 유지되었습니다. 엔지니어 개별적인 드릴다운(drill-down)은 없었습니다. 시니어 SDM(Senior SDM) 뷰에는 리더보드(leaderboards) 대신 팀 탭과 패턴이 있었습니다. 주니어 엔지니어 뷰는 비교가 아닌 개인의 성장 신호(growth signals)에 집중하도록 유지되었습니다.

백엔드(backend)는 동일합니다. 추상화 수준(abstraction levels)만 다를 뿐입니다. 이것은 단순한 UI 개선이 아닙니다. 그것은 채택 전략(adoption strategy)입니다.

왜냐하면 일단 엔지니어들이 시스템이 자신을 순위 매기기 위해 존재한다고 생각하는 순간, 데이터는 조작(gamed)되기 시작하고 도구는 정치적인 것이 되어버리기 때문입니다.

이 모든 과정을 통해 제가 배운 것은 꽤 단순합니다:

AI는 제가 기존에 가지고 있던 판단력을 더 넓은 영역에 더 쉽게 적용할 수 있도록 도와주었기 때문에 유용했습니다.

AI가 저에게 위험한 스프린트(sprint)가 어떤 모습인지 가르쳐준 것은 아닙니다. 마법처럼 저를 더 나은 관리자로 만들어준 것도 아닙니다. 그저 "신호가 존재하는 상태"와 "내가 그 신호에 따라 행동할 수 있는 상태" 사이의 사무적인(clerical) 작업에 제 시간을 낭비하지 않게 해주었을 뿐입니다.

이것은 현재 우리가 찬양하고 있는 많은 사례보다 훨씬 더 성숙한 AI 활용 방식처럼 느껴집니다.

우리는 여전히 AI의 코드 출력(code output) 능력에는 과도한 신뢰를 부여하고, 의사 결정 지원(decision support) 능력에는 과소평가하고 있다고 생각합니다. 화려한 데모는 "모델이 기능을 작성했다"는 것입니다. 하지만 유용한 현실은 종종 "시스템이 재구성 작업에 드는 3시간을 아껴주었고, 내가 실제로 직접 해야만 하는 유일한 부분에 집중할 수 있도록 도와주었다"는 것입니다.

AI가 경험을 대체하는 것이 아닙니다.

AI가 경험의 확장(scale)을 돕는 것입니다.

토론 (Discussion)

다른 분들은 이를 어떻게 보고 계시는지 궁금합니다.

만약 엔지니어링 워크플로우 (engineering workflows)에서 AI를 사용하고 있다면, 현재 실제로 가장 큰 레버리지 (leverage)를 얻고 있는 부분은 어디인가요?

여전히 주로 코딩 (coding)인가요?

아니면 계획 (planning), 보고 (reporting), 리뷰 (review), 측정 (measurement), 그리고 코드 주변의 나머지 소프트웨어 개발 생명주기 (SDLC) 단계에서 더 큰 성과를 발견하기 시작하셨나요?