기간이 짧은 만큼 부담이 되지 않을 것이며 부트캠프와 같은 학습의 장은 안되겠지만 협업을 해보는 경험과 특히 이 스프린트 프로세스가 가지고 있는 힘을 알려주고 싶었습니다.
-테오 스프린트 1기 회고 중-

글을 읽기 전 알고 있으면 좋은 지식

• 테오의 구글 스프린트(체험) 1기 : 구글 스프린트를 이해하기 좋습니다.
• 테오의 스프린트 15기 : 최신 스프린트 회고이며, 테오 스프린트 방식을 이해하기 좋습니다.

해당 스프린트는 테오님이 진행하고 있는 테오 스프린트를 토대로 진행하였습니다. 테오 스프린트는 구글 스프린트를 모티브하여 실제 협업의 팁들을 추가한 스프린트입니다.

글 중간에 💡 아이콘에 담겨있는 글을 진행자를 위한 팁입니다. 스프린트 진행에 관심이 있으신 분들에게 좋은 훈수가 되길 빕니다.

테오 스프린트(체험) 1기에 참여해준 시뮨, 하이수, 단지, 제리, 팡이, 앨빈, 헬로월드, 메이, 니노 모두 감사해요!

프롤로그

2023년 7월, 어느 회사에 면접을 보게 되었다. 절었다. 당연히 결과는 안 좋았다. 기초쌓기 + 협업경험이 이 결과를 초래했다고 결론지었다. 나혼자 기초쌓기는 할 수 있지만 협업은 아니다. 과거에 협업 프로젝트에 참가해봤는데 몇 주 뒤면 각자의 열정이 식어 팀이 와해되었고 결과는 좋지 않았다.

우연히 시니어 프론트엔드 개발자 테오님의 진행하는 스프린트을 접하게 되었다.'협업'이라는 단어가 눈에 띄었다. 그리고 기간과 프로토타입. 테오 스프린트가 기반으로 하고 있는 구글 스프린트는 5일동안 정해진 프로세스에 따라 진행하면 프로토타입이 나온다. (자세한 설명은 구글 스프린트가 뭔가요?를 읽어보기 바란다)

내가 경험했던 협업 프로젝트는 5주면 결과물도 없이 사라진다. 그런데 5일만에 결과물이 나온다고?
심장이 두근거렸다. 1기부터 15기의 글을 읽으면서 뭔가 벅차올랐다.
'그래 이거다. 한 번 나서보자!'

1주일동안 글을 꼼꼼하게 읽으면서 분석했다. 혼자 아이디어를 내서 팀원들을 설득하는 상황도 재현해보고 목적, 대상, 가치 찾기도 혼자해봤다. 만족스러웠다.

스프린트 체험하실 분?

처음에는 분야별로 총 5명정도를 생각했다. 원작자에게 동의를 구하는 것이 마음이 편할 것 같아 테오님의 오픈채팅을 찾아가서 문의를 드렸다.

인원 미달이 아니고선 절대 도망 못 가는 장치와 약속을 만들었다. (왜그랬어!!!!!!!)

그리고 협업 프로젝트 사이트(Hola, 커리어리, 인프런)에 올렸다. 추가로 테오님의 오픈채팅방에도 올렸다.

협업 경험해보고 싶지 않으세요?
이 글을 읽고 계신다면 협업을 해보는 경험하고 싶은 생각이 있다는 겁니다. 그런데 이런 생각이 들 겁니다.
'장기 사이드 프로젝트는 뭔가 부담스러워.'
'예전에 단기 프로젝트를 해봤는데 어영부영 흐지부지 사라졌어요.'
(...중략...)
같이 도전해보실래요?
저도 실제로 참석해본적은 없는 스프린트입니다. 스프린트를 진행해본적도 없습니다. 이 글을 적는 순간에도 잘하는 짓인가 생각이 듭니다. 그런데 안하면 나중에 후회할 것 같습니다.
같이 ‘협업하는 자세’를 경험해보고 싶으신 분은 참가신청서를 작성하세요.

지금 읽어봐도 약을 많이 친 거 같다.

많은 분들이 관심을 보이셨고 참가신청서를 작성해주셨다. 나의 무게감은 스택처럼 쌓여져갔다.

DAY-준비

