이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

리트머스에서는 고객이 화면 속 버튼을 클릭하고 "여기 이렇게 바꿔주세요"라고 코멘트를 남기면, 사람이 아니라 AI 에이전트가 코드를 고치고 스크린샷까지 찍어서 확인시켜줍니다. 씨그로 주식회사가 운영하는 외주 개발 에이전시 리트머스는 이런 방식으로 하루에 개발 티켓을 300~400개씩 처리하고 있어요.

요즘 다들 'AI로 업무를 자동화한다'고 말하지만, 회사 하나를 통째로 에이전트가 돌아가는 운영체제 위에 올려버린 사례는 흔치 않죠.

김응진 대표는 세일즈·PM·개발자라는 구분을 아예 없애고 전부 '컨설턴트'라는 하나의 직군으로 합친 뒤 생산성이 3배 이상 올랐다고 말합니다. AX를 조직에 어떻게 심었는지, 그리고 왜 이게 앞으로 회사의 실행 엔진이 될 수밖에 없는지, 그 과정을 하나씩 들어봤어요.

(세일즈 파트에 관한 내용은 리트머스 세일즈 리드 유영준 님이 설명해 주셨습니다.)

['빌더 조쉬' 유튜브 구독하러가기]

리트머스라는 회사

Q. 리트머스와 대표님 소개를 부탁드려요.

저는 2021년에 창업을 해서 씨그로(cigro)라는 법인으로 시작했고 지금도 운영 중입니다. 사업부가 두 개예요. 하나는 엔대시 씨그로라는 이커머스 데이터 분석 솔루션이고, 다른 하나가 외주 개발 사업부인 리트머스입니다. 기본적으로 인력 중심적인 회사예요.

Q. 세일즈부터 운영, 구축, 모니터링, QA까지 전 영역을 자동화하고 계신데, 이걸 'AIOS'라고 부르시는 배경이 궁금해요.

저희가 AI에 집중하게 된 핵심 계기는 '미래가 없다'는 생각이 제일 크게 들었기 때문이에요. 기존 비즈니스 모델과 방식으로 계속 운영하면, 결국 LLM이 성장하는 만큼 저희 일이 잠식되는 구조더라고요. 반복적인 업무는 AI가 대신하게 될 테고, 남는 건 그걸 관제하고 총괄하는 사람들 중심이 될 거라고 봤어요.

그래서 '사람이 일할 때 어느 부분을 자동화해야 LLM과 경쟁하지 않으면서 오래 갈 수 있는 경쟁력이 될까'를 계속 고민했어요. LLM이 결국 지능을 대체하는 거잖아요. 그 관점에서 좋은 키워드를 하나 얻었는데, 바로 OS예요. 운영체제가 많은 걸 관장하듯이, 회사도 일하는 방식에 대한 하나의 플랫폼이 돼야 한다고 생각했어요. 그걸 AIOS라고 부르니까 제일 직관적으로 와닿더라고요.

Q. 개별 업무를 하나씩 자동화하는 걸 넘어서, 워크플로우 전체를 더 높은 층위에서 본다는 관점으로 읽혀요.

맞아요. 앞으로는 에이전트를 활용해서 다양한 업무를 복합적으로 수행하는 영역이 중요해질 거예요. 결국 기업의 경쟁력이라는 게, 유연하게 대응하는 능력이나 현실에서 변수를 마주치며 쌓은 경험을 녹여내는 데 있다고 보거든요. 그래서 개별 작업이 아니라 체계와 시스템 관점에서 일을 보게 됐어요.

AX는 3단계로 간다

Q. AX를 조직에 도입한다고 하면, 실제로는 어떤 순서로 진행되나요?

제 생각에 요즘 가장 핫한 분야는 교육이에요. 개인의 업무 생산성을 높이는 방향이 제일 시작하기 쉽거든요. 그래야 조직이 바뀌고요. 그다음 단계는 프로젝트를 띄우는 거예요. 개인 역량이 아니라 조직 역량을 만들기 위해서, 부서별로 '원래 하던 업무 A를 자동화해 보자'는 식으로 나아가는 거죠.

마지막 단계로 가면 전사를 어떻게 AI화할 거냐는 문제가 나와요. 데이터를 어떻게 관리할지, 각자가 만든 에이전트를 어떻게 공유할지, 그리고 공유보다 더 중요한 게 어떻게 고도화할지예요. 개인이 자기 업무 경험과 현실의 맥락을 담아 만든 에이전트를 공유하고 발전시키려면, 이 단계부터는 ERP 수준으로 전체를 관제하는 솔루션이 필요해져요. 올해부터는 그래서 생산성 차이를 본격적으로 느끼기 시작한 시점인 것 같아요.

