이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가,  비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

이승민 총괄은 사흘 동안 83번의 실험을 돌렸습니다. 정확히는, 지켜보기만 했어요. 실험을 설계하고, 결과를 채점하고, 다음 버전을 만드는 일까지 전부 AI가 혼자 했거든요. 검색 정확도는 52%에서 91%까지 올라갔습니다. 예전에 그가 톰슨 로이터에서 법률 AI를 만들 때는, 변호사 200명과 6개월을 갈아 넣어야 정확도 3%를 올릴 수 있었습니다.

"에이전트가 늘어날수록 사람이 직접 하는 일은 줄어듭니다. 대신 좋은 것과 나쁜 것을 구별하는 판단 기준을 만들어야 합니다." 오늘 모신 두 분은 그 판단 기준을 만드는 도구를 파는 회사, 어라이즈 AI(Arize AI)의 이승민 APAC 기술총괄과 진상열 코리아 GM입니다. 포춘 500대 기업 중 100곳이 쓰는 AI 관측(Observability) 플랫폼이 실제로 어떻게 돌아가는지, 화면을 열어 놓고 하나씩 물어봤습니다.

['빌더 조쉬' 유튜브 구독하러가기]

AI 에이전트를 찍는 엑스레이 회사

Q. 먼저 두 분 소개 부탁드립니다.

이승민 | 제 이름은 이승민이라고 하고요. 업계에는 15, 16년 정도 있었던 것 같아요. 지금은 어라이즈 AI라는 미국 스타트업에서 아시아 태평양 기술 총괄로 일하고 있습니다. 한국, 일본, 호주, 싱가포르, 인도, 대만, 태국, 베트남까지 아태 지역 고객분들께 어라이즈를 잘 쓰시는 법, 그리고 AI 에이전트를 만드는 전반적인 과정을 가이드해 드리는 역할을 하고 있어요.

진상열 | 진상열이라고 합니다. 저도 비슷한 연차의 경력을 갖고 있고요. 현재는 어라이즈 AI에서 한국과 일본 쪽 비즈니스를 총괄하고 있습니다. 세일즈뿐만 아니라 파트너십, 그리고 다양한 플랫폼 파트너사와 함께 고객분들께 더 나은 서비스를 제공하는 패키지를 발굴하는 역할을 하고 있습니다.

Q. 어라이즈 AI는 어떤 회사인가요?

이승민 | 어라이즈는 2020년에 설립된 LLM(대규모 언어 모델) 가시성 전문 회사예요. 제가 이직할 때 주변에서 "거기 뭐 하는 데냐"고 많이들 물으셨는데, 저는 이렇게 설명합니다. 엑스레이나 MRI를 만드는 회사인데, 찍는 대상이 사람이 아니라 AI 에이전트다.

우리가 챗GPT를 쓸 때 뒤에서 어떤 동작이 일어나는지 확인이 안 되잖아요. 그런데 기업이 AI 에이전트를 만들 때 내부에서 어떻게 돌아가는지 모르면, 어디가 잘못돼서 답변이 이상하게 나왔는지 분석하기가 어렵거든요. 그래서 우리가 건강검진 받듯이 AI도 주기적으로 사진을 찍어 줘야 한다, 그런 서비스를 제공하는 회사라고 보시면 됩니다.

Q. 기업이 이런 도구를 꼭 써야 하는 이유는 뭔가요?

진상열 | 예전에는 시스템을 모니터링할 때 지표가 명확했어요. 그런데 AI 쪽은 다릅니다. 특히 단일 모델 호출이 아니라 여러 에이전트가 유기적으로 결합해서 돌아가는 기업 환경에서는, 기존에 보던 지표는 전부 정상인데 품질에 문제가 생기는 경우가 많아요. 원래는 A라는 답변이 나와야 하는데 우리 AI 서비스는 B나 C 같은 이상한 답변을 하고 있고, 그런데 모든 지표는 정상인 거죠.

저희가 제공하는 건 그걸 잘 볼 수 있는 옵저버빌리티(observability, 시스템 내부 상태를 밖에서 관찰할 수 있게 만드는 것)와, AI가 어떻게 행동하고 있는지 판단할 수 있는 정량적인 기준입니다. AI로 비즈니스를 하는 분들께는 필수불가결한 플랫폼이 아닌가 생각해요.

Q. 승민 님은 원래 어떤 커리어를 밟아 오셨나요?

이승민 | 대학에서 컴퓨터공학을 전공하고, 한국에서 취업하지 않고 캐나다로 건너갔어요. 커리어의 12년 정도를 캐나다에서 보냈습니다. 한국에 들어오기 직전에 일했던 회사가 톰슨 로이터인데, 거기 AI 연구실에서 웨스트로(Westlaw, 톰슨 로이터의 법률 검색 서비스)의 검색 성능과 답변 품질을 높이는 일을 4년 정도 했어요.

결정적인 분기점은 2016년이었습니다. 알파고가 나왔잖아요. 알파고를 보는 순간 '무조건 AI를 해야겠다'는 생각이 들었어요. 그러다 톰슨 로이터에 AI 랩이 생겼다는 얘기를 듣고 합류해서, AI를 전문으로 하는 박사님들과 제품 개발에 참여하게 된 거죠. 그 뒤 한국에 들어와서 AWS의 전문가 서비스 팀에서 일했고요.

Q. 어라이즈에 합류하게 된 계기는 어떻게 되시나요?

이승민 | 2025년 6월쯤 합류했는데, 그때는 아시아 태평양 전체에 어라이즈 직원이 저 혼자였어요.

어라이즈를 처음 알게 된 건 아마존에서 국내 엔터프라이즈 고객들을 만나면서였어요. 2024년부터 다들 AI 에이전트를 도입하기 시작하셨는데, 그전까지는 에이전트 동작을 확인하고 검증하는 걸 전부 로그 기반으로 했어요. 그런데 로그는 여러 데이터가 섞여서 들어오니까, 어떤 프롬프트가 문제였는지, 어떤 모델이 문제였는지, 임베딩 벡터가 문제였는지 파악하려면 로그를 전부 뒤져 볼 수밖에 없더라고요.

그러다 어라이즈가 만든 오픈소스 피닉스(Phoenix)를 접하게 됐어요. 제가 담당하던 고객분들께 추천해서 쓰기 시작했는데, 고객들이 너무 좋아하시고 저희 삶도 눈에 띄게 나아졌습니다. 그래서 오픈소스 커뮤니티에 기여를 시작했죠. 그때만 해도 애사심이 대단해서, 아마존 관련 코드와 튜토리얼이 너무 없는 게 눈에 밟혔거든요. 그걸 추가하다 보니 어라이즈 쪽에서 연락이 왔어요. 매년 6월에 샌프란시스코에서 '옵저브(Observe)'라는 행사를 하는데, 초청할 테니 오겠냐고요. 당연히 갔죠. 가서 CEO, CPO, CISO를 다 만나고 "한국에서 제품이 너무 좋아서 이야기 들으러 왔다"고 했어요. 그날 하루 세션이 정말 좋았고, 그 이후로 인연이 이어졌습니다.

