채팅창에 '진행 중인 딜 현황을 보고해 줘'라고 치면, 에이전트가 회사 DB를 설명해 둔 페이지를 찾아 읽고 거기 연결된 기능으로 DB를 조회해 결과를 내놓습니다. 이런 페이지에는 테이블과 용어, 조회할 때 지킬 금칙이 사람이 읽는 말로 적혀 있어요. 온톨로지라는 말은 여러 번 들었어도 어떻게 만드는지는 감이 없는 분이 많을 텐데요. 그래프와 형식 문법 없이도 온톨로지를 만들 수 있을까요?
제네시스랩 유대훈 CTO님의 답은 온톨로지를 말로 풀어서 원래 업무하듯 글로 쓰면, LLM이 컴파일해 준다는 것입니다. 10년 가까이 딥러닝을 연구해 온 회사에서 기업용 에이전트 빌더 에이전트리아를 만들고 있고, 그 페이지들을 만드는 기능이 슬립박스예요. 슬립박스가 나오기까지의 시행착오부터 변환 품질을 확인하는 방법, RAG와 나눠 쓰는 기준까지, 실제 화면을 열어 놓고 하나씩 물어봤습니다.
딥러닝 연구실이 에이전트 빌더를 만들기까지
Q. 구독자분들께 자기소개를 부탁드립니다.
제네시스랩 CTO 유대훈입니다. 회사가 생긴 지 10년 정도 됐는데, 그동안 대부분 딥러닝 기술을 연구했어요. 채용 면접 분석부터 음성 인식, 음성 합성, AI 휴먼까지 딥러닝 모델을 10개 넘게 만들었던 것 같습니다.
그러다 여러 서비스를 만들게 됐고, 지금은 그걸 전부 모아 에이전트 빌더를 만드는 일을 총괄하고 있습니다.
Q. 뷰인터 HR을 만들던 제네시스랩이 이제 에이전트리아를 만드는데, CTO로서 지금 하시는 일은요?
지금은 에이전트 빌더를 직접 개발하는 데까지 깊숙이 들어가 있어요. 2~3년 전부터 생각해 온 것들을 실제 구현체로 빠르게 만들면서, 제품을 빨리 내놓는 데 집중하고 있습니다.
프롬프트 몇 개 고치는 데도 1~2주가 걸렸습니다
Q. 어떤 문제를 보고 기업용 에이전트 빌더를 만들게 됐나요?
저희는 채용 서비스 뷰인터 HR 말고도 엔터테인먼트 서비스 쥬시, 정신건강 자가평가 챗봇 닥터리슨을 만들어 왔어요. 그중 뷰인터 HR에는 AI가 10개 넘게 들어가고, 고객마다 워크플로우(일이 처리되는 순서)도 달랐습니다.
그래서 HR 전문가 같은 현업 도메인 전문가가 고객의 필요를 짚어 주면, AI 연구원이 스트림릿(시험용 화면을 빠르게 만드는 파이썬 도구)으로 프로토타입을 만들었어요. LLM으로 만드는 것도 똑같았고요.
그건 실제 서비스 수준이 아니라서 다시 서비스 개발팀으로 갑니다. 트래픽을 버티게 다듬어 배포하는데, 이 운영 주기가 2주 정도 걸려요.
AI 서비스가 일반 서비스와 다른 점은 불확실성이에요. 원래는 QA 시트만 잘 통과시키면 배포에 문제가 없었습니다.
그런데 AI는 배포한 순간부터가 시작입니다.
사용자는 저희가 원하는 대로 쓰지 않거든요. 배포 뒤 문제가 생기면 현업이 판단하고, 그걸 정리해 AI 연구팀이 다시 프로토타입을 만들어 넘깁니다. 현업, AI 연구원, 개발팀 세 팀이 얽히다 보니 프롬프트 몇 개로 끝날 일도 1~2주가 걸렸어요.
그래서 쥬시에서 쥬시 스튜디오라는 도구를 만들어 시험해 봤습니다. 현업 부서가 프롬프트나 지식 체계를 직접 설정하면 에이전트가 바로 만들어지고, 문제가 생기면 연구팀과 같은 화면을 보며 그 자리에서 고치게 했어요. 그랬더니 어떤 건 하루 만에 테스트해 볼 수 있었습니다.
그걸 보고 세 서비스의 바탕이 될 범용 에이전트 빌더를 만들자고 정했어요. LLM도 AI도 계속 바뀌니, 개발자에게 맡기지 말고 현업 전문가가 직접 테스트해 볼 수 있는 환경이 필요했습니다. 당시엔 개발 인력이 부족해서 기존 도구를 쓸까 하고 다 조사해 보기도 했고요.
Q. n8n(노드를 이어 자동화를 만드는 도구) 같은 도구도 있었잖아요?
네, n8n을 특히 많이 검토했어요. 그런데 걸린 게 있었습니다. 버저닝(버전 관리)을 거친 API 배포가 너무 힘들었어요.
작업은 한곳에서 하더라도 모듈마다 버전을 매기고, 스테이징 서버(배포 전 시험 서버)와 개발 서버에 버전을 달리해 배포할 수 있어야 했어요. API 키 관리까지 넣고 보니 기존 도구는 쓸 수 없다고 판단했습니다.
그래서 처음엔 내부에서 쓰려고 직접 만들기 시작했어요. 이 빌더는 저희 QA팀과 직원분들이 정말 많은 고통을 겪은 도구이기도 합니다.
그래프 대신 '말'로 쓰는 온톨로지
Q. 오늘의 주제인 슬립박스, 모르는 분들을 위해 설명해 주시겠어요?
저희 목표는 AI 워크플로우가 아니라 에이전트였어요. 그래서 에이전트에게 능력을 준다는 뜻에서 어빌리티(Ability)라는 말을 씁니다. n8n에서 워크플로우라고 부르는 것을 저희는 어빌리티라고 불러요.
Q. 노드를 이은 워크플로우 전체를 어빌리티라고 부르시는 거군요?
그 어빌리티를 버전으로 관리하고, 다른 어빌리티 안에 모듈처럼 다시 꽂아 쓸 수 있게 했어요.
마치 개발자 마인드죠.
에이전트 계층은 따로 뒀어요. 에이전트 노드를 붙이고 어빌리티나 일반 노드를 연결하면, 에이전트가 그걸 도구처럼 씁니다.
계속 마음에 걸린 건 데이터 레이어였어요. 처음엔 임베딩(글을 숫자로 바꿔 비슷한 뜻을 찾는 방식)과 RAG(관련 문서를 찾아 답에 붙이는 방식)로 데이터 스토리지를 출시했어요. 그래도 2~3년 전부터 연구해 온 온톨로지(개념 사이의 관계를 정의한 지식 체계)가 계속 마음에 남았습니다.
그때 연구한 것의 핵심은, 고객사에 흩어진 데이터 시스템과 API를 지도처럼 그리는 거였어요. 어떤 데이터는 어느 DB의 어느 테이블에 어떻게 접근하고, 어떤 데이터는 어느 시스템의 API를 불러야 하는지 모아 둔 것. 저는 그 지도를 온톨로지라고 정의했습니다.
공개된 자료로 공부해 보니, 팔란티어는 고객사 시스템을 자기 데이터 레이크(데이터를 한곳에 모은 저장소)에 올리고 그 위에 온톨로지를 쌓더라고요. 실시간 동기화에 엄청난 인프라가 들 테고, 기업도 자기 자산을 남의 솔루션에 넣는 셈이라 부담일 거라고 봤어요. 생각보다 많은 중견기업이 데이터 주권을 더 소중하게 여기시거든요.
그래서 있는 시스템을 최대한 그대로 쓰는 방법을 고민했습니다.
문제는 온톨로지 문법이 개발자인 저에게도 너무 어렵다는 거였어요. 그러다 클로드 스킬(작업 방법을 파일로 묶어 클로드에게 주는 기능)을 보고, 역시 마크다운(간단한 기호로 서식을 붙인 텍스트) 문서가 실시간으로 다루기 좋고 사람이 이해하기도 좋다 싶었어요.
그러다 안드레 카파시가 LLM 위키(LLM이 자료를 읽어 마크다운 위키를 쌓고 고쳐 가는 방식)를 공유했어요. 저희는 2~3년 전 제텔카스텐(메모를 서로 이어 쌓는 메모법) 붐 때부터 옵시디언을 쓰고 있었거든요.
그렇게 쓰다가 불현듯 '이걸 연결하면 되겠구나' 싶었습니다.
제가 보기에 LLM 위키는 목차가 200개를 넘으면 성능이 떨어져서, 목차를 트리로 만들었습니다. 또 LLM이 글을 쓰며 목차를 잇다 보니 다른 제목을 달아 연결이 끊기기도 해요.
Q. 같은 제목이 두 번 생기는 경우도 있나요?
네. 그래서 마지막에 린트(끊긴 연결을 찾는 점검)를 돌려 고아 페이지(어디에도 연결되지 않은 페이지)를 맞추는데, 이게 토큰을 엄청 씁니다.
그래서 목차는 DB로 관리하기로 했습니다. DB는 정합성(데이터끼리 어긋나지 않는 상태)을 기본으로 맞춰 주거든요. 목차를 바꿀 때도 토큰을 써서 고치는 게 아니라, 재구성 계획만 세운 뒤 트랜잭션 한 번으로 반영합니다.
그런데 DB로 관리하면 에이전트가 이해를 못 해요. 그래서 DB 내용을 다시 마크다운으로 렌더링해 에이전트에 넣어 주는 방식으로 실시간 동기화를 맞췄습니다.
W3C 표준 온톨로지는 규칙이 정말 좋지만, 저희가 감당하기에도 고객에게 설명드리기에도 너무 힘들었어요. 그래서 온톨로지를 말로 풀어서, 원래 업무하듯이 글로 쓰자고 했습니다. 계약 관계든 어떤 관계든 말로 설명해 두면, 이제는 LLM이 뒤에서 컴파일해 줍니다. 그렇게 탄생한 게 슬립박스(Slipbox)예요. 독일어 제텔카스텐을 영어로 바꾸면 슬립박스거든요.
DB를 넣으면 용어 사전과 조회 금칙이 생긴다
Q. 온톨로지가 어떤 모습인지, 간단하게라도 화면을 보여 주실 수 있나요?
온톨로지라고 하면 대부분 그래프를 떠올리시죠. 엔티티(사람, 장소, 제품 같은 명사 정보)와 그 사이 관계를 셋씩 묶어 잇는 방식이에요. 그런데 말로 설명한다고 생각하면, 페이지들 사이의 관계를 설명하는 것으로도 충분하다고 봤습니다.
LLM 위키는 파일을 인제스트(자료를 읽어 지식 페이지로 만드는 작업)해서 페이지를 만드는데, 저희는 DB나 구글 드라이브, 디스크도 인제스트할 수 있게 했어요.
테이블을 인제스트하면 먼저 테이블 이름과 컬럼 이름, 코멘트를 봅니다. 그런데 컬럼 이름이 약칭이라 알아보기 힘든 경우가 많아요. 그래서 데이터 일부를 샘플링해 보며 뜻을 추정합니다. 데이터가 어떤 구조로 어디 있는지만 알면 에이전트는 시행착오를 거쳐 찾아가요. 아무것도 없으면 뭐부터 할지 막막해하고요. 그래서 '지도를 만든다'고 표현합니다. 테이블 사이의 의존 관계도 함께 연결해 줘요.
앞쪽 페이지를 보면, 온톨로지라는 게 결국 거기서 쓰는 용어와 그 용어의 정의예요. 같은 용어도 분야마다 다르게 쓰이거든요.
Q. '파리'가 호주에도 미국에도 있듯, 어느 파리인지 뜻을 명시해 주는 거네요?
네. 그래서 데모용 DB를 합성 데이터로 만들어 인제스트해 봤어요. 용어에 설명을 같이 넣으면 LLM이 이런 걸 너무 잘합니다. '이 용어는 이런 뜻이야'라고 주면, LLM은 그때부터 그 용어를 그 뜻으로 받아들여요. 사용자는 그 도메인의 용어를 그대로 쓰실 거고요.
해 보면서 느낀 것도 있어요. 센서 데이터처럼 엄청나게 쌓이는 테이블은 실수로 전체를 조회하는 순간 메모리가 터집니다. 그래서 그런 테이블을 추적해 '누적 시계열 데이터니까 기간 필터를 걸어라' 같은 금칙과 할 수 없는 연산을 남겨요.
처음엔 이게 자동으로 만들어지지만, 슬립박스 에이전트에게 고치게 할 수도 있어요. '이 용어는 잘못 설명돼 있네' 싶으면 노션이나 옵시디언 쓰듯이 여기서 그대로 고치면 됩니다.
위키의 장점은 사람이 관계를 따라가다 보면 전체를 이해하게 되는 느낌이 든다는 거예요. 지금 하위 페이지로 보이는 게 아까 말씀드린 DB로 관리하는 부분인데, 실제로는 마크다운 블록으로 에이전트에 들어갑니다.
Q. DB 이름이 명시돼 들어가니 속도가 빨라진 건가요?
맞습니다. 정합성도 분명해져서 데이터가 틀리는 걸 막을 수 있어요. 그리고 온톨로지가 다루는 연결과 관계, 절차를 모두 그래프로 만들 필요는 없다고 생각했어요. 저희는 페이지 하나를 하나의 작은 온톨로지로 봤습니다.
공장이 자동화 라인과 어떻게 연결돼 있는지를 원래는 공장, 라인, 제품 같은 엔티티로 이어야 하는데, 여기서는 그냥 글로 씁니다. LLM이 그걸 너무 잘하니까요.
잘 바뀌었는지는 질문과 테스트로 확인합니다
Q. 엑셀, PPT를 인제스트했을 때 잘 변환됐는지는 고객사가 어떻게 검증하나요?
파일 인제스트에는 원문보전 방식이 있습니다. 원문을 알맞게 잘라 제자리에 넣는 역할만 해요. 법률은 글자 하나만 바뀌어도 내용이 잘못될 수 있잖아요. 그래서 마크다운은 조금 덜 예쁘게 나오지만 원문을 보고 잘라 그 위치에 맞춰 넣습니다.
합성 방식도 있어요. 내용을 토픽으로 나눠 트리 목차를 만드는 게 핵심입니다. 문서에 목차가 있으면 거기서 힌트를 얻고, 목차가 없거나 실제와 어긋나 있으면 페이지를 직접 뒤지며 토픽을 뽑아 목차를 만들어요. 어떨 때는 3단계, 어떨 때는 2단계 깊이로 나옵니다.
Q. 제가 로펌을 운영한다면, 인제스트한 뒤 평가는 어떻게 하나요?
AI 관점에서 보면 결국 밸리데이션 데이터셋(정답을 아는 검증용 데이터)이 필요합니다. 우선은 여기서 질문을 던져 확인할 수 있어요. 도메인을 아는 분이라면 일일이 들여다보기보다 중요하게 여기는 포인트를 물어보는 걸로 1차 확인을 합니다.
두 번째는 에이전트리아의 벌크 테스트(여러 입력을 한꺼번에 돌려 결과를 확인하는 시험)예요. 어빌리티가 정답을 맞히는지 결과를 뽑아 검증합니다. AI에서 데이터를 확인하는 방법은 여전히, 검증용 데이터셋을 합성이든 뭐든 만들어 차이가 있는지 계속 비교하는 거예요.
Q. 비개발자에게는 평가 자체가 긴 작업일 텐데, 줄일 방법은 없나요?
저희가 가칭으로 제로클릭이라고 부르는 기능이 있습니다. 입력 데이터를 가상으로 합성해 테스트를 만들어 달라고 시킬 수 있어요.
예를 들어 직원이 재미난 에이전트를 만들면, 저희가 만든 채팅 테스트로 시험해 볼 수 있거든요. 그런데 제로클릭 에이전트에게 '네가 채팅 테스트를 해 봐'라고 하면, 제로클릭이 스스로 말을 주고받으며 테스트를 처리합니다. 다들 입력 데이터 만드는 걸 특히 힘들어하시는데, 도메인만 주면 알아서 재밌게 만들더라고요.
Q. 로펌이라면 가진 파일에 비해 바깥 데이터는 없을 텐데, 웹 검색으로 가져와 같이 넣나요?
여기서는 에이전트를 분석해 맞는 입력값을 찾고, 합성 데이터를 스스로 만들어 동작합니다. 심리상담 에이전트라면 여러 페르소나가 있을 수 있잖아요. '건강한 사람의 페르소나로 대화를 시작해'라고 하면 제로클릭이 대화를 만들어 주고받고, 끝나면 '에이전트를 이렇게 고치면 좋겠습니다' 하는 가이드까지 줍니다.
어떤 값을 넣을지 상상하기는 너무 어렵잖아요. 큰 틀만 알면 바로 테스트해 볼 수 있습니다. 본격적으로 준비되면 결국 데이터 테스트를 만들게 되고, 그때는 벌크 테스트로 같은 결과가 나오는지 추적하며 안정성을 높여야 해요.
자주 바뀌는 지식에 임베딩을 쓰지 않는 이유
Q. RAG는 안정적인 답이 장점인데, 임베딩을 포기한 슬립박스가 더 나았던 예가 있나요?
저희 데이터 스토리지에도 임베딩 기능은 있습니다. 테이블의 특정 텍스트 컬럼을 임베딩 필드로 연결해 두고 모델을 고르면 돌려요. RAG로 프로젝트를 해 보니 데이터가 바뀌지 않으면 나쁘지 않았어요. 고민은 임베딩 모델을 바꿀 때부터 시작됐습니다.
몇천 쪽짜리 PDF를 청크(잘게 나눈 조각)로 나눠 임베딩해 뒀는데, 고객이 다른 모델로 바꿔 달라고 하면 일부만 바꿀 수가 없어요. 전면 교체해야 합니다.
슬립박스는 성격이 달라요. 정적인 데이터는 데이터 스토리지에서 임베딩을 쓰면 되지만, 에이전트를 돌리다 문제가 생기면 바로 고쳐야 하거든요.
그러면 고칠 때마다 임베딩을 다시 해야 합니다.
AI를 오래 하며 느낀 건, 모델을 바꾸는 게 엄청난 일이라는 거예요. 모델이 바뀌면 모든 게 달라지는데, 회귀 테스트(바꾼 뒤에도 예전처럼 되는지 보는 시험)를 전수로 하기가 너무 어렵습니다.
데이터가 1년에 한 번 바뀔 만큼 정적이라면 임베딩이 적합하고 빠르고 좋아요. 그런데 일주일이나 한 달 단위로 바뀌면 감당할 수 있을까요? LLM 위키에 RAG를 붙여 성능을 높인 사례도 꽤 있지만, 그러면 GPU 서버가 필요하고 고객이 그걸 관리해야 하고 모델이 바뀌면 전체를 바꿔야 해요.
그래서 저희는 하이브리드입니다. 이럴 때는 슬립박스, 이럴 때는 RAG를 써요. 형식을 갖춘 온톨로지는 이미 준비된 시스템이 많으니 어빌리티 노드로 조회하면 됩니다. 그래프로 하던 일은 대부분 슬립박스로 풀고, 정말 형식이 필요한 건 다른 시스템과 협업하자는 생각이에요.
화면으로 본 슬립박스, 딜 현황 보고부터 Text-to-SQL까지
Q. 준비하신 시연 영상을 같이 보면서 설명해 주시겠어요?
먼저 슬립박스에 DB를 인제스트한 다음 그 구조를 보여 드리고 싶었어요. 이 데이터를 바탕으로 슬립박스가 노드로 바뀌는데, 연결 고리와 그래프의 관계성은 전부 자동으로 만든 것입니다.
에이전트는 목차부터 탐색합니다. 처음엔 이 부분이 좀 느려서, 그래프를 키워드로 검색하는 서치 노드도 제공해요. 최근 나온 Jev(정해진 선택지 중 하나를 고르는 결정 모델)도 저희한테 딱 맞는다고 봅니다.
지금 보이는 건 페이지에 어빌리티를 연결하는 부분이에요. 연결해 두고 '이걸 실행해'라고 글로만 써 두면, 서브 에이전트(큰 에이전트가 일을 나눠 맡기는 작은 에이전트)가 그 페이지를 보고 그 어빌리티를 실행합니다.
에이전트는 입력 노드와 출력 노드 사이에 에이전트 노드를 두고, 쓸 LLM 노드와 슬립박스 탐색 노드를 연결해 구성해요. 슬립박스도 하나의 서브 에이전트라 가벼운 LLM을 따로 붙일 수 있고, 다음 단계로 여기에 Jev를 붙이면 목차 탐색이 빨라질 거라고 기대하고 있습니다.
여기에 슬립박스 실행 노드를 붙이고 채팅창에 '진행 중인 딜 현황을 보고해 줘'라고 하면, 오른쪽에 과정이 차례로 보입니다. 슬립 페이지를 탐색해 해당 페이지를 찾아 실행하고, 그 페이지의 어빌리티가 DB를 조회한 결과를 에이전트가 받아 출력해요. 조회에서 그치지 않고 실행까지 하는 모습을 보여 드리고 싶었습니다.
이어서 '전략 고객은 표 맨 위에 따로 모아 보여 줘'라고 하면 다시 탐색해서 결과를 보여 줍니다. 디버깅하려면 이 과정을 다 봐야 어디를, 슬립박스를 어떻게 고칠지 알 수 있어요. 그래서 과정마다 입력값과 출력값을 다 볼 수 있게 해 뒀습니다. 이번 AI 기본법이 말하는 투명성, 설명 가능성과도 이어진다고 봐요.
Q. 이 화면은 또 어떤 데모인가요?
인제스트 과정 데모예요. 파일은 많이들 보셨을 테니 DB로 준비했습니다. DB와 크레덴셜을 고르고 쓸 어빌리티를 선택한 뒤 인제스트를 걸면, 스키마 같은 사전 정보 없이도 분석해서 페이지들이 만들어져요.
제대로 됐는지 일일이 보기 힘들 때 AI의 도움이 필요합니다. 쭉 훑어본 다음 슬립박스 에이전트에게 '품질 검사를 하려면 어떤 정보가 기록되느냐'고 물으면, 페이지를 보고 판단해서 설명해 줘요. 품질 검사 결과가 다른 정보와 어떻게 연결돼 있는지도 대화로 들어 볼 수 있고요.
이 구조를 아는 분들은 꽤 명확한 질문을 하시더라고요. AI와 함께 뭘 할 수 있는지, 잘 되는지를 이렇게 일단 체크할 수 있습니다.
Q. 그러면 현업이 할 일은, 어떤 질문을 던질지 정한 질문 데이터셋을 따로 만드는 거겠네요?
그렇죠. 인제스트한 슬립박스를 에이전트에 연결하고 슬립박스 쿼리문을 쓰라고 가이드를 준 다음 질문을 만듭니다. 불량률 같은 걸 사람이 직접 확인해 볼 수 있고, 쿼리문도 노출하게 해 둬서 어떤 쿼리가 나갔는지 보여요.
생각보다 Text-to-SQL(말로 한 질문을 DB 쿼리로 바꾸는 기술)에 갈증이 많으시더라고요. 쿼리가 잘 안 만들어지면 그다음엔 할 수 있는 게 별로 없어요. DB 정보가 개발 문서나 코드에 흩어져 있고 시스템 프롬프트에 크게 좌우되거든요. 인제스트하면 DB 명세가 나오잖아요. 그러니 쿼리를 짤 때 모르는 것은 슬립박스에서 맥락을 넣어 주면 됩니다.
아까 파리 같은 경우가 DB 안에도 있어요. 최근 한 고객사는 똑같은 사업자 번호가 테이블마다 의미가 다르다고 하시더라고요. 관련 테이블이 많아서 프롬프트에 다 넣기엔 양이 너무 많은데, 페이지별로 돼 있으면 거기에 한두 줄만 넣으면 됩니다.
현업분들이 '이 데이터로는 못 하겠구나' 싶으면 해당 페이지에 가서 빠진 부분만 글로 써 주면 됩니다. 그다음은 LLM이 잘 판단해 주니까요. 이게 에이전트를 빠르게 배포한 뒤 안정적으로 만들어 가는 방법이 아닐까 생각합니다.
개인의 프롬프트를 회사의 자산으로, 책임은 사람에게
Q. 자기 데이터를 아직 못 넣었다는 회사가 많은데, 슬립박스로 풀 수 있는 대표 도메인은요?
지금은 클로드 같은 앱이 이미 너무 잘하죠. 그 상황에서 기업들이 한계로 많이 말씀하시는 게 있어요. 처음 AI를 쓰려고 할 때 주저하셨던 첫 번째 이유는 우리 데이터가 학습용으로 나가는 것 같다는 두려움이었습니다.
그래도 결국 다들 도입하시죠. 그다음엔 경영진이 ROI를 고민하세요. 생산성이 엄청나다는데 실제로는 그렇게 대단해 보이지 않고, 전체 직원으로 보면 여전히 비싸거든요. 개인이 자기만의 프롬프트를 만들고 '내가 만든 거니 회사에 공유할 수 없다'고 하는 사례도 뉴스에서 봤는데, 틀린 말은 아니에요. 그러니 처음부터 회사의 규칙을 만들어야 합니다.
지금 가장 큰 화두는 자산화인 것 같아요. 회사는 시스템으로 가야 하니까요. AI 활용을 개개인의 역량으로 푸는 게 아니라, 회사 자체의 역량이 높아지게 하려면 어떻게 해야 할까를 고민하시는 거죠.
저희가 해 볼 수 있는 건 그런 것들을 슬립박스로 모아 가며 쓰게 하는 거예요. 그런 고충에 조금은 도움이 될 수 있지 않을까 생각합니다. 모든 걸 풀 수는 없지만, 글로 쓰는 거니까 현업이 쉽게 뭐라도 시도해 볼 수 있습니다. 슬립박스 노드를 어빌리티로 만들면 MCP(AI 앱을 외부 도구에 연결하는 표준 규약) 서버의 도구로도 쓸 수 있어요.
Q. 그 MCP 서버 주소를 제 클로드에 연결해 쓸 수 있다는 거네요?
네. 슬립박스 쓰기 같은 MCP 도구도 다 있거든요. 클로드로 작업하다 정리가 끝나면, 내 개인 스킬로도 남기지만 회사 자산 쪽에도 같이 연결해 달라고 할 수 있죠. 도구로도 에이전트로도, 여러 방식으로 가지고 놀 수 있는 형태를 생각하고 있습니다.
Q. 마지막으로 더 하고 싶었던 이야기가 있으신가요?
저희는 10년 동안 AI 딥러닝과 데이터 설계를 해 왔는데, 그중 7~8년은 학습 데이터를 어떻게 만들지 정말 많이 고민했어요. 그런데 LLM이 모든 도메인을 하게 되면서 학습 방법이 달라졌고, 다행히 챗GPT 덕분에 많은 사람이 AI가 뭔지 알게 됐습니다. 예전엔 AI가 뭔지 설명하는 데 시간을 많이 썼거든요.
AI가 어마어마하게 발전하고 사람을 대체할 거라고들 하죠. 하지만 저는 책임을 지는 게 만만치 않을 거라고 봐요.
결국 책임은 사람이나 기업이 져야 합니다.
그러면 정말 중요한 의사결정은 사람이 승인하는 것만 남을지도 모르죠. 요즘 이해가 병목이라고들 하잖아요. AI가 잘 만들어 준 걸 'HTML로 만들어서 나를 이해시켜 줘' 하면서 이해한 다음 결정하죠. AI가 뛰어나져도 그 안이 어떻게 돌아가는지는 사람이 이해해야 합니다. 문제가 터지면 사후에라도 들여다보고 무엇을 바꿀지 사람이 결정해야 하니까요.
얼마 전 클로드가 한동안 멈췄을 때 모두가 가만히 있어야 했던 일도 있었잖아요. 최소한 문제가 생기면 사람이 들어가서 워크플로우를 보든 고치든 할 수 있어야 합니다. 그래서 실용적인 서비스라면 어떤 형태로든 사람과 협업하는 방식이 계속 있을 것 같아요.
조쉬가 직접 운영하는 AI 솔로프리너 클럽에 초대합니다.
이미 300명이 넘는 분들이 ASC와 함께 성장하고 있습니다.
구글 엔지니어, 토스 PM, 산부인과 전문의, 스타트업 대표까지
— 각자의 자리에서 정상에 선 사람들이 지금 AI로 새로운 도전을 시작했습니다.
그리고 ASC 14기는 단 30명만 함께합니다.
아직 늦지 않았습니다.
지금 시작하는 당신이, 1년 뒤 가장 앞서 있을 솔로프리너입니다.
의견을 남겨주세요