엔지니어링 매니저는 AI 논의에서 가장 많은 정보를 가진 사람이다

엔지니어링 매니저(Engineering Manager, EM)들은 AI 전환(AI transformation) 담론에서 거의 완전히 배제되어 있습니다. 여기에는 구조적인 이유가 있으며, 이를 이해하는 것이 문제를 해결하기 위한 첫 번째 단계입니다.

엔지니어들은 인터넷에 글을 씁니다. 경영진(C-suite)의 결정은 헤드라인을 장식합니다. 엔지니어링 매니저는 위로부터의 압박과 아래로부터의 복잡성을 흡수하며, 양방향 모두에서 공을 인정받는 결과물을 만들어냅니다. 시스템은 EM의 목소리를 공개적으로 보상하지 않습니다. 하지만 EM의 위치는 경영진도, 엔지니어링 엔지니어도 갖지 못한 것을 제공합니다. 바로 현재 AI가 팀에 실제로 어떤 영향을 미치고 있는지에 대한 가장 완전한 관점입니다.

이것은 위로를 위한 보상이 아닙니다. 당신이 이를 의도적으로 사용하기로 결정한다면, 그것은 진정한 강점이 됩니다.

당신은 아무도 보지 못하는 것을 봅니다

글을 쓰는 사람들은 독자가 있는 곳이나 권위가 있는 곳으로 향합니다. EM은 둘 다 아니며, 이것이 바로 플레이북(playbooks)들이 EM을 계속 놓치는 이유입니다. 경영진은 마찰 없는 구현을 전제로 하는 조언을 받습니다. 엔지니어들은 조직의 안정성을 전제로 하는 조언을 받습니다. 팀 수준에서는 그 어느 것도 성립하지 않습니다.

EM은 이 두 가지가 모두 무너지는 정확한 교차점에 앉아 있습니다.

그 위치는 불편합니다. 또한 유난히 많은 정보를 제공합니다. 당신은 다음을 갖추고 있습니다:

리더십이 무엇을 달성하려 하는지 이해할 수 있는 조직적 맥락 (Organizational context)
코드베이스에서 실제로 무슨 일이 일어나고 있는지 이해할 수 있는 기술적 신뢰도 (Technical credibility)
엔지니어들이 매일 무엇을 경험하고 있는지 알 수 있는 사람과의 근접성 (People proximity)

조직 내의 그 누구도 이 세 가지를 동시에 갖지 못합니다.

문제는 그 관점이 가치 있는가 하는 점이 아닙니다. 가치가 있습니다. 문제는 당신이 그 관점을 능동적으로 사용하고 있는지, 아니면 그저 조용히 흡수만 하고 있는지입니다.

숫자는 당신이 다룰 수 있는 무언가를 제공합니다

기술 분야 고용주의 49%는 2029년까지 인력을 줄이기 위해 AI를 사용할 것으로 예상합니다 1. 개발자의 87%는 AI를 자신의 고용에 대한 즉각적인 위협으로 간주하지 않습니다 1.

리더십과 팀은 서로 다른 현실 속에서 움직이고 있습니다. 그 격차는 당신에게 떨어집니다. 하지만 이는 또한 당신이 해결할 수 있는 구체적이고 다룰 수 있는 문제, 즉 _번역 (translation)_을 제공합니다.

