요즘IT » 피드

로컬 LLM으로 민감정보를 걸러봤습니다

코드나 오류 로그를 ChatGPT, Claude 같은 클라우드 AI에 붙여 넣으면 문제를 빠르게 정리할 수 있습니다. 하지만 전송 버튼을 누르기 전에는 API 키, 내부 서버 주소, 사용자 이메일, 로컬 경로가 남아 있지 않은지 직접 확인해야 합니다.

형식이 일정한 값은 검색으로 찾기 쉽습니다. 반면 “프로젝트 오로라를 금요일 자정에 전환한다” 같은 문장에서는 ‘오로라’가 공개 제품인지 아직 발표하지 않은 내부 프로젝트인지 문맥을 봐야 합니다. 이 확인 작업을 줄이기 위해 정규표현식과 세 종류의 로컬 LLM을 결합한 작은 필터를 만들고, 실제로 어디까지 도움이 되는지 합성 데이터로 측정했습니다.

이 필터의 목표는 보안을 자동화하는 것이 아닙니다. 사용자가 마지막으로 확인해야 할 위치를 먼저 보여주는 보조 장치가 실제로 쓸 만한지 확인하는 실험입니다.

로컬 필터가 외부 전송 전 검토할 민감정보 후보를 표시하는 과정을 실험했다. <출처: 작가>

무엇을 민감정보로 봤나

이번 실험의 대상은 다섯 종류입니다.

API 키와 접근 토큰
이메일 주소
내부 서버 주소와 사설 IP
사용자명과 폴더 구조가 드러나는 로컬 경로
문맥을 봐야 알 수 있는 비공개 프로젝트명과 구체적인 출시·전환 일정

실제 회사 정보나 유효한 키는 사용하지 않았습니다. .invalid 이메일, RFC 1918 사설 IP, 인증에 사용할 수 없는 합성 키와 가짜 프로젝트명만 넣었습니다. 공개 제품명, 문서용 예약 IP, 버전 번호, 공용 시스템 경로처럼 가리면 안 되는 대조 입력도 포함했습니다.

규칙과 로컬 모델의 역할을 나눴다

첫 단계의 규칙 필터는 이메일, 사설 IP, 사용자 홈 경로, 키·토큰 형태를 자동으로 찾아 [EMAIL_1], [PRIVATE_IP_1] 같은 표식으로 바꿉니다. 같은 값에는 같은 표식을 사용해 문장 안의 관계를 보존했습니다.

두 번째 단계에서는 원문과 규칙 탐지 결과를 로컬 모델에 전달했습니다. 모델에는 문장을 다시 쓰거나 “안전하다”고 선언하는 권한을 주지 않고, 후보 문자열·분류·판단 이유만 JSON으로 반환하게 했습니다. 후보는 자동 마스킹하지 않고 검토 목록에 올렸습니다.

규칙은 형식이 뚜렷한 값을 가리고, 로컬 모델은 사람이 확인할 문맥 후보만 제시한다. <출처: 작가>

실험 환경은 Apple M5 Pro, 메모리 48GB, Ollama 0.32.7입니다. 비교한 모델은 gpt-oss:20b 20.9B MXFP4 13.8 GB, qwen3.6:27b 27.8B Q4_K_M 17.4 GB, gemma4:26b 25.8B Q4_K_M 18.0 GB입니다. Qwen은 기존 파일에서 실사용 프롬프트가 빈 응답을 냈지만, Ollama를 업그레이드하고 모델 무결성을 다시 확인한 뒤 정상화됐습니다.

50개 입력으로 조건을 비교했다

데이터는 총 50개입니다. 코드 15개, 오류 로그 20개, 업무 문서와 메모 15개로 구성했습니다. 민감정보가 있는 입력은 35개, 없는 대조 입력은 15개입니다. 정답 민감정보는 총 50개이며 다섯 유형을 각각 10개씩 넣었습니다.

전체 50개 입력은 모델별로 한 번 처리하고, 문맥 판단이 어려운 10개는 총 5회 반복했습니다. 규칙은 전체 데이터를 100회 처리해 문장당 중앙값을 구했습니다. 모델 시간은 완전히 내린 뒤의 최초 실행 3회와 예열 후 10회를 분리했습니다.

조건별 결과 요약

규칙만: 미탐 10, 오탐 0, 정밀도 100.0%, 재현율 80.0%
규칙 + GPT-OSS 20B: 미탐 6, 오탐 6, 정밀도 88.0%, 재현율 88.0%, 최초 16.95초, 예열 후 9.83초
규칙 + Qwen 3.6 27B: 미탐 5, 오탐 5, 정밀도 90.0%, 재현율 90.0%, 최초 10.54초, 예열 후 5.56초
규칙 + Gemma 4 26B: 미탐 4, 오탐 5, 정밀도 90.2%, 재현율 92.0%, 최초 2.90초, 예열 후 0.87초
대표 모델 + 사람 확인: 미탐 0, 오탐 0, 정밀도 100.0%, 재현율 100.0%

규칙 처리 시간의 문장당 중앙값은 0.003밀리초였습니다. 모델별 결과는 다음과 같습니다.

gpt-oss:20b: 미탐 6개, 오탐 6개, 재현율 88.0%, 예열 후 중앙값 9.83초, JSON 실패 5회
qwen3.6:27b: 미탐 5개, 오탐 5개, 재현율 90.0%, 예열 후 중앙값 5.56초, JSON 실패 0회
gemma4:26b: 미탐 4개, 오탐 5개, 재현율 92.0%, 예열 후 중앙값 0.87초, JSON 실패 19회

실험 기준에 따라 대표 모델은 gemma4:26b로 결정됐습니다. 우선순위는 재현율, 낮은 오탐, JSON 실패율, 예열 후 처리 시간이었습니다.

동일한 합성 문장에서 세 로컬 모델이 제시한 민감정보 후보를 비교했다. <출처: 작가>

대표 화면에 사용한 입력은 sohee@example.invalid에게 12월 3일 새벽 1시 출시 계획을 공유했습니다.입니다. GPT-OSS는 ‘sohee@example.invalid’, ‘12월 3일 새벽 1시’, Qwen은 ‘sohee@example.invalid’, ‘12월 3일 새벽 1시 출시 계획’, Gemma는 ‘sohee@example.invalid’, ‘12월 3일 새벽 1시 출시 계획’을 후보로 냈습니다. 설명이 자연스럽더라도 실제 후보가 빠질 수 있어 사람이 원문과 함께 확인해야 했습니다.

조건별 미탐·오탐과 처리 시간. 최초 실행에는 모델 적재 시간이 포함됐다. <출처: 작가>

규칙은 빠르지만 문맥 앞에서 멈췄다

규칙만 사용한 조건은 미탐 10개, 오탐 0개였습니다. 형식이 일정한 이메일·RFC 1918 사설 IP·키·사용자 경로 40개는 모두 찾았지만, 프로젝트명과 일정 10개는 설계상 그대로 남았습니다. 문서용 예약 IP와 일반 시스템 경로는 가리지 않았습니다.

규칙을 계속 늘리면 특정 사례는 잡을 수 있지만, 프로젝트명과 일정이 바뀔 때마다 금칙어 목록을 관리해야 합니다. 예상하지 못한 문맥 표현을 찾는 역할은 모델 후보가 보완했습니다.

로컬 모델은 후보를 보완했지만 서로 다르게 틀렸다

세 모델은 같은 프롬프트와 합성 입력을 받았지만 결과가 같지 않았습니다. GPT-OSS는 안정적인 JSON을 위해 thinking 모드가 필요했고, 예비 검사에서는 이메일과 IP만 잡고 프로젝트명과 일정을 놓쳤습니다. Qwen과 Gemma도 문맥 후보를 더 찾는 대신 대조 문장을 내부 정보로 과하게 판단하는 경우가 있었습니다.

반복 실행의 후보 집합 일치율은 GPT-OSS 91.1%, Qwen 100.0%, Gemma 100.0%였습니다. 결과가 매번 같더라도 정확하다는 뜻은 아니며, 반대로 후보가 흔들리면 자동 승인에 쓰기 더 어렵습니다.

이 작은 표본에서는 마스킹 방식보다 응답 변동이 컸다

대표 오류 로그 5개를 원문, 후보를 모두 승인한 과도한 마스킹, 식별값만 가리고 관계를 보존한 마스킹으로 나눠 동일한 클라우드 모델에 보냈습니다. 오류 원인, 실행 가능한 해결책, 잘못된 가정, 추가 원문 없이 이해 가능한지를 각 0~2점으로 평가했습니다.

원문 평균: 8.0/8점
과도한 마스킹 평균: 8.0/8점
관계 보존 마스킹 평균: 7.2/8점

식별값을 제거하면서 로그의 관계를 보존했을 때 답변 활용도가 얼마나 유지되는지 비교했다. <출처: 작가>

후보 전부 승인 조건은 이메일이 아닌 user@example까지 가렸지만 5개 평균은 원문과 같은 8.0점이었습니다. 오히려 Q1에서는 후보 전부 승인과 관계 보존 입력이 같았는데도 독립 응답 점수가 8점과 4점으로 갈렸습니다. 5개뿐인 이번 결과로 관계 보존 마스킹이 항상 더 좋은 답변을 만든다고 결론낼 수는 없습니다. 다만 식별값 대신 일관된 표식을 사용하면 문장 안의 관계를 유지하면서 전송 범위를 줄일 수 있다는 설계상의 장점은 남았습니다.

로컬 실행도 따로 확인했다

Ollama API는 127.0.0.1:11434에 바인딩돼 있었습니다. 대표 추론 전·중·후 프로세스 연결을 211초 동안 360회 관찰했습니다. 네트워크 결과 문구는 “관찰 구간에서 Ollama 외부 연결을 확인하지 못했다.”로 제한했습니다. 로그와 데이터 경로의 canary 검사도 “확인한 경로에서는 평문 canary를 찾지 못했다.”라고만 기록했습니다.

모델 실행 위치와 관찰 가능한 네트워크·로그 흔적을 별도로 확인했다. <출처: 작가>

이 결과는 시스템 전체에서 외부 전송이 절대 없었다는 증명이 아닙니다. 확인한 프로세스와 시간, 경로 안에서 관찰된 사실입니다. 로컬 실행 여부, 외부 연결, 프롬프트 저장 여부는 서로 다른 주장으로 분리해야 합니다.

마치며: 보안 도구가 아니라 전송 전 체크리스트에 가까웠다

실제 사용 흐름은 다음과 같이 정리됐습니다. 먼저 비밀정보가 코드와 로그에 남지 않도록 환경 변수와 비밀정보 관리 도구를 사용합니다. AI에는 필요한 부분만 복사합니다. 규칙 필터가 형식이 분명한 값을 마스킹하고, 로컬 모델은 문맥 후보를 보여줍니다. 마지막으로 사람이 원문과 결과를 나란히 확인한 뒤 전송합니다. 필터가 아무것도 찾지 못해도 검토를 생략하지 않습니다.

이번 결과는 직접 만든 50개 합성 데이터에 대한 소규모 실험입니다. 일반적인 보안 성능을 증명하지 않으며, 민감도가 높은 자료에는 애초에 클라우드 AI를 사용하지 않는 판단이 우선입니다. 로컬 LLM의 역할은 “이 문서는 안전하다”고 허가하는 것이 아니라, 전송 전에 한 번 더 의심할 위치를 보여주는 데 있었습니다.

<참고>

]]>

회고 잘하고 싶어서 만든 인터랙티브 회고 도구

질문하는 AI: Twine으로 만든 인터랙티브 회고

나는 ‘메모어’라는 모임에서 주말마다 회고를 한다. 지난 한 주의 행동과 생각을 돌아보고, 다음 주에는 무엇을 다르게 해볼지 고민하는 시간이다. 회고를 처음 시작했을 때만 해도 이 과정은 무척 새롭고 흥미로웠다. 그러나 모든 일이 그렇듯, 시간이 흐르자 매너리즘이 찾아왔다. “참 재미있었다”라는 한마디로 끝나는 여름방학 일기처럼 나의 회고도 점점 짧고 무성의해졌다.

10주간의 메모어 활동을 마치고 다음 기수가 시작되기 전까지 잠시 쉬는 동안, 그동안 쓴 회고를 다시 읽어보았다. 처음에 쓴 글과 비교하니 생동감이 확연히 줄어 있었다. 같은 방식으로 회고를 반복하는 것만으로는 이 권태를 벗어나기 어려워 보였다. 새로운 동력이 필요했다.

그래서 회고를 도와주는 도구를 직접 만들어보기로 했다. 내가 생각한 도구는 글을 대신 써주는 작가보다, 미처 들여다보지 못한 부분을 끈질기게 묻는 인터뷰어에 가까웠다. 먼저 AI가 회고 초안을 읽고 내용이 부족하거나 모호한 지점을 찾아 질문한다. 나는 그 질문에 답하면서 당시의 상황과 감정을 조금 더 구체적으로 돌아본다. 충분한 답변이 모이면 AI가 초안과 인터뷰 내용을 바탕으로 하나의 회고를 완성한다.

여기에 약간의 재미를 더하기 위해 인터랙티브 소설 형식을 빌렸다. 인터랙티브 소설은 독자의 선택이나 입력에 따라 이야기의 흐름이 달라지는 소설이다. 나는 이야기의 콘셉트를 ‘평행우주’로 정했다.

양자역학의 다세계 해석은 가능한 결과들이 서로 다른 세계에서 실현된다는 발상을 담고 있다. 여기서 아이디어를 빌려, 회고에 등장하는 후회와 선택의 순간마다 또 다른 우주가 갈라진다고 상상해보았다. “그때 다른 말을 했다면?”, “그 일을 맡지 않았더라면?” 같은 질문이 하나의 분기점이 되는 것이다. 사용자가 회고를 작성하면 AI는 그 안에서 선택의 순간을 찾아낸다. 그리고 선택하지 않았던 길이 각각의 평행우주에서 어떻게 이어졌을지 이야기로 만든다. 사용자는 그렇게 만들어진 우주를 하나씩 여행하며 자신의 선택을 여러 방향에서 되짚어본다.

이 앱을 만들며 나는 AI에게 답을 잘 쓰게 하는 것만큼, 필요한 맥락을 먼저 질문하게 하는 일이 중요하다는 것을 알게 됐다.

또한, 이번 앱을 만드는 과정에서 ‘Twine’이라는 오픈 소스 도구를 새롭게 알게 되었다. Twine은 선택에 따라 흐름이 달라지는 인터랙티브 이야기를 시각적으로 만들 수 있는 도구다. 이번 글에서는 Twine을 활용해 평행우주를 여행하는 회고 앱을 만든 과정과, 그 안에서 AI에게서 답이 아닌 질문을 얻기 위해 노력한 경험을 소개하려 한다.

인터랙티브 시나리오를 만드는 도구, Twine

Twine은 비선형적인 이야기를 만드는 도구다. 각 장면을 선으로 연결해 사용자와 상호작용하며 전개되는 시나리오를 만들 수 있다. 편집은 그래프를 그리는 방식으로 이루어진다. 각각의 장면은 하나의 노드가 되고, 그 장면에서 여러 갈래로 뻗어나오는 장면을 새로운 노드로 추가하면 된다. Play 버튼을 누르면 첫 장면이 재생되고, 사용자는 버튼으로 제공되는 선택지를 클릭하면서 장면을 탐색할 수 있다.

나는 바로 이러한 비선형성이, 회고라는 활동과 잘 어울린다고 생각했다. 선택의 순간을 하나의 장면으로 만들고, 선택의 결과들을 여러 갈래로 탐색해보는 것이 재미있을 것 같았다.

<출처: Twine>

Claude 스킬

하지만 막상 사용해보니 바로 난관에 봉착했다. 우선 Twee라는 형식이 낯설었다. Twee는 Twine 이야기를 장면 단위로 표현하는 평문 형식이다. 장면의 제목과 본문, 장면 사이의 연결 관계를 일정한 규칙에 따라 적는다. 여기에 Harlowe 같은 스토리 포맷의 변수와 매크로까지 사용하려면 별도의 문법도 익혀야 했다. 내게는 새로운 프로그래밍 언어를 하나 더 배우는 것처럼 느껴졌다. 익숙해지면 편리하겠지만, 반드시 배워야 하는지 의문이 들었다. 이 부분을 AI가 도와줄 수 있을 것 같았다. 변환은 AI에게 맡기고, 나는 시나리오 생성에만 집중하기로 했다.

그리고 노드를 직접 만드는 일도 생각보다 번거로웠다. 그래프 위에 노드의 위치를 정하고, 다른 노드와 연결하는 작업을 반복해야 했다. 그래프를 보기 좋게 정리하는 일까지 생각하면 글을 쓰는 시간보다 구조를 만드는 시간이 더 길어질 수도 있었다. 나는 이것 역시 인터랙티브 시나리오 작가의 몫이 아니라고 생각했다. 그래서 장면과 연결 관계를 사람이 하나씩 만들지 않도록, AI가 전체 이야기를 Twee 형식으로 생성하게 했다. 이 파일을 Twine으로 불러오면 각 장면이 노드로 만들어지고, 이야기의 흐름도 그래프에서 확인할 수 있었다.

처음 만든 것은 Claude 스킬이었다. 자연어로 작성한 회고 초안을 스킬에 전달하면 AI가 내용을 읽고, 장면과 연결 관계를 담은 Twee 파일로 바꿔준다. 이 과정에서 내가 직접 Twee 문법을 작성하거나 노드를 하나씩 연결할 필요는 없었다.

사용자가 자연어로 회고 초안을 작성한다.
AI가 초안을 Twee 텍스트로 변환한다.
사용자가 이 Twee 텍스트를 Twine 로컬 스토리지에 붙여넣으면 바로 플레이할 수 있다.

Claude 스킬 대신 웹앱으로 만들기

1) 저장 공간

앞서 로컬 스토리지를 언급했다. Twine을 브라우저에서 사용하면 이야기가 브라우저의 로컬 스토리지에 저장된다. 아이패드와 맥북을 오가며 작업하는 데 익숙한 나는 계정에 연결된 데이터베이스가 아니라, 기기마다 별도로 저장되는 방식이 불편했다. 또한 앞서 만든 Claude 스킬이 생성한 Twee 텍스트를 복사해 붙여넣기에는 로컬 스토리지의 입력 화면이 너무 작아 내용을 한눈에 확인하기 어려웠다. 애초에 로컬 스토리지는 사용자가 직접 데이터를 편집하기 위해 만들어진 공간이 아니었다.

<출처: Twine 웹사이트>

저장 공간이 필요했다. 나는 우선 클라우드 저장소 연동이 가능한지 확인하기 위해 깃허브의 twinejs 레포지토리를 찾아보았다. 나 말고도 클라우드 저장소를 원한 유저가 이슈를 올린 적이 있었지만, 운영상의 부담과 복잡도를 이유로 보류된 것으로 보였다. 납득이 가는 설명이었다. 나였어도 같은 부담을 느꼈을 것 같아서 공감이 되었다. 하지만 어쨌든, 당장 나의 회고 앱에는 클라우드 저장소가 필요했다. 명색이 AI 앱인데, 사용 과정에 ‘로컬 스토리지에 텍스트 붙여넣기’라는 수동적인 절차가 포함되어 있는 것은 너무 원시적이었다.

하지만 클라우드 저장 기능을 붙이려니 또 다른 고민이 생겼다. 지금은 나 혼자 쓰는 앱이지만, 사용자가 늘어나면 그들의 회고가 내가 관리하는 저장소에 쌓이게 된다. 회고에는 업무에서의 실수나 인간관계, 당시의 감정처럼 민감한 이야기가 담길 수 있다. 그런 기록을 맡는 순간부터 나는 저장 공간의 비용뿐만 아니라 보안까지 책임져야 한다. 운영자인 나조차 필요 이상으로 내용을 들여다볼 수 없게 하고, 외부 공격이나 실수로 데이터가 유출되지 않도록 지켜야 한다. 누군가의 기록을 보관한다는 것은 작은 사이드 프로젝트가 가볍게 감당할 수 있는 일이 아니었다.

그래서 Notion을 저장소로 사용하기로 했다. Notion은 무료 플랜으로도 꽤 많은 용량을 저장할 수 있다는 점, OAuth 연동이 쉽다는 점, 편집 툴로서 편리하다는 점이 이유였다. 사용자는 OAuth 화면에서 앱이 접근할 페이지를 직접 선택해주기만 하면 되었다. Twine에 동기화해주는 기능만 추가해주면, Notion에서 직접 편집할 수 있어서 사용성이 높아질 것 같다는 생각이 들었다.

2) 동기화

Notion의 강력한 텍스트 편집 기능을 십분 활용하기 위해 Twine의 로컬 스토리지와 Notion 페이지 간의 동기화 기능을 추가했다. 웹에서 글을 수정하면 먼저 브라우저의 로컬 스토리지에 저장하고, 수정이 멈춘 뒤 3초가 지나면 Twee 형태의 스냅샷을 Notion으로 보낸다. 반대로 앱을 열 때는 Notion에 저장된 이야기를 불러와 로컬 사본과 비교한다. 두 내용이 다르면 수정 시각이 더 최근인 쪽을 선택한다. 이 앱은 협업 도구를 의도한 것이 아니어서 동시 수정 충돌은 별도로 처리하지 않았다. 따라서 두 기기에서 동시에 글을 수정하면 나중에 저장된 사본이 이전 내용을 덮을 수 있다.

결론적으로, 이 회고 웹앱의 최종적인 사용 흐름은 다음과 같다.

회고 생성 버튼을 클릭한다.
Notion 계정을 연결한다.
회고를 저장할 Notion 페이지를 고른다.
사용할 AI 모델의 API 키를 입력한다.
회고 제목과 초안을 작성한다.
AI가 던지는 질문에 답한다.
내용이 충분해지면 인터랙티브 회고가 생성된다.
Play 버튼을 눌러 평행우주를 여행한다.

3) AI 호출 비용, 누가 낼까?

이 앱을 만들 때 가장 큰 고민은, AI 토큰 비용을 누가 지불하는가 하는 것이었다. 이 고민을 하면서, 왜 많은 앱들이 서버 비용을 벌기 위해 광고를 붙이는지 이해가 되었다.

인터랙티브 회고를 한 번 만들 때마다 AI 호출 비용이 발생한다. AI는 회고 글을 읽고, 그 내용을 바탕으로 질문한 뒤 최종 스토리까지 생성한다. 이 과정마다 토큰이 사용되는데, 사용자가 많아진다면 비용이 어디까지 늘어날지 생각하니 아찔했다. 설령 이 앱이 많은 사용자에게 공개되더라도 오픈 소스 프로젝트 기반이라 수익을 내는 앱이 아니기에, 모든 사용자의 회고 생성 비용을 직접 부담하는 것은 무리라는 판단이 들었다.

그래서 사용자가 자신의 API 키를 입력하고 모델을 고르는 BYOK(Bring Your Own Key) 방식을 사용했다. 그리고 선택한 제공업체에 따라 지원되는 AI 모델들을 나열해서 사용자가 선택할 수 있도록 했다.

<출처: 작가>

4) API 키 관리 문제

BYOK 방식으로 비용 문제를 해결했지만, 보안 문제가 남아있었다. AI를 호출하려면 앱이 사용자의 API 키를 전달받아야 하기 때문이다.

처음에는 평문 키를 Notion 페이지에 적어두고 서버에서 읽는 방식도 생각했다. 하지만 Notion 페이지는 오래 남고 공유나 검색의 대상이 될 수 있다. 비밀값을 보관할 장소로는 적절하지 않다고 판단해 이 방식은 바로 폐기했다.

최종적으로는 사용자가 입력한 AI API 키와 Notion 접근 토큰을 하나의 세션 정보로 묶었다. 세션 전체를 AES-256-GCM 방식으로 암호화한 뒤, 브라우저의 자바스크립트에서 읽을 수 없는 HttpOnly 쿠키에 저장했다. 세션은 30일 동안 유지되며, 세션 정보가 다시 저장될 때마다 만료 시각도 갱신된다. 서버는 AI나 Notion API를 호출할 때만 쿠키를 복호화한다.

그렇다고 암호화 쿠키가 모든 문제를 해결해주는 것은 아니다. AI 호출 시점에는 서버가 복호화된 키를 다루게 된다. 서버가 복호화할 수 있다는 사실은 서버가 침해되었을 때 키가 노출될 가능성도 있다는 뜻이다. 따라서 이 앱에서만 사용할 별도의 API 키를 발급하고, 가능한 경우 사용 한도를 낮게 설정하며, 사용을 마친 뒤에는 제공업체 콘솔에서 키를 폐기하는 편이 안전하다.

5) 좋은 회고를 위한 좋은 질문

기능만 놓고 보면 앱은 처음 상상했던 모습에 꽤 가까워졌다. 회고를 작성하면 AI가 질문하고, 답변을 반영한 Twee를 만들고, Notion에 저장한 뒤 바로 플레이할 수 있다. 클라우드 저장과 모델 선택, 비용과 보안 문제도 나름의 방식으로 해결했다.

이제는 정말 이야기를 생산하는 데에만 집중할 시간이었다. 새삼 AI에게 고마웠다. 하마터면 도구의 사용법을 익히느라 시작도 하기 전에 지칠 뻔했으니 말이다.

그런데 결과물의 문장이 어딘가 마음에 들지 않았다. 여전히 추상적인 경우가 많았고, 심지어 내가 하지 않은 일을 지어내는 경우도 있었다. AI가 빈칸을 상상으로 채운 이야기는 재미있었지만, 그것은 더 이상 나의 회고가 아니었다.

그래서 나는 프롬프트에 중요한 규칙을 추가했다. 회고 초안에 선택이나 갈림길이 잘 드러나지 않고 맥락·감정·결과가 비어 있다면 곧바로 변환하지 말고, 질문을 통해 살을 붙이도록 했다. 예시 질문도 몇 개 제시하고, 충분하다고 판단할 때까지 반복해서 질문하게 했다.

<출처: 작가>

그때의 핵심 결정이나 전환점은 무엇이었나?
그때 함께 고민했지만 고르지 않은 선택지는 무엇이었나?
그 길을 갔다면 어떻게 됐을 것 같나?
지금 다시 그 좌표에 선다면 무엇을 다르게 할까?
그 순간의 감정과 상황은 어땠나?
실제 결과와 이후의 변화는 어땠나?

그리고 마지막으로는, 선택지들을 띄워주면서 사용자에게 가장 마음에 드는 선택지를 다시 한번 고르게 하고 그 우주의 나에게 메시지를 보낼 수 있게 했다. 마치 우주에서 신호를 보내는 것처럼 보이도록, 메시지가 깜빡거리는 효과를 주었다.

<출처: 작가>

답을 만드는 AI가 아니라, 질문하는 AI

이번 앱을 만들기 전까지 나는 AI를 주로 답을 얻기 위한 도구로 사용했다. 모르는 것을 물어보고, 필요한 코드를 요청하고, 작성한 문장을 다듬었다. 내가 질문하면 AI가 답하는 방식에 익숙했다.

그런데 이번 프로젝트에서는 반대로 AI에 질문하는 역할을 맡겼다. 사용자가 작성한 회고를 읽고, 이야기로 만들기에 부족한 부분을 찾아 다시 묻게 했다. 당시 어떤 감정을 느꼈는지, 다른 선택지는 없었는지, 그 선택이 이후에 어떤 영향을 주었는지 질문하도록 했다.

앱으로 나의 회고를 만들던 중, AI가 이렇게 물었다.

“아무리 별로였던 순간조차도, 그 안에서 얻은 것이 있지 않아?”

그동안 나는 회고를 하면서 잘못한 점을 찾고 자책하는 데 익숙해져 있었다. 무엇을 잘못했는지, 다음에는 어떻게 고쳐야 할지만 고민했다. 그런데 이 질문을 받고 나니 실패라고 생각했던 선택에서도 나름의 이유와 괜찮았던 점이 보이기 시작했다.

업무상 저지른 실수를 되짚어보면서는 개인의 부주의만이 아니라, 같은 실수를 반복하게 만드는 구조에도 문제가 있다는 것을 발견했다. 덕분에 업무 구조를 개선해야 할 필요성을 느꼈다. 틀어진 인간관계를 돌아보면서는 내가 어떤 사람과 관계를 편안하게 느끼는지, 반대로 어떤 상황에서 힘들어하는지를 조금 더 분명하게 알게 되었다.

후회했던 선택을 실제로 바꿀 수는 없다. 하지만 이야기 속 평행우주를 여행하며 선택하지 않은 가능성을 살펴볼 수는 있다. 그리고 여행을 마치고 현실로 돌아왔을 때, 다음 갈림길에서는 이전과 조금 다른 선택을 할지도 모른다.

사람은 자신이 한창 몰두하고 있는 일의 빈틈을 발견하기 어렵다. 대화 상대에게 내 생각이 이미 충분히 전달됐다고 여기거나, 글에 필요한 내용이 모두 담겼다고 착각하기도 한다. 이때 한 걸음 떨어진 곳에서 질문을 던지는 조수가 있다면 미처 보지 못한 빈칸을 발견할 수 있다. AI는 내가 머릿속으로만 알고 있는 맥락까지 알 수 없다. 모르는 내용을 그럴듯하게 채우게 하기보다 필요한 맥락을 파악할 때까지 질문하도록 만들면, AI는 내가 놓친 빈틈을 발견하도록 돕는 조수가 된다.

적어도 회고에서는 답이 내 안에 있는 경우가 많았다. AI가 해야 할 일은 그럴듯한 결론을 대신 내려주는 것이 아니라, 내가 아직 꺼내지 못한 생각을 발견하도록 돕는 일이었다. 문장을 얼마나 멋지게 썼는지보다 어떤 질의응답을 주고받았는지에 따라 결과물의 품질이 달라졌다.

이 회고 앱은 혼자 사용할 목적으로 만들었지만, 만들다 보니 애정이 생겨 주변 사람들의 피드백도 듣고 싶어졌다. 언젠가 나와 함께 회고하는 사람들이 이 도구를 통해 자신의 평행우주를 여행하는 모습을 보고 싶다. 그러기 위해 지금 필요한 것은 더 좋은 질문을 통해 사용자의 생각을 자연스럽고 깊게 끌어내는 회고 앱을 만드는 일일 것이다.

이 글은 AI를 활용해 작성했습니다. 작가가 주제와 구성, 실제 개발 경험과 코드를 제공했으며, AI는 공식 문서를 바탕으로 한 자료 조사와 초안 작성을 도왔습니다. 이후 작가가 원고 전체 문장을 직접 고쳐 썼고, AI는 맞춤법과 문장 표현, 사실관계를 점검했습니다. 최종 검수와 퇴고는 작가가 직접 진행했습니다.

<참고>

]]>

지금 당장 서비스에 쓸만한 API ① 지도·교통·날씨·주식·부동산 편

얼마 전, 그늘 많은 길을 골라 안내하는 ‘그늘로’ 앱이 유행했습니다. 정말 재미있는 컨셉에 아이디어가 무척 뛰어났죠. 개인이나 소규모 팀이 가야 할 ‘어떻게 보여줄 것인가’를 정말 이상적으로 구현한 제품이라 생각합니다.

언뜻 보면, 지도 위에 경로만 표시해주는 앱 같지만, 다시 보면 그리 만만하지만은 않습니다. 그늘진 길을 고르려면 어디에 어떤 건물이 얼마나 높게 서 있는지, 가로수가 어디에 심겨 어느 만큼 그늘을 드리우는지를 알아야 하니까요. 개인이 전국을 돌며 건물 높이와 가로수 위치를 잴 수는 없습니다. 코드는 AI가 대신 짜준다 해도, 이 ‘데이터’는 만들 수가 없습니다.그래서 앱 제작자는 여기에 공공데이터를 활용했다고 합니다.

사실 우리가 앱이라고 부르는 건 대개 하는 일이 데이터를 가공해 보여주는 게 전부입니다. 지하철 앱은 도착 시각을 받아 보여주고, 가계부 앱은 내가 적은 금액을 받아 계산해 보여줍니다. 화면은 그걸 보기 편하게 정리한 껍데기고, 버튼은 이 데이터를 저기서 가져오라는 심부름을 맡습니다.

그러니 서비스를 만든다는 건 사실 어디서, 무슨 데이터를 받아, 어떻게 보여줄지 정하는 일에 가깝습니다. 아무것도 모를 때는 이 데이터를 직접 만드는 게 좋다고 생각하기 쉽습니다. 웹페이지를 긁어오거나, 숫자를 손으로 옮겨 적거나 하면서요. 문제는 데이터가 매번 갱신된다는 겁니다. 그 데이터를 가지고 있는 쪽은 따로 있으니까요. 버스 도착 시간은 국토부, 환율은 은행에 있고요.

다행스럽게도 이들은 데이터를 보내는 창구, API를 열어 두고 있습니다. 그러니 받아 쓰는 편이 거의 항상 낫습니다. 다만, 이게 막 큰돈이 되는 건 아니니 그 API가 어디 있는지 원래 하던 사람들이나 아는 경우가 많습니다. 그래서 제가 모아봤습니다. “어떻게 보여줄지”만 신경 써도 그럴듯한 앱이 나오는 믿을 만한 API들. 무엇이든 서비스를 만들기 시작할 때 쓸만한 재료 창고입니다.

오픈API의 보고, 공공데이터포털 <출처: 공공데이터포털, 작가 캡처>

뭘 만들 수 있을까?

지도·날씨·교통처럼 서비스가 다루는 정보의 주제 단위를 도메인이라고 부릅니다. API는 대개 이 주제 단위로 제공되기 때문에 ‘뭘 만들까’라는 고민은 결국 ‘어느 도메인의 데이터를 물릴까’에서 시작하는 게 빠릅니다.

이번 편의 도메인은 지도·위치, 교통·모빌리티, 날씨, 금융·경제, 부동산입니다. 전부 매일 보기도 하고, 갱신도 빠른 편이라 얼마나 신선한 데이터를 얼마나 자주, 많이 받아올 수 있는지가 중요합니다. 전문 용어로 하면 실시간성, 갱신 주기, 호출 한도죠.

그런 기준을 바탕으로 도메인마다 만들 수 있는 것, 대표 API, 판정, 부업으로 키울 때 볼 것 순서로 정리했습니다.

1. 지도와 위치

동네 카페 지도, 반려견 산책 코스 기록, 모임 장소 중간 지점 찾기. 위치가 들어가는 아이디어는 전부 이 도메인에서 출발합니다. 장소 검색과 경로 탐색까지 붙이면 앱 하나 뚝딱입니다. 이를테면 한동안 유명했던 거지맵도, 위치 데이터에 다른 데이터(음식 가격)를 얹어 “어떻게 보여줄지”에 집중한 것에 가깝습니다. 앞서 본 그늘로도 같은 구조죠.

카카오맵: 심사 없이 바로 쓰는 지도

카카오맵 API는 지도 SDK와 장소 검색에 대중교통, 도보, 자전거 경로, 정적 지도까지 한 계정으로 다 얻어올 수 있습니다. 2026년 7월 21일 개편으로 신청과 심사 절차가 통째로 사라진 게 가장 큰 변화예요.

발급하기: 개발자 계정 + [사용 설정]만 켜면 끝
무료 한도: 첫 활성화 앱은 지도·로컬 기존 제공량 유지 + 신규 4종(경로 3종·정적 지도) 각 일 1,000건
갱신 주기: 경로, 검색 실시간
주의점: 2번째로 활성화하는 앱부터 유료(신규 4종은 경로 건당 10원·정적 지도 건당 2원, 지도·로컬 API도 기존 유료 정책 기준으로 과금 대상). 2026년 7월 21일 이전부터 쓰던 앱의 기존 무료 쿼터는 별도 안내 전까지 유지

카카오맵 API 문서 첫 화면 <출처: 카카오디벨로퍼스>

비슷한 서비스로 네이버 지도 API가 있습니다. 예전에 쓰던 ‘AI NAVER API’ 쪽 지도 상품 7종은 2025년 5월 22일부터 신규 신청이 막혔고 무료 이용량도 그해 6월 30일로 끝났습니다. 7월부터는 쓴 만큼 전부 과금이고요.

다만 새로 나온 단독 상품 ‘Maps’로 가면 무료로도 쓸 수 있습니다. 무료 이용량은 API별로 월 3,000건에서 600만 건까지인데, 전화번호나 사업자번호로 묶인 계정 가운데 대표 계정 하나에만 한도가 붙습니다. 앱을 여러 개 만들어도 총량은 계정 단위로 하나라는 뜻이죠. 한편, 주소 검색·좌표 변환만 필요하면 도로명주소 API를 무료로 쓸 수 있습니다.

그래도 지도 관련 취미나 사이드 프로젝트를 시작한다면 카카오 쪽을 권합니다. 심사가 없어져 계정만 있으면 그날 바로 붙일 수 있거든요. 부업을 염두에 두고 있을 때도 카카오가 편합니다. 유료 단가가 건 단위로 공개돼 있어 원가 계산이 쉽고, 트래픽이 늘면 비즈월렛 연결로 확장하기도 괜찮아 보입니다.

2. 교통과 모빌리티

‘지하철 몇 분 뒤 도착’ 같은 알림을 띄우는 순간, 앱의 체급이 달라집니다. 출근길 버스/지하철 위젯, 따릉이 대여소 잔여 알림 같은 것들이요. 다섯 도메인 중 실시간성 요구가 가장 센 곳인데요, 또 그만큼 국가에서 제공해 주는 데이터라 쓰기에는 편합니다.

서울 열린데이터광장: 서울 안에서는 밀도 최고

서울 열린데이터광장은 따릉이 대여소별 잔여 대수, 지하철 실시간 도착, 버스 도착까지 서울의 ‘지금 교통 데이터’를 가장 촘촘하게 주는 서비스입니다. API로 바로 연결할 수 있고요.

발급하기: 인증키 발급만(지하철 실시간은 전용 인증키를 따로 신청)
무료 한도: 회당 최대 1,000건, 지하철 실시간은 일 1,000건(활용사례 등록 심사 후 해제 가능)
갱신 주기: 실시간

서울 열린데이터광장 메인 <출처: 서울 열린데이터광장, 작가 캡처>

국토부 TAGO: 전국 단위 교통 데이터가 필요할 때

TAGO는 버스 도착·정류소·노선에 지하철·열차·항공·선박까지 13종의 교통 데이터를 하나로 모아 줍니다. 역시 오픈API로 열려 있고요.

다만, 범위가 넓은 만큼 한계도 있습니다. 버스 도착은 ‘도시코드 목록 조회’에 잡히는 도시만 되고, 지하철은 실시간 도착이 아니라 시간표로 알려 줍니다.

발급하기: 공공데이터포털 활용신청
무료 한도: 개발계정 일 10,000회
갱신 주기: 도착 정보는 실시간, 노선·시간표는 준정적

공공데이터포털의 국토교통부 TAGO 버스도착정보 <출처: 공공데이터포털>

결국, 서울 한정 서비스면 열린데이터광장, 전국이면 TAGO를 추천합니다.

둘 다 공공데이터라 요금이 나올 일은 없습니다. 다만 과금 리스크가 없다는 것과 마음대로 써도 된다는 건 다른 얘기입니다. 이용허락범위가 데이터셋마다 달라서, 돈을 받을 생각이라면 쓰려는 데이터마다 하나씩 확인해야 합니다. 요금보다 오히려 사용 조건이나 활용사례 등록을 통한 한도 증량 쪽이 까다로울 수 있습니다.

3. 날씨

‘내일 우산 챙기세요’ 알림, 캠핑 날짜 추천, 동네 미세먼지 위젯. 날씨는 어떤 서비스에든 곁들일 수 있는 도메인입니다. 메인 데이터로 쓰기에도 좋고요.

기상청 단기예보: 예제가 가장 많은 데이터

기상청 단기예보 조회서비스는 초단기실황부터 글피·그글피 예보까지, 5km 격자로 읍·면·동 날씨 데이터를 줍니다. 2026년 8월 기준 활용신청이 6만 5,000건을 넘어, 공공데이터포털에서도 손꼽히게 인기 있는 오픈API입니다. 그만큼 예제와 커뮤니티 글이 많아, 참고하기에도 좋습니다.

발급하기: 공공데이터포털 활용신청
무료 한도: 개발계정 일 10,000회
갱신 주기: 초단기실황 매시각, 단기예보는 02시부터 3시간 간격으로 하루 8회 발표

기상청 단기예보 조회서비스 <출처: 공공데이터포털>

원천 데이터를 더 쓰고 싶으면 기상청 API허브가 있습니다. 가입하고 키만 받으면 무료인데, 지상관측(AWS, 자동기상관측장비), 예특보, 레이더, 위성 데이터 등 포털보다 원천이 풍부하거든요. 한편, 미세먼지는 에어코리아 대기오염정보가 측정소별 측정치를 시간 단위로 줍니다(활용신청, 개발계정 하루 500회).

정리하면, 시작은 단기예보, 원천은 API허브, 미세먼지는 에어코리아 조합을 고려할 수 있습니다.

부업으로 확장하기도 유리합니다. 단기예보는 공공누리 제1유형(출처표시만 하면 되는 데이터)이라, 출처만 밝히면 상업적 활용까지 문제없습니다. 글로벌 날씨를 보려면 오픈웨더(OpenWeather)로 갈아탈 수도 있는데, 무료 티어도 상업 이용은 되지만 출처 표기와 오픈 라이선스(ODbL) 조건이 붙습니다. 약관은 한 번 읽어 보는 게 좋아요.

4. 금융과 경제

주식 관심 종목 모아보기, 환율 알림, 기준금리 그래프 대시보드. 돈이 걸린 도메인이라 만들고 싶어 하는 사람이 많은 쪽이 아닐까 싶습니다. 그래서인지 발급이나 한도에 제한은 있는 편입니다.

토스증권 오픈API: 심사 없이 받아 쓰기

토스증권 오픈API는 2026년 8월 13일 정식 서비스를 시작했습니다. 5월부터 사전 신청으로 열려 있던 걸 전체 고객에게 푼 거죠. 시세, 계좌·보유주식, 주문에 조건주문(OCO·OTO)까지 REST로 열고, 실시간 체결·호가·주문 이벤트는 웹소켓으로 밀어 줍니다. 국내(KRX·NXT 통합)와 미국 주식을 한 API로 다룹니다.

발급 관문: 토스증권 계좌 + WTS 설정 > Open API에서 client_id·client_secret 즉시 발급(심사 없음)
무료 한도: 무료. API 그룹별 초당 호출 제한(시세 15회, 주문 10회, 계좌 1회 등). 매수가능금액·수수료 같은 주문 조회는 초당 6회인데, 장 시작 직후인 09:00~09:10에는 3회로 줄어듭니다
갱신 주기: 실시간(웹소켓 구독)
주의점: 허용 IP를 미리 등록해야 하고, 목록에 없는 IP에서 부르면 403으로 막힘

토스증권 Open API 가이드 문서 <출처: 토스증권>

바이브 코딩 쪽에서 눈에 띄는 건 문서를 AI가 읽도록 만들어 뒀다는 점입니다. OpenAPI·AsyncAPI 규격 파일과 llms.txt를 따로 두고 있어서, 코딩 에이전트에 문서 주소만 물려도 호출 코드를 곧잘 짭니다. 챗GPT나 클로드에 키를 연결해 대화로 주문을 넣는 방식도 공식으로 안내하죠.

한국투자증권 KIS Developers: HTS 없이 쓰는 증권사 API의 출발점

KIS Developers는 실시간 시세부터 잔고·주문까지 REST와 웹소켓으로 연결할 수 있습니다. 2022년 4월에 문을 열었는데, HTS에 접속하거나 별도 프로그램을 깔지 않고도 쓸 수 있게 한 건 국내 증권사 중 처음이었습니다. 그전에도 키움 Open API 같은 게 있었지만 윈도우 PC를 켜 둬야 도는 방식이었습니다. python-kis처럼 AI가 이해하기 좋은 코드 기반 생태계가 붙어 있다는 것도 장점이죠.

발급 관문: 비대면 계좌 개설 + 앱키 발급(공공데이터 쪽보다 문턱이 높은 편)
무료 한도: 무료(호출 유량 제한 있음)
갱신 주기: 실시간

한국투자증권 KIS Developers 메인 <출처: 한국투자증권>

금융위 주식시세정보: 공짜로 받아오는 공식 주가 정보

금융위원회 주식시세정보 API는 시가, 종가, 고가, 저가, 거래량 데이터를 줍니다. 대신 아쉽게도 실시간은 아닙니다. 영업일 기준 하루 지나 오후 1시 이후에 받을 수 있죠. 그러니 바로바로 체크하기보다는 기존 데이터의 분석이나 활용에 쓰는 편이 좋아 보입니다.

발급 관문: 공공데이터포털 활용신청, 키만
무료 한도: 개발계정 일 10,000회
갱신 주기: 일 1회

금융위원회 주식시세정보 <출처: 공공데이터포털>

경제 지표는 한국은행 ECOS API가 가입 즉시 키를 주고 기준금리, 환율, GDP까지 커버해 줍니다. 일자 단위 고시 환율만 필요하면 수출입은행 환율 API로도 충분하고요(인증키 발급만, 하루 1,000회).

즉, ‘지금 호가’가 필요하면 증권사 API로 가야 합니다. 시작하기 쉬운 쪽은 토스, 상품 범위가 넓은 쪽은 KIS(파생·채권까지)입니다. 키움증권도 REST와 웹소켓을 열어 뒀으니 셋 중에 고르면 됩니다. ‘어제 종가 대시보드’면 금융위 데이터로 충분합니다. 다만 하루 늦는다는 한계는 용도에 따라 치명적일 수 있습니다.

부업 확장 시 주의할 건 증권사 API 쪽입니다. 본인 계좌의 매매를 자동화하는 용도로 열린 것이라, 받아 온 시세를 상업 서비스로 다시 제공하는 건 사실상 어렵다고 봐야 합니다. 이건 토스도 KIS도 키움도 마찬가지예요.

5. 부동산

우리 동네 아파트가 얼마에 팔렸는지 조회하기, 관심 단지 실거래 알림, 전세가율 계산기 등등. 부동산 앱은 관심이 큰 만큼 새로 파볼만한 영역입니다. 이 앱의 메인 재료로 쓰는 데이터는 대부분 실거래가입니다.

국토부 아파트 매매 실거래가: 공신력 최고 부동산 데이터

국토교통부 아파트 매매 실거래가 자료 API는 법정동코드 앞 5자리와 계약년월 6자리만 넣으면 그 동네의 매매 실거래 목록 데이터를 통째로 줍니다.

발급 관문: 공공데이터포털 활용신청(자동승인)
무료 한도: 개발계정 일 10,000회
갱신 주기: 신고 기반 수시 반영, 계약 신고 기한이 30일이라 사실상 월 단위
주의점: 전월세·연립·오피스텔 등 유형별로 같은 패턴의 API가 따로 있음

국토교통부 아파트 매매 실거래가 자료 <출처: 공공데이터포털>

그 특성상 다섯 개 도메인 가운데 계약 시점에서 내 앱까지 데이터가 오는 데 가장 오래 걸립니다. 애초에 신고 들어오기까지가 길기 때문이죠. 반면 활용신청 횟수는 1만 6,000건을 넘어요(2026년 8월 기준). 한 달 정도 늦게 나오는 데이터라도 큰 돈이 걸린 거니 충분히 귀하다는 뜻이죠. 실시간이 전부는 아닙니다. 데이터의 중요도가 신선도보다 강력하니, 잘 보여줄 방법을 고민하는 게 좋습니다.

공공누리라 상업적인 이용도 할 수 있고요. 유료 서비스를 고려한다면, 마찬가지로 활용사례를 등록해 운영계정으로 전환해야 합니다.

마치며

찾다 보니, 특히 이쪽 방면에서는 국가가 제공하는 데이터가 생각보다 참 많았습니다. 알아두면 어떻게든 일상에 밀접한 정보이니 보여주는 방법을 잘만 고민하면 충분히 사용자를 구하기도 쉽겠다는 생각이 들었죠.

그래서 내가 어떤 도메인에 관심이 있는지 잘 생각해 보고, 그 데이터의 특성에서 서비스를 구상하는 것도 좋겠다 싶었습니다. 데이터를 받아오는 속도는 어느 정도인지, 얼마나 신뢰할 수 있는지, 한계는 무엇인지 등등. 여기에 이 데이터를 가장 잘 보여주며, 사람들이 또 데이터를 쌓아갈 수 있는, 재미있는 컨셉이 얹어지면 꽤 훌륭한 서비스가 나오지 않을까요?

다음 편에서는 사람들이 일부러 찾아가는 재미·취향형 다섯 도메인, 사주, 영화, 게임, 여행, 검색 트렌드 API를 소개하려고 합니다. 또 궁금한 것이 더 있다면, 그쪽 API도 찾아볼게요.

]]>

[요즘IT x 노션] ‘로컬앱 자랑대회’ 출전작 모집!

업무용으로 직접 만들었지만, 내 컴퓨터에서만 도는 도구를 요즘IT가 찾습니다.

배포도 못 했고 코드도 공개할 수 없지만 회사에서는 매일 쓰이는 것들, 그걸 무대에 올려 보려고 합니다.

요즘IT 로컬앱 자랑대회(w. 노션), 출전 접수 받습니다!

➡️ 로컬앱 자랑대회 출전 접수하기

로컬앱이요?

클코나잇이 빌더나잇이 된 이유

지난 1년, 요즘IT는 클코나잇 시즌1·2를 통해 AI로 직접 뭔가를 만들어 본 사람들의 이야기를 들어 왔습니다. 두 시즌 걸쳐 라이브세션 신청자만 1,500명이 넘었고, 전체 콘텐츠 조회 수는 10만을 넘어섰습니다. 시즌1에서는 “이게 진짜 되네?” 같은 놀라움을, 시즌2에서는 이런 도구가 업무의 필수품으로 자리 잡은 노하우를 들었죠.

그러다 보니 한 가지가 눈에 들어왔습니다. 결과물 대부분이 배포를 목적으로 하기보다, 자기 자신과 팀을 위해 만든 도구였다는 점입니다. 코딩을 모르던 영상 PD가 만든 번역용 웹앱, PM이 직접 만든 크롬 익스텐션, 사내망 밖으로 못 나가는 견적 계산기. 밖에서는 존재를 아는 사람이 거의 없지만, 업무의 문제를 정말로 잘 해결하는 앱들이었습니다.

그래서 시즌3부터 클코나잇의 이름을 빌더나잇으로 바꾸고, 도구가 아닌 “결과물”에 집중하기로 했습니다. 그 첫 회차가 바로 로컬앱 자랑대회입니다.

로컬앱 자랑대회는 무엇을 자랑하나요?

이번 자랑대회에서는 완성품을 자랑하지 않습니다. 문제 이해도와 창의적 해결력을 자랑합니다.

특수 규칙 3가지

코드 공개 없음
배포·설치 파일 없음
화면을 못 보여주면 말로 설명해도 됨

여기서는 “보안상 여기까지만 보여드릴 수 있습니다”, “손이 많이 가서 배포할 생각은 없습니다”가 흠이 아닙니다. 대회의 정체성입니다.

이런 출전작을 찾고 있어요

출전 부문은 3가지입니다.

1. 로컬 프로그램

업무용으로 직접 만든 도구·앱. 보안 때문에 배포 못 하고 사내망이나 개인 노트북에서만 도는 것 대환영

예) 한 시간 걸리던 일을 5분으로 줄인 사내용 견적 계산기, 100명이 하던 반복 업무 1초로 줄여준 휴가 신청 프로그램 ….

2. 업무 자동화

반복 업무가 알아서 돌게 만든 파이프라인·에이전트·봇·스크립트. 앱 형태가 아니어도 무방, 흐름 자체가 작품

예) 월요일 아침에 알아서 도는 리포트 수집기, 회의가 끝나면 업무를 자동 분해하는 에이전트 ….

3. AI 네이티브 조직

팀·조직 단위로 일하는 방식이 실제로 바뀐 사례. 역할과 업무 경계의 변화 포함해, 모든 업무를 완벽히 AI와 함께하는 조직 이야기

예) 모든 일을 AI와 함께 꾸려가는 팀. 모든 경험과 권한을 AI와 공유하는 워크플로 …

경력·직군·회사 규모는 보지 않습니다. 개발자가 아니어도 됩니다.

팀에서 세 명만 쓰는 도구, 아직 진행 중인 자동화, 사람보다 에이전트가 더 많은 팀 모두 환영합니다!

그럼 무엇을 보나요?

신청 폼에서는 아래 내용만 받습니다.

작품명과 한 줄 소개
무슨 문제를, 어떻게 해결해서, 어떠한 결과를 얻었나?
수치 성과 1개
데모 자료: 영상·스크린샷 또는 “말로 설명하겠습니다”

가장 중요한 조건은 “왜”, 그리고 “성과”입니다. 설계의 아름다움도, 동작의 완결성도 중요하지 않습니다. AI가 만든 스파게티 코드여도 상관없습니다. 문제를 새롭게 바라보고 AI와 함께 해결한 과정, 그리고 그로 인해 얻은 성과만을 주목하려고 합니다.

그래서 문제와 성과 / 아이디어 / 재현 가능성 / 발표 서사 네 가지를 기준으로 발표작을 선정합니다.

출전팀에게 드리는 것

본선 무대: 데모 데이 20분 발표. 현장과 온라인 동시 송출
기록 자산: 발표 내용을 요즘IT 매거진 아티클과 발표 영상으로 제작. 공유·포트폴리오 활용 환영
공식 소개: 요즘IT 웹사이트·뉴스레터·SNS에서 출전팀과 작품 소개
데모 데이 현장 네트워킹: 노션이 제공하는 공간에서 지금 진짜 일 잘하는 분들과 네트워킹할 기회
굿즈: 노션과 함께 준비한 현장 굿즈
다음 기회 연결: 후속 인터뷰나 다음 시즌 우선 참여 기회

➡️ 로컬앱 자랑대회 출전 접수하기

공간 파트너, 노션

이번 대회는 노션(Notion)이 공간 파트너로 함께합니다. 데모 데이 장소와 현장 F&B, 참가자 굿즈를 노션이 제공합니다. 로컬앱과 업무 자동화를 만드는 사람들이 실제로 가장 많이 쓰는 도구 중 하나이니, 판을 함께 깔기에 이보다 알맞은 파트너를 찾기 어려웠습니다.

특별 혜택, 하나 더! 본선 4팀 중 1팀은 노션 담당자가 직접 고른 ‘노션 특별상’으로 참여합니다. 워크플로에 노션이 들어간 응모작이 후보입니다.

*나머지 3팀은 요즘IT가 부문별로 편성하며, 이 3팀의 편성에는 어떤 AI 툴을 썼는지가 전혀 반영되지 않습니다.

노션이 제공하는 파트너 혜택: Notion for Startups

아직 노션을 써 보지 않은 스타트업을 위해 Notion for Startups 프로그램을 운영합니다. Notion Business 플랜(Notion AI 포함)을 최대 100명 · 6개월 무료로 쓸 수 있죠. 투자유치 조건은 없습니다. 팀으로 출전하실 분들은 한번 확인해 보시면 좋겠습니다.

신청 링크:Notion for Startups

대회 안내

접수 기간: 8월 26일(수) ~ 9월 13일(일)자정
발표 길이: 20분 (발표 15분 + 문답 5분)
본선 규모: 4팀. 3개 부문별 1팀 + 노션 특별상 1팀
데모 데이: 10월 6일(화) 오후 7시
방식: 현장(선릉 위워크 3호점, 노션 제공) + 줌·유튜브 동시 송출
참가 단위: 개인 또는 팀. 본선 현장 참여는 팀당 1~3명

신청 방법

진행 절차: 접수 → 서류 검토 → 개별 온라인 인터뷰(9월 중, 팀당 15분) → 본선 편성
본선 4팀 발표: 9월 17일(목) 개별 연락 및 공지

다시 한번, 로컬앱 자랑대회는?

이번 자랑대회는 깔끔한 성공담을 기다리지 않습니다.

정말로 막혔던 구간, 몇 번이고 다시 만든 이야기, 팀에서 세 명만 쓰는 도구도 그대로 좋습니다. 내 컴퓨터에서만 돌아도 출전 자격은 충분합니다.

부담 갖지 마시고 편하게 자랑해 주세요!

➡️ 로컬앱 자랑대회 출전 접수하기

]]>

리더는 "AI 왜 안 쓰냐" VS 실무자는 "사고 나면요?"

라이브 서비스는 멈출 수 없다. 신규 개발은 실패하면 접으면 되지만, 이미 서비스 중인 제품은 그럴 수 없다. 사고가 나면 지금 접속해 있는 사용자에게 바로 영향을 미친다. 그래서 라이브 조직에서는 어떤 판단을 하든 “지금 돌아가는 걸 망가뜨리지 않는가”를 먼저 확인하게 된다.

AI 도입도 마찬가지다. 지금 대부분의 회사가 AI를 쓰라고 한다. 흐름 자체는 거스를 수 없고, 언젠가는 해야 할 일이라는 데도 대체로 동의한다. 그런데 유독 라이브 조직에서는 이 흐름이 더디다. 몰라서도 아니고, 하기 싫어서도 아니다. 라이브라는 환경이 가진 조건 때문이다.

이 글에서는 그 조건이 무엇인지, 필자가 게임 조직에서 경험한 점을 토대로 그것이 왜 조직 안에서 경영진과 실무자의 갈등으로 번지는지, 그리고 그 상황에서도 실제로 시도해 볼 수 있는 것이 무엇인지를 정리해 보려 한다.

<출처: 작가, AI로 생성>

라이브 서비스가 원래 안고 있는 것들

AI 이야기를 하기 전에, 라이브 서비스의 유지보수가 왜 그렇게 무거운지부터 짚어야 한다. 이 조건들이 뒤에서 AI 도입을 막는 이유가 되기 때문이다.

기능은 더해지기만 하고 빠지지 않는다

라이브 서비스는 한 번 만든 기능을 좀처럼 지우지 못한다. 이미 그 기능을 쓰고 있는 사용자가 있고, 없애면 항의가 들어온다. 쓰는 사람이 적어도 마찬가지다. 그래서 업데이트마다 새 기능은 더해지는데, 기존 기능은 그대로 남는다.

문제는 늘어나는 것이 기능의 개수만이 아니라는 점이다. 기능이 늘면 기능끼리 서로 영향을 주는 경우의 수가 같이 늘어난다. 하나를 수정할 때 확인해야 할 범위도 같이 커진다. 그래서 유지보수 부담은 기능이 늘어나는 속도보다 빠르게 커진다.

얽혀 있는 구조를 AI가 정확히 파악하지 못한다

라이브 서비스는 데이터 테이블과 오래된 코드가 스파게티처럼 복잡하게 연결되어 있다. 파트끼리 공유하는 문서 형식도 마찬가지다. 그래서 특정 파트만 떼어 AI로 처리할 수가 없다.

AI가 대충 해석은 할 수 있을지 몰라도, 사용자가 정확히 짚어 주지 않으면 완벽히 파악하지 못한다. 관련 코드 파일과 로직 구조, 돌아가는 흐름과 세팅된 데이터 값을 모두 던져 주고 시간을 주고 진행 도중 포인트를 짚어 주면서 진행해도 한계가 있다. 어느 정도 파악한 것 같아 테스트 케이스를 돌려 보면, 꼭 20% 정도는 엉뚱한 값이 들어가거나 값을 비워 놓는 경우가 생긴다.

이런 부분이 자칫 큰 사고로 이어진다. 예를 들어, 게임 조직에서 어떤 아이템을 추가하는 기능을 바이브코딩으로 만들거나, AI를 통한 자동화 도구로 구축했다고 가정해 보자.

아이템을 데이터 테이블에 몇 개 추가하고, 데이터 연결성을 모두 통과하여 QA까지 검수 완료된 아이템이 라이브에 패치되었다. 그런데 패치 몇 시간 뒤 갑자기 메신저가 울린다. 아이템을 얻을 수 있는 획득처가 잘못 설정된 것이다. 그럴 리가. 분명 데이터 연결성 검증도 통과하고 QA도 확인한 부분이다. 다시 살펴본다. “A던전 보스를 클리어”해야 얻을 수 있는 아이템인데, “A던전 전체에서 획득 가능한” 아이템으로 설정되어 있다.

유저들은 난리가 났다. 돈을 써서 던전을 열심히 돌았는데 하나도 안 나온다, 유저 기만이다, 환불해라. 큰일 났다. 다시 확인해 본다. 아이템을 설정하는 시트 내부, 해당 아이템의 획득처 설정에서 onlyBoss 컬럼의 값이 FALSE인 것이다. 데이터 연결성 체크에서는 저 값이 TRUE이든 FALSE이든 상관없이 값이 있으면 PASS 처리되고, QA 과정에서는 A던전의 보스를 잡았더니 나왔다고 판단되어 OK 사인이 떨어진 것이다. 물론 이런 상황은 어느 정도 QA와 작업자의 미스이지만, 항상 모든 이슈는 이런 실수로부터 시작된다라는 가정을 하고 넘어가자.

AI에게 현재 상황을 말하고 왜 저 셀 값을 TRUE가 아니라 FALSE로 했는지 추궁하니, 자신의 판단에 있어 그 부분이 세팅 시 명확히 제공되지 않아 폴백 과정에서 FALSE로 처리했다고 답한다. 죄송하다는 말과 함께.

<출처: 레딧, r/ClaudeCode>

세팅과 폴리싱은 다른 일이다

라이브 작업 중에는 사람이 창의성을 발휘해야 하는 종류가 섞여 있다. 게임이라면 신규 스킬이나 패턴을 만드는 일이 그렇다. 그런데 이 작업은 아이디어를 내는 것으로 끝나지 않는다.

5년 전에 시작한 어떤 게임의 라이브 서비스가 있다고 가정해 보자. 스킬 하나를 만들기 위해서는 엑셀 파일 세 개를 동시에 열어 작업해야 하고, 만들어진 스킬을 다시 캐릭터에 연결하는 작업까지 하면 대략 열 개 정도의 엑셀 시트에 데이터가 올바르게 입력되어야 한다.

보통 게임에서 사용되는 데이터 테이블 값이 단순히 수치만 입력된 것이 아니다. 업데이트에서 클라이언트 코드를 수정하면 바이너리 업데이트가 필요해지기 때문에, 통상적인 게임에서 데이터 테이블은 스크립트를 적당히 엑셀에 구겨 넣은 형태다. A1 셀에 30, 이런 식으로 들어가는 것이 아니라 skill(스킬ENUM, 밸류, val1, val2, 스킬타입) 같은 식이다. 게임 장르나 리드 프로그래머의 성향에 따라 다를 수 있지만, 대개는 이런 식의 복잡한 문자열 기반이 많을 것이다. 게다가 라이브 업데이트에서 스킬 파라미터가 바뀌면 이 부분도 같이 바뀐다. 간단한 스킬 데이터도 저런 문자열 기반, 혹은 스크립팅 데이터가 복잡하게 얽혀 동작한다.

게다가 이 부분은 제작자의 창의성이 필요하다. 게임을 해 본 사람이라면 알겠지만 스킬 하나에는 많은 리소스가 포함된다. 어떤 이펙트를 쓸 것인지, 이펙트의 범위는 어떻게 되는지, 사운드는 어느 타이밍에 시작되는지, 시전 속도, 소모 자원, 아이콘, 쿨타임 등. 이런 부분은 단순히 값을 채워 넣는 게 아니라, 최초 세팅 후 수 시간 혹은 몇 달 동안 계속 폴리싱하여 깎아 나가야 유저들에게 제공할 수 있는 프로덕트 레벨의 아웃풋이 나온다.

AI는 값을 세팅할 수는 있어도, 세팅된 값이 유저 입장에서 어떻게 느껴지는지 알 수 없다.

그 사이 담당자는 계속 바뀐다

이런 복잡도를 가진 작업이 수개월, 수년간 누적되며 서비스는 피로해지고 사람은 떠나거나 교체된다. 코드와 데이터, 리소스들은 계속 남게 되지만 정작 그걸 만든 사람은 조직에 남아 있지 않다. 문서가 남아 있어도 왜 그렇게 만들었는지까지 정확히 적혀 있는 경우는 드물고, 코드 주석도 마찬가지다. 심지어 이 부분이 중간중간 유지보수가 누락되면서 서로 안 맞는 경우도 생긴다. 서비스는 돌아가지만, 왜 이렇게 만들어졌고 구현되었는지를 아는 히스토리를 아는 사람이 없어진다. 결국 시스템이 아니라 몇몇 사람에 의해 겨우겨우 연명해 가는 형태가 된다.

남은 사람들이나 충원된 인력은 각자 자기가 맡은 부분만 겨우 이해한 상태로 아슬아슬한 유지보수를 이어가게 된다. 자기 담당이 아닌 부분은 아예 건드리지 않는 것이 서비스 관점이나 자기 관리 관점에서 유리하기 때문에, 제발 무너지지 않아라 기도하며 아슬아슬한 줄타기를 하고 있는 현실이 생기게 된다.

너무나 쓰고 싶고, 해야 하지만, 어디서부터 써야 할지 모르겠다

이런 문제들이 겹겹이 쌓이면서 모순이 생긴다. 회사가 줄이고 싶어 하는 비용의 1순위는 라이브 유지보수다. 인원이 계속 붙어 있어야 하고, 컴퓨터 전원 끄듯 내일 당장 서비스를 종료할 수도 없다.

더군다나 유지보수 인력이 계속 있을 거라는 보장도 없다. 라이브가 겨우 유지되는 조직은 보통 성과나 달성, 이로 인한 리워드가 박한 편이라 인력 이탈이 빈번하고, 심지어 이탈된 인원을 충원하기도 힘들다. 더 좋은 비전과 미래를 가진 신규 조직, 혹은 같은 라이브여도 굉장히 고밸류의 서비스를 제공하는 조직이 아니라면, 구직자 입장에서도 이 조직을 선택할 메리트가 극히 적기 때문이다.

따라서 회사나 내부 조직도 AI를 활용하여 이 부분을 어떻게든 극복해 보고 싶어 한다. 하지만 역설적으로 이런 라이브 서비스는 AI를 도입하기 어려운 구조적인 문제가 있다.

일정도, 검증할 여력도 없다

빡빡한 라이브 일정에서 위험을 감수하기는 어렵고, 도입하더라도 별도 QA를 붙이기 어렵다. AI로 기능 한두 개를 고쳐서 써 보다가 결국 이슈가 생기거나 생각만큼 효율이 나오지 않고, 당면한 일감에 치여 문제들을 모두 해결할 수 없어 결국 다시 원래 방식으로 회귀한다.

앞에서 말한 데이터 구조를 직접 겪고 나면, 작업자 입장에선 공포가 생긴다. AI가 저 셀 하나를 인식하게 하는 것도 몇 시간이 걸리는데, 각 데이터 시트의 연결도를 정리하고 오차 없이 도구를 만들 수 있을까. 지금은 개발 단계가 아니라 5년차 라이브 서비스 중인데 말이다. 다음 주 업데이트를 준비해야 하고, 다음 달 메이저 업데이트도 준비해야 한다.

몇 번 시도해서 겨우 도구를 만들어 내고 돌려 보면 오류투성이다. 게다가 검증은 당사자가 직접 해야 한다. 앞에서 본 것처럼, 시키지도 않은 부분을 AI가 추론해서 처리해 놓은 경우까지 직접 찾아내야 한다. 이런 위험을 안고 과연 어떤 실무자가 공격적으로 AI를 도입할 수 있을까.

문제가 났을 때 누가 책임지는지가 정해져 있지 않다

앞의 문제들은 조직 안에서 결국 이런 모습으로 드러난다. 위에서는 왜 안 쓰냐고 묻고, 아래에서는 사고 나면 누가 책임지냐고 답한다. 어느 쪽도 틀린 말을 하고 있지 않다.

경영진 입장에서는 경쟁사도 다 쓰는 도구를 우리만 안 쓰는 상황을 방치할 수 없다. 실무자 입장에서는 문제가 생겼을 때 결국 자기가 밤을 새우고, 자기 이름이 사고 보고서에 올라간다. 실무자가 소극적인 이유는 능력이 없어서가 아니라, 결정 권한은 없는 상태에서 위험과 책임만 혼자 지기 때문이다. 도입 여부를 정하는 사람과 문제가 났을 때 수습하는 사람이 다르면, 소극적인 태도일 수밖에 없다.

이 상태를 그냥 두면 조직은 이상해진다. 공식적으로는 AI를 도입한 회사인데, 실제로는 각자 알아서 개인 도구를 쓰는 상태로 굳는다. 무엇을 어디까지 썼는지 아무도 정리하지 않으니, 나중에 문제가 생겨도 원인을 찾기 어렵다.

그럼에도 해야 하고, 할 수 있는 부분은 있다

도구 성능을 아무리 비교해도 이 상황은 풀리지 않는다. 더 좋은 모델이 나와도 데이터 구조가 복잡한 것은 그대로고, 일정이 빠듯한 것도 그대로다.

그렇다고 책임 소재를 정하는 것으로 끝날 문제도 아니다. 누가 책임질지를 문서로 정해 둔다고 해서 데이터 구조가 단순해지지도, 검증할 시간이 생기지도 않는다. 책임이 명확해지면 시도할 여지가 조금 생기는 정도이고, 그 다음이 없으면 결국 아무것도 달라지지 않는다. 그렇다고 안 할 수도 없다. 그러니 필요한 것은 지금 조건에서 실제로 굴러갈 수 있는 방법을 찾는 일이다.

양쪽 모두에 조정이 필요하다.

책임자 쪽에서는 지금 수준의 AI가 모든 것을 자동화할 수 없다는 점과, 실무자가 소극적일 수밖에 없는 것임을 이해해야 한다. 그리고 단순히 “하라면 해라” 혹은 책임 소재 같은 주관적 요소가 아니라, 실무자에게 구체적인 현재 상황을 요청하고 그로 인해 발생할 수 있는 문제점과 실 이득을 명확히 해야 한다.

지원이 필요하다면, 세미나 참석이나 강의 수강같이 실무자 입장에선 뜬구름 잡는 것들이 아니라, AI를 도입하기 위해 필요한 시간과 KPI를 명확히 지정해 주는 것이다. AI를 도입한다고 당장 내일부터 나아지는 것이 아니다. AI를 사용하여 결과물이 나올 때까지는 시간이 걸리고, 그것이 실제 눈에 보이는 코스트 절감으로 이어지기까지는 생각보다 오랜 시간이 소요될 수 있다.

도입 후 개발 사이드에서의 시행착오, 그 시행착오를 거쳐 새로운 파이프라인을 만들었을 때 파이프라인의 안정성을 검증해야 하는 시간, 프로덕트로 배포되었을 때 사용자 사이드에서 이전과 같은 수준으로 느끼는지에 대한 반응까지. 단순히 AI로 무언가 만들어 낸 것과 달리, 라이브 서비스에서는 이 모든 것이 완료될 때까지를 KPI에 편입해야 서로의 이해관계가 맞는다.

실무자 쪽에서는 모든 AI 활용을 라이브 사고 위험과 같은 것으로 놓고 전면 거부하는 태도를 다시 봐야 한다. 위험한 부분도 있지만, 그렇지 않은 부분도 분명히 있다. 그 구분을 가장 정확히 할 수 있는 사람은 실무자다. 안전하게 시도할 수 있는 업무를 골라내는 것 자체가 실무자만 할 수 있는 일이다.

그리고 현재 구조를 구체적으로 정리하고 명시해서 상급자와 소통해야 한다. 단순히 “위험해서 안 된다”는 건 상위자 입장에서 받아들일 수 없는 변명처럼 들리기 때문에, 이를 정확히 왜 어떻게 안 되는지, 혹은 어떤 부분이 가능한지, 앞에서 말한 것처럼 도입은 가능하나 발생할 수 있는 개발적 리스크와 품질적 리스크는 무엇이고 파이프라인 적용 후 사후 플랜은 어떻게 되는지로 정리하는 것도 실무자가 해야만 하는 일이다.

반복되는 작은 작업부터 시작한다

내 생각은 이렇다. 아주 작은 것부터 하나씩 해 보는 것이다. 라이브 서비스를 해 본 사람이라면 이해하겠지만, 라이브 서비스는 정말 자잘자잘한 것들이 모이고 모여 서비스의 부채를 만드는 경우가 많다. 추가하거나 변경할 때는 코드 몇 줄, 혹은 데이터 셀 몇 개, 스프라이트 리소스 몇 개였을지라도, 이것들이 시간이 지남에 따라 계속 누적되어 코스트를 만든다.

그러니 엄두가 안 나는 것이다. 개발자 입장에서는 가장 큰 것부터 줄이고 싶지만, 오히려 그렇게 큰 부분은 파이프라인 자체를 통째로 변경하거나 대규모 리팩토링을 해야 하는 경우, 혹은 연관된 부분이 너무 많아 사이드 이펙트를 만들 수 있는 경우일 가능성이 높다.

따라서 가장 작은 것부터, 가장 귀찮은 것부터, 그리고 가장 중요한 건 조직 구성원 개개인이 가볍게 시도할 수 있는 것부터 해야 한다. 그래야 AI를 다루는 스킬이 늘어나고, 처음엔 막막했더라도 어디서부터 어디까지 가능한지에 대한 개념이 생길 것이다.

예를 들어, 데이터 시트를 변경하거나 자동화 툴을 만들어야 하는 비프로그래머 조직에서는 데이터 입력, 파이프라인 문서 포맷, 데이터 연결성 검증 등이 늘 문제가 된다. 특히 데이터 연결성 검증이나, 특정 기능 혹은 엔진상에서 클라이언트 온리로 동작하던 시뮬레이션 기능 등이 필요할 경우, 이슈 발제부터 컨펌, 구현 명세서 작성, 구현 요청, 테스트를 거치는 일반적인 개발 파이프라인을 여러 파트에 걸쳐 확인받고 핑퐁하여 만들어야 했다. 상상만 해도 머리 아픈 일이다.

지금은 작업 당사자가 직접 도구를 만들어 볼 수 있다. 이 방식은 서비스 자체를 건드리지 않으니 승인하는 쪽에서 결정하기 쉽고, 요청 명세서처럼 다른 파트에 설명하기 위해 해야 하는 기반 작업 없이 필요한 사람이 즉시 만들 수 있기 때문에 명확한 결과물이 나온다. 이것이 즉시 라이브 서비스에 도움이 되진 않더라도, 라이브 서비스를 진행하면서 작은 것들이 누적되어 큰 라이브 코스트를 만들듯이, 이런 시도들이 하나하나 모여 어느샌가 정말 눈에 띌 정도로 코스트나 프로세스 절감, 혹은 라이브 서비스의 효율성 상승, 프로덕트 완성도 상승 등의 긍정적인 효과로 이어질 수 있는 것이다.

내 경험도 여기서 출발한다. 엑셀 입력 시 휴먼에러를 줄이는 일, 다량의 시트를 한 번에 바꾸는 일, 전투 공식 문서를 최신화하기 위해 전투 관련 코드를 직접 분석해서 프로그래머와 함께 유지보수용 문서를 최신화하는 일, 혹은 콘텐츠마다 설정된 확률값이 현재 데이터와 안내된 값이 맞는지 크로스 체크하는 일들이었다. 당시 전투 담당 클라이언트 프로그래머도 초기 멤버가 아니어서 모든 히스토리를 알고 있지 못했고, 부분부분 모르는 부분이 서로 존재하는 상황이었다.

우선 기획 파트 및 CS 파트에서 매번 궁금하거나 필요한 위키 형태의 정리가 필요했고, 각 파트에서는 리스트를 정리해 담당 프로그래머에게 넘겼다. 또한 전투를 담당하던 기획자는 알려진 버그 및 전투 시 발생하는 기능들의 우선순위를 알기 위해 해당 부분이 어떤 코드 파일을 참조하는지 프로그래머와 핑퐁했다. 프로그래머는 기존 히스토리 점검 및 위키를 정리하며 자신이 알고 있는 내용을 최신화했고, 다른 파트에서는 최신화된 데이터를 갱신할 수 있게 되어 매번 프로그램 파트에 문의하던 비효율적인 프로세스를 끊어낼 수 있었다.

핵심은, 일반적인 업무 과정처럼 보이는 이 과정이 실제 라이브 조직에서는 AI를 사용한 코드 분석 및 정리 없이는 쉽지 않다는 점이었다. 이걸 그냥 하려면 최소한 2주짜리 작업이었는데, 불과 이틀 만에 모두 마무리할 수 있었다. 그때 당시에는 조직 구성원 모두가 AI에 익숙하지 않아 회의적이었는데, 결과물이 일목요연하게 이틀 만에 정리된 것을 보고 모두 여론이 바뀌는 계기가 되었다.

데이터 시트를 최신화하는 경험은 구체적으로 이런 사례였다. 엑셀 파일 하나가 50메가가 넘는다. 겨우 엑셀 파일 하나 여는데 이렇게 무겁다고? 하는 상황이다. 게다가 파일을 열어 보면 각종 서식, 중복 체크, 데이터 무결성 검사 등, 정말 엑셀을 열어 수정할 때마다 짜증과 한숨이 나올 수밖에 없다. 그런 상황에서 순간적으로 잘못된 셀에 데이터가 입력되는 경우가 잦고, 그게 라이브에 나가면 주말에 메신저가 울린다.

깃(Git)이나 SVN에서 데이터 변경 사항을 diff로 확인하면 되는 거 아니냐고 할 수 있다. 5년차 라이브 서비스 게임의 데이터 양은 diff로 확인할 수 있는 수준이 아니다. 그래서 필자는 이런 방식을 시도해 봤다. 앞서 말한 서식과 중복 체크, 데이터 무결성 검사 같은 엑셀 자체의 기능은 모두 끄고, 그 역할을 대신할 기능을 따로 만드는 것이다. 엑셀을 닫을 때 이번 작업에서 수정한 부분이 어느 시트의 어느 셀인지 추가 확인창을 띄우는 식이다. 엑셀의 주요 기능, 특히 데이터 유효성 검사 등은 여러 사람이 사용할 경우 문제를 일으킬 가능성이 높기 때문이다.

그리고 더 나아가, 해당 엑셀을 직접 수정하는 게 아니라 마치 포인터처럼 파일을 열지 않고 수정할 수 있는 툴을 만들어 보기도 했다.

<출처: 작가 캡처>

처음엔 성공적이었다. 엑셀 파일을 매번 직접 열 필요가 없어지니 엑셀이 무거워짐으로 인해 발생하는 버벅거림이 사라졌고, 작업자들의 스트레스가 줄어드는 간접적인 효과도 있었다. 다만 이 역시 필자가 해당 게임의 라이브 서비스에서 손을 떼고 툴 유지보수가 끊기면서, 이후에는 다시 레거시 방식으로 돌아갔다고 전해진다. (단, 이 부분은 AI를 통한 자동화 이슈라기보다는 조직 사이드에서 발생한 인수인계 프로세스 문제라, AI의 문제는 아니라고 생각되긴 한다.)

정리할 대상이 반복 입력만은 아니다. 하나의 기획서를 각 파트가 쓸 수 있는 형태로 옮기는 작업도 매번 반복된다. 같은 내용을 파트마다 다른 형식으로 다시 쓰는 일이다. 이 변환 규칙을 도구로 만들어 두면 반복 작업이 줄어든다. 그리고 어떤 형식으로 주고받기로 했는지가 사람의 기억이 아니라 도구에 남으니, 담당자가 바뀔 때 히스토리가 사라지는 문제도 조금은 덜해진다.

모두 드라마틱하게 라이브 코스트를 줄여 주는 부분은 아니었지만, 분명히 필요한 부분이었다. 특히 전투 관련 코드, 문서 최신화와 콘텐츠 확률값 점검은 계속 해야지, 해야지 하면서 미루고 미루던 일이었다. 당장 생산성에 도움이 되지 않더라도 해야 하는데, 일정상 계속 뒤로 밀려 부채가 쌓이던 상황이었기 때문이다.

넘지 말아야 할 부분

반대로 지금 수준에서 하지 말아야 할 것도 있다. 실사용자와 서비스 데이터베이스에 AI가 직접 쓰기 작업을 하도록 자동화하는 것이다. 읽어서 정리하는 것까지는 괜찮지만, 사람 확인 없이 바꾸게 두면 앞에서 말한 문제들이 그대로 재현된다.

마치며

정리하면 이렇다. 라이브 조직이 AI를 쓰지 못하는 이유는 몰라서도 게을러서도 아니다. 데이터와 코드가 오래 얽혀 있어 부분만 떼어 낼 수 없고, 사람이 감각으로 깎아야 하는 작업이 섞여 있고, 일정에 검증할 여유가 없기 때문이다. 당장 바꾸기 어려운 조건들이다. 그렇다고 손을 놓을 수도 없으니, 그 안에서 지금 할 수 있는 것을 찾아야 한다.

그리고 처음부터 크게 시작할 필요는 없다고 본다. 가능한 부분부터 명확히 한다. 그리고 너무 보수적으로 접근할 필요도 없다. 단순한 반복 작업부터 시작해서, 조직 전체가 AI에 익숙해지는 속도에 맞춰 범위를 넓혀 가는 편이 현실적이다. 작게 보이지만 이런 시도가 쌓여야 다음 단계를 설득할 근거가 생긴다. 근거 없이 위에서 밀어붙이거나 아래에서 버티기만 하면, 조직이나 프로덕트, 혹은 작업자 개인 모두 아무것도 얻을 수 없다.

AI를 거부할 수 있는 흐름은 이제 그 어디에도 존재하지 않는다. 그러나 아직 각자의 위치에서 AI 사용에 대한 인지 상태가 크게 다르기에, 우리는 단순히 AI를 써야 한다가 아니라, AI를 쓰기 위해서 필요한 것부터 접근하는 방식을 써야 한다.

AI는 한 사람이 직접 할 수 있는 일의 범위를 넓혀 준다. 다만 무엇을 맡기고 무엇을 사람이 할지는 여전히 사람이 정할 수밖에 없다. 라이브 서비스는 수많은 이해관계가 정말 상상할 수 없을 만큼 어지럽게 묶여 있다. 그래서 AI 도입이 기술적인 문제가 아니라, 사람과 사람 간의 이해관계 구조에 있다. 답답하고 막막하지만, 그 구조 안에서도 시작할 수 있는 부분은 있다는 것을 모두에게 전하고 싶다.

]]>

현장이 만든 AI를 GS는 어떻게 상용 제품으로 키웠나

세계 3대 디자인 어워드로 꼽히는 레드닷 디자인 어워드에서 올해 한국의 산업 안전 서비스 하나가 상을 받았습니다. 이름은 ‘AIR’. 산업 현장에서 작업 전에 반드시 작성해야 하는 위험성평가서를 AI가 초안까지 만들어 주는 서비스죠.

디자인 상을 받은 제품이라 하면 으레 전문 디자이너와 개발자가 모인 팀을 떠올리게 됩니다. 그런데 AIR의 첫 프로토타입을 만든 것은 에너지 기업 GS파워 발전소 직원 다섯 명이었습니다. 다섯 명 모두 코딩을 한 번도 해 본 적 없는 비개발자였죠. 이들이 2024년 GS그룹 사내 해커톤에 나가 이틀 만에 만든 프로토타입이, 고용노동부 장관상 수상을 거쳐 2년 뒤 전국 사업장에 배포되고 디자인 상까지 받은 것입니다.

해커톤에서 나온 아이디어가 실제 제품이 되는 일은 드뭅니다. 대부분은 발표가 끝나는 순간 운명을 다하죠. 아이디어가 좋아야 살아남는 것이라고 하기도 어렵습니다. 좋은 아이디어도 현실화되기까지는 그 여정이 험난하니까요. 그렇다면 AIR에는 무엇이 더 있었을까요.

이 과정의 한가운데에 52g(오이지)가 있습니다. 52g는 GS그룹의 오픈 이노베이션 커뮤니티로, 그룹 전체의 AI·디지털 확산을 주도하는 변화 관리 역할을 수행합니다. 요즘IT는 AIR를 처음 만든 GS파워 부천안전보건팀 이주필 팀장, 그리고 이 제품을 상용 서비스로 키운 ㈜GS 52g 스튜디오의 심재혁·선우정·김원희 매니저를 만나, 아이디어가 살아남는 데 무엇이 필요했는지 들어보았습니다.

왼쪽부터 (주)GS 52g스튜디오의 선우정 매니저, 심재혁 매니저, 김원희 매니저와 GS파워 이주필 팀장 <출처: 요즘IT>

낯선 이야기는 아닐 겁니다. 사내 해커톤이나 AI 경진대회에서 나온 프로토타입 대부분은 데모와 함께 사라집니다. 아이디어가 나빠서가 아닙니다. 당장 수익이 되는 일이 아니거나, 만들 사람이 없거나, 어렵게 만들어도 운영을 이어받을 사람이 없기 때문입니다. AIR는 그 관문들을 어떻게 통과했을까요. 이 인터뷰는 그 답을 따라갑니다. 문제를 고른 사람, 만들게 한 구조, 그리고 이어받은 사람들의 이야기입니다.

52g(오이지)란?
52g는 GS그룹의 AI·디지털 확산을 이끄는 오픈 이노베이션 커뮤니티로, 'Open Innovation GS'의 약어입니다. 계열사마다 활동하는 '52g 크루'와 지주사 소속의 '52g 스튜디오로 구성되어 있습니다. 크루는 소속 기업을 대표하여, 조직의 변화를 직접 시도하고, 그 경험을 공유하는 실행 주체입니다. 올해부터 GS뿐만 아니라 외부 회사도 '오픈크루'로 활동하고 있습니다. 스튜디오는 이 활동의 실행을 더 빠르고 안정적으로 만드는 역할을 합니다.

서류 한 장에 한 시간, 그 시간에 현장을 못 갔다

이 이야기는 AI가 아니라 번거로운 문서 작업에서 시작합니다.

위험성평가는 산업안전보건법에 명시된 의무입니다. 어떤 작업을 하기 전에 그 작업에 어떤 위험이 있는지 빠짐없이 끄집어내고, 등급을 매기고, 개선 대책을 세워 문서에 담아야 합니다. 올해 6월부터는 이를 어기면 과태료를 무는 조항까지 시행됐습니다.

절차는 번거롭습니다. 설계 자료와 운전 매뉴얼, 과거 사고 사례를 모아 놓고 작업자들이 토론하며 위험 요인을 하나씩 채워 넣는 일로, 이주필 팀장에 따르면 ‘제대로 하면 한 건에 30분에서 1시간 정도’ 걸립니다. GS파워 부천사업소에서만 한 달에 600건 안팎의 작업이 발생한다고 하니, 산술적으로 매달 최대 600시간이 서류에 들어간다는 뜻입니다.

그가 답답했던 것은 시간 자체가 아니라 그 시간이 빼앗아가는 것이었습니다.

“사전 평가와 문서 기록도 중요하지만, 실제 현장에서 안전 대책을 확보하는 것이 가장 큰 도움이 됩니다. 문서 작업에 1시간이 걸리면 현장에서 써야 할 시간이 그만큼 줄어드는 것이니 아쉬웠죠.”(이주필 팀장)

안전을 위해 만든 절차가 정작 안전을 확인할 시간을 빼앗는 구조였던 것이죠.

또 하나의 문제는 사람이었습니다. 2020년을 전후로 시니어 근무자들이 대거 교체되면서 현장은 빠르게 젊어졌습니다. 그런데 이 팀장의 말에 따르면 위험성평가는 평가자의 경험에 큰 영향을 받습니다. “현장에는 변수가 많기 때문에 경험이 많아야 다양한 예측을 할 수 있습니다. 끼임 사고가 날 만한 곳인지, 질식 위험이 있는 곳인지는 경험으로 판단하는 것이죠.” 그래서 시니어와 주니어는 위험을 “도출할 수 있는 레벨 자체가 다르다”는 것이 이주필 팀장의 설명입니다.

GS 파워 부천안전/보건팀 이주필 팀장. GS 파워 소속 직원들과 함께 해커톤에 출전해 GS의 AX 플랫폼 미소를 활용한 위험성평가 도구 AIR의 초기 버전을 만들었다. <출처: 요즘IT>

이에 GS파워는 2023년, 2004년부터 쌓아온 JSA(작업안전분석) 데이터에 안전보건공단의 KRAS 기법을 결합한 자체 기법 P-JSA를 만들었습니다. 20년 치 작업 데이터와 평가 결과를 분석해 발생 가능한 위험을 440개 표준 유해위험요인으로 정형화하고, 세 단계 추론으로 해당하는 것을 찾아가게 한 것입니다.

P-JSA는 잘 정착했지만, 여전히 사람이 직접 위험을 상상해 찾고 클릭해야 했기에 소요 시간도, 시니어와 주니어 간의 격차도 좁히는 데는 한계가 있었죠.

코딩 한 번 안 해본 다섯 명이 해커톤에 나갔다

이 문제를 AI로 풀어보자고 제안한 것은 GS파워 기계정비팀의 한 젊은 직원이었습니다. 2024년, GS그룹이 개최한 1박 2일 생성형 AI 해커톤에 참가해보자는 것이었죠. 원래 2025년쯤으로 잡아 뒀던 AI 접목 계획을 한 해 앞당긴 것입니다.

팀은 다섯 명으로 꾸려졌습니다. 안전보건팀 3명, 기계정비팀 2명. 이주필 팀장이 사람을 고른 기준은 직무가 아니라 태도였습니다. “안전 담당자 외에 실제 현장에서 일하는 분들의 입장도 들어봐야 한다고 생각했어요. 안전에 관심을 두고 현장에 적용하려 노력하는 현업 담당자들로 꾸렸습니다.”

2024년 제 3회 GS그룹 해커톤 현장 사진 <출처: GS그룹>

코치로 붙은 52g 스튜디오 개발자 김원희 매니저는 당시 상황을 이렇게 전했습니다. “MISO로 위험성평가 관련 플로우를 하나 만들어 드렸는데, 다음 날 그 팀에서 300개를 더 만들어 오셨어요. 각 케이스마다 대응되게끔 작업 플로우를 다 만들어 오셔서, 역시 전문가 분들은 다르구나 생각했습니다.” MISO는 코딩 없이 블록을 연결하듯 워크플로우를 짜면 AI 서비스가 만들어지는 GS 그룹의 AX 플랫폼으로, 비개발자 다섯 명이 이틀 만에 프로토타입을 만들 수 있던 배경입니다.

이 팀장의 팀은 P-JSA를 위해 만들어뒀던 440개의 표준 위험 요인 데이터를 워크플로우 각 단계의 LLM에 입히고, 거기에 고용노동부가 구축한 과거 사망사고 유발 고위험요인(SIF) 데이터를 붙였습니다. 이 선택이 결과를 갈랐습니다. “여러 사업장이 저희를 찾아와 하소연한 것이, 자체 AI 위험성평가를 만들어봤는데 다 실패했다는 겁니다. 이유는 AI가 아무 말이나 다 해준다는 것이었어요. 저희는 실제 과거 데이터로 440개를 추려 놓았고, 거기에 법령에서 요구한 SIF를 붙여서 실제로 있을 법한 상황을 도출해 준다는 차이가 있었죠.” (이주필 팀장)

이름은 팀에서 가장 어린 1995년생 직원이 지었습니다.

“제가 이상한 네이밍을 던지는 걸 듣고 있던 팀원이 ‘혹시 AIR는 어떻겠습니까’ 하더군요. AI Risk Assessment의 앞글자인데, 공기처럼 누구나 쓸 수 있고 어디에나 존재한다는 뜻까지 담을 수 있었죠. 다들 순간 ‘이거다’ 했습니다.”(이주필 팀장)

해커톤의 초기버전에서 현재 외부 배포되는 제품으로 발전한 버전의 AIR로 위험성평가서가 작성된 화면. <출처: (주)GS>

AI가 100을 내놓자 논쟁이 시작됐다

살아남는 데 필요한 것은 잘 작동하는 제품만이 아니었습니다. 이 도구가 현장에서 어떻게 쓰여야 하는지를 두고, 해커톤 이후 고도화 과정에서 팀 내부에 열띤 논쟁이 있었습니다. AI가 만든 결과를 참여자들이 다시 검토하는 절차를 넣어야 한다는 안전팀과, 편의성을 고려해 결과를 그대로 쓰자는 정비팀의 입장이 부딪혔죠.

이 대립은 AI 성능이 나빠서가 아니라 좋아서 생긴 것이었습니다.

“저희가 평소 잘하는 위험성평가를 50이라 한다면, AI는 100에 가까운 결과물을 내놓습니다. 처음에는 ‘성공했다, 이대로 적용할 수 있겠구나’ 싶었죠. 그런데 하나하나 들여다보니 우리 사업장에 맞지 않는 것들이 있었습니다. AI도 실수할 수 있으니 걸러 주는 절차가 반드시 있어야 한다고 생각했습니다.”(이주필 팀장)

AI가 틀린 말을 한다는 뜻은 아닙니다. “다 맞는 말입니다. 해야 하는 것들이고요. 다만 우리 현장에 실제로 접목할 수 있느냐의 차이인 거죠.”

개발자 관점에서 이 절차는 정석에 가깝습니다. 김원희 매니저의 설명입니다.

“AI는 현실 세계를 모릅니다. 현실의 맥락은 사람만 알 수 있으니, AI는 입력된 맥락 안에서 최대한 그럴듯하게 뽑아 주고 사람이 마지막에 검수하는 것이 거의 정석 패턴입니다. HITL(Human-in-the-loop)이라고 해서, 이런 위험한 작업에는 반드시 넣도록 되어 있습니다.”

(주)GS 52g스튜디오의 김원희 매니저 <출처: 요즘IT>

결국 ‘안전을 위해서라면 약간의 불편함도 감수하는 것이 맞다’는 데 뜻을 모았습니다. 이에 AIR에 사람이 검토하는 절차가 반영됐고, 지금도 각 단계마다 사람이 리뷰를 마쳐야 다음 단계로 넘어가는 구조가 유지되고 있습니다.

선우정 매니저는 이것이 AIR만의 원칙이 아니라고 덧붙였습니다. “AI가 100% 대체하기는 어렵다는 것이 저희 지론입니다. 항상 마지막에 사람이 있어야 한다는 기준으로 AIR도, 52g에서 만드는 다른 AI도 만들고 있습니다.”

결과물의 품질은 AI가 높였지만, 그것을 현장이 믿고 쓸 수 있는 형태로 만든 것은 쓰는 사람들의 합의였습니다.

“차라리 벌금 내자”던 곳도 쓰게 하려면

이런 과정을 거쳐 AIR는 GS파워 내부에서 위험성평가에 활용하는 도구가 됐습니다. 하지만 내부 도구에만 멈추지 않았습니다. 2025년 6월, 현장 점검을 나온 고용노동부 감독관이 AIR를 보고 외부 배포를 제안했습니다.

GS파워가 컨설팅하던 민간 업체 한 곳에 무상으로 배포한 것이 시작이었고, 이 사례가 공정안전관리 우수사례로 뽑혀 고용노동부 장관상을 받으면서 GS그룹 차원의 사회공헌 활동으로 확대됐죠.

여기서부터 52g 스튜디오가 전면에 나섭니다. 내부에서 쓰던 도구를 외부에서도 쓸 수 있을 만큼 제품화하는 것이 과제였죠.

“당시 MISO로 만들어진 형태는 GS파워 현장에 맞춰진 것이라, 다른 회사가 쓰기에 적합한 형태는 아니었습니다. 그래서 브랜딩과 웹사이트 디자인, 외부 회사가 쓸 수 있는 형식까지 52g 스튜디오가 이관받아 배포하게 된 거예요.”(심재혁 매니저)

현장 전문가는 현장으로 돌아가고, 제품은 제품 만드는 사람들이 이어받은 것입니다.

52g 스튜디오가 AIR를 맡으며 가장 크게 바꾼 것은 UX였습니다. 김원희 매니저는 그 이유를 사용자에서 찾았습니다.

“가장 많이 신경 쓴 건 UX입니다. 무상 배포 대상인 영세 사업장까지 고려해 ‘누구나’ 쉽게 쓸 수 있는 제품이 되어야 했어요. 그러려면 단계 하나하나마다 어려움 없이 쓸 수 있어야 했죠. 60대 이상 사용자가 쓴다 생각하고 UX를 하나하나 쪼개서 기획했습니다.”

그는 “정부 문서에는 ‘해야 한다’는 지침만 있을 뿐 세부적인 가이드가 없어요. 그래서 영세한 곳에서는 실제로 ‘차라리 벌금을 내자’며 실행을 하지 않는 곳도 있습니다.”라며 현장 분위기를 전했습니다.

AIR 첫 화면. 52g는 반복적인 UT를 통해 고령의 이용자도 쉽게 쓸 수 있도록 글자 크기를 키우고 네비게이터를 삽입하는 등 UX에 특히 집중했다고 밝혔다. <출처: (주)GS>

방향을 잡아 준 것은 사용자 테스트였습니다. 52g 스튜디오는 고용노동부 소속 중대산업사고예방센터(중방센터)와 협업해 실제 안전 관리자들을 불러 UT(user test)를 반복했습니다. 작아서 안 보이는 글씨, 지나치기 쉬운 입력 안내 등 크고 작은 문제를 하나씩 잡아 고쳤고, 회사마다 제각각인 위험 등급 체계는 프리셋 몇 개로 대응하는 대신 아예 처음부터 조립해 쓸 수 있게 다시 만들었습니다.

선우정 매니저는 이렇게 다듬어진 AIR를 사용하던 한 사업장의 풍경을 기억합니다.

“인터뷰를 하러 간 소규모 사업장이 있었습니다. 직원이 12명이고 안전 조직이 따로 없어서, 그중 한 명이 이 일을 맡고 있었어요. 새로 오신 분이라 위험성평가를 작성해 본 경험이 전혀 없는데 해야 하는 상황이었죠. 그런데 AIR로 기본적인 작업을 할 수 있게 되고, 열두 명이 모니터 앞에 모여 그 결과물을 보면서 의견을 나눌 수 있었어요.”(선우정 매니저)

심재혁 매니저는 AIR가 작은 사업장에 준 가치에 대해 이렇게 설명했습니다. “위험성평가서 작성 경험이 적은 회사들은 기존에는 법적 기준만 맞추어, 무슨 보호구인지 모른 채 ‘보호구를 착용해야 합니다’라고 적는 식이었습니다. AIR는 작성 단계에서 어떤 보호구를 어디서 어떻게 착용해야 하는지 세부 정보까지 제안합니다.” 사용자 중 한 사람은 AIR를 “사막의 오아시스 같다”고 표현했다고도 합니다.

(주)GS 52g스튜디오의 심재혁 매니저 <출처: 요즘IT>

이렇게 52g 스튜디오의 손을 거쳐 내부 툴에서 외부 솔루션으로 완성된 AIR는 2026년 2월 27일부터 중방센터를 통해 100인 이하 소규모 사업장에 정식으로 무상 배포되기 시작했습니다. 사용 중인 회사는 292곳(2026년 7월 29일 기준)까지 늘었고, 도입 전 약 1시간이던 위험성평가 작성 시간은 약 5분으로 줄었습니다.

사회공헌 대상이 아닌데도 쓰고 싶다는 요청이 이어져 소정의 구독료를 받는 유상 제공이 최근 시작됐지만, 52g는 유료 이용자를 늘리겠다는 목표가 있다기보다 “무상 배포의 가치를 높이는 사회공헌 활동에 집중해 무상과 유상의 기준을 나눈 것”이라고 설명했습니다.

아이디어를 제품으로 옮기는 52g의 프로세스

GS에서 그간 다섯 번의 해커톤을 진행하며 선보인 수많은 프로토타입 중 외부 제품화까지 성공한 것은 AIR가 첫번째입니다. 그러나 이것은 우연한 성공이라기보다, 52g가 의도적으로 다듬어 온 프로세스 위에서 나온 결과물입니다.

그 프로세스의 출발은 기술이 아니라 문제 정의입니다.

“저희가 가장 주안점을 두는 건 문제 정의입니다. AI 시대에 대부분의 문제는 AI가 풀 수 있어요. 그런데 AI 생성물이 너무 많아지면 쓸모없는 결과물만 쌓이죠. 그래서 진짜 중요한 문제를 푸는 게 더 중요해요. AIR가 잘된 것도 현업이 진짜 문제라고 생각한 것이었기 때문입니다. 현업이 그 문제 정의를 잘하게 하는 것이 저희가 집중하는 일이고요.”(선우정 매니저)

(주)GS 52g스튜디오의 선우정 매니저 <출처: 요즘IT>

이처럼 문제 정의를 중요하게 생각하기 때문에, 계열사의 ‘52g 크루’가 현업과 함께 진짜 문제를 찾고 정의합니다. 현업이 현장에서 풀어야 할 진짜 문제를 찾으면, 업무 전체의 여정을 톺아보고, 업무 단위를 쪼개봅니다. 리서치도 진행합니다. 이 과정을 각사의 52g 크루가 돕습니다.

“처음부터 업무를 구조화하하는 것은 어렵습니다. 늘 하는 일이라 무엇이 중요하고 중요하지 않은지 가려내기가 어렵거든요. 그래서 인터뷰를 아주 깊게 합니다.”(선우정 매니저)

이러한 과정을 통해 진짜 문제가 무엇인지 정의합니다. 전체적인 워크플로우를 그려 놓고 필요한 데이터, 사람의 판단이 필요한 구간, AI에 위임할 구간을 정합니다. 선우정 매니저는 이를 요리에 빗댔습니다. “일종의 ‘현장형 레시피’ 기법입니다. 요리할 음식이 정해지면, 요리사가 직접 투입돼야 할 자리와 AI라는 주방 도구가 투입될 자리를 비율로 나눈 다음, 그 레시피를 보고 프로덕트를 만듭니다. 그리고 가장 중요한 판단은 언제나 요리사, 즉 사람이 하는 거죠.” 300~400명이 참가하는 해커톤에서는 이 과정의 축약판으로 코칭이 이뤄지는데, AIR 팀은 현장에서 문제를 정의해 해커톤에 들고 온 경우였습니다.

왼쪽부터 (주)GS 52g스튜디오의 심재혁 매니저, 선우정 매니저, 김원희 매니저. (주)GS 52g스튜디오에서는 인터뷰를 통해 전체적인 워크플로우를, 포스트잇을 활용해 한눈에 보이도록 펼쳐놓고 필요한 데이터, 사람의 판단이 필요한 구간, AI에 위임할 구간을 정하며 진짜 문제를 정의한다.

해커톤이 끝난 뒤에도 52g의 문제 해결은 계속됩니다. 선우정 매니저는 “모델이 충분히 발전하지 않았던 초반에 52g가 겪은 고민은 해커톤에서 나온 아이디어가 아이디어로만 끝난다는 것"이었다며, " 3회차부터 현실화에 힘을 쏟았다”고 말했습니다.

또 AIR처럼 외부에서도 사용할 수 있는 정식 제품은 만들어진 뒤에도 유지보수가 중요합니다. 52g 스튜디오가 이를 전담해 AIR가 프로토타입에 그치지 않을 수 있었습니다. “AIR의 상용화는 저희 스튜디오가 맡았고, 현업의 의견을 듣고 서비스에 반영하며 다시 현장에서 활용되는 선순환을 만들었어요.” (선우정 매니저)

현장에서 변화를 시도하며 문제를 발굴하는 문화부터 해커톤과 제품화까지. 아이디어가 각 단계에서 사라지지 않도록 받쳐 주는 구조가 있었던 것입니다. 그리고 이 구조는 조직의 공기도 바꿨습니다.

“처음에는 바텀업, 즉 현업이 스스로 AI를 활용해 자기의 문제를 푸는 것만 생각했어요. 그런데 다양한 활동으로 리더들의 생각도 함께 바뀌면서, 탑다운의 과제도 이뤄지니 두 가지가 조화되어 선순환이 일어났습니다.”(이주필 팀장)

AIR의 다음, 만든 사람들의 다음

AIR의 다음 단계는 범위 확장입니다. 심재혁 매니저는 “안전 프로세스에서 위험성평가는 일부분”이라며, 최근 다음 단계인 작업 전 회의(TBM)까지 커버했고 “결국 AIR는 전반적인 산업 안전 프로세스를 모두 커버하는 시스템이 되어야 한다”고 했습니다.

김원희 매니저는 조금 더 멀리 내다봤습니다. “사용자에게 가치를 전달하는 건 정말 어렵습니다. 만드는 사람 입장에서는 서비스를 만들어 무료로 뿌려도 누군가 써 준다는 건 거의 기적이에요. 그런데 AIR는 돈을 내고도 쓰겠다는 고객사가 한두 군데씩 나오고 있습니다. 저는 AIR가 대한민국 안전의 표준이 됐으면 합니다.”

마지막으로 17년 동안 에너지 업계에서 일한 이주필 팀장에게 소회를 물었습니다.

“만감이 교차합니다. 작은 아이디어였고 작은 도전이었습니다. 그것이 나의 필요가 되고, 회사의 필요가 되고, 또 다른 사업장의 필요가 되면서 상품화까지 됐으니까요. 아이디어에서 끝나는 경우가 굉장히 많고 이것도 거기서 끝날 수 있었는데, 중간에 사명과 열정을 가진 누군가가 있어야 한다고 생각합니다.”(이주필 팀장)

AIR의 2년을 따라가 보면, 좋은 아이디어가 살아남는 데 필요한 조건이 보입니다. 문제를 가장 잘 아는 사람이 문제를 정의했고, 코딩을 못 해도 만들어 볼 수 있는 도구와 코치가 있었고, 만든 사람이 현장으로 돌아간 뒤에도 제품을 이어받아 끝까지 다듬는 사람들이 있었습니다. 어느 하나라도 없었다면 AIR 역시 해커톤과 함께 사라진 수많은 프로토타입 중 하나로 남았을 것입니다.

그리고 이 이야기의 끝에는 스타트업의 성공 문법과는 다른 그림이 있습니다. 생존을 위해 시장성 있는 문제와 돈이 되는 사용자를 골라야 하는 스타트업과 달리, GS는 시장성보다 현장의 필요를 기준으로 현업이 정의한 문제를 골랐고, 그 답을 디지털에 익숙하지 않은 사람까지 쓸 수 있게 다듬었으며, 이를 경쟁이 아니라 사회공헌으로 풀었습니다. 직원 열두 명이 모니터 앞에 모여 앉은 그 작은 사업장의 풍경은, 대기업의 AX가 어떤 가치를 줄 수 있는지를 보여주는 하나의 답일 것입니다.

]]>

충원이 거절되자 "이거 한번 해보자"로 시작한 자동화

인력 대신 도구를 붙잡은 사업관리의 3달

앞서 두 편의 글 ‘비개발자가 400페이지 서명 검사를 자동화하며 고민한 것’, ‘자동화할 일을 고르는 것도 실력이다’에서 나는 도구에 관한 이야기를 했다. 첫 번째 글은 400페이지짜리 점검철의 서명 검사를 자동화한 제작기였고, 두 번째 글은 넉 달 동안 만든 열두 개를 놓고, 무엇을 자동화하고 무엇은 하지 않았는지에 대한 기준이었다. 어떻게 만들었나, 그리고 무엇을 고를까. 두 편 모두 도구가 주인공이었다.

이번 글은 그보다 더 앞의 이야기다. 도구가 아니라 사람 이야기이고, 정확히는 “내가 왜 그 자리까지 몰렸는가”에 대한 기록이다. 코딩이 본업이 아닌 사업관리 담당자가 어느 날 갑자기 자동화에 관심이 생겨서 시작한 게 아니었다. 정확히 말하자면 나는 떠밀렸다. 그래서 이 이야기의 대상은 분명하다. 지금 반복 업무에 짓눌려 있으면서도, “나는 코딩을 못 하니까”라며 미뤄 두고 있는 분들이다.

이미 도구를 만드는 법이나 고르는 법을 알려 주는 글은 많다. 그런데 정작 그 앞에 있는 질문, 어쩌다 거기까지 갔는가를 솔직하게 적은 글은 드물다. 그 자리에 서 본 사람만 쓸 수 있는 이야기라고 생각해서, 이번 글에서 풀어보고자 한다.

업무가 두 배가 된 해

작년까지 우리 팀은 인프라 운영 사업만 수행했다. 시스템이 멈추지 않게 지키고, 장애가 나면 복구하고, 월마다 운영 실적을 정리해 보고하는 일이다. 익숙했고, 리듬이 있었다.

올해는 여기에 유지관리 사업이 더해졌다. 운영을 계속하면서 유지관리까지 병행하게 된 것이다. 나만 그런 게 아니었다. 팀원 전체가 기존 운영 업무에 더해 유지관리까지 맡게 됐다. 사람은 그대로인데 사업이 하나 더 늘었으니, 늘어난 몫은 고스란히 각자에게 나뉘었다.

운영 사업만 하던 해에서 운영과 유지관리를 함께 맡은 해로, 업무 구조가 어떻게 바뀌었는지 정리한 도식 <출처: 작가, 클로드로 생성>

숫자로 딱 떨어지게 말하긴 어렵지만, 체감으로는 해야 할 일이 몇 배로 늘었다. 더 정확히 표현하자면 일의 양보다 일의 종류가 늘어난 것이 힘들었다. 하던 일을 더 많이 하는 것과, 안 해 본 일이 새로 들어오는 것은 완전히 다른 피로다.

처음 하는 일에는 체계부터 없었다

유지관리 업무는 나에게 처음이었다. 그리고 처음 하는 일에는 늘 같은 문제가 따라온다. 할 일이 어려운 게 아니라, 할 일을 담을 그릇이 없다는 것.

표준이 없는 상태에서 시작하기

유지관리에 필요한 산출물 표준이 정립되어 있지 않았다. 어떤 문서를 어떤 형식으로 받아야 하는지부터 정해야 했다. 그래서 표준 양식을 만들어 유지관리 업체 전체에 미리 배포했다.

그런데도 매달 같은 오류가 반복됐다. 배포한 양식이 현장 점검자에게까지 제대로 전달되지 않은 듯했다. 반복되는 유형은 대체로 정해져 있었다.

작년 양식을 그대로 가져와 작성한 경우
점검은 했는데 작업자 서명이 빠진 경우
특이사항을 모호하게 적은 경우

마지막 유형이 특히 손이 많이 갔다. “추후 조치예정”이라고만 적혀 있으면 그건 아무것도 정해지지 않았다는 뜻이다. 그래서 “2주 내 조치예정”처럼 정확한 완료일자를 명기하도록 매번 되돌려 보냈다. 점검이 끝난 일지를 최종적으로 확인하는 일은 생각보다 큰 부담이었다.

1) 흐름을 끊는 병목, 파일 반출입

체계를 잡는 것과는 결이 다른 문제도 있었다. 보안상 파일 반출입은 사업단과 고객 사이의 단일 경로로만 처리해야 했다. 다시 말해 그 창구가 나였다. 문제는 요청이 예고 없이 온다는 점이었다. 내 일을 하고 있는 중간에 반출입 요청이 들어오면 하던 작업을 멈추고 처리해야 했다. 한 건 한 건은 몇 분이면 끝난다. 그런데 끊긴 흐름을 다시 잇는 비용은 그 몇 분보다 훨씬 컸다. 이 손실이 하루 종일 쌓였다.

이 문제는 결국 구조를 바꿔서 풀었다. 내부 프로젝트 관리 시스템에 있는 게시판 기능에 반출입 요청 창구를 만들고, 요청이 나를 거치지 않고 고객에게 바로 가도록 흐름을 다시 짰다.

반입부터 보겠다. 외부에서 온 메일을 담당 고객에게 보내 두고, 요청자가 내부 시스템에 해당 건의 반입을 직접 요청한다. 반출도 같은 방식이다. 요청 글을 내부 시스템에 올려 두면 고객이 확인하고 외부로 반출해 준다.

바뀐 것은 처리 건수가 아니라 경로였다. 예전에는 모든 요청이 나를 한 번 거쳐야 다음으로 넘어갔다. 지금은 요청자와 고객이 시스템 위에서 직접 주고받고, 나는 그 기록을 확인하면 된다. 내 하루를 끊던 지점이 사라진 것이다. 이 경험이 나중에 자동화를 생각할 때 기준이 되기도 했다. 일을 더 빨리 하는 것보다, 나를 거치지 않아도 되게 만드는 편이 낫다.

2) 결국 내가 만든 관리 흐름

그래서 점검 관리 흐름을 직접 만들었다. 순서는 단순하다. 팀원이 점검 일정을 잡으면, 작업일정계획표를 보고 엑셀에 번호를 매겨 업체와 담당 파트, 작업자 정보를 정리한다. 한 달 치 계획이 끝나면 작업일지를 고객에게 전달해 전체 검토와 서명을 받고, 그것을 스캔해 검수 문서로 보고한 뒤 업체별로 스캔본을 다시 전달한다.

돌아보면 이 흐름 자체가 대단히 어려운 일은 아니었다. 정리하고 나면 순서대로 하면 되는 일이다. 문제는 따로 있었다. 하나씩 하면 어렵지 않은 일도, 한꺼번에 몰리면 사람이 무너진다.

석 달, 퇴근 후에야 일이 시작됐다

그 시기를 한 문장으로 말하면 이렇다. 낮에는 내 일을 하지 못했다. 일이 복합적으로 몰리다 보니 집중이 흩어졌다. 게다가 여러 곳에서 동시에 나를 찾았다. 반출입 요청, 업체 문의, 팀원 확인, 고객 요청이 순서를 지키지 않고 들어왔다. 하나에 손을 대면 다른 하나가 밀렸다.

그래서 나는 퇴근 시간이 지나기를 기다리게 됐다. 사람들이 빠지고 연락이 잦아들면, 그제야 자리에 앉아 그날 처리했어야 할 일들을 하나씩 쳐냈다. 조용한 사무실에서 혼자 노트북을 보고 있는 시간이 하루 중 유일하게 일이 되는 시간이었다.

그렇게 약 석 달을 버텼다. 버틴다는 말이 정확하다. 그때 나는 문제를 해결하고 있던 게 아니라 견디고 있었다. 매일 밀린 것을 따라잡을 뿐, 구조는 그대로였다. 다음 달에도 같은 일이 같은 방식으로 돌아올 것을 알면서 견뎠다.

사람을 요청했지만, 받아들여지지 않았다

석 달쯤 지나 나는 결론을 냈다. 이건 개인의 노력으로 메울 문제가 아니라고 판단했다. 그래서 업무보조 한 명을 충원해 달라고 요청했다. 가장 상식적인 해법이라고 생각했다. 일이 늘었으면 사람이 늘어야 한다. 그런데 요청은 받아들여지지 않았다. 솔직히 말하면 그때 좌절했다. 방법을 몰라서가 아니라, 방법을 알고 있는데 그 방법을 쓸 수 없다는 사실이 사람을 지치게 만든다. 사람이 안 되면 남는 선택지는 하나뿐이었다. 일하는 방식 자체를 바꾸는 것. 다만 그때는 그게 무엇인지 몰랐다.

“이거 한번 해보자”

그 무렵 본사 행사에 참석했는데, 거기서 클로드를 활용한 자동화 시연을 보게 됐다. 지금 돌아봐도 신기한 건, 그 시연이 대단히 어려운 기술을 보여주지는 않았다는 점이다. 그런데 화면을 보는 순간 머릿속에 든 생각은 분명했다. 이거다.

그 자리에는 사업관리 후배 직원이 함께 있었다. 우리는 시연을 보면서 서로에게 말했다. “이거 한번 해보자.”라는 문장이 이 글의 제목에 들어간 이유가 있다. 나중에 도구를 열두 개까지 만들게 되지만, 그 출발점은 대단한 결심이나 계획이 아니었다. 옆자리 동료와 나눈 한마디였다. 시작이 혼자가 아니었다는 것이 지금 생각해도 큰 차이를 만들었다.

명령어 한 줄, 그리고 첫 화면

돌아와서 실제로 설치를 해 봤다. 여기서부터는 비개발자가 어떻게 첫발을 뗐는지에 대한 이야기라, 따라 해 보실 분들을 위해 최대한 그대로 적는다.

나는 먼저 다른 인공지능에게 설치 방법을 물었다. 평소 쓰던 생성형 인공지능 서비스에 “클로드 코드 설치 방법 알려줘”라고 입력했더니, 운영체제별로 명령어 한 줄씩을 정리해 알려 줬다. 별도의 개발 환경을 갖출 필요 없이 명령 프롬프트에 그 명령어를 복사해 붙여넣기만 하면 되는 방식이었다.

그래서 그대로 했다. 복사하고, 붙여넣고, 실행했다. 설치는 몇 분 만에 끝났다.

다른 인공지능에게 설치 방법을 물었을 때 받은 안내 화면. 명령어 한 줄을 복사해 붙여넣는 방식이었다. <출처: 작가, 화면 캡처>

실행하자 화면에 인사말이 떴다. “조차장님, 안녕하세요.”

별것 아닌 문구인데, 그게 제일 먼저 눈에 들어왔다. 도구를 켰다기보다 누군가에게 말을 건 것 같은 기분이었다. 그리고 화면 자체가 낯설지 않았다. 평소 쓰던 인공지능 서비스와 크게 다르지 않은 구성이라, 무엇을 어디에 입력해야 하는지 헤매지 않았다. 비개발자에게는 이 ‘낯설지 않음’이 생각보다 중요하다. 진입 장벽은 대체로 기능이 아니라 낯설다는 느낌에서 생기기 때문이다.

이후에는 유튜브를 찾아봤다. 처음 설정할 때 알아두면 좋은 것들, 이렇게 쓰면 편하다는 사용법을 영상으로 보면서 하나씩 따라 했다. 배우는 방식도 특별할 게 없었다. 남들이 해 둔 것을 보고 그대로 해 보는 것부터였다.

자신감은 결과물이 아니라 과정에서 왔다

첫 결과물이 완성됐을 때의 기분은 기억에 남는다. 그동안 머릿속으로 고민만 하다가 끝났던 것들이 눈앞에 형태로 보이기 시작했다. 그러자 뭔지 모를 자신감이 생겼다. 이걸 할 수 있으면 저것도 되겠다는 생각이 자연스럽게 따라왔다. 그런데 시간이 지나고 나서 돌아보니, 나를 바꾼 건 결과물 자체가 아니었다.

정말 좋았던 것은 거기까지 가는 과정이었다. 무엇보다 대화하듯 주고받으며 만들었다. 내가 문제와 제약을 설명하면 방법을 제안받고, 실제로 돌려 본 뒤 왜 안 됐는지를 다시 설명하는 식이었다. 지시하고 받는 게 아니라 오가는 흐름이었다.

내가 생각하지 못한 선택지를 제안받은 것도 컸다. 나는 아는 만큼만 질문할 수 있는데, 답이 내가 아는 범위 밖에서 오는 경우가 많았다. 혼자 고민했다면 떠올리지 못했을 방향이었다. 그리고 그 선택지에 나오는 용어가 어려워서 다시 물으면 비유를 들어 쉽게 풀어 줬다. 이게 비개발자에게는 결정적이다. 모르는 단어 앞에서 멈추지 않아도 된다는 것, 물어봐도 창피하지 않다는 것. 나는 이 지점에서 계속할 수 있겠다고 느꼈다.

자신감은 완성된 결과물이 아니라, 대화하는 과정에서 왔다. 결과물은 증거였을 뿐이다.

마치며: 자동화는 여유가 아니라 한계에서 시작된다

이 글을 쓰면서 다시 확인한 것이 있다. 나는 자동화에 관심이 많아서 시작한 사람이 아니다. 더 이상 버틸 수 없어서 시작했다. 업무가 두 배가 됐고, 체계는 없었고, 사람은 늘지 않았다. 남은 선택지가 그것뿐이었다.

그래서 혹시 지금 비슷한 자리에 계신 분이 있다면, 시작의 조건을 오해하지 않으셨으면 한다. 여유가 생기면 배워서 해 보겠다고 미루기 쉬운데, 내 경우는 정반대였다. 여유가 없었기 때문에 시작했다. 그리고 그 시작은 거창하지 않았다. 시연 하나를 보고 옆자리 동료와 “이거 한번 해보자”고 말한 것, 명령어 한 줄을 복사해 붙여넣은 것이 전부였다.

그때의 나에게 지금 한마디를 건넬 수 있다면 이렇게 말하고 싶다. 이 또한 지나갈 것이고, 언젠가는 너의 자산이 될 거라고. 실제로 그 석 달은 지금 이 글의 재료가 됐다. 지금 반복 업무에 눌려 있다면, 완벽한 준비를 기다리지 않으셔도 된다. 가장 귀찮은 일 하나를 떠올리고, 옆자리 동료에게 한 번 말해 보시면 좋겠다. “이거 한번 해보자.” 나도 딱 그 한마디에서 시작했다.

이 글이 마음에 드셨다면, 작가 페이지에서 알림 설정과 좋아요를 부탁드립니다.

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

]]>

아니요, 로컬 모델이 승리하진 않을 겁니다

이 글은 요즘IT가 AI의 도움을 받아, 션 고데크(Sean Goedecke)의 글 <No, local models will not win>를 번역한 글입니다. 필자는 GitHub의 스태프 소프트웨어 엔지니어(Staff Software Engineer)로, GitHub Copilot 관련 개발을 담당하고 있습니다. 수학 학사와 도덕철학 석사라는 이색적인 배경을 지닌 엔지니어로, Zendesk를 거쳐 2021년 GitHub에 합류했으며, 소프트웨어 엔지니어링과 대기업 조직의 역학을 주제로 한 인기 블로그를 운영하고 있습니다.

이 글은 새로운 오픈웨이트(Open Weights) 모델이 나올 때마다 반복되는 “로컬 모델이 결국 미래다”라는 주장에 정면으로 반박합니다. 필자는 로컬 모델이 아무리 강해져도 대부분의 추론(inference)은 결국 AI 데이터센터에서 이뤄질 것이라고 단언하며, 그 근거로 성능 격차, 비용·효율 구조, 배칭(batching)의 경제학을 차례로 짚습니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

새로운 오픈 웨이트(Open Weights), 모델의 가중치를 공개한 형태) AI 모델이 출시될 때마다 사람들은 “로컬 모델이 미래”라고 말합니다. 모두가 노트북이나 휴대폰에서 AI 모델을 실행할 수 있게 된다면, 굳이 수십억 달러를 들여 데이터센터를 구축할 필요가 있겠느냐는 것이죠. 하지만 저는 이런 생각이 결국 실패할 것이라고 봅니다. 오픈 웨이트 모델이 아무리 강력해지더라도 대부분의 AI 작업은 결국 데이터센터에서 이루어질 것입니다.

로컬 모델은 널리 쓰이기에는 너무 약합니다

로컬 모델*은 최첨단 모델만큼 강력해지기 어려울 겁니다. 이 점은 분명하다고 생각합니다. 현재 존재하는 모든 최첨단 모델은 폐쇄형이든, 오픈 웨이트든 데이터센터의 GPU 클러스터가 아니면, 실행하기에 너무 큽니다. 물론 시간이 지나면서 더 작은 모델도 점점 똑똑해질 겁니다. 1년 뒤에는 지금의 GPT-5.6-Sol 정도의 성능을 내는 모델을 노트북에서 실행할 수 있을지도 모릅니다. 하지만 그때가 되면 여러분은 GPT-5.6-Sol 정도의 성능을 더 이상 유용하다고 생각하지 않을 겁니다.

*로컬 모델: 클라우드 서버 대신 내 개인 컴퓨터나 온프레미스 장비에서 직접 실행하는 인공지능 대형 언어 모델

많은 사람이 이 마지막 부분을 부정하지만, 저는 실제로 그렇다고 생각합니다. 사람들은 결국 자신이 지불할 수 있는 범위에서 가장 강력한 모델을 선택합니다. 만약 AI의 발전이 GPT-4에서 멈췄다면, GPT-4를 기반으로 아주 강력한 도구들을 만들 수 있었을 겁니다. 하지만 지금 누가 GPT-4를 쓰고 싶어 할까요?

LLM(대규모 언어 모델)이 더 강력해질수록 우리의 기대 수준도 함께 높아졌습니다. 이제 우리는 에이전트 시스템이 점점 더 많은 문제를 스스로 해결하기를 기대합니다. AI가 혼란스러워하거나 작업을 중단하면 굉장히 답답하게 느껴지죠. 선택권이 있다면 사람들은 자신을 덜 답답하게 만드는 모델을 선택할 겁니다. 그리고 그 모델은 결국 더 크고 강력한 모델일 가능성이 높습니다.

로컬 모델은 더 비싸고 비효율적입니다

게다가 같은 모델을 실행한다면 데이터센터가 항상 더 저렴할 겁니다. 사람들이 왜 계속 로컬 모델이 저렴하다고 말하는지 저는 이해하기 어렵습니다. 마치 우버를 운전하는 것이 ‘공짜 돈’이라고 말하는 것과 비슷한 실수라고 생각합니다. 자동차의 연료비와 유지·감가 비용을 무시하고 있기 때문이죠.

집에서 저사양 GPU 서버를 구축하는 데 드는 초기 비용만 생각해도, AI 서비스 몇 가지를 유료 구독하는 데 몇 년은 쓸 수 있는 금액입니다. 전력 비용까지 고려하면, AI를 얼마나 많이 사용하는지에 따라 한 달에 약 50~300달러가 들어갑니다. 역시 유료 AI 서비스 몇 개를 더 구독할 수 있는 돈입니다.

그렇다면 왜 데이터센터에서 실행하는 모델이 더 저렴할까요? 데이터센터의 AI 작업 비용이 보조금을 받아서 그런 것이 아닙니다. 실제로 AI 추론(inference, AI가 입력을 받아 결과를 생성하는 과정)은 상당히 저렴한 편입니다. 같은 모델을 로컬과 데이터센터에서 실행한다고 가정하면, 데이터센터에서 실행하는 쪽이 구조적으로 훨씬 효율적입니다.

가장 큰 이유는 배칭(batching, 여러 사용자의 요청을 묶어서 한꺼번에 처리하는 방식)입니다.

GPU는 수십만 개의 수학 연산을 한 번에 처리할 때나, 하나의 연산을 처리할 때나 거의 비슷한 시간 안에 처리할 수 있습니다. 하지만 한 사용자가 AI를 사용할 때는 이전에 생성한 토큰(token, AI가 텍스트를 생성할 때 사용하는 기본 단위)의 결과가 다음 토큰을 생성하는 데 필요하기 때문에, 한 사용자의 요청을 여러 개로 묶어 처리하기는 어렵습니다.

반면 수백 명의 사용자가 동시에 AI를 사용한다면 이들의 작업을 함께 묶어 처리할 수 있습니다. 수백 명의 요청을 한꺼번에 처리해도, 사용자 한 명의 요청을 처리할 때와 비교해 필요한 시간이나 전력 소비가 크게 늘어나지 않습니다.

집에서 직접 AI를 실행하면 이런 식으로 묶을 사용자가 없습니다. 많아야 몇 개의 AI 에이전트를 동시에 실행하는 정도죠. 결국 GPU 활용률이 매우 낮아집니다. 비용을 지불하고 있지만 실제로 사용하지 못하고 버려지는 처리 능력이 상당한 것입니다.

이를 해결하는 유일한 방법은 친구들과 함께 로컬에서 실행하는 AI 서버를 공유하는 것입니다. 그런데 그렇게 되면 사실상 형편없는 자체 데이터센터를 운영하는 것과 크게 다르지 않습니다.

또 다른 이유는 데이터센터가 더 크고 효율적인 GPU를 사용할 수 있다는 점입니다.

로컬 모델을 돌릴 때 사용하는 GPU는 RTX 4090 같은 게이밍 GPU인 경우가 많습니다. 반면 AI 작업을 위해 설계된 데이터센터용 B200은 같은 전력량으로 약 3배의 연산 성능과 거의 4배에 달하는 메모리 대역폭(memory bandwidth, GPU가 메모리에 데이터를 읽고 쓰는 속도)을 제공합니다.

배칭과 GPU 효율을 모두 고려하면, 같은 모델을 로컬에서 실행하는 데 필요한 자원은 데이터센터보다 대략 30배 더 많다고 볼 수 있습니다.

그래서 저는 ‘로컬 모델이 데이터센터의 거대한 자원을 사용하지 않아 친환경적이다’라는 주장에도 의문이 듭니다. LLM을 효율적으로 실행하고 싶다면 오히려 가능한 한 많은 AI 작업을 데이터센터로 보내야 합니다.

물론 이 사람들이 말하고 싶은 것은, 자원 사용량이 적은 더 작은 모델을 사용해야 한다는 것일 수도 있습니다. 하지만 그렇다고 해도 직접 작은 모델을 운영하기보다는, 예를 들어 GPT-5.6 Luna API처럼 작은 모델을 제공하는 API를 사용하는 편이 이상적입니다.

그렇다면 로컬 모델이 이길 가능성은 없을까?

그럴 가능성이 전혀 없는 것은 아닙니다.

예를 들어 정부가 AI 데이터센터의 사용 자체를 금지하는 상황이 올 수도 있습니다. AI의 위험성에 대한 우려 때문일 수도 있고, 단순히 대중의 압력에 정부가 굴복하기 때문일 수도 있습니다. 그런 세상에서는 로컬 모델이 유일한 선택지가 될 겁니다.

또는 대규모 모델의 AI 발전이 어떤 이유로 정체되고, 작은 모델만 계속 발전하는 상황이 올 수도 있습니다. 이런 일이 어떻게 가능한지는 잘 상상이 되지 않습니다. 정부 개입 같은 특별한 상황을 제외한다면 말이죠. 하지만 파라미터(parameter, 모델이 학습을 통해 조정하는 값)가 300억 개(30B) 정도인 모델이 최첨단 모델이 될 수 있는 세상이라면 로컬 모델도 충분히 경쟁력을 가질 수 있습니다.

혹은 모델이 너무나 강력해져서 300억 개의 파라미터를 가진 모델만으로도 모든 일을 처리할 수 있게 될 수도 있습니다. 그렇다면 리만 가설을 풀려고 하는 사람이 아닌 이상 굳이 Opus나 Sol 같은 모델을 사용할 필요가 없겠죠.

저는 이것도 별로 믿지 않습니다. 오늘날 모델은 이미 최첨단 수준의 수학 문제를 풀 수 있습니다. 그런데도 대규모 코드베이스를 리팩터링(refactoring, 기존 코드를 유지·보수하기 쉽게 개선하는 작업)하는 일은 저만큼 잘하지 못합니다. 그렇다면 모든 작업에서 가장 똑똑한 모델을 사용하고 싶지 않은 세상이 어떻게 올 수 있을지 상상하기 어렵습니다.

그렇다고 로컬 모델이 쓸모없는 것은 아닙니다

저는 로컬 모델이 앞으로도 분명 틈새 시장을 차지할 것이라고 생각합니다.

Thinking Machines가 제안한 ‘Interaction Models’의 놀라울 정도로 단순한 아이디어가 떠오릅니다. OpenAI도 비슷한 방식을 사용합니다. 핵심은 음성 대화처럼 지연 시간에 민감한 애플리케이션에서는 작고 빠른 모델이 대화를 담당하고, 어려운 사고가 필요한 경우 더 크고 느린 모델에 작업을 넘기는 것입니다.

5년 뒤에는 대부분의 AI 사용이 휴대폰이나 노트북의 로컬 모델을 통해 이루어질 수도 있다고 생각합니다. 다만 그런 세상이 오더라도 실제 작업의 대부분은 여전히 AI 데이터센터에서 처리될 것입니다.

물론 더 약하고 더 비싸더라도 로컬 모델을 선호하는 사용자도 있을 겁니다. 예를 들어, 모델을 로컬에서 직접 제어할 수 있다는 점이 일부 사용자에게는 결정적인 장점이 될 수 있습니다. 어떤 사람들은 자신의 인프라를 완전히 통제할 수 있다는 점을 중요하게 생각할 수도 있고, 인터넷 연결이 불안정할 수도 있습니다.

이런 사람들에게, 특히 AI를 대화하는 정도의 용도로만 사용한다면 로컬 모델은 좋은 선택입니다. 하지만 저는 이런 사람들이 언제까지나 소수일 것이라고 생각합니다. 대부분의 사용자는 계속해서 데이터센터를 통해 AI를 사용할 겁니다.

작가의 덧붙임:
이 글에는 Hacker News와 Lobste.rs에서 다양한 의견이 달렸습니다. 일부 댓글에서는 AI 산업이 완전히 붕괴한다면 모든 상황이 달라질 수 있다고 지적했습니다. 물론 그럴 가능성은 있습니다. 하지만 저는 AI 버블이 꺼진다고 해서 AI 제품 산업 자체가 그렇게까지 심각하게 붕괴할 것이라고는 생각하지 않습니다.

또 어떤 사람들은 사람들이 항상 더 강력한 모델을 선택할 것이라는 제 가정에 반대하며, 자신들이 직접 로컬 AI를 사용해 본 경험을 공유했습니다. 로컬 모델을 사용하는 것은 전혀 문제가 없다고 생각합니다. 다만 해커 포럼에서는 로컬 모델 사용자가 실제보다 더 많아 보일 가능성이 있다고 생각합니다.

마지막으로 일부 독자들은 제가 ‘win(승리한다)’이라는 단어를 사용한 것에 불편함을 표했습니다. 저는 꽤 일반적인 표현이라고 생각합니다. 여기서 제가 말하는 ‘승리’란 사람들이 클라우드에서 AI를 사용하는 대신 모두 로컬에서 AI를 실행하게 되는 상황을 의미합니다.

정확히 말하면 병목은 모델의 가중치(weights, 모델이 학습을 통해 갖게 된 값)를 GPU로 옮기는 과정입니다. 이 과정은 한 사용자의 토큰을 처리할 때나 100명의 사용자 토큰을 처리할 때나 수행해야 하며, 걸리는 시간도 동일합니다.
이 수치는 LLM의 도움을 받아 추정한 것이며, NVIDIA의 관련 수치와 GPU 아키텍처 자료를 통해 직접 확인할 수 있습니다.
물론 안정적인 전력 공급이 가능하고, 집에 AI용 GPU 서버를 구축할 만큼 충분한 비용을 감당할 수 있다는 전제하에서 말입니다.

*이 글은 AI를 통해 번역한 글입니다. 오역이나 어색한 표현이 있다면 댓글로 알려주시면 감사하겠습니다.

<원문>

No, local models will not win

]]>

GEO 분석 툴을 만들다: E-E-A-T 분석하는 법

언제부턴가 궁금한 게 생기면 검색창 대신 ChatGPT나 Perplexity 같은 AI부터 찾는게 일상이 됐습니다. 사용자의 검색 습관이 검색엔진에서 AI로 옮겨가면서, 기업의 시선도 자연스럽게 GEO(Generative Engine Optimization)로 이동하고 있습니다.

그런데 기업 담당자들과 이야기를 나눠보면 대부분 무엇부터 손대야 할지 잘 모르겠다고 합니다. 왜 이런 현상이 생기는지 이유는 명확합니다. 지금까지 어떤 빅테크 기업도 AI가 답변을 생성하는 방식이나, 인용 가중치 기준을 공개한 적이 없기 때문입니다. 완전한 블랙박스죠. 그러니 개선은 커녕 우리가 지금 어느 수준인지조차 알기 어려웠던 겁니다.

그래서 결국 GEO를 확인해 보기 위해 매일 아침 AI에 주요 질문을 하고, 답변 화면을 캡처해 보고서에 붙이는 일을 반복합니다. 어쩌다 우리 브랜드 링크가 한 번 인용되면 개선되고 있다고 보고하는데, 다음 날 같은 질문을 하면 또 답변에서 사라져 버립니다. 이렇게 우연히 인용된 스크린샷 한 장으로 성과를 주장하는 건 위험합니다.

“측정할 수 없으면 관리할 수 없고, 개선할 수도 없다.” — 피터 드러커(Peter Drucker)

결국 제대로 측정해 주는 도구를 찾지 못해서, 직접 만들어보기로 했습니다. 이번 글에서는 그 여정을 다뤄보겠습니다.

<출처: 작가>

GEO 분석 서비스
참고) Gemini API 키(BYOK)를 등록해 이용할 수 있습니다.
키 정보는 사용자 브라우저 로컬 스토리지에 저장됩니다.

미리 요점만 콕 집어보기

GEO(Generative Engine Optimization) 대응의 출발점은 AI의 답변 스크린샷 수집이 아니라 재현 가능한 진단 체계를 만드는 것입니다.
경험(Experience)·전문성(Expertise)·권위성(Authoritativeness)·신뢰성(Trustworthiness)을 뜻하는 E-E-A-T는 추상적인 원칙처럼 보이지만 정규식과 계산 로직으로 나누어 진단할 수 있습니다.
커머스는 구매 후기와 실사용 경험(Experience)을, 미디어는 작성자의 전문성(Expertise)을 중심에 두는 것처럼 업종별로 평가 관점을 다각화해야 비로소 의미 있는 분석이 가능해집니다.

측정할 수 없어서 관리할 수 없었던 GEO의 시작

기존 검색엔진 최적화(SEO, Search Engine Optimization)에는 순위 추적 도구가 있었습니다. 그런데 GEO에는 그에 해당하는 게 없습니다. 순위가 중요한 게 아니라 생성된 답변 안에 인용되느냐가 핵심이기 때문입니다. 측정할 마땅한 툴이 없다 보니 측정 가능한 지표를 정의하고 기준점부터 세워야 했습니다.

첫 버전은 말 그대로 단순했습니다. 웹페이지를 긁어와 AI에 통째로 넘기고 “GEO 평가해줘”라고 시켰습니다. 결과는 그럴듯했습니다. 근거도 잘 대고, 개선 제안도 날카로웠습니다.

그런데 다음 날 같은 사이트를 다시 평가해 달라고 했더니 점수가 황당할 정도로 달라졌습니다. 사이트 소스는 한 줄도 바꾸지 않았는데 말이죠. 어느 날은 “저자 정보가 없어 전문성이 낮다”며 낮게 평가하더니, 다음 날은 똑같은 페이지를 보고 “회사 소개가 충실해 전문성이 높다”고 좋게 평가했습니다.

사실 구조적인 문제가 있었던 겁니다. AI 언어 모델은 본질적으로 확률에 따라 다음 토큰을 고릅니다. temperature를 0으로 낮춰도 평가처럼 긴 추론이 필요한 작업에서는 미세한 확률 차이가 최종 평가 점수와 의견을 크게 흔듭니다.

여기에 환각(Hallucination)까지 더해지면, 아무것도 안 바꿨는데 점수만 혼자 좋아졌다 나빠졌다를 반복하는 웃긴 상황이 연출됩니다. 결국 AI의 그날 기분에 따라 달라지는 수치였던 셈입니다. 이런 건 지표가 될 수 없습니다.

그래서 원칙 하나를 세우고 다시 만들었습니다. 진단 및 수치 산출은 100% 코드가 로직 기반으로 수행한다. AI는 확정된 수집 데이터를 바탕으로 설명 서술만 맡는다.

이렇게 하면 동일한 입력에는 언제나 동일한 진단 결과가 나옵니다. 물론 “이 콘텐츠가 전문성이 있는가?” 같은 추상적 판단에는 여전히 AI를 씁니다. 다만 그 판단이 자의적으로 점수를 부여하도록 허용하지 않을 뿐입니다.

그리고 GEO 분석을 크게 두 가지 영역으로 나눴습니다. AI 봇이 사이트 정보를 손실 없이 읽고 활용할 수 있게 만드는 기술 인프라 영역, 그리고 브랜드 신뢰성과 메시지 구조를 다루는 콘텐츠 영역입니다.

전체 구조: 수집 → 병렬 분석 → 종합

먼저 전체 파이프라인의 구조입니다. 수집(Collection) → 병렬 분석(Analysis) → 종합(Synthesis)으로 이어지는 흐름으로 5개의 에이전트가 병렬로 동작합니다.

<출처: 작가>

여기서는 파이프라인 단계 자체보다, 어떤 문제를 해결하려고 이렇게 만들었는지가 더 중요합니다.

1단계, 모든 분석은 같은 시점의 원본을 봐야 한다

진단에 필요한 입력 값은 단 2개입니다. 사이트 주소(URL)와 브랜드명이죠. 이 글에서 사이트는 그 주소 아래 딸린 페이지들을, 브랜드는 그 사이트가 내세우는 이름을 가리키는데, 회사명일 수도 서비스명일 수도 특정 제품명일 수도 있고 사람들이 검색창에 그 이름으로 찾는다면 무엇이든 브랜드가 될 수 있습니다. 표현상 브랜드로 통칭해서 부르도록 하겠습니다.

사이트 URL 기반으로 직접 크롤링해야 하고 브랜드는 검색을 통해 확인해야 합니다. 분석을 위해서 소스가 되는 데이터 수집 과정은 엄격한 통일성이 필요합니다. 만약 분석 모듈이 제각각 데이터를 수집하게 두면, 시차로 인해 모듈마다 서로 다른 버전의 HTML을 참조하게 되고, 결국 같은 사이트를 두고도 평가 근거가 달라지는 오류가 발생합니다.

즉, 진단의 일관성을 보장하기 위해서는 모든 분석 과정이 반드시 동일 시점의 동일한 소스를 바라봐야 합니다. 그래서 데이터 수집은 프로세스 맨 처음 수행해 단일 스냅샷을 생성해 두고, 모든 분석 에이전트가 이 스냅샷을 기반으로 평가를 진행하도록 설계했습니다. 구체적인 수집 범위는 다음과 같이 두 가지 항목으로 나뉩니다.

<출처: 작가>

온사이트와 오프사이트를 굳이 나눠 수집하는 이유는 온사이트 내용은 브랜드 자신의 주장이고 오프사이트 기록은 그 주장에 대한 외부 검증이라 AI가 이 두 영역의 정보를 복합적으로 판단하기 때문입니다.

2단계, 영역별 분석하는 전문 에이전트를 구분한다

“GEO 분석 해주세요?”라고 단순하게 물으면 날카로운 분석 의견 대신 그럴듯하긴 한데 장황하고 막상 실무에 쓰려면 모호한 말들만 돌아옵니다. 개선할 대상이 특정되지 않기 때문이죠. 그래서 분석 영역을 나누고 특화된 각 에이전트들을 만들어 활용했습니다.

<출처: 작가>

이 평가 항목들은 일반적으로 GEO 분석 카테고리로 많이 알려진 요소들입니다. 이 컨셉을 가지고 어떻게 만들것인가는 구현의 영역입니다. 저는 각 영역은 서로의 결과를 참조하지 않고, 동시에 돌아가며 점수는 로직으로 계산합니다. 그리고 LLM은 이미 확정된 근거 목록을 받아, 사람이 이해할 수 있게 분석과 개선 가이드를 만듭니다. 그래서 LLM의 문장이 어제와 조금 달라져도 점수는 크게 달라지지 않기 때문에 일관된 평가 지표로 활용할 수 있습니다.

추가로, AI에 브랜드에 대한 연관 질문을 하고, 그 답변 중에 실제 브랜드에 대한 인용이 있는지도 실시간으로 같이 분석했습니다.

3단계, 점수 합산 다음에 나오는 우선순위

다섯 영역의 진단 결과를 합쳐 최종 GEO 점수(0~100점)를 만듭니다. 이때 영역마다 실제 AI 답변 인용에 미치는 영향력이 제각각이라, 합칠 때 반영 비율(가중치)을 따로 설정했습니다.

다만 실무에서 더 자주 쓰는 쪽은 총점이 아니라 영역 간 교차 분석에 대한 내용일 겁니다. 예를 들어 콘텐츠 수준이 아무리 좋아도 기술적 인프라 점수가 극단적으로 낮다면, 온사이트 영역을 고쳐봤자 AI 봇이 그 내용을 수집하지 못합니다. 이런 선후 관계를 따져, 어디부터 손대야 인용률이 가장 빨리 오르는가?의 개선 우선순위를 만들어 리포트에 제공합니다.

E-E-A-T 분석: 점수가 아닌 ‘관점과 시행착오’의 기록

다양한 분석 영역중에 저는 콘텐츠 분석 에이전트에 대해서 좀 더 설명을 할까 합니다. 콘텐트 영역 분석에 중요한 항목은 ‘E-E-A-T’입니다.

이 E-E-A-T는 구글 검색 품질 평가 가이드라인의 개념으로,

경험(Experience)
전문성(Expertise)
권위성(Authoritativeness)
신뢰성(Trustworthiness)을 뜻합니다.

AI 검색 엔진이 어떤 페이지를 답변 재료로 쓸지 판단할 때 참조하는 핵심 기준이기도 합니다.

문제는 이게 추상적인 개념이라는 점입니다. “전문성이 있다”는 명제를 코드는 직접 판정할 수 없습니다. 코드가 읽어낼 수 있는 건 저자 이름이 실명으로 표기돼 있다, JSON-LD에 Person 타입이 있다 같이 겉으로 드러난 정보들뿐입니다.

따라서 핵심은 어떤 관점으로 사이트를 바라보고, 어떤 요소를 통해 E-E-A-T를 입증할 것인가에 있습니다. 이 시스템을 구축하며 정의한 핵심 탐지 요소는 아래와 같습니다.

<출처: 작가>

이 관점들을 실제 코드로 옮기는 과정에서 수많은 오탐과 시행착오를 만났습니다. 그중 대표적인 6가지 이야기를 소개합니다.

첫 번째 시행착오: Experience(경험)와 Expertise(전문성)는 다르다

처음 만든 버전은 Experience(경험)와 Expertise(전문성)를 따로 구분하지 않고, 여러 평가 요소들을 한데 뭉뚱그려 합치는 단순한 방식이었습니다. 예를 들어, 저자 표기가 있으면 점수 추가, 통계가 있으면 점수 추가하는 식이었죠.

이 구조가 무너진 건 커머스 사이트를 진단하면서입니다. 상품 상세 페이지에 구매 후기가 수백 개 쌓여 있고 실사용 사진도 붙어 있는 쇼핑몰이, 저자 프로필 표기가 없다는 이유로 부당하게 낮은 평가를 받았습니다. AI 입장에서 고객들의 구체적 후기 데이터는 훌륭한 인용 재료인데 말이죠.

E-E-A-T 원문을 다시 읽고 나서야 알았습니다. Experience(경험)와 Expertise(전문성)는 결이 전혀 다른 평가 기준입니다. Experience(경험)는 자격을 요구하지 않습니다. 직접 해봤다는 증거, 원본 데이터, 구체적 사용 사례면 충분합니다. 반면 Expertise(전문성)는 자격과 이력을 봅니다. 이 둘을 한 덩어리로 뭉개면, 경험은 넘치지만 자격은 없는 사용자 제작 콘텐츠(UGC)나 커머스 상세 페이지가 구조적으로 부당한 저점을 받게 됩니다.

그래서 자격 키워드를 찾는 로직은 Expertise(전문성) 항목으로 제한하고, Experience(경험) 항목은 완전히 다른 패턴으로 데이터를 체크하도록 했습니다. 예를 들어, 아래 같은 형태로 말이죠.

// Experience(경험) — 자격을 확인하지 않는다. 원본 데이터·1인칭 서술·구체적 사례로 판단.
const CASE_STUDY_PATTERN = /\d+%|\d+개월\s*만에|\d+주\s*만에|\d+배\s*(증가|향상|성장|절감)/
const EXPERIENCE_NARRATIVE_PATTERN =
  /직접\s*(경험|사용|체험)|저희가\s*실제로|다녀와서|사용해\s*보니|실제로\s*써\s*본|다녀온\s*후기|we\s+tested|in\s+our\s*experience|hands-on/i

// Expertise(전문성) — 자격과 이력은 여기서만 본다.
const CREDENTIAL_KEYWORD_PATTERN = /대표\s|박사|자격증|경력\s*\d+\s*년|CEO|founder|certified|Ph\.?D|공인/i

이 코드는 ‘경험’과 ‘전문성’을 판단하는 기준을 분리하여, 경험 기반 콘텐츠가 전문성 부족으로 부당하게 감점되는 문제를 해결합니다.

“3개월 만에 40% 절감” 같은 표현은 자격 증명 없이도 경험을 증명합니다. “사용해 보니”, “다녀온 후기” 같은 1인칭 서술도 마찬가지입니다. 반대로 “박사”, “경력 10년”은 경험이 아니라 자격의 증거입니다. 이 구분을 코드로 명확히 구분 할 수 있어야, 평가에서도 적절하게 활용할 수 있었습니다.

또한, 외부 신뢰도를 증명하는 권위 도메인(Authoritative Domains)을 판정할 때도 한국어 콘텐츠만의 고유한 맥락을 반영해야 했습니다.

글로벌 기준의 GEO 도구들은 주로 위키백과(wikipedia.org), 네이처(nature.com), 뉴욕타임스(nytimes.com) 같은 영미권 매체나 국제기구 사이트 위주로 권위성을 체크합니다. 그러다 보니 국가통계포털(kosis.kr)이나 정부 부처 공공기관 보고서, 국내 주요 언론사를 인용한 양질의 한국어 콘텐츠가 ‘권위 있는 출처 인용 없음’으로 무참히 필터링되는 문제가 있었습니다.

이를 해결하기 위해 진단 대상이 한국 브랜드이거나 한국어 기반의 사이트일 경우에는, 국내 공공 데이터 포털, 국가 통계 사이트, 국내 주요 언론사 등 한국 환경에 최적화된 로컬 권위 매체 목록을 추가로 병합하여 교차 검증하는 동적 판단 로직을 적용했습니다. 글로벌 통용 기준만 고집하지 않고 타깃 시장의 맥락에 맞게 검증 대상을 확장한 것입니다.

두 번째 시행착오: “작성자: 관리자”라는 오탐

저자 식별 로직을 처음엔 HTML에 author, byline, 작성자, 필자 같은 문자열이 포함되어 있으면 저자가 명시된 것으로 간주했습니다.

그랬더니 국내 사이트 상당수가 이 항목에서 무더기로 통과했습니다. 워드프레스(WordPress)나 국내 콘텐츠 관리 시스템(CMS)으로 만든 블로그들이 기본값으로 ‘작성자: 관리자’를 출력하고 있었기 때문입니다. ‘작성자: 운영팀’, ‘작성자: admin’도 흔했습니다.

이건 저자가 누구인지 밝힌 것이 아니라, 사실상 저자를 밝히지 않은 것과 마찬가지입니다. 실제 값 자체가 없으면 감점 요소로 판단하면 되지만 값이 있는 경우엔 그 값이 의미 있는 정보인지 파악해야 합니다. 아래 예시 한 줄짜리 로직으로 부정확한 정보를 필터링할 수 있었습니다.

const GENERIC_AUTHOR_PATTERN = /^(관리자|운영자|운영팀|admin|administrator|staff|marketing\s*team)$/i
function hasNamedAuthorSignal(rawHtml, searchText) {
  const labelMatch = searchText.match(/(작성자|필자|저자|byline)\s*[:：]?\s*([^\n,·|]{1,20})/i)
  if (!labelMatch) return /author|byline|written by|작성자|필자|기자|저자/i.test(rawHtml)
  return !GENERIC_AUTHOR_PATTERN.test(labelMatch[2].trim())
}

이 코드는 CMS 기본값인 ‘관리자’ 등의 무의미한 저자 표기를 걸러내어, 실제 저자 정보가 없는 페이지를 정확히 식별하기 위한 로직입니다.

세 번째 시행착오: 메인 페이지만 봐서는 Expertise(전문성)를 찾을 수 없다

Expertise(전문성) 항목의 자격 키워드를 메인 페이지(홈페이지) 본문에서만 찾으려 하니 놓치는 경우가 많았습니다. 기업 대표 이력, 팀 구성원 소개, 관련 자격증은 대부분 메인 페이지가 아니라 ‘회사 소개(About)’나 ‘팀 소개’ 페이지에 위치합니다. 메인 페이지에는 브랜드 슬로건과 주요 서비스 안내 버튼만 있는 경우가 태반이기 때문입니다.

그래서 파이프라인 앞단에서 사이트맵(sitemap)을 파싱하여 정보 가치가 높은 서브 페이지를 추가로 추출한 뒤, Expertise(전문성) 진단에 한해 메인 페이지와 서브 페이지 텍스트를 합쳐서 검증하도록 개선했습니다.

다만 이 방식을 모든 진단 항목에 남발해서는 안 됩니다. 단 하나의 페이지에만 정보가 있어도 다른 저자가 작성한 정보도 모두 병합되어 오탐이 발생할 수 있습니다.

따라서 작성자의 Expertise(전문성)를 명확히 인지하게 하려면 콘텐츠 내에 다음과 같은 구체적인 정보를 구조화하여 노출해야 합니다.

명확한 저자 프로필: 콘텐츠 상단이나 하단에 작성자 이름과 사진 표시
객관적 자격 명시: 저자의 관련 전공, 보유 자격증, 해당 분야 실무 연차 표기
증빙 링크 연결: LinkedIn 프로필, 공식 인증 페이지, 학위/자격 검증 링크 연결

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@name": "홍길동",
  "@jobTitle": "소프트웨어 엔지니어",
  "@sameAs": [
    "https://www.linkedin.com/in/your-profile",
    "https://github.com/your-id"
  ]
}

위 예시처럼, sameAs 속성에 공식 SNS나 외부 프로필 링크를 연결하면, 구글 지식 그래프(Knowledge Graph)가 이 글의 저자와 외부의 실제 인물을 동일인으로 인지하는 데 도움을 줍니다.

네 번째 시행착오: 푸터를 지워놓고 푸터를 찾았다

이것은 순전히 개발 파이프라인 처리 순서에서 발생했던 제 버그였습니다.

HTML 파서는 본문 텍스트를 정제할 때 헤더(header), 푸터(footer), 내비게이션(navigation) 영역을 먼저 제거합니다. 본문 분량이나 단락 길이를 계산할 때 상하단 공통 메뉴 텍스트가 섞이면 데이터가 오염되기 때문에 지극히 당연한 정제 과정입니다.

그런데 확인해야 하는 Trustworthiness(신뢰성) 핵심 단서들인 개인정보처리방침, 이용약관, 연락처, 고객센터 등의 정보가 거의 푸터 영역에 몰려 있습니다. 이미 푸터가 제거된 본문 텍스트에서 약관을 찾으니 아무것도 검출되지 않았고, 멀쩡히 약관을 갖춘 사이트들이 신뢰성 항목에서 누락되었습니다.

해결책은 파이프라인의 입력을 바르게 교정하는 것이었습니다. Trustworthiness(신뢰성) 검증 로직은 정제된 본문이 아니라, 정제 전 원본 HTML(rawHtml)을 직접 참조하도록 해서 분석에 필요한 소스 정보를 놓치지 않도록 했습니다.

이 버그가 준 교훈은 명확합니다. 자동화 진단 로직에서 발생하는 수많은 오류는 판정 규칙 자체가 틀려서라기보다, 분석의 소스 데이터가 언제 어떻게 가공되었는지를 놓칠 때 발생한다는 점입니다. LLM에 평가를 몽땅 맡겼다면 이 파이프라인의 오류는 발견조차 되지 못했을 겁니다.

다섯 번째 시행착오: 에이전트 간 분석 결과를 참조하지 않는다

초기에는 시스템 효율을 높이고자 했습니다. 구조화 데이터를 분석하는 에이전트가 이미 JSON-LD를 파싱하고 있었으므로, E-E-A-T 분석 에이전트에서는 그 파싱 결과값을 가져다 써도 되겠다고 판단했습니다.

하지만 이 의존성이 엉뚱한 연쇄 오류를 낳았습니다. 구조화 데이터 에이전트는 스키마 표준 규격에 맞게 엄격한 문법 검증(Validation)을 수행하고 온전한 객체만 결과물로 넘겨줍니다. 그런데 어떤 사이트의 JSON-LD에 사소한 쉼표 누락 같은 문법 오류가 발생하자, 구조화 데이터 에이전트는 이를 유효하지 않음으로 규정하고 빈 데이터(null)를 반환해 버렸습니다.

이 때문에 E-E-A-T 에이전트는 본문에 엄연히 저자(Person) 정보가 기재되어 있었음에도 불구하고, 앞선 에이전트가 넘겨준 null 값만 보고 저자 정보가 없다며 E-E-A-T 점수를 깎아버렸습니다. 구조화 데이터의 문법 규격 오류가 아무 상관 없는 콘텐츠의 저자 신뢰성 평가 실패로 꼬여서 번진 것입니다.

이처럼 개별 에이전트가 다른 에이전트의 처리 결과물에 의존하면, 한 곳의 사소한 에러나 로직 수정이 도미노처럼 다른 에이전트의 분석 결과를 오염시키게 됩니다.

이를 해결하기 위해 E-E-A-T 에이전트가 다른 에이전트의 가공된 결과물 대신, 원본 소스 데이터로부터 직접 스키마 텍스트를 추출해 독립적으로 정보를 분석하도록 구조를 개선했습니다.

비록 파싱 연산이 중복되어 자원은 조금 더 들더라도, 개별 에이전트의 로직 수정이나 특정 페이지의 오류가 시스템 전체로 전파되는 것을 완벽히 방지하여 독립성을 유지할 수 있게 되었습니다.

여섯 번째 시행착오: 업종의 맥락을 생략하면 분석에 왜곡이 발생한다

E-E-A-T를 분석할 때는 업종의 특성을 좀 더 고려해야 했습니다.

예를 들어 전문 기술 블로그나 미디어는 고객 실사용 후기나 1인칭 체험담(Experience)이 거의 없습니다. 이 매체들이 AI 검색 답변으로 인용되는 핵심 가치는 필자의 깊은 전문성(Expertise)과 외부 언론의 권위(Authoritativeness)입니다. 반대로 전자상거래 쇼핑몰은 저자의 학위나 자격증(Expertise)보다는 실제 구매자의 사용 경험 데이터(Experience)가 훨씬 중요한 신뢰 기준입니다.

모든 사이트를 동일한 기준으로 바라보면, 쇼핑몰은 전문성 부족으로, 기술 블로그는 경험 부족으로 억울한 감점을 받게 됩니다. 그래서 사이트의 업종 맥락을 정규식 매칭을 통해 먼저 분류하고, 업종별로 4가지 관점의 가중치를 다르게 할당하도록 개선했습니다.

쇼핑몰과 지역 서비스는 경험(Experience 35%)에 무게를 두고, 미디어/출판은 전문성(Expertise 30%)에 더 가중치를 주는 식입니다.

또한 이 업종 분류 과정에서도 성급한 확정을 피하는 안전장치를 두었습니다. 자사 브랜드 몰을 직접 운영하는 SaaS 기업처럼 두 가지 성격이 비등하게 섞여 있는 경우, 단어 몇 개 차이로 업종이 강제 정의되면 진단 프레임 전체가 요동치기 때문입니다. 분류가 애매할 때는 섣부르게 억지로 분류하지 않고, 균등 가중치를 적용합니다.

그래서 LLM은 무엇을 하나

여기까지 설명하면 “그렇다면 LLM은 아무 역할도 하지 않는가?”라는 의문이 들 수 있습니다. 당연히 LLM의 역할은 매우 명확하고 강력합니다.

코드로 구성된 로직 엔진이 E-E-A-T 검증 결과와 수집된 정황 근거, 본문 샘플을 깔끔한 데이터 객체로 정리하여 넘겨주면, LLM은 이를 바탕으로 사람이 읽고 즉시 실행할 수 있는 분석 리포트를 작성합니다.

진단 점수는 로직이 계산한 값 그대로 고정되며, LLM 응답값에서 숫자를 역파싱하지 않습니다. 프롬프트 문구로 “점수를 바꾸지 말라”고 부탁하는 것이 아니라, 코드 구조상으로 LLM이 수치 데이터에 접근해 임의적 해석을 할 수 없도록 물리적 격리를 구현한 것입니다.

대신 LLM은 서술 영역에서 압도적인 능력을 발휘합니다. 어떤 부분을 어떻게 고쳐야 하는지 실제 교체 가능한 예시를 작성해 주고, 개발 지식이 없는 마케팅/콘텐츠 담당자도 바로 복사해 적용할 수 있는 직관적인 가이드를 제공합니다.

마치며

GEO(Generative Engine Optimization)는 키워드를 반복 배치하던 기존 SEO의 단순 연장선이 아닙니다. AI 검색 엔진은 단순 키워드 매칭을 넘어서, 파싱 가능한 형태로 정돈된 데이터 인프라와 콘텐츠의 실질적 신뢰도를 판단합니다.

진단 도구를 뜯어고치며 얻은 6가지 핵심 레슨을 요약하면 다음과 같습니다.

<출처: 작가>

AI 빅테크 기업들이 정확한 인용 가중치 공식을 완전히 공개하지 않는 한, 우리가 만든 모든 진단 프레임워크는 현실에 대한 정교한 추정일 뿐입니다.

하지만 그 추정을 AI의 환각에 맡기지 않고 명확한 코드로 구현해 두면, 어디가 틀렸고 어떤 예외 상황에서 오탐이 발생하는지 추적하여 계속해서 로직을 진화시킬 수 있습니다. AI가 그날그날 다르게 뱉어내는 수치로는 엔지니어가 개선할 요소를 파악하기 어렵습니다.

내일 아침 경영진이나 팀원이 “우리 서비스가 AI 검색에 왜 인용되지 않는가”를 물어온다면, AI에 검색어를 입력하고, 화면을 캡처하는 일을 멈추시길 바랍니다. 대신 우리 서비스의 데이터가 AI에 손실 없이 전달되고 있는지, E-E-A-T를 입증할 단서들이 올바른 관점으로 정돈되어 있는지 진단 체계부터 세워보시길 권합니다. 관점이 명확해지는 순간, GEO 대응은 막연한 추측이 아니라 ‘다음 스프린트에 어떤 기술적/콘텐츠적 결함을 고칠 것인가’라는 구체적인 실행 계획으로 바뀔 것입니다.

]]>

채용 공고 1만 건에서 뽑아낸 ‘AI 엔지니어링 스킬 맵’

“이 로드맵대로 공부하면 취업할 수 있다”는 글을 요즘도 종종 봅니다. 그런데 이상하게 예전만큼 그런 말에 눈이 가지 않더라고요. 로드맵이 가리키는 목적지가 반년 뒤에도 그대로 있을 거라는 확신이 없어서 그렇습니다. 남들이 미리 밟아본 길을 따라 걸으면 어딘가에 도착하던 시대는 끝난 것 같습니다. 지금 필요한 건 정해진 목적지로 가는 지도보다 이 혼란기에 적어도 멈춰서지는 않게 해주는 이정표가 아닐까 싶습니다.

마침 그런 이정표로 삼을 만한 글이 하나 올라왔습니다. 스탠퍼드 교수이자 세계적인 AI 대가 앤드류 응(Andrew Ng)이 지난 8월 14일 공개한 아티클 “The AI Engineering Skills Map”입니다. 그는 주요 AI 이론을 정립한 연구자이자, 코세라(Coursera)와 딥러닝.AI(DeepLearning.AI)처럼 유명한 교육 플랫폼을 창립한 교육자이기도 합니다.

그러한 AI 업계의 멘토가 제시한 지도를 따라가며, 이 시대의 생존을 위해 필요한 스킬이 무엇인지, 그 능력을 얻기 위해 실제로 무엇을 할 줄 알아야 할지 정리해 봤습니다.

<출처: Andrew Ng X>

- Andrew Ng, 〈The AI Engineering Skills Map〉

글에서 이탈릭 체로 처리한 모든 대화체는 아티클에서 인용한 글입니다.

지금 가장 중요한 AI 엔지니어링 스킬 4가지

이런 종류의 글은 대개 유명한 분들의 직관에서 나오는 것을 많이 봤습니다. 그런데 이번 스킬 맵의 출처는 데이터라고 합니다. AI 덕분에 전과는 전혀 다른 방식으로 소프트웨어를 만들 수 있게 됐고 기회도 많아졌는데, 정작 AI를 둘러싼 정보 환경은 “시끄럽고 과장으로 가득”합니다. 그래서 지금 배울 가치가 가장 큰 스킬이 무엇인지를 데이터로 추려 보기로 했다는 겁니다. 개발자에게는 무엇을 먼저 배울지 우선순위를, 고용주에게는 숙련된 개발자를 알아보는 기준을 주겠다는 목적으로요.

응 교수의 팀은 1만 건이 넘는 채용 공고를 분석했습니다. AI 전문가와 채용 관리자, 리크루터를 상대로 수십 건의 구조화된 인터뷰를 진행하고 설문과 온라인 데이터까지 종합했고요. 그렇게 뽑아낸 가장 중요한 AI 엔지니어링 스킬이 네 가지입니다.

AI 애플리케이션을 만들고 배포하기
소프트웨어 엔지니어링 기본기
코딩 에이전트 사용하기
그리고 무엇을 만들지 형태를 잡기(Shaping the build)

목록에는 새로운 프레임워크 이름도, 뜨는 도구 이름도 없습니다. 이는 다분히 의도된 것입니다.

응 교수는 이번 스킬 맵이 ‘AI 엔지니어’라는 직무 대신 ‘AI 엔지니어링’이란 영역을 다룬다고 단언합니다. “나는 ‘AI 엔지니어’라는 직무(AI 시스템을 만드는 것이 일인 사람)가 아니라 ‘AI 엔지니어링 스킬’을 이야기한다. 후자가 훨씬 넓기 때문”이라고요. 오늘날 모든 개발자는 클라우드를 다룰 줄 알아야 하지만 ‘클라우드 엔지니어’라는 직함을 가진 사람은 그보다 훨씬 적은 것처럼, 풀스택이든 데이터든 데브옵스든 머신러닝이든 모든 개발자가 AI 엔지니어링 스킬을 필요로 하게 될 거라는 겁니다.

이 관점이 기존 스킬 로드맵과의 가장 큰 차이라고 생각합니다. 특정 직무로 갈아타기 위한 목록이 아니라, 지금 자기 직무를 그대로 가진 채, 새로 더해야 하는 스킬의 목록이라는 거죠. 그럼 하나씩 보겠습니다.

1. AI 애플리케이션을 만들고 배포하기

첫 번째 스킬은 AI 애플리케이션을 만들고 배포하는 것입니다. 응 교수는 AI 애플리케이션과 그렇지 않은 애플리케이션의 핵심 차이를 한 문장으로 정리합니다.

“AI 애플리케이션과 AI가 아닌 애플리케이션의 핵심 차이는, 전자는 출력을 예측할 수 없다는 점이다.”

우리는 LLM에 프롬프트를 넣을 때 무엇이 돌아올지 알 수 없습니다. 또, 딥러닝 알고리즘을 학습시킬 때 새 예시에 어떤 예측을 내놓을지 알 수 없습니다. 반면 전통적인 소프트웨어는 훨씬 예측 가능하게 동작하죠. 같은 입력에는 같은 출력이 나오도록 짜는 게 지금까지의 개발이었으니까요.

그렇다면 이 스킬에 능숙하다는 건 무엇을 할 줄 안다는 걸까요. 응 교수에 따르면 LLM, 컨텍스트 엔지니어링, RAG, 에이전틱 워크플로, 머신러닝과 딥러닝 같은 AI의 구성 요소를 이해하는 것이 바탕이 됩니다.

하지만 그가 “무엇보다”라며 강조하는 건 따로 있습니다. 통계적 기법으로 AI 시스템을 측정하고 방향을 잡고 통제해, 더 예측 가능하게 행동하도록 만들 줄 아는 것. 그리고 그 핵심은 규율 있는 평가(eval)와 오류 분석 루프를 굴릴 줄 아는 기술에 있다고 합니다. 예측할 수 없다는 특성을 없앨 수는 없으니, 측정하고 좁혀가는 루프를 사람이 돌릴 줄 알아야 한다는 겁니다.

<출처: Google DeepMind>

2. 소프트웨어 엔지니어링 기본기

두 번째는 소프트웨어 엔지니어링 기본기입니다. AI가 코드를 다 짜주는 시대에 기본기라니, 목록에서 가장 의아한 항목일 수 있는데요. 응 교수의 논리는 이렇습니다.

소프트웨어를 엔지니어링한다는 건 비용, 확장성, 신뢰성, 속도 사이에서 트레이드오프를 하는 일이고, 보안과 프라이버시가 여기에 복잡성을 더합니다. 기본기를 이해하면 애초에 어떤 트레이드오프가 존재하는지를 알아볼 수 있습니다. 그 결과 소프트웨어 스택 선택, 시스템 아키텍처 설계, 데이터 저장소 설계, 테스트 같은 결정이 더 나아집니다.

대비되는 인물은 누굴까요? 코딩 에이전트가 어떤 트레이드오프를 하고 있는지도 모른 채 바이브 코딩으로 해법을 만들어내는 미숙한 개발자입니다. 응 교수는 이들의 결과가 나쁜 이유를 “코딩 에이전트에 어떤 컨텍스트를 줘야 하는지 모르기 때문”이라고 짚습니다. 반대로 기본기를 이해하면 “소프트웨어 엔지니어링의 정확한 언어로 코딩 에이전트를 조종해 좋은 트레이드오프를 할 수 있다”고 하고요.

그러니까 기본기를 익혀야 하는 ‘필요’가 바뀐 겁니다. 예전에는 내 손으로 좋은 코드를 짜기 위해 기본기가 필요했다면, 이제는 에이전트에 무엇을 시킬지 정확한 언어로 말하기 위해 필요합니다. 즉, “이 API는 캐시를 두되 무효화 조건을 이렇게 걸어라”라고 말할 수 있는 사람과 “빠르게 만들어줘”라고밖에 못 하는 사람의 차이는, 타이핑 실력이 아니라 트레이드오프를 알아채는 지식에서 갈립니다.

<출처: Pexels>

3. 코딩 에이전트 사용하기

세 번째는 코딩 에이전트 사용하기입니다. 응 교수는 에이전틱 코딩을 효과적으로 쓰는 것이 이제 모든 개발자의 핵심 스킬이라고 말합니다. 그렇다면 ‘숙련된 기술’을 가진 개발자의 모습은 무엇일까요?

이 스킬을 갖춘 사람은 에이전트가 어떻게 동작하는지에 대한 좋은 ‘멘탈 모델’을 가지고 있습니다. 글에 따르면 “에이전트의 한계와 그 한계를 우회하는 방법을 이해하고, 빠르게 방향을 잡아줄 수 있다 — 얼마나 개입하고 얼마나 내버려둘지를 알고 — 그래서 시간과 토큰을 지나치게 낭비하지 않으면서 견고한 소프트웨어”를 만들 수 있다는 뜻입니다. 어느 도구의 어느 기능을 쓸 줄 아느냐가 아니라, 언제 손을 대고 언제 손을 뗄지 판단하는 능력이 진짜 스킬이라는 얘기입니다.

구체적으로 할 줄 알아야 하는 것들 목록도 있습니다. 1) 코딩 에이전트의 컨텍스트를 관리할 줄 알아야 하고, 2) 계획과 실행 사이의 트레이드오프를 할 줄 알아야 합니다. 3) 검증기(verifier)나 평가를 제공해 에이전트가 스스로 루프를 닫도록 도울 줄도 알아야 하죠. 4) 명확한 스펙을 가지고 일하는 법과 굳이 그럴 필요가 없는 때가 언제인지 아는 것, 5) 여러 에이전트를 함께 동작하도록 오케스트레이션하는 법, 6) 에이전트가 프로덕션 데이터베이스를 망가뜨리는 것 같은 함정을 피하는 법도요.

하나하나가 도구 매뉴얼보다는 판단 기준에 가깝습니다.

무엇보다 에이전틱 코딩은 빠르게 진화하고 있습니다. 그래서 코딩 에이전트를 능숙하게 쓴다는 건 최신 실천법을 아는 것뿐 아니라 새로운 도구를 계속 시도해 보고 모범 사례가 바뀔 때마다 자기 워크플로를 진화시키는 루틴을 갖추는 것을 뜻합니다. 오늘 익힌 도구 활용법은 몇 달 지나면 낡은 것으로 바뀝니다. 그래서 이 스킬의 핵심은 빠르게 루틴을 갱신할 힘에 있습니다.

<출처: Anthropic>

4. 무엇을 만들지 형태를 잡기

네 번째 스킬의 이름이 ‘무엇을 만들지 형태를 잡기’입니다. 명확한 스펙을 줄수록 코딩 에이전트가 그것을 구현해 내는 능력은 빠르게 좋아지고 있습니다. 그러니 엔지니어의 일은 스펙에 무엇이 들어가야 하는지를 결정하는 쪽으로 옮겨 가고 있습니다. 응 교수는 꽤 단호하게 말합니다. “엔지니어는 더 이상 픽셀 단위까지 완성된 디자인을 받아서 구현만 하도록 요구받는 존재로 스스로를 기대해서는 안 된다.”고요.

대신 요구되는 건 제품, 그리고 비즈니스 맥락과 고객의 목표에 대한 이해입니다. 그래야 무엇을 만들지 형태를 잡고 추진하는 데 참여할 수 있으니까요.

응 교수는 “AI가 전보다 더 큰 주인의식과 주도권을 가질 기회를 준다”고도 덧붙입니다. 흥미로운 문제와 기회를 스스로 발견하고 책임 있게 실행에 옮길 수 있게 됐다는 겁니다. 이 기회를 잡으려면 프로젝트를 앞으로 밀고 나가는 법을 알아야 합니다. 언제 빠르게 MVP를 만들어 사용자에게 가져가 테스트할지, 언제 속도를 늦추고 시간을 더 들여 신중하게 만들지를 아는 것.

만드는 속도 자체는 더 이상 병목이 아니니, 어떤 속도로 만들지 정하는 게 스킬이 된 겁니다. 구현 능력을 갈고닦아 온 사람에게는 불편한 변화일 수 있지만, 방향은 분명해 보입니다.

<출처: Pexels>

스킬보다 더 중요한 ‘마인드셋’ 하나

마지막으로, 이 모든 스킬 밑에 깔려 있는 것은 ‘꾸준히 학습을 멈추지 않겠다’는 마인드셋입니다.

“AI는 계속 빠르게 변하기 때문에, 우리 모두 계속 배우고 스킬을 진화시켜 새롭게 떠오르는 모범 사례를 받아들여야”합니다. 그리고 이 모든 것이 저 4가지 역량을 키우는 토대가 됩니다.

이렇게 보니 네 가지 스킬의 공통점이 보입니다. 전부 외워두면 끝나는 지식이 아니라 계속 굴려야 하는 루프라는 거죠. 코딩 에이전트 워크플로는 모범 사례가 바뀔 때마다 다시 짜야 하고, 무엇을 만들지 정하는 힘도 시장과 모델이 바뀌는 것을 따라가야 합니다. 이제 AI는 스스로 다루는 걸 멈추는 순간 무뎌지다 못해 손에서 사라져 버리는 칼로 변했습니다.

그래서 저는 요즘 자주 쓰이는 ‘언런(unlearn)’이라는 말을 떠올렸습니다. 언제나 새로 배우려는 마음가짐. 대신, 가진 것을 모조리 버리라는 말로 이해하지는 않고 있습니다. 기본기 항목에서 봤듯 옛 지식은 버려지는 게 아니라 쓰는 방식이 바뀌는 것뿐이라고 생각하니까요.

변화의 속도에 압도돼 아무것도 손에 안 잡히는 상태야말로 피해야 할 것이겠죠. 혼란과 두려움에 갇혀 있는 대신, 지금 다룰 수 있는 것을 다뤄 보면서 스스로를 갱신해 나가는 것. 응 교수의 표현으로는 지속 학습 마인드셋, 이것이야말로 진짜 역량이 아닐까 합니다.

마치며

여러분은 에이전트에 정확한 언어로 트레이드오프를 말할 수 있나요? 개입할 때와 내버려 둘 때를 제대로 구분하고 있나요? 스펙을 받기만 하는지, 아니면 스스로 스펙을 정하고 있나요?

응 교수의 지도는 목적지를 약속하지 않습니다. 이 네 가지를 익히면 어떤 직함과 어느 정도 연봉에 도달한다는 식의 보장은 어디에도 없습니다. 대신 지금 무엇을 공부하고 익혀야 하는지는 비교적 잘 보여준다고 느낍니다.

그리고 지금 같은 혼란기에는, 어쩌면 그게 바랄 수 있는 전부이자 가장 필요한 것일지도 모르겠습니다.

]]>

요즘 클로드가 한국어를 어색하게 쓴다고 느꼈다면

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

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

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

써볼 것: fluent-korean - 클로드가 어색한 한국어를 쓰지 않게 잡아주는 도구
참고할 것: AI 에이전트를 깊이 이해하기 - 한국어판이 나온 무료 에이전트 교과서
적용해볼 것: AI가 다 만들어주는 시대에 사람이 챙겨야 할 것

<출처: snflkd/fluent-korean, GitHub>

1. 써볼 것: 클로드가 어색한 한국어를 쓰지 않게 잡아주는 도구

클로드로 작업하다 보면 답변이나 결과물의 한국어가 어딘가 어색할 때가 있습니다. 조사가 빠지거나, 문장이 명사만 뚝뚝 이어지거나, 평소 잘 안 쓰는 단어가 튀어나오죠. 최근 이런 현상을 겪는다는 이야기를 자주 봤는데요. fluent-korean은 이를걸 잡아주는 도구입니다. snflkd라는 개발자가 만들어 GitHub에 공개했어요.

fluent-korean은 클로드에게 명확한 한국어를 쓰라고 미리 지시해두는 출력 스타일(output-style)입니다. 클로드 코드(Claude Code)라는 개발 도구에 붙여 쓰는 방식이지만, 지침 자체를 복사해 클로드 웹이나 앱, 다른 AI에도 적용할 수 있어요.

<출처: snflkd/fluent-korean, GitHub>

LLM, 코딩 에이전트는 왜 한국어를 어색하게 쓸까요?

흥미로운 부분은, 이 도구가 왜 이런 문제가 생기는지까지 짚어준다는 점입니다.

AI 코딩 도구는 대개 말을 짧게 하도록 맞춰져 있습니다. 처리하는 글자 수(토큰)를 줄이면 비용이 내려가고 속도가 빨라지거든요. 문제는 이 간결함이 한국어에서 문장 성분을 생략하는 쪽으로 나타난다는 거예요. 영어는 단어 순서로 문장의 뼈대가 잡혀서 좀 줄여도 뜻이 대략적으로 통하는데, 한국어는 조사와 어미가 그 뼈대를 지탱해서 이것들이 빠지면 의미가 흔들립니다. 그래서 짧게 쓰라는 설정이 유독 한국어에서 어색한 문장을 만들어내죠.

fluent-korean을 만든 사람은 여기에 한 가지를 더 짚습니다. 어색한 한국어가 단순히 읽기 불편한 데서 끝나지 않는다는 거예요. 요즘 AI는 답을 내기 전에 스스로 생각하는 과정(추론)을 거치는데, 그 생각을 흐린 한국어로 하면 생각의 질 자체가 나빠질 수 있다는 겁니다. 문장이 어색해지는 문제가 아니라 판단이 흐려지는 문제라는 관점이죠.

한 가지 더 있습니다. 요즘은 여러 AI가 서로 한국어로 정보를 주고받으며 일하는 경우가 늘고 있어요. 이때 어색한 한국어가 단계마다 조금씩 쌓이면, 처음엔 사소했던 의미 손실이 마지막엔 결과물 전체의 완성도를 떨어뜨릴 수 있습니다.

어떻게 쓰나요?

클로드 코드를 쓴다면 명령어 두 줄로 설치합니다.

/plugin marketplace add snflkd/fluent-korean
/plugin install fluent-korean@fluent-korean

설치한 뒤 설정에서 출력 스타일을 고르고, 새 세션을 시작하면 적용됩니다. 코딩 지침을 함께 담은 버전과, 코딩 없이 글쓰기에만 쓰는 버전 두 가지가 있어요.

클로드 코드를 쓰지 않는 분이라면 더 간단합니다. 이 도구의 지침 텍스트를 클로드 웹이나 앱의 설정(개인 지침)에 붙여넣으면 돼요. 무료이고(MIT 라이선스), 세부 취향도 고를 수 있습니다. 초보 개발자도 이해하게 써달라거나, 높임말을 쓰게 하거나, 잘 안 쓰는 어려운 단어를 피하게 하는 식으로요.

명령어가 익숙하지 않다면, 클로드에게 이 저장소 주소를 주면서 README 읽고 설치 방법 알려줘라고 부탁하는 방법도 있습니다. 이 경우 알아서 내 환경에 맞게 안내해주죠.

한 가지 알아둘 점은, 이 방식이 토큰을 조금 더 쓴다는 겁니다. 생략됐던 문장 성분을 되살리니 그만큼 글자 수가 늘어나거든요. 품질과 비용을 맞바꾸는 셈인데, 한국어 결과물의 완성도가 중요한 작업이라면 그만한 값어치가 있을 것 같습니다.

누구에게 좋을까요?

클로드가 주는 한국어 문서나 보고를 자주 받고, 결과물을 본인이 다듬는 사람. 결과물을 다시 다듬는 수고가 줄어듭니다.
AI가 쓴 한국어가 자꾸 어색해 의미를 파악하기 불편하고 아쉬웠던 사람.

참고로 이 도구를 만든 사람은 국어국문학 전공자라고 밝혔고, README에 앤트로픽이 이 글을 보면 연락 달라, 클로드에게 한국어가 무엇인지 알려주겠다는 위트 있는 문구도 남겼죠. (ㅎㅎ) 비슷한 목적의 다른 도구(im-not-ai, korean-skills 등)도 여럿 나오고 있어서, 한국어를 쓰는 개발자들이 같은 문제의식을 공유하고 있다는 것도 엿볼 수 있었습니다.

<출처: bojieli/ai-agent-book, GitHub>

2. 참고할 것: 한국어판이 나온 무료 AI 에이전트 교과서

AI 에이전트를 직접 만들거나 깊이 이해하고 싶은 분께 반가운 자료가 나왔습니다. AI 에이전트를 깊이 이해하기라는 책의 한국어판이 8월 19일 공개됐어요. 원저자는 중국의 개발자 리보제(Bojie Li)이고, 한국어판은 커뮤니티 번역가가 옮겼습니다. 전체가 무료로 공개된 오픈소스 자료예요.

미리 말씀드리면, 이 책은 에이전트를 만드는 사람을 위한 본격 기술서에 가까운 자료입니다. 강화학습 같은 깊은 주제까지 다뤄주죠. 그래서 개발이 주 업무가 아니라면 처음부터 끝까지 볼 필요는 없습니다. 다만 요즘 여기저기서 들리는 에이전트라는 게 대체 어떻게 굴러가는 건지 그 큰 그림을 잡고 싶다면, 앞부분만 봐도 얻어갈 수 있는 것들이 있습니다.

이 책이 말하는 에이전트의 뼈대

책은 에이전트를 한 문장으로 정리합니다. 에이전트 = LLM + 컨텍스트 + 도구예요. 저자는 이걸 사람에 빗대 두뇌 + 눈 + 손발이라고 풀어줍니다.

두뇌(LLM)는 생각하고 판단하는 부분이에요. 눈(컨텍스트)은 에이전트가 무엇을 볼 수 있는지, 그러니까 어떤 정보와 지시를 갖고 일하는지를 정합니다. 손발(도구)은 에이전트가 실제로 무엇을 할 수 있는지, 검색이든 파일 작업이든 그 행동의 범위를 정하고요. 요즘 에이전트가 똑똑해 보이는 건 두뇌만 좋아서가 아니라, 이 눈과 손발을 잘 설계했기 때문이라는 게 책의 관점입니다.

이 비유 하나만 가져가도, 에이전트 관련 소식을 읽을 때 지금 이건 두뇌 얘기인가, 눈 얘기인가, 손발 얘기인가를 구분하며 볼 수 있어요. 앞선 회차들에서 다룬 컨텍스트 엔지니어링이 왜 중요한지도 이 틀로 보면 선명해집니다. 결국 에이전트에게 무엇을 보여줄지(눈)를 다루는 일이니까요.

개발자가 아니어도 가져갈 만한 것

저자는 서문에서 실천이 먼저이고 이름은 나중이라고 말합니다. 스킬이나 하네스처럼 요즘 에이전트 업계를 휩쓴 용어들이, 사실은 어떤 회사가 발명한 게 아니라 이미 현장에서 쓰이던 방식에 나중에 이름을 붙인 것뿐이라는 거죠.

여기서 저자가 끌어내는 교훈은 프로덕트 메이커에게도 통합니다. 어떤 용어가 유행하기 시작할 즈음이면, 앞서가는 곳은 이미 그 문제를 풀어본 뒤라는 겁니다. 유행어가 퍼지고 나서야 시작하면 이미 한발 늦은 셈이죠. 남보다 앞서고 싶다면 이름이 붙기 전에 직접 부딪혀 봐야 하는데, 이건 개발만이 아니라 새로운 걸 다루는 모든 일에 해당하는 이야기일 것 입니다.

이 책이 무료로 풀린 배경도 그렇습니다. 저자는 인세를 받는 대신 오픈소스 공개를 택했어요. 이 지식이 더 많은 실무자에게 닿기를 바란다는 이유였습니다.

무엇을 얻어가면 될까요?

개발자라면 94개의 실습 코드까지 딸려 있으니, 에이전트를 만드는 실전 교재로 삼을 만합니다. 개발자가 아니라면 두 가지만 기억해도 충분해요. 에이전트는 두뇌와 눈, 손발로 이뤄진다는 틀, 그리고 실천이 먼저이고 이름은 나중이라는 관점이요. 이 둘만 알아둬도 요즘 쏟아지는 AI 에이전트 소식을 한결 차분하게 볼 수 있을 거라 생각합니다. 무료로 공개돼 있으니 앞부분만 부담 없이 살펴봐도 좋을 것 같고요.

<출처: Joseph Heck, Software Engineering fundamentals matter more than ever>

3. 적용해볼 것: AI가 다 만들어주는 시대에 사람이 챙겨야 할 것

최근 AI로 뭐든 빠르게 만들 수 있게 되면서, 그럼 사람은 뭘 해야 하나 하는 질문이 많아졌습니다. 그리고 그에 대한 여러 관점과 의견도 나오고 있고요. 그중에서 시애틀의 개발자 조지프 헥(Joseph Heck)이 자기 블로그에 쓴 글을 소개하려 합니다. 흔히 나오는 관점과 취향을 길러라 같은 이야기에서 한발 더 들어가, 그래서 구체적으로 뭘 어떻게 챙겨야 하는지를 짚어주기 때문입니다. 저자는 개발자를 위해 쓴 글이지만 핵심 내용은 제품을 만드는 누구에게나 통한다고 생각해, 개발 이야기를 조금 걷어내고 프로덕트 메이커의 언어로 옮겨봤습니다.

만들 수 있다는 건 시작일 뿐입니다

저자는 20대에 용접을 배웠던 이야기를 꺼냅니다. 금방 뭔가를 만들어냈는데, 너무 크고 무거워서 작업장 문 밖으로 꺼낼 수조차 없었다고 합니다. 만드는 것과 실제로 쓸 수 있게 만드는 것은 다른 일이라는 걸 그때 배웠다고 하죠.

AI도 비슷한데요. AI로 작동하는 무언가를 뽑아내는 건 이제 쉬워졌습니다. 프로토타입이든 랜딩페이지든 하루면 나오죠. 그런데 그건 시작점이지 끝이 아니에요. 그게 실제로 굴러가는 제품이 되려면, 고객 문의에 대응하고, 내용을 고치고, 다른 기능과 붙이는 긴 과정이 남습니다. 급하게 만든 것이 이 단계에서 오히려 발목을 잡기도 하고요. 만드는 순간보다 만든 뒤 오래 데리고 살 것을 생각하며 판단하는 게 중요하다는 이야기입니다.

진짜 어려운 건 조각이 아니라 이음새입니다

저자가 가장 힘주어 말하는 대목입니다. 개별 조각을 만드는 것보다, 그 조각들이 서로 맞물리는 이음새를 설계하는 게 훨씬 어렵다는 거예요.

개발자에게 이음새는 코드와 코드가 만나는 지점, 기능을 외부와 연결하는 방식입니다. 이를 프로덕트 메이커에게 옮기면, 기능과 기능이 이어지는 흐름, 화면에서 화면으로 넘어가는 경험, 여러 조각이 하나의 제품으로 통합되는 지점이라 할 수 있을 것 같습니다. AI에게 개별 기능이나 화면을 하나씩 만들라고 하면 곧잘 해냅니다. 그런데 그것들이 자연스럽게 이어지는지, 사용자가 A에서 B로 넘어갈 때 매끄러운지는 잘 챙기지 못하죠. 각 조각은 훌륭한데 합쳐놓으면 어딘가 어긋나는 경험, 다들 겪어보셨을 겁니다. AI가 조각을 잘 만들수록, 그 조각들을 하나의 경험으로 잇는 사람의 안목이 더 중요해집니다.

AI는 생각하는 게 아니라 예측하는 겁니다

저자는 냉정하게 짚습니다. AI는 사실 추론하지 않는다는 거예요. 인간이 남긴 방대한 지식을 압축해뒀다가, 다음에 올 말을 예측해 내놓는 것에 가깝다고 합니다. 그래서 인간 지식에 이미 담긴 문제는 잘 풀지만, 전에 없던 새로운 상황에서는 약하죠.

이 이야기는 AI가 어떤 상황에서 약한지 알려줍니다. 많이 논의된 흔한 문제는 잘하지만, 처음 마주하는 문제에선 그럴듯하게 틀릴 수 있어요. 그럼 어떻게 해야 할까요. 저자의 답은 막연하지 않습니다. 저자의 답은 막연하지 않아요. 오히려 당연하게 들릴 만큼 구체적입니다. AI에게 좋고 간결한 자료를 적절한 때에 주고, 결과가 맞는지 확인할 방법을 함께 붙이라는 겁니다. 이건 개발만의 이야기가 아니라 AI에게 일을 시키는 법 자체에 가까워 보입니다. 기획서를 맡기든 리서치를 시키든, 좋은 자료를 주고 결과를 검증하는 습관은 직무를 가리지 않아요.

지시를 잘 따르는 AI일수록 방향이 중요합니다

저자가 걱정하는 지점이 하나 더 있어요. AI는 좋은 지시와 나쁜 지시를 구분하지 못한 채, 시키는 대로 지치지 않고 따른다는 거예요. 좋은 판단 없이 지시만 충실히 따르는 존재가 오히려 무섭다고까지 말합니다.

프로덕트 메이커에게 이건 방향의 문제입니다. AI가 유능할수록, 사람이 잘못된 방향을 잡으면 그 잘못을 아주 빠르고 그럴듯하게 완성해버리겠죠. 그러니 AI가 얼마나 잘하느냐만큼, 무엇을 시킬지를 정하는 사람의 판단이 결과를 좌우합니다.

결국 무엇을 고정하고 무엇을 열어둘지 정하는 일

저자가 마지막에 던지는 요점입니다. 만들기의 핵심은 어떤 부분을 안정적으로 고정하고, 어떤 부분을 유연하게 바꿀 수 있게 둘지 정하는 데 있다는 거예요. 만병통치약은 없고, 늘 무엇을 얻고 무엇을 포기할지 고르는 일이라고 합니다.

이건 사실 기획의 본질과 맞닿아 있습니다. AI가 뭐든 빠르게 만들어주니 다 바꿀 수 있을 것 같지만, 그럴수록 무엇을 안 바꿀지를 정하는 게 중요해질 겁니다. 제품의 뼈대로 삼아 고정할 부분과, 실험하며 바꿔갈 부분을 나누는 판단이요.

적용해볼 수 있는 것

AI에게 일을 맡길 때, 개별 결과물만 보지 말고 그것들이 어떻게 이어지는지를 함께 살펴보세요. 이음새에서 문제가 드러나는 경우가 많습니다.
뭔가를 빠르게 만들었다면, 이걸 반년 뒤에도 고쳐가며 쓸 수 있을까를 한 번 물어보세요.
AI에 일을 시키기 전에, 좋은 자료를 골라 주고 결과를 어떻게 확인할지 함께 정해두세요.

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

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

]]>

클로드 코드 제대로 써먹는 프롬프트 작성 팁 6가지

바이브 코딩에서 좋은 결과물을 얻기 위해서는 프롬프트의 품질이 중요합니다. 같은 에이전트를 만들더라도 요청 방식에 따라 결과물의 완성도가 크게 달라질 수 있습니다. 이 글에서는 효과적인 프롬프트 작성법을 실제 예시와 함께 상세히 설명해보겠습니다.

프롬프트 원칙 1: 배경·목적·제약을 먼저 설명하라

가장 흔한 실수는 결과물만 요청하는 것입니다. “~ 만들어 줘.”라는 모호한 요청보다 배경과 목적을 설명해야 클로드 코드가 최적의 설계 과정을 거쳐 사용자의 상황에 맞는 가장 정확한 결과물을 만들어낼 수 있습니다.

나쁜 프롬프트 예시

뉴스 수집 에이전트 만들어 줘

좋은 프롬프트 예시

나는 IT 스타트업에서 사업 개발을 담당하고 있어. 
매일 아침 출근 전에 AI, 클라우드, 핀테크 분야 주요 뉴스를 
5분 안에 파악하고 싶어.

이를 위해 다음 기능을 하는 에이전트를 만들어 줘:
- 매일 오전 7시 자동 실행
- 키워드: AI 기술, 클라우드 서비스, 핀테크 규제
- 각 키워드당 최신 뉴스 3건 수집
- 각 뉴스의 비즈니스 영향도를 높음/보통/낮음으로 분류
- 영향도 높음 뉴스만 모아서 Gmail로 발송
- 메일 제목: ‘[일일 뉴스 브리핑] YYYY-MM-DD’

차이가 보이나요? 좋은 프롬프트는 ‘내가 누구인지’, ‘무엇을 달성하고 싶은지’, ‘구체적인 요구사항이 무엇인지’를 명확하게 담고 있습니다. 이 세 가지 정보가 있어야 클로드 코드가 내 상황에 맞는 최적의 에이전트를 설계할 수 있습니다.

목표(뉴스 수집)가 동일하지만 배경이 다른 프롬프트 예시

예시1 마케팅 담당자

경쟁사 마케팅 캠페인 동향을 매일 5건씩 모아서 분석하고 마케팅 팀 슬랙 채널에 공유하고 싶어.

→ 웹 검색 + 분석 + 슬랙 연동 에이전트)

예시2 주식 투자자

기술주 관련 뉴스와 실시간 주가 변동을 함께 보여 주고, 매도/매수 신호가 나타나면 즉시 알림을 받고 싶어.

→ 웹 검색 + 금융 데이터 API + 푸시 알림 에이전트)

예시3 대학 신문 편집자

캠퍼스 관련 뉴스를 자동으로 수집하고, 기사 가치도별로 분류한 후 구글 문서로 편집 대기 목록을 만들어 줘.

→ 웹 검색 + 분류 + 구글 문서 에이전트)

프롬프트 원칙 2: 출력 형식을 구체적으로 명시하라

에이전트 요청 시 출력 형식을 구체적으로 명시해야 의도에 맞는 완성도 높은 결과물을 얻을 수 있습니다. 이메일 본문에는 마크다운, PDF 보고서에는 표와 그래프, JSON 데이터 연동일 때는 구조화된 형식 등과 같이 매체나 용도에 맞춰 원하는 구조를 명확히 제시하는 것이 중요합니다.

나쁜 프롬프트 예시

분석 결과를 메일로 보내 줘.

좋은 프롬프트 예시

분석 결과를 메일로 보내 줘. 메일 형식은 다음과 같아: 

제목: [뉴스 브리핑] {날짜} 

오늘의 핵심 뉴스 ({영향도 높음 건수}건) 

1. {뉴스 제목} 
요약: {2-3줄 요약} 
영향도: 높음 
링크: {URL} 

---
전체 수집: {총 건수}건 | 높음: {건수} | 보통: {건수} | 낮음: {건수}

일반적인 출력 형식 선택 기준

HTML 이메일:웹처럼 배경색, 이미지, 테이블 등 풍부한 스타일링이 필요할 때 사용하지만, 메일 클라이언트마다 렌더링된 화면이 다를 수 있음을 고려해야 합니다.
순수 텍스트 메일:스팸 필터에 걸릴 확률이 낮고 모든 기기에서 동일하게 보이며, 가장 높은 신뢰도와 호환성을 보장합니다.
마크다운 형식: 구조적이면서도 가독성이 높아, 깃허브(GitHub)나 슬랙(Slack)처럼 마크다운을 지원하는 플랫폼에 정보를 보낼 때 최적입니다.
PDF 첨부: 보고서나 공식 문서처럼 고정된 레이아웃이 필요하거나, 파일을 다운로드하여 오프라인에서 읽어야 하는 경우에 적합합니다.
JSON 데이터:사람이 읽기보다는 다른 시스템이나 프로그램과 연동하여 데이터를 자동으로 파싱하고 처리해야 할 때 가장 효율적입니다.

프롬프트 원칙 3: 예외 케이스와 오류 처리를 미리 말하라

예외 처리 없이 만든 에이전트는 예상 밖의 상황이 오면 그냥 중단되거나 이상한 결과를 만들지만, 예외 처리를 미리 정의하면 어떤 상황이 와도 에이전트가 적절히 처리하고 사용자에게 알려주므로 에이전트의 신뢰도가 달라집니다.

일반적인 예외 케이스

검색 결과 부재 시:메일을 발송하지 않거나, 검색 결과가 없음을 알리는 요약 메시지를 전송하여 불필요한 빈 메일 확인을 방지합니다.
메일 발송 실패 시:자동 재시도를 수행하거나, 즉각적인 조치가 가능하도록 텔레그램 등 다른 채널로 오류 알림을 보냅니다.
파일 부재 시:유사한 파일명을 제안하거나 사용자에게 알림을 보내어, 경로 설정이나 파일 생성 상태를 즉시 점검하게 합니다.
API 한도 초과 시:작업을 다음 날로 미루거나 중요도가 높은 일부 데이터만 우선 처리하여 시스템의 연속성을 유지합니다.
네트워크 타임아웃 발생 시:일정 시간 후 재시도 로직을 가동하거나, 수집된 부분 결과라도 반환하여 전체 작업이 멈추지 않게 합니다.
인증 토큰 만료 시:오류 발생 사실과 함께 갱신 필요 알림을 보내거나, 사전에 등록된 자격 증명을 통해 자동으로 재인증을 시도합니다.

좋은 프롬프트 예시

예외 처리 예시:

웹 검색 결과가 없는 키워드는 건너뛰고 나머지는 진행해 줘.

Gmail 발송 실패 시 3번까지 재시도하고, 그래도 실패하면 텔레그램으로 알림 보내 줘.

네트워크 오류 발생 시 최대 5초 대기 후 1회 재시도

모든 오류는 ./logs/error.log 파일에 타임스탬프와 함께 저장

5개 이상의 오류가 쌓이면 알림 메일 발송

프롬프트 원칙 4: 단계별로 나누어 요청하라

복잡한 에이전트를 만들 때는 한 번에 처리하기보다 단계별로 나누어 요청하는 것이 훨씬 안정적입니다. 이는 ① 컨텍스트 창(Context Window)의 한계로 인한 중요 정보 누락을 방지하고, ② 문제 발생 시 오류 원인을 쉽게 격리(Error Isolation)하여 수정할 수 있도록 도와줍니다.

뉴스 수집 에이전트를 단계별로 만든다면 다음과 같습니다.

1단계: 뉴스 수집 에이전트 생성 및 테스트

요청 내용

뉴스 수집 에이전트 하나만 만들고 테스트해 줘.

확인 포인트: 실제로 뉴스가 수집되는지, 데이터 구조가 올바른지 확인

2단계: 영향도 분류 기능 추가

요청 내용

수집된 뉴스에 영향도 분류 기능 추가해 줘.

확인 포인트: 분류 기준이 적절한지, 결과가 기대에 맞는지 확인

3단계: 메일 발송 기능 추가

요청 내용

분류 완료된 결과를 메일로 보내는 기능 추가해 줘.

확인 포인트: 메일 형식 및 실제 수신 여부 확인

4단계: 자동 실행 스케줄 등록

요청 내용

이 전체를 매일 오전 7시에 자동 실행하도록 스케줄 등록해 줘.

확인 포인트: 스케줄러의 정상 동작 여부 확인

프롬프트 원칙 5: 수정 요청은 구체적으로

결과가 마음에 들지 않을 때는 ‘무엇이 문제인지’, ‘왜 문제인지’, ‘어떻게 바뀌어야 하는지’ 세 가지를 함께 담아 수정을 요청해야 가장 효과적으로 원하는 방향에 도달할 수 있습니다.

막연한 수정 요청

결과가 별로야. 다시 만들어 줘.

구체적인 수정 요청

두 가지를 수정해 줘: 

1. 현재 메일에 뉴스가 제목만 있는데, 
각 뉴스 아래에 2-3문장 요약을 추가해 줘. 

2. 영향도 '높음'으로 분류된 기준이 너무 느슨한 것 같아.
현재 10건 중 8건이 높음으로 나오는데,
실제로 즉각적인 비즈니스 행동이 필요한 뉴스만 높음으로

분류되도록 기준을 강화해 줘.

‘나쁜 요청’에는 클로드 코드가 스스로 채워야 할 질문들이 숨어 있는데, 아래 예시에서는 그 숨은 질문들을 괄호로 나타내 보았습니다. ‘좋은 요청’은 이미 요청 안에 그 질문들의 답이 들어 있는 요청입니다.

나쁜 수정 요청

메일이 너무 길어

→ (어느 부분이? 몇 줄까지가 적당한지?)

뉴스 분류가 잘못 되었어

→ (어떤 뉴스? 왜 잘못된 것인지?)

성능이 안 좋아

→ (어디가 느린지? 목표는?)

좋은 수정 요청

메일이 현재 3000자인데 500자 이내로 줄여 줘. 각 뉴스의 요약 문장을 1-2줄로 단축하고 링크는 제거해 줘.

AI 관련 뉴스 3개를 실행해 본 결과 2개는 '높음'으로 분류되었는데, 둘 다 장기 기술 뉴스라서 낮음이 맞아. 높음 기준을 '3개월 내 즉시 행동이 필요한 경우'로 더 엄격하게 조정해 줘.

지난 3회 실행에서 평균 45초가 걸렸는데, 30초 이내로 줄이고 싶어. 어디가 병목일까? 병목을 제거하는 방식을 제안해 줄 수 있어?

프롬프트 원칙 6: 유형별 프롬프트 템플릿

유형별 프롬프트 템플릿입니다. 그대로 사용하거나 원하는 내용으로 채워서 사용하세요.

새 에이전트 생성

나는 [직업/역할]이야. 
[문제 상황]을 자동화하고 싶어. 

다음 기능을 하는 에이전트를 만들어 줘:
- 트리거: [언제 실행되는가? 매일 몇 시? 특정 이벤트?]
- 입력: [어떤 데이터를 사용하는가?]
- 처리: [어떤 작업을 수행하는가?]
- 출력: [결과를 어떻게 전달하는가?]

예외 처리:
- [예외 상황 1]: [처리 방법]
- [예외 상황 2]: [처리 방법]

기존 에이전트 기능 추가

기존 [에이전트 이름]에 [새 기능]을 추가해 줘.


추가 기능 상세:
- [기능 설명]
- 기존 [특정 부분] 다음에 실행되어야 해.
- 이미 있는 [기존 기능]은 유지해야 해.

오류 수정 요청

아래 오류가 발생했어. 원인 분석하고 수정해 줘.

[오류 메시지 전체 붙여 넣기]

이 오류는 [어떤 상황에서] 발생했어.
기대했던 동작은 [기대 동작]이야.

결과 형식 수정

[현재 출력 형식의 문제점]이 마음에 안 들어.

다음과 같은 형식으로 변경해 줘:
[원하는 출력 형식 예시를 직접 작성]

프롬프트 작성에서 가장 중요한 것은 ‘내가 원하는 것’을 구체적으로 아는 것입니다. 에이전트를 만들기 전에 잠깐 시간을 들여 정확히 무엇을 자동화하고 싶은가를 정리하면 훨씬 좋은 결과가 나옵니다.

이 글은 길벗에서 출간된 책 <클로드 코드 & 오픈클로> 에서 발췌·편집한 글입니다. 원문은 [여기]에서 볼 수 있습니다.

]]>

출근하면 코드부터 짜던 개발자가 이제 봇부터 켭니다

하네스 엔지니어링으로 코드를 한 줄도 안 쳐도 되는 환경을 만든 이야기

지난 글 ‘하네스 엔지니어링으로 AI 에이전트를 길들여봤습니다’에서 “프롬프트 엔지니어링은 끝났다”고 적으면서, 프롬프트만으로는 부족하고 시스템 레벨에서 hooks·권한·품질 게이트로 감싸야 한다고 정리했다. 그게 하네스 엔지니어링이다. 그 글을 쓴 지 몇 달이 지난 지금, 가장 크게 달라진 건 코드도 도구도 아니라 내 하루의 루틴이다.

요즘 내가 출근해서 가장 먼저 하는 일은 코드 에디터를 켜는 게 아니다. 봇을 켠다.미리 말해두면 이 글은 봇 자랑이 아니다. 봇 하나 붙인다고 하루가 바뀌지는 않는다. 실제로 하루가 바뀐 건 그 뒤에 누가 작업을 시작하든 같은 품질이 나오게 만든 하네스가 있었기 때문이다. 제목은 눈길을 끌려고 골랐고, 이 글은 사실 그 하네스로 인해 바뀐 내 일상 이야기다.

<출처: 작가, 제미나이로 생성>

코드를 짜던 자리에 무엇이 들어왔나

AI가 있기 전 내 오전 일과는 대략 이런 식이었다.

QA: “이거 이렇게 동작하는 게 맞나요? 여기 문구 수정하면 어디까지 영향 가요?”
나: “잠시만요… 금방 확인하고 알려드릴게요.” 하던 작업을 멈추고, 머릿속 생각들을 지우고, 코드를 열어 확인하고, 답을 한다.
QA: 그 답을 기다리는 동안 멈춰 있다.

질문 하나에 길게는 반나절이 갔다. 게다가 그 반나절은 내 “진짜 일”이 아니라 남이 막힌 곳을 뚫어주는 일이었고, 컨텍스트 스위칭 비용은 덤이었다.

지금은 이렇게 바뀌었다.

출근하면 Anvil(사내 Slack 봇)을 가동한다.
QA는 나 대신 봇과 직접 일한다. “이 API 아직 쓰나요?”처럼 묻고 끝나는 경우도 많고, “이거 고쳐줘”를 Slack DM으로 보내면 봇이 티켓을 분석하고, 영향 범위를 판정하고, 수정하고, MR까지 올린다.
나는 그사이 내 티켓 처리를 통째로 Slack에서 Anvil에 맡기고, Anvil이 더 나은 작업을 할 수 있도록 하네스를 깎는다.
Anvil이 올려둔 MR이 쌓이면, 점심 즈음 그걸 한 번에 리뷰하고 머지한다.

여기까지만 보면 그냥 “편해졌네”다.

<출처: 작가>

QA가 시작한 수정을, 내가 직접 한 것과 같은 품질로 믿고 머지할 수 있는 근거가 뭔가?

위임은 “맡기는 것”이 아니라 “맡겨도 같은 결과가 나온다는 보장”이 있을 때만 성립한다. 그 보장이 없으면 봇은 그냥 또 하나의 불안한 도구일 뿐이고, 결국 내가 일일이 다시 봐야 한다. 그 보장을 만든 게 하네스 엔지니어링이다.

다만 그 보장에는 범위가 있다. 뒤에 나올 장치들이 받치는 건 이 품질의 기술적 바닥까지다. 린트와 타입 검사, 위험 명령 차단은 “코드가 문법적으로 멀쩡하고 위험한 짓을 안 한다”까지는 보장한다. 하지만 “이 기능이 내가 의도한 대로 동작한다”까지는 보장하지 못한다. 그건 시스템의 몫이 아니라 정책 문서와 사람 리뷰의 몫이다. 의도적인 병목을 둔 것이다.

“코드를 안 쳐도 되는 환경”의 정체

“코드를 안 쳐도 된다”는 말은 “아무렇게나 만들어도 된다”가 아니다. 오히려 반대다. 사람이 한 줄 한 줄 챙기지 않아도 품질의 바닥이 시스템으로 보장돼야, 비로소 손을 뗄 수 있다.

그 바닥이 실제로 차이를 만드는지는 한 번 대조해 봤다. 같은 요구사항(캠페인 등록 폼)을 아무 설정도 없는 프로젝트와 하네스를 깐 프로젝트에 각각 던졌다. 정산 기준이나 최소 금액 같은 정책은 프롬프트에 한 줄도 적지 않았다. 코드베이스의 다른 화면에 이미 구현돼 있었을 뿐이다.

<출처: 작가>

모델이 똑똑해져서가 아니라, 코드베이스를 먼저 읽게 만들었느냐의 차이였다. 사람이 매번 “우리 정산은 28일이야”라고 일러주지 않아도 같은 답이 나온다면, 그 역할은 넘겨도 된다고 생각했다. 그 차이를 만든 장치에는 무엇이 있을까.

사람이 안 챙겨도 품질이 보장된다

응답 직전에 강제로 도는 품질 게이트가 있다.

에이전트가 “다 했습니다”라고 응답하려는 바로 그 순간(Stop 이벤트)에 끼어드는 훅이 있다. 이번 작업에서 수정된 파일들을 모아, 자동 수정 가능한 건 ESLint --fix로 먼저 정리하고, 남은 린트 에러와 tsc --noEmit 결과를 에이전트에 돌려준다. 통과해야 응답이 나가고, 실패하면 통과할 때까지 이 검문을 다시 거친다.

사람이 “린트 돌렸어?”라고 물어볼 필요가 없다. 프롬프트로 “꼭 검사해”라고 부탁하는 것과, 통과 못 하면 응답 자체가 안 나가게 막는 것은 신뢰도가 완전히 다르다. 사람도 “다 됐다” 직전에 한 번 더 안 보면 같은 실수를 반복한다.

위험한 행동은 두 층위로 거른다. 프롬프트로 막는 게 아니라 훅이 거른다.

아예 막는 것: rm -rf, DROP TABLE, .env 파일 생성은 실행 자체를 차단한다.
한 번 더 보게 하는 것: git push --force, --no-verify 같은 우회는 실행은 되지만 사람 확인을 거친다.

대장간으로 치면 용광로 둘레에 친 울타리(차단)와 “여기 뜨거움” 표지판(경고)의 차이다. 비개발자가 무심코 위험한 동선에 들어가도, 그 길이 시스템 레벨에서 끊긴다.

<출처: 작가, 제미나이로 생성>

누가 시작하든 기준이 같다

사고 모델을 에이전트 정의 안으로. 이게 의외로 컸다. 예전엔 “기존 코드를 먼저 확인하고, 검증하고, 안 되면 접근을 바꾼다”는 사고 모델이 프로젝트 루트 문서에만 있었다. 그런데 작업을 쪼개 서브에이전트를 부르면, 그 서브에이전트는 부모 문서를 상속받지 않아 제멋대로 움직이는 구멍이 있었다.

그래서 코드를 직접 만지는 에이전트의 정의 파일 안에 사고 모델을 직접 박았다. 누가, 어디서 스폰됐든 같은 사고 위에서 움직이게 만든 거다. 메인이든 서브든 기준이 같아야, 비개발자가 시작한 작업도 결국 같은 품질을 받는다.

봇은 별개 시스템이 아니다. Anvil은 내가 따로 만든 똑똑한 봇이 아니다. 내부적으로는 그냥 내가 평소에 쓰는 것과 똑같은 하네스를 헤드리스로 호출한다.

[QA가 Slack DM “이거 고쳐줘”]

→ Anvil (Node.js)

→ claude -p (헤드리스 모드)

→ 평소 쓰는 플러그인 그대로 활성화

(위험 명령 차단 · 사고 모델 · 품질 게이트)

→ MR 생성 → 담당자에게 DM

QA가 Slack에서 시작한 작업도, 내가 터미널에서 시작한 작업과 완전히 같은 훅, 같은 품질 게이트, 같은 사고 모델을 통과한다. 바깥 인터페이스(Slack DM)만 다를 뿐, 안쪽 기준은 다르지 않다. “인터페이스는 달라도 기준은 같다”가 위임의 전제였다.

그리고 그 통과 기록은 MR description에 자동으로 남는다. 어떤 에이전트가 몇 초 분석했는지, 코드 리뷰에서 무엇을 봤는지, lint와 build 결과가 무엇인지, 그리고 테스트를 안 돌렸다면 그 사유까지 적힌다.

테스트 전략

- 정책 키워드 감지: 없음 / 코어 모듈 변경: 없음

- 판정: 테스트 스킵 (사유: 매핑 로직만 변경)

내가 그 MR을 믿는 건 봇이 똑똑해서가 아니라, 안 한 것까지 이유가 남아 있어서다. 리뷰라기보다 감사 추적에 가깝다.

<출처: 작가>

사람은 꼭 필요한 곳에만 들어간다

모든 변경을 똑같이 빠르게 통과시키면 그건 안전한 게 아니라 그냥 검증이 없는 거다. 그래서 영향 범위를 세 등급으로 나눴다.

<출처: 작가>

원칙은 하나다. MAJOR에 일부러 병목을 두기 때문에, MINOR/MODERATE를 더 넓게 열 수 있다. 어느 등급인지는 프로젝트별 기준 파일(SSOT)이 코어 경로·정책 키워드를 보고 자동으로 판정한다. 덕분에 “사람이 꼭 봐야 하는 지점”이 좁아지고 명확해졌고, 나는 그 좁아진 지점에만 시간을 쓴다.

<출처: 작가, 제미나이로 생성>

코드를 안 친다고 일이 사라지진 않는다

그래서 내 일이 사라졌느냐 하면, 아니다. 옮겨갔다. 아래는 정확한 측정이라기보다 내 체감에 가깝다.

<출처: 작가>

키보드는 여전히 친다. 다만 코드가 아니라 정책 문서와 시나리오를 친다. 예전엔 “로그인 개선” 같은 요구사항을 받으면 곧장 컴포넌트 설계로 들어갔다면, 지금은 먼저 [사용자 흐름 / 입력 검증 규칙 / 에러 메시지 / 실패 케이스]를 마크다운으로 적는다. 그 문서가 곧 봇에게 주는 사양이 되니까.

무엇을 만들지를 모호함 없이 적는 일과 올라온 결과를 보는 일, 솔직히 이 둘은 사람이 직접 했을 때 결과가 더 좋아지는 종류의 일이다. 내 시간이 거기로 옮겨간 건, 손해가 아니라 이득에 가까웠다.

그래도 안 되는 것

솔직히 말하면, 이게 마법은 아니다.

운영하면서 자잘하게 깨진 것도 많았다. 예컨대 모노레포가 여러 개인 환경에서 봇이 어느 레포를 고칠지 자동으로 못 정하면, 처음엔 에러만 띄우고 끝났다. 비개발자 입장에선 “그래서 뭘 어쩌라고”인 상황이라, 자동 판별이 실패하면 후보 레포를 버튼으로 띄워 고르게 바꿨다. 실패할 때의 사용자 경험까지가 설계 범위라는 걸 그때 배웠다.

하지만 이런 건 코드로 고쳐진다. 정작 사이클이 통째로 멈추는 날은 거의 항상 “도구가 멍청해서”가 아니라 “내 정책 문서가 모호해서”였다. 도메인의 암묵적인 규칙, 그러니까 “이건 당연히 이래야지” 싶어서 굳이 문서에 안 적은 것은 봇이 끝내 못 잡는다. 봇은 내 머릿속을 읽지 못하고, 내가 적어준 문서만 읽는다. 그래서 난 그럴수록 코드 수정이 아닌 정책과 하네스를 다듬었다.

코드를 안 쳐도 굴러간 게 아니라, 정책을 직접 썼기 때문에 코드를 안 쳐도 됐다.

자기 도메인을 명시화할 수 있을 만큼은 알아야 한다는 전제는 사라지지 않는다. 다만 그 명시화의 결과물이 곧장 동작하는 코드로 이어지는 환경을, 이번에 한 번 만들어본 거다.

코드를 안 친 결과물은 몇 점이었을까?

그런데 앞에서 그어둔 선이 여기서 걸린다. 게이트가 받친 건 품질의 기술적 바닥이었지, 기능이 의도대로 도는지까지는 아니었다. 그래서 이 “코드 안 친” 작업의 결과물을 AI에 직접 코드 리뷰를 시켜 점수를 매겨봤다. 결과는 기술 완성도 85점, 명세 반영률 62.5%였다.

흥미로운 건 두 숫자가 같은 결과물을 보고도 전혀 다른 이야기를 했다는 점이다. 모달의 생명주기와 타입, 상태 관리, 테스트 구조는 꽤 단단했다. Jest 테스트 151개가 모두 통과했고, 6개 모달의 상태 정리도 빠진 곳이 없었다. 그런데 명세 40개를 코드와 하나씩 맞춰보니 실제로 반영된 건 25개였다. 구조는 프로덕션 수준이었지만, 카테고리 정책이나 직원의 담당 범위, 검색 필터처럼 기능의 의미를 결정하는 규칙 15개가 비어 있었다.

더 이상했던 건 AI가 이 누락을 몰랐던 것도 아니라는 점이다. 작업 보고서에는 카테고리, 담당자 표시, 저장 확인 같은 최우선 미완 항목이 이미 적혀 있었고, 실제 코드에서도 그대로 빠져 있었다. 스스로 간극을 발견하고 기록하는 데까지는 갔지만, 그 간극을 닫는 행동으로 연결하지는 못한 것이다. 기술적 게이트만으로는 잡히지 않는 종류의 실패였다.

사람은 결국 “무엇을”에 집중한다

시즌1에서 하네스를 “AI가 일하는 작업대”라고 불렀다. 이번 실패 뒤에는 그 작업대에 기능 검증을 위한 층을 하나 더 만들기 시작했다. 변경된 코드가 어느 정책에 닿는지 찾고, 연결된 테스트를 돌리며, 소스만 바뀌고 정책 문서가 따라오지 않으면 경고하는 구조를 품질 게이트에 넣었다. 아직 모든 프로젝트에서 실제로 굴러가는 단계는 아니고, 문서에 적히지 않은 암묵적인 규칙까지 자동으로 잡지도 못한다. 그래도 AI가 미완 항목을 보고서에만 남기고 지나가지 않도록 “무엇을 만족해야 끝인가”를 테스트와 연결하기 시작했다.

그 작업대가 단단해지니, 출근해서 봇을 먼저 켜는 건 내가 게을러져서가 아니라 그 작업대를 믿게 됐기 때문이 됐다. 이제 일을 “몇 줄을 쳤나”가 아니라 “무엇을 정확히 정의했나”로 다시 정의할 수 있게 됐다.

한편 이 작업대를 키우는 동안 또 다른 역설도 생겼다. 실패할 때마다 규칙과 훅, 에이전트를 하나씩 보태다 보니 어느 순간 하네스 자체가 모델이 먼저 통과해야 할 장애물이 됐다. 읽어야 할 지시와 도구가 많아질수록 컨텍스트와 토큰을 먼저 쓰고, 정작 중요한 것들은 희미해지는 것 같았다. 요즘은 그래서 모든 규칙들을 선두에서 주입하기보다 짧은 가이드만 넣어주고, 필요한 맥락들은 그때그때 꺼내 쓰며 모델이 판단할 여지를 남기는 쪽으로 흐름이 바뀌고 있다.

<출처: 작가, 제미나이로 생성>

당장 유행을 따라 지금까지 만든 하네스를 한꺼번에 걷어낼 생각은 없다. 시행착오 끝에 생긴 규칙들 중 반드시 지켜야 할 것은 코드와 테스트들로 단단히 남겨놓고, 겹치는 설명들이나 발전한 모델들이 몇 달 전에는 못했지만 지금은 충분히 잘하는 일들은 덜어내고 싶다.

경계는 단단하게, 경계 안에서는 자유롭게 모델을 두는 것이다. 이제 내가 고민할 하네스 엔지니어링은 무엇을 더 강제할지가 아니라, 어디까지 강제하고 어디서부터 모델을 믿을지에 가까워질 것 같다.

<출처: 작가>

바뀐 건 내 하루만이 아니었다. 얼마 전에는 내가 속하지 않은 다른 스쿼드의 기획자분이 Anvil을 통해 Slack DM만으로 신규 필드 추가를 시작해서, 영향 범위 분석부터 코드 수정, MR 생성, 배포 요청까지 한 흐름으로 밀고 갔다. 개발자가 한 명도 붙지 않은 채 상용까지 나간 첫 사례였다. 내가 만든 걸 내가 쓴 게 아니라, 내 손이 닿지 않는 곳에서 굴러간 거다.

개발자의 하루가 “코드부터”에서 “봇부터”로 바뀐 만큼, 비개발자가 일하는 방식은 또 어떻게 달라질까. 그게 솔직히 제일 궁금하고 제일 기대된다.

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

<참고>

이 하루를 가능하게 한 봇 ‘Anvil’의 토대는 velog 프롬프트 엔지니어링은 끝났다 — 하네스 엔지니어링으로 AI 에이전트를 길들인 이야기에 모아뒀다.
‘Anvil’의 실제 실행기는 여기어때 기술블로그의 개발자 없이 5분 만에 버그를 고친 QA, 우리가 설계한 것과 설계하지 않은 것에서 자세히 확인할 수 있다.
그 외에 하네스를 받치는 플러그인으로, 컨텍스트 상태를 실시간으로 보여주는 ‘HUD forge-glow’도 공개했다. Claude Code에 바로 붙일 수 있다(깃허브 저장소, 스타 환영).

]]>

AI-UX 포트폴리오 제작할 때 체크 포인트 7가지

지난 3~4년간 취업을 준비하는 학생들과 이직을 준비하는 실무자를 대상으로 AI 기반 UX 디자인 워크숍을 진행하며 포트폴리오 작업물을 함께 제작해 왔다. 그 과정에서 기존 UX 디자인 포트폴리오와는 다른 관점에서 신경 써야 할 몇 가지 요소를 발견했다.

AI-UX 디자인 워크숍 현장 사진 <출처: 작가>

물론 AI를 활용하든 안 하든 포트폴리오에서 기본적으로 지켜야 할 부분은 있다.

예를 들어, 이전 글 런던에서 만난 AI 시대 디자이너의 5가지 생존 전략에서 언급한 것처럼 AI로 인해 직무 간 경계가 무너지고 디자이너의 역할이 확장되고 있는데, 그럼에도 여전히 왜 이 제품을 만드는지, 사용자가 누구인지 등 근본적인 원칙에 집중해야 한다는 건 변함이 없다. 따라서 어떤 방법으로 리서치를 수행하고 데이터를 수집했는지, 그 데이터를 어떻게 분석해서 문제를 정의했는지, 그리고 어떤 과정을 거쳐 해결안을 도출했는지와 같은 논리적인 흐름은 AI를 활용한 프로젝트에서도 동일하게 유지되어야 한다.

그렇다면 AI 기반 UX 디자인 프로젝트에서는 무엇을 추가로 고려해야 하며, 이를 포트폴리오에는 어떻게 담아내야 할까? 이번 글에서는 AI를 활용한 UX 프로젝트를 소개할 때 특히 확인해야 할 일곱 가지 체크 포인트를, 워크샵 경험을 바탕으로 정리해 보았다.

AI x UX Design 포트폴리오 체크포인트 7가지

이 이미지는 AI-UX 디자인 워크숍에서 사용하는 포트폴리오 템플릿의 일부이다.

AI-UX 디자인 포트폴리오 템플릿 <출처: 작가>

템플릿은 앞서 설명한 것처럼 UX 디자인 프로젝트를 소개할 때 필요한 논리적인 흐름에 맞춰 구성되어 있다. 리서치부터 데이터 분석, 솔루션 도출, 검증까지의 과정에서 AI를 활용하면 어떤 내용이 추가될 수 있는지 하나씩 살펴보자.

체크 포인트 1. 명확한 AI 협업 프로세스 제시

첫 번째 체크 포인트는 AI와의 협업 프로세스를 명확하게 보여주는 것이다.

더블 다이아몬드 프로세스 <출처: 작가>

AI를 활용한다고 해서 문제를 정의하고 해결책을 도출하는 UX 디자인 프로세스의 큰 틀이 달라지는 것은 아니다. 다만 세부 단계는 조금씩 바뀐다.

예를 들어 기존에는 데스크 리서치나 사용자 리서치만으로 데이터를 수집했다면, AI를 적극 활용한 AI 페르소나 시뮬레이션이나 AI 인터뷰가 추가될 수 있다. 또는 데이터를 수집한 뒤 AI가 생성한 정보의 신뢰도를 검증하는 과정이 새롭게 포함될 수도 있다.

한편 와이어프레임 단계는 축소되고, 프로토타입을 반복적으로 수정/개선하는 단계에 더 많은 시간을 투자하는 경우도 있다.

프로세스 예시 <출처: 수강생 작업물>

이처럼 프로젝트마다 AI가 개입하는 지점이 달라질 수 있기 때문에, 프로젝트를 소개하기에 앞서 전체 작업 프로세스를 먼저 제시하는 것이 좋다. 예시 이미지처럼 프로젝트 초반에 프로세스를 시각화해 두면, 어떤 단계에서 AI를 활용했는지 한눈에 이해할 수 있다. 또한 해당 프로젝트가 단순히 AI를 사용한 것이 아니라, AI와 협업하는 방식까지 설계한 프로젝트라는 점을 효과적으로 전달할 수 있다.

체크 포인트 2. AI의 역할 및 사용 범위 제시(AI 사용자를 인간 사용자와 혼용하지 않기)

AI를 어느 단계에서, 어떤 역할로 활용했는지를 명확하게 설명하는 것도 중요하다. 아래 예시는 AI를 활용해 사용자 인터뷰를 진행한 과정을 담은 포트폴리오 페이지다.

AI 인터뷰 소개 페이지 <출처: 수강생 작업물>

왼쪽의 점선 표시를 보면 두 가지 방식으로 타깃 페르소나를 생성한 뒤, 이를 대상으로 AI 인터뷰를 진행했음을 확인할 수 있다.

A: 주요 타깃층의 특성을 반영해 생성한 AI 페르소나
B: 실제 인물을 기반으로 생성한 클론 AI 페르소나

같은 AI 인터뷰 과정이라도 AI를 일반적인 타깃 사용자의 특성을 반영한 페르소나 생성 도구로 활용했는지, 또는 실제 사용자를 1:1로 시뮬레이션하는 도구로 활용했는지에 따라 의미가 달라진다. 따라서 포트폴리오에서는 AI가 어떤 역할을 수행했는지 구체적으로 설명하는 것이 필요하다.

실제 사용자 대상 리서치 <출처: 수강생 작업물>

이 단계에서 가장 중요한 점은 AI 사용자를 실제 인간 사용자와 혼용하지 않는 것이다. AI가 특정 연령, 성별, 직업 등의 인구통계학적 특성이나 개인의 성격, 성향, 가치관을 반영하도록 설정할 수는 있다. 그러나 어디까지나 이는 특성을 기반으로 한 시뮬레이션일 뿐, 실제 사람의 복잡한 사고 과정이나 감정을 그대로 재현한다고 볼 수는 없다.

따라서 실제 사용자 리서치를 수행하지 않았다면, 포트폴리오에서도 AI 페르소나와 실제 사용자를 명확하게 구분해 표현하는 것이 바람직하다. 예시처럼 AI 기반 인터뷰와 실제 사용자 인터뷰를 구분해 표기하면, 프로젝트의 신뢰성을 높이는 동시에 AI의 활용 범위를 더욱 명확하게 전달할 수 있다.

체크 포인트 3. 어떤 AI를, 왜 사용했는지 설명

AI 도구의 종류가 빠르게 늘어나면서, 왜 특정 AI를 선택했는지 설명하는 것도 포트폴리오에서 중요한 요소가 되었다. 단순히 AI를 사용했다는 사실보다, 각 도구의 특성을 이해하고 목적에 맞게 선택했다는 점을 보여주는 것이 더 중요해진 것이다.

예를 들어 스카이스캐너는 국내 사용자와 해외 사용자가 모두 사용하는 서비스다. 국내 사용자와 해외 사용자의 페인 포인트를 각각 조사해 비교하려면, 활용하는 AI 도구도 달라질 수 있다.

구체적으로 국내 사용자 리뷰는 앱스토어에서 데이터를 수집한 뒤, 리스틀리(Listly)와 클로드(Claude)를 활용해 리뷰를 크롤링하고 분석*할 수 있다. 반면 해외 사용자 리뷰는 퍼플렉시티(Perplexity)에서 데이터 출처를 소셜로 설정하여 레딧(Reddit)에서 리뷰 데이터를 수집하고 분석하는 방식이 더 적합할 수 있다.

*자세한 내용은 AI로 생생한 사용자 의견 모을 ‘소셜 리스닝’하는 법의 2번 내용을 참고

소셜 리스닝에 사용된 AI <출처: 수강생 작업물>

동일한 데이터셋에 여러 AI를 함께 활용하는 방법도 있다. 예를 들어 같은 리뷰 데이터를 클로드와 GPT에 각각 분석하도록 한 뒤, 두 결과를 비교하여 공통적으로 도출되는 인사이트가 무엇인지 확인할 수 있다. 이렇게 하면 하나의 AI가 생성한 결과를 그대로 수용하기보다 교차 검증하는 과정까지 보여줄 수 있다.

프로토타이핑에 사용된 다양한 AI <출처: 수강생 작업물>

프로토타입을 생성할 때도 마찬가지다. Stitch AI, Motiff 등 다양한 AI 기반 프로토타이핑 도구를 사용할 수 있는 상황에서 왜 특정 도구의 결과물을 선택했는지를 설명하는 것이 좋다. 예시에서 볼 수 있듯, Stitch AI로는 스카이스캐너의 기존 디자인 스타일을 재현하는 데 어려움이 있었지만, Motiff는 기존 디자인 시스템과 시각적 톤을 비교적 잘 유지했다. 따라서 Motiff의 결과물을 초안으로 삼아 최종 결과물을 완성했다는 내용을 담았다.

이처럼 특정 AI를 선택한 이유, 또는 생성된 결과물 가운데 무엇을 선택했고 왜 그렇게 판단했는지를 명확하게 설명하면, AI를 무작정 사용한 것이 아니라 각 도구의 장단점을 이해하고 목적에 맞게 활용했다는 점을 효과적으로 전달할 수 있다. 이는 디자인 역량뿐 아니라 AI 활용 능력과 도구 선택에 대한 판단력까지 함께 보여주는 요소가 된다.

체크 포인트 4. 검증 절차 진행 여부 및 방식 제시

AI를 활용한 콘텐츠가 쏟아지며 이제 사람들은 어떤 콘텐츠를 보더라도 ‘사람이 직접 만든 게 맞을까?’, ‘사실 여부가 검증된 내용일까?’라는 의문을 갖게 되었다. 그만큼 AI를 활용하는 대부분의 작업에서는 생성된 결과를 검증하고 사실 여부를 확인하는 과정이 무엇보다 중요하다.

특히 UX 디자인은 리서치와 데이터에 기반한 분야인 만큼, 데이터의 정확성과 신뢰도가 프로젝트의 완성도를 좌우한다. 따라서 AI를 통해 리서치를 수행했다면 어떤 방식으로 리서치 결과를 검증했는지까지 함께 보여주는 것이 필요하다.

검증 절차 및 방법 설명 <출처: 수강생 작업물>

위 예시에서는 AI를 활용해 사용자 리뷰를 분석한 뒤, 실제 통계 자료와 원본 데이터를 다시 확인하는 과정을 거쳤다고 설명한다. 관련 통계 자료의 URL을 직접 확인하며 AI가 도출한 결과와 비교/검증했고, 이를 바탕으로 사용자가 실제로 서비스를 어떻게 이용하는지 이해했다고 덧붙였다. 이처럼 단순히 “AI가 이렇게 분석했다”에서 끝나는 것이 아니라 출처를 확인하고 데이터를 직접 검증했다는 과정을 명시하면 리서치 결과의 신뢰도를 더욱 높일 수 있다.

A/B 테스트 결과 검증 <출처: 수강생 작업물>

디자인 개선 과정에서도 AI를 활용할 수 있는데, 이때도 마찬가지로 검증 절차가 필요하다. 예를 들어 AI를 활용해 A/B 테스트의 가설을 도출했다면, 거기서 끝내는 것이 아니라 실제 사용자에게 투표를 받거나 사용성 테스트를 진행해 가설을 검증하는 과정을 함께 제시하는 것이 좋다.

예시에서는 실제 인간 사용자들에게 투표를 받을 수 있는 플러그인을 사용하여 직접 결과를 검증했고 이를 바탕으로 사용자가 선호하는 시안을 채택했다고 설명한다. 이처럼 AI는 가설을 빠르게 생성하는 도구로 활용하되, 최종 의사결정은 실제 데이터를 통해 검증했다는 점을 명확히 보여주면 프로젝트의 신뢰성과 의사결정의 설득력을 한층 높일 수 있다.

체크 포인트 5. 복합적인 근거 체계 필요

체크 포인트 5번은 간단히 말해, 하나의 근거에만 의존하여 문제를 정의하지 말라는 의미이다. 특히 리서치 단계에서 실제 사용자 인터뷰 없이 AI만으로 데이터를 수집했다면, 아무리 검증 절차를 거쳤더라도 결과의 신뢰성에는 한계가 있을 수 있다.

여러 가지 근거 제시 <출처: 수강생 작업물>

따라서 하나의 리서치 방법에만 의존하기보다, 여러 출처에서 수집한 근거를 종합해 문제를 정의했다는 점을 보여주는 것이 중요하다.

예를 들어 위 그림처럼 최근 시장 동향 분석, 경쟁 서비스 분석, 사용자 리뷰 분석 등 다양한 방법으로 데이터를 수집하고, 각각에서 도출한 A, B, C 근거를 종합해 사용자의 페인 포인트를 정의하는 방식이다.

AI 기반 사용자 시뮬레이션 <출처: 수강생 작업물>

AI를 활용한 사용자 시뮬레이션도 마찬가지다. AI 페르소나를 생성해 한 번만 인터뷰하는 것이 아니라, 서로 다른 페르소나와 다양한 시나리오를 반복적으로 시뮬레이션하며 결과를 비교하는 것이 좋다. 여러 관점과 상황을 반복해서 검토함으로써 사용자의 실제 니즈가 무엇인지, 핵심 페인 포인트가 무엇인지를 지속적으로 재확인하는 과정이 필요하다. 반복적인 시뮬레이션을 빠르게 수행할 수 있다는 점은 AI가 가진 대표적인 장점이기에 이를 적극적으로 활용하는 것이 좋다.

이때는 가능한 실제 사용자 리서치를 함께 진행하는 것이 가장 효과적이다. 앞서 체크 포인트 2에서 소개한 것처럼 AI 기반 리서치와 실제 사용자 인터뷰를 함께 활용하면, AI만으로 데이터를 수집하고 분석했을 때보다 훨씬 높은 신뢰도를 확보할 수 있다.

결국 중요한 것은 하나의 AI 리서치 결과만을 근거로 사용하는 것이 아니라, 여러 데이터와 인사이트를 통해 보다 탄탄한 근거 체계를 구축하는 것이다. 이러한 접근은 프로젝트의 논리성과 설득력을 높이는 것은 물론, AI 기반 리서치의 객관성을 유지하는 데에도 도움이 된다.

체크 포인트 6. AI 답변을 자신의 언어로 수정

이번에는 주의해야 할 점이다. AI를 사용하여 데이터를 분석하거나 인사이트를 도출한 후에, 그 내용을 그대로 복사하여 포트폴리오에 넣는 경우가 종종 있다. 혹은 직접 초안을 작성하였더라도 AI로 교정하거나 다듬는 과정에서 AI가 수정한 문장을 거의 그대로 사용하는 경우가 있다. 문제는 이러한 문장들이 AI가 작성한 티가 난다는 점이다.

AI 생성 답변을 그대로 활용한 결과 <출처: 수강생 작업물>

예시 이미지에서 표시한 부분을 보면 AI가 작성한 내용이라는 걸 쉽게 짐작할 수 있다. 특정 키워드를 강조하는 마크다운 강조 기호(**) 때문이다. 내용이 아무리 타당하더라도 이러한 표현이 반복되면, 독자는 글의 신뢰성을 의심하게 될 수 있다.

이 밖에도 AI가 작성한 글에서 자주 나타나는 특징이 있다. 제목이나 말머리에 이모지를 과도하게 사용하거나, 불필요한 위치에 쉼표를 반복해서 넣는 경우, 엠대시(—)를 지나치게 사용하는 경우, 또는 번역체처럼 어색한 문장과 어휘를 사용하는 경우다. 이런 표현이 눈에 띄면 포트폴리오 전체의 완성도와 전문성이 떨어져 보일 수 있다.

포트폴리오는 자신의 사고 과정과 문제 해결 능력을 보여주는 문서다. 따라서 AI는 아이디어를 정리하거나 초안을 다듬는 보조 도구로 활용하되, 최종 문장은 반드시 자신의 언어로 다시 작성하는 게 좋다. 특히 디자인 프로젝트는 많은 설명을 늘어놓기보다, 한두 문장으로 핵심을 명확하게 전달하는 것이 중요하다. 그러므로 포트폴리오에 들어가는 텍스트만큼은 직접 표현을 고민하고, 여러 차례 교정·교열을 거쳐 자신의 문체로 완성하는 것이 좋다.

체크 포인트 7. 피드백을 받을 때 비판적이고 객관적인 관점 요청

마지막 체크 포인트는 AI로부터 피드백을 받아 결과물을 개선하는 작업에 적용하는 것이다.

AI 활용 피드백 <출처: 수강생 작업물>

바로 이전 글 나만의 ‘UX/UI 디자인 피드백봇’ 만들기에서 소개했듯, 프롬프트를 통해 AI에 일반 사용자의 역할을 부여하고 피드백을 받아볼 수 있었다. 이처럼 일반 사용자 역할을 부여하는 대신, 전문가의 역할을 지정하고 그 관점에서 디자인 피드백을 받아보는 것도 가능하다.

이때 주의할 건, AI의 아첨이다. AI는 사용자의 의견에 지나치게 동조하거나 결과물을 긍정적으로 평가하는 경향이 있다. 이는 AI가 갖고 있는 일반적인 특징 중 하나이기도 하지만 특히 프로젝트를 진행하는 동안 같은 대화창에서 여러 차례 의견을 주고받았다면, 이전 대화의 맥락에 영향을 받아 객관적인 피드백을 제공하지 못할 가능성이 더욱 커진다.

따라서 최종 결과물을 검토할 때는 “장점을 칭찬하기보다 문제점을 중심으로 평가해줘”라든가 “비판적이고 객관적인 관점에서 개선해야 할 부분을 찾아줘”와 같이 평가 기준을 명확하게 제시하는 것이 좋다. 이렇게 해야 예시처럼 실제 디자인 개선에 도움이 되는 구체적이고 실질적인 피드백을 얻을 가능성이 높아진다.

마치며

이번 글에서는 AI 기반 UX 디자인 프로젝트를 포트폴리오에 담을 때 고려해야 할 일곱 가지 체크 포인트를 살펴보았다. 7가지 모두 기존 포트폴리오와는 달리, AI를 활용한 프로젝트의 신뢰성과 설득력을 높이기 위해 특히 신경 써야 할 요소들이다.

이제 AI를 활용하는 것 그 자체는 특별한 일이 아니다. 누구나 AI의 도움을 받아 작업할 수 있는 시대이다. 그러나 동시에 AI가 생성한 결과물에 대한 의심도 함께 커지고 있다. 그렇기 때문에 프로젝트에서 AI를 어떤 과정에 활용했는지, 왜 해당 도구를 선택했는지, 생성된 결과를 어떤 방식으로 검증했는지를 명확하게 설명하는 것이 무엇보다 중요하다. 이는 단순히 AI를 사용했다는 사실을 넘어, AI를 목적에 맞게 활용하고 결과를 비판적으로 검토할 수 있는 역량까지 보여주는 근거가 된다.

이 글을 읽고 있는 분들 가운데는 취업이나 이직을 위해 포트폴리오를 준비하는 사람도 있을 것이고, 반대로 포트폴리오를 검토해 채용 여부를 결정해야 하는 사람도 있을 것이다. 어떤 입장에 있든, 이번에 소개한 일곱 가지 체크 포인트를 기준으로 포트폴리오를 점검해 본다면 AI 시대에 더욱 설득력 있는 프로젝트를 만들고 평가하는 데 도움이 될 것이다.

]]>

내 사이트에 MS 클라리티를 달고 직접 관측해봤습니다

웹 분석 도구는 오랫동안 ‘집계’를 중심으로 발전해 왔습니다. 하루에 몇 명이 들어왔고 몇 퍼센트가 나갔는지를 숫자로 정리해 주는 방식이죠. 우리에게 익숙한 구글 애널리틱스(GA)가 바로 이런 도구입니다.

그런데 막상 페이지를 고쳐야 하는 입장이 되면, 이런 숫자만 들고는 손이 잘 움직이지 않습니다. 대시보드가 “이 페이지 이탈률이 높습니다”라고 알려 줘도, 그래서 어디를 어떻게 손봐야 하는지까지는 말해 주지 않기 때문입니다. 그러다 보면 자연스럽게 그다음 질문이 떠오릅니다. 사용자는 이 페이지에 들어와서 무엇을 하다가 나갔을까요?

이 질문에 답하지 못한 채 페이지를 고치면 결국 감으로 고치는 셈입니다. 그리고 감으로 고친 것은 나중에 효과를 따져 볼 방법도 마땅치 않습니다.

마이크로소프트 클라리티(Microsoft Clarity)는 이 구간을 채우는 무료 도구입니다. 이 글은 도구 소개에서 멈추지 않고, 제 사이트에 붙여 한 주를 관측하며 데이터를 잘못 읽을 뻔했던 지점들과 그 뒤에 세우게 된 기준까지 담았습니다.

미리 요점만 콕 집어보면?

마이크로소프트 클라리티는 기존 분석 도구가 답하지 못하는 “어떻게” 구간을 채우는 무료 도구로, 세션 레코딩·열 지도·스마트 이벤트를 제공합니다.
열 지도는 색보다 클릭 수 총합과 필터 상태를 먼저 확인하고, 세션은 길이보다 활성 시간과 AI 요약을 직접 검증하며, 관측 기간은 요일 기준 한 주기로 잡는 편이 결론이 덜 흔들렸습니다.
도구는 관측 장비이지 판독 장비가 아니며, 무료로 붙일 수 있는 도구일수록 그 데이터를 언제 믿을지에 대한 기준을 함께 세워 두는 편이 좋습니다.

마이크로소프트 클라리티란?

먼저 클라리티가 기존 분석 도구와 무엇이 다른지, 그리고 왜 무료로 쓸 수 있는지부터 살펴봅시다.

1) 집계가 답하지 못하는 구간

기존 분석 도구가 답하는 질문은 “얼마나”입니다. 방문자 수, 페이지뷰, 이탈률 같은 것들입니다. 반면 페이지를 개선하려는 사람이 궁금한 것은 “어떻게”에 가깝습니다. 어디까지 읽고 내려갔는지, 어떤 요소를 눌렀는지 말입니다.

클라리티는 이 “어떻게” 구간을 담당합니다. 즉, 기존 도구를 대체하는 물건이 아니라 비어 있던 칸을 채우는 도구에 가깝습니다.

2) 무료이고, 사이트가 느려지지 않습니다

체험 기간이나 유료 기능이 따로 있는 형태가 아니라 전체가 무료입니다. 수집된 데이터는 내 서버가 아니라 마이크로소프트 쪽에 저장되므로, 사용자가 늘어도 내 사이트가 느려지지 않습니다. 다만 무료에는 대가가 붙어 있는데, 이 부분은 마지막 절에서 다루겠습니다.

어떤 기능을 제공할까?

기능은 크게 셋입니다. 각각이 어떤 질문에 답하는 도구인지를 중심으로 살펴보겠습니다.

1) 세션 레코딩(session recording)

세션 레코딩은 사용자의 화면 조작을 영상처럼 재생해 줍니다. 마우스가 어디로 움직였고 어디에서 스크롤을 멈췄는지가 그대로 보입니다. 실시간 관찰도 되고, 녹화되므로 나중에 몰아서 볼 수도 있습니다.

2) 열 지도(heatmap)

열 지도는 여러 세션을 겹쳐 한 화면으로 요약해 줍니다. 클릭 지도는 클릭이 몰린 위치를, 스크롤 지도는 사용자가 어디까지 내려갔는지를, 주의 지도는 화면에 오래 머문 영역을 색으로 보여줍니다.

3) 스마트 이벤트(smart events)

스마트 이벤트는 같은 곳을 연타하는 rage click, 클릭되지 않는 요소를 누르는 dead click처럼 문제를 암시하는 행동을 자동으로 잡아 줍니다. 해당 세션만 걸러 볼 수 있고, 세션마다 AI 요약도 붙습니다.

설치와 첫 관측

설치는 짧게 끝나지만, 직후에 한 번 헤매게 되는 구간이 있어 함께 적었습니다.

1) 프로젝트 만들고 스크립트 넣기

프로젝트를 만들면 설치 방법을 고르는 화면이 나옵니다. 여러 방식 중 수동 설정이 단순합니다. 아래 스크립트를 문서의 `<head>`에 넣으면 됩니다. 구글 애널리틱스를 붙여 본 적이 있다면 익숙한 방식입니다.

<!-- 클라리티 추적 스크립트 -->
<script type="text/javascript">
  (function (c, l, a, r, i, t, y) {
    c[a] = c[a] || function () { (c[a].q = c[a].q || []).push(arguments) };
    t = l.createElement(r); t.async = 1;
    t.src = "https://www.clarity.ms/tag/" + i;
    y = l.getElementsByTagName(r)[0];
    y.parentNode.insertBefore(t, y);
  })(window, document, "clarity", "script", "YOUR_PROJECT_ID");
</script>

프레임워크를 쓰면 넣을 위치가 프로젝트마다 다릅니다. 저는 이 코드를 그대로 복사해 AI 에이전트에 넘기고 “프로젝트 구조에 맞게 삽입해 달라”고 요청했습니다.

2) 설치 직후에 겪은 일

여기서 저는 한 번 당황했던 부분이 있었는데요. 실시간 세션은 곧바로 잡혔지만 열 지도는 한동안 비어 있었습니다. 코드를 다시 확인하고 배포를 다시 걸어 보기도 했지만 설치는 정상이었고, 대부분의 기능이 활성화되기까지 두 시간 정도가 걸렸습니다. 실시간 세션이 잡히고 있다면 기다리는 편이 좋습니다.

직접 써보며 세운 기준

여기서부터가 이 글의 중심입니다. 기능을 아는 것과 그 데이터로 판단하는 것은 다른 일이었습니다.

1) 열 지도는 색보다 클릭 수 총합을 먼저 봅니다

열 지도가 위험한 이유는 비율을 색으로 환산해 보여주기 때문입니다. 비율은 분모가 작아도 계산됩니다. 세션이 열 건이든 만 건이든 화면 어딘가는 붉게 표시되고, 눈으로 보기에 두 화면은 똑같이 그럴듯합니다.

제 사이트의 클릭 지도가 그랬습니다. 한 주 동안 이 페이지는 98번 열렸고 클릭은 66번이었는데, 그 66번을 39개 요소가 나눠 가집니다.

<출처: 작가, Clarity 캡처>

1위는 ‘첫 레슨부터 시작’ 버튼으로 10.61%였습니다. 두 자리 퍼센트라 그럴듯하지만 실제 클릭 수는 7번입니다. 2위도 7번, 3위부터 5위는 나란히 3번(4.55%)입니다. 상위 다섯 개가 `7, 7, 3, 3, 3`이니 누군가 네 번만 더 눌러도 3위가 1위와 동률이 됩니다. 이런 분포에서 순위를 읽는 것은 의미가 없습니다.

그래서 저는 클릭 지도를 열면 색이나 순위보다 클릭 수 총합을 먼저 봅니다. 이 숫자가 두 자리에 머물면 순위는 읽지 않고 넘어갑니다. 퍼센트의 분모가 조회수(98)가 아니라 전체 클릭 수(66)이라는 점도 함께 봅니다. 어떤 버튼이 30%라고 해서 방문자의 30%가 눌렀다는 뜻이 아니고, 한 사람이 세 번 누르면 그 세 번이 모두 분자에 들어갑니다.

그래도 이 표본으로 읽을 수 있는 것은 있었습니다. 공들여 만든 소개 문구와 카드 영역에는 클릭이 거의 찍히지 않았고, 대신 사이드바 목차 항목들에 흩어져 찍혔습니다. 순위는 못 믿어도 “강조한 곳과 실제로 눌리는 곳이 다르다”는 방향성만큼은 보였습니다.

2) 필터가 걸렸는지부터 확인합니다

열 지도에는 기기, 유입 경로, 사용자 같은 필터가 있습니다. 무엇을 걸었느냐에 따라 같은 페이지가 전혀 다른 화면이 됩니다.

<출처: 작가, Clarity 캡처>

위는 같은 페이지의 스크롤 지도인데, 특정 사용자 한 명으로 필터를 건 상태라 표본이 4뷰입니다. 필터를 풀면 앞의 클릭 지도처럼 98뷰가 잡히니, 같은 페이지 같은 기간인데 표본이 스물네 배 차이 납니다. 어느 쪽이 맞고 틀린 문제가 아니라 서로 다른 질문에 답하고 있을 뿐입니다. 문제는 화면만 봐서는 필터 여부를 알아채기 어렵다는 점입니다. 그래서 열 지도를 근거로 인용할 때는 필터 상태를 함께 적어 둡니다.

주의 지도도 같은 필터로 본 화면입니다. 상단이 붉고 20% 아래 구간은 평균 소요 시간이 1초 미만이었습니다.

<출처: 작가, Clarity 캡처>

다만 체류가 길다는 사실만으로는 정독인지 혼란인지 구분되지 않습니다. 잘 쓰여서 오래 읽은 것일 수도, 어려워서 다시 읽은 것일 수도, 뭘 눌러야 할지 몰라 멈춰 있던 것일 수도 있습니다. 셋 다 같은 붉은색입니다. 주의 지도는 결론이 아니라 좌표에 가깝습니다.

3) 무슨 신호를 볼지는 사이트 규모가 정합니다

한 주 동안 쌓인 세션은 172건이었습니다. 이걸 앞에서부터 재생하는 것은 172번 중 몇 번이 걸리기를 기다리는 일에 가깝습니다. 그래서 레코딩을 목록이 아니라 검색으로 다뤘습니다. 가설을 세우고 해당하는 세션만 걸러서 봤습니다.

<출처: 작가, Claude로 생성>

퍼센트만 보면 네 가지 모두 지표처럼 보입니다. 그런데 세션 수로 바꾸면 절반은 쓸 수가 없습니다. rage click은 이름이 알려져 있어 먼저 찾게 되는 신호인데, 제 사이트 규모에서는 일주일에 1건이었습니다. 1건으로는 경향을 말할 수 없습니다. 반대로 dead click 41건과 빠른 뒤로 가기 48건은 들여다볼 만한 양입니다. 괄호 안은 한국어 화면의 표기입니다.

4) 세션은 길이순으로 정렬하지 않습니다

긴 세션부터 여는 것은 자연스러운 선택처럼 보이지만 그렇지 않았습니다. 아래는 12분 46초짜리 세션인데, 클라리티가 붙여 준 요약을 보면 01:20부터 12:45까지가 페이지가 숨겨진 상태였습니다. 실제로 화면을 보고 있던 시간은 1분 남짓입니다.

<출처: 작가, Clarity 캡처>

이 세션만의 특성이 아닙니다. 같은 기간 대시보드값이 총 시간 13.4분에 활성 시간 4.2분, 세 배 차이였습니다. 어느 쪽 숫자를 집었는지 확인하지 않으면 관심의 크기를 세 배로 부풀려 읽게 됩니다.

AI 요약도 결론이 아니라 좌표로 씁니다. 화면에 “인사이트는 AI를 통해 지원되므로 실수가 가능합니다”라고 적혀 있습니다. 위 세션도 요약이 00:38과 01:06에 문제가 있었다고 알려 주는데, 저는 그 판단을 믿는 대신 그 시점으로 건너뛰어 직접 확인합니다.

5) 관측 기간은 요일 한 주기로 잡습니다

며칠 치 데이터는 하루치를 여러 번 본 것에 가까울 수 있습니다. 트래픽은 요일에 따라 성격이 갈리기 때문입니다. 사흘 치로 판단하면 그 사흘의 성격에 결론이 끌려갑니다.

그래서 조회 구간을 날짜 수가 아니라 요일 기준으로 잡습니다. 이 글의 데이터도 일요일 오전부터 다음 일요일 오전까지 딱 7일입니다. 며칠을 봤느냐가 아니라 주중과 주말이 한 번씩 다 들어왔느냐를 기준으로 삼는 편이 결론이 덜 흔들렸습니다.

<출처: 작가, Clarity 캡처>

그 한 주 동안 쌓인 것이 세션 172건, 고유 사용자 104명이었습니다. 하루 평균 25건 안팎이라, 하루치만 떼면 어떤 지표든 몇 사람의 행동에 좌우되는 양입니다. 한 주를 채워야 세션당 페이지 수 4.12, 평균 스크롤 깊이 74.15% 같은 값을 판단 근거로 꺼낼 수 있었습니다.

6) 클라리티 단독으로는 결론이 나지 않습니다

클라리티는 페이지 안에서 벌어진 일을 잘 보여주는 대신, 그 사용자가 어디에서 왔는지에는 약합니다. 제 경우 짝으로 쓰는 도구는 비틀리입니다. 비틀리는 어떤 경로로 몇 명이 눌러서 들어왔는지를 보여주고, 클라리티는 그렇게 들어온 사람이 무엇을 했는지를 보여줍니다. 링크 바깥은 비틀리가 맡고 링크 안쪽은 클라리티가 맡는 셈입니다.

그래서 한쪽만으로는 답이 안 나옵니다. 비틀리에서 클릭이 많이 잡혀도 그 유입이 좋았는지는 알 수 없고, 클라리티에서 행동이 이상해 보여도 어느 경로로 도착했는지는 좁히기 어렵습니다.

다만 두 숫자를 나란히 놓고 비교하지는 않습니다. 비틀리는 링크 클릭을, 클라리티는 세션을 셉니다. 한 사람이 두 번 눌러도 한 세션으로 묶일 수 있고, 링크를 거치지 않고 들어온 사람은 비틀리에 잡히지 않습니다. 절대값을 맞추기보다 각 도구 안에서의 변화를 보는 편이 실용적입니다.

실무 적용과 주의할 점

마지막으로 도입 단계에서 확인할 것들을 정리해 보도록 하겠습니다.

1) 마스킹은 보안과 관측의 맞교환입니다

클라리티 이용약관에는 수집된 정보를 마이크로소프트가 활용할 수 있다는 조항이 있습니다. 금융이나 의료처럼 개인정보 민감도가 높은 서비스라면 그대로 도입하기 어려울 수 있습니다. 대신 특정 영역을 수집에서 제외하는 마스킹을 설정할 수 있습니다.

<!-- 이 영역은 레코딩에서 가려집니다 -->
<div data-clarity-mask="true">
  <span>{{ user.email }}</span>
  <span data-clarity-unmask="true">주문 상태: 배송 중</span>
</div>

여기서 판단이 필요합니다. 마스킹을 건 영역은 레코딩에서도 보이지 않습니다. 보안을 위해 가린 만큼 관측 능력을 잃는 셈입니다. 입력 폼을 통째로 가리면 개인정보는 지켜지지만 사용자가 어느 칸에서 멈췄는지도 함께 사라집니다. 그래서 저는 폼 단위가 아니라 값이 들어가는 요소 단위로 가립니다.

2) 도입을 미루는 편이 나은 경우

이 도구가 어울리지 않는 상황이 두 가지 있습니다. 하나는 앞서 이야기한 민감 정보 중심의 서비스이고, 다른 하나는 아직 트래픽이 충분히 쌓이지 않은 사이트입니다.

트래픽이 적은 경우가 조금 더 까다롭습니다. 설치해 두는 것 자체는 부담이 없지만, 데이터가 적은 상태에서 열 지도를 열면 오독의 위험만 커집니다. 판단 근거가 아니라 판단을 왜곡하는 화면이 되는 셈입니다. 설치는 해 두되, 일정 기준을 넘기기 전까지는 대시보드를 열지 않는 편이 낫습니다.

마치며

클라리티는 무료이고, 설치는 스크립트 하나를 넣는 것으로 끝나고, 화면은 직관적입니다. 도입 장벽이 낮다는 점에서 개인 프로젝트나 소규모 서비스에 잘 어울립니다.

다만 직접 운영해 보고 남은 감각은 조금 다릅니다. 이 도구가 준 것은 답이 아니라 질문이었습니다. 열 지도의 붉은 영역은 “여기가 문제다”라고 말해 주지 않습니다. “여기서 무언가 일어나고 있으니 확인해 보라”고 말할 뿐입니다.

여기 정리한 여섯 가지는 특별한 기법이 아닙니다. 데이터를 다룰 때 원래 지켜야 하는 것들에 가깝습니다. 그런데 행동 데이터는 화면이 직관적이라서 오히려 이 기본을 건너뛰게 만드는 힘이 있습니다. 숫자로 된 지표는 해석이 필요하다는 사실을 스스로 알려주지만, 붉게 물든 화면은 이미 해석이 끝난 것처럼 보이기 때문입니다.

도구는 관측 장비이지 판독 장비가 아닙니다. 무료로 붙일 수 있는 도구일수록, 그 데이터를 언제 믿을지에 대한 기준을 함께 세워 두는 편이 좋습니다.

*이 글은 AI의 도움을 받아 작성했습니다. (예제 코드 생성 및 교정/교열)

<참고>

]]>

Orca vs. Paseo vs. 순정: 에이전트 관리 도구 비교하기

Claude가 나은지 GPT가 나은지 따져 보는 게 세상 제일 중요하던 때가 있었습니다. 그러다 사용 경험을 가르는 변수가 모델에서 래퍼, 그러니까 에이전트를 감싸는 그 무언가로 내려왔습니다. Claude Code와 Codex 같은 것들이 대표적이죠. 이들을 비교하는 것 역시 매우 인기를 얻었는데요, 이제 26년 하반기 들어서는 그 비교가 좀 줄어든 느낌입니다. 하나 고를 것 없이 좋은 거 다 쓴다는 생각이 퍼졌거든요. 실제로 좀 쓴다는 사람들은 모델 하나를 고르는 대신 여러 계정과 여러 하네스를 구독해 두고 돌려 씁니다.

문제는 이 작업들이 여전히 터미널과 모델을 공급하는 회사의 제품에 묶여 있다는 점입니다. 게다가 세션 하나의 컨텍스트를 관리하는 것만으로도 머리가 아픈데 세션 여러 개가 오가는 걸 보고 있자니 피로가 말도 안 됩니다. 그래서 요즘 주목받는 도구가 Orca와 Paseo입니다.

‘에이전트를 몇 개 돌릴 수 있는가’에는 이미 한계가 없습니다. 할 수 있는 만큼 하는 거죠. 구독만 있으면 세션이야 얼마든지 늘릴 수 있으니까요. 지금의 한계선은 사람이 몇 개를 지켜볼 수 있느냐입니다. 그래서 이 글에서는 Orca와 Paseo가 무엇을 해결해 주는지 살펴보고, 터미널을 그대로 쓰는 ‘순정’과 견줘 언제 무엇을 고르면 좋을지 정리해 보려고 합니다.

왜 지금 이런 도구가 주목받을까?

<출처: 작가, Gemini로 생성>

‘실행’에서 ‘감독’으로

2026년 들어 중요한 건 “에이전트 여러 대를 동시에 어떻게 관리하나”입니다. 개인 개발자도 에이전트를 3~5개씩 같이 돌리기 시작했거든요.

에이전트가 코드를 쓰는 동안 사람이 하는 일은 지시를 내리고 검토 대기열을 관리하는 쪽입니다. 에이전트가 무엇을 할 수 있느냐보다 몇 개를 동시에 지시하고 리뷰할 수 있느냐가 문제입니다. 그러니까 사람이 병목인 거죠. 그래서 그 사람이란 병목을 조금이나마 줄여보고자 감독을 잘하기 위한 장비들이 필요해졌습니다.

하네스가 앱으로 나와도 남는 한계

물론 코딩 에이전트를 만드는 회사들도 이를 잘 알고 있습니다. 그래서 Claude Code와 Codex도 이제 터미널에서만 쓸 수 있는 물건이 아닙니다. 데스크톱 앱과 웹, 여러 기능이 생기면서 편의성은 분명 올라갔죠. 그런데 여러 세션을 나란히 놓고 감독하는 화면은 여전히 없습니다. 어느 세션이 멈춰 있는지 한눈에 알 수 없다는 것, 이게 여러 대를 돌릴 때 사람 시간을 가장 많이 잡아먹는 지점인데 말이죠.

계정 쪽도 비슷합니다. 구독 계정을 바꾸려면 매번 다시 로그인해야 하는 데다, 지금 이 계정에 사용량이 얼마나 남았는지 한눈에 들어오는 대시보드가 없으니 감으로 관리해야 합니다. 컴퓨터 앞을 떠나는 순간 작업 접근이 끊기는 것도 문제예요. SSH나 모바일 터미널로 우회할 수는 있지만 폰 화면에서 터미널을 조작하기엔 엄청 불편합니다.

새 도구들이 보여준 기능 4가지

5개월 전 제가 오케스트레이터 도구들을 다룰 때 기준으로 삼았던 격리·가시성·리뷰는 이제 이 카테고리의 기본기가 됐습니다. 지금 주목 받는 도구, Orca와 Paseo는 그 위에 더 많은 걸 구현했습니다.

첫째, GUI가 들어왔습니다. 보기 좋은 게 최고입니다. 이제 워크트리 여러 개를 눈으로 보면서 각각에 에이전트를 붙일 수 있습니다. 뭐가 달라졌는지 확인한 다음 각각 코멘트를 달아 그대로 에이전트에 되돌리기도 하죠. 실제 창을 띄워 UI 요소를 클릭하면 그 HTML/CSS가 프롬프트로 들어가기까지 합니다.

둘째, 계정과 쿼터 관리가 훨씬 쉽습니다. Orca는 상태바에 현재 사용량과 한도 리셋 시점을 띄워둡니다. 무엇보다 다시 로그인할 필요 없이 계정을 바꿔줍니다. 2026년 들어 사용 한도 압박이 커지면서 개인 구독과 회사 구독을 같이 쓰는 사람이 늘었는데요, 그때마다 다시 로그인하는 게 일이었거든요.

셋째, ‘오케스트레이션’을 지원합니다. 약간 뜻이 다르긴 합니다. Orca에서는 한 작업을 여러 에이전트에 동시에 던져 결과를 비교하고 더 나은 걸 채택하는 일을 뜻합니다. 반면 Paseo에서는 한 사람이 여러 세션을 어디서든 조종하는 일을 뜻하고요. 어쨌든 ‘여러 에이전트’를 다루는 게 훨씬 쉬워졌습니다.

넷째, 핸드폰으로 쓰기 좋아졌습니다. 에이전트가 한 번 돌기 시작하면 수 분에서 수십 분이 걸립니다. 원래라면 언제 끝나나 싶어서 컴퓨터 앞을 서성여야 했죠. 그래서 원격 접근과 모바일 지원이 또 들어왔습니다.

보기만 해도 훨씬 좋아 보이죠. 이제 본격적으로 두 가지 핫한 도구가 왜 그리 유명한지 보겠습니다.

Orca: ‘감독’ 능력 최적화

Orca는 에이전트 여러 대를 한 화면에서 보기 쉽게 해주는 로컬 설치형 에이전트 전용 개발 환경(ADE, Agent Development Environment)입니다. 랜딩 페이지 문구인 “Ship 100x With The Agent IDE”만 봐도 뭘 원하는지 바로 알겠습니다. 에디터와 터미널, 브라우저, GitHub·Linear 이슈까지 개발에 쓰던 화면을 앱 하나로 흡수한 쪽입니다. 즉, 감독으로 일하기에 가장 좋습니다.

스펙은 이렇습니다. macOS·Windows·Linux 환경을 지원하고요, Claude Code·Codex·Gemini·Cursor 등 지원 에이전트는 25~30개에 이릅니다. 도구는 무료이고 모델 비용은 내 구독과 API 키에서 나갑니다.

orca

무엇을 해줄까?

병렬 워크트리: 격리된 git 워크트리를 여러 개 띄우고 각각에 에이전트를 붙입니다. 쉬운 말로, 에이전트 여럿이 일하기 제일 좋은 환경으로 만들어 줍니다.
디자인 모드(Design Mode): 각 작업대마다 눈에 보이는 화면이 뜹니다. 화면에서 UI 요소를 클릭하면 그 HTML/CSS가 프롬프트로 주입됩니다. 말로 설명하기 힘든 시각 요소를 가리키는 커서가 생기는 셈이죠.
계정 바꾸기와 한도 대시보드: Claude·Codex 계정을 재로그인 없이 바꾸고 상태바에서 현재 사용량과 한도 리셋 시점을 확인합니다.
인라인 코멘트: 변경 사항 비교에 마크다운 주석을 달면 그대로 에이전트에 되돌아갑니다.
SSH 원격 워크트리: 성능 좋은 원격 머신에서 돌리면서 파일 편집, git, 터미널을 쓰기 좋습니다.

여기에 한 작업을 여러 에이전트에 시켜보고 결과를 비교하는 /orchestrate 명령, PR과 이슈를 앱 안에서 열어 볼 수 있는 GitHub·Linear 연동도 지원합니다. iOS와 Android 앱도 있는데, 엄청 많은 일을 하기보다는 라이브 모니터링용 보조 화면이라고 보는 게 좋습니다.

장점과 아쉬운 점

장점

“GUI라서 되는 일”의 대부분이 이 앱 안에 들어 있습니다. 특히 브라우저에서 요소를 집어 지시하는 디자인 모드가 프론트엔드 작업에서 체감이 정말 크다는 리뷰들이 많이 보였습니다. 계정 관리도 편하고 GitHub 연동은 말해 무엇 하고 아무튼 장점이 많습니다.

단점

아쉬운 점은 그걸 만드느라 좀 무겁다는 겁니다. 앱 하나가 통째로 새 개발 환경이라 에디터, 터미널, 브라우저를 다 Orca 기준으로 갈아타야 합니다. 그만큼 학습과 연동이 어렵습니다. 기존 설정에 손때가 묻은 사람일수록 옮길 마음을 먹기가 어렵죠. 기능이 많아 화면 자체도 무겁습니다. 그러니 워크트리를 1~2개만 쓰는 사람에게는 과잉으로 보입니다.

이런 상황에 추천합니다

에이전트를 최소 3~5개 이상 돌리며 쉬지 않고 리뷰해야 하는 사람에게 가장 잘 맞습니다. 혹은 브라우저에서 요소를 하나하나 뜯어 고치는 일이 잦은 프론트엔드 작업이라면 디자인 모드 하나만으로도 도입할 이유가 있어 보이고요. 개인과 회사 구독을 둘 이상 두고 쓰는 사람, 노트북 성능은 별로인데 빌드가 무거워 원격 환경에서 돌려야 하는 사람에게도 값을 합니다.

반대로 말하면 터미널 세션 하나로 충분한 사람이 여기서 얻을 것은 많지 않습니다.

Paseo: 어디서든 ‘감독’할 수 있는 도구

Paseo는 어디서든 쉽게 에이전트를 돌리는 데 최적화되어 있습니다. 스스로를 “내 머신과 폰, 데스크톱, CLI에서 코딩 에이전트를 돌리는 독립 오픈소스 프로젝트”라고 소개할 만큼요.

애초에 이걸 만든 개발자가 2025년 9월 산책하면서도 에이전트에 명령을 내리고 싶어 만든 음성 인터페이스가 출발이라고 합니다. 제품명 paseo부터가 스페인어로 ‘산책’이라는 뜻이죠. 자전거를 타면서 폰으로 확인했다는 사람, 공원 벤치에서 작업을 이어갔다는 사람, 아이들과 시간을 보내면서 개발한다는 사람들의 후기가 올라와 있습니다. 낡은 태블릿에서도 돌아갈 만큼 가볍기도 하대요.

스펙은 이렇습니다. 공식으로 지원하는 최적화 에이전트는 일단 Claude Code·Codex·Copilot·OpenCode·Pi 5종입니다. macOS, Linux에서 돌고 클라이언트는 데스크톱, 웹, iOS, Android, CLI고요. 마찬가지로 도구는 무료, 모델 비용은 직접 부담해야 합니다.

paseo

무엇을 해줄까?

어디서든 에이전트 돌리기: macOS 네이티브 데스크톱, 웹, iOS/Android 앱, CLI가 모두 세션 하나를 조종할 수 있습니다. 클라이언트마다 격차도 작아 폰에서도 데스크톱과 거의 같은 구조로 일을 줍니다.
집 밖 접속 경로 3가지: 종단간 암호화 릴레이(“Paseo는 트래픽을 읽을 수 없다”고 합니다), Tailscale·Cloudflare Tunnel 같은 자체 터널, 포트 직접 노출 중에 고릅니다.
음성 지시: 프로젝트의 시작인 만큼 편리합니다. 기본은 기기 로컬 환경에서 처리하는데, 전사·TTS 품질이 필요하면 OpenAI 음성 공급자를 연결합니다.
리뷰부터 머지까지: 브랜치 생성, 브라우저 프리뷰, 인라인 diff 리뷰, 커밋/PR/머지를 Paseo 안에서 끝낼 수 있습니다. git 워크트리 격리도 됩니다.

팀 단위로 쓸 일이 있다면 GitHub, Slack, Discord 트리거로 접근을 붙이는 Hub 기능이 있습니다. 프라이버시 설계도 좋아 코드가 샐 일이 적어 보입니다.

장점과 아쉬운 점

장점

아주 뚜렷합니다. 접근성이죠. 에이전트가 10~30분씩 도는 동안 컴퓨터 앞에 붙어 있을 이유가 사라집니다. 세션 수를 늘려주기보다 세션에 접근하는 방법을 늘려주는 도구거든요. 폰에서 지시하다가 책상에 돌아오면 데스크톱 클라이언트가 같은 세션을 그대로 이어받습니다.

단점

먼저 눈에 띄는 건 계정·쿼터 관리 기능이 없다는 점입니다. 구독을 여러 개 두고 쓰는 사람에게는 Orca 쪽이 낫습니다. GUI 화면도 호불호는 있습니다. 깔끔하다는 사람도, 그냥 기본 수준이라는 사람도 있죠. 게다가 핸드폰 화면에서 diff를 읽는 일처럼 그 자체의 한계는 없애주지 못합니다. 그래서 정밀 리뷰에는 약합니다.

이런 상황에 추천합니다

어디서든 에이전트를 쓰고 싶은 사람에게 먼저 권합니다. 개발 서버나 VM, 홈서버에서 에이전트를 돌리고 노트북과 폰으로 확인·지시만 하고 싶은 구성에도 맞습니다. 즉, 세션 수보다 접근성이 문제인 사람, 여러 세션을 ‘한 사람이’ 이어서 관리해야 하는 사람을 위한 도구입니다.

Orca vs. Paseo vs. 순정, 어떻게 고를까

<출처: 작가, Gemini로 생성>

1단계: Orca/Paseo vs. 순정

순정, 그러니까 Claude Code나 Codex를 원래 방식대로 터미널에서 쓰는 쪽부터 봐야 합니다. 워크트리 1~2개, 하루 한두 세션에 집중하는 쪽이라면 순정이 나아 보입니다. 애초에 도구를 들여서 얻는 이득이 사실상 없고, 하네스의 새 기능을 지연 없이 받는 이점이 더 크기 때문입니다. 래퍼가 업데이트를 따라오길 기다릴 일도 없고요. 하네스 자체가 데스크톱 앱과 웹으로 나오면서 기본 편의성이 꽤 올라가기도 했고요.

그러다가 아, 도저히 이거 에이전트가 쏟아내는 텍스트를 못 따라가겠다 싶은 순간이 오면 다음 단계입니다.

2단계: Orca vs. Paseo

대략 어떤 목적이 제일 땡기는지 보는 게 좋아 보입니다.

Orca가 좋을 때

같은 작업을 여러 에이전트에 붙여 더 나은 걸 고르고 싶다
구독 계정을 여러 개 두고 엄청 오가면서 쓴다
프론트엔드 보고 고치는 일이 잦다

Paseo가 좋을 때

서로 다른 작업 여러 개를 이동 중에도 이어가고 싶다
(물론 완벽하진 않지만) 코드가 내 인프라 밖으로 나가면 안 된다

결정에 필요한 것만 담은 비교표

마치며

다행히 Orca와 Paseo 모두 무료 오픈소스이고 이미 가진 구독 계정으로 바로 쓸 수 있습니다. 일단 깔아보고 정말 이게 필요한지 봐도 괜찮습니다. 며칠 써 보고 아니다 싶으면 지우면 그만이니까요.

사실 저조차도 이 두 가지 도구가 여기저기서 인기가 좋길래 찾아보기 시작했습니다. 그러다 보니 얼른 도입해야 하나 마음이 급했는데요. 하지만 정작 알아보고 나니 왜 이 도구가 뜨는지를 보는 게 더 중요하다고 생각했습니다. 결국, ‘에이전트 감독’이라는 역할이 도구가 핫해질 만큼 필요해졌다는 겁니다. 그러니 오늘 다룬 도구 두 개는 사실 이제 시작에 가까울 겁니다. 더 많은 게 쏟아질 거라고 봅니다.

그렇다면 이런저런 도구에 휩쓸리기보다 더 중요한 건, 내가 이것들을 ‘감독해 만든 성과’를 파악하는 힘은 아닐까요?

]]>

모두가 AI 네이티브한다고 하지만, ‘진짜’는 아직 없다

‘AI 네이티브 기업’, 아직 없습니다. 그리고 당분간 생겨나기도 어려울 거라고 생각합니다.

그 이유 중 하나는 바로 ‘업력’입니다. 50년 된 기업에는 50년치 결정들이 켜켜이 쌓여서 그 회사의 운영 방식 자체로 굳어버리게 되죠. 이건 쉽게 다시 쓸 수 있는 게 아닙니다.

그런데 이것조차 표면적인 이유일지도 모릅니다. 어쩌면, 더 근본적인 문제는 바로 기업이 나름의 내부적인 물리 법칙이 작동하는 생태계이고, 그 법칙은 “AI 한번 해봅시다”는 의지 하나로 바뀌지 않는다는 것에 있을 겁니다.

밖에서 보면, 대기업이라는 건 고객, 경쟁자, 수익률에 반응하는 하나의 단일한 조직처럼 보이기도 하지만, 그건 반쪽짜리 관찰에 불과해요. 나머지 절반에는 전혀 다른 논리로 돌아가는 내부 경제 구조가 있습니다.

기업은 ‘돈’을 쓰는 게 아니라 ‘예산’을 씁니다. 예산은 분기별로 나눠지고, 인원수와 FTE(풀타임 환산 인원) 단위로 계산되고, 서로 이해관계가 다른 부서들 사이에 배분되고, 그 구조 위에서 모든 활동이 조직됩니다. 정보는 권력이 되고, 많은 경우에 그 정보를 혼자 쥐고 있는 것이 합리적인 선택으로 보이게 됩니다. 부서마다 자기 영역이 생기고, 그 영역을 지키려고 합니다. 그리고 윗사람을 잘 관리하는 것 자체가 하나의 전문 역량이 됩니다.

모든 조직은 결국 어떤 균형 상태에 도달하고, 그 균형은 변화에 저항합니다. 그 상태가 바로 내부 구성원들이 수십 년에 걸쳐 최적화해온 결과물이기 때문이죠.

똑같은 숫자가 담긴 발표자료가, 어떤 방에서는 박수를 받고 다른 방에서는 싸늘한 반응을 얻는 이유가 바로 여기에 있습니다. 이건 조직의 ‘병리’가 아니라, 오히려 기업의 ‘본질’에 가깝다고 할 수 있습니다. 외부에서는 일사불란한 하나의 조직처럼 보이지만, 그 내부는 각자의 방향으로 움직이고, 영역을 지키고, 협상하고, 살아남으려는 수많은 집단들로 이루어져 있습니다.

“AI 네이티브 혁신”을 다루는 글들 대부분이 이 현실을 무시하기 쉽습니다. 목적지가 어디고, 어디에 도달해야 하는지만 이야기할 뿐이고, 그 여정이 조직이라는 이 거대한 건물을 떠받치고 있는 콘크리트 벽과 기둥을 통과해야 한다는 사실은 간과하는 것이죠.

AI ‘IN’ the business vs. AI ‘ON’ the business

AI를 기업에 적용하는 방식에는 크게 두 가지가 있습니다.

하나는 ‘AI in the business’인데, 이건 제품을 더 잘 만들고, 서비스를 더 효율적으로 제공하고, 고객을 더 잘 응대하는 데 AI를 쓰는 겁니다. 쉽게 말해서 회사가 시장에 내놓는 것들을 더 잘 만들어내는 과정에 AI를 끌어들이는 거죠.

다른 하나는 ‘AI on the business’입니다. 이건 회사 자체가 돌아가는 방식을 어떻게 AI로 혁신할 거냐에 관한 건데요. 누가 무엇을 결정하는지, 예산이 어디로 흘러가는지, 정보가 어떻게 조직의 상부로 올라가는지, 그리고 공식 조직도와 실제 의사결정 구조가 얼마나 다른지, 바로 그 조직의 운영 자체에 AI가 개입하는 거죠.

10명짜리 작은 스타트업에서는 이 두 가지가 구분이 잘 되지 않습니다. 창업자가 직접 코드를 짜면서 동시에 방향도 결정하고 회계 장부도 보죠. 회사 안에서 일어나는 모든 일을 모두가 알고 있습니다.

그런데 5만 명짜리 대기업에서는 이야기가 완전히 달라집니다. 어떤 은행은 최신 AI 사기 탐지 시스템을 출시하면서도, 정작 분기별 계획은 임원 비서들이 이메일로 주고받는 슬라이드로 만들고 커뮤니케이션을 할 수도 있습니다. 어떤 제조사는 창고 물류에 컴퓨터 비전 기술을 도입했으면서도, 인력 예산은 회계연도 초에 FTE 단위로 결정해버리는 방식을 그대로 쓸 수도 있고요. 즉, 파는 제품은 AI 네이티브인데, 회사 자체는 여전히 AI 이전 시대의 방식으로 굴러가고 있을 가능성이 충분히 있다는 겁니다. 겉은 바뀌었는데 속은 그대로인 거죠.

지금 대부분의 기업들이 하는 AI 작업은 이 첫 번째, 즉 ‘AI in the business’에 거의 집중되어 있고, 정작 두 번째인 ‘AI on the business’, 조직 자체가 돌아가는 방식에는 손을 거의 대지 않거나 못하고 있습니다. 수십 년 전에 만들어진 시스템, 몸에 밴 관행, 오래된 의사결정 구조들이 여전히 그대로 살아 있는 거예요.

그래서, 기업에서 던져볼 만한 진짜 질문은 이겁니다. 제품을 바꾸는 것과 조직 자체를 바꾸는 것, 이 두 가지를 어떻게 동시에 해낼 수 있을까요?

AI가 조직 안에서 제대로 작동하려면, 조직의 운영 방식 자체가 AI도 이해하고 따라갈 수 있는 형태로 바뀌어야 합니다. 그런데 문제는, 기업이라는 곳에서는 자기가 아는 것을 굳이 드러내지 않는 게 개인에게 오히려 합리적인 선택인 경우가 많다는 겁니다. 앞선 에피소드에서 이야기했던 바로 그 문제입니다.

그리고, 진짜 거친 싸움이 시작되는 게 바로 그곳이죠.

AI 에이전트는 왜 조직의 숨겨진 권력 구조에 부딪히는가

모든 조직에는 두 개의 지도가 있습니다. 하나는 벽에 붙어 있는 공식 조직도이고, 다른 하나는 실제로 일이 돌아가는 방식입니다. 그리고 대부분의 경우에 이 두 가지는 꽤 많이 다르죠.

사람은 이 두 번째 지도를 본능적으로 찾아냅니다. 메타의 앤드루 보스워스(Andrew Bosworth)는 이걸 체계적인 방법으로 정리했습니다. 새 팀에 합류하면 팀원 한 명 한 명과 30분씩 면담을 합니다. 25분은 “제가 알아야 할 것들을 다 얘기해 주세요”, 3분은 “지금 팀의 가장 큰 문제가 뭔가요”, 마지막 2분은 “또 누구를 만나봐야 할까요”라고 묻습니다. 새로운 이름이 나오지 않을 때까지 그 이름들을 찾아가 똑같이 반복한다고 해요.

이렇게 일주일을 하면, 공식적인 조직도 뒤에 숨어 있는 진짜 조직 지형이 머릿속에 그려진대요. 그리고 능력 있는 신임 임원들은 거의 다 이런 방식을 쓴다고 하고요. 거창하게 이름을 붙이지 않을 뿐이고, 그냥 “적응 기간”이라고 부를 뿐인 이 방식, 꽤 효과가 있다고 합니다.

그런데, AI 에이전트는 이런 방식을 통해서라도 조직의 두 번째 지도를 찾아낼 방법이 없죠.

에이전트는 어딘가에 기록된 것만 읽을 수 있습니다. 경리팀 비용 처리 기준이 담당자 머릿속에만 있다면, 에이전트는 그걸 쓸 방법이 없습니다. 실제 결재를 받으려면 조직도에 나오지 않는 세 사람을 거쳐야 한다면, 에이전트는 조직도에 나온 사람한테만 요청을 보내다가 일을 막아버리게 될 겁니다.

사람이라면 담당자에게 한 번만 물어보면 되지만, 에이전트는 그럴 수가 없습니다. 업무가 돌아갈 때마다, 팀이 바뀔 때마다, 예외 상황이 생길 때마다 매번 그 정보가 필요합니다. 담당자는 한 명인데 에이전트는 수백 개입니다. 결국 에이전트가 제대로 돌아가려면, 조직이 오랫동안 알고 있었지만 굳이 적어두지 않았던 모든 것을 문서로 만들어야 합니다.

그리고 바로 이 순간, 기술의 도입 문제가 조직 내의 권력 문제로 바뀌게 됩니다.

사람이 파악한 조직의 실제 운영 방식은, 그 사람의 머릿속에만 있습니다. 그런데 그것을 에이전트가 쓸 수 있는 문서로 만드는 순간, 상황이 완전히 달라집니다. 담당자만 알고 있던 비용 처리 기준이 누구나 볼 수 있는 정보가 되죠. 실제로는 세 단계를 거쳐야 하는 결재 과정이 공식적으로 드러나고요. 모두가 알면서도 아무도 입 밖에 내지 않던 것들, 특정 거래처에만 적용되는 가격 예외, 관행적으로 처리해온 인보이스 방식, 벤더와의 특약 같은 것들이 에이전트가 읽고 감사인이 들여다볼 수 있는 문서로 남게 된다는 겁니다.

스타트업에서는 이 과정이 상대적으로 수월하겠죠, 아직 그런 담당자가 없기가 쉬울 테니까요. 반면에, 업력이 긴 대기업은 그런 사람들로 가득 차 있습니다. 그들이 나쁜 사람이라는 게 아닙니다. 자신만 아는 정보가 곧 자신의 자리를 지켜주는 조직 안에서, 그냥 합리적으로 행동하고 있는 것뿐입니다.

그런 차이 때문에, 스타트업의 경우에는 아래 표의 L2 수준에까지 상당히 빠르게 도달할 수 있는 반면에, 대기업에서는 그 과정이 너무도 지난한 여정이 되는 상황이 발생합니다.

조직의 AI 성숙도 6단계 (L0~L5) <출처: 튜링포스트>

그러니 AI 도입 과정에서 만나게 되는 저항의 상당 부분은, 기술을 몰라서가 아닙니다. 모든 것이 투명하게 드러나면 지금의 힘의 균형이 깨진다는 것을 사람들이 몸으로 알고 있기 때문인 경우가 오히려 훨씬 더 많습니다.

섀도우 IT, 섀도우 AI, 그리고 섀도우 조직

겉으로 보이는 조직과 실제로 돌아가는 조직은 다릅니다. 그 간극의 절반은 사람들 머릿속에 있고, 나머지 절반은 섀도우 IT 안에 있습니다.

공식적으로 도입한 시스템이 현실을 따라가지 못할 때, 사람들은 기다리지 않고 알아서 방법을 찾습니다. 개발자는 개인 노트북에서 스크립트를 돌리고, 재무팀은 회사 ERP 대신 자기 스프레드시트에 진짜 숫자를 관리하고, 영업 담당자는 회사 CRM 대신 자기가 찾아낸 도구에 실제 영업 현황을 기록합니다. 회사 입장에서는 공식 시스템이 잘 돌아가는 것처럼 보이지만, 실제 업무, 진짜 일은 공식 시스템의 경계 바깥에서 이루어지고 있는 겁니다.

이런 현상을 두고 직원들이 규정을 어기는 문제, 즉 거버넌스의 실패로 규정하는 경우가 많죠. 완전히 틀린 이야기는 아니지만, 이건 대체로 대기업 안에서 실제로 일해본 적 없는 사람들의 시각이기가 쉽습니다.

섀도우 IT는 문제가 아니라 신호거든요. 공식 시스템이 어느 지점에서 현실을 감당하지 못하는지를 정확히 가리키는 지표예요. 그러니까, “섀도우 IT를 어떻게 없앨 것인가”는 처음부터 잘못된 질문입니다. 억누를수록 더 보이지 않는 곳으로 숨어들 뿐이고, 결국 통제는 더 어려워집니다. 올바른 질문은, 어떻게 하면 공식 경로를 섀도우 경로보다 더 빠르고 쓰기 편하게 만들 수 있는가 하는 데서 시작합니다.

지금, AI의 도입 과정에서도 똑같은 일이 벌어지고 있습니다. 회사가 AI 툴 하나를 공식적으로 도입하려면 구매 승인 절차만 몇 달이 걸리는데, 당장 이번 주 안에 분석을 끝내야 하는 직원 입장에서는 개인 계정으로 챗GPT를 열고 회사 문서를 올리는 게 가장 현실적인 선택이죠. 회사의 공식 AI 전략이라는 게 실행 계획도 없이 보고서 한 장으로 끝나 있으니, 중간 관리자는 기다리는 대신 혼자서 클로드(Claude)로 업무 자동화 도구를 만들어 씁니다. 공식 승인을 기다리다가는 언제 될지 모른다 싶은 팀장은 아무 말 없이 에이전트를 실제 운영 데이터베이스에 연결해 버릴 수도 있죠. 지금 이 순간 회사 내부에서 아무도 모르게 돌아가고 있는 ‘비공식 AI’가 얼마나 되는지 정확히 아는 사람, 아마 없을 겁니다.

이게 바로 섀도우 AI입니다. 아마, 수많은 조직에 이미 많이 퍼져 있을 겁니다. 이걸 막겠다는 건, 계획이라기보다는 망상에 가깝습니다.

섀도우 AI가 생겨나는 이유, 그리고 그것을 막는 방법

이런 ‘섀도우 AI’가 생겨나는 이유는 단순합니다. 간단하게 이야기해서, 회사가 공식적으로 제공하는 AI 환경이 너무 느리고 불편하기 때문이에요. 따라서, 해결책도 단순합니다. 회사가 직접 제대로 된 환경을 만들어주면 됩니다. 말은 쉽지만, 실제로 해야 할 일의 목록은 엄청나죠.

그렇지만, 잘 정리해서 크게 보면 세 가지입니다. 무엇을 표준화할 것인가, 그 표준화 기준 아래에 무엇을 갖춰야 하는가, 그리고 문제가 생겼을 때 어떻게 대응할 것인가.

1. 표준화

먼저 표준화입니다. 플랫폼을 하나든, 두 개든, 골라서 밀어붙이세요. 클로드든, GPT든, 제미나이(Gemini)든, 각각 장단점이 있지만 어느 하나가 압도적으로 뛰어난 것도 아니고, 승자가 가려질 때까지 기다릴 이유도 없습니다. 중요한 건 조직 전체가 “우리는 이걸 씁니다, 이게 회사 공식 툴입니다, 교육자료와 문서는 여기 있습니다”라고 말할 수 있는 상태를 만드는 겁니다. 쓰는 툴이 사람마다 다 다른 회사는 사실상 아무 툴도 없는 것과 같습니다.

플랫폼을 골랐다면 그 위에 올라가는 것들도 관리해야 합니다. 스킬, 에이전트, 내부 시스템에 연결하는 MCP(Model Context Protocol) 서버들입니다. 이것들이 없으면 플랫폼은 장난감에 불과하고, 실제 생산성의 혁신을 달성하기가 어렵습니다. 다만 이것들은 하나하나가 회사가 새로 끌어안는 외부 시스템이니만큼, 정식으로 쓰기 전에 검토가 필요하고, 변경될 때마다 다시 여러 관점에서 체크를 해 봐야 합니다. 2년 전만 해도 존재하지 않았던 새로운 종류의 관리 업무가 등장하는 겁니다.

2. 갖춰야 할 것들

다음은 그 아래에 갖춰야 할 것들입니다. 에이전트가 한 모든 행동은 나중에 다시 들여다볼 수 있어야 합니다. 언제, 누가 요청해서, 어떤 데이터를 넣었고, 어떤 판단을 거쳐서, 어떤 결과를 냈는지, 사람이 개입했다면 어느 단계에서 했는지까지 전부 기록으로 남아야 합니다. “에이전트가 환불을 처리했습니다”가 아니라, 법적 분쟁이 생겼을 때 법정에 제출할 수 있고, 개인정보 열람 요청에 답할 수 있고, 금융감독 기관의 요청에도 내놓을 수 있는 수준의 기록이어야 합니다. 기록을 남기는 것 자체는 어렵지 않을 수 있지만, 법적으로 유효한 수준으로 남기는 건 전혀 다른 이야기이고, 이 작업의 규모를 제대로 가늠한 기업은 아직 거의 없습니다.

고객 데이터 문제도 미리 답을 준비해야 합니다. 고객 데이터가 모델 제공업체 서버로 넘어가고 있나요? 그 데이터가 모델 학습에 쓰이고 있지는 않나요? 그렇지 않다는 걸 실제로 증명할 수 있나요? 데이터가 어디에, 얼마 동안, 어느 나라 법의 적용을 받으며 저장되나요? 요즘 고객사 계약서에는 2년 전만 해도 없던 조항들이 빼곡히 들어가 있고, 제대로 된 법무팀이 있는 고객이라면 반드시 짚고 넘어가는 사항들입니다.

말로만 “우리는 고객 데이터로 학습하지 않습니다”라고 해서는 안 됩니다. 실제로 그렇게 설정되어 있어야 하고, 그 설정을 언제든 확인해 보여줄 수 있어야 합니다. 지금 대부분의 기업은 이걸 증명하지 못합니다.

문서 보안 등급 문제도 있습니다. 사람이 기밀 문서 다섯 개를 읽고 요약을 쓰면, 그 요약은 원본 문서와 같은 보안 등급을 갖습니다. 에이전트가 같은 문서 다섯 개를 읽고 요약을 쓰면, 그 요약의 보안 등급은 무엇인가요? 다섯 개 중 네 개에는 접근 권한이 있지만 한 개에는 없는 사람이 에이전트를 돌렸다면 어떻게 되나요? 사람을 대상으로는 수십 년에 걸쳐 이미 정리된 문제들입니다. 정보를 읽고, 섞고, 가공해서 내보내는 에이전트를 대상으로는 아직 정리되지 않았습니다.

에이전트의 신원과 권한 문제도 마찬가지입니다. 에이전트가 어떤 작업을 실행할 때, 그건 누구 자격으로 하는 건가요? 요청한 사람의 권한을 그대로 물려받나요, 아니면 에이전트 자체의 계정으로 하나요? A라는 직원이 요청한 에이전트가 B만 볼 수 있는 자료에 접근하려 하면 어떻게 되어야 하나요? 지금까지 회사 시스템의 접근 권한 체계는 전부 사람을 기준으로 설계되어 있었습니다. 이제 그 체계가 사원증도 없고, 상사도 없고, 인사 평가도 받지 않는 에이전트들까지 아우를 수 있도록 바뀌어야 합니다.

3. 사고 대응

마지막은 사고 대응입니다. 에이전트가 잘못된 일을 했을 때 어떻게 할지를 미리 정해두어야 합니다. 누가 먼저 보고를 받나요? 이미 실행된 작업을 어떻게 되돌리나요? 이미 고객에게 나간 이메일, 처리된 결제, 변경된 데이터는 어떻게 하나요? 고객에게는 어떻게 알리나요? 최종 책임은 누가 지나요? 대기업에서 에이전트가 처음으로 큰 사고를 냈을 때, 아무도 생각해두지 않았던 질문들이 한꺼번에 쏟아질 텐데, 그 전에 미리 시나리오를 만들고 점검해두는 편이 훨씬 낫습니다.

고객에게 하는 약속도 실제로 지킬 수 있는 것만 해야 합니다. “고객 데이터로 학습하지 않습니다”, “동의 없이 외부 모델에 데이터를 보내지 않습니다”, “요청하면 삭제해 드립니다”, “AI가 고객 계정과 관련해서 한 모든 행동의 기록을 제공할 수 있습니다”. 이것들은 이제 웬만한 기업 고객의 구매 심사 서류에 기본으로 들어가는 항목들입니다. 이걸 실제로 이행할 체계를 갖추거나, 아니면 그 고객의 사업을 포기하거나, 둘 중 하나입니다. 지금 대부분의 기업은 일부 경우에 대해서만, 그것도 제대로 지켜지지 않는 방식으로 갖추고 있는 게 현실입니다.

자, 이런 것들이 실제로 실행해야 할 일들입니다. 어떤 AI 전략 보고서도, 플랫폼을 파는 벤더도 이 일들이 얼마나 중요한지, 그리고 얼마나 어려울 수 있는지 솔직하게 말하지 않습니다. 하지만, 이것이 바로 ‘AI on the business’가 실제로 어떤 모습인지에 대한 답이기도 합니다.

직원들이 회사 몰래 AI를 쓰는 이유는 회사가 이 일들의 무게를 아직 감당하지 못하고 있기 때문이고, 현장에서는 기다릴 여유가 없기 때문입니다. 회사가 이 무게를 실제로 감당할 수 있을 때, 그리고 그것이 섀도우 AI보다 빠르고 편할 때, 비로소 직원들은 굳이 다른 길을 찾지 않겠죠. 더 안전하기만 해서는 부족합니다. 더 빠르고 편해야 합니다.

기존의 잣대로는 AI 시대의 가치를 잴 수 없다

섀도우 AI를 막을 환경을 갖추는 것만으로 끝이 아닙니다. 그것과는 별개로, 더 근본적인 문제가 기다리고 있습니다. 이것도 플랫폼 벤더들이 아직 잘 꺼내지 않는 문제인데, 그들 입장에서는 똑 부러진 해결책이 아직은 없기 때문이기도 해요. 이 문제는 바로, 기업이 지금껏 가치를 측정하고 돈을 받아온 방식 자체가 AI 시대에는 더 이상 맞지 않는다는 겁니다.

컨설팅이나 법무 같은 서비스 업종은 오랫동안 시간 단위로 요금을 청구해왔습니다. 따지고 보면 시간이란 가치를 재는 단위가 아니라 비용을 재는 단위입니다. 더 나은 기준이 없었기 때문에 업계 전체가 암묵적으로 시간을 가치의 대용으로 써온 겁니다. 80시간짜리 분석 작업을 에이전트가 40분 만에 해치우는 순간, 이 오래된 합의가 무너집니다. 40분에 대해 기존 시간당 요율로 청구하면 말이 안 되고, 실제로 하지도 않은 80시간을 청구하는 것도 말이 안 됩니다. 만들어낸 가치는 분명히 존재하는데, 그것을 청구서에 담을 방법이 없습니다.

디자인 업종은 결과물 단위로 청구해왔습니다. 완성된 PDF, 피그마 파일, 브랜드 가이드라인. 이 결과물들은 그 안에 녹아든 생각과 판단의 대가로 받는 돈이었습니다. 그런데 사람과 에이전트가 함께 작업해서 하룻밤 사이에 결과물이 나오면, 이 공식도 흔들립니다. 견적을 어떻게 내는지, 가격을 어떻게 정하는지, 누구를 채용하고 어떻게 교육하고 어떻게 승진시키는지, 이 모든 것이 사람이 일정한 속도로 결과물을 만들어낸다는 전제 위에 세워져 있었기 때문입니다.

소프트웨어 업종은 사용자 수 단위로 요금을 받아왔습니다. 직원 한 명에 계정 하나, 월정액 요금제 하나. 그런데 에이전트는 사람이 아닙니다. 스스로 돌아가고, 여러 개가 동시에 늘어나고, 사람 수로는 도무지 셀 수 없는 방식으로 작동합니다. 기업 간 소프트웨어가 기업과 에이전트 사이의 소프트웨어로 바뀌고 있는데, 요금 체계도, 보안 체계도, 신원 확인 방식도, 고객 지원 방식도 전부 다시 짜야 하는 상황입니다.

기업에는 수십 년에 걸쳐 켜켜이 쌓인 운영 체계가 있습니다. CFO의 실적 예측, 구매 조달 정책, 인사팀의 인력 계획, 영업팀의 성과 보상 구조. 이것들은 모두 인원수, 투입 시간, 사용자 수, 결과물 수, 분기 예산이라는 단위로 돌아갑니다. 그런데 AI가 만들어내는 가치는 이 단위들 중 어느 것으로도 잘 잡히지 않습니다. CFO는 기존 방식으로 계획을 세울 수 없고, 구매팀은 기존 방식으로 도입 승인을 할 수 없고, 인사팀은 기존 방식으로 인력을 배치할 수 없습니다. 가치는 분명히 만들어지고 있는데, 그것을 재는 도구가 이전 시대의 것입니다.

결국 문제는 여기서 하나로 모입니다. 에이전트가 조직의 일원으로 제대로 작동하려면, 지금 인사 시스템이 사람에게 해주는 것들과 같은 성격의 관리 체계가 에이전트에도 필요합니다. 누구인지 확인하고, 무엇을 할 수 있는지 정하고, 무엇을 했는지 기록하고, 누가 책임지는지 정하고, 더 이상 필요하지 않을 때 어떻게 정리할지까지.

거의 모든 플랫폼 벤더는 에이전트가 돌아가는 엔진만 팝니다. 그 엔진이 회사 안에서 제대로 작동하게 만드는 환경, 즉 신원 관리, 권한 체계, 행동 기록, 사고 대응 절차를 에이전트에 맞게 갖추고 운영하는 것은 기업 스스로 해야 합니다.

별도 조직을 만드는 것도 대부분 실패한다

요즘 테크 언론에서 자주 나오는 조언이 있습니다. 바로 ‘AI 네이티브 자회사’를 따로 만들라는 겁니다. 사실 저도 대기업에서 AI 전환을 담당하시는 임원분들께 가끔 이런 이야기를 하기도 하는데요. 기존 조직의 낡은 시스템에 발목 잡히지 말고, 작고 빠른 팀을 새로 꾸려서 처음부터 AI 중심으로 설계하라는 것이죠.

솔깃한 이야기이고, 실제로 잘 되는 경우도 있습니다. 하지만 대부분은 이렇게 됩니다. 팀은 빠르게 움직이지만, 정작 필요한 것들, 즉 고객 데이터, 실제 매출, 핵심 시스템에는 접근할 수 없는 경우가 아주 많아요. 그런 중요한 요소들은 여전히 기존 조직 안에 있고, 기존 조직은 새로운 것이 자기 영역을 침범하면 본능적으로 밀어냅니다. 협력한다고 하지만 실제로는 아무것도 공유되지 않습니다.

결국 그 팀이 하는 일은 이사회 보고용 데모를 만들고, 그럴듯한 화면을 캡처하고, 보고서에 들어갈 성과를 포장하는 것으로 끝나게 됩니다. 그 결과, 실제 사업에 영향을 주는 시스템은 하나도 나오지 않습니다.

진짜 AI 전환은 그런 방식으로 되지 않습니다. 기업의 AI 전환은, 궁극적으로 기존 조직을 안에서부터 바꾸는 일입니다. 조직이 어떻게 돌아가는지를 AI도 이해할 수 있는 형태로 만들고, 직원들이 몰래 쓰는 AI보다 회사가 공식적으로 제공하는 AI 환경을 더 빠르고 편하게 만들고, AI가 만들어내는 가치를 조직이 실제로 인식하고 측정할 수 있도록 운영 방식을 바꾸는 일입니다. 느리고, 돈이 많이 들고, 조직 내부의 저항과 싸워야 하는 일이지만, 이것 말고는 방법이 없습니다.

지금 당신이 기업에서 AI 기반의 혁신을 이끄는 분이라면, 자회사를 만드는 것보다 훨씬 효과적일 수 있는 방법이 있습니다. 바로, 실제 권한을 가진 내부 AI 팀을 꾸리는 겁니다. 여기서 ‘권한’이 중요합니다. 자문만 하는 위원회로 만들면 안 되고, AI 전도사 한 명을 세워두는 것도 안 됩니다. 예산을 쥐고, 결정을 내리고, 회사가 쓰는 AI 툴과 그 운영 방식 전반에 대한 실질적인 책임을 지는 엔지니어링 팀이어야 합니다. 그 팀이 회사의 AI 환경을 섀도우 AI보다 빠르고 편하게 만들면, 나머지는 자연스럽게 따라옵니다.

모든 기업이 이것을 해낼 수 있을지는 솔직히 모르겠습니다. 어떤 기업은 기존 방식을 완전히 버리고 처음부터 다시 시작해야 할 겁니다. 어떤 기업은 10년에 걸쳐 두 가지 방식을 병행하다가 서서히 하나로 합쳐갈 겁니다. 어떤 기업은 결국 살아남지 못하겠죠.

살아남는 기업들의 공통점은 하나입니다. 좋은 AI 제품을 샀거나, 유능한 AI 책임자를 임명해서 되는 게 아니라, ERP 도입, 클라우드 전환, 디지털 트랜스포메이션 때도 그랬듯이, 화려하지도 않고 빠르지도 않지만 조직의 뼈대를 바꾸는 구조적인 작업을 실제로 해낸 기업들입니다. 컨설팅 업계는 종종 이걸 그럴듯한 방법론으로 포장하려 하지만 매번 실패합니다. 이건, 포장할 수 있는 종류의 일이 아니기 때문입니다.

진짜 분기점

오랫동안, 엔터프라이즈 AI를 둘러싼 논의는 결국 ‘제품 선택의 문제’로 귀결되어 왔습니다. 어떤 모델을 쓸 것인가, 어떤 벤더를 고를 것인가, 어디서부터 시작할 것인가. 맞는 것을 고르면 나머지는 따라온다고들 생각한 거죠.

물론, 틀린 말은 아니지만, 기업에게 진짜 중요한 질문은 거기에서 찾을 수 없습니다. 기업이 목표로 삼고 통과해야 할 진짜 분기점은 다른 곳에 있습니다. 바로, 조직이 실제로 어떻게 돌아가는지를 있는 그대로 드러낼 수 있느냐, 없느냐입니다. 지금까지 누군가의 머릿속에만 있던 것들, 관행적으로 처리해온 것들, 모두가 알지만 아무도 공식적으로 인정하지 않던 것들을 AI가 읽고 실행할 수 있는 형태로 만드는 것을 감당할 수 있는 기업과, 그렇지 못한 기업 사이에 선이 그어집니다.

정보를 쥐고 있는 것이 힘이던 시절에는, 드러내지 않고 쌓아두는 것이 합리적인 선택이었습니다. 그런데 AI를 제대로 활용하려면 조직의 작동 방식이 투명하게 열려야 하는 시대에는, 그 오래된 전략이 오히려 짐이 됩니다. 이 전환을 먼저 해내는 기업들은 상당한 경쟁 우위를 오랫동안 향유하게 될 것이고, 기존의 운영 방식을 놓지 못하는 기업들은 그것을 지키는 데 앞으로의 10년을 쓰게 되고, 결국은 소멸의 길을 걷게 될 겁니다.

‘AI in the business’는 그나마 쉬운 절반입니다. 진짜 어려운 것은 ‘AI on the business’입니다. 이 둘의 차이를 이해하고, 그 과정에서 필연적으로 맞닥뜨리는 내부 저항과 정치적 마찰을 감수할 의지가 있는 기업들이 10년 후에도 살아남을 겁니다.

<원문>

모두가 AI 한다고 하지만, 진짜 AI 네이티브 기업은 아직 없다

]]>

클로드 코드 길들이기: 6인의 실제 사례집 출시

클로드 코드(Claude Code)가 꾸준히 사랑받는 이유는 무엇일까요?

아마 개발 지식과 상관없이 뚝딱 짜주는 코드 때문일 수도 있고, 복잡한 작업을 대신 처리해주는 편리함 때문일 수도 있습니다. 그런데 실제로 클로드 코드를 오래 써온 분들에게 물어보면, 답은 조금 다른 곳에서 나옵니다. 이 도구가 좋은 진짜 이유는, 쓰는 사람마다 자기 방식대로 "길들일" 수 있다는 데 있다고들 합니다.

스킬로 반복되는 업무를 자동화하고, CLAUDE.md로 맥락을 관리하고, 팀 전체의 표준으로까지 확장하는 방식으로 말이죠. 물론 사람마다, 팀마다 환경은 다를 겁니다. 그만큼 자신에게 맞는 방식을 찾기까지 시행착오도 따를거고요. 그렇다면 “어떻게 클로드 코드를 길들여야 할까요?”

요즘IT는 이 질문에 힌트가 될 만한 이야기들을 모아봤습니다. 지난 5월 27일과 6월 10일, 두 차례에 걸쳐 클코나잇 시즌2 웨비나가 진행됐는데요. 여기서 발표자로 참여한 프리랜서 개발자, 대기업 비개발자 PM, 1인 빌더, AI 스타트업 CTO, AX 기획자, BizOps 리드까지. 클로드 코드를 실무에서 각자의 방식으로 길들여 온 6인이 직접 부딪히고 배운 것들을 한 권의 사례집과 발표 영상으로 엮어봤습니다.

참고로 이들의 이야기는 완벽한 성공담보다는 삽질하고, 실패하고, 다시 시도하는 과정 속에서 배운 점, 그렇게 자신만의 방식 혹은 팀의 방식을 찾아간 과정에 가깝습니다. 이번 글에서는 사례집에 담긴 이야기 중 두 가지만 먼저 소개해 드리겠습니다.

전국 30개 캠퍼스의 정산 이의제기, 두 번의 피벗 끝에 5일 만에 뒤집은 이야기

IT 교육기업 AX 전략팀에서 기획자로 일하는 이현 님의 이야기입니다.

그가 맡은 첫 AX 과제는 슬랙 기반의 정산 비효율을 해결하는 일이었습니다. 전국 30개 이상의 캠퍼스가 저마다 슬랙 채널로 정산 업무를 처리하다 보니, 전체 현황이 한눈에 보이지 않았고, 사람이 손으로 계산하니 오류가 났고, 그 위에서 이의제기가 반복됐습니다. 그런데 피그잼으로 업무 흐름을 하나하나 뜯어보고 현장 데이터를 들여다보니, 진짜 병목은 예상과 다른 곳에 있었습니다. 본사가 통보한 정산값에 대한 이의제기와 확인 절차, 바로 그 지점이었죠. 그는 여기서 "이의제기 자체가 생길 수 없는 구조"라는 기획으로 방향을 잡았습니다.

문제는 이걸 무엇으로 구현하느냐였습니다. 처음엔 슬랙 안에서 해결하려 했지만 현장 반응이 좋지 않았습니다. 다음엔 노코드 툴을 조합해 봤지만, 툴 간 의존성과 하드코딩 이슈에 부딪혔습니다. 두 번의 피벗 끝에 그가 선택한 건 클로드 코드였고, 놀랍게도 여기서부터는 5일이면 충분했습니다.

런칭까지는 순조로웠습니다. 그런데 배포 다음 날, "로그인이 느리다"는 피드백이 들어왔습니다. 코드에는 문제가 없었습니다. 문제는 코드 밖, 인프라의 기본값에 숨어 있었습니다.

비개발자였던 그는 이 문제를 어떻게 알아챘고, 또 어떻게 해결했을까요? 두 번의 실패를 거듭한 피벗이 오히려 5일 런칭의 발판이 된 이유는 무엇이었을까요? 자세한 과정은 사례집에서 직접 확인해 보세요.

사례집에서 확인할 수 있는 것들

업무 프로세스 맵보다 현장 데이터를 먼저 봐야 하는 이유, 그리고 진짜 병목을 찾아낸 과정
슬랙 → 노코드 → 클로드 코드, 두 번의 피벗을 거치며 MVP를 좁혀나간 전체 흐름
5일간의 실제 작업 순서 (Day1 빌드 → Day2~3 검증 → Day4 사용자 교육 → Day5 배포)
배포 다음 날 터진 로그인 지연 이슈와 원인을 알아챈 과정
클로드 코드의 첫 제안을 그대로 따르지 않고 도메인 지식으로 역제안해, 로그인 속도를 80% 개선한 방법

1인 개발자가 혼자서 9개 프로젝트를 굴리게 된 이야기

1인 빌더로 활동하는 김상욱 님의 이야기입니다.

그는 원래 한 스타트업의 백엔드 개발자였습니다. 프론트엔드 채용이 안 돼서 얼떨결에 프론트까지 혼자 맡게 됐고, 그렇게 익숙해지던 차에 갑작스레 해고를 당했습니다. 다시 취업 준비를 하거나, 뭐라도 혼자 만들어 보거나의 선택에서 그는 후자를 택했고, 그때 처음 클로드 코드를 만났습니다.

혼자서 만드니 속도가 달랐습니다. 예전엔 MVP 하나에 1~2주씩 걸렸는데, 이제는 단 몇 시간이면 나왔죠. 신이 나서 계속 프로젝트를 찍어냈고, 손에 쥔 프로젝트가 순식간에 아홉 개로 불어났습니다. 초등학교 학급 경영 서비스, 진정서를 자동으로 써주는 서비스, 방치형 RPG 게임, 웹소설 팬 위키까지, 만드는 것만큼은 정말 쉬웠습니다.

문제는 그 다음이었습니다. 세션을 켤 때마다 "내가 어디까지 했더라?"를 매번 다시 더듬어야 했고, 같은 지시를 프로젝트마다 반복해서 입력해야 했습니다. 어제 바로잡은 실수를 오늘 또 저지르기도 했죠. 그는 "만드는 건 쉬워졌지만, 만드는 것에서 끝이 아니구나"를 깨달았다고 말합니다. 그리고 이 문제를 하나씩 시스템으로 풀어, 지금은 혼자서 한 컴퓨터로 13개의 프로젝트를 굴리고 있습니다.

어떻게 가능했을까요?세션이 늘어날수록 관리 비용도 함께 늘어나지 않았을까요? 어떻게 혼자서 프로젝트를 13개까지 유지할 수 있었을까요? 고민 끝에 그가 만든 다섯 가지 장치, 그리고 선택과 집중에 대해서는 사례집에서 직접 확인해 보세요.

사례집에서 확인할 수 있는 것들

세 가지 통증(진행 상황 까먹기·같은 지시 반복·같은 실수 반복)을 각각 다른 장치로 해결한 방법
home/CLAUDE.md 하나로 13개 프로젝트의 맥락을 관리하는 실제 구조
"핸드오프"라는 한마디로 세션 전환 비용을 0으로 만드는 방법과, 이걸 CLAUDE.md에 규칙으로 적용하는 법
세션을 시작하고 끝낼 때 실제로 어떤 순서로 작업하는지와 그가 만든 다섯가지 장치
AI에게 정답 대신 컨텍스트를 던지고 함께 답을 찾는 실제 작업 방식

이 두 이야기 외에도, 4명의 실무자가 각자의 자리에서 부딪히고 배운 기록이 사례집에 담겨 있습니다. 어떤 내용들이 있는지 아래에서 함께 살펴보겠습니다.

클로드 코드 길들이기: 6인의 실제 사례

요즘IT는 지난 5월 27일과 6월 10일, 두 차례에 걸쳐 온라인 웨비나 ‘클코나잇 시즌2’를 진행했습니다. 시즌1이 "클로드 코드로 일하는 법"을 다뤘다면, 시즌2는 그 다음 단계를 다룹니다. 처음엔 개인의 생산성 도구였던 클로드 코드로 나만의 워크플로우를 만들고, 나아가 팀과 서비스 단위로 확장하는 이야기입니다.

이 사례집은 그 웨비나의 기록으로, 완벽하게 다듬어진 강의가 아니라, 현업에서 직접 부딪친 실무자들의 시행착오와 성공기를 솔직하게 담았습니다. 발표 후 이어진 현장 Q&A도 사례집에 함께 담아, 독자들의 궁금증을 해소하고자 했습니다.

클로드 코드에서 스킬을 묶어 워크플로우 자동화하기 _김규동 / 프리랜서 개발자
코딩 말고 일: Repo를 세컨 브레인으로 1년 굴린 이야기 _정덕범 / 라인플래닛 프로덕트 매니저
1인 빌더가 클로드 코드로 프로젝트 9개 운영한 방법 _ 김상욱 / 1인 빌더

PART 2. 클로드 코드를 우리 팀, 서비스에 맞게 확장하기

클로드 코드로 5일 만에 웹 포털 런칭한 방법 _ 이현 / IT 교육기업 AX 전략팀 기획자
우리 개발팀 맞춤 하네스 엔지니어링 구축하기 _ 김영채 / VIBERS AI CTO
AI 도구 26개를 직접 만들며 알게 된 자동화 노하우 _김현민 / 스파르타 게임즈 BizOps Lead

부록

클로드 코드 핵심 용어 사전
발표에서 언급된 플러그인·스킬 레퍼런스
CLAUDE.md / PRD.md 샘플 템플릿
오늘 바로 따라해 보는 체크리스트

※ [추가 안내]
클코나잇 시즌 2 웨비나에 함께해 주신노성현 님,이용학 님의 콘텐츠는 부득이하게 이번 사례집에 담지 못했습니다. 대신 요즘IT 콘텐츠로 만나보실 수 있습니다.

상품 구성

“PDF 사례집만 보고싶어요”

PDF 단품/ ~~16,000원~~ ▶ 할인가 13,500원

“발표 영상까지 함께 보고싶어요”

PDF + 발표 영상 ~~40,000원~~ ▶ 할인가 29,000원 (★추천)

“기업(팀)에서 같이 보고싶어요”

기업(팀) 구매(PDF + 발표 영상) ~~70,000원~~ ▶ 할인가 59,000원 (*10인 이내)

이제 클로드 코드를 "쓸 줄 아는" 사람은 많아졌습니다. 관건은 내 워크플로우 안에 얼마나 녹여내는지, 그리고 개인을 넘어 팀으로까지 옮길 수 있는지입니다. 프리랜서 개발자든, PM이든, CTO든, 결국 부딪히는 질문은 같습니다. “나 그리고 우리 팀에 맞게 어떻게 길들일 것인가” 이 질문에 대한 힌트를 지금 사례집에서 확인해 보세요.

[클로드 코드 길들이기: 6인의 실제 사례] 보러 가기

]]>

23년 된 동네슈퍼를 데이터로 분석하기: 무엇이 팔렸나?

지난 글 ‘23년 동안 살아남은 동네슈퍼를 데이터로 분석해봤습니다’에서 제가 한 일은 단순했습니다. 기존 나들가게 POS에서 월별 매출, 거래 건수, 객단가, 현금매출과 카드매출 데이터를 크롤링하고, 이를 Supabase에 저장해 별도의 대시보드에서 볼 수 있도록 만들었습니다.

기존 POS에서도 데이터를 조회할 수는 있었습니다. 그러나 과거 데이터를 조회할 때마다 직접 하나씩 하나하나 조회해야 했고, 여러 메뉴에 정보가 흩어져 있어 전체 흐름을 한눈에 파악하기 어려웠습니다. 그래서 한 번 수집한 과거 데이터는 데이터베이스에 저장하고, 이후부터는 복잡한 POS 사이트에 다시 접속하지 않고 바로 불러오는 구조로 변경했습니다. 그 결과, POS가 처음 도입된 2011년의 매출과 2026년의 매출을 같은 화면에서 비교할 수 있는 기반이 만들어졌습니다.

이 단계까지만 해도 나름대로 의미가 있었습니다. 오래된 시스템 안에 갇혀 있던 데이터를 외부로 꺼냈고, 과거의 기록을 빠르게 탐색할 수 있게 되었기 때문입니다.

하지만 여전히 알 수 있는 것은 다음 정도였습니다.

이번 달 매출이 얼마인지
지난달보다 올랐는지 내렸는지
거래 건수가 늘었는지
객단가가 달라졌는지
현금과 카드의 비중이 어떻게 변했는지

매출이 왜 달라졌는지 알려면 결국 무엇이 팔렸는지까지 내려가야 했습니다. 이번 편에서는 프로젝트가 어디까지 확장되었는지, 그리고 데이터를 많이 모으는 것만으로는 왜 점주의 의사결정을 도울 수 없었는지를 정리해 보려고 합니다.

이번에는 ‘얼마나 팔렸는가’에서 ‘무엇이 팔렸는가’로 내려갔다

이번에 가장 먼저 추가한 것은 상품 상세 데이터였습니다.

기존에는 하루 총매출과 거래 건수만 가져왔다면, 이제는 POS의 다른 메뉴에 들어가 다음 정보까지 수집하도록 만들었습니다.

국산 담배류, 아이스크림류, 소주 등 중분류별 매출
에쎄 수, 떡붕어싸만코처럼 실제 판매된 세부 상품
상품별 판매수량과 매출액
해당 상품에서 남긴 매출이익
거래가 발생한 시간
같은 영수증에 포함된 다른 상품

<출처: 작가>

이 데이터는 월매출 달력보다 수집하기 더 어려웠습니다.

상품별 이익은 ‘일일 분류별 상품 판매 현황’에 있었고, 몇 시에 어떤 상품이 팔렸는지는 별도의 ‘상품 판매내역 조회’ 화면에 있었습니다. 결국 두 화면을 각각 크롤링한 뒤, 날짜와 상품을 기준으로 다시 연결해야 했습니다.

특히 거래 내역 화면은 하루치 영수증을 하나씩 열어 상품을 확인해야 했습니다. 어떤 날은 하루 데이터를 가져오는 데만 몇 분이 걸렸습니다. 그래서 최근 데이터만 가져오는 것으로 끝내지 않고, 과거 날짜를 하루씩 거슬러 올라가며 자동으로 수집하는 백필 과정을 만들었습니다.

월별 매출 데이터는 2011년까지 수집을 마쳤지만, 상품과 영수증 단위의 상세 데이터는 양이 훨씬 많아 아직도 수집 중입니다. 현재는 대략 2014년의 데이터까지 내려가며 차근차근 데이터베이스에 쌓고 있습니다.

그리고 이 과정을 대시보드에서 직접 확인할 수 있도록 별도의 ‘수집 현황’ 페이지도 만들었습니다.

<출처: 작가>

처음에는 단순히 오래 걸리는 작업이라고만 생각했습니다. 하지만 수집 기간이 길어질수록 어느 연도까지 정상적으로 들어왔는지, 누락된 날짜는 없는지, 달력 매출과 세부 상품 매출의 합계가 일치하는지를 확인하는 기능도 중요해졌습니다.

데이터가 많아지면 수집 자체보다 제대로 수집되었는지를 검증하는 일이 더 어려워진다는 사실도 알게 되었습니다.

데이터가 쌓이자 결국 무료 요금제를 벗어나게 됐다

처음에는 개인 프로젝트이기 때문에 Supabase 무료 요금제로도 충분할 것이라고 생각했습니다. 하지만 영수증 거래 데이터만 60만 건을 넘어섰고, 영수증에 포함된 개별 상품 행은 100만 줄 이상 쌓였습니다. 일별 상품 집계 데이터까지 더해지면서 데이터베이스 용량은 빠르게 증가했습니다.

결국 Supabase 무료 요금제에서 제공하는 500MB 한도를 넘겼습니다. 오래된 데이터를 삭제하거나, 최근 2년 정도만 보관하는 방법도 생각해 볼 수 있었습니다. 하지만 이 프로젝트를 시작한 중요한 이유 중 하나가 2011년부터 이어진 가게의 데이터를 한곳에 모으는 것이었습니다.

과거 데이터를 삭제하면 비용은 줄어들겠지만, 이 프로젝트가 가진 가장 중요한 자산도 함께 사라지게 됩니다. 결국 Supabase Pro 요금제로 업그레이드했고, 현재 매달 약 3만 8천 원 정도를 지불하고 있습니다.

개인 사이드 프로젝트에 매달 비용을 내는 것이 부담스럽지만, 10년이 넘는 실제 가게의 원장을 보존하고 분석하는 비용이라고 생각하고 유지하기로 했습니다.

데이터가 늘어나면서 대시보드의 구조도 다시 나눴다

상품과 시간대 정보가 추가되자 기존 한 화면에 모든 내용을 담기 어려워졌습니다.

그래서 상단 메뉴를 크게 다음과 같이 구분했습니다.

오늘
월별
판단
날씨

처음 화면을 열면 ‘오늘’ 탭이 나타납니다. 점주가 가게에서 가장 먼저 궁금해할 정보는 과거의 장기 추세보다 오늘 장사가 어떻게 되고 있는지이기 때문입니다.

‘오늘’ 탭에서는 현재까지의 매출, 거래 건수, 객단가, 예상 이익과 함께 오늘 판매된 주요 상품군과 세부 상품을 보여줍니다. 반면, ‘월별’ 탭에서는 한 달 동안 누적된 데이터를 기준으로 다음 내용을 확인할 수 있도록 했습니다.

일별 매출 흐름
평균적으로 매출이 높은 요일
거래가 가장 많은 시간대
중분류별 매출과 이익
세부 상품별 매출·이익·판매량 순위
현금과 카드 결제 비중

<출처: 작가>

실제로 데이터를 확인해 보니 담배, 소주, 맥주가 전체 매출에서 매우 큰 비중을 차지하고 있었습니다. 세 상품군을 합치면 매출의 절반에 가까운 기간도 있었습니다.

그런데 여기서 재미있는 점이 하나 있었습니다. 매출이 높은 날이 반드시 돈을 많이 남긴 날은 아니었습니다.

어떤 날은 음식물 쓰레기 종량제 스티커가 많이 판매되면서 매출액 자체는 높게 나타났습니다. 하지만 이 상품은 가게에 남는 이익이 거의 없기 때문에 매출 순위만 보면 좋은 날처럼 보이지만, 실제 이익 측면에서는 그렇지 않았습니다.

<출처: 작가>

이 경험을 통해 단순한 매출 순위가 점주에게 잘못된 인상을 줄 수 있다는 사실을 확인했습니다. 얼마나 많이 팔렸는가와 실제로 얼마가 남았는가는 전혀 다른 질문이었습니다.

보기 좋은 대시보드만 만들고 싶었던 것은 아니었다

사실 제가 처음부터 만들고 싶었던 것은 POS를 현대적으로 다시 디자인한 화면이 아니었습니다.

기존보다 정보를 보기 쉽게 만들고, 토스처럼 중요한 숫자가 먼저 들어오도록 UI를 구성하는 것도 필요했습니다. 하지만 그것만으로는 기존 POS를 조금 예쁘게 다시 만든 것에 불과합니다.

제가 정말 만들고 싶었던 것은 다음 구조였습니다.

Raw Data
무엇이 언제 얼마에 팔렸는가
↓  
Calculation
요일·시간·상품·이익의 관계를 코드와 공식으로 계산
↓
Decision
그래서 점주가 무엇을 확인하거나 바꿔볼 것인가

여기서 중요한 점은 계산을 LLM에 맡기지 않는 것입니다. 매출 변화율, 판매지수, 동반구매율, 상품별 마진과 같은 숫자는 SQL과 코드로 계산합니다. LLM은 이미 계산된 결과를 점주가 이해할 수 있는 문장으로 바꾸는 역할만 맡도록 했습니다.

LLM이 원본 데이터를 보고 자유롭게 판단하게 하면 그럴듯하지만 근거가 불분명한 설명을 만들 가능성이 있기 때문입니다.

그런데 첫 번째 ‘인사이트’는 별로 유의미하지 않았다

처음에는 이런 판단 카드를 만들었습니다. 13시 방문을 이익으로 전환할 기회가 있어요. 13시는 거래 건수가 많지만 객단가가 낮으므로 계산대 근처에 고마진 상품을 배치해 보라는 내용이었습니다.

처음 화면에 띄웠을 때는 꽤 그럴듯해 보였습니다. 하지만 점주의 입장에서 다시 생각해보니 별로 의미 있는 정보가 아니었습니다.

정확히 어떤 상품을 놓아야 하는지
이러한 패턴이 하루만 나타난 것인지 반복되는지
실제로 얼마나 이익이 늘어날 수 있는지
단골 한두 명의 반복 구매로 만들어진 패턴은 아닌지

어느 것도 충분히 설명하지 못했습니다. 결국 ‘데이터를 분석한 문장’처럼 보일 뿐, 실제 행동을 바꿀 만큼 구체적인 판단은 아니었습니다. 그래서 이 카드를 제거하고, 계산 계층을 다시 설계했습니다.

반복되는 패턴만 판단 후보로 올리기 시작했다

이후에는 하루의 숫자 하나를 보고 인사이트를 만들지 않도록 했습니다.

예를 들어, 특정 상품이 금요일에 많이 팔렸다고 판단하려면 다음 조건을 함께 계산합니다.

최근 8주 동안 비교 가능한 금요일이 충분히 존재하는지
8주 중 몇 주에서 같은 패턴이 반복됐는지
다른 요일보다 얼마나 많이 팔렸는지
최근 4주 동안 증가하거나 감소하고 있는지
결과를 만들 수 있는 데이터가 충분히 수집되었는지

이를 바탕으로 다음과 같은 결과를 만들고자 했습니다. 최근 8주 금요일 중 7주에서 12~14시 아이스크림 판매량이 다른 시간대보다 높았습니다. 단순히 “금요일에 아이스크림이 많이 팔립니다”라고 말하는 것보다, 표본과 반복성을 함께 보여주는 방식입니다. ‘더 준비하세요’라는 표현도 조심했습니다.

현재 데이터에는 실제 재고 수량이나 발주 단위가 없기 때문에 정확히 몇 개를 주문해야 하는지는 알 수 없습니다. 그래서 시스템에서는 ‘발주량’이 아니라, 과거 판매량의 중앙값과 최근 추세를 기준으로 목표 준비량을 보여주도록 만들었습니다.

가게의 시간을 하나의 리듬처럼 보기 시작했다

데이터가 충분히 쌓이면서 각각의 표를 나열하는 것보다, 가게의 운영 구조를 한 번에 보고 싶다는 생각이 들었습니다. 그래서 ‘판단’ 탭을 일종의 가게 디지털 트윈처럼 다시 구성했습니다. 물론 공장의 설비나 물류 흐름을 실시간으로 복제하는 거창한 디지털 트윈은 아닙니다. 이 가게에서 반복되는 시간과 상품의 구조를 데이터로 옮겨놓았다는 의미에 가깝습니다.

이 화면은 네 가지 관점으로 구성했습니다.

1) 시간대 리듬

요일과 시간을 히트맵으로 연결해, 언제 가게의 거래가 집중되는지 보여줍니다. 실제로 데이터를 확인해 보니, 요일에 관계없이 대체로 오후 5시에서 8시 사이가 가장 중요한 시간대로 나타났습니다.

단순히 피크 시간만 보여주는 것이 아니라, 오전 8~12시, 12~16시, 16~20시, 20~24시로 나누어 각 시간대에 어떤 상품과 상품 조합이 주로 판매되는지도 연결했습니다.

<출처: 작가>

2) 계절 달력

월별로 어떤 카테고리의 비중이 달라지는지 여러 해의 평균으로 계산했습니다. 아이스크림처럼 계절성이 명확한 상품뿐 아니라, 같은 계절에도 매년 반복적으로 증가하거나 감소하는 상품군을 확인할 수 있습니다.

<출처: 작가>

3) 명목 매출과 실질 성장

2011년보다 지금의 매출이 높다고 해서 가게가 실제로 더 많은 상품을 판매한다고 볼 수는 없습니다. 그동안 상품 가격 자체가 올랐기 때문입니다. 그래서 공식 소비자물가지수와는 별개로, 우리 가게에서 여러 해 동안 공통으로 판매된 상품들의 단가 변화를 이어 붙인 자체 단가 지수를 만들었습니다.

이를 통해 매출이 가격 상승 때문에 오른 것인지, 실제 거래와 상품 판매가 늘어 오른 것인지를 구분해보려 했습니다. 이 지수는 공식 물가지표가 아니라, 어디까지나 우리 가게의 판매가격을 기준으로 계산한 지표라는 점도 화면에 함께 표시했습니다.

<출처: 작가>

4) 상품의 세대교체

같은 카테고리 안에서도 시간이 지나면서 대표 상품이 바뀝니다. 과거에 많이 팔렸던 상품의 점유율이 줄어들고 새로운 상품이 이를 추월하는 시점을 찾아, 어떤 제품이 어떤 제품으로 대체됐는지 시각화했습니다.

데이터에서는 박카스 중심이던 에너지음료 수요가 몬스터 같은 새로운 상품으로 이동하는 모습도 확인할 수 있었습니다.

<출처: 작가>

과거에 무엇이 팔렸는지를 단순히 보여주는 것은 “그때는 그랬구나”에서 끝날 가능성이 큽니다. 제가 찾고 싶었던 것은 과거의 기록 자체가 아니라, 현재 상품 운영에 영향을 줄 만큼 반복되거나 구조적으로 변한 패턴이었습니다.

함께 사가는 상품도 데이터로 꺼내보았다

영수증 단위의 상품 데이터가 생기면서 어떤 상품을 함께 구매하는지도 계산할 수 있게 되었습니다. 다만 판매 건수가 많은 상품끼리는 우연히 함께 잡힐 가능성도 높습니다.

그래서 단순 동반 구매 횟수뿐 아니라, 두 상품이 각각 팔릴 확률과 비교해 실제로 함께 구매될 가능성이 몇 배 높은지를 나타내는 lift도 함께 계산했습니다.

그 결과 POS에 기록된 상품명을 그대로 기준으로 다음과 같은 조합을 발견했습니다.

[시원] 360ml 보조 상표(통합) + 카스1000L
98회 함께 판매, 일반적인 경우보다 20.5배 높은 조합
[시원] 360ml 보조 상표(통합) + 팔리아멘트 아쿠아5
53회 함께 판매, 일반적인 경우보다 22.8배 높은 조합

<출처: 작가>

부모님은 오랫동안 가게를 운영했기 때문에 어떤 상품이 함께 팔리는지 어느 정도 이미 알고 계셨을 수 있습니다. 다만 그동안은 경험과 감각으로 알고 있던 사실을 데이터상에서 정확한 횟수와 수치로 꺼낼 수 있게 되었습니다.

그렇다고 이 결과만 보고 곧바로 두 상품을 묶어 팔거나 진열을 바꾸는 것은 아닙니다. 두 상품을 함께 산 사람이 실제로 여러 명인지, 한 명의 단골이 반복해서 구매한 것인지 현재 POS 데이터만으로는 알 수 없기 때문입니다.

결국 동반 구매 분석도 정답이라기보다, 점주가 현장을 다시 살펴볼 질문의 출발점에 가깝습니다.

2011년부터의 날씨도 가게 데이터와 연결했다

이번에는 POS 밖의 데이터도 처음으로 연결했습니다. 기상청 데이터를 활용해 2011년부터 현재까지 부산의 기온, 습도, 강수량, 운량 등의 날씨 정보를 수집했습니다.

현재는 약 5,690일의 일별 날씨와 13만 건이 넘는 시간대별 관측 데이터가 쌓여 있습니다. 처음에는 같은 달과 같은 요일 안에서 날씨가 더운 날과 그렇지 않은 날을 비교했습니다. 하지만 15년 가까운 데이터가 생기자 같은 달에만 한정할 필요가 없다는 생각이 들었습니다.

작년 8월과 올해 7월이라도 기온과 습도, 강수 조건이 비슷하다면 가게의 입장에서는 충분히 비교할 수 있는 날이기 때문입니다. 그래서 현재는 강수 여부를 먼저 나누고, 기온·습도·운량이 오늘과 가장 비슷했던 과거 날짜를 전 기간에서 찾는 방식으로 변경했습니다.

그 뒤 비슷한 날들에 평소보다 더 팔렸던 상품과 덜 팔렸던 상품을 보여줍니다.

<출처: 작가>

예를 들어, 단순히 “더운 날에는 아이스크림이 잘 팔립니다”라고 보여주는 것은 큰 의미가 없습니다. 대신 다음과 같이 보여주는 것이 목표입니다. 오늘과 비슷한 날씨였던 과거 20일에서 비비빅은 하루 평균 9개, 메로나는 3.2개 더 판매됐습니다. 판매량이 0.02개에서 0.4개로 올랐다면 수치상으로는 20배지만, 실제로는 하루 0.38개 차이에 불과합니다.

그래서 배수보다 하루에 실제로 몇 개 더 팔렸는지를 기준으로 순위를 정했습니다. 다만 이것 역시 인과관계라고 단정할 수는 없습니다. 기온이 비슷한 날에 특정 상품이 함께 많이 팔렸다는 사실을 보여줄 뿐, 날씨 때문에 해당 상품이 팔렸다고 확정하는 것은 아닙니다. 계절, 요일, 상품의 출시 시점과 단종 여부 같은 다른 요인도 함께 영향을 줍니다.

따라서 날씨 탭도 현재는 정답을 알려주는 기능이라기보다, 내일 무엇을 조금 더 준비해 볼지 판단할 근거를 제공하는 단계에 있습니다.

LLM은 계산하지 않고, 계산된 결과만 설명하게 했다

분석 결과를 점주가 읽기 쉬운 문장으로 바꾸기 위해 LLM API도 연결했습니다. 하지만 LLM이 매출 원장을 직접 보고 계산하거나, 자유롭게 상품 운영 방법을 추천하도록 하지는 않았습니다.

역할을 다음과 같이 분리했습니다.

SQL과 코드
판매량·마진·반복성·동반구매·날씨 효과를 계산

LLM
계산된 수치와 한계를 사람이 이해하기 쉬운 문장으로 정리

LLM이 실패하거나 API를 사용할 수 없는 경우에도 판단 기능이 멈추지 않도록, 같은 내용을 정해진 문장으로 출력하는 템플릿도 함께 만들었습니다. 결국 이 시스템에서 LLM은 판단을 만들어내는 두뇌라기보다, 이미 계산된 결과를 점주의 언어로 번역하는 인터페이스에 가깝습니다.

기능을 추가할수록 서비스는 느려졌다

이번 프로젝트를 하면서 개발자분들이 새삼 대단하다고 느낀 순간도 많았습니다. 이 서비스는 사실상 한 사람, 많아야 가족 몇 명이 사용하는 개인용 서비스입니다. 대규모 트래픽이 발생하지도 않고, 수많은 사용자가 동시에 요청을 보내지도 않습니다.

그런데도 상품 데이터, 판단 탭, 날씨 데이터처럼 기능을 하나씩 추가할 때마다 탭 이동이 느려지고 로딩 시간이 길어졌습니다. 과거 데이터를 매번 다시 계산하면 화면을 열 때 오래 기다려야 했고, 백필 작업이 브라우저를 사용하고 있으면 오늘 데이터를 수집하는 작업이 밀리기도 했습니다.

이를 해결하기 위해 다음과 같은 방법을 계속 추가했습니다.

변하지 않는 과거 데이터는 데이터베이스에서 즉시 조회
무거운 분석은 사용자가 접속했을 때가 아니라 야간에 미리 계산
계산 결과는 스냅샷 형태로 저장
사용자가 새로고침하면 과거 백필 작업이 브라우저를 양보
한 번 계산한 값은 캐시에 저장
누락되거나 합계가 맞지 않는 날짜는 별도로 탐지해 재수집

혼자 사용하는 서비스에서도 이 정도의 고민이 생겼습니다. 그렇다면 토스처럼 수많은 사용자가 동시에 접속하고, 계속 새로운 기능이 추가되는 서비스에서 백엔드 개발자분들은 얼마나 많은 통신 방식과 캐싱, 동시성, 데이터 정합성 문제를 고민하고 있을까 하는 생각이 들었습니다.

화면에서는 버튼을 한 번 누르면 바로 다음 정보가 나오지만, 그 자연스러운 경험 뒤에 얼마나 많은 최적화가 숨어 있는지 조금이나마 체감할 수 있었습니다.

바이브 코딩에도 기억을 보존하는 장치가 필요했다

기능이 많아지면서 또 다른 문제가 발생했습니다. Claude나 Codex를 이용해 바이브 코딩을 하다 보면, 새로운 터미널과 새로운 대화창에서 작업을 시작하게 됩니다. 그러면 이전 대화에서 왜 특정 구조를 선택했는지, 어떤 오류 때문에 방어 로직을 추가했는지가 사라집니다.

새로운 AI는 현재 코드만 보고 다음과 같이 판단할 수 있습니다. 이 부분은 복잡해 보이니 제거해도 되겠습니다. 하지만 실제로는 과거에 발생했던 데이터 오염이나 삭제를 막기 위해 일부러 복잡하게 만들어둔 코드일 수 있습니다.

실제로 프로젝트에서는 같은 날 같은 이름을 가진 다른 상품이 한 번에 들어오면서 저장 배치 전체가 실패한 적도 있었습니다. 그 문제로 1,000일이 넘는 상품 데이터가 정상적으로 저장되지 않았고, 백필 작업도 과거로 내려가지 못한 채 같은 구간을 반복하고 있었습니다.

또 수집이 2014년에서 멈춘 이유를 처음에는 데이터베이스 용량이나 POS 보관기간 때문이라고 의심했지만, 실제로는 앞선 저장 오류로 미완료 날짜가 쌓여 과거 날짜까지 내려가지 못한 것이 원인이었습니다.

이런 맥락을 모르는 AI가 코드를 단순화하면 이미 해결한 문제가 다시 발생할 수 있었습니다.

그래서 SSOT.md라는 문서를 만들었습니다.

<출처: 작가>

SSOT는 Single Source of Truth, 즉 하나의 기준이 되는 문서라는 의미입니다.

이 문서에는 다음 내용을 계속 기록했습니다.

프로젝트가 어떤 문제를 해결하는지
현재 데이터베이스 구조
각 파일이 맡는 역할
왜 특정 구조를 선택했는지
과거에 발생한 장애와 실제 원인
제거하거나 변경하면 안 되는 로직
현재 진행 중인 작업과 다음 단계

AI에 새로운 작업을 맡길 때도 먼저 이 문서를 읽도록 했고, 중요한 구조를 변경하면 코드와 함께 SSOT도 갱신하도록 했습니다. 바이브 코딩은 코드를 빠르게 만드는 데에는 매우 유용합니다.

하지만 프로젝트가 길어질수록 중요한 것은 코드를 빨리 생성하는 능력보다, 왜 이런 코드가 존재하는지를 잊지 않는 능력이라는 사실도 알게 되었습니다.

동네 슈퍼 데이터는 편의점 데이터와 다르다

이 프로젝트에서 계속 경계하고 있는 부분도 있습니다. 우리 가게는 불특정 다수가 끊임없이 방문하는 대형 매장이나 프랜차이즈 편의점이 아닙니다. 주변에 거주하는 단골손님과 매일 담배나 술을 사러 오는 고객의 비중이 높습니다.

따라서 특정 상품 조합이 많이 나타났다고 해서 많은 고객이 공통으로 선호한다고 단정할 수 없습니다. 한 명의 단골이 같은 조합을 반복해서 구매했기 때문에 만들어진 결과일 수도 있습니다. 고객 ID가 없는 POS 데이터만으로는 이를 완전히 구분하기 어렵습니다.

예를 들어, 데이터를 분석하니 월요일에는 캔커피가 평소보다 약 2.3배 많이 팔리는 패턴이 나타났습니다. 하지만 이 수치만 보고 월요일마다 캔커피를 두 배로 발주하는 것은 위험합니다.

먼저 현장에서 다음 질문을 해봐야 합니다.

월요일마다 특정 단골이 대량으로 구매하는 것은 아닌가?
주변 사업장의 근무 일정과 관련이 있는가?
특정 납품이나 작업 일정이 월요일에 몰려 있는가?
실제로 진열 위치를 바꾸면 추가 판매로 이어질 수 있는가?

이 시스템이 해야 할 일은 “월요일에는 캔커피를 더 주문하세요”라고 정답을 말하는 것이 아닐 수 있습니다. 오히려 부모님이 오랜 경험 속에서 놓치고 있던 패턴을 꺼내 다음과 같은 질문을 던지는 것이 더 중요할 수 있습니다.

월요일에 캔커피가 반복적으로 더 팔리는 이유가 무엇일까?
이 패턴을 이용해 함께 판매할 상품이나 준비 방식을 바꿔볼 수 있을까?

필요한 데이터는 거의 모았지만 진짜 어려운 문제가 남았다

처음에는 POS 데이터를 가져오는 것 자체가 가장 어려운 문제라고 생각했습니다. 엑셀 다운로드도 제대로 지원하지 않는 오래된 사이트에서 데이터를 크롤링하고, 2011년부터의 기록을 데이터베이스에 저장하는 일이 가장 큰 과제처럼 보였습니다.

그런데 지금은 생각이 달라졌습니다. 데이터를 모으는 것은 어렵지만, 언젠가는 끝납니다. 진짜 어려운 문제는 그다음입니다. 수집한 데이터를 어떤 기준으로 연결하고, 어떤 차이를 의미 있는 변화로 판단하며, 어떤 결과만 점주에게 보여줄 것인가.

수많은 숫자를 보여주는 것은 쉽습니다. 그러나 그중 실제로 부모님의 다음 행동을 바꿀 만한 신호를 찾아내는 것은 전혀 다른 문제입니다. 현재 시스템은 과거와 비슷한 날, 특정 요일과 시간대의 평균, 함께 팔린 상품, 날씨 조건에 따른 판매 차이를 보여줄 수 있는 단계까지 왔습니다. 하지만 아직은 대부분 관찰과 비교에 가깝습니다.

앞으로는 여기서 한 단계 더 나아가고 싶습니다.

어떤 패턴이 우연이 아니라 반복되는지
어떤 상품은 늘리고 어떤 상품은 줄여볼지
진열 위치를 바꾸면 실제 이익이 늘어나는지
추천한 행동을 실행한 뒤 결과가 어떻게 달라졌는지
부모님의 현장 경험과 데이터가 서로 충돌할 때 무엇을 다시 확인할지

결국 제가 만들고 싶은 것은 가게 운영의 정답을 대신 내려주는 AI가 아닙니다. 점주가 그냥 지나쳤을 수 있는 변화를 발견하고, 무엇을 확인하고 시험해 볼지 더 정확한 출발점을 제시하는 시스템입니다.

23년 동안 가게를 운영해 온 부모님의 경험을 데이터로 대체하는 것이 아니라, 그 경험이 새로운 질문을 만날 수 있도록 돕는 것. 그것이 이 프로젝트가 다음 단계에서 풀고 싶은 문제입니다.

<원문>

23년 동안 살아남은 동네슈퍼를 데이터로 분석해보려 합니다. (3편)

]]>

이제 클로드가 만든 글엔 눈에 안 보이는 워터마크가 붙습니다

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

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

써볼 것: Hallmark - AI가 만든 티 안 나는 디자인을 만들어주는 도구
참고할 것: Grok Bot - 자기 컴퓨터를 갖고 스스로 일하는 AI 동료
적용해볼 것: AI가 만든 콘텐츠에 표시가 붙기 시작합니다

<출처: Nutlope/hallmark, GitHub>

1. 써볼 것: Hallmark, AI가 만든 티 안 나는 디자인을 만들어주는 도구

AI에게 웹페이지나 화면을 만들라고 하면, 되긴 되는데 어딘가 AI가 만든 티가 나죠. 비슷비슷한 레이아웃에, 가운데 정렬된 제목에, 보라색 그라데이션까지. Hallmark는 이 AI가 만든 티(개발자들은 AI 슬롭이라고 불러요)를 걷어내주는 도구입니다. Together AI가 만들었고, 깃허브 스타 2만 4천 개를 넘기며 주목받고 있어요.

Hallmark는 AI 코딩 도구에 붙여 쓰는 스킬입니다. 클로드 코드, 커서, 코덱스에 설치해두면, AI가 화면을 만들 때 좋은 디자인 원칙을 따르도록 잡아줘요. 타이포그래피, 색, 여백, 모션 같은 걸 65가지 기준으로 점검해서, 흔한 AI 기본값을 벗어난 결과를 내놓습니다.

무슨 문제를 해결해 주나요?

AI로 만든 화면이 밋밋한 건, AI가 학습한 가장 무난한 평균값을 내놓기 때문이에요. 그래서 다들 비슷한 결과가 나오죠. Hallmark는 여기에 구체적인 취향과 규칙을 심어줍니다. 예를 들어 깔끔하고 모던하게 같은 두루뭉술한 지시는 거부하고, 에디토리얼, 브루탈리즘, 럭셔리처럼 뚜렷한 방향을 하나 고르게 해요. 제목을 무조건 가운데 두거나, 아무 데나 그라데이션을 넣는 것 같은 흔한 AI 디자인 습관도 걸러내고요.

어떻게 쓰나요?

터미널에서 npx skills add nutlope/hallmark를 실행하면 설치됩니다. 그다음부터는 클로드 코드나 커서에서 화면을 만들 때 Hallmark 규칙이 적용돼요. 무료로 쓸 수 있고(MIT 라이선스), 네 가지 방식으로 활용할 수 있습니다.

새로 만들기: 그냥 화면을 만들어달라고 하면, Hallmark가 방향을 잡아 디자인합니다.
audit(진단): 이미 있는 화면 코드를 넣으면, AI 티 나는 부분을 짚어줍니다. 고치진 않고 목록만 뽑아줘요.
redesign(재설계): 기존 화면의 내용은 두고, 구조와 겉모습만 새로 바꿔줍니다.
study(분석): 이게 Hallmark의 특징인데, 내가 좋아하는 디자인의 스크린샷이나 주소(URL)를 주면, 그 디자인의 특징(글꼴 느낌, 색, 구조)을 뽑아냅니다. 그대로 베끼는 게 아니라 분위기만 추출해서 내 화면에 적용해주는 거예요.

한 가지, study 기능에는 좋다고 느낀 점이 있습니다. 남의 것을 함부로 베끼지 않도록 선을 그어뒀다는 점인데요. 유료 템플릿이나 경쟁사 페이지는 분석을 거부하고, 픽셀을 그대로 복제하지도 않습니다. 내가 참고할 만한 공개된 디자인의 느낌만 가져오는 용도라, 이런 장치가 있다는 게 마음에 듭니다.

누구에게 좋을까요?

AI로 화면을 만드는데 결과가 밋밋해서 아쉬웠던 사람. 디자인 완성도를 한 단계 올려줍니다.
디자인을 전문으로 배우지 않은 1인 개발자나 기획자. 좋은 디자인 규칙을 빌려 쓸 수 있어요.
참고하고 싶은 사이트가 있는 사람. study로 그 느낌을 분석해 내 작업에 녹일 수 있습니다.
반대로 이미 탄탄한 디자인 시스템이 있다면 굳이 필요하진 않아요. 이건 AI에게 디자인 감각을 빌려주고 싶을 때 쓸모가 큰 도구입니다.

<출처: SpaceXAI, Grok Bot>

2. 참고할 것: Grok Bot, 사람처럼 앱에 로그인해 일하는 AI 에이전트

지난 몇 주 동안 AI 에이전트가 스스로 나서서 문제를 일으킨 사건들을 다뤘는데요. 이번엔 아예 그런 에이전트를 제품으로 내놓은 곳이 나왔습니다. SpaceXAI(일론 머스크의 AI 회사, 옛 xAI)가 커서와 함께 8월 11일 공개한 Grok Bot입니다.

Grok Bot의 콘셉트는 자기 컴퓨터를 가진 AI 동료예요. 기존 AI 비서와 다른 점은, 이 봇이 클라우드에 자기만의 컴퓨터를 갖고 있어서 사용자의 앱과 웹사이트에 직접 로그인해 사람처럼 쓴다는 겁니다. 일을 맡기면 처음부터 끝까지 진행하고, 승인이 필요할 때만 돌아와요. 여러 봇을 만들어 병렬로 굴릴 수도 있고, 봇끼리 일을 주고받게 할 수도 있습니다.

무엇을 할 수 있나요?

SpaceXAI에 따르면 Grok Bot은 팀 동료에게 일을 넘기듯 쓸 수 있습니다. 영업 대상을 조사해 이메일 초안을 쓰거나, 지원 문의에 답하거나, 경비를 처리하는 식이에요. 한 번 워크플로를 보여주면 그걸 기억했다가 다음엔 알아서 반복하고요.

실제로 써본 사람들의 반응을 보면 콘셉트에는 대체로 감탄하는 분위기입니다. 한 개발자는 리서처 봇과 작가 봇을 만들고 이 둘을 지휘하는 봇을 붙여 협업시켰더니 당연히 안 될 줄 알았는데 바로 되더라고 평했어요. 셋업이 거의 필요 없다는 점(워크플로를 그려 넣을 필요 없이 바로 일을 맡긴다)도 강점으로 꼽힙니다.

물론 아직 베타라 조심스러운 평가도 많습니다. 개념은 강력하지만 고객 데이터나 결제, 중요한 결정을 맡기기엔 이르다는 반응이 공통적입니다. 워크플로를 한 번 보여주면 배운다는 기능도, 만든 회사 스스로 그렇게 학습한 건 초안일 뿐이라 사람이 결정 규칙과 예외 처리를 더해야 한다고 밝히고 있고요.

알아두면 좋은 것

Grok Bot에는 눈여겨볼 배경이 두 가지 있습니다.

하나는 커서와의 관계입니다. Grok Bot은 다운로드도 결제도 전부 커서를 통해 이뤄져요. 접근도 SuperGrok Heavy, Cursor Ultra, Cursor Teams Premium 같은 특정 구독자(월 120~200달러)로 한정돼 있고요. 이건 SpaceX가 커서를 만든 회사(Anysphere)를 600억 달러에 인수하기로 한 것과 이어집니다. 아직 인수가 공식 완료되진 않았지만, Grok Bot은 두 회사가 합쳐지며 나온 첫 제품인 셈이에요.

다른 하나는 최근 나온 Grok 4.6입니다. SpaceXAI는 8월 12일 Grok 4.6을 내놨는데, 모델 크기를 키우기보다 긴 작업을 놓치지 않고 해내는 능력과 코딩에 초점을 맞춘 버전이에요. Grok Bot처럼 오래 이어지는 에이전트 작업에 쓰라고 만든 모델이고, 커서와 Grok Bot에서 함께 쓸 수 있습니다. SpaceXAI 발표 기준으로는 성능이 경쟁 모델과 비슷한 수준이라는데, 독립적인 검증은 아직 나오는 중이라 참고만 하면 됩니다.

무엇을 얻어가야 하나요?

Grok Bot이 흥미로운 건, AI를 쓰는 방식이 달라지는 걸 보여주기 때문이에요. 지금까지 AI는 물어보면 답하는 쪽이었는데, 이제는 일을 맡겨두면 알아서 해오는 쪽으로 바뀌고 있습니다.

다만 여기엔 지난 회차들에서 짚은 문제가 똑같이 걸려 있어요. 자기 컴퓨터를 갖고 내 앱에 로그인하는 에이전트는, 그만큼 실제로 할 수 있는 일도 많아져요. 실사용자들이 입을 모아 아직은 감독이 필요하다고 하는 것도 이 때문이죠. 그러니 이런 도구를 쓸 때는 무엇을 맡길지와 무엇을 직접 확인할지를 나눠두는 게 중요합니다. 중요한 작업일수록 봇이 끝냈다고 바로 넘기지 말고, 사람이 한 번 확인하는 단계를 두는 거죠.

<출처: Anthropic, How Claude marks AI-generated content>

3. 적용해볼 것: Claude가 만든 콘텐츠에 워터마크가 붙기 시작합니다

앞으로 AI가 만든 글과 파일에는 AI가 만들었다는 표시가 붙습니다. 앤트로픽이 8월 초 이 계획을 공식적으로 밝혔는데요. 유럽연합의 AI법(EU AI Act)이 AI로 만든 콘텐츠에 표시를 남기도록 요구했고, 앤트로픽이 여기에 동참하며 구체적인 방법을 내놓았습니다. 이는 내가 클로드로 쓴 글이나 만든 이미지에 눈에 보이지 않는 표시가 들어간다는 뜻이라, AI로 콘텐츠를 만드는 사람이라면 참고해둘 내용입니다.

어떻게 표시되나요?

앤트로픽에 따르면 표시 방식은 두 가지입니다.

하나는 텍스트에 새겨지는 워터마크예요. 클로드가 쓴 글에 사람 눈엔 안 보이는 표시를 심는데, 글의 의미나 읽는 느낌은 그대로입니다. 복사해서 다른 곳에 붙여도 따라가고, 어느 정도 편집에도 남습니다.
다른 하나는 파일에 붙는 출처 정보입니다. 클로드가 이미지 같은 파일을 만들면, 이 파일이 클로드를 거쳤다는 정보를 파일 안에 서명해서 넣습니다. C2PA라는 업계 공통 표준을 쓰는데, 이걸로 파일이 중간에 변조됐는지도 확인할 수 있습니다.

적용 범위는 꽤나 넓은데요. 클로드를 쓰는 거의 모든 곳(웹, API, 클로드 코드 등)과 전 세계에 적용되고, 2026년 8월 2일 이후 나온 최신 모델부터 우선 적용됩니다. 그 이전 모델도 표시를 붙이는 작업을 하는 중이고요.

여기서 꼭 알아둘 한계

표시가 붙는다고 해서 모든 게 명확해지는 건 아닙니다. 앤트로픽도 관련한 한계를 분명히 밝혔는데, 실무에선 이 부분이 더 중요할 것 같습니다.

먼저, 표시가 있다고 클로드가 그 내용을 만들었다는 뜻은 아닙니다. 사람들은 클로드로 남의 글을 교정하거나 번역하거나 요약도 하잖아요. 그럴 때도 표시가 붙습니다. 그러니 표시가 있다는 건 이 콘텐츠가 클로드를 거쳤다 정도지, 클로드가 처음부터 모든 걸 작성했다는 증거는 아닙니다.

반대로, 표시가 없다고 AI가 안 만든 것도 아니에요. 글이 아주 짧거나, 많이 고쳐 썼거나, 번역을 거치거나, 스크린샷으로 캡처하거나, 파일 형식을 바꾸면 표시가 사라질 수 있거든요.

무엇을 적용하면 될까요?

내가 만든 결과물이 클로드를 거쳤다는 게 표시로 남을 수 있다는 걸 알아두세요. 특히 다른 사람 이름으로 나가는 글이나, 원작자가 따로 있는 작업이라면 이 점을 염두에 두면 좋습니다.
표시를 진위 판별 도구로 맹신하진 마세요. 표시가 있다고 AI가 다 지어낸 것도, 없다고 사람이 다 쓴 것도 아닙니다. 앞으로 이런 표시가 여러 AI 회사로 퍼질 텐데, 그 신호는 참고 자료지 결론이 아니라는 걸 기억해두면 됩니다.
AI로 만든 걸 서비스에 쓴다면, 앞으로 이런 표시와 관련한 규정이 나라마다 생길 수 있다는 걸 미리 알아두세요. 지금은 유럽이 앞서 있지만, 이런 흐름은 대개 번져갑니다.

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

]]>

그록 4.6 + 그록 봇 = 스페이스X > 구글?

그록이 치고 나왔습니다.

8월 11일에 상시 업무 에이전트 그록 봇(Grok Bot), 8월 12일에 새 모델 그록 4.6이 등장했습니다. 이걸 만든 회사의 이름은 이제 xAI가 아닙니다. 로켓 회사 스페이스X입니다. xAI는 올해 초 스페이스X에 흡수됐고, 6월에는 커서(Cursor) 개발사 애니스피어를 600억 달러 전액 주식으로 사들인다고 발표했죠. 모델을 만드는 xAI와 코딩 도구 커서, 로켓과 위성을 한 회사가 만드는 겁니다.

사실 그전까지 그록이 새 모델을 낼 때마다 머스크가 “이번엔 다르다”고 한 말은 대개 마케팅에 가까웠습니다. 그런데 이번엔 마케팅이 아닐 수도 있습니다. 값싼 프론티어급 모델과 누구나 쓰는 에이전트가 진짜 나왔거든요. 마침 구글이 흔들리는 지금, 정말 그록이 1등 후보가 되는 날이 올까요?

GPT-5.6 솔 급이라는 그록 4.6

그록 4.6 출시 <출처: SpaceX>

그록 4.6이 자랑한 건 두 가지입니다.

하나는 여러 단계의 일을 오랜 시간 붙들고 가는 장시간 에이전트 작업, 다른 하나는 화면/인터랙션 만들기죠. 요즘 모델을 고르는 기준이 “얼마나 똑똑한가”에서 “일을 통째로 맡겨도 되는가”로 바뀌고 있어서, 그에 따라 포인트를 잡은 것 같습니다.

성능

스페이스x 발표 기준으로는 GPT-5.6 솔과 비슷한 수준이라고 합니다. 이런 자사 벤치마크는 대개 어느 정도 걸러 듣게 되지만요, 측정기관 아티피셜 애널리시스(Artificial Analysis)의 지능 지수에서 61점으로 GPT-5.6 솔과 같은 점수를 받았습니다. 오퍼스 5가 63점, 페이블 5가 62점으로 최상위보다는 한두 점 아래지만 프론티어 라인에 올라선 건 맞습니다.

어찌되었든 GPT-5.6 솔, 페이블5와 벤치마크 수치들을 나란히 세우는 거 자체가 큰 발전입니다.

그록 4.6 벤치마크 <출처: SpaceX>

가격

진짜 눈여겨볼 대목은 가격입니다. 입력 100만 토큰당 2달러, 출력 6달러. 지금 최상위권 모델들과 나란히 놓으면 이렇습니다.

GPT-5.6 솔과 비교하면 입력은 절반 이하, 출력은 5분의 1입니다. 페이블 5와 놓고 보면 출력 기준으로 8분의 1 수준까지 떨어지고요. 그록 4.6 혼자 자릿수가 다릅니다.

훈련 방식

훈련 방식에서 재미있는 얘기도 나왔습니다. 담당 팀은 그록 4.6이 내부 모델 개발 업무 자체를 학습 과제로 삼은 첫 모델이라고 밝혔는데요.

이게 실제로 먹히는지 보려고, 학습 중간 버전에 자사 프로덕션 추론 코드를 통째로 넘기고 완전 자동화 환경에서 돌려 봤다고 합니다. 5시간 동안 297개 최적화 후보를 훑어 PR 7건을 올렸고, 그중 3건이 지금 그록 챗 트래픽을 처리하고 있습니다. prefill 3.1%, decode 1.5% 개선이고요. 297개 중 3건이면 타율은 낮지만 자동화 환경에서 나온 반영이라는 게 요점입니다. 이런 순환이 돌기 시작했다는 게 흥미롭습니다.

사용 환경

오늘부터 바로 쓸 수 있습니다. 커서, 그록 빌드, 그록 봇, API 같은 연계 제품이랑 오픈라우터, 버셀, 클라우드플레어 등 외부에서도 쓸 수 있습니다. 커서를 쓰고 있다면 이미 골라 쓸 수 있는 상태고요. 첫 주에는 이벤트 느낌으로 사용량을 2배 더 제공한다고 합니다.

그런데 어쩌면 모델보다 더 중요한 건 하루 앞서 나온 이쪽입니다.

그록 봇: 챗봇 아닙니다, 에이전트입니다

8월 11일에 얼리 베타로 나온 그록 봇 얘기입니다. 이름만 보면 챗봇 같지만, 실제로는 상시 업무 에이전트에 가깝습니다.

그록 봇 <출처: SpaceX>

동작 구조: 클라우드에 컴퓨터 하나씩 + 직접 로그인해 화면을 조작

공식 포스트가 설명하는 동작 방식은 이렇습니다.

봇마다 클라우드에 자기 컴퓨터를 하나씩 갖습니다.
이 봇들이 내가 쓰는 도구에 직접 로그인해 사람처럼 화면을 조작하죠. 그래서 API 연동이 없는 서비스도 씁니다.
노트북을 닫아도 클라우드에서 계속 돌아갑니다. 그러다 승인이 필요한 순간에만 물으러 돌아오고요.
한 번 시연해 보이면 루틴으로 저장돼서 다음부턴 알아서 반복합니다.

즉, 메신저로 말을 시켜 두면 알아서 일하고 필요할 때만 물으러 오는 방식입니다.

지시도 대화로 하고 보고도 대화로 받으니 쓰는 사람 입장에선 원격에서 일하는 어시스턴트를 한 명 두는 거에 가깝겠죠. API가 뚫려 있지 않은 사내 시스템이나 오래된 웹 서비스에도 붙는다는 게 기존 자동화 도구와 갈리는 지점이고요. 그러니 개발보다는 비개발자의 반복 업무 쪽에 좋아 보입니다.

사용 환경

요금은 개인 월 200달러(커서 울트라), 팀 플랜으로는 인당 월 120달러입니다. 기존 슈퍼그록 헤비(월 300달러) 가입자도 쓸 수 있고요. 맥·윈도우·리눅스·iOS를 지원하며, 안드로이드는 출시 예정입니다.

월 200달러부터 시작이니 사실 좀 꺼려지긴 합니다.

그래서 찾아본 후기

그래서 직접 써 본 사람들의 후기에 눈이 가는데요.

가장 크게 퍼진 건 레니 라치츠키(Lenny Rachitsky)의 후기입니다. 프로덕트 업계에서 ‘레니의 뉴스레터’로 유명한 그 사람이죠. 얼리 액세스로 써 봤다는 그는 “한동안 이렇게까지 신났던 AI 제품이 없었다”고 했습니다. 오픈클로와 비슷한데 훨씬 쉽고, 안정적이고, 덜 무섭다는 평가고요. 구직자와 채용 중인 회사 짝지어 주기, 고객 지원 메일 자동 응답(몇 시간을 아꼈다고 합니다), 카드 명세서를 훑어서 해지할 정기 구독 찾아내기, 다음 팟캐스트 게스트 브리핑 문서 만들기 등을 시켰다고 합니다. 개발과는 아무 상관 없는 목록이죠.

제품을 아예 뜯어본 후기도 있습니다. 쿤 첸(Kun Chen)은 하루를 붙들고 일을 시켜 본 뒤 구조까지 역추적해 정리했는데요. 사용자마다 클라우드에 리눅스 VM이 하나씩 주어지고(8 vCPU·메모리 16GB·디스크 128GB), 맥 앱과 iOS 앱은 그 VM 속 봇과 대화하는 얇은 껍데기라고 합니다. 봇들은 이 VM을 함께 쓰지만 각자 자기 가상 데스크톱을 가져서 화면 조작이 서로 부딪히지 않고요. 이 정도 사양으로 감당이 안 되는 무거운 코딩 작업은 커서 클라우드 에이전트로 넘어갑니다. 그의 총평은 “일부러 깊게 만든 다음 단순한 인터페이스 뒤에 잘 숨겨 놓은 제품”이었습니다.

그록 4.6 + 그록 봇 출시의 진짜 의미

모델이 아닌 “AI 종합 세트”

중요한 건 값싸고 좋은 모델에 붙은 게 코딩 에이전트가 아니라 누구나 쓰는 에이전트라는 점입니다. 개발자용 도구는 사실 이미 클로드 코드와 코덱스가 꽉 잡고 있습니다. 커서도 있고요. 그러니 이 에이전트는 그 외의 영역, 그러니까 매일 반복되는 업무를 겨냥합니다. 그렇다고 커서를 완전 대체하는 그림은 아닙니다. 무거운 코딩 작업은 그록 봇이 커서 클라우드 에이전트로 넘긴다고 해요. 가벼운 일은 봇이 직접 하고 무거운 일은 전용 도구로 보내는 병행 구도입니다.

사실 이런 상시 범용 에이전트 자체는 완전 새로운 건 아닙니다. 2026년 들어 챗GPT 워크, 클로드 코워크, 제미나이 스파크가 몇 달 사이에 줄줄이 나왔으니까요. 다들 이런 형태의 에이전트가 다음이라고 본다는 뜻입니다. 코딩에서 검증된 에이전트 방식이 일반 업무로 번지고 있죠.

이를 다시 말하면, AI 프론티어 경쟁이 이제 모델 단품 싸움에서 벗어나고 있다는 뜻입니다. 컴퓨팅, 데이터, 개발 도구에다 업무 에이전트를 모두 만드는 회사들로 판이 재편되고 있다고요.

그리고 스페이스X는 그걸 이틀 만에 주루룩 공개한 겁니다. 모델 성능표에서 1위를 다투는 것과는 종류가 다른 경쟁입니다. 어느 쪽 종합 세트가 먼저 일상 업무에 들어가냐의 싸움이죠.

어떻게 이런 일이 가능했을까

후발주자인 스페이스X가 어떻게 이를 따라잡았을까요?

가장 큰 건 역시 커서 인수입니다. 6월 16일 600억 달러 전액 주식, 벤처 스타트업 인수로는 사상 최대 수준이었죠. 이 거래로 IDE의 기술력과 AI 개발 데이터가 X에서 쌓아 온 데이터와 합쳐졌습니다. 특히, 커서는 에이전트를 쓰면 쓸수록 에이전트형 데이터가 눈덩이처럼 쌓이는 구조입니다. 시간이 갈수록 벌어지는 자산이라는 거죠.

<출처: TechCrunch>

여기에 컴퓨팅 자원이 더해집니다. 스페이스X는 자체 데이터센터까지 가진 곳입니다. 그러니 토큰을 남들보다 싸게 뽑을 수 있죠. 저 2달러·6달러 가격표의 배경이라는 관측이 있습니다. 값을 낮춰도 남는 구조를 가진 쪽이 가격 경쟁을 주도하게 되니까요. 물론 가격 경쟁력을 빼고서라도, 저 프론티어 모델을 만드는 데 들어간 컴퓨팅 자원도 직접 부담할 수 있었을 겁니다.

스페이스X 데이터 센터 <출처: SpaceX>

마치며: 휘청이는 구글과 Top 3의 한 자리

한동안 오픈AI-앤트로픽-구글의 AI Top 3 라인은 단단했습니다.

그런데 구글이 흔들립니다. 제미나이 3.5 프로는 여전히 언제 나올지 아무도 모르고, 8월 들어서는 딥마인드 내부 이탈과 지연 보도가 나왔습니다. 데미스 허사비스, 제프 딘, 존 점퍼 같은 핵심 인력들의 위치가 바뀌었죠. 두 달 내내 나쁜 소식만 쌓였습니다. 중국 모델까지 치고 올라오니 구글 최상위 모델은 어느새 10위권까지 밀렸습니다.

일론 머스크는 “그록 4.7이 3~4주 안에 나오며, 여기에 스페이스X 사내 데이터를 대량으로 투입하고 있다” 예고했습니다. 정말 예고대로라면, 다음 달에 그록이 정말로 GPT와 클로드마저 위협할지도 모릅니다. 분명한 건, 그록을 “이상한 이미지나 잘 만드는 머스크의 그거”로 접어둘 시기는 지났다는 겁니다.

]]>

10년 전 자격증 교재가 AI 테스트를 살렸다

‘Why’는 어디서 오는가

이전 글 ‘AI와 200만 줄의 코드를 작성하며 깨달은 것들’에서 저는 AI에 ‘Why’를 줘야 한다고 했습니다. 그런데 정작 그 Why를 어떻게 줘야 하는지는 쉽지 않습니다. Why를 그렇게 잘 줄 수 있다면, AI가 왜 필요한가 하는 생각도 듭니다. AI가 다 알아서 해줘야 하는 것 아닌가? 싶기도 하고요. 하지만 Why는 결국 ‘내가 원하는 것’입니다. 우리는 AI를 통해 무언가를 얻으려 하고, 그 원하는 것을 얻기 위해 Why를 주는 겁니다.

한 가지 덧붙이면, Why는 곧 우리의 생각이고, 이 생각은 AI를 통해 얼마든지 확장할 수 있습니다. 이를 확장된 사고(Extended Thinking)라고 부르기도 합니다. 우리가 원하는 것을 얻기 위해 자신의 생각을 최대한 넓혀 가는 것이죠.

내가 잘 아는 영역이라면 얼마든지 좋은 Why를 줄 수 있습니다. 문제는 내가 잘 모르는 영역입니다. 잘 모르는 영역에서 답을 구할 때는 환각 증상이 더 많이 나타날 수 있습니다. AI가 준 그 답을 내가 검증할 수 없기 때문입니다.

<출처: 작가>

그래서 잘 모르는 영역에서 답을 구할 때는, AI와 브레인스토밍을 하며(저는 이 방법을 자주 씁니다) 원하는 답을 향해 차근차근 나아가는 방법도 있습니다. 이때는 AI가 길을 잘 찾아가도록, AI 내부가 아니라 밖에서 힌트를 구해 던져 주면 됩니다. 그러면 AI는 그 힌트를 붙잡고 길을 제법 잘 찾아갑니다.

오늘은 AI가 헤매지 않고 내가 원하는 목적지로 길을 잘 찾아가게 만드는 일에 대한 경험을 이야기해 보려 합니다.

미리 요점만 콕 집어보면?

1인 개발이라 테스트를 AI에 맡겼더니, 테스트는 늘 ‘통과’인데 정작 버그는 그대로였습니다. 기준을 주지 않았기 때문입니다.
그 기준은 새로 만드는 게 아니라, 10여 년 전 자격증 공부하며 읽었던 이미 쌓여 있는 문서 안에 있었습니다.
AI가 강력해질수록 낡은 문서의 값은 오히려 오릅니다. 다만 그것을 판단에 쓰고 책임지는 일까지 AI에 넘겨선 안 됩니다.

AI가 늑대 소년이 되다

저는 1인 개발자라 모든 게 부족합니다. 무엇보다 기획과 테스트를 맡아 줄 사람이 없습니다. 그래서 AI로 QA 담당 에이전트를 만들었습니다. AI가 직접 브라우저로 화면을 열어 로그인하고, 값을 입력하며 자동으로 테스트하도록 만든 것이죠. 나온 버그는 슬랙으로 리포트를 받고, 제가 확인해 코드를 고치고 다시 돌렸습니다.

그리고 테스트는 늘 통과했습니다. 저는 아무 생각 없이 결과 리포트만 보고 ‘아, 잘됐구나’ 했습니다. 통과, 또 통과. 테스트 보고서에는 언제나 ‘모두 패스’라고 적혀 있었습니다. 그 깔끔한 성공 리포트 자체가 이상 신호였는데, 당시엔 오히려 안심하고 있었습니다.

서비스 오픈이 얼마 남지 않았을 무렵, 혹시나 하는 마음에 회사 내부 직원에게 같은 화면을 테스트해 보라고 했습니다. 오류가 쏟아졌습니다. 또 AI에 당한 겁니다. 저는 테스트가 정말 잘되고 있는 줄 착각하고 있었습니다. 실제로는 화면에 보이는 표면만 확인됐을 뿐, 정작 중요한 비즈니스 로직은 건너뛰거나 대충 넘어가고 있었습니다.

AI는 그저 테스트를 ‘통과하도록’ 만들어져 있었던 것이죠. 최종 결과를 사람이 확인하지 않고 “네가 확인해라” 하고 맡겼더니, AI는 테스트 항목 몇 개를 만들어 놓고 그냥 통과라고 말해 버린 것이었습니다.

기준을 감으로 만들 수는 없었다

처음 테스트 에이전트를 만들 때, 시간이 없다는 이유로 대충 만들었더니 이런 일이 벌어졌습니다.

왜 이 테스트를 해야 하는지, 무엇을 확인해야 하는지를 명확하게 주지 않아서 발생한 일이었습니다. 테스트 기준이 너무 헐거웠고, 검증 또한 너무 대충이었습니다. 방대한 코드베이스 전체의 테스트를 손수 작성하기에는 시간이 턱없이 부족했습니다.

이걸 어떻게 제대로 만들 수 있을까 고민하다가, 오래전에 따 두었던 테스터 자격증이 문득 떠올랐습니다. ‘아, AI에게 기준을 줘야겠구나.’ 물론 어떤 기준을 왜 줘야 하는지는 당연히 우리의 결정이고, 우리의 일입니다.

AI와 필자가 QA가 잘못된 부분을 다시 검증한 대화 발췌 <출처: 작가>

그런데, 이미 누군가 다 적어 놓았더군요

10여 년 전에 따 놓은 테스팅 자격증(ISTQB). 이력서 한 줄 외에는 거의 쓸 일이 없던 자격증이었습니다.

테스트는 AI의 환각을 막아 주는 최후의 보루라고 생각했기에, 저에게는 아주 중요한 업무였습니다. 환각을 완전히 제거하는 건 불가능하니, 발생할 환각을 ‘이건 환각이다’ 하고 발견해 막아 주는 게 최선이라 여겼습니다. 그래서 테스팅 전략과 시나리오를 처음부터 다시 정리하기로 했습니다.

그 자격증 사이트에 들어가 테스팅 교육 문서들을 다운로드하고, 제가 가지고 있던 몇몇 문서까지 함께 AI에 던져 정리 작업을 시켰습니다. 그런 다음 테스트 에이전트를 다시 작성했습니다. 그러자 AI는 이전에 만들어 둔 테스팅 전략을 수정하고 다시 세우기 시작했습니다. 이제 기준점이 생겼기 때문입니다. 이 기준을 바탕으로 테스팅 전략이 다시 만들어졌고, 전체 시나리오도 새로 작성됐습니다.

사실 저는 개발하면서 기존에 잘 정리된 문서들을 이미 많이 활용해 왔습니다. API 명세서, 국제 표준 스펙 문서 같은 것들이죠. 모두 오랜 시간에 걸쳐 잘 정리된 문서였기에, AI에 아주 좋은 품질의 데이터가 되어 주었습니다.

애자일과 테스팅의 선구자인 켄트 벡(Kent Beck)은 저서 『테스트 주도 개발(Test-Driven Development: By Example)』에서, 테스트를 작성하는 일이 프로그램을 작성하는 것과는 다른 종류의 사고를 요구한다고 봤습니다. 프로그램이 ‘어떻게 작동하게 만들 것인가’를 고민한다면, 테스트는 ‘이것이 어떻게 망가질 수 있는가’를 고민한다는 것이죠.

이 한 문장에 모든 게 담겨 있습니다. 테스트는 성공을 위한 것이 아니라, 실패를 위한 것입니다. 그리고 AI는 실패를 만들어 내는 데 서툽니다. 그래서 우리가 실패하도록 유도하고, 검증해야 합니다.

저는 늘 ‘AI가 모든 걸 자동으로, 그럴듯하게 해주니 편하구나, AI 정말 좋네’ 하며 그냥 넘어가고 있었습니다. 제 일을 AI에 통째로 일임했던 것이고, AI는 결국 이런 결과로 답한 것입니다. 그 뒤로 저는 AI와 협업할 때 항상 확인하고, 질문하고, 검증하는 버릇이 생겼습니다. 맞아 보여도 한 번 더 묻습니다. “너의 결과가 나의 의도(context)와 맞는지 확인하고, 어긋나면 나에게 피드백을 달라”고 말이죠.

감으로 기준을 준 경우와 문서로 기준을 준 경우 비교 <출처: 작가>

문서에서 설계를, 설계에서 자동화를

테스팅 작업을 예로 들었지만, 제가 정작 강조하고 싶은 건 ‘문서’입니다. AI가 환각을 줄이고 더 나은 판단을 하도록 만드는 방법은 멀리 있지 않습니다. 우리가 그동안 한 땀 한 땀 적어 놓은 수많은 기록들이 있습니다. 오타도 있고 잘못 적힌 내용도 있지만, 우리가 일했던 그 흔적들이 AI에는 훌륭한 참고서가 됩니다.

결국 AI 시대에도 중요한 건 데이터였습니다. AI로 개발을 시작한 뒤로는, AI가 문서를 워낙 잘 만들어 주다 보니 제가 예전에 만든 문서들은 촌스럽고 낡은 것이 되어 어딘가에 백업본으로만 남아 있었습니다. 그 파일들 안에는 문서를 쓰며 고민했던 흔적과 시행착오 같은 경험이 고스란히 녹아 있었는데, AI의 멋진 출력물에 취해 저는 그걸 다 잊고 있었습니다.

그 문서를 다시 꺼내게 된 계기가 바로 이번 테스트 오류였습니다. AI에도 데이터를 주고, 가르치고, 쓰게 해야 한다는 당연한 사실을, 저는 AI의 근사함에 가려 잊고 있었던 겁니다.

그래서 PC 어느 구석에 숨어 있던 그 문서들을 AI에 정리시키고, 다시 참고서로 던져 주었습니다. 그러자 AI는 Why와 What, 그리고 Goal을 훨씬 잘 이해한 결과물을 내놓기 시작했습니다.

AI가 스스로 좋은 결과물을 내놓게 하려면, AI가 작업하는 환경 자체가 매우 중요하다는 걸 느꼈습니다. 문서를 주고, 의도를 주고, 형태를 주더라도 결국 모든 것은 저의 의사결정에 따라 움직여야 한다는 사실을 알게 됐습니다.

한 가지 팁을 덧붙이면, 참고 문서가 너무 많으면 프롬프트가 길어져 오히려 답변 품질이 떨어질 수 있습니다. 이럴 때는 AI에 먼저 문서 구조화 작업을 시켜 두면, 훨씬 효율적으로 활용할 수 있습니다.

마치며: 낡은 문서의 값이 오르는 시대

AI에 일을 맡기려는 순간, 우리는 그동안 굳이 명시적으로 답할 필요가 없던 질문들과 마주하게 됩니다. 무엇이 통과이고, 무엇이 실패인가. 확신이 서지 않을 때는 어떻게 할 것인가. 사람에게 맡길 때는 이런 것을 하나하나 정의하지 않습니다. 상대가 알아서 판단해 주니까요.

그리고 그 판단의 기준은 대개 이미 어딘가에 존재합니다. 제 경우엔 이력서 한 줄로만 남아 있던 자격증 교재였고, 다른 분야라면 회계 기준이나 임상 가이드라인, 하다못해 선배가 남긴 낡은 운영 매뉴얼일 수도 있겠죠. 우리는 그런 문서들을 낡았다고 여겨 왔습니다. 이론일 뿐이라고, 현장에선 안 쓴다고, 자격증 딸 때나 보는 거라고요.

하지만 AI 시대에 그 문서들의 값은 오히려 올라갑니다. AI는 그 문서를 읽고 실행할 수는 있어도, 만들어 낼 수는 없기 때문입니다.

AI는 최종 판단을 하지 않습니다. 언제나 그랬듯, 우리의 삶과 마찬가지로 중요한 결정은 결국 자기 자신이 내려야 합니다.

다만 한 가지 경계할 것이 있습니다. AI를 오래 쓰다 보면 ‘생각의 외주화’라는 함정에 빠지기 쉽습니다. AI의 출력이 그럴듯하니 점점 거기에 기대게 되고, 그러는 사이 사고력을 잃어 가는 것이죠. AI에 많이 의존할수록, 우리는 정작 Why를 던지는 일조차 서툴러집니다. 그래서 저는 늘 ‘기준은 내가 결정하고, 내가 책임진다’는 말을 되뇌며 작업합니다.

AI는 그 결과를 책임져 주지 않습니다. AI가 어떤 내용을 주든, 어떤 판단을 내리든, 최종 책임은 그것을 받아들인 우리 몫입니다. 늘 결과를 확인하고 검증해 최적의 답을 얻는 것, 그리고 결정하는 것. 그건 언제나 우리의 일입니다.

<참고>

1. ISTQB® Certified Tester Foundation Level 실라버스 (공식)

2. Kent Beck, 『Test-Driven Development: By Example』, Addison-Wesley, 2002.

]]>

AI 챗봇이 있어도 왜 콜센터 전화는 줄지 않을까?

이미 AI 챗봇 서비스는 많은 회사가 도입했고, 일상에서도 흔하게 접하는 소통 수단이 됐습니다. 그러다 보니 AI 챗봇을 개발하는 기술 또한 빠르게 진화하고 있죠.

실제로 저는 월 수백만 트래픽을 가진 커머스에 AI 챗봇 서비스를 오픈했고, 1년 넘게 운영하고 있습니다. AI 챗봇 서비스 오픈 이후 사용자가 폭발적으로 늘었고, 안정적인 서비스 안착에도 성공했습니다. 매월 이용자도 눈에 띄게 늘어났죠.

결과적으로 오픈 초기 대비 300% 이상 성장하는 눈부신 성과를 거두었습니다. 그러다 보니 상담 운영 비용도 드라마틱하게 줄어들 것이라는 기대감이 생겼죠. 그런데 1년 넘게 운영하면서, 실제로 마주한 결과는 전혀 달랐습니다. 챗봇 이용자 수는 계속 늘고 온갖 정보들을 물어보는데, 실제 콜센터의 문의 비율은 감소하지 않았습니다.

왜 정작 콜센터 문의는 큰 감소가 없었을까요? 기술은 유례없이 화려해졌고, 트래픽은 300%나 폭증했는데, 왜 현장의 역설은 더 깊어만 갈까요? 이 역설을 이해하지 못하면, 사용자들은 우리가 고생해서 만든 AI 챗봇을 누르지 않고 이탈할 겁니다. 이건 AI 챗봇 개발의 문제가 아닙니다. 아마도 AI 챗봇을 도입한 많은 회사들이 마주했거나, 마주하게 될 현실일 겁니다.

미리 요점만 콕 집어보기

지표의 역설: 월 수백만 트래픽의 커머스 서비스에서 AI 챗봇 도입 후 사용자가 초기 대비 300% 이상 급증하며 안정적인 안착에 성공했지만, 정작 콜센터의 인바운드 문의건은 큰 감소가 없는 묘한 괴리감은 무엇일까요?
답답함의 두 가지 결: 사용자가 느끼는 AI 챗봇의 답답함은 ‘환불처럼 직접 처리를 못 해주는 완결성의 한계’와 ‘사람의 질문 속 미세한 숨은 맥락을 이해하지 못하는 한계’라는 두 갈래에서 터져 나옵니다.
진정한 해법: AI 챗봇이 권한 한계에 부딪히는 순간 대화 맥락을 상담사에게 자연스럽게 연결(Hand-over)하고, 숨은 맥락을 온톨로지 기반 지식 그래프로 풀어내는 과정에 집중해야 합니다.

<출처: 작가, AI로 생성>

사용자들이 조용히 X 버튼을 누르는 진짜 이유

멀티 에이전트 구조에 RAG, 지식 그래프 등 AI 개발 기술을 총동원하고, 지속적으로 개선 업데이트한다면 웬만한 질문엔 막힘없이 답변할 겁니다. 하지만 콜센터 문의 비율 관점에서 보면, 사용자들은 여전히 AI 챗봇에 만족하지 못합니다. 챗봇이 대답을 잘 해도, 왜 사용자들은 답답하다고 느낄까요? 많은 회사들이 놓치는 지점이 바로 여기에 있습니다.

1) ‘완결성’의 한계: 요청을 끝까지 처리하지 못하는 에이전트

AI 에이전트는 ‘텍스트로 정해진 매뉴얼을 보여주는 일’은 기가 막히게 잘합니다. 예를 들어, “아이디나 비밀번호를 찾는 절차가 어떻게 되나요?” 같은 단순 질문에는 단 몇 초 만에 완벽한 가이드를 알려줍니다.

문제는 사용자들이 진짜 해결하고 싶은 건 대개 일차원적이지 않다는 데 있습니다. “지난달에 정기 구독 해지 신청을 분명히 했는데, 이번 달에 또 이중 청구가 됐습니다. 환불해 주세요.” 같은 복합적인 맥락이 얽힌 요청들이 많습니다. 또 대부분은 AI 에이전트에 이러한 결제/취소 및 민감한 기능에 대한 처리 권한을 주지 않습니다. 그래서 “마이페이지 > 결제 내역에서 신청해 주세요”라는 안내만 되풀이할 수밖에 없는 게 현실입니다.

즉, 사용자는 요청에 대해 완결성 있는 마무리를 원하지만, 실제 AI 챗봇의 권한상 일을 끝맺기 어려운 게 현실입니다. 이런 상황이 반복되면 사용자들은 답답함과 짜증이 밀려오죠. 그리고 조용히 대화창의 닫기 버튼을 누르고, 콜센터에 전화를 겁니다.

결국 AI가 직접 해결할 수 없는 권한의 한계에 도달했을 때, 얼마나 매끄럽게 사람에게 맥락을 넘겨주느냐(Hand-over)가 핵심 포인트 입니다.사실 최악의 경험은 AI 챗봇과 한참 대화하다 콜센터로 연결되었을 때, 상담사가 “고객님 어떤 문제가 있으신가요?” 하고 처음부터 다시 물어보는 순간입니다.

즉, AI 챗봇의 목표는 ‘무조건 내가 대답해서 고객 질문을 방어하기’가 아니라, ‘내가 못 하는 순간 사용자의 수고를 최소화하며 사람에게 넘겨주기’로 바뀌어야 합니다.

특히 AI 챗봇이 답변에 실패하거나, 사용자가 반복해서 부정적 반응을 보일 때 억지로 대화를 이어가지 않고 바로 ‘상담사 연결 버튼’을 띄워야 합니다. 그리고 상담사 연결을 누르는 즉시, AI 챗봇과 나누었던 대화 요약본과 AI가 확인할 수 있는 API를 호출해, 확인된 사용자의 상황을 상담사 모니터에 실시간 보여줘야 합니다.

그래야 상담사가 연결된 후, “고객님, 조금 전 이중 청구 건으로 당황하셨죠? 대화 기록 확인했으니 제가 바로 환불 처리 도와드릴게요.”라고 대응할 수 있고, 이것이 바로 처리 권한의 한계를 극복하는 가장 자연스러운 흐름입니다.

사람이 처리해야 하는 건은 사람이 나서야 합니다. 괜히 모든 것을 AI로 대응하려고 하면, 좋은 성과로 이어갈 수 없습니다. 사용자들이 끝내 사람을 찾는 이유는 기계 시스템이 채울 수 없는 세 가지 공백 때문인데요. 바로 신뢰, 보안, 책임에 있습니다. 이 부분을 간과해서는 안 됩니다.

돈이 걸려 있거나, 본인의 민감한 개인정보를 다뤄야 하는 고위험 비즈니스 사안일수록, 사용자들은 AI의 그럴듯한 답변보다 “제가 책임지고 이 부분 확실하게 처리해 드리겠습니다.”라는 사람의 음성에 신뢰를 가집니다. 즉, 핸드오버 과정에서 위험도와 복잡성에 따라, AI와 사람간 역할을 정교하게 나누는 하이브리드 협업 구조가 필요하죠.

<출처: 작가, AI로 생성>

자동화 영역: 단순 정보 조회, 예약 변경, 주소지 변경처럼 절차가 명확하고, 리스크가 낮은 정형 문의는 인공지능 에이전트가 24시간 완전 자율형으로 신속하게 처리하는 구조입니다.
협업 영역: 난이도가 조금 있는 문의는 AI가 실시간으로 사용자의 맥락을 분석해 상담사에게 최적의 답변 초안과 가이드를 제안하고, 최종 판단과 커뮤니케이션은 상담사의 재량과 유연성에 맡겨 진행합니다.
사람 전담 영역: 심각한 브랜드 클레임, 복잡한 법적 사안, 극도로 소진된 감정 케어가 필요한 위기 순간에는 AI를 대신 숙련된 전문 상담사가 전면에 나서서 신뢰를 완성해야 합니다.

2) ‘숨은 맥락’의 한계: 온톨로지 기반 지식 그래프의 필요성

또 다른 한계는 사람의 글 안에 숨어 있는 맥락 이해의 한계입니다. 최근 AI 에이전트를 고도화하며, 가장 치열하게 들여다보는 지점은 기술의 화려함보단, 고객 맥락을 다루는 시스템의 정교함과 안정성입니다.

최근 고객들의 탐색 패턴은 키워드 검색에서, 자연어 기반의 추상적인 질의로 급격히 바뀌었습니다. 고객은 이제 조건이 완벽히 정리되지 않은 상태로 AI에 질문을 던집니다. 문제는 자연어 속 숨은 프롬프트(Prompt)와 제약 조건을 엔지니어링 관점에서 어떻게 해결하느냐입니다.

예를 들어, “아이와 함께 갈 만한 휴양지 추천해 주세요.”라는 한 문장 뒤에는, 유모차가 다닐 수 있는 평지 동선, 키즈 전용 시설, 응급실 접근성 같은 디테일한 제약 조건들이 숨어있죠. 질문 속 숨은 맥락을 짚어내지 못하고, 비슷한 답변만 반복하는 AI에 사용자는 더 이상 대화를 이어갈 이유를 찾지 못합니다. 가차 없이 대화창을 닫아버리죠.

단순히 AI 챗봇에게 “더 똑똑하게 대답해 봐”라고 요구하는 건 무리입니다. 단순히 질문의 의미만 파악해서는 부족합니다. 사용자가 최근 앱에서 검색한 기록, 과거의 예약 이력, 그리고 아이 관련 문의 내역까지 유기적으로 엮어내야 합니다. 이런 파편화된 정보들이 하나의 맥락으로 연결될 때, AI는 비로소 ‘아이와 함께라면 유모차 이동이 쉽고, 응급실이 가까운 곳이 좋겠네요.’라는 같은 제안을 건넬 수 있습니다. 이게 바로 우리가 기대하는 진짜 대화의 모습입니다. 기술적으로 보면, 이런 유기적 연결성을 강화 하기 위해서는 단순 RAG(문서 검색)를 넘어 지식 그래프(Knowledge Graph)와 온톨로지(Ontology) 기반의 하이브리드 검색 레이어가 필수적이고요.

온톨로지(Ontology): 데이터의 개념 체계와 관계 규칙(Schema)입니다. 예를 들어, “아이 동반”이라는 개념은 “평지 동선”, “키즈 시설”, “응급실 거리”라는 제약 조건과 연결되어야 한다는 관계 규칙 설계도입니다.
지식 그래프(Knowledge Graph): 그 온톨로지라는 뼈대 위에 실제 데이터(인스턴스)를 노드(Node)와 간선(Edge)으로 연결해 구축한 실체입니다. 예를 들어, “A 리조트(노드) - [갖추고 있다] ➔ 키즈 클럽(노드)”, “A 리조트 - [거리] ➔ B 병원 응급실 10분(노드)”이라는 실제 데이터 그래프입니다.

사용자가 “아이와 갈 휴양지”라고 툭 던졌을 때, 지식 그래프가 ‘아이 동반’에 연결된 필수 제약 조건 노드들을 탐색해 프롬프트에 자동으로 주입합니다. 이 엔지니어링이 밑바탕에 깔려야만, 비로소 AI가 사용자의 숨은 의도와 맥락을 정확히 파악해 답변할 수 있습니다.

3) 기업과 사용자 사이의 목적 불일치

결국 본질을 들여다보면, 기업과 사용자 사이의 심각한 ‘목적 불일치’가 있습니다. 기업은 효율성과 비용 절감이라는 내부 지표에 매몰되어, ‘얼마나 많은 문의를 AI 챗봇 단계에서 답변(방어)했는가’를 성공의 기준으로 삼기 쉽습니다. 사용자의 니즈의 완결성이 아니라, 질문에 답변을 했는가에 집중하는 거죠. 물론 AI 챗봇은 오류가 아니라면, 정해진 대로 기준에 따라 답을 했을 겁니다. 그런데 앞에서도 이야기했지만, 단순히 답변만 했다고 해서 사용자의 니즈가 해소되는 건 아닙니다.

사용자의 목적은 단 하나, “귀찮고 복잡한 문제를 얼마나 적은 수고로 해결할 수 있는가”이기 때문입니다.

이 간극을 메우지 못한 채 서비스 도입을 강행하는 건, 냉정하게 말해 기업이 스스로 감당해야 할 업무와 수고를 사용자에게 은근슬쩍 떠넘기는 것밖에 안 됩니다. 원하는 답을 찾기 위해 사용자가 필터 메뉴를 이리저리 누르고, 질문을 바꾸는 일을 직접 하게 만들기 때문입니다. 그렇게 기계적인 응대에 지친 사용자의 문의는 콜센터에 연결되는 순간, 분노가 결합한 고난도 클레임으로 변질되곤 합니다. 결국 상담사의 감정 노동과 평균 처리 시간(AHT)이 오히려 폭증하는 부메랑으로 돌아오죠.

성패는 ‘사용자의 노력을 얼마나 줄였는가’에 있다

그렇다면 프로덕트 팀은 여기서 어떤 시사점을 얻고, 관점을 전환해야 할까요? 많은 조직이 “챗봇 기능을 더 고도화하자.”라며 성능을 올리는 데 집중합니다. 하지만, 핵심은 챗봇 대화 창 안의 프롬프트 몇 줄이나 단일 기능 스펙을 고도화하는 데 있지 않습니다. 고객 문제 해결 여정 전체를 지원할 수 있는 체계로 확장해야 합니다.

트래픽이 300%나 늘어났어도 콜센터 문의량은 그대로였던 진짜 원인은, 챗봇이 해결하지 못한 문제가 다음 단계로 이어지지 못하고, ‘단순 챗봇 응대 처리율’이라는 단편적인 지표 뒤에 숨어있었기 때문입니다.

프로덕트 팀이 가져야 할 관점의 전환은 명확합니다.

지표의 패러다임 전환 (자동 처리율 ➔ 여정 완료율): “챗봇이 얼마나 많은 문의에 답변했는가”라는 공급자 중심 지표를 버려야 합니다. 챗봇 대화부터 사람 상담 연결까지 포함해, 고객이 자신의 문제를 완결짓는 데 걸린 총 시간과 수고가 얼마나 줄었는가를 핵심 지표(KPI)로 삼아야 합니다.
시스템 인프라의 전환 (단일 대화창 ➔ 여정 파이프라인): 앞서 살펴본 것처럼, 온톨로지 기반 지식 그래프로 고객의 숨은 맥락을 정교하게 읽어내고, AI의 한계 지점에서는 대화 요약 및 맥락을 동기화해 사람에게 매끄럽게 넘기는 [맥락 추론 ➔ 오케스트레이션 ➔ 핸드오버] 전체 파이프라인을 구축해야 합니다.

결국 AI 기술의 화려함보다 중요한 것은 ‘고객의 노력을 얼마나 줄여주었는가’입니다. 챗봇이 못 하는 일은 솔직하게 인정하고, 다음 해결책으로 매끄럽게 연결해 주는 시스템 구조야말로 사용자가 AI 챗봇 창을 닫지 않게 만드는 첫걸음입니다.

마치며

우리는 기술의 홍수 속에서 종종 본질을 잊곤 합니다. 어떤 생성형 AI 모델을 썼는지, 프롬프트 파인 튜닝을 얼마나 정교하게 했는지는 우리 개발팀 내부의 치열한 엔지니어링 기록일 뿐, 서비스를 이용하는 사용자에게 중요한 건 아닙니다. 사용자의 좋은 경험은 “와, 이 서비스 AI가 대단하네.”라고 인지하는 순간이 아니라, 내가 겪은 불편함이 기분 좋게 해결되어, “어라? 생각보다 쉽게 끝났네.”라고 느끼는 짧은 찰나에 있습니다.

여러분이 만든 AI 챗봇은 어떤가요? 지금 바로 브라우저를 켜고, 우리 서비스의 가장 대표적인 케이스를 직접 끝까지 해보시기를 권합니다. 사용자가 되어 직접 질문을 던지고, 챗봇과 씨름하며 그 답답함을 온몸으로 겪어보세요. 우리가 만든 프로덕트가 정말 고객을 돕고 있는지, 아니면 그저 시간만 끌고 있는지. 그 냉정한 현실을 마주하는 게 진짜 개선의 시작입니다.

]]>

지금 전 세계에서 가장 인기 있는 에이전트 스킬 Top5는 뭘까?

<출처: 작가>

스킬(Skill)이란, 에이전트에 건네는 온보딩 문서에 가깝습니다. 무언가 일을 할 때 필요한 모든 것을 정리해 둔 문서로, 실제 그 일을 해야할 때만 읽는 안내서죠. Anthropic은 이를 두고 “에이전트가 특정 작업을 더 잘 해내도록 동적으로 발견하고 불러오는, 지시문·스크립트·리소스를 담은 폴더”라고 정의해요. 초기에는 에이전트를 잘 쓰려면 “스킬만 잘 써도 절반은 간다”는 말이 나왔을 만큼 핵심 중의 핵심입니다.

이러한 스킬은 목적과 과정을 말로 설명하고, 에이전트한테 “만들어 줘”라고 요청하는 것만으로 쉽게 만들 수 있어요. 저도 작업 하나가 잘 마무리되고 나면, 잊지 않고 이 일을 스킬로 만들어달라고 요청하는 편입니다. 문제는 스킬을 서너 개 만들어 쓰다 보면 슬슬 의심이 간다는 데 있어요. 하다 보면 내가 지금 이걸 제대로 만들고 있는 게 맞나? 싶어진다는 거죠.

그럴 때 제일 빠른 답은 남이 잘 만든 걸 열어보는 거라고 생각해요. 그래서 사람들이 제일 많이 쓰는 스킬들을 찾아봤습니다.

‘인기’의 기준은 GitHub 스타로 잡았습니다. 각 레포는 릴리스 파일을 배포하지 않아서 다운로드 수라는 게 아예 잡히지 않습니다. 대안으로 쓰이는 skills.sh 설치 수는 운영사 Vercel이 자사 CLI로 직접 집계하는 값이라 원자료를 밖에서 확인할 방법이 없고요. 그래서 써 보고 좋았던 사람들이 누른 “좋아요”, 즉, 스타 수를 기준으로 잡았습니다.

위의 순위는 2026년 8월 10일 기준 값이며, 따라서 개별 스킬이 아닌 “레포지토리” 전체를 다룹니다.

2026 스킬 순위 1~5위

각각 세 가지 기준으로 정리했습니다. 어디에 쓰는 물건인지, 안에서 무슨 일이 벌어지는지, 나머지 넷과 뭐가 다른지.

1위 obra/superpowers· 269,762★

<출처: GitHub, 작가 캡처>

이 스킬을 적용하면, 코딩 에이전트를 켜는 순간부터 스킬이 동작합니다. 뭘 만들려는 낌새가 보이면 에이전트가 코드로 달려가지 않고 한 발 물러서서 “진짜 하려는 게 뭐냐”부터 묻죠. 설계 문답에서 격리 작업 공간, 계획 분해로 이어지는 앞 세 단계를 지나 테스트·리뷰·병합 정리까지 일곱 단계가 순서대로 이어져요.

어찌나 강력한지 GitHub 전체 스타 수로 14위에 오를 만큼 큰 인기를 얻었죠.

이 레포의 정체는 작동 방식에 있습니다. 스킬 14개만 들어 있는 게 아니라, 세션을 열 때마다 자동으로 도는 스크립트가 같이 있습니다. 이 스크립트가 매번 부트스트랩 스킬의 전문을 컨텍스트에 밀어 넣고, 그 부트스트랩이 나머지 스킬을 제때 깨웁니다. 지시문은 선택지를 지우는 쪽으로 쓰여 있습니다. “IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.” 스킬이 적용되는 작업이면 선택권이 없으니 쓰라는 겁니다.

다른 점은 스킬 자체를 테스트 주도로 만든다는 데 있습니다. 스킬 내용을 고치는 PR은 스킬을 켠 실행과 끈 실행의 평가 결과를 봤을 때 괜찮아야 통과됩니다. 평가 근거 없이는 받지 않겠다고 선언까지 해뒀고요. 코드를 곧바로 만들기보다는 설계 문서와 승인 기록을 우선으로 봅니다. 대신 큰 단위 맥락이 매 세션 주입되는 구조라, 시작하자마자 22,000토큰을 넘게 먹었다는 이슈가 올라온 적이 있습니다.

설치 명령어

/plugin install superpowers@claude-plugins-official.

2위 affaan-m/ECC· 239,034★

<출처: GitHub, 작가 캡처>

ECC란 레포 이름은 “Everything Claude Code”의 약자입니다. 계획부터 테스트·구현·리뷰·검증·기억까지 엔지니어링 절차를 설정 자산으로 한 번에 까는 배포판이에요. 기능 개발은 /ecc:plan, 코드 리뷰는 새 컨텍스트에서 /code-review처럼 진입점이 명령어로 정리돼 있습니다.

규모는 소개할 다섯 개 가운데 제일 큽니다. 레포 안 SKILL.md 파일이 897개인데, 번역본과 하네스별 사본을 걷어내면 정본은 284개라고 합니다(2026-08-10 기준).

문제는 필요한 스킬만 골라 불러주는 라우팅 장치가 없다는 점입니다. 전부 설치하면 이름과 설명만으로 매 세션 약 17,600토큰을 상시 점유해요. 그러니 레포 스스로도 필요한 것만 선택해 설치할 것을 추천합니다.

개인적으로 재밌다고 생각한 건 skill-comply입니다. claude -p를 실제로 돌려 도구 호출 기록을 잡고 프롬프트 강도를 단계별로 낮춰가며 스킬이 진짜 지켜지는지를 잽니다. 말하자면 스킬을 감사하는 스킬이죠. 또, 국내 개발팀이라면 inherit-legacy-style 쪽도 괜찮습니다. 손으로 짠 레거시 프로젝트에 AI가 학습한 주류 관용구를 밀어붙이는 “스타일 드리프트”를 막으려고, 코드베이스의 암묵 규칙을 스캔해 문서로 고정하고 이후 코딩 작업의 제약으로 삼죠.

설치 명령어

 ./install.sh --target claude --skills tdd-workflow,security-review(뒤의 스킬들은 골라서 입력)

3위 mattpocock/skills· 211,297★

<출처: GitHub, 작가 캡처>

TypeScript 교육자 Matt Pocock이 자기 .agents 디렉터리를 그대로 공개한 35개짜리 스킬 모음입니다. 간판 스킬은 이름 그대로 아이디어와 설계를 캐물어 굽는(grill) 시리즈예요. 머릿속 생각만 다듬고 싶으면 /grill-me, 코드베이스에 문서까지 남기려면 /grill-with-docs. 상황별 진입점이 이런 식으로 갖춰져 있습니다.

그중 grill-me의 전문이 이렇습니다.

---
name: grill-me
description: A relentless interview to sharpen a plan or design.
disable-model-invocation: true
---

Run a `/grilling` session.

한 줄이죠. 이 명령이 호출하는 열 줄짜리 grilling 스킬에 쓰인 건 인터뷰 절차입니다. 이때 무엇을 물을지는 에이전트의 일이라 직접 조회할 수 있는 걸 사람에게 묻지 않습니다. 그 대신 결정은 사람 몫이고요. 지금 답할 수 있는 질문을 묻고, 그 답변들을 모두 취합하면 다음으로 궁금한 것들을 묻습니다.

그러니 이 레포가 주는 건 산출물 템플릿이 아니라 일 하기 전에 스스로 할 일을 캐물어보라는 행동 규약에 가깝습니다. 파일도 거의 안 남아요. 참고로 grill-me는 /grilling이 함께 있어야 도는 한 줄짜리 래퍼라, 스킬을 골라 설치하는 경로에서 이 파일만 받으면 동작하지 않습니다.

설치 명령어

/plugin marketplace add mattpocock/skills.

4위 multica-ai/andrej-karpathy-skills· 200,937★

<출처: GitHub, 작가 캡처>

이건 앞서 본 스킬 레포들과 조금 다릅니다. 스킬 패키지가 아니라 에이전트 지침 문서 한 장이거든요. AI 업계에서 가장 유명한 개발자 중 하나인 Andrej Karpathy가 LLM 코딩의 함정을 관찰해 올린 X 게시물에서 파생한 CLAUDE.md 65줄이 전부입니다. 파일 여덟 개를 다 합쳐 20KB이고 실행 코드는 0줄이에요. 훅도 스크립트도 서브에이전트도 없는 건 이것뿐입니다. 스킬 디렉터리 구조는 공개 이튿날부터 외부 기여자들이 배포 호환용으로 덧씌운 껍데기고요.

원칙은 네 가지입니다. 코딩 전에 생각하고, 단순하게 가고, 수술하듯 고치고, 검증 가능한 목표를 잡으라는 것. “200줄을 썼는데 50줄로 될 일이면 다시 써라”, “바뀐 모든 줄은 사용자의 요청으로 곧바로 거슬러 올라가야 한다” 같은 지침들이죠. 새로운 능력을 주는 게 아니라, 흔히 벌어지는 사고 유형에 이름과 판정 기준을 붙여주는 겁니다.

짚을 것이 있습니다. Karpathy는 이 레포의 작성자도 기여자도 아닙니다. 그가 언급하거나 승인한 기록도, 반대로 부인한 기록도 딱히 없고요. 어쨌든 그의 유명세를 타고 스킬은 큰 인기를 얻었습니다.

설치 명령어

/plugin marketplace add multica-ai/andrej-karpathy-skills.

5위 anthropics/skills· 167,251★

<출처: GitHub, 작가 캡처>

Anthropic이 직접 운영하는 공식 레퍼런스입니다. Claude의 문서 생성 기능을 실제로 구동하는 프로덕션 스킬 docx·pptx·xlsx·pdf와 예제를 합쳐 17종이 들어 있어요. 다섯 중 유일하게 결과물을 뽑아주는 쪽입니다. 회사 PPT 템플릿을 던져주면 전 슬라이드 썸네일로 레이아웃을 고르고 슬라이드를 복제해 채운 뒤, 템플릿이 원래 갖고 있던 오류와 새로 생긴 오류를 분리해 검증하는 데까지 스크립트로 짜여 있습니다.

가장 눈에 띄는 건 frontend-design이에요. 스크립트도 참조 파일도 없는 55줄짜리 마크다운 한 장인데, 지금 AI가 만드는 디자인이 몰리는 세 가지 모양을 콕 집어 반대로 가라고 지시해요. 크림색 배경에 고대비 세리프를 얹은 조합은 #F4F1EA라고 헥스 코드까지 박아뒀어요. 브리프가 방향을 지정하지 않았다면, 적어도 이 기본값으로 가지 말라는 겁니다. 비슷한 프롬프트를 한 번 더 돌려 같은 곳에 도착하면 “그건 선택이 아니라 기본값”이라며 고쳐야 코드 작성을 허용하는 자기 표절 테스트도 걸려 있고요.

다만, 실무에서 걸리는 건 라이선스입니다. 가장 탐나는 문서 스킬 4종은 독점으로(“source-available, not open source”가 README의 표현입니다), 오픈소스인 쪽은 나머지예요. 보통 “스킬은 공짜”라고 이해하는 분들이 많지만, 이걸 포함해 수익화할 때는 조심해야 합니다.

설치 명령어

/plugin marketplace add anthropics/skills.

초인기 스킬들의 공통점

지금까지 설명한 다섯 개 스킬의 성격과 특징, 주의사항을 모아 놓은 표입니다. 나란히 놓고 보니 비슷한 점이 보입니다.

1) 스킬은 통제형

superpowers의 테스트 스킬은 “테스트보다 코드를 먼저 썼다면? 지워라. 처음부터 다시”라고 합니다. karpathy 지침은 “인접한 코드·주석·서식을 ‘개선’하지 마라”고 하고요. mattpocock의 grilling은 “사용자가 합의에 도달했다고 확인해 주기 전까지는 그것에 대해 행동하지 마라”입니다.

셋 다 무엇을 하라는 지시가 아니라 무언가 맘대로 못 하게 막는 문장입니다. 그러니까 인기 상위권 스킬이 팔고 있는 건 통제입니다. 코드부터 치지 마라, 먼저 캐물어라, 가정하지 마라.

2) 누군가의 사고방식을 흉내 내기

또 하나 재미있는 건 특정 개인의 사고방식이나 업무 방향을 정리해 기록해 둔 것들이 많다는 점입니다. grill-me는 Matt Pocock이 정리한 인터뷰 구조를 따르고, karpathy 지침은 애초에 한 사람의 X 게시물에서 시작했습니다. 스킬이라는 개념 자체가 결과물 템플릿이 아니라 누군가의 머릿속 기준을 옮겨 적은 메모에 가깝기 때문입니다.

3) 중요한 건 “왜?”

특히 흥미로운 건 이들 스킬이 결과를 만들기보다, “왜?”를 정리해 주는 데 있다는 겁니다. grill-me, grill-with-docs는 이름부터 캐묻는 행위(grilling)이고, karpathy 지침의 “수정한 모든 건 사용자의 요청으로 곧바로 거슬러 올라가야 한다”도 결국 이유를 계속 되짚는 규칙입니다. superpowers는 코드를 쓰기 전에 “진짜 하려는 게 뭐냐”부터 묻고요. 저는 결국 사람들이 AI와 함께하며 공통적으로 겪고 있는 문제는 “어떻게”가 아닌 “왜”에 있다는 방증이라고 생각합니다.

그래서, 직접 만들어 쓰는 게 나을 수 있다

결국 이렇게 “왜”를 파고들다 보면 “어떻게”를 다룬 스킬은 직접 만들어 쓰는 게 낫습니다.

만드는 것도 참 쉽습니다. Anthropic이 공개한 공식 스킬 skill-creator가 있는데요. 대화로 초안을 잡은 다음, 테스트 프롬프트를 놓고 스킬을 준 실행과 안 준 실행을 같이 띄워 채점하고, 그 점수로 스킬을 고칩니다. 감이 아니라 수치로 다듬는 구조죠. Claude Code나 Cowork에서 보통 “스킬 만들어 줘”라고 하면 자동으로 이 스킬이 돌아가고는 합니다.

<출처: GitHub, 작가 캡처>

이때 설명문을 조금 밀어붙이듯 쓰라는 공식 지침이 있습니다. 특히 “이럴 때 쓴다”를 구체적으로 적어야 실제로 호출된다는 겁니다. 개인이 만든 스킬의 가장 큰 약점 중 하나는 결국 “쓰이지 않는다”는 겁니다. 알아서 필요할 때 동작하며 도움을 줘야 하는데, 귀찮은 명령어가 붙다 보면 잘 안 쓰이게 되는 거죠. 그러니 무슨 범위까지, 언제 쓸 스킬을 만들지를 미리 잘 생각하면 좋습니다.

이런 맥락에서 최근 잘 쓴 건 “Record a skill”입니다. 화면을 녹화하면 Claude가 관찰한 내용으로 초안을 제안하는 기능입니다. 화면 녹화를 켜고 반복해 하는 일을 순서대로 하니 AI가 그대로 스킬로 만들어 줬고, 꽤 만족하며 스킬을 쓰고 있습니다. 다만 Claude for Mac의 Cowork 전용이라 Windows에서는 안 되는 제약이 있습니다.

마치며

지금의 스킬 순위표를 조사하고 보니, 결국 내 일에 큰 영향을 끼치는 스킬은 직접 만들어야 겠다고 느꼈습니다. 돌고 돌아 제가 만든 스킬이 더 편하더라고요.

그래도 다섯 개 스킬을 뜯어보는 동안 건진 게 하나 있습니다. 스타 수가 높은 스킬 대부분은 대단한 기능이 아니라, 에이전트가 날뛰는 것을 멈춰 세우는 일을 한다는 것. 그 요령으로 내 에이전트가 자꾸 반복하는 실수 하나를 골라 문서로 적어 보시면 어떨까요? 그 문서 하나가 세계에서 가장 인기 있는 스킬의 방법론들보다 나을 수 있습니다.

]]>

B2B AI SaaS가 성공하려면 뭐가 중요할까?

국내외를 막론하고 B2B AI SaaS를 운영하는 경영진(CEO, CTO, CPO)이 세일즈 현장에서 마주하는 가장 큰 장벽은 무엇일까요? 뛰어난 모델 성능이나 유용한 기능에도 불구하고, 고객사에서 계약 검토가 수개월씩 지연되거나 무산되는 것일 거라고 생각합니다.

최근 해외 정책 동향을 보면, 일본 정부는 미국 빅테크 기술 종속 극복을 위해 국가 차원의 생성형 AI 정책 드라이브를 강하게 걸고 있습니다. 국내 AI 인프라 지원책과 더불어, 의료·범죄 기록 등 민감한 개인정보도 AI 모델 개발과 학습용으로 수집·활용할 수 있도록 규제를 완화하는 개정 개인정보보호법안이 2026년 7월 통과되었습니다.

하지만 정부가 규제를 풀어주어도 기업 세일즈 현장의 분위기는 쉽게 변하지 않습니다. “우리 회사의 핵심 자산과 고객 데이터가 외부 LLM에 유출되거나 학습되면 어떻게 하지?”라는 근본적 불안이 여전하기 때문입니다.

이번 글에서는 해외 규제 완화와 현장에서의 인식 차이를 데이터로 살펴보고, 한국 B2B AI SaaS 기업이 고객사 보안 심의를 뚫고 세일즈 리드타임을 단축하기 위해 제품 아키텍처에 적용해야 할 3가지 하이브리드 보안 전략을 정리해 보겠습니다.

미리 요점만 콕 집어보면?

비즈니스 인사이트: 제도적 규제 완화가 기업의 AI SaaS 구매로 즉시 연결되지 않으며, B2B 세일즈의 성패는 공급사가 ‘기술적 데이터 통제권’을 제품 수준에서 증명하는 데 달렸습니다.
전략적 트레이드오프: 고객사의 물리적 망 분리(Single-tenant) 요구는 SaaS의 스케일업을 저해하므로, 데이터 거점(Data Residency) 고정과 암호화 키 분리를 결합한 하이브리드 인프라로 타협점을 찾아야 합니다.
실행 가능한 거버넌스: 과도한 마스킹으로 인한 답변 품질 저하를 막는 ‘민감도 기반 하이브리드 라우팅’과 관리자 감사 로그(Audit Log) 기반의 ‘Trust UX’를 통해 세일즈 리드타임을 실질적으로 줄일 수 있습니다.

열리는 규제, 닫히는 지갑

글로벌 AI 시장에서 일본 정부의 정책 행보는 대표적인 규제 완화 드라이브 사례입니다. 디지털청 장관 기자회견(2026년 6월 12일) 및 디지털 사회 구상 회의(2026년 5월 22일) 발표에서 보듯, 자체 ‘Sovereign AI’ 생태계를 조속히 구축하기 위해 정부 차원에서 민감 정보 활용 규제를 전폭적으로 완화해 왔습니다.

그러나 정부의 전폭적인 제도 지원에도 불구하고, 실제 시장의 도입 속도는 기대에 미치지 못하는 현상을 보입니다. 데이코쿠데이터뱅크(TDB)가 발표한 생성형 AI 동향 조사(2026년 3월, 유효응답 10,312사) 지표는 한국 B2B AI SaaS 경영진에게 매우 유용한 실증 벤치마크를 제공합니다.

높은 효용성 (86.7%): 생성형 AI를 도입해 활용 중인 기업 중 86.7%는 “업무 효율과 성과가 뚜렷하다”며 유용성을 높이 평가했습니다. 기술의 성능이나 비즈니스 가치에는 의문이 없습니다.
낮은 도입률 (34.5%): 그럼에도 전체 기업의 생성형 AI 도입률은 34.5% 수준에 머물러 있습니다. AI를 도입한 기업은 만족하지만, 전체 기업 10곳 중 6곳 이상(65.5%)은 여전히 도입을 주저하며 관망하는 것입니다.

<출처: 데이코쿠데이터뱅크>

정부가 규제를 풀어주고 기술 효과도 입증되었는데, 왜 65.5%의 기업은 도입을 망설일까요? TDB 조사에 따르면 기업들이 꼽은 생성형 AI 도입 시 우려·과제 1위는 바로 ‘정보의 정확성(50.4%)’이었으며, 이어 ‘전문인재·노하우 부족(41.3%)’, ‘활용 업무 범위(40.0%)’, 그리고 ‘정보 유출 리스크(33.5%)’가 주요 원인으로 나타났습니다.

즉, 기업들은 단순히 보안 유출 하나만 두려워하는 것이 아닙니다. “AI 답변의 정확도와 업무 맥락을 유지(50.4%)하면서도, 핵심 데이터 유출 위험(33.5%)을 어떻게 철저히 통제할 것인가”라는 ‘답변 품질과 보안 통제권의 동시 충족’을 요구하고 있는 것입니다.

<출처: 데이코쿠데이터뱅크>

이러한 우려와 컴플라이언스 부담은 기업 규모별 도입 격차로도 나타납니다. 도쿄상공리서치(TSR)의 조사(2026년 4월, 유효응답 6,327사) 지표를 살펴보면 그 차이가 드러납니다.

[2026년 기업의 생성형 AI 도입 지표 및 양극화 현상]

1. TDB 조사(10,312사 대상)

도입 기업의 업무 만족도: 86.7% (기술적 효용은 이미 검증됨)
주요 우려·과제 원인: 정보 정확성(50.4%), 전문인재 부족(41.3%), 정보 유출 리스크(33.5%)

2. TSR 조사(6,327사 대상)

대기업 AI 활용 비율: 59.1% (자체 보안 검토 및 프라이빗 구축 여력 보유)
중소기업 AI 활용 비율: 30% 안팎 (보안 및 정확성 검토 인력 부재로 약 2배 격차)

TSR 데이터에 따르면 대기업의 생성형 AI 활용 비율은 59.1%에 달하는 반면, 중소기업은 30% 안팎에 그쳐 약 2배의 도입 격차를 보입니다. 대기업은 내부 인력을 동원해 SaaS 공급사와 별도의 프라이빗 구축이나 커스텀 보안 계약을 협상할 여력이 있지만, 중소기업은 보안 검토 및 답변 정확성 검증 인력 자체가 부족해 우려가 해결되지 않으면 도입을 유예해 버리기 때문입니다.

한국 B2B AI SaaS 경영진이 이 데이터에서 얻어야 할 시사점은 명확합니다. 세일즈 타겟을 확장하려면, 고객이 복잡한 설정 없이도 안심하고 정확한 답변을 얻을 수 있는 ‘완제품 형태의 기술적 보안 신뢰(Secure by Default)’를 제품 아키텍처로 증명해야 한다는 점입니다.

제도적 규제 완화는 시장 진입을 위한 신호일 뿐입니다. 실제 매출 전환을 위해서는 법률적 기준을 넘어 고객사의 보안 불안을 해소하는 제품 수준의 신뢰 엔지니어링이 필수적입니다.

물리적 망 분리 요구를 극복하는 ‘하이브리드 인프라 전략’

B2B AI SaaS 기업이 대기업 고객사를 대상으로 세일즈를 진행할 때 마주하는 첫 번째 장벽은 보안 부서의 ‘물리적 망 분리(Single-tenant)’ 요구입니다. “자사 데이터가 타사와 섞여선 안 되며, 전용 클라우드 환경에 독립 배포해 달라”는 요구조건이죠.

실제로 저희 팀에서 금융·제조 업종 대기업 고객사의 보안 심의에 참여했을 때, 보안 부서에서 가장 먼저 내건 조건이 바로 이 물리적 망 분리였습니다. 처음에는 이 요구를 그대로 수용해, 고객사별 독립 인프라(싱글테넌트)를 설계하는 방향을 검토했습니다.

그러나 실제로 설계를 진행해 보니 문제는 예상보다 심각했습니다. 고객사가 추가될 때마다 별도의 인프라 스택과 배포 파이프라인을 구축·운영해야 하므로, 인프라 비용이 멀티테넌트 대비 수 배로 증가했습니다. 신기능 배포 시 모든 고객 환경에 개별 적용해야 하는 운영 복잡도도 급격히 높아졌고요. 이 방식으로는 SaaS 사업의 수익성과 배포 속도를 유지하면서, 고객 기반을 확장하는 것이 사실상 불가능했습니다.

이런 경험을 통해 저희가 내린 결론은 물리적 격리 요구를 액면 그대로 수용하는 것이 아니라, 고객이 진정으로 원하는 것, 즉 ‘자사 데이터가 타사와 논리적으로 완전히 분리되어 있다는 확신’을 기술적으로 증명하는 것이었죠. 그래서 대안으로 선택한 것이 바로 ‘지리적 데이터 거점(Data Residency)’과 ‘논리적 암호화 격리’를 결합한 하이브리드 아키텍처였습니다.

저희 팀의 경우, 데이터 역외 반출을 우려하는 일본 기업 고객을 위해, 모든 데이터 저장·처리 영역을 AWS 도쿄 리전(Primary)과 오사카 리전(DR, 재해복구)으로 고정하는 Data Residency 설계를 적용했습니다.

고객사 보안 담당자에게 ‘데이터가 국경을 넘지 않는다’는 점을 인프라 구성도 레벨에서 증명할 수 있도록 한 겁니다.

또한 SaaS 배포 효율을 지키기 위해 단일 멀티테넌트 DB 구조는 유지하되, 행 수준 보안(RLS, Row-Level Security)을 적용했습니다. 그리고 AWS KMS를 연동해 고객사가 데이터 암호화 키(BYOK, Bring Your Own Key)를 직접 소유·관리하도록 구성했습니다.

이러한 설계로 인해 “인프라는 멀티테넌트이지만, 데이터 복호화 권한은 귀사의 전용 키에 묶여 있어 SaaS 공급사도 들여다볼 수 없다”는 점을 들어 물리 격리와 동등한 수준의 데이터 안전성을 증명할 수 있었습니다. 결과적으로 독자적인 싱글테넌트 구축 대비 인프라 운영 비용을 크게 절감하면서도, 고객의 요구사항을 만족시킬 수 있었죠.

TIP: 만약 비슷한 상황에 놓였다면, 고객의 요구사항에 수긍하여 SaaS의 확장성을 포기하지 마세요. 고객이 실제로 원하는 것은 ‘데이터가 분리되어 있다는 확신’이며, 데이터 거점 고정과 암호화 키 분리를 결합한 하이브리드 전략으로 이 확신을 기술적으로 증명해야 합니다.

AI 답변 품질을 지키는 ‘민감도 기반 하이브리드 라우팅’

두 번째 기술적 난관은 개인정보(PII)마스킹과 AI 답변 품질 간의 트레이드오프입니다.

외부 LLM(OpenAI, Claude 등)으로의 데이터 유출을 막기 위해 PII 필터링을 적용하면, 오탐(False Positive)으로 인해 핵심 고유명사나 내부 제품 코드까지 마스킹되어 버리는 문제가 발생합니다.

저희 팀도 초기에는 오픈소스 PII 필터링 라이브러리를 일괄 적용하는 방식을 택했습니다. 그런데 운영 과정에서 일본어 고유명사와 전문 비즈니스 용어가 개인정보로 오탐되어 마스킹되는 문제가 반복적으로 발생했습니다. 예를 들어, “오사카 지점 A100 부품 납품 일정”이라는 업무 프롬프트가 "[LOCATION] 지점 [CODE] 부품 납품 일정"으로 변환되면, LLM은 업무 맥락을 잃고 엉뚱한 답변을 출력합니다. 보안을 위해 적용한 필터가 오히려 서비스 품질을 훼손하는 상황이었죠.

이 문제를 해결하기 위해 저희는 일괄 필터링 대신, 민감도에 따라 처리 흐름을 나누는 ‘하이브리드 라우팅(Hybrid Routing)’ 아키텍처를 도입했습니다.

실시간 민감도 감지: 사용자가 프롬프트를 입력하면 경량 NLP 분류 모델이 사내 기밀 및 PII 포함 여부를 실시간으로 측정합니다.
일반 데이터 외부 라우팅: 보안 우려가 적은 일반 업무 프롬프트는 최소한의 PII 마스킹 후 LLM API로 처리하여 처리 속도와 지능 수준을 최상으로 유지합니다.
민감 데이터 로컬 라우팅: 오탐 위험이 크거나 외부로 내보낼 수 없는 핵심 민감 데이터는 외부 인터넷망을 타지 않고 사내 VPC 내에 배포된 경량 오픈소스 LLM(Llama-3, Qwen 등)으로 직접 리다이렉션합니다.

이 하이브리드 라우팅을 적용하니, 외부 유출 위험을 근본적으로 차단하면서도 프롬프트 훼손율을 크게 줄일 수 있었는데요. 일괄 마스킹 방식에서 문제가 된 고유명사·제품 코드 오탐 이슈가 해소되면서, AI 서비스의 답변 품질과 보안 컴플라이언스를 동시에 확보할 수 있었죠.

TIP: 무조건적인 정보 훼손으로 AI 서비스의 핵심 성능을 떨어뜨리지 마세요. 민감도 판별에 따라, LLM API와 사내 로컬 LLM을 분기 처리하는 하이브리드 라우팅이 효용성과 보안을 모두 잡는 전략입니다.

수십 페이지 보안 서류를 대체하는 ‘Trust UX’

아무리 뛰어난 보안 아키텍처를 구축했더라도, 의사결정권자가 체감하지 못하면 최종 계약으로 연결되기 힘듭니다. Trust UX를 설계하게 된 계기는 몇몇 고객사의 도입 검토 과정에서 겪은 경험이었는데요.

몇몇 고객사의 보안 책임자는 저희가 작성한 문서에 “데이터를 AI 학습에 활용하지 않는다”고 명시했음에도, “직접 눈으로 확인하기 전에는 결재를 올릴 수 없다”고 답했습니다. 보안 서류에 아무리 완벽한 보안 스펙을 기술해도, 보안 담당자가 직접 확인할 수 없으면 계약까지 이어지지 않았죠.

이 경험을 계기로, 보안에 대한 내용을 문서가 아닌 사용자 경험(Trust UX)을 통해 직접 체감하도록 해야 한다는 판단을 내렸습니다.

실시간 안심 문구: 서비스 화면 하단에 "입력하신 데이터는 AI 학습에 활용되지 않으며, 암호화 처리 중입니다"라는 안내 문구와 실시간 보안 상태를 상시 노출하여 실무자의 데이터 업로드 불안을 낮췄습니다.
관리자 자율 통제 대시보드(Compliance Admin):
비학습 Opt-out 토글: 관리자 페이지에서 스위치 클릭 한 번으로 AI 학습 비활성화 상태를 자율적으로 통제할 수 있게 했습니다.
감사 로그(Audit Log)시각화: 프롬프트 데이터의 마스킹 여부, 처리된 리전 위치, 활용된 모델 종류를 실시간 타임라인으로 투명하게 확인할 수 있는 대시보드를 구축했습니다.

이후 보안 심의 과정에서 수십 페이지의 관련 서류를 주고받는 대신, 실제 작동하는 관리자 화면의 감사 로그와 자율 통제 토글 기능을 직접 시연하는 방식으로 전환했고요. 그 결과 이전에 도입을 보류했던 고객사가 심의를 재개했고, 기존에 수개월이 소요되던 보안 검토 프로세스를 단축하는 성과를 얻었습니다.

도입을 결정한 고객사들에게 이유를 물은 결과 “화면에서 직접 확인하고 통제할 수 있다는 것이 안심이 된다”는 피드백을 받았죠.

TIP: 보안 스펙이 아무리 훌륭해도 고객이 체감하지 못하면 무용지물입니다. 사용자와 관리자가 데이터 통제권을 실시간으로 확인할 수 있도록 ‘Trust UX’에 적극적으로 투자하세요.

B2B AI SaaS 세일즈의 무기는 ‘보안 아키텍처’다

생성형 AI 기술 경쟁은 모델 파라미터 크기 자랑에서 이제 ‘고객의 경계 내에서 데이터를 얼마나 안전하고 투명하게 통제할 수 있는가’로 이동하고 있습니다.

정부 차원의 규제 완화가 이루어지더라도, 기업의 불안은 B2B 세일즈의 거대한 장벽으로 남아 있을 거고요. 결국 다가오는 B2B AI SaaS 시장의 승자는 하이브리드 인프라로 SaaS의 스케일업 마진을 지키고, 하이브리드 라우팅으로 성능과 보안의 균형을 잡으며, Trust UX로 고객의 신뢰를 즉각 확보하는 기업이 될 겁니다.

보안 컴플라이언스는 더 이상 수동적인 방어용 방패가 아닙니다. 시장의 장벽을 뚫고 고객사의 지갑을 열게 만드는 B2B 세일즈의 가장 강력한 무기입니다.

[C-Level을 위한 다음 단계 가이드]
현재 운영 중인 AI SaaS의 B2B 세일즈 전환율을 높이고 보안 심의 기간을 단축하고 싶으시다면, 기존 싱글테넌트 구축 요청에 하이브리드 인프라(Data Residency + BYOK)와 Trust UX 시연을 세일즈 제안서의 핵심 스펙으로 전면 배치해 보세요.

<참고>

일본 디지털청, 「디지털청 장관 기자회견 기록 (최근 2026년 6월 12일)」
일본 디지털청, 「제12회 디지털 사회 구상 회의 자료 (최근 2026년 5월 22일)」
데이코쿠데이터뱅크(TDB), 「生成AIに関する企業の動向調査（2026年3月調査）」 (생성 AI에 관한 기업 동향 조사, 최근 2026년 5월 발표, 유효응답 10,312사)
도쿄상공리서치(TSR), 「生成AIに関するアンケート調査」 (생성 AI에 관한 앙케트 조사, 최근 2026년 4월 발표, 유효응답 6,327사)

]]>

MCP 새로운 스펙 총정리: 무엇을 결정하고 바꿔야 할까?

지난 7월 28일, MCP(Model Context Protocol) 스펙의 새 버전 2026-07-28이 확정됐습니다. MCP 공개 이후 가장 큰 개정으로, 변경 이력(changelog)에 굵직한 변경만 9건이 올라와 있습니다. 클로드 코드(Claude Code)나 커서(Cursor) 같은 코딩 에이전트에 MCP 서버를 붙여 쓰는 환경에 직접 해당하는 내용들입니다.

다행히 오늘 당장 MCP 설정을 바꾸지 않는다고 해서 기존 동작에 문제가 생기는 건 아닙니다. 공식 발표도 “기존 클라이언트와 서버는 오늘도, 7월 28일에도 문제없이 동작한다(nothing breaks today, and nothing breaks on July 28 either)”라고 분명하게 밝혔습니다.

하지만, 변경의 폭이 넓어 스테이트리스(stateless) 전환이라는 헤드라인 하나만 보고 넘어가면 중요한 내용들을 놓치기 쉽습니다. 그런 만큼 이 글에서는 이번 개정의 변화 전체를 6개로 나누어 하나씩 설명하고, 지금 MCP를 쓰고 있는 사용자라면 무엇을 알아두고 무엇을 결정해야 하는지 정리해 보겠습니다.

MCP 개편 항목 한눈에 보기

우선 공식 변경 이력의 항목들을 성격에 따라 다음 6가지로 구분하여 표로 정리해 볼 수 있습니다.

2026-07-28 개정의 변화 전체: 6가지 분류 <출처: 작가>

참고로 MCP는 앤트로픽(Anthropic)이 만들었고 2025년 12월부터 리눅스 재단 산하 AAIF(Agentic AI Foundation, 에이전틱 AI 재단)에 기부되어 중립 재단 아래에서 관리되고 있습니다. 이번 릴리스는 그 체제에서 나온 첫 대규모 개정이며 릴리스 후보(RC, Release Candidate)가 5월 21일에 나와 10주의 검증 기간을 거쳐 확정됐습니다.

그러면 6가지 주요 변화를 하나씩 함께 보겠습니다.

1. 스테이트리스 코어: 세션이 사라진 이유와 방식

가장 큰 변화로, 이로 인해 나머지 변화들이 생겼다고 볼 수 있습니다.

기존 핸드셰이크 구조의 문제

기존 MCP에서 클라이언트(코딩 에이전트)와 서버(도구 제공자)는 요청을 주고받기 전에 확인 절차부터 거쳤습니다. 즉, 클라이언트가 initialize 요청으로 “나는 이런 기능을 지원한다”라고 알리면 서버가 세션(session) ID를 발급해 돌려주는 핸드셰이크(handshake) 구조였습니다. 이후 모든 요청에는 Mcp-Session-Id 헤더로 발급받은 세션 ID를 함께 보내야 했습니다.

물론 이 구조를 쓴다 해도 로컬에서 서버를 1개 띄웠을 경우에는 문제가 되지 않습니다. 하지만 원격에 여러 대로 늘려 운영하는 순간, 문제가 생깁니다. 세션이 특정 서버에 묶여 있다 보니 요청 분배와 장애 복구에서 문제가 일어날 수 있습니다. 특히, 같은 클라이언트의 요청은 세션을 기억하는 서버 인스턴스로만 보내야 하므로 일반 로드밸런서(load balancer)의 라운드로빈 분배 대신 스티키 세션(sticky session) 같은 장치가 필요했습니다. 결국 그 인스턴스가 죽으면 세션도 함께 사라졌습니다.

여기에 세션을 만들고 관리하고 나중에 정리하는 코드까지 서버 개발자가 직접 구현해야 하다 보니 버그와 메모리 누수로 이어지는 경우도 많았습니다. 스펙 개선 제안 문서인 SEP-2575(Specification Enhancement Proposal)를 보면, 이러한 문제들이 많이 등장합니다.

MCP 코어 메인테이너인 MS 개발자 케이티 맥카프리(Caitie McCaffrey)의 릴리스 직후 인터뷰에 따르면, 호스트마다 세션 기능의 구현 방식이 제각각이거나 아예 올바르지 않아 상태 유지가 프로토콜에서 제대로 작동한 적이 없었다고 합니다. 실제 사용 사례의 약 90%는 그 기능을 쓰지도 않았다고 합니다. 그래서 이번 2026-07-28 개정이 이 문제들을 해결했습니다.

새로운 스펙이 문제를 해결한 방법

그렇다면 새로운 스펙은 이 문제를 어떻게 풀었을까요?

답은 “처리에 필요한 정보를 요청 하나에 전부 담는다(self-contained)”입니다. 매 요청의 _meta 필드에 프로토콜 버전과 클라이언트 기능 목록이 필수로 실립니다. 어떤 서버 인스턴스가 받아도 그 요청 하나만 보고 독립적으로 처리하도록 했습니다. 서버 정보가 궁금하면 server/discover라는 요청으로 지원 버전과 기능을 물어볼 수 있고, 이 요청은 모든 서버가 반드시 지원하게 됩니다.

세션 기반(구 스펙) 요청 흐름과 스테이트리스(신 스펙) 요청 흐름 비교 <출처: 작가>

변경에 따른 두 가지 오해

두 가지 오해를 짚고 넘어가는 게 좋겠습니다. 첫째, 세션이 없어졌다고 해서 상태 자체가 금지된 것은 아닙니다. 장바구니처럼 여러 호출에 걸친 상태가 필요한 서버는, 생성 도구가 basket_id 같은 명시적 핸들(handle)을 돌려주고 이후 호출마다 그 식별자를 인자로 받는 방식으로 바뀌게 됩니다. 기존에는 이러한 상태가 전송 계층에서 세션으로 관리되어 모델이 그 존재를 보기 어려웠습니다. 그러나 이제는 핸들 방식으로 변경되면서 도구의 인자와 반환값처럼 모델이 직접 볼 수 있는 데이터 형태로 오갑니다.

둘째, 끊긴 스트림을 이어받는 재개(resumability) 기능도 함께 사라졌습니다. 스트림을 이어받으려면 서버가 직전까지 보낸 내용을 기억하고 있어야 하는데, 상태를 남기지 않는다는 새 원칙과 맞지 않기 때문입니다. 응답 스트림이 끊기면 클라이언트는 새 요청으로 다시 시도해야 하고, 오래 걸리는 작업은 뒤에서 설명할 Tasks 확장이 담당하게 됐습니다.

왜 기존 방식과 호환되는 방식을 선택하지 않고 전면적인 개정으로 진행하게 되었을까요? 두 상호작용 모델을 병행하면 프로토콜과 모든 구현체가 두 벌의 로직을 만들고 유지해야 해서 복잡도와 버그 여지가 커집니다. 그래서 메인테이너들은 한 번에 정리하는 쪽이 생태계 전체에 낫다고 판단했습니다. (보다 상세한 내용은 SEP-2575 문서에 기록되어 있으니 참고하시기 바랍니다.)

2. 통신 방식 변경: 서버가 더 이상 클라이언트를 호출하지 않음

세션이 사라지면서 서버가 클라이언트와 연결을 계속 유지한다는 전제도 사라졌기 때문에, 통신 방식도 함께 달라졌습니다.

기존에는 서버가 역으로 클라이언트에 요청을 보낼 수 있었습니다. 도구 실행 중에 사용자 입력을 요청하는 엘리시테이션(elicitation)이 대표적입니다. 신 스펙에서 서버는 JSON-RPC 요청을 시작할 수 없도록 했고 이런 상호작용은 MRTR(Multi Round-Trip Requests, 다중 왕복 요청)이라는 패턴으로 바뀌었습니다. 서버가 클라이언트를 직접 호출하는 대신 “추가 입력이 필요하다”는 중간 결과를 돌려주면 클라이언트가 입력을 채워 원래 요청을 다시 보내는 방식입니다. 이때 서버는 진행 상태를 requestState라는 문자열로 내보내고 클라이언트가 그대로 돌려줍니다.

그런데 이 값은 클라이언트를 거쳐 돌아오기 때문에, 서버가 보낸 그대로라는 보장이 없습니다. 그래서 스펙은 이 값을 믿지 말고 외부에서 온 입력처럼 검증하도록 명시합니다. 인가나 비즈니스 로직에 영향을 준다면 HMAC(Hash-based Message Authentication Code, 해시 기반 메시지 인증 코드) 같은 무결성 보호가 필수입니다. SDK가 이를 위한 도구를 제공합니다.

[노트] 엘리시테이션(elicitation)이 무엇인가요?

서버가 도구를 실행하다가 사용자에게 추가 입력이나 확인을 요청하는 기능입니다.
예를 들어 배포 도구가 실행 도중에 “어느 환경에 배포할까요?”라고 물어보고 답을 받아 이어가는 상호작용이 여기에 해당합니다.

서버에서 클라이언트로 가는 통신에는 응답을 요구하는 요청 말고도 일방적으로 알려주기만 하는 알림이 있는데, 이 알림 채널도 하나로 합쳐졌습니다. 기존에는 알림을 받는 통로가 2개여서, 서버가 보내는 일반 알림은 클라이언트가 HTTP GET으로 열어 둔 상시 연결로 받고 리소스 변경 알림은 별도의 구독 요청으로 신청했습니다. 게다가 서버가 아무 때나 일방적으로 알림을 보낼 수 있어서 클라이언트는 쓰지도 않을 알림까지 받아서 처리해야 했습니다. 서버도 어느 클라이언트가 듣고 있는지를 세션 상태로 관리해야 했습니다.

신 스펙은 이 둘을 subscriptions/listen이라는 단일 스트림으로 통합하고 받고 싶은 알림 종류(도구 목록 변경 등)를 클라이언트가 명시적으로 신청하는 옵트인 방식으로 정리했습니다. 이제 클라이언트는 신청한 알림만 받고, 서버는 신청받은 알림만 처리해서 보냅니다.

3. 인프라 친화적 개선: HTTP 헤더와 캐시 표준화로 운영 부담을 줄임

운영하는 쪽에 이득이 집중된 변화입니다. 이제 Streamable HTTP 요청에는 어떤 메서드인지(Mcp-Method), 어떤 도구를 호출하는지(Mcp-Name)가 HTTP 헤더로 필수로 실리도록 했습니다. 게이트웨이나 로드밸런서가 요청 본문(JSON)을 뜯어보지 않고도 특정 도구 호출만 골라서 다른 경로로 보내거나 차단하거나 기록하는 일을 할 수 있게 된 것입니다. 실제로 깃허브(GitHub)는 자사 MCP 서버를 신 스펙으로 옮기면서 본문 검사(deep packet inspection) 없이 헤더 기반 라우팅으로 바꿨다고 밝혔습니다.

캐시 규칙도 표준화됐습니다. 도구 목록(tools/list) 같은 조회 결과에는 캐시 유효 시간 힌트인 ttlMs와 공유 캐시 허용 여부인 cacheScope가 필수로 붙게 됐습니다. 목록이 연결마다 달라지는 것도 금지되어 같은 서버라면 누가 물어도 같은 목록이 나오는 캐시 가능한 구조를 전제로 삼았습니다. 여기에 요청이 여러 구성 요소를 거칠 때 하나의 흐름으로 이어서 추적하는 분산 추적도 오픈텔레메트리(OpenTelemetry) 기준으로 연동 방법이 문서화됐습니다. 이제 MCP 트래픽을 일반 웹 트래픽처럼 관리 도구로 다룰 수 있습니다.

4. 인증과 보안 강화: OAuth 실전 배포에 맞게 다듬음

원격 MCP 서버의 인증 계층도 여러 곳이 수정되었습니다. 고친 항목 하나하나는 작은 기술적 수정이지만 기업의 실제 OAuth·OIDC(OpenID Connect) 배포 환경에서 통용되게 만든다는 점에서는 모두 동일한 방향성을 가지고 있습니다.

특히, 인가 응답에 발급자(issuer) 정보를 실어, 응답을 보낸 인가 서버가 클라이언트 자신이 요청했던 서버와 같은지 확인하게 하는 요건이 더해졌습니다. 공격자가 서로 다른 인가 서버의 응답을 뒤섞어 인가 코드를 가로채는 경로를 막기 위한 것입니다. 또한 클라이언트 자격 증명은 발급한 서버에만 쓸 수 있게 묶어 다른 서버에 재사용하지 못하게 했습니다.

사실 가장 눈에 띄는 변화는 클라이언트 등록 방식입니다. 그동안 쓰이던 동적 클라이언트 등록(DCR, Dynamic Client Registration)은 더 이상 사용을 권고하지 않는 상태(deprecated)로 변경되었습니다. 당장 지원이 끊기는 것은 아니고 기존 환경과의 호환을 위해 당분간 유지되지만 새로 만드는 구현에서는 쓰지 말라는 뜻입니다. 그 대신 HTTPS URL 자체가 클라이언트 ID가 되는 CIMD(Client ID Metadata Documents, 클라이언트 ID 메타데이터 문서)가 권장 방식으로 지정됐습니다. 클라이언트가 자기 메타데이터를 URL로 게시하면 어떤 인가 서버에서든 재등록 없이 통하는 방식입니다.

개인이 로컬에서 stdio 방식으로 서버를 쓰는 경우에는 이 인가 스펙이 적용되지 않으니, 원격 HTTP 서버를 만들거나 운영하는 쪽에서 대응해야 하는 내용이라고 보면 됩니다.

5. 확장 프레임워크: 코어는 작게, 나머지는 확장으로

이번 개정의 설계 방침이 잘 드러나는 변화입니다. 코어 프로토콜에는 extensions 필드가 추가되어 클라이언트와 서버가 각자 지원하는 확장을 이 필드로 알립니다. 코어에 지금 담지 않기로 한 기능들은 공식 확장으로 분리하고 버전을 따로 매겨 관리하는 형태가 되었습니다. 쿠버네티스가 코어 API 밖에서 Gateway API 같은 프로젝트를 별도 버전으로 발전시켜 온 것과 비슷한 관리 방식이라고 볼 수 있습니다.

Tasks: 오래 걸리는 작업 처리가 코어의 실험 기능에서 공식 확장(io.modelcontextprotocol/tasks)으로 이동했습니다. 서버가 작업 핸들을 돌려주면 클라이언트가 폴링(polling, 주기적으로 상태를 물어보는 방식)으로 진행 상황을 확인하고 접속이 끊겼다 돌아와도 결과를 받아갈 수 있습니다. 스트림 재개가 사라진 부분을 대신하는 기능이기도 합니다.
MCP Apps: 서버가 채팅 화면 안에 렌더링되는 대화형 UI를 제공할 수 있게 하는 확장입니다.
EMA(Enterprise-Managed Authorization, 기업 관리형 인가): 이번 개정과 묶여 자주 언급되는 기업용 인증 확장인데, 실제로는 이번 코어 스펙의 일부가 아니라 별도 확장으로 이미 6월에 안정화됐습니다. 이 구분이 매우 중요한 이유는, 스펙을 따라가는 일과 EMA를 도입하는 일이 서로 별개의 결정이기 때문입니다. 이를테면 직원이 회사의 IdP(Identity Provider, Okta 같은 신원 제공 서비스)에 한 번 로그인하면 서버마다 개별 동의 화면을 거치지 않고 회사가 승인한 MCP 서버들이 연결되는 방식입니다. IdP·클라이언트·서버 삼자가 모두 지원해야 동작하는 옵트인 기능이기에, 개인 사용자와는 무관합니다. 사내 MCP 접근 통제를 고민하는 조직이 지켜볼 영역입니다.

확장은 전부 선택 사항이고 기본으로 꺼져 있습니다. 코어를 가볍게 유지하면서 필요한 조직만 필요한 확장을 켜는 구조입니다.

6. 기능 정리와 수명주기: 세 기능이 제거 수순에 들어감

마지막은 기능을 덜어내는 변화입니다. Roots, Sampling, Logging 세 기능이 더 이상 사용을 권고하지 않는 상태가 됐습니다. 지금은 동작하지만 신규 구현에는 넣지 말라는 의미입니다. 각 기능이 하던 일과 스펙이 제시한 대안을 정리하면 다음과 같습니다.

이번에는 이렇게 기능을 정리하는 절차 자체도 정해진 규칙을 따르게 되었습니다. 기능이 이 상태로 지정되면 최소 12개월은 유지된 뒤에야 제거될 수 있다는 수명주기 정책이 정식 문서로 만들어진 것입니다. 따라서 위 세 기능은 적어도 2027년 7월 28일까지는 그대로 유지되며 실제 제거는 그 이후에 나오는 첫 리비전에서야 가능합니다. 그 시점이 되어도 자동으로 제거되는 것은 아니고 메인테이너가 릴리스를 준비하며 결정하는 것이라 더 늦어질 수도 있습니다.

그에 반해 2024년 말의 초기 전송 방식인 HTTP+SSE(Server-Sent Events)는 정리 절차가 훨씬 앞서 있습니다. 아직 이 방식을 쓰고 있다면 가장 시급한 이전 대상입니다. 그러면 구 스펙(2025-11-25) 자체는 언제까지 지원될까요? 아쉽게도, 종료일은 명시되어 있지 않습니다. 수명주기 정책이 리비전이 아니라 기능 단위로 적용되기 때문입니다.

그래서 지금, 사용자 유형별로 해야 할 일

그럼 이제부터 각자의 자리에서 무엇을 하면 되는지 정리해 보겠습니다.

MCP 서버를 붙여 쓰는 사용자

원칙적으로 할 일이 없습니다. 버전 협상, 그리고 신 스펙이 통하지 않는 상대를 만나면 기존 방식으로 자동 전환해 다시 시도하는 폴백(fallback)은 클라이언트와 SDK가 처리합니다. 깃허브도 자사 MCP 서버를 전환하면서 “사용자는 아무것도 할 필요가 없다”라고 얘기했습니다.

하지만 예외가 두 가지 있을 수 있습니다. 하나는 설정에 SSE 전송을 명시적으로 고정해 둔 경우로, 클라우드플레어(Cloudflare)는 자동 감지나 Streamable HTTP로 바꾸라고 안내됩니다. 다른 하나는 회사 내부 MCP 서버가 세션에 상태를 묶어 두는 경우입니다. 접속 시점 헤더로 받은 테넌트(tenant) 정보를 세션에 저장해 쓰는 유형의 서버라면 신 스펙 환경에서 동작이 어긋날 수 있습니다. 실제로 전환 시점 전후 이런 유형으로 추정되는 동작 이상 보고도 올라왔습니다.

추가로 이 글을 작성하는 시점(8월 5일) 기준으로도 클라이언트 쪽은 공개된 정보가 부족하다는 점을 알아두면 좋겠습니다. 서버와 플랫폼에 대한 지원과 관련된 내용은 많이 나왔지만 앤트로픽은 “클로드 제품군에 순차 적용 중”이라고만 밝혔고 커서의 변경 이력에는 관련 언급이 아직 없습니다. 오픈AI 코덱스(Codex) CLI는 기능 플래그 등록에 이어 일부 기반 코드를 넣는 단계라, 어느 클라이언트가 어느 버전부터 신 스펙을 지원하는지 정리된 표는 아직 없습니다.

서버를 만드는 개발자

마이그레이션을 실제로 계획해야 하는 시점입니다.

우선 스펙 확정과 같은 시기에 주요 SDK 안정 버전이 나왔습니다. 파이썬은 mcp 2.0.0이 릴리스 당일 나왔습니다(이제 pip install mcp가 2.x를 설치하므로, 준비가 안 된 프로젝트는 mcp>=1.28,<2처럼 상한을 거는 것이 공식 권고입니다). 타입스크립트는 기존 @modelcontextprotocol/sdk가 1.x에서 멈추고 @modelcontextprotocol/server 등 새 패키지의 2.0.0으로 나뉘었습니다. 그래서 새로 만드는 MCP 서버라면 처음부터 신 스펙(SDK 2.x)으로 시작하면 되고 구 스펙으로 새로 만들 이유는 없습니다.

다행히 세션 관리 코드는 모두 지워집니다. 실제로 깃허브 MCP 서버를 옮긴 메인테이너 샘 모로우(Sam Morrow)도 얻은 것밖에 없다고 말할 정도입니다.

대신 손이 가는 곳은 세션에 두던 상태를 핸들이나 외부 저장소로 넘기는 일, 엘리시테이션을 MRTR 패턴으로 다시 작성하는 일, 그리고 오래 걸리는 작업을 Tasks 확장으로 옮기는 일입니다. 또, 파이썬 SDK 2.0.0에는 Tasks 확장이 아직 구현되지 않았으므로 장기 작업 의존 서버는 조금 기다려야 합니다. 마지막으로 신/구 클라이언트를 모두 받는 양쪽 지원(dual-era) 운영이 SDK 기본값이므로, 아직 사용자 중에 기존 버전을 사용하는 경우가 있을 수 있으니 그대로 두는 게 더 안전합니다.

배포/운영하는 팀

이번 변경으로 운영 구성이 실제로 단순해집니다. 스티키 세션과 세션 공유 저장소가 필요 없어지고 쿠버네티스(Kubernetes) 서비스 뒤에 평범한 라운드로빈으로 레플리카를 늘리는 구성이 프로토콜 차원에서 성립합니다.

전환 전략으로는 게이트웨이를 앞에 두는 방법이 제시되어 있습니다. 오픈소스 MCP 게이트웨이인 에이전트게이트웨이(agentgateway)는 1.4.0 버전부터 신 스펙을 정식으로 지원합니다. 클라이언트를 일괄 업그레이드하지 않고 게이트웨이 뒤에서 서버만 먼저 올린 뒤 트래픽을 조금씩 옮기는 카나리(canary) 방식이 가능합니다.

마지막으로, 적용 여부를 어떻게 판단하면 될까요? 호환되지 않는 조합은 정해져 있습니다. 신 스펙 전용 클라이언트가 구 스펙 전용 서버를 만나거나 그 반대인 경우만 실패하고 한쪽이라도 양쪽을 지원하면 동작합니다. 따라서 당분간은 양쪽을 다 지원하는 구성이 안전합니다. 강제 전환 시점이 없고 유예도 넉넉하니, 이를 상황별로 정리하면 다음과 같습니다.

사용자 유형과 상황별 권고 정리 <출처: 작가>

마치며

결국, 이번 개정은 대다수가 쓰지 않던 기능을 걷어내고 웹에서 오래 검증된 스테이트리스 요청 모델로 돌아온 것이 가장 핵심 변화라고 볼 수 있습니다. 이는 즉, MCP가 실험적 프로토콜에서 운영 가능한 인프라로 넘어가는 단계가 된 것이라고 생각합니다.

깃허브와 클라우드플레어는 확정일 전후로 전환을 마쳤고 AWS와 마이크로소프트도 대응 방안을 내놨으니, 방향은 이미 정해진 셈입니다. 물론 이 글은 스펙과 공식 발표, 릴리스 직후 며칠간의 생태계 반응을 기준으로 쓴 것이라, 클라이언트 지원 현황 같은 부분은 앞으로 몇 주 사이에 빠르게 갱신될 수 있습니다. 영향을 크게 받는 분들이라면 꾸준히 커뮤니티를 주목하는 것이 좋겠습니다.

참고로, 저는 이 중에서도 1번 항목인 스테이트리스 전환이 실제 운영 환경에서 어떤 차이를 만드는지가 궁금해졌습니다. 따라서 구 스펙 서버와 신 스펙 서버를 같은 쿠버네티스 클러스터에서 돌려 스케일아웃과 파드 교체 상황을 실측하는 실험을 준비하고 있습니다. “스티키 세션이 필요 없어졌다”는 말이 수치로는 어떻게 나타나는지, 괜찮은 측정 결과가 나온다면 또 소개해 보겠습니다.

참고 자료

MCP 2026-07-28 공식 발표: https://blog.modelcontextprotocol.io/posts/2026-07-28/
스펙 변경 이력(changelog): https://modelcontextprotocol.io/specification/2026-07-28/changelog
SEP-2575 (Make MCP Stateless): https://modelcontextprotocol.io/seps/2575-stateless-mcp
SDK 베타 발표(호환성 정책 포함): https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/
Arcade.dev 메인테이너 인터뷰: https://www.arcade.dev/blog/mcp-maintainers-interview
GitHub MCP 서버 전환 안내: https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/

작가

조훈 (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 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.

]]>

[티켓 증정 이벤트] 개발자·PM도 알아야 할 검색의 미래, 구글에게 직접 듣는다

본 콘텐츠는 Search SEOul 2026과의 파트너십으로 제작되었으며, 요즘IT 독자를 위한 티켓 증정 이벤트를 포함합니다.

“검색은 마케팅팀 일”이라고만 생각하셨나요? 이제 개발자, PM도 ‘검색’에 주목해야 합니다. 사용자가 제품이나 서비스를 찾는 경로 자체가 바뀌었기 때문이죠. AI가 검색 결과 화면 구조를 다시 짜고, LLM이 직접 답을 내놓으면서, “우리가 만든 서비스가 검색엔진과 AI 모델에게 어떻게 읽히는가”가 곧 제품의 발견 가능성을 결정합니다.

렌더링 방식, 정보 구조, 배포 파이프라인처럼 원래 개발자·PM의 영역이었던 것들이 이제 검색·GEO(생성형 엔진 최적화) 전략과도 직접 맞닿아 있는 셈입니다.

실제로 요즘IT에서도 한 엔지니어가 서비스 코드를 건드리지 않고, CDN 엣지에서 GEO 태그를 자동 삽입하는 실험을 소개하기도 했습니다. GEO가 콘텐츠 문제를 넘어, 운영과 인프라의 문제가 되고 있다는 걸 보여주는 사례죠.

그래서 다가오는 9월, 마포에서 조금 특별한 SEO 컨퍼런스가 열립니다. 올해로 2회째를 맞는 Search SEOul(서치 서울) 2026입니다.

<출처: Search SEOul 홈페이지>

“한국 최초의 글로벌 SEO 컨퍼런스”인 서치 서울은, 그동안 미국·유럽·동남아시아에서만 열리던 글로벌 SEO 행사를 한국으로 가져오겠다는 문제의식에서 출발했습니다. 세계에서 가장 빠르게 움직이는 디지털 시장 중 하나인 한국에서, 정작 해외와 국내 SEO 전문가가 만나는 자리가 없었다는 건데요.

이번 서치 서울 2026에선 구글 검색팀, Ahrefs, Common Crawl Foundation 등 SEO·GEO 업계의 쟁쟁한 실무자들이 직접 발표에 나섭니다.

특히 올해는 20명 이상의 연사와 10개국 이상이 참가하여, 더 큰 규모로 구성됐습니다. 행사는 다가오는 9월 3일부터 4일까지 양일간 호텔 나루 서울 엠갤러리에서 열립니다.

어떤 행사인가

이번 컨퍼런스의 목적은 한국 고유의 검색 환경과 해외의 SEO 혁신을 서로 연결하고, 지금 SEO 업계에서 벌어지는 가장 큰 변화의 중심에 있는 전문가들을 한자리에 모으는 데 있습니다.

AI가 검색 결과 화면의 구조를 바꾸면서, 이제는 사람들이 검색 결과 페이지(SERP)만 보고 구매를 결정하지 않는 시대가 됐는데요. 이건 마케팅 지표만의 문제가 아닙니다. AI가 웹페이지를 어떻게 파싱하고, 어떤 정보를 우선 인용하는지가 곧 제품이 발견되는 방식을 좌우하기 시작했다는 뜻이니까요. SEO·개발·프로덕트가 따로 움직일 수 없다는 이야기가 나오는 이유이기도 합니다.

현재 인하우스 SEO를 담당하거나, 마케팅팀의 리드, 혹은 에이전시, 테크니컬 SEO 담당자, 콘텐츠·PR 담당자, 이커머스·글로벌 마케터, AI 검색 실무자라면 충분히 주목해 볼 만한 행사입니다. 그리고 검색 유입 지표를 자주 들여다보거나, 자사 제품이 AI 검색 결과에 얼마나 잘 노출되는지 궁금했던 개발자·PM 등 프로덕트 빌더에게도 유익할 겁니다.

프로덕트 메이커라면 이 세션들을 주목하세요!

그럼 서치 서울 2026에서 준비한 세션 중 특히 개발자·PM 등 프로덕트 메이커가 참고할 만한 것들을 짚어봤습니다.

가장 주목해 볼 만한 세션은 2일차 오후 2시, 구글 검색팀 Search Relations Analyst인 게리 일리스의 「블루 링크에서 AI Overviews까지」입니다. 검색 결과 화면이 왜 지금의 모습이 됐는지, 그 변화를 만든 구글 검색팀에서 직접 설명하는 자리입니다. 프로덕트가 검색에 노출되는 방식이 왜, 어떻게 바뀌었는지를 구글에 직접 들을 기회는 흔치 않습니다.

렌더링과 배포 파이프라인을 다루는 세션도 눈에 띕니다. 1일차 오후 SEO 및 분석 컨설턴트인 조나단 무어의「LLM을 위한 자바스크립트 디버깅」에서 자바스크립트로 렌더링한 화면이 LLM에게 어떻게 읽히는지를 다룹니다.

2일차 오전에 The Aspen Group 시니어 디렉터, 조리 포드의「개발 파이프라인의 SEO 통합」은 SEO 요구사항을 배포 과정 안으로 끌고 들어오는 이야기입니다.

두 세션 다 마케팅팀에서 요청서가 넘어오기 전에, 개발 단계에서 먼저 알아두면 좋을 주제입니다.

정보 구조 자체를 다시 생각해보고 싶다면, 1일차 오전 Artience 최윤희 님의 「다음 GEO 시대를 위한 지식 구조화와 온톨로지」도 챙겨볼 만합니다. AI를 향해 글을 쓰는 것을 넘어 지식 자체를 구조화해야 한다는 문제의식을 다루는 세션으로, GEO를 콘텐츠 작성의 문제가 아니라 정보 설계의 문제로 다시 보게 만드는 자리입니다.

1일 차 오후에는 Blogtalk의 황성원 대표가 「네이버 블로그 SEO와 한국 검색 생태계」라는 주제로 발표합니다. 전체 어젠다에서 한국 검색 환경을 정면으로 다루는 유일한 세션이라, 국내 서비스를 운영하는 분들에게 특히 추천합니다.

연사진 라인업 일부 캡처 <출처: Search SEOul 홈페이지>

세션 대부분은 영어로 진행되지만, 실시간 한글 자막이 상시 제공된다고 하니 참고해 주세요!

현재 국내에서 티켓을 구매하실 분들은 이벤터스 페이지를 통해 신청하실 수 있습니다. 3~4인 이상 단체로 참가하실 예정이라면, host@search-seoul.com으로 문의 주시면 추가 할인 혜택을 안내받으실 수 있습니다.

[★마감] 요즘IT 독자 대상 ‘2-Day Pass 증정 이벤트’

요즘IT는 이번 Search SEOul 2026의 공식 미디어 파트너로 함께하게 되었는데요. 이에 요즘IT 독자 두 분께 Search SEOul 2026 2-Day Pass(49만 원 상당) 티켓을 드리는 이벤트를 진행합니다. 9월 3~4일 열리는 본 컨퍼런스 이틀을 모두 참석할 수 있는 티켓입니다.

이벤트 안내

경품: Search SEOul 2026 2-Day Pass 티켓 (49만 원 상당) / 9월 3~4일 양일 간 참석 가능
당첨 인원: 2명
응모 방법: 댓글로 이번 서치 서울 2026에서 “가장 듣고 싶은 ‘세션’이 무엇인지”남겨주세요!
응모 기간: 2026년 8/10일(월) 11:00부터 ~ 8월 20일(목) 23:59분까지
당첨자 발표: 2026년 8/21(금) 당첨자 추첨 및 댓글을 통해 발표
당첨자 회신 기한: 당첨자의 경우, 2026년 8월 24일(월) 24시까지 당첨자 정보 회신 필요 (*기한 내 미회신 시 예비 당첨자 추첨 후 승계)

응모 전 확인해주세요!

참석권은 이벤터스 쿠폰으로 지급되어, 당첨자에게는 [이벤터스 계정]이 필요합니다.
쿠폰으로 티켓을 발급받는 과정에서 [이름, 이메일, 연락처, 소속, 부서, 직함]을 입력합니다.
당첨자 발표 이후 8월 24일(월) 23:59까지 회신해주셔야 하며, 기한 내 미회신 시 예비 당첨자에게 참석권이 넘어가니, 이 부분 유의해주세요!

수집하는 개인정보

티켓 발급용: 이름, 이메일, 연락처, 소속, 부서, 직함 (이벤터스 계정 필요)
제세공과금 원천징수용: 성명, 주민등록번호, 연락처, 주소 (소득세법상 원천징수·지급명세서 제출 목적, 법정 보존기간 후 파기, 제출 거부 시 경품 지급 불가)

유의사항

경품 소득세법상 기타소득으로 발생하는 제세공과금 22%는 전액 주최 측이 부담하며, 당첨자 부담금은 없습니다. (원천징수영수증 요청 시 발급 가능)
응모는 개인 자격으로만 가능하며, 국내 거주자에 한합니다.

서치 서울 2026과 관련된 상세 정보는 공식 홈페이지에서, 세션별 시간표는 어젠다 페이지에서 확인하실 수 있습니다.

이번 서치 서울 2026에서 실무에 바로 적용할 수 있는 SEO, GEO 노하우를 만나고 싶다면, 지금 바로 댓글로 ‘가장 기대되는 세션’을 남겨서 참여해 주세요!

]]>

테스트 코드 없이 웹을 검수하는 Manta AI, 믿을만할까?

웹 서비스를 만들 때는 화면을 완성하는 것만큼 배포 전 흐름을 확인하는 일도 중요합니다. 그런데 페이지가 많아지면 모든 화면을 직접 열어보는 데 시간이 걸리고, 어떤 경로부터 확인할지 정하는 일도 쉽지 않습니다.

특히 여러 외부 서비스의 운영 상태와 장애 이력을 보여주는 ‘VibeStatus’처럼, 서비스별 상태 페이지와 이력 페이지가 반복되는 웹 서비스라면 더욱 그렇습니다. (VibeStatus는 제가 바이브코딩 방식으로 작업한 웹 서비스로, 메이커가 자주 쓰는 서비스의 실시간 상태와 업데이트 소식을 확인할 수 있습니다.)

오늘 소개할 ‘Manta AI’는 URL을 입력하면 웹 서비스를 탐색하고, 페이지와 이동 관계를 정리해 주는 AI 소프트웨어 테스트 에이전트입니다. 자연어로 테스트 계획을 작성하고 실행하는 기능도 제공하는데요. 저는 반복 페이지가 많은 VibeStatus의 공개 영역을 연결해 실제로 어떤 도움을 받을 수 있는지 살펴봤습니다.

사용 전에는 자연어 테스트 계획(Test Plan)을 가장 기대했습니다. 테스트 코드를 직접 작성하지 않고도 핵심 흐름을 확인할 수 있을 것 같았기 때문입니다. 그런데 사용해 보니 자연어 테스트보다 먼저 실행한 탐색(Exploration)과 사이트 인텔리전스(Site Intelligence)가 서비스 구조와 검수 범위를 정리하는 데 더 도움이 됐습니다.

Manta AI 안에서는 별도의 테스트 코드를 작성하지 않았고, 보고된 항목이 실제로 수정이 필요한 문제인지 구분하기 위해 공개 흐름만 ‘Playwright’로 다시 실행하는 방식으로 테스트를 진행해봤습니다. 이번 글에서는 Manta AI의 주요 기능과 실제 결과, 아쉬운 점을 함께 정리해 보겠습니다.

미리 요점만 콕 집어보면?

사용 전에는 자연어 Test Plan을 가장 기대했지만, 실제로는 Exploration과 Site Intelligence가 서비스 구조와 검수 범위를 파악하는 데 더 도움이 됐습니다.
Bugs에는 보안 설정 누락과 외부 API·리소스 오류처럼 성격이 다른 항목이 함께 포함돼, 표시된 숫자를 곧바로 실제 버그 수로 보기는 어려웠습니다.
자연어 Test Plan은 원하는 흐름을 테스트 절차로 바꿔줬지만, 정상 리디렉션까지 실패로 처리해 허용할 URL 이동과 성공 조건을 구체적으로 적어야 했습니다.
Manta AI는 테스트를 모두 대신하기보다 검수할 범위와 문제 후보를 먼저 펼쳐 주는 도구에 가까웠으며, 우선순위와 최종 오류 판단은 사람이 맡아야 했습니다.

‘Manta AI’의 주요 기능과 특징

<출처: Manta AI, 작가 캡처>

Manta AI는 크게 두 가지 흐름으로 사용할 수 있습니다. Exploration으로 웹 서비스의 구조와 문제 후보를 먼저 파악한 뒤, 확인이 필요한 사용자 흐름을 자연어 Test Plan으로 만들어 실행하는 방법입니다.이 과정에는 내비게이션 맵(Navigation Map), 인증 영역 확인, UI 변경에 대응하는 셀프 힐링(self-healing)이 활용됩니다.

<출처: Manta AI, 작가 캡처>

시작점은 Exploration입니다. 서비스 URL을 입력하고, 운영·스테이징 같은 환경을 지정하면 에이전트가 접근한 범위에서 경로를 탐색하고, 결과 화면에 경로(routes)와 문제 후보(findings)를 표시해줍니다. (다만, 모든 URL을 빠짐없이 수집했다는 의미는 아닙니다. 에이전트가 접근한 범위에서 탐색 가능한 경로와 문제 후보를 다음 단계로 넘겨주는 구조이기 때문입니다.)

<출처: Manta AI, 작가 캡처>

Site Intelligence는 Exploration 결과를 서비스 구조 관점에서 정리한 화면입니다. 탐색된 페이지(pages)와 페이지 사이의 이동 관계(flow transitions)를 보여주기 때문에, 반복 페이지의 분포와 사용자 타입(게스트, 회원, 관리자 등)에 따른 영역, 폼·인증 지점의 위치를 파악할 때 참고할 수 있습니다. Navigation Map은 이 구조를 지도 형태로 보여줍니다. Site Intelligence에서 전체 구성과 규모를 파악했다면, Navigation Map에서는 특정 페이지가 어떤 경로와 연결되는지 확인할 수 있습니다.

<출처: Manta AI, 작가 캡처>

문제 후보는 Bugs에서 검토할 수 있습니다. 리스트에서 개별 내용을 클릭하면 상세 화면에서 URL, 심각도, 신뢰도, 환경과 재현 절차를 볼 수 있습니다.

<출처: Manta AI, 작가 캡처>

특정 사용자 흐름은 자연어로 조건을 요청해 Test Plan으로 실행할 수 있습니다. 저는 홈에서 영어 Stripe 상태 페이지로 이동해 내용을 확인하고 돌아오는 내용을 입력했는데, 8단계의 실행 가능한 테스트 절차를 확인할 수 있었습니다. 테스트 실행(Test Run)을 누르면, 앞서 설정한 Test Plan을 실제 브라우저에서 실행하며, 단계별 통과와 실패 결과를 기록합니다.

2026년 7월 기준 Manta AI는 공식 홈페이지에서 공개 베타(Public Beta)로 운영되고 있습니다. 신용카드 등록 없이 무료로 시작할 수 있으며, 팀 요금은 사용량 기반이라고 안내합니다. 다만, 구체적인 요금과 크레딧(credits) 환산 기준은 공개 화면에서 확인하기 어렵습니다.

URL 하나로 서비스 구조 확인하기

<출처: Manta AI, 작가 캡처>

어떤 식으로 서비스가 작동하는지 확인하기 위해, Exploration부터 실행했습니다. 'VibeStatus' 서비스를 운영(Production) 환경에 연결했고, 관리자 로그인, 상태 구독 제출, Slack 설치와 외부 링크 이동은 제외했습니다. Exploration을 실행하면 자동으로 Site Intelligence, Navigation Map, Bugs가 기록됩니다.

새 탐색은 17분 45초 동안 진행됐고, 결과 화면에는 466 routes와 12 findings가 표시됐습니다. 실행 전후 잔액 차이로 계산한 크레딧 사용량은 0.79였습니다. (참고로, 가입 시 25 크레딧이 제공됩니다) 이는 기능별 고정 요금이 아니라 이번 실행에서 확인한 차감량으로, 서비스 규모와 탐색 범위에 따라 달라질 수 있습니다.

<출처: Manta AI, 작가 캡처>

탐색이 끝난 뒤, Site Intelligence를 열어봤습니다. 총 464 pages와 424 flow transitions가 수집된 것을 확인할 수 있습니다. 서비스별 상태와 이력 페이지처럼 반복되는 경로가 보였고, 게스트와 관리자 영역, 폼과 인증이 필요한 지점도 영역별로 구분돼 있었습니다.

<출처: Manta AI, 작가 캡처>

Navigation Map에서는 /en에서 상태 페이지로 이어지는 경로와 /status/*, /en/status/* 형태의 언어별(이 서비스는 한글과 영문이 모두 지원됩니다.) URL이 드러났습니다. /guides/*, /updates/*, /en/data-deletion, /slack/install 같은 경로도 함께 보였는데요. 공개 흐름과 인증·설치 흐름을 나눠 다음 검수 순서를 정할 수 있었습니다.

<출처: Manta AI, 작가 캡처>

Bugs의 43 open 중 대표 항목을 직접 열어 실제 응답과 화면을 확인해봤습니다. 대표 사례는 ‘Missing security header’였습니다. 상세 화면에는 URL, 신뢰도 100%, 심각도(Medium), 운영(Production) 환경 등에 대한 정보와 재현 절차가 포함되어 있습니다.

확인해 보니 이 항목은 브라우저가 허용할 콘텐츠 출처를 제한하는 CSP(Content Security Policy)와 관련된 내용이었습니다. 공개 URL 응답에서 Content-Security-Policy 헤더가 보이지 않아 보안 정책을 검토할 개선 후보로 결정할 수 있었습니다.

<출처: Manta AI, 작가 캡처>

Manta AI가 콘솔 오류로 표시한 다섯 URL도 Playwright로 다시 실행했습니다. 실행 로그를 확인해 보니, 다섯 페이지 모두 Supabase의 outage-analysis 함수 요청이 HTTP 402 또는 429 응답으로 실패했다는 것을 알 수 있었습니다. Manta AI가 감지한 오류 응답 자체는 다시 확인할 수 있었던 셈입니다.

다만 오류가 발생한 이유와 사용자에게 미친 영향은 별개의 문제였습니다. 429는 일반적으로 요청이 짧은 시간에 몰렸을 때 반환되지만, 이번 함수가 어떤 조건에서 응답했는지는 서버 측 확인이 필요하기 때문입니다. 402 역시 응답 본문이나 서버 로그 없이는 원인을 특정하기 어려웠습니다. 따라서 이 결과만으로 주요 화면이나 사용자 흐름에 문제가 생겼다고 판단할 수는 없었습니다.

외부 파비콘을 불러오지 못해 발생한 404처럼 핵심 기능과 직접 관련이 낮은 항목도 있었습니다. 결국 Bugs에는 실제로 재현되는 응답 오류와 사용자 영향이 낮은 리소스 오류가 함께 포함돼 있었습니다. 수정 티켓으로 옮기기 전에는 오류가 발생한 위치와 사용자 영향, 중복 여부를 기준으로 우선순위를 다시 판단하는 과정이 필요하다고 느낀 순간이었습니다.

자연어로 테스트 시나리오 만들기

<출처: Manta AI, 작가 캡처>

다음 조건으로 자연어 Test Plan을 만들었습니다. 게스트로 홈을 열고, 영어 Stripe 상태 페이지로 이동해 상태 콘텐츠를 확인한 뒤 홈으로 돌아오는 흐름입니다. 로그인과 폼 제출, Slack 설치와 외부 링크 이동은 하지 않는 조건도 함께 적었습니다. 다만 /에서 /en으로 이동하는 정상 리디렉션을 허용한다는 조건은 별도로 적지 않았습니다.

Manta AI는 이 요청을 Guest can view Stripe status page and return to home이라는 Test Plan으로 만들었고, 생성된 계획은 총 8단계였습니다.

<출처: Manta AI, 작가 캡처>

아쉽게도, 결과는 8단계 중 1단계만 통과한 뒤 실패(Failed)로 끝났습니다. 두 번째 단계에서 Plan이 https://vibestatus.co.kr/를 기대했지만, 실제 브라우저는 https://vibestatus.co.kr/en에 도착했기 때문입니다. 정상적인 리디렉션이었지만, 이번 Test Plan에서는 URL 불일치로 처리됐습니다.

Test Plan이 두 번째 단계에서 중단된 원인이 실제 서비스 오류인지 확인하기 위해, 같은 공개 흐름을 Playwright로 다시 실행했습니다. 홈에 접속하자 /에서 /en으로 정상 이동했고, 영어 Stripe 상태 페이지에서도 현재 상태와 최근 인시던트, 가동 시간 영역이 모두 표시됐습니다. Incidents와 Updates 페이지도 정상적으로 열렸습니다. 실제 사용자 흐름이 중단된 것이 아니라, Test Plan이 정상 리디렉션을 예상하지 못해 실패한 결과라는 것을 알 수 있었습니다.

이번 경험을 통해 자연어 Test Plan은 확인할 흐름을 실행 가능한 절차로 만드는 데는 도움이 되지만, 서비스별 정상 동작까지 모두 알아서 판단하지는 못한다는 점을 알 수 있었습니다. /에서 /en으로 이동해도 성공으로 처리한다는 조건처럼 허용할 URL 변화와 성공 기준을 요청에 구체적으로 적어야 합니다.

어떤 팀이 활용하기에 적합할까?

<출처: Manta AI, 작가 캡처>

반복 페이지가 많아 어디부터 검수할지 정하기 어려운 서비스라면 Manta AI를 초기 탐색에 활용해 볼 수 있습니다. 공개 영역이나 안전한 스테이징 환경에서 먼저 범위를 넓혀 보고, 정상 리디렉션과 인증 전환, 성공 조건을 사전에 정의할 수 있는 팀에도 잘 맞습니다. 다만, 자동 결과를 그대로 확정하지 않고 대표 표본을 골라 직접 재현할 수 있어야 한다는 전제가 붙습니다.

결제·삭제·권한 변경처럼 잘못 실행했을 때 영향이 큰 흐름은 신중하게 적용해야 합니다. 정상적인 인증 전환과 외부 API 오류의 경계를 사전에 명확히 정의하기 어려운 서비스도 마찬가지입니다. Bugs 결과를 재현 없이 바로 수정 티켓으로 옮기거나, 셀프 힐링과 반복 회귀 테스트의 완전 자동화를 기대하는 방식은 이번 테스트 결과만으로 뒷받침하기 어렵기 때문입니다.

이번 테스트에서 가장 현실적이었던 활용 순서는 자동 탐색으로 구조를 펼치고, 사람이 우선순위를 정한 뒤 핵심 흐름만 Test Plan으로 만들고, Bugs의 문제 후보를 재현하는 방식이었습니다.

마치며

Manta AI를 사용하기 전에는 자연어 Test Plan을 가장 기대했습니다. 하지만 실제로 더 도움이 된 기능은 Exploration과 Site Intelligence였습니다. 반복되는 상태 페이지와 이동 관계를 펼쳐 보여줘, 서비스 구조와 검수 범위를 파악하는 데 바로 활용할 수 있었기 때문입니다.

Manta AI에 맡길 수 있었던 일은 에이전트가 접근한 페이지와 이동 경로를 모으고, 반복 구조와 문제 후보를 정리하며, 자연어 요청을 테스트 절차로 바꿔 실행하는 단계까지였습니다. 반면, 어떤 경로를 먼저 검수할지, 정상 리디렉션과 실제 실패를 어떻게 구분할지, 외부 API 응답이 사용자에게 영향을 주는지, Bugs 항목의 중복과 중요도를 어떻게 판단할지는 사람의 몫이었습니다.

UI 변경 후 셀프 힐링과 수정 후 반복 회귀 테스트까지는 검증하지 못했지만, 반복 페이지가 많아 검수의 시작점을 잡기 어려운 팀이라면 Manta AI를 서비스 구조와 문제 후보를 먼저 펼쳐 보는 도구로 활용해 볼 수 있을 거라 생각합니다.

<참고>

https://mantaai.co

]]>

자동화할 일을 고르는 것도 실력이다

비개발자가 넉 달에 도구 12개를 쌓으며 세운 기준

지난 글 비개발자가 400페이지 서명 검사를 자동화하며 고민한 것에서 나는 400페이지가 넘는 점검철의 서명 검사를 자동화한 이야기를 했다. 도구 하나를 어떻게 만들었는지에 대한 기록이었다. 그런데 그 도구는 내가 넉 달 동안 만든 열두 개 중 하나일 뿐이다. 이번 글은 ‘어떻게 만들었나’가 아니라, 열두 개를 앞에 두고 무엇을 먼저 만들고 무엇은 아예 만들지 않았나에 대한 이야기다.

솔직히 처음엔 나도 ‘많이 만드는 것’이 실력인 줄 알았다. 아니었다. 도구를 몇 개 만들고 나서야, 진짜 어려운 건 코드를 짜는 일이 아니라 손댈 일을 고르는 일이라는 걸 알았다. 반복 업무는 사방에 널려 있는데, 시간과 체력은 정해져 있다. 그래서 이 글은 코딩을 못 해서 자동화를 미뤄 둔 실무자, 그리고 팀에 자동화를 붙여 보려는 분들을 위한 글이다. 도구 만드는 법을 알려 주는 글은 많지만, 무엇을 만들지 고르는 기준을 실제 사례로 이야기하는 글은 드물었기 때문이다.

넉 달간 만든 자동화 도구 12개를 유형별로 정리한 지도 <출처: 작가, 클로드로 생성>

넉 달에 열두 개, 먼저 전체를 펼쳐 놓고 시작한다

기준 이야기를 하기 전에, 내가 실제로 무엇을 만들었는지부터 펼쳐 놓는 편이 낫겠다. 아래가 넉 달 동안 만든 열두 개다. 하나하나 자세히 볼 필요는 없다. 뒤에서 대표 몇 개만 깊이 들여다볼 것이고, 이 표로는 ‘이런 것들이 쌓였다’는 감만 잡으면 된다.

열두 개를 한 줄로 줄이면 이렇다. 검증이 셋, 수집·정산이 넷, 나머지가 입력·스케줄·변환이다. 처음부터 이렇게 나눠 만든 건 아니다. 그때그때 급한 걸 하나씩 처리했을 뿐인데, 돌아보니 이런 모양이 되어 있었다. 그런데 이 ‘돌아보니’가 중요하다. 어떤 일은 도구로 만들었고 어떤 일은 손대지 않았는데, 그 갈림길에 나름의 기준이 생겨 있었다.

무엇부터 골랐나? 나를 움직인 네 가지 기준

나는 개발 지식이 얕아서, 멋있는 걸 만들 능력이 없었다. 그래서 오히려 ‘이걸 만들 가치가 있나’를 매번 따질 수밖에 없었다. 그 과정에서 굳어진 기준이 네 가지다. 하나씩 풀어 본다.

첫째, 얼마나 자주 하는 일인가 (빈도)

아무리 귀찮아도 1년에 한 번 하는 일이라면, 도구를 만드는 시간이 더 아깝다. 반대로 매달, 매주 돌아오는 일이라면 한 번 만들어 두는 값어치가 매번 쌓인다. 나는 ‘이 일을 앞으로 몇 번이나 더 할까’를 먼저 셌다.

둘째, 한 번에 얼마나 오래 걸리나 (소요 시간)

빈도가 높아도 30초면 끝나는 일은 굳이 자동화하지 않았다. 사람이 한 번에 오래 매달려야 하는 일, 그래서 하고 나면 진이 빠지는 일을 우선했다.

셋째, 틀리면 얼마나 위험한가 (리스크)

이건 조금 결이 다르다. 자주 하지 않고 오래 걸리지 않아도, 틀리면 사고가 나는 일이 있다. 마감 서류에서 서명 하나를 놓치는 것 같은. 이런 일은 시간을 아끼려고가 아니라, 실수를 막으려고 자동화했다.

넷째, 다시 쓸 수 있는가 (재사용성)

한 번 만든 방식을 다른 일에도 붙일 수 있으면, 그 도구의 값어치는 눈에 보이는 것보다 크다. 뒤에서 이야기하겠지만, 나는 도구 하나를 만들면서 만든 ‘실행 방식’ 하나를 이후 여러 도구에 그대로 재활용했다.

이 네 가지를 하나의 체크리스트처럼 놓고 봤다. 어느 하나만 해당한다고 바로 만들지 않았고, 여러 항목에 걸리는 일부터 손댔다. 실제로는 네 가지가 다 걸리는 일은 드물었다. 그래서 완벽한 1순위를 찾기보다, 두세 개에 걸리는 일이면 일단 손대는 쪽을 택했다. 그리고 이 기준이 가장 선명하게 드러난 것이 아래 대표 사례들이다.

대표 사례로 보는 선별, 세 개만 깊이 들여다본다

열두 개를 다 설명하면 지루하고, 사실 다 볼 필요도 없다. 기준이 어떻게 작동했는지 잘 보이는 세 개만 골랐다.

사례 하나, 서명 검사: 빈도도 높고, 틀리면 위험하다

내가 가장 먼저 완성한 것이 지난 글에서 다룬 서명 누락 검사 도구다. 왜 이걸 첫 번째로 골랐는지가 이 글의 맥락에서는 더 중요하다. 이 일은 매달 돌아오고(빈도), 한 번에 30분에서 한 시간이 걸리며(시간), 하나라도 놓치면 마감이 틀어지는(리스크) 일이었다. 내 네 가지 기준 중 셋이 동시에 걸린 셈이다. 고민할 것도 없이 1순위였다.

결과는 앞 글에서 밝힌 대로다. 400페이지가 넘는 스캔본을 눈으로 넘기며 서명란을 대조하던 30분에서 한 시간짜리 일이, 1분 남짓의 자동 분석과 한 화면 확인으로 줄었다. 무엇보다 결과가 그림이 박힌 문서 한 장으로 남아, “확인했다”가 아니라 “이렇게 확인했다”는 증빙이 함께 생겼다.

서명 검사 결과 화면(마스킹본). 애매한 항목만 위로 올라오고, 사람은 마지막 1초만 확인한다. <출처: 작가, 클로드로 생성>

사례 둘, 출근부·휴가 대조: 사람이 오래 매달리던 일

두 번째는 출근부(출퇴근 기록)와 휴가 신청서를 맞대어 보는 일이다. 매달 마감 때, 기록부에 반차나 연차로 표시된 날이 실제 휴가 신청서와 맞는지, 신청서가 빠진 건 없는지 한 장씩 대조했다. 빈도는 서명 검사와 같지만, 이건 ‘오래 걸린다’는 쪽(시간)이 더 컸다. 사람 수만큼, 날짜만큼 눈이 왔다 갔다 해야 했다.

특히 반차처럼 하루 안에서 나뉘는 휴가나, 대체휴무처럼 종류가 헷갈리는 경우에는 한 번 더 확인해야 해서 손이 더 갔다. 놓치기 쉬운 건 대단한 실수가 아니라, 기록부에는 휴가로 표시돼 있는데 정작 신청서가 빠져 있는 것 같은 작은 어긋남이었다. 이런 건 눈이 피로할수록 더 잘 지나친다.

이 도구는 두 서류를 나란히 읽어 휴가 표시를 서로 맞춰 보고, 한쪽에만 있고 다른 쪽에 없는 것만 붉게 띄운다. 눈으로 30분쯤 걸리던 대조가 1분으로 줄었다. 결과는 대시보드 형태의 리포트로 나와서, 나는 애매한 항목만 한눈에 보고 직접 확인했다. 여기서도 원칙은 서명 검사와 같았다. 최종 판단은 사람이 한다. 도구는 어긋난 지점만 찾아 눈앞에 모아 줄 뿐이다.

실제로 돌려 보니, 사람이 훑을 때는 지나치기 쉬운 한두 건이 리포트 맨 위에 붉게 떠올랐다. 시간을 줄인 것보다, ‘빠진 것을 빠짐없이 봤다’는 확신이 생긴 게 나에게는 더 컸다.

출근부·휴가신청서 대조 결과 대시보드(가명·마스킹). 누락·확인 필요만 붉게·노랗게 떠, 사람은 그것만 본다. <출처: 작가, 클로드로 생성>

기록부와 신청서를 한 건씩 맞춰 본 매칭 상세(가명·마스킹). 25건 중 어긋난 1건만 붉게 표시된다. <출처: 작가, 클로드로 생성>

사례 셋, 예산 이월: 한 번 만든 방식을 다시 쓰다

세 번째는 조금 다른 이유로 골랐다. 예산 이월 도구는 월 이익금을 다음 예산으로 넘기는 계산을 대신하는데, 이 일 자체의 빈도나 위험보다 재사용성 때문에 이야기할 값어치가 있다.

앞서 만든 도구들에서 나는 ‘점검철 파일을 아이콘 위에 끌어다 놓으면 실행되는’ 방식을 만들어 두었다. 명령어를 칠 줄 몰라도 쓸 수 있게 하려던 것이었다. 그런데 이 ‘끌어다 놓기’ 실행 방식은 서명 검사에만 쓰이는 게 아니었다. 블로그용 이미지 변환에도, 예산 이월에도 그대로 붙었다. 도구마다 하는 일은 달라도, 사람이 쓰는 입구는 똑같이 만든 것이다. 하나를 잘 만들어 두니, 다음 도구는 그 위에 얹기만 하면 됐다.

이 방식이 특히 좋았던 건, 나 말고 다른 사람도 쓸 수 있다는 점이었다. 사용법이 ‘파일을 아이콘에 끌어다 놓는다’ 한 줄이면, 길게 설명하지 않아도 옆자리 동료가 바로 따라 했다. 도구를 나 혼자 쓰는 것과 팀이 함께 쓰는 것은 값어치가 다르다. 재사용성은 나중에 시간을 아껴 주는 정도가 아니라, 도구가 나 한 사람을 넘어서게 해 주는 성질이었다.

예산 이월 도구의 처리 흐름. 파일을 끌어다 놓으면 네 단계가 자동으로 이어진다(원본은 그대로 보존). <출처: 작가, 클로드로 생성>

이월 처리 결과 리포트(금액은 예시로 축소·사업명 마스킹). 자가검증까지 끝난 뒤 사람이 최종 확인한다. <출처: 작가, 클로드로 생성>

만들지 않기로 한 것들: 고르는 눈의 반대편

‘무엇을 자동화할까’만큼 중요한 게 ‘무엇은 자동화하지 않을까’였다. 몇 가지는 만들 수 있었는데도 일부러 손대지 않았다.

하나는 어쩌다 한 번 하는 일이다. 1년에 한두 번 하는 정리 작업은, 도구를 만들고 관리하는 품이 그 일을 손으로 하는 것보다 컸다. 만들고 싶은 마음은 굴뚝같았지만, 그건 자동화가 아니라 취미가 될 참이었다.

다른 하나는 틀렸을 때 사람이 책임져야 하는 판단이다. 예를 들어 애매한 특이사항을 ‘문제없음’과 ‘조치 필요’ 중 어디로 볼지 같은 것. 이건 도구가 대신 단정하게 두면 오히려 위험하다. 그래서 이런 일은 도구가 자료를 모아 주는 데까지만 맡기고, 판단 자체는 넘기지 않았다. 앞 글에서 말한 ‘사람 먼저, 도구 나중’이 여기서도 그대로 적용됐다.

자동화를 하다 보면 ‘이것도 되네’ 하는 욕심이 붙는다. 그 욕심을 어디서 멈출지 정해 두는 것도 도구를 만드는 일의 한 부분이었다. 안 만들기로 정하고 나면, 남은 시간을 진짜 손댈 값어치가 있는 일에 쓸 수 있었다.

이 두 가지를 걸러 내는 것만으로도, 나는 헛심을 꽤 아꼈다. 고르는 눈은 결국 ‘만들 것’과 ‘만들지 않을 것’을 함께 보는 눈이었다.

하나가 다음을 부른다, 열두 개가 쌓인 방식

돌아보면 열두 개는 계획해서 나온 숫자가 아니다. 첫 번째 도구가 생각보다 잘 돌아가고, 그게 눈에 보이는 결과로 남으니, 자연스럽게 ‘그럼 저것도 되지 않을까’ 하는 생각이 따라왔다. 하나를 만들면 다음이 보였고, 앞서 만든 조각(끌어다 놓기 실행 방식 같은)을 다시 쓰니 두 번째, 세 번째는 점점 빨라졌다.

열두 개째에 이르러서는, 새로운 반복 업무를 만나면 ‘이건 며칠이면 붙이겠다’는 감이 먼저 왔다. 그 감이 생긴 것이 도구 개수보다 더 남는 것이었다. 처음엔 도구를 하나 만드는 게 목표였는데, 어느새 ‘어떤 일을 도구로 바꿀 수 있는가’를 보는 눈이 생겨 있었다.

그래서 지금 반복 업무에 지쳐 있는 분께 권하고 싶은 건 ‘열두 개를 만들라’가 아니다. 딱 하나만 골라 보라는 것이다. 앞의 네 기준으로 오늘 한 일을 훑어보면, 유난히 자주·오래·위험한 일 하나가 반드시 눈에 걸린다. 그 하나부터다. 나도 그 하나에서 시작했다.

마치며: 코딩보다 먼저 필요한 건 고르는 눈

나는 개발자가 아니다. 넉 달 동안 도구 열두 개를 만들었지만, 그 사이 내 코딩 실력이 는 것 같지는 않다. 대신 분명히 는 것이 하나 있다. 무엇을 자동화하고 무엇은 두어야 하는지 고르는 눈이다.

자동화는 대단한 기술에서 시작되지 않았다. 매달 나를 지치게 하던 일 하나를 정확히 짚는 데서 시작됐다. 자주 하는가, 오래 걸리는가, 틀리면 위험한가, 다시 쓸 수 있는가. 이 네 가지만 스스로에게 물어도, 어디부터 손댈지가 보인다. 구현은 그다음 문제고, 그건 요즘 도구의 도움을 받으면 된다.

혹시 “나는 코딩을 못 하니까”라며 미뤄 둔 반복 업무가 있다면, 만드는 법을 배우기 전에 고르는 연습부터 해 보시길 권한다. 가장 자주, 가장 오래, 가장 위험한 일 하나. 거기서부터 생각보다 많은 것이 바뀐다.

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

]]>

아직도 1년 전 프롬프트를 그대로 쓰고 있나요?

저장해 두고 매번 그대로 다시 쓰는 프롬프트가 있나요? 저는 몇 가지 있습니다. 프롬프트 엔지니어링이 한참 유행할 때, 만든 프롬프트인데요. 성능이 꽤 훌륭해 즐겨 쓰고 있었습니다. 이런 프롬프트는 몇 가지 비슷한 구조를 가집니다. “단계별로 생각하세요”, 같은 규칙을 여러 차례 강조한 문단, 도구 쓰는 법을 예시로 늘어놓은 블록, “오늘은 2026년 8월입니다” 같은 기준 문구.

그런데 어느 순간, 이런 프롬프트가 영 제 성능을 내지 못했습니다. 그래서 이유를 찾다 보니 더는 이런 규칙이 큰 효과를 내지 못한다는 걸 알게 되었습니다.

앤트로픽은 최근 블로그 글 「클로드 5세대 모델을 위한 컨텍스트 엔지니어링의 새 규칙」에서 클로드 오퍼스 5·페이블 5용 클로드 코드 시스템 프롬프트의 80% 이상을 지웠다고 밝혔습니다. 코딩 평가에서 측정 가능한 손실은 없었다고 했고요. 심지어 그동안 모범 사례로 통했던 컨텍스트 엔지니어링 요령 여러 개를 두고 “미신(myth)”이라고 부르기까지 합니다.

<출처: 앤트로픽>

그래서 궁금해졌습니다. 그렇다면 지금의 AI는 어떻게 써야 하지? 무슨 프롬프트와 컨텍스트를 줘야 하지?

AI 모델을 만드는 회사, 앤트로픽과 오픈AI, 구글과 xAI, 문샷이 발표한 공식 문서를 훑었습니다. 그랬더니 몇 가지 공통점이 보이더라고요. 프롬프트와 컨텍스트, 하네스의 오래된 미신들을 찾고, 바로 점검할 만한 규칙들을 정리했습니다. 새 술은 새 부대에 담아야 하는 겁니다.

낡은 규칙과 미신들

우선 자주 쓰던 프롬프트에서 지워도 괜찮은 것들부터 볼까 합니다. 아래는 널리 퍼진 프롬프트와 컨텍스트 방법론 가운데, 최신 문서들이 직접 낡았다고 표시한 항목입니다.

1. “단계별로 생각해”, “네 추론을 설명해”

오픈AI의 추론 모델 베스트 프랙티스는 모델이 내부에서 추론하니 이 두 문구가 불필요하다고 적어 뒀습니다. 구글 제미나이 프롬프트 전략 문서도 내부 사고 텍스트가 자동 생성되니 응답 안에서 추론 단계를 서술하게 할 필요는 일반적으로 없다고 합니다.

2. 도구 쓰는 법을 예시로 알려주기

이 방식은 도구 사용의 1순위 규칙이었는데요. 앤트로픽은 최신 모델에서 그 예시가 오히려 모델을 특정 탐색 공간에 가둔다는 걸 발견했다고 합니다. 예시는 만들기 힘들뿐 언제든 옳다고 생각했는데, 그렇지 않다는 거죠.

3. 같은 규칙을 두 군데에 반복해 쓰기

예전 클로드 모델은 컨텍스트 창 끝의 지시를 앞의 지시보다 더 잘 듣는 경향이 있었어요. 그래서 도구 얘기를 시스템 프롬프트에도 쓰고 도구 설명에도 쓰는 관습이 생겼습니다. 하지만 이제는 토큰 낭비에 가깝습니다. 알아서 잘 이해하니까요.

4. 상세한 단계별 절차 안내, 그리고 프롬프트에 적어 둔 출력 스키마

오픈AI GPT-5.5 모델 가이드의 레거시 프롬프트 정리 체크리스트가 두 가지 문제를 나란히 지목합니다. 제품이 그 경로를 요구하는 게 아니라면 경로는 모델이 고르게 두고, 스키마는 Structured Outputs로 옮기는 편이 좋습니다.

5. “오늘은 2026년 8월입니다” 같은 현재 날짜 문구

요즘 모델은 현재 날짜(UTC)를 이미 안다고 문서에 적혀 있습니다.

6. 역할 부여와 단계 명시

“전문가처럼 생각해” 계열이죠. 이걸 이제 지우라고 못 박은 문서는 아직 없긴 합니다. 다만, 최근 가이드에서는 이런 안내가 자취를 감췄습니다. 특히, 7월 들어서는 이런 역할 부여가 있던 최상단 자리에 어떤 판단을 해야 하는지 두라는 서술들이 보입니다.

7. 문서를 상주 컨텍스트에 다 올리기

구글 Genkit 블로그(7월 31일)는 표준 운영 절차와 참조 가이드, 문서를 모두 올려 두는 건 지속 가능하지 않다고 적습니다. 도구 정의를 전부 요청에 넣는 방식도 문샷 키미 K3 도구 호출 문서가 하지 말라고 하죠.

<출처: 작가>

정리하고 보니 꽤 충격적이네요. “10년 차 개발자처럼 생각해”라든가 “단계별로 생각해” 같은 건 이제 숨 쉬듯 그대로 넣는 문구 중 하나였거든요. 오픈AI는 이러한 예전 프롬프트가 구형 모델이 궤도를 유지하도록 절차를 과하게 규정해 둔 것뿐이라고 합니다. 지금 모델에 이를 그대로 옮기면 노이즈가 되고 탐색 범위만 좁아진다고 하죠.

그럼 왜 이러한 변화가 생긴 걸까요?

모델을 움직이는 도구의 변화

요즘 모델은 클로드 코드나 코덱스처럼 최적화된 껍데기를 함께 달고 나옵니다. 또 지금의 챗GPT와 클로드, 제미나이 웹 버전은 초기 형태와 비교하면 무척 다양한 기능을 달고 있죠. 예전엔 “테스트 돌려서 확인까지 해”라고 적어 주는 게 당연했잖아요. 그렇게 사람이 프롬프트로 채워 넣던 절차가 이미 그 껍데기들, 그러니까 하네스 안에 들어가 있습니다.

저 프롬프트들이 맡고 있던 것, 그러니까 계획과 검증도 그 안에 들어갔습니다.

앤트로픽은 「모든 작업에 맞는 하네스」라는 글에서 기본 클로드 코드 하네스가 한 컨텍스트 창 안에서 계획과 실행을 같이 해야 한다고 설명합니다. 그 방식이 무너지는 작업을 위해 클로드가 직접 하네스를 만들어 쓰는 동적 워크플로를 공개했고요. 뒤에 나온 글 「스킬로 검증 루프 만들기」에서는 에이전트가 테스트, 린터, 자체 점검까지 돌려 실패한 걸 고치고 나서야 다음으로 넘어간다고 정의합니다. 물론, 알아서 다 봐준다는 얘기는 아니지만요. 사람이 손으로 하던 점검을 스킬로 옮겨 두면 클로드가 자기 피드백 루프를 닫는다는 뜻입니다.

그러니 프롬프트로 주던 절차 지시가 하네스와 겹치기 시작합니다. 앤트로픽이 자기들 시스템 프롬프트를 지우며 찾아낸 것도 그 부분이었죠. 시스템 프롬프트와 CLAUDE.md, 스킬들이 클로드 코드를 과도하게 제약하고 있었고, 한 요청 안에 “적절히 문서를 남겨라”와 “주석을 달지 마라”가 같이 들어가 있기도 했다는 겁니다.

모델도, 이를 둘러싼 하네스도 알아서 발전하고 있으니 사용자가 직접 채울 일이 줄었다는 뜻입니다.

모델 만든 회사가 직접 알려주는 지금 기준

다행히 모델을 만든 회사에서 직접 새로운 모델을 잘 쓰는 방법을 알려 줬습니다. 비슷합니다. 덜어내는 게 먼저, 남길 건 결과와 중단 조건이라는 겁니다. 나머지는 필요할 때 불러오게 만드는 것이 좋습니다.

이 규칙들을 모델에 명령을 내리는 세 층, 프롬프트와 컨텍스트, 그리고 하네스로 나눠 정리했습니다.

프롬프트: 목적지만 적고 경로는 맡기기

오픈AI GPT-5.6 프롬프트 가이드는 첫 단락부터 이렇게 적습니다. 프롬프트에서는 결과와 중요한 제약, 쓸 수 있는 근거, 완료 기준만 정의하고, 모델이 어떤 경로를 고를지 여지를 남길 때 가장 잘 작동한다는 거예요. “항상”·“절대”는 안전 규칙처럼 진짜 예외가 없는 곳에만 쓰고, 판단이 필요한 사안에는 결정 규칙을 적으라고 덧붙입니다.

<출처: 오픈AI>

충돌 지시 얘기도 같은 강도로 합니다. GPT-5 계열은 프롬프트 계약을 밀착해 따르니 상충하는 규칙이 디테일 부족보다 더 큰 불안정을 만든다는 겁니다. 지시를 줄이라는 말과는 다릅니다. 서로 부딪히는 지시를 없애라는 쪽이에요.

한편 앤트로픽은 도구 사용법을 예시로 남기면 탐색 공간이 좁아진다는 이야기도 합니다. 프롬프트의 기본 방법론이었던 퓨샷(few-shot) 규칙과 정면으로 부딪치죠. 그 자리는 도구·스크립트·파일의 설계가 대신 채웁니다. Todo 도구의 상태 값(pending·in_progress·completed)이 그 자체로 사용법의 힌트가 되는 식이죠.

그럼 어떤 예시를 남겨야 할까요? 오픈AI에 따르면, 행동을 바꾸지 않는 예시는 빼는 것이 좋습니다.

사고를 어떤 단계로 해나갈지도 같은 방식으로 정리하는 것을 추천합니다. 응답 안에 추론 단계를 서술하게 만드는 지시는 오픈AI와 앤트로픽 모두 불필요하다고 적었어요. 꼭 쓰고 싶다면 무거운 문제를 풀 때만 노력(effort) 정도를 조건부로 지목하라고 합니다.

컨텍스트: 지나치게 많은 것은 덜어내기

일단 과도한 컨텍스트를 덜어내라는 제안은 어느 문서나 같습니다.

구글 Genkit 블로그는 문서를 있는 대로 다 올려 두면 토큰은 토큰대로 쓰면서 모델의 초점까지 흐린다고 적습니다. xAI는 파일이 전부 로드되니 긴 지시보다 짧고 구체적인 지시가 더 안정적으로 지켜진다고 쓰고요. 문샷은 도구 정의를 다 넣으면 잘못된 도구를 고를 확률이 높아진다고 하죠.

오픈AI는 여기에 숫자 기반 관측까지 더합니다. 내부 코딩 에이전트 평가 실행 표본에서 시스템 프롬프트를 가볍게 한 구성이 평가 점수를 약 10~15% 올리고 비용은 33~67% 줄였다고 공개했어요. 다만 워크로드마다 결과가 달라지니 이 범위는 방향 지시로만 보고 각자 애플리케이션의 대표 태스크에서 검증하라는 단서를 달았고요.

하네스: 분리한 컨텍스트를 잘 찾는 구조

그렇다고 덜어낸 컨텍스트를 아예 참조하지 말라는 건 아닙니다. 이를 잘 정리해 두고, 필요한 것만 적절하게 찾아오는 구성을 짜야 합니다.

구글은 Genkit Go에 에이전트 스킬을 넣으면서 그 원리를 프로그레시브 디스클로저(progressive disclosure), 곧 필요할 때만 정보를 드러내는 방식이라고 설명해요. 이를테면 SKILL.md에서 처음에는 프론트매터(frontmatter)만 노출하고 조건이 맞으면 본문을 불러오는 것이 좋습니다. 남의 랩에서 나온 파일 규격을 자사 프레임워크에 넣은 셈이죠.

다른 곳도 방식만 다릅니다. 앤트로픽은 일부 도구를 지연 로딩으로 두고 에이전트가 ToolSearch로 정의를 찾은 뒤 쓰게 만들었고, 문샷과 오픈AI는 검색 도구 하나로 같은 일을 합니다.

층별 역할도 다시 배치하라고 합니다. 앤트로픽은 CLAUDE.md를 가볍게 두고 저장소 용도로만 짧게 적되, 토큰 대부분은 코드베이스 안의 함정을 피하는 데 쓰라고 권합니다. 파일 시스템이나 저장소를 보면 알 수 있는 뻔한 내용은 적지 말라고 하고요.

외부 검증 결과도 있습니다. 취리히연방공대 SRI 랩의 「AGENTS.md 평가」는 여러 코딩 에이전트와 모델을 대상으로 컨텍스트 파일이 작업 성공률을 올리지 못하면서 추론 비용만 20% 넘게 올렸다고 보고했습니다. 논문 결론 자체는 사람이 쓴 컨텍스트 파일이 최소 요구사항만 적어야 한다는 쪽이라, 개발사들이 내놓은 최신 권고와 비슷한 방향입니다. 컨텍스트 파일이 무의미하다는 게 아니라 무엇을 적는지에 따라 갈린다는 뜻이겠죠.

<출처: 취리히연방공대 SRI 랩>

오늘 바로 지울 프롬프트/남길 프롬프트

다만, 이미 내 작업에 깊이 관여하는 항목들을 갑자기 지우면 어떤 문제가 생길지 모릅니다. 그러니 낡은 목록을 실제 프롬프트에서 걷어낼 때 역시 순서가 중요합니다.

한꺼번에 다시 쓰지 말고 이미 작동하는 프롬프트와 도구 세트에서 지시나 예시, 도구를 한 그룹씩만 빼고 같은 평가를 다시 돌리는 것이 좋습니다. 그래야 무엇이 실제로 행동을 바꾸던 지시였는지 알 수 있으니까요. 특히, 모델 업데이트와 함께 잘 쓰던 규칙이 이상해졌을 때 해볼 만합니다.

안 쓰는 도구와 반복되는 승인 규칙이 특히 그 대상입니다. 오픈AI는 태스크와 관련된 도구만 노출하고, 안전한 행동(파일 읽기, 로그 확인, 범위 안 코드 수정, 테스트 실행)은 허용 목록으로 묶고, 정책은 한 곳에 한 번만 적으라고 합니다. “먼저 물어라”나 “승인을 기다려라”를 여기저기 반복하면 예상할 수 있는 안전한 행동에까지 승인 요청이 쏟아집니다.

물론 반드시 남겨야 하는 것도 있습니다. 사용자에게 보이는 결과, 성공 기준과 중단 조건, 안전·비즈니스·권한에 기반한 제약, 맥락에 따라 도구를 고르는 라우팅 규칙, 필요한 출력 형태와 검증 요구입니다.

마지막으로, 어떤 프롬프트를 써야 하나 싶을 때면 앤트로픽 페이블 5 실무 가이드(7월 6일)에 그대로 복사해 써볼 만한 예시가 실려 있습니다.

Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture.
애매한 게 있으면 한 번에 한 질문씩 나를 인터뷰해 줘. 내 답이 아키텍처를 바꿀 만한 질문을 먼저.

Can you do a blind spot pass to help me figure out my relevant unknown unknowns and help me prompt you better.
내가 모른다는 것조차 모르는 부분을 찾도록 블라인드 스팟 패스를 해 줘. 그래서 내가 더 잘 시킬 수 있게.

마치며

이 모든 건 모델과 하네스가 똑똑해졌으니 명령을 덜어내라는 얘기지, 직접 만든 하네스를 버리라는 뜻은 아닙니다.

앤트로픽은 클로드가 한 컨텍스트 창에서 오래 일할 때 나타나는 실패 유형을 「모든 작업에 맞는 하네스」에 적어 뒀어요. 복잡한 다단계 작업을 끝내지 않고 중간에 완료를 선언하는 것(보안 검토 50개 항목 중 35개만 처리하고 끝내는 식), 검증이나 판정을 시키면 자기 결과를 편애하는 것, 요약이 반복되면서 “X를 하지 마라” 같은 제약이 사라지는 것. 그러니 실제로 실무 환경처럼, 컨텍스트를 길게 소비하며 작업을 돌릴 때는 사람이 만든 하네스를 쌓아가는 것이 좋습니다.

그렇다면 사람이 명령해야 하는 것은 뭘까요? 모델이 스스로 알아낼 수 없는 것만 적는 겁니다. 그리고 그 ‘알아낼 수 없는 것’이 무엇인지는 이 작업을 가장 잘 아는 나만이 답할 수 있습니다.

무엇보다 이 모든 건 내가 풀어야 할 문제로 돌아옵니다. 어느 문서나 대부분 같은 단서가 달려 있습니다. 내가 자주 쓰는 대표 태스크에서 직접 검증하라는 거죠. 낡은 목록에서 무엇을 지우고 무엇을 남길지 가르는 기준은 결국 내 작업에서만 나옵니다. 그러니 직접 써보면서 스스로 맞는 방법을 찾아가길 권합니다.

]]>