11월 9일 일지

11월 9일

오늘 공부에 투자한 순수한 시간: 5시간

학습한 개념 : apps-in-toss-harness 프로젝트 분석 및 이해하기

<app-in-toss>

app-in-toss는 토스 앱 안에 있는 또 다른 미니앱으로, 사용자가 내 앱을 따로 설치하지 않고도, 토스를 켜면 미니앱 탭이나 검색에서 해당 서비스를 열면 그 서비스가 실행이 되는 구조이다.

토스는 훌륭하고 유용한 서비스 앱들을 자신의 플랫폼과 인프라 안으로 끌어들여 사용자들에게 보다 편리하고 유용한 서비스와 가치를 주고자 하는 취지에서 만들어진 시스템이다.

app-in-toss에서의 핵심 구조는 "내가 만든 app-in-toss 미니앱은 독립된 앱이 아니라, 토스 앱이 띄워주는 화면 하나"이다.

<apps-in-toss-harness>

1. 왜 필요한가.(목적성)

-> 토스 안에 또 다른 앱 즉, app-in-toss 앱을 만들려고 할때, 이를 만들기 위해 Claude code, Codex. Cursor 등등의 에이전트를 사용하여 앱 개발 작업을 실행하려고 할때, 에이전트가 토스 내의 정보를 모르니까 이를 알 수 있도록 하는 방법을 공개했는데 이 방식이 하네스를 통해 내 에이전트가 토스 내부의 SDK, 콘솔, 실제기기를 하네스를 통해 알 수 있도록 해서 에이전트가 작업을 할때, toss가 공개한 하네스를 통해서 에이전트 코딩을 보다 쉽고 편리하게 할 수 있도록 도와주고, 토스 밖에 이미 좋은 서비스들이 많은데, 좋은 서비스가 유저에게 충분히 닿을 수 있는 환경을 만들면 좋겠다 라는 취지에서 만들어진 프로젝트라고 볼 수 있다.

1-0. 에이전트가 혼자 하지 못하는 일의 종류 (하네스가 필요한 이유)

1-1. 토스앱의 네이티브를 소유하지 않는다. (모른다.)

-> 내 코드는 웹이고 WebView 안에서 돌아간다. 따라서 로그인, 결제, 카메라, 위치, 연락처, 햅틱 같은 네이티브 기능을 직접 호출할 수가 없다. 왜냐하면 이는 토스 앱(네이티브)이 가지고 있기 때문이다.

1-2. 배포 채널을 소유하지 않는다. (못 한다.)

-> 내 앱은 앱스토어나 플레이 스토어에 올라가는 것이 아니라 사용자 폰에 이미 다운로드 되어있는 토스 앱이 Bundle을 받아서 실행을 하는 것이다. 따라서 배포는 토스에 Bundle을 제출해야 한다. 하지만 Bundle을 제출하는 배포 채널을 가지고 있지 않는다.

1-3. 런타임을 소유하지 않는다. (못 본다.)

-> 에이전트를 통해 만든 코드가 실제로 동작을 하는 곳은 개인 크롬 브라우저가 아니라 토스 앱 안의 WebView이다. 이 둘의 환경은 동일하지 않는다. 내 브라우저와 토스를 이어주는 브릿지가 없다. 이로인해 데스크톱 기본 폭에서는 레이아웃이 실제로 다르게 보일 수 있고, 휴대폰 WebView 안의 console.log를 내 PC에서 볼 방법이 기본적으로 존재하지 않는다.

즉, 처음부터 서로 전혀 다른 환경에서 돌고 있다는 사실의 필연적인 결과일 수 밖에 없는 것이다.

2. 하네스를 통해 어떻게 에이전트가 모르는 세 부분을 메우는가?

2-1. docs MCP (지식을 채워주다)

-> 먼저 플러그인, MCP, 개발자센터 문서 이 세 가지가 서로 어떻게 동작하는지를 우선 구분해야 한다. 공식문서는 토스 서버에 있는 하네스를 위한 내용(지침이 들어가있음)물이고, MCP는 그 내용물을 AI가 꺼내 갈 수 있도록 토스가 열어둔 창구이고, 플러그인은 내 컴퓨터에 설치가 되어서 그 창구의 주소와 이용 규칙을 들고 있는 것이다. 문서와 창구는 토스 서버에 그대로 남아 있고 플러그인만 내 쪽으로 넘어온다고 생각하면 된다.

