행사 242개를 AI로 추려 캘린더에 넣기까지 (Seattle Tech Week 2026)

Seattle Tech Week 2026이 이번 주(7/27~31) 시애틀에서 진행 중이다. 일주일 동안 열리는 행사가 242개, 그중 AI 태그가 붙은 것만 77개다.

전부 내 관심 분야라 오히려 고르기가 어려웠다. 갈 만한 게 없는 게 아니라, 관심 가는 게 한 주에 몰려 있는 게 문제였다. 행사 하나 확인하는 데 2분씩만 잡아도 8시간이 넘는다.

이걸 AI에게 맡기는 과정에서, 같은 문제를 두 에이전트가 어떻게 다르게 접근하는지 꽤 선명하게 볼 수 있었다. 결론부터 말하면 이번 건은 명확히 Codex Win이었다.

1. Claude Code가 막힌 지점

처음 요청은 단순했다. "이 페이지에 있는 행사들을 정리해줘."

Claude Code는 Luma 허브 페이지를 찾아냈다. 거기까지는 문제없었다. 그런데 각 행사의 날짜·시간·장소·신청 링크를 안정적으로 추출하지 못했다.

이유는 명확하다. Luma는 동적 웹앱이다. 사람 눈에 보이는 카드 목록은 정적 HTML에 들어 있는 게 아니라, 브라우저 안에서 API 호출로 렌더링된 결과다. 즉 "페이지를 찾았다"와 "그 페이지의 모든 이벤트 데이터를 구조화해서 가져왔다"는 전혀 다른 문제다.

게다가 이벤트가 200개가 넘으면 개별 링크를 하나씩 타고 들어가는 방식은 금방 병목이 된다. 결국 내가 화면 캡처를 제공하고, AI가 그걸 읽어 표로 만드는 우회로를 택했다. 하루치는 처리되지만 5일치를 하려면 같은 짓을 반복해야 한다. 확장성이 없는 방식이었다.

자동화하려다 반자동 수작업이 된 셈이다.

2. Codex가 문제를 다시 정의한 방식

같은 상황을 Codex에게 그대로 설명하고 방법을 물었다.

Codex는 "화면을 더 잘 읽는 방법"을 찾지 않았다. 대신 "이 화면이 데이터를 어디서 가져오는가"를 추적했다. JavaScript 번들과 네트워크 호출 구조를 확인해, 허브가 내부적으로 쓰는 공개 API 엔드포인트를 찾아냈다.

확인된 정보는 이랬다.

• Calendar ID: cal-7YGhWSN0o5k0LsQ
• Endpoint: https://api.luma.com/calendar/get-items?calendar_api_id=...&period=future
• 페이지네이션: pagination_limit, pagination_cursor, has_more, next_cursor

이 API를 호출하니 각 이벤트의 제목, 시작·종료 시간, 장소, 태그, 등록 상태, URL이 구조화된 JSON으로 떨어졌다. 페이지네이션을 따라가며 전체를 수집해 242개 전량을 확보했다.

구분 Claude Code 초기 방식 Codex 해결 방식

접근 대상	화면, 검색 결과, 사용자 캡처	공개 JSON API
데이터 형식	화면 텍스트, 수동 링크 매칭	구조화된 JSON
확장성	날짜별 캡처 필요	전체 자동 수집
병목	이벤트별 링크 추적	페이지네이션 처리

중요한 건 어느 모델이 더 똑똑하냐가 아니다. 문제를 어떤 레벨로 정의했는가가 결과를 갈랐다. "이 페이지의 행사들을 정리해줘"는 사람에게는 자연스러운 요청이지만, 에이전트에게는 동적 렌더링·숨겨진 API·페이지네이션·링크 매칭·상태 변경이 뒤섞인 복합 요청이다.

3. 수집 다음이 진짜 일이다

데이터가 모였다고 끝이 아니다. AI 태그만 77개인데 다 갈 수는 없다.

