2024 후반기 회고록 (2년차)
Last updated
Last updated
2024년 하반기 회고는 이 영상으로부터 시작한다.
영상속에서 아이언맨은 터진 이슈들에 대한 대응책을 마련해나가면서, 위기의 상황을 모면하는 장면들을 보여준다.
' 내가 우러러 보는 사람들도 사실 장기간 동안 의식적으로 개선해 나간것이 아닐까?' 라고 생각했다.
이번 년도는 나의 부족함을 많이 깨닫게 해주는 일년이였다.
이번년도에는 단기간에 회사, 회사외의 일들로 빡세게 일을 해봤다. (3개월정도 주말근무를 했다.)
나의 부족함이 여실히 드러나면서, 불안함과 불면증이 생겼었다.
커뮤니케이션 능력 부족
도메인 지식 부족
일정 관리 능력 부족
기술적 능력 부족
나의 부족함 속에 불안함들을 개선해나가면서 일이 되게 만드는 팀원이 되고 싶다.
'다른 사람들과 일하면서, 나의 부족함들을 찾아내고 끝없이 개선하는 씩씩함을 가지고 헤쳐나가자'를 마음 깊숙히 새긴 2024년 하반기였다.
신규 권한 데이터 구조를 모델링 한 이후, 신규 권한 데이터 구조로 마이그레이션을 하는 업무를 진행했다.
마이그레이션에서의 이슈는 기존 데이터의 정합성이 틀어져있었고, 신규 데이터 구조로 '1:N으로 맵핑'되어야하는 상황에서 마이그레이션 로직을 생성해야됐다.
진행할 당시에, 수동적인 업무 태도로 '일률적인 규칙으로마이그레이션 이후 검증 로직을 생성했다.'
(사실, 커뮤니케이션이 필요한 부분인지도 인지가 늦었었다.)
하지만, 마이그레이션 데이터에서 정합성이슈들이 많이 발생하면서, 등에 땀이 났다.
왜 기존 권한이 동작하지 않나요? (권한 검증에 대한, 트러블 슈팅 및 문의 응답시간 증가)
기존 권한이 정확하게 마이그레이션이 되었나요? (권한 마이그레이션에 대한 정합성 이슈)
이 일을 수습하기 위해, 부랴부랴 기존 권한에서의 기존데이터에대한 도메인 로직을 문서로 정리해서 마이그레이션 로직에 대해서논의를 진행하여 업무를 완료할 수 있었다.
개인적으로 이 업무를 진행하면서, 어떻게 정합성이 맞지 않는 기존 데이터를 정리하고, '기획, PM, 개발 간의 논의내용을 정리하는 능력'이 필요한지를 배울 수 있었다. 배치를 사용한 도메인 검증 로직을 작성하는 것도 배울 수 있었다.
이것과 더불어, 연동 인증,인가 로직부터 프로젝트 내에 레거시 인가로직에 대해서 리팩토링을 진행했다.
몇년 이상된 코드베이스에 대해서, 히스토리를 찾아보고, 걷어낼 수 있었다.
기존에 분석하기 힘들고, 테스트하기 힘든 SP 때문에 변경하기 힘든 코드들을 제거할 수 있어 기뻤다.
또, Filter 로직들도 겹겹이 쌓여있었는데 분리해 낼 수 있었다.
SP에서 애플리케이션으로 마이그레이션 하면서, 모니터링에 대한 도입이 필요한데 이 부분도 논의 중에 있다.
레거시 유저기능을 개편을 맡게 됐다.
DDD 수업에서 언급하는 용어사전과, 요구사항들에 대해서 정리를 먼저 진행하였다. 컨텍스트 맵까지 작성하여, 같이 진행하게된 동료분과 공유 드렸으며, 이 문서들을 기반으로 테이블을 생성하고, JPA Entity를 모델링 했다.
실제로 업무에서 강의 내용들을 적용해보면서, 구현해야할 기능들에 대해 확신을 가질 수 있었다. 이후에 기획의 요청에 따라 수정한 건들도 있었는데, 변경하기 쉬운 코드들의 구조를 가지고 빠르고 안정적이게 변경할 수 있었다.
기존의 프로시져 로직들을 걷어내면서, 테스트 로직을 구현하기에 쉬운 구조로 유저 모듈에 대해서는 유지보수 리소스를 최소한으로 줄인 상태라고 생각한다.
앞으로 추가되어야할 개선점은 테스트 커버리지를 높이고, event를 도입하여, 성능을 개선해볼 수 있을것같다.
신규 인원이 들어왔을때, 부끄럽지 않을 정도의 수준이라서 완료하고 뿌듯한 표정으로 유저 모듈을 바라볼 수 있었다. (기술적으로 배운점들: DB 커넥션 풀 설정, 서비스간 요청 실패시 대응법)
형상이 변경되고 복잡한 테스트 환경 배포 파이프라인이 깨지는 경우가 많이 생긴다.
아마 오랜 시간전에 테스트 환경 배포가 깨지고 누군가 팀을 떠나게되서 테스트 환경 배포 파이프라인이 없다. 그래서, 수동으로 배포해주는 과정이 10분 정도 소요가 된다.
이 짜잘한 업무들이 나의 리소스를 가져가는게 신경이 쓰이기 시작했다. 간단한 배포 파이프라인이겠지 하면서 파이프라인을 시작했고, 생각보다 설정파일들과 초기화 해줘야하는 값들이 많아서 애를 먹었다.
Jenkins를 설정하고, 배포 파이프라인 까지 설정해서 리소스가 누수되지 않게 배포 업무를 제거할 수 있었다. 이런 작은 경험을 쌓아 Jenkins를 활용한 정합성 모니터링이나, 에러 리포팅같은 간단한 업무들도 제거할 예정이다.
한 여름밤, Jason 님께서 유스방에서 발표자 모집 공고가 올리셨다.
'내 생각을 다른 사람들에게 빠르게 전달하는 능력'과 '고민 지점들을 공유하는 방법들'에 대해서 고민하고 있었다.
첫 OT를 시작으로, 첫 리허설까지 빠르게 진행됐고 초기 발표 제목은 'Linux Kernel Parameter로 TCP 설정 알아보기' 였었다. 네트워크 이슈로 최근에 트러블 슈팅을 실패한 경험이 있어, 어려운 네트워크를 주제로 공유하려고 했다.
8월 15일에 AWS의 송증훈 멘토님께서 '너무 많은 내용을 전달하려고 하고있다'는 문제점을 지적해주셔서 발표의 내용을 몇개의 개념으로 줄여서 '백엔드 개발자가 알아야하는 네트워크 최적화 꿀팁'으로 변경했다.
증훈님께서 내용에 대해서 틀린 부분들을 지적해주시고, 어떻게 설명해야 청중들이 이해를 할지도 검수해주셨다. 증훈님이 장표를 가지고 예시로발표하실 때, 마인드 맵처럼 잘 나눠서 설명해주시는데 세부 개념들을 암기하시고 남은 인지자원으로 개념간 상호 관계성까지 설명하셨다.
하헌님과 김범님도 피드백 세션에 참가해주셔서, 전달력이 필요한 사항들을 장표에 나타내고 최대한 쉽게 전달해야한다고 피드백을 주셨었다.
실제 무대에서 발표를 하게되니, 내용에 대해서 하나도 기억이 나지 않았고 긴장감에 발표 내용을 제대로 전달하지 못했다.
Jason 님께서 전달해주신 Youtube 영상에서 '발표를 하는 법' 같은 꿀팁들을 보면서 연습하였는데 최종 리허설날 심각하게 절어버렸다.
마지막 발표까지 얼마 안남은 시점에서, 슬라이드를 다시 만들었다. 내가 슬라이드를 잘 설명할 수 있게 구성을 했다. 발표 전날에도 장표가 시각적으로 중구난방이라서, 한번 더 수정을 진행했다.
발표 당일이 찾아오고, 스터디 카페를 빌려서 5번 정도 연습을 하고 발표를 진행했다.
개발자들이 추상화 되어있어 잘 모르는 TCP 연결에 대한 세부사항들을 잘 설명할 수 있었다.
MTU 설정 최적화
Congestion Window 최적화
애플리케이션개발자가 하기 좋은 꿀팁들
압축을 통한 통신량 줄이기
CDN 활용하기
커널 버전 최신화하기
여러개의 리소스를 하나의 리소스로 통신하기(이미지 스트라이핑)
발표를 진행하면서, '만들면서 배우는 Spring 4기' 도 수강 중이었고, 회사일도 바빴다. 수면시간이 극단적으로 줄어들면서, 매 순간 집중하려고 노력하는 것을 느꼈었다.
하지만, 기술적 내용을 발표해보는 경험은 모두에게 추천해볼 만한 경험이었다.
발표자의 입장에서 세가지 좋은 점들이 있었다.
다른 사람들이 어떻게 정보를 받아들이는지 고민하면서 미래의 발표를 쉽게 구성할 수 있다.
나의 지식을 공유하면서, 객관적으로 내가 이해하고 있는 사항인지 검증 할 수 있다.
더 나아가, 개발자분들과 이 경험을 공유하며, 같은 고민들을 서로 질문하며 개선해 나갈 수 있다.
연차가 몇년이든 이 경험을 통해서 얻어 가실 부분들이 많다고 생각한다. 미래에 공지가 나오면 꼭 해보는 것을 추천한다.
끝까지 발표를 도와주셨던 송증훈 멘토님께 감사드리고, 스태프분들과 Jason 님께 감사한 마음을 전합니다.
JWP 수업을 결국에 듣게 되었다! 이전부터 고대해오던 수업이라서, 바로 듣게 되었다.
스프링 개발을 하면서, 기본적인 원리를 알면서 개발을 하는것과 아닌 것의 차이가 디버깅할 때 크게 나타났다. 개발자로서의 제일 중요한 역량이 나는 '추상화 되어있는 것의 너머를 보는 능력'이라고 생각한다.
만들면서 배우는 Spring 4기에 대한 자세한 내용은 노션에 작성되어있다. https://celestial-fountain-2b6.notion.site/Spring-4-19d3b5568b2a806c8af4c9b0dbe151e3?pvs=4
Tomcat을 구현하면서, I/O를 핸들링 하는법, HTTP에 대한 구현을 배웠다.
MVC를 구현하면서, Servlet Request와 Spring MVC의 대한 관계를 배웠다.
DI 컨테이너를 구현하면서, SPRING에서 주입은 어떤 방식으로 진행되는지 배웠다.
JDBC 라이브러리를 구현하면서, JDBC의 라이브러리 구현을 배웠고 트랜잭션은 어떤 원리로 구현되는지 배웠다.
AOP에 대한 구현을 진행하면서, 실무에서 로깅을 위해 사용할 수 있는 개념을 배울수 있었다.
전반적으로 오류코드를 볼때나, 라이브러리 코드를 뜯어볼때, 어디서 문제인지 어느정도 가늠이 가능한 상태가 된 것 같고, 빈 주입 같은 경우도 더 쉽게 활용하고 있다.
Spring의 순환 의존성을 감지하는 방법(BeanCurrentlyInCreationException)도 나중에 기술 블로그로 작성해보려고한다! 스프링 코드를 읽어보신 분은 아시겠지만, 이 예외를 잡는 코드에 대한 의도성을 알아채기 버겁다.
힘든 9주간의 스터디가 끝났다. (일정이 너무 빠듯해서 전날밤 계속 새가면서 과제를 했다.)
스터디 내부 자료가 너무 잘돼있어서, 끝까지 할 수 밖에 없었다.
선배님들의 k8s를 사용하시면서, 생기는 이슈들과 경험담들을 들을 수 있었다.
클러스터를 운영하면서 생기는 트러블 슈팅은 누가 담당하고, 물리 장비는 누가 담당하는지?
CoreDNS 에 대한 dns fail 이슈
Istio 운영 문제 (cpu 과점유)
pause container가 어떻게 실행되는지?
네트워크의 흐름은 docker 안에서도 복잡하고, pod간도 복잡하고 node 간도 복잡했다.
거기다 CNI들도 복잡성을 추가하게 된다.
이런 복잡성을 극복하고, '장애없는 서비스를 제공할 수 있는지'는 네트워크 지식에 달렸다고 생각한다.
이번 9주간의 네트워크 특훈으로, 미래의 내가 이슈들을 멋있게 처리했으면 한다.
가시다 서님과 @CloudNet 님께 감사의 마음을 표한다!
회사에서 종종 상태 처리 이슈가 나오기 때문에, 서비스 두개간 연동시에 생기는 문제에 대해 알고 싶었다.
이미 누군가는 해결한 사례가 있을것이라고 생각하며, 찾아보니 MSA를 구축하면서 생기는 이슈라고한다.
첫번째 책은 이론적인 MSA 구성으로, 빌드환경, MSA의 당위성, 통신 방식, 보상트랜잭션, 변경의 범위 조절하기, 배포, 테스트, 모니터링 까지 광범위한 내용을 설명해주려고 했다.
이 책을 읽을 당시, MSA 와 Modulith에 대해서 박용권님의 모듈형 모놀리스는 무엇인가? 라는 세미나에 참석할 수 있었다. DDD가 끝나고 나서, Jason님께서 호스트해주신 세미나 였다.
복잡한 시스템을 제어하고 지속가능한 변경을 위해 우리는 아키텍처를 사용하고, MSA는 유연성과 확장성을 제공하지만, 분산시스템의 복잡성을 극복해야한다.
대부분 이 단계에서, MSA를 먼저 도입하고, 깨닫게 되는 경우가 많은데, 분산시스템의 운영 복잡성을 제어하기 힘든 경우가 대부분이라고 생각한다.
당근에서도 MSA에서 모놀리스로 이전하였고, 여러번 바운디드 컨텍스트를 변경하기도 하셨다고 했다.
쇼피파이나 스택오버플로우, 스레드도 모두 모놀리스 방식으로 만들었고 대규모 트래픽을 처리하고 있는 예시도 들어주셨다.
그 이후에, 실제로 MSA를 구축해보고 싶었고, MSA 스터디에 들어갈 수 있었다.
'마이크로 서비스 공작소'라는 책에서, 실제로, Docker Compose를 띄우고, MSA를 설정해볼 수 있었다. 다만, 책에서 제공하는 코드가 오래되서, 내가 실제로 프로젝트를 구축해서 시간이 오래걸렸다.
이번 하반기에는 운이 좋게도, 우테코와 당근 테크 컨퍼런스, Kafka KRUG 밋업에 참가할 수 있었다.
각 회사들의 부서들 마다 겪고 있는 이슈들과 기술문제들이 달랐고, 해결과정까지의 결정과정들이 재밌었다.
자세한 컨퍼런스 후기는 우테코, 테크 컨퍼런스, KAFKA KRUG 밋업 에서 다룬다.
컨퍼런스에서 만나는 기술 문제들은 회사에서 적용하기 좋은 리소스를 제공하고 판단의 기준을 생성하기 좋은 것같다.
나는 진정한 즐거움은 매일 자신을 향상하고 목표를 달성하는 것에 있다고 믿는다.
하지만, 생활속에서 낭비하는 시간들이 늘어나면, 목표를 달성하기 위한 시간들이 줄어들게된다.
처음에는 수면을 줄여서 시간을 확보했지만, 수면 부족으로 인한 업무 효율 감소로 생활습관들을 단순화하여 시간을 확보했다.
불안감과 불면증으로, 수면시간이 5시간 이하로 유지된 적들이 있었다.
업무에 대한 효율이 줄어들면서, 너무 답답했었고, 생활 습관들에 대한 점검들과 내 머리속에 있는 고민들을 하나씩 정리하기 시작했다.
잠들기전에 대한 루틴을 생성했다.
카페인 섭취를 잠들기 5시간 이전에 섭취하지 않았다.
마그네슘 같은 보조제를 사용했다.
휴대폰을 손에 닿지 않는 곳으로 배치했다.
잠들기 1시간 전에는 책을 보면서 시간을 보냈다.
회사에서 근무하는 시간 제외하고, 업무에 집중 할 수 있는 공간이 필요했다.
카페 영업시간에 맞춰 장소들을 물색하고, 콘센트를 찾아다니며 허비되는 시간들이 너무 아까웠다.
비용은 조금 들지만, 고정적인 장소를 확보함으로써, 업무 장소와 쉬는 장소를 구분할 수 있어 쉴 때의 능률을 확보했다.
스터디 카페도 장기간 다녀보고, 카페에서도 해보고, 집에서도 해봤을 때, 독립된 공간을 가진다는 점에서 사무실이 왜 필요한지 알 수 있었다.
재무
주식 모으기
장기적인 재무 계획을 가진 사람은 주식과 부동산 같은 재무 계획에 관심이 많을 것이다.
재무 계획은 중요한 결정이지만, 목표에 비해 중요하지 않은 결정이라고 생각한다. 나 또한, 주식시장을 모니터링하는데 시간이 많이 들어갔다. 지금의 목표를 희생하여 재무 계획을 실행할 수 없다고 생각한다.
하지만, 'Keep Buying' 이라는 책에 따르면, 적립식 투자로 계속 구매하는 방법을 추천했다.
이에 따라, 나도 적립식 투자를 결정하여 주식 모으기 기능으로 적립하기 시작했다.
이 결정으로, 재무적인 전략들로 소모되는 시간들은 최소화 할 수 있었다.
출퇴근시간
명상하기
나는 버스를 타고 출퇴근을 한다. 출퇴근할 때, 휴대폰의 유혹에서 벗어나기 힘들다.
쇼츠를 보고 출근하게 되면, 시간은 빨리 가지만, '피곤함'의 체감이 조금 강했다.
'StayFree' 와 같은 앱을 사용해서, 쇼츠와 Social Media를 차단을 시켰다.
명상 음악을 통해 집중을 느끼는 과정을 하고 출근을 하게 되면, 업무의 능률이 올라간 것을 느낄 수 있었다.
이런 좋은 결정들 하나씩 쌓아가서 더 많은 목표에 도달할 수 있지 않을까?
배우거나 이해한 개념들을 블로그에 글로 공유를 해보려고 한다.
내가 익힌 내용들을 다시 확인하고 내것으로 만드는 연습을 '블로그 공유'로 해보고 싶다.
이번 년도에는 아키텍처 설계에 대한 이해를 하게 됐다.
쓰는 기술을 왜 사용하는지?
아키텍처 설계에 대한 장단점
대안들을 명시적으로 구성하는 방법
또, 애플리케이션 로직 구성시에 도메인 로직과 정책을 쉽게 구성할 수 있게 됐다.
멀티 모듈 구성
도메인 로직 구성 및 분리
다른 프로세스(RDB, 다른 서비스) 와의 통신시 실패처리, 설정
내년에는 회사에서 성능 개선이나 테스트를 전방위적으로 도입해볼 예정이다.
페토그램 서비스운영이 1년이 지나가고 있다.
AWS 비용이 WAF도 추가하고 이래저래 추가하다보니 비용이 조금 발생하고있다.
홈서버로 마이그레이션 해서 운영해볼 생각을 가지고 있다.
