1년이 지났다.
난 뭐했냐!

서론

철저하게(?) 직장인이 되어가고 있었다. ^-^v
학교에서 배우지 못한걸 많이 배웠다. 당연하다. 그것이 신입이니까.
연차가 쌓이고 나서 예전 추억을 보며 흐뭇한 겸손한 마음을 가지기 위해 + 한 스텝씩 밟아 올라가는 기록을 남기기 위해 + 누군가에게 도움이 되지 않을까 하는 마음에 이 글을 적는다.

학교 수업에서는 알려주지 않았던 내용들.

🧪 테스트와 설계

테스트와 설계에 드는 시간

새 기능을 만들거나 기존 기능을 수정해야 할 때, 각 작업별로 드는 시간은 다음과 같다.

(이걸 어떻게 만들지 생각하기) > (테스트하고 뜯어고치기) > (코드 적기)

학교 과제를 하기 전에도 물론 '이걸 대체 어떻게 해야 하지???' 라는 생각을 하겠지만, 실무에서는 그것보다 좀 더 고려할게 많아진다. '이건 어떻게 하고 저건 어떻게 하며 그건 어떻게 해야하지 ????' 정도다.

이전에 없던 새 기능을 만드는 상황이라면 (이걸 어떻게 만들지 생각하기) 에 드는 시간은 훨씬 많아진다. 기존 기능을 수정할 때는 (테스트하고 뜯어고치기)와 순서가 바뀌는 경우도 있었다. 어쨌든 코드를 타이핑하는데 드는 시간이 가장 적었다.

테스트와 디테일

테스트를 적당히 하고 슥 넘어가면 시간을 절약할 수 있다. 고쳐야하는 코드가 많이 발견되지 않으니 기분도 좋다. ^^ 하지만 이렇게 하다간 모두 불길에 휩싸이는 수가 있다. 내 프로그램뿐만 아니라 나와 우리 팀 모두가...! (사실 그정도는 아니다 한 사람의 실수로 모든게 불타버릴정도로 허술한 팀이라면 팀의 잘못이 아닐까)

아직은 테스트를 너무 제대로 해서 문제가 된 경우는 없었다.테스트를 너무 빡세게 해서 마감 기한을 놓치거나, 너무 열심히 해서 QA팀이 발견하는 버그가 0건일정도로 QA 기간이 무용지물이 되었다거나, 테스트에만 너무 집중해서 다른 업무에 지장이 생긴 적은 없었단거다. 아마 앞으로도 그럴 것이다. 테스트는 강조하고 또 강조해도 부족한 것 같다.

우리는 맥주집에 들어온 손님이 근처에 칵테일바는 없냐고 물어볼 상황까지 대비해야 한다. 손님이 갑자기 공중제비를 돌거나, 주방으로 난입하거나, 닌자가 등장해서 맥주집의 모든 사람을 납치해갈 상황도 생각할 수 있어야 한다. 그런 케이스를 생각해내면서 디테일을 챙기는게 중요하면서도 쉽지 않다고 느낀다.

설계와 후회

설계에 대한 후회를 한 적이 있다. 기존 설계에 따라 개발하다가 나중에 뒤엎고 다른 설계로 구현하게 된 날, 엔티티 설계를 잘못했음을 깨달았지만 이제 와서 뒤엎기는 무리라는걸 인정해야 했던 날, 개념을 오해해서 비효율적으로 설계한 다음 기존 PR을 close하고 완전히 다른 버전의 PR을 올렸던 날, ...

설계를 잘못했다고 해서 맥주집이 불타버리진 않았다. 설계 미스로 인한 문제는 그보다 더 천천히, 은밀하게 나타난다.

아래는 내 '설계 미스 모음집'이니 읽기 지루하다면 건너뛰어도 된다.

1. 기존 설계에 따라 개발하다가 나중에 뒤엎고 다른 설계로 구현하게 된 날
  예외적인 상황을 제대로 고려하지 않았다는걸 깨달았다. 카프카가 발행하는 메세지에 대한 의심을 해봐야 했는데 그러지 못했다.
  인프라의 동작 방식에 대한 깊은 이해가 부족한 상태에서 그 인프라를 너무 믿어서 생긴 일이었다.
  덕분에 개발 기간이 3주나 늘어났다.
  
2. 엔티티 설계를 잘못했음을 깨달았지만 이제 와서 뒤엎기는 무리라는걸 인정해야 했던 날
  '설계 미스 모음집' 중에서 가장 슬픈 날이었다.
  처음에는 설계한 대로 만들어도 별 문제 없었지만 이 엔티티의 역할이 커지면서 문제가 슬슬 드러나기 시작했다.
  엔티티 구조가 이상하니 DB에 날리는 쿼리가 복잡해지기 시작했다.
  NoSQL을 쓸 때는 어떤 쿼리를 보내게 될지 미리 생각해보라는 말이 와닿은 날이었다.
  
