[퇴사 회고]

인터넷 서핑을 하며 대기업인 넷플릭스 에서는 퇴사자에게 부검메일을 작성하여 퇴사 원인과 개선점을 남기는 문화가 있다는 기사를 보게 되어 이를 기반하여 내가 원하는 항목을 몇가지 더 추하가여 퇴사 회고를 작성해보고자 한다.
안타깝게도 이 회고는 나 또는 공유를 원하는 이들만 보게되겠지만 나를 돌아보는 시간이 되는 좋은 기회일거같아 작성해보고자 한다.

1. 입사

2020년 10월에 입사한 회사는 지인의 추천으로 괜찮은 프로젝트가 있으니 같이 해보자는 제안으로 시작되었다.
추천인은 나를 다무너져가는 프로젝트를 살려내는 일잘하고 책임감있고 실력있는 사람으로 추천하였고 바로 면접을 보게된다
실제로 이전에 다니던 회사에서 담당자 2명이 퇴사하고 5개월 이나 지연된 프로젝트에 신입으로 2주동안 인수인계받고 혼자 투입되어 매일같이 야근하고 회의 참석하며 개발도 해가면서 2021년 12월 에 종료가 되었어야하는 프로젝트가 2022년 5월 중순이 되어서야 마무리할 수 있었다.
면접에서는 대표님과 부대표님 두분이서 참석 하셨고 간단한 기술질문과 가장 기억에 남는 프로젝트에 대해 얘기 해주실 수 있냐는 질문에 "제가 낸 실적에 대해 말씀드리려면 면접을 밤 새도록 해야할거같은데 괜찮으시겠어요?" 라는 대답에 웃으시며 분이기 좋게 면접이 종료되었고 당일 면접 합격 통보와 함께 입사하게 되었다.

2. 회사에서 배운 것

1. 서비스 추상화의 중요성과 트랜잭션 그리고 여러개 인스턴스가 존재할경우 항상 동시성 이슈를 습관같이 고려하자

카라이프 중계플랫폼 애플리케이션은 현재 3개의 채널 마이현대(MYHD) 마이제네시스(MYGN) 블루링크 디지털키 서비스를 지원하는 (MYDKC) 서비스 요청부 가 존재하며 Vendor라고 불리는 서비스 처리부 오토앤, 로드윈 인스타워시 캐럿보험이 존재하여 채널과 밴더사의 직접적인 API 호출없이 중계 플랫폼을 통해 서로 상호작용하는 API 이다.

• 서비스 추상화의 중요성
  위와같은 구조로 인해 벤더사에 대해 요구사항 변화를 중계플랫폼에서는 유연하게 대채 해야했으며 특정 벤더사의 변경 요청이 다른 벤더사와 서비스에 영향을 주지 않도록 하는것이 매우 중요했다. 지금 까지 봐왔던 코드들은 if 문을 떡칠하여 놓았겠지만 운이 좋게도 코드를 작성해놓은 선임자 (카라이프 중계플랫폼 구축 프로젝트 참여 개발자. 우리는 흔히 God 종식이님이라고 불렀다.) 는 추상 팩토리 패턴을 적극 활용하였다.
  추상 팩토리 패턴을 활용했을 경우의 장점으로는 밴더사의 추가 서비스 요청 이 들어왔을때 간단한 방법으로 요구 사항을 들어줄 수 있는 장점이 생긴다. 예를들어 방문세차 서비스를 instawash 측에서 진행하고 있었는데 AutoN 에서도 방문세차 서비스 런칭 요청이들어와 이에 대한 개발건을 핸들링하였다. 위 요구조건이 들어왔을때 팩토리 패턴에 방문세차 기능을 담당하는 클래스 하나만 추가하는것으로 서비스를 런칭할 수있었으며 각자 서비스 핸들러에서 API 수정요청에 벤더사별로 유연하게 대처가 가능했다.

