[AI 해커톤 후기] AI 해커톤 1위 팀이 AI에게 맡기지 않은 것

기업의 업무에 AI를 도입하면 무엇이 달라질까요? 반복 업무를 자동화하고, 매달 작성하던 보고서를 대신 만들고, 업무 시스템과 연결해 사용자가 요청한 작업까지 처리할 수 있을까요?

네이버 사내에서 열린 ‘모두의 Engineering Day AI 해커톤’에 참여하면서 저희도 비슷한 의문을 품었습니다. 낯선 재무 업무를 이해하고 Claude Code를 활용해 실제로 동작하는 결과물을 만들어야 하는 상황에서, 처음에는 자연스럽게 ‘AI가 무엇을 해줄 수 있을까?’부터 생각했습니다.

하지만 프로젝트가 진행될수록 질문은 달라졌습니다. AI가 할 수 있는 일보다 어떤 일을 맡겨도 되는지, 결과가 그럴듯한지보다 틀렸을 때 발견하고 설명할 수 있는지, 자동화할 수 있는지보다 AI가 멈춰도 업무가 계속될 수 있는지가 더 중요해졌습니다.

이 글은 하나의 재무 업무를 AI로 바꿔 보려다 문제를 어떻게 다시 정의했고, 어떤 방식으로 접근했으며, AI를 쓰며 어떤 한계를 마주했는지를 정리한 기록입니다.

실제 사내 문제를 함께 해결하는 해커톤

‘모두의 Engineering Day AI 해커톤’은 참가자가 각자 준비한 아이디어로 경쟁하는 일반적인 해커톤과 조금 달랐습니다. 출발점은 사내 구성원이 실제 업무에서 겪고 있는 문제였습니다.

현업에서 해결하고 싶은 문제를 겪고 있는 구성원은 출제자(problem holder)로, AI를 활용해 그 문제를 함께 풀고 싶은 참가자는 문제를 푸는 사람(solver)으로 참여했습니다. 참가자는 개발, 기획, 디자인, 재무, 운영 등 여러 직군이 섞여 네 명이 한 팀을 이루었고, 출제자가 업무의 배경과 예외를 설명하면 참가자는 문제를 구조화하고 실제 동작하는 프로토타입을 만들었습니다.

문제를 푸는 과정은 팀당 두 대의 개발 환경을 두고 여러 명이 함께 프롬프트를 작성하고 결과를 검토하는 ‘페어 프롬프팅’ 방식으로 진행되었습니다. 한 사람이 AI에 지시한 결과를 그대로 받아들이는 대신, 서로 화면을 보며 질문을 고치고 결과를 함께 확인했습니다. 행사 당일 오전 10시부터 오후 4시까지, 문제를 구체화하고 설계해 동작하는 결과물로 만드는 데 주어진 시간은 약 6시간이었습니다. 완성된 서비스를 만드는 시간이 아니라 실제 업무 문제를 여러 직군의 시선으로 다시 보고, AI로 어디까지 바꿀 수 있는지 실험하는 시간이었습니다.

가장 낯선 문제를 선택

저희 팀이 선택한 문제는 다음과 같았습니다.

수기 Microsoft Excel(이하 엑셀) 기반 출자 현황 관리를 LLM·MCP 기반 투자 포트폴리오 관리 플랫폼으로 전환한다.

저희는 서비스 개발에는 익숙했지만 발행 주식 수, 보유 주식 수, 지분율, 유상증자, 구주 양수도, RCPS, 감자 같은 재무·투자 용어에는 익숙하지 않았습니다. 더 빠르게 이해하고 결과물을 만들기 쉬워 보이는 과제도 있었지만, 네 명 모두 이 문제를 1순위로 선택했습니다.

당시 네이버와 계열사가 투자한 법인의 변동 사항은 17명의 담당자가 각자의 엑셀 파일로 관리하고 있었습니다. 매월 담당자에게 직접 연락해 변동 사항을 받은 뒤 여러 파일을 다시 모아 전체 출자 현황을 정리해야 했습니다. 투자 대상이 늘고 다국가, 다통화, 다단계 지분 구조가 복잡해질수록 거래 이력을 관리하기 어려워졌고, 경영진이 원하는 기준으로 데이터를 다시 추출하는 데도 시간이 들었습니다.

