안녕하세요, 디어코퍼레이션 물류팀 개발리드 김명재입니다. 2022년 5월에 이 회사에 입사한 이후에 조직의 제품 개발 생산성을 높이기 위해 고군분투하고 있습니다. 5개월이라는 길지 않은 시간이었지만 개발 프로세스를 정비하고 효율을 높이기 위해 도입했던 절차와 아이디어들을 공유하고 싶습니다.Shape Up“… 생각할 시간이 부족해요.”디어 물류팀의 첫 번째 필드테스트(개발한 제품을 물류 주선사의 직원분들에게 제공해서 사용자 반응을 관찰)와 지금까지의 개발 방식을 회고하면서 개발자들이 모두 동의했던 문장입니다. 개발 방식에 어떤 변화가 필요할지 고민하던 중에 은성이(물류팀 개발자)가 Shape Up이라는 개발 방법론을 들고 왔습니다.첫 인상Shape Up은 개발 방법론이면서 책 이름이기도 합니다. 이 책은 웹에 무료로 공개되어 있고 pdf로 받아볼 수도 있습니다. 저는 Introduction을 읽으면서부터 강렬한 인상을 받았습니다.Ruby on Rails첫 번째 강렬한 인상은 Ruby on Rails가 Basecamp라는 프로덕트를 만들면서 탄생한 부산물이라는 것입니다. Ruby on Rails의 핵심 철학인 ‘Convention over Configuration’은 Spring Boot가 탄생하는 데 큰 기여를 했습니다.- Convention Over Configuration: Rails has opinions about the best way to do many things in a web application, and defaults to this set of conventions, rather than require that you specify minutiae through endless configuration files.- https://guides.rubyonrails.org/getting_started.htmlBasecamp는 회사 이름인 동시에 프로덕트 이름입니다. 2003년에 Basecamp(회사)는 웹사이트 디자인을 하는 컨설팅 회사였습니다(At the time we were a consultancy designing websites for clients).일을 하면서 고객, 디자이너, 프로젝트 매니저 간의 의사소통에서 발생하는 정보 파편화와 문제를 겪었고, Basecamp는 이 문제를 해결하기 위해 정보를 한곳에 모을 수 있는 제품을 만들었습니다. 많은 회사가 동일한 문제를 겪고 있었고 오늘날에는 수백만 명의 사람들이 다양한 업종에서 Basecamp를 사용하고 있습니다.Basecamp의 첫 번째 버전은 Basecamp 설립자인 Jason Fried, 공동 설립자이자 프로그래머인 David Heinemeier Hansson, 그리고 디자이너인 Ryan Singer가 만들었습니다. David는 당시 Basecamp에 주당 10시간밖에 할애할 수밖에 없는 상황이었기 때문에 Basecamp는 코딩할 수 있는 10시간을 최대한 생산적으로 사용해야만 했습니다.10시간의 제약조건을 극복하기 위해 Basecamp는 해야 할 일의 범

