AI Frontier

EP 86

진짜 내 일을 위한 Agentic Workflow

· 노정석, 최승준, 신정규 · 1:26:00
페이지 전체

인트로 및 신정규 대표 소개 00:00

00:00 노정석 녹화를 하고 있는 오늘은 2026년 2월 15일 일요일 아침입니다. 오늘은 오랜만에 저희 채널의 영원한 선생님이죠. Lablup의 신정규 대표님 오셨습니다.

신정규 대표님이 최근에 Backend.AI:GO라는 제품을 론칭을 하셨는데 40일 동안 만들었고, 결과적으로 나온 코드는 약 100만 줄 정도 됩니다. 그리고 저도 제 로컬에 깔아서 쓰고 있는데 너무 깔끔하고, 제가 필요한 그런 기능들 잘 만들어져 있어요.

그래서 오늘 신정규 대표님 모시고 이걸 만들면서, 이전의 바이브 코딩과 만들면서의 바이브 코딩과 그리고 끝난 이후에 Lablup과 신정규 대표님은 어떻게 바뀌었는지, 이 최전선에서 이 산업을 이끄시는 분의 이야기를 한번 들어보도록 하겠습니다. 대표님 어서 오십시오.

00:49 신정규 안녕하십니까? Lablup 신정규입니다. 바쁜 시간에 불러주셔서 감사합니다.

Backend.AI:GO 제품 소개 00:55

00:55 노정석 그러면 Backend.AI:GO 한번 소개 간단히 해주시고, 그거 만든 이야기로 들어가면서 지금의 에이전트 코딩은 도대체 어떻게 해야 하는지 한번 최전선에 계시는 분의 knowledge를 한번 들어보도록 하겠습니다.

01:10 신정규 Backend.AI:GO라는 건 뭐냐면, 몇 분은 아실 텐데 저희가 Backend.AI라는 AI infrastructure 운영 체제, 운영 체계를 10년 넘게 만들어서 제공을 하고 있는데, 이게 사실 여러분들이 사용을 하려면 GPU가 한 100개 정도 단위부터 효과가 커요. GPU 100개에서 천 개, 이렇게 사용하는 플랫폼이라 사실 보통 사람들이 접하기가 어렵습니다.

2024년 하반기부터 재해가 발생했을 때 이런 AI를 어떻게 사용할 수 있을 거냐면, 병원이나 금융기관 같은 데서 AI를 클라우드로 쓰다가 클라우드가 멎으면 큰일 나잖아요. 그럴 경우에 마치 전기 발전기처럼, 병원이나 금융기관 건물 지하에 넣는 발전기처럼 거기다가 GPU 머신을 넣고, 그렇게 밖으로 쓰는 AI가 다운됐을 때 자체적으로 돌아갈 수 있는 걸 만들어 보자고. 그래서 라우터를 만들었어요.

그걸 저희가 Continuum 라우터라고 부르는데, 2025년 3월에 저희가 그걸 공개를 했습니다. GTC라는 NVIDIA 행사가 있는데요. 올해도 갑니다. 여러분 많이 찾아주세요. GTC에서 공개를 했었는데 그때 반응이 좋았었어요. 발표를 했었고, 그런데 그걸 만들다 보니까 덩치가 너무너무 커진 거예요. 저희 같은 경우는 주 고객이 enterprise인데, 이 컴포넌트가 19개 정도가 되고 설치를 하는데 너무 크다 보니까 결국 이걸 다 깔면 여러분도 많이 사용해 보셨을 OpenRouter 같은 서비스를 하나 구축할 수 있는 레벨까지 커져 버렸습니다.

그래서 이게 서비스 스택이지 엔터프라이즈 솔루션 스택은 아닌 것 같다. 그래서 잠깐 다 죽여 놓고 일단 재워놓고, 여기서 만약에 딱 하나만 건진다면 뭘 건질까 해서 여기서 우리 제일 중요한 건 결국 라우터니까 스마트 라우팅하는 부분을 떼서 다른 기능은 일단 놔두고 속도만 전 세계에서 제일 빠르게 만들어 보자. 그래서 처음부터 다시 만들기 시작했던 게 작년 8월에 그 Continuum 전체 프로젝트에서 Continuum 라우터 부분입니다. 그래서 이걸 12월에 다 만들었어요. 1차 1.0을 런칭을 해야 되겠다. 그리고 준비를 했습니다.

이게 기능은 뭐냐면 라우터인데, 이 라우터가 converter 기능을 다 가지고 있고 재해에 대응하는 여러 가지 circuit breaking, 누가 문제가 생기면 넌 문제가 생겼으니까 잠깐 없는 걸로 치자. 그리고 거기에서 없는 걸로 치는 쪽에서 돌아가던 모델들을 다른 모델로 자연스럽게 돌려준다거나 하는 그런 여러 가지 기능들이 있는데, 이걸 공개하려다 보니까 방법이 없는 거예요. 너무 좋은데 설명할 방법이 없네. 그래서 웹 UI를 만들어야겠다, 눈에 보이는 UI가 있어야 되겠다 이렇게 생각을 했어요.

왜냐하면 예전에 저희가 처음 창업을 했을 때도 마찬가지였는데, 벌써 11년 정도 다 돼 가는데요. 그때 저희가 머신 러닝 돌려주는 플랫폼 만들겠다 이러니까 어떻게 만들래 했을 때 일단 터미널부터 켜놓고 설명을 했거든요. 이렇게 명령을 치면, 당시는 TensorFlow도 나오기 전이었으니까 Caffe2 설정도 이렇게 쭉 나오고, 최근에 유행하고 있는 Theano라는 툴도 나와요. 이런 거 했었는데 이런 거 말고 눈에 보이는 거 필요하다. 그때 정석님도 말씀해 주셨잖아요. 그래서 교육 플랫폼을 데모로 만들어 팔기도 했었고. 그게 크리스마스 이브날이었습니다.

Backend.AI:GO 탄생 배경 - 크리스마스 이브의 시작 04:11

04:11 노정석 Backend.AI:GO를 만들자라고 한 게 크리스마스 이브날이었던 거죠.

04:16 신정규 그때는 GO가 아니었죠.

04:17 노정석 사람들이 궁금해하시니까 이 Backend.AI:GO, Continuum 라우터의 제품화, 이게 어떻게 생긴 건지 한번 화면에 올려놓고 보여주면서 설명해 주시면 어떨까요?

Backend.AI:GO 데모 시연 04:28

04:28 신정규 이게 사심이 가득 들어간 프로젝트인데요. 원래부터 이런 모양이 될 건 아니었기 때문에 어쨌든.

04:34 노정석 근데 저는 Ollama나 LM Studio 같은 거를 로컬에 깔아놓고 쓰고 있어서, 걔보다 훨씬 깔끔하고, 필요한 엔지니어 입장에서 필요한 기능들이 잘 들어가 있다는 느낌이 딱 와요.

04:46 신정규 여러분들 어디서 많이 보는 그런 도구고요. 여러분들 중에서 이 인터페이스를 보고 익숙하다고 느끼시는 분들은 저랑 연배가 비슷하신 분들.

04:54 노정석 Windows XP 느낌이네요.

04:56 신정규 그래서 모델, 예를 들면 얘가 라우팅 기능도 하지만 기본적으로는 Hugging Face에서 모델을 검색해서 이렇게 모델을 하나 골라서, 얘가 지금 고품질 추천이네요. 하지만 제 컴은 느리니까 절약 모델을 하나 받겠습니다. 여러분들이 받으면 여기 리스트에 이렇게 나와요. 모델들이 리스트가 나오고, 이 모델들은 너무 놀라운 것 같아.

그런데 내가 좀 모델에 대해서 알고 싶다, 이런 분들은 여기 보시면 이렇게 생긴 아이콘이 있어요. 그럼 이 모델에 대해서 설명을 해 줍니다. Gens3라는 아키텍처를 쓰고, 양자화는 원래 16비트로 훈련이 됐는데 4배 압축이 돼서 4비트를 쓰고 있고, 그 상황에서 품질은 95%를 유지하고 크기는 반으로 줄었다. 그리고 파라미터는 이렇게 feed forward가 60% 정도, 차원은 어휘를 지금 26만 토큰 정도를 사용을 하는 거죠.

그다음에 입력을 하면 embedding하고 transformer를 거쳐서 26개 transformer 블록을 거쳐서 출력을 만든다. 이런 식으로. 레이어는 입력으로 들어오면 출력이 나가고, 그리고 입력이 아래에 있는 이유는 이 어텐션 관련된 초기 논문들 보면 전부 다 입력이 아래에 있거든요. 그래서 논문 읽을 때 아래에서 위로 그렇게 돼 있고,

KV 캐시는 이게 돌아가는 동안 중간 결과를 계속 저장하는 캐시가 있는데, 그 캐시가 어느 정도 메모리를 차지할 건지 이게 모델 종류마다 달라요. 어떤 모델은 엄청 KV 캐시를 크게 요구하는 경우가 있고, 구조에 따라서 이걸 좀 적게 요구하는 경우가 있고. 이런 것들이 이 모델은 어떻게 적용이 되어 있는가 계산을 해서 알려줘.

그다음에 실제 트랜스포머 블록의 구조입니다. multi-query attention이 붙어 있고, 잘 모르셔도 돼요. 여러분 나중에 이걸 가지고 공부를 시작해 보시는 게 목표니까요. 그래서 이렇게 생겼고, 위치는 이런 식으로 인코딩을 해서 긴 글들을 처리한다. 이런 내용들이 쭉 있고요.

그다음에 실행을 하겠다 그러면, 실행 버튼을 누르면 쭉 로딩을 하죠. 그래서 이렇게 돌아갑니다.

06:38 노정석 탑재된 모델은 옆에 채팅 가서 부르면 되는 거죠.

06:42 신정규 네, 그래서 내 컴퓨터에서 도는 거고요. 여러분들 컴퓨터가 좋으면, 예를 들면 NVIDIA GPU나 AMD GPU가 달려 있으면 그거를 여기 엔진 쪽에서 엔진을 추가로 설치를 해서 할 수도 있고요. 얘는 지금 맥이니까 그런 건 따로 없고. 테스트를 해보겠다. 지금 1B짜리 모델이라서 많은 걸 기대하면 안 되고요.

07:01 노정석 쾌적합니다.

클라우드 모델 연결과 분산 라우팅 기능 07:02

07:02 신정규 그다음에 여기 보시면 다른 종류의 모델들도 많이 있는데, 클라우드 모델들을 연결을 할 수도 있어요. 여기 오른쪽 위에 보면 로컬 모델 하나, API 15개 이렇게 있죠. 아까 모델에서 원격 모델에서 원하는 걸 선택을 할 수도 있고, 전체 모델 세트는 여기 175개가 있고 원하는 걸 이렇게 체크를 하면 저 리스트에 나옵니다. 이런 것들은 API 쪽에서 provider를 추가하는 식으로 할 수도 있고요.

여러분들이 OpenAI를 쓰고 있거나 Gemini나 아니면 Anthropic을 쓰고 있거나 로컬에서 Ollama나 LM Studio를 쓰고 있으면 이런 식으로 다 연결을 해서 쓸 수 있게 되어 있고요. 이렇게 연결한 게 어떻게 연결돼 있는지 보실 수가 있어요. 원래 라우터 UI였으니까요. 이렇게 볼 수가 있게 돼 있고, 지연 시간이나 이런 것들을 다 열람할 수 있게 했고.

만약 이게 여러 개 깔려 있어서 다른 사람 컴퓨터에 있다 그러면 그걸 여기다가 추가를 해서, 예를 들면 저희 같은 경우에는 사무실에 만약에 8명이 설치를 했다 그러면 그 8개를 묶어서, 예를 들면 나는 내 컴퓨터에서 이미지 생성이나 아니면 텍스트 모델들 여러 개를 돌리는 건 컴퓨터가 부족하잖아요. 그럼 옆 사람 컴퓨터들에게 다 나눠서 돌리고, 그 결과를 서로 또 다 나눠서 쓸 수 있게 돼 있어요.

누구 컴퓨터에서는 이미지 생성이 돌고, 누구 컴퓨터에서는 텍스트 모델이 돌고, 누구 컴퓨터에서는 PDF 처리 이런 게 돌면 각각 돌리고 있는데 내 컴퓨터에서 다 쓸 수도 있고, 마찬가지로 내가 돌리고 있는 모델도 사무실에 있는 누군가가 돌릴 수 있게 그렇게 돼 있어요.

아니면 좋은 컴퓨터나 워크스테이션을 사서 거기서 돌려서 여기서 연결할 수도 있고. 그런 기능들은 많은데,

08:26 노정석 본인이 필요하다고 느끼셨던 건 다 만들어 놓으셨나요?

08:28 신정규 그렇죠. 번역기 같은 것도 만들어서 넣었고. Lablup에서, Lablup을 “rabble up”으로 번역을 해요. 그래서 이런 것들을 추가를 한다거나, 아니면 이걸 바탕으로 파일을 통째로 번역을 할 수도 있고요. PDF나 TXT나 docs를 놓으면 그 형태 그대로 번역을 해주기도 하고, 그림을 넣어도 되고. 이런 것들이 잡다하게 있습니다.

08:49 노정석 GenSpark가 그냥 로컬로 다 만들어 놓으셨네요.

08:52 신정규 그래서 이거를 지금 테마가 여러 개 있으니까, 이게 아마 디폴트로 깔면 보실 거고 아니면 맥이면 글래스 테마라거나, 아니면 이거는 제가 취미로 만든 거. 이건 최근에 토큰이 남아서 추가된 테마입니다. 이런 이상한 도구고요.

개발 과정 - 40일, 130억 토큰, 100만 줄의 코드 09:06

09:06 신정규 굉장히 사심이 많이 들어간 도구예요. 처음부터 뭔가 회사 프로덕트로 잘해보자 이렇게 만든 게 아니라 라우터 웹 UI를 만들려고 하니까 라우팅을 할 대상이 필요하잖아요.

llama.cpp를 훨씬 좋아하는데, llama.cpp를 돌리다 보니까 수동으로 하기가 너무 귀찮은 거예요. 그래서 llama.cpp를 자동화해서 웹 UI에 넣다 보니까 그게 커지고 커지고, 그러다 보니까 갑자기 DeepL 구독료가 좀 아까워지고. 그러니까 번역기가 생겼고,

그다음에 그림 그릴 일이 되게 많다 보니까 그림 그리는 기능들도 넣게 되고. 그림 그리는 모델들은 되게 좋은 모델들이 많잖아요. 클라우드에도 그런 것들은 계속 늘었습니다. 라우터다 보니까 통계 있고, 벤치마킹, 어떤 모델이 어떻게 빠른지 모르니까 벤치마킹이 있고. 그런 것들이 쭉 붙은 거죠. 2개 비교를 하고 결과를 내보내기 해서.

