백엔드 개발자로 밥벌이 1년을 축하하며 2022년의 회고를

집앞 멋진 롯데타워 뷰

 

드디어 내가 개발자로 밥벌이를 한지 1년이 되어가는 시점이 왔다.

 

매년 내가 스스로 성장해가는 것이 느껴질 만큼 항상 난 뭔가를 많이 해왔고 돌아보면 그것들이 매우 가치있는 것들이었다.

 

올해 2022년도 마찬가지로 한 해를 돌아보면 정말 많은 것들을 했다는것을 느꼈다. 개발자의 꿈을 품었던 지난 2019년도와 공부에 미쳐있던 2020년, 2021년도와 비교도 되지 않을만큼.

 

우선 큰 이유는 바로 내 취업이다.

 

첫 취업과 이직을 포함한 전반적인 2022년도

 

카페에서 막 써본 내 1년간의 기록

 

난 2019년 첫 개발을 시작할 때 부터 꼭 네이버, 카카오, 라인이 내 첫 직장이 될 것이고 그것만이 유일한 option 이라고 스스로 세뇌를 시키면서 살았다.

 

그래서 대부분의 나의 취준 커리어나 학습 방향 및 목표가 흔히 말하는 네카라에 맞춰져 있었고 정말 오랜 시간동안 기대하면서 꿈꿔왔었다.

 

그리고 내가 부족한 것이 무엇일까? 를 고민해보다 인턴 경력이 지금 상황에서 꽤나 유용할 것이라는 판단이 들었고 2019 년도에 지인 추천으로 지원해서 떨어진 ukov 라는 단체에 다시 지원을 해보았다.

 

나는 java/spring 을 주로 했었고 그간의 프로젝트들이 대부분 java/spring 으로 구성되어있었다.

 

인턴쉽 참여사들의 대부분은 스타트업의 특성인지 node/python 을 사용하는 참여사들이 많았고 내가 좋아하는 것을 잘 할 수 있는 곳은 드물었다.

 

당시 MSA 나 CNCF 같은 cloud infrastructure 에 관심이 많던 나의 관심을 끌기에 트레바리의 채용공고는 기술적으로 너무나도 완벽했다.

 

그리고 기술보다 더욱 멋진건 당시의 팀의 가치에 대해서 써놓은 몇가지 말들이 나를 흥분시켰고, ukov 를 추천해준 지인이 트레바리의 새로운 cto 님이 유명하시고 잘하시는 분이다 라는 말에 힘입어 결국 트레바리를 지원하기로 마음먹었다

 

하지만 그럼에도 불구하고 머릿속 다른 한 곳에서는 나는 인턴쉽이라는 한줄짜리 취업 스펙이라는 생각이 머릿속을 지배했었고 흥분과 냉담이 공존한 채로 트레바리에 입사를 하게 되었다...

 

트레바리에서의 1년

 

트레바리에서의 1년은 앞서 언급한 나의 원대한 계획에 전혀 예상에 없던 여정이었다. 

 

트레바리 커피

 

그렇게 시간이 흘러 첫 출근, 첫 일주일, 이주, 삼주, 한달이 지나게 되었고 나는 전혀 다른 종류의 개발자가 되어있었다.

 

정확히는 다른 종류라기 보다는 "나는 어떤 커리어를 쌓아서 어떤 회사에 다닐 것인가?가 아니라 어떤 경험을 통해서 개발자로 성장해야 하는가?" 라는 형태의 사고 전환이 있었다.

 

트레바리의 몇개월이 개발을 처음 시작한 2019년도부터 2022년 초까지 내 머릿속을 지배했던 네카라의 길을 반전시킬 만큼 강력한 사건이었다.

 

그렇게 트레바리에 합류하고 1년여간 정말 많고 다양한 프로젝트를 진행했다.

 

대표적으로는

 

• notifier
  • composite pattern with double dynamic dispatch
  • api first design by oas
  • 그림을 통해서 대화한다
• refund
  • test code as a documentation
  • test code 는 내 프로덕션 코드의 첫번째 클라이언트
• membership terminator
  • specification pattern 과 policy 를 통한 비즈니스 정책을 코드화
  • test code 의 합성함수 논리의 책임감
