채팅 인터페이스에서 에이전트 플랫폼으로
간단한 AI 채팅 앱에서 자율 에이전트 플랫폼으로의 아키텍처 진화 — 그것을 형성한 결정들을 통해 이야기합니다.
모든 플랫폼은 기능으로 시작된다
Google은 검색 상자로 시작했습니다. Slack은 채팅룸으로 시작했습니다. AWS는 서버 임대 서비스로 시작했습니다.
LikeClaw는 채팅 인터페이스로 시작했습니다. 메시지를 입력하면 AI가 응답했습니다. 그게 전부였습니다.
84일 후, 우리는 샌드박스 실행, 다중 모델 지원, 기술 마켓플레이스, 백그라운드 작업 스케줄링, 자가 치유 CI 파이프라인을 갖춘 자율 에이전트 플랫폼이 되었습니다.
이것이 바로 그러한 진화의 이야기입니다 — 계획된 로드맵이 아니라, 우리가 몰랐던 문을 열어주는 일련의 아키텍처 결정들로 이루어졌습니다.
1단계: 채팅 (11월 21-22일)
첫 이틀 동안 채팅 인터페이스가 만들어졌습니다. 장난감이 아닌, 실제 채팅 시스템입니다:
- 세션 관리 (여러 대화, 각각 보존됨)
- 스트리밍 응답 (토큰이 실시간으로 나타남)
- 에이전트 전환 (다양한 작업을 위한 다양한 AI 성격)
- 파일 시스템 통합 (AI가 파일을 읽고 쓸 수 있음)
이 단계에서 LikeClaw는 더 나은 ChatGPT였습니다. 동일한 상호작용 모델 — 인간이 질문하고, AI가 대답하는 — 하지만 지속적인 파일과 전문화된 에이전트를 갖추고 있었습니다.
이 기반이 이후 모든 기능에 효과적이었던 이유: 채팅 레이어와 에이전트 레이어의 분리. 채팅 UI는 에이전트가 뒤에서 무엇을 하고 있는지 알지 못했으며, 신경 쓰지도 않았습니다. 그냥 메시지를 표시했을 뿐입니다. 이는 우리가 채팅 코드를 건드리지 않고도 에이전트를 극적으로 더 유능하게 만들 수 있음을 의미했습니다.
2단계: 작업 공간 (11월 22-28일)
1주가 끝날 무렵, 우리는 작업 공간을 갖추게 되었습니다. 작업 공간은 지속적인 환경입니다: 대화, 파일, 에이전트, 설정이 모두 함께 그룹화됩니다.
이것은 간단하게 들릴 수 있습니다. 하지만 실제로는 프로젝트의 가장 중요한 아키텍처 결정이었습니다.
작업 공간이 없으면 모든 대화는 일시적입니다. AI는 세션 간의 맥락을 기억하지 못합니다. 파일은 정리되지 않습니다. “내가 작업 중인 프로젝트"라는 개념이 없습니다.
작업 공간이 있으면 사용자는 지속적인 맥락을 생성합니다. “마케팅” 작업 공간에는 마케팅 파일, 마케팅 에이전트 및 마케팅 대화 기록이 있습니다. “개발” 작업 공간에는 코드 파일, 코딩 에이전트 및 기술 대화가 있습니다. 각 작업 공간은 하나의 세계입니다.
핵심 통찰: 작업 공간이 맥락의 단위입니다. 나머지 모든 것 — 에이전트, 파일, 일정, 설정 — 은 작업 공간 안에 존재합니다. 이는 이후 기능의 범위를 쉽게 정의할 수 있게 했습니다. “일정 추가"는 “작업 공간별 일정 추가"로 바뀌었습니다. “설정 추가"는 “작업 공간별 설정 추가"로 바뀌었습니다. 작업 공간 경계가 복잡성을 포함했습니다.
3단계: 다중 에이전트 (12월 12-27일)
두 번째 달에는 에이전트 폭발이 일어났습니다. 하나의 AI 성격 대신, 우리는 전문화된 에이전트를 만들었습니다:
- 채팅 에이전트: 파일 인식이 가능한 일반 대화
- UX 에이전트: 연구를 위한 Perplexity 통합을 갖춘 디자인 중심
- PM 에이전트: 작업 위임 기능을 갖춘 프로젝트 관리
- 스튜디오 에이전트: 이미지 생성 도구를 갖춘 창의적 작업
- 이미지 마스터: 시각 콘텐츠 생성 전문
각 에이전트는 고유한 시스템 프롬프트, 도구 및 성격을 가지고 있습니다. 채팅 UI 구성 요소는 변경되지 않았습니다 — 여전히 메시지만 표시합니다. 하지만 그 뒤의 에이전트들은 극적으로 더 유능해졌습니다.
아키텍처의 승리: 에이전트는 코드가 아닌 구성입니다. 새로운 에이전트를 추가하는 데 플랫폼을 변경할 필요가 없습니다. 시스템 프롬프트를 정의하고, 도구를 선택하고, 행동을 구성하면 됩니다. 우리는 에이전트를 데이터베이스에 저장합니다. 사용자는 결국 자신의 에이전트를 만들 수 있습니다. 플랫폼은 얼마나 많은 에이전트가 존재하는지 또는 그들이 무엇을 하는지 신경 쓰지 않습니다.
4단계: 자율 (12월 2일 - 1월 31일)
여기서부터 흥미로워졌습니다. 이전 단계는 모두 사람이 키보드에 앉아 AI가 작업하는 것을 지켜보고 있다는 가정을 했습니다. 4단계에서는 그 가정을 제거했습니다.
일정 관리가 먼저 도입되었습니다. 사용자는 일정에 따라 실행되는 작업을 정의합니다. AI는 깨어나고, 작업 공간을 로드하고, 작업을 실행하고, 결과를 저장하고, 사용자에게 알립니다. 사람은 없습니다.
백그라운드 작업이 다음으로 도입되었습니다. 대화 중에 AI는 장기 실행 작업을 백그라운드 에이전트에 위임할 수 있습니다. “이 코드베이스 분석"은 20분이 걸릴 수 있습니다. 사용자는 기다릴 필요가 없습니다. 백그라운드 에이전트는 자신의 E2B 샌드박스에서 실행되며, 결과는 준비되면 나타납니다.
이벤트 기반 아키텍처가 이를 연결했습니다. 모든 행동 — 작업 완료, 파일 생성, 에이전트 종료 — 는 이벤트를 생성합니다. 이벤트는 사용자의 인박스에 나타납니다. 이벤트는 알림을 트리거합니다. 이벤트는 자율 에이전트와 이를 관리하는 인간 간의 연결 고리입니다.
어려운 부분은 기능을 만드는 것이 아니었습니다. 그것은 가정을 재고하는 것이었습니다. 사용자가 있을 때는 오류를 대화 상자에 표시할 수 있습니다. 사용자가 없을 때는 오류를 캡처하고, 기록하고, 나중에 표시해야 합니다. 사용자가 지켜보고 있을 때는 부분적인 진행 상황이 유용합니다. 아무도 지켜보지 않을 때는 최종 결과만 중요합니다.
5단계: 플랫폼 (2월 1-13일)
최종 진화: 우리가 제어하는 제품에서 스스로 확장하는 플랫폼으로.
E2B 샌드박스는 실행을 안전하고 확장 가능하게 만들었습니다. 모든 작업은 격리된 상태에서 실행됩니다. 우리는 서로 간섭하지 않고 백 개의 작업을 동시에 실행할 수 있습니다.
기술 마켓플레이스는 사용자(그리고 결국 제3자)가 재사용 가능한 자동화 패키지를 만들 수 있게 해줍니다. 기술은 게시 전에 보안 검토를 받습니다 — 문서화된 보안 문제가 있는 공개 마켓플레이스와는 다릅니다.
자가 치유 CI는 플랫폼이 스스로 버그를 수정한다는 것을 의미합니다. Claude는 GitHub 문제를 읽고, 수정 사항을 작성하고, PR을 생성하며, 코드를 검토합니다. 개발 프로세스는 부분적으로 자동화됩니다.
평가 프레임워크는 에이전트 품질을 체계적으로 측정합니다. 우리는 에이전트가 잘 작동하기를 바라는 것이 아니라 — 수십 가지 시나리오에서 측정하고 품질을 추적합니다.
진화 뒤의 패턴
돌아보면, 패턴은 분명합니다: 각 단계는 “AI 에이전트"의 경계를 확장했습니다.
1단계: AI는 인간 입력에 응답합니다.
2단계: AI는 지속적인 맥락 내에서 작업합니다.
3단계: AI는 다양한 작업을 위해 전문화됩니다.
4단계: AI는 인간 감독 없이 작업합니다.
5단계: AI는 플랫폼 자체를 확장합니다.
이 단계들 중 어느 것도 이전 단계들을 다시 작성할 필요가 없었습니다. 1주차의 채팅 UI는 여전히 작동합니다. 2주차의 작업 공간 모델은 여전히 모든 것을 정리합니다. 2개월 차의 에이전트 시스템은 여전히 모든 상호작용을 지원합니다.
좋은 아키텍처는 미래를 예측하는 것이 아닙니다. 아직 상상하지 못한 미래를 지원할 수 있는 기반을 만드는 것입니다.
우리는 채팅 인터페이스로 시작했습니다. 플랫폼으로 끝났습니다. 그리고 첫날에 구축한 기반은 여전히 모든 것을 지탱하고 있습니다.
플랫폼이 되는 다섯 단계
- 1
1단계: 채팅
1주차. 사용자들이 AI와 대화해. AI가 응답해. 핵심 상호작용 루프. 간단하지만 필수적이야.
- 2
2단계: 작업 공간
2주차. 사용자들은 지속적인 파일이 있는 작업 공간으로 대화를 정리합니다. 컨텍스트가 지속적으로 유지됩니다.
- 3
3단계: 다중 에이전트
4주차. 다양한 작업을 위한 다양한 에이전트. 코딩 에이전트. 창의적인 에이전트. PM 에이전트. 전문화.
- 4
4단계: 자율적
6주차. 예정된 작업. 백그라운드 실행. AI는 사용자가 없을 때도 작동합니다.
- 5
단계 5: 플랫폼
10주차. 샌드박스 실행. 기술 마켓플레이스. 셀프 힐링 CI. 제품이 스스로 확장됩니다.
플랫폼 진화에 대한 질문
처음부터 모든 다섯 단계를 계획했나요?
우리는 처음 세 단계를 계획했어요. 4단계와 5단계는 사용자 요구와 기술적 기회에서 비롯되었죠. 핵심은 1-3단계에서 4-5단계를 재작성 없이 흡수할 수 있는 아키텍처를 구축하는 것이었어요.
가장 힘든 전환은 무엇이었나요?
3단계에서 4단계로 — 상호작용형에서 자율형으로. 상호작용형 시스템은 사용자가 오류를 처리하고 결정을 내릴 것으로 가정합니다. 자율형 시스템은 모든 것을 스스로 처리해야 합니다. 이를 위해 오류 처리, 상태 관리 및 결과 전달 방식을 재고해야 했습니다.
아키텍처의 발전이 끝났나요?
전혀 그렇지 않아. 우리는 여러 에이전트가 복잡한 작업을 조정하는 멀티 에이전트 협업을 진행 중이야. 플랫폼 아키텍처는 계속 발전하도록 설계되어 있어.