Rocky 's Blog

회고를 시작하며

이번 주는 어떻게 보냈는가?

화요일과 목요일에 팀원들과 대면으로 진행했다. 작업을 리스트업하고 배분하는 데 걸리는 시간이 크게 단축되었고, 완료된 작업을 공유하고 즉시 다음 작업으로 넘어가는 흐름이 매끄러웠다.

특히, 고민되는 부분이 있을 때 바로 논의하며 방향성을 잡을 수 있었던 점이 좋았다. 비대면에서는 화면 공유로 전달할 수 있는 내용에 한계가 있었지만, 대면에서는 여러 노트북을 함께 살펴보고 각자 찾아본 내용을 편리하게 공유할 수 있었다.

이번 주에 가장 신경 쓴 부분은?

CS 지식의 부족함을 많이 느꼈다. 지난 주말 동안 학습하면서 느낀 점은, 분명 배운 내용임에도 명확하게 기억나지 않는다는 것이었다. 이번 주에 논의된 CS 개념 역시 전공 수업에서 배웠던 것들이었다. 어떤 과목에서 언제 배웠는지는 기억나지만, 구체적인 내용은 가물가물했다.

그래서 정리가 필요하다고 판단했다. 하루 작업을 마친 후, 관련 강의 자료를 찾아보며 개념을 정리했다. 이번 미션에 필요한 핵심 내용이었기에, 정리한 내용을 팀에 공유하면 분명 도움이 될 거라 생각했다. 화이트보드에 개념을 적어두고 말로 설명할 수 있도록 반복해서 연습했다. 이 개념을 우리 프로젝트에 어떻게 녹여낼 수 있을까? 를 계속 고민했고, 이번 주말에는 이를 토대로 설계를 진행해보고자 한다.

목표 설정

이번주의 목표는 무엇이었는가?

목표가 실제로 잘 이루졌는가?

이번 주와 다음 주에 진행해야 하는 작업 리스트를 정리했을 때 양이 상당했다. 과연 2주 안에 가능할까? 라는 의구심이 들었지만, 팀원들과 함께 우선순위를 정하고 체계적으로 접근했다. 작업을 하나씩 선별하고 효과적으로 분배한 덕분에 이번 주 목표의 상당 부분을 달성할 수 있었다.

기존 테스트 커버리지가 매우 낮은 상태였다. 리팩토링 전에 각 기능의 동작 방식과 요청-응답 흐름을 확인하기 위해 테스트를 작성했다. 통합 테스트를 처음 다루며 헷갈리는 부분도 있었지만, 팀원들과 고민을 공유하며 의견을 나누고 해결해 나갔다. 그 결과 브로드캐스팅 기능을 제외한 모든 기능에 대해 테스트를 완료할 수 있었다.

다만 CS 개념을 실제 동작 원리에 맞게 설계하는 부분은 아직 진행 중이다.

목표가 잘 이루어진 이유가 무엇일까?

우선순위 설정이 가장 큰 역할을 했다. 이번 미션에서 어떤 부분에 집중해야 할지 회의를 통해 정했다. 자잘한 내용까지 모두 챙기기에는 시간이 아깝다고 판단했다. 팀원들의 역량이라면 충분히 구현 가능하겠지만, 단순 코드 수정뿐만 아니라 PR 작성, 리뷰, 승인받기까지의 시간적 비용을 고려했다. 따라서 우선순위가 낮은 작업은 과감히 제외하고, 우리가 경험하면 좋을 핵심 내용 위주로 집중했다.

대면 작업의 효과도 컸다. 중간중간 작업 우선순위를 함께 점검하고 다음 작업을 확인하는 과정이 반복되면서, 중요한 작업들을 빠르게 처리할 수 있었다. 막히는 부분이 있으면 바로 옆 사람에게 물어보고 해결할 수 있었던 점도 큰 도움이 되었다.

더 나아가서

현재 그룹 프로젝트 4주 차까지 진행하면서 다양한 팀과 이야기를 나누며 깨달은 점이 있다. 우리 팀이 순조롭게 진행될 수 있었던 이유 중 상당 부분은 팀원들의 작업 스타일과 생각이 비슷했기 때문이라는 것이다.

