작년 말부터 준비한 토비의 스프링 3 증보판이 마무리되서 지난 주말부터 인터넷 서점에서 예판을 시작했다. 실제 출간일은 이달 말이다.

이번 증보판은 스프링 3.0을 기준으로 설명한 토비의 스프링 3 내용에 스프링 3.1내용을 200여페이지 추가한 것이다. 덕분에 책을 두 권으로 분리해야 했고 두권을 합쳐 전체 페이지 수가 1700이 넘게 되었다. 분책을 하다보니 각 권만 선택해 책을 보는 독자들의 편의를 위해 앞의 부속글과 부록, 찾아보기 등이 양 권에 모두 들어가서 페이지 수가 좀 더 늘어났다.

Vol1은 예전 1부 내용에 user 예제 코드를 스프링 3.1의 DI 스타일로 업그레이드 하는 과정과 그 특징을 설명하는 내용을 추가했다. Vol2는 예전 2부의 스프링 기술 설명에 각 장마다 스프링 3.1에 새로 등장한 내용을 다루는 절을 추가했다. 스프링 3.0 내용도 일부 추가된 것이 있다. 3.0.3이후에 나온 mvc 네임스페이스의 일부 태그에 관한 설명이 MVC를 다루는 장에 추가됐다.

책이 두 권으로 분권됐기 때문에 낱권으로 구매가 가능하다. 물론 세트로 구입할 수도 있다.

그 밖에 하고 싶은 얘기가 정말 많긴 한데… 이번엔 그냥 여기까지만.

이제 드롭박스 없이 일하는 건 상상하기도 힘들다. 사내 파일서버, 이메일과 FTP 등으로 자료를 공유하고 주고 받던 고객에게 드롭박스를 소개해주니 몇 주만에 모든 업무가 다 드롭박스를 기반으로 바뀌는 것을 볼 수 있을 정도로 실무자들 사이에서도 인기가 대단하다. 직관적인 인터페이스와 안정적인 서비스, 회사 업무용 파일 정도를 주고 받기에 충분히 빠른 속도, 다양한 미디어 지원 등등.

프로젝트를 진행하면서 관련된 분석자료나 참고할 정보, 각종 설계문서 등을 드롭박스를 통해서 고객과 공유하던 중에 새로운 용도를 하나 발견했다. 서버에서 동작하는 시스템과 자료를 주고 받는 데 사용하는 것이다.

재작년부터 진행했던 프로젝트에서 회계관련 업무를 지원하기 위해서 은행의 기업용 뱅킹 시스템과 연동하는 기능이 필요했다. 단순 트랜잭션이 아닌 특별한 서비스라 그런지 호주 은행의 IT 기술의 발전이 더뎌서 그런지는 모르겠지만, 아무튼 해당 뱅킹 업무를 은행 시스템과 자동으로 연결해서 처리할 방법이 없었다. 그래서, 사람이 직접 기업용 인터넷 뱅킹 사이트에 들어가서 여러 단계의 OTP 보안을 거쳐서 필요한 정보 파일을 다운로드 받아오거나 업로드하는 작업이 필요했다. 파일 포맷은 15년 전에 은행 프로젝트 할 때나 다뤄봤던 통짜 전문이었다. 은행에 요청할 뱅킹 작업이 있으면 시스템에서 파일을 다운로드 받아서 기업용 뱅킹 사이트에 업로드 하고, 다음날 아침에 해당 요청의 처리결과를 역시 파일로 받아서 시스템에 다시 업로드하는 식으로 구성할 수 밖에 없었다

하루에도 여러번 은행 시스템에 들어가서 파일을 받아오고, 다시 사내 시스템에 로그인해서 업로드하고, 또 그 반대 작업을 반복해야 하느라 담당자가 소모하는 시간이 적지 않았다.

은행 시스템이야 어떻게 손댈 수 있는게 아니라 어쩔 수 없지만, 내가 개발했던 고객사 시스템은 뭔가 개선할 방법이 있지 않을까 고민을 해봤다. 그러던 중에 드롭박스를 이용해서 편리하게 파일을 주고 받는 것을 서버와 담당자 사이에도 적용할 수 있지 않을까하는 생각이 들었다. 그래서 찾아보니, 리눅스 서버에서 돌아가는 드롭박스 서비스가 있었다.

https://www.dropbox.com/install?os=lnx

여기에 나온 Dropbox Daemon을 이용하면 리눅스 서버에서 드롭박스를 돌릴 수 있다.

드롭박스를 이용하겠다고 생각하니 그 다음은 간단했다.

