프로그라피 6기 활동을 마치며

프로그라피 6기 

친구의 권유로 '세상에 필요한 IT 서비스를 만드는 단체'인 프로그라피에 지원하여 지난 상반기동안 활동을 하였고, 지난 주말 이번 기수의 활동을 일단락지었다. 프로그라피는 주로 대학생, 2-30대 직장인들로 구성되어 있다. 정말 훌륭한 분들도 많이 계시고, 배울 점이 많은 어린 친구들도 많았다. 본인이 개발 지식을 흡수하는 속도만 빠르다면 정말 많은 것들을 배울 수 있는 곳이라고 생각한다. 

 

아쉬운 점 : 빠듯한 개발 일정 

기획, 디자인, 개발을 모두 하기에 개발 일정은 매우 빠듯하다. 기획을 한 달동안 하면 꽤나 커다란 프로젝트가 나오는데, 문제는 3개월 안에 클로즈 베타, 오픈 베타로 내놓을 수 있는 어플리케이션을 만들어 내야 한다는 점이다. 늘 혼자서만 토이 프로젝트를 진행해왔고, 주로 2주 안에 끝나는 아주 간단한 것들이어서 3개월이란 시간이 길다고 생각했었다. 하지만 혼자서 진행하는 것이 아니고 백앤드, 디자이너, 그리고 다른 프론트 개발자와 협력을 해야 한다는 점을 간과했다. 협력하며 진행하는 3개월이란 프로젝트 기간은 혼자서 진행했을 경우 5주 정도와 맞먹는 것 같다. 

 

이렇듯 일정이 매우 빠듯했고, 그래서 그런지 내가 원하던 테스트코드 가득하고 꼼꼼한 어플리케이션은 커녕 미완성된 API와 허술한 비즈니스로직이 가득한 앱을 출시해야만 했다. 더 나아가서 디자인을 세 번이나 크게 갈아엎었는데도, 여전히 부족한 부분이 많다. (개인적으로 성격이 매우 까다롭기는 하지만)

 

내가 얻은 교훈 

물론 빠듯한 개발 일정으로 인해서 만족할만한 앱을 만들지는 못했지만 그 과정에서 배운 점들이 매우 많다. 안드로이드 프레임웍을 다루는 부분에서는 말 할 것도 없고, 협력을 하는 스킬도 많이 늘었다. 여러 교훈 중에서 가장 크다고 생각하는 것 세 가지를 꼽자면 다음과 같다. 

 

1. 기획 - 디자인 - 개발 이라는 순서가 괜히 있는 것이 아니다.

모두가 알고 있는 서비스 출시 단계이지만 쉽게 간과할 수 있는 부분이다.  기획이라는 계단을 올라가야 디자인을 하는게 맞고, 디자인과 프로토타이핑이 끝나야 개발을 하는 것이 순서이다. 여기서 기획이 무너지면 디자인도 무너지고, 개발 단계는 말 할 것도 없이 혼돈의 상태가 된다. 기획을 대충하면 서비스에 필요한 데이터 모델들이 무엇인지에 대해 불확실해진다. 예를 들어 만약 A라는 정보를 사용자에게 보여주고 싶으면 A와 관련된 B, C, D 라는 정보들 (즉, 테이블들)에 대한 정의도 명확히 해야 할 필요성이 생긴다. 하지만 A라는 정보를 보여주자! 까지만 대충 기획을 하고 나중에 가서 "B, C, D"도 보여주면 좋지 않을까? 라고 했을 때 총체적 난국이 시작된다. 서버는 테이블을 다시 만들고, 이에 해당하는 API를 짜야하며 이 API에 대한 테스트도 작성해야 하고, 에러 처리를 해야한다. 클라이언트는 서버와 마찬가지로 네트워크 코드를 짜고, 이에 대한 응답 성공-실패 코드를 짜야하며, 이 API에 클라이언트가 접근할 때 올바른 인풋값을 주는지에 대해 확인하는 비즈니스 로직도 작성해야 한다. 캐싱까지 해야하는 정보이면 내부 저장소에 접근하는 코드도 덤으로 작성해야 한다. 뿐만 아니라 해당 서비스에 대한 화면도 디자인 해야 하는데 문제는 완벽한 디자인은 여러번의 수정을 거쳐야 나오므로 최소 디자인을 4-5번 정도 더 해야하는 상황에 직면하게 되는 것이다. 개발을 그나마 좋아하는 편인지라 별 탈 없이 수정되는 기획안들을 소화할 수 있었지만, 조금이라도 개발을 싫어했으면 정말이지 고통스럽기 짝이없는 상황이다. 

 

