화장품 OEM/ODM 개발 프로세스를 시스템으로 만든다는 것

산업 이야기1

들어가며

지금까지 이 블로그에서는 R&D 관리에 대한 일반론을 다뤘습니다. Project란 무엇인지, R&D Project는 왜 다른지, 국내 기업의 관리체계는 어떤 배경에서 만들어졌는지.

오늘은 한 산업 안으로 들어가 보려고 합니다. 화장품 OEM/ODM입니다.

이 영역을 고른 이유가 있습니다. 앞서 저희는 "수주형 프로젝트와 R&D 프로젝트는 성격이 다르다"고 말씀드렸습니다. 그런데 화장품 OEM/ODM 개발은 그 두 가지가 한 프로젝트 안에 섞여 있는 흔치 않은 영역입니다. 그래서 시스템으로 만들기가 유독 까다롭고, 반대로 잘 만들면 효과가 큽니다.

1. 이 산업의 개발이 특별한 이유

일반적인 기업 R&D는 자사 전략에서 출발합니다. 우리가 어떤 제품을 만들 것인지 스스로 정하고, 그에 맞춰 연구를 시작합니다.

OEM/ODM은 다릅니다. 고객사의 의뢰에서 출발합니다.

이 한 가지 차이가 모든 것을 바꿉니다.

지난 글에서 저희는 프로젝트를 두 종류로 나눴습니다. 계약 조건이 명확한 수주형 프로젝트는 QCD(품질·원가·납기)로 관리하고, R&D 프로젝트는 Outcome으로 관리한다고요.

화장품 OEM/ODM 개발은 이 둘이 겹쳐 있습니다.

납기는 수주형처럼 관리해야 하는데, 처방 개발은 R&D처럼 불확실합니다. 그런데 이 둘의 관리 방식은 정반대입니다. 하나는 계획을 지키는 것이 미덕이고, 다른 하나는 계획이 바뀌는 것이 정상입니다.

개발관리 시스템이 어려운 이유가 여기 있습니다. 어느 한쪽 논리로만 만들면 반드시 다른 쪽이 어긋납니다.

2. 의뢰 시점의 정보는 언제나 불완전합니다

고객사가 처음 가져오는 것은 대개 컨셉과 대략의 방향입니다. 어떤 느낌의 제품을 원하는지, 타깃은 누구인지, 예상 단가는 어느 정도인지. 확정되지 않은 것이 훨씬 많습니다. 정확한 사양, 최종 용량, 용기, 출시 국가, 수량. 이런 것들은 개발이 진행되면서 하나씩 정해집니다. 때로는 개발이 거의 끝나갈 무렵에 정해지기도 합니다.

여기서 시스템 설계의 첫 번째 난관이 나옵니다.

많은 시스템이 이 지점에서 무너집니다. 등록 화면에 필수 입력 항목을 잔뜩 만들어 두면, 담당자는 아직 모르는 값을 임의로 채워 넣습니다. 나중에 실제 값이 정해져도 그 임시값이 그대로 남습니다. 그러면 시스템의 데이터를 아무도 믿지 않게 됩니다.

반대로 필수 항목을 최소화하면 등록은 쉬워지지만, 정작 필요할 때 정보가 없습니다.

저희가 이 문제를 다루는 관점은 이렇습니다.

항목의 개수가 아니라 정보의 상태를 관리해야 합니다. 같은 항목이라도 "아직 미정", "고객사 협의 중", "확정" 상태가 구분되어야 하고, 확정 시점이 기록되어야 합니다. 그래야 나중에 "그때 왜 이렇게 갔는지"를 되짚을 수 있습니다.

이것은 화장품만의 이야기가 아닙니다. 앞서 다룬 "착수 시점에 계획을 확정할 수 없다"는 R&D의 속성이 여기서도 그대로 나타나는 것입니다.

3. 처방은 왜 관리하기 어려운가

개발관리에서 가장 까다로운 대상이 처방입니다. 이유는 처방이 하나의 문서가 아니기 때문입니다.

기본 처방이 있고, 거기서 원료 하나를 바꾼 변형이 있고, 시험 회차마다 조정된 버전이 쌓입니다. 하나의 제품 개발에서 수십 개의 처방이 만들어지는 일이 드물지 않습니다.

이것을 파일로 관리하면 어떤 일이 생기는지는 다들 아실 겁니다. 제품명_최종.xlsx, 제품명_최종_수정.xlsx, 제품명_최종_진짜최종.xlsx.

시스템으로 만들 때 반드시 담아야 하는 것이 두 가지입니다.