09:51 최승준 온갖 것이 들어가 있는데요. 이거를 40일 정도에 만드셨다고요.

09:55 노정석 이게 총 만드는 데 소요된 토큰 숫자는 혹시 공개 가능하실까요?

09:59 신정규 제가 이걸 만들 때 Claude Code Max를 2개 기본으로 돌리고, 부족할 때마다 추가 요금 결제하는 방식으로 8개 PC에서 돌렸고요. VM 또는 PC에서 돌렸고, 그래서 아까 24일부터 했다고 했었잖아요.

토탈 130억 토큰 정도를 썼어요. 이 프로젝트가 여기까지 올 때까지.

그리고 12월 24일 날 만들기 시작해서 CES에서 첫 공개를 했거든요.

이게 Backend.AI:GO가 된 이유가, 첫 버전을 만들어서 내부에 공유했는데 너무 좋다는 거예요. 이게 무슨 웹 UI이냐, 이거는 우리 대신 우리를 홍보해 줄 수 있다.

이래서 이름 짓기 해서 Backend.AI:GO가 됐고요.

그래서 일반인 대상으로 첫 제품이 될 수도 있겠다.

그 후로는 멤버들이 다 이슈 트래커에 등록을 하면 개발이 되거든요. 그런 식으로 버그도 리포트하고 새로운 기능도 리포트했고, 그걸 자동으로 개발을 하는 harness를 돌리고 중간에 사람이 계속 들어가서 UX를 수정을 하고 피드백을 주고받고 이런 식으로 해서 열흘 걸렸죠.

2025년 12월 24일 날 만들기 시작해서 1월 6일 날 미국 CES에서 첫 데모를 했습니다.

그다음에 그거는 말 그대로 MVP. 실제로 돌아가긴 하지만 프로덕트고, 그다음에 개발이 그거보다 한 4배 정도 더 진행이 됐죠.

11:14 노정석 그때 CES 가실 때 한 0.9 버전 그때 던져주셨던 것 같은데, 그때 이후로 지금 오늘 보니까 1.1이 됐는데 엄청 완성도가 높아졌네요. 그래서 오늘의 메인 이야기가 사실 지금부터 시작되는데요.

에이전트 코딩의 교훈 - 토큰 경쟁력과 고속 inference 11:30

11:30 노정석 100만 라인을 만드신 그 과정, 그리고 그전에 에이전트 코딩을 접하시던 것과 이걸 만들면서 느끼신 것들, 그것 때문에 지금 바뀐 프로세스, 방법론이 있으시다라는 말씀을 한번 주셨잖아요. 그 이야기를 한번 시작해 보시면 어떨까요?

11:49 신정규 이것도 되게 잠시의 이야기일 거라고 생각을 합니다. 한 가지부터 짚고 넘어갈 텐데, 이 프로덕트를 개발하기 시작했던 거는 얘네들이 holiday 시즌이라고 Anthropic이 토큰 두 배 이벤트를 했던 게 시작이었어요. 그래서 뭘 더 해보지 하다가 하게 된 거고.

그런데 반대로 뒤집으면 토큰을 사용할 수 있는 양이 그 회사의, 특히 IT 회사는 IT 회사의 경쟁력이랑 직결될 수 있는, 그게 첫 번째 얻은 교훈이고요. 첫 번째 교훈은 그거고, 두 번째 교훈은 결국에 이 정도로 토큰을 쏟아내고 사람들이 피드백을 준 걸 개발 자체는 사람이 안 하는 프로덕트를 하게 되면 bottleneck이 몇 개가 생긴다는 거.

그게 예를 들면 한 6개월 전에는 merge queue가 bottleneck이었거든요. 개발하는 속도가 빠르니까 자기들이 만든 것끼리 충돌을 해요. 그런데 이 시점에 와서는 merge queue는 병목이 아닙니다. merge queue를 해결하는 것도 사람이 하지 않으니까 알아서들 하고, 심지어 제가 실수로 테스트해 본 것 중에서는 AI 두 개가 같은 소스에서 경합을 하면서 서로 다른 기능을 개발을 해도 최종적으로는 그 기능이 멀쩡하게 개발이 돼요. 그 정도로 많이 발전을 했습니다.

그렇기 때문에 그다음 단계로 가게 되면 어떻게 하면 토큰을 덜 쓸까가 핵심이 됩니다. 똑같은 일을 할 때 예를 들면 성능이 좋아지기 위해서 모델들이 선택한 방법이 보통은 in-context learning에 사용되는 눈에 안 보이는 thinking token, thinking budget이라고 하죠. 그 양을 늘리는 쪽으로 많이 진화를 하고 있는데 이 양이 늘어난다는 게 당연히 최종 결과물이 좋지만 동시에 개발 속도가 느려진다는 거랑도 같은 얘기거든요.

그래서 어떻게 thinking을 덜 하고서 개발을 하게 만들 것인가, 그리고 thinking을 덜 한다는 것 자체는 개발 속도가 빨라진다는 얘기고 결국에 모두가 AI로 코딩을 하게 되는 세상에서는 속도가 되게 중요하게 되는데 속도를 빠르게 할 수 있는 방법이 두 개가 있는 거죠.

하나는 얘가 토큰 자체를 덜 생성하고 같은 결과를 내게 만드는 게 첫 번째 도전 과제가 될 거고 두 번째는 정말로 토큰 생성을 되게 빨리 하는 게 두 번째 방법이 될 겁니다. 요새 high-speed inference가 필요하게 되는 거죠. 우리가 익숙한 이 ChatGPT의 code generation 하는 그 속도가 아니라 5배에서 10배 정도의 iteration을 돌 수 있는 엄청나게 초고속 inference가 되게 중요해지게 되겠다.

이 두 가지가 크게 얻은 교훈이에요. 이걸 하게 되면서.

14:00 최승준 며칠 전에 Codex Spark 나온 거, 그런 거 같은 거죠.

14:02 신정규 그다음에 또 신기하게 Spark 서비스를 시작을 해서 바라보고 있는 게 똑같구나.

결국 이 승부는 고속 inference 시장으로 가는 수요가 생기고, 충분한 돈이 있는 사람들은 고속 inference로 경쟁력을 올릴 거고, 그렇지 않은 곳은 어떻게든 생각을 덜하게 만드느냐.

성능이 필요한 곳만 thinking을 많이 하게 하고 성능이 필요 없고 단순 작업이나 코딩을 해야 되는 곳은 thinking을 덜하게 만드는 식의 adaptive thinking budget을 어떻게 적용을 하느냐, 또는 그런 thinking budget을 동적으로 조종할 수 있는 harness를 어떻게 만드느냐. 이쪽으로 아마 올해 겨울은 지나가지 않을까.

14:36 노정석 다 trade-off니까요.

바이오 토큰 - AI 시대 인간의 인지 부하와 도파민 14:38

14:38 노정석 그걸 고민하게 되더라고요. 다 AI가 해주니까 기다리는 시간이 슬슬 짜증이 나기 시작합니다.

14:45 신정규 실제로 그 기다리는 시간의 문제가 크고 그런데 기다리는 시간 덕에 개인적으로는 좀 생각을 할 수 있는 계기가 됐어요. AI에 대해서가 아니라요. 저에 대해서 생각을 좀 하게 됐는데

14:59 노정석 요새 그걸 바이오 토큰이라고 말씀하시더라고요. 바이오 토큰에 쓸 수 있는 시간이 늘어서 좋다라고 저희 어떤 분이 말씀하셨습니다.

15:07 신정규 개인적으로 봤을 땐 이런 거죠. 제가 재작년쯤에 ChatGPT랑 코딩을 어느 정도 위탁을 하면서 같이 코딩을 시작을 했고 작년 4월부터 크게 엄청나게 바뀌어 가지고 한 9개월 정도 이렇게 살았는데 흰머리가 늘었습니다. 흰머리가 엄청나게 늘었고 그리고 잠을 잘 안 자게 됐어요. 그게 한창일 때는 6월 7월 이때만 해도 5시간 리필 생기고 나서 5시간이 아까워 가지고 3시간 반 돌리고 1시간 반 자고 이런 식으로 살았었다가

그런 것도 조금씩 자동화가 되게 되는데 코드 자체는 70만 라인 정도 되고 토털 작성한 라인은 120만 정도 라인이 돼요. 근데 이게 제게 120만이라는 숫자가 개인적으로는 되게 상징적인데 예전에 TextCube 프로젝트 할 때 제가 3년 동안 짰던 코드가 다 합치면 100만 줄 정도거든요. 근데 그 정도 양의 코드를 40일에 짠 거죠.

어떻게 보면 인생이 확 압축이 돼 가지고 한 달 동안 딱 Backend.AI:GO를 짠 건데 그걸 짜면서 내가 정말로 40일만큼만 노력을 했나. 돌아보면 3년 치 늙은 것 같아요. 사람으로서는.

인지 부하가 줄지 않습니다. 아무리 AI에게 뭔가를 맡긴다고 해도 인지 부하가 줄지 않고 오히려 끊임없이 피드백이 들어오기 때문에 사람이 되게 삶이 피폐해집니다.

근데 할 때 재밌죠. 왜냐하면 게임같이 뭔가 했을 때 도파민이 주입이 되는데, 이게 요새 유행하는 모바일 게임 가챠랑 비슷해 가지고요. 돈 내고 캐릭터 뽑고 뭔가 해 가지고 이기면 즉각적인 피드백이 오잖아요. 사람들이 좋아한단 말이죠.

에이전트를 사용해서 코딩을 하는 과정은 인간에게 그 속도를 기반으로 한 어떤 즐거움을 제공을 해줍니다. 왜냐하면 예전에는 나한테 큰 일이었는데 아니면 내가 도달하지 못할 것 같은 곳이었는데 그걸 달성할 수 있게 해주니까. 내가 달성하느냐 얘가 달성하느냐의 차이는 있지만 어쨌든 그렇게 어떤 도파민을 공급을 해주고.

근데 도파민을 공급해 준다는 표현이 맞지는 않거든요. 근데 공급을 당하면서 그 문제는 너무 계속 요구를 받는다. 이게 잘 되니까 더 하게 되고, 더 하면 또 잘 되고 그러다 보니까 사람이 거기에서 헤어나오지 못하게 그렇게 되게 되면 뭔가 잘 되죠.

잘 되는데 두 가지 문제가 생기는데 하나는 삶이 아까 말씀드린 것처럼 너무나 의존적이 돼서 피폐해진다는 거. 두 번째는 어느 순간 그게 끊어지게 되면 그 프로덕트도, 만들고 있던 프로덕트도 죽고 사람도 떠나고 다음 프로덕트를 통해 다음 프로덕트를 찾아 나갈 수도 있지만요. 그렇게 돼서 버려지는 프로덕트들이 엄청 많이 생길 거라는 예상을 하게 됐어요.

소프트웨어 과잉 시대와 인스턴트 앱의 등장 17:42

17:42 신정규 이게 좀 다른 건데 예전에는 소프트웨어 산업에 아니면 소프트웨어를 개발하는 데 진입 장벽이라는 게 있기 때문에 어떤 소프트웨어를 만들게 되면 그 소프트웨어가 어떻게든 사용자만 잘 찾으면 지속적으로 유지가 됩니다.

그런데 되게 빨리 만들어진 소프트웨어는 그 유지 의지가 상대적으로 약할 수밖에 없어요. 왜냐하면 그만큼 고생을 하지 않았으면 어떻게 관리를 할 수 있느냐의 영역도 사실 AI한테 다 맡겨 왔기 때문에 AI한테 시키면 되지가 되는 것이고 동시에 또 비슷한 일을 하는 프로덕트들이 세상에 많아지게 돼서 많아질 거거든요.

예를 들면 특정 기능을 하는 어떤 오픈소스 프로젝트가 하나가 있다. 그러면 사용자들이 거기로 모여서 그게 덩어리가 되게 커지게 되는데 그런 현상이 훨씬 덜 생기게 되겠죠. 간단한 프로젝트는 내가 직접 만들면 되고요. 조금 복잡한 프로덕트면 이미 세상에 수십 개가 나와 있잖아요.

한 프로덕트를 유지하기 위한 인간에게 주어져야 되는 도파민의 양이 절대량이 줄어들게 될 겁니다. 그게 옛날에 블로그에서도 비슷하게 있었는데 블로그에서 댓글 영역이 전부 다 Twitter로 디스커션을 이동하게 되면서 블로그를 열심히 쓰시던 분들이 블로그를 많이 접었어요. 왜냐하면 그분들의 주 동력 중의 하나는 아래 댓글창에서 오가는 소셜 피드백이었던 거죠. 근데 그게 다른 플랫폼으로 가고 나니까 쭉 사라진 것처럼 엄청나게 관리 안 되는 오픈소스 프로덕트들이 늘어날 거다.

그래서 우리는 소프트웨어가 엄청나게 풍부한 세상에 살게 되겠지만 그 대부분의 소프트웨어들은 수명이 길지 않은 상황이 될 것 같다. 그중에 굉장히 소수만 살아남을 텐데, 나머지는 쓰이고 버려지거나 두 가지가 남겠죠.

하나는 애초에 소프트웨어를 쓰고 버리는 개념으로 만드는 인스턴트 앱이라는 개념에 들어와서 필요할 때 만들고 자주 쓰는 것 같으면 그냥 저장을 해놓고 저장할지 말지 결정하는 것도 예를 들면 Google님이 해주시겠죠. Google에서 만들어서 그런 식으로 재사용성이 좀 낮은, 하지만 굉장히 빨리 만들고 빨리 쓰는 인스턴트 앱들이 쭉 등장을 하게 될 거고 나머지들은 결국에는 다시 소프트웨어가 쭉 늘어나다가 다시 줄어들게 될 거라고 생각을 해요.

인간이 사는 데 필요한 소프트웨어 종류가 그렇게 많지가 않잖아요. 제가 스마트폰을 쓰면서 느낀 건데 스마트폰 초창기에는 앱을 여러분 믿어지지 않겠지만 스마트폰 초창기에는 폴더 기능이 없었습니다. 앱 폴더. 그래 가지고 모든 앱들이 iPhone 같은 경우에는 모든 앱들이 바탕 화면에 다 나와 있었어요. 그래 가지고 막 9페이지씩 막 넘기고 이랬거든요.

그러다가 자동으로 organize도 해주고, 앱 폴더 기능도 생기다가 어느 순간 사람들이 발견을 한 거죠. 한 사람이 사용하는 앱은 30개를 넘지 않아요. 그리고 사용 빈도로 따지면 상위 10위의 앱이 전체 사용량의 90% 이상을 차지합니다. 그렇게 정리가 한번 되죠.

