1주차 MVP가 두 달 뒤 서버를 고치는 데모로 돌아왔다

2026년 8월 6일 벨뷰 시청에서 Builders Lounge 네 번째 모임을 열었습니다. 네 분의 발표 영상을 모두 공개했고, 이 글은 그 기록입니다.

이번 모임에서 제가 가장 인상 깊었던 건 개별 발표의 완성도가 아니라 한 발표가 두 달 사이에 얼마나 달라졌는가 였습니다. 그 이야기부터 하겠습니다.

6월엔 컨셉이었던 것이 8월엔 돌아가는 시스템이 됐다

손민수 님은 샌프란시스코시에서 일하십니다. 6월 2차 모임 때 "시스템 장애 대응 AI 에이전트"를 들고 오셨는데, 그때는 개발 1주차 MVP였습니다. GateKeeper·Specialist·Judge 세 단계로 장애를 판단한다는 구조만 있었습니다.

두 달 뒤 4차 모임에서 같은 프로젝트가 다시 나왔습니다. 이번엔 이름이 붙었고(Conductor AI), 라이브 데모가 있었습니다. 서버 메모리를 스트레스 테스트로 90%까지 올리자 에이전트들이 서로 대화하며 원인을 찾고, Root Cause로 파이썬 프로세스의 PID까지 특정하고, 복구 방법 세 가지를 후보로 제시했습니다.

이 프로젝트의 출발점이 인상적입니다. 어느 날 새벽 세 시에 관리하던 시스템에 문제가 생겨 관련자를 전부 깨우고 다 같이 붙어서 대응했는데, 나중에 분석해 보니 원인은 로그인 관련 서버의 아주 간단히 처리할 수 있는 이슈였다고 합니다.

"이 정도 문제는 AI가 스스로 분석하고 해결하면 되지 않을까?"

한 가지 짚어둘 것이 있습니다. 이건 퇴근 후 취미로 만드는 사이드 프로젝트가 아닙니다. 업무 중 겪은 문제를 풀기 위해 직원으로서 자발적으로 개발 중인 MVP이고, 실제 도입 여부는 회사가 판단할 몫입니다. 발표 중에도 이 점을 분명히 하셨습니다.

그래서 설계에 흥미로운 제약이 하나 들어가 있습니다. 복구를 실행하기 전에 반드시 사람이 승인해야 합니다. 발표자의 표현을 그대로 옮기면 이렇습니다.

"회사에 쓴다고 하면 절대 AI가 자동으로 고치게는 안 할 걸 제가 알기 때문에"

기술적으로 자동 복구가 가능한데도 승인 단계를 넣은 겁니다. 조직에 제안하려면 필요한 설계라는 판단이었고, 저는 이 대목이 이번 모임 전체에서 가장 실무적인 통찰이었다고 생각합니다.

에이전트를 역할로 쪼갠다는 것

Conductor AI는 에이전트 7개가 역할을 나눠 갖습니다.

• Judge Agent — 메트릭 분석 & 의사결정
• Specialist Agent — SSH로 심층 조사 (ReAct 패턴)
• Flow Agent — E2E 헬스체크
• Remedy Agent — 복구 명령 생성 & 실행
• Airman — 음성으로 시스템 제어
• GitHub Agent — 배포·커밋 히스토리 분석
• NewRelic Agent — APM 메트릭 수집

여기서 ReAct 패턴이 실제로 어떻게 쓰이는지가 잘 드러납니다. Specialist Agent는 미리 정해진 순서로 명령을 실행하는 게 아니라, get_top_cpu_processes() → get_java_heap_info() → get_docker_logs("tomcat") 순으로 스스로 다음에 무엇을 볼지 고르면서 결론에 도달합니다.

비용 설계도 눈여겨볼 만합니다. 상태를 Normal / Warning / Critical로 먼저 분류하고 Normal일 때는 AI를 아예 호출하지 않습니다. 사고는 자주 일어나지 않으므로 대부분의 시간에는 비용이 들지 않습니다. 발표자가 밝힌 예상 월 비용은 $50~100입니다.

"이게 진짜 에이전틱인가"

