“소프트웨어 개발자로서 솔직히 말하자면, 난 건축가를 질투한다”라고 Every의 CEO Dan Shipper는 고백합니다. 건축가는 완벽한 청사진을 그리고 마천루를 짓지만, 프로그래머인 자신은 청사진이 완성되기 전에 파고들어가 5층쯤 올라갔을 때는 이미 엉망이 되어 있다는 거죠.
그런데 AI가 등장하면서 완전히 다른 방식이 가능해졌습니다. 마천루를 짓는 게 아니라 정원을 가꾸는 방식이요.
Every가 발표한 ‘에이전트 네이티브 아키텍처’ 가이드는 Claude Code를 사용하면서 발견한 놀라운 사실에서 출발합니다. 정말 훌륭한 코딩 에이전트는 사실 범용 에이전트라는 거예요. 코드베이스를 리팩토링하는 똑같은 방식으로 파일을 정리하고, 독서 목록을 관리하고, 워크플로를 자동화할 수 있다는 겁니다. 이 통찰을 바탕으로 Every는 회사 전체의 소프트웨어 전략을 이 방향으로 선회했어요.
출처: Agent-native Architectures: How to Build Apps After Code Ends – Every
핵심은 간단합니다: 코드 대신 에이전트
에이전트 네이티브 앱의 핵심은 코드가 아니라 에이전트예요. Dan Shipper는 이걸 “트렌치코트를 입은 Claude Code”라고 표현합니다. 앱의 각 기능은 “이 단계들을 따라해”가 아니라 “이 결과를 달성해줘”라고 말하는 프롬프트죠. 어떻게 할지는 에이전트가 알아서 결정합니다.
개발자는 “어떻게”를 코딩하는 대신 “무엇을”만 정의하면 돼요. 그래서 앱을 만들고 고치고 바꾸는 게 훨씬 빨라집니다. 더 흥미로운 건, 사용자도 프롬프트만 바꾸면 앱 동작을 바꿀 수 있다는 거예요. 소프트웨어가 소수의 전문가만 만들 수 있는 게 아니라 우리가 함께 만드는 것이 되는 거죠.
이 아키텍처는 다섯 가지 원칙으로 정리됩니다.
1. Parity(동등성): 사용자가 UI로 할 수 있는 건 에이전트도 할 수 있어야 해요. 노트 앱 사용자가 “미팅 요약한 노트 만들고 긴급 태그 달아줘”라고 요청했는데 UI로는 가능하지만 에이전트는 막힌다면? 그건 실패입니다. 이게 기본 중의 기본이에요.
2. Granularity(세분성): 도구는 레고 블록처럼 작아야 합니다. analyze_and_organize_files처럼 판단 로직을 묶어넣으면 안 돼요. 대신 read_file, write_file, move_file 같은 기본 블록을 주고, 에이전트가 프롬프트에 따라 조합하게 합니다. 동작을 바꾸고 싶으면? 코드를 고치는 게 아니라 프롬프트만 수정하면 됩니다.
3. Composability(조합성): 작은 도구들과 동등성이 있으면 새 기능을 프롬프트만으로 만들 수 있어요. “이번 주 수정된 파일 검토하고 주요 변경사항 요약한 다음, 미완료 항목과 다가오는 마감일 보고 다음 주 우선순위 세 가지 제안해줘”라고 쓰면 끝. 에이전트가 list_files, read_file 쓰면서 알아서 해냅니다.
4. Emergent Capability(창발적 능력): 에이전트는 당신이 만들지 않은 기능도 해냅니다. 사용자가 “미팅 노트랑 할일 목록 비교해서 내가 약속했는데 일정에 안 넣은 거 찾아줘”라고 하면, 당신이 ‘약속 추적’ 기능을 안 만들었어도 에이전트가 노트랑 할일을 읽을 수만 있으면 해내요. 이게 잠재적 수요를 드러냅니다. 사용자가 뭘 원할지 미리 상상할 필요가 없어요. 그냥 관찰하면 되죠.
5. Improvement Over Time(시간에 따른 개선): 전통적 소프트웨어와 달리 에이전트 네이티브 앱은 코드를 새로 배포하지 않아도 나아집니다. 컨텍스트 파일로 상태가 세션 간에 유지되고, 개발자는 프롬프트만 업데이트해서 모든 사용자에게 배포하며, 사용자는 자기 워크플로에 맞게 프롬프트를 고칠 수 있어요.
왜 파일 시스템일까요?
여기서 재미있는 발견이 하나 나옵니다. 에이전트는 파일에 능숙하다는 거예요. Claude Code가 잘 작동하는 이유는 bash + 파일시스템이 역사상 가장 검증된 에이전트 인터페이스이기 때문입니다.
생각해보세요. 에이전트는 이미 cat, grep, mv, mkdir 같은 명령어를 알고 있어요. 파일 작업은 에이전트가 이미 유창하게 다루는 언어죠. 게다가 파일은 투명합니다. 사용자가 에이전트가 만든 걸 직접 보고, 편집하고, 삭제할 수 있어요. 블랙박스가 아니죠. 내보내기도 쉽고, 백업도 쉽고, 사용자가 데이터를 소유합니다. iPhone에서 iCloud 쓰면 모든 기기가 같은 파일시스템을 공유해서 에이전트 작업이 어디서나 나타나요. 서버 구축 없이요.
가이드는 이런 원칙을 제시합니다. “에이전트가 추론할 수 있는 걸 위해 설계하세요. 가장 좋은 기준은 인간에게 의미 있는 것입니다.” /projects/acme/notes/ 같은 폴더 구조는 SELECT * FROM notes WHERE project_id = 123 같은 SQL 쿼리보다 자기 설명적이에요. 인간이 폴더 구조를 보고 무슨 일이 일어나는지 이해할 수 있다면, 에이전트도 아마 이해할 수 있습니다.
특히 흥미로운 건 context.md 패턴이에요. 에이전트가 매 세션 시작할 때 읽고, 상태가 바뀌면 업데이트하는 파일인데, 코드 변경 없이 에이전트의 ‘작업 메모리’ 역할을 합니다.
# Context
## 나는 누구인가
Every 앱의 독서 보조
## 이 사용자에 대해 아는 것
- 군사사와 러시아 문학에 관심
- 간결한 분석 선호
- 현재 『전쟁과 평화』 읽는 중
## 무엇이 존재하는가
- /notes에 노트 12개
- 진행 중인 프로젝트 3개
## 최근 활동
- 사용자가 "프로젝트 킥오프" 노트 생성 (2시간 전)
## 내 가이드라인
- 읽고 있는 책 스포일러 금지
- 사용자 관심사로 인사이트 개인화간단하지만 강력하죠.
도구 설계의 철학
순수한 기본 도구(bash, 파일 작업)로 시작하세요. 이게 아키텍처가 작동한다는 걸 증명하고, 에이전트가 진짜 필요로 하는 게 뭔지 보여줍니다.
패턴이 보이면 그때 도메인별 도구를 추가해요. 예를 들어 create_note 도구는 에이전트에게 “노트”가 뭔지 가르쳐주고, 자주 쓰는 작업을 빠르게 만들어줍니다. 하지만 중요한 건 이거예요. 도메인 도구는 바로가기일 뿐, 문지기가 되면 안 됩니다. 기본 도구를 계속 사용 가능하게 둬야 해요. 그래야 에이전트가 예상 못한 상황에서도 기본 블록으로 돌아가서 해결할 수 있거든요.
도구 설계 철학을 한 문장으로 정리하면: “판단은 프롬프트에, 실행은 도구에.” 도구는 한 가지 행동을 나타내되, 그걸 할지 말지 결정하는 건 에이전트의 몫입니다.
모바일은 특별한 경우입니다
모바일은 에이전트 네이티브 앱에 완벽한 플랫폼이에요. 파일시스템이 있고, 엄청난 컨텍스트(건강 데이터, 위치, 사진, 캘린더)가 있고, iCloud로 모든 기기가 동기화되죠.
근데 문제가 하나 있어요. 에이전트는 오래 실행되는데 모바일 앱은 그렇지 않다는 거예요. 에이전트가 작업하는 데 30초, 5분, 아니면 한 시간이 필요할 수 있는데, iOS는 몇 초만 비활성 상태면 앱을 백그라운드로 보내버리거든요. 사용자가 작업 중에 전화 받거나 화면 잠그면? 앱은 종료될 수 있습니다.
그래서 모바일 에이전트 앱은 체크포인팅이 필수예요. 작업이 손실되지 않게 상태를 저장하고, 중단된 곳에서 다시 시작할 수 있어야 합니다. iOS가 주는 대략 30초 동안 현재 작업을 마무리하고, 상태를 저장하고, 우아하게 종료해야 해요.
정말 오래 걸리는 작업이면? 서버 측 오케스트레이터를 고려할 수 있어요. 서버가 몇 시간이고 돌면서 작업하고, 모바일 앱은 그걸 보여주고 입력받는 창구 역할만 하는 거죠.
아직 탐험 중입니다
이 가이드가 정직한 점은, 모든 걸 다 알아낸 척하지 않는다는 거예요. 곳곳에 “Claude의 제안이고 Dan은 아직 의견 형성 중”이라는 주석이 달려 있습니다. 에이전트 네이티브 아키텍처는 여전히 탐험하는 영역이거든요.
예를 들어 에이전트가 “잠깐, 이건 사용자한테 물어봐야겠어” 하고 멈추는 기능이나, “이건 내 권한 밖이야” 하고 에스컬레이션하는 기능 같은 건 아직 표준화되지 않았어요. 현재는 에이전트가 입력이 필요하면 텍스트 응답으로 물어볼 뿐, “입력 대기 중”이라는 공식적인 상태가 없죠. 이것도 여전히 찾아가는 중입니다.
에이전트가 자기 프롬프트를 스스로 수정할 때 뭐가 바뀌었는지 어떻게 투명하게 보여줄지도 마찬가지예요. 승인 플로우가 한 가지 방법이고, 쉬운 롤백이 가능한 감사 로그도 다른 방법이 될 수 있습니다. 원칙은 명확해요: 투명하게 만들어라.
하지만 핵심 통찰만큼은 확실합니다. 정말 훌륭한 코딩 에이전트는 범용 에이전트예요. Claude Code SDK가 이걸 누구나 접근 가능하게 만들었죠. 이제 우리는 기능이 코드가 아니라 목표 설명인 앱을 만들 수 있습니다.
Dan Shipper는 마지막에 이런 질문을 던져요. “몇 년 후 에이전트 정원에 살게 되면, 우리는 높고 정확하고 완벽했던 마천루 시대를 그리워하며 돌아볼까?” 아마 그럴 수도 있죠. 하지만 지금 우리는 통제되고 싶지 않은 세상에 완전한 통제를 부과하려던 아름답고 정교한 시도에서 벗어나, 야생적이고 유연하고 자유로운 것을 키우는 법을 배우고 있습니다.
참고자료:
답글 남기기