출발점

SNA의 출발점은 단순했습니다. Claude Code와 Codex를 오가며 작업하다 보니, 쓸 만한 결과물이 서로 다른 툴, 세션, 인터페이스에 흩어졌습니다. 작업은 옮길 수 있었지만, 그 주변 맥락은 같이 따라오지 않았습니다. 그래서 코딩 에이전트를 바꿔도 흐름이 끊기지 않는 계층이 필요했습니다.

각 코딩 에이전트는 CLI로서 이미 강점이 있습니다. 하지만 모든 워크플로에서 CLI가 가장 좋은 인터페이스는 아닙니다. 어떤 작업은 더 나은 연속성, 가시성, 제어권을 가진 독자적인 GUI가 필요했습니다.

계기는 VS Code의 Claude Code 확장 기능이었습니다. 겉으로는 Claude Code였지만, 터미널 안의 CLI만은 아니었습니다. "CLI가 아닌데 어떻게 연결했을까?"라는 질문에서 Claude Code의 옵션과 런타임 표면을 파고들기 시작했습니다. 그 과정에서 Claude Code를 프로그래밍적으로 통합할 수 있고, Codex도 같은 앱 계층 뒤에 둘 수 있다는 것을 확인했습니다.

이름을 유지한 이유

Skills-Native Application이라는 이름은 더 초기의 아이디어에서 왔습니다. 처음의 SNA는 Skills를 런타임처럼 다루는 백엔드 인프라였습니다. 앱은 xterm을 띄웠고, 사용자가 UI를 클릭하면 그 터미널 위에 스킬 명령이 입력되는 방식이었습니다.

그 모델은 계속 바뀌었습니다. UI 제약 때문에 터미널을 화면에서 감추게 되었고, 결국에는 터미널을 띄우지 않는 헤드리스 제어 모델로 옮겨갔습니다. 지금의 SNA는 에이전트 런타임을 직접 제어하고, 구조화된 상태를 앱으로 스트리밍합니다.

따라서 "Skills-Native"는 이제 구현을 문자 그대로 설명하는 이름은 아닙니다. 그래도 이름을 바꾸지 않은 이유는 출발점을 남기기 위해서입니다. SNA는 원래 스킬을 별도의 터미널 워크플로가 아니라 앱 안의 자연스러운 기능처럼 다루려는 시도에서 시작되었습니다.

SNA는 그 관찰에서 시작되었습니다. 네이티브 코딩 에이전트는 각자의 강점을 유지해야 하지만, 연속성은 앱이 소유해야 합니다. 세션, 히스토리, 권한, UI, 런타임 전환이 서로 다른 툴에 흩어져 있으면 제품이 될 수 없습니다.