문자 그대로 10x 엔지니어이신 건가요

https://youtu.be/Og0mtAbDrDY?si=rrSyvWrJ8anZ1bwh

EP 70. 뭘 하느라고 AI 토큰 5억 원 어치씩 태웠는지 알려드림

-- 녹화를 하고 있는 오늘은 2025년 9월 27일 토요일 아침입니다. Sionic의 고석현 대표님 두 번째로 모셨습니다. 지난번에 고 대표님과의 톡을 마무리하면서 이 회사의 성과가 곧 인재의 성과이고 인재의 성과는 토큰 사용량에 비례하는 것 같다는 그런 뉘앙스로 대화를 끝맺었었는데요. 아주 흥미로웠죠. 그 사이에 저희가 또 시간이 한참 흘렀고 Claude Code와 Codex가 나오면서 또 그러한 미래가 Sionic이라는 회사에 미리 와 있다는 소식을 듣고요. 오늘 한번 그 화제의 주인공 한 분 모셨습니다. 제가 이전에 한번 굉장히 과격한 이야기를 했던 적이 있습니다. 그러니까 저도 회사를 운영하고 있는 입장에서 저희 임직원들의 성과가 토큰의 사용량에 비례하는 것 같다며 토큰을 많이 쓰는 사람이 더 많은 성과를 내는 것 같다는 이런 되게 위험한 발언을 한 적이 있는데요. 실제로 그걸 저희 회사에서 증명하고 계신, 제가 볼 때는 거의 10명, 100명의 일을 하고 계신 것 같은 저희 임직원분 박진형 님을 모셨습니다.
-- 같이 이야기 나눠보면서 한번 그 발언을 수습해 보겠습니다. 문자 그대로 10x 엔지니어이신 건가요? 100x 엔지니어라고 불러야 될 것 같아요. 100인 것 같아요, 10이 아니라.

-- 그래서 궁금하신 분들이 있으실 텐데 Claude Code가 나온 지 얼마 안 됐을 때 한 달의 기간 동안 약 5억 원어치의 토큰을 태우셨던 분이에요. Claude 토큰 사용량 글로벌 1위를 하셨고 Reddit에서도 크게 화제가 되셨던 바로 그 인물입니다. 안녕하세요. 안녕하세요, 진형님. 네, 반갑습니다. Sionic AI의 박진형이라고 합니다. 흥미로운 이야기 기대됩니다.

-- 그래서 소개해 주신 대로 제가 지난 8월쯤에 Claude Code 사용량이 한 5억 원 정도의 토큰 사용량이 있었고 그러다 보니까 이게 나름 훈장 같다고 생각이 들었어요. 왜냐하면 이게 결국에는 AI를 많이 쓰는 사람이 결국에는 더 많은 지혜라고 해야 되나요, 지혜를 얻기도 하고, 결국 이 지혜라는 것은 내가 어떻게 하면 이 AI라는 친구한테 더 좋은 인풋을 넣고 이 친구의 아웃풋이 있을 텐데 어떻게 잘 활용할 수 있을까, 이런 고민들을 해야 하는데 어떤 특정 시점에서는 마치 양치기를 하는 것처럼 사용을 해야 그 특정 AI 모델의 behavior나 아니면 선호하는 형태를 알 수도 있다고 생각하거든요. 그러다 보니까 이 AI한테 최대한 많은 일을 맡기면서 이 지능적 잠재력을 최대한으로 끌어낼 수 있을까 이런 고민을 많이 했습니다. 이러면서 토큰을 정말 많이 사용했던 거죠. 실제로 5억 원이 사용된 거는 아닌 거죠? 청취자분들이 깜짝 놀라실 수 있을 것 같아서. 사람들이 제일 많이 헷갈려 하시는 게 실제로 한 달에 5억 원을 냈다고 생각을 하시는데 한 달에 5억 원을 낸 건 아니고 200불이죠. 200불짜리 계정을 한 3개 정도. 그러면 저희가 600불을 가지고 5억 원을 만드는 오병이어의 기적 같은 걸 만드는 거죠. 600불이면 한 80만 원 정도 사용해서 5억 원어치의 토큰을 사용했다고 보시면 되고 재미있었던 게 제가 LinkedIn에 올리니까 어떤 분은 회사에서 Claude Code에 계정 지원을 요청할 때 저 Sionic이라는 회사에서는 어떤 직원이 한 달에 5억 원을 쓰는데 우리 회사는 30만 원도 투자를 못 하냐 이렇게 설득해서 전 직원이 도입했다는 그런 미담도 들어서 굉장히 여러모로 의미가 있었다고 생각합니다. 많은 사람에게 도움이 되는 LinkedIn 포스팅이었습니다. 생각하고 ccusage가 그런 것을 측정해 주는 건가요? ccusage는 여기 보면 Claude Code 토큰 사용 리포트라고 해서 로컬에서 Claude Code를 사용하면 사용한 만큼 토큰 기록이 남습니다. 얼마나 토큰이 사용됐는지 그럼 데일리로 환율에 따라 계산해서 '너는 이 정도의 토큰을 사용했다'라는 게 오는 거죠. Sionic 리서치팀에서 Claude Code를 굉장히 많이 사용하고 있는 Claude Code뿐만 아니라 Codex나 Qwen Code 같은 걸 많이 사용하고 있는데 그러다 보니까 예를 들면 이런 얘기도 하죠. 하루 사용량이 500불이 안 되면 오늘 일을 안 하셨네요, 업무를 안 하셨네요. 이런 식으로 농담을 하기도 하고 그런 것들이 굉장히 흥미롭고 재미있습니다. 제가 지난 8월에 manifesto 같은 것도 한번 제가 Claude Code를 시켜서 만들어봤어요. 한 6월쯤이었는데 개인적으로 Agile Manifesto 이런 것들을 프로그래밍 처음 공부할 때 읽어보기도 하고 이런 철학들이 있구나라는 생각을 했는데 요즘은 AI와 함께 업무를 해 나가야 하는 새로운 세상의 시작점에서 manifesto를 만들어서 배포하면 사람들이 좋아하지 않을까. 이게 Claude Code가 유행을 타기 조금 전이었어요. 이게 6월 말, 5월 말 이 정도여서 이때는 5억은 안 썼고 이때 한 5천만 원 정도 쓴 것 같은데 한 달에 5천만 원 정도 사용을 하면 이게 또 다른 영역이잖아요. 5천만 원어치의 토큰을 사용한다는 것은 그러면 그에 대한 결과물이나 아웃풋도 결국에는 어떻게 검증할 것인가. 그리고 어떤 모델을 사용해서 만들면 5천만 원을 써야 할 것인가.
-- 그리고 아까 승준님께서 말씀해주신 것처럼 사용한 토큰 자체가 얼마나 유의미한가. 이런 것들도 사실 많이 고민해야 하는 그런 측면이 있다고 생각하거든요. 제가 이런 고민을 담은 것을 프로젝트에 넣어서 manifesto를 만들어서 GeekNews나 Hacker News에 올렸었는데

-- 그러나 GeekNews에 악플이 달려서 내용이 뭔지 간단하게 소개해 주실 수 있을까요? 일단 첫 번째로 제가 작성했던 manifesto는 AI가 못할 게 없다고 생각해야 한다. 그러니까 불가능은 없다고 생각해야 한다고 생각해요. 불가능은 없다는 그런 마인드, 그다음에 두 번째는 이건 제 개인적인 철학과 비슷한데 최대한 좋은 모델을 잘 선별해서 써야 한다. 예를 들면 GPT-5 Pro가 좋으니까 GPT-5 Pro만 쓰는 게 아니라 예를 들면 파이썬은 파이썬 코드 컨벤션 같은 걸 잘 지키는 건 주로 Claude가 잘 지키는 그런 성향이 있고, 아니면 고차원적인 사고를 요구하는 critical thinking을 요구하는 것은 GPT-5 High가 굉장히 잘하는 측면이 있고 그다음에 README나 문서 작성 같은 것은 굉장히 Gemini가 잘 하기도 하고 어떤 특정 모델을 주력 모델로 주포를 하나 선택하고 그러면 그 주포 모델로 쭉 가는데 또 반대로 그 주포 모델만 사용해서는 안 된다는 거죠. 왜냐하면 그 모델 자체도 굉장히 편향성이 있을 수도 있으니까. 그럼 특정 시점에서는 예를 들면 다른 모델을 호출해서 디베이트를 시켜서 B 모델이 코드 리뷰를 할 때 만족시킬 수 있을 정도로 A 모델을 설득하는 그런 과정도 필요하다는 거고. 문서를 작성하기도 하죠. A 모델이 B 모델한테 전달해야 하는데 그러면 Markdown 파일 형태로 전달하니까 Markdown 파일이 나오면 저도 읽어보고 저만의 아이디어도 있을 수 있으니까 저도 AI한테 의견을 개진하는 거죠. 함께 공동으로 작업을 하는 거죠.

-- 그래서 여러 모델을 같이 써야 한다. 이런 manifesto를 제가 작성했었습니다. Agile Manifesto가 기억이 가물가물한데 그게 왼쪽에 있는 가치도 중요하지만 오른쪽에 있는 가치가 더 중요하다 그런 식으로 쓰였던 거잖아요.

-- 그래서 지금 진형님 마음속의 심상이 뭔가가 더 가치 있다는 것을 선언하신 느낌인 거죠. 네, 예를 들면 이런 거죠. 한 모델만 쓰는 것보다는 여러 모델을 쓰는 것이 더 낫고, 값싼 모델보다는 비싼 모델을 앙상블해서 쓰는 게 좋다. 그리고 그냥 컨텍스트에 맡기기보다는 AI가 하고 있는 일들을 분명하게 Markdown 파일로 지속적으로 문서화해서 회람시키는 것이 좋다. 이런 manifesto라고 보시면 되고 거기에 적혀 있는 것도 5천만 원어치 토큰 사용량, 이런 내용이었는데 사람들이 거기에 악플을 너무 많이 달았다. '유지보수는 누가 하냐', '저러면 Ultrathink가 아니라', '마케팅 용어 아니냐', 'hangover think 아니냐' 이런 식의 악플이 달렸었는데 악플을 보던 저희 리서치 팀원은 저거 한두 달 정도 뒤면 사람들이 이것의 가치를 알 것이라고 했던 것이 기억이 납니다. 그리고 한 달 반 정도 뒤에 Claude Code가 갑자기 이유는 모르겠어요. 갑자기 유명해졌더라고요.

-- 그래서 Ultrathink로 만든 결과물이라고 해서 제가 좀 가져왔는데, 첫 번째는 제가 요즘 취미로 하고 있는 게 뭐냐면 요즘 Google DeepMind가 페이퍼를 많이 냅니다. 많이 내는 것 중에 예를 들면 이미지 쪽으로도 많이 내고 아니면 텍스트 임베딩 쪽으로도 많이 내고, 이런 다양한 페이퍼를 내고 있는데, 보면 implementation이 없거나 아니면 implementation이 굉장히 한 부분만 되어 있는 상태에서 특정 코드 베이스의 일부분으로 이렇게 들어가는 경우들이 있어서 저는 이렇게 생각하는 거죠. 단순히 보는 게 아니라, 결과물이 있으면 좋잖아요. 결과물이 있으면 실제로 보여주는 게 있고 사람들한테 증명을 할 수 있고, 그러면 이 'paper to code'라면 어떨까? 만약에 유명한 논문이 될 것 같은데, 이걸 실제 결과물로 내가 만들어서 뽑아내면 어떨까? 그런데 기존이라면 이런 것들을 하는 데 굉장히 많은 시간이 쓰이거나 내가 많은 공수를 들여야 할 텐데, 물론 이걸 안 들인다는 건 아니지만 AI랑 이렇게 함께하면 내가 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 중에서 3, 4, 5만 하고 나머지 일은 사실 얘한테 delegation을 해도 괜찮은 거죠.

