목표는 이렇다. Claude Code한테 "checkout 체인지셋 그린이야?"라고 물으면, 로컬 테스트 결과로 짐작하지 않고 osFoundry에서 체크 결과를 읽어서 답한다. 어떤 체크가 떨어졌는지 짚어 주고, 플레이키해 보이면 그 체크 하나만 재실행하자고 제안한다. 제안하는 순간엔 아무것도 안 돈다. osFoundry에 "Retry GitNest check" 카드가 오고, 거기에 체인지셋 버전과 대상 커밋이 적혀 있다. Approve retry를 눌렀을 때만 다시 돈다.
누가 뭘 하나
| Claude Code | osFoundry | |
|---|---|---|
| 로그인 | 로컬 Claude Code 자체 로그인 | 워크스페이스 하나에 한 번 승인한 연결(osfoundry:read / osfoundry:write) |
| 보이는 저장소 | 서버가 준 목록에서 고른다 | 연결이 들어간 프로젝트에 배정된 GitNest 저장소만 |
| 체크 읽기 | 체인지셋 하나에 list_gitnest_checks | 현재 컴포즈된 커밋의 상태를 상한 걸어서 돌려준다 |
| 체크 실행 | 안 한다 | 직접 등록한 러너 머신이 돌린다. osFoundry는 코드를 실행하지 않는다 |
| 재실행 | propose_gitnest_check_rerun. destructive라서 Claude Code 쪽에서도 먼저 허락을 묻는다 | "Needs your approval"에 카드가 온다. Approve retry로 끝난 체크 하나를 다시 큐에 넣는다 |
| 승인 시 재확인 | 없음 | 저장소 접근 권한, 체인지셋 버전, 커밋, 체크 상태 |
세팅
1. Claude Code에 osFoundry 추가
$ claude mcp add --transport http -s user osfoundry https://api.osfoundry.io/api/v1/external-mcp osFoundry CLI에서 osfoundry agent connect claude --print를 실행해도 같은 줄이 나온다. Claude Code에서 /mcp를 열고 osfoundry를 골라 Authenticate. 브라우저에 osFoundry가 뜨면 워크스페이스 하나를 고른다. 그다음부턴 도구가 mcp__osfoundry__…로 보인다.
2. 저장소에 체크랑 러너가 있는지 확인
한 번도 안 돈 체크는 읽을 수도, 다시 돌릴 수도 없다. GitNest에서 저장소 설정 페이지를 열고 패널 두 개를 본다.
- Check runners: "Checks run on your machine, not ours"라고 적힌 대로 체크는 내 머신에서 돈다. Register runner를 누르면 토큰이 딱 한 번 보이고, 실행 명령
OSF_RUNNER_TOKEN=… osfoundry-runner --api https://api.osfoundry.io이 나온다. 러너가 없으면 "Checks will stay queued until one is."라고 경고한다. 은근히 많이 걸리는 데다. - Required checks:
.osfoundry/checks.yaml에 적은 체크 이름을 넣는다. 여기 넣은 체크가 전부 통과해야 체인지셋을 머지할 수 있다.
3. 저장소와 연결을 같은 프로젝트에 넣기
GitNest에서 저장소의 Project 칸을 열면 "Connected agents in this project can use approved GitNest read tools when their connection owner still has repository access."라고 나온다. 고를 수 있는 건 저장소 오너뿐이다. 프로젝트를 고르면 "Repository project updated"가 뜬다.
이어서 자물쇠 아이콘 → Connected에서 Claude Code 연결을 고르고, Projects에 같은 프로젝트를 추가한다.
예시: 저장소가 들어 있는 프로젝트에 Claude Code 연결을 추가하는 화면
같은 패널의 Tools는 "All supported tools are on by default."다. 이번에 쓰는 건 list gitnest work, list gitnest checks, list gitnest saved results, read gitnest work, propose gitnest check rerun이다(밑줄은 공백으로 표시된다). 체크를 읽기만 시키고 싶으면 propose gitnest check rerun을 끄고 Save tools를 누른다.
실제 대화
도구 이름과 인자 이름은 osFoundry 서버가 tools/list로 돌려주는 그대로다. 저장소, 체인지셋, ID, 체크 이름, 답변은 예시다.
예시 You: shop-api의 checkout-retry 체인지셋 그린이야? 코드 말고 다른 이유로 떨어진 체크 있으면 osFoundry에 재실행 요청해 줘. Claude Code → mcp__osfoundry__list_granted_resources {} ← project "Payments" · GitNest repository "shop-api" Claude Code → mcp__osfoundry__list_gitnest_work {"repository_id": "…", "kind": "changes"} ← "Fix double charge on checkout retry" (cs_4e81a0) · version 3 Claude Code → mcp__osfoundry__list_gitnest_checks {"repository_id": "…", "change_set_id": "cs_4e81a0"} ← composed commit 9c1e47a…: unit passed · lint passed · e2e failed Claude Code → mcp__osfoundry__list_gitnest_saved_results {"repository_id": "…", "limit": 10} ← 2 saved results behind this change set Claude Code → mcp__osfoundry__read_gitnest_work {"repository_id": "…", "kind": "runs", "item_id": "…"} ← run summary: payment client tests passed locally Claude Code: 9c1e47a에서 unit이랑 lint는 통과했고 e2e만 떨어졌어요. 바뀐 건 결제 클라이언트뿐이고 저장된 실행에서도 그 테스트는 통과했으니, 다시 돌려 봐도 될 것 같아요. 제안할까요? You: 응. Claude Code → mcp__osfoundry__propose_gitnest_check_rerun {"repository_id": "…", "change_set_id": "cs_4e81a0", "check_name": "e2e", "expected_change_set_version": 3, "expected_composition_oid": "9c1e47a…", "idempotency_key": "rerun-5b0c…"} ← proposal waiting for the owner Claude Code: Connected → Needs your approval에 재실행 제안이 들어가 있어요. 승인하면 알려 주세요. 체크를 다시 읽을게요. 제안 전에 Claude Code가 한 번 묻는 건 이 도구가 destructiveHint: true라서다. Claude Code 쪽 허락이고, osFoundry 승인과는 별개다.
승인하기 전에 체인지셋 자체도 보자. GitNest 리뷰 페이지엔 탭 위에 체크 패널이 있고, 컴포즈된 커밋의 결과를 한 줄로 요약한다. 이번엔 "Checks did not pass: e2e"이고, 그 아래에 체크별 상태가 나온다. 아직 컴포즈 안 한 체인지셋엔 패널 자체가 없고, 체크가 하나도 없는 커밋은 초록 체크 표시 대신 "No checks have run against this commit"이 뜬다.
알림 벨엔 "<연결 이름> proposes retrying a GitNest check"가 뜬다. 자물쇠 아이콘 → Connected → 연결 → Needs your approval의 카드는 이렇게 생겼다.
Retry GitNest check in shop-api Change set: cs_4e81a0 · expected version 3 Reviewed commit: 9c1e47a… Check to retry: e2e Review change set before approving Expires … [ Approve retry ] [ Decline ] 
예시: Needs your approval에 도착한 GitNest 체크 재실행 제안
"Review change set before approving"을 누르면 아까 그 리뷰 페이지가 열린다. 카드의 커밋이 내가 본 거랑 같으면 Approve retry. 그 커밋에 대해 e2e가 다시 큐에 들어가고 러너가 가져간다. Claude Code한테 "승인했어"라고 하면 list_gitnest_checks를 한 번 더 불러서 결과를 알려 준다.
어디까지 되나
재실행 대상은 브랜치가 아니라 커밋이다. propose_gitnest_check_rerun은 expected_change_set_version과 expected_composition_oid가 필수라서, 카드엔 항상 Claude Code가 실패를 본 그 커밋이 찍힌다. 카드가 기다리는 동안 누가 체인지셋을 다시 컴포즈하면, 승인하려는 커밋은 이미 카드의 커밋이 아니다. osFoundry는 누르는 순간 버전, 커밋, 체크 상태를 다시 확인하니까 낡은 카드는 실행되지 않는다. 그럴 땐 패널에 "Could not decide this proposal. Its access may have changed."가 뜬다. Claude Code한테 체크를 다시 읽히고 새 커밋으로 다시 제안받으면 된다.
다시 돌릴 수 있는 건 끝난 체크뿐이다. 도구 설명에도 "retry one finished check"라고 돼 있고, 체크 상태가 승인 시 재확인에 들어간다. 누가 먼저 재실행했거나 재컴포즈돼서 이미 큐나 실행 중으로 돌아간 체크가 두 번 쌓이는 일은 없다.
제안 한 번에 체크 하나다. check_name은 200자까지의 문자열 하나다. 스위트 전체를 다시 돌리려면 체크마다 카드가 한 장씩 오고, 한 장씩 판단하게 된다. 플레이키한 e2e 김에 일부러 실패한 채 둔 보안 스캔까지 조용히 다시 도는 일이 안 생긴다.
이 경로에선 osFoundry 머신에서 뭔가 돌지도, 코드가 바뀌지도 않는다. 체크를 돌리는 건 내가 등록한 러너다. 재실행 승인은 체크를 다시 큐에 넣을 뿐이고 컴포즈도, 머지도, 공개도 안 한다. 머지는 여전히 필수 체크가 그 커밋에서 전부 통과할 때까지 기다린다.
읽히는 정보도 얇다. list_gitnest_checks가 돌려주는 건 현재 컴포즈된 커밋의 상태뿐이다. list_gitnest_saved_results와 read_gitnest_work엔 로컬 바인딩이나 자격 증명이 안 들어 있다. Claude Code는 테스트가 떨어졌다는 건 알려 줄 수 있어도, 러너 토큰이나 로컬 체크아웃 경로는 못 본다.
해 보려면 남는 머신에 러너를 하나 등록하고, 플레이키한 걸 아는 체크가 들어간 체인지셋을 만든 다음 Claude Code한테 "그린이야?"라고 물어보자. 저장소, 체인지셋, 체크 화면은 GitNest 페이지에, 승인 패널은 Connected 페이지에 정리돼 있다.
