[펌]개발은 암기과목이 아니다

[펌]개발은 암기과목이 아니다

가끔씩 질문 게시판에 들러 글을 읽다보면 오류 내용을 통째로 복사해서 붙여 넣고 "이런 오류가 생겼는데 어떻게 해야 하나요?" 와 같은 식의 질문이 너무 많은 것 같아 안타까운 마음이 듭니다.

개발은 절대 암기로 배울 수 있는 영역이 아닙니다. 어떤 메시지가 나오면 어떤 부분을 고치면 된다는 식의 사례를 많이 외운다고 디버깅 능력이 높아지지는 않습니다.

프로그래밍 과정에서 발생하는 오류 메시지는 복사해서 검색을 하라고 나오는 것이 아니라 읽고 원인에 대해 생각하라고 제공되는 것입니다. 디버깅이 이런 경우에 이렇게 고치고 저런 경우에 저렇게 고치는 공식을 외워서 적용하는 과정이라면 오류 사전 같은 게 벌써 나왔겠지요.

예를들어, 커넥션 풀을 사용하다 "Connection Pool Exception: Cannot get a connection, pool error Timeout waiting for idle object"와 같은 오류를 접했다면, 가장 먼저 할 일은 복사해서 구글에서 검색하거나 질문 답변 게시판에 "이런 오류 났는데 어떻게 해야되요?"라고 묻는 것이 아니라 오류 내용을 읽어보는 것입니다.

그래서 '커넥션 풀', '타임아웃', '아이들 객체' 같은 개념들이 어떤 의미를 가지는지 이해하려고 노력하고, 안되면 관련 문서를 찾아보는 과정을 거치는 것이 정상입니다.

'커넥션 풀'이 무슨 개념이고 왜 사용하는지를 이해했다면 아마도 '아이들 객체'가 대기 상태의 데이터베이스 연결을 뜻함은 어렵지 않게 유추할 수 있을 것입니다. 스택트레이스를 읽을 줄 안다면 해당 오류가 'commons-dbcp'라는 커넥션 풀 라이브러리에서 발생하는 것임도 알아볼 수 있을테니 필요하면 해당 라이브러리의 프로젝트 페이지에 찾아가 문서를 참조할 수도 있을 것입니다. (인터넷 검색은 보통 스택트레이스를 통째로 검색하는 게 아니라 이런 경우 'dbcp'라는 키워드로 프로젝트 페이지를 찾을 때 쓰는 것입니다.)

이렇게 기본 개념들을 다시 정리했으면 이젠 왜 그런 문제가 생겼는지 연역적 추리를 통해 원인을 찾아보면 됩니다.

타임아웃이 될 때까지 대기 상태의 연결을 얻지 못하고 포기했다는 건 어떤 경우에 발생할까 생각해보면 어렵지 않게 '모든 연결이 타임아웃 시간 동안 사용 중인 경우'가 원인임을 유츄할 수 있습니다. 그럼 다음 단계로, 어떤 경우에 타임아웃 시간 동안 연결을 항상 사용하게 되는 지 고민해보면 대략 다음과 같은 논리적 '경우의 수'가 발생하는 것을 알 수 있습니다:

1. 연결을 한 번에 너무 오래 사용하는 경우
2. 커넥션 풀이 예약하는 연결 갯수가 지나치게 적은 경우.
3. 지나치게 짧은 시간 동안 대기하는 경우.

이런 경우 이해가 가지 않으면 머릿속으로 비슷한 경우를 형상화하거나 비유해서 이해해보는 것이 도움이 됩니다. 예컨대 커넥션 풀의 자원 관리 모델은 은행을 방문해서 대기표를 받고 업무를 보는 것과 비슷합니다.

은행 업무를 보기 위해 들렀다가 사람이 너무 많아서 점심시간 내내 기다리다 되돌아갔다면 이유가 무엇이었을지는 아마 은행 사진을 찍어서 게시판에 질문하지 않아도 누구나 쉽게 이해할 수 있을 것이라 생각합니다.

점심시간이라는 정해진 기간이 타임아웃 기간이고, 은행 창구가 얻으려는 리소스, 즉 데이터베이스 연결이고, 해당 지점 창구의 갯수가 커넥션 풀의 크기('max idle')라면 앞서 발생한 오류의 원인이 되는 경우의 수를 직관적으로 이해할 수 있을 것입니다:

1. 연결을 한 번에 너무 오래 사용하는 경우 -> 예) 진상 고객.
2. 커넥션 풀이 예약하는 연결 갯수가 지나치게 적은 경우 -> 창구나 담당 직원 부족.
3. 지나치게 짧은 시간 동안 대기하는 경우 -> 바빠서 빨리 사무실도 돌아가야하는 경우.

이렇게 경우의 수까지 추출했다면 그 다음으로는 실제 지금 프로젝트가 어느 경우에 해당하는지 검증만 하면 됩니다. 1번의 경우라면 정말 오래 걸리는 질의가 있는지, 혹은 질의는 짧게 끝나도 연결을 닫지 않아 계속 사용 중 상태로 남아있는 경우가 있는지 찾아보면 되겠지요.

사실 이번 오류의 예는 얼마전 실제로 이곳 질문 게시판에서 읽은 사례입니다. 질문자는 역시 오류 메시지만 복사해서 질문을 올렸고 이에 대한 답은 "'removeAbandoned' 속성을 설정하면 되더라" 였습니다.

