앱팀장의 스타트업 개발이야기

프로젝트는 크고 작은 문제들이 숨어 있다.

언제 드러날지는 아무도 알 수 없다.

그런데 개발관련 문제들은 

대부분 런칭 직전에 나타난다.

이걸 팀이 수습하지 못하면

불난 프로젝트가 되는 거다.

3번정도 불을 끈적이 경험이 있다.

생각하기 싫은 기억이지만

지금 이 순간에 화재현장에 있을 분들 위해

정리해본다.

현장답사

사고현장은 정신없다.

팀원들과 미팅을 해보면

자잘한 이야기들이 두서없이 오간다.

주로 방화범 찾는 것에 대한 이야기다.

일단 개발자는 없다.

대표는 얼마나 좋은 건지 설명한다.

팀원들은 불평 불만하기 바쁘다.

이와중에 팀원들의 역할을 파악할 수 있다.

그나마 프로젝트를 기획한 사람은

답답함을 토로한다.

"이 사람이다."

이사람과 이야기해서 풀어 나가야한다.

일단은 포기를 권한다.

그래야 팀에 변화가 생기기 때문이다.

팀을 그대로 두고 개발을 찯다시하는건

같은 실패를 반복할 가능성이 높다.

결과물 확인

눈으로 보면 잘못된 부분이 보인다.

만져보면 빠진 것들을 확인할 수 있다.

그러나 이건 결과이다.

개발은 정보가 유통과정이다.

처음 보낸 정보와 비교 해봐야한다.

그래야 잘 못 도착한 것도 찾을 수 있고

아예 보내지도 않은 것들도 찾을 수 있다.

찾은 걸 파악해보면 만들어져야 할 것과

만든 것을 차이가 나타난다.

이게 "해야할 일"이다.

이걸 엑셀에 정리해서 작업목록을 뽑아낸다.

전반적인 완성도도 검토해야한다.

처음 만들때처럼 기획서를 보고 

TODO리스트를 작성한다.

불끄기 위해 손대야 할 것들은 따로 정리해둔다.

소스확인

코드에는 로직만 있는게 아니다.

팀의 태도와 업무방식도 포함되어 있다.

개발자의 눈으로 코드를 보면 이게 보인다.

그래서 자기가 만든 건 잘 보여주지 않는다.

결과물의 문제가 있던 부분으로 가본다.

여러번 수정한 흔적과

임시로 수정한 부분이 많이 보이는 건

그 만큼 기획이 변경되었다는 거다.

전체적인 구성를 살펴보면

구조가 없는 경우도 있는데

이건 초보자가 만들었다는 의미가 된다.

구조가 일관되지 않은 경우라면

프로젝트가 여러명의 개발자를 거쳤다는 의미한다.

이런식으로 살펴보면

전체적인 문제인지 부분적인 문제를 가릴 수 있다.

이걸 가지고 팀에 알려줘야한다.

"내가 이럴 줄 알았다"라는 이야기가

나오도록 사실대로 알려줘야 한다.

현황공유

절체절명의 순간에도 이성은 있다.

그래서 지푸라기도 잡는거다.

현재 상황을 이야기하면 단체멘붕에 빠지지만

곧 "어떻게 해야할까요?"도 나오게 된다.

대표는 결정해야하는 사람이다.

선택할 수 있는 옵션을 알려주고

장단점을 설명해준다.

"싹 뜯어 고칠까? 이건 이런거야"

"급한데로 조금씩 고칠까? 이건 이런거야"

팀원들과는 협력을 해야한다.

각자의 업무에 맞는 준비할 것들을 알려준다.

이때 업무조정이 안되면

대표와 이야기 하도록 해야한다.

불 끌때 가장 중요한 건 속도다

개발속도에 영향을 주는 방해요소는

제거할 수 있도록 협의해야한다.

해결과정

바닥부터 만드는 방식으로 개발되지는 못한다.

일단 팀을 안정화 시켜야 한다.

이미 개발자에게 신뢰는 없다.

보이는 부분부터 만들어 줘야한다.

조금씩 수정하는 경우에는

화면부터 만들어서 연결시킨다.

코드개선할 시간은 따로 시간을 잡아야한다.

그리고 매주 미팅을 진행하고

미팅시 결과를 확인하고 다음주에 확인할 결과를 알려주며 진행해야한다.

처음부터 만드는 경우에는 

지금까지 만들어진 걸 최대한 살려서

껍데기부터 만들어서 연결시켜야한다.

그 다음에 구조를 잡하서 화면 뒷쪽 코드들을 작성한다.

완성되는 결과물은 라이브로 확인 가능하도록 수시로 전달한다.

어느쪽이든 완성도는 떨어진다.

일정과 고민할 시간이 없기 때문이다.

그래서 프로젝트의 미래따위는 접어두고 작업해야한다.

해야할게 있다면 "여러분들 화이팅" 정도?

후기

불끄고 나면 잔해가 남는다.

잔해를 치우는 건 온전히 팀의 몫이다.

나는 떠나야 하는 거다.

팀이 정이되는 경우도 있었고

앱이 런칭되는 경우도 있었다.

서비스가 별로 개선되지는 못했는데

그래도 1-2년은 그럭저럭 돌아갔다.

불난 프로젝트에 가기 싫은 이유는 

끝났을때 아무도 고마워 하지 않기 때문이다.

그들도 잊고 싶은 기억인거다.

나는 그걸 이해하는데 생각보다 오래 걸렸다.

마무리

그런데 불난 팀에 다른 개발자가 있었다면

원래의 계획대로 진행되었을까?

결국 팀에 모인 모든 사람들이 방화범이다.

마음 먹고 "불내지 말자"라고 생각하면 안된다.

시간쓰는 방법과 사람과 관계하는 방법을 바꿔야 한다.

그래야 작은 불이 보인다.