SOPT 37기 appjam 데모데이 후기

 

왜갔나?

https://dev-dx2d2y-log.tistory.com/67

쓰리트랙

https://dev-dx2d2y-log.tistory.com/155

쓰리트랙 2

내가 블로그에 개많이 올리긴했는데 그래도 꾸준히 이 내용을 말하게되긴한다. 요즘 내 블로그 및 개발공부는 위의 쓰리트랙을 하나의 큰 방향성으로 삼는다. 그리고 이는 여러 개발유튜브, 파트스터디의 알럼나이 세미나, 팀네이버 컨퍼런스 DAN25 등, 여러 의견을 들어보며 어느정도의 검증된 방향성이라고 생각한다.

 

https://dev-dx2d2y-log.tistory.com/114

팀네이버 컨퍼런스 'DAN25' 후기

https://dev-dx2d2y-log.tistory.com/153

쓰리트랙은 잘 존재하는가?

 

쓰리트랙은 개발공부를 CS - 프로젝트 - 알고리즘이라는 3개의 방향성으로 나눠서 공부하는 방식이다. 알고리즘은 우선 논외로 치고 요즘은 프로젝트와 CS에 주로 집중하고 있는데, 내 개발공부와 이 블로그 글의 가장 큰 문제점은 프로젝트 아이디어가 안나온다였다.

 

아이디어를 생각해내도 결국에는 실사용자 및 수요를 고려하지 않을 수 없는데, 그러다보니 재밌어보이는 토이프로젝트는 못하고 그 아이디어조차 몇 학번 선배들도 팀프로젝트하면서 겨우 생각해내는데 내가 생각해낼리 만무. 그래서 요즘은 프로젝트 파트 쪽은 제대로 무언갈 해보지 못하고 있었다. 블로그에 CS만 우루루 올라온 것도 그 이유.

 

또 내 인스타그램 계정은 SOPT 계정을 팔로우 중이다. 언젠가 한 번 들어가보고 싶다는 생각을 가지기도했고, 주변에서 들어보니 들어가기 빡세고 어려운 그런 개발자 창업 연합동아리라고 들어서 관심을 가지고 있다가, 솝트 37시 appjam 데모데이를 개최한다는 것을 보고 못해도 프로젝트 아이디어에 대한 레퍼런스는 잡아볼 수 있지 않을까 싶어서 참가하게 되었다.

 

그래서 내가 이 SOPT 데모데이가 참가한 이유는 부스를 통해서 결과물을 체험해보거나 하는게 아니라, 어떻게 프로젝트를 기획했고, 문제사항을 이겨냈고, 어떤 아이디어를 가지고있었냐라는 것에 대해서 알아보기 위해 가게되었다. 장소는 마곡.

 

느낀점

음.. 우선은 주변에서 들어가기 빡세다고한 이유를 알 수 있을정도로 발표된 프로덕트들의 완성도가 매우 높았다. 우선은 릴리즈를 염두에 두고 개발된 것은 물론, 수익화 모델도 고려했으며, 이미 어떤 단체 등과의 컨택을 통해서 실사용자를 확보한 경우도 있었다. 인원도 PM팀, 디자인팀, 기획팀, 개발팀으로 세분화되어있는 경우도 많았고. 후드티도 단체로 맞췄음ㄷㄷ

 

내가 생각한 것은 "참고할만한 프로젝트 아이디어라도 좀 찾아보자"라는 것이었는데, 솝트 데모데이 발표에는 심사위원도 참가하였다. 그래서 결국에는 "우리 프로젝트는 왜 등장했고, 어떤 구조로 수익을 얻을 수 있으며, 실사용자는 어떤 점 때문에 우리 프로젝트를 사용하게될 것이다."라는 것을 심사위원에게 어필하는 구조였다. 그래서 오히려 처음에 생각했던 목적에서 몇 가지 인사이트를 더 얻을 수 있었다.

 

문제점 찾기

