9oormthon RAID SPRING 사내 해커톤 후기 : 푸르미를 만든 네 명의 구르미 이야기

현충일을 하루 앞둔 6월 5일. 징검다리 연휴를 맞아 산과 들, 바다로 휴식을 떠나며 평소보다 일찍 판교에 어둠이 짙게 내렸다. 판교 PDC 9층에 위치한 구름스퀘어만이 자정이 다 되도록 어둠속에서 불을 밝히고 있었다. 그곳에서는 9oormthon RAID SPRING이 한창이었다. 

9oormthon RAID SPRING은 구름의 첫 사내 해커톤이다. 6월 5일 오전 10시부터 다음날 오전 10시까지 24시간 동안 진행됐다. 총 다섯 팀이 ‘생성형 AI를 활용해 구름 서비스와 백오피스 업무 개선’이라는 주제로 참가했다. 

이 글은 9oormthon RAID SPRING에 참여한 ‘제일 모로’ 팀의 제시카(Jessica)와 로아(Roah), 해커톤 운영자 스노우(Snow)가 정리한 그날의 기억이다.

by Jessica, Roah, Snow

사내 해커톤이 열린다고욧?!

한가롭던 어느날 슬랙 채널에 올라온 공지에 구르미(구름에서는 구성원을 구르미라고 부른다)들은 한껏 들떠 있었다. 구름의 첫 사내 해커톤이 개최된다는 소식 때문이었다. 사내 해커톤이 열리기를 손꼽아 기다렸지만, 한참 바쁜 시기라서 참여를 망설이는 이들이 많았다.

그럼에도 몇몇은 참여에 적극적이었다. IDE SQD에서 풀스택 개발을 하는 모노(Mono)도 그 중 한 명이었다. “함께 참가할 분 찾아요”라는 9oormthon RAID 슬랙 채널에 모집 공고에 구름LEVEL 서비스 기획과 프로그래밍 콘텐츠 제작 업무를 맡은 일리움(ilium), SRE 스쿼드에서 인프라 엔지니어 직무를 맡고 있는 로아가 속속 손을 들었다.

모노가 ChatGPT 프롬프트(prompt)와 백엔드를, 로아가 ChatGPT API와 프론트엔드 개발을, 일리움은 서비스 기획을 맡았다. 남은 건 디자이너 한 명. 해커톤에 익숙치 않아서일까. 디자이너는 쉽게 섭외되지 않았다. 계속 시간만 보낼 수는 없는 일. 우선 팀 이름과 아이디어부터 정해야 했다.

우승 향한 집념이 팀 이름과 아이디어로

세 사람이 처음 마주한 자리에는 어색함보다는 기대와 자신감이 넘쳤다. 팀 이름은 그리 어렵지 않게 정할 수 있었다. ‘제일 모로’다. 순 우리말 ‘모로’는 햇무리, 달무리와 같은 대기광학 현상을 의미한다. 우승을 목표로 한 만큼 ‘여럿 가운데서 첫째가는 것’이란 의미의 ‘제일’을 붙여 제일 모로라고 이름을 지었다.

이번 해커톤의 주제는 생성형 AI를 활용해 구름 서비스와 백오피스 업무를 개선하는 것이었다. 고객 문의를 생성형 AI로 답하는 서비스 등 여러 아이디어가 나왔다. 그중 우리가 정한 주제는 ‘함수형 알고리즘 문제 생성기’였다.

완전히 새로운 아이디어는 아니었다. 구름의 코딩 테스트 서비스인 구름DEVTH에서 예전부터 페인 포인트(지속적으로 고객에게 불편을 초래하는 상품/서비스)로 논의된 주제였지만 아직 제공하지는 못하고 있었다.

이 아이디어를 정한 데에는 비즈니스적인 이유도 있었다. 경쟁 서비스는 함수형 문제가 늘어나는 추세인데, 구름LEVEL과 DEVTH는 아직 제공하지 못하고 있다. 함수형 문제 유형에 대한 고객 선호도도 높아서 제공을 더 이상 미룰 수 없었다.

