한발 한발 나아가기

입사한 지 얼마 안돼서 새로운 프로젝트를 경험하였다. 비록 아직 서비스를 오픈한 것은 아니지만, 개발의 한 프로세스를 경험하면서 느낀 것이 많기 때문에 글을 작성해두려고 한다. 자잘한 것들까지 포함하면 발가락까지 동원해도 셀 수 없지만 크게 여섯 가지로 추려보았다. 추가로 개발 목표도 구체화해 보았다.

느낀 점

1. 엄격한 테스트 코드 작성

테스트 코드의 필요성을 크게 코드의 검증과 리팩터링, 이 두 가지에서 느낄 수 있었다.

1) 작성한 코드의 검증

일정상 기능 개발에만 급급해서 검증이 안된 api를 내보내는 경우가 종종 있다. 하지만 외부 사용자(클라, qa 등)가 버그를 발견하는 경우 더 큰 대가를 치러야 한다는 사실을 알 수 있었다. 치뤄야 할 대가는 서버에만 국한된 것이 아니며, 자세한 내용은 아래와 같다.

서버에서 들어가는 비용

• 커뮤니케이션
• 후속 조치(센트리, 키바나 등을 사용한 원인 추적, 로컬에서 재현, 로직 수정 및 재배포 등)
• 개선된 로직이 야기하는 새로운 에러의 가능성
• ...

외부(클라, qa, 사용자 등)에서 들어가는 비용

• 커뮤니케이션
• 해결되기 전까지 다음 작업이 블로킹
• 재테스트
• ...

2) 리팩터링의 어려움

테스트 코드가 없으면 검증이 어렵기 때문에, 로직을 개선하거나 프로젝트 구조를 변경하기 꺼려진다. 반면에 로직이 잘 작동하는 것을 언제든지 확인할 수 있다면 코드를 변경하는 데에 망설일 이유가 전혀 없다. 따라서 테스트 코드를 꼼꼼하게 작성한다면, 리팩터링을 통해 더 나은 코드와 더 나은 구조를 지향할 수 있게 된다.

2. 모니터링 도구의 중요성

코드에 문제가 발생하지 않도록 조기에 차단하는 게 좋다. 하지만 애플리케이션이 작동하고 있다면 이슈를 마주할 순간이 온다. 이를 해결하기 위해서는, 당연하게도 에러 추적과 원인 파악이 가능해야 한다. 이럴 때 도움을 주는 것이 모니터링 도구이다. 이를 활용하면 의도하지 않은 에러나 성능 부족을 쉽게 파악하고 대응할 수 있다.

3. 칸반 보드의 적극적인 활용

1) 백로그의 적극적인 활용

주기적으로 슬랙에 할 일들을 정리한다. 하지만 이 방법은 해야 할 일을 정리하거나 시간이 들고 종종 빼먹기도 한다. 다시 찾아보기도 어렵다는 단점도 있다. 그러지 않고 백로그를 적극적으로 활용한다면 우리는 효율적으로 남은 작업을 파악할 수 있다. 다만, 참여하는 모두가 주기적으로 관리해야 하는 게 번거로운 점이긴 하다.

2) 우선순위의 적극적인 활용

개인적으로 프로젝트를 진행하면서 우선순위를 결정하기 어려웠다. 내용을 전혀 알지 못하는 작업이 많았기 때문이다.

그래서 중요도와 시급도를 고려해서 우선순위를 구분하면 좋을 것 같다. 주어진 시간은 한정되어 있기 때문에 중요하지 않은 작업은 뭉개는 것도 좋은 방법이라고 생각한다.

• 중요 O, 시급 O
• 중요 O, 시급 X
• 중요 X, 시급 O
• 중요 X, 시급 X

4. 하나의 브랜치는 하나의 기능만 담기

