그러던 중 2025년 11월 말 클로드 코드 토큰 사용량으로 전 세계 1위를 찍은 개발자 박진형 님을 초청해 라이트 토크를 진행하기도 했는데요. “함께한다는 시간 자체로 영감을 얻어간다” “새로운 시각!”이라고 호평을 받았습니다. 아쉽게도 참석하지 못한 분들을 위해 그날의 핵심 내용을 정리해 콘텐츠로 다시 전해드립니다. 세션을 진행한 지 약 3개월이 지난 시점이라, 현재 상황과 조금 다를 수 있습니다.

"토큰을 많이 쓴다고 좋은 건 아니에요"

안녕하세요, 사이오닉AI라는 회사에서 머신러닝 엔지니어를 하고 있는 박진형입니다. 사이오닉AI는 B2B 엔터프라이즈용 AI 에이전트를 만들 수 있는 솔루션을 개발하는 곳이에요. 저는 사실 스스로를 머신러닝 엔지니어보다는, 울트라씽크(Ultrathink) 엔지니어라는 표현을 씁니다. Instruct.KR이라는 AI 개발자/연구자를 위한 오픈소스 커뮤니티도 운영 중입니다.

지난 8월 23일에 바이브랭크에서 세계 1위를 기록했는데요, 이 기록은 사실 1월부터 누적한 사용량을 기준으로 한 것입니다. 사람들이 토큰 수와 금액을 보고 놀라시는데, 몇 가지 오해가 있는 것 같아서 말씀드리고 싶어요.

비용의 오해: 15억 토큰을 썼다고 15억 원을 낸 건 아닙니다. 당시 무제한이었던 맥스 플랜(월 200달러)을 최대한 활용했을 뿐입니다.
성능의 오해: 토큰을 많이 쓰는 것 자체가 실력은 아닙니다. AI 코딩의 핵심은 '얼마나 빨리 결과를 꺼내 사람과 피드백 루프를 도는가'에 있습니다. 토큰 소모가 많다는 건 오히려 워크플로우가 정교하지 못하다는 반증일 수도 있습니다.

클로드 코드 베스트 프랙티스는 스스로 만들어야 해요

중요한 건 클로드 코드 베스트 프랙티스를 스스로 만들어야 한다는 거예요. 많이 써보면서 스스로 생각하는 수밖에 없어요. 완전한 베스트 프랙티스는 없겠죠. 다만 본인 스스로가 어떤 워크플로우를 계속 가질 수 있을 것인가를 질문하고 생각할 필요가 있습니다.

2월에 베타 버전이 나왔을 때 제가 처음 한 건, 자바스크립트 바이너리를 디컴파일해서 뜯어본 거였어요. 안에 보니 하드코딩으로 'think harder' ‘think intensely”, 'ultra think' 같은 게 적혀 있더라고요. '왜 이게 하드코딩되어 있을까?' 궁금해 하면서 계속 실행해보는 거죠. 결국 이런 AI 도구들을 많이 사용해보면서 스스로 노하우를 쌓아가는 게 중요합니다.

제 블로그에 ‘ultrathink engineer’ 원칙을 적어두었는데요. 제가 개인적으로 생각하는 건, 각각의 모델은 각각의 특징이 있고 각각의 강점이 있기 때문에, 가장 좋은 모델들의 최고 결과를 어떻게 뽑아낼 것인가가 중요하다는 거예요. 최근에 카파시가 LLM Council이라는 깃헙을 냈잖아요. 가장 좋은 모델들끼리 앙상블해서 합의를 보거나 피드백을 계속 주고받는 방식이죠.

이걸 따라가려면 요즘 같이 변화가 빠른 시대에는 AI 최고급 옵션을 가지고 있어야 한다고 생각해요. 그걸로 여러 가지 에이전트 워크플로우를 실험하지 않고서는 이 시대에 살아남을 수 없어요. 한 달에 AI 비용만 100만 원 넘게도 쓸 수 있어야 한다고 봅니다. 저도 월에 한 120만 원은 쓰는 것 같아요. 월세를 내는 것만큼 AI 비용을 내야 한다는 거예요. 사람들이 ‘미쳤냐’고 하죠. 하지만 어쩔 수 없어요. 이렇게 많이 쓰는 대신, 그 이상의 가치를 어떻게 창출할 것인지를 고민하는 것이 이 시대에 살아남기 위한 방법이라고 저는 생각합니다.

작년만 해도 제가 크리티컬하지 않은 시스템은 클로드코드에 모든 걸 맡기고 배포한다는 이야기를 인터넷에 올렸을 때 욕도 많이 먹었습니다. 하지만 이젠 많은 분들의 생각도 변했죠. 저는 AI가 발전하는 속도가 너무 빠르기 때문에 최고의 모델을 계속 써봐야 한다고 생각합니다.

AI 개발 도구 생산성이 저하됐다고 느끼는 이유

그런데 저와 다르게, AI 개발 도구를 써보고 생산성이 더 저해되었다고 말하던 분들도 있습니다. 원하는 결과가 나오지 않으니 “AI 별로네”라고 하죠. 이건 사실 AI를 잘 못 써서 생기는 일일 수 있는데요. 이걸 더 잘 들여다 보면, AI에게 어떤 지시를 내려야 할지 스스로도 잘 모른다는 의미일 수 있습니다.

