나만의 생각으로 채운 2024년

벌써 2024년이 끝났다.. 

여기서도 쓸 줄은 몰랐지만 길었다면 길었고 짧았다면 짧은..

 

이런저런 일들이 많았지만 작년 나에게 영향이 많았던 일을 정리해보려 한다.

 

 

파트장 관리 경험

2022년 11월 입사하고 2023년 12월 파트장이란 직급을 맡았다.

 

처음에는 거부감이 먼저 들었던 거 같다.

부담감도 있었고 아직은 개발을 더 해야 하지 않나 라는 생각이 넘쳤지만,

지금 생각해보면 회사 다니면서 잘 한 일중 하나라고 생각이 든다.

 

파트장을 맡으면서 힘든것도 많았지만 성장도 많이 한 거 같다.

특히 일을 어떻게 해야할지에 대해 많이 배웠다.

 

1. 제가 이해한게 맞을까요?

 

파트장이란 직급을 달며 결정을 해야 하는 일이 많아졌다.

초반에는 결정해야 하는 건 너무 큰 부담으로 느껴지고, 모든 걸 알아야 한다는 압박감이 있었던 거 같다.

결국 이러한 생각이 실수로 이어졌었다.

 

웹뷰 프로젝트를 진행하며 클라이언트와 연결하는 브릿지에 동작에 대해 논의를 진행했는데,

브릿지 동작에 대해 애매하게 이해한 상태로 작업을 진행하게 되었다.

덕분에 QA 중 동작 이상이 있었고, 브릿지 설계부터 다시 진행을 하는 것에 일정이 하루 딜레이가 되는 상황이 벌어졌다.

일을 하다 보면 항상 일어나는 일이지만, 나의 애매한 결정 때문에 이러한 상황이 발생했다는 것에 부끄러웠던 거 같다.

그때 이후부터 모르는 것이 부끄운게 아닌 아는 척이 더 부끄러운 것인걸 깨달은 거 같다.

 

항상 애매하거나 모르는 것에는 이해한 것에 대해 정리를 하고 다시 확인을 요청했다.

"제가 이해한 건 이런데 제가 이해한 게 맞을까요?"

누군가에게는 귀찮고 이것도 모르나 싶겠지만 제대로 된 일을 진행하기 위해서는 항상 필요한 질문이란 걸 잊지 말자.

 

여담으로 웹뷰와 클라이언트의 연동은 정말 신중해야 한다.

앱은 배포 일정이 있고 한번 배포가 나간다면 버전이 살아 있는 이상 코드를 수정할 수 없다.

신중하고 신중해야 웹뷰의 숙명인 버전 분기를 피해 갈 수 있다는 것도 잊지 말자.

 

 

2. 무엇을 포기해야 하는가?

 

관리 업무를 하다 보면 많은 확인 요청과 PR 요청 개발 업무들이 쌓이기 시작한다.

처음에는 스트레스를 많이 받았던 부분인 거 같다.

 

그러다 친한 동료분의 말이 해답을 준거 같았다.

"무엇을 챙기는 것보다 무엇을 포기하는 선택이 더 중요하다."

 

쌓인 업무 전부 같은 기간에 완벽하게 해결하고 마무리하는 것은 불가능하다.

이걸 받아들이니 머리가 조금은 덜 복잡해지기 시작했던 거 같다.

 

그러면 "어떤 걸 포기하는 게 맞을까?"로 생각을 해보기로 했다.

• 맡은 프로젝트의 목적은 무엇인가?
• 지금 일이 프로젝트 목적에 중요한 일인가?
• 크리티컬 한 이슈인가?
• 우리 파트가 병목인가?

대략적으로 위 사항들을 생각하며 맡은 업무의 우선순위를 따져갔다.

신경 써야 하는 곳이 명확해지고 집중을 하다 보니 효율이 늘어난 거 같았다.

하지만 따라오는 단점은 누군가에게는 빌런이 되는 상황이 생긴다.

이걸 감당해야 가능한 일인 거 같다..

 

모든 걸 항상 저 상황에 맞게 꽉 막혀서 움직이는 걸 경계하자

중요한건 지금 정말 중요한 게 뭔지에 대한 유동적인 판단이다.

 

 

3. 우리의 목적은 무엇인가?

 

일을 하면서 생각보다 잊기 쉬운 주제인 거 같다.

당장 일이 바쁘다면 앞에 있는 일을 쳐내기 바쁜데 언제 생각하고 있어라는 생각이 든다.

맞는 말이지만.. 그럴 때일수록 한번 상기를 하는 게 좋은 거 같다.

 

그래야 내가 무엇을 중요하게 생각해야 하는지 판단이 들고 그거에 따라 일정 관리가 된다.

