사람에게 좋은 것이 AI에게도 좋다

게시일: 2025년 12월 31일 | 원문 작성일: 2025년 9월 18일 | 저자: Luca Rossi | 원문 보기

핵심 요약

AI 발전이 둔화된 지금, 현재 우리가 가진 것을 점검할 좋은 시점입니다. 생산성 데이터는 결론이 나지 않지만, AI를 잘 활용하는 팀들에게서 발견한 공통점이 있습니다.

비밀 공식은 없다 — 사람에게 좋은 것이 AI에게도 좋습니다. 좋은 엔지니어링 관행이 AI 활용도를 극대화합니다.
AI는 코드 품질을 위협하는 게 아니라 도와야 한다 — AI는 코드 생성보다 코드 추론에 더 뛰어납니다.
많은 팀이 재설계되어야 한다 — 조율 비용을 줄이고 개인에게 더 넓은 오너십을 부여해야 합니다.

• • •

지난 몇 달간 제 관심의 대부분은 하나의 주제에 집중되어 있었습니다: 우수한 엔지니어링 팀들이 AI를 어떻게 활용하는가.

저는 여러 각도에서 이 주제를 탐구해왔습니다:

뉴스레터 설문조사를 마무리하고 있습니다 — 전체 업계 보고서가 몇 주 내로 발표될 예정입니다.
커뮤니티 스레드와 이벤트에서 다양한 관점을 탐구했습니다.
Coderabbit, Unblocked, Augment, Convex 등 AI 퍼스트 기업들의 팟캐스트 게스트 및 실제 엔지니어링 팀과 많은 1:1 대화를 나눴습니다.
마지막으로, 최근 직접 많은 코딩을 하며 사이드 프로젝트에서 좋은 진전을 이뤘습니다.

이 모든 것을 합치면 광범위하고 정량적인 데이터 포인트부터 깊고 정성적인(하지만 일화적인) 데이터까지 아우르는 거대한 정보의 피라미드가 됩니다.

AI에 대해 어떻게 생각해야 하는지, 어떻게 활용해야 하는지 고민하는 기술 리더라면, 다음이 알아야 할 핵심 사항들입니다:

진척이 둔화되고 있다 — 지금이 현 상황을 점검하기 좋은 시점입니다.
생산성 데이터는 결론이 나지 않는다 — 늘 그래왔듯이.
사람에게 좋은 것이 AI에게도 좋다 — 비밀 공식은 없습니다… 다행히도.
AI는 코드 품질을 개선해야 한다 — 위협하는 게 아니라.
많은 팀이 재설계되어야 한다 — AI를 최대한 활용하려면.

풀어볼 내용이 많으니, 바로 시작하겠습니다!

• • •

진척이 둔화되고 있다

지난 2년간 AI에 대한 글을 쓸 때마다 저는 “이 아이디어들은 몇 주 안에 구식이 될 것”이라는 같은 농담을 해왔습니다.

하지만 오늘은 더 이상 그런 느낌이 들지 않습니다. 사실 코딩 AI뿐 아니라 전반적으로 AI 진척이 상당히 둔화되었다고 말할 수 있습니다.

진척이란 무엇을 의미할까요? 소프트웨어 엔지니어링에서 AI 진척은 주로 두 가지 축에 의해 주도됩니다: 프론티어 모델과 개발 도구.

이 둘은 완전히 독립적이지 않습니다: 전자의 개선이 당연히 후자의 변화를 주도하지만, 도구의 사용성에 대해 모델과 관계없이 발견하고 있는 것들도 있습니다.

사실 지난 1년간 우리는 여러 패러다임을 거쳐왔고, 오늘날 주요 세 가지는:

AI 기반 IDE — Cursor, Augment 같은
자율 에이전트 — Devin 같은
CLI 도구 — Claude Code 같은

경계도 모호합니다. 각 도구가 종종 하나 이상의 기능을 시도하기 때문입니다.

한편, AI 모델은 정체되거나 최소한 효과가 점점 줄어드는 단계에 들어선 것으로 보입니다. 가장 권위 있는 코딩 벤치마크인 SWE-Bench에서 꾸준히 1위를 차지해온 Anthropic 모델들은 점점 더 작고, 짧고, 점진적인 반복 트렌드를 보여왔습니다. OpenAI의 최신 GPT5도 같은 트렌드를 따릅니다.

