Notice
Recent Posts
Recent Comments
Link
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Tags
more
Archives
Today
Total
관리 메뉴

체대출신 코더의 개발자 성장기

Cocoa project - 4주 프로젝트 본문

CodeStates/CodeState projects

Cocoa project - 4주 프로젝트

미토콘크리트 2019. 8. 20. 22:13

코드 스테이츠 에선 이머시브 코스를 잘 따라와 준 수강생들에게 큰 기회를 선물로 준다.

바로 기업과의 협업 프로젝트 기회를 주는 것인데, 나는 이번 4주 프로젝트에서 그 기회를 이용해

마인드 로직이라는 회사와 함께 구글 어시스턴트를 이용해 '초성 퀴즈'와 '끝말잇기' 게임을 만들었다.

 

마인드 로직은 

마인드로직 로고

인공지능 기술을 이용해 현재 가상남자친구, 여자 친구 서비스를 Google Assistant에 현재 제공하고 있는 기업이다.

https://mindlogic.ai/#/

 

MINDLOGIC

 

mindlogic.ai

1. Cocoa project 란?

Actions on Google Logo

Actions on google 이라는 라이브러리를 이용하면 구글 어시스턴트와 대화를 나눌 수 있다.

또한 Google interactive Canvas를 이용하면 이 대화 위에 화면을 입힐 수 있는데

그렇게 되면 구글 어시스턴트와의 대화를 소리만이 아닌 눈으로도 즐길 수 있게 되는 것이다.

Cocoa project는 위의 두 가지를 이용하여 '초성 퀴즈'와 '끝말잇기' 게임을 만드는 프로젝트이다.

시연 영상 :  https://www.youtube.com/watch?v=p03hs_7yJQU&feature=youtu.be

 

2. 어떤 기술들을 사용했을까?

Front-end : Vue.js , Interactive Canvas API

Back-end : Node.js , Django ,  PostGresql

Tools : Actions on Google , Docker , EC2(AWS) 

처음 이 기술들을 맞다고 드렸을 때

위의 기술 들 중 우리가 아는 것은 Node.js 뿐이었다.

하지만 그 마저도 Actions on Google의 이해가 없다면, 우리 팀원들은 마냥 VS Code 만 켜놓고 멍 때려야 하는 상황이었다.

 

3. 내가 맡은 역할은?

난 Back-End 작업을 위주로 진행했다.

그중에서도 Docker를 이용해 버전 관리를 용이하게 만들고

Google Assistant - Node.js - Django의 Connection 연결을 이용한 게임 로직 제작을 위주로 작업했다.

 

4. 주요 기술적 이슈들

 4-1. Docker 

Docker icon

 1) Docker의 개념

 위에 보이는 로고는 Docker 의 개념을 잘 나타내고 있다.

 Docker는 버전 관리를 위해 탄생한 없으면 안 되는 귀중한 존재이다.

 도커는 글씨 몇 줄로 이뤄진 '이미지'라는 것을 이용해, 어느 환경에서 던 지 '이미지'안에 적힌 내용을 그대로 실행시킬 수 있다.

 이로서 가능해지는 것은, 서버 세팅이 매우 쉬워진다. 

 '이미지' 안에 서버 세팅에 대한 모~~든것을 적어놓고, 그 이미지를 실행시키면

 어딜 가던 '이미지' 안에 적힌 서버셋팅 환경을 도커가 만들어준다.

 지금부터는 도커를 붕어빵에 비유해서 설명해보겠다.

 

2) 이미지

붕어빵 틀 도면

 이미지는 '붕어빵 틀 도면'이라고 생각하면 된다.

 이 '붕어빵 틀 도면'을 보고 틀을 만들면 한국사람이 만들어도, 영국 사람이 만들어도 , 아니면 미국 사람이 만들어도 똑같은 모습을

 유지할 것이다.

 왜냐하면 도면에는 길이와 모습 등 다양한 정보들이 자세하게 기입되어 있기 때문에 어딜 가던지 이 수치들을 보고 만들기만 하면 되기

 때문이다.

하지만 도면만으로는 붕어빵을 만들 수 없다는 건 모두가 알 것이다.

따라서 이 도면을 이용해 실제로 틀을 만들어야 하는데 도커에서는 build 명령어를 이용한다. 

docker build -t  [이미지이름지정]  -f  [실행시킬도커파일]

 -t : 붕어빵 틀의 이름을 정한다.