한 pr에 여러 내용이 담기면 코드를 파악하기 어렵다. 무엇보다 해당 pr에 오류가 있어서 롤백해야 할 때, 여러 기능이 담겨있으면 의도하지 않은 에러가 발생할 수도 있다. 따라서 번거롭더라도 한 브랜치는 하나의 기능만을 담는 것이 바람직하다고 생각했다.

5. 외부와 맞닿은 영역(api 스펙, 에러 코드 등)을 미리 정의하기

프로젝트 구성 요소들은 크게 두 가지로 분류할 수 있을 것 같다. 내부에서만 사용되는 영역과 외부에 노출되는 영역이다.

내부에서 사용되는 영역의 예시로 내부 로직을 들 수 있다. 해당 영역은 테스트 코드가 잘 작성되어 있다면 얼마든지 로직 개선이 가능하다. 따라서 처음부터 완벽하게 로직을 구현하지 않아도 되고, 그럴 수도 없다.

반면, api와 같이 외부에 노출되는 영역은 변경이 어렵다. 이를 수정하기 위해서는 타 직군과 합의하는 과정이 필요하기 때문이다. 따라서 해당 영역은 사전에 타 직군과 함께 미 정의하는 게 중요하다고 생각한다. 그러면서 api만 뚫어도 될지, 웹 소켓을 사용해야 하는지 등도 조기에 파악할 수 있다.

6. 내가 필요하다고 생각한 작업을 독단으로 진행하지 않기

작업을 하면서 종종 어떤 기능이 필요하다고 생각이 드는 경우가 있다. 그럴 때는 나보다 이해도가 높은 사람이나 기획자와 대화해 보는 게 좋다고 느꼈다. 그 과정에서 요구사항을 명확하게 할 수도 있고, 사실 필요 없는 기능인 경우도 많았기 때문이다.

향후 목표

프로젝트하면서 가장 크게 다가왔던 것은 시급하게 구현한 메서드가 야기하는 버그이다. 일정상 테스트 코드를 작성을 생략한 게, 오히려 일정에 악영향을 줄 수 있음을 깨달았다. 에러를 효과적으로 추적하는 것도 정말 중요하지만, 그보다 에러 발생을 줄이는 게 더 효과적이다는 말이다.

기존에는 24년까지 백엔드 최고가 되겠다는 목표를 가지고 있었다. 그리고 이번 경험을 통해 목표를 더욱 구체화할 수 있었다.

먼저 소프트웨어의 프로세스를 개발, 빌드, 배포 세 단계로 구분한다. 그중 개발과 빌드 단계에서 버그 없고 변경에 유연한 애플리케이션을 지향하는 게 내 목표다. 이를 위해 테스트 주도 개발, 빠른 테스트 속도, 지속적인 리팩토링, 좋은 설계, 빠른 빌드를 추구한다. 배포 단계는 기본적인 개념과 구축 경험만 쌓는다.

대학교에서 화학공학을 전공하던 시절부터, 나는 책을 완독하는 공부법을 선호했다. n회독 할때마다 지식이 축적되고 강화되는게 느껴졌고, 실제로 좋은 성적도 받았었다. 하지만 it 분야는 기술을 직접 사용하는게 중요하다고 느꼈기 때문에, 키보드를 열심히 두들기는 형태로 학습 방법이 변했다.

취업을 하면서 지식의 바다에 빠져버린 지금, 학습 방법의 개선이 필요함을 느꼈다. 기존의 버릇이 남아서인지 기술을 사용하기 전에 최대한 많은 지식을 축적하려는 경향이 있다. 그에 따른 비효율성은 다음과 같다.

1. 막상 기술을 사용할 때는 일부의 지식만 활용한다.
2. 많은 지식들 중 어떤게 중요한 개념인지 알기 어렵다.
3. 기술을 직접 사용하기 전까지는 지식들이 와닿지 않는다. 그로 인해 흥미가 떨어진다.

학습 방법에 대해 고민하면서 여러 블로그와 책을 뒤적였다. 그 중 소프트 스킬이라는 책이 가장 잘 정리된 것 같다! 학습 방법은 아래와 같으며, 나에게 적용하면서 글을 수정할 예정이다.