이것이 의미하는 바는: 오늘이 멈춰서 현 상황을 점검하기 좋은 시점이라는 것입니다. AGI나 특이점이 곧 올 것으로 기대하기 어려우니, 지금 우리가 가진 것을 살펴봅시다.

데이터부터 시작하겠습니다.

• • •

생산성 데이터는 결론이 나지 않는다

팀과 개인의 생산성에 AI가 미치는 영향에 대한 모든 가용 데이터와 연구를 살펴봤는데, 사실 데이터는 많은 것을 말해주지 않습니다.

아니, 더 정확히 말하면, 이 문제에 대한 편향이 무엇이든 그것을 뒷받침하는 데이터를 찾을 수 있습니다.

몇 가지 개인 사례부터 시작해보겠습니다:

🟢“AI 덕분에 코딩 속도가 5배 빨라졌습니다” — Redis 창시자 Salvatore Sanfilippo, Refactoring Podcast에서

Salvatore는 역대 가장 성공한 오픈소스 저자 중 한 명이고, 믿을 수 없을 정도로 복잡한 저수준 시스템 코드를 작성하며, 매우 현실적이고 실용적인 사람입니다. 다시 말해, 저는 그를 신뢰합니다.

🟢“우리 코드의 90%가 AI로 작성됩니다” — Every 창업자 Dan Shipper, Refactoring Podcast에서

Every는 100만 달러 이상의 ARR을 달성하고 Spiral, Cora 같은 실제로 작동하는, 수익을 창출하는 소프트웨어를 출시합니다. Dan은 팟캐스트에 출연해 그들이 대부분 바이브 코딩1으로 모든 것을 만든다고 설명했습니다.

이런 개인 이야기는 많지만, 더 종합적인 데이터를 보면 전망이 덜 밝습니다:

🟡“팀에서 관찰되는 AI로 인한 생산성 향상은 약 5-10%입니다” — DX CEO Abi Noda, Refactoring Podcast에서

Abi는 DX에서의 업무를 통해 수천 개의 코드베이스를 보고, 세계 최고의 팀들을 돕고 있습니다.

🔴“AI가 딜리버리 성과를 해치고 있습니다” — DORA, The State of DevOps

DORA 팀은 부정적인 AI 영향을 지적했습니다: AI를 정기적으로 사용하는 팀은 딜리버리 처리량에서 -1.5%, 딜리버리 안정성에서 -7.2%를 기록했습니다.

🔴“AI가 개발자를 19% 느리게 만듭니다” — [Becker et al.] METR 연구

마지막으로 널리 공유된 METR의 이 연구는 매우 작은 표본(개발자 19명)을 살펴보지만, AI 생산성에 대해 제가 본 것 중 가장 나쁜 수치를 보고합니다.

그래서 데이터는 결론이 나지 않아 보이지만, 이것이 정말 놀라운 일일까요? 소프트웨어 딜리버리 성과는 항상 큰 편차를 보여왔습니다. 이 분야에서 가장 영향력 있는 연구인 Accelerate를 생각해보면, 엘리트 팀과 평균 팀 사이의 격차는 종종 놀라울 정도입니다. 여러 측정치에서 50배 차이를 말하는 것입니다.

업계로서 우리는 많은 엔지니어링 관행에 대해 합의를 찾지 못했고, 다른 팀들보다 (몇 배) 뛰어난 성과를 내는 팀들이 항상 있었습니다. 따라서 AI에서도 팀들이 극명하게 다른 결과를 보고하는 것은 자연스러워 보입니다.

“데이터와 일화가 충돌할 때, 대개 일화가 맞습니다” — Jeff Bezos

이것은 또한 평균 종합 데이터는 별로 의미가 없고, 개별 팀들과 대화하며 그들이 어떻게 하고 있는지 파악하는 것이 더 도움이 된다는 것을 의미합니다.

그리고 이것이 제가 해온 일입니다.

• • •

사람에게 좋은 것이 AI에게도 좋다

최근 몇 달간 저는 팟캐스트 게스트들과, Unblocked, Augment, Convex, CodeRabbit, CodeScene 등 AI 퍼스트 기업들의 실제 팀들로부터 이야기를 수집했습니다.