Q. 생산성 차이를 느끼게 되신 구체적인 계기나 사례가 있을까요?

지표가 제일 커요. 최근 들어서 저희가 모든 포지션을 통합하고 있거든요. 세일즈·PM·개발자로 나뉘는 게 아니라, 다 같이 하는 컨설턴트 형태의 롤로 모든 포지션이 진화한다고 보고 조직 체계를 바꿨어요. 그렇게 하고 나서부터 생산성이 거의 3배 이상 높아졌다고 느껴요. 같은 매출을 내는 데 투입되는 인력 수가 많이 줄어들고 있다는 뜻이죠.

Q. 그렇게 통합하면 각자 원래 가진 전문 영역을 확장하는 형태인가요, 아니면 완전히 다른 직무를 새로 시도하는 건가요?

확장에 좀 더 가까워요. 특히 확장이 잘된 영역이 개발 쪽이에요. LLM 모델 자체가 워낙 잘 되고 있으니까요. 그래서 PM이나 세일즈 하시는 분들이 개발을 같이 한다거나, 세일즈와 개발을 함께 하는 식으로 확장이 많이 되고 있어요.

Q. 그러면 한 사람이 프로젝트 하나만 맡나요, 아니면 여러 개를 동시에 하나요?

프로젝트 단가가 제일 중요해요. 규모가 크면 다른 걸 같이 할 여유가 아예 없거든요. 그래서 단가가 5천만 원, 8천만 원 정도 되면 그 프로젝트만 집중한다고 보시면 돼요. 반대로 1천만~2천만 원짜리면 어느 정도 협업해서 몇 개를 같이 하는 게, PM·세일즈 하시는 분들한테는 더 적절하고요.

리트머스의 운영체제 : 워크벤치, 넥서스, 파운드리

Q. AIOS를 구성하는 요소들을 하나씩 소개해 주시면 좋겠어요.

먼저 워크벤치부터 말씀드릴게요. 워크벤치는 각자의 작업 공간인데, 쉽게 말하면 직무별·업무별로 특화된 레포지토리라고 보시면 돼요. 예를 들어 세일즈면 세일즈에 필요한 컨텍스트 정보를 다 레포지토리에 넣고, 거기에 에이전트도 세팅해 두는 거죠. 그렇게 하면 세일즈, 기획, 디자인, 영상 편집 같은 것마다 워크벤치가 생기고, 개인 업무는 다 거기서 해요. 상황에 따라 코덱스를 쓰거나 클로드를 쓰거나 자유롭게 선택하고요.

Q. 그러면 회사의 핵심 정보를 넣어주고 권한을 관리하는 플랫폼도 따로 필요할 것 같은데요.

그래서 저희가 '넥서스'라는 걸 만들었어요. 일종의 ERP 같은 개념으로 보시면 돼요. 경영진에게는 급여 정보나 계약 정보, 평가 정보까지 관리가 가능한 플랫폼이고, 직무에 따라 열어주는 데이터가 달라져요. 세일즈면 세일즈에 맞는 데이터가 있고, PM이면 프로젝트 진행 상황에 대해 읽고 쓸 수 있는 형태죠.

Q. 그럼 워크벤치와 넥서스는 어떻게 연결이 되나요?

MCP로 연결돼 있어요. 넥서스에서 MCP를 생성해서 넘겨주는 방식이에요. 개인별로 토큰이 발급되고, 에이전트한테도 각각 따로 발급돼요. 권한이 에이전트별로 다른 거죠.

Q. 넥서스에는 데이터가 어떻게 쌓이나요?

넥서스에는 기본적으로 정형화된 데이터만 저장한다고 보시면 돼요. 저희가 세팅한 스키마가 있고, 그 스키마에 필요한 정보만 적재돼요. 그 내용을 업데이트하거나 저장하는 건 보통 워크벤치에서 많이 해요. 반복적으로 하는 완전히 정형화된 데이터는 중앙에서 API 키로 수집해서 넥서스에 넣고요. 그냥 정리되지 않은 원본 데이터, 즉 로우(raw) 데이터는 메모리라는 걸 따로 써서 거기에 적재합니다.

Q. 메모리에 적재한다는 게 잘 이해가 안 되는데, 그 메모리가 정확히 어떤 건가요?

이건 좀 외주사 특화된 부분이라고 할 수 있는데, 저희는 프로젝트별 컨텍스트가 아주 중요하거든요. 이걸 문서로만 정리하면 나중에 찾아가기가 어려워요. 그래서 시맨틱 서치(단어가 정확히 일치하지 않아도 의미로 검색해주는 방식)가 되게 해줘야 하는데, 그 시맨틱 서치가 이뤄지는 곳이 메모리예요.

