로드 존슨 쓴 책을 조금 읽었다. Pragmatic이라는 단어도 나오지만, 그의 접근 방식은 그야 말로 실용적이다. 그의 아들, 스프링(Spring)도 그대로 닮아 있다. AOP라는 새로운 기술1을 채용하는데 있어서 스프링이 취하는 방식은 실용적인 것이 무엇인지 그야말로 제대로 보여준다.
스스로 실용주의를 동경하기 때문에 실용주의 프로그래머라는 책을 곁에 두고 있다. 하지만 일터에서 진정한 실용주의자가 되기란 쉬운 일이 아니다.
C라는 인물이 있다. 그는 하이버네이트라는 ORM이 워낙에 좋다고 하여 프로젝트 공통코드(혹은 프레임워크)에 이를 적용했다. 그런데 개발자들이 온통 불평이다. 이해할 수가 없다. 그런데 만일 함께 일할 개발자들 모두가 하이버네이트를 처음 쓰는 상황이라면 어떠한가? 그 뿐 아니라 자바 문법만 알 뿐, 객체에 대한 개념도 없는 상황이라고 한다면 C가 불평할만한 상황일까? 툴은 좋은데 개발자가 문제라는 대답은 전혀 실용적이 아니다.
K라는 인물이 있다. 그는 ActiveX를 쓴 웹을 너무나도 싫어했다. 왜 웹 표준을 쓰지 않고 그 따위(?) 기술을 쓰는지 이해할 수가 없다. 그는 ActiveX로 화면 개발하는 일은 자신의 커리어에 전혀 도움을 주지 않아 시간 낭비라고 생각했다. 그렇다고 그는 대안을 내놓을 수 없다. 이런 태도는 실용주의와는 정반대에 서 있는 모습이다.
가상의 이야기가 아니라 실존 인물 이야기를 해보자. A씨는 개발팀 대부분이 객체에 대한 개념이 없는 곳에서 설계 방안을 고민하고 있다. 더군다나 CBD를 적용하자고 하는데 고객이나 개발팀 대다수가 CBD에 대해 합의한 적은 없다.(아니, 합의 따위가 필요없다고 생각하는 듯 하다.) 단순히 CBD를 하면 '컴포넌트'(?)로 개발하니까 유지 보수에 좋지 않겠느냐 정도일까?
A씨는 팔을 걷어 붙이고 일을 해보고 싶지만, 상황이 그리 녹록해보이지는 않는다. 객체를 기반으로 하는 설계에는 경험이 전혀 없는 사람들로만 설계자를 뽑았다. 비즈니스 로직은 if문과 SQL로만 작성하는 것으로 아는 사람들에게 클래스 설계는 파일 분할과 다를 것이 없다. 게다가 과반수 이상은 자바 플랫폼에 대한 이해가 전혀 없다. 결과적으로 CBD 기반은 커녕 객체 기반 설계서는 기대하기 힘들다. A씨 입장에서 그들이 객체 지향의 설계를 하게 한다는 것은 그야말로 전도에 해당한다. 새로운 것을 배울 의지가 없는 사람들에게 패러다임 전환이라고 할 만큼 지대한 변화를 수용하라는 것은 무리한 요구다. Technical evangelist의 의미가 떠오르는 상황이다. 설계서를 만들 수 없는 설계자들은 남는 시간2에 무엇을 할까? A씨의 경험에 따르면, 그들은 무엇가 비슷한 것을 만들려고 노력하며 시간을 보낸다.
A씨는 그 일이 벌어지지 않게 노력하는 것에 초점을 맞췄다. 아니. 막을 수는 없을 것 같아서 요식 행위가 가능한 실제 설계 작업과 비슷해지도록 할 참이다. 자주 했던 일인지라 방안을 찾는 것은 그리 어려운 작업이 아니다. 문제는 실용주의하고는 전혀 거리가 먼 잣대로 프로젝트를 진단하는 외계인들을 대비하는 일이다. 당장에는 유익한 작업이라고 설계서 형식을 바꾸고 설계 방식을 변경하지만, 훗날 실정을 전혀 모르는 감리사3의 혹평으로 인해 개발팀이 고생할 수 있다. 그래서, 전혀 실용적이지 않은 기준과도 조우할 수 있도록 근거를 만드는 일이 도리어 실용적이게 된다.
그렇게 그렇게... 하루는 간다. 그 하루 속에서, 하루를 마감하며 읽어던 책 구절에서, 그 책의 내용을 자신의 목소리로 이야기해주던 사람에 대한 기억을 통해서, 아침에 들었던 오디오북에서... 실용주의가 무엇인지 배울 수 있었다. 배움이란 참 더딘 일이다.
스스로 실용주의를 동경하기 때문에 실용주의 프로그래머라는 책을 곁에 두고 있다. 하지만 일터에서 진정한 실용주의자가 되기란 쉬운 일이 아니다.
C라는 인물이 있다. 그는 하이버네이트라는 ORM이 워낙에 좋다고 하여 프로젝트 공통코드(혹은 프레임워크)에 이를 적용했다. 그런데 개발자들이 온통 불평이다. 이해할 수가 없다. 그런데 만일 함께 일할 개발자들 모두가 하이버네이트를 처음 쓰는 상황이라면 어떠한가? 그 뿐 아니라 자바 문법만 알 뿐, 객체에 대한 개념도 없는 상황이라고 한다면 C가 불평할만한 상황일까? 툴은 좋은데 개발자가 문제라는 대답은 전혀 실용적이 아니다.
K라는 인물이 있다. 그는 ActiveX를 쓴 웹을 너무나도 싫어했다. 왜 웹 표준을 쓰지 않고 그 따위(?) 기술을 쓰는지 이해할 수가 없다. 그는 ActiveX로 화면 개발하는 일은 자신의 커리어에 전혀 도움을 주지 않아 시간 낭비라고 생각했다. 그렇다고 그는 대안을 내놓을 수 없다. 이런 태도는 실용주의와는 정반대에 서 있는 모습이다.
 | 실용주의 프로그래머 -  앤드류 헌트 외 지음, 김창준 외 옮김/인사이트 |
