첫 회사 프로젝트에서 느낀 점

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

 

느낀 점

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년까지 백엔드 최고가 되겠다는 목표를 가지고 있었다. 그리고 이번 경험을 통해 목표를 더욱 구체화할 수 있었다.

 

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