데모데이에 참가하고보니 예전에 프로젝트 트랙을 할 때나, 개인 프로젝트 기획을 할 때나 문제상황이 명확하지 않았다라는 생각이 들었다. 어떻게됐든 결국에는 우리 프로젝트를 사용해야한다고 설득하는 발표임에도 불구하고, 단순히 "저는 대충 ~~가 문제라고 생각했어용" 내지는 "제가 이거 개발하고 싶어서 ~~문제를 붙여봤어용" 정도였다. 물론 단순한 토이프로젝트에서는 문제가 될 것은 없지만..

 

솝트 데모데이에서는 팀별로 하나의 페르소나를 만들었다. 팀이 해결하는 문제를 겪고 있는 사람들을 생각해내거나 찾아내고, 그들의 입장에서 몇 가지 페인포인트를 도출해낸다. 그리고 각 페인포인트마다 하나의 기능을 만들어내는 것이다.

 

이게 이렇게 말하니까 되게 당연한 것 같은데, 생각해보니 내가 프로젝트 문제상황에 대해서 깊게 파고든 적이 있나 생각해보니 그런적은 많이 없었던 것 같다. 그냥 대충 "아 그냥 ~~가 문제겠네"하고 바로 OKR 쓰는식으로 진행했는데, 그러다보니 명확한 문제상황을 알지도 못하고, 어떤 기능을 개발해야할지도 알지 못하고, 그럼 결국 다시 "이 프로젝트는 왜 존재하는거야?"라는 질문으로 돌아오게되었다. 그리고 여기로 돌아왔으면, 보통 대답을 하지 못한다. 왜냐하면 처음에 시작하려던 이유를 잊어버리기 때문. OKR에는 문제상황이 아니라 단순한 목표치만 적혀져있으므로 결국에는 "왜 이 프로젝트를 시작한건데?"라는 의문을 해결하지 못하고 많은 프로젝트가 그렇게 폐기되었다.

 

그래서 나는 이 점은 찾은 것만으로도 데모데이 행사에 아주 잘 참여했다고 생각했다. 전에 프로젝트 주제를 찾기 힘들다는 고민을 다른 선배분께 털어놓은 적이 있는데, 그 선배 분이 "문제상황을 찾고, 그 상황의 페르소나를 찾으세요. 이 사람은 왜 이러한 불편함을 가지고 있을까? 이런걸 생각해보세요"라는 답변을 하셨다. (아닐수있습니다지금기억나는대로쓴겁니다)

솔직히 그 때는 무슨 얘기인지는 알 수 있는데 어떻게 해야할까를 몰랐다. 결국 페르소나와 타인의 페인포인트를 찾아내는 과정 역시 기존에 내가 겪었던 프로젝트 주제 찾기 문제와 비슷하다고 생각들었다. 그리고 솝트 데모데이 행사가 "어떻게"를 보여주었다.

 

이 날 본 팀들은 정말 고급진 기술을 개발하는 것이 아니며, GDG 프로젝트 트랙에서 다른팀이 사용한 기술과 크게 다르지 않은 기술을 사용한 팀도 있었다. 하지만 솝트팀들은 "문제"에 더 집중했다고 생각들었다. 그래서 결국 나에게 도움이 되는 프로젝트, 나중에 다른 연합동아리나 또는 포트폴리오용으로 사용할 프로젝트, 그리고 SOPT에서 이상적으로 바라보는 프로젝트는 그렇게 복잡한 기술이 아니어도 (물론 단순하기만한 기술도 좀 지양하고, 몇 개는 어려운 고급 기술을 사용한 프로젝트면 좋겠지) 이 "문제해결"에 집중해서 남의 문제를 효과적으로 인식하고 해결하는 것이라는 것을 알게되었다. 그리고 그 문제를 인식하는 과정에 대한 예시를 좀 보여주지 않았나 생각들었다.

 

이전에는 프로젝트 아이디어를 생각해내도 "이거 너무 간단한 아이디어 아니야? 이런거 너무 쉬운데?"라는 생각으로 몇 가지 아이디어를 반려시켰던 때도 있는 반면에, 앞으로는 뭐, 간단하더라도 문제상황만 명확하고 이를 내가 효과적으로 해결할 수 있다면 해볼만한 프로젝트가 아닐까 생각든다. 물론 프로젝트 찍어내는 기계처럼 영양가 없는 프로젝트만 우수수 찍어내는 것은 지양해야하긴하지

 