그러다 2025년 2월에 어라이즈가 시리즈 C 투자를 받으면서 자금이 확보됐어요. 북미에서는 이미 안정된 비즈니스를 갖춰 놨으니 아시아 태평양으로 확장하자, 그런데 아시아에 우리가 아는 사람이 하나 있었네, 한번 물어보자. 4월쯤 연락이 왔어요. "우리 아시아 태평양 확장하려는데 네가 맡아 줄 수 있어?"

고민하지 않았어요. 커뮤니티 활동을 같이하면서 느낀 게, 이분들의 엔지니어링 성숙도가 상당히 높다는 거였거든요. 그리고 제가 셰릴 샌드버그와 에릭 슈미트 일화를 좋아해요. 샌드버그가 스타트업 시절의 구글에 합류할지 고민할 때 슈미트가 이렇게 말했다고 하죠. "로켓에 자리가 나면 무조건 타야 한다." 회사 이름부터 어라이즈, 올라간다는 뜻이잖아요. 그래서 바로 탑승했습니다.

Q. 상열 님은 보안 엔지니어 출신이라고 들었습니다.

진상열 | 제 시작은 조금 독특해요. 원래 보안 엔지니어였는데, 예전에 사고를 한번 쳤습니다. 지금 윤리 기준으로는 안 되는 해킹 같은 걸 해서 우여곡절을 겪었죠. 그러다 국내 SI 회사의 미국 법인으로 취직했고, 다음에는 우리가 흔히 아는 쇼핑하는 아마존, 그 리테일 쪽에서 일하다가 2018년쯤 카카오모빌리티와 연이 닿아 한국으로 돌아왔어요.

그 과정에서 AWS에서 연락이 와서 몇 개 포지션을 제안받았고, 이승민 총괄님과 같은 조직인 전문가 서비스 팀에 합류했습니다. 총괄님에게 톰슨 로이터가 전환점이었다면 저는 AWS 입사가 전환점이었던 것 같아요.

총괄님이 2025년에 어라이즈로 옮기셨는데, 저는 같은 팀에 있다 보니 2024년부터 어라이즈에 대해 어느 정도 알고 있었어요. 어라이즈가 한국에서 고객을 찾을 때 저희가 만나는 고객들마다 소개도 해 드렸고요. 그러다 제안을 받았고, 또 다른 물결을 탈 수 있는 좋은 기회라고 판단해서 지금 이 자리에 오게 됐습니다.

쌓고, 평가하고, 인사이트

Q. AI 옵저버빌리티가 정확히 뭔지 조금 더 쉽게 설명해 주실 수 있을까요?

이승민 | 우리 업계의 큰 병폐 중 하나가, 간단한 걸 어려운 말로 표현해서 많은 분들께 장벽처럼 느끼게 한다는 거예요.

옵저버빌리티는 한마디로 '쌓는다'입니다. 쌓은 데이터를 평가(evaluation)하면, 그 두 개가 합쳐져서 인사이트라는 아웃풋이 나와요. 그러니까 옵저버빌리티를 구축한다는 말은, 우리 에이전트의 동작을 전부 기록한다는 뜻입니다. 그렇게 정리하면 간단해요.

Q. 에이전트가 현장에서 돌아가는데, 왜 굳이 전부 기록해야 하는 걸까요?

이승민 | 어라이즈는 포춘 500대 기업 중 100곳이 채택해서 쓰고 있는데, 유즈 케이스를 좁혀서 말씀드릴게요. 특히 금융사와 통신사가 어라이즈를 선호하세요. 금융과 비슷한 도메인이 의료와 국방인데, 단 1%의 오류도 허용해서는 안 되는 분야예요.

특히 금융은 규제 산업이라 정부가 여러 증적 자료를 요청할 수 있고, 실제로 요청하고 있습니다. 우리나라도 관련 법안이 준비돼서 작년 말에 가이드라인이 나왔고, 올해부터 강제성을 띠고 적용되고 있어요. 그러면 옵저버빌리티가 없는 상태에서는 대응을 할 수가 없죠. 금융 감독 당국이 나와서 "너희 개인정보 처리 어떻게 하고 있어?"라고 물었을 때, "저희는 느낌 좋게 하고 있습니다"라고 답할 순 없잖아요. 증거 자료가 없으면 심사 탈락입니다. 실제로 어디라고 말할 수 없는 국내 기업 중에, 에이전트를 다 만들고 보도자료까지 뿌린 상태에서 심사에 탈락해 런칭을 못 한 곳이 있어요.

규제만 문제가 되는 것도 아니에요. 여행 에이전트 같은 경우를 보면요. 고객이 프랑스 파리로 가는 비행기 티켓을 예약하려는데, 공교롭게도 미국에도 패리스라는 도시가 있습니다. 에이전트가 목적지를 착각해서 예약해 버리면 고객 입장에서는 그 브랜드를 쓸 이유가 없어지고, 경쟁사에 뺏기겠죠.

그런 문제를 풀려고 하면 첫 번째 숙제는, 이 에이전트가 왜 그런 판단을 했는지, 어디서 그런 판단이 일어나는지를 처음에는 모른다는 거예요. 그래서 일단 다 쌓아야 합니다. 다 쌓고, 그 위에서 평가를 돌려서 우리 에이전트가 어디서 실패하는지 파악하고, 그 부분을 집중 공략해서 풀어 나가는 거죠. 규제 산업이든 아니든, 우리 에이전트가 브랜드에 데미지를 줄 수 있는 상황에서 우리를 보호하려면 어떤 행동을 왜 하는지에 대한 증적을 쌓아야 한다는 겁니다.

Q. 그 '쌓는다'는 게 기술적으로는 어떻게 이뤄지나요?

진상열 | AI 쪽에서 일어나는 모든 액션에는 시작과 끝이 있잖아요. 그걸 최소 단위로 쪼개는데, 그 단위를 스팬(span)이라고 불러요. 그 스팬 하나하나를 전부 쌓습니다. 에이전트가 한 개든 열 개든 수천 개든, 나노초 수준까지 액션을 관찰하면 결국 각 에이전트가 활동하는 액션이 다 남게 되거든요. AI 쪽의 가장 작은 단위를 하나하나 로그로 남긴다고 보시면 돼요.

그 로그를 남기는 데이터 규격을 저희가 자체적으로 만들었는데, 그게 오픈인퍼런스(OpenInference)예요. 이게 어쩌다 보니 업계 표준이 됐습니다. 보통 가장 빠르게 치고 나가는 회사가 하나 있고, 그 회사 것을 남들이 갖다 쓰기 편한 형태면 글로벌 표준이 되는 건 금방이더라고요.

Q. 오픈인퍼런스라는 규격이 왜 중요한 건가요?

