(본 글은 2016년 7월 브런치 글을 옮겨온 것입니다.)
혼자 풀스택으로 사업과 개발을 같이 진행하며 가장 고민이었던 것은, 내가 도대체 어디를 개발하고 있지? 라는 의문이다. 전체적인 아키텍트가 없이 무턱대고 Fullstack Framework만 믿고 신나게 개발을 하다가 문득 돌아보면 전혀 진도가 나가지 않았다. 이상하다, 분명 작년 말에는 프로토타입이 나왔어야 했는데 벌써 반 년이나 지체됬다. 물론 회사를 운영하며 예상치 못한 paperwork가 주된 원인이겠지만 개발을 하면서 발생한 전혀 예상치 못했던 것들에 대해 내가 너무 큰 시간을 할애해서 해결하려고 한 것이 더 큰 원인인 것 같다.
오래전 SI시절에는, PM이나 PL이 작성한 문서라던가, 길어야 일주일 정도의 교육만 받으면 실무에 투입되서 개발이 가능했다. 정말 내가 이해하지 못한 범주에 있더라도, Spring 2.5를 쓰던 시절, 선임이 개발해둔 MVC구조를 그대로 본따다가 UI에 폼 몇개와 모델만 바꿔서 새로운 서비스 추가가 가능했다. 즉, Copy-and-Paste를 한 셈이다. 그렇게 오픈하고, 나중에 데이터가 꼬이면 그때가서 부랴부랴 밤새서 서비스를 수정하곤 했는데 어쨌든 중요한 것은 기본적인 설계가 잘 되어 있으니 서비스 하나 추가하는 것도 (완벽하진 않더라도) 이리 쉽게 되었다는 것이다.
그런데 상황이 바뀌었다. 솔직히 말해서 프리랜서 생활을 하며 진행한 두세가지 프로젝트 모두 딜레이 되었었다. 이유는 물론 Unexpected Exceptions이라고 칭하고 싶지만, 지금와서 돌이켜보면 약간 무식한 완벽주의에서 온 것이 많다는 느낌이다. 실제로 서비스는 오픈도 안했는데 벌써부터 MITM(Man-In-The-Middle) 공격도 걱정되고, SSL도 적응 안됬으니 암호화도 걱정되고, MySQL의 password함수는 뚫렸다는데 비번 암호화도 걱정되고.. 보안적인 부분 뿐만 아니라 간혹 보다보면 내가 왜 이런 Aggregation/Composition을 가지고 있지, 왜 이 DB스키마 상에서 정규화가 제대로 되지 않았을까. 왜 쓸때없이 N:N관계가 들어갔을까.. 이런 부분을 수정하다 보면 예상 기일을 훌쩍 넘김은 물론, 심지어 모 프로젝트는 개발이 제때 되지 않아 취소될 위기까지 있었다. 모든게 다 내 개발적인 ‘욕심‘ 탓인 것이다.
그런 내가 지금은 스타트업까지 하며 제품을 혼자 개발한다. AngularJS등의 프론트 기술에 약해서 러닝커브도 상당히 들어가며 시간소요가 됬고, 백엔드 개발을 하며 RestAPI 구조를 이해하며 빼다 보니 CORS/CSRF/Token 도 이해하고 적용해야 했다. 괜시리 Scala의 Future나 Promise이 웹 구조상 적합해 보여서 여기다 Slick까지 써다가 모든걸 비동기 처리를 했다. 물론 이 과정에서 일단 스칼라가 익숙하지 않아서 시간이 소요되고, Slick의 JPA같은 모델이 잘 이해가 안되서 시간이 소요되고.. 다행히 사업 초반이라 그렇게까지 딜레이 되지는 않았지만, 이대로 가다가는 개발이 전혀 안될 것이라는 생각이 들었다.
왜 이런 상황이 발생했던 것일까, 우선 내가 맹목적으로 풀스택 프레임워크를 믿었던 자체도 있다. 오픈소스가 넘쳐나니 잘 관리할 것이라 생각하고 이리저리 덕지덕지 붙혔다. 그러다 의존성 관리가 안되 다시 Bower니 gradle이니 sbt니 이런걸 배우고 다시 개발한다. 그래도 전혀 통일된 규격이란 존재하지 않았다. 결국 공부가 필요했다. 아무리 개발을 수년간 했다 해도 Ajax에서의 비동기가 아닌 서버단에서의 비동기나 Queue방식은 잘 이해가 가지 않는다.
초반에 설계했던 유라임의 라이브러리 의존 관계도. Too Much라는 생각.
가장 중요한 것은 아키텍처 문서가 없던 것이다. 지난번 나는 조대협님의 ‘대용량 아키텍처와 성능 튜닝’ 이란 책을 보면서 내가 개발을 한답시고 이런 설계 문서하나 빠져있는 것이 참으로 난해했다. 개발을 하겠다는건가 말겠다는건가? 그저 무턱대고 “하면 되겠지” 하며 개발환경이며 CI/CD환경이며 다 구축을 해두면 뭐하나, 그 흔한 문서하나 없는데. 기껏해야 IP들과 계정 정리된 에버노트 페이지, ERD, UI 프로토타입 그리고 Business Plan이 전부였다. 정말 이런 상황에서 지금까지 어느정도 개발을 해왔다는 자체가 신기할 정도이다.
개발중인 “유라임”의 개발환경과 CI/CD환경. 모든 서비스 설치와 연동을 완료했지만 정작 문서가 너무나도 전무하다.
그래서 정말, 이대로 개발을 하다간 프로토타입 하나 나오지 못하고 프로젝트가 산으로 가겠구나 라는 생각이 들었다. 그래서 다시금 책을 정독하며 아키텍처 설계를 하기로 마음먹었고, 지난주부터 약 10일동안 삽질한 끝에 어느정도까지는 만들어냈다.
아키텍처 설계의 시작
시작은 순탄치 않았다. 우선 책에 나온대로 보면 Business Architecture와 System Architecture가 필요했다. 나는 ERD를 제외하고는 System Architecture가 아에 없었고, Business Architecture는 Business Plan으로 퉁치기에는 보통의 사업계획서가 그렇듯이 후자가 너무 방대했다. 그래서 결국 새로 만들 수 밖에 없었다.
유라임의 비즈니스 아키텍처 썸네일.
사업이 진행중인 관계로 공개하기는 힘들지만, 대충의 Flow는 1) 요약 2) 제품 3) 마켓분석 4) Core Functions 5) 도메인 모델 6) 전체 아키텍처 7) 마일스톤 8) 팀 정도로 요약할 수 있겠다. 특히 Core Function에 대해서, 다시금 JIRA에 옮기기 쉽게 User Story 방식으로 As a <type of user>, I want <some goal> so that <some reason>. 로 작성했다. 이 과정에서 일단 핵심 Components가 나뉘어 졌고, 각각에 대해 전체적인 연동 관계를 다시금 도식화해서 표현해봤다. 그리고 프로토타입/버전1/버전2/버전3 정도까지 해서 약 5년정도의 기간을 가지고 중요도를 나누고, 이에 대해서 Plan을 작성해봤다.
유라임의 향후 팀 구성
특히 이 과정에서 조직구성에 대해 생각해봤다. 일단 나는 팀을 확장한다는 자체를 아에 생각해 보지 않았는데, 절대 프로젝트는 혼자할 수 없다는 것을 최근들어 점차 느끼고 있다. 그럼 언젠가는 조직을 확장해야 할 테인데, 어떤 팀을 가지고 갈 것인가.. 라고 해봤을 때, 어차피 나는 직급이나 그런건 관심은 없고 전체적인 관계가 자신의 책임 위주로 돌아갔으면 좋겠다는 생각이다.
구글의 조직도 도식화. 색깔=서비스 로 서비스 단위로 나뉜다.
여러 기업문화를 확인해 본 결과, 구글의 그것이 내게는 매력적으로 느껴졌다. Product단위의 책임전가, 사실 내가 설계한 조직도 상에는 디자인팀이 타 팀의 세부 업무를 서포트 하는 식으로 되어 있는데, 사실 이것도 정확히 따지면 맞지는 않다. 허나 나는 조금 더 시스템화 된 디자인팀이었으면 좋겠고, 독립된 UI Components를 만들 수 있는 팀이었으면 하는 생각이다. 그렇게 전체적인 디자인 규격은 통일되게 가져가는 것이 좋다는 생각에서 별도로 빼봤다.
그런데 중요한건 팀 구성은 크게 지금, 그리고 최소한 올해동안은 별로 필요하지 않다. 중요한 것은 어떤 컴포넌트를 핵심으로 가져갈 것이고, 정말 어떤 부분이 나(글쓴이)의 역량 밖이라 그쪽의 전문가를 필요로 할 것인가, 그것을 이해하는데에 있어서는 큰 도움이 되었다. 그래서 부족하다 느낀 디자인이나 아키텍처, 보안과 관련된 팀은 꼭 필요하겠다고 느꼈다. 그렇게 되니, 적어도 지금 내가 프로토타입을 개발하면서 끙끙대지는 않아도 될 것이라는 생각을 하니 한결 마음이 편해졌다.
시스템 아키텍처 설계
그렇게 약 4일정도 비즈니스 아키텍처를 끝내고 시스템을 설계하기 시작했다. 어떻게 보면 기존에 개발하던 것들을 도식화 하는 것에 불과하니 금방 될 것이라 생각했지만, 거의 1주일이라는 시간이 들었다. 전체적인 목차는 아래와 같다.
1. APPLICATION ARCHITECTURE
STATIC ARCHITECTURE
DATA&ACTION FLOWS
DETAIL ARCHITECTURE
PROTOCOL DEFINITION
MESSAGE EXCHANGE PATTERN
REST API DESIGN
2. TECHNICAL ARCHITECTURE
DEVELOPMENT ENVIRONMENT
BIG DATA PROCESSING
DEPLOYMENT ARCHITECTURE
NETWORK ARCHITECTURE
FRAMEWORK ARCHITECTURE
3. DATA ARCHITECTURE
DOMAIN MODEL
ENTITY-RELATIONSHIP MODEL
NOSQL DESIGN
모든것이 책에 나온대로 따라갔기 때문에 목차는 쉽게 구성이 되었다. 하지만 일단 당장 필요없는 것들을 가지치기 할 필요가 있었다. 예컨데 구글 클라우드를 사용하면서 일단 서버 사양이나 네트워크 같은것은 고려하지 않았다. 그런 진짜 Bear-metal 서버용 아키텍처를 제외하고 정말 내게 필요한 것 위주로 제작을 해나가기 시작했다.
가장 중요한 것은 컴포넌트의 구분을 명확히 하고, 데이터를 정확히 정의하고 이에 대한 관계를 명확하게 도식화 하는 것이다. 개발하면서 몇번이나 기존에 만든 컴포넌트로 인해 헷갈리는 부분이 있었다. 한 예로 사용자의 Open API의 API Key를 관리하는 측면에서, SNS Key와 Healthcare(Fitbit같은) API Key에 대해, 물론 최근에야 OAuth 2.0으로 많이 통일화되어 있는데도 다른 DB에 저장했다. (전자는 Account DB, 후자는 API DB) 이러다 보니 실제 서비스와 DAO자체도 두개가 만들어지고, REST URL까지도 두개가 나오니 프론트조차 두개를 만들어야 했다. 나중에 이해를 하고 부랴부랴 수정을 했는데, 이를 이해하기 위해서는 다시금 종이에 전체 아키텍처를 그려보거나 Forward Engineering을 해서 분석해서 수정할 수 밖에 없었다.
사실 그게 내게는 가장 크나큰 문제점이었기 때문에 이번 설계에서 가장 큰 핵심이었다. 전체 컴포넌트를 Tier단위로 3단계 정도로 구분하고, 여기서 발생하는 데이터의 유기적 흐름을 따져보니 어떤 모델이 필요한지와 모델이 어떤 컴포넌트와 관계를 가져야 할지가 보이기 시작했다. 결국 이 과정에서 MVC에 해당하는 컴포넌트 영역이 정리가 됬으며, 모델이 정리되면서 ERD또한 정리가 되었다.
그래서 이렇게 정리된 문서들을, 물론 keynote를 주로 사용했지만, 캡쳐를 하던 어떻게 하던지 간에 Confluence에 정리를 했다. 예전엔 Redmine을 썼는데, Confluence도 플러그인이 많아서 재밌다. 그리고 비로서 나중에 누군가 프로젝트에 참여를 했을 때, 보여줄 수 있는 무언가가 생겼다. 아니, 적어도 내가 헤메지 않을 그러한 웹 문서 말이다.
Atlassian의 Confluence는 사용하면 할수록 훌륭한 Wiki인 것 같다.
일차적 아키텍처를 마치며
그렇게 지금은 상세설계를 진행하고 있다. 프로토타입 이전까지 나와야 할 컴포넌트에 대해 내가 꼭 필요한 것들인 1) 기능정의 2) 프로시저 3) UI/UX Prototype 4) Data Flow 5) Related Data Model 정도를 개별 컴포넌트마다 정의하고 있다. 그런데 이것까지 완성하고 개발하면 제품이 전혀 나올 것 같지 않아서 일차적으로 여기서 손을 놓았다. 개발하면서 시간날 때마다 틈틈히 해야겠다는 생각이다.
말 그대로, 일차적인 아키텍처를 마쳤다. 그러면서 계속 머릿속으로 떠오른 질문은, “완벽한 아키텍처라는게 있을까?” 라는 생각이다. 그리고 과연, 소프트웨어가 그 완벽한 아키텍처 내에서 나올 수 있을까 라는 생각. 나름대로 나도 10일을 투자하며 큰 흐름을 잡고 부족한 부분을 고쳐나가긴 했지만 일단 상세설계도 없어서 살짝은 “내가 뭐한거지?” 라는 생각도 들더라. 하기사, 돌이켜보면 그간 참여했던 프로젝트에서도 PM이나 기획자들이 수시로 설계를 변경하며, 약간은 점진적 모델로 개발을 하곤 했었다. 결국 완벽할 수는 없는데, 자꾸만 나는 완벽을 추구하고 있다.
결국 어디에도 답은 없다. 완벽한 프로덕트가 나올 것이라는 생각도 버려야한다. Devops의 큰 기능인 빠른 피드백과 개발, 대응 만큼 스타트업의 그 아키텍처는 기존의 개발보다는 더 빨라야 하지 않을까. 하지만 혼자 개발을 하면 설계를 하면 설계를, 개발을 하면 개발을 하지 둘다 동시에 하는 자체는 너무나도 큰 에너지가 소비가 되고 실제로 잘 되지도 않는다.
그러니 쳐낼 것은 쳐내야 한다. 나도 지금의 상세 설계도에서 UI/UX Ptototype은 정말 대충 만들 수 밖에 없고, Model은 큰 모델을 가지고 지속적으로 공유하며 사용할 수 밖에 없다. Data Flow와 프로시저는 결국 프로그램의 핵심 알고리즘이기 때문에 어쩔 수 없이 디테일하게 설계를 해야 한다. 이게 제대로 안되면 프로그램을 개발하는 속도 자체가 너무나도 줄어들기 때문이다. 그나마 UML이나 Class Diagram같은 것들은 없으니 이런 OOP적인 문제는 머릿속에서 돌아가야 한다는 것이다.
앞으로 하는 개발의 Step-by-Step
1) 상세 아키텍처 설계
전체 흐름이 있으니 해당되는 데이터 모델 설계
프로시저(알고리즘) 설계
UI/UX Prototype
2) 모델 개발 (모델설계 참조)
DB스키마 제작
Model 설계/제작
REST API 설계/제작
Frontend에서 사용할 Model개발
3) 로직 개발 (UI, 프로시저 참조)
Backend의 Controller/Service/DAO 개발
Frontend View/Controller 개발
4) 테스트 (이것도 언젠가는 테스트 케이스를 개발해야 할텐데..)
열심히 REST 테스트, 바인딩 테스트, DB에 들어간 정보 테스트 등등..
나도 사실 브런치에 포스팅을 하기 전까지는 “완벽한 프로토타입을 만들고 포스팅을 시작해야겠다” 라고 생각했는데, 그러다 보니 정말 세월아 네월아 하더라. 빨리 내놓고 QA를 받을 수 밖에. 그러니 결국 쳐낼 것은 쳐내야 한다. 고로 스타트업은, 완벽주의적 성향을 부릴 수는 없다는 것.
어쨋든, 아키텍처에 대해서는 끝없이 공부할 필요가 있다는 것은 많이 느낀 것 같다. 앞으로도 열심히 보안해 나갈 수 밖에 없다는 것, 그리고 나중에 조직이 커진다면 아키텍처는 꼭 필요하다는 것. 그것을 느끼게 해준 그간의 아키텍처 설계 모험이었던 것 같다.
(6/28 추가)
몇몇 분들이 테스트 관련하여 피드백을 주셨는데, 저 또한 테스트가 중요하다고 생각합니다. 하지만.. 이제 막 설계도 위의 글처럼 초보단계에 불과하기 때문에 테스트 자동화와 관련하여 더 깊게 공부하고 반영을 해야 하는데, 프로토타입 전까지는 그럴 충분한 시간이 없기 때문에 이후 리펙토링 과정에서 Test Case를 제작하려고 생각하고 있습니다. 사실 QA는 깊게 공부도 하지 않아서 앞으로 공부해야 할 중요한 부분 중 하나이기도 합니다.. 더불어 개인적으로는 되려 이러한 아키텍처도 없어서 개발이 자꾸만 산으로 가서 먼저 아키텍처를 고민했고, 어느정도 상세설계가 되면 테스트 케이스를 만드는 것도 수월할것이라고 개인적으로는 생각하였습니다.
아직은 한참 부족한 제 생각을 ‘정리’ 하는 차원에서 작성했다고 생각해 주시고, 글을 읽어주셨으면 좋겠습니다 🙂
글쓴이 메튜장 | [email protected] | http://www.matthewlab.com
