🤗 이 글에는 욕설이 없습니다. 누구나 읽을 수 있는 안전한 글입니다.

아무도 안 가르쳐 주는 내용을 적어 봤다. 학생일 때는 전혀 몰랐지만 직업을 갖고 일을 시작하니 정말 중요했던 것들이다. 그러나 아무도 가르쳐 주지 않았고 당연하듯이 이런게 있는듯 행동하는 회사에서 적응하기 위해 애를 많이 써야 했다.

학생 때 알았다면 사무실 적응이 훨씬 더 편했을 것 같은 주제들, 내게 아무도 알려주지 않아서 배신감 느꼈던 주제들을 여러가지 뽑아 봤다.

📊 Log

설령 간단하게 장난감을 만들어 테스트를 해 보더라도 logging을 하는 것을 추천한다. 로그는 나중에 실제 서비스를 시작 했을 때 내 프로그램을 얼마나 많은 사람이 이용하는지 분석하는데 큰 도움이 된다.

하지만 그 무엇보다 Exception이 발생 했을 때 error log를 남기는 것이 중요하다. 뭔가 일이 터졌는데 어쩌다 이렇게 error가 났었는지 기록으로 남아야 한다. 그래야 나중에라도 내가 무엇을 잘못 한 건지 분석을 해 볼테니 말이다. 프로그램이 정상적으로 작동하지 않고 갑자기 꽥 죽어 버렸는데 error log는 남아 있지 않다면 참으로 난감해진다. 누가 돌연사 해 버렸는데 부검 할 의사도 없는 상황인 것이다.

특히 Java에서 try catch 구문을 쓸 때 catch 내부는 아래와 같이 두는 경우가 정말 많았다. 그냥 Exception을 catch하기만 하고 아무런 처리도 하지 않는 경우도 많았다. 그렇게 둘 경우 try를 쓴 이유가 거의 없다. 아래 코드 처럼 말이다.

try {
    doSomething();
} catch(IOException e) {
    e.printStackTrace(); // default.
}

보통 이런 코드는 IDE에서 자동 완성 해 주는 기능을 엔터만 휘갈겨서 남은 경우들이 많다. 학생 때는 뭐 어차피 나 혼자 쓰는 코드니까 아무 생각 없이 IDE가 추천 하는대로 코딩 했지만 회사에서는 이러지 말자. 물론 회사에서도 이런 코드는 많이 발견 된다. 아무튼 너는 그렇게 하지말자. 이제는 아래 처럼 로그를 남기도록 하자.

try {
    doSomething();
} catch(IOException e) {
    log.error(e);
}

물론 이런식으로 로그만 툭 싸고 끝나는 것 보다는 Exception을 처리 할 수 있으면 더욱 좋다. 만약 이 Exception이 일어 났을 때 복구를 할 수 있다면 그런 처리를 해 주는 것이 좋다.

try {
    doSomething();
} catch(IOException e) {
    log.error(e);
    goto RETRY;
}

🎡 Log Rotation

logging 라이브러리를 잘 써서 로그를 잘 남겼다. 근데 이런다고 끝이 아니다. 막상 어플리케이션을 서버에서 실행하고 서비스를 하기 시작하면 날이 갈 수록 로그가 쌓여가기 시작한다. 1년 동안 서비스를 했다면 365개의 파일이 생기는 것이다.

log는 텍스트 로만 이루어져 있지만 이게 은근히 용량을 많이 차지한다. 인기 서비스라면 하루에 수천만 개의 로그가 쌓이고 사용자까지 많다면 억대로 쌓이는 경우도 봤다. 로그를 자세히 남긴다면 하루치 로그가 100GB를 넘는 것은 일도 아니다. 대형 포털에서 일하게 된다면 반드시 그럴 것이다.

나도 처음엔 text로만 이뤄진 log file을 만만하게 생각했었다. 한 번 큰 코 다친 적이 있었다. 영화관에서 혼자 즐겁게 감상을 하고 있는데 갑자기 경고 알람이 날아 왔다.

