박성현님의 아티클

대학생들이 3주동안 몰입하여 서비스를 만든다면?

안녕하세요 저희는 IT 협업 동아리 PARD입니다!

파드는 경북권 대학생들의 IT 협업의 장이 부족하다는 문제를 해결하기 위하여 만들어진 동아리로, 'Pay it forward' 라는 가치 아래에서 서비스 기획, 개발, 디자인 직군의 대학생이 모여 함께 현업의 스킬을 공부하고 실제 프로덕트를 구현할 뿐 아니라 '어떻게 협업을 잘하는 사람이 될 것인가?'를 함께 고민하는 동아리입니다!

(파드의 성장과정이 궁금하다면? 다음 링크를 참고해주세요!)

이러한 파드는 벌써 네번째 파도를 맞이하고 있는데요, 현재 파드 4기는 파드 활동의 꽃, 롱커톤을 진행하며 한 기수의 종착지인 데모데이를 일주일 앞두고 있습니다.

롱커톤은 6주간의 세미나와 다양한 활동을 통해 실력을 다진 기획,디자인, 개발 파트원들이 팀을 이뤄, 한명 이상의 라이브한 사용자를 유치시킬 수 있는 배포가능한 수준의 프로덕트를 3주안에 만들어야 하는 파드만의 해커톤입니다.

이 롱커톤의 결과물을 볼 수 있는 롱커톤 데모데이에 여러분을 초대합니다.

일시: 2025년 1월 4일(토)

장소: 포항 한동대학교 김영길 그레이스 채플

이번 파드 4기의 롱커톤 주제는 바로 'FORWARD' 입니다.

각팀은 현재 몰입하여 FORWARD 라는 주제를

-모니터링을 통한 발표력 향상

-쉬운 여행 약속 생성

-효과적인 계획표 생성

-특별한 여행 아카이빙

-탁월한 팀프로젝트 진행

등의 다양한 서비스로 풀어내고 있습니다.

이번 데모데이에 오시면 다음과 같은 경험을 가져가실 수 있습니다.

• 대학생들이 3주동안 몰입하여 만든 서비스 결과물과 현업 심사위원들의 평가를 들을 수 있는 데모데이 발표

• 구현한 서비스를 직접 사용해 볼 수 있는 서비스 부스

• 서비스 발표팀, 파드의 운영진, 현업자 심사위원 분들과 자유롭게 이야기를 나눌 수 있는 네트워킹 시간

그외에도 경품추첨부터 파드의 웰컴 굿즈 등 청중 분들의 경험을 위한 다양한 이벤트를 준비하고 있습니다. 대학생 IT씬에 관심이 있으신 분들은 이번 데모데이에 오셔서 생생한 현장을 경험하시길 바랍니다!

그냥 사용자를 만나자

빨리 사용자를 만나자

나는 포항의 IT 협업 동아리 파드의 3기 서비스 기획 파트로 들어왔다.

3기를 수료하며 문제정의, 서비스 기획 산출물, 기본적인 서비스 개발 프로세스 등 서비스 기획에 대해 배우고 18시간의 해커톤, 3주간의 해커톤을 통해 서비스가 구현되는 과정을 경험했다.

이 과정을 마친 시점에서 나에게 지속적으로 든 생각이 있었는데

그것은 바로 '빨리 사용자를 만나는 법을 알아야겠다'는 것이었다.

왜 사용자를 빨리 만나야 할까?

우리가 서비스를 기획하는 이유는 '구현하기 위함'이 아니라 '구현한 서비스로 사람들에게 영향을 미치기 위함'이다.

그러기위해서는 사용자들에 대해 파악해야 하는데,(사용자가 모르는 사용자의 니즈까지도!)

문제는 우리가 아무리 머리 맞대어 사용자들의 반응을 예상하여도 사용자들은 우리 예상을 훨씬 벗어날 때가 많다는 것이다.

한번은 수업 프로젝트로 '업사이클링 베이킹 제품을 이용해 시제품을 개발하고, 이 시제품을 소개하는 팝업 스토어를 여는 프로젝트' 를 진행한 적 있다.

