[2022 회고] 주니어 개발자가 갖추어야 할 5가지 역량
2022년 회고를 작성하자니 이미 2021년 회고 이후 퇴사 부검 그리고 수습 기간 회고까지 작성했기 때문에 딱히 적을 이야기가 없다.
그래서 약 반년 동안 스타트업에서 근무하며 사수에게 배운 업무 역량 중 주니어 개발자가 꼭 키워야 할 업무 역량 5가지에 대해 적어보려 한다.
어떻게 보면 마인드셋이고 어떻게 보면 업무 스킬이지만, 꼭 필요한 역량이라 생각하는 내용들이다.
나 자신에게 중요하다고 되뇌기 위해 회고라는 이름으로 정리해 본다.
1. 업무 히스토리를 기록하자
업무를 할 때는 꼭 무엇을, 왜, 어떻게, 어디서 했는지를 남겨야 한다. 언제는 작성일이고 누가는 본인이다.
어떠한 문제를 해결하기 위해 이슈를 생성하였고, 이 이슈를 ~~ 에서 무엇을 해서 어떻게 처리했는지를 남긴다.
같은 작업을 한 번 이상 반복하게 될 때 이러한 히스토리는 강력한 무기가 된다.
정말 가끔 같은 작업을 반복해야 하는 경우 효과는 배가 된다.
작성할 때는 블로그를 작성하는 것과 같이 이 업무를 처음 접하는 사람도 보고 따라 할 수 있도록 작성하는 것이 좋다.
이런 부분에서 블로그에 글을 작성해오던 것이 도움이 되었다.
또, 문제를 해결하며 사용했던 쿼리를 남기거나 관련하여 물어보면 좋을 참고인을 멘션 해두는 것도 도움이 된다.
유사한, 또는 같은 문제를 해결하기 위해 했던 일을 반복하거나 물어본 질문을 또 묻게 되는 자원 낭비를 줄일 수 있다.
이렇게까지 히스토리를 남기는 이유는 물론 나 또는 팀원이 같은 문제를 해결해야 하는 일이 생기거나 수정해야 하는 일이 생겼을 때를 위해서지만 사수에게 배운 더 중요한 이유가 또 있다.
바로 내가 없는 경우를 위해서이다.
사실 주니어 개발자는 팀에서 내가 없는 경우를 생각하기 어렵다. 주니어라 경험을 쌓기 위해 이직 생각이 없을 확률이 높기 때문이다.
하지만 언제든 나는 이 팀을 떠나 다른 팀으로 갈 수도 있고, 내 팀원들도 마찬가지이다.
평소에 작성 해둔 히스토리는 곧 이슈 단위의 인수인계서가 된다.
만일 내가 다른 팀에 갔는데 상세히 작성된 히스토리가 있다면 작성자를 찾아가 커피를 사주고 싶을 만큼 고마울게 분명하다.
2. 확장성을 고려하자
최근 진행한 프로젝트의 기획에는 수정, 삭제 기능이 없었다.
간단히 설명하자면 1:1 게시판처럼 게시글을 작성하면 작성자와 수신자가 서로 해당 글에 답글을 달며 소통할 수 있는 기능이다.
수정, 삭제를 고려하지 않고 설계를 하자 테이블 9개짜리의 적당한 관계가 설정되었다.
하지만 언제나 기획은 변하기 마련이고 스타트업은 MVP를 출시한 후 사용자 니즈를 바탕으로 LEAN 하게 제품을 개선해야 한다.
그래서 기획에 없지만 수정, 삭제가 가능하도록 테이블과 기능을 분리했다.
수정, 삭제가 없이 시작해버리면 나중에 수정, 삭제에 대한 필요가 생겼을 때 손 쓸 방도가 없었기 때문이다.
테이블이 9개에서 14개까지 늘었고 업무량과 복잡도가 곱절이 되었다.
정말 기획대로 수정, 삭제를 사용하지 않는다면 불필요한 쓰레기 코드를 생산한 게 될 수도 있다.
하지만 엔지니어라면 자신이 설계하고 제작한 제품에 대한 오너쉽이 있어야 한다고 생각한다.
돌아만 가면 되지, 시키는 것만 하면 되지, 나중에 해달라면 그때 고치지 뭐, 하 바쁜데 그냥 덮어 둘까..? 그냥 안된다고 해? 필요 없다며!
부족한 사람인지라 이러한 생각을 매번 이겨내지는 못하지만 적어도 내가 작성한 코드와 내가 설계한 구조에 대해서는 이유가 있어야 한다.
그렇지 않다면 내 코드는 누가 봐도 인정하는 레거시가 되어 아래 사진과 같은 상태가 되고야 만다.
물론 강박처럼 불필요한 코드를 미리 다 마련해 두는 것은 옳지 않다.
하지만 비즈니스를 두고 고민해 볼 때, 고려해둔 기능을 언젠가 제공하는 것이 유리하게 작용할지 고민해볼 필요는 있다.
3. 로그, 에러 리포팅 분석을 루틴으로 만들자
우리 팀은 Sentry를 사용하여 서비스에서 발생하는 에러와 예외처리를 리포팅받고 있다.
팀에 합류한 초기에는 서비스 파악하기도 바쁜데 무슨 말인지도 모를 내용들이 올라온다고 눈에 들어오지 않았다.
그때쯤 내 실수로 인해 일부 데이터가 꼬여서 간헐적으로 해당 데이터를 사용하는 경우 예외가 발생한 적이 있었다.
나는 앞에서 말한 것처럼 내 앞가림하기도 바빴기 때문에 전~~ 혀 모르고 있었다.
사수는 이 문제를 에러 리포팅에서 확인하고 나에게 "현재 이러이러한 문제가 발생하고 있으니 확인하고 처리해 달라" 전달해주었다.
에러 리포팅과 로그는 이미 문제가 발생한 뒤에 원인 파악과 빠른 대응을 위해 존재한다.
충분한 정보의 로그가 없다면 문제가 재현되더라도 원인을 파악하기가 어렵다.
또 에러 리포팅이 없다면 문제가 발생하더라도 VOC로 유입되거나 로그를 열어보기 전까지는 문제가 발생했다는 것을 알기 어렵다.
하지만 충분한 정보의 로그와 에러 리포팅이 있더라도 이를 확인하지 않으면 무용지물이다.
이런 일이 있은 이후 매일 출근 직후, 업무 중간 틈틈이, 퇴근 직전에 모든 에러 리포팅을 확인하는 것을 업무 루틴으로 만들었다.
에러 리포팅 확인 후에는 여러 차례 발생하거나, 어느 기점부터 급증한 에러는 어떤 문제가 있는 것은 아닌지 확인해 본다.
또, 별다른 처리가 필요하지 않지만 너무 많이 발생하는 에러는 예외를 발생시키지 않고 처리하는 방법으로 바꾸는 것을 고민해보기도 한다.
4. 테스트 코드가 곧 문서이다. 진짜로.
나는 이전 직장에서 테스트 코드가 없이 개발 된 프로젝트를 넘겨 받았다.
개발자는 나 혼자였고 모든 요구사항의 데드라인은 언제나 ASAP이였다.
그래서 테스트 코드 작성은 나중에.. 나중에. .지금은 할 수 없다 말해가며 하지 않았다.
매번 배포를 진행한 뒤엔 해당 기능과 주변 기능을 직접 눌러가며 테스트했다.
그러다 문제가 생기면 유추하여 수정하고 다시 배포하고 다시 테스트하기를 반복했다.
내 정신과 시간을 정말 많이도 갉아먹었던 방법이고 그 마저도 완전하지 못한 지엽적인 테스트였을 뿐이다.
지금 돌이켜보면 테스트 코드 작성하는 시간이 그때 했던 테스트 시간보다 훨씬 짧았을 것이 분명하다.
지금의 팀에서는 테스트 코드를 필수로 작성하고 CI를 한다.
하지만 테스트 케이스에 대한 경험과 배움이 적었던 내가 작성한 테스트는 CI를 통과했지만 장애를 일으키는 간첩 같은 코드였다.
정말 기적의 코드가 아닐 수 없다. 테스트 통과를 위한 테스트였을 뿐이다.
그런 일이 있은 후 최대한 테스트를 꼼꼼히 다양한 케이스를 설정하여 수행하기 위해 노력하고 있다.
그렇게 테스트를 작성해보니 이제야 테스트 코드가 곧 문서라는 말이 이해가 된다.
[단위 테스트 작성에 대한 모범 사례 - Microsoft Learn]에 보면 아래와 같은 챕터가 나온다.
테스트 이름 지정
테스트의 이름은 다음 세 부분으로 구성되어야 합니다.
테스트할 메서드의 이름입니다. 테스트 중인 시나리오입니다.
시나리오에서 호출될 때 예상되는 동작입니다.
이름 지정 표준은 테스트의 의도를 명시적으로 표현하기 때문에 중요합니다.
테스트는 단순히 코드가 작동하는지 확인하는 것 이상이며, 문서도 제공합니다.
단위 테스트 도구 모음을 살펴봄으로써 코드 자체를 조회하지 않고도 코드의 동작을 유추할 수 있습니다.
또한 테스트가 실패하면 예상을 충족하지 않는 시나리오를 정확하게 확인할 수 있습니다.
아래 예시는 단편적이지만 테스트가 곧 문서라는 의미를 잘 나타낸다.
각 테스트 메서드 이름과 DisplayName을 보면 테스트를 실행하지 않더라도 해당 테스트가 어떤 것을 검증하고자 하는지 알 수 있다.
게다가 시나리오가 실패했을 때의 상황도 테스트 코드로 작성하여 어떤 상황에서 실패하고, 실패할 경우 어떻게 처리되는지도 확인할 수 있다.
만일 어떤 코드의 동작 방식이나 시나리오를 알고 싶다면 더는 해당 코드를 호출 순서대로 따라가며 읽지 않아도 된다.
테스트 코드를 보고 어떤 메서드가 어떤 동작을 하는지, 어떤 시나리오에서 어떻게 동작하는지, 어떤 상황에서 실패하는지를 읽으면 된다.
테스트 코드가 곧 문서다. 진짜로.
테스트 코드가 문서가 되는 정도가 되었다면 이제 자연스레 TDD를 적용해 볼 수 있다.
우리가 글을 작성할 때 주제를 정하고 개요를 짜고 문단을 나눈 뒤 핵심 문장을 고르듯이, 구현하고자 하는 대상을 정한 뒤 테스트를 위한 설정을 하고 테스트 케이스를 나눈 뒤 시나리오를 작성하면 된다.
대신 최대한 다양하고 자세하게 테스트 케이스를 작성한다.
그 후에는 TDD 법칙을 따라가면 그만이다.
첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
5. 느리더라도 제대로 하자
주니어일수록, 자신의 개발에 자신이 없을수록 빠른 개발이 실력이라고 생각하기 쉽다.
하지만 빠르게 구현하고 빠르게 수정하면 사소한 곳에서 문제가 생기고 그 문제를 수정하느라 더 오래 걸린다.
일단 멈추고, 궁리한 뒤 행동하라 라는 제목의 기사에서 좌산 이광정 상사는 아래와 같은 말을 전한다.
나쁜 마음은 정리하고, 좋은 마음은 살리고, 챙겨야 할 것은 때를 놓치지 않고 챙기는 게 유념하는 것이다.
챙겨야 할 것을 놓쳐버리면 무념한 것이다.
가령 가스를 틀어놓고 외출하거나, 운전대를 잡고도 무념하면 언제 목숨을 잃을지 모른다.
경계가 오면 우르르 덤비지 말고, 일단 멈춰 서서 상황을 예의 주시하면서 정확히 판단하고, 그다음 결과에 따라 행동해야 한다. 유념을 습관화하는 게 중요하지만, 그게 끝이 아니다.
일의 결과가 잘될 때까지 잘 챙겨야 유념을 잘한 것이다.
일이 잘못됐다면 유념을 챙기는 게 어딘가 부실했다는 증거다.
- 출처 [일단 멈추고, 궁리한 뒤 행동하라]
사실 역시 여전히 잘 되지 않는다.
내가 배포한 기능에서 예외가 나거나 장애가 발생하면 일단 식은땀부터 주룩 흐른다.
원인을 파악하는 동안 심장 박동은 빨라지고 코드를 수정하는 동안 머리는 차가워진다.
커밋을 하는 동안 눈앞은 깜깜해지고 PR을 작성할 때는 손이 떨린다.
하지만 일단 멈춰야 한다. 느리더라도 제대로 해야 한다.
수습 기간 회고 게시글에 이런 말을 적었었다.
지난 3개월을 돌이켜 보고 한 순간을 꼽자면 지난 어느 날 내 잘못으로 인한 문제를 복구하기 위해 회사에 남아 있던 날 밤
나에 대한 기대치가 낮아졌으니 기회로 삼아 서두르지 말고 느리더라도 바르게 가자
던 사수의 말이 기억에 짙게 남는다.
여전히 잘 되지 않는다.
언제나 마음이 급해지고 더 빠른 기능 구현이 나를 지켜주는 것 같다.
하지만 급하게 할수록 구현 사항을 놓치거나 사이드 이펙트가 발생할 가능성이 높아진다.
결국 나를 더 실력 없고 빈틈 투성이의 개발자로 만들 뿐이다.
느리더라도 제대로, 제대로 하는 것은 주니어 때 꼭 필요한 업무 역량이라 생각한다.
계속 이야기하자면 꼰대가 되어 얼마든지 중요하다고 생각하는 역량을 설파할 수 있다.
하지만 나도 잘 지키지 못하는 이야기를 나불대봐야 정말 꼰대 밖에 더 되나 싶다.
2023년에는 위의 5가지 만큼은 잘해내는, 초보 티를 벗은 주니어가 되어야지.
P.S.
얼마 전 첫 콘퍼런스로 NHN forward 2022에 다녀왔다.
정말 많은 사람들이 방문했고 정말 재밌는 콘텐츠가 많았다.
각 세션들은 정말 알차고 멋진 이야기들이었고 이래저래 얻어 온 것이 많았다.
따로 후기를 작성하고 싶었지만 하루 종일 트랙을 들었다 보니 어떤 내용을 써야 할지 감이 잘 오지 않아서 하지 못했다.
참 많은 수의 개발자들이 참 다양한 회사에서 많은 노력을 하는구나 느낄 수 있던 날이었고,
조금의 무력감과 약간의 야망이 간헐적으로 스파크를 내던 하루였다.
그리고 어느덧 블로그를 운영한 지 2년이 되어 간다.
그나마 이 블로그를 통해 얻은 가장 눈에 보이는 것인 광고 수익에 대해 말해보려 한다.
구글 애드센스는 심사를 통과하고 작년 7월부터 노출하기 시작하여 1년 반 정도 달았는데 9월에 지급 기준액인 100달러를 한번 정산받았다.
그에 비해 애드 핏은 처음부터 가능해서 2년째 노출 중인데 그동안 모인 수익이 정말 적다
블로그를 개설한 초반에는 글도 적고 방문자도 없어서 동기부여가 될 만한 소지가 적었는데 광고를 게시한 이후로는 나름의 돈기부여가 되어 100달러 수익을 목표로 열심히 했던 기억이 있다.
이때는 정말 블로그 주도 개발이라고 농담할 정도로 블로그에 글을 쓰기 위해 공부를 했을 정도였다.
개발을 공부하기 시작하면서 블로그를 시작한 것은 정말 큰 도움이 되었다.
지금 이렇게 회고라는 이름으로 나에게 필요한 역량을 되뇌는 것도 블로그 덕분인 것 같다.
말로만 제대로 된 콘텐츠를 발행하고 싶다고 하고 사이드 프로젝트를 연재하고 싶다고 한지도 2년째다.
민망할 정도로 조악하더라도 내년에는 꼭 작은 사이드 프로젝트를 설계부터 배포까지 연재해 봐야지.
조금은 이르지만 여기서 2022년을 정리한다.
