NOTE: K-ON! 아니고, Kaon입니다.
Kaon은 Pi 코딩 에이전트의 얇은 web shell이다. 이름도 중간자 Pion 다음으로 발견된 입자 Kaon에서 따왔다.
이미 Cluade Code, Codex, Antigravity, Cursor가 데스크탑 에이전트 앱을 내놓았는데, 굳이 기능도 부족한 제품을 만들어야할까? Pi 에이전트 생태계의 다른 데스크탑용 도구도 있을텐데, 앞으로도 계속 좋은 도구가 나올텐데, 굳이? SW 개발이 쉬워진 시대에 불필요한 도구를 하나 더 늘리는 것 아닌가?
Claude Code가 처음 출시되었을때, 왜 만들었는지 알겠더라. 당시 Visual Studio Code에서 fork한 Cursor가 인기를 끌었지만, 모두가 IDE를 Cursor로 변경할 수 있는 것은 아니었다. IDE 중립적인 코딩 에이전트. 정말 똑똑한 선택이라 생각했다.
(뜬금없겠지만 언젠가 AI로 만든 인간이 이해할 수 없는 프로그래밍 언어로 프로그래밍하는 날이 올지도 모르겠다. 필시 이런 생각은 장강명 작가의 “먼저 온 미래"를 읽고 있는 영향이다.)
과학.공학 분야 컴퓨팅은 기능보다는 안정성을 유지하길 원한다. 그러다보니 컴퓨팅 환경을 한 번 구성하면 수 년간 업그레이드 없이 유지하는 경우가 많다. 거기에 네트워크 제약은 얼마나 많은지. LLM 모델도 허용된 것만 써야할 수 있다(아예 쓸 수 없는 환경은 논외로 하자). 제한된 상황에서 동작하는 무언가가 있다면 쓸모가 있을 것 같다. Pi를 처음 봤을때 단순함이 좋았다. 특수한 목적으로 구성하기에 적합할 것 같다. 대부분의 작업은 Claude Code나 Codex로 하고, 일부만 Kaon+Pi로 넘기는 시나리오.
좀 더 생각해본다면, 연구과정에서 파생되는 수많은 artifacts를 다루려면 웹 환경이 더 좋겠다. 그래서 Kaon과 Pi의 관계를 Jupyter와 Jupyter Kernel 관계로 봤다. 그리고 SW개발과 다르게 연구는 하나의 Git 저장소(프로젝트)만 다루기는 어렵다. 여럿이 공유하는 저장소도 있겠고, 연구원 혼자서 실험하면서 만든 저장소들도 있겠다. 이런 환경에서 쓸 수 있는 도구가 되면 좋겠다.
이제 어떤 것을 만들든 70% - 80%는 진짜 빠르게 만든다. 초기 구상이 딱 그 정도 이기도 하고. 만들다보면 처음 설계를 변경해야하는 경우도 있다. Kaon도 그렇다. 개발 방향도 만들면서 정리했지, 처음에는 모든 것이 모호했다. 딱 Jupyter와 Jupyter Kernel까지만 생각했다. 그러다보니 Jupyter처럼 Python으로 개발했는데, 방향성을 다시 잡으면서 배포의 편의성을 위해서 Go로 재구현했다. 광을 내려면(polishing) 직접 사용해보고 계속 개선해야하는데 이것도 참 품이 많이 든다. 나머지를 어떻게 채울 것인가.