테오 스프린트 회고글을 보면서 활동을 정리했다. 목적, 타당성, 가치를 숙지하고 대략적인 소요시간을 계산했다. 진행자가 참가자들에게 '이렇게 되어 있으니까 하세요' 라는 것보다 '이 활동은 OO을 위해 합니다'라는 것이 더 설득력이 있다고 생각했다.
처음 접하는 메타버스 모임 장소도 만들고 (ZEP) 스프린트 준비 메일도 작성했다.

신청해주신 분들을 위해서라도 꼼꼼하게 준비해야겠다는 생각이 들었다. (저 J답지 않은 P같은 행동)

만나서 반가워요 👋 (D-DAY)

오후 8시. ZEP에 9분 모두 입장하셨고 스프린트가 시작되었다. 스프린트의 취지, 나아가려는 방향, 그라운드 룰, 피그잼 설명 방법을 안내했다.

아이디어 발표 -> 선정 -> 팀 분배

아홉명이라서 1~2팀으로 나눌 것으로 예상하고 먼저 아이디어부터 발표하도록 진행했다.
아직 어색한 분위기에서 아이디어를 발표하다보니 일부러 내가 호응을 많이 유도했다.
why? -> what? -> how? -> if? 작성 방식은 말하는 사람도, 듣는 사람도, 글을 읽는 사람도 마음을 편안하게 만든다.

💡 구글 스프린트는 팀 캔버스부터 시작하는데 참가자 전원이 한 팀으로 운영되지 않을 거라면 아이디어로 팀을 나누고 팀 캔버스를 하는 것이 시간을 줄일 수 있다. 진행자의 선택이다.

테오 스프린트는 한 팀당 6 ~ 8명, 최적 인원 7명을 추천한다. 우리는 두 팀으로 나눌 수 있었지만 구성원의 역할(기획, 디자이너, 개발)을 고려하여 한 팀으로 운영하기로 했다.

💡 디자이너 1명, 개발 2명(FE 1, BE 1)은 필수 역할군이라고 생각한다. 디자이너가 있으면 프로토타입이라고 하더라도 그럴싸하다. FE나 BE 둘 중 하나만 없어도 아이디어를 충분히 구현하기 힘들다.

최종선택된 아이디어! 일정관리 + 투표기능!

Team Canvas

팀 캔버스는 자신의 생각을 쓰고 말하는 시간이다. 듣고 있는 사람의 적극적인 리액션은 필수이다. 온라인으로 진행을 하면 듣고 있는 사람의 행동을 볼 수 없어 혼자 말하는 느낌을 받게 된다. 심지어 피그잼의 커서까지도 가만히 있으면 '컴퓨터가 멈추었나' 라는 상상까지 하게 된다. 하지만 내가 쓴 스티커에 뭔가 줄이 쳐지고 스티커가 붙여지면 '다 듣고 있구나'하면서 안심하게 된다. 다음 발표자까지도 안심하게 된다.

💡 진행자가 먼저 적극적인 리액션을 해주자. 받은 참가자가 다른 참가자에게 똑같이 하는 모습을 보게 된다.
💡 작성시간에 음악을 트는 것도 좋은 방법입니다. 재즈와 글쓰기. 낭만있지 않나요?

내가 팀장이 된다면 꼭 해보고 싶다. 오프라인임에도 불구하고 이런 팀 빌딩 시간은 발표자나 듣는 사람이나 모두 민망하다. 뭔가 끄적끄적 거릴 것이 필요하다. 피그잼을 만들어서 진행자가 큰 화면에 발표자의 스티커를 보여주고 발표자는 발표를 하고 듣는 사람은 발표자의 스티커에 낙서를 하면서 듣는다면 민망함도 줄고 집중도 잘 될 것이다.

DAY1 과제

우리 서비스(아이디어)의 목적, 대상, 중요하게 여겨야할 가치는 무엇입니까?

이 질문의 의도는 무엇일까?
아이디어는 정해졌지만 서로 생각하는 그림은 다르다. 맛있는 사과를 생각해보자. 누군가는 빨간 사과를 생각할 것이고, 어떤 이는 초록 사과를 생각할 것이다. '맛있는' 이라는 추상적인 개념이 다르게 생각하는 원인이다. 그래서 추상적인 개념을 정하는 작업이 필요하다.
테오 스프린트에서 이 작업을 '생각의 주파수를 맞춘다'고 한다. 하나의 주파수를 정하고 맞추는 것이 아닌 주파수를 펼치다가 서로 맞추는 작업이라고 생각하면 편하다. 이런 애매모호하고 로맨틱한 작업에는 위의 질문에 대한 생각을 하면 수월해진다.
즉, 각자의 기준을 생각해오는 것이 과제였다.

