Review는 정말 중요한데 왜 안하는 걸까?


프로세스 개선 사례를 보면 비용대비 가장 효율적인 검증 활동은 Review라고 한다. 그런데 주변을 둘러보면 제대로 review를 하고 있는 곳을 보질 못했다. ISO 26262뿐만 아니라 DO-178C나 DO-278A같은 다른 개발 표준에서도 review를 상당히 중요하게 생각한다.

왜 현업에서는 review를 안하는 것일까?

1. 쓸데 없어 보인다. 

최근에 워낙 모델링, 분석 및 검증 도구가 강력한 것이 있어서 그것만 있으면 만능이라고 생각하고 CASE TOOL만능주의에 빠져서 그런지 review활동을 많이 무시한다. 코드 리뷰 같은 경우에도 그렇다. 대부분 MISRA-C:2004 혹은 MISRA-C:2012를 기반으로 하여 툴을 돌리고 나온 결과를 검토한다. 그러면 다 된 것으로 생각한다.

정말 그런가?

사람들은 인간이 하는 활동는 오류가 많이 개입될 수 밖에 없다고 생각하고 그렇기 때문에 도구의 힘을 빌리려고 하고 보다 형식화시키고 정형화 시키려고 한다. 그런데 그런 형식화와 정형화는 만능은 아니다. 어느 특정 영역에서는 도움이 되고 유용하기는 하다. 하지만 그것이 전부는 아니다. 형식화시키기 어려운 것들이 존재하기 때문이다. 그 부분에 있어서 형식화를 시키려고 시도하는 것이 형식주의자들의 목표이겠지만 일반인이 적용하기에는 쉬운 문제는 아니다.

MISRA표준이 나오게 된 것도 많은 경험자들이 과거의 실패사례와 경험을 집대성하여 나온 결과물들이고 툴이 나오기 전에는 코드를 하나하나 읽어가면서 점검을 했을 것이다. 지금이야 코드를 읽으면서 그런 규칙을 위반했는지를 검사할 필요는 없겠지만..

검토의 대상이 코드에 대한 것만 있는 것은 아니다. 요구사항도 검토 대상이고, 설계도 검토대상이고 모든 개발 산출물이 검토 대상이다. 그런데 동료에 대한 믿음이 강해서(?)인지 검토를 잘 하지 않는다.

믿지 않겠지만 cost대비 가장 효과적인 검증 활동이 review이다. 이런 얘기하는 나에게 야유를 보낸다. 진짜라니까? 책에서 그렇게 얘기했어..라고 얘기해봤자 현실을 모른다는 말만…

설계를 하고 설계검토를 생략한채 테스트를 해서 버그를 찾는 경우, 그 오류를 수정하기 위해서는 코드를 수정해야 하고, 수정된 코드의 재시험(단위, 통합, 최종)을 수행해야 한다. 설계 검토에서 오류 발견되었으면 그런 삽질 안해도 되는데..

필드나가기 전에 시험은 왜 하는 목적을 생각해본다면 구현하기 전에 설계 검토를 왜 하는지를 이해할 수 있을거라고 생각하는데, 모든 사람이 동의하는 것 같지는 않다.  인식의 전환이 매우 중요하다.

2. 바쁘다.

프로세스 개선하는 업무에서 검토하는 것이 좋다고 얘기했을때, 즉각적인 현업 담당자의 반응은 이랬다.

“할일이 엄청 많은데 검토 할 시간이 어딨냐? 현실을 너무 모르시네.”

그렇다. 바빠죽겠는데 무슨 얼어죽을 검토냐.. 검토할 시간에 다른거 하나 더 하는 것이 개인에게는 더 유리할 것이다. 누가 알아주지도 않는 검토따위 해서 뭐하랴? 사전에 문제를 예방한다고 누가 상을 준다더냐? 사고 터지고 수습하는 한이 있어도 예방은 하지 않으리라…

어찌보면 회사의 문화가 예방을 중시하는 문화인지 아닌지의 여부에 따라 달라질 수 있는 부분이다.

바쁘지 않아도 프로세스를 지켜서 하라는 것이 정말 짜증나는 일이 될텐데(왜냐면 각 개인별로 습관화된 업무 방식과 맞지 않으므로) 바쁘면 그게 지켜지겠나?