넣는 포맷은 맥락을 설명하는 식이에요. 예를 들어 '몇 월 며칠에 누구랑 미팅을 했는데, 여기서 이런 얘기가 나왔고, 이건 정책 협의가 됐다' 이런 걸 한두 문장으로 간단하게 정리해서, 미팅 한 번 하고 나면 수십 개씩 저장해요. 카카오톡에 있는 내용도 저장하고요. 그러면 에이전트가 작업할 때 그와 관련된 걸 검색해서 쓰는 거죠. 메모리도 프로젝트별로 나뉜 권한 개념이 있어요.

Q. 권한 관리는 어떻게 하시나요? 임원진이 보는 정보와 구성원이 보는 정보가 영역별로 나뉘어 있을 텐데, 그 가드레일을 어떻게 설정하셨는지 궁금해요.

권한을 처음에 탑다운으로 설계하면 실무를 반영하지 못하더라고요. 그래서 넥서스를 만들면서 권한 시스템을 세 번 정도 완전히 갈아엎었어요. 처음엔 롤별로 접근 가능한 페이지만 나눴는데, 하다 보니 읽기와 쓰기를 나눠야 했고, 거기에 더해 MCP로 무엇을 호출하고 업데이트할 수 있는지까지 구분해야 했어요. 게다가 조직도 바뀌거든요. 처음엔 세일즈와 PM이 완전히 나뉘어 있다가 지나고 나니 합쳐지면서, 나눠뒀던 권한을 다시 풀어야 했고요.

결론적으로 해결책은, 권한 관리만 담당하는 시스템을 따로 만든 거예요. 인증 시스템과 권한 관리를 별도로 만들고, 데이터 읽기 권한이나 화면 접근 가능 여부 같은 걸 다 키로 정리한 다음 그 키로 처리하는 방식이에요. 이걸 사람이 개념적으로 다 짜기는 너무 어려우니까, 컨텍스트와 요청 사항을 넣고 정리된 걸 확인한 뒤 업데이트하는 식으로 관리하고 있어요. 그리고 테스트 케이스가 중요하죠.

Q. 그렇게 정리된 내용이 쌓이는 곳이 넥서스라면, 실제로 에이전트가 작업하는 인터페이스는 어떤 건가요?

에이전트를 배포해서 사이트에 들어가면 채팅처럼 쓰는 곳이 따로 있어요. 화면이 ChatGPT처럼 생겼는데, 이건 Open WebUI(오픈웹UI, ChatGPT 같은 채팅 화면을 직접 띄울 수 있는 오픈소스 툴)라는 걸 커스텀한 거예요. 그 화면에는 에이전트가 여러 개 있어요.

요청 사항을 정리하는 에이전트, 홈페이지를 수정하는 에이전트, PM 전용 에이전트, 그리고 대표인 제 프로필 같은 것들이요. 프로필을 생성해서 띄워두면, API를 연결해 요청을 보내고 거기서 해결해 주는 구조예요.

Q. 그건 전 직원이 같이 쓰는 공용 도구라고 보면 되나요?

맞아요. 필요한 사람들한테 프로필 에이전트를 하나씩 열어줘요. 예를 들어 홈페이지 프로필에 들어가면 거기에 특화된 스킬들이 있어요. 블로그에 글을 업로드하는 스킬, 랜딩 페이지에서 특정 서비스를 바꾸는 스킬 같은 것들이요. 이 프로필로 들어가면 해당 컨텍스트와 스킬로 세팅된 에이전트로 작업하게 되고, 그 에이전트는 저희 서버 컴퓨터에서 실행돼서 결과를 내줍니다.

Q. 그러면 이 인터페이스 자체는 껍데기고, 실제 작업은 다른 곳에서 이뤄지는 거네요.

맞습니다. 넥서스에는 권한 데이터가 있고, 에이전트가 실제로 뭔가 작업하는 건 공용으로 쓸 수 있는 에이전트가 담당해요. 이렇게 해두면 장점이 있어요. 개개인이 각자 에이전트를 만들면 공동으로 고도화가 안 되거든요. 그런데 다 같이 쓸 수 있는 에이전트를 만들어두면 여기를 함께 고도화해 나갈 수 있어요. 세션 기록이 쌓이면 그걸 바탕으로 발전시킬 수 있으니까요.

Q. 여기서 말하는 고도화는, 대화를 하면 할수록 그 로그를 메모리에 저장하고 발전시킨다는 의미인가요?

