개발경력 3년차 학부생때와 다르게 관심 서적이 변했다.

학부생시절 코딩서적만 보다.

프로젝트를 몇 번 하고 났더니 개발 경력이 이제 3년 차가 되었다. 만 3년이 된 건 아니고 만 2년하고 조금 더 지났다. 최근 IT 관련 서적을 구매하면서 느낀 점이 있다. 대학생 때와는 책을 고르는 기준이 달라졌다. 대학생 시절은 그냥 오로지 문법과 코딩에 관한 서적만을 구매했다. 대표적인 예로 들면 저자 유성우 씨의 열혈 C 프로그래밍, 남궁성 씨의 자바의 정석, 신용권 씨의 이것이 자바다 이외에 HTML, CSS, JAVASCRIPT와 같은 책을 구매했다. 오로지 코딩만이 중요하다고 느꼈던 것 같다.

 

데이터베이스로의 이동

그리고 취업을 한 후에 필드에서 개발을 하게 되다 보니 데이터베이스의 중요성도 어느 정도 느끼게 되어 데이터베이스 교재를 구매했다. 학부생 시절에 데이터베이스에 관심을 가지지 않았던 이유는 학부에서 떠도는 소문 때문이었다. 디자이너, 프런트, 백엔드, 데이터베이스 서로 각각 따로 개발을 하기 때문에 골고루 알 필요가 없었다는 소문이었다. 그래서 프런트를 하고 싶은 사람은 프런트만 공부를 하면 되고 백엔드를 하고 싶은 사람은 백엔드만 하면 된다. 이런 식의 소문이었는데 그리하여 나는 데이터베이스는 필요 없고 코딩만 하면 된다는 마음으로 코딩 서적만 봤던 것 같다. 하지만 막상 취업을 하고 현장에 투입이 됐는데 내가 상상했던 개발과는 많이 달랐다. 우선 데이터베이스를 건드릴 일이 없을 줄 알았는데 데이터베이스 쿼리문 작성을 해야 했고 서버단 개발도 같이 해야 했다. 물론 이전 시스템에서 차세대 시스템으로 옮기는 과정이라 이전 시스템 쿼리 문의 칼럼명을 단순히 새로운 이름으로 바꿔주고 매핑만 시키면 되기 때문에 난이도가 그렇게 높지는 않았다. 하지만 중간중간에 테이블들이 바뀌어버려 쿼리문 구조 자체를 바꿔야 할 때는 상당히 방황했던 것으로 기억한다. 그리하여 현장에서 어려움을 느꼈기에 데이터베이스 서적을 구매해서 공부를 했었다. 이때 HTTP 서적이나 LINUX와 같은 서적을 구매하기도 했다.

 

프로젝트 관리 서적으로의 이동

그다음 프로젝트는 신규 업무였기 때문에 테이블도 새로 만들고 테이블 설계를 왜 이렇게 하였는지에 대한 이해도 필요했기 때문에 이때 쿼리문 작성에 대한 요령이 많이 늘었던 것 같다. 두 번째 프로젝트를 마치고 3번째 프로젝트를 진행하면서 이제 기술이 아니라 프로젝트 관리와 사람에 대해 관심사가 이동을 하게 됐다. 우선 두 번째 프로젝트의 경우같이 일하던 개발자가 경력은 15년이 넘었는데 개발을 너무 못해서 내가 대신해주었고 3번째 프로젝트에서도 2번째 프로젝트와 같은 상황이었다. 경력 20년이 넘는 특급 개발자 2명이서 구현을 제대로 못해 프로젝트를 개판치는 모습을 보고 왜 이런 사람들이 특급이라는 타이틀을 달고 여기에 와있을 수 있는 걸까?라는 생각이 들었다. 그러다 보니 피플웨어, 맨 먼스 미신과 같은 기술서적이 아닌 프로젝트 인적관리? 서적에도 손이 가게 되었다. 그러면서 단순히 개발 경력만으로 사람을 채용하는 SI에 아쉬움을 느끼기도 했다. 물론 지금도 느끼고 있다. 단순히 경력이 많다는 이유로 나보다 개발 본수도 많지 않고 일도 열심히 안 하는데 돈을 많이 가져가는 모습을 보면 SI 업계의 아쉬움을 못 느낄 수 없다.

 

코딩,DB,프레임워크,관리서적 다방면으로의 이동

위와 같은 상황들로 인하여 관심 가는 부분이 늘어나게 되었고 현재는 다방면으로 학습을 하려고 노력하고 있다. 코딩 서적도 보고, 데이터베이스 서적도 보고, 프레임워크 서적도 보고, 프로젝트 관리 서적도 보고, 팀워크와 관련된 서적도 보고 그리고 프로젝트를 하면서 제일 중요하게 느끼는 부분은 커뮤니케이션의 중요성이다. 일을 잘 할 의지가 있느냐, 일을 할 의지가 있느냐, 일을 할 의지가 없느냐로 나눈다면 일을 잘 할 의지가 있는 개발자의 경우에는 커뮤니케이션을 엄청 열심히 한다. 일을 잘 할 의지는 없고 일을 할 의지가 있는 개발자란 어떠한 경우냐 하면 설계가 틀어졌으면 설계자에게 이야기를 해서 설계를 고칠 생각을 해야 하는데 틀어진 설계를 바탕으로 코딩으로 소스코드를 조금 더럽게 만들어 편법적으로 넘어가려고 하는 성향의 개발자이다. 테이블에 PK가 없으면 없다고 이야기를 해야 할 텐데 오라클의 ROWID를 이용하여 PK처럼 이용하는 경우를 목격했다. 내가 "왜 설계자한테 이야기 안 하고 그렇게 개발을 하느냐"라고 물었더니 "설계자가 그렇게 만들어서..."라는 대답이 들어왔다.