들어가기에 앞서

아직 갈 길이 먼 신입 개발자가 지금 회고를 작성하고자 마음먹게 된 이유는

내가 추구하고자 하는 것, 내가 생각하는 좋은 개발자가 되기 위한 방향성이 조금 바뀌었기 때문이다

이 회고는 내가 했던 사이드 프로젝트에 국한된 것이 아닌 어떤 계기로 새로이 방향성을 정하게 되었는지 기록하고

그다음은 무엇인지에 대해 내 생각을 기록하고자 한다.

TILog 사이드 프로젝트

첫 사이드 프로젝트에서 내가 얻고자 한 것

TILog 프로젝트는 무지한 코더 두 명이 시작한 프로젝트였다

나름대로 프로젝트 구현 목표에 달성하기 위해, 좋은 코드에 대해 생각하고 거침없이 행동했다.

프로젝트를 시작하면서 정한 핵심 목표, 행동에 대해 간단하게 정리해 본다면 다음과 같다.

부실한 기초에서 나오는 부실한 코드를 방지하자
- 그동안 했던 연습 프로젝트의 문제점을 파악하기, 그리고 실수를 반복하지 않기
- 성능 테스트하고 개선하기
좋은 코드, 아키텍처는 핵심 가치가 서로 공유될 때 나온다
- 개발 지식 공유가 자유로운 환경을 조성하자
- NestJS 도입하자
- 깃 플로우, 협업툴을 적극 사용하자
- SonarQube로 코드를 점검하는 시간 가지기
배포의 두려움에서 벗어나자
- 지속적 배포로 서비스 배포하기

위 내용은 2021 회고에서도 자세히 기술했으니 참고 바란다

내가 처음 이 프로젝트를 통해 얻고자 한 것은 팀과 함께 소통하는 능력, 구현 능력의 함양이였고

그 목표를 달성하기 위해서 팀원과 지식을 나누고 소통하는 데 초점을 맞췄다

하지만 이 모든 노력이 어떤 프로젝트 목표를 구현하는 것에 치중되어 있다는 것을 여러분도 느낄 것이다

실제로 이때까지만 해도 문제를 해결하는 뛰어난 코드, 도구가 존재할 것이라고 믿었다

하지만 이 대단한 착각은 입사 직후에 바로 깨지게 된다.

그런 개발자로 괜찮은가?

코더에서 소프트웨어 엔지니어로

TILog 사이드 프로젝트를 마치고 곧바로 나는 신입 백엔드 개발자로 입사하게 되었다

입사 전 나는 실제 프로덕션 코드에 대해서 조금 기대하고 있었다

어떤 놀라운 코드( 원피스 ) 가 있을 것만 같았고 내가 걸어왔던 길의 방향성과 노력의 결과물이

틀리지 않았다고 보장받을 수 있기를 원했다

주니어 개발자 프로덕트 팀원으로써 참여하며

사소한 곳에서 발휘하는 정직은 사소하지 않다

당연하게도 내가 상상했던 놀라운 코드 ( 원피스 )는 없었다

하지만 누가 봐도 깔끔하다고 생각할 수 있을 정도의 코드가 있었다

이후 팀과 소통하고 코드를 한 줄 한 줄 짚어 가면서 코드를 작성해 나간 생각과 방식을 배울 수 있었다

클린코드 책에 보면 벨 연구소 이야기가 나온다.

이 이야기를 읽어보면 내 상황과 일맥상통한 이야기가 나오는데 간단히 글을 옮겨 보자면 이렇다

벨 연구소에서 일하던 시절 간단한 조사로,
일관적인 들여쓰기가 버그 수를 줄여주는 가장 중요한 요인 중 하나라는 결과가 나왔다
흔히 우리는 아키텍처, 프로그래밍 언어, 좀 더 고차원적인 뭔가가 이 품질을 결정하는 요인이기를 바란다

소위 전문가는 고상한 설계 방법론과 도구에 통달해야 한다고 생각하는 까닭에 간단한 들여쓰기 스타일로
가치를 더한다는 사실에 모욕감을 느낀다.

품질은 하늘에서 뚝 떨어진 위대한 방법론이 아니라 사심 없이 기울이는 무수한 관심에서 얻어진다.

고차원적인 무언가가 좋은 코드를 만들고 코드의 품질을 결정하는 요인이라 생각했었던 나에게 정말 많은 것을 코드로 가르침을 받을 수 있었고 이 경험은 그 어디에서 할 수 없을 것이다

“코더” 에서 탈출하기 위해서는 어떻게 해야 할까?

전문적인 엔지니어란 무엇이며 어떤 마음가짐으로 개발해야하는가

좋은 개발자가 되겠다는 절대적인 목표 바뀌지 않는다

리드 개발자님께서 말씀하신 것 중에 이 상황에서 가장 기억에 남는 말씀이 있다.

엉망진창으로 코드를 짜도 돌아는 갑니다, 성능 차이도 크지 않습니다
그렇기에 여러분은 코더가 아닌 한 명의 전문적인 엔지니어로서 코드 작성에 임해야 합니다

그럼 전문적인 엔지니어란 무엇일까? 이 질문은 사람마다 너무 다르고 두고 있는 가치에 따라

얼마든지 달라질 수 있다고 생각한다. 단순히 뛰어난 기술로 비즈니스적 문제를 푸는사람일수도 있다

지금 나보다 앞선 길을 걷고 있는 개발자분들이 남긴 글과 영상을 통해서

전문적인 엔지니어가 가져야 할 마음가짐에 대해 조금이나마 짐작해보자

소프트웨어 아키텍처의 중요성 - 마틴 파울러