그것도 있지만, 저는 좀 더 직접적인 방식을 써요. 지금 응답이 좋은지 나쁜지 평가를 할 수 있어요. 좋다 나쁘다를 클릭하면 거기에 피드백을 남길 수 있고요. 그 로그를 보고 스킬을 고도화하는 거예요. 쓰다 보면 이상하거나 불편한 게 있거든요. 그럼 그 에이전트를 아는 사람이 스킬을 손봐서 권한을 더 열어주거나 동작을 제한해서 더 잘 작동하게 만들어요. 이런 루프를 계속 돌면서 에이전트를 함께 고도화하는 시스템이 되는 거죠.

Q. 에이전트 고도화는 아무나 할 수 있는 게 아닐 것 같은데요.

맞아요. 그래서 인프라를 한 컴퓨터 안에서 돌게 해뒀어요. 에이전트를 제일 잘 아는 사람이 관리하는 컴퓨터 안에서 동작하게 해서, 어떤 동작이 일어나는지 완전히 통제 가능하게 해놓고, 피드백 남기는 건 팀원들이 할 수 있게 하자는 게 지금 생각이에요. 에이전트 자체를 설계하거나 튜닝하는 건 아직 정교하게 되어 있지 않고, 워크플로우를 어떻게 정의하느냐가 워낙 중요해서, 에이전트 구성을 정확히 아는 사람만 사실상 고도화가 가능하거든요.

Q. 그럼 '파운드리'는 어떤 역할을 하고, 왜 만들게 되신 건가요?

파운드리는 에이전트가 아주 많이 돌아가기 시작하면 관리가 안 되기 때문에 만들었어요. 하루에 런(실행)이 몇백 개씩 돌기 시작하면, 이게 잘 돌았는지 안 돌았는지, 작업이 끝났는지 아닌지 관리가 안 되거든요. 여기서 티켓은 작업 단위라고 보시면 되고, 러닝은 지금 돌고 있는 것, 베리피케이션은 작업이 실패하거나 문제가 있으면 알려주는 거예요. 게이트라는 것도 있는데, 승인이 필요한 작업을 막아주는 역할이고요.

에이전트 시스템은 특성상 계속 문제가 생겨요. 분류를 잘못하거나, 분류가 됐는데 큐(대기열)에 안 들어가거나 하는 식이죠. 그런 걸 로그로 보면서 어떤 문제가 있는지 확인하고 에이전트를 고치는, 개발자용 플랫폼이에요. 또 프로젝트별로 브랜치를 어떻게 머지(병합)할지도 관리해요. CI/CD(코드를 자동으로 통합하고 배포하는 방식) 때문에 자동 배포가 되는 경우가 있으니까요. 이런 걸 관리하는 게 파운드리예요.

Q. 이게 고도화되면 에이전트 거버넌스 관리 도구가 되겠네요.

네. 플랫폼을 선택할 때 권한 관리가 잘 돼 있느냐가 중요한 요소 중 하나예요. Open WebUI도 에이전트를 다 공개하는 게 아니라 따로 권한을 나눠서 줄 수 있게 돼 있거든요. 공용 에이전트를 쓸 때 모든 정보가 한 방으로 이어지면 안 되니까, 에이전트를 여러 개로 설계하면 권한 통제도 쉽고 쓰는 도구도 그에 맞춰 제한할 수 있어요. 결국 핵심은 에이전트가 돌아가는 실행 환경을 제어하는 거예요. 워크벤치 쪽에서는 데이터 관리만 하면 되는데, 에이전트 쪽에서는 실행 환경 제어가 중요하거든요.

Q. 각 에이전트가 접근할 수 있는 데이터 셋도 분류돼야 할 텐데, 그건 어떻게 하나요?

에이전트 레벨에서는 거의 환경 변수(프로그램이 실행될 때 참고하는 설정값)로 통제해요. 접근을 API 콜로 다 하기 때문에, 그 API 콜에 대한 키를 넣어주는 거죠. 크게 두 부류로 나뉘어요. 하나는 환경 변수 기반으로 데이터베이스부터 배포까지 다른 인프라 접근을 다 갖는 부류, 다른 하나는 넥서스에서 툴 콜링(에이전트가 특정 도구를 호출하는 것)이 제한적으로 열리는 부류예요.

앞에서 분류 에이전트 얘기를 했잖아요. 그 에이전트가 하는 일은, 티켓이 생성되면 다음 에이전트가 작업할 수 있도록 그 티켓 데이터를 업데이트하는 거예요. 이 에이전트한테는 작업에 특화된 툴만 완전히 한정해서 전용 MCP 키를 줘요. 순수하게 정확도 때문에 그렇게 하는 거예요. 인프라 자체가 완벽하게 통제되니까, 격리된 것만 넣어주면서 정확도에 초점을 맞추게 됐어요.

