이노베이션 아카데미 풍경

두 달간 이노베이션 아카데미에서 인턴십을 진행하며 어떤 일을 했고, 무엇을 배웠는지 정리 해보고자 한다.

인턴십을 시작하고 첫 출근 했을 때 보급 받은 맥북에 개발환경을 세팅하라는 것 외에 업무 지시가 전혀 없어서 “왜 아무것도 안 시키지?”, “아무것도 안하고 두달동안 꿀 빨면 되는건가?”, “이번 인턴 하면서 뭐라도 배워가고 싶었는데…”, “혼자 백준이라도 풀어야겠다.” 등등의 생각을 했다. 그렇게 2~3일간 웹서핑을 하며 무의미한 시간을 보내던 중 이호준 멘토님께서 “여러분, 왜 아무것도 안물어보세요?”라는 말씀을 시작으로 여러 말씀을 해주셨다.

당시 나눴던 대화에서 이호준 멘토님이 자주(?) 애용하시는 “학생관성”이라는 단어가 가장 기억에 남는다. 학생관성을 내 나름대로 해석해보자면 “최근까지 학생이던 사람들은 주어진 일을, 주어진 정도까지만 하려고 하는 사고 방식을 가지고있다.” 라는 뉘앙스의 단어인 것 같다. 내 생각에 학생관성에 반의어는 주도적이고 능동적인 업무 처리(스스로 해야 할 일을 찾고 목표치의 +@ 까지 바라보는)가 아닐까 싶다.

본론으로 돌아가서, 이노베이션 아카데미 인턴 8명 중 누구도 학생관성을 깨지 못하고 그저 일을 시킬때 까지 기다리고만 있었고 이호준 멘토님의 말씀을 듣고서야 무엇을 해야되는지, 어떤 마음가짐으로 직장 또는 업무에 임해야 하는지 생각하게 되었다. 이후 멘토님은 우리들의 굳은 뇌를 말랑말랑하게 한다는 명목 하에 패킷, 캐시서버, 샤딩, NoSQL 등 여러 Agenda를 던져주시며 조사해 오라고 하셨고, 이 Agenda들을 이용해 우리가 알고있다고 착각하는 여러 지식들 각각을 어떻게 이어야 하며 어떻게 알고 있다는 착각이 아닌 진짜 지식으로 만들 수 있는지에 대해 말씀해 주셨다. 멘토님 말씀으로는 우리가 다 알고있는 개념들이지만 그것들 끼리 어떻게 연결해야 하는지 모른다고 하셨다. 아직 머리속에 산재되어 있는 지식들을 어떻게 연결하는지에 대한 정답을 찾지는 못했지만, 멘토님과의 대화를 통해 어떻게 접근해야 지식들을 연결할 수 있는지 정도의 실마리는 잡을 수 있었다.

1주일정도 뇌를 말랑말랑하게 하는 작업을 거친 뒤, 멘토링 매칭 시스템을 개발하라는 오더를 주셨다. 어떤 방식으로 동작해야 하는지, 원하는 기능이 무엇인지에 대한 요구사항은 말씀하시지 않고 그냥 딱 “멘토링 매칭 시스템”이라는 키워드만 던져주셨다. 처음에는 좀 더 자세히 말씀해 주시면 개발하기 수월할텐데 라는 생각을 했지만, 아마 멘토님은 인턴십을 통해 도움이나 가이드 없이 기획, 설계, 구현, 문서 등 개발의 전반적인 프로세스를 경험하게 하려는 생각을 가지고 계셨던 것 같다.


프로젝트

기획

지금부터는 프로젝트 얘기를 해보려 한다. 우선, 학생티를 못벗은 8명이 머리를 싸매고 멘토링 매칭 시스템을 기획했다. 정말 많은 아이디어가 나왔고, 이게 좋니 저게 좋니 많은 마찰도 있었다. 결국 인턴끼리 기획한 서비스는 커뮤니티(게시판)+채팅 기능을 바탕으로 한 멘토링 시스템이었다. 지금 생각해보면 2달 안에 구현 불가능 한 기획이었는데 어떤 자신감으로 기획한 건지 모르겠다. 기존 기획은 멘토님께 반려당하고, 대신 키워드를 기반으로 해서 멘토와 멘티를 연결시켜주는 매칭 서비스를 기획하였다. 지금에서야 생각할 수 있는거지만, 기획 단계에서 서비스에 대해 서로가 생각하는 개념을 통일 시켜뒀으면 설계가 수월하지 않았을까 싶다.

기획서: https://docs.google.com/document/d/1uAlGkbty2iu5OMT8FW8rcUBGqfdEGOf9bJ_JPcnnrew/edit?usp=sharing

설계