하네스를 통해 에이전트에게 지식을 채워주는 과정은 총 3단계이다.

첫 번째는 통로이다. plugin.json이라는 파일에 창구 주소가 적혀있다. 문서 창구는 인증이 필요 없어서 플러그인을 설치하면 바로 연결될 수 있따. 토스가 서버에서 직접 운영하고 있기 때문에 하네스는 그냥 그 주소를 에이전트에게 알려주면 되는 것이다.

두 번쨰는 규약이다. 지식을 채울 수 있는 통로가 열려 있어도 에이전트는 헤딩 문서를 읽지 않고 기억으로 답을 하려고 한다. 따라서 문서를 언제 어떻게 읽어야 하는지에 대한 규약이 반드시 필요하다.

에이전트가 기억에 의존해서 답변을 하려고 하는 이유에 대해 간단하게 말해보자면, 가장 중요한 점으로는 에이전트 모델은 자기가 모른다는 것을 모를 수도 있기 때문이다. 모델이 하는 핵심적인 일은 다음에 올 그럴듯한 단어를 고르는 일을 확률적으로 계산하는 것인데, 여기서 정확한 답과 그럴듯하지만 틀린 답이 똑같이 매끄럽게 나올 수 있기 때문이다. 에이전트 모델은 그 이전에 수 많은 개발에 대한 데이터와 라이브러리, 프레임워크, SDK 등등의 코드들을 학습했기 때문에 확신의 근거와 정확성이 따로 놀 수 가 있기 때문이다.

이렇게 되면 틀렸다는 신호가 어디에도 뜨지 않기 때문에 한참 뒤에 터지고, 그때는 원인을 찾을 수가 없는 상황이 발생할 수 있다. 따라서 규약이 전부 금지문으로 되어 있다.

즉, 문서를 확인하라는 권유가 아니라 원문을 읽기 전에 판정하지 말라는 금지문이라고 볼 수 있다.

세 번째 층은 주소록이다. lookup-map이라는 표에 상황 14개와 그때 열어볼 문서 경로가 적혀 있다. 규약이 원문으로 판정하라고 해도 어느 원문인지 모르면 할수가 없다. 서버를 통해 닿는 하네스 문서가 수백 장인데 이 안에서 읽을 문서를 찾는 것은 시간이 매우 오래걸릴 수가 있다.

따라서 경로가 미리 적혀 있으면 읽는 빠르게 원하는 부분을 읽을 수 있다. 또한 이 부분에서 문서 내용을 옮겨 적지 않고 경로만 적어 두었다. 토스가 문서를 고쳐도 하네스가 낡지 않게 하기 위함이다. 표 아래에는 문서에서 찾지 못한 것은 문서에 없음, 확인 필요로 적고 다른 페이지에서 추측해 채우지 말라는 규칙도 같이 붙어 있다.

즉, 지식의 결핍은 접근 권한만으로 메워지지 않는다. 닿게 하고, 기억을 금지하고, 어디를 읽을지까지 정해 주어야 비로소 메워지는 것이다.

2-2. console MCP (권한을 위임받다)

-> 콘솔 창구는 plugin.json에 적힌 줄이 문서 창구와 거의 같고 oauth라는 한 줄만 다르다. 하지만 이 한 줄이 결정적인 차이를 만드다. 문서는 누구나 보는 공개 문서이지만 콘솔은 내 앱을 작동시킬 부분이기 때문에 권한이 매우 중요해진다. 이 부분 또한 3가지의 과정으로 나눌 수 있다.

첫 번쨰 부분은 위임 선언이다. oauth는 비밀번호를 넘기지 않고 권한만 빌려주는 방식이다. 사용자가 한 번 승인을 하면 에이전트는 이 사람 대신 행동해도 된다는 권한을 얻는 것이다. 여기서 나의 콘솔 비밀번호는 에이전트에게 가지 않는다. 이는 구글 로그인 기능을 사용해본 경험이 있으면 쉽게 받아들일 수 있다. 구글 로그인 버튼을 누르면 구글 비밀번호를 그 사이트에게 주지 않고도 구글이 "이 사람이 맞다" 증표를 건네주는 것이다.

두 번재는 멈춤 규약이다. 에이전트가 콘솔에서 할 수 있는 일은 각각 저마다 가진 무게가 다르다. 목록을 보는 일은 백 번 해도 아무 일이 없지만 출시는 누르는 순간 내 앱이 수천만 명이 쓰는 토스 앱에 올라간다. 그래서 "되돌릴 수 있는지"를 기준으로 행동을 세 등급으로 나눈다.