3. 개념을 오해해서 비효율적으로 설계한 다음 기존 PR을 close하고 완전히 다른 버전의 PR을 올렸던 날 
  Java Consumer Interface 를 무심코 지나쳐서 문제가 생긴 날이었다.
  일단 동작은 한다. 버그도 없고, 코드가 많이 더러워보이지도 않는다.
  하지만 인터페이스를 사용하면 훨씬 깔끔하게 설계할 수 있는걸 concrete 하게 만들어서 코드가 장황해졌다. 

결론은, 새 기능을 만들 때 일단 스스로에게 멈춰!를 외치기로 했다. 곧바로 코드 편집기를 열고 TODO를 적는 대신 천천히 문제에 대해 생각해보는 시간을 갖는다. 예외 케이스를 찾아보고, 변화 가능성에 대해 생각해보고, 사용할 도구(인프라, 프레임워크, 개념, ...)에 대해 찾는데에 좀 더 시간을 쓰기로 했다. 하루종일 설계만 생각하다가 전체 설계에 영향을 미칠만한 예외를 찾게 되어서 안도의 한숨을 내쉰 날도 있었다.

큰그림을 머릿속에서만 그리지 말고 글이나 그림으로 구체화시켜보자. 그리고 한 부분씩 의심해보자. 그리고 아무도 믿지말자. 나도 믿지 말자.

🌏 지역

지구가 둥글어서 생기는 문제

바로 타임존이다. 보통의 서버는 UTC+0를 기본 시간대로 갖는다. 하지만 우리는 UTC+9에 살고 있고, UTC+x 지역에 서비스를 해야 한다.
학교에서는 고려해보지 않았던 문제다. 다행히도 서버 프레임워크에서 시간 변환을 자동으로 잘 해주기 때문에 대부분의 경우에는 신경쓰지 않아도 되었다. 하지만 프로젝트의 기초부터 닦아야 하거나, 타임존 적용의 대상이 되는 시간 데이터를 쌓을 때는 주의해야 한다.

언어가 달라서 생기는 문제

이 역시 범지구적인 문제라 어떻게 피해갈 수가 없다. 전세계 사람들이 한국어를 쓰도록 만들 수 있는 신의 권능이 있다면 이런 고민쯤은 필요없겠지만 우리는 다국어 문제를 고려해야 한다. '서버 개발자는 그런거 필요없지 않나?'라고 생각할 수도 있지만 서버에도 다국어 지원이 필요하다. 서버가 보내는 메세지가 있으니까! 유효하지 않은 id 값입니다. 를 N개 국어로 표현해야 한다. 나중에 노가다를 하기 싫다면 처음부터 미리 준비해두자. (물론 나도 아직 귀찮아서 다른 일에 시간을 쏟느라 + 실제로 필요할 지 몰라서 미뤄놓은 다국어 작업이 있다...^^.. 미래의 나 화이팅)

🌱 환경

로컬에선 되는데 여기선 안 되네

대학교 수업은 정말 친절하다. OT 때 보통 실습 환경 셋팅 방법을 알려준다. 내 컴퓨터의 개발환경과 테스트를 채점하는 조교의 컴퓨터 개발 환경이 서로 동일하다. 여기서 되면, 거기서도 된다.
하지만 실전에선 그렇지 않다. 왤까? 크게 3가지 원인이 있는 것 같다.

• 버전, 리소스 차이 등 팀 내부적인 개발 이슈
• '저희 아직 개발 중인데요..' 다른 팀과의 배포 타이밍 이슈
• 로컬에서 테스트했다간 컴퓨터가 욕을하며 스스로 꺼질 정도의 트래픽 이슈

그래서 보통은 로컬보다는 실제 환경에 가깝지만 실 데이터는 사용하지 않는 환경을 따로 두고 거기서 테스트를 한다. ('개발 환경'이란게 있긴하지만 실질적으로 쓰지 않는 회사도 있는 것 같다.😳) 물론 배포 타이밍 이슈는 서로 잘 조율해서 순서를 맞춰 배포하는 수밖에 없다. (일단 지금의 내가 알기론 그렇다.)

갑자기 이런 일이 ?

테스트까지 마치고 실제 운영 환경에서 잘 돌아가던 서버가 갑자기 터지는 이유는 생각보다 다양하다.

• 갑자기 트래픽이 몰려서 <-- 보통 이게 궁극적인 원인이다
• 테스트 할 땐 멀쩡하게 되던 GC가 잘 안 돼서
• 누군가 악의적인 마음을 품고 DDoS 같은 공격을 가해서
• 사용하고 있던 클라우드 서버 제공사의 시스템에 오류가 나서 <-- 이건 좀 다른 얘기다