예를 들어, 우리는 회의를 자주 하고 작업 단위를 세밀하게 나누자는 의견이 일치했기에 병합 시 충돌이 적었다. 만약 하루에 PR 병합을 딱 한 번만 진행하는 팀이었다면 어떻게 행동했을까? 우선순위 설정 시에도 이견이 적었고, 있더라도 회의를 통해 최적의 방법을 찾아 모두가 동의하며 진행했다. 만약 의견이 쉽게 통일되지 않는 상황이라면 어떻게 대처해야 할까?

좋은 팀 환경에서 경험하고 있기에, 정작 의견 충돌이 발생했을 때 어떻게 대응해야 하는지에 대해서는 깊이 고민해보지 못한 것 같다. 다음 주가 끝나면 이번 프로젝트의 전체 과정을 돌이켜보고, 만약 그렇지 않았다면? 이라는 가정 상황들에 대한 대처 방안을 생각해보면 좋겠다.

CS 개념을 적용해보자

CS 개념을 적용하는 과정에서 목표는 무엇인가?

학습한 CS 개념을 프로젝트에 실제로 적용해보자.

목표가 실제로 잘 이루졌는가?

팀원들과 설계까지는 진행하지 못했지만, 우리 프로젝트에 도입 시 어떤 부분에 어디까지 적용할 수 있을지 고민해보았다. 다음 주에는 함께 설계를 진행하고, 시간 여유가 된다면 구현까지 해볼 계획이다.

목표가 잘 이루어지지 않은 이유가 무엇일까?

하나의 개념을 도입하려 했는데, 그에 따라 연쇄적으로 적용해야 할 개념들이 많았다. 이 모든 내용을 현재 프로젝트 상태에 도입하기는 쉽지 않았다. 설계를 진행하려면 전체 프로젝트 구조를 분석하고 도입하려는 개념에 적합하게 재설계해야 했는데, 그 규모가 예상보다 훨씬 컸다.

주말 동안 개념을 더 깊이 공부하고, 다음 주에는 팀원들과 함께 실제 동작 방식에 맞게 설계해보기로 했다. 구현까지 완료할 수 있을지는 미지수다. 어디까지 개념을 도입할 것인지에 따라 작업 규모가 달라질 것이고, 변경해야 할 범위도 크게 달라질 것이다. 그렇기에 개인적으로 먼저 설계안을 만들어보고, 이를 바탕으로 팀 전체의 의견을 종합해보려 한다.

더 나아가서

CS 개념을 알고 있는가? 그것이 도움이 되는가? 라는 질문을 받는다면 단연코 그렇다 고 답할 것이다. CS 지식의 범위를 어디까지 잡느냐에 따라 달라지겠지만, 그 개념들이 실제 문제 해결에 도움이 될 때가 분명히 있다.

예를 들어, 이전에 소켓을 처리하는 과정에서 네트워크 개념을 많이 떠올리며 작업했다. ACK를 받는 과정과 ACK이 손실되는 경우를 염두에 두고 재전송 로직을 설계했던 경험이 있다. 만약 네트워크 기초 개념을 몰랐다면, 단순히 전송에 실패했네? 로 끝났을 것이다. 하지만 동작 원리를 알고 있었기에 어느 단계에서 실패했는지, 어떻게 복구해야 하는지 를 더 고민해볼 수 있었다.

지금도 확실하지는 않지만, 이런 개념이 있었던 것 같은데? 라는 희미한 기억만으로도 관련 내용을 빠르게 찾아보고 바로 적용할 수 있었다. 만약 개념을 더 확실하게 알고 있다면, 이를 훨씬 더 효과적으로 활용할 수 있을 것이다. 따라서 시간을 들여 제대로 정리하고 이해하는 것이 중요하다고 생각한다.

우리는 지금 리팩토링을 하고 있는 것일까?

리팩토링 과정에서 목표는 무엇인가?

리팩토링이 필요한 부분을 찾아내고 근거를 바탕으로 개선하자.

목표가 실제로 잘 이루었는가?

목요일까지는 원하는 내용을 모두 달성했다고 생각했다. 프론트엔드에서는 상태 관리 스토어와 데이터 패칭 로직을 분리하고 React 컴파일러를 도입하여 성능을 개선했다. 백엔드에서는 통합 테스트를 진행했고, 응답 형식을 통일하는 작업을 마쳤다.

모두가 처음 시도하는 작업이었음에도 결과는 나름 만족스러웠다. 하지만 개인적으로 다시 돌아보게 된 계기가 있었다. 다른 팀과의 데모 시간에 리팩토링의 정의에 관한 이야기가 나왔는데, 그때 문득 의문이 들었다.