함수형 알고리즘 문제 제작은 일반형 문제보다 더 많은 시간이 든다. 이를 자동화한다면 분명 심사위원에게 좋은 점수를 받을 수 있을 터였다.

디자이너 모셔요!

팀 이름과 주제는 정해졌고, 마지막 팀원만 모으면 됐다. 틈틈이 디자이너를 모시고자 주위에 제안했지만 하나 같이 거절할 뿐이었다. 신청 마감일을 며칠 남기지 않은 어느날. 슬랙 채널의 디자이너 모집 글에 누군가가 수줍게 ‘손’을 들었다. Edu Biz Division에서 교육운영매니저로 일하는 제시카였다. 그녀의 대학 전공이 ‘디자인’이라고. 고민할 것은 없었다. 제일 모로 팀이 온전한 ‘팀’이 된 순간이었다.

Q. 참가 이유가 궁금해요!

일리움_ 구름LEVEL 서비스 기획과 프로그래밍 콘텐츠 제작 업무를 담당하고 있어요. 해커톤에 참가할 당시에는 직무가 제작에서 기획으로 막 바뀌었을 때라서 기획자로서의 능력을 증명해 보고 싶었죠. 해커톤이 바로 그 기회였어요.

제시카_ 작년 겨울에 교육운영매니저로 구름에 입사했어요. 수강생과 소통하는 일을 주로 하는데, 코딩 교육 콘텐츠에도 관심이 생겨 콘텐츠 개발, 기획 관련 업무도 맡고 있어요. 평소 함께 일해본 적 없는 분들과 함께 무언가를 만들 수 있다는 기대에 해커톤에 참가했어요. 무엇보다 백오피스 프로덕트를 만들며 구름 내부 구성원이 업무를 하며 느끼는 페인 포인트와 니즈를 고민해볼 수 있는 기회라 생각했죠.

모노_ IDE SQD에서 풀스택 개발을 하고 있어요. 요즘은 개발보다는 비즈니스 일을 더 맡고 있지만요. 유지보수와 새로운 프로덕트를 만드는 것은 완전히 다르잖아요. 스스로 부족함을 느끼던 차에 내 실력을 확인하고 싶어 해커톤에 참여했어요. 

로아_ SRE SQD에서 인프라 엔지니어 직무를 맡고 있어요. 조금 생소할 수 있는데 SRE SQD는 구름 전체 서비스에 대한 구축, 모니터링, 장애 대응을 담당하고 있어요. 인프라 자동화도 맡고 있죠.

구름 입사 전에 IT 벤처 창업 동아리에서 여러 해커톤을 경험해봤어요. 개발자로 직접 참여하기도 하고, 해커톤을 직접 운영해보기도 했죠. 무박 2일 동안 팀을 이뤄 한 가지 제품을 만드는 일이 얼마나 즐거운지 이미 알고 있었죠. 생성형 AI를 활용해야 한다는 주제가 특히 재밌어 보였어요.

‘근거’가 필요해

새로운 팀원이 합류한 만큼 아이디어를 재검토하는 시간을 가졌다. 서로 다른 비즈니스에서, 다른 일을 하기에 ‘아이디어’에 대한 이해 정도는 제각각일 수밖에 없었다. 아이디어를 구현할 구성원부터 ‘아이디어’와 ‘비즈니스’를 명확히 이해할 필요가 있었다.

아이디어를 구체화하면서 왜 이런 서비스가 필요한지, UI는 어떻게 제공되면 좋을지 고민이 커졌다. 그때 제시카가 “그럼 설문조사를 해볼까요?”라고 제안했다. 고객 니즈도 파악하고 서비스에 대한 이해도 높인다면 기획의 근거도 마련하고 UI 디자인의 실마리도 찾을 수 있지 않을까 하는 생각에서였다.

일은 일사천리로 진행됐다. 제시카가 설문조사 초안을 작성하고, 일리움은 알고리즘 콘텐츠 크리에이터로 일한 경험을 살려 첨언을 했다. 설문조사는 알고리즘 스터디 커뮤니티, 그리고 팀원들의 동료(개발자)들에게 일일이 부탁해 받았다. 50여 명이나 시간을 내 응답해줬다. 다음은 설문조사 결과.

