[Wavebridge X AI] EP1. AI로 매일 아침 발송되는 뉴스레터, LEX의 원리

[Wavebridge X AI] EP1. AI로 매일 아침 발송되는 뉴스레터, LEX의 원리

Episode 1. AI로 매일 아침 발송되는 뉴스레터, LEX의 원리

편집자의 말: 웨이브릿지는 매일 아침 8시 30분, 사람의 손으로 만든 뉴스레터를 3년간 보내왔습니다. 그러다 올해 10월, 이 뉴스레터는 AI를 통해 자동화되며  ‘렉스(LEX)’라는 이름으로 새롭게 탄생했습니다. AI가 업무 현장을 바꾼다는 말이 먼 미래의 이야기가 아님을 체감한 순간이었습니다. 웨이브릿지는 이제 AI로 일하는 방식을 배워가고 있습니다. 그 진화의 순간들을 기록하고자 합니다. 첫 번째 기록은, LEX의 탄생으로 시작합니다.

레베카 (인터뷰 및 제작⬝편집) × 에릭(개발/프로젝트 리드)

레베카 : 에릭, 안녕하세요. 오늘 이 자리 인터뷰를 흔쾌히 응해주셔서 감사해요. 말씀드렸듯이, ‘LEX’를 직접 만드시고, 웨이브릿지에 AI DNA를 앞으로 심어주실 분이셔서 이 자리로 모셨어요.

에릭 : 이런 자리를 마련해주셔서 감사해요. 

레베카 : 우선 웨이브릿지 뉴스레터는 구독자들만 아실테니, 간단히 소개부터 부탁드려요.

에릭 : 웨이브릿지는 매일 아침, 디지털자산 관련 투자자들이 알아야 할만한 간밤 일어난 뉴스들을 요약 정리하고 인사이트를 공유하는 구독형 뉴스레터였어요. 3년간 웨이브릿지 팀이 조기 출근해서 만들어 왔었어요. 출근 전에 보실 수 있도록 해야 하니까요.

레베카 : 그러다 올해 10월에 LEX 라는 이름으로 개편했어요. 그러면서 이 LEX는 에릭이 직접 AI 툴을 이용해 개발하셨다고요. 그 원리부터 설명해주시겠어요?

에릭 : LEX는 단순한 자동 발송 툴이라기보다, 웨이브릿지 뉴스레터의 큐레이션 역할을 맡은 시스템에 가깝습니다.

기존에는 사람이 매일 아침 간밤 뉴스를 스크리핑하고, 걸러내고, 요약하고, 인사이트까지 얹는 형태였죠. 그런데 이건 반복 노동이 많고, 담당자가 바뀌면 지속이 어려웠거든요. 이 운영방식을 개선하는 과정에서 대표님께서 저에게 “AI로 되겠냐”고 여쭤보셨어요. 저도 이 뉴스레터의 팬 중 한명이었어서, 만일 뉴스레터 발간이 중단된다면 아쉬울 거라는 생각이 있었고요. 동시에 'AI 애플리케이션을 통해 어느 정도의 퀄리티가 나올 수 있을까?'가 궁금했습니다. 그래서 제안을 받자마자 든 생각은, '재밌겠다. 한 번 해보자.' 였죠. 평소 업무 외 시간에도 기술 트렌드를 꾸준히 공부하고 따라가려고 노력하거든요. 요즘은 AI로 개발할 수 있는 서비스와 프로덕트에 대한 논의가 가장 활발하고, 저도 공부하고 배울겸 이 프로젝트를 잘 해봐야겠다는 생각이었어요.

레베카 : AI로 대체하면 일이 줄어들 것 같은데, 막상 해보니 생각보다 복잡했다고요?

에릭 : 처음엔 저도 ‘AI로 개발을 대체하면 일이 줄어들겠지’라고 생각했어요. 그런데 만들어보니, 사람이 하던 일을 AI로 바꾸는 순간 일이 줄어든다는 개념 보다는, AI와 소통할 규칙을 만들어야 한다는 개념이 더 와닿았어요.

