[ 12-3 ] 지난 2024년을 돌이켜보며 (1) 개인적인 부분

서점에서 나의 눈길을 사로잡은 책.

 

벌써 24년은 거의 지나가고있고, 이제 25년이 다가오고 있다. 이번 2024년은 어떠했을까? "좋았다." "나빴다." "성장했다." "유지했다." "퇴보했다". "모르겠다.", "바빴다." 등 많은 단어들이 떠오르는데, 어느 한 단어로 표현하기에는 많이 어려운 것 같다.(너무 당연한건가?)

 

하지만 한가지 내가 분명하게 느끼는 것이 하나 있다. "시간이 흐를 수록 점점 가속이 붙는 것 처럼 느껴진다"는 것이다. 시간은 언제나 일정하고 동일하게 흘러가나, 나는 점점 더 가속이 붙는 것처럼 느껴진다. "일을 할 때도, 왜 벌써 시간이..?", "출퇴근을 할 때도 왜 벌써 도착을..?", "운동을 할 때도, 왜 벌써 시간이..", "지인을 만날 때도, 우리가 벌써..?" 등.. 시간이 너무 빠르게 지나감을 느끼는 단어와 말을 많이하는 내 모습을 보곤한다.

 

현재 작성 중인 회고 글을 작성하면서 또 나는 "왜 벌써 12-3.. 인가?" 하는 생각을 했다. 이렇게보면, 24년은 "바빴다." 이 단어로 표현할 수 있을지도 모르겠다.

 

연말이되면 내가 반드시 하는 2가지 요소가 있다. 두가지 작업 모두 나를 정리하는 작업인데 벌써 올해로 3회차이다. 내가 지난 22년, 23년에 이 작업을 진행하면서 느낀점이 한가지 있는데, 그것은 바로 정말 오래걸린다는 것이다. 올해는 쫒기듯이 작성하지 않기위해 먼저 조금씩 시작해보고자 한다.

내가 연말에 꼭 하는 작업은 1년 회고 와 이력서 업데이트 이다.
- 1년 회고: 지난 1년간 내 스스로의 메타인지를 위해 작성한다. 스스로 아쉬웠던 부분과 잘했던 것, 해보고 싶은 것 등을 포함하고 내년의 목표를 설계하는데 목적을 둔다.
- 이력서 업데이트: 이직을 목적으로 하는 것이 아닌, 나를 잘 다듬고, 내 목표를 향해 나아가고 있는지 등을 확인 및 재정비 하기 위해 작성한다.

 

1년 회고의 경우, 크게 두가지로 구성된다. 1) 개인적인 부분 과 2) 업무적인 부분 이다. 그리고 나는 이번에 개인적인 부분에 대하여 돌이켜보고자 한다.

 

1년 회고에서 개인적인부분과 업무적인 부분
- 개인적인 부분: 내가 생각하는 목표, 성장, 좋았던 점, 아쉬웠던 점, 불편했던 점 등을 돌이켜본다.
- 업무적인 부분: 실제 업무를 진행하면서 느낀점(좋았던 점, 아쉬웠던 점, 불편했던 점 등..)을 돌이켜본다.

 

그리고 이번 2024년의 개인적인 부분은 내가 느끼기에 근 5년간 가장 큰 성장(?)을 한 해라는 생각이 들어, 회고보다는 성장기를 작성해보고자 한다.

이번 글에서는 개인적인 부분 중에서도 나의 성장기(?)를 작성해보고자 한다.

• 개발 가치관 변화
• 일에 대한 나의 생각
• 나의 목표 

---

개발 가치관 변화

 

나는 개발자이다. 그래서 매일 코드를 작성한다. 코드를 작성하고, add를 할 때면 항상 고민을 하곤 한다. 이것이 최선의 코드인가? 수정할 부분은 없는가? 등을 고민한 뒤, 이상이 없다하면 add를 그대로 진행한다. 그리고 내 질문의 답의 기준은 나의 개발 가치관 + 팀의 개발 컨벤션과 일치하는가? 를 중심으로 판단한다.

 