DBCP 라이브러리의 'removeAbandoned' 속성은 연결을 일정 시간 닫지 않았을 때 이를 강제로 해제하는 속성입니다. 이는, 앞서 말한 경우의 수 중 1번의 경우, 또 그 중에서도 질의가 오래 걸리는 것이 아니라 개발자가 연결 해제를 잊었을 경우에만 적용될 수 있는 해법입니다. 그나마도, 정상적인 해결 방법은 해당 부분을 찾아서 연결 해제 코드를 넣는 것이기 때문에 임시 방편이나 미봉책에 불과하다고 할 수 있습니다.

이는 비유를 하자면, 내가 은행 지점장인데 점심시간에 사람이 붐벼서 고객 불만 사항이 많은 경우에 덮어 놓고 "한 사람당 창구는 3분씩만 쓰게 하라"고 강제하는 것입니다. 실제로는 창구를 하나 더 열거나 창구 하나 잡고 한 시간씩 떼를 쓰는 진상 고객 한 명만 처리하면 될 문제를 덮어놓고 "창구가 붐비면 이용 시간을 제한한다"는 '해법'을 공식처럼 적용한 결과입니다.

그럼에도 불구하고 이런 식으로 문답이 오가는 것은 질문자나 답변자 모두 올바른 디버깅 방법을 이해하지 못하고, 그냥 어떤 오류가 발생하면 어떻게 대처한다는 단편적 지식을 많이 쌓으면 개발 능력이 높아질 것으로 기대하는 잘못된 인식을 가지고 있기 때문입니다.

그런 습관이 생긴 경우 흔히 보는 현상이 무작정 아무 것이나 바꾸어 보는 것입니다. 검색해서 해결이 안되면 지푸라기라도 잡는 심정으로 개발 환경도 새로 설치해보고, 어제는 된 것 같은데 오늘부터 안된다면 어제자 소스로 롤백해보기도 하는 식으로 시간 낭비를 하는 것은 흔하게 볼 수 있습니다.

역시 은행 지점의 예로 비유를 하자면 사람이 많아 불만이 접수되면 일단 인테리어도 바꾸어보고 그런 문제가 없는 지점과 직원들도 서로 교체해보고 하는 식의 쓸데없는 시간 낭비를 하는 것입니다.

혹시 해당 질문 답변 글을 쓰신 분들이 이 글을 보시고 기분이 상하셨다면 죄송합니다만, 저는 단지 해당 사례가 바로 기억에 떠올라서 예시로 들었을 뿐 이는 그 분들만의 문제도 아니고 그 분들의 잘못이라고만 할 수 있는 것도 아니라고 봅니다.

이 곳의 질문 답변 게시판만 봐도 단순히 오류 내용 복사해 붙여넣고 내용을 이해하려는 어떠한 노력 없이 "이런 오류가 생겼는 데 어떻게 하나요?"하고 물어보는 글은 너무도 흔하게 접할 수 있습니다. 그리고 "이 것 저 것 다해봐도 안되요", "어제까진 됐는데 갑자기 안되요", "이클립스도 다시 깔아봤어요" 같은 절박한 푸념도 쉽게 보는 내용입니다.

제 생각에 이는 신입 개발자의 자질보단 그런 신입 개발자를 키워내는 시스템의 문제가 더 크지 않나 싶습니다. 개발자를 양성하는 학원은 많지만 개념이나 접근 방법을 제대로 가르치기보단 단 시간에 스프링 MVC 예제 따라해보기 같은 식으로만 수업을 진행하니 정작 중요한 내용은 수박 겉핥기 식으로 넘어가게 된 것이 아닌가 생각합니다.

또한 실무에서도 회사들이 면접에서 "스프링은 써봤어요?" 같은 걸 물어보지 디버깅을 어떻게 하는지, 객체지향을 얼마나 이해하고 있는지 같은 근본적인 지식을 따지지 않기 때문에 개발자로 입문하는 분들이 무턱대고 준비없이 완전히 이해하지 못하는 코드를 따라 치는 연습만 하니까 원래 개발은 그런 식으로 하는 것이다라는 착각을 하게 되는 게 아닌가 싶습니다.

정리하면, 개발은 원리를 이해하고 이를 적용해서 문제를 해결하는 최적의 답을 찾는 과정이지 '스프링-마이바티스' 같은 정해진 답 하나를 반복 숙달해서 아무데나 가져다 쓰는 단순 반복 작업이 아닙니다.

또한 디버깅은 문제의 원인을 연역적 사고 과정을 통해 찾아내는 절차이지, 결코 "A의 오류 메시지에는 B로 대응"과 같은 공식을 찾아 적용하는 작업이 아닙니다.

혹시라도 그런 식의 잘못된 접근 방법으로 개발에 입문한 신입 개발자분들이 계시면 지금부터라도 올바른 방법이 무엇인지 고민해 보셨으면 좋겠습니다.

그래서 앞으로는 질문 답변 게시판에 "이런 오류가 났는데 도와주세요" 같은 글보다는 최소한 "이런 오류가 났는데 메시지에서 이런 개념이 이해가 가지 않습니다" 또는 "이런 오류는 이럴 때 발생하는 것 같은 데 다른 경우가 있을까요?" 같은 최소한의 사고 과정이 드러나는 질문을 보다 많이 볼 수 있게 되었으면 좋겠습니다.

 

출처:http://okky.kr/article/311337

이글을 보고 많이 반성하게 되네요. 저또한 문제에 대한 정확한 해결분석보다 문제 대한 빠른 해답을 찾을려고 하는 경향이 있는데 앞으로 이런 습관을 고치려고 노력해야겠다는 생각이드네요.