사용자가 아주 많은 업무는 아니었지만, 이 숫자들은 사업보고서 같은 외부 공시의 기초 자료로 쓰일 수 있었습니다. 숫자 한 건이 잘못되었을 때의 영향은 작지 않았습니다. 익숙해서 빠르게 풀 수 있는 문제보다 제대로 바뀌었을 때 효과가 분명한 문제를 선택하자고 판단했고, 그렇게 NStake 프로젝트가 시작되었습니다.

문제는 엑셀이 아니라 설명하기 어려운 숫자

처음 떠올린 해결책은 비교적 명확했습니다. 담당자가 엑셀 대신 웹 화면에서 투자 내역을 입력하고, 여러 파일의 데이터를 하나의 데이터베이스에 모읍니다. 대시보드에서 현재 투자 현황을 보여주고, 자연어 질문에 답하며, AI가 월말 변동 보고서를 만들면 된다고 생각했습니다.

그러나 자세히 들여다보자 문제가 다르게 보였습니다.

파일을 데이터베이스로 옮기면 취합은 쉬워집니다. 하지만 한곳에 값을 모으기만 해서는 신뢰할 수 있는 기준 데이터로 사용할 수 없었습니다. 현재 지분율이 30%라고 적혀 있어도 그 숫자만으로는 왜 30%가 되었는지 알 수 없습니다. 이를 알기 위해서는 신규 투자, 구주 매도, 유상증자, 감자가 어떤 순서로 발생했고 각 거래가 발행 주식 수와 보유 주식 수에 어떤 영향을 주었는지를 함께 봐야 합니다.

사내 재무 원장이나 외부 공시 자료와 값이 다를 때는 문제가 더 복잡했습니다. 기준일이 다르거나 최근 거래가 한쪽에 아직 반영되지 않았을 수 있고, 데이터의 정의 자체가 다를 수도 있었습니다. 단순히 값이 다르다는 이유만으로 어느 쪽이 틀렸다고 결론 내리거나 자동으로 수정할 수 없었습니다.

결국 저희가 다시 정의한 문제는 이것이었습니다.

현재 숫자가 어떤 거래를 거쳐 만들어졌고, 무엇을 근거로 신뢰할 수 있는지 설명하기 어렵다.

프로젝트의 목표도 ‘엑셀을 대체하는 입력 화면’에서 ‘숫자가 만들어진 과정과 검증 결과를 함께 관리하는 기준 시스템’으로 바뀌었습니다.

[기존 방식]
담당자별 엑셀 작성
→ 변동 사항 요청
→ 여러 파일 취합
→ 사람이 직접 비교·확인
→ 보고 및 공시

[NStake]
담당자가 거래 내역 입력
→ 거래 이력으로 현재 상태 계산
→ 내부 규칙과 외부 자료로 검증
→ 불일치 확인 및 처리
→ 출자 현황과 보고서 생성

AI에게 무엇을 어떻게 맡길지 설계하기

문제를 다시 정의한 뒤에는 어떤 기능을 더 만들지보다 업무를 끝까지 움직이게 하는 기준을 먼저 세웠습니다. 저희 팀은 업무 흐름, 검증 기준, 보고서 규칙, 안전 장치를 함께 보며 문제에 접근했습니다.

업무가 끝나는 지점

해커톤에서는 자연어 질의, 대시보드, 자동 보고서처럼 눈에 잘 띄는 기능부터 만들고 싶어집니다. 하지만 입력 화면 하나가 동작한다고 담당자의 업무가 끝나는 것은 아니었습니다.

저희는 먼저 전체 업무 흐름을 정리했습니다.

입력
→ 값 검증
→ 불일치 발견
→ 담당자 확인 및 처리
→ 현재 상태 반영
→ 보고