나의 개발 가치관은 "컴퓨터가 읽기 좋은 코드가 아닌 사람이 읽기 좋은 코드를 작성한다."(가독성) 이다. 내가 생각하는 가독성이 좋은 코드는 추상화 수준이 일치하고, 글처럼 읽히며, 작성된 변수 및 함수의 명명을 통해 코드의 로직을 예측 가능한 수준의 코드를 가독성이 좋은 코드라고 생각한다.

 

나는 여전히 가독성이 좋은 코드를 작성하는 것이 코드 작성에서 가장 중요한 요소라고 생각하고 있다. 그러나 가독성과 견줄만큼 중요한 요소로 비용을 생각하게 되었다. 

• 가독성 있는 코드를 작성하다보면, (너무나도 소중한..)리소스를 낭비하는 일이 생기곤했다.(가독성 있는 코드를 작성하는 비용이 비싸다.)
• 올 한해 코드를 작성하면서, 생각보다 작성하는 코드를 계속하여 사용하는 일이 많지 않았다.(한번 작성한 코드를 수정할 일이 많지 않았다.)

 

아직 나는 분명하게 가독성있는 코드를 작성하는데 많은 비용이 사용되곤 했다. 내가 작성한 코드가 실제 팀원들에게는 의도가 분명하게 들어나지 않은 코드가 되기도 하였으며 이로인해 소중한 리소스가 많이 사용되곤했다.

 

하고 싶은 일과 해야하는 일이 많으나, 리소스는 한정적인 상황의 연속의 2024년의 하루들은 결국 나를 고민에 빠지게 만들었다.

• 나는 현재 내가 하고싶은 일 과 해야하는 일에 대하여, 내가 하고싶은 방향으로 일을하고 있지 않은가?
• 제한된 리소스를 효율적으로 사용하기 위해서는 어떤 방법을 적용해야하는가?

 

다양한 질문을 하면서, 나는 스스로 답을 내리지 못하고 있었다. 그러나 개발 업무를 진행하면서, 함께 일하는 대엽님과의 개발 미팅 간 이에 대한 도움을 받을 수 있었다.

대엽님과 진행했던 개발 미팅 중...
나는 4분기 3회차 스프린트 개발을 진행하면서, 기획에서는 고려되지 않았지만, 개발을 진행하면서 예측되는 기능의 확장 가능성에 대하여 어떻게 개발할 것인가? 를 주제로 이야기를 나눴었다.

나는 당시, 개발을 하게되면 너무나도 당연하게(?)얼마 지나지않아 개발 백로그 혹은, 다른 스프린트 수준에서 작업이 진행될 것이라고 생각이 들었다.그리고 이에 대한 대엽님의 의견은 다음과 같았다.

"현재의 설계가 (언급된) 확장가능한 기능을 반영하기에 설계적으로 문제가 있는가? 없는가? 만약 우려되는 확장 가능성을 현재 설계가 수용할 수 없다면, 확장 가능한 기능을 고려하는 것이 아닌, 지금 개발 중인 코드를 먼저 수정해야한다."

나는 정말 머리를 한대 맞은 것 같았다. 그리고 나는 개발 가치관이 바뀌게 되었다.

 

 

비싼 (자체적으로 가독성 있다 생각하는) 코드를 작성할 때 나는 불필요한 부분까지 고려하여 작성하였다는 사실을 알게 되었다.

