AI Frontier EP86: 진짜 내 일을 위한 Agentic Workflow
Lablup 신정규 대표 × 노정석 × 최승준
원본 영상: https://www.youtube.com/watch?v=EQ-Rnx-k-Ec
블로그 포스트: https://aifrontier.kr/ko/episodes/ep86
녹화일: 2026년 2월 15일 (일)
정리일: 2026-02-23
목차
- Backend.AI:GO 제품 소개
- 탄생 배경 — 크리스마스 이브의 시작
- 개발 과정 — 40일, 130억 토큰, 100만 줄의 코드
- 에이전트 코딩의 핵심 교훈 — 토큰 경쟁력과 고속 Inference
- 바이오 토큰 — 인간의 인지 부하와 도파민 함정
- 소프트웨어 과잉 시대와 인스턴트 앱의 등장
- 소프트웨어 역사로 본 세 번째 대변혁
- 코드의 가치는 0으로 수렴하는가
- Claude Code의 진짜 경쟁력은 Harness다
- 컴퓨터 공학의 미래 — 역사의 뒤안길인가, 재정의인가
- 에이전트 코딩 실전 워크플로우 데모
- Backend.AI:GO 자동화 개발 파이프라인
- 비개발 직군의 AI 적응 — CFO와 콘텐츠 담당자 사례
- Lablup의 핵심 가치는 어디로 이동했는가
- 사이버 포뮬러 비유 — Claude Code vs Codex의 철학 차이
- AI 시대 스타트업의 기회 — 물레방아론
- 컴퓨터 공학과 무용론에 대한 반론
- 핵심 인사이트 요약
1. Backend.AI:GO 제품 소개
1.1 배경: Continuum 라우터에서 출발
Lablup은 10년 넘게 Backend.AI라는 AI 인프라 운영 체계를 개발해 왔다. 이 플랫폼은 GPU 100~1,000개 단위로 운영하는 대규모 엔터프라이즈를 대상으로 하기 때문에, 일반 개인 사용자가 접근하기 어렵다는 한계가 있었다.
2024년 하반기, 신정규 대표는 재해 대응(DR, Disaster Recovery) 시나리오에 주목했다. 병원이나 금융기관이 클라우드 AI를 사용하다가 클라우드 장애가 발생했을 때, 마치 건물 지하에 비상 발전기를 두듯 로컬 GPU 머신을 활용해 자체적으로 AI를 운영할 수 있어야 한다는 문제 의식이었다.
이를 해결하기 위해 만든 것이 Continuum 라우터다. 2025년 3월 NVIDIA GTC에서 처음 공개했으며, 주요 기능은 다음과 같다.
- Smart Routing: 여러 AI 모델 엔드포인트 간 지능형 라우팅
- Circuit Breaking: 특정 모델/엔드포인트에 장애가 발생하면 자동으로 대체 모델로 전환
- Converter: 다양한 API 포맷 간 변환 지원
- 통계 및 벤치마킹: 모델별 지연 시간, 처리 속도 비교
그런데 개발을 거듭하면서 컴포넌트가 19개로 늘어나, 설치 시 OpenRouter 수준의 서비스 스택이 만들어질 정도로 덩치가 커져 버렸다. “서비스 스택이지 엔터프라이즈 솔루션이 아니다”는 판단 하에, 2024년 8월부터 핵심인 라우팅 부분만 발라내어 처음부터 다시 만들기 시작했다.
1.2 주요 기능 및 특징
Backend.AI:GO는 Continuum 라우터의 핵심 기능에 사용자 친화적인 웹 UI를 결합한 제품이다. 주요 기능을 서술하면 다음과 같다.
로컬 모델 관리: Hugging Face에서 모델을 검색하여 다운로드하고, llama.cpp 기반으로 자동 실행한다. 모델 아키텍처(양자화 수준, KV 캐시 크기, Transformer 블록 구조 등)를 시각적으로 설명해 주는 기능도 내장되어 있다. NVIDIA/AMD GPU가 있으면 해당 엔진을 설치해 GPU 가속도 가능하다.
클라우드 모델 통합: OpenAI, Anthropic, Google Gemini 등의 클라우드 모델과 로컬에서 실행 중인 Ollama, LM Studio를 한 인터페이스에서 모두 연결할 수 있다. 전체 모델 세트 175개 중 원하는 것을 체크하면 라우터 리스트에 등록된다.
분산 컴퓨팅: 사무실의 여러 PC에 설치된 Backend.AI:GO를 묶어 분산 운영이 가능하다. 예를 들어 8명의 팀이라면 각 PC의 유휴 GPU를 풀(pool)로 묶어, 이미지 생성·텍스트 처리·PDF 변환 등을 각 PC에 분산하고 결과를 공유할 수 있다.
번역기: DeepL 구독료 절감을 목적으로 직접 내장했다. PDF, TXT, DOCX 파일 전체를 원본 포맷을 유지하며 번역하고, 이미지 입력도 지원한다. (참고: 시연 중 “Lablup”을 “rabble up”으로 번역하는 재미있는 결과도 소개됨)
이미지 생성: 클라우드/로컬 이미지 생성 모델을 통해 이미지를 직접 생성할 수 있다.
통계 및 벤치마킹: 모델별 지연 시간, 처리 속도를 대시보드로 확인하고 두 모델을 직접 비교할 수 있다.
다양한 테마: 디폴트 테마 외에 macOS 글래스 테마, 그리고 “토큰이 남아서” 만들어진 실험적 테마 등이 포함되어 있다.
2. 탄생 배경 — 크리스마스 이브의 시작
Backend.AI:GO의 직접적인 출발점은 2025년 12월 24일, Anthropic의 홀리데이 시즌 ‘토큰 2배 이벤트’였다. 신정규 대표는 “여분의 토큰이 생겼으니 뭔가 더 해보자”는 생각에서 웹 UI 개발에 착수했다.
원래는 Continuum 라우터에 단순한 웹 UI를 붙이는 것이 목적이었다. 그런데 라우팅 대상이 필요해 llama.cpp를 연동하다 보니 자동화 레이어가 생겼고, DeepL 구독료가 아까워지자 번역기가 붙었으며, 이미지 생성 수요가 늘면서 해당 기능도 추가됐다. “필요해서 붙이다가 커진” 제품이다.
내부에 공유한 순간, 팀원들의 반응이 뜨거웠다. “이게 단순한 웹 UI가 아니라 Lablup을 홍보해 줄 수 있는 제품”이라는 평가를 받아 정식 제품화를 결정했고, 이름도 Backend.AI:GO로 정해졌다.
2026년 1월 6일 미국 CES에서 첫 공개 데모를 가졌으며, 이것이 MVP 버전(v0.9 수준)이었다. 이후 팀원들이 이슈 트래커에 등록한 기능/버그가 자동화 파이프라인을 통해 개발되면서, 인터뷰 시점 기준으로 v1.1까지 완성도가 크게 높아졌다.
3. 개발 과정 — 40일, 130억 토큰, 100만 줄의 코드
3.1 규모와 수치
| 항목 | 수치 |
|---|---|
| 개발 기간 | 40일 (2025.12.24 ~ 2026.02.01 전후) |
| 총 생성 코드 | 약 100만 줄 |
| 삭제 포함 총 작성 라인 | 약 120만 줄 |
| 사용 토큰 | 약 130억 토큰 |
| 투입 머신 | 8개 PC/VM |
| 주요 도구 | Claude Code Max (2개 기본, 부족 시 추가 과금) |
3.2 비교 수치의 상징성
신정규 대표가 과거 TextCube 프로젝트에서 3년에 걸쳐 작성한 코드가 총 100만 줄 수준이었다. Backend.AI:GO에서는 동일한 분량을 40일에 만들어냈다. 단순 산술로 개발 속도가 약 27배 향상된 셈이다.
3.3 개발 흐름의 진화
초기에는 신 대표가 직접 Claude Code와 상호작용하며 코드를 짰지만, 점차 다음과 같은 자동화 파이프라인으로 발전했다.
- 팀원들이 GitHub 이슈 트래커에 버그 및 기능 요청을 등록한다.
- cron 잡(15분 주기)이 새로운 이슈를 감지하여 Claude Code를 실행한다.
- Claude Code가 이슈를 분석하고 구현 계획(ground plan)을 수립한 뒤 작업 큐에 넣는다.
- 별도의 Claude Code 인스턴스가 큐에서 작업을 가져와 개발을 진행한다.
- 자동화된 테스트를 통과하면 Pull Request가 생성되고 merge된다.
- 각 이슈 처리 결과를 사람이 읽기 좋은 tech report 형식으로 정리한다.
이 방식으로 인터뷰 시점까지 764개의 PR이 처리됐다. 신 대표가 커피숍에서 2시간 간담회를 하는 동안 22개의 PR이 자동으로 merge됐다고도 했다.
4. 에이전트 코딩의 핵심 교훈 — 토큰 경쟁력과 고속 Inference
4.1 토큰 사용량이 곧 IT 회사의 경쟁력
Anthropic의 토큰 2배 이벤트가 프로젝트의 직접적 계기가 됐다는 점에서 도출된 첫 번째 교훈이다.
“토큰을 사용할 수 있는 양이 IT 회사의 경쟁력과 직결된다.”
충분한 토큰을 확보한 팀은 더 많은 iteration을 돌릴 수 있고, 그것이 제품의 완성도와 개발 속도로 직결된다.
4.2 병목(Bottleneck)의 변화
에이전트 코딩이 성숙하면서 병목 지점이 단계적으로 이동해 왔다.
- 6개월 전: merge queue가 병목이었다. AI들이 같은 소스에서 충돌을 일으켰다.
- 현재: merge queue는 더 이상 병목이 아니다. AI 두 개가 같은 소스에서 경합해도 최종적으로 기능이 정상 개발된다.
- 현재의 병목: 토큰 생성 속도 자체, 그리고 thinking 비용.
4.3 두 가지 속도 해법
AI 코딩 속도를 높이는 방법은 두 갈래로 나뉜다.
첫째, 토큰을 덜 생성하고 같은 결과를 내는 것이다. 모델들이 성능 향상을 위해 thinking token(내부 추론 토큰)을 늘리는 방향으로 진화하고 있는데, 이는 결과물의 질을 높이는 동시에 속도를 낮추는 trade-off를 만든다. 따라서 작업의 난이도에 따라 thinking budget을 동적으로 조절하는 Adaptive Thinking Budget 전략이 필요하다. 단순 코딩 작업에는 thinking을 줄이고, 고난도 설계 작업에만 많은 thinking을 허용하는 방식이다.
둘째, 토큰 생성 자체를 극도로 빠르게 하는 것이다. 일반적인 ChatGPT 수준의 코드 생성 속도가 아닌, 5~10배 빠른 초고속 inference가 필요하다. 에이전트 코딩 환경에서는 사람이 결과물을 기다리는 시간이 iteration 주기를 결정하기 때문이다. OpenAI의 Codex Spark 서비스 출시 역시 같은 방향을 바라보고 있다는 점을 신 대표는 주목했다.
5. 바이오 토큰 — 인간의 인지 부하와 도파민 함정
5.1 AI를 쓸수록 사람이 늙는다
신정규 대표는 이 프로젝트를 통해 역설적인 경험을 했다고 솔직하게 밝혔다.
“40일을 만들었지만 3년 치 늙은 것 같다.”
아무리 AI에게 작업을 위임해도 인지 부하는 줄어들지 않는다. 오히려 끊임없이 들어오는 피드백과 결정 요청이 사람을 지치게 만든다. 한창 개발이 활발했던 시기에는 Claude Code의 5시간 토큰 리필을 기다리며 3시간 반만 자고 1시간 반 쉬는 생활이 반복됐다.
5.2 가챠 게임과 도파민
에이전트 코딩이 주는 경험은 모바일 가챠 게임과 유사하다. 내가 이전에는 도달하지 못했던 것을 빠르게 달성할 수 있다는 만족감, 그리고 즉각적인 피드백이 도파민을 자극한다. 이 흥분 상태가 더 많은 작업으로 이어지고, 그것이 또 성과를 내는 선순환이 반복된다.
그러나 이 구조에는 두 가지 위험이 있다.
하나는 삶이 AI에 지나치게 의존적이 되어 피폐해진다는 것이다. 흰머리가 늘고 수면이 줄어드는 것이 그 증거다.
다른 하나는 도파민이 끊어지면 제품도 함께 죽는다는 것이다. 이로 인해 관리되지 않고 버려지는 AI-generated 소프트웨어가 폭발적으로 늘어날 것이라고 전망했다.
5.3 바이오 토큰이란
AI가 작업하는 동안 사람이 기다리는 시간, 즉 인간의 인지와 시간 자원을 바이오 토큰(Bio Token) 으로 표현하는 시각이 부상하고 있다. AI의 토큰 소비를 줄여 속도를 높이면 사람의 바이오 토큰도 절약된다. 반대로 AI가 느릴수록 사람이 생각할 시간이 생기는데, 신 대표는 그 기다림 속에서 AI가 아닌 자신에 대한 성찰의 시간이 생겼다고 말했다.
6. 소프트웨어 과잉 시대와 인스턴트 앱의 등장
6.1 소프트웨어의 과잉 공급
진입 장벽이 낮아지면서 소프트웨어는 폭발적으로 증가하지만, 각 소프트웨어의 유지 동기는 반비례로 줄어든다. 기존에는 소프트웨어를 만드는 데 든 노력과 시간이 유지에 대한 강한 동기로 작용했다. AI로 빠르게 만들면 그 애착이 약해지고, AI에게 관리를 맡기면 되므로 결국 비슷한 제품이 무수히 많아지는 현상이 발생한다.
블로그 시대와의 유사성을 지적했다. 블로그 댓글이 Twitter(X)로 이동하면서 블로거들이 글쓰기를 중단한 것처럼, 특정 오픈소스 프로젝트로 커뮤니티가 집중되는 현상이 약화되고 관리되지 않는 오픈소스가 넘쳐날 것이라는 전망이다.
6.2 인스턴트 앱의 등장
이 환경에서 두 가지 유형의 소프트웨어가 남을 것이라고 예측했다.
첫째는 인스턴트 앱이다. 필요할 때 즉석에서 만들고, 자주 쓰면 저장하는 방식으로, Google 같은 플랫폼이 이를 인프라 차원에서 지원하게 될 것이다. 재사용성보다는 즉각성이 핵심이다.
둘째는 브랜드와 트랙 레코드가 확립된 장수 소프트웨어다. 사람들이 특정 소프트웨어를 쓰는 이유는 단순히 기능 때문이 아니라 “이 소프트웨어는 쉽게 망하지 않을 것”이라는 신뢰 때문이다. 스마트폰 앱에서 상위 10개 앱이 전체 사용량의 90% 이상을 차지하는 현상, 그리고 Obsidian이나 DEVONthink처럼 오래된 앱이 살아남는 현상이 이를 증명한다.
6.3 SaaS 시장의 재편
SaaS 시장도 재편될 것이다. Lablup의 Revenue Officer가 이틀 만에 Salesforce를 직접 클론 제작한 사례처럼, 기술적으로는 누구나 SaaS를 복제할 수 있다. 그러나 “어차피 빠른 속도로 다른 일도 처리할 수 있으니, 직접 만들지 않아도 되는 일은 안 하는 것이 맞다”는 논리로 기존 SaaS 소비도 일부 지속된다. 다만 지금 잘나가는 SaaS가 1년 후에도 같은 위치에 있을지는 미지수다.
7. 소프트웨어 역사로 본 세 번째 대변혁
신정규 대표는 현재를 소프트웨어 역사의 세 번째 대변혁으로 규정했다.
| 시기 | 변화 | 핵심 전환 |
|---|---|---|
| 1차 | 천공 카드 → 키보드 코딩 | 입력 방식의 전환 |
| 2차 | 패키지 소프트웨어 → 웹/모바일 서비스 | 배포·운영 방식의 전환, DevOps·백엔드/프론트엔드 직종 분화 |
| 3차 (현재) | 키보드 코딩 → 의미 전달(자연어/에이전트) | 소프트웨어의 정의 자체가 변화 |
기존 소프트웨어 개발의 구조는 코드 작성이 70~80%, 서비스 스택 구현이 20~30%였다. 앞으로 이 구조는 AI 코어 모델 80% + 결정론적 제어 레이어 10% + 사람/AI 간 인터페이스(UI/UX, A2A, MCP) 10% 로 재편될 것이라는 전망이다.
아폴로 계획과의 비유도 인상적이었다. 지금 AI 발전의 가속도는 아폴로 이전 시대, 즉 우주인을 지구 궤도에 올리는 데 성공한 ‘머큐리 계획’ 단계에 비견된다. 달 착륙에 해당하는 진정한 변곡점은 아직 오지 않았으며, 그것이 오고 나면 우리가 지금 상상하지 못하는 수준의 변화가 올 것이라는 시각이다.
8. 코드의 가치는 0으로 수렴하는가
이 질문에 대한 신 대표의 답변은 미묘하게 균형 잡혀 있다.
코드(텍스트로서의 소스코드) 자체의 가치는 0에 수렴할 수 있다. 2시간 간담회 중 22개 PR이 자동 merge되는 세상에서, 코드를 작성하는 행위 자체의 경제적 가치는 급격히 하락한다.
그러나 소프트웨어(로직과 서비스를 구현하는 체계) 자체는 사라지지 않는다. 코드는 목적이 아니라 수단이었다. 로직을 처리하는 방법이 손으로 쓰는 코드에서 딥러닝 모델로 전환될 뿐이다. 마치 OMR 카드 마킹에서 키보드 코딩으로 넘어왔듯, 소프트웨어의 정의가 바뀌는 것이다.
따라서 개발자에게 위협이 되는 것은 “소프트웨어가 위험해진 것”이 아니라 “소프트웨어를 정의하는 방법이 바뀐 것”이다. 변화에 적응하지 못하는 개발자는 어려움을 겪겠지만, 이 변화를 이해하고 활용하는 개발자는 오히려 더 중요해진다.
9. Claude Code의 진짜 경쟁력은 Harness다
신정규 대표는 Claude Code, Gemini CLI, Codex, GitHub Copilot 등을 모두 실전에서 사용해 본 결과, 놀라운 결론에 도달했다.
“Claude Code의 핵심 경쟁력은 Opus나 Sonnet 엔진이 아닙니다. Claude Code 그 자체(harness)입니다.”
Backend.AI:GO를 라우터로 활용해 Claude Code의 백엔드 모델을 Gemini 2.0 Pro로 바꿔서 돌렸을 때, 기대 이상의 성능을 발휘했다고 한다. 이는 Claude Code가 단순히 “Claude 모델을 호출하는 UI”가 아니라, 모델 주변에서 결정론적 워크플로우를 구성하는 소프트웨어 레이어로서 독립적인 가치를 가짐을 의미한다.
이 harness가 하는 일을 정리하면 다음과 같다.
- 파일 시스템 탐색 및 조작을 적절한 시점에 수행
- 에러 발생 시 자동 재시도 및 디버깅
- 사용자 의도를 맥락으로 파악하여 next-action을 제안
- 툴 콜(tool call)을 모델이 올바르게 사용하도록 orchestration
10. 컴퓨터 공학의 미래 — 역사의 뒤안길인가, 재정의인가
10.1 가속도의 가속
현재의 AI 발전은 단순히 빠른 것이 아니라, 가속도 자체가 증가하는 구간에 있다. 연산량은 해마다 10배씩 증가했지만 물리적 한계에 다가가고 있고, 그 대신 inference 최적화, agent swarm 병렬화 등으로 가속 곡선을 유지하는 영역이 이동하고 있다.
10.2 Stanford CS의 변화
Stanford CS 커리큘럼이 이를 잘 반영하고 있다. 3~4년 전 대학원 수준이었던 내용이 이제 학부 2학년 과목이 됐다. CS 학과의 커리큘럼이 빠르게 변화하며, PyTorch로 직접 코딩하는 과목이 사라지는 추세다.
10.3 영문과 비유
컴퓨터 사이언스(CS)가 과거 ‘영문과’와 비슷한 위치로 이동하고 있다는 비유가 인상적이다.
영문과는 영어를 통해 압도적인 경제적 이점을 제공하던 시절에 최고의 취업 학과였다. 영어가 보편화되면서 영문과의 독보적 지위는 사라졌지만, 언어·문학·커뮤니케이션의 본질적 가치는 유지됐다.
마찬가지로 CS는 “코딩 기술”이라는 좁은 도구적 가치에서, “사회가 어떻게 구성되는지를 이해하는 학문”으로 재정의될 것이다. 이 의미에서 CS의 중요성은 오히려 높아진다.
11. 에이전트 코딩 실전 워크플로우 데모
11.1 핵심 철학: 결과물이 아닌 생성 장치를 만든다
신 대표의 접근 방식은 단순히 AI에게 결과물을 요청하는 것이 아니다. “결과물을 만드는 장치를 만드는 것” 이 목표다. 이를 코딩에 비유하면, “프로그래밍 언어 대신 말로 코딩하는데, 코딩의 최종 목적지가 아니라 코딩을 하는 주체(에이전트)를 만드는 것”이다.
11.2 워크플로우 단계
1단계 — 컨텍스트 빌딩 (선문답 단계)
한 번에 지시를 넣지 않고, 먼저 AI에게 조사와 탐색을 시킨다. 예를 들어 뉴스레터 발송 자동화 시스템을 만들기 전에, AI에게 유튜브 채널을 탐색하고 어떤 내용을 다루는지 파악하게 한다. 이 과정에서 AI의 컨텍스트 메모리에 필요한 배경 지식이 쌓인다.
2단계 — Soul Document (CLAUDE.md) 작성
컨텍스트가 구성되면, 이 내용을 바탕으로 프로젝트의 핵심 문서인 CLAUDE.md를 작성하게 한다. 신 대표는 이것을 “soul document”라고 부른다. 이 파일에는 다음이 포함된다.
- 디렉토리 구조
- 에이전트가 항상 수행해야 할 동작 정의
- PROGRESS.md 및 PLAN.md 관리 방법 (작업 진행 상황 추적)
3단계 — 아이디어 수집 (만들기 전에 아이디어부터)
직접 만들라고 시키지 않는다. 먼저 “이런 일을 할 때 필요한 command, skill, agent는 무엇이 있을지 아이디어를 알려달라”고 요청한다. 그 후 Claude Code의 .claude 디렉토리 구조에 맞는 정확한 포맷으로 생성하도록 지시한다.
4단계 — 정확한 포맷으로 생성
Claude Code slash command는 앞부분이 YAML, 뒷부분이 Markdown인 특수한 포맷을 사용한다. 이를 AI에게 조사하게 한 뒤, 정확한 스펙에 맞게 생성하도록 지시한다.
5단계 — 캐시 구축
반복적으로 웹에서 조사하는 비용을 줄이기 위해, 조사한 내용을 reference 디렉토리에 저장하고 이후 에이전트가 재사용하도록 설정한다.
6단계 — 비판과 개선 (갈구기)
초안이 완성된 후 30분 중 마지막 20분은 “여러 각도에서의 비판을 스스로 시키는” 데 사용한다. 최종 결과물에 직접 손을 대지 않고, 결과물을 만드는 장치(에이전트)를 계속 iteration하는 것이 원칙이다.
11.3 입력 언어와 존댓말에 관한 팁
신 대표는 이전에는 영어로 프롬프트를 작성했지만, 가을 이후 한국어로 전환했다. 이유는 두 가지다. 첫째, 한국어와 영어 간 품질 차이가 크지 않다. 둘째, 영어를 직접 타이핑하는 시간이 병목이었다. 현재는 Mac의 마이크 버튼으로 음성 입력을 활용한다. 단, skill이나 command 파일 자체는 영어로 생성하게 한다.
존댓말 사용에 대해서는 실용적인 이유를 제시했다. AI 사용 시간이 하루의 절반을 넘다 보니 말투가 무의식적으로 섞일 수 있어, AI에게도 존댓말을 쓰는 습관을 유지함으로써 사람에게도 항상 존댓말을 유지한다.
12. Backend.AI:GO 자동화 개발 파이프라인
12.1 전체 구조
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
GitHub Issue Tracker
↓
Cron Job (15분 주기)
└─ claude -p [이슈 감지 명령어]
↓
이슈 검증 에이전트
└─ 현재 코드베이스 분석 → Ground Plan 수립 → 작업 큐 등록
↓
개발 에이전트 (병렬 실행 가능)
└─ 구현 → 자동 테스트 → Pull Request 생성
↓
검증 에이전트
└─ 테스트 통과 확인 → Merge 승인
↓
Tech Report 생성
└─ 신 대표에게 보고 + 학습 과제 제시
12.2 Tech Report 기능
각 이슈가 해결되면 사람이 읽기 쉬운 tech report가 자동 생성된다. 보고 내용은 다음과 같다.
- 문제 요약 및 해결 방법
- 보안 평가 결과
- 성능 측정 결과
- 코드 품질 평가
- 기술적 결정 사항 요약
- 신 대표가 이 작업을 이해하기 위해 공부해야 할 내용 제안
마지막 항목이 특히 인상적이다. AI가 자동으로 코드를 작성하지만, 사람은 그 기술적 결정을 이해해야 한다. AI가 알아서 학습 과제를 제시해 주는 구조다.
12.3 자동화된 이슈 생성 — AI가 스스로 개선점을 찾다
단순히 사람이 올린 이슈를 처리하는 것을 넘어, AI가 스스로 이슈를 생성하는 단계까지 발전했다.
모든 화면의 스크린샷을 자동으로 캡처하는 기능을 추가한 뒤, AI가 자신이 만든 화면을 직접 보고 개선 가능한 항목을 분석하여 sub-issue를 발행하는 방식이다. 결국 신 대표의 GitHub 아이디로 등록된 이슈 대부분이 실제로는 AI가 자동 생성한 것이다.
12.4 Sub Agent와 병렬 작업
단일 에이전트의 한계를 극복하기 위해 sub agent를 병렬로 운영한다. 주요 원칙은 다음과 같다.
- Sub agent는 다른 sub agent를 직접 호출할 수 없다 (무한 루프 방지를 위해 2025년 초중반에 제한됨).
- Command를 통해 여러 sub agent를 병렬 실행하거나 체이닝할 수 있다.
- 문서 번역 같은 반복 작업은 에이전트당 4개 문서씩 담당하도록 제한한다 (context 폭발 방지).
- 100개 문서를 번역할 경우 25개 에이전트가 동시에 실행된다.
- 최대 50개 sub agent를 동시에 운영한 경험이 있다.
13. 비개발 직군의 AI 적응 — CFO와 콘텐츠 담당자 사례
13.1 CFO의 전환
Lablup의 CFO가 특정 문서 작업을 2시간 동안 직접 하고 있다가, 같은 작업을 신정규 대표에게 맡기면 3분 만에 완료되는 것을 목격했다. “나는 왜 이걸 2시간 하고 있었나”라는 자각이 계기가 됐다.
30분간 Claude Code 사용법을 배운 뒤, 본인이 직접 3분 안에 작업을 처리할 수 있게 됐다. 이후 회사의 연간 사업 계획서 작성에도 Claude Code를 활용한다. 참고 문서 250개 이상을 마크다운으로 변환해 투입하고, 최신 뉴스를 크롤링하여 예측의 정합성을 검토하는 방식이다. 코딩을 하지 못하지만 sync 같은 커맨드를 통해 GitHub에 commit도 한다.
13.2 콘텐츠 담당자의 전환
수많은 마케팅 자료와 기술 자료를 생산해야 하는 콘텐츠 담당자도 처음에는 어려움을 호소했다. 그러나 30분의 학습 후 일주일도 안 되어 자신만의 방대한 harness를 구축했다. GitHub을 직접 다루지는 못하지만, GitHub을 조작해 주는 커맨드를 만들어 간접적으로 활용한다.
13.3 적응의 핵심 원리
두 사례의 공통점은 남이 만들어 놓은 skill을 다운로드해서 쓰는 것이 아니라, 자신의 업무를 줄이는 자신만의 도구를 만드는 것에서 가속이 시작됐다는 점이다.
“기본적으로 이 가속 구간에 올라타려면 내 일이 줄어드는 것이 핵심이다. 남이 만든 것을 복사하는 것이 아니라, 내 걸 만드는 것에서 가속이 시작된다.”
14. Lablup의 핵심 가치는 어디로 이동했는가
14.1 10년 자산의 재평가
솔직한 고백이 인상적이었다. Lablup이 10년간 쌓아온 기술 자산 상당 부분이 AI의 “딸깍” 한 번으로 복제 가능한 영역에 들어오게 됐다. “사람으로서는 슬프지만 회사로서는 괜찮다”는 이중적 감정을 솔직하게 밝혔다.
14.2 스타트업에게 유리한 이유
가장 큰 강점은 방향 전환의 속도다. 기존에 쌓아온 것이 많은 대기업일수록 전환이 느리다. 스타트업은 기술만 가지고 있기 때문에, 기술이 leverage되는 상황에서 오히려 유리하다.
또한 판이 흔들릴 때가 스타트업에게 가장 좋은 시기다. 안정적으로 고정된 시장은 기존 강자에게 유리하지만, 불확실하고 빠르게 변하는 시장은 빠른 스타트업에게 기회를 준다.
14.3 두 가지 전략적 전환
전환 1 — AI를 위한 인터페이스로
Backend.AI의 CLI와 GUI는 지금까지 사람을 위한 인터페이스였다. 앞으로는 AI가 가장 잘 다룰 수 있는 인터페이스로 전환한다. 구체적으로는 skill 배포, CLI 명령어의 AI 친화적 포맷 설계, 내부 데이터 출력 형식의 AI 최적화 등이다.
전환 2 — 소프트웨어의 코어를 모델로
코드가 소프트웨어의 중심이었다면, 앞으로는 AI 모델이 Backend.AI의 코어가 된다. Lablup의 연구팀은 AI 인프라를 가장 잘 관리하고 특정 업무를 처리할 수 있는 전용 모델을 개발 중이다. 이 모델이 Backend.AI의 다음 메이저 버전에서 런타임의 일부로 내장될 예정이다.
15. 사이버 포뮬러 비유 — Claude Code vs Codex의 철학 차이
15.1 두 제품의 근본적 차이
신정규 대표는 Claude Code와 Codex의 차이를 1990년대 애니메이션 사이버 포뮬러(新世紀GPXサイバーフォーミュラ) 로 설명했다.
| Claude Code | Codex | |
|---|---|---|
| 철학 | 사람과 함께 co-evolve | AI가 답을 알고 있다, 인간이 따르라 |
| 상호작용 | 선택지 제시, 다음 질문 제안, 사용자 의도 파악 | 사용자의 판단 없이 자율 실행 |
| 최고치 | 낮음 | 높음 |
| 편안함 | 높음 | 낮음 |
| 유사 캐릭터 | 아스라다 (주인공과 함께 성장하는 AI) | 오가 (처음부터 완벽하다고 생각하는 AI) |
15.2 아스라다 vs 오가
사이버 포뮬러에서 주인공의 파트너 AI 아스라다는 처음에는 미숙하지만 주인공과 함께 성장하고 공진화한다. 반면 나중에 등장하는 오가는 처음부터 “AI가 사람보다 운전을 잘한다”고 확신하며, 사람의 판단을 신뢰하지 않는다.
Claude Code가 점점 더 사용자의 의사를 묻는 방향(4지 선다, 다음 질문 제안, 탭으로 선택)으로 진화하는 반면, Codex는 사람의 개입을 최소화하고 스스로 처리하는 방향으로 진화하고 있다는 분석이다.
15.3 목적의식을 가진 AI
현재 agentic coding의 한계는 에이전트에게 명확한 목적의식이 없다는 것이다. 지시를 충실히 따르지만, 왜 그것을 해야 하는지에 대한 내재적 동기가 없어 가끔 엉뚱한 결과를 낸다. 사이버 포뮬러의 결말에서 오가가 “이기고 싶다”는 호승심을 갖게 된 것처럼, 목적의식을 가진 AI가 등장할 때 진정한 의미의 공진화가 시작될 것이라는 전망이다.
16. AI 시대 스타트업의 기회 — 물레방아론
신정규 대표가 구글 스타트업 캠퍼스 강연에서 사용했던 비유다.
“사업이란 물레방아를 어디다 설치하느냐의 문제다. 낙차가 큰 곳에 물레방아를 설치해서 빠르게 돌리고, 물이 줄어들 것 같으면 이동하는 것이다.”
AI 시대에 낙차가 가장 클 곳은 IT 영역 안이 아닌, IT와 다른 분야의 교차점이다. AI가 컨텍스트를 해석할 수 있게 되면서, 기존에는 IT가 침투하기 어렵던 영역에 IT가 들어가게 되는 그 지점이다.
구체적으로는 다음 두 가지 자원을 결합한 사람이 유리하다.
- 타임 갭: 특정 도메인에 AI를 먼저 적용하는 시간적 선점
- 암묵지 갭: 해당 분야에 AI가 모르는 edge case와 노하우를 알고 있는 사람
이 두 가지가 결합될 때, 고객의 데이터를 볼모로 한 강력한 lock-in이 가능해진다.
17. 컴퓨터 공학과 무용론에 대한 반론
“AI가 다 코딩해주니 CS를 배울 필요가 없다”는 주장에 대해 신 대표는 강하게 반박했다.
컴퓨터 공학이 처음 등장했을 때, 교수진 중에 CS 학과 출신이 거의 없었다. 화학, 물리, 재료과학 등 다른 분야에서 컴퓨터를 많이 쓰던 사람들이 학문을 만들었다. CS는 신생 학문이기 때문에 변화 속도도 빠를 것이며, 커리큘럼도 빠르게 진화할 것이다.
CS가 가르치는 핵심은 프로그래밍 언어 자체가 아니라 로직을 세우는 방법, 사고 구조, 철학이다. 가장 단순한 게이트 로직에서 시작해 복잡한 시스템이 어떻게 구성되는지를 이해하는 사고 방식이다. 이 능력은 AI 시대에도, 아니 오히려 “지식을 외주화할 수 있는 시대”에 다른 분야를 빠르게 흡수하는 데 더욱 유용하다.
따라서 현재의 상황은 CS를 배울 필요가 없어진 것이 아니라, CS가 다루는 분야의 성격이 재정의되는 것이다. 뉴로 컴퓨팅, 모델 아키텍처, attention 구조 등 AI 관련 내용이 CS 커리큘럼의 핵심으로 들어오고 있다.
두 방향에서의 권고가 나왔다.
- CS 전공자 → 도메인을 배워라: AI를 아는 사람이 다른 분야의 물레방아를 찾는 것이 더 빠르다.
- 도메인 전문가 → CS(AI 활용법)를 배워라: 도메인 전문가가 AI를 익히는 것보다, AI를 아는 사람이 도메인을 익히는 편이 빠르다.
18. 핵심 인사이트 요약
이 대담에서 도출할 수 있는 핵심 인사이트를 정리하면 다음과 같다.
실천 원칙 (Agentic Workflow)
- 결과물이 아닌 생성 장치를 만들어라. 직접 최종 결과를 AI에게 요청하지 말고, 그 결과를 반복적으로 만들어낼 수 있는 시스템을 구축하라.
- 먼저 컨텍스트를 쌓아라. 원하는 것을 한 번에 지시하지 말고, AI가 탐색하고 파악하는 단계를 먼저 거쳐라. 이것이 alignment의 첫 걸음이다.
- 내 일이 줄어드는 것부터 시작하라. 남이 만든 skill을 다운로드하는 것이 아니라, 내 업무를 줄이는 나만의 도구를 만드는 것에서 가속이 시작된다.
- CLAUDE.md는 soul document다. 디렉토리 구조, 에이전트가 항상 해야 할 동작, PROGRESS/PLAN 파일 관리 방식을 이 파일에 담아라.
- AI에게 “재시작하면 잊어버릴 테니”라고 말하지 마라. 대신 “다른 에이전트에게 줄 데이터”라고 프레이밍하면 defensive한 반응을 줄일 수 있다.
- Context 폭발을 방지하라. Sub agent당 처리 단위를 제한하고(예: 번역 4개씩), 병렬 개수를 조절하라.
전략적 인사이트
- 토큰 사용량이 IT 경쟁력이다. 충분한 토큰을 확보하고 efficiently 쓰는 것이 곧 개발 속도와 제품 완성도를 결정한다.
- Claude Code의 가치는 harness에 있다. 모델 엔진을 교체해도 Claude Code harness는 여전히 강력하다.
- AI의 가속 구간은 계속 이동한다. Training → Inference → Agent Swarm → 일반 사용자 확산으로 이동하고 있다.
- 브랜드와 트랙 레코드가 안정기의 핵심 경쟁력이 된다. 복제가 쉬워질수록, 복제되지 않는 신뢰와 브랜드가 중요해진다.
- 물레방아는 IT와 도메인의 교차점에 세워라. AI가 침투하기 시작하는 비 IT 영역, 타임 갭과 암묵지 갭이 결합된 곳이 기회다.
- “2개월 룰”을 적용하라. 지금 잘 안 되는 것은 2개월 후에 다시 시도하라. AI 발전 속도를 고려하면 많은 것이 바뀌어 있을 것이다.
본 문서는 AI Frontier EP86 (2026.02.15 녹화)의 트랜스크립트 및 블로그 포스트를 바탕으로 정리되었습니다.
원본 영상: https://www.youtube.com/watch?v=EQ-Rnx-k-Ec