AX 전환 해커톤 — 100명 규모, 개발자·비개발자 분반

과제

한화생명은 100명 규모의 참여자를 대상으로 AX 해커톤을 운영하고자 했습니다. 참여자는 개발자 직군과 비개발자 직군이 함께 섞여 있었고, AX에 대한 이해 수준도 한 가지 속도로 맞추기 어려운 상태였습니다. 출발점의 핵심 긴장은 명확했습니다. 같은 시간 안에 같은 주제를 다루되, 각자가 가져갈 산출물은 서로 달라야 했습니다.

운영 조건은 짧고 밀도가 높았습니다.

• 전체 기간은 2일이었으며, 1일차는 6시간 교육으로 운영했습니다.
• 2일차는 6시간 해커톤이었고, 2시간 단위 3클래스로 나누어 진행했습니다.
• 대상은 100명 규모였으며, 개발자 직군과 비개발자 직군이 함께 참여했습니다.
• 직군 차이뿐 아니라 기초반과 심화반의 수준 차이도 함께 고려해야 했습니다.
• 개발자에게는 실제로 작동하는 에이전트 제작이 중요했고, 비개발자에게는 자기 업무 흐름에 AX를 어떻게 녹일지 정리하는 일이 더 중요했습니다.

따라서 이 과제는 단순한 교육 행사가 아니었습니다. 단일 강연으로 공통 이해만 맞추면 비개발자에게는 추상적으로 남고, 단일 미션으로 해커톤을 밀어붙이면 개발자와 비개발자의 산출물 기준이 서로 어긋난다고 판단했습니다. 학습 곡선과 역할 차이를 동시에 흡수하는 운영 구조가 먼저 필요했습니다.

접근

전체 설계는 “한 번 듣고 끝나는 교육”이 아니라 “다음날 자기 손으로 결과물을 만드는 흐름”에 맞추었습니다. 1일차에는 직군과 수준에 맞는 언어로 AX 활용의 기준을 맞추고, 2일차에는 그 기준을 각 분반의 과제와 산출물로 전환하도록 했습니다.

가장 먼저 버린 선택지는 100명을 한 공간에 모아 동일한 강연과 동일한 미션을 제공하는 방식이었습니다. 표면적으로는 운영이 단순하지만, 이 경우 빠른 참여자는 대기하고 느린 참여자는 따라가기 어렵습니다. 더 큰 문제는 개발자와 비개발자가 같은 결과물을 내야 하는 상황이 생긴다는 점이었습니다. 이번 프로그램에서는 같은 AX라는 주제를 다루되, 도달점은 다르게 잡는 편이 맞다고 판단했습니다.

직군과 수준을 동시에 나누었습니다

분반 기준은 하나만으로는 충분하지 않았습니다. 개발자와 비개발자를 나누는 것만으로는 기초 참여자와 심화 참여자의 속도 차이를 해결하기 어렵습니다. 반대로 기초와 심화만 나누면, 개발자에게 필요한 구현 중심 설명과 비개발자에게 필요한 업무 흐름 중심 설명이 한 교실 안에서 섞이게 됩니다.

그래서 직군 축과 수준 축을 함께 적용했습니다. 결과적으로 개발자 기초, 개발자 심화, 비개발자 기초, 비개발자 심화의 4개 분반을 동시에 운영했습니다. 이 구조는 운영 난도가 올라가는 방식이지만, 100명 규모의 혼합 참여자에게는 더 현실적인 선택이었습니다. 참여자가 “내가 왜 이 과제를 해야 하는지”를 자기 역할의 언어로 이해해야 다음날 해커톤의 집중도가 유지된다고 봤습니다.

개발자 분반의 도달점은 작동하는 에이전트로 잡았습니다

개발자 분반은 개념 이해보다 실제 작동 여부가 중요했습니다. 교육 단계에서부터 해커톤의 끝을 “설명 자료”가 아니라 “작동하는 에이전트”로 상정했습니다. 그래야 2일차에 아이디어 발표만 남는 것을 피하고, 구현 과정에서 필요한 판단을 빠르게 드러낼 수 있었습니다.

기초반과 심화반의 차이는 기대 난이도에서 조정했습니다. 기초반은 작동 조건을 명확히 잡고 완성 가능한 범위를 좁히는 방향이 적합했습니다. 심화반은 더 복잡한 과제를 다루되, 6시간 안에 검증 가능한 수준으로 끊어내는 운영이 필요했습니다. 2시간 단위 3클래스는 이 리듬을 만들기 위한 장치였습니다. 처음 2시간에는 문제와 구현 범위를 정리하고, 다음 2시간에는 제작을 진행하며, 마지막 2시간에는 결과물을 정리해 공유 가능한 형태로 만드는 흐름을 의도했습니다.

비개발자 분반은 업무 흐름 안에 AX를 넣는 방식으로 설계했습니다

비개발자 분반에 개발자와 같은 구현 산출물을 요구하지 않았습니다. 이 분반의 핵심은 자기 업무 흐름을 다시 보고, 어느 지점에 AX가 들어가야 하는지를 결과물로 정리하는 데 있었습니다. 도구 사용법만 익히는 방식으로는 해커톤 이후 부서 단위 검토로 이어지기 어렵다고 판단했습니다.

운영에서는 산출물의 형태를 개발자 분반과 다르게 두었습니다. 비개발자 참여자는 자기 업무의 반복 구간, 판단이 필요한 구간, 초안화가 가능한 구간을 구분해 보도록 했습니다. 기초반은 AX를 적용할 수 있는 업무 장면을 선명하게 잡는 데 초점을 두고, 심화반은 그 장면을 실제 운영 과제에 가깝게 정리하도록 했습니다. 이 차이를 둔 이유는 단순했습니다. 비개발자에게 중요한 결과는 코드가 아니라, 조직 안에서 논의 가능한 업무 적용안이기 때문입니다.

교육과 해커톤을 하루 간격으로 붙였습니다

1일차 교육과 2일차 해커톤 사이를 길게 벌리지 않았습니다. 교육에서 얻은 개념과 예시가 식기 전에 바로 손으로 옮겨야 한다고 봤습니다. 하루 교육을 마친 뒤 다음날 6시간 해커톤으로 이어지면, 참여자는 전날 배운 내용을 추상적인 이해로 남겨두지 않고 자기 분반의 과제로 전환하게 됩니다.

이 구조에서는 강사의 역할도 달라집니다. 1일차에는 분반별 학습 목표를 분리해 진도 차이를 흡수하는 일이 중요했습니다. 2일차에는 모든 참여자에게 같은 답을 요구하기보다, 각 분반의 산출물이 해당 직군과 수준에 맞는지 확인하는 쪽이 더 중요했습니다.

운영 관점에서는 다음 세 가지를 계속 맞추었습니다.

• 같은 AX 프로그램 안에 있다는 공통감은 유지했습니다.
• 분반별 난이도와 산출물 기준은 다르게 두었습니다.
• 해커톤 결과가 사내 AX 도입 후속 작업의 입구가 되도록, 결과물의 표현 방식을 조직 안에서 다시 논의 가능한 형태로 정리했습니다.

단발 행사가 아니라 후속 도입의 입구로 보았습니다

해커톤은 행사 당일의 완성도만으로 판단하기 어렵습니다. 특히 금융사 내부에서 AX 도입을 검토하려면, 누가 어떤 업무 맥락에서 관심과 실행 의지를 보였는지가 중요합니다. 이번 프로그램은 그 사람들을 드러내고 연결하는 장으로도 설계했습니다.

그래서 2일차 산출물은 분반별로 서로 다른 형태를 허용했습니다. 개발자 직군은 실제로 작동하는 에이전트를 통해 기술적 가능성을 보여주고, 비개발자 직군은 자기 업무 흐름에 AX를 넣는 방안을 통해 현업 적용 가능성을 보여주는 구조였습니다. 두 결과물은 성격이 다르지만, 후속 검토에서는 함께 필요합니다. 기술적으로 만들 수 있는 사람과 업무 장면을 설명할 수 있는 사람이 동시에 보여야 부서 단위 도입 논의가 시작되기 때문입니다.

결과

이번 운영의 결과는 하나의 우수작을 뽑는 방식보다, 직군별로 다른 형태의 구체 산출물을 남긴 데 의미가 있었습니다. 개발자 분반에서는 실제로 작동하는 에이전트 형태의 결과물이 도출되었고, 비개발자 분반에서는 자기 업무 흐름에 AX를 어떻게 녹일지 정리한 결과물이 만들어졌습니다.

또 하나의 결과는 사람의 연결이었습니다. 100명 규모의 혼합 참여자가 4개 분반에서 함께 학습하고 해커톤을 수행하면서, 사내 AX 도입 후속 작업을 위한 인적 네트워크가 형성되었습니다. 이후에는 부서 단위 도입 검토로 이어졌습니다. 이 사례는 대규모 AX 프로그램일수록 동일한 메시지보다 역할별 산출물 설계가 먼저라는 점을 보여줍니다. 유사한 사내 확산 구조는 AX Ops 방법론 →에서 더 자세히 보실 수 있습니다.