메일링에서 활동하는 사람들의 이름정도는 보셨는지 돌아가면서 간단히 소개를 하고 간단한 토비님의 소개가 이어졌습니다. 토비님은 개발을 하면서 항상 즐거움을 찾아서 했다고 하였습니다. 여기서 즐거움은 도전, 기술을 통한 감동, 새로운 기술 등을 의미하는 것이고 한창 EJB2를 하면서 Java라는 언어데 대하여 실망을 가지고 있던 터에 스프링 1에 대한 레퍼런스 문서를 그당시에는 그렇게 큰 관심을 가지지 않고 읽고 있다가 뒤통수를 맞은 것 같은 깨달음이 있었다고 하셨습니다.
EJB에서 스펙에 짜맞추어서 해야했던 개발에 쓰지도 않은 수많은 메서드를 만들어야했던 그런 복잡함을 버리고 스프링의 간결함을 보면서 Java를 처음 보았을 때는 객체지향의 매력을 다시 느끼게 되셨다고 합니다. 이런 부분은 요즘 스프링이 EJB를 넘어서서 인기를 끌고 있는 것과 같은 맥락이라고 할 수 있죠.
그리 딱딱한 자리가 아니었기 때문에 진행은 좀 자유롭게 진행이 되었습니다. 원래는 약간 고급 스프링스킬에 대해서 이야기 해보려고 하셨었는데 참석자의 대다수가 스프링을 그렇게 많이 겪어보지 않았다는 것을 아시고는 방향을 바꾸어서 스프링의 기본적인 이야기를 하기로 하셨습니다.
스프링 무엇이 좋은가??
보통 사람들이 스프링이 복잡해지고 어려워지고 있다고 불평을 하는데 전혀 공감을 할 수 없다고 하셨습니다. 공부하기가 어려운 것은 예전이나 지금이나 마찬가지고 스프링이 할 수 있는 일이 많아진 것은 사실이지만 스프링 자체의 복잡도는 전혀 증가하지 않았습니다. 스프링이라은 기술의 사용법만 가지고 익히려고 했다면 다른 기술이 나오면 새로 배워야 하고 스프링은 똑같은 기능에 대해서 너무나도 많은 선택권을 제공하고 있습니다. 물론 자기 주장이 강한 언어들이 있습니다. 특히 Ruby on Rails나 JBoss Seam같은 경우가 그렇습니다. 그들이 생각하기에 최고라고 생각하는 것 하나만의 방법만을 제공하고 있고 개빈킹은 "우리가 실제로 최고다"라는 식의 대답을 하였습니다. 이런 것은 건방져 보이고 기분나쁠 수도 있지만 선택권이 하나이기 때문에 사실상 배우기가 쉽습니다.
하지만 스프링은 완전히 다른 관점을 가지고 있습니다. 확장을 위한 연결부분만을 제공하고 있기 때문에 아무 많은 옵션을 제공하고 있고 이런 관점 덕분에 스프링 1.0시절부터 지금까지 모든 기능이 다 호환이 되고 이전의 기능을 하나도 버리지 않았습니다. 이런 것을 다 배우려고 하면 부담스럽고 너무 어렵습니다. 스프링은 다른 시각으로 접근해야 합니다. 많은 기능은 버리고 스프링이 가지는 핵심을 보아야 하는데 이말은 이게 없으면 스프링이 아니다 라고 할만한 것입니다. 이런 시각으로 바라보게 되면 스프링을 이해하는 것이 완전히 달라집니다.
스프링의 핵심은 Dependency Injection(의존성 주입)이라고 생각합니다. 다른 것들은 모두 부가 기능이고 이 모든 기능들이 DI에 의존하고 있습니다. 즉 다른 기능을 어떻게 구현할까 하는 문제를 DI로 해결한 것입니다. 모든 기능을 다 익히려고 하는 것 보다 스프링이 이 기능을 어떻게 해결하려고 했는가를 고민해 보는 것이 훨씬 낫습니다. 스프링 그 자체도 DI로 만들어졌기 때문에 그 스스로 DI입니다. 그렇기에 메가니즘적인 관점으로 스프링을 바라보면 스프링을 제대로 이해할 수 없습니다.
그리고 이건 모임후에 따로 얘기하면서 들은 얘기는 스프링은 새로운 개념이 도입되었다기 보다는 객체지향언어로서의 자바라는 언어의 기본자체로 돌아같 것이라고 하셨습니다.
Live Coding
스프링에 대한 설명 이후에 아주 간단한 코드를 가지고 설명을 해주셨습니다.
소스는 정말 기초라고 할 수 있는 JDBC로 간단한 Insert와 Select를 하는 메서드를 가진 클래스 소스를 작성하면서 시작되었습니다. 중복된 기능을 삭제하고 어떻게 분리하고 확장시켜나가는지를 설명해 주었는지를 설명해 주습니다.(다른 분들에게는 너무 기본적인 얘기였는지 모르겠지만 저에게는 딱 수준에 맞아서 참 좋았습니다. 사실상 저는 사수없이 책이랑 인터넷만 가지고 공부를 했기 때문에 놓치고 있는 부분이 많았는데 이번 세미나를 통해서 많은 것을 알게 되었습니다. JUnit같은 고급 기법만이 아니라 간단하게 main메서드를 통한 테스트를 알 수 있었고 기능을 메서드로 분리할 때 코히즌 단위로 해주는 것이 좋다고 하셨는데 지난번 켄트벡 세미나때 잘 감이 안오던 코히즌에 대해서 약간은 감을 잡을 수 있었습니다.)
커넥션 연결부분을 분리하고 커넥션만 달르게 적용시켜야할 요구사항에 맞추어서 기능확장을 설명하시면서 OCP(Open-Close Principle)의 개념이 나왔습니다. OCP는 "확장에는 열려있고 변경에는 닫혀있다"는 것입니다. 즉 변경될 필요가 있는 것은 쉽게 변경되고 변경될 필요가 없는 것은 변경 안된채로 남아있게 하는 구조입니다. 확장에서 가장 쉽게 생각할 수 있는 것은 상속입니다. 하지만 상속은 상위클래스의 기능과 밀접하기 때문에 상위가 바뀌면 하위에 영향이 매우 크기 때문에 이걸 "깨지기 쉬운 상위클래스 문제"라고 부릅니다. 이것을 컴포지션으로 해결할 수 있습니다. 인터페이스를 만들어서 클라이언트는 인터페이스를 사용하고 대신 객체를 넘겨주어야 합니다.(전략패턴) (소스를 보면서 하던 설명이라 정리하기가 쉽지 않습니다.)
어쨌든 나중에 리펙토링을 할 수 있기 때문에 한동안은 설계의 문제가 있어도 괜찮다고 하셨습니다.
개인적 생각
내용으로 정리하면 머 엄청난 내용이 없었다고 생각될 수도 있겠지만 저 개인적으로는 많은 생각을 해보게 되는 시간이었습니다. 스프링이라는 기술의 대해서 다시 생각해 볼 수 있게 되었고 제 개인발전에 대해서도 생각해 보게 되었습니다. 기술의 난이도는 낮았음에도 전의 회사에서는 공부를 하고 프로젝트때 사용하고 다시 공부하고 다시 사용하면서 어쨌든 선순환의 구조가 이루어지고 있었는데 지금은 업무를 ASP로 하다 보니 공부와 코딩의 순환구조를 따로 구성해야 했습니다. 그리고 지난 6개월을 뒤돌아보면 제가 기대하고 생각했던 것 보다 그 순환구조가 이루어지지 않았고 자기 개발은 지지부지한게 사실이었습니다.
자바를 좋아하고 중요하게 생각하면서도 성격상 많은 관심사를 가지고 있다 보니 이것도 해보고 저것도 해보고자 하는 마음에 선택과 집중이 제대로 이루어 지지 않았었습니다. 지나보니 올해 와서는 자바도 제대로 못보고 RoR도 제대로 못보고 있었다는 걸 이번 세미나에서 문득 깨달았습니다. 아니 문득 깨달았다기 보다는 내심 알고는 있었는데 어찌할지는 딱히 결정하지 못하다가 생각을 정리할 기회가 되었던것 같습니다. 그래서 현재 보고 있던(진도는 지지부진했지만) RoR을 일단 무기한 보류하고 자바와 스프링에 초점을 맞추기로 했습니다. 아직도 시간활용이나 해결해야 할 문제들은 많지만 열심히 달려봐야죠. ㅎ
Comments