[SI이야기] 턴키(Turn key)계약에서 현장대리인의 역할

SI 프로젝트를 수행하다 보면 단일회사로만 구성해서 프로젝트를 수행하는 일은 극히 드물다. 한 회사에 하나의 시스템을 구성하기 위해 요구되는 솔루션과 인력을 다 갖추기 어려워서 그러한 건데(이런 일이 발생하는 이유는 절대 그 회사가 무능해서가 아니다), 이런 상황에서는 갑-을의 관계 이상으로 갑-을-병 이상의 구조가 만들어지기 마련이다. (갑-을-병-정 이상으로 가는 경우는 '재하도'가 금지된 경우 불가능한데 이건 다음에 기회가 되면 이야기하겠다.)

 

오늘은 이런 경우에 생기게 되는 '현장대리인'이라는 사람에 대한 이야기를 하려고 한다.

 

우선, '현장대리인'이라는 존재는 맨먼스(MM) 계약에서는 등장하지 않는다. 턴키(Turn Key) 계약인 경우에 등장하는데 그 이유는 어 계약의 특성 때문이다. 혹시 둘의 구분을 잘 모른다면 지난 포스팅을 참고하자.

 

2020.06.11 - [슈르의 오피스라이프/SI 이야기] - [SI이야기] SI 계약 방식, 턴키(Turn key)방식과 맨먼스(Man Month)방식의 장단점

[SI이야기] SI 계약 방식, 턴키(Turn key)방식과 맨먼스(Man Month)방식의 장단점

 

턴키 계약은 맨먼스와 달리 업무 자체에 대한 계약으로 이루어지기 때문에 그 안에 어떤 사람이 들어오고 어떻게 일하는지에 대한 관리 권한이 매우 약한 계약이다. 무슨 말인고 하니, 회사 대 회사의 계약으로 '우리 회사(갑)가 상대회사(을)에게 얼마의 기간과 얼마의 비용을 줄 테니 A라는 시스템을 완벽하게 개발해서 전달해주세요'라고 하는 것이기 때문에 개발 범위, 기간, 비용에 대한 합의가 이루어졌다면 그 이외의 사항에 대해서는 노터치하는 구조라는 것이다. 그렇기 때문에 갑사가 을사가 지금 뭘 하고 있는지, 누가 하고 있는지, 어떻게 하고 있는지에 대해서는 사실 관여할 권한이 약하다고 볼 수 있다. (없는 거 아니냐고 오해할 수 있는데 없는 건 아니다. 보통 계약에는 주간보고, 산출물 등의 세부 사항들이 있기 때문에 관리 감독은 가능하다.)

 

맨먼스 계약은 회사 대 회사가 시스템을 개발해달라고 하는 계약이 아니다. '얼마를 줄 테니 사람을 주세요'라는 계약이다. 그렇기 때문에 어떤 사람(스펙)이 얼마 간의 기간 동안 얼마를 받고 일하는지 계약하는 것이다. 이런 경우 그 사람을 받아서 일을 주는 거기 때문에 그 사람의 근태, 수행 업무 등 다 관리할 수 있다. 그 범위도 나름 정해져 있긴 한데 (개발자를 불러서 커피 심부름을 시킬 순 없다.) 그래도 일을 줄 수 있는 범위가 자유로운 편이다. 그래서 프로젝트의 범위가 명확하지 않고 임기응변이 요구되는 계약을 해야 한다면 맨먼스 계약도 괜찮다.

 

쨌든, 이런 특성 때문에 턴키 계약을 하면 '현장대리인'이라는 사람이 등장하게 된다. 프로젝트 수행하려고 계약할 때 업체 직원에게 '현장대리인 지정해주세요'라고 말하면 나름 베테랑인 회사는 바로 대답이 나오는데 그러지 못한 회사는 '그게 뭐죠?'라고 묻기도 한다. 그렇게 이름을 지정해서 계약을 하는데, 업체에서 이름 불러준 사람은 베테랑이라 이름을 쉽게 던져줬는데 실제 당사자는 자기 역할이 뭔지 모르는 경우가 다반사이다. '전 개발하러 왔는데요?'라는 눈빛으로... 

 

안타까운 점은, 현장대리인의 이런 태도 하나 때문에 그 회사의 직원들이 다 고통을 감수하게 된다는 것이다. 왜일까? 현장대리인이 뭐길래?

---

얼마 전에 팀 후배에게 전화가 왔다. 현재 일이 너무나도 힘들다는 하소연이었다. 뭔 일인지 들어보러 직접 사이트로 찾아갔다. 그리고는 이야기해보라고 했다. 그 후배의 이야기는, 놀라웠다.

 

