[네이버부스트캠프 웹･모바일 10기] 멤버십 14주차 회고

들어가며

이번 주는 화요일과 목요일에 팀원들과 대면으로 모였다. 작업을 리스트업하고 배분하는 시간이 크게 줄었고, 완료한 작업을 공유하고 바로 다음 작업으로 넘어가는 흐름도 매끄러웠다. 비대면에서는 화면 공유로 전달할 수 있는 내용에 한계가 있었지만, 대면에서는 고민되는 부분을 그 자리에서 논의하며 여러 노트북을 함께 살펴볼 수 있었다.

가장 신경 쓰인 것은 CS 지식의 부족함이었다. 이번 주에 논의된 개념은 모두 전공 수업에서 배운 것들이었는데, 어떤 과목에서 언제 배웠는지는 기억나도 구체적인 내용은 가물가물했다. 그래서 하루 작업을 마칠 때마다 강의 자료를 찾아 개념을 정리했고, 팀에 공유할 수 있도록 화이트보드에 적어두고 말로 설명하는 연습을 반복했다. 이 개념을 우리 프로젝트에 어떻게 녹여낼 수 있을까?라는 질문은 이번 주 내내 이어졌다.

우선순위를 좁혀 핵심에 집중하다

이번 주 목표는 세 가지였다. CS 개념을 적용해 실제 동작 원리와 비슷하게 설계하기, 테스트 커버리지를 효율성을 체감할 만큼 높이기, 리팩토링 목표에 맞춰 MoSCoW 방법으로 우선순위를 매기고 작업을 분배하기였다. 2주 동안 해야 할 작업 리스트는 과연 가능할까? 싶을 만큼 많았지만, 우선순위를 정해 하나씩 선별하고 분배한 덕분에 상당 부분을 달성할 수 있었다.

기존 테스트 커버리지는 매우 낮았다. 리팩토링 전에 각 기능의 동작 방식과 요청-응답 흐름을 확인하려고 테스트부터 작성했다. 통합 테스트는 처음이라 헷갈리는 부분도 있었지만, 팀원들과 고민을 나누며 풀어갔고 브로드캐스팅을 제외한 모든 기능의 테스트를 마쳤다. CS 개념을 동작 원리에 맞게 설계하는 일은 아직 진행 중이다.

목표를 이룬 데는 우선순위 설정이 가장 큰 역할을 했다. 팀원들의 역량이라면 자잘한 작업까지 모두 구현할 수 있었겠지만, 코드 수정뿐 아니라 PR 작성, 리뷰, 승인까지의 시간 비용을 고려하면 아까웠다. 그래서 우선순위가 낮은 작업은 과감히 빼고 우리가 경험하면 좋을 핵심 위주로 집중했다. 대면 작업도 힘을 보탰다. 중간중간 우선순위를 함께 점검하고, 막히면 바로 옆 사람에게 물어 해결했다.

다른 팀들과 이야기를 나누며 깨달은 점도 있다. 우리 팀이 순조로웠던 데는 팀원들의 작업 스타일과 생각이 비슷했던 덕이 컸다. 회의를 자주 하고 작업 단위를 잘게 나누자는 데 의견이 맞았기에 병합 충돌이 적었고, 우선순위를 정할 때도 이견이 적었다. 하루에 PR을 한 번만 병합하는 팀이었다면, 의견이 쉽게 통일되지 않는 상황이었다면 어떻게 대처했을까. 좋은 환경에 있다 보니 정작 의견 충돌에 대응하는 법은 깊이 고민해보지 못했다. 프로젝트가 끝나면 만약 그렇지 않았다면?이라는 가정에 대한 대처 방안도 생각해보려 한다.

흐릿한 CS 개념도 문제 해결의 실마리가 된다

학습한 CS 개념을 프로젝트에 실제로 적용하는 것이 목표였지만, 팀원들과 설계까지는 가지 못했다. 하나의 개념을 도입하려 하니 연쇄적으로 적용해야 할 개념이 많았기 때문이다. 전체 프로젝트 구조를 분석하고 도입하려는 개념에 맞게 재설계해야 했는데, 그 규모가 예상보다 훨씬 컸다. 어디까지 도입하느냐에 따라 작업 규모와 변경 범위가 크게 달라지기에, 주말 동안 개념을 더 공부하고 개인 설계안을 먼저 만든 뒤 다음 주에 팀의 의견을 모아보기로 했다.