⚠️ [WARNING]
디스크 사용률이 80%를 넘었습니다!

디스크 용량이 500GB에 육박하는 서버였는데 로그 파일이 너무 많이 쌓여서 공간이 부족 해 져 가고 있던 것이다. 끊고 나가긴 아까워서 무시하고 있었는데 85%… 90%… 못본척 하려다가 '95%' 알람이 오는걸 보고 전력질주로 집에 달려갔다.

결국 프로그래밍을 해도 끝난게 아닌 것이다. 코드를 잘 써서 예외 처리를 잘해도 로그를 잘 남겨야 하고, 로그를 잘 남기면 로그가 꽉 차지 않도록 과고 로그를 지워줘야 한다. 이것을 log rotation이라고 하는데 참 무엇하나 간단하게 없고 할게 너무 많다.

아래에서 소개하는 것 외에도 nginx log rotate, go log rotate 등으로 검색하면 각 진영별 툴을 만날 수 있다.

📎 pm2 log-rotate

pm2에서는 log-rotate라는 플러그인을 제공하고 있어 위에서 내가 겪은 문제를 쉽게 해결 할 수 있다.

📎 Sentry

난 이 모든게 다 싫고 귀찮다? sentry를 추천한다. Exception이 발생하면 자동으로 이메일로 알려주고 스택 트레이스 정보를 이슈로 등록 해 줘서 나중에 신경을 써 주기가 매우 쉽다. 장난감 프로젝트들은 돈 받고 하는 회사 일도 아니라서 개발 해 놓고 신경을 쓰기가 무척 어렵다. 특히 Exception들은 log를 뒤져 찾아 내는 것도 귀찮고 따로 메모를 해 놓자는 그건 더 귀찮다. 그래서 난 혼자 개발 할 때 이 플랫폼을 써 왔는데 최근 들어서는 Sentry를 도입하는 회사가 늘어가는 것 같다.

🏞 ENV

리눅스를 잘 다루면 좋다는 점은 아무리 말 해도 지나치지 않을 것이다. environment는 node를 다룰 때 많이 접하게 된다. OS 환경변수 설정으로 development 환경이냐, production 환경을 구분해서 logging을 하도록 하면 print로 코드가 지저분 해지는 것을 잘 막을 수 있다. ENV는 아래에서 설명할 config와 관련이 깊다.

나는 개발이란걸 하면 마냥 서버 하나만 있으면 된다고 생각했다. 그러나 회사에 가 보면 개발용 서버인 dev와 진짜 서비스용인 prod가 있을 것이다. stage라는 서버도 따로 있는 경우도 있다. 서비스가 더 복잡하면 stage1, stage2.. .까지 환경을 구성 해 둔다. 따라서 서버의 환경은 대략 아래와 같다.

local --- dev --- stage1 --- stage2 --- prod

대체 왜 이렇게 많이 서버를 두는 걸까? 회사에서 일을 해 본 지금은 당연히 있어야 한다고 생각하지만 대학생 때는 도저히 이해 할 수도 없었고 설명을 들어도 와닿지도 않았다. 일단은 좋은 구절이 있어서 아래 한 문단을 인용 하였다.

환경이 많아지면 조금 더 다양한 형태의 검증과 각 stakeholder (테스터, 개발자, 사용자 등)별로 테스트가 쉽지만 반대로, 각 환경을 유지 하는데, 필요한 서버들과, 운영 인력이 많이 소요되는 단점이 있다.

📎 https://bcho.tistory.com/759

🔧 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하는 등의 방법이 있다.

그래서 config의 관리가 중요하다. 코드를 실행 했을 때 이것이 내 local에서 실행 될 것인지 아니면 dev용 서버에 배포되어 테스트 할 건지 결정하기 위해 실행 할 때 마다 코드를 고칠 수 없기 때문이다. dev서버의 주소를 넣었다가 그대로 prod에 배포 해 버리면 무슨 일이 벌어질지는 불보듯 뻔하다.