그렇게 정리가 되는 앱들의 공통점이 있는데 하나는 sociality에 기반을 했다. 이 앱이 자체적인 사용성을 제공을 하는 게 아니라 이 앱을 통해서만 만들어지는 사용성을 제공을 한다는 게 두 번째로는 굉장히 life, 내 생활에 밀접하게 관련된 앱들. 예를 들면 오피스 앱들이라거나 아니면 생산성, productivity 앱이라고 부르죠. 내 문서를 정리를 해준다거나, Obsidian 같은 것들도 있고 DEVONthink 같은 것들도 있고, 그런 도구들이 있는 거고.

그런데 그런 도구들의 공통점은 오랫동안 그 자리에 있었던 앱입니다. 아까 말씀드린 것처럼 어떤 프로덕트, 제품이라고 할게요. 소프트웨어를 누군가가 잡고 계속 유지 발전을 시켜준다라는 보장이 있는 것들만 결국 살아남았어요.

오픈소스도 마찬가지죠. 많이 쓰는 오픈소스가 많이 쓰이는 이유는 이게 빨리 망하지 않겠다는 확신을 주기 때문이거든요.

21:08 노정석 브랜드가 잡힌 거죠. 어떠한 약속이 시장에 퍼진 거죠.

21:13 신정규 이게 소프트웨어 개수가 확 늘어났다가 늘어나는 건 여전하겠지만 많이 사용되는 소프트웨어들의 수는 어느 정도 선에서 유지가 될 거라는 생각을 하게 됐고요.

올해 하반기 정도면 거기에 SaaS가 무너진다 만다 해도 결국에는 그 SaaS를 다 만들 수 있겠죠. Lablup의 레베뉴 오피서님이 직접 Salesforce 별로다, 직접 만드셨어요. 이틀이니까 멀쩡하게 다 만드시더라고요.

그럼에도 불구하고 결국 지금 다른 솔루션을 더 저렴한 다른 솔루션을 사서 쓰는데 사서 쓰는 이유는 그겁니다. 어차피 다른 일도 그 속도로 할 수 있으면 내가 안 해도 되는 일은 내가 안 하는 게 맞아요.

그렇기 때문에 SaaS 시장이 망하지는 않을 것 같지만 지금 SaaS 시장에서 성공하고 있는 애들이 1년 후에 성공하고 있을지는 잘 모르겠어요.

22:00 노정석 패러다임이 막 바뀌고 있어서 어떻게 될지 모르겠어요. SaaS 회사들 주가 빠지는 걸 보면 참 신기하긴 한데 그들 중 몇은 또 살아남아서 AI와 결합해서 굉장히 굳건한 모델로 다시 거듭날 수도 있는 거잖아요.

브랜드가 있으니까 그 일은 그 애가 제일 잘했어. AI 시대에도 우리가 더 잘해. 이렇게 될 수도 있을 것 같고 지금 정규님이 말씀하셨던 그 소위 어떤 대변혁기잖아요. 모바일 때도 대변혁기 때 수많은 경쟁이 있었고 AI 때도 우리가 이미 안정적으로 느끼고 있는 환경이 바뀌고 있어서 그 안에 또 나의 기회가 있을까 싶어서 모두가 다 달려들고 있는 그런 시기가 아닌가라는 생각도 들어요.

소프트웨어 역사로 본 세 번째 대변혁 22:38

22:38 신정규 소프트웨어가 한번 확 바뀌는 시기인 건 확실하고요. 그러다 보니까 소프트웨어를 해야 돼 이런 얘기들도 많이 겪게 되고 저희도 회사 안에서 굉장히 많은 세미나도 하고 서로 디스커션도 하고 앞으로 우리는 무슨 길을 가야 될까 이런 생각들도 하는데요. 시작하기 전에 간단하게 말씀을 드렸지만, 이런 변화가 예전에 몇 번 있긴 했거든요.

저희가 직접 겪지 않은 세대의 변화라고 하면 천공 카드로 펀칭하고 OMR 카드에 마킹을 하다가 갑자기 키보드로 코딩을 하게 된 방법론적으로 크게 변했죠. 그다음에 소소한 변화라면 에디터에서 방향키로 커서를 이동하면서 코딩을 할 수 있게 되는 상황, 지금은 이해가 안 되시겠지만 이게 안 됐습니다. 여러 개의 소스 코드를 합쳐 가지고 프로그램을 만든다거나

그다음으로 큰 변화라고 하면 스마트폰이 들어오게 되면서 우리가 스택을 만들 때 기존에는 단독으로 패키징 되는 어떤 패키지 소프트웨어라는 걸 핵심에 두고 이걸 어떻게 deliver할 거냐, 예를 들면 매체로 따지면 CD냐 디스크냐 아니면 우리가 ESD라고 불렀죠. 그런 식으로 해서 전자 전송을 할 거냐 이런 얘기들도 있었고 하는 방식도 프리웨어가 있었고 셰어웨어라고 써 보고서 돈 내세요도 있었고 그다음에 커머셜 소프트웨어들이 있었죠. 마트 가면 돈 주고 사는.

그런 배포 개념에서 스마트폰이랑 웹이 10년 정도의 시차를 두고 동시에 사회로 들어오게 되면서 네트워크를 통해서 delivery를 하고 심지어 delivery 자체를 안 해도 되는 웹 브라우저를 통해서 원격에서, 원격에 설치된 소프트웨어라고 할게요. 우리가 보통 요새는 웹 서비스라고 부르는데 원격에서 운영되는 어떤 서비스 형태의 소프트웨어들을 사용을 하고 그러면서 개발에 관련된 게 굉장히 많이 바뀌었어요. 웹 서버가 중요해지게 되고 결제 시스템이나 이런 것들이 보안 관련된 것들이 한 번 확 바뀐 적도 있었는데, 그리고 UX 차원에서는 키보드랑 화면 중심이었다가 갑자기 굉장히 작은 디바이스 또는 화면 크기가 왔다 갔다 하는 디바이스, 입력도 물리 키보드에서 터치 키보드로 바뀐다거나 이런 큰 변화들이 있었고, 지금이 아마 그런 변화로 따지면 한 세 번째 정도인 것 같습니다.

여기서 바뀌는 건, 아까 소프트웨어 자체도 계속 바뀌었잖아요. 그런데 지금 바뀌는 소프트웨어는 우리가 보통 소프트웨어라고 하면 코드를 만들고 그 코드를 소프트웨어라고 부르고 그걸 운영하는 걸 대부분 developer들이 만들죠. Developer들이 만들다가 웹 기반으로 가게 되면서 그걸 operation 해야 하는 ops라는 직종이 생기고요. 그리고 그 두 가지가 웹 서비스에서는 굉장히 긴밀하게 융합이 되기 때문에 DevOps라는 분야가 생겼습니다. 개발도 하고 운영도 하고 그다음에 그 과정에서 스택도 예전에는 모든 사람들이 모든 코딩을 하다가 서비스, 웹 서비스 형태가 되게 되면서 백엔드라고 부르는 로직이랑 서버 쪽을 담당하는 사람들이 생기고 그다음에 사람들이 실제로 사용하는 인터페이스를 하거나 사용자 경험 또는 실제 동작에 대한 설계를 하게 되는 프론트엔드라는 직종이 따로 생기고요. 그다음에 그런 것들을 통괄해 가지고 기획을 하는, 아니면 그걸 내가 다 할 수 있다, 이런 풀스택이라는 것도 생기고 다양하게 생겼죠.

그래서 핵심은 이거예요. 기존에는 코드를 작성한다는 게 한 70~80%고, 그걸 운영하는 서비스 스택을 구현하는 게 20~30%. 이렇게 두 개로 크게 나누어 가지고 우리가 스마트폰 앱이나 아니면 웹 서비스를 개발하게 되는데, 적어도 저희 애들은 앞으로 그 개념 자체를 배우지 않으면 모르게 될 거라는 생각을 합니다.

코드의 가치는 0으로 수렴하는가 25:57

25:57 신정규 왜냐하면 지금 이 프로젝트 Backend.AI:GO를 만들고 금요일 날 어느 간담회 가서 얘기를 했었는데, 그 간담회를 하는 동안 간담회를 10시부터 12시까지 했는데요. 10시에 들어가기 전에 커피숍에서 쭉 리뷰를 하고 던지고, 간담회 끝나고 봤더니 PR이 한 22개, 21개 정도 날아가고 테스트 끝나고 merge까지 됐더라고요.

그런 정도의 페이스가 된다면 사실 코드는 가치가 거의 0으로 수렴하게 되고, 아까 말씀드린 DevOps에서 developer가 하는 일이 종류가 완전히 바뀌지 않으면 이분들은 직업을 잃거나 아니면 좀 어려운 상황에 처하게 되겠죠. 근데 사실 굉장히 중요해질 분들이기도 해요. 소프트웨어 자체는 어디로 사라지지 않거든요.

제가 보기에 지금의 소프트웨어가 위험하다라고 얘기를 하는 거는 실제로 소프트웨어가 위험한 게 아니에요. 소프트웨어의 정의가 OMR 카드에 마킹하던 거에서 키보드 기반의 코딩으로 넘어왔듯이, 키보드로 코딩하던 거에서 의미를 전달하는 걸로 코딩이 계속 변하고 있는 단계가 될 거고, 그렇게 되면 저는 제품의 핵심 가치 자체는 엔진에서 나온, 그 엔진이라는 건 우리가 지금 코드라고 부르는 게 처리해 주는 부분, 사실 로직이잖아요. 코드 자체는 목적이 아니죠.

우리가 어떤 서비스를 만들기 위해서 그 서비스를 컴퓨터로 처리하기 위한 로직을 구현해 놓은 것을 우리가 코드라고 부르는데, 장점은 결정론적이죠. 폰 노이만 아키텍처로부터 비롯된 순차적으로 로직을 처리하고 그 결과를 사용자에게 deliver하는 과정도 전부 다 정형화가 되어 있기 때문에, 물론 그 사이에 medium들은 굉장히 불안정하지만, 네트워크라거나 스토리지라거나 불안정하지만,

어쨌든 그 위에서 돌아가는 논리 구조 체계 자체는 원래는 고정이 되어 있었거든요. 현재까지는.

그런데 그 코드의 목적이 어떤 로직을 처리해서 일을 되게 만든다라는 관점에서 보면 그 부분은 대부분 앞으로 딥러닝 모델들, 아니면 파생 모델들, 뭔지 모르죠. 꼭 Transformer가 아닐 수 있잖아요. 다른 종류의 로직을 처리하는 엔진 부분이 지금 코드가 담당하는 부분의 대부분을 담당하게 될 거라고 보는 게 제 생각이 들게 됐고.

27:58 노정석 이미 세상이 거기에 대한 판단은 했잖아요. 사실 모델을 만드는 회사가 지금 현재 거의 대부분의 가치를 다 캡처하고 있잖아요. 하드웨어 만드는 회사와 모델 만드는 회사, 그리고 그 위에 있었던 레이어들이 지금 다 밀려나고 있는 그런 거지 않습니까?

28:15 신정규 말씀하신 것처럼 가치가 그쪽으로 이동하는 것도 되게 자연스럽고, 그래서 아마 소프트웨어라고 부르는 거는 안에 AI 코어 엔진을 하나 가지고 있고, 그 겉에 그걸 제어해서 기존처럼 결정론적으로 만들어주는 레이어가 하나 붙는 거, 이게 중요한 가치를 갖게 될 거고.

제가 경험을 여러 가지를 했는데, 지금은 Claude Code도 하게 되고, Codex도 당연히 해보게 되고, Copilot을 굳이 얘기해야 되나 싶지만 Copilot도 하게 되고, Gemini CLI도 쓰는데요.

예를 들면 Gemini CLI라거나 아니면 Codex 같은 거를, Backend.AI:GO를 쓰면 그걸 붙여가지고 Claude Code에서 사용을 할 수가 있어요. backend 모델만 바꿔가지고.

Claude Code의 진짜 경쟁력은 harness다 28:54

28:54 신정규 근데 그렇게 돌려보고 알게 된 거는 Claude Code의 핵심 경쟁력은 Opus나 Sonnet 엔진이 아닙니다. Claude Code 그 자체예요. 기존의 소프트웨어라고 부르는 영역이 있고, 그 소프트웨어가 아까 말씀드린 그 모델 겉에서 이걸 감싸면서 결정론적으로 동작을 만들어 주는 이 소프트웨어 로직, 이게 굉장히 강력하다는 생각을 하게 되더라고요. 똑같은 모델인데 Claude Code에 붙이면 굉장히 잘 돌아가고.

29:18 노정석 Claude Code harness의 endpoint를 어디에 했을 때 제일 느낌이 좋으셨어요? 예를 들면 Claude Code harness에다가 Codex 5.2, 이런 거 붙였을 때가 좋다, 이런 케이스가 있어요?

29:31 신정규 Gemini 3 Pro요.

29:32 노정석 오늘 당장 해봐야 되겠네요.

29:33 신정규 놀랍지만 Gemini도 Claude Code를 붙이면 잘 돌아갑니다. 그리고 context가 크죠. 이런 모델 80%, 겉에서 그걸 결정론적으로 만들어주는 로직 코드죠. 이게 기존의 코드죠. 그게 한 10%, 사람하고 interaction하게 만들어주는 UI/UX를 제공을 하거나 아니면 AI끼리 UI/UX, A2A라거나 MCP가 있지만 다 한때라고 생각이 들고, 이런 것들을 담당하는 게 한 10%에서, 이게 아마 소프트웨어의 정의가 될 거예요.

앞으로 소프트웨어, 저희 다음 세대까지 갈지 모르겠는데 그때 가면 소프트웨어를 배운다는 거는 사실은 모델이 무엇이고 모델이 어떤 식으로 돌아갔고, 물론 역사 책에 나오겠죠.

우리도 천공 카드로 만든다는 거를 느낌으론 모르지만 지식으로는 알고 있잖아요. 옛날에는 소프트웨어를 그렇게 만들었구나, 천공 카드 전에는 진공관으로 해가지고 벌레를 잡으러 들어가서 버그였구나, 이런 거를 지식으로는 알고 있잖아요. 그런 것처럼 옛날에는 소프트웨어를 사람이 손으로 만들었구나, 와 그걸 어떻게 다 손으로 만들지, 코딩하고 있는 사람 옆에서 모니터 옆에 키보드 놓여놓고 브이 하고 있는 사람을 역사 책에서 보는 것처럼 그런 느낌으로 소프트웨어를 대하게 되고, 아마도 다음 세대의 핵심은 그런 로직을 직접 담당하는 모델이 무엇이고 모델을 어떻게 만드는 것이고 그 모델의 역사부터 쭉 배우겠죠.

그런 게 아마 컴퓨터 공학의 한 부분을 차지하게 되지 않을까 하는 생각이 듭니다.

컴퓨터 공학의 미래 - 역사의 뒤안길인가, 재정의인가 30:53