이승민 | 용어를 정확히 하면, 인퍼런스는 우리말로 추론이에요. 오픈인퍼런스는 그 추론을 추적하는 기능인데, 중요한 건 저희가 규격을 선언했다는 부분이에요.

규격이 왜 중요하냐면, 우리나라 어딜 가도 전기 콘센트에 꽂을 때 젠더를 갖고 다니지 않잖아요. 믿고 쓰니까요. 오픈인퍼런스도 마찬가지로, 규격만 통일하면 랭체인(LangChain, AI 앱 개발 프레임워크)으로 에이전트를 만들든 파이썬으로 만들든 자바스크립트나 자바로 만들든 상관없이 규격 하나로 모든 에이전트를 추적할 수 있어요. 완전히 공개된 건 아니지만, 이름을 말하면 아는 퍼블릭 클라우드 업체에서도 오픈인퍼런스를 자체 규격으로 채택했다는 얘기를 듣고 있습니다.

제로 베이스에서 만든 건 아니에요. 업계에서 오랫동안 써 온 오픈텔레메트리(OpenTelemetry, 시스템 모니터링 데이터를 수집하는 오픈소스 표준)를 기반으로, LLM 가시성에 필요한 요소들을 추가한 버전이라고 보시면 됩니다.

이벨(Eval)의 네 가지 무기

Q. 데이터를 다 쌓았다면, 그다음 평가는 어떻게 하는 건가요? 요즘 이벨(evals)이라고 많이들 부르던데요.

이승민 | 이벨, 그러니까 평가는 전통적으로 두 가지 방식이었는데, 시대가 발전하면서 세 가지가 됐고 올해부터는 네 가지 방식으로 수행할 수 있게 됐습니다.

제가 톰슨 로이터에 있던 2018년부터 2022년까지는 두 가지뿐이었어요. 첫 번째는 사람이 하는 이벨. 엑셀 파일로 하는 이벨이에요. 웃으시겠지만 그때는 정말 열심히 했습니다. 엑셀 파일을 '최종의 최종의 최종'까지 버전 관리해서 서로 전달하면서요. 저희는 법률 AI였기 때문에 도메인 전문가가 전부 변호사였어요. 변호사 200명에게 엑셀 파일을 뿌리고, 그분들이 마킹해 준 걸 다시 수집해서 데이터셋을 추려 내는 작업을 했죠. 비싼 작업이고, 지금도 하고 있는 가장 고급 이벨이에요. 가장 비싸지만 가장 높은 품질의 데이터셋이 나옵니다.

그거랑 병행했던 게 코드 이벨, 다른 말로 룰 베이스예요. 정규식 같은 걸 넣어서 특정 단어가 있냐 없냐로 탐지해서 코드로 평가하는 거죠. 2022년까지 인류에게 주어졌던 무기는 이 두 개였습니다.

2022년에 챗GPT가 나오면서 세 번째 문이 열렸어요. LLM 이벨이죠. 모든 업체가 LLM 이벨을 도입해서 에이전트 평가에 쓰기 시작했는데, 어떤 느낌이냐면, 사람보다는 많이 떨어지지만 그래도 인간에 준하는 지능을 가진 모델을 쓰는 거라 경향성은 측정할 수 있는 거예요. 오늘 점수가 55점인데 일주일 뒤 65점이면 "나아졌구나" 판단할 수 있는 거죠.

Q. LLM 이벨에도 한계가 있었나요?

이승민 | 있습니다. LLM 이벨에서 우리가 만질 수 있는 요소는 두 개뿐이에요. 모델을 바꾸든지, 평가 프롬프트를 바꾸든지. 그런데 이 두 요소만으로는 인간 전문가의 도메인 지식을 온전히 반영을 못 하는 거예요. 그건 LLM 이벨로는 못 잡는다는 게 거의 확정된 것 같아요.

그래서 올해 어라이즈가 출시한 새로운 기능이 에이전트 이벨입니다. LLM과 프롬프트라는 두 요소만으로는 인간 전문가의 지식을 담아낼 수 없다는 게 확인됐으니, 훨씬 고도화된 에이전트를 자체적으로 만들고, 그 에이전트가 평가를 수행하게 하는 거예요. 그러면 가장 고급이라고 했던 휴먼 이벨에 준하는 이벨을 가질 수 있게 됩니다. 요약하면, 이 네 가지를 구사해서 우리 에이전트의 문제점을 감지할 수 있다는 거예요.

Q. 평가라는 게 왜 그렇게까지 필요한 건가요? 사람마다 기준도 다를 텐데요.

진상열 | 평가라는 게 재밌어요. LLM한테 물어봐서 하는 거냐, 사람한테 물어봐서 하는 거냐. 연구 결과를 보면 LLM이 사람과 비교해서 대략 80~85% 정도는 사람에 가까운 평가를 내릴 수 있다고 해요. 나머지 15~20% 격차가 엄청난 거잖아요. 그런데 웃긴 건, 사람도 사람마다 평가 기준이 다 다르거든요. 그걸 어떻게 신뢰하느냐는 반론에 항상 부딪히는 것도 사실이에요.

그럼에도 평가가 중요한 이유는, AI에서 어떤 결과물이 나왔을 때 그게 어떤 과정을 거쳐 왜 나왔는지를 100% 명확한 정답지로 판단하는 게 현재로서는 불가능하기 때문이에요. 그러면 '이 정도면 우리가 어느 정도 수용할 수 있는 수준이지 않을까'라는 전제 조건을 가지고 판단하는 거죠. 평가는 아직 부정확성과 불안정성이 크긴 하지만, 반드시 필요한 요소라고 생각합니다.

Q. 우리 회사도 해 볼 수 있을까 싶은 분들을 위해서, 이벨은 어디서부터 시작하면 되나요?

이승민 | 이벨은 건강 검진으로 접근하면 가장 좋은 것 같아요. 우리가 할 수 있는 가장 쉬운 검진이 있죠. 체중계에 올라가는 거예요. 체중계로 메트릭을 재는 건데, 체중계만으로도 건강 관리에 필요한 웬만한 정보는 얻을 수 있잖아요.

그러니까 이벨은 여정이에요. 한번 도입했다고 끝나는 게 아니고, 이벨에는 여러 층위가 있어요. 가장 간단한 것부터 시작해서 점점 고도화해 나가는 거죠. 처음에는 체중으로 시작했다가 혈당도 재고, BMI도 재고, 나중에는 MRI도 찍고. 점점 방망이를 깎아 나가는 거예요.이벨을 잘 수행한 곳과 아닌 곳은 사고가 터지느냐 안 터지느냐에서 갈려요.

