이노베이션 아카데미(42seoul) 2020년 하계 인턴십

이번 2020년 하계 인턴을 이노베이션 아카데미에서 진행한 국민대학교 소프트웨어 전공자 윤준호입니다.

필자가 진행한 자체 세미나 : 데이터 시각화

1주차 (6/29 ~ 7/3)

개발을 위한 회의를 시작하기 전, 원활한 진행을 위해 사전 지식 조사

1. 개발하려고 하는 서비스에 대한 확실한 이해.
2. 해당 서비스의 런칭 대상인 이노베이션 아카데미에 대한 이해.
3. 전체적인 이해로 사용자에 대한 이해를 한다.

• 요구사항 분석

서비스 개발을 위해 작성한 요구사향 명세서

대학생적인 학생 마인드를 버리고, 개발자의 자세를 갖추기 위한 기간

1. 토이 프로젝트를 할 때에는 고려하지 않았던 서버 수용 인원수를 고려하며 서버 선택
2. 고려할 필요가 없던 데이터베이스 시간과 성능 최적화에 대해 고려
3. 무작정 개발먼저 시작을 하기 전, 사전에 모든 회의로 논리적 구멍을 논하기로 함

개발을 위한 맥북 지급

(좌) : 인턴 출근 첫날 지금된 맥북 프로 터치바 16인치, (우) : 원래 사용하고 있던 맥북 프로 논터치바 13인치

2주차 (7/6 ~ 7/10)

1. 서버 개발을 위해 packet 이란 무엇인가에 대해 학습
   → 동영상 링크 (패킷의 여행) : https://www.youtube.com/watch?v=XwphKCS_Kgw
2. DB를 결정하기에 앞서, NoSQL 의 등장 배경을 조사
   → R-DBMS, Data Sharding, Join 문제, 캐시 서버에 대해서 조사
3. 온라인 시장에 대해서 이해
   → 이동 상 - 지역 시장에서의 경제 - 온라인 마켙 - 서비스 시장
   : Air bnb, Amazon 에 대해서 이해
4. 개발 환경에 대한 이해
   → Window OS | Mac OS 차이에 대한 이해.
5. 비즈니스와 개발의 관계에 대해 이해
   → 서비스를 개발하는 것으로의 수익 창출 방법에 대해 생각.
   → 한 분야에서의 서비스가 다른 분야의 서비스에서도 받는 영향이 있다는 것에 대한 이해
   : (ex. 나이키가 발표한 자사의 경쟁업체 : 아디다스나 뉴발란스가 아닌 '닌텐도' )

3주차 (7/13 ~ 7/17)

1. 개발 이전, 사전에 모든 논리적인 시퀀스를 전부 상세하게 논의
   → 먼저 개발을 시작하게 되면 논리적인 구멍이 있으나 뛰어 넘는 경우가 생긴다
   → 아주 작은 if, else 와 같은 논리까지 전부 문서 처리
2. 서버와 로그 기록
   → 서버는 모든 사용자를 신회하지 않는 다는 가정하에 진행된다.
   → 이러한 농담이 있다 : 서비스를 개발하고 내가 쓰러지더라도 서버는 살린다. 서버가 뻗어도 로그는 남긴다
3. 팀 빌딩
   → 프론트앤드 / 백엔드(서비스) / 운영팀
4. 시퀀스 다이어그램 작성으로 상세 논리까지 고려

처음 작성하게 된 개략적인 시퀀스 다이어그램

4주차 (7/20 ~ 7/24)

개발 환경 맞추기

1. Coding convention (합의 하에 맞춘 개발 표준) 맞추기
   → n명이 개발에 참여하더라도, 1명이 개발을 한 것 처럼 표준이 존재해야 한다.
   → 변수명, 함수명, 데이터베이스 쿼리문에 대해서 논한다.
2. 개발에 어떠한 언어를 쓸 것이지 결정. 어떠한 프레임워크를 쓸 것인지, 데이터베이스는 어떤 것을 사용할 지에 대해 결정 : 어떠한 결정을 했다면, 다른 선택은 하지 않은 이유도 설명 가능 할 정도로 회의.

• 코딩 컨벤션

코딩 스타일을 통일 시키기 위한 코딩 컨벤션