서버 시스템용 드롭박스 계정을 하나 만들고 커맨드 라인용 드롭박스 서버를 설치한 뒤에 계정을 연결했다. 그리고, 업로드용 폴더와 다운로드용 폴더를 각각 생성하고 고객사 담당자의 드롭박스 계정과 공유하도록 했다.

시스템에서 은행 업무가 필요한 시점이 되면 필요한 파일을 생성해서 드롭박스의 다운로드 폴더에 넣도록 만들었다. 그러면 담당자의 드롭박스 폴더에 파일이 들어가고, 이를 뱅킹 시스템에 업로드 해주고 폴더에서 삭제한다.

반대로 은행에서 받아서 시스템에 업로드할 파일이 있으면 담당자가 시스템 업로드용 드롭박스 폴더에 파일을 넣어주기만 하면 된다. 파일은 서버의 드롭박스 폴더에 들어갈테고, 이를 서버 시스템이 가져와 처리하도록 만들었다. 새로운 파일이 생성되는 것을 인식하는 데는 jpatchwatch(http://jpathwatch.wordpress.com/)를 이용했다. 성공적으로 처리된 파일은 백업해두고 공유 폴더에서는 삭제한다.

시스템에 들어가 파일을 다운로드 하고, 업로드하는 작업을 드롭박스 폴더에 파일을 넣고 가져오는 것으로 대체한 것이다.

서버가 새로운 파일을 생성했거나 업로드된 파일을 처리했을 때의 결과를 알리는 데는 메일이나 메신저, SMS를 이용했다. 정해진 시간 내에 통보가 오지 않고 업로드용 폴더에서 파일이 제거되지 않으면 뭔가 서버가 제대로 처리하지 않았다는 것을 알 수 있다. 물론 개발하면서 테스트할 때 빼고는 지난 2년간 그런 문제는 발생하지 않았다. 기대 이상으로 안정적으로 동작하는 편리한 환경을 구성할 수 있었다.

그 외에도 개발이나 서버관리, 유지보수를 위해서 관련 파일을 가져오거나 올릴 때도 ftp나 scp 등을 사용하는 대신 개발용으로 따로 생성한 드롭박스 폴더를 이용하니 매우 편리하다.

드롭박스 없을 땐 어찌 살았나 상상이 안되네.

http://www.infoq.com/presentations/How-We-Mostly-Moved-from-Java-to-Scala

오래 전에 들은, 36만 라인의 EJB 코드로 작성됐던 프랑스 정부의 세금신고 시스템을 단계적으로 스프링으로 전환해서 3만라인의 깔끔한 코드로 만들었다는 이야기 다음으로 흥미로운 내용이군. 유사한 점도 많다.

프로그래밍 언어와 런타임 플랫폼의 전환은 애플리케이션 프레임워크 전환과는 비교도 안될만큼 큰 비용이 든다. 언어의 패러다임까지 바뀐다면 말할 것도 없고. 매 프로젝트마다 작은 시스템을 바닥부터 다시 만들어도 그만인 소규모 팀이라면 모를까. 장기간 개발해왔고 운영중인 미션 크리티컬한 시스템을 운영중인 채로, 인력 풀도 그대로 두고, 단계적인 전환을 해야 한다면 그에 맞는 치밀하고 유연한 전략이 필요할 것이다.

기존 기술과 플랫폼을 유지한 채로 작은 변화를 만들고, 언어의 변화도 일단 기존 언어를 개발하던 습관을 크게 바꾸지 않은 채로 서서히 전환하고, 시간을 두고 발전시켜 나간 것이 성공의 이유가 아닐까 싶다.

스칼라를 세미콜론 없는 자바라고 생각하고 사용하기 시작하는 것과 같은 용기가 필요하다. 오덕들이 몰려와 비아냥 거리기 딱 좋겠지만. 뭐 어때. 자바를 자바답게 쓰기 시작한 건 얼마나 됐나.

자기 잘난 거 증명하려고 코딩하는 해커가 아니라면, 개발자는 적절한 기술을 이용해서 고객의 문제를 해결하고 가치를 만들어내는 것이 가장 큰 관심이어야 할 것이다. 그런 면에서 스칼라와 같은 많은 장점이 있는 언어에 관심을 가지는 것도 필요하고, 동시에 욕심을 내지 말고 무식한 방법처럼 보이더라도 작은 단계를 거쳐서 변화를 시도하는 것도 중요할 듯.

제대로 적용할 기회도 못 만들면서 이런 저런 언어를 찝적거리는 것은 그만하고 스칼라에 올인해볼까. 흠흠.