두 번째는 비용 관리에서 갈립니다. 제가 최근에 리서치한 케이스 중에 윈드서프(Windsurf)와 커서(Cursor)의 대결이 있는데요. 물론 하나의 이유로 결정되진 않았겠지만, 둘의 큰 차이 중 하나가 비용 관리였더라고요. 커서는 어떻게든 자체 모델로 비용을 커버하려고 했고, 윈드서프는 모델 비용을 앤트로픽이나 OpenAI에 고스란히 내는 구조였어요. 그러니까 고객이 늘수록 커서는 그래도 이익이 생기는데, 윈드서프는 고객이 늘수록 적자가 커지는 구조라 장기적으로 유지가 안 됐던 거죠.

Q. 비용 관리에 이벨이 어떻게 쓰이는 건가요?

이승민 | 처음부터 스펙트럼을 쭉 펼쳐 놓고 보면, 정말 이벨을 잘 쓰시는 분들은 몇백 개의 이벨을 돌려요. 그걸 처음부터 다 할 수는 없죠. 나에게 좋은 이벨이 뭔지 찾아가는 과정이 필요하고, 시작은 간단한 것부터 하는 거예요.

예를 들어 직원들에게 클로드 코드(Claude Code)를 사 줬다고 해 볼게요. 코드 이벨, 룰 베이스로 이런 걸 측정할 수 있어요. "우리 직원들 대화 내용 중에 주식·부동산·코인 들어간 거 찾아줘." 들어가면 예스, 없으면 노. 그러면 전체 대화 중 몇 %가 업무와 무관한 대화였는지 나오죠. 그걸 보고 회사가 시스템 프롬프트를 내려 줄 수 있어요. "그런 대화는 못 하는 거야." 그러면 직원이 클로드 코드를 쓰더라도 설정 파일(CLAUDE.md)에 박혀 있으니 업무 무관한 요청에는 에러 메시지가 나겠죠. 회사가 의도한 대로 에이전트와 사용자가 잘 쓰고 있는지, 이런 걸 측정할 수 있는 거예요.

점점 고도화하다 보면 이런 판단도 할 수 있어요. 우리는 지금 오퍼스 5(Claude Opus 5)를 쓰고 있는데, 윈드서프처럼 비용 문제가 생길 수 있잖아요. 그러면 이걸 GLM이나 큐원(Qwen) 같은 오픈소스 모델로 대체할 수 있을까? 평가를 돌리면 점수가 나오고, 약점이 드러나죠. 우리 데이터셋으로 돌려 봤더니 오퍼스와 차이가 20% 정도 나는데, 우리 도메인에 한해서는 하네스(harness, 모델을 감싸는 워크플로우 전체)를 개선해서 따라잡을 수 있겠다. 그러면 모델을 교체하고 하네스를 보강해서 동일 품질, 또는 그 이상의 품질을 내면서 운영 비용은 3분의 1로 줄이는 거예요.

그게 실제로 LG유플러스가 지난 6월에 발표한 사례이기도 해요. LG유플러스도 프론티어 모델(최신 최고 성능 모델)을 벤치마크로 쓰고, 에이전트에는 여러 모델이 들어가잖아요. 그중 단순 작업은 전부 자사 모델로 빼 놓은 거예요. 전체 코스트를 낮췄고, 소형 모델은 응답도 빨리 나오니까 응답 속도도 개선되는 효과가 있었죠. 이벨로 비용 관리도 하고, 사고 예방도 하고, 사용자의 행동을 우리가 원하는 방향으로 유도하는 것도 가능합니다.

Q. LLM 이벨과 에이전트 이벨은 구체적으로 뭐가 다른가요?

이승민 | 가장 큰 차이를 설명하는 데는 2024년 앤드류 응(Andrew Ng) 교수의 강연이 제일 좋은 것 같아요. 응 교수가 이렇게 말했어요. "나는 GPT-3.5로 GPT-4.5 이상의 성능을 뽑아낼 수 있다"는 거예요.

에이전트와 모델의 큰 차이는, 모델이 에이전트라는 큰 워크플로우의 한 요소로 들어간다는 겁니다. 응 교수는 이걸 '에이전틱 워크플로우'라고 정의했는데, 글자 수가 많아서 사람들 입에 안 붙었죠. 그래서 새로 나온 용어가 하네스예요. 같은 말입니다. 하네스 안에 모델이 여러 번 들어가는 거죠.

응 교수의 논리는 이래요. 나는 글을 쓰기 전에 리서치를 하고, 직접 쓰고, 세 번째로 리뷰를 한다. 그러니까 GPT-3.5를 세 번 호출하는 거예요. 리서치 용도로 한 번(우리가 말하는 툴 콜링), 실제 글 쓰는 작업으로 한 번, 리뷰로 한 번. 이렇게 세 단계로 나눠 GPT-3.5를 세 번 호출하면 GPT-4.5를 한 번 호출하는 것보다 결과물이 낫다는 거죠.

이 접근법을 그대로 평가에 적용하면 됩니다. LLM 호출 한 번으로 평가하는 건 부정확하더라도, LLM 여러 번을 워크플로우로 묶으면 정확해지는 거예요.

예를 들어 구글에 이미 들어가 있는 구글 검색 그라운딩(grounding, 답변을 실제 검색 결과에 근거하게 만드는 기능) 같은 걸 평가 단계에 넣어서, 바로 웹 검색을 해서 라이브 데이터로 검증하는 거죠. LLM 호출만으로 하면 과거 데이터로 학습됐기 때문에 평가가 정확하지 않을 수 있거든요. 그래서 에이전트 평가는 LLM 평가의 업그레이드 버전이라고 보시면 됩니다.

벤치마크는 이미 공략됐다

Q. 벤치마크도 하나의 평가잖아요. 그런데 벤치마크 점수가 좋다고 해서 모델을 바꿔 보면 성능이 그만큼 안 나오는 경우가 많다고 들었어요.

이승민 | 올해부터 포착되는 트렌드 중 하나가 커스텀 벤치마크예요. 공개돼 있는 벤치마크는 거의 다 학습 데이터로 사용돼 버렸다고 보시는 게 맞아요. 그래서 말씀하신 이슈가 생기는 거예요. 모델이 과적합된 거죠. 이건 안 할 수가 없어요. 경쟁사는 그 벤치마크에서 점수가 잘 나올 거고, 내가 현실에서 잘되는 모델을 만들었다 해도 벤치마크 점수가 안 나오면 사람들이 안 쓸 테니까요. 업계에서 다 알고 있는 문제고, 그래서 앞선 회사들은 커스텀 벤치마크의 필요성에 눈을 뜬 상태예요.

그런데 커스텀 벤치마크를 만드는 게 쉽지 않아요. 요즘 가장 큰 병목이 어디냐고 묻는다면 저는 데이터셋이라고 생각하거든요.

Q. 데이터셋이 왜 병목인가요?

이승민 | 이렇게 생각하면 간단해요. 데이터셋은 좋은 것과 나쁜 것을 구별할 수 있는 것입니다. 