무엇보다 개인, 파트 단위보다 프로젝트 팀 단위로 하는 것이 더욱 효과적인 거 같다.

특히, 새로운 프로젝트일수록 매우 중요하다고 느낀 거 같다.

 

이번에 새로운 프로젝트를 맡으며 빠른 일정에 맞춰 개발을 진행해야 했다.

앱, 웹, 어드민 등등 많은 것이 하나의 서비스 운영을 위해 빠르게 움직여야 했다.

 

앱 개발은 있었던 기능 떼어내 신규 앱으로 만드는 상황이라 일정이 넉넉하지 않았다.

우리의 목표 설정은 당연히 빠른 개발이었다.

 

개발자라면 기존의 레거시 코드를 신규 개발 프로젝트에 넣고 싶지는 않을 것이다..

나도 어떻게든 이전 레거시 코드를 고쳐보려 노력을 했지만 일정에 맞추기에는 한 없이 부족했다.

( 실력을 키우자고 많은 자극을 받은 계기가 된 거 같다. )

다들 하나씩 포기해 가며 같이 하나의 목표인 빠른 개발만을 위해 움직였다.

 

문제는 그 다음이었던 거 같다.

담당자들이 하나의 일만 맡고 있는 상황이 아니고 다른 일들도 진행해야 하는 상황이라

신경을 못 쓰게 되는 게 있었던 거 같다 나 또한 같은 상황이었다.

그러다 분명 서비스 운영을 위해 앱 말고 다른 것들도 진행을 해야 할거 같은데 너무 조용한 거 같단 생각이 들었다.

 

새로 오신 PM님이 히스토리 파악도 안 되었을 상태였지만,

우리의 목적인 서비스 운영을 위한 최소한의 기능이 어떤 건지를 질문을 드렸을 때,

최소한의 기능이 어떤 것인지에 대해 명확한 기준이 없다는 것을 알았다.

그때부터 모두가 빠르게 움직이기 시작했다.

 

목표인 서비스 운영을 위한 최소한의 기능 개발을 위해 움직이고 있고

덕분에 일정에 영향이 없을 만큼 일이 진행되고 있다.

 

글이 길어졌지만 결론은 아래와 같은 거 같다.

• 프로젝트 목적을 생각하며 움직여야 한다.
• 우리가 지금 무엇이 중요한지 파악해야 한다.
• 개인, 파트도 좋지만 결국 프로젝트 팀이 같은 목표를 바라봐야 한다.
• 목표를 위해서는 포기해야 할 것들이 생긴다.

 

4. 소속감은 중요하다.

 

팀 내의 파트장이란 직급이 없는 체계였을 때는 팀이지만 따로 움직이는 분위기가 있었던 거 같다.

 

파트장이란 직급이 생김과 동시에 일일 스크럼이라는 문화가 생겼다.

일일 스크럼에서는 파트끼리 모여 일정이나 이슈를 서로 공유하는 자리였다.

처음 얘기를 들었을 때는 일도 바쁜데 매일 모여야 한다는 것에 약간의 거부감이 있었다.

 

파트장이 되고 일일 스크럼을 진행하며 거부감이 줄어갔다.

일정, 이슈 공유를 하며 어디가 병목인지를 찾고 다 같이 생각하는 시간이 늘어갔다.

특히 사소한 일상 얘기를 하며 파트끼리 같이 일을 한다는 느낌이 들었다.

 

시간이 지나 파트에 퇴사자분들이 생길 때 질문을 드렸다.

"파트에서 일하면서 어떤 게 좋았던 거 같아요?" 

모두 같은 대답을 해주셨다. 

"소속감이 생긴 거 같아 좋았어요!"

 

나도 적응을 못했을 때 불안함 때문에 가끔 판단이 흐려지고, 제대로 된 역량을 보여주지 못하는 상황이 있었던 거 같다.

( 신입이라 더 그랬던 거 같은.. )

적응을 하고 나서야 나의 의견을 말할 줄 알게 되었고, 실수를 줄일 수 있게 되었다.

 

소속감은 어느 집단이서든 개개인의 불안 요소를 줄이는 것에 도움이 된다고 생각한다.

이것이 적응하는 시간을 줄여주는 좋은 방법인 거 같다.

 

일일 스크럼을 진행하면서 많은 장점이 있었지만,

제일 좋은 장점은 소속감을 만들어 준다 인거 같았다.

 

다만, 너무 친해지는 것은 어느 정도 경계가 필요하다고는 생각한다.

감정 상할 일 없이 서로 건강한 피드백을 주고받을 수 있다면 괜찮지만 어려울 수 있다.

 

+++  항해 플러스  +++

 