이 기업의 제품은 밀가루를 대체하여 쓸 수 있는 업사이클링 제품이었기에 우리는 이 제품을 이용한 '쿠키, 와플, 머핀' 레시피 자체 개발하고 지속적으로 개선을 했다( 이때 한학기동안 평생 구울 빵을 다 구운 것 같다.)

어느정도 레시피가 잡히고 더 나은 개선을 하기 위해 레시피 AB 테스트를 진행했다.

'사람들은 ~ 한 이유 때문에 분명 이 레시피를 더 맛있어 할 것이다' 라는 나름의 가설이 무색하게 사람들의 반응은 한참 예상밖이었다. 각자 맛있어 하는 레시피가 있었고 그 레시피가 더 맛있는 각자의 이유도 있었다. 그리고 그러한 반응들은 우리가 생각한 것보다 훨씬 다양했다. 그 후 몇차례 진행된 AB 테스트 역시 마찬가지였다.

팝업 스토어를 열고 나서도 이런 일이 많았다.

우리는 팝업 스토어의 인테리어가 아쉽다고 생각했지만, 사람들에게 팝업 스토어 인테리어에 크게 만족했다는 피드백이 다수 들어오는 일이라던가,

A 제품이 많이 팔릴 것 같아 많이 구워놨는데 사람들은 생각보다 B 제품을 많이 원했다던가,

함께 팔면 잘 팔릴 것이라 예상 했던 음료 메뉴는 한 잔도 안 팔린다거나 하는 일들이었다.

이때 우리가 아무리 머리 맞대어 예상해도 사용자들의 반응은 훨씬 예상 밖일 수 있다는 사실을 배웠다.

가설검증

이 사실은 IT 서비스에도 적용된다고 생각한다.

우리가 좋은 서비스를 위해 치열하게 고민해도 사용자를 만나는 부분 없이 그 과정이 이뤄진다면 결국 적중하기 어렵다고 생각한다.

그래서 책상에 앉아 곰곰히 사용자들의 반응을 예상하고 있는 것보다, 초라하게라도 빨리, 그리고 많이 사용자와 직접 만나는 지점을 만드는 것이 좋은 서비스를 만드는데에 훨씬 효과적이라고 생각한다.

사용자들을 만나기 전까지는 결국 모두 가설일 뿐이다.

그래서 최근에는 사이드 프로젝트에서 서비스를 개발하며 빠르게 사용자를 만나고 반응을 관찰할 수 있는 방법들에 대해 알아보고 시도하고 있다.

다음에는 빠르게 사용자들을 만난 경험을 들고 돌아와야겠다!

18시간 안에 앱 만들기 가능?

이번 시간에는 치열했던 숏커톤을 회고 해보고자 한다.

숏커톤은 한학기 동안의 세미나를 통해 각자의 자리에서 배우고 성장한 기획, 개발, 디자인 파트가 모여 18시간 동안 서비스를 기획-구현- 발표하는 행사이다.

숏커톤의 주제와 숏커톤의 팀원들은 당일 날 현장에서 공개되기 때문에 상당히 흥미진진 했다.

이번 숏커톤의 주제는 '청춘'이었다.

우리 팀은 '청춘을 기록하고 꺼내보고 싶은 사람들이 시간이 없어 소중한 청춘을 기록하고 돌아보는 활동을 쉽게 할 수 없다'는 문제를 정의하고, 청춘의 기록을 그림일기 형태로 쉽게 기록하고, 쌓아둔 기록을 청춘 뽑기라는 가챠를 통해 랜덤으로 뽑아보여주는 서비스' 를 개발 했다.

서로를 돕는 팀원들 덕분에 아낌없이 의사소통 하며 숏커톤을 진행 할 수 있었고, 2등 수상이라는 결과를 얻을 수 있었다.

이번 회고를 통해 잘한점과 못한점에 대해 생각해보고자 한다.

잘한점

