우당탕탕 개발자 두 번째 회고

설렘만 가득하던 2025년 새해는 짧은 기간에 절망으로 바뀌었고, 억울함에 가득 차 취업준비에 다시 돌입했다.

당시에는 개발자가 될 수 있을까라는 두려움만 가득했다.

요구사항을 구현해나가고 어떻게 해결해나갈까 하는 개발자의 고민만을 하고 있는 지금은, 정말 모두에게 감사함을 표현할 따름이다.

다시 시작

2025년 1월에 직무전환으로 들어간 첫 회사에서는 어렵게 잡은 동아줄을 놓치지 않으려고 부단히 노력했다.

채용되어서도 윗선을 설득해서 나를 합격시켜주었다는 말에는 잘해야 한다는 결의와 부담감이 가득했다.
그렇게 부담감과 두려움을 해소하고자 달마다 회고글도 썼다.

• 개발자 한 달 회고 - 입사부터 글또 반상회까지
• 두 달, 그 언저리 개발자 회고

분에 넘치는 칭찬을 받았고, 인생에서 맛보지 못했던 좌절감도 얻었던 짧은 2개월이었다.
짧지만 다른 회사의 프로세스와 개발환경, 다양한 사람들을 만나볼 수 있어서 값진 경험이기도 했다.

나를 절망에 빠뜨렸지만, 그만큼 희망을 주었다고도 할 수 있다.

새로운 시작

운이 좋게도, 짧은 공백기에 바로 일을 할 수 있게 되었다.

다시 개발을 할 수 있다는 것과 함께, 주변의 두 명의 친구가 사용하는 서비스에 합류해서 개발한다는 것에 감사함을 느꼈다.

일 한 내용

입사하고 나서는 바로 신규 서비스 개발에 투입되었다.

아주 짧은 온보딩이 있었던 터라, 기존 서비스에 신규 서비스를 추가하는 업무에는 무리가 없었던 것 같다.
그만큼 재미있기도 했다.일정에 급급해서 급하게 구현에 집중하게 되었지만, 나름의 고민은 담겨 있었다.
그 중에 기억에 남는 것이 리스트 페이지를 만드는 작업과 디자인 시스템인 것 같다.

리스트

클로즈 베타를 위해서 진행된 신규 프로젝트였기에 데이터의 개수가 어떻게 될지 모르는 상황이었다.

그에 더불어 아래의 요구사항이 함께 있었다.일단, 유닛과 챕터가 있다.
하나의 유닛에는 여러 챕터가 존재하며, 해당 챕터를 클릭하면 사용자가 그 챕터를 수강할 수 있는 공간으로 이동할 수 있다.

개발해야 하는 것은 유닛 리스트를 보여주는 수업 페이지이다.

• 처음 수업페이지 접근 시,
  • 사용자가 수강해야 하는 챕터로 스크롤을 이동시켜야 한다.
  • 유닛은 아코디언 형식이며, 사용자가 현재 수강하거나 수강해야 할 유닛은 기본적으로 아코디언을 오픈한다.
  • 아코디언의 내용으로 보여줄 챕터 리스트는 챕터 리스트 API를 호출하여 받아온다.
• 위아래로 스크롤되며 강의아이템을 보여준다.

매끄러운 아코디언 사용을 위해, 아코디언을 펼치기 전에 챕터 정보를 프리페칭하기로 했다.

강의 유닛 리스트에 들어갈 데이터가 몇 개가 될지 문의해도 알 수 없는 상황에서 스크롤에 의한 유닛 리스트 데이터를 어떻게 만들어야 하는지 고민이었다.

초기 구현 접근

요약된 강의정보를 담은 전체 리스트를 이용하여 가상스크롤을 구현하여 렌더링과 프리페칭 기준을 설정했다.
하지만 요구사항이 변경되면서 스크롤 주체가 바뀌었고, 클로즈 베타 단계에서는 더 단순한 구현이 적합하다고 판단했다. 인터섹션 옵저버를 사용한 프리페칭과 함께 단순 스크롤로 변경했다.

학습 포인트

클로즈 베타 초기 단계에서는 복잡한 최적화보다는 빠른 검증과 피드백 수집이 더 중요하다는 것을 배웠다. 요구사항이 유동적인 상황에서는 유연하게 대응할 수 있는 단순한 구조가 오히려 효율적일 수 있다.

릴리즈 이후 개선 작업에서는 디자인과 데이터 구조가 변경되어 양방향 무한 스크롤로 최적화할 수 있었다.

유닛 리스트 상단	아코디언이 열려있을 때

디자인 시스템

입사 후에 디자인 시스템 컴포넌트를 이렇게 열심히 만들고 있을 줄은 몰랐다.

이슈 발견

디자인 시스템 컴포넌트를 Next.js에서 사용할 때 'use client' 지시어 관련 이슈가 있었다. Next.js 서비스 프로젝트 내부에서 'use client'를 명시한 배럴 파일을 만들어 래핑하고 있었다.

이 방식이 다른 Next.js 프로젝트에서도 반복될 것 같았고, non-interactive 컴포넌트까지 클라이언트 컴포넌트로 사용해야 하는 상황이 비효율적이라고 판단했다.

