마크다운 한 장이 깃허브 액션스 YAML을 대신하기 시작했습니다

액션스 YAML의 들여쓰기 하나에 파이프라인이 깨졌습니다. 깃허브의 실험 조직 Next가 다른 방법을 들고 나왔습니다. 마크다운으로 자동화 지시를 쓰면, gh-aw라는 CLI가 그걸 액션스 워크플로로 컴파일해 줍니다. 이슈 분류, PR 리뷰, CI 실패 조사 같은 반복 잡무를 에이전트가 레포 안에서 맡는 구조입니다.

발표 트윗이 조회 3만 8천, 북마크 204개를 모았습니다.

마크다운이 어떻게 워크플로가 되나요?

순서는 세 단계입니다.

하나, 마크다운 파일에 YAML 머리말을 얹어 무슨 일을 언제 할지 적습니다. 새 이슈가 열리면 분류하라, PR이 오면 리뷰하라, CI가 깨지면 원인을 조사하라. 지시의 본문은 자연어예요.

둘, gh-aw 명령이 이 마크다운을 잠금 파일(.lock.yml)로 컴파일합니다. 사람이 쓴 말이 액션스가 알아듣는 형식으로 번역되는 단계입니다.

셋, 깃허브 액션스가 그 파일대로 에이전트를 돌립니다. 코파일럿, 클로드, 코덱스, 제미나이. 특정 에이전트에 잠그지 않고 열어놨어요. 설치는 gh extension install github/gh-aw 한 줄이고, 샘플 모음 레포(githubnext/agentics)와 퀵스타트 문서까지 갖춰져 있습니다.

안전장치는 어떻게 설계됐나요?

이 실험에서 제일 공들인 흔적이 보이는 대목입니다.

기본 권한은 읽기 전용입니다. 에이전트는 샌드박스 안에서 돌고, 밖으로 나가는 행동은 safe-outputs라는 규격을 거쳐야 해요. 이슈에 댓글을 달거나 PR을 만드는 것 같은 쓰기 행동만 명시적으로 허용 목록에 올리는 방식입니다.

낯익은 사상이에요. 가역 작업은 자유롭게, 불가역 행동만 통제하는 승인선. 개인 파이프라인에서 검증되던 원칙이 깃허브 규모의 인프라로 올라온 겁니다. 레포에 상주하는 에이전트가 늘어날수록 이 통제선의 값어치가 커져요.

반대편에서는 뭐라고 하나요?

답글 두 개가 이 발표의 논쟁 지점을 정확히 보여줍니다.

하나는 뼈아픈 농담입니다. Next의 다음 실험 말고, 매주 장애 안 나는 깃허브부터 주면 안 되나. 신기능보다 기본기라는 견제구는 어느 발표에나 붙지만, 인프라 회사에게는 특히 아픕니다.

다른 하나는 방향 자체에 대한 반박이에요. 불필요하다. 내 컴퓨터에 이미 에이전트가 있다. 최고의 API와 MCP만 내놓으면 된다.

이건 노선 싸움입니다. 에이전트를 레포에 상주시킬 것인가, 내 손의 에이전트가 레포에 드나들게 할 것인가. 깃허브는 전자에 걸었고, 로컬 하네스 진영은 후자를 밀어요. WebMCP가 웹사이트에 에이전트 정문을 내는 것과 같은 구도가 코드 저장소에서도 벌어지는 중입니다.

남는 생각

저는 이 실험을 자동화 문법의 세대교체로 읽습니다.

액션스 YAML은 사람이 기계에게 맞춰 쓰는 언어였어요. 들여쓰기 하나에 파이프라인이 깨지고, 문법을 익히는 데 하루가 갔습니다. 마크다운 워크플로는 방향이 반대입니다. 사람 말로 쓰면 기계가 자기 언어로 컴파일해요.

인프라 설정이 프롬프트가 되는 흐름은 이미 여러 곳에서 보입니다. 의도 파일로 개발을 시작하는 SDLC 플레이북이 그랬고, 스킬 마크다운으로 조직 지식을 싣는 하네스들이 그랬어요. 이제 CI/CD 층까지 같은 문법이 내려온 겁니다.

다만 답글의 반박도 유효합니다. 레포 안 에이전트와 내 손의 에이전트, 어느 쪽이 표준이 될지는 열려 있어요. 확실한 건 하나입니다. 어느 쪽이 이기든, YAML을 손으로 쓰는 시대는 끝나가고 있습니다.

---

원문·소스

• 발표 트윗: https://x.com/GitHubNext/status/2092701389600264447
• 레포: https://github.com/github/gh-aw
• 문서: https://github.github.com/gh-aw/
• 샘플 모음: https://github.com/githubnext/agentics