이제 시작이야! (DAY+2)

오늘은 자신이 생각하는 그림을 이야기하는 날이다. 이 날은 무언가를 정하는 것보다 각자의 생각을 이야기하고 수렴되는 날이다. 그래서 질문이 일곱가지나 된다. 질문마다 모든 사람이 답을 한다.

💡 참가자들에게 각 질문의 의미를 설명해줘야한다. 그리고 결정을 하는 것이 아니라는 것을 계속 상기시켜줘야 한다.

1. 우리 서비스의 목적과 대상 찾기

• 우리 서비스의 궁극적인 목적은 무엇일까요?
• 우리 서비스의 궁극적인 대상은 누구일까요?

이 질문은 시작점과 도착점에 대한 질문입니다.

2. 우리 서비스의 가장 중요한 가치

같은 아이디어를 가지고 비슷한 목적을 가진 서비스는 많지만 서로 다른 가치를 전달한다. 우리 서비스가 대상에게 전달할 가치에 대해 이야기하는 시간이다.

3. 자연스럽게 생각 합치기 - 워드 클라우드

이 시간은 구체적인 생각을 추상적인 단어로 합쳐보는 시간이다. 나의 생각, 다른 이의 생각, 다시 떠오르는 생각을 정리하는 과정이다.

앞선 과정에서 반복적으로 등장했던 단어가 하나로 모이는 느낌이었다. 마치 교훈같다.

💡 이미지에서는 단어의 카테고리별로 자리를 잡았는데 진행자의 권한으로 몰아서 볼 수 있도록 하였다.

4. 어떻게 하면 ~ 할 수 있을까 질문 찾고 답하기!

DAY2의 제일 중요한 과정이다. 앞선 과정의 단어를 다시 구체화시키는 작업이다.
'어떻게 하면 직관적인 UI를 만들 수 있을까?', '어떻게 하면 우리의 계획을 한 눈에 보이게 할 수 있을까?' 라는 질문을 적고 각자의 답을 아래로 나열하는 방식이다. 내가 하고 싶은 말이 있다면 질문을 만들어 답변을 달면 된다.
단, 질문이 무언가를 결정하는 투표가 되면 안된다.

그리고 UI/UX/개발 측면에서 풀어낼 수 있는 질문/답변만 할 것을 강조했다. 왜냐하면 홍보, 사업성은 스프린트에서 해결할 수 있는 문제가 아니기 때문이다.

💡 이 과정에서 일일 MC를 뽑았다. 시도해보고 싶었다. 참가자들이 더 많은 것을 말하는 기분이었다. 진행자와 MC의 차이가 있나보다.

💡 답변을 작성하는 시간에 레퍼런스를 요구했다. 참가자의 기분이 나쁘지 않게 '혹시 이 답변은 어떤 내용인가요? 관련한 화면이나 이미지를 볼 수 있을까요?' 질문을 했다. 기준은 내가 답변이 이해되지 않을 때였다.

이 과정을 하다가 다른 서비스보다 강조할 것이 생겨났다. 아이디어 안에 아이디어가 나온 것이다. 내용은 투표에 참가하지 않는 사람에게 벌칙을 주는 것이다. 다들 뭔가 한이 있었나보다.

💡 처음에는 없었던 질문이다. 어떻게 하면 차별화할 수 있을까 라는 질문의 답변에 벌칙, 벌금이 있었는데 흘려보내기에는 너무 아쉬웠다. 좋은 아이디어라 생각해서 질문을 따로 생성해서 다시 진행했다.

5. 서비스에 넣고 싶은 요소 찾기

개발 범위, 스프린트 기간은 생각하지 않고 서비스에 넣고 싶은 요소를 써내려가는 과정이다.

6. 스토리보드 - 우리가 찾아낸 기능을 같은 화면 기준으로 분류해주세요!

같은 화면에 있어야 하는 기능들을 분류하는 과정이다. 분류가 되면 기능에 맞는 UI를 생각해 오는 것이 다음날의 과제가 된다.

일정관리, 일정생성, 외부공유, 투표, 기타(설정같은) 화면으로 나누었다.

DAY3 과제