발표 중반에 이 질문으로 긴 토론이 붙었습니다. 발표자 본인이 동료에게 "네 앱은 에이전틱이 아니라 그냥 오토너머스 툴"이라는 피드백을 받았다고 합니다.

토론에서 나온 구분 기준은 이렇습니다.

에이전틱이 아닌 것은 룰 베이스다. 어떤 조건이면 이것이 Root Cause라고 미리 정해져 있으면 그건 에이전틱이 아닙니다. 반면 로그를 보고 AI가 판단해서 Root Cause를 내고, 그 Root Cause를 근거로 해결책까지 제시하면 그건 에이전틱한 접근입니다.

더 실용적인 기준도 나왔습니다. 앱이 돌아가는 동안 LLM을 한 번이라도 호출하는가. 코드 에이전트로 만들었더라도 실행 중에 LLM 콜이 한 번도 없으면 그냥 자동화 프로그램입니다.

파이썬으로는 안 되더라 — Go로 바꾼 이유

발표 막바지에 나온 이야기인데, 저는 이게 이 발표에서 가장 실무적인 정보라고 봅니다.

처음엔 파이썬으로 만들었다가 Go로 다시 썼다고 합니다. 이유는 이렇습니다.

"이 에이전트 수가 100개 아니 30개만 넘어가도 파이썬의 싱글 스레드 제한이 있거든요. 아무리 비동기를 해도 하나씩 처리하는 파이썬의 아주 고질적인 단점입니다."

Go로 옮긴 뒤에는 인텔 코어 노트북 한 대에서 수십 개 네임스페이스의 파드를 감시하며 수십 개 에이전트를 동시에 돌리고 있다고 합니다. goroutine이 이런 용도에는 따라갈 게 없다는 이야기였습니다.

여기서 파생된 지적도 좋았습니다. 우리는 "에이전트"라고 하면 LLM을 떠올리는데, PC 안에서 실제로 돌아가는 건 전부 CPU 프로세스입니다. AI 시대에 CPU가 다시 중요해지는 이유가 여기 있습니다.

나머지 세 발표

목사님이 바이브 코딩에 빠져서 만든 앱 — 김성수

재외 한인 정착 커뮤니티 플랫폼 HebronGuide. 목사님이 직접 만드셨고 현재 86개 도시에서 쓰이고 있습니다. 비개발자가 AI로 실제 사용자를 가진 제품을 만든 사례입니다.

이 앱의 기본 정신은 환대입니다. 최근 크리스토퍼 놀란 감독의 「오딧세이」가 주요 화두로 삼은 것도 바로 이 환대였는데, 김성수 목사님이 앱을 만든 출발점이 정확히 같은 자리에 있습니다.

발표에서 직접 밝히신 계기가 있습니다. 낯선 땅에 도착했을 때 "내가 여기 아는 사람이 하나도 없다, 나를 안내할 사람이 하나도 없다" 는 벽을 겪으셨고, 그때 어떤 분이 아무 대가 없이 아파트 열쇠를 건네줬다고 합니다.

"그만큼 환대의 힘이라고 하는 게 굉장히 파워가 있다는 거예요. 사람은 교리보다 자신을 따뜻하게 맞이해주는 그 손길에 더 마음이 열리는 거예요."

개발자가 제품을 만들 때 사람들의 중요한 필요를 채우는 데서 시작한다면, 사람에게 가장 필요한 것이 무엇이냐 — 목사님의 답이 환대였습니다.

Bila AI Agent 개발 업데이트 — 강민석

스타트업 창업자인 강민석 님이 만드는, 커뮤니티가 남긴 모든 기록을 읽고 답하는 에이전트. 이번 모임에서 모바일 앱 출시 소식까지 나왔습니다.

제가 만든 AI가 "왜 규칙을 어겼냐"고 따집니다 — 이도규

회사에 다니면서 만든 개인용 퀀트 투자 에이전트. 메일과 뉴스레터에서 종목 정보를 모아 매수·매도 신호를 분석하고 매일 스케줄로 돌아갑니다. 데모에서 본인이 정한 "실적 발표 전 매수 금지" 규칙을 어기자 에이전트가 되받아치는 장면이 나옵니다.