많은 이들이 바이브코딩을 도박처럼 생각해요. 내가 원하는 소원이 있고, AI한테 넣으면 들어줄 수도 있고 안 들어줄 수도 있는 거죠. 안 될 것 같은데 되는 경우도 있고, 될 것 같은데 안 되는 경우도 있어요. 계속 도박을 하면서 "그다음엔 될까? 그다음엔 될까?" 이런 식으로 넣어보는 거예요. 게임 요소랑 비슷한 거죠. 그냥 기도하는 거랑 비슷하기도 해요. 프롬프트 앤 프레이(Prompt and Pray)를 하는 거죠.

그런데 우리가 기능 개발을 게임으로 하진 않잖아요. 내가 논리적으로 뭘 원하는지 알고, 뭘 분석해야 하는지 알아야 개발할 수 있죠. 즉 내가 나의 필요에 의해서 AI를 호출할 수 있어야 합니다. 지시를 잘하는 수밖에 없어요. 예를 들어 아무리 좋은 모델한테 “카카오톡 만들어줘”라고 한다고 해도, 3조짜리 카카오톡 같은 걸 만들어줄 수는 없잖아요.

내가 책임져야 하는 상황에 대해 내가 모르면 문제가 있는 것입니다. 그래서 많은 사람들이 "생산성 개선이 없다"고 말하는 상황이 생기는 것 같아요.

결국 내가 AI에게 무언가를 핀포인트로 지시할 수 있어야 한다는 게 굉장히 중요합니다. 생각보다 자기 분야에서 전문성이 있으면 토큰 사용량이 적어요. 내가 구체적으로 어떤 걸 핀포인트로 주거나, 모델이 잘못된 방향으로 갈 때 빨리 멈추고 다시 시작하기 때문이에요.

결국 내가 무엇을 할 것인지를 명확히 아는 것이 중요

이렇게 하기 위해서는 빠르게 피드백을 받아서 AI한테 의견을 낼 수 있는 사람이 되어야 합니다. 단순히 흘러가는 대로 따라가기에는 너무 힘듭니다.

AI가 발전할수록 나도 발전하는 게 굉장히 중요합니다. AI한테 조금이라도 다른 지시사항을 주었을 때 방향성이 달라질 수 있으니까요. AI는 당연히 놓치는 부분이 있을 수밖에 없고, 동료로서 바라본다면 나는 어떻게 피드백을 줄 것인가를 생각해야 해요. 테스트해서 결과물을 보고 로그를 줄 수도 있고, 다른 AI한테 소셜 피드백을 받아서 넣어줄 수도 있고요. 만약 내가 어떤 특정 분야에 전문성이 있으면, 그 전문적인 걸 주었을 때 AI가 놓치는 부분을 내가 잡을 수 있어요.

AI가 잠재적인 지식을 가지고 있는데, 그걸 어떻게 꺼낼 것인가도 굉장히 중요합니다. 그냥 "해줘"라고 했을 때 안 꺼내지는 경우가 있거든요. 프롬프트로 꺼내든지, 퓨샷으로 예시를 주든지, 여유가 있다면 강화학습으로 후학습해서 꺼내든지. 결국 중요한 건 내가 스스로 뭘 하는지 안다면 좋은 방향으로 잘 조정할 수 있다는 겁니다.

제가 하는 많은 일들 중 가장 큰 임팩트를 만드는 일은 논문을 코드로 바꾸는 거예요. 원래 이걸 하려면 대학원생들 석박사 서너 명이 붙어서 미친 듯이 해야 하거든요. 근데 이제 더 이상 그럴 필요가 없어요. 혼자 할 수 있는 거고, 저는 전공자도 아니고 대학도 졸업하지 않았습니다.

근데 그냥 머신러닝 페이퍼를 코드로 만든 다음에 마이크로소프트 같은 곳 리서처한테 보내서 피드백받고 하는 거죠. 이런 것들이 가능한 시대가 왔다는 거고요. 다만 이 분야를 전혀 모르고 일을 할 수는 없겠죠. AI가 작업한 것들에 대해서 나도 공부하고, 나도 피드백을 줘야 남들한테 설명할 수 있고, 제품의 방향에 의견을 제시할 수 있는 거잖아요.

이니셔티브를 시작하는 건 사람이에요. 계속 같은 얘기를 하고 있는 것 같은데, 이게 가장 근본적인 핵심이라고 생각해요. 바이브 코딩의 시대다, AI가 다 해준다, 대체된다 이런 얘기를 하지만, 결국 중요한 건 내가 뭘 원하는지 아는 것입니다. 지금 현실에서 어떤 걸 하는 게 비즈니스 임팩트가 있고, 어떤 걸 하지 않는 게 제품 성공에 중요한지. 이런 판단을 결국 사람이 해야 하고, AI한테 잘 알려주고 이력 관리를 어떻게 할 것인가를 생각해야 합니다.

