아마 이게 어떤 느낌인지 알 겁니다. 우리 모두가 한 번쯤 겪었던 일입니다.
코드를 수십 번 읽어 보았으나 어디가 문제인지 발견하지 못하고 있습니다.
그 코드에는 여러분이 도저히 처리할 수 없는 버그 혹은 오류가 존재하고 있습니다.
여러분은 코딩하고 있는 컴퓨터에 문제가 있거나 프로그램을 실행하는 운영체제 혹은 사용하는 도구나 라이브러리에 문제가 있다고 생각해버립니다.

“분명히 다른 곳에 버그가 있어!”

하지만 아무리 좌절스럽더라도 그런 접근을 해서는 안됩니다.
우연에 맡기는 프로그래밍은 이제 그만하십시오. 그건 정말 나쁜 행동입니다.
어렵고 모호한 버그와 맞서는 것이 좌절감을 줄 수도 있지만, 그런 좌절감 때문에 잘못된 길로 들어서서는 안 됩니다.

좋은 프로그래머가 되기 위한 필수 조건은 여러분이 작성한 코드에 문제가 있을 때마다 그것이 항상 자신의 잘못이라고 생각하는 일입니다.
이 내용은 실용주의 프로그래머에서 select 함수는 잘못되지 않았다 부분에 잘 요약되어 있습니다:

대부분의 프로젝트에서 당신이 디버깅하고 있는 코드는 당신의 프로젝트 팀, 써드파티 결과물(데이터베이스, 네트워킹, 그래픽 라이브러리, 특화된 통신 방법들이나 알고리즘 등), 플랫폼 환경 상에서(운영체제, 시스템 라이브러리, 컴파일러) 당신과 다른 이들에 의해 작성된 응용 프로그램 코드의 결합물일 것이다.

운영체제나 컴파일러 혹은 써드파티 제품에 버그가 있을 수도 있다.
하지만 그것이 첫 번째로 의심하는 사항이 되어서는 안 된다.
당신의 코드에 버그가 존재할 가능성이 훨씬 더 크다. 라이브러리 자체에 버그가 있다고 의심하는 것보다는 라이브러리를 호출하는 응용 프로그램의 코드가 문제가 있다고 생각하는 것이 보통 더 이득이다.
설사 진짜로 써드 파티 코드에 문제가 있었다 할지라도, 어차피 버그리포트를 제출하기 전에 자신의 코드를 정리하는 일을 해야만 한다.

우리는 한 프로젝트에서 솔라리스 운영체제에 있는 select 함수에 버그가 있다고 확신하는 한 고참 개발자와 일한 적이 있었다.
어떤 설득이나 논리도 그의 생각을 바꿀 수는 없었다. (같은 컴퓨터에서 다른 네트워크 프로그램들은 모두 잘 작동했지만 그건 그에게 별 상관이 없었다.)

그는 몇 주동안 문제를 해결하려고 이리저리 코드를 변경해보았지만, 이상하게도 그 문제는 해결이 되지 않는 것처럼 보였다.
그가 우리의 강요에 의해 억지로 자리에 앉아 select 함수의 문서를 읽었을 때, 그제야 그는 어떤 것이 문제였는지 깨달았고 그 문제를 몇 분만에 해결했다.
그 이후 우리는 누군가가 자신의 실수일 수 있는 문제를 시스템의 버그라고 탓하는 것을 볼 때마다 select 함수의 버그 라는 말을 사용하게 되었다.

코드 주인의식의 다른 말은 코드 책임의식입니다.
여러분의 소프트웨어의 문제가 무엇이든지 간에 (그 문제가 자신의 코드에 없었다 할지라도) 항상 자신의 코드 안에 문제가 있다고 가정해야 하고 그에 따라 행동해야 합니다.
만약 여러분의 소프트웨어가 최고가 되길 원한다면 제품의 버그에 대해 전적으로 책임을 져야만 합니다.
사실 엄밀히 말하면 그럴 필요까지는 없습니다만, 이것이 여러분이 존경과 신뢰를 얻게 되는 방법입니다.
만약 그 문제에 대해 다른 사람들, 회사나 다른 소스로 그 잘못을 떠넘긴다면 여러분은 분명 존경과 신뢰를 얻지 못하게 될 것입니다.

여러분도 알다시피, 오류가 여러분의 잘못이 아닌 소프트웨어의 오류일 확률은 통계적으로 극히 드뭅니다.
스티브 맥코넬은 그의 책 코드 컴플리트에서 이 사실을 증명하는 두 가지 연구사례를 인용했습니다:

1973년과 1984년에 수행된 연구는 보고된 총 버그의 약 95%가 프로그래머에 의해서 발생한 것들이라는 것을 발견했다.
2%는 시스템 소프트웨어(컴파일러나 운영체제) 이고 2%는 그 외의 다른 소프트웨어들이었으며 1%는 하드웨어였다.
오늘날 시스템 소프트웨어와 개발도구들은 1970~80년대에 비해서 훨씬 많은 사람들에 의해 사용되고 있기 때문에 지금은 프로그래머의 오류 비율이 예전보다 더 높아졌을 것이라 추측한다.

여러분의 소프트웨어가 가지고 있는 문제가 무엇이든지 간에 주인의식을 가지시기 바랍니다.
먼저 여러분의 코드에서부터 출발해서, 그 문제 원인에 대한 결정적 증거를 손에 넣을 때까지 계속해서 바깥으로 범위를 넓혀가며 살펴보십시오.
만약 그 문제가 자신이 컨트롤할 수 없는 다른 코드에 존재한다면 문제 진단 및 디버깅 기술을 배워야 할 뿐만 아니라 자신의 주장을 뒷받침해줄 수 있는 증거 또한 확보해 두어야 할 것입니다.

이 과정은 어깨를 한번 으쓱하며 운영체제, 개발도구, 프레임워크의 잘못으로 돌리는 것보다는 훨씬 더 번거로운 일입니다.
그러나 이는 여러분에게 남 탓으로 돌리기나 문제 회피 등으로는 절대로 얻지 못하는 신뢰와 존경을 얻도록 할 것입니다.

만일 진심으로 좋은 프로그래머가 되고 싶다면
“그건 내 실수야. 내가 그 원인이 뭔지 찾아내고 말 거야.”
라고 말하는 것을 꺼리지 마세요.

이 글은 스택오버플로우를 개발한 제프 앳우드가 2008년 3월에 쓴 The First Rule of Programming: It’s Always Your Fault 를 원저자의 허락을 받고 번역한 글입니다.

–

2년여 전 즈음에, 카카오의 동료들하고 심심풀이로 기술 관련 좋은 글들을 구글 독스에서 소셜 번역(?) 을 하곤 했었는데, 그중 하나였던 이 글이 최근 자꾸 생각나서 다시 읽어보다가 블로그에 올려야지 생각하게 되었다. (함께 했던 Jenny, Clare, Probe 감사!)
이 글은 코딩 호러의 이펙티브 프로그래밍이라는 번역서 내에도 담겨있으며, 이 책에는 다른 좋은 글들도 많으니 관심이 있는 사람들은 읽어보는 것도 좋겠다.
제프 앳우드의 다른 책으로는 코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기라는 책도 있다.
둘 다 너무 재미있고 좋은 이야기들이 많이 담겨있는 책이다.