회고 | (5월~8월) 그 모든 파도는 한 번뿐이고, 결국 모두 지나간다.

💪🏻 내가 한 것과 잘한 것

1. 사내 개발 스터디 시작 

이번 분기 가장 큰 성과는 바로 사내 개발 스터디를 시작했다는 것이다.

다른 스터디도 많은데 사내 스터디에 참여한 이유는 다음과 같다.

 

1. "팀원"들이랑 개발 관련 얘기를 나누면서 좀 더 친해지고 싶었다.

2. 외부 스터디와 다르게 업무 관련된 고민을 가감 없이 나눌 수 있다.

3. 스터디 시간대를 유동적으로 조율할 수 있다. 

 

1-1. 테스트 코드 스터디

벌써 3년 차 개발자인데, 그동안 테스트 코드를 작성해 본 적이 없었다. 

테스트 코드를 짤 수 있지만, 여건상 짤 수 없는 개발자가 아니라 짤 수 조차 없는 개발자라는 사실이 부끄러웠다.

 

다른 팀원 분도 테스트 코드에 관심이 있어 자연스럽게 스터디 첫 번째 주제는 "테스트 코드"로 정해졌다.

 

각 주차별 목표는 달랐지만, 나만의 목표는 다음과 같다.

 

1. 완벽하지 않아도 된다.

2. 일단 짜보기라도 하자.

3. 테스트 코드 인강 들었던 내용을 적용해 보자 

 

 

매주 스터디 시간에 각자 작성한 테스트 코드를 리뷰하며 서로의 코드를 리뷰했다.

 

스터디 시작 전 각자 작성해보는 KPT

 

테스트 코드 스터디를 하며 부가적으로 많은 부분을 공부할 수 있었다.

1. 비즈니스 로직은 DTO가 아닌 Domain 객체에서 처리하자

2. 결과 객체 내부의 필드를 검증할 때 hasFieldOrPropertyWithValue 사용

3. 나.. 생각보다 스프링 부트에 많이 의존했었구나.. 의존성 주입, 의존성 역전등 테스트 코드를 작성해보니 프레임 워크에 대해 다시 한번 공부할 수 있었다. 

 

좋았던 점

- 사내 네트워크 이슈로 개발 환경 접속이 불가능한 상황이 있었는데, Mock 객체 통해 외부 의존성을 제거할 수 있었다. 외부 환경에 구애받지 않고 개발할 수 있어서 공부한 보람이 있었고, 이 순간이 가장 인상 깊었다. 

- 테스트 코드를 짜라면 짤 수는 있는 개발자가 되었다. 레벨 업한 기분이 들어서 뿌듯하다.

 

아쉬운 점

- 사내 스터디 참여하지 못한 날들이 있어서 아쉬웠다. ㅠ 바쁘다는 건 핑계가 맞았다. 잠깐이라도 참여할 걸 아쉽다.

- 테스트 코드를 위한 테스트 코드를 작성했다. 개발과 테스트 코드 작성이 유기적으로 이뤄져야 하는데, 아직 테스트 코드 작성에 익숙하지 않다 보니 개발이 어느 정도 완료 되면 테스트 코드를 작성하게 되는 거 같다. 빨리 개발해야 된다는 생각 때문인지 자꾸 미루게 된다.

 

1-2. 미션 프로젝트 

다음 스터디는 미션 프로젝트를 진행했다. 총 2번의 미션 프로젝트를 진행했다. (자동차 경주, 숫자 야구)

이번 스터디에서는 리뷰어와 리뷰이를 지정하고 PR을 통해 코드 리뷰를 해보았다. 

개인적으로 숫자 야구가 재미있었다. 처음 미션 프로젝트를 한다면 숫자 야구 추천한다.

 

좋았던 점

- 그동안은 프레임워크가 구성된 환경에서 개발을 진행해 왔어서, 계층 격리에 대해 큰 고민이 없었다. 이번 미션을 통해 아키텍처를 직접 설계해 보니 자연스럽게 각 계층 간 역할과 책임에 대해 고민하게 되었다. 

- 도식화하는 과정을 통해 '설명에 가장 좋은 방법은 바로 그림 그리는 것'임을 다시 한 번 느낄 수 있었다. 그림을 명확하게 그릴 수 있다는 것은 설계가 명확하다는 것이고, 어떤 의도를 가지고 설계했는지를 표현할 수 있다는 증거이기도 하다. 

- 인생 첫 PR을 날려보았다. 어떤 고민을 했는지 댓글로 남길 수 있었고, 답글을 달면서도 내가 알고 있는 내용을 다시 한번 검증해서 남겼다. 

 