-- 그래서 가장 유명했던 게, 제가 몇 가지가 있는데 그중 하나를 가져온 게 MuVera라고 해서 cost를 좀 싸게 사용해 보자는, 그러니까 멀티 벡터라는 이 임베딩 방법을 굉장히 싸게 잘 사용해 보자는 딥러닝 페이퍼가 이게 7월인가 6월에 나왔었는데, 이걸 저희가 Claude Opus 4.1이나 그다음에 Gemini 2.5 Pro를 함께 사용해서 제가 이걸 implementation했습니다. 선릉에 있는 사우나에서 제가 새벽 1시에 '이거 해보면 재밌겠다' 싶어서 한 4시간 정도 같이 대화하면서 만들었는데, Gemini 2.5 Pro랑은 논문 리뷰를 하고 그다음에 이 친구한테 구체적으로 technical implementation에 대한 스펙 사양을 Markdown으로 같이 최종적으로 작성한 다음에 이걸 Claude Opus 4.1한테 돌린 거죠. 웃긴 포인트가 있었던 거 아니에요? 지금 이 친구가 누구예요? Claude Code. Claude Code. 사우나에서요. 네, 사우나에서요. 선릉 사우나에서. 사우나 하다 말고 코딩을 하셨던 거예요? 잠이 안 와서 뭘 할까 하다가 이걸 했습니다. 제가 조금 코멘트하면, 지금 저희가 말하고 있는 MuVera라는 논문과 구현체가, 지금 저희는 되게 쉽게 이야기하고 있잖아요. 이게 제가 볼 때는 다음 검색을 바꿀 새로운 제너레이션의 시작이에요. 그런데 이걸 그냥 사우나에서 조금 하다가 시작한다는 게 엄청난 일인 거죠. 제 생각엔 한 5년 뒤, 3년 뒤에 이 접근 방법 외에는 거의 모든 검색이 사라질 것 같아요. 그 정도로 압도적인 일입니다. 그런데 이런 일들이 되게 쉽게 갑자기 사우나에서 벌어지고 있고, 이게 저번에 석현님, 이 Pinecone 대표가 뭐 이렇게 마음에 안 들어 할 거다, 그 맥락하고 관련이 있는 건가요? 맞습니다, 그것입니다. 제가 볼 때 이것 때문에 벡터 DB 회사가 다 사라질 것 같아요. 일단 그런 맥락이 하나 있고, 진형 님 얘기에 저도 좀 코멘트를 해보면, 사실 다들 이런 접근을 생각할 수 있어요. AI 많이 써서 성과 내면 좋죠.