1. 재밌게 하는 것을 1순위로 두었던것(심리적 안정감)
   
   : 누군가는 열심히 해야하는 순간에 재미를 1순위로 두는 것이 맞냐고 물을 수도 있다. 하지만 협업이 갖는 힘은 팀의 편안한 분위기에서 시작한다고 생각한다. 누군가는 그저 친목도모라고 볼 수 있는 분위기가 협업에서 더 쉽게 의사소통을 하게하고, 자신이 가진 능력들을 꺼내게 하고, 문제가 생겼을 때 빠르게 공유하여 함께 답을 찾아가는 과정들을 가능하게 한다고 생각한다.
   이 사실을 아는 팀원들과 18시간동안 웃을 수 있을 때 함께 웃고, 서로 응원과 칭찬을 아끼지 않았던 것이 짧은 시간이지만 목표를 달성하게 하는 것에 도움을 주었다고 생각한다.
   최선을 다해 잘하려고 한다. 하지만 결과가 성공일지 실패일지는 완벽하게 예상할 수 없다고 생각한다. 우리가 할 수 있는 것은 결과로 가는 과정을 즐겁게 만들어 성장의 과정을 반복할 수 있게 하는 것 아닐까?

1. 자체적으로 테스크들의 데드라인을 정했던 것.
   
   : 숏커톤에서 주어지는 '결과물 제출 시간'만을 우리의 데드라인으로 인식했다면 서비스를 구현하기 어려웠을 것이라고 생각한다. 각 파트 누구나 '조금만 더 하면 될것같은데' 라는 마음이 들기 때문에 마지막 데드라인 전까지 자신이 해결할 문제를 잡고 있게 된다. 그러다가 마지막에 가서 안될 것 같다는 판단을 하게 되면 이미 늦게된다고 생각했다.

   우리의 테스크를 파악하고 각 테스크에 대해 데드라인을 설정하며 진행했기 때문에 정해진 시간동안 목표를 이룰 수 있었다고 생각한다.

1. 진행상황을 자주 체크한 것
   
   : 특히 개발파트에 잘 진행되는지, 예상치 못한 어려움이 없는지 자주 물었던 것 같다. 서로 진행 상황을 자주 공유했기때문에 새롭게 발견된 문제가 더 커지기 전에 잡고 갈 수 있었던 것같다. 우리의 목표는 구현이었기 때문에 어려움이 생기면 핵심기능을 제외하고 버릴 수 있는 것은 빠르게 버리고 가자고 함께 지속적으로 말했던 것이 주어진 시간 안에 앱을 구현하게 해주었다.
   
   