학습 방법 : 1 ~ 6 단계는 한 번만, 7 ~ 10단계는 반복해서 실행한다.

1. 큰 그림을 보라
   • 앞으로 배울 주제에 어떤 내용이 있는지, 범위가 어느 정도 되는지 큰 그림을 보는 단계다.
   • 무언가를 처음 배울 때는 무엇을 배워야 할지조차 모른다. 그래서 큰 그림을 파악하는 것이다.
   • 인터넷 검색을 주된 방법으로 활용하되, 관련 도서가 있다면 서론 정도만 읽어보자.
2. 범위를 정하라
   • 집중적으로 학습할 영역을 명확히 정하는 단계다. 무한대로 늘어날 수 있는 주제를 좁혀야 한다.
   • 배우는 이유와 쓸 수 있는 시간을 고려하여, 적정한 범위로 주제를 한정한다.
3. 성공을 정의하라
   • 열심히 노력해서 도달할 성공을, 명확하고 간결하게 한 문장으로 정의하자.
   • 나쁜 기준
     • 자바 기초를 배우겠다.
     • 디지털 카메라로 좋은 사진을 찍겠다.
   • 좋은 기준
     • 자바의 주요 기능을 활용해서 간단한 응용 프로그램을 만들겠다.
     • 디지털 카메라의 모든 기능이 각각 어디에 있는지, 각 기능을 어떤 상황에서 어떤 이유로 쓰는지 익히겠다.
4. 자료를 찾아라
   • 책, 유튜브, 블로그, 소스코드 등 가능한 많은 자료를 찾는다.
5. 학습 계획을 세워라
   • 자료는 모았으니, 이것을 참고하여 무엇을 어떤 순서로 배울지 정리한다.
   • 어떤 주제든 학습 순서는 어느 정도 정해져 있기 마련이다. 4단계에서 고른 책을 여러 권 뒤적이며 목차를 살펴보는 것도 좋다.
6. 자료를 선별하라.
   • 여러 자료 중에서, 설정한 목표를 이루는데 가장 도움이 되는 자료만 고른다.
7. 대충 사용할 수준까지 배워라
   • 우리는 크게 두 가지의 실수를 범한다. 1) 잘 모르는 상태에서 너무 빨리 실전에 뛰어들거나, 2) 너무 오래 준비하느라 행동에 옮길 적절한 시기를 놓친다.
   • 기술을 사용하기 위한 최소한의 내용만 배워라. 파고 들겠다는 유혹을 이겨내야 한다.
8. 놀아라
   • 아무런 제한 없이 원하는 것은 무엇이든 해보자.
   • 자연스레 궁금증이 생기면, 스스로 고민해보고 자료를 확인하며 질문에 답을 찾자. 답을 찾지 못한 질문을 따로 적어두자.
9. 유용한 일을 할 정도까지 배워라
   • 8단계에서 답을 찾지 못한 질문의 답을 찾아보자. 또한, 모든 자료를 찾아보면 학습 대상을 깊이 있게 이해하자. 이때가 자료에 파고들어 가능한 많이 배우는 시기다.
   • 모든 자료를 전부 봐야한다는 책임감을 갖지 않아도 된다. 자료는 궁금했던 내용을 찾는 도구에 불과하다.
   • 언제든 8단계로 돌아가서 새로운 질문을 찾아봐도 좋다.
10. 가르쳐라
    • 배운 내용을 다른 사람에게 설명하는 일은, 자신이 제대로 배웠는지 확인하는 유일한 방법이다. 빠뜨린 부분을 찾아낼 수도 있다.
    • 블로그, 유튜브, 발표, 대화, 질문에 답하기 그 어떤 방법도 좋다.