암튼 그래서 이 문제상황을 구체화하는 것에 대해서는 알았다. 문제상황을 찾는 것은 또 다른 얘기긴하다만.. 또다른 고찰글에서 다뤄보기로한다. 우선은 기존에 문제상황을 생각해내도 명확한 로드맵이 없어서 프로젝트 아이디어 폐기되는 일이 있었는데, 그것을 막을 수 있다는 것을 찾아냈다. 이걸 뭐 프로젝트 트랙에서 알았다면 좋았을텐데 쩝..

 

기능 개발하기

기능 개발 쪽 역시 앞서 기획단계에서 나왔던 페인포인트를 해결하는 방향으로 기능개발이 이루어졌다. 특이한 점은 거의 창업 직전 단계의 프로덕트를 개발하는 것이 데모데이의 목표라 실제로 이 프로젝트를 실사용자가 사용할지, 그리고 이 프로젝트의 수익화모델은 어떻게 되는지에 집중한 모습이 인상깊었다. 경쟁사는 누구인지, 경쟁사와 대비되는 프로젝트의 특징은 무엇인지, 만약 경쟁사가 같은 서비스를 제공한다고할 때 기존고객을 떠나지 않게할 방법은 무엇인지 등..

 

위에서도 말했지만 특별히 엄청난 고급기술은 없다. 백엔드 서버개발을 JSON상하차라하는 미친발언이 있듯이, 특별히 엄청난 고급기술을 도입하지 않는이상 개발난이도가 비슷비슷하기도하고. (하지만 나에게는 어렵지) 또 무턱대고 고급기술을 도입하면 개발난이도도 올라갈 뿐더러 오버엔지니어링이 되기도하고.

 

그래서 DAN25에서 모 개발자 분께서 다룰 수 있는 언어나 프레임워크 종류보다는 문제해결력이 중요하다라고 말한 이유가 바로 이 이유 아닐까 싶다. JSON상하차에서 벗어나려면 트래픽관리, 성능개선을 시켜야하는데 데모데이에 나온 서비스처럼 페인포인트와 수요층이 명확하고 실사용자도 어느정도 확보한 상황이라면 이게 훨씬 더 쉬우니까.

 

또 발표를 들어보면 수요층이나 해당사항이 정말로 문제가 되는지를 제시하기 위해서 여럿 통계자료를 사용했고, 스프린트를 사용해서 실제로 사용자의 반응을 통계 데이터로 조사한 경우도 있었다. 특히 관련된 설문조사나 논문도 참고한 적도 있고, 뭔가 아주 체계적으로 발표가 진행되었다는 느낌을 받을 수 있었다.

 

앞으로 계획

앞으로는.. 이전에 버린 프로젝트 계획들을 다시 되살려볼 생각이다. 쓸만한 문제상황이 명확하다면야 간단한 개인 프로젝트로는 문제없을듯하다. 그리고 몇 가지 아이디어도 더 생각해봐야지음..

 

앞으로 몇 가지 프로젝트를 진행하면서 이 문제상황과 페르소나를 명확히 규정하고, 객관적이며 논리적인 자료로 페인포인트를 도출해 그에 맞는 기능을 만드는 프로젝트를 진행하는 것을 목표로 삼아보려고한다. 물론 이것이 필요없는, 그냥 공부용이자 연습용 토이 프로젝트도 진행할 생각이다.

 

앞으로 CS공부는 하루에 게시글 한두과목 정도로하고, 나머지는 프로젝트에 한 번 사용해보면 좋을듯하다. 지금 자주 올라오는 컴네 + 컴구(운체) + 논회 중에서 두 개씩 돌아가며 공부하는걸로하고, 시간 남으면 프로젝트도 해보고, 어떨땐 백엔드 공부도 같이 돌아가면서 하는걸로