수학이란 머리 아픈 것일까요?

부끄러운 말이지만, 저는 중/고등학교를 통털어 “수학”을 잘해본 역사가 없습니다.
어문 계열의 과목은 어느 정도 괜찮았지만, 수학만은 시험 칠 때마다 극과 극이었습니다. ^^;
어찌보면, 대학 진학에 있어서 가장 큰 난점이 “수학”이었습니다. 수학 성적에 따라 당시 학력고사 성적이 50점까지 왔다갔다했으니 말입니다.
지금와서 생각해보면, 수학이란 것이 정말 지겹기 그지 없었습니다.
이유는 모르겠어요. 지겹기 그지 없었습니다.

수학이란 것이 지겹지 않게 된것은 몇년 안되었습니다. (그렇다고 지금 수학을 잘한다는 말은 아닙니다.)
단지, 수학의 수식이 가진 의미를 읽어낼 수 있는(풀수 있는 건 아니지만..) 단계까지는 온 것으로 느끼는데, 이것이 바로, 제가 대학원을 잘 왔다고 생각하는 가장 큰 이유중의 하나입니다. 즉, 수식을 “언어이자 기호”로서 이해할 수 있는 단초를 제공해 주었다는 측면인 것이지요.

되짚어 생각해보면 왜 그렇게 수학이 싫었던 것일까요?
그건 바로 “수식을 무조건 암기하라고 강요하는 교육”의 성과가 아닌가 싶습니다.
수식을 외우면 문제는 잘 풀려요. 문제집을 술술 풀수 있지요.. 근데, 그게 다에요.. 지겹습니다.
머리에 남지도 않구요.
저에게 수식들이 지닌 의미를 알려주신 두 분 교수님(이형우 교수님과  김민기 교수님)이 아니었으면 저는 아직도 수식을 지겨워 할 것입니다.
그만큼 좋은 선생님을 만난다는 것은 인생에 있어서 깊은 의미를 지닌다고 생각합니다.

요즘에 “리만 가설”이란 책을 읽고 있습니다. 현욱님의 블로그의 글을 보고 관심을 두고 있다가 읽게 되었지요.
이 책을 읽으면서 좋은 수학 선생님을 만난 느낌입니다.
사실 수학이란 퀴즈를 좋아하는 사람에게 가장 큰 지적 호기심을 제공하는 것인데, 문제를 명확하고, 단순하게 표현하기 위한 수식에 압도되어 문제 자체의 즐거움을 놓치게 되는 경우가 많은데, 이 책은 그런 수식의 위압감보다는 수식의 아름다움을 잘 설명하고 있습니다.


  리만 가설 – 베른하르트 리만과 소수의 비밀  존 더비셔 지음, 박병철 옮김
전문 수학자들이 가장 많은 관심을 갖고 있는 미해결 문제. ‘제타 함수의 자명하지 않은 모든 근들은 실수부가 1/2’이라는 리만 가설이 나오게 된 역사적 배경과 관련 인물들을 소개했다.

이 책의 많은 수식은 이미 여러 책을 통해서 눈에 익은 수식이 많습니다.
당시에 큰 의미없이 받아들였던 부분인데, 어떤 의미인지 더 명확해지는 상쾌함을 느낄 수 있습니다.

이 책의 특징은 홀수 장은 수식 위주로, 짝수 장은 수학사 위주로 풀어놓은 재미있는 구조를 지니고 있습니다.
수식에 위압감을 느끼시는 분은 짝수 장만 보셔도 될듯 합니다.

수학적 즐거움에 빠져보고 싶으신 분은 한번 도전해 보세요..

변화가 싫다?

이 이야기는 설계 회사에 들어가실 분들에게 유용할 수도 있는 글이라 생각하여 써봤습니다. ^^;
—–
차라리 백지가 좋은데, 그렇지 않은 경우가 있습니다.
학교에서 배워온 코딩 스타일(사실 학교에서 코딩 스타일을 가르쳐주지는 않지요?)과 회사의 코딩 스타일이 다를때 자기 자신이 납득할 때까지 바꾸기도 쉽지 않지요 (그게 바로 엔지니어니까요!)

회사에서는 왜 특정 코딩 스타일을 고집할까요?
반대로 학교에서는 왜 코딩 스타일에 둔감할까요?

회사에서는 “칩이 정상적으로 도는 것”이 가장 중요한 목표인 반면에, 학교에서는 시뮬레이션을 돌려서 “결과를 뽑는 것”이 가장 중요한 목표이기 때문이지요.