• 트랜잭션
  플랫폼 내부에서 기능개발 여건이 들어왔을때 굉장히 많은 시간에 브레이킹이 걸리고 실제로 결제 장애 상황까지 발생기켰던 부분은 OSIV 옵션과 @Transactional 이었다.
  서비스 시작부 부터 선언되어있는 무지성 트랜잭셔널과 실제 Entity 단에 달려있는 Lombok 라이브러의 @Setter
  의 합작으로 결제 완료가 되었으면 해당 주문정보에 결제 완료 상태로 변경되었어야 하는데 그렇지 않고 리턴되는 경우가 많았다. 메서드 종료시 즉각적인 DB 커밋을 일으키고자 의도한 Transaction 속성중 propagation = REQUIRES_NEW 와 같은 속성으로 부모 트랜잭션에 하위 REQUIRES_NEW 옵션에서 속성을 변경한후 커밋은 일어났지만 상위 부모 트랜잭션에서 그 객체를 보유한후 속성을 변환하는, 상태값 변경 혼돈의 카오스 였다.
  이에 카라이프 플랫폼 운영개발팀에서는 원자성을 유지하는 범위 내에서 트랜젝션영역을 최소화 하였고 REQUIRES_NEW 를 통해 자식 트랜잭션이 부모 트랜잭션보다 선행되어 커밋되는 옵션 사용을 지양하게 되었으며 엔티티에 직접적인 데이터 변환이 이뤄지지 않는 로직이라면 Projection 을 이용 JPA 영속성 컨텍스트에 불필요한 캐시가 남지 않도록 하는 컨벤션을 만들게 되는 계기가 되었다.

• 동시성이슈
  우리는 슬랙으로 주로 트러블 슈팅이 이뤄졌다. 어느날 현대자동차 책임님이 어떤 고객이 다중결제가 이뤄졌다는 이슈가 발생했다. 우리가 사용하는 테스트 환경은 Dev, Stg 서버로 나뉘어져 있었다. Dev 와 Stg 이 두 서버와 상용서버의 가장 큰 차이점은 상용은 다중인스턴스가 올라가있었고 Dev 와 Stg 서버는 단일 인스턴스로 존재하고 있었다. 동시성 이슈를 막기위해 Dev 와 Stg 결제 메서드에 syncronized 키워드를 달아 한번에 한 스레드에대한 연산만 진행하도록 하여 Dev 와 Stg 서버의 이슈는 해결할 수 있었으나 인스턴스가 여러개라면 이또한 아무짝에 쓸모없는 조치에 불과했다. 하여 다중인스턴스 상황에서의 동시성 이슈를 핸들링 해야 했다.
  후보가 여러가지 있었지만 팀에서 채택될 수 있었던 건은 Pessimistic Lock 이였다.
  위 기술이 채택된 이유는 OptimisticLock 인경우 데이터베이스에 컬럼추가가 불가피 했으며 (낙관적Lock -탈락) 이는 또다른 수정사항을 야기시킬 소지가 있다고 판단 Redisson Lock pub/sub 구조로 DB 에 주는 부하가 가장 적은 방법을 선택할 수 있었지만 Redis 구축이 가능한 서버가 현재까지 할당받기 너무 어려웠기때문에(redisson-lock 탈락) 불필요한 컬럼추가 없이 특정 컬럼에 x-Lock 을 걸 수 있는 비관적 락 방식을 채택하여 위 장애를 해결할 수 있었다.
  그외 1급 객체와 생성자를 이용한 도메인 패턴 적용, Setter 사용 지양과같은 팀원들과 끊임없이 상의 하여 어떻게 하면 더욱 향상된 어플리케이션이 될까에 대한 고민을 끊임없이 하며 무한한 재미를 느꼈고 만족감도 높았던 프로젝트 였다.

---

2. 작은 감동만으로도 충분하다.