"진척 확인을 하라고 해서 개발자를 다 만나서 하나씩 이야기하고 있어요."

"(어느 부분) 개발 영역은 자기 역할이 아니라고 해서 PL님이랑 저랑 모여서 회의해서 정리해야 했어요."

그리고... 그리고...

 

그 후배에게 내가 "그 업체 현장대리인이 누구예요?"라고 물었다.

후배 : "현장대리인이요? 모르겠는데요?"

나 : "네? 그럼 누구랑 이야기하고 있었어요?"

후배 : "매번 달랐죠."

 

아.... 큰일이다. 싶었다.

---

현장 대리인은... 턴키 계약을 하면 계약하는 회사마다 한 명씩 지정하는 사람이다. 그 현장에서 자기 회사를 대리하는 사람이라고 보면 된다. 발주사(갑)에는 그런 존재는 없고, 수행사(을)에는 PM/PL이 그런 역할을 수행한다. 그 밑에 업체(병)의 경우 PL이 있다면 그 사람이 현장대리인을 겸하는 게 보통이고, 만약 PL이 없고 개발자만 있다면 그중에 누군가가 현장대리인을 해야 한다. (현장대리인 지정을 안 하는 방법은 없다. 본 적이 없다.)

 

그래서 그 현장대리인이 하는 일이 무엇인고 하니, 나에게 갑사가 되는 존재가 나의 회사 직원에게 찾아가서 직접 업무 지시를 못하게 하는 것이 나의 일이다. "우리 애 괴롭히지 말고, 저랑 이야기하시죠"라는 존재랄까? 

 

그 현장대리인이 하는 일은 다음과 같다.

 

 

1. 업무 범위 협상

 

고객님이 내 밑에 직원에게 "기존 계약에 없던 범위가 새로 생겼는데 이몽룡 씨 업무랑 연관이 있으니 이몽룡 씨가 해주세요."라고 이몽룡 씨에게 직접 말하지 못하는 게 현장대리인의 일이다. 고객이 그런 짓을 하면 홍길동/이몽룡 씨는 '아, 그건 저희 현장대리인과 이야기해주세요'라고 넘겨야 한다. 그 말을 들었을 때 괘씸해할 고객은 없다. 알겠다고 하고 현장대리인을 부를 거다. '고객이 시키는데 어떻게 거절해요?'라고 개발자들이 묻는다면 간단하다. '그건 그 고객이 할 수 있는 범위 밖이에요.' 이건 회사 대 회사의 관계 그 이상으로 법이 지키는 범위에 있는 것이다.

 

그렇기 때문에 현장대리인은 '업무 범위 협상'이라는 역할이 생긴다. 고객이 어떤 요구를 했을 때 '우리 계약 범위 밖이에요'라고 하면서 밀어내거나 '이건 추가 계약 건이네요'라고 말하거나 '그러면 어떤 업무를 빼주세요'라고 말하든 이 모든 건 현장대리인이 자기 회사를 대표로 말해야 하는 일이다. 턴키 계약은 결국 시스템의 완성을 조건으로 요구하기 때문에 이 모든 것을 수용했다가 완성하지 못하면 누구도 추가 계약을 해서 해결해주지 않기 때문이다. (현장대리인이 수용을 한다면 '계약 범위 안'이 되어버린다.)

 

만약 현장대리인이 모르는 사이에 회사 소속 개발자가 수용을 하는 일이 발생한다면 현장대리인 권한으로 다시 이야기해보는 것은 가능하다. '우리 애가 뭣도 모르고 실수했네요' 하면서 어른이 개입하는 느낌으로 말이다. 물론 그게 너무 늦어지면 안 된다. 개발자가 수용했다는 걸 아는 그 순간에 고객에게 쫓아가서 정식으로 이야기를 해야 한다. 늦으면 수습할 기회가 사라진다. 이때 '선은 니가 넘었어!' 하는 느낌으로 덤비는 것도 좋은 방법이다.(유리잔은 던지지 말고... 드라마 '스토브리그' 참고) 프로세스 위반 같은 느낌으로 살짝 건드리면 고객은 움찔하고 수그릴 것이다.

 

 

2. 근태 관리

 