2. 의사결정이 길어질 때는 의사결정 기준에 대해 이야기 했던 것.
   
   : '문제를 정의-해결책 생각-서비스 기획' 이 세미나를 통해 지금까지 해오던 방식이었지만 사실 숏커톤에서는 청춘이라는 주제에 맞는 서비스를 먼저 정하게 되었다. 그래서 이 서비스가 설득력이 있냐 라는 문제로 소통이 길어지게 되었다. 하지만 숏커톤이라는 특성상 의사결정에 걸리는 시간을 오래 사용할 수 없었다. 그래서 구현 vs 설득: 지금 우리는 서비스가 구현 되는 것이 중요하다고 생각하는지, 아니면 시간이 부족하여 서비스가 구현이 되지 못하더라도 설득력 있는 서비스를 기획하는 것이 중요하다고 생각하는지에 대해 먼저 팀원들과 이야기 했다.

   팀원들 대다수가 '그래도 숏커톤의 목적은 짧은 시간동안 서비스를 구현하는 것'이라고 생각했고, 그렇다면 바로 개발 작업을 시작하고 이 서비스에 대해 설득할 수 있는 부분을 찾자는 의사결정을 하게 되었다.

   의사결정 과정이 길어져 진전이 없다고 느껴지면 동기가 떨어질 수 있다고 생각 한다. 의사결정이 길어진다면 먼저 의사결정 기준에 대해 먼저 나누고 그것을 토대로 의사결정을 하는 것이 좋은 방법이라는 것을 알 수 있었다.
   
   

   못한 점

   1. 설득을 만드는 능력
      : 이번 숏커톤을 진행하며 설득을 만들어 내는 능력을 더 갈고 닦아야겠다는 생각을 했다. 기획자의 중요한 능력 중 하나는 '설득'이라는 것을 세미나를 통해 지속적으로 들어왔고 연습해왔지만 막상 짧은 시간안에 이 서비스가 왜 만들어졌고 누구의 문제를 어떻게 해결하는지를 전달하는 설득력 있는 내용을 구성하려고 하니 생각보다 잘 되지 않았다. 기획을 연습할 때는 설득할 내용을 구성할 적당한 시간이 주어졌지만 기획자가 된다면 분명 이렇게 짧은 시간안에 설득을 만들어야 하는 경우가 있을 것이라 생각한다. 설득을 만들어 내는 연습을 더 많이 해나가야겠다.

   2. 문제정의로 시작하지 않은 것
      : 사실 이게 가장 큰 문제였다고 생각한다. 앞서 말한 설득을 만드는 것이 어려웠던 것이 설득을 만들어 내는 연습이 부족한 것도 있겠지만 이 부분도 크게 작용했다고 생각한다. 문제정의가 왜 중요한지에 대해 배울 때 '문제정의가 제대로 되지 않으면 뒷단에 가서 고생한다'는 말을 들은 적 있다. 숏커톤을 통해 이 말을 몸으로 느끼게 되었다. 문제를 정의하고 그 문제를 해결하기 위해 서비스를 구현 한 것이 아니라, 서비스를 구현하고 그 서비스가 어떤 문제를 해결해 줄 수 있는지 찾다보니 서비스를 설득력있게 전달하기 어려웠다.

      
      또한 숏커톤의 경우 18시간이라는 짧은 시간이 주어지기 때문에 서비스에 대해 조금 납득 되지 않은 팀원도 '구현'이라는 목표를 잡고 진행할 수 있었지만, 프로젝트의 기간이 길어지고 프로젝트를 위해 많은 시간과 에너지를 쏟게 된다면 제대로 되지 않은 문제정의는 서비스를 개발하는 팀원들의 동기에 큰 영향을 줄 것이다. 이 서비스가 꼭 있어야 하는지 잘 모르는데 계속 만들어야 하는 것이기 때문이다. 설득하는 능력을 키우는 것과 함께 납득할 수 있는 진짜 문제를 빠르게 발견하는 능력을 계속 연습해야 한다는 것을 알 수 있었다.
      

      직접 경험하면 그냥 공부할 때는 예상하지 못했던 점들이 튀어나온다. 그렇기 때문에 직접 해보는 것이 중요하다고 생각한다. 이번 숏커톤 경험은 또 하나의 실습이었고 생각하지 못했던 배움이 있었다. 앞으로도 직접 부딪치며 배우는 경험을 많이 만들어 가야겠다.

첫 개발자 설명을 회고하며

5월 11일 기획 세미나는 개발자들과 함께 했다. 개발자들에게 정의한 문제와 기획한 서비스를 발표하고 질의 응답 하는 시간을 가졌다.

진짜 문제를 찾고, 그 문제를 해결하는 서비스를 기획하고, 설득을 위한 원페이저를 작성하여, 기획문서와 함께 그것을 전달하는 일이 이제 낯설지는 않게되었지만, 개발자들에게 전달하는 것은 또 새로운 일이었다.

개발자로는 서버 부파트장 민지님, iOS 파도 하람님, 서버 파도 채린님이 함께 해주셨다.

세션은 1. 전 기획 파트가 기획해 온 서비스를 원페이저를 바탕으로 발표하고 2. 순서대로 개발자 분들에게 질문을 받고 3. 다시 자기 차례가 돌아오기전 받은 질문에 대한 답과 설명 자료를 준비하는 방식으로 이뤄졌다.

나는 첫 순서로 발표하여 기획 파트원들의 발표가 끝난 후 첫 순서로 질의를 받았다.