테크 스펙 먼저 쓰고, AI와 토론하기

내가 하고자 하는 걸 명확히 하는 방법으로, 저는 적어보는 걸 추천해요. 메모를 쓰고, 그걸 가지고 어떤 일을 하면 좋을까 계속 생각하고 판단하는 거죠.

특히 테크 스펙을 작성하는 게 좋아요. 할 것과 하지 않을 것, 하기 위해서는 무엇부터 해야 하는지, 어떤 결정이 있을 때 일이 끝났다고 판단할 수 있는지를 적는 거죠. 이런 내용을 테크 스펙이나 사양으로 정의해두고, 이 문서를 읽어본 뒤 파악하고 구체적인 플랜을 세워보라고 AI 코딩 에이전트에 요청하는 거예요.

전 이 과정이 너무 중요하다고 생각해요. 코딩 AI 에이전트에게 그냥 ‘해줘’라고 부탁하기보다는, 내가 지금 뭘 하고 싶은지에 대한 분명한 목표가 있는 상태에서 가장 최신의 모델들에게 플랜을 동의받고, 나도 그 디스커션에 참여해서 완료한 것을 코딩 AI 에이전트에게 주는 것이죠.

이를 기반으로 세부적으로 단위를 쪼개서 일하도록 합니다. 그 하나하나가 별도의 세션이 될 것이고, 별도 세션마다 AI가 커밋을 남기면서 그다음으로 나아가는 것입니다. 즉 지금 뭘 하고 싶은지, 해야 하는 게 뭐고 안 되는 게 뭔지를 개발자와 AI가 서로 확인하는 게 중요합니다. 이런 대화 과정을 통해서 개발자 스스로도 뭘 하고 싶은지를 알 수 있게 되죠.

X-Y Problem이라는 게 있어요. 실제로 풀고 싶은 문제가 X인데, 내가 생각했을 때 Y를 풀면 X가 풀릴 거라 생각하는 거죠. 근데 알고 보니까 Y랑 X는 관련이 없고, Y를 풀기 위해 또 Z가 나오는데 Z를 풀어도 X는 안 풀리는 거예요. 이 과정에서 사람이랑 디스커션하고 대화하기가 너무 어렵습니다. AI도 똑같아요.

테크 스펙 문서를 작성해보고 가장 좋은 AI 모델에 물어보면, 결국 어떤 문제를 해결해야 하는지 논리적인 흐름을 잡을 수 있어요. 예를 들어 일의 배경, 목표, 목표가 아닌 것, 이런 이야기를 AI와 계속 나누고, 코딩 AI에이전ㅇ트에 일을 시킵니다. 그다음 구체적인 플랜을 만들고 그 세부 과업을 정하고요, 그 과업별로 커밋을 만들어 자세한 내용을 적죠. 그렇게 되면 어떤 문제를 어떻게 해결했는지 기록되고 그다음에 새로운 세션을 켠다 하더라도 이전의 과정을 깃으로 계속 읽어 그다음으로 나갈 수 있습니다.

SDD의 부활: 문서는 가볍게, 이력은 Git에

사실 2000년대 초반에도 문서를 기반으로 개발하는 SDD(Spec-Driven Development)라는 개념이 있었지만, 지금은 많이 사라졌습니다. 가장 큰 이유는 '문서와 코드의 괴리' 때문입니다. 거대한 문서는 코드의 변화를 따라가지 못하고 결국 동기화가 깨지기 마련입니다.

그래서 저는 새로운 방식을 제안합니다. 테크 스펙은 최소한의 방향성만 담고, 구체적인 플랜과 로직 설명은 깃(Git)에 남기는 것입니다.

과업별 세션 분리: 세부 플랜에 따라 각각의 세션을 별도로 운영합니다.
커밋 메시지의 상세화: 각 세션에서 문제를 어떻게 해결했고, 어떤 난관이 있었는지를 커밋 메시지에 자세히 기록합니다.
실행 이력 기반의 컨텍스트: 이렇게 하면 새로운 세션을 시작하더라도 AI가 이전의 깃 기록을 읽고 문맥을 파악해 다음 단계로 나아갈 수 있습니다.

결국 문서가 아니라 실행 이력을 관리하는 것이 핵심입니다. "네가 지금 무엇을 해야 하고, 하면 안 되는 게 무엇인지 알아?"라고 AI와 끊임없이 확인하며 워크플로우를 설계하는 것, 이것이 울트라씽크 엔지니어가 AI와 협업하며 압도적인 생산성을 만들어내는 비결입니다.

시스템 프롬프트보다 중요한 ‘룰 베이스’와 ‘빠른 피드백’

요즘은 시스템 프롬프트나 .json 설정 파일을 세세하게 관리하는 것이 생각보다 큰 의미가 없을 수도 있다는 생각이 듭니다. 근본적으로 모든 AI 작업은 'Next Token Prediction'일 수밖에 없으므로 일차적으로 틀릴 가능성이 늘 존재합니다. AI가 맥락을 완벽히 팔로우하는 것이 쉽지 않기 때문에, 이를 도와주는 룰 베이스(Rule-base) 시스템의 중요성이 백 배는 더 높아집니다.