사람은 우리가 생각하는 것보다 여러 층위의 정보를 한번에 압축해서 판단합니다. 예를 들어 우리는 보도자료 하나로 여러 언론사에서 조금씩 다르게 쓴 걸 보면, 하나의 기사라고 바로 판단 내리잖아요.

그런데 AI는 코드고 규칙이니, ‘유사 기사’ 판별 기준을 명시적으로 사전에 만들어 놔야 해요. AI가 기사 수집을 600건씩 해오면 그 안에서 유사한 걸 솎아내는 게 핵심인데, 그게 자동으로 되지 않더라고요.

그냥 수집만 하면 부동산 뉴스, 광고성 뉴스, 가격 기사가 끼어듭니다. 특히 양적으로 많거나 클릭이 많은 기사를 솎아내라고 하면서 그대로 두면 뉴스레터가 아니라 ‘가격 추적기’가 됩니다.

그래서 결국 해야 했던 건 요약이 아니라 큐레이션 방식을 만드는 거였어요.

  • 동일/유사 기사 판별
  • 광고성·비관련 기사 제거
  • 카테고리 설계 및 비중 조정
  • 매체별 소스 비중 조절

이런 것들을 사람은 머릿속에 규칙을 써둔 게 아니라 감각적으로 자연스럽게 해왔던 거죠. 그런데 서비스화, 자동화로 넘어가는 순간 그 감각을 룰로 번역해야 했습니다. 이 과정이 가장 복잡했어요.

레베카 : LEX는 결국 'AI가 콘텐츠를 읽고 판단하는' 큐레이션 방식으로 볼 수 있는 건가요?

에릭 : 네 그렇죠. 기사 자체를 수집하고, 내용을 읽고 판단해서 선정합니다. AI가 실제로 읽는 거죠. 그런데 여기서 중요한 건 'AI가 알아서'가 아니라 사람이 기준을 지정해줘야 한다는 점입니다. 예를 들어 '비슷한 내용의 기사들이 있을 때 어떤 매체를 기준으로 하느냐' 같은 것도 사람이면 감각으로 결정하지만, AI는 기준이 없으면 제멋대로예요. 그래서 저는 기본적으로는 최신 기사로 연결하라는 원칙을 줬습니다.

레베카 : 뉴스레터에 담을 기사 ‘개수’나 ‘선정 방식’도 기준을 정해두셨다고요. 뭐가 중요한지 판단해서 뉴스레터에 올릴 것인가 말 것인가를 판별하는 게 사실 그때그때 다르잖아요.

에릭 : 맞아요. 그 판단을 사람은 바로바로 하는데, AI의 경우 임의로 하라고 두면 안되고, 정해줘야 해요. 섹션 별로 범위를 정해뒀고, 그 안에서 점수화해서 점수가 높은 것들 중 정한 개수가 들어가게끔 만들었어요. 미국 시장과 글로벌 매크로는 2~5개 사이, 디지털 자산 관련은 20~30개 (다만 내부에서 다시 세부 카테고리로 분해)로요.

그리고 해당 개수 안에서 기사를 선정하는 기준은 단순히 '많이 있느냐'에 있지만은 않아요. 글로벌 영향도, 시장 임팩트 같은 기준으로 점수를 부여해서 정렬합니다. 대략 10단계로 점수를 나누고(구간화), 그걸로 sorting하는 방식이죠.

여기서 중요한 게 나오는데요. 이 과정을 하면서 제가 배운 건 이겁니다. 저는 개발 디렉팅만 하면 될 줄 알았는데, 실제로는 콘텐츠 디렉팅이 훨씬 더 많이 필요했다는 거에요. 즉, 만들고자 하는 서비스와 프로덕트의 본질에 대한 탐구를 더 많이 했어야 한다는 거죠.

레베카 : LEX를 만든 방식이 흥미로웠어요. 요즘 핫한 ‘바이브 코딩’으로 만드셨다고요.