그럼에도 CS 개념이 도움이 되는가?라고 묻는다면 단연코 그렇다고 답할 것이다. 이전에 소켓을 다루면서 ACK를 받는 과정과 ACK가 손실되는 경우를 염두에 두고 재전송 로직을 설계한 적이 있다. 네트워크 기초를 몰랐다면 전송에 실패했네?로 끝났겠지만, 동작 원리를 알았기에 어느 단계에서 실패했는지, 어떻게 복구해야 하는지까지 고민할 수 있었다.

지금도 확실히 아는 것은 아니지만, 이런 개념이 있었던 것 같은데?라는 희미한 기억만으로도 관련 내용을 빠르게 찾아 적용할 수 있었다. 개념을 더 확실히 안다면 훨씬 효과적으로 활용할 수 있을 것이다. 시간을 들여 제대로 정리하고 이해하는 것이 중요하다고 느낀 이유다.

정의 없이 모든 작업을 리팩토링이라 불러오다

리팩토링이 필요한 부분을 찾아 근거를 바탕으로 개선하는 것이 이번 주 목표였다. 프론트엔드에서는 상태 관리 스토어와 데이터 패칭 로직을 분리하고 React 컴파일러를 도입해 성능을 개선했고, 백엔드에서는 통합 테스트를 진행하고 응답 형식을 통일했다. 목요일까지는 목표를 모두 달성했다고 생각했다.

그런데 다른 팀과의 데모 시간에 리팩토링의 정의에 관한 이야기가 나오면서 우리가 한 작업을 다시 돌아보게 됐다. 리팩토링은 외부 동작이나 기능을 바꾸지 않으면서 내부 코드 구조를 개선하는 과정이다. 그렇다면 자잘한 UX 개선도 리팩토링일까? React 컴파일러 도입은? 상태 관리와 데이터 패칭 분리는?

상태 관리와 데이터 패칭 분리는 외부 동작은 그대로 두고 내부 구조만 바꿨으니 명확히 리팩토링이다. 반면 UX 개선은 사용자가 느끼는 동작 자체가 변하므로 기능 개선에 가깝다. 우리는 이런 구분 없이 모든 작업을 리팩토링이라는 하나의 이름으로 묶어버렸다. 개선이 필요한 부분은 어차피 고쳐야 했으니 어느 쪽이든 문제는 없다. 다만 팀원들과 리팩토링이 무엇인지를 먼저 정의하지 않아, 지금 하는 일이 리팩토링인지 개선인지 인식하지 못한 점이 아쉽다.

돌이켜보면 특정 용어를 별생각 없이 넘기는 일이 잦았다. 막상 설명해보라고 하면 명확히 설명하지 못하는데, 영어 문장 속 모르는 단어를 문맥으로 추측하고 넘어가듯 추상적으로만 이해했기 때문이다. 용어가 나올 때마다 한 번씩 짚고 넘어가는 습관이 필요하다.

낯선 코드를 읽고, 내 코드를 전달하는 법

모든 팀원이 승인해야 병합할 수 있도록 PR 규칙을 정했고, 개선할 부분은 코멘트로 남기며 더 나은 코드를 만드는 것이 목표였다. 목표는 잘 이뤄졌다. PR 단위가 작아 읽기 편했고, 대면으로 모인 덕에 더 많은 의견이 오갔다. API 인스턴스를 생성하는 코드에서는 이런 방식은 어떨까요?라는 제안을 계기로 제네릭으로 타입 중복을 줄이고, 함수 단위로 분리해 테스트 용이성을 확보했다.

이렇게 이야기가 활발했던 것은 팀의 분위기 덕분이다. PR을 세심하게 읽고 개선점을 공유하되, 내 방식이 맞아가 아니라 이런 방식은 어떨까요?처럼 서로의 의견을 존중했기에 더 편하게 말할 수 있었다.