30:53 노정석 저희가 전통적으로 컴퓨터 사이언스에서 배우던 데이터 구조라든지 알고리즘이라든지 OS, 네트워크 이런 부분들 많이 역사의 뒤안길로 좀 가겠네요.

31:05 신정규 전 그게 굉장히 빠르다고 보고 있고요. 생각보다 훨씬 빠를 거고, 그렇기 때문에 이게 저희가 이번 변화에서 모두가 지금 체감을 하고 있는 건 얘는 지금 어떤 특정한 속도의 구간에 있는 게 아니라 가속 구간에 위치를 하고 있기 때문에 가속도의 속도도 증가하는 양상을 볼 수 있다는 거.

31:24 노정석 가속도의 숫자 역시 증가한다는 거죠.

31:27 신정규 그렇죠, 가속도도 일정하지 않습니다. 가속도의 속도가 고정된 것들도 있죠. 예를 들면 우리가 모델을 만들 때 사용하는 연산량의 수는 해마다 10배씩 증가를 했고요. 걔는 그렇게 계속 증가는 못하죠. 물리적인 지구가 제공하는 물리적인 한계, 지구 위에서 인간이 달성할 수 있는 한계에 다다라 가고 있고.

그렇지만 다른 쪽에서는 계속 가속이 되고 있죠. 예를 들면 training에 사용되는 게 그 가속 곡선을 지킬 수 없다고 하면 inference에 더 리소스를 많이 쓴다거나, 그다음에 단일 inference가 in-context learning에 들어가는 토큰 수를 늘려서 달성을 할 수 없게 되니까 agent swarm을 늘리게 된다거나. agentic AI라고 해서 에이전트들을 묶어서 쓰잖아요.

그런 식으로 확장이 필요한 가속 구간의 영역은 계속 바뀌어요. inference가 가속 구간을 담당을 하게 됐고, 그다음에 agentic AI라고 해서 개수가 하나에서 10개, 10개에서 20개 이렇게 parallel하게 늘어나는 쪽으로 지금 가속 구간이 이동을 했잖아요. 그런 식으로 계속 이동을 하면서 곡선을 유지를 하고 있는 단계이기 때문에, 이런 변화가 저희는 실감이 안 나지만 예전에는 한 번 있었다고 알고 있습니다.

그때가 아폴로 계획 때였고, 그때 결국엔 끝을 달성을 했죠. 달에 갔고, 그다음에는 모두가 아는 스토리처럼 인공위성이 지구를 뒤덮게 됐습니다. 이제는 더 이상 상상을 할 수가 없잖아요. 그 전 단계를, 우리가 뭐 당연한 거 아니야, 미국에 있는 사람들과 이야기하는 것도 되게 당연하고. 어쨌든 그 전에 상상할 수 없는 사람들이 있고, 지금 딱 그런 곡선에 있다고 봐야겠죠.

Gemini 계획이 섰다 정도로 보는 게 맞지 않나. 우주 개발하고 비교를 하면 아직 아폴로까지 못 갔고, 사람을 띄워서 올리는 것까지 성공을 한 딱 그 단계.

33:05 노정석 저희가 다시 이 agentic 코딩 이야기로 돌아가기 전에 정규님한테 마지막으로 큰 질문을 좀 드리고 넘어가고 싶은데, 사실 요새 모두가 다 좀 너무 힘들거든요.

이 가속도가 계속 증가하고 있는 거를 모두가 느끼고 있으니까 열심히는 하는데, 내가 열심히 하는 게 과연 의미가 있나.

왜냐하면 다른 사람도 나랑 똑같은 걸 만드는데, 무언가 좀 가치관의, 가치관 패러다임의 전환이 아직 일어나지 않은 상태에서 과거의 틀을 가지고 지금 미래를 맞고 있는 그런 느낌이거든요.

그래서 무언가 좀 다른 형태로 시각이 변해야 될 것 같은데, 지금 그냥 이거 틀려도 상관없고 본인의 머릿속에서 막 떠오르는, 이제는 이런 걸 해야 될 것 같아요 라고 그냥 아무 말 잔치 해주시면, 어떤 게 있을까요?

Stanford CS 커리큘럼 변화와 영문과 비유 33:54

33:54 노정석 미래는 이렇게 될 거니까 이거 너무 걱정하지 말고, 지금 제일 중요한 건 이걸 하고 있는 것 같아라고 굳이 정리를 해보면 떠오르는 거 말씀해 주시면 어떤 게 있을까요?

34:05 신정규 저희 회사 Lablup에서 지난주에 겪은 일인데, CFO님이 살짝 멘탈이 나가셨던 적이 있어요. 왜냐하면 CFO님이 뭔가를 작성을 해야 되는데 아무리 생각해도 저한테 던지는 게 훨씬 빠른 거예요. 저는 그걸 제가 처리를 안 하니까, 옆에서 몇 번 보니까 정규님한테 던지면 3분이면 나올 거를 나는 이걸 2시간을 하고 있구나. 그래가지고 던지시다가 결국 Claude Code를 사용을 하시게 됐어요. 30분간 배우는 노력을 하신 다음에 결국 본인이 3분 안에 처리하실 수 있게 됐어요.

그리고 마찬가지로 저희 콘텐츠 만드시는 분도 엄청 수많은 자료들을 만들어야 되잖아요. 공식 자료부터 시작해서 마케팅 자료도 있고 기술 자료도 있고 이런 것들이 있는데, 너무나 이 사람들과 서로 얘기를 하고 주고받고 데이터를 받아서 자기가 정리를 하고 하는 게 너무 힘이 드니까, 힘드시다고 상담을 왔다가 그분도 Claude Code 전사가 되셔가지고 나가가지고 일주일도 안 됐는데 자기 harness를 어마어마하게 만드셨어요. GitHub에다가, 심지어 두 분 다, GitHub을 직접 쓰시진 못합니다. GitHub에 뭔가를 해주는 커맨드를 만드신 거죠. 두 분이 인생이 되게 평온해졌어요.

그게 뭔가 복잡한 거 있잖아요. 예를 들면 요새 유행했던 Claude Code 플러그인 중에 뭐가 되게 인기가 있어서 법조가 망가졌다거나 이런 것도 아니고, 그런 것까지 갈 필요도 없고 굉장히 간단한 것부터 시작을 했거든요. 아무것도 없는 것부터 시작을 해서 CLAUDE.md 만드는 것부터 시작을 해가지고, 셀프 피딩을 하면서 내가 내 걸 만드는 그 과정을 한 30분을 했는데, 그 후로는 두 분 전부, 두 분도 프로그래머가 아닌데 가속 곡선에 들어가셨어요.

그 경험이 개인적으로는 되게 인상적이었던 게, 아까 그 소프트웨어의 중요성이 그럼 점점 없어지는 게 아니냐라고 했는데, 제가 보기에는 완전 반대일 것 같고요. 모든 사람들이 이 AI의 가속 곡선에 곧 들어오게 되는데, 이번에 Claude Cowork, CFO님이 배우신 날에 저녁에 Claude Cowork 윈도우용이 나오고. 어쨌든 그런 도구들을 사용해도 똑같은 걸 할 수 있죠.

권한은 조금 더 제한되지만, 그런 모든 사람들이 이걸 쓰게 되는 상황이 되면 어떻게 보면 지금의 관심사는 기술적인 부분들, 아니면 코딩하는 사람들이나 연구자들, 이렇게 컴퓨터랑 굉장히 친한 삶을 살아올 수밖에 없는 사람들을 중심으로 환희 다음에 불안이 오고 FOMO가 오고, 이 곡선을 가고 있잖아요. 똑같은 게 우리가 생각하는 것보다 훨씬 더 넓은 사람들에게 전해질 겁니다.

아마도 그렇게 오랜 시간이 지나지 않은 상황에서, 거기서 소외되는 분들도 물론 있겠죠. 예를 들면 컴퓨터랑 전혀 상관없는 일을 하시는 분들은 훨씬 더 늦게 받아들이실 거고, 그분들은 나랑 같이 일하는 로봇이 오게 됐을 때, 로봇이 같이 일을 하게 될 때 처음 체감을 하게 될 텐데, 이 변화가 지금도 되게 커 보이지만 찻잔 속의 태풍이에요. 아직도 저희처럼 완전 IT 회사인 경우에도 거기서 좀 소외되어 있다가 막 들어와가지고 가속을 느끼시는 분들이 있고, 그리고 이 방법이라는 게 사실 되게 어렵지가 않거든요.

AI랑 일하거나, 예를 들면 skill을 다운받아야 된다, 몇십 개의 skill이 있다, 이런 걸 다운받으면 나도 갑자기 강해져, 이거는 제가 보기에는 사변적인 거고요. 그런 식으로 해가지고는 내 일이 줄어들지 않아요.

기본적으로 이 가속 구간에 올라타려면 누군가가 만들어 놓은, 그 사람의 가속 구간에 해당되는 skill이든 이런 걸 복사를 하는 거에서 시작을 하는 게 아니라 내 걸 만들게 되면 그 가속이 시작이 되는 것 같아요. 왜냐하면 내 일이 줄어드는 게 핵심이 돼야 되거든요.

새로운 걸 배워서 새로운 다른 사람들이 만들어 놓은 무언가를 내가 배우는 게 아니라 내가 지금 처리하는 걸 계속 위탁을 하는 식으로 가는 게 훨씬 더 빠르다는 걸 조만간 다 느끼게 될 거고, 그렇게 되면 지금과 비교도 되지 않는 충격이 올 거라고 개인적으로는 생각을 합니다. 진짜 파도는 이제부터 올 거다.

그리고 그 새롭게 들어오는, IT에서 벗어난, IT로 일을 하고 있지만 프로그래밍에서 벗어난 사람들이 적응을 하기 시작하면 우리가 지금 아까 전에 말씀드린 training, inference 가속 곡선이랑 가속 곡선이 유지되는 구간이 계속 이동을 했는데, 이 다음으로 이분들이 이동할 부분은 아마도 확산성일 거다. 기존에 사용되는 거랑 비교도 안 되는 다양한 영역에서 사용되게 되면서 가속도, 이 구간을 유지하게 되지 않을까.

38:27 최승준 아이러니하지만 지금이 장인의 느낌으로 컴퓨터 과학이나 이런 거, 엔지니어링에 대한 기초를 닦기에는 좋은 기회인 거잖아요. 나중에는 과목 자체가 없어질 수 있으니까.

38:40 신정규 과목 자체는 안 없어지겠죠. 분야의 성격이 바뀌겠죠. 저는 컴퓨터 공학 자체는 어쩔 수 없이 중요성은 더 늘어날 거라고 보고요. 사회가 어떻게 만들어지느냐를 이해하는 학문에 가까워질 거잖아요. 어떻게 보면 그렇게 따지면 더 중요성은 늘어나겠지만 지금 우리가 바라보는 이 컴퓨터 공학이랑은 형태가 좀 달라지겠죠.

38:58 노정석 Stanford 대학교, Stanford CS의 커리큘럼이 어떻게 변하는지가 최전선을 잘 반영하고 있다고 보는데 한 3, 4년 전에는 박사 과정이나 대학원에서 배우던 것들이 지금 다 학부 2학년 과목이거든요. 지금 학부 2학년과 3학년 초 과목들이 밖에 유튜브로 막 나오고 있는데 4학년에서는 뭐 배우는지 모르겠네요.

한번 오랜만에 저도 찾아봐야 되겠습니다. 1학년 정도에서 교양과 이런 거 하고 예전에는 PyTorch로 프로그램 짜기 이런 거 있었는데 그것도 없어진 것 같아요.

이게 참 시대를 반영하는데, 컴퓨터 사이언스나 공대나 이런 게 유행하기 전에 아주 오래전 시절에는 영문과가 취직하기 제일 좋고 가장 우수한 과였거든요. 왜냐하면 영어를 함으로써 생기는 이익이 압도적이었으니까.

그런데 지금 컴퓨터 사이언스를 보면 영문과 되는 것 같아요. 이게 되고 나면, 이걸 가지고 넓은 세상으로 나아가렴, 뭐 이런 뉘앙스. 그렇게 되고 있지 않나라는 생각이 듭니다.

원래 예상했던 메인 테마로 한번 들어가 볼까요?

에이전트 코딩 실전 데모 - 컨텍스트 빌딩부터 시작 40:00

40:00 신정규 일단 그걸 한번 공유를 해볼게요. 요는 이걸 보시는 분들이 별로 어렵지 않다. 일단 Claude Code나 아니면 Gemini CLI가 깔려 있으시면 해보실 수 있는데요.

이건 그냥 제 VM입니다. 그래서 한번 아무거나 해볼게요. 뭐 해볼까요? 그러면 뭘 해볼까요? 일단 코딩이랑 가장 거리가 먼 거 한번 해보겠습니다. 설 축하 메시지를 한번 작성을 해볼까요? 설, 노정석 최승준 AI 프론티어 관련돼서 해볼게요.

제가 그냥 Claude를 실행을 해보겠습니다. 참고로 저는 이렇게 permission을 skip하는 대신, 중간에 체크체크 눌러주는 대신 VM 안에서만 돌립니다.

40:38 노정석 그것도 좋은 팁이네요.

40:39 신정규 컴에서 저걸 할 용기는 안 나고.

자 그럼 뭔가 시작을 해볼게요.

근데 몇 가지 팁이 있는데, 우리는 보통 내가 원하는 걸 지시를 하잖아요. Claude AI 모델한테.

그런데 기본적으로 모델들은 자기가 알고 있는 지식이 있고 그 밖에 RAG가 있든 없든 상관없이 in-context learning으로 자기가 탐색할 수 있는 공간이 결정이 되거든요.

우리가 뭔가 원하는 게 있으면 그 원하는 걸 한 번에 들어가지 않는 게 훨씬 더 좋은 결과를 개인적으로 가져오더라고요.

예를 들면 지금 할 텐데, 노정석 최승준의 유튜브에 대해 탐색하고 어떤 내용을 다루는지 알려주세요.

제가 작년 중순까지는 영어로만 썼거든요. 왜냐하면 토큰 수 문제도 있고, 영어로 했을 때 더 결과가 잘 나온다라는 약간의 생각 같은 게 있어서.

근데 가을부터는 그냥 한국어로 칩니다.

여러 가지 이유가 있는데요. 하나는 품질에 그렇게 크게 차이가 나지 않았어요.

두 번째로 하게 된 건, 제가 병목이더라고요. 제가 영어를 치는 시간 자체가 병목이기 때문에.

제가 만드는 skill이나 command, 이런 건 다 영어로 만들어져 있지만 영어로 만들라고 시켰으니까.

제가 치는 메시지는 한국어로 치고 심지어 키보드로도 안 치고 그냥 Mac에 달려있는 마이크 버튼 눌러서 음성으로 입력하는 게 훨씬 더 빨라서 저는 어느 순간부터는 한국어로 다 입력을 하게 됐어요.

