16시간 안에 앱 개발하기
2020년 하반기동안 SOPT 기획파트로 활동을 했다. 실제로 기획자로서 협업을 해본 결과 느낀 것은 "개발 지식의 부족"이었다. 기획을해도 구현이 가능한지, 얼마나 걸리는 지 등을 파악하기가 어려웠다. 또한 아무리 좋은 기획을 해도 구현이 불가능하다면 소용이 없었다. 더 원활하게 협업할 수 있는 기획자가 되기 위해서 다음 SOPT는 안드로이드 OB로 지원을 했다.
안드로이드 파트의 세미나를 듣던 도중 솝커톤(SOPKATHON)이 열렸다.
SOPKATHON이란?
SOPT 엔 기획,디자인,안드,IOS,웹,서버 파트가 모여 무박 이틀동안 하나의 서비스를 만들고 발표하는 '솝커톤'이란 행사가 있다. 세미나의 절반이 끝난 후에 진행되는거라 그동안 세미나에서 배운 것을 직접 응용하고, 다른 파트와 첫 협업을 할 수 있는, 아주 좋은 기회다.
클라이어튼 개발자는 처음이라
28기 솝커톤에 참여를 할지 말지 많은 고민을 했다.
난 지금까지 기획자였다. 개발자는 처음이었다. 과제 현황을 보면 내가 제출 수가 적은 편에 속했고, 안드로이드 파트 중에선 내가 제일 못한다는 마음으로 임했다.
깃허브도 익숙치가 않아서 꼬이면 어쩌지? 구현을 못하면 어쩌지? 이로인해서 안좋은 이미지가 심어져 팀빌딩 때 악영향을 끼치면 어쩌지?
등등 정말 많은 고민과 걱정을 했었다.
하지맨 솝커톤은 개발자로서 협업을 할 수 있는 기회이자 내 실력을 확인할 기회였다. 이런 저런 걱정이 앞섰지만 가서 그냥 경험하고 오자는 마음으로 신청했다.
아이데이션
주제는 '기억'이었다.
아이데이션을 할 때 개발 가능 여부를 먼저 판단하다보니 아이디어가 생각이 잘 안났다. 개발 여부에 한계를 많이 보았다.
일기 어플을 할까?
☞ 그럼 사용자가 입력한 값을 서버에 넘겨주어서 출력하는걸 해야할텐데 할수있나?
기억을 기록하는 어플을 할까?
☞사진 출력과 캘린더를 사용할텐데....캘린더 어려운데 할수있나?
이런식이었다. 기획자로서 갖고있는 개발 지식은 도움이 되었다. 하지만 개발 공부를 본격적으로 시작한 지금, 어플 제작 초기 단계부터는 굉장히 방해가 되었다. 구현에 대한 걱정이 앞서서 더 그랬다.
그리고 괜히 이런 걱정을 내보였다가 기획단이 아이디어를 내는데 제한을 둘까봐 걱정됐다.
그래서 그냥 개발 가능 여부를 생각하지 않고 생각나는대로 던져보기로했다. 구현 방식은 우리 클라가 쉽게 바꾸먼 되는거니까.
"개발 가능유무 신경쓰지말고 일단 그냥 말해줘. 그럼 쉽게 구현 가능한 형태를 우리가 말해줄게"
"사용자 이름을 입력받아서 룰렛을 돌리는거 어때?"
"그거는 클라랑 서버한테 지금 상태에선 무리라서... 대신 색깔이나 번호로 표현하는건 어때?"
"그래 그러자"
단지 어렵다는 이유로 기획단이 말한 기능을 자르고 싶지 않았다. 어려우면 '안된다'가 아닌 '쉽게 제안'해주는 개발자가 되기 위해 노력했다.
세부 기능짜기
개발자로서 기획자와 협업하기
'우리 좀 재밌게 갔으면 좋겠어. 술자리에서 재밌는 기억에 관한 질문을 던지는거야.'
'예를들어 이성한테 뺨맞으면서 차인적 있다. 이런 질문들을 던지면서 재밌는 기억을 공유하는거지'
사실 기록 밖엔 생각이 안나서 한계를 맛봤었다. 그러다 갑자기 서버 파트원이 이 얘기를 꺼냈고 다들 귀가 솔깃해져서 '재미는 기억을 나누자'에 포커스를 맞추기로 했다.
오프라인으로 밥 먹으면서 나온 얘기였고, 오프라인엔 디자이너들이 없었다. 보통 아이디어를 내면 디자이너들이 그걸 어떻게 표현해줄기 얘기를 해줘서 좀 수월해지는데... 디자이너들이 없어서 약간 어려웠다.
그래서 온라인 전체 회의 때 얘기를 하기로했다.
온라인으로 전체회의하는 중
재밌는 질문을 던진다
질문에 답하며 나의 재밌는 기억을 공유한다
게임 형식
이렇게 큰 틀은 잡혔다.
'우리 실제로 술자리에 갔다고 상상해보자'
'질문을 할때 누구 한명 지목을 하겠지?'
'아 그럼 룰렛을 넣을까?'
'룰렛 돌리려면 전체인원수가 몇명인지 알아야돼!'
'아 그럼 처음에 인원수 입력해야겠다'
'질문에 빨리 답하라고 재촉하는 스타일이야 나는'
'맞아 루즈해지면 재미없잖아. 그럼 타이머 넣을까?'
'질문에 답을 못하면 술도 멕여야지'
'그럼 벌칙받는 기능도 넣을까?'
'벌칙을 랜덤으로 띄워주는거 어때?'
길지 않은 회의 끝에 세부적인 기능을 가진 어플을 만들 수 있었다
UI 작업
개발자로서 디자이너와 협업하기
기능이 다 완료 됐으니 피그마에서 UI를 짜보기로 했다.
보통은 디자인이 끝난 후에 개발이 들어가지만 아이디어가 확정된 시간이 저녁 10시. 발표까지 10시간이 남았고 디자인이 다 될때까지 기다릴 시간이 없었다.
그래서 디자이너와 함께 UI에 대해 논의를 했다. 화면 전환은 언제 어디서 일어나는지, 총 뷰는 몇 개인지, 특정 뷰에 버튼은 몇 개인지, 화면 크기는 몇인지 등등
먼저 구조와 기능만 구현한 후에 뷰가 완성되면 디자인을 입히기로 했다.
실제 그날에 디자이너와 같이 작업한 UI
기획과 마찬가지로, 구현 가능 여부 때문에 디자이너들이 제한을 받으면 안된다고 생각했다. 개발 가능 여부를 먼저 따지게 되면 '고객을 위한 앱'이 아닌 단순하게 '만들 수 있는 앱'이 되버린다.
또한 시장에서 개발자의 사정을 봐주는 회사는 많지 않다... 우린 그 환경에 익숙해져야한다
그래서 디자이너들에게 이렇게 말했다.
나 : '개발 가능여부 생각하느라 제한을 안 받으면 좋겠어. 일단 하고싶은거 다 말을 해! 우리 클라들이 최대한 해보면되는거야.'
다른 클라이언트: '불가능하면 최대란 비슷하게 우리가 할 수 있으면서도 최대한 비슷한 쉬운 형태를 말해줄게'
디자이너 : '그러면.... 이건 필수는 아니고 그냥 있으면 좋겠는데 혹시 이 이미지 나올 때 사라졌다가 나타나는 애니메이션 입힐 수 있어?'
나 : '이건 지금 내 실력으론 불가능하고... 좌우로 움직이는 애니메이션 정도는 가능해! 애니메이션 있으면 더 재밌겠다! 일단 필수 기능 다 구현한 다음에 시간 남으면 애니메이션 해볼게'
디자이너: '오 좌우로 움직이는 것도 좋은데? 알았어'
이런식으로 UI를 구성했다.
개발 시작
개발자로서 개발자와 협업하기
UI 구성이 끝나고 클라들끼리
보기 편하게 피그마로 뷰의 구조(프래그멘트,액티비티) 버튼개수, 각 뷰의 기능을 정리했고 역할을 분담했다.
개발 세팅
github 으로 merge를 할 때 comflict를 막기 위해, 기본적인건 미리 세팅한 다음에 각자 맡은 뷰를 개발하기로했다.
그니까 '진술게임'은
게임액티비티☞질문액티비티(룰렛 프래그멘트☞•질문프래그멘트☞•타이머프래크멘트☞벌칙 프래크멘트)로 구성되어있다.
이걸 먼저 다같이 만든후 각자 시작하기로 했다.
기본 세팅 끝난 후 git clone을 했는데 다행히 문제가 없었고 각자 맡은 뷰 개발을 시작할 수 있었다!
나는 질문을 못했을 경우 벌칙받기를 누르면 나오는 '벌칙뷰'를 맡았다. 반잔,한잔,두잔 중 하나를 랜덤으로 소주 이미지로 띄우는 뷰였다.
이때 랜덤값을 서버에서 받아와야했다.
0☞ 반잔 이미지 띄우기
1☞한 잔 이미지 띄우기
2☞두 잔 이미지 띄우기
우선 난 서버통신이 어려웠다. 그래서 서버통신 연결을 못했을 경우를 대비해서 먼저 클라 내부에서 처리했다.
서버 개발자와 협업하기
사실 클라상에사 처리를 다 했기 때문에 시연에 문제가 없었다. 안드로이드 공부하면서 젤 어려웠던게 서버통신이라 진짜 자신 없었다. 하지만 서버개발자들이 열심히 api를 만들었기 때문에 도전해보기로 했다.
세미나 때 배운 내용을 그대로 썼지만 잘 안됐다...�
postman에서도 에러가 떠서 서버 개발자들을 꽤나 호출했었다. postman이 해결이 됐지만 안드로이드에서 잘 안돼서 파트장을 2번이나 소환했고 새벽 4-5시쯤에 서버통신을 성공할 수 있었다.
에러 뜰때마다 옆에서 서버 개발자가 같이 슬퍼 했었다ㅋㅋㅋㅋㅋ 성공하니까 서버엔 문제가 없었다며 기뻐했다
개발자로서 이슈처리하기
기능에 의문이 생길 때가 있다. 그럴 땐 제안과 의견을 말해주되 기획자와 디자이너 그들의 영역은 침범하지 않았다.
'개발하면서 느낀건데.... 이 버튼을 누르면 00뷰로 이동하던데 다른 뷰로 이동하는게 낫지않아? 어떻게 생각해?'
'여기가 약간 유저가 아리송할거 같거든? 그리고 ~~~할 수 있게 설명 텍스트를 좀 넣어주면 좋을거 같은데 어떻게 생각해? 기디가 논의하고 알아서 해줘'
내 뷰가 젤 마지막에 나왔다. 시연 연상 제출 시간이 3시간 정도 밖에 안남아서 정말 엄청나게 불안 했었다. 그렇다고 재촉하면 안돼서 기다릴 수 밖에 없었다. 뷰가 나왔다는 카톡을 보자마자 바로 디자인을 입히기 시작했다.
온오프라인 환경
온/오프라인 혼합이기 때문에 게더를 사용했다. 평소엔 꺼놨다가 이슈가 생기면 게더에 접속했기 때문에 편했다.
merge하기
Merge할때 conflict가 나면안되기 때문에 담당한 뷰가 아니면 절대 건드리지 않았다. 각자 작업을 끝나고 풀리퀘를 할 때 다같이 보면서 천천히했다.
조심했는데도 불구하고 conflict가 났다. 상태바 색깔 코드라던가, 스플래시를 하느라 메니페스트에서도, 서버 통신 때문 등등...
각자의 코드를 천천히 비교하면서 수정을 했다. 파트장의 도움도 받아보니 성공!!! 그렇게 제한 시간 내에 무사히 여유롭게 시연 연상도 만들 수 있었다.
진술게임 : 당신의 진술한 기억을 나눠보는 술자리 게임
지금봐도 너무 잘만들었다
여기가 내가 맡은 뷰!
개발자로서 솝커톤에 참여하며
우리팀뿐만 아니라 모든 팀의 결과물이 다 훌륭했다. 솝커톤을 할 때마다 짧은 시간 내에 어떻게 이런 퀄리티를 내는지 매번 놀랍다.
회고
솝커톤이 끝난 후 우리는 온라인으로 모여 MIRO의 롤링페이퍼 툴로 회고를 했다.
진술게임팀은 최고의 팀워크를 보여주었다.
우리 클라들은 정말 침착하게 다같이 풀리퀘와 머지를 했어서 git이 꼬이지 않았다. 서로 굉장히 잘 했다고 칭찬하고, 에러가 나면 도우면서 했었다.
우리 디자이너들 또한 YB임에도 불구하고 너무 잘해주었다. 미리 우리 클라랑 상의해서 구조를 다 정하고 디자인을 시작해주어서 차질이 생기지 않았다. 너무 귀엽고 예쁜 뷰를 딱 맞춰서 만들어줘서 고마웠다. 폰트를 적용하지 못해서 좀 미안했다.
서버는 개발이 새벽 3시에 끝났다. 사실 그냥 자도 되는데 둘 다 돌아다니며 상황을 체크했다. 서버 통신이 잘 안될 때도 계속 옆에서 봐주어서 굉장히 고마웠다.
기획자들도 다 YB였다. 내가 작년에 기획 YB여서 그런지 기획단한테 눈길이 유독 갔다. 그래서 괜히 참고하라고 작년 PPT 주고, 언제 무엇을 해야하는지 이것 저것 알려주었다. 굉장히 열심히하고, 내가 가르쳐준 것뿐만 아니라 이것저것 알아외서 실행했다. 작년의 나보다 훨씬 잘한 거 같다.
무엇보다 온라인팀인데도 불구하고 몇 명이 오프라인 참여 의사를 밝혀주어서 굉장히 고마웠다.
진술 게임팀을 만나 굉장히 다행이었다.
솝커톤을 끝내며
클라는 확실하 부담감이 컸다. 기획자가 기획한 기능을, 디자이너가 만든 뷰를, 서버 개발자가 만든 API를 모두 클라가 구현 해야했다. 하지만 기능을 하나하나 구현 할 수록, 디자인을 입힐 수록, 서버 통신이 되갈수록 점점 더 욕심이 나기 시작했다.
'이런 기능 추가하면 좋을거같은데?' 생각도 났다. 능력이 안돼서 못했을뿐...
마지막에 스플래시가 갑자기 추가됐고 가능하냐는 질문을 받았다. 예쁘게 만들었을텐데 해주고 싶었다. 그래서 바로 승락하고 만들었다. 시간이 흐를 수록 계속 이런 생각이 들었다.
클라이언트 개발자는 기획자, 디자이너, 서버 개발자들이 만든걸 세상에 꺼내줄 의무가 있는 사람이다.
난 솝커톤을 통해 클라이언트 개발자로서 처음으로 '욕심'이 생기기 시작했다. 왜 공부를 해야하는지 동기 부여가 된 소중한 '기억'이었다. 개발자로서의 첫 시작이었다.