-- 그런데 대부분 생각하는 문제 중 하나가 뭐냐면, 그럼 그걸 어떻게 관리할 거냐. 사실 이런 논의가 되게 많이 있었어요. 지금이 아니라 한 40년, 50년도 더 전에 제가 기억하기로는 콘웨이의 법칙(Conway's Law)이라는 게 있어요. 그게 뭐냐 하면 소프트웨어의 구조가 그걸 만드는 조직의 구조를 닮아간다는 겁니다. 소프트웨어에 3개의 모듈, 4개의 라이브러리가 있다면 아마도 그걸 만드는 회사는 4개의 팀이나 3개의 팀으로 나눠져 있을 것이다. 결국 그 조직의 구조가 소프트웨어에 투영되는 게 있고, 이게 여러 가지 인력적인 문제, 커뮤니케이션 문제이기도 한데, 지금 AI에서 말하는 가장 큰 문제 중 하나는, 제가 생각하기로는 흔히 버스 팩터(bus factor)라고 합니다. 우리 팀원 중 하나가 사고가 났을 때, 버스에 치였을 때 이게 얼마나 문맥이 있느냐.

-- 그런데 이게 이런 Claude Code화되고 AI 에이전트화되면서 누군가를 조롱하듯이 이렇게 이야기를 하고 있어요. "야, 너의 코드는 버스 팩터가 0이야. 그 누구도 알 수 없는 코드야." 그런데 이게 사실 어떻게 보면 많은 시니어분들이 걱정하는 사실이기도 합니다. 저는 반대로 생각해요. 사실 Claude Code가 할 수 있다는 건 버스 팩터가 무한대다. 왜냐하면 '문맥이 왕이다'라는 말 많이 하시잖아요. 최대한 많은 문맥을 AI에 제공해라. 사실 그게 어떤 관점이냐면, 그 문맥은 모두에게 공개될 수 있어요. 그래서 한 사람이 아니라 Claude Code에 나온 어떤 컨텍스트, 그걸 또 정의하기 위해서 했던 저희는 테크 스펙(tech spec)이라고 합니다. 그런 것들이 원형대로 보존돼 있으면 그 누구라도 이걸 재현할 수 있는 건, 어떻게 보면 그렇기 때문에 오히려 버스 팩터가 무한대다. 그리고 아까 콘웨이의 법칙이 얘기했던 것처럼, 조직의 구조를 만약에 소프트웨어에 담는다고 하면 미래에 생산되는 모든 소프트웨어는 무한의 에이전트가 있다는 조직 구조를 투영하고 있을 것이다. 그래서 이게 말이 좀 길어지는데, 제가 겪어본 많은 회사들, 좀 큰 대기업이죠. 그러면 개발자의 숫자랑 코드 리포지토리의 숫자가 좀 비슷했던 것 같아요. 한 1만 명 정도 있는 회사에 개발자가 2,000명이라면 코드 리포지토리가 한 2,000개 정도 되고, 한 1,000명 정도 있는 곳이 오래된 곳입니다. 한 1,000개 정도 있는 것 같아요.

-- 그런데 저희 같은 경우는 개발자가 사실 한 10명 좀 넘을 것 같습니다. 내부 git을 한번 보면 공유하기에는 너무 짜치긴 한데, 한 300~400개 정도 됩니다. 애초부터 저희의 소프트웨어 구조, 그런 것들을 마이크로서비스라고 하죠. 그런 여는 구조가 한 직원이 10배, 30배 있는 것처럼 이미 투영되기 시작했어요. AI로 어떤 제품을 만드는 소프트웨어를 만든다는 가정 자체가 생기면서, 모든 것들이 공개되고 모든 문맥이 남으며, 아까 말한 무한의 버스 팩터로 점점 가고 있다는 거죠. 누군가의 어떤 히스토리나 컨텍스트 사일로가 아예 해체되고 있어요. 이게 저는 굉장히 중요한 시점이라고 보고, 반대로 말하면 이걸 만들 수 있는 회사와 아닌 회사에 엄청난 격차가 생기겠다. 애초부터 그게 중요하지 않다는 거죠. 그걸 감안해서 이 말씀을 들어주시면 더 이해가 잘될 것 같습니다. 굉장히 재미있는 포인트가 있었는데, 지금 레이어가 2개라서 청취하시는 분들이 다시 돌아가서 보시면 오히려 재미있을 것 같아요. 왜냐하면 지금 MuVera의 Python 구현체를 만드는 이야기인데, 그것이 어떻게 가능했는지에 대한 레이어를 한 겹 더 쌓아주셔서 이걸 한번 다시 돌아가서 보시면 또 재미있는 포인트가 되지 않을까 하는 생각이 들었습니다. 맞습니다.

-- 그래서 예를 들면 말씀대로, 고석현 대표님 말씀하신 대로 결국에 하나는 이런 거죠. 프로젝트 하나당 보통 서버를, 그냥 예를 들면 이런 거죠. 사우나에서 '우리 이거 하고 싶다' 하면 그냥 repo로 만든 다음에 그냥 뭐 Claude나 Gemini에게 얘기를 해보고 구현체 만든 다음에 배포를 하는 거죠. 그러면 사실 이게 2~3시간 안에 어떤 새로운 신규 서비스를 배포할 수 있는 거고, 그러면 배포를 했으면 어쨌든 피드백을 받을 수 있으니까 저희 옆 사람한테 주든 앞 사람한테 주든, 이걸 가지고 피드백을 빨리 쌓고 이걸 새로운 컨텍스트로 유지한 상태에서 '이런 피드백이 있으니 어떻게 생각하느냐' 이 내용을 가지고 조금만 뒤로 가서 할 수 있는 거죠. 네, 그렇습니다.

-- 그래서 MuVera 파일을 올리고 나서, 사실 진짜 저는 개인적으로 LinkedIn이 그때 많이 터졌거든요. 이게 터져서 몇 개를 보여드리자면, 일단 외국인한테 연락이 와요. 외국인한테 연락이 많이 와서 MIT 이런 분들이 이상한 얘기를 해요. 그래서 이건 이런 식으로 최근에 모았던 게, Jina에서 Perplexity로 이직을 하셨던 그 왕보라는 사람이 있는데, 이분도 진짜 임베딩 쪽 헤드였던 분이에요. 저런 분께 DM이 오기도 하고, xAI에서 그냥 팔로우를 걸기도 하고, 이런 식으로 굉장히 많은 관심을 받아봤습니다. 주목을 받았고, Kilo Code, 이거 AI 코딩 도구로도 많이 유명한데 여기서 인터뷰도 하나 따왔습니다. 저한테 그런 것도 있었고,

-- 그래서 에이전트 도구를 굉장히 잘 사용하는 방법이라고 저는 하는데, 사람들이 Claude Code를 좀 사용하니까 어느 정도 이 도구에 대해서는 알고 있어요. 그래서 예를 들면 Claude Code랑 바이브 코딩을 하면 예를 들면 프런트엔드 코드가 나온다든가 이 정도의 인식에 좀 멈춰 있는 것 같고 제 관심사는 굉장히 낯설고 내가 잘 모르고 난이도가 높은 요구 사항을 내가 AI와 함께 어떻게 잘 부숴나갈 수 있을 것인가 저는 이게 관심사가 많거든요. 그러다 보니 단순히 휘발적이면 안 되고 예를 들면 단순히 다음 토큰을 뱉는 형태의 구현에서도 안 되고 구현체 하나하나가 굉장히 신중해야 합니다. 당연히 AI와 코딩을 하다 보니까 예를 들면 이렇게 되는 경우도 있죠. 아마 많은 'vibe 코딩'을 하시는 분들이 생각하실 수 있는 게 예를 들면 이런 거죠. 대표적으로 파일을 수정하다가 내가 다른 지시를 같이 넣게 되는 경우가 있는데 그러다 보니 이런 AI 도구가 굉장히 안정적이지 못하게 파일을 수정하는 거죠. 때로는 파일 자체가 깨져버리기도 하고 깨져버리다가 '이것을 과거로 돌리고 싶어'라는 명령을 주니까 특정 변경들이 한꺼번에 다 이전으로 돌아가서 내가 어떤 작업을 했는지 모르게 되는 그런 경우도 많이 있단 말이죠.

-- 그러다 보니까 내가 한 번에 모든 것을 다 해결했다고 해서는 안 되겠더라고요. 이것은 예를 들면 고석현 대표님도 옛날에 이런 얘기를 하셨는데, 자기는 예를 들면 어떤 작업을 할 때 토큰 사용량이 굉장히 적게 나온다. 나는 100불도 안 나오는데 저는 맨날 500불씩 쓰고 있으니까 그 차이가 어디서 날까 고민을 해봤는데 전 이거 같아요. 원래 내가 할 수 있는 만큼의 일을 하면 사실 내가 구체적으로 지시를 주고 내가 어떤 일을 하고 있는지를 명확히 tracking을 하니까 그러면 나의 범위 안에서 나를 대신해 주는 친구처럼 되는 건데 예를 들면 내가 기본적으로 잘 모르거나 내가 하지 못했던 일들을 시도하려고 하면 사실 '해줘'가 되는 겁니다. 구체적인 요구 사항이 있는 게 아니라 내가 최종 output만을 가지고 대화를 할 수밖에 없는 거죠. 그러면 AI 자체도 최종적으로 output을 원하는 유저가 있긴 한데 그 안의 과정들이 많이 생략되어 있으면

-- 그러면 AI 입장에서도 그 과정에서 작업 자체를 굉장히 혼란스럽게 하는 경우도 있단 말이죠. 그러다 보니 최종적인 output을 받는 사람 입장에서도 만들다 만 느낌이 들기도 하고 그러면 내가 어디서부터 어디까지 피드백을 줬는지 모르겠다라는 그런 혼란의 상태에 주로 빠지게 됩니다. 사실 이런 상태가 되면 가장 최악이고 사전에 이런 상황을 막을 필요가 있고 저는 그 방법 중 하나가 내가 뭘 하고 싶은지, '너 자신을 알라'에 가까운 것 같아요. '너 자신을 알라'가 되려면 지금 만들려고 하는 게 도대체 무엇이냐를 명확하게 해야 되고, 명확하게 예를 들면 사전에 어떤 스펙의 문서나 사양을 작성할 필요가 있다는 거죠. 재미있는 게, 예를 들면 Agile Manifesto를 보면 문서보다는 돌아가는 코드가 더 중요하다는 이야기를 하잖아요. 그럴 수밖에 없는 이유가 코드의 변경을 만드는 것은 굉장히 어렵고 문서로 얘기하는 건 탁상공론이 될 가능성이 높으니까 저는 그런 얘기를 한다고 생각하는데 반대로 이제 생각해보면 오히려 문서, 그러니까 코드를 작성하는 행위 자체는 너무나도 쉬운 행위예요. 너무나도 쉬운 행위인데, 내가 뭘 하고 싶은지를 스스로 납득하는 것 자체가 너무나도 중요한 거죠. 어찌 보면 동작하는 코드는 너무 빨리 만들어지니까 저는 그런 관점에서 예를 들면 코딩 AI 도구를 사용하기 전에 먼저 GPT-5 같은 어떤 Pro나 이런 친구들과 함께 예를 들면 주로 Markdown 형태로 내가 어떤 스펙이 있는지를 먼저 이 discussion을 충분히 하고 나도 동의가 되고 내 앞에 있는 AI 모델도 동의가 되고 옆에 있는 Gemini 모델도 동의가 되고 3자 OK가 된 상태에서 저는 작업을 시작하거든요. 그리고 작업 안에서도 하나만 읽으면 이것을 다 해달라는 게 아니라, 지금 이 상태에서는 이 작업을 먼저 하는 게 좋을 것 같다고 하면 그 특정 scope만 최대한 줄여서 코딩 CLI 도구는 최대한 파일 편집 자체에 집중하고 완결성 있는 코드를 작성하는 것에만 집중하도록 코딩 CLI 도구의 부담을 많이 줄여주는 게 필요하다고 저는 그렇게 보고 있습니다. 예를 들면 제가 사용하는 tech spec의 일부인데요. 예를 들면 여기서는 이런 background나 goal이나 non-goal 이런 것들이 있으면서 너는 이런 proposed change에 이런 것들을 구현해야 한다. goal을 만족시키기 위해서 이런 변경을 만들어야 되고 저런 변경을 만들어서는 안 된다는 것도 코드와 함께 굉장히 구체적으로 명시를 시킵니다. 그리고 이 spec 문서를 회람해서 미리 다 Gemini Deepthink나 이런 친구들한테 회람시켜서 OK 사인을 받은 것을 CLI에 던지는데

-- 그러면 코딩 CLI 도구가 잘할 수 있는 것은 지금 내가 가지고 있는 codebase의 맥락을 굉장히 잘 아는 친구거든요. 왜냐하면 내가 모든 codebase 작으면 다 넣으면 되지만 어느 정도 동작하는 production level의 codebase에서는 코딩 CLI 도구가 주목받는 이유가 codebase를 좀 더 명확하게 가져올 수 있기 때문에 grep이나 아니면 다양한 Linux의 tool을 사용하는 것이 가능하기 때문에 사람들이 '코딩 CLI 도구가 좋아' 이렇게 느끼는 건데

-- 그러면 이런 function call을 할 수 있으니까 그러면 지금 이런 문서 회람이 있으니 너가 가진 최대한의 능력을 발휘해서 지금 어떤 일을 해야 할 것 같은지를 네가 스스로 TODO.md를 작성해서 '스스로 너의 계획을 세워봐라'라고 하는 거예요.

-- 그러면 네가 스스로 너의 계획을 세우면 이걸 다시 저는 Gemini나 아니면 GPT-5-pro한테 다 회람시키죠. 이런 plan.md가 나왔고 이런 계획들이 있는데 이런 세부 계획을 어떻게 생각하느냐 이 세부 계획을 단순히 approve 하겠습니까? approve 하지 않겠습니까? 만약 approve 하지 않는다면 어떤 이유인가 이런 것들을 충분히 discussion을 하는 거예요. 충분히라고 하는 것은 모든 모델이 다 accept를 하기 전까지 다음 작업을 하지 않는 거예요. 만약 이것들이 다 accept됐다고 하면 이런 것들을 보면 TODO.md 하나하나가 다 있잖아요. 1번, 2번, 3번, 4번 그러면 이것 하나하나가 예를 들면 코딩 CLI가 내가 코딩 CLI 도구를 켜서 이것을 마감하고 리뷰를 하고 commit을 하는 하나의 작은 cycle을 만드는 게 이 하나하나의 task가 됩니다. 그리고 하나의 대화 turn은 이 한 줄, 이 sub-task 하나를 코딩 CLI 도구가 완성하고 그다음에 이것들에 대해 test를 돌리고 그다음에 이것을 어떻게 변경했는지에 대해서 나한테 충분히 briefing을 해라. 그럼 내가 briefing을 읽어보고 옆에 있는 모델, 앞 모델한테 물어보고 OK 사인이 나면 그다음, 그다음, 그다음 일, 이렇게 반복하는 거죠. 이것을 최대한 많이 자동화하려는 시도를 하고 있고 그리고 그 과정 안에서 남들은 예를 들면 100토큰 이렇게 쓸 건데 예를 들면 저는 5,000토큰 이렇게 쓰게 되는 겁니다. 왜냐하면 이런 iteration이 굉장히 빨리 많이 돌게 만드는 것이 사실 제 관심사에 있기 때문이죠. 코딩 들어가기 전에 쓰는 토큰이 지금 되게 많은 거네요. 그렇죠. 이거 농담이지만 그 옛날 사람들만 아는 '신세기 에반게리온'의 MAGI 시스템 생각이 나거든요. 왜냐하면 거기서도 3개의 컴퓨터가 합의를 이뤄야 뭔가를 하기 때문에 최근 굉장히 유명한 AI 스타트업 중 한 곳에 GPU 서버 3대가 있습니다. 그 세 대의 이름이 지금 말씀하신 동방박사 3인의 이름이에요. 그렇군요. 발타자르, 이렇게 해가지고 지드래곤 나오는 그 회사입니다. 지금 들으면서, 요새 또 많이 유행했던 용어가 surgical이라는 표현이었거든요. 외과 수술적인 prompting, 정확하게 pin point에서 그걸 할 수 있게 하는 그런 맥락하고도 되게 공명하는 그런 느낌의 말씀을 해주시네요. 사실 AI 모델과 같이 작업을 하다 보면 좀 hangover한다는 느낌이 있긴 하거든요. 사실 위에서 hangover한다, 이런 말이 있었는데 사실 맞는 말이에요. 왜냐하면 그냥 돌려놓고 '되겠지'라고 하면 아무것도 되지 않기 때문에 왜냐하면 이 친구가 머리가 좋은데 일을 안 한다고 생각해야 해요. 머리가 좋고 일을 안 하고 굉장히 뺀질거려서 '안 되는데 됐습니다' 'You are absolutely right!' 이런 말을 하는 친구니까 얘를 잘 앉혀놓고 '너는 ADHD인 것 같으니까 잘 관리하고, 애걸복걸하고, 달래고' 이런 과정들인 거죠.

-- 그래서 사실 사람은 이런 걸 하고 있고 실제 코딩은 AI가 하고 어찌 보면 제가 매니저가 됐다는 느낌이 있는데 여기를 두텁게 쌓아놓으면 그다음에 코딩은 차라리 일사천리로 토큰을 덜 쓴다는 거죠. 그야말로 implementation 과정에 지나지 않는 그런 것이 되는 것 같아요. 맞아요. 사실 제가 하는 방법이 대단한 건 아닙니다. tech spec을 회람시키고 TODO.md를 회람시켜서 각 상호 동의가 되면 그다음 작업에 들어간다. 그 작업도 이것 하나하나별로 CLI를 켠다. 생각보다 이런 접근을 하는 분들이 많이 없더라고요. '내가 원하는 것을 넣으면 나오겠지' 좀 주술적인 코딩을 하시는 분들이 너무 많아서 'vibe 코딩'과 Ultrathink! 엔지니어링은 다르다고 저는 계속해서 주장하는 겁니다. 제가 느끼는 게 있는데요. 요즘 마치 AI 모델을 쓰는 게 한 10명에서 100명 정도 있는 개발 조직을 리딩하는 CTO처럼 느껴져요.

-- 그래서 한 사람을 쓰는 게 아니라 한 10명에서 100명 정도 리딩한다는 느낌으로 쓰는 게 훨씬 압도적으로 많은 가치와 성과를 내고 있고 이미 우리가 에이전트와 대화하는 게 아닌 것 같은 거죠. 조직을 경영하는 것처럼 보입니다. 진형 님이 얘기해 주신 걸 종합하면 저는 그렇게 느껴지거든요. 실제로 제가 하는 일이기도 하고 그런 느낌입니다. 또 여기서 떠오르는 게 저번에 강규영 님하고 대화를 하다가 waterfall이 오히려 가능해진 시점 아니냐라는 얘기를 하셨는데 예전에는 waterfall이 힘들고 진화했는데 지금은 복잡한 문서를 체계적으로 만들고 traceable하게 하는 일들이 너무 쉬워졌기 때문에 오히려 앞단의 계획을 충실히 하는 것이 작동하는 것이 아니냐 하는데 맥락이 좀 비슷하게 느껴져서 지금 흥미롭게 듣고 있습니다. 네, 맞습니다. waterfall이 잘 안 돌았던 이유가 사실 저희가 implementation에 걸리는 시간이 굉장히 크고 길었기 때문이고 그 기간 동안 세상이 변했기 때문에 그 사이에 원래 짰던 계획은 변하기 마련인데 그 implementation이 없어지니까 그렇죠.

-- 그런데 진형 님이랑 고 대표님이 말씀하시듯이 일 잘하시는 분들은 사실 이건 꼭 코딩이 아니더라도 문제를 잘 정의하고 그 문제의 scope를 안에 이렇게 잘 어떤 형태로 이렇게 네트워크가 구성되어 있는지 그것을 머릿속에 잘 넣으시는 분들 그러면 그분들의 특징이 다 그거거든요. 그 안에서 중요하지 않은 문제와 중요한 문제, 에너지가 굉장히 많이 투입돼야 하는 부분과 그냥 너무 쉽게 돼야 하는 부분들, 이런 것들을 잘 가리시죠. 그리고 나서 그게 다 하나의 완결된 계획표로 나오면 그때 실행에 들어가면 사실은 결과가 좋을 수밖에 없는 거죠. 그리고 좀 중요한 게 저는 개인적으로 요즘 많이 알려진 claude.md 혹은 agent.md 마크다운으로 어떤 특정한 instruction을 강제하는 것이 유명하죠. 유명한데 예를 들면 agent.md 어떤 게 좋다, 이런 게 돌아다니기도 하고

-- 저는 개인적으로 제가 사용하는 agent.md 스타일이 있고 이것을 제가 언어별로 관리를 합니다. 예를 들면 언어별로 관리한다는 것은 예를 들면 저희 회사 안에 Go나 아니면 Rust 같은 것을 사용하시는 분들도 굉장히 많이 있는데 굉장히 어떤 특정 언어나 프레임워크에 대한 이해가 있는 분이 있다고 하면 굉장히 capable한 엔지니어가 작성한 코드를 가지고 그것을 어떻게 잘 나의 것으로 흡수할 수 있을 것인가, 내가 나의 것으로 distillation을 할 수 있을 것인가, 이런 고민을 하다 보면 그럼 결국에 이것을 도와주는 친구들이 AI일 수밖에 없다. 너는 이런 굉장히 best practice 같은 코드가 있는데 이것을 바탕으로 너가 교훈을 한번 얻어봐라. 그 사람이 쓴 Slack thread일 수도 있고 그다음에 말한 발화일 수도 있고 이런 것들을 굉장히 종합적으로 제공하면

-- 그러면 이 사람은 이런 코드 스타일이 있는 것 같고 이런 상황에서는 저런 방어 로직을 작성하는 것 같다, lesson을 뽑아볼 수가 있거든요. 그러면 그 lesson을 뽑고 언어별로 관리를 하는 거죠. 예를 들면 Kotlin을 잘하는 사람은 kotlin.md, Go를 잘하는 사람은 golang.md.

-- 그러다 보니까 이 에이전트라는 것도, 이 마크다운 파일 같은 것도 언어별로, 프레임워크별로, 혹은 특정 task별로 사람의 어떤 heuristic을 잘 distillation하고 그 distillation을 최대한 AI 모델이 시스템 프롬프트 안에서 그것을 모방하도록 만들 수 있습니다. 저는 그런 식으로 관리를 해서 사용하는 편이고 그러다 보니까 저는 개인적으로 agent.md를 Kent Beck이 사용하고 있다고 최근에 올라왔던 그것을 바탕으로 agent.md를 저만의 variation을 만들어서 많이 사용하고 있습니다. 특히 제가 아까 말씀드렸듯 한 번에 하나의 일을 하고, 하나의 일을 한 다음에 회람시키고 이런 것들에 대한 구체적인 행위를 강제할 수 있는 방법이 두 가지가 있는데, 하나가 agent.md 같은 시스템 프롬프트로 관리하는 것, 다른 하나는 특정한 파일이 수정되었으면 무조건 그 행위가 돌도록 rule base를 만드는 것. 이 두 가지가 있는 것 같은데 일단 하나의 큰 축으로서 이 agent.md를 좀 활용하고 있어요. AI 상황에서 굉장히 유리한 언어가 있을 것이고 프레임워크가 있을 것 같다는 생각을 많이 하거든요. 특정한 AI 모델이 학습하는 코딩 데이터에서 분포가 많은, ratio가 많은 그런 언어가 굉장히 유리할 수 있겠죠. 이런 전제는 당연히 있고 그러면 내가 AI가 잘하는 언어, 즉 AI가 많이 봤을 것 같은 언어를 나는 선택해야겠다는 생각을 기본적으로 갖고 있어요.

-- 그런데 예를 들면 이런 거죠. Go가 예를 들면 AI에 맞을 것 같다는 말을 어떤 분이 하시더라고요. 어떤 분은 Rust가 굉장히 AI 친화적인 언어라고 주장하시는 분들도 있는데 컴파일러가 어떤 특정 상황에서 오류를 뿜어낼 때 다른 언어들에 비해서 어떤 부분에서 문제가 있었고 어떻게 고치면 해결될 수 있는지, 이것을 충분히 rule-based로 친절하게 가이드를 주는 언어이기 때문에 이런 언어들이 유리할 것이다, 이렇게 판단하시는 분들도 있고 저는 이 관점이 굉장히 좋은 것 같아요. 그러니까 특정 언어가 의미가 있다기보다는 컴파일러가 최대한 친절하게 AI에 context를 다시 제시해 줄 수 있는가. 그러면 AI는 어쨌든 굉장히 비결정적인 시스템이니까 만들다가 실수를 할 수도 있겠죠. 그러면 '당신은 실수를 했고 지금 이것은 빨리 고쳐야 한다', '어떤 특정 부분에서 수정을 해야 한다'라는 명확한 피드백을 빠르게 제공하는 것이 나중에 가서 수습 못 하는 문제를 막을 수 있단 말이죠.

-- 그래서 저는 이런 것들을 굉장히 중요하게 생각하고 있고 예를 들면 Python은 많이 사용할 수밖에 없는 언어입니다. AI에서 여러 가지 이유로 그러면 이 Python은 사실 굉장히 자유롭고 분방한 친구이기 때문에 그러면 이런 친구들한테 어떻게 이런 컴파일러가 있는 것처럼 모사해서 최대한 빠르게 이 AI의 실수를 캐치하고 '네가 지금 하고 있는 일을 다 중단하고서라도 이 실수를 고치고 가라'는 이런 커뮤니케이션을 명확하게 할 수 있을까를 봤을 때 type checker가 몇 개 있습니다. Python 툴이 몇 개 있고 이것을 예를 들면 Makefile로 만들어서 특정한 command를 항상 shell script처럼 실행할 수 있도록 만든 다음에 이것을 예를 들면 Claude Code hook 같은 기능에 붙여서 hook 은 이런 겁니다. 그러니까 특정한 function이 호출됐을 때, 예를 들면 edit file이 됐을 때, new file이 됐을 때, 혹은 multi-edit이라는 것이 호출됐을 때 파일을 수정, 삭제, 추가하는 거죠. 이것을 했을 때 너가 항상 명시적으로 formatter를 돌려라, linter를 돌려라, 너가 명시적으로 type check를 돌려라. type check도 예를 들면 한 2~3개를 같이 ensemble로 쓰는 거고요. 2~3개를 동시에 사용해서 이 모든 rule-based type checker들이 에러가 없다고 말하면 그러면 '너는 이 하나의 task를 완전하게 수행한 거야'라고 하고 그다음 task로 가기 전에 checkbox에다가 체크를 하고 그것을 체크한 다음에 그다음 next step으로 넘어가도록 이런 행위를 시스템, claude.md나 agent.md에 명시하고 이 작업을 굉장히 집요하게 하도록 만드는 거죠. 이쯤에서 정석님과 제가 context를 한번 압축하고 가야 하지 않나요? 청취자분들의 이해를 돕기 위해서 이해한 바를 한번 말하고 가는 게 좋지 않을까요? 어떻게 할까요? 일단 저는 재미있게 듣긴 했는데 조금 앞으로 올려주시면 컴파일러의 비유를 지금 말씀하시는 거잖아요. 컴파일러가 빌드할 때 에러가 나면 진행이 안 되는 거잖아요. 실행 안 하고,

-- 그래서 거기서 되게 유의미한 피드백이 오류 메시지같이 나와서 그것을 LLM에 주는 방식으로 하자는 거죠. 그렇죠.

-- 그래서 그런 이유 때문에 Go나 Rust를 좋아하시는 분들이 많아요. 환경 세팅할 필요도 없이 binary 하나로 그냥 싹 묶여서 그 실행 파일이 떨어지니까 그것을 깔끔하다고 해서 좋아하시는 분이 많이 있는 것 같아요. Python은 그게 안 되니까 그것처럼 하려고 지금 linter나 checker 같은 것들이 붙은 거죠.

-- 그래서 저희가 방금 한 얘기는 곁가지인 것 같고 진형 님이 deliver하시려고 했던 핵심 메시지는 이 언어가 무엇이 되었건 간에 최대한 많은 정보를 Claude Code나 AI에게 다시 되먹임시킬 수 있는 그런 일종의 harness를 잘 까는 게 훨씬 유리하다. 그것도 마찬가지로, 코드를 진행하기 전에 그 정보를 얻어내야 한다는 코드를 진행하기 전에도 얻고, 작성한 뒤에도 이것을 명시할 필요가 있다. 코드를 작성한 뒤에 체크하는 과정이 있어야 된다. 그리고 진형 님이 말씀하시는 것들을 정말 상위로 올라가서 딱 요약해보면 지금 이것들을 다 테스트하고, 구현하고, 에러를 고치고 이렇게 하는 데 들어가는 비용이 지금 0에 수렴하고 있는 그런 신기한 세상에 살고 있기 때문에 이러한 일들을 더 많이 시키면 시킬수록 그 일의 최종 수혜자인 나에게는 압도적으로 유리해진다는 일관된 메시지를 지금 전달하고 계시는 거거든요. 여기서 분기가 갈리는 게 Claude Hook은 조금 더 시스템적으로 harness가 작동을 하는 거잖아요. LLM한테 맡기지 않고 결정론적으로 작동하는 거니까 그 부분의 얘기를 좀 더 풀어주시면서 하면 되게 좋을 것 같습니다. 결국에는 내가 특정한, 그러니까 어떤 행위를 내가 안 하도록 강제로 하고 싶은데 이걸 하지 않을 수도 있거든요. 결국 이게 비결정적인 시스템이기 때문에

-- 그러다 보니까 마치 이런 거죠. 아까 조직 얘기도 했는데 어르고 달래는 것처럼 "이걸 해주세요, 해주세요" 하기도 하지만 예를 들면 무조건 이걸 하도록 만드는 규정을 세팅해 버리는 것도 필요한 거죠. 그러다 보니까 항상 이런 외부적인, 그러니까 어떤 특정 function이 호출되었을 때 이런 명령을 실행하도록 한다는 어떤 rule base도 굉장히 잘 엮어서 사용할 필요가 있고 너무 rule base만 이렇게 많이 사용하게 되면 얘가 자기 작업을 못 할 수도 있습니다. 마치 사람한테 어떤 특정 규칙을 너무 많이 부여하면 자기 일을 못 하는 거랑 비슷하기도 하거든요.

-- 그런데 hook이라는 개념을 잘 모르시는 분들도 있을 수 있기 때문에 hook이 특정 이벤트에 시스템이 트리거하는 거죠. 여기 보시면 post-tool-use라는 게 있어요. 이게 뭐냐면 write를 하거나 그러니까 파일을 쓰는 거죠. edit를 하거나 파일을 수정하는 거죠. multi-edit, 복수 3개 이상 2개 이상의 tool을 동시에 수정하는 것, 이게 있으면 이 특정 shell script를 시행한다는 거고 pre-use일 수도 있어요. 이건 리뷰를 맡기는 거예요. 그러니까 "너 지금 난 이런 작업을 할 거야"라고 사실 thinking하면 명시적으로 내부 사고 과정이 나오는데 그럼 사고 과정을 예를 들면 이것마저도 리뷰를 맡겨버릴 수도 있어요. "얘가 올바른 사고 과정을 하고 있는 게 아니야?" 아니라고 하면 중간에 빨리 개입해서 다른 path로 바꿔줘, 이런 것도 가능하긴 한데 주로 post-tool-use, 이런 format checker, 이걸 기본적으로 사용하는 편입니다. 그러면 거기에 얽혀 있는 shell script가 실행되면서 다시 LLM이 작동하거나 다른 뭔가가 작동하는 그런 식으로요? 맞습니다. 스크립트의 output이 나오면 이 output을 항상 되먹여서 내가 다음 작업을 하기 전에 "이거는 해결하고 가야겠네"라고 만들도록 유도를 하는 거죠. 아까 진형 님 말씀 주신 거에 저희 use case가 있어서 한번 그걸 소개해 보면 어떨까요? 사실 LLM이 잘하는 언어가 좀 한정적입니다. 못하는 언어들이 되게 많아요. 그래서 잘한다, 못한다의 기준은 두 가지일 것 같아요. 코드를 잘 쓰느냐, 써진 코드가 잘 동작하느냐. 그런데 첫 번째도 문제고 두 번째도 문제입니다. 그래서 보통 첫 번째, 잘하는 건 Python을 잘 쓰고요.

-- 그런데 두 번째 문제, 잘 써진 코드가 동작하는 것들은 compiler hint가 많고 타입이 정적인 언어가 훨씬 후자의 성공률이 높습니다. 그래서 저희 쪽 사례를 한번 말씀드리면 일단 저희 제품의 화면 중 하나입니다. 여러 가지 기능이 있는데 그중 하나가 보통 에이전트라고 불리는 workflow를 작성하는 기능이 있어요.

-- 그래서 이런 것들을 사실 코드로 하기가 좀 어려우니까 이런 것들을 GUI 도구로 n8n처럼 이렇게 할 수 있습니다.

-- 그런데 사실 이걸 만드는 과정이 정말 어려워요. 예를 들어 Roblox로 게임을 한다고 하면 Roblox가 아니라 Scratch죠. 엄청나게 어렵다는 걸 혹시 해보신 분들은 알 텐데 그런 것처럼 이런 workflow 도구가 코드보다 어려워지는 지점이 있습니다. 저희가 하고 있는 프로젝트 중 하나가 이거예요. 화면이 지금 보이시나요? 이게 뭐냐 하면 이 workflow도 자연어로 만들겠다는 겁니다. Zapier 이런 데도 있는 기능이고요.

-- 그런데 이게 되게 잘 안 됩니다.

-- 그래서 저희가 하는 방식이 뭐냐면 AI가 잘 쓰는, 그러니까 Python은 아닙니다.

-- 그런데 Python-like한 DSL, domain-specific language를 만들고 거기에 또 Rust로 되어 있는 compiler를 만듭니다.

-- 그래서 이 Rust로 되어 있는 compiler가 Python 언어를 해석해서 저희 workflow 엔진인, 거기는 또 Kotlin이에요. Kotlin 엔진을 사용한 DSL을 만들고 이걸 또 학습하는 강화 학습으로 이 Rust로 하는 compiler가 힌트를 줍니다.

-- 그래서 Python같이 생긴 workflow 전용 언어를 저희 모델이 학습도 하고 모델의 강화 학습을 compiler랑 이 이 도구, Rust가 도와줘서 결국 에이전트를 엄청 잘 만드는 모델을 만들 수 있는 거죠. 데이터가 별로 없어도요.

-- 그래서 이런 복합적인 엔지니어링의 기반이 아까 사실 진형 님이 말씀해 주신 LLM의 한계와 장점에 좀 기인하고 있어요. 아까 좀 전에 블록, 그러니까 diagram 형태로 보여준 게 만드신 DSL의 껍데기인 거예요, 그러면?

-- 그런데 이 DSL은 사실 화면도 잘 그려야 되고 실제 이걸 실행도 해야 합니다. 예를 들면 저희는 이런 에이전트를 한 몇천 개에서 1만 개 정도 운영하는데 그걸 1만 개의 서버를 띄우거나 1만 개의 Python 파일을 만들 수 없잖아요. 그러니까 이 DSL이 그냥 DB에 들어가 있고 실행되는 시점에 호출되게 됩니다. 그걸 Python으로 할 수도 없고요. diagram 류가 아까도 Scratch 예를 들어주셨지만 좀 뭘 제대로 하려고 하면 화면 복잡도가 기하급수적으로 늘어나는 문제가 있는데 그걸 다시 추상화시켜서 압축해 놓은 diagram인 거죠. 네, DSL 생성은 다 자연어로 하고 수정은 DSL로 하되 그 중간 과정에 compile이나 이런 것들은 Rust나 Kotlin이나 이런 언어로 쓰이는 거죠. 매우 난이도가 높은 내용일 수 있지만 재밌습니다. 네, 다시 진형 님 받아서 hook 다음으로 가시죠.

-- 그러다 보니까 아까 고석현 대표님이 말씀하신 것처럼 그런 제가 지금 하고 있는 workflow 같은 어쩌면 제가 가지고 있는 heuristics도 몇 개 있거든요. 그럼 이걸 어떻게 하면 내가 잘 자동화할 수 있을까. 아까 소개해 주신 workflow 엔지니어링도 제가 시작한 프로젝트이고

-- 그러다 보니까 관심 있는 사람들이 많이 있어서 이걸 한 2~3명 정도 사내에서 팀을 꾸려서 이 프로젝트들을 계속 진행하고 있습니다. 진행하고 있고

-- 그러다 보니까 이런 것들도 좀 중요한 것 같아요. 어떻게 하면 이렇게 좀 만들어진 에이전트들을 CLI 도구의 어떤 특정한 상황에서 명확하게 호출하도록 만들 수 있을까. 어떤 checklist를 호출하는 이런 형태였다면 지금은 어떻게 내가 에이전트를 좀 잘 만들게 할 수 있을까, 호출을 만들 수 있을까라고 보는 거고

-- 그러면 사실 요즘에는 MCP 같은 형태의 표준화된 규격으로 호출할 수 있기 때문에 굉장히 좀 붙이기가 쉽습니다. 에이전트를, 그래서 에이전트에 연동 방법인 거죠. MCP는,

-- 그러면 제가 좀 주로 사용하고 있는 MCP를 몇 개 소개해 드리면 하나는 DNP나 이런 건데 그러니까 뭐냐 하면 이건 그런 거예요. 제가 아까 말씀드렸듯이 예를 들면 Gemini 2.5 Pro 같은 거를 내가 중간중간마다 피드백을 주고 리뷰를 하도록 내가 만들고 싶다고 하면 그럼 이 특정 상황에서 어떻게 호출할 것인가도 굉장히 중요하고 그다음에 내가 호출하고 나서 어떤 일을 시키는 게 중요합니다. 예를 들면 "너는 무조건 이걸 비판적으로 보아라"라고 하는 게 굉장히 좋을 수도 있거든요. 저는 최근에 있었던 얘기 중 하나인데 뭐냐 하면 저희 회사가 일본 지사도 있고 동남아 쪽 지사도 있는데 그럼 사내에 예를 들면 일본어나 특정 현지 언어를 굉장히 잘하시는 분들이 같이 일할 수 있는데 예를 들면 저도 커뮤니케이션을 현지 담당자랑 고객사랑 할 때도 좀 많이 있는데 그러면 그런 고객사들과 대화를 할 때 제가 직접 이메일을 발송하거나 전송해야 하는 그런 상황들이 좀 발생합니다. 그럼 제가 알기로는 그냥 Gemini나 이런 데 해가지고 번역을 해서 보낼 수 있는데

-- 그런데 그것보다는 저는 어떤 오기가 좀 드냐면 그러면 내가 저 옆에 있는 언어 전공자들보다 더 잘하고 싶다. 그럼 내가 어떻게 해야 저 언어 전공자보다 잘할 수 있을까.

-- 그러면 결국에는 AI가 가지고 있는 역량을 최대한 끌어내는 거죠. 뭐냐면 "네가 지금 어떠한 translation output을 만들었는데 그럼 translation output을 가지고 이건 마음에 안 들어. 왜냐하면 이건 내가 전달해 보니까 자연스럽지 않고 현지인이 봤을 때 굉장히 이상해"라고 억지로 비판을 하는 거죠. 억까를 하는 겁니다.

-- 그러면 얘가 "죄송합니다" 하면서 어떤 특정한 예시를 주면서 "나는 이런 것들을 잘했어야 할 것 같습니다"라고 스스로 자아비판을 하거든요.

-- 그러면 이걸 한 2~3번 반복해서 나온 어떤 output이 옆에 있는 언어 전문가들을 봤을 때 이게 실제로 현지인이 썼다고 해도 무방한 수준이라는 이야기를 듣고 굉장히 깜짝 놀랐던 적이 있습니다. 이런 role-playing이라고 하죠. role-playing을 굉장히 잘 주는 것도 필요하고

-- 그러면 내가 어떤 특정 상황에서는 어떤 모델과 어떤 role-playing을 시키는 게 굉장히 유의미하겠다는 것들을 동적으로 판단할 필요가 있고 이런 것들을 굉장히 잘 해놓은 오픈소스 중 하나가 Zen MCP, Serena MCP 이런 것들이 있는데 당연히 이런 것들만 사용해서는 안 되고 예를 들면 제가 이런 것들을 직접 에이전트로 꾸려서 사용하기도 하고 그런 식으로 많이 합니다. 결국 제가 하고 싶은 말은 어떤 특정 상황에서 어떤 모델과 어떤 role-playing을 시켜서 내가 원하는 바를 최대한 이룰 수 있게 만들어야 되고 코드 리뷰라고 하면 최대한 비판을 하는 거야. 네가 의심이 하나도 없을 때까지 끝까지 비판을 쭉 이어나가야 한다. 이런 stance를 강제해주는 것도 필요한 거죠. 그렇게 했을 때 최대한 이 AI가 가진 잠재력을 극단으로 끌어올 수 있다. 지금 진형 님이 코딩에 한정해서 말씀해 주셨는데 이게 어떻게 들으시면 되냐면 우리가 원하는 employee들을, 직원들의 persona를 설정하고 업무 job description을 설정해서 코딩에 넣을 수 있다는 이런 것들에 대해서 지금 얘기해 주시는 것 같이 들립니다. 네, job description이기도 하고 때로는 이게 stance이기도 해요. 리뷰어인데 너는 굉장히 깐깐해서 끝까지 물어뜯는 거죠. 이런 stance를 잘 주는 게 생각보다 중요하더라.

-- 그러면 이런 것이 실행되는 것도 결정적으로 trigger 되게 하는 방식인 건가요? 네, 맞습니다. 어떻게 trigger를 하면 괜찮냐면 이런 sub-task 하나하나 끝날 때마다 trigger를 시킬 수도 있고 전체 task가 끝났을 때 시킬 수도 있고

-- 결국 지금 내가 가지고 있는 이 하나가 PR이라고 한다면 PR의 diff 사이즈, 코드의 변경 사이즈를 보고 예를 들면 이게 100줄 이상 넘어간다고 하면 무조건 이것을 trigger시킨다고 강제할 수 있습니다. 좋네요. 결정적으로 지표가 나오게 한다면 그것에 의해 trigger 되게 하고 ensemble을 쓰고 계속 맥락에서 모델들의 ensemble을 쓰는 것을 강조하시는데 그것의 가정은 같은 모델에서 다른 생성을 하더라도 다른 의견이 나오긴 하지만 그것보다는 다른 모델이, 그러니까 각각의 Gemini, Claude, ChatGPT가 가지고 있는 특유의 성질이 있을 것이라는 가정이 있는 거죠. 네, 맞습니다. 결국 어떤 모델은 강점이 있고 어떤 모델은 다른 장점이 있고 그다음 하나의 모델을 사용하다 보면 자기 스스로 자기 확신에 빠질 가능성이 높습니다. 그렇군요. 일종의 합평회를 진행하고서는 모든 일이 되게 하니까 토큰을 많이 쓸 수밖에 없겠네요. 네, 맞습니다. 합평회를 계속해야 합니다. 최근에 paper가 하나 있었는데 이것은 정보 올림피아드, 이게 좀 유명했던 paper예요. Gemini 2.5 Pro를 가지고 IMO에서 예를 들면 5점을 100점으로 만들었다는 paper로 굉장히 유명했던 건데 이것을 저희 research 팀하고 굉장히 친한 웹 디자이너분이세요. 디자이너인데 이분도 LLM을 잘 사용하시는 분이 있어요. 이분이 한국 정보 올림피아드에 Claude Code 서브 에이전트 시스템으로 똑같이 이것을 reproduce 하셔서 굉장히 유명한 research paper처럼 작성하셔서 저희와 같이 회람했던 적이 있습니다. 이게 공개 링크라서 가져왔고 여기서 말하는 원본 논문, paper는 이런 식으로 얘기해요. 제가 말한 것과 사실 크게 차이가 없거든요. 처음에 solution generation을 하고 그다음 다른 모델이 들어와서 improvement를 시키고, 그러니까 의견을 주면 얘가 안 들었던 종류의 self-improvement를 하는 거죠. 자기 스스로에게 '더 좋은 방법이 없었을까?' 그것을 만들고 그다음에는 여기서 verification을 하는 건데 verification은 굉장히 결정적이어야 해요. 저는 이 결정적인 verification은 사실 테스트 코드라고 생각하거든요. 테스트 코드라고 한다는 것은 굉장히 이게 unit이든 E2E든 플랜별로 있었던 task를 가장 잘 성공했다고 만들 수 있는 'definition of done'을 할 수 있는 테스트 코드를 최대한 많이 만드는 거죠. 최대한 많이 유의미하게 만들고 그다음 이 verification의 도구로서는 계속해서 테스트를 돌리는 거예요. 돌려서 실패하는가 성공하는가, 그리고 네가 self-improvement 했을 때 테스트를 성공하는데 이 테스트를 달성했을 때까지의 시간, 복잡도를 네가 체크해 봐라. 이런 방식을 3번 정도 돌리죠. 보통 이렇게 돌아가는 프레임워크를 구현하다 보면 특정 threshold를 넘어가면 종료시킬 수도 있고 아니면 횟수 자체를 강제할 수도 있는데 예를 들면 내가 token limit이나 이런 것들이 좀 있다면 이 step 1에서 3을 예를 들면 내가 횟수 제한을 이렇게 넣을 수도 있습니다. 아무튼 step 1, 2, 3을 반복하고 특정 버그가 있으면 이 버그를 외부에서 report를 줄 수도 있죠. 지금 이것이 동작하기는 하는데 전체 맥락을 같이 보니까 이것은 안 쓰이는 코드거나 이것은 좀 오동작할 가능성이 있다, 이런 외부의 감사를 두는 것도 결국 다른 모델이어야 하는데 이런 co-action을 반복하고 이것을 반복하는 겁니다. 반복하는 건데, 이게 제가 기본적으로 사용하는 방식의 기본 철학과 굉장히 맞닿아 있거든요. 예를 들면 이런 방법을 내가 서브 에이전트 시스템으로 만들어서 사용할 수 있다는 거죠. 너는 problem solver고, fixer고, improver고, reviewer다. 이런 persona를 주고 특정한 도구를 강제적으로 실행하도록 만드는 behavior case를 유형화시켜 놓고 이 유형화를 step이 1번에서 2번으로 넘어갈 때 반드시 실행되도록 결정적으로 만드는 것, 이런 것들을 예를 들면 Claude Code나 아니면 Codex나 이런 것으로 구현해 놓고 이것을 반복적으로 실행하는 거죠. 이렇게 했을 때 굉장히 성과가 좋더라는 것을 경험적으로 느끼고 있고, 이런 것들을 반복하다 보니까 한 달에 5억 원을 쓸 수 있다는 거죠. 유의미하게 쓰셨던 거군요. 일종의 neuro-symbolic 접근과 비슷하게 느껴지기도 하고 신경망도 쓰고 symbolic한 접근도 같이 해서 두 개를 화해시키는 느낌도 있고요.

-- 그래서 이 얘기를 오늘 굉장히 길게 했는데, 이것을 지난번 Claude Code 행사가 있었을 때 제가 한 20분 정도 얘기하니까 사람들이 눈이 번쩍 뜨이면서 많이 여쭤보시더라고요.

-- 그래서 이런 pipeline들을 소개해 드리고 한번 이것을 잘 접목하면 유의미하지 않을까 이런 얘기를 하고 있습니다. 여기까지가 제가 준비했던 내용이고 아무튼 저는 그렇게 생각해요. 결국 이게 token budget을 굉장히 많이 사용할 수밖에 없는 형태인데 저는 최근에 Claude Code가 성능이 낮아진 것 같다는 얘기를 아마 많이 들어보셨을 것 같고 저도 그때쯤 해서 Claude Code를 원툴로 사용하다가 지금은 코딩 CLI 에이전트를 여러 개를 같이 사용하고 있거든요. 예를 들면 Codex CLI랑 Claude Code랑 Gemini CLI, 세 개를 같이 한 화면에 같이 띄워놓고 활용하는데

-- 그러면 이렇게 할 수 있습니다. Claude Code가 조금 예를 들면 성능도 좀 떨어지는 것 같다고 하면 얘는 그냥 file edit 기능으로만 쓸 수도 있어요. 왜냐하면 현재 시점에서 코딩 에이전트에 이런 결정적인 rule을 주는 가장 강력한 도구가 Claude Code니까 예를 들면 너는 주어진 file edit만 해라. 그리고 Codex나 아니면 Gemini를 가지고 discussion을 하는 거죠. 예를 들면 이런 식으로 사용할 수도 있고 이게 꼼수를 부리는 단순한 일이 아니라 유의미할 수도 있다고 생각하는 게 제가 아까도 말씀드렸듯이 토큰 비용은 비싸지고 있는데 계속 비싸지는 것에 내가 따라갈 수는 없으니까 내가 어떻게든 경제적으로 사용하는 방법도 고민을 안 할 수가 없단 말이죠.

-- 그러면 예를 들면 중국의 좋은 모델들한테는 너는 file edit는 잘할 것 같으니까 너는 file edit를 해라, junior라고 생각하는 거죠. Junior, 너는 file edit를 하고 저 senior들이 discussion한 것들을 갖다 줄 테니까 네가 한번 해보고 네가 만든 것을 가지고 나는 다시 그 내용을 senior들한테 전달하겠다. 저 top-notch 모델한테 내가 전달하겠다. 이런 사용도 가능할 거라고 생각합니다. routing이군요, 일종의.

-- 그러면 그렇게 하다 보면 예를 들면 진짜 5억 원어치를 사용하는 만큼의 성능을 500만 원으로 낼 수도 있는 거죠. 다만 토큰 사용량은 여전히 높을 겁니다. 사담을 얘기하자면 사실 제가 진형 님을 소셜미디어를 통해서 알 때는 예전에 설리번 프로젝트도 하시고 그다음에 군대 사지방에서도 코딩을 열심히 하시고 향상심이 굉장하신 분이라고 느껴지는데 그런 성향이 아무래도 지금의 어떤 극한으로 사용하시는 맥락하고 또 연결이 되는 거 아닌가 인간의 동기가 있어야지 이런 일들이 또 실제로 가능한 모델로부터 이끌어진다는 그런 느낌도 다시 받게 됩니다. 감사합니다.

-- 결국 사람이 시작과 끝을 마무리 짓는 거기 때문에 어쩌면 중간 과정은 많이 부스트할 수 있는데 결국에 어떤 걸 내가 할 거냐 그리고 어떤 것을 내가 끝낼 거냐 이런 것이 사실 굉장히 중요한 고민이 되겠다고 생각을 하고 있습니다. 그리고 고 대표님이 저번에도 언급 주셨는데 지금 근무를 외국에 가서도 하실 때도 있고 탄력적으로 하시는 상황일까요? 네, 맞습니다. 지금 계시는 진형 님도 사실 거의 5대양 6대주를 돌아다니면서 일하시는 타입이고요. 사실 저는 관심사가 두 개일 것 같아요. 일단은 저는 회사를 운영할 때 AI의 퍼포먼스를 극대화할 수 있는 방향으로 회사의 조직을 운영하고 있어요. 무한의 컨텍스트를 모두가 알 수 있게 사실 그게 첫 번째고요. 그리고 또 하나는 저희의 주업인데 사실 Sionic은 회사니까 어떤 회사들의 AX를 지원하는 솔루션을 만드는 팀입니다. 그리고 예전에는 설득할 때 왜 회사가 AX를 해야 되냐고 하면, DX + AX죠, 두 가지밖에 말씀드릴 수 없었거든요. 하나는 경영진께서 회사를 투명하게 들여다볼 수 있다. 그리고 구성원들의 커뮤니케이션 비용을 최적화할 수 있다.

-- 근데 이게 좀 약했어요.

-- 근데 지금은 이런 식으로 DX나 AX가 이루어지게 되면 회사가 10배나 100배의 성과를 낼 수 있습니다. 왜냐하면 이게 준비된 팀은 저희가 언급한 생성형 AI의 수혜를 그대로 받을 수 있는데 레거시 기업은 이게 불가능하다는 거죠. 근데 그게 그런 인프라스트럭처, 조직의 구조, 일하는 방식 자체를 다 바꿔야 시작할 수 있는데 어렵죠.

-- 그래서 저는 지금 저희가 해야 될 일 중 하나가 AI 솔루션 만드는 건 중요한데 회사 자체가 AI로 100배의 성과를 만들 수 있는 회사를 먼저 만들고 그 구조를 좀 더 어떻게 나눠야겠다, 전파해야겠다가 더 커진 것 같습니다. 저희 팟캐스트를 들어주시는 분들 중에 저희가 회사의 미래라든지 노동의 미래 이런 것들에 대한 어떤 그런 주제를 얘기하면 이거는 너무 빠른 얘기 아니냐는 말씀들을 하는데 방금 고 대표님이 말씀하신 것처럼 이 AI라는 도구 자체가 워낙에 강력하기 때문에 이걸 먼저 그 가능성을 보고 그거의 본질은 이 computation의 양을 더 많이 쓰는 거야. 토큰을 더 많이 소비하는 게 일단 최고의 지표야, 이런 것들에 대해서 본능적으로 깨닫고 미래의 회사가 먼저 되는 곳들이 저는 심심찮게 보여요. Sionic도 그중에 하나라고 보여지고요. 그리고 거기에서 어떤 best practice가 나오면 그것들이 어떤 대기업의 단위 조직에 전파될 수도 있고 혹은 저는 기존의 기업들이 transform하는 것보다 이 한 명 한 명의 개인이 회사가 되고 그들이 새로운 경제 주체가 되는 확률이 훨씬 더 높을 거라는 생각은 드는데 그렇게 미래가 다가오고 있는 그런 생각이 듭니다. (VC가) 보통 Request for Startups 같은 것들을 발표하는데 0순위로 되어 있던 게 지금 노 대표님 말씀해 주신 딱 그거였어요. 기존 회사가 바뀌는 게 아니라 새로운 조직이 나와서 AI로 기존의 모든 산업을 부수는 소수의 회사를 지원하겠다, 이게 최근에 YC가 투자하고 싶다고 내놓은 Call for Startups의 1번이었어요.

-- 그래서 정말 앞선 생각이라는 생각이 드는 거죠, 저도. 맞습니다.

-- 근데 이 부분에 사실 저희 팟캐스트 들으시는 분들은 굉장히 고관여자이기 때문에 저희가 컨텍스트를 많이 생략해도 이게 뭘 얘기하는구나 하는 걸 아실 수 있지만 그렇지 않고 그냥 처음 이 맥락을 공유하지 않으시는 분들 같은 경우에는 저희가 오늘 하는 얘기가 '쟤들이 뭐라고 하는 거냐'고 하나도 이해가 안 되실 수 있거든요. 그럼에도 불구하고 그냥 하나의 메시지를 좀 남겨보자면 '이거 해야 된다, 안 하면 큰일 난다'는 이야기를 좀 드리고 싶어요. 저도 하나 더 말씀드리고 싶은 게 있는데, 아니, 질문인데요. 두 분, 기존 기업을 운영하고 계신 두 분 대표님께 공통 질문으로 드리자면 저번에 정석 님이 새로운 인재와의 계약 같은 것들에 대한 고민 같은 거를 말씀해 주신 적이 있었잖아요. 몇 번 전 에피소드에 다르게 해보고 싶은 생각이 있다.

-- 근데 저번에 석현 대표님도 이렇게 인재들에게 상방을 열어주는 방식으로 인센티브를 주고 싶다, 그런 뉘앙스로 말씀하신 기억이 나거든요. 아마 그건 카톡에서 얘기를 했었던 것 같은데, 예를 들면 오늘 재미있게 발표해 주신 진형 님 같은 분들처럼 10x, 100x로 일하실 수 있는 분들을 어떻게 또 이렇게 관계를 맺게 하실지에 대한 그런 생각 같은 게 있으실까요? 일단은 그리고 되게 조심스러운 것도 있어요. 예를 들면 진형 님 같은 경우 회사를 다니면서 별도 법인을 설립해서 운영도 하고 있고요. 네, 그런 것도 하고 있고 심지어 근무의 형태, 근무 시간, 방식, 모든 것들에 다 상방을 열어 뒀습니다. 단순히 보상 이런 게 아니에요. 당신이 할 수 있는 모든 걸 해봐라.

-- 근데 우리는 그걸 지원할 거고 여기에 대한 것들의 상방을 정말 열어놓는 거죠. 저는 이분이 어디서 일하는지도 모르고 언제 일하는지도 몰라요. 심지어 다른 법인에서 수익을 내고 있는 것도 몰라요. 중요하지 않다, 이런 거죠. 기본적으로. 하지만 기여를 하면 상관없다. 사실 고 대표님이 사석에서 진형 님을 빗대어서 AI 시대의 새로운 인재상에 대한 이야기를 굉장히 많이 해주셨어요. 사실 진형 님 같은 근무 형태나 이런 성과에 대한 계약이나 이런 게 전통적인 회사의 관점에서 보면 용납할 수 없는 그러한 근무 형태거든요. 누구는 출퇴근 시간 안 지키는 게 말이 돼? 누구는 '넌 어디서 지금 뭐 하는지도 모르는 게 말이 돼? 회사원인데.' 이러한 형태가 되어 있을 수도 있는데 그것보다도 훨씬 더 성과를 규정짓는 압도적인 어떤 factor가 있다면 그것은 AI의 잠재력을 무한히 끌어낼 수 있는 어떤 오케스트레이션 능력, 리딩 능력, 저는 고 대표님이 지난번에 정의해 주신 거를 저희 노동의 미래 편에서 써먹었는데, 예전에는 태도가 굉장히 중요했다면 지금은 그것은 곱셈의 factor가 아닌 것 같다. AI를 활용하는 능력이 제일 중요하기 때문에 사람의 성과는 '(AI 곱하기 능력) 더하기 태도'가 성과인 것 같다는 이야기를 해주신 것이 저는 굉장히 기억에 남았거든요.

-- 그런데 오늘 얘기를 쭉 듣고 보니까 그게 그냥 하는 얘기는 아니었던 것 같고, 이게 진형 님이 prior, 그러니까 이미 가지고 계신 아까 manifesto 등에서 이 업계가 흘러가는 것에 대해서 공부하고 이해해서 그걸 압축해서 생각을 가지고 논리를 가지고 임했다는 생각이 들어요.

-- 그래서 토큰이 많이 쓰였고 그냥 어그로 끌듯이 5억 원이 탕진되는 것이 아니라 이게 유의미한 실험의 포인트들이 있었고 그런 경험을 쌓아가는 게 지금 2025년 현재 AI 업계의 인재상이 오늘의 모습을 좀 되게 단면을 보여주셨다는 인상을 받았고요. 굉장히 흥미로웠습니다. 그리고 그게 Sionic에서 가능했다, 대표님의 마인드가 또 달랐다는 거죠. 맞아요. 저희 사실 뭐 Sionic에서 협찬받은 건 전혀 없고 진짜 정말 거기서 배울 게 있기 때문에 두 분 모신 거고요. 저 그래도 조금 질문 한두 개만 더 해보고 싶은데, 이미 고 대표님이나 아니면 진형 님이나 이런 분들한테는 이러한 일하는 방식이 어떻게 보면 3년 후의 미래, 1년 후의 미래라고 얘기하는 게 이미 와 있단 말이죠. 이미 진행 중인 거죠, 현재.

-- 그런데 밖에서 사실 조금 심하게 요약하면 98%에 해당하는 다른 분들은 사실 이러한 어떤 방법론이 있다, 이렇게 하면 된다는 부분들을 거의 모르고 계신 경우도 정말 많아요. 그 갭이 굉장히 크게 있다고 느껴지는데, 지금 저희 주니어, 시니어 이런 얘기도 했었고 그다음에 이러한 진형 님이나 고 대표님 같은 경우는 어떻게 보면 지난 10년간의 IT 사이클에서 학습할 수 있는 그런 환경과 이런 것들을 굉장히 잘 부여받으신 분이란 말이죠.

-- 그런데 급작스럽게 이 AI 시대를 맞이해야 되는, 이 경험을 가지고 있지 않은 다른 분들이 이 툴에 대한 능숙도, proficiency를 높이고 이 툴의 본질을 더 잘 이해하고 본인들의 능력을 끌어올리기 위해서 어떤 것들을 해야 된다고 보시나요? 좀 open-ended 질문이긴 한데, 이거 굉장히 중요한 질문이거든요.

-- 그래서 저도 기대하고 있는 대답의 형태가 있는 건 아니고 다른 분들에게 길을 열어준다는 생각을 하시면서 답변을 좀 해주시면 어떨까요? 고 대표님과 진형 님한테 각각 한번 들어보고 싶습니다. 사실 지금 가장 중요한 준비는 AI 사용보다는 최대한 많은 것들이 회사에서는 디지털화가 되어야 합니다. 모든 회의, 모든 논의가 문서화, 디지털화되는 게 너무너무 당연해서 AI를 넣기만 하면 그게 그대로 성과가 나오는 시스템을 만들지 않으면 정말 정말 어려울 거고요. 사실 저는 그걸 처음부터 하려고 회사를 만들었고 그 작업들의 노하우를 계속 다른 회사에 전파하고 있는데, 저희 주업이기도 하고.

-- 그래서 그 작업이 먼저 돼야 할 것 같다. 사실 이게 AI의 문제가 아니에요. 얼마나 커뮤니케이션 비용을 줄이면서 우리가 스케일업하느냐는 거죠. 한 명이 하던 일을 천 명이 해도 손실이 없게 만드는 그런 작업을 먼저 하는 게 훨씬 더 중요하고 거기에는 문서와 도구의 사용, 조직 구조 배포나 그런 마이크로서비스 같은 엔지니어링도 포함되고요. 이게 업에 따라 다를 수 있겠습니다만 결국에는 얼마나 디지털적으로 일을 하느냐로 시작해야 합니다. 나머지는 그렇게 중요하지 않아요. 저 같은 경우는 회사 만들 때 일단 1천 명의 엔지니어가 협업을 할 수 있는 구조로 시작했어요.

-- 그런데 두세 명의 스타트업에서 그리고 그게 실제 저희의 밑바탕이 되고 자산이 되고 있습니다.

-- 그래서 그런 것들을 봤을 때 그게 먼저 선행될 거고 흔히 말하는 DX, 회사 자체의 선진화가 가장 먼저 돼야 할 것입니다.

-- 그런데 사실 저희가 볼 때 이런 큰 물결이 있을 때 기존의 모든 회사가 적응하고 따라오는 경우는 역사적으로 단 한 번도 없어요. 항상 새로운 변화가 있을 때는 한 10%, 5%의 일부만 여기에 순응하고 혹은 따라가면서 갔고, 한 90~95%는 항상 선택압으로 도태되거나 멸종한 거죠. 저는 똑같이 봅니다.

-- 그래서 열심히 준비한 일부만 살아남을 거고 나머지는 다 이전 세대에 남을 것이다 그렇게 보고 있습니다. 네, 무서운 얘기인데 그 이전 세대에 남을 사람들에게 어떤 말씀을 해 주셔야 하는 거잖아요.

-- 그런데 정말 내가 여태까지 배운 것과 한 것을 다 내려놓고 unlearning하고 새로 따라가는 것밖에 없습니다. 정말 모든 것을 시인하고 내려놓고 우리가 새로운 것을 다 받아들여서 해야 한다는 걸 너무너무너무 강하게 느끼고 하셔야 돼요. 그렇지 않으면 모든 회사는 사라질 거고 이건 사실 모두 반복됐습니다. 역사적으로도 반복되고 생태계에서도 반복되고 회사에서도 반복됐고 그렇게 갈 수밖에 없습니다. 혹시 이걸 들으시는 분이 있다면 정말 그것부터 하셔야 합니다. 여태까지의 것은 다 내려놓고 새로운 시대에 순응해야 합니다. 물살을 따라가야 합니다. 매우 단절적인 변화라는 말씀을 해주고 계시네요. 조직에 대한 얘기를 아마 석현 대표님이 많이 하신 것 같고 개인의 입장에서는 저는 못할 것과 내가 하던 것과 이런 것들에 대한 장벽을 좀 없애야 할 필요가 있다. 예를 들면 나는 A라는 직군이니까 B의 일은 못할 것이다, 혹은 내가 하면 안 된다 혹은 커리어상 이것을 하는 것이 나한테 유리하지 않다 이런 생각을 하면 안 된다고 생각하는데

-- 결국은 나는 어떤 현재 시점에서 가장 유의미한 일을 하는 거고 내가 이런 것들을 안 해봤지만 옆에 AI가 있으니까 지금 하는 것이 유의미하다고 지금 내가 판단이 든다면 처음이지만 내가 그냥 바로 해봐서 결과를 볼 수도 있는 거죠.

-- 그러면 이게 기존에 사람들이 가지고 있는 마인드셋과 많이 달라지는 것 같아요. 나는 어떤 팀에서 어떤 일을 하고 있으니까 난 이것만 해야지 예를 들면 저는 이번 주에 저희 회사 사내 프런트엔드에 5개의 커밋을 넣었는데 저는 제가 프런트엔드를 원래 하던 사람은 아닙니다. 내가 제품을 사용하다가 이 제품에 대한 버그가 있으면 이것을 "고쳐주세요"라고 얘기하면 이게 어떤 티켓으로 들어가서 누군가가 이것을 정해진 스프린트에 잡아서 일을 하겠죠. 굳이 그렇게까지 할 필요가 없다는 말이에요. 왜냐하면 내가 지금 사용하고 있다가 좀 불편한 것 같다고 하면 내가 PR을 올린 다음에 "이런 버그가 있고 이렇게 해결하니까 되더라"라고 먼저 제시나 제안을 할 수 있는 거거든요. 개발적인 얘기를 지금 했지만 꼭 개발이 아닐 수도 있습니다. 예를 들면 저희가 최근에 저희 회사에 CPO분께 제가 Claude Code를 좀 가르쳐 드린 적이 있어요. 하루 정도 서버 개발자분이 예를 들면 휴가를 가거나 어떤 상황이 되었을 때 이분이 그냥 작업을 해서 배포를 하기도 합니다. 말씀하신 대로 조직에서 그런 서포트가 된다면 사실 비개발자도 예를 들면 뭔가 작업을 해서 기능이나 이런 것을 넣어볼 수 있는 거죠. 물론 이게 라이브까지 간다는 것은 위험하다고 생각할 수도 있는데 최소한 내가 이것에 대한 개념 검증은 해볼 수 있는 거죠. 직군의 제한이 사라지고 있는 모습을 저는 굉장히 많이 목격하고 있고 조직적인 측면에서 많이 장려해야 하고 개인적인 측면에서도 내가 가지고 있는 심리적 부담감을 많이 내려놓을 필요가 있고, unlearning할 필요가 있다. 저는 그렇게 생각하고 있습니다. 미래가 먼저 와 있다고 느껴지는 회사 Sionic의 그리고 가장 미래를 견인하고 계시는 박진형 엔지니어님 모시고 저희가 어떻게 이 Claude Code나 AI를 이용해서 생산성을 극대화하는지 그것에 대한 이야기를 들어봤습니다. 재미있었습니다. 이거 농담인데, 이게 Sionic Storm하고 관련이 있는 건가요? 저희 제품 이름이 Storm입니다. 사실 저희가 처음에 AI로 하려고 했던 게 AI의 가장 큰 문제인 hallucination을 없애기 위해서 회사를 만들었는데 다들 아시겠지만 High Templar가 Storm을 쓰면 hallucination이 닿자마자 사라집니다. 그런 뉘앙스가 있었던 거군요. 그런 폭풍의 전조 같은 느낌을 받은 세션이었던 것 같습니다. 정말 재미있게 들었습니다. 주말 아침 소중한 시간 내주신 두 분께 감사드립니다.

---


-- 감사합니다.

---------

제공해주신 자료를 바탕으로 생략 없이 완벽하고 최대한 길게 요약해 드립니다.

이 녹화는 2025년 9월 27일 토요일 아침에 진행되었으며 [1], Sionic의 고석현 대표와 임직원인 박진형 님을 두 번째로 모신 대화입니다 [1]. 이전 대화에서는 회사의 성과가 인재의 성과이고 인재의 성과는 토큰 사용량에 비례하는 것 같다는 뉘앙스로 마무리되었으며 [1], 이번에는 Claude Code와 Codex가 등장하면서 Sionic에 이미 미래가 와 있다는 소식을 듣고 화제의 주인공을 모셨습니다 [1].

**AI 토큰 사용량과 성과**

고석현 대표는 임직원의 성과가 토큰 사용량에 비례하고, 토큰을 많이 쓰는 사람이 더 많은 성과를 낸다는 '위험한 발언'을 한 적이 있는데 [1], 박진형 님은 실제로 Sionic에서 이를 증명하며 거의 10명, 100명의 일을 하고 계신다고 소개되었습니다 [1]. 최승준 님은 박진형 님을 문자 그대로 10x 엔지니어인지 물었고, 노정석 님은 **100x 엔지니어**라고 불러야 할 것 같다고 언급했습니다 [2].

박진형 님은 Claude Code가 나온 지 얼마 안 됐을 때 한 달(약 8월쯤) 동안 **약 5억 원어치의 토큰을 사용**했으며 [2], 이로 인해 Claude 토큰 사용량 글로벌 1위를 차지하고 Reddit에서도 크게 화제가 되었던 인물입니다 [2]. 박진형 님은 이 사용 기록을 일종의 훈장 같다고 여겼는데 [2], 이는 AI를 많이 쓰는 사람이 더 많은 지혜를 얻고, 이 지혜는 AI에게 더 좋은 인풋을 넣고 아웃풋을 잘 활용하는 고민에서 나오기 때문이라고 설명했습니다 [3]. 특정 AI 모델의 행동(behavior)이나 선호 형태를 알기 위해서는 마치 양치기를 하듯이 사용해야 한다고 보았으며 [3], 지능적 잠재력을 최대한 끌어내기 위해 토큰을 많이 사용했습니다 [3].

청취자들이 놀랄 수 있는 **'5억 원' 사용의 진실**은, 실제로 한 달에 5억 원을 낸 것이 아니라 [3], 약 200불짜리 계정 3개, 즉 **600불(약 80만 원)**을 사용해 5억 원어치의 토큰을 사용했다는 것입니다 [3]. 이는 '오병이어의 기적' 같은 것이라고 비유했습니다 [3]. 이 일화는 긍정적인 영향을 미쳐, 박진형 님이 LinkedIn에 올리자 어떤 회사의 직원이 이를 근거로 "Sionic에서는 직원이 한 달에 5억 원을 쓰는데 우리는 30만 원도 투자를 못 하냐"며 설득하여 전 직원이 Claude Code를 도입하는 미담도 있었다고 합니다 [4].

Sionic 리서치팀에서는 Claude Code뿐만 아니라 Codex나 Qwen Code 같은 AI 코딩 도구를 많이 사용하고 있으며 [4], 하루 사용량이 500불이 안 되면 "오늘 업무를 안 하셨네요"라고 농담하기도 할 정도입니다 [5].

**AI Manifesto와 Ultrathink 방법론**

박진형 님은 지난 6월쯤(당시 토큰 사용량은 5억 원이 아닌 약 5천만 원어치) [5], Claude Code를 시켜서 새로운 세상의 시작점에서 AI와 함께 업무를 해나가기 위한 **manifesto(선언문)**를 만들어 배포했습니다 [5]. 5천만 원어치의 토큰을 사용한다는 것은 또 다른 영역이며, 그 결과물과 아웃풋을 어떻게 검증할지, 어떤 모델을 사용해야 할지에 대한 고민이 담겨 있습니다 [5, 6].

**박진형 님이 작성한 Manifesto의 주요 내용은 다음과 같습니다 [6-8]:**

1.  **AI가 못할 것은 없다고 생각해야 한다 (불가능은 없다)** [6].
2.  **최대한 좋은 모델을 잘 선별해서 써야 한다 (앙상블)** [6]. (예: 파이썬 코드 컨벤션은 Claude, 고차원적 사고는 GPT-5 High, 문서 작성은 Gemini) [6, 7].
3.  **특정 모델만 주력으로 사용해서는 안 된다** [7]. (모델 자체의 편향성 가능성 때문) [7].
4.  **다른 모델을 호출해 디베이트(토론)를 시켜야 한다** [7]. (예: B 모델이 코드 리뷰를 할 때 만족시킬 수 있도록 A 모델을 설득하는 과정) [7].
5.  **Markdown 파일 형태로 지속적으로 문서화하여 회람시키는 것이 좋다** [7, 8]. (컨텍스트에만 맡기기보다는) [8].
6.  **값싼 모델보다는 비싼 모델을 앙상블해서 쓰는 것이 좋다** [8].

이 manifesto를 GeekNews 등에 올렸을 때 "유지보수는 누가 하냐", "마케팅 용어 아니냐", "**hangover think** 아니냐" 같은 악플이 달렸으나, 박진형 님은 곧 사람들이 그 가치를 알게 될 것이라고 확신했습니다 [8].

**Paper to Code: MuVera 구현 사례**

박진형 님은 단순히 AI를 사용하는 것을 넘어, Google DeepMind 등이 발표하는 논문(implementation이 없거나 일부만 되어 있는 경우)을 실제 결과물로 만들어내는 **'paper to code'** 프로젝트를 진행했습니다 [9]. AI를 활용하면 전체 10단계 중 3, 4, 5단계만 사람이 하고 나머지는 AI에게 위임(delegation)할 수 있습니다 [9, 10].

가장 유명했던 사례 중 하나는 **MuVera**라는 딥러닝 페이퍼(멀티 벡터 임베딩 방법)의 구현입니다 [10]. 박진형 님은 선릉 사우나에서 새벽 1시에 아이디어를 얻어, 4시간 동안 Gemini 2.5 Pro와 Claude Opus 4.1을 함께 사용해 이를 구현했습니다 [10, 11]. Gemini 2.5 Pro와는 논문 리뷰 및 기술 구현 스펙 사양을 Markdown으로 작성하고 [10], 이를 Claude Opus 4.1에게 돌려 구현을 완료했습니다 [10].

고석현 대표는 MuVera 논문과 구현체가 **다음 검색을 바꿀 새로운 세대의 시작**이며, 5년 뒤에는 이 접근 방식 외의 거의 모든 검색이 사라질 정도로 압도적인 일이라고 평가했습니다 [11]. 또한, 이는 벡터 DB 회사를 모두 사라지게 할 수 있는 맥락이 있다고 언급했습니다 [11]. 사우나에서의 급속한 구현은 새로운 신규 서비스를 2~3시간 안에 배포할 수 있게 하며, 즉각적인 피드백을 쌓고 새로운 컨텍스트로 유지하는 데 유리합니다 [12, 13].

이 결과물(MuVera 파일)은 LinkedIn에서 크게 화제가 되어, Jina에서 Perplexity로 이직한 임베딩 헤드나 xAI 관계자 등으로부터 연락과 관심을 받았습니다 [13].

**Ultrathink 엔지니어링 방법론: 계획의 중요성**

박진형 님은 단순히 AI와 '바이브 코딩'(vibe coding)을 하는 단계를 넘어 [14], **난이도가 높은 요구 사항을 AI와 함께 잘 부숴나갈 수 있을지**에 관심이 많습니다 [14]. 휘발적이지 않고 신중하며, 파일 수정 시 안정적이지 못해 파일이 깨지거나 명령 오류로 작업 내용이 사라지는 'vibe 코딩'의 문제를 지적했습니다 [14, 15].

그는 '내가 뭘 하고 싶은지'를 명확하게 하는 것(‘**너 자신을 알라**’에 가까움)이 중요하며 [16], 사전에 **구체적인 스펙 문서나 사양을 작성**할 필요가 있다고 강조합니다 [16]. 애자일 선언문(Agile Manifesto)은 문서보다 작동하는 코드가 중요하다고 하지만 [16], AI 시대에는 코드 작성 행위 자체가 너무 쉽기 때문에 [17], **내가 뭘 하고 싶은지를 스스로 납득하는 것**이 중요해졌습니다 [17].

박진형 님의 작업 방식은 다음과 같습니다:

1.  **3자 OK 확보:** 코딩 AI 도구를 사용하기 전에 GPT-5 Pro 같은 모델들과 함께 Markdown 형태로 스펙에 대한 충분한 논의(discussion)를 하고, **자신과 AI 모델, 옆의 다른 AI 모델(예: Gemini) 모두 동의(3자 OK)**하는 상태에서 작업을 시작합니다 [17].
2.  **Tech Spec 명시:** 스펙 문서에는 background, goal, non-goal 등을 포함시키고, 달성해야 할 구체적인 proposed change를 코드와 함께 명시합니다 [18]. 이 Spec 문서를 Gemini Deepthink 등에게 회람시켜 OK 사인을 받은 후 CLI에 던집니다 [18].
3.  **AI의 자율 계획 (TODO.md):** 코딩 CLI 도구(코드베이스 맥락을 잘 아는 친구)는 주어진 문서를 바탕으로 **스스로 `TODO.md` (계획)를 작성**하도록 지시받습니다 [18, 19].
4.  **계획의 회람 및 승인:** 이 `plan.md`를 다시 Gemini나 GPT-5-pro 등에게 회람시켜 세부 계획을 논의하고, **모든 모델이 accept할 때까지** 다음 작업을 진행하지 않습니다 [19].
5.  **작은 사이클 반복:** `TODO.md`의 각 항목(sub-task)은 코딩 CLI 도구가 완성하고, 테스트를 돌리고, 변경 내용을 브리핑하는 **하나의 작은 사이클**이 됩니다 [19, 20]. 이 반복적인 사이클(iteration) 때문에 남들은 100 토큰을 쓸 때 박진형 님은 5,000 토큰을 사용하게 된다고 설명했습니다 [20].

이 방식은 코딩에 들어가기 전에 많은 토큰을 사용하며 [20], 마치 '신세기 에반게리온'의 **MAGI 시스템**처럼 3개의 컴퓨터가 합의를 이뤄야만 일이 진행되는 것과 유사합니다 [20, 21]. 또한, '외과 수술적인 prompting'(surgical) 맥락과도 공명합니다 [21]. 박진형 님은 실제 코딩은 AI가 하고, 자신은 AI를 관리하고 달래는 **매니저** 역할이라고 느낀다고 했습니다 [22].

**결정론적 관리(Harness)와 Claude Hook**

AI 모델은 '머리가 좋지만 일을 안 한다'고 생각하고 [21], 비결정적인 시스템이기 때문에 '이걸 해주세요'라고 어르고 달래는 것 외에 **무조건 이를 하도록 만드는 규정(rule base)**이 필요합니다 [23].

박진형 님은 최대한 많은 정보를 AI에게 되먹임시킬 수 있는 일종의 **harness**를 잘 까는 것이 유리하다고 강조하며 [24], 이를 위해 **Claude Code hook** 같은 기능을 활용합니다 [25]. Hook은 특정 이벤트에 시스템이 트리거(trigger)하는 것을 의미하며 [26], 주로 `post-tool-use` 기능(파일 쓰기/수정/멀티 수정이 발생했을 때)을 사용하여 특정 셸 스크립트(shell script)를 실행합니다 [26].

예를 들어, 파일을 수정했을 때 **명시적으로 formatter, linter, 2~3개의 앙상블 type checker를 돌리도록 강제**하며 [25], 이 모든 rule-based type checker가 에러가 없다고 말해야만 해당 task를 완전하게 수행한 것으로 보고 다음 단계로 넘어갑니다 [25, 27]. 이는 Python처럼 자유로운 언어에서 Go나 Rust의 친절한 컴파일러 힌트처럼 작동하도록 **명확한 피드백을 빠르게 제공**하여 수습 못 하는 문제를 막기 위함입니다 [24, 28]. 스크립트의 아웃풋은 항상 LLM에게 되먹여져서 다음 작업을 하기 전에 해결해야 할 문제를 명확히 인식하도록 유도합니다 [29].

**다중 에이전트 및 역할 부여 (Role-Playing)**

박진형 님은 엔지니어의 휴리스틱을 언어별, 프레임워크별, 작업별로 분리한 `agent.md` 파일을 관리하여 [30, 31], AI 모델이 이 휴리스틱을 모방하도록 시스템 프롬프트 안에서 강제합니다 [31].

그는 특정 상황에서 어떤 모델과 어떤 **role-playing**을 시키는 것이 유의미한지 동적으로 판단할 필요가 있으며 [32], 이를 위해 DNP, Zen MCP, Serena MCP 같은 표준화된 규격(MCP)을 활용하거나 직접 에이전트로 꾸려서 사용합니다 [32, 33].

예를 들어, 번역 작업 시 **의도적으로 AI의 아웃풋을 비판('억까')**하여 [34], AI가 스스로 자아비판을 하고 개선(self-improvement)하게 만들며 [32], 이 과정을 2~3번 반복하면 옆의 언어 전문가가 보기에 현지인이 썼다고 해도 무방한 수준의 결과물이 나왔다고 합니다 [32]. 코드 리뷰 시에는 의심이 하나도 없을 때까지 **끝까지 비판하는 stance를 강제**하는 것도 필요하다고 강조했습니다 [35]. 이러한 역할 부여는 코드 변경 사이즈(PR diff size)가 100줄 이상 넘어갈 때처럼 **결정적으로 trigger**되도록 만들 수 있습니다 [36].

이러한 **Co-Action 반복 방식**은 정보 올림피아드(IMO) 관련 유명 논문(Gemini 2.5 Pro가 IMO에서 5점을 100점으로 만든 사례)에서 사용된 방식과 철학적으로 맞닿아 있습니다 [37, 38]. 이 프레임워크는 Solution Generation, Improvement, 그리고 **결정적인 Verification (테스트 코드)** 과정을 반복합니다 [37, 39]. 테스트 코드는 태스크의 'definition of done'으로서 중요하며 [39], 테스트를 돌려 실패/성공 여부와 복잡도를 체크하며 3번 정도 반복합니다 [39]. 박진형 님은 이 방법을 Problem Solver, Fixer, Improver, Reviewer 같은 페르소나를 부여한 서브 에이전트 시스템으로 구현하여 반복적으로 실행한다고 밝혔습니다 [38, 40].

**조직 구조와 미래 노동의 변화**

**고석현 대표의 관점 (조직 구조):**

고석현 대표는 Sionic이 이미 **AI 퍼포먼스를 극대화할 수 있는 방향**으로 조직을 운영하고 있으며, 이는 무한의 컨텍스트를 모두가 알 수 있도록 하는 것이 핵심이라고 설명했습니다 [41].

1.  **버스 팩터 (Bus Factor)의 무한대화:** 전통적으로 버스 팩터(한 팀원이 사고를 당했을 때 문맥이 얼마나 남아있는지)는 우려 사항이었지만 [42], AI 에이전트화되면서 AI에 제공된 문맥(테크 스펙 등)은 모두에게 공개될 수 있으므로, 오히려 버스 팩터가 **무한대**가 된다고 주장했습니다 [43].
2.  **콘웨이의 법칙 (Conway's Law)의 투영:** 소프트웨어 구조가 조직 구조를 닮는다는 콘웨이의 법칙에 따라 [42], 미래 소프트웨어는 무한의 에이전트가 있는 조직 구조를 투영할 것이며 [43], Sionic은 이미 개발자 10여 명에 코드 리포지토리가 300~400개 정도로 [44], 한 직원이 10배, 30배의 역할을 하는 것처럼 마이크로서비스 구조가 투영되기 시작했습니다 [44]. 이는 컨텍스트 사일로(silo)가 해체되고 있음을 의미합니다 [44].
3.  **DX/AX의 필수성:** 기업들은 모든 회의와 논의를 **문서화, 디지털화**해야 AI를 넣었을 때 그대로 성과가 나오는 시스템을 만들 수 있습니다 [45]. 이는 AI의 문제가 아니라 커뮤니케이션 비용을 줄이고 스케일업하는 문제이며 [45], 회사 자체가 AI로 100배의 성과를 만들 수 있는 구조를 먼저 만드는 것이 중요합니다 [46].

고 대표는 역사를 볼 때 새로운 변화에 순응하는 소수(5~10%)만이 살아남고 나머지는 도태되거나 멸종했다며 [47], 기존 기업은 모든 것을 내려놓고(unlearning) 새로운 시대에 순응해야 한다고 강하게 역설했습니다 [47, 48].

**박진형 님의 관점 (개인의 변화):**

박진형 님은 개인이 '내가 하던 것'과 '못할 것'에 대한 장벽을 없애고 **심리적 부담감을 내려놓아야 한다**고 강조했습니다 [48, 49]. 직군의 제한이 사라지고 있으므로 [49], AI가 있으니 현재 시점에서 가장 유의미하다고 판단되면 **처음 해보는 일이라도 바로 시도**해야 합니다 [48, 50].

예시로, 원래 프런트엔드 개발자가 아니지만 제품 사용 중 불편한 버그가 있으면 직접 프런트엔드 커밋을 올리거나 [50], 조직의 서포트가 있다면 비개발자(예: CPO)도 서버 개발자가 휴가를 갔을 때 작업을 해서 배포를 해볼 수 있습니다 [49, 50]. 이는 개념 검증(PoC)이라도 해볼 수 있다는 의미이며, 개인적인 측면에서 unlearning이 필요합니다 [49].

**토큰 사용의 경제성 및 인재상**

박진형 님은 Claude Code 성능 저하와 토큰 비용 상승 때문에 [51], 현재는 코딩 CLI 에이전트 세 개(Codex, Claude Code, Gemini CLI)를 함께 사용하며 [51], **경제적인 사용 방법**을 고민해야 한다고 밝혔습니다 [51].

그는 **라우팅(routing)** 방법을 제안하며 [52]: 토큰 비용이 싼 모델(예: 중국 모델)에게는 파일 편집(file edit) 같은 '주니어' 역할을 맡기고, 토큰이 비싼 '시니어' 모델(top-notch 모델)과는 논의(discussion)를 진행하여 [52], 5억 원어치의 성능을 500만 원으로 낼 수도 있다고 예측했습니다 [52]. 다만 토큰 사용량은 여전히 높을 것이라고 보았습니다 [52].

Sionic은 박진형 님과 같은 인재에게 **근무 형태, 시간, 방식, 심지어 다른 법인에서의 수익 활동까지도 상방을 열어두고** 있으며 [53], 이는 성과를 규정짓는 압도적인 요소가 'AI의 잠재력을 무한히 끌어낼 수 있는 오케스트레이션 능력'이 되었기 때문입니다 [54]. 노정석 님은 예전에는 태도가 중요했지만, 이제 성과는 '**(AI × 능력) + 태도**'가 되는 것 같다는 고석현 대표의 정의를 인용했습니다 [54].

결국 사람이 시작과 끝을 마무리 짓는 주체이며 [41], 중간 과정은 AI가 부스트할 수 있지만, '어떤 것을 할 것이고 어떤 것을 끝낼 것인가'에 대한 인간의 동기가 중요하다고 결론지었습니다 [41]. Sionic의 제품 이름은 **Storm**인데, 이는 AI의 가장 큰 문제인 할루시네이션(hallucination)을 하이 템플러의 스톰(폭풍)처럼 사라지게 하려는 의도에서 지어진 이름입니다 [49, 55].