축구선수 수비수에게 골 결정력을 요구하는 감독을 봤는가?


투수에게 타율을 높여야 한다고 말하는 코치가 있다면 아마추어 선수단의 코치일 것이다. 프로팀에서 그런것을 요구한다는 것은 말이 안되는 행동이다. 그 투수가 타자로 전향한다면 혹시 모를까.. 

그런 이야기를 왜 하냐면, 어떤 회사에서는 SQA엔지니어에게 개발자가 해결해야 하는 문제점을 해결할 수 있는 방법을 요구하고 개발자의 몫인 개발 산출물을 요구하는 상황을 경험했기 때문이다. 정말 놀라웠다. 그걸 요구하는 것이 프로다운 발상인가?  

기본적으로 테스터와 개발자의 성향은 차이가 있다고 생각한다. 기본적으로 갖추어야 하는 성격이나 기술의 스탯에 차이가 있다. 물론 개발을 잘하면서 시험도 잘 할수는 있다. 그러면서 문서작성도 잘하고 품질관리도 잘하고 일정도 잘짜고…. 

슈퍼스타를 원하는 것은 알겠는데 그런 사람한테 돈 얼마나 줄 수 있는가 묻고 싶다. 그리고 그런 슈퍼스타는 흔하지 않다. 각 role별로 요구되는 skill은 차이가 있고 모든 stat이 full인 경우는 흔하지 않으므로 보통은 skill tree를 따라 경력 설계를 하기 마련이다. 나도 마찬가지이고.

 게임에서 몸빵 유닛에게 힐링 스킬을 높인다거나 공격마법스킬을 높인다면 그건 스마트한 전략은 아니다.

마찬가지로 멀티플레이어를 요구한다는 것은 그 개인이 뭔가를 특별나게 잘하는게 없도록 요구하는 것과도 같다고 생각한다.

Sponsored Post Learn from the experts: Create a successful blog with our brand new courseThe WordPress.com Blog

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

Competency가 정말 중요하다.


능력이 부족한 사람이 맡겨진 일을 잘 수행할 것이라고 기대하는 것은  상당히 낙관적인 생각이고 근거없는 생각이다. 당연히 잘 하리라고 기대하지않는 것이 자연스러운 것이다.

회사들을 돌아다니면서 교육훈련의 중요성을 느끼게 되었는데, 좀 안좋게 말하자면 그만한 능력이 되지 않았는데 회사는 그 일을 맡겨버린다는 것이다. 일을 시킬려면 일을 할 수 있도록 도와주고 일을 시켜야 하는데 난 모르겠고 니가 알아서 해라?

그러면 도대체 누구 손해인가? 회사 입장에서 손해는 매우 크다. 다만 그것이 눈에 보이지 않아서 그러는거 같다.

조직에서 살아남아 자리만 지키기만 하면 신입이 들어오고 자기 자리는 아래에서 위로 떠 밀려서 올라가게 된다. 그러면 위의 자리에서 해야 하는 일들을 해야 하는데 전문성이나 자격등을 고려하지 않고 시키는 것 같다는 인상을 받는다.

교육을 시킨다고 항변할 지도 모르겠다.. 그런데 내가 경험한 바로는 단순히 수강만 하고 99%의 합격을 하는 그런 교육이 아닌가 싶다.

왜 자꾸 이런 소리를 하냐면, 가장 기본적인 부분에 있어서도 교육이 필요하다는 것을 깨닫게 되면 상당한 내적 절망감에 빠지게 되는데 그런 경우를 적지 않게 경험했기 때문이다.

이런 현실에서 내가 어떻게 해야 할지를 고민해야 할 필요가 있을 것 같다.  부족한 시간과 고객의 수많은 요구들을 만족시키기 위한 방법이 무엇이 있을까? 그 고민은 내가 해야 하는 것이고, 회사에 다니는 엔지니어들은 자신에게 부족한 것이 무엇인지를 알고 그 부분을 보완해야 할 필요가 있고, 회사의 입장에서는 각 인력들을 필요한 곳에 잘 배치하도록 하기 위해 인력의 기술수준을 높게 유지해야 할 필요가 있다.

아무리 개인이 열심히 하려고 해도 회사에서 도와주지 않으면 잘 해볼 도리가 없다. 쉬운 문제는 아니지만, 회사는 아무리 바쁘고 힘들어도 직원들이 경쟁력을 갖춘 인재가 되도록 하는 일에 관심을 가져야 한다.

어떤 회사는 능력있는 인재가 되면 회사를 나갈까봐 발전의 기회를 빼앗고 닭장에 가두듯이 자기 회사에 가둬서 시키고 싶은 일만 시키는데, 안타깝다. 그렇게 해서는 애플의 혁신, 영업이익 40%이상의 놀라운일이 일어나지 않는다. 그저 그런 영업이익 정도의 이익만 날 뿐이지…

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. 싸운다.

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

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

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

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

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

ISO26262, SOTIF, Autonomous Vehicle, Robot