Yidu Song

·Reflections·3 min read

카카오 X 한국정보과학회 에이전트 경진대회 회고록

처음 나간 AI 에이전트 대회에서 겪은 일과 배운 점

들어가며

작년 12월, 카카오와 한국정보과학회(KSC 2025)가 함께 연 AI 에이전트 경진대회에 나갔다. 처음에는 제안서를 만들어 제출해 보는 경험이라도 해 보자는 생각으로 지원했다. 그런데 의도치 않게 본선에 올랐고, 장려상까지 받았다.

이 글은 그 과정에서 겪은 일과 느낀 점을 정리한 기록이다.

AI 에이전트 경진대회 본선장. 빈 책상들 너머 스크린에 '여러분의 상상력으로, AI 에이전트의 새로운 챕터를!'이라는 문구가 떠 있다
KSC 2025 AI 에이전트 경진대회 본선장

주제 선정

대회 주제는 '일상을 혁신할 에이전트'였다. 일상이라는 범위가 워낙 넓어서, 자칫하면 주제를 고르다가 시간을 다 쓸 것 같았다.

그래서 큰 주제를 먼저 정하고 점점 좁혀 나갔다. 평소 관심 있던 협상 에이전트에서 중고거래 에이전트로, 다시 중고거래의 정보 불균형을 해결하는 에이전트로 좁혔다.

돌이켜 보면 당연한 방식이지만, 처음부터 정답을 찾으려 했다면 시간만 날렸을 것 같다. 처음부터 모든 걸 계획하기보다 큰 덩어리에서 조각하듯 깎아 나가는 편이 훨씬 효율적이었다. 평소에 AI 말고도 경제나 인문학 같은 분야를 두루 기웃거려 두면 이런 과정이 훨씬 쉬워지겠다는 생각도 들었다.

제안서 작성

대회는 예선에서 제안서를 평가하고, 본선에서 실제로 구현하는 방식이었다. 우리 팀은 예선에서 매우 긍정적인 평가를 받았다.

제안서에서 가장 신경 쓴 건 서사였다. 사회나 특정 산업이 겪는 페인 포인트를 정의하고, 기존 방법론의 구조적 한계를 짚은 뒤, 우리가 무엇을 제안하는지, 그리고 이 솔루션이 적용되면 어떤 정량적·정성적 효과가 기대되는지를 하나의 흐름으로 엮었다.

특히 초반 문제 정의에서는 여러 객관적인 지표로 문제가 실제로 존재하고 해결할 가치가 있다는 걸 보여 주는 데 공을 들였다. 통계를 나열하기보다는 에세이를 쓴다는 마음으로 그 숫자들에 서사를 붙였다. 쓰는 내내 내가 심사위원이라면 이 논리에 설득될까를 계속 물었다.

구현

구현은 이번 대회에서 가장 뼈아픈 부분이자, 가장 많이 배운 부분이었다.

우리는 NegotiationArena 기반의 LLM 에이전트 두 개로 동작하는 시스템에 룰 베이스 검증기를 붙여, 협상 과정의 안전성을 확보한다는 논리로 구현했다. 그런데 현장에서 다른 팀들을 보니 Graph RAG를 붙이거나 실제로 돌아가는 서비스를 만들어 오는 등 수준이 높았다.

우리는 유일하게 학부생으로만 이루어진 팀이었고 대학원생 위주의 팀들과 경쟁했지만, 대회는 그런 사정을 봐주지 않는다. 결국 기술적 깊이가 얕았다는 게 가장 큰 패착이었다. 다시 한다면 동작하는 프로토타입에서 멈추지 않고, 최신 논문의 협상 모델을 쓰거나 실제 채팅 서비스와 연동해 유저 만족도를 평가하는 등 깊이를 더하고 싶다.

본선

본선은 여수 엑스포 컨벤션 센터에서 카카오 관계자와 다른 팀들 앞에서 발표하는 자리였다. 두 번째 순서로 발표해서, 일찍 끝내고 비교적 편한 마음으로 다른 팀들의 발표를 볼 수 있었다. 보면서 느낀 건 발표 준비의 밀도와 PPT·데모 영상의 완성도가 결과에 큰 영향을 미친다는 점이었다.

사실 이번 대회에서 일정 관리를 제대로 하지 못했다. PPT 제작이 예상보다 훨씬 늦어져 마감 직전까지 붙잡고 있었고, 그 탓에 발표 대본을 쓰고 연습할 시간이 없었다. 새벽까지 준비해서 갔지만, 막상 무대에 서니 머리가 새하얘졌다. 결국 대본을 그대로 읽었고, 그게 정말 아쉬웠다.

상위권 팀들은 기술적 깊이만큼이나 청중을 설득하는 데에도 공을 들였다. 깔끔한 슬라이드는 물론이고, 데모 영상에 내레이션을 넣거나 영상을 멈춰 가며 설명하는 등 어떻게 전달할지 고민한 흔적이 보였다.

내 논리가 아무리 좋아도 상대에게 전달되지 않으면 없는 것과 같다는 걸 이때 느꼈다. 다음에는 마감을 최소 이틀은 앞당겨 잡고, 연습할 시간을 따로 떼어 두려고 한다. 평소 팀플에서도 발표를 더 자주 맡아 봐야겠다는 생각이 들었다.

팀장 역할

대회를 준비하다 보니 팀원 간 실력 차이, 일정 차이, 물리적인 시간 부족 같은 예상치 못한 변수가 계속 생겼다. 그러면서 팀장이 할 일은 팀원을 탓하는 게 아니라, 어떤 상황에서도 프로젝트가 굴러가도록 규칙과 시스템을 설계하는 것이라는 걸 깨달았다.

프로젝트 팀장은 처음이라 미숙한 점이 많았다. 처음에는 역할을 나누고 깃 브랜치와 커밋 메시지 규칙까지 정해 뒀으니 알아서 잘하겠지 하고 막연히 믿었다. 하지만 규칙만 정해 두고 챙기지 않는 건 방임에 가까웠다.

가장 중요했던 건 꾸준히 상황을 확인하고 구체적인 마일스톤을 제시하는 일이었다. 팀원 각자가 어디서 막혔는지 수시로 확인하고, 전체 일정이 흔들리지 않게 중간 목표를 분명히 짚어 줘야 했다. 결국 팀장의 역할은 일을 나누는 데서 끝나지 않고, 개개인의 변수가 프로젝트 전체의 리스크로 번지지 않게 피드백 루프를 만드는 것이었다.

다음에 팀장을 맡으면 팀원의 자율성은 존중하되, 그 과정이 시스템 안에서 투명하게 관리되고 있는지부터 챙기려고 한다.

마치며

처음에는 제안서만 내 보자는 생각이었는데, 의도치 않게 본선까지 갔다. 결과도 좋았지만, 준비하면서 내가 부족한 점을 많이 알게 된 게 더 뜻깊었다. 다음에는 이번에 깨달은 점을 살려서 더 나은 결과를 내고 싶다.