저는 AI를 위해 이것저것을 어떻게 최적화하는지, 이것을 어떻게 AI 친화적으로 만드는지 등의 질문을 가지고 들어갔습니다. 그리고 압도적으로 공통된 응답은: 마법의 레시피는 없다는 것이었습니다. 사람에게 좋은 것이 AI에게도 좋습니다. 이것은 놀라울 정도로 좋은 소식입니다.

하지만 사람에게 좋다는 것은 무엇을 의미할까요? 제가 주목한 네 가지 가장 중요한 멘탈 모델로 풀어보겠습니다:

1) 작은 배치로 작업하기

이것을 상세히 설명하는 게 거의 바보 같게 느껴지지만, 어쨌든 말해볼게요: AI는 작은 반복으로 작업하는 것에서 엄청난 혜택을 받습니다 — 우리 인간과 마찬가지로.

사실 Claude Code나 Cursor 등과 잘 작업하는 방법에 대한 가장 인기 있는 블로그 글들을 보면, 조언의 많은 부분이 이것의 변주입니다. 욕심 부리지 말고, 작업을 계획하고, 자주 커밋하고, 피드백 루프를 촘촘하게 유지하세요.

2) 제약 조건 만들기

이것은 더 흥미롭지만 여전히 놀랍지는 않습니다. AI는 선택을 덜 하고 물리적으로 실수를 덜 할 수 있을 때 더 잘 수행합니다. 이것은 Charity Majors의 이 환상적인 인용문을 떠올리게 합니다:

“올바른 일을 가장 쉬운 일로 만들어라” — Charity Majors

그녀는 사람을 위해 이것을 말했지만, AI에게도 마찬가지입니다. 하지만 실제로 이것은 어떤 모습일까요? 일반적인 아이디어들:

정적 타입 언어 사용
강력한 린팅 사용
코드베이스 전체에서 추상화 일관성 유지
좋은 테스트 커버리지에 투자

다시 말해, 1) AI가 파악해야 할 범위를 제한하고, 2) 여러분(과 AI)이 오류를 일찍 잡을 수 있게 하는 설계 선택입니다.

3) 컨텍스트 설계하기

요즘 컨텍스트 엔지니어링, 즉 AI가 잘 수행하는 데 필요한 모든 것을 제공하는 방법에 대한 이야기가 많습니다.

이 영역은 AI가 사람과 진짜 좀 다르게 작동하는 부분이에요. 하지만 결론은 — 나중에 보겠지만 — 비슷합니다.

어느 정도 단순화하면, 어떤 작업을 위한 정보를 파싱하거나 조합할 때, 우리가 다루는 컨텍스트는 두 가지 유형이 있습니다:

넓은 컨텍스트 — 팀 채팅, 티켓팅, 문서, OKR 등 다양한 도구에서 오는 데이터를 이해하여 인사이트를 얻음
깊은 컨텍스트 — 코드베이스, 로그, 분석 같은 데이터가 많은 개별 소스를 분석하여 인사이트를 얻음

사람은 넓은 컨텍스트를 다루고 이 다양한 것들을 머릿속에 유지하는 데 탁월합니다. 반면 AI는 이것에 어려움을 겪지만, 우리보다 훨씬 더 큰 개별 데이터 덩어리를 처리하는 데는 뛰어납니다.

물론, 넓은 컨텍스트를 처리하는 AI의 한계 중 일부는 순전히 도구의 한계일 수도 있어요. MCP는 아직 투박하고, RAG는 초기 기술 느낌이며, 일부 소스는 아예 연결조차 안 되어 있죠. 하지만 지금 현실이 그렇고, 우리는 이 조건에서 작업해야 해요.

그래서 오늘날 AI는 로컬 추론 기회를 극대화할 때 가장 잘 작동합니다: 자체 완결적으로 만들고, 결합을 제한하고, AI가 같은 장소에서 모든 것을 찾게 하세요.

이것은 보통 좋은 컴포넌트화, 레포 안에 문서 유지, 그리고 불변의 낮은 결합 + 높은 응집 같은 좋은 설계 선택에서 나옵니다.

4) 모든 것을 코드로

마지막으로, 무언가를 코드로 표현할 수 있다면, 아마도 그래야 합니다. AI는 웹사이트를 탐색하고 클릭하는 것은 잘 못하지만, 코드를 작성하는 것은 환상적입니다.

Infrastructure as Code, Configuration as Code, Documentation as Code — 이 모든 것이 AI가 루프에 있을 때 훨씬 더 의미가 있습니다. 하지만 솔직히 말해서 — 이전에도 많은 의미가 있었습니다.