AI에게 내 기준을 줬다. 지금 진행 중인 프로젝트와의 관련성, 시간 충돌 여부, 시애틀-벨뷰 이동 부담(편도 약 30분). 결과물은 추천 목록이 아니라 내가 Yes/No만 판단하면 되는 후보표였다.

여기서 한 가지 짚어둘 게 있다. AI가 내 기준을 알 수 있었던 건 평소에 작업 기록을 로컬 마크다운으로 남겨뒀기 때문이다. WorkLog, Daily Roundup, Topic 문서가 쌓여 있으니 AI는 "이 사람이 무엇에 관심 있는지"를 추론할 근거를 갖고 시작했다. 그래서 인기 있어 보이는 행사가 아니라, 내가 하던 일과 연결되는 행사를 우선 보고했다.

최종적으로 참가 확정 12개, 승인 대기 12개. Google Calendar에 반영하고 승인 메일이 올 때마다 상태를 갱신했다.

4. 한 번의 통찰을 재사용 가능하게 만들기

여기서 끝났으면 그냥 잘 풀린 사례 하나였을 것이다.

일주일 뒤, 전혀 다른 사이트(Wix 기반 페이지)에서 똑같은 벽을 만났다. WebFetch가 "JS로 동적 렌더링돼서 내용을 다 못 가져온다"고 보고했다. 그때 이 원칙을 다시 적용했다 — 화면 말고 데이터 원천을 찾는다. 원본 HTML을 직접 받아보니 페이지 안에 임베드된 JSON 객체에 전체 콘텐츠가 들어 있었다.

같은 접근이 두 번 통했으면 그건 우연이 아니라 패턴이다. 그래서 이 방법 자체를 web-data-extraction이라는 재사용 가능한 스킬로 정리했다. 다음에 같은 상황이 오면 AI가 이 원칙을 잊지 않도록.

재사용 가능한 절차는 대략 이렇다.

1. 사용자가 보는 화면과 AI가 접근 가능한 데이터가 같은지 먼저 확인한다
2. 동적 페이지라면 HTML 텍스트만 읽지 말고 JS 번들과 네트워크 호출을 본다
3. 임베디드 JSON이나 공개 API가 있으면 화면 캡처 대신 거기서 구조화된 데이터를 가져온다
4. 페이지네이션(cursor, limit, has_more) 구조를 확인한다
5. 원천 데이터 저장과 선별·추천을 별도 단계로 분리한다
6. 상태가 바뀌는 정보(등록 승인 등)는 최종 결정 직전에 다시 확인한다

5. 한계도 분명하다

과장하지 않기 위해 적어둔다. AI가 Luma에 로그인해서 Register나 Request to Join을 대신 눌러주지는 못했다. 신청·승인 흐름을 에이전트가 안정적으로 처리하는 건 아직 일반 사용자가 안심하고 맡길 수준이 아니다.

그러니까 이 실험의 결론은 "AI가 다 해줬다"가 아니다. 정보 과부하를 줄이고, 내가 결정할 수 있는 형태로 정리해주는 데까지가 현재 지점이다. 그것만으로도 8시간짜리 일이 며칠 저녁 잠깐씩으로 줄었다.

6. 여담 — 월요일 현장에서

이렇게 정한 일정으로 어제 월요일 첫 행사에 갔다. 벨뷰 시청에서 열린 Startup425 행사였는데, 거기서 한국에서 온 42 Network 학생들을 만났다.

42는 강의와 시험 대신 프로젝트와 동료 학습(peer-to-peer)으로 개발자를 키우는 소프트웨어 교육기관이다. 프랑스 파리에서 시작해 지금은 30여 개 나라에 캠퍼스가 있고, 한국에는 42 서울이 있다. 공식 소개에 따르면 세계 최대 규모의 무료 IT 교육 네트워크다.

먼 길 왔으니 많이 배우고 가면 좋겠다.

영상

전체 과정을 7분짜리 영상으로 정리했다.

https://youtu.be/EQ1I0YSfMvM

 

영어 버전: https://youtu.be/OjSXw0_4ihY