그렇다면 룰 베이스를 어떻게 잘 사용할 수 있을까요? 결국 테스트를 잘 작성하는 수밖에 없습니다. 테스트를 작성한다는 것은 AI에게 적절한 피드백을 제시간에 주는 행위입니다. 모든 피드백은 빠를수록 좋습니다. 룰 베이스 컴파일러도, 테스트도, 사람도 마찬가지입니다.

클로드 코드를 예로 들면, 내가 밤에 자서 아침에 일어날 때까지 8시간 동안 혼자 돌게 두면 안 됩니다. 내가 원하는 것과 AI가 원하는 것이 다를 수 있기 때문에, 사람이 계속 핸들링하며 잡아줘야 합니다. 마치 비행기를 조종할 때 가만히 놔두면 기체가 경로를 벗어나 버리는 것과 비슷합니다. 따라서 빨리 꺼내서 피드백을 주고 다음 단계로 가는 장치들을 마련하는 게 중요합니다.

자동 피드백 루프에 중요한 ‘딴지’

이 루프 안에서는 누군가 계속 '딴지'를 걸어줘야 합니다. 대표적인 예로 파이썬 개발을 들 수 있습니다. 파이썬은 타임 체크(Type Check)가 없어서 머신러닝 작업을 할 때 크리티컬한 실수를 하기 쉽습니다. 이런 관점에서 클로드 코드의 '스킬(Skills)' 기능을 활용할 수 있습니다. 예를 들어 에디트(Edit)나 멀티 에디트(Multi-edit)로 파일이 추가되거나 편집될 때 특정 스킬이 실행되도록 설정하는 방식입니다. 저 같은 경우에는 적당히 메이크 파일(Make file)을 만들어 돌리다가 AI에게 그냥 시키는 편입니다. 그러면 AI가 스스로 피드백 루프를 돌며 실수를 바로잡게 됩니다.

그다음에는 AI에게 직접 테스트를 작성하게 해보십시오. 테크 스펙을 기반으로 테스트를 만들게 한 뒤, "네가 이 테스트를 통과하니? 안 되면 왜 안 되는지 생각해보자"라고 하며 반복시키는 겁니다. 이 과정에서 토큰이 꽤 많이 소모될 수 있습니다. 이틀 정도 리트라이(Retry)를 반복해야 성공할 때도 있지만, 그렇게 해서 성공했을 때의 확률이 압도적으로 높습니다.

'에이전트 드롭'과 상호 리뷰: 사람이 개입해야 하는 이유

그리고 AI끼리만 두면 집단 편향에 빠질 수 있습니다. 이를 방지하기 위해 제가 사용하는 방법은 '에이전트 드롭'입니다. 클로드 안에서 제미나이를 실행하게 하거나 서로 핑퐁을 시키는 거죠. 오케스트레이터(Orchestrator)를 호출해 서로의 결과물에 점수를 매기게 하고, 동의할 때까지 반복하며 롤플레잉 상태를 유지하는 것이 베스트입니다.

그럼에도 불구하고 사람이 중간에 들어와야 합니다. 특정 시점에 결과물을 꺼내봤을 때, AI가 만든 플랜이 사람이 이해하기 너무 어렵다면 피드백을 줄 수 없고 일의 진행 상황에 확신을 가질 수 없기 때문입니다. 하루 이틀 지나서 실제로는 구현이 안 된 것을 발견하면 스스로 황당함을 느끼게 되죠. 그래서 중간중간 작동하는 샘플(Working Example)을 확인할 수 있는 테스트 환경이 정말 중요합니다.

반복 루프 설계하기

5점짜리 모델을 100점으로 만드는 '마인드셋'

이는 Poetiq 리서치 팀이 ARC-AGI 벤치마크에서 세계 1위를 기록한 방식과 일맥상통합니다.

가설 설정(Initial Solution): 처음 솔루션을 생성합니다.
자가 개선(Self-improvement): 솔루션을 스스로 발전시킵니다.
검증(Verification): 테스트를 통해 작동 여부를 확인합니다.
교정(Correction): 실패 시 버그 리포트를 리뷰하고 수정하는 과정을 5~10회 반복합니다.

아무리 좋은 모델이라도 여러 스텝의 일을 하면 실수할 수밖에 없기에, 이 '반복 루프'를 설계하는 것이 핵심입니다.

컨텍스트 엔지니어링보다 빠른 피드백 루프가 중요

많은 사람들이 프롬프트 하나하나 세션을 열고 열심히 기도하는데, 사실 그러면 안 돼요. 하나의 세션에 하나의 에이전트한테 계속 똑같이 이어나가면서 이것저것 하다 보면, 실수가 한 번 일어나면 누적됩니다. 여러 가지 모델이 서로 각각의 일을 하고, 서로 투표해서 가장 좋은 걸 선택하면서 가야 해요.

결론적으로 하나의 일을 하는 데 여러 에이전트를 사용하는 게 중요합니다. 밀리언 스텝의 태스크를 에러 없이 하려면 프레임이 명확해야 하고, 더 좋은 건 여러 가지 LLM 모델의 결과를 가지고 앙상블해서 같이 써서 가장 좋은 답을 뽑아내는 겁니다. 서로 비판적이어야 하고요.

