DRBFM 방법론 - 특징, 적용, 의견

DRBFM(Design Review Based on Failure Mode)은 제품이나 프로세스의 설계 단계에서 진행되며, 

설계 단계에서 발생할 수 있는 잠재적인 문제점을 분석하고 분석된 문제점을 사전에 예방하기 위한 방법론입니다.

린(Lean) 방법론과 마찮가지로 Toyota 에서 시작되었습니다. 

 

개인적으로, 이 글을 접하는 모든 분들께 꼭 추천드리는 방법론입니다. 

[목차]

• 특징
• 적용 방법
• 의견

특징

다른 방법론과 조금 다른 것은 이 방법론은 제품의 오류를 최소화하고, 제품의 안정성을 향상시키는데 중점을 둔다는 것입니다. 

자동차라는 특수성이 있어서 더 부각되는 것 같습니다. 

• Design Review 
  • 설계 단계에서의 리뷰를 말하며, 제품이나 프로세스의 설계 과정에서 잠재적인 문제를 식별하고 검토합니다. 
• Failure Mode 
  • 제품이나 프로세스의 결함이나 실패 경우를 이해하고 문제점을 파악합니다. 
• Based on 
  • 기존의 데이터나 과거 경험, 품질 도구 등을 기반으로 결함을 예방하고 개선합니다.
• Prevention
  • 문제 발생을 예방하는 데 집중하며, 설계 단계에서의 문제 예방 조치를 통해 잠재적인 문제를 최소화합니다. 

적용 방법

1. Failure Mode 정의 
   • 설계 단계에서 발생할 수 있는 잠재적인 실패 모드를 식별합니다. 
   • 제품이나, 시스템이 어떻게 실패할 수 있는지에 대한 가능성을 고려합니다. 
2. 원인 분석 
   • Failure Mode 가 발생하는 원인을 분석합니다. 
   • 실패의 근본적인 이유를 찾는게 핵심입니다. 
3. 예방책 도출 
   • Failure Mode를 방지하기 위한 대응책을 도출합니다. 
   • 도출된 대응책 또는 예방 방법을 찾아 설계에 반영합니다. 
4. 검토 및 확인 
   • 도출된 대응책이나, 예방 방법을 동료들과 리뷰합니다. 
   • 설계에 반영된 부분을 다시 동료들과 리뷰하고 제품에 반영하여 효과를 모니터링합니다.
5. 문서화와 공유
   • 전체 과정에서 도출된 내용을 문서화하고, 이를 조직원들과 공유합니다. 
   • 유사한 문제 상황에서의 경험을 공유하여, 다른 프로젝트에서 활용 될 수 있도록 합니다.

의견

DRBFM을 진행하기 위해서는 필수적으로 설계 문서가 준비되어야 합니다. 하지만 현실적으로 많은 개발 회사에서는 설계 단계를 충분히 거치지 않거나, 임시로 만들거나 아예 생략하는 경우가 많습니다. 이로 인해 DRBFM을 실행하기 어려운 상황이 현실입니다.

설계를 철저히 수행하는 조직이라면 DRBFM을 진행하는 것이 부담스럽지 않을 것입니다. 그러나 설계가 충분하지 않은 조직은 이를 수행하기 어려울 수 있습니다. 따라서 최근에 제가 경험한 내용을 공유드리겠습니다.  ( 너무 아쉬워서요. )

설계 문서가 없더라도 현재의 제품 또는 서비스를 기반으로 상황을 살펴보면, 개선할 수 있는 부분을 발견하는 것이 가능합니다.

• 네트워크 오류 팝업이 노출되고 이후로 동작이 되지 않는다. 
  • 원인 ) 일시적인 네트워크 접속 오류 ( 서버에 인입된 Request 도 없음 , 클라이언트 통신 실패 ) 
  • 개선 ) API 호출에 Retry 정책을 고려 ( e.g - 3번 200ms 간격으로 성공때까지 호출 ) 
• 고객의 입력 절차가 계속 반복적으로 이뤄진다. 
  • 원인 ) 입력된 데이터를 업로드하는 API 에서 데이터 오류 발생 
  • 개선 ) 서버와 클라이언트 간의 API 버전 규격을 정하고 버전이 맞지 않는 경우 서비스 및 프로덕트의 버전 업데이트를 유도

간단히 예를 들었습니다. 

DRBFM의 이론적인 부분부터 접근하면, 조직원들이 너무 어려워하기 때문에 조금은 어설프지만, 중요한 핵심만 살려서 진행해도 너무 좋은 방법론입니다. 

제가 생각하기에 제일 중요한 부분은 실패 상황에 대한 가정입니다. 

 

물론, 모두 개발을 너무 잘 하시기 때문에 문제 없는 코드를 작성하셨으리라 생각됩니다.

다만, 고객의 입장에서 불편함은 언제나 생기고 있습니다. 그 이유는 너무나 많습니다. 

보통 우리는 고객에게 불편함이 발생된 이후에 대응하는 방법을 택하게 됩니다, 그러니 매일 매일이 시급성을 다투는 문제 해결로 시간을 모두 쓰고, 정작 중요한 기능 개발에는 시간이 부족함을 느끼는 것일 테죠. 

 

경험이 충만한 개발자는 어느 정도 경험을 바탕으로 모든 상황을 충분히 고려하여 코드를 작성하겠지만, 그렇지 않은 개발자는 어떻게 할까요? 

코드리뷰만으로 충분할까요? 

정말 필요한 문서는 이러한 문서라고 생각합니다. 공유되어야하고, 활용되어야만 합니다.