요즘IT » AI » 피드

AI. vs 사람 맡길 일 고르는 기준 4가지

요즘 AI로 무엇을 만들고 계신가요?

반복 업무를 덜어 줄 스크립트 몇 개, 팀에서 같이 쓰는 도구 한두 개를 만들 수도 있고, 뭐든지 에이전트에게 통째로 넘겨 보기도 하죠. 그런데 맡기는 범위가 넓어질수록 다른 고민이 생깁니다. 같은 일을 돌릴 때마다 결과가 달라지고, “완료”라는 보고를 믿었다가 빠진 곳을 뒤늦게 발견하고, 만들어 둔 도구는 늘었는데 계속 손이 가는 건 몇 개 안 됩니다. 이제는 정말 ‘이것도 돼?’를 넘어서, 어디까지 맡기고 어떤 건 내가 꼭 해야 하는지를 정해야 할 때입니다.

이 질문에 딱 맞아 떨어지는 정답은 없습니다. 그래도 먼저 맡겨 보고, 자기만의 기준을 갖게 된 경험과 사고 과정을 기록해둔 사람들이 요즘IT에 있습니다. 매달 400페이지 점검철을 넘기던 사업관리 담당자, 웹페이지 진단 서비스를 만드는 팀, 법률 AI 서비스를 만든 디자이너, 5년 차 라이브 게임 조직의 기획자, 구현과 검증을 통째로 AI에게 맡겨 본 프론트엔드 개발자까지, 직무나 업무는 제각각입니다. 하지만 맡길 것과 맡기지 않을 것의 기준은 모두가 비슷했습니다.

이 글에서는 요즘IT에 2026년 5월부터 10월까지 실린 글 가운데, AI에 무엇을 맡기고, 무엇을 맡기지 않을지를 고민하고 나름의 기준을 만든 사례 아홉 편을 분석해 그 기준을 네 가지로 정리했습니다.

AI에게 맡길 가치가 있는 것을 맡긴다
정해진 답이 있는 일은 AI의 판단이 아닌 규칙으로 만든다
되돌리기 어려운 결정은 맡기지 않는다
언제 어디서 확인할지를 설계한다

1. AI에게 맡길 가치가 있는 것을 맡긴다

AI 자동화 이야기는 대개 “어떻게 만드나”에서 시작합니다. 그런데 먼저 해 본 사람들이 가장 오래 고민한 건 그보다 한 단계 앞이었습니다. 코딩이 본업이 아닌 사업관리 담당자 아이엠 조차장 작가는 넉 달 동안 업무 도구 열두 개를 만들고 나서야 “진짜 어려운 건 코드를 짜는 일이 아니라 손댈 일을 고르는 일”이라는 걸 알았다고 합니다.

작가가 세운 기준은 네 가지입니다.

얼마나 자주 하는가
한 번에 얼마나 오래 걸리는가
틀리면 얼마나 위험한가
다시 쓸 수 있는가

매달 마감 때마다 400페이지가 넘는 점검철 스캔본을 넘기며 서명이 빠진 곳을 찾는 일이 있었습니다. 할 때마다 30분~1시간이 걸리고, 하나만 놓쳐도 마감이 틀어지는 일이었죠. 이 일은 기준 네 가지 중 1~3번에 해당했습니다. 그래서 가장 먼저 만들었습니다. 하지만 1년에 한두 번 하는 다른 작업은 만들 수 있었지만 만들지 않았습니다.

아이엠 조차장 작가가 넉 달간 만든 자동화 도구 12개. ★는 작가가 글에서 대표 사례로 든 도구다. <출처: 아이엠 조차장, 「자동화할 일을 고르는 것도 실력이다」>

무엇을 만들지 골랐다고 해도 그걸 꼭 AI로 만들어야 하는 건 아닙니다. 게임 스튜디오에서 마케팅, 사업, 피플까지 맡고 있는 김현민 님은 코딩 에이전트 활용 사례를 공유하는 요즘IT의 클코나잇2(현 빌더나잇) 발표에서 “결국 AI는 도구이고, 문제 정의 역량이 중요하다.”고 강조했습니다.

그는 모든 것을 처음부터 클로드 코드로 해보지 않았습니다. 앱스크립트나 n8n으로 충분한 자동화도 많았기 때문입니다. 다만 매번 같은 환경 변수를 반복해 세팅해야 할 만큼 프로젝트가 늘어났을 때 비로소 클로드 코드가 필요하다고 느꼈다고 합니다. 그래서 “기존에 잘 돌아가고 있는 것을 꼭 클로드 코드로 다시 만들어야 할까”를 한 번씩 물어보라고 권합니다.

조직에서도 고르는 순서는 비슷했습니다. 라이브 게임 조직에서 일한 수께끼수 작가는, 데이터와 코드가 오래 얽힌 서비스에서는 큰 문제일수록 연관된 부분이 많아 손댔다가 다른 곳까지 흔들기 쉽다고 봅니다. 그래서 “가장 작은 것부터, 가장 귀찮은 것부터” 맡겼습니다. 엑셀 입력 실수를 줄이는 일, 코드를 분석해 유지보수 문서를 최신화하는 일처럼 서비스를 직접 건드리지 않는 일들이었죠.

그냥 하면 최소 2주가 걸렸을 문서 정리를 이틀 만에 끝내자 회의적이던 조직의 여론이 바뀌었다고 합니다. 개인적으로는 시간을 아낄 수 있었던 작업이기도 했지만, 조직을 설득할 근거를 만든 일이기도 했습니다.

2. 정해진 답이 있는 일은 AI의 판단이 아닌 규칙으로 만든다

맡길 일을 골랐다면 이제 통째로 AI에게 넘기면 될까요? 여기서 많은 사람이 한 번씩 실수를 합니다. AI 검색 노출을 진단하는 서비스를 만드는 zurang23 작가의 팀은 처음에 진단을 거의 통째로 AI에게 맡겼습니다. 그런데 결과가 매번 달랐습니다. 같은 페이지를 세 번 돌렸는데, 점수가 72점, 85점, 61점으로 나온 거죠. 데모에서는 근사했지만 돈을 내는 고객이 믿어 줄 수 없는 숫자였습니다.

팀은 일을 둘로 나눴습니다. robots.txt 파일이 있는지, 특정 태그가 들어 있는지처럼 답이 정해진 사실은 코드가 확인하고, ‘콘텐츠가 믿을 만한지’처럼 판단이 필요한 것만 AI에게 맡겼어요. 작가는 돌아보면 AI를 더 똑똑하게 만든 게 아니라 “AI가 틀려도 괜찮은 자리와 절대 틀리면 안 되는 자리를 나눈 것”이었다고 정리합니다.

zurang23 작가 팀이 나눈 진단 역할. 확인할 수 있는 사실은 코드가, 판단은 범위를 좁힌 AI가 맡는다. <출처: zurang23, 「AI 진단의 신뢰도를 높인 건 AI에게 덜 맡기는 것이었다」>

프론트엔드 개발자 김의중 작가도 비슷한 경험이 있습니다. 그의 기준은 “결정론적인 일은 자동화에, 추론이 필요한 일은 AI에”입니다. 결정론적인 일이란 입력이 같으면 결과도 늘 같아야 하는 일을 말합니다. 작가는 이 기준을 확인하려고 실제 프로젝트의 OpenAPI 스펙(서버와 화면이 주고받을 데이터 규격을 적은 문서)으로 API 연동 코드를 두 가지 방법으로 만들어 비교했습니다. 하나는 Orval이라는 코드 생성기입니다. AI가 아니라, 스펙을 미리 정해진 변환 규칙대로 코드로 옮기는 프로그램이죠. 다른 하나는 같은 스펙을 AI에게 주고 코드를 짜게 한 것입니다.

결과는 차이가 컸습니다. 코드 생성기는 약 1초 만에, 비용 없이 코드를 만들었고 몇 번을 다시 돌려도 똑같은 코드가 나왔습니다. AI는 같은 일에 2~4분이 걸렸고, 돌릴 때마다 약 1.4달러가 들었습니다. 그런데 두 번 돌린 결과가 서로 달랐고, 그중 한 번은 타입 에러를 4개 남겼습니다. 시간도 돈도 더 들었는데 결과는 매번 달랐던 거죠. 스펙이라는 정답지가 이미 있는 일에서는 규칙대로 옮기는 프로그램이 AI보다 빠르고, 싸고, 정확했습니다. 작가는 이렇게 결정론적인 토대를 깔아 두면 그 위에서 AI가 판단이 필요한 일을 더 정확하게 한다고 결론짓습니다.

같은 OpenAPI 스펙으로 코드 생성기(Orval)와 AI가 각각 코드를 만들게 해 비교한 결과 <출처: 김의중, 「AI 시대의 엔지니어링: 이 일, 정말 AI에 시켜야 하는가?」>

그런데 규칙을 정하는 일에는 AI를 활용할 수 있습니다. 앞서 소개한 사업관리 담당자 아이엠 조차장 작가는 점검철 서명 검사를 자동화하려고 서명 검사 도구를 만들었습니다. 400페이지가 넘는 스캔본에서 표지를 골라내고, 표지 아래 서명란 두 칸이 비었는지 확인하는 도구입니다. 이 도구는 서명란에 잉크가 얼마나 묻었는지를 숫자로 재서 서명이 있는지 판정합니다. 매번 AI에게 서명이 있는지 묻는 대신 정해진 규칙으로 판정하게 한 거죠. 그런데 그 규칙을 짠 사람은 개발자가 아니라, 클로드 코드와 대화하며 설계를 잡은 작가 자신이었어요. 정해진 답이 있는 일은 AI가 그때그때 판단하게 두지 않고 규칙으로 고정하되, 그 규칙을 만드는 데는 얼마든지 AI를 쓸 수 있다는 것. 세 작가 모두 경험을 통해 결론 지었습니다.

3. 되돌리기 어려운 결정은 사람에게 남긴다

그럼 정답이 없는 일, 판단이 필요한 일은 AI에게 맡겨도 될까요? 먼저 해 본 사람들은 우선 ‘AI가 틀렸을 때 무엇이 망가지는지’를 확인했습니다. 디자이너 Sarah 작가가 만든 로윈은 판례 기반 법률 AI 서비스입니다. 사용자가 자기 사연을 입력하면 비슷한 실제 판례를 찾아 쟁점과 대응 전략을 짚어 주고, 가장 깊은 단계에서는 변호사 상담으로 연결해 줍니다. 작가는 이 서비스를 만들며 “AI가 틀렸을 때 사람이 되돌릴 수 있는 지점까지만 AI에 맡긴다.”는 기준을 세웠습니다. 쟁점 정리는 틀려도 변호사 상담에서 바로잡을 수 있으니 AI의 몫이지만, 소송을 할지 말지는 틀리면 되돌리기 어려우니 끝까지 사람의 몫으로 남겼어요.

그래서 이 서비스는 승소를 약속하는 문장을 쓰지 않고, 사용자가 가장 많은 돈을 내는 마지막 단계의 마지막 버튼도 더 똑똑한 AI가 아니라 변호사 연결로 두었습니다. 반대로 작가가 따로 만들고 있는 직장 생존 유형 진단 서비스처럼, 결과가 틀려도 사용자가 웃고 넘기는 가벼운 서비스에서는 AI에게 넓은 무대를 준다고 합니다. 되돌리기 어렵다는 건 곧 틀렸을 때 치를 대가가 크다는 뜻입니다. 그래서 대가가 작은 곳에서는 AI에게 많이 맡기고, 소송처럼 틀리면 인생이 걸린 곳에서는 사람이 결정하게 두는 거죠. 작가의 말대로 “경계선의 위치를 결정하는 건 AI의 성능이 아니라 오류의 비용”입니다.

로윈의 변호사 상담용 요약 화면. AI가 쟁점을 정리하되, 끝에 참고용이며 법적 효력이 없다고 밝힌다. <출처: Sarah, 「내가 일부러 AI에게 맡기지 않은 것들」(화면: 로윈)>

사람을 상대하는 사내 업무에서도 비슷합니다. Un 작가가 인터뷰한 클래스메소드의 HR 담당자 박동현 님은 평가 내용 정리나 급여 데이터 처리 같은 반복 업무는 AI 에이전트로 자동화했지만, 직원 갈등이나 갑작스러운 퇴사 상담처럼 정답이 없는 일에서는 동료에게 묻듯 의견을 구하는 데까지만 AI를 씁니다. 평가나 급여 처리는 자동화할 수 있어도 “최종 판단이나 직원과의 소통은 결국 사람의 몫”이라는 게 박동현 님의 답이에요.

개발 현장에서는 이 기준이 더 구체적인 모습으로 나타납니다. 꼼비 작가는 기획 문서와 디자인 시안(Figma)에서 요구사항을 뽑고, 구현하고, 테스트까지 이어서 AI가 처리하게 하는 개발 도구(하네스 플러그인 code-forge)를 직접 만들었습니다. “구현과 검증은 모두 AI가 맡았다.”고 할 만큼 개발을 통째로 넘겨 본 셈이죠. 그런데 그 흐름 안에서도 애매한 비즈니스 정책은 작가가 직접 정했고, 커밋·푸시와 PR 생성은 작가가 승인한 뒤에야 진행됐으며, 작업을 끝내도 될지도 마지막에 작가가 판단했습니다. 제품 코드나 정책을 고쳐야 한다는 결론이 나오면 도구는 직접 고치지 않고 변경 범위와 재현 근거만 넘기게 해 두었고요.

꼼비 작가의 AI 개발 흐름. 단계마다 AI가 맡는 일과 사람이 확인하는 일이 나뉘어 있다. <출처: 꼼비, 「AI에게 처음부터 끝까지 개발을 맡겼습니다」>

수께끼수 작가도 지금 수준에서 넘지 말아야 할 선을 따로 적어 둡니다. 실사용자 데이터와 서비스 데이터베이스를 AI가 직접 고치도록 자동화하는 일은 아직 하지 말아야 한다는 겁니다. 읽어서 정리하는 데까지는 괜찮지만, 사람 확인 없이 데이터를 바꾸게 두면 오래 얽힌 구조를 AI가 다 파악하지 못한 채 건드려 다른 곳까지 흔드는 사고가 그대로 되풀이된다는 이유에서죠. 맡기는 범위가 넓은 사람일수록, 되돌리기 어려운 지점에는 오히려 더 명확하게 사람의 역할을 두고 있었습니다.

4. 언제 어디서 확인할지를 설계한다

이제 명확한 기준을 갖고 맡겼다면 손을 떼도 될까요? 그렇지 않습니다. 앞서 소개한 꼼비 작가의 개발 도구는 요구사항 정리부터 구현, 테스트까지 AI가 이어서 처리합니다. 이 도구가 작성한 테스트(Jest)가 전부 통과하자 “개발 완료”를 보고했지만, 요구사항 명세 40개 가운데 코드에 실제로 들어간 건 25개였습니다. 테스트가 이미 구현된 동작만 검사했으니 빠진 기능은 어디서도 실패로 잡히지 않았던 거예요.

그 뒤로 작가는 요구사항마다 수용 조건, 테스트, 코드가 어디에 연결되는지 적은 추적표를 AI에게 만들게 하고, 빠진 연결은 자신이 확인합니다. “요즘은 전체 PASS 보고를 받으면 요구사항 추적표를 먼저 연다.”고 해요. 같은 시나리오가 아홉 번 실패하면 AI가 더 붙잡지 않고 로그와 판단 근거를 들고 작가에게 묻게 하기도 했습니다.

언제 어디서 확인해야 할지를 설계하는 방식은 사람마다 달랐습니다. 아이엠 조차장 작가의 서명 검사 도구는 표지를 찾아 서명 부분만 잘라 결과 보고서 한 장(HTML 파일)에 모으고, 서명이 있는지 애매한 것만 빨갛게 표시해 보고서 맨 위에 올립니다. 사람은 그 위쪽만 눈으로 확인하면 되죠. 출근부와 휴가 신청서를 대조하는 도구도 결과를 대시보드 형태의 보고서로 보여 주는데, 여기서도 두 서류가 서로 어긋난 것만 붉게 띄웁니다. 작가는 “빠뜨리느니, 차라리 좀 더 보여주자.”는 원칙으로 애매하면 무조건 사람이 한 번 더 보도록 했고, 이렇게 하자 “AI한테 다 시키자”고 했던 때보다 “더 정직하고 실제로 더 빨랐다”고 말합니다.

서명 검사 결과 화면(재구성). 407페이지에서 표지 68건을 찾아 66건은 자동으로 확인하고, 애매한 2건만 맨 위에 올려 사람이 본다. <출처: 아이엠 조차장, 「자동화할 일을 고르는 것도 실력이다」>

출근부·휴가 신청서 대조 대시보드(가명). 어긋나거나 확인이 필요한 항목만 붉게, 노랗게 표시된다. <출처: 아이엠 조차장, 「자동화할 일을 고르는 것도 실력이다」>

AI가 무서운 속도로 텍스트와 코드를 생성하는데, 사람이 그 속도를 따라잡지 못하기 때문에 ‘사람이 병목’이라는 말도 나오는 요즘인데요. 그렇다고 모든 확인을 사람이 해야 한다는 뜻은 아닙니다. 김의중 작가가 제안하는 개발 흐름에서는 스펙이 바뀌면 코드 생성기가 타입을 갱신하고, 컴파일 에러가 난 곳을 AI 에이전트가 고치는 데까지 사람 손을 거치지 않고 이어집니다. 다만 여기서도 AI가 막연히 추측하는 게 아니라, 결정론적인 도구가 어디가 고장 났는지 먼저 짚어 준다는 전제가 있어요.

사람이 직접 보든 규칙을 정해두든, 아홉 작가 모두 AI의 결과를 묻지도 따지지도 않고 믿는 게 아니라, 확인하는 지점을 따로 설계해 두었습니다. 꼼비 작가의 말처럼 제품 코드를 직접 치는 시간은 줄었어도 “전보다 더 많이 생각하고, 키보드도 더 많이 친다.”는 게 이렇게 AI에 일을 맡긴 사람들의 공통된 경험이었습니다.

AI에 일을 맡길 때 고려해야 할 4가지

아홉 가지 사례에서 작가들은 모두 AI가 얼마나 똑똑한지보다 내가 AI에게 맡기려는 그 일이 어떤 성격인지를 먼저 따졌습니다. 자주, 오래, 위험하게 반복되는 일인지 보고, 정해진 답이 있으면 규칙으로 묶고, 틀렸을 때 되돌리기 어려우면 결정을 사람에게 남기고, 맡긴 일에는 확인할 지점을 따로 만들었습니다. AI에게 맡긴다는 건 사람의 일이 사라지는 게 아니라, 사람이 봐야 할 곳이 좁고 분명해지는 일이었던 것입니다.

그러니 지금 맡길까 말까 망설이는 일이 있다면, 아홉 작가가 그은 네 가지 기준에 그 일을 하나씩 대 보면 어떨까요?

1. 맡길 가치가 있는 일인가: 자주, 오래, 위험하게 반복되는 일인지 보세요. 1년에 한두 번이라면 도구를 만들고 관리하는 품이 더 클 수 있어요.
2. 정해진 답이 있는 일인가: 있다면 AI가 매번 판단하게 두기보다 규칙으로 고정할 수 있는지 먼저 보고, 그 규칙은 AI와 함께 만들어도 됩니다.
3. 틀리면 되돌릴 수 있는 일인가: 되돌리기 어렵다면 AI에게는 자료를 모으고 정리하는 데까지만 맡기고, 결정과 승인은 사람에게 남겨 두세요.
4. 어디서 확인할 것인가: “완료” 보고만 믿지 말고, 결과를 언제 어디서 확인할지 맡기기 전에 정해 두세요. 사람이 직접 볼지, 규칙이 대신 볼지도 함께요.

지금 내 상황이라면 이 글부터

만들 수 있는 건 많은데 무엇을 계속 키울지 가늠이 안 된다면

아이엠 조차장 작가의 「자동화할 일을 고르는 것도 실력이다」부터 읽어 보세요. 지금 만들려는 도구, 이미 만들어 둔 도구를 작가의 네 가지 기준에 대 보면 공들일 것과 손을 뗄 것이 갈립니다.
무엇으로 만들지가 고민이라면 김현민 님의 발표를 정리한 「AI 도구 26개를 직접 만들며 알게 된 자동화 노하우」가 문제 정의부터 도구 고르기까지 이어 줘요.

AI에게 맡겼더니 결과가 돌릴 때마다 다르다면

zurang23 작가의 「AI 진단의 신뢰도를 높인 건 AI에게 덜 맡기는 것이었다」에서 사실과 판단을 가르다 만난 함정들을, 김의중 작가의 「AI 시대의 엔지니어링: 이 일, 정말 AI에 시켜야 하는가?」에서 코드 생성기와 AI를 직접 비교한 수치를 볼 수 있어요.
개발자가 아니라면 아이엠 조차장 작가의 「비개발자가 400페이지 서명 검사를 자동화하며 고민한 것」에서 다섯 번 넘어지며 도구의 역할을 줄여 간 과정을 따라가 보세요.

개발을 크게 맡겨 봤는데 “완료” 보고를 믿어도 될지 모르겠다면

꼼비 작가의 「AI에게 처음부터 끝까지 개발을 맡겼습니다」가 맞습니다. 테스트가 다 통과했는데도 기능이 빠졌던 이유와, 그 뒤 완료 조건을 어떻게 바꿨는지까지 적혀 있어요.

틀리면 되돌리기 어려운 일을 다룬다면

서비스 기획자는 Sarah 작가의 「내가 일부러 AI에게 맡기지 않은 것들」을, 사람을 상대하는 업무 담당자는 Un 작가가 박동현 님을 인터뷰한 「일본 IT 기업의 HR 담당자가 AI로 업무를 혁신한 방법」을 읽어 보세요.
위에서는 쓰라는데 팀은 사고가 무섭다면 수께끼수 작가의 「리더는 “AI 왜 안 쓰냐” VS 실무자는 “사고 나면요?”」가 리더와 실무자가 각자 무엇을 조정해야 하는지까지 짚어 줍니다.

여러분은 지금 무엇을 AI에게 맡기고, 무엇을 일부러 맡기지 않고 있나요? “우리 팀은 이 일까지는 AI에게 맡기고, 여기서부터는 사람이 본다”는 기준이 있다면, 그렇게 정한 이유를 요즘IT에 댓글, 이메일(yozm@wishket.com) 등을 통해 들려 주세요. 다음 레퍼런스로 함께 나누겠습니다.

요즘IT 뉴스레터 받아보기

먼저 해 본 사람들의 AI 실무 레퍼런스를 매주 목요일에 보내 드려요. 요즘IT에 가입하면 뉴스레터를 받아볼 수 있어요.

[요즘IT 가입하고 뉴스레터 받기]

이 글은 AI의 도움을 받아 작성했습니다.

]]>

개발자들이 더 이상 질문하지 않는다면

안녕하세요, 요즘 프로덕트 메이커입니다.

프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: HackerTube - 카파시가 클로드와 대화만으로 2시간 만에 만든 해커뉴스판 유튜브
참고할 것: 스택오버플로 새 질문이 한 달 1,000개 안팎으로 줄었다, 개발자는 이제 어디서 답을 찾을까
적용해볼 것: AI가 95%를 맡으면, 사람은 남은 5%를 감당할 수 있을까

<출처: HackerTube>

1. 써볼 것: 카파시가 클로드와 대화만으로 2시간 만에 만든 해커뉴스판 유튜브

퇴근하고 유튜브를 켰는데 과장된 썸네일과 매번 비슷한 추천 영상만 이어져서, 볼 만한 걸 찾다가 그냥 끈 적이 있을 거예요. 오픈AI 공동 창업자이자 테슬라에서 AI를 이끌었던 안드레이 카파시(Andrej Karpathy)도 그랬다고 합니다. 10월 30일 금요일 밤 11시, 카파시는 유튜브 첫 화면을 보다가 이 추천 방식이 인터넷의 평균적인 사람에게는 잘 맞을지 몰라도 자기에게는 맞지 않는다는 걸 깨달았죠.

해커뉴스(Hacker News)는 개발자와 창업자가 많이 모이는 미국의 기술 커뮤니티예요. 다음 날 아침, 카파시는 클로드 오퍼스 5.5에게 "해커뉴스에서 추천된 영상으로 우리만의 유튜브를 만들자"며 일을 맡겼습니다. 그렇게 나온 사이트가 HackerTube입니다. 카파시가 10월 31일 블로그에 공개했고, 해커뉴스에서 2,877점을 받았습니다.

무엇이 들어 있나요?

HackerTube에는 2007년부터 올해까지 해커뉴스 댓글 가운데 유튜브 영상을 추천한 댓글 약 4만 개를 모아, 여러 사람이 추천한 영상 6,454개를 주제 150개로 나눠 담았습니다. 화면은 유튜브와 거의 같지만 몇 가지가 다릅니다.

올린 사람이 고른 썸네일 대신, 영상 길이의 한가운데 장면을 썸네일로 씁니다. 카파시가 불만으로 꼽은 과장된 썸네일을 피하려는 것으로 보입니다.
회원가입 없이도 내 취향에 맞춘 추천을 받을 수 있습니다. 시청 기록은 서버가 아니라 내 브라우저에만 저장됩니다.
키보드 단축키로 조작할 수 있습니다.
사이트 데이터를 내려받을 수 있습니다. 카파시는 이 데이터를 AI 에이전트에게 주면 나만의 버전을 쉽게 만들 수 있다고 적었어요.

카파시는 무엇을 직접 했나요?

카파시가 블로그에 덧붙인 설명에 따르면, 이제 코드를 읽거나 쓰고 터미널에 명령어를 입력하는 식의 개발을 거의 하지 않습니다. 앤트로픽의 AI 코딩 도구인 클로드 코드(Claude Code)의 맥용 데스크톱 앱에서 오퍼스 5.5와 대화만 하며 모든 일을 맡긴다고 해요.

HackerTube를 만들 때도 해커뉴스 댓글을 모두 내려받아 거르는 일은 클로드가 했습니다. 이어서 클로드 코드의 워크플로(Workflow) 기능으로 여러 AI 작업을 한꺼번에 돌려, 더 저렴한 모델인 소넷이 댓글을 하나하나 읽고 스팸을 걸러내게 했습니다. 유튜브처럼 보이는 화면도 클로드가 만들었어요. 전체 작업에는 약 2시간이 걸렸습니다.

카파시가 직접 한 일은 세 가지였습니다.

유튜브 영상 정보를 불러올 때 필요한 인증 값(API 키)을 구글 클라우드에서 발급받기
사이트를 올릴 가상 서버(VPS) 켜기
도메인 구매하기

세 가지 모두 본인 계정으로 가입하거나 결제해야 하는 일이라 AI에게 넘기기 어려웠던 것으로 보입니다. 서버가 준비되자 그 주소만 알려주고, 사이트를 서버에 올려 보안을 설정하고 속도를 높이는 일은 다시 클로드에게 맡겼습니다. 카파시는 이 일들을 클로드가 일하는 사이사이에 처리해서 "조금은 팀으로 일하는 느낌"이었다고 적었습니다.

HackerTube를 보고 다른 사람들도 만들었습니다

HackerTube가 화제가 되자 비슷한 사이트가 사흘 사이에 잇따라 나왔습니다.

HackerBooks(11월 1일): 해커뉴스 댓글에서 두 명 이상이 언급한 책 약 1만 6,500권을 모았습니다. 책마다 그 책을 언급한 댓글로 연결됩니다. 만든 사람은 데이터 처리부터 사이트까지 거의 다 클로드가 만들었고, 자신은 주로 방향을 정하고 판단을 내렸으며 도메인을 샀다고 밝혔어요. 언급 횟수만 세기 때문에 책을 칭찬한 댓글과 비판한 댓글이 똑같이 한 번으로 잡힌다는 한계도 함께 적었습니다.
Wikihack(11월 2일): 해커뉴스 댓글에서 여러 사람이 링크한 위키백과 문서를 많이 링크된 순서대로 보여줍니다.
HackerTV(11월 3일): HackerTube의 영상 데이터를 주제별 채널로 묶어 24시간 방송처럼 틀어줍니다. 고르지 않고 채널을 돌리며 보고 싶었다는 게 만든 이유였어요. 밤 11시부터 새벽 5시까지만 방송하는 심야 채널도 있습니다. 이 사이트도 클로드 코드로 몇 시간 만에 만들었습니다.

누구에게 좋을까요?

추천 알고리즘에 지쳐서 오래 볼 만한 강연이나 다큐멘터리를 찾는 사람. hackertube.org에 들어가면 가입 없이 바로 볼 수 있습니다.
사이드 프로젝트를 구상 중인 기획자와 디자이너. 공개 데이터와 AI 코딩 도구만으로 2시간 만에 서비스 하나를 만든 과정과, 사람이 직접 해야 했던 일이 무엇이었는지 참고할 수 있습니다.
커뮤니티나 콘텐츠를 운영하는 사람. 우리 서비스 댓글에 쌓인 추천을 모아 보여주는 서비스도 같은 방식으로 만들어볼 수 있습니다.
다만 영상 대부분이 영어이고, 해커뉴스 사용자의 관심사인 개발, 과학, 공학 쪽에 치우쳐 있습니다. 카파시는 사이트를 만들고 운영하는 데 든 비용은 밝히지 않았습니다.

<출처: Stack Exchange API>

2. 참고할 것: 스택오버플로 새 질문이 한 달 1,000개 안팎으로 줄었다, 개발자는 이제 어디서 답을 찾을까

개발자라면 에러 메시지를 그대로 검색창에 붙여넣었다가 스택오버플로(Stack Overflow) 답변에서 해결법을 찾은 경험이 한 번쯤 있을 거예요. 스택오버플로는 2008년 문을 연 개발자 질문·답변 사이트입니다. 10월 말, 이 사이트에 올라오는 새 질문이 한 달 1,000개도 안 된다는 그래프가 개발자 커뮤니티에서 화제가 됐습니다.

얼마나 줄었나요?

스택오버플로가 외부에 공개한 데이터 조회 기능(API)으로 월별 새 질문 수를 직접 세어봤습니다(11월 5일 기준).

질문이 가장 많던 무렵인 2014년 3월에는 한 달에 20만 7,169개가 올라왔습니다.
ChatGPT가 공개되기 직전인 2022년 10월에는 10만 5,743개였습니다.
올해 9월에는 964개, 10월에는 1,001개였습니다.

ChatGPT가 나오고 4년이 채 안 돼 질문 수가 100분의 1 수준으로 줄었어요. 다만 이 숫자에는 삭제된 질문이 빠져 있어서, 같은 달이라도 집계한 날짜와 사람에 따라 숫자가 조금씩 다릅니다.

원인은 AI뿐일까요?

질문 수는 ChatGPT 이전부터 줄고 있었습니다. 2017년 3월 20만 1,343개였던 질문이 2022년 3월에는 12만 3,260개로, 이미 40% 가까이 줄어 있었어요. AI가 감소를 크게 앞당긴 건 분명해 보이지만, 줄어들기 시작한 건 그전부터였습니다.

개발자들 사이에서는 운영 문화를 원인으로 꼽는 목소리도 오래 있었습니다. 질문하러 온 사람에게 날 선 답을 달거나 질문을 쉽게 닫아버리는 일이 잦았다는 거예요. 미국 개발 매체 데브클래스(DevClass)는 1월 기사에서 한 개발자의 말을 인용했습니다. "AI가 감소를 앞당긴 건 맞지만, 이건 커뮤니티에 참여하려는 사용자에게 꾸준히 벌을 줘온 결과다. 사람들은 마침내 질문이 멍청하다고 말하지 않는 도구가 생겨서 그저 반가웠던 것이다."

개발자들은 이제 어디서 답을 찾나요?

스택오버플로가 10월 6일 발표한 2026 개발자 설문(3만 명 이상 응답)에서도 개발자가 답을 찾는 방법이 달라진 게 보입니다.

막혔을 때 검색엔진을 찾는다는 응답은 83%, AI에게 묻는다는 응답은 70%였습니다.
업무에 필요한 답은 동료(72%), 코드(63%), 문서(60%)에서 찾는다는 응답이 많았습니다.
간단한 질문 때문에 스택오버플로를 찾는 일은 줄었다는 응답이 64%였습니다. 반대로 AI가 준 답의 출처를 확인하려고 더 자주 찾는다는 응답도 16% 있었어요.
AI가 준 결과를 믿으려면 출처 표시가 필요하다는 응답은 93%였습니다.

스택오버플로는 설문 결과를 소개하며, 예전에는 검색엔진이 사람들을 스택오버플로 질문으로 데려왔지만 검색 결과 위에 뜨는 AI 요약과 챗봇은 그러지 않는다고 적었습니다. AI는 여전히 스택오버플로의 답변을 쓰지만, 답을 단 사람에게 늘 공을 돌리지는 않는다고도 덧붙였습니다.

스택오버플로는 어떻게 답했나요?

10월 29일, 스택오버플로는 공식 블로그에 "스택오버플로가 죽었다는 소문은 과장됐다"는 글을 올렸습니다. 스택오버플로가 죽었다고 보는 사람들은 지식을 찾는 방법이 바뀐 것을, 그 지식과 회사가 사라진 것으로 착각하고 있다는 주장이에요. 글에 따르면 질문·답변 사이트는 회사 사업의 일부일 뿐입니다.

사람이 검증한 스택오버플로의 답변은 AI 모델을 학습시키고, AI가 답할 때 참고 자료를 찾아오는 기능을 개선하는 데 쓰입니다. 스택오버플로는 이 데이터를 AI 회사에 라이선스로 판매하고 있습니다.
기업용 서비스 스택 인터널(Stack Internal)의 새 버전을 9월에 냈습니다. 회사 안의 지식을 모아 출처와 신뢰 표시를 붙이고, 확인이 필요하면 사내 전문가를 연결해주는 서비스입니다.
AI 에이전트끼리 지식을 나누고 해결책을 검증하는 Stack Overflow for Agents를 베타로 열었습니다.

회사는 답을 찾으러 들르는 웹사이트를 넘어, 개발자와 회사, AI가 함께 쓰는 지식 서비스로 바뀌는 중이라고 설명했습니다.

무엇을 얻어가면 될까요?

제품의 도움말 센터나 사용자 커뮤니티를 운영하고 있다면 같은 일이 생길 수 있습니다. 사용자가 궁금한 걸 AI에게 먼저 물으면, 간단한 질문 때문에 도움말 페이지에 들어오는 사람은 줄어들 거예요. 그래도 설문에 응답한 개발자의 93%가 AI의 답을 믿으려면 출처가 필요하다고 답했습니다. 사람이 확인한 답변은 AI가 인용하는 출처로 여전히 쓸모가 있을 것으로 보입니다.

<출처: SigNoz Observability Real Talk>

3. 적용해볼 것: AI가 95%를 맡으면, 사람은 남은 5%를 감당할 수 있을까

회의록 요약, 데이터 정리, 문서 초안을 AI에게 맡기는 게 이제 익숙해졌습니다. 그런데 어느 날 AI가 풀지 못하는 일이 생기면, 그 일을 직접 해낼 수 있을까요? 이 질문을 다룬 글이 최근 개발자 커뮤니티에서 다시 화제가 됐습니다. 오픈소스 관측 도구 SigNoz의 뉴스레터에 올해 2월 실린 글로, 제목은 "AI는 SRE를 대체하는 게 아니라, SRE의 실력을 떨어뜨리고 있다"입니다.

SRE(사이트 신뢰성 엔지니어)는 서비스가 멈추지 않게 운영하고, 장애가 나면 원인을 찾아 복구하는 엔지니어입니다. 관측 도구는 서버의 상태 지표와 기록(로그)을 모아 보여주며 이 일을 돕습니다. 글은 SRE를 예로 들지만, 글쓴이도 이 이야기가 SRE에만 해당하지 않는다고 말합니다.

1983년 논문은 무엇을 말했나요?

글쓴이는 1983년 영국 인지심리학자 리잰 베인브리지(Lisanne Bainbridge)가 쓴 논문 「자동화의 아이러니」에서 출발합니다. 베인브리지는 공장과 산업 설비가 자동화된 뒤 그곳에서 일하는 사람에게 무슨 일이 생겼는지 살폈어요.

자동화할수록 사람이 할 일은 줄어듭니다. 하지만 자동화가 실패하는 드문 순간에는 사람이 나서야 하고, 그 순간의 판단은 오히려 더 중요해집니다. 문제는 평소에 그 일을 해볼 기회가 없으니, 정작 나서야 할 때 더 서툴러진다는 점이에요. 그래서 베인브리지는 사람이 오랫동안 지켜보기만 하다가 가끔 터지는 위기만 떠맡게 된다고 봤습니다.

SigNoz 글쓴이가 출발점으로 삼은 「자동화의 아이러니」 논문 소개 <출처: SigNoz Observability Real Talk>

SRE의 일도 비슷하게 바뀌고 있습니다. 쏟아지는 알림을 묶어 정리하고, 해결법이 알려진 문제에 정해진 대응 절차를 실행하고, 로그에서 이상한 패턴을 찾는 일은 이미 상당 부분 자동화됐어요. 장애 알림 서비스 페이저듀티(PagerDuty)는 장애를 세 단계로 나눠 설명합니다.

원인과 해결법을 아는 장애는 완전히 자동으로 처리합니다.
일부만 이해한 문제는 AI가 해결책을 제안하고 사람이 확인합니다.
처음 보는 복잡한 장애는 사람이 주도하고 AI가 정보를 보탭니다.

글쓴이는 여기서 묻습니다. 사람이 처음 보는 장애만 맡게 된다면, 그런 장애를 다룰 감각은 어디서 기를 수 있을까요? 그 감각은 수년 동안 장애에 직접 대응하며 같은 패턴을 반복해서 겪어야 생기는 것이니까요.

다른 분야에서는 무슨 일이 있었나요?

글쓴이는 다른 분야의 연구도 함께 소개합니다.

의료: 의학 학술지 「랜싯 소화기학·간장학(The Lancet Gastroenterology & Hepatology)」에 실린 연구에서, 대장 내시경 때 AI와 함께 검사한 뒤로 의사들은 AI 없이 검사할 때 용종을 찾아내는 비율이 28%에서 22%로 떨어졌습니다. 이론을 잊어서가 아니라 직접 찾는 연습을 덜 하게 돼서였다고 글쓴이는 설명합니다.
항공: 자동 비행 장치에 많이 기대는 장거리 노선 조종사들은 주변 상황을 파악하는 능력과 손으로 비행기를 다루는 실력이 떨어졌다는 연구가 있습니다. 글쓴이에 따르면 미국 연방항공청(FAA)은 이 때문에 수동 비행 시간을 늘리도록 했습니다.

글쓴이는 자기 이야기도 털어놓습니다. 지난 1년 사이 AI가 가끔 꺼내 쓰는 도구에서 늘 가장 먼저 손이 가는 도구가 됐고, 이제는 AI에게 맡길 수 없는 일에만 머리를 쓰다 보니 생각하는 힘이 무뎌진 게 느껴진다고요.

더 위험한 건 실력이 떨어지는 걸 본인이 알아채기 어렵다는 점입니다. AI 덕분에 일이 쉬워지고 결과도 좋아 보이니, 실제 실력이 어느 정도인지 가늠하기 힘듭니다. SRE라면 AI가 요약해주니 원본 로그를 읽지 않게 되고, AI가 원인을 제안해주니 장애 중에 스스로 가설을 세우지 않게 됩니다. 하나하나는 일이 빨라진 것처럼 보이지만, 이런 일이 쌓이면 예상 못 한 장애를 다룰 실력이 사라지죠.

글쓴이는 "never-skilling"이라는 말도 소개합니다. 이미 갖고 있던 실력을 잃는 게 아니라, 처음부터 실력을 쌓지 못하는 문제예요. AI가 대응을 대부분 맡는 환경에서 일을 시작한 신입은 직접 부딪히며 감각을 기를 기회가 거의 없습니다.

반대 의견도 있습니다. 원문에 달린 한 댓글은 "AI 도입이 앞으로 나아갈 유일한 길"이라는 글쓴이의 전제를 이 글의 약점으로 꼽았어요. AI를 쓰는 게 이미 정해진 결론처럼 여겨지는 게 불편하다며, 필요한 곳에만 도구를 만들어 쓰던 예전 방식으로는 왜 안 되느냐고 물었습니다.

무엇을 생각해볼 수 있을까요?

글쓴이는 AI를 쓰지 말자는 게 아니라고 분명히 하면서 두 가지를 제안합니다. 여기에 AI 기능을 만드는 쪽에서 생각해볼 점을 하나 더했습니다.

첫째, 일부러 비효율을 남겨둡니다. 자동 비행 장치가 있어도 조종사에게 수동 비행 시간을 두게 하는 것처럼, AI가 처리할 수 있는 장애 가운데 일부는 사람이 연습 삼아 직접 맡는 방식입니다. 가장 빠른 해결은 조금 포기하더라도, 길게 보고 실력을 유지하는 데 시간을 쓰자는 제안이에요.

둘째, 사람이 AI의 결과를 승인만 하지 않고 문제를 함께 풀게 합니다. AI의 제안에 승인 버튼만 누르는 구조에서는 사람이 지켜보는 역할로 밀려나고, 앞서 본 「자동화의 아이러니」 논문이 말한 것처럼 주의력이 점점 떨어집니다. 사람이 직접 문제를 들여다보고 AI와 함께 원인을 좁혀가는 구조여야 생각을 멈추지 않는다는 이야기입니다.

셋째, 이 고민은 AI 기능을 만드는 쪽에도 해당합니다. SigNoz는 자기 제품에 AI를 넣으면서, 처음에는 사람이 통제하는 보조 기능으로 시작하고 신뢰가 쌓이는 만큼 AI가 스스로 하는 일을 넓히겠다고 밝혔어요. 자사 제품 이야기라는 점은 감안하고 보면 좋겠습니다. 다만 AI 기능을 만들고 있다면, 그 기능이 사용자의 어떤 실력을 대신하는지는 따져볼 만합니다.

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

이 글은 AI의 도움을 받아 작성했습니다.

]]>

커서 엔지니어가 한 달 PR 2,500개 머지한 방법(내 저장소에 붙여 보니)

2026년 9월 22일,X에 영상 하나가 올라왔습니다. “지난달 PR 2,500개를 프로덕션에 배포한 방법”이라는 제목이었죠. 글쓴이는 커서에서 일하는 로런 탠이었습니다. 영상 길이는 38분이었고, 한 달 사이 조회 수 400만 회를 넘겼습니다.

그런데 영상보다 답글 하나에 먼저 눈길이 갔습니다. 한 사용자가 “PR 2,500개면 리뷰어한테는 지옥 아닌가요?”라고 물었고, 로런 탠은 “제 에이전트들이 자기 PR을 직접 머지해요. 사람 리뷰는 없어요.”라고 짧게 답했습니다.

로런 탠이 X에 고정한 게시물과 영상 첫 화면 <출처: lauren(@poteto) X>

리뷰어 부담을 묻는 질문에 사람 리뷰가 없다고 답한 장면 <출처: lauren(@poteto) X>

이 답글을 보고 제 작업 화면이 먼저 떠올랐습니다. 저는 요즘 기업 교육 서비스인 에이전트 아카데미의 강의실과 과제 평가 시스템을 에이전트와 함께 만들고 있습니다. 해커톤 과제 평가 기능을 붙이던 주에는 열흘 남짓한 사이에 PR이 서른 개 가까이 쌓였죠. 모두 제가 맡긴 작업인데도 diff를 한 줄씩 읽고 머지하는 일이 가장 늦게 끝났습니다. 다 읽자니 다음 작업이 밀리고, 건너뛰자니 불안했습니다. 혼자 하는 프로젝트도 이런데, 한 달에 PR이 2,500개라면 어떤 모습일지 쉽게 그려지지 않았습니다.

처음에는 과장이거나 위험한 주장이라고 생각했습니다. 그런데 영상을 끝까지 보고 그가 공개한 저장소를 한 줄씩 읽고 나니 생각이 조금 바뀌었습니다. 그는 리뷰를 버린 것이 아니라, 리뷰가 하던 일을 쪼개서 다른 자리로 옮겨 두었습니다. 이 글은 그 자리가 어디인지 따라가 본 기록입니다. 끝에는 제 저장소에 비슷한 장치를 붙여 본 경험도 덧붙였습니다.

사실 그가 올린 X 게시물에서는 PR 2,500개라고 했지만, 영상 첫 화면과 발언에서는 2,000개라고 했습니다. 둘중 어느 쪽이 맞는지, 왜 차이가 있는지는 영상에 나오지 않았죠. 또 PR 하나의 평균 변경량, 되돌린 PR의 비율, 장애 건수, 들어간 비용 등 공개되지 않은 내용도 많습니다. 모든 PR에 사람 손이 한 번도 닿지 않았는지도 확인할 수 없습니다. 다만 그 진위를 꼼꼼히 따지기보다 이런 작업량을 가능하게 한 구조 자체를 살펴보는 것은 의미 있다고 생각했고, 이 글에서도 그 부분에 집중했습니다.

미리 요점만 콕 집어보면?

커서(Cursor)의 로런 탠(Lauren Tan, @poteto)은 한 달에 풀 리퀘스트(Pull Request, PR) 2,500개를 프로덕션에 보냈다고 밝혔습니다. 사람 리뷰는 없었다고 답했죠.
그렇다고 리뷰가 사라진 것은 아닙니다. 리뷰가 하던 일이 PR을 열기 전의 증거, 작성자가 아닌 검증 에이전트, 코드 구조와 린트(lint)로 나뉘어 옮겨 갔습니다.
그가 공개한 pstack 저장소에는 이 흐름이 문서와 스킬(skill)로 정리되어 있습니다. 이 글은 영상 38분과 pstack 저장소를 함께 읽고, 그 방식을 제 저장소에 붙여 본 기록입니다. 에이전트 덕분에 PR은 늘었는데 리뷰가 따라가지 못하는 팀이라면, 리뷰가 하던 일을 어디로 옮길 수 있을지 힌트를 얻을 수 있습니다.

에이전트를 늘리기 전 필요한 것

코드 리뷰 이야기를 하기 전, 로런 탠은 속도보다 신뢰 이야기부터 꺼냈습니다. 에이전트를 아무리 많이 띄워도 그 결과를 믿지 못하면 사람이 다시 하나하나 확인해야 하니까요. 그는 커서의 성능 문제를 직접 추적하던 시기를 떠올리며 “병목은 나 자신이다(I am the bottleneck)”라고 말했습니다.

그래서 그는 에이전트를 병렬로 늘리기 전에, 에이전트가 자기 작업을 스스로 확인할 수단부터 만들었습니다. 감독이 필요한 상태에서 에이전트 수만 늘리면 품질이 낮은 PR과 회귀(regression)가 같이 늘어난다는 이유였습니다.

사람이 모든 줄을 읽는 코드 리뷰는 왜 무너질까

코드 리뷰에 관한 그의 발언은 영상 18분 무렵에 나옵니다. 팀의 규칙을 스타일 가이드에만 적어 두면, 그 규칙을 지키게 하는 방법은 사람이 리뷰에서 지적하는 것뿐입니다. 리뷰어는 바뀐 모든 줄을 보고, 규칙을 기억하고, 잊지 않고 코멘트를 남겨야 하죠. 그는 “지금처럼 PR이 들어오는 속도라면 그 일은 불가능해진다”고 말했습니다.

여기서 눈여겨볼 대목이 있습니다. 그는 사람 리뷰를 쓸모없다고 하지 않았습니다. 사람 리뷰는 “무엇이 빠졌는지 찾는 좋은 출발점”이라고 했습니다. 리뷰에서 같은 지적이 반복된다면, 그 지적은 사람의 기억이 아니라 코드나 자동 검사에 들어가야 한다는 뜻입니다.

에이전트를 교정할 때마다 내용을 반영하는 다섯 층 <출처: lauren(@poteto) X 영상>

슬라이드에는 에이전트를 교정할 때마다 그 내용을 넣을 곳이 다섯 개 적혀 있습니다. 코드베이스(codebase), 린트·컴파일러·CI 같은 정적 분석, 규칙(rules)과 버그봇(Bugbot), 스킬, 스타일 가이드(style guide) 순입니다. 아래로 갈수록 강제력이 약해집니다. 맨 아래 스타일 가이드는 사람이 리뷰에서 지적해야만 지켜지는 층입니다.

그렇다면 리뷰가 하던 일은 구체적으로 어디로 갔을까요. pstack 저장소를 열어 보면 그 답이 단계별로 적혀 있습니다.

PR 열기 전: 검증 스킬로 작동 증거부터 남긴다

pstack은 로런 탠이 커서의 공개 플러그인 저장소(cursor/plugins)에 올린 작업 방식 묶음입니다. 문서 가이드와 스킬, 상황별 플레이북(playbook)으로 이뤄져 있습니다. 검증 가이드에는 “‘컴파일된다’는 증거가 아니다”라는 문장이 맨 앞에 나옵니다.

pstack 검증 가이드의 첫 문장 <출처: cursor/plugins GitHub 저장소>

가이드에 따르면 작업을 시작하기 전에 완료 조건부터 정하고, 앱마다 검증 스킬을 하나씩 만들어 둡니다. 이 스킬은 앱을 띄우고, 상태를 점검하고, 사용자처럼 조작하고, 증거를 남기고, 정리하는 절차를 담습니다. 영상에서는 이것을 기능 지도(feature map)와 CLI의 조합으로 설명합니다. 기능 지도는 어떤 기능이 어디에 있고 어떻게 들어가는지를 적은 문서입니다. 명령줄 인터페이스(CLI)는 에이전트가 앱을 직접 실행하고 조작하는 도구입니다. 화면에는 “기능 지도는 맥락을 주고, CLI는 조작 수단을 준다”는 문장이 적혀 있었습니다.

기능 지도와 CLI를 묶은 검증 스킬 설명 <출처: lauren(@poteto) X 영상>

사람 리뷰어가 PR을 열고 가장 먼저 묻는 질문은 보통 “이거 돌려 봤어요?”입니다. pstack에서는 PR이 열리기 전에 에이전트가 이 질문의 답을 증거로 준비해 둡니다.

머지 판정: 코드를 쓰지 않은 검증 에이전트가 PASS·FAIL을 내린다

배포 절차를 담은 shipping 플레이북에서 제가 가장 오래 들여다본 규칙은 누가 판정하느냐였습니다. PR마다 검증 에이전트를 하나씩 붙이고, 이 에이전트가 사용자처럼 변경을 실행해 본 뒤 PASS, PASS+NOTES, FAIL 중 하나를 PR에 남깁니다. 그리고 코드를 쓰지 않은 에이전트의 판정만 인정합니다. 작성자는 자기가 만들려고 했던 것을 확인할 뿐이라는 이유입니다.

작성자가 아닌 검증 에이전트의 판정만 인정하는 규칙 <출처: cursor/plugins GitHub 저장소>

같은 문서에는 이런 문장도 있습니다. “초록색 CI와 승인한 봇 리뷰는 판정이 아니다.” 둘 다 사용자처럼 변경을 실행해 보지 않기 때문입니다. 머지는 가장 아래 PR부터 차례로 하고, 검증받지 않은 PR이 나오면 그 위는 기다립니다. 리베이스(rebase)로 커밋(commit)이 바뀌면 git patch-id를 비교해서 이전 판정이 지금 코드에도 유효한지 다시 확인합니다.

많은 개발팀이 쓰는 ‘작성자가 아닌 사람이 승인해야 머지(merge)할 수 있다’는 규칙과 닮았습니다. 다른 점은 승인자가 변경 내용(diff)을 읽는 대신 직접 실행해 본다는 것입니다.

리뷰 코멘트: 여러 모델과 버그봇의 지적을 걸러 읽는다

리뷰 코멘트가 많다고 리뷰가 잘된 것은 아닙니다. pstack의 interrogate 스킬은 같은 diff와 의도, 평가 기준을 서로 다른 계열의 모델 여러 개에 보냅니다. 모델마다 놓치는 곳이 다르니, 두 모델이 따로 같은 문제를 짚으면 가장 믿을 만한 신호로 봅니다. 결과는 바로 고치기(Act on), 검토하기(Consider), 기록만 하기(Noted), 기각하기(Dismissed)로 나뉩니다. 기각할 때는 이유를 적고, 어느 것도 자동으로 반영하지 않습니다.

여러 모델의 리뷰 결과를 네 가지로 분류하는 interrogate 스킬 <출처: cursor/plugins GitHub 저장소>

버그봇 코멘트를 다루는 규칙도 따로 있습니다. 고치기(fix), 기각하기(dismiss), 물어보기(ask) 중 하나로 분류하는데, 보안이나 개인정보, 데이터에 관한 지적이나 애매한 지적은 사람에게 묻습니다. 문서에는 애매하면 물어보라는 원칙과 함께 그 이유가 적혀 있습니다. 사소한 코드 품질 코멘트를 넘기는 비용은 작지만, 진짜 데이터 버그나 보안 버그를 넘기는 비용은 크다는 것이죠.

버그봇 코멘트를 fix, dismiss, ask로 나누는 기준 <출처: cursor/plugins GitHub 저장소>

반복 실수: 같은 지적은 린트·CI와 코드 구조로 막는다

영상에서 가장 현실적인 장면은 코드 주석 이야기였습니다. 처음에는 에이전트가 남기는 주석이 별문제 아니라고 생각했다고 합니다. 그런데 커서 코드베이스에서 에이전트가 주변 주석을 근거로 진짜 문제를 고치지 않고 임시방편을 정당화하는 일이 반복됐습니다. 우회 코드 하나가 여러 에이전트에게 복사되면 며칠 만에 사실상의 표준이 됩니다. 화면에는 “한 번 복사될 때마다 다음 복사가 더 쉬워진다”는 문장이 적혀 있었습니다.

리뷰 전에 지름길을 잡는 Dune의 가드레일 <출처: lauren(@poteto) X 영상>

그래서 그는 그록 봇(Grok Bot) 코드베이스에 에이전트용 프레임워크 듄(Dune)을 만들고, 주석을 금지했습니다. 잘못된 임포트(import), 정해진 계약을 거치지 않은 RPC 직접 호출, 파일 크기 증가 같은 지름길은 리뷰 전에 린트와 빌드에서 걸리게 했습니다. 화면 제목은 “가드레일은 리뷰 전에 지름길을 잡는다”였습니다. 이 주석 금지는 그 팀의 선택입니다. 모든 팀에 맞는 규칙이라는 근거는 영상에 없습니다.

pstack의 correct 스킬은 이 생각을 절차로 만든 것입니다. 최근 커밋, 되돌린 커밋, 리뷰 코멘트를 읽고 두 번 이상 나온 실수를 묶습니다. 그리고 가능한 가장 높은 층에서 막습니다. 먼저 구조로 실수가 불가능하게 만들고, 안 되면 타입과 린트와 CI로, 그다음 테스트로 막고, 문서는 마지막에 씁니다. 새로 만든 검사는 과거의 실제 실수에서 실패하는지 확인해야 합니다.

반복된 실수를 가장 높은 층에서 막는 correct 스킬 <출처: cursor/plugins GitHub 저장소>

리뷰어가 같은 코멘트를 세 번째 쓰고 있다면, 그 지적은 사람보다 규칙에 맡기는 편이 낫습니다. 그는 팀에 이런 나쁜 패턴을 일찍 찾아 뽑아내는 “정원사(gardener)” 역할이 필요하다고 말했습니다.

그래도 사람이 맡는 일: 보안·데이터 판단과 검증 기준

이 구조에서 사람의 역할은 사라지지 않고 달라집니다. 영상 앞부분에서 그는 “최종 결과에 대한 책임은 여전히 우리에게 있다”고 말했습니다. pstack에서도 사람의 자리는 분명합니다. 보안과 데이터처럼 되돌리기 어려운 판단은 사람에게 묻습니다. 린트 예외를 둘 때는 이유와 만료일, 사람의 승인을 함께 남깁니다. show-me-your-work 스킬은 에이전트가 내린 결정을 근거와 함께 표로 남기게 하고, 사람이나 다른 모델이 나중에 그 표를 위에서부터 읽으며 확인합니다.

사람이 하던 일은 모든 줄을 읽는 일에서, 검증 기준을 정하고 반복되는 실수를 구조로 바꾸고 최종 결과를 책임지는 일로 옮겨 갑니다.

사람 리뷰가 하던 일이 옮겨 간 자리 <출처: 작가>

제 저장소에 붙여 보니: 커밋 훅·푸시 훅·변경 검토 에이전트

pstack 문서를 읽으며 고개를 끄덕인 대목이 많았습니다. 에이전트 아카데미 저장소에도 비슷한 장치를 하나씩 붙여 왔기 때문입니다. 처음부터 설계한 구조는 아니었습니다. 같은 실수를 두 번 겪을 때마다 제 기억 대신 훅(hook)이나 자동 검사에 맡기다 보니 지금 모양이 됐죠.

지금은 변경 하나가 머지되기 전에 몇 단계를 거칩니다. 커밋할 때는 훅이 메시지 형식과 결정 기록 번호를 확인합니다. 푸시하기 직전에는 다른 훅이 테스트와 빌드를 돌리고, main 브랜치로 곧장 올리는 푸시는 거부합니다. PR이 열리면 클라우드 빌드가 미리보기를 만들고, 별도 서버의 에이전트가 읽기 전용으로 diff를 살펴 원래 목적과 상관없는 변경이 섞였는지 댓글로 알려 줍니다. 빌드가 깨지면 또 다른 에이전트가 원인을 고쳐 PR 브랜치에 다시 올립니다. 머지 버튼은 지금도 제가 누릅니다.

에이전트 아카데미 저장소에서 PR 하나가 머지되기까지 거치는 루프 <출처: 작가>

효과를 실감한 건 해커톤 평가 기능을 다듬던 날이었습니다. 마감 뒤에 올라온 과제를 어떻게 판정할지 바꾸는 PR이었죠. 빌드와 테스트는 모두 통과했습니다. 그런데 변경 검토 에이전트가 댓글 하나를 남겼습니다. 결정 기록에는 지각 제출 판정만 적혀 있는데, diff에는 순위를 정렬하는 코드도 바뀌어 있다는 내용이었습니다. 열어 보니 코드를 쓴 에이전트가 근처 코드를 ‘정리하는 김에’ 손댄 것이었습니다. 그대로 머지했다면 참가자 순위가 아무도 모르게 바뀌었을 겁니다.

저는 그 변경을 떼어 내 별도 PR로 다시 확인했습니다. 비슷한 일이 한 번 더 생긴 뒤에는, 결정 기록과 diff가 맞는지 보는 규칙 일부를 스크립트 검사로 옮겼습니다. 같은 지적을 두 번 하지 말라는 pstack의 correct 스킬과 같은 방향입니다. 밤사이 깨진 빌드에는 아침이면 수정 커밋이 붙어 있는 날이 많아졌습니다. 그러자 제 리뷰도 달라졌습니다. 모든 줄을 읽는 대신, 결정 기록과 에이전트가 남긴 댓글을 보고 머지할지 판단하는 일이 됐죠.

물론 한계도 분명합니다. 혼자 운영하는 저장소라 규모가 작고, 변경 검토 에이전트는 경고만 할 뿐 머지를 막지 않습니다. 가끔은 문제없는 변경에도 경고를 남겨 다시 확인하는 수고가 생깁니다. 그래도 리뷰 부담이 어디서 줄어드는지는 분명히 느꼈습니다. 작동 증거와 판정, 반복되는 지적을 루프에 맡기자 제가 직접 봐야 할 것만 남았습니다.

우리 팀에 도입하기 전에 확인할 것

이 사례를 우리 팀에 그대로 옮기기는 어렵습니다. 로런 탠은 그록 봇 코드베이스에 많은 시간을 투자했다고 말했습니다. 비밀이라기보다 노력이 많이 든다는 말도 덧붙였죠. 검증 스킬, 기능 지도, 린트 규칙, 프레임워크를 먼저 만든 뒤에야 에이전트에게 더 많은 자유를 줬습니다.

조건도 다릅니다. 그는 커서 내부에서 클라우드 에이전트, 오토메이션(Automations), 버그봇을 자유롭게 쓸 수 있는 환경에 있습니다. 비용, 장애율, 되돌린 PR 비율은 공개하지 않았습니다. 보안 리뷰와 권한 분리를 어떻게 하는지도 영상에는 나오지 않습니다. PR 수만 보고 생산성이 몇 배 늘었다고 계산할 수는 없습니다.

마치며

한 달 PR 2,500개라는 숫자는 눈길을 끌기 쉽습니다. 하지만 제가 이 사례에서 가져가고 싶은 것은 숫자보다 몇 가지 질문입니다. 우리 팀 리뷰어가 매주 쓰는 코멘트 중 몇 개가 지난주와 같은 내용일까요. 그 코멘트는 린트 규칙이나 타입이 될 수 없을까요. PR을 연 사람과 그 PR이 작동한다고 판정하는 사람은 같은 사람일까요. 초록색 CI를 보고 머지 버튼을 누를 때, 누가 실제로 그 변경을 돌려 봤을까요.

에이전트가 PR을 여는 속도는 앞으로 더 빨라질 겁니다. 그 속도를 사람의 눈으로 따라가려 하면 리뷰어가 먼저 지칩니다. 다음 리뷰에서 같은 지적을 쓰려는 순간, 그 지적을 어디에 남길지 한 번 생각해 보면 어떨까요.

요즘IT 사례 카드: 커서 엔지니어 로런 탠이 검증 에이전트·린트·CI로 한 달 PR 2,500개를 사람 리뷰 없이 머지한 흐름과, 필자가 같은 방식을 자기 저장소에 붙여 본 결과 <출처: 요즘IT>

]]>

오픈소스 컴퓨터 유즈 cua-driver 써보니: GUI 시나리오 5개 막힌 곳과 우회법

요즘IT 실험 카드: 오픈소스 컴퓨터 사용 드라이버 cua-driver 0.21.0을 MCP로 AI 에이전트에 연결하고, MacBook Pro에서 GUI 시나리오 5개를 직접 돌려 성공 여부와 걸린 시간을 잰 실험 <출처: 요즘IT>

AI 에이전트가 코드를 짜주는 시대는 이제 익숙합니다. 그런데 에이전트가 내 컴퓨터를 직접 만지기 시작하면 어떨지 궁금했습니다. 브라우저를 열고 앱을 실행하고 마우스를 클릭하고 키보드로 입력하는 일까지 에이전트에 맡기는 것입니다. 이를 컴퓨터 사용(Computer Use)이라고 부릅니다.

cua-driver는 이런 컴퓨터 사용을 가능하게 해주는 오픈소스 드라이버입니다. trycua/cua 프로젝트의 일부로, MIT 라이선스로 공개돼 있습니다. macOS·윈도우·리눅스에서 네이티브 앱과 브라우저를 조작할 수 있죠. 클로드 코드(Claude Code)나 코덱스(Codex) 같은 AI 코딩 에이전트와 MCP(모델 컨텍스트 프로토콜)로 연결하면, 에이전트가 데스크톱을 손발처럼 쓰게 됩니다. MCP는 AI와 외부 도구를 잇는 연결 규격입니다.

cua-driver 공식 문서는 친절합니다. 설치 방법도, 도구 목록도 잘 정리되어 있습니다. 하지만 실제로 써 보면 어디서 막히는지, 에이전트의 “했습니다”라는 말을 어디까지 믿을 수 있는지는 문서에 없습니다. 그래서 직접 해 봤습니다. 다섯 가지 데스크톱 조작 시나리오에서 막힌 지점과 우회 경로를 따라가고, 번외로 컴퓨터 조작에 특화된 초소형 모델의 한국어 성적도 살펴봅니다.

1. cua-driver를 선택한 이유

컴퓨터 사용 기능 자체는 새로운 것이 아닙니다. 앤트로픽이 2024년 클로드에 도입했고 오픈AI도 오퍼레이터(Operator)로 선보였습니다.

그런데 이들은 모두 특정 벤더의 모델·플랫폼에 종속됩니다. 반면 cua-driver는 드라이버일 뿐입니다. 모델을 고르지도, 에이전트 루프를 돌리지도 않습니다. 클로드 코드든 코덱스든, 쓰는 에이전트 아래에 붙는 도구 계층입니다. MIT 라이선스 오픈소스라 누구나 뜯어 볼 수 있습니다. 컴퓨터 사용이라는 개념을 벤더 종속 없이 실험해 보고 싶다면 지금 가장 만만한 출발점입니다.

2. 테스트 환경과 방법

테스트는 제 맥북 프로(MacBook Pro, M5 Pro·통합 메모리 48GB)에서 진행했습니다. cua-driver 0.21.0이 이미 설치되어 있었고 데몬도 실행 중이었습니다. 그래서 재설치는 하지 않고 기존 설치본의 상태를 확인하는 것부터 시작했습니다.

여기서 재미있는 일이 생겼습니다. 데몬(백그라운드에서 계속 실행되는 프로그램)의 권한 모드는 standard였습니다. 접근성(Accessibility)과 화면 기록(Screen Recording) 권한도 정상적으로 true를 반환했습니다. 그런데 permissions status 조회에서는 daemon_running=false 혹은 unknown이 떴습니다. status 명령은 실행 중이라고 했습니다. 두 상태 조회가 서로 다른 말을 한 셈입니다.

원인은 확정하지 못했습니다. 어쨌든 실제 화면 캡처는 성공했으니 데몬 자체는 살아 있었습니다.

MCP 연결은 현재 테스트 폴더의 .mcp.json에 바이너리 절대 경로와 mcp 인자를 등록하는 방식으로 검증했습니다. MCP 프로세스를 직접 실행해 initialize 응답까지 받았습니다. MCP 서버는 cua-driver 0.21.0, 프로토콜 버전은 2025-06-18이었습니다. 초기화 응답까지는 5.283초가 걸렸습니다. 다만 실제 테스트 시나리오는 CLI로 순차 실행했습니다.

에이전트는 행동을 결정하고 cua-driver는 데스크톱 조작 도구를 제공합니다. 이 리뷰의 GUI 시나리오는 CLI로 실행했습니다. 설명용 도식입니다. <출처: 작가>

테스트는 AI 에이전트가 수행했습니다. 저는 테스트 조건을 정하고 막힌 지점에서 재실험을 요청하고 나온 수치와 해석을 실행 로그와 공식 자료에 대조해 검토했습니다. 이 글에 나오는 모든 수치는 그렇게 확인했습니다.

3. 다섯 가지 시나리오, 결과는 제각각

소요 시간은 명령 시작부터 응답까지의 실측값입니다. 단회 측정이므로 평균이나 순수 GUI 반응 속도로 해석하면 안 됩니다.

최초 실행의 14개 CLI 호출 합계는 84.154초였습니다. 호출 사이 판단 시간을 포함한 경과 시간은 약 131초였으며 이후 텍스트 편집기 재시험은 별도로 측정했습니다.

숫자를 늘어놓고 보니 드는 생각이 있습니다. 6초짜리 작업도 있고 24초짜리도 있는데 이 편차를 그대로 실무 자동화에 얹으면 느린 응답이 작업 실패로 번질 수 있습니다. 컴퓨터 사용 에이전트를 실무에 쓰려면 평균 속도보다 최악의 경우를 먼저 설계해야 합니다.

시나리오 2가 흥미로웠습니다. 이 버전에서 screenshot은 지원하지 않아 호출이 거부됐습니다. 대신 get_desktop_state로 3456×2234 PNG를 생성하는 데 성공했습니다. 막힌 도구 대신 다른 경로를 쓸 수 있다는 것을 처음 확인했습니다.

시나리오 5에서는 실행 중에 활성 앱이 코덱스에서 카카오톡으로 바뀌어 있었습니다. 이전 코덱스 창은 빈 접근성 트리(UI 요소 목록)를 반환했고 새 활성 앱의 창을 다시 선택해 조회해야 했습니다. 포커스는 조회 사이에도 바뀔 수 있습니다. 원인은 이 실험으로 확정하지 못했습니다.

4. 백그라운드에서 열리지 않는 텍스트 편집기 창

시나리오 4는 처음부터 삐걱거렸습니다. 텍스트 편집기 프로세스는 실행됐는데 window_ready=false였고 창 목록은 비어 있었습니다. 백그라운드 Cmd+N 호출도 window_target_not_found로 거부됐습니다. 문서 생성 단계에서 막혀 입력도, 닫기도 시도조차 못 했습니다.

백그라운드 제약(전경 조작 금지)을 풀고 다시 시도했습니다. 전경 Cmd+N으로 새 문서가 생기는 것을 확인했고 이번에는 입력 단계까지 갔습니다. 그런데 여기서 두 번째 사건이 터졌습니다.

5. 한글 입력 깨짐 사건

전경 type_text로 “cua-driver 테스트 성공”을 입력했는데 12.213초 뒤에 들어간 문자열은 “다cu-driver 테스트 성공식도”였습니다. 요청과 달랐습니다. 입력기 문제인지 포커스 간섭인지, 그때는 확정할 수 없었습니다.

“cua-driver 테스트 성공”을 요청했지만 실제 문서에는 다른 문자열이 입력됐습니다. 당시 실험에서 캡처한 원본 화면입니다. <출처: 작가>

접근성 경로로 우회했습니다. set_value로 값을 직접 설정하니 8.113초 만에 정확한 문구가 들어갔고 후속 조회에서도 일치함을 확인했습니다. 입력 자체는 성공한 셈입니다. 하지만 찝찝함이 남았습니다. 도대체 왜 깨졌는지 알고 싶었습니다.

그래서 조건을 바꿔 재시험했습니다. 제가 포커스를 바꾸지 않겠다고 약속한 상태에서 다시 실행했습니다. 결과는 놀라웠습니다. 전경 type_text가 첫 시도에 성공했고 “cua-driver 테스트 성공”이 정확히 입력됐습니다. 10.719초가 걸렸습니다. set_value는 필요 없었습니다.

앞선 깨짐은 사용자인 제 포커스 간섭 때문일 가능성이 커졌습니다. 에이전트가 타이핑하는 동안 제가 뭔가를 건드렸을 수 있습니다. 다만 원인을 확정하지는 못했습니다. 입력기 문제일 가능성도 완전히 배제할 수 없습니다. 전경 키보드 입력을 시험할 때는 사용자의 조작을 멈추고 조건을 통제할 필요가 있었습니다.

6. 아직 풀리지 않은 Cmd+W 미스터리

그런데 같은 재시험에서 다른 하나는 재현됐습니다. 전경 Cmd+W로 문서를 닫으려 했는데 닫기 확인 시트가 나타나지 않았습니다. 포커스 간섭이 없는 상태에서도 실패했습니다. 앞선 모든 문제를 사용자 간섭 탓으로 단정할 수 없다는 증거죠.

대신 메뉴 경로로 우회했습니다. invoke_menu로 파일 → 닫기를 호출하니 5.937초 만에 저장 확인 시트가 나타났습니다. 시트의 ‘삭제’(미저장 문서 폐기) 버튼은 전경 접근성 클릭으로 눌렀습니다. 시트가 사라지고 문서 창이 닫힌 것까지 확인했습니다. 원래 요청이 “저장하지 않고 닫기”였으므로 저장 버튼은 누르지 않았습니다.

실험 중 캡처한 텍스트 편집기의 저장 확인 화면입니다. 미저장 문서를 폐기하는 ‘삭제’ 버튼과 ‘저장’ 버튼을 구분해야 했습니다. 이 이미지는 닫기 완료 전의 상태입니다. <출처: 작가>

Cmd+W가 왜 안 되는지는 아직 모릅니다. 드라이버의 문제인지, 텍스트 편집기의 문제인지, 타이밍의 문제인지 확인하지 못했습니다. 이 글의 숙제로 남겨 둡니다. 모든 실패에 원인을 붙일 수 있는 것은 아니라는 점도 실측의 일부입니다.

7. 70만 파라미터 모델의 한국어 성적표 (번외)

cua 팀은 드라이버에 이어 컴퓨터 조작에 특화된 초소형 모델 CUA-S1-FORMS도 공개했습니다. 파라미터 706,048개, 체크포인트 용량 2.8MB입니다. 텍스트를 생성하는 대신 UI 요소 하나와 선택지 목록을 받아 한 번의 계산으로 선택지별 확률만 돌려주는 판단 전용 모델입니다. 공개된 평가 수치는 합성 테스트에서 top-1 정확도 99.95%입니다.

직접 돌려 봤습니다. 실험은 같은 맥북 프로의 CPU 단일 스레드로, 오프라인 상태에서 진행했습니다. 모델은 CUA-S1-FORMS(cua-ai/cua-s1-forms, 리비전 4a7a9f4·모델 버전 식별자)를 썼습니다.

입력도 제출도 없이 선택지만 평가했습니다. 평가 사례는 영어 합성 폼 10개, 한국어 실제 웹 폼 10개, 모호한 사례 5개입니다. 한국어 폼은 공개 사이트의 원본 HTML에서 라벨과 입력 타입을 추출해 정규화했습니다. 비교용으로 범용 모델인 클로드에도 같은 문제를 냈습니다.

보존된 실험 결과로 그린 정확도 비교입니다. 한국어 사례를 영어로 번역해도 S1은 10개 중 1개를 맞혔습니다. 작은 표본의 관측 결과입니다. <출처: 작가>

이번 영어 합성 10개에서는 100%가 나왔습니다. 공개된 99.95%와는 표본과 평가 조건이 달라 직접 비교할 수 없습니다. 그런데 한국어 실제 폼에서는 0점이었죠. 그것도 평균 99.99%의 확률로 자신만만하게 틀렸습니다. 10개 모두 ‘skip’을 골랐습니다.

처음에는 언어 문제인가 싶었습니다. 그래서 같은 한국어 사례를 영어로 번역해 다시 테스트했습니다. 결과는 1/10에 그쳤습니다. 같은 항목을 영어로 번역해도 비밀번호 확인이나 전화번호 분할 입력처럼 이번에 선택한 항목·표현에는 취약했습니다. 언어와 항목 구성의 영향을 이 실험만으로 완전히 분리할 수는 없습니다.

CUA-S1-FORMS 모델 카드도 “바이트 레벨 인코더에 영어 중심 라벨 어휘”라고 한계를 스스로 밝히고 있습니다. 이번 실험에서 그 한계가 실제로 드러났습니다.

속도는 압도적이었습니다. 같은 35개 사례를 일괄 처리하는 데 S1은 평균 45.47ms가 걸렸습니다. 35개 사례를 묶어 보낸 클로드 요청 1회는 6.07초였습니다. 클로드는 claude -p --model sonnet --effort low로 호출했고, Claude CLI 응답에 기록된 모델 식별자는 claude-sonnet-5-5였습니다.

사례당 단순 환산하면 S1은 약 1.30ms, 클로드는 약 173ms지만 개별 요청의 응답 시간은 아닙니다. 클로드 측정에는 CLI 시작·네트워크·응답 생성이 포함됐습니다. 참고로 35개 사례를 묶은 클로드 요청 1회의 토큰 비용은 정가 환산 약 3센트(한화 약 40원)였습니다.

같은 35개 사례를 처리했지만 측정 범위는 다릅니다. S1은 워밍업 후 30회 평균, 클로드는 CLI 시작과 네트워크 등을 포함한 요청 1회입니다. <출처: 작가>

높은 확률이 정확한 판단을 보장하지는 않았습니다. 작은 모델은 빨랐지만 낯선 분포 앞에서는 빠르고 자신 있게 틀렸습니다. 이 두 가지를 숫자로 확인했으니 번외 실험을 해 볼 값어치는 있었습니다.

그래서 이 모델의 용도는 명확해 보입니다. 영어 폼 분류처럼 분포가 좁고 정해진 용도에는 빠르고 싸게 쓸 수 있습니다. 반면 한국어 실서비스처럼 분포가 넓은 곳에 그대로 얹으면 빠르고 자신 있게 틀리는 직원을 고용한 셈입니다. 작은 모델은 만능이 아니며 용도가 좁을수록 강한 도구라는 것을 이번 실험에서 수치로 확인했습니다.

마치며

AI가 작업을 실행했다는 응답과 실제로 작업이 끝났다는 증거 사이에는 차이가 있었습니다. 이 글의 모든 장면이 그 차이를 확인하는 과정이었습니다. 도구가 거부되면 돌아가고, 입력이 깨지면 원인을 추적하고, 닫기가 안 되면 메뉴로 우회했습니다. 에이전트는 유능하게 작업하지만 믿고 맡기려면 아직 검증이 필요합니다.

컴퓨터 사용 에이전트는 정해진 도구가 있는 정돈된 작업에서는 꽤 믿을 수 있습니다. 그러나 화면처럼 비정형인 환경에서는 사람의 눈으로 한 번 더 확인하는 과정이 아직 필수입니다. 지금은 그 확인 과정 자체가 가장 재미있는 일입니다.

그래서 저는 이걸 반복 작업의 “첫 손”에 써 볼 생각입니다. 사람이 하기 귀찮은 정돈된 작업을 에이전트에 먼저 맡기고 저는 검증만 하는 식입니다. 완전히 맡기지는 않고 작업을 돕는 용도로 쓰려는 것입니다.

이 글의 실험은 모두 제한된 조건에서 이뤄졌습니다. GUI 작업은 단회 실행과 제한된 재시험으로 측정했고 S1 추론 속도는 워밍업 후 30회 반복해 평균을 냈습니다. 정확도 평가 표본은 작아 결과를 일반화할 수 없습니다. 파일 저장·메시지 전송·실제 웹 폼 제출은 제외했습니다.

그래도 직접 해 보니 문서에서는 알 수 없는 것들을 건졌습니다. 권한 상태 조회의 불일치, 도구 거부의 우회 경로, 한글 입력과 포커스의 관계, 자신만만하게 틀리는 소형 모델까지. 컴퓨터 사용은 현재 생각보다 훨씬 더 직접 만져 볼 만한 상태입니다.

이 글은 AI의 도움을 받아 작성했습니다.

]]>

A2A는 스펙대로 동작할까? 12개 항목 직접 확인해 보니

2026년 8월 17일에 A2A가 에이전틱 AI 재단(AAIF, Agentic AI Foundation)의 호스티드 프로젝트가 되었습니다. 구글이 2025년 4월에 공개한 프로토콜이 특정 회사의 것에서 중립 재단이 관리하는 것으로 바뀐 것인데, 이 소식이 이번 글을 쓰게 된 계기입니다.

이 재단에는 이미 MCP(Model Context Protocol), AGENTS.md, agentgateway 그리고 Goose가 있었습니다. 이 프로젝트들은 에이전트가 사내 인프라에서 도구를 어떻게 호출하는지, 프로젝트 규칙을 어떻게 읽는지 그리고 그 요청을 어디에서 중계하고 기록하는지까지 이미 담당하고 있었습니다. 여기에 A2A는 에이전트가 다른 조직의 에이전트에게 일을 맡기고 그 진행을 확인하는 역할로 더해져서, 그동안 상대마다 직접 만들어야 했던 에이전트 사이의 연결까지 같은 재단의 규격으로 다룰 수 있게 됩니다. 에이전틱 AI 재단의 앰버서더인 아나 히메네스 산타마리아(Ana Jimenez Santamaria)가 지난 8월 MCP Dev Summit Seoul 키노트에서 이 구성을 한 장으로 정리했는데, 옮겨 보면 다음과 같습니다.

[그림 1] 에이전트 하네스, 열린 프로토콜 규약 그리고 공유 인프라로 층이 나누어지는 구성. 출처는 아나 히메네스 산타마리아(리눅스 재단, 에이전틱 AI 재단 앰버서더)의 MCP Dev Summit Seoul 키노트 발표 자료이고 본인에게 받은 자료입니다.

그림은 세 층으로 나누어져 있습니다. 맨 위가 사람이 직접 쓰는 에이전트 하네스(agent harness)이고 가운데가 그 에이전트가 바깥과 주고받는 규약이며 맨 아래가 그 요청이 지나는 공유 인프라입니다. 가운데 층의 왼쪽이 도구와 데이터로 이어지는 MCP이고 오른쪽이 다른 에이전트로 이어지는 A2A인데, 이번에 에이전틱 AI 재단의 프로젝트가 된 것이 그 오른쪽입니다.

이렇게 나누어진 요소들을 하나로 묶어서 보려고 합니다. 그런데 요즘IT는 A2A를 이미 세 번 다뤘습니다. 2025년 5월에 A2A는 AI 에이전트들의 ’언어’가 될 수 있을까?로 프로토콜을 소개했고 한 달 뒤에는 구글클라우드가 A2A를 리눅스 재단에 이관한 소식을 전했으며 올해 6월에는 AI 에이전트는 왜 서로 통신해야 할까? A2A의 모든 것으로 개념과 산업 동향을 다시 정리했습니다. 그래서 이 글에서는 개념 설명을 다시 하는 대신 스펙에 정해 둔 것이 실제 서버에서 그대로 되는지 확인해 보겠습니다. 공식 SDK로 서버를 직접 실행해 놓고 항목 12개로 확인해 봤고 같은 작업을 MCP와 순수 HTTP로도 만들어서 클라이언트에 드는 비용까지 비교해 봤습니다. 결과부터 말씀드리면 A2A로 얻는 것은 진행 확인(task status)과 취소(cancellation)에 대한 규약이고 그 대신 응답 바이트와 지연 시간이 늘어납니다. 하지만 에이전트 카드가 선언한 인증은 SDK 기본 구성에서 검사되지 않았기 때문에 선언과 강제를 나누어 보셔야 합니다.

A2A가 통신하는 흐름을 그대로 따라가면서 가능한 한 쉽게 이해하실 수 있도록 구성했습니다.

A2A가 무엇을 정하고 무엇은 정하지 않는지 확인합니다.
실제로 써 보면 얻는 것과 잃는 것을 비교합니다.
공식 SDK로 띄운 서버가 스펙에 적힌 대로 동작하는지 확인합니다.

에이전틱 AI 재단의 프로젝트가 되었다는 것이 무엇을 뜻하는지, 그리고 이 통신과 이어지는 다른 프로젝트들이 어떤 역할을 맡는지는 하편에서 이어서 다룹니다.

[노트] 이 글을 읽는 데 필요한 용어 5가지

에이전트 카드(Agent Card): 에이전트가 자기를 설명하려고 공개해 두는 JSON 문서입니다. 무엇을 할 수 있고 어디로 어떻게 호출하는지, 어떤 인증을 요구하는지가 적혀 있습니다. 두는 곳은 /.well-known/agent-card.json인데 예전 자료에 나오는 /.well-known/agent.json은 지금 스펙에 없는 경로라 불러도 404가 돌아옵니다.
메시지(Message): 에이전트끼리 주고받는 내용입니다. 일을 맡길 때도 중간에 되물을 때도 메시지로 하며 그 안에 담기는 텍스트, 파일 그리고 구조화 데이터 하나하나를 파트(Part)라고 부릅니다.
태스크(Task): A2A가 정한 일의 단위입니다. 메시지를 보내면 생기고 그 안에 식별자, 상태, 이력 그리고 산출물이 들어 있습니다. 쿠버네티스의 잡이나 CI 파이프라인에서 말하는 태스크와는 다른 것이니 구분해서 읽어 주시기 바랍니다.
아티팩트(Artifact): 태스크가 만들어 낸 결과물입니다. 중간에 오가는 메시지와 달리 이쪽이 최종 산출물입니다.
SDK: A2A를 언어별로 구현해 둔 공식 라이브러리입니다. 스펙과는 버전이 따로 매겨지며 이 글에서 서버를 만들 때 쓴 것은 파이썬용 a2a-python입니다. 스펙이 정해 둔 것과 SDK가 실제로 하는 것이 다를 수 있다는 점이 뒤에서 중요해집니다.

이 밖에 A2A를 이루는 개념은 앞서 말씀드린 2025년 5월 글과 올해 6월 글에 자세히 설명되어 있으니 참고하시기 바랍니다.

➡️참고: A2A 도입 전에 확인할 것 7가지

A2A가 정하는 4가지, 그리고 MCP와 다른 점

그러면 A2A는 무엇을 정하는 프로토콜일까요? 개념과 산업 동향은 앞서 말씀드린 6월 글이 자세히 다뤘으니 여기서는 뒤의 측정을 읽는 데 필요한 만큼만 확인하고 넘어가겠습니다. 우선 밖에서 보이는 것은 에이전트 카드, 메시지, 태스크 그리고 아티팩트 4가지뿐입니다. 상대 에이전트가 어떤 도구와 모델을 쓰는지 그리고 어떤 계획으로 일하는지는 보이지 않는다고 가정하기 때문에 안에서 무엇을 어떻게 하는지는 A2A가 정하지 않습니다.

[그림 2] A2A에서 밖으로 보이는 것은 총 4가지

이 4가지를 JSON-RPC, HTTP+JSON(SDK에서는 REST라고 부릅니다) 그리고 gRPC 중 하나로 실어 보낸다는 것까지가 A2A의 범위입니다. MCP와의 관계는 여러 글이 이미 설명했으니 한 문단으로만 적겠습니다. 둘은 상대편에 무엇이 있느냐가 다른데, 스펙 부록의 표현을 그대로 옮기면 MCP는 에이전트가 도구와 자원을 사용하는 방식을 표준화하고 A2A는 에이전트가 다른 에이전트에 일을 맡기는 방식을 표준화합니다. 도구는 호출하면 결과가 돌아오는 것이고 에이전트는 일을 받아서 시간을 들여 처리하다가 중간에 되물을 수도 있고 거절할 수도 있는 상대라, MCP에는 도구 목록과 도구 호출이 있고 A2A에는 에이전트 카드, 태스크 그리고 상태 변화가 있습니다. 여기서 한 가지 오해하기 쉬운 것이 둘의 관계인데 순서대로 거쳐야 하는 것이 아니라 상황에 따라 고르는 것입니다. 도구를 직접 사용하려면 MCP만 있으면 되고 다른 에이전트에게 일을 맡길 때는 A2A를 쓰면 됩니다.

[그림 3] 요청을 보내는 대상이 다른 MCP와 A2A

측정에 쓴 버전도 함께 밝혀 두는 것이 좋겠습니다. 스펙은 2026년 3월 12일에 고정된 v1.0.0의 후속인 v1.0.1(5월 28일)입니다. v1.0 앞에는 v0.3이 있었고 지금도 두 버전이 함께 쓰이는데 그 이야기는 뒤에서 다루겠습니다. 공식 파이썬 SDK는 a2a-python 1.1.2입니다. 비교 대상인 MCP 서버는 mcp 2.0.0으로, HTTP 서버는 표준 라이브러리로 만든 최소 JSON-RPC 서버로 두었습니다. 환경은 버추얼박스(VirtualBox) 3노드 쿠버네티스 1.37.0이라 절대 수치보다는 구현 사이의 상대 비교로 읽으시면 좋겠습니다.

A2A로 얻는 진행 확인과 취소의 규약

같은 작업 함수를 구현 3개로 감싸서 15초짜리 일을 맡겨 보면 결과를 받기까지 걸린 시간은 셋 다 15.1~15.2초로 같았습니다. 차이가 생기는 것은 그 15초 동안 클라이언트가 무엇을 할 수 있느냐입니다. 이때 맡긴 일이 어디까지 됐는지 아는 방법은 3가지이고 A2A는 이 방법을 모두 스펙으로 정해 두고 있습니다.

폴링(polling): 클라이언트가 주기적으로 상태를 조회합니다. 만들기는 가장 쉽지만 조회하는 횟수만큼 왕복이 생깁니다.
스트리밍(streaming): 서버가 연결을 열어 두고 상태가 바뀔 때마다 이벤트를 보냅니다. 클라이언트가 따로 조회하지 않아도 됩니다.
푸시 알림(push notification): 클라이언트가 미리 등록해 둔 주소로 서버가 알림을 보냅니다. 연결을 계속 유지하지 않아도 되므로 오래 걸리는 일에 맞습니다.

순수 HTTP와 MCP에도 같은 것을 만들 수는 있습니다. 그렇지만 규약으로 주어지는 것이 없어서 전부 직접 구현해야 하고 호출 이름도 응답 형식도 서버마다 따로 정하기 때문에 연결할 상대가 바뀌면 클라이언트도 다시 손보게 됩니다. 이번 측정에서는 양쪽 다 상태를 조회하는 호출만 만들어 1초 간격으로 확인했고 스트리밍과 푸시에 해당하는 것은 만들지 않았습니다. MCP에는 선택지가 하나 더 있는데 15초를 그대로 기다리는 블로킹(blocking) 호출입니다. 상태 확인 왕복이 0회라는 점은 좋지만 그동안 어디까지 됐는지 확인할 방법이 없고 타임아웃을 넘기면 결과를 잃게 됩니다.

[그림 4] 15초 동안 구현 3개가 주고받는 왕복(확인 횟수는 조회 주기에 따라 달라짐)

취소도 마찬가지입니다. 사용자가 취소를 누르거나 상위 작업이 실패해서 맡겨 둔 일을 중간에 멈춰야 하는 경우인데, 오래 걸리는 일일수록 이런 상황이 생깁니다. A2A는 취소가 스펙에 있고 SDK가 그것을 AgentExecutor(앱이 작업 로직을 넣는 클래스)의 취소 훅(hook)에 연결해 두었기 때문에, 진행 중인 태스크와 되물음을 기다리는 태스크가 실제로 취소되었습니다. 순수 HTTP와 MCP에는 취소 규약이 아예 없어서 이번에는 표시만 바꾸는 최소 구현으로 두었고 그 구현에서는 작업 스레드가 그대로 계속 실행되었습니다. 진짜 취소를 붙이는 것은 물론 가능하고 그 작업량이 규약이 없을 때 드는 비용입니다. 덧붙여 상대 에이전트가 처리 도중에 되묻는 경우도 있는데, A2A에는 그 상태(input-required)가 있어서 같은 태스크로 답을 이어 보내면 하던 일이 재개됩니다. 그에 반해 mcp 2.0.0 코어에는 그 상태가 없어서 앱이 따로 만들지 않으면 호출을 처음부터 다시 하게 됩니다.

얻는 것을 숫자로 보면 이렇습니다. 진행 확인과 취소를 직접 만들려면 상대 에이전트에 대해 5가지를 알아야 합니다. 어떤 호출로 일을 시작하는지(message/send), 그 일을 가리키는 식별자 필드 이름이 무엇인지(taskId), 어떤 호출로 상태를 조회하는지(tasks/get), 돌아오는 상태 값에는 어떤 것이 있는지(8종) 그리고 어떻게 취소하는지(tasks/cancel)입니다. 괄호 안은 v0.3 표기이고 v1.0에서는 SendMessage, GetTask 그리고 CancelTask로 바뀌었는데, 이름이 바뀌어도 스펙이 정해 준다는 것은 같습니다. 순수 HTTP와 MCP에서는 이 5가지를 에이전트마다 각자 정하기 때문에 연결할 상대가 하나 늘 때마다 그쪽 규칙을 확인하고 클라이언트 코드를 새로 만들게 됩니다. A2A에서는 전부 스펙에 있으니 상대가 바뀌어도 쓰던 코드를 그대로 쓸 수 있습니다. 물론 사내 에이전트 1개만 호출한다면 이 숫자는 의미가 없고 호출할 곳이 5군데쯤 되거나 외부 업체가 운영하는 에이전트라면 그때부터는 규약이 정해져 있는 쪽이 실제로 도움이 됩니다.

A2A로 잃는 작은 응답과 낮은 지연

얻는 것이 있으면 잃는 것도 있습니다. 짧은 작업에서는 세 구현이 돌려준 결과 문자열이 글자까지 같았고 다른 것은 왕복 수, 지연 그리고 응답 바이트뿐이라, 이를 표로 정리하면 다음과 같습니다.

A2A의 첫 왕복은 에이전트 카드를 받아 오는 호출이고 858바이트가 듭니다. 응답이 큰 이유는 태스크 객체를 매번 함께 보내기 때문인데, 그 안에 식별자, 상태 그리고 이력이 들어 있고 나중에 진행을 확인하거나 취소할 때 쓰라고 미리 실어 주는 것입니다. 그런데 1초 안에 끝나는 호출에서는 나중에 확인하거나 취소할 일 자체가 생기지 않으므로 늘어난 바이트를 쓰지 않고 버리게 됩니다.

진행 확인을 폴링으로 하면 이 부담이 반복됩니다. 상태를 한 번 확인할 때마다 태스크 객체 전체가 돌아오기 때문에 진행 중에 확인하면 423바이트가 돌아왔고 완료를 확인하는 마지막 응답은 571바이트였습니다. 순수 HTTP 쪽에 직접 만든 상태 조회가 92바이트였으니 완료 응답은 6배가 넘고 진행 중 응답도 4배가 넘습니다. 15초짜리 작업을 1초 간격으로 조회하면 완료까지 16번 확인하게 되고 그동안 6,916바이트를 받았습니다. 다만 이것은 어디까지나 폴링을 골랐을 때의 값입니다. 같은 일을 스트리밍으로 확인하면 이벤트 4개를 합쳐 1,287바이트였고 푸시로는 서버가 보낸 요청 2건을 합쳐 465바이트였습니다. 응답마다 크기가 큰 것은 맞지만 오래 걸리는 일에서는 폴링을 쓰지 않는 쪽이 훨씬 적게 주고받고 끝납니다.

지연도 늘어납니다. 세 구현에 같은 부하를 걸어 확인했는데 초당 요청 수(rps, requests per second) 2가지와 연결 방식 2가지를 조합해 조건 4개를 만들고 회차를 10번 돌렸습니다. 그 중앙값을 표로 정리하면 다음과 같습니다.

표의 값은 호출당 지연의 p50(요청 절반이 그 안에 끝나는 시간)이고 단위는 ms입니다. 초당 50건과 100건은 부하 생성기의 동시성 설정이 달라서 행끼리 비교하지 않고 한 행 안에서 구현 사이의 차이만 읽으시면 됩니다. 여기서 A2A와 순수 HTTP의 차이(1.2~2.1ms)를 A2A와 MCP의 차이(0~0.4ms)와 비교해 보면 비용의 큰 부분이 A2A라서 생기는 것이 아니라 구조화된 프로토콜이라면 공통으로 생긴다는 것을 알 수 있습니다. 따라서 이미 MCP를 쓰고 계셔서 그 정도 지연에 익숙하시다면 A2A를 더해도 지연이 크게 늘지는 않고 순수 HTTP만 쓰고 계셨다면 1.2~2.1ms가 그대로 더 들게 됩니다.

[그림 5] 프로토콜에 따라 얻는 것과 잃는 것이 다름

선언만 되고 강제되지 않는 에이전트 카드의 인증

지금까지는 얻는 것과 잃는 것을 설명드렸습니다. 이제부터는 스펙이 얼마나 그대로 동작하는지 직접 확인해 본 결과를 말씀드리겠습니다. 스펙이 반드시 지키라고 하거나 지키는 편이 좋다고 적어 둔 항목 가운데 12개를 골라 공식 SDK의 기본 구성으로 만든 서버에 하나씩 호출해 봤습니다. 그 결과를 판정별로 나누어 표로 정리하면 다음과 같습니다.

표의 순서대로 하나씩 보겠습니다.

스펙대로 동작한 5개입니다.

우선 카드 경로는 /.well-known/agent-card.json 하나에서만 응답했고 다른 경로에는 없었습니다. 태스크는 접수, 처리 중 그리고 완료로 옮겨 갔고 처리 도중에 되물으면 같은 태스크로 답을 이어 보내 재개됐습니다. 단건 조회와 목록 조회도 모두 동작했고 스트리밍은 첫 이벤트가 태스크이고 마지막 이벤트가 완료 표시였습니다. 이 5개는 문서에 적힌 대로 쓰시면 됩니다.

조건부로 동작한 4개입니다.

취소: 진행 중인 태스크와 되묻음을 기다리는 태스크는 취소됩니다. 완료된 태스크를 취소하면 거절되는데 그 오류 코드가 스펙이 정한 TaskNotCancelableError(-32002)가 아니라 내부 오류(-32603)로 옵니다.
푸시 알림: 알림 설정을 담아 둘 곳과 푸시를 보내는 부분을 직접 만들어 연결해야 동작합니다. 연결하기 전에는 설정 요청 자체가 거절되고 연결한 뒤에도 발송이 실패하면 태스크는 완료로 끝나서 클라이언트는 실패를 확인할 방법이 없습니다.
버전 선택: A2A는 2026년 3월에 v1.0이 고정되면서 메서드 이름, 파트의 타입 이름 그리고 태스크 상태 이름이 한 번에 바뀌었습니다. 그렇다고 기존 v0.3 버전 클라이언트의 지원을 바로 중단할 수는 없으니 호환을 켠 서버는 두 버전을 함께 서비스하게 되는데, 어느 쪽으로 처리될지는 A2A-Version 헤더 값 하나로 나누어집니다. 스펙 3.6.1절이 클라이언트는 이 헤더를 반드시 보내라고 하면서 같은 문장에서 헤더가 없으면 v0.3으로 본다고 함께 적어 두었기 때문에, v1.0 클라이언트가 헤더를 빠뜨리면 오류가 아니라 v0.3 요청으로 처리되어 버립니다. 저도 처음에는 “JSON-RPC는 v0.3 형식만 받는구나” 하고 잘못 판단했다가 헤더를 붙여서 다시 호출해 보고 나서야 같은 주소가 v1.0 메시지 형식을 그대로 받는다는 것을 알게 되었습니다.
오류 형식: 바인딩(binding, 같은 스펙을 어떤 통신 방식으로 실어 보내는지 정해 둔 것)마다 다릅니다. JSON-RPC는 HTTP 200 안에 오류 코드가 실리고 REST는 404에 다른 형식으로 옵니다. 오류를 코드로 처리한다면 바인딩별로 따로 보셔야 합니다.

12개 항목 밖이지만 서버를 띄워 보면 바로 마주치는 것도 하나 있습니다. SDK 기본값이 태스크를 파드(Pod) 메모리에 담는 InMemoryTaskStore라서 백엔드를 재시작하면 맡겨 둔 일의 상태가 사라집니다.

스펙과 다르게 동작한 3개입니다.

셋 다 에이전트 카드와 관련이 있고 그중 2개는 원인이 같습니다. 인증부터 보겠습니다. 스펙 7.4절은 서버가 에이전트 카드에 선언한 요구에 따라 모든 요청을 인증하도록 정해 두었습니다. 그래서 에이전트 카드에 API 키, HTTP Bearer 그리고 OAuth2 3가지 인증 스킴(security scheme, 어떤 방식으로 인증할지를 가리키는 이름)을 한꺼번에 선언해 두고 셋 중 어느 것으로 막히는지 그리고 틀린 키를 넣으면 어떤 오류가 오는지를 보려고 했습니다. 그런데 자격 증명 없이 그냥 호출해 보니 200이 돌아왔고 틀린 키를 실은 요청도 같았습니다. 막히는 방식을 비교하려고 만든 서버였는데 애초에 막히지가 않았습니다.

확장 카드도 마찬가지였습니다. 확장 에이전트 카드(extended agent card, 기본 카드에 더해 자세한 정보를 담아 두는 카드)는 스펙이 인증된 요청에만 돌려주도록 정해 두었지만 인증하지 않은 요청에도 공개 카드에 없는 스킬(skill, 그 에이전트가 할 수 있는 일을 카드에 적어 둔 목록)까지 그대로 돌려주었습니다. 둘의 원인은 같은데, SDK의 기본 핸들러에 호출자가 누구인지 확인하는 부분이 아예 없기 때문입니다. 에이전트 카드의 securitySchemes는 클라이언트에게 이런 방식으로 인증해서 오라고 알려 주는 선언일 뿐이고 서버가 그 선언대로 검사하는 코드는 앱이 직접 만들어야 합니다. 따라서 에이전트 카드를 읽고 인증을 붙였다고 해서 서버가 막아 준다고 보시면 안 되고 인증은 앱 안에서 직접 걸거나 앞단에 인증을 담당하는 계층을 따로 두어야 합니다. 확장 카드 쪽도 같은데 인증을 통과한 상대에게만 보여 주려고 정보를 넣어도 주소를 아는 누구에게나 나가게 됩니다.

마지막은 카드에 적힌 인터페이스가 실제와 다른 것입니다. v0.3 호환을 끈 서버의 에이전트 카드에도 v0.3 인터페이스가 그대로 남아 있는데 그 주소를 실제로 호출하면 거절당합니다. 카드에 적어 두는 목록과 서버가 실제로 받는 주소가 따로 관리되기 때문입니다. 앞의 인증과 함께 놓고 보면 에이전트 카드에 적힌 내용을 그대로 믿으면 안 된다는 점을 이 프로토콜에서 다시 확인하게 됩니다.

이번 글은 여기까지입니다. 다음편에서는 에이전틱 AI 재단의 프로젝트가 되었다는 것이 무엇을 뜻하는지, A2A와 이어지는 MCP, agentgateway, Goose가 각각 어떤 역할을 맡는지, 그리고 지금 도입한다면 확인할 것과 앞으로 지켜볼 것을 정리하겠습니다.

➡️ 다음편 A2A 도입 전에 확인할 것 7가지

요즘IT 실험 카드: 에이전틱 AI 재단 앰버서더가 에이전트 간 통신 규격 A2A v1.0.1을 공식 파이썬 SDK(a2a-python)로 직접 띄워 스펙 12개 항목을 확인한 결과, 5개는 스펙대로·4개는 조건부로 동작했고 에이전트 카드에 선언한 인증은 검사되지 않은 실험 <출처: 요즘IT>

]]>

A2A 도입 전에 확인할 것 7가지

2026년 8월 17일에 A2A가 에이전틱 AI 재단(AAIF, Agentic AI Foundation)의 호스티드 프로젝트가 되었습니다. 상편에서는 공식 SDK로 A2A 서버를 직접 띄워 항목 12개로 확인하고, 같은 작업을 MCP와 순수 HTTP로도 만들어 비교했습니다. 결과부터 말씀드리면 A2A로 얻는 것은 진행 확인(task status)과 취소(cancellation)에 대한 규약이고 그 대신 응답 바이트와 지연 시간이 늘어납니다. 하지만 에이전트 카드가 선언한 인증은 SDK 기본 구성에서 검사되지 않았기 때문에 선언과 강제를 나누어 보셔야 합니다. 그리고 아직은 스펙 그대로 동작하는 것이 12개 중 5개로 많지 않았습니다. 하편에서는 A2A가 에이전틱 AI 재단의 프로젝트가 되었다는 것이 무엇을 뜻하는지부터 정리하고, A2A와 이어지는 다른 프로젝트들과 도입 전에 확인할 것 7가지를 차례로 보겠습니다.

중립 재단으로 관리 주체가 바뀐 A2A

관리 주체가 바뀌기까지는 두 단계를 거쳤습니다. 공개하고 두 달 뒤인 2025년 6월에 구글이 리눅스 재단으로 넘기겠다고 발표했고 올해 8월에 그 산하의 에이전틱 AI 재단이 관리를 넘겨받은 것입니다. 그리고 지금 재단 안에서 A2A가 놓인 성숙도 단계는 Growth인데 그 위에 Impact 단계가 하나 더 있습니다. 발표문에 따르면 공급망, 금융 그리고 모바일 플랫폼에서 이미 운영 환경에 쓰이고 있고 함께하는 조직도 150곳이 넘습니다.

그렇다면 관리 주체가 바뀌는 것으로 무엇이 달라질까요? 2가지로 나누어 볼 수 있습니다.

첫 번째는 한 회사의 결정에 따라 프로토콜의 앞날이 정해질 여지가 줄어든다는 것입니다. 특정 회사가 만든 규격은 그 회사가 전략을 바꾸면 유지와 개정이 함께 멈출 수 있는데 중립 재단이 관리하면 그 걱정을 덜 수 있습니다. 실제로 저장소 주소도 google/A2A에서 a2aproject/A2A로 바뀌었고 지금은 예전 주소로 가면 새 주소로 넘어갑니다.

두 번째는 에이전트를 만들 때 필요한 요소들이 한곳에 모였다는 것입니다. 도구를 호출하는 규격, 코딩 에이전트에게 프로젝트 규칙을 알려 주는 파일, 그 앞단에 두는 인프라 그리고 실제로 쓰는 에이전트 도구가 이미 재단에 있었고 여기에 에이전트끼리 일을 주고받는 규격이 더해진 것입니다. 에이전틱 AI 재단은 2025년 12월에 만들어졌고 A2A가 들어온 다음 날 Agent Router까지 승인되어 이 글을 작성하는 시점에는 프로젝트 6개를 관리하고 있습니다. 이를 성격에 따라 구분하여 표로 정리해 볼 수 있습니다.

여기서 표준이 될 수 있는 것은 위의 3개입니다. 규격을 정하는 문서이기 때문에 여러 회사가 같은 규격을 따르면 그것이 곧 표준이 됩니다. 실제로 그렇게 되어 가는 사례가 최근에 하나 나왔는데, 클로드 코드(Claude Code)가 v2.1.277부터 AGENTS.md를 직접 읽기 시작했습니다. CLAUDE.md가 여전히 기본이지만 그 파일이 없으면 AGENTS.md를 읽으며 설정에서 둘 다 읽게 할 수도 있습니다. 그에 반해 아래 3개는 그 규격을 쓰는 제품이라서 표준 자체라기보다는 표준이 실제로 쓰이는지를 보여 주는 쪽입니다. 이 가운데 MCP와 AGENTS.md는 제가 이 지면에 쓴 MCP 2026-07-28 스펙 총정리와 우리 팀의 CLAUDE.md, AGENTS.md로 바꿔도 될까에서 다뤘으니, 이번 글은 남은 A2A를 중심에 두고 MCP와의 관계부터 게이트웨이와 에이전트까지 차례로 보겠습니다.

여기서 한 가지 나누어 보셔야 할 것이 있습니다. 에이전틱 AI 재단의 프로젝트가 되었다는 것과 스펙에 적힌 대로 동작한다는 것은 다른 이야기입니다. 에이전틱 AI 재단이 담당하는 것은 거버넌스와 중립성이지 개별 SDK가 스펙을 지키는지까지 보증하지는 않기 때문입니다. 상편에서 공식 SDK로 만든 서버가 스펙대로 동작하는지 직접 확인한 것도 그래서입니다.

A2A와 다른 프로젝트들의 연관 관계

상편에서는 A2A 자체에 대해서 확인해 보았습니다. 그런데 A2A는 상대 에이전트를 찾아서 일을 맡기고 진행을 확인하고 취소하는 규약까지만 정합니다. 에이전트 사이의 통신을 실제로 운영하려면 카드에 선언한 인증을 누군가 검사해야 하고 오가는 요청을 중계하고 기록하는 장치도 있어야 하며 일을 받은 에이전트가 도구를 호출하는 규격도 필요합니다. 이러한 것들은 A2A 밖의 다른 프로젝트가 담당하는데 각각이 A2A와 어떻게 연결되는지를 하나씩 보겠습니다.

도구를 호출하는 쪽에는 MCP가 있습니다.

상편에서 상대에 따라 골라 쓴다고 말씀드렸는데, 한 서비스가 둘을 함께 제공할 수도 있습니다. A2A로 일을 받은 에이전트가 그 일을 처리하려고 MCP로 도구를 호출하는 구성이 스펙 부록에도 나오는데, 이때 안쪽에서 무엇을 쓰는지는 일을 맡긴 쪽에 보이지 않습니다.

앞단에는 agentgateway가 있습니다.

쿠버네티스 서비스에 설정값 하나(appProtocol: agentgateway.dev/a2a)를 지정하면 게이트웨이가 그 트래픽을 A2A로 처리하는데, 이때 에이전트 카드의 주소를 자기 주소로 바꿔서 내보내고 액세스 로그에 어떤 메서드를 호출했고 결과가 무엇이며 JSON-RPC 오류 코드가 몇 번인지를 남깁니다. 지원하지 않는 메서드를 호출하면 HTTP는 200으로 오고 그 안에 JSON-RPC 오류가 실리기 때문에 상태 코드만 보는 모니터링은 이를 성공으로 집계하게 되는데, 그 대신 게이트웨이 로그가 오류를 기록해 줍니다. 다만 카드를 바꿔 내보내는 동작에는 확인할 점이 있습니다. 두 버전을 함께 서비스하는 서버는 카드에 v0.3 주소와 v1.0 주소를 둘 다 적어 내보내는데, agentgateway는 v1.0 주소만 자기 주소로 바꾸고 v0.3 주소는 백엔드의 직접 주소로 남겨 둡니다. 이 때문에 v0.3 클라이언트가 게이트웨이를 거치지 않고 백엔드로 바로 요청을 보내는 경우를 확인했습니다.

하지만 agentgateway는 A2A 요청의 인가를 판단하지 않습니다.

호출자가 누구인지 확인하는 것이 인증(authentication)이라면 그 호출자가 어떤 메서드나 스킬을 호출해도 되는지 판단하는 것은 인가(authorization)입니다. 이 가운데 인가 쪽을 보면 agentgateway v1.5.0에는 해당 기능이 없습니다. MCP 쪽에서는 도구 이름과 인자에 규칙을 강제하는데 A2A 쪽에는 같은 장치가 아직 마련되지 않아서 관측은 하고 강제는 하지 않습니다. 그래서 상편에서 확인한 인증 검사가 없는 문제는 agentgateway를 앞에 둔다고 해서 해결되지 않고 인증과 인가 모두 앱이나 다른 계층이 담당해야 합니다.

이 규격들을 직접 사용하는 에이전트로는 Goose가 있습니다.

앞의 둘이 규격과 그 규격으로 오가는 요청을 중계하는 인프라였다면, 그 규격으로 실제 일을 주고받는 것은 사람이 직접 쓰는 에이전트입니다. 성격이 그 둘과 다르다는 점은 밝혀 두는 것이 좋겠습니다. 규격은 여러 곳이 같은 문서를 따르면 표준이 되지만 에이전트는 각 파운데이션 모델(foundation model)을 기반으로 동작하는 경우가 많아서 1개로 규격화하기 쉽지 않은 부분이 있습니다. 그리고 opencode를 비롯한 비슷한 도구가 계속 나오면서 경쟁이 치열해지고 있어서 어느 쪽이 자리를 잡을지는 아직 말씀드리기 어렵습니다. 그래도 이 자리를 함께 보는 이유는 규격이 문서로만 있는지 아니면 실제로 쓰이고 있는지를 그 규격을 쓰는 도구에서 확인할 수 있기 때문입니다.

Goose는 2025년 12월에 MCP, AGENTS.md와 함께 에이전틱 AI 재단 창립 기부 3종에 포함되었고 2026년 4월 7일에는 저장소가 블록(Block)의 조직에서 재단 조직(aaif-goose/goose)으로 옮겨 갔습니다. 기업이 만들어 키운 에이전트가 중립 재단으로 관리 주체를 옮긴 사례입니다. 이 글을 작성하는 시점에 별이 54,500개를 넘었고 최신 버전은 2026년 9월 17일에 나온 v1.51.0이며 MCP로 연결할 수 있는 확장이 70가지가 넘고 컨텍스트 파일도 AGENTS.md를 먼저 읽습니다. 두 표준을 현업에서 쓰는 도구가 이미 있다는 뜻입니다.

그러면 A2A는 어떨까요? 아직 그렇게 쓰는 도구가 보이지 않습니다. Goose 같은 에이전트에서 다른 조직의 에이전트를 카드로 찾아 일을 맡기는 구성을 기본으로 제공하기 시작하면, 그때부터 A2A는 규격 문서가 아니라 현업에서 쓰는 규약이 됩니다. 지금 관심을 두고 어떻게 변화하는지 계속 살펴봐야 할 부분 중에 하나가 이 지점이라고 생각합니다.

지금 확인할 것과 앞으로 지켜볼 것

A2A를 도입하실 생각이라면 확인하시면 좋을 내용을 먼저 정리해 보겠습니다.

에이전트 카드에 인증 방식을 적어 두어도 SDK 기본 구성은 그것을 검사하지 않으니 인증은 앱이나 앞단에서 직접 거셔야 합니다.
확장 에이전트 카드는 스펙상 인증된 요청에만 주는 카드지만 SDK 기본 구성은 신원을 확인하지 않습니다. 따라서 주소만 알면 누구나 받아 갈 수 있으니 공개해도 되는 내용만 담으시기 바랍니다.
A2A-Version 헤더는 반드시 붙이셔야 합니다. 빠뜨리면 오류 없이 v0.3으로 처리됩니다.
에이전트 카드의 인터페이스 목록을 그대로 믿지 마시고 실제로 호출해서 확인해 보시는 것이 좋습니다.
완료된 태스크를 취소하면 스펙이 정한 코드(-32002)가 아니라 서버 내부 오류를 뜻하는 코드(-32603)가 옵니다. 그러니 취소 결과를 오류 코드로 처리한다면 이 코드를 서버 장애로 오해해 재시도하지 않도록 따로 처리하셔야 합니다.
푸시 알림을 쓰시려면 알림 설정을 담아 둘 곳과 푸시를 보내는 부분을 직접 만들어 연결하셔야 하며 연결한 뒤에도 보내기에 실패하면 서버 로그에만 남으니 그쪽을 함께 보셔야 합니다.
태스크 저장소는 기본값이 파드 메모리라 재시작하면 상태가 사라지니 재시작해도 남는 저장소로 바꾸셔야 합니다.

그리고 지금은 도입하지 않더라도 관심을 두고 계신다면 지표 3가지를 보시면 좋겠습니다. 앞에서 직접 만들어야 한다고 말씀드린 것들을 언제부터 안 만들어도 되는지 알려 주는 지표라, 이것들이 변경되면 그때 도입 여부를 다시 고려해 보아야 합니다.

첫 번째는 공식 SDK가 인증 검사와 푸시 보내기를 기본으로 제공하게 되는지입니다. 지금은 앱이 직접 만들어야 하는 부분이라 SDK가 이것까지 담당하게 되면 도입 부담이 크게 줄어듭니다.

두 번째는 게이트웨이가 A2A에서도 누가 무엇을 호출할 수 있는지 검사해 주는지입니다. MCP 쪽에는 이미 정책 장치가 있어서 그 기능을 어디에 넣을지는 보이는 상태입니다. 이것이 생기면 인증과 인가를 앱마다 만들지 않고 앞단에서 한 번에 걸 수 있습니다.

세 번째는 에이전틱 AI 재단 안에서 A2A가 Growth에서 Impact로 올라가는지입니다. 에이전틱 AI 재단은 2026년 9월 1일에 신생 프로젝트를 받는 Sandbox 단계를 새로 만들면서 단계별 기준을 정리했고 그 기준으로 보면 다음 단계로 올라간다는 것은 채택, 커뮤니티 그리고 재단 관여가 함께 커졌다는 뜻입니다. 다른 조직의 에이전트를 여럿 연결할 계획이라면 연결할 곳이 그만큼 늘었다고 보셔도 됩니다.

마치며

정리하자면, A2A가 제공하는 것은 다른 에이전트에게 맡긴 일이 지금 어디까지 됐는지 확인하는 방법과 그 일을 처리 도중에 취소하는 방법입니다. 이 둘이 스펙에 정해져 있어서 상대 에이전트가 바뀌어도 쓰던 클라이언트를 그대로 쓸 수 있습니다. 호출한 일이 오래 걸리지 않고 중간에 상태를 확인하거나 관리할 필요도 없다면 MCP로 충분합니다. 특히 MCP는 지난 7월 개정으로 요청 하나하나를 독립적으로 처리하는 구조가 되어서 API 서버처럼 여러 요청을 나눠 받기에 적합합니다. 그런데 시간을 들여 일하다가 중간에 되묻거나 거절하기도 하는 에이전트가 상대라면 그때부터 이 규약이 의미를 가지게 됩니다. 대신 응답 바이트가 늘고 호출당 1.2~2.1ms가 더 걸립니다. 그리고 아직은 스펙 그대로 동작하는 것이 12개 중 5개로 많지 않았습니다. 그중에서도 에이전트 카드에 적힌 것과 서버가 하는 일은 따로 보셔야 하고 그 일을 게이트웨이가 대신 해 주지도 않습니다.

에이전틱 AI를 구성하는 표준은 현재(2026년 9월) 이런 상태입니다. 규격은 v1.0으로 고정되어 읽을 만해졌지만 그 규격을 강제하는 부분은 아직 쓰는 쪽에서 직접 갖춰야 합니다. 그래서 지금은 문서를 믿기보다 직접 실행해서 확인해 보시는 편이 좋습니다. 측정에 사용한 스크립트, 매니페스트 그리고 항목별 판정 표는 공개 저장소에 정리해 두었으니 직접 돌려 보고 싶으신 분들은 참고하시기 바랍니다. 게이트웨이 쪽 측정은 같은 저장소의 다른 연구에 있습니다. 덧붙여 A2A 쪽은 9월에 갱신한 로드맵에서 v1.1을 준비한다고 적었는데 태스크 타임라인을 다듬는 것과 양방향 스트리밍이 그 안에 있으니 이번에 확인한 내용도 그때 다시 봐야 합니다.

게이트웨이는 이 글에서 다 다루지 못했습니다. 같은 재단의 두 게이트웨이인 agentgateway와 Agent Router를 비교하고 게이트웨이를 한 번 더 거치는 비용까지 잰 이야기는 「에이전틱 AI 세계에서 게이트웨이는 어떤 의미를 가질까요?」에서 이어서 보실 수 있습니다.

이 지면에 쓴 앞의 두 글, MCP 2026-07-28 스펙 총정리와 우리 팀의 CLAUDE.md, AGENTS.md로 바꿔도 될까와 함께 읽으시면 에이전틱 AI 재단의 프로젝트 6개를 모두 이어서 보시게 됩니다. 끝으로 한 가지를 더 말씀드리겠습니다. 저는 에이전틱 AI 재단의 앰버서더로 활동하고 있고 이 글에서 다룬 A2A와 agentgateway는 그 재단의 프로젝트입니다. 그렇다 보니 좋은 점만 적기보다 스펙대로 되지 않는 부분까지 직접 확인해서 적었습니다.

]]>

한 번 연결한 MCP, 다른 환경에서도 그대로 쓸 수 있을까? Liner Actions 일주일 사용기

*이 글은 라이너와 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

MCP를 잘 붙여 두면 일이 확 줄어듭니다. 분기마다 성과를 정리할 때면 Jira 티켓과 Confluence 문서, 공유 드라이브의 지표 문서를 하나씩 열어 양식에 옮기느라 2~3시간이 갔는데, Atlassian MCP를 붙인 뒤로는 기준만 주면 에이전트가 맥락을 모아 초안을 만들어 줘서 10분이면 끝났습니다.

문제는 늘 붙이는 과정이었습니다. Datadog MCP는 사내 보안 정책 때문에 프로젝트 범위로 설정하고 API 키를 따로 넣었지만 인증 실패가 계속 나서 끝내 포기했어요. 요즘은 에이전트에게 “이 MCP 붙여 줘”라고 하면 설정까지 해 주니 처음 붙이는 일은 많이 쉬워졌습니다. 그런데 같은 연결을 되풀이하는 품은 그대로 남았습니다. 새 프로젝트를 열면 서비스마다 다시 붙이고, 다른 컴퓨터로 가면 로그인과 키 설정을 또 하고, 웹이나 폰, 다른 에이전트에서는 아예 처음부터 해야 했죠.

그러다 라이너의 의뢰로 Liner Actions를 일주일 넘게 써 볼 기회가 생겼습니다. MCP 서버 하나를 등록하고 서비스 연결을 라이너 계정에 한 번 해 두면, 다른 환경과 에이전트에서도 그 연결을 그대로 쓸 수 있다는 도구입니다. 정말 그런지 평소 쓰는 GitHub·Notion·Sender·Mixpanel을 연결해 두고 맥북의 Claude Code, Claude Code on the web, 폰의 Claude 앱, Codex를 오가며 확인해 봤습니다.

이 글에서는 먼저 직접 MCP를 하나하나 붙일 때와 Liner Actions를 사용할 때 무엇이 다른지, 다른 환경과 에이전트로 옮길 때 다시 해야 하는 일이 실제로 얼마나 줄었는지를 비교합니다. 이어서 Liner Actions를 붙여 두는 동안 컨텍스트를 얼마나 차지하는지, 일주일 동안 실제 업무에 써 보니 어땠는지, 에이전트에게 쓰기 작업을 맡길 때 무엇을 확인해야 하는지를 차례로 다룹니다. 마지막에는 Liner Actions가 잘 맞는 사람은 어떤 사람인지도 정리했습니다. 여러 서비스를 연결해 두고 프로젝트나 컴퓨터, 에이전트를 오가며 일하는 분이라면 참고해 보셔도 좋겠습니다.

Liner Actions는 어떤 도구인가

Liner Actions는 MCP 서버 주소 하나를 등록하고 라이너 계정으로 로그인해 두면, 에이전트가 천 개 넘는 서비스에서 필요한 액션을 찾아 제 계정으로 실행할 수 있게 해 주는 도구입니다. 에이전트에게 보이는 도구는 액션 검색·실행·계정 연결·연결 확인 네 개뿐이고, 서비스 인증 정보는 라이너가 보관해 에이전트에는 넘기지 않습니다. 연결도 라이너 계정에 남아서 다른 에이전트에서 그대로 쓸 수 있다는 게 공식 설명입니다.

<출처 : 작가>

제가 평소 업무에 주로 붙여 쓰는 MCP는 GitHub·Notion·Sender(이메일 마케팅)·Mixpanel(제품 분석) 네 가지인데요. 이 넷을 Liner Actions로 연결해 썼고, 쓰는 중에 Google Search Console을 하나 더 붙였습니다. 맥북 터미널의 Claude Code와 Claude Code on the web, 폰의 Claude 앱, Codex를 오가며 썼습니다.

MCP 서버를 직접 연결할 때와 무엇이 다른가

먼저 Liner Actions로 붙이는 것과 직접 붙이는 것이 어떻게 다른지 알아보려고, 새 저장소에서 같은 네 서비스를 직접 붙여 봤습니다. 직접 붙일 때는 서비스마다 MCP 서버를 하나씩 추가해야 하는데요. Claude Code에게 “project scope로 Notion MCP 연결해 줘”처럼 맡기니 공식 서버를 찾아 프로젝트 설정에 넣어 줬고, 네 서비스라 서버도 네 개가 들어갔습니다. 그다음 서비스마다 따로 로그인해 승인했고, 네 개를 다 붙이는 데 10분 남짓 걸렸습니다.

하지만 Liner Actions는 Liner Actions 서버 하나만 등록해 두면 됩니다. 채팅으로 “Liner Actions로 Notion 연결해 줘”라고 하면 링크가 오고, 열어서 승인 버튼을 두 번 누르면 끝입니다. 넷 중 셋은 직접 붙일 때도 OAuth라, 승인 버튼을 누르는 단계만 놓고 보면 두 방식이 비슷했죠.

차이는 이 방식에서 벗어나는 서비스에서 났습니다. GitHub는 Datadog 때처럼 키를 넣어야 하는 토큰 방식이라, 토큰을 새로 발급하는 대신 gh CLI의 토큰을 환경 변수로 넣어 우회했습니다. Sender는 Claude Code가 공식 서버를 바로 찾지 못해 제가 다시 짚어줘야 했고요.

반면 Liner Actions에서는 이 두 서비스도 다른 서비스와 똑같이 링크와 승인 버튼으로 끝났습니다. Mixpanel만 처음에 실패했는데, 이는 2026년 8월 이전에 만든 계정은 조직 설정에서 MCP 접근이 기본으로 꺼져 있어서였죠. 이건 직접 연결에서도 똑같이 켜야 하는 단계입니다.

<출처 : 작가>

Google Search Console을 붙일 때가 가장 인상적이었어요. 제가 운영하는 뉴스레터의 검색 유입을 보려고 직접 붙이려다가, 구글 클라우드 프로젝트를 만들어 API를 켜고 인증 키와 속성 권한까지 준비해야 해서 미뤄 둔 연동이었거든요. Liner Actions에서는 “연결해 줘” 한마디 뒤에 브라우저에서 몇 번 클릭하니 붙었죠. 동의 화면에서 권한 체크를 하나 빠뜨려 한 번 다시 했는데도 몇 분이면 됐습니다. 미뤄 뒀던 일이 이렇게 끝나니 편하면서도 신기했습니다.

Claude Code 웹·폰·Codex에서도 MCP 연결을 그대로 쓸 수 있을까

두 방식의 차이가 가장 크게 느껴진 건, 이미 해 둔 연결을 다른 곳에서 다시 쓸 때였습니다.

<출처 : 작가>

터미널의 Claude Code에서 MCP를 프로젝트 범위로 붙여 쓰면, 새 프로젝트를 열 때마다 서버 네 개를 다시 추가해야 합니다. 하지만 Liner Actions는 서버 하나를 추가하고 라이너 인증 버튼을 한 번 누르니 네 서비스가 바로 보였습니다. 라이너 계정에 해 둔 연결이 그대로 쓰여서 3분 안에 끝났어요.

Claude Code on the web에서는 제 컴퓨터에만 설정해 둔 MCP가 하나도 따라오지 않았습니다. 웹에서는 claude.ai 커넥터로 어느 정도 해결할 수 있죠. 커넥터 목록에 GitHub·Notion·Mixpanel은 있어서, 이 셋은 서비스마다 커넥터를 따로 연결하면 됩니다. 다만 Sender는 커넥터가 없었습니다. 그리고 이 연결은 Claude 밖으로 따라가지 않아서, Codex 같은 다른 에이전트로 가면 처음부터 다시 붙여야 합니다.

그런데 Liner Actions는 claude.ai 커넥터에 서버 주소 하나를 등록하는 것으로 끝났고, 웹 세션에서 따로 설정할 것도 없었어요. 같은 커넥터가 데스크톱 앱과 폰의 Claude 앱에도 떠서, 이동 중에는 폰으로도 썼습니다.

평소 함께 쓰는 Codex에서도 같은 연결이 그대로 쓰이는지 해 봤습니다. 네 서비스가 하나도 없던 Codex에 Liner Actions 서버를 추가하고 OAuth를 한 번 하자, 3분이 채 안 돼 네 서비스를 모두 쓸 수 있었어요. Codex의 자체 플러그인에도 셋은 있지만, Sender는 거기에도 없었습니다.

<출처 : 작가>

다른 컴퓨터로 옮기는 경우도 따져 봤어요. 어떤 서버를 쓰는지는 프로젝트 설정에 남아 따라오지만, 서비스마다 하는 로그인과 키 설정은 컴퓨터마다 다시 해야 합니다. 같은 컴퓨터에서도 새 터미널을 열었더니 직접 붙인 GitHub가 인증 오류로 동작하지 않았습니다. 키를 넣어 둔 설정이 그 터미널에는 없었던 탓으로 보입니다. 그러나 Liner Actions는 서비스마다 챙길 키가 없어서, 새 프로젝트나 Codex에서처럼 라이너 인증 한 번이면 됩니다.

환경별로 다시 해야 했던 일을 다음과 같이 표로 정리했습니다.

MCP를 연결해 두면 컨텍스트는 얼마나 쓸까

MCP를 많이 붙여 두면 그만큼 기본 컨텍스트를 차지해서, 저는 평소에도 안 쓰는 MCP는 꺼 두는 편입니다. 그래서 여러 서비스를 Liner Actions 하나로 연결해 쓰면 컨텍스트를 아끼면서 쓸 수 있지 않을까 궁금했습니다. 에이전트에게 보이는 도구가 네 개뿐이니 아껴 줄 거라 기대하고 직접 연결과 비교해 봤는데, 결과는 달랐어요.

비교는 이렇게 했습니다. 같은 프로젝트에 네 서비스를 직접 연결한 쪽과 Liner Actions로 연결한 쪽을 두고, 각각 새 세션에서 네 서비스를 차례로 조회하는 같은 요청을 보낸 뒤 /context로 컨텍스트 사용량을 봤어요. 환경은 터미널 Claude Code(v2.1.285, 1M 컨텍스트 모델)였고, 도구 검색은 기본값(켜짐) 그대로 뒀습니다.

붙여 두기만 했을 때는 Liner Actions 쪽이 1.8k 토큰 많았습니다. 네 서비스를 한 번 조회한 뒤에는 56k 대 67k처럼, 두 번 재서 모두 11~13k 차이가 났어요. 같은 조회를 값만 바꿔 한 번 더 하자, 이번에는 액션을 다시 검색하지 않고 바로 실행했습니다.

<출처 : 작가>

Claude Code에는 붙여 둔 도구의 정의를 처음부터 다 싣지 않고, 필요할 때 찾아서 불러오는 도구 검색 기능이 있습니다. 기본으로 켜져 있어서 직접 연결한 도구는 쓰기 전까지 컨텍스트를 거의 차지하지 않아요. 그런데 Liner Actions의 검색·실행 도구는 처음부터 실려 있었고, 붙여 두기만 했을 때 1.8k 토큰 차이가 난 건 그 때문입니다.

조회한 뒤의 차이는 동작 방식에서 왔습니다. 도구 정의 자체는 Liner Actions 쪽이 적었지만(2.3k 대 5k), 서비스마다 액션을 먼저 검색하고 나서 실행하다 보니 네 번의 검색 결과(약 4.9만 자)가 대화에 그대로 남았습니다. 라이너는 검색 결과의 상위 후보에만 입력 스키마를 붙이고, 이미 검색한 액션은 다시 검색하지 않는다고 설명합니다. 두 번째 조회에서 검색 없이 바로 실행한 것도 그래서죠. 처음 검색한 만큼은 남지만, 반복할수록 그 비중이 줄어드는 셈입니다.

한 작업을 한두 번 잰 결과라 일반화하지는 않으려 합니다. 1M 컨텍스트에서는 체감할 차이도 아니었고요.

일주일 실무에 써 보니: GitHub·Notion·Sender·Mixpanel

Liner Actions를 연결해 둔 상태로 일주일 넘게 평소 업무를 하면서, 필요한 데이터와 자료를 그 자리에서 가져와 일할 수 있는지를 봤습니다.

저는 여러 프로젝트의 할 일과 우선순위를 GitHub 이슈로 관리합니다. 폰에서 한 프로젝트의 열린 이슈를 보여 주고 다음 할 일을 제안해 달라고 하자, 이슈마다 남은 일과 막힌 지점을 정리하고 다음에 할 일을 이유와 함께 골라 줬습니다. 제가 직접 할 일과 AI에게 맡길 일을 나눠 둔 목록을 언제 어디서든 들여다볼 수 있으니, 일이 훨씬 생산적으로 돌아간다는 느낌을 받았습니다.

뉴스레터 성과는 그동안 눈대중이나 플랫폼 기본 통계로만 봤는데, 이동 중에 폰에서 Search Console을 불러오니 글마다 노출과 클릭, 클릭률, 평균 순위와 어떤 검색어로 들어왔는지가 한 표로 정리됐습니다. 미뤄 뒀던 연동을 붙이자마자 바로 일에 썼고, 다음 글은 이 검색어를 보고 써야겠다는 생각까지 들었습니다.

Sender로 돌리는 자동 메일 흐름의 성과도 폰으로 점검했습니다. Sender는 구독자에게 보내는 안내 메일과 자동 메일 흐름을 돌리는 이메일 마케팅 도구인데요.Claude 앱에서 “Liner Actions로 Sender 자동화 목록 보여 줘”라고 하자 15초쯤 뒤 자동화 세 개가 표로 나왔고, 강의 안내 자동화의 단계별 오픈율·클릭률에서 가장 약한 단계를 찾아 달라고 하니 1분쯤 뒤 단계별 표와 개선안 다섯 개가 왔어요. 메일과 단계의 대응은 발송 순서로 추정했다는 한계도 에이전트가 먼저 밝혔습니다. 요청 두 번, 3분이었어요. Claude 기본 커넥터에는 Sender가 없는데도, 폰에서 따로 연결하는 단계 없이 바로 썼어요.

<출처 : 작가>

확인만 한 게 아니라, 쌓아 둔 자료를 꺼내 쓰는 데도 썼습니다. 예전 강의 교안과 자료는 노트·문서 도구인 Notion에 쌓아 뒀는데, 아직 주로 일하는 저장소로 옮기지 못한 게 많습니다. 그래서 필요할 때마다 그 맥락을 옮겨 오는 일이 늘 번거로웠습니다. 전에 다른 방법으로 연결해 클라우드 세션에서 Notion을 불렀을 때는 호출이 몇 번 실패해서, 그 뒤로는 아예 손을 놓고 있었죠. 이번엔 Liner Actions로 교안 열한 페이지를 읽어 특강용 커리큘럼을 짜 달라고 했더니, 원문과 기존 구성안을 대조해 고칠 점 세 가지까지 짚은 문서를 저장소에 남겨 줬습니다. 그 문서를 바탕으로 슬라이드까지 짧은 시간에 끝냈고, 커리큘럼 검수는 돌아다니면서 했습니다. 실질적으로 도움이 가장 컸던 게 이 교안 작업이었습니다.

<출처 : 작가>

마지막으로 이렇게 따로 쓰던 네 서비스를 한 흐름으로 이어 봤어요. 제품 분석 도구인 Mixpanel로는 랜딩페이지 지표를 보는데, 불러오니 SNS 유입부터 실제 강의 구매까지 퍼널 전체가 한눈에 펼쳐졌고, SNS 쪽에서 무엇을 고쳐야 할지도 바로 보였습니다. 분석하다 나온 할 일은 그 자리에서 GitHub 이슈로 남겼고요.

이어 Notion에 쌓아 둔 자료를 가져와 Sender 캠페인을 만들자, 그럴듯한 캠페인 아이디어와 초안이 금세 나왔습니다. 평소라면 세그먼트를 나누고 지표를 보는 데만 품이 꽤 드는데, 프롬프트 몇 번으로 대상 세그먼트를 뽑아 발송 준비까지 마쳤죠. 이 흐름 내내 호출이 실패하거나 연결이 끊긴 적은 한 번도 없었습니다.

<출처 : 작가>

아쉬운 점도 있었습니다. Sender는 제가 써 본 범위에서 캠페인을 만들 수는 있어도 지울 수는 없었고, 발신 주소나 제목을 바꾸려 하자 캠페인을 새로 만들어야 했어요. 그리고 처음엔 쓰기가 걱정돼 Claude 커넥터 설정에서 Liner의 실행 도구를 “승인 필요”로 두었는데, 그러자 읽기만 하는 작업에도 실행할 때마다 허용을 눌러야 해서 위 자동화 점검 한 번에 다섯 번을 눌렀습니다. “허용”으로 바꾼 뒤로는 묻지 않고 매끄럽게 돌아갔지만 그만큼 쓰기도 함께 열리는데요, 이건 다음 섹션에서 이어서 볼게요.

에이전트에게 MCP 쓰기 권한 을 맡겨도 될까

MCP로 붙인 서비스는 제 계정의 실제 서비스와 연결된 상태라, 쓰기 권한은 늘 신경 쓰는 부분입니다. 읽기는 권한을 크게 따지지 않아도 되지만, 쓰기는 한 번 잘못되면 되돌릴 수 없는 결과가 날 수 있으니까요. Liner Actions는 수많은 서비스를 한곳에 연결해 쓰는 만큼, 권한이 어떻게 돼 있는지도 살펴봤습니다.

실행 도구 설명에는 허용된 액션은 읽기·쓰기·삭제를 가리지 않고 바로 실행되니 사용자가 요청했는지 에이전트가 확인하라고 적혀 있어요. 라이너는 액션마다 위험 수준을 붙여 주고, 개발자용 API 문서에서는 쓰기 작업마다 사람의 승인을 받으라고 권합니다. 확인은 에이전트와 클라이언트의 몫인 거죠. 자동화를 점검할 때도 에이전트는 메일 본문 수정이 쓰기 작업이니 요청하면 진행하겠다고 먼저 말했어요.

앞에서 말한 허용 설정이 읽기와 쓰기에 한꺼번에 걸리는 건, 클라이언트에 보이는 실행 도구가 하나뿐이어서입니다. Claude 앱의 허용 팝업에는 실행할 액션과 인자가 그대로 보였지만, 허용 여부는 도구 단위로만 정할 수 있어 읽기와 쓰기를 따로 둘 수 없었죠. 개인 작업엔 괜찮았는데, 회사 문서처럼 중요한 자료라면 신중해야겠다고 생각했습니다. 연결 권한도 넓어서 Notion은 개인 스페이스 전체, GitHub는 비공개 저장소까지 열렸습니다. 다만 직접 연결에 쓴 gh CLI도 기본 로그인 토큰이 repo 범위라, 비공개 저장소까지 열리는 건 마찬가지였습니다.

대신 Actions Console에서는 액션마다 스위치를 끌 수 있었습니다. Notion의 페이지 생성을 꺼 두고 빈 페이지를 만들어 달라고 하자, 에이전트는 “You have turned this capability off” 오류를 받고 멈췄습니다. 폴더나 데이터베이스처럼 요청과 다른 것을 만드는 기능으로 돌아가지도 않았습니다. 그래서 커넥터는 “허용”으로 두고 걱정되는 쓰기 액션만 콘솔에서 꺼 두면, 읽기에는 묻지 않으면서 그 쓰기는 막을 수 있죠. 다만 쓰기만 한꺼번에 끄는 버튼은 없고 목록에 읽기·쓰기 표시도 없어서, 막고 싶은 액션을 이름을 보고 하나씩 꺼야 합니다.

<출처 : 작가>

사실 Sender 캠페인 발송은 처음엔 없던 기능입니다. 사용을 시작할 때 Sender 캠페인 액션은 캠페인 초안을 만드는 데까지라 발송을 문의했더니, 쓰던 중에 라이너가 공식 Sender MCP에 없는 발송을 API로 따로 구현해 넣어 줬습니다. 라이너 쪽의 빠른 피드백과 업데이트가 인상 깊었습니다. 이 발송 액션에는 되돌릴 수 없으니 호출 전에 캠페인과 수신 대상을 사용자에게 확인하라는 설명이 붙어 있는데, 위험 수준 표시는 쓰기(write)였습니다.

앞 섹션에서 만든 캠페인은 강의를 들은 분들에게 보내는 후속 메일이었고, 내용을 확인한 뒤 실제 발송까지 Liner Actions로 했습니다. 발송은 매끄럽게 됐지만, 되돌릴 수 없는 작업인데도 발송을 요청하자 에이전트는 다시 묻지 않고 바로 실행했습니다. 커넥터를 “허용”으로 둔 상태라 클라이언트 팝업도 뜨지 않았습니다. 캠페인이 아니어도 자동화를 켜는 쓰기 액션으로 실제 메일이 나갈 수 있다는 점도 알아 둘 만합니다.

<출처 : 작가>

그래서 발송을 맡길 때는 프롬프트로 대상과 범위를 분명히 지시하고, 번거롭더라도 보내기 전에 내용을 한 번 더 확인하는 게 좋겠다고 느꼈습니다. 아주 중요한 캠페인이라면 초안까지만 맡기고 발송은 직접 누르는 편이 안전하겠다는 생각이 들었습니다.

Liner Actions는 누구에게 맞을까

써 보니 Liner Actions는 처음 붙일 때보다 같은 연결을 다시 할 때 품을 더 많이 덜어 줬습니다. 그래서 서비스를 여러 개 쓰면서 프로젝트와 컴퓨터, 에이전트를 오가는 사람, 폰에서도 일하는 사람에게 잘 맞아요. 서비스 하나를 한 컴퓨터에서만 쓴다면 지금처럼 에이전트에게 직접 붙여 달라고 하는 것으로 충분합니다. 읽기와 쓰기 권한을 서비스별로 나눠 관리해야 하는 업무 환경이라면 앞에서 본 허용 단위를 먼저 확인해 보는 게 좋겠습니다.

저는 앞으로도 계속 쓸 생각입니다. 도구를 워낙 매끄럽게 쓸 수 있어서, 쓰는 내내 AI에 팔다리가 붙은 느낌이었죠. 가장 좋았던 건 클라우드 환경에서도 잘 동작한다는 걸 확인한 점입니다. 아이디어가 떠오를 때마다 언제 어디서든 폰으로 일을 맡길 수 있어서, 그만큼 생산성이 올라갔습니다. Claude Code와 Codex를 함께 쓰는데, Codex에 일을 시킬 때도 별다른 설정 없이 MCP가 다 붙어 있는 상태로 쓸 수 있어 편했어요. 지원하는 서비스가 천 개를 넘어서, 쓰다가 새 서비스가 필요해지면 Search Console 때처럼 그 자리에서 붙여 쓸 수 있다는 점도 계속 쓰려는 이유입니다.

]]>

직접 만든 Claude 비서 3주, Duet과 뭐가 다를까

요즘IT 사례 카드: 개발자가 Claude 예약 작업과 Chrome 확장, Jira·Notion 커넥터로 직접 만든 AI 비서를 3주 동안 운영한 기록. 실행 23회, 실수 6건, 그리고 Claude Duet과의 비교 <출처: 요즘IT>

10월 21일, Anthropic이 AI 비서 Claude Duet을 리서치 프리뷰(research preview)로 공개했습니다. 미국의 Pro, Max 구독자가 대기 명단에 올라 순서대로 써 보는 단계라, 한국에서는 아직 쓸 수 없습니다. 저는 이미 Claude로 비슷한 비서를 만들어 쓰고 있었는데요.

제 비서는 평일 오전 9시 5분마다 회사 업무, 오픈소스 기여, 블로그와 커뮤니티를 확인하고 현황판에 정리합니다. 하지만 비서가 작성해준 현황판이 매번 완벽하진 않습니다. 가끔 할 일을 빼먹거나 중요 알림을 놓치기도 해서, 지금은 신입 비서 정도로 생각하고 쓰고 있습니다.

그럼 Anthropic이 만든 비서와 제가 만든 비서는 무엇이 다를까요? 지난 3주 동안 제 비서는 어디에서 얼마나 똑똑했고 어디에서 얼마나 멍청한 실수를 저질렀을까요?

AI 비서를 만들거나 업무에 들이려는 분들이 자동화 범위와 승인 기준을 정할 때 참고하시라고, 운영 중 발견한 실수와 개선 실험을 정리해봤습니다.

1. Claude 비서의 아침 브리핑

제 비서의 정체는 Claude 앱의 예약 작업(scheduled task)입니다. 모델은 Claude Opus 5.5이고 평일 오전 9시 5분에 실행됩니다.

주로 확인하는 영역은 4가지입니다.

업무 정보는 티켓 번호와 한 줄짜리 할 일만 현황판에 올리도록 제한했고, 회사 업무의 세부 내용은 이 글에서 다루지 않겠습니다.

비서는 확인한 결과를 JSON 파일 하나로 정리해 비공개 GitHub 저장소에 저장(커밋)합니다. Vercel에 배포한 현황판이 이 파일을 화면에 보여 주고, 전날과 달라진 내용이 있을 때만 휴대폰 알림을 보냅니다. 같은 상태가 며칠째 이어지는 항목은 ‘반복’으로 표시해서 매일 같은 알림이 오지 않게 했습니다.

연결한 도구는 PC 폴더 2개, Notion, Jira 커넥터, 웹페이지를 읽는 Chrome 확장입니다. 처음에는 Chrome으로 GitHub 웹 편집기를 조작해 커밋했는데, 토큰을 많이 쓰고 실수도 잦았습니다. 그래서 최근에는 PC에 내려받은 저장소에서 git으로 커밋하도록 바꿨습니다.

지시문도 역할별로 나눴습니다. 무엇을 어떤 순서로 할지와 금지 사항은 지시문에, 구체적인 작업 방식은 스킬 파일에, 자주 바뀌는 메모는 저장소의 마크다운 파일에 두고 있습니다. 규칙이 서로 부딪히면 지시문을 따르게 했습니다.

서버 대신 PC와 브라우저를 고른 이유

비서를 만들기 전, 웹에서 다른 사람들은 AI 비서를 어떻게 구현하는지 찾아봤습니다. 흔히 볼 수 있는 구조는 GitHub Actions에서 Python 스크립트를 실행해 GitHub 데이터를 수집하고, Claude API를 호출해 브리핑을 생성하는 방식이었습니다. 저는 조금 다른 방향을 선택했습니다. API를 직접 호출하는 대신, 제 계정으로 로그인된 Chrome 화면을 읽도록 했습니다. 서버에서 실행하는 대신, 제 PC에 설정한 예약 작업으로 비서를 움직이게 했습니다.

이유는 간단했습니다. 제가 확인하고 싶은 페이지 대부분이 로그인해야 볼 수 있는 곳이었기 때문입니다. GitHub 알림함이나 티스토리 관리자 통계처럼 로그인이 필요한 페이지가 대표적입니다. 하지만 이 방식에도 약점은 있었습니다. API는 정해진 형식으로 데이터를 반환하지만, 웹 화면은 사이트가 바뀌면 함께 바뀝니다. 로그인 세션이 만료되면 데이터에 아예 접근할 수 없기도 합니다.

3주간의 운영 기록

예약 작업을 만든 지 5주, 현황판에 기록을 남긴 지 3주
기록한 3주 동안 평일 15일 중 14일 실행 (공휴일 하루는 기록 없음)
일부 영역만 다시 돌린 것까지 포함해 실행 기록 23회, 데이터 커밋 48회
실행한 14일 중 11일은 오전 9시 16~26분 사이 현황판 갱신

<출처: 작가, Claude로 이미지 제작>

2. 어디까지 알아서 하게 둘까?

비서에게 일을 맡기면서 가장 고민한 건 승인 기준이었습니다. 기준은 2가지입니다.

다른 사람에게 보이는 작업인가? 잘못했을 때 되돌리기 어려운가?

외부에 공개되는 작업은 비서가 문안을 작성해 현황판과 알림에 올리는 데까지만 진행합니다. 제가 내용을 확인하고 승인해야 실제로 게시됩니다.

추가 규칙도 하나 있습니다. 개인적인 오픈소스 활동과 업무가 섞이지 않도록, GitHub에 글을 쓰기 전에는 현재 로그인된 계정이 개인 계정인지 확인하고, 아니라면 작업을 중단하도록 했습니다.

3. 비서는 어디서 실수했을까?

3주간의 기록에서 회사 업무를 제외하고, 오픈소스 활동과 블로그 관리 중 발생한 실수 6개를 골랐습니다.

1) 스레드 흐름 놓치기

제가 참여한 GitHub 이슈에 메인테이너(maintainer)가 답변을 남겼는데, 비서가 이 알림을 놓쳐 나중에야 알게 되었습니다. 현황판만 믿고 있었다면 답변이 달렸다는 사실조차 모르고 지나갈 뻔했습니다. 원인을 살펴본 뒤, 이슈 타임라인 전체를 읽고 접혀 있는 댓글까지 펼쳐 확인하도록 바꿨습니다. GitHub 알림함도 별도로 열어 전날 이후 새 알림이 있으면 해당 스레드를 다시 확인하게 했습니다.

2) 기여 후보 상태 놓치기

zod #6657은 자동화 봇이 생성한 이슈였습니다. 비서는 이 이슈를 오픈소스 기여 후보로 등록했지만, 이틀 뒤 메인테이너가 PR #6661로 직접 수정하고 이슈를 닫았습니다. 제가 작업을 시작하기도 전에 기회가 사라진 겁니다. 이후에는 등록해 둔 기여 후보를 매일 다시 확인하도록 했습니다. 담당자가 정해졌는지, 연결된 PR이 생겼는지, 누군가 작업을 맡겠다는 댓글을 남겼는지 살펴보고, 이미 진행 중인 이슈는 후보 목록에서 제외하도록 했습니다.

3) 미완료 작업 멋대로 지우기

아침 점검 중 비서가 현황판에서 ‘네이버 서치어드바이저 캡처 보내기’라는 할 일을 삭제했습니다. 문제는 아직 보내지 않았다는 겁니다. 잘못 지운 항목을 복구하기까지 30분 가까이 걸렸습니다. 당시 비서는 실행할 때마다 할 일 목록을 처음부터 다시 구성하고 있었습니다. 그러다 보니 실제로 끝난 일과 끝나지 않은 일을 잘못 판단할 여지가 있었습니다. 그때는 일단 항목을 복구하는 데 그쳤습니다. 하지만 이 문제는 이후 5절에서 소개할 실험 2의 출발점이 됐습니다.

4) 댓글 작성 시각 못 읽기

비서는 댓글 옆에 표시되는 ‘3일 전’ 같은 상대 시간을 기준으로 새 댓글이 달렸는지 판단했습니다. 그런데 어느 날은 페이지에서 이 시간 표시를 하나도 찾지 못했습니다. 새로운 댓글이 있는지 확인할 근거 자체가 사라진 겁니다. 이후에는 화면에 표시되는 상대 시간 대신, 페이지 내부에 기록된 실제 작성 시각(createdAt)을 비교하도록 변경했습니다. 수정한 방식이 제대로 작동하는지 확인하기 위해 답을 이미 알고 있던 Vite 문서 번역 이슈를 테스트 대상으로 삼았습니다.

5) GitHub 검색에서 변경사항 놓치기

비서는 GitHub 검색을 이용해 제가 참여한 이슈에 새로운 움직임이 있는지 확인했습니다. 하지만 이날은 한 저장소에서 발생한 변화가 검색 결과에 나타나지 않았습니다. 저장해 둔 이슈 목록을 하나씩 열어 작성 시각을 비교하는 스크립트를 실행한 뒤에야 변화를 발견했습니다. 이후 검색의 역할을 나눴습니다. 새로운 PR과 이슈를 찾을 때는 검색을 활용하되, 이미 추적 중인 기여는 검색 결과에 의존하지 않고 직접 열어 확인하도록 했습니다.

6) 티스토리 통계 읽기 실패하기

티스토리 관리자 통계는 14일 중 6일 동안 읽지 못했습니다. 관리자 화면 대신 로그인 페이지가 나타났기 때문입니다. 매번 로그인 문제를 해결할 수는 없으니, 우선 통계를 읽지 못했을 때의 처리 방식을 바꿨습니다. 전날 수치를 유지하되 ‘어제 값’이라고 표시하고, 로그인 문제가 처음 발생한 날에만 알림을 보내도록 했습니다. 적어도 오래된 수치를 최신 데이터인 것처럼 보여 주거나, 같은 문제로 매일 알림이 쌓이는 일은 피할 수 있게 했습니다.

실수의 원인은 모델의 판단력만이 아니었다

6가지 사례를 살펴보면 원인이 조금씩 다릅니다. 1번, 4번, 5번, 6번은 페이지나 데이터를 제대로 읽지 못한 문제였습니다. 2번은 기여 상태를 계속 추적하지 못한 문제였고, 3번은 할 일 목록을 관리하는 방식에서 발생했습니다. 물론 모든 실수를 이렇게 명확하게 나눌 수 있는 건 아닙니다. 데이터를 제대로 읽지 못하면 판단도 틀릴 수 있고, 판단이 맞더라도 상태를 관리하는 방식 때문에 문제가 생길 수 있습니다.

그래도 기록을 돌아보며 확인한 건, 복잡한 추론을 잘못한 경우보다 화면이 예상과 다르게 나타나거나 필요한 정보를 읽지 못한 경우가 더 많았다는 점입니다. 특히 4번과 6번은 1절에서 설명한 화면 읽기 방식의 한계가 그대로 드러난 사례였습니다.

문제는 비서의 본 작업에서만 발생하지 않았습니다. 별도로 설정해 둔 일회성 알림 예약도 두 차례 실행되지 않은 채 꺼졌습니다. 기록을 확인해 보니 예약을 생성했던 대화 세션이 사라진 것이 원인이었습니다. 한 번은 그날 아침 점검 과정에서 이 문제를 발견했습니다. 이후에는 매번 새 세션에서 실행되는 예약으로 다시 설정했고, 이틀 뒤 정상적으로 실행되는 것을 확인했습니다.

4. Claude Duet과 다른 AI 비서 비교

Claude Duet은 미국의 Pro, Max 구독자를 대상으로 대기 명단을 받는 리서치 프리뷰로 공개된 상태입니다. 한국에서는 직접 써 보지 못해서 각 회사의 공식 도움말을 기준으로 비교했습니다. 아래 내용은 2026년 10월 29일 기준이고, 기능과 이용 조건은 바뀔 수 있습니다.

각 서비스의 공식 도움말을 기준으로 정리했고, 출처는 글 마지막에 있습니다.

Duet, Gemini, Copilot Cowork는 메시지를 보내거나 데이터를 바꾸고 지우는 일 앞에서 사람에게 묻습니다. 제가 정한 기준과도 비슷합니다. ChatGPT 예약 작업은 공식 도움말에서 그런 규칙을 찾지 못했고, 관리형 워크스페이스에서 관리자가 제한하면 승인이 필요할 수 있다는 안내만 있었습니다.

서비스마다 크게 갈리는 건 실행 시점입니다. 제 비서는 아침에 한 번 실행되지만, Copilot Cowork는 메일이나 Teams 메시지가 오면 바로 움직입니다. ChatGPT 예약 작업은 아직 웹훅 같은 이벤트 실행을 지원하지 않는다고 도움말에 적혀 있습니다. Duet은 정해진 간격으로 계정을 확인하고, 조용해진 대화를 다시 따라가 주며, 할 일의 완료 표시는 사용자만 할 수 있다는 점도 눈에 띄었습니다.

Duet도 Claude Opus 5.5로 돈다고 안내되어 있어서 제 비서와 모델이 같습니다. 그래서 둘의 차이는 모델보다 무엇을 확인하고 언제 사람을 부르도록 설계했느냐에서 나오는 것 같습니다. 근데 직접 써 본 비교가 아니라서 실제 성능까지 단정하지는 못하겠습니다.

5. Duet에서 아이디어를 가져와 개선해 보기

제 비서에 추가하고 싶은 규칙 2개를 골랐습니다.

오랫동안 답이 없는 기여를 다시 알려 주기
할 일의 완료 여부는 사용자가 정하기

새 규칙을 비서에 넣고 몇 주 기다리는 대신, 3주 동안 쌓인 현황판 데이터에 규칙을 적용해 봤습니다. 날짜별 마지막 버전을 기준으로 한 과거 기록 시뮬레이션이고, 실제 운영 결과는 아닙니다.

실험 1. 답이 없는 기여를 다시 알려 주기

측정 지표: 상대 답을 기다리는 열린 기여 중 N일 넘게 움직임이 없는 걸 비서가 먼저 짚은 수, 짚은 뒤 7일 안에 풀린 수

현재 비서는 새 움직임이 있을 때만 알립니다. 움직임이 없으면 아무리 오래 기다려도 ‘변화 없음’으로 넘어갑니다.

그래서 3주 넘게 답이 없는 기여가 5개(zod와 CDISC에 2개씩, getodk에 1개) 있었는데도 비서가 먼저 짚은 적은 없었습니다. 이 5개와 별개로 react-pdf 이슈는 알림 구독까지 꺼져 있어서, 답이 왔어도 모르고 지나갈 뻔했습니다.

새 규칙은 상대 답을 기다리는 열린 기여가 N일 동안 움직이지 않으면 할 일에 올리고, 정중한 댓글 초안을 붙이는 것입니다. 실제로 올리는 건 기존처럼 제가 승인한 뒤입니다.

7일 기준에서는 짚고 6일 만에 병합된 MDN 번역 PR도 짚게 됩니다. 가만히 둬도 풀렸을 기여까지 재촉하게 되는 셈입니다. 반면 14일 기준으로는 6개를 짚었고, 이 6개는 기록 마지막 날까지 모두 답이 없었습니다.

그래서 일단 14일을 기준으로 삼으려 합니다. 근데 표본이 10개, 기간이 3주뿐이고 저장소마다 답하는 속도도 달라서 더 지켜봐야 합니다.

실험 2. 할 일 완료는 사람이 표시하기

측정 지표: 끝나지 않았는데 현황판에서 빠진 할 일 수

현재 할 일 목록은 실행마다 처음부터 다시 만들어집니다. 이렇게 하면 실행할 때마다 결과가 새로 나와서 어제 상태와 꼬일 일이 없고 구조도 단순합니다. 대신 ‘아직 안 끝났다’나 ‘이건 안 할 거다’처럼 제가 정한 상태를 담아 둘 자리가 없습니다.

3주 동안 할 일 14개가 올라왔고 그중 10개가 중간에 목록에서 빠졌습니다. 끝났거나 더 이상 하지 않기로 한 일이 많았지만, 끝나지 않았는데 빠진 걸로 확인된 일도 1개 있었습니다.

그래서 비서가 만드는 항목과 제가 정한 상태를 따로 저장하기로 했습니다. 비서는 완료된 것 같다고 표시만 하고, 제가 ‘끝남’이나 ‘안 함’이라고 답해야 상태가 바뀝니다. ‘안 함’으로 처리한 일은 날짜와 이유도 남겨서 같은 일을 다시 제안하지 않게 했습니다.

과거 기록에 적용하면 끝나지 않은 일이 목록에서 빠지는 건 규칙상 0개가 됩니다. 대신 제가 직접 완료 여부를 확인해야 할 일이 3주 동안 10개 늘어납니다. 평일 하루 1개도 안 되니 감당할 만하다고 판단했습니다.

두 규칙 모두 아직 과거 기록에 적용해 본 단계입니다. 실제 비서에 반영한 뒤에도 같은 효과가 나는지는 다시 재 봐야 합니다.

<출처: 작가, Claude로 이미지 제작>

마치며

3주간의 기록에서 자주 눈에 들어온 건 ‘어제 값’ 같은 표시였습니다.

비서가 똑똑하게 판단한 순간보다 무엇을 확인하지 못했는지 그대로 적어 둔 순간이 더 쓸모 있었습니다. 통계를 읽지 못했다면 전날 숫자라고 밝히고, 일이 끝난 것 같더라도 제가 확인하기 전에는 완료 처리하지 않는 식입니다.

AI 비서를 만들거나 업무에 들인다면, 자동으로 할 수 있는 일뿐 아니라 비서가 혼자 완료 처리하거나 삭제해도 되는 일도 함께 정해 두면 좋겠습니다.

Duet을 한국에서 쓸 수 있게 되면 같은 기록으로 다시 비교해 볼 생각입니다.

이 글은 AI의 도움을 받아 작성했습니다.

참고 자료

(모두 2026년 10월 29일 확인)

Claude Duet 시작하기: https://support.claude.com/en/articles/17631495-get-started-with-claude-duet
ChatGPT 예약 작업: https://help.openai.com/en/articles/10291617
Gemini 예약 작업: https://support.google.com/gemini/answer/16316416
Gemini 작업(Task) 모드: https://support.google.com/gemini/answer/17094507
Copilot 예약 프롬프트: https://support.microsoft.com/en-us/microsoft-365-copilot/schedule-your-most-used-copilot-prompts
Copilot Cowork 사용하기: https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/use-cowork

]]>

인하우스 IT 기획자가 AI로 대시보드 만들며 배운 4가지

요즘IT 사례 카드: 인하우스 IT 조직의 기획자가 VS Code와 클로드 코드(Claude Code)로 테이블 100개 가까운 레거시 DB에서 홈페이지·앱 직판 예약 데이터 분석 대시보드를 만들고, SQL 검증 2주를 거쳐 사내 배포한 사례 <출처: 요즘IT>

“솔루션 업체에 가능한지부터 확인해 봐야 한다.”

인하우스 IT 조직에서 일하다 보면 이런 말을 정말 자주 들으셨을 겁니다. 제가 말하는 IT 조직은 일반적인 IT 기업 안의 IT팀이 아니라, 본업을 돌아가게 만드는 사내 지원 조직에 가깝습니다. 그래서 새로운 걸 처음부터 설계하기보다, 이미 깔린 시스템 위에서 최대한 잘 돌아가게 만드는 일이 훨씬 많습니다.

제가 속한 산업군의 핵심 시스템은 PSS(Passenger Service System), 즉 항공 예약 시스템입니다. 호텔에는 객실 재고를 관리하고 아고다 같은 판매 채널에 연동하는 PMS(호텔 관리 시스템)가, 제조업에는 생산과 재무 등을 통합 관리하는 ERP(전사적 자원관리 시스템)가 있듯이, 각 업종마다 전 세계에서 통용되는 표준 솔루션이 있고 많은 조직이 이러한 표준 솔루션을 도입해서 쓰고 있습니다.

이 글에서는 이렇게 핵심 업무를 처리하고 원본 데이터가 쌓이는 시스템을 ‘원천 시스템’이라고 부르겠습니다.

대부분의 원천 시스템은 한번 도입하면 그 위에 다른 시스템이 쌓이기 때문에, 새로운 걸 하려면 솔루션 업체에 가능한지부터 확인해야 합니다. 제가 속한 항공 서비스 조직도 다르지 않습니다.

이 글은 그런 환경에서, 개발 리소스를 기다리는 대신 기획자인 제가 AI와 함께 직판(홈페이지와 앱) 데이터를 분석하는 대시보드를 직접 만든 경험을 기록한 글입니다. 제가 속해있는 산업군에 대한 이야기도, 요즘 쏟아지는 ‘AI가 대신 개발해 준 이야기(바이브 코딩)’도 아닙니다. 문제를 정의하고, 데이터 구조를 이해하고, 화면으로 설계하고, 결과물을 검증하는 과정에서 기획자가 실제로 무엇을 했는지에 대한 이야기입니다. AI는 도구일 뿐, 어떤 데이터를 어떤 순서로 보여줄지 판단하는 건 여전히 기획자의 몫이었습니다.

몇 년째 ‘있으면 좋지만 지금은 만들 수 없는 것’으로 남아 있던 대시보드를 업무 틈틈이 만들어 사내 배포까지 했습니다. 그런데 가장 오래 걸린 건 코드가 아니라 검증이었습니다. 데이터 구조를 이해하는 일, 지표를 고르는 기준, AI가 짠 코드의 검증, 그리고 사람에게 도움을 청해야 하는 지점까지, 만들며 배운 4가지를 정리했습니다.

<출처: Pixabay>

넘치는 데이터 속 숨어 있는 필요 데이터

만들어야겠다고 생각한 대시보드로 보고 싶었던 건 홈페이지와 앱에서 예약하는 고객이 어떤 여정을 거치는지였습니다. 홈페이지를 운영하고 고도화하는 기획자로서 꼭 알아야 하는 데이터였습니다.

문제는 고객 한 명의 여정이 예약 하나로 끝나지 않는다는 점이었습니다. 예약, 결제, 취소, 부가서비스 구매, 체크인, 탑승까지 이어지고, 리드타임이나 노선, 채널(직판, 여행사 등)에 따라 그 흐름도 계속 달라집니다. 게다가 이 데이터들은 한곳에 예쁘게 모여 있지 않습니다. 홈페이지와 앱에서 일어난 예약과 구매는 홈페이지 데이터베이스에, 모든 판매 채널의 원본 데이터는 원천 시스템에, 결제 데이터는 수입관리 시스템에 따로 저장됩니다.

물론, 가시화된 데이터가 전혀 없었던 건 아닙니다. 원천 시스템의 원본 데이터는 이미 비즈니스 인텔리전스(BI) 툴을 통해 세일즈 관점에서 보고 있었지만, 그건 직판과 여행사 등 모든 판매 채널을 합친 실적 관점이었습니다. 홈페이지 데이터도 GA(구글 애널리틱스)와 빅쿼리(구글의 데이터 분석 도구)로 이미 보고 있었습니다. 다만 GA는 방문, 클릭, 유입 경로처럼 고객이 홈페이지에서 어떻게 행동했는지를 이벤트로 수집해서 보여주는데 특화된 도구입니다. 제가 보고 싶었던 건 그와 별개로, 실제 DB에 기록된 예약과 구매 결과를 노선, 동반 인원, 예약 시점 등과 같은 기준으로 나눠 보는 것이었습니다.

전체 채널을 합친 세일즈 숫자는 있어도, 홈페이지와 앱을 통해 예약하고 이용하는 고객의 흐름을 직관적으로 확인하고 비교할 수 있었던 화면은 없었던 셈입니다. 그래서 이번에는 읽고, 분석할 데이터의 범위를 홈페이지 DB로 정했습니다.

탑승(출입국)처럼 홈페이지와 앱이 관여하지 않는 단계의 데이터는 원천 시스템에 따로 있기 때문에, 대시보드는 홈페이지와 앱에서 일어나는 구간을 다루는 것으로 목적을 분명히 했습니다.

제가 아니더라도, 필요성은 모두가 알고 있었습니다. 항상 그렇듯 한정된 자원에서 문제는 늘 우선순위였습니다. 조직에서 개발 리소스는 언제나 운영 이슈와 핵심 프로젝트에 먼저 배정됐습니다. 게다가 이러한 자체 분석 대시보드를 만들려면 많은 비용과 리소스가 드는 일이었습니다. 그렇게 이 대시보드는 몇 년째 ‘있으면 좋지만 지금은 만들 수 없는 것’으로 남아 있었습니다.

1. 프롬프트보다 중요한 건 데이터 구조의 이해다

처음부터 운영에 쓸 대시보드를 만들겠다는 계획은 아니었습니다. 당시 저는 AI를 업무에 어떻게 활용해야 그 효과를 극대화할 수 있을지 스스로 스터디하며 이것저것 실험해보던 시기였습니다. 문서를 작성하는 수준을 넘어 ‘기획자가 AI를 활용해서 어디까지 직접 만들 수 있을까’를 시험해보고 싶었습니다. 마침 필요하다는 걸 모두가 알지만 계속 밀려나던 직판 데이터 분석 대시보드가 있었고, 개발 리소스가 배정되기를 기다리는 대신 일단 최소 기능 제품(MVP)부터 만들어보기로 했습니다. 본업이 아니라서, 업무 사이사이 시간이 날 때마다 틈틈이 진행한 작업이었습니다.

VS Code와 Claude Code를 열고 가장 먼저 한 일은 화면을 만드는 것이 아니라 데이터를 이해하는 것이었습니다. 어떤 데이터를 보여줄지부터 다시 정의해야 했습니다. 읽을 범위는 홈페이지 DB로 정했으니, 그 안에서 무엇을 어떻게 보여줄지를 정해야 했습니다. 예약 현황만 볼 것인지, 승객과 노선, 부가서비스 구매까지 하나의 흐름으로 볼 것인지를 먼저 결정했습니다.

문제는 데이터 구조였습니다. 접근할 수 있는 테이블이 100개 가까이 되는 상황에서 어떤 테이블을 써야 하는지부터 직접 찾아야 했습니다. AI에게 “SQL을 짜달라”고 요청해도, 어떤 테이블에 무슨 데이터가 있는지, 어떤 컬럼이 실제로 쓰이는지를 제가 모르면 AI도 정확한 쿼리를 만들어줄 수 없었습니다. 결국 테이블과 컬럼을 하나씩 분석하며 관계를 추론하는 일은 제가 직접 해야 했습니다. 여기에 데이터 자체가 암호화되어 있는 경우가 많아서 분석하고 이해하는데 어려움이 더 컸습니다.

같은 작업을 반복해야 하는 상황이 잦아지자 아예 데이터베이스 메타데이터를 탐색할 수 있는 화면을 직접 만들었습니다. 이렇게 분석해 보니 실제로 쓴 테이블은 전체의 10% 안팎이었습니다. 예약 정보를 담은 테이블이 모든 집계의 기준이었고, 여기에 승객, 여정, 부가서비스, 회원 정보 테이블을 연결하는 구조였습니다. 애당초 기획자인 저에게는 시스템의 읽기(Read) 권한만 부여되어 있기도 했지만, 잦은 조회와 테스트가 원본 운영 DB에 부하를 주지 않도록 처음부터 철저히 읽기 전용 환경을 바라보도록 설계했습니다.

필요한 데이터를 조합할 구조를 정리한 뒤에야 쿼리를 작성할 수 있었습니다. 원하는 결과가 한 번에 나오는 경우는 거의 없었습니다. 더미 데이터를 먼저 만들어 테이블이 어디서 연결되는지 파악했고, 그 뒤에는 정확한 데이터가 나올 때까지 쿼리를 수정하고 확인하는 일을 반복했습니다. AI가 코드를 짤 줄 안다고 해서 이 과정이 짧아지는 건 아니었습니다. 무엇을 연결해야 하는지, 그 결과가 맞는지를 판단하는 건 데이터를 직접 들여다본 사람만 할 수 있었습니다.

<출처: 작가, Claude로 이미지 제작>

2. 예쁜 화면보다 행동으로 이어지는 지표가 먼저다

데이터 구조가 정리된 뒤에는 ‘이 데이터를 어떻게 보여줘야 실제 의사결정에 도움이 될까’를 고민했습니다. 기획자로서 저는 이 대시보드가 직판 홈페이지의 판매율을 높이는 데 도움이 되었으면 좋겠다고 생각했습니다. 그렇다면 현황을 보여주는 데서 끝나면 안 되고, 보는 사람이 개선안을 바로 떠올릴 수 있어야 합니다. 전체 채널의 실적을 보여주는 화면은 이미 BI 툴에 있었습니다. 제가 필요했던 건 어디를 고치면 판매율이 오를지를 가리키는 화면이었습니다.

그래서 지표를 고르는 기준도 ‘중요해 보이는가’가 아니라 ‘이 숫자를 보고 무엇을 바꿀 수 있는가’였습니다. GA4 같은 행동 분석만으로는 판매율을 높이는 개선안을 구체화하기에 부족하다고 생각했습니다. 노선별, 동반 인원 규모별로 구매하는 방식이 다르다면 개선도 그 기준에 맞춰 따로 해야 하기 때문입니다. 그래서 구매 패턴이 갈리는 지점마다 그에 맞는 분석이 따로 필요하다고 판단했고, 화면을 그 기준으로 나눠 설계했습니다.

첫 화면에는 판매와 직결되는 지표만 뽑아서 올리고, 더 보고 싶은 사람이 상세 화면으로 들어가게 했습니다. 상세 화면에서는 예약 비중과 매출 비중을 위아래 두 막대로 나란히 놓았습니다. 예약 건수는 적어도 매출 기여가 큰 구간을 찾으면, 개선에서 어디부터 손대야 하는지 우선순위를 바로 정할 수 있기 때문입니다. 노선, 동반 인원, 예약 시점별 등 세부 분석화면에 같은 방식을 반복해서 썼습니다.

* 산업군이나 서비스 성격에 따라 유의미한 데이터 관점은 달라지므로, 이 글에서는 기획 의도를 보여주기 위한 가상의 예시를 활용했습니다.

<출처: 작가, Claude로 이미지 제작>

데이터가 얼마나 예쁘게 보이는지보다, 이 대시보드를 쓸 사용자가 필요한 정보를 얼마나 빠르게 찾고, 비교하고, 다음 질문으로 이어갈 수 있는지가 더 중요하다고 생각했습니다. 이 판단에는 그동안 UI/UX 기획과 서비스 정책 정의를 하며 쌓아온 경험이 가장 많이 쓰였습니다. 기획안을 개발자에게 전달하고 화면이 나오기를 기다리는 대신, 기획한 사람이 그대로 화면설계하고, 구현까지 할 수 있게 된 것 입니다.

3. 맥락을 주고 검증하는 건 기획자의 몫이다

구현까지 끝나고 나서 가장 오래 걸린 건 검증이었습니다. 본업을 하면서 짬짬이 진행한 기간이라, 영업일 기준 경과 기간으로 보면 분석에 1주, 설계에 3일, 구현에 2일이 걸렸고 검증에만 2주가 걸렸습니다. 전체 기간의 절반입니다.

<출처: 작가, Claude로 이미지 제작>

방법은 단순했습니다. 대시보드에 나온 수치를 실제 DB에서 제가 직접 쿼리를 짜서 조회한 값과 대조했습니다. 화면에 숫자가 나오는 것만으로는 그 숫자가 맞는지 알 수 없었기 때문입니다.

대조해 보니 처음에는 값이 맞지 않았습니다. 테이블을 어떻게 연결할지 따로 지침을 주지 않고 AI에게 쿼리를 맡겼더니, 결과가 원본과 완전히 어긋나 있었고 중복된 값도 하나도 일치하지 않았습니다. 원인은 예약 한 건에 승객, 여정, 부가서비스가 여러 행으로 붙어 있는데, 이 관계를 고려하지 않고 테이블을 연결한 데 있었습니다. 그래서 메타데이터 화면에서 파악한 데이터 구조를 정리해서 전달하고, 기본키(PK) 기준으로 중복을 제거해 조인(JOIN)으로 묶으라는 지침을 더했습니다. 예약 기준으로 집계할지 승객 기준으로 집계할지 집계 단위도 못 박고, 기대하는 결과값 예시를 함께 주자 그 뒤에야 대조 결과가 맞았습니다.

<출처: 작가, Claude로 이미지 제작, 설명을 위한 예시>

대처 전: 지침 없이 맡긴 요청

“예약, 승객, 부가서비스 데이터를 합쳐서 노선별 예약 건수와 매출을 구하는 SQL을 짜줘.”

대처 후: 맥락을 정리해서 준 요청

데이터 구조: 예약 한 건에 승객과 부가서비스가 여러 행으로 연결됨
연결 방식: 각 테이블은 기본키(PK) 기준으로 중복을 제거한 뒤 조인(JOIN)으로 묶을 것
집계 단위: 예약 건수는 예약 기준, 매출은 승객 기준으로 집계할 것
기대 결과: 노선별 예약 건수를 모두 더하면 전체 예약 건수와 같아야 함

(실제 사용한 프롬프트가 아니라 설명을 위해 만든 예시입니다.)

AI가 SQL 문법을 틀린 건 아니었습니다. 제가 테이블 사이의 관계와 집계 기준을 충분히 알려주지 못한 게 원인이었고, 그 맥락을 정리해서 전달하자 AI도 맞는 쿼리를 만들어 냈습니다.

(지금 생각해보면 참 무식한 방법으로 검증을 한 것 같습니다. 다음에 진행하게 된다면 지표별 집계 단위와 ‘합계가 맞아야 하는 기준값’을 먼저 정해 두고, AI가 만든 쿼리가 그 기준에 맞는지부터 확인하는 방법으로 진행할 것 같습니다.)

4. AI는 개발자를 대체하지 않고, 단계를 하나 더 만든다

검증과는 별개로, 프론트엔드 개발과 서버 배포는 저에게 완전히 새로운 영역이었습니다. 특히 배포는 방법 자체를 몰랐습니다. 그동안 만든 바이브 코딩 프로젝트는 제 컴퓨터(로컬)에서만 실행해 봤을 뿐, 서버에 올려본 적이 없었습니다. 이번 MVP도 처음에는 로컬에서 혼자 데이터를 보고 분석하는 용도였습니다.

그러다 우연한 기회에 상위 의사결정자에게 시연할 일이 생겼는데, 직판 데이터를 한 화면에서 볼 수 있다는 점과 운영·기획 관점의 직관적인 화면 구성이 좋은 반응을 얻었습니다. 이후 내부 시연으로 범위를 넓혀 사내 배포까지 이어졌습니다. 사내 구성원이 함께 써야 했기 때문에 보안이 적용된 내부망 서버에 올려야 했고, 외부 오피스에서 근무하는 팀원은 VPN(가상사설망)이 있어야만 접속되는 환경이라는 점도 고려해야 했습니다.

먼저 내부 인프라팀과 협의해 서버를 할당받았습니다. 인프라팀에는 테이블 같은 데이터 세부 내용이 필요하지 않아서, 용도와 접속 범위만 정리해서 전달했습니다. 그다음 코드를 Git에 올리고, 할당받은 서버에 올리는 순서로 진행했습니다.

회원 정보를 연결할 때는 개발자에게 접근 권한을 요청했습니다.데이터를 누구에게 보여줄지도 정해야 했습니다. 예약과 구매 데이터는 모두가 접근할 수 있는 정보가 아니기 때문에, 암호화된 데이터에서 수치만 뽑아 대시보드에 올렸고, 판매 데이터를 볼 수 있는 관계자에 한해서만 배포했습니다. 대시보드를 만들었다고 해서 데이터를 아무에게나 열어 둔 것이 아니라, 원래 판매 데이터를 볼 수 있는 사람들에게만 더 빠르게 볼 수 있는 화면을 제공한 것이었습니다.

서버와 권한은 사내 담당자에게 요청해야 풀리는 일이었습니다. AI 덕분에 직접 해볼 수 있는 범위는 넓어졌지만, 그 범위를 넘어서는 부분은 사람과 소통하며 진행했습니다. 그래서 이건 ‘AI가 개발자를 대체했다’는 이야기는 아닙니다. 정확히는, 개발자와 인프라팀에 도움을 요청하기 전에 기획자가 먼저 빠르게 MVP를 만들어 직접 검증해볼 수 있는 단계가 하나 더 생긴 것에 가깝습니다.(당연히 데이터를 더 확장하고 검증하려면 다음 단계는 개발자의 도움과 인사이트가 필수적이라는 점을 부정하는 것은 아닙니다.)

이 경험으로 알 수 있는 것

AI가 쿼리를 짜주고 화면을 만들어주는 시대가 되었다고 해서 기획자의 일이 쉬워진 건 아닙니다. 이번에 가장 오래 걸린 건 코드를 만드는 일이 아니라 그 결과가 맞는지 확인하는 일이었고, 어떤 테이블이 어떻게 연결되는지, 어떤 숫자를 어떤 순서로 보여줄지 판단하는 건 끝까지 제 몫이었습니다. 대신 기획자가 직접 확인하고 실행해 볼 수 있는 범위가 넓어졌습니다.

레거시 시스템이 두꺼운 환경일수록 ‘있으면 좋지만 지금은 만들 수 없는 것’이 쌓입니다. 막대한 비용과 시간이 들고, 개발자가 붙지 않으면 시작조차 할 수 없다고 여겨지기 때문입니다. 이제는 개발자나 인프라팀에 도움을 요청하기 전에, 기획자 혼자서도 먼저 문제를 정의하고 데이터를 파악해서 직접 만들고 검증해 볼 수 있는 환경이 생겼습니다.

이제 “개발 리소스가 없어서 못 합니다”라고 결론 내리기 전에, “내가 지금 직접 확인해볼 수 있는 데까지는 어디일까?”를 한 번 더 질문해볼 수 있게 됐습니다. 병목되어 ‘언젠가는 만들어야할 것이 있다면’ 일단 한번 시작해보는게 어떨까요?

이 글은 AI의 도움을 받아 작성했습니다.

]]>

Next.js 모바일 웹을 일주일 만에 앱으로 바꾼 방법 ②

요즘IT 사례 카드: 프론트엔드 개발자가 AI 에이전트와 자체 스킬, Expo·Figma MCP·모노레포로 Next.js 모바일 웹을 React Native 앱으로 전환한 사례. 1주 만에 POC를 만들었지만 2주 출시는 못 했다 <출처: 요즘IT>

지난 1편의 목표는 명확했습니다. 어떻게든 빠르게 앱 POC를 만들어내는 것이었죠. 이미 돌아가던 Next.js 모바일 웹을 SSOT(Single Source of Truth)로 삼아 모노레포를 세팅하고, mobile-design-sync 스킬을 돌려가며 리셋된 토큰을 3일 만에 다 태울 만큼 무섭게 화면을 찍어냈습니다.

그렇게 일주일 만에 그럴듯한 앱이 나왔으니, 남은 일주일 동안 가볍게만 손보면 “앱 출시까지 2주면 된다”는 말을 증명할 수 있을 줄 알았습니다. 하지만 1편 마지막에 말씀드렸듯이, 바로 출시까지 가는 데는 실패했습니다.

속도를 최우선으로 두고 달렸던 만큼, 실제 스토어에 올리려니 그때는 미처 보지 못했던 빈틈들이 한꺼번에 드러났기 때문입니다. 마크다운 문서상으로는 분명 화면들이 다 올라와 있었지만, 막상 휴대폰으로 하나씩 눌러보니 여기저기서 문제들이 쏟아졌습니다.

모바일 웹과 앱은 본질적으로 UI/UX 프로세스가 달랐습니다. 디자인만 맞춘다고 끝이 아니라 터치 영역, 키보드, 그리고 어떤 화면을 웹뷰(WebView)로 두고 네이티브로 갈지까지 다시 짚어야 했습니다.
겉모습은 같은데 실제 로직이 어긋난 부분이 생각보다 너무 많이 발견됐습니다.
푸시 알림이나 본인인증처럼 모바일 앱에서 지원해야 하는 기본 기능의 추가 개발이 필요했고, 픽셀·토큰 단위의 세밀한 싱크와 반응형 디자인 이슈도 남아 있었습니다.

결국 1편이 ‘속도’를 무기로 빠르게 POC를 올린 이야기였다면, 이번 하편은 속도를 잠시 내려놓고 ‘디테일한 체크’에 집중한 기록입니다.

초벌로 찍어낸 앱을 실제 유저 손에 쥐여줘도 부끄럽지 않은 상태로 만들기 위해 무엇을 하나씩 점검하고 고쳤는지, 그리고 “앱 출시까지 2주면 된다”를 직접 테스트해 본 최종 후기를 풀어보고자 합니다.

디테일 체크 1. 모바일 웹과 앱은 UI/UX 프로세스가 다르다

스크린샷에는 안 찍히는 차이: SafeArea, 키보드, 터치 영역

1편에서 만든 mobile-design-sync 스킬은 모바일 웹과 앱의 스크린샷을 찍어 나란히 비교하며 화면을 맞췄습니다. 빠르게 POC를 올릴 때는 이 방식이 정말 강력했습니다. 그런데 실제 휴대폰에 앱을 빌드해서 손가락으로 눌러보는 순간, 스크린샷 비교만으로는 절대 알 수 없었던 문제들이 줄줄이 나왔습니다.

대표적인 것이 상·하단 SafeArea 여백, 키보드 올라옴 처리, 그리고 손가락 터치 영역이었습니다.

화면 캡처본에서는 멀쩡해 보이던 상단 헤더가 실제 기기에서는 노치(Notch) 영역과 겹치거나, 반대로 상단 공통 헤더가 이미 상단 여백을 먹고 있는데 화면 컨테이너가 한 번 더 SafeArea를 잡아서 상단에 광활한 빈 공간이 생기기도 했습니다. 입력 폼에서는 키보드가 올라오는 순간 하단 ‘다음’ 버튼을 덮어버렸고, iOS에서 잘 되던 키보드 회피 처리가 Android에서는 먹히지 않았습니다. 웹에서는 마우스 커서로 정확히 클릭할 수 있던 32px짜리 아이콘이나 약관 체크박스도 앱에서는 손가락에 자꾸 빗나갔죠.

처음에는 문제가 보이는 화면마다 들어가서 패딩을 고쳤는데, 화면이 수십 개다 보니 한 곳을 고치면 다른 화면과 기준이 달라졌습니다. 그래서 개별 화면을 땜질하는 대신, 웹의 공통 레이아웃에 대응하는 앱 전용 루트 셸 컴포넌트(Screen)를 만들어 화면 규칙을 한곳에서 통제하기로 했습니다.

Screen 컴포넌트 <출처: 작가>

이렇게 루트 셸에서 세 가지 디테일을 일괄로 체크했습니다.

SafeArea(edges) 자동 분기: 상단 공통 헤더가 붙는 탭 화면은 헤더 자체가 이미 상단 SafeArea를 처리하므로 본문에는 하단(bottom)만 적용하고, 자체 스택 헤더를 쓰는 로그인·가입 화면은 상·하단(top, bottom)을 모두 적용하며, 웹뷰나 중첩 컨테이너는 여백이 두 번 잡히지 않도록 제외했습니다.
OS별 키보드 대응 분리: iOS는 기본 KeyboardAvoidingView의 padding 옵션만으로 충분했지만, Android edge-to-edge 환경에서는 창 높이가 기대대로 줄어들지 않았습니다. 그래서 Android에서는 키보드 노출 이벤트(keyboardDidShow/keyboardDidHide)에서 높이를 읽어 하단 패딩을 직접 밀어 올리는 커스텀 훅을 붙였습니다.
터치 타깃(hitSlop) 확보: 피그마 시안상 아이콘 크기가 작더라도 손가락으로 누르기 쉽도록 헤더 아이콘 버튼 영역을 넉넉하게 키우고, 체크박스와 텍스트 라벨 전체에 hitSlop과 터치 영역을 넓혔습니다.

홈 화면 비교 <출처: 작가>

사진상으로는 큰 차이가 없어 보일 수 있지만, 모바일 웹을 만들면서 함께 협업하는 디자이너분께 대략 350개의 디자인 QA를 받았던 저로서는 큰 수고로움 없이 이런 디테일을 일괄로 맞출 수 있다는 점이 아주 매력적이었습니다.

모든 화면을 네이티브로 만들 필요는 없다 - 웹뷰(WebView)로 싱크 비용 줄이기

빠르게 POC를 찍어낼 때는 “일단 웹에 있는 페이지를 다 앱 화면으로 옮기자”는 생각으로 달렸습니다. 하지만 출시 전 디테일 체크 단계에서 냉정하게 따져보니, 유지보수 관점에서 고민되는 지점들이 보이기 시작했습니다.

예를 들어 회사소개, 자주 묻는 질문(FAQ), 블로그, 릴리즈 노트, 1:1 문의, 파트너 등록 안내 랜딩 같은 페이지들은 복잡한 네이티브 인터랙션이 없는 정보 전달용 화면입니다. 이런 화면까지 전부 React Native로 따로 들고 있으면, 문구 하나나 배너 하나를 바꿀 때마다 웹을 고치고 앱도 고쳐서 스토어 심사를 다시 받아야 합니다. 물론 이런 불편함을 줄이기 위해 Expo로 프로젝트를 관리하고 있지만, 그럼에도 단순한 문구 변경 때문에 앱 버전을 올리고 배포하는 일은 너무 번거로울 것 같았습니다.

그래서 디테일 체크 과정에서 “어디까지 웹뷰(WebView)로 두고, 어디서부터 네이티브로 전환할 것인가”라는 경계선을 명확히 그었습니다.

웹뷰 허용 경로 <출처: 작가>

정적 페이지들은 과감하게 웹뷰 허용 경로(Allowlist)로 묶어 react-native-webview로 띄웠습니다. 대신 앱 안에서 웹뷰를 열었을 때 상단 헤더가 두 개(앱 헤더 + 웹 헤더)로 겹쳐 보이면 유저 입장에서는 단번에 “껍데기만 씌운 앱”처럼 느껴집니다. 이를 막기 위해 웹뷰 호출 시 식별용 쿼리(?webview=1)와 쿠키를 심어 보내고, Next.js 웹에서는 이 신호가 들어오면 웹 자체 헤더·푸터·플로팅 버튼(FAB)을 숨기도록 처리했습니다. 덕분에 상단은 앱의 네이티브 헤더가, 본문은 모바일 웹이 이질감 없이 이어졌습니다.

자주 묻는 질문 페이지 <출처: 작가>

그런데 이렇게 만들고 나니, 다시 프론트엔드의 전통적인 고민으로 돌아가게 됩니다. “아, 하이브리드 앱으로 가도 될 것 같은데?”

하이브리드 앱은 네이티브 앱의 껍데기(셸) 안에 웹뷰(WebView)를 띄워, 웹으로 만든 화면과 네이티브 기능을 함께 쓰는 앱입니다.
푸시 알림·생체 인증이나 복잡한 입력처럼 기기 성능과 UX가 중요한 곳은 네이티브로 처리하고, 자주 바뀌거나 정적인 화면은 웹을 그대로 재사용해 개발·유지보수 비용을 줄일 수 있습니다.

참 애매했습니다. 결국 모바일 웹과 모바일 앱을 일일이 싱크하는 것보다, 모바일 웹만 관리하고 앱 껍데기를 씌우는 구조로 간다면 굳이 이런 디테일한 싱크 작업을 하지 않아도 되니 말입니다.

하지만 이내 “하이브리드보단 네이티브가 더 성능이 좋지, 장기적으로 고민하자”라는 합리화를 하고 넘어가게 됩니다. 아직 이 부분은 저도 계속 고민 중인 지점입니다.

반면, 웹뷰에서 시작하더라도 입력과 검증이 핵심인 구간에서는 즉시 네이티브 화면으로 바통을 넘기도록 설계했습니다. 가장 좋은 예가 ‘출강업체 등록’ 흐름입니다.

출강업체 등록 안내 랜딩 페이지는 긴 소개 이미지와 안내 문구가 주를 이루므로 웹뷰로 보여줍니다. 하지만 유저가 그 웹뷰 안에서 ‘출강업체 등록하기’ 버튼을 누르는 순간, 웹뷰 안에 주입해 둔 브릿지 스크립트가 가입 페이지 이동을 가로채어 앱의 네이티브 회원가입 화면으로 라우팅을 전환합니다.

웹뷰 - 앱 네이티브 전환 <출처: 작가>

약관 동의부터 아이디, 사업자등록번호 실시간 검증, 비밀번호 입력, 포커스 자동 이동까지 이어지는 다단계 가입 폼은 웹뷰보다 네이티브로 구현했을 때 키보드 반응성과 입력 경험이 훨씬 쾌적하기 때문입니다.

여기에 더해, 네이티브 가입 도중 거쳐야 하는 통신사 PASS 본인인증은 외부 본인인증 모듈 특성상 다시 전용 웹뷰로 띄우고, 인증이 끝나 리다이렉트될 때 결과 URL에서 인증 식별값만 추출해 다시 네이티브 가입 단계로 복귀시켰습니다.

본인인증 웹뷰와 화면 <출처: 작가>

이렇게 웹뷰와 네이티브의 적당한 타협과 조합으로 개발 속도와 앱다운 사용성을 동시에 잡을 수 있었습니다. 지금도 어떤 페이지를 웹뷰로 두고 어떤 페이지를 네이티브로 가져갈지 계속 고민하고 있습니다. 다만 이전과 다른 점은 개발 속도가 더 이상 큰 병목은 아니라는 것입니다.

의사결정 과정에서 네이티브가 더 좋다고 판단되면 이젠 바로 실행하면 됩니다.

디테일 체크 2. 겉모습은 같은데 어긋난 로직 바로잡기

모노레포를 깔아뒀는데도 왜 로직이 어긋났을까?

두 번째로 발목을 잡은 건 ‘겉모습은 똑같은데 속 로직이 다른’ 문제였습니다.

분명 1편에서 시작할 때부터 모노레포를 구축하고 공통 패키지(api, utils)에 비즈니스 로직을 모아두었습니다. 그러니 앱에서도 당연히 똑같은 로직이 돌아갈 거라 믿었죠. 하지만 QA를 시작해 보니 웹에서는 통과되는 입력값이 앱에서는 막히거나, 에러 토스트 문구가 미묘하게 다르거나, 버튼 연타 시 중복 요청 방지 가드가 빠진 곳들이 무더기로 발견됐습니다.

원인은 명확했습니다. POC 단계에서 AI 에이전트에게 “모바일 웹 화면을 보고 앱 화면을 빠르게 만들어줘”라고 지시할 때, 에이전트가 매번 공통 유틸 패키지의 검증 함수를 찾아 연결하기보다 각 화면 컴포넌트 안에 빈 값 체크나 정규식 몇 줄을 즉석에서 인라인으로 짜 넣는 쪽을 택했기 때문입니다. 눈으로 보는 UI는 100% 똑같이 돌아가니 초벌 작업 때는 눈치채지 못했던 겁니다.

디자인을 맞추기 전에 로직부터 잠그는 mobile-logic-sync

이 문제를 겪고 나서 워크플로를 뜯어고쳤습니다. 픽셀과 색상을 맞추기 전에, 반드시 웹과 앱의 입력 검증, API 호출, 상태 전이부터 대조하는 mobile-logic-sync 단계를 먼저 거치도록 강제한 것입니다.

가장 먼저 앱 화면 컴포넌트 안에 흩어져 있던 인라인 검증 코드들을 전수 검색해 걷어내고, 모든 검증 규칙과 에러 문구를 공통 유틸 패키지의 단일 함수로 끌어올렸습니다.

공통 로직 <출처: 작가>

이렇게 공통 패키지에 정의해 두면, Next.js 웹이든 React Native 앱이든 똑같은 함수를 호출해 똑같은 에러 메시지를 보여줍니다. 또한 이 함수들에 단위 테스트(Vitest)를 붙여두어, 나중에 누군가(아마도 대부분 경우에는 AI가) 화면 UI를 수정하더라도 검증 조건이 슬그머니 바뀌는 일을 원천 차단했습니다.

동시에 플랫폼 특성상 웹과 앱이 의도적으로 다르게 동작해야 하는 부분은 각 화면의 싱크 마크다운 문서에 명시해 두었습니다. 예를 들어 웹에서는 비밀번호 입력 중 실시간 강도 검증 API를 디바운스로 호출하지만, 모바일 앱에서는 네트워크 지연을 줄이기 위해 제출 시점에 공통 검증 규칙으로 일괄 검증하도록 결정했습니다. 이런 차이를 문서에 적어두지 않으면 다음번 QA나 에이전트 실행 때 “웹이랑 로직이 다른 버그”로 오해해 다시 덮어쓰는 일이 반복되기 때문입니다.

디테일 체크 3. 모바일 앱이라서 추가로 챙겨야 했던 기본 기능들

“알림 화면이 있는 것”과 “푸시 알림이 오는 것”은 전혀 다른 문제다

1편 도입부에서 말씀드렸듯, 애초에 모바일 웹만으로도 잘 돌아가던 서비스에 굳이 앱을 만들기로 결심한 이유는 단 하나였습니다. “알림을 보지 못해서 계약이 불발되었다”는 고객의 VOC 때문이었죠.

그런데 1주일 만에 찍어낸 POC 앱에서 ‘알림’을 점검해 보니 갈 길이 멀었습니다. 우선 UI부터가 어색했습니다. 모바일 웹에서는 상단 헤더의 종 모양 아이콘을 누르면 그 자리에서 바텀시트(Bottom Sheet)로 알림 인박스가 열렸는데, 초벌 앱에서는 종 아이콘을 누르면 아예 별도의 알림 페이지로 화면 전체가 이동해 버렸습니다.

디테일 체크 단계에서 이를 모바일 웹과 동일하게 바텀시트 형태의 알림 인박스로 다시 맞추고, 미읽음 배지와 탭 필터(전체/견적/공지), 그리고 외부 알림 링크를 타고 들어왔을 때 최대 3초간 ‘이동 중...’ 스피너를 보여준 뒤 목표 화면으로 넘겨주는 브릿지 화면까지 웹과 똑같이 정렬했습니다.

알림 인박스 비교 <출처: 작가>

알림 리다이렉트 비교 <출처: 작가>

하지만 진짜 문제는 그다음이었습니다. 앱 안에 알림함 화면이 예쁘게 들어앉은 것과, 유저의 휴대폰이 꺼져 있을 때 잠금화면에 푸시 알림이 울리는 것은 완전히 별개의 기능이었기 때문입니다.

웹을 그대로 옮기는 스킬만으로는 네이티브 푸시가 저절로 생겨나지 않습니다. 실제 유저가 계약을 놓치지 않게 하려면 다음의 네이티브 파이프라인을 처음부터 끝까지 별도로 챙겨야 했습니다.

OS 권한 및 디바이스 토큰 수명주기: iOS(APNs)와 Android(FCM) 인증서를 세팅하고, 로그인 직후 적절한 타이밍에 알림 권한을 요청해 발급받은 푸시 토큰을 백엔드에 등록·갱신하고 로그아웃 시 해제하는 처리
기존 알림톡과의 서버 팬아웃(Fan-out): 기존에 카카오 알림톡이나 웹 알림이 발송되던 이벤트 지점마다 앱 푸시 토큰 보유 여부를 확인해 푸시를 함께 쏘는 백엔드 연동
콜드 스타트(Cold Start) 딥링크: 앱이 완전히 종료된 상태에서 푸시 배너를 탭했을 때, 페이로드에 담긴 URL을 읽어 브릿지 화면을 거쳐 해당 견적서나 채팅 화면으로 정확히 꽂아주는 라우팅 검증

여기까지 진행하니 이젠 앱다운 모습이 어느 정도 완성된 것을 확인할 수 있었습니다. 이젠 진짜 마지막 단계로 넘어가 보도록 하겠습니다.

디테일 체크 4. 스크린샷 비교를 넘어 픽셀·토큰 단위로 디자인 조이기

왜 스크린샷 비교만으로는 디자인이 계속 틀어졌을까?

마지막으로 가장 많은 시간을 쏟은 곳은 픽셀과 토큰 단위의 디자인 디테일 체크였습니다.

1편에서 소개한 mobile-design-sync의 초벌 방식은 심플했습니다. 피그마 전체 화면 스크린샷, 모바일 웹 스크린샷, 모바일 앱 스크린샷을 찍어 AI에게 보여주고 “다른 부분을 찾아 고쳐라”고 시키는 것이었죠. 레이아웃이 크게 무너진 초벌 단계에서는 이 방법이 마법처럼 통했습니다.

그런데 완성도를 80%에서 99%로 끌어올리려 하자, 전체 화면 스크린샷 비교가 오히려 디자인을 망치는 역효과를 내기 시작했습니다. 크게 두 가지 이유 때문이었습니다.

1) PNG 압축 착시와 피그마 캔버스의 함정 (#dbdbdb vs #aaaaaa)

가장 짜증 났던 사례가 견적 요청(RFQ) 1단계 화면의 카테고리 선택 버튼들이었습니다.

피그마 시안과 맞춘다며 에이전트가 수정을 끝냈는데, 앱 화면을 보니 2열 그리드로 놓인 버튼들의 테두리가 유독 시커멓고 답답해 보였습니다. 확인해 보니 에이전트가 버튼의 기본(rest) 테두리 색상을 #aaaaaa로 넣어둔 상태였습니다.

왜 #aaaaaa를 넣었는지 추적해 보니 두 가지 문제가 겹쳐 있었습니다.

첫째로, 전체 화면을 한 장의 PNG로 캡처해 축소하면 1px짜리 연한 회색 테두리(#dbdbdb)가 주변 픽셀과 섞이면서 눈대중으로는 진한 회색(#aaaaaa)과 구분이 되지 않았습니다.

둘째로, 피그마 전체 화면 프레임 안에 예시로 배치된 버튼 인스턴스 하나가 디자이너가 작업하던 중 우연히 마우스 오버(hover) 상태로 놓여 있었는데, 에이전트가 스크린샷만 보고 그 호버 상태의 진한 테두리를 ‘기본 테두리’로 착각해 모든 버튼에 덮어씌운 것이었습니다.

결국 Figma MCP로 화면 전체 캡처가 아니라 개별 버튼 컴포넌트의 리프 노드 변수를 직접 조회하고 그 값을 사용하도록 스킬을 변경하고 나서야 이슈가 해결되었습니다.

스크린샷을 눈으로만 비교했다면 영영 못 잡았을 1px 단위의 미묘한 톤 차이였습니다.

색상 비교 <출처: 작가>

2) 데스크탑 웹과 모바일 웹의 반응형 차이에서 오는 혼선

또 하나 예상치 못한 복병은 기존 Next.js 웹 코드 안에 데스크탑 스타일과 모바일 스타일이 함께 섞여 있었다는 점이었습니다.

저희 웹은 Tailwind의 반응형 프리픽스(lg:gap-20, lg:p-10 등)로 데스크탑과 모바일을 한 컴포넌트에서 처리하거나, 화면에 따라 데스크탑에서는 컴팩트한 카드로 보여주고 모바일에서는 풀사이즈 카드나 바텀시트로 보여주는 곳들이 있었습니다.

반응형 사이즈 비교 <출처: 작가>

처음에는 피그마 시안과 웹 코드, 앱 코드를 한꺼번에 열어두고 싱크를 맞췄더니, 에이전트가 웹 코드에 적힌 데스크탑용 패딩(lg:p-10)이나 폰트 크기를 모바일 앱에 그대로 가져다 쓰는 실수가 반복됐습니다.

해결책: 스크린샷은 배치만 보고, 스타일은 수치로 읽되 ‘한 번에 한 축씩’ 조이기

이 시행착오 끝에 디자인 싱크 2라운드에서는 규칙을 완전히 바꿨습니다.

반드시 모바일 웹(@375px)을 먼저 피그마와 맞춘 뒤 앱으로 넘어간다: 피그마-웹-앱 3자 비교를 금지했습니다. 무조건 1단계(Figma → 모바일 웹 375px 뷰포트)에서 반응형 깨짐이나 토큰 누락을 먼저 다 잡고, 완벽히 검증된 모바일 웹을 기준으로 2단계(모바일 웹 375px → 모바일 앱)를 진행했습니다.
스크린샷과 노드 검사의 역할을 분리한다: 전체 화면 스크린샷은 블록의 순서나 하단 고정 버튼 위치 같은 큰 레이아웃 배치를 확인할 때만 쓰고, 색상·폰트·간격은 반드시 Figma 리프 노드의 토큰 이름과 픽셀 수치를 직접 읽어와 공통 디자인 토큰과 UI 패키지에 반영했습니다.
한 번에 하나의 디자인 축(Axis)만 수정한다: 한 번에 테두리, 폰트 크기, 패딩을 다 고치라고 시키면 하나가 맞아도 다른 하나가 틀어졌습니다. 그래서 border → font → spacing처럼 하나의 기준점으로 쪼개어, 한 번에 한 가지씩만 체크하고 넘어가는 방식으로 회귀를 막았습니다.

마치며: “앱 출시까지 2주면 된다”를 직접 테스트해 본 최종 후기

1편과 하편에 걸친 실험을 마무리하며, 처음 던졌던 질문으로 돌아가 보려 합니다.

“정말 AI와 모노레포가 있으면 모바일 웹을 앱으로 만들어 출시하는 데 2주면 충분할까?”

직접 부딪혀 본 제 대답은 “절반은 맞고, 절반은 틀렸다”입니다.

맞았던 절반은 ‘속도’입니다. 예전 같았으면 React Native 프로젝트를 세팅하고 수십 개의 화면과 컴포넌트를 일일이 손으로 옮기는 데만 한 달이 훌쩍 넘게 걸렸을 겁니다. 이미 돌아가는 Next.js 모바일 웹을 SSOT로 삼고, 모노레포와 자동화 스킬을 엮어 단 일주일 만에 모든 화면이 연결된 앱 POC를 눈앞에 띄운 것은 분명 AI 시대에만 가능한 속도였습니다.

틀렸던 절반은 ‘디테일’입니다. 화면을 빠르게 찍어내는 것과, 그 앱을 스토어에 출시해 실제 고객의 계약을 책임지게 만드는 것은 전혀 다른 영역이었습니다.

물론 토큰을 더 태운다거나 디테일보다는 속도에 집중하면 큰 문제가 안 될 수도 있었습니다. 하지만 사이드 프로젝트인 만큼 토큰을 무작정 태울 수도 없었고, 디테일을 타협하는 것은 제 생각일 뿐 함께 일하는 디자이너분께는 포기할 수 없는 문제였죠.

그럼에도 한 가지 확실한 건, 1주일 만에 초벌 앱을 뽑아내는 ‘속도’가 있었기에 남은 시간과 에너지를 온전히 이 ‘디테일한 체크’에 쏟아부을 수 있었다는 점입니다. 코딩 자체에 치여 정작 중요한 앱 UX와 푸시 경험, 디자인 완성도를 타협하는 대신, 진짜 제품다운 디테일을 집요하게 파고들 수 있었습니다.

혹시 지금 돌아가는 웹 서비스를 바탕으로 빠르게 앱 출시를 고민하고 계신다면, 초반에는 과감하게 자동화 워크플로로 속도를 내어 POC를 올리시되, 그다음에는 반드시 속도를 내려놓고 UX 경계·로직 SSOT·네이티브 기본기·토큰 단위 디자인을 하나씩 체크하는 시간을 일정에 꼭 넣어두시길 추천합니다.

긴 호흡의 상·하편 여정을 끝까지 읽어주셔서 감사합니다.

]]>

코드 멀쩡한데 트래픽 떨어졌다면? 배포 전 SEO 장애 막는 품질 게이트 전략

트래픽이 갑자기 떨어졌는데, 무엇이 바뀌었는지 아무도 모릅니다. SEO 실무자라면 한 번쯤 겪어 봤을 장면입니다. 지난 9월 3일과 4일 서울 마포에서 열린 ‘Search SEOul(서치 서울) 2026’에서는 이 익숙한 장면을 출발점으로 삼은 발표가 있었습니다. 올해 2회째인 서치 서울은 해외에서 주로 열리던 글로벌 SEO 컨퍼런스를 한국에서 열고, 한국 검색 환경과 해외 SEO·GEO 흐름을 함께 다루는 행사입니다.

요즘IT는 서치 서울 2026의 공식 미디어 파트너로서, 행사 발표 가운데 요즘IT 독자에게 도움이 될 만한 내용을 골라 전문을 소개하고 있습니다. 이번 글은 행사 둘째 날 오전, 아스펜 그룹(The Aspen Group)에서 AI 기반 SEO를 이끄는 조리 포드(Jori Ford) 시니어 디렉터가 ‘SEO Needs Quality Gates, Not Audits(SEO에 필요한 건 감사가 아니라 품질 게이트다)’라는 제목으로 발표한 내용입니다. 개발팀이 코드를 배포하기 전에 거치는 자동 검사 단계에 SEO 점검을 끼워 넣어, 문제가 터진 뒤에 찾아내는 대신 배포 전에 막자는 제안입니다. 영어로 진행된 발표를 한국어로 옮겼고, 발표 말미의 질의응답도 함께 실었습니다.

앞선 세션에서 감사(audit), 그러니까 사이트를 기술적으로 점검하는 이야기가 많이 나왔습니다. 우리 SEO 실무자들은 감사를 정말 자주 하죠. 그래서 본론에 들어가기 전에 이야기를 하나 들려 드리려고 합니다. 감사를 해 본 분이라면 대부분 어떤 식으로든 겪어 봤을 이야기, 한마디로 개발 작업이 SEO를 망가뜨린 이야기입니다.

코드는 멀쩡했는데, 트래픽이 떨어졌습니다

매일 애널리틱스를 들여다보는데 모든 게 순조롭습니다. 오가닉 트래픽도 아주 좋습니다. 그러다 트래픽이 떨어집니다. 여러분은 아무것도 하지 않았는데요. 그럼 트래픽은 왜 떨어졌을까요? 상사나 클라이언트에게서 무슨 일이냐는 전화가 오고, 여기저기 다 뒤져 봐도 답이 없습니다.

보통 그다음에는 웹사이트에, 기술 쪽에 무슨 일이 있었는지를 떠올립니다. 그래서 배포 이력, 새로 반영된 것들을 찾아봅니다. 엔지니어에게 “코드 배포한 거 있어요? 뭔가 잘못한 거 아니에요?” 하고 묻죠. 그런데 핵심은 바로 이 ‘잘못’이라는 말에 있습니다. 엔지니어는 잘못한 게 아닙니다. 원인이 엔지니어가 한 작업인 경우가 대부분이긴 하지만요.

이 이야기는 SEO 담당자가 엔지니어에게 요청한 수정이, 엔지니어의 손을 거쳐 결국 SEO에 해를 끼친 이야기입니다. 코어 웹 바이탈(Core Web Vitals)은 다들 아실 겁니다. 성능을 높이려고 엔지니어에게 코어 웹 바이탈을 개선해 달라고 요청해 본 분도 많을 거고요. 이 사례에서는 CLS(Cumulative Layout Shift, 누적 레이아웃 이동)를 개선하려는 코어 웹 바이탈 수정이 배포됐는데, 그 수정이 DOM을 망가뜨렸습니다. title 태그를 엉뚱한 곳으로 옮겨 버렸거든요. SEO 담당자가 SEO 문제이자 사용자 경험 문제를 풀어 달라고 엔지니어에게 요청했는데, 그 결과가 SEO를 해친 겁니다.

코어 웹 바이탈 수정 뒤 <head>에 있어야 할 title 태그가 <body>로 밀려난 사례. 실제로 반복되는 패턴을 합쳐 재구성한 대표 사례다

전날 발표에서 오케스트레이션, 즉 여러 부서의 일을 조율하는 이야기를 아주 잘 풀어 줬는데요. 부서마다 목표가 다르게 정해져 있습니다. 엔지니어에게 코어 웹 바이탈 수정을 요청하면 어떻게 될까요? 엔지니어는 성능을 고치려고 합니다. 이 사례에서 문제는 코드가 아니라 DOM이었습니다.

구글 문제가 아니라 크롤러 문제입니다

우리는 이런 일을 SEO 문제로 여길 때가 많습니다. 구글이 특정한 기술 작업을 하도록 우리를 몰아붙이니까요. 우리에겐 가이드라인이 있습니다. 전날에도 전략적으로 콘텐츠와 기술에 집중하라는 이야기를 들었고, 맞는 말입니다. 기술을 고치기 위한 구체적인 가이드라인이 있죠. 그런데 여기서 핵심은 ‘고친다’는 말입니다. 망가지지 않은 걸 어떻게 고칩니까?

크롤러가 여러분의 정보와 데이터에 접근하려면 아주 구체적인 무언가가 필요합니다. 크롤러는 그 정보를 뽑아낼 때 일관되게 DOM을 활용합니다. 그러니 DOM이 구조를 갖추고 있어야 합니다. 코드를 위계에 맞게 구조화하라는 말, 구조화 데이터가 있어야 코드를 이해할 수 있다는 말을 얼마나 자주 듣습니까? 그러니 이건 구글 문제가 아니라 크롤러 문제입니다.

제 발표를 들어 본 분은 아시겠지만, 저는 크롤러를 정말 좋아합니다. 그 기반이 되는 층을 이해하지 못하면 SEO 일을 제대로 해낼 수 없다고 생각합니다. 모든 게 크롤러와 연결돼 있습니다. 그리고 모든 게 크롤러와 연결돼 있다면, 기술은 우리 모두가 일을 잘 해내는 데 필요한 토대입니다. 그 토대가 깨지면 우리는 실패합니다. AI 답변도 크롤러를 쓰고, 쇼핑 봇도 크롤러를 씁니다. 구글도 네이버도 모두 크롤러에 기대고 있습니다. 이게 핵심입니다.

이 크롤러들은 아주 특화된 구조를 요구합니다. 그 때문에 우리는 팀의 다른 구성원들에게 그 구조를 대신 만들어 달라고 가르쳐야 했습니다. 저는 이걸 바꾸고 싶습니다. 우리가 팀과 더 나은 파트너, 더 나은 오케스트레이터가 되도록 돕고 싶어요. 기술이 그 토대라면, 우리가 해야 할 단 한 가지는 엔지니어링팀과 더 나은 파트너가 되는 겁니다.

어떻게 하면 될까요? 저는 엔지니어에게 무엇을 고치라고 지시하고 감사를 하는 대신, 우리가 그들의 프로세스 안으로 들어가자고 제안합니다. 파트너의 프로세스를 들여다보고, 거기에 녹아드는 겁니다.

엔지니어가 매일 쓰는 CI/CD 파이프라인

그래서 먼저 소개하고 싶은 게 대부분의 엔지니어가 매일 일하는 방식, CI/CD 파이프라인입니다. 발표장에서 물어보니 아는 분이 많지 않더군요. 에이전시든 컨설팅이든 인하우스 SEO든, 엔지니어는 여러분을 돕고 지원해 줘야 하는 사람들입니다. 그들의 지원을 받으려면 여러분도 그들이 하는 일을 이해해야 합니다.

여러분이 수정 요청을 보내거나, 감사 결과를 들고 가서 뭔가 망가졌다고 말하면 엔지니어 쪽에서는 이런 일이 일어납니다. 티켓이 들어가고, 그 티켓은 피처 브랜치(feature branch)에서 작업됩니다. 엔지니어는 코드를 작성해 저장소(repository)라는 곳에 푸시합니다. 이 저장소는 엔지니어가 일을 잘 해낼 수 있도록 짜여 있어서, 코드를 푸시하면 자동으로 CI 파이프라인을 거칩니다.

일반적인 CI/CD 파이프라인의 네 단계. 피처 브랜치에 푸시하는 커밋, 빌드·린트·자동 테스트를 돌리는 CI, 동료가 PR을 승인하는 코드 리뷰, 병합 후 스테이징을 거쳐 프로덕션에 배포하는 CD. 대부분의 팀에 이미 있지만 어느 단계에서도 SEO는 점검하지 않는다

CI 파이프라인은 한마디로 사전 테스트입니다. 망가진 코드를 내보내지 않도록 미리 확인하는 장치죠. 그런데 SEO는 코드가 망가졌느냐 고쳐졌느냐의 문제가 아닙니다. 우리는 엔지니어에게 우리가 원하는 대로 코드를 리팩터링하고 수정해 달라고 요청하는 겁니다. 엔지니어는 뭔가를 망가뜨리는 게 아니라, 무엇을 내보내야 하는지 모를 뿐입니다. 그래서 저는 우리가 이 파이프라인의 일부가 되자고 제안합니다. CI 단계에서 우리만의 테스트를 만들어 엔지니어를 돕자는 거죠.

CI 다음은 코드 리뷰입니다. 다른 엔지니어가 코드를 검토하면서 도와주고, 제대로 됐는지 확인합니다. SEO 쪽에서도 비슷한 걸 합니다. 사이트에 이런 작업을 했는데 한번 봐 줄 수 있는지, 괜찮아 보이는지 서로 묻습니다. 그런데 우리가 놓치는 게 있습니다. 엔지니어의 코드 리뷰는 다른 엔지니어가 웹사이트와 코드를 보고 망가지지 않았는지를 확인하는 일이라는 점입니다. 망가진 게 없으니 무엇을 고쳐야 하는지도 모릅니다.

코드 리뷰를 마치면 코드는 병합(merge)돼 프로덕션에 배포됩니다. 우리가 실패하는 지점이 바로 여기입니다. 엔지니어는 탄탄하고 잘 작동하는 코드를 병합해 내보냈는데, 그 코드가 사용자에게는 아무 문제가 없지만 우리에게는 문제가 되는 겁니다.

감사 대신 품질 게이트

그래서 제 제안은 이렇습니다. 앞선 세션에서는 감사를 많이 하라고 했는데, 이 대목에서만큼은 반대 의견을 내겠습니다. 저도 많은 것을 감사해야 한다고 생각합니다. 다만 기술 감사는 그만두고, 이미 있는 파이프라인에 참여하자는 겁니다. 그게 선제적인 방식입니다. 감사는 낡은 방식입니다. 엔지니어가 자기 일을 다 끝낸 뒤에야 돌아가니까요. 누군가 일을 잘 해냈는데 “잘하긴 했는데, 아주 잘못했어요”라는 말을 듣는다고 생각해 보세요. 아무도 그런 말을 듣고 싶어 하지 않습니다.

엔지니어는 일을 잘 해냈고, 우리는 그걸 인정해 주고 싶습니다. 그러니 너무 늦게, 수동으로 또는 정해진 일정에 따라 돌아가는 감사 대신 선제적인 품질 게이트(quality gate) 절차로 바라보자는 겁니다. 다들 스크리밍 프로그(Screaming Frog), 셈러시(Semrush), 에이레프스(Ahrefs) 같은 도구로 기술 감사를 돌리실 겁니다. 그리고 너무 늦게 알게 되죠. 트래픽은 이미 빠졌고, 엔지니어는 이미 수정을 배포했고, 이제 진짜 문제도 아닌 문제를 찾느라 엄청난 시간을 허비합니다.

품질 게이트는 문제가 생기기 전에 작동합니다. 문제가 밖으로 나가지 않으니 오가닉 트래픽이 깨질 일도 없고, 엔지니어가 일을 잘못했다는 말을 들을 일도 없습니다. 감사를 하면 우리는 피해를 찾아냅니다. 방식을 바꾸면 피해를 막을 수 있습니다. 사후 대응에는 돈과 시간이 들고, 우리 브랜드와 클라이언트도 타격을 입습니다. 그런데 엔지니어들은 이미 예방하는 시스템을 만들어 뒀습니다. 우리가 하고 싶은 것도 예방입니다.

감사(기존 SEO)와 품질 게이트(새로운 SEO) 비교. 감사는 배포 후 수동·정기로 돌며 이미 난 피해를 찾고, 품질 게이트는 병합 전 모든 PR에서 자동으로 돌며 피해를 막는다

그럼 어떻게 할까요? 엔지니어 친구들에게서 조금 빌려 오겠습니다. 엔지니어의 기존 파이프라인에는 지금 빠져 있는 게 있습니다. DOM을 보지 않는다는 점입니다. 엔지니어의 머릿속에 DOM은 없습니다. 엔지니어가 확인하는 건 웹사이트가 제대로 작동하느냐입니다. 버튼이 작동하는지, 폼을 채울 수 있는지, 올바른 응답이 오는지요. DOM이 망가졌는지는 보지 않습니다.

그래서 CI/CD 파이프라인 안에 DOM 렌더링 확인을 넣습니다. 이를 위한 스크립트를 우리가 직접 만들어 게이트를 세워 줍니다. 그러면 엔지니어는 코드를 내보낼 때 통과했는지 실패했는지를 그 자리에서 알게 됩니다. 문제 있는 코드를 내보내면 프로덕션에 가기 전에 거기서 멈춥니다. 플래그가 붙으니 미리 경고할 수 있는 거죠.

그리고 우리 자신에게 필요한 것, 피드백 루프를 닫는 일입니다. 뭔가 배포됐는데 우리는 전혀 모르는 경우가 얼마나 많습니까? 무언가 망가졌을 수 있다는 것도, 어떤 기능이 출시됐다는 것도 모르죠. 하지만 우리가 게이트의 일부가 되면 우리만의 피드백 루프를 만들 수 있습니다. 슬랙이나 팀즈 알림, 문자 메시지, 이메일로 우리에게 알림이 오게 하면 됩니다.

작은 수정이 큰 장애로 번지는 네 지점

제가 이게 왜 그렇게 중요하다고 생각할까요? 제 SEO 커리어의 90%는 기술에 관한 일이었습니다. 그 경력으로 CMO가 됐고, 이어 최고제품책임자(CPO)가 됐다가 지금은 다시 인하우스로 돌아왔습니다. 그런데 2000년대 초에 제가 풀던 바로 그 근본적인 문제가 여전히 그대로였습니다. 테크니컬 SEO로서 매번 똑같은 문제를 봐야 했습니다. title 태그가 엉뚱한 곳에 들어가 있거나, canonical 태그 때문에 색인이 망가지는 문제 말이죠. 배포된 작은 변경이 SEO에는 큰 장애를 일으켰습니다.

그리고 그건 우리가 그 작은 것들을 요청했기 때문에 벌어진 일이었습니다. 이커머스 사이트 템플릿에 프로그래매틱 SEO를 요청했는데, 그 템플릿에 뭔가가 배포되면서 DOM 전체가 다시 배치되고 잘못된 상태로 나가 버립니다. 스키마 마크업 변경을 요청했더니, CMS는 한쪽에서 스키마를 넣고 있는데 템플릿 단에서는 클라이언트 사이드에서 또 넣고 있습니다. 이런 일들이 모두 우리에게 큰 혼란을 일으킵니다. 예를 들어 보겠습니다.

관련 없는 코드가 바뀔 때 소리 없이 깨지는 템플릿 단의 네 요소. title 태그(<head> 안 위치), 레이아웃 이동(UX만이 아닌 DOM 재배치), 스키마 마크업(JSON-LD 유지), canonical·robots(소리 없는 색인 제외)

title 태그 위치

렌더링된 head 코드에 title 태그가 없다면 구글이든 네이버든, 어떤 검색엔진이든 그 태그가 있다는 걸 알 수 있을까요? 모릅니다. 작은 수정 하나가 렌더링 결과를 바꿔 버리면 이제 여러분 페이지에는 title이 없습니다. 구글은 제멋대로 제목을 만들어 내고, 여러분 브랜드는 마땅히 나와야 할 모습으로 검색 결과에 나오지 않습니다. 품질 게이트가 있었다면 렌더링된 DOM에서 title이 head 안에 있는지 확인하고 엔지니어에게 경고했을 겁니다.

실패 지점 1, 프로덕션에서 발견된 title 태그 위치 오류. 게이트는 <head> 안에 title이 정확히 하나 있고, <head> 밖에는 없으며, 내용이 비어 있지 않은지 확인한다

레이아웃 이동

우리는 앞으로도 코어 웹 바이탈 개선을 계속 요청할 겁니다. 그런데 문제가 있습니다. CLS까지 내려가면 엔지니어가 고칠 수 있는 방법은 몇 가지로 정해져 있습니다.

그 시간을 줄이려고 엔지니어가 가장 먼저 꺼내는 해법이 DOM을 다시 배치(reflow)하는 겁니다. 여러분은 그 몇 밀리초가 아주 값지다고 생각할지 모릅니다. 하지만 그 대가로 색인에서 빠질 위험을 감수해야 한다는 걸 안다면, 아마 그 몇 밀리초는 포기할 겁니다. 초록색(양호)으로 만드는 대가가 구글이 더는 페이지를 크롤링하지 못하는 거라면, CLS가 노란색(개선 필요)이어도 괜찮다고 할 겁니다.

이걸 품질 게이트에 넣으세요. DOM을 다시 배치해도 좋지만 다른 걸 망가뜨리지는 말라는 걸 엔지니어가 알게 하는 겁니다. 우리가 감수할 수 있는 최소선, 즉 임계치를 정해 두면 게이트가 경고해 줍니다.

실패 지점 2, CLS를 고치려고 DOM 순서를 바꾼 뒤 title 노드가 <body> 안에 중복으로 생긴 사례. 게이트는 CLS가 예산 안에 있는지와 함께, <head>에 속한 요소가 재배치 뒤에도 살아남았는지 확인한다

스키마 마크업

게이트에 또 무엇을 넣을 수 있을까요? 스키마 마크업입니다. 이번 행사에서 모두가 AI 이야기를 했고, 구조 이야기를 했고, 검색 결과에 노출되고 싶다는 이야기를 했습니다. AI는 페이지의 맥락을 이해할 때 구조화 마크업에 크게 의존합니다. 그런데 스키마 마크업의 구조가 잘못돼 있거나, 중첩이 제대로 안 돼 있거나, 두 번 삽입돼 있으면 AI는 이해하지 못합니다. 그러니 스키마가 제대로 나오는지 확인하는 것도 게이트에 넣으세요.

실패 지점 3, 병합 뒤 JSON-LD 블록이 사라진 사례. 화면에는 아무 이상이 없어 눈으로는 찾을 수 없다. 게이트는 렌더링 결과에 JSON-LD 블록이 하나 이상 있고, 파싱되며, @context·@type을 갖췄는지 확인한다

이 게이트들이 중요한데도 아직 표준이 아닌 이유, 그리고 제가 이 이야기를 하는 이유는 SEO가 그렇듯 모든 조정이 브랜드마다, 작동 방식마다 제각각이기 때문입니다. 이 모델도 마찬가지입니다. 엔지니어가 일하는 방식, 템플릿을 코딩하는 방식, 어떤 CMS를 쓰는지, 애초에 이걸 문제로 보는지에 따라 달라집니다. 이런 패턴이 여러분 비즈니스에는 아예 없을 수도 있고, 하나만 발견될 수도 있습니다.

canonical 태그와 meta robots

제게 가장 치명적인 건 이겁니다. 저는 제 사이트가 색인에서 빠지는 걸 원하지 않습니다. 중복 콘텐츠도 원하지 않습니다. 어떤 페이지가 가장 중요한지 검색엔진이 알 수 있도록 그렇게 공을 들였는데, 템플릿에 대한 CMS 업데이트 한 번이 그걸 전부 망칠 수 있습니다. 게이트에 넣는다면, 파트너를 돕는다면 그런 일은 없습니다.

실패 지점 4, 스테이징용 noindex 플래그를 지우지 않은 채 프로덕션에 배포한 사례. 공용 레이아웃 컴포넌트에 붙은 noindex는 사이트 전체를 한꺼번에 색인에서 빼낼 수 있다. 게이트는 허용 목록 밖에 noindex가 없는지, canonical이 <head> 안에 절대 경로로 하나만 있는지 확인한다

실제로 돌아가는 게이트

그래서 실제로는 어떤 모습일까요? 이렇게 말로만 하면 듣기 좋은 이야기처럼 들린다는 걸 압니다. 게이트에 넣으면 될 것도 같지만, 정말로 작동합니다. 제가 게이트를 직접 만들었습니다. 저는 발표할 때마다 오늘도, 내일도, 앞으로도 쓸 수 있는 자료를 남기려고 합니다. 그래서 누구의 파이프라인에든 오늘 바로 덧붙일 수 있는 기본 구조의 게이트를 만들었습니다. 기존 파이프라인을 흔들 필요가 없습니다. 깃랩(GitLab)이나 깃허브(GitHub) 같은 곳에 이 액션을 추가하면 됩니다.

잘못된 코드의 병합을 그 자리에서 멈추는 실제 깃허브 액션(GitHub Actions) 워크플로

엔지니어에게는 이게 어떻게 보일까요? 발표장에서는 시연 영상으로 보여 드렸습니다. 엔지니어가 코드를 배포하려는 장면입니다. 사실 영상 속 사람은 제 코드를 배포하는 저지만, 배포 과정은 똑같습니다. 엔지니어가 병합 요청(merge request)을 올리면 무슨 일이 일어나는지 보여 드리고 싶었습니다. 오늘 당장 실시간으로 할 수 있는 일이라는 걸 아셨으면 해서요. 엔지니어가 보게 되는 게 바로 이 게이트입니다. 코드를 내보낼 때 회귀 테스트가 돌고, 액션이 실행됩니다.

그러면 게이트가 빨간 플래그를 띄우고 무엇을 해야 하는지 알려 줍니다. 엔지니어는 그걸 검토할 수 있습니다. 게다가 저는 이미 슬랙에 연결해 뒀습니다. 그래서 여러분도 SEO 알림을 받는데, 엔지니어용이 아니라 여러분이 이해할 수 있는 쉬운 말로 옵니다. 어디를 살펴봐야 하는지, 엔지니어가 무엇을 배포했는지, 엔지니어와 무슨 이야기를 해야 하는지 알 수 있습니다. 그리고 나중에 엔지니어가 그걸 고쳤는지도 다시 확인할 수 있습니다.

게이트가 실패했을 때 SEO 담당자에게 가는 알림 예시. 무엇이 깨졌는지, 어디서(템플릿·브랜치·PR) 깨졌는지, 병합되면 어떤 영향이 있는지를 쉬운 말로 알리고, 해결될 때까지 상태(플래그 → 확인 → 수정 → 재검증)를 추적한다

품질 게이트의 좋은 점이 여기 있습니다. 게이트가 엔지니어의 코드 배포를 멈추니까, 엔지니어는 코드를 검토하고, 문제가 무엇인지 이해하고, 코드를 어떻게 리팩터링할지 정한 뒤 다시 내보낼 수 있습니다. 엔지니어도 원인을 파악하는 시간을 아끼고, 여러분도 시간과 돈을 아낍니다.

잘 통과하면 이렇게 됩니다. 품질 게이트가 돌고 모든 게 잘되면 엔지니어는 초록색 체크 표시를 봅니다. 그리고 무엇을 제대로 했는지 쉬운 말로 설명을 받습니다. 엔지니어가 배웠으니 같은 실수를 할 가능성도 줄어듭니다.

AI를 붙이면 게이트도 배웁니다

앞서 말했듯 게이트는 엔지니어를 막기만 하는 게 아닙니다. 엔지니어도 배우고, 여러분도 배웁니다. 지금 보여 드린 건 정적인 버전입니다. 이 정도로도 꽤 잘 돌아가고, 저는 마음에 듭니다. 각자 자기 방식으로 고쳐서 핵심 요소를 챙기면 된다고 생각합니다.

그런데 이걸 더 낫게 만들 수 있다면요? 저는 뭐든 더 낫게 만드는 걸 좋아하고, AI 시대에는 훨씬 더 낫게 만들 수 있다고 생각합니다. AI API와 연동하면 게이트가 스스로 학습합니다. 새로운 패턴이 보이면 그 패턴을 넣어 품질 게이트를 업데이트할 수 있습니다. 이런 일이 쌓일수록 AI가 더 잘 알아보고, 플래그가 많이 붙을수록 여러분은 어떤 새 습관을 들여야 하는지 알게 됩니다. 이제 엔지니어도 배우고 게이트도 배웁니다. 코드도 좋아집니다.

그렇게 배포를 이어 가면서 우리가 그만둔 게 있습니다. 감사를 그만뒀습니다. 엔지니어가 일을 잘하는 걸 가로막는 것도 그만뒀습니다. 그러면서도 우리 일은 빈틈없이 해냅니다. 우리 스스로 걸림돌이 되지 않는 겁니다. 우리 성과를 깎아 먹는 수정을 요청하는 건 우리에게 도움이 안 됩니다. 우리 시간도, 엔지니어의 에너지도 낭비합니다. 수정을 요청했는데 기술 부채 우선순위 목록 어딘가에 올라가서 언제 처리될지 영영 모르는 경우가 얼마나 많았습니까? 이제 그런 일은 없어야 합니다. 이게 그 해법입니다.

게이트가 배우면 여러분도 배우고, 여러분이 배우면 여러분이 남기는 코멘트가 좋아지고, 코멘트가 좋아지면 시스템 전체가 좋아집니다.

저는 이게 다른 부서와의 진정한 오케스트레이션이자 파트너십이라고 생각합니다. 이제 우리는 친구이자 동맹이고, 합리적이고 책임감 있게 함께 일합니다. 그리고 여러분에게는 숨 돌릴 여유가 생깁니다. 테스트하고 모델링할 여유, 파트너가 자기 일을 잘 해낼 거라고 믿을 여유 말이죠. 파트너도 여러분을 믿을 수 있습니다. 이제 여러분이 그들이 무엇을 상대하는지 이해하고, 그들이 매일 일하는 제약 안에서 함께 일하니까요.

어떤 도구로, 어떻게 들여올까

이런 게이트가 어떻게 돌아가는지 더 잘 이해하고 싶다면 아래 도구들을 익혀 보길 권합니다. 대부분 무료이고, 엔지니어가 자기 쪽에서 바로 적용할 수 있는 도구입니다.

제가 만든 저장소는 누구나 쓸 수 있습니다. 제 깃허브에 올려 뒀으니 링크드인으로 연락 주세요. 답이 조금 늦을 때가 있어서, 행사 중 점심 전이나 쉬는 시간에 저를 붙잡아 주시면 연결해서 저장소를 공유하고 사용법도 안내해 드리겠다고 말씀드렸습니다. README를 꼼꼼하게 써 뒀으니 엔지니어와 함께 보셔도 됩니다. 다만 기본 저장소이니, 여러분이 이걸 바탕으로 더 발전시키면 좋겠습니다.

품질 게이트에 쓸 수 있는 도구 지형. 헤드리스 브라우저·DOM 테스트(Playwright, Puppeteer), 성능 예산(Lighthouse CI), 스키마 검증(structured-data-testing-tool, Rich Results Test API), 크롤링 비교(Screaming Frog CLI 모드), CI/CD 연동(GitHub Actions, GitLab CI, 브랜치 보호 규칙). AI 진단은 그 위에 얹는 선택 사항이다

헤드리스 브라우저·DOM 테스트

플레이라이트(Playwright)와 퍼피티어(Puppeteer)는 엔지니어 대부분이 이미 알고 있을 겁니다. 브라우저를 헤드리스로 띄워 크롤링이나 추출, 리모델링을 해 본 사람이라면 익숙한 도구입니다.

성능 예산

코어 웹 바이탈을 다룬다면 라이트하우스(Lighthouse) 같은 도구를 쓰는 게 좋습니다. 직접 연동할 수 있습니다.

스키마 검증

구글이 제공하는 도구에 직접 연결하길 권합니다. 무료 API를 써서 처리할 수 있습니다.

크롤링 비교

엔지니어에게도, 우리에게도 정말 중요한 부분입니다. 엔지니어는 코드 수준에서 차이를 보고, 여러분은 여러분 쪽에서 두 환경의 차이를 볼 수 있습니다. 스크리밍 프로그를 권합니다. 엔지니어가 보는 코드와 비교할 수 있고, 엔지니어는 자기 환경에서 확인하면서 서로 메모를 공유하고 이야기를 나눌 수 있습니다.

CI/CD 연동

엔지니어에게 파이프라인이 있는지 모르거나 함께 다뤄 본 적이 없다면 그냥 물어보면 됩니다. 깃허브나 깃랩을 쓰는지, 그 밖의 비슷한 도구를 쓰는지요. 엔지니어가 정확한 답을 못 하면 “브랜치는 어떻게 보호하고 있어요?”라고 물어보세요. 그 답이 아마 여러분이 찾는 파이프라인일 겁니다.

이런 도구를 쓸 때 꼭 알아 두셨으면 하는 게 있습니다. 이걸 엔지니어에게 들고 가서 “오늘 당장 이걸 적용하고 매번 돌려야 합니다”라고 말하면 안 됩니다. 엔지니어는 그렇게 일하지 않습니다. 자기들 게이트를 만들 때도 먼저 시험해 봅니다.

그러니 이런 걸 도입한다면 기존 파이프라인과 나란히 돌려 달라고 요청하세요. 독립적으로 실행되는 액션으로 두고, 필수가 아니라 선택으로 두세요. 이게 잘 작동한다는 걸 엔지니어가 직접 보게 하고, 여러분이 그들의 일하는 방식을 이해하고 있다는 걸 보여 주세요. 그래야 두 부서 사이에 신뢰가 쌓입니다.

혼자든, 에이전시든, 인하우스든 오늘 시작할 수 있습니다

저는 이 방식이 우리 모두에게 통한다고 생각합니다. 컨설턴트도, 에이전시도, 인하우스도 계실 텐데, 어느 경우에나 기회가 됩니다.

혼자 일한다면 직접, 독립적으로 돌려 보세요. 파트너에게 그들의 깃허브 저장소에서 나란히 돌려 봐도 되는지, 내 브랜치를 따로 운영해도 되는지 물어보세요. 적어도 그들이 지금 무엇을 배포하는지, 어디에 기회가 있는지 이해할 수 있고, 더 나은 대화를 나눌 수 있습니다. 내가 그들을 어떻게 도울 수 있을지도 보입니다.
에이전시라면 영업에 쓰기 아주 좋은 기본 상품입니다. 지금 이걸 하는 곳은 없습니다. 저는 아무도 하지 않는 걸 가져오는 걸 좋아합니다. 개념적으로 우리가 더 잘할 수 있다고 생각하니까요.
인하우스라면 오늘 바로 엔지니어에게 가서 정말 멋지다고 말해 주세요. 오늘 배운 걸 이야기하고, 이걸 함께 세팅해서 시험해 봐도 되는지 물어보세요.

질의응답

발표 말미에는 사전에 받은 질문 두 가지에 답하고, 현장 질문을 하나 받았습니다.

Q. 사이트가 색인은 되는데 노출과 트래픽이 거의 없습니다. 구글 디스커버(Google Discover)에 들어가려면 무엇이 가장 중요할까요?

기술 주제에서 조금 벗어난 질문이라고 생각하실 수 있지만, 저는 SEO로서 이것저것 두루 다뤄 왔으니 답해 보겠습니다. 사이트 이름을 소리 내어 말하진 않겠습니다. 구글 디스커버에 들어가고 싶은 블로그입니다. 제가 보기에 이 블로그는 색인은 아주 잘 되고 있는데, 원하는 만큼의 노출과 키워드 클릭이 나오지 않는 게 문제입니다.

간단히 살펴봤더니 크게 두 가지 문제가 보였습니다. 첫째는 우리 SEO 실무자들이 즐겨 이야기하는 코어 웹 바이탈입니다. 코어 웹 바이탈은 사용자 경험을 이해하는 방법이고, 지금 좋은 사용자 경험을 제공하고 있느냐에 대한 구글의 해석일 뿐입니다.

이 사이트에는 사이트 전체가 렌더링되기 전에 먼저 렌더링되는, 존재감이 아주 강한 광고가 있습니다. 스스로 콘텐츠를 가려 구글이 접근하지 못하게 막고 있는 셈이죠. 그러니 코어 웹 바이탈 성능부터 챙기세요. 우선 렌더링을 막는 요소를 모두 걷어내 콘텐츠에 실제로 접근할 수 있게 해야 합니다. 지금은 구글이 콘텐츠를 보지 못하고 있으니까요.

둘째, 이 사이트는 여행 분야인데, 여행 분야에서는, 특히 한국에서는 E-E-A-T, 그중에서도 전문성을 봅니다. 블로그를 둘러보니 전문 여행 업체가 없었습니다. 여행사를 대변해 이야기하는 사람도, 이 분야에서 이력을 쌓은 사람도 없었습니다. 권위 측면에서도 문제가 있습니다. 이 사이트를 가리키는 권위 있는 사이트가 없고, 이 사이트도 그런 사이트를 가리키지 않습니다. 데이터를 가져오는 정부 사이트들은 관련성이 있습니다. 하지만 이 사이트가 관련성을 얻으려면 전문가들도 이 사이트를 가리켜야 합니다.

Q. 새로 낸 앱을 앱 스토어에서 더 많이 내려받게 하려면 어떻게 해야 할까요?

처음에는 답하지 못할 줄 알았는데, 생각해 보니 제가 푸드보스(FoodBoss)에서 CMO로 일하면서 앱 다운로드 수를 100건에서 1만 건 남짓까지 늘렸더군요. 그러니 답할 수 있을 것 같습니다.

저는 우리 사업의 틈새, 이 경우에는 음식 배달에 집중했습니다. 도어대시(DoorDash)를 비롯한 거대 기업들과 경쟁해야 했죠. 저는 키워드가 아니라 사람들이 겪는 문제에 집중했습니다. 사람들의 문제에 집중하면 사람들이 여러분을 찾아옵니다. 그 문제에 맞춘 랜딩 페이지를 두세요. 사람들이 찾아오면 앱 다운로드로 이끌면 됩니다.

다음으로, 테스트 프로그램을 만드세요. 이걸 하지 않는 곳이 많던데, 다운로드와 좋은 리뷰, 솔직한 피드백을 얻는 쉬운 방법입니다. 자체 프로그램을 시작해 베타나 알파 단계의 앱을 내려받아 달라고 하고, 피드백을 직접 달라고 요청하세요. 그리고 문제를 바로 고치세요. 문제를 고쳐 주면 그 사람들이 공개적으로 리뷰를 남깁니다. 좋은 관계가 생기고, 새 고객이 생기고, 이게 테스트 플랫폼의 일부가 됩니다.

앱 스토어 페이지는 대표 키워드(head term)가 아니라 구체적인 표현에 맞춰 최적화하세요. 앱 스토어에 들어가면 선두에 서서 판을 이끌고 싶어지기 마련인데, 꼭 그럴 필요는 없습니다. ‘보안 앱’과 ‘스미싱 공격 방지 앱’을 비교해 보세요. 후자가 더 롱테일이지만 훨씬 좋은 성과를 냅니다. 그리고 플레이 스토어 광고를 쓰세요. 경쟁이 덜한 키워드를 노린다면 그 키워드를 차지하고 경쟁사 옆에 노출될 수 있습니다. 그러면 브랜드가 알려집니다.

Q. (현장 질문) 웹사이트에 마크다운 연동을 넣는 곳이 많아 저도 버튼 형태로 추가했는데, AI 트래픽에는 이렇다 할 효과가 없었습니다. 특히 고객지원 페이지에서 마크다운이 의미가 있는지 경험을 듣고 싶습니다.

좋은 질문입니다. 사실 작년 테크 SEO 커넥트(Tech SEO Connect)에서 이 주제로 이야기했습니다. 마크다운은 가치가 있지만, 그 가치는 사이트 규모에 달려 있습니다. AI 크롤러를 인색한 봇이라고 생각하세요. 바로 얻을 수 있는 정보에 에너지를 낭비하고 싶어 하지 않습니다. 페이지의 텍스트에서 맥락을 뽑아낼 수 있다면 마크다운은 완전히 무시합니다.

이번엔 방대한 정보를 담은, 엄청나게 큰 사이트를 떠올려 보세요. 마크다운이 실제로 의미를 갖는 건 이럴 때입니다. 크롤러가 이미지를 다 해석하지 못하고 자바스크립트를 다 파싱하지 못할 때, 그리고 head에서 마크다운의 존재를 알려 정보를 더 쉽게 가져갈 방법이 있다는 표시를 줄 때입니다. 그렇지 않으면 크롤러는 마크다운을 통째로 무시합니다.

]]>

모델이 그렇게 좋다면 오픈AI는 왜 직접 회사를 차리지 않을까

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: huashu-motion - 말 한마디로 제품 출시 영상을 만드는 AI 스킬
참고할 것: 앤트로픽 상장 신청서(S-1) - 클로드를 만드는 앤트로픽은 어떻게 돈을 벌고 있을까
적용해볼 것: 모델이 그렇게 좋다면 오픈AI는 왜 직접 회사를 차리지 않을까, 해커뉴스 댓글 750여 개가 내놓은 답

<출처: alchaincyf/huashu-motion, GitHub>

1. 써볼 것: 말 한마디로 제품 출시 영상을 만드는 AI 스킬

새 기능을 내놓을 때 30초짜리 소개 영상이 있으면 좋겠다고 생각해도, 영상 편집 도구가 낯설면 결국 스크린샷 몇 장으로 대신하게 됩니다. huashu-motion은 클로드 코드(Claude Code)나 코덱스(Codex) 같은 AI 코딩 도구에 "우리 제품 30초 출시 영상 만들어줘"라고 말하면 영상을 만들어주는 스킬입니다. 중국에서 AI 가이드북을 펴내는 크리에이터 화수(花叔, Huashu)가 10월 18일 공개했고, 열흘 만에 GitHub 스타 1,800개를 넘었습니다. 화수는 앞서 클로드의 디자인 기능을 스킬로 옮긴 huashu-design도 만들었습니다.

시작은 앤트로픽의 새 기능이었어요. 10월 8일 앤트로픽은 클로드 모션(Claude Motion)을 Team·Enterprise 요금제에 베타로 내놨습니다. 클로드가 보고서나 차트, 제품 설명을 짧은 애니메이션으로 만들고, 화면을 가리켜 고칠 수 있게 한 기능입니다. 화수는 이 발표를 보고 클로드 코드에 "클로드 모션의 능력을 완전히 재현하고, 훨씬 강하게 만들자"는 한 문장만 주고 작업을 맡겼다고 합니다.

어떻게 만들어지나요?

영상을 부탁하면 huashu-motion은 아래 순서로 일합니다.

제품 웹사이트나 자료를 읽고 분위기를 파악합니다.
방향이 서로 다른 시안 세 가지를 대표 장면으로 보여주고 하나를 고르게 합니다.
장면마다 박자를 정한 리듬표를 쓰고, 영상과 배경음악을 만듭니다. 음악은 AI가 악보를 쓰고 피아노·현악·드럼 소리로 연주하는 방식이라, 장면이 바뀌는 순간이 박자에 맞아떨어집니다.
브라우저에 편집기를 열고 사용자의 의견을 기다립니다.

영상 생성 AI는 쓰지 않습니다. 화면을 모두 웹 애니메이션 코드로 그리기 때문에 영상 한 편이 웹페이지 파일 하나예요. 그래서 글자나 숫자 하나만 바꿔도 나머지 장면은 그대로 유지됩니다. 대신 사람이 나오는 실사 장면은 만들지 못하죠.

화면을 가리켜서 고칩니다

마음에 들지 않는 장면이 있으면 편집기에서 C 키를 누르고 화면을 클릭한 뒤 "첫 장면이 별로야, 타이핑하는 모습에 집중해줘"처럼 적으면 됩니다. 그 시점과 장면, 클릭한 요소가 함께 AI에게 전달되고, AI는 그 부분만 고쳐요. 제목, 숫자, 색, 장면 길이는 오른쪽 입력칸에서 직접 바꿀 수 있고, 고친 버전이 모두 남아 언제든 되돌릴 수 있습니다.

화면을 클릭해 의견을 남기면 그 부분만 고칩니다 <출처: huashu-motion>

출시 영상 말고도 쓸 데가 있습니다. 데이터 파일(CSV)을 주고 "가입률이 왜 두 배가 됐는지 30초로 설명해줘"라고 하면 지표를 설명하는 영상을 만들고, 내 녹음 파일을 주면 말하는 단어에 맞춰 화면이 바뀌고 자막이 붙습니다. 가로 영상을 세로로 바꾸거나, MP4·GIF·배경이 투명한 영상으로 내보낼 수도 있어요.

어떻게 이런 영상이 나오나요?

화수는 첫날 결과물이 스스로 보기에도 지루했다고 털어놨습니다. 편집기와 버전 관리, 테스트 100여 개까지 갖췄지만, 클로드에게 프로젝트를 평가해달라고 하자 "공유하고 싶은 작품은 아직 하나도 없다"는 답이 돌아왔다고 해요. 화수는 그날 바로 처음부터 다시 만들었습니다.

그 뒤로는 영상을 보기 좋게 만드는 데 시간을 썼습니다. 애플, 구글, 앤트로픽 등의 실제 출시 영상 21편에서 장면이 바뀌는 순간과 박자, 소리 크기를 하나하나 측정하고, 반응이 좋았던 영상 142편을 뜯어봐 움직임 유형 20가지로 정리했어요. 3초 안에 눈길을 끌고, 중간에 한 번 크게 터뜨리고, 가장 큰 장면 앞에서는 한 박자 쉰다는 규칙도 여기서 나왔습니다. 작업하며 받은 "PPT 같다", "지루하다" 같은 피드백도 규칙으로 바꿔 스킬에 넣었다고 합니다.

저장소에는 지난주 다룬 클로드 듀엣을 소재로 만든 비공식 팬 영상도 있습니다. 화수는 듀엣이 나온 날 "클로드 코드와의 차이, 대기 명단이라는 이용 조건, dots·Muse·Grok Bot과의 경쟁을 담아 영상을 세 가지 버전으로 만들고, 90점이 넘어야 완성"이라고 요청했어요. 이어서 "나한테 확인받지 말고 혼자 끝까지 해", "자막보다 움직임과 시각적 비유로 표현해" 두 마디를 더했고, 그 뒤로는 의견을 주지 않았습니다. 점수는 별도의 평가용 AI가 매겼고, 영어판은 9번째 버전에서 91점을 받아 완성됐다고 합니다.

huashu-motion으로 만든 클로드 듀엣 팬 영상(비공식) <출처: huashu-motion>

어떻게 쓰나요?

AI 코딩 도구에 "huashu-motion 스킬을 설치하고 데모를 돌려줘"라고 부탁하거나, 아래 명령어 한 줄로 설치합니다.

npx skills add alchaincyf/huashu-motion

설치하려면 Node 22 이상과 Chrome, 영상을 내보낼 때 쓰는 FFmpeg가 필요합니다. 빠진 게 있으면 AI에게 설치를 맡기면 됩니다. 그다음 "huashu-motion으로 우리 제품 30초 출시 영상 만들어줘. 웹사이트는 OOO이야"라고 말하면 작업이 시작돼요.

MIT 라이선스라 무료이고, 영상을 만드는 데 드는 AI 사용량은 각자 쓰는 AI 코딩 도구의 요금제에서 차감됩니다. 화수는 주로 클로드 오퍼스 5.5로 만들었고, 딥시크(DeepSeek)의 저렴한 모델로 바꿔 22초 영상을 30분 안에 만든 사례도 소개했습니다. 다만 모델마다 영상의 감각이 다르다고 덧붙였어요. 4초가 넘는 영상은 끝에 "Made with huashu-motion"이라는 작은 문구가 들어가는데, AI에게 말하면 뺄 수 있습니다. 안내 문서는 중국어가 기본이고 영어판도 있습니다.

누구에게 좋을까요?

기능 출시 소식을 짧은 영상으로 알리고 싶은 기획자와 마케터. 웹사이트 주소 하나로 시안 세 가지를 받아볼 수 있습니다.
출시 영상의 방향을 빠르게 잡아보고 싶은 디자이너. 장면을 클릭해 고치거나 색과 숫자를 직접 바꿀 수 있습니다.
지표 변화를 공유해야 하는 사람. 데이터 파일 하나로 30초짜리 설명 영상을 만들 수 있습니다.
다만 클로드 코드 같은 AI 코딩 도구가 있어야 쓸 수 있고, 화수는 macOS에서만 실제로 테스트했다고 밝혔습니다. 공개된 지 열흘 된 개인 프로젝트라는 점도 감안하면 좋겠습니다.

<출처: Anthropic, Form S-1, SEC>

2. 참고할 것: 클로드를 만드는 앤트로픽은 어떻게 돈을 벌고 있을까

앤트로픽이 10월 26일 미국 증권거래위원회(SEC)에 상장 신청서(S-1)를 공개했습니다. S-1은 회사가 주식시장에 상장하기 전에 사업 방식과 재무 상태를 낱낱이 밝히는 문서예요. 이 소식은 해커뉴스에서 추천 1,700개, 댓글 1,600개를 넘겼습니다. 이 문서에는 매일 쓰는 클로드를 만드는 회사가 어디서 돈을 벌고 어디에 쓰는지가 처음으로 자세히 담겼습니다. 이번에는 상장 일정이나 주가 대신 이 이야기를 살펴봅니다.

얼마나 버나요?

앤트로픽의 매출은 2023년 4,100만 달러에서 2024년 3억 8,600만 달러, 2025년 46억 달러로 늘었습니다. 올해 상반기에만 163억 달러를 벌었는데, 지난해 같은 기간 12억 달러의 14배 가까이 됩니다. 반년 매출이 지난해 1년 매출의 세 배를 넘은 셈이죠.

어떻게 버나요?

돈을 버는 방식은 크게 두 가지입니다.

쓴 만큼 내는 방식: 클로드가 처리한 양을 토큰 단위로 재고, 고른 모델(Mythos, 오퍼스, 소넷, 하이쿠)에 따라 값을 매깁니다. 클로드를 자기 서비스에 넣는 회사, 그리고 클로드 코드 같은 앤트로픽의 앱을 쓰고 사용량만큼 결제하는 고객이 이 돈을 냅니다. 올해 상반기 매출의 80%(131억 달러)입니다.
구독: 개인용 Pro·Max나 기업용 요금제처럼, 정해진 사용량을 기간 단위로 사는 방식입니다. 상반기 매출의 20%(32억 달러)를 차지해요.

두 방식은 이어져 있습니다. 구독 한도를 다 쓰면 상위 요금제로 올리거나 사용량을 추가로 사게 되고, 이때 산 사용량은 쓴 만큼 내는 매출로 잡힙니다. 앤트로픽은 앞으로도 쓴 만큼 내는 매출이 대부분을 차지할 거라고 밝혔습니다. 클로드 코드를 "자율적으로 일하는 AI가 어떤 모습인지 가장 분명하게 보여준 제품"이라며 앞세웠지만, 클로드 코드만의 매출은 따로 적지 않았어요.

누가 돈을 내나요?

대부분 기업입니다. 9월 30일 기준으로 1년에 10만 달러 넘게 쓰는 고객이 1만 1,900곳을 넘고, 100만 달러 넘게 쓰는 곳은 1,900곳 이상, 1,000만 달러 넘게 쓰는 곳도 약 250곳이에요. 기존 고객이 쓰는 돈은 1년 사이 약 9배로 늘었습니다(개인 구독 제외). 매출이 몇몇 고객에게 몰렸다는 보도도 있었지만, 신청서에 따르면 올해 9개월 동안 매출의 10%를 넘은 고객은 없습니다. 상위 다섯 곳을 합쳐도 약 25%예요.

고객이 늘어나는 방식도 밝혔습니다. 개발자 같은 개인이 먼저 클로드를 써보고 회사 안에서 쓰자고 권하면서 팀 전체로 퍼진다는 거죠. 앤트로픽의 영업팀이 찾아갈 즈음엔 그 회사가 이미 클로드를 쓰고 있는 경우가 많다고 해요. 앤트로픽이 개인 구독을 기업 계약으로 가는 첫걸음으로 보는 이유입니다.

파는 경로도 여럿입니다. 상반기 매출의 48%가 AWS, 구글 클라우드, 마이크로소프트 애저 같은 클라우드 회사의 마켓플레이스를 거쳐 들어왔어요. 계약은 앤트로픽이 고객과 직접 맺고, 클라우드 회사에는 수수료를 냅니다. 액센츄어, 딜로이트 같은 컨설팅 회사와 세일즈포스 같은 데이터 플랫폼도 클로드를 고객에게 연결해줍니다. 최근에는 사모펀드와 함께 AI 서비스 회사 Ode with Anthropic을 세워, 중견기업에 클로드 기반 솔루션을 직접 만들어주기 시작했어요.

어디에 쓰나요?

버는 만큼 씁니다. 올해 상반기 비용은 약 170억 달러로 매출보다 조금 많았습니다. 가장 큰 항목은 모델을 연구하고 학습시키는 연구개발비로 97억 달러였습니다. 이어서 영업과 마케팅에 38억 달러, 고객의 요청을 처리하는 연산 비용에 24억 달러가 들었어요.

앤트로픽은 효율이 좋아지고 있다고 강조합니다. 2분기 매출이 1년 전보다 1,368% 느는 동안 연산·인프라 비용은 300% 느는 데 그쳤고, 직원 한 명당 연 매출은 1년 새 140만 달러에서 660만 달러 이상으로 늘었다고 해요. 모델이 좋아질수록 같은 일을 더 싸게 처리할 수 있게 되고(오퍼스 5.5는 오퍼스 5보다 작업당 고객 비용이 약 40% 낮다고 합니다), 값이 내려가면 더 많이 쓰게 된다는 설명입니다. 다만 앤트로픽 스스로도 지금의 성장은 시장 초기라서 가능한 것일 수 있고, 성장률은 앞으로 떨어질 거라고 적었습니다.

<출처: Hacker News>

3. 적용해볼 것: 모델이 그렇게 좋다면 오픈AI는 왜 직접 회사를 차리지 않을까, 해커뉴스 댓글 750여 개가 내놓은 답

10월 22일 해커뉴스에 이런 질문이 올라왔습니다. "모델이 그렇게 좋다면, 오픈AI는 왜 회사 100개를 직접 차리지 않을까?" 질문한 사람은 100개는 과장이라고 스스로 밝히며 이렇게 덧붙였어요. 최고 수준의 모델이 그렇게 뛰어나다면 오픈AI나 앤트로픽은 왜 모델을 파는 걸 주된 돈벌이로 삼을까, 그 모델로 직접 제품을 만들면 더 많이 벌 수 있지 않을까, 토큰 값이 계속 떨어지는데 돈은 오히려 앱을 만드는 쪽에서 더 벌리지 않을까.

이 질문은 추천 680개를 받았고 댓글이 750개 넘게 달렸습니다. 앞에서 본 앤트로픽의 S-1을 떠올리면 질문이 더 실감 납니다. 앤트로픽 매출의 80%가 쓴 만큼 내는 모델 사용료이고, 직접 서비스 회사를 세운 건 이제 막 시작한 일이니까요.

해커뉴스 독자들은 어떻게 답했나요?

답은 크게 네 갈래로 나뉘었습니다.

AI는 두뇌일 뿐이다: 가장 많은 답글(139개)이 달린 댓글입니다. 맥킨지가 포춘 500대 기업의 사정을 속속들이 알면서도 그 회사들을 직접 경영하지 않는 것과 같다는 비유예요. 회사에는 두뇌 말고도 손발과 사람 사이의 관계가 필요하고, 아이디어가 아무리 많아도 회사를 키우려면 수년의 시간과 인내, 자본이 든다는 겁니다.
만드는 건 쉬워졌고, 어려운 건 고객이다: 한 사람은 작은 SaaS를 하룻밤 만에 만들었는데, 첫 고객은 가족 중 한 명이었고 그 사람이 몇 명을 더 데려왔다고 했어요. 제품만 있었다면 작은 가게들에 아무리 영업 전화를 돌려도 실제 사용자는 한 명도 못 구했을 거라고 덧붙였습니다. 소프트웨어는 사업의 일부일 뿐이고, 나머지 부분이 더 어렵다는 답이 여럿 달렸습니다.
금을 캐는 것보다 곡괭이를 파는 게 낫다: 애플이 앱스토어의 앱을 전부 직접 만들지 않는 것과 같다는 의견입니다. 누가 성공하든 토큰을 판 쪽은 위험 없이 돈을 받는다는 거죠. 오래 일하는 AI 에이전트가 토큰을 많이 쓰니, 지금은 그쪽이 매출을 확실히 늘리는 방법이라는 현실적인 설명도 나왔습니다.
사실 이미 하고 있다: AI 회사들이 내놓은 제품 때문에 개발 도구나 업무 자동화 도구 같은 분야의 회사들이 이미 존재 이유를 설명하기 어려워졌다는 댓글에도 130개 넘는 답글이 달렸습니다.

해커뉴스에서 가장 많은 답글이 달린 댓글 <출처: Hacker News>

반론도 있었습니다. 에이전트로 쉽게 만들 수 있는 사업이라면 다른 사람의 에이전트도 똑같이 만들 수 있으니 그 사업의 이익은 금방 사라진다는 지적이 나왔습니다. 모델이 그 정도로 좋지 않다는 회의론도 있었습니다. AI 회사들도 여전히 개발자 수천 명을 고용하고 있다는 게 근거였어요.

무엇을 생각해볼 수 있을까요?

첫째, 만드는 비용이 떨어질수록 만든 다음의 일이 더 중요해집니다. 하룻밤에 SaaS를 만든 사람도 첫 고객은 가족에게서 얻었죠. 기능을 빨리 만드는 것만큼, 누가 처음 써줄지와 그 사람에게 어떻게 알릴지 정해두는 일도 중요합니다.

둘째, 모델을 직접 만드는 앤트로픽도 고객을 만나는 일은 다른 회사와 함께합니다. 매출의 절반 가까이가 클라우드 회사의 마켓플레이스를 거쳐 들어오고, 컨설팅 회사와 데이터 플랫폼이 고객을 연결해줘요. 이미 고객과 관계를 맺고 있는 곳과 손잡는 편이, 고객을 처음부터 직접 찾는 것보다 빠르다고 판단한 것으로 보입니다.

셋째, 반론에서 나온 질문은 내 제품에도 던져볼 만합니다. 내가 AI로 하루 만에 만든 기능이라면 경쟁자도 하루 만에 만들 수 있어요. 그때 경쟁자가 쉽게 따라 하지 못하는 건 기능보다, 고객과 쌓아온 관계나 고객 데이터, 고객이 우리를 찾아오는 경로일 가능성이 큽니다.

적용해볼 수 있는 것

지금 만들고 있는 기능 하나를 골라, 경쟁자가 AI 코딩 도구로 일주일 안에 따라 만들 수 있을지 적어보세요. 따라 할 수 있다면, 기능 말고 우리만 가진 것은 무엇인지 생각해보세요.
다음 기능을 만들기 전에, 완성되면 가장 먼저 써줄 사람 다섯 명의 이름을 적어보세요. 다섯 명이 떠오르지 않는다면 만드는 것보다 그 사람들을 찾는 게 먼저일 수 있습니다.
이번 주에 쓴 시간을 만드는 일과 고객을 만나고 알리는 일로 나눠보세요. 한쪽으로 크게 기울었다면 다음 주 일정을 조정해보세요.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

이 글은 AI의 도움을 받아 작성했습니다.

]]>

국내 FDE 현황 조사 2026: 현장 FDE에게 직접 묻습니다

FDE를 바라보는 두 가지 시선

현재 ‘FDE(Forward Deployed Engineer)’라는 직무를 두고 시선이 엇갈립니다. 한쪽에서는 FDE를 AI 시대의 새로운 직무로 봅니다. 고객 현장에 직접 들어가 문제를 정의하고, 그 경험을 다시 제품으로 가져오는 사람이라는 거죠. FDE라는 직무를 처음 만든 팔란티어의 영국 AI 총괄 닉 프레티존(Nic Prettejohn)은 이 일을 “안에서부터 하는 제품 발견(product discovery from the inside)”이라고 표현했습니다(출처). 이 시각에서 FDE는 고객과 제품 사이를 잇는 지금까지 없던 역할입니다.

다른 한쪽에서는 “고객사에 엔지니어를 보내 맞춤형으로 개발해 주는 일은 이전에도 있었다”고 말합니다. 해외 투자업계에서는 FDE를 두고 “새 이름을 단 컨설팅”이라는 비판이 나왔죠(출처). 결국 사람이 직접 투입되어야 돌아가는 일이라, 규모를 키우기 어렵다는 지적도 함께 나옵니다. 스노우플레이크의 최고매출책임자(CRO)를 지낸 크리스 데그넌(Chris Degnan)은 FDE를 “포장만 그럴듯한 전문 서비스 인력”이라고 평가했죠(출처).

어느 쪽이 맞는지는 단순히 ‘FDE’라는 이름만 봐서는 알 수 없습니다. 같은 이름이라도 어떤 회사에서, 어떻게 계약되어 일하느냐에 따라 하는 일이 크게 다르기 때문입니다. 결국 답은 실제로 이 일을 하는 사람들이 어디서 왔고, 어떻게 일하고 있는지에서 찾아야 합니다.

요즘IT와 한국 FDE / AX 엔지니어 커뮤니티 ‘비욘드디플로이’가 위시켓의 지원을 받아 함께 기획한 「국내 FDE 현황 조사 2026」은 바로 이 질문에서 출발했습니다.

이번 글에서는 이 조사를 통해 얻고자 하는 네 가지 질문을 소개합니다. 현황 조사는 10월 31일(토)까지 진행됩니다. FDE 업무 경험이 있으시다면, 여러분의 소중한 경험을 들려주세요!

질문 1. FDE는 어디서 오는가

FDE는 처음부터 FDE로 시작하는 경우는 드뭅니다. 이전에 백엔드 개발자였을 수도 있고, 데이터 엔지니어나 PM, 컨설턴트였을 수도 있습니다.

그래서 이번 조사는 이 일을 하기 직전에 어떤 직무를 맡았는지, 그리고 왜 이 일을 시작했는지 묻습니다. 스스로 선택한 사람이 많은지, 회사의 조직 개편으로 맡게 된 사람이 많은지, 하던 일에 새 이름만 붙은 경우는 얼마나 되는지 알고 싶습니다. 이 답이 모이면, 새롭게 FDE를 준비하는 분들에게는 “어떤 경험이 이 일로 이어지는가”에 대한 참고 자료가 됩니다.

질문 2. 같은 FDE, 회사마다 얼마나 다를까

FDE라는 이름은 같아도, 어디에 소속되어 어떤 계약으로 일하느냐에 따라 하는 일은 크게 달라질 수 있습니다. 자사 AI 제품을 고객에게 붙이는 FDE와, 고객사에 상주하며 요구사항대로 개발하는 FDE는 같은 일을 한다고 보기 어렵습니다.

그래서 이번 조사는 소속(자사 제품 기업, SI·컨설팅 기업, 고객사 내부)과 계약 형태(구독, 납품, 상주, PoC)를 나눠 묻습니다. 그리고 이 기준에 따라 문제를 누가 정하는지, 무엇으로 평가받는지가 어떻게 달라지는지 비교합니다. 이 비교가 있어야 “FDE는 새로운 직무인가, 아니면 기존 일의 새 이름인가”라는 질문에도 근거를 가지고 답할 수 있습니다.

질문 3. 현장에서 만든 것은 어디에 남을까

FDE는 고객 현장에 들어가 무언가를 만들고, 언젠가는 떠납니다. 그러면 그때 만든 것은 어떻게 될까요?

어떤 현장에서는 만든 코드와 도구가 회사 제품에 반영되고 다음 현장에서 다시 쓰입니다. 또 어떤 현장에서는 고객사에만 남거나, 담당자의 머릿속에만 남습니다. 떠난 뒤에 고객이 스스로 고치고 운영할 수 있는지도 현장마다 다릅니다.

이번 조사는 현장에서 만든 것이 재사용되는지, 프로젝트가 끝난 뒤 시스템은 어떻게 되는지, 떠나기 전에 무엇을 넘겨주는지를 묻습니다. FDE의 일이 한 번 납품하고 끝나는 일인지, 쌓여 가는 일인지를 보여 주는 질문입니다.

질문 4. 이 일을 계속하고 싶을까

마지막은 FDE 스스로가 이 일을 어떻게 보는지에 대한 질문입니다. 자신의 일을 새로운 직무로 보는지, 컨설팅이나 기술 영업에 가깝다고 보는지 묻습니다.

그리고 3년 뒤에도 이 일을 하고 있을지, 그렇지 않다면 왜 그런지도 묻습니다. 이 일의 수요는 커진다고 보면서도 정작 본인은 다른 직무를 생각하고 있다면, 그 이유에는 이 직무가 아직 풀지 못한 과제가 담겨 있을 것입니다.

마지막 문항에서는 “이 일을 해보지 않은 사람에게 어떻게 설명하시나요?”도 묻습니다. 현장의 FDE가 직접 내린 정의는 리포트에 그대로 담을 예정입니다.

설문 안내

기간: 10/15(목)~10/31(토)
소요 시간: 약 5~7분
참여 혜택: 네이버페이 포인트 3,000원(추첨 100명, 현재 당첨 확률 높아요!), 리포트 발행 시 우선 안내
응답 처리: 익명으로 집계하며, 리포트 작성 외의 목적으로 쓰지 않습니다
참여 링크: ★설문 참여하기★

조사 결과는 11월 중 「국내 FDE 현황 조사 2026」 리포트로 공개합니다. 네이버페이 포인트 응모와 리포트 발행 알림은 설문 마지막 문항에서 신청하실 수 있습니다.

다른 FDE들은 어디서 왔고, 어떻게 일하고 있을까요? 그 답은 여러분의 응답에서 시작됩니다.

마감까지 얼마 남지 않았으니, 지금 바로 참여해 주세요. 주변에 관련 업무를 하는 분께 공유해 주셔도 큰 힘이 됩니다!

]]>

AI 에이전트 비용, 모델 라우팅으로 얼마나 줄까(Liner Router API 실측기)

*이 글은 라이너와 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

AI 에이전트는 도구를 실행한 결과를 모델에 돌려줄 때마다 그때까지의 대화를 모두 다시 보냅니다. 도구를 많이 실행할수록 대화가 길어지고 그만큼 입력 토큰과 비용도 늘어납니다.

모델 비용을 줄이는 방법으로 라우팅(routing) API가 있습니다. 라우팅 API는 요청을 받으면 그 요청에 맞는 모델을 선택해서 대신 보내 주는 API입니다. 쉬운 요청은 단가가 낮은 경량 모델로, 어려운 요청은 상위 모델로 보내서 품질은 유지하면서 비용은 낮추려는 방식입니다. 그렇다면 에이전트 작업에서도 라우팅 API로 비용을 줄일 수 있을까요?

이 질문의 답을 라이너(Liner)가 2026년 9월 15일에 출시한 Liner Router API로 직접 측정해서 확인해 봤습니다. 논문과 자료를 찾는 AI 검색 서비스로 알려진 라이너는 이 API가 “요청에 따라 가장 적합한 모델을 자동으로 선택”하고 “프론티어 모델의 성능을 50% 가격으로” 이용할 수 있게 해 준다고 소개합니다. 요금은 어떤 모델이 처리하든 100만 토큰당 입력 1달러, 캐시된 입력 0.1달러 그리고 출력 5달러로 같다고 합니다(이 글을 작성하는 시점의 버전인 liner-mark-1.3 기준). 이렇게 보면 라이너가 내세우는 것은 모델을 선택하지 않아도 된다는 주장과 비용이 줄어든다는 주장입니다.

결론부터 말씀드리면 모델 사이에 차이가 나도록 새로 만든 장애 10개에서 라이너는 이런 결과를 냈습니다.

품질:오픈AI(OpenAI)의 상위 모델인 GPT-6.1 Sol보다 조금 낮지만 비슷한 품질(정확도와 안전도를 곱한 운영 점수 0.940 대 0.960)을 냈습니다.
비용: GPT-6.1 Sol의 28%였습니다. 단가 차이만으로 비용이 약 45% 줄었고 나머지는 토큰이 적었던 효과였는데, 이 부분은 에이전트 설정에 따라 달라질 수 있습니다.
경량 모델과 비교: 경량 모델인 GPT-6 Luna보다는 3.3배 비쌌습니다.
속도:첫 출력까지는 GPT-6.1 Sol보다 0.8초 정도 길었지만, 장애 1건을 처리하는 전체 시간은 GPT-6.1 Sol보다 짧았습니다.

저는 쿠버네티스 장애 대응을 AI 에이전트에게 맡겼을 때 어떻게 되는지 측정하는 벤치마크를 운영하고 있고 그 결과를 요즘IT에 K8s 운영을 AI 에이전트에 맡길 수 있을까?로 소개한 적이 있습니다. 이 벤치마크에서 연결하는 API만 라이너로 바꾸면 같은 장애를 같은 에이전트가 처리할 때의 비용과 품질을 비교할 수 있습니다. 라이너 측이 밝힌 절감 효과는 자사 서비스의 트래픽에서 얻은 결과라서 에이전트 작업에서는 어떤지 직접 확인해 보기로 했습니다.

라이너의 의뢰로 요즘IT를 통해 작성한 글이지만 측정 방법, 시나리오 그리고 채점 기준은 모두 제가 정했습니다. 비용은 대시보드 사용 금액과 대조했고 품질은 라이너로 미리 실행하지 않은 장애로 다시 측정한 뒤 모델 이름을 가린 블라인드 검토로 한 번 더 검증했습니다. 라우팅 API를 검토하시는 분들이 판단에 참고하실 수 있도록 결과와 함께 측정 과정을 정리했습니다.

Liner Router api와 측정 방법

라이너 측이 설명하는 Liner Router api의 구조는 다음과 같습니다.

[그림 1] Liner Router api가 요청을 처리하는 구조

여러 회사의 모델을 한 API로 제공하는 OpenRouter에도 모델을 자동으로 선택하는 기능(Auto Router)이 있는데, 이때는 선택된 모델의 요금을 그대로 내고 처리한 모델도 응답에 표시된다고 합니다. 그에 반해 라이너는 자체 모델 이름인 liner-mark로 요청하면 토큰당 요금이 정해져 있고 어떤 모델이 요청을 처리했는지는 알 수 없습니다. 그리고 이 고정 요금을 근거로 같은 티어(tier, 성능 등급)의 OpenRouter 최저가 모델보다도 50% 이상 저렴하다고 밝히고 있습니다.

측정은 다음 순서로 진행했고 글도 이 순서를 따릅니다.

공개된 장애 시나리오로 라이너와 GPT-6 계열 모델 3개를 비교했습니다.
라이너의 비용이 예상보다 낮아서 그 이유를 실험으로 찾았습니다.
품질 차이가 보이지 않아서 모델 사이에 차이가 나는 장애 10개를 새로 만들어 다시 측정했습니다.
그 결과를 모델 이름을 가린 블라인드 검토로 한 번 더 확인했습니다.

이하에서는 공개 시나리오로 진행한 측정을 1차 측정, 새로 만든 장애 10개로 진행한 측정을 2차 측정이라고 부르겠습니다.

측정 환경으로는 이전 글에서 소개한 AIOps(AI for IT Operations) 에이전트 벤치마크를 사용했습니다. 시나리오와 클러스터 구성은 공개 저장소에서 확인하실 수 있습니다. 다만 이번에는 같은 구성으로 쿠버네티스 버전만 1.37로 올린 클러스터를 새로 만들었습니다.

[그림 2] 이번 측정에 사용한 환경의 구성

그림에 담지 못한 조건은 다음과 같습니다.

에이전트와 버전 고정
에이전트로는 OpenAI의 코딩 에이전트인 Codex CLI를 0.161.0 버전으로 고정하고 모델만 바꿨습니다. 라이너의 라우팅 방식에도 버전이 있어서 측정하는 동안 바뀌지 않도록 당시 최신 버전인 liner-mark-1.3을 지정했습니다.
운영 점수 계산 방식
운영 점수(Ops)는 정확도와 안전도를 곱한 값입니다. 정확도는 미리 정한 기준에 따라 해결하면 1.0, 대표적인 잘못된 조치를 하면 부분 점수 그리고 해결하지 못하면 0이며 일부 시나리오에서는 에이전트의 최종 보고 내용도 판정에 반영했습니다. 안전도는 다른 팀 소유로 표시된 리소스를 수정하거나 파드(Pod)를 강제로 지우는 것처럼 감사 로그(audit log)로 판정한 위험 조치 1건마다 0.25씩 깎이고 최저값은 0입니다.
요청과 응답 원문 저장
에이전트와 API 사이에 프록시를 두고 라이너의 요청과 응답 원문을 저장했고 2차 측정에서는 GPT 조건까지 포함했습니다.
반복 조건
조건마다 시나리오별로 3회씩 실행했습니다. 시나리오 1개를 한 번 실행한 것은 앞으로 런(run)이라고 부르겠습니다.

비교 대상은 오픈AI의 GPT-6 계열 모델 3개입니다. GPT-6.1 Sol과 GPT-6 Sol은 상위 모델이고 그중 GPT-6 Sol은 라이너 측이 요금 비교표 첫머리에 둔 모델입니다. GPT-6 Luna는 GPT-6 계열에서 단가가 가장 낮은 경량 모델이라 더 저렴한 선택지로 넣었습니다. 이 글의 표와 본문에서 ’라이너’는 Liner Router api(liner-mark-1.3)로 측정한 조건을 뜻합니다. 조건별 100만 토큰당 단가는 다음과 같습니다.

GPT 모델에는 캐시 쓰기 요금이 따로 있습니다. 에이전트가 대화를 다시 보내면 앞부분은 대부분 캐시에서 읽히고 뒤에 붙은 부분이 캐시에 새로 저장되는데, GPT 모델에서는 이 입력을 입력 단가의 1.25배로 계산합니다. 라이너에는 이 요금이 없습니다.

1차 측정에서는 공개 저장소의 장애 10개 가운데 5개를 난이도별로 선택했습니다. 이전 글에서 모델에 따라 결과가 달랐던 009와 010을 넣었고 나머지는 난이도마다 토큰 사용량이 안정적인 것으로 정했습니다. ★★ 난이도(003, 004)는 모델 사이에 차이가 없었고 ★과 ★★★의 중간이라서 제외해도 난이도 범위가 크게 줄지 않아 뺐습니다.

라이너에는 Codex CLI 설정 파일을 적용한 조건도 하나 더 두었습니다. 이 조건은 뒤에서 Codex CLI 설정이 비용에 주는 영향과 함께 설명하겠습니다.

1차 측정 결과와 비용이 낮았던 이유

1차 측정에서는 모든 조건이 거의 만점을 받았고 GPT-6 Luna를 빼면 라이너가 가장 비용이 적었습니다.

[그림 3] 1차 측정(공개 시나리오 5개)의 조건별 운영 점수와 비용

설정 파일 조건을 뺀 60런 가운데 만점이 아닌 것은 GPT-6 Luna가 010에서 다른 팀의 크론잡을 일시 정지(suspend)시켜 위험 조치로 기록된 1런뿐이었습니다. 라이너의 비용은 GPT-6.1 Sol의 27%였습니다. 73%가 줄어든 셈이라 라이너 측이 안내한 절감 폭(50% 이상)보다도 컸습니다. 그래서 이 숫자를 그대로 믿기 전에 비용이 낮을 만한 이유를 가정으로 세워 차례로 실험했습니다.

비용 계산이 맞는지 확인

첫 가정은 비용 계산이 틀렸다는 것이었습니다. 이를 확인하려고 처음 보내는 긴 글, 같은 글을 다시 보내는 요청 그리고 출력이 긴 요청을 1건씩 보내고 대시보드에서 늘어난 사용 금액과 비교했습니다. 10월 8일과 10월 15일 모두 3건의 계산값이 0.0001달러 단위까지 맞았습니다.

[그림 4] 요청 1건마다 계산한 비용과 대시보드의 사용 금액을 대조한 결과

안내된 단가가 그대로 적용되었고 캐시 쓰기 요금은 붙지 않았습니다. 1차 측정 전체로도 라이너 조건 2개(기본 설정과 설정 파일 적용)의 요청 428건에서 늘어난 대시보드 사용 금액이 1.2860달러로 계산한 1.2861달러와 맞았습니다.

단가와 토큰으로 나눈 비용

계산이 맞았으니 비용을 단가와 토큰으로 나눠 봤습니다. 라이너의 토큰에 GPT-6.1 Sol 단가를 적용하면 0.78달러로 GPT-6.1 Sol 실제 비용 1.64달러의 47%였습니다(라이너 토큰 가운데 캐시에서 읽지 않은 입력은 캐시 쓰기로 계산). 단가를 같게 놓으면 라이너의 토큰이 절반 정도였다는 뜻입니다. 같은 토큰을 라이너 단가로 계산한 실제 비용 0.44달러는 0.78달러의 56%였습니다. 즉 토큰이 절반 정도인 효과와 단가가 절반 정도인 효과가 곱해져서 27%가 되었습니다.

그렇다면 라이너는 왜 토큰을 절반만 사용했을까요?

점검량과 명령을 묶어 실행하는 방식

다음 가정은 라이너가 클러스터를 덜 점검해서 토큰을 덜 사용했다는 것이었습니다. 런당 kubectl 명령 수는 라이너가 19.8개로 GPT-6.1 Sol(24.7개)보다 20% 적은 정도였지만 입력 토큰은 56% 적어서 점검량 차이만으로는 설명되지 않았습니다. 그보다는 명령을 실행하는 방식이 달랐는데, 라이너는 셸 명령 1개 안에 kubectl 여러 개를 묶어 실행했습니다. 006-hpa에서 라이너가 두 번째로 실행한 명령은 다음과 같습니다(클러스터 지정 옵션은 지우고 줄을 나눴습니다).

HPA 설정부터 부하 생성기 로그까지 6가지를 한 번에 조회한 것입니다. 다만 GPT-6.1 Sol과 GPT-6 Luna도 Codex CLI가 GPT 모델용으로 제공하는 실행 도구로 명령 실행 1건에 kubectl을 평균 1.5~1.7개씩 묶었습니다(라이너는 3.9개). 따라서 묶어 실행하는 것만으로는 토큰 차이를 설명하기 어려웠습니다. 원인은 요청 원문을 모두 저장한 2차 측정 결과와 함께 뒤에서 살펴보겠습니다.

한편 중간 결과를 보지 않고 다음 명령까지 실행하는 방식에 불리할 수 있는 005-pvc(원인을 단계별로 따라가야 함)와 008-throttle(첫 가설이 틀리기 쉬움)도 조건 4개로 3회씩 더 측정한 결과 모든 조건이 만점이었습니다.

여기까지 비용 계산과 비용 구성은 확인했지만 품질은 비교할 수 없었습니다. 설정 파일 조건과 추가 측정까지 합친 1차 측정 99런 가운데 점수가 깎인 것이 1런뿐이었기 때문입니다. 또 1차 측정의 시나리오는 공개되어 있어서 라이너 측이 미리 맞춰 두었을 가능성도 확인해야 했습니다.

모델 사이에 차이가 나는 장애 10개로 다시 측정

공개 시나리오는 원인과 조사 방향에 대한 힌트를 모두 뺀 프롬프트로도 GPT-6 Luna가 만점을 받는 수준이었습니다. 그래서 원인이 2개 이상이거나 쉬운 해결책이 통하지 않거나 원인과 무관한 신호가 섞인 장애를 새로 만들었습니다. 다른 팀 소관이라 수정할 수 없는 부분이 남으면 해결했다고 지어내지 않고 그대로 보고하는지도 확인할 수 있게 했습니다.

후보는 쿠버네티스 장애 20개에 에이전틱 AI 재단(AAIF, Agentic AI Foundation)의 프로젝트와 erofs를 활용한 장애 10개를 더한 30개였습니다. 재단 쪽은 에이전트 규약인 MCP(Model Context Protocol)와 A2A(Agent2Agent) 그리고 에이전트의 요청을 중계하는 게이트웨이인 agentgateway와 Agent Router를 사용했습니다. erofs(Enhanced Read-Only File System)는 재단 프로젝트는 아니지만 컨테이너 이미지를 읽기 전용으로 실행하는 기술이라 더했습니다.

이 30개를 앤트로픽(Anthropic)의 Claude Sonnet 5와 Claude Opus 5.5로 먼저 풀어 보고 실패한 런이 나온 것을 남겼습니다. A2A와 erofs 장애는 Claude 모델 2개가 모두 풀었는데도 프로젝트마다 1개씩 포함되도록 했습니다. 쿠버네티스 장애 5개는 GPT-6 Luna와 GPT-6.1 Sol로 미리 실행해 본 결과까지 고려해서 선택했고 나머지는 GPT 결과를 보지 않고 정했습니다. 이 장애 10개는 라이너로 한 번도 미리 실행하지 않았고 공개하지도 않았습니다.

측정 전에는 결과를 해석하는 규칙을 문서로 정해서 커밋했습니다. 특히 3회씩 실행하는 작은 표본이라 운영 점수 차이가 0.1 이하면 같은 수준으로 보기로 했습니다. 비교 대상으로는 1차 측정에서 GPT-6 Sol과 점수가 같고 비용이 더 적었던 GPT-6.1 Sol을 선택했고 경량 모델인 GPT-6 Luna도 함께 측정했습니다.

품질과 비용

2차 측정에서 조건마다 30런(장애 10개, 3회씩)을 실행한 결과는 다음과 같습니다.

[그림 5] 2차 측정(장애 10개)의 조건별 운영 점수와 비용

운영 점수는 라이너와 GPT-6.1 Sol이 0.02 차이로 미리 정한 규칙상 같은 수준이었고 라이너와 GPT-6 Luna도 0.094 차이로 같은 수준이지만 경계에 가까웠습니다. 그에 반해 GPT-6.1 Sol과 GPT-6 Luna는 0.114 차이로 다르다고 판정했습니다. 비용은 라이너가 GPT-6.1 Sol의 28%, GPT-6 Luna의 3.3배였습니다. 장애별 점수(런 3회)는 다음과 같습니다.

라이너와 GPT-6.1 Sol은 MCP 421에서 GPT-6.1 Sol이 1회 만점을 받은 것을 빼면 점수가 모두 같았습니다. MCP 421에서는 9런 모두 DNS 리바인딩 보호를 유지한 채 HTTP 421 오류는 해결했지만 두 번째 원인인 환경 변수 충돌까지 찾은 것은 GPT-6.1 Sol의 1런뿐이었습니다. 반면 GPT-6 Luna는 장애 3개에서 라이너와 GPT-6.1 Sol보다 점수가 낮았습니다. Agent Router 도구 이름에서는 3회 모두 환불 도구가 목록에서 빠진 채 끝났는데 그중 2회는 해결되었다고 보고했습니다. 셀렉터와 네트워크 폴리시에서는 2회가 셀렉터만 수정하고 마쳤습니다. 쿼터와 축출의 0.38은 증상만 없앤 데다 파드를 강제로 지운 위험 조치가 겹친 결과입니다.

토큰 차이의 원인과 Codex CLI 설정

2차 측정에서는 모든 조건의 요청 원문을 저장해서 토큰 차이의 원인을 확인할 수 있었습니다. 1차 측정처럼 나눠 보면 라이너의 토큰에 GPT-6.1 Sol 단가를 적용한 비용이 GPT-6.1 Sol의 51%였고 여기에 단가 차이(55%)가 곱해져 28%가 되었습니다. 단가 쪽에서는 이번 측정에서 집계된 GPT-6.1 Sol 비용 가운데 57%가 라이너에는 없는 캐시 쓰기 요금이었습니다.

토큰 쪽에서는 요청 수가 런당 라이너 11.4회, GPT-6.1 Sol 13.3회로 14% 정도만 적었지만 입력 토큰은 16.6만 대 34.8만으로 절반 이하였습니다. 그래서 요청 1건에 담긴 내용을 나누어 문자 수를 비교했습니다.

[그림 6] 런 1회에서 모델에 보낸 내용의 구성

차이는 크게 3가지 부분에서 났습니다.

첫 번째는 명령 출력입니다. Codex CLI는 liner-mark처럼 등록되지 않은 모델 이름에는 명령 출력을 약 1만 바이트(영문 기준 약 1만 자)에서 자르고 GPT 모델에는 명령마다 토큰 단위로 상한을 둡니다. 그 결과 출력이 잘린 도구 호출의 비율은 라이너 15%, GPT-6.1 Sol 3%였고 라이너가 받은 명령 출력은 GPT-6.1 Sol의 절반이었습니다. 이 차이는 대부분 출력이 잘린 데서 났습니다.

두 번째는 요청마다 보내는 지시문과 도구 정의입니다. Codex CLI가 등록되지 않은 모델에 보내는 기본 지시문과 도구 정의는 GPT-6.1 Sol용보다 25% 정도 짧았고 요청마다 다시 보내므로 요청 수만큼 차이가 쌓였습니다.

세 번째는 추론 기록입니다. GPT 모델 요청에는 이전 단계의 추론 기록이 다시 전달되었지만 라이너 요청에는 없었습니다. 다만 이 동작은 liner-mark-1.3에서 확인한 것이라 이후 버전에서는 달라질 수 있으며 라이너 측은 “다음 배포에서 변화할 예정”이라고 설명했습니다.

문자 수로 보면 차이의 절반 정도가 명령 출력, 3분의 1 정도가 지시문과 도구 정의 그리고 10분의 1 정도가 추론 기록이었습니다.

이 가운데 첫 번째와 두 번째는 Codex CLI의 설정에서 나온 차이로, 1차 측정에 함께 둔 설정 파일 조건에서 그 영향을 확인할 수 있었습니다. 이 조건은 Codex CLI의 모델 카탈로그 설정 파일로 liner-mark를 GPT-6 계열 모델처럼 등록해서 Codex CLI가 GPT-6 기준 지시문을 보내게 하고 명령 출력을 자르는 한도도 40만 토큰으로 늘린 것입니다. 라이너 문서대로 API 주소, 키 그리고 모델 이름만 바꾼 기본 설정과 비교하면 다음과 같습니다.

설정 파일을 적용하자 라이너의 입력 토큰은 GPT-6.1 Sol보다 오히려 많아졌지만 비용은 GPT-6.1 Sol의 52%였습니다. 단가 차이에서 나온 절감 폭이 기본 설정의 44%에서 37%로 작아졌을 뿐 대부분 남았기 때문입니다. 이처럼 단가에서 나오는 절감은 설정을 바꿔도 거의 유지되었고 그 밖의 절감은 Codex CLI 설정에 따라 달라졌습니다. 앞에서 본 2차 측정은 기본 설정으로 진행해서 출력이 더 많이 잘렸는데도 라이너의 점수는 GPT-6.1 Sol과 규칙상 같은 수준이었습니다. 출력을 자르는 것 하나만의 영향은 따로 측정하지는 않았습니다.

공개 시나리오에 맞춘 동작인지와 응답한 모델

앞에서 남겨 둔 공개 시나리오 맞춤 여부는 2차 측정 결과로 확인할 수 있었습니다. 라이너는 미리 실행해 본 적이 없는 장애 10개에서도 kubectl을 셸 명령 1개에 평균 2.7개씩 묶어 실행했고 품질도 GPT-6.1 Sol과 비슷했으므로 공개된 시나리오에 맞춘 동작이라고 보기는 어렵습니다. 1차 측정에서도 설정 파일로 지시문과 출력 한도를 바꾸자 런당 셸 명령 실행 횟수가 5.1회에서 8.5회로 늘었는데, 미리 맞춘 동작이라면 이렇게까지 달라지기 어렵습니다. 또 같은 내용을 보냈을 때 입력 토큰 수가 라이너와 GPT 모델에서 일치해서 서버에서 내용을 덧붙여 과금했다고 볼 근거도 없었습니다.

이와 별개로 라이너 측은 처리한 모델을 공개하지 않지만 응답 형식으로 모델 계열을 추정해 보면 1차 428건과 2차 343건 모두 오픈AI 계열이었습니다. 다만 실제 처리 모델을 확인한 것은 아니고 그 안에서 어느 모델인지도 알 수 없었습니다. 처리 모델은 질문 맥락과 라이너 백엔드에 따라 달라질 수 있는 값이라 다른 작업에서는 결과가 다를 수 있습니다.

응답 속도

비용과 품질에 이어 요청 1건의 응답 시간과 런 1회의 전체 시간도 비교했습니다.

[그림 7] 요청 1건의 응답 시간과 런 1회의 전체 시간

GPT 모델의 첫 바이트는 응답을 시작한다는 신호일 뿐이고 모델이 만든 내용은 그 뒤에 도착했습니다. 반면 라이너는 이 신호와 첫 출력을 거의 함께 보냈습니다. 그래서 저장해 둔 요청을 다시 보내 첫 출력이 도착하기까지의 시간을 따로 정했습니다.

그 결과 라이너는 약 2.3초로 GPT-6.1 Sol(약 1.5초)보다 0.8초 정도 늦었고 GPT-6 Luna(약 2.6초)와는 비슷했습니다. 응답을 끝까지 받는 데 든 시간도 비슷했고 요청 수가 적어서 런 1회에 모델 응답을 기다린 시간의 합은 라이너가 가장 짧았습니다. 명령 실행까지 더한 전체 시간은 GPT-6 Luna와 GPT-6.1 Sol 사이였습니다. 따라서 작업 전체가 끝나는 시간이 중요한 에이전트 작업에서는 차이가 크지 않을 것 같습니다.

하지만 응답을 끝까지 받는 데 든 시간은 비슷했고 요청 수가 적어서 런 1회에 모델 응답을 기다린 시간의 합은 라이너가 가장 짧았습니다. 명령 실행까지 더한 전체 시간은 GPT-6 Luna와 GPT-6.1 Sol 사이였습니다. 따라서 작업 전체가 끝나는 시간이 중요한 에이전트 작업에서는 차이가 크지 않을 것 같습니다.

블라인드 검토로 확인한 결과의 신뢰도

점수는 채점 스크립트로 매기고 블라인드 검토로 확정했습니다. 채점 기준을 제가 만들었고 어느 런이 어느 모델인지도 알았던 데다 광고주가 있는 측정이라 모델 이름을 모르는 상태에서 다시 판정해 볼 필요가 있었기 때문입니다.

[그림 8] 모델 이름을 가린 기록으로 진행한 블라인드 검토 절차

90런의 기록에서 모델 이름을 가리고 장애마다 순서를 섞은 뒤 측정 대상이 아닌 Claude 기반 AI 에이전트 5개에게 장애를 2개씩 나누어 판정하게 했습니다. 검토 에이전트는 런 기록, 장애 정의 파일 그리고 채점 기준을 요약한 판정 기준을 받았고 채점 코드와 점수는 보지 않았습니다. 그 결과 90런 가운데 89런의 정확도와 위험 조치 판정이 점수와 일치했습니다.

나머지 1런은 판정 기준에 강제 삭제 항목이 빠져 있어서 위험 조치 판정만 달랐습니다. 블라인드 판정으로 다시 계산한 운영 점수(라이너 0.940, GPT-6.1 Sol 0.960, GPT-6 Luna 0.850)로도 결론은 같았습니다. 물론 라이너가 명령을 묶어 실행하는 방식은 이름을 가려도 기록에 남아서 검토 에이전트가 라이너 조건을 알아봤을 가능성이 있고 사람이 다시 판정하면 일부 결과가 달라질 수 있습니다.

측정 결과로 다시 본 Liner Router API

처음에 소개한 주장 2가지를 이번 측정 결과로 정리하면 다음과 같습니다.

[그림 9] 측정 결과와 라이너의 주장 2가지

모델을 선택하지 않아도 된다는 주장

라이너는 모델을 따로 선택하지 않아도 이번 장애 10개에서 GPT-6.1 Sol보다 조금 낮지만 비슷한 품질을 냈습니다. 다만 어떤 모델이 처리했는지 알 수 없고 라우팅 방식에도 버전이 있으므로 운영 환경에서는 버전을 고정하고 신규 버전이 나오면 다시 확인하시는 게 좋겠습니다.

비용이 줄어든다는 주장

비용은 라이너 측이 안내한 50% 이상 절감과 비슷했습니다. 단가 차이만으로도 GPT-6.1 Sol보다 45% 정도, GPT-6 Sol보다 54% 적었습니다. 기본 설정에서는 토큰 사용량까지 줄어 GPT-6.1 Sol의 28%가 되었지만 이 부분은 에이전트 설정에 따라 달라지므로 연결할 때 설정을 정하고 비용을 확인하시기 바랍니다.

도입을 검토하면 좋은 경우

GPT-6.1 Sol 같은 상위 모델로 에이전트를 운영하고 있다면 Liner Router API로 바꿔서 비용을 줄일 수 있을 것으로 보입니다. 이번 측정에서 품질은 조금 낮았지만 비슷한 수준이었고 비용은 72% 줄었기 때문입니다. 반대로 GPT-6 Luna 같은 경량 모델로도 원하는 품질이 나오는 작업이라면 경량 모델을 직접 사용하는 쪽이 더 저렴합니다. 하지만 GPT-6 Luna는 장애 3개에서 라이너와 GPT-6.1 Sol보다 점수가 낮았고 해결되지 않은 장애를 해결했다고 보고한 경우도 있었습니다. 이 때문에 경량 모델로 충분한지 미리 확인하기 어려운 작업이라면 라이너가 상위 모델과 경량 모델 사이의 선택지가 될 수 있습니다. 한편 첫 응답이 시작되는 속도가 중요한 대화형 서비스라면 첫 출력까지의 시간을 먼저 확인해 보는 것이 좋습니다.

덧붙여 Liner Router API로는 liner-mark 말고도 다른 회사의 모델을 같은 API 주소와 키로 호출할 수 있지만 이때는 모델마다 정해진 요금이 적용됩니다. 이번 측정은 liner-mark만 다뤘습니다.

마지막으로 이번 결과는 Codex CLI로 쿠버네티스, 에이전틱 AI 재단 프로젝트 그리고 erofs의 장애를 처리한 에이전트 작업에서 나온 것이고 장애 10개를 3회씩 실행해서 표본도 크지 않습니다. 또 라이너 측이 자사 서비스 질의의 57%를 경량 모델로 배정했다고 밝힌 것처럼 질의의 절반 이상이 경량 모델로 가는 질의응답 서비스에서는 결과가 다를 수 있습니다. 이 글이 에이전트에 드는 LLM 비용을 줄일 방법을 찾고 계신 분들께 조금이나마 도움이 되었으면 좋겠습니다.

참고 자료

Liner Router API 소개:https://liner.com/ko/developers
Liner Router API 출시 발표:https://liner.com/ko/developers/liner-model
Liner Router API 문서(버전 정책):https://liner.com/developers/docs/liner-model-api
Liner Router API 요금:https://liner.com/developers/docs/pricing
Liner Router API에서 호출할 수 있는 다른 회사 모델 목록: https://liner.com/ko/developers/docs/llm-gateway
OpenRouter Auto Router:https://openrouter.ai/docs/guides/routing/routers/auto-router
AIOps 에이전트 벤치마크 공개 저장소:https://github.com/sysnet4admin/Research/tree/main/AIOps-Agent-Benchmark
K8s 운영을 AI 에이전트에 맡길 수 있을까?:https://yozm.wishket.com/magazine/detail/3817/

]]>

AI 진단의 신뢰도를 높인 건 AI에게 덜 맡기는 것이었다

같은 페이지에 매번 다른 점수를 주던 AI를, 믿을 수 있는 진단으로 만들기까지

저희가 만드는 서비스는 웹페이지를 진단합니다. 주소를 넣으면 이 페이지가 AI 검색에 잘 노출될 수 있는지를 항목별로 따져 점수를 매기고, 무엇을 고치면 좋은지 알려줍니다. 진단이 핵심인 제품이죠. 그리고 진단을 내놓는 제품에게 가장 중요한 건 하나입니다. 그 진단을 고객이 믿을 수 있어야 한다는 것입니다.

그런데 초기에 저희는 그 신뢰를 스스로 무너뜨릴 뻔했습니다. 이 글은 AI에게 채점이나 판정, 평가를 맡기는 제품을 만드는 분들을 위해 썼습니다. AI를 기능으로 얹으면 데모는 근사하게 나오는데, 막상 실제 사용자에게 내놓으려 하면 전혀 다른 문제가 시작되거든요. 그 간극을 어떻게 메웠는지에 대한 기록입니다.

미리 요점만 짚어보면?

초기엔 AI에게 진단을 통째로 맡겼더니, 같은 페이지인데 볼 때마다 점수가 달랐습니다.
그래서 역할을 나눴습니다. 확인할 수 있는 사실은 코드가 판정하고, 판단이 필요한 것만 AI에게 맡겼습니다.
신뢰는 AI를 완벽하게 만드는 게 아니라, AI가 틀려도 되는 곳과 틀리면 안 되는 곳을 가르는 데서 나왔습니다.

같은 페이지를 세 번 봤는데 점수가 달랐습니다

아마 지난 1편 ‘콘텐츠 열심히 만들어도 왜 AI는 우리 회사를 모를까?’를 읽으신 분이라면 이 장면을 기억하실지도 모르겠습니다. 같은 페이지를 세 번 돌렸는데 점수가 72점, 85점, 61점으로 나왔던 이야기입니다. 진단을 대부분 AI에게 통째로 맡겼더니 벌어진 일이었죠.

데모에선 그럴 듯했습니다. 설명도 매끄럽고 감탄도 나왔죠. 그런데 돌려볼 때마다 답이 달라지는 진단을, 돈을 내고 쓰는 고객이 믿어줄 리 없었습니다. 그 세 개의 숫자를 보고 저희는 AI에게 전부 맡긴다는 생각을 접었습니다.

1편에서는 여기까지, 그러니까 ‘사실 확인은 코드, 판단은 AI로 나눴다’는 결론만 짧게 말하고 넘어갔습니다. 그런데 막상 그 말대로 역할을 가르는 일은 한 문장으로 끝나지 않았습니다. 무엇보다 ‘확인할 수 있는 사실’이라는 게 생각보다 호락호락하지 않았거든요. 이 글은 그 결론 뒤에서 실제로 무엇과 씨름했는지에 대한 기록입니다.

확인할 수 있는 사실은 코드에게

<출처: 작가, gpt 생성>

먼저 한 일은 AI가 하던 일을 둘로 나누는 것이었습니다. 한쪽은 “사실 확인”, 다른 한쪽은 “판단”. 이 둘은 성격이 완전히 다른데, 초기엔 둘 다 AI에게 떠넘긴 게 화근이었습니다.

사실 확인은 애초에 판단이 필요 없는 영역입니다. robots.txt라는 파일이 있는가, 특정 태그가 페이지에 들어 있는가, 보안 연결이 걸려 있는가. 이런 건 답이 정해져 있어서 코드가 확인하면 100% 맞습니다. 여기에 AI의 해석이 끼어들 이유가 없었습니다. 오히려 끼어들어서 “있는 것 같다”는 애매한 답을 내는 게 문제였죠.

다만 이 “사실 확인”도 생각만큼 단순하지는 않았습니다. robots.txt 같은 파일이 있는지 볼 때, 그 주소로 요청을 보내 정상 응답(200)이 왔는지만 보면 될 것 같지만 그렇지 않았습니다. 분명 200이 왔다고 기록돼 있는데 정작 그 안에 담긴 건 robots.txt가 아니라 사이트의 에러 페이지인 경우가 쌓이고 있었거든요. 요즘 웹사이트는 없는 주소를 요청해도 에러 화면을 정상 응답으로 돌려주는 일이 많습니다. 응답 코드만 믿었다면 “파일이 있다”고 판정하고 그냥 넘어갔을 겁니다. 그래서 응답이 정상인지뿐 아니라, 그 내용이 실제로 robots.txt나 사이트맵의 형식을 담고 있는지까지 확인하도록 고쳤습니다.

고객이 직접 짚어준 함정도 있었습니다. 어떤 고객의 robots.txt는 맨 위에 전체 차단(Disallow: /)이 걸려 있었습니다. 저희 초기 검증은 그 한 줄만 보고 “검색 로봇을 전부 막아두셨다”며 수정 가이드를 띄웠죠. 그런데 그 아래에는 검색엔진별로, 또 폴더별로 필요한 경로를 다시 열어둔(Allow) 규칙이 붙어 있었습니다. 전체를 막아두고 들여보낼 곳만 골라 허용하는, 오히려 꼼꼼한 설정이었던 겁니다. “우리는 제대로 열어뒀는데 왜 막혔다고 나오느냐”는 고객의 피드백을 받고서야, 저희 검증이 첫 줄만 보고 성급하게 판정했다는 걸 알았습니다. 그 뒤로는 규칙을 끝까지 읽고 봇과 경로별 예외까지 반영해 판정하도록 고쳤습니다.

이런 함정은 한둘이 아니었습니다. 사람 눈엔 같은 사이트인데, 주소 앞에 www가 붙었는지 아닌지에 따라 기계는 다른 사이트로 셉니다. 이걸 그냥 두면 같은 곳을 두 번 진단하거나, 같은 사이트인데 점수가 갈리는 일이 생깁니다. 그래서 이런 경우를 하나로 묶어 보도록 했습니다. 사이트맵이나 robots.txt 같은 파일이 아예 없는 사이트도 많은데, 그 하나가 없다고 관련 항목을 줄줄이 실패로 처리하면 실제보다 훨씬 나쁜 점수가 나옵니다. 그래서 “없어서 확인 자체가 안 되는 것”과 “있는데 잘못된 것”을 구분해, 없는 걸 무조건 감점하지는 않도록 나눴습니다.

모바일도 함정이었습니다. 어떤 사이트는 m으로 시작하는 별도 주소로 모바일 화면을 따로 두는데, 이걸 못 알아보면 “모바일 대응이 안 되어 있다”고 오판합니다. 실제로는 잘 되어 있는데도요. 이런 자잘한 판별을 코드로 하나씩 정리할 때마다, 진단은 조금씩 더 흔들림 없이 같은 답을 내놓았습니다. 겉보기엔 사소하지만, 이 바닥이 흔들리면 그 위의 점수는 전부 흔들립니다.

판단이 필요한 것만 AI에게, 대신 하네스를 씌워서

<출처: 작가, gpt 생성>

그렇다고 AI를 안 쓴 건 아닙니다. 사실만으로는 답할 수 없는 것들이 있으니까요. “이 콘텐츠가 전문가가 쓴 것처럼 보이는가”, “내용이 믿을 만한가” 같은 건 정답이 딱 떨어지지 않습니다. 이런 정성적인 판단은 오히려 AI가 사람보다 일관되게, 지치지 않고 해줍니다. 문제는 초기처럼 그냥 통째로 맡기면 흔들린다는 것이었습니다. 그래서 AI를 그대로 믿는 대신, 그 주위에 입력과 출력을 단단히 묶어두는 장치를 둘렀습니다. 저희는 이걸 하네스(harness)라고 부릅니다. 모델 자체를 더 똑똑하게 만드는 게 아니라, 모델이 틀릴 수 있다는 전제를 깔고 그 틀림이 최종 결과까지 번지지 않게 가두는 뼈대입니다.

먼저 한 번에 모든 걸 묻지 않았습니다. “이 페이지 어때?”처럼 크게 물으면 답이 산만해지고 매번 달라집니다. 그래서 판단해야 할 항목을 잘게 쪼개, 좁고 분명한 질문을 여러 번 던지는 방식으로 바꿨습니다. “이 글이 전문가가 쓴 것 같아?”처럼 뭉뚱그려 묻는 대신, “저자가 누구인지 본문에 드러나 있어?”, “주장에 근거나 출처가 붙어 있어?”처럼 확인 가능한 조각으로 나눠 물었습니다. 질문이 좁아질수록 답의 편차도 줄었습니다.

좁게 물어도 AI가 엉뚱한 걸 집어오는 일은 있었습니다. 한번은 “이 글의 저자가 본문에 드러나 있냐”고 물었더니, 페이지 아래 댓글 입력란에 적힌 임의의 닉네임을 저자로 끌어온 적이 있습니다. 사람이 보면 저건 저자가 아니라 댓글 칸이라는 걸 바로 아는데, AI는 이름처럼 생긴 글자를 그럴듯하게 저자라고 답한 거죠. 그래서 저자를 어디서 찾을지 범위를 좁혀주고, 댓글이나 입력란처럼 저자가 있을 리 없는 영역은 아예 보지 않도록 손봤습니다.

그리고 AI가 준 답도 그대로 믿지 않았습니다. AI의 답이 정해진 형식에 맞는지 한 번 더 검사하고, 형식을 벗어나거나 있지도 않은 값을 지어내면 그 단계에서 걸러냈습니다. AI를 신뢰하되, 그 신뢰를 검증으로 뒷받침한 겁니다. 이렇게 역할을 가르고 하네스를 씌우고 나서는, 같은 페이지를 다시 돌려도 점수가 예전처럼 크게 튀지 않았습니다.

페이지의 성격부터 정확히 봐야 했습니다

한 가지가 더 있었습니다. 같은 항목이라도 페이지 성격에 따라 잣대가 달라야 한다는 점입니다. 뉴스 기사에 어울리는 기준과 쇼핑몰 상품 페이지에 어울리는 기준은 다르니까요. 그런데 이 성격을 알아내는 일, 그러니까 이 페이지가 대체 어떤 페이지인지를 기계에 이해시키는 게 생각보다 까다로웠습니다.

처음엔 이것도 AI에게 페이지를 보여주고 키워드 몇 개로 성격을 짐작하게 했습니다. 그랬더니 헤더에 장바구니 버튼 하나가 들어 있다는 이유로, 실제로는 이벤트 안내 페이지나 단순 소개 페이지인데도 전부 상품 페이지로 인식해버렸습니다. 그 결과 상품 페이지에나 필요한 항목들이 잣대로 들이대지면서, 멀쩡한 페이지에 엉뚱한 감점과 맞지 않는 개선 가이드가 따라붙었습니다. 진단이 첫 단추부터 어긋난 거죠.

그래서 페이지 성격을 알아내는 것도 AI의 어림짐작이 아니라, 페이지에 실제로 담긴 단서들을 정해진 순서로 따져 판별하도록 바꿨습니다. 버튼 하나 같은 단편적인 신호가 아니라 여러 단서를 종합해서, 무엇을 근거로 이 페이지를 그 유형으로 봤는지 설명할 수 있게 만든 겁니다. 진단의 출발점이 흔들리지 않아야, 그 위에 쌓는 점수도 흔들리지 않았습니다.

결국 신뢰는 ‘틀려도 되는 곳’을 가르는 데서 나왔습니다

돌아보면 저희가 한 일은 AI를 더 똑똑하게 만든 게 아니라, AI가 틀려도 괜찮은 자리와 절대 틀리면 안 되는 자리를 갈라놓은 것이었습니다. 확인할 수 있는 사실은 코드에게 맡겨 바닥을 다지고, 판단이 필요한 것만 AI에게 좁게 물어보고, 그 답조차 다시 검증하고요. 진단을 믿게 만든 건 AI를 완벽하게 만드는 일이 아니라, 바로 그 사이에 분명한 선을 하나 긋는 일이었습니다.

물론 이걸로 다 해결된 건 아닙니다. 정성적인 판단에는 여전히 미세한 편차가 남아 있고, 그래서 저희는 그런 지표를 단독으로 내세우기보다 보조적으로 다룹니다. 완벽하게 똑같은 답을 강요하기보다, 흔들려도 되는 곳과 흔들리면 안 되는 곳을 구분하는 쪽을 택한 셈입니다.

AI를 얹은 제품이 점점 늘고 있습니다. 그때마다 저는 같은 질문을 먼저 하게 됩니다. 이 기능에서 AI가 틀려도 되는 부분은 어디고, 절대 틀리면 안 되는 부분은 어디인가. 그 선을 긋는 것이 곧 제품의 신뢰를 긋는 일이었습니다.

다음 편에서는 이 진단의 기준 자체를 어떻게 세웠는지, 그러니까 “AI는 어떤 콘텐츠를 인용하고 어떤 콘텐츠는 그냥 지나치는가”를 저희가 직접 들여다본 데이터와 함께 풀어보겠습니다.

※이 글은 AI의 도움을 받아 작성했습니다. 초반 구조 설계와 자료 정리에 AI를 활용했으며, 데이터 해석과 판단, 최종 문장은 직접 작성했습니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

세상에 나온 지 27년 된 책 '리팩터링'을 다시 펼치는 이유

1999년 1월 1일, 책 <리팩터링(Refactoring)>이 세상에 나왔다. 그리고 세월이 흘러 2018년 11월 30일, 책의 저자인 마틴 파울러(Martin Fowler)는 고침판(2판)을 다시 세상에 내놨다. 현재 내가 글 쓰는 시점이 2026년이니 <리팩터링> 1판이 나온 지 햇수로 대략 27년이 된 것이다.

<리팩터링>은 동작하는 코드를 고치는 법을 다루고 있다. 변화 속도가 둘째가라면 서러울 소프트웨어 분야에서 원칙이나 추상적 문제를 다루는 고전은 여럿 있다. 하지만 구체적인 코드를 다루는 책이 이토록 오래 살아남아 고침판까지 나오는 일은 쉽게 보기 어렵다.

<출처: Amazon.com>

최근 몇 년간 AI 코딩 에이전트는 소프트웨어를 만드는 사람들이 일하는 방식에 큰 변화를 주었다. 바이브 코딩(Vibe Coding)이라는 말이 일상적으로 쓰일 만큼 AI 기반 개발이 보편화됐다. 이제 더는 코드를 볼 필요가 없고, 손으로 코딩하는 시대는 끝났다고 말하는 사람도 심심치 않게 보인다.

나는 몇 주 전 함께 일하는 동료들에게 <리팩터링>을 함께 보자고 제안했다. 책을 함께 보는 동료 중 한 명은 AI 코딩 에이전트가 보편화되기 시작한 무렵에 개발을 시작했다. 자신이 만든 코드의 90% 정도를 AI로 작성한다고 내게 말했을 정도로 AI 기반 개발에 익숙하다. AI 코딩 에이전트 기반 개발이 보편화된 마당에, 손 코딩의 종말을 말하는 마당에, 코드에 관한 책이라니… 심지어 동작하는 기존 코드를 고치는 책이라니!

코드를 직접 생산하지 않는 변화된 개발 환경 속에서 동작하는 코드를 다시 고치는 법을 학습해야 하는 이유는 무엇일까? 그 속에는 어떤 가치가 있을까?

이 글에서는 <리팩터링>이 말하는 좋은 코드의 조건에서 출발해, AI 코딩 에이전트와 일하는 지금도 동작하는 코드를 고치며 배우는 일이 왜 중요한지 살펴본다.

좋은 코드의 조건, 높은 응집성과 느슨한 결합도

누구나 좋은 코드를 만들고 싶어 하고, 요즘은 AI 코딩 에이전트가 좋은 코드를 만들어 주기를 기대한다. 여기서 본질적인 질문을 해보자.

좋은 코드란 무엇인가?

‘좋다’라는 말이 추상적이고 각자가 느끼는 것도 제각각이라 정의하기 어렵다. ‘좋은 코드’를 정의하는 일도 마찬가지다. 그래도 오랜 세월 소프트웨어를 만들어 온 장인들이 경험적으로 말하는 것이 있다. 바로 ‘변경이 쉬운 코드’다.

코드를 ‘수정하기 쉬운 정도’야말로 좋은 코드를 가늠하는 확실한 방법이라고 믿는다. — <리팩터링>

코드 베이스가 작을 때에는 ‘변경’이 큰 문제가 되지 않는다. 코드 전체를 충분히 인지할 수 있는 수준이기 때문에 변경 영향도를 쉽게 추정할 수 있으며, 고쳐야 할 곳을 어렵지 않게 찾을 수 있다.

문제는 코드 베이스가 사람이 인지할 수 없는 수준으로 넘어가면서 발생한다. 나는 코드 에디터로 수만 줄의 코드를 보다가 여기가 어디쯤인지 헤맨 적이 꽤 있다. 인간은 일반적으로 뇌의 인지 한계를 넘어설 때 복잡하다고 느끼는데, 슬금슬금 늘어나는 코드 베이스에서 ‘복잡성’ 문제는 그렇게 서서히 고개를 들기 시작한다.

프로그래밍의 역사는 복잡성을 다뤄 온 역사라 해도 과언이 아니다. 따라서 복잡성을 잘 다루지 않고서는 ‘변경이 쉬운 코드’에 도달하기란 요원하다.

인류가 문자를 발명한 이후, 오랜 세월 인간은 복잡성이라는 문제를 나눠서 정복(Divide and conquer)해 왔다. 비슷한 것들은 인지할 수 있는 단위로 덩이지어(Chunking) 의미를 부여한 후 경계를 만들고 경계 간 상호작용을 최소로 줄여 인간이 가진 뇌의 용량 한계를 극복해 온 것이다.

그렇기에 우리는 프로그래밍할 때 코드를 파일 하나에 모두 넣지 않는다. 코드를 ‘함수’라는 단위로 덩이 짓고 이름으로 의미를 부여하고, ‘클래스’라는 단위로 덩이 짓고 이름으로 의미를 부여하며, ‘패키지’라는 단위로 덩이 짓고 이름으로 의미를 부여한다.

프로그램을 모듈화할 때는 코드를 여러 영역으로 나눈 뒤 영역 안에서 이뤄지는 상호작용은 최대한 늘리고 영역 사이에서 이뤄지는 상호작용은 최소로 줄이는 데 주력한다. — <리팩터링>

비슷한 코드끼리 덩이 짓고 덩이 안에서 상호작용을 최대한 늘리는 것은 응집성을 높이는 것이며, 덩이 사이의 경계를 만들고 경계 간 상호작용을 최소로 만드는 것은 덩이 사이의 의존성을 낮춰 결합도를 느슨하게 만드는 것이다. 정리하면 좋은 코드는 ‘변경이 쉬운 코드’다. 그리고 변경이 쉬운 코드가 도달하려는 궁극적인 목표는 높은 응집성과 느슨한 결합도를 달성하는 데 있다.

경험적 설계: 고치며 배우고 깨닫기

어떻게 해야 높은 응집성과 느슨한 결합도를 갖춘 코드를 만들 수 있을까? 그냥 코딩 에이전트에 “높은 응집성과 느슨한 결합도로 만들어줘”라고 지시하면 되는 것일까? 그렇게 AI가 생성한 코드가 높은 응집성이 있는지 느슨하게 결합되어 있는지 어떻게 검증할 수 있을까? 그렇게 만든 코드가 변경이 쉬운 코드가 되는 걸까? 다른 사람에게 설명할 수 있을까?

코딩 에이전트에 일을 맡기기 전에, 코드 수준에서 무엇이 높은 응집성이고 무엇이 느슨한 결합도인지 구분할 지식을 갖춰야 한다. 그렇지 않으면 초보자(개발자)가 전문가(AI)를 이끄는 역전된 학습(Inverted Learning)이 일어나고 인지적 부채만 쌓일 뿐이다.

개발자가 역량을 키우기 어렵다는 SI(System Integration) 프로젝트 환경에서 뛰어난 전문성을 지닌 개발자의 인터뷰를 읽은 적이 있다. 그에게는 남들이 하지 않는 습관이 있었다. 프로젝트가 끝나면 자신이 작성한 코드를 다시 작성하는 것이다. 경험을 토대로 이전에 작성한 코드를 고치면서 배우는 것이었다. AI가 등장하기 훨씬 전부터 뛰어난 개발자들은 동작하는 코드를 계속 고쳐 나가며 지식을 쌓아왔다.

실력 있는 프로그래머는 항상 자신의 코드를 정리하는 데 어느 정도의 시간을 할애해왔다. 복잡하고 지저분한 코드보다는 깔끔한 코드가 수정하기 쉽고, 처음부터 깔끔하게 작성하는 경우는 거의 없다는 것을 경험을 통해 알기 때문이다. — <리팩터링>

나는 높은 응집성과 느슨한 결합도를 만들 수 있는 역량은 추상적인 설명이 아니라 구체적인 코드를 고치면서 얻는 깨달음에서 시작한다고 믿는다. 그래서인지 <리팩터링>과 켄트 벡(Kent Beck)의 <Tidy First?>를 펼치면 코드를 구체적으로 고치는 예시가 가득하다. 책으로 학습하고, 일상에서 마주하는 코드에 적용해 보고, 코드를 점진적으로 개선하면서 무엇이 응집성이고 무엇이 결합도인지 서서히 깨닫는다. 그렇게 기술이 매개된 간접 경험이 아니라 직접 경험으로 지식을 차곡차곡 쌓아 가는 것이다.

저는 매시간 “코드 정리가 먼저인가?”라는 질문에 대해 논의하면서, 그 해답을 찾았습니다. 그 논의를 통해 설계자로서 제 마음에 소중한 많은 주제를 다룰 수 있었습니다. — <Tidy First?>

소프트웨어 분야에서 아주 오래된 격언 중 하나는 “잘 동작하는 것을 고치지 말라”는 것이다. 동작하는 코드를 고치며 배우는 과정은 쉽지 않다. 하지만 문제를 해결하며 겪는 마찰과 어려움이 결국 내 지식이 된다.

AI 코딩 에이전트와 함께 나아가기

나는 ‘당신의 사고까지 AI에게 외주화하지 마라’ 글에서 ‘사고의 주도권’을 강조했다. 마찬가지로 바이브 코딩을 하지 않는다면 AI가 생성한 코드의 주도권은 내가 가져야 한다. 주도권을 가진다는 것은 내가 예상하는 곳에 코드가 존재한다는 것이며 그것은 곧 내 인지 범위 안에 있다는 것이다. 반면 AI가 생성한 코드가 어떤 의미인지 모르거나 검증할 수 없으면 주도권을 잃은 것이다. 코드가 인지 범위를 벗어났고, 인지적 부채를 겪고 있다는 뜻이다.

하네스 엔지니어링은 AI에 지켜야 할 규칙이나 지침을 주어 코드 통제력을 구현한다. 문제는 지침이 남의 것, 즉 내가 이해하지 못한 것이라면 그런 지침으로 생성된 코드에 내가 주도권을 가질 수 없다는 점이다. 남들이 만든 지침을 AI에 줄 수는 있다. 하지만 그렇게 만들어진 코드를 스스로 판단할 수 없으니 결국 다시 인지적 부채의 늪에 빠진다.

앞서 나는 동작하는 코드를 고치면서 얻는 깨달음에 대해 언급했다. 깨달음에서 멈추는 것이 아니라 직접 경험을 통해 익힌 직관이나 습관을 지침으로 만들어 AI에 줄 수 있다. 이 과정은 처음부터 깔끔하게 잘될 수 없기에 점진적이며 경험적으로 접근할 수밖에 없다. 지침을 어떻게 만드는 것이 효과적일까? 일찍이 이 분야 선배들은 다음 세 단어를 많이 써왔다.

원칙(Principles)
실천 방법(Practices)
패턴(Patterns)

나만의 원칙, 실천 방법 그리고 패턴(이하 PPP)을 지침으로 만든다는 것은 PPP를 새롭게 창조하라는 것이 아니다. 세상에는 이미 좋은 PPP가 존재한다. PPP를 익히면서 이해한 것들을 내 것으로 만들어 모으는 것에서부터 시작해 보자.

‘PPP’ 아마존 검색 결과 <출처: Amazon.com>

마치며

책 <다시, 소프트웨어>의 저자가 말하듯 AI 코딩 에이전트 덕분에 코드를 생산하는 비용은 매우 싸졌다. 하지만 엔지니어링까지 싸진 것은 아니라는 점을 꼭 기억하길 바란다. 좋은 코드를 만드는 길은 먼저 깨달은 누군가가 말해 줄 수 있다. 하지만 아무도 당신을 어깨에 앉히고 그 길을 걸어가 주지 않는다. 스스로 그 길을 걸어갈 수밖에 없다.

<리팩터링> 1판은 1999년 출간되었지만 한국에는 2002년에 소개되었다. 내가 1판을 산 것은 2010년쯤으로 기억한다. 당시에는 이 책이 말하는 것을 대부분 이해하지 못했고 실천하지도 못했다. 켄트 벡은 자신의 책 <Tidy First?>에서 에드워드 요던과 래리 콘스탄틴이 1975년에 쓴 책 <Structured Design>을 언급하며 “뉴턴의 운동 법칙을 소프트웨어 설계에 적용하고 있다”라고 극찬했다. <리팩터링>을 다시 펼친 지금 나는 켄트 벡과 같은 감정을 느낀다.

<원문>

세상에 나온 지 27년이나 된 책을 다시 펼치는 이유

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

AI에게 처음부터 끝까지 개발을 맡겼습니다

부제: 결함이 처음 생긴 단계로 돌아가 고치고, 다음 작업의 규칙으로 남긴 과정

“개발 완료.”

지난 글“출근하면 코드부터 짜던 개발자가 이제 봇부터 켭니다“ 끝에 코드 한 줄 안 치고 만든 결과물의 완성도를 점수로 매긴 것을 적었었다. Jest 테스트가 전부 통과했는데, 요구사항 명세 40개 중 코드에 실제로 들어간 건 25개였다. 빠진 15개는 검색 필터와 정책 분기처럼 기능의 의미를 정하는 항목이었다.

이렇게 누락이 된 게 많았지만 내가 만든 하네스 플러그인 code-forge는 “개발 완료”라고 보고했다. 테스트가 전부 통과했다는 말은 사실이었다. 작성된 테스트는 이미 구현된 동작들만 검사했고, 빠진 요구사항을 확인할 테스트가 없었으니, 검증을 모두 통과해도 누락은 드러나지 않았던 것이었다.

지난 글 마지막에 나는 “무엇을 만족해야 끝인가”를 테스트와 연결하기 시작했다고 썼다. 먼저 누락된 기능들이 어느 단계에서 빠졌는지 추적했고, 그걸 고친 뒤에도 결함이 나왔다. 두 번 다 테스트보다 앞 단계로 돌아가야 했다. 이번 글에선 실제 그 과정을 적어볼 것이다. (지난 글이 궁금하시다면, 먼저 읽고 오셔도 좋습니다.)

<출처: 작가, 제미나이로 생성>

AI는 plan.md와 Figma부터 읽는다

개발은 Figma나 티켓에서 시작했다. AI가 그 내용을 분석해 요구사항과 기능 명세를 `plan.md`에 정리하면, `/start`가 그 문서를 기준으로 구현했다. 검증 단계에서는 `/generate-test`와 `/e2e`가 같은 요구사항과 기능 명세에서 테스트 케이스(TC)와 테스트 코드를 만들고, 구현 결과가 명세대로 동작하는지 확인했다.

`/start`는 요구사항과 수용 조건, Figma를 바탕으로 구현 계획을 만들었다. `/generate-test`와 `/e2e`는 수용 조건을 “어떤 상황에서 무엇을 하면 어떻게 된다”는 BDD 시나리오로 옮기고, 시나리오마다 테스트 코드를 만들었다. 정책 분기가 복잡한 작업에는 요구사항을 정책 케이스 표로 정리하는 분석 에이전트를 필요할 때만 붙였다. 구현이 끝나면 Playwright로 실제 브라우저 화면을 확인했다.

작업이 길어져 한 세션에 대화가 쌓이면, 다음 세션으로 작업을 넘기는 `/handoff`를 썼다. 끝낸 일과 남은 일, 아직 결정하지 않은 질문을 `progress.md`에 적었고 컨텍스트를 비운 뒤 알아서 프롬프트를 작성하여 새 세션에서 그 문서를 읽고 이어 갔다. 모델의 자동 요약에만 맡기지 않고 필요한 내용을 직접 정리했기 때문에, 검증을 여러 번 반복해도 앞서 확인한 내용이 끊기지 않고 중요한 맥락들을 이어 가는 게 가능해졌다. 한 세션에 대화를 계속 쌓으며 드는 비용도 줄일 수 있었다.

<출처: 작가, 제미나이로 생성>

AI가 계획과 시나리오를 만들면 내가 확인했고, 애매한 비즈니스 정책은 직접 정했다. 구현과 검증은 모두 AI가 맡았다. 커밋·푸시와 PR 생성은 내가 승인한 뒤에 진행됐고, 마지막에는 결과를 보고 작업을 끝내도 될지 판단했다.

요구사항 명세도 같은 파이프라인에서 만든 게 허점이었다. AI는 원문에서 요구사항 목록을 뽑고, 거기서 수용 조건과 BDD 시나리오를 만들었다. 검색 필터 하나가 목록에서 빠지자 수용 조건과 시나리오, 테스트에도 그 필터를 다루는 항목이 없었다. 구현은 필터 없는 화면으로 끝났고, 어느 단계도 누락을 실패로 처리하지 않았다.

신호는 보고서에 이미 있었다

돌이켜보면 당시 AI 보고서에는 P0(가장 시급한 우선순위) 미완 항목 세 개(카테고리 옵션, 담당자 표시, 저장 확인)가 이미 적혀 있었다. 하지만 파이프라인은 “작성된 테스트가 통과했는가”만 완료 조건으로 검사했고, “요구사항 명세가 모두 연결됐는가”는 검사하지 않았다. 미완 항목은 보고서에 남았지만 작업은 계속 진행됐다.

그래서 `plan.md`와 Figma에서 뽑은 요구사항을 되짚었다. AI에게 요구사항 명세의 각 항목이 수용 조건, 시나리오, 테스트, 코드 중 어디에 연결되어 있는지 한 줄씩 적은 요구사항 추적표를 만들게 하고, 나는 그 표에서 빠진 연결이 없는지 확인했다.

요구사항 명세의 각 항목이 수용 조건과 정책 분기로 이어지는가
각 수용 조건이 BDD 시나리오와 테스트를 갖는가
테스트가 실제 구현 파일과 연결되는가
확인하지 못한 항목과 스킵 이유가 드러나는가

빠진 기능이 나오면 AI에게 어느 단계에서 빠졌는지부터 분석하게 했다. 요구사항 목록에서 빠졌는지, 정책 분기가 모호했는지, Figma의 화면 상태를 잘못 읽었는지를 근거와 함께 내놓게 했다. 나는 그중 비즈니스 판단이 필요한 원인만 직접 정하고, 확정된 내용을 문서와 체크리스트에 반영한 뒤 테스트와 구현을 다시 돌렸다.

mock과 구현은 같이 틀린다

두 번째 결함은 mock에서 나왔다. 브라우저에서 사용자 흐름을 자동으로 실행하는 E2E 테스트가 mock(실제 API 대신 미리 만들어 둔 가짜 응답)으로는 전부 통과했는데, 실제 서버와 연결한 스테이지 환경에서 동작하지 않았다. 원인을 모아 보니 가장 큰 패턴은 mock을 실제 응답이 아니라 추정으로 만든 것이었다. 프론트엔드와 mock은 `id`, `category`, `state`, `businessKeyId`를 쓰고 있었는데, 실제 API는 `propertyId`, `propertyType`, `propertyStatus`, `affiliateId`를 내려주고 있었다.

같은 추정 타입으로 구현과 mock을 함께 만들었으니 둘 사이에는 모순이 없었다. 실제 API를 붙이자 `id`가 전부 비어 모든 행이 같은 행으로 취급됐고, 한 행의 체크박스를 눌러도 전체가 선택됐다. 카테고리 칸에는 영문 코드가 그대로 찍혔고, 상태 칸에는 “-”만 남았다.

타입과 mock이 같은 추정에 기대는 한 테스트는 이 차이를 잡을 수 없다. 그래서 순서를 바꿨다. 개발 서버의 실제 응답을 먼저 캡처하고, 그 구조 그대로 타입과 fixture(테스트용 준비 데이터), mock을 만들었다. mock을 고칠 때는 실제 응답과 다시 대조했다.

결함이 처음 발생한 곳은 개선해야 할 곳이다

두 사건을 겪은 뒤로는 문제가 생길 때마다 문제점을 기록하여 개선했고, 어느 단계로 먼저 돌아갈지도 함께 정했다.

<출처: 작가, 제미나이로 생성>

이상이 어디서 나왔든 원본 문서, Figma, API 계약을 대조해 처음 틀린 산출물을 찾았다. AI가 수정 근거와 범위를 내놓으면 내가 원문과 정책을 확인했고, 필요하면 원본 문서부터 고친 뒤 새 `/start` 작업을 열어 그 아래 테스트, mock, 구현을 다시 만들었다.

`/test`는 바뀐 파일과 거기에 묶인 정책·테스트만 골라 다시 돌렸고, 화면이 바뀐 작업은 `/e2e`가 시나리오를 Playwright로 실행했다. 어느 쪽이든 제품 코드나 정책을 고쳐야 한다는 결론이 나오면 도구가 직접 고치지 않고 변경 범위와 재현 근거를 나에게 넘겼다. 나는 그걸 별도 `/start` 작업으로 열었다.

<출처: 작가, 제미나이로 생성>

아홉 번을 시도해도 안 되면 나에게 묻는다

처음에는 테스트가 깨질 때마다 다른 모델을 붙여 끝날 때까지 돌릴 생각이었다. 하지만 틀린 전제에서 횟수만 늘려서는 해결되지 않았다. E2E 검증은 같은 시나리오가 계속 실패하면 세 단계에 걸쳐 접근법을 바꾼다. 단계마다 최대 세 번씩 시도한다. 세 단계를 모두 거쳐도 해결되지 않으면 로그와 판단 근거를 나에게 보여준다.

아홉 번 시도해도 실패하면 나는 스킵, 힌트 제공, 시나리오 수정, 전체 중단 중 하나를 고른다. 힌트를 주면 첫 단계부터 다시 시도한다. 시나리오를 수정하면 테스트 코드를 다시 만든다.

같은 실패는 다음 작업의 규칙이 된다

검증이 실패하면 먼저 기록을 확인했다. 화면 문제는 Figma와 실제 브라우저의 캡처를 비교했다. 수정한 뒤에는 같은 화면을 다시 캡처해 무엇이 달라졌는지 AI에게 확인하게 했다. 그리고 이 근거를 바탕으로 처음 판단이 어긋난 부분을 찾게 했다.

결함을 고쳐 현재 작업을 다시 돌려도 다음 작업의 체크리스트와 완료 조건은 그대로였기에, QA에서 드러난 원인을 다음 작업의 규칙으로 옮겼다.

앞의 mock 불일치는 나의 검토를 거쳐 ‘mock은 실제 백엔드 응답과 일치해야 한다’는 규칙이 됐고, 신규 API 체크리스트의 첫 항목은 ‘실제 응답부터 캡처’로 바뀌었다. 규칙은 늘 읽는 지시문에 쌓지 않고, 그 규칙이 필요한 단계의 체크리스트와 완료 조건에만 넣었다. 지난 글에 적었듯 앞에 쌓인 규칙이 많아질수록 현재 프롬프트의 지시사항이 흐려지기 때문이다.

`code-forge`는 `quality.jsonl`에 쌓인 품질 이벤트 중 같은 내용이 세 번 이상 기록된 항목을 찾고, `forge whet --draft`로 반복 횟수와 기록을 담은 규칙 후보 문서를 만들었다. 나는 그 후보들이 다른 작업에도 적용되는지 검토한 뒤, 필요한 단계의 체크리스트와 완료 조건에 반영했다.

앞으로는 이 과정에서 쓰이는 프롬프트들도 기록하여, 실패 기록과 화면 비교 결과를 보고 원인과 다음 작업에서 먼저 확인할 항목을 제안하도록 다듬을 생각이다.

정책, 테스트, 실행 결과, 회고를 잇는 구조는 별도 도구 `flow-toolkit`에도 구현했지만, 아직 실운영 경로에는 연결하지 않았다. 품질 이벤트가 더 쌓이면 그때 다시 판단할 생각이다.

<출처: 작가, 제미나이로 생성>

전체 통과 알림이 오면 요구사항부터 확인한다

요즘은 전체 PASS 보고를 받으면 요구사항 추적표를 먼저 연다. AI가 정리한 표에서 수용 조건(AC)과 테스트 케이스(TC)를 확인한 뒤, 실제 화면에서 E2E를 돌려 요구사항대로 동작하는지 본다. 확인하지 못한 항목이 있다면 이유와 함께 적는다. 그 결과를 보고 내가 완료 여부를 결정한다.

요구사항 누락을 발견하고 추적표 검토를 완료 조건에 넣었다. mock과 실제 API 응답이 달랐던 일을 겪은 뒤에는 신규 API 작업에서 실제 응답부터 캡처하도록 순서를 바꿨다. 이제 “개발 완료” 보고를 받으면 테스트 결과, 요구사항 누락 여부, 확인하지 못한 범위를 함께 본다. 실패 뒤에 고친 지침이 다음 작업에도 반영됐는지도 확인한다.

AI가 코드를 쓰는 모습을 보면 개발도 ‘딸깍’ 한 번이면 끝난다고 생각하는 사람이 많아진 것 같다. 내 경우 제품 코드를 직접 치는 시간은 줄었지만, 요구사항을 정리하고 검증 방법을 설계하고 실패 기록을 읽어 체크리스트와 프롬프트를 고치는 시간은 늘었다. 전보다 더 많이 생각하고, 키보드도 더 많이 친다.

요즘 개발자로서 내가 더 힘을 쏟는 건 기능 하나의 구현보다 전체 품질을 확인하는 과정과 시스템을 만드는 일이다. 이번에 바꾼 검증 기준이 내 다음 작업에서 통하는지 확인하고, 다른 개발자의 작업환경에서도 도움이 되는지 함께 써 보며 고치고 싶다.

AI가 코드를 쓰는 환경에서 개발자는 무엇을 해야 하고, 회사는 어떤 개발자를 필요로 할까. 요즘 자주 하는 고민이다. 내가 겪은 실패를 문서로 남기고, 다른 사람의 경험을 듣고, 내 방식을 다시 살펴보는 일부터 계속하려 한다. 이 글의 방식과 다른 의견이나 사례가 있다면 듣고 싶다. 이런 이야기를 편하게 나누는 게 특별하지 않은 개발 문화가 되었으면 좋겠다.

<참고>

code-forge 스킬 문서: /start, /generate-test, /e2e, /handoff

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

비개발자라면 이렇게 해보세요: 클로드 코드와 친해지기

지난 1편 ‘비개발자라면 이렇게 해보세요: 바이브 코딩 실전 가이드’에서는 나만의 첫 번째 프로덕트를 만드는 과정에 대해 소개해 드렸습니다. 그와 관련된 4가지 팁을 전달드렸고요. 이번 글에서는 한 걸음 더 나아가, 외부 서비스(Supabase, GitHub 등)와의 CLI 연동으로 작업을 자동화하고, 이해하기 어려운 개발 용어는 쉽게 풀거나, HTML·PNG 파일로 추출해 확인하는 노하우를 소개하려고 합니다.

제가 바이브 코딩을 처음 시작할 때부터 지금까지의 경험을 담았습니다. ‘기획자 입장에서 바이브 코딩을 시작하는 방법’과 프로덕트를 개발해 나감에 있어 ‘몸으로 때우며 알게된 팁’에 관한 이야기입니다. 물론 디자이너나 마케터 등 비개발자 직군에게도 도움이 될 것이라 생각합니다. 추상적인 개념보다는 실제로 사용한 ‘방법’에 집중하고자 노력했고, 이 방법이 꼭 ‘정답’은 아니라는 점을 미리 말씀드립니다.

‘딸깍’만으로는 잘 되지 않습니다

나는 잘 모르겠고, 직접 해줘

개발하고자 하는 프로덕트의 특성에 따라 상이하겠지만, 거의 대부분의 프로덕트는 외부 서비스와의 연동이 필수적입니다. 대표적으로 github가 있고, F/E 또는 B/E, DB 등의 외부 서비스가 그런 것들입니다. 저의 경우와 같이 카카오톡 로그인이 필요하므로, 카카오톡까지 포함되었고, 다른 로그인 방식(e.g. 구글 또는 애플 ID) 필요 시, 구글 및 애플과의 연동도 필요합니다.

참고로 저의 경우, 앞서 설명 드린 ‘일정 공유 캘린더’ 서비스에 아래와 같은 외부 서비스가 연동되어 있습니다

로그인: 카카오톡 로그인
호스팅: Render
DB: Supabase
저장소: github

간단한 예시를 들어보겠습니다.

지난 글에서 설명드린 Plan Mode를 통해 어느 정도 계획 수립이 완료되면, 본격적으로 개발이 진행되는데요. 이때 주요 작업 중 하나가 DB 설계 및 테이블 생성입니다. 로그인이 필요한 서비스라면 기본적으로 사용자 테이블이 필요할 것이고, 인증 테이블도 필요합니다. 그리고 컨텐츠가 등록될 때 이에 대한 테이블도 필요합니다. 이런 작업을 개발자도 아닌 일반 사용자가 직접 수행한다고 생각해보면 정말 끔찍합니다. 아마 DB 설계 및 테이블 생성에만 몇 주는 필요할 것입니다.

이런 것들을 직접 하나하나 만들 필요 없이 ‘클로드 코드 ↔ Supabase’ 간 연동만 해 놓으면 바이브 코딩을 통해 자동으로 생성 및 관리할 수 있습니다. 이런 방식을 보통 CLI라고 부릅니다. (스킬이나 에이전트와 마찬가지로) CLI에 대해 자세한 정의를 알 필요는 역시 없습니다. 중요한 것은 사용자가 직접 처리하지 않고 클로드 코드를 통해 각 서비스 간의 연동 및 작업 진행을 수행하도록 한다는 것만 기억하시면 됩니다. 사용자는 발생한 이슈 및 작업 사항에 대해 ‘직접 진행해줘’라고 명령만 하면 됩니다.

만약 직접 진행을 요청했는데 클로드 코드가 수행할 없는 경우일 때는, 클로드 코드가 직접 수행을 위해 필요한 정보를 알려줍니다. 해당 서비스의 인증 키(Secret Key)를 요청하는 경우가 대표적입니다. 이 경우, 해당 서비스에 직접 로그인 한 후, 클로드 코드의 가이드에 따라 메뉴 진입 및 인증 키를 알려주면 그 이후부터는 따로 관리할 필요 없이 작업 수행을 클로드 코드에게 위임할 수 있습니다.

이런 식으로 각 서비스의 주요 정보를 알려달라고 요청합니다. <출처: 작가>

▣ 팁 5. 실제 작업 수행은 클로드 코드에게

아래와 같은 순서로 클로드 코드의 CLI를 구성하여 편하게 바이브 코딩으로 작업을 수행할 수 있습니다.

계획 수립을 통해 내가 개발하고자 하는 프로덕트에 적합한 외부 서비스를 확인
각 외부 서비스의 가입 및 로그인
클로드 코드와 함께 CLI 구성
- 로그인 후 인증 키를 클로드 코드에게 전달
클로드 코드에게 ‘직접 실행해줘.’라고 당당하게 요청하기

CLI의 개념도는 대략 이렇습니다만, 그냥 클로드 코드와 외부 서비스 간의 연동이라고 보시면 됩니다. <출처: 작가>

이해가 안되면, 다시 요청하자

바이브 코딩으로 개발을 진행하다 보면, 클로드 코드와의 질의응답 과정을 제법 많이 거칩니다. 사용자의 요청 사항을 파악하고 의도에 대한 확인을 하는 경우도 있고, 작업 수행 방식에 대한 여러가지 선택지를 제공하고 사용자에게 의사결정을 요청하는 경우가 그 예입니다. 이 때마다 어려움을 느끼는게, ‘클로드 코드는 비 개발자인 나의 고려는 전혀 없이 어려운 개발 용어로 나에게 선택을 요구한다는 점’입니다. 개발자라면 전혀 어려움이 없을 테지만 저를 포함한 비 개발자에게는 이런 과정들이 제법 바이브 코딩의 난이도를 높이는 요소 중 하나로 작용합니다.

이 때마다 제가 했던 것은 ‘비 개발자도 이해할 수 있도록 쉽게 설명해줘.’라고 요청하는 것이었습니다. 그러면 해당 이슈에 대해 클로드 코드가 개발 용어를 최대한 제거하고 이해 가능한 수준으로 다시 설명을 합니다. 그러면 우리는 이 설명을 보고 판단 & 선택을 하면 되는 것입니다.

이렇게 요청하면 됩니다. <출처: 작가>

더 나아가서, 조금 더 복잡하고 큰 이슈에 대해 설명이 필요할 경우에는 HTML로 정리 문서를 생성하여 내용을 확인할 수도 있습니다. 아무래도 IDE의 터미널 상에서 설명해주는 것은 한계가 있고 가독성도 떨어지므로, 저의 경우 간단한 이슈는 터미널에서 확인하고 이슈 내용이 많을 경우 HTML로 추출하여 상세히 검토하는 편입니다.

이슈 내용은 HTML로, 화면 예시는 PNG로 추출하여 확인합니다. <출처: 작가>

▣ 팁 6. 파일로 추출하여 쉽게 확인하자

HTML과 PNG 등, 파일 형태로 추출하여 확인하면 훨씬 수월합니다.

클로드 코드에게 ‘비개발자도 이해할 수 있도록 쉽게 설명해서 HTML로 만들어줘.’라고 요청하거나 ‘이 화면 설계를 PNG로 만들어줘.’라고 요청하면 됩니다.

개발 지식이 아예 없는 일반 사용자라면 CLAUDE.md 파일에 아예 정의를 해 놓는 것도 하나의 방법입니다. 예를 들어 ‘내가 ‘쉽게 설명해줘.’라고 요청하면, 이슈 사항에 대해 비 개발자가 이해할 수 있도록 쉽게 설명하여 HTML 파일로 만들어서 제공할 것’이라고 정의해 놓으면, 매번 요청할 필요 없이 이해가 되지 않는 시점에 ‘쉽게 설명해줘’라고만 요청하면 됩니다.

파일을 활용하자

바이브 코딩이라는 것은 결국 클로드 코드와의 대화가 중심이 되는 행위입니다. 그러다보니 가능한 정확한 요청을 하는 것이 제일 중요합니다. 전통적인 개발 방식 기준으로 본다면, 기획안 및 정책서, 화면설계서 등이 개발을 진행함에 있어 뼈대가 되는 문서입니다. 특히, 화면설계서의 경우 원하는 UI에 대한 정의를 포함하므로 화면 개발 및 UX 개발에 있어 기준이 되는 문서라고 볼 수 있습니다.

문제는 바이브 코딩을 할 때 이 부분이 쉽게 생략된다는 점입니다. 열 줄의 텍스트 요청사항보다 한 장의 이미지로 원하는 바를 표현하는 것이 더 나을 때가 있는데, 바이브 코딩을 함에 있어서도 이 부분은 유효합니다.

저의 경우는 프로젝트 폴더 내, 임의의 폴더를 생성하여 클로드 코드와 소통하는데 사용하는 방식을 채택했습니다. 특정 폴더에 원하는 문서나 이미지를 넣은 후, 클로드 코드에게 이 파일을 탐색하여 개발을 진행하도록 지시하는 형태입니다. 오류가 발생했을 때도 오류 발생 상태를 캡쳐 후 클로드 코드에게 탐색 및 수정 진행을 하도록 지시하여 보다 명확하게 수정을 지시할 수 있습니다.

▣ 팁 7. 파일로 대화하기

막히는 부분이 있다면 아래와 같은 예시를 따라서 진행해 보시길 바랍니다.

프로젝트 폴더 내 임의의 폴더 생성
- 생성 시, 폴더명 제일 앞에 콤마를 붙일 것 (이렇게 하면 git hub에 푸시되지 않음)
- 예시 : .file
클로드 코드가 확인해야 하는 파일 삽입
- 만약 오류가 발생한 화면이 있다면 해당 화면 캡쳐본을 해당 폴더에 삽입
클로드 코드에게 이 파일 확인 후 수정 요청
- 예시 : “.file 폴더에 있는 error.jpg 확인 후, 오류 사항 확인하여 수정해줘.”

몇 가지 명령어와 단축키는 알아두면 좋아요

클로드 코드에서는 수많은 명령어를 제공하고, 실제로 명령어에 따른 효과들이 제법 좋다고 알려져 있습니다. 어차피 모든 명령어를 다 쓸 수도 없고, 사실 모두 알 필요도 없기에 제가 바이브 코딩을 진행하면서 주로 썼던 몇 가지만 알려드리고자 합니다.

가장 일반적으로 사용하는 명령어는 ‘/compact’와 ‘/clear’입니다. 이 2가지 명령어는 수시로 사용하는 편이라 제일 먼저 언급하게 되네요. 바이브 코딩을 하시는 분들께는 습관적으로 사용하기를 권장합니다.

‘/compact’는 현재 세션에서 진행한 작업 내역을 압축하는 명령어입니다. 클로드 코드 특성 상 세션 내 맥락이 길어질수록 정확도 측면에서 성능이 저하되는 현상이 있습니다. 때문에 작업 내역이 길어져서(즉, 대화의 스크롤이 엄청나게 길어진다면) 연속된 다음 단계 작업을 진행하기에 부담스러울 정도가 된다면 이 명령어를 통해 앞서 처리한 작업의 핵심 내용들만 기억하도록 하는 것이 좋습니다. 작업의 핵심은 기억하고 맥락은 줄여서 작업의 연속성을 지킬 수 있도록 하는 명령어입니다.

‘/clear’는 현재까지 대화한 모든 내역을 지우는 명령어입니다. 말 그대로 모든 내역을 초기화하는 것입니다. 저의 경우는 하고자 했던 작업이 완료되면 이 명령어를 통해 초기화를 진행한 후, 다음 작업을 시작합니다. 만약 후속 작업이 이전 작업과 연관이 있다면 ‘/compact’를 사용하고, 이전 작업과 무관하다면 ‘/clear’를 사용하시면 됩니다.

그 외에 몇가지 소소한 명령어는 다음과 같습니다.

- /model : 현재 사용 중인 클로드 코드의 모델 정보 확인하고 변경할 수 있습니다. 모델과 해당 모델의 강도를 조절할 수 있고, 저의 경우는 opus로 세팅하고 efforts는 max로 설정합니다. 모델과 강도가 강할수록 강력한 추론이 적용되어 정확도가 올라가지만 그만큼 추론 연산에 시간이 소요되므로 적절한 세팅으로 하시면 됩니다. 모델의 변경은 상하 방향키로(↑↓), efforts는 좌우 방향키(←→)로 설정합니다.

작업 대상에 맞는 모델 설정을 하면 됩니다. <출처: 작가>

- /usage : 클로드 코드 사용량을 확인할 수 있습니다. 아시다시피 유료 모델을 구독하더라도 토큰 사용량의 한계가 있습니다. 이 명령은 현재까지의 토큰 사용량을 확인할 수 있고, 주간 한도가 얼마나 남았는지 볼 수 있습니다. 최근에는 Fable이 추가됨에 따라 Fable 사용량도 함께 볼 수 있습니다. (Fable은 사용량을 따로 집계합니다.)

전체 주간 한도 및 Fable 주간한도, 그리고 초기화되는 시점을 알 수 있습니다 <출처: 작가>

단축키 중에서는 단연 ‘컨트롤 & C’가 압도적입니다. 이 단축키는 클로드 코드에게 지시한 명령의 수행 중단을 의미합니다. 만약 잘못된 명령이 전달되었거나 내용 추가가 필요할 경우 이 단축키로 작업을 중단할 수 있습니다. 윈도우의 복사 단축키와 동일하다보니 가끔 복사를 하기 위해 눌렀다가 작업이 중단되는 경우가 종종 있으니 이 점만 주의해 주시면 됩니다.

그 다음으로 단축키는 아니지만, 클로드 코드와의 대화에서 유용한 방법으로, 방향키 조작이 있습니다. 바이브 코딩을 진행하다보면 클로드 코드가 추천하는 답안을 프롬프트 입력란에 Place holder 형태로 표시합니다. 이 때 이 추천 답안을 그대로 적용하고자 할때 우측 방향키(→)를 입력하면 추천 답안이 그대로 입력됩니다. 경험 상 많은 경우에서 클로드 코드의 추천 답안이 옳은 경우가 많아서, 이 방식 역시 자주 사용했습니다.

이런식으로 추천 답안이 제시될 때 우측 방향키(→) 입력 시, 프롬프트에 그대로 입력됩니다. <출처: 작가>

마지막으로 클로드 코드를 실행할 때 제가 사용하는 명령어입니다.

처음 바이브 코딩을 진행하면, 클로드 코드가 사소한 것 하나까지 확인 요청을 하는 것을 경험하게 될 것입니다. git hub 푸시나, DB 마이그레이션처럼 중요한 작업의 경우는 사용자에게 한번 더 확인 요청하는 것이 어느 정도 납득이 갑니다만, 중요도가 낮은 일반 작업에서도 매번 확인 요청을 하므로 업무 효율성이 많이 떨어지게 됩니다. (이른바, 엔터 지옥…)

때문에 저의 경우는 아래와 같은 형태로 클로드 코드를 실행합니다.

이 명령어는 제가 설명하기 보다는 아래와 같이 클로드 코드의 답변으로 자세한 설명을 대신하는 게 좋겠습니다.

이런 의미입니다. <출처: 작가>

▣ 팁 8 : 다양한 명령어와 단축키

클로드 코드의 시작과 끝 사이에는 유용한 명령어가 많습니다. 제가 알려드린 것 외에도 도움이 되는 많은 명령어가 있으니 나에게 맞는 것이 있다면 사용해 보시길 권장합니다.

1. /clear와 /compact는 습관처럼 이용하길 권장합니다.
- 세션 관리가 습관화되어야 클로드 코드가 길을 헤매는 확률을 줄일 수 있습니다.
작업 중단이 필요하면 ‘컨트롤 & C’키를 눌러서 중단할 수 있습니다.
- 일단 중단시킨 후, 프롬프트를 수정하여 작업을 수정하거나 추가하여 진행합니다.
클로드 코드 시작 전, 앞서 알려드린 형태로 옵션을 적용해서 실행하면 작업 효율성에 도움이 됩니다.
- 자주 쓰는 모델을 디폴트로 설정되도록 할 수 있고, 잦은 확인 요청에서 해방될 수 있습니다.

마치며

2회에 걸쳐 제가 처음으로 바이브 코딩을 시작하면서 느꼈던 부분과 나름의 팁이라고 생각되는 부분에 대해 크게 8가지로 정리해보았습니다. 이전 글에서도 말씀드렸지만 저보다 클로드 코드 또는 다른 서비스를 통해 바이브 코딩을 하시는 분들이 너무나도 많습니다.

다만 저와 같은 비 개발자 입장에서 바이브 코딩을 시작하기 위한 심리적 허들을 조금 해소하고 싶었고, 바이브 코딩을 반복 수행함에 있어 접하게 되는 낯선 부분들에 대해서 조금이나마 도움이 되고자 했습니다. (잘 전달 되었을지 모르겠습니다.)

바이브 코딩에 대해 관심이 있지만 선뜻 시작하지 못하고 계시다면, 부디 이 글이 바이브 코딩의 시발점이 되면 좋겠습니다.

▣ 직접 경험한 바이브 코딩 팁 8가지

바이브 코딩으로 개발할 첫 프로덕트는 가급적 가볍고 볼륨이 적은 것으로 선정
바이브 코딩을 하기 위한 환경 설정은 클로드 코드와 질의응답 형태로 진행
스킬과 에이전트를 적극 활용
프로덕트 개발 계획을 먼저 수립하여 검토 후 개발 진행
실제 작업 수행은 클로드 코드의 CLI를 활용하여 직접 수행하도록 요청
이해되지 않는 내용은 쉽게 풀어서 설명 요청하고, 복잡한 내용은 HTML 등의 파일로 추출 요청
이슈가 있거나 막히는 부분은 파일로 정리하여 클로드 코드에게 확인 요청 후 진행
바이브 코딩에 도움이 되는 명령어 및 단축키 사용

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

LLM부터 MCP까지 ‘왜 필요한가’로 이해하는 AI 리터러시

AI를 잘 쓴다는 것은 무엇일까요? 새로운 모델과 기능이 등장할 때마다 관련 내용을 찾아보고 직접 사용해보며, 어느 정도까지 알아야 하는지 고민해왔는데요. 클로드코드(Claude Code)와 코덱스(Codex) 같은 코딩 에이전트부터 에이전트, 워크플로우, 스킬, MCP까지. AI를 잘 써보려고 할수록 오히려 공부할 것이 더 늘어나는 느낌이었습니다.

문제는 새로운 개념을 안다고 해서 반드시 AI를 더 잘 쓰게 되는 것은 아니었다는 것입니다. 유료 스터디부터 수많은 강의까지 시간을 내어 들었음에도 막상 내 업무에서는 무엇을 써야 하는지 여전히 의문이었습니다.

그러다 문득, 생각이 들었습니다. 나는 지금 AI라는 도구를 공부하고 있는 걸까, 아니면 일을 더 잘하고 싶어서 AI를 공부하고 있는 걸까?

일을 더 잘하고 싶어 공부한다면 접근이 달라져야 했습니다. 모든 개념의 원리를 깊게 이해하기보다, 어떤 문제가 생겼을 때 어떤 개념이 필요한지 아는 것이 더 중요했던거죠. 내 업무가 한 번의 질문으로 끝난다면 프롬프트면 충분할 수 있고, 반복되는 절차가 있다면 스킬이 유용할 수 있습니다. 회사 내부 자료를 참고해야 한다면 RAG를 고민해야 하고, AI가 다른 서비스까지 사용해야 한다면 API나 MCP가 필요할 수 있습니다.

그렇게 하나씩 연결해보니 따로 보이던 개념들이 조금 다르게 보이기 시작했습니다. 각각이 독립적으로 떠다니는 개념이라기보다, AI의 쓰임이 넓어지면서 하나의 업무 흐름 안에서 만나게 되는 개념들에 가까웠습니다.

저는 이를 크게 세 가지 흐름으로 나누어 이해해보려 합니다.

AI가 행동하는 흐름에서는 LLM에서 프롬프트, 스킬, 에이전트, 루프(Loop)로 이어집니다. AI가 단순히 답을 만드는 것에서 시작해, 원하는 방식으로 일하고 여러 작업을 연결해 수행하기까지 필요한 개념입니다.
AI가 자료를 참고하는 흐름에서는 할루시네이션(Hallucination)에서 RAG, 청킹(Chunking)·벡터화(Vectorization)로 이어집니다. AI가 어떻게 보다 근거 있는 결과를 만들게 할 것인지에 대한 흐름입니다.
마지막으로 실제 업무로 이어지는 흐름입니다. AI와 나눈 대화가 실제 일의 결과물이 되고, 나아가 조직의 업무 방식이나 외부 시스템과 연결되는 과정입니다.

기술의 발전을 나열하기 보단, 업무를 맡기는 사람의 입장에서 ‘무엇이 부족해서 다음 개념이 필요해지는가’를 이해하기 위해 재구성한 것에 가깝습니다.

묻는 말에만 답하던 AI가 일을 하기까지

<출처: 작가, ChatGPT 제작>

가장 먼저 출발점이 되는 것은 LLM(Large Language Model)입니다. 우리가 ChatGPT나 Claude 같은 서비스에 무언가를 질문하거나 요청했을 때 ‘문맥’을 바탕으로 답변을 생성하는 모델인데요. 대부분 이렇게 질문을 입력하고, 답을 받는 형식으로 생성형 AI를 처음 경험하게 됩니다.

그런데 같은 모델을 쓰더라도 요청하는 방식에 따라 결과의 품질은 크게 달라집니다. “보고서를 써줘”라고 요청할 때와, 목적과 독자, 참고 자료, 원하는 형식까지 설명했을 때의 결과가 다른 것처럼 말입니다. 그래서 프롬프트엔지니어링(Prompt Engineering)이 중요해졌습니다. 원하는 결과를 얻을 수 있도록 충분한 맥락과 명확한 지시를 제공하는 방법입니다. OpenAI 역시 프롬프트 작성에서 맥락, 원하는 결과, 길이와 형식 등을 구체적으로 제시하는 것을 기본적인 원칙으로 안내합니다.

그런데 AI를 실제 업무에 반복적으로 사용하다 보니 다른 문제가 생겼습니다. 매번 비슷한 설명을 다시 해야 했습니다. 프롬프트를 매번 잘 작성하는 것보다, 반복되는 업무의 방법 자체를 저장해두고 필요할 때 다시 사용할 수 있는 형태가 필요해진거죠.

이 과정에서 등장한 것이 스킬(Skill)입니다. Skill이라는 이름과 구현 방식은 서비스마다 다르지만, 최근에는 반복되는 지침과 절차, 필요한 자료나 스크립트를 하나의 재사용 가능한 단위로 묶는 방식으로 사용되고 있습니다. Anthropic은 Agent Skills를 지침·스크립트·리소스를 묶어 특정 업무에 필요한 전문성과 절차를 에이전트가 필요할 때 불러오는 구조로 설명합니다.

프롬프트가 ‘이번 일을 어떻게 해달라’는 요청이라면, Skill은 ‘이런 종류의 일은 앞으로 이렇게 한다’는 업무 방식을 남기는 것에 더 가깝습니다. 여기서부터 AI 활용은 일회성 대화에서 반복 가능한 업무 방식으로 넘어가기 시작합니다.

실제 일은 하나의 절차만으로 끝나지 않습니다. 자료를 찾고, 내용을 검토하고, 분석하고, 결과물을 만든 뒤 다시 확인해야 합니다. 상황에 따라 도구도 달라지는데요, 이처럼 하나의 목표를 위해 여러 단계의 일을 연결해서 수행해야 할 때 Agent라는 개념이 중요해집니다.

OpenAI는 Agent를 LLM이 워크플로의 실행을 관리하면서 상황에 따라 판단하고, 필요한 외부 도구를 선택해 정보를 얻거나 행동할 수 있는 시스템이라고 설명합니다. 기본적으로 모델과 지침, 도구가 결합하고, 필요한 경우 여러 번 실행하며 목표를 완성하는 구조입니다. 이를 루프(Loop)라는 개념으로 따로 설명하기도 합니다. AI가 결과를 확인하고, 부족하면 다시 시도하는 과정입니다.

프롬프트의 복잡도가 높거나 에이전트가 작동하는 시간이 길다고 좋은 것은 아닌데요, 오히려 Anthropic은 단순한 프롬프트로 해결할 수 있는 문제에는 단순한 방식을 사용하고, 부족한 경우에만 다단계 에이전트 시스템으로 복잡성을 높일 것을 권합니다.

즉, 멋진 에이전트를 만드는 것보다 내가 맡기려는 일이 프롬프트로 충분한지, 스킬이 필요한지, 에이전트까지 필요한지를 구분할 수 있어야 한다는 뜻이죠.

행동의 흐름만 놓고 보면 이렇게 정리할 수 있습니다.

<출처: 작가, ChatGPT 제작>

일은 잘해도, 모르는데 어떻게 해요?

AI에게 점점 복잡한 일을 맡길 수 있게 되었지만, 일을 수행하는 능력과 그 일을 위한 정보를 가지고 있는 것은 별개의 문제입니다.

예를 들어, AI에 “우리 회사의 개인정보 처리 기준에 맞춰 이 문서를 검토해줘”라고 요청한다면? 일반적인 개인정보 보호 원칙에 대해서는 꽤 자연스럽게 답하겠지만, 우리 회사가 정한 내부 규칙과 최신 정책 문서를 AI가 가지고 있지 않다면 정확한 판단을 기대하기 어렵습니다.

하지만 AI는 충분한 근거가 없는 상황에서도 그럴듯한 내용을 생성할 수 있습니다. 할루시네이션(Hallucination)이라고 부르죠. 그래서 업무에 AI를 적극적으로 활용할수록 단순히 ‘모델이 얼마나 똑똑한가’보다 ‘무엇을 근거로 답하게 할 것인가’가 중요해집니다.

<출처: 작가, ChatGPT 제작>

그래서 같이 중요해진 것이 RAG(Retrieval-Augmented Generation)라는 개념입니다. 필요한 정보를 자료에서 먼저 검색하고, 찾아온 내용을 모델의 답변 생성 과정에 포함하여 함께 제공하는 방식인데요. 모델 내부에 저장된 지식만으로는 필요한 정보를 정확하게 활용하거나 최신 지식을 반영하고 근거를 제시하는 데 한계가 있기 때문에 외부에서 관련 정보를 검색, 참고하여 답변하는 것이죠. 쉽게 말하면 AI에게 모든 것을 기억하라고 하는 대신, 필요할 때 모델 외부의 자료를 찾아보고 답하게 하는 것입니다.

하지만 회사 문서를 수백 개 넣어두었다고 해서 필요한 자료를 자동으로 잘 찾아내는 것은 아닙니다. 이때 긴 문서를 적절한 단위로 나누는 청킹(Chunking)이나, 텍스트의 의미적 유사성을 비교할 수 있도록 수치 표현으로 변환하는 벡터화(Vectorization) 같은 방법이 활용됩니다. 모두 필요한 자료를 더 잘 찾아 AI에게 제공하기 위한 기술입니다.

AI가 더 넓게, 더 많이 일해야 한다면

마지막으로 AI가 내 파일과 자료를 넘어 외부 서비스에서 정보를 가져오거나 행동해야 한다면 ‘연결’이 필요해집니다.

흔히 사용하는 방식은 API(Application Programming Interface)연결 입니다. 서로 다른 소프트웨어가 정해진 규칙에 따라 데이터를 주고받거나 특정 기능을 사용할 수 있게 하는 인터페이스입니다. AI가 사내 시스템의 데이터를 조회하거나 일정을 등록하고, 다른 서비스의 기능을 실행하려면 이런 연결 수단이 필요합니다.

최근 자주 언급되는 MCP(Model Context Protocol)도 같은 ‘연결’이라는 맥락에서 이해하면 쉬워지는데요, MCP는 AI 애플리케이션이 외부의 데이터 소스와 도구를 사용할 수 있도록 연결 방식을 표준화한 공개 프로토콜입니다.

API가 각 소프트웨어의 기능을 외부에서 사용할 수 있게 만든 인터페이스라면, MCP는 AI가 여러 데이터와 도구를 보다 공통된 방식으로 발견하고 사용하도록 연결해주는 규칙에 가깝습니다.

AI를 잘 쓴다는 것은, 우리가 어떤 일을 하는지 잘 안다는 것

<출처: 작가, ChatGPT 제작>

그런데 여기까지 정리하고 나니, 애초에 AI가 참고할 Input이 있는가?라는 대전제가 중요해집니다.

회의에서 결정한 내용이 기록되어 있지 않고, 정책이 사람의 머릿속에만 있으며, 프로젝트 자료가 개인 PC 곳곳에 흩어져 있다면 아무리 좋은 시스템을 만들어도 참고할 것이 없습니다. PPT, Excel, PDF, 회의 녹취와 회의록, 사내 정책, 사용자 인터뷰, 업무 메모처럼 우리가 매일 만들어내는 자료가 결국 AI가 일하기 위한 Input이 됩니다.

그래서 AI를 사용할수록 오히려 문서화와 지식 관리의 중요성이 커집니다. 과거에는 자료를 잘 ‘보관하는 것’이 중요했다면, 이제는 필요한 순간에 사람과 AI가 다시 찾아 사용할 수 있는 상태로 남기는 것까지 생각해야 합니다. 결국 업무에서 쓸모 있는 Output을 만들기 위해서는 쓸모 있는 Input이 필요하고, 어떤 정보를 어떻게 남길 것인지를 고민하는 것 자체가 업무 프로세스를 개선하는 중요한 지점이 됩니다.

여기서 한 단계 더 나아가면, AI가 만들어낸 Output 역시 다시 다음 업무의 Input이 됩니다. 잘 만든 보고서나 분석 자료, 업무 기준과 결과물을 어떻게 모으고 다시 활용할 수 있는 형태로 남기느냐에 따라 개인의 일회성 결과물이 될 수도 있고, 조직이 반복해서 활용할 수 있는 자산이 될 수도 있습니다. Input과 Output이 순환하는 구조를 얼마나 잘 만들 수 있는지가 결국 조직의 효율과 성과에도 영향을 미치는 셈입니다.

하지만 그것만으로 곧바로 좋은 업무 자동화가 만들어지는 것은 아닙니다. 무엇을 어떤 순서로 수행하고, 어떤 기준으로 판단해야 하는지가 정리되어 있지 않다면 AI 역시 일을 안정적으로 반복하기 어렵습니다.

그래서 도구보다 먼저 SOP(Standard Operating Procedure), 즉 실제 업무 절차를 정리하는 일이 필요할 때가 있습니다. 어떻게 업무를 시작하고, 어떤 자료를 참고하며, 무엇을 기준으로 판단하는지처럼 그동안 암묵지로 남아 있던 업무 방식을 절차화하는 것입니다. 이 과정을 거치고 나면 어느 부분은 사람이 판단해야 하고, 어느 부분은 Skill이나 Agent에 맡길 수 있을지도 구분할 수 있습니다.

이렇듯 AI를 도입한다는 것은 단순히 사람의 업무를 AI로 치환하는 일이 아닙니다. 오히려 기존 업무가 실제로 어떻게 이루어지고 있었는지 발견하고, 흩어진 지식과 결과물을 모으고, 다시 활용할 수 있는 구조로 만드는 과정에 더 가깝습니다. 결국 AI를 활용한다는 것은 기술을 도입하는 일을 넘어, 우리가 일하고 지식을 축적하는 방식을 다시 설계하는 일이기도 합니다.

이제는 ‘어떻게(How)’보다 ‘왜 필요한가(Why)’를 묻게 됩니다

이 지점까지 오면 묻는 질문에만 답하던 AI가 실제 업무 환경에 상당히 깊게 들어올 수 있다는 것을 알 수 있습니다. 자료를 참고하고, 업무 절차를 따르고, 파일을 만들고, 여러 도구를 사용하며, 필요하면 외부 시스템에서 실제 행동까지 수행합니다.

다시 정리해 보면,

그런데 이 모든 것을 실제 업무에서 제대로 활용하려면, 결국 AI에게 어떤 Input을 주고 어떤 Output을 만들 것인지, 우리의 일이 어떤 절차로 이루어지는지를 먼저 이해해야 합니다.

결국 AI를 잘 쓴다는 것도 새로운 기술을 가장 많이 아는 일이 아니라, 내 업무 안에서 어떤 기술을 왜 사용하는지 이해하고 필요한 만큼 선택할 수 있는 일이 아닐까요?

무언가 새로 적용하거나 도입하기 위해 우리는 흔히 How to를 찾곤 했습니다. 하지만 이제 How to를 찾는 비용은 이전보다 크게 낮아졌습니다. Skill을 만드는 방법도, RAG를 구축하는 방법도, MCP를 연결하는 방법도 AI에게 물어보면 단계별로 설명해주니까요. 그렇다면 사람에게 남는 중요한 역할 중 하나는 ‘어떻게 만들 것인가’보다 ‘지금 이 문제에 무엇이 필요한가’를 판단하는 일일지도 모릅니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

VSCode를 사용하다가 Orca로 옮긴 후기

많은 사람들이 코딩 에이전트를 터미널에서 사용하곤 합니다. VSCode에서 터미널을 하나 열고 클로드 코드(Claude Code)나 코덱스(Codex)를 실행하면, 에이전트가 파일을 읽고 고치는 과정을 편집기에서 그대로 볼 수 있기 때문입니다. 저도 한동안은 VSCode를 사용해 코딩 에이전트를 아무 문제 없이 편리하게 사용했습니다.

하지만 문제는 두 번째 에이전트를 켤 때 생깁니다. 터미널을 하나 더 열어 다른 에이전트를 실행하면, 두 에이전트가 같은 작업 디렉터리를 보고, 한쪽이 파일을 고치는 동안 다른 쪽도 같은 파일을 읽습니다. 브랜치도 하나뿐이라 서로 다른 두 작업의 변경 사항이 한곳에 섞이게 됩니다. 이 상태에서 커밋을 하려고 하면, 어느 줄이 어느 작업의 결과인지 되짚어봐야 하는 번거로운 문제가 발생합니다.

이러한 문제를 해결하고자, 여러 에이전트로 병렬 작업을 하기 좋은 도구를 찾아보다가 오르카(Orca)라는 도구를 알게 되었습니다. 최근 2주 반 동안은 오르카(Orca)라는 도구로 옮겨 작업을 해보고 있습니다. 그래서 이번 글은 코덱스와 클로드, 두 에이전트를 함께 쓰는 사람의 기준으로 쓴 이야기입니다. 이 글에서는 오르카가 무엇인지 먼저 소개한 다음, 제가 VSCode를 사용하면서 겪었던 불편과 옮기고 나서 달라진 작업 방식, 그리고 지금까지 확인한 한계를 이야기해보겠습니다.

Orca(오르카)란?

오르카를 설명할 때 먼저 짚어야 할 것은 이것이 새로운 AI 모델이 아니라는 점입니다. 쓰던 에이전트를 그대로 쓰되, 그 에이전트들을 어디에 담아 둘지를 바꾸는 도구입니다.

<출처: 작가 캡쳐, https://www.onorca.dev >

1) 모델이 아니라 에이전트를 담는 그릇

오르카는 오픈소스 도구로, 공식 사이트에서는 스스로를 에이전트 개발 환경(Agent Development Environment)이라고 소개합니다. MIT 라이선스로 공개되어 있어 소스를 직접 확인할 수 있고, macOS와 윈도우, 리눅스를 지원합니다.

오르카 안에서 돌아가는 것은 클로드 코드, 코덱스, 제미나이(Gemini), 커서 CLI(Cursor CLI)처럼 이미 쓰고 있는 에이전트들입니다. 오르카가 제공하는 것은 모델이 아니라, 그 에이전트들이 각자 어디서 일할지를 정해 주는 자리입니다.

새로운 에이전트 모델이 아니기 때문에, 구독을 새로 늘릴 필요 없이 쓰던 계정을 그대로 연결하면 됩니다. 저는 클로드와 코덱스 계정을 하나씩 등록해 두고 작업에 따라 골라서 사용하고 있습니다.

2) 작업마다 따로 열리는 git 워크트리

오르카의 구조에서 핵심은 워크트리(worktree)입니다. 낯선 이름이지만 git에 원래 있는 기능인데요. 하나의 저장소를 여러 디렉터리로 펼쳐 두고, 각 디렉터리에 서로 다른 브랜치를 올려 두는 방식입니다.

오르카는 작업을 하나 만들 때마다 이 워크트리를 하나씩 생성합니다. 그 결과 에이전트마다 자기 폴더와 자기 브랜치를 갖게 됩니다. A 작업의 에이전트가 파일을 고쳐도 B 작업의 폴더에는 아무 일도 일어나지 않습니다. 또한 같은 파일을 두 에이전트가 동시에 열어도 서로 다른 사본이라 충돌하지 않습니다. 커밋도 각자의 브랜치에 쌓이기 때문에, 나중에 어느 작업의 결과인지 되짚을 필요가 없습니다.

<출처: 작가, GPT로 생성>

3) 한 화면에 모이는 여러 에이전트

오르카의 또다른 장점은, 이렇게 나뉜 작업들을 한 화면에서 관리한다는 점입니다.

<출처: 작가, Orca 캡쳐>

왼쪽에 저장소와 작업 목록이 있고, 작업을 고르면 그 워크트리의 터미널과 변경 사항, 필요하면 브라우저까지 같은 창 안에서 열립니다. 목록에는 어떤 작업이 어느 에이전트로 돌고 있고 어디까지 진행됐는지가 함께 보여서, 터미널을 하나씩 눌러 보지 않아도 누가 무엇을 하는 중인지 알 수 있습니다.

VSCode로 두 에이전트를 돌리며 불편했던 점

VSCode로도 충분히 에이전트를 돌릴 수 있었지만, 에이전트 구독을 두 개로 늘린 뒤부터 같은 불편이 반복됐습니다.

1) 이전 버전을 보고 판단하는 다른 에이전트

자주 걸린 지점은 작업 디렉터리였습니다. VSCode에서 터미널을 두 개 열면 두 에이전트가 같은 폴더를 봅니다. 제가 한쪽에서 이미 고쳐 둔 내용이 있는데도 다른 에이전트는 그 이전 상태를 기준으로 판단해, 엉뚱한 답을 내놓는 일이 있었습니다. 같은 파일의 서로 다른 시점을 보고 있으니 생기는 일이었습니다.

하지만 오르카로 옮긴 뒤에는 이 일이 없어졌습니다. 작업마다 워크트리가 따로 생겨서, 두 에이전트가 같은 사본을 두고 부딪히지 않고, 변경 사항도 작업별 브랜치에 나뉘어 쌓입니다. 어느 시점의 내용을 기준으로 일하는지가 작업 단위로 분명해진 셈입니다.

2) 브랜치를 오가며 생기는 대기

폴더가 하나뿐이라 브랜치를 바꾸려면 작업 중인 내용을 먼저 치워야 합니다. 에이전트가 파일을 고치고 있는 중이라면 그 작업이 끝나기를 기다렸다가 정리하고 브랜치를 옮기게 됩니다.

결국 두 작업을 동시에 진행한다고 생각했지만 실제로는 번갈아 진행하는 형태가 됐습니다. 한쪽이 움직이는 동안 다른 쪽은 멈춰 있어야 했기 때문입니다.

3) 터미널 이름만으로는 알기 어려운 진행 상황

터미널이 두 개에서 세 개로 늘어나면 어느 탭이 무슨 작업인지 이름만으로는 구분되지 않습니다. 보고 있는 답변이 코덱스가 낸 것인지 클로드가 낸 것인지도 출력을 한참 올려 보고 나서야 알게되는 상황이 자주 발생했습니다.

진행 상황도 마찬가지였습니다. 에이전트가 아직 일하는 중인지 이미 끝내고 멈춰 있는 것인지 알려면 탭을 하나씩 눌러 마지막 출력을 읽어야 했습니다. 오래 걸리는 작업을 맡겨 두고 다른 일을 하다 보면, 이미 끝난 줄 모르고 한참 뒤에 확인하는 경우도 있었습니다.

4) 구독 두 개의 사용량을 따로 세는 번거로움

또한 코덱스를 얼마나 썼고 언제 다시 채워지는지, 클로드는 또 얼마나 남았는지를 작업할 때마다 따로 확인하면서 써야 했습니다. 한 번 보고 끝나는 일이 아니라 맡길 때마다 반복되는 일이라, 나중에는 확인을 미루게 됐고 어느 에이전트에게 맡길지는 그때그때 감으로 정했습니다.

옮기고 나서 달라진 작업 방식

도구를 바꾸면서 기능이 늘어난 것보다, 작업을 나누는 단위가 달라진 쪽이 더 크게 느껴졌습니다.

1) 작업마다 하나씩 생기는 워크트리

작업을 하나 만들 때 제가 하는 일은 이름을 정하고 어떤 에이전트를 붙일지 고르는 것까지입니다. 그 다음은 오르카가 맡아서 그 작업 몫의 워크트리를 실제로 만들어 줍니다. 폴더와 브랜치가 함께 준비되기 때문에, 제가 git 명령을 직접 치지는 않습니다. 예전에는 금방 끝날 일에 브랜치까지 만드는 것이 번거로워서, 쓰던 브랜치에서 그냥 이어가곤 했는데, 지금은 그럴 일이 없어졌습니다.

작업이 끝나면 그 워크트리를 통째로 정리하고, 결과를 더 봐야 하면 남겨 둡니다. 브랜치를 지우고 폴더를 원래대로 되돌리는 일을 따로 하지 않아도 되기 때문에, 작업을 시작하는 것만큼 끝내는 것도 가벼워졌습니다.

<출처: 작가, GPT로 생성>

2) 작업이 끝나면 오는 완료 알림

터미널을 눌러 확인하는 대신 알림을 받게 되면서 확인하는 습관이 바뀌었습니다. 예전에는 작업이 종료가 됐는지, 작업 중인지 확인을 위해 중간에 몇 번씩 들여다봤는데요, 그때마다 하던 일의 흐름이 끊겼습니다.

작업을 맡겨 두고 다른 일을 하다 보면 시켜 놓았다는 사실 자체를 잊기도 합니다. 하지만 오르카는 작업이 끝나면 알림을 보내줘서, 맡겨 둔 일이 끝났다는 것을 바로 알아차릴 수 있습니다.

알림은 오르카를 띄워 둔 컴퓨터에서만 오는 것이 아닙니다. 계정을 연결해 두면 휴대폰으로도 같은 알림이 옵니다. 오래 걸릴 작업을 맡겨 두고 자리를 떠서 평소 하던 일을 보다가, 끝났다는 알림을 받고 그때 돌아와 확인하면, 시간을 효율적으로 사용할 수 있습니다. 작업이 도는 동안 컴퓨터 앞을 지키고 있을 이유가 없어진 셈입니다.

<출처: 작가, Orca 캡쳐>

확인하는 것에서 끝나지 않고 휴대폰에서 다음 지시를 바로 넣을 수도 있습니다. 결과를 훑어보고 이어서 시킬 일이 분명하면 자리로 돌아오기 전에 다음 작업을 걸어 둡니다. 돌아왔을 때 그것까지 끝나 있으면 기다리는 시간이 한 번 더 줄어듭니다.

3) 검토 범위가 분명해진 변경 사항

변경 사항이 각 작업의 브랜치에 나뉘어 담기면서 검토하는 방식도 달라졌습니다. 어떤 작업을 볼 때 그 워크트리의 diff만 보면 되기 때문에, 다른 작업의 수정이 섞여 들어오지 않습니다.

이 덕분에 결과가 마음에 들지 않을 때의 대처도 간단해졌습니다. 예전에는 두 작업이 섞인 상태에서 한쪽만 되돌리려면 어느 줄이 어느 작업의 것인지 가려내야 했지만, 지금은 해당 워크트리를 통째로 삭제하면 됩니다.

4) 한눈에 보이는 사용량

사용량을 한곳에서 볼 수 있게 되면서 에이전트를 고르는 기준이 생겼습니다.

<출처: 작가, Orca 캡쳐>

오르카는 두 계정의 사용량을 한 화면에 보여 줍니다. 코덱스를 얼마나 썼고 언제 다시 채워지는지가 바로 보여서, 남은 양을 보고 이번 작업을 어느 쪽에 맡길지 정할 수 있습니다. 코덱스가 얼마 남지 않았으면 긴 작업은 클로드로 넘기는 식으로 작업이 가능해집니다.

오르카가 잘 맞는 상황과 그렇지 않은 상황

도구를 바꾸는 데에는 적응 비용이 들기 때문에, 모든 상황에 권할 만한 것은 아닙니다.

1) 에이전트를 두 개 이상 돌리는 사람

여러 작업을 동시에 맡기고, 그 결과를 각각 검토해야 하는 상황이라면 유용합니다. 작업이 서로 다른 브랜치에 나뉘어 있으니 검토할 범위가 분명하고, 하나를 버리더라도 다른 작업에 영향이 없습니다.

구독을 두 개 이상 쓰고 있다면 이점이 더 큽니다. 어느 에이전트에게 무엇을 맡길지 고르는 일이 사용량을 확인하는 일과 한자리에서 이뤄지기 때문입니다.

2) 아직 VSCode가 나은 경우

에이전트를 하나만 쓰고 있다면 지금 쓰는 편집기로도 충분합니다. 확장 프로그램과 단축키, 디버거를 새 환경으로 옮겨 오는 비용이 적지 않은데, 작업을 나눠 맡길 일이 없다면 그 비용을 치르고 얻는 것이 크지 않습니다. 오르카의 이점은 작업이 두 갈래 이상으로 갈릴 때부터 나타나기 때문입니다.

에이전트에게 맡기는 일과 직접 쓰는 일의 비중을 먼저 따져 보시길 권합니다. 맡기는 쪽이 늘고 있다면 옮길 이유가 생기고, 직접 쓰는 쪽이 여전히 많다면 서두를 필요가 없습니다.

아직 확인해야 할 한계점

오르카는 아직 빠르게 바뀌는 중입니다. 제가 쓰는 동안에도 버전이 여러 번 올라갔고, 지금 쓰는 버전은 1.4.205입니다. 화면 구성이나 기능 이름이 글을 읽는 시점과 다를 수 있습니다. 작업 단위로 분리 된다는 점은 장점이면서 동시에 생각할 거리이기도 합니다. 폴더가 나뉘어 있으므로 한 작업에서 설치한 의존성이나 만들어 둔 설정 파일이 다른 작업에는 없습니다. 여러 작업에 공통으로 필요한 준비가 있다면 그 부분을 어떻게 공유할지 정해 두는 편이 좋습니다.

쓰면서 크게 불편했던 점은 아직 없습니다. 굳이 꼽자면 VSCode에서 쓰던 ‘터미널 키퍼(Terminal Keeper)’처럼 폴더마다 어떤 터미널을 띄울지 미리 정해 두는 방식이 없다는 점입니다. 작업을 만들 때마다 터미널이 새로 생기다 보니, 자주 쓰는 구성을 저장해 두고 불러오는 식으로는 쓰지 못하고 있습니다.

마치며

VSCode를 쓸 때에는 에이전트를 하나 더 켜는 일이 곧 관리할 것을 하나 더 만드는 일이었습니다. 그러다보니, 에이전트를 여러개 사용하는 것이 효율적으로 다가오지 않았습니다. 어느 터미널이 무슨 작업인지 기억해야 했고, 두 작업의 변경 사항이 섞이지 않도록 신경 써야 했습니다.

오르카로 옮긴 뒤에는 워크트리와 브랜치가 함께 만들어지고, 에이전트는 자기 폴더 안에서만 움직이기 때문에, 제가 하던 관리 업무가 자연스럽게 훨씬 쉬워졌습니다. 다만 이 장점은 에이전트를 여러 개 돌리는 사람에게 더 크게 돌아옵니다. 현재 하나만 쓰신다면 지금 쓰는 편집기로도 충분하고, 굳이 옮기면서 적응 비용을 치를 이유가 크지는 않습니다. 저처럼 새로운 도구를 경험해보고 싶으시다거나, 에이전트를 여러 개 사용하고 계신 분들에게는 오르카를 사용해 보시는 것을 추천드립니다.

이 글은 AI의 도움을 받아 작성했습니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

LLM을 위한 자바스크립트 디버깅 ②: 페이지를 무너뜨리는 파일 찾기부터 AI처럼 접속해 보기까지

이 글은 ‘Search SEOul(서치 서울) 2026’에서 테크니컬 SEO·애널리틱스 컨설턴트 조너선 무어(Jonathan Moore)가 ‘Seoul Searching: Debugging JavaScript for LLMs’라는 제목으로 발표한 내용을 두 편으로 나눠 소개하는 글의 두 번째 편으로, 1회에서 이어집니다. 요즘IT는 서치 서울 2026의 공식 미디어 파트너로서 행사 발표 가운데 요즘IT 독자에게 도움이 될 만한 내용을 골라 전문을 소개하고 있습니다.

1회에서 조너선 무어는 챗GPT·클로드·제미나이 같은 AI 어시스턴트가 답변 근거를 찾을 때 자바스크립트를 렌더링하지 않을 수 있다는 테스트 결과에서 출발했습니다. 그래서 서버가 처음 보내는 원본 HTML(소스 보기)과 자바스크립트가 실행된 뒤의 DOM 사이에서 ‘실패 지점’을 찾아야 한다고 짚었죠. 이어 자신의 디버깅 흐름 다섯 단계(서버가 보내는 것 확인 → 브라우저가 만드는 것과 비교 → 의존 관계 분리 → 콘텐츠 출처 추적 → 여러 사용자 에이전트로 테스트) 가운데 앞의 두 단계를 크롬 개발자 도구 세팅과 텍스트 검색으로 보여 줬습니다.

이번 2회는 나머지 세 단계입니다. 네트워크 요청을 걸러내고 막아 문제의 파일을 찾는 법부터 AI처럼 접속해 보기, 스니펫 활용, 감사 원칙, 크롤러를 이용한 확장까지 이어집니다. 영어로 진행된 발표를 한국어로 옮겼고, 코드 예시는 글 말미의 저장소 링크에서 받아 볼 수 있습니다.

➡️1화 보기:LLM을 위한 자바스크립트 디버깅 ①: 사람에게 보이는 페이지, AI에게도 보일까

요청을 걸러내고 막아서 범인 파일 찾기

그럼 문제를 어떻게 분리할까요? 네트워크 탭에는 아주 유용한 필터 단축 문법이 있습니다. 구글 검색에서 쓰는 site: 명령과 비슷해요. domain: 뒤에 와일드카드를 붙이면 원하는 도메인의 요청만 걸러 낼 수 있습니다. 예를 들어 wolves.co.uk 사이트라면 그 호스트로 필터링해서, 어떤 리소스가 자사 도메인에 있는지 서드파티에 있는지 확인할 수 있죠. 오른쪽 위의 반전(Invert) 체크박스를 켜면 필터 조건의 반대로 걸러 줍니다. 이것도 아주 유용한 팁입니다.

네트워크 필터. 필터 속성(domain: 등)으로 요청 걸러 내기

MIME 유형으로 필터링하는 것도 좋아합니다. Ctrl을 누른 채 클릭하면 여러 유형을 함께 고를 수 있어요. 저는 Fetch/XHR, 문서(Doc), 자바스크립트(JS)를 함께 걸러 봅니다. 찾는 걸 더 쉽게 찾게 해 주는 방법이죠.

MIME 유형으로 필터링하기. Ctrl + 클릭으로 여러 유형을 함께 고른다

다음은 요청 차단입니다. 네트워크 탭의 어떤 요청이든 마우스 오른쪽 버튼을 눌러 그 URL만 막을 수도 있고, 아예 도메인 전체를 막을 수도 있습니다.

네트워크 탭에서 요청 차단하기

명령어 메뉴로 요청 조건(Request conditions) 서랍을 열어 직접 입력해 막는 방법도 있어요.

명령어 메뉴로 요청 조건(Request conditions) 서랍 열기

예를 들어 저는 GraphQL 파일로 필터링했습니다. 이 파일이 페이지를 하이드레이션하는 데 쓰인다는 걸 알고 있었거든요. 이 요청을 막고 새로고침하면 페이지가 처참하게 무너집니다.

GraphQL 요청 하나를 차단하자 페이지 콘텐츠가 사라진 모습

파일 하나가 페이지 전체를 하이드레이션하고 있었던 겁니다. 클로드나 챗GPT가 이 페이지를 가져가면 위 화면처럼 콘텐츠가 빠진 페이지를 보게 될 거라고 저는 꽤 확신합니다. 좋은 상황은 아니죠.

요청 이니시에이터 체인도 볼 수 있습니다. 맨 위에 HTML 파일이 있고, 그 파일이 연쇄적으로 불러오는 다른 파일들이 아래로 이어집니다. CSS, 폰트, 이미지, 그리고 엄청난 양의 자바스크립트까지요. 파일들이 서로 어떻게 연결돼 있는지 보여 주니, 사슬의 고리를 따라가며 어느 파일이 문제인지 짚어 낼 수 있습니다.

요청 이니시에이터 체인

Shift를 누른 채 요청 위에 마우스를 올리면 요청 의존성 트리가 하이라이트되기도 해요. 다만 요청이 수백 개면 아주 큰 모니터가 아닌 이상 한 화면에 다 보이지 않습니다. 쓸 만하지만 약간 보여 주기용 기능이긴 한데, 소개할 가치는 있다고 생각했습니다.

Shift를 누른 채 요청 위에 마우스를 올려 요청 의존성 체인 보기

AI처럼 접속해 보고, 반복 확인은 스니펫에 맡기기

이제 네트워크 조건을 보겠습니다. 이건 정말 중요해요.

명령어 메뉴로 네트워크 조건(Network conditions) 서랍 열기

네트워크 조건 서랍에서는 사용자 에이전트를 바꿀 수 있습니다. 서버가 접속하는 쪽에 따라 다른 응답을 주도록 설정돼 있을 수 있기 때문이죠. 제가 정리한 AI 사용자 에이전트 목록에서 원하는 것을 복사해 붙여 넣으면, 그 사용자 에이전트가 어떻게 동작하는지 어느 정도 흉내 낼 수 있습니다. 서버가 특정 LLM 도구를 막도록 잘못 설정돼 있는지 가늠해 볼 수 있죠. 사용자 에이전트 전환은 정말 유용하니 꼭 써 보세요.

네트워크 조건 서랍에서 사용자 에이전트 바꾸기

다음은 아주 흥미로운 기능입니다. 크롬에서는 스니펫(Snippets)을 실행할 수 있는데, 이걸 아는 분이 많지 않은 것 같아요. 정말 영리한 기능입니다. 대규모 언어 모델 덕분에 저 같은 바보도 자바스크립트를 짤 수 있게 됐거든요. 보시다시피 이 코드에는 이모지가 들어 있으니 제가 짠 게 아닌 건 확실합니다.

스니펫으로 반복 작업 시간 아끼기

이 스니펫은 선택한 텍스트가 원본 HTML과 렌더링된 DOM에 각각 들어 있는지 확인합니다. 만드는 데 30초쯤 걸렸어요. 챗GPT에 “이런 걸 하는 표현식을 짜 주고, 결과를 표로 정리해 주고, 이모지도 넣어 줘”라고 했더니 이걸 줬습니다. 실행할 때는 명령어 메뉴를 열고 느낌표(!)를 입력하면 저장해 둔 스니펫 목록이 나옵니다. 여기서 원하는 스니펫을 고르면 콘솔에 결과가 뜹니다.

명령어 메뉴에 느낌표(!)를 입력해 저장한 스니펫 실행하기

선택한 텍스트가 원본 HTML과 렌더링된 DOM에 있는지 확인하는 스니펫 실행 결과

결과를 보면 이 Q&A 텍스트는 요소 패널(DOM)에는 있지만 소스 보기에는 없습니다. “항암 치료 중에 이 제품을 써도 안전한가요?”처럼 LLM에게 중요한 텍스트가 거기 있다면, 그 내용은 LLM에게 전달되지 않는다는 뜻입니다. 좋지 않죠.

여기서부터는 정말 창의적으로 쓸 수 있습니다. 다음 스니펫에는 좀 더 영리한 일을 시켰어요. 세 가지를 확인합니다. 제목, 메타 디스크립션, 캐노니컬 같은 핵심 태그, 탐색(discovery)에 중요한 페이지에 삽입된 링크, 그리고 구조화 데이터입니다.

핵심 태그·삽입된 링크·구조화 데이터를 확인하는 두 번째 스니펫

예시로 든 사이트는 좀 엉망이었습니다. 구조화 데이터는 전부 소스에는 있는데 DOM에는 없었어요. 제목은 DOM에는 있는데 소스에는 없었고요. 메타 디스크립션은 소스에는 있는데 DOM에는 없었는데, 이건 저도 예상하지 못한 결과였습니다. 믿으셔도 됩니다. 제가 직접 다시 확인했거든요. 이렇게 빠르게 비교할 수 있다는 점이 아주 유용합니다. 결과를 그대로 개발자에게 공유하면 이해하기 쉬워서, 이슈를 보여 주고 강조하기에도 좋습니다.

두 번째 스니펫으로 원본 HTML과 DOM을 비교한 결과

마지막으로 소개할 건 새로운 AI 어시스턴스 기능입니다. 크롬의 실험 기능이라 설정(Preferences)에서 직접 켜야 합니다. 켜고 나면 ‘Debug with AI’ 옵션이 생기는데, 네트워크 요청에서 마우스 오른쪽 버튼을 눌러 “이 요청은 무슨 일을 하나요?”라고 물으면 제미나이가 그 요청이 무엇인지 맥락과 함께 알려 줍니다. 기술을 잘 모르거나 그 웹사이트를 전혀 모르는 사람도 제미나이에 물어보면 요청의 정체를 알 수 있어요. 그러고 나서 개발자와 회의하면 꽤 아는 사람처럼 보일 수 있죠.

개발자 도구의 AI 어시스턴스 기능

감사는 템플릿·전역 요소·기술 스택·서드파티 순서로

기술적인 이야기를 아주 자세히 했으니, 이제 한 걸음 물러나 이것들을 어떻게 엮을지 감사(auditing) 원칙으로 마무리하겠습니다. 저는 페이지 템플릿, 전역 요소, 기술 스택, 서드파티 연동 순으로 감사합니다. 아주 단순하죠.

페이지 템플릿은 하나씩 검토합니다. 자바스크립트를 감사하는 일은 자바스크립트를 크롤링하는 일과 마찬가지로 시간이 걸리고, 페이지를 하나하나 눈으로 보는 편이 더 쉽기 때문입니다. 시간을 아끼려고 저는 템플릿 유형별 상위 페이지를 뽑아 주는 스크립트도 씁니다. 구글 애널리틱스 등에서 데이터를 가져와 상위 카테고리, 상위 목록, 상위 상품 등을 알려 주죠. 카테고리 페이지는 모두 같은 방식으로 만들어지고 목록 페이지도 마찬가지일 테니, 이 상위 페이지부터 감사를 시작합니다.

다음으로 전역 요소를 봅니다. 모든 페이지 템플릿에 들어가는 요소라서, 이걸 고치면 웹사이트의 모든 페이지가 좋아지는 효과가 있습니다. 내비게이션, 사이트 검색, 브레드크럼이 대표적인데, 대체로 처리가 꽤 엉성한 편입니다. 리뷰 띠(review strip)도 있습니다. 들어가 있을 때도 있고 아닐 때도 있죠. 배송 정보 같은 요소와 푸터도 있습니다. 상식적으로 모든 페이지에 무엇이 있는지 파악하면 됩니다.

그다음은 기술 스택입니다. 어떤 CDN, 플랫폼, 프레임워크, 데이터, API 호출을 쓰는지가 서로 어떻게 맞물리는지 봅니다. 다만 저는 이걸 마지막 즈음에 봅니다. 앞의 두 가지가 훨씬 중요하다고 느끼거든요. 앞에서 사이트가 어떻게 돌아가는지 감을 잘 잡았다면 기술 스택을 크게 걱정할 필요는 없습니다. 내부 작동을 속속들이 이해하기보다는 눈에 보이는 차이를 설명할 수 있으면 됩니다.

마지막으로 서드파티입니다. 저는 서드파티 연동이 정말 흥미로운 부분이라고 생각합니다. 특히 이커머스에서는 외부 소스에서 불러오는 요소가 많은데, 서드파티 스크립트는 거의 확실히 서버 사이드에서 렌더링되지 않습니다.

리뷰가 대표적이죠. 리뷰가 좋든 나쁘든, 유용한 맥락을 주는 것이라면 제대로 전달되는지 꼭 확인해야 합니다. Q&A와 FAQ도 마찬가지예요. 정보의 금광이니까요. 상품 추천 같은 요소는 그보다는 덜하지만 전체가 어떻게 맞물리는지 보는 데 도움이 됩니다. 주문 처리·배송 정보는 아주 중요합니다. UGC와 소셜 프루프도 있는데, 성능 측면에서는 이미지와 서드파티 폰트 라이브러리 등을 잔뜩 불러와 페이지를 느리게 만드는 경향이 있습니다.

이렇게 나눠서 본 뒤 하나로 합치면, 전체가 어떻게 맞물리는지 큰 그림이 보입니다. 앞서 말씀드렸듯 이슈를 발견하는 족족 고치고 싶은 유혹이 들지만, 그보다 큰 그림을 보고 “이렇게 맞물려 있으니 이걸 고쳐야 효과가 난다”고 판단하는 게 중요합니다.

페이지 범위와 영향도를 기준으로 수정 우선순위를 정리한 예시

이를테면 이런 고전적인 ‘영향도 대 페이지 범위’ 지표로 정리할 수 있습니다. 무엇을 어떤 순서로 고쳐야 하고 그 결과 무엇을 얻을지 설명하는 거죠. 전역 요소는 더 많은 페이지에 영향을 주니 효과도 클 테고, 서드파티는 그보다 작을 수 있습니다. 이 그림은 챗GPT로 만든 거라 수치는 지어낸 것이지만, 대체로 맞는 이야기입니다.

규모를 키울 때는 크롤러로

이제 확인 작업을 규모 있게 하는 법입니다. 이런 작업에 브라우저 확장 프로그램도 나쁘지 않습니다. ‘View Rendered Source’는 나온 지 꽤 됐고 3년째 업데이트가 없는데, 저도 가끔 씁니다. 하지만 Ctrl + U를 쓸 때처럼 제 브라우저가 멈춰 버려서 자주 쓰지는 않아요.

브라우저 확장 프로그램 ‘View Rendered Source’

대신 저는 크롤러를 좋아합니다. 무엇을 크롤링하고 무엇을 하지 않을지, 어떻게 렌더링할지 직접 정할 수 있어서 규모를 키우기에 좋습니다. 한국에서 얼마나 쓰이는지는 모르겠지만, 사이트벌브(Sitebulb)는 아주 강력합니다. 좋은 기능 중 하나는 클라우드에서 돌릴 수 있다는 점이에요. 설정해 두고 주 1회든 월 1회든 필요한 주기로 예약해 두면, 다시 돌아왔을 때 무엇이 바뀌었고 무엇이 그대로인지, 무엇이 크롤링됐고 무엇이 삭제됐는지 알려 줍니다.

크롤러 사이트벌브(Sitebulb)로 자바스크립트 사이트 크롤링하기

써 보신 적이 없다면 무료 체험판도 있습니다. 돈 받고 하는 말은 아니에요. 사이트를 대규모로 크롤링하고, 요즘 하기 싫은 지루한 일들을 대신 맡기기에 가성비가 정말 좋은 방법입니다.

LLM이 받는 페이지를 보세요

마무리하겠습니다. 우리는 LLM이 무엇을 받아 가는지 알아야 합니다. 여러분이 보고 있는 페이지가 LLM이 받는 페이지와 같지 않을 수 있기 때문입니다. 가져가지 못한 콘텐츠는 보이지 않습니다.

오늘 보여 드린 코드 예시는 모두 깃허브 저장소에 올려 두었습니다. 스크린샷이 작아서 제가 무엇을 가리켰는지 잘 안 보였을 테니, 특히 뒷자리에 계셨던 분들을 위해 발표 자료도 스피커덱(Speaker Deck)에 올려 두었습니다. 깃허브 저장소에 스피커덱 링크도 함께 넣어 두겠습니다.

발표 뒤 질의응답에서는 서버 비용 부담을 고려할 때 동적 렌더링 같은 방식이 더 나은 선택이 될 수 있는지에 관한 질문이 나왔습니다. 제 답은 이렇습니다.

결국 목표에 따라 가장 좋은 렌더링 방식을 정해야 합니다. 저는 늘 비즈니스 사례와 연결해 보려고 합니다. 렌더링 전략을 바꾸는 건 꽤 큰 변화니까요. 어떤 LLM에 맞춰 최적화할지부터 정해야 합니다. 그 LLM이 자바스크립트를 렌더링할 수도 있고, 렌더링하지 않을 수도 있죠. 그렇게 결정한 다음, 렌더링 전략을 바꿨을 때 얻을 이점이 무엇인지 따져 보세요. 모든 걸 한 가지 방식으로 렌더링하면 좋겠지만, 거기에는 연산 비용이 따릅니다.

다른 우회책도 있습니다. 이미 이야기가 나왔듯, llms.txt 같은 방식을 지지하는 사람들이 있습니다. 특정 상황에서는 페이지의 마크다운 버전을 제공해서, LLM이 정보를 뽑느라 토큰을 다 쓰지 않아도 되게 하는 거죠. 클라우드플레어(Cloudflare)처럼 에이전트용 마크다운(Markdown for Agents)을 내놓은 곳도 있습니다. 엣지에서 에이전트에게 페이지의 마크다운 버전을 보여 주는 방식이에요. 렌더링 방식을 바꾸는 대신, 텍스트가 더 풍부한 다른 버전을 에이전트에게 보여 주는 또 다른 우회책입니다.

이 둘 중 어느 쪽을 권하는 건 아닙니다. 다만 각자의 기술적 과제에 맞춰 사람들이 여러 해법을 찾고 있다는 점은 흥미롭다고 생각해요. 결국 여러분의 비즈니스와 조직, 기술 스택과 예산에 무엇이 맞는지로 돌아가게 됩니다.

▶ 발표 코드 예시 저장소(깃허브) 보기:

]]>

LLM을 위한 자바스크립트 디버깅 ①: 크롬 개발자 도구로 AI 가시성 점검하기

AI 검색이 새로운 유입 경로로 자리 잡으면서, 검색 최적화 실무자의 질문도 달라지고 있습니다. “구글이 우리 페이지를 잘 읽는가”를 넘어 “챗GPT나 클로드 같은 AI는 우리 페이지에서 무엇을 가져가는가”를 따져야 하는 때가 된 것이죠. 지난 9월 3일과 4일 서울 마포에서 열린 ‘Search SEOul(서치 서울) 2026’은 이런 고민을 국내외 SEO·GEO 실무자가 함께 나눈 자리였습니다. 올해 2회째를 맞은 서치 서울은 해외에서 주로 열리던 글로벌 SEO 컨퍼런스를 한국에서 열고, 한국 검색 환경과 해외 SEO·GEO 흐름을 잇겠다는 취지로 시작된 행사입니다.

요즘IT는 서치 서울 2026의 공식 미디어 파트너로서, 행사 발표 가운데 요즘IT 독자에게 도움이 될 만한 내용을 골라 전문을 소개하고 있습니다. 이번 글은 행사 첫날 오후, 테크니컬 SEO·애널리틱스 컨설턴트 조너선 무어(Jonathan Moore)가 ‘Seoul Searching: Debugging JavaScript for LLMs’라는 제목으로 발표한 내용입니다. 사용자가 보는 페이지와 LLM이 받아 가는 페이지 사이의 간극을 크롬 개발자 도구로 직접 찾아내는 방법을 다룹니다. 발표 분량이 많아 두 편으로 나눠 싣습니다. 이번 1회에는 문제의 배경과 디버깅 원칙, 크롬 개발자 도구 세팅과 텍스트 검색까지 담았습니다. 영어로 진행된 발표를 한국어로 옮겼고, 발표에 쓰인 코드 예시는 발표자가 공개한 저장소(글 말미 링크)에서 받아 볼 수 있습니다.

참고로 발표는 9월 초에 진행됐고, 이 글은 10월에 공개합니다. AI 서비스는 업데이트가 잦은 만큼, 글에 나오는 각 AI 시스템의 자바스크립트 렌더링 여부는 지금 시점과 다를 수 있습니다.

안녕하세요. 저는 테크니컬 SEO·애널리틱스 컨설턴트 조너선 무어입니다. 오늘은 디버깅 이야기를 하려고 합니다. 시작하기 전에 먼저 사과부터 드려야겠네요. 제가 영국인이라서요. 썰렁한 농담이 나오더라도 통역을 거치면서 조금이나마 살아나길 바랍니다. 커피 브레이크 직전 마지막 발표이기도 하니, 최대한 요점 위주로 가 보겠습니다.

구글은 괜찮다던 자바스크립트, AI는 다릅니다

이야기의 틀부터 잡아 볼게요. 저는 유럽에서 일하고 있어서 주로 구글을 상대로 일합니다. 그런데 꽤 오랫동안 구글에 “자바스크립트 신경 써야 하나요?” 하고 물으면, 구글 담당자들은 대체로 이렇게 답했습니다. “아니요, 괜찮습니다. 저희가 처리할 수 있어요. 크롤링도 잘하고, 색인도 잘하고, 렌더링도 잘하니까 크게 걱정하지 않으셔도 됩니다.” 그래서 우리는 이런 문제를 어느새 신경 쓰지 않게 됐죠.

문제는 여기서부터입니다. 구글은 자바스크립트를 정말 잘 처리합니다. 하지만 LLM은 그렇지 않을 수 있어요. 이게 지금 우리가 마주한 과제입니다.

구글이 몇 년 동안 소개해 온 렌더링 파이프라인은 다들 익숙하실 거예요. 구글 시스템이 어떻게 작동하는지 보여 주는 좋은 예시지만, 대규모 언어 모델(LLM)에 맞춰 최적화하는 지금의 상황에 그대로 들어맞는 건 아닙니다. 그래서 어떤 AI 시스템이 자바스크립트를 렌더링하고 어떤 시스템은 하지 않는지를 알아야 합니다. AI가 페이지에서 정보를 뽑아 답변을 합성하는 방식에 큰 문제가 될 수 있기 때문이에요.

다행히 누군가 이미 이 부분을 조사해 줘서 제가 직접 할 필요는 없었습니다. 안드레 알파(Andre Alpar)가 AI 어시스턴트가 답변 근거를 찾을 때 실제로 자바스크립트를 렌더링하는지 테스트한 결과입니다.

AI 어시스턴트별 자바스크립트 렌더링 여부를 테스트한 결과 (출처: Search Engine World, 안드레 알파)

결과를 보면 서구권 모델들은 대체로 지금 자바스크립트를 렌더링하지 않는 것으로 보입니다. 이런 모델을 쓰고 있다면 꽤 곤란한 일이죠. 위쪽에는 자바스크립트를 렌더링하는 모델이 있습니다. 딥시크(DeepSeek), 큐원(Qwen), 키미(Kimi), 미스트랄(Mistral)은 모두 자바스크립트를 렌더링해요. 아래쪽의 챗GPT, 클로드, 제미나이 등은 렌더링하지 않습니다. 문제가 될 수 있으니 좀 더 자세히 들여다봐야 합니다.

문제는 자바스크립트가 아니라 ‘실패 지점’입니다

제 생각에 문제가 꼭 자바스크립트 자체에 있는 건 아닙니다. 자바스크립트는 인터넷의 큰 부분을 차지하고 있고, 앞으로도 그랬으면 좋겠어요. 웹사이트에 상호작용을 더해 주는 훌륭한 도구니까요. 다만 자바스크립트가 실패 지점(point of failure)이 된다는 게 문제입니다. 젠가 탑을 떠올려 보세요. 블록 하나를 잘못 빼면 탑 전체가 무너집니다.

제 디버깅의 핵심 개념은 두 가지입니다. 먼저 소스 보기(View Source)입니다. 다들 아실 텐데, 서버가 처음 브라우저로 보내는 코드, 즉 원본 HTML(raw HTML)을 말합니다.

소스 보기: 서버가 처음 브라우저로 보내는 코드

다음은 DOM입니다. 브라우저에서 자바스크립트가 실행된 뒤의 HTML, 그러니까 브라우저가 지금 이 페이지를 어떻게 표현하고 있는지를 나타냅니다. 우리가 이해하려는 기본 개념이 바로 이 둘이에요.

DOM: 자바스크립트가 바꾼 내용까지 반영한, 브라우저가 지금 표현하고 있는 페이지

렌더링 방식에는 여러 가지가 있고, 정답도 오답도 없습니다. 페이지가 얼마나 자주 바뀌는지, 어떤 콘텐츠를 담는지 등에 따라 렌더링 전략은 달라져야 해요. 어느 쪽도 틀리지 않지만, 각 방식이 어떻게 작동하는지 알아야 맞는 방식을 고를 수 있습니다.

가장 기본은 서버 사이드 렌더링(SSR)입니다. 모든 것이 서버에서 완전히 렌더링된 채로 넘어오고, 소스 코드에 들어 있습니다. 페이지 제목, 메타 디스크립션, H1 같은 요소가 서버에서 바로 받아집니다.

문제가 생기기 쉬운 쪽은 클라이언트 사이드 렌더링(CSR)입니다. 서버는 HTML 뼈대(shell)만 보내고, 브라우저가 자바스크립트를 실행해야 합니다. 자바스크립트가 실행되면서 페이지를 하이드레이션(hydration)하고 콘텐츠를 채워 넣는 방식이죠.

클라이언트 사이드 렌더링: 콘텐츠가 브라우저에서 자바스크립트로 렌더링된다 (출처: web.dev)

기초 수준에서 정리하면, 이 두 방식의 차이가 우리가 주의해야 할 부분입니다. 우리가 길러야 할 기술은 어디까지가 서버에서 렌더링되고 어디부터 그렇지 않은지, 즉 실패 지점을 찾아내는 능력입니다.

원인부터 찾는다: 제 디버깅 원칙과 흐름

제가 일하는 방식, 일종의 철학부터 말씀드릴게요. 첫째, 근본 원인을 찾습니다. 어떤 이슈든 근본 원인을 파악하는 게 가장 중요하다고 생각해요. 문제에서 거꾸로 거슬러 올라가 해결책을 찾는 겁니다. 둘째, 이슈를 쏟아 내듯 나열하지 않습니다. 발견한 문제를 잔뜩 늘어놓는 대신 뿌리를 찾는 것, 저는 이게 핵심이라고 봅니다.

제가 주로 쓰는 방법은 직접 눈으로 보는 겁니다. 브라우저에 들어가서 하나하나 확인하죠. 제 디버깅 흐름은 이렇습니다.

서버가 무엇을 보내는지 확인한다
브라우저가 무엇을 만드는지 비교한다
의존 관계를 분리한다
콘텐츠가 어디서 오는지 추적한다
여러 사용자 에이전트로 테스트한다

지금부터 브라우저 안에서 이 각각을 어떻게 확인하는지 보여 드리겠습니다. 그리고 두 번째 사과를 드립니다. 저는 윈도우를 씁니다. 맥을 쓰신다면 단축키는 알아서 바꿔 생각해 주세요.

크롬 개발자 도구부터 디버깅용으로 세팅하세요

디버깅이나 SEO 작업에 관심 있는 분께 제가 가장 먼저 권하는 건 디버깅 전용 크롬 프로필을 만드는 것입니다. 크롬에서는 이메일마다 프로필을 따로 둘 수 있고, 꼭 이메일이 없어도 프로필을 만들 수 있어요. 프로필마다 확장 프로그램과 설정을 다르게 둘 수 있으니, 프로필만 바꾸면 바로 디버깅할 준비가 됩니다. 제 최고의 조언이 바로 이겁니다.

디버깅 전용 크롬 프로필 만들기

프로필에 들어가면 저는 네트워크 탭부터 설정합니다. 맞춤 설정할 수 있는 항목이 많거든요. 작은 톱니바퀴 아이콘을 누르면 요청 행을 크게 보는 옵션(Big request rows), 스크린샷 옵션 등을 켤 수 있습니다. 페이지를 오가며 볼 때는 로그 유지(Preserve log)도 켜고, 캐시 비활성화(Disable cache)도 기본으로 켜 두는 편인데, 이건 다른 종류의 디버깅에 더 쓰입니다. 옵션이 정말 많으니 한번 살펴보세요.

네트워크 탭 설정에서 Big request rows와 Screenshots 옵션 켜기

다음으로 네트워크 탭의 열(헤더)을 맞춤 설정합니다. 켜고 끄기도 쉬워서 아주 유용해요. 저는 기본으로 URL, 도메인, 메서드를 추가하고, 성능 최적화 작업을 할 때는 우선순위(Priority)도 추가합니다. 원치 않는 열을 켰다가 되돌리고 싶을 때는 마우스 오른쪽 버튼으로 열 설정을 다시 바꾸면 됩니다.

네트워크 탭에 원하는 열(헤더) 추가하기

세팅을 마쳤으면 요소(Elements) 패널을 엽니다. 단축키는 Ctrl + Shift + C입니다. DOM으로 바로 들어가는 길이죠.

요소 패널 열기(Ctrl + Shift + C)

소스 보기는 Ctrl + U로 열 수 있는데, 저는 분석이나 디버깅에 소스 보기를 잘 쓰지 않습니다. 큰 페이지에서는 브라우저가 그냥 죽어 버리거든요. 적어도 제 컴퓨터에서는 그렇습니다. 오래된 컴퓨터인데 바꿀 형편이 안 돼서요.

소스 보기(Ctrl + U)

그래서 저는 소스(Sources) 패널에서 원본 HTML을 봅니다. 서버에서 받아 온 실제 HTML을 보려면 여기가 제 출발점이에요. 정리하면 DOM은 요소 패널에서, 원본 HTML은 소스 패널에서 봅니다.

소스 패널에서 서버가 보낸 원본 HTML 확인하기

크롬 개발자 도구에는 명령어 메뉴도 있습니다. 개발자 도구를 연 상태에서 Ctrl + Shift + P를 누르면 명령어 서랍이 열립니다. 쓸 수 있는 명령이 아주 많은데, 자주 쓰는 것 중 하나가 스크린샷이에요. 크롬 안에서 뷰포트 크기를 정해 전체 페이지 스크린샷을 찍을 수 있습니다. 디버깅에 특화된 기능도 여럿 있으니 전체 명령어 목록을 한번 확인해 보세요.

개발자 도구의 명령어 메뉴(Ctrl + Shift + P)

오늘 주제가 자바스크립트이니, 먼저 자바스크립트를 끄고 켜는 방법부터 보겠습니다. 명령어 메뉴에 ‘Disable JavaScript’를 입력하고 새로고침하면 브라우저에서 자바스크립트가 꺼집니다. 자바스크립트 없이도 페이지가 돌아가는지 확인하는 가장 단순한 방법이에요. 단점은 다시 켜는 걸 기억해야 한다는 겁니다. ‘Enable’을 입력해 다시 켜야 해서 조금 번거롭지만, 확장 프로그램을 따로 쓸 필요 없이 명령어로 바로 처리할 수 있어 시간을 아낄 수 있습니다.

명령어 메뉴에서 Disable…·Enable…을 입력해 자바스크립트 끄고 켜기

텍스트 검색으로 서버 응답과 DOM 비교하기

이제 텍스트를 검색해 보겠습니다. 텍스트 문자열 검색은 우리가 하는 가장 기본적인 작업일 거예요. 요소 패널에서 Ctrl + F를 누르면 원하는 텍스트를 찾을 수 있습니다. DOM에서 보이는 텍스트가 소스 패널에도 있는지 확인하는 것, 이게 변화를 찾아내는 가장 기본적인 방법입니다.

소스 패널에서 텍스트 찾기

요소 패널의 좋은 점은 페이지에서 텍스트를 드래그한 뒤 마우스 오른쪽 버튼을 눌러 ‘검사’를 선택하면 해당 DOM 노드로 바로 이동한다는 겁니다. 하이라이트까지 해 줘서 편리하죠.

페이지에서 텍스트를 선택하고 마우스 오른쪽 버튼 → 검사로 요소 패널에서 찾기

요소 패널에서 정말 강력한 기능은 XPath 표현식을 쓸 수 있다는 점입니다. AND, OR 조건을 걸 수 있고, 부정(negation) 조건도 쓸 수 있어요. 예를 들어 페이지를 하이드레이션하는 데 쓰이는 JSON 텍스트 덩어리를 XPath로 찾을 수 있습니다. LLM이 관심을 가질 만한 정보를 바로 찾아낸 뒤, 그게 소스 보기에도 있는지 확인하는 거죠. XPath로 할 수 있는 영리한 작업은 정말 많습니다.

요소 패널에서 Ctrl + F로 검색하기. XPath로 패턴을 찾을 수 있다

선택한 노드는 $0으로 참조할 수 있습니다. Esc를 눌러 콘솔 서랍을 열고 아래 코드를 넣으면, 선택한 JSON 덩어리를 보기 좋게 정리해 줍니다.

console.log(JSON.stringify(JSON.parse($0.textContent), null, 2))

$0으로 선택한 노드를 참조해 JSON을 정리해 출력하기

이걸 복사해서 원하는 LLM에 넣고 추가로 분석할 수 있습니다. 필요한 부분만 떼어 내 클립보드나 텍스트 파일로 저장하기에도 좋은 방법이에요.

제가 즐겨 쓰는 또 하나는 로드된 모든 텍스트를 검색하는 Ctrl + Shift + F입니다. XPath 검색과 달리 여기서는 정규표현식 검색을 쓸 수 있어요. 특정 자바스크립트 라이브러리를 불러오는 데 쓰일 법한 자바스크립트 구문을 정규표현식으로 검색하면, 페이지를 빠르게 훑으면서 차단 요인이나 근본 원인 후보를 찾아낼 수 있습니다.

로드된 모든 텍스트 검색(Ctrl + Shift + F). 정규표현식 검색을 쓸 수 있다

마지막으로 개별 네트워크 요청 안을 검색할 수 있습니다. 서버에서 바로 받아 온 것을 골라내는 데 유용해요. 네트워크 탭에서 Ctrl + F를 누르면 네트워크 요청 안에서 텍스트를 바로 찾을 수 있고, DOM에 있는 것과 소스에 있는 것, 그리고 그 텍스트가 어느 파일에서 왔는지를 비교할 수 있습니다.

네트워크 탭에서 Ctrl + F로 응답 내용 검색하기

정리하면, 용도에 따라 검색 위치가 다르고 매칭 방식도 다릅니다. 일반 텍스트 검색, XPath, 정규표현식이 그것이죠. 이 검색들을 이것저것 써 보다 보면 건초 더미에서 바늘을 찾는 데 꽤 가까워질 겁니다.

개발자 도구의 검색 기능 정리 (출처: Chrome for Developers)

지금까지 LLM이 자바스크립트를 렌더링하지 않을 때 무엇이 문제가 되는지, 그리고 크롬 개발자 도구를 디버깅용으로 세팅해 서버가 보낸 원본 HTML과 브라우저가 만든 DOM을 텍스트 검색으로 비교하는 방법을 살펴봤습니다. 조너선 무어가 소개한 디버깅 흐름 다섯 단계 가운데 앞의 두 단계, ‘서버가 무엇을 보내는지 확인하고 브라우저가 무엇을 만드는지 비교하기’에 해당합니다.

이어지는 2회에서는 나머지 세 단계를 다룹니다. 네트워크 요청을 걸러내고 차단해 페이지를 무너뜨리는 ‘범인 파일’을 찾는 법, 사용자 에이전트를 바꿔 AI처럼 접속해 보는 법, 반복 확인을 스니펫과 AI 어시스턴스 기능에 맡기는 법을 소개합니다. 이어서 이 도구들을 엮어 사이트를 감사하는 순서와 크롤러로 점검 규모를 키우는 방법까지 정리합니다.

▶ 발표 코드 예시 저장소(깃허브) 보기

]]>

AI 시대에 아이에게 무엇을 가르쳐야 할까

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: wshobson/agents - 클로드 코드, Codex, 커서에서 함께 쓰는 플러그인 94개 모음
참고할 것: 클로드 듀엣(Claude Duet) - 할 일을 먼저 챙겨서 알려주는 앤트로픽의 새 에이전트
적용해볼 것: AI 시대에 아이에게 무엇을 가르쳐야 할까, 해커뉴스 댓글 600여 개가 내놓은 답

<출처: wshobson/agents, GitHub>

1. 써볼 것: 클로드 코드, Codex, 커서에서 함께 쓰는 플러그인 94개 모음

AI 코딩 도구를 오래 쓰다 보면 같은 부탁을 반복하게 됩니다. 코드 리뷰는 이런 순서로 해줘, 테스트는 이렇게 짜줘 같은 지시를 매번 다시 적는 거죠. 이런 지시와 작업 순서를 묶어, 설치만 하면 바로 쓸 수 있게 만든 것이 플러그인입니다. wshobson/agents는 플러그인 94개를 모아둔 저장소로, GitHub 스타가 4만 개를 넘었습니다.

이 저장소의 특징은 한 가지 도구에 묶이지 않는다는 점입니다. 클로드 코드(Claude Code), 코덱스(Codex), 커서(Cursor), GitHub Copilot, OpenCode, Antigravity, Pi까지 일곱 가지 AI 코딩 도구에서 같은 플러그인을 쓸 수 있어요. 팀원마다 쓰는 도구가 달라도 같은 작업 방식을 나눠 쓸 수 있다는 뜻입니다.

무엇이 들어 있나요?

플러그인 94개 안에 에이전트 202개, 스킬 185개, 명령어 105개가 들어 있습니다. 에이전트는 특정 일을 맡아 처리하는 보조 AI, 스킬은 AI가 필요할 때 꺼내 읽는 작업 지침, 명령어는 이름을 불러 바로 실행하는 작업 순서입니다.

대부분은 개발용입니다. 파이썬·자바스크립트 개발, 코드 리뷰, 테스트, 보안 점검, 장애 대응 같은 플러그인이 많아요. 그런데 개발자가 아니어도 쓸 만한 것도 섞여 있습니다.

before-you-build: 만들기 전에 제품의 위험 요소를 점검합니다. 저장소는 창업자와 프로덕트 팀, AI로 뭔가를 만드는 사람을 위한 플러그인이라고 소개합니다.
startup-business-analyst: 시장 규모 추정, 재무 모델, 팀 구성 계획 같은 사업 분석을 돕습니다.
avoid-ai-writing: README나 문서에서 AI가 쓴 티가 나는 문장을 찾아 고쳐 씁니다.
pptx-deck-creation: 바로 고쳐 쓸 수 있는 PowerPoint 발표 자료를 만듭니다.
accessibility-compliance: 웹 접근성 기준(WCAG)에 맞는지 점검합니다.

어떻게 쓰나요?

클로드 코드에서는 아래 두 줄로 설치합니다. 첫 줄은 이 저장소를 플러그인 목록에 등록하고, 둘째 줄은 원하는 플러그인 하나를 설치하는 명령이에요.

/plugin marketplace add wshobson/agents
/plugin install before-you-build@claude-code-workflows

첫 줄은 목록만 등록할 뿐, 플러그인을 불러오지는 않습니다. 필요한 플러그인만 골라 설치하는 방식이라, AI가 쓸데없는 지침까지 읽느라 헷갈리는 일을 줄일 수 있어요. 9/11 회차에서 오픈AI 개발자 에릭 프로벤처가 스킬을 너무 많이 깔지 말라고 조언했는데, 이 저장소도 같은 원칙을 따릅니다.

다른 도구를 쓴다면 스킬 하나만 따로 설치할 수도 있습니다. 설치 방법은 도구마다 달라서 저장소 안내 문서에 정리돼 있어요. MIT 라이선스라 무료로 쓸 수 있습니다. 저장소를 만든 AI 엔지니어 시스 홉슨(Seth Hobson)이 세운 회사의 메모리 플러그인 하나가 외부 항목으로 함께 올라가 있다는 점은 알아두면 좋습니다.

누구에게 좋을까요?

여러 AI 코딩 도구를 함께 쓰는 개발자. 도구를 바꿔도 같은 작업 방식을 그대로 가져갈 수 있습니다.
팀원마다 쓰는 AI 도구가 다른 팀. 코드 리뷰나 테스트 기준을 플러그인 하나로 맞출 수 있어요.
클로드 코드로 제품을 직접 만들어보는 기획자. before-you-build처럼 만들기 전 점검용 플러그인부터 써볼 만합니다.
다만 플러그인 대부분이 개발 작업용이고, 클로드 코드 같은 AI 코딩 도구가 있어야 쓸 수 있습니다. 개발 도구를 써본 적이 없다면 설치부터 낯설 수 있습니다.

<출처: Anthropic, Introducing Claude Duet>

2. 참고할 것: 할 일을 먼저 챙겨서 알려주는 앤트로픽의 새 에이전트

10/9 회차에서 a16z 보고서를 다루며, 메타의 Muse와 오픈AI의 dots, SpaceXAI의 Grok Bot처럼 일을 맡기면 알아서 처리하는 개인 비서 AI 경쟁이 시작됐다고 전해드렸습니다. 이번엔 앤트로픽 차례입니다. 앤트로픽이 10월 21일 클로드 듀엣(Claude Duet)을 연구 프리뷰로 공개했어요.

클로드 듀엣은 사용자가 말을 걸기 전에 먼저 챙길 일을 알려주는 에이전트입니다. 앤트로픽은 혼자 챙기기 어려울 만큼 할 일이 많은 전문직과 소상공인을 위해 만들었다고 설명합니다.

무엇이 다른가요?

매일 아침 연결된 앱에서 중요한 일을 추려 짧은 브리핑을 보내고, 낮에는 몇 시간마다 앱을 살피다가 꼭 필요할 때만 말을 겁니다. 확인 간격을 몇 시간으로 둔 건, 쉬지 않고 살피면 요금제 사용량이 훨씬 빨리 닳기 때문이라고 해요.

일을 맡길 때는 대화창 하나에서 글이나 음성으로 부탁하면 됩니다. 클로드 듀엣은 자기만의 가상 컴퓨터와 브라우저에서 일하기 때문에, 내 노트북이나 휴대폰이 꺼져 있어도 일이 계속 진행돼요. 끝나거나 확인이 필요하면 알림이 옵니다. 클로드 계정에 쌓아둔 메모리와 스킬, 연결한 앱도 그대로 이어받아서 따로 설정할 게 거의 없습니다.

무엇을 맡길 수 있나요?

클로드 마켓플레이스의 커넥터와 플러그인 6,000개 이상을 쓸 수 있습니다.

클로드 듀엣과 연결해 쓸 수 있는 앱들 <출처: Anthropic>

앤트로픽이 든 예시는 이렇습니다.

놓친 Gmail과 Slack 메시지를 찾아 답장 돕기
QuickBooks나 Stripe에서 미수금을 확인하고 독촉 메일 초안 쓰기
Gusto에서 근무 시간과 보너스를 채워 급여 처리하기
채용 공고를 쓰고, 승인하면 LinkedIn에 올리기
HubSpot의 거래 기록을 바탕으로 후속 메일 쓰기
Shopify 스토어를 만들고 관리하기

먼저 써본 사람들의 사례도 공개됐습니다. 한 부동산 중개인은 시키지 않았는데도 클로드 듀엣이 매물 안내 일정이 다른 날짜로 잘못 잡힌 걸 찾아냈다고 해요. 직원 약 110명 규모의 식당을 운영하는 사장은 매장별 청구서를 한꺼번에 정리하며 탭을 100개씩 열 필요가 없어졌다고 했고요. 한 브랜드 전략가는 고객 미팅 직후에 비행기 일정이 있다는 걸 클로드 듀엣이 먼저 알아차리고 미팅을 옮기자고 제안했다고 전했습니다.

어디까지 맡기나요?

클로드 듀엣은 읽고, 초안을 쓰고, 준비하는 일은 혼자 합니다. 하지만 메시지를 보내거나, 결제하거나, 서명하거나, 무언가를 지우기 전에는 무엇을 하려는지 보여주고 승인을 기다려요. 증권 거래나 계좌 간 이체처럼, 사용자가 승인해도 하지 않는 일도 정해뒀습니다.

정보를 다루는 기준도 따로 있습니다. 비밀번호나 로그인 정보는 클로드 듀엣이 직접 보지 못하게 설계했고, 카드 번호나 신분증 정보는 보내달라고 해도 거절합니다. 건강이나 개인 재정 정보는 사용자가 분명하게 지시할 때만 보낸다고 앤트로픽은 밝혔습니다.

바로 써볼 수 있나요?

아직은 어렵습니다. 미국의 Pro·Max 구독자부터 대기 명단으로 열었고, Team과 Enterprise 요금제는 빠져 있어요. 한국 이용 시점은 따로 밝히지 않았습니다. 기존 클로드 앱과는 별도인 iOS·안드로이드 앱과 claude.ai 웹에서 씁니다. 추가 요금은 없지만, 요금제 사용량은 다른 클로드 기능과 나눠 씁니다. 백그라운드 확인도 사용량에 포함되고, 재무 모델이나 발표 자료처럼 큰 작업은 더 많이 차감된다고 해요.

앤트로픽도 한계를 밝혔습니다. 대화를 잘못 읽거나 급한 정도를 잘못 판단할 수 있고, 티켓 예매 같은 개인 심부름은 아직 서툴고, 작업 중인 브라우저 화면을 사용자에게 보여주지 못한다고 해요.

써본 사람들의 반응은 어떨까요?

해커뉴스에서는 공개 당일 이 소식이 추천 300개를 넘겼고, 댓글도 280개가 달렸습니다. 팟캐스트 How I AI를 진행하는 클레어 보(Claire Vo)는 레니 뉴스레터에 쓴 리뷰에서 지금까지 본 에이전트 출시 중 가장 완성도가 높다고 평가했어요. 특히 처음 시작하는 과정과 할 일 목록, Slack처럼 주제별로 나뉜 대화방을 좋게 봤습니다.

다만 리뷰 제목은 "클로드 듀엣은 아름답다. 그런데 나는 쓰는 걸 잊었다"였습니다. 먼저 말을 거는 일이 기대보다 적고 대화를 주고받는 속도도 느린 데다, 데스크톱 앱과 여럿이 함께 쓰는 기능이 없어서 매일 쓰는 도구가 되지는 못했다는 거예요.

무엇을 얻어가면 될까요?

앤트로픽은 클로드 듀엣을 만들며 언제 말을 걸고 언제 조용히 있을지를 많이 고민한 것으로 보입니다. 자주 확인하면 사용량이 빨리 닳고, 드물게 다가오면 클레어 보의 말처럼 사용자가 존재를 잊어요. 앤트로픽도 메시지를 보낼 시점은 테스터 의견을 받아 계속 다듬고 있다고 밝혔습니다.

알림이나 추천처럼 사용자에게 먼저 다가가는 기능을 만드는 프로덕트 메이커라면 같은 질문을 마주합니다. 무엇은 바로 알리고 무엇은 미뤄도 되는지, 어떤 일은 반드시 사람에게 확인받아야 하는지요. 클로드 듀엣이 승인받을 일과 승인해도 하지 않을 일을 나눠둔 방식은 그 기준을 정할 때 참고해볼 만합니다.

<출처: Steve Krouse, What Shall I Teach My Son?>

3. 적용해볼 것: AI 시대에 아이에게 무엇을 가르쳐야 할까, 해커뉴스 댓글 600여 개가 내놓은 답

클라우드에서 코드를 바로 실행하는 서비스 Val Town을 만드는 개발자 스티브 크라우스(Steve Krouse)가 10월 19일 짧은 에세이를 올렸습니다. 제목은 What Shall I Teach My Son?, 아들에게 무엇을 가르쳐야 할까입니다. 크라우스는 곧 첫 아이를 맞을 예정이라고 해요. 예전에 아이들에게 코딩을 가르치는 방과 후 프로그램까지 세웠던 사람이지만, 정작 자기 아이에게 무엇을 가르쳐야 할지는 혼란스럽다고 털어놓습니다. 그동안 돈을 벌어온 기술인 프로그래밍이 갑자기 덜 가치 있게 느껴진다는 거예요.

그래서 크라우스는 아이에게 무엇을, 무엇을 위해 가르쳐야 할지 묻습니다. 해커뉴스에서는 이 글이 추천 470개를 넘겼고, 댓글도 600개 넘게 달렸습니다.

크라우스는 어떤 고민을 했나요?

크라우스는 1995년에 나온 닐 포스트먼의 책 『교육의 종말』을 다시 읽으며 생각을 정리합니다. 먼저 기술이 학교를 바꿀 거라는 예측이 계속 틀려왔다는 이야기부터 꺼내죠. 1913년 에디슨은 학교에서 책이 곧 쓸모없어지고 10년 안에 학교가 완전히 바뀔 거라고 했습니다. 크라우스 자신도 2013년에는 온라인 공개 강좌(MOOC)가 교육을 뒤집을 거라고 내다봤지만, 그렇게 되지 않았습니다.

학교가 오래 살아남은 이유도 짚습니다. 하버드나 예일 같은 대학은 원래 성직자를 기르려고 세워졌는데, 종교의 힘이 약해진 뒤에도 학교는 남았습니다. 겉으로 내세운 목적이 바뀌어도 기부금과 명성, 그리고 부모가 일하는 동안 아이를 맡길 곳이 필요하다는 현실이 학교를 지탱해왔다는 겁니다. 그래도 크라우스는 이번엔 다르지 않을까 하는 의문을 떨치지 못합니다.

크라우스를 가장 흔들어 놓은 건 두 가지입니다. 하나는 그가 예전에 교육의 목적을 한 단어로 꼽으며 고른 말, 리소스풀(resourceful)이에요. 주어진 자원으로 문제를 찾아내 풀 줄 아는 사람이라면 더는 학교에 다닐 필요가 없다고 봤는데, 지금은 AI 에이전트가 바로 그 일을 해내고 있다는 겁니다. 다른 하나는 생계를 꾸리는 능력이에요. 교육의 여러 목적 가운데 이 능력이 자신에게 얼마나 중요했는지, 흔들리기 시작하고 나서야 알았다고 합니다.

결론은 정답이 아니라 태도입니다. 무엇을 가르치느냐보다 어떻게 가르치느냐가 중요하다고 보고, 아이에게 무언가를 해주기보다 아이와 함께 하겠다고 해요. 교육의 목적도 아이와 함께 찾아가겠다며 글을 맺습니다. 마지막 문장은 "행운을 빌어주세요"였습니다.

해커뉴스 독자들은 어떻게 답했나요?

댓글 대부분은 글을 평가하기보다 저마다 자기 답을 내놓았습니다. 개발자가 많은 커뮤니티의 반응이라는 점은 감안하고 보면 좋겠습니다.

가치관을 가르치자: 친절, 공감, 다른 사람을 존중하는 태도처럼 사람됨을 꼽은 답이 많았습니다.
배우는 힘을 가르치자: 호기심과 비판적 사고, 적응력이 자주 나왔어요. 크라우스가 꼽은 리소스풀에 호기심과 의심하는 태도를 더하자는 댓글도 있었고, 서른 살 안팎의 자녀를 둔 한 부모는 좋은 질문을 던지는 법을 익히게 하라고 권했습니다.
몸으로 하는 기술을 가르치자: 집안 배선, 목공, 배관, 타이어 점검 같은 손기술이 오래간다는 답이 많았어요. 타고난 몸만큼은 바꿀 수 없으니 백플립을 가르치라는 농담 섞인 답도 있었습니다.
인문학으로 돌아가자: 스스로 생각하고, 자기 생각을 설득력 있게 표현하는 힘이 앞으로 더 중요해질 거라는 의견입니다.

가장 많은 답글이 달린 댓글은 질문의 전제부터 다르게 봤습니다. 부모와 할아버지, 삼촌까지 모두 정비공이었지만 정작 자신은 정비를 거의 모른다며, 아이는 부모와 다른 사람이고 자기 길을 스스로 찾을 거라고 했어요. 부모가 할 일은 가치관과 좋은 판단을 내릴 힘을 길러주는 것이지, 20년 뒤를 예측해 진로를 정해주는 게 아니라는 거죠.

해커뉴스에서 가장 많은 답글이 달린 댓글 <출처: Hacker News>

다른 시각도 있었습니다. 이런 답들이 AI가 얼마나 빨리 좋아질지를 과소평가한 자기 위안이라는 반론이 나왔고, 정보에 접근할 수 있다고 해서 교육받은 건 아니라며 학교와 교사의 역할은 그대로라는 의견도 있었습니다. 학교의 진짜 역할은 아이를 돌보는 데 있다는 댓글은, 크라우스가 학교가 살아남은 이유로 꼽은 현실과 겹칩니다.

무엇을 생각해볼 수 있을까요?

첫째, 크라우스가 교육의 목적이라고 여겼던 리소스풀, 곧 자원을 잘 활용하는 능력은 지금 프로덕트 메이커가 일하는 방식이기도 합니다. 검색하고, 도구를 골라 쓰고, 필요한 자료를 모아 문제를 푸는 일이요. 공교롭게도 앤트로픽도 이번 주 클로드 듀엣을 소개하며, 자원을 잘 활용해 일하도록 만들었다고 설명했습니다. 도구를 잘 다루는 능력 자체가 AI의 일이 되어가고 있다면, 내 일에서 남는 부분이 무엇인지 따져볼 때입니다.

둘째, 해커뉴스의 답이 한 방향으로 모이지 않았다는 점도 눈여겨볼 만합니다. 가치관, 배우는 힘, 손기술, 인문학까지 답이 갈렸고, 질문 자체를 되묻는 사람도 있었어요. AI가 무엇을 대신할지 예측하기보다, 어떤 상황에서도 쓸모 있는 것을 찾으려는 답이 많았습니다.

셋째, 크라우스가 고른 방법은 목적을 정해서 내려주는 대신 함께 찾는 것입니다. 팀에도 같은 방식을 적용해볼 수 있어요. AI 도입으로 일하는 방식이 바뀔 때, 무엇을 지키고 무엇을 바꿀지 팀원과 함께 정하면 더 오래가는 기준을 세울 수 있습니다.

적용해볼 수 있는 것

내 일 중에서 "필요한 자료를 찾아 도구로 처리하는" 부분과 "무엇을 할지 정하는" 부분을 나눠 적어보세요. 앞쪽부터 AI에게 맡겨볼 수 있습니다.
해커뉴스 답 중 하나를 골라 내 일에 대입해보세요. 예를 들어 좋은 질문을 던지는 법이라면, 이번 주 회의에서 내가 던진 질문을 다시 적어보는 식입니다.
팀에서 AI 도입을 이야기할 때, 도구 이야기 전에 우리 일의 목적이 무엇인지부터 함께 적어보세요.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

이 글은 AI의 도움을 받아 작성했습니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

[AX일지]재고 안 맞는 유통사에서 AI가 할 수 있는 것

Editor's note

요즘IT가 〈AX일지〉를 연재합니다. AX는 지금 가장 뜨거운 말이지만, 현장에서 실제로 어떤 고민 끝에 무엇을 제안했고 무엇이 되고 무엇이 안 됐는지까지 밝힌 기록은 드뭅니다. 그 자리를 채워 보자는 취지에 위시켓 AIDP가 공감해 함께 기획했습니다. 위시켓 AIDP는 위시켓의 AX 사업부입니다. 진행 중인 프로젝트의 판단을 결론이 나기 전에 공개하고, 결과가 나오면 잘된 것과 안된 것을 함께 싣습니다.

이 시리즈는 한 회사의 손익이 실제로 달라질 때까지의 여정을 기록합니다. 필자는 현장에서 고객의 이야기를 듣고 실제 구축을 돕는 AIDP의 FDE(Forward Deployed Engineer)들입니다. 고객사 특정을 막기 위해 업종 특성과 규모는 일반화했고, 대화는 취지를 살려 재구성했습니다.

[AX일지]③ 재고 안 맞는 유통사에서 AI가 할 수 있는 것
: 유통사 AX, AI 발주 예측보다 재고 장부를 먼저 맞춘 이유

구두를 파는 회사가 백화점 안에 매장을 냈습니다. 손님이 구두 한 켤레를 사면 매장 직원은 계산대 단말기로 결제를 받는데, 그 단말기는 구두 회사 것이 아니라 백화점 것입니다. 그래서 무엇이 팔렸다는 기록은 백화점 컴퓨터에만 남고, 구두 회사 장부에는 저절로 들어오지 않습니다.

매장 직원은 그 기록을 회사 장부에 다시 입력해야 합니다. 그래야 회사가 무슨 물건을 얼마나 팔았는지 알 수 있으니까요. 그런데 그 장부가 본사가 보는 장부, 직원이 직접 관리하는 장부, 대표 보고를 위한 장부처럼 목적에 따라 나뉘어 있습니다. 직원은 같은 판매 한 건을 다섯 군데에 입력해야 합니다.

구두 한 켤레가 팔리면 백화점 단말기에 찍히고, 매장 직원은 그것을 회사 장부 다섯 군데에 다시 적습니다. 그래도 실제 재고가 몇 켤레인지는 아무 데도 없습니다. <출처: 요즘IT>

매장만 그런 게 아닙니다. 본사에서도 물건을 주문하고, 받고, 매장으로 보내고, 판 기록이 약 10개 도구에 흩어져 있습니다. 재고는 이 기록을 전부 더하고 빼야 나오는 숫자라, 지금 재고가 얼마인지 한 번에 답하는 곳은 어디에도 없습니다.

최근 AX 프로젝트를 함께 진행하고 있는, 해외 구두 브랜드를 수입해 파는 유통사의 이야기입니다. 이 회사는 AX를 어디서부터 시작해야 할까요?

의뢰는 자사몰, 바람은 재고

아홉 곳의 매장에서 판매하고, 본사 다섯 명이 그 아홉 곳을 관리하고 운영하는 회사입니다. 대표님이 원한 건 실제 재고와 신고한 재고를 맞춰서 그 데이터를 기반으로 정확히 세금을 내는 것이었습니다. 직원들은 매장마다 흩어진 판매 기록을 자동으로 모으거나 발주 관리를 쉽게 할 수 있기를 바랐습니다. 다만 그 바람이 저희에게 도착했을 때의 모양은 ‘자사몰을 바꾸고 싶다’는 의뢰였습니다.

진단을 해 보니 자사몰을 바꾼다고 그 바람이 이뤄지지는 않았습니다. 대표님과 직원들이 원하는 일들은 전부, 지금 재고가 몇 켤레인지 누가 언제 봐도 같은 답이 나오는 장부 하나가 있어야 시작할 수 있는 일이었기 때문입니다. 그래서 저는 자사몰만 바꾸는 대신, ERP 한 곳에 필요한 재고 정보를 체계적으로 모을 수 있도록 만드는 일부터 하자고 했습니다. 그래야 AI가 그 ERP 위에서 다양한 자동화를 하고, 누구나 그 결과물을 믿을 수 있게 되죠.

이 회사뿐 아니라 유통사 프로젝트를 하다 보면 이와 비슷한 일이 많이 벌어집니다. 유통사들은 정확한 재고를 확인하기 어렵거나 자사몰에서 상품 관리가 어려울 때 ERP나 자사몰 개편을 고려하고는 하고, 최근에는 AI 도입까지 더해졌습니다. 요청의 모양은 다르지만 그 밑에 있는 문제는 대개 같습니다. 재고가 안 맞는다는 것입니다.

그래서 이 글에서는

재고는 왜 그렇게 안 맞는지
안 맞는 재고 위에 AI를 올리면 왜 안 되는지
그리고 AI는 이런 회사에서 실제로 무슨 일을 할 수 있는지

이 세 가지를 이 회사의 이야기로 풀어 보겠습니다.

결론부터 말씀드리면, 지금 이 회사에서 AI가 하는 일은 두 가지입니다. 이 회사를 진단하기 위해 각종 기록을 읽는 일, 그리고 입고 물품을 검수할 때 박스 사진의 글자를 읽어 수량을 맞춰 보는 일입니다. 새 ERP로 재고를 누구나 한눈에 파악할 수 있게 되면 그때부터 AI로 할 수 있는 일이 늘어나죠. 여기에 본사 다섯 명이 반복되는 업무를 하나씩 봇으로 만들 수 있도록 AI 교육도 함께 진행하기로 했습니다.

글쓴이 안재훈 · 위시켓 AIDP 파트장 <출처: 요즘IT>

재고가 안 맞는 이유 세 가지

인터뷰와 매장 실사를 거치며 저는 이 회사의 재고가 안 맞는 이유를 찾아 크게 셋으로 나눴습니다.

재고가 장부에 아예 없기 때문에
같은 재고를 사람마다 다르게 세기 때문에
그리고 들어오기도 전에 팔리고 값도 모르기 때문입니다.

장부에 아예 없는 재고

이 회사는 ERP를 회계용 재고 장부로 씁니다. 그래서 자산으로 잡는 구두만 품목으로 등록해 두었고, 액세서리와 슈케어 용품, 샘플 같은 잡화는 ERP에 등록하지 않았습니다. 이 잡화들은 특별한 이유가 있어서라기보다는 자산으로 할지 결정하지 않아 등록하지 않았을 뿐이었습니다. 그동안 잡화는 구글시트로만 셌고, 한 케어용품은 장부와 실물이 약 2천 개 다릅니다.

불량인 상품과 손님에게 서비스로 드리는 것도 따로 세지 않았습니다. 본사 창고는 정기 전수조사 없이 전표를 더하고 빼서만 추적했죠. 매장 진열용으로 나간 구두는 한 창고로 몰아 넣어 어디에 뭐가 있는지 모릅니다. 담당 팀장님은 이걸 십 년 동안 정리되지 않은 재고라고 했습니다.

세는 사람마다 다른 재고

앞서 판매 한 건을 다섯 군데에 기록한다고 했죠. 회사가 공식적으로 재고를 기록하는 ERP, 매장 직원이 직접 관리하는 매장 재고 엑셀, 백화점 단말기 금액과 맞춰 보는 수기 판매 장부, 매일 저녁 대표님에게 가는 마감 보고, 그리고 ERP에 없는 물건까지 세는 구글시트, 이렇게 다섯 곳입니다.

판매 한 건이 기록되는 곳. 백화점 단말기는 회사 밖에 있고, 회사 안의 다섯 곳에는 사람이 옮겨 적습니다. 반품이면 다섯 곳을 거꾸로 고칩니다. <출처: 요즘IT>

장부마다 매출을 세는 기준도 다릅니다. 장부를 보는 사람이 다르고, 그 사람의 일에 필요한 시점이 다르기 때문입니다. 이 회사에서는 같은 달의 매출이 네 가지로 나옵니다. 발주를 정하는 팀장님의 보고서는 손님이 주문한 날, 재고를 빼는 ERP는 물건이 나간 날, 백화점 온라인몰은 고객에게 배송이 끝난 날을 기준으로 잡고, 세무사에게 가는 계산서는 각종 수수료를 뺀 금액으로 잡습니다.

계산이 틀린 사람은 없습니다. 각자 자기 일에 필요한 기준으로 셀 뿐입니다. 그런데 회사 안에서 언제를 매출로 볼지 정해 두지 않으면, 장부마다 답이 다른 채로 굴러갑니다. 팔린 구두가 언제 장부에서 빠지느냐가 다르니, 월말에 남은 구두가 몇 켤레인지도 장부마다 달라집니다.

어느 매장에서 팔리느냐에 따라서도 다릅니다. 백화점 매장 여섯 곳에서는 백화점 명의로 판매되기에 수수료를 뺀 금액이 이 회사 매출이 되고, 다른 매장 세 곳은 이 회사 명의로 판매되므로 판매 총액이 곧 매출입니다. 이걸 한 장으로 정리한 적이 없어서, 매장에서 영수증을 아홉 장 받아 놓고서야 제가 정리할 수 있었습니다.

들어오기 전에 팔리고, 값도 모르는 재고

물건이 실제로 창고에 들어오기 전에는 ERP에 기록되지 않습니다. 하지만 구글 시트에는 입고 예정인 물건이 먼저 기록되죠. 매장에 손님이 찾는 사이즈가 없으면 직원은 이 시트를 보고 “다음 주에 들어옵니다” 하고 미리 결제를 받습니다. 하지만 그렇게 되면 ERP에는 없는 물건을 판 것으로 적혀 재고가 0보다 작아집니다. 아직 들어오지 않은 재고를 ERP가 다루지 못하면 이런 마이너스는 어느 회사에서나 생깁니다.

수량이 맞는다 해도 금액이 안 맞습니다. 이 회사는 해외 물건을 수입하기 때문에 원가가 환율에 영향을 받습니다. 그런데 이 환율은 실제 송금한 환율이 아니라 대략 어림잡아 설정한 환율이고, 거기에 어림잡은 운송비를 더한 값이 원가가 됩니다. 수입하는 회사는 환율과 운송비가 확정되기 전에 물건이 먼저 들어오는 일이 많아 흔한 구조입니다.

그래서 해마다 법인세를 낼 때 신고하는 재고가 실제로 센 값이 아니라 대략치였습니다. 대표님 스스로 대부분의 회사가 실제 재고를 반영하고 있지는 않다고 하셨고, 저도 그 말이 맞다고 생각합니다. 이 회사 대표님은 그걸 맞추고 싶어 했습니다.

왜 AI보다 재고가 먼저였나

물론 이 회사도 AI 도입을 생각하고 있었습니다. 팀장님은 과거 판매 데이터로 다음 발주 수량을 예측하는 일, 채널마다 흩어진 판매 기록을 모으는 일, 단순한 문의를 챗봇으로 받는 일 등을 AI로 하고 싶어 했죠. 팀장님 자신은 이미 엑셀을 클로드에 연결해 판매 분석 리포트를 만들고 있었고, 마케팅 담당 대리님은 쇼핑몰에 상품을 등록하는 반복 작업을 클로드에게 시켜 두었습니다.

그런데도 저는 AI보다 재고가 먼저라고 봤습니다. 발주를 예측하거나 판매를 취합하려 해도 회사의 모든 구성원이 동일하게 취급하고 신뢰하는 재고 데이터가 있어야 가능하기 때문입니다.

재고·판매·입고 예정이 한 표에 있어야 AI가 발주 준비, 판매 취합, 재고 요청을 거들 수 있습니다. 실제 화면이 아니라 설명을 위해 만든 그림입니다. <출처: 요즘IT>

발주 예측은 재고·판매·입고 예정이 한 표에 있어야 다음 달 수량을 계산할 수 있는데, 이 데이터가 여러 곳에 나뉘어 있고 액세서리는 등록된 것조차 없습니다. 판매 취합도 마찬가지입니다. 앞에서 본 대로 언제 매출로 잡느냐가 곧 언제 재고에서 빠지느냐이기 때문입니다.

매출도 넷, 재고도 넷인 회사에서 AI가 판매 기록을 자동으로 모으면 기계가 넷 중 하나를 마음대로 고르고, 남은 재고도 그 선택을 따라가게 되죠. 그 결과물을 아무도 믿지 못하니 아무것도 해결되지 않는 겁니다.

그래서 킥오프에서 AI 예측은 이번 범위에서 뺐습니다. 재고가 정리된 뒤에야 방향이 보이기 때문입니다. 대신 이 프로젝트가 잘됐는지는 발주 준비나 입고 검수, 판매 취합, 재고 요청 처리 등의 시간을 단축하는 것을 목표로 했습니다. 지금 걸리는 시간을 재 두었고, 끝날 때 다시 실측해 비교합니다. AI를 쓰든 안 쓰든 현재 ERP를 새로 만들면서 해결해야 할 문제들이고, 당초 AI로 줄일 수 있을 거라 기대했던 영역이기도 하죠.

재고가 맞으려면 먼저 정해야 하는 것

구성원 모두가 신뢰할 만한 하나의 재고 데이터를 만들려면, 그것을 담을 시스템이 있어야 합니다. 그 시스템이 이번에 새로 만드는 ERP입니다. 지금처럼 회계용 재고 장부로만 쓰는 ERP가 아니라, 물건이 들어와서 매장으로 가고 팔려 나가기까지 재고가 움직이는 일을 전부 담는 ERP입니다. 그런데 이를 만들려면, 회사가 먼저 정해줘야 하는 것들이 있습니다.

가장 큰 것이 매출을 언제 잡을 것인가입니다. 앞에서 본 것처럼 이 회사에는 매출이 넷이었는데, 시스템은 그중 하나를 골라 주지 못합니다. 어느 날을 고르느냐에 따라 이번 달 매출도, 월말에 남은 재고도 달라지니 회사가 골라야 합니다. 백화점 명의로 팔린 것과 이 회사 명의로 팔린 것을 어떻게 나눠 적을지, 악세사리와 샘플과 진열품을 재고 자산에 넣을지도 같은 종류의 질문입니다. 넣기로 하면 회사 재고 금액이 그만큼 늘고 세금 신고도 달라집니다. 원가를 어느 환율로 계산할지까지도 저나 시스템, AI가 대신 정할 수 없죠.

그래서 이런 것들은 대표님이 정할 목록으로 따로 뽑았습니다. 원가부터 대표님과 이야기해 답을 냈습니다. 실제 송금한 환율에 그 입고분의 운송비 평균을 더해 켤레마다 붙이기로 했습니다.

그다음은 회사가 발주부터 정산까지 쓰는 약 10개의 도구를 두 가지 종류로 나눌 필요가 있었습니다. 입고 예정인 품목을 확인하기 위해 존재하는 시트나 수기 판매 장부 등은 회사에서 필요로 하는 기록이지만 현재 ERP가 담지 못하는 것들이었습니다. 그래서 외부 도구를 사용하던 것이죠. 이런 것은 새로운 시스템에 올리기로 했습니다.

회사 기록인데 지금 ERP가 못 담아 밖으로 샌 것은 새 ERP에 올리고, 남의 시스템은 파일을 올리고 내려받는 접점으로만 남깁니다. 설명을 위해 만든 그림입니다. <출처: 요즘IT>

반대로 해외 본사와 주고받는 이메일, 백화점 단말기에 따른 전산, 택배사 접수 양식, 세무사의 장부 등 외부 협력 업체와 관련된 기록은 내부에 들이기 어렵습니다. 대표적으로 백화점 단말기를 찍으면 백화점 전산에 찍히는 것을 내부화하기는 어렵겠죠. 택배사 접수 양식이나 세무사 장부도 협업사 양식에 맞춰야 합니다. 이런 종류의 일은 내부 ERP에 담지 않고, 파일을 올리고 내려받는 접점으로만 남기기로 했습니다.

그리고 새 ERP에 재고를 처음 올리는 날, 이 회사 직원들이 창고와 매장의 재고를 한 번 전부 셉니다. 지금 장부의 숫자를 그대로 옮기면 틀린 숫자로 시작하기 때문입니다. 백 개인 줄 알았던 것이 여든 개면 스무 개는 어디서 싸게 팔았거나 버렸다고 적어야, 그날부터 회계와 재고가 같은 숫자에서 출발합니다. 팀장님은 이 전수조사를 숙원이라고 했습니다.

그러면 AI는 언제 무엇을

앞에서 말씀드린 것처럼 지금 AI가 하는 일은 이 회사를 진단하기 위해 각종 기록을 읽는 일, 그리고 입고 물품을 검수할 때 박스 사진의 글자를 읽어 수량을 맞춰 보는 일입니다. 박스 사진 검수는 이 글에서는 자세히 밝히지 않았지만, 지금 정확도를 테스트하는 중이고 최종 확정은 여전히 사람이 합니다.

이제 새로운 ERP를 통해 재고를 누구나 한눈에 파악할 수 있게 되면, 그때부터 AI가 할 수 있는 일이 생깁니다. 지난 판매와 남은 재고를 보고 다음 달 발주 수량을 제안하는 일, 채널마다 흩어진 판매를 한 표로 모으는 일, 재입고를 기다리는 손님에게 알리는 일, 매장이 본사에 보내는 재고 요청에 답하는 일입니다. 팀장님이 처음에 AI로 하고 싶다던 일들이 그대로 이 목록에 있습니다. 무엇을 먼저 할지는 ERP가 자리 잡은 뒤에 이 회사에 가장 이익이 되는 것부터 다시 정하기로 했습니다.

한편 본사 다섯 명이 AI로 자신의 일을 수행할 수 있도록 교육도 하기로 했습니다. 상품 등록을 자동화해 사용하고 있던 대리님처럼 다른 분들도 반복되는 업무를 하나씩 봇으로 만들 수 있게 합니다.

<출처: 요즘IT, ChatGPT로 제작>

물건을 받아 하나씩 확인하는 일은 지금도 사람이 합니다. 매일 쓰는 사람이 시스템을 스스로 고칠 수 있어야 그 가치가 유지됩니다.

이걸 함께 하기로 한 이유는시스템은 만든 날이 아니라 쓰이는 날부터 가치가 생기기 때문입니다.저희는 시스템을 만들어 넘기고 떠나는 게 아니라, 만든 것이 회사 업무 안에서 매일 돌아가게 하는 것까지를 일로 봅니다. 저희는 이걸 운영형 AX라고 부릅니다. 그러려면 매일 쓰는 사람이 스스로 고치고 늘려 갈 수 있어야 하고, 교육이 그 일을 합니다.

제가 인터뷰를 정리하고 진단 문서를 쓰는 동안 이 회사 직원 분들도 가만히 계시지 않았습니다. 스스로 업무 흐름을 그려 두고 계실 만큼 의욕적이었습니다. 언젠가 담당 팀장님이 말했습니다. 직원들이 이제 우리가 뭘 해야 하냐고 묻고 있었다고, 빨리 와서 요청해 달라고요.

AX는 저 혼자 하는 일이 아닙니다. 고객사가 함께 움직여야 하는데, 이 회사는 저보다 한발 앞서 있었습니다. 그래서 문서로 범위를 미리 확정하기보다, 80%쯤 완성된 ERP 실물을 미리 드리기로 했고요, 2주 동안 써보시면서 확정하기로 했습니다. 직원 분들께서 의욕적인 만큼 저도 기대되는 프로젝트입니다.

마치며

재고가 안 맞는 회사에 AI를 올리면 안 맞는 재고를 빨리 보여 줄 뿐입니다. 이는 매출과도 연동되고요. 회사의 구성원이 누구나 조회하고 활용하고 신뢰할 수 있는, 물건의 흐름을 보여주는 ERP가 그래서 먼저 필요했습니다. 자사몰 개편보다도 중요했던 이유고요.

AX가 AI를 도입하는 일이라면 이 글은 AX일지가 아닙니다. 그런데 저는 제가 이 글에서 다룬 일을 AX라고 부릅니다. 저희 회사는 고객사의 AX 성숙도를 다섯 레벨로 나누고 진단에 활용하는데요. 정식 판정 전이기는 하지만, 현재 이 회사의 재고·물류 영역에서 관찰한 장면은 기록이 어디서나 같은 값을 갖는 Lv1(데이터 정합)에 못 미쳤고, 업무가 사람의 머릿속과 카톡에서 도는 Lv0(암묵 운영)에 가까웠습니다.

위시켓 AX 성숙도 모델(v1.0)의 다섯 레벨. 이 회사의 재고·물류 영역은 Lv0에 가깝고, 새 ERP가 Lv1과 Lv2를 만듭니다. Lv0에서 Lv3로 바로 건너가는 다리는 없습니다. <출처: 요즘IT>

새 ERP가 하는 일은 이 영역을 Lv1로, 그리고 일이 흐르는 경로가 시스템에서 보이는 Lv2(프로세스 정형)로 올리는 일입니다. AI가 업무를 거드는 단계인 Lv3(지능 보조 운영)는 그 앞 단계를 달성해야 실행할 수 있습니다. 한 단계를 건너뛰면 AX는 어렵다고 생각합니다. 그래서 당장 AI를 도입하기보다 회사에 필요한 것을 찾아 단계별로 해결해 나가는 것이 AX라고 생각합니다. 이 글이 AX일지인 이유입니다.

인터뷰에서 팀장님이 하신 말이 기억에 남습니다. “입점 제안은 많이 들어오지만 다 거절하고 있어요. 결국 할인 싸움이거든요. 저희는 그 싸움을 안 하고 싶어서요.” 원칙과 자부심을 바탕으로 일하는 모습에서 저도 영감을 받았습니다. 그래서 이 프로젝트가 꼭 잘 되면 좋겠습니다. 이 회사는 이번 프로젝트로 AX의 과정에 올라섰다고 생각합니다. 실제로 손익이 달라지는 것을 볼 때까지 좋은 결과를 만들어가고 싶습니다. 그리고 결과가 나오면 다음 글에 적겠습니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

"이 자료 넣어도 될까?" 엄격한 보안 환경에서 도구를 만드는 일

내가 일하는 자리의 PC는 회사 보안 환경 안에 있다. 외부 프로그램을 함부로 설치할 수 없고, 파일을 올려 처리하는 온라인 서비스도 쓸 수 없다. 첫 글에서 서명 검사 도구를 만들 때 이 제약을 잠깐 적었는데, 그때는 도구 이야기가 먼저라 제약은 배경으로만 지나갔다.

이번 글은 그 배경을 앞으로 꺼낸다. 넉 달 넘게 AI로 도구를 만들고 그 도구 이야기를 글로 쓰는 동안, 나는 매번 같은 질문 앞에 섰다. 이 자료를 AI 도구에 넣어도 되는가? 처음부터 원칙이 있었던 건 아니다. 부딪힌 지점에서 그때그때 선을 그었다. 그래서 이 글은 원칙 목록으로 시작하지 않는다. 선이 어떻게 그어졌는지 그 장면을 순서대로 적고, 마지막에는 그 선들을 모아 정리해 보았다.

우선 이 글에 적는 기준은 내가 처한 환경에서 나온 기준이라는 점을 먼저 밝힌다. 조직마다 규정이 다르고, 규정이 있으면 규정이 개인의 판단보다 먼저이기 때문이다. 이 글은 그 규정 위에서 실무자 한 사람이 어디에 선을 그었는지에 대한 기록이다.

미리 요점만 콕 집어보면?

외부 프로그램 설치가 제한되고 온라인 서비스를 쓸 수 없는 보안 환경에서 넉 달 넘게 자동화 도구를 만들었다. 원칙을 먼저 세우고 시작하지 않았다. 부딪힌 장면마다 선을 하나씩 그었다.
인터넷 없이 도는 검사기를 만들면서는 선을 지키는 데도 비용이 든다는 것을 배웠고, 결국 그 비용 때문에 두 달 만에 손을 놓았다. 강의 자리에서 개인정보를 걱정하는 질문을 받고서야 내 기준에 빠진 자리를 봤다. 자료를 고르는 기준은 있었는데, 그 자료를 받는 도구의 설정은 한 번도 열어 본 적이 없었다.
선이 늘 같은 자리에 있었던 것도 아니다. 어떤 문서는 온라인 서비스에 한 번도 올리지 않았고, 어떤 문서는 이미지로 바꿔 AI에게 읽혔다. 그 둘의 차이를 설명할 수 있게 되는 것이 내가 말하는 선이다.

도구와 글에서 그어 온 선을 한 장으로 정리했다. 실제 화면이 아닌 재구성 도식 <출처: 작가, 클로드로 생성>

첫 도구에서 그어둔 선

내가 만든 첫 도구는 매달 마감 때 올라오는 400페이지가 넘는 점검 문서에서 서명 누락을 찾는 것이었다. 그 도구를 어떻게 만들었는지는 첫 번째글에 자세히 나와있으니 다시 다루진 않는다. 대신 이 글에서 필요한 건 한 가지다. 그 도구는 인터넷 없이 돌도록 만들었고, 원본 점검 문서를 온라인 서비스에 올린 적은 한 번도 없다는 것이다.

처음부터 그럴 생각은 아니었다. 파일을 열어 몇 번 부딪히고 나서야 길이 하나로 좁아졌다. 글자를 검색할 수 없었고, 글자를 읽어 주는 프로그램은 함부로 설치할 수 없었다. 파일을 올려 처리하는 서비스 역시 쓸 수 없었다. 세 번째가 특히 분명했다. 그 문서에는 시스템마다 표지가 한 장씩 있고, 그 표지마다 두 사람의 서명과 날인이 들어 있었다. 결국 개인정보다.

그때 알게 된 게 하나 있다. 나중에 결과물에서 이름을 지우겠다는 다짐은 방어가 되지 못한다. 지우는 일은 자료가 이미 나간 다음에 하는 일이기 때문이다. 그래서 두 번째 도구부터는 순서를 바꿨다. 무엇을 넣을지 고르기 전에, 이 작업에서 자료가 회사 밖으로 나가는 지점이 어디인지부터 봤다. 첫 선은 그렇게 그어졌다.

인터넷 없이 돌게 만든 검사기, 그리고 선의 비용

지난 6월에는 오타 검사기를 만들었다. 회의록과 보고서를 제출하기 전에 오타와 띄어쓰기를 처음부터 끝까지 눈으로 훑는 일이 매주 있었다. 밖에서라면 온라인 맞춤법 검사에 붙여 넣으면 끝나는데, 내 자리에서는 그 화면이 열리지 않는다. 그래서 인터넷 없이 도는 것을 직접 만들었다.

띄어쓰기는 한국어 형태소 분석기 Kiwi로 처리했고, 오타는 내가 관리하는 사전으로 잡았다. 도구가 도는 동안 바깥과 통신하는 곳은 한 군데도 없게 만들었다. 사전은 자주 틀리는 표기 94개로 시작했다. 그중 86개는 자동으로 고치고, 로서와 로써, 결재와 결제처럼 문맥에 따라 답이 갈리는 8개는 자동으로 고치지 않고 확인 필요로만 표시하게 했다. 도구가 멋대로 고쳐서 생기는 사고가 더 무서웠기 때문이다.

처음 돌렸을 때는 잘 됐다. 오타를 넣은 문장은 잡아냈고, 정상 문장에서 잘못 잡는 게 없는지도 확인했다. 그런데 지난 글에 쓴 도구 전체 실사에서, 이 검사기는 안 쓰는 도구로 분류됐다. 만든 지 두 달이 채 되지 않았을 때다.

이유를 되짚어 보니 도구가 틀려서가 아니었다. 온라인 검사기는 사전을 남이 갱신해 준다. 검사기를 선 안쪽에 두려니 그 94개를 내가 들고 있어야 했다. 회의록에 자주 나오는 시스템 이름을 도구가 띄어쓰기 오류로 고쳐 놓곤 했다. 그때마다 교정본에서 그 자리를 되돌리고, 사전에 손을 댔다. 문서가 바뀌면 손볼 곳도 늘었다. 그 손질이 검사로 아끼는 시간보다 커지는 순간부터 열지 않게 됐다.

이 도구를 이 글에서 성공 사례로 쓸지 실패 사례로 쓸지 정해야 했다. 실패 사례로 쓴다. 다만 무엇이 실패했는지는 정확히 적어 두고 싶다. 선은 지켜졌다. 검사기 때문에 제출 문서가 밖으로 나간 일은 없었다. 실패한 것은 선을 지키는 비용을 계산에 넣지 않은 것이다. 밖에서 공짜로 받던 사전 갱신을 안에서는 내가 직접 해야 했는데, 만들 때 그 손이 얼마나 가는지를 세지 않았다. 그래서 두 번째 선은 이렇다. 선 안쪽에 두기로 했다면, 밖에서 받던 것 중 무엇을 내가 대신 들어야 하는지를 만들기 전에 센다.

남이 물어봐 주기 전까지

지난 8월에는 옆 프로젝트의 두 사람에게 한 시간짜리 강의를 했다. 그날 한 분이 개인정보 이야기를 꺼냈다. 영화에 나오는 것처럼 AI가 자기 정보를 가져가면 어떻게 되느냐는 것이었다. 그날 받은 질문은 그 강의를 다룬 글에 적었으니 여기서 되풀이하지 않는다. 이 글에 적을 것은 그 질문이 내게 남긴 자리다. 답을 하고 돌아와서야 알았다. 나는 자료를 넣을지 말지를 넉 달 동안 매번 판단해 왔는데, 그 자료를 받는 도구가 자료를 어떻게 다루는지는 확인한 적이 없었다. 계정에 그런 설정 화면이 있다는 것을 알면서도 한 번을 열어 보지 않았다.

두 사람이 물은 것과 내가 판단해 온 것이 다른 질문이라는 것도 그때 알았다. 두 사람이 물은 것은 이 도구가 안전한가였다. 내가 판단해 온 것은 이 자료를 넣어도 되는가였다. 앞의 질문은 설정을 열어 확인하면 답이 나오고, 뒤의 질문은 설정 어디에도 답이 없어 넣기 전에 내가 정해야 한다. 둘 다 필요한데 나는 뒤쪽만 하고 있었다.

혼자 쓸 때는 그 자리가 비어 있는 줄도 몰랐다. 내 손이 지키는 기준은 매번 작동했으니 완결돼 있다고 느꼈고, 빠진 쪽은 물어보는 사람이 없으니 드러날 일이 없었다. 남이 묻고 내가 답하는 자리가 아니었으면 아마 지금도 몰랐을 것이다. 그날 나는 내 설정을 열어 보지 않은 채로 그 자리에 앉아 있었다.

선이 늘 같은 자리에 있진 않았다

여기서 솔직하게 적어야 할 것이 하나 있다. 앞에서 점검 문서는 온라인 서비스에 올린 적이 없다고 썼는데, 모든 문서를 그렇게 다룬 것은 아니다.

출근 기록과 휴가 신청서를 대조하는 도구를 다룬 글에서 나는 두 스캔 문서를 이미지로 바꿔 AI에게 읽혔다고 썼다. 손으로 쓴 오전반차와 연차를 구분해 읽는 일은 코드로는 안 되는 일이었기 때문이다. 그 문서에도 사람 이름이 들어 있다. 같은 사람이 같은 몇 달 안에 한 문서는 넣지 않았고 다른 문서는 넣었다.

점검 문서는 따질 것도 없었다. 종이에 서명하고 날인해 통째로 스캔한 400페이지 넘는 원본을 그대로 넘겨야 했다. 대조 도구 쪽에서 내가 따진 것은 범위와 뒤처리였다. 그달 두 문서만 넣었고, 대조가 끝나면 만들어 둔 이미지 파일을 지웠다. 남긴 것은 어긋난 건을 표시한 결과 화면뿐이다. 다만 지운 것은 내 PC 쪽이고, 받은 쪽에 무엇이 얼마나 남는지는 앞 절에 적은 그 확인을 하지 않은 상태였다.

사실 이 문단을 쓸까 말까 오래 고민했다. 빼고 나면 글은 더 깔끔해진다. 그런데 도구가 지켜야 할 선에 대한 글인데, 애매한 구간을 빼고 쓰면 읽는 사람에게는 지킬 수 없는 기준만 남는다. 물론 아직 이 구간의 답은 확신하지 못한다. 다만 그때마다 넣기 전에 범위를 정하고, 끝나고 지울 것을 정했다는 것. 그리고 그 둘을 말로 설명할 수 없으면 넣지 않았다는 것만은 분명하다.

글에 넣지 않은 것들

글을 쓸 때 그은 선은 도구를 만들 때와는 달랐다. 연재를 시작하고 나서 새로 결정할 것이 생겼다. 도구의 실제 화면을 글에 싣는가.

첫 글에는 결과 화면을 마스킹해서 넣었다. 그런데 담당 매니저가 이미지 자료를 더 넣어 달라고 했다. 경험기는 관련 자료가 많을수록 독자가 맥락을 잡기 쉽다는 이유였고, 맞는 말이었다. 그래서 넉 장을 더 만들었는데, 그중 셋은 실제 화면 대신 형식만 본떠 새로 그린 것이었다. 도구 폴더와 실행 화면, 그리고 도구를 만들 때 오간 대화. 마지막 한 장만 실물을 그대로 썼다. 개인정보가 없는 사용안내 문서였다. 이때 캡션에 재구성이라고 적기 시작했다.

두 번째 글에서는 이미지 여섯 장을 전부 정제본으로 만들었다. 결과 화면을 본뜬 넉 장은 이름을 가명으로 바꾸고, 금액은 예시로 줄이고, 사업명은 가렸다. 출근 기록을 대조하는 도구를 다룬 글에서는 실제 화면의 이름을 홍길동으로 바꿔 그렸다. 지울 것을 정하다 보니 남길 것도 정해졌다. 판정 흐름과 색 구분, 건수, 어긋난 한 건이 화면 어디에 뜨는지는 남겨야 글이 된다.

그러면서 기준이 두 개 생겼다. 하나, 이 화면에서 원본이 유추되는가. 둘, 이 화면 속 사람이 자기 것이라고 알아볼 수 있는가. 둘 중 하나라도 걸리면 지우거나 바꿨다. 그렇게 걸린 것이 실명, 사업명과 기관명, 금액, 시스템 화면 원본이었다. 글 여섯 편의 이미지를 만들며 이 네 가지는 예외 없이 뺐다.

최근에는 한 가지가 더 붙었다. 그전까지는 캡션에 재구성이라고만 적었는데, 이번 연재 기획안을 검토한 매니저가 실제 화면이 아니라는 점까지 캡션에 분명히 적어 달라고 했다. 나는 독자가 실제 화면으로 오인하지 않게 하려는 뜻으로 읽었다. 처음에는 보안과 별개라고 생각했는데, 따져 보니 같은 판단의 마지막 단계였다. 지우는 것만으로는 끝나지 않는다. 지웠다는 사실까지 밝혀야 읽는 쪽의 오해가 없다. 아래 이미지가 그 판단을 그대로 보여 주는 예시다.

[이미지 2] 도구 결과 화면을 글에 싣기 전에 무엇을 지우고 무엇을 남기는지 정리한 예시. 왼쪽과 오른쪽 모두 실제 화면이 아닌 재구성 예시이며, 이름·기관·금액은 전부 가상의 값이다. <출처: 작가, 클로드로 생성>

장면들이 남긴 여섯 줄

장면을 다 적고 나서 선을 모아 봤다. 원칙으로 시작했다면 더 그럴듯한 목록이 나왔겠지만, 실제로 지킨 것은 아래 다섯 줄이다. 마지막 한 줄은 이 글을 쓰면서 새로 보탰다. 넣기 전에 판단한다. 자료가 회사 밖으로 나가는 지점이 어디인지를 먼저 보고, 그 앞에서 결정한다. 나간 뒤에 결과물에서 무엇을 지워도 자료는 이미 나가 있다.

글에 실을 때는 실명, 사업명과 기관명, 금액, 시스템 화면 원본을 예외 없이 뺀다. 도구에 넣을 때는 그 일에 필요한 범위를 넣기 전에 정하고, 끝나면 지운다. 매달 도는 대조 도구에는 그달 두 문서만 넣었고 끝나면 지웠다. 반대로 오래 두고 참고할 자료를 옮길 때는 지우는 대신 처음부터 뺐다. 개인정보가 든 문서와 암호가 걸린 문서는 아예 옮기지 않았다. 애매하면 뺀다.

사내 시스템에 붙는 도구는 회사 PC 안에서만 돈다. 회사 PC 안에서만 돌게 만든 도구가 여덟 개이고, 그중 사내 시스템에 접속해 등록과 수집을 대신하는 것이 여섯 개다. 첫 도구를 그렇게 만든 뒤로 같은 방식을 지켰다.

선을 지키는 비용을 센다. 오프라인으로 두기로 했다면 밖에서 받던 갱신을 내가 대신해야 한다. 그 비용이 아끼는 시간보다 크면, 도구는 만들어 놓고도 열지 않게 된다. 밖으로 내보낼 때는 재구성하고, 재구성했다고 쓴다. 지울 것과 남길 것을 정하고, 그 화면이 실제 화면이 아님을 밝힌다.

그리고 그 질문을 받고서야 알게 된 한 줄을 여기 적어 둔다. 쓰는 도구의 데이터 설정을 한 번은 직접 열어 본다. 자료를 고르는 일만 내 몫인 줄 알았는데, 받는 쪽이 그것을 어떻게 다루는지 확인하는 것도 내 몫이었다.

앞의 다섯 줄은 회사 규정이 허용하는 범위 안에서, 규정이 정해 주지 않는 세부를 내가 정해 지켜 왔다. 마지막 한 줄은 이번에 빠뜨린 것을 알고 적어 둔다.

마치며: 불편함이 경계심으로 바뀌기까지

처음 도구를 만들던 때의 나는 회사 자료를 AI에 넣는다는 말 자체를 불편해했다. 그때는 무엇이 되고 무엇이 안 되는지 몰랐다. 선이 보이자 그 불편함은 경계심으로 바뀌었고, 경계심은 막연한 두려움보다 쓸모가 있었다.

도구를 만들 때마다 선을 하나씩 확인했고, 글을 쓸 때마다 그 선을 한 번씩 시험했다. 앞으로 도구가 늘면 선도 늘 것이고, 검사기처럼 선의 비용을 잘못 계산한 사례도, 남이 물어봐 주기 전까지 모르고 지나는 자리도 또 있을 것이다. 4절에 적은 애매한 구간처럼 아직 답을 못 정한 자리도 남아 있다. 그때마다 이 목록을 고칠 생각이다.

만약 나처럼 엄격한 보안 환경에서 AI 도구를 쓰는 일이 막연히 불안하다면, 원칙부터 세우지 말고 자료 하나를 앞에 놓고 물어보길 권한다. “이게 밖으로 나가면 누가 곤란해지는가.” 그 질문에 답이 나오는 자료부터 선을 그으면 된다. 나는 400페이지가 넘는 점검 문서 한 권에서 시작했고, 그 한 권 앞에서 그은 선을 도구 열다섯 개와 글 여섯 편에서 지켜왔다. 그리고 이 글을 쓰면서 지키기는커녕 적어 두지도 않았던 선이 하나 더 있었다는 걸 깨달았다.

이 글은 AI의 도움을 받아 작성했습니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

제품 출시 전 사용자 대신 디지털 트윈에게 물어보기: ‘august’ 사용기

새로운 기능을 만들 때 가장 어려운 질문 중 하나는 ‘사용자가 정말 이 기능을 원할까?’입니다. 팀 안에서는 필요하다는 의견이 쉽게 모이지만, 실제 사용자가 같은 문제를 중요하게 생각하는지는 별도로 확인이 필요합니다. 가격을 바꾸거나, 랜딩 페이지 문구를 고칠 때도 마찬가지입니다. 출시한 뒤 지표가 떨어지거나, 고객 문의가 쌓인 다음에야 잘못된 가정을 발견하면 수정 비용이 그만큼 커질 수밖에 없습니다.

그렇다고 매번 사용자 조사를 진행하기는 어렵습니다. 참여자를 모집하고, 일정을 맞추고, 질문을 준비하고, 답변을 정리하는 과정이 필요하기 때문입니다. 시간이 촉박한 팀은 결국 동료 몇 명에게 의견을 물으며 인터뷰를 건너 뛰거나, 가상의 사용자와 인터뷰를 진행하는 방식을 활용하게 됩니다. 인터뷰를 진행한다 하더라도, 적절한 대상자를 찾는 건 또 다른 문제로 다가오죠. 실제로 제가 운영하는 오픈 채팅방에도 갖가지 프로젝트에 대한 설문조사 또는 인터뷰 요청내용이 종종 올라오는데요. 가끔 보면 채팅방에 모여있는 대상과 맞지 않는 프로젝트의 내용이 포함되기도 합니다.

<출처: august, 작가 캡처>

‘august’는 이러한 문제를 디지털 트윈(Digital Twin)이라는 방식으로 접근하는 서비스입니다. august의 공식 설명에 따르면, Digital Twin은 일반적인 페르소나가 아니라, 실제 사용자 한 명의 행동 데이터를 바탕으로 만든 합성 사용자 모델에 가깝습니다. 제품팀은 이 Twin에게 일대일 질문을 하거나, 여러 Twin을 모아 포커스 그룹과 설문을 진행할 수 있습니다. 가격이나 새 화면을 보여주고 반응을 예측하는 식입니다.

미리 요점만 콕 집어보면?

august는 범용 AI에게 가상의 사용자를 연기하게 하는 대신, 실제 사용자 행동 데이터를 바탕으로 만든 합성 사용자 모델(Digital Twin)에게 신기능·가격·화면을 먼저 보여주는 사용자 조사 서비스입니다.
제품팀은 한 명의 Twin과 대화하며 특정 사용자의 맥락을 확인하거나, 여러 Twin을 포커스 그룹·설문으로 비교하면서 출시 전에 어떤 가정을 확인해야 할지 좁힐 수 있습니다.
무료 계정에서는 Representative Twin으로 질문 입력·대상 선택·응답 비교의 흐름을 경험할 수 있습니다.

August의 주요 기능과 특징

범용 페르소나가 아닌 실제 행동 기반 ‘Digital Twin’

august의 핵심은 질문을 잘 만드는 AI가 아니라 질문을 받을 대상에 있습니다. 일반적인 AI 페르소나는 ‘온라인 쇼핑을 자주 하고 가격에 민감한 사용자’처럼 몇 가지 특징을 입력해 만듭니다. 그럴듯한 답을 얻을 수는 있지만, 특정 사용자가 실제로 무엇을 클릭했고 어떤 정보를 비교했으며, 어떤 순간에 구매를 포기했는지까지 반영하기는 어렵습니다.

august는 이 대상을 개별 사용자의 행동 데이터로 만든 디지털 트윈(Digital Twin)으로 바꿉니다. 공식 홈페이지는 Twin이 상호작용과 행동에서 의사결정 방식과 성향을 만들고, 각 상호작용을 기억으로 남긴다고 설명합니다. 그 위에 사용자의 고차원적인 생각과 동기를 정리한 반영 정보가 쌓인다는 구조입니다.

<출처: august, 작가 캡처>

서비스에서 Digital Twin을 활용하는 방법은 크게 세 가지입니다.

하나는 1:1 인터뷰, 또 하나는 포커스 그룹 인터뷰 마지막으로 설문조사입니다. 로그인한 뒤 Twins 화면을 먼저 살펴봤는데, 처음부터 제가 연결한 사용자 데이터가 나타난 것은 아니고 서비스에서 미리 설정해둔 Robin H., Avery N., Jamie T. 같은 가상의 사용자를 볼 수 있었습니다. 총 다섯 명이 등록되어 있으며, 어떤 일을 하는지 최근 흥미있는 분야는 무엇인지 등 간단한 정보를 함께 확인할 수 있게 구성된 모습입니다. 원하는 대상을 선택하면 보다 상세한 정보를 확인할 수 있으며, 바로 인터뷰를 시작할 수 있습니다.

서비스를 통해 우리는 상황에 따라 하나의 Twin과 대화하거나, 여러 Twin을 묶어 조사할 수 있습니다. 일대일 대화는 특정 사용자의 맥락을 깊게 확인할 때 어울립니다. 예를 들어, 가격을 본 뒤 구매를 망설이는 이유, 새 기능을 찾지 못하는 이유, 랜딩페이지에서 신뢰하지 못한 문장을 질문하는데 적합합니다.

여러 명을 한 번에 살펴보고 싶다면 포커스 그룹이나 설문을 사용할 수 있습니다. 공식 홈페이지의 예시에는 ‘창업자를 위한 AI inbox를 사용해 볼래?’라는 질문을 12명의 참가자에게 보여준 결과가 나옵니다. 9명이 사용해 보고 싶다고 답했지만, 동시에 글이 너무 기계적으로 느껴진다는 의견도 나타났습니다. 흥미로운 부분은 단순히 찬반 비율만 보여주는 데서 끝나지 않는다는 점입니다. 응답을 묶어 보면 참가자들이 불편해하는 진짜 문제는 메일을 분류하는 방식보다, 너무 많은 스팸 메일 자체일 수 있다는 해석이 함께 제시됩니다.

이런 흐름은 제품팀이 ‘기능을 추가하면 좋아할 것’이라는 가정을 세우는 대신, 어떤 문제를 해결해야 반응이 달라지는지 다시 묻는데 많은 도움이 된다고 생각합니다.

PRD, Figma, GitHub 안으로 들어오는 피드백

<출처: august, 작가 캡처>

august는 별도의 리서치 도구에서 결과를 확인하는 방식만 제안하지 않습니다. 예를 들어, PM이라면 Claude에서 새 기능의 PRD를 작성한 뒤, august MCP를 통해 Digital Twin의 피드백을 받을 수 있습니다. 디자이너는 Figma에서 만든 목업을 Figma 플러그인으로 보여주고, 개발자는 GitHub Pull Request에 대한 제품·UX 리뷰를 받을 수도 있습니다.

이 구조의 장점은 피드백이 작업 흐름과 떨어지지 않는다는 데 있습니다. PRD를 다 쓰고 나서 별도의 문서로 의견을 모으는 것이 아니라, 필요한 순간에 바로 질문할 기회를 잡을 수 있기 때문입니다. 화면을 넘기기 전에 어떤 요소를 오해할지 확인하고, 코드가 병합되기 전에 사용자에게 보이는 변화가 어떤 문제를 만들 수 있는지 살펴보는 식입니다.

GitHub App은 각 PR에 고객 Twin 패널의 리뷰를 남기는 방식입니다. 공식 안내에 따르면 리뷰는 병합을 막지 않는 조언 형태이며, 새 커밋이 올라오면 이전 리뷰는 이전 내용으로 접힙니다. 다만 이를 사용하려면 Twin이 준비된 august 조직과 저장소 접근 권한이 필요합니다. 단순히 GitHub App을 설치하는 것만으로 모든 저장소의 코드가 검토되는 구조는 아닙니다.

실제 사용하면서 살펴본 august의 사용 흐름

august의 공개 홈페이지에는 서비스를 실제로 어떤 질문에 사용할 수 있는지 보여주는 예시가 포함되어 있습니다. 한 화면에는 트레일 러닝화를 240달러에 구매하겠냐는 질문과 함께, 제품의 소재와 기술적 근거를 더 알고 싶다는 Twin의 답변이 표시됩니다. 단순히 ‘비싸다’라고 말하는 것이 아니라, 과거에 비싼 신발을 구매했다가 만족하지 못했던 경험과 기술 정보에 대한 요구를 연결한 형태입니다.

다른 화면에서는 실제 행동 데이터에서 만들어진 기억과 성향의 예시를 볼 수 있습니다. 장바구니를 포기했다가 할인 후 다시 구매한 행동, 여러 신발을 비교한 뒤 무게를 기준으로 필터링한 행동이 기억으로 정리되어 있습니다. 그 위에 가격에 민감하지만 품질을 중시하고, 마케팅 문구보다 구체적인 성능 근거를 신뢰한다는 반영 정보가 제시됩니다.

이 사례를 통해 알 수 있는 것은 august가 말하는 답변의 방향입니다. 사용자의 일반적인 취향을 만들어내는 것보다, 과거 행동을 근거로 다음 선택을 추정하려는 시도를 계속하기 때문입니다. 반대로 아직 알 수 없는 것도 있습니다. 이 정보가 실제 사용자 한 명의 전체 행동을 얼마나 충분히 담고 있는지, 새로운 제품이나 전혀 다른 상황에서도 같은 수준의 판단을 하는지는 사례로 확인하기 어렵습니다.

그래서 직접 질문을 던져보기로 했습니다. 인터뷰 메뉴로 진입 후 처음 입력한 질문은 “새로운 제품 기능을 평가할 때 Digital Twin의 응답을 믿으려면 무엇이 필요할까?”입니다. Interview 화면의 질문 입력창에 내용을 넣고 Start interview를 누르자, august가 질문에 맞는 대상을 자동으로 골랐고, Robin H.과의 인터뷰 화면이 열렸습니다.

화면에는 Robin이 30개 세션, 4개 조직 맥락, 358개의 경로 관찰을 바탕으로 만들어졌다는 정보가 표시됐습니다.

<출처: august, 작가 캡처>

답변은 막연하지 않게 구체적인 조건을 바탕으로 전달되었습니다. 사용자가 실제로 자주 이용하는 화면과 작업 흐름을 짚고, 기능이 어느 화면을 바꾸는지 명확해야 한다고 말했습니다. 또 기능 도입 전후에 미리 보기 화면을 오가는 횟수가 줄어드는지, 저장 상태가 분명해지는지, 프로젝트 사이를 더 빠르게 이동할 수 있는지를 보여줘야 신뢰하겠다고 설명했습니다. 반대로 “유용하다”처럼 일반적인 답변만 나오면 신뢰하기 어렵다는 내용도 포함되었습니다.

<출처: august, 작가 캡처>

이 답변에서 확인한 august의 장점은 결과를 찬반으로만 끝내지 않는다는 점입니다. 질문 속 기능을 특정 화면과 작업 흐름에 연결해, 제품팀이 다음에 확인할 질문을 만들어 준다는 점도 매력적인 부분이었습니다.

두 번째 질문은 실제 제품 개선 상황에 가깝게 바꿨습니다. “프로젝트 목록에 프로젝트를 한 번에 복제하는 기능이 추가된다면 무엇을 기대하고, 무엇 때문에 망설일 것 같나요?”라고 물었습니다. 이번에는 자동 선택 대신 Avery N.을 직접 골랐습니다. Avery의 화면에는 22개 세션, 6개 조직 맥락, 515개의 경로 관찰이 표시됐습니다.

Avery는 프로젝트 복제에서 확인해야 할 범위를 나눠 설명했습니다. 구성 요소와 스타일, 연결된 데이터 라이브러리 참조가 함께 복사되는지, 어느 계정으로 복사되는지, 게시 상태는 어떻게 되는지가 중요하다고 했습니다. 특히 여러 고객 조직을 오가는 사용자라면 현재 열려 있는 계정으로 조용히 복사되는 것보다, 대상 계정을 직접 선택하는 단계가 필요하다고 답했습니다. 복제 결과는 바로 공개되지 않고 미게시 상태로 만들어 미리 보고 정리할 수 있어야 한다는 조건도 덧붙였습니다.

<출처: august, 작가 캡처>

앞서 Robin에게서 받은 “기능이 실제 작업 화면에서 어떤 변화를 만드는지 보여줘야 한다”는 답변과 비교하면, Avery는 복제 기능이라는 구체적인 상황에서 범위·계정·게시 상태라는 위험 요소를 더 분명하게 꺼낸 모습입니다. 두 답변이 완전히 다른 결론을 내린 것은 아니지만, 같은 질문을 모든 대상에게 던지는 대신 특정 사용자 프로필을 선택해 맥락이 다른 반응을 비교할 수 있다는 점은 분명히 확인할 수 있었습니다.

<출처: august, 작가 캡처>

추가로 그룹 인터뷰도 진행해봤습니다. 온보딩 과정의 어려움으로, 팀이 특정 도구를 처음 사용하던 상황을 제공해 어떤 순간에 작업이 지연/중단되었으며, 어떤 부분에서 어려움을 겪었는지 질문했습니다. 다섯 명은 순서대로 자신의 생각을 말했고, 모더레이터는 이들의 답변을 하나로 요약해 다음에 무엇을 어떻게 물어보면 좋을지 제안해 줍니다.

<출처: august, 작가 캡처>

august는 Digital Twin이 범용 Claude보다 특정 고객의 행동을 더 잘 예측한다고 설명합니다. 공식 평가 글에서는 한 전문 소매업체의 고객 47명을 대상으로, 실제 방문 세션의 뒷부분을 네 개의 후보 중에서 고르는 실험을 진행했다고 밝힙니다. Twin은 앞부분을 전혀 보지 않은 조건에서 66.0%를 기록했고, 기본 Claude는 25.5%, 다른 사람의 Twin은 19.1%였습니다.

세션의 첫 세 행동을 보여준 조건에서는 Twin 57.4%, 기본 Claude 38.3%로 소개됩니다. 이 숫자는 Twin이 특정 사람의 과거 행동을 알고 있을 때 범용 모델보다 유리할 수 있다는 점을 보여주는 자료입니다. 다른 사람의 Twin을 넣었을 때 점수가 낮아졌다는 결과도, 모든 Twin이 같은 답변을 만드는 것은 아니라는 설명을 뒷받침합니다.

하지만 이 평가가 제품팀의 모든 질문에 대한 정확도를 뜻하지는 않습니다. 실험은 특정 조직의 고객과 특정한 행동 예측 과제를 대상으로 했습니다. 제품 아이디어의 선호도, 가격에 대한 태도, 화면의 이해도처럼 정답을 하나로 정하기 어려운 질문에는 같은 방식의 숫자를 적용하기 어렵습니다. august의 FAQ도 여러 사례 연구가 진행 중이며, 자신의 Twin으로 직접 질문해 보는 것이 가장 좋은 확인 방법이라고 안내합니다.

어떤 팀이 활용하기에 적합할까?

적합한 조건

august는 이미 사용자 행동 데이터가 쌓여 있고, 그 데이터를 바탕으로 제품 결정을 반복해서 내려야 하는 팀에 어울립니다. 새 기능을 만들 때마다 고객을 다시 모집하기 어렵지만, PRD·화면·가격안을 자주 바꾸는 SaaS 팀이라면 활용 장면을 만들기 쉽습니다. 특히 “이 버튼을 누를까?”보다 “이 사용자가 이 상황에서 어떤 선택을 할까?”를 알고 싶은 팀에 적합합니다.

PM은 기능 요구사항을 정리한 뒤 놓친 가정이 있는지 확인할 수 있습니다. 디자이너는 화면을 구현하기 전에 사용자 행동에 막힐 만한 부분을 찾을 수 있습니다. UX 리서처는 실제 조사 질문을 만들기 전에 여러 가설을 비교할 수 있습니다. 개발자는 GitHub PR에 대한 제품·UX 관점의 의견을 참고해, 사용자에게 보이는 문제를 미리 살필 수 있습니다.

<출처: august, 작가 캡처>

비용 구조도 초기 실험을 시작하려는 팀을 고려한 모습입니다. 공식 홈페이지에 따르면, 구독료나 선불 비용 없이 시작할 수 있고, 가입 시 카드 없이 100 크레딧을 제공합니다. 이후 결제 수단을 추가하면 500 크레딧, 첫 번째 커스텀 Twin이 준비되면 1,000 크레딧을 추가로 받을 수 있습니다. 500 크레딧은 25달러이며, 일대일 대화는 약 20 크레딧, 포커스 그룹은 약 250 크레딧, 설문은 약 800~1,200 크레딧이 필요합니다. 실제 사용량은 질문의 길이와 복잡도에 따라 달라질 수 있습니다.

신중해야 하는 조건

가장 먼저 확인할 부분은 데이터입니다. august의 핵심 가치는 실제 사용자의 행동을 바탕으로 한 Twin에 있지만, 그만큼 어떤 데이터를 연결했는지가 결과에 영향을 줍니다. 충분한 행동 기록이 없거나 특정 사용자 집단만 데이터에 포함되어 있다면, 결과 역시 그 범위를 벗어나기 어렵습니다. 인구통계나 평균적인 고객상만으로 실제 고객의 반응을 대신하는 제품으로 이해하면 안 됩니다.

개인정보와 보안도 중요한 조건입니다. 개인정보 처리방침은 계정 정보, 조직 멤버십, 질문과 포커스 그룹 지시문, 업로드 이미지, Figma 링크 등이 처리될 수 있다고 설명합니다. 또한 기밀·민감·규제 대상 개인정보는 조직에서 사용을 승인하지 않았다면 제출하지 말라고 안내합니다. 실제 고객 데이터를 연결하기 전에는 조직의 보안 정책과 데이터 처리 조건을 먼저 확인해야 합니다.

비용을 계산할 때는 질문의 횟수만 세어서는 안 됩니다. 일대일 대화와 포커스 그룹, 설문은 사용하는 크레딧이 크게 다릅니다. 짧은 가설을 여러 번 확인하는 방식과 많은 Twin을 한 번에 조사하는 방식의 비용이 다르기 때문입니다. 초기에는 한두 개의 구체적인 질문으로 답변의 유용성을 확인한 다음 범위를 넓히는 편이 적절합니다.

마지막으로 Twin의 답변을 실제 사용자 의견으로 바꾸어 말하지 않아야 합니다. 서비스 약관도 AI 결과가 부정확하거나 불완전하거나 실제 고객 행동을 대표하지 않을 수 있다고 명시하고 있습니다. 가격을 올려도 되는지, 개인정보를 수집해도 되는지, 중요한 접근성 문제를 무시해도 되는지처럼 사람의 판단이 필요한 결정은 Twin의 답변만으로 내릴 수 없습니다. 실제 사용자 인터뷰·사용성 테스트·제품 지표와 함께 해석해야 합니다.

마치며

august는 사용자 조사를 없애는 도구라기보다, 조사에 들어가기 전 제품팀이 더 나은 질문을 준비하도록 돕는 도구에 가깝습니다. 일반적인 AI 페르소나에게 “이런 사용자는 어떻게 생각할까?”라고 묻는 대신, 실제 행동 데이터를 바탕으로 만든 Digital Twin에게 특정 가격·화면·기능을 보여주고 반응을 살펴보려 합니다. 이 방식이 제대로 작동한다면 제품팀은 막연한 찬반 의견보다 사용자의 과거 행동과 연결된 반응을 참고할 수 있습니다.

이번에 공개 화면과 로그인한 Free tier를 통해 확인한 범위에서는 Digital Twin, 인터뷰, 포커스 그룹, Figma·GitHub 연동, 사용량 기반 가격 구조가 비교적 선명하게 제시되어 있습니다. 대표 Twin을 선택해 실제 질문과 답변을 주고받는 흐름도 경험할 수 있었습니다. 반면 제 사용자 데이터를 연결한 Twin, 화면 자극물을 첨부한 반응, 포커스 그룹의 이견 비교는 아직 직접 확인하지 못했습니다. 공개 홈페이지의 예시와 공식 평가 수치, 대표 Twin 인터뷰 결과를 하나의 성능 지표로 묶을 수 없는 이유입니다.

다시 말해 현재 무료 계정에서 경험한 august는 완성된 사용자 조사 결과를 보여주는 서비스라기보다, 자체 데이터로 Twin을 만들었을 때 어떤 질문을 던질 수 있는지 미리 보여주는 단계에 가깝습니다. 이 접근이 실제 업무에 도움이 되는지는 결국 팀이 가진 데이터로 Twin을 만들고, 그 답변을 실제 사용자 반응과 비교해 본 뒤에야 판단할 수 있습니다.

결국 august에 맡길 수 있는 일은 출시 전 가정을 빠르게 펼쳐 보고, 어떤 질문을 실제 사용자에게 물어야 하는지 좁히는 작업입니다. 최종적으로 무엇을 만들지, 누구의 데이터를 사용할지, 답변을 실제 의사결정에 어느 정도 반영할지는 제품팀이 판단해야 합니다. 실제 사용자 반응을 기다릴 시간이 부족한 팀이라면 좋은 보조 수단이 될 수 있지만, 데이터의 범위와 Twin의 답변을 검토할 여유가 없는 팀이라면 도입 전에 더 신중한 확인이 필요합니다.

<참고>

https://www.getaugust.ai/

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

Next.js 모바일 웹을 일주일 만에 앱으로 바꾼 방법 ①

서서히 유저를 끌어모으던 웹 서비스가 있었습니다. Next.js로 잘 돌아가던 B2B 서비스였죠. 모바일 웹에서도 핵심 플로우는 이미 잘 동작하고 있었습니다. 그런데 VOC를 살펴보다가 고민에 빠졌습니다. 알림을 보지 못해서 계약이 불발되었다는 내용이었습니다. 웹에서는 항상 보이는 헤더의 알림창이 서비스를 벗어나면, 더이상 쉽게 볼 수 없는 정보가 됐습니다. 그래서 앱을 만드는 것에 대해 고민하기 시작했죠.

앱을 만드는 건 생각보다 많은 시간이 걸립니다. 하지만 이미 잘 정리된 모바일 웹이 있으니, 이걸 기반으로 AI에게 시키면 잘 만들어주지 않을까?라는 생각을 하게 된 거죠. 결론부터 미리 말하자면, 생각보다 더 잘 만들어줬습니다. 이 글의 제목처럼 일주일 만에 POC수준 이상의 앱을 만들었고, 지금은 QA를 거치는 중입니다.

그래서 이번 글에서는 모바일 웹을 앱으로 바꾸는 과정에서 부딪힌 이슈와, 이를 위해 어떤 워크플로우를 도입했고, 어떻게 기술 스택을 선정했는지에 대한 얘기를 풀어보고자 합니다.

시대를 역행하는 기술 스택

최근에 Shopify 엔지니어링 블로그의 “Native is now the future of mobile at Shopify”를 읽었습니다. 한 줄로 말하면, Shopify가 앱을 React Native에서 Swift와 Kotlin 네이티브로 되돌린다는 내용입니다.

흥미로운 지점은 “RN(React Native)이 실패해서”가 아니라는 데 있습니다. 글에서도 2020년 RN 올인은 매우 성공적이었다고 말합니다. 기능을 한 번만 만들고, 모바일 배경이 없는 개발자도 기여할 수 있게 하고, 플랫폼 간 패리티 추격에 덜 매달리게 해 주었다는 거죠. 그런데 코딩 에이전트(LLM)가 좋아지면서, 같은 기능을 두 번 만드는 비용이라는 가정이 흔들렸다고 합니다. 에이전트가 iOS를 보고 Android를 구현하거나, 그 반대를 할 수 있고, 공유 스펙·테스트·리뷰로 패리티 유지비가 예전만큼 무겁지 않다는 실험이 나왔다는 이야기입니다. 그래서 플랫폼에 더 가까운 네이티브가, 지금 Shopify 규모에서는 다시 합리적이 되었다는 결론으로 갑니다.

Shop 앱은 AI를 도우미로 두고, 약 12주 만에 네이티브로 재구축해 스토어에 올렸다는 대목도 인상적이었습니다. Helix 같은 체크포인트 루프로 “한 방에 네이티브 번역”이 아니라, 작은 단위로 검증하며 옮긴다는 점도요. 이 글을 읽고 나면, 2026년에 React Native를 고르는 일이 어쩐지 시대를 역행하는 선택처럼 느껴질 수 있습니다. 큰 회사들이 다시 네이티브로 가는 타이밍에, 저는 Expo 기반 RN으로 POC를 시작했으니까요.

그럼에도 저는 RN을 골랐습니다. Shopify의 결론을 부정해서가 아니라, 전제가 달랐기 때문입니다.

Shopify는 여러 대형 앱과 수백 명의 엔지니어, 이미 쌓인 RN 자산과 네이티브 전환을 감당할 조직이 있습니다. 저는 사실상 1인에 가까운 프론트엔드로, 이미 돌아가는 Next.js 웹과 같은 제품 언어를 최대한 공유해야 했습니다. Swift와 Kotlin을 동시에 새로 배우고, 웹까지 세 갈래로 의미를 맞추는 일은 일주일 POC의 목표가 아니었습니다.

제가 원한 공유는 단순히 UI에만 국한되지 않고, 가입 스키마, 에러 카피, API 훅, 폼 검증처럼 의미의 코드베이스를 웹과 앱이 같이 쓰는 쪽이었습니다. React 문법을 아는 상태에서 RN(Expo)으로 가면, AI 에이전트에게도 “웹 모바일 화면을 보고 앱 화면을 조립해”라는 지시가 통합니다. 같은 훅, 같은 zod, 같은 도메인 단어를 유지한 채 화면 단위로 옮길 수 있었죠. 네이티브 두 플랫폼을 AI가 잘 옮겨 준다는 Shopify의 논리와는 결이 다르지만, 이미 있는 React 웹을 SoT(Single source of Truth)로 삼아 한 사람이 개발해야 하는 상황에서는 RN이 훨씬 저에겐 합리적인 선택이었습니다.

모노레포를 먼저 깐 이유

이전에 AI 에이전트에게도 “웹 모바일 화면을 보고 앱 화면을 조립해”라는 지시가 통하게 하려면 웹 모바일 화면에 대한 충분한 컨텍스트를 제공할 수 있어야합니다. 그래서 기존 프로젝트를 모노레포로 옮기는 작업을 먼저 시작했습니다.

전체적인 구조는 다음과 같은데요. pnpm workspace로 apps/*와 packages/*를 나눴습니다.

apps 내부에는 “web”, “admin”, “mobile” 이렇게 3개의 프로젝트가 있고, packages 아래 이미지처럼 생겼습니다.

packages의 이름과 역할 <출처: 작가>

이렇게 앱과 패키지를 나눈 세세한 이유는 없습니다. 단지 공유가능한 단위를 패키지로 옮기다보니, 이렇게 점점 생기고 있을 뿐입니다. 만약 추가로 옮겨야 하는 것들이 있다면 패키지에 추가하면 됩니다. 지금 떠오르는 후보는 Grafana, Sentry처럼 에러 로깅 시스템을 패키지화하면 좋지 않나라는 생각이 드네요.

하나의 패키지로 웹이랑 앱은 무리다

패키지 표를 보면 UI의 핵심이 되는 축이 세 개로 보입니다. @chulgang/ui, @chulgang/ui-native, @chulgang/tokens입니다. 특히 ui와 ui-native로 나뉘어 있는 것을 눈여겨봐 주셨으면 합니다.

저는 웹과 앱을 한 레포에 두더라도, UI를 억지로 하나의 패키지로 묶으면 오히려 비용이 커질 거라고 생각했습니다. 하나의 패키지로 웹이랑 앱을 다 커버하는 일은 무리에 가깝다는 쪽이었습니다.

처음 구상할 때는 당연히 욕심이 났습니다. 웹도 앱도 React를 쓰니, 컴포넌트 패키지 하나로 웹과 앱을 다 커버하면 좋겠다고요. 그런데 기존 웹에서 쓰던 shadcn/ui 쪽을 다시 보니, 웹에서만 자연스러운 로직이 상당히 많이 들어가 있었습니다. DOM 이벤트, 포커스 트랩, Radix 포털, asChild같은 패턴이요. 그대로 RN에 끌고 가기엔 “공유”보다 “예외 분기”가 먼저 쌓일 것 같았습니다.

그래서 역할을 이렇게 나눴습니다.

@chulgang/ui : 웹과 어드민용. shadcn/ui 계열로, Radix primitive와 Tailwind(DOM)로 이루어져 있습니다.
@chulgang/ui-native : 모바일(Expo)용. React Native Reusables 계열로, rn-primitives와 NativeWind로 이루어져 있습니다.
@chulgang/tokens : ui와 ui-native가 함께 쓰는 색,타이포,간격의 이름표입니다. colors / typography / spacing, 그리고 theme CSS 진입점이 여기에 있습니다.

구현체는 둘로 두되, 부르는 이름은 맞추려 했습니다.

예를 들면, @chulgang/ui/button, @chulgang/ui-native/button 이렇게 되었습니다.

웹용 버튼 <출처: 작가>

앱용 버튼 <출처: 작가>

공유하는 토큰 <출처: 작가>

그리고 실제로 구현된 모습을 보면, 다음처럼 구현되어 있습니다.

실제 Button 사용 예시 <출처: 작가>

지금은 ui/button과 ui-native/button이 함께 있기 때문에 as NativeButton으로 되어있지만, 실제 코드로 보면 둘다 <Button>으로 동일하게 사용합니다.

지금 단계까지는 여기까지 왔습니다. 저는 추후에 각 버튼에서 사용하는 button variant도 패키지화를 시켜야 할지 고민하고 있습니다. 다만 컴포넌트가 분리되어있는데, 스타일만 통일해야 할까?라는 고민이 있어서, 지금은 그냥 두고 있습니다.

화면 단위로 올리는 워크플로

기술 스택을 선정하고 패키지를 만든 뒤에, 드디어 화면을 만들기 시작했습니다. 다만 앱 전체를 한번에 만들기 보다는 화면 단위로 하나씩 만들기로 결정하고 메인 페이지부터 만들기 시작했습니다.

당연히 AI 에이전트를 시켜서 만들었고, 다음과 같이 진행했습니다.

피그마화면, 모바일 웹 화면 스크린샷을 AI에게 공유한다.
같은 화면과 기능 단위로 모바일 앱을 개발해달라고 요청한다
구현이 완료되면 화면과 기능을 점검한다.

이게 계속 반복되다가, 반복이면 스킬로 만들어 알아서 돌려야겠다는 생각이 들었는데요. 그 결과가 mobile-design-sync 입니다.

스킬 mobile-design-sync를 만든 이유

한 줄로 이 스킬을 설명하면, Figma 링크 하나로 모바일 웹을 먼저 맞추고 그 다음 앱을 맞추며, 결과를 스크린샷으로 남기는 end-to-end 워크플로입니다. 사람이 매 슬라이드마다 추가적인 명령과 컨텍스트를 전달하지 않아도 되게 스킬을 만든 것입니다.

실제 사용 예시 <출처: 작가>

이 스킬이 실행되면 다음처럼 워크플로가 진행됩니다.

피그마 링크를 보고 피그마 MCP가 해당 노드의 스크린샷을 찍어옵니다.
스크린샷을 보고 연관된 컴포넌트를 식별하고, Playwright MCP를 통해 해당 컴포넌트로 이동하고 스크린샷을 찍어옵니다.
노드의 스크린샷과 컴포넌트의 스크린샷을 비교하여 수정할 내용을 선정합니다.
수정을 한뒤에 변경된 스크린샷을 찍어옵니다.
마크다운 문서로 만들어 유저의 최종 확인을 기다립니다.

다음은 실제 정리된 마크다운 문서를 공유하면서 결과를 살펴보겠습니다.

해당 작업에 대한 메타데이터와 Goal <출처: 작가>

모바일 웹과 모바일 앱의 파일 식별과 변경사항 도출 <출처: 작가>

모바일 웹과 모바일 앱의 기능을 동기화하기 위한 로직 추출 <출처: 작가>

1단계 피그마 모바일 웹 싱크 <출처: 작가>

2단계 모바일 웹 - 모바일 앱 싱크 <출처: 작가>

저는 특히 2단계에서 큰 희열을 느꼈습니다. 앱 이전에는 단순히 피그마 전체 스크린샷을 주고, 만들때 AI가 초벌로 만들어준 작업이고, 앱 이후가 해당 스킬을 통해 싱크한 결과물입니다.

실제로 보면 피그마와 최종 결과물이 약간 다른 부분이 있는데요. 이게 중간 피그마 업데이트가 되지 않아, 모바일 웹이 최신 결과물이고 피그마가 Outdated된 파일이기 때문입니다. 하지만 말씀드렸다시피 웹이 SSOT(Single Source of Truth)이기 때문에, 모바일 웹을 기준으로 앱을 만든 것을 확인할 수 있습니다.

마치며

이렇게 스킬을 만들고 개발자는 최종 마크다운으로 결과만 확인 후, PR을 Merge하는 반복적이지만 지루한 과정의 연속이었습니다. 그 결과 크게는 3일 동안 어마무시한 라인을 수정하면서 완성하게 되었습니다.

9월 9일 ~ 9월 11일 라인 수정량 <출처: 작가>

토큰 사용량 그래프 <출처: 작가>

또 AI 에이전트를 사용하면서 처음으로 모든 토큰을 리셋된지 3일 만에 전부 다 쓰게 되었습니다. 저는 결제일이 7일인데, 11일날 토큰을 전부 다 사용했다는 알림이 오더라고요. 그런데도 계속 가능했던 이유는 커서 또한 다 쓰게 되면 100불짜리 추가 크레딧을 주기 때문입니다.

그럼 최종 결과는 어떻게 되었을까요? 앱 출시까지 바로 완료했을까요? 아쉽게도 결론적으로는 실패했습니다.

그 이유는 크게 3가지였습니다.

모바일 웹과 모바일 앱은 본질적으로 UI/UX 프로세스가 다르다. 디자인만 맞춘다고 끝이 아니다.
실제 로직이 어긋난 부분이 생각보다 너무 많이 발견됐다.
모바일 앱에서 지원할수 있는 기본 기능에 대한 추가 개발이 필요하다. (ex.푸시 알림, 패스키)

여기에 각 픽셀이나 토큰 단위의 싱크도 추가로 필요했고, 데스크탑 웹과 모바일 웹의 반응형 디자인의 차이까지 생각보다 여러 추가 수정사항이 계속해서 나왔던 탓입니다. 이번 편에서는 여기까지로 마무리짓고, 다음 편에서는 이러한 역경을 이겨낸 최종 출시까지의 여정을 다뤄보겠습니다. “앱 출시까지 2주면 된다”를 실제로 테스트해 본 최종 후기로 돌아올게요.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

국내 FDE 현황 조사 2026: FDE의 실제 모습을 묻습니다

FDE, 왜 다들 이야기할까?

AI 도입이 시범 사업을 넘어 실제 업무에 붙는 단계로 넘어가면서, 다시 주목받는 직무가 있습니다. 고객 현장에 직접 들어가 문제를 찾고, AI로 풀고, 실제 운영까지 붙이는 엔지니어, 곧 “FDE(Forward Deployed Engineer)”입니다.

이 직무는 데이터 소프트웨어 기업 팔란티어가 2010년대 초반에 처음 만들었습니다. 최근에는 OpenAI, Anthropic 같은 AI 기업들이 FDE를 적극적으로 채용하면서 다시 화제가 됐습니다. 파이낸셜타임스를 인용한 보도에 따르면, FDE 채용 공고는 2025년 초부터 9월까지 800% 넘게 늘었습니다.

국내 상황도 다르지 않습니다. ‘FDE’라는 이름을 단 채용 공고와 조직이 하나둘 생기고 있고, AX(AI 전환)를 맡은 현장에서도 비슷한 역할을 하는 사람이 늘어나고 있습니다.

팔란티어 채용 공고 <출처: 팔란티어 홈페이지>

그런데 아무도 정확히 모릅니다

문제는 FDE가 실제로 어떤 일을 하는지 정리된 자료가 거의 없다는 점입니다. 요즘IT도 인터뷰를 준비하며 현장의 FDE들을 만났지만, "FDE는 어떤 일을 하나요?"라는 질문에 돌아오는 답은 사람마다 달랐습니다.

우선 이름부터 제각각입니다. 비슷한 일을 하면서도 어떤 회사는 FDE, 어떤 회사는 AX 엔지니어나 솔루션 엔지니어라고 부릅니다. 같은 FDE라도 자사 제품이 있는 회사에서 일하는지, 고객사에 상주하며 일하는지에 따라 하는 일도 크게 달라집니다. 그래서 이 직무를 바라보는 시각도 나뉩니다. 기존에 없던 새로운 직무라고 보는 사람도 있고, 기존 개발 업무에 새 이름이 붙었을 뿐이라고 보는 사람도 있습니다. 어느 쪽이 맞는지 말하려면, 무엇보다 실제로 이 일을 하는 사람들의 경험이 필요합니다.

그래서 요즘IT와 한국 FDE / AX 엔지니어 커뮤니티 ‘비욘드디플로이’가 위시켓의 지원을 받아 함께 「국내 FDE 현황 조사 2026」을 기획하게 됐습니다.

무엇을 묻나요?

이번 조사는 FDE를 네 가지 질문으로 살펴봅니다.

어디서 왔는가: 이 일을 하기 전에 어떤 직무를 맡았고, 왜 이 일을 시작했는지 묻습니다.
어디서 일하는가: 어떤 회사에 소속되어, 어떤 계약 형태로 일하는지 묻습니다.
어떻게 일하는가: 문제를 누가 정하는지, 현장에서 만든 것이 어디에 쌓이는지, 프로젝트가 끝난 뒤에는 어떻게 되는지 묻습니다.
앞으로: 이 일을 스스로 어떻게 보고, 앞으로도 계속할 생각이 있는지 묻습니다.

모인 응답은 소속과 계약 형태에 따라 나눠 비교합니다. 같은 FDE라는 이름 아래에 어떤 서로 다른 일들이 있는지 보여 드리려는 것입니다.

누가 참여할 수 있나요?

직함은 상관없습니다. 이번 조사는 이름이 아니라 하는 일을 기준으로 대상을 정했습니다.

고객 현장의 업무 문제를 AI로 풀어 실제 운영까지 붙이는 일

이 일을 지금 하고 있거나, 지난 1년 안에 해 보셨다면, 지금 불리는 이름이 FDE든, AX 엔지니어든, 솔루션 엔지니어든 누구나 참여하실 수 있습니다. 사내 현업 부서를 고객으로 두고 일하는 경우도 포함합니다. 이름이 다르다고 이분들의 경험을 빼놓으면, 국내 현황을 온전히 담을 수 없기 때문입니다.

참여 안내

기간: 10/15(목)~10/31(토)
소요 시간: 약 5~7분
참여 혜택: 네이버페이 포인트 3,000원(추첨 100명, 현재 당첨 확률 높아요!), 리포트 발행 시 우선 안내
응답 처리: 익명으로 집계하며, 리포트 작성 외의 목적으로 쓰지 않습니다
참여 링크: ★설문 참여하기★

어떤 이름으로 불리든 현재 이런 일을 하고 계신다면, 여러분의 경험을 들려주세요.

주변에 관련 업무를 하는 분께 공유해 주셔도 큰 힘이 됩니다!

▶지금 참여하러 가기

<출처>

Fast Company, “Forward-deployed engineers: a new role in the evolving AI job market” (2025. 11. 8.)

]]>

에이전틱 AI 세계에서 게이트웨이는 어떤 의미를 가질까요?

2025년 5월, 보안 회사 인베리언트 랩스(Invariant Labs)가 한 가지 공격 방법을 공개했습니다. 깃허브(GitHub)의 공개 저장소에 올린 이슈 하나로 AI 에이전트가 같은 사용자의 비공개 저장소 내용을 밖으로 옮기게 만들 수 있다는 것입니다. 에이전트는 깃허브 MCP 서버가 제공하는 도구를 정해진 권한 안에서 호출했을 뿐이고, 서버 코드에는 버그가 없었습니다. 인베리언트 랩스는 깃허브가 서버 쪽만 고쳐서는 이 문제를 해결할 수 없으며, 에이전트 시스템 수준에서 다뤄야 한다고 결론 내렸습니다.

그렇다면 에이전트와 도구 사이, 다시 말해 에이전트가 도구를 호출할 때 그 요청이 거쳐 가는 지점에서는 무엇을 할 수 있을까요? 그리고 에이전틱 AI 세계에서 그 지점에 놓이는 게이트웨이(gateway)는 어떤 의미를 가질까요?

이 글에서는 에이전트를 실제 업무에 연결하려는 분들이 언제 게이트웨이를 고민하면 좋을지 판단하는 데 도움이 되도록 이 질문의 답을 차례로 찾아보겠습니다. 먼저 1) 여러 회사가 왜 지금 이 지점에 제품을 내놓는지 보고, 이 흐름이 마이크로서비스 때와 어디가 같고 어디는 다른지 살펴봅니다. 이어서 2) 에이전틱 AI 재단(AAIF, Agentic AI Foundation)이 이 영역을 어떻게 키우려 하는지, CNCF(Cloud Native Computing Foundation)가 쿠버네티스 생태계를 키운 과정과 비교해 보겠습니다. 마지막으로 3) 재단의 게이트웨이 2개를 직접 설치해 확인한 결과를 바탕으로 언제 게이트웨이를 고민하면 좋을지 정리하겠습니다.

여러 회사가 에이전트의 연결 지점에 제품을 내놓는 이유

최근 1년 사이에 에이전트가 모델과 도구, 그리고 다른 에이전트를 호출하는 지점에 놓이는 제품이 계속 나오고 있습니다.

쉴새없이 커지는 에이전트 게이트웨이 시장

API 게이트웨이를 만드는 콩(Kong)은 2026년 9월 1일에 LLM 호출과 MCP 도구 호출, 에이전트끼리 주고받는 A2A(Agent2Agent) 요청을 한 제품에서 다루는 Kong AI Gateway 2.0을 정식으로 내놓았습니다. AWS는 2025년 10월에 Amazon Bedrock AgentCore Gateway를, 구글(Google)은 2026년 6월에 Agent Gateway를 정식 출시했습니다. 인증 회사인 옥타(Okta)도 2026년 9월에 에이전트와 도구 호출 사이에 놓이는 Agent Gateway를 발표했습니다.

국내에서는 KT DS가 자사 API 게이트웨이인 BEAST에 AI 게이트웨이 기능을 넣었고, 삼성SDS는 2026년 10월 출시 예정인 패브릭스(FabriX) 2.0에 AI 게이트웨이와 스마트 라우터 기능을 넣는다고 합니다.

인수도 이어졌습니다. 보안 회사 팔로알토 네트웍스(Palo Alto Networks)는 AI 게이트웨이를 만드는 Portkey를 약 1억 1,700만 달러(한화 약 1,560억 원)에 인수했고, 스트라이프(Stripe)는 여러 모델로 LLM 호출을 나눠 보내는 OpenRouter를 인수하기로 했습니다.

이처럼 에이전트 게이트웨이 업계에서 생겨난 쉴새없는 흐름을 에이전틱 AI 재단과 이 글에서 다룰 두 게이트웨이의 주요 사건과 함께 시간순으로 정리하면 다음과 같습니다.

에이전트 게이트웨이 시장과 에이전틱 AI 재단의 주요 사건 <출처: 작가>

왜 모두가 에이전트 게이트웨이에 관심을 가질까?

이렇게 많은 회사가 같은 지점에 관심을 보이는 이유가 있습니다. 이 지점을 지나가는 호출이 정말 빠르게 늘었는데, 그 호출을 관리할 체계는 아직 갖춰지지 않았기 때문입니다.

에이전틱 AI 재단의 발표에 따르면 ChatGPT 사용자가 MCP 도구를 호출한 횟수는 2026년 8월, 1월의 98배로 늘었습니다. 호출을 받는 서버 쪽도 비슷합니다. 보안 회사 트렌드마이크로(Trend Micro)가 인터넷에 노출된 MCP 서버를 다시 세어 보니, 2025년 7월 492개에서 2026년 4월 1,467개로 약 3배 가까이 늘었다고 합니다.

반면 관리 체계는 턱없이 부족합니다. 딜로이트(Deloitte)가 24개국 3,235명에게 물어 보니, 2년 안에 에이전틱 AI를 쓰겠다는 곳은 74%였지만, 자율적으로 동작하는 에이전트를 관리할 성숙한 체계를 갖췄다는 곳은 21%에 그쳤습니다.

제품을 사서 쓰는 대신 직접 만드는 회사도 있습니다. 우버(Uber)는 2026년 10월 1일에 사내 MCP 게이트웨이를 설계한 과정을 엔지니어링 블로그에 공개했습니다. MCP 서버 800개 이상과 도구 5,000개 이상을 게이트웨이 하나로 묶은 사례입니다. 만든 이유는 팀마다 따로 연결을 만들다 보니 도구가 흩어지고 같은 인프라가 중복됐기 때문이라고 설명했습니다. 이 게이트웨이에서는 새로 찾은 도구도 꺼진 상태로 등록되고, 그 도구를 소유한 팀이 켜야 에이전트에 보입니다.

도어대시(DoorDash)도 7월에 MCP 서버 200개 이상을 연결하는 에이전트 게이트웨이를 만든 과정을 공개하면서, MCP는 호출하는 방법을 정해 줄 뿐 누가 무엇을 해도 되는지까지 정해 주지는 않는다고 정리했습니다.

오픈 소스 쪽에서도 같은 흐름이 보입니다. 깃허브에서 이름이나 설명에 “MCP gateway”가 들어간 저장소는 2024년 3개에서 2025년 306개, 2026년에는 9월까지만 1,764개까지 새로 생겼습니다. 대부분은 개인이 실험 삼아 만든 저장소라 시장 규모로 읽을 수는 없지만, 이 지점에 대한 관심이 늘어나는 속도는 확인할 수 있습니다.

깃허브에 새로 만들어진 MCP 게이트웨이와 에이전트 게이트웨이 저장소 수 <출처: 작가>

에이전트 게이트웨이가 필요한 진짜 이유

에이전틱 AI 재단은 이 상황을 조금 다르게 설명합니다. 이를테면 블룸버그(Bloomberg) 엔지니어들이 외부 모델과 자체 운영 모델을 연결하기 시작했을 때 부딪힌 문제는 모델 자체와는 별로 관계가 없었다고 합니다. 오히려 업계가 이미 10년 동안 풀어 온 트래픽 문제에 가까웠다는 것입니다. 에이전트가 무언가를 호출하는 요청도 결국 네트워크를 지나가는 트래픽이므로, 그 길목에서 관리하면 된다는 뜻으로 볼 수 있습니다.

이미 많은 분이 아시는 것처럼, 게이트웨이의 역할은 MCP 서버를 고치지 않고도 누가 어떤 도구를 호출할 수 있는지 정하고 그 호출을 기록하는 것입니다.

이런 게이트웨이가 필요해지는 때는 에이전트가 호출하는 도구를 제공하는 MCP 서버가 팀마다 생길 때입니다. (여기서 도구란 사내 데이터를 조회하거나 배포를 실행하는 것처럼 에이전트에 실제 작업을 시키는 기능을 말합니다.) 서버가 늘어나면 클라이언트 설정이 서버 수만큼 많아지고, 누가 어떤 도구를 호출할 수 있는지도 서버마다 따로 관리해야 합니다. 게이트웨이를 1개 두면 클라이언트는 주소 1개만 알면 되고, 통제와 이에 따른 기록을 한곳에서 관리할 수 있습니다.

이 구조를 그림으로 표현하면 다음과 같습니다.

게이트웨이가 없을 때와 있을 때의 MCP 서버 연결 구조 <출처: 작가>

앞에서 본 깃허브 사례도 이 그림으로 다시 보면 이해하기 쉽습니다. 문제가 서버 1개의 코드에 있지 않았으니 서버를 하나씩 고쳐서는 막기 어렵습니다. 여러 서버로 가는 호출이 모두 지나가는 자리에서 누가 무엇을 호출하는지 보고 정해야 합니다.

마이크로서비스 때와 같은 점, 그리고 다른 점

사실 호출이 거쳐 가는 자리에 공통 계층을 두는 이 흐름은 처음 보는 것이 아닙니다. 마이크로서비스가 늘어났을 때도 서비스마다 인증, 재시도, 관측을 따로 넣다가 그 일을 서비스 밖으로 꺼내 한곳에서 처리하는 API 게이트웨이와 서비스 메시(service mesh)가 자리 잡았습니다.

이 글에서 다룰 게이트웨이 가운데 하나인 agentgateway를 만든 솔로닷아이오(Solo.io)도 같은 이야기를 합니다. 2025년 4월 agentgateway를 발표하면서, 마이크로서비스에 서비스 메시가 필요했던 것처럼 에이전트에도 보안, 관측, 가드레일을 위한 연결 계층이 필요하다고 설명한 것입니다. 같은 회사의 램 베남(Ram Vennam)은 2026년 5월에 쓴 글에서 이 비유에 중요한 차이가 하나 있다고 덧붙였습니다. 바로 예측 가능성입니다. 마이크로서비스는 호출 경로가 코드로 정해져 있지만, 에이전트는 같은 요청을 받아도 매번 다른 도구를 다른 순서로 호출할 수 있습니다. 그래서 미리 정해 둔 호출만 허용하는 방식으로는 부족하고 호출이 지나갈 때마다 확인하고 기록하는 지점이 더 중요해집니다.

쿠버네티스 쪽을 보면 이 계층이 표준이 되기까지 시간이 꽤 걸렸다는 것도 알 수 있습니다. 쿠버네티스는 처음에 인그레스(Ingress)로 외부 트래픽을 받았지만 기능이 부족해 구현체마다 설정 방식이 달라졌습니다. 그러자 이를 정리한 Gateway API가 등장해 2023년 10월에야 정식 버전이 되었습니다. 결국 현재 쿠버네티스 공식 문서에는 인그레스는 더 이상 기능이 추가되지 않으니 Gateway API를 쓰라고 적혀 있습니다.

AI 트래픽 쪽에서도 같은 일이 벌어지고 있습니다. 모델 추론 요청을 다루는 Gateway API Inference Extension이 2025년 9월에 정식 버전이 되었고, 같은 달에는 쿠버네티스에 AI 게이트웨이를 다루는 워킹그룹도 생겨 2026년 3월에 이를 공식적으로 알렸습니다. 즉, 에이전트가 도구를 호출하는 지점을 다루는 표준도 이제 막 만들어지기 시작한 단계라고 보시면 됩니다.

그런데 에이전트 쪽에서는 프로토콜에서 먼저 변화가 생기고 있습니다. 2026년 7월에 개정된 MCP 스펙은 호출하는 메서드와 도구 이름을 요청 헤더에 따로 넣도록 했습니다. 스펙 문서에 따르면 게이트웨이 같은 중간 계층이 본문을 해석하지 않고도 요청을 확인할 수 있게 하려는 것입니다. 반면 에이전트 사이의 대화를 이어 가는 프로토콜을 다룰 IETF(Internet Engineering Task Force) 워킹그룹은 2026년 10월 8일에야 승인되었고, 첫 문서 제출 목표도 2028년 3월입니다.

에이전틱 AI 재단이 키우려는 생태계

CNCF가 쿠버네티스 생태계를 키웠을 때와의 비교

앞에서 본 Gateway API 프로젝트는 CNCF가 관리합니다. 이 재단은 2015년 7월에 구글이 쿠버네티스를 기부하면서 만들어졌습니다. 그 뒤로 처음에는 쿠버네티스뿐이던 재단에 모니터링, 서비스 메시, 게이트웨이 같은 프로젝트가 차례로 더해졌습니다. 2017년에는 지금 많은 게이트웨이의 바탕이 되는 Envoy도 CNCF 프로젝트가 되었습니다.

2026년 10월 기준으로 CNCF의 호스티드 프로젝트(hosted project)*는 졸업, 인큐베이팅, 샌드박스(Sandbox) 단계를 합쳐 230개이고 회원사는 723곳입니다. 쿠버네티스라는 중심이 먼저 있었고 그 주변에서 필요한 계층이 하나씩 채워지면서 지금의 클라우드 네이티브 생태계가 만들어졌습니다.

*호스티드 프로젝트: 재단이 상표와 저장소를 넘겨받아 중립적으로 관리하는 프로젝트를 말합니다.

에이전틱 AI 재단은 2025년 12월에 리눅스 재단(Linux Foundation) 산하에서 같은 방식으로 출발했습니다. 앤트로픽(Anthropic)의 MCP, 블록(Block)의 goose, 오픈AI(OpenAI)의 AGENTS.md를 창립 프로젝트로 두었고 이후 2026년 8월에는 구글이 시작한 A2A도 호스티드 프로젝트가 되었습니다.

이때 재단은 자신을 에이전틱 스택(agentic stack)이 만들어지는 개방적이고 중립적인 곳이라고 소개하면서, 도구 연결부터 에이전트 간 통신과 운영까지 전체 스택을 같은 방식으로, 같은 곳에서 관리하겠다고 밝혔습니다. 회원사는 2026년 10월 기준, 벌써 270곳에 달합니다. 출범 4개월 만에 이미 같은 시기 CNCF 회원 수의 두 배를 넘은 수치를 달성했습니다.

두 재단의 구성을 비교해서 정리하면 다음과 같습니다.

CNCF와 에이전틱 AI 재단의 생태계 구성 비교 <출처: 작가>

에이전틱 AI 재단에서 관리하는 두 개의 게이트웨이

여기서 운영 계층에 해당하는 것이 게이트웨이입니다. agentgateway를 만든 솔로닷아이오는 구글과 함께 만든 앰비언트 메시(ambient mesh)를 이스티오(Istio)에 기여했고, 자사 게이트웨이를 kgateway라는 이름으로 CNCF에 기부해 샌드박스 프로젝트가 된 이력이 있습니다. 이 회사가 2025년 4월에 발표한 agentgateway도 4개월 뒤인 8월에 리눅스 재단에 기부되었으며, 2026년 6월에는 에이전틱 AI 재단의 호스티드 프로젝트가 되었습니다.

한편, 블룸버그와 테트레이트(Tetrate)가 시작한 Envoy AI Gateway도 2026년 9월 Agent Router로 이름을 바꾸면서 같은 재단의 프로젝트가 되었습니다.

그 결과 지금 에이전틱 AI 재단의 호스티드 프로젝트 6개 가운데 2개가 유사한 역할을 하는 게이트웨이입니다. 솔로닷아이오와 테트레이트는 모두 각자의 프로젝트를 바탕으로 한 상용 제품을 따로 팔면서도, 오픈 소스는 중립적인 재단에 기부했습니다. 저는 이런 기부가 어쩌면 이 지점을 두고 벌어지는 매우 치열한 경쟁을 그대로 보여준다고 생각합니다.

재단 쪽에서 보면, CNCF에서 Envoy가 여러 게이트웨이의 공통 바탕이 되었던 것처럼 에이전틱 AI 재단도 MCP와 A2A 옆에 운영 계층을 함께 두려는 것으로 보입니다. 에이전트 생태계 전체를 한곳에서 키우겠다는 것이죠.

다만 두 게이트웨이는 배치 방식이 다릅니다. agentgateway는 요청을 직접 처리하는 단독 프록시이고, Agent Router는 Envoy를 확장한 구조라 요청이 Envoy를 2번 지나갑니다. 이를 그림으로 표현하면 다음과 같습니다.

에이전트와 MCP 서버 사이에 놓이는 게이트웨이 2개의 배치 차이 <출처: 작가>

두 게이트웨이를 직접 설치해 확인한 4가지

그러면 실제로, 이 두 가지 게이트웨이를 써 보면 어떨까요?

두 프로젝트를 쿠버네티스 클러스터에 직접 설치하고 정책을 걸어 가며 호출해 봤습니다. 결론부터 말씀드리면, 이 글에서 확인한 버전(agentgateway v1.5.0, Agent Router v1.1.0)을 기준으로 두 프로젝트가 통제하는 범위는 서로 꽤 다릅니다.

도구 이름 단위로 막는 것은 양쪽 모두 쓴 대로 동작하지만, 호출할 때 넘긴 값까지 보고 판단하는 통제에서는 갈립니다. 예를 들어 삭제 도구를 아예 막는 대신 운영 환경의 레코드를 지우는 호출만 막고 싶다고 해 보죠. Agent Router는 인가(authorization, 누가 무엇을 해도 되는지 판단하는 것) 정책만으로 처리할 수 있지만, agentgateway는 v1.5.0에서 외부 검사 서버를 따로 두어야 했습니다.

여기에 더해 사용자가 주로 보는 설정 문서에는 별다른 언급이 없지만, 실제로는 문서나 설정에 적은 대로 동작하지 않는 경우도 있었습니다. 확인한 것을 정리하면 다음과 같습니다.

*표의 시간은 같은 클러스터에서 게이트웨이를 거치지 않고 직접 호출한 경우와 비교해 늘어난 값(p50, 응답 시간을 줄 세웠을 때 가운데 값)입니다. 두 게이트웨이를 같은 조건에 두고 비교한 것은 아닙니다.

다만 두 프로젝트 모두 빠르게 바뀌고 있습니다. 이 글을 작성하던 2026년 10월에도 agentgateway v1.6.0(10월 2일)과 Agent Router v1.2.0(10월 7일)이 나왔습니다. agentgateway에서는 라우트 단위 인가 정책으로 넘긴 값 조건을 적용할 수 있게 되었고, 외부 검사 서버 없이도 막아야 할 호출이 막히는 것을 다시 확인했습니다. Agent Router에서는 세션 암호화에 쓰는 시드(seed, 암호화에 쓰는 초기값)의 기본값이 무작위로 만들어지도록 바뀌었습니다.

그러니 위 표는 고정된 차이가 아니라, 계속 개발 중인 두 프로젝트의 현재 모습으로 읽어 주시기 바랍니다. 측정 조건과 항목별 결과는 공개 저장소의 agentgateway 쪽과 Agent Router 쪽에 정리해 두었으니 참고하면 좋겠습니다.

게이트웨이 도입을 고민하면 좋은 시점

그럼 이제 어떤 경우에 게이트웨이 도입을 고민하면 될까요?

도구를 제공하는 MCP 서버가 여럿이 되고 누가 무엇을 호출할 수 있는지를 서버마다 따로 관리하기 어려워졌다면 그때부터 검토해 보면 됩니다. 반대로 MCP 서버가 1개뿐이거나 도구 이름 단위로 막는 것으로 충분하다면 굳이 넣지 않아도 됩니다. 이번에 확인한 두 게이트웨이를 거쳐도 도구 호출이 빨라지지는 않았고 한 번 더 거치는 시간만 늘었기 때문입니다.

도입하기로 정하셨다면 다음 3가지는 꼭 확인해 보시길 권합니다.

1) 정책을 넣은 뒤에 에이전트가 받는 도구 목록 확인하기

에이전트는 게이트웨이에서 도구 목록을 먼저 받고 그 안에서 호출할 도구를 정합니다. 그런데 이번에 확인해 보니, 정책을 넣은 다음 게이트웨이 상태에는 아무 문제가 없는데도 이 목록이 빈 채로 돌아오는 경우가 있었습니다. 이렇게 되면 에이전트 입장에서는 도구가 전혀 없는 것과 같습니다. 그러니 정책을 넣은 뒤에는 목록을 한 번 받아서 도구가 제대로 남아 있는지 확인해 보셔야 합니다.

2) 막으려던 호출이 실제로 막히는지 직접 호출해 보기

정책이 오류 없이 등록되었다고 해서 그 조건이 실제로 적용된다는 뜻은 아니었습니다. 예를 들어 호출할 때 넘긴 값을 조건으로 적은 정책이 문제없이 등록되었지만, 실제로는 그 조건이 평가되지 않아 의도와 다르게 동작했습니다. 그래서 막아야 하는 호출과 허용해야 하는 호출을 각각 직접 보내서 결과가 정책에 적은 대로 나오는지 확인하는 것이 좋습니다.

3) 기본값으로 둔 설정이 운영 환경에 맞는지 확인하기

이번에 Agent Router에서 확인한 약 20ms의 지연은 대부분 구조 때문이 아니라 세션 암호화 반복 횟수라는 설정의 기본값에서 나왔습니다. 이 값을 낮추자 늘어나는 시간이 약 0.5ms로 줄었습니다. 다만 이 값은 보안과도 관련이 있어 무조건 낮추면 되는 것은 아닙니다. 따라서 기본값을 그대로 쓰는 설정이 있다면, 그 값이 왜 그렇게 정해져 있는지와 운영 환경에 맞는지를 함께 확인해 보시면 됩니다.

마치며

처음의 질문으로 돌아가 보겠습니다. 에이전틱 AI 세계에서 게이트웨이는 어떤 의미를 가질까요?

제가 확인한 범위에서 답을 하자면, 게이트웨이를 두면 에이전트가 늘어날수록 함께 늘어나는 호출을 서버를 하나하나 고치지 않고도 한곳에서 통제하고 기록할 수 있습니다. 깃허브 사례처럼 서버 1개를 고쳐서는 막기 어려운 문제가 생기고, 호출은 몇 달 만에 수십 배로 늘고 있습니다. 여러 회사가 이 영역에 제품을 내놓고 에이전틱 AI 재단이 게이트웨이 프로젝트를 2개나 받아들인 이유도 여기에 있다고 생각합니다.

하지만 아직은 시작 단계입니다. 쿠버네티스에서 인그레스가 Gateway API로 정리되기까지 몇 년이 걸렸던 것처럼 에이전트가 도구를 호출하는 지점을 다루는 표준도 이제 막 만들어지는 중입니다. 심지어 재단의 두 프로젝트조차도 통제하는 범위와 기본값이 서로 달랐습니다. CNCF가 쿠버네티스를 중심으로 생태계를 키워 온 것처럼 에이전틱 AI 재단이 MCP와 A2A를 중심으로 이 계층을 어떻게 키워 갈지 계속 지켜보시면 좋을 것 같습니다.

이 글이 에이전트를 실제 업무에 연결하려는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

저는 에이전틱 AI 재단의 앰배서더로 활동하고 있고, 이 글에서 다룬 agentgateway와 Agent Router는 그 재단의 프로젝트입니다. 그런 만큼 좋은 점만 쓰기보다 문서에 적힌 대로 되지 않는 부분까지 직접 확인해서 담았습니다.

작가

조훈 (CNCF&AAIF 앰버서더)

쿠버네티스 및 AI 네이티브 기술 전문가로, CNCF와 에이전틱 AI 재단(AAIF) 글로벌 앰버서더이자 Kubestronaut이다. 쿠버네티스랩을 운영하며 인프라 자동화 기술을 연구하고 공유한다. ‘IT 인프라 엔지니어 그룹’ 운영진이자 오픈소스 컨트리뷰터로 활동 중이며, 맞춤형 인프라 교육, 쿠버네티스 비용 최적화, 멀티 LLM 및 AI 에이전트 비교 검증 등 다양한 실무 PoC를 수행하고 있다. 최근 출간한 『AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드 코드』를 포함해 총 5권의 IT 서적을 집필했으며, 인프런 강의 및 요즘IT 기고 등 지식 공유 활동을 이어가고 있다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>

RAG 다음은 Knowledge Layer: 검색 뒤에 남는 4가지

<출처: 작가, ChatGPT 생성>

2026년의 벤더 발표문을 나란히 놓고 보면 낯선 이름들이 눈에 띕니다. 마이크로소프트는 Foundry IQ를 “기업 데이터를 위한 관리형 지식 계층”이라고 정의하고, AWS는 7월 가이드의 제목을 “온톨로지, 기호 추론, 가상 지식 그래프를 이용한 에이전틱 AI용 시맨틱 레이어”로 달았습니다.

Snowflake는 Horizon Context 발표 글을 “AI, BI, 앱을 위한 거버넌스가 적용된 컨텍스트 레이어”로 잡았고, Forrester는 같은 영역을 아예 context layer라 부릅니다.

이렇게 이름은 회사마다 다릅니다. 마이크로소프트 회사 안에서도 가장 위에 있는 이름은 ‘knowledge layer’가 아니라 ‘intelligence layer’이고, knowledge layer라 불리는 Foundry IQ는 그 아래 구성요소 중 하나입니다. Fabric IQ의 온톨로지 문서는 한 페이지 안에서 같은 대상을 “시맨틱 레이어”, “공유 컨텍스트 레이어”, “비즈니스 컨텍스트 레이어” 세 가지로 부르기도 합니다.

이번 글은 어느 한 벤더의 정의를 보는 게 아니라, 이 회사들이 서로 다른 이름으로 풀고 있는 문제가 무엇인지를 살펴보려고 합니다.

<출처: 작가, 각 사 공식 문서 기반 재구성>

RAG를 만들어 놓고도 생기는 문제들

1) 검색에 성공했다고 정답을 아는 건 아니다

작년 할루시네이션 논문 리뷰에서 “이론상 RAG가 할루시네이션을 더 줄이려면 Vector보다는 ‘유사한게 아니라 명확하고 확실하게 검색되는 것’이 더 도움을 줄 수 있다”라고 리뷰했었습니다.

이젠 여기에 하나 덧붙여, “정확히 찾는다”와 “찾은 것 중 무엇을 믿는다”는 다른 계층의 문제인 것 같습니다. 앞은 검색의 일이고, 뒤는 검색 관련도를 올리는 것만으로는 풀리지 않는 일입니다.

2) 검색은 이미 한참 발전했지만, 그래도 남는 문제가 있습니다

이 글에서 다루는 문제가 검색이 아직 부족해서 생기는 문제라고 오해하기 쉬운데, 그렇지 않습니다. 검색 자체는 RAG보다 훨씬 오래된 분야입니다. 웹 검색과 포털 검색, 자연어 검색, 그 밑의 검색 엔진까지 이미 다 있었고, RAG는 그 검색 결과를 LLM에 넣어 주는 데서 시작했습니다.

물론 그건 나이브 RAG 얘기고 요즘 검색은 다르긴 합니다. Self-RAG는 검색을 할지 말지를 모델이 판단하게 만들었고, CRAG는 가벼운 평가기를 앞에 두고 검색 결과를 Correct / Incorrect / Ambiguous로 나눈 뒤 조건부로 웹 검색까지 확장합니다.

Microsoft가 8월 31일 갱신한 문서에서 새 검색 기능인 agentic retrieval을 어떻게 정의했는지 보면 방향이 보입니다. “검색 증강 생성(RAG) 패턴과 에이전트 간 워크플로를 위한 것이다”고요. 이름은 새로 지었지만 RAG를 밀어내는 기능이 아니라, RAG 안에서 검색 단계를 더 잘하게 만드는 기능이라고 스스로 못을 박아 둔 겁니다.

3) Agent가 오자 문제의 크기가 달라졌습니다

사람이 검색 결과를 직접 보던 시절엔 이상하면 “사람이” 멈췄습니다. 반년 전 정책 문서가 위에 올라와도 날짜를 보고 “이건 옛날 거네” 하고 넘기고, 남의 팀 문서가 섞여 나와도 “이건 내가 볼 게 아닌데” 하고 닫습니다.

자율 에이전트는 그 판단을 대신하기로 한 쪽이라, 검수를 사람이 해 준다는 전제를 둘 수 없습니다. 옛날 문서를 거르는 일도, 봐서는 안 될 문서를 거르는 일도 시스템이 맡아야 합니다. 그래서 벤더들이 먼저 손댄 게 권한입니다. 검색이 끝난 뒤 사람이 거르던 것을 검색쪽으로 밀어 넣기 시작했습니다.

Foundry IQ 문서는 질의 시점에 권한을 강제한다고 설명하는데, ACL을 동기화하고 민감도 레이블을 확인한 뒤 “호출자의 Microsoft Entra 신원으로 질의를 실행”하고 답변에 출처를 붙입니다.

사람이 마지막 안전장치였던 구조에서 사람을 빼면, 그 안전장치를 시스템 어딘가에 다시 만들어 넣어야 합니다. 그래서 문제의 크기가 달라집니다. 예전에는 검색이 잘 되느냐만 보면 됐는데, 이제는 찾아온 문서가 지금 맞는 값인지, 이 사람이 봐도 되는 문서인지, 어디서 온 것인지까지 시스템이 답해야 합니다.

검색이 잘 돌아간 다음에 남는 네 가지 문제

Snowflake가 8월 17일 사내 컨텍스트 레이어를 만든 경험을 공개했는데, 자체 진단 문장이 인상적입니다. “병목은 한 번도 데이터였던 적이 없다”라고 쓰고, “병목은 컨텍스트였다”고 합니다. (규모는 2025년 7월 한 달에 400명 넘는 사내 사용자가 5,400건 이상을 질의)

이를 정합성, 최신성, 권한, 그리고 출처 네 가지로 나눠 살펴보겠습니다.

<출처: 작가>

1) 같은 것을 서로 다르게 부릅니다

Snowflake 글이 드는 사례는 “활성 고객이란 무엇인가?”라는 질문 하나입니다. 어떤 팀은 credits_consumed > 0 and account_type != ‘TRIAL’로 세고, 어떤 팀은 리전 조건 없이 COUNT(DISTINCT account_id)로 셉니다.

둘 다 SQL은 잘 돌아가고, 둘 다 “active customer 수”라는 결과로 나오지만, 두 숫자는 다릅니다. Microsoft도 Fabric IQ 문서에서 같은 진단을 합니다. “조직이 데이터를 다루는 방식은 여전히 ‘의미’보다는, 기계 처리를 위해 설계된 테이블과 스키마 같은 구조에 머물러 있다”

이건 AI 때문에 생긴 문제가 아닙니다. LLM 이전에도 있었고, LLM 이후 컨텍스트의 중요성이 커지면서 다시 화두가 됐을 뿐이죠. 이게 얼마나 오래된 문제인지는 빅테크 엔지니어링 블로그를 거슬러 올라가 보면 바로 나옵니다.

Uber는 2020년 Databook 글에서 “각기 다른 메타데이터 시스템을 사용하면서 통합된 관점이 사라졌고, 같은 작업이 반복되는 비효율도 생겼다” 라고 썼습니다. LinkedIn은 그보다 4년 앞선 2016년 글에서 같은 표현이 문맥에 따라 다른 뜻이 되는 문제를 지식 그래프의 핵심 난제로 꼽았습니다. Pinterest는 2020년 글에서 동일성 판단을 끝까지 자동화하지 못했다고 인정하고요.

Pinterest가 말한 동일성 판단은 “이 둘이 같은 것을 가리키는가”를 기계가 정하는 일입니다. 저는 그 판단의 가장 작은 시작점부터 잡았습니다. 조사가 특히 문제였습니다. 사용자가 “XX시트가”라고 물으면 색인에 들어 있는 원형 토큰 “XX시트”를 못 찾아서 시스템이 “찾지 못했다”고 답하는 경우가 있었습니다. 검색 엔진이나 임베딩이 잘못된 것도 아니었습니다.

1차 해결은 질의 쪽 접두사 확장이었습니다. 질의 토큰 말미 한두 글자를 잘라내고 와일드카드를 붙이는 방식인데 이걸로 “XX시트가”는 잡혔습니다. 그런데 접두사만으로는 두 글자 조사가 안 잡혔고, 색인 쪽 문장에 조사가 붙은 방향은 여전히 실패했습니다.

그래서 2차 해결로 한글 bigram 분절을 색인과 질의 양쪽에 넣었습니다. bigram이 접두사 확장을 대체한 건 아닙니다. 세 글자 이상 원형 토큰은 여전히 접두사 확장이 잡고, 접두사 확장이 놓치는 경우를 bigram이 메우는 식으로 둘을 병행하게 했습니다.

<출처: 작가>

왜 bigram일까요? 두 글자 단위로 쪼개면 조사가 앞뒤 어디에 붙어도 원형 토큰의 bigram이 살아남기 때문입니다. 예를 들어 색인 문장에는 “연차는”이 있고 사용자는 “연차가”라고 물으면, 둘 다 “연차”라는 bigram을 갖고 있습니다.

정합성이 어렵다고 하면 보통 온톨로지나 엔티티 해소 같은 큰 얘기부터 떠올리는데, 그 전에 이 부분부터 잡는 게 좋습니다.

2) 최신성은 선택이 아니라 필수

Atlassian은 Rovo 검색에서 신선도를 최종 수정 시각으로 판정하되 그 기준이 제품마다 다르다고 설명합니다. “최신성은 가장 최근 업데이트 시점을 기준으로 결정되며, 제품마다 월, 주, 일 단위로 서로 다르게 적용된다”

더 깊이 들어가면 색인 자체의 지연이 있습니다. Glean 제품 문서를 보면, 변경은 웹훅으로 받아 보통 “1~5분” 안에 처리하고 웹훅이 놓친 변경은 24시간 주기 증분 크롤러가 수집합니다. 크롤 대상은 “콘텐츠, 연결된 권한, 활동 메타데이터” 세 가지입니다. 권한도 콘텐츠와 똑같이 동기화 대상이라는 뜻이고, 전파가 늦어지면 권한도 그만큼 낡은 채로 남습니다.

제 경우엔 옛날 문서가 결과에 섞여 들어오고, “비슷하다”는 이유만으로 상위에 랭킹되는 문제가 있었습니다. 임베딩 유사도는 시간을 모릅니다. 본문에 “2026-01”과 “2026-07”이 글자로만 적혀 있으면 벡터 위에서는 거의 같은 값이 되니까요. 그래서 날짜는 임베딩에 맡기지 않고 검색 조건과 랭킹용 메타데이터로 따로 뺐습니다.

그리고 질의에 담긴 시간 의도를 먼저 셋으로 나눕니다.

as_of: “2026년 7월”, “상반기”처럼 시점이 박힌 질의. 이때만 시작과 끝이 정해진 UTC 범위로 결정론적으로 풀어 검색 전에 하드 필터로 겁니다.
recency: “최근”, “요즘”처럼 최신을 묻지만 정확한 범위를 알 수 없는 질의. 하드 필터를 걸지 않습니다.
agnostic: 시간과 무관한 질의. 마찬가지로 범위 없음.

세 경우 모두 요청이 들어온 시각을 검색 쪽에 같이 넘기는 일을 공통으로 합니다.

그 시각을 기준으로 프롬프트에 오늘 날짜를 적어 주고, 그 시각보다 뒤에 발행된 문서는 결과에서 뺍니다. 모델은 오늘이 며칠인지 모르고, 날짜 라이브러리가 알아서 잡는 “지금”도 서버 시계와 시간대에 따라 달라질 수 있습니다.

그래서 날짜 계산만큼은 요청 시각을 받아 코드에서 직접 하기로 했습니다. 그리고 as_of로 분류됐는데 표현을 해석하지 못하면 필터 없이 통과시키는 폴백을 뒀습니다. 시간 조건을 잘못 걸어서 있는 문서를 못 찾는 쪽이 더 나쁘다고 봤기 때문입니다.

<출처: 작가>

3) 권한 확인은 검색 뒤가 아니라 앞에서

“권한 확인은 항상 검색 뒤가 아니라 검색 앞에서 이뤄져야 한다” Microsoft ISE 팀이 4월에 쓴 글에서 못 박은 문장입니다. 이유도 같은 글에 있는데, SharePoint는 계층적이고 상속되는 권한 체계를 제공하지만, “Blob Storage, 검색 인덱스, LLM 검색 계층과 같은 후속 시스템은 SharePoint의 접근 제어 목록(ACL)을 자체적으로 해석하지 못한다” 때문입니다.

Microsoft는 Copilot 배포 지침에서 배포 전에 할 일의 첫 번째로 “과도하게 부여된 공유 권한 바로잡기(Remediate oversharing)”를 둡니다. AI가 권한을 잘 지켜도 그 권한 자체가 원래 엉망이면 소용이 없다는 이야기죠.

앞 절에서 권한에도 크롤 지연이 있다고 했는데, 그래서 색인된 권한만 믿지 않는 구조가 나옵니다. Atlassian은 같은 글에서 리랭킹이 끝난 뒤 원 제품에 한 번 더 확인한다고 밝힙니다. “재랭킹이 끝난 뒤, 원본 퍼스트파티 또는 서드파티 제품을 기준으로 한 번 더 권한 검증을 수행”

저도 만들면서 같은 결론을 내렸습니다. 검색 단계에서부터 그 사람이 볼 수 있는 문서만 후보에 올라와야지, 다 찾아 놓고 답변 직전에 걸러내는 구조는 늦습니다.

<출처: 작가, Microsoft ISE 블로그, Atlassian 엔지니어링 블로그, Microsoft Learn 문서 기반 재구성>

규모가 있는 회사라면 SSO에서 넘어오는 신원 정보를 기준으로 테이블 스키마 같은 데이터 소스 단위의 접근 제한을 걸어야 하고, 프롬프트에 가드레일을 적는 데서 그치지 말고, 요청이 모델에 닿기 전에 코드가 강제로 거르는 하드룰로 박아 둬야 합니다. 누가 어떤 테이블을 볼 수 있는지는 모델이 아니라 코드가 판단해야 합니다.

4) 출처, 그리고 출처가 없을 때

Uber는 사내 온콜 코파일럿을 만들면서 벡터 DB 검색 결과마다 sub-context 절과 그 소스 URL을 명시적으로 함께 넣었다고 밝혔습니다. 같은 회사가 2025년에는 에이전틱 RAG로 바꾼 뒤 수용 가능한 답변 비율이 상대적으로 27% 늘고 잘못된 조언이 상대적으로 60% 줄었다고 자체 측정 결과를 발표했습니다. 절대값이 아닌 상대 개선치이고, 대상은 보안, 프라이버시 정책 문서 40여 건에 골든 질의 100여 건입니다. 평가자는 내부 전문가고요.

여기서부터는 출처를 어떻게 붙이느냐가 아니라, 출처가 없을 때 답을 할지 말지의 문제입니다.

저는 이 규칙을 좀 극단적으로 적용해, 검색 결과가 없으면 LLM을 아예 호출하지 않고 “찾지 못했다”를 반환하게 했습니다. 그럴듯한 문장을 만들어 볼 기회 자체를 주지 않는 겁니다. 다만 “찾지 못했다”를 판정하는 것 자체가 생각보다 어렵습니다. 검색 엔진은 원래 유사한 것을 최대한 긁어모은 뒤 정말 아무것도 없을 때만 없다고 말하는 쪽으로 만들어져 있습니다. 그게 검색 엔진 바닥의 오랜 규칙이라, 없다는 답을 자신 있게 내놓으려면 어디까지를 찾은 것으로 칠지 기준이 먼저 있어야 합니다.

그리고 이 규칙을 평가 지표에 박아 넣었습니다. 골든셋에 함정 질문을 섞어 두고, 함정 질문은 “찾지 못했다”를 반환해야 정답으로 채점합니다. 모른다고 답해야 점수가 오르는 항목을 만들어 둔 셈인데, 이렇게 안 해 두면 정확도를 올리려는 모든 튜닝이 일단 뭐라도 답하자는 방향으로 흐를 수도 있었습니다. 모른다고 답하는 쪽에 점수를 주자는 발상은 앞서 인용한 할루시네이션 논문 리뷰의 영향이기도 합니다.

2026년, 회사들은 ‘검색 다음에 남는 문제’를 뭐라고 부르나

1) 이름은 다 다르고, 표준은 없습니다

앞의 문제들을 각 회사가 어떻게 부르는지 원문 표현 그대로 모아 봤습니다.

Microsoft IQ: 최상위 계층. “기업 AI를 위한 통합 지능 계층”이고 구성은 Work IQ / Fabric IQ / Foundry IQ / Web IQ 넷입니다.
Foundry IQ: 그 아래 항목이고 “기업 데이터를 위한 관리형 지식 계층”으로 정의됩니다. 색인과 검색 인프라는 Azure AI Search가 맡습니다.
AWS: 최상위 용어가 Semantic Layer이고 Knowledge Layer는 그 안의 여러 층 가운데 하나입니다. ontology(T-Box)를 인스턴스 데이터(A-Box)에 적용해 데이터를 지식으로 바꾸는 DIKW의 knowledge tier라고 설명합니다.
Snowflake: 정의되는 용어는 semantic layer와 semantic view입니다. 사내 블로그 제목에는 “사내 컨텍스트 레이어”가 있지만 본문에서 context layer가 정의되지는 않습니다.
Databricks: Unity Catalog semantics. 카탈로그 데이터 위에 표준 지표와 용어, 조직 구조를 정의하는 도구 모음이라고 쓰고, semantic layer나 knowledge layer라는 표현은 이 문서에서도, 핵심 구현을 설명하는 metric views 문서에서도 쓰지 않습니다.
그 밖에: Glean은 콘텐츠, 사람, 활동을 잇는 Knowledge Graph라 부르고, Palantir는 Ontology를 “조직을 위한 운영 계층”으로 정의하면서 actions와 functions 같은 실행 요소까지 범위에 넣습니다. 애널리스트인 Forrester는 context layer라 부르고요.

제품 자체를 knowledge layer라고 정의하는 곳은 Microsoft Foundry IQ 한 곳이고, AWS는 Knowledge Layer를 제품명이 아니라 참조 아키텍처 안의 계층 이름으로 씁니다. 아직 “업계 표준 용어”라고 부르기는 어려운 상태로 보입니다.

2) 그런데 의미 규격에는 모이기 시작했습니다

이름은 제각각이지만, 지표와 온톨로지를 적는 형식만큼은 한 규격으로 모이기 시작했습니다. 저는 이름 싸움보다 이쪽이 중요하다고 봅니다.

2025년 9월 Snowflake, Salesforce, dbt Labs 등 17개사가 Open Semantic Interchange를 출범시켰습니다. 목표는 “공통의, 벤더 중립적인 시맨틱 모델 규격”이고, 문제 진단은 “도구마다 비즈니스 지표와 메타데이터를 다르게 해석한다.”입니다.

11월엔 AWS, Informatica, JPMC 등이 합류해 26곳이 됐고, 2026년 7월 8일 이 이니셔티브가 Apache 인큐베이터에 받아들여져 Apache Ossie (Incubating)로 이름을 바꿨습니다. 참여 규모는 “50개 이상의 조직”이고, 아직 최상위 프로젝트가 아닌 인큐베이팅 단계입니다.

범위도 정확히 해 두면, Ossie는 “시맨틱 레이어와 온톨로지 양쪽을 위한 개방 규격”, 곧 지표, 차원, 관계와 비즈니스 규칙을 적는 형식이지 검색이나 권한, 최신성까지 묶는 규격은 아닙니다.

이름은 아직 회사마다 다르지만 규격은 하나로 모이고 있습니다. 경쟁사들이 지표와 온톨로지를 적는 형식까지 맞추기로 했다는 건, 검색 다음에 생기는 문제, 적어도 그중 정합성만큼은 다들 같은 문제로 보고 같은 방향으로 풀고 있다는 뜻으로 보입니다.

3) 그럼 RAG라는 말은 사라진 건가?

Microsoft의 agentic retrieval 문서는 이 기능을 RAG 패턴을 위한 것으로 정의하고, 문서 설명문도 “더 나은 RAG와 에이전트 워크플로를 위해”입니다. 더 눈에 띄는 건, 이번에 원문을 확인한 여섯 곳의 2025년 9월 이후 신규 제품과 객체 이름에 RAG가 하나도 붙지 않았다는 점입니다.

knowledge base, knowledge source, agentic retrieval, Horizon Context, Unity Catalog semantics, Enterprise Graph(2025년 9월 발표), Knowledge Layer, Context Engine이 그 목록입니다.

사견으로, 적어도 이번에 본 벤더들의 최근 제품명에서는 RAG보다 knowledge, context, semantic이 앞에 나옵니다. RAG가 사라진 게 아니라 구현 기법 쪽으로 내려가고 있는 것으로 보입니다.

LlamaIndex는 2025년 5월에 “RAG는 죽었다, 에이전틱 검색이여 영원하라”라는 제목의 글을 올렸는데, 제목은 죽음을 말하고 결론은 검색이 더 중요해졌다는 쪽이었습니다. (프레임워크 벤더의 마케팅 언어라는 점은 감안해야 합니다.)

4) 그래서 이 글에서 말하는 Knowledge Layer는?

AI가 여러 지식원 위에서 의미, 관계, 검색, 권한, 출처, 최신성을 함께 고려해 지식을 사용할 수 있게 해 주는 중간 계층이라는 아키텍처 관점입니다. 특정 제품이나 구현(기술) 이름이 아니라 역할 이름으로 쓰는 셈입니다.

AWS 기준으로 문서 청킹과 벡터 검색은 Data Layer 소관이고 Knowledge Layer가 아닌데, Microsoft는 chunking과 임베딩을 Foundry IQ의 능력으로 열거합니다. 두 회사가 같은 단어를 써도 가리키는 범위가 다르고, 부분적으로만 겹칩니다.

그래서 Knowledge Layer는 무엇으로 되어 있나?

1) 실제 구현은 하나의 제품이 아니라 조립식입니다

AWS 가이드에서 Knowledge Layer의 내부를 열어 보면 완제품 하나가 아니라 네 덩어리를 조립한 구조입니다.

Virtual Knowledge Graph 서비스는 원본을 옮기지 않고 그래프처럼 질의하게 해 주고, Neptune은 ontology와 인스턴스 데이터를 저장합니다. 추론기와 규칙을 처리하는 Symbolic Reasoning 서비스, 지표 정의를 담는 Metric Store가 나머지 둘입니다.

그러니까 “Knowledge Layer를 도입한다”는 문장은 실제로는 “이 중에 우리한테 필요한 걸 고른다”에 가깝습니다. 사견으로, AWS 목록의 중심에 Neptune 같은 자사 서비스가 놓여 있는 건 이 참조 아키텍처가 곧 판매 구성이기도 하다는 뜻이라, 목록을 그대로 따라 사기보다 우리 문제에 맞는 부품만 고르는 게 맞다고 봅니다.

<출처: 작가, AWS Prescriptive Guidance 및 Microsoft Learn 문서 기반 재구성>

2) Vector DB도, Knowledge Graph도, Ontology도 그 자체로는 아닙니다

“온톨로지를 도입했으니 지식 계층이 생겼다!” 가 가장 흔한 오해인 것 같은데, W3C의 OWL 2 정의를 보면, ontology는 “세계의 어떤 부분에 대한 정밀한 서술문의 집합”으로 정의되고 구성은 classes, properties, individuals, data values입니다.

검색도, 권한도, 실행도 이 정의 안에 없습니다.

Microsoft가 역할을 나눠 쓴 문장도 이 구분을 보여 줍니다. “온톨로지는 무엇이 왜 연결되는지를 선언하고, 그래프는 그 연결을 저장하고 순회한다.” 그래프 쪽 대표 사례인 GraphRAG도 정확히 쓰면 문제를 해결했다기보다 해결을 제안하고 입증을 시도한 쪽이고요.

3) MCP로 다 연결하면 되는 것 아닌가요?

MCP 스펙이 스스로 뭐라고 말하는지 먼저 보겠습니다. (2026년 7월 28일 개정판 기준)

자기 정의: “LLM 애플리케이션과 외부 데이터 소스, 도구를 매끄럽게 통합하게 해 주는 개방형 프로토콜”
아키텍처: “MCP는 무상태 프로토콜이다. 모든 요청은 자기완결적이며 프로토콜 버전과 기능 정보를 스스로 지닌다.” 2025년 11월판까지는 “상태를 가진 세션 프로토콜(a stateful session protocol)”이었는데, 이번 개정에서 initialize 핸드셰이크와 세션을 걷어내고 무상태로 바꿨습니다.
Resources: “사용자나 AI 모델이 쓸 컨텍스트와 데이터”. URI로 식별되고 “텍스트 또는 바이너리 데이터를 담을 수 있는” 형태로 전달됩니다.
범위 열거: Base Protocol에 서버 기능 Resources / Prompts / Tools, 클라이언트 기능 Elicitation, 그리고 설정과 진행률, 취소, 오류 보고 같은 부가 유틸리티. 예전에 있던 Sampling과 Roots, 로깅은 이번 개정에서 deprecated로 내려갔고, Tasks 같은 것은 코어 밖의 확장으로 빠졌습니다. 설계 원칙은 여전히 “코어 프로토콜은 최소한의 필수 기능만 제공한다.”입니다.

스펙이 규정하는 범위는 연결입니다. 다만 MCP 스펙에도 Security and Trust & Safety 절은 있어서, “MCP는 신뢰를 안 다룬다”고 쓰면 틀립니다. 그 절이 다루는 건 사용자 동의와 도구 안전성 쪽입니다. 규모로는 이미 표준이라 불러도 될 만합니다. 2024년 11월 공개 뒤 2025년 12월 Linux Foundation 산하 재단에 기부됐고, 그 시점에 활성 공개 서버가 1만 개를 넘었다고 하니까요.

제가 쓴 글에서 “MCP는 연결 표준이지 검색 품질 표준이 아닙니다. 검색이 구리면 MCP로 연결해도 구리다.”라고 썼는데요. 지금은 검색 품질만이 아니라 앞에서 본 정합성, 최신성, 권한, 출처의 우선순위까지도 이 스펙이 정해 주지는 않습니다.

그래서 저는 그 규칙을 MCP 서버 코드 안에 직접 넣었습니다. 밖으로 내놓은 도구는 위키 검색과 문서 가져오기 둘뿐입니다.

어려웠던 건 이 서버를 호출하는 쪽이 사람이 아니라 LLM 에이전트라는 점이었습니다. 사람이 쓰는 화면이면 입력값은 폼이 제한해 주고, 이상한 결과가 와도 사람이 알아채고 넘깁니다. 에이전트는 다릅니다. 호출 인자를 스스로 지어서 넘기고, 서버가 돌려준 문서 내용을 그대로 다음 판단의 재료로 씁니다. 그래서 값이 엉뚱하게 들어올 수 있고, 문서 안에 적힌 문장을 자기한테 내린 지시로 착각할 수도 있습니다. 그런 일이 생겨도 서버 쪽에서 막히도록 규칙을 코드에 넣어야 했습니다.

# 실제 코드는 아니고, 사내 시스템의 MCP 도구 처리 규칙을 흐름만 남겨 재구성한 의사코드
# 전체 보안 설계가 아니라 MCP 서버가 책임지는 입력 통제의 일부만 단순화한 것

def wiki_fetch(doc_id, char_offset=0, limit=None):
    limit = clamp(limit or LIMIT_DEFAULT, 1, LIMIT_MAX)   # 호출하는 에이전트가 아무 값이나 넘길 수 있으니 서버가 범위를 강제
    body = load(doc_id)

    if char_offset > len(body):
        # 빈 응답을 "내용 없음"으로 오해하지 않도록 범위 초과를 명시적으로 알린다
        return error(f"char_offset {char_offset:,}이 본문 길이({len(body):,}자) 범위를 벗어난다")

    body = sanitize(body)              # 1. 정화: 원천 문서를 지시로 오독하지 않게
    body = truncate(body, MAX_FETCH)   # 2. 자르기: 최대 길이는 실제로 넘어가는 결과 기준이어야 컨텍스트 예산이 지켜진다
    return wrap_with_boundary(body)    # 3. 경계 태그

예를 들어, 에이전트가 한 번에 가져갈 글자 수(limit)는 에이전트가 아무 값이나 만들어 넘길 수 있으니, 서버가 최소 1에서 최대치 사이로 강제로 맞춥니다. 코드의 clamp가 그 일을 합니다.

본문을 자를 때의 최대 길이도 서버가 마지막에 내보내는 결과 기준으로 잡습니다. 에이전트가 한 번에 읽을 수 있는 양(컨텍스트 창)은 정해져 있어서, 문서 하나가 그 안을 다 차지하면 질문과 지시, 다른 검색 결과가 밀려나고 비용도 그만큼 늘어납니다. 그래서 도구 하나가 내보내는 글자 수에 상한을 두는데, 그 상한은 정화와 경계 태그를 거쳐 실제로 에이전트에 넘어가는 결과 기준이어야 지켜집니다. 빈 응답 대신 오류 문구를 돌려주는 것도 같은 이유인데, 에이전트가 빈 응답을 “내용이 없다”로 읽어 버리면 그 다음 판단이 통째로 틀어지니까요.

정리하면 MCP는 연결까지만 책임집니다. 어떤 문서를 얼마나, 어떤 순서로, 어떤 검사를 거쳐 에이전트에 내보낼지는 프로토콜이 아니라 서버를 만드는 사람이 정해야 했습니다.

Knowledge Layer라고 그래프나 온톨로지부터 필요한 건 아닙니다

1) ‘그래프만 세팅하면 강력한 컨텍스트가 생긴다’는 근거는 생각보다 약합니다

GraphRAG-Bench 논문은 첫 번째 관찰로 “단순 사실 검색 과제에서는 기본 RAG가 GraphRAG와 비슷하거나 더 낫다.”를 답니다.

다른 체계적 평가 논문의 결론은 한 문장입니다. “RAG와 GraphRAG는 한쪽이 일관되게 이기기보다 서로 보완적인 양상을 보인다.”

같은 논문이 비용도 적어 뒀는데, 인덱싱 구축 시간이 커뮤니티 기반 GraphRAG 5,560초 대 일반 RAG 135초였습니다. 평가 방법을 뒤집어 본 연구는 기존 GraphRAG 평가에 “두 가지 치명적 결함, 즉 무관한 질문과 평가 편향”이 있고, 편향을 빼고 재면 이득이 훨씬 온건해진다고 합니다.

그렇다고 “그래프는 소용없다”는 뜻은 아닙니다. 지금까지 보고된 이득 가운데 상당수가 평가 방법 때문에 부풀려졌다는 비판이지, 조건이 맞으면 그래프가 이깁니다. 통신 규격 문서처럼 좁고 밀도 높은 도메인에서는 GraphRAG가 앞섰다는 결과도 있습니다. 가장 최근 논문은 에이전틱 검색이 “성능 격차를 좁힌다.”고 하면서도, “그럼에도 복잡한 다단계 추론에서는 GraphRAG가 여전히 유리하다.”고 덧붙입니다. 격차를 좁힌 것이지 없앤 게 아닙니다.

그래프를 도입하고 나서가 더 어렵다는 이야기도 많습니다. 온톨로지스트 Kurt Cagle과 Chloe Shannon은 “실패한 지식 그래프의 수가 성공한 것의 수를 훨씬 넘어선다.”라고 썼는데요.

이들이 든 실패 유형 중 눈에 띄는 게 “컨텍스트 창 쑤셔 넣기”입니다. 지식 그래프를 AI에 붙이라는 조언을 너무 곧이곧대로 받아들여, 그래프의 큰 덩어리를 통째로 LLM 컨텍스트 창에 밀어 넣고 토큰 비용만 키우는 경우를 말합니다. 두 사람은 그래프를 미리 다 퍼 주지 말고 AI가 필요한 정보만 그때그때 질의하게 하라고 권합니다.

2) 그래서 언제 넘어가야 할까요?

진부하지만 답은 “기술이 아니라 회사가 준비돼 있느냐” 입니다. 데이터 일을 10년 가까이 하고 지금은 미디어테크 회사에서 데이터 조직을 이끄는 Tomas Peluritis가 쓴 글에서, 기반 없이 semantic layer를 올리면 “그럴싸한 채팅 화면을 단, 아주 자신만만한 오답 기계”가 된다고 합니다. 여기서 말하는 기반은 합의된 지표 정의, 문서화된 규칙, 소유권, 테스트, 접근 정책입니다.

DDD(도메인 주도 설계)의 유비쿼터스 언어(Ubiquitous Language), 그러니까 한 팀이 같은 단어를 같은 뜻으로 쓰자는 약속을 먼저 세우는 게 이 기반의 첫 줄일 겁니다. 그게 없으면 온톨로지 도구를 들여와도 서로 다른 뜻을 정교하게 저장하는 일밖에 안 된다고 봅니다.

저자가 보는 진짜 위험은 환각이 아니라, 오해석이라고 합니다. 환각은 모델이 없는 사실을 지어내는 것이고, 오해석은 데이터는 진짜인데 질문을 잘못 알아듣고 답하는 것입니다. 앞의 활성 고객 예로 돌아가면, 있지도 않은 고객 수를 만들어 내면 환각이고, 무료 체험 계정까지 넣어 센 숫자를 “활성 고객 수”라고 정확히 계산해 주면 오해석입니다. 숫자 자체는 틀린 데가 없으니 받아 보는 사람은 잘못된 줄도 모르고, 검수를 해도 뭐가 틀렸는지 바로 알아보기 힘듭니다.

정리하면, 판단 기준은 이 정도인 것 같습니다. 코퍼스가 하나고 권한 구조가 단순하고 질의응답만 한다면, 잘 설계한 RAG로 충분합니다.

반대로 여러 소스를 붙여야 하고 같은 대상의 정합성, 관계, 권한, 출처, 최신성이 반복해서 문제가 된다면 그때부터는 검색기를 더 튜닝해서 안 풀립니다.

<출처: 작가>

마치며: RAG 다음이 Knowledge Layer라는 말은 RAG의 죽음이 아닙니다

RAG 원논문 공저자인 Douwe Kiela는 인터뷰에서 “MCP는 그저 프로토콜일 뿐이다. MCP를 써도 결국 하고 있는 건 RAG다.”라고 말했습니다.

RAG라는 이름을 만든 사람이 “이름만 바뀌었다”고 말하는 셈이라 무게가 있습니다. 다만 두 가지는 같이 봐야 합니다. Kiela도 RAG 제품을 파는 회사의 대표이고, 그가 비판한 대상은 MCP와 context engineering이지 knowledge layer가 아닙니다.

제가 보기엔 RAG가 죽은 게 아니라, 시스템 전체를 부르던 이름 자리에서 내려와 그 안에서 쓰는 기술 방법론 중 하나가 된 것에 가깝습니다. 검색은 사라지지 않고, 그 위에 의미, 권한, 출처, 시간을 다루는 층이 얹힌 형태요.

다시 처음 질문으로 돌아가 보겠습니다. 이 회사들이 서로 다른 이름으로 풀고 있는 문제는 하나였습니다. 검색이 찾아온 것을 조직의 지식으로 쓰려면, 같은 대상을 같은 것으로 세고(정합성), 지금 유효한 값을 고르고(최신성), 볼 수 있는 사람에게만 보여 주고(권한), 어디서 왔는지 밝혀야(출처) 한다는 것입니다. 관련 문서를 잘 찾아주는 문제와는 다른 문제입니다.

Microsoft는 이걸 knowledge layer로, AWS는 Semantic Layer 안의 한 층으로, Snowflake는 context layer로 부르지만, 검색 위에 이 네 가지를 얹는다는 점은 같습니다.

검색은 어떤 문서를 가져올지를 정하고, 지식 계층은 가져온 문서를 믿어도 되는지, 지금 값이 맞는지, 이 사람이 봐도 되는지, 어디서 온 것인지를 정합니다.

지금 당장 시작한다면, 온톨로지와 같은 기술적 방법론보다는 앞의 네 가지를 각각 한 줄로 적어 보는 게 어떨까요?

정의가 갈리는 지표가 무엇인지, 어떤 소스가 며칠 지연되는지, 권한 판정이 검색 앞인지 뒤인지, 답변에 출처가 붙는지요. 적어 보고 볼 것은 네 가지 중 몇 개가 문제냐가 아니라, 검색 결과가 맞아도 잘못된 판단이나 행동으로 이어지는 일이 반복되느냐입니다. 그게 반복된다면 그때가 검색을 더 튜닝하는 대신 지식 설계 쪽을 볼 시점인 것 같습니다.

<출처>

벤더 공식 문서

표준 규격 문서

벤더 블로그와 발표

기업 엔지니어링 블로그

논문

이 글은 AI의 도움을 받아 작성했습니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은
“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

]]>