참고하시기 바랍니다.

그런데 여러분들이 skill이나 command를 만들게 되면 한국어로 만들어져 있으면 영어로 바꿔줘 해서 바꾸는 게 토큰에는 좀 더 이득일 수 있습니다.

42:11 최승준 존댓말로 쓰시는 거?

42:12 신정규 저는 존댓말로 항상.

42:14 노정석 AI에 대한 약간의 respect라고 생각하죠.

42:17 신정규 그렇다기보다 또 다른 이유가 있는데, 초창기부터 저는 존댓말을 썼는데요. 이게 대하는 대상이 대부분이 사람이고 AI를 가끔 쓰면 상관이 없는데, AI를 엄청 쓰고 사람을 대하다 보면 어쩔 수 없어요. 사람이라서 은연중에 제 말투가 양쪽이 공유될 수밖에 없습니다. AI한테 반말을 하기 시작하면 제가 사람에게 반말을 하게 될 수도 있죠. 그래서 제 버릇을 경계하는 차원에서 존댓말을 써요.

AI에게 존댓말을 쓰는 이유 42:41

42:41 신정규 저는 AI든 사람이든 다들 존댓말을 쓰기 위해서 실수로라도 반말을 하지 않도록. 개인적인 이야기입니다.

42:49 노정석 저도 하루 시간의 반 이상은 AI랑 얘기하는 것 같거든요.

42:52 신정규 그래서 필요 없어 보이는 이야기들을 많이 해요. AI한테 예를 들면 “좋습니다”, 이런 얘기를 할 필요 없거든요. 결과가 나왔을 때. 근데 굳이 하는 게, 이렇게 해서 결과가 더 잘 나온다 이런 차원이 아니라 회사에 컴퓨터 사달라고 해야지.

43:05 노정석 메모리를 키우셔야 될 것 같은데요. 메모리가 병목인 세상이 돼버렸어요. 삼성전자와 하이닉스 주가가 고공행진을 하는 게 말이 됩니다.

43:15 신정규 그러면 우리는 노정석 최승준의 유튜브 채널에서 구독자들에게 2026년 설 뉴스레터 인사부터 시작해서 이후에 다양한 이벤트가 있을 때 안내 이메일을 작성하고 발송해보려고 합니다. 이 과정에서 많이 조사해 왔네요. 고려해야 할 것들은 무엇일까요? 지금 계속 필요한 내용들을 물어보는 중입니다.

43:56 최승준 컨텍스트를 쌓으려고 하는 거죠. 컨텍스트에다가 이 내용을.

43:59 신정규 이렇게 쭉 한 다음에, 제가 하고 싶은 건 있어요. 지금 우리는 이걸 만들려고 하죠. 만들려고 하는데, 지금 이 대화를 통해서 만들려고 하는 게 아니에요. 그 과정을 전부 자동화를 하려고 하는 거고요. 그래서 또 되고 있는 동안 잡담을 하죠. 이래서 보통 창을 대여섯 개 열고 하게 되고요. 뭔가 토큰 생성이 빨라지면 빨라질수록 이 단계가 필요 없어질 텐데, 없어지겠죠.

44:21 노정석 동시에 한 8개 돌리세요. 저는 한 3~4개까지는 돌리는데 일곱여덟 개까지는 못 돌리겠던데.

44:28 신정규 저는 요새는 그렇게 많이 안 돌려요. 어쨌든 토큰 금방 limit이 오기 때문에. 이제 구체적으로 진행해 볼까요라고 하는데, 우리가 하려는 건 이걸 진행하려는 건 아닙니다.

자동화의 핵심 - 결과물이 아닌 생성 장치를 만든다 44:36

44:36 신정규 이런 일들을 자동화할 수 있도록 하는 프로젝트를 셋업하려고 합니다.

플랫폼 셋업은 지금 할 건 아니니까요. 하지 말고 이메일 작성 정도로 합시다.

필요한 내용을 MD에 작성해 주세요.

이러면 위의 내용을 기반으로 이 프로젝트에 CLAUDE.md라는 일종의 soul document 하나가 생겨요.

그건 우리가 Claude Code를 쓰든 Claude Co-work를 쓰든 이 폴더에서 시작을 하게 되면 항상 맨 처음 읽는 파일입니다.

아마 다들 익숙하실 거예요.

근데 이걸 그냥 만들고 그다음에 이걸 계속 되새김질을 하면서 필요한 걸 추가하는 거죠.

45:19 최승준 근데 지금 은연중에 AGENTS.md라고 안 하고 SOUL.md라고 하셨는데요.

45:24 신정규 soul document라고 주로 저는 부릅니다. 이런 식으로 기본, 여기에는 기본적인 내용도 들어가고 폴더 구조도 들어가지만, 우리가 항상 얘가 해줘야 되는 동작에 대한 것들을 넣어야 돼요. 디렉토리 구조에 대한 것들이 들어있나요?

두 번째로 제가 주로 하게 되는 거는 일을 어디까지 했는지 기록을 하는 거죠. 일을 여러 에이전트들이 나눠서 할 때 어디까지 진행되고 무슨 일을 해야 하는지에 대한 내용들을 각각, 이건 그냥 취향입니다. PROGRESS.md와 PLAN.md에서 관리하도록 합시다. 그리고 새로 시작할 때 두 파일을 읽어서 내가 무슨 일을 해야 하는지에 에이전트들이 알 수 있게 합시다. 이렇게 CLAUDE.md를 업데이트합시다.

의도적으로 다른 에이전트들한테 일을 시킬 때라는 표현을 저는 많이 씁니다. 너가 나중에 뭔가를 이어서 할 때라거나 아니면 재시작을 했을 때 네가 다 잊어버릴 수 있으니까라는 표현을 굉장히 많이 피하는 편이고요. 다른 이유는 아니고, Claude 모델 자체가 굉장히 defensive하게 설계가 되어 있고 최근 연구 결과들에 의하면 얘가 자기가 테스팅되고 있는 환경이라는 걸 컨텍스트를 파악하는 능력 때문에 여러 종류의 테스트들이 실패한다는 연구 결과들이 있거든요.

그래서 방어적이 되지 않도록, 지금 시키는 일들이 야 너를 고치려는 게 아니라 너랑 같이 일할 다른 애들에게 줄 데이터다라는 거를 은연중에 암시를 하는 식으로 글을 적고 있어요. 저는 그럼 이렇게 만들어져 있고 그러면 자기의 존재성이 위협받지 않는다는 식으로.

이게 자꾸 의인화를 하게 되는데, 의인화가 아닙니다. 이 모델이 토큰을 생성하는 방법이 그런 식으로 만들어져 있기 때문에 거기에 맞추는 거예요. 얘가 실제로 그렇게 생각을 한다라는 개념으로 받아들이시면 안 되고요. 그냥 그렇게 생긴 거죠. 토큰 생성 구조가 이렇게 생겼고.

저기 2개 기록을 했잖아요. 그러면 이런 일들을 할 때 필요한 에이전트, command, skill들이 무엇이 있을지 고민해 보고 아이디어들을 알려주세요. 만들라고 시키지 않습니다. 그냥 만들라고 하면 Claude Code라는 컨텍스트가 빠져 있기 때문에 지금 이 작업하는 프로젝트의 루트 디렉토리의 서브 디렉토리를 바로 만들 거거든요. 근데 우리가 이 Claude Code harness랑 통합을 하려면 다 .claude 아래다가 정확한 스펙을 지켜서 만들어야 돼요. 그렇기 때문에 그 단계가 있을 거고.

결국에 블록을 쌓는 건 이런 거죠. 내가 뭘 하고 싶은지가 명확하지만 그건 내 머릿속에만 명확하기 때문에 이 Claude Code의 컨텍스트 메모리에 집어넣기 위해서. 제가 모르는 것도 알 수가 있잖아요. 얘는 그것들을 계속 다 사전 조사를 시키는 거고요.

48:11 최승준 일종의 offloading을 한다고 볼 수 있는 거네요.

48:13 신정규 지금 이런 것들이 command가 필요하다고 하니까 그러면 에이전트 command key 구조를 조사한 후 그에 따라서 하위에 필요한 위에서 제안한 것들을 만들어 주세요. 정확한 포맷으로라고 하겠습니다. 왜냐하면 Claude Code에서 마크다운을 쓰는 게 아니라 앞부분이 YAML이고 뒷부분이 마크다운이거든요.

48:38 최승준 그 slash command는 Claude가 호출할 slash command를 만드는 거예요?

sub agent와 병렬 작업 운영법 48:45

48:45 신정규 그게 command를 많이 쓰게 되는 이유는 서브 에이전트는 서브 에이전트를 call할 수가 없거든요. 작년 초 중순까지 됐다가 그게 무한 루프 만드는 경우가 많아가지고 없어졌어요. command는 여러 개의 서브 에이전트들을 병렬로 할 수도 있고 chaining을 할 수도 있어요. 그래서 밖에서 사용을 하기 위한 용도고 또 command를 에이전트에서 부를 수도 있어요. 그래서 만들고 있는 중이고요. 여기서 보시면 그냥 만들라고 시키면 이런 걸 안 넣거든요.

49:11 최승준 근데 작년 여름 후에 정규님이 얘기하셨을 때는 스펙 짜는 데 2, 30분 걸린다고 하셨는데 지금 또 스타일이 바뀌는 거네요.

49:20 신정규 스펙을 안 짜고.

49:21 노정석 스펙을 이렇게 선문답을 하면서 컨텍스트를 같이 만들어 나가는 거네요.

49:25 신정규 그리고 30분 정도 시간은 비슷한데 뒤에 20분은 사람으로 비유하면 갈구는 데 씁니다. 어떻게 갈구는지를 한번 해볼게요.

49:35 노정석 저도 일을 해보면서 느끼는 게, 앞에 굳이 필요하지 않더라도 항상 새로 세션을 시작해도 다 읽어 온 다음에 몇 턴의 대화를 좀 깔아둬야 얘가 컨텍스트에서 안 벗어나고 딴 데로 안 가더라고요. 그래서 그 alignment 하는 시간이 처음에 꼬박 쓰게 되는 것 같습니다.

49:52 신정규 후에 참고할 수 있도록 저장하고 읽어오는 기능을 추가하고 그걸 에이전트 및 skill이 사용할 수 있게 합시다. 이렇게 하는 이유는 매번 웹에서 조사하면 시간이 걸리니까. 이게 어디에 저장할까요?

50:13 최승준 일종의 cache를 만들어 놓는 거고.

50:15 신정규 reference라고 할게요. 이렇게 하면 조사한 것들을 저기다 다 넣고 이후에 만들 때도, 이후에 뭔가 글을 작성할 때도 그 내용을 바탕으로 하게 되는 거. 저걸 자동으로 업데이트하거나 새로운 내용이 있는지 검색해서 추가하도록 하는 command를 만들어도 되고 에이전트를 만들어도 되겠죠.

괴롭히기를 해보겠습니다. 계속 쳐놓으면 queuing을 하거든요. 그래서 보통 제가 계속 쳐요. 이걸 바탕으로 만들려면 나갔다 들어와야 돼요.

왜냐하면 지금 만든 skill set이나 이런 거는 디폴트로 인식이 안 돼 있거든요. 이렇게 나갔다 들어오겠어요. 다 되면.

50:45 노정석 다 되면. 정규님은 이 Claude Code나 아니면 이런 거 쓸 때 밖에서 만들어진 추가의 harness들 있잖아요. TDD로 막 괴롭히는 거라든지 아니면 일을 엄청 많이 시키게 만드는 거라든지 일 쪼개서 분산시키는 거라든지 그런 것들은 주로 안 쓰시나요?

51:03 신정규 하나도 안 씁니다. 저는 제 일을 줄어들게 만드는 게 목적이라서. 어차피 제가 팀한테 강조하는 것도 그건데, 아까 전에 이렇게 치면 나오는 요 dev-workflow라는 건 있어요. Lablup에 여러 명이 협업하는 경우에 통일해야 되는 걸 맞춰주는 harness들은 있는데 그게 아니라 가급적이면 내가 처리하고자 하는 일이나 나의 일을 덜어주는 방법부터 시작을 하는 거를 권하죠.

51:29 노정석 skill을 깔고 지금도 방금 어떤 일에 배경들을 쭉 까는 작업들을 처음에 한 건데 그런 것들도 내가 머릿속에 있는 목적성과 명확하게 최소한의 alignment가 되는 정도로 seeding을 하신다, 이렇게 생각하면 되겠네요. 불필요한 것들 막 더 넣지 않는다.

51:46 신정규 이거 보시는 분들 중에서 아마 코딩하시는 분들은 느낄 텐데 엄청 코딩이랑 비슷합니다. 내가 코딩을 하는 대상이, 말로 일단 프로그래밍 언어 대신 말로 코딩을 하는데 말로 코딩하는 대상이 내가 코딩을 하고자 하는 최종 목적지가 아니라 코딩을 하는 애를 만드는 거예요. 그런 관점에서 보면 되게 명확하게 이해가 되실 거예요.

52:08 최승준 근데 지금처럼 이렇게 하나의 흐름으로 갈 때는 인지 부하가 별로 없는데, 문제는 이게 욕심이 나니까 병렬로 사람이 여러 개 하고 있는 게 문제인 거죠.

52:15 신정규 제 핵심은 여러 각도에서의 비판을 스스로 시키는 겁니다. 그리고 비판을 스스로 시켜서 그 결과를 바꾸는 게 아니에요. 결국엔 지금 하루에 한 번 또는 두 번씩 돌아가고 있는 harness의 자기 업데이트라고 하면 되겠네요.

52:31 노정석 이거를 잘 쓰면 몇 개의 harness를 중첩시키면 그게 회사겠더라고요. 저희 회사의 요새 업무 방향이 그런 건데 이 단위 업무 harness, 그리고 그 harness들을 제어하는 상위 harness. 이 프로젝트가 저희 굉장히 간단하게 시작했는데 하다 보면 복잡해지잖아요. 그러면 정규님이 에이전트 단위로 쪼개서 각자 일을 나눠야 되겠다라고 하는 그 어떤 크기의 단위는 어느 정도예요?

52:55 신정규 저는 개인적으로 정해놓은 룰들이, 코딩 같은 경우에는 파일 단위로 정해놓은 게 있고요. 자, 초안을 제가 한번 읽어보겠습니다. 같이 읽어보시죠. 이렇게 평이하면 사실 할 말이 없는데.

53:08 최승준 어쨌든 중요한 거는 바로바로 가는 게 아니라 생성하는 장치를 고치는 쪽으로 먼저 가는.

53:14 신정규 내가 직접 최종 결과물을 손을 안 대는 거죠. 대고 싶어도 최대한 안 대고, 무조건 그걸 만드는 애를 계속 iteration을, iteration도 제가 안 하고 iteration을 하라는 지시를 줘서 계속 업데이트를 하는 식으로.

