본문 바로가기
분류없음

아무도 가르쳐 주지 않았던 것 (작성중)

by xenophilius 2019.09.12

아무도 가르쳐 주지 않았던 것

Log

설령 간단하게 장난감을 만들어 테스트를 해 보더라도 logging을 하는 것을 추천한다.

ENV

리눅스를 잘 다루면 좋다는 점은 아무리 말 해도 지나치지 않을 것이다. environment는 특히 node를 다룰 때 많이 접하게 된다. 환경변수 설정으로 development 환경이냐, production 환경을 구분해서 logging을 하도록 하면 print로 코드가 지저분 해지는 것을 잘 막을 수 있다. 조금 더 힘을 내서 stage까지 만들어 둔다면 나중에 서비스를 테스트하는데 큰 도움이 된다.

config

설정들을 어떻게 관리 할 것인가? 혼자 개발하면서는 딱히 신경이 가지 않아 대학생 때는 잘 느끼지 못해서 경험이 없는 채로 졸업하게 된다. 예를들어 어떤 데이터 베이스에 접속하는 코드가 있다고 가정하자.

 

redis.Redis(host='redis-us-east', charset='utf-8', password='WCaZYz7Kn14vdvw')

 

이렇게 하면 당연하게도 host나 password가 코드 내에 여실히 드러나게 되어 썩 우아하지 않아 보인다. 나는 이렇게 하는 것이 무언가 전문적이게(?) 보이지 않는다는 느낌을 받았지만 구체적으로 무엇이 문제인지 짚어내지 못했다. 가장 흔히 들어 온 것이 host가 바뀌거나 할 경우 곳곳에 산재한 host 주소를 바꾸기가 귀찮다는 것이다. 그러나 어차피 혼자 개발하면서 이런 코드는 거의 한 번만 쓰이게 되기에 고개를 끄덕이기가 어려웠다.

그러나 개발 경험이 쌓인 이제는 확실한 단점 몇가지를 말 할 수 있게 되었다.

  • dev 환경용 데이터베이스와 prod 환경용 데이터 베이스 주소가 다를 수 있다. 이 경우 ENV에 따라 host가 바뀔 수 있다면 좋을 것이다. stage1, stage2 등의 다른 환경의 host가 쓰일 수도 있다.
  • password를 안전하게 보관해야한다. 코드에 password를 써 두면 git push하는 순간 비밀번호가 외부에 노출된다. API secret key나 각종 access token들도 마찬가지로 겪는 문제이다. 이런 key를 담은 config file들은 암호화하여 push하는 등의 방법이 있다.

Heroku나 Dokku를 사용한다면 config var를 사용 할 수 있다. 서버에 직접

CI/CD

사실 CI의 경우 테스트 이야기를 먼저 해야한다.

git commit과 git push 한 번으로 테스트와 배포를 자동으로 할 수 있다.

요즘에는 워낙 좋은 PaaS와 서비스들이 많아서 이건 사실 잘 몰라도 버튼 몇번이면 다 해 낼 수 있다. 정말 간단하게 사용하려면 heroku를 무료로 썼었다. Gitlab도 좋다. gitrunner를 사용하는 방법에 대해서 한 번 써보고 싶다. 유료이긴 하지만 Digital Ocean도 좋았다. 학생이라면 50$를 무료 크레딧으로 제공한다.

결국 일주일에 몇번 Deploy하느냐 얼마나 자주 deploy를 할 수 있느냐가 App Quality에 영향을 미치게 됐다. 수 년전 부터 Facebook과 Twitter의 모바일 앱은 Quality Improvement라는 짤막한 내역과 함께 Regular update를 하기 시작했다.

git

이건 요즘 학생들도 많이 알고 많이 배우고 나보다 더 잘 알 것이라 생각한다. 때문에 다른 것 보다는 간단하게 적으려 한다. 극단적으로 말해서 말해서 소위 말하는 지잡대에서는 교수가 수업에 시도할 엄두도 못내어 어렴풋이 들어본 정도가 대부분일 수도 있다. 최근에는 github와 git이 동일 한 것인줄 아는 한 현직 개발자를 본 적도 있다. git은 버전 관리 소프트웨어이고 github는 git을 사용하여 서비스하는 것임을 모르고 있던 것이다.

Test

수많은 글들이 TDD를 주창하고 TDD를 설명하고 있다. test가 전혀 뭔지 몰라도 배울 수 있는 좋은 포스팅이 많다. 그러나 내가 가장 싫어하는 것이 test다. 일단 test를 작성하기 시작하면은 재미있고 CI가 된 상태라면 매우 편해지지만 회사에도 가장 실현하기 어렵고 지속되기 어려운 것이 test가 아닐까 생각한다.

심리적인 측면에서의 Test

Monit/Analytics

자신이 만든 프로그램을 잘 배포 했다면 프로그램이 잘 동작하는지 확인 하여야한다. CI를 통과해서 Deploy 되었다면 매우 안심이 되는 한편이지만 멋진 그래프를 보면서

pm2의 경우 나름대로 멋진 UI를 가진 moniotring 플랫폼을 제공하고 있다.

iOS 또는 Android App을 개발한다면 firebase의 Analytics를 사용 해 볼법도 하다. Web이라면 Google Analytics를 생각 해 볼 수도 있다.

실제 회사에서 서비스를 하나 런칭하고 나면은 질리도록 말하는 '성장'을 위해서 여러가지 분석을 하게 된다. 사용자 연령층은 어떠한지 성별은 어떤지 사용 시간과 어떤 메뉴를 얼마만큼 누르는지 데이터를 통해 또 다른 직감을 얻어나간다.

학생이야 재미있게 만들어서 배포한 뒤에 여러가지 개선점을 스스로 생각하면된다. 만약 배포한 프로그램이 좋은 인기를 얻어 몇몇 사람들이 리뷰를 해 준다면 더 좋을 것이다. 내 앱을 어떤 사람들이 그리고 어떤 디바이스를 사용해서 어떻게 사용하고 있는지 데이터를 체계적으로 축적 해 둔다면 또 질리도록 말하는 '인사이트'를 기르는데 많은 도움이 된다.

댓글0