EP1. 같은 LLM, 다른 결과
"ChatGPT야, 로그인 모듈 좀 짜줘!"
개발자라면 하루에도 몇 번씩 던지는 이 요청. 똑같은 Claude, 똑같은 GPT를 붙잡고 말이다.
그런데 신기하게도 결과는 전혀 다르게 흘러간다. 어떤 사람은 AI가 준 코드를 복사·붙여넣기 하다가 밤을 새우고, 어떤 사람은 마치 10명짜리 천재 개발팀을 지휘하듯 여유롭게 원하는 결과물을 뽑아낸다.
도구는 완전히 똑같다. 대체 왜 이런 차이가 생기는 걸까?
이 질문에 대한 답을 찾는 것이 오늘 이야기의 시작이다.
🚨 A님의 하루 — "AI가 시키는 대로"
바쁜 주니어 개발자 A님. 오늘도 마감에 쫓기고 있다. 급한 마음에 AI에게 요청한다.
"로그인 모듈 추가해줘."
AI가 순식간에 그럴듯한 코드를 내놓는다. A님은 깊은 고민 없이 그대로 프로젝트에 붙여넣는다. "AI가 잘 짰겠지, 뭐." 당장은 잘 돌아가니 다행이다 싶어 가슴을 쓸어내린다.
하지만 진짜 문제는 일주일 뒤에 터진다.
보안 리뷰에서 세션 관리에 취약점이 발견됐다거나, 다른 모듈과 인터페이스가 안 맞는다는 경고가 날아온다. 결국 A님은 코드를 이해하지 못한 채 붙여넣었기 때문에, 밤을 새워가며 처음부터 다시 갈아엎어야 했다.
코드는 늘어났지만, 정작 A님의 머릿속에는 '모르는 것'만 눈덩이처럼 쌓여갔다.
여기서 드는 생각, 없으신가요? "아, 나도 가끔 이렇게 하는데..."
🤝 B님의 방식 — "AI와 함께 고민한다"
똑같은 연차의 B님도 로그인 모듈이 필요하다. 하지만 AI를 대하는 방식이 완전히 다르다.
"우리 프로젝트는 사용자가 10만 명 정도고 보안이 철저해야 해. 먼저 적용할 수 있는 인증 방식들을 제안해 주고, 각각 장단점을 비교해 줘."
AI가 세션 기반, JWT 토큰 기반, OAuth 2.0 등 다양한 선택지를 제시하자, B님은 AI와 티키타카를 주고받으며 우리 프로젝트의 미래(모바일 앱 확장성 등)까지 고려한 최적의 구조를 함께 설계한다.
한 시간 치열한 논의 끝에 구조를 확정 짓고 나서야 비로소 코드를 요청한다. B님이 받은 코드는 A님의 것과 겉보기엔 비슷할지 모른다. 하지만 B님은 이 코드가 왜 이렇게 짜였는지, 에러 처리는 왜 이 패턴인지, 모든 설계 이유를 완벽하게 이해하고 있다.
이게 무슨 차이일까? 기술의 차이? LLM 버전의 차이? 아니다. 바로 태도의 차이다.
🔍 AI-assisted Engineer vs AI-native Engineer
A님과 B님의 차이는 단순한 실력 차이가 아니라, AI를 대하는 방식의 차이다.
| AI-assisted Engineer | AI-native Engineer | |
|---|---|---|
| AI의 역할 | 나를 도와주는 도구 (계산기처럼) | 일을 수행하는 팀원 |
| 사용자의 역할 | AI의 도움을 받아 직접 수행 | 지시하고, 검토하고, 승인 |
| 검토 방식 | "AI가 잘 짰겠지" → 그냥 넘어감 | "내가 이해했는가?" → 검토 후 승인 |
| 결과 | 코드↑, 이해도↓, 무지↑ | 코드↑, 이해도↑, 역량↑ |
A님은 AI-assisted Engineer다. AI는 나를 도와주는 도구일 뿐이다. 계산기 같은 보조 도구. 필요할 때 쓰고 만다.
B님은 AI-native Engineer다. AI가 일을 수행하고, 내가 리더로서 AI 팀원을 이끈다. 나는 지시하고, AI가 수행하며, 그 결과를 내가 검토하고 이해하고 분석하고 평가한 후에야 승인한다. AI는 도구가 아니라 나를 대신해 일하는 팀원이다.
AI를 도구로 보느냐, 팀원으로 보느냐. 이것이 AI-assisted와 AI-native를 가르는 기준이다.
💡 "진짜 가능할까?" — OpenAI가 증명한 현실
여기서 많은 엔지니어들이 이렇게 말한다.
"아니, AI한테 일을 맡기고 내가 검토만 한다고? 그게 진짜 가능해?"
정말 자연스러운 의문이다. 하지만 이것에 대한 명확한 답변이 있다.
가능하다. 이미 현실에서 증명되었다.
올해 4월, OpenAI의 Ryan Lopopolo라는 엔지니어가 발표한 내용이다.
- 3명의 엔지니어가 5개월 동안 100만 줄의 프로덕션 코드를 구축했다.
- 그리고 중요한 건... 단 한 줄도 직접 작성하지 않았다는 점이다.
- 전통적인 개발 방식보다 10배 빠른 속도였다.
이 팀은 Symphony라는 시스템으로 여러 AI 코딩 에이전트들을 자율적으로 운용했다. 인간의 역할은 무엇이었을까? Architect & Gardener. 시스템을 설계하고, AI가 생성한 결과를 검토하는 가드너였다.
Lopopolo는 자신들의 역할을 이렇게 표현했다.
"500명 규모의 조직을 이끄는 그룹 테크 리드"
3명이 500명 조직의 생산성을 낸 것이다. 이것이 AI-native Engineer의 실제 모습이다.
🎯 당신의 AI는 몇 명의 팀원입니까?
AI-native 방식이 가능하다는 것을 확인했다. 그렇다면 이제 질문이 달라진다.
더 이상 *"가능할까?"*가 아니다. 이제 던져야 할 질문은 이것이다.
"당신의 AI는 몇 명의 팀원입니까?"
AI-native 방식으로 일한다는 건, AI를 팀원으로 활용한다는 뜻이다.
- 1명? — 1명 분량의 업무를 AI에게 위임하고 검토할 수 있다.
- 4명? — 4명 분량의 업무를 AI에게 위임하고 검토할 수 있다.
- 10명? 20명? — 소규모 팀을 리드하듯 AI 팀원들을 운용할 수 있다.
당신은 몇 명의 AI 팀원을 리딩해서 업무를 수행하고 있나요? 아니, 몇 명의 AI 팀원을 리딩해서 업무를 수행할 수 있습니까?
결국 당신의 역량이 중요하다. 팀장의 역량에 따라 관리할 수 있는 팀원의 규모가 달라지듯, AI-native Engineer의 역량에 따라 AI 팀원의 규모가 달라진다.
그렇다면, 어떻게 이 역량을 키울 수 있을까?
🦉 Cocrates Harness — 상호 소크라테스 관계
Cocrates는 여러분이 AI-native Engineer가 되도록 도와주는 에이전트 하네스다.
Cocrates는 Co + Socrates다. 상호 소크라테스 역할을 한다는 의미다.
당신은 AI에게 소크라테스가 된다.
AI는 확률적으로 가장 그럴듯한 답변을 생성할 뿐이다. 당신이 질문하고, 검토하고, 판단해서 AI가 잘못된 것을 생성하지 않도록 막아야 한다. 이것이 바로 AI-native Engineer의 핵심 역량이다.
AI도 당신에게 소크라테스가 된다.
당신이 AI에게 막연한 요청을 하거나 AI의 산출물을 이해하지 못한 채 승인하지 않도록 한다. 당신이 대충 알고 넘어가는 것을 제대로 이해하도록 한다. 소크라테스처럼 당신의 무지를 알게 하고, 당신 스스로 역량을 키우도록 한다.
Cocrates는 바로 이렇게 "상호 소크라테스 관계"로 AI를 사용하게 하는 에이전트 하네스다. 이것이 AI-native Engineer로서 AI 팀원을 이끄는 도구이며, AI를 올바르게 사용하는 방법이다.
📌 오늘의 핵심
- 같은 LLM, 다른 결과. AI의 성능이 아니라, AI를 대하는 당신의 방식이 결과의 차이를 만든다.
- AI-native Engineer. AI에게 일을 지시하고, 그 결과를 검토하고, 승인하는 사람. 검토와 승인이 AI-assisted와 AI-native를 가르는 기준이다.
- "당신의 AI는 몇 명의 팀원입니까?" 이 질문에 대한 답은 당신의 역량에 달려 있다. 1명일 수도, 10명일 수도 있다. 중요한 것은 당신의 역량이다.
잠시 스스로에게 질문을 던져보시길 권한다.
- "지금 나는 AI-native Engineer인가? 아니면, 아직 AI-assisted Engineer인가?"
- "오늘 내가 AI에게 한 요청 중에, AI-native 방식으로 검토한 것은 몇 개나 되는가?"
AI-native Engineer의 첫걸음은 자기 인식에서 시작한다.
🎬 다음 편 예고
오늘 우리는 *'무엇'*이 문제인지 알게 되었다. 바로 태도였다. AI-assisted Engineer와 AI-native Engineer의 차이는 기술이 아니라 태도의 차이였다.
그렇다면, AI-native Engineer가 되기 위해 꼭 필요한 핵심 역량은 무엇일까?
바로 검토다. AI가 한 일을 이해하고, 분석하고, 평가하고, 승인하는 것. 이 검토라는 행위가 AI-native Engineer의 가장 중요한 업무다.
다음 편에서는 이 시리즈를 관통하는 강력한 원칙을 선언한다.
"The unexamined code is not worth generating." (검토되지 않은 산출물은 생성할 가치가 없다.)
이 한 문장이 왜 AI-native Engineer의 무기가 되는지, '검토한다'는 행위의 진짜 본질은 무엇인지, 다음 편에서 낱낱이 파헤쳐 보겠다.
이 시리즈는 Cocrates Harness 프레임워크를 소개합니다. Cocrates는 소크라테스식 대화로 사용자가 주도권을 잡고 성장하도록 설계된 에이전트 하네스입니다.