[ToyProject]'뭐먹지' 개발기

아이디어나 기획은 작년에 해놨지만 1년이 지난 지금에서야 완성한 첫 토이 프로젝트 뭐먹지(what-eat). ’뭐먹지’를 개발하며 겪었던 이야기를 공유하려 합니다.

뭐먹지?

점심과 저녁 메뉴를 선뜻 고르지 못하고 하던 작은 미니게임이 있었습니다. 한식, 중식, 양식, 일식, 분식 중 오늘은 먹고 싶지 않은 카테고리를 빼고 남은 카테고리에서 메뉴를 고르는 방식의 게임이었죠.

’뭐먹지’는 그 게임을 고스란히 인터넷으로 옮겨놓은 프로젝트입니다.

실패

사실 뭐먹지는 이미 몇 번이고 제 repository에 이런저런 형태와 이름으로 만들어졌다가 사라졌습니다. 그 잔재가 남아있기도 하죠. (https://github.com/wesbin/what-eat/releases/tag/v20210317) 다시 생각해도 이 버전은 참 맘에 들지 않습니다.

다행히 저는 여기서 멈출 이유는 없었습니다. 저는 '실패’를 성공의 어머니로 만들기 위해 이유를 한번 찾아보기로 합니다.

실패의 이유

결론은 이렇습니다. 디테일한 계획(혹은 기획)의 부족.

실패했던 프로젝트들을 돌이켜 보면 저는 “그건 그렇게 하고, 저건 그렇게 만들면 되겠지”라며 프로젝트를 시작했습니다. 그저 머릿속으로 생각한 목업(Mock-up) 수준의 것을 구현하려 했던 것이죠. 지금 생각하면 그 결과는 뻔한 것이었죠.

다시 뭐먹지

plan1

plan2

plan3

정말 별거 없는 기획서입니다.

혼자 볼 땐 몰랐는데 올려서 보니 글씨 정말 안 이쁘네

갤럭시 탭에 머릿속에 있던 내용을 꺼내놓으면서 배포나 구현을 어떤 식으로 할 것인지 조사하고 메모해둔 수준이죠. 그 와중에 중간에 3번 정돈 조금씩 내용이 바뀌기도 했습니다. 하지만 그런 기획서이지만 없는 것과 있는 것의 차이는 엄청났습니다.

’뭐먹지’가 완성이 되었으니까요!!

완성된 ’뭐먹지’는 https://wesbin.github.io/what-eat/ 에서 체험하실 수 있으십니다.

---

앞에서는 ’뭐먹지’가 어떻게 시작되었는지 얘기했었습니다. 여기서부터는 ’뭐먹지’를 실제로 개발하면서 겪었던 일들에 대해 얘기하려 합니다.

프로젝트를 진행하면서 정말 다양한 장애물들이 있었습니다. React.js에 대한 생소함, Github Pages를 이용한 배포. 지금 생각하면 프로젝트를 진행하면서 했던 모든 작업들이 수월하게 진행이 되었던 적이 없었던 거 같네요.

그런 장애물들 중에서도 가장 높았던 장애물인 Github API 그리고 Proxy를 중심으로 이 글을 작성하고자 합니다. 우선 제가 Github API를 사용했던 이유를 말씀드려야 할 것 같습니다.

Why?

’뭐먹지’는 Github가 제공하는 서비스 중 하나인 Github Pages(https://pages.github.com/)를 이용하여 배포를 진행했습니다. Github에 업로드된 소스를 이용하여 배포를 도와주는 서비스입니다. 특징이 있다면 Server-side 코드를 실행하지 않는다는 점입니다. 오직 업로드된 정적인 파일들을 읽어내죠.

’뭐먹지’에서는 추첨에 사용될 메뉴들이 저장될 곳이 필요했습니다. DB 같은 것도 물론 좋지만 간단하게 JSON 파일이라도 필요했습니다. 하지만 위에서 말씀드린 Github pages의 특징 때문에 DB도 JSON 파일도 이용할 수 없었습니다. 그때 눈에 띈 게 Github API를 이용하여 Repository의 issue 기능을 이용한 댓글 서비스였습니다.

이때 그냥 Cloud 서비스를 이용하겠다고 선택했으면 이 고생을 안 했을 수도…

그리고 저는 Github API를 이용하여 이슈를 댓글로서가 아닌 메뉴로서 활용할 생각을 하게 됩니다.

Github API

Github API(https://docs.github.com/en/rest)는 정말 많은 기능들이 있습니다. 이 기능을 활용하여 생각보다 많은 사람들이 저마다의 툴을 만들어 사용하고 있습니다.

저도 나름 그렇게 됐고요.

그중에서 저는 issue를 가져와 읽고, 쓰는 기능이 필요했습니다. 이건 정말 생각보다 쉬웠습니다.

지금 보니 있네요. 수월하게 풀린 부분이

Github API를 사용하는 방법은 간단합니다. 공식 문서에서 URL을 확인하고

적당히 날려주면 끝!

아래와 같이 요청해주시면 됩니다.

저는 굳이 postman을 이용했지만 위와 같이 간단한 GET 요청인 경우엔 주소창에 입력해도 무방합니다. POST나 PUT, DELETE의 경우에도 크게 어렵진 않습니다. Personal access Token을 발급받아 Header에 Authorization: ’token [발급받은 토큰 번호]’만 넣어주시면 수월하게 돌아갑니다. 하지만 그건 어디까지나 ’개인’이 사용하는 경우에 해당합니다.

저의 경우엔 다른 이용자의 계정 정보 즉, 로그인 동작이 필요했습니다. 그리고 여기서 그 녀석이 등장하죠. CORS…

ㅁ나ㅣㅓㅇㄹ ㅏㅣ;ㅁㄴㅇㄹ

CORS

Cross-Origin Resource Sharing(교차 출처 리소스 공유)는 SOP(Same-Origin Policy)와 짝을 이루는 개념입니다. SOP는 말 그대로 “같은 출처에서만 리소스를 공유할 수 있다”라는 정책인데 웹에서 다른 출처에 있는 리소스를 가져와서 사용하는 것은 흔한 일이죠. 그렇기에 예외 조항을 두기로 합니다. 그중 하나가 “CORS 정책을 지킨 리소스 요청”입니다. 생략(CORS에 대한 자세한 이야기는 다른 글에서 하도록 하겠습니다.) ~

CORS 문제의 해결 방법은

제가 알고 있는 건

두 가지입니다. 서버에서 Access-Control-Allow-Origin을 세팅해주거나 proxy를 이용하는 방법이죠. 첫 번째 방법은 제가 Github에 요청해 얻거나

쳐들어가서

안 됩니다. 그러면 자연스레 남는 건 proxy서버를 이용하는 방법입니다.

proxy server

proxy 서버는 중계 서버, 나와 상대방(출처와 출처) 사이에 요청을 받고 전달해주는 서버를 말합니다. 보안을 강화하려 사용하기도 하지만 웹 혹은 브라우저를 속이기 위해 사용하기도 합니다. 저희가 보내는 요청을 마치 CORS 정책을 지킨 것처럼 위장해 브라우저를 속이는 것이죠.(proxy에 관한 이야기도 다른 글에서 자세히 알아보도록 하겠습니다.)

proxy 서버를 사용하기 위한 가장 간단한 방법은 package.json 있다면 아래와 같이 작성하면 proxy가 동작하게 됩니다. 하지만 저의 경우엔 github pages를 이용해 배포를 했기 때문에 이 방법은 되지 않았습니다. 해서 저는 azure의 App service를 이용해 Node 서버를 배포를 하기로 했습니다.

 

{
    "name": ~~~,
    "version": ~~~,
    "proxy": "https://api.github.com",
    ~~~
}

 

제가 azure에 배포한 proxy 서버의 소스는 이곳(https://github.com/wesbin/github-proxy)에서 보실 수 있습니다. 혹시 보셨다면 아시겠지만 정말 간단합니다. 포인트는 app.js에서 사용한 cors 미들웨어에 있죠. 아주 간단하게 CORS 요청을 설정할 수 있는 미들웨어입니다. 저의 경우엔 다른 설정 없이 사용했지만 다양한 설정 방법이 있으니 찾아서 사용하시는 것도 좋을 것 같습니다.

완성

그렇게 제 첫 토이 프로젝트인 뭐먹지가 완성되었습니다. 두서없이 쭈욱 적고 보니 과연 이 글이 누군가에게 도움이 될 수 있을까 싶네요. ㅠㅠ

저의 글재주가 모자란 건지, 미루고 미루다 프로젝트가 끝난 2달이나 지난 시점에서 이 글을 쓰고 있어 그때의 감정이 사라진 건지. 프로젝트를 진행하면서 겪었던 고생들이 잘 드러나지 않는 느낌이 있네요.

그래도 적어도 저에게는 토이 프로젝트를 하면서 겪었던 고생들이 제 개발 이야기에 큰 도움이 될 거라고 생각합니다.

만약 이 글을 여기까지 읽어주신 분들이 있다면 그리고 아직 토이 프로젝트를 진행해보지 않으셨다면

꼭! 해보시길 바랍니다.

대신 계획은 최대한 작게 잡아보세요. 생각보다 더 힘드니까요.

글 읽어주셔서 감사합니다.