그리고 보다 물리적인 원인도 있다.

• 서버 컴퓨터가 모여있는 곳에 불이 나서
• 서버 컴퓨터가 모여있는 곳에 자연재해가 발생해서
• 상어가 해저 케이블을 뜯어먹어서

모든 문제를 100% 예측해서 예방할 수는 없다. 예방도 중요하지만, 장애가 발생했을 때 빠르게 대처하는 방법을 익히는 것도 중요한 것 같다. 이런 얘기를 하면 꼭 나오는게 '이중화' 이야기이다. 학교 수업 중에 '분산 시스템 설계' 과목을 들어볼걸 하는 후회가 조금 된다. 지금 스터디가 끝나면 책을 한번 봐야겠다.

🤼‍♀️ 협업

컴퓨터 공학 수업과 다른 과 수업의 가장 큰 차이점은? 바로 팀플이 없다는 것. 일단 우리학교는 그랬다. 경영학과 친구가 팀플 지옥에 갇혀 허우적거리는동안 멀리서 불구경만 하면서 4년을 보냈다. (물론 졸업 프로젝트 때는 내가 스스로 불구덩이에 뛰어든 꼴이 되었지만...) 4년 내내 컴퓨터랑 대화하면서 사람과 대화하는걸 까먹은 것 같은 친구들도 종종 보였다.

하지만 그런식으로 회사를 다니다간 제대로 되는 일이 별로 없을 것이다. 이건 장담할 수 있다. 개발자는 자신이 맡은 부분을 잘 설계하고 코드를 잘 짜면 그만인 직업이라고 말하는 사람도 있겠지만 나는 정반대다. 오히려 자신의 사고과정을 다른 사람과 제대로 공유하지 않거나, 반대로 다른 사람의 작업물에 대해 제대로 파악하고 있지 않는게 스스로에게 해로운 것 같다. 그렇게 되면 결국 자기자신의 일도 영향을 받게 된다. 팀원이 새롭게 도입한 인프라 위에서 돌아가야하는 애플리케이션을 개발하는 상황을 상상해보자. 혹은, 혼자서 며칠 끙끙 앓고 있던 문제가 다른 사람이 보기엔 몇초만에 해결할 수 있는 간단한 문제일수도 있다. 집단지성이라는 단어가 괜히 생긴게 아닐 것이다.

단순히 프론트와 서버 간 API 스펙을 맞추는게 협업은 아닌 것 같다. 그정도는 개인이 해낼 수 있다. 하나의 목표를 이루기 위해 서로 다른 의견을 공유하고 결과물을 만들어내는게 진정한 협업이 아닐까.

💨 회고

학교에서는 학기가 끝나면 방학이 찾아온다. 직장에서는 방학 같은건 없지만 잠시 쉬어가는 코너가 있다. 회고 시간이다.

먼저 프로젝트를 진행하면서 좋았던 점과 별로였던 점을 먼저 나열한다. 한 사람씩 의견을 말한 다음, 각각에 대한 액션 아이템을 도출한다. 잘한 점이 있다면 그 일을 계속해서 잘하기 위해, 못한 점이 있다면 그걸 보완하기 위해 구체적으로 어떻게 행동할 지 결정한다.

그저 '좋았다', '아쉬웠다' 등으로만 끝나지 않고 액션 아이템을 도출해내니 훨씬 건설적인 시간이었다. 말 그대로 추진력을 얻기 위해 한 템포 늦춰 가는 것이다. 올해 새롭게 적기 시작한 '삽질 로그'가 있는데 여기서도 매번 액션 아이템을 도출하고 있다. '이런 실수를 했었지'를 기억하는 것보다 '이런걸 막기 위해서는 이렇게 해야지'를 기억하는게 훨씬 명확하고 실수도 줄여준다.

결론

크게 5가지 카테고리로 나누어서 회고를 작성해봤다. 테스트와 설계, 지역, 환경, 협업, 그리고 회고.

학교에서는 '어떻게 문제 없이 잘 작동하는 프로그램을 만들 것인가'를 배웠다면 실무에서는 '그 프로그램을 어떻게 설계, 테스트, 운영할 것인가'까지 고려해야한다. 그래서인지 모르는 부분이 날이 갈수록 늘어났다. 어째 일을 배우고 하나둘씩 원리를 파악해가는 속도보다, 모르는게 튀어나오는 속도가 더 빠른 느낌을 지울 수 없다. (그리고 사실일 것이다.) 언젠가 '그래도 제가 그거에 대해서 50%정도는 알아요'라고 말할 수 있는 날이 오면 좋겠다.

마지막으로 게임 업계에 종사하는 누군가가 6년 전에 올려놓은 슬라이드 페이지를 구경하며 글을 마친다. 프로그래머로써의 기본…. 신입이 알아야 할 지식.