주말동안 머릿속에 떠오른 컨셉이 있어서 재밌게 AI coding CLI를 하나 만들어보고 있습니다. 아래 이미지가 시작시 인터페이스입니다. 이름하여 DDUDU DDUDU~ 혼자서 흥얼거리다가 생각났어요.
다들 알다싶이 모델 성능만큼 그 모델을 감싸는 하네스의 중요성은 이제 많은 분들이 알고 계실 거라 생각합니다. 같은 모델이라도 어떤 하네스 위에서 돌리느냐에 따라 결과가 꽤 달라지는데, 그 설계 쪽에 더 초점을 두고 깎아보고 싶었습니다. 원래는 기존 tool에 OMO/OMC처럼 플러그인을 추가하는 방식으로 쓰고 있었는데, 어느 순간 처음부터 만들어보면 어떨까 싶었습니다. Pi처럼 커스텀 영역이 열려있는 아이디어를 기반으로 조립해볼까도 했는데, 공부 겸 저만의 UI를 가지고 해보고 싶기도 했습니다. 떠오른 컨셉에서 디자인이 제일 중요했기에 결국 처음부터 리서치하면서 직접 만들어보는 쪽으로 방향을 틀었습니다.
최근 OpenCode와 OMO의 사용 경험이 꽤 좋았고, 그런 것들이 왜 좋았는지를 분해해서 처음부터 녹여보고 싶었습니다. 지금은 제가 이미 결제해둔 서비스가 많아(Claude, Codex, Gemini) 기존 로컬 credential을 재사용하면서 그 위에 제가 원하는 맥락 관리와 tool 조합을 올리는 구조입니다. 이미 공룡과도 같은 서비스들이 쌓아둔 인프라와 그들의 설계 지식 기반에서 커스텀에 가까운 작업(심지어 제작 작업도 Codex로 하고 있고)이라 from scratch라고 하기엔 좀 그렇지만, 그 조각들을 어떤 구조로 엮을지는 직접 해봐야 감이 오는 영역이라 시작했습니다.
이미 있는 기능들이고 많은 분들이 체감하고 계신 내용이겠지만, 처음부터 하나씩 만들다 보니 이런 것들이 다 고려 요소더라고요. 정리하면 이렇습니다.
[1] 모델 호출과 라우팅. 경험적으로 아시다싶이 프로바이더마다 잘하는 영역이 다릅니다. 복잡한 판단이 필요한 오케스트레이션에는 강한 모델을, 단순 반복 실행에는 빠른 모델을, 설계나 디자인 판단에는 또 다른 모델을 쓰는 식으로 모드를 나누고 작업에 따라 라우팅하는 구조를 시도하고 있습니다.
[2] Tool 구성. 여러 coding agent들을 뜯어보면 tool 조합이 정말 다양합니다. 파일 I/O나 셸 실행 같은 기본기부터 코드베이스 검색, 심볼 탐색, 다른 에이전트에게 작업 위임까지 범위가 넓은데, 어떤 tool이 왜 필요한지를 하나씩 뜯어보게 됩니다. 어디까지를 빌트인으로 넣고 어디부터 MCP 같은 확장으로 뺄지도 계속 조율하고 있습니다.
[3] Context 관리. 제한된 컨텍스트 창에 지금 필요한 정보만 채우는 문제입니다. 대화 전체를 다 넣으면 될 것 같지만 불필요한 맥락이 쌓이면 오히려 성능이 떨어집니다. 특히 저는 이전부터 context compaction 쪽을 관심있게 보고 있는데, 언제 얼마나 압축할지, 압축 후에도 사용자가 흐름을 잃지 않으려면 어떻게 해야 하는지 같은 부분을 고민하고 있습니다.
[4] 세션과 상태 유지. 사람은 아까 하던 작업을 자연스럽게 이어가지만 모델 입장에서는 매 턴이 완전히 새로운 요청입니다. 세션을 재개하거나 분기하거나, 긴 세션을 요약해서 다음 작업으로 넘기는 흐름이 필요합니다. 위임한 작업은 git worktree로 격리해서 메인 작업을 건드리지 않게 하고, 오래 걸리는 작업은 백그라운드로 빼서 메인 흐름을 막지 않게 하는 것도 여기서 풀고 있습니다.
[5] 검증과 복구. 코드를 한 번에 잘 쓰는 것보다, 쓴 다음에 검증하고 실패하면 고치고 필요하면 다른 에이전트에게 넘기고, 통과하면 실제 워크스페이스에 apply하는 전체 루프를 만드는 쪽에 시간을 쓰고 있습니다. 검증을 통과한 결과는 메모리에 남겨서 비슷한 작업이 나왔을 때 재활용할 수 있게 하는 흐름도 시도 중입니다.
[6] 메모리. 현재 세션의 작업 맥락, 과거 세션에서 배운 것, 코드베이스에 대한 구조적 지식, 반복 사용하는 규칙과 절차를 나눠서 각각 유지 기간과 저장 방식을 다르게 가져가면 어떨까 싶어서 그 구조를 실험하고 있습니다. 아직 정답을 찾았다기보다는 이런저런 조합을 시도해보고 있는 단계입니다.
[7] 권한과 신뢰 경계. 에이전트에게 얼마나 자율성을 줄 것인가의 문제입니다. 모든 걸 다 허용하면 위험하고, 매번 물어보면 느려집니다. tool별로 허용/확인/차단을 세분화하고, 전체 권한 수준을 단계별로 전환할 수 있는 구조를 잡고 있습니다. (근데 솔직히 이건 AI가 권장해주는 방식에서 크게는 벗어나지 못하고 있어요.)
[8] UI/UX. 에이전트가 지금 뭘 하고 있는지, 백그라운드 작업 상태, 외부 tool 연결 상태가 한눈에 보여야 합니다. 처음에 TUI를 Ink로 만들었는데 너무 무거워서 Rust 기반 Ratatui로 바꿨고, IME나 사용성 등 이게 정말 좋은 선택이었습니다. (이걸로 알게 된 점은 Opencode의 강점은 단순히 그들의 설계말고도 Opentui를 잘 만들었다는 점) 개인적으로 TUI를 좋아하기도 하고 터미널 안에서의 깔끔한 디자인과 가독성에 집착하는 편이라, 정보를 색과 배치로 최대한 빠르게 혼동 없이 해석할 수 있게 작업에 집중하고 있습니다. 이건 기능과 취향의 영역을 동시에 만족하는 부분이라 제일 열심히 시간을 쓰고 있습니다.
이것 외에도 시스템 전체의 데이터 구조나 슬래시 명령어나 알림 표시 방법 등 만들수록 고려해야 할 게 계속 나오고 있어 재밌네요. 아직 기본 기능 수정부터 하고 있는 단계이고, 기존 하네스들보다 좀 더 좋은 결과가 나오면 한 번 또 공유해보겠습니다.
목표는 제 하네스를 기반으로 제 하네스를 강화하는 그 날과 모든 이들이 쉽게 본인 CLI툴을 만들 수 있는 Pi보다 나은 Modular Harness 구축까지.
github.com/subinium/ddududdudu