첫째, 계보입니다. 이 처방이 어느 처방에서 갈라져 나왔는지, 무엇을 바꿔서 만든 것인지가 연결되어 있어야 합니다. 이게 없으면 6개월 뒤에 "왜 이 원료를 뺐더라"에 아무도 답하지 못합니다.

둘째, 역방향 추적입니다. 원료 하나에 문제가 생겼을 때 — 공급 중단이든, 규제 변경이든, 단가 인상이든 — 그 원료가 들어간 처방이 몇 개이고 어떤 제품에 걸려 있는지를 바로 알 수 있어야 합니다.

두 번째가 특히 중요합니다. 원료 이슈는 예고 없이 옵니다. 그때 파일을 하나씩 열어보고 있으면 이미 늦습니다.

4. 규제는 개발이 끝난 뒤가 아니라 개발 중에 확인되어야 합니다

화장품은 규제 산업입니다. 배합 한도가 정해진 원료가 있고, 아예 쓸 수 없는 원료가 있고, 전성분을 표시해야 하며, 이 기준이 나라마다 다릅니다. 여기서 흔히 벌어지는 일이 있습니다. 처방을 다 완성하고 나서 규제 검토를 하는 것입니다.

그러면 걸립니다. 수출국 기준에 맞지 않는 원료가 들어가 있거나, 한도를 넘겼거나. 그리고 처음부터 다시 시작합니다. 개발 기간이 늘어나고, 납기가 흔들리고, 원가가 올라갑니다.

규제 검토는 별도의 단계가 아니라 개발 과정에 녹아 있어야 합니다.

처방에 원료를 넣는 순간, 그 원료가 대상 국가에서 사용 가능한지, 한도는 얼마인지가 즉시 확인되어야 합니다. 사람이 매번 기준을 찾아보는 방식으로는 지속되지 않습니다. 바쁘면 건너뛰게 되고, 건너뛴 것이 나중에 사고가 됩니다.

이것을 시스템으로 만들려면 원료 마스터에 규제 정보가 함께 관리되어야 하고, 그 정보가 계속 갱신되어야 합니다. 규제는 바뀌기 때문입니다. 그래서 이 영역은 한 번 구축하고 끝나는 것이 아니라, 계속 손봐야 하는 영역입니다.

5. 개발과 생산 사이의 끊김

개발이 끝나면 생산으로 넘어갑니다. 그런데 많은 회사에서 이 지점이 끊겨 있습니다.

개발에서 만든 처방을 생산 시스템에 다시 입력합니다. 사람이 옮겨 적습니다. 여기서 오기가 나고, 버전이 어긋나고, "개발이 준 건 이게 아닌데"가 시작됩니다.

왜 이런 일이 생기느냐면, 개발 시스템과 생산 시스템이 서로 다른 전제 위에 있기 때문입니다.

여기서 앞서 던진 질문에 답할 수 있습니다. "ERP로는 왜 안 되는가."

ERP와 MES는 확정된 것을 처리하는 시스템입니다. 확정된 BOM, 확정된 수량, 확정된 공정. 이 영역에서 이 시스템들은 대단히 훌륭합니다.

하지만 개발은 확정되기 전 단계입니다. 처방이 아직 흔들리고, 사양이 아직 안 정해졌고, 몇 번 더 돌지 모릅니다. 이걸 ERP에 넣으려면 확정된 척을 해야 하는데, 그러면 실제 개발 상황과 어긋납니다.

그래서 필요한 것이 개발 영역을 담는 별도의 관리 체계이고, 그것이 확정되는 순간 생산 쪽으로 넘어가는 접점입니다. 두 시스템을 하나로 합치는 것이 아니라, 경계를 명확히 하고 그 경계에서 데이터가 흐르게 만드는 것입니다.

이 경계를 어디에 둘 것인가가 이 산업 시스템 설계의 핵심 판단 중 하나입니다.

6. 사람이 나가면, 무엇이 같이 나가는가

마지막으로 가장 중요한 이야기를 하겠습니다.

현장의 관리자분들과 이야기를 나눠 보면, 가장 자주 나오는 걱정이 하나 있습니다. 시스템이나 예산 이야기가 아닙니다.

화장품 개발은 개인의 노하우 의존도가 유독 높은 영역입니다. 어떤 원료끼리 안 맞는지, 이 제형에서 점도를 잡으려면 어디를 건드려야 하는지, 이 고객사는 어떤 컨셉을 좋아하고 어느 지점에서 까다로운지. 문서 어디에도 안 적혀 있고, 그 사람 머릿속에만 있습니다.