리더십의 관점이 틀린 것은 아니지만, 불완전합니다. AI 툴링 (AI tooling)은 측정 가능한 개별 결과물을 만들어내며, 이에 따라 행동해야 한다는 압박 또한 실재합니다. 하지만 수치에서 누락된 사실은, AI 투자로부터 유의미한 생산성 향상을 보고한 개발자는 3분의 1에 불과하다는 점입니다 2. 실제 병목 현상들 — 지식의 파편화 (knowledge fragmentation), 레거시 시스템 (legacy systems), 문서화되지 않은 아키텍처 (undocumented architecture), 그리고 모든 성숙한 코드베이스에 존재하는 특유의 기술 부채 (technical debt) — 는 코드 생성 (code generation)만으로는 해결되지 않습니다. 연구에 따르면 AI 도입이 25% 증가할 때, 전달 처리량 (delivery throughput)은 1.5% 감소하고 시스템 안정성 (system stability)은 7.2% 감소하는 것으로 나타났습니다 3. 이는 주로 더 빠른 생성 속도가 더 크고, 리뷰하기 어렵고, 다운스트림 (downstream)에서 문제를 일으킬 가능성이 높은 풀 리퀘스트 (pull requests)를 만들어내기 때문입니다.

여러분은 아마 팀의 경험을 통해 이미 이 사실을 알고 있었을 것입니다. 이제 여러분은 이를 당당하게 말할 수 있는 데이터를 갖게 되었습니다.

리더십과의 대화에 참여하여 _"왜 AI 도입이 더 빠르지 않은가"_라는 질문을 _"우리 특정 코드베이스에서 생산성이란 실제로 무엇을 의미하는지, 그리고 AI가 진정으로 도움이 되는 부분은 어디이며 비용을 줄이지 못한 채 전가하기만 하는 부분은 어디인지"_로 재구성할 수 있는 엔지니어링 매니저 (EM)는 매우 가치 있는 일을 하고 있는 것입니다. 그러한 대화는 무엇에 자원이 배정될지, 무엇을 측정할지, 그리고 무엇을 기대할지를 변화시킵니다. 이는 AI 도입 명령에 맞서 싸우라는 뜻이 아닙니다. 그 명령에 대해 구체적이어지라는 뜻입니다.

어휘 선택이 중요합니다. AI 보조 개발 (AI-assisted development)에 관한 Martin Fowler의 연구는 우리가 반드시 가져와야 할 지표의 변화를 시사합니다. 리더십이 추적하는 경향이 있는 첫 번째 결과물까지의 시간 (time to first output) 대신, 초도 통과 승인율 (first-pass acceptance rate), 태스크당 반복 주기 (iteration cycles per task), 그리고 _병합 후 재작업 (post-merge rework)_을 측정하십시오. 이 수치들은 AI가 실제로 성과를 내고 있는 곳이 어디인지, 그리고 단순히 비용을 다운스트림으로 밀어내고 있는 곳이 어디인지에 대해 완전히 다른 이야기를 들려줍니다. 또한 이 수치들은 여러분 팀의 데이터를 통해 산출할 수 있는 것들입니다. 이것이 추상적인 주장과 구체적인 주장의 차이입니다.

보이지 않는 추적을 가시화하라

Harness의 'Software Delivery 2025' 보고서는 구조적인 패턴이 하나 자리 잡았음을 기록하고 있습니다 4. AI를 사용하여 기능을 빠르게 출시하는 개발자들은 비기술직 리더십(non-technical leadership)의 눈에 띄게 됩니다. 취약한 코드(fragile code)를 생성하는 것과 동일한 프롬프팅 루프(prompting loop)가, 그 코드로 인해 발생한 장애에 대한 빠른 핫픽스(hotfix)를 생성할 수도 있습니다. 멀리서 보면, 이것은 마치 대응력이 뛰어난 것처럼 보입니다.

향후 발생할 5건의 장애를 방지하기 위해 3주를 보낸 엔지니어는 보여줄 수 있는 결과물이 아무것도 없습니다.

이것은 새로운 문제가 아닙니다. 엔지니어링 조직은 무언가가 망가지는 것을 조용히 막고 있는 사람을 식별하는 데 항상 어려움을 겪어왔습니다. AI는 가시적인 궤적(visible track)을 더 빠르고 저렴하게 만들었으며, 이는 그 격차를 더욱 벌려 놓았습니다. 하지만 엔지니어링 매니저(EM)는 조직 내에서 이 두 가지 궤적을 동시에 볼 수 있는 유일한 사람입니다. 바로 그 지점이 개입이 필요한 지점입니다.