• 추상화 수준을 맞추기 위해, 함수로 추출 -> 관련된 메서드를 클래스로 추출 -> 관리 포인트 증가하는 모습이 많이 보였다.
• 단순한 가독성 개선을 위해 진행된 작업이, 이것저것 살이 붙어 다른 의도를 포함한 작업이 되었다.(배보다 배꼽이 커지는 일이 많았다.

 

나는 가독성 있는 코드를 작성하기 위해, 현재  불필요한 부분까지 고려하여 코드를 작성한다는 것이었다. 그리고 이는 대엽님과의 대화를 통해 현재 정말 필요한 부분만 해당 부분을 고려하여 작성하는 것으로 개선할 수 있었고, 실제로 작업 퍼포먼스가 많이 향상되었다. 

• (정성 데이터) 코드의 의도가 메서드에 잘 표현되어 있어 코드를 리뷰하기 편했다.
• (정성 데이터) 추가된 클래스의 코드 라인수가 많아 리뷰하기 전 부담이 되었으나, 실제 리뷰 시에는 가독성 있게 읽힘으로써 부담이 되지 않았다.
• (정량 데이터)4분기 스프린트(4-1~5)기준 하루동안 작업해내는 작업 태스크의 양이 평균 2개 에서 5개 수준으로 올랐다.

 

업무 처리량을 동일한 업무가 아닌이상, 처리량을 비교하는 것에 대해 의문은 있으나, 내가 실제로 작업을 하면서, 불필요한 고민과 과정이 많이 개선되어 업무 처리속도가 증가되었다는 것을 채감하고 있어 기록해보았다.

 

정리를 해본다면, 나는 개발 가치관이 변화하였다. 기존에는 가독성이 가장 중요하며, 가독성을 증가시기키 위한 코드 작성 기법을 고민하고 이를 가능한 적용하는 것을 목표로 하였었다. 하지만 이는 비효율적이었으며, 내가 하고싶은 방식대로만 하는 방법이었다. 가독성을 고려한 코드작성은 빈번하게 배보다 배꼽이 더 커지는 경우가 많았고, 개선의 필요성을 인정하게 되었다. 개선 과정에서 나는 개발에서 비용 또한 굉장이 중요한 요소라는 것을 인지하게 되었다. 개발 비용에는 내가 고려한 가독성과, 확장성, 유지보수성 등 다양한 요소가 비용으로 측정 될 수 있다. 여기서 나는 가독성의 비용을 고민하게 되었고, 내가 작성하는 (가독성)코드의 작성 비용 효율성을 개선했다.

 

나는 코드 작성에서 가독성은 여전히 중요하다. 하지만 가독성을 갖춘 코드를 작성하는데 있어 비용 효율성을 고려한 가독성이 중요하다는 개발 가치관으로 성장하게 되었다.

 

---

일에 대한 나의 생각

 

먼저 나는 개발을 사랑(?)한다. 개발이 너무 즐겁다. 개발의 과정과 결과를 보면서 힘들지만 행복함을 느낀다. 하지만 최근 나는 일을 무리하면서 자꾸만 하고싶은 일을 할 수 없는 상황을 많이 직면하게 되었다.

• 24년 평균 주당 업무시간을 계산(출퇴근 시간 제외) 평균적으로 10시간이 넘었다.
• 회사의 일이 많아짐에 따라 개인 공부 시간과 가족과 지내는 시간이 줄어들었다.
• 수면 시간이 줄어듬에 따라 컨디션이 떨어지는 날이 많았고, 하지 않던 실수의 빈도가 늘어났다.
• 소중한 사람과의 시간을 보낼 때에도 다른 사람이 나의 눈치를 보게되는 일이 생기게 되었다.

 

이런 악순환이 반복되면서 나느 일에 대한 생각을 하게 되었다. 나는 일을 왜 하는가? 일은 무엇인가? 등 일과 관련된 질문을 스스로 하게 되었다.

• 내가 일(개발)을 하는 이유: 나는 개발의 과정(일)을 즐기고 있다. 문제를 인지하고, 이를 다양한 방법으로 해결하는 과정을 즐거워한다. 문제를 해결하는 해결책의 다양성에 흥미를 느끼고, 내가 선택한 해결책을 개선해 나가는 것에 대하여 즐거움을 느끼고 있다.
• 내가 생각하는 일은 무엇인가?: 코드를 통해 문제를 해결할 수 있는 것이라면 모두 일이라는 생각을 갖고 있다. 그래서 사실 일과 일상을 구분짓기는 어렵다. 하지만 내가 정한 규칙이 존재한다. 집에서는 회사와 관련된 문제를 생각은 하나, 해결하지 않는다는 것이다. 

 

그러나, 일에 대한 스스로의 질문과 답을 해보면서 나는 큰 문제점 하나를 인지했다. 바로 건강 이다. 나는 흔히 몸을 갈아 넣으며 일을 하고 있었다.  내가 좋아서 한 일이기에, 후회를하거나 누군가를 원망한다는 것은 아니다. 다만, 이것이 문제가 될 것이라는 생각은 전혀 하지 못하고 있었다.

 

(TMI)나는 지금까지 횟수로 8년째 웨이트 등 운동을 지속하고 있다. 작년까지는 내가 원하는 일을 하기에 체력이 부족하다는 생각을 해본 적이 없었다.

 

하지만, 올해는 상황이 달랐다. 나는 목이 아파 감기라 생각하고, 병원에 갔는데 의사 선생님께서 과로 라는 말을 하셨다. 일을 쉬어야하고, 어쩔 수 없이 해야하는 일이라면 정말 무리하면 안된다는 말을 들었다. 이 일을 계기로 일에 대한 나의 태도와 생각을 개선할 필요성을 인지하게 되었다.

 

 

일에 대한 나의 태도와 생각의 변화

 

내가 지금 생각하는 일은 회사의 문제를 해결하는 것이다. 이것은 기존의 생각과 다르지 않다. 그러나, 회사의 문제만을 일로서 정의하는 것에서 과거의 생각과 차이가 있다.

•  과거: 회사 및 일상에서 코드로 작성하는 모든 작업은 일과 동일한 것으로 인지했다. 회사의 업무도 일이고, 집에서의 개인 공부도 일이었다.
• 현재: 회사의 업무만 일로 정의한다. 집에서 하는 개인 공부는 공부 그 이상 이하도 아니다. 개인 공부에 부담 및 강한 책임감을 갖지 않는다.

 

나는 개인 공부도 일이라는 생각을 갖고 있었다. 이는 공부에 대한 강박보다는, 회사 일을 잘하기 위해서는 개발 실력을 계속해서 키워야 한다는 생각에서 회사의 업무와 개인 공부를 모두 일로서 정의했었다.

 

올해 읽은 서비스 기획의 기술 책의 일부분. 모든 일에는 고객이 존재한다.

 

모든 일에는 고객이 존재한다. 회사 일에는 우리 서비스를 이용자와 서비스를 담당하는 관리자가 고객이며, 개인 공부에서는 내가 고객이라 할 수 있다. 

 

이제 다시 일의 정의에 대하여 생각해볼 때, 개인 공부를 일이라고 정의하는게 맞는가? 에 대한 질문에는 그렇지 않다는 생각을 갖게 되었다.

• 고객(나)는 어떤 사람인가?: 나는 개발을 좋아하고 개발 역량 증진에 욕심이 많다. 
• 고객(나)는 이루고자 하는 바가 무엇인가?: 개인 공부를 통해 궁극적으로 회사 일을 잘하고 싶다는 목적을 갖고 있다.
• 고객(나)를 어떻게 도울 수 있는가?: 이루고자하는 바를 달성하기 위해서는 컨디션 조절 및 건강 관리가 가장 중요하다.

 

집에서는 점차 업무에 대한 부담을 줄이면서, 나의 심리적인 부담감과 압박감을 줄이고  보다 보람찬(?) 집에서의 시간을 보낼 수 있게 되었다. 이에 더불어 가장 핵심은, 업무에 보다 더 몰두 할 수 있었다.

 

하지만, 현재 문제는 업무에 부담의 문제는 줄였으나, 업무의 피로도의 문제가 여전히 존재한다. 이 문제는 다음 글(업무에 대한 회고)에서 내용을 정리해보아야 겠다.

 

---

나의 목표 

 

내가 설정한 올해의 핵심 목표 OKR. 나는 처음으로 OKR을 개인적인 부분에서 시도해 보았다.

 

나의 올해(2024)목표는 크게 두가지였다. 1.사이드 프로젝트를 통한 개발 역량 향상 과 2.개발관련 독서와 강의를 통한 개발 역량 증진 이다.

• 새로운 기술을 사용한 최소 2개의 사이드 프로젝트를 진행하는 것을 목표로 설정했다.
• 상반기까지 개발 관련 컨텐츠를 3개이상 공부하는 것을 목표로 설정했다.

 

그리고 목표와 관련된 나의 행동을 정리해보면 다음과 같다.

• (1) FastAPI를 공부하기 위해, fastapi-playground 를 만들어 FastAPI, Pydantic, SQLAlchemy를 학습하고 연습했다.
• (1) 같은 기능 다른 구현을 학습하기 위해 spring-playground 를 통해 다양한 도메인(user, skeleton, jpa, kotlin-spring 등)을 학습했다.
• (1) SNS(FE 영역)을 직접 만들어 보기 위해 React, typescript 를 활용하여 sns-nextjs를 만들어 보았다.(진행 중)
• (2)서비스 기획의 기술(책), 켄트 벡의 Tidy First?(책), 이펙티브 엔지니어(책), 육각형 개발자(책), 그로킹 동시성(책)을 읽었다.
• (2) Pydantic V2:Essentials(강의, 완강), 데이터베이스 엔지니어링(Database Engineering) 마스터하기(강의, 진행 중), 개발자를 위한 Redis 완벽 가이드(강의, 진행 중)을 수강했다.

 

강의를 보고, 책을 본다하여 해당 내용이 모두 내것이 되는 것이 아니라는 사실을 분명하게 인지하고 있다. 그러나 분명하게 이 책들과 강의를 통해 개발 역량과 생각, 과정이 많이 개선되었다. 그리고 올해 가장 인상적인 내용은 육각형 개발자의 일부분이다.

 

트레이드 오프, 모든게 완벽한 것을 추구하지 않고, 가장 나쁘지 않은 것을 선택하자. 육각형 개발자의 일부분

 

항상 모든 선택에는 트레이드 오프가 존재함을 인정해야한다. 그리고 어떤 선택을 할지에는 어떤 가치가 더 중요한지 따져보고 판단해야한다. 나는 이 생각(모든 선택에는 트레이드 오프가 존재함을 인정한다.)를 하지 못했다. "이런 문제가 생기는데 어떻게 해야하지?" "이 선택을 하게되면 결국 저 문제가 발생할텐데, 나는 어떤 선택을 해야하지?" 그러나 육각형 개발자 및 다른 책들을 읽으며, 해당 고민에 많은 스스로의 결정을 할 수 있는 방법을 배웠다.

 

이펙티브 엔지니어의 일부분. 우리는 레버리지가 높은 곳에 투자해야한다.

 

이 뿐만아니라, 어떤 선택을 하는 것이 좋을지 많은 힌트를 준 이펙티브 엔지니어 책과 전반적인 서비스 개발 의사결정에 맣은 도움을 준 서비스 기획의 기술 등 많은 독서를 통해 많은 내용을 학습할 수 있었다.

 

올 한해는 빈틈 없이 모두 잔디를 채우지 못했다.. 그래도 열심히 시간을 쪼게 개인 공부를 기록했다.

 

그리고 많은(?)프로젝트 개발 공부 덕에 실제 업무에서 많은 도움과 인사이트를 얻을 수 있었다. 대표적인 내용에는 다음 이야기들을 할 수 있을 것 같다.

• fastapi-playground를 직접만들어 연습하면서, 실제 서비스 내, API 내 response_model을 추가하여 응답 값의 예시를 적용하여 FE 개발 편리성을 증진시킬 수 있었다.
• Pydantic을 연습하면서, 파이썬의 타입 안정성을 증진시키고, 입력 값의 안정성 문제를 사전에 해결할 수 있었다.
• SQLAlchemy를 학습하면서, ORM의 장점을 살리면서 코드의 가독성을 증진 시킬 수 있는 방법과 다양한 쿼리 방법을 학습하여 raw query 작성을 줄이고, ORM을 통한 코드 안정성을 증진시킬 수 있었다.
• spring-playground 를 통해 다양한 구현 방법과 현 서비스에서 직면하지 않은, 그러나 직면할 수 있는 문제에 대한 다른 구현 방법을 학습하고 이를 현 서비스 사용 스택으로 적용방법을 학습할 수 있었다.

 

내가 공부한 내용이 실제 업무에 적용된 것들도 아닌 것들도 있지만, 지금까지 공부한 내용들을 기반으로 많은 기여를 할 수 있었던 것 같다. 라고 자신감있게 이야기할 수 있다.

 

비록 연말이 될 수록, 새로운 기술 공부에 시간 투자 비중이 줄어들었지만,  포기하지 않고 꾸준히 하다보니 이런 결과물을 얻을 수 있던 것 같아 뿌듯하다. 

 

 

그런데 잊지 말아야할 것이 하나 있다. "화이트보드에 내가 작성한 목표들은 궁극적으로 무엇을 위한 목표들인가?" 나의 개발의 목표는 서버 개발만 하는 개발자가 되는것이 아니다. 나는 다양한 경험과 지식을 바탕으로 아키텍트가 되는 것이 목표로 화이트 보드에 해당 목표들을 작성하였다. 

 

그리고 한해가 끝나가는 지금, 나의 목표는 아키텍트 보다는 스태프 엔지니어라는 사실을 알게되었다. 사실 스태프 엔지니어는 기업과 조직마다 약간씩은 다르게 정의를 내리고 있는 것으로 알고 있다. 이와 관련하여 내가 정의한(책에서 참고한) 스태프 엔지니어는 다음과 같다.

• 제한된 상황에서, 제시간에 프로젝트가 완료 될 수 있도록 프로젝트를 만들어 내는 사람을 의미한다.
• 스태프 엔지니어는 견고한 시스템 결과물을 구성하고, 기업의 기술 환경이 적합(적절)한지 확인하는 책임을 진다.
• 아키텍트와 차이점이라고 한다면, 아키텍트는 추상적인 수준에서 기술적인 설계를 하는 사람으로 나는 정의하였다.

 

즉, 내가 생각하는 스태프 엔지니어는 리더의 역할을 맡으며, 기업 프로젝트나 팀 차원에서 '누군가가 이 지점에서는 무언가를 해야하는 상황이 발생한다면, 그 누군가가 바로 스태프 엔지니어이다.

 

스태프 엔지니어에 대하여 알게 해준 책. 작성 시점 아직 다 읽지 못했다.

 

 

누구나 그렇듯(?) 나 또한 단순한 코드 작성만 하는 개발자가 되고 싶지 않다. 일부분이 아닌 전체를 이해하고 보다 합리적인 의사결정을 할 수 있는 사람이 되고 싶다. 동시에 다른 사람들에게 긍정적인 영향을 줄 수 있는 개발자가 되고 싶다. 이런 내 목표를 고려할 때, 나는 스태프 엔지니어가 내 커리어의 목표로 적절하지 않을까 하는 생각이 들었다.

 

---

 

요약: 그래서 24년은 나에게 어떤 한 해였는가?

 

나의 24년 개인적인 부분은 아쉽다. 돌이켜보니 한 것은 좀 있는 것 같은데 정리도 기록도 되지 않았다. 이런 부분은 분명하게 내가 개선해야 할 부분으로 인식된다. 그리고 정리 하지 못한 부분에 대하여 정리가 되었을 때, 어떤 긍정적인 결과가 나타날지 기대도 된다.

 

24년은 아쉽지만, 올 한해가 근 4년간 느끼지 못했던 성장통(?을 크게 겪은 한해라는 생각이 든다. 첫 개발자로 취업을 했을 때에도 느끼지 못했던 다양한 개발적 고민과 행동을 경험하면서 분명하게 내가 성장한 것 같다. 비록 효율적으로 성장했는가? 에는 노코멘트 하겠다..

 

올 한해 마무리는 내 생일의 내 모습으로..!

 

 

이제 내년이면 벌써 30이다.. 왜 벌써 30대가 되었는지 모르겠다만.. 부디 내년에는 보다 더 성장한 내가 될 수 있도록 한 해를 잘 설계해서 농사를 잘 지어 보아야 겠다!!