‘협상’이란 무엇일까? 내 이익을 위해 상대에게 양보를 바라는 논쟁일까?

KOTRA가 2007년에 조사한 「16개국 비즈니스 협상스타일」에 따르면 우리나라 경영자들은 상대의 이익은 고려하지 않고 나의 이익만을 추구하는 이기심은 최고인 반면, 협상을 자신의 의도대로 이끌어 가는 협상주도력은 꼴찌였다. 

이 조사를 주도했던 글로벌 협상전문가 진브렛(Jeanne Brett) 교수는 “협상 시 자신의 이익만큼 상대의 이익도 중요하다는 것을 인식해야만 양측의 기대치를 모두 충족시키는 원만한 결과를 도출할 수 있으며, 협상 결렬에 대비한 대안을 얼마나 갖고 있느냐에 따라 협상의 성공여부가 달려있음을 알아야 한다.” 라고 충고했다.  

우리 주변에서 협상은 쉽게 발생한다. “오늘은 무엇을 먹을까?” “이번 주말은 어디로 갈까?” 등 혼자 결정하지 않는 이상 모두 협상이 필요하다. IT컨설턴트로 BPR¹, ISP², PMO³ 등 여러 프로젝트에 참여하며 협상이 필요한 많은 순간들을 겪었다. 여러 이해관계자가 존재하는 프로젝트 현장에서 모두가 수용할 수 있는 협상 대안을 도출하고, 서로의 관계도 해치지 않는 협상 방법이 있을까? 미국 하버드 대학의 협상프로젝트팀들의 경험을 기술한 ‘Yes를 이끌어 내는 협상법(Getting to Yes)’의 일부와 필자의 경험을 소개한다.

1. BPR(Business Process Reengineering) : 업무 효율 극대화를 위한 비즈니스 프로세스 재설계
2. ISP(Information Strategy Planning) : 조직의 중장기 비전 및 목표, 경영계획을 지원하기 위한 정보시스템 구현 목적의 정보화 전략 계획 수립
3. PMO(Project Management Office) : 대규모 장기 프로젝트의 성공적인 수행을 위하여 범위관리, 일정관리, 위험관리, 인력관리 등 체계적인 프로젝트 관리 지원

 

1. “요구”가 아닌 “욕구”에 집중하라

‘요구’는 상대에게 주장하는 요구사항이고, ‘욕구’는 이를 주장하게 된 동기이다. 예를 들어 회식장소 선정을 위해 막걸리파와 와인파로 나뉘어졌다. 양측의 ‘요구’에만 집중하면 장소 선정이 어렵지만, ‘욕구’를 파악하면 쉽게 해결된다. ‘비가 오니 막걸리가 마시고 싶다’는 욕구와 ‘주종상관없이 와인바 같은 분위기 좋은 곳에 가고 싶다’란 욕구를 모두 충족시켜줄 수 있는 ‘와인 잔에 막걸리를 마시는 분위기 좋은 퓨전 주점’으로 가면 된다.

● 추가 요구사항이 발생하는 경우 고객의 욕구를 파악해본다

프로젝트 도중에 고객이 과업범위서에 없던 추가 요구사항을 제시하기도 한다. 이런 경우 타이트한 일정으로 수용하기 어려워 단번에 거절하거나, 주말 작업을 각오하고 수용하는 결정을 내리기 전에 고객이 왜 이런 ‘요구’를 했는지에 대한 ‘욕구’를 파악해야 한다. 나 스스로 ‘왜 이런 요구를 할까?’에 대해 생각해보고, 고객에게 질문을 함으로써 정확히 파악하는 것이 좋다. 정확한 ‘욕구’를 파악한다면 기존 산출물에 해당 내용을 포함하여 상세하게 작성하거나, 추가 작업을 하는 조건으로 기존 과제의 작성 수준을 고객과 협의하는 등의 대안을 제시할 수 있다.

 

2. 상호이익이 되는 “창의적인 대안”을 개발해라

프로젝트는 시간과 인력이 한정되어 있다. 소속과 이해관계가 다른 사람들이 모여서 프로젝트를 수행한다. 서로 중요하게 생각하는 기준이 달라서 의견 충돌이 발생할 수 있다. 이런 경우 가치 교환하기(중요한 가치는 상대에게 요구하고, 덜 중요한 가치는 양보하며 서로가 중요한 가치를 얻는 법), 안건 추가하기(협상중인 안건 ‘agenda’ 외에 새로운 안건을 추가하여 파이 키우기), 공정한 제삼자에게 조언 구하기 등의 방법을 이용할 수 있다.

● 테스트를 위한 테스트가 아니라, 성공을 위한 테스트 방안을 생각해본다

통합테스트 단계로 들어가더라도 발견된 오류를 수정하거나, 잔여 물량의 개발 등의 업무가 진행된다. 테스트책임자는 개발자들에게 테스트에 몰입해줄 것을 요구한다. 개발자는 개발 물량 소화가 급하기 때문에 테스트에만 전념하기 어려운 상황이 된다. 테스트에만 전념하면 품질 문제는 해결되겠지만, 예정 진도를 지키기 어렵게 된다. 이런 경우에는 테스트 대상을 등급제로 구분하는 방안을 적용할 수 있다. 중요도와 의존성을 기준으로 분류하여 개발과 테스트가 병행될 수 있도록 대안을 준비하는 것이다.

 

3. “사람”과 “문제”를 분리하라