리팩토링이란 외부 동작이나 기능을 변경하지 않으면서 내부 코드 구조를 개선하는 과정 을 의미한다. 그렇다면 우리가 한 작업은 정말 리팩토링이었을까? 자잘한 UX 개선 사항도 리팩토링에 속하는가? React 컴파일러 도입은? 상태 관리와 데이터 패칭 분리는?

목표가 잘 이루어지지 않은 이유는 무엇인가?

리팩토링의 정의를 명확히 하지 않았기 때문이다. 팀원들과 함께 리팩토링이 무엇인지 를 먼저 정의한 후 진행했어야 했다.

돌이켜보면 우리는 리팩토링뿐 아니라, 개선 의 관점에서 더 적극적으로 접근했다. 사실 어느 쪽이든 문제는 없다고 생각한다. 개선이 필요한 부분들은 분명 고쳐야 했으니까. 다만 지금 하고 있는 것이 엄밀히 리팩토링인지 개선인지를 명확하게 인식하지 못했던 점이 아쉽다.

예를 들어, 상태 관리와 데이터 패칭 분리는 명확히 리팩토링이다. 외부 동작은 동일하고 내부 구조만 개선했으니까. 하지만 UX 개선은 사용자가 느끼는 동작 자체가 변하므로 리팩토링이 아니라 기능 개선에 가깝다. 이런 구분을 하지 않고 모든 작업을 리팩토링 이라는 하나의 이름으로 묶어버렸던 것이다.

더 나아가서

용어가 나올 때마다 한 번씩 짚고 넘어가는 습관이 필요하다. 특정 용어를 별 생각 없이 넘어가곤 하는데, 막상 그 용어를 설명해보라고 하면 명확하게 설명하지 못한다. 추상적으로만 이해하고 넘어가기 때문이다. 마치 영어 문장을 읽을 때 모르는 단어가 나와도 문맥으로 추측하며 넘어가는 것처럼 말이다.

더 나은 코드를 위하여

좋은 코드를 위한 목표는 무엇인가?

모든 팀원의 승인이 있어야만 병합할 수 있도록 PR 규칙을 설정했다. 개선할 수 있는 부분은 코멘트로 남기고, 더 나은 코드를 만들기 위해 노력한다.

목표가 실제로 잘 이루졌는가?

잘 이루어졌다. 모두가 PR을 꼼꼼하게 확인했고, 개선할 부분은 항상 논의했다. PR 단위가 작아 코드를 읽기 편했고, 특히 이번 주는 대면으로 진행했기에 더 많은 의견을 나누고 개선할 수 있었다.

구체적으로는 API 인스턴스를 생성하는 과정에서 이런 방식은 어떨까요? 라는 제안이 오갔다. 이를 통해, 제네릭을 활용해 타입 중복을 줄이고, 함수 단위로 분리하여 테스트 용이성을 확보했다. 모르는 부분은 질문하며 이해하고, 더 나은 방식이 있다고 생각하면 추천하고 논의하며 개선 방안을 찾아갔다.

목표가 잘 이루어진 이유가 무엇인가?

이 부분은 팀의 큰 장점이라고 생각한다. PR을 세심하게 읽고 개선 가능한 부분은 공유하는 분위기가 형성되어 있다. 그 과정에서 내 방식이 항상 맞아 라기보다는 이런 방식은 어떨까요? 와 같이 의견을 존중하는 분위기라서 더 편하게 이야기하고 더 많은 이야기가 오갈 수 있었다고 생각한다.

더 나아가서

다른 사람의 코드를 읽는 것은 결코 쉬운 일이 아니다. 절대 그들의 방식이 잘못되었기 때문이 아니라, 사람마다 스타일과 접근 방식이 다르기에 낯설게 느껴지는 것이다. 나와 다른 방식일 때는 어떤 이유에서 이런 방식을 선택했을까? 라는 질문을 던지며 작성자의 의도를 파악하려 노력했다.

분명 우리 팀의 코드를 다른 누군가가 본다면 똑같이 느낄 것이다. 그렇다면 이런 간극을 줄이고 내 코드를 더 잘 전달하기 위해 무엇을 할 수 있을까 고민했다. 결국 문서화가 핵심이라고 생각한다.

1. 팀의 공통 원칙을 문서로 명확히 작성하자.

