
「AI 도구를 만든 본인이 오히려 편해지지 않았다고 말한다」 opencode 제작자 Dax Raad의 이야기 요점 해설
요약
opencode 제작자 Dax Raad가 AI 코딩 도구 도입이 실제 개발 효율과 제품 품질에 미치는 역설적인 영향을 설명합니다. 코딩 속도는 빨라졌지만, 무엇을 만들지 결정하는 판단의 병목 현상과 기술적 부채 문제는 오히려 심화될 수 있음을 경고합니다.
핵심 포인트
- 코딩 속도 향상이 전체 개발 프로세스의 속도 향상으로 직결되지 않음
- 타이핑은 병목이 아니며, 의사결정과 설계가 진정한 병목임
- 무분별한 기능 출하는 제품의 일관성을 해치고 유지보수 비용을 높임
- AI로 인해 만드는 비용은 낮아졌으나, 잘못된 판단의 비용은 제품에 축적됨
이 기사에 대하여
AI 코딩 도구 opencode (및 SST)의 제작자인 Dax Raad가 The Pragmatic Engineer 팟캐스트에서 이야기한 내용을 요점만 뽑아 한국어로 해설합니다.
가장 가슴에 와닿았던 것은, 시작 직후의 이 한마디였습니다.
"매일 사용하고 있고, 워크플로 (Workflow)의 핵심이기도 합니다. 하지만,
예전부터 고민하던 문제는 여전히 남아 있습니다."
AI 코딩 도구를 직접 만들고 있는 사람이 "AI로 인해 편해진 것 같지 않다"라고 말합니다. 이번 회차는 거기서부터 시작하여, 왜 그렇게 되는지를 깊이 파고듭니다.
테마 1: 왜 "편해진 것 같지 않다"고 느끼는가
Dax의 이야기는 많은 엔지니어가 막연하게 느끼고 있는 위화감을 언어화하는 것에서 시작됩니다.
- 확실히 많은 작업이 편해졌다. 객관적으로 보았을 때 쉬워진 것은 틀림없다. - 그런데 "왜 이전만큼 머리를 쓰고 있는 것일까"라는 감각이 사라지지 않는다. - "그 두 가지가 동시에 성립하는 것이 이상한 감각이다."
그리고 경영진과의 인식 차이를 지적합니다. CEO, CTO, 창업자와 같은 의사 결정자들은 이렇게 생각합니다——"코딩은 과거에 난관이었고 방대한 시간을 잡아먹었다. 가장 시간을 많이 쓰던 부분이 빨라졌으니, 전체도 빨라질 것이다".
하지만 실제로는 그렇지 않습니다.
▶ 해당 클립 (영상은 TikTok @talks.tldr.jp에서 순차 공개):
- "AI 도구 제작자가 말하는 'AI로 편해진 것 같지 않다'는 진실"
- "AI 코딩 도구의 불편한 진실"
필자의 견해: 이 부분이 가장 핵심이라고 생각했습니다. "코딩이 유일한 병목 현상 (Bottleneck)이었다"라는 전제 자체가 애초에 틀렸던 것입니다. 타이핑은 속도를 제한하는 단계 (Rate-limiting step)가 아니었던 것입니다. 따라서 가장 빠르게 칠 수 있게 되어도 전체 속도는 빨라지지 않습니다.
그리고 Dax는 경영진에게 잔혹할 수 있는 가능성을 하나 더 제시합니다. **"작업량은 같더라도 엔지니어가 행복해지는 결말도 있을 수 있다. 하지만 그것만으로는 많은 기업에 충분하지 않다"**라고 말이죠. AI 도입의 투자 대비 효과 (ROI)를 "행복도"로 회수할 수 있는 회사는 많지 않습니다.
테마 2: 출하 속도가 10배 빨라져도, 좋은 아이디어가 10배가 되지는 않는다
다음은 AI로 초고속 개발을 한 결과 어떻게 되었는지에 대한 실패담입니다. Dax는 다음과 같은 루프를 돌렸다고 합니다.
- 경쟁사가 기능을 출시했다 → 에이전트 (Agent)에게 프롬프트 (Prompt)
- 사용자가 문제를 보고했다 → 에이전트에게 프롬프트
- 이를 반복한다
결과적으로, 1000개의 기능을 출하한 것 같은 기분이 든다. 하지만 만들어진 것은,
"실제로는 최악의 프로덕트가 됩니다. 무엇 하나 일관성이 없습니다."
더 까다로운 점은 기능에는 **영속적 비용 (Perpetual cost)**이 따른다는 점입니다. "한 번 출시하면 영원히 지원해야 한다. 장래에 만드는 어떤 기능도 그것과 간섭한다."
그리고 결론은 이것입니다.
"출하가 10배 빨라진다고 해서, 좋은 아이디어가 10배 있는 것은 아니다."
▶ 해당 클립:
- "AI로 기능을 1000개 출하 → 최악의 제품이 완성된 이야기"
필자의 견해: 이 문장이 테마 1의 답이 되고 있다고 생각했습니다. 빨라진 것은 "만드는 것"뿐이며, "무엇을 만들지 결정하는 것"은 빨라지지 않았다. 오히려 만드는 비용이 저렴해진 만큼, 판단의 잘못됨이 그대로 제품에 쌓이게 됩니다. 병목 현상이 이동했을 뿐이라는 이야기입니다.
테마 3: 기술적 부채 (Technical Debt)의 "죄책감"이 사라져 간다
개인적으로 가장 소름 끼쳤던 테마입니다. Dax는 AI 도입 이전과 이후로 자신의 내면이 변했다는 것을 1인칭으로 이야기합니다.
AI 도입 이전, 해킹 (Hack, 임시방편의 조잡한 코드)을 작성할 때 엔지니어는 다음과 같은 상태였습니다——
- 자신이 해킹을 하고 있다는 것을 알고 있다 - 제대로 생각한다. 죄책감을 느낀다. 정말 싫은 기분이 든다 - 두 번째 해킹을 하면 첫 번째를 떠올리며 더욱 기분이 나빠진다
- 왜 싫은가 하면, 경험이 있고 고생을 해봤기 때문이다. **"다른 사람을 위해 지뢰를 매설하고 있다. 내가 밟을지도 모른다"**는 것을 알고 있기 때문이다.
에이전트는 어떨까요?
"에이전트는 그냥 해버립니다. 감정이 없으니까요. 노력도 사고도 생략해 버립니다. '해킹을 하고 있습니다'라고 말조차 하지 않습니다. 자신이 해킹을 하고 있다는 것조차 깨닫지 못합니다. 그저 학습 데이터에 따를 뿐입니다. 그것은 인터넷상의 저품질 코드입니다."
그리고 인간 측에도 변화가 일어납니다.
"
그 불쾌했던 감각이 지금은 희미해졌어요. 다른 사람에게 맡긴 느낌이 들기 때문일까요. 문제를 남에게 떠넘겼다는 기분이랄까. 문제는 아직 남아있고, 지뢰는 언젠가 터질 거예요. 하지만 그 싫었던 감각을 이제는 별로 느끼지 못해요. 그래서 판단이 흐트러져요. 피드백 루프(feedback loop)가 작동하지 않는 거죠.
▶ 해당 클립:
- "AI 에이전트가 '기술적 부채의 죄책감'을 사라지게 한다"
필자의 견해: 죄책감을 '비효율적인 감정'이 아니라 **피드백 메커니즘(feedback mechanism)**으로 파악한 점이 날카롭다고 생각했습니다. 그 싫었던 감각은, 미래의 자신(혹은 동료)가 밟을 지뢰에 대한 고통의 선지급입니다. 그것이 사라졌다는 것은, 지뢰가 사라진 것이 아니라, 경보기만 꺼진 것이라는 의미입니다. 부채는 조용히 쌓여갑니다.
AI 생산성 논의는 '얼마나 빨라졌는지'에 집중하는 경향이 있지만, 판단의 질이 측정되지 않은 채로 저하될 수 있다는 위험성은 충분히 다뤄지지 않은 것 같습니다.
주제 4: 예측이 넘쳐나는 시대의 읽는 법
약간 다른 내용이지만, SNS에서 유행한 '연령별 AI 예측'(24~29세가 가장 유리하다는 식의 것)에 대한 반론도 포함되어 있습니다.
"매일 아침 피드를 열면 예측이 끝없이 늘어서 있어요. 모두 대충 꾸며낸 것뿐이에요."
Dax가 지적하는 것은, 유행하는 예측의 구조입니다.
- "나 같은 사람이 전부 유리하고", "나와 다른 사람은 전부 불리하다"
- 마치
자신에게 되뇌는 만트라(mantra) 같아서 - 결국에는 항상 "우리 회사는 성공할 거야", "다른 회사는 실패할 거야",
**"내 일은 AI에 빼앗기지 않지만, 모두의 일은 빼앗길 거야"**라는 결론으로 귀결됩니다.
그 근본에는, 거대한 변화 속에서 자신의 위치가 어떻게 될지 아무도 불안해한다는 것이 있습니다. 방어 본능으로서 '내가 이기는 미래'를 자신만만하게 주장하는 것에 지나지 않는다고 말입니다.
▶ 해당 클립:
- "'24~29세가 최고' 논리에 건설가가 반론하는 이유"
필자의 견해: 예측을 읽을 때는 내용보다 '이 사람이 이기는 미래로 만들고 있는가'를 보는 실용적인 필터라고 생각했습니다. 포지셔닝 토크(positioning talk) 감지기 역할을 하는 데 매우 유용합니다. ……그리고, 이런 글을 쓰고 있는 저 자신에게도 그대로 적용됩니다.
주제 5: DevTools와 제품에 대한 이야기
남은 내용은, 도구를 만드는 사람의 시점입니다.
"DevTools는 B2C 제품이다" — DevTools를 만드는 사람은 모두 프로그래머이고, 그리고 프로그래머는 B2C(소비자 대상)가 서투르다. 탑다운 방식의 영업형으로도 성공할 수는 있지만, '표준'이라고 불릴 만큼 보급된 DevTools는 모두 바텀업(bottom-up) 방식으로, 개별 개발자들이 사용해보고 마음에 들어서 퍼져나가는 것입니다. 그러니 Instagram 같은 SNS 앱을 런칭하는 감각으로 접근해야 한다고 말합니다.
'일시적인 악역' 전략 — 대형 플랫폼에 대한 의존에서 벗어나기 위해, 공통의 가상 적(仮想敵) 하나를 세워 경쟁사들을 한데 모으는 전략도 언급됩니다. 작은 회사라도 상황에 따라 쓸 수 있는 방법이라고 합니다.
'덤'이 크게 성장한 이야기 — 온보딩 개선을 위해 만든 추론 서비스가, 5~6개월 만에 **연간 환산 $15M(약 25억 원)의 랜 레이트(run rate)**에 도달했다는 에피소드도 나옵니다. 오픈소스 모델은 수익률도 좋고, 예상치 못하게 중요한 기둥이 되었다고 합니다.
▶ 해당 클립:
- "DevTools로 승리하는 비결: 프로그래머는 B2C에 약하다"
- "작은 회사가 대형 플랫폼 의존에서 벗어나는 전략 — 경쟁사를 아군으로 만들기"
- "덤으로 만든 기능이 연간 환산 25억 원 페이스가 된 이야기"
주제 6: AI의 도움을 받을 수 없었던 유일한 것
마지막으로, 엔지니어 경력에 가장 실용적인 이야기가 나옵니다. '제품 감각(Product Sense)'만큼은 AI가 도와주지 못했다고 Dax는 말합니다.
"프로덕트의 일은 문제를 받고 바로 해결책을 내놓는 것이 아니에요.
모든 문제를 흡수해서, 하나의 해결책으로 50개의 문제를 해결할 수 있다는 것을 깨닫는 거예요."
그것에 필요한 것은 경험, 깊이 생각하는 것, 사용자와 이야기하는 것, 팀과 이야기하는 것, 코드베이스를 이해하는 것입니다. 프로덕트는 많은 문제들에 대한 해결책을 추상화한 것이기 때문입니다.
그리고 이렇게 이어집니다.
"그것은 항상 어렵습니다. 하지만
무한히 향상시킬 수 있는 기술이기도 해요. 저는 예전에 매우 어려워했어요. 지금은 그럭저럭 할 수 있을 정도예요. 앞으로 몇십 년 동안 성장할 거예요. ……AI는 전혀 도움이 되지 않았어요"
▶ 해당 클립:
- "AI가 발전해도 '제품 감각'만은 향상시킬 수 있다"
필자의 견해: 「AI에게 빼앗기지 않는 기술」을 다루는 기사는 무수히 많지만, 도구를 만들고 있는 본인이 "이것만큼은 AI가 도와주지 않았다"라고 실감에 기반해 말하는 것은 무게감이 달랐습니다. 게다가 "무한히 향상될 수 있다"라고 덧붙인 점이 좋습니다. 빼앗기지 않아서 안전한 것이 아니라, 투자하면 계속 성장하기 때문에 가치가 있다는 이야기입니다.
요약
이번 회차를 관통하는 것은, **"AI는 코드를 작성하는 속도는 높였지만, '무엇을 만들지 결정하는 능력'과 '잘못되었다고 깨닫는 감각'은 높이지 않았다. 오히려 후자는 약해지고 있다"**라는 일관된 관찰이었습니다.
- 테마 1·2: 빨라진 것은 "만드는 것"뿐.
- 병목 현상은 판단으로 이동했다 - 테마 3:
- 잘못되었다고 깨닫는 감각(죄책감)이 사라져, 피드백 루프 (Feedback Loop)가 깨져 있다 - 테마 6: 그렇기에,
- 문제를 묶어 추상화하는 능력이 남겨진 투자처가 된다
그리고 전체를 통틀어 가장 강력하게 작용했던 것은, 이 말을 하는 사람이 AI 코딩 도구를 직접 만든 사람이라는 사실이었습니다. "AI는 만능이 아니다"라고 외부인이 말하는 것과, 제작자가 "매일 사용하고 있지만 편해졌다는 느낌이 들지 않는다"라고 말하는 것은 무게감이 완전히 다릅니다.
- 원본 영상: Dax Raad "Building OpenCode with Dax Raad" (The Pragmatic Engineer)
- 클립 영상 보기: TikTok @talks.tldr.jp
- 관련 기사 (게시 전 예측): 이 영상의 9개 클립 중 어떤 것이 인기를 끌지 게시 전에 예측했습니다 → #20 게시 전 예측
- 지난 해설: #19 Gergely Orosz 「감속하여 가속하라」
해외 Tech Talk를 매번 이렇게 일본어 클립 + 요점 기사로 만들고 있습니다. 제작 뒷이야기(Claude Code로 구축한 자동화 파이프라인)에 대해서도 별도로 정리해 두었습니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기