아쉬운 점

- 리뷰어일 때 팀원들에게 유의미한 답글을 달아주지 못한 거 같아서 아쉽다. 

- 테스트 코드를 작성하지 못해서 아쉽다.

 

2. 테스트 코드 및 리액트 강의 완강

2-1. 테스트 코드 인강

Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 

Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 강의 | 김우근 - 인프런

 

우근님의 테스트 코드 인강을 완강했다. 사내 스터디와 병행하니 더 열심히 듣게 되고, 바로 적용해 볼 수 있었다.

가장 인상 깊었던 부분은 "테스트하기 어렵다면, 테스트 코드가 신호를 보내고 있는 것이다. 설계가 잘못되었다고" 이 부분이다.

 

좋았던 점

- 테스트 코드를 왜 짜야하는지 궁금한 개발자라면 해당 강의에서 답을 얻을 수 있을 수 있을 것이다!

- 실제로 프로덕션 코드 중 UUID로 key를 만드는 로직이 있었는데, 이 부분이 테스트하기 정말 까다로웠다. 설계가 잘못되었다고 테스트 코드가 신호를 보내고 있던 것이었다. 이 부분을 의존성 역전으로 해결할 수 있었다. UUID 생성 로직을 추상화하여 서비스 로직에서는 해당 인터페이스의 구현체를 호출했고, 테스트 환경에서는 모의 객체를 주입하여 특정 UUID를 반환하도록 설정할 수 있게 되었다. UUID이 아닌 다른 정책으로 변경되더라도 서비스 로직을 수정하는 것이 아닌 UUID 생성 로직만 변경하면 된다.

 

아쉬운 점

- 후시 녹음이다 보니 타이핑이 굉장히 빨랐고, 강의 중간중간 리팩터링을 진행하다 보니 타이핑하랴, 개념 이해하랴 정신이 없었다. 빠른 배속으로 전체적인 흐름을 확인한 다음 타이핑하는 걸 추천한다.

 

2-2. 클린 코드 리액트 인강

[최신 2024 버전] 클린코드 리액트(React)

 

리액트와 조금 더 친해지기 위해 들었던 클린코드 리액트 강의를 완강했다. 핵심만 쏙쏙 짚어주기 때문에 만족스러운 강의였다.

useReducer()를 사용해서 상태를 구조적으로 관리하는 방법을 배울 수 있었는데, 이 부분을 업무에 적용하여 A 상태인 경우 a 버튼 활성화 b 버튼 비활성화, B 상태인 경우 a, b 버튼 모두 활성화등과 같이 상태 관리를 명확하게 처리할 수 있었다. 

 

좋았던 점

- 한 강의당 10분 내외이기 때문에 출퇴근길에 가볍게 듣기 좋다.

- 강의가 독립적으로 구성되어 있어서, 관심 있는 챕터만 볼 수 있다.

 

아쉬운 점

- 강의 들었던 시점에는 예제 코드가 올라오지 않아서 아쉬웠다. (다시 확인해보니 예제 코드 업로드 되었다.)

 

3. 메인 대시보드 개발 

처음 메인 대시보드 개발 업무가 주어졌을 때 오만가지 생각이 들었다. 다른 기능도 아니고 메인 대시보드라니.. 

 

랜딩 페이지이다 보니 레이아웃도 신경 써야 하고, 여러 테이블과 조인하다 보니 데이터 정합성도 확인해야 하고, 도메인도 이해해야 하고..,, 

그렇게 7월 중순 ~ 8월 초는 메인 대시보드 개발에 전념했다. 다행히 여러 팀원분들의 도움으로 무사히 메인 대시 보드 개발이 완료되었다.

 

새롭게 배운 것

- WITH AS : 서브쿼리를 만들고 공통 테이블 표현식(Common Table Expression, CTE)을 정의하여 복잡한 쿼리에 가독성을 높일 수 있다. 쉽게 말하면  쿼리에 이름을 붙여서 미리 정의하고 나중에 해당 쿼리를 호출해서 사용할 수 있는 방법이라고 생각하면 된다. 

 

- LAG() : 윈도우 함수 중 하나로, 현재 행 이전의 행의 값을 가져오는 데 사용된다. 

 

4. Naming Convetion 정의

프로젝트 공통에서 사용할 Naming Convention 가이드를 만들었는데, 역시 이름 짓는 일이 가장 어렵다.

각 모듈 간 통신에 사용되는 명명 규칙을 정하는 게 메인이었다. 그래서 사용 가능한 모듈명과 depth 구성을 가이드했고, 예시 코드도 같이 첨부했다. 