5주차 (7/27 ~ 7/31)

개발 시작

로그 수집에 대한 기술
→ 개발을 할 때에는 항상 오류가 날 수도 있고, 얘기치 못한 성능 저하가 생길 수 있다.
그러한 오류등에 대해 버그 수정을 하려면 기록을 남겨야 한다. (로그)
그렇다면 로그를 효율적으로 남기는 방법에 대해서도 논의를 해야 했다.

데이터베이스와 시스템 로그를 기록하여 에러를 빠르게 찾아낸다

로그 수집의 이유

1. 개발 영역 → 버그나 크래쉬
2. 마케팅 영역
3. 기획/디자인 영역

Elasticsearch(오픈소스 풀텍스트 검색 및 분석 엔진)
→ DB 위에다가 검색엔진을 붙인 느낌.
→ 대신 그냥 like 처럼 찾는게 아니라, 형태소로 분석을 하는 것.
Logstash
→ 실시간 파이프라인 기능 가진 오픈소스 테이터 수집 엔진
Kibana
→ 시각화

업무 환경

사무실 내부

환경에 집중이 안되는 경우 바로 앞 베란다에서 개발을 할 수 있었다

6주차 (8/3 ~ 8/7)

코드 중간리뷰 및 리펙토링

configuration 과 같은 파일들은 config 라는 파일에 따로 넣어 놓기로 함.

팀별 간 코드 리뷰 시간을 가졌다

Front

• 프로토타입이 나올 때에는, 개발에 전혀 참여하지 않은 처음 보는 사람이 페이지 view만 봐도 이게 뭘 하는 페이지인지 기능이 무엇인지 한 번에 알 수 있어야 한다.
• cold start를 허용을 할 것 인지에 대해서도 한 번에 알아볼 수 있어야 하고
• UX/UI 적으로 확인을 하게 될 경우에, 금방 확인 방법을 익힐 수 있는 디자인이 나와야 한다.
• 지저분해 보이더라도 뭔지는 알 수 있어야 한다. 최소한 mouseover 이 일어났을 때에 설명이라도 뜨게 해야 한다.
• 데이터 정렬
  • 검색 결과 상에서 몇 명이 나왔는가
  • 검색 결과를 어떻게 정렬을 할 것인가 USN 기준? → 검색어 많이 있는 순 + 연관도 순으로 나오게 만들어야 한다.

Back-end - Service

• API 요청에 대해서 처리를 할 때에 우리는 router 을 변수가 중간에 들어가게끔 했는데 이건 좋지 않은 것 같다.
  router.get('/:usn/inform', userController.getUsers);
  → http://localhost:3001/user/2/keyword 의 방식으로 사용을 하게 되는데, 이렇게 한다면 url 파싱에서 많이 힘들어진다, rounter 자체가 url 파싱 규칙을 만들어 쓰라는 것이다. 그런데 이렇게 사용을 하게 된다면 하나만 가져온다면 usn 을 하나만 넣으니까 쉽겠다.
• 하지만, 여러 유저를 요구한다면 이렇게 하는게 나쁘다. 여기서 :usn 을 맨 뒤로 빼야 한다. 그래야 뒤가 아무리 길어 진다고 해도 파싱을 해서, 앞 부분은 어차피 명령이니까 쑥 들어가고, 다 끝나고 usn 온 것들이 아무리 길어도 파싱하면 맨 뒤만 읽으면 끝이니까. 바인드 쿼리 or 대체 Controller 에서 usn 을 확인을 하고 DAO 로 넘긴다. 그런데 여러 컨트러에서 불러다 쓰는데, 앞 단에 계속 체크 로직을 또 써 놔라. DAO를 어느 Controller에서 부를 지 모른다.
  • Controller 에서의 체크
    let usn = parseInt(req.params.usn, 10); if (Number.isNaN(usn)) { return res.status(200).json({ statusCode: 500, message: 'Controller 에서 잘못된 매개변수 타입' }); }
  • DAO 에서의 체크
    let usn = parseInt(req.params.usn, 10); if (Number.isNaN(usn)) { return res.status(200).json({ statusCode: 501, message: 'DAO 에서 잘못된 매개변수 타입' }); }
