AX 인재전쟁에 지원한 이유
AX 인재전쟁은 유튜브에서 조코딩님의 영상을 통해 처음 알게 되었습니다.
저는 AI-native 조직과 AX에 관심이 많습니다. 단순히 ChatGPT를 잘 사용하거나 업무에 AI 기능 하나를 추가하는 것을 넘어, 조직의 업무 방식 자체를 AI에 맞게 다시 설계하는 것에 관심을 가지고 있었습니다.
그런 점에서 기업이 겪는 문제를 직접 정의하고, 해결책을 프로덕트와 플러그인 형태로 만들어 제출해야 한다는 예선 방식은 처음에는 당황스러우면서도 저와 잘 맞는 방식이라고 생각했습니다.
다만 저는 군 복무 중이었기 때문에 예선을 준비할 수 있는 시간이 약 3일 정도밖에 없었습니다. 원래는 최대 3개의 기업 트랙에 지원할 수 있었지만, 여러 트랙에 어설프게 지원하기보다 하나의 문제를 깊게 파고들기로 했습니다.
그렇게 선택한 곳이 삼일PwC였습니다.
예선: AI를 도입했지만 감사 업무의 병목은 왜 사라지지 않았을까
예선을 준비하면서 가장 먼저 한 일은 회계법인이 실제로 겪고 있는 문제를 찾는 것이었습니다.
조사 과정에서 대형 회계법인들이 AI 챗봇과 내부 플랫폼, 문서 검색 도구 등을 빠르게 도입하고 있지만, 실제 감사 실무에서는 AI의 활용이 문서 검색이나 계약서 초안 작성처럼 개별 기능에 머물러 있다는 내용의 기사를 접했습니다.
오히려 자체 모델을 학습시키기 위해 고객사의 조서와 자료를 정리하고 입력하는 업무가 추가되면서, 실무자의 업무가 기대만큼 줄지 않는다는 문제도 언급되고 있었습니다.
저는 여기서 문제를 다음과 같이 정의했습니다.
회계법인은 감사 업무를 줄이기 위해 AI를 도입했지만, 감사 업무 전체의 흐름을
다시 설계하지 않은 채 개별 기능 단위로 AI를 붙였다.
그 결과 AI는 문서를 검색하거나 초안을 작성하는 보조도구에 머물렀고,
감사 업무의 전체 병목을 해결하지 못했다.
문서를 찾아주는 기능 하나가 빨라진다고 해서 감사 업무 전체가 자동화되는 것은 아닙니다.
감사 업무에서는 고객사로부터 자료를 요청하고, 도착한 자료가 어떤 거래와 관련된 것인지 확인하고, 전표와 증빙을 매칭하고, 필요한 감사절차를 수행한 뒤, 그 결과를 조서로 작성해야 합니다. 자료가 부족하면 다시 고객사에 요청해야 하고, 이 모든 과정에서 감사인이 검토하고 책임져야 합니다.
따라서 저는 AI 기능을 여러 개 만드는 대신, 감사 업무 전체의 워크플로우를 먼저 구조화하고 그 흐름 안에서 AI가 각 업무를 수행하도록 해야 한다고 판단했습니다.
예선에서 만든 제품
최종적으로 제품의 콘셉트를 다음과 같이 정했습니다.
감사 시즌의 전표·증빙·감사절차·조서를 연결하는 실무형 AI 워크플로우
고객사가 제출하는 자료는 Excel, CSV, PDF, 스캔된 PNG 이미지 등 형식이 제각각입니다. 따라서 먼저 문서의 형식과 관계없이 내용을 추출하고, 이를 감사 업무에서 사용할 수 있는 표준 객체로 변환하도록 설계했습니다.
그 위에서 전표와 증빙을 연결하고, 필요한 자료가 모두 제출됐는지 확인하며, 감사절차와 조서 초안까지 연결하는 흐름을 만들고자 했습니다.
전체 구조는 다음과 같습니다.
| 단계 | 주요 기능 |
|---|---|
| 자료 수집 | Excel, CSV, PDF, PNG 등 고객사 제출자료 업로드 |
| 추출·표준화 | 문서 형식과 관계없이 내용을 추출해 표준 객체로 변환 |
| 객체 연결 | 전표, 증빙, 감사절차, 조서, 자료요청 항목을 연결 |
| 완전성 검사 | 필요한 증빙이 모두 제출됐는지 확인 |
| 예외 탐지 | 누락·불일치·매칭 실패 항목 표시 |
| 조서 작성 | 확보된 자료와 수행 절차를 바탕으로 조서 초안 작성 |
| 추가자료 요청 | 부족한 자료가 있으면 고객사 요청 메일 초안 생성 |
| 근거 추적 | 어떤 문서와 데이터를 참고했는지 링크와 흐름으로 표시 |
| 감사인 검토 | 감사인이 근거를 검토하고 최종 판단 및 승인 |
이를 흐름으로 표현하면 다음과 같습니다.
고객사 제출자료
Excel / CSV / PDF / PNG
↓
문서 내용 추출 및 표준화
↓
전표·증빙·감사절차·조서 객체 생성
↓
전표와 증빙 자동 매칭
↓
필수자료 완전성 검사
↓
누락·불일치·예외 항목 탐지
↓
조서 초안 및 보충자료 요청 메일 작성
↓
근거 문서와 판단 흐름 시각화
↓
감사인의 최종 검토·판단이 제품을 기획하며 가장 중요하게 생각한 원칙은 AI가 최종 감사판단을 하지 않는 구조였습니다.
AI는 자료를 추출하고, 매칭하고, 누락을 찾고, 조서와 메일의 초안을 작성할 수 있습니다. 그러나 어떤 항목을 감사상 중요한 예외로 볼 것인지, 감사의견에 어떤 영향을 주는지는 감사인이 판단해야 합니다.
AI가 감사인을 대체하는 것이 아니라, 감사인이 책임져야 하는 업무에 더 집중할 수 있도록 그 앞단의 반복적인 작업을 정리하는 것이 제품의 본질이라고 생각했습니다.
실제 고객 데이터를 확보할 수는 없었기 때문에 GPT를 이용해 전표, 증빙, 계약서, 거래명세서 등의 합성 데이터를 만들었습니다. 이를 GitHub에 업로드하고, 제출된 데이터로 실제 데모가 동작하도록 구현했습니다.
그렇게 예선 제품을 제출했습니다.
문제가 정해져 있지 않은 해커톤은 부실한 해커톤일까
AX 인재전쟁 예선에서 가장 논란이 되었던 부분은 명확한 문제나 데이터셋이 제공되지 않았다는 점이었습니다.
“문제를 알아서 찾고 해결해서 제출하라”는 방식에 대해, 운영이 부실한 것이 아니냐는 반응도 있었습니다. 탈락 이후 본선 진출작을 전부 공개해 달라는 의견도 적지 않았습니다.
물론 참가자 입장에서는 문제 범위와 평가 기준이 더 명확하게 느껴졌다면 준비가 수월했을 것입니다. 하지만 저는 이 방식 자체가 잘못됐다고 생각하지는 않았습니다.
지금은 AI를 통해 코드를 만들고, 화면을 구성하고, 문서를 작성하는 것 자체는 이전보다 훨씬 쉬워졌습니다. 오히려 더 중요한 역량은 다음과 같은 것이라고 생각합니다.
- 어떤 현상을 문제로 볼 것인가
- 그 문제가 실제로 존재한다는 근거는 무엇인가
- 표면적인 증상이 아니라 원인은 무엇인가
- 누구를 위한 문제인가
- 해결책이 실제 업무 흐름을 어떻게 바꾸는가
결국 요구되는 것은 결과물을 빠르게 만드는 사람이 아니라, 문제를 발견하고 정의해 해결 가능한 구조로 바꾸는 Problem Solver에 가깝습니다.
실제로 운영 측 설명에 따르면 예선 제출물의 약 3분의 1은 자신이 정의한 문제의 출처나 근거가 되는 기사, 보고서, 보도자료 등을 명확히 제시하지 못했다고 합니다.
문제를 자유롭게 정할 수 있었다는 것은 아무 문제나 상상해서 제출해도 된다는 뜻이 아니라, 문제의 존재부터 스스로 증명해야 한다는 뜻이었습니다.
저는 오히려 이 지점이 예선에서 중요했다고 생각합니다.
생각지도 못했던 본선 진출
예선 제출 후 약 일주일 정도가 지났을 때였습니다.
사지방에서 연등을 하던 중 본선 진출 메일을 확인했습니다. 기대하지 않았던 결과였기 때문에 기쁘면서도 당황스러웠습니다.
본선 전날까지 별도의 프로덕트를 미리 만들 수는 없었습니다. 어떤 문제가 나올지, 어떤 데이터가 제공될지 알 수 없었기 때문입니다.
대신 GPT와 한 번의 긴 대화를 진행했습니다.
삼일PwC 트랙의 문제는 유튜브를 통해 일부 공개된 내용을 보면 Trusted CEO Agent를 만드는 것이었습니다. 결국 CEO가 여러 조직의 정보를 종합해 더 빠르고 신뢰할 수 있는 의사결정을 내리도록 돕는 에이전트가 필요하다고 생각했습니다.
저는 조직에서 의사결정이 느려지는 이유를 다음과 같이 가정했습니다.
각 부서에는 그 조직에서만 통하는 암묵지와 판단기준이 존재합니다. 같은 사건이라도 영업팀은 주문으로 보고, 생산팀은 생산능력으로 보며, 재무팀은 매출과 현금으로 봅니다. 데이터는 존재하지만 서로 다른 시스템과 시간축에 흩어져 있어 CEO가 하나의 맥락으로 이해하기 어렵습니다.
그래서 본선에서 데이터가 제공되면 먼저 회사와 부서의 행위를 정의하고, 단순한 숫자를 사건과 관계로 변환해야 한다고 생각했습니다.
날짜를 사건으로 바꾸고, 사건의 순서를 인과가설로 바꿔야 한다.
누가 어떤 결재를 올렸는지, 어떤 원료가 어느 생산 배치에 사용됐는지, 그 배치가 언제 출하되고 언제 고객 클레임으로 이어졌는지를 하나의 흐름으로 볼 수 있어야 한다고 생각했습니다.
그 정도의 방향성만 정리한 뒤, 다음 날 새벽 4시에 일어나 첫차에 가까운 KTX를 타고 서울로 향했습니다.
본선: 3시간 안에 CEO Agent 만들기
본선은 오전 10시에 시작해 오후 1시까지 제출해야 하는 3시간짜리 해커톤이었습니다.
주어진 문제를 요약하면 다음과 같습니다.
Aurora Holdings의 CEO가 두 자회사에 흩어진 자료를 종합해, 5일 뒤 이사회에서 Top 3 Agenda와 90일 Action Plan, 가용자금 300억원의 활용 방향을 제시할 수 있도록 Trusted CEO Agent를 만들어라.
Aurora Holdings는 화장품 제조사인 Corevia Cosmetics와 유통사인 Masil Commerce를 자회사로 두고 있었습니다. 여기에 더마 원료기업 Celtonic Labs의 인수까지 검토하고 있었습니다.
문제와 함께 거의 60개에 가까운 데이터와 문서가 주어졌습니다. 주문, 출하, 생산능력, 품질검사, 원료 로트, 고객 클레임, 마케팅 캠페인, 반품, 재고, 발주, 현금전망, 계약, 투자 검토자료 등이 모두 섞여 있었습니다.
시나리오와 데이터를 분석하면 다음과 같은 충돌이 나타났습니다.
- 출하는 정상인데 신규 발주는 감소하고 있었습니다.
- 내부 검사에서는 규격을 통과했지만 고객 단계에서는 불량 클레임이 발생했습니다.
- GMV, 즉 주문금액은 증가했지만 실제 현금은 감소했습니다.
- 공식 현금전망에서는 문제가 없었지만, 확정된 발주 지급일을 반영해 재계산하면 Covenant 기준 아래로 내려갈 가능성이 있었습니다.
제공된 데이터에는 단순한 오류뿐 아니라 서로 다른 종류의 충돌이 존재했습니다.
- 실제 계산 결과가 문서의 주장과 다른 경우
- 서로 다른 지표가 상반된 신호를 주는 경우
- 하나의 원인가설을 지지하면서 동시에 반박하는 데이터가 존재하는 경우
- 공식 전망과 확정된 일정의 반영 범위가 다른 경우
이를 한 문장으로 표현하면 다음과 같습니다.
성과가 좋아 보이는 문서와 실제 데이터를 기반으로 한 계산 결과가 일치하지 않았다.
CEO는 각 부서의 보고서 중 하나를 선택해 믿는 것이 아니라, 어떤 데이터와 계산을 기준으로 판단해야 할지 확인해야 했습니다.
그런데 문제를 제대로 이해하기 전에 만들기 시작했다
문제는 시간이었습니다.
약 60개의 데이터를 사람이 하나씩 열어보고 연결하기에는 3시간이 너무 짧았습니다. 문제를 읽고 데이터를 분석하는 데만 30분 이상을 사용해야 했고, 그 이후에는 프로덕트를 설계하고 실제 화면까지 구현해야 했습니다.
저는 모든 데이터를 AI에게 전달하고 다음을 요청했습니다.
- 데이터 사이에 어떤 충돌이 존재하는가
- 시나리오의 주장과 실제 계산은 어떻게 다른가
- CEO가 중요하게 봐야 할 의사결정은 무엇인가
- 어떤 문제를 Primary Issue로 선택해야 하는가
AI는 빠르게 여러 시사점을 정리해 줬습니다. 저는 그 결과를 바탕으로 문제를 이해하고 프로덕트를 만들기 시작했습니다.
당시에는 이것이 AI를 잘 활용하는 방법이라고 생각했습니다. 제한된 시간 안에 사람이 보기 어려운 양의 데이터를 AI로 분석하고, 사람이 제품 방향을 결정한다고 생각했습니다.
하지만 돌이켜보면 저는 데이터를 분석하는 일을 AI에게 맡긴 것에 그치지 않고, 문제를 바라보는 프레임 자체도 AI가 제시한 해석에 상당 부분 의존하고 있었습니다.
AI가 발견한 숫자가 맞는지 일부를 다시 검증했지만, 시간이 부족해 전체 흐름을 직접 이해하지 못했습니다. 그러다 보니 “왜 이 문제가 중요한가”를 제 언어로 설명하기보다, AI가 정리한 문제와 시사점을 제품에 옮기는 데 급급해졌습니다.
AI를 이용해 문제를 빠르게 이해하려 했지만, 어느 순간부터는 제가 AI를 활용한 것이 아니라 AI가 정리한 해석을 따라가며 제품을 만들고 있었습니다.
본선에서 만든 Aurora Decision Trace
제가 선택한 문제는 단순히 문서와 계산이 다르다는 것이 아니었습니다.
조금 더 근본적으로 다음과 같이 접근했습니다.
데이터는 많지만 품질, 생산, 영업, 재무, 마케팅 데이터가 서로 다른 시스템과 시간축에 흩어져 있어 하나의 CEO 의사결정으로 연결되지 않는다.
예를 들어 C-201이라는 대형 신규 고객 입찰에 참여할지를 결정하려면 영업 데이터만 봐서는 안 됩니다.
- 고객이 요구하는 생산물량
- 기존 라인의 잔여 생산능력
- 더마 제품의 품질 문제
- 원료 로트와 생산 배치
- 기존 고객과 Masil에 공급해야 할 물량
- 설비투자 금액과 리드타임
- 입찰계약의 지연·회수 책임
을 함께 봐야 합니다.
그래서 저는 여러 부서의 데이터를 하나의 의미세계로 연결하고, CEO가 특정 안건을 선택하면 관련된 사실, 계산, 가설, 반대증거, 미확인 정보와 승인조건을 확인할 수 있는 제품을 만들었습니다.
전체 구조는 다음과 같았습니다.
부서별 데이터·문서
품질 / 생산 / 영업 / 재무 / 마케팅 / 계약
↓
데이터 표준화 및 객체 매핑
고객 / 제품 / 원료 / 배치 / 계약 / 캠페인 / 현금
↓
정적 온톨로지
회사·부서·고객·제품·공급사·승인권한
↓
동적 이벤트
원료 입고·생산·출하·클레임·발주·현금지급
↓
계산 및 규칙
불량률·생산 부족량·공헌이익·현금전망·승인조건
↓
Decision Case
대안·경쟁가설·지지근거·반대증거·Unknown
↓
CEO Agenda Dashboard
현재 권고·결정기한·자금 영향·필요 승인
↓
Scenario Update
새로운 정보 입력
↓
Decision Diff
이전 판단과 변경된 판단 비교
↓
Human Approval
CEO·이사회·품질위원회 최종 승인첫 화면에서는 CEO가 90일 안에 판단해야 할 Top 3 Agenda를 확인할 수 있도록 했습니다. 특정 안건을 선택하면 관련된 부서의 데이터와 경쟁가설, 반대증거, 대안을 비교할 수 있었습니다.
또한 새로운 정보가 들어오면 어떤 가설이 강화됐는지, 기존 권고가 왜 변경됐는지, 후속 Action과 승인자가 어떻게 달라졌는지를 Decision Diff로 보여주도록 설계했습니다.
제가 중요하게 생각했던 것은 AI가 원인을 함부로 단정하지 않는 것이었습니다.
예를 들어 특정 원료 로트를 사용한 문제 배치가 발견됐지만, 같은 원료를 사용한 정상 배치도 존재했습니다. 따라서 “원료가 원인이다”라고 결론내리는 대신 다음 가설을 함께 보여주도록 했습니다.
- 원료 자체의 문제
- 특정 생산공정의 문제
- 고객별 사용환경이나 관찰기간의 차이
- 원료와 공정이 결합된 복합 원인
그리고 각 가설의 지지 근거뿐 아니라 반대증거와 미확인 정보를 함께 표시했습니다.
방향 자체는 문제 요구사항과 맞았습니다. 문제에서도 최소 두 가지의 합리적인 가설이나 의사결정 대안을 비교하고, 결론을 바꾸는 조건을 제시하라고 요구했기 때문입니다.
“그래서 제가 CEO라면, 저한테 뭘 팔겠다는 거예요?”
문제는 발표였습니다.
저는 심사위원에게 프로덕트가 어떤 상황에서 CEO에게 어떤 도움을 주는지 먼저 설명했어야 했습니다.
예를 들어 다음처럼 말할 수 있었습니다.
“이 에이전트는 각 부서의 보고와 실제 계산이 충돌할 때, 어떤 원천 데이터와 가정에서 차이가 발생했는지를 추적하고, CEO가 선택해야 할 대안과 결론이 바뀌는 조건을 보여줍니다.”
하지만 실제 발표에서는 Aurora의 데이터가 왜 사일로되어 있는지, 각 부서가 어떻게 다른 세계관을 가지고 있는지, 왜 의미체계 통합이 필요한지를 길게 설명했습니다.
제가 문제를 어떻게 바라봤는지를 설명하는 데 집중한 나머지, 정작 제품을 사용하는 CEO가 무엇을 얻게 되는지를 명확히 전달하지 못했습니다.
결국 심사위원 한 분이 다음과 같이 질문했습니다.
“그래서 제가 CEO라면, 저한테 뭘 팔겠다는 거예요?”
그 질문을 듣는 순간 아차 싶었습니다.
저는 문제를 설명하고 있었지만, 제품을 설명하고 있지 않았습니다.
제품이 어떤 잘못된 계산을 찾아내는지, 어떤 데이터를 다시 계산하는지, 그 결과 CEO의 어떤 결정이 달라지는지를 보여줬어야 했습니다.
하지만 저는 문제의 근본 원인을 설명하는 데 너무 많은 시간을 사용했습니다. “데이터 사일로”, “부서별 세계관”, “의미 통합”이라는 표현은 틀리지 않았지만, CEO의 구체적인 업무와 연결하지 못하면 일반론처럼 들릴 수밖에 없었습니다.
“저도 Codex를 쓰는데, 프롬프트만 주면 똑같이 만들 수 있지 않나요?”
또 다른 심사위원분은 다음과 같이 질문했습니다.
“저도 Codex를 쓰는데, 저도 똑같이 프롬프팅만 주면 만들 수 있는 것 아닌가요?”
당시에는 카메라 촬영과 마이크까지 진행되고 있었고, 예상하지 못한 질문을 받자 머리가 순간 하얘졌습니다. 제대로 답하지 못하고 의미 없는 말을 이어갔던 것 같습니다.
하지만 대회가 끝난 뒤에는 이 질문이 가장 오래 남았습니다.
처음에는 “내 프로덕트에 해자가 없다는 뜻인가?”라고 생각했습니다. 동시에 제가 실제로 제품을 이해하고 주도한 것이 아니라, AI에게 프롬프트를 주고 만들어진 결과물을 들고 온 것처럼 보였다는 의미이기도 했습니다.
실제로 제 제품은 Claude Code나 Codex를 통해 빠르게 구현됐습니다. 하지만 코드가 AI로 생성됐다는 사실 자체가 문제는 아니라고 생각합니다.
중요한 것은 다음 질문에 답할 수 있느냐는 것입니다.
- 왜 이 문제를 선택했는가
- 어떤 데이터 충돌을 직접 확인했는가
- 어떤 계산은 코드로 고정했고 어떤 판단은 LLM에 맡겼는가
- 왜 이 객체와 관계를 설계했는가
- 어떤 가정이 들어갔는가
- 다른 사람이 같은 프롬프트를 입력해도 만들 수 없는 판단구조는 무엇인가
저는 그 질문에 충분히 답할 준비가 되어 있지 않았습니다.
프로덕트의 해자는 코드의 양이나 화면의 완성도가 아니라, 문제를 이해한 사람이 설계한 데이터 모델, 계산 규칙, 검증 방식, 업무 흐름과 판단 기준에서 나와야 했습니다.
그런데 저는 그 핵심을 심사위원에게 보여주지 못했습니다.
지금 다시 만든다면 무엇을 다르게 할까
수상자의 발표를 보며 가장 인상 깊었던 것은 에이전트의 구조가 매우 명확했다는 점입니다.
제품은 다음 네 단계로 나뉘어 있었습니다.
Raw Data
→ Calculation
→ Conclusion
→ ReportCEO는 각 섹션을 직접 확인할 수 있었고, 별도의 패널에서는 하나의 보고서와 결론이 어떤 원천 데이터에서 시작됐는지를 그래프로 추적할 수 있었습니다.
이 구조가 좋았던 이유는 단순합니다.
결론을 설명하는 것이 아니라 결론이 만들어진 과정을 증명했기 때문입니다.
저는 온톨로지를 통해 여러 부서의 의미를 연결하고, 경쟁가설과 반대증거를 표현하려고 했습니다. 그 방향은 잘못되지 않았습니다. 하지만 온톨로지는 제품의 전면이 아니라 Raw Data에서 CEO 보고까지 연결하는 내부 구조로 사용했어야 했습니다.
다시 만든다면 다음과 같이 구성할 것 같습니다.
1. Raw Data
어떤 문서와 데이터 행을 사용했는지 보여줍니다.
- 출처 파일
- 기준일
- 데이터 소유 부서
- 사용한 컬럼
- 데이터의 상태
- 사실·서술·규칙 구분
2. Calculation
LLM이 아닌 코드와 공식으로 계산합니다.
- 생산 부족량
- 불량률
- 실제 공헌이익
- Real ROAS
- 확정 발주를 반영한 현금전망
- Covenant 하회 여부
계산식과 사용한 데이터, 가정을 모두 표시합니다.
3. Conclusion
계산 결과를 CEO 의사결정으로 변환합니다.
- 가능한 대안
- 경쟁가설
- 지지 근거
- 반대증거
- 미확인 정보
- 결론이 바뀌는 조건
- 현재 권고
4. Report & Action
CEO가 실제로 사용할 수 있는 결과를 만듭니다.
- 이사회 1페이지 보고
- 90일 Action Plan
- 300억원 집행·보류 방향
- 담당 부서
- 완료기한
- 필요한 승인
그리고 보고서의 각 문장을 클릭하면 어떤 Raw Data와 계산, 규칙을 거쳐 만들어졌는지 역추적할 수 있도록 만들 것입니다.
온톨로지는 이 네 단계를 연결하는 역할을 합니다.
Raw Data
원료·배치·클레임·생산능력·현금
↓ 온톨로지 관계
Calculation
불량률·부족량·공헌이익·현금전망
↓ 규칙과 Boundary
Conclusion
가설·대안·현재 권고
↓ 승인체계
Report & Action
CEO·이사회·품질위원회 상신이렇게 구성했다면 “데이터 사일로를 해결합니다”라는 추상적인 설명 대신, 다음과 같이 말할 수 있었을 것입니다.
“이 에이전트는 문서의 주장과 실제 계산이 충돌할 때 원천 데이터를 다시 계산하고, 어떤 결론이 더 타당한지와 결론을 바꾸는 조건을 CEO에게 보여줍니다.”
AI를 많이 사용한 것과 AI에 끌려다니는 것은 다르다
이번 대회에서 가장 크게 배운 점은 AI를 많이 사용했다고 해서 AI-native하게 일한 것은 아니라는 점입니다.
AI-native하게 일한다는 것은 모든 분석과 개발을 AI에게 맡기는 것이 아닙니다.
AI가 많은 데이터를 빠르게 읽고 가설을 만들어 줄 수는 있지만, 무엇이 중요한 문제인지, 어떤 가설을 검증해야 하는지, 어떤 데이터는 믿을 수 없는지, 제품이 누구의 어떤 결정을 바꾸는지는 사람이 판단해야 합니다.
본선에서 저는 AI를 통해 데이터를 빠르게 분석했지만, AI가 만든 해석을 충분히 제 언어와 판단으로 바꾸지 못했습니다.
그래서 프로덕트는 만들었지만, 그 프로덕트가 왜 이런 구조여야 하는지를 심사위원에게 제대로 설명하지 못했습니다.
돌이켜보면 제게 부족했던 것은 AI 사용 역량이 아니라 문제를 좁히고 직접 검증하며, 하나의 완결된 의사결정 흐름으로 만드는 능력이었습니다.
3시간 안에 모든 조직 문제를 해결하려 하기보다, 다음 하나를 완성했어야 했습니다.
문서에서는 캠페인이 성공했다고 하지만, 실제 데이터를 계산하면 이익이 남지 않는다.
Agent는 이 차이를 검증하고, 변수가 바뀔 때 계산과 권고, Action을 다시 갱신한다.
범위는 더 작지만, 제품의 역할은 훨씬 명확했을 것입니다.
그래도 본선까지 올라가서 다행이었다
대회가 끝난 직후에는 아쉬움이 컸습니다.
제가 만든 제품을 제가 제대로 이해하지 못한 것 같았고, 심사위원의 질문에 제대로 답하지 못한 장면도 계속 떠올랐습니다. 특히 카메라 앞에서 머리가 하얘졌던 순간은 당분간 잊기 어려울 것 같습니다.
하지만 시간이 지나고 다시 돌아보니, 이 경험이 없었다면 저는 계속 “근본적인 문제를 정의했다”는 것만으로 좋은 프로덕트를 만들었다고 생각했을 수도 있습니다.
좋은 문제의식은 중요합니다. 하지만 프로덕트는 문제의식을 설명하는 데서 끝나지 않습니다.
사용자에게 무엇을 제공하는지, 어떤 입력을 받아 어떤 계산을 하고, 어떤 판단과 Action으로 이어지는지가 명확해야 합니다. 그리고 그 과정이 다른 사람이 검증할 수 있어야 합니다.
이번 대회를 통해 다음을 배웠습니다.
- 근본적인 문제를 찾는 것과 제품의 범위를 좁히는 것은 별개의 일이다.
- 데이터가 많을수록 AI의 요약보다 계산과 출처 추적이 중요하다.
- 온톨로지는 목적이 아니라 판단 근거를 연결하는 수단이다.
- AI가 만든 결과물을 제출하는 것보다, 내가 어떤 판단을 내렸는지가 보여야 한다.
- 짧은 해커톤에서는 넓은 플랫폼보다 하나의 완결된 의사결정 경험이 낫다.
- 제품을 설명할 때는 “무엇을 만들었는가”보다 “사용자의 어떤 결정이 달라지는가”를 먼저 말해야 한다.
예선 준비부터 본선 발표까지 완벽하게 해낸 것은 아니었습니다. 오히려 제가 AI를 활용하는 방식의 약점을 적나라하게 확인한 경험에 가까웠습니다.
그래도 군 복무 중 3일간 준비한 예선 제품으로 본선까지 올라가고, 실제 기업의 심사위원 앞에서 제가 만든 프로덕트를 설명해 본 것은 흔하지 않은 경험이었습니다.
아직 취업 연계라는 작은 기대도 남아 있습니다.
다음에 비슷한 기회가 온다면 더 많은 기능을 만들기보다, 문제를 제 손으로 더 정확하게 이해하고 하나의 판단이 Raw Data에서 계산, 결론, 보고와 Action까지 이어지는 과정을 끝까지 완성해 보고 싶습니다.
이번 대회에서 가장 크게 남은 질문은 이것이었습니다.
나는 AI를 사용해 문제를 해결한 것인가, 아니면 AI가 만든 해석을 따라 결과물을 만든 것인가?
이번에는 후자에 가까웠던 순간이 많았던 것 같습니다.
다음 프로젝트에서는 그 차이를 극복하고 싶습니다.
오