되돌릴 수 있는 일은 그냥 하고, 되돌리기 어려운 일은 사용자에게 물어보고 하고, 되돌릴 수 없는 일은 아예 하지 않도록 하는 것이다. Bundle을 올리는 것은 창고에 상자를 하나 더 쌓는 것이라 자유에 들어가고, 검수 요청은 토스 직원의 시간이 들어가는 일이라 승인을 받아야 하고, 출시와 롤백은 사람이 콘솔에서 직접 하도록 하게 하는 것이다.

세 번째 부붕은 하드 차단이다. 폰에서 디버깅을 하려면 디버그 도구가 들어간 Bundle을 올려야 하는데, 콘솔은 폰에서 테스트한 그 Bundle을 그대로 검수에 보낸다. 두 Bundle은 겉으로 똑같이 생겨서 사용자가 봐도 구분을 할 수가 없기 때문에 따라서 이것은 사람의 승인으로는 막는 것이 쉽지 않다. 그래서 사람에게 묻지 않고 기계가 먼저 검사를 한다.

디버그 번들을 올렸을 때 그 번호를 파일에 적어 두고, 번들 파일을 직접 뜯어서 디버그 도구의 흔적을 찾는다. 하나라도 걸리면 사용자가 승인을 해도 풀리지 않는다. 그리고 흔적을 못 찾았으면 통과가 아니라, 확인이 안 되면 거절이 기본값으로 되는 것이다.

2-3. 관측 debugger (들여다보다)

-> 이 단계는 내 개인 PC에서 작동하는 앱이 폰에서는 다르게 작동할 수 있는데, 이를 에이전트가 관찰해서 수정 및 디버깅 하는 단계이다. 내 개인 PC의 브라우저와 toss에서 작동해야 하는 앱의 환경은 매우 다를 수 밖에 없기 때문이다.

이 부분 또한 세 가지 단계로 나눌 수 있다.

첫 번째는 폰에 작은 코드인 debugger-client을 심는 것이다. 폰 속 미니앱 안에 들어가는 아주 작은 코드로, 지금 디버그를 켜도 되는 상황인지를 검사하고 폰 속 상황을 내 PC로 계속 보내는 발신기 이렇게 두 가지 역할을 한다.

다른 패키지에 의존하는 것이 하나도 없어서 SDK 버전이 무엇이든 그냥 붙을 수 있고, 코드의 양도 많다. 다만 이 통로는 남이 내 앱 속을 들여다보는 구멍이 될 수 있기 때문에 방어를 할 수 있는 네 개의 가드를 세워 두었다.

평소 Bundle에는 코드 자체가 들어가지 않고, 테스트용 주소일 때가 제대로 되어 있어야 하고, 중계소의 도장이 진짜인지를 확인한다. 네 개 중 앞의 두 개는 내 실수로 켜지는 것을 막고 뒤의 두 개는 남이 끼어드는 것을 방어한다.

두 번째는 내 PC에서 도는 중계소인 debugger이다. 폰이 보낸 것을 받아서 에이전트가 쓸 수 있는 도구 모양으로 바꿔 주는 것이다. 가드 네 개를 통과하면 에이전트 손에 로그 보기, 통신 기록 보기, 화면 사진 찍기, 안전영역 재기 같은 도구 열일곱 개가 쥐어진다. 이 패키지는 내 앱에 절대 들어가지 않고, 앱 코드에서 불러올 입구조차 만들어 두지 않았다.

또한 내 PC는 인터넷에서 찾아올 주소가 없기 때문에 cloudflared라는 도구가 지금 이 순간만 쓰는 임시 주소를 하나 만들어 주고 폰이 그 주소로 찾아온다.

세 번째는 둘이 쓰는 말 약속인 internal-protocol이다. 이것은 통신을 하게 해 주는 것이 아니다. 통신 자체는 일반적인 방법으로 이미 된다. 양쪽이 똑같이 알고 있어야 하는 이름, 모양, 번호 같은 약속을 한 군데 모아 둔 것이다. 이 약속을 양쪽에 따로 적어 두면 한쪽만 고쳐질 수 있는데, 그때 에러가 나지 않고 조용히 이상하게 동작을 한다. 그래서 버전 번호를 하나 두고 붙기 직전에 비교해서 다르면 반쯤 되게 두지 않고 아예 거절을 한다.

