본문
최근에 LinkedIn, GitHub, 홈페이지와 블로그를 한꺼번에 놓고 보았다.
각각에는 나름 열심히 살아온 흔적이 있었다. LinkedIn에는 경력이 있고, GitHub에는 그동안 만든 코드가 있고, 홈페이지에는 논문과 프로젝트가 있다. 블로그에는 대학원 생활부터 이런저런 생각들이 쌓여 있다.
그런데 묘하게도 네 곳이 지금의 같은 사람을 가리키고 있지는 않았다.
LinkedIn은 과거의 이력을 보여주고, GitHub은 한동안 멈춘 프로젝트가 많고, 홈페이지는 논문 목록에 가깝다. 블로그에는 내가 무슨 생각을 하는지는 있지만, 요즘 어떤 기술적 질문을 붙잡고 있는지는 잘 보이지 않는다.
퍼스널 브랜딩을 해야겠다는 생각은 여기서 시작했다. 그렇다고 갑자기 “AI 전문가가 알려주는 최신 기술” 같은 글을 쓰고 싶지는 않았다. 이미 공개된 발표를 요약하면서 아는 척하는 것도 영 내키지 않고, 회사에서 하는 일을 내 성과처럼 꺼내놓는 것은 더더욱 안 된다.
그럼 회사 일을 말하지 않고도, 내가 어떤 연구자이고 엔지니어인지를 어떻게 보여줄 수 있을까?
내가 내린 답은 공개 모델을 직접 실험하는 것이었다.
1. 소속이 아니라 방식으로 증명하기
여기서 말하는 독립 실험자는 소속이 없는 연구자라는 뜻이 아니다.
실험에 사용하는 모델, 코드와 데이터가 공개되어 있고, 개인 장비와 개인 계정으로 실행하며, 결과의 근거를 소속이 아니라 재현 가능한 조건에서 찾는다는 뜻에 가깝다.
새로운 모델이 나오면 보통 benchmark 점수, context length, token efficiency와 reasoning 성능이 함께 발표된다. 모두 중요한 숫자다. 그런데 실제 사용자는 그다음 질문을 만나게 된다.
•
내 환경에서도 같은 경향이 나타나는가?
•
한국어 지시와 문서에서도 잘 작동하는가?
•
한 번의 성공이 아니라 반복해서 성공하는가?
•
품질을 얻기 위해 token, latency와 memory를 얼마나 더 쓰는가?
•
어디에서 어떤 모양으로 실패하는가?
이 질문은 소개 글만으로는 답하기 어렵다. 모델 버전과 조건을 고정하고, 직접 실행하고, 여러 번 측정해야 한다.
앞으로 쓰고 싶은 것은 모델 전체에 점수를 매기는 종합 순위표가 아니다. 공개된 주장이나 실용적인 질문 하나를 골라 작은 실험으로 바꾸는 글이다. 공식 결과와 비슷하면 어떤 조건에서 비슷했는지 기록하고, 다르면 내 실험이 잘못되었을 가능성부터 확인한다. 그래도 차이가 남으면 그것도 결과로 남긴다.
2. EXAONE으로 시작하는 이유
Cookbook은 단순한 API 예제를 넘어 structured output, tool calling, agent loop, MCP, RAG, memory, safety와 evaluation까지 연결한다. 특히 동일한 모델과 입력에서 단순 API 호출과 agent harness를 비교하는 평가 스위트가 재미있다.
공개된 reference result도 장점만 나열하지 않는다. schema 준수, 중복 tool call 방지와 빈 응답 복구가 좋아지는 한편, 일부 조건에서는 더 많은 token을 사용하고 반복 성공률이 낮아지는 trade-off도 함께 보인다.
이런 결과를 보면 자연스럽게 다음 질문이 생긴다.
무엇이 좋아졌는가보다, 무엇을 얻기 위해 무엇을 더 지불했는가?
EXAONE으로 시작하는 것은 내가 이 공개 생태계에 비교적 가까워 더 구체적인 질문을 만들 수 있다고 생각하기 때문이다. 그러나 가까이 있다는 사실을 결과의 권위로 쓰지는 않을 생각이다. 오히려 가까운 만큼 실험 조건과 회사 일의 경계를 더 분명하게 적어야 한다.
그리고 EXAONE에만 갇힐 생각도 없다. 같은 데이터와 같은 평가 기준을 적용할 수 있다면 다른 공개 모델도 함께 돌려볼 것이다. 특정 모델을 항상 이기게 만드는 종합 점수보다, 각 모델이 어떤 조건에서 유용하고 어디에서 무너지는지 보는 편이 훨씬 재미있다.
3. 하나의 실험, 네 개의 기록
그동안 블로그와 LinkedIn 중 어디에 글을 써야 할지도 조금 고민했다. 결론은 둘 중 하나를 고르는 것이 아니라, 역할을 나누는 쪽이다.
블로그에는 질문을 고른 이유, 실험 조건, 결과와 실패, 해석과 한계를 긴 글로 남긴다. LinkedIn에는 가장 중요한 질문과 숫자 하나, 차트 한 장, 예상 밖의 실패 하나를 요약하고 전체 글로 연결한다.
GitHub에는 실행 코드, 환경 정보와 공개 가능한 raw result를 둔다. 홈페이지에는 이 실험들을 모아 지금 내가 무엇을 탐구하는지 보여주는 작은 입구를 만든다.
정리하면 이런 구조다.
•
Blog: 생각과 실험의 전체 과정
•
LinkedIn: 결과가 가진 의미와 대화의 시작
•
GitHub: 다른 사람이 다시 실행할 수 있는 증거
•
Homepage: 흩어진 기록을 묶는 포트폴리오
같은 내용을 네 번 복사하는 것은 아니다. 하나의 실험을 서로 다른 깊이의 기록으로 나누는 것이다. LinkedIn에는 앞으로 조금 더 자주 글을 써보려고 한다. 다만 짧게 줄인다고 조건과 한계까지 지워버리지는 않을 생각이다. 숫자 하나가 멋있어 보이려면 그 숫자가 나온 조건부터 적어야 한다.
4. 우선 직접 돌려볼 것들
당장은 다음 질문들이 머릿속에 있다.
1.
EXAONE Cookbook은 깨끗한 환경에서 어디까지 한 번에 재현되는가?
2.
한국어 지시의 길이와 모호성, schema 크기는 JSON과 tool call 실패율을 어떻게 바꾸는가?
3.
agent harness가 높이는 안정성은 추가 token과 latency를 정당화하는가?
4.
한 번의 성공과 pass^k, 즉 반복해서 성공하는 능력은 얼마나 다른가?
5.
K-EXAONE의 tokenizer와 long-context 특성은 실제 한국어 문서에서 어떤 차이를 만드는가?
6.
EXAONE Deep의 reasoning budget과 EXAONE 4.5의 문서 이해 능력은 개인 환경에서 어디까지 재현되는가?
평가 방법도 완전히 새로 만들기보다 공개된 기준을 먼저 활용하려고 한다. tool calling에는 Berkeley Function Calling Leaderboard, 반복 성공에는 τ-bench의 pass^k, 지시 준수에는 IFEval 같은 선행 연구가 있다. 우선 이 기준을 재현한 뒤, 한국어와 개인 사용 환경에 필요한 변수를 하나씩 추가하는 편이 결과를 비교하기 좋다.
모든 실험이 거창할 필요는 없다. 작은 데이터셋과 개인 장비로 시작하더라도 질문이 명확하고 다른 사람이 다시 실행할 수 있다면 충분히 쓸 만한 기록이다.
무엇보다 처음부터 너무 웅장하면 첫 글이 영영 나오지 않는다. 나는 웅장한 계획을 세우는 데 꽤 능숙하고, 계획을 세웠다는 사실에 만족하는 데도 제법 능숙하다. 그러니 이번에는 작게 시작하는 편이 안전하다.
5. 공개하는 것과 공개하지 않는 것
기준은 단순하게 Public in, public out으로 잡았다.
공개된 모델, 코드, 논문과 데이터만 사용한다. 실험은 개인 시간과 개인 장비·계정·비용으로 수행한다. 회사의 비공개 데이터, 코드, 장비, 내부 평가와 앞으로의 계획은 사용하지 않고, 그것을 유추할 만한 단서도 만들지 않는다.
모델과 코드의 정확한 버전, commit, 실행 환경, prompt, sampling 설정과 반복 횟수는 가능한 한 남긴다. 평균값 하나보다 분산과 실패 사례를 함께 공개한다. 표본이 작거나 평가 방법이 허술하면 그것도 적는다.
가설이 틀렸거나 별 차이가 없거나, 재현 자체에 실패해도 버리지 않을 생각이다. 잘되는 데모는 공식 문서에도 많다. 어디에서 왜 안 되었는지가 오히려 다음 사람의 시간을 더 많이 아껴줄 수 있다.
마지막으로 이 기록은 EXAONE을 다루더라도 공식 평가나 공식 홍보가 아니다. 내 소속은 경력의 맥락이지 실험의 근거가 아니다. 결과의 근거는 공개한 코드와 데이터, 조건과 숫자에서 나와야 한다.
6. 첫 번째 기록
첫 실험은 EXAONE Cookbook을 새로운 환경에 설치하고, structured output과 tool calling을 한국어 조건에서 다시 실행하는 것으로 정했다.
설치가 한 번에 끝나면 실제 소요 시간과 환경을 적고, 막히면 막힌 지점부터 적을 것이다. 그다음에는 지시문의 길이, schema 크기와 표현의 모호성을 바꾸면서 성공률, retry 횟수, token과 latency가 어떻게 달라지는지 측정해보려고 한다.
결과가 멋지게 나오면 좋겠다. 별 차이가 없어도 괜찮고, 내 실험 설계가 틀렸다는 결론이 나와도 괜찮다. 대신 무엇을 했고 무엇을 보았는지는 다시 확인할 수 있게 남겨두려고 한다.
결국 만들고 싶은 것은 EXAONE에 관한 좋은 말의 목록이 아니다.
공개된 주장을 질문으로 바꾸고, 질문을 실험으로 바꾸고, 실험의 성공과 실패를 다시 공개하는 사람이라는 기록이다.
일단 첫 번째 환경부터 만들어보자.
이 글에서 언급하는 모든 실험은 공개 자료와 개인 자원으로 수행하는 독립적인 개인 연구입니다. LG AI Research 또는 현 직장의 공식 평가·입장·보증을 의미하지 않습니다. 모델·코드·데이터의 이용 조건은 각 실험 시점의 공식 라이선스를 별도로 확인합니다.