24년 2월 회고

KPT 회고 방법론을 적용하며 잘한 점은 유지하고 부족한 점은 개선하기 위해 2월을 회고해본다.

Keep

더 나은 코드를 위한 고민

개발할 때 코드 구조(컴포넌트 설계 등)에 대해 고민하며 제일 나은 방안에 대해 코드 리뷰 시간에 논의한다.

사수분은 나의 고민과 방안에 대해 들으시곤 고민 해결 방향성을 봤을 때 바람직한 것 같다는 피드백을 주셨다. 물론 코드를 짜는 방식은 취향 차이가 있을 수 있지만 그렇게 짠 방식에 대한 타당한 이유는 있어야 한다고 생각하기에 고민하며 보낸 시간들이 헛되지 않았다고 느꼈다.

아무리 바쁘지만 내가 짠 코드에 대한 설명은 할 수 있어야 한다고 생각한다. 그래야 결과물에 책임을 질 수 있기 때문이다.

Problem

고민을 너무 많이 하는 것 같다는 피드백

한 문제에 대해 더 나은 코드 구조를 위해 계속 고민하던 모습을 본 사수분은 나에게 고민을 너무 많이 하는 것 같다는 피드백을 주셨다. 고민을 할만한 가치 있는 이슈에는 공을 들여도 되지만 그렇지 않다면 너무 많은 시간을 쏟는 것은 좋지 않다고 하셨다. 좋은 코드도 좋지만 데드라인 내에 개발을 끝내는 것이 최우선이기에 작업 별로 데드라인을 설정해 개발하는 것도 좋은 방법이라고 하셨다. (예를 들면 3시간까지 작업이라고 한다면 1일 내로 끝내는 것을 목표로 하는 식으로 설정한다. 왜냐면 개발만 하는 것이 아니라 다른 이슈 논의 등 다른 일이 중간에 낄 수도 있기 때문이다.)

장애 원인 파악이 오래 걸림

결론적으론 빌드 환경에 다른 원인으로 인해 로컬에서 잘 실행되던 코드가 배포 환경에서는 에러를 반환했다. 그래서 hotfix 배포를 했다.  에러난 부분은 이번 작업에 포함되지 않았었기에 문제에 대해 어떻게 접근할 지 갈피를 제대로 잡지 못했다. 결론적으로 장애 원인 파악이 오래 걸렸다.

 

Try

한 문제에 대해 오래 고민하지 않기

나는 매일 본격적인 업무를 시작하기 전 오늘 할 일들, 언제 어떤 작업을 몇시간정도 할애할지 계획하는 편이다. 그런데 한 문제에 파고들다보면 종종 기준 시간보다 더 넘을 때가 있다. 물론 좋은 작업물을 내는 것도 좋지만 고민이 끝나지 않는다면 한 템포 끊고 가는 것도 하나의 방법일 수 있다. 어찌 됐던 내가 정한 데드라인은 넘기지 않도록 하자.

문제 원인을 빨리 파악하는 방법

문제 발생시 아래의 프로세스를 따르자. 이번 hotfix 배포 과정을 예로 들면 다음과 같다.

• 정상적으로 동작하는 상황과 문제가 되는 상황의 차이를 알아낸다. (원인 파악)
  • 가능성 1. - 배포 중 개발자가 실수로 잘못짠 코드가 들어갔다. (코드 히스토리를 파악해 언제 버그가 발생했는지 찾는다.)
  • 가능성 2. - 배포할 때 코드가 변경되니까 이 과정에서 코드가 평소와는 다르게 변환된 것 아닐까? 이번에 CI/CD를 도입하면서 github actions 환경에서 다르게 빌드된 것 같다.
• 원인을 파악했다면 그 원인이 정확한지 검증한다.
  • 코드는 동일한데 이전 버전의 빌드 결과물과 현재 버전의 빌드 결과물이 다른지 확인하기 위해 json-diff를 이용해 package-lock.json을 비교한다.
  • 현재 프로젝트에는 package.json, yarn.locak을 이용해 라이브러리를 설치한다. 로컬 빌드시 yarn 패키지 매니저를 사용했고 CI 환경에서는 npm을 사용했기에 패키지 버전이 달라졌다. (npm 모듈의 semantic versioning(semver) 기반 범위 지정 방식으로 인해 버전 정보 앞에 기호를 부여하게 되면 업데이트 범위가 고정되지 않음 (예를 들어 A 패키지에 대해 ^1.2.3 이라고 package.json에 설정해 둔다면, 내 로컬에는 실제로 1.2.4가 설치될 수도 있고 1.3이 설치될 수도 있음))