K가 구매업무를 본격적으로 시작했다고 한다. 개발구매를 맡게 될지도 모른다는 소식이 주변에서 들려온다. 개발 구매가 어렵다는 애기를 주변에서 들어서인지 걱정이 한가득이라고 한다. 나 역시 신입을 곧바로 개발구매를 맡긴다는 게 다소 의아스럽긴 하다. 그래도 조직이 한 다면 하는 거지. 신입은 개발구매를 하지 말라는 법은 없는 거니까?    

개발구매는 말 그대로 연구 또는 개발용 자재를 구입하는 업무다. 개발 자재란 신규 제품 개발 및 연구에 소요되는 자재를 말한다. 따라서 양산 제품 생산에 투입되는 자재와 성격이 많이 다르다. 우선 자재가 다품종 소량이다. 새롭게 개발하는 다양한 품목에 소요되는 관계로 많이도 구매하지 않는다. 그래서 조금씩 사서 사용한다. 양산의 경우, 이미 확정된 자재 리스트(BOM이라고 한다)가 있고 구매 물량이 많은 것과는 딴 판이다. 구입 수량이 적으면 생각보다 구매가 쉽지 않다. 최소주문량(MOQ : Minimum Order Quality)이 있기 때문이다. 공급업체에서 납품할 수 있는 수량의 마지노선이다. 이를 좀 더 자세히 풀어보면 구매 수량이 공급업체의 포장이나 생산의 기본 단위보다 적으면, 운송비나 기타 비용을 따졌을 때 손해이기 때문에 그 이하로는 공급하지 않는 기준 수량이다. 예를 들어 구매담당자가 개발 자재로 3개만 필요해도 공급업체의 MOQ가 10개면 10개를 구매해야 한다. 나머지 7개는 쓸모가 없다. 또한 개발 자재는 구매자재에 대한 명확한 스펙이나 규격도 없다. 그래서 구매 요청자도 힘들고 구매담당자도 버겁다. 구매업무에서도 개발구매는 상당히 고급 직무에 속한다. 그만큼 어렵고 난이도도 높다. 주로 연구개발(R&D) 위주의 개발팀이나 연구소 조직에서 많이 접할 수 있다.   

“아니, 연구원님. 제작품에 대한 정확한 규격을 주셔야지, 이렇게 달랑 형상 스케치만 보내면 어떡합니까?”

“저도 확정된 규격 드리고 싶어요. 하지만 아직 확실한 스펙이 정해진 게 없어서 그래요?”

“그렇게 말씀하시면 저희 구매는 뭘 기준으로 구매를 합니까? 이러면 구매 못합니다.”

“그래서 제가 계속 말씀드리잖아요. 정 힘드시면 먼저 업체를 지정해 달라, 그러면 우리가 얘기를 해 보겠다고 말입니다.”

“그게, 말이 안 되는 게.. 지금 요청하신 스케치 형상 가지고 견적을 낼 수 있는 업체가 어디 있어요. 없어요? 연구원님이 추천하신 업체 말고는..”

“어? 그래요. 그러면 뭐, 그 업체 하고라도 해야지요.”

“그리고 이렇게 빠듯하게 납기를 잡는 경우가 어디 있습니까? 아무리 개발 자재라지만 이건 너무한 것 아닌가요?”

“최대리 님, 저희도 힘들어요. 개발 일정이 넉넉한 것도 아니고, 고객 요구사항은 매번 바뀌지.. 이번 건도 마찬가지예요. 고객이 날짜를 갑자기 앞당겨서 그래요.”

“아무리 그래도 이건 아니지요. 그냥 연구원님이 추천한 업체에서 물건 사서 그냥 구매는 서류 처리만 하라는 거 아닙니까?”

“아니, 무슨 말씀을 그렇게 하십니까? 내가 뭐 개인적으로 필요해서 요구한 것도 아니고, 다 회사 일 좀 잘해보자고, 업체하고 먼저 애기 좀 한 것뿐 이에요.”