영상

전부 한국어 진행입니다. 영어 자막은 1~3편이 하드섭(화면에 구움)이고, 4편은 자막 트랙이라 재생기의 CC 버튼으로 한국어·영어를 선택할 수 있습니다. 각 영상에 챕터를 넣어 뒀습니다.

https://youtu.be/vXPCbt47rok

https://youtu.be/5nlVyb6HBR0

https://youtu.be/dsl7CZCCAh4

https://youtu.be/e9iMkxUGXfM

마치며

Builders Lounge는 무언가를 만드는 사람들이 각자 만든 것을 들고 와서 서로의 첫 사용자가 되는 모임입니다. 지역에 상관없이 누구나 참여하실 수 있습니다.

만든 분들께 전하고 싶은 말씀이 있으시면 커뮤니티에 남겨 주세요. 직접 닿습니다.

창발 스페이스 — https://gobispace.com/spaces/changbal

다음 모임에서는 손민수 님이 멀티 에이전트를 어떻게 구현했는지 메인 스피커로 20분 정도 다루기로 했습니다. 그 이야기도 정리해서 올리겠습니다.

https://youtu.be/U0L2oyE6Ph4

이름은 들어봤는데, 정확히 뭐 하는 사람인지는 모르겠다

Forward Deployed Engineer. 미국 AI 기업 채용 공고에서 부쩍 자주 보이는 직함이다. Anthropic은 $280K–$320K, OpenAI 시애틀은 $162K–$280K에 주식까지 걸고 뽑는다. 그런데 이 직무가 정확히 무엇을 하는 자리인지 설명한 한국어 자료가 거의 없다.

찾다 지쳐서 직접 정리했다. 채용 공고 10건을 1차 출처로 놓고, Palantir의 원형부터 2026년 8월 기준 채용 동향까지 42개 문서로 만든 뒤 28분짜리 영상으로 압축했다. 이 글은 그 과정에서 정리된 것 중 핵심만 뽑은 것이다.

한 문장 정의와, 뒤따르는 오해 세 가지

FDE는 고객 가까이에 배치되어, 자사 기술이 고객의 실제 업무 안에서 돌아가게 만드는 엔지니어다.

이 정의에서 자주 어긋나는 오해가 셋 있다.

첫째, "고객사에 파견 나간 개발자"가 아니다. 파견은 인력을 보내는 것이고, FDE는 결과(outcome)를 책임지는 것이다. Palantir가 만든 원형이 정확히 이 지점이었다.

둘째, "영업 지원 엔지니어"가 아니다. Sales Engineer는 계약 전까지가 책임 범위지만, FDE는 계약 후 운영에 올라갈 때까지가 범위다.

셋째, "컨설턴트"가 아니다. 문서를 남기고 나오는 게 아니라 코드를 짜고 배포한다.

왜 지금 다시 필요해졌나 — 데모와 운영 사이의 간극

LLM 데모는 하루면 만든다. 문제는 그걸 실제 기업 업무에 넣는 순간이다. 데이터 권한, 보안, 평가, 비용, 지연시간, 통합, 거버넌스가 한꺼번에 터진다.

이게 FDE가 다시 호출된 이유다. 범용 AI가 강력해질수록 "우리 회사 상황에서 이게 실제로 돌아가게 만드는 일"의 난이도는 오히려 올라간다. 모델이 좋아진다고 이 간극이 저절로 메워지지 않는다.

같은 이름, 여섯 가지 다른 직무

여기가 이 조사에서 가장 실용적인 부분이었다. FDE는 하나의 직무가 아니다. 채용 공고를 모아 보면 최소 여섯 가지 유형으로 갈린다.

• AI Lab형 (OpenAI, Anthropic) — 프론티어 모델을 고객 업무에 적용. 프로토타이핑 속도와 고객 접점 능력을 함께 본다
• Developer Workflow형 (Cursor) — 개발자가 고객이다. 제품 감각과 개발 생산성 이해가 핵심
• Infrastructure형 (Scale AI) — 데이터·평가 파이프라인 구축이 중심
• Vertical형 (Hebbia 등) — 금융·법률 등 특정 도메인 지식이 진입 장벽
• Government형 (OpenAI Gov, Palantir) — 보안 인가와 규제 대응이 전제
• Classic FDSE형 (Palantir) — 원형에 가장 가까운, 배포까지 전 과정 소유