Q. 그럼 직원분들은 자기가 어디까지 할 수 있고 어떤 스킬을 쓸 수 있는지를 어떻게 파악하나요?

보통 저한테 뭐가 필요하다고 하면, 그 에이전트에 들어가서 직접 물어보라고 해요. 저는 각자 만들어서 할 수 있는 건 각자 하는 게 더 효율적이라고 생각하거든요. 자기가 돌아가는 걸 제일 잘 아니까요. 대신 협업을 해야 하거나, 내가 모르는 부분을 누군가에게 요청해서 작업해야 할 때 공용 에이전트를 쓰는 거죠. 공용 에이전트는 진짜 공용 업무에만 쓸 수 있어요. 개인적인 건 그냥 클로드 코드나 코덱스 같은 개인 환경에서 쓰면 되고요.

Q. 접근이 제한된 강력한 에이전트도 있을 텐데, 그런 건 어떻게 다루시나요?

버그를 고치는 CRH라는 에이전트가 있는데, 사실상 모든 권한을 다 가지고 있어요. 모든 배포와 수정에 대한 권한이요. 그런데 이걸 모두에게 열어줄 수는 없어요. 그러면 문제가 생기니까, 이 에이전트가 그 작업을 할 수 있는 유일한 관문이 되는 거예요. 위험성과 범위는 직원들도 인지하고 있어요. 이 에이전트는 다 할 수 있는 존재라서, 서로 알고 작업해야 하는 부분이 크거든요.

고객이 코멘트를 남기면 에이전트가 고친다

Q. 부서별 자동화 사례도 처음부터 공유해 주시면 좋겠어요. 어떤 것부터 보여주실 수 있을까요?

파트너 플랫폼이라는 걸 예로 들어볼게요. 기본적으로 버그 티켓이 올라오는 플랫폼이에요. 이 플랫폼에서 특이하게 만들어놓은 게, 화면의 요소를 클릭해서 선택하면 거기에 코멘트를 달 수 있다는 거예요. 그렇게 코멘트를 달면 플랫폼에 티켓이 생기고요. 그럼 아까 말씀드린 CRH 에이전트가 그 요청을 확인하고, 수정한 다음, 작업을 완료 상태로 바꿔요.

Q. 그러면 고객이 셀프로 개발을 하는 구조인 건가요?

어떻게 보면 그럴 수 있죠. 에이전트가 대신 해주니까요. 그런데 이것도 상황에 따라 달라요. 초기 단계에서는 티켓을 받으면 바로 돌려도 되는데, 중기·후기로 가면 PM이 확인해서 이 작업을 돌릴지 말지, 바로 머지할지를 판단하게 돼요.

이게 고도화되다 보니 아까 그 분류 에이전트가 필요해진 거예요. 핵심 기능 중 하나가 스크린샷이거든요. 코멘트를 누르면 넥서스에 화면이 뜨고, 에이전트가 작업을 하고 나면 이미지를 같이 올려요. 그 스크린샷을 보고 검증을 하는 거죠.

Q. 초반엔 고객이 직접 코멘트를 남기게 하다가, 중간부터 PM이나 승인 시스템이 왜 필요해지는 건가요?

저희가 외주사이다 보니 요즘 특징 중 하나가, 예전 5천만 원짜리 건과 지금 5천만 원짜리 건의 복잡도가 3배 이상 차이가 나요. 구현은 되는데 정책이 안 맞는 경우가 자주 발생하고, 비즈니스 목적과 안 맞아서 가이드를 줘야 하는 경우도 많아요. 이런 걸 PM이 판단해서 제한하거나 커트해야 하는 거죠.

그래서 기본 세팅은 프로젝트별로 티켓을 남기면 바로 수정하는 건데, 브랜치를 바꾸는 방식으로 바로 머지하지 않고 PR을 날리게 바꿀 수도 있어요. 아니면 작업을 바로 안 하고 대기 상태로 둔다거나요. 그러고 나서 PM이 댓글로 '이거 이렇게 작업해'라고 하면, 분류 에이전트가 다시 작업 대기 상태로 바꿔서 처리해요. 이런 플로우를 상황에 따라 다 제어하는 거예요. 컨설턴트가 고객사와 얘기하면서 정책을 정하는 거죠.

Q. 그러면 이건 100% 고객 셀프 개발이라기보다, 서로 협의하기 위한 도구에 가까운 거네요.