팀 내에서 공통적으로 따르는 원칙을 명확히 기록하고 이를 일관되게 적용하면 좋겠다. 예를 들어, 서로 다른 관심사를 가질 때는 분리하는 것을 적극 지향한다 와 같은 원칙을 문서에 기록하고, 실제로도 분리 가능한 부분들을 체계적으로 분리한다면 코드 가독성과 이해도가 높아질 것이다.

누군가 우리 코드를 볼 때 "왜 이렇게 잘게 쪼개놨지?"라고 의아해할 수 있다. 하지만 문서에 우리는 관심사 분리를 중요하게 생각합니다 라고 명시되어 있다면, 그 사람은 아, 이 팀의 철학이구나 라고 바로 이해할 수 있을 것이다.

2. 주요 의사결정의 배경을 기록하자.

왜 이 라이브러리를 선택했는가, 왜 이런 구조로 설계했는가 와 같은 맥락을 ADR 형식으로 남기는 것도 좋을 것 같다. 코드를 처음 접하는 사람도 Zustand를 선택한 이유는 X, Y, Z 때문이었구나 라고 빠르게 이해할 수 있을 것이다.

다음 주에 시도해볼 내용

이번 주를 정리해보자면?

프로젝트 구조를 파악하고 개선점을 반영했다. 테스트 커버리지를 높이고 내부 자잘한 구조적 문제들을 해결했으며, 다음 주 작업 목록까지 정리해두고 마무리하였다. 이제 다음 주에는 마지막까지 열심히 달려가면 될 것 같다.

다음 주를 위해서 준비한 내용이 있어?

주말 동안 학습한 CS 개념을 바탕으로 실제 동작 원리에 맞는 설계안을 만들어볼 계획이다. 모듈 구조를 재설계 해야하는 부분이 많기에 처음 마주하면 꽤 시간이 걸리는 작업이라 생각한다. 그래서 먼저 한번 시도해보고, 그 과정에서 마주한 문제들과 고민들을 정리해두려 한다. 다음 주 월요일에 팀원들과 함께 개선해나간다면 더 빠르게 좋은 결과물을 만들 수 있지 않을까 싶다.

배포 과정을 완벽하게 이해하고 싶다. 이번 배포 과정은 기존에 비해 훨씬 복잡했다. 관련 개념을 알고 있다면 비교적 쉽게 이해할 수 있겠지만, 나에게는 처음 접하는 내용이라 아직 제대로 이해하지 못했다. 주말 동안 전체 흐름을 살펴보고 어떤 방식으로 진행되는지 도식화하며 체계적으로 이해해보려 한다. 각 단계에서 어떤 일이 일어나는지, 왜 이런 구조가 필요한지를 명확히 파악하고 싶다. 이것도 정리해서 팀에 공유하면 좋을 것 같다.

다음 주에 새롭게 시도해 볼 내용이 있어?

벌써 그룹 스프린트의 마지막 주차다. 이번 팀원들은 모두 프론트엔드를 지향해왔지만, 이번 그룹 스프린트 기간 동안 프론트엔드/백엔드 구분 없이 모두 경험했다. 이 과정 속에서 느끼고 배운 점에 관하여 이야기 나눠보면 좋을 것 같다.

프론트엔드 관련해서는

백엔드 관련해서는

이 프로젝트를 정리하는 회고 시간을 평소보다 조금 더 길게 가져보면 어떨까 싶다. 단순히 이번 주 어땠어요? 가 아닌 4주간의 전체 과정을 돌이켜본다면, 모두에게 의미 있는 마무리가 될 것 같다.

회고를 마치며

그룹 스프린트를 정리하는 시간을 가지자

그룹 활동을 하면서 많이 배웠고, 다음 주까지도 배울 점이 많을 것이다. 한 주 단위를 넘어 하나의 완성된 프로젝트로 바라보고, 이를 체계적으로 정리하는 시간을 가져야겠다. 어떤 점을 배웠고 어떤 노력을 했는지, 어떤 부분이 여전히 부족한지 종합적으로 정리해보면 좋겠다.

더 잘할 수 있는 부분

다음 주가 지나면 벌써 마지막 그룹 프로젝트에 들어간다. 그룹 프로젝트를 위한 준비가 필요할 것이다. 지금까지 해온 것들과 마지막으로 시도해 보고 싶은 것들을 적절히 조합해 후회 없이 마무리하고자 한다.

이처럼 나만의 명확한 목표를 정하고, 이를 이루기 위해 무엇을 어떻게 해야 할지 차분히 고민해 보려 한다.