설문조사 결과는 예상과 크게 다르지 않았다. 아니 우리의 생각이 정확히 적중했다. 응답자 81%가 함수형 문제를 더 선호했다. 그 이유는 입출력을 고려하지 않아도 되고, 로직(문제 풀이)에만 집중할 수 있기 때문이었다. 코딩 테스트를 준비할 때 함수형 문제를 많이 풀었기 때문에 익숙하다는 의견도 있었다.

설문조사로 ‘아이디어’에 대한 믿음이 확고해졌다. 고객이 어떤 점을 어려워하고 무엇을 바라는지도 알 수 있어 개발과 UI 디자인의 방향을 정하는 데에도 큰 도움이 됐다.

각자의 일이 있는 상황에서 팀원 모두가 한 마음, 한 뜻으로 참여하기는 쉽지 않은 일이다. 잘 공감되지도 않고 이해되지 않는 아이디어를 구현한다면 더 그럴 것이다. 우리가 설문조사로 얻은 가장 큰 수확은 아이디어에 대한 확신이 생겼다는 점이었다.

9oormthon RAID SPRING 막이 오르다

6월 5일 오전 10시. 그토록 기다리던 구름의 첫 해커톤의 막이 올랐다. 총 다섯 팀이 참가했다. 간단한 행사 소개 이후 각 팀의 베이스캠프가 정해졌다. 베이스캠프로 이동하는 발걸음은 가벼웠다. 초조한 마음도 없었다. 누구보다 철저히 많은 것을 미리 준비했기 때문이었다.

누가 시킬 것도 없이 우리는 각자 맡은 일을 하기 시작했다. 제시카는 UI 시안을, 모노는 ChatGPT 프롬프트와 백엔드를, 로아는 프론트엔드 개발과 ChatGPT API 연동 개발을 맡았다. 일리움은 기획이 모두 끝났기에 발표자료를 준비했다. 우승을 위해서는 발표도 매우 중요했다.

디자인은 순조로웠다. GDS(Goorm Design System)를 이용한 덕분이었다. GDS는 피그마에 UI에 사용되는 각각의 컴포넌트를 구름 스타일로 미리 디자인해 놓은 일종의 템플릿이다. 각 컴포넌트를 배치하며 UI를 디자인할 수 있다. 서비스를 빠르게 디자인하면서도 구름 서비스의 디자인 통일성을 유지할 수 있다.

개발에도 큰 어려움은 없었다. 생성형 AI로는 ChatGPT를 쓰기로 일찌감치 정했다. 차후 구름LEVEL 서비스에 내장할 수도 있기에 구름의 기술 스택을 그대로 사용하기로 했다. 개발 도구로는 구름의 클라우드 기반의 통합개발환경인 구름IDE를 사용했다. 평소에 구름IDE로 구름 서비스를 개발하고 있고(강제사항은 아니다), 구름의 기술 스택(리액트, 노드JS) 또한 구름IDE에서 기본 스택으로 제공하기에 직접 개발 환경을 구축하는데 시간을 소모할 필요가 없었다. ChatGPT를 제외하면 새로 배워야 할 것은 없는 셈.

프롬프트를 공략하라

가장 어려웠던 것을 한 가지 꼽는다면, 다름 아닌 ‘프롬프트’였다. 프롬프트의 사전적 의미는 연극에서 대사나 동작을 지시하고 상기시켜주는 일이다. ChatGPT와 같은 생성형 AI에서 프롬프트는 AI에게 어떤 일을 해야 하는지 자연어로 설명해 원하는 결과를 출력하도록 하는 입력값을 말한다. 프롬프트에 따라 ChatGPT 답변의 품질이 크게 달리지기 때문에 이번 아이디어 구현은 프롬프트에 달려있었다.

ChatGPT에게 ‘알고리즘 콘텐츠 크리에이터’라는 역할을 부여하고, 역할에 따른 업무를 System으로 정의했다. ChatGPT에게 정해 코드를 전달하고 받은 결과는 함수형 문제와 입력 코드로 나눠 출력하도록 프롬프트를 작성했다. 콘텐츠 변수명과 지문 컨벤션을 학습시키고, 함수형 코드 템플릿도 학습시켰다. 요구가 명확해야 올바른 결과가 나오기 때문에 프롬프트는 수정하고 또 수정했다. 프롬프트는 그야말로 시간과의 싸움이었다.