맞아요. 고객이 셀프로 개발하는 측면도 있지만, 결국엔 저희랑 소통하기 위한 도구예요. '이 화면이 이렇게 바뀌었으면 좋겠다'는 제안이나 넓은 범위의 요청도 많이 주시거든요. PR로 미리 보기를 하면서 '이대로 갑시다' 하면 배포하고, 수정이 필요하면 멈추고 다시 개발하거나 정책을 세우는 형태의 협업 도구인 거죠.

Q. 티켓 양이 많아질 때는 어떻게 하나요?

많을 때는 하루에 300~400개씩 처리할 때가 있어요. 그렇게 되면 에이전트를 돌리는 비용이 엄청 커져요. 코덱스가 프로젝트별로 빌드하고 스크린샷 찍는 것들이 문제가 되거든요. 그래서 큐 시스템을 만들게 되는데, 그게 파운드리에서 다 이뤄져요. 에이전트를 몇 개 둘지부터 시작해서, 인프라의 CPU와 램 사양에 영향을 많이 받아요. 빌드가 리소스를 많이 잡아먹으니까, 그걸 적절히 관리하려고 분류하고 격리하고 리소스를 제어하는 식으로 해요.

Q. 이런 관제 시스템 자체를 다 직접 개발하신 건가요?

제가 다 했어요. 저는 항상 좀 앞서 있어야 한다고 생각하거든요. 계속 고민하다 보니 효율이 가장 클 부분이 이쪽이라고 생각했어요. 만들어놓고 나니 문제들이 보이더라고요. 권한 관리는 어떻게 할지, 서버에서 인스턴스 관리는 어떻게 할지 같은 것들이요. 이 에이전트들을 잘 돌아가게 하는 게 굉장히 고통스러운 일이라, 저희도 몇 개월 동안 작업을 많이 했어요. 대량으로 많아지면 파운드리 같은 시스템이 정말 필요할 수밖에 없는 상황이 되고요.

세일즈부터 자동화한다

Q. 세일즈 쪽 자동화는 어떻게 진행하셨나요?

(영준 님) 세일즈도 사실 똑같아요. 하는 과정에서 계속 문제가 발생하고 그걸 해결해 나가는 과정이거든요. 처음엔 워크벤치 개념을 제시하고, 그걸 전사적으로 공유하려고 깃(Git)으로 쓰자고 했어요. 그런데 작년 말부터 클로드가 너무 좋아지면서 클로드로 다 넘어오게 됐어요. 그래서 클로드 네이티브하게 작업하는 것부터 시작해서, 이후에 생기는 세부 디테일을 잡는 작업을 했어요.

워크벤치라는 레포에서 필요한 에이전트를 몇 개 만들고, 그 에이전트로 워크플로우를 정의했어요. 그 워크플로우 단계에서 견적의 중심이 되는 MD 파일들을 중앙화하고, 그걸 모듈처럼 써서 스킬을 만든 구조라고 보시면 돼요.

Q. 스킬이 계속 늘어나면 관리가 어려워질 것 같은데요.

맞아요. LLM은 세션마다 스킬을 새로 생성하잖아요. 이걸 통제하지 않으면 나중에 스킬이 200개, 300개가 되어버려요. 그러면 이상한 스킬들이 호출되는 일이 너무 많아지고요. 그래서 스킬 구조의 디스크립션을 세밀하게 다듬는 작업을 했어요.

Q. 세일즈 워크플로우는 구체적으로 어떻게 흘러가나요?

인바운드가 들어오는 상황부터 시작해요. 저희는 요구 사항 구체화를 세일즈 단계에서부터 하거든요. 원래는 계약 후 PM이 하던 작업인데, 그때 하면 리스크 판단이 어렵다는 문제가 있었어요. 그래서 세일즈 단계에서 리스크를 줄이려고 이 작업을 앞으로 당긴 거예요.

고객사 문의를 처음 받으면, 서버 에이전트를 스폰해서 그 회사의 최근 뉴스, 매출액, 직원 수, 영업 이익 같은 걸 한꺼번에 종합해요. 이 회사가 최근에 프리시드(pre-seed, 극초기 단계 투자)를 받았다는 걸 알면, WTP(지불 의사, 고객이 낼 수 있는 가격대)를 고려하는 데 도움이 되거든요. 그리고 질문을 생성하는 게 정말 중요한데, AI가 기획 단계에서 사람이 빠뜨린 부분을 채우는 데는 훨씬 뛰어나요. 정리를 정말 잘해주죠.

Q. AI가 질문을 만들어주는 수준이 실제로 쓸 만한가요?

클로드 오퍼스 4.8이나 4.7 정도면 그런 걸 잘 뽑아줘요. 예를 들어 고객사가 앱을 원했는데 저는 당연히 웹이라고 생각하는, 그런 어긋남이 생각보다 많았거든요. 다만 계약 전 단계라 온도 관리가 중요해요. 처음부터 200개 질문을 던지면 안 되니까, 그런 조정도 필요했고요.

