반응형

우선협상대상자로 선정되고 협상을 1주일 동안 진행했다. 지나고 나서 안 사실이지만 많은 사람들이 협상 때 난항이 있을 거라고 예상했다고 한다. 아무런 이슈 없이 협상이 끝났다고 하자 다들 갸우뚱해했다. 안심하면서 신기하다고 했다. 그리고 이건 어떻게 됐냐, 저건 어떻게 됐냐 물었는데 모두 다 협상 때 크게 다루지 않았던 것들이었다. 협상을 무난하게 넘기고 싶다면 참고하면 좋을 팁들을 몇 가지 공유하려고 한다.


1. 굳이 불리한 이야기는 꺼내지 마라

 

어차피 일하면서 정해질 일들이 있다. 어차피 해야 하지만, 처음부터 이야기해서 득이 되지 않을 것들 말이다. 대표적인 것이 인공지능 사업에서는 '인식률' 또는 '정확도'라고 부르는 것이다. 상호 간에 동일한 기준을 이야기하고 있는 것 같지만 그렇지 않은 경우들이 많고, 서로 이해하는 수준이 달라서 누군가의 숫자가 받아들이기 어려운 상황이 나타나기 마련이다. 그럴 때 숫자를 최대한 높게/적게 잡는 것이 협상에서 중요하다고 생각할 수 있지만 사실 그렇지 않다. 

 

협상이 다 끝나고 고객 PM에게도 그렇게 이야기했다. "모두 인식률 갖고 걱정을 많이 하셨는데 저희는 프로젝트 진행하면서 상호 협의하에 숫자를 정하는 걸로 했다고 보고했습니다. 만약 저에게 높은 숫자를 주셨다면 저는 그날부터 그 숫자를 맞추기 위한 산식을 만들고 있었을 거예요. 그러다 보면 결국 사용자가 체감하는 인식률과 거리가 멀어졌을 거예요." 

 

팁이 그런데 인식률에 대한 이야기가 왜 협상 때 나왔냐...라고 물으면... 우리 영업대표가 이야기를 꺼냈다. (참고로 이야기하면 우리 영업대표는 우리 발에 총 쏘는 일을 잘하신다. ^^) 그 질문에 고객 PM도 나도 난색을 표했는데 다행히 당장 답을 못 주는 고객에게 내가 이후에 정해도 된다는 시간적 유예를 줘서 고객도 오케이를 해줬다. 숫자를 정하지 않겠다는 게 아니니 고객도 오케이를 한 것이다. 그리고 숫자가 정해지지 않은 협상 회의록이니 검수 기준으로 분쟁이 생길 수 없다. (당장은 그렇다는 것이다.)

 

 

2. 어차피 해야 하는 건 협상거리가 아니다.

 

고객 PM이 A 기능을 만들어달라고 해서 나는 RFP에 있던 기능이니 만들어서 제공할 거라고 대답했다. 그에 대해 고객 PM이 A 기능을 어떻게 제공할 건지 정해야 하는 건지 얼마나 상세하게 협의해야 하는지 내 의견을 물었을 때 나는 간단하게 대답했다. "지금은 수용여부에 대해서 정하면 될 것 같고, 어떻게 개발할지는 설계 단계에서 합의하면 될 것 같습니다." 고객은 이에 오케이 했다.

 

1번도 2번도 모두 내가 미루는 걸로 보일 수 있다. 단순히 시간을 버는 행위 아니냐고 물을 수도 있다. 하지만 그 요건이 어떤 수준인지 모르는 상황에서 무조건 그 방식까지 수용하는 것은 위험하다. 분석/설계 단계가 있는 이유가 그런 거다. 고객 현황에 어떤지 분석을 하고 그 요구사항을 개발하기 위해 설계를 하는 것이다. 고객사에 대해 아무것도 모르는 상태에서 고객이 제시한 방식을 수용한다는 것은 설계 단계에 우리의 권한을 다 걷어가겠다는 것과 다름없다. 설계 단계는 고객사/수행사 모두 유리한 방향으로 설계가 되어야 한다. 그렇기 때문에 나는 '제가 더 파악한 이후에 결정하는 것이 맞을 것 같습니다'라고 돌려서 대답한 것이다.

 

협상 단계에서부터 최대한 많은 이야기를 듣고 싶은 마음은 이해하지만 그 모든 대화가 회의록에 남아야 할 수도 있으니 일을 줄이고 싶다면 그건 뒤로 미루는 것을 추천한다.

 

 

3. 해주기 어려운 걸 해달라고 하는 경우, 수용 여부에 대한 답이 아닌 할 수 있는 수준에 대한 답을 해라.

 

고객이 무리한 요청을 하는 경우가 있다. 협상 회의록에 적시하게 해서 상호 간의 사인을 통해 그 효력을 발생시키게 하려는 속셈이다. 다른 회의록보다 협상 회의록은 그 중요성이 더 크기 때문에 기회를 노리면서 서로 자기에게 유리한 말을 넣는 데에 혈안이라고나 할까. 이럴 때는 마치 다른 요구사항처럼 하겠다/못한다와 같은 결정을 내야 할 것 같은 압박을 느낄 수 있지만, 꼭 그럴 필요는 없다. 이런 결정을 내려야 하는 것은 RFP에 이미 명시되어 있거나 수행사가 제안서에 이미 적시해서 빼박인 경우다. 갑작스럽게 협상에서 꺼낸 이야기라면 무조건적으로 수용할 필요가 없다. 

 