커피로 예를 들어 볼게요. 저는 커피에 호불호가 없어서 누가 좋은 커피 추천해 달라고 하면 못 해 줘요. 그런데 유명한 바리스타는 좋은 커피와 나쁜 커피를 정확하게 구별할 수 있죠. 그게 그분의 도메인 지식이고, 그분 머릿속에는 데이터셋이 있는 거예요. 그분을 인터뷰해서 "콜롬비아산 이 커피는 좋은가 나쁜가" 하면 체크를 하실 거고요.

이분이 어떻게 그런 데이터셋을 갖게 됐는지 생각해 보면, 오랜 시간 시행착오를 겪으면서 맛있는 것과 맛없는 것을 다 먹어 보고 자기만의 판단 기준이 생긴 거잖아요. 이 정보가 그 사람 안에만 있으면 노하우인데, 어떤 식으로든 추출해서 AI가 볼 수 있는 형식으로 뽑아내면 그게 데이터셋이에요. 사람 머릿속에만 있는 기준, 다른 말로 하면 '취향'이 AI가 볼 수 있는 형식으로 만들어진 것.

그런데 그러려면 첫째, 훌륭한 도메인 전문가를 찾아야 합니다. 그리고 훌륭한 도메인 전문가는 대부분 바빠요. 비싸고, 시간 확보도 어렵고요. 게다가 이 정보를 쉽게 나눠 주지도 않아요. 그걸 내가 갖고 있는 게 직업 안정성에 도움이 되니까요. 이 관문을 다 통과해야 하니 기업이 좋은 데이터셋을 확보하기가 어려운 거죠. 그래도 일부 기업은 하고 있어요.

Q. 그러면 이벨과 좋은 데이터셋은 결국 같은 얘기인가요? 좋은 데이터셋이 이미 있다면 이벨은 어떻게 활용되는 거죠?

진상열 | 좋은 데이터셋이 있으면 이벨은 그 범위 안에서 자동으로 굴러가요. 그런데 방금 좋은 데이터셋 만들기가 어렵다고 하셨잖아요. 그런데 사람은 오류를 전제로 하는 동물이잖아요. 실제로 쓰다 보면 오타도 많을 거고, 아무리 잘 정제된 데이터라도 이 컬럼에는 A를 저장해야 하는데 B가 들어가는 경우가 무수히 많거든요.

그래서 제가 생각하는 좋은 데이터셋은 그런 오류마저 자연스럽게 녹아 들어간 환경이어야 한다고 봐요. 그 오류까지 모델이 학습해야 우리가 원하는 실질적인 답변을 잘 해낼 수 있는데, 그걸 어떻게 쌓을 거냐가 모두의 숙제인 것 같아요. 결론은, 우리 회사만의 패턴과 오류는 우리 회사만 가질 수 있다는 거예요. 그러니까 회사마다 데이터셋을 쌓아 가는 방법을 알려 주는 것도 어려운 영역이고요. 반대로 어떤 회사가 그걸 잘해서 장기간 쌓았다면, 그 회사는 자동으로 평가를 할 수 있는 거죠. 그 데이터셋이 우리의 정답지가 되니까요.

Q. 골든 데이터셋이 고정된 정답지가 아니라 회사마다 달라진다는 거네요. 중소기업에서 팀장 한 분이 감으로 하던 판단을 기록해 에이전트에게 넘기는 것도 해당하나요?

이승민 | 맞아요. 그런 부분에서 저희는 시작하려고 합니다. 제가 만든 실시간 번역기 데모로 잠깐 보여 드릴게요.

번역기가 돌아가는 동안 어라이즈에 실시간으로 트레이스(trace, 에이전트의 동작 기록)가 쌓이고 있어요. 쌓인 트레이스를 열어 보면 어떤 식으로 번역이 일어나고 있는지 확인할 수 있고요.

제가 보여 드리고 싶은 건 세 가지예요.

첫째 옵저버빌리티를 쌓고, 둘째 평가를 돌리고, 셋째 그 둘을 합치면 인사이트가 나온다.

일단 트레이스를 쌓으면, 어라이즈에는 '데이터셋에 추가(Add to Dataset)'라는 기능이 있어요. 라이브 트레이스를 그대로 데이터셋으로 만들 수 있는 거예요. 여기에 평가를 돌려서 문제가 있었던 데이터만 따로 모아 별도 데이터셋을 만들 수도 있고, 좋았던 것만 모을 수도 있고요. 방금 말씀하신 암묵지 가득한 전문가가 있다면, 그분의 사번으로 검색해서 그분 대화만 뽑아 데이터셋을 만들 수도 있죠.

데이터셋이 있으면 그다음엔 루프 엔지니어링(AI가 실험→평가→개선을 자동으로 반복하는 방식)을 돌릴 수 있어요. 리버스 엔지니어링을 하는 거죠. "이분이 이렇게 판단한 기록이 있는데, 이런 의사 결정을 반영한 에이전트를 설계해 줘"를 역으로 생성할 수 있는 거예요.

Q. 그러니까 회사의 중요한 멤버가 LLM으로 일한 과정이 전부 기록으로 남으면, 그걸 묶어서 별도 에이전트나 평가 체계로 만들 수 있고, 그 자체가 하네스가 되는 거네요.

진상열 | 그렇죠. 저희를 도입해 주시면 너무 좋은데요. 다만 제가 강조하는 건, 시작할 수 있는 것부터 빨리 해 보는 게 중요하다는 거예요. 데이터셋까지 만들어서 평가하라는 건 더 많은 테크닉이 필요하지만, 트레이스를 쌓는 행위는 다양한 오픈소스로 지금도 할 수 있어요. 어라이즈도 오픈소스 피닉스가 있고, 한국에서는 랭퓨즈(Langfuse)가 꽤 유명한 오픈소스로 자리 잡고 있는데, 어떤 툴이 됐든 일단 트레이스를 쌓는 데서 시작하는 거예요. 데이터가 있어야 뭐라도 해 볼 수 있으니까요.

제일 좋은 건 일상 업무에 녹여 두는 거예요. 클로드 코드나 코덱스(Codex), 제미나이 CLI처럼 일반 사용자 랩탑에서 돌아가는 개발 에이전트가 있잖아요. 저희는 무료 티어가 있으니까 구글 계정으로 간단히 가입한 뒤, 트레이스 로그를 수집하는 플러그인을 설치하면 돼요. 구글에 '어라이즈 클로드 코드 플러그인'이라고 치면 페이지가 나오고, 어렵지 않게 구성할 수 있어요. 그러면 사용자는 평소처럼 클로드 코드를 쓰는데 자동으로 트레이스가 쌓이는 거죠.

쌓인 데이터를 실제로 확인해 보고, 거기에 어떤 평가를 도입할지 정하는 거예요. 룰 베이스 먼저 해 보고, 모델도 도입해 보고, 나중에는 에이전트까지. 순서대로 진행하면 좋지만 정답은 없어요. 규모에 따라 상황이 다르니까요. 다만 누구나 지금 시작할 수 있는 건, 트레이스를 쌓는 행위예요.

바이브 체크 대신 점수표