그래서 컨텍스트 엔지니어링이 별로 의미가 없다고 생각해요. 가장 좋은 컨텍스트 엔지니어링은 가장 깔끔하고 토큰이 없는 상태입니다. 매번 플랜이 명확하고 매번 해야 할 일들이 명확하게 잘 설계되어 있으면, 이전에 있는 것들을 잘 요약해서 넣는 걸 할 필요가 없어요.

심지어 요즘 모델들은 컨텍스트가 워낙 늘어났기 때문에 제미나이 같은 경우 원밀리언 토큰, 한 500페이지 책 1만 권을 5천 권 넣어도 버티는 양이에요. 그래서 컨텍스트 엔지니어링이 생각보다 의미가 없습니다.

정리하자면, 가장 중요한 건 빠르게 결과물을 꺼내서 빠르게 보여주고 빠르게 피드백을 받는 반복적인 플로우입니다. 이것이 컨텍스트 엔지니어링보다 더 중요하다고 생각해요.

빨리 꺼네보려면 플래닝보다는 시키는 것을 하도록 하면 되기 때문에 무거운 모델을 써서 토큰 수를 늘릴 필요는 없어요. 토큰 수를 덜 쓸 수도 있고, 조금 싼 모델을 편집 용으로 쓸 수도 있어요. 예를 들어 중국 모델 키미 K2나 미니맥스 같은 건 클로드 코드가 소넷 3.5 수준의 성능을 가지는데 10분의 1 가격이에요. 수돗물 쓰듯이 쓸 수 있습니다.

Q. 시스템 프롬프트, 컨텍스트, 룰 등 규정을 빠듯하게 세워도 자연스럽게 누락되는 요소들이 생기더라고요. 말을 안 듣는 상황을 어떻게 해결하셨을까요?

당연히 없앨 수 없는 거예요. 결정론적인 시스템이 아니고 너무나 비결정적이니까요. 리뷰와 검수를 계속 봐주는 룰 베이스 장치가 있는 게 너무나도 중요합니다. 예를 들어 셸 스크립트를 작성해놓고, 이 룰을 안 지켰으면 그냥 에러를 뱉게 만드는 거예요. Hook이나 클로드 스킬을 작성해서 매번 작업할 때 에러로 뜨면 아차 하면서 고치겠죠.

LLM의 불확실성 때문에 문제가 발생하는 경우가 많아요. 이 문제를 막아주는 기본적인 확인 장치는 룰입니다. 그래서 룰 베이스의 가치 역시 100 배 이상 증가했다고 말씀드리고 싶습니다.

Q. 클로드에서 스킬과 에이전트를 둘 다 써보고 있는데 솔직히 큰 차이를 잘 모르겠습니다. 커맨드 창에서 "SKILLS.md 참고해서 뭐 해줘"라고 직접 지시하는 것과 그 지시 내용을 에이전트에 설정해두고 호출하는 것 정도의 차이로만 느껴지는데요. 스킬과 에이전트의 핵심적인 차이가 있을까요?

물론 차이는 있어요. 스킬 같은 경우에는 파이썬 스크립트를 안에서 호출하거나 아이솔레이트된 샌드박스 수행을 하겠다, 이런 형태의 이야기들을 하고요. 에이전트.md는 시스템 프롬프트적인 관점이 있어요. 그런데 본질적으로는 같아요. 결국 스킬이든 에이전트든 모두 다 LLM을 룰 베이스로 사용하기 위한 CLI의 기능들이에요. 본질은 다 똑같아요. 일정 조건에서 이 스크립트를 룰 베이스 측으로 실행하길 바란다는 거고요.

AGENTS.MD는 시스템 프롬프트의 관점이 있기 때문에 좀 다르긴 한데, 어쨌든 기본적으로 풀고자 하는 문제들의 본질은 비슷합니다.

Q. LLM이 출력하는 내용을 어느 정도로 확인하고 리뷰하시나요? LLM들이 출력하는 내용이 너무 많아서 코드나 문서 같은 경우에 다 읽기보다는 중요한 부분만 확인하게 돼요.

사실 저는 어떤 방식으로든 사람이 내용을 계속 확인하는 건 너무나도 중요하다고 생각해요. 책임지지 않아도 상관없는 상황이면 모르겠지만, 책임져야 하는 상황이면 저는 무조건 봐야 한다고 생각합니다.

바이브 코딩을 하면 너무 빨리 결과가 나오기 때문에 그 도박에 취하는 거랑 비슷하다고 생각해요. 근데 우리가 제품을 그렇게 만들지 않잖아요. 빨리 나오는데 그걸 잘 검토하는 게 사람의 역할입니다.

적당히 일감을 나도 볼 수 있을 만큼 자르는 것도 중요해요. AI는 너무 많은 일을 한 번에 처리할 수 있으니까요. 컨텍스트가 늘어나면 속도가 느려지는 것도 분명하고, 내용에 대한 정확도가 떨어질 수밖에 없어요. 그렇기 때문에 내가 볼 수 있을 만큼의 태스크 과업으로 잘 나눈 다음에 그다음에 가보자, 이게 중요합니다.