2. 무조건 쪼개서 작업해야 한다. 

혼자서만 작업을 많이 하던 사람이면 커밋을 할 때 기능별로 쪼개서 하는 것이 생각보다 번거롭게 느껴진다. feature branch 도 만들지 않고 그냥 무더기로 작업하고 무더기로 커밋하는게 아무런 문제가 되지 않기 때문이다. 하지만 이런 습관은 비록 혼자 작업한다 하더라도 앱의 규모가 커지면 본인에게 후폭풍으로 돌아온다. 개발 일정이 매우 빠듯했기 때문에 하나의 기능에 온전히 몰입할 수 없었다. 그래서 하루에 A화면 디자인 수정, B화면 비즈니스 로직 작성, C 화면 오류 수정, 등 여러 화면들의 작업을 한꺼번에 하기 시작했다. 이렇게 되니 다음 날 내가 뭘 했는지, 오늘은 무슨 작업을 더 해야 하는지 헷갈렸다. 중구난방으로 작업을 한 결과 특별한 기능 하나 없는 껍데기뿐인 어플리케이션이 나왔다. 심지어 로그인 로그아웃 기능마저 부실했으니 말 다했다. 앞으로 작업할때는 반드시 A화면 디자인 - 비즈니스로직 작성 - 에러처리 와 같이 하나의 브랜치에서 하나의 온전한 기능을 구현할 수 있도록 해야겠다. 

 

3. 생각보다 사소한 것들까지 보고하는게 맞다. 절대 혼자서만 생각하지 말자. 

사이드 프로젝트로 프로그라피 활동을 하는 사람들이 많다보니 회사 일처럼 일일이 보고하지 않고 작업을 하는 경우가 많다. 특히 직장을 다녀보지 않은 나와 같은 대학생들이 보고하는 습관이 부족한 것 같다. 회사에서 매일 얼굴을 보는 경우가 아니라면 서로가 무엇을 했는지 알 방법이 없다. 말을 하지 않고 있다가 나중에 가서 얘기하면 그건 팀원들에게 득보다는 실이 된다. 공유된 것들을 가다듬어서 결과물을 내는 것이지, 혼자서만 생각하고 있던 아이디어를 갑자기 툭 던져서 무언가 이루어지기를 바라면 안된다. 누가 보든 안보든, 무조건 클라우드에 업로드 하고, 업로드한 사실을 알리자. 만약 어떤 API를 작성했으면 엔드포인트와, API의 목적과, 정확한 요청 형식, 그리고 응답 형식을 공유하자. 클라이언트단은 화면 디자인에 대해서 수시로 피드백을 받자. 만약 공유했으나 아무도 피드백을 하지 않으면 그 때는 공동의 책임이지만, 공유하지 않다가 나중에 일이 터지면 온전히 본인의 책임이다. 

 

 

코로나 사태로 인해서 프로그라피 활동을 하는 데 많은 어려움이 있었다. 하지만 운영진들이 체계적으로 이끌어 주기도 했을 뿐더러, 팀원들의 협조로 어렵게나마 활동을 마칠 수 있었다. 이번 기수에 제작한 "애견호텔 예약 서비스 : 마이펫밀리"는 아직 많이 부족한 단계이다. 우선은 그럴듯한 프로토타입을 만들고, 어드민 사이트를 만들어서 예약 시스템을 구축한 후에야 영업을 시작할 수 있고, 영업을 시작 한 후 부터 다시 서비스를 다듬어야 하기에 많은 노력이 투입되어야 성공할 수 있는 서비스이다. 코로나 장기화로 인해서 7기는 모집하지 않고 현재 기수의 사람들끼리 더 작업을 하는 식으로 진행될 터인데, 앞으로 위의 교훈들을 잊지 않고 더 나은 서비스를 만드리라 다짐한다. 

 

구글 플레이 링크