Q. 방금 트레이스가 쌓이던 그 번역기, 처음부터 보여 주실 수 있을까요? 에이전트에 어라이즈를 물리면 요청이 들어왔을 때 내부적으로 어떤 일이 일어나는지요.

이승민 | 저희가 밋업을 하는데, 해외 분들이 오셔서 강의할 때 보면 실시간 번역기를 돌리시더라고요. 그래서 제가 바이브 코딩(AI에게 말로 시켜서 코드를 짜는 방식)으로 하나 만들어 봤어요.

특징은 모델을 골라서 테스트하고 싶었다는 거예요. 먼저 음성을 텍스트로 옮기는 STT 작업이 필요하고, 그다음 텍스트를 한국어로 번역하는 작업이 필요하죠. 여기서는 속도가 중요하니까 경량 모델인 하이쿠(Claude Haiku)를 써 봤고요. 그리고 그록(Groq, 초고속 추론 칩 회사로 지금은 엔비디아가 기술 라이선스를 받고 핵심 인력을 데려간 곳)에서 큐원 모델을 빠르게 쓸 수 있는데, 개인적으로 써 보니 속도가 무척 빠르더라고요. 그리고 이제는 우주 기업이 돼 버린 xAI(스페이스X에 합병됨)의 그록(Grok). 발음이 같은 세 개의 모델을 두고 번역을 시켜 봤습니다.

제가 좋아하는 코난 오브라이언의 강연을 틀어 볼게요. 하이쿠 버전으로 시작하고, 오버레이(화면 위에 띄우는 자막창)를 띄워서 프레젠테이션 하단에 볼 수 있게 하고, 멈춘 다음 xAI 그록으로 넘어가서 다시 들어 보고요.

이렇게 다양한 모델로 번역을 수행해 봤어요. 영어를 아는 사람이 들어 보고 번역본을 보면 평가할 수 있겠죠. 업계 영어로는 바이브 체크라고 합니다. 바이브 체크로 "우리 이번 이벤트에는 그록으로 가야겠다" 또는 "하이쿠로 가야겠다" 결정할 수 있잖아요.

그런데 여기서 멈추지 않는 거예요. 이렇게 대화한 것들이 전부 어라이즈로 쏟아져 들어가고 있습니다. 들어간 다음에는 평가를 돌릴 수 있어요. 원, 투, 쓰리. 쌓고, 평가하고, 인사이트.

번역기를 돌리면서 바로 백단에서 평가를 돌려 지연 시간(latency)을 평가해 봤는데, 지연 시간은 확실히 그록(Groq)이 빨라요. 그런데 점수로 평가해 보면 xAI 그록이 품질은 더 좋습니다. 평가 결과가 표로 나오는데, 영어 원문을 놓고 비교해 보면 한쪽은 번역이 조금 딱딱하고 다른 쪽은 더 자연스럽죠.

이걸 보고 나면 우리는 더 이상 바이브 체크로 결정하지 않아요. 정량적인 숫자로, 우리 아키텍처에 적합한 모델이 무엇인지 확정할 수 있죠.

Q. 모델 선택을 숫자로 결정한다는 게 요즘 특히 중요한 이유가 있을까요?

이승민 | 업계에서 제가 우려하는 문제 중 하나가 이거예요. 클로드 코드에서 오퍼스나 페이블(Claude Fable) 모델을 쓰면 토큰 사용량이 어마어마하고 비용도 상당하거든요. 그런데 2026년 특히 하반기부터 글로벌 트렌드는 "당신 에이전트가 ROI(투자 대비 수익)가 나오느냐"를 묻고 있어요.

클로드 코드에 반드시 클로드 모델만 묶어서 쓰라는 법은 없거든요 . 모델을 바꿀 수도 있어요. 그런 식으로 선택의 가짓수에 유연하게 대처해야 합니다. 어느 한 에이전트 회사의 1등 하네스만 쓰는 게 과연 우리한테 최적일까? 이걸 바이브 체크로 결정하는 게 아니라 정량적인 평가 결과로 결정할 수 있다는 게 이제부터의 트렌드가 돼 가고 있다고 생각해요.

앞으로는 기업들이 우리 도메인에 맞는 모델이 뭔지 먼저 파악하고, 데이터셋을 확보하는 방법까지 쉬워졌으니 그걸로 모델을 파인튜닝하거나 강화 학습을 해서 우리 도메인에 맞는 우리 버전을 만들 거예요. 그걸 데이터셋 위에서 프론티어 모델과 같은 선상에 놓고, 우리가 더 낫냐 못하냐로 실제 프로덕션 배포를 결정하는 거죠.

Q. 방금 보여 주신 게 프라이빗 벤치마크의 샘플이라고 봐도 되겠네요. 그렇다면 각자 환경에 맞춰 이걸 쌓으려면 어디서부터 시작해야 할까요?

진상열 | 어렵게 생각할 필요는 없어요. 지금 LLM과 에이전트를 어떤 형태로 쓰고 있는지에 먼저 초점을 맞춰야 해요. 중앙에 GPU가 많아서 내부 모델을 온보딩해서 쓰고 있느냐, ADK나 SDK(에이전트·모델을 코드로 직접 다루는 개발 도구) 같은 걸 직접 호출해서 쓰고 있느냐, 아니면 모델을 제공하는 파트너사, 예를 들면 AWS·마이크로소프트·구글 같은 해외 CSP(클라우드 서비스 제공사)나 국내의 네이버·삼성SDS·LG CNS 같은 게이트웨이 역할을 하는 곳을 쓰고 있느냐.

일단 하나의 표본군을 정의하는 게 중요해요. 표본군을 정하고, 만약 게이트웨이 같은 걸 쓰고 있다면 거기서 발생하는 모델 호출 행위에 저희 플러그인을 가볍게 설치해서 시작하는 거예요.
엔터프라이즈 기준으로 결론을 말씀드리면, 어느 팀이 시작할 건데 그 팀이 어떤 아키텍처 지점에 오너십을 갖고 시작할 수 있느냐, 인프라 단에서 바로 시작할 수 있는지 아니면 사용자 PC 단에서 시작할 수 있는지를 먼저 파악하시는 거죠. 저희는 그런 지점들을 다 트레이싱할 수 있는 플러그인을 제공하고 있으니, 조직 내부에서 가장 빠르게 할 수 있는 지점을 정하고 거기 맞춰 시작하시길 추천합니다.

Q. 피닉스는 무료로 도입할 수 있다고 들었는데, 어떻게 하면 되나요?

이승민 | 피닉스는 오픈소스라서, 사내에 컨테이너 기술을 아는 분이 있다면 쉽게 쓸 수 있어요. 도커 허브(Docker Hub, 컨테이너 이미지 저장소)에서 피닉스 이미지를 받아서 구동만 하면 현재 돌리고 있는 에이전트에서 바로 트레이스를 받을 수 있게 돼 있습니다. 이미지가 빠른 속도로 개선되고 있어서, 지금 확인해 보니 5시간 전에 새 버전이 올라와 있더라고요.