다음으로, 기획을 바탕으로 서비스를 설계했다. 요구사항 분석, 유즈케이스 분석, 시퀀스 다이어그램, 스키마&ERD 설계, 코드 컨벤션, 개발 언어 선정, 기능 명세서, Wire Frame 등등… 정말 문서작업이 많은 단계였고 그만큼 많은 시간을 할애해야 했다. 이 과정에서 기획단계에서의 구멍이 점점 커졌다. 같은 기능, 개념에 대해 서로 다르게 이해하고 있는 경우가 잦았기 때문이었다. 설계단계에서도 마찬가지로 스키마 설계에 구멍(어떤 컬럼은 Camel casing, 어떤 컬럼은 Snake casing을 사용하는 문제, 필요한 컬럼이 없는 문제 등 다양한 문제가 발생했다.)이 있어 개발단계에서 고생했다ㅠㅠ 학생관성을 못 깨고 이정도면 됐겠지 하는 생각으로 꼼꼼히 검토하지 않고 그냥 넘어가서 문제가 됐던 것 같다.

API 명세: https://docs.google.com/spreadsheets/d/1Y5-N-qXjsTuKqgtl4Tv2BLnVbAXbRxCMipZWM3MEh1A/edit?usp=sharing

와이어프레임: https://docs.google.com/presentation/d/1dASYJrKPcUQEcUIOX3In381ulBZImEJHEwiaqNo_qYc/edit?usp=sharing

시퀀스 다이어그램: https://drive.google.com/drive/folders/1SlZF6sH8v0owlfKbGZc21gCtk3q5aaaE?usp=sharing

데이터베이스 명세: https://drive.google.com/drive/folders/1M771_Q8JTB93Y4ZrfI78Q6tIoz-4s1b5?usp=sharing

개발

설계를 마치고 드디어 대망의 개발단계에 접어들었다. 실무에서 만큼은 아니겠지만, 학교에서 진행했던 프로젝트들에 비해서는 아주 세세하게 설계했었기 때문에 실제 개발기간은 그리 길지 않았다. 다만 아쉬웠던 점은 앞서 말한것 처럼 스키마 설계에 구멍이 있어서 예상외로 많은 시간이 소요됐다. 한가지 더 아쉬운 점은 코드컨벤션에 맞지 않는 코드들이 있다는 것이다. 다른 인턴분들도 마찬가지겠지만, 최대한 컨벤션을 신경쓰고 개발하려고 하지만 코드를 작성하는데에만 집중해서 미처 생각하지 못하거나 무의식적으로 평소 습관처럼 코드를 작성해서 컨벤션을 잘 지키지 못한 것 같다. 컨벤션을 정의하고 정의된 컨벤션에 따라 린터를 커스텀해서 사용하는건 어땠을까 라는 생각도 든다.(물론 멘토님이 허락하시진 않았을 것 같다.)

깃허브: https://github.com/open-inno/2020intern_admin

문서

지금은 개발을 마치고 개발하는 동안 설계 단계와 비교해 변경된 사항들과 API 명세서 등의 문서 작업을 진행하고 있다. 아이러니하게도 앞선 3단계보다 이번 단계의 일정이 더 빡빡하다… 아마 설계단계에서 명확하게 정의되지 않은 것들이 많아서인 것 같다. 원래는 Swagger라는 툴을 이용해 API를 명세하려고 했지만 툴이 익숙하지 않아 학습을 해야하는데 학습에 투자할 시간이 부족할 것 같아 엑셀 시트로 나마 간략히 정리했다.

프로젝트 후기

이번 프로젝트는 크게 서비스 개발팀과 운영툴 개발팀 두팀으로 나뉘었다. 서비스 개발팀은 프론트엔드 개발2명, 백엔드 개발 3명으로 구성되었고, 운영툴 개발팀은 프론트엔드 개발 2명, 백엔드 개발 1명으로 구성되었다. 나는 이번 프로젝트에서 Typescipt+Node.js 조합으로 운영툴 개발 백엔드 파트를 담당하였다. MVC 패턴을 적용하였고 User, Notification, Keyword, Category, Matching에 대한 CRUD, Winston을 이용해 로깅, Jest를 이용해 유닛 테스팅 코드를 구현하였다.특별히 처리해야하는 로직이 있었던 것은 아니어서 개발에 어려움은 없었다. 타입스크립트를 처음 사용해봐서 크고 작은 이슈가 있었지만 팀원들도 백엔드 개발에 지식이 있어 큰 어려움 없이 해결할 수 있었다.