-f : 어떤 도면을 이용해 붕어빵 틀을 만들지를 정한다. 

위의 명령어가 무사히 수행되면 이미지 ID가 주어진다.

 

 3) 컨테이너 

붕어빵 틀

docker ps

컨테이너는 붕어빵을 만들 수 있는'붕어빵 틀'이라고 생각하면 된다.

실체가 존재하지만 아직 전기가 들어와 있지 않기 때문에 아직은 '붕어빵'을 만들 수 없다.

따라서 아직은 이 틀은 '이미지'로서의 기능밖에 하지 못한다.

그럼 이제 붕어빵 틀이 실제로 작동할 수 있도록 전기를 연결시켜야 한다.

docker run -d -p [로컬port] : [dockerport] --volume=$(pwd):/app/ -t [실행시킬이미지이름]

- p : 붕어빵 틀을 처음 만들 때 계획한 전기 포트의 V와 다른 곳에서 만들 때의 전기포트 V를 일치시킨다

--volume : 이 옵션을 이용하면, 붕어빵 틀에 어떤 변경이 생길 때마다 새로운 붕어빵 틀을 만들어 줄 필요가 없다. 

              $(pwd) : /app/ 을 해석하자면, 내 로컬 상의 경로와 /app/의 경로를 똑같은 경로로서 도커 환경에서 인식시킨다는 소리이다.

 -t : 전기를 연결시킬 붕어빵 틀의 이름이 어떤 것인지 정해준다.

docker ps

명령어를 이용하면 컨테이너 ID를 보여주고, 현재 컨테이너의 상태가 어떤 지 확인할 수 있다.

 

4) 유용한 명령어들

사실 위에서 설명한 게 도커의 전부이긴 하다.

하지만 내가 프로젝트를 진행하면서 유용하게 썼던 명령어들 까지 있다면 도커를 훨씬 유용하게 쓸 수 있을 것이다.

/*1. 컨테이너 정지 */
docker stop [컨테이너ID]

/*2. 컨테이너 재시작 */
docker restart [컨테이너ID]

/*3. 컨테이너 삭제 */
docker rm [컨테이너ID]

/*4. 컨테이너 터미널 진입 */
docker exec -it [컨테이너ID] bash

/*5. 컨테이너 log 확인 */
docker logs -f [컨테이너 ID]


/*5. docker hub에서 docker이미지 가져오기 */
docker pull [이미지이름]

/*6. docker hub에 docker 이미지 올리기 */
docker push [docker hup][이미지이름]:[태그]

/*7. docker 이미지 확인 */
docker images 

/*8. docker 이미지 삭제 */
docker rmi [이미지ID] 

 

5)  Docker 가 효율적인 이유

<좌> Docker 이용시 와 <우> VM 이용 시 각각의  자원 이용 방식 차이

처음엔 단순히 docker 가상 환경이라고만 생각했다. 하지만 docker는 가상 환경이긴 하지만 좀 다른 개념이라고 생각하면 된다.

보통 가상 환경의 경우에는 CPU의 자원을 할당받아서 또 자신만의 환경을 구축한다. 

하지만 docker은 자신만의 환경을 만들지 않고, 기생충처럼 CPU의 기능을 필요할 때만 야금야금 사용한다. 

이것은 마치 docker가 진짜 컴퓨터고 진짜 컴퓨터가 docker인 것이다.

이게 어떤 의미인가 하면.. 

가상 환경의 프로그램에 진짜 CPU가 접근하기 위해서는 또 다른 가상의 CPU를 거쳐야 한다.

하지만 기생충 같은 docker의 환경은 CPU가 곧바로 해당 환경에 접근할 수 있기 때문에, 가볍고 빠른 환경 구축 및 관리가 가능해지는

것이다.

 

 4-2. Django 

 1) MTV 패턴

Django를 접하게 되면 가장 먼저 접하는 것이 Model Template View 패턴이다.

일반적으로 Node.js에서 학습했던 Modle View Controller 패턴과 단어 빼고는 모두 같지만, Django는 MVT 패턴에 맞추어 코드가

작성되야만 하는 고리타분한 프레임워크이다. 따라서 이 패턴이 무엇인지를 익히는 것이 Django와 친해지는 가장 빠른 길일 것이다.