사용 방법은 피닉스 공식 홈페이지에 친절하게 나와 있고, 설치 관련해서 도움이 필요하시면 채널을 통해 연락 주시면 적극적으로 도와드리겠습니다. 공식 슬랙 서포트 채널이 있긴 한데 영어로만 응대가 가능해서요.

Q. 혼자 만드는 싱글 빌더도 있을 텐데요. 피닉스 이미지를 받아서 쌓는다면 뭐부터 쌓으면 좋을까요?

이승민 | 두 가지 방향에서 접근해야 하고, 둘 다 해야 한다고 생각해요.

첫 번째는 트레이스를 쌓는 것. 기본 중의 기본이죠.

두 번째는 벤치마크인데, 처음부터 만드는 건 너무 어려워요.

그런데 저는 IT 업계에 너무 감사한 게, 제가 필요하다고 생각한 걸 누가 이미 만들어 놨어요. 허깅 페이스(Hugging Face)에 가면 웬만한 벤치마크로 쓸 수 있는 데이터셋이 다 올라와 있습니다. 그걸로 테스트를 해 볼 수 있어요. 내 에이전트 버전 1을 만들고 벤치마크 데이터셋으로 테스트하면 점수가 나오겠죠. 그러면 "다음 달에는 24점에서 47점까지 올려 보자" 이런 식으로 셀프 미션을 줘서 풀어 나갈 수 있는 거예요.

그러다 보면 우리 도메인과 결이 달라지는 방향이 당연히 생기죠. 그때 쓰는 게 어라이즈의 데이터셋을 만지는 기능이에요.

Alyx라고 어라이즈 AX에 있는 기능인데, 이것도 무료로 가입할 수 있어요. 예를 들어 허깅 페이스에서 가져온 데이터셋이 있는데 내 방향과 조금 안 맞는 것 같다, "일단 한글 데이터셋을 새로 만들어 주면 좋겠어"라고 자연어로만 얘기해도, 저희 내장 에이전트가 나의 도메인 트레이스와 허깅 페이스 데이터셋을 다 보는 상태에서 신규 데이터셋을 만들어 줄 수 있습니다. 그게 테스트 데이터셋 버전 2가 되는 거죠.

그걸로 다시 테스트하면 33점이 나오고, 허깅 페이스 기준으로는 에이전트 고도화에 성공했는데 실제 도메인 데이터셋으로 테스트하면 점수가 떨어지고, 그걸 다시 80, 90, 나중에는 99까지 올리는 식으로 데이터셋을 만들어 나갈 수 있어요.

 

Q. 프라이빗 벤치마크가 트렌드라고 하셨는데, 이걸 리딩하는 곳이 있나요?

이승민 | 시에라 AI(Sierra AI)라는 회사예요. 어떻게 보면 큰 SI 회사인데, CEO가 제가 알기로 OpenAI 이사회 의장을 비상근으로 맡고 계신 브렛 테일러(Bret Taylor)예요. 이분이 한 얘기가 와닿았어요. 2000년에 인터넷 시대가 열리면서 홈페이지 없는 기업이 없어졌듯이, 2022년 이후에는 대고객 에이전트 없는 회사가 없을 거다. 그 비전으로 대고객 에이전트 제작을 대응해 주는 회사죠.

 

그런데 그 일을 하다 보니 회사마다 테스트해야 하는 항목이나 지식이 완전히 다르다는 거예요. 그래서 만든 게 타우벤치(τ-bench)입니다. 도메인별로 테스트할 수 있게 돼 있어요. 오픈 데이터셋이라 특정 고객에 타게팅된 건 아니고 도메인에 타게팅돼 있죠. 항공업, 은행업, 통신업 이런 식으로요. 통신 데이터셋으로 모델을 줄 세워 보면 이렇더라, 하는 걸 볼 수 있는 거예요.

3일, 83번의 실험

Q. 어라이즈를 멀티 에이전트 고객사에 설치하면 에이전트가 스스로 셀프 임프루빙까지 할 수 있지 않을까 상상하게 되는데요. 그런 것도 지원하나요?

이승민 | 셀프 임프루빙은 어라이즈로 충분히 가능한 작업이고, 제가 직접 해봤습니다. 금융 도메인은 1%의 오류도 허용을 안 하는데, LLM은 확률적인 모델이라 검색 품질이 떨어지면 답변이 이상하게 나오는 걸 막기가 힘들거든요. 예전에는 에이전트를 배포하면 도메인 전문가들이 써 보고 피드백을 주는 데 하루, 새 버전을 만들고 배포하는 데 2~3일, 다시 평가받는 데 하루. 버전과 버전 사이에 4~5일씩 계속 누적됐어요.

셀프 임프루빙(self-improving)은 어라이즈로 충분히 가능하고, 저도 직접 해 봤어요. 실험을 해서 실제로 측정해 봤거든요. 시계열이 좀 길긴 한데, 첫 번째부터 보면 명백한 우상향 트렌드가 확인됩니다.

제가 돌린 셀프 임프루빙 루프는 금융 도메인 고객들이 공통으로 고통받는 문제예요. 비즈니스 쪽이나 리걸 쪽에서 1%의 오류도 허용을 안 하는데, LLM 자체가 확률적인 모델이고 검색 품질이 떨어지면 답변이 이상하게 나오는 걸 막기가 힘들거든요.

예전에는 이 문제를 풀려면 에이전트를 먼저 개발하고 배포하면 도메인 전문가들이 써 보고 피드백을 줘요. 피드백 받는 데 하루. 피드백이 오면 사람들이 인사이트를 캐치해서 새 버전을 만들고 배포하는 데 2~3일. 그걸 다시 도메인 전문가에게 주면 또 하루 걸려서 평가하고. 이 사이클을 돌리면 버전과 버전 사이에 4~5일씩, 일주일씩 계속 누적되는 거예요. 그게 곧 생산성이죠.

Q. 구체적으로 어떤 걸 실험하던가요?

이승민 | 검색에서 중요한 메트릭 중에 리콜(recall)이 있어요. 검색된 문서 열 개 중에 정답이 들어 있을 확률이죠. 처음에는 52%로 시작했어요. 실험하다 보면 떨어지기도 하고요.

여러 옵션을 테스트해요. 처음에는 하이드(HyDE, 가상의 답변을 먼저 만들어 그걸로 검색하는 기법)로 쿼리를 다시 써 보기도 하고, 리랭커(reranker, 검색 결과의 순위를 다시 매기는 모델)를 붙여 보기도 하고, 리랭커도 이것저것 써 보고, 임베딩 모델도 바꿔 보고, 임베딩 벡터도 바꿔 보고, 청크 사이즈도 바꿔 보고. 이걸 혼자서 다 실험을 돌려 본 다음에 최종적으로 91점, 90점까지 스스로 개선되는 거죠.