모든 것이 종결되기 전에는 협상이 끝나지 않는 것이 원칙이라 결론을 내리지 않고 협상을 종료시킬 수 있는 방법은 없다. 그래서 이런 아젠다가 나오면 할 수 있는 방법이 몇 가지가 있다.

 

어떤 걸 해줄 수 있지만 고객사에서 어떤 어떤 걸 해줘야 한다.라는 식의 조건. 그게 역할일 수도 있고(예 : 데이터 적재는 해줄 수 있으나 적재할 데이터는 고객이 다 제공해줘야 한다), 아니면 수준의 명시일 수도 있다(예 : 협상 때 이야기한 새로운 기능에 대해서는 개발까지는 못해주고 설계까지 해주겠다.) 그것도 아니면 "이번 과업범위가 아니며 추가 계약을 통해서 제공 가능함"과 같이 돈을 더 주면 해주겠다고 할 수도 있다. 마지막 방법은 사실 싸우자는 이야기가 될 수 있어서 추천하진 않지만, 특정 요구사항은 그렇게 해야 정리되기도 하니 참고하면 좋다.

 

 

4. 불리한 요구사항에 대한 내용은 회의록에 모호하게 써라

 

그 자리에서 "네"라고 수용했어도 고객과 내가 이해한 수준에 GAP이 있다면 회의록에 명시를 모호하게 하는 게 중요하다. 고객이 '어떻게 쓰세요'라고 불러줬어도 내가 능력이 부족하여 이 정도밖에 못 쓰는 것인 양 써서 돌려주는 방법이다. 아주 성실한 고객이나 아주 독한 고객은 그 문구에 취소선을 긋고 빨강색으로 새로 써서 돌려주기도 하지만, 무리한 부탁을 했다는 걸 알고 + 무리한 부탁이라 모호하게 썼다는 걸 이해하는 고객이라면 넘어가준다. 이런 과정에서 고객이 어떤 스타일인지도 파악이 가능하다.

 

모호한 요구사항에 대해 나에게 유리한 해석이 무엇인지도 미리 잘 대비해야 한다. 그냥 어물쩡 '난 몰라요~'하면 안 되고 '당신이 이렇게 말해서 난 이렇게 이해했다. 회의록도 그렇게 썼다. 그 회의록에 서로 사인한 거 아니냐?'라고 주장할 수 있는 수준의 논리가 있어야 한다는 뜻이다.

 

 

5. 협상 회의록은 프로젝트의 성공을 위해 써야 한다

 

가끔 수행사라고 수행사에게 불리한 건 안 쓰고 유리한 것만 쓰는 데에 집중하는 사람들이 있다. 예를 들면 "PoC이기 때문에 인식률은 검수 기준이 아니다"이거나 "인식률 80%를 검수 기준으로 한다"라는 내용들을 회의록에 쓰고 그거 믿고 프로젝트를 수행하는 것이다. 그리고 마지막에 프로젝트가 인식률이 엉망이거나, 인식률이 90%로 집계되었으나 고객의 불만이 하늘을 찌를 때가 있다. 결국 "이런 인식률이 나오는 시스템은 쓸 수가 없다. 고로 우리는 검수해 줄 수 없다"라는 상황에 직면하게 된다. 쉽게 생각하면 협상 회의록을 꺼내고 싸우면 간단하게 이기고 나올 거라 생각할 수가 있다. 당당하게. "이거 봐라, 이렇게 쓰고 서로 합의하지 않았냐!" 하면서 말이다.

 

실제로 "숫자 맞췄는데 왜 개선작업을 더 해야 하죠?"라고 나에게 따졌던 업체 직원이 있었다. 검수 기준 인식률 90%을 만족시키는 숫자가 나왔는데 더 많은 걸 요구한 나에게 화내는 소리였다. 그 사람에게 대답을 줬다. "쓸 수 없는 시스템에 검수 사인을 해줄 고객은 없으니까요. 입장 바꿔 생각해 보세요. 당신이라면 쓸 수 없는 시스템을 돈 들여서 만들었는데 그걸 윗사람에게 보고할 수 있겠어요?" 당시에 내 대답에 못 마땅해했지만 억울함을 억누르고 그분은 작업을 진행했고 우리 시스템은 모델 인식률 90%, 실질 업무 적용 인식률 97%를 달성하고 프로젝트 종료 1일 전에 고객과 악수하고 철수했다.

 