일단 Django는 앱이 init 될 때 생기는 파일 자체가 MTV 패턴을 준수해서 생긴다.

Django app init 시 생기는 파일들

어떤 파일이 있고 어떤 기능을 하는지는 아래의 링크를 타고 들어가 보면 자세히 적어 놓았다.

https://miticoncrete.tistory.com/26

 

장고-MTV 모델

초기의 웹 페이지 백엔드코드의 형태는 모든 코드가 하나로 합쳐진 형태였다. 하나로 합쳐서 꼬일데로 꼬인 코드는 프로젝트 관리를 어렵게 만들었다. 따라서, 사람들은 관리가 쉽도록 코드들을 구분짓기 시작했고..

miticoncrete.tistory.com

 2) 왜 이런 고리타분한 프레임워크를 사용할까?

장고는 마치 어린아이를 가진 어머니 아버지와 같다는 느낌이 든다.

자유도를 최소화 시키지만 안전하다.

- 기본 보안이 되어있다.

  장고 프레임워크는 웹 공격을 settings.py에 간단히 작성함으로서 방어할 수 있다.

  또한 settings.py 를 통해 손쉽게 장고에 접근가능한 url만 지정이 가능하여 해킹으로 부터 방어가 가능하다. 

- 디버깅이 쉽다.

  장고는 디버깅 툴을 제공하여, 한 눈에 어디서 버그가 일어났는지 보여준다.

- 빠른 개발 속도 

  이건 사람마다 다르겠지만, 장고는 틀이 갖춰져있기 때문에 그 틀의 기능만 잘 파악한다면

  틀의 기능에 맞추어 코드만 작성해 주면 된다. 그렇기 때문에 서버 구축 속도에 있어서 보다 효율적인 시간절약을 가능하게 만들어

  준다.

3) 내가 Django를 사용하면서 느꼈던 것들

  - 어렵다

처음에 파일이 각각 의미하는 바를 공부하는데 너무 많은 시간이 걸렸다.

MTV 패턴부터 시작해서, 기본적인 보안이 너무 잘 갖춰져 있어 그걸 뚫고 요청을 주고 받는 것 조차도 쉬운일이 아니었다.

Csrf token 이슈는 post 요청을 지속적으로 보내던 우리 프로젝트에선 최악의 이슈였다.

미들웨어를 추가하니 바로 해결되는 간단한 일이긴 했지만 이런 사용법을 익히는 데 까지는 굉장히 오래 걸렸다.

  -  익숙해지면 쉽다.

모든 패턴이 그런건 아니겠지만, 장고에서 내가 반복한 패턴은

문제발생 -> 미들웨어 추가 -> 해결 -> 문제발생 -> 미들웨어 추가 -> 해결

의 연속이었다. 

또한 Docs가 굉장히 자세하게 나와있어서(소스코드가 공개되어있다!!)

그것만 이해한다면 재미있게(?) Django를 이용한 서버를 구축할 수 있을 것이다.

 

 4-3. Interactive Canvas

프론트 작업을 거의하진 않았지만, 화면을 보여주는 Interactive Canvas의 URL을 장고에서 줘야하기 때문에 

발생한 Interactive Canvas 만의 몇몇 이슈들을 말해보겠다.

 - http url은 interactive canvas url 로서 사용할수 없다.

  아무리 배포된 url 이라도 http 프로토콜을 이용하였다면 URL 자체가 넘어가지 않는다. 

  URL 을 https 형식으로 변경하니 바로 해결 되었다. 

 - x-frame-option 을 뚫어야한다.

구글 어시스턴트는 html로 이루어져있고, Interactive Canvas에서 제공되는 Url에 연결된 화면또한 html로 이루어져 있다.

 html 화면 위에 또다른 html을 띄우는 것을 iframe 화면이라고 하는데

 이 때, x-frame-option 설정을 따로 해주지 않으면 CORS 에러가 발생한다.

 아무래도 여러 리소스를 사용하는 일이기 때문인 것 같다.

 settings.py 에 이 두 줄만 추가해 주니 모든 문제가 해결 되었다.

X_FRAME_OPTIONS = 'ALLOWALL'

XS_SHARING_ALLOWED_METHODS = ['POST','GET','OPTIONS','PUT','DELETE']

 

 

'CodeStates > CodeState projects' 카테고리의 다른 글

owlPost Project - 2주 프로젝트  (0) 2019.08.22
Comments