저장한 값이 맞는지 확인할 수 없다면 담당자는 다시 엑셀과 다른 자료를 열어야 합니다. 불일치를 찾아주더라도 수정하거나 ‘이슈 없음’으로 처리할 수 없다면 확인할 목록만 하나 더 생깁니다. 보고서의 숫자가 어떤 거래에서 합산되었는지 추적할 수 없다면 공식 자료로 쓰기 어렵습니다.

이 흐름을 정리하자 시연에서 눈에 띄는 기능과 사용자의 일을 실제로 끝내기 위해 필요한 기능을 구분할 수 있었습니다. 저희가 보는 기준도 기능의 개수에서 업무 흐름의 완결성으로 옮겨갔습니다.

AI를 평가자와 검증자로 사용

저희는 AI를 ‘코드를 빨리 만들어 주는 도구’로만 사용하지 않았습니다. 문제와 평가 기준을 구조화하는 평가자, 여러 설계안을 비교하는 설계 파트너, 실제 결과물을 만드는 구현 보조자, 문서와 코드의 불일치를 찾는 검증자로 역할을 나눠 사용했습니다.

큰 기능을 만들 때는 다음 순환을 반복했습니다.

짧은 설계 문서 작성
→ 구현
→ 스크린샷·로그 등 테스트 증거 수집
→ 발표 자료와 README 반영
→ 문서와 실제 실행 흐름의 일치 여부 재검증

“발표에서 설명한 기능이 코드에도 있는가”, “보안상 위험한 동작은 없는가”, “부분 구현을 완성된 기능처럼 설명하지 않았는가”처럼 반복해서 물어야 하는 질문은 체크리스트로 만들었습니다. 이를 통해 하고 싶은 기능을 늘리는 대신, 성공 기준에 직접 연결되는 작업부터 처리할 수 있었습니다.

중요한 차이는 AI에게 무엇을 만들어 달라고 요청하는 데 그치지 않았다는 점입니다. 저희는 무엇이 성공인지 먼저 정의하고, 그 기준으로 결과를 계속 검증하는 데 AI를 사용했습니다.

현재 값이 아니라 거래 이력을 중심으로

기존 방식에서는 현재 발행 주식 수, 보유 주식 수, 지분율을 직접 수정했습니다. NStake에서는 현재 값만 저장하는 대신 그 숫자를 만든 거래를 시간순으로 기록했습니다. 자본금 납입과 신규 투자, 유·무상증자, 구주 양수도와 지분 매도, 감자와 액면분할, 청산 같은 거래를 바탕으로 현재 보유 주식 수와 지분율을 계산했습니다.

현재 지분율이 30%라는 결과만 있으면 문제의 원인을 찾기 어렵습니다. 하지만 어떤 투자와 증자, 매도를 거쳐 30%가 되었는지가 남아 있다면 계산 과정을 되짚을 수 있습니다. 거래 내역으로 계산한 값과 저장된 현재 상태가 다르다면 그 차이 자체를 확인 항목으로 만들 수도 있습니다.

이 기준에 따라 검증을 Rule, Statistical, eXternal 세 가지로 나눴습니다.

• Rule: 지분율 합계, 누락된 환율, 청산 이후의 신규 거래처럼 명확한 규칙으로 판정할 수 있는 항목
• Statistical: 평소보다 큰 거래 금액이나 급격한 주식 수 변화처럼 오류를 확정하지는 않지만 담당자가 먼저 볼 대상을 좁혀 주는 신호
• eXternal: 내부 값과 외부 공시의 차이처럼 시스템이 자동으로 옳고 그름을 결정하지 않고 사람이 확인해야 하는 항목

규칙 위반과 통계적 이상치, 외부 자료와의 차이를 모두 ‘오류’라고 부를 수는 없었습니다. 시스템이 확정할 수 있는 문제, 의심할 수 있는 값, 사람이 최종 판단해야 하는 차이를 구분해야 했고, 이 구분은 서비스 전반의 신뢰성을 높이는 데 중요한 역할을 했다고 생각합니다.