좋은 아키텍처를 가져가려는 노력을 지속하면 아키텍처 디자인을 고민하지 않은 프로젝트보다 개발 속도가 가속화된다
- → 소스 코드의 플랫폼화
아키텍처( 뭔가 대단히 중요한 것 )는 팀과 핵심 가치(Insight)를 공유하고 그 핵심 가치를 코드에 녹여내는 것이다
중요한 결정은 대부분 앞에서 이루어지며 이후에 바꾸기 매우 힘들다

클린코드

나쁜 코드는 나쁜 코드를 만들고 결국 생산성은 0에 수렴한다
코드를 쓰는 시간보다 코드를 읽는 시간이 훨씬 많다
나중에 코드를 정리하겠다 다짐하지만, 나중은 절대 오지 않는다

버스지수

팀 구성원 일부가 사고로 자리를 비우게 될 때 추진하는 프로젝트가 어느 정도 위험에 빠질 것인가를 측정한 수치다

수치를 높이기 위해서는 다음과 같은 행동이 수반되어야 한다

읽기 쉬운 코드
잘 짜인 아키텍처 디자인
팀원간 코드 시야(Insight) 공유

TL;DR

3가지 이야기는 각기 다른 방식과 주제로 이야기하지만 의미하는 바는 다음과 같다.

프로젝트를 빨리 완성하는 왕도는 없으니 세세한 것에 신경 쓰고 팀원 간에 핵심가치(Insight)를 공유하면서

누가 봐도 좋은 아키텍처, 코드 컨벤션을 가진 읽기 쉬운 코드를 만들라는 것이다

다음 우리가 녹여내야할 가치

내가 부족 했던것에 대해서

고찰의 시간을 가지면서 내가 했던 사이드 프로젝트까지 새로운 시각으로 돌아봤다

프론트 엔드의 경우엔 기능적인 부분, 중복이 많아 제외하겠다

프로젝트 개발 방식

구현, 개선을 동시에 검토하며 진행해서 구현 속도가 매우 느렸다
프로젝트 파일 구조가 제대로 정해지지 않았다
- 미들웨어, 익셉션 필터, 도메인 서비스 폴더가 서로 엉켜있다
개발, 배포, 실행 스크립트가 명확하게 구분되어 있지 않았다
환경변수에 대해 검증을 하지 않았다
DTO가 제대로 작성되어 있지 않고 생략되어 프론트에서 사용하기 힘들다
- OpenAPI를 적용할 수 없었다
- Swagger 에서 응답 데이터에 대해 명확하게 알 수 없었다
Class-validator 에러를 제대로 처리하지 않았다
로우 쿼리로 작성된 테이블을 사용해서 변경 사항을 추적하기 힘들었다

코드

코드 리뷰를 진행하지 않았다
- 하다가 안 하게 됐다
주석, 커밋, 코드 컨벤션이 서로 일치하지 않았다
불필요한 코드 라인이 많다
- console.log, 엔터 등..
명령형으로 모든 코드가 작성되어 있어서 코드를 읽기 힘들다
뮤터블한 변수를 많이 사용한다

TypeScript

엄격 모드를 사용하지 않고 있다
ESLint룰을 일부 비활성화했다
- 빨간 줄이 너무 뜬다는 게 이유
Try-Catch를 남발했다

Package

팀 간에 패키지 매니저가 통일되지 않았다
애플리케이션이 실행되는 노드 버전이 정해져 있지 않아 개발 환경이 달랐다
패키지관리? 그게뭐지

팀에서 배운 새로운 사고방식, 시야로 바라본 내 사이드 프로젝트의 문제점이다

사이드 프로젝트는 코더로써 구현 목표엔 성공적으로 도달했을지라도

내가 추구해야 할 전문적인 엔지니어로서 실패했다고 명확히 말할 수 있으리라

잘 모른다는 이유만으로 사소한 문제를 방치했고 결과적으로 프로젝트 전체의 분위기가 틀어졌으리라

처음 코드 리뷰를 진행하다가도 “급하니까~” 라는 이유로

좋은 코드를 작성할, 코드의 품질을 지켜야 할 내 의무를 저버린것이 아닐까 반성했다

그다음

연습해 연습!

실패를 인정했으니 개선할 차례다! 현재 두 가지에 대해서 집중하고 있다

책 스터디

세세함에 집중하고, 소통하는 개발자가 되기 위해서 기초지식이 매우 중요하다는 것을 회의 때마다 통감했다

그리고 좋은 프로그래머의 생각 방식, 발자취를 따라가는 게 얼마나 중요한지도 깨닫게 되었다

아래 책을 공부하면서 내 잘못된 시야에 대해서 많은 가르침을 받고 있다

클린코드
- 좋은 코드, 엔지니어는 기술이 아니라 세세함에 나온다고 알려준다
- 좋은 코드로 가는 길에 지름길은 없다고 알려준다
- 좋은 개발자가 되기위해 고민했던 선배 개발자의 발자취를 따라갈 수 있도록 해 준다
객체지향의 사실과 오해
- 객체지향이 클래스와 상속인 줄만 알았던 나에게, 객체의 협력 역할 책임 메시지의 관점에서 볼 수 있도록 도움을 주는 책

## 마치며

내가 잘못하고 있었다는것, 좋은 개발자, 코드로써 실패 했다는것을 알았다

하지만 회사가 그리고 있는 개발 문화의 미래 가치에 공감했다 그렇다면 연습할 차례이다!

위에서 언급했던 문제점을 고치고 내가 고쳐야 한다고 생각한 문제에 거침없이 직면해볼 예정이다

프로젝트 기술부채를 단번에 해결하는 고차원적인 무언가는 없다.
좋은 코드, 좋은 프로덕트를 향한 지름길은 없다.
어떤 어려운 상황에서도 코드 품질을 지키는 것은 우리의 의무다

화이팅 하자!

2022 중간 회고