기획, 설계, 개발, 문서작업까지 E2E로(배포, 운영은 없지만..) 프로젝트를 진행한건 이번이 두번째이다. 첫 프로젝트를 진행했을 때에는 개발 단계에 많은 초점을 맞추고 있었지만, 이번 프로젝트를 진행하며 설계가 완벽하면 개발에 많은 시간을 소요할 필요가 없다는 것을 배웠다. 또 Git, Slack, Trello와 같은 그룹웨어를 사용했었는데, Git, Slack 같이 사용 경험이 있던 도구들도 있었고 Trello와 같이 처음 사용해보는 도구들도 있었다. 첫 프로젝트를 진행할 때는 Task 관리도 엑셀 시트를 활용해서 했었는데 이런 그룹웨어들의 사용법을 숙지해두면 프로젝트 관리 측면에서 많은 도움이 될 것 같다는 생각이 들었다.


테크 세미나

다음으로는 인턴십을 진행하는 동안 이호준 멘토님과 했던 자체 테크 세미나에 대해 정리해보고자 한다. 이호준 멘토님은 그로스 해킹(Growth Hacking), 데이터 마케팅, 데이터 시각화, ELK, 인프라, CI/CD, MSA, 개발 퍼포먼스 향상 등의 주제를 던져주셨다.

그로스 해킹

그로스 해킹

처음 그로스 해킹이란 말을 들었을 때는 Gross Hacking이라 생각하고 총 해킹?? 일제히 공격하는 공격기법인가? 라는 생각을 했다.. 알고보니 Gross가 아니라 Growth 해킹이었다. 그로스 해킹에 대해 이해한 바를 정리하자면, 유저의 서비스 사용 패턴을 수집 및 분석하여 유의미한 데이터를 도출한 뒤 그 데이터를 이용해 마케팅을 하거나 서비스 또는 기업의 성장 방향을 결정하는 것 이라고 이해했다. 옛날의 유저 리서치는 사용자의 니즈를 파악하기 위해 시장을 조사하거나 설문을 하는 등 비교적 수동적인 방식이었다면 그로스 해킹은 사용자를 직접 분석한다는 측면에서 완전히 능동적인 방식의 리서치인 것 같다. 그로스 해킹은 데이터 마케팅, 데이터 시각화, ELK와도 깊은 관련이 있는 것 같다. 어떻게보면 그로스 해킹이 앞서 말한 것들을 포괄하는 단어가 아닐까 싶다.


데이터 마케팅

데이터 마케팅

데이터 마케팅을 간단히 말하자면, 당연하게도 데이터를 이용한 마케팅이다. 조금 더 구체적으로 말하자면, 사용자들의 니즈를 파악하기 위해 행동 패턴을 분석하고 분석한 결과를 통해 도출해낸 데이터를 이용해 사용자의 니즈를 만족시키는 것이다. 장표에서 보이는 것과 같이 과거에는 심리학을 기반으로 해서 추측성(?) 마케팅을 했다면, 현재는 데이터 통계를 이용해서 보다 정확하게 사실 기반의 마케팅을 할 수 있다. 데이터를 최대한 활용하기 위해서는 역설적으로 충분한 데이터가 필요하다. 그럼 충분한 데이터를 얻기 위해서는 무엇이 필요할까? 사용자의 행동 패턴을 분석할 수 있는 로그이다. 백엔드 개발자를 지망하는 내 입장에서는 로그의 중요성을 다시금 깨닫는 세미나였다.


데이터 시각화

데이터 시각화

데이터 시각화란 사용자 행동 패턴 데이터를 포함한 여러 데이터들을 수집한 뒤 시각적으로 쉽게 이해하고 분석할 수 있도록 표현하는 것이다. 또한 의사결정권자에게 어떤 자료를 제시할 때, Raw 데이터를 제시하는 것 보다 시각화 된 데이터를 제시하면 더 빠른 의사결정을 이끌어 낼 수 있다. 지금까지 그로스 해킹의 데이터 수집, 분석(시각화), 마케팅 중 시각화와 마케팅에 대해 얘기했다. 그럼 데이터 수집은 어떻게 하는걸까?


ELK

ELK(ElasticSearch, Log Stash, Kibana)

ELK스택이란 로그 수집기인 Logstash, 로그 적재소 및 검색 엔진인 Elasticsearch, 분석 및 시각화 도구인 Kibana의 약자를 따 ELK라고 부른다. 앞서 말한 데이터 분석(시각화)를 위해 데이터 수집이 선행되어야 하는데 이것을 Logstash라는 엔진이 처리한다. Logstash에서 다양한 로그를 수집, 통합(Filter)하고 사용자가 원하는 목적지로 전송한다. Elasticsearch는 Logstash에서 로그 등 데이터를 전달받고 저장, 검색, 분석한다. Kibana는 Elasticsearch에 저장된 데이터를 브라우저 환경에서 실시간으로 시각화하여 대시보드를 생성한다.

