웹어플리케이션을 개발하는데 있어 기본 소양으로 갖춰야할 사항은 클라이언트사이드 스크립트, 마크업 랭귀지, 서버사이드스크립트, Database 관련지식, 사용하는 서버/클라이언트 어플리케이션에 대한 이해다.. 이것은 선택이 아닌 필수 지식이라 볼 수 있다.. 해서 구체적으로 정리를 해보면 다음과 같이 나열해볼 수 있다..

• 클라이언트사이드 스크립트 : 자바스크립트


• 마크업랭귀지 : HTML, CSS, XHTML, XML, DOM


• 서버사이드스크립트 : PHP, ASP, JSP, ASP.NET, Ruby 기타 등등


• Database 관련 : RDBMS 지식, 쿼리문 작성능력, DB 모델링 능력, 튜닝 및 성능향상 능력


• 관련 어플리케이션 이해 : 웹브라우저, 웹서버, WAS, DB서버, OS 등의 동작원리이해 및 세팅, 관리능력

위의 3가지는 프로그래머들이 자신이 꼭 알아야 하는 내용이라 생각하고 열심히 공부한다.. (물론, 간혹 DOM 구조나 CSS, XML 등은 자신이 몰라도 된다고 생각하는 안타까운 경우가 있기는 하다.. 필요한 것이라 설명해주면 알아 듣는 사람이 있는 반면, 끝까지 왜? 라고 우기는 태도를 보이는 사람들을 만나면 슬프기까지 하다.. 언제까지 프로그래머를 할 수 있을까 라는 생각이 들어서.. 물론, 이런 내용을 몰라도 프로그래머이긴 하다..)

하지만, 뒤의 두개는 재미난 양상을 보인다.. 내가 만드는 어플리케이션의 완성도를 위해 모든 부분을 관심을 가지고 모르던 부분이 나오면 눈빛을 초롱초롱 빛내는 부류가 있는 반명, 그거 몰라도 지금까지 프로그래밍하는데 지장 없었다는 태도를 보이는 부류로 양분된다.. 특히 회사나 팀에 DBA나 시스템 엔지니어가 있는 경우에는 후자의 태도를 보이는 사람들이 더 많아지게 된다.. 나는 개인적으로는 후자의 경우를 잘 이해를 할 수는 없지만, 그렇다고 사람을 미워할 수는 없는 노릇이므로 내 생각을 여러차례 이야기를 해주곤 한다.. 하지만, "세상 사람들이 모두 당신같지 않다"는 반응을 접할때는 좀 당황스럽기도 하다.. 내가 표현을 잘 못 했는가 보다.. "니들 같은 프로그래머, 이해가 안간다"는 느낌을 준건가?

그냥 내 생각은 간단하다.. "내가 만들고자 하는 것이 있을때, 동료의 도움을 받으면 더 쉽게 해결되겠지만 부득이한 경우 혼자서라도 문제를 해결할 수 있는 능력을 키우자"는 것이다.. 물론, 요즘같은 복잡한 세상에 뭔가를 혼자 하려는 생각은 위험하고 좋지 않은 생각이지만, 그렇다고 다른 사람이 도와주지 못해서 성취를 못했다는 느낌은 더 싫다..

웹 어플리케이션은 속성상 DB와 매우 밀접한 관계를 맺고 있다.. 개발을 진행하면서 많은 쿼리문을 만들게 되는데, DBA의 전폭적인 서포트를 아주 많이 받는 경우가 아니라면 쿼리문은 프로그래머가 직접 작성하게 되는 경우가 많다.. 경우에 따라서는 모델링도 하게 된다..

놀라운 사실은 많은 프로그래머들이 쿼리문 작성시 인덱스는 생각하지 않는다는 것.. 신경을 못 쓰는 정도가 아니라 프로그래밍 과정에서 내가 생각해봐야할 대상이라는 생각이 아예 없는 경우도 있어 깜짝 놀라곤 한다..

인덱스를 나중에 다는 것도 나쁜 방법은 아니다.. 하지만, 최소한 쿼리문 작성시 이 테이블은 이런 목적으로 만들어졌으니 이러 이러한 방식으로 많이 활용될 것이고, 대략 이런 인덱스를 달아두면 조회시 성능향상이 되겠군 하는 생각을 하며 쿼리문을 만드는 것과 아닌 것과의 차이는 유지보수 과정에서 많은 차이를 낸다..

첫번째로, 이런 과정을 거듭하면서 프로그래밍시 고려해야 할 사항을 폭넓게 넓혀가는 훈련을 매일매일 해온 프로그래머와 그렇지 않은 프로그래머의 프로토타입 혹은 알파버젼의 품질 차이는 엄청나다.. 단순히 인덱스를 고려 했느냐 마느냐의 차이가 아니라 평소 자신을 훈련시키는 자세의 문제이기 때문이다.. 대부분의 사람들은 매일 매일 조금 더 나은 발전을 위한 도전 보다는 일도 많아 바쁘고, 다른 할 것도 많은데 그럴 여유가 없다며 현실과 타협한다..

두번째로는 이미 고민을 해서 쿼리문을 만들어두었기 때문에 나중에 성능 튜닝을 위한 쿼리문 검토가 보다 신속하게 이루어지며, 튜닝 대상이 되는 쿼리문의 수가 줄어들게 된다.. 당연히 유지보수 단계에서 개발팀은 좀 더 부가가치를 높이고, 만족도를 높일 수 있는 의미 있는 일에 시간을 할애할 수 있게 되며 성취욕도 높아진다.. 역시, 우리팀은 달라 하는 생각까지 미치게 되면 금상첨화다..

가장 최악의 시나리오는 이 테이블이 뭔지도 모르겠고, 이 필드가 왜 만들어졌는지도 모르겠으며 내가 맡은 화면에 필요한 데이터와 가장 비슷한 데이터를 보여주기만 하는데 급급하게 만드는 경우다.. 일정에 쫒기게 되면 회사나 팀에서 의도적으로 이렇게 만드는 경우도 있겠지만, 개인이 독자적인 판단에 의해 이렇게 만든다면 통합테스트나 유지보수 단계에서 아주 화가나게 된다.. 당해보면 정말 우울해진다.. 프리랜서들과 일할때 이런 경우가 많았는데, 오죽하면 이런 실망스런 프리랜서들을 검색해볼 수 있게 하는 사이트를 만들어야 한다는 생각도 가져봤다.. (물론, 누가 만들어줬으면 하는 생각이 더 간절하다..)

프로그래머들이 DB 관련 어플리케이션을 개발할때 성능향상을 위한 인덱스를 고려하는 것이 DBA의 몫이 아닌 프로그래머의 몫이라는 생각을 가져봤으면 한다.. 이건 누가 일을 더하고 적게하고, 네 일인데 내가 하고의 문제가 아닌 내 경쟁력을 높이는 훈련이라 생각하면 된다..