그런데 보통 회사에서는 바쁜데도 불구하고 프로세스를 지켜서 일을 하라고 하기는 한다. 그래서 잘 되는가? 일부는 잘 하기도 하지만 보통 그렇게 하는 척을 한다. 그래서 검토는 흉내를 내게 된다.

3. 어떻게 하는지 모르겠다.

검토에도 교육이 필요하다. 산출물을 검토하는 것을 가이드할 수 있는 체크리스트 같은 것들이 필요하다. 보통 체크리스트 하면 상당히 애매하고 모호하고 적용하기 어려운 체크리스트를 떠올리는 사람들도 꽤 있는 것 같다. 그래서 희한한 체크항목으로 검토했다고 show를 하는 곳을 많이 봤다.

체크리스트는 두가지 관점에서 만들어야 한다. 하나는 형식적 요소이다. 형식적 요소를 추출하기 위해서는 산출물의 템플릿이 있어야 한다. 템플릿으로부터 다음의 형식적 요소를 뽑아낼 수 있다.

1. 작성자가 기술되었는가?

2. 문서의 버전이 기술되었는가?

3. 문서의 개요가 기술되었는가?

다른 관점은 기술적 관점인데, 이는 개발 표준으로부터 추출해야 한다. DO-178C나 DO-278A에서는 검토하기 위한 표준(요구사항 표준, 설계 표준)을 요구하기 때문에 그 문서로부터 체크리스트를 만들면 쉬운데, ISO26262같은 경우는 그러한 표준을 요구하지 않아서 ISO26262만 알고 있는 사람은 이 부분을 어떻게 하라는 것인지 어려워 하는 것이 사실이다.

이 부분은 ISO26262외부에서 찾아봐야 한다. 가장 애매한 부분이기도 하지만 내부적으로 품질 기준을 수립해서 규칙을 정의할 수도 있다.

요구사항 같은 경우 요구사항에 대한 시험 가능성 관점에서 테스트 케이스를 만들 수 있는지를 검토하는 것도 중요한 검토항목중의 하나가 될 수 있다.

아니면 외부의 출처문서들을 조사해보면 다른 domain에 있기는 하지만 적용 가능한 유용한 점검항목들을 작성할 수 있다. 미국의 FAA나 NASA이나 유럽의 EURO CONTROL이나 Euro자금을 funding받아서 운영중인 프로젝트들을 보면 많은 도움을 얻을 수 있다.

체크리스트는 그 정도면 될 것 같고…그 외에도

검토하기 위한 절차서 혹은 검토 계획서가 필요하다. 실무자들은 검토절차서 및 검토 계획서에 대해 교육을 받아야 한다. 검토 회의에서 누구를 참석시킬 것인지 무엇에 대해서 논의할 것인지 몇시간 할 것인지 등 구체적인 사항들을 계획해야 한다. 일반적으로 권장되는 방법은 다른사람이 어떻게 했는지를 벤치마킹하는 것이다. Karl Wiegers의 Peer reviews in Software를 추천한다.

4. 싸운다.

개발자들 중 일부는 자기 산출물에 대한 다른 사람의 의견에 대해 상당히 못마땅해 하는 사람들이 있다. 의견을 제기하는 사람들이 비난하듯이 얘기한 것이 아님에도 불구하고.. 그러다보면 검토하다가 말싸움을 하게 되고 급기야 회의가 중단된다.

말하는 사람이 문제일 수도 있지만 듣는 사람이 문제일 수도 있다. 물론 네번째 이슈도 세번째와 같이 교육을 통해 인식의 전환을 유도해야 한다.

검토해달라고 해서 무엇에 문제가 있다고 지적하면 분위기가 싸해진다.

나름 신경써서 시간내서 봐줬더니만, 검토자도 기분이 나쁘다.. 검토받는자도 기분나쁘기는 마찬가지이다. 건방진놈이라고 생각하고 있을지도 모르겠다.

이런 상황에 대한 해결책은 리뷰 회의시의 커뮤니케이션 스킬을 높이는 것이다. 모리사키 슈지의 리뷰의 기술과 브라이언 피츠패트릭의 협업의 기술을 추천한다.

Advertisements

“Review는 정말 중요한데 왜 안하는 걸까?”에 대한 1개의 생각

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중