오늘까지는 자신의 생각을 발산하는 시간이었다면 내일부터는 본격적인 결정을 하는 시간이다.

일정 연장

당초 5일로 예정되었던 스프린트를 연장할 필요를 느꼈다. 개발일정이 하루 밖에 되지 않는다. 아무리 기능을 축소한다고 하더라도 환경세팅만 하루가 걸릴 것으로 예상했다. 페어코딩에 기대를 하는 분들이 많아서 개인적으로는 개발기간을 늘리고 싶었다. 그래서 참가자들에게 의사를 물어봤다.
충분한 이야기를 나누어서 수, 목에는 스케치 + 역할 분배를 금, 토, 일에는 개발을, 월요일날 테스트 + 회고를 하기로 결정했다.

💡 테오 스프린트 1기에서는 5일 일정이었는데 이후부터는 일정이 늘어났다. 아이디어를 펼치고 정리하는 기간만 3일이라서 개발하는 기간이 하루인 것이다. 참석자의 대부분이 개발자인 것을 감안하면 개발기간을 주말로 몰아서 시간적 여유를 주자는 취지인 것 같다. 나도 동의한다. 페어코딩과 개발 협업을 경험해 보고 싶은 참가자들이 많다. 그들에게 자리를 마련해주자는 것이 이 스프린트를 만든 취지이다. 그렇기에 개발기간을 늘리는 것이 좋다고 생각한다. 다음 스프린트는 일정을 이렇게 할 듯하다.

스케치 (DAY3)

이 날은 자신이 생각하는 화면을 그려오고 그 생각을 정리하면 화면을 결정하는 날이다. 그래서 결정권자도 뽑는다.

각자 과제를 열심히 해왔다. 레퍼런스도 가지고 오고 자신만의 플로우도 만들어왔다. 발표를 하고 발표자에게 질문하는 시간을 갖았다.

그리고 UI/UX를 담당하는 최고권위자와 프로젝트를 이끌어줄 리더도 뽑았다. (두 분 고생 많으셨습니다)

그리고 페이지별 기능을 정하는 과정을 했다.

이 과정에서 문제가 생겼다. 화면 결정의 진도가 안 나가는 것이다. 시간에 조급하지 말자라는 생각을 했지만 참가자들 역시도 힘들어 했다. 새벽 2시가 되어서 진행자의 권한으로 회의를 중단하고 내일로 미루었다.

위기였다. 매끄럽게 진행이 안된다. 새벽에 혼자 고민을 했다. DAY2의 페이지 구성을 하지 않은 것이 화근이었다. 페이지 구성이 없는 상태로 각자의 스케치를 그려오니 페이지의 연관관계가 다 제멋대로였다.
또, 키워드 중에 많은 득표를 받은 '한 눈에 보이는 우리 계획'을 구체화하는 것을 잊었다. UI/UX 결정 기준의 키워드를 놓쳤다.

DAY2에서는 자신의 생각을 발산하는 시간이라고 생각하여 무언가를 결정하는 것을 피했는데 페이지 구성까지는 수렴을 해야 했던 것 같다. 참으로 아쉽다.
테오 스프린트에서도 우리와 같은 일이 발생했다. 그 팀도 뭔가 이상함을 감지하고 앞선 과정의 내용들을 찬찬히 훑어 보았다. '잃어버린 우리의 컨텍스트를 찾아서'로 팀이 나가는 방향을 잡았다.

일련의 사고로 인해 지금까지 과정이 중요하다는 것을 다시 한 번 느꼈다. 이전에 적어둔 우리 생각이 지금 우리 생각의 레퍼런스가 되고, 기준이 되는 사실이 신기했다.

💡 참가자들이 헤매는 느낌이 든다면 진행자가 앞선 과정을 정리해주는 것도 좋은 방법인 것 같다.

참가자들에게 사과의 메일을 보냈고 DAY4에 진행할 과정을 상세하게 설명했다.

💡 일정이 끝나고 다음날 일정에 대한 계획표를 보내자. 참가자들도 준비를 할 수 있다.

페이지 UI 결정 (DAY4)

1. 페이지 구성 결정

우리 서비스의 구석구석을 화면단위로 연결해보았다. 참가자들이 대부분 서비스를 이용해본 적은 있지만 만들었던 경험은 적었다. 그래서 잠깐 개입을 하여 같이 프로세스를 구성해보았다.