함수형 알고리즘 문제 제작기 ‘푸르미’

각고의 노력 끝에 우리는 함수형 알고리즘 문제 제작기를 완성할 수 있었다. ‘푸르미(Foormee)’란 이름도 지었다. 푸르미에서 푸(foo)는 변수명이나 함수 이름을 아무거나 쓰는 이름이다. ‘푸’에 구름 구성원을 부르는 ‘구르미(goormee)’를 합친 합성어다.

푸르미는 하나의 정해 코드를 주면 다양한 함수형 콘텐츠를 제작해준다. 제작자에게 UI가 친숙하고 구름 서비스에 쉽게 내장할 수 있게 고안했다. 차후 푸르미가 구름DEVTH에 내장된다면 코딩 테스트 응시자가 선호하는 문제 타입을 정하도록 할 수도 있을 거다.

가령, 푸르미에게 다음과 같은 정해 코드를 함수형으로 변환하도록 일을 시키면 푸르미가 함수형 문제(A 부문)와 입력 코드(B 부문)를 각각 나눠 만들어준다. 응시자는 함수형 문제(A 부문)를 보고 문제를 푸는 식이다. 일반형 알고리즘 문제를 함수형으로 바꾸는 데 약 20분이 걸렸다면, 푸르미는 1분 내외면 충분했다.

정해 코드(파이썬)

import sys
input - sys.stdin.readline
n = int(input())
arr = list()
for _ in range(n):
	s, e=map(int, input().split())
	arr.append([s, e])
arr.soft(key=lambda x : (x[1], x[0]))
count = end = 0
for s, e in arr:
	if s > end:
		count += 1
		end = e
print(count)

푸르미 변환 결과(파이썬)

#A 부문(함수형 문제)
def solve(n, arr):
	result = 0
	return result

#B 부분(입력 코드)
import sys
input = sys.stdin.readline

n = int(input())
arr = list()
for _ in range(n):
	s, e=map(int, input().split())
	arr.append([s, e])
print(solve(n, arr))

해커톤이 남긴 것

6월 6일 오전 9시. 이제 해커톤 발표만이 남았다. 기획자 일리움이 심사위원과 참가자들에게 ‘푸르미’를 소개했다. 함수형 알고리즘 문제 제작기란 아이디어를 내고 문제를 정의하고 어떻게 해결할 수 있는지 차분하게 발표했다. 흔히 말이 씨가 된다고 한다. 말을 조심하라는 이 격언(?)처럼 우리는 우승했다. 

1박 2일. 24시간을 밤새 쉬지 않고 개발에 몰입한다는 것은 쉽지 않았다. 우리는 하나고, 공통된 목표를 향해 피곤한 줄도 모르고 해커톤이란 ‘마라톤’을 완주했다. 그렇게 구름의 첫 사내 해커톤 9oormthon RAID SPRING의 막은 내렸다. 우리 모두 각자의 자리로 돌아갔지만 해커톤에 참가한 20명의 구르미가 보여준 ‘열정’은 우리 모두의 기억 속에 오래도록 기억될 것이다. ☁️

Q. 기억에 남는 점은 무엇인가요?

일리움_ 처음으로 함수형 알고리즘 코드가 무사히 변환되었을 때가 기억납니다. 기쁜 마음 한 켠에는 이게 왜 대단한 것인지 어떻게 이해시킬지 걱정되더군요. 알고리즘 크리에이터로서의 경험과 제시카가 도와준 설문조사가 큰 도움이 돼 ‘푸르미’를 잘 어필할 수 있었습니다.

제시카_ 우선, 다른 팀(Division, Squad) 분들과 소통하며 제가 이제껏 제대로 알지 못했던 구름 서비스를 직접 경험하는 흔치 않은 기회였습니다. 특히 일리움과 함께 기획, 디자인을 하며 프로토타입을 만들고 로아, 모노의 피드백으로 디자인과 기능을 수정하며 완성도를 높인 일이 특히 기억에 남네요.