2-3은 2-2와 밀접한 관계를 가지고 있다고 볼 수 있다. 디버그 Bundle도 콘솔에 올려야 폰에서 열 수 있으므로 2-3은 2-2의 업로드를 쓴다. 그리고 올릴 때 그 번호를 기록해 두고, 검수를 넣을 때 2-2의 하드 차단이 그 기록을 보고 막는다. 즉 2-3이 만든 위험을 2-2가 받아서 막는 짝꿍 구조이다.

마지막으로 이 단계의 핵심은 관찰이고 보정이나 변환이 아니다. 아이폰의 사파리 엔진을 내 크롬으로 바꿀 수 없고 진짜 브릿지를 내 PC로 가져올 수도 없다. 환경을 같게 만드는 것은 불가능하므로 다른 것은 다른 대로 두고 그쪽을 직접 들여다보는 것이 핵심 포인트이다.

2-4. agent-plugin (순서대로 엮다)

-> 2-1부터 2-3까지로 에이전트는 능력 세 개를 갖게 되지만 그것만으로는 에이전트가 제대로 일이 되지 않는다. 순서를 모르기 때문에 아이콘도 없이 번들을 빌드하거나 약관 동의를 하지 않고 검수에 넣고, 지난 대화를 기억하지 못하기 때문에 어제 정한 규칙을 오늘 또 알려줘야 하고, 어느 능력을 써야 할지를 매번 다르게 판단하기 때문이다.

2-4는 능력을 더 주는 것이 아니라 능력을 쓰는 순서를 적어 둔 지시서 묶음이라고 볼 수 있다. 작업의 종류별로 지시서(Skill)가 열두 장 있고, 짧은 명령 네 개는 그 지시서를 가리키기만 하는 껍데기이다. 명령 파일의 내용은 지시서를 펴라는 한 줄뿐이다. 명령에 내용을 넣으면 같은 내용이 두 군데에 적히게 되고, 그러면 한쪽만 고쳐질 수 있기 때문이다.

지시서를 고르는 것은 사용자가 아니라 에이전트이다. 따라서 각 장 맨 앞에 이럴 때 나를 펴라는 설명이 사용자가 할 말 그대로 적혀 있다. 대화가 시작되면 열두 장의 앞머리만 올라가고, 한 장을 고른 뒤에 그 본문이 올라간다.

또한 단계가 끊기지 않게 하는 장치도 있다. 각 지시서가 끝날 때 다음에 할 일을 명령과 말 두 가지로 알려 준다. 그래서 전체 순서를 외우지 않고 지금 할 것만 보면 된다.

그리고 에이전트가 그 이전의 작업 내용을 기억하지 못하는 문제는 프로젝트 폴더에 그 전에 한 작업을 기록해둔 AGENTS.md를 심어서 해결한다. 기억을 한다기 보단 AGENTS.md 파일을 읽어서 그 전까지 했던 작업을 읽는 것이라고 이해하는 것이 더 좋다.

하네스는 Claude Code, Codex, Cursor를 모두 지원하는데 지시서는 한 벌만 만들었다. 내용은 한 군데에 두고 각 에이전트용 표지만 따로 두었으며, 설정 파일 위치처럼 어쩔 수 없이 다른 부분은 코드로 분기하지 않고 지시서에 한 줄로 적어 두었다. 또한 지시서는 그냥 글이기 때문에 고치다 보면 한 줄이 조용히 사라질 수 있다. 그래서 검사 프로그램이 지시서의 구조를 확인하고 통과하지 못하면 새 버전을 내지 못하게 막는다.

3. 전체 과정 (흐름)

-> 레포에는 station 0~8까지의 번호가 있다. 다만 이 번호는 순서가 아니라 구역 이름이다. 0은 설치, 1은 스캐폴드, 2는 개발, 3은 디버그, 4는 기능, 5는 등록과 출시, 6은 상태 조회, 7은 기획, 8은 디자인이다. 기획이 7번인데 실제로는 두 번째로 하기 때문에 번호 순서대로 하면 안 된다. 실제 순서는 개발 여정에 적힌 아래 아홉 단계이다.

1단계 설치

-> /plugin marketplace add toss/apps-in-toss-harness 을 통해 마켓플레이스를 추가하고 플러그인을 설치한 다음 콘솔 인가를 처음애 딱 한 번 한다.