나는 항해 99 부트캠프를 수료했었다.

그래서 그런지 매번 항해에서 새로운 걸 시작할 때마다 문자가 온다.

 

항해 플러스 1기가 시작할 때부터 문자가 왔다.

신입 개발자라면 발걸음을 멈춰 볼만한 매력적인 말이 있었다.

 

"주니어 개발자 물경력 탈출 코스"

( 얼마나 자극적이고 끌리는 말인가.. )

 

하지만 당장은 불가능했다. 작은 기능 개발 하나도 나에게는 벅찬 업무들이었었다.

2기도 그냥 그렇게 지나쳐 가고 3기를 모집한다는 문자가 왔었다.

 

그때 실무를 하며 실력을 키워야겠다는 계기가 된 일이 있었다.

공부를 열심히 해보자 하려고 생각을 했을 때,

퇴근해서 일하고 쉬고 하면서 개인 공부하는 습관이란 게 깔끔하게 없어진 상황이었던 거 같다.

공부도 하고 습관도 다시 만들고자 마감 3일 전 다시 10주간 항해를 떠나기로 했다.

 

 

1. 공부하는 습관

 

항해하는 10주 동안 그냥 일-과제-일-과제였다.

난이도가 높은 과제가 나왔을 때는 일주일에 3일은 거의 밤을 새야 했다.

 

일이 많은 상황이 생겼을 때는 "이번 과제는 놓아줄게"라는 말을 많이 했다.

( 하라고 옆에서 소리 쳐주신 동료분들 감사합니다 ㅎ_ㅎ )

근데 자는 시간 줄이고 핸드폰 사용 시간 줄여가며 시간을 더 쓰면 되더라..

 

일 바쁜데 언제 공부해.. 어제 일 많이 했으니 쉬어야지.. 하면서 보냈던 하루하루들이 많았던 거 같다.

그러면서 뒤쳐지기는 싫어했다는 게 참 부끄러운 걱정을 하고 있었다는 걸 새삼 다시 느껴졌었다.

걱정하는 시간에 하면 되는 거다...

 

10주 동안 매일 일-과제를 하다 보면 정말 퇴근하고 노트북을 켜는 게 습관이 된 거 같다.

항해를 하며 가장 값진 성과라고 생각한다.

이제 이걸 꾸준히 해야 더욱더 값진 성과들이 나올 것이다.

항상 잊지 말고 걱정하는 시간에 하자..

 

 

2. 공부하는 방법

 

돌아보면 "뭘 공부해야 하지?"가 많았다.

사실 공부할 건 너무 많지만 "뭐부터 시작해야 하지?"가 더 맞는 말 같다.

항해를 하면서 고개를 살짝 돌려 질문 하나만 던져도 시작할 수 있었다는 걸 깨달았다.

단순히 안 한 것뿐이었다는 걸을 알게 되었다.

 

프레임워크 없이 SPA를 만드는 과제를 진행했었다.

바닐라 자바스크립트만 사용하여 개발을 진행해야 했고, 자연스럽게 컴포넌트를 함수로 작성하기 시작했다.

 

하지만 함수형 컴포넌트를 사용하는 과정은 쉽지 않았다. 특히 이벤트 바인딩과 리렌더링 같은 작업에서 막히며,

"왜 바닐라 자바스크립트로 함수형 컴포넌트를 구현하기 어려울까?" 질문이 생겼다.

 

함수는 한 번 리턴되면 종료되기 때문에 호출 이후 상태를 유지하거나 추가 작업을 수행하기 어렵다.

내가 작성한 함수형 컴포넌트는 DOM 요소를 return 했지만,

버튼과 같은 요소에 이벤트를 바인딩하려면 setTimeout이나 requestAnimationFrame 같은 트릭을 사용해야 했다.

 

이때 리액트의 함수형 컴포넌트도 비슷한 어려움이 있었을 텐데,

"어떻게 이 문제를 해결했을까?" 궁금증이 생겼었다.

 

마침 다음 과제가 리액트 랜더링 과정을 간략하게 구현을 해보는 과제였고,

과제를 진행하며 공부를 했었다.

 

리액트에서 클릭 이벤트를 추가하려면 아래처럼 작성했을 것이다.

<button onClick={handleClick}>클릭</button>

 

리액트는 내부적으로 React.createElement를 호출하여 JSX를 ReactElement 객체로 변환한다.

(이 과정을 Render단계라고 한다.)

 

이 객체는 다음과 같은 구조를 가진다. 

{
	type:'button',
	props:{
		onClick: handleClick, 
		children:'클릭'
	}
}

 

이후 리액트는 변환된 ReactElement들(Virtual DOM)을 기존 Virtual DOM과 비교(Diffing)하며 변경점을 계산한다.