실질적인 조치: 예방 작업을 명시적으로 서술하십시오. _"이번 분기에 우리는 이러한 작업 덕분에 이 5건의 장애를 겪지 않았습니다"_라는 문장은 대부분의 엔지니어링 조직 어디에도 존재하지 않는 문장입니다. 이 문장은 당신의 것이 되어야 합니다. 이는 리더십이 무엇을 보는지, 무엇이 보상받는지, 그리고 시간이 흐름에 따라 무엇이 우선순위가 되는지를 변화시킵니다. 작업이 보이지 않는 이유는 아무도 신경 쓰지 않아서가 아닙니다. 리더십이 이해할 수 있는 관점에서 아무도 그 작업을 설명하지 않기 때문입니다. 당신은 그것을 바꿀 수 있습니다.

정체성 변화를 겪는 엔지니어들을 도와라

2025년 PNAS 연구에 따르면: 동일한 결과물에 대해 AI를 사용하는 개발자는 역량 평가(competence ratings)에서 9% 더 낮은 점수를 받았으며, 여성의 경우 그 불이익이 더 심했습니다 5.

이러한 낙인(stigma)은 설문 조사에 나타나기 전부터 행동을 형성합니다. 엔지니어들은 개인적으로 도구를 사용하고, 리뷰에서 이를 언급하지 않으며, 1:1 미팅에서도 문제를 제기하지 않습니다. GitHub 개발자들을 대상으로 한 종단적 연구(longitudinal study)에 따르면, AI 도입이 동료 간의 협업을 거의 80% 감소시켰는데 6, 이는 사람들이 관심을 끊었기 때문이 아니라 낙인이 업무 방식(how work gets done)을 조용히 재구조화했기 때문입니다.

실질적인 결과는 다음과 같습니다: 지식이 예전과 같은 방식으로 흐르지 않게 됩니다. 시니어 엔지니어에게 AI와 단독으로 작업하는 것은 집중하는 것처럼 느껴질 수 있습니다. 하지만 주니어 개발자에게 이는 비공식적인 학습 채널(informal learning channel)의 소멸을 의미합니다. 즉, 업무 흐름 속에서 오가는 질문들, 실제로 무언가를 가르쳐주었던 리뷰 코멘트들, 그리고 누군가 공식적으로 가르치지 않아도 판단력(judgment)이 길러지던 근접성(proximity)이 사라지는 것입니다. 이러한 인프라는 의도적으로 재구축하지 않는 한 존재하지 않습니다.

당신은 주니어가 성장을 멈추는 순간을 가장 먼저 알아차릴 수 있는 위치에 있는 사람입니다. 해결책은 도구 사용을 제한하는 것이 아닙니다. 근접성에 의존하지 않는 명시적인 순간들을 만드는 것입니다. AI를 의도적으로 끄고 진행하는 구조화된 페어 세션(pair sessions), 아키텍처 워크스루(architecture walkthroughs), 그리고 단순히 결과물이 아닌 로직에 대해 토론하는 코드 리뷰(code reviews) 등이 그 예입니다. 목표는 AI를 덜 사용하는 것이 아닙니다. AI를 유용하게 만드는 기술들이, 그 기술을 개발해야 할 사람들에게서 퇴화하지 않도록 보장하는 것입니다.

팀 내에서 AI 사용에 대해 논의할 수 있는 환경을 만드세요. 사람들이 실제로 AI를 어떻게 사용하는지, 무엇이 효과적이고 무엇이 그렇지 않은지 공유하는 세션을 운영하십시오. 대화가 정상화되면 낙인(stigma)은 사라집니다. 그리고 대화가 정상화될 때, 무언가 잘못되고 있다는 신호(signal)를 놓치는 일을 멈출 수 있습니다.

다른 사람이 하기 전에 미결제 질문들을 선점하십시오

