프로젝트 오픈일에 벌어지는 일
10년이 넘어도 바뀌지 않는 과정과 절차
( 인터뷰나 면접 등에서 ) 레퍼런스에 대한 질문을 받으면 자주 하는 대사가 있다.
6개 회사에서 12개 분야의 35개 프로젝트를 갑을병정에서 수행했다
초반에 여러 번 이직을 해서 그런지 6개의 회사가 많아 보였는데, 15년쯤 다니고 보니 심심찮게 이 정도 이직을 하신 분들을 만나게 된다. 하지만 프로젝트를 이렇게 많은 분야에서 수행하는 것은 일반적이지 않다.
그럼에도 내 이력의 조금의(?) 잘난 척으로 내세우는 건, 이 일을 시작한 이래 지금까지 끊임없이 프로젝트를 수행했다는 것이다. 그 과정에는 거의 쉼이 없었고, 2개의 프로젝트를 병렬로 수행하기도 했다. 1년에 평균 2개 이상의 프로젝트를 수행해야 이 정도 개수가 되는데, 현재도 약 20개월 이상 연속으로 프로젝트를 수행 중이다.
얼마저에 36번째 프로젝트를 오픈하면서 또 한 번 느낀
'프로젝트 오픈 즈음 벌어지는 일'들을 적어보고자 한다.
첫 번째, 막판에 몰리는 일들.
프로젝트 경험이 어느 정도 쌓이다 보면, 프로젝트의 상황을 대략 알 수 있다. 어느 정도 개발이 되었고, 어떤 상황이고, 어떤 것을 해야 하는지가 보이게 된다.
프로젝트 초반부터, 프로젝트 후반을 예상해서, 나중에 벌어질(생겨날) 일들을 앞당겨서 진행해본다.
이렇게 수행을 했다면, 분명 프로젝트 후반에는 여유로운 오픈이 가능해야 한다. 하지만 단 한 번도 그런 과정을 거쳐본 적은 없다. 왜 그럴까, 왜 꼭 막판이 되어야만 일이 되어질까
- 1번째 이유, 긴장감이다.
아무리 미리 준비한다고 아무리 애를 써도, 오픈 시점이 가까워지면, 새로운 일들이 생겨난다. 그전까지는 일을 미뤄오던 사람들도 'OPEN'이라는 이름이 주는 긴장감 때문에 막판에 긴급하게 일을 가져온다.
- 2번째 이유, 퀄리티에 대한 욕심
서비스 기획 / 특히 UX 쪽은 정답이 정해져 있지 않다. 그래서 막판까지 고민하게 되고 새로운 답을 찾으려고 애쓰게 된다. 분명 다 된 디자인 다된 화면인데, 테스트를 하다 보면 조금이라도 퀄리티를 높이려고 애쓴다. 그러다 보면 추가적인 수정/요건이 발생하게 된다. 원칙상으로는 오픈 이후에 적용하면 되는 backlog로 넘겨야 하지만 서비스 기획자 / Uxer의 욕심을 막기 어렵다 ( 이것을 사전에 정의한 규정에 따라 컨트롤하거나 애자일이라는 이름하에 끊임없이 반영하는 2가지 케이스가 주로 있기는 하다. )
- 3번째 이유, 의사결정권자의 등판
의사결정권자는 보통 프로젝트 시안 과정 정도 외에는 등판하지 않는다. 특히 프로세스 상의 많은 화면들을 기획 단위에서 보는 것은 불가능하다 ( 사실 봤다고 해도 마음을 바꾸는 일도 자주 일어난다. )
프로젝트 후반에 의사결정권자가 등판해서 이런저런 수정 요건을 제시하는 순간 막판 리스크로 떠오른다. 그것이 어떤 롤도 아닌 의사결정권자이기에 누구도 막기 어렵다. '임원 리스크'라고도 불리는데 기업의 의사결정 포인트가 많을수록, 회사가 클수록 임원 리스크도 커진다 ( 아이러니 한건 이런 회사일수록 프로젝트가 크기에 리스크에 대응하는 대응력이 떨어지기 마련이기에 더 어려운 것이다. )
두 번째, 위기의 순간
한 번씩은 오픈전 위기의 순간이 온다.
이를테면 이런 순간이다.
BTS툴 내 오류가 넘쳐나는데 개발자는 배포할 때마다 새로운 오류를 내고,
후배들은 나만 쳐다보고 어떻게 해결해야 하냐고 묻는다
위에서는 왜 계속 지연되냐며, 이럴 거야 면 오픈을 보류하겠다고 한다.
( 어차피 자기들이 하는 것도 없으면서 오픈은 보고 퇴근하고 상부 임원에게 보고 하겠다고 한다. ).
외주로 쓰는 개발업체는 빨리 퇴근하고 싶어 안달이다. 요즘은 개발자들도 야근하는 문화가 아니라고 한다
한 곳 두 곳 폭탄이 터지듯이 사람이 죽어나가듯이 기능이 잘려 간다.
피 터지는 전쟁터에 과연 제대로 된 프로젝트 결과물을 지켜낼 수 있을까
여기서, BTS 툴은 Bug Tracking System을 말한다. IT사람들은 아는 얘기자만 방탄소년단의 BTS를 얘기했을 때 무슨 '저런 이름이 있어'라고 생각했다.
오픈하는 날은 왠지 누구도 내편이 없는 것 같다. PM의 위치에는 외롭게 싸워야 하고, 또 그 싸움을 위한 전략/전술을 미리 준비해야 한다. 그렇지 않으면 오픈이라는 성과는 쉽게 찾아오지 않는다.
세 번째, 마지막 날의 반전, 갈아 넣어야 하는 철야의 미션
통합 테스트 과정에서 신기한 점은 1일 차 테스트에는 정말 이런 식이어도 되나 싶을 만큼 되는 기능이 없다.
테스트 2~3일 차가 지나면 수없이 버그들이 쌓여간다.
그럼에도 신기한 건, 마지막 날이 가까워 오면 순식간에 버그들이 처리되어 치워 진다
미스터리하게도, 이전에 처리된 속도와 전혀 다른 속도로 업무가 처리되는 걸 느낄 수 있다.
'이럴 거면 진작하지' 생각이 나다가도, 그래 지금이라도 되는 게 어디냐 로 바뀌게 된다.
그리고 이 마지막 날은 대부분 한 번에 배포를 하지 못하고 2~3번 배포를 하다가 철야를 맞는 경우가 대다수다. 아침에 오픈을 하기로 해놓고 꼭 야밤에 오픈을 하게 된다. 또는 오픈을 하지 마자 오류가 나서 재배포를 반복하다가 밤을 맞기도 한다.
내가 했던 최악의 경험에는 오픈 이후 오픈전 24시간 오픈 후 24시간 내 안정화를 하지 못해서 결국 휴식을 거쳐 3일째 만에 오픈했던 경험이 있다. 48시간 동안 우리는 모두 깨어있었고, 더 이상 개발자가 손을 대지 못하겠다고 GG를 치고 서야 하루를 더 연장하고 나서 그다음 날에 다시 오픈을 할 수 있었다.
이상하게도 철야를 해야만. 밤을 새워야만 오픈이라는 결과물을 만날 수 있는 건가 생각한 적도 있다.
( 물론 SI에서는 의도적으로 밤 오픈을 선호한다, 고객들이 접속하지 않는 시간을 택하는 것 반 + 클라이언트에게 고생했음을 알리고, 같이 고생하면서 동질감을 만드는 것 반 )
네 번째, 숟가락을 얹는 사람들, 발을 빼는 사람들
프로젝트가 오픈할 시기가 다가오면, 대부분 실무단에서는 이 프로젝트의 흥망성쇠를 예감한다.
그리고는 좋은 결과가 예상된다면 숟가락을 얹는 사람들이 등장한다.
'나도 뭐 하나 했다'라고 어필하는 사람들이 돌아다닌다.
이렇게 숟가락을 얹는 사람들이 많아지면, 실제 프로젝트에 참여한 사람들의 멘털이 흔들린다.
반대로, 프로젝트 결과가 안 좋다면
'거봐, 내가 안된다고 했잖아'라는 사람들이 나타난다. 담갔던 발을 빼고 본인의 책임이 아니라고 말한다.
이렇게 발을 빼면 PM이 대체로 짐을 지게 된다.
개인적이지만, PM은 더 많은 보수를 받아야 한다는 주의인데, 그만큼 각종 리스크와 책임을 떠안고 프로젝트를 해야 하기 때문이다.
어쨌든 오픈,
요즘엔 앱 서비스가 많다 보니 앱스토어에 앱을 올리는 심사 신청 버튼 또는, 서버 반영 버튼이 live의 마지막 절차였는데, 신입사원들이 있을 땐 꼭 이 마지막 과정을 경험시켰다. 우리가 고생한 결과물의 마지막을 경험해보라는 의미였다.
정말 많은 고통과 어려움이 있지만, 어쨌든 오픈을 하고 나면 모두 잊힌다.
오픈을 하고 나면 이제 서비스를(또는 UX를) 평가받아야 하니 냉정한 시장의 평가로 내몰려지지만,
그전까지 적어도 오픈 이후 하루 정도의 그 짧은 시간 동안은 걱정도 미움도 원망도 없는 긍정의 마음뿐이다.
그 어떤 일에서도 느낄 수 없는 보람, 희열, 감동, 성취감, 즐거움, 안도감 등 모든 것을 느낄 수 있다.
어쩌면 이 바닥에서 계속 이 일을 하는 이유도 그 순간을 위한 것이라고 생각이 든다
최근 론칭한 서비스 오픈은?
역시나 미리 준비를 많이 했지만, 막판에 일이 몰려왔고. 사방에서의 견제하는 사람들로 인해 위기의 순간도 있었으며, 마지막엔 프로젝트 팀원들을 갈아 넣어 완성했지만, 역시나 박수를 받고 싶어 발을 걸치려는 사람들도 늘어났다. 하지만, 이번 오픈 또한 즐거웠으며, 새로운 구성원들과 의미 있는 결과를 도출함에 행복을 느낄 수 있었다.
10년이 넘게 이 일을 하면서도 이번 프로젝트에도 이런 일들이 따라오는 거구나 생각이 들지만
경험이 쌓이면서 프로젝트에서 막판의 항상 일어나는 일들, 특히 프로젝트가 끝나는 전후의 경험들을 통해
'후회 없이' 프로젝트를 하는 방법을 조금씩 알아 나가게 되는 것이 달라지는 점인 것 같다.
할 수 있는 모든 것을 쏟았기에 후회는 없다.
그렇게 후회 없이 최선을 다했다면 그다음은
Cheers~