Q. AI를 활용할 때 생산성 기대와 현실 사이의 괴리는 어떻게 보시나요? AI를 쓰면서 기대하게 되는 것이 사람이 직접 작업하는 것보다 생산성이 좋아야 하고, 결과물도 더 좋고 시간도 아껴줘야 하지 않을까 하는 생각이 드는데요. 그러다 보면 결국 ‘내가 하고 말지’ 하는 생각이 드는 경험이 있지는 않으신지요

결국에는 사람의 시대가 끝났다고 생각해요. 그런 시대는 이제 없어요. 코딩을 제가 직접 하지도 않아요. 결국 중요한 건 나는 코딩한 결과물을 가지고 계속 테스트를 보겠다, 이런 판단을 해요.

생산성 얘기를 하면, 제가 코드를 영타 타속이 굉장히 빠른 편이지만 AI의 속도를 따라갈 수는 없겠죠. 이것만 봐서도 생산성은 꽤 높은 거고요.

숙련된 개발자가 개발하는 것과 AI가 개발하는 것 사이에 어느 정도 차이가 있어야 해요. AI가 나보다 빨라요. 근데 결국 빠른 것도 빠른 거지만 내가 어떻게 잘 피드백을 주느냐가 중요합니다. 빠르게 내 아이디어를 실험해보고, 아닌 것 같으면 빨리 돌려보고, 이터레이션을 빨리 돌리는 측면에서 너무나 중요해요.

Q. 팀 단위로 클로드 코드를 적용할 때 조언을 부탁드립니다. 디자인을 먼저 완성하고 그 후에 스펙 문서를 작성하는 방식으로 개발을 준비하고 있습니다. 디자인 기반으로 스펙을 작성할 때 UI 설명, 플로우, 제약사항 등을 어떤 형식으로 구조화하면 AI 개발 단계에서 가장 효과적일까요?

결국 구현의 제약도 사실 AI한테 해달라고 하는 게 제일 좋다고 생각해요. AI가 스스로 프롬프트를 만드는 게 더 명확할 때가 많거든요.

예를 들어 자료가 있으면 캡쳐해서 AI한테 주고 해보라고 하는 거죠. "너가 스펙 문서를 만들어봐라, 너가 프롬프트도 만들어봐라." 그럼 그거에 대한 아웃풋이 있을 거고, 그걸 사람이 보고 테스트를 해보는 거예요. 실제로 한번 적용해보고, 아쉬운 부분들이 있으면 그걸 반복해서 깎아나가는 과정들이 중요해요.

Q. 스펙 드리븐 개발(SDD) 방식을 팀에 적용하기 위한 인사이트가 있을까요? 클로드 코드를 통한 코드 생성 시 AI 모델에 전달하는 컨텍스트를 다수의 팀원 간 어떻게 공유하고 관리해야 할지 고민 중입니다.

아까도 얘기했지만 스펙이 관리되는 게 저는 사실상 어렵다라고 생각해요. 모두가 스스로 솔직히 생각하고 계실 것 같고 저도 그렇게 생각하거든요.

중요한 건 깃에다가 잘 작성해두는 거예요. 기본적인 코딩 AI 에이전트는 깃을 볼 수 있도록 되어 있기 때문에, SSoT(Single Source of Truth)를 만들어놓고 이것만 활용시키면 어느 정도 싱크를 할 수 있죠.

매번 작업할 때마다 문서와 코드를 같이 업데이트하는 건 쉽지 않아요. 다만 중간중간 생략되는 내용들을 어떻게 깃 커밋 메시지로 표현해서, 나중에 보는 사람이 Git 만으로도 어느 정도 파악할 수 있도록 만드는 게 중요하지 않을까 생각합니다.

Q. PRD를 잘 쓰는 팁이 있을까요? PRD가 매우 중요하다는 것은 알게 되었지만, 프로젝트 개발 경험 자체가 없어서 어떻게 해야 이 문서를 잘 쓸 수 있을지 감이 잘 안 옵니다.

내 스스로에게 인지될 수 있을 만한 레벨로 AI한테 해달라고 하는 게 중요하다고 생각해요. 영어가 어려우면 내가 이해할 수 있는 버전으로 하나를 만들어달라고 하는 거죠. 그걸 가지고 AI와 소통해서 계속 깎아나가는 방향도 괜찮아요.

이런 고민들과 팁들은 결국 정해져 있는 수준이 있는 게 아니고 나만의 것이 있는 거예요. 실버 불렛 같은 건 없어요. AI랑 많이 대화하고, 어쩌면 롤플레이를 해야 될 수도 있고 "너는 일부러 나를 비판해라" 이렇게 가져가야 할 수도 있고요. 그런 과정들을 반복하다 보면 내 스스로 어떤 것들이 목표고 어떤 것들이 목표가 아닌지 명확해집니다.

Q. 내용을 종합해 보면 휴먼 합의체를 만드는 것을 지향하는 것으로 보이는데, 이런 휴먼 합의체를 만드는 포맷이 따로 있으실까요?