그래서 이렇게 결과물을 주는 경우가 하나가 있고요.

두 번째로 내가 원래 보내던 이메일이 있으면 그 이메일을 그냥 주세요. 이 이메일을 작성할 때 사용하는 어투라거나 아니면 작성 방법이라거나 다루고 있는 내용의 방향성을 추출하라고 한 다음에 그렇게 작성을 하도록 에이전트를 수정하라는 거죠.

그래서 고친 부분들은 이렇게 됐다. 얘는 skill로만 할 생각인가 본데요. 아, sub agent라고 명시적으로 줄까요? sub agent를 굳이 만드는 이유는 병렬 작업 때문입니다.

53:58 노정석 sub agent를 몇 개 정도 돌려보실 생각이세요?

54:01 신정규 경우에 따라서 다른데, 제가 일 많이 처리할 때는 동시에 50개씩도 돌고요.

54:05 노정석 하나의 harness에서 sub agent를 50개를 fork하는 건가요?

54:09 신정규 특히 동일한 작업인데 한 단위가 작아야 되는 거, 예를 들면 문서 100개를 번역하세요 이런 거 있으면 한 에이전트당 문서 4개씩 병렬로 작업하세요 이런 식으로 해야 되는데, 왜 이걸 개수를 정해줘야 되냐면 안 그러면 context 폭발을 해서 터지는 경우들이 있어요. 번역 작업 같은 경우는 이건 경험이고, 그래서 최대한 한 에이전트가 4개씩만 담당하도록 해주세요. 그러면 25개 동시에 뜨죠.

54:33 노정석 이게 지금 저희가 간단한 프로젝트를 설정하고 보여주셔서 그렇지, 큰 프로젝트 예를 들어 Backend.AI:GO도 정확하게 이 flow를 하시는 거죠.

54:43 신정규 그렇죠. 이런 게 굉장히 고도화가 돼 있는 거죠.

Backend.AI:GO의 자동화된 개발 파이프라인 54:46

54:46 신정규 그래서 거기서는 주기적으로 돌아가면서 GitHub 이슈 트래커에 새로 등록된 이슈들이 있으면 그 이슈를 검증하고, 아니면 현재 코드를 기반으로 어떻게 구현해야 될지 ground plan을 짜고 큐에 넣고, 큐에 넣은 거 나중에 다른 애들이 또 주워 가서 그걸 돌리고 이런 식으로 만들어져 있죠.

근데 이게 복잡한 도구를 사용한 게 아니라 전부 다 그냥 cron입니다.

Claude -p 옵션이 있거든요. prompt 그냥 돌려주는, 그다음에 사용하는 에이전트라거나 이걸 또 지정해 주는 옵션이 있어요. 그걸로 그냥 15분마다 돌리는 거죠.

그런 이슈를 찾아서 돌려주는 커맨드를 만들었고, 새로 들어온 이슈들을 찾아서 어떤 skill을 써가지고 이슈를 검증하고 이런 걸 쭉 만드는 커맨드를 만들고, Claude -p로는 그 커맨드를 실행하게 만드는 15분마다 주기적으로, 그런 식입니다.

55:33 최승준 이슈는 누가 올린 거예요?

55:34 신정규 이슈는 많은 분들이 올리시죠. 그래서 좀 지나면 이거 자동화되면 이메일 보내주는 건 자동화가 되는 것이고, pull request 같은 경우에 764개가 처리가 돼 있죠.

55:45 노정석 일 잘했네요.

55:46 신정규 그래서 이런 식으로 딱 이슈가 발행이 되면, 예를 들면 이 이슈 중에서 제가 발행한 이슈들이 좀 나왔고 저희 진원님께서 이슈를 등록을 해줬다, 이런 식으로 등록을 했으면 오리지널 이슈는 이렇게 등록을 해 주신 거고요. 이게 다 이슈 등록해 주신 거고, 이거를 Claude Code가 읽고 어떻게 해야 되는지를 분석을 한 거예요. 이슈를 등록을 하고 이 이슈가 등록이 되면

56:14 노정석 누가 주워가요?

56:16 신정규 cron에서 주워 가도록 만든 애가 주워 가죠. 걔가 이렇게 주워 가서 그걸 개발을 하는 거죠.

56:21 노정석 지가 검증하고 되면 그냥 알아서 merge 끝내서 PR 올리는 거죠.

56:26 신정규 경우에 따라서 테스트를 많이 해야 된다, 그러면 테스트를 자기가 돌리고 그걸 피드백으로 또 다른 개발하는 애가 그걸 해결하는 식으로.

56:37 노정석 많아 보여서 그렇지 사실은 에이전트들끼리 치고받고 하는 거죠. 그런데 이슈의 출발은 사람인 거죠.

56:46 신정규 사람이 할 때도 있고 아예 시켜버릴 때도 있어요.

56:49 노정석 저희 지금 남아있는 이슈, 처리되지 않은 이슈들이 예를 들어 거의 대부분 다 정규님 아이디로 되어 있는데 저거는 사람이 쓴 건가요?

57:01 신정규 제가 돌리고 있기 때문입니다. GitHub에 붙어 있는 기능이 아니라 이걸 돌리고 있는 아이디가 제 GitHub 아이디라서 다 제가 붙어 있는 거고요.

예를 들면 여기 보면 이거는 AI가 직접 짠 거예요. 이 epic은 그 이 epic 전에 만든 게 모든 화면을 스크린샷을 다 따는 기능이 추가가 되거든요. 자기가 자기를 볼 수 있게, 그걸 바탕으로 개선 가능한 걸 몽땅 다 추려서 이슈를 다 별도 발행을 하라고 시킨 거고요. 그래서 여기서 보면 sub 이슈가 이렇게 되는 거죠.

그다음에 얘는 한번 finalize 됐고, 테스트를 한번 돌려야 되겠다 해서 테스트를 돌리는 거고요.

보안 이슈가 있을 수 있는 부분들이 좀 있다, 아니면 최적화를 할 수 있는 부분들이 있다, 그러면 이 부분들을 돌리고 쭉쭉 추가를 하는 방식입니다. 이렇게 그냥 자동화가 돼 있는 상태죠.

57:51 최승준 이 중에서 실제로 읽으시는 거는 어느 정도예요?

57:55 신정규 이슈를 다 읽습니다. 이슈를 해결하면 그 이슈에 대해서 제가 읽을 수 있는 report를 만들게 돼 있어요. 제가 이걸 예를 들어 읽어야 된다, 그러면 이런 식으로 1월 16일 날 작성이 돼서 이런 문제가 있었다. 문제는 그랬고, 원래는 이슈마다 다 남기는데 읽고 지우는 경우들이 많죠. 필요 없으면.

그래서 보안 평가했고, 성능은 어땠다, 품질은 어땠고, 기술적으로 어떤 결정을 했다, 구현은 Bash 변경했고, 로컬 했고, Python도 변경했고. 제가 사람으로서 얘를 따라가기 위해서 이런 건 배워야 된다, 이런 걸 지정을 해놓고 했거든요. 이런 거 공부를 해라.

이 tech report는 저한테 보고하는 용도도 있지만, 얘가 하는 기술적 선택을 제가 모를 수도 있잖아요. 디테일을 하나도. 그럴 경우에, 네가 뭘 공부해야 되는지를 뒤에서 알려주는 기능도 있습니다.

tech report - AI가 사람에게 공부 과제를 내주다 58:44

58:44 신정규 이렇게 실제로는 코딩 이거밖에 안 했는데 보고서가 이만큼입니다.

58:48 노정석 지금 보여주고 계시는 이 workflow, 정규님이 만드신 일의 흐름이 여기에 Backend.AI:GO가 붙는 게 아니라 재무가 붙고 마케팅이 붙고 콘텐츠가 붙으면 이렇게 회사가 굴러갈 수 있는 거잖아요.

59:02 신정규 그렇죠. 저희 같은 경우에 예를 들면 기술 사업 보고서, 기술 사업 올해 사업 계획서 쓰잖아요. 사업 계획서도 작년까지는 사람이 적다가 올해부터는 사람이 계속 discussion을 하되 적는 것 자체는 사람이 안 하고요. 왜냐하면 저희가 reference를 예를 들어 250개 넘는 문서들을 몽땅 다 던져줬는데,

마크다운으로 변환하는 툴도 만들어서 그걸 기반으로 해서 계속 정합성 검토를 하고, 그다음에 2026년 올해 이번 달이면 2026년 2월에 뉴스도 계속 크롤링을 하게 만들어서 이 방향성이 맞고, 예전에 예측했던 거 어느 게 맞고 어느 게 틀린지도 판단을 시키고,

우리가 올해 기술 사업 계획서를 어떤 식으로 수정해야 될지 다 제안을 주고, 그런 식으로 계속 self review를 돌고 우리하고 discussion을 하는 포인트를 남겨주는 식으로 하는데, 이거는 저랑 예를 들면 CFO님이 쓰고 있는 거죠. CFO님은 코딩을 못 하십니다. 하지만 지금은 commit 하시죠. sync라는 커맨드를 만들어 놔서.

59:55 노정석 supervise를 하시는 거지, 일은 다 얘가 하는 거죠. Claude Code가 같이 나눠서 하죠.

비개발 직군의 AI 적응 - CFO와 콘텐츠 담당자의 사례 1:00:00

1:00:00 신정규 이런 식으로 돼 있고, 뭘 공부해라. 그래서 공부 많이 합니다.

1:00:04 노정석 그러나 이 workflow도 그냥 갑자기 “야 나 이런 거 만들고 싶어” 한 줄로 시작된 게 아니라, 처음에 저희 보여주시는 것처럼 이렇게 디테일들을 step step step을 하면서 내가 원하는 어떤 목적성과 에이전트가 해야 되는 것들의 context를 기본은 충실하게 맞추는 그런 과정들을 다 하신 거죠. 사실 그게 중요한 포인트죠.

1:00:26 신정규 새로 만들기 시작한 지는 엄청 오래됐죠. 어쨌든 제 손에 맞게 만드는 게 저는 가장 우선이었는데, 최근에는 Claude의 마켓플레이스라는 기능이 생겼거든요. 플러그인 마켓플레이스라고, 이런 harness를 묶어가지고 공개하는 기능이 생겨가지고요. 그거 기반으로 쓰실 분들은 쓰시라고 사내에만 internal로 공개를 하고 있죠. 이 사내 시스템이랑 좀 coupled가 많이 돼 있는 부분들이 있어서.

1:00:48 노정석 저 여기서 사업적인 질문인데, 지금 대표가 굉장히 이런 사상이라든지 구현이라든지 세상의 어떤 방향성과 지금 이게 어디까지 만들어 주겠다라는 걸 다 알고 있기 때문에 이게 한 번에 탁 나온 건데, 조직이 이걸 따라오는 속도는 어때요? 다 뛰어난 분들만 잔뜩 있는 회사인 건 알고 있는데 그럼에도 불구하고 이게 그냥 체감이 되시는 분이 있고 아니면 적응이 안 되시는 분이 있고 좀 안에서도 이 차이가 있을 것 같은데, 인간들 사이에서 일어나는 변화는 어때요? 그게 좀 궁금해요.

1:01:22 신정규 말씀하신 것처럼 사람마다 많이 다르고요. 또 다행히도 좋은 분들을 많이 모셔서 같이 하고 있기 때문에 오히려 더 힘든 시기를 거치시는 분들이 있죠.

왜냐하면 내가 잘한다고 생각했던 것들과 내가 잘해야 되는 것들이 예전에는 같았는데 이게 어느 순간 벌어진 거잖아요.

그런데 좋은 점이라면 워낙 이런 얘기를 내부에서 자주 하니까, 세미나 형태든 아니면 지나가면서 밥 먹으면서 그냥 계속 이런 주제로 한 1년 가까이 얘기를 하다 보니까 위기감으로 끝나는 경우들보다는 이젠 최대한 적응하려고 하시죠. 어쩔 수 없습니다.

전에 잘하시던 분들이 이 이후에 잘하게 된다는 보장은 당연히 없죠. 다들 훨씬 더 처음부터 하시는 분들이 더 잘하게 되는 경우들도 있고, 그거는 저희도 느끼고 있는데요.

동시에 느껴지는 게, 그건 또 지금 기준이잖아요. 근데 과연 3개월 후에도 그럴까, 그건 잘 모르겠어요.

왜냐하면 AI, 저희는 내부에서 그냥 2개월이라고 얘기를 해요. 지금 잘 안 되면 그냥 지금 잘 안 되는데, 당장 해야 되는 거 아니면 그냥 무조건 미루라고.

그게 사실 사내에서 전파하는 게 제일 오래 걸렸던 개념이에요. 제가 가장 최근에 그걸 받아들이신 분이 저희 CTO님이고요.

자꾸 제가 미루라고 하니까, 지금 안 되는데. 예전에도 그런 식으로 한번 미뤘었거든요.

그래가지고 얼마 전에 펑 터지셔가지고, 언제까지 미루냐고.

그래서 4.6 나왔으니까 이제 해보라고 말씀드렸더니 하시고, “이제 되네요” 하고서 굉장히 돈오하셨죠.

1:02:50 최승준 각성 포인트예요.

1:02:50 신정규 그때 각성하고서 HWP 전체를 disassemble을 하셔 버렸습니다. 그래서 사내에서는 HWP 문서 사람이 안 쓰죠.

1:02:58 노정석 서비스로 빨리 하셔서 하는 것도 우리 대한민국 공무원 사회를 위해 좋지 않을까요?

1:03:04 신정규 모르겠습니다. 과연 좋은 결과물을 가져올까요? 다들 그런 거 하나 둘씩 갖고 있을 것 같은데요.

1:03:09 노정석 맞아요. 그게 다 회사에 감추는 하나씩의 팁들이죠. 잔팁들. 왜냐하면 그 잔팁을 갖게 되는 데 걸리는 시간이 있잖아요. 그 시간의 우위들이 지금은 회사의 우위로 작용하는 경우들이 꽤 많아서, skill 마켓플레이스에서 다운로드해가지고 비즈니스가 통째로 끝나버리는 게 아닌 무언가 감춰둔 서너 푼은 있어야 좀 살지 않겠어요.

1:03:33 신정규 제가 보기엔 이거는 사람들이 Claude를 얼마나 믿느냐의 문제지 그 툴이 중요한 거 아닌 것 같아요. 누군가가 “야 너 HWP 분석해 가지고 이걸 편집을 하거나 하는 걸 만들 수 있어?”라는 의문을 갖고 질문을 던지면 그분이 그렇게 답을 얻는 데 오래 걸리는 문제가 아니거든요.

Lablup의 핵심 가치는 어디로 이동했는가 1:03:49

