Paul Graham이 쓴 Hackers and Painters라는 글을 보면 math envy라는 말이 나옵니다. 과학계에 있는 사람들은 속으로 수학자들이 자신들보다 똑똑하다고 믿는 것을 두고 나온 말입니다. 이런 생각의 결과로 자신의 작업을 되도록이면 수학적으로 보이려고 애쓰게 되는데 물리학같은 과학에선 이런 현상이 별 해가 없지만 자연과학에서 멀어질수록 문제를 발생시킬 수 있습니다. 정말 중요한 문제보단 수학적으로 보일 수 있는 문제를 풀려는 유혹이 강해진다는 것이죠.
제 생각에 개발자들에게 또 하나의 envy가 있다면 low-level envy가 아닐까 합니다. C++를 알다보면 컴파일러의 구현 방법에 대해 알고 싶어집니다. 표준 라이브러리를 사용하다보면 이 함수는 어떤 시스템 콜을 사용하는지 궁금해지고요. 다음으론 그 시스템 콜은 커널에서 어떻게 동작하는지, 커널이나 디바이스 드라이버는 어떻게 구현되는지, 하드웨어와는 어떻게 인터페이스하는지, CPU는 한 명령어를 어떻게 처리하는지, 캐시는 어떻게 사용되는지 등등.
사실 이런 low-level envy는 math envy와는 달리 실제 프로그래밍 작업에 많은 도움이 됩니다. 실제 지난 글에서 살펴봤던 pure virtual function called와 같은 에러는 컴파일러가 vtbl과 vptr를 어떻게 구현하는지를 몰랐다면 원인을 찾기가 어려웠을 것입니다. 다른 예로 시스템의 메모리는 남아 있는데 왜 더 이상 쓰레드 생성이 안되는지와 같은 에러의 원인을 알려면 커널이 어떻게 쓰레드를 구현하고 있는지를 알고 있어야 할 것입니다. C++ and the Perils of Double-Checked Locking과 같은 문제점을 찾으려면 sequence point라는 개념과 컴파일러와 CPU에 의한 최적화 방법들까지 어느 정도 알고 있어야 합니다.
이런 low-level의 지식들은 날마다 필요한 것들은 아닙니다. 하지만 진짜 어려운 문제를 만났을 때 그것을 해결할 수 있느냐 없느냐의 차이를 가져옵니다.
이런 문제가 가장 많이 발생하는 곳이 바로 multi-threading쪽이 아닐까 합니다.
이 문제가 어려운 이유는 재현이 어렵다는 것이죠. 따라서 일반적인 디버깅과 같이 trial and error 방법을 써서 문제를 풀기가 어렵습니다. 이런 문제는 꼼꼼한 code inspection과 알고 있는 지식을 가지고 정확히 문제가 되는 코드를 찾아야 합니다. 주로 lock이 있어야 할 곳에 없거나 locking의 범위에 몇 라인이 빠졌다거나 하는 문제입니다만 multi-threading의 원리를 이해하지 못하고 있으면 원인을 찾지 못하거나 "printf를 한 줄 넣었더니 잘 되요"나 "debugging 옵션으로 컴파일하니 문제가 없어져요"와 같은 엉뚱한 결론을 내리게 됩니다.
저 역시 항상 좀 더 low-level을 알고자 하는 욕심이 있어서 리눅스 커널 관련 서적을 몇권 읽었습니다. 하드웨어에 관해선 학교 다닐때 수업시간에 들은게 다입니다만 항상 관심을 가지고 있고요. ((art.oriented사이트에서 가끔 재밌는 글을 읽게 됩니다. 얼마전에도 false sharing에 대한 글이 올라 왔었죠. Monaca사이트도 등록해 놓고 읽고 있습니다. 여긴 가끔 프로그래밍 이외의 강한 어조의 글들이 올라옵니다. :-| ))
얼마전에 회사에서 시켜주는 교육중에 임베디드 리눅스 프로그래밍이란 것이 있길래 냉큼 신청해서 들었습니다. 여태까진 임베디드 시스템이라고 해도 거의 PC 수준의 시스템이었기 때문에 항상 진짜 임베디드 시스템 프로그래밍이란 어떤 것인지 궁금했는데 (몰라서 불안했는데) 부트로더나 커널 포팅에 대해 배우고 나니 많은 도움이 되었습니다. (좀 안심이 되더군요.) 일단 커널 포팅이 되고 나니 다음은 거의 하드웨어 스펙 보기나 애플리케이션 레벨의 프로그래밍이 되어 좀 지루해지긴 했습니다만... :-)
훌륭한 개발자의 조건은 무엇보다 호기심인 것 같습니다. 모르는 것이 생겼을 때 궁금해서 못 견디는 그런 호기심 말이죠. :-)
.
덧) 한가지 문제는 low-level envy뿐 아니라 high-level envy도 있다는 것입니다. 코딩만 하다보면 설계 방법도 배워야 되고, 디자인 패턴, 리팩토링, UML에 각종 methodology까지... 제가 요새 읽고 있는 책은 Fit for Developing Software. :-|
제 생각에 개발자들에게 또 하나의 envy가 있다면 low-level envy가 아닐까 합니다. C++를 알다보면 컴파일러의 구현 방법에 대해 알고 싶어집니다. 표준 라이브러리를 사용하다보면 이 함수는 어떤 시스템 콜을 사용하는지 궁금해지고요. 다음으론 그 시스템 콜은 커널에서 어떻게 동작하는지, 커널이나 디바이스 드라이버는 어떻게 구현되는지, 하드웨어와는 어떻게 인터페이스하는지, CPU는 한 명령어를 어떻게 처리하는지, 캐시는 어떻게 사용되는지 등등.
사실 이런 low-level envy는 math envy와는 달리 실제 프로그래밍 작업에 많은 도움이 됩니다. 실제 지난 글에서 살펴봤던 pure virtual function called와 같은 에러는 컴파일러가 vtbl과 vptr를 어떻게 구현하는지를 몰랐다면 원인을 찾기가 어려웠을 것입니다. 다른 예로 시스템의 메모리는 남아 있는데 왜 더 이상 쓰레드 생성이 안되는지와 같은 에러의 원인을 알려면 커널이 어떻게 쓰레드를 구현하고 있는지를 알고 있어야 할 것입니다. C++ and the Perils of Double-Checked Locking과 같은 문제점을 찾으려면 sequence point라는 개념과 컴파일러와 CPU에 의한 최적화 방법들까지 어느 정도 알고 있어야 합니다.
이런 low-level의 지식들은 날마다 필요한 것들은 아닙니다. 하지만 진짜 어려운 문제를 만났을 때 그것을 해결할 수 있느냐 없느냐의 차이를 가져옵니다.
이런 문제가 가장 많이 발생하는 곳이 바로 multi-threading쪽이 아닐까 합니다.
이 문제가 어려운 이유는 재현이 어렵다는 것이죠. 따라서 일반적인 디버깅과 같이 trial and error 방법을 써서 문제를 풀기가 어렵습니다. 이런 문제는 꼼꼼한 code inspection과 알고 있는 지식을 가지고 정확히 문제가 되는 코드를 찾아야 합니다. 주로 lock이 있어야 할 곳에 없거나 locking의 범위에 몇 라인이 빠졌다거나 하는 문제입니다만 multi-threading의 원리를 이해하지 못하고 있으면 원인을 찾지 못하거나 "printf를 한 줄 넣었더니 잘 되요"나 "debugging 옵션으로 컴파일하니 문제가 없어져요"와 같은 엉뚱한 결론을 내리게 됩니다.
저 역시 항상 좀 더 low-level을 알고자 하는 욕심이 있어서 리눅스 커널 관련 서적을 몇권 읽었습니다. 하드웨어에 관해선 학교 다닐때 수업시간에 들은게 다입니다만 항상 관심을 가지고 있고요. ((art.oriented사이트에서 가끔 재밌는 글을 읽게 됩니다. 얼마전에도 false sharing에 대한 글이 올라 왔었죠. Monaca사이트도 등록해 놓고 읽고 있습니다. 여긴 가끔 프로그래밍 이외의 강한 어조의 글들이 올라옵니다. :-| ))
얼마전에 회사에서 시켜주는 교육중에 임베디드 리눅스 프로그래밍이란 것이 있길래 냉큼 신청해서 들었습니다. 여태까진 임베디드 시스템이라고 해도 거의 PC 수준의 시스템이었기 때문에 항상 진짜 임베디드 시스템 프로그래밍이란 어떤 것인지 궁금했는데 (몰라서 불안했는데) 부트로더나 커널 포팅에 대해 배우고 나니 많은 도움이 되었습니다. (좀 안심이 되더군요.) 일단 커널 포팅이 되고 나니 다음은 거의 하드웨어 스펙 보기나 애플리케이션 레벨의 프로그래밍이 되어 좀 지루해지긴 했습니다만... :-)
훌륭한 개발자의 조건은 무엇보다 호기심인 것 같습니다. 모르는 것이 생겼을 때 궁금해서 못 견디는 그런 호기심 말이죠. :-)
.
덧) 한가지 문제는 low-level envy뿐 아니라 high-level envy도 있다는 것입니다. 코딩만 하다보면 설계 방법도 배워야 되고, 디자인 패턴, 리팩토링, UML에 각종 methodology까지... 제가 요새 읽고 있는 책은 Fit for Developing Software. :-|
low-level envy, 멋진 표현입니다. 호기심이 중요하다는 말이 무척 와닿습니다. 호기심이 많을수록 low-level envy가 많이 생기는 것 같더라구요.
ReplyDelete