🧪 Test

수많은 글들이 TDD를 주창하고 TDD를 설명하고 있다. test가 전혀 뭔지 몰라도 배울 수 있는 좋은 포스팅이 많다. 그러나 내가 가장 싫어하는 것이 test다. 나는 학창 시절 시험을 쳤다하면 늘 꼴지였기 때문에 그냥 '테스트'라는 단어 자체에서 부터 오는 거부감이 상당했다. 😞.

테스트란 내가 작성한 코드가 내가 의도한대로 잘 작동하는지 검사 해 주는 코드 또는 과정을 말한다. 나는 처음 이 말을 듣고 잘 이해하지 못했다.

아니 처음부터 집중 해서 잘하면 되지 내가 잘 짰는지 검증 하는 코드를 만들어 둔다고? 그럼 내가 잘 짰는지 검증하는 코드를 잘 작성했는지 검증하는 코드는 안 필요 한 모양이지?

내가 만약에 어떤 함수를 작성했다고 가정하자. 이 함수가 하는 일은 게시판에 글을 쓰는 것이다. 그렇다면 테스트 코드를 대충 아래와 같은 정도로 써 볼 수 있다.

Test() {
    // 일단 글을 쓴다.
    Post("으아아 이건 내 글 제목", "글 내용")
    
    // 이제 리스트에 내가 쓴 글이 있는지 확인 해 본다.
    var list = PostList()
    
    if (list.contain("으아아 이건 내 글 제목")) {
      return true // 예아 테스트 성공
    } else {
      return false // ??? 내가 쓴 글 어디감?
    }
}

내가 쓴 함수를 내가 호출해서 확인 해 보는 과정이다. 늘 우리가 코드 중간에 print 넣어서 디버깅(?)하는 과정을 코드로 써 둔 것이라고 표현할 수도 있다. 그렇담 이 Test 함수는 어디서 호출 하는데? 그것이 아래와 같은 명령어들이 존재하는 이유다.

npm test

javascript에서는 이 모든 테스트 과정을 체계적으로 도와주는 것이 📎 Jest나 Mocha와 같은 테스트 도구들이 있다. JAVA에는 📎 JUnit이 있고 이건 아마 테스트가 뭔지 몰라도 한 번쯤 들어 봤을 정도로 유명 한 툴이다. 벌써 테스트에 관심이 생겼다면 한 번 여러분이 쓰는 언어에는 어떤 테스트 도구들이 있는지 검색 해 보자.

나는 그 유명한 켄트 벡의 📎 테스트 주도 개발이라는 책을 읽어 본 적이 없다. TDD라고 부르는 이것에는 아주 많은 논쟁이 있다. 아니 그냥 코드 쓰기도 바쁜데 테스트 코드를 쓸 시간에 '진짜' 코드를 쓰는게 훨 낫다는 주장과, 초기에 시간이 더 들더라도 오히려 나중에는 테스트 코드 덕분에 버그도 덜 생기고 더 탄탄한 SW를 만들게 됐다는 주장이 있다.

수 많은 논쟁이 있지만 아무튼 TDD는 분명히 업계에서 적용되고 적극적으로 사용하는 곳도 있는 '방법론'이다.

나는 미친놈이라 "TDD는 별로에요" 또는 "TDD는 무조건 해야하는데요?"라고 어느 쪽도 입장은 안 정했다. 그냥 팀이 하자고 하면 따라서 했고 안 하면 내가 하자고 하는 청개구리 같은 놈이었다. 🤪. 그래도 이 말은 하고 싶다.

REST API 서버를 개발하고 있다고 치자, 최소한 request에 대해 200 OK status가 오는지 확인 하는 코드 한 줄이라도 있는 것이 좋다고 생각한다.

최소한의 테스트 코드라도 작성 해 두면 git push를 할 때, deploy를 할 때 망설임이 없게 된다. 필요한 코드를 쓸 때도 부담이 덜 하다. 만약 내가 뭔가 잘못 했다면 테스트 코드가 검증을 해 낼 테니까.