지금까지 그로스 해킹을 위한 데이터 수집, 데이터 분석 및 시각화, 데이터 마케팅에 대해 얘기했다. 요즘처럼 데이터가 넘쳐나는 세상에서는 데이터를 어떻게 활용할 수 있을 지에 대해 고민하는데 많은 시간을 할애해야 하는 것 같다. 더 나아가 지금보다 훨씬 많은 데이터가 응용될 수 있다면? 가령 지금은 사용자의 요청에 따른 웹 로그 만을 기록한다고 가정 했을 때, 미래에 사용자가 요청을 보낼 때 누구와 함께 있는지, 사용자가 입은 옷은 무엇인지, 사용자가 하는 생각이 무엇인지 알 수 있게 된다면 이 데이터를 어떻게 활용할 수 있을지 궁금하다.


인프라

인프라

다음으로는 인프라 라는 주제로 세미나를 진행하였다. 인프라는 개발에 필요한 네트워크부터 애플리케이션까지 넓은 범위를 의미한다. 기존의 기업들은 On-Premise 모델로 개발에 필요한 모든 인프라를 관리해야했다. 하지만 클라우드 서비스가 시작되며 IaaS, PaaS, SaaS등이 등장하였고, 기업들은 더이상 스스로 인프라를 관리하지 않고 클라우드 서비스를 이용하여 쉽게 비지니스 모델을 구현할 수 있다. 언뜻 보면 인프라에 필요한 인력이 줄어드니 좋아보이지만, 클라우드 서비스를 이용하는 비용도 만만치 않다. 또, 클라우드 서비스를 이용해 인프라를 구축, 관리하지 않아도 된다고 해서 인프라에 대해 몰라도 된다는 것은 아닌 것 같다. 인프라에 대해 알고 있어야 시스템에 장애가 발생 했을 때 복구가 가능하고 장애를 예방할 수 있다. 백엔드 개발자로서 인프라를 공부하는 것에 대한 필요성을 느낀 세미나였다.


CI/CD

CI/CD

인프라에 이어 CI/CD를 주제로 세미나를 진행했다. CI란 지속적 통합(Continous Integration)의 약자로 수정된 코드를 자동으로 빌드, 테스트하고 병합하는 것을 의미한다. CI를 사용했을 때의 이점은 테스트를 마친 후 코드를 병합하므로 병합할 때 많은 버그가 발생하는 것을 예방할 수 있다. CD란 지속적 배포(Continous Deployment)로 변경사항을 유저가 사용 가능한 환경까지 자동으로 배포하는 것을 의미한다. Monolithic구조의 서비스에서는 CD의 중요성이 부각되지 않았지만, MSA구조가 도입 된 후 수십개의 기능을 수백, 수천대의 서버에 일일히 배포하는 것에 어려움이 생겼고 이것을 해결하기 위해 지속적 배포가 도입되었다. 보통 젠킨스라는 툴을 많이 사용하는데, 들어보기만 했지 사용해 본 적은 없다. 세미나 중에 멘토님이 한번쯤은 젠킨스를 사용해보라고 적극 권장하셔서 다음 프로젝트때 젠킨스를 사용해 볼 예정이다.


MSA

MSA

그 다음은 MSA로 세미나를 진행했다. MSA는 각각의 기능을 하는 애플리케이션들을 조합해 하나의 애플리케이션을 구성하는 구조이다. Monolithic 프로그램과 비교했을 때, 하나의 기능에서 장애가 발생해도 전체 시스템으로 장애가 확장될 가능성이 적다는 것이 장점외에도 여러 장점이 있다. 또, 앞서말한 CI/CD 도구를 이용해 각각의 기능을 개별로 배포할 수 있다. 하지만 Network Latency가 높아진다는 단점도 있다. 아직 기회가 없어 MSA 프로젝트(또는 MSA에 사용되는 Microservice)에 참여한 경험은 없지만 한번쯤 경험해보고 싶다.


마무리…

짧았던 9주간의 인턴십이 벌써 끝나간다. 처음 시작했을 때의 학생의 모습을 완전히 벗지는 못했지만 그래도 이호준 멘토님의 열정적인 멘토링 덕에 조금은 개발자에 가까워 진 것 같다. 지금도 충분히 뇌가 말랑말랑해졌다 생각하지만 멘토님과 대화하면 항상 “아! 왜 저렇게 생각을 못했을까” 하며 망치로 머리를 맞는 기분이 든다. 아직 배울게 한참 남았다는거겠지. 기간이 조금만 더 길었다면.. 하는 아쉬움도 남는다. 이번 기회를 통해 개발능력도 향상 되었겠지만, 시야가 넓어지고 생각이 깊어져 조금은 더 개발자 답게 보고 생각할 수 있게 되었다는 것에 더욱 의의를 두고 싶다.