이미지에 나온 문구 중에 '플로우' 관련한 이야기는 아래에서 자세히 다루겠다.

💡 테오 스프린트는 참가자들에게 많은 자유도를 준다. 하지만 잘못된 방향으로 흘러가는 것은 어느정도 선에서 진행자가 막고 가이드라인을 만들어줘야 한다. 협업을 경험하는 것에 더 집중해야 한다. 우리는 사업을 하러 온 것이 아니기 때문이다. 당연히 먼저 개입을 해서 막기보다는 참가자들이 원하거나 헤매는 모습이 보인다면 개입하는 것을 추천한다.

2. 페이지마다 스케치 & 페이지 UI 결정

앞선 과정에서 페이지 구성을 결정해보았다. 이제 페이지마다 자신이 생각하는 UI를 그리는 것이다. 어제 이미해보았기 때문에 다들 수월하게 그렸다.

페이지가 많은데 왜 두 페이지만 나왔느냐? 페이지마다 모든 참가자들이 그리는 것보다 한 페이지마다 각자의 의견을 내겠다고 하였다. 테오 스프린트의 방식은 아니지만 참가자들의 의견이므로 동의하였다.

팀에 디자이너가 없어서 진행자가 디자인을 해주기로 하고 주요 기능만 스케치를 진행했다.

💡 스프린트에서 디자이너는 필수이다. 그럴싸함을 매우 그럴싸하게 만들어준다.

3. BDD & SDD로 개발 설계하기

PL 역할을 담당한 앨빈의 강의 덕분에 참가자들이 태스크를 쪼개는 행위부터 처리하는 방법까지 쉽게 이해할 수 있었다. 강의나 유튜브에서 배우기 힘든 것을 배울 수 있는 기회였다.
(앨빈 고생했어요~)

시간 관계상 실제로 태스크를 나누는 것은 내일로 미루어졌다.

4. 기나긴 DAY4를 마치며

어제 끝났어야 하는 것이 오늘까지 넘어왔다는 점이 아쉬웠다. 뭔가 시간에 쫓기듯 과정을 해가는 것도 아쉬웠다. 그래도 참가자들이 모두 늦은 시간까지 열정적으로 참여하는 모습을 보며 스프린트에서 좋은 경험을 얻어갈 수 있도록 내가 최선을 다해야겠다고 생각했다.

이제 개발 시작! (DAY5)

개발 환경세팅을 하기 전에 우리 서비스의 이름을 만들었다.

공감, 일상, 공유를 줄여서 공일공(zero-one-zero)!

PL이 준비한 Git/버전관리 강의를 들으면서 레포지토리를 어떻게 할지도 결정을 했다.

💡 테오 스프린트의 진행 순서대로 하면 좋지만 상황에 따라 변화하는 것도 나쁘지 않다고 본다.

페어프로그래밍 팀 정하기

많은 참가자들이 이 과정을 기대하였다. 사수분을 통해서 알게 되었는데 많은 것을 배워갈 수 있는 시간이었다. 그래서 좋은 경험을 많은 사람과 할 수 있도록 경력 유무로 참가자를 나누고 경력자를 로테이션하기로 했다. 나도 경력자로 참가하였다. 백엔드 참가자가 한 명이라서 내가 훈수꾼으로 DB설계정도까지만 도와드리기로 했다.

태스크 나누기/선점

프론트팀은 PL의 지도하에 화면 단위로 태스크를 나누고 각자 하고 싶은 태스크를 선점했다.

백엔드팀은 화면을 보면서 DB설계를 진행했다.

조금 줄여볼까요?

나와 니노(백엔드팀)가 페이지 UI를 보면서 DB설계를 하는데 결정된 것이 너무 없어서 난항을 겪고 있었다. 어느정도 DB설계를 해 본 경험이 별로 없는 것도 한 몫을 하였다.

개발 범위가 너무 크다라는 생각이 들었다. DB상으로도 테이블이 6개 정도는 나오고 있고 프론트에서 나눈 태스크를 보니 주말가지고는 그럴싸한 데모도 안 나올 것 같은 느낌이 들었다.

그래서 모든 참가자들을 한 곳으로 모이게 했다.

이 스프린트는 우리 서비스의 가능성을 테스트하기 위함이다. 그러기 위해 데모가 나와야 한다. 하지만 이 전체를 만들기에는 시간이 부족하고 개발 범위를 축소해야 한다.