이 역시 많이들 모르는 일인데, 턴키 계약에는 고객사가 근태를 관리할 권한이 없다. 슈 과장도 근태 관리 빡세게 하는 고객사에서 엄청 많이 일하긴 했지만 (지각했다고 결근 처리해버린다거나 한다. 턴키에는... 결근이 의미가 없거든요?) 이 역시 엄밀히... 고객에게는 그럴 권한이 없다. 그래서 내가 PL인 프로젝트에서는 우리 회사까지는 근태 관리를 꼼꼼히 했고 (아침 9시에 고객이 연락하면 받아야 하니까), 내 아래에 있던 업체는 자유롭게 뒀다. 지각을 하면 '야근하는 날도 있었으니 늦게 올 수도 있죠~'하고 넘겼고, 병원을 가야 하면 '몸이 먼저죠~'하고 보냈고, 휴가를 간다고 하면 '휴가 갈 수 있을 때 얼른 다녀오세요~' 했다. 이렇게 한 이유는 내가 관대하거나 착한 PL이고 싶어서가 아니었다. 나에게 뭐라 할 권한이 없었기 때문이었다. 정해진 기간에 일을 한다는 원칙을 다 갖고 일하는 개발자에게 지각 갖고 뭐라 하는 게 웃기는 일이었다. '일정만 맞추면 뭘 해도 된다'라는 모토로 일했다. 고객보다 법이 더 무서웠다. ^^

 

그래서 업체 직원이 잦은 지각이나 결근을 하는 상황이 발생해서 고객이 그 직원을 불러서 뭐라 한다면 현장대리인은 가서 '제가 챙기겠습니다'라고 말하면서 둘 사이에 벽을 쳐줘야 한다. 고객에게는 그럴 권한이 없으니까. 고객은 그 사람의 지각이나 결근이 프로젝트에 어떠한 영향이 없다면 뭐라 해선 안된다. 하지만 일정관리 측면에서 뭔가 걱정이 되어서 경고를 하고 싶다면 (이건 충분히 걱정이 될 수 있으니까), 이럴 땐 현장대리인을 불러서 이야기할 수 있다. '당신 회사의 직원이 지각이 많고 결근이 발생해서 프로젝트 일정을 지킬 수 있을지 걱정이 됩니다. 상황을 확인해주시고 일정상 문제가 발생할 것 같으면 조치 부탁해요."라고 말이다. 그 이후에 그 인력을 혼내든, 교체하든 그건 현장대리인이 할 일이다.

 

 

3. 산출물, 진척 등 관리

 

내 후배가 곤란해했던 부분이 진척 관리였는데, 진척을 확인하기 위해 개발자에게 일일이 찾아가서 진척이 어느 정도였는지 묻고 답을 구했다는 것이었다. 그때 그 개발자는 '이 부분은 제 역할이 아닌데요?'라고 대답했고, 당황했던 내 후배는 그걸 챙기기 위해 동분서주했다는 것이다. 

 

이럴 때는 그 회사의 현장대리인을 부르면 된다. '주간보고를 위한 진척을 확인하고 있습니다. 목요일 5시까지 진척률 회신 부탁드려요." 그러면 일 끝이다. 그 현장대리인이 자기 개발자들 찾아가서 숫자를 받아오면 되는 것이다. 그 개발자가 자기 일이 아니라고 하면, 그 회사 안에서 누가 그 개발을 할지 그 현장대리인이 결정하면 된다. 고객은 그 문제까지 관여할 필요는 없는 것이다. 일을 맡겼으면, 믿고 맡겨야 하는 것이다.

 

그래서 현장대리인에게는 산출물, 진척 관리 역할이 생긴다. 자기가 소속된 회사에서 계약한 내용에 대해 제대로 이행하고 있는지 확인하고 그 결과물을 잘 챙기는 역할이 있다는 뜻이다. 어디까지나 계약된 범위까지 관리하는 것이 그 역할이다. 만약 내 후배 같은 사람(갑)이 와서 자기 회사 개발자에게 '진척률을 알려달라, (너의 역할이 아니라고?) 그러면 회의를 하자'라고 말하고 있다면 얼른 인터셉트해서 '우리 쪽 진척률은 제가 챙겨서 드리겠습니다'라고 말하고 돌려보내야 한다.

---

SI 일을 하면서 가장 안타까웠던 것은 이런 거였다. '계약'에 대한 내용을 하나도 모르고 프로젝트에 끌려들어 와서는 자기를 용역업체 직원처럼 부려먹는 사람들에게 호되게 당하다가 일정 끝나면 번아웃되어서 프로젝트 철수하는 개발자들을 보는 것... 사원/대리 시절 계약서도 보지 못하고 투입되었을 때 내 기분은 분노와 참담함 그 둘을 왔다 갔다 했던 것 같다. '내가 어디까지 해야 하는 거지?', '우린 무슨 계약을 한 거지?', '이 일도 계약에 포함되어있나?' 이런 궁금증을 해소하지 못해서 답답해하기도 했다.

 

그래서 나에게 업무 범위, 계약 범위가 쥐어졌을 때 제일 먼저 한 것은 1) 내가 그 내용을 다 숙지하고, 2) 현장대리인이 지정되면 그 업체 직원 앉혀놓고 교육시킨 것이다.

 

