모든 시스템은 결국 자신의 병목에 부딪힌다.
때로는 환경,
때로는 나 자신으로부터.
그래서 나는
더 빨리 일하려는 것을 멈췄다.
대신 시스템을 다시 설계했다.
내가 필요한 순간이 '예외'뿐인 시스템으로.
사이트마다 담당 에이전트를 두고, 그 위에서 마스터와 함께 13개 사이트 전체를 관장하는 실제 운영 화면이다.
미완의 UI가 나름의 재미를 준다.
이 공간은 한 장의 이력서에 담기지 않았던 이야기들이다.
성장 과정, 결과에 대한 이야기보단 좀 더 개인적인 것들.
그리고 나만의 프로덕트를 만들어 가기까지의 여정에 대한 기록이다.
1장 · 본업
엔터프라이즈에서의 7년.
신입 때 나는, 쓸모 있는 사람이 되는 가장 빠른 길이 “전부 다 해보는 것”이라고 판단했다. 매장 전시, 회원, CS, 주문부터 이벤트, 쿠폰 발행 대상 추출, 리텐션 타겟 설정, CRM 도구 관리, CI/CD 구축까지, 남들이 되도록 피하고 싶어 하는 일들이 내겐 성장의 발판이었다.
부족한 부분은 경험으로 채울 수 있다고 믿었고, 아무도 선뜻 맡지 않는 일에 재미있는 문제가 숨어 있다고 생각했다. 그 어려움 자체가 핵심이었고, 그 어려움을 해결해나가며 얻는 만족감도 그랬다.
- 어디서
- 현대백화점그룹.
- 그리팅
- B2C 사이트 그리팅을 오픈 초기부터 만들며 전시·상품·이벤트·프로모션을 처음부터 끝까지 맡았고, 주문·회원·CS·인프라까지 함께 다뤘다. 한 사람이 감당하기엔 넓은 범위였지만, 내가 원하던 넓이였다.
- 배포 설계
- 배포 경로를 직접 설계했다. 소스 관리는 SVN, 배포는 서버에 jar를 직접 풀어 넣는 수동 방식이던 것을 Jenkins로, 다시 Bitbucket과 Bamboo로 옮겼다. 배포 셸 스크립트를 직접 작성하고 인프라 구조 분석을 리딩했다.
- Papia
- 사내 AI 러닝크루를 이끌며 에이전틱 코딩을 실무에 들여왔다. 첫 성과는 네이버에서 우리 사이트의 커뮤니티 반응이 튀는 순간을 수집해 Teams로 알림을 보내는 바이럴 트래커였다.
- 지금
- 2025년 11월부터 더현대 이커머스팀에서 해외 브랜드 5곳(COS, ARKET, & Other Stories, TOTEME, NANUSHKA)과 NCP 샵인샵 5곳을 맡고 있다. Akamai, React, Next.js, Tomcat, Oracle.
2장
유용했던 결과물이 왜 프로덕션에 닿지 못했을까?
신입이 만든, 잘 작동하던 모델. 그리고 그걸 끝내 배포하지 못하게 막은 온프레미스 런타임.
입사 1년차. 아무도 체계적으로 읽지 않던 리뷰 데이터가 쌓여 있었고, 나는 그걸 읽기 시작했다.
그걸 이해하려고 감성분석 모델을 만들었다. 로지스틱 회귀, 화려할 것 없는 방법으로. 모든 리뷰를 긍·부정과 카테고리로 분류했고, 그 결과를 두고 현업 미팅을 직접 리딩했다.
반응은 열광적이었다. AI가 상용화되지 않았던 시절, 현업이 2~3일을 쓰던 리뷰 분류 작업이 30분으로 줄었다. 완벽히 작동했다. 하지만 배포되지 못했다. 온프레미스 서버의 파이썬 버전이 모델이 요구하는 버전과 맞지 않았고, 운영 안정성을 이유로 버전업은 허락되지 않았다. 결과를 결정짓는 마지막 한 가지, 인프라 환경만은 신입이 통제할 수 없었다.
마지막 한 조각을 앞두고 멈춰 선 파이프라인
쓸모 있는 것을 만들면 끝인 줄 알았다.
하지만 나를 둘러싼 환경까지도 내가 통제해야 할 결과의 영역이었다.
그 미완의 파이프라인이 이후 6년의 방향을 정했다.
이야기 나누고 싶은 질문들
3장
노력만으로는 뚫리지 않는 것도 있다.
노력만으로는 뚫리지 않던 다섯 번의 애드센스 낙방, 하루 1달러에 멈춘 블로그 넷, 그리고 끝내 나를 통과시킨 깨달음: 정답은 없어도, 정도(正道)는 있다.
3년차, 이커머스 업무가 훤히 보이기 시작했다.
온전한 나의 것이 가지고 싶어졌다.
그 첫 시작은 블로그. 하루 10시간, 매일 20개가 넘는 포스팅을 썼다.
하지만 6개월간 그 노력의 결과는 다섯 번의 애드센스 승인 거절이었다.
노력은 잘못이 없었다. 방향이 성장의 병목이었다.
그래서 기술을 적용했다. 나의 티스토리 블로그에 SEO를 독학하고 적용하며, GA와 Clarity를 익혀, 추측 대신 측정했다.
여기에 정답은 없지만 정도(正道)는 있고, 그 “정도”는 데이터에서 찾았다.
결국 구조를 바꾸자, 애드센스의 문이 열렸다.
기나긴 6개월의 MVP가 검증되자, 다음 스텝은 확장이었다. 블로그가 넷이 되었다. 트래픽도 상승하고 수익도 증가했다.
하지만 다음 문제는 하루 1달러라는 작은 수익이었다.
월 40달러 남짓에서 서서히 식었다.
내가 소유하지 않은 플랫폼 위에 있는 한, 비효율의 천장이었다.
이번엔 노력의 범위를 티스토리라는 플랫폼에서 유튜브로 확장했다. 블로그에서 배운 시장 분석 능력과 키워드 캐치, SEO 적용 경험은 유튜브라는 다른 환경에서도 그대로 적용되었다. 미국 시청자를 겨냥해 세팅한 유튜브 채널이 3달 만에 구독자 1만 명에 닿았다. 올바른 방향으로의 노력이 증명된 것이다. 하지만 그 후, 나는 티스토리와 유튜브 활동을 모두 중단했다.
본질을 놓치고 있었다. 결국 나의 노력이 플랫폼에 종속되어 있다는 사실을 깨달았기 때문이다. 그러던 중 내가 소유하지 않은 플랫폼, 티스토리가 나의 고단가 롱테일 포스트들을 예고 없이 삭제했다.
그 사건은, 오래가야 할 것은 온전한 나의 것으로 소유하여야 한다는 확신을 줬다.
드디어 나만의 사이트를 구축하기 시작했다. 나만의 호스팅, 나만의 도메인 서버, 나만의 DB. 티스토리의 모든 자산을 내 인프라로 옮겼다. canonical을 설정하고 301을 유지하며, 그 과정에서 색인이 풀리는 사고를 감수했다.
결과는 압도적인 성과로 돌아왔다.
2026년 3월 시작한 나만의 사이트는 지금 총 13개, 3개월 만에 월 누적 10만 명의 유입과 월 500달러의 수익을 만들어냈다.
온전한 나의 것을 가지려 한 첫 시도로부터, 비로소 병목을 해소할 “정도”를 찾은 것이다.
그 종속에서 벗어나,
자체 인프라와 SEO라는 정도(正道)의 노력이 들어가자
진짜 성장이 시작되었다.
정도(正道)가 통하기 시작했을 때 데이터가 보여준 모습이다.
이야기 나누고 싶은 질문들
4장 · 지금 운영하는 것들
실제 트래픽 위에서 돌아가는 13개의 실험.
이것은 13개의 웹사이트가 아니다. 하나하나가 내가 답을 원했던 질문이고, 의도적으로 고른 렌더링 트레이드오프이며, 다른 방법으로는 배울 수 없던 교훈이다.
5장 · A Company of One
인간은 AI 시스템을 어떻게 운영해야 하는가?
그 질문에 답하려 만든 시스템, 그 안에 담긴 트레이드오프와 실패들, 그리고 이 규모에서는 왜 결국 아키텍처만이 확장되는가.
사이트가 10개를 넘어가자, 콘텐츠 생성은 더 이상 병목이 아니라는 걸 깨달았다. 병목은 내 주의력이었다.
시스템
답은 나 없이도 돌아가는 시스템이었다. 마스터 하나에 사이트마다 워커 하나. 각 사이트의 에이전트가 일감을 받아 실행하고 다시 보고한다. 하루에 약 100개의 포스트가 그 사이를 지나가고, 나는 일상 운영에서는 완전히 빠져 있다.
왜 방아쇠는 여전히 내가 당기는가
정확히는, 거의 빠져 있다. 처음엔 나를 완전히 빼려 했다. tmux 루프가 3분마다 inbox를 확인해 마스터가 쌓아 둔 것을 실행했다. 잘 돌아가는가 싶더니, 계속 새로 뜨는 AI 세션이 메모리를 잡아먹었고 결국 머신이 OOM으로 내려앉았다. 그래서 구조를 바꿨다. 일상 업무는 여전히 쌓이되, 내가 실행 명령을 한 줄 직접 내리기 전까지는 아무것도 돌지 않는다. 완전 자동화는 매력적이고 운영의 대부분은 자동화돼 있지만, 무엇을 바꿀지 그리고 그 변경이 할 가치가 있는지에 대한 판단만큼은 내가 쥔다. 그 검토는 시스템이 아니라 운영자의 몫이다.
프로토콜
에이전트들이 서로 소통하는 방식은, 최신 오케스트레이션 프레임워크를 건너뛰고 제1원리에서 출발했다. 조율은 메일박스와 파일시스템으로, 1970년대 메일 시스템에서 빌려왔다.
나는 처음부터 끝까지 추론할 수 있는 구조를 원했고, 그것을 제1원리에서부터 만들어 가는 데에는 분명한 만족이 있었다.
하네스
텍스트를 생성하는 에이전트는 내버려 두면 흔들린다. 그래서 품질은 컨텍스트 예산으로 붙잡는다. 기본 스펙은 200줄 아래로 유지하고, 포스팅은 전용 스펙을 따로 두며, 색인은 IndexNow에 넘긴다. 결과물이 흩어지지 않게 잡아주는 건 이 제약이다.
양은 자랑이 아니라 리스크다
그리고 그게 가장 중요한 곳이 바로 “양”이다. 하루 100개의 초안은 쉬운 부분이자 위험한 부분이다. 양만으로는 아무것도 발행되지 않는다. 모든 초안은 실제 검색 의도에 대응해야 하고, 품질 기준을 통과해야 하며, 검색엔진이 스팸으로 감점하는 바로 그 신호들(얇은 콘텐츠, 템플릿 같은 문장, 중복 구조)에 대한 검증 레이어를 거쳐야 한다. 이걸 놓치는 순간 콘텐츠 시스템은 스팸 네트워크가 된다. 그래서 엔지니어링의 대부분은 더 많이 찍어내는 데가 아니라 바로 여기에 있다.
여기엔 별개의 시스템이 없다
이 중 어느 것도 따로 떨어져 있지 않다. 검색, 콘텐츠, 렌더링, 색인, 수익은 별개의 관심사가 아니다. 하나의 선이며, 13개 자산을 아우르는 first-party 애널리틱스가 그 전체를 한 번에 보게 해준다.
렌더링 선택은 광고 수익을 움직인다. 색인 결정은 트래픽을 움직인다. 캐싱 주기는 그 둘을 동시에 움직인다. 한 고리만 따로 조율할 수는 없기에, 이걸 운영하는 유일한 방법은 사슬 전체를 머릿속에 담는 것이다.
먼저, 트래픽은 어디서 오는가
거의 모두가 무언가를 구체적으로 검색해서 들어온다. 의도를 갖고 왔고, 이 사이트가 그 의도에 답했다.
그다음, 그것이 검증한 것
월 기준
How I Debug · 실제 사건, 처음부터 끝까지 추적
어느날 가장 큰 사이트의 RPM이 하룻밤 사이에 $8에서 $4로 떨어졌다. 배포된 것은 없었다. 내가 어떤 순서로 어디를 봤고, 각 단계가 무엇을 걸러냈는지 그대로 담았다.
애널리틱스
트래픽은 정상. 세션도 지역도 그대로였다. 움직인 건 RPM뿐. 문제는 몇 명이 왔느냐가 아니라, 방문 하나의 가치였다.
광고 스택, 그다음 변경 이력
노출은 여전히 나갔으니 하락은 물량이 아니라 노출당 단가였다. 그날 배포는 없었지만, 직전에 렌더링 변경이 있었다. ISR에서 SSG로, revalidate는 7일.
가설
광고 컨텍스트의 신선도가 입찰가를 정한다. 7일 얼어붙은 페이지는 일주일 묵은 컨텍스트를 내밀고, 경매는 지금 읽을 수 있는 것을 기준으로 값을 매긴다. 렌더링이 조용히 수익 변수가 되어 있었다.
revalidate를 1~4시간으로 되돌리자, RPM은 즉시 회복됐다.
원인을 찾기까지 일주일, 그동안 누적 손실은 약 $25~30.
고치는 데는 몇 분, 찾는 데는 일주일이 걸렸다. 그 일주일 때문에, 나는 이제 어떤 기술 변경이든 그 다음 날 RPM을 확인한다.
렌더링에는 청구서가 따른다
RPM 사고는 렌더링이 수익 변수임을 가르쳐 줬다. 그걸 Vercel 위에서 운영하니, 렌더링이 비용 변수이기도 하다는 걸 알게 됐다. ISR은 트래픽에 따라 늘어나는 서버리스 호출과 사용료를 뜻했고, 13개 사이트에 걸쳐 그 청구서는 매출보다 빠르게 불어났다.
그래서 프리빌트 방식으로 옮겼다. 모든 사이트를 로컬에서 직접 빌드해 정적 결과물만 올려, 온디맨드 렌더링을 비용 통제와 맞바꿨다. 그 선택은 또 다른 방식으로 무너졌다. 수천 페이지짜리 사이트 열세 개를 한 대에서 빌드하니 메모리가 한계를 넘었고, 빌드가 OOM으로 죽기 시작했다.
모든 선택지가 트레이드오프였다. ISR은 편했지만 비쌌고 광고 컨텍스트를 묵히게 했다. 순수 SSG는 싸고 신선했지만 빌드가 무거웠다. SSR은 유연했지만 요청당 느리고 비쌌다. 그래서 하나만 고르길 멈췄다. 이제 각 사이트는 자기 트래픽과 신선도에 맞춰 SSG·SSR·ISR을 쓰고, revalidation은 자산별로 조정한다. 시스템은 지금 그 균형점에 있고, 나는 청구서와 RPM을 함께 지켜보며 그 선을 유지한다. 그 실패들이 곧 그 선을 찾은 방법이었다.
병목은 계속 옮겨간다
병목은 사라지지 않는다. 풀면 다른 곳으로 옮겨갈 뿐이다. 2020년엔 손댈 수 없는 환경이었다. 규모가 커지자 병목은 콘텐츠가 됐고, 그래서 콘텐츠 생성을 자동화했다. 콘텐츠가 거의 공짜가 되자, 병목은 내 주의력이 됐다.
이 모든 이동의 답은 늘 같았고, 한 번도 “더 열심히”가 아니었다. 제약이 내가 실제로 옮길 수 있는 자리에 오도록 시스템을 다시 설계하는 것이었다. AI를 운영하는 규모에서는 그 설계가 남은 유일한 지렛대다. 하루에 100개의 초안을 찍어내는 시스템은 노력으로 이길 수 없다. 오직 설계로만 이길 수 있다.
내가 아키텍처에 마음을 쓰는 이유, 그리고 모든 트레이드오프를 이해하겠다고 고집하는 이유가 이것이다. 시스템 전체를 보는 것만이, 다음 병목이 나를 찾기 전에 내가 먼저 찾아 의도적으로 옮기게 해준다.
2020년의 그 파이프라인은 내가 통제하지 못한 환경에서 멈췄다.
그다음 제약은 내가 소유하지 않은 플랫폼이었다.
내 최고의 페이지를 지워 버릴 수 있는 호스트,
그리고 매출을 넘어 불어날 수 있는 청구서.
그 병목들을 옮겨 온 6년 뒤,
나는 이제 그 환경 전체를 설계로 통제한다.
그리고 배포되지 못했던 그 단계는 이제 제한 없이 배포된다.
파이프라인이 마침내 닫힌다.
2020년에 멈춰 있던 그 조각이 마침내 끼워졌다
시스템을 들여다보는 두 개의 창
손댈 수 없던 파이썬 런타임, 6개월간의 애드센스 낙방, 하루 1달러에서 멈춘 수익, 내 최고 포스트를 삭제한 플랫폼, 그리고 일주일치 수익을 날린 캐싱 변경.
이 다섯 가지 중 무엇도 진짜 문제가 아니었다. 하나같이 증상일 뿐이었다.
진짜 문제는 매번 같았다. 부분은 봤지만, 그 부분들이 속한 시스템 전체는 보지 못했었다.
6장 · 원칙
7년의 병목 풀이가 내게 남긴 다섯 문장.
- 추상화하기 전에 이해하라.그 아래에서 어떻게 작동하는지 설명할 수 있기 전까지, 나는 어떤 것도 프레임워크로 덮지 않는다.메일박스에서
- 신뢰하기 전에 측정하라.사람들이 무엇을 원하는지에 대한 내 직감은 충분히 자주 틀렸다. 그래서 이제는 먼저 데이터로 확인한다.6개월의 실패에서
- 오래가야 할 것은 직접 소유하라.오래가야 할 것은 내가 통제하는 인프라 위에서 돌린다. 내가 소유하지 않은 플랫폼은 하룻밤 사이에 그걸 지워 버릴 수 있으니까.포스트를 지운 플랫폼에서
- 병목과 싸우지 말고, 옮겨라.무언가가 제약이 되면, 그것과 더 힘겹게 싸우는 대신 그것이 더 이상 제약이 아니도록 시스템을 다시 설계한다.주의력에서 오케스트레이션으로에서
- 필요가 진짜일 때, 위에서 아래로 배워라.진짜 문제가 그것을 필요로 하는 바로 그 순간에 깊이 배운다. 그 전이 아니라. 그리고 그 필요가 배움을 몸에 남긴다.일기에서
나는 매일 무언가를 쓴다. 오늘 무엇을 했는지가 아니라, 지금 이 순간 보고 있는 것을. 한 줄이어도 된다. 이걸 몇 년쯤 하다 보면 알게 된다. 무언가를 적으려면 먼저 무엇이 중요한지를 정해야 하고, 무엇이 중요한지를 정하려면 전체를 봐야 한다는 것을. 이 지면의 모든 글들도, 10년간 적어 온 내 일기 속 사고의 흐름에서 비롯되었다.
일의 본질을 알면 기술은 쉽게 습득된다.
나는 기술을 수집하지 않는다. 나는 과정을 수집한다.
왜 OpenAI인가, 왜 FDE인가
OpenAI의 FDE 공고를 처음 읽었을 때, 인생에서 가장 큰 설렘을 느꼈다.
지난 7년간 내가 해 온 모든 것 — 문제를 현업과의 커뮤니케이션으로 함께 정의하고, 병목을 찾고, 시스템을 다시 설계하고, 내 손으로 직접 AI를 운영해 온 과정.
그 과정은 이 한 자리를 향해 있었다.
지금까지 채워지지 않던 그 한 조각을 찾은 기분이었다.
나는 AI로 세상에 실질적인 편의를 만들어 내는 미션을 수행하고 싶다.
고객의 진짜 문제 앞에 직접 서서, 모델을 실제로 작동하는 제품으로 만들어 내는 일.
그것이 내가 가장 잘할 수 있는 일이기 때문이다.
이 기록이 OpenAI의 FDE 직무에 부합하는 사람으로 읽히길 바라며,
여기까지 읽어준 그대에게 깊은 감사를 표한다.
더 많은 이야기를 남겨두며.
Lee Seung Hwan