가령, 파이썬, 자바스크립트, C++ 언어로 변환하는 기능을 토글(On/Off)로 제작을 했는데, 체크 박스로 바꾸고 생성하기 버튼, 초기화 버튼을 하단에 두자는 피드백을 받았었습니다. 사용자 흐름상 UI, UX가 한결 더 자연스러워졌죠. ChatGPT가 코드를 변환하는 데에는 시간이 걸릴 수밖에 없는데, 프론트엔드 개발 과정에서 프로그레스 바(Pregress Bar)를 추가하자는 의견에 따라 UX를 개선하기도 했죠. ‘함께’ 일한다는 의미를 다시금 생각하게 되는 일이었습니다.

모노_ 우리 팀뿐 아니라 참가한 다섯 팀 모두 끝까지 포기하지 않고 완주해다는 게 가장 인상적이었습니다. 저는 지쳐서 틈틈이 쉬곤 했는데, 다른 분들은 잠시도 쉬지 않고 밤을 꼬박 세더군요. 특히 해커톤이 끝난 후 나온 결과물을 업무에 사용하는 것을 보고, 이번 해커톤의 의미를 다시금 생각하게 되었습니다.

로아_ 실제 사용자의 ‘니즈’를 확인했던 것이 생각납니다. 개인적으로는 알고리즘 문제를 풀 때, 일반형 문제를 선호합니다. 그래서 함수형 문제에 대한 사용자 니즈가 무척 궁금했는데요. 제시카의 제안으로 한 설문조사 결과를 보니 제 생각이 틀렸더군요.

함수형 알고리즘 문제에 대한 사용자 니즈를 확인하고 나니 아이디어에 대한 믿음이 더 커졌습니다. 개발 방향성을 잡고 사용자 경험을 개선하는 데에도 큰 도움이 됐죠. 사용자의 목소리를 들으며 아이디어를 발전시키는 과정에서 제품이 더욱 탄탄해진 것 같습니다.

Q. 끝으로 하고 싶은 말을 남겨주세요.

일리움_ ‘주제’에 대해 이렇게 깊게 고민해본 적은 처음이었습니다. ‘구름’스러우면서, 고객이 원하는 무언가를 찾아내는 게 어려웠거든요. 이전에도 몇 번 해커톤을 참여한 적이 있었는데, 대충 이렇게 하면 되겠지 생각하고 개발하곤 했었습니다. 이번 해커톤에서는 고객 니즈가 무엇인지, 왜 이런 니즈를 가지고 있는지, 어떻게 만족시킬 수 있을지를 고민하는 과정에서 기획자로서 스스로 더 성장했음을 느꼈습니다.

제시카_ 이번 해커톤에 디자이너로서 참여했는데, 시안 디자인이 늦어져 개발이 늦어지면 어떡하지 걱정이 컸어요. 하지만 팀원들이 피곤한 와중에 끝까지 제품의 완성도를 높이기 위해 함께 고민하고 의견을 줘 고마웠습니다. 모노, 로아, 일리움 모두 감사합니다.

모노_ 접점이 없는 분들과 함께 일하며 서로 배우고 성장하는 좋은 자리였다고 생각합니다. 현업에서 벗어나 다소 생소한 기획과 개발을 하며 현업에 더 몰입할 수 있는 에너지를 얻을 수 있었습니다. 담당 제품이 아닌 다른 제품에 대해 고민해볼 수 있었던 점도 좋았고요.

로아_ 이 아이디어를 처음 제시하고 발표까지 한 제일모로의 기획자 일리움, 사용성을 고민하면서 구름과 어울리는 멋진 디자인을 한 디자이너 제시카, 제품 개발을 끝내도 쉬지 않고 코드 리팩토링까지 한 개발자 모노가 있어 우리가 우승할 수 있었습니다.

9oormthon RAID SPRING에서 만들어진 제품들이 구름에서 서비스될 때까지 기다려주세요. 마지막으로 같이 밤을 새며 멋진 해커톤을 준비한 운영자에게도 감사의 말씀을 전합니다.