"당신 회사가 하기로 계약한 일이 뭔지 모르죠? 여기서부터 여기까지예요. 당신이 이걸 관리해야 하는 현장대리인이에요. 우린 당신 하고만 이야기할 수 있고, 우린 당신 회사의 개발자에게 업무를 지시할 권한이 없어요. 당신이 다 배정해줘야 해요. 우리에겐 당신 회사의 근태 권리를 할 권한이 없어요. 되도록이면 고객사 업무 시간에 맞춰서 일해주면 고맙겠지만 본사에 일이 있거나, 개인적으로 휴가를 내야 하는 일이 발생하면 당신이 관리하시면 돼요. 우리에게는 공유 정도 해주시면 감사하겠습니다. 혹시나 우리가 급한 마음에 범위 밖의 일을 요구하거나 개발자에게 직접 업무를 지시하는 일이 발생할 수 있는데 그게 범위 밖이거나 수용할 수 없는 범위면 이야기를 해주세요. 그걸 할 수 있는 게 현장대리인이에요. 알겠죠?"

 

그와 동시에 고객이 이에 대해 얼마나 감이 있는지를 확인했다. 그리고 중간중간에 선을 넘는 말을 하거나 의사를 내비치면 내 선에서 우선 겁을 줬다. "아, 저도 그렇고 싶은데, 그렇게 하면 하도급법 위반이라고 회사에서 귀 아프게 교육을 받아서요... 현장대리인에게 사정은 해보겠습니다."라는 식으로 말이다. '너 이러면 위반이야!'라고 말하는 게 아니라 '너의 마음 잘 알지, 나도 그런 마음이야. 하지만 직접 지시하면 위반이니까... 잘 부탁해서 해결해보자'라는 식으로 말이다. 처음에 이런 이야기가 나오면 보통 그 범위는 업체에서 수용하게 되는데 (프로젝트 초기에 나오기도 하고, 처음 하는 부탁이니까), 한번 이런 식으로 법을 들이밀며 겁주면 이런 요구가 점점 줄어들게 된다.

---

현장대리인은, 업체 직원들을 만나보면 흔히들 벌칙이라고 생각한다. '개발자인데... 왜 현장대리인까지 해야 하죠?'라고 말이다. 그것도 그럴 것이, 현장대리인의 존재를 무시하고 일을 마구 시키는 플젝 뛰다가 '현장대리인'의 역할을 충실히 존중하고 시키는 나를 만나면 벌칙같이 느껴지는 것이다. 자기 파트도 아닌데 회의 참석해야 하고, 업무 범위도 확인해야 하고, 진척률도 확인해야 하고... 개발자는 대부분 관리업무가 추가되면 벌칙이라 생각한다.(ㅋㅋㅋ)

 

확실히 현장대리인은 힘든 일이다. 그 회사의 PM이나 마찬가지니까. 하지만, 현장대리인은 개발자로 하여금 조금이나마 더 주체권을 주는 역할이라 생각한다. 어떻게 할지, 누가 할지, 언제 할지 등을 결정할 수 있다. 고객사가 업무 협의를 하자고 불렀을 때 그 업무를 수용할지 'Yes/No'를 결정할 권한도 생긴다. 그게 골치가 아플 수도 있지만, 나와 이해관계가 다른 현장대리인 또는 고객이 일을 미친 듯이 몰아줄 때 거절할 기회가 없을 때의 분노를 느껴본 적이 있다면 그럴 기회가 있는 현장대리인이 좋을 수도 있다. 특히 업무를 모르는 현장대리인을 모신다면 아~~ 주 골치가 아프니 말이다.

 

그러니 혹시나 현장대리인을 하게 된다면, 주도적/주체적으로 일할 기회가 생겼다고 생각하자. 개발만 하느라 들어가 보지 않은 회의를 들어가 보자. 다른 사람들은 어떻게 말하는지, 협상을 어떻게 하는지도 잘 듣고 배워보자. 그리고 나의 역할에 따른 책임만 생각하지 말고 그에 따른 권리/권한이 무엇인지도 관심 있게 알아보도록 하자. 보람 있는 일일 것이다.

 

참고로 예전에 현장대리인이 처음이라는 개발자에게 그의 역할/권한이 무엇인지 가르쳐줬었는데, 그분이 얼마 전에 우리 회사에 지원해서 입사하셨다. 우리 회사의 다른 팀으로 입사하셨는데 면접 때 "그 프로젝트에서 만난 PM/PL님처럼 좋은 PM/PL이 되는 게 제 커리어의 목표입니다"라고 말하셨다고 한다. 뿌듯했다. 훌륭한 현장대리인님, 어서 와요!!

 

2022.05.29 22:38