(이 과정을 Reconcile단계라고 한다.)

 

변경 사항은 실제 DOM에 반영되며, 이때 이벤트 핸들러와 같은 props는 Synthetic Event System을 통해 효율적으로 관리된다.

(이 과정을 Commit단계라고 한다.)

 

Synthetic Event System은 DOM의 최상위 노드(root element)에 이벤트 리스너를 단 한 번만 등록하고,
하위 요소들의 이벤트를 위임(Delegation) 방식으로 효율적으로 처리한다.
이는 메모리 사용을 줄이고 성능을 최적화하는 장점이 있다.

 

리액트는 Fiber Architecture 기반의 추상화된 랜더링 방식으로 개발자가 쉽게 사용할 수 있도록 한다.

또 랜더링을 작은 단위로 나누어 스케줄링하고 우선순위를 정하는 등 불필요한 랜더링을 방지하고 성능을 최적화해준다.

 

함수형 컴포넌트도 위와 같은 방식을 통해 이벤트 바인딩을 쉽게 해결할 수 있고,

상태 관리(useState), 사이드이펙트(useEffect) 처리하기 위해 Hooks가 도입된 것을 자연스럽게 알 수 있었다.

 

공부는 거창한 계획이 아니라 작은 호기심에서 시작되는 거 같다.

"왜 함수형 컴포넌트가 어려웠을까?"

"리액트는 어떻게 해결했을까?"
"왜 리액트는 함수형 컴포넌트를 권장하게 되었을까?"

(내용이 길어져 따로 글을 작성해 보겠습니다..)

공부를 어떻게 시작해볼까 가 아니라 "왜?"라는 질문을 던져보자.

 

 

3. 인정받아 보기

 

항해 10주간, 생각보다 좋은 피드백을 많이 받았다.

항상 "내가 잘하고 있는 걸까?"라는 의문을 품고 있었지만,

이번 경험을 통해 "부족하지만 못하고 있는 건 아니다"라는 자신감을 조금 얻었다.

 

테스트 코드 주차를 진행하며 코치님께 질문을 드렸었다.

"가치 있는 테스트가 무엇일지가 궁금합니다."

 

코치님께서 해주신 한 문장이 깊게 와닿았다.(F입니다.)

"평소에 개발에 얼마나 진지한 태도로 접근하고 계시는지 바로 와닿습니다."

이 말을 듣고 "내가 개발을 대하는 태도가 이상하지는 않구나"라는 안도감과 함께 자신감이 생겼다.

 

피드백을 받으며 또 중요하게 생각한 건 모든 기술에서는 어느 정도 나만의 생각이 포함되어야 한다.

그래야 서로 의견을 나눌 때 더 좋은 대화와 결과를 만들어낼 수 있는 거 같다.

(다시 한번 열정적으로 리뷰를 해주신 성호 코치님께 감사드립니다!)

 

10주가 끝난 후, 동료분이 "많은 것을 배웠다"라고 말씀해 주셨는데, 처음에는 "나한테 배울 게 있을까?" 싶었다.
하지만 회고와 편지를 보고, 내가 가지고 있는 생각과 태도를 좋게 봐주셨다는 걸 느끼게 되었다.

 

다 적지는 못했지만 많은 분들께서 좋은 말씀을 해주셨고 다들 너무 감사했다.

덕분에 조금은 성장했다는 걸 느꼈고 약간의 자신감이 생겼던 거 같다.

 

그리고 시간을 갈아가며 과제를 했던 게 좋은 성과로 돌아왔다.

 

 

이번 경험을 통해 나의 불안함과 의심을 돌아보게 되었다.
항상 "내가 잘하고 있는 걸까?", "지금 내 생각이 맞는 걸까?"라는 질문을 반복했지만,
너무 많은 의심은 자신감을 떨어뜨리기도 하는 거 같다.

 

스스로 의심하고 더 나은 방향을 고민하는 건 분명 좋은 태도다.
하지만 자신만의 생각을 가지고 확신을 가질 때, 자신감이 생긴다.

그 자신감이 단순한 고집이 아니라면, 성장에 도움이 될 것이라 생각하게 되었다.

 

 

마지막으로 돌아보면..

올해는 참 많은 걸 생각해 보고 경험해보고 좋은 사람들도 많이 만난 거 같다.

내가 쓴 걸 올려다보면 무슨 현자처럼 써버린 거 같아 부끄럽기도 하지만 중요한 것들이라고 생각한다.

 

올해는 앞으로 내가 어떻게 해야 할지에 대한 생각 정리였다면

내년에는 생각들을 행동으로 옮기는 걸 목표로 해보자!!

(알고리즘 공부도 꼭 하자...)