담론(discourse)은 엔지니어링 매니저(EM)를 안정적인 맥락으로 취급합니다. 하지만 우리는 그렇지 않습니다.

상당 부분 사람이 작성하지 않은 PR(Pull Request)을 어떻게 평가해야 할까요? 생산성 기준선(productivity baseline)이 계속 변할 때 기대치를 어떻게 조정해야 할까요? 행사되는 판단력이 주로 에이전트(agent)를 지시하고 검증하는 것에 관한 것이라면, 엔지니어링 판단력(engineering judgment)을 평가한다는 것은 무엇을 의미할까요? 후보자가 적절한 프롬프트(prompt)를 통해 실시간으로 어떤 알고리즘이든 풀 수 있다면, 기술적 역량(technical competence)을 확인하기 위해 어떻게 인터뷰를 진행해야 할까요?

이러한 질문들에 대해 업계의 합의는 아직 이루어지지 않았습니다. 하지만 이 질문들에 대한 답은 지금 이 순간, 모든 팀에서 1:1 미팅과 성과 주기(performance cycles)를 운영하는 사람들에 의해 만들어지고 있습니다. 당신이 능동적으로 결정하지 않는다면, 당신은 다른 누군가의 답변을 따르거나, 혹은 아무런 답변도 얻지 못한 채 기본값(default)에 머물게 될 것입니다.

이것은 사실 좋은 소식입니다. 불확실성은 하나의 기회(window)입니다. 이 전환기를 잘 헤쳐 나가는 팀은 프레임워크(framework)를 기다렸던 팀이 아닐 것입니다. 그들은 엔지니어링 매니저(EM)가 일찍 답을 내리고, 이를 명시적으로 만들며, 학습하면서 지속적으로 개선해 나간 팀이 될 것입니다.

목록에 예산 문제도 추가하십시오. 거버넌스(governance)가 없는 에이전틱 워크플로우(agentic workflows) 환경에서 개별 개발자의 AI 사용량은 월 수천 달러까지 급증할 수 있습니다. 결과물보다는 가시성에 의해 유도되는 고용량 소비인 _토큰맥싱(Tokenmaxxing)_은 Meta가 공개 리더보드를 구축하고, 최다 지출자에게 "세션 이모탈(Session Immortal)" 타이틀을 부여했다가, 이것이 운영 장애(production incidents)의 원인이 된 후 시스템을 폐지할 정도로 널리 퍼졌습니다. 지금 당장 구축하는 간단한 정책 — 승인된 도구, 토큰 기대치, AI 생성 코드에 대한 리뷰 표준 — 은 정책이 없는 것보다 무한히 낫습니다. 완벽한 프레임워크가 필요한 것이 아닙니다. 당신의 팀이 근거를 가지고 논의할 수 있는 시작점이 필요할 뿐입니다.

언급할 가치가 있는 더 깊은 거버넌스 계층이 있습니다. Fowler는 AI 어시스턴트를 _"무한한 에너지를 가졌지만 컨텍스트(context)는 전혀 없는 주니어 개발자"_라고 묘사합니다. 대부분의 팀이 겪는 좌절의 루프 — 코드를 생성하고, 리뷰하고, 코드베이스와 맞지 않는 것을 발견하고, 수정을 거쳐 다시 생성하고, 이를 반복하는 과정 — 는 AI가 팀의 표준 대신 일반적인 인터넷 패턴을 기본값(default)으로 사용하기 때문에 발생합니다. 해결책은 더 나은 프롬프트(prompt)가 아닙니다. 팀의 암묵지(tacit knowledge)를 더 이상 암묵지가 아니게 되도록 인코딩(encoding)하는 것입니다. 즉, 아키텍처 결정 사항을 문서화하고, 컨벤션(convention)을 명시하며, 리뷰 표준을 글로 남기는 것입니다. 이러한 작업은 언제나 가치 있는 일이었습니다. AI의 도움을 받는 팀에서 이 작업은 핵심적인 지지대(load-bearing)가 됩니다. 그리고 이것은 EM의 업무입니다. 조직 내에서 팀 전체에 걸쳐 표준 계층(standards layer)을 책임지는 사람은 아무도 없기 때문입니다.