그래서 우리가 여기서 다룬 모든 것을 보면, 대부분이 고전적인 엔지니어링 트레이드오프입니다: 지금 조금 더 일을 하고(예: 좋은 코드, 좋은 테스팅, 좋은 문서) 나중에 혜택(즉, 더 높은 속도)을 거두는 것.

그리고 핵심은: AI가 저울을 기울이고 있다는 것입니다, 양쪽 모두에서:

한쪽에서, AI는 많은 노가다를 더 쉽게 만듭니다: 테스트 작성을 잘 하고, 문서 작성을 잘 하며, 구문과 DSL을 기억하는 인지 부담을 덜어줍니다.
다른 쪽에서, 지금 일을 잘 하는 것은 우리 사람뿐만 아니라 AI 자체에게도 이익이 됩니다.

다시 말해, AI는 동시에 1) 노력을 줄이고, 2) 혜택을 증가시킴으로써 좋은 엔지니어링의 ROI를 급상승시킵니다.

좋은 엔지니어링에 대해 말하자면, 품질에 대해 이야기해봅시다.

• • •

AI는 코드 품질을 도와야 한다

지금까지 우리가 대부분 좋은 엔지니어링 관행에 대해 이야기했다면 — 그 자체로 품질을 가능하게 해야 합니다 — 왜 품질에 대해 별도로 이야기해야 할까요?

우리가 이야기해야 하는 이유는, 단순히 말해서, 코드 품질이 AI와 관련하여 엔지니어들의 #1 관심사이기 때문입니다.

요즘 흔히 들리는 내러티브 중 하나가 바로 이거예요: AI가 더 짧은 시간에 더 많은 코드를 뽑아내게 해주겠지만, 그 코드를 제대로 통제 못 하고, 버그 투성이가 되고, 장기적으로 후회하게 될 거라는 이야기죠.

그럴 수도 있어요. 하지만 그게 피할 수 없는 운명은 아니고, 저는 그게 AI를 쓰는 최선의 방법이라고도 생각하지 않아요.

사실 AI는 기존 코드에 대해 추론하는 걸 굉장히 잘해요. 이건 코드 리뷰와 개선의 핵심 능력이죠. 저는 심지어 AI의 코드 추론 능력이 코드 생성 능력보다 낫다고까지 말하고 싶어요. 아마 더 제약된 도메인이라서, 좁은 영역을 깊이 파고드는 AI의 특성과 잘 맞기 때문일 거예요.

이유가 뭐든, 오늘날 AI는 코드 스멜, 보안 취약점, 누락된 테스트를 잡는 데 이미 환상적이에요. 그뿐 아니라 팀만의 모범 사례와 컨벤션 준수를 점검하고, PR 자동 요약, 릴리스 노트 같은 삶의 질을 높여주는 자잘한 개선들도 해줘요.

이걸 도와주는 도구 목록은 날마다 늘어나고 있어요. 제가 직접 써보고 효과를 본 것들 중에는 Codacy, Packmind, Augment, CodeRabbit 등이 있어요.

AI가 얼마나 빠르고 저렴하게 마법을 부리는지 때문에, 코드 품질이 계속 왼쪽으로 이동하고 있다는 것도 흥미롭습니다.

AI 이전에는 CI/CD에 속했던 많은 정적 분석 검사가 이제 IDE에서 실시간 제안이 됩니다. 그리고 이 중 일부는 에디터에서 보기도 전에 AI 생성 코드를 조종할 수 있는 MCP 서버가 되기도 했습니다.

여기서 더 왼쪽으로 가기는 어렵습니다!

그래서 저는 코드 품질의 미래가 매우 밝다고 믿지만, AI를 순수한 코드 생성기가 아닌 그것을 위해 의도적으로 사용해야 합니다.

• • •

많은 팀이 재설계되어야 한다

마지막으로, 지금까지 우리는 대부분 코딩에 대해 이야기했지만, SDLC는 많은 다른 단계로 구성된 파이프라인입니다.

AI 코딩 생산성 향상을 측정하는 데 있어 방 안의 코끼리2는 소프트웨어 엔지니어들이 평균적으로 코딩에 매우 적은 시간을 보낸다는 것입니다 — 정확히 말하면, 하루에 한 시간도 안 됩니다.