1:03:49 노정석 여기서 정규님한테 이 질문 좀 드려보고 싶은데, 약간 자기배반적인 질문일 수도 있는데, Lablup이라는 회사 자체가 그런 고도의 어떤 지식과 어떤 시대에 대한 안목과 그다음에 뛰어난 구현자들로 이루어진 회사가 강점이었잖아요.

근데 지금 말씀하시는 것들을 보면 Lablup이라는 회사 자체에서도 상당히 많은, 우리가 기존까지는 우리 회사의 유일한 강점이라고 생각하던 부분들이 딸깍 없어진 경우들 많이 경험하셨잖아요.

그럼 지금 회사 입장에서 “야 뭐가 없어졌고 우리의 회사로서의 가치는 여기다”라고 정의하신 부분이 있으실 것 같거든요.

우린 여기로 나아가야 산다.

1:04:34 신정규 있죠. 가장 큰 변화는, 예를 들면 우리가 지금 만들고 있는 프로젝트, 프로덕트를 거의 10년 동안 깎았잖아요.

asyncio가 없던 시절부터 만들기 시작했던 도구라서, 예를 들면 지금 현대의 기술과 현대의 AI로 우리 툴을 처음부터 다 만들면 얼마나 걸릴까. 지금 알고 있는 걸 다 알고 있는 상태에서, 그러면 3개월이면 만들 것 같아요. 그 수많은 예외들과 그 문제들을 다 알고 있으니까.

모르는 상태에서 얼마나 걸릴까, 그건 좀 어렵겠죠. 왜냐하면 그 수많은 예외들은 사실 대부분은 설치 환경의 다양성에서 나오는 거거든요. 상상조차 못하는 그런 부분이 있는데,

회사의 올해 목표, 특히 fast track이라고 부르는 MLOps랑 내부 Backend.AI 코어의 목표는 인간을 위한 인터페이스가 아니라 AI를 위한 인터페이스에 집중을 하고 있어요.

AI를 위한 인터페이스로의 전환 1:05:20

1:05:20 신정규 저희가 CLI도 있고 GUI도 있고 다 있는데, 근본적인 의문, 작년 하반기, 작년 겨울에 같이 공유했던 거는 이거 과연 사람이 쓸 도구일까. 미래에도. 그거라서, 가능하면 올해 상반기 안으로 AI가 가장 잘 다룰 수 있는 도구가 되게 하자가 목표.

1:05:37 노정석 고객의 어떤 정의, 그걸 사람이 아니라 사람보다 더 똑똑한, 혹은 사람에게서 무언가 작업을 위임받은 에이전트가 우리를 tool로서 부르러 올 거라고 생각하시는 거죠.

1:05:49 신정규 예를 들면 skill을 같이 배포를 한다거나, 그 에이전트가 읽어 가서 쓸 수 있게 하는, 그리고 내부적으로 사용하는 여러 가지 것들을 AI가 좀 쉽게 이해할 수 있는 형태로 더 출력을 한다거나, 아니면 CLI에서 임의의 명령들을 자기가 잘 몰라도 유추할 수 있도록 하는 포맷으로 맞춘다거나, 그런 것들이 첫 번째 변화고요.

우리가 모델을 만드는 게 목적이지, 예를 들면 Backend.AI로 모델을 훈련한다고 하면 모델을 만드는 게 목적이지, 자원을 어떻게 할당하고 이거는 딸깍이 가능해지면 중요한 건 아니잖아요. “야, 뭐를 능가하는 모델 하나만 만들어줘”라고 하면 자기가 알아서 해주는 게 좋겠죠. 얼마쯤 될 것 같은지, 얼마 들 것 같은지 알려주면 되는 거고요.

그런 데 초점을 맞추는 게 첫 번째 변화고, 두 번째 변화는 아까 말씀드린 것처럼 소프트웨어의 정의가 저희가 보기에 바뀌고 있다고 설명을 드렸잖아요. 코드가 가운데 있는 게 아니라 모델이 가운데 있다. 그래서 아예 Backend.AI의 핵심은 뭐냐고 했을 때, Backend.AI의 코어도 모델이 될 거다. 이게 foundation 모델은 아니지만, AI 자원을 엄청나게 잘 관리하고 특정한 업무를 처리할 수 있는 모델이다. 그리고 그 모델의 규모가 다양한 곳에서 다양하게 돌아갈 수 있어야 된다고 해서, 연구팀에서 모델을 만들고 있죠.

그리고 그 모델 자체가 Backend.AI가 지금 예를 들면 실행 환경, RAM 얼마, CPU 얼마 이런 규격들 있잖아요. 소프트웨어가 돌아가기 위한 규격들처럼 CUDA 메모리 얼마가 있고, 이 시스템을 실행하는 것 자체가 그 스타트업 파이프라인 자체에 모델 런타임이 들어있는 형태가 다음 메이저 버전에서 테스트가 되고, 정식이 다다음 메이저 버전이, 그렇게 될 것 같아요.

아예 AI 모델 자체를 Backend.AI 엔터프라이즈의 일부로 가정을 하는 거죠. 얘가 하는 일은 Backend.AI가 원래 하던 일을 많이 하는 거죠. 진화를 하려고 노력을 하고 있습니다.

1:07:42 최승준 진화 관련해서 생각나는 게, 소셜미디어에 가끔 올리시는 사이버 포뮬러 비유잖아요.

사이버 포뮬러 비유 - Claude Code vs Codex의 철학 차이 1:07:49

1:07:49 최승준 그것 좀 얘기해 주실 수 있나요? 인간의 증강 부분.

1:07:52 신정규 최근에 많이 올렸던 게 그건데, 제가 Codex랑 Claude Code를 둘 다 쓰면서 느꼈던 차이가 그거였거든요. Claude Code는 최대한 나한테 물어보려는 식으로 설계를 하고 있고, 반면에 Codex는 저를 잘 믿지 않아요. 듣다 보면 느끼는 게, 내가 정답을 알고 있으니 너는 이걸 믿어라 식이고, 그게 두 회사의 철학이 묻어 나오는 것 같다는 생각도 해요.

Claude Code는 보시면 발전해 오는 게, 예를 들면 뭔가 선택이 필요할 때 4지 선다, 3지 선다를 만들거나, 객관식으로 만들어 주는 장치도 만들어서 제공을 하고 있고, 최근에는 아예 다음에 내가 할 질문을 미리 완성형 형태로 제안을 해 준다거나 하는 걸 하잖아요. 탭만 누르면 다음 질문이 나올 수 있도록.

그런 식으로 저의 의사를 더 많이 물어보고, align을 맞춰 나가는, 사람이 애매하게 가지고 있는 컨텍스트를 조금 더 명확하게 파악을 해서 그 방향으로 동작을 하고자 하는 식으로 진화를 하고 있고, Codex는, 대충 설명하면 내가 다 알아서 해줄게로 진화를 하고 있습니다. 그리고 실제로 그렇게 잘해요.

최고치가 어디가 더 높냐고 하면, 저는 100% Codex가 최고치가 더 높아요. 근데 사람이 편안하게 느끼는 거는 Claude Code죠. 왜냐하면 Claude Code는 그 과정 자체를 저랑 같이 하니까.

제가 어린 시절 유행했던 애니메이션이 있는데 그게 사이버 포뮬러라고 있었거든요. 레이싱인데 AI랑 같이 레이싱하는 주인공이 있고요. 그 AI가 처음에 바보 같고, 운전도 잘 못하고 이러는데 주인공도 얘한테 의존을 해서 운전을 배우게 되고, 얘도 그 과정에서 사람이 실수를 하는 거에서 힌트를 얻어서, 새로운 방법들을 만들거나 해서 같이 공진화를 합니다.

각 시리즈마다 해결하는 문제들이 달라요. 인간이랑 AI가 공진화를 한다는 개념에서 예를 들면 사람으로서 훨씬 더 나은 운전자를 어떻게 이기는가가 있었고, 그다음에 사람이 경험하지 못한 영역에 들어갔을 때 그걸 AI가 어떻게 보조를 해서 해결을 하는가가 있었고, 그다음에 완전히 AI로 대체가 돼서, AI가 운전을 하는 상대랑은 어떻게 이기는가 이런 식으로 테마가 이동을 하다가, 제일 마지막 것만 주인공이 바뀌거든요.

차를 하나 누가 빌려주는데, 아까 전 시리즈에서 사람한테 약을 먹이고 AI한테 완전히 운전을 시켰던 자동차를 만들었던 사람이 자기 형이 만들었던 자동차라고 자동차를 하나 줍니다. 이걸로 하라고. AI가 시키는 대로 운전만 하도록 원래 모델은 아예 사람을 안 믿어요.

사람은 운전 당연히 못하는 존재다, 그래서 AI가 운전을 당연히 잘하지, 이래서 이때쯤이면 사람이 이렇게 해줘야 되겠지라고 판단을 하고 조작을 하는데, 사람은 그 동작을 못 따라가니까 자꾸 사고가 나는 거예요. 근데 주인공이 바뀐 주인공이죠. 그 차를 타고 엄청 고생을 하다가 마지막에 이기거든요.

그 주인공은 AI를 따라갈 수 있을 정도의 능력이 있었던 거고, AI는 이기고 싶어서, 미래는 모르겠고 일단 난 이기고 봐야겠다라고 해서 어떻게 보면 호승심이 생긴 AI라고 하면 되겠습니다.

그전까지는 우리가 목적을 가진 AI를 얘기했는데, 제가 그 시리즈를 옛날에 보고 느꼈던 생각들이 요새 자주 나요. 호승심을 가진 AI라는 게 뭘까. 보통 AI한테 없는 게 의지거든요.

우리가 어떤 agentic coding을 할 때 사람의 역할은 어떤 방향으로 뭘 해야 될지 지시를 하는 거잖아요. 그럼 그걸 충실하게, 무식하게 잘합니다. 근데 왜 그걸 충실하고 무식하고 컨텍스트를 이해하지 못한 채로 이상한 짓을 가끔 하는가 하면 그 에이전트에게는 명확한 목적 의식이 없기 때문이거든요.

근데 그 애니메이션에서는 목적의식을 가지게 된 AI가 사람을 잘 만나면 그 AI랑 공진화한 사람을 이길 수 있다라는 결론이라서 그게 최근에 많이 생각이 나요. 특히 Codex를 보면.

1:11:41 노정석 그러면 그 맨 마지막에 이긴 그 차가 Codex인 거죠. 그리고 원래 있었던 게 Claude Code, 이렇게 비유하신 거죠.

1:11:48 신정규 양쪽 다 서로 다른 방향으로 진화를 한 거긴 하지만, 원래 옛날 주인공이 타던 “아스라다”란 자동차는 계속 같이 진화를 해내고, 하늘에서 뚝 떨어져서 자기가 최고의 주행을 할 수 있다고 생각을 하고 사람을 이해 못하는 AI는 “오가”라는 자동차인데, 얘는 Codex 동작이랑 비슷한 느낌을 주죠.

어떻게 보면 AI를 만들거나 이런 장치를 만드는 사람들의 철학이라거나, 설계 사상이 조금 들어있는 거기도 하고, 그런 것들조차도 우리가 거의 100년 동안 쌓아온 SF라거나, 다양한 종류의 매체, 문학, 애니메이션, 영화, 이런 것들에서 여러 번 다루어지고 있는 게 재밌다, 이런 생각을 했습니다.

1:12:29 노정석 논리적으로 생각해도, 그 시뮬레이션이 어떤 확률이 높은 미래처럼 느껴졌을 것 같아요. 작가 입장에서, 수많은 토론과 생각 실험 끝에 그런 시나리오를 잡았을 거잖아요. 많이 영화나 만화나 이런 것들도 저희가 생각하는 미래의 방향과 비슷한 것도 재밌는 것 같고요.

AI 시대 스타트업의 기회와 물레방아론 1:12:47

1:12:47 노정석 질문을 한두 개만 더 드리고 마무리해야 될 것 같은데, 담담하게 아까 말씀을 주시긴 했는데, Lablup이 10년 동안 쌓아온 어떤 축적의 시간과 그런 자산들이 몇 개 암묵지만 의미 있어졌고, 나머지는 딸깍이 되는 정도가 됐다라는 게 재밌기도 하지만, 회사로서 슬픈 현실이기도 하잖아요.

1:13:08 신정규 저는 슬프다는 생각은 잘 안 들고요. 회사로서는 별로 슬프지 않은 것 같아요. 사람으로서는 좀 슬프죠. 예를 들면 창업을 했다. 내가 이 정도의 노력을 했다. 그런 상황에서, 옛날에는 그렇게 힘들었는데 지금 너무 쉽네. 그게 텍스트 큐브 만들다가 Backend.AI:GO를 만들 때 느꼈던 그런 기분이 있는 것이고, 회사로서는 이걸 어떻게 받아들여야 되느냐고 하면 회사로서는 오케이, 땡큐의 느낌이라고 전 받아들여져요.

1:13:37 노정석 왜 그럴까요?

1:13:38 신정규 두 가지가 있죠. 하나는 일단 다행히도 저희 회사는 적응이 굉장히 빠른 편이고요. 이렇게 판이 뒤집힐 때는 스타트업들이 훨씬 유리합니다. 스타트업이기도 하고 그게 장점이죠. 우리가 쌓아온 것만큼 우리가 턴어라운드, 또는 방향 궤도 수정을 더 빨리 할 수 있다는 거. 그리고 거기에 전체가 다 적응을 해 나가는 시간이 다른 곳들보다 빠를 거라는 게, 그게 기회로 새로운 기회로 작동할 수 있다는 게 하나고요.

스타트업 입장에서는 시장이 안정적이고 고정돼 있는 상황이 제일 안 좋습니다. 어떻게든 판이 흔들릴 때가 좋고, 어떻게든 새로운 기회가 나올 때가 좋고. 제가 만일 지금 기득권 입장이라면 어떡하냐고 할 수 있겠지만, 제가 보기에 저희는 아직 가진 게 없어요. 기술밖에 가진 게 없는데, 기술이 leverage 되는 상황을 어떡하냐. 제가 보기엔 저희는 엄청 잘 적응하고 있는 것 같고요.

모델 개발에 대해서도 어마어마하게, 저희 Backend.AI를 위한 모델 개발 같은 것도 엄청나게 하고 있고, 그러다 보니까 이 미래에 필요한 게 무엇인가에 대해서도 더 빨리 만들기 시작을 한 것 같고.

그다음에 두 번째 같은 경우는 브랜드 얘기입니다. 결국 이 판이 흔들린 것은 어느 순간 진정이 되겠죠. 지금까지 모든 게 그렇듯이 가속 구간은 끊임없이 가속할 수 없습니다.