😶 당연히 이 모든건 test code를 잘 작성 했을 때의 이야기다. test code가 개판인데 test가 잘 될리가 없다. test code도 사람이 작성하는 것이기 때문에 당연히 에러가 있을 수 있고 test를 통과 했다고 해서 quality를 확실히 충족 했다고 볼 수도 없다.

🏗 git

이건 요즘 학생들도 많이 알고 많이 배우고 나보다 더 잘 알 것이라 생각한다. 그러나 지잡대에서는 교수가 git을 수업에 시도할 엄두도 못내어 어렴풋이 들어본 학생도 있을 것이다.

얼마전에는 github와 git이 같은 것인줄 아는 개발자를 본 적도 있다. git은 버전 관리 소프트웨어이고 github는 git을 사용하여 서비스하는 것임을 모르고 있던 것이다. 요즘 공부하는 10, 20대 학생들은 이 정도는 아니다.

git은 기본적으로 잘 익혀 두는 것이 뭔 프로젝트를 하던간에 편하다. 만약 git을 모른다면 지금 부터 알아라. 또 반드시 git을 사용해서 친구끼리 협동을 해 보아야 한다. git의 rebase 같은 커맨드는 직접 협업을 해 보지 않으면 쉽게 와닿지 않는 것들이 많다.

또 git commit을 할 때 commit message를 어떻게 작성하는 것이 좋은지 팀과 합의 할 수 있는 좋은 방법도 있다. 📎 Node 프로덕트 퀄리티를 높이는 협업 방법의 Commit message convention을 참고 하면 좋다.

📎 Gitflow Workflow

여러명이서 git을 쓸 때 branch를 어떻게 구성하고 각 branch는 어떤 역할을 해야 팀이 협업 할 수 있을까? 이 방법들을 'Branch 전략'이라고 불리기도 하는데 그 중 gif flow라는 것이 유명하다. 이와 관해서도 공부 할 것이 많다. 잘 설명 된 글을 첨부한다.

📎 Git Kraken

나 같이 눈 앞에 안 보여주거나 그림으로 안 그려주면 이해 못하는 바보들을 위해 만들어진 툴이다. git의 flow를 소스 트리 처럼 시각화 해 주어서 좋다. Merge나 Cherry Picking 같은 것도 마우스로 딱딱 클릭해서 처리 할 수 있으니 좋다. 그러나 맥북에서는 켰다 하면 꼭 배터리를 많이 소모하는 앱 1위로 등극한다. 사실 commit, push는 그냥 cli가 훨씬 빠르고 크라켄은 그냥 눈으로 확인하거나 rebase하는 용도로만 쓰고 있다.

⚠️ git의 브랜치 전략은 git을 사용 해 본 사람도 어렵고 git을 모르면 당연히 어렵다. 지금부터 당장 이것들 모조리 공부 해야 하는 것은 아니다. 적어도 이런 것이 있다는 점을 알고만 있어도 회사 갔을 때 두려움에 와들와들 떠는 일은 없다. 마치 교과서 처럼 git을 공부하지 말고 자신의 개인 프로젝트에 직접 적용 해 보면서 끊임 없이 익숙 해 져 가는 것이 훨씬 더 큰 공부가 된다.

🦾 CI/CD

git commit과 git push 한 번으로 위에서 말 한 테스트와 배포를 자동으로 할 수 있다. 이 사실을 알았을 때 얼마나 충격이었는지 모른다. 내가 학생일 때는 이런걸 가르쳐 준 사람이 없었다.

요즘에는 워낙 좋은 PaaS와 서비스들이 많아서 CI/CD가 뭔지 잘 몰라도 버튼 몇번이면 다 해 낼 수 있다.

정말 간단하게 CI/CD를 해내고 싶으면 Heroku를 무료 버전으로 써도 좋다. Hroku에 github repository를 등록하면 내 깃허브에 push 할 때 마다 자동으로 Deploy를 해 주고 심지어 호스팅까지 해 준다.