사용자 맥락에서 다시 판단한 디자인 프로토타입

이번 해커톤에서는 기획, 디자인, 개발, QA가 순서대로 이어지는 기존 프로세스도 사실상 뒤집혔습니다. 각 직군이 자기 영역의 기획을 미리 맡고 시작했고, AI가 프로토타입을 곧바로 만들 수 있었기 때문에 완성된 초기 기획서를 기다리기보다 먼저 구현한 뒤 함께 고치는 방식이 훨씬 빨랐습니다. 다만 빠르게 만든 프로토타입도 실제 사용자의 업무 맥락에 맞는지 다시 판단해야 했습니다.

프로젝트를 시작한 지 한 시간 만에 세 명의 개발자가 귀여운 스테이크 캐릭터와 갈색·베이지색을 중심으로 NStake 전체 화면을 만들어 보여줬습니다. 로딩 화면에도 스테이크 캐릭터가 등장했습니다. 결과가 나온 속도는 놀라웠지만, 재무팀 담당자가 이 화면을 처음 마주하면 꽤 당황하겠다는 생각도 들었습니다.

출자 현황 관리 시스템에서 디자인의 목표는 화려함이나 친근함이 아니었습니다. 기존 엑셀보다 불편하지 않게 정보를 확인할 수 있고, 숫자를 믿고 다룰 수 있다는 인상을 주는 것이 더 중요했습니다. 재무팀이 사용하던 엑셀에서는 셀 하나의 색에도 의미가 있었습니다. 노란색, 회색, 옅은 푸른색은 단순한 장식이 아니라 정보의 상태와 용도를 나타냈습니다. 이런 사용자에게 필요한 것은 귀여운 캐릭터보다 익숙함, 신뢰감, 공적인 인상과 전문성이었습니다.

그래서 캐릭터 중심의 시안에서 벗어나 재무팀에도 익숙한 네이버 디자인 시스템을 적용했습니다. 뉴트럴 톤을 기본으로 네이버 그린을 포인트 컬러로 쓰는 차분한 ERP 스타일로 전환하고, 앱 아이콘과 파비콘, 웹 페이지 제목에 필요한 로고도 제작했습니다.

design.md 파일에 원칙을 정리해 두면 AI는 전체 톤과 시안을 빠르게 만들었습니다. 그러나 원하는 수준에 도달하려면 “그게 아니다”, “이런 스타일로 바꿔 달라”는 요청을 여러 번 반복해야 했고, 결국 일부 요소는 처음부터 다시 그리거나 직접 세부 조정을 해야 했습니다. 필요한 PNG 파일이 나오기를 팀 전체가 기다리면서 디자인이 개발의 병목이 되기도 했습니다.

이 경험은 프로토타이핑의 기준을 분명하게 했습니다. AI는 탐색과 초안 제작의 속도를 높이는 데 유용했지만, 최종 판단자가 되지는 않았습니다. 실제 사용 가능 여부는 재무팀의 업무 방식과 정보 해석 기준에 맞춰 다시 판단해야 했습니다.

월말 보고서는 생성하지 않고 규칙에 따라 정리

초기에는 거래 이력을 AI 모델에 전달해 월말 보고서를 만들었습니다. 구현은 빨랐고 시연 효과도 좋았습니다. 하지만 같은 데이터에서도 표현이 달라질 수 있었고, 회사의 보고 형식과 맞지 않는 문장이 생겼으며, 모델 연결에 문제가 생기면 공식 보고서 생성 자체가 영향을 받았습니다.

무엇보다 공식 보고서의 거래 분류와 합계는 표현의 문제가 아니었습니다. 같은 거래 데이터에서는 언제나 같은 결과가 나와야 했습니다. 결국 거래를 투자, 처분, 변경으로 나누는 기준과 합계 계산을 명시적인 규칙으로 바꿨습니다. 화면과 엑셀 보고서에서도 같은 계산 결과를 사용했습니다. AI는 공식 숫자를 결정하는 역할에서 빠졌습니다.