해결 과정

빌드 설정을 분석한 결과, 하나의 파일로 번들링되면서 모든 컴포넌트가 클라이언트 컴포넌트로만 사용할 수 있게 되어 있었다.

'use client' 지시어를 명시할 클라이언트 컴포넌트와 서버 컴포넌트를 명확하게 빌드하여 가져오도록 설정을 변경하는 방법을 제안했다.

실제로 브랜치를 생성해 설정을 변경하고 빌드 결과물과 함께 해당 내용을 작성하여 팀에 공유했다.

디자인 시스템 빌드 이슈 해결방법 공유 슬랙	노션 정리

• 문제점
  • 현재 설정은 빌드 시에, 'use client' 지시어가 제거되며 한 파일로 빌드된다.
• 해결법
  • 플러그인 preserveDirectives를 사용하여 디자인 시스템을 빌드할 때, 파일에 존재하는 지시어를 유지
  • 컴포넌트 단위로 각각 빌드하여 'use client'가 혼재되지 않도록 함

생각보다 해결 방법은 단순했지만, 문제 제기부터 해결 제안, 설득 및 적용까지의 과정을 경험할 수 있었던 좋은 기회였다.

일지

현재 회사 입사하기 전에 두 달 있던 회사에서는 도메인과 개발환경이 너무 어려웠다.

그래서 매일 일지를 작성하면서 이해한 내용을 정리하고 트래킹 용도로 사용했다.
이번 회사는 할당받는 업무가 더 많기도 한 만큼 일지 작성에 심혈을 기울이지 못했다.

입사 한 달 후부터 하루의 내용을 한 줄로 간략히 쓰는 일지를 쓰고 있다. 원한다면 페이지 내부에 들어가서 자세하게 쓸 수 있게끔 만들어 놨다.
5월 달에는 스크롤과 모달의 뒤로 가기 물리버튼으로 너무 힘들었나 보다.
그런 내용밖에 없다.

7월 달에는 신규 서비스 릴리즈 날이 있었기 때문에 힘들기도 했다.

프로젝트 릴리즈 후

7월 프로젝트 릴리즈 후 팀 회고를 진행했다.
동료들로부터 책임감 있는 작업 태도와 일정 준수에 대해 긍정적인 피드백을 받았다.

이를 바탕으로 팀 소통과 협업을 더 개선하기 위해 데일리 스크럼과 Pn룰을 도입했다.

데일리스크럼

업무 진행 상황에 대한 헬스체크와 프로젝트 이슈 공유를 위한 소통 채널이 필요했다.
웹/앱 프론트 팀 간의 소통 창구를 만들기 위해 데일리 스크럼을 도입했다.
단순히 서로의 이슈를 공유하고 헬스 체크를 하거나, 더 좋은 방법을 이야기해보는 용도로 활용하고 있다.
팀원들의 부담을 최소화하기 위해 간단한 규칙을 만들었다:

• 웹/앱 프론트엔드 팀원 모두 공유할 것이 없다면 해당일의 데일리 스크럼을 진행하지 않을 수 있다.
• 한 명이라도 제안 및 공유할 건이 있다면, 조율하여 데일리 스크럼을 진행한다.

또한 서기가 필요할 때에는 도입을 제안한 내가 직접 작성하고 있다.

pn룰

새로 도입해야 하는 문화는 항상 많은 대화와 설득이 필요하다.
그러면서 현재 우리 상황에 맞는 기준으로 조정해 나가는 시간 또한 필요하다.

코드리뷰 시 명확한 의도 전달과 리소스 절감을 위해 Pn룰을 적용하는 것을 제안했다.

Pn룰 제안	Pn룰 설명 풀리퀘스트 추가

Pn룰 도입 제안을 하게 된 계기를 솔직하게 공유하였고, 그것에 공감해준 팀원들과 함께 PN 기준을 세웠다.
팀원 전부 Pn룰을 처음 사용하기 때문에 선택의 폭을 좁혀 부담감을 줄이고자 P3 방식을 채택했다.
팀원의 건의로 해당 룰에 대한 설명과 예시를 PR 템플릿에 추가하기도 했다.

Pn룰을 도입하고 나서 아직 많은 양의 코드리뷰를 진행하지는 않았기 때문에 이것이 유효한지는 데이터가 부족하긴 하다.
그래도 매 순간 프리픽스를 통해서 리뷰어의 의도와 중요도를 파악할 수 있다는 점에서 리소스가 감소하긴 했다.

데이터가 어느 정도 모이게 되면 우리팀에서의 Pn룰이 유효한가에 대해서 데일리 스크럼 때 이야기해봐야겠다.

마무리

개발자가 될 수 있을까라는 두려움에서 시작해, 이제는 어떻게 더 나은 개발을 할 수 있을까를 고민하는 개발자가 되었다.

짧은 시간이었지만 많은 것을 배웠고, 특히 팀과 함께 성장하는 것의 가치를 깨달았다.
앞으로도 지속적으로 회고하며 더 나은 개발자, 더 나은 동료가 되어가고 싶다.