같은 FDE 타이틀에 지원하면서 준비를 똑같이 하면 안 된다는 뜻이다. 유형별로 요구하는 것이 다르다.

공고 읽는 법 — 직함이 아니라 동사를 봐라

Applied AI Engineer라는 같은 직함이 회사에 따라 완전히 다른 일을 가리킨다. 직함으로는 구분이 안 된다.

대신 공고 본문의 동사를 보면 갈린다.

• deploy, integrate, onboard, own the outcome → FDE 성격
• scope, demo, pre-sales → Sales Engineer 성격
• train, fine-tune, benchmark → ML Engineer 성격
• design, ship, iterate on the product → Product Engineer 성격

한 줄만 읽어도 유형이 판별되는 경우가 많다.

기술 스택은 넓게, 깊이는 목표 유형에 맞춰

FDE 기술 스택은 8개 영역으로 정리된다. LLM/RAG/Agent, 평가(Evals), 관측(Observability), 보안·권한, 데이터 파이프라인, 통합(API·MCP), 배포·인프라, 제품 감각.

전 영역을 깊게 할 필요는 없다. 영역마다 Literacy(알고는 있다) / Working(직접 만든다) / Production(운영에 올린다) 세 단계로 나누고, 목표 유형에 필요한 것만 Production까지 끌어올리는 편이 현실적이다.

특히 Evals는 선택이 아니다. 데모와 운영을 가르는 것이 바로 평가 체계이고, FDE가 존재하는 이유의 절반이 여기 있다.

배경별로 준비 경로가 다르다

이 영상을 만든 진짜 이유다. "지금 내 위치에서 뭘 해야 하나"에 대한 답이 배경마다 완전히 다르다.

주니어 — 직함을 노리기 전에 증거를 만든다. 6개월 목표는 "FDE로 취업"이 아니라 "FDE 모양의 증거"다.

IT 시니어 — 새로 배우기 전에 다시 쓴다. 첫 질문은 "무엇을 배울까"가 아니라 "내 경력에서 이미 FDE 일이었던 것이 무엇인가"다. 고객 요구사항을 받아 시스템에 반영하고 운영까지 책임진 경험이 있다면, 그건 이미 FDE 업무다. 표현이 안 되어 있을 뿐이다.

비IT — 직행보다 우회가 확률이 높다. FDE로 바로 가는 것이 불가능하진 않지만 예외적이다. 인접 직무에서 증거를 쌓고 넘어가는 경로가 훨씬 자주 작동한다.

자료는 전부 공개했다

조사 문서 42개(한국어 + English)를 GitHub에 공개했다. 영상에 담기 어려운 실습 자료가 여기 있다.

• 내게 맞는 FDE 유형을 고르는 자가진단 질문지
• Production Readiness 체크리스트 (Evals / Security / Observability)
• 배경 10종별 이력서 Before → After
• 포트폴리오 프로젝트 3종 상세 설계서
• 면접 루프 단계별 예상 질문 25개

FDE 학습 자료 (GitHub)

영상 안에서도 각 파트가 시작될 때 해당 모듈로 연결되는 QR 코드가 뜬다.

영어 버전 영상도 있다. Forward Deployed Engineer — English version

마지막으로

채용 공고와 보상 범위는 수시로 바뀐다. 이 글과 영상의 수치는 2026년 8월 16일 기준 공개 페이지 스냅샷이다. 실제 지원 전에는 반드시 원문을 다시 확인하기 바란다. 이 자료는 학습·참고용이며 특정 회사의 채용을 보장하거나 대변하지 않는다.

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 해결 방식

중요한 건 어느 모델이 더 똑똑하냐가 아니다. 문제를 어떤 레벨로 정의했는가가 결과를 갈랐다. "이 페이지의 행사들을 정리해줘"는 사람에게는 자연스러운 요청이지만, 에이전트에게는 동적 렌더링·숨겨진 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