모두 공감했다. 서비스의 차별성을 강조하기 위해 투표 기능과 미참여자 벌칙 기능을 먼저 구현하기로 했다.

해당 부분만 UI와 FLOW를 빠르게 만들었다.

💡 PL과 싸인이 맞지 않아 개발 범위를 정하는 과정를 하지 않으면서 이런 상황이 발생한 것 같다.

개발 중입니다 (시연 D-2, D-1)

이틀동안 주말을 포기한 참가자들은 열심히 개발을 했다. 다들 늦은 시간(다음날 아침)까지 개발을 하고 점심쯤 지나면 한두명씩 다시 나타났다. 나는 백엔드팀과 프론트팀을 돌아다니면서 응원의 메시지를 보냈다.

테스트 및 회고 (D-Day)

테스트

스프린트의 마지막 날이 밝았다. 혼자 회고를 하기 전에 피그잼을 돌아보면서 이런저런 생각을 했다. 참가자들의 열정이 담겨져있는 피그잼이었다.

테스트를 진행했다. 백엔드와 프론트의 연결 문제로 인해 원활하게 진행은 하지 못했지만 이렇게 만들어졌다는 것이 좋았다. 추가 프로젝트를 진행하여 기능도 추가하는 것으로 테스트를 마무리 지었다.

이렇게 아이디어 -> 기획 -> 설계 -> 디자인 -> 구현 -> 배포 라는 큰 사이클을 짧게 경험을 해보았다. 협업의 맛도 살짝 맛보았다.

회고

테오 스프린트의 회고 방식대로 회고를 진행했다. 가장 아쉬움이 남는 거 나였다. 매끄럽지 못한 진행으로 인해 참가자들의 시간과 노력이 많이 소모된 것 같아서 미안했다.

테오 스프린트(체험)을 마치며

Role : 진행자

처음에는 구글 스프린트를 토대로 만들었기에 테오 스프린트(구글 스프린트)라고 적었다. 진행하면서 구글 스프린트를 지워버렸다. 구글 스프린트가 기반이었기는 하지만 추가된 내용과 방식이 구글 스프린트라는 존재를 잊게 만들었다.

스프린트를 준비/진행하면서 가장 도움이 되었던 것은 지금까지의 테오 스프린트 관련 글이었다. 나에게는 이정표 같았다. 과정마다 왜 하는지? 어떻게 진행했는지? 어떤 결과물이 나왔는지?가 상세히 적혀있었다. 이것을 보고 따라하면서 기록의 중요함을 느꼈다.

퍼실리테이터의 역할인데 참가자들의 의사결정에 개입을 너무 많이 한 것 같아서 아쉽다. 다음 기수에는 개입을 덜 해보려고 한다.

누군가 프로젝트를 시작한다면?

결과물을 원한다면 적극 추천해주고 싶다.

사이드 프로젝트, 토이 프로젝트는 개발관련 일을 하는 사람이라면 꼭 해보고 싶어한다. 아이디어 -> 기획 -> 설계 -> 디자인 과정이 정말 어렵다. 이 과정에서 같은 뜻을 가진 사람들끼리 다툼없이 온전한 아이디어를 표현하기는 힘들다. 그 힘듬을 줄여주는 것이 테오 스프린트이다. 각자의 생각을 발산하여 수렴하는 주파수를 찾는다. 애매모호하지만 경험해보면 구체적인 방식이다. 실제로 참여해보면 좋지만 안된다면 테오 스프린트 관련 글을 읽어보고 따라하는 것을 추천한다.

현업에서는 개발자가 아이디어 -> 기획 -> 설계 -> 디자인 과정에 참여하는 일은 거의 없다. 테오 스프린트를 통해 경험하면 위의 과정을 참여하지는 않았지만 프로젝트의 핵심 가치를 찾게 될 것이고 다른 직군과의 협업에 도움이 될 것이다.

감사인사

테오 스프린트(체험) 1기에 참여해준 시뮨, 하이수, 단지, 제리, 팡이, 앨빈, 헬로월드, 메이, 니노 모두 감사해요!

그리고 테오님께도 감사의 인사 드립니다. 정리해주신 회고글로 인해 진행자의 경험을 하게 된 것 같습니다.

Cookie

키유의 테오 스프린트(체험)은 멋지게 키유의 스프린트로 돌아옵니다.
Coming Soon...