당신에게 주어지지 않았던 직무 기술서

이것은 대부분의 사람들이 처음에 동의했던 것보다 훨씬 더 어려운 형태의 엔지니어링 매니지먼트 (Engineering Management)입니다. 당신은 리더십이 믿고 있는 AI 생산성에 대한 기대와 팀 레벨에서 실제로 일어나고 있는 일 사이의 간극을 메워야 하며, 진정한 정체성 변화를 겪고 있는 엔지니어들을 위해 공간을 마련해주어야 하고, 이전에는 존재하지 않았던 거버넌스 (Governance) 구조를 구축해야 하며, 동시에 당신 자신의 변화 또한 헤쳐나가야 합니다.

이것은 불평이 아닙니다. 이는 단순히 "1:1 미팅을 진행하고 조직의 소음으로부터 팀을 보호하는 것" 보다 훨씬 더 흥미로운 직무입니다.

이 일을 제대로 해낼 임원들은 AI를 구현하는 사람들에게 단순히 결과물을 측정하는 것에 그치지 않고, 그들에게 실제로 무엇이 필요한지를 묻는 사람들입니다. 엔지니어링 매니저 (EM)는 보통 '마찰 없는 구현 (frictionless implementation)'이라는 가정이 더 이상 유효하지 않을 때 이를 가장 먼저 알아차리는 사람입니다. 그 정보는 반드시 표면화될 가치가 있습니다. 리더십은 보이지 않는 것에 대해서는 조치를 취할 수 없기 때문입니다.

보이지 않는 업무에는 자원이 배정되지 않습니다. 그 업무의 이름을 붙이십시오. 의사결정을 움직일 수 있는 용어로 프레임 (Frame)을 잡으십시오. 이 전환기의 중간 지점에서 바라보는 관점은 조직 내에서 가장 완전한 관점입니다. 이를 활용하십시오.

원문은 pixari.dev에 게시되었습니다.

"개발자와 그 상사가 생성형 AI에 대해 의견이 다른 이유" (Why developers and their bosses disagree over generative AI), LeadDev. https://leaddev.com/ai/why-developers-and-their-bosses-disagree-over-generative-ai ↩
Atlassian 개발자 경험 현황 보고서 2025 (Atlassian State of Developer Experience 2025). https://www.atlassian.com/teams/software-development/state-of-developer-experience-2025 ↩
Google Cloud / DORA, "2024 DORA 보고서 발표" (Announcing the 2024 DORA Report). https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report. 2025년 데이터에 따르면, 더 강력한 관행을 통해 처리량이 개선되었으나 안정성은 여전히 음의 상관관계를 보입니다. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report ↩
Harness 소프트웨어 전달 현황 보고서 2025 (Harness State of Software Delivery 2025). https://www.harness.io/state-of-software-delivery ↩
Reif, Larrick & Soll, "AI 사용에 대한 사회적 평가 페널티의 증거" (Evidence of a social evaluation penalty for using AI), PNAS, 2025년 5월. https://www.pnas.org/doi/10.1073/pnas.2426766122 ↩
"협업적 오픈 소스 소프트웨어 개발에 대한 생성형 AI의 영향: GitHub Copilot의 증거" (The Impact of Generative AI on Collaborative Open-Source Software Development: Evidence from GitHub Copilot), arXiv:2410.02091. https://arxiv.org/pdf/2410.02091 ↩
기업 AI 지출 패턴, 업계 출처 (2025/2026). Meta 리더보드 세부 정보는 이차 연구에서 인용되었으며, 일차 출처는 독립적으로 검증되지 않았습니다.