그거를 만들면 꽤 유명해질 수 있다고 생각해요. 그런 것들을 하겠다고 나오는 프로젝트도 많고요.

다만 현재 시점에서 그걸 하기가 별로 좋지 않은 이유는, 매번 일주일씩 제가 주로 사용하는 코딩 AI가 다 달라지거든요. 오픈 AI GPT-5.2-codex-xhigh가 나오기 전에는 클로드만 썼다가 지금은 같이 쓰거나요. 변화가 빠르기 때문에 내가 포맷을 만들어놔도 다음 주에 못 쓰는 경우일 수도 있어요.

뭔가 어느 정도의 프레임워크를 만들어주는 게 의미가 있을 수도 있다는 생각을 가지고 있긴 해요. 근데 저는 개인적으로 이걸 규격화해서 사용하는 정도까지는 일부러 하지 않고 있습니다. LLM이 결국 계속 개선되기 때문에 따로 에이전트까지 만들어서 쓰지도 않고요. 테스트는 해봤는데 의미가 없더라고요. 일주일 단위로 바뀌는데 유지보수하는 것도 일이니까요.

Q. llm 과 rag 등을 활용해서 에이전트를 구축하고 적용할 때 필요한 프레임워크, ML 지식 수준에 대해서 현장에서 느낀 점에 대해해 의견을 주세요.

프레임워크를 쓰는 게 저는 현 시점에서 아직 의미가 많이 없다고 생각해요. 변화가 너무 빠르기 때문이에요. "랭체인 쓰지 마라"는 블로그 글 보신 분들 계실 텐데, 랭체인을 떠나서 프레임워크 자체가 변화 속도가 빨라요. 물론 여기에 AI의 힘을 얼마나 잘 빌릴 수 있냐도 포함된 이야기입니다.

가장 빠른 시점에서 내가 빨리 프로덕트를 딜리버할 수 있는 방향을 생각해보고, 그에 필요한 지식이 있다면 그 지식이 정말 문제 해결에 핵심적인 센터가 되는 건지 같이 고민해볼 필요가 있어요.

현재 시점에서 지식을 배우는 것보다 지능을 빌리는 게 너무나 값싸졌어요. 그러면 여기서 내가 중요한 건 시간밖에 없습니다. 시간은 여전히 값어치 있는 자산이에요. 한정된 시간 안에 내가 무엇을 하는 게 중요한가, 계속 이런 판단을 해보는 게 의미가 있을 것 같습니다.

Q. 현재 시점에서 AI 활용 능력은 어떻게 평가할 수 있을까요?

그건 스스로 알 수 있는 것 같아요. AI는 무조건 할 수 있다고 전제를 해놓고, 내가 지금 스스로 매뉴얼하게 일하고 있는 게 얼마나 되지? 혹은 AI는 할 수 있을 것 같고, 나만 할 수 있을 것 같은 일만 정말 집중하고 있는가? 불필요한 일을 덜어낸, 내가 해야 될 일을 많이 하고 있는가? 스스로 이 질문을 계속 던져보는 게 중요하지 않을까 합니다.

뭔가 자격증이 있는 게 아니잖아요. 스스로 AI의 발전으로 많은 힘을 빌리고 있고, 그 과정에서 매번 느껴지는 거죠. 일주일 전에 안 됐는데 이번 주에는 된다, 이런 것도 계속 있어요. 모델이 계속 바뀌니까요. 그 과정에서 내가 계속 이 흐름의 루프에 타고 있는가, 스스로 질문할 필요가 있죠.

Q. 동시에 여러 가지를 개발할 때 컨텍스트 스위칭이 어려운데 팁이 있을까요?

사실 이건 모든 사람들이 그렇게 느낀다고 생각해요. 일을 시작하는 건 사람이니까요.

내가 스스로 할 수 있는 일의 스코프를 잘 만드는 게 중요해요. 바이브 코딩하는 분들의 특징이 여러 가지 동시에 일을 많이 하는 데 집중한단 말이죠. 사실 꼭 그럴 필요는 없다고 생각해요. 아까도 얘기했듯이 바이브 코딩 같은 경우에는 도박, 게임의 사행성이 있기 때문에 스스로 그걸 잘 통제하는 것도 너무나 중요해요. 그래야 내가 믿을 수 있는 결과물을 낼 수 있습니다.

동시에 여러 일을 하는 게 멋져 보이고 좋아 보이지만, 결국 중요한 건 내가 스스로 흡수할 수 있을 만큼의 일을 잘 만들고 세부적으로 잘 다듬는 거예요. 이게 사람이 해야 되는 영역이라고 생각합니다.

Q. 꼭 클로드 코드가 아니어도 특정 개발 프로젝트에 맞는 AI 툴을 선정할 때 어떤 기준을 고려하면 좋을까요?