에릭 :  맞습니다. 올 3월 쯤 바이브 코딩이 처음 나왔을 때 저도 시도해봤는데, 당시엔 솔직히 '아직 못 쓴다'고 봤어요. 그런데 시간이 지나면서 모델도 업그레이드 되고 도구도 업그레이드 되더라고요. 7월 쯤엔 '이제 해볼 만하다'는 느낌이 왔습니다. 그래서 바이브 코딩으로 해볼 수 있겠다 생각했어요. 전체 감독은 제가 하고, 실제 코딩 작업은 AI에게 순수하게 맡기는 방식으로.

저는 코드 타이핑을 거의 안 했고, 지시만 계속 타이핑했습니다. 그런데 재밌는 건, 코드 타이핑 때보다 지시 타이핑의 양이 훨씬 많았다는 점이에요 (웃음)

레베카 : 실제 바이브 코딩으로 코딩을 해보시니 어땠나요?

에릭 :  일단 손이 아팠습니다. (웃음)  코드를 치는 게 아니라 지시를 치게 되니까 초반에는 타이핑이 훨씬 많아져요. 그리고 초반엔 답답함이 큽니다. AI가 코딩하는 걸 보고 있으면 '그렇게 하면 안 좋은데' 싶은 순간이 계속 나오거든요. 벽에다 대고 얘기하듯이 짜증도 내고, 주니어 혼내듯이 말이 나가기도 했습니다. 결국 AI 성능이 좋아지는 시간 + 내가 AI에게 일 시키는 법을 훈련하는 시간을 보내게 되더라고요. 저도 AI를 알아가고, AI도 제 방식을 알아가는 과정을 같이 지나갔다고 해야 할까요.

레베카 : 그런데 'AI가 만든 콘텐츠는 AI 티가 난다'는 얘기가 있잖아요. 그 문제는 어떻게 해결했나요?

에릭 : 처음 요약을 돌리면 확실히 AI스럽게 나옵니다.  친절한데 묘하게 진심이 없고, 문장이 평면적이고, 사람이 쓴 느낌이 덜하죠. 그래서 저는 프롬프트를 이것저것 바꾸는 방식으로는 한계가 있다고 판단했습니다.

대신 기존 사람이 만들었던 뉴스레터 샘플을 모아서 AI에게 주고 스타일 분석을 시킨 뒤 그 톤을 모방하게 했어요. 40~50개 수준까지 참조를 쓴 걸로 기억합니다. 이때 쓴 방식이 흔히 말하는 Reverse Prompting(리버스 프롬프팅)이에요.  '내가 원하는 결과물이 이건데, 이런 결과물을 얻으려면 너에게 어떤 지시를 해야 하니?'라고 결과물→지시문을 역으로 도출하는 방식이죠.

레베카 : 코딩은 바이브 코딩을 사용하셨고, 그 외 다른 AI 모델들도 쓰셨나요?

에릭 : 당시(개발 시점)에는 제미나이가 무료로 제공되는 부분이 많아서 통일해 쓰려 했어요. 그런데 어떤 구간에서 성능이 안 나와서 당황했습니다. 특히 유사 기사 판별처럼 정교한 분류와 판단이 필요한 구간에서 문제가 생겼어요. 기사 수집을 600건 정도 해오면 그 안에서 유사 기사들을 솎아야 하는데 그게 잘 안 됐죠. 그래서 OpenAI 모델과 섞어서 사용했습니다. 다만 이건 지금의 모델 비교가 아니라, 그때 개발하던 시점의 판단이라는 전제를 꼭 붙여야 합니다.

레베카 : 렉스를 만들고 난 뒤, 가장 크게 배운 점은 무엇이었나요?

에릭 :  '된다'는 확신이 생겼다는 겁니다. 처음엔 가능할 거라 보면서도 확신은 못 했어요. 그런데 해놓고 보니 ‘이게 되네’가 됐죠. 그리고 지금은 오히려  '요즘 모델로 하면 훨씬 더 잘 되겠다.' 생각합니다. 올해 7월 개발 당시보다 모델들이 더 진화했거든요.  ‘AI의 침투 속도가 우리가 예상한 것보다 훨씬 빠를 수 있겠구나.’ 체감했습니다.

