GPTers 스터디 「홈랩에서 24시간 멈추지 않는 AI 에이전트 운영 인터페이스」 4주차 사례 발표
서비스: https://datalab.sogoodmarketing.kr
이번 발표는 시연이 아니라 삽질 기록과 교훈 공유입니다.
아직 분석 스킬들이 많이 부족하지만, 앱은 잘 돌아가고 있고,
마지막 사례발표에서는 앱이 돌아가는 것이나 분석 결과를 보여드리는 것 보다는
개발 과정에서 배운 것들 위주로 정리해봅니다.
1. 3주차 -> 4주차 앱 개발 작업 요약
목표 (2차발표 이후): 이 앱을 「에이전트가 쓰는 분석 서버」로 만든다 — 사람이 화면으로 조작하던 걸, 화면 없이 채팅으로도 되게 한다.
만든 것
· Docker 전환 — web·worker·cloudflared 전부 컨테이너화 (기존엔 web·worker가 맥 OS 네이티브였음)
· MCP 서버 — 도구 8개(세트 조회·개요·세트 생성+수집+분석 자동 연계·보고서 조회)
· 실제 연결 — claude.ai 웹 커넥터로 실제 연결·도구 호출 성공
모식도 — 이전(2차발표 시점)
: web·worker는 맥 OS에서 직접 실행, Docker 안에는 cloudflared(터널)뿐
방문자 브라우저
│ HTTPS
▼
datalab.sogoodmarketing.kr
│
▼
Cloudflare (전 세계 엣지)
│ 터널 (안쪽에서 바깥으로 연결)
▼
┌──────────────────────────────────────────┐
│ 맥스튜디오 (로컬, 24시간 가동) │
│ │
│ ┌── Docker ──────────┐ │
│ │ cloudflared │ ← 터널 연결만 │
│ └─────────┬──────────┘ │
│ │ host.docker.internal:8001 │
│ ▼ │
│ ┌── 도커 밖 (macOS 자체 실행) ────────┐ │
│ │ web — 화면·API·AI 채팅 │ │
│ │ worker — 수집·분석 백그라운드 │ │
│ │ SQLite — 데이터베이스 │ │
│ └─────────────────────────────────┘ │
└──────────────────────────────────────────┘모식도 — 지금(3차발표)
: web·worker도 Docker 안으로 들어옴 + web에 MCP 서버(/mcp)가 붙어 에이전트도 같은 문으로 들어옴
방문자 브라우저 claude.ai (에이전트)
│ HTTPS │ HTTPS + OAuth
▼ ▼
└────────────┬───────────────┘
▼
datalab.sogoodmarketing.kr
│
▼
Cloudflare (전 세계 엣지)
│ 터널
▼
┌──────────────────────────────────────────────┐
│ 맥스튜디오 (로컬, 24시간 가동) │
│ │
│ ┌── Docker ──────────────────────────────┐ │
│ │ cloudflared ← 터널 연결만 │ │
│ │ │ 127.0.0.1:8001 (외부 비공개) │ │
│ │ ▼ │ │
│ │ web — 화면·API·AI 채팅·MCP 서버(/mcp) │ │
│ │ worker — 수집·분석 백그라운드 │ │
│ └──────────────────┬─────────────────────┘ │
│ │ 볼륨 마운트 │
│ ▼ │
│ SQLite · 백업 · 문서 볼트 (호스트) │
└──────────────────────────────────────────────┘가장 큰 변화는 진입점이 하나 더 늘어난 것입니다 — 사람은 브라우저로, 에이전트는 MCP로,
같은 서버·같은 데이터에 들어옵니다.
지난주까지 해결못하던 "도커 안에 넣지 못했다"는 과제가 프롬프트 한줄로 해결되었습니다claude setup-token
무슨 말이냐구요? 지금부터 설명 드리겠습니다.
2. 구독 vs API 키 개념 정리
핵심 비유
· 구독(Pro·Max) : 예를 들면, 신분증 — 확인 방식: "나"라는 사람을 직접 확인 / 과금: 월 정액 / 대여 가능?: 원칙적으로 안 됨
· API 키 : 예를 들면, 법인카드 — 확인 방식: 카드 번호만 맞으면 통과 / 과금: 쓴 만큼 종량제 / 대여 가능?: 아무 프로그램에나 넘겨도 됨
"신분증(구독)" = "OAuth" ??
신분증(구독)은 OAuth라는 절차를 거쳐서 나오는 결과물,
OAuth는 신분증을 만들어내는 방법 그 자체입니다.
OAuth는 두 단계 과정
· ① 발급 — "너 맞구나" 확인받고 토큰을 받음. 사람 개입 필요(보통 한 번)
· ② 사용 — 그 뒤로는 토큰만 제시. 사람 개입 불필요
OAuth-①(발급) 의 두 가지 방식
: 이걸 몰랐던 것이 Docker 작업을 헤맨 진짜 원인이었습니다.
①-1 자동 브라우저 인증 — 하는 일: 로그인 화면에서 클릭만 하면 앱이 알아서 토큰을 받아 보관 / 난이도: 쉬움, 제일 흔한 방식 / 옮길 수 있나: 그 앱·그 컴퓨터 안에 갇힘(사람이 꺼내 볼 수도 없음) claude login
①-2 직접 토큰 발급 — 하는 일: 별도 명령을 실행해서 토 큰 문자열 자체를 손에 쥠 / 난이도: 한 단계 더 필요 / 옮길 수 있나: 어디든 복사해서 넣을 수 있음(확장성이 여기서 나옴)claude setup-token
규칙을 다시 정리하면
내가 로컬에서 직접 쓸 때는 신분증(구독)도 되지만,
"다른 시스템(eg.도커)에 넘겨서 대신 쓰게 하는 순간"부터는 신분증을 "자동 브라우저" 방식으로 발급받은 상태로는 못 옮긴다.
이때 방법은 둘 중 하나다 — ① 아예 법인카드(API 키)로 바꾸거나, ② 같은 신분증을 "직접 토큰" 방식으로 다시 발급받는다.
오늘 Docker 전환은 ②(신분증 유지, 발급 방식만 교체)였습니다 — 구독 과금 그대로 쓰면서 컨테이너로 옮긴 것이 핵심이었습니다.
결과
저(AI)는 애초에 "자동 브라우저 인증" 한 가지 방식만 알고 있었고, 그래서 "컨테이너에는 브라우저가 없으니 구독 인증은 원천적으로 불가능하다"고 결론 내렸습니다. claude setup-token이라는 직접 발급 방식이 따로 있다는 것 자체를 몰랐던 것이 한달간 헤맨 진짜 원인이었습니다
이재엽스터디장님이 툭~ 한마디를 던졌습니다
"터미널에서 claude setup-token 실행 한번 해보세요~"
이후의 과정은 일사천리였습니다
물론 사소한 문제들이 있었지만 클로드코드-오퍼스5가 무난히 해결해가면서,
한달 내내 풀리지 않던 절름발이 도커 문제가 1시간도 안걸려 모두 해결되었고,
이제는 완벽하게 도커 안에서 앱이 구동되고 있습니다
3. MCP 서버 만들기 — claude.ai가 요구하는 접속 규격
앱을 도커에 넣은 뒤, 앱을 MCP서버로 만들기 시작했습니다. 헤르메스-슬랙, 클로드웹, 노션 같은 다양한 진입점을 만들기 위해서 입니다.
MCP서버를 클로드 커넥터에 등록하는 과정에서 인증 문제가 해결되지 않아 계속 삽질을 했습니다.
claude.ai 커스텀 커넥터는 "자동 브라우저 인증"만 강제합니다 — 고정 토큰을 붙여넣는 칸 자체가 없고, "연결" 버튼을 누르면 무조건 로그인 화면으로 보내는 정식 OAuth 절차를 갖춰야만 통과됩니다
처음에는 클로드코드가 구글이나 깃허브로 우회해서 인증을 하겠다고 우깁니다. 하지만, 예전에 만든 위키 검색 도구(wiki-mcp)에서 똑같은 문제를 이미 충분히 겪었던 기억이 났고, 정확한 기술적 내용은 잘 몰랐기 때문에, wiki-mcp만들었을 때의 기록을 찾아보라고 프롬프팅했습니다. 결과는 성공~! OAuth+PIN 로그인으로 우회했던 기록이 있어, 그 코드를 그대로 이식해서 무난히 작업을 완료했습니다.
MCP 서버를 원격으로(내 컴퓨터 밖에서) 붙이려는 분이라면 아래 두 가지는 실제로 부딪히게 되는, 서로 다른 지식입니다.
지식 1 — 접속하는 클라이언트마다 "발급 방식"이 다르게 강제된다
· claude.ai 웹 커넥터 — 자동 브라우저 인증만 / 비고: 직접 토큰(고정값) 넣는 칸 자체가 없음
· Claude Desktop 설정 파일 — 직접 토큰 발급도 가능 / 비고: 설정 파일을 직접 편집할 수 있으면 더 간단
"발급 방식은 자동 브라우저 vs 직접 토큰, 둘로 나뉜다"고 했는데, 그 선택권이 우리한테 있는 게 아니라 접속하는 클라이언트(claude.ai, Desktop)가 정합니다. claude.ai는 자동 브라우저 방식만 받아주기 때문에, 저희가 처음 시도했던 "고정 토큰 하나로 끝내기"는 애초에 통할 수 없는 방법이었습니다.
지식 2 (완전히 별개 문제) — "발급 창구"와 "실제 출입문"은 다른 위치에 있어야 한다
이건 "어떤 발급 방식을 쓰느냐"와는 상관없이, 주소를 어디에 둘 것이냐의 문제입니다.
우리 서버를 건물 하나라고 생각해보면 이렇습니다.
· 로비(도메인 루트) = "신분증 발급받는 창구"가 있는 곳
· 3층 특정 사무실(/mcp) = 그 신분증을 들고 실제로 들어가서 일을 보는 곳(도구를 호출하는 곳)
claude.ai는 우리 건물에 처음 올 때 무조건 로비에서 발급 창구를 찾습니다
— "이 건물 발급 창구 어 디예요?"를 로비에서만 물어봐요.
저희가 처음엔 발급 창구를 3층 사무실 안에 숨겨뒀는데(=/mcp 아래에 넣어둠), claude.ai는 로비에서 못 찾고등록에 실패했습니다. 그래서 발급 창구는 무조건 로비(도메인 루트)에 있어야 했던 거예요.
그리고 "발급 창구"와 "실제 출입문"은 원래 다른 위치에 있는 게 정상입니다
—신분증은 로비에서 만들지만, 그 신분증으로 들어가는 문은 3층 사무실이잖아요.
저희가 처음엔 이 둘을 같은 위치로 착각해서 또 오류가 났습니다(로그인은 됐는데 정작 도구 호출은 거부되는 문제).
마지막으로 "표준"이라는 건 — 이 발급 절차가 claude.ai만의 특별한 규칙이 아니라, 여러 회사가 같이 쓰기로 약속한 공용 규칙이라는 뜻입니다. 전국 어디서나 통하는 신분증 발급 규격처럼요. 그래서 한 번 이 규격대로 발급 창구를 만들어두면, claude.ai뿐 아니라 같은 규격을 쓰는 다른 서비스(Notion 등)에서도 그대로 통합니다. (OAuth 2.1·DCR·PKCE는 그 규격 안의 세부 절차 이름일 뿐이라 외우실 필요는 없습니다.)
지식 3 — 표준 규격을 지키면서도 "우회"할 수 있는 지점이 있다
발급 창구(정식 규격)를 만드는 방법은 크게 두 가지입니다.
1. 이미 있는 큰 회사(구글·깃허브)의 로그인에 통째로 맡기기 — "구글로 로그인" 버튼
2. 직접 나만의 발급 창구를 만들기
1번이 더 쉬워 보이지만, wiki-mcp에서 이미 시도했다가 실패한 적이 있습니다
—구글 로그인을 claude.ai가 요구하는 정식 절차에 연결하는 부분이 기술적으로 맞지 않았기 때문입니다.
그래서 2번(직접 만들기)을 택했는데, 진짜 우회는 여기 있습니다: 발급 창구의 겉모습(claude.ai가 알아보는 정식 규격)은 그대로 다 갖추되, 그 창구 뒤에서 실제로 확인하는 절차는 최대한 간단하게 만드는 것입니다.
비유하면
— 신분증 발급 창구를 정부 표준 양식으로는 정확히 만들지만, 그 안에서 실제로 확인하는 건 복잡한 신원조회가 아니라 "비밀번호(PIN) 하나가 맞는지"만 보는 겁니다. 이 서비스는 쓰는 사람이 저(운영자) 한 명뿐이라, 복잡한 회원 시스템을 새로 만들 이유가 없었습니다. 이 방식 자체도 새로 고안한 게 아니라, wiki-mcp를 만들 때 이미 검증해둔 방법을 그대로 가져온 것입니다.
4. AI와 사람의 역할 분담 — 오늘 얻은 교훈
이번 개발 과정에서 도커 내부에서의 클로드 인증 문제, 그리고 MCP서버를 클로드커넥터에 등록하면서 인증 문제, 두 번의 큰 막힘이 있었는데, 둘 다 AI가 "몰라서"가 아니라 "어디를 찾아봐야 하는지 물어볼 생각을 안 해서" 풀지 못하고 헤맸었다는 결론입니다.
과정
· Docker 인증 — 막힌 이유: AI가 "이미 아는 사실(구독은 브라우저 필요)" 안에서만 사고. 풀린 계기: 이재엽 스터디장의 아이디어가 완벽한 발화점이 됨
· MCP 인증 방식 — 막힌 이유: AI가 곧장 일반적인 업계 패턴(외부 로그인 위임)을 리서치. 풀린 계기: 내가 "정확히 내가 알고 있는 내용은 아니지만, 예전에 비슷한 문제를 해결했던 것 같은데, 그 폴더 뒤져봐"
· 두 경우 모두 AI에게 새로운 기술 지식이 부족했던 게 아니라, 다른 방식으로 접근해볼 생각을 하지 못한 것이 원인. 페이블 같은 고성능의 목표 지향 AI가 여러가지 웹서치와 시행착오를 통해 끝내 결과를 만들어냈다고 하더라도, 그 결과까지 들어갔을 토큰과 시간까지 감안한다면 매우 심각한 문제일 수 있음
교훈
사람이 해야하는 역할과 AI가 해야 하는 역할은 다르다!
· 사람의 역할: 여러가지 경로를 찾아봐야 한다. 방향을 정해야 한다. 방법까지 직접 알 필요는 없다.
· AI의 역할: 문제가 던져지면 빠르게 해법을 조사해서 풀어간다.풀거나 조사한다.
— 사람이 방향을 한 번 짚어주면, 그 다음부터는 AI가 알아서 좁혀나간다.