나는 큰 부와 큰 성공의 쟁취, 그리고 원하는 것을 하고자 하는 욕망이 있다. 그곳으로 도달하기 위해 여러 험난한 단계(= 목표)를 거쳐야 한다고 생각한다. 재작년 지금쯤, 웹 공부를 시작하면서 세운 목표가 첫 단계였다. 그리고 그 목표를 올해 초에 이루면서 큰 성취를 느꼈다.(관련 링크)

입사한 후에는 투자 공부와 개발 공부를 2 ~ 3년간 지속하며, 두마리 토끼를 잡자고 다짐했다. 하지만 투자 공부가 꽤나 재밌기도 했고, 회사일도 많기도 해서 개발 공부를 소홀히 했던 것 같다. 비록 투자와 개발을 병행하기 어렵다는 점을 느꼈지만, 그래도 소기의 성과는 있다. 그동안 투자에 대한 통찰력을 얻을 수 있었고, 이를 기반으로 한 투자 전략도 세울 수 있었다.

이제는 개발에 집중하려 한다. 그 편이 리턴값이 더 크다고 생각한다. 그리고 팀 내에서, 회사 내에서 제일 잘하는 사람이 되고자 하는 욕망도 생겼다. 그러므로 나의 두 번째 목표는 2024년 12월 31일까지 최고가 되는 것이다. 이에 대한 구체적인 내용은 다음 글에서 작성하겠다.

2023년 초에 원하던 기업에 원하는 백엔드 직무로 입사를 할 수 있었다. 그동안 동기들이나 팀원들과 스터디를 하거나, 프로젝트를 새로 시작하는 등의 경험을 쌓으며 수습기간을 마쳤다.

앞으로는 개발자라 이직이 잦다는 것을 감안하더라도, 최소한 2 ~ 3년 이상은 현재 회사에서 몸 담을 생각이다. 그러면 어떻게 성장해야 할까.

나는 현재 신입이다. 사방에는 모르는 지식들이 너무 많아서 초조함을 느끼곤 한다. 하지만 단기간에 모든 것을 학습하기란 불가능에 가깝기 때문에, 우선순위를 두고 공부해야 한다. 그래서 백엔드 개발자 로드맵과 같은 자료나 유튜브 영상들을 찾아보면서, 다음과 같이 고민을 해 보았다. 물론 학습을 진행하면서 변동이 있을 듯하다.

2023년과 24년은 아래에 집중한다.

• 개발 언어와 프레임워크
  • kotlin, java
  • spring, jpa
  • typescript, vue for admin
• 버전 관리
  • git
  • github
• 네트워크
  • 인터넷, HTTP 등의 기본 지식
  • REST, GraphQL, gRPC 등 api 관련
  • 쿠키/세션, OAuth, JWT 등의 인증 관련
• 운영체제
  • 기본 지식
  • linux, 명령어 등
• 데이터베이스
  • ORM, 트랜잭션 등의 기본 지식
  • MySQL, PostgreSQL, H2 등의 RDB
  • MongoDB, Redis 등의 NoSQL
  • 인덱스, 레플리카, 샤딩, CAP 등의 scaling 지식
• 테스트
  • 통합/단위/기능 테스트
  • JUnit, Kotest, mockk 등
• CI/CD
  • jenkins, sonarQube 등
• 리팩토링
• 캐싱
  • client side
  • server side - redis, memcached 등
  • cdn
• 웹 보안
  • HTTPS, CORS, SSL/TLS, 해싱 알고리즘 등

그 이후는 대략적으로 다음과 같다.

• 개발 방법론
• 아키텍처 패턴
• 메시지 브로커
• 컨테이너화, 가상화 기술
• 웹소켓, SSE
• 웹서버
• ...

참고로 해당 연도에 벗어나있다고 관련 기술을 아예 배제하는 것이 아니다. 가령 도커와 쿠버네티스와 같은 기술들은, 업무 중에서 흔히 접하기 때문에 일정 부분의 지식이 필요하다. 단지 깊이 있게 학습하는 것을 25년 이후로 미뤘을 뿐이다.