여러 도구를 많이 쓰는 건 좋고, 기본적으로 개발이라고 하는 일감들이 달라지지 않기 때문에 여러 도구로 동시에 써보고 스스로 평가해보는 게 중요해요. 저도 주력으로 쓰는 도구들이 매주 달라지기 때문에 뭘 꼭 쓴다는 생각은 전혀 하고 있지 않아요. 중요한 건 현장과 상황에 맞는 도구를 잘 선택하고, 팔로우하면서 계속 써보는 거죠.

Q. AWS에서 나온 Kiro를 사용해보셨을까요?

네, 계속 테스트해보고 있어요. 모든 코딩 AI 에이전트가 수렴하고 있고, 클로드 코드 처음 나온 다음부터 이 패러다임이 퍼지는 거죠.

기본적인 코딩 AI 에이전트가 어떤 걸 가져야 하는가에 대해서는 어느 정도 답이 있다고 생각해요. 결국 중요한 건 모델, 그다음에 스스로에 대한 자각, 그다음에 여러 모델 간에 서로 리뷰할 수 있도록 해서 하나의 모델을 믿지 않는다는 것이죠.

최근 여러 모델을 오케스트레이션할 수 있는 oh my opencode가 개발자 커뮤니티에서 큰 화제가 되기도 했죠. 제가 운영하는 커뮤니티인 Instruct.KR의 멤버 김연규 님이 만들었는데요. oh my opencode는 오픈소스 코딩 에이전트 OpenCode를 위한 플러그인으로 다양한 대규모 코딩 에이전트들을 오케스트레이션하고, 여러 전문화된 에이전트를 동시에 운용합니다. oh my opencode도 활용해보시길 추천드립니다.

Q. 결국 내가 어떤 문제를 풀어야 하는지에 대한 자각이 중요하다는 말씀을 많이 하셨는데요. 내가 풀어야 할 문제를 자각하는 과정에서 도움이 되었던 사례나 경험이 있을까요?

o4-mini-max 모델이나 GPT 5.1 Pro, 재미나이 3.5 씽크 같은 게 있잖아요. 사실 진짜 이 세상의 아주 많은 지식을 가지고 있는 친구를 내가 바로 앞에서 맞이할 수 있다는 거어요. 그 친구와 대화를 많이 해보는 게 중요하고, 그 결과물이어야 합니다.

AI랑 많이 대화하고, 어쩌면 롤플레이를 해야 될 수도 있어요. "너는 리뷰어야, 너는 무조건 비판만 해" 이런 식으로 반복해서 모델 간의 대화를 엮어가는 거죠.

그럼에도 가장 좋은 AI을 잘 쓰는 게 중요하고, 어떤 시점에서의 방향을 찾았을 때는 스스로에게 어떤 문제를 풀지를 스스로가 아는 거예요. 그러면 지시도 잘 될 수밖에 없거든요. "너 자신을 알라" 같은 과거의 교훈들이 요즘 같은 시대에서도 많이 등장하는 것 같습니다.

Q. 정보를 얻는 공간으로 반드시 알아야 하는 곳이 있을까요?

기본적으로 요즘IT도 좋은 내용 많이 올라온다고 생각하고요. 긱뉴스도 유명하죠. 저는 이것들부터 팔로우하는 게 중요하다고 생각해요. 그러다 보면 스스로에 대한 관심사가 있으면 레딧이나 다른 사이트로 빠지면서 활동할 수도 있고요.

기본적으로 요즘IT만 봐도 저는 꽤 잘 된다고 생각해서요. 다시 얘기하지만 뭔가 특별한 지식이 어딘가에 있지 않아요. 전혀 그렇지 않아요. 중요한 건 스스로에게 맞는 건 스스로한테 있고, 실버 불렛 같은 건 없는 거죠.

뭔가 멋진 프롬프트가 있다면 AI랑 같이 롤플레이를 하든, 특정 페르소나를 쥐어주고 "너는 무조건 비판만 해" 이런 식으로 반복해서 모델 간의 대화를 엮어가는 거죠. 저는 그럼에도 가장 좋은 AI 모델을 잘 쓰는 게 중요하고, 스스로에게 어떤 문제를 풀지를 스스로가 아는 것이 가장 중요하다고 생각합니다.

Q. 아무리 리젝하고 멈추고 주의를 줘도 정말 멍청해지는 때가 있는데요. 이럴 때 도움이 될 만한 방법이 있을까요?

일단 제 생각에 첫 번째는 모델을 바꿔보면 의미가 있을 거고요. 도구를 바꿔보는 것도 의미가 있어요. 여러 모델을 투표시켜도 유의미할 거예요.

이렇게도 해결이 안 되면 스스로 생각해보는 거죠. 내가 지금 맡고 있는 문제를 해결해달라고 하는 게 나라면 할 수 있었을까? 너무 내가 문제를 광범위하게 설정하지 않았을까? 혹은 내가 무슨 문제를 풀고 싶은지 모르는 게 아닐까?

저는 이상적인 멋진 프롬프트는 없다고 생각해요. 심지어 코딩 AI 에이전트도 그냥 키워드 검색해서 가져오는 거예요. 클로드 코드로 안 되는데 코덱스를 같이 호출해서 둘이 토론시키니까 문제를 해결했네, 뭐 이런 과정들을 많이 겪어보는 것도 중요합니다.