대신 자연어로 투자 현황을 묻고 답하거나, 사용자가 쓴 거래 설명을 입력 초안으로 바꾸거나, 복잡한 불일치를 이해하기 쉽게 설명하는 일에 AI를 사용했습니다.

이 경험을 통해 역할을 나누는 기준도 분명해졌습니다.

업무 특성	적용 방식
같은 입력에 반드시 같은 결과가 필요함	명시적인 규칙과 코드
금액·수량·비율을 공식적으로 계산함	결정론적 계산
재무·법적 판단에 직접 사용됨	규칙 기반 처리와 사람의 승인
다양한 표현이 허용됨	생성형 AI
사용자가 결과를 다시 검토할 수 있음	AI를 활용한 초안 생성
정답보다 확인 범위를 줄이는 일이 중요함	AI 또는 통계 모델

AI의 안전 장치는 응답이 아니라 요청 단계부터

재무 데이터를 다루는 AI의 가드레일이라고 하면 흔히 위험한 질문이나 부적절한 답변을 막는 필터를 떠올립니다. 하지만 NStake에서 가드레일의 핵심은 응답 필터보다 권한 경계에 있었습니다.

더 중요한 질문은 누가 어떤 회사의 데이터를 볼 수 있는지, AI는 누구의 권한으로 그 데이터를 조회하는지, 조회 결과를 설명하는 일과 실제 데이터를 바꾸는 작업을 어떻게 구분할 것인지였습니다.

저희는 가드레일을 모델의 답변을 사후에 검사하는 기능이 아니라 ‘AI가 데이터와 도구에 접근하기 전부터 적용되는 권한 경계’로 정의했습니다. AI가 모든 데이터를 조회한 뒤 최종 답변에서 일부만 가리는 방식은 안전하지 않다고 봤습니다. 처음부터 현재 로그인한 사용자가 볼 수 있는 법인의 데이터와 실행할 수 있는 도구만 AI에 제공해야 했습니다.

이를 위해 다음과 같은 구조를 설계했습니다.

경계	적용 원칙
인증	사내 SSO 이후 AI·MCP용 짧은 수명의 토큰을 별도로 발급하고 최소한의 식별 정보만 담음
데이터 권한	토큰이나 모델의 판단만 믿지 않고, 매 요청마다 사용자의 역할과 담당 법인 범위를 DB에서 다시 확인
도구 권한	조회, LLM 질의, 쓰기, 관리자 기능을 서로 다른 정책으로 구분
변경 승인	입력·수정·삭제처럼 상태를 바꾸는 작업은 실행 전에 사용자의 명시적인 확인을 요구
정보 보호	민감 정보 마스킹, 입력 길이 제한, 로그와 오류 메시지의 인증 정보 노출 방지
추적 가능성	누가 언제 어떤 데이터를 조회·생성·수정·삭제했는지 append-only 방식의 감사 로그에 기록

안전 정책은 프롬프트에 ‘권한 없는 데이터는 보여 주지 마’라고 적는 것으로 끝나지 않습니다. 모델이 규칙을 잘 따르기를 기대하기보다, 모델 밖의 인증·인가 계층과 도구 실행부가 허용되지 않은 행동을 구조적으로 차단해야 합니다.

AI를 쓰며 부딪힌 한계

접근 방법을 정리한 뒤에도 AI를 실제 업무에 적용하는 과정에서는 한계가 분명했습니다.

권한과 실행 통제의 위험

가장 큰 문제는 AI가 잘못된 숫자를 답한 일이 아니었습니다. 로컬 테스트 데이터만 지우기 위해 만든 초기화 코드가 공용 개발 데이터베이스에 연결된 상태에서 실행된 일이었습니다.

복구 스크립트 덕분에 데이터를 되살릴 수는 있었지만, 위험한 초기화 코드를 완전히 제거하기 전까지 같은 실행이 반복되었고 최종 복구까지 20분 이상 걸렸습니다. 6시간짜리 해커톤에서 20분은 짧지 않았습니다.