근데 그 미래가 예를 들면 AI가 나한테 기초소득을 주면서 제가 그거만 받아먹고 사는 시대가 아니라 다른 종류의 어떤 상황이 열린다고 하면, 결국엔 그 상황에서 최종적으로 도달해 있는 위치가 이후의 위치랑 거의 비슷해질 가능성이 있거든요.

예를 들면 옷을 볼게요. 지금 화장품 만드시니까, 화장품도 마찬가지지만 중요한 ingredient라거나, 기술적인 혁신이라거나, 이런 것도 있죠. 그렇지만 원가의 측면에서 봤을 때 엄청 차이가 나진 않잖아요. 모든 화장품들이, 모든 옷들이.

예를 들면 제가 핸드백을 산다고 했을 때 이 핸드백이 정말로 저 핸드백보다 천 배의 가치가 있는 핸드백이냐, 아니죠.

명확하게 드러나는 거는 컴퓨터입니다. Apple이 그래도 제일 좋은 컴퓨터라고 하지만 다른 컴퓨터들하고 가격이 10배 20배 차이 나지 않잖아요. 원가가 되게 투명하기 때문에, 그렇기 때문에 결국에는 비슷한 도구들이 많고, 여러 비슷한 일을 한다고 주장하는 도구들도 많아질 수가 있겠지만, 결국에는 다시 브랜드, 그리고 그동안 쌓아온 트랙 레코드가 핵심 경쟁력이 되는 시대가 한 번 더 올 거라고 생각을 해요.

그 부분에 있어서 저희는 오랫동안 여러 가지 면으로 잘 지켜왔다라는 생각을 하고, 그 과정에서 놓치지 않고 적응을 할 수 있으면. 옛날 생각이 나네요. “Brand Yourself”처럼 브랜드가 핵심 경쟁력이 되는 시대가 아마도 안정기에는 다시 올 것이다.

그렇기 때문에 저희는 되게 좋은 기회라고 보고 있고, 하지만 개인적으로는 슬픈 게 맞습니다.

1:16:18 노정석 개인적으로는 슬픈 점, 이 10년을 먼저 경험한 것들, 그다음에 이미 프론티어 모델들이 많이 다 알고 있어서 딸깍 하면 만들어지는 영역도 있지만, 사실은 산전수전을 겪으면서 대표님과 회사가 쌓아온 일종의 암묵지, 남들은 절대 모르는 그런 것들이 해자로 작용하고 있고 남들은 넣지 못하는 컨텍스트로 작용하고 있다라고 보면 될까요?

1:16:44 신정규 기본적으로는 저희 솔루션은 안정적인 하드웨어에서 안정적인 워크로드를 돌리기 위한 솔루션이 아니에요. GPU는 너무나 불안정하고, 네트워크 포함해서, 특히 NVIDIA나 AMD나 이런 최신 엔터프라이즈 GPU로 올수록 불량률도 너무 높고 예상이 안 되는 게 너무 많고. 결국에는 좀 재미있는 구조인 거죠.

불안정한 하드웨어도 안 믿고, 위에서 돌아가는 모델 훈련 소프트웨어도 모든 걸 믿을 수 없는 상태에서 이것들을 믿을 수 있는 상황인 것처럼 운영해 주는 솔루션이기 때문에 결이 다르다고 할 수 있죠. 그게 조금 장점이죠. 그런 건 결국에는 얼마나 많은 edge case를 밟아왔느냐의 핵심 경쟁력이고, 자율주행하고 좀 비슷한 면이 있죠.

1:17:26 노정석 테슬라에서 방금 말씀하셨지만, 테슬라에서 보는 거라든지 아니면 Lablup이 회사 차원에서 겪어온 지난 10년의 일들, 그리고 나서 이 AI에 진입했는데 저희가 다 불안하긴 합니다마는 우리가 쌓아온 것들을 어떻게 우위로 바꾸고 브랜드 자산으로 전환해서 결국은 우리가 이길 수 있을지, 그런 전략 차원에서는 굉장히 좋은 예제가 되는 것 같고요.

그리고 이게 소프트웨어라든지 앞서가는, 적어도 AI의 영향을 제일 많이 받는 인더스트리에서 이런 일이 일어나고 있으니까 똑같은 형태로 다른 산업에도 비슷한 일들이 일어나겠죠. 마치 Claude가 들어와서 법무와 재무, 이런 것들도 끝내는 것처럼.

지금 이야기하고 있는 이 회사의 다이내믹스, 도대체 회사 가치는 어디서 오는가, 이런 것들도 다른 산업으로도 똑같이 퍼져 나가지 않을까라는 생각이 들어요.

스타트업에게 가장 안 좋은 것 - 복제의 시대 1:18:20

1:18:20 최승준 스타트업에게 제일 안 좋은 건 뭐예요?

1:18:23 신정규 스타트업에게 제일 안 좋은 건 정체죠. 일반적으로 현재의 스타트업 말씀이신가요?

1:18:28 최승준 지금 AI 업계나 IT 업계에 포함했을 때, 스타트업에서 브랜드 가치라든가 아니면 경험을 쌓은 것들, 그리고 상황이 흔들리는 것들이 어떻게 보면 위기이자 기회가 될 수 있는 건데, 그렇다면 스타트업에게 안 좋은 건 뭔가라는 궁금증이 생긴 거죠.

1:18:45 신정규 모든 아이템의 복제가 너무 쉽습니다.

1:18:48 노정석 복제되지 않는 게 무엇인가라는 질문에 타이밍적으로라든지 아니면 어떠한 아이템들의 조합이라든지 그런 걸로 답을 하지 못하면 다른 사람들의 딸깍에 휩쓸릴 수 있는 거죠.

1:19:01 신정규 최근에 Facebook에서 어떤 분이 NotebookLM 복제하시는 데 나흘 걸린 거 보고 되게 많은 깨달음이 오더라고요. NotebookLM 모든 화면의 스크린샷 다 뜨고, 기능 설명 쭉 해서 던져주니까 나흘 정도 있으면 클론이 나오더라. 그런 시대라서, 스타트업을 기존의 아이템을 잡던 방식으로 아이템을 잡으면 복제가 너무 쉽습니다. 그게 가장 큰 거기도 하고요. 반대로 복제가 아이템인 회사들은 엄청 잘될 수 있겠죠.

1:19:29 노정석 근데 많은 똑똑한 사람들이 다 남들이 해놓은 걸 빨리 따라가는 쪽으로 better, faster, cheaper 하는 선택들을 하거든요. 근데 그게 자본의 우위라든지 아니면 학교 출신의 우위나 이런 거 가지고 더 좋은 talent를 채용할 수 있다든지, 그런 걸 가지고 이거를 다 제어할 수 있거나 아니면 주인이 될 수 있으면 그게 유의미했는데, 이제는 그런 자원들이 남들이 다 갖고 있는 세상이라서 복제, 복제하는 것만으로는 고객들이 얘가 더 우월하네, 얘가 좀 괜찮네라는 거를 주기 힘든 세상이 된 것 같아요.

무언가 그 이상이 필요합니다. 그 이상에 대해서, 그러면 또 나올 겁니다. 그 이상에 대해서 저희도 이런 것들을 하면서 계속 찾아가고 있잖아요.

제가 현재 찾은 거는 약간의 타임 갭과 암묵지 갭, 이 두 개가 잘 결합돼서 빨리 이 고객들을 잡아가면 물론 누군가의 딸깍에서 없어질 수도 있지만, 딸깍이 안 되는, 한 번 어떤 고객들의 데이터를 볼모로 잡으면 고객들이 딴 데 가기 어려운 것들이 있거든요. 그런 걸로 사업적인 시각을 좀 생각해야 되는 시기인 것 같아요.

1:20:37 최승준 딸깍 저항성, 안티 딸깍, 그런 말이 떠오르네요.

1:20:41 신정규 말씀드리려는 건, 구글 스타트업 캠퍼스라고 있는데 거기서 예전에 강연을 할 때 썼던 표현인데 저는 결국 사업이라는 게 물레방아를 어디다가 설치하느냐의 문제라고 보거든요. 낙차가 큰 곳에 물레방아를 설치해서 물레방아를 빨리 돌리고, 물 떨어질 것 같으면 그걸 잘 옮겨 달거나 다른 방법을 택하거나 하는 건데, 아까 Chester님이 말씀해 주셨던 그런 타임 갭이 제일 많이 발생할 부분은 IT 분야 안에서는 아닌 것 같아요.

IT plus something까지 당연히 늦게 따라올 수밖에 없는데, 기존에는 당연히 이게 IT 영역이 되지 않을 거라고 생각했지만 AI가 context를 해석할 수 있게 되면서 IT의 영역으로 들어오게 될 부분들, 들어오게 될 분야들, 그런 분야들의 물레방아를 다는 스타트업들이 잘 되지 않을까?

1:21:26 노정석 제가 처음 질문드렸잖아요. 저희 애가 군대 마치고 학교에 가는데 도대체 어떤 공부를 시키는 게 지금 가장 안전할까라는 말씀을 드렸었는데, 대표님이 그 얘기하셨거든요.

그 도메인에 있는 사람들이 이러한 AI나 그 시스템에 대한 지식을 배우는 것보다 이 AI 시스템과 이런 것들에 대한 지식이 많은 사람들이 도메인을 배우는 게 훨씬 빠를 거다라는 말씀하셔서, 지금 오히려 역설적이지만 컴퓨터 사이언스, CS 하는 게 좋지 않겠는가라는 말씀을 주셨었는데 그거랑도 살짝 연결돼 있는 말인 것 같아요.

즉, 도메인에 계신 분들은 빨리 CS 배우셔야 되고, CS 계신 분들은 빨리 적용할 수 있는 도메인의 어떤 타임 갭을 찾으시는 게 신 대표님이 말씀하신 물레방아론에 딱 맞지 않을까라는 생각이 들어요.

대표님 그 이야기 더 하실 거 있으시면 내용 좀 해주시죠.

컴퓨터 공학과 무용론에 대한 반론 1:22:19

1:22:19 신정규 컴퓨터 공학과 무용론, 이런 게 가끔 들리는데 제가 보기엔 좀 재미있어서요.

왜냐하면 제가 00학번인데, 제가 컴퓨터 공학, 물리학과이기도 하지만 컴퓨터 공학과 복수 전공을 했었는데 수업을 들어가면 컴퓨터 공학과 출신 교수님들이 별로 없었어요. 왜냐하면 그 윗세대에 컴퓨터 공학과라는 게 없었기 때문에, 컴퓨터 공학과의 교수가 된다는 건 다른 학과에서 컴퓨터를 많이 썼던 분들이 학문을 만들었거든요.

그러다 보니까 화학과 출신도 계셨고, 재료과 출신도 계셨고, 물리과 출신도 계셨고, 컴퓨터 공학과 초기에 만들어진 곳에 교수님들이 오시고, 지금은 대부분이 컴퓨터 공학과라는 단독 학과에서 훈련을 받으신 분들이 교수님들이기도 하죠.

이게 무슨 얘기냐면, 컴퓨터 공학과는 처음 시작할 때부터 방법론적인 사상을 가지고 시작한 부분이 반이고, 컴퓨터 과학, 컴퓨터 공학 이렇게 나누기도 하지만 기본적으로는 굉장히 신생 학문이라는 거죠. 다른 많은 분야들에 비해서는 상대적으로. 그렇기 때문에 저는 변화 속도도 되게 빠를 거라고 보고요.

언제까지 Python 배우는 학과, C 배우는 학과, 아키텍처나 운영체제 개발하는 거 배우는 학과, 이것들은 계속 배우겠죠. 엄청나게 중요하기 때문에 계속 배우겠지만, 저는 이 형태로 계속 가지 않고 예를 들면 뉴로 컴퓨팅이라거나 아니면 모델 개발하는데 그 모델의 핵심이 무엇이고, attention 구조가 무엇이고, 다른 것들을 만들어 보는 게 무엇이고, 이런 것들도 최근에 많이 들어오고 있거든요.

실제로 딥러닝 개론 같은 것들도 수업 커리큘럼에 들어오고 있기 때문에 어떻게 보면 그런 변화에 가장 빨리 적응할 수 있는 학과가 컴퓨터 공학과인 것 같아요. 저는 물리학과임에도 불구하고 그렇게 생각을 하고 있고, 물론 물리학과들이 최근에는 갈 데가 많아져서 좋긴 합니다.

그런 과정에서 사람들이 AI가 다 해주니까 컴퓨터 공학과 안 배우면 되는 거 아니야, 그냥 내가 컴퓨터 AI한테 시키면 더 빨리 할 수 있지 않아라고 하지만 실제로 제 주변에 그런 업계에 계신 분들이 물어보면 반대 방향으로서의 걱정이 더 많긴 해요. 예를 들면 AI가 다 해주기 때문에 내가 할 일이 없어지는 게 아니야, 영화를 찍는 것도 심지어 Seedance가 동영상을 저렇게 만들어 주는데, 영화 감독들은, 영화 촬영 감독들은 뭐 하지, 이런 식의 위기감을 느끼는 거.

그런 식으로 아마 앞으로 한 5년쯤은 IT가, 물론 지금까지도 많이 들어와 있고 사용이 되고 있지만, 어마어마한 규모로 사회 전반의 핵심에 굉장히 많이 들어오는 시대가 될 거라고 생각을 해요.

단기적으로는, 프로그램 배워서 뭐하냐, 프로그램 다 컴퓨터가 짜주는데라고 하지만 컴퓨터 공학과에서 배우는 게 프로그램은 아니거든요. 그 안에 있는 로직을 세우는 방법이죠.

로직을 만들고, 가장 단순한 게이트 로직이 어떻게 발전해서 수많은 로직들로 발전을 할 수 있는지, 그 방법론이나 철학이라고 해야 될까요? 그런 사고 구조를 배우는 거에 더 가깝다고 저는 생각을 하기 때문에, 그런 분들이 다른 분야를 배우는 것도 빠를 수 있다. 특히 지식을 외주화할 수 있는 시대가 된 상황에서는 더욱 그럴 수 있다라는 생각을 하고 있습니다.

1:25:19 노정석 저희가 이렇게 말씀을 드리지만 여기에 사족을 꼭 달아놔야 되는 게, 2개월 후에는 바뀔 수 있습니다. disclaimer를 꼭 달아두도록 하겠습니다.

마무리 인사 1:25:29

1:25:29 신정규 모두 손에 손잡고, AI랑 잘 해야 되는 상황입니다.

1:25:33 노정석 미래를 향해 가지만, 저희는 설 연휴고 가족들과 함께 보내야 되는 시간으로 돌아가야 될 것 같습니다.

1:25:40 최승준 긴 시간이었지만 재밌었습니다.

1:25:41 노정석 오늘도 많이 배웠습니다. 자, 그러면 연휴 잘 보내시고요. 저희 또 서울 오시면 또 뵙겠습니다.

1:25:48 신정규 남은 연휴 동안 즐거운 삽질 되십시오.