• lagecy refactoring
  • testcode 대신 small step 을 통해 마음의 확신
  • hexagonal architecture for domain protection
  • 방어적 프로그래밍
• seoulyeok
  • event driven architecture (message polling publisher & event streams)
  • 오픈소스 메인테이너의 마음가짐
  • 클라이언트 관점의 api
• cohort dashboard
  • oop & domain driven
  • regressive integration test
  • message integrity layer for loss & Redundant & ordering

 

그 중 몇가지의 성장에 대해서 공유해보자면

 

1. 그림을 통해서 대화한다

 

트레바리에 있으면서 나는 그림을 정말 많이 그렸다. 많이 그리고 많이 찢고 많이 잃어버리고 많이 성공하고 많이 실패하곤 했다.

 

그간 트레바리에서 그렸던 몇가지 그림들

 

내가 처음으로 진행한 notifier 라는 프로젝트는 나에게 그림을 통해서 사람들과 대화하는 법을 알려준 프로젝트이다.

 

학부시절 소프트웨어 공학 시간에 시험문제로 그리던 다이어그램을 실무에서 만날줄은 몰랐다. (ㅋㅋㅋ.. 사실 난 정말 쓸모없는 수업이고 이런 그림을 누가 그릴까 하며 대충 봤던 수업이라 뜨끔했다) 그때 주의깊게 보지 않은 것을 후회했다

 

notifier 이외에도 트레바리에서 나는 그림을 통해서 대화했다.

 

그림을 통해서 내가 그린 아키텍처를 설명하고 그림을 통해서 이해하곤 했다. 모든 프로젝트가 트레바리에서는 그림을 통해서 공유된다

 

필요에 따라서 usecase diagram 도 그려보고 event storming 을 통해서 event 와 message 를 정의하기도 하며 state diagram 을 그리며 도메인의 lifecycle 에 대해서 고민하기도 했다

 

그리고 그 그림은 찢어서 버리거나 잃어버린다.

 

처음에 그림을 그리는 것에 대해서 실수한 몇가지가 있는데, 그림을 너무 잘 그리려고 노력했다는 것이다

 

그림을 잘 그리려다보니 그림을 그리는 것 자체에 매몰되더라.

 

그림을 그리는 가장 중요한 이유는 의사소통이다. 이 사실을 깨닫고 난 후 나는 여기저기 그림을 난발하고다녔다. 심지어 개인 프로젝트에서도

 

2. test code 의 합성함수 논리의 책임감

 

이 소제목이 의미하는 바는 결국 테스트를 어디까지 할 것인가? 에 대한 이야기다. 내가 작업한 부분에 대해서만 테스트 코드를 작성해야 하는가? 내가 작업한 부분과 연관되어있다면 모두를 테스트해야 하는가?

 

때는 트레바리 독서모임 멤버십 해지 레거시 리팩토링 작업때였다. 멤버십 프로젝트는 트레바리의 코어라고 불리울 만큼 거대하고 중심이 되는 프로젝트이다.

 

해당 프로젝트의 큰 수정이 있었고 member 가 협력하는 다른 프로젝트도 full path 로 테스트를 해야하는가? 에 대한 의문이 있었고, 결국 팀과 리더의 상의 끝에 다음 논리를 따르기로 했었다.

 

합성함수 논리

 

즉, 함수 x 가 true 이고 함수 y 가 true 이면 합성함수 xy 도 true 라는 논리에 의해서, 새로 배포하는 기능 x의 테스트가 성공하고 이고 기존에 동작하던 기능 y 가 테스트에 성공하면 이전 기능을 보장한다! 라는 논리에 따르게 되었다

 

그리고 그 다음 작업에서 위의 논리를 그대로 적용했는데, 큰 문제가 발생했다.

 

새로운 기능 x 가 테스트에 성공하고 이전의 기능 y 가 테스트에 성공했지만 결국 이전의 기능 y 의 테스트가 올바르지 않아서 배포된 xy 가 장애가 발생한 것이다.

 

이를 통해서 알 수 있는 사실은 두가지였다

 