CTO 님으로부터 레거시 시스템 컨버팅 과정에 관한 기술 블로그를 작성해보는 것은 어떠냐, 하는 제안을 받았습니다. 순간 1년이 꼭 10년 같았던 고난과 좌절, 그리고 환희의 순간들이 주마등처럼 머리를 스쳐갔습니다. 그 대장정의 이야기 보따리를 하나씩 짚어가며 풀어나가 보겠습니다. 1. 레거시 시스템 현황 파악 2019년 6월 4일 화요일, 딸의 생일 다음 날, 동대문을 시스템화 한다는 거대한 꿈을 가지고 있는 회사에 부푼 마음을 안고 힘차게 첫 출근을 했습니다. 무슨 일부터 해야 할까요? 일단 소스 보면서 구조부터 파악하시면 될 것 같습니다. 네! 알겠습니다. 여러 모듈이 있던데 git 주소 좀 알려주세요~. 네. XX와 XX의 git 주소는 OO 이고요, XX와 XX의 FTP 주소는 OO 입니다. !! FTP. 마지막으로 이 단어를 들었던 순간이 언제였을까 한참 생각해보았습니다. 조금 과장을 보태면 아마도 구한말 순종 8년 때 마지막으로 듣고 못 들어본 단어였습니다. 형상 관리부터 심상치 않음을 느낀 저는 떨리는 마음으로 한가지 질문을 추가했습니다. 그. 그럼 모바일이랑 웹에서 사용하는 API 소스는 그 중에 어느 것일까요? 모바일 API 주소는 XX, 웹 API 주소는 OO, 관리자 API 주소는 KK 등등 블라블라 입니다. !!!! 뭐. 뭐지. 왜 API 주소가 모조리 나뉘어 있는 거지. 좀 구식이지만 MSA(Micro Service Architecture)로 구현한 형상관리인가 이런 저런 의문과 두려움을 품은 채 소스를 하나씩 분석해 나가기 시작했는데, 결과는. 절망이었습니다. 그 이유를 한가지 예를 들어 설명해보겠습니다. 어떤 상품의 상세 정보를 반환 하는 API가 있다고 가정하면, 일반적으로 그 API 하나를 작성하고 나면 그것을 사용하는 매체는 모바일이나 웹, 플랫폼 상관없이 호출할 수 있고 인증 부분만 다른 구조를 가질 것입니다. 그러나 이 레거시 시스템은 모든 매체에 따라 API 서버, 소스가 모두 나뉘어져 있었습니다. DB에 어떤 테이블에 컬럼이 하나 추가되었다고 가정하면 관련된 API만 수정하면 되는 게 일반적인데, 이 시스템에서는 해당 컬럼과 관계된 모든 부분을 같은 코드로 수정해야 하는 안타까움이 존재하고 있던 것입니다. (실제로 2019년 7월경에 약간 복잡도가 있는 모듈을 개발한 경험이 있었는데, 그 때 자칫 잘못하면 소스 수정하다가 공황 장애가 올뻔했습니다.) 비슷하면서도 살짝 씩 다른 소스를 계속 수정하다 보니 데자뷔 같기도 하고, 8중 if 문을 따라 들어가다가 길을 잃고 림보 상태에 빠졌다가 겨우 현실 세계로 돌아온 경험도 있었습니다. 위대한 수학자이자 철학자 피타고라스께서는 이런 상황에 대해서 아래와 같은 말을 남겼습니다. 내가 보기엔 이건 답이 없다. - 피타고라스 - 빛이 보이지 않는 상황이었습니다. 설상가상으로 서버는 AWS가 아닌 다른 서비스를 사용하고 있어서 오토 스케일링 같은 유연함도 없었고, 어떤 서비스는 상용 서비스임에도 불구하고 서버 1대로 운영하는 깡(?)을 보여주기도 하였습니다.

안녕하세요? 리멤버를 개발하는 드라마앤컴퍼니 서버/웹팀의 서버 개발자 이한별입니다. 저는 Spring Framework 로 제품 개발을 3년 정도를 했습니다. 이후 최근 11개월동안은 Rails 로 제품 개발을 하고 있습니다. Spring 개발자가 왜 Rails 에 관심을 갖게 됐는가? Spring, 특히 Spring Boot 라는 Framework 에 부족함을 느끼지 못했습니다. 그런데 왜 지금 리멤버를 서비스하고 있는 드라마앤컴퍼니에 와서 Rails 로 개발을 하고 있는지를 떠올려봅니다. 언제인지 정확한 기억은 나지 않지만, Ruby 의 기초를 공부한 적이 있었는데 문법이 저랑 잘 맞을 것 같단 느낌과 함께 마냥 긍정적인 시각이 생겼습니다. 많은 현대 Web Framework 들에 영감을 준 Ruby on Rails 에 대해서도 궁금증이 생 겼습니다. 그 이후, 기회가 되면 Ruby 로 개발해보면 재밌겠다라는 생각이 들었고, 드라마앤컴퍼니로 이직하는 것이 계기가 되어 Rails 로 개발을 하고 있습니다. 이 글에서는 Spring 으로 개발하던 사람이 Ruby on Rails 로 개발을 해보고 난 후 드는 생각들을 정리해봤습니다. Ruby on Rails 프레임워크의 철학 Ruby on Rails 는 MVC 패턴 기반의 개발을 빠르고 편리하게 해주는 Web Framework 이며, Rails 의 철학은 아래 두가지의 주요한 가이딩 원칙을 바탕으로 하고 있습니다. – DRY(Don’t Repeat Yourself) – CoC(Convention over Configuration) – Spring Boot 가 나오게 된 배경도 Spring MVC 만을 사용할때 비즈니스 로직보다 설정에 관련된 코드를 많이 작성해야했기 때문인 점과 일맥상통하다고 볼 수 있습니다. The Rails philosophy includes two major guiding principles: Don't Repeat Yourself: DRY is a principle of software development which states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." By not writing the same information over and over again, our code is Convention Over Configuration: Rails has opinions about the best way to do many things in a web application, and defaults to this set of conventions, rather than require that you specify minutiae through endless configuration files. from Ruby on Rails 공식 가이드 Ruby on Rails 의 강점 위