그리고 연구원은 이동합니다. 이직하기도 하고, 팀을 옮기기도 하고, 다른 프로젝트로 빠지기도 합니다. 관리자 입장에서는 사람 한 명이 아니라 몇 년치 개발 경험이 통째로 나가는 것입니다.

남은 사람은 처음부터 다시 시작합니다. 3년 전에 비슷한 제품을 개발하면서 이미 겪었던 문제를, 이미 시도해 보고 접었던 대안을, 다시 시도합니다. 그리고 같은 결론에 도달합니다. 회사는 같은 수업료를 두 번 냅니다.

시스템이 할 수 있는 것과 할 수 없는 것

여기서 정직하게 말씀드릴 부분이 있습니다.

시스템이 그 사람의 감각까지 옮겨 담지는 못합니다. 20년 경력자의 손끝 판단, 제형을 보는 눈, 고객사와의 관계. 이런 것을 시스템에 넣을 수 있다고 말하면 거짓말입니다.

시스템이 할 수 있는 것은 다른 쪽입니다.

• 이 제품을 개발하면서 어떤 처방들을 시도했는지
• 그중 무엇을 접었고, 왜 접었는지
• 안정성이나 관능에서 어떤 문제가 있었는지
• 고객사와 무엇을 협의했고 어떻게 정리됐는지
• 규제나 원료 이슈로 어떤 제약이 있었는지

이것들은 감각이 아니라 사실과 판단의 기록입니다. 그리고 이건 시스템에 담을 수 있습니다.

저희는 이것을 "천장을 씌우는 게 아니라 바닥을 까는 일"이라고 표현합니다. 시스템이 뛰어난 연구원을 만들어 주지는 않습니다. 다만 새로 맡은 사람이 회사가 이미 아는 것 아래로 떨어지지 않게 받쳐줍니다.

관리자 입장에서 달라지는 것은 이렇습니다. 인수인계할 때 선배를 며칠씩 붙잡고 있어야 했던 것이, 이력을 열어보고 몇 시간 안에 흐름을 파악하는 것으로 바뀝니다. 그 선배가 이미 퇴사했더라도요.

그리고 이건 별도 업무가 되면 안 됩니다

한 가지 조건이 있습니다.

이 기록이 "따로 정리해서 남기세요"가 되는 순간 실패합니다. 아무도 안 합니다. 바쁘고, 당장 급한 일이 아니고, 남겨서 본인에게 돌아오는 이득이 없기 때문입니다.

업무를 하는 과정에서 자연스럽게 남아야 합니다. 처방을 등록하면 계보가 남고, 시험 결과를 입력하면 판단 근거가 되고, 고객사 협의 내용을 그 자리에 적으면 이력이 되는 구조. 기록이 목적이 아니라 업무의 부산물이어야 합니다.

앞선 글에서 저희는 R&D 관리의 핵심이 "판단을 기록하는 것"이라고 말씀드렸습니다. OEM/ODM 개발에서는 이것이 특히 직접적인 경쟁력이 됩니다. 같은 실패를 반복하지 않는 것만으로 개발 기간이 줄어들기 때문입니다.

정리하며

화장품 OEM/ODM 개발관리를 시스템으로 만들 때 부딪히는 것들을 정리하면 이렇습니다.

• 수주형과 R&D의 성격이 섞여 있어, 한쪽 논리로만 만들면 어긋납니다
• 의뢰 시점의 정보가 불완전하므로, 항목이 아니라 상태를 관리해야 합니다
• 처방은 계보와 역방향 추적이 되어야 합니다
• 규제 검토는 개발이 끝난 뒤가 아니라 개발 중에 확인되어야 합니다
• 개발과 생산의 경계를 명확히 하고, 그 경계에서 데이터가 흘러야 합니다
• 사람이 나가도 그 사람이 내린 판단은 회사에 남아야 합니다. 감각은 옮길 수 없지만, 시도와 실패와 협의의 기록은 옮길 수 있습니다

저희는 이 영역에서 오랫동안 시스템을 만들어 왔습니다. 화장품 OEM/ODM의 개발 전 과정을 관리하는 Cosmetic PLM, 처방 관리와 규제 대응에 특화된 F-ELN, 원료 유통을 다루는 CosFlow가 각각 위의 문제들에 대응합니다. 국내는 물론 해외 법인까지 하나의 체계로 운영되는 사례도 만들어 왔습니다. 구체적인 이야기가 필요하시면 언제든 연락 주십시오.