Gitlab도 좋다. gitrunner를 사용하는 방법에 대해서 한 번 써보고 싶다.

유료이긴 하지만 Digital Ocean도 좋았다. 학생이라면 50$를 무료 크레딧으로 제공한다. 1년 정도는 쓸 수 있는 액수다.

일주일에 몇번 Deploy하느냐, 얼마나 자주 deploy를 할 수 있느냐가 App Quality에 영향을 미치게 됐다. 수 년전 부터 Facebook과 Twitter의 모바일 앱은 Quality Improvement라는 짤막한 내역과 함께 Regular update를 하기 시작했다. 장난으로라도 개발을 할 때는 CD가 갖춰지면 매우 편하다. 어쨌든 열심히 코드만 다듬으면 되니까.

🔍 AMP/Analytics

자신이 만든 프로그램을 잘 배포 했다면 프로그램이 잘 동작하는지 확인 하여야한다.

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

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

📎 Sentry

처음에 Log에서도 추천 했던 Sentry이다. 모니터링에도 해당 되는 것 같아서 그냥 같이 링크 걸어 두었다.

📎 pm2 monitor

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

📎 Google Analytics / Firebase

iOS 또는 Android App을 개발한다면 firebase의 Analytics를 사용 해 볼법도 하다. Web이라면 Google Analytics를 생각 해 볼 수도 있다. GA로 많이들 언급하는 구글 애널리틱스는 꼭 개발자들만이 알고 있는 것은 아니다. 마케팅을 일삼는 사람들 역시 GA를 공부하곤 한다.

🐞 Debugging / Profiling

가장 잘 해야 하는 것이고 중요한 부분이 될지도 모르겠다. 한창 개발만 부여잡다가 어느 날 스택을 추적하거나 디버깅을 해야 할 상황이 생겼을 때 어떤 버튼을 눌러야 되는지 조차 몰랐다. 자신에게도 너무 부끄러운 순간이었다. 디버깅을 하는 방법은 반드시 알아두도록 하자.

프로파일링은 함수의 실행 시간이나 이벤트가 발생한 빈도 등을 측정해 내 프로그램의 성능을 높이고자 함이다. 썩 괜찮게 만들어 놨다고 생각해도 막상 프로파일러로 실행 시간을 보면 분명히 실수하거나 이전에는 몰랐던 지식 때문에 크게 느려지는 구간이 하나 쯤 나타난다.

특히 구글링과 기타 블로그에 널리 퍼져 있는 코드들을 그대로 따라서 쓰기 전에 프로파일러로 검증을 해 보는 것을 추천한다. 아무리 유명하고 간단하고 확실해 보이는 코드라도 뭔가 이상한 점이 다 하나씩 있다.

📎 Flow

콘솔 화면이 아무리 멋있다지만 시각화 해 줄 수 있는게 최고다. 실행 시간이 그래프로 나와 있다면 막대기 제일 큰 놈이 제일 느린 놈 아닌가? 그 함수만 죽어라 빠르게 만들면 100점 만점에 최소 80점은 받을 수 있다. Spring으로 개발을 할 때 자주 사용했었고 병목구간을 많이 잡아 냈었다. 정말 좋아 했던 툴인데 최근에는 커뮤니티가 박살이 난건지 이 프로젝트를 이어 받아서 계속 개발할 사람을 구한다는 메일을 보내 오더라. 그래도 아직은 쓸만 하다고 자신한다.

📎 Lighthouse

내가 만든 웹 페이지가 옹골찬 PWA 페이지인지 검사 해주는 툴이다. PWA에 대해선 알아서 알아보자 미안하다.

📎 Artillery

Node로 서버를 만들었다면 서버의 성능을 측정 하고 싶을 것이다. velog에 Artillery를 설명해 주신 분이 있어 이 글을 보면 좋다. 📎 Node환경에서 Artillery를 활용한 스트레스테스트

💰 toss로 서포트하기