SI개발자를 갈구는 기획자는 갑인가?
여러분 안녕하세요. 꿈꾸는 개발자입니다
이번 포스팅에서는 SI개발자를 갈구는 기획자는 갑인지에 대해서 말씀드리려고 해요. 제가 예전 포스팅에 SI업체는 피해야 하나? 라는 포스팅을 만든적이 있는데 그때 제가 SI업체의 장점과 단점에 대해서 저의 경험을 바탕으로 말씀드린적이 있어요. 암튼 저는 SI개발자로 일을 할때도 있었는데 사실 그 전에 저의 직업은 기획자 였어요. 서비스를 구상하고 비즈니스 모델을 만들고 실제 화면단 기획을 하고 개발을 의뢰하는 역할을 맡았었어요. 그 과정에서 SI개발 업체와의 계약도 담당했구요. 그때는 아직 개발자가 아니여서 개발자의 고충을 잘 이해하지는 못했는데 이제는 좀 알겠더라구요. 왜냐하면 그때 제가 개발자들을 정말 많이 고생시켰거든요. 정말 미안한 생각이 지금도 있는데 당시에는 어쩔수 없었던 경우가 너무나 많았어요. 그래서 말을 안했지만 저 스스로도 굉장히 고민이 많았구요. 그래서 이번 포스팅에서는 개발자를 갈구는 기획자가 정말로 갑인지에 대해서 자세하게 말씀 드리려고 합니다. 이러한 포스팅이 도움이 되신다면 지금 저의 유튜브 채널에 오셔서 구독과 좋아요를 눌러 주시고 많은 분들에게 공유해 주시면 너무나 감사하겠습니다.
바로 본론으로 들어가서 기획자가 뭘 하는지에 대해서 말씀드리고 시작할게요. 앞서 말씀 드렸지만 기획자는 서비스를 구상하고 비즈니스 모델을 만들고 실제 화면단 기획을 하는 사람입니다. 회사에 따라서 경우에 따라서 조금씩 일거리가 더해지고 덜해지는 경우는 있지만 기본적으로 해야하는 것들은 정해져있어요. 저의 경우 SI업체와의 계약과 금액조정을 하고 최종적으로 납품까지 담당해야하는 역할을 맡아서 서비스의 탄생과 운영까지의 전반적인 업무를 맡았었어요. 그러다보니 자연스럽게 많은 사람들을 상대해야하는 일이 참 많았는데요. 조금 윗급의 직급을 가지고 계신 분들을 아시겠지만 하나의 서비스가 태어나려면 생각보다 많은 사람들이 관여하게 됩니다. 저의 경우 임원 회의 때 어떠어떠한 배경으로 인해서 어떠어떠한 비스니스가 필요하다 라고 결론이 나오면 그 비즈니스 요건을 채우기 위한 방법을 모색하게 됩니다. 그 방법이 개발이 필요한 서비스라고 결론이 나오면 초안 단계의 안건을 만들고 부장급 혹은 팀장급 이상의 멤버들을 소집해서 브리핑을 했습니다. 브리핑 시에는 회사에서 필요한 비즈니스가 무엇인지를 설명하고 작성한 초안이 어떤 효과를 만들 수 있는지를 설명한 뒤에 모두의 의견을 들어보고 초안에 문제가 없다면 필요한 자원은 어떤 것들이 있는지… 누구의 협조를 받아야 하고 기간은 얼마나 걸리는지를 확인했어요.
이렇게 회의를 통해서 개발이 필요하다는 결론이 나오면 초안을 더 보강해서 간단한 기획서와 요건을 정리해서 예산을 따내야 하는 과정이 있는데 이 개발을 해줄 업체를 조사하고 견적을 받아야하는데요. 이때는 정말로 하루종일 미팅만 하다가 집에가는 경우도 있어요. 특히 계약 내용에 관해서 심도있게 다루게 되는데 SI업체는 회사의 영업비밀이나 개인정보를 다루게 되기 때문에 NDA라고 해서 비밀유지 서약서를 받게 되어있어요. 뿐만 아니라 이레귤러한 일이 생겼을 경우 어떻게 할지 등을 확인하고 정해야 하기 때문에 다른 때보다 신경을 많이 쓰는 부분입니다. 이렇게 해서 어찌어찌 업체 선정이 끝났다면 이제는 사장님과 관련 임원들 앞에서 다시한번 더 브리핑을 하게 되요. 그래서 대략적인 개발 기간과 필요한 예산을 설명하고 품의를 올리게 되는데 품의에 결제하는 사람은 대부분이 부장급 이상인데 한사람이라도 반려를 하게 되면 반려 이유를 확인하고 다시 품의서를 써서 모든 임원의 결제를 받아야 합니다. 그리고 문제없이 품의가 통과가 되면 이제부터 본격적으로 개발이 진행되기 시작합니다. 다시말해서 개발을 진행하기도 전에 기획자는 사장님을 포함해서 부장급 이상의 임원과 팀장급 이상의 멤버, 그리고 개발을 진행해줄 외부SI업체와 수많은 미팅을 하게되요. 제가 많은 부분을 생략해서 설명했지만 적성에 안맞는 사람은 이 과정에서 이미 많은 스트레스를 받아요. 기획 내용이 잘못되어있으면 욕 바가지로 먹어가면서 다시 수정해야하고 회사의 전체적인 스케쥴이 이미 정해져 있으니 그 기간안에 빨리 품의까지 통과 시켜야하는데 많은 사람들에게 기획의 내용을 설명하고 설득을 해야하니 정신적인 스트레스가 심할 때도 있어요. 다행히도 저는 그정도까지는 아니였는데 그래도 만만치 않았던 것은 사실이에요. 특히 외부SI업체를 선정하고 견적을 받을 때가 가장 긴장 되었는데 개발에 대해서 잘 모르는 임원들 입장에서는 돈에 민감하거든요. 그래서 기획된 내용대로 잘 개발해 줄거 같으면서도 가격이 싼 업체를 선정하게 되는데 그래도 한번 개발을 시작하면 몇천만원에서 몇억 단위로 예산이 필요하게 되요. 이 숫자를 임원들에게 말하고 설득하는 일이 정말로 보통 어려운 일이 아니에요.
이렇게 기획자는 아직 개발 시작도 안했는데도 불구하고 많은 힘을 들이게 되고 품의가 통과 되고 나면 이제서야 본격적으로 개발을 시작하게 되는데 이제부터는 전혀 새로운 스트레스를 받게 됩니다. 회사로부터 Go 사인을 받게 되면 바로 Kick off가 진행되는데 그때까지 언제까지 어떤 개발을 완료할지 더 정확한 스케쥴을 정합니다. 회사에 따라서 WBS를 작성하는 곳도 있고 건 차트를 사용하는 곳도 있는데 개발스케쥴의 전반적인 흐름을 한눈에 알 수 있게 하는 점에서는 같은 맥락을 같고 있어요. 여기까지 정하고 하면 모든 멤버들에게 개발일정을 공유하고 개발을 시작하게 됩니다. SI업체는 이 스케쥴대로 개발을 진행하게 되고 그때부터 기획자는 개발자들로부터 많은 질의 응답을 하게 되요. 회사마다 다르지만 중간에 팀장급이상의 브릿지 개발자가 대부분의 질의에 대응을 해주는 경우도 있지만 브릿지 개발자가 대응하기 어려운 경우는 기획자에게 질의가 오게 되요.
이렇게 문제없이 개발이 진행되고 납품을 받게 되면 너무나 행복한 회사생활이 될거 같은데 그러기가 쉽지 않은게 현실이에요. 정말 상상도 할 수 없는 일 때문에 개발이 지연되고 추가 예산을 따내야 하는 경우가 종종 생기는데요. 어떠한 경우가 있는지 제가 몇가지 예를 설명해드릴께요. 먼저는 기획단계에서 문제가 있는 경우인데요. 아무리 꼼꼼하게 기획 했다고 하더라도 조건이 많아지면 서로 모순 되는 기능이 생기게 마련이에요. 노련한 기획자들은 이런 모순을 빨리 알아채고 미리미리 수정을 하지만 그래도 사람인지라 모르고 개발을 진행할 때가 있어요. 그럼 개발자가 개발하는 단계에서 알아채고 기획자에게 문의를 해요. 크리티컬한 문제가 아니라면 그냥 다행이지만 경우에 따라서는 비즈니스 모델을 변경해야하는 상황까지 일어나게 되요. 그럼 어떻게 해야하냐… 다른 베스트 대안을 찾아내던가 아니면 추가 예산을 따내야하죠. 물론 추가 예산까지 따낼 정도면 정말 최악이고 대부분은 다른 베스트 대안을 찾게 됩니다. 암튼 이러한 이유로 스케쥴이 지연되는 경우가 있어요.
그 다음으로는 임원들의 변심입니다. 기획자는 정기적으로 현재 개발의 진행도와 중간 결과를 임원급들에게 보고하게 되는데 보고가 끝나면 임원들이 서로 한마디씩하는데 이게 문제에요. 다들 어디서 보고 들은건 있어서 이 화면에서는 이런 기능이 있으면 좋겠다…이건 없어도 좋겠다… 이건 왜 이따구로 했냐… 이렇게 한마디씩 하는데 지금와서 그런 말을 하면 어쩌자구… 이런 생각이 너무나 자연스럽게 들어요. 그런 말은 기획단계일 때 해주던가… 지금 개발 하고 있는데 기획서를 수정하면 개발자들한테 욕먹는 사람은 기획자거든요… 시간과 예산이라도 늘려주면 그나마 다행인데 이마저도 안해주면 정말로 내 문서에 있는 퇴직서에 오늘 날짜를 적고 싶은 생각이 북받쳐요. 그래도 어떻합니다. 까라면 까야지… 임원들 시키는 대로 기획서 내용 수정하고 충분한 기도와 마음의 준비를 하고 SI업체에 연락합니다. 기획서 변경됬다고… 이러면 당연히 짜증냅니다. 저 같아도 그럴거 같아요. 근데 저도 어쩔 수가 없는 상황이잖아요. 위에서 시키는 거니깐 억지로라도 밀어붙여야 하는 입장이니 SI업체가 뭔 말을 하든 저의 대답은 정해져 있어요. 하기 싫은 말을 할 수 밖에 없거든요. 말 하다보니깐 제가 기획자에 대해서 안좋은 이야기만 하게 됬는데 잠깐 해명을 하자면 매번 이런건 아니에요. 그리고 다른 기획자 분들은 어떤지 제가 모르기 때문에 저만 이런 경우가 있었다고 생각해 주세요. 정말 기획자로서 행복하게 일을 하고 계시는 분들도 분명 계실 수 있기 때문에 기획자에 대해서 편견을 안 가지셨으면 해요.
암튼 제가 이제 개발자가 되서 다시금 기획자를 바라보면 모두가 다 그런건 아니겠지만 세상에 쉬운 일은 없구나 하는 생각을 하게 되요. 혹시나 이 포스팅을 보고 계신 분들중에 저와 비슷한 경험을 하고 계신 개발자님이 계시다면 짜증은 나겠지만 그냥 저사람들도 먹고 살려고 고생하는 구나.. 이렇게 생각해 주세요. 정상적인 인간이라면 자기도 바꾸고 싶어서 바꾸지는 않을거에요. 가끔 정상적이지 않은 호모사피엔스가 있긴 한데 모든 기획자나 영업맨이 악의를 가지고 바꾸지는 않아요.
근데 더 큰 문제는 이러한 문제가 한번이면 족한데 여러번 발생 했을 경우가 정말 힘들어요. 그때는 정말 개발자들이 싫어하는 짓만 골라서 하게되요. 기획자가 스케쥴의 압박을 받으니깐 일주일에 한번 하던 개발 진행상황 보고도 이틀에 한번, 하루에 한번 씩 받자고 하고 문제가 생기면 팀장급 개발자에게 맡기면 될 일을 기획자가 오지랍 떠는 경우가 생기게 되요. 참고로 제가 기획자일 때는 그러지 않았어요. 제가 SI개발자일때 이런 호모사피엔스를 자주 만났어요. 어차피 코드 보여줘도 못 알아들을거면서 뭐가 문제냐고 오지랍떠는 클라이언트쪽 기획자가 있는데 하루에도 몇번을 전화하고 메일을 보내는데 그때는 정말 가족 이상으로 저에게 연락을 해주는 사람이 되요. 암튼 특히 이러한 일이 여러번 발생할 경우 거의 99.999%의 확률로 개발이 딜레이되고 있을 거에요. 그럼 기획자는 이미 많은 임원들로 부터 갖은 욕과 압박을 받은 상태일 확률이 높습니다. 스케쥴이 지연되니 빨리 대응책을 마련해야하고 이렇게 준비한 자료를 임원들에게 보고하고 얼마나 딜레이되고 경우에 따라서는 추가예산이 얼마인지도 보고하고 품의 진행해야 해요. 이쯤되면 기획자는 잘해야 본전이라는 말이 딱 어울리게 되요. 만약 추가 예산이 안잡히면 정해진 기간 내에 빨리 개발하라고 개발자들을 압박을 하게 되는데 정말 개발자들과 점점 사이가 틀어지게 됩니다.
이렇게 어찌어찌 개발을 완성하게 되면 리뷰를 진행하고 납품까지 완료하게 되는데요. 납품하는 날 웃으면서 서로 고생했다고 말은 하지만 다시는 만나지 말자는 감정까지 같이 전해집니다. SI업체에 들어가면 많은 개발자들이 고생한다고 이미 많은 매체를 통해서 들으셨을거라 생각하는데 어떠신가요? 기획자의 입장이 갑으로 보이시나요? 제가 모든 기획자를 대변하려는 건 아니고 이번 포스팅에서는 저의 경험을 토대로 이런 경우도 있다는 것을 알려드리고 싶어서 포스팅을 하게 되었어요. 기획자라고 해서 항상 갑의 위치는 아니고 갑의 위치인지 아닌지는 항상 상대적이라는 것을 전달해 드리고 싶었어요. 지금은 제가 개발자가 되었고 기획자들과 같이 일을 하면서 어떻게 하면 나와 기획자가 서로 윈윈 할 수 있는 관계를 만들 수 있을까 하는 고민을 하는 단계까지 왔어요. 경우에 따라는 기획자가 절대 생각해 낼 수 없는 해결 방법을 개발자는 생각해 낼 수 있거든요. 이런 생각을 할 수 있었던 건 아마도 제가 기획자와 개발자를 둘다 경험해 봐서 알 수 있었던 건지도 모르겠네요. 때문에 오늘의 결론. 기획자와 트러블이 있다면 이성적으로 원인을 분석하고 원만한 커뮤니케이션으로 베스트 대안을 같이 찾아내야 한다는 점이에요. 확 까놓고 말해서 기획자나 나나 서로 월급쟁이거든요. 저쪽도 살려고 이것저것 하는거니 문제가 생겼을 때 너무 감정적으로 대하지는 마시고 이성적으로 해결한다면 더 행복한 개발 생활이 가능하지 않을까 싶습니다.
제가 준비한 포스팅은 여기까지이고 혹시나 다른 의견이나 에피소드가 있으시면 댓글로 남겨주세요. 그리고 이 포스팅이 도움이 되셨다면 좋아요와 구독을 눌러주시고 더 많은 사람들이 볼수 있게 많은 공유를 부탁드립니다. 그럼 저는 더 좋은 포스팅으로 여러분들을 다시 찾아뵙겠습니다. 감사합니다.