따라서, 회사에서는 아주 안전하고, depensive한 코딩 스타일을 유지하게 됩니다. 즉, 시뮬레이션과 합성 이후의 결과에 차이가 나기 어려운 코딩 스타일을 유지한다고 보시면 됩니다.

학교에서는 아이디어를 빨리 구체화해서 도는 걸 보이는 것이 목표니까.. 약간은 offensive한 문법을 사용합니다. 좀 위험한 넘도 많이 사용하구요. 그래서, 가끔은 질문 게시판에 “시뮬레이션은 도는데, 합성하면 이상하다.. 툴이 이상한거 아니냐.. “라는 질문이 올라옵니다.

이런 측면에서 예전 SIPAC 코딩 스타일이나, RMM의 코딩 스타일 가이드는 실무적으로 아주 중요합니다.
(SIPAC은 이제 사라졌지만 말입니다.) 학교에서만 끝낼것이 아니라면 RMM[1]RMM: Reuse Methodology Manual. Cadence, Synopsys 엔지니어들이 코딩 스타일에 대하여 가장 체계적으로 정리한 실무서입니다. 저는 SIPAC나 IPCOS의 코딩스타일 가이드라인이 모두 RMM에서 출발했다고 보는 입장입니다. ^^; 예전에 학회에서 SIPAC의 서책임님과 이런 이야기를 나누었다가 반박당한적도 있습니다만 ^^; 요기에 간단히 소개되어 있습니다. 을 보세요
—-

버젼 관리라는 것은 아주 중요합니다. 절대적으로 중요합니다.
하지만, 학교에서 버젼 관리하는 경우는 거의 못봤습니다.
회사에서도 하는 회사도 있고, 하지 않는 회사도 있습니다.

회사에서 소스 코드에 대한 버젼관리를 하고 있다면, 귀찮아하시지 마시고 긍정적으로 따라가십시요. 버젼 관리를 통해서 구원받을 날이 반드시 있습니다.
그리고, 버젼 관리를 하지 않는다면 반드시 버젼관리를 시작하십시요. CVS와 같은 강력한 툴이 있습니다. 하드웨어 검증 책마다 강조하는 것들이 있는데 빠지지 않는 것이 있다면 바로 버젼관리입니다.

버그 트래킹이란 것이 생소하신가요? 아직 체계적인 버그 보고 체계가 없다면, 지금부터는 고려할 때가 되었습니다. (이건 뭐, 상품 카피 같기도 하네요.. ^^;)
버그 트래킹은 어찌보면 “버그를 확인하고, 정확히 정의하고, 동일한 문제가 발생하지 않도록 체계적으로 관리하는 방법”이라 보는 것이 맞겠습니다.

Trac이나 Mantis, Bugzilla가 버그 트래킹 시스템에서 가장 많이 알려져 있겠습니다.

저도 사실 위의 3가지를 기반으로 저희 회사에 맞는 방법을 저울질 중인데.. 초반에는 버그 질라에.. 지금은 trac쪽에 약간 무게를 두고 있습니다. 사실 버그 트래킹 기법이라것이 소프트웨어 개발쪽에서 출발한 것이라, HDL에는 약간 귀찮은 면이 있습니다.

그것보다 더 귀찮을 것이라 생각되는 부분은 “변화를 싫어하는 마음”입니다.
버그 트래킹이나, 버젼 관리 좋다.. (듣기는 들었으니..) 하지만, 나를 귀찮게 하는 건 싫다..
이런 마음이 가장 문제겠지요..

귀찮더라도 도전합시다.

Notes & References

Notes & References
1 RMM: Reuse Methodology Manual. Cadence, Synopsys 엔지니어들이 코딩 스타일에 대하여 가장 체계적으로 정리한 실무서입니다. 저는 SIPAC나 IPCOS의 코딩스타일 가이드라인이 모두 RMM에서 출발했다고 보는 입장입니다. ^^; 예전에 학회에서 SIPAC의 서책임님과 이런 이야기를 나누었다가 반박당한적도 있습니다만 ^^; 요기에 간단히 소개되어 있습니다.

새해 복 많이 받으세요

한국적인 정서로는 아무래도 설날이 새해로 생각됩니다.


제 블로그에 찾아주시는 여러분.
모두 새해 복 많이 받으시고, 하시는 설계와 검증에 신의 손길이 함께하시길 바랍니다 ^^;

저도 바쁘다는 핑계로 쓰고 싶은 글을 몇개 못쓰고 있었는데, 설날 지나고 몇개 적어보도록 하겠습니다.
모두~ 즐거운 설날!



[이미지 출처는 다음입니다.]