톰슨 로이터 때 기억을 떠올려 보면, 정말로 6개월 동안 변호사 200분과 열심히 일해서 정확도를 3% 올렸거든요. 6개월 동안이요. 그러면서 "우리 너무 잘했다" 하고 포상금도 받고 그랬는데, 그게 아닌 거예요. 이제는 루프를 돌리면 3일 만에 이런 결과가 나옵니다. 이걸 굉장히 큰 스케일로 하는 분야가 신약 개발이기도 하고요.

루프 엔지니어링의 재밌는 부분은, 원리적으로는 별게 아니라는 거예요. 그런데 얘가 뭘 하냐면, 인간이 가 보지 않은 길을 가요. 인간은 선입견이 있어서, 시간 제약 때문에, 또 게으름 때문에 가 보지 않은 길이 있는데 얘네는 가 보는 거예요. 그러다 보니 얻어걸리는 돌파구들이 있죠. 바둑에서 알파고가 이세돌을 이긴 묘수, 무브 37(Move 37)이 그렇게 탐색 과정에서 발견된 거고요. 이 기법들도 보다 보면 인간이었으면 테스트하지 않았을 시나리오를 테스트하거든요. 그러면서 제가 오히려 배워요. "RAG를 개선할 때는 이런 기법, 이런 조합도 가능하구나."

Q. 루프 엔지니어링이 검색 말고 프롬프트에도 적용되나요?

이승민 | 됩니다. 검색 개선에 비하면 마이너할 수도 있는데, 프롬프트를 자동으로 개선시켜 주는 것도 할 수 있어요.

진상열 | 지금 가장 적은 비용으로 양질의 결과를 낼 수 있는 방법 중 하나가 프롬프트 최적화거든요. 총괄님이 시연한 예시에서는 한글로 간단하게 "이 아티클을 요약해 줘"라고만 했어요. 허깅 페이스 데이터셋을 다운받아서 하신 거고요. 1번, 2번, 3번 버전이 조금씩 바뀌면서, 총괄님 개입 없이 프롬프트가 계속 자동으로 업데이트되는 거예요. 나중에 각 버전의 프롬프트를 적용해 보고, 무조건 최신 것이 좋은 건 아닐 수 있으니, 내가 가장 만족할 만한 답변을 내는 프롬프트를 쓰는 거죠.

이승민 | 이걸 트리거하려면 어라이즈에 옵티마이즈(Optimize)라는 기능이 있어요. 테스트하고 싶은 데이터셋만 물려 주면 구동됩니다. 저는 처음에 말도 못 하게 간단한 프롬프트를 줬어요. 그런데 얘가 새 버전을 쓰기 시작해요.

이 프롬프트는 사람이 쓴 게 아니라 AI가 쓴 거예요. 계속 반복하면서 깨닫는 거죠. "아, 예시를 줘야 점수가 잘 나오는구나." 그다음부터 예시를 넣기 시작하고, 성능이 나오는 걸 확인한 다음에는 룰도 쓰기 시작해요. 룰도 쓰고 예시도 넣고 계속 개선해 나가서, 최근 버전까지 가면 처음 한 줄짜리 프롬프트가 아주 탄탄한 프롬프트가 됐죠. 과거에는 프롬프트를 잘 쓰려면 프롬프트 엔지니어가 필요하다고 했는데, 이제는 자기가 자각해서 개선해 버리는 거예요. 

마지막에 남는 건 취향

Q. 어라이즈 코리아에서 커뮤니티를 운영하고 계시죠. 분기마다 하던 밋업을 월별로 전환했다고 들었는데, 커뮤니티에 공을 들이는 이유가 궁금합니다.

이승민 | 어라이즈에 합류하고 나서 실리콘밸리 본사에 갔는데, 거기서 아주 활동적인 커뮤니티를 많이 봤어요. 업무 끝나고 다른 회사 커뮤니티에 참여해서 배우고 싶은 걸 배우고, 거기서 만든 네트워크로 새로운 사업을 시도해 보기도 하고요. 우리나라도 밋업이 많이 활성화되고 있는 단계인 것 같아요. 저도 밋업에 많이 참가하고, 7월에는 허깅 페이스 코리아 밋업도 있었고요..

조심스러운 표현이긴 한데, 제 역할이 문익점이 아닐까 생각했어요. 어라이즈를 통해서 북미나 글로벌의 어드밴스드된 재밌는 에이전트 유즈 케이스를 많이 접하게 되거든요.

제가 하나의 채널이 돼서 그 유즈 케이스를 한국 사용자분들께 알려 드리고 싶어요. 유즈 케이스라는 게 한번 들으면 "진짜 재밌다"고 생각할 수 있지만, 누가 알려 주기 전에는 그 방향을 상상 자체를 못 하거든요. 오늘 보여 드린 루프 엔지니어링이나 프롬프트 옵티마이제이션도 그런 트렌드의 하나로 계속 소개하고 싶은 기능이에요.

Q. 마지막으로, AI 엔지니어링 쪽에서 일하는 방식이 앞으로 어떻게 달라질까요? 남이 만든 벤치마크가 아니라 스스로 만든 벤치마크를 쌓는 능력이 어떤 위치를 차지하게 될지 궁금합니다.

이승민 | AI 시대에는 어느 직종이 두각을 나타냈다가 금세 사그라지는 걸 많이 봐요. 아까 보여 드린 것처럼 프롬프트 엔지니어가 중요하다고 했지만, 프롬프트 엔지니어링은 몇 년 안에 정복이 됐거든요. 지금 AI 엔지니어라는 타이틀로 랭그래프(LangGraph)나 ADK 같은 걸로 오케스트레이션 레이어(여러 모델과 도구를 지휘하는 층)를 짜 주는 분들이 많은데, 그 부분도 아직 확산은 안 됐지만 루프 엔지니어링으로 상당히 커버될 거예요.

이렇게 계속 지워 나가다 보면 뭐가 남느냐. 취향인 것 같습니다. 취향밖에 안 남더라고요. 취향만이 사람이 가진 고유한 것이고, 취향은 단기간에 만들거나 따라 하기 힘들거든요. 커피 얘기도 했지만, 정말로 실패도 많이 해 봐야 좋은 취향이 생기는 거예요.

그래서 탐구의 방향이 자기 취향으로 가야 해요. 도메인으로 봤을 때 나는 금융 쪽에 취향이 있는지, 의료인지, 법률인지. 내가 만들고 싶은 에이전트와 나의 취향, 이게 결정된 다음에는 어라이즈든 다른 도구든 통해서 가시성을 확보하고, 허깅 페이스를 보면서 업계에서 앞서 나가는 사람들이 데이터셋을 어떻게 구성하고 쓰는지 공부하고, 내 데이터셋을 고유하게 만들어 가는 거죠. 스텝 바이 스텝으로 진화를 거듭하면 1인 기업으로도 충분히 성공할 수 있는 비즈니스를 만들어 낼 수 있을 거라고 생각해요.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의  뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]