이번엔 지금 직장에 입사 했을 때부터 지금까지 개발을 하면서 회사의 개발환경에 각각 인프라와 개발 방법, 협업나눠서 느낀점과 과거, 현재 상황, 그리고 이번에 새로이 시작하는 프로젝트에서 사용할 개발환경 계획에 대해 애기할려고 한다.
적용할려고 하는 기술들은 각각 인프라는 DevOps, 개발방법은 MSA, 협업툴은 JIRA&Notion 사용할 생각이다.
이 글을 썻던 시점에는 '이렇게 만들 것이다.' 라는 계획과 설정을 시작하는 단계이며 왜 DevOps와 MSA를 적용을 생각하게 되었는 지 그리고 DevOps와 MSA가 무엇인지에 대한 설명을 하려한다.
1. 과거와 현재 상황
1.1 인프라
먼저 설명을 하기 앞서 거의 똑같은 상황에서 개발 환경을 구축한 글이 있어 링크를 소개한다.
웃긴 이야기지만 이 글을 쓰고 난 후 다시 보니 상당히 비슷한 점이 많은 거 같다.
1.1.1 커뮤니케이션
회사내에서는 구글 메일과 Telegram을 사용하고 있고 현재도 사용하고 있다.
메일은 있지만 거의 사용되지 않고 있고 Telegram 역시 필요한 링크나 파일을 옮길 경우에 사용되고 회사 내에서는 바로바로 이야기로 하는 편이다.
일단 개인적으로 Slack을 Gitlab에서 merge 요청이 들어 왔을 경우 메시지를 받는 용도로 사용 중이다.
1.1.2 코드 관리
SVN를 사용하고 있었고 branch, tag 같은 경우는 전혀 사용 되지 않았다. 나 같은 경우는 입사 후 한동안 다른 프로젝트를 했었어 상관 없었지만 퍼블과 개발 쪽에서는 소스 충돌이 꽤 있던 거 같았다. 참고로 퍼블1명 개발1명 단 두명이였다.
현재는 GitLab를 설치해서 사용하고 있다. 각각에 한명씩 branch를 가지고 있고 master 같은 경우는 팀장님 혹은 프로젝트 담당자만 merge 할 수 있게 되었다. 제대로 된 branch 사용법은 아니지만 일단 이러므로써 master에 소스를 어느정도 관리할 수 있고 소스충돌 관리가 편해졌다.
1.1.3 라이브러리 관리
따로 공통 라이브러리가 없었다. 그러므로 따로 내부 리포지토리 역시 없었다. 그러다가 자바스크립트 라이브러리가 필요한 일이 생겼고 Sinopia를 설치해 사용하다가 검색결과 Verdaccio라는 더 괜찮은 툴이 있어 변경했고 새로운 프로젝트에서는 Maven 내부저장소가 필요해 Nexus를 설치해 사용하고 있다.
1.1.4 코드 배포
SSH로 접속해서 수동으로 코드를 복사해서 서버로 옮기고 수동으로 빌드를 하며 수동으로 서버를 재시작했다. 하다못해 그 흔한 스크립트 파일도 없다.
참고로 난 첫 프로젝트를 할 때는 로컬에 Jenkins를 설치해서 배포를 했으며 지금은 수동으로 복사해서 서버로 옮기고 스크립트 파일을 실행해서 배포를 한다. 초창기에 AWS에 CI 서버를 만들어 볼려고 시도를 했었는 데 실패를 하고 한동안 수동으로 했었는 데 이번에 새로운 프로젝트를 시작하면서 이번에는 CI 서버 구축을 다시 해볼려고 한다.
1.1.5 모니터링
없다.
1.2 개발 방법
1.2.1 DB
아무런 설계가 없다.
정규화 없다.
이미 가공된 데이터가 DB에 저장된다.
1.2.2 아키텍처
프론트는 React를 사용하고 백엔드는 Spring을 사용한다.
백엔드는 기본적으로 모놀리식 아키텍처를 사용한다.
모놀리식에 대한 간단한 설명을 하자면 예전부터 사용해 온 전통적인 방식이다. 기본적으로 계층형(레이어) 구조를 갖는 다. 각각 데이터(퍼시스턴스), 서비스(비즈니스), 프레젠테이션이라고 부른다.
- 데이터: DB 이용이 주된 책임이다. SQL쿼리, JDBC, 트랙잰션 등을 처리한다.
- 서비스: 비즈니스 로직이 들어간다. 데이터 계층을 호출하고 이 데이터를 가공한다.
- 프레젠테이션: 사용자에게 보여주는 뷰, HTTP 프로토콜을 처리를 한다.
[모놀리식 아키텍처 그림 참조: https://medium.com/@yesesyo/가볍게-마이크로서비스-구축해보기-1-fb4d7741b316]
테스트는 없다.
1.2.3 서버
클라우드 서버인 AWS를 사용하고 있다. 서버 구성은 하나의 인스턴스에 DB, Front, Backend 어플리케이션이 다 같이 있다.
1.3 협업
1.3.1 문서
없었다. 그러다가 검색해보니 스타트업 같은 경우 현재 Notion으로 문서공유를 많이 한다는 것을 알고 대표님에게 건의를 드렸으나 반려되었다. 그리고 6~7개월이 지나 다시 문서화에 대한 애기가 나왔고(지원군이 한명 생겼다. 신입개발자...) 아무생각없이 Notion에 회사메일로 가입했다가 대표님이 팀으로 결제한 노션으로 들어가게 되었고(대표님도 모르고 있었다.) 어쩌다 보니 Notion을 사용하게 되었다.
Notion으로 문서 공유를 하는 스타트업
1.3.2 파일
구글 드라이버를 사용한다.
1.3.3 프로젝트 관리툴
없었다. 그러다가 GitLab에 있는 이슈트래커을 사용했었다. 하지만 GitLab에 있는 기능이 모자르다 생각하여 전직장에서 사용했던 Redmine을 설치해서 사용했었는 데 내가 프로젝트 이슈관리방법, 툴 사용법에 대한 전달이 부족하여 흐지부지되고 그러다가 회사에 디자인팀이 생기면서(그전에는 디자인팀이 없고 외주를 했다.) 다시 이슈트래커툴에 대한 말이 나왔다. 그래서 JIRA 애기가 나왔지만 유료툴은 힘들다라고 해서 NHN 만든 dooray라는 툴을 사용했었다. 하지만 또 dooray라는 툴의 기능부족으로 인해 새로 들어가는 프로젝트에 다시 Redmine을 사용하려 했으나 팀장님이 프로젝트 관리를 맡게 되면서 JIRA 툴을 사용하자고 해서 현재는 JIRA를 시행착오를 거쳐가며 사용 중에 있다.
2. 문제점
2.1 인프라
커뮤니케이션과 코드관리에서는 개선점은 있어 보이지만 문제점이라고 할 만 거는 없는 거 같다. 하지만 내부 리포지토리가 없어서 그런지 공통라이브러리가 없다.
그리고 프론트에 React프로젝트 배포 같은 경우 빌드된 폴더가 옮기면 되는 데 모든 파일을 복사해서 옮기고 실섭에서 빌드하는 법으로 배포가 되었다.
2.2 개발 방법
2.2.1 DB
설계 문서가 없으니 그래서 DB 파악이 힘들다. 안그래도 사용되지 않는 테이블도 많고(지우지 않고 남아있다) 정보자체도 전문적인 내용이 많아 이해하기 힘든 데 간단한 ERD 문서가 없다.
거기에 데이터가 중복되어 저장되어 있고 정규화가 하나도 안되어 있다. 예를 들면 회사의 이름을 저장한 곳이 5개이상이다. 상당히 중요한 정보인데 만약 이름이 수정된다면 하나하나 찾아 수정을 해야 하는 상황이다.
기본이 안지켜지고 있었다. IT관련 자격증 혹은 DB 책 하나만 읽어 봤다면 모를 수가 없는 데... 보통 5정규화까지는 아니더라도 3정규화까지는 많이 하는 데 1정규화도 안 되어 있었다.
여기에 가공된 데이터가 들어가 있다. 현재 회사에서 'KeyLines'이라는 라이브러리를 사용하고 있는 데 여기서 사용하는 데이터를 로직을 돌려 만드는 게 아닌 가공된 데이터가 그대로 들어가 있다.
위 그림이 지금 현재 그 데이터의 일부분이다.(너무 길어 2개로 나눴다.) 컬럼명을 보자 b, bg, bs, c... 식별하기 힘든 이름을 가지고 있다. 왜냐하면 저 컬럼명으로 KeyLines이라는 라이브러리가 데이터를 사용하기 때문이다. 그래서 keyLines 문서를 보지 않으면 저 컬럼이 무슨 데이터인지 알 수가 없다.
그리고 데이터를 좀 더 보면 회사이름, 회사 타입도 있는 게 보일 거다. 참고로 따로 Company 테이블이 있다. 즉 위에도 말했지만 데이터가 중복되어 저장되고 있다는 애기이다.
거기에 컬럼명 c 같은 경우 색상을 뜻하는 데 만약 이 색상을 바꾸려면 모든 Row을 업데이트를 해야한다. 참고로 17만 6천개이다.
위 그림은 저 위에서 보여준 데이터의 관계를 저장한 데이터이다. 역시 가공된 데이터이며 식별하기 힘든 이름과 row 하나하나마다 색상(c 컬럼 16만 3천개) 이 저장된 게 보일 거다.
덕분에 위에 저장된 관계말고 다른 관계를 보여주려면 또 다른 가공된 관계 테이블이 필요하다.
그리고 저 가공된 관계데이터 말고 관계데이터만 저장된 테이블도 있는 데 거기가 수정되면 그에 맞쳐 이 가공된 관계테이블도 수정되어야 하는 데 잘 되는 지는 잘 모르겠다.
속도 때문에 이렇게 가공된 데이터를 저장했다고 하는 데 N+1문제로 수천개의 쿼리를 한 거랑 필요없는 데이터도 넘겨서(22MB나 되었다 실제로 필요한 데이터는 1.1MB 였다.) 속도가 느렸다. 메인페이지 였고 나오는 데 21초나 걸렸다. 내가 입사하고 첫 회의가 이거 속도를 개선할 수 있는 방법이 없나? 였었다. 참고로 어려운 것은 아니였다. IDE 창에 로그창만 보면 바로 알 수 있을 정도로 문제점을 찾는 게 어렵지 않았고 해결하는 것도 어렵지 않았다.
2.2.2 아키텍처
React를 사용하는 데 있어 모듈형식 단위인데 모듈이 잘 사용이 안 되고 있었다. 그래서 네비게이션 같은 경우가 중복되고 있었고 한 파일 안에 코드라인이 1000줄이 넘는 게는 기본이였다.
모놀리식 아키텍처에 문제점이 있지는 않다. 잘 사용된다면 해당 아키텍처만의 장점도 있다. 하지만 회사내에서 사용되는 모놀리식에는 문제가 있다.
일단 레이어에 대한 구분이 명확하지 않다. 프레젠테이션에 비즈니스 코드가 있고 퍼시스턴스 계층과 연결되어 있다.
레이어를 나누는 거는 유지보수의 용이성과 의존성을 줄이려고 나누는 건데 해당 장점을 전혀 누릴 수가 없다.
2.2.3 서버
한 서버안에 DB, 프론트, 백엔드가 전부 다 있으니 저 셋 중에 하나만 문제가 생겨도 다 같이 죽는 상황에 어디서 에러가 났는 지 찾기 힘든 구조이다.
AWS에서 CPU 사용량을 모니터링 하면 5시 15분 + 9시간 = 14시 15분쯤에 갑자기 사용량이 80%정도까지 치솟는 다. 처음에는 배치작업인가 했는 데 이 시간 때에 설정된 배치 작업이 없었다. 나중에 물어보니 DB 백업하는 시간이라고 한다.
2.3 협업
어떻게 개발 해야 한다는 기획 문서 대신에 화면 디자인 페이지만 있다. 그것도 기능에 전체적인 디자인 페이지가 있는 게 아닌 일부 페이지 디자인만 온다.
2.3.1 문서
문서가 없으니 프로젝트에 대해 파악하기도 힘들 뿐더러 기획을 대표님이 하는 데 모든 계획과 기능은 대표님만 알고 잘 전달이 안된다.(이거는 내가 아닌 다름 사람이 한 애기이며 나 역시 그렇게 생각하고 있었다.) 대표님은 문서를 만들고 하는 게 시간이 걸리고 필요없다 생각한다. 본인의 머릿속에 다 있고 그걸 그대로 바로바로 디자인으로 찍어내면 된다 생각한다.(외주작업, 대표님의 형님과 그렇게 작업한다.)
예를 들면 어떤 기능을 만들어야 되는 데 개략적인 설명과 디자인된 페이지 2개가 온다. 참고로 그 페이지 들은 기능을 기승전결로 나눈다면 기의 일부분, 전의 일부분이다. 그러면 이런 로직이 있어야 된다는 추론을 한다. 그러다 보니 필요한 페이지들이 많았고 그걸 팀장님과 애기를 하여 필요한 페이지를 정해서 대표님과 회의를 해서 요청을 했다.
이제 요청한 대로 디자인 페이지가 나올 거라는 생각으로 기능개발을 했는 데 나온 디자인은 또 다른 기능들이 추가되고 수정된 페이지가 온다. 이 때도 모든 페이지가 오진 않았다. 기, 전의 일부분, 결의 일부분, 승은 없다.
그리하여 디자이너를 요청했고 새로 뽑힌 디자이너와 중간중간 빈 페이지들을 넣었고 그걸 본 팀장님이 중간중간 허술한 부분이 보였는 지 전부 모여 회의를 거쳐 다시 보완되었다.
이렇게 개발하다 보니 중간중간 수정도 많았고 페이지가 순차적으로 안오고 띄엄띄엄 오다 보니 고려 못한 부분이 생겨 구조를 한번 뜯어고친 적이 있다. 그리고 다른 사람들이 이해하기 어려운 UX를 가지게 되는 결과가 나왔다.
또한 API 문서가 없으니 어떤 API가 있는 지도 찾기 힘들고 일일히 소스코드를 분석해야 한다.
2.3.2 파일
파일 공유에 대한 문제점은 없는 거 같다.
2.3.3 프로젝트 관리툴
처음에 툴이 없어 도입하자고 했을 때 들은 애기는 사람이 몇명 안되니 누가 무얼하는 지 다 알고 있어 필요없다는 애기였다. 개인적으로 플래너도 사용하는 판국에 아무리 적다고 해도 관리툴을 사용하지 않는 거는 이해하기 힘들었다.
사람이 몇명 더 들어오면서 툴이 없으니 다른 사람이 무얼하는 지 내가 해야 하는 개발의 사전작업이 어디까지 되었는 지 알 수는 없고(작업 중간에 다른 작업이 들어오기도 하는 데 알기가 힘들다.) 언제 되냐고 묻자니 재촉하는 거 같아서 눈치 보이고 그랬다.
3. PS
여기까지 회사내에서 사용되는 개발환경에 대해 내가 느낀 것과 문제점을 애기했고 앞으로 쓸 3개의 글에서는 새로운 프로젝트에 들어가면서 이 문제를 개선하는 방법에 대한 설명과 계획을 애기할려고 한다.
나중에 2부로 도입이 되고 난 후에 후기를 쓸까도 생각하는 중이지만 일단은 그 것은 나중 애기로 남겨 두려한다.
댓글