이 일을 단순히 “AI가 위험한 코드를 만들었다”라고만 설명할 수는 없었습니다. AI는 로컬 환경을 전제로 코드를 만들었고, 이후 데이터베이스 연결 대상이 공용 개발 환경으로 바뀌었습니다. 코드의 실행 환경이 달라진 것이었습니다. AI 작업 도구에 필요 이상의 권한이 부여되어 있었고, 로컬과 공용 개발 환경이 충분히 분리되지 않았으며, 삭제 전 대상 환경과 복구 절차를 확인하지 않았던 점이 함께 원인이 되었습니다.

이후 저희는 다음 원칙을 정리했습니다.

1. AI 작업 도구에 관리자 권한을 기본으로 주지 않는다.
2. 로컬·개발·운영 환경을 명확히 분리한다.
3. 삭제나 대규모 변경 전 대상 환경을 다시 확인한다.
4. 파괴적인 작업에는 사용자의 명시적 승인을 받는다.
5. 기능 개발 전에 백업과 복구 가능성을 확인한다.
6. AI가 생성한 코드는 설명이 아니라 실제 실행 결과로 검증한다.

AI가 실제 시스템에 접근해 코드를 만들고 실행하는 환경에서는 환각보다 권한과 실행 통제가 더 직접적인 위험이 될 수 있었습니다.

‘기능이 있다’와 ‘업무에서 동작한다’의 차이

함수도 있고 파일도 존재해 AI는 기능이 완성되었다고 설명했지만, 사용자가 화면에서 버튼을 누르고 결과를 확인하는 전체 흐름에는 연결되지 않은 기능도 있었습니다.

그 뒤로는 파일이나 함수의 존재만으로 완료를 판단하지 않았습니다. 사용자가 실제로 다음 흐름을 끝까지 수행할 수 있어야 했습니다.

로그인
→ 담당 회사 확인
→ 거래 입력
→ 저장
→ 검증
→ 불일치 확인
→ 문제 처리
→ 현재 상태와 보고서 반영

자료를 많이 제공하면 AI가 업무를 정확히 이해할 것이라는 기대도 다시 보게 되었습니다. 문서가 늘수록 서로 다른 용어와 기준일이 섞였고, 어떤 파일이 기준인지 모호해졌습니다. 기존 화면과 실제 업무 규칙이 충돌하기도 했습니다.

필요했던 것은 자료의 양보다 판단 기준이었습니다. 어떤 문서가 기준인지, 값이 다르면 무엇을 우선하는지, 최신 값은 어떤 기준일로 판단하는지, 예외는 누가 결정하는지, 무엇을 자동 반영하고 무엇을 사람이 확인할지를 정해야 했습니다. 이 판단을 AI에게 일임할 수는 없습니다. 결국 업무의 기준은 사람이 정해야 한다는 점을 깨달은 과정이었습니다.

결과와 남은 질문

기능의 개수보다는 흐름의 완결성

해커톤은 코드와 문서를 바탕으로 한 LLM의 1차 평가, 출제자의 평가, 참가자의 최종 평가로 진행되었습니다. NStake는 LLM 1차 평가에서 1위로 선정되었고 출제자의 SUPER(슈퍼패스)에 선택되었으며 최종 평가에서도 1위를 기록했습니다. 행사 이후 같은 조건으로 다섯 차례 다시 평가했을 때도 네 차례 1위를 기록했다고 소개되었습니다. 다만 상위권 팀 사이의 점수 차이는 크지 않았습니다.

평가에서는 NStake가 출자 현황 입력에서 멈추지 않고 기준 데이터 대조와 불일치 처리까지 업무 흐름을 연결했다는 점이 언급되었습니다. 저희는 이 결과가 특정 AI 기능 하나 때문이라고 생각하지 않습니다. 웹, 모바일 앱, 백엔드, AI 기능을 모두 만들었다는 사실도 핵심이 아니었습니다.

중요했던 것은 모든 기능이 하나의 업무 흐름을 공유했다는 점이었습니다.

