최근에 아이폰, 안드로이드폰이며 모바일 환경에 급격한 변화가 일고 있다. 지금 같은 추세라면 모바일 환경이 기존의 웹 시장을 무너트릴 기세이다. 하지만 생각하는 것만큼 너무 부풀려지는 감이 없지 않다. Yes24나 강컴과 같은 온라인 서점은 보면 아이폰, 안드로이드폰과 관련한 개발 서적이 베스트 10안에 들어와 있는 것을 보면 소프트웨어 개발 업계 종사자에게 얼마나 많은 관심사가 되고 있는지 알 수 있다.

이 같은 변화의 흐름 속에 소프트웨어 개발 회사들은 모바일 어플에 집중하고 있는 것이 사실이다. 기존에 자신들의 핵심 서비스에 집중하기에도 여력이 부족한데 모바일 어플에 대한 분산 투자라.. 기존에 세워져 있던 우선 순위 또한 뒤죽박죽되고 있는 현실이다. 정말 이렇게까지 해야할까? 정말 지금과 같은 시점에 우리 개발자들은 무엇에 집중해야 할까? 이런 고민을 안고서 스터디를 진행해볼까 한다.

이런 관점에서 봤을 때 아이폰이냐 안드로이드폰이냐는 중요하지 않다고 생각한다. 필요하다면 그 시점에 준비해서 진행해도 될 터이다. 소프트웨어 개발에 있어서 진정 중요한 것은 유행을 따라가는 것이 아니라 핵심에 집중하는 것이다. 아이폰, 안드로이드폰 개발자 급구 글을 통해서 많은 것을 느낄 수 있다고 생각한다.

내가 생각하는 스터디의 방향은 단순히 스터디에서 안드로이드에 대한 기술적인 부분만을 이야기하고 싶은 생각은 없다. 현재와 같이 스마트폰이 이슈인 현재 시점에 개발자인 우리에게 정말 필요한 것이 무언인지에 대한 논의도 해보고(물론 안드로이드 어플도 만들어 보겠죠.) 더 깊이 있는 논의를 하고 싶다. 이런 방향으로 스터디를 진행한다면 참석하고자 하는 사람들이 있을까? 현재 아이폰 스터디도 진행하기 위해서 준비하고 있는데 동시에 두개의 스터디를 진행하는 것도 좋은 생각일 듯하다. 관심이 있는 분들은 덧글을 남겨주면 좋겠다. 어느 정도의 관심이 있는지 살펴보고 스터디의 진행 여부를 결정할 생각이다.

1. 자신의 직군 => 기획자, 개발자 등등
2. 경력
3. 기타 의견

위 세가지 내용으로 덧글을 남겨 주면 앞으로 스터디의 방향을 정하는데 많은 도움이 될 듯하다.

2월 1일자로 조직 개편이 되면서 프로토타이핑을 담당하는 조직을 맡게 되었다. 새롭게 진행하는 업무가 기획자의 요청에 따라 발빠르게 프로토타이핑을 할 수 있어야 하기 때문에 최대한 빨리 대응할 수 있는 기반을 만들기 위한 준비 작업을 하고 있다. 처음 개발 작업을 위한 기반 프레임워크로 Ruby on Rails, Grails, Spring Roo 세 개가 물망에 올랐다. 각각에 대하여 개발 편의성, 학습 비용, 프로토타이핑 팀 개발자 및 사내 개발자들의 지식 수준, 향후 실 프로젝트에 적용할 때의 적용 가능성 등을 고려해서 Spring Roo로 진행하기로 잠정적으로 결정하고 준비하고 있다. 이에 대한 더 자세한 내용은 같이 일하고 있는 꿈꾸는 개발자님이 더 자세하게 부연 설명 해주리라 생각한다.

직접적인 기반 준비 작업은 꿈꾸는 개발자님이 진행하고 있지만, 옆에서 지켜보면서 느끼는 Spring Roo에 대한 감정은 일단 긍정적이다. 우리는 Spring Roo의 UI 관련 기능은 제외하고 Entity 영역만 사용하기로 결정했다. 포털의 성격상 UI에 대한 변화나 요구가 많고, Spring Roo를 통하여 생성되는 JSP가 만족스러운 수준은 아니었다. Spring Controller까지 자동 생성하고 싶었지만 Ben Alex에게 문의한 결과 Controller만 단독으로 생성할 수는 없다고 한다. Spring 3.0으로 버전업 하면서 @MVC가 잘 만들어져 있어 Controller 만들기는 어렵지 않게 해결하고 있다. 이후 이 작업이 귀찮으면 Controller만 생성할 수 있는 add-on을 하나 만들어도 좋을 듯 하다.

Spring Roo를 적용하면서 가장 만족할만한 부분은 코드 생성 방식이다. Introduction To Spring Roo 1.0.0 문서에서도 설명하고 있지만 Passive Generation과 Active Generation을 모두 지원하고 있다는 것이다.

이 같은 코드 생성 방식은 roo shell을 이용하여 소스 코드를 생성하는 것도 가능하지만, 도메인 모델 클래스를 직접 변경하더라도 관련된 aj 소스가 자동으로 변경되는 것을 확인할 수 있었다. 예상하지도 못했던 부분까지 고려해서 개발되었다는 것을 보고서 놀라지 않을 수 없었다. 이 같은 기능을 지원하기 때문에 JPA Annotation과 Validation Annotation만 알고 있다면 굳이 roo shell을 사용하지 않고 도메인 모델 클래스에서 직접적인 수정이 가능하다. 이 같이 동작하는 방식에 대해서는 Spring Roo 1.0.0 Technical Deep Dive 문서에서 좀 더 구체적으로 파악할 수 있다.

아직 add-on까지 만들어 보지 못하고 Spring Roo에서 제공하는 샘플 add-on 프로젝트를 생성하고 배포해 봤는데 생각보다 쉽게 개발할 수 있을 듯 하다. 이미 add-on을 쉽게 개발할 수 있도록 roo shell에서 샘플 프로젝트까지 제공하고 있어 이 프로젝트를 참고해서 만든다면 어렵지 않게 개발하는 것이 가능하리라.

이 참에 지난 번에 만들었던 Spring Batch Monitoring System을 Spring Roo 기반으로 만들어보면 어떨까라는 생각을 했다. "Spring Batch Log야 단순 조회용도니까 지금처럼 Spring Jdbc 기반으로 개발하면 되고, 그 외의 User, Role, 통계 기능에 대해서는 Spring Roo를 적용가능하지 않을까?", "기존 Legacy Project에 Spring Roo를 적용하기 어렵지 않을까?"라는 생각으로 시도해봤는데 생각보다 쉽게 Spring Roo를 통합할 수 있었다. 물론 아직까지 기존 Legacy 테이블까지 매핑해서 개발하는 단계까지는 가지 않았지만 기존 Legacy Project에 쉽게 통합해서 일부만이라도 Spring Roo 기반으로 개발하는 것이 가능하다는 것을 확인할 수 있었다. Spring Roo에서 강조해서 이야기하고 있듯이 Spring Roo는 상당한 유연성을 가지고 있다는 생각이 들었다.

아직 프로토타이핑 업무에 직접 적용한 단계는 아니고 준비 단계이지만 만족할만한 수준이라고 생각한다. 사내 프로토타이핑 업무와 Spring Batch Monitoring System에 적용해 나가면서 Spring Roo의 허와 실에 대해서 지속적으로 공유해보도록 하겠다.