협상을 하다 보면 감정이 격해져 상대방을 비난하고 공격하여 서로 기분이 상하는 일이 생길 수 있다. 하지만 공격대상은 상대방이 아닌 문제(안건)이며, 상대방은 나와 같이 문제를 해결하는 동반자로서 존중해야 한다. 감정 문제가 되면 협상은 꼬이게 되고, 문제 해결은 더욱 어려워진다. IT프로젝트를 진행하면서 항상 발생하는 것은 개발자가 자신이 약속한 일정을 종종 어긴다는 것이다. 이런 일이 반복되면 문제에 집중하기 보다 서로 비난하는 상황이 되기도 한다. 

● 사실을 기반으로 ‘트레이드 오프’를 생각해본다

닫힌 문제(closed problem)는 해결되지 않는다. 열린 문제(open problem)로 만들어야 길이 열린다. 수용할 수 없는 품질 수준의 산출물이 뒤늦게 발견되는 경우는 심각한 상황을 만든다. 예정된 모든 산출물을 원하는 수준으로 목표 기간 내에 완수한다는 것이 불가능한 것임을 알게 된 경우에도 원래 계획을 밀어붙이면 도리어 큰 실패에 봉착할 수 있다. 범위 조정, 인력 추가 투입, 납기 연장, 산출물 일정 변경 등의 대안에 대해서 사실에 근거해서 논의하고 결정해야 한다. 이를 위해서는 프로젝트 참여자들의 신뢰관계 형성이 중요하다. 비난 보다는 이해와 존중이 필요하다.

 

4. “객관적 기준”에 근거하여 주장하라

협상에서 서로 주장이 부딪히는 경우가 종종 있다. 서로 자기 입장만 주장하면 결론이 나지 못하고 네버엔딩 토의가 되어서 결론을 내리지 못하게 된다. 예를 들어서 주택 매매 협상 시 집주인이 제시한 금액의 기준을 원매자가 받아들이지 못한다면, 주택 매매 협상은 결렬될 것이다. 협상 상대방이 서로 받아들일 수 있는 공정한 기준을 제시할 수 있다면 협상은 진척을 보이게 될 것이다. 공정한 기준에는 객관적 기준(법률, 정책, 선례, 시장가격, 전문가 의견 등)과 주관적 기준(상대가 추구하는 약속, 신념, 철학 등)이 포함된다. 사람들은 자신의 약속과 신념을 책임지고 지키려고 하기 때문에 이에 반하는 의견은 받아들여지기 어렵다. 

● 사용자 인터페이스 설계는 사용자 승인을 잘 관리해야 한다

IT프로젝트에서 현업사용자의 변경 요청이 가장 많은 대상은 화면이다. 설계 때 화면표준정의서, 디자인가이드, 스토리보드, 화면 설계서 등 문서로 확인했음에도, 테스트 단계에서 실제 동작하는 화면을 보게 되면 변경을 요청하는 경우가 자주 발생한다. 심한 경우에는 당초 확인한 A안을 B안으로 변경해달라고 했다가, 변경된 화면을 보고 나서 다시 A안으로 바꿔달라고 하기도 한다. 개발자는 불필요한 작업을 수행하게 되는 셈이다. 화면 설계와 개발 및 변경은 전체 프로젝트 생산성에 큰 영향을 미친다. 확정된 화면은 변경할 수 없다는 기준을 명확하게 하고, 관련 문서를 기록으로 관리하여야 한다. 화면과 관련된 객관적 기준을 확보함으로써 프로젝트 지연을 최소화할 수 있다.

 

5. 협상 준비 과정에서, “BATNA”를 만들어라

모든 협상이 항상 원만하게 타결되는 것은 아니다. 협상이 교착, 결렬될 경우를 대비하여 대신 선택할 수 있는 대안이 있다면 나의 협상력은 달라진다. 협상을 내 의도대로 이끌고 가는 협상주도력은 BATNA(Best Alternative to a Negotiated Agreement)가 있을 때 생긴다. 예를 들어 딸기를 사려고 가게에 갔는데, 가격이 너무 비싸 깎아달라고 했다. 주인은 나 말고도 사겠다는 손님이 많으면 거절하겠지만, 손님이 없다면 깎아줄 것이다. 나도 주변에 다른 가게가 있다면 가격을 비교하며 더 좋은 곳을 선택할 것이다. 주인 입장에선 ‘나 말고 다른 손님’, 내 입장에선 ‘다른 가게’가 BATNA인 것이다.

● 발주 단계에서도 대안을 만드는 것이 좋은 협상을 할 수 있다

사업자 선정에서 단독 입찰과 경쟁 입찰에 따라 발주사의 협상력은 크게 달라진다. 경쟁입찰이면 우선협상대상자와 협상이 잘 안될 경우 2순위 업체와 협상을 할 수 있다. 이처럼 BATNA(2순위 업체)가 있는 경우 발주사가 요구사항을 강하게 주장할 수 있지만, 단독 사업자만 존재하는 경우 힘들다. 협상학에서는 BATNA가 없다면 협상을 포기하라고 하지만, 어렵게 예산을 확보하여 기획한 사업을 취소할 수 없다. 사업을 매력적으로 기획하고 홍보해야 하며, 단독 입찰로 유찰된 경우에도 다른 제안사가 참여할 수 있도록 노력해야 한다⁴. 

4. [대규모 IT프로젝트 단독 입찰을 피하려면 어떻게 해야할까?] 투이톡 글을 참고하길 바람