그리고 welcome을 실행하여 환경을 점검한다. git과 Node가 있는지, 지금 폴더가 빈 폴더인지 기존 프로젝트인지, 창구가 연결되었는지를 점검하고 첫 번째로 할 일을 알려준다. 플러그인 설치 자체는 아무 안내를 해 주지 않으므로 그 빈자리를 welcome이 메우는 것이다. 설치한 플러그인은 새 대화부터 적용이 된다.

2단계 기획

-> 자신의 아이디어가 구체적이지 않고 막연하다면 먼저 plan으로 시작할 수 있다. 아이디어가 없으면 발산하고 걸러서 하나로 좁히고, 또한 만약 아이디어가 있으면 PRD 아홉 항목을 대화로 채운다. 그리고 그 PRD에서 필요한 SDK 기능 묶음, 그것이 요구하는 폰 권한, 콘솔에서 동의해야 할 약관 세 가지를 뽑는다.

3단계 프로젝트 만들기

-> new를 실행하면 빈 폴더가 프로젝트가 된다. 기본 틀과 함께

-Mock 토스 SDK와 확인 패널,

-색과 간격 설정 파일,

-기본 스타일과 아이콘,

-디자인 규칙 문서,

-이모지 서체,

-AGENTS.md

를 같이 심어 준다. Mock SDK가 있기 때문에 토스 앱 없이도 내 브라우저에서 개발을 시작할 수 있다. 이 단계에서 심은 AGENTS.md가 이후 모든 대화에 자동으로 올라오는 메모가 된다.

4단계 개발

-> dev를 띄우면 내 브라우저에서 앱이 뜬다. Mock SDK가 로그인 버튼에 Mock 응답을 주기 때문이다.

광고·결제 같은 SDK 기능 붙이기 -> /ait:feature

서버 코드 쓰기 -> /ait:server

화면 만들기·고치기 -> /ait:design

문구 다듬기 -> /ait:ux-writing

이 단계에서는 콘솔을 전혀 건드리지 않는다. 다만 브라우저에서 보이는 것은 어디까지나 흉내이므로 그 다음 단계가 반드시 필요하다.

5단계 실기기 확인

-> /ait:test-on-device를 통해서 처음으로 진짜 토스 앱에서 본다. 프로젝트를 읽어서 종류에 맞는 빌드를 하고, Bundle을 콘솔에 올리고, 콘솔이 컴파일을 끝냈는지 확인하고, 폰에서 열 링크를 준다.

올리기 전에 폴더와 인가, 앱 등록, 자산이 있는지를 먼저 확인하고 안 되면 바로 멈춘다. 디버그 빌드로 올렸을 때는 그 배포 번호를 프로젝트에 기록해 두고 나중에 검수에 못 가게 한다.

6단계 디버그

-> 폰에서만 생기는 문제가 있을 때만 거치는 단계이다. /ait:setup-debugger를 통해 PC가 폰의 정보를 변환해서 에이전트에게 전달해주고, /ait:debug로 그 정보를 들여다본다. 가드 네 개를 통과하면 로그와 통신 기록, 화면 사진, 안전영역 치수를 에이전트가 직접 본다. 2-3의 과정이 거의 그대로 적용되는 단계이므로 관찰을 하는 단계라고 볼 수 있다.

7단계 디자인 마무리

-> /ait:design 으로 화면을 고치고 등록용 로고와 썸네일, 스크린샷을 만든다. 글자 크기 하한이나 터치 영역, 하단 안전영역처럼 꼭 지켜야 하는 규칙에 걸리면 지적만 하지 않고 코드를 직접 고친다.

8단계 출시 준비

-> /ait:launch로 점검을 한다. 기계가 먼저 디버그 흔적을 보고 걸리면 멈추고, 통과하면 공식 체크리스트 원문과 코드를 맞춰 보고, 보낼 내용 전체를 보여준 다음 승인을 받아 한 번만 제출한다.

만약 통과되지 않으면 같은 명령에 사유를 붙여서 원인을 문서와 맞춰 찾는다.

9단계 운영

