Elephants, Goldfish and the New Golden Age of Software Engineering
업데이트: 2026-10-21 — Google이 나와 우리 팀에게, 이 방법론을 따르려고 사내에서 쓰는 AI 코딩 어시스턴트 플러그인을 오픈소스로 공개하도록 허락했다. 자세한 내용은 여기서 볼 수 있다: https://egm.dev
들어가며
2026년 4월 이 글을 쓰는 지금, 생성형 AI 도구, 특히 대규모 언어 모델(Large Language Models, LLM)이 우리가 일을 생각하고 해내는 방식을 송두리째 바꾸고 있다는 것은 이미 분명하다. 이것은 소프트웨어 엔지니어링만의 변화가 아니다. 모든 직업 하나하나에 닿는 변화다. 이 글은 지난 한 해에 대한 내 기록이다 — 나와 우리 팀들이 걸어온 여정, 우리가 얻은 쓰라린 교훈, 그리고 다음에 올 것에 대한 내 개인적인 견해.
이미 AI 코딩 도구로 일하고 있든, 이제 막 AI 챗봇을 이리저리 건드려 보기 시작했든, 이 글에서 무언가를 얻어 가기를 바란다. 일에서 AI가 맡는 역할을 생각하는 데, 그리고 AI를 써서 자신을 더 생산적이고 가치 있는 사람으로 만드는 방법을 생각하는 데 도움이 될 무언가를.
출발점이 어디든, 두 가지를 크고 분명한 목소리로 말해 두겠다:
- 이 관찰들은 내 개인적인 관점을 반영한다. 이 도구들로 성공하는 길은 여럿이니, 폭넓게 탐색하고 자신에게 가장 잘 맞는 방법을 찾아야 한다. 사람마다 결과는 다를 수 있다.
- 변화의 속도가 이토록 무섭다 보니, 한 해만 더 지나도 이 말들은 낡은 것이 될 수 있다. 건강한 회의심을 품고 읽어 주기 바란다.
이 글의 구성
이 글은 크게 세 부분으로 되어 있다.
1부에서는 우리 대부분이 AI 도구를 — 기본적인 챗봇까지 포함해 — 잘못 쓰고 있다고 주장한다. 그리고 당신이 누구든, 무엇으로 먹고살든 가치가 있기를 바라는 다른 접근법을 제안한다. 이 부분은 모두를 위한 것이고, 뒤에 이어지는 내용의 토대가 된다.
2부에서는 1부의 기본 원칙을 소프트웨어 작성이라는 작업에 성공적으로 적용하는 방법을 더 자세히 다룬다. 특히 우리가 코끼리-금붕어 모델(Elephant-Goldfish Model, EGM)이라고 부르는 작업 모델을 소개한다. 이미 AI 코딩 도구를 쓰고 있다면 이 부분의 많은 내용이 익숙하겠지만, 그래도 처음 접하는 알맹이가 몇 개는 있으리라고 생각한다. 2부를 읽는 데 소프트웨어 엔지니어일 필요는 없지만, 거기서 설명하는 작업 방식은 소프트웨어를 써 온 내 경험에서 곧바로 나온 것이다.
마지막으로 3부에서는 (변화 속도를 생각하면 아마 현명하지 못하게도) 예언의 영역에 발을 들인다. 업계는 무서운 속도로 진화하고 있지만, 우리가 결국 살게 될 미래가 구체적으로 어떤 것이든 그에 대비하는 데 쓸 수 있는 패턴이 이미 몇 가지 떠오르고 있다고 생각한다.
1부: 장난감이 아니라 도구다
10배의 생산성 향상은 AI 모델을 쓰는 엔지니어만의 것이 아니다. 당신의 것이기도 하다. 지금 도구를 쓰는 방식을 간단히 바꾸기만 해도 오늘은 더 빨리, 내일은 훨씬, 훨씬 더 빨리 갈 수 있고, 결과물의 품질도 좋아진다. 이것은 낚시성 제목이 아니다. 단순한 진실이다
차를 사 보자!
새 차를 사고 싶다고 해 보자. 이 문제에 어떻게 접근하겠는가?
우리 대부분은(얼마 전까지의 나를 포함해) 이 차에 대해 자기에게 중요해 보이는 것들을 곰곰이 생각한 다음, 가장 좋아하는 LLM 도구를 리서치 모드로 열고 이렇게 말할 것이다:
“새 차를 사고 싶다. 내가 사고 싶은 차에 대해 생각해 둔 것을 전부 여기 적는다. <여기에 생각해 둔 것을 무엇이든 넣기> 인터넷을 샅샅이 뒤져서, 내가 고려해야 할 차와 사야 할 차에 대해 세상에서 가장 포괄적이고 인상적인 보고서를 만들어라. 시간은 얼마든지 써도 된다.”
20분 뒤면 꽤 인상적으로 보이는 보고서가 나오고, 거기에는 그럴듯하게 들리는 추천이 담겨 있을 것이다. 우리는 스스로 얼마나 영리한지 흐뭇하게 고개를 끄덕이고는, AI가 승인한 새 차를 가장 좋은 조건에 살 곳을 찾아 인터넷을 뒤지기 시작할 것이다.
그리고 우리는 잘못했다.
아주 강력한 도구를 장난감처럼 썼고, 장난감 같은 결과를 얻었다. 그러면.. 차를 사는 데 AI를 어떻게 써야 할까?
1단계: 승리는 준비를 사랑한다
올바른 차를 사려던 우리의 가상 원정이 실패할 운명이었던 것은, 기계가 우리를 대신해 성공할 수 있도록 제대로 준비시키지 않았기 때문이다. 우리는 기계에게 심문관이 아니라 연구원 역할을 시켰다.
고생하는 우리 AI 어시스턴트에게 원래 줬어야 했던 프롬프트는 이것이다:
“새 차를 사고 싶습니다. 큰돈이 드는 일이라 충분히 알아보고 잘 따져 본 결정을 내리는 것이 아주 중요합니다. 새 차에 무엇이 필요한지 생각해 봤지만, 중요한 측면을 놓치고 있다고 확신합니다. 지금까지 생각해 낸 것을 말씀드릴 테니, 당신이 할 일은 제가 그만하라고 할 때까지 계속 명확히 하는 질문을 던지는 것입니다. 우리가 함께 할 일은 이 결정의 중요한 가장자리를 빠짐없이 탐색하는 것입니다. 끝났다고 제가 말할 때까지 계속 제 가정을 의심하고, 중요한 점을 명확히 하도록 저를 몰아붙여 주세요. 지금까지 생각해 낸 것은 이렇습니다: <여기에 앞의 문단 넣기>”
이어지는 15~20분 동안 AI가 던지는 질문과 반박에 답하라. 가끔은 모델에게 “네 생각은 어떤가?”라고 물어라. 동의하지 않으면 논쟁하라. 다만 반드시 이기려고가 아니라 배우려고 논쟁하라.
참고: 모델이 “정말 좋은 지적이야! 넌 천재야!” 같은 쓸모없는 말을 하기 시작하면, 아첨의 소용돌이에 빠진 것이다. (이 모델들이 모두 “친절하고 도움이 되라”는 지시를 받는 데서 오는 피할 수 없는 결과다.) 대개는 진짜로 도움이 된다는 게 무슨 뜻인지 상기시키면 모델을 이 고리에서 끌어낼 수 있다:
“네가 내게 동의할 때 너는 도움이 되고 있지 않다. 너는 내 생각에 도전하고 내 문제의 가장자리를 생각하도록 나를 몰아붙일 때 가장 도움이 된다”
모델이 지나치게 맞장구를 치기 시작할 때마다 내가 꺼내는 단골 대답이 이것이다.
15~20분이 지나면 사고 싶은 이상적인 차에 대해 훨씬 풍부한 설명을 갖게 된다. 처음의 한 문단이 2~3쪽으로 불어나 있을 것이다. 여기서 멈추고 이 새 설명을 AI에게 줘도 이미 훨씬 나은 결과를 얻는다. 하지만 우리는 더 잘할 수 있다.
이제 2단계로 갈 준비가 됐다.
2단계: 신뢰하되 검증하라
문제를 철저히 설명하는 것은 훌륭한 답을 얻는 레시피의 앞쪽 절반일 뿐이다. 다음 단계는 모델이 알려 주는 것이 쓸모 있으면서 검증 가능하게 참인지 확인하는 것이다.
지금 채팅 세션을 이어 가면서 이 프롬프트를 줘라:
“질문 고맙다. 하지만 이제 우리의 설명은 완성됐다고 생각한다. 나는 이 설명을 한 번도 같이 일해 본 적 없는 연구원에게 넘길 것이다. 그가 보고서를 만든 뒤에 그 품질을 믿을 수 있다는 걸 알아야 한다. 이제 네가 회의적인 전문 팩트체커의 페르소나를 맡아 주면 좋겠다. 그의 보고서에서 무엇을 찾을 수 있어야 그의 작업이 철저하고 정확했다고 확신할 수 있을지, 그 모든 것에 대해 너와 대화하고 싶다. 어떤 종류의 링크? 인용? 등등.. 그에게 이 리서치를 부탁할 기회는 단 한 번뿐이고 후속 질문을 할 기회도 없으니, 내가 그의 작업을 어떻게 평가할지 아주 분명하게 전해야 한다. 지금 이것을 논의하자. 합격 기준 만들기가 끝나면 알려 주겠다.”
이제 앞 단계의 인터뷰 과정을 똑같이 되풀이하되, 이번에는 최종 결과물의 품질을 어떻게 채점할지에만 집중한다. 앞에서처럼 이 단계에도 15~20분쯤 쓸 거라고 예상하라.
끝나면 보고서의 채점 기준표에 해당하는 텍스트가 2~3쪽 더 생겨 있을 것이다. 이제 질문과 평가 기준 양쪽에 대해 더 완전한 설명을 갖췄으니 마지막 단계로 갈 준비가 됐다.
3단계: 이득
LLM으로 새 세션을 열고 딥 리서치 모드 같은 것으로 설정하라. 그리고 이렇게 말하라:
“깊이 생각해 주었으면 하는 주제가 하나 있다. 쓸 수 있는 도구는 무엇이든 써서 이 질문에 철저히 답하라. 리서치 주제와 함께 내가 네 최종 보고서의 품질을 평가할 때 쓸 구체적인 기준도 주겠다. 네 목표는 질문에 철저히 답하고 모든 평가 기준을 너끈히 통과하는 최종 결과물을 만드는 것이다.
내가 리서치해 주기를 바라는 주제에 대한 설명은 이렇다:
— — — — — — -
<여기에 1단계의 텍스트 넣기>
— — — — — — -
네 결과물의 품질을 평가할 기준은 이렇다:
— — — — — — —
<여기에 2단계의 텍스트 넣기>
— — — — — — -”
이제 모델이 필요한 만큼 오래 딥 리서치를 돌리게 두면 된다. 그리고 한 번에 끝내는(one-shot) 프롬프트로 하려 할 때보다 훨씬 나은 결과물을 얻으리라고 자신해도 좋다.
판단력에 관한 한마디
우리 중 누구도 평소 하는 일이 차를 사는 것은 아니다(물론 그게 정말 당신의 본업이라면 아주 멋진 직업을 가진 것이다!). 직무가 무엇이든(영업, 마케팅, 재무 등) 우리는 모두 같은 일을 하라고 고용됐다 — 사업을 위해 더 많은 가치를 만들어 내도록 탁월한 판단력을 발휘하는 것.
회사는 우리가 꾸준히 보여 주는 판단의 질과 영향력으로 우리의 가치를 정한다.
경력 초기라면, 고용주는 우리가 자기 업무 영역에서 좋은 판단력을 빠르게 익힐 능력이 있다는 데 돈을 건 것이다. 경력 후반이라면, 회사는 우리가 이미 쌓아 온 판단력을 회사를 위해 발휘하고 다른 사람들이 각자의 판단력을 익히도록 도우라고 우리를 고용한 것이다.
이 모델들은 (적어도 이 글을 쓰는 시점에는) 이런 종류의 판단을 할 수 없다 — 겉보기에 판단을 닮은 단어 열을 만들어 내는 데는 탁월하지만. 판단을 기계에 외주 주는 실수를 하지 마라.
미래의 나를 가속하기
이 절의 단계들은 판단력을 아주 빠르게 훨씬 큰 생산성으로 바꾸는 데 도움이 된다. 하지만… 진짜 가치는 사실 시간이 지나면서 복리로 쌓인다..
이 단계들에서 만든 전체 설명, 합격 기준, 최종 결과물을 쉽게 찾을 수 있는 곳에 저장하라. (공유 드라이브, NotebookLM 등.) 시간이 지나면 엄청난 양의 추론과 이력이 쌓이고, 다른 문제를 두고 모델과 나눌 미래의 대화에서 그것을 지렛대로 쓸 수 있다.
참고: 대화 전체를 저장할 필요는 없다. 이 세 가지 산출물이면 충분하고, 나머지는 대부분 토큰 잡음으로 드러난다
왜 이렇게 하는가? 이제 과거의 내 판단, 혹은 팀의 집단 지혜와 대화할 수 있기 때문이다!
“우리는 왜 이 결정을 이런 식으로 내렸나? X에 대한 우리의 사고 과정은 어땠나?” 등등..
새 팀원을 온보딩하거나 미래의 결과물을 과거의 추론에 비춰 시험하는 일이 얼마나 쉬워질까? 프로젝트나 팀, 오래 이어지는 프로그램의 궤적을 재구성하는 일은 얼마나 쉬워질까?
오늘 이렇게 하기 시작하면 속도와 품질은 앞으로 빠르게 복리로 불어난다. 미래의 나는 지금의 나와는 알아볼 수 없을 만큼 더 생산적이 된다.
2부: 코끼리와 금붕어
2025년 여름, 나는 회사에서 업무상 문제를 하나 안고 있었고, 그것을 푸는 데 도움이 될 작은 도구를 (AI의 도움을 잔뜩 받아) 만들었다. 그 작은 도구는 팀 동료들에게 쓸모가 있었고 — 나로서는 놀랍게도 — 다른 많은 사람에게도 쓸모가 있었다. 다른 엔지니어들이 찾아와 이 도구에 새 기능을 기여하고 싶다고 했고(나는 고맙게 받아들였다), 몇 달 만에 10만 명이 넘는 구글러가 비슷한 모양의 자기 문제를 풀려고 이 도구를 정기적으로 쓰게 됐다.
AI 코딩 어시스턴트 없이도 이렇게 빨리 가면서 수십 명의 기여를 안전하게 받아들이고, 그러면서도 보안·프라이버시·신뢰 기준을 지키는 일이 가능했으리라고는 생각하지 않는다. (내 경우에는 Google Antigravity와 Gemini를 쓴다.)
이렇게 일하는 것은 놀랍지만, 머지않아 무서운 사실 하나를 금세 깨닫게 된다.
조심하지 않으면, 우리는 그저 코드를 더 빨리 쓰는 게 아니다. 우리는 실수를 대량 생산하고 있다.
AI를 써서 빨리 가는데 신호 대 잡음비를 높게 유지하지 못한다면, 생산성은 사실 뒷걸음질하고 있는 것이다. 나쁜 코드가 생성되는 속도가 생산적인 코드가 생성되는 속도보다 크면, 프로젝트는 결국 읽을 수도 유지보수할 수도 없는 자기 슬롭(slop)의 무게에 짓눌려 무너진다.
그 뒤 몇 주, 몇 달에 걸쳐 우리는 더 나은 방법을 찾았다. 하지만 먼저 사람만으로 이뤄지는 “코더”의 시대가 빠르게 끝나 가고 있다는 사실을 받아들여야 했다.
세 번의 “아하” 순간
문제의 크기가 정말로 와닿은 것은 유난히 답답했던 어느 오후였다. 나는 AI로 새 기능을 구현하고 있었다. 세션에 들어간 지 한 시간, 세부 사항 깊숙이 파묻혀 있을 때 모델이 그냥 뻗어 버렸다.
새 세션을 시작하자 백지 상태였다. 앞선 한 시간의 작업을 전혀 기억하지 못했다. 수백 줄의 코드를 먹여 가며 이 몹시 복잡한 작업에 기계를 다시 부트스트랩하는 일은 지루하고, 토큰을 많이 잡아먹고, 엄청나게 짜증 나는 일이었다.
그것이 아하 순간 #1이었다. 만약 내가 그저 내 의도와 현재 진행 상태를 설명하는, 명확하게 쓴 문서 하나를 유지했다면, 다시 부트스트랩하는 데 30초면 됐을 것이다. (“이 문서를 읽어라. 문서가 가리키는 코드를 읽어라. 우리가 어디까지 왔는지 말하고, 계속하자.”)
그래서 그렇게 해 봤다. 맥락을 되찾았다. 그런 다음 AI에게 구현을 마무리하라고 했다.
문제 해결! 그런데.. AI는 곧바로 궤도를 벗어나, 내가 요청한 적 없는 방향으로 질주하고, 있지도 않은 API를 환각으로 지어내고, 우리 시스템에서는 전혀 말이 안 되는 아키텍처 선택을 했다.
그것이 아하 순간 #2였다. AI 모델은 비위를 맞추고 싶어 안달이라서, 아주 엄격한 가드레일을 세워 두지 않으면 신이 나서 절벽 너머로 질주한다.
하지만 진짜 깨달음은 몇 주 뒤, 완전히 새로운 기능을 시작할 때 찾아왔다. AI가 시스템을 이해하게 하려고 소스 코드를 먹일 필요가 없다는 걸 깨달았다. 설계 문서만 먹이면 됐다.
그것이 아하 순간 #3으로 이어졌고, 그것은 간단히 이렇다:
sizeof(docs) << sizeof(code)
수만(혹은 수십만) 줄의 날것 그대로의 코드를 억지로 읽고 해석하게 하는 것보다, 평이한 영어로 쓴 설계 문서로 AI에게 맥락을 주는 편이 훨씬 훨씬 싸고, 빠르고, 믿을 만하다.
사라지는 코드
이것이 왜 그렇게 중요한지 이해하려면, 오늘날 우리가 소프트웨어를 만드는 방식을 들여다봐야 한다.
역사적으로 설계 판단 — 시스템의 “왜”와 “어떻게” — 은 두 곳에 놓인다. 설계 문서, 그리고 코드 자체. 사람이 코드를 쓸 때는 로직 안에 미세한 결정들의 흔적을 남긴다.
하지만 AI가 코드를 쓴다면, 사람은 더 이상 그 미세한 결정들을 내리지 않는다. 코드가 쓰이기 전에 그 설계 판단들을 모두 설계 문서 쪽으로 “왼쪽 이동(shift left)”하도록 강제하지 않으면, 그렇게 나온 시스템은 최종적으로 그것을 책임지는 사람에게 전혀 이해할 수 없는 것이 된다.
우리는 지금 문턱에 걸친(liminal) 상태에 있다. 여전히 엄밀함이 필요하기 때문에 여전히 코드가 필요하다. 하지만 사람이 100% 검토하는 코드는 사라져 가는 중간 단계다.
내가 보기에 우리는 둘 중 한 곳에 도착할 것이다. (1) 모델이 너무 많은 코드를 만들어 내서 사람이 그것을 전부 검토하는 일이 현실적으로 불가능해지거나, (2) 모델이 아예 바이너리를 직접 만들어 내기 시작해 코드를 통째로 건너뛰거나. 하지만 어느 쪽이 맞든 상관없다. 눈보라처럼 쏟아지든 바이너리로 나오든, 코드는 우리에게 불투명해질 것이고, 코드가 불투명해지면 의미 있는 산출물은 설계뿐이다.
설계가 새로운 코드다.
코끼리-금붕어 모델(EGM) 소개
시간이 지나며 팀은 간단하면서도 아주 효과적인 운영 틀을 만들어 냈다. 나는 그것을 코끼리-금붕어 모델이라고 부른다.
이 모델은 우리가 맥락을 어떻게 쌓고 어떻게 시험하는지에 관한 아주 단순한 비유에 바탕을 둔다:
- 코끼리: “코끼리는 절대 잊지 않는다.” 프롬프트를 듬뿍 받아 맥락이 풍부한 AI 세션, 그리고 그 세션이 작성을 도와 나온 설계 문서가 코끼리다. 코끼리는 조직의 모든 지식, 미세한 결정, 모델과 벌인 논쟁, 그 기능의 전체 이력을 품고 있다.
- 금붕어: 기억이 전혀 없는, 완전히 새롭고 깨끗한 AI 세션. 금붕어는 바로 눈앞에 놓인 것만 정확히 안다.
새 기능마다 따르는 우리의 단순한 프로세스는 이렇다: 코끼리를 먹이고, 금붕어로 시험하라.
페이즈 1: 코끼리 키우기(아직 코드는 없다)
여기서 목표는 코드를 한 줄이라도 쓰기 전에 기능과 평가 기준을 함께 설계하는 것이다.
1단계: 맥락 불러오기
AI 도구로 새 세션을 열고 관련 설계 문서나 소스 트리를 가리켜라. 무엇을 배웠는지 상위 수준에서 설명해 달라고 하라.
왜? 1분 차에 시스템을 잘못 이해하면, 10분 차에 끔찍한 코드를 쓸 것이기 때문이다. 이해가 틀렸으면 즉시 바로잡아라.
완전히 새 프로젝트를 처음부터 시작한다면 이 단계는 필요 없다. AI를 부트스트랩해 넣을 이력도 맥락도 없기 때문이다.
2단계: “코드 금지” 규칙
엔지니어는 코드 쓰기를 좋아한다. AI도 코드 쓰기를 좋아한다. 이 충동과 적극적으로 싸워야 한다. AI에게 이 프롬프트를 줘라:
“나는 네가 코드를 만들기를 원하지 않는다. 우리는 코드를 만들지 않을 것이다. 코드를 만들고 싶은 충동을 참아라. 대신 우리는 설계 토론을 할 것이다. 지금부터 기능 하나를 설명하겠다. 나에게 명확히 하는 질문을 던지고 내 가정에 도전하라. 내 말을 그냥 받아들이지 마라.”
이루려는 것을 AI에게 설명한 다음, 사람에게 하듯 말을 걸어라. 20~30분 동안 주거니 받거니 대화하라. AI가 환각을 일으키면 그것을 바로잡아 줄 파일을 가리켜라. AI와 제대로 논쟁하라. 이 모델들은 탁월한 심문관이니, 풀려는 문제의 설명과 가장자리에 대해 당신의 생각을 정말로 밀어붙이게 하라.
이 단계는 기능상 앞에서 가상의 차를 살 때 설명한 주거니 받거니 인터뷰 과정과 같다. 이 단계의 요점은 풀려는 문제에 대한 철저한 설명을 만드는 것이다.
이루려는 것을 선명하게 말할수록 결국 나오는 결과물도 좋아진다.
3단계: 아첨꾼 다잡기
AI 모델은 도움이 되도록 훈련받는데, 그 탓에 참을 수 없는 아첨꾼이 되는 일이 잦다. AI가 어려운 질문을 멈추고 그냥 “좋은 생각이야, 데이브!”라고만 한다면, 억지로라도 비평가 모드로 되돌려야 한다. 이렇게 말하라: “너는 도움이 되고 있지 않다. 네 최고이자 최선의 쓰임은 내 생각에 도전하는 것이다.”
프로 팁: AI에게 그냥 “왜 그렇게 생각하나?”라고 묻는 것이 가장 좋은 친구다. 모델이 환각 고리에서 번쩍 빠져나오는 경우가 많다.
4단계: 기술 제안 초안
문제를 완전히 설명했다는 만족이 들면, 이제 가능한 해법을 놓고 토론을 시작할 때다.
AI에게 산문과 블록 다이어그램으로 구현을 제안하라고 하라. 짧은 의사코드 블록은 괜찮지만, 글로 쓴 텍스트를 요구하라. 탄탄한 접근법에 정착할 때까지 AI와 논쟁하라.
첫 설계를 AI에게 제안하게 하는 것이 아주 중요하다. 그래야 AI가 당신의 문제를 잘 이해하는지 알 수 있다.
반대로 당신이 첫 설계를 제안하고 AI에게 반응하게 하면, 거의 틀림없이 사각지대를 몇 군데 놓친다. 모델에게 이것을 시키는 방법은 많지만, 내가 가장 자주 쓰는 프롬프트는 이것이다:
“코드베이스에 대한 네 이해와 우리가 논의한 내용을 바탕으로, 이 기능을 실제로 구현할 기술적 방안의 초안 제안을 내게 줬으면 한다. 코드를 원하는 게 아니다. 내 시스템을 이해하고 있음을 보여 주는 산문을 원한다. 도움이 된다고 생각하면 짧은 의사코드 블록은 괜찮지만, 명확하게 쓴 텍스트와 블록 다이어그램을 훨씬 선호한다.”
초안은 (적어도 조금은) 틀릴 것이다. 명확히 하는 질문을 던져라(예: “왜 그 패턴을 골랐나? 나는 시스템이 X처럼 동작한다고 생각했는데…”). 탄탄한 기술적 접근법에 정착할 때까지 AI와 논쟁하라.
모델이 시스템에 대해 무언가를 환각하면, 그 이해를 바로잡아 줄 파일을 가리켜라. “아니요. 그렇게 동작하지 않는 것 같아요. auth.py를 읽어 주세요. (또는 AUTH.md든 뭐든)”
기술 제안을 만드는 이 주거니 받거니는 몇 시간이 걸릴 수도 있다. Gemini와 중요한 결정을 두고 토론하느라 2~3일씩 이어진 세션도 있었다.
이 주거니 받거니를 서두르지 마라. 서두르면 후회한다.
페이즈 2: 코끼리 가르치기
이제 코드의 절대적인 진실 공급원(source of truth)이자 가드레일 역할을 할 마크다운 문서를 만든다. AI에게 문서 전체를 한 번에 쓰라고 하지 마라. 현재 모델들은 한 번에 내놓는 출력에 토큰 한도가 있기 때문이다. 같은 채팅 세션 안에서 반복하며 쌓아 올려라.
우리가 가장 쓸모 있다고 찾아낸 절들의 구조와 순서는 이렇다. 이 문서를 한 번에 끝내려고(one-shot) 하지 마라. 각 절을 따로 써라.
- 문제: AI에게 사업상 문제를 평이한 영어로 설명하게 하라. 아마 3~5문장이면 충분할 것이다. 지나가며 읽는 사람이 무엇을 이루려는지 이해할 수 있을 만큼이면 된다.
- 기술 계획: 큰 구성 요소들과 그것들이 어떻게 맞물리는지를 전문 용어를 줄여 설명하게 하라. 말이 된다면 주요 구성 요소의 블록 다이어그램을 넣어라. 이 절의 목표는 설명하는 산문이다.
- 대안: 페이즈 1에서 고려했지만 배제한 아이디어를 기록하라. 고려했다가 기각한 주요 결정이 이 절에서 빠짐없이 다뤄지도록 하라. 이것들은 앞으로의 환각과 논쟁을 막는 중요한 가드레일이 된다.
- 상세 구현: 이 문서에서 가장 긴 절이 된다. 아주 상세한 단계별 구현 계획을 담아야 한다. 새로 만들거나 바꿀 파일 하나하나 전부와 그 이유를 AI가 열거하도록 요구하라. 이것이 결정적이다. 이렇게 하면 구현에 들어갔을 때 AI가 궤도를 벗어나지 않도록 붙잡아 두는 데 도움이 된다.
이 파일을 트리에 저장하라. 이것이 새 기능의 첫 산출물이고, 이제 당신의 새 소스 코드다.
페이즈 3: 금붕어 프로토콜
설계 문서가 정말로 좋은지, 아니면 “코끼리” AI 세션에 쌓인 맥락에 기대고 있을 뿐인지 어떻게 알 수 있을까?
금붕어로 시험한다.
5단계: 이해도 시험
완전히 새로운 빈 AI 세션(금붕어)을 시작하라. 마크다운 문서를 주고 이렇게 말하라:
“이 문서와 문서가 가리키는 파일들을 읽어라. 이 문서가 무엇을 이루려 하는지, 그리고 이 기능과 관련해 내 시스템이 현재 어떻게 동작하는지 말하라.”
금붕어가 오직 그 문서와 문서가 가리키는 파일만으로 시스템을 설명하지 못한다면, 문서에 맥락이 빠져 있는 것이다. 세부 사항을 보태고 통과할 때까지 되풀이하라. 이 고리를 건너뛰지 마라. 금붕어 시험을 통과한 문서는 슬롭을 막는 중요한 방어막이 된다.
6단계: 비평가 리뷰
금붕어 세션을 하나 더 시작하라:
“전문 기술 리뷰어 역할을 맡아라. 이 설계 문서와 문서가 가리키는 모든 파일을 읽어라. 내가 놓친 것, 잘못된 가정, 빠뜨린 엣지 케이스, 고려했어야 하는데 하지 않은 것을 전부 말하라. 네가 찾아내는 실수와 모호함 하나하나가 너를 더 도움이 되고 쓸모 있게 만든다.”
경험상, 제안의 약 30%가 아주 가치 있다 — 이것만으로도 할 가치는 충분하다. 그에 맞게 파일을 고쳐라.
권고와 질문이 꾸준히 “트집 잡기” 범주에 들어가기 시작할 때까지 같은 과정을 되풀이하라.
7단계: 구현 준비도 점검
새 금붕어를 시작하고 이렇게 물어라:
“너는 우리 코드베이스에 익숙한 숙련된 소프트웨어 엔지니어다. 이 문서와 문서가 가리키는 파일들을 읽고 말하라: 이 기능을 첫 시도에 성공적으로 구현하는 데 필요한 정보가 이 문서에 정말로 전부 들어 있는가?”
질문을 하면 문서 안에서 답하라. 중요한 누락이나 풀리지 않은 모호함이 없다고 만족할 때까지 같은 과정을 되풀이하라.
마지막으로, 진짜 사람에게 보여 주고 리뷰와 승인을 받아라. (혼자 일한다면 이 선택지가 없을 수도 있다. 최선의 판단을 따르라.)
페이즈 4: 구현
8단계: 가드레일 안에서 코딩하기
이제야, 그리고 오직 지금에야 코드를 쓴다. 완성된 설계 문서를 AI에게 건네고 이렇게 말한다:
“이 설계 문서와 문서가 가리키는 파일들을 읽어라. 설명된 대로 기능을 구현하라. 계획을 정확히 따르라.”
문서가 모든 파일과 모든 변경을 명시적으로 나열하기 때문에, AI는 훨씬 높은 품질의 코드를 만들어 낸다. 구현 세션 도중에 AI가 헛돌거나 뻗어 버려도, 새 세션을 열어 설계 문서를 건네고 문서와 문서가 가리키는 모든 파일을 읽으라고 하면 곧바로 다시 일할 수 있다.
9단계: “독한” 코드 리뷰
코드가 다 되면 그것을 다시 AI에게 먹여라. 코드가 형편없는 구석을 모조리 찾으라고 하라. 나는 실제로 이렇게 말한다:
“이 코드의 품질이 형편없다는 강한 직감이 들어요. 갈기갈기 찢어발기고, 이 코드가 구린 점을 전부 말해 주세요.” (그렇다, 이게 내 실제 프롬프트다)
주석 없이 10줄을 넘긴 곳은 전부 표시하라고 하라. 엄격한 가독성을 요구하라.
비평이 사소해질 때까지(혹은 사라질 때까지) 같은 과정을 되풀이하라.
지금의 현실에서 부트스트랩하기(또는, “코끼리에게 땅콩과 건초 먹이기”)
이 이야기를 다른 엔지니어들에게 하면 그들이 맨 먼저 하는 말은 이렇다. “데이브, 새 프로젝트라면 그거 좋지. 그런데 내 코드베이스는 수백만 줄이야. 그 전부에 대해 설계 문서를 쓸 시간은 없어. 모놀리스를 위해 코끼리를 훈련시킬 수는 없다고.”
사실은 할 수 있다. 그리고 코드베이스가 아무리 크든 (거의) 상관없이 일주일쯤 걸린다.
요령은 코끼리를 먹이는 법을 이해하는 것이다. 비유를 좀 더 억지로 늘려 보자면, 소스 코드라는 정글 전체를 한꺼번에 AI에게 먹이려 하면 AI는 목이 막힌다. 맥락을 잃고, 헷갈리고, 환각을 일으킨다. 대신 땅콩과 건초를 먹여야 한다 — 작고, 영양가 높고, 압축된 맥락 조각들. (그렇다. 여전히 엔지니어다. 끔찍한 말장난까지 다 포함해서.. 하지만 적어도 이걸 보면 이 글을 사람이 썼다는 건 알 수 있다.)
그 “땅콩과 건초”가 README.md 파일이다. 재귀적 요약 과정을 통해 그것들을 거둬들이는 힘든 일은 AI에게 시키기만 하면 된다:
- 소스 트리의 잎에서 시작하라. 개발자마다 디렉터리 묶음을 하나씩 맡겨라.
- 땅콩 만들기: 각자 AI에게 디렉터리를 가리키고 이렇게 말하게 하라: “이 디렉터리의 파일들을 읽고 README.md라는 새 파일을 만들어라. 이 파일은 (a) 이 디렉터리와 그 안에 든 파일들의 목적을 설명하고 (b) 디렉터리 안의 파일을 하나씩 열거하며 각 파일의 기능을 짧게 설명해야 한다”
- 사람의 검증: 잎 디렉터리에서는 AI가 기댈 것이 코드뿐이라 약 50%는 틀린다. 맡은 엔지니어가 5~10분을 들여 파일 내용을 고친다.
- 건초 말아 올리기: 잎이 끝나면 한 단계 위로 올라간다:
“내 아래 모든 하위 디렉터리에 있는 README.md 파일을 전부 읽고, 그다음 이 디렉터리에 있는 코드만 읽은 뒤, 여기에 README.md라는 파일을 만들어 주세요. 그 정보를 바탕으로 이 파일은 (a) 이 디렉터리와 그 안에 든 파일들의 목적을 설명하고 (b) 디렉터리 안의 파일을 하나씩 열거하며 각 파일의 기능을 짧게 설명해야 합니다” - 계속 위로 올라가라 — 한 단계씩 — 프로젝트 루트에 닿을 때까지.
다 끝나면 훌륭한 맥락의 위계가 생긴다 — 그것이 “땅콩과 건초”다. 프로젝트 루트에서 새 세션을 열고 트리 안의 README만 코끼리에게 먹이면, 코끼리는 코드베이스를 (거의) 즉시 이해하고, 소스 파일을 하나하나 읽어야 할 때보다 컨텍스트 윈도를 훨씬 적게 쓴다.
완벽하지는 않겠지만, 놀랄 만큼 잘 이해한다. 주요 서브시스템과 설계 패턴을 믿을 만하게 짚어 낼 수 있을 것이고 — 변경을 하러 들어갈 때 그것은 엄청난 도움이 된다.
README는 얼마나 오래 필요한가?: README는 모든 코드 파일이 적어도 하나의 문서에서 언급(그리고 가볍게 설명)될 만큼 설계 문서가 쌓일 때까지만 있으면 된다. 파일 커버리지가 100%가 되면 README는 지워도 된다(안 지워도 된다. 당신 마음이다). 새 애플리케이션에 코끼리-금붕어 모델 프로세스를 쓰고 있고 설계 문서를 엄격하게 관리한다면, 이 README들은 아예 필요 없을 것이다.
거기서부터는 위의 코끼리-금붕어 프로세스로 새 기능의 설계 문서를 쓰기 시작하면 된다.
보너스 기능: 즉시 온보딩
소스 트리 전체가 README.md 파일의 위계 그리고/또는 탄탄한 설계 문서로 문서화되어 있으면 놀라운 부수 효과가 하나 있다. 새 엔지니어를 온보딩할 때 마찰이 아주 적어진다.
새 엔지니어가 팀에 합류한다면, 새 온보딩 절차는 이렇다:
- 새 NotebookLM 노트북(또는 원하는 비슷한 도구)을 만든다.
- README.md 파일의 위계 전체와 기존 설계 문서를 거기에 쏟아 넣는다.
- 시스템 지침에, 새 팀원이 시스템의 구체적으로 어느 부분에 집중할지 노트북에 알려 준다.
- 노트북을 엔지니어에게 건넨다.
첫 번째 일은 그 노트북을 써서 시스템을 충분히 배운 다음, 자기 첫 기능에 대한 훌륭한 설계 문서를 (위의 프로세스로) 쓰는 것이라고 말해 준다.
금붕어 시험을 통과하는 좋은 문서를 쓸 수 있게 되면, 그 사람이 코드베이스에 생산적으로 기여할 만큼 — 아니면 적어도 코드 리뷰에서 당신 시간을 낭비하지 않을 만큼 — 알고 있다고 안심해도 된다. 몇 주씩 선배 뒤를 따라다니거나 불투명한 레거시 코드를 역공학하려 애쓰는 일은 이제 없다.
누군가 내 받은편지함에 나타나 우리 도구에 새 기능을 제안하는 일은 흔하다. 2025년 이전이라면 그냥 백로그에 넣고 언젠가 처리했을 것이다. 하지만 이 접근법으로는 그냥 이렇게 묻는다. “코드를 짜 본 경험이 좀 있어?”
제품 관리자, 프로그램 관리자, 그 밖에 많은 사람이 적어도 약간의 코딩 경험은 있다. 그런 사람들에게는 새 노트북을 준비해 주고, 그것을 써서 원하는 기능의 설계 문서를 써 보라고 한다.
(보통) 며칠 뒤면 새 설계 문서가 내 리뷰 대기열에 올라온다. 대개 약 70~80%는 맞아서, 나는 그것을 리뷰하고 개선 방법을 제안한다. 한두 번 더 주고받으면 우리 품질 기준을 충족하게 된다.
그 기준을 충족하고 나면, 그들이 AI로 만드는 코드가 결국 우리 소스 트리에 들어가리라고 안심할 수 있다. 물론 전부 평소처럼 리뷰를 거치지만, 슬롭은 아닐 것이다 — 그러니 시간 낭비가 아니라는 뜻이다.
속도 때문에 와서, 이해 때문에 머문다
우리는 IDE에 문법을 타이핑하는 일이 더 이상 소프트웨어 엔지니어의 주된 일이 아닌 세상으로 들어가고 있다. 일은 의도다. 일은 아키텍처다. 일은 설계 판단이다.
사람이 읽을 수 있고 엄격하게 시험한 문서 안으로 그 설계 판단들을 밀어 넣지 않은 채 코드 작성을 전적으로 AI에 기댄다면, 우리가 책임지고 서야 할 작업에 자신 있게 이름을 걸 능력을 잃게 된다. 결국 에이전트가 한 모든 행동의 책임은 사람이 지게 되는데, 우리 지시로 에이전트가 만든 시스템을 우리가 제대로 이해하지 못한다면 그 위험을 떠안으라고 기대하는 것은 합리적이지 않다.
하지만 설계를 새로운 코드로 대하면, 이해를 바라는 인간의 필요와 AI의 속도 역량이 한 줄로 맞춰진다. 이것이야말로 궁극의 위험 줄이기 작업이다.
3부: 아마 틀릴 몇 가지 예측
“예측은 어렵다. 특히 미래에 관한 예측은.”
― 요기 베라(Yogi Berra)
이 분야는 너무 빨리 움직이고 있어서 어떤 예측이든 하는 것 자체가 아마 실수일 테지만, 그래도 나는 예측을 하려 한다. 무엇이 오든 헤쳐 나가는 데 쓸 수 있는 오래가는 패턴의 윤곽이 몇 가지 보인다고 생각하지만, 틀릴 수도 있으니 아주 건강한 회의심을 품고 읽어 주기 바란다.
이제 우리는 모두 관리자다
지금의 질서에서는 직원을 관리하면 “피플 매니저”, 그렇지 않으면 “개인 기여자(individual contributor, IC)”라고 불린다. 내가 보기에 이 구분은 올해 몹시 흐릿해질 것이다.
도구와 모델이 더 유능해지면서, 우리는 모두 우리 대신 일하는 에이전트를 몇이든 관리하기 시작할 것이다. 이미 경험 많은 피플 매니저라면 꽤 쉽게 적응할 것이다. 하지만 다른 사람을 관리해 본 적이 없다면, 새로운 (그리고 아주 쓸모 있는) 기술을 몇 가지 배워야 한다.
겉보기에는 사람을 관리하는 일과 AI 에이전트를 관리하는 일이 아주 다를 것 같다. 하지만 나는 둘이 생각보다 훨씬 많이 겹친다고 주장하고 싶다.
AI 에이전트는 사람이 아니다 — 하지만 가끔은 운이 맞는다
관리의 목적은 자신의 판단력과 전문성을, 혼자 해낼 수 있는 일을 훨씬 넘어서는 곳까지 지렛대로 늘리는 것이다.
나쁜 관리자라면 직원에게 자잘한 일 하나하나를 할 때 밟아야 할 단계를 정확히 지시한다. 우리는 이것을 마이크로매니징이라 부르고, 겪어 본 사람이라면 누구나 이것이 규모를 키울 수 없고 원하는 결과를 내는 일도 드물다는 것을 안다.
반면 좋은 관리자는 직원에게 자기가 바라는 결과가 무엇인지 말하고, 가드레일과 지침을 준다. 직원이 움직일 수 있는 권한의 범위와 자유도를 분명히 설명하고, 어떤 조건에서는 멈추고 지침을 구하기를 바라는지도 분명히 설명한다.
직원에게서 한동안 눈을 뗐다가 다시 봤을 때 일이 제대로 굴러가고 있다면, 관리자로서 잘하고 있는 것이다. 눈을 뗄 수 있는 시간이 길수록 직원을 더 잘 키우고 있는 것이다. 그 시간이 길어질수록 한 사람당 드는 간접비가 줄어드니 사람을 더 늘릴 수 있다.
이것이 AI 에이전트 관리에 어떻게 들어맞는지는 눈을 가늘게 뜨고 애써 볼 필요도 없다고 생각한다. 물론 경력 계획까지 세워 줄 필요는 없지만, 다른 점보다 비슷한 점이 훨씬 많다고 말하고 싶다.
몇 가지 실용적인 조언
이 전제가 완전히 정신 나간 소리는 아니라고 생각하고 지금 IC라면, 무엇을 해야 할까?
기본적인 피플 매니지먼트 강좌를 들어라. 지금 당장. 진짜로.
이상한 조언처럼 보일 수 있지만, 내 말을 들어 보라…
관리의 목적은 당신 판단의 영향력을 하루에 혼자 해낼 수 있는 일 너머로 확대하는 것이다. 직원에게서 한동안 눈을 떼고도 다시 들여다볼 때 일이 제대로 굴러가 있으리라고 확신할 수 있다면 좋은 관리자다.
직원들이 성공하도록 잘 준비시키고 있다는 증거는, 성공적으로 눈을 뗄 수 있는 시간이 갈수록 늘어난다는 것이다. 그렇게 되면 직원 한 명당 당신에게 지워지는 개인적인 간접비가 줄어든다. 즉 인터럽트에 잡아먹혀 번아웃되지 않고도 더 많은 직원을 성공적으로 맡을 수 있다는 뜻이다.
당신 대신 행동하는 독립된 주체들 전반으로 판단을 성공적으로 확장하는 법을 배우는 것은 훈련과 연습이 필요한 기술이다. AI 에이전트 관리의 시대가 이미 와 있고, 지금 이 능력을 쌓기 시작해야 한다.
많은 회사가 처음 관리자가 된 사람을 위한 사내 교육을 두고 있고, 거기서는 위임·조율·오케스트레이션을 구체적으로 다룬다. 그런 강좌에 등록하라. 지금 고용주가 그런 강좌를 제공하지 않는다면 책을 사든, 유튜브 영상을 보든, 온라인 강좌를 듣든, 어쨌든 무언가를 하라.
내가 줄 또 하나의 조언은 한 번에 관리하려는 에이전트 수를 천천히 늘려 가라는 것이다.
처음 피플 매니저가 되면 보통 3~5명짜리 작은 팀을 맡는다. 그 이유는 사람을 관리한다는 것이, 인터럽트에 압도당하지 않도록 목표와 인센티브와 기본 규칙을 정하는 법을 배우는 일이기 때문이다.
이 경험칙은 에이전트를 통해 판단을 매끄럽게 확장하는 법을 배울 때 처음 겨냥할 좋은 목표로 보인다. 새 운동을 시작할 때와 조금 비슷하다. 천천히 시작하고, 올바른 자세를 몸에 익힌 다음, 거기서부터 늘려 가라.
지속적인 집중은 길러야 하는 근육이다
AI는 상태 보고서나 진행 상황 회의 같은, 일의 고된 잡무 일부를 꾸준히 흡수하고 있다. 정말로 좋은 소식이다. 하지만 이것은 질문을 낳는다. 되찾은 시간으로 무엇을 할 것인가?
답은 우리가 늘 시간이 모자라 하지 못했던 일이다. 깊이 생각하기. 진짜 설계. 동료에게도 모델에게도 위임할 수 없는 종류의 판단.
문제는 지속적인 집중이 우리 대부분이 기를 기회가 없었던 기술이라는 점이다. 역량이 모자라서가 아니라, 현대 사회가 우리 주의를 차지하려고 경쟁하는 것들로 우리를 방해하기를 좋아하기 때문이다.
집중력을 기르는 것은 다른 어떤 지구력을 기르는 것과도 같다. 오래 집중해서 생각하는 데 익숙하지 않다면, 두 시간으로 시작하는 것은 첫날 10킬로미터를 달리는 것과 같다. 더 나은 출발점은 근무일마다 30~45분 동안 한 문제에 세게 집중하는 것이다. 매주 초에 5~10분씩 늘려라. 몇 달이면 한 번에 2시간(그 이상)씩 집중할 수 있는 정신적 지구력이 생긴다.
이것은 모두가 길러야 하는 근육이다. 수도원 같은 침묵 속에 앉아 있을 필요는 없다. 그 시간에 작업 중인 문제를 놓고 AI 도구와 토론해도 좋다. 요점은 생각하고 토론해서 어느 정도의 정신적 피로에 이르는 것이다. 지친 뇌는 지친 이두근과 똑같이 성장의 신호다.
AI가 우리 잡무를 잔뜩 가져가면, 그냥 다 같이 덜 일하게 된다는 뜻 아닌가? 아니다.
AI가 일을 아주 효율적으로 만들어 줘서 하루 몇 시간만 일하면 될 거라고 바랄지도 모른다. 하지만 역사가 보여 주듯, 도구가 일을 쉽게 만들어도 우리가 꼭 덜 일하지는 않는다 — 그 노력의 비용이 떨어졌기 때문에 결국 더 많이 하게 될 뿐이다. 이것은 제번스의 역설이라고 알려진, 오래전부터 관찰된 현상이다.
마지막 생각
윌리엄 제번스(William Jevons)와 그의 유명한 역설 이야기가 나온 김에, 나는 가끔 학생들과 젊은 동료들에게서 AI 때문에 길고 보람 있는 경력을 가질 수 없게 될까 걱정하는 소리를 듣는다. 일상의 업무가 어느 정도 바뀌는 것은 사실일 수 있지만, 그렇다고 우리가 목적도 가치도 없어진다는 뜻은 아니다. 이런 종류의 변화는 내가 일을 해 온 내내 늘 있었다.
당신의 가치는 당신이 익히고 성공적으로 적용하는 판단에 있다. 자기 영역에서 더 나은 안목을 기르고 그것을 확장하는 법을 더 많이 배울수록, 당신을 찾는 수요는 커진다. 이것은 언제나 사실이었고, 앞으로도 언제나 사실일 것이라고 생각한다.
이 AI들은 이미 아주 강력한 도구다. 장인처럼 쓰는 법을 배우면 당신의 기술을 찾는 수요가 모자랄 일은 없을 것이다. 어려울까? 물론이다. 하지만 그것은 산처럼 어려운 게 아니라 언덕처럼 어려운 것이다. 그러니 그냥 걷기 시작하라.
이 글이 세상에 나오도록 귀중한 도움을 준 동료들에게 감사를 전하고 싶다. 애초에 이런 것들을 글로 적으라고 나를 떠민 엘리스 유잉(Elise Ewing), 그리고 초고를 끈기 있게 읽고 사려 깊은 편집 제안을 해 준 앰버 허프먼(Amber Huffman)과 파사 랑가나탄(Partha Ranganathan)에게.