견적서를 생성할 때 예전엔 텍스트만 나왔다면, 지금은 IA를 뽑고 상세 기획을 해서 화면 초안까지 바로 나와요. 화면을 보면서 얘기할 수 있는 거죠. 이 작업을 하면서 넥서스의 필요성을 많이 느꼈어요.

지난번에 서장원 대표님이 인터뷰 때 지나가듯 하신 말인데 저한테는 인사이트가 됐던 게, 'DX가 안 되어 있는데 AX를 하면 안 된다'는 거였어요. 로우 데이터를 어떻게 가져오고 활용할지가 넥서스에서 이뤄지니까, 저희는 그냥 MCP로 한 번 콜하면 되거든요. 거기에 문맥과 클라이언트에 대한 합의 사항이 다 쌓이니까요.

Q. 세일즈를 이렇게 자동화하면서 실질적으로 어떤 도움이 됐나요?

일단 온보딩이 엄청나게 빨라졌어요. 신규 세일즈 직원이 오면 모르는 걸 워크벤치 레포에서 다 물어보라고 하면 되거든요. 그리고 저희가 할 수 없던 도메인을 훨씬 넓게 쓸 수 있게 됐어요.

예전에는 PM과 세일즈 사이에 보이지 않는 기싸움이 있었어요. 세일즈는 수주를 해야 하고, PM은 프로젝트를 성공적으로 완수해야 하니까요. 그러려면 PM은 리소스를 넉넉히 배분받는 게 중요하고, 세일즈는 가격을 낮춰서 계약을 성사시키는 게 중요하죠. 그런데 워크벤치를 통해 기획 단계에서 구체화를 시켜주는 에이전트가 생기니, 할 수 있는 영역이 넓어지면서 여러 업무를 통합하는 직무가 생기는 거예요.

Q. 견적을 낼 때 필요한 '맨먼스 단가'나 '이 프로젝트는 몇 개월'이라는 판단은 암묵지에 가까웠을 텐데, 이런 것까지 커버가 되나요?

이 암묵지를 설계하려고 노력을 많이 했어요. 저희가 산정하는 맨먼스 단가나 프로젝트에 대한 프로젝션이 있는데, 이 프로젝션을 사실 AI가 엄청나게 못 해요. '이건 2주짜리 작업'이라고 하는데 실제로는 두어 시간 만에 끝낼 수도 있고요. 그냥 AI에 넣었을 때는 안 나오는 것들에 대한 설계가 많이 필요했어요.

첫 번째로는 저희가 생각하는 단가 같은 걸 모으는 작업이었고, 그다음은 프롬프팅을 어떻게 하느냐의 이슈였어요. 그 하네싱(harnessing, AI가 원하는 결과를 내도록 앞단에서 조건과 맥락을 잡아주는 것)을 스킬 단계에서 넣는 작업이 있었고요. 요즘은 셀프 러닝 루프(스스로 학습하는 구조)도 시도하고 있는데, 에이전트를 구분해놓은 이유가 문맥이 분리돼야 하거나 SOP(표준 작업 절차)가 달라지는 부분이 있어서예요.

Q. 스스로 학습하는 구조는 실제로 어떻게 작동하나요?

저희가 깃을 쓰니까 오토 싱크가 돼요. 커밋 로그를 보면 1만 2천 개 정도 있고, 하루에도 몇백 개씩 커밋이 돼요. 에이전트가 파일을 수정하거나 명령어를 썼을 때 무조건 커밋을 하게 해놨거든요. 파일을 변경했다는 뜻이니까요.

그리고 그 변경된 걸 나중에 별도 에이전트가 살펴봐요. 이게 단순 변경인지, 아니면 전반적으로 일반화할 수 있는 변경인지를 세션이 끝나는 시점에 사용자에게 물어보는 걸 추가했어요. 이 SOP를 잡는 게 정말 중요해요. SOP가 잡혀 있지 않으면 리소스가 많이 들어가거든요.

영상 편집 프로그램까지 만든 이유

Q. 워크플로우 자동화 중에서 이것만큼은 소개하고 싶다 하는 게 또 있으실까요?

(김응진 대표) 영상 편집 워크플로우를 만든 게 있어요. 프로젝트를 생성하고 영상을 업로드하면, 스크립트를 자동으로 뽑아요. 그다음 구간을 선택해서 쇼츠를 만들 수도 있고, 보통은 AI 추천을 쓰면 AI가 클립 목록을 추천해줘요. 프롬프트를 넣으면 그 내용에 맞는 쇼츠 구간을 쭉 뽑아주는 거죠. 클립을 확정하면 자막을 생성하는데, 이게 저희 스타일대로 포맷을 만들어놨어요.

