어떻게 하면 ISO 26262 요구사항을 달성할 수 있을까?


분명 Safety를 달성한다고 표현하지 않았고, ISO 26262 요건에 대한 달성관련 내용이다.

오랜만에 26262의 Part 4를 들여다보니 흥미로운 점들을 발견할 수 있었다.

예전에는 어떻게 implement할 것인지에 대해서는 system level에서는 관심이 없어서 별로 생각하지 않았었는데, 요즘 들여다보니 lifecycle을 잘 정의해야겠구나 라는 생각을 하게 되었다.

엔지니어들은 나름 대충 혹은 열심히 일을 한다. 외부인의 입장에서 그것을 평가하기 위한 객관적인 방법은 문서밖에 없다. 엔지니어들도 문서를 통해 평가를 받는다는 것을 안다. 하지만 어떻게 하면 잘 보일 수 있을 것인지에 대해서는 별로 관심이 없는 것 같다. (내 주변의 사람들만 그런 것일 수도 있다.)

오늘 문득 이런 생각이 들었다. 취업을 위한 면접에 슬리퍼에 츄리닝 차림으로 가는 사람은 없을 것이고, 아무리 formal을 지양한다고는 하지만 그런 차림이라면 이건 너무 하잖아~ 라고 할 것이 분명하다.

제품에 대한 단 하나의 지식이 없는 제 3자가 그 문서를 들여다본다고 했을때, 그들은 그 제품이 safe할 것인지에 대해서 평가할 수 있는 능력은 없다. (개인적인 의견이다.) 하지만, 그들은 그 문서를 통해 이 제품이 충분하게 safe하지 않은지에 대해서 평가할 수 있는 능력은 갖추고 있다. (대체로 그렇다)

그들의 입장은 대체로 일관적이며 질문 리스트와 예상 답변도 공개되어 있는 편이다. 그렇다면 많은 기업들이 출제자 관점으로 자료를 잘 준비할까?

안타깝게도 그렇지 않은 것 같다. 그 이유는 engineer의 접근 방식으로 제품 자체의 safety나 contents 자체에 대하여 깊이있게 기술하려고 하기 때문이다. 참 미안한 말이지만, 제 3자가 단기간에 그런 깊이 있는 내용을 이해할 수 있는 사람은 많지 않다. 대부분 10분 내로 읽고 흘려버린다. 나중에 궁금하면 다시 물어보면 된다.

그래서 누군가가 출제자의 mind로 문서에 대한 포장을 리딩해야 한다. 그 포장의 시작은 lifecycle이다.

lifecycle은 일의 시작과 방법에 대하여 어떻게 할 것인지를 정의해 놓은 것인데, 사실 lifecycle만 봐도 얼마나 조작을 했는지가 금새 티가 난다. 마치 밀린 일기 쓰듯이 썼겠구나라고 예상이 된단 말씀..

그럴법한 lifecycle을 정의해 놓으면 그만큼 힘도 덜 들고 자연스럽게 포장이 된다. 26262를 펴 놓고 내용을 한줄한줄 읽으면서 어떻게 implement할지를 생각해보시길… 그리고 lifecycle을 정의해놓고 말이 될지를 생각해 보시길.. 말이 되면 당신은 고수!

Advertisements