입력
→ 검증
→ 판단
→ 처리
→ 결과 생성

사람 평가자와 LLM 모두 기능의 개수보다 이 흐름의 완결성을 본 것이 아닐까 생각합니다. 물론 저희 방식이 유일한 정답이었다고 말할 수는 없습니다. 상위권 팀의 점수 차이가 작았던 만큼, 기능이나 문서 하나가 우승을 결정했다고 단정할 수도 없습니다. 다만 저희가 정한 문제 해결의 기준이 평가자에게도 어느 정도 전달되었다는 의미로 받아들이고 있습니다.

해커톤 뒤에 남은 질문

NStake는 가능성을 보여 준 결과물이었지만 바로 실제 업무에 투입할 수 있는 시스템은 아니었습니다. DART 일부 항목의 대조와 감사 로그는 프로토타입에 반영했지만, 사내 재무 원장까지 포함한 자동 대조, 운영 수준의 MCP 인증, 개발·운영 환경 분리, 트랜잭션 보장, 감사 로그의 보관·모니터링, 자동 테스트 같은 과제가 남았습니다.

이번 해커톤에서 확인한 것은 완성된 서비스가 아니라 여러 담당자가 엑셀을 취합하던 업무를 입력, 검증, 처리, 보고가 이어지는 흐름으로 바꿀 수 있다는 가능성이었습니다.

다음 단계로 가려면 세 가지 질문에 답해야 합니다.

• AI가 만든 결과를 어디까지 믿고, 누가 최종 확인할 것인가?
• AI가 볼 수 있는 데이터와 실행할 수 있는 작업을 어디까지 허용할 것인가?
• 동작하는 PoC를 안전하고 효과를 측정할 수 있는 운영 시스템으로 어떻게 전환할 것인가?

마치며

이번 해커톤은 AI의 가능성과 한계를 함께 보여 줬습니다. AI는 낯선 업무를 이해하는 속도를 높였고 여러 설계안을 빠르게 비교했으며, 코드와 화면, 문서를 짧은 시간 안에 만들 수 있도록 도왔습니다. 완성된 기획서를 기다리지 않고 먼저 구현한 뒤 함께 수정하는 새로운 협업 방식도 가능하게 했습니다.

동시에 같은 데이터로 다른 표현의 보고서를 만들었고, 사용자의 전체 업무 흐름에 연결되지 않은 기능을 완성되었다고 설명하기도 했습니다. 디자인 시안을 빠르게 생성했지만 실제 사용자의 맥락과 신뢰를 담은 결과로 다듬는 일은 사람의 몫이었습니다. 실행 환경과 권한을 충분히 통제하지 않아 공용 개발 데이터가 삭제되는 사고도 있었습니다.

기업의 AX는 기존 업무에 AI 기능을 하나 더 붙이는 일이 아니었습니다. 어떤 판단을 규칙으로 남기고, 어떤 판단을 사람에게 맡기며, AI가 그 사이에서 어떤 역할을 할지 다시 설계하는 일이었습니다.

NStake에서 가장 중요했던 선택도 새로운 AI 기능을 하나 더 추가하는 것이 아니었습니다. 공식 숫자는 규칙으로 계산하고, 애매한 결과는 사람이 판단하게 하며, AI는 그 과정을 더 빠르게 이해하고 처리하도록 돕는 것. 그리고 입력부터 검증, 처리, 보고까지 이 역할들을 하나의 업무 흐름으로 연결하는 것이었습니다.

해커톤이 끝난 뒤 저희에게 남은 결론은 단순했습니다.

좋은 AI 시스템은 AI가 많은 일을 하는 시스템이 아닙니다. AI가 틀리거나 멈춰도 중요한 업무가 흔들리지 않는 시스템입니다.

AI 도입의 시작점은 ‘무엇을 AI로 바꿀 것인가’일 수 있습니다. 그러나 운영 가능한 시스템을 만들기 위한 질문은 결국 여기로 돌아옵니다.

무엇을 AI에게 맡기고, 무엇은 끝까지 맡기지 않을 것인가.