그래서 협상 회의록에 나에게 유리한 문구를 쓰면서 좋아하는 사람이 있다면 꼭 알아두기를 바란다. 그 문구가 고객의 발을 잡는 게 아니라 내 발을 잡게 된다는 사실을. 검수를 못 받고 곤란한 상황에 빠지게 되면 내 회사는 "회의록에 이렇게 쓰고 합의했잖아. 이거 들고 가서 싸워서 이기고 와."라고 할 것이다. 그러면 고객은 그 숫자가 있든 말든 상관없이 "쓸 수도 없는 시스템을 만들어놓고 어떻게 검수해요"라고 화를 낼 것이다. 그 사이에서 고생하는 것은 결국 수행사 PM과 그 프로젝트 팀원들이다. 누구도 도와주지 않을 것이기 때문이다.

 

이번 협상 회의록을 쓰면서 고객이 "인식률이 나쁘다고 검수를 안 해주진 않을 거다"라고 말했다. 그 말을 세 번 하면서 나를 쳐다봐서 내가 "왜 저를 보면서 그런 말을 하시나요?"라고 물었더니 "PM이시니까요"라는 답이 돌아왔다. 그 대답을 듣고 좋아했던 우리 회사 영업대표와 프로젝트 팀원과 달리 나는 미지근하게 "네"라고 하고 모호한 표현으로 협상 회의록을 썼다. 그리고 고객 PM과 따로 만난 자리에서 이야기했다. "협상 회의록이 저에게 불리하게 쓰지도 않았지만, 저에게 유리하게도 쓰지 않았습니다. 특정 문구로 인하여 우리 회사가 저로 하여금 고객사와 싸워서 이기고 오라고 할 명분을 주기 싫었습니다. 전 이 프로젝트가 잘 끝나기 위한 기준으로 회의록을 썼습니다." 내 대답에 고객은 조용히 날 쳐다봤다. 다른 건 몰라도 내가 회의록을 대충 쓰지 않았다는 건 아시는 것 같았다.

 

 

6. 중요하지 않은 것, 묻고 싶은 내용은 회의록에서 빠뜨려라

 

고객이 기억하지 못할 것 같은 내용인데 나에게 불리한 내용이 있다면 스리슬쩍 회의록에서 지워버려라. 회의록을 먼저 쓰는 게 수행사라는 장점은 여기에 있다. 백지에서 내용을 채울 때는 빠뜨린 내용이 있는지 확인하면서 쓰는 게 쉬운데, 다 채워진 내용을 검수하는 입장이 되면 빠진 내용을 찾아내기 어렵기 때문이다. 그래서 언급하고 싶지 않은 내용이 있다면(글로 박제시키고 싶지 않은 내용) 슬쩍 쓰지 말자. 검토 요청을 고객에게 어차피 보내야 하니 그때 고객이 찾아내면 추가하고(어머 제가 깜빡했네요! 추가할게요!), 그렇지 않으면 빠진 채로 덮자. 나름 이것도 팁이라면 팁이다.


고객사라면 몰라도 수행사는 사실 협상 단계에서 쐐기를 박으면서 유리해질 수 있는 방법이 별로 없다. 협상이 잘 흘러가지 않으면 위로 보고가 올라가서 힘으로 누르기도 하고, 그보다 더 심각하면 협상이 결렬되면서 다른 회사에게 협상이 넘어갈 수도 있기 때문이다. 그래서 수행사는 불리한 입장에서 협상 테이블에 앉을 수밖에 없어서 꼼꼼한 고객이 나타나서 다 짚어가면서 확인하거나(이거면 그래도 다행) 선을 넘어서 갑질을 가미해서 업무 범위에 없는 걸 요구하는 협상을 하면 수행사는 고개 숙이고 수용할 수밖에 없는 상황에 처하기도 한다.

 

그렇기 때문에 최대한 동등한 입장에서 이야기를 하려면 협상 단계를 무난히 넘겨야 한다. '나는 수용 잘해주는 PM이에요~ 다 맞춰드려요~'의 이미지를 풀풀 보이면서 고객의 신뢰를 얻는 단계로 써야 한다. 거짓으로 그런 연기를 하라는 건 아니다. 그저 협상은 그런 단계라는 걸 이야기하는 것이다. PM끼리 서로 대화가 될 사이인지, 우리가 잘 맞을지 견줘보는 것이니 그 단계를 잘 넘기는 것이 중요하다. 그러면 양사 PM이 '이런 거라면 이 프로젝트는 끝까지 잘 가겠구나'라는 인상을 받을 수가 있다.

 

협상을 넘겨버리고 싶은 단순한 단계로 생각한다면 그러지 않기를 바란다. 상대방보다 2걸음은 더 앞서 걸어야 하고 문구 하나라도 더 유리하게 쓰기 위해서 고도의 머리를 써야 하는 두뇌게임이다. 그리고 그렇게 협상이 잘 끝났을 때, 난 힘들게 했지만 주변은 모두 '쉽게 지나갔네?' 할 것이다. 이런 피드백을 들으면 그제야 '아 내가 잘했구나'라고 생각하면 될 것이다. 물론 이 모든 것이 정말 잘 된 건지는 프로젝트가 끝날 때 알 수 있을 것이다.

 

자, 이제 다음 단계다!

 

2023.10.23 00:13

반응형

+ Recent posts