“누구는 회사 일 안 합니까? 저희도 회사 일 합니다. 중요한 것은 규정과 절차에 따라야 한다는 거죠. 추천업체도 그래요. 아무 업체하고 사전에 막 애기해도 되는 거예요. 아예 연구원님이 구매를 직접 하세요.”

“그놈의 규정과 절차 때문에 아무 일도 못해 먹겠네. 이거 뭐 치구 하나 구매하기가 이렇게 어려워서야..”

“반려할 테니까요. 다시 검토해서 구매요청서 수정해서 보내주세요.”    

구매담당자와 개발자인 연구원이 부딪치는 사례는 흔하게 볼 수 있다. 각자의 입장이 서로 다르기 때문이다. 당연하다. 개발자는 구매 규정과 절차보다 기간 내 개발을 끝마치는 것과 고객의 요구사항이 먼저다. 하지만 구매는 다르다. 개발자의 그런 마인드를 인정하게 되면 구매업무는 진짜로 힘들어진다. 그렇지 않아도 여기저기 시비 거는 적들(?)과 싸우기도 힘이 벅차다. 우선 회사에 어디 개발자가 한 두 명인가? 그들 모두는 자기가 맡고 있는 개발 프로젝트가 제일 중요하다고 생각한다. 그리고 각자가 나름의 기막힌 사연들을 구구절절이 가지고 있다. 가장 흔한 게 개발 일정의 준수와 고객의 요구사항이다. 이 둘은 거의 만병통치약 수준이다. 때로는 개발자가 구매담당자에게 당당하게 협박(?)도 한다. 개발 일정이 늦어지면 구매팀에서 다 책임지라고. 이런 상황에서 한 명의 개발자에게라도 규정과 절차를 느슨하게 적용한다면, 구매의 기준은 무너지고 각종 문서처리와 배달업무만 남게 된다. 그럴 바에야 차라리 개발자가 직접 구매를 하는 게 낫다. 그럼에도 회사에서 물건을 살 때 반드시 구매를 통하라는 이유가 무엇인가? 구매 절차의 통일성과 구매권의 남용 방지를 위해서다. 개발자가 직접 구매권을 행사하게 된다면 각자의 성향에 따라 수많은 구매 절차가 생겨날 것이다. 또한 견제받지 않는 구매권한은 불필요한 오해와 함께 개발자가 연구업무 본연에 집중하지 못하게 할 것이다. 그래서 전문가로 구성된 전담조직으로 구매팀을 별도로 둔 것이다.    

개발자와 구매담당자 사이의 본질적인 간격을 어떻게 메꿀 것인가? 심할 경우, 구매절차가 너무 힘들다는 핑계로 회사를 그만두는 연구원도 가끔 있다. 이처럼 개발업무의 특성상 구매절차의 과감한 축소(?)를 주장하는 개발자의 요구와, 구매절차의 예외란 곧 회사 불이익임을 강조하는 구매담당자 인식의 충돌을 피할 수 있는 방법은 없을까? 없다. 실제로 그렇다. 다만 줄일 수 있는 방법은 있다. 개발자가 임의로 업체를 접촉하지 말고 구매담당자에게 먼저 물어보는 것이다. 개발업무를 하다 보면 신규 자재가 수시로 필요하게 되는데, 이때 개발자가 구매팀과 상의 없이 업체와 연락하는 경우가 적지 않다. 구매 규정과 절차를 뛰어넘는 것이다. 설상가상으로 그 업체가 회사의 거래 이력이 없는 신규 업체이면 일은 더욱 꼬인다. 개발자 입장에서는 당장 필요한 자재만 눈에 들어온다. 내가 원하는 자재만 공급해줄 수 있는 업체라면 만사 오케이다. 업체가 부실하거나 거래조건 등은 생각하지 않는다. 즉 업체의 적정성 여부에 대한 검토가 이루어지지 않는 것이다. 이 경우 뒷수습은 고스란히 구매담당자 몫이다. 회사 입장에서도 검증되지 않는 업체 리스크를 떠안고 가는 셈이다. 그래서 업체 선정은 구매담당자에게 맡길 필요가 있다. 모든 갈등의 시작이 여기서부터 출발하기 때문이다.    

카멜 작가님의 더 많은 글 '보러가기'