운이 좋아서 90번째 백분위수 근처에 있어 약 2시간을 쓴다 해도, 크게 달라지지 않습니다: 여전히 시간의 약 25%에 불과합니다.

나머지는 어디로 갈까요? 기본적으로 조율입니다: 다른 사람들이 뭔가를 하기를 기다리기, 회의, 상태 관리, 협상 등.

조율 비용은 일을 출시하는 데 관여하는 사람 수의 직접적인 함수입니다. 그래서 저는 이 숫자를 줄이고 사람들에게 더 넓은 오너십 범위를 부여하는 것을 강력히 믿습니다—AI가 전체 제품 스택에서 사람들의 기본 역량을 폭넓게 보강해주는 점을 활용해서요.

오늘날 엘리트 스타트업이 출시하는 방식과 평균 팀 사이에 격차가 있다면, 바로 이것입니다. 지난 10~15년간 쌓아온 조직 계층화이고, 사람들이 진정한 숙달과 최대 생산성을 개발할 수 있도록 해체해야 합니다. DHH가 이 점에서 옳고, 오늘날의 새로운 팀들은 이것의 많은 부분을 제거하고 있습니다.

이에 대해 무엇을 할 수 있을까요? 몇 가지 아이디어:

기술 스택 풋프린트를 작게 유지하세요 — 풀스택 프레임워크를 사용하고, 만드는 것보다 10배 더 구매하고, 지루한 선택을 하고, 일반적으로 엔지니어의 인지 부담을 줄이기 위해 일을 쉽게 만드세요.
좋은 디자인 시스템을 유지하세요 — 엔지니어들의 블로커를 해제하고 모든 사람을 루프에 넣지 않고도 간단한 것들을 출시할 수 있게 하세요.
제품 성공이 어떤 모습인지 정의하세요 — 엔지니어들이 일이 되는지 안 되는지 파악하고 반복할 수 있도록.
게이트를 제거하세요 — 프로세스의 블로킹 부분을 줄이세요: 예를 들어 피처 플래그로 배포와 릴리스를 분리하고, QA를 비동기로 만들고, 일이 잘못됐을 때 빠르게 롤백하는 워크플로우로 전환하세요. 여러 블로킹 게이트를 통과시켜 올바른지 확인하는 대신.

다시 말하지만, 이것 중 거의 새로운 것은 없습니다. 10년 전에, 어쩌면 그 이상 전에 이미 이런 것들에 대해 이야기하고 있었습니다. 차이점은 — 이것이 공통 스레드입니다 — 이런 것들이 AI와 함께 이제 더 쉽고, 더 보람 있다는 것입니다.

• • •

우리는 운이 좋다

작은 성찰로 마무리하고 싶습니다: 우리는 운이 좋습니다.

우리 인간이 번성하게 만드는 것들과 대부분 같은 것들에서 번성하는 기술을 우연히 발견하게 되어 운이 좋습니다. 좋은 소프트웨어 엔지니어링을 중요하게 생각한다면, 오늘이 당신이 빛날 시간입니다.

오늘 당신이 중요하게 생각하는 것들이 이전보다 더 가치 있고 더 명확합니다.

역자 주

바이브 코딩(Vibe Coding): AI에게 자연어로 원하는 것을 설명하면 AI가 코드를 생성하는 개발 방식. 2025년 Andrej Karpathy가 처음 명명했으며, 개발자가 코드를 한 줄 한 줄 작성하지 않고 AI와 대화하듯 개발하는 것을 말합니다. ↩
방 안의 코끼리(Elephant in the Room): 모두가 알지만 아무도 언급하지 않는 명백한 문제를 가리키는 영어 관용구. 거대한 코끼리가 방에 있는데 없는 척하는 상황을 비유합니다. 여기서는 ‘모두가 알지만 자주 간과하는 핵심 사실’이라는 의미로 사용되었습니다. ↩

저자 소개: Luca Rossi는 Refactoring 뉴스레터를 운영하며, 엔지니어링 리더십과 기술 문화에 대해 글을 씁니다.

참고: 이 글은 Luca Rossi가 Refactoring 뉴스레터에 게시한 아티클을 번역하고 요약한 것입니다.

원문: What’s good for humans is good for AI - Luca Rossi, Refactoring (2025년 9월 18일)

생성: Claude (Anthropic)

총괄: 존 (디노이저denoiser)