2번째로 개발적으로 배운것도 있지만 소셜한 부분도 배운점으로 빼놓을 수 없을듯 하다. 2022년 6월에 잠시 KT 인프라 어뎁터 라 불리는 프로젝트 구축사업중 CMS 개발 리더를 긴급히 맡은적이 있었다. 회사의 대표와 부대표가 모두 참여, 긴급함이 매우 높은 프로젝트였다. 프로젝트 기간이 촉박 하였고 투입인력이 부족하여 CMS 개발 리더라고 해봐야 팀원 총 1명이었다. 2022년 6월부터 9월 종료 였던 프로젝트가 결론적으로 최종 11월에 종료 보고를 할 수 있었고 총 5개월 동안 매일같이 야근했고 주말까지 반납하며 일을하였다. 물론 나의 심신도 지쳐있었지만 어리고 생기가득한 나의 팀원은 훨씬 견디기 힘든 업무강도 였을것이다. 힘들다 못하겠다 라는 말을 매일 했지만 조금만 더 힘내보자 잘해주고 있다 라는 말밖에 해줄 수 없었다. 팀원에게 할당된 업무를 가져와 더 많이 뛰고 일할 수 있는정도.
최종 11월 프로젝트 종료보고날 고객사에서 올해 받은 종료보고중 가장 완성도가 있었고 프로젝트 잘 마무리 해줘서 고맙다 라는 칭찬을 들었지만 정작 자사에서는 진심어린 격려의 말을 아꼈다.
매일 야근하는 모습에 고생이 많다. 격려차 커피한잔이라도 사주는 사소한 배려가 있었다면 이같은 서운함은 없었으리라는 이쉬움이 남았다. 긴급할 경우 야근은 불가피한 요소라 생각한다 하지만 열심히 일해주는 직원에 대해 격려의 말은 꼭 필요 하다고 생각하며 힘듦을 공감하고 더 나아가 표현까지 해준다면 정말 좋을것같다.

3. 회사에 아쉬운 점

경영진들이 직원들과 소통을 조금더 많이 해줬으면 하는 마음은 있지만 그것 외 아쉬운점은 없다.
아쉽다 라는 느낌은 개인적인것이 많기때문에 이부분은 따로 정리해 두는게 좋을것 같다.

4. 왜 떠나는지

• 노력에 대한 보상의 부재
• 충분한 대화 없이 갑작스런 전사적 연봉 동결공지
• 출근길의 고단함
• 파견지 사무실 환경의 열악함
• 주인의식이 떠난 개발 분위기

5. 앞으로의 계획

1. TDD 에 대한 깊은 공부
   회사를 다니며 비교적 약하다고 생각하는 부분이 테스트 코드 작성과 단위 테스트가 용이하도록 코드를 작성하는것이였다. 현재까지 프로젝트를 진행하며 레거시 코드에 테스트 코드가 존재하는것을 경험하지 못했다.
   하여 코드 변경에 대한 사이드 이펙트를 최소화 하며 나의 코드를 타인이 리펙터링 했을때 또한 의도한대로 수정하여 정상 작동을 검증할 수 있도록 이에대한 공부에 정진하려한다.

2. 클린코드의 습관화
   팀원이 내가 작성한 코드에서 원하는 로직을 빠르게 찾을 수 있으며 단번에 도메인 로직을 이해할 수 있도록 코드를 작성하는것을 습관화와 더 나아가 단위테스트가 용이하도록 코드를 작성하는것 까지 개발자가 가져야할 기본 소양이다 라는 마음가짐으로 공부할계획이다.

3. CS,네트워킹
   작성한 코드 모두 OS 위에 하드웨어 자원을 이용하는 프로세스가 되며 웹개발에 있어 네트워크를 심도있게 이해하지 않고 있다면 반쪽짜리 전문성을 갖는다 할 수 있을것같다. 하여 더욱 가치있는 개발자가 되기 위해 컴퓨터 지식과 네트워크 학문에 심도있게 공부할것이다.

꼭 위 3가지가 아니더라도 항상 부족한점을 꾸준히 성실하게 채워나가는 노력을 할 예정이다.