-> 출시 버튼은 사람이 콘솔에서 직접 누른다. 이는 2-2 부분에서 마지막 하드차단 부분때문이다. 그 뒤로는 전용 명령이 없고 에이전트가 콘솔 창구의 조회 도구를 직접 불러서 검수와 출시 상태, 올린 번들 목록을 본다. 노출 단계와 핵심 지표 등록은 콘솔 웹에서 사람이 하는 일로 남겨 둔다. 출시 이후 부터는 하네스가 손을 떼는 구간이고, 되돌릴 수 없는 버튼을 끝까지 사람 몫으로 남겨 둔 것이 이 프로젝트의 중요한 경계선이다.

키워드

ㄴ꼬리질문1 우선 앱인토스가 뭘 의미하는지 알아야 앱인토스의 SDK, 콘솔, 실기기환경을 가지고 있고, 또 어떤 상황에 이를 몰라서 문제가 생기게 되기 떄문에 이 프로젝트가 공개된건지 그리고, 사용자들은 이 앱인토스의 SDK, 콘솔, 실기기를 하네스를 통해 해결을 할 수 있는지에 대해 목적성을 좀 더 디테일하게 설명해줘

ㄴ꼬리질문2 토스 안에 또 다른 앱을 만들려고 하는데, 만들기 위해 에이전트에게 작업을 맞기려는데 에이전트가 토스 내의 정보를 모르니까 이를 알 수 있도록 하는 방법을 공개했는데 이 방식이 하네스를 통해 내 에이전트가 토스 내부의 SDK, 콘솔, 실제 기기을 하네스를 통해 알 수 있도록 해서 에이전트가 작업을 할 수 있도록 하는 프로젝트로 이해했는데

내가 이해한 것이 맞는지 판단해주고, 잘못된 부분이나, 오류가 있으면 알려주고, 이를 바로잡아줘

ㄴ꼬리질문3 이제 하네스를 통해 내부에서 에이전트가 어떻게 작동되도록 하는지에 대해 조금 더 깊게 들어가보자

하네스가 프로젝트 내부에 어떻게 구현되어 있는지 쉽게 설명해주고, 목적서과 연결해서 설명해줘

ㄴ꼬리질문4 우선 먼저 2-1번 먼저 자세하게 파보자 지금부터는 내가 꼬리질문을 하는거니까 그냥 순수 나를 이해시킬 수 있도록 쉽게 설명해주면 되는거야

에이전트가 MCP와의 연결 통로가 열려있어도, 기억으로 대답을 하려고 한다는게 무슨 말인지 설명해줘

ㄴ꼬리질문5 4줄 옆에 규약이 필요하다고 했고, 이 규약은 Skill로 하네스를 만들었잖아?

이 Skill이 막는 4가지 상황에 대해 조금 더 쉽고 자세하게 설명해줘

ㄴ꼬리질문6 마지막으로 상황별 어떤 문서를 열어야 하는지가 표로 적혀있다고 했는데 이 부분도 설명해줘

그리고 내가 지금 헷갈리는게 4가지의 규약이랑 상황별로 어떤 문서를 열어야하는지에 대한 표 또한 상황이 4개로 되어있어서 이 두 분류를 자꾸 혼동하는 것 같아

2-1을 이제 마무리 하려고 하니까 이 두 분류를 어떻게 연결해서 정리해야 할지 설명해줘

ㄴ꼬리질문7 정리해보자면 2-1 총 3개의 하위 구조로 나뉘는데 은 서버 MCP 경로를 보여줘서 toss 서버에 있는 플러그인 문서에 경로를 통해 닿을 수 있게 하고, 이 해당 문서를 어떻게 봐야 하는지(기억에 의존하지 않고, 이 지시문) 보기 그리고, 어떤 문서를 보는지에 대한 것이 층 3 마지?

ㄴ꼬리질문8 2-1 단계에서의 플러그인, MCP, 개발자센터 문서 이 3가지의 관계와 연결성이 정리가 안돼

MCP를 통해 개발자센터 문서에 접근할 수 있게 되는 것이고 등등 이런식으로 3가지를 정리해줘

ㄴ꼬리질문9 멈춤 규약 또한 Skill로 주어지는거야?

ㄴ꼬리질문10 멈춤 규약 부부분의 설명을 읽는데, 이해가 너무 안되, 쉬운 단어를 사용해서 쉽게 설명해줘봐

ㄴ꼬리질문11 개발을 통해 만든 앱이 PC를 통해 보게 되는데, 이를 개인 폰에서 보려고 하니까 환경이 안 맞아서 이 간극을 맞추는 단계가 2-3단계인거지?