• 이런 식으로 같은 에러 처리라고 해도 에러를 statusCode 가 다르게 설정을 해서 바로 어디서 오류가 났는지 알 수 있도록 해줘라. 이렇게 내가 구분을 해야 워라벨을 챙길 수 있다. 라우팅 규칙이 있는 형태에는 폴더를 만들어서 router 들을 저장하는 폴더를 만들어 넣는 것이 좋음.
• DB에서 배열을 주어, 배열의 요소 중 있는 것이 있는 지에 대해서 확인을 해 볼 때에는 WHERE 절을 사용하거나 for 문을 돌려 확인을 하는 것 보다, IN 으로 검색을 하는 방식으로 변경을 하였을 때에 검색 속도가 많이 향상되었다.

Admin

페이지로 할 것과, 모달로 할 것을 나누어라. 페이지는 수정 창, 모달은 입력 창 이런 식으로 기능 별로 구분하여 통일된 방법을 사용하는 쪽이 좋다.

7주차 (8/10 ~ 8/15)

개발 마무리 및 리펙토링 진행

소프트웨어의 배포에 대해서 알아보는 시간을 가지게 됨.

 

지속적인 리펙토링 과정으로 반복되는 코드를 한 부분으로 빼 라이브러리에 모아놓고, 필요한 경우 불러 쓰는 방식으로 바꿔 코드의 길이를 최소화 했습니다. + 데이터 베이스 쿼리문을 정확하며, 빠른 시간으로 처리가 가능한 방향으로 바꿔 보았습니다,

 

• 지속적으로 사용을 하게 되는 함수는 lib 라는 라이브러리 폴더를 만들어, 다른 파일에서 그저 불러서 사용하기만 하였습니다.

공통적으로 사용되는 것들은 library로 따로 모아 빼놓았다

• 매번 API 요청에 대한 결과를 POSTMAN 으로 확인하기가 불편하다는 점을 느껴, VS code에서 바로 API 요청과 결과를 확인할 수 있는 REST client 라는extension 을 사용하여 vscode 에서 바로 확인을 하며 개발하였습니다.
  : Visual Studio Code 툴 내부에 REST Client 라고 POST MAN과 같은 기능을 하는 확장 프로그램이 있어 설치하여 사용해보았습니다.

처음 사용해본 REST Client

• 데이터베이스

DB 테이블과 뷰의 구조

데이터베이스의 ERD

8주차 (8/17 ~ 21)

문서 정리

기술 세미나

그로스 해킹 (Growth Hacking)
→ 로그 수집 + 로그 시각화 + 마케팅 전략
그로스 해킹이란 사용자들이 어떻게 서비스를 사용을 하는 지에 대해서 행동 데이터를 수집을 하는 것이다. 이런 데이터를 기반으로 UI/UX를 고칠 수도 있고, 서비스를 변경을 하는 곳에도 쓰인다.

개략적 그로스 해킹

데이터 마케팅

데이터를 가지고 마케팅을 한다는 용어다. 기업에서의 이전 의사 결정에서는 경영진의 감에 의해 결정이 되었다. 하지만 이제는, 객관적인 데이터에 의해 정확한 의사결정을 할 수 있게 되었다. 쿠팡의 성공 사례와 같이, 매장에서의 쇼핑 정보들을 모아, A라는 상품을 사는 사람들은 B라는 상품을 같이 산다 라는 그런 정보들을 모아, 새벽 배송이 가능하게 된 사례가 많다.
기업들의 경제활동 데이터가 쌓이면, 데이터를은 가치있게 사용이 될 수 있으며, 그 자체로 돈이 되게 팔 수가 있다.
데이터 마케팅을 효율적으로 예를 들어

데이터 마케팅 세미나

데이터 시각화