들어보니 자막을 바꾸고 시간을 조정하는 게 다들 많이 불편해하시더라고요. 그래서 앞의 자막 시간을 바꾸면 뒤의 것도 같이 바뀌게 하고, 자막을 화면에서 바로 수정하는 것도 되게 했어요.

Q. 캡컷 같은 툴이 아니라 자체적으로 만든 프로그램이라는 거네요.

네, 자체 프로그램이에요. 이걸 만든 이유는, 파이널 컷 같은 툴은 디테일하게 만지는 건 잘 되는데, 자막과 쇼츠 스크립트의 시간을 맞추는 게 손이 너무 많이 가거든요. 프레임별로 다 맞춰야 하니까요. 그런 걸 쉽게 하면서, 쇼츠 후보는 AI로 빨리 뽑고 싶은데 저희한테 딱 맞는 툴이 없었어요. 저희 브랜드 에셋이나 스타일을 먹이는 것도 AI로 하기엔 불편하고요. 그래서 하이브리드 형태로 만든 거예요. 실제로 마케터분이 이 작업을 하는 데 일주일 정도 걸렸던 것 같아요.

Q. 마지막에 특히 편하다고 느끼는 부분이 하나 있다고 하셨어요.

편집이 끝난 뒤 유튜브 업로드가 자동으로 되는 부분이에요. 보통 영상을 내보낸 다음 유튜브에 제목이나 설명 같은 정보를 하나하나 입력하는 게 무척 불편하잖아요. 그런데 이건 쇼츠마다 AI가 메타데이터를 대화하듯 뽑아줘요. 후보를 쭉 만들어주면 그중에 골라서 API로 쏘고, 배포 직전에 메타 태그나 디스크립션만 손보면 돼요. 확정만 누르면 유튜브에 링크로 뜨는, 딱 그 역할만 해주는 에이전트예요.

에이전시업의 미래

Q. 앞으로 에이전시업, 대행업의 미래는 어떻게 될 것 같으신가요?

에이전시업은 육성 시스템을 통해 그 회사만의 프로세스를 구성하고 거기서 효율을 만들어내던 것들이, 앞으로 에이전트화가 많이 될 것 같아요. 여기서 흥미로운 지점이 있는데, 에이전시업의 다이나믹스를 보면 대부분 B2B거든요. 그런데 탑티어 플레이어가 시장을 크게 점유하는 흐름이 나와요. 예를 들어 로펌 시장을 보면 상위 한 곳이 매출과 이익의 상당 부분을 가져가는 식이죠.

AI 시대에는 좀 다른 부분이 있어요. 하단, 즉 실무 오퍼레이션이 자동화되면서 거기서 고마진이 난다는 거예요. 원래는 고부가가치 영역에서만 마진이 났다면, 지금은 오퍼레이션 영역에서도 부가가치가 크게 날 수 있어요. 어떻게 보면 신생이거나 치고 올라가는 에이전시한테 큰 기회가 될 수 있다고 봐요. 그래서 앞으로 이 둘이 경쟁하거나 합쳐질 거라고 보고 있어요.

Q. 고객사의 수준이 많이 올라와서, 저부가 개발은 직접 다 할 수 있는 시대가 된 것 같아요. 리트머스는 이걸 어떻게 대응하려고 하시나요?

거스를 수 없는 흐름이라고 생각해요. 정확히 말하면 저희의 주 수익처가 점점 LLM한테 잠식되니까, 더 높은 티어로 올라가야 하는 건 계속될 거예요. 그런데 반대로 말하면, 그 시차를 저희가 활용할 수 있는 것도 기회거든요. LLM이 새로 올라왔을 때 그걸 완전히 레버리지하는 경험은 일반 회사에서는 하기 어려운데, 저희는 그것만 하잖아요.

결국 대비하는 방향은 도메인 특화예요. 저희가 중요하게 보는 도메인은 기획이거든요. 기획과 사업 전략을 연결해서 솔루션을 설계하는 이 부분이 중요하다고 봐요. 그래서 지금은 세일즈와 PM이 나뉜 것처럼 보일 수 있지만, 결론적으로는 다 '컨설턴트'라는 새로운 직군이 돼야 한다고 생각해요. 개발도 알아야 하고 세일즈도 잘해야 하죠. 그게 곧 솔루션 설계 능력이니까요. 이 부분에 계속 특화해 나가야 한다고 생각하고 있습니다.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]