ㄴ꼬리질문12 2-3 단계를 전체적으로 한번 정리해볼게 개발을 하는 과정에서 브라우저로 앱을 볼때는 멀쩡하지만 앱인 앱 즉, 토스 앱 안에서의 앱이므로, 토스 앱은 내 개인 PC의 크롬 브라우저랑 환경이 전혀 다르다 따라서 이로 인해 생기는 문제 (서로 다른 환경으로 인해 같은 코드여도 동작이 다를 수 있음)로 인해 앱에서도 잘 동작하도록 하기 위해서는 앱에서 어떤 문제가 발생하는지를 에이전트가 알아야 해

따라서 폰 속에서 작동하는 앱을 PC에서도 볼 수 있도록 통로를 만들어두는 것이 핵심인 부분이야 그래서 폰 안에 작은 코드 (debugger-client, 폰 안의 상황을 컴퓨터로 전송해줌)를 심고, PC에는 중계소 역할을하는 debugger를 심어서 폰에서 보낸 정보를 받아서 이를 에이전트가 쓸수 있도록 모양을 바꿔줘

그러기 위해서는 폰쪽과 PC쪽이 서로 통신을 하기 위한 프로토콜이 필요하고, 이 프로토콜이 intesnal-protocol인거야

근데 protocol을 통해서 서로 연결이 되려면 주소가 필요한데, 이를 위한 cludflared란ㄴ 도구가 지금 이 순간만 쓰느 인터넷 주소 하나를 만들어주고, 이 주소를 통해서 Pc와 폰이 연결되는거야

그런데 이 통로를 통해 다른 사람이 침투할 수도 있으니까 4가지 가드를 세워놨어

이 4가지의 가드를 다 통과하면 비로소 에이전트가 폰에서 보낸 정보를 PC가 도구로 바꿔서 에이전트 손에 17개의 크롬 개발자 도구가 쥐어져 이를 통해 PC에서 되던 앱이 폰에서는 안되는 문제를 해결하는 거야

최대한 내가 정리를 해봤어

틀린 부분이 있으면 어디가 틀렸고, 왜 틀렸는지 설명해주고, 올바르게 고쳐줘

ㄴ꼬리질문13 너가 분류한 2번 가지들을 ait 플러그인 기준으로 나눈거야?

만약 그런거라면 이유가 뭐야?

app in toss harness 프로젝트 하네스의 가장 중요한 축을 이루고 있는 기준이 ait 플러그인인거야?

ㄴ꼬리질문14 이 하네스의 핵심 작동 방식에 정리해줘

ㄴ꼬리질문15 오케이 이제 남은 3번으로 가서 앱인토스 하네스가 작동하는 원리와 과정을 알 수 있고, 이 하네스를 통해 에이전트가 어떻게 작업 즉, 작동을 하는지에 대해 쉽고 자세하게 내가 이해할 수 있도록 설명해줘

ㄴ꼬리질문16 너가 책상에 올린다는 표현을 좀 많이 사용한 것 같은데 "책상에 올린다"라는 말에서 책상이랑 올린다를 무슨 의미로 사용한건지 설명해줘

AI 대화 내역 링크:

클로드: https://claude.ai/share/ec12c656-f300-4c70-8d59-492a9f2973e4

오늘 잘한 점: 내가 만든 개인 맞춤형 학습 지시서를 심은 대화 세션을 통해 app-in-toss-harness에 대해 공부를 한 것이 잘한 것 같다. 공부를 하면서 아직 부족한 부분들이 맣이 보였고, 이를 어떻게 보완해나가야 할지에 대한 많은 생각을 하게 되었다.

오늘 부족했던 점: 처음에는 이 프로젝트가 뭔지에 대한 개념을 잡는게 쉽지 않았다. 하네스라는 개념을 대충만 알고 있었기 때문에 이해하는데 오래 걸린 것이 아닌가 하는 생각을 한 것 같다.

오늘 총평: 말로만 듣던 하네스가 실제로 toss라는 대기업이 공개해준 app-in-toss-harness를 통해서 공부가 맣이 된 것 같다. 내가 만든 개인 맞춤형 학습 지침서 또한 나만의 하네스가 될 수도 있다는 사실을 알게 되었다.

뛰어난 개발자들의 많은 노하우와 경험을 세상에 공개된 하네스를 역으로 잘 공부하면 배움을 통해 얻어갈 점이 많다는 생각이 들었다.