사람은 데이터에 대한 분석이나 현재의 수치에 대해서 텍스트로 정보를 전달을 받게 된다면, 그 결과를 한 번 더 생각하여 어느 정도의 수치인지, 다시 생각을 해야 하는 과정이 생기게 됩니다. 예를 들어, 매 순간 직관적인 이해가 필요한 자동차의 속도계, 주유량 등은 수치화된 숫자로만 보았을 경우와 그래프로 시각화가 되었을 때가 있습니다.
현재의 속도를 직관적으로 보아야 하는 운전의 경우, 위와 같은 계기판은 숫자로 시속을 보아도, 다시 한 번 이 숫자라면, 어느 정도로 위험하게 달리고 있는지에 대해 한 번 더 생각을 거쳐야 합니다. 이러한 순간적인 사고 결정에 도움을 주기 위해 데이터를 시각화를 하기도 합니다.
데이터의 시각화도 목적에 따라 그에 알맞은 분석 방법과 시각화 방법이 필요합니다. 예를 들어 전날의 업무 결과에 대한 보고가 목적인 경우, 어제의 매출 총 금액이 얼마인지에 대한 분석 결과와 같은 데이터는 정적인 데이터로 전달이 되는 것이 효율적인 방법일 것입니다. 하지만 한 달 간의 변화 추이와 같은 것들은 그래프로 보여주거나, 변화 되는 것들을 동적으로 보여주는 데이터가 좋을 것입니다.

데이터 시각화 세미나 : 다른 게시물에 상세히 다루었습니다.

웹 쇼핑몰을 예로 들어보겠습니다. 소비자가 쇼핑몰에 들어가서 상품을 1. (조회/관심상품 등록/장바구니) 2. (구매/환불/교환) 등의 행위를 할 것입니다. 이 행위들의 분석 결과를 사이트 디자이너, 사이트 운영자, 경영자 에게 전달을 하는 경우 전달되어야 하는 분석 결과들은 달라야 할 것입니다.

 

디자이너는 어떤 위치에 인기 상품을 배치를 했을 경우 조회수가 떨어지거나 높아지거나 하는 결과를 받아야 할 것입니다. 일반적인 오프라인 의류 매장을 들어가도 주력 상품을 문을 열고 들어왔을 때 가까운 곳에, 바로 보이는 위치(협탁과 같이 낮은 높이)에 전시를 한다던가, 가격대 별, 특정 프로모션이나 프로젝트 라인 별 상품들은 한 블럭에 모으는 전시 방식을 택합니다. 이와 같은 배치도 구매 행위의 분석 결과를 반영한 배치입니다. 웹 상에서도 이와 같은 분석을 사용하기 위해 위와 같은 분석 결과를 필요로 합니다.

운영자와 경영자는 어떠한 구매 행위에서 구매 과정이 길어져 불만이 생긴 유저들이 불편을 겪고 구매를 취소하게 되거나, 어떤 상품은 조회만 하고 어떠한 이유로 조회수가 굉장히 많은 상품임에도 불구하고 판매가 되지 않는지에 대한 분석 결과가 필요할 것입니다.

이러한 문제는 시장이 웹 상으로 오게 되며 필요해진 분석이기도 합니다. 어떠한 물건을 사는 경우, 해당 사이트에서는 구경만 하고, 최저가를 검색하여 다른 사이트에서 구매를 하는 쇼루밍 소비 방식이 늘고 있습니다. 나의 사이트에서 구경을 많이 하지만 구경을 하고 다른 사이트로 이동을 하는 로그들이 많이 남게 된다면, 쇼루밍 페이지가 되고 있지는 않은가에 대해서 생각을 할 필요가 있습니다.

또, 구매를 진행을 하는 과정에 한 번씩 겪어본 일들이 있을 것입니다. 로그 분석 결과 결제를 진행하는 도중 취소를 결정하게 되는 사람들이 많아진다면, 결제 시스템에 대한 고려를 해 보아야 한다는 해결책을 생각하게 될 것입니다. 좋은 상품을 좋은 가격에 구매를 할 수 있더라도, 결제를 하기 위한 단계가 많고 복잡하다면 번거로움에 못이겨, 구매를 포기하거나 다음 부터는 다른 사이트를 이용하는 경우가 많이 생기게 됩니다. 소비자는 결제를 위해 여러 단계를 겪으며 구매에 대한 의구심을 한 번 더 품습니다. 최근의 결제 방식은 이러한 과정 자체를 삭제하려 중간 과정을 생략하려고 하는 경향이 많습니다.(ex.네이버 페이, 쿠팡머니, 삼성페이 등등...)