개인적으로 SoC에서 가장 재미있게 생각하는 부분이 검증/디버깅입니다.

처음부터 버그없는 넘을 만들면 좋겠지만, 그럴수 없다면 효과적인 검증과 디버깅은 “비용을 소모하는 부수적인 일”이 아니라 이미 필수적인 일인 것입니다.

간혹 몇몇 경영자분들께서 “자신이 실수를 하고 자신이 디버깅하는데 시간과 돈을 소모하는 건 전적으로 엔지니어의 부주의다.”라고 말씀하시곤 하는데, 50%는 납득하지만, 50%는 절대 납득할 수 없습니다.

부주의에의 해서 생긴 버그, 스팩 이해에 문제로 인한 버그, 전달 과정에서의 버그, 초기 아키텍쳐에 의한 버그.. 이 모든 것이 발생하지 않게 완벽한 스팩과 작업을 할 수 있는 사람이 있으리라 생각하지 않기 때문입니다.

아.. 오늘의 이야기에 들어가서.. 디버깅하시는 스타일을 보면 참 여러가지 부류가 있습니다.

검증/디버깅의 기본은 “원인의 파악”이겠죠?

그런데, 그 원인 파악이 아주 아주 어려울때가 있습니다. 수많은 로직들에 연관 관계가 있고, 게다가 타이밍에 의한 영향까지 받는경우 말입니다.

간혹 이런 경우에, 좀 찾으시다가.. 재미난 이유를 대시는 분들이 있습니다.

마치 “고양이가 코드를 먹어버리는 바람에 코드가 사라졌어요” [이 문장은 제가 어느 책에서 본 문장입니다.] 라던지 “낮에는 죽는데 밤에는 안죽네요..” 같은 이유 말입니다.

아.. 얼마나 고생했으면 그런 생각이 다 들겠습니까?

하지만, 신화속에 들어가는 순간 버그는 절대 사라지지 않습니다.

적어도 디지털 회로에서 신화속에 사는 버그란 없습니다. (아날로그 회로에는 아날로그 행운의 신이 있다고 믿는 분들이 많으시고.. 저도 일부 믿습니다.. ^^; )

자.. 디버깅/검증에서 또 한가지 주의해야 할 사항이 있습니다.  바로 “이 일은 절대 일어날 수 없어 ” 라는 것입니다. 이런 신념은 눈앞에서 지나가는 벌레를 그냥 못보고 지나치게 할 수 있습니다.

네.. 바로 눈앞에서 일어나고 있는 일을 그냥 모른채 할 뿐인거죠..

여러분은 “절대 일어날 수 없는 일”을 디버깅하는 것이 아니라 “지금 그 일이 일어났으니까..” 디버깅 하는 겁니다.

현실에서 도망가지맙시다.

이제 튼튼한 올가미 몇개를 준비할 차례입니다.

몇몇 책에서는 shot-gun이라 말하기도 하더군요… [verification plan (james저)]

여하튼 의심나는 곳, 절대 일어날 수 없다고 생각하는 곳 모두에 던져 봅시다.

그리고, 선입관을 버리고 찾아나가다 보면 결국 찾을 수 있을 것입니다.

점점 확신을 얻어가게 될때도 항상 “다른 가능성”을 열어두면서, 범위를 좁혀가면 얼마 시간이 지나지 않아서 올가미에 벌레가 딸려 올라오는 걸 보게 될 것입니다.

잡기 어려운 버그일수록 잡았을때 기쁘지 않겠습니까?

버그찾기란 그런것이니까요..

자! 즐깁시다….

p.s. 요즘 버그잡기에 한창입니다. 신화에 빠지지 않으려 써봤습니다.