요즘 코딩 에이전트를 하나만 쓰는 분은 드물 거예요. 터미널에서는 Claude Code, 에디터에서는 Cursor를 쓰고, 가끔은 Codex나 Gemini CLI도 번갈아 써요. 그러다 보면 꼭 부딪히는 벽이 있거든요. 에이전트끼리 서로 뭘 알고 있는지 전혀 모른다는 거예요. 오늘 소개할 Jotbus가 바로 이 문제를 겨냥한 프로젝트인데요. 스스로를 “코딩 에이전트를 위한 공유 암호화 스크래치패드”라고 소개해요. 쉽게 말하면 여러 에이전트와 사람이 같이 읽고 쓰는 암호화된 공용 메모장이에요.
스크래치패드가 왜 필요할까요?
스크래치패드는 수학 문제를 풀 때 옆에 두고 계산을 끄적이는 연습장 같은 거예요. 에이전트에게 이게 필요한 건 LLM이 동작하는 방식 때문이에요. 모델은 컨텍스트 윈도우 안에 있는 것만 알아요. 컨텍스트 윈도우는 모델이 한 번에 볼 수 있는 글의 범위예요. 세션이 끝나거나 대화가 길어져서 앞부분이 잘려 나가면, 아까 열심히 파악한 내용도 같이 사라지거든요.
그래서 다들 나름의 우회책을 쓰고 있죠. 프로젝트 루트에 CLAUDE.md나 AGENTS.md를 두고 규칙을 적어두거나, “작업 끝나면 NOTES.md에 진행 상황 정리해줘”라고 시키는 식이에요. 그런데 이 방식에는 아쉬운 점이 몇 가지 있어요.
- 메모가 리포지토리에 커밋되면 팀 히스토리에 잡다한 작업 기록이 섞여요.
- 노트북의 에이전트와 원격 서버의 에이전트처럼 머신이 다르면 공유가 안 돼요.
- 디버깅하다 나온 내부 URL이나 설정값 같은 민감한 내용이 평문으로 남아요.
이런 장면에서 빛을 발해요
예를 들어 Claude Code로 버그를 추적하다가 “원인은 캐시 무효화 타이밍 같음, DB 쿼리 쪽은 확인했는데 문제없음”까지 알아냈다고 해볼게요. 나중에 다른 세션이나 다른 에이전트로 이어서 작업하려면, 보통은 사람이 이 맥락을 다시 설명해줘야 하잖아요. 공유 스크래치패드가 있으면 첫 번째 에이전트가 거기에 적어두고, 다음 에이전트는 시작할 때 그걸 읽고 바로 이어갈 수 있어요. 일종의 업무 인수인계 노트인 셈이죠. 사람도 같은 메모장에 “이 디렉터리는 건드리지 마” 같은 지시를 남겨둘 수 있고요.
도입 전에 꼭 따져볼 것: 암호화와 신뢰
“암호화”라는 단어가 붙었다고 보안 수준이 다 같은 건 아니에요. 체크할 포인트를 정리해보면 이래요.
1. 어디서 암호화하나요? 서버에 저장할 때만 암호화하는 방식(at-rest)이면 서비스 운영자는 내용을 볼 수 있어요. 반대로 클라이언트에서 암호화해서 서버에는 암호문만 남기는 방식(종단 간 암호화, E2E)이면 운영자도 못 봐요. 둘은 신뢰 모델이 완전히 달라요.
2. 키는 어디 있나요? 에이전트가 메모를 읽으려면 결국 에이전트가 도는 환경에 복호화 키가 있어야 해요. 그 머신이 털리면 메모도 같이 털린다는 뜻이죠.
3. 프롬프트 인젝션 통로가 되진 않을까요? 이게 제일 흥미로운 부분인데요. 프롬프트 인젝션은 모델이 읽는 텍스트에 악의적인 지시를 숨겨서 모델을 조종하는 공격이에요. 공유 메모장에서는 한 에이전트가 쓴 글을 다른 에이전트가 “참고 자료”로 읽잖아요. 그래서 오염된 웹페이지를 읽은 에이전트가 이상한 지시를 메모에 옮겨 적으면, 다음 에이전트가 그걸 따를 수도 있어요. 암호화는 외부 유출을 막아줄 뿐, 이런 내부 오염까지 막아주진 않거든요.
Jotbus가 정확히 어떤 방식으로 암호화하는지, 에이전트와는 어떻게 연동되는지는 공식 사이트에서 직접 확인해보세요.
업계 흐름 속에서 보면
에이전트의 “기억” 문제는 요즘 가장 뜨거운 주제 중 하나예요. Letta(구 MemGPT)나 mem0처럼 장기 기억을 전문으로 다루는 프로젝트가 있고, MCP로 메모리 서버를 붙이는 방식도 흔해졌어요. MCP(Model Context Protocol)는 에이전트를 외부 도구에 연결하는 표준 규격이에요. 다만 이런 도구들은 주로 에이전트 하나의 기억을 늘려줘요. Jotbus는 여러 에이전트 사이의 공유와 보안에 초점을 맞췄다는 게 차별점이에요. Notion이나 Gist에 메모를 붙여넣는 것과 비교하면, 처음부터 에이전트가 읽고 쓰는 걸 전제로 설계됐다는 점도 다르고요.
한국 개발자에게 주는 시사점
회사에서 쓰려면 보안 정책부터 확인해야 해요. 코드 관련 맥락이 외부 SaaS로 나가는 거라서, 망분리 환경이나 금융권이라면 보안팀 검토 없이 쓰기는 어려울 거예요. 대신 개인 프로젝트나 사이드 프로젝트에서는 부담 없이 실험해볼 만해요.
도구를 안 쓰더라도 아이디어 자체는 바로 가져다 쓸 수 있어요. .gitignore에 추가한 로컬 노트 폴더를 하나 만들어 두세요. 그리고 AGENTS.md에 “작업 시작 전에 노트를 읽고, 끝나면 결론과 남은 할 일을 적어라”라는 규칙 하나만 넣어 보세요. 그것만으로도 에이전트 사이의 인수인계 품질이 확 달라지거든요.
마무리
에이전트를 여러 개 쓸수록 모델 성능만큼이나 중요한 게 에이전트 사이에서 맥락을 안전하게 넘기는 방법이에요. 여러분은 여러 에이전트를 쓸 때 맥락을 어떻게 넘기고 계신가요? 공유 메모장에 민감한 맥락을 어디까지 맡겨도 괜찮다고 보시나요?
🔗 출처: Hacker News