안녕하세요. 지난 글에 이어 지적 덕후생활 공동체(지덕체)개발기를 연재하고 있는 ryukim입니다.
지난 글에서는 서비스 시작 직후 직면했던 문제들과 그 해결과정을 적어보았는데요.
오늘은 CI/CD 환경 구성 과정과 모바일 뷰 최적화 과정을 적어보려고 합니다.
CI/CD를 만나고 개발 인생이 달라졌다!
여러 번 버그를 잡으며 느낀 것
지난 시간에 적었던 서비스 시작 후 여러 버그들을 잡으면서 가장 힘들었던 점은 바로 로컬에서 작업한 코드들을 다시 서버로 배포할 때 였습니다.
.gitignore 파일을 제대로 관리하지 않아 로컬과 서버 사이에서 pull, push 할 때 마다 충돌나는 부분이 있었습니다. 특히 파일 내용이 계속 변경되는 log 디렉토리의 경우 매번 삭제해줘야했고 매번 업데이트 되어야하는 build 디렉토리의 경우 .gitignore 내에서 설정이 꼬여 제대로 업데이트가 되지 않아 직접 서버 컴퓨터에서 빌드해줘야 했습니다.
하지만 클라우드 컴퓨터의 메모리 용량이 부족해 종종 빌드에 실패했고, 이로 인해 버그 수정 버전의 배포가 늦어지기 일쑤였습니다.
이 외에도 배포가 이루어지는 동안 잠시 서버에 접속할 수 없는 문제 등을 해결하기 위해 배포 자동화와 무중단 배포를 도입하기로 결정했습니다.
42 과제 중 인프라 관련 과제에서 많은 어려움을 겪으면서 해당 분야에 자신감이 떨어져 있는 상태였지만 다행히 잘 정리된 블로그가 있어 따라하며 쉽게 배울 수 있었습니다.
여러 툴 중에서 가장 레퍼런스가 많은 Travis를 채택했습니다. (의사 결정에 도움이 된 블로그입니다. 참고하시면 좋을 것 같습니다.)
다만 Travis를 무료로 사용하기 위해서는 git 레포가 퍼블릭 상태여야 했습니다.
기존 지덕체 서비스 코드는 private으로 설정되어 있었고 이를 public으로 돌리기에는 개발 과정에서 실수로 push한 mongoDB 계정 정보 등이 담겨있어 위험이 따를 것으로 판단했습니다.
따라서 새로운 퍼블릭 레포를 구성하여 이런한 위험을 해결하고, 더불어 기존에 꼬여있던 환경들도 처음부터 설정할 수 있었습니다.
무중단 배포 환경을 완성하다
먼저 저는 다음 블로그 글을 참고하여 배포 자동화 및 무중단 배포 환경을 구성하였습니다. 참고하시면 많은 도움이 될 것 같습니다. 배포 자동화 과정은 다음과 같습니다.
- 깃 레포가 Travis에 변경된 소스코드를 보내준다.
- Travis에서 소스코드의 테스트와 빌드를 진행한다.
- Travis에서 빌드된 파일은 S3에 업로드한다.
- Travis가 CodeDeploy에 배포 명령을 내린다.
- CodeDeploy가 EC2인스턴스에 빌드된 파일을 넣어준 후 배포 스크립트를 실행한다.
대부분의 과정은 AWS와 Travis에서 제공해주는 툴들을 사용하므로 특별한 것이 없었고, 저에게 가장 많은 공부가 된 것은 CodeDeploy를 통해 EC2에 파일이 전송된 후의 과정이었습니다.
무중단 배포의 원리는
- 인스턴스에 배포된 깃 레포의 파일들을 Dockerfile을 이용해 빌드하여 이미지화한다.
- Docker compose를 두 개 작성하여 빌드된 이미지의 실행과 포트 바인딩을 자동화한다.
- deploy 쉘 스크립트를 실행하여 하나의 Docker compose가 실행되고 있는지 확인 후 다른 Docker compose를 실행하여 두 개의 컨테이너를 활성화한 후 기존 compose를 실행종료한다.
이 때 nginx는 웹서버로 사용되지 않고 (저의 서비스의 경우 node.js 앱이 프론트 정적 파일들을 서빙하는 방식으로 구성되어 있기 때문에) 리버스 프록시와 로드밸런싱(upstream 기능을 이용하여)의 역할을 하게 됩니다.
그 전까지 웹서버, 애플리케이션 서버, 도커 등 전반적인 인프라에 대한 이해도가 부족했던 저는 무중단 배포과정을 통해 인프라에 흥미도 생기고 조금은 이해도를 높일 수 있었습니다.
CI/CD에 대해 더 공부한 것
사실 제목을 CI/CD 환경이라고 적었지만 조금 더 공부해보니 배포 자동화와 무중단 배포는 CI/CD에서 일부에 해당한다는 것을 알 수 있었습니다.
먼저 CI (Continuous Integration – 지속적 통합)는 여러 개발자가 동시에 개발을 진행할 때 코드의 변동사항이 있을 때 지속적으로 빌드, 테스트, 병합을 진행하는 것이라는 것을 알게 되었습니다. CI의 경우 혼자 개발하는 저로서는 당장 경험하기 어려운 영역이지만 여러 개발자들과 협업을 할 때 반드시 필요하다고 생각했습니다. 당장 이 영역에 대한 경험을 늘리기 위해 제가 할 수 있는 것은 Git에 대해 조금 더 공부해 보는 것이라고 판단했습니다. 이번 개발 과정을 통해 제가 git 사용에 정말 미숙하다는 것을 알게 되었고 앞으로의 협업 과정을 위해 학습이 더 필요할 것 같습니다.
다음으로 CD(Continuous Delivery – 지속적 제공, Continuous Deployment – 지속적 배포)는 CI를 통과한 소스코드에 대해 테스트 서버와 운영 서버에 자동으로 릴리즈 되는 것임을 알게 되었습니다. 사실상 제가 이번에 진행한 배포 자동화와 무중단 배포 작업도 모두 CD에 해당한다고 보면 될 것 같습니다. 실제로 이 작업을 통해 장애에 정말 빠르게 대응할 수 있었고, 배포를 위한 개발 공수를 극단적으로 줄일 수 있었습니다.
이번 과정에서 가장 크게 얻을 수 있었던 것은 무엇보다도 흥미를 완전히 잃고 제 길이 아니라고 생각했던 인프라 영역에 대해서도 다시 흥미를 가지게 되었다는 점인 것 같습니다.
모바일 환경의 중요성
미뤄서 남는 건 늦어지는 개발 속도 뿐
본격적으로 서비스를 시작한 후 재단과 멘토님께서 많은 홍보를 해주셨는데요. 이 때 가장 걸렸던 점이 바로 모바일 뷰를 지원하지 않는다는 점이었습니다. (모바일 뷰 최적화 전 모바일 접속 영상)
보시는 것처럼 Google Analytics를 통해 접속 기기 분포를 봤을 때 많은 사용자들이 모바일로 접속하는 것을 알 수 있습니다.
물론 홍보하면서 아직 모바일 페이지는 준비되지 않았다, 데스크탑으로 접속 부탁드린다는 말을 덧붙였지만 언제까지고 그 말이 통하지 않는다는 것을 알고 있었습니다.
그간 계속해서 모바일 뷰를 구성하지 않았던 것은 사실 css에 대한 편견때문이었습니다. 개인적으로 예술적인 감각이 뛰어나지 않다고 생각했기 때문에 언젠가 팀원을 구하게 되면 그 분께 부탁해야지 하고 계속 미뤄왔던 것이었습니다.
하지만 당장 팀원을 구하는 것은 고려하기 힘들었고, 모바일 뷰 구현을 미룰수록 홍보와 사용자 유입만 늦어진다는 것을 깨달았습니다.
편견을 버리면 보이는 세상
css에 대한 편견을 버리고 어려워도 해보자고 마음을 먹었습니다. 늘 그렇듯 가장 먼저 한 것은 구글에 ‘반응형 웹 구현하기’라고 검색하는 것이었습니다.
여러 블로그들을 통해 미디어쿼리(@media)를 이용하여 반응형 웹을 구현할 수 있다는 것을 알았고 이를 이용해 하나씩 구현해나가기 시작했습니다.
다행히 강의를 들으며 UI를 구현했던 일부 코드에 미디어 쿼리에서 기준 값으로 쓸 수 있는 값들이 정의되어있었고 크롬에서 제공하는 개발자 도구의 ‘toggle device toolbar’를 이용하여 매번 빌드하지 않고도 UI를 바로바로 확인하며 작업할 수 있었습니다.
구현을 하면서 막히는 부분들은 (px단위와 뷰포트 단위 등) 구글링을 통해 하나씩 알아가며 구현하다보니 UI도 점점 예쁘게 변해갔고 예술적 감각이 부족해 제대로 만들지 못할 것 같다는 것은 진짜 말 그대로 편견이었음을 깨달았습니다. 막상 부딪혀보니 코드에 따라 바로바로 UI가 변하는 것도 재미있었고 마찬가지로 편견 때문에 제 길이 아니라고 생각했던 프론트 영역에 대한 흥미도 생겼습니다.
그렇게 다음과 같은 결과물이 탄생했습니다.
이번 두 작업을 통해 제가 다른 분야보다도 웹 프로그래밍에 가장 흥미가 있다는 것은 확실히 알 수 있었습니다.
새롭게 직면한 문제
생각보다 반응이 약하다
그렇게 개발로 해결할 수 있는 문제들을 어느정도 마무리하니 사실상 가장 큰 문제점이 보였습니다. 바로 사용자들의 반응이었습니다.
대부분의 홍보가 개발자 커뮤니티에서만 이루어지다보니 재방문율이 현저히 떨어졌습니다.
(아래 자료를 보시면 새 사용자 수에 비해 재사용자수가 현저히 적은 것을 알 수 있습니다.)
또한 사용자가 컨텐츠를 채워야하는 커뮤니티의 특성상 사용자가 없는 것이 곧 컨텐츠의 부재로 이어져 사용자 지속 시간이 굉장히 짧았습니다.
(아래 자료를 보시면 평균 지속시간이 1분을 넘기지 못합니다.)
부정적인 의견도 많다
사실 타겟 사용자 층인 팬들에게 홍보를 하지 않은 것은 아니었습니다.
하지만 비공식 굿즈 자체가 저작권 문제를 포함하고있고 이 때문에 부정적인 반응이 상당히 많았습니다.
‘궁극적으로 비공식 굿즈의 저작권 문제를 해결하려한다’ 보다는 당장 비공식 굿즈의 정보를 제공한다는 것 자체로 부정적으로 다가오는 것 같았고 사실 저도 이 부분에 대해 충분히 동의했습니다.
비공식 굿즈에 대한 부정적인 반응에 대한 해결과 사용자 유입을 위한 방법을 고민할 때가 왔다는 생각이 들었습니다.
앞으로의 대책은?
가장 먼저 생각한 대책은 기존의 루트로 접근하자였습니다.
지금까지 대부분의 비공식 굿즈는 트위터를 통해 홍보되고 거래되어 왔습니다. 따라서 트위터를 통해 저희 서비스의 타겟층에게 홍보를 할 수 있겠다고 생각했습니다.
다만 조사를 하던 중 이미 위치폼이라는 서비스를 통해 대부분의 타겟층이 판매를 하고 있었고 해당 서비스와 어떠한 차별점을 내세울 수 있을지 고민하는 것 또한 중요한 과제라고 생각됩니다.
이렇게 어느정도 사용자를 확보하고 나면 그 후에는 어떻게 비공식 굿즈에 대한 부정적 이미지를 해소할 수 있을지, 본질적으로 지적재산권 문제를 해결하기 위해 어떤 식으로 접근할지 또한 중요한 과제인 것 같습니다.
오늘 글을 끝으로 지금까지의 개발과정을 모두 적었습니다.
물론 아직 많은 과제가 남아있습니다. 개발면에서는 프론트 서버 분리, SSR도입 등의 과제가 남아있고, 운영면에서는 새로운 카테고리 도입이 있습니다. 또한 무엇보다도 가장 중요한 과제인 홍보에 대한 부분도 남아있습니다.
개인적인 사정으로 약 2주간 지덕체 프로젝트를 쉬었습니다. 하지만 저는 이제 다시 짧게는 비공식 굿즈 문화의 양지화를 위해, 길게는 세상 모두가 하고싶은 일을 직업으로 삼을 수 있는 세상을 만들기 위해 계속 나아갈 것입니다.
앞으로도 ‘웹 개발 입문자의 우당탕탕 개발기’ 시리즈는 이어집니다! 많은 관심 부탁드립니다.
긴 글 읽어주셔서 정말 감사합니다.
(해당 시리즈는 42서울 블로그에 있던 저의 글을 velog로 옮긴 것임을 밝힙니다.)
