최근 팀원과의 대화
언제 enum을 쓰고? 언제 state pattern을 써야 할까?
strategy pattern을 쓰는 것이랑 template-callback을 쓰는 것은 무엇이 다를까?
상속을 써야 할까? 위임을 써야 할까?
Micro Service Architecture를 적용하면 좋을 것 같은데. 운영도 좋을까?
이번 주 오랜만에 제주 출장을 가서 팀원과 이런 저런 얘기를 나누다가 최근 우리가 위와 같은 논의/고민을 하고 있다는 것이 생각났다. 그리고 팀원에게
이런 고민하는 개발 부서 얼마나 있을까?
라고 물으니...
별로 없을 것 같아요
가 답이었다. 진짜 그럴 것 같았다.
지금 있는 다음 카페는 올해로 16년 된 서비스다. 1999년에 시작되었다고 들었다. 그러다 보니 정말 오래된 코드도 서비스에 사용되고 있고, 아주 최신 기술도 사용되고 있다. 우리는 기존 기능을 변경하거나 새로운 코드를 추가할 때 다루게 되는 코드들은 깨끗하게 고치려고 노력하고 있다. 그래서 위와 같은 고민을 하는 것 같다. 사실 위 고민 중 3가지는 이미 우리 내부에서는 답을 얻었다. 마지막 MSA(Micro Service Architecture)가 아직 답이 없는 상태다.
Spring-Boot를 이용해서 MSA를 만들고 사내 클라우드에 DB를 올리고, Docker로 클라우드에서 할당받은 WAS에 배포를 하니 정말 편했다(정말 오랜만에 프로덕션 코드를 작성해서 그런지도...). 그러다 spring-boot를 이용하여 MSA로 기능을 구현하고 서비스한다면 어떨까 하는 생각이 들었다. 레거시는 아무리 지저분하게 개발되었더라도 서비스를 제공하고 있다는 것 자체만으로 존중받아야 한다고 생각한다. 하지만 기존 레거시를 변경하거나 기능을 추가할 때 레거시의 제약으로 불편함은 개발 생산성에 위해가 되는 것 또한 존중되어야 할 의견이라고 생각한다. MSA로 기능을 추가한다면 레거시로 인한 제약으로부터 자유로와질 수 있을 것 같다.
다 좋은데 MSA를 운영을 해 보질 않아서 운영 시에 어떤 어려움이 있을지 고민이 된다...
지금 생각은 일단 한번 작게 해보고 경험을 통해 느껴보고 결정하자는 쪽으로 가고 있다.
혹 MSA에 대한 경험이 있는 분들이 이 글을 보고 의견을 주신다면 정말 고마울 것 같다. ^^
어떤 분들은 MSA가 ESB, SOA의 또 다른 이름이지 않냐? 그때도 실패했으니 이번에도 그러지 않겠냐? 고 하시는 분들도 있다. 어쩌면 맞을지도 모른다. 하지만 시간이 변했고, 시도하는 사람들이 변했으니 이번엔 성공할지도 모른다는 생각이 든다. 뭐 이번에 실패하면 다음에 또 시도되지 않을까 ^^
아래는 MSA에 대한 Chris Richardson(POJO's in Action의 저자)의 자료이다.
http://plainoldobjects.com/2014/04/01/building-microservices-with-spring-boot-part1/
