AX Engineer로 방향을 바꾸고 싶다고 생각했지만, 처음에는 무엇부터 준비해야 할지 잘 몰랐다. Agent, RAG, MCP 같은 기술을 하나씩 시험하고는 있었지만 이것들을 실제 문제와 어떻게 연결해야 할지는 여전히 막연했다.
그러던 중 AX 인재전쟁 해커톤을 알게 됐다. 준비가 충분했던 것도 아니고 만들고 싶은 것이 정해져 있던 것도 아니었다. 그래도 이런 기회가 생겼으니 일단 참가해 보자는 마음으로 시작했다.
끝나고 나서야 규모를 알았다
해커톤에는 여섯 기업이 각자의 문제를 공개했고, 참가자는 공개 문서를 근거로 문제를 좁혀 Codex 플러그인을 만드는 방식이었다. 여기서 플러그인은 AI가 아무 답이나 만들게 하는 기능이 아니라, 정해진 자료와 절차를 바탕으로 특정 작업을 반복할 수 있게 만든 작은 도구에 가깝다.
행사가 끝난 뒤 받은 결산 리포트에서 참가자가 5,341명이었고, 최종 본선 진출자는 60명이었다는 것을 알았다. 시작할 때는 규모를 생각할 여유가 없었다. 주어진 문제를 읽고 무엇을 만들지 정하는 것만으로도 바빴다.
나는 여섯 기업 중 마이리얼트립, 무신사, 카카오페이증권 세 곳에 제출했다.
하나만 잘 만들면 됐는데 세 개를 만들었다
처음부터 세 개를 만들 계획은 아니었다. 하나를 끝내고 나니 다른 기업은 어떤 문제가 있는지 궁금해졌다. 기업마다 공개한 자료와 사용자가 겪는 문제가 달랐고, 각각 다른 방식으로 풀어보고 싶었다. 욕심이 났다는 말이 가장 정확하다.
대신 세 과제에서 지키려고 한 기준은 같았다.
- 공개 문서로 확인할 수 있는 내용만 사용한다.
- AI가 정답을 대신 만들기보다 사람이 확인할 부분을 찾게 한다.
- 구현하지 못했거나 확인하지 못한 범위를 숨기지 않는다.
- 같은 입력을 다시 넣었을 때 같은 결과를 확인할 수 있게 테스트한다.
마이리얼트립: 오류가 난 뒤 문서를 찾는 일을 줄이고 싶었다
마이리얼트립 개발자센터를 읽다 보니 Open API를 연결할 때 놓치기 쉬운 조건이 여러 곳에 흩어져 있었다.
투어 검색은 페이지가 1부터 시작하지만 숙소와 항공은 0부터 시작한다. 응답에서 페이지 크기를 나타내는 필드도 다르다. 항공 검색의 파라미터 이름은 fromCityCode, toCityCode지만 실제로는 도시 코드가 아니라 공항 코드를 넣어야 한다. 링크 길이 제한, 인증 헤더 형식과 호출 횟수 제한도 각각 확인해야 했다.
개발하다 오류가 난 뒤 FAQ를 뒤져 원인을 찾는 대신, 코드 작성이나 리뷰 단계에서 미리 알려주는 편이 낫겠다고 생각했다. 그래서 공개 문서에서 확인한 10개 항목을 검사하는 MRT API Doctor를 만들었다.
잘못된 연동 코드를 넣으면 문제가 있는 줄과 이유, 수정 방향, 문서 원문을 함께 보여준다. 실제 API 키가 없어도 실행할 수 있도록 나쁜 예제와 수정된 예제를 만들었고, 연동 코드 검사 14개와 문서 인용 검증 5개를 합쳐 19개 테스트를 작성했다.
무신사: 상품을 올리기 전에 한 번 걸러볼 수 없을까
무신사 기술 블로그에는 2024년 당시 주요 속성이 모두 채워진 의류 상품이 10% 미만이었고, 후드 티셔츠에 스웨트셔츠 태그가 들어가는 것 같은 오입력 사례가 소개돼 있었다.
상품을 등록한 뒤 반려되거나 검색 품질에 문제가 생기기 전에, 공개 기준으로 확인할 수 있는 항목만 먼저 살펴보면 도움이 될 것 같았다.
그래서 상품 속성, 태그, 사이즈와 상품정보제공고시 누락을 확인하는 Commerce Listing Preflight를 만들었다. 상품정보제공고시 항목은 국가법령정보센터 원문에서 직접 확인했고, 사이즈 값이 역전되거나 후드 티셔츠에 맞지 않는 태그가 들어간 예시도 테스트에 넣었다.
무신사의 실제 등록 화면이나 내부 기준을 안다고 가정하지 않았다. 공개 자료로 만든 검수용 입력 형식이라는 점을 문서에 명시했다. 총 17개 테스트를 작성했고, 이 과제는 본선 후보로 선정됐지만 최종 본선 진출로 이어지지는 않았다.
카카오페이증권: 그럴듯한 답변이 잘못된 확신을 줄 수 있었다
초보 투자자가 “지금 사도 될까요?”라고 물었을 때 AI가 “사셔도 됩니다”라고 답하면 자연스럽게 들릴 수 있다. 하지만 투자 목적과 기간, 손실을 감당할 수 있는지 확인하지 않은 채 결론부터 내리는 답변은 위험하다.
추천 챗봇을 만드는 대신 답변이 사용자 대신 결정을 내리고 있지는 않은지 확인하는 Investment Answer Gate를 만들었다.
직접적인 매수·매도 권유, 수익을 보장하는 표현, 사용자 조건 누락, 위험 설명과 공개 근거 URL 누락을 검사한다. 이 도구가 투자 조언이나 준법 판정을 하는 것은 아니며, 상담·안내 답변 초안을 사람이 검토하기 전에 살펴보는 품질 확인 도구라는 점도 분명히 적었다.
제출 당시에는 정상 답변과 문제가 있는 답변, JSON 입력을 확인하는 7개 테스트를 만들었다.
AI가 만든 인용문을 그대로 믿을 수 없었다
세 과제를 만들면서 가장 기억에 남은 일은 기능 구현보다 자료를 확인하는 과정에서 생겼다.
AI가 공개 문서의 여러 문장을 자연스럽게 이어 붙여 하나의 인용문처럼 작성한 적이 있었다. 처음 읽었을 때는 그럴듯했다. 원문을 열어보니 실제로는 그런 문장이 없었다. 이후 모든 인용을 원문과 다시 비교했고, 문서에서 직접 확인할 수 있는 문장으로 바꿨다.
후보 아이디어를 고르는 과정에서도 비슷한 일이 있었다. AI가 한 후보를 “비공개 정보를 추측해야 한다”는 이유로 낮게 평가했는데, 같은 기준을 적용하면 자신이 1순위로 추천한 후보도 성립하지 않았다. 왜 같은 기준을 다르게 적용했는지 다시 묻자 논리의 빈틈이 드러났다.
AI가 작성한 코드만 검토할 것이 아니라, AI가 문제를 고르고 설명하는 논리도 사람이 다시 확인해야 한다는 것을 이때 분명하게 느꼈다.
결산 리포트에서 뒤늦게 확인한 기준
행사가 끝난 뒤 주최 측이 공개한 결산 리포트를 읽었다.
예선에서 점수를 가른 기준은 핵심 기능이 실제로 동작하는지, 출처를 확인할 수 있는지, 문제를 충분히 좁혔는지, 한계를 솔직하게 적었는지, AI에게 맡길 일을 설계했는지, 다른 사람도 다시 실행할 증거가 있는지 등이었다.
처음부터 이 평가 항목을 알고 만든 것은 아니었다. 다 만들고 나서 읽어보니 내가 세 과제에서 신경 썼던 부분과 많이 겹쳤다. 기능 수를 늘리기보다 범위를 줄이고, 공개 근거와 테스트를 남긴 선택이 틀리지 않았다는 생각이 들었다.
끝나고 나서 알게 된 것
최종 본선에는 진출하지 못했다. 그래도 시작할 때 막연했던 질문에는 답을 얻었다.
내가 관심 있는 일은 AI에게 더 많은 답을 만들게 하는 것보다, AI가 만든 결과를 사람이 확인하고 실제 업무에 사용할 수 있는 형태로 바꾸는 일에 가까웠다.
세 제출물은 AX Evidence Gates 저장소에 공개했다. 제출 당시 43개였던 테스트는 금융 답변 입력 검사와 LangGraph 기반 사람 검토 흐름을 추가하면서 현재 49개가 됐다. 문제가 발견되면 사람이 승인·수정·반려하고, 수정한 답변을 다시 검사하는 과정까지 연결했다.
이때 정리한 문제 정의, 공개 근거와 사람의 최종 판단이라는 기준은 이후 AX Doctor를 설계할 때도 이어졌다. 비슷한 시기에 만들기 시작한 Agent Bridge도 해커톤 이후 테스트와 문서를 보강하며 공개 도구로 다듬었다.
해커톤 하나로 AX Engineer가 됐다고 생각하지는 않는다. 다만 무엇을 더 공부해야 하는지만 보던 상태에서, 어떤 문제를 어떤 기준으로 풀고 싶은지는 이전보다 분명해졌다.