가상의 이야기가 아니라 실존 인물 이야기를 해보자. A씨는 개발팀 대부분이 객체에 대한 개념이 없는 곳에서 설계 방안을 고민하고 있다. 더군다나 CBD를 적용하자고 하는데 고객이나 개발팀 대다수가 CBD에 대해 합의한 적은 없다.(아니, 합의 따위가 필요없다고 생각하는 듯 하다.) 단순히 CBD를 하면 '컴포넌트'(?)로 개발하니까 유지 보수에 좋지 않겠느냐 정도일까?
A씨는 팔을 걷어 붙이고 일을 해보고 싶지만, 상황이 그리 녹록해보이지는 않는다. 객체를 기반으로 하는 설계에는 경험이 전혀 없는 사람들로만 설계자를 뽑았다. 비즈니스 로직은 if문과 SQL로만 작성하는 것으로 아는 사람들에게 클래스 설계는 파일 분할과 다를 것이 없다. 게다가 과반수 이상은 자바 플랫폼에 대한 이해가 전혀 없다. 결과적으로 CBD 기반은 커녕 객체 기반 설계서는 기대하기 힘들다. A씨 입장에서 그들이 객체 지향의 설계를 하게 한다는 것은 그야말로 전도에 해당한다. 새로운 것을 배울 의지가 없는 사람들에게 패러다임 전환이라고 할 만큼 지대한 변화를 수용하라는 것은 무리한 요구다. Technical evangelist의 의미가 떠오르는 상황이다. 설계서를 만들 수 없는 설계자들은 남는 시간2에 무엇을 할까? A씨의 경험에 따르면, 그들은 무엇가 비슷한 것을 만들려고 노력하며 시간을 보낸다.
A씨는 그 일이 벌어지지 않게 노력하는 것에 초점을 맞췄다. 아니. 막을 수는 없을 것 같아서 요식 행위가 가능한 실제 설계 작업과 비슷해지도록 할 참이다. 자주 했던 일인지라 방안을 찾는 것은 그리 어려운 작업이 아니다. 문제는 실용주의하고는 전혀 거리가 먼 잣대로 프로젝트를 진단하는 외계인들을 대비하는 일이다. 당장에는 유익한 작업이라고 설계서 형식을 바꾸고 설계 방식을 변경하지만, 훗날 실정을 전혀 모르는 감리사3의 혹평으로 인해 개발팀이 고생할 수 있다. 그래서, 전혀 실용적이지 않은 기준과도 조우할 수 있도록 근거를 만드는 일이 도리어 실용적이게 된다.
그렇게 그렇게... 하루는 간다. 그 하루 속에서, 하루를 마감하며 읽어던 책 구절에서, 그 책의 내용을 자신의 목소리로 이야기해주던 사람에 대한 기억을 통해서, 아침에 들었던 오디오북에서... 실용주의가 무엇인지 배울 수 있었다. 배움이란 참 더딘 일이다.
이올린에 북마크하기
이올린에 추천하기