개인적으로는, 제가 회사 실무자 중 나이가 많은 편인데(웃음), 바이브 코딩을 통해 이런 결과물을 만들었다는 것 자체가 저에게는 부스터 툴이 생긴 느낌이었습니다. 안도하면서도 두렵고, 앞으로 일하는 방식이 크게 바뀌겠다는 감각이 왔어요.

레베카 : 앞으로 웨이브릿지에서 AI가 맡게 될 범위를 어떻게 보세요?

에릭 : 개발 생산성은 최소 2배 이상은 충분히 가능하다고 봅니다. 써본 사람들은 2~3배도 기대하죠. 그러면 우리가 '사람이 모자라서 못하고 있던 일'을 성취할 수 있는 여지가 생깁니다. 그리고 더 중요한 건, AI가 디테일을 가져가면 사람은 오히려 틀(architecture), 구조, 데이터 흐름, 서비스 본질에 집중하게 된다는 점입니다.  예전에는 개발자가 구현을 위해 공부하고, 가져오고, 해보고… 이게 컸는데, 이제는 AI가 상당 부분을 대신하니까 개발자는 프로덕트의 본질을 더 많이 고민해야만 하는 형태로 바뀔 가능성이 큽니다.

레베카 : 'AI를 잘 쓰는 법'을 한 문장으로 정리하면요?

에릭 :  범위를 줄이고, 필요한 정보를 정리해서 붙여라. 범위를 줄여야 지시가 길어지지 않고, 디테일한 지시가 가능해집니다. 사람은 ‘척하면 척’이 되는 구간이 있지만, AI는 그게 없어서 더 명확해야 합니다.
초반에 제가 손이 아팠던 것도 지시가 장황해져서 였어요. 지금은 '일을 시키는 틀'이 제가 갖춰진 느낌이고, 그걸 전사에 전파하고 있습니다. 이제부터는 'AI를 활용하는 효과적인 개발 방법' 형태로 공유할 예정이고요.

그리고 매번 요구 조건을 새로 입력하는 대신, 헌법 같은 문서를 만들어 계속 누적시키는 게 좋습니다. 제약 조건과, 요구 조건을 문서로 쌓아두고 AI가 참조하게 만들면 결과물이 일관되게 나오거든요.

레베카 : 에릭에게 AI는 도구인가요, 동료인가요?

에릭 :  저는 AI가 [셜록 홈즈] 의 등장인물인 왓슨에 가깝다고 생각해요. 지능은 나보다 못할 때도 있고, 말귀를 못 알아듣는 순간도 있지만,  내가 생각 못한 걸 제안해주기도 하고, 성실하고… 이만한 공로를 가진 동료를 찾기 어렵죠.

레베카 : 마지막으로, AI와 함께 일하는 환경에 관심 있는 사람들에게 한마디만 해주신다면요?

에릭 : 두려워하지 말자.  어차피 미래는 누구나 다 두렵다. 다 같이 모르는 걸 두려워할 필요는 없다.  그냥 쓰자.  AI는 좋은 도구이자 동료다.

레베카 : 오늘 말씀 들으면서 LEX가 단순한 자동화 툴이 아니라는 걸 확실히 느꼈어요. 그리고 에릭의 여정 자체도 궁금해지는데요. 다음에 또 시간 내주실 수 있을까요?

에릭 : 물론이죠. 언제든 환영입니다.

레베카 : 감사합니다.

다음 편 Episode 2에서는, 에릭과 함께 '스타트업들이 AI로 할 수 있는 영역이 무엇일까'에 대한 관점을 나눠볼 예정입니다.

👉 웨이브릿지 뉴스레터 구독하러 가기 : 첫 페이지 우상단의 'Subscribe' 를 눌러주세요!

Subscribe to Wavebridge Insights

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe