아임웹은 어쩌다 사내 해커톤을 하게 되었을까

date

slug

author

status

tags(최대 3개)

summary

type

thumbnail

해커톤의 시작

개발자 서베이

시작은 사내 개발자 서베이였어요. 여러 답변 중 유독 자주 등장하는 응답이 있었죠.

“AI 활용 경험을 공유할 자리가 부족하다.” ”조직 간 교류가 부족하다.”

아임웹은 AI를 잘 쓰는 조직임은 분명했지만, 그 경험이 조직 안에서 순환하지 않았습니다. 조직 간 경험치 편차가 컸고, 교류하고 공유할 기회가 부족했죠.

자연스럽게 교류하기

처음 떠올린 것은 밋업(Meetup)이었어요. 사내외에서 잘 쓰는 분들의 사례를 듣는 자리였고, 관심 있는 구성원들은 앉아서 듣기만 하면 되죠.

준비와 운영도 비교적 수월한 편이고요. 그런데 기획하다 보니 걸리는 지점이 있었어요. 듣고 나서 남는 것이 얼마나 될까. 좋은 발표를 들어도 며칠 지나면 좋았다는 인상만 남는 경우가 많아요.

그래서 듣는 자리 대신 직접 만들어보고 그 경험을 나누는 자리를 만들기로 했습니다. 만들어본 사람은 할 말이 생기고, 할 말이 있는 사람이 모이면 공유는 자연스럽게 일어나거든요.

참여 대상에 대한 고민

방향을 정하고 나니 또 하나 걸리는 것이 있었어요. ‘AI 활용이 정말 개발자만의 이야기일까?’ 디자이너, 마케터, 세일즈 담당자도 이미 각자의 방식으로 AI를 쓰고 있었어요. 개발 조직 밖에서 더 창의적으로 쓰는 경우도 있었죠.

그런데 그 경험은 어디에서도 공유되지 않았어요. 그래서 개발자 서베이에서 출발한 문제를 전사 단위로 넓히기로 결정합니다. AI를 잘 쓰는 사람들이 조직 곳곳에 흩어져 있다면, 그들을 섞는 것 자체가 답이 될 수 있다고 판단했죠.

컨셉과 네이밍 정하기

첫 사내 해커톤인 만큼 컨셉이 중요했어요. 잘 잡힌 컨셉은 기억 속에 오래 남아 다음을 기대할 수 있거든요. 무엇을 하는 프로그램인지 한 번에 와닿으면서도 참여하고 싶어지는 이름이 필요했죠. 또한 경험상 ‘해커톤’이라고 명시하기보다 갖춰진 컨셉과 키비주얼을 내세우는 편이 진입장벽을 낮춰요.

부시크래프트(Bush Craft)는 야생에서 주변의 재료만으로 도구를 만들고 불을 피우는 생존 기술이에요. AI로 필요한 도구를 만들어낸다는 메타포와 맞아 떨어지는 점을 활용했어요.

꾸며진 사내공간 일부 여기에 부시크래프트가 일어나는 장소인 텐트라는 의미를 하나 더 얹었어요. 황야 한가운데 세운 베이스캠프처럼, 이번 프로그램으로 각자 흩어져 있던 사람들이 모이는 자리가 되기를 바랐죠.

키비주얼도 AI를 텐트 형태로 형상화해 이미지를 직접 디자인했고, 포스터와 굿즈까지 신경써 제작했어요.

프로그램 설계

기존처럼 개발자들만 대상으로 진행한다면 주제와 심사는 기술 역량을 펼칠 수 있게, 각자 원하는 팀원을 꾸려올 수 있게 안내하면 됩니다. 다만 참여 대상이 넓어진 덕에 크게 고민하지 않았을 지점들을 짚어봐야 했어요.

운영 기간의 딜레마

해커톤은 제한된 시간 안에 결과물을 만들어야 하니 무박 2일이나 반나절 동안 진행하는 형태가 관행처럼 이어집니다.

이번에는 그 형식을 따르지 않고, 4일간 각자 업무와 병행하며 자율적으로 진행하도록 구성했어요. 정답이 있는 문제는 아니지만 다음 세 가지를 놓고 보니 시간을 압축하는 방식이 이번 프로그램과는 맞지 않았어요.

하루를 통으로 비우는 일이 혼자만의 문제가 아니에요. 아임웹에는 자율과 책임이라는 문화가 있어요. 자율적으로 일하되, 그 자율이 협업하는 동료에게 부담이 되지 않는 선에서 움직이죠. 무박 2일은 하루를 전부 비워야 하고, 같이 일하는 사람들에게 영향이 갈 수 밖에 없어요. 각자 업무를 조율하며 자율적으로 참여하는 형태가 아임웹 문화에 더 맞다고 판단했습니다.

무엇보다 해커톤이 처음인 구성원이 많았어요. 전 직군을 대상으로 하는 프로그램이었고, 해커톤 자체가 낯선 분들이 대부분이었죠. 이런 상황에서 밤샘까지 요구하면 참여를 주저하게 돼요. 참여 문턱을 높일 이유가 없었어요.

무박 2일이라는 형식 자체가 유효기간을 지났다고 판단했어요. 과거 해커톤이 밤을 새운 것은 낭만 때문만이 아니었어요. 개발 인력과 시간 등 제한된 리소스라는 조건이 실재했기 때문이죠. 짧은 시간에 무언가 만들어내려면 사람의 시간을 갈아 넣는 것 외에 방법이 별로 없었어요.

지금은 AI가 그 제약을 상당 부분 걷어냈고, 밤새 붙잡고 있어야 나오던 결과물이 훨씬 짧은 시간에 나와요. 시간 대비 프로덕트의 퀄리티도 높아졌고요.

그렇다면 밤을 새우는 형식은 무엇을 위한 것일까요?

AI를 주제로 한 해커톤이 정작 AI 이전 시대의 형식을 그대로 답습하는 것은 앞뒤가 맞지 않았어요. 그래서 시간을 압축하는 대신 일상 속에 흩어놓는 방식을 택했죠.

팀 구성: 불편한 규칙

이번 해커톤이 지향한 것은 기술 경쟁보다 교류와 공유이니 규칙도 그 방향을 따라야 했어요. 가장 고민한 부분이자 이례적인 규칙을 만든 이유이기도 합니다.

해커톤에서 개발자를 제한한다는 것이 낯설게 들릴 수 있어요. 개발자 비중에 제한을 두지 않으면 결국 개발자만의 대회가 되기 쉬워요. 결국 비개발 직군은 자신이 기여할 수 없다고 판단해 참여를 망설일 수 밖에 없습니다.

또한 다양한 인사이트가 오가기를 기대하며 같은 직군 간 편성을 제한했어요. 뒤이어 나올 주제를 같은 직군끼리 고민하면 결국 다른 직군의 공감을 얻기 어렵거든요. 조금 불편하더라도 낯선 조합을 강제했어요.

처음에는 개발자로 팀을 채우려던 계획이 어긋나 당황하는 분들도 있었어요. 하지만 곧 지나가며 인사만 나누던 동료들과 팀을 이루기 시작했죠.

주제: 구성원에게 도움되는 서비스

주제를 정하는 것이 생각보다 훨씬 어려웠어요.

비즈니스 과제와 연계하면 참가자들이 업무의 연장선으로 생각해 부담을 느낄 수 있어요. 첫 해커톤인 만큼 쉽게 접근할 수 있는 주제가 필요했죠. 처음에는 업무에 도움되는 서비스 정도로 잡았는데, 이렇게 두면 각자 자기 직군에게만 필요한 도구를 만들 가능성이 큽니다. 유용하지만 해당 직군이 아니라면 다른 구성원의 공감을 얻기 어렵죠. 개발자는 PR 리뷰 봇을, 리크루터는 이력서 스크리닝 도구를 만드는 것처럼요.

그래서 기준을 하나 더 세웠어요. 도움이 직군 경계를 넘어야 한다.

실제로 해커톤 기간 중 한 참가자가 이런 질문을 주셨어요.

“오피스 윗 층의 공사 소음 문제를 해소하는 것도 주제에 해당될까요?”

이런 질문에는 맞다, 틀리다로 답하지 않으려 했어요. 대신 판단 기준을 드렸죠. 불편을 겪는 구성원이 있고 그 답답함에 공감할 수 있는지 생각해 보시라고 안내했습니다.

운영을 위한 올인원 페이지

규칙을 정하니 운영이 문제였어요. 팀 결성부터 미션, 제출, 투표, 심사까지 챙길 것이 많은데, 이를 스프레드시트와 슬랙 메시지로만 운영하면 담당자가 계속 붙어 있어야 해요. 참가자도 지금 무엇을 해야 하는지 매번 물어봐야 하고요.

그래서 운영 페이지를 직접 풀스택으로 개발했어요. 여기에 슬랙을 연동해 참가자들이 놓치는 정보가 없도록 기능을 덧붙였습니다.

팀 결성: 팀 생성과 합류를 페이지에서 처리, 팀 구성 규칙을 자동으로 검사

알림: 일정과 공지를 슬랙으로 자동 발송

미션: 참여형 미션 안내와 수행 현황 확인, 가산점 계산

제출: 데모 영상과 산출물 접수, 구글 드라이브(영상) 임베드

심사: 예선 투표와 본선 채점, 심사위원 선발 및 지정

리더보드: 진행 상황과 결과를 실시간으로 공개

운영자는 어드민 페이지에서 이 모든 것을 올인원으로 제어해요. 규칙과 정책을 코드로 옮겨 두니 일일이 확인할 일이 줄었고, 참가자는 페이지 하나만 보면 지금 할 일을 알 수 있었죠.

심사: 공감대 얻기

심사는 두 단계로 나눴습니다.

예선은 전 구성원 온라인 투표였어요. 서비스 핵심 기능을 담은 90초 이내 데모 영상만 보고 투표하는 방식이죠. 투표를 예선에 둔 것은 주제를 고려했어요. 이번 주제가 구성원에게 도움되는 서비스였으니, 구성원들의 공감을 얻는 것이 가장 중요한 평가 기준이라고 봤죠. 심사위원 몇 명이 아니라 실제로 그 서비스를 쓸 사람들이 판단하는 것이 맞다고 봤어요.

여기서 중요하게 생각한 것은 해커톤에 참여하지 않은 구성원도 투표할 수 있게 한 점이에요. 참가자들만의 잔치가 되지 않으려면 참여하지 않는 사람에게도 참여할 자리가 있어야 합니다. 결과적으로 전체 구성원의 90%가 투표에 참여할 만큼 사내 관심이 뜨거웠어요.

예선에서 발표를 하지 않은 데도 이유가 있는데요. 발표 없이 영상만으로 평가하면 팀 입장에서는 아쉬울 수 있어요. 다만 참가 팀이 많아질 수록 전체 발표 시간을 고려하면 효과적인 방식이 아니었죠. 개발 구현보다 그럴듯한 화면 디자인과 발표 자료로 포장하는 경우를 막을 필요도 있었어요.

그래서 예선은 각자 편한 시간에 영상을 보고 투표하는 방식으로, 본선은 투표에서 상위팀만 오프라인 발표를 진행 했어요.

본선은 상위 3팀이 오프라인에서 발표하고 C레벨을 포함한 심사위원들이 심사했어요. 창의성, 완성도, 업무 활용도, AI 활용도 4개 기준을 적용했습니다.

본선 발표 현장에선 깜짝 심사위원 2명을 현장 추첨으로 선발했어요. 리더진만 점수를 매기면 위에서 내려다보는 심사가 될 수 있죠. 이번 주제는 구성원에게 도움되는 서비스였으니 실제 사용할 사람의 시선이 심사석에도 있어야 한다고 봤어요. 예선을 전 구성원 투표로 진행한 것과 같은 이유죠. 누가 뽑힐지 모른 채 진행하다 보니 현장 분위기도 함께 달아올랐습니다.

AI 심사를 도입하지 않은 이유

AI가 주제였으니 심사에도 AI를 넣을 수 있었어요. 실제로 많은 해커톤이 객관적인 평가를 위해 AI 심사를 도입합니다. 하지만 이번 해커톤은 다음 2가지 이유로 사람의 심사에 맡겼는데요.

결과물을 쓰는 사람은 결국 사람이기 때문이에요. 이번 주제는 구성원에게 도움되는 서비스였고, 그 도움이 실제로 도움인지는 쓸 사람만 판단할 수 있어요. 16층 소음 문제를 겪어본 사람만이 그 답답함의 크기를 아는 것처럼 말이죠. AI는 완성도나 기술 난이도는 가늠할 수 있어도, 이 서비스가 내 하루를 낫게 만드는지는 판단하기 어려워요.

객관성이라는 명분도 다시 생각해 볼 지점이 있어요. 기술적으로 진보한 결과물에 초점을 뒀다면 충분히 고려할 수 있죠. 다만 이번 심사에서 필요했던 것은 편향 없는 점수가 아니라 쓸 사람의 편향이었어요. 그래서 예선은 전 구성원 투표로, 본선은 리더진과 추첨 심사위원으로 구성했죠. 사람이 판단하는 자리를 늘리는 쪽을 택한 거예요.

가산점 제도

큰 규칙 말고도 작은 재미 요소를 넣었어요. 무박 2일 해커톤과 다르게 뜨거운 현장 분위기를 조성할 수 없으니, 강제로 대화를 유도할 장치가 필요했죠. 예선에서는 가산 1점 차이로 본선에 오른 팀이 나올 정도로, 가산점 제도는 참여 열기를 끌어올렸어요.

리스크를 감수하고 우리 팀의 주제를 기꺼이 공개할 것인지, 제출까지 비밀을 유지할 것인지 치밀한 눈치싸움이 오고 갔습니다.

전사 행사로 확장하기

해커톤의 끝은 보통 심사와 시상으로 마무리돼요. 그러다 보면 이름이 불린 팀만 신나는 자리가 되기 쉽죠. 본선 당일에는 시상뿐만 아니라 전 구성원을 대상으로 AI를 활용한 네트워킹 프로그램을 진행했어요.

특히 반응이 좋았던 것은 AI가 그린 그림을 보고 프롬프트 키워드를 빙고로 맞히는 팀 게임이었어요. 그림을 보여주고, 어떤 프롬프트가 입력되었을지 정답과 오답 키워드를 섞어 제시하는 방식이었죠.

처음 만난 구성원들과 핸드폰이 아닌 스케치북을 들고, 삼삼오오 모여 고민하는 모습은 매우 인상적이었어요. 더욱 생생한 전사 행사 당일의 현장은 아임웹 팀블로그에서 확인해보세요.

예상 밖의 변화

첫 해커톤인만큼 절반에 가까운 많은 구성원들이 관심을 갖고 참여한 점도 의미있는 결과예요. 가장 인상적이었던 것은 구성원들에게 일어난 변화인데요.

기대한 것은 비개발자도 AI로 무언가 만들어볼 수 있다는 수준이었는데, 실제로는 그보다 멀리 갔어요. 참가자의 65%가 비개발 직군이었다는 점을 감안하면 더욱 그렇습니다.

이는 AI가 만든 변화라기보다, 해야 할 이유가 생겼을 때 사람들이 얼마나 빨리 움직이는지를 보여준 장면에 가까워요. 비교적 낮은 허들의 주제였지만 ‘옆 팀과 겹치면 어떡하지’라는 고민은 금방 사라졌어요. 평소라면 Docker는 개발자 영역이라며 지나쳤을 일도, 팀원과 함께 만들 것이 생기니 바로 실행에 옮겼습니다.

특히 ‘나는 개발을 못 하니까’라는 벽은 생각보다 얇았고, 이번 해커톤에서 가장 부시크래프트다운 장면이 많이 나왔습니다. 맨손으로 시작해 필요한 도구를 하나씩 주워 들고 결국 불을 피워냈으니까요.

마무리

일주일간의 해커톤 일정을 마치고 돌아보며 처음 서베이에서 봤던 두 문장을 되짚어 봅니다.