그래도 다른 사람의 코드를 읽는 일은 결코 쉽지 않다. 그 방식이 틀려서가 아니라, 사람마다 스타일과 접근 방식이 달라 낯설게 느껴지기 때문이다. 나와 다른 방식을 만나면 어떤 이유로 이 방식을 선택했을까?를 물으며 작성자의 의도를 파악하려 했다. 우리 팀의 코드를 다른 누군가가 본다면 똑같이 느낄 것이다. 그 간극을 줄이려면 결국 문서화가 핵심이라고 생각한다.

먼저 팀이 공통으로 따르는 원칙을 문서로 명확히 남기고 일관되게 적용하고 싶다. 누군가 우리 코드를 보고 "왜 이렇게 잘게 쪼개놨지?"라고 의아해하더라도, 문서에 우리는 관심사 분리를 중요하게 생각합니다라고 적혀 있다면 이 팀의 철학이구나라고 바로 이해할 수 있다. 여기에 왜 이 라이브러리를 선택했는가, 왜 이런 구조로 설계했는가 같은 의사결정의 배경을 ADR 형식으로 기록하면, 코드를 처음 보는 사람도 Zustand를 선택한 이유가 이것이었구나라고 빠르게 파악할 수 있을 것이다.

다음 주에는 설계안과 배포 흐름을 정리한다

이번 주에는 프로젝트 구조를 파악해 개선점을 반영하고, 테스트 커버리지를 높이고, 내부의 자잘한 구조 문제를 해결했다. 다음 주 작업 목록까지 정리해두었으니 이제 마지막까지 달려가면 된다.

주말 동안에는 학습한 CS 개념을 바탕으로 실제 동작 원리에 맞는 설계안을 만들어볼 계획이다. 모듈 구조를 재설계할 부분이 많아 처음 마주하면 꽤 시간이 걸릴 작업이기에, 먼저 시도해보며 마주한 문제와 고민을 정리해두려 한다. 월요일에 팀원들과 함께 다듬는다면 더 빠르게 좋은 결과물을 만들 수 있을 것이다. 배포 과정도 제대로 이해하고 싶다. 이번 배포는 기존보다 훨씬 복잡했고 처음 접하는 내용이라 아직 이해가 부족하다. 전체 흐름을 도식화하며 각 단계에서 어떤 일이 일어나는지, 왜 이런 구조가 필요한지 파악하고, 이것도 정리해 팀에 공유하려 한다.

벌써 그룹 스프린트의 마지막 주다. 팀원 모두 프론트엔드를 지향해왔지만 이번 스프린트에서는 프론트엔드와 백엔드를 가리지 않고 경험했다. 프론트엔드에서는 새로 알게 된 점과 서로 다른 스타일을 접하며 느낀 점, 협업하기 좋았던 패턴을, 백엔드에서는 직접 코드를 작성하며 느낀 어려움과 다른 팀의 설계를 보며 느낀 점, 앞으로 집중하고 싶은 부분을 이야기해보려 한다. 단순히 이번 주 어땠어요?가 아니라 4주간의 전체 과정을 돌아보는 회고를 평소보다 길게 가진다면, 모두에게 의미 있는 마무리가 될 것 같다.

정리하며

그룹 활동에서 많이 배웠고, 다음 주까지도 배울 점이 많을 것이다. 한 주 단위를 넘어 하나의 완성된 프로젝트로 바라보며, 무엇을 배웠고 어떤 노력을 했는지, 무엇이 여전히 부족한지 종합적으로 정리하려 한다. 다음 주가 지나면 벌써 마지막 그룹 프로젝트가 시작된다. 지금까지 해온 것과 마지막으로 시도해보고 싶은 것을 잘 조합해, 최종적으로 무엇을 얻고 싶은지, 끝까지 지키고 싶은 목표는 무엇인지 나만의 기준을 세워보려 한다. 어떤 모습으로 부스트캠프를 마무리할지 차분히 고민하고, 후회 없이 마무리하고 싶다.