개발자로부터 첫 질의를 받았을 때 내 머릿속은 다음과 같았다.

개발자분들이 제시해주는 의문을 들으며, 개발자의 입장에서 생각한다는 것이 어떤 것인지 투박하지만 처음으로 알게 되었다. 새로운 느낌이었다. 기본적인 IT 요소에 대해 이해하고 있다고 해서 개발자의 방식으로 생각할 수 있는 것이 아니었다.

한 기능을 구현하기 위해서 생각보다 더 많은 조각으로 쪼개서 생각해야한다는 것을 알게 되었다.

개발자분들이 설명을 잘해주신다고 느꼈다. 그저 피드백을 해야해서 하는 것이 아닌 어떤 점이 왜 어려운지 스스로 제대로 이해하고 제시해준다고 느껴서 더 경청해서 듣게 되었다.

질의가 끝난 후에는 다시 내 차례가 돌아오기전까지 개발자들의 의문을 해결하고 설득할 자료를 준비 해야했다.

'개발자들이 어렵다고 하는 가장 큰 문제는 뭐지?'

'이 문제가 해결될 수 있다는 가능성을 어떻게 제시해야 하지?'

'몇 분안에 기술적인 해결책을 이해하고 제시하기는 무리가 있을 것 같다.'

'기능을 구현한 사례를 제시해야하나'

다양한 생각이 들었던 것 같다. 감이 잡히지 않아 제대로 답변을 하기 어려웠다.

개발자와 소통한다는 것은 이런 느낌이구나 하는 것을 처음으로 느낄 수 있었다. 좋은 시행착오였다고 생각한다.

이번 세션을 통해 알게 된 점은 크게 다음과 같다.

1. 적절한 양의 기능 수와 데이터

   : 기능을 최소화 했다고 생각했지만 '3주안에 구현하기에 기능과 데이터가 너무 많다'는 피드백을 듣고 다시 한번 적절한 양의 기능 수와 데이터에 대해 생각하게 되었다. 또 꼼꼼한 기획문서와 과한 기획문서는 다르다는 생각도 하게 되었다.

1. 개발자와 소통이 어려웠던 지점

   : 보통 요청하는 사항에 대해 조율할때

   상대가 'A는 어려워요 ~(B) 때문이에요' 라고 하면 B에 대해 질문하거나 이야기 하며 타협점을 찾아간다.( ex B 중에서도 어떤 점이 가장 어려운가요? 그럼 B를 이렇게 해보면 어떨까요?)

   개발자와 소통이 어려웠던 이유는 A가 B 때문에 어렵다는 것은 알겠으나 B가 기술적인 내용일 때 B를 어떻게 풀어나가야 할지 모르겠다는 것이었다. 이 부분에 대해서 개발자와의 소통을 어떻게 해나갈지 알아봐야겠다는 생각을 했다. 개발 경험을 가져봐야겠다는 생각도 했다.

1. 기능의 우선 순위를 확실하게 정하는 것이 중요하다.

   :개발자들의 질의를 들으며 기능의 우선 순위를 확실하게 정하는 것이 중요하다는 사실을 체감하게 되었다. 한정된 기간에서는 기획한 기능을 모두 구현하기 어려운 상황이 쉽게 발생할 수 있겠다는 생각을 했다. 기능의 우선순위가 명확하게 정해져야 개발자들의 입장에서도 개발의 방향성을 잡을 수 있겠다는 생각을 했다. 하는 일이 힘든데 중요한건지 안 중요한건지 알 수 없으면 동기가 많이 떨어질 것이라 생각한다.

그렇게 첫 개발자 설명을 마쳤다.

항상 처음은 초라한 것 같다. 하지만 돌아볼때마다 느끼는 것은 초라함을 느꼈던 순간들이 알고보면 가장 많이 배우고 있던 시기였다는 것이다. 또 새롭게 배워나갈 부분을 찾았으니 부지런히 배워 가야겠다!

개발자 친구들과 많이 소통해야겠다. 책한권이 스쳐 지나간다.