가이드는 만들고 끝! 이 아니라 꾸준하게 업데이트하는 것이 더 중요하다고 생각된다...!

 

이 작업을 하면서 느낀 점 : 개발 가이드 만드는 거 정말 어려운 일이구나.. 

 

5. 미라클 모닝 

5월~7월 미라클 모닝 챌린지에 참여했다. 역시 의지는 돈을 주고 사는 것이다.

30,000원 참가비를 건 덕분에(?) 100% 성공했다. 6,000원 정도 상금을 받아서 기분이 좋았다.

 

좋았던 점

- 아침 시간을 여유롭게 활용할 수 있다.

- 갓생뽕(?)에 취할 수 있다.

- 덕분에 출근 전 운동 + 공부를 할 수 있었다.  

 

아쉬운 점

- 너-무 피곤한 날은 인증샷을 찍고 다시 잤다.

찍고 다시 자는 한이 있더라도 남겼던 인증샷..

💭 고민/생각

 

- 완벽해지는 것에서 벗어나자

- (일기에서 발췌) 7월 초는 스스로에 대한 확신이 부족해서 힘들었다. 작년에 썼던 일기 보면서 위로받았고, 다른 분들에게 물어보면서 멘탈 케어를 해나갔다. 좋은 개발자란 결국 (같이 일하기) 좋은 개발자라는 생각이 들었다. 그러기 위해서는 기술적인 테크닉뿐만 아니라 문제를 해결하기 위해 생각해 보는 능력, 소통하는 능력이 중요하다는 답을 얻었다. 더 큰 사람이 되기 위해 실수하는 경험도 해보고 결단력도 기르는 과정이라고 생각하자

그러나 한 치 앞도 보이지 않는 상황일수록 시선이 중요하다. 밀려가는 것을 응시하는 행동이야말로 우리 사회의 향방을 가늠하는 나침반이 되어주리라 믿는다. 언제나 그랬듯, 세성을 바꾸는 건 기술이 아니라 관점이다
-“액세스가 거부되었습니다.”

당신이 극복할 수 있었던 것을 계속 상기시키세요.
해낼 수 없을 것 같다는 생각이 들었던 매 순간, 당신은 그게 틀렸다는 걸 증명했습니다.
당신은 본인이 생각하는 것보다 더 강합니다.

모든 일은 반드시 수정하게 되어 있다.
결과물이 70점 혹은 80점 짜리라도 상관없으니 일의 전체 그림을 그리는 것부터 시작하라.
스마트폰 애플리케이션이 업데이트를 반복하는 이유를 생각해 보면 된다.
처음부터 완벽한 결과물은 존재하지 않는다.

파도가 칠 땐 파도를 타고, 파도가 없을 땐 물에 빠지지 않도록 노력하여 다음 파도를 기다린다.
어떤 파도는 너무 거세기 때문에 타기가 어려울 테고, 어떤 파도는 나를 위해 만들어진 듯 나를 사뿐히 들어 옮길 것이다.
그 모든 파도는 한 번 뿐이고, 결국 모두 지나간다.
- "퇴근길의 마음"

 

두려움은 가만히 앉아 있을 때 생기며, 행동에 나설 때 사라진다. 

🐣 배운 것과 성장 지점

- 7월에 미리 작업해서 8월을 여유롭게 보낼 수 있었다. 

- 사내 역량 증명 시험 도전했다. 시험 접수 당시 업무 때문에 자존감이 많이 낮아진 상태라 시험에 응시할까 말까 고민했었지만, 떨어질까 봐 겁먹지 말고 일단 해보자! 는 마음으로 응시했다. 비록 한 문제 차이로 떨어졌지만, 도전한 나에게 큰 박수를! 다음에 합격하면 되지

- 통제할 수 없는 상황에 불안해하지 않으려 노력했다. 

👏🏼 아쉬운 것과 다음에 다시 시도해 볼 수 있는 것

- 테스트 코드를 좀 더 능숙하게 사용할 수 있었으면 좋겠다. 

- "안된다. 못한다." 보다 타협점을 제안하자. "~까지 가능하고, 우선순위 조정해 달라"라고 요청하기

- 개발 전 Flow Chart로 로직 도식화하기  

😎  다음 분기에 나에게 올 기회

- 새로운 도메인 개발! 그동안 소나큐브 미들웨어를 메인으로 개발했었는데, 신규 도메인을 개발할 기회가 생겼다. 

- 자바 중급 인강 완강 (* 1분기부터 듣기 시작했는데 미뤄왔었다. 놀랍게도 지난 분기 목표였음..!)

- 솔루션 제품 개발