1. 단위 테스트와 통합 테스트는 다르다. 합성함수의 논리도 타당하지만 통합 테스트는 통합 테스트가 갖는 의미는 단위 테스트의 의미와 다르다. 이 둘을 같은 위상으로 보지말아야 한다
2. 책임감이 필요하다. 누군가는 나의 기능을 합성함수 논리로 사용할 수 있다.

 

3. testcode 대신 small step 을 통해 마음의 확신

 

복잡한 레거시를 마주할 때면 두려운 이유는 바로 코드 수정에 대한 확신이 없어서라 생각한다.

 

나는 앞선 선배 개발자의 지혜를 본받아 small step 으로 마음의 신뢰와 확신을 얻는다.

 

이를테면 pr 을 잘게 나누어서 리뷰를 받는다. 그리고 잘게 자주 배포한다. 롤백은 언제나 준비되어있다.

 

가끔 일을 하다보면 꼼꼼한 리뷰가 필요한 분야에서 동료들의 리뷰를 적절히 받지 못하는 경우가 생긴다.

 

누군가 내가 과거에 싸놓았던 pr 들을 보면 당연하다고 느낄 것이다. 무엇을 리뷰해야하는지 모르고 무엇이 개선되었는지 전혀 코드에 드러나있지 않기 때문이다.

 

특정 시점 이후부터 나는 레거시를 마주할 때 PR 을 잘게 나누고 리뷰어들에게 인지 부조화를 막도록 최대한 힘쓴다.

 

내 개인적 성장의 1년

 

앞서서 '트레바리 백엔드 개발자 장원익' 에 대한 1년에 대해서 이야기 했다면 이번에는 '개발을 좋아하는 장원익' 의 1년에 대해서 이야기해보려 한다.

 

 

2022년 올 한 해의 내 활동을 대표하는 키워드는 오픈소스이다.

 

이번 년도에는 오픈소스 활동에 눈을 떴다.

 

회사에서 seoulyeok 이라는 오픈소스를 만드는 작업을 하다보니 자연스럽게 오픈소스에 대해서 많은 관심을 가지게 되었다

 

그래서 1년동안 2개의 프로젝트를 오픈소스로 릴리즈하였다

 

1. zsmq (zola simple message queue)
2. cqrs journey guide 한글 번역본

 

2022년을 대표하는 나의 프로젝트들

 

이제 하나씩 가볍게 이야기해보자

 

생에 첫 오픈소스 프로젝트: zsmq

 

오픈소스 활동을 시작한 첫 프로젝트가 바로 zsmq 다.

GitHub - dhslrl321/zsmq: 📨 Zola (Extremely) Simple Message Queue for spring, It is the simplest Message Queue you've ever exp

 

zsmq 도 역시 그림이 빠질 수 없다

 

시작은 내가 회사에서 event driven architecture 로 일부 시스템의 패러다임을 전환 하는 과정에서 기존에 알고있던 CRUD 와는 다른 몇몇의 개념들이 등장했다.

 

그래서 한동안 내 관심사는 EDA 에 빠져있었는데, 그에 따라 자연스럽게 여러 학습 및 자료를 접하며 느낀 불편함이 있었다.

 

그것은 바로 학습용 프로젝트 환경 세팅이었다.

 

event 에 대해서 친해지고 학습하기 위해서는 message queue 개념이 중요하고 자주 사용되는데, mq를 비롯한 프로젝트 환경 세팅에 너무 많은 시간을 빼앗긴다는 이유였다

 

그래서 mq 의 핵심 개념만을 가지고 동작하는 가장 간단한 model 을 만들기로 결심했고, 그것이 바로 zsmq 다.

 

나는 이전에 업무를 하면서 기술적으로 굉장히 멋진것들, 배움들, 시도해볼만한 것들을 어디엔가 따로 정리를 해놓고 있었고 이들을 언젠간 나의 것으로 만드리라라는 생각이 늘 존재했는데, zsmq 가 바로 그런 도화지였던 것이다.

 

앞서 내가 회사에서 배웠던 것들을 모두 쏟아낼 수 있는 자리였다

 

코드 레벨의 naming convention, reflection, immutable, dbc, 컴포넌트 레벨의 gradle module 설계, 객체지향의 composite, strategy, 결정하지 않는 아키텍처, 프로젝트 레벨의 spring-boot-starter, sym-ver, deploy...

 

내가 만든 것이 제품이 되게하라 라는 사명을 똑같이 이 프로젝트에 적용했고, 누군가가 내가 만든 코드를 보고 지적하며 감탄하고 유용하게 사용하길 바라며 사소한 것 하나 하나에도 신경을 썼다.

 

실제로 성공한 라이브러리를 보면서 내 오픈소스를 가꿔나갔다

 

디렉토리와 module 구조는 어떻게 되는지를 spring 을 보면서 배워나갔고 메시지 큐는 어떻게 구성되고 동작하는지는 aws 의 sqs 를 참고했다.

 

결국 이 프로젝트로 인해서 나는 실행하는 개발자가 되었다고 스스로 생각한다. 이 프로젝트가 있었기에 난 무엇이든 끝낼 수 있다라는 자신감을 얻게 되었다

 

'나'라는 개발자를 알린 프로젝트: cqrs journey guide

 

앞서 이야기하였듯, 내가 속한 조직에서는 event driven architecture 로 패러다임을 전환하는 과정이었다.

 

그래서 자연스럽게 cqrs, event sourcing 이라는 개념에 대해서도 접할 수 있었다.

 

그리고 사내 스터디 목록을 찾아보다 cqrs + event sourcing 의 정수라고도 할 수 있는 책인 cqrs journey guide 를 하는것이 어떻겠냐는 의견이 나왔고, 그렇게 나는 cqrs journey 에 대해서 접할 수 있게 되었다.

 

cqrs journey guide 가 정수라는 것은 cqrs 에 관심이 있는 사람이라면 알 수 있지만 영문판 원서만 존재하는 이유로 알찬 책의 내용과 구성에 비해 잘 알려지지 않은듯 했다

 

그 길로 나는 cqrs journey guide 의 한글 번역본을 만들기 시작했고 대략 4개월에 걸쳐 프로젝트를 완성시켜나갔다.

GitHub - dhslrl321/cqrs-journey-guide-korean: 🚘 CQRS Journey 의 한글 번역본 (Korean version translation of Microsoft's

 

현재까지도 책의 뒷부분은 번역이 되지 않았지만 현재 약 80% 번역이 끝난 상태다.

 

cqrs journey guide 는 또 다른 의도가 숨어있다.

 

나는 self-pr 을 되게 중요하게 생각한다.

 

그래서 가끔 '나'라는 개발자를 어떻게 세상에 알려야할까? 를 고민하곤 하는데, cqrs journey guide 는 '나의 cqrs 관심을 세상에 표출하기' 에 충분한 프로젝트였다.

 

그리고 실제로 많은 사람들에게 내 관심을 보여주고 또 그들의 관심에 대해서도 들을 수 있는 너무 소중한 기회였다.

 

zsmq 를 개발 하면서 나 혼자만 고군분투하기에 오픈소스라는 느낌을 사실상 받지 못했다. 하지만 번역 프로젝트는 정말 오픈소스라는 생각이 들었다.

 

너무 감사한 cqrs journey guide contributors

 

누군가는 내가 미뤄놓은 번역을 대신 해주는가 하면 누군가는 사람들은 오타를 수정해준다. 또 누군가는 잘못된 번역을 지적하고 정정해준다.

 

 

지난 나는 cqrs 를 이렇게 생각하고 정의내린다 라는 글을 통해서 내가 생각하는 cqrs 와 몇몇 사람들이 오해하는 cqrs 에 대해서 이야기했듯이, cqrs 라는게 더 자연스럽게 받아들여져야 한다고 믿는다.

 

그래서 cqrs 에 대한 사람들의 관심을 더 끌어올리는데 업계에 대한 기여를 한것 같아서 스스로가 매우 자랑스러운 프로젝트이다

 

그 외에도

 

개인적인 활동으로는 그 외에도 몇가지가 더 생각난다.

 

내가 좋아하는 부엉이를 닮은 개발자 님의 회고에 영감을 받아 나도 읽었던 책과 스터디를 나열해보려 한다

 

나는 2022년 한 해 동안 4개의 스터디를 진행했고 중도포기한 책 4권을 포함해 총 11권의 책을 읽었다.

 

스터디

• effective unit testing
• 자바 성능튜닝 이야기
• 클린코드
• 오브젝트

 

책 '오브젝트' 가 가장 기억에 남는 스터디였는데, 다양한 개발자들과 만나서 서로의 의견을 가지고 토론하며 경험을 공유하는 시간이었다. 이 스터디로 인해서 객체지향 사고에 더 가까워졌고 그 매력을 느껴버렸다.

 

2023년도에도 난 꾸준히 스터디를 할것 같다. 이전처럼 여러 사람들의 경험을 더 들어보고싶다.

 

독서

올해의 책

• 클린 코드
• 클린 아키텍처
• 대규모 시스템 설계 기초
• 소프트웨어 개발의 본질
• 도메인 주도 개발 시작하기, DDD 핵심 개념 정리부터 구현까지
• CQRS Journey Guide
• Effective Unit Testing
• Kotlin In Action
• (중도 포기) Building Event-Driven Microservices
• (중도 포기) Effective Java
• (중도 포기) Domain Driven Design eric evans

 

총 11권의 책을 2022년동안 읽었다.

 

책들을 자세히 보면 책의 난이도가 정말 들쑥날쑥하다는 것을 알 수 있다. 이 중, 내가 중도 포기한 책 3권은 effective java 를 제외하고는 난이도 조절 실패로 인한 중도 포기였다.

 

내가 읽는 책이 당장 impact 를 낼 수 있는가? 에 집중할 것인가 혹은 시기에 맞는 탄탄한 기본기를 위한 책을 읽어야 하는가? 이 둘 사이에서 여전히 저울질 중이다

 

내가 1년간 받았던 피드백들

 

1년동안 난 참 다양한 피드백을 받았던것 같다.

 

그 중 몇가지는 너무 정확하고 차가워서 아팠던 피드백이 있고 몇가지는 감격의 눈물이 날만큼 좋은 평가를 받았던 것들이 있다.

 

이 피드백들을 긍정적인 것과 부정적인 것으로 나누어서 하나씩 가볍게 분석해보자

 

긍정적인 피드백

• 원익님은 문제 해결에 있어서 집요함이 있어요
  • 전 직장의 시니어 개발자분이 해주신 피드백이었다. 적어도 내가 맡은 일에 대해서 어떻게든 끝내는 사람이구나? 라는 인상을 심어주고싶어한다
• 너는 너한테 무슨 문제가 있는지 잘 아는것 같아, 그리고 그 문제를 해결하는 방법도 꽤나 빨리 찾고 그것을 실제로 해
  • 가장 가까이서 지내며 스터디와 회고를 하는 대학 선배들이 해주신 피드백이다. 난 계속해서 스스로를 객관적인 시선에서 보려고 하고 action item 을 꼭 뽑아내려 노력한다
• 원익님은 무언가를 배우면 확실하게 본인의 것으로 만들려는 노력이 보여요
  • 가장 가까이서 일하는 팀 동료의 피드백이었다. 요즘은 적은 걸음이지만 완벽한 small step 에 대해서 관심을 가지고 있고 이 모습이 보였을것 같다.
• 원익님은 어떻게 이런 사람이 신입일까? 하는 생각이 들어요
  • 이 말을 해준 사람은 100% 진심에서 나온 말이 아니었을것이라 나는 확신한다. 하지만 이렇게 과장해서 말할 만큼 내가 무언가를 보여주었구나 하는 생각에 스스로의 자존감과 책임감이 올라가는 말이라 잘 간직하고 있다

 

부정적인 피드백

• 원익님은 일을 할 때 다른 사람들과 이야기하는 시간이 적은것 같아요.
• 원익님 코드에 너무 매몰되어있는것 같아요. 해결책이 올바른가 확인해보았으면 좋겠어요
  • 위 두 피드백은 모두 같은 맥락이다.
  • 난 아직 문제 해결 자체에 집중을 하고있다. 어떻게 코드를 짜고 어떻게 기술적으로 해결할 것인가?
  • 그리고 아직은 비개발 동료들과 의사소통이 두렵다.
    • 내가 이런 말을 했을때 저 사람들이 나를 멍청이라고 생각하면 어떡하지? 라는 생각을 실제로 한다
• 원익님 코드에 꼼꼼하지 못한 부분들이 보여요 원익님의 사소한 실수들이 모여서 장애가 나요
  • 사소한 실수로 인해서 사소하지 않은 장애를 두번이나 냈었다. 그 사소한 실수가 고쳐지지 않아서 동료들이 몇시간이나 연장근무를 한 적도 있다.
  • 이로써 더 small step 에 집중하는 경향이 있다. 내가 안도할 수 있는 small step.
    • 전 cto 님의 노하우를 따라 small step 에 집중한다
      • 이를테면 pr 을 small step 으로 나눈다. 그리고 잘게 리뷰를 받고 잘게 배포를 내보낸다
    • 이는 대부분 레거시 리팩토링에서 사용되는 기법이다
• 너의 커리어에 대해서 너무 조급해하지 말아라. 이러다간 일을 그르칠 수 있겠다는게 보인다
  • 나는 이직을 할 수 밖에 없던 상황에 놓여졌었다. 그리고 예정에 없던 이력서와 경력 지원을 한동안 엄청나게 했다
  • 결과가 좋지 않았고 그에 따라 잘못된 선택지들을 고민하고 있었는데, 주변의 경험 많은 선배들이 해준 조언이 있었다.
    • 이로 인해서 나는 올바를 선택을 할 수 있었는데, 그것이 나의 내년 커리어를 책임질만큼 엄청난 선택이었다.

 

2023년과 내년의 나의 목표

 

최근 나에게 좋은 기회와 제안으로 인해서 LG U+ 의 아이들나라 라는 회사로 이직을 하게 되었다.

트레바리의 값진 경험 덕분에 개발자로 밥벌이를 시작한지 1년만에 많은 것들이 바뀌었다.

 

더 나은 근무 환경과 더 나은 복지를 받으며 더 혹독한 상황에 나를 내쳐질 수 있게 되었다.

 

이 혹독한 상황에서 나는 다음 3가지 목표를 가지고 달려갈 것이다

 

첫번째 목표는 나의 능력과 템포를 그들에게 알리는 것이다.

 

내가 그간 배운것들이 헛되지 않게, 오버하지 않고 나만의 템포를 그들에게 보여주는 것이다.

 

그리고 또 나는 피드백을 받는다. 그 피드백으로 다시 배운다. 또 다시 피드백을 받는다. 또 다시 배우고 성장한다.

 

두번째 목표는 앞서 얻은 것들을 잃지 않는 것이다.

• 여러 의사소통의 도구들
• small step 의 힘
• 문제 해결의 집요함과 책임감

 

힘들게 얻어낸 나의 키워드이다. 고작 1년으로 모두 나의것이 되지 않으리라 확신한다.

 

잃지 않도록 경계한다

 

세번째 목표는 1일 챌린지를 계속하는 것이다.

도전적인 것들을 기록하는 1일 챌린지 대시보드

 

약 3개월 전에 1일 챌린지라는 것을 시작했다.

 

위의 그림처럼 하루에 미리 정의된 목표들을 달성하면 하나씩 칸을 채우고 그에 따라 월마다 결산을 하면서 더 나은 다음을 위해 회고와 그 결과로 action item 을 뽑아낸다.

 

월별 챌린지 결산

 

그리고 달성한 challenge 개수를 세어 그래프를 그릴 예정이다.

 

이 기록들은 아마도 내년 회고에서 쓰이겠지..

 

결론은 새로운 목표는 없다.

 

앞선 글을 보면 알 수 있듯 다 이전에 하던 것들이다. 신년이라고 해서 새로운 목표는 없다.

 

그냥 내가 지금까지 얻은 것들을 계속 잘 할 수 있도록 짐을 줄이는게 내가 지금 할 수 있는 최선이라 판단되었다.

 

늘 그렇듯 난 필요에 의한 목표 조정이 끊임없이 이루어질 것이다.