Loki 's Blog

회고를 시작하며

최종 발표를 앞둔 이번 주는 그야말로 정신없이 지나갔다. 주말 내내 이어온 리팩토링을 월요일까지 마무리하고, 여러 시나리오로 테스트를 반복하며 드러나는 오류들을 하나씩 잡아 나갔다. 테스트를 돌릴 때마다 예상치 못한 엣지 케이스가 계속 튀어나왔고, "이 정도면 충분하겠지"라는 생각은 끝까지 하기 어려웠다.

그래도 오류를 하나 고칠 때마다 서비스가 조금씩 단단해지는 게 느껴졌다. 피로감보다 안정감이 더 컸다. 발표 전날에는 팀원 모두가 모여 발표 자료를 다듬고 시연 흐름을 맞추다 보니, 새벽이 다 되어서야 잠자리에 들 수 있었다.

그룹 프로젝트 마지막 목표는 최종 발표를 단순한 기능 나열이 아닌, 실제 화상 강의 상황에 가까운 데모로 보여주는 것이었다. 우리 팀이 만든 서비스는 화상 강의에 활용되는 도구이기 때문에, 실제 강의와 비슷한 문맥에서 사용되지 않으면 이 서비스의 강점이 제대로 전달되지 않을 것이라 생각했다.

이 서비스가 왜 필요한지, 기존 강의 환경의 어떤 불편함을 해소하는지, 다른 서비스와 무엇이 다른지를 청중이 발표를 따라가는 과정에서 자연스럽게 체감할 수 있도록 구성하고자 했다.

지난 주 회고의 피드백

팀 회고에 대한 피드백 반영

지난주 오픈 스테이지에서는 많은 이슈가 드러났고, 팀원들과 함께 원인을 빠르게 파악해 하나씩 해결해 나갔다. 그 결과 눈에 보이는 오류의 수가 이전보다 확연히 줄었고, 기능 전체의 안정성도 많이 높아졌다. 이슈를 하나씩 빠르게 쳐내며 PR이 연달아 올라오는 모습이 눈에 들어왔다. 괜히 속이 뜨거워지는 느낌이었다.

이번 주에도 매일 Plum에 접속해 실제 사용자처럼 기능을 사용하며 테스트를 이어갔다. 화면 전환, 입장과 퇴장, 네트워크 이슈 등 실제 강의에서 충분히 일어날 법한 상황들을 떠올리며 어떤 문제가 생길 수 있을지 계속해서 고민했다. 발견된 문제들을 그때그때 정리하면서 우선순위를 정해 개선해 나갔다.

이런 식으로 반복해서 서비스에 압력을 가하다 보니, 단순히 오류를 줄인다기보다 실제 사용 시나리오에 더 잘 맞는 형태로 다듬어지고 있다는 느낌을 받을 수 있었다.

프로젝트가 막바지로 갈수록 코드가 점점 지저분해지고 있다는 생각이 강하게 들었다. 특히 내가 맡은 영역을 다른 사람이 수정하거나 읽어야 하는 상황을 떠올리면, "이 코드를 그대로 넘겨도 괜찮을까?"라는 걱정이 늘 따라붙었다. 기능은 돌아가지만, 코드 자체에 대한 확신은 점점 줄어들고 있다는 점이 마음에 계속 걸렸다.

결국 불안을 만드는 코드가 과연 좋은 코드일까? 라는 질문을 스스로에게 던지게 되었고, 이를 계기로 구조를 다시 설계하는 리팩토링에 집중하기로 했다. 컴포넌트와 파일 이름을 역할이 잘 드러나도록 정리하고, 한 함수에 섞여 있던 책임들을 더 작은 단위로 쪼갰다. 덕분에 나중에 이 코드를 보게 될 사람도 전체 흐름과 의도를 훨씬 수월하게 파악할 수 있게 되었다.

개인 회고에 대한 피드백 반영

지난주부터 이어진 구조에 대한 고민을 본격적으로 풀어내기 위해, 이번 주에는 전체 흐름을 다시 그려 보며 코드를 재구성했다. 특히 mediasoup 관련 로직을 다른 비즈니스 로직과 분리하고 싶다는 생각이 강해서, 역할별 책임을 나누고 의존성을 줄이는 방향으로 모듈을 쪼개기 시작했다. "이 부분은 왜 이렇게 엮여 있었는지", "어디까지가 이 모듈의 책임인지"를 생각하며 구조를 차츰 잡아나갔다.

다른 팀원들도 이해할 수 있는 코드를 기준으로 여러 번 구조를 바꾸고 되돌리는 과정을 거쳤다. 이 기준에 맞춰 설계를 다시 다듬다 보니, 다이어그램과 실제 코드 흐름을 나란히 놓고 봤을 때 각 부분이 맡은 책임이 훨씬 명확해진 상태로 정리되었다.

지난주에는 머릿속으로는 이해하고 있지만, 막상 말로 설명하는 순간 말이 꼬이고 흐름이 끊기는 아쉬움이 있었다. 그래서 이번 주에는 일정 단위 작업을 마칠 때마다 지금 무엇을 하고 있는지, 왜 이렇게 하고 있는지를 스스로에게 말로 설명해 보는 연습을 했다. 입 밖으로 꺼내다 보니 근거가 충분하지 않은 결정에서는 다시 한번 더 고민하게 되었다.

어떤 부분은 설명을 하다 보니 스스로도 납득이 되지 않아, 다시 다이어그램과 코드를 들여다보며 책임을 조정해야 했다. 이런 과정을 반복하면서 "이 기능은 왜 여기에 있어야 하는가?", "이 의존성은 정말 필요한가?"를 더 자주, 더 구체적으로 묻게 되었다. 말로 스스로를 설득할 수 있을 때, 비로소 그 코드가 진짜 내 코드가 된다는 걸 느꼈다.

Plum에서 최종 발표를 진행합니다.

최종 발표는 처음부터 끝까지 Plum 안에서 라이브 데모 형식으로 진행했다. 약 30명이 동시에 입장한 상태에서 실제 강의가 시작되고 흐름이 이어지는 것처럼 시나리오를 구성하고, 그 안에 주요 기능들을 하나씩 자연스럽게 녹여 소개했다.

발표가 끝나자마자 AI 요약 기능을 실행해 두고, 요약이 생성되는 동안 QnA를 받는 방식으로 시간을 설계했다. QnA가 활발하게 이어지는 사이 요약이 완료되어, 대화가 마무리될 즈음 요약본을 함께 확인하는 타이밍이 자연스럽게 맞아 떨어졌다.

감사하게도 많은 분들이 적극적으로 의견을 남겨 주었고, 이후 개선 방향을 잡는 데 큰 도움이 되었다. 전반적인 완성도와 안정성에 대해 좋은 평가를 해 주신 분들이 많아 놀라우면서도, 그동안의 노력이 인정받은 듯해 뿌듯했다.

추가되면 좋을 기능, 사용성 측면에서 아쉬웠던 부분처럼 구체적인 피드백도 다양하게 받아서, 다음 단계에서 어떤 기능을 우선순위에 둘지 더 또렷하게 정리할 수 있었다.

무엇보다도 서비스의 완성도가 높고 안정적이라는 반응이 많이 나왔다. 오픈 스테이지 이후 실사용에 가까운 테스트의 중요성을 느끼고 팀원들과 매일 Plum에 접속해 다양한 상황을 점검했던 경험이 발표에서 빛을 발했다고 생각한다. 다른 팀원들도 더 나은 UI/UX를 위해 인터랙션과 화면 흐름을 계속 다듬고, 동시 접속 인원이 많을 때를 가정한 대비를 충분히 해 둔 덕분에 긍정적인 평가로 이어졌다.

강의 요약 기능에 대한 반응도 특히 좋았다. 마스터클래스를 들으면서 "놓치는 내용이 너무 많다", "복습을 더 쉽게 할 수 있으면 좋겠다"라고 느꼈던 경험에서 출발한 기능인데, 그 니즈가 다른 캠퍼들의 경험과도 잘 맞아떨어진 것 같다.

제스처 인식과 강의 몰입도 관련 기능에 대한 반응도 인상적이었다. 캠퍼들이 제스처를 적극적으로 사용해 주면서 분위기가 가벼워지는 동시에 집중도는 오히려 높아지는 효과가 있었다.

발표 중 브라우저 크래시가 발생했다는 피드백도 있었다. Zoom과 Plum을 동시에 실행했을 때 간헐적으로 브라우저가 크래시 나는 문제는 이전부터 인지하고 있었지만, 정확한 원인을 찾지 못해 애매한 상태로 남겨 두고 있었다. 이 문제를 다시 마주한 만큼, 브라우저 리소스 사용량과 메모리, CPU 부하 등을 측정하며 원인을 추적하고 반드시 개선해 나가야겠다.

또한 '참여자 목록 스크롤'처럼 팀 내부에서 논의했지만 성능 이유로 제외했던 기능에 대한 피드백도 있었다. 당시에는 참가자들의 카메라 화면을 소비하는 서버 부하를 낮추기 위해 내렸던 결정이었지만, 실제 사용자 입장에서는 기대했던 편의성이 빠진 선택일 수 있겠다는 걸 느꼈다. 사용자 경험을 해치지 않으면서 성능도 지킬 수 있는 다른 설계 방향이 있는지, 다시 한번 들여다보려 한다.

그룹 프로젝트를 마무리하며

이번 프로젝트에서 가장 좋았던 점은 작업 분배가 유연하게 이루어졌다는 것이다. 각자의 역할과 담당 영역은 분명했지만, 상황에 따라 필요한 일을 먼저 가져가고 서로의 업무를 자연스럽게 돕는 흐름이 형성됐다. 겹치지 않게 분업은 하되 선을 긋지 않았다. 이런 방식이 가능했던 건 팀원 모두가 서비스 전반의 흐름을 이해하고 있었고, 풀스택 과정을 따라가며 관련 지식이 쌓여 있었기 때문이라고 생각한다.

이번 팀은 정말 실력 있는 분들이 모인 팀이었고, 그래서 여기까지 올 수 있었다고 믿는다. 그래서인지 한편으로는 초반에 규칙과 설계를 더 단단히 잡았으면 어땠을까 하는 아쉬움도 남는다. 코드 스타일, 디렉토리 구조, 의사결정 방식 같은 기준을 초기에 조금만 더 구체적으로 정리했다면, 전체적인 코드 품질을 더 끌어올리고 불필요한 시행착오를 줄일 수 있지 않았을까 싶다. 충분히 잘했지만, 더 잘할 수 있었을 것 같다는 욕심이기도 하다.

또 하나의 아쉬움은 테스트 코드에 대한 고민이 충분하지 못했다는 점이다. 요구사항 변화와 리팩토링에 맞춰 테스트 코드를 자주 고치다 보니, 어느 순간 이게 정말 믿을 수 있는 테스트인가? 라는 의문이 들었다.

테스트의 핵심은 구현이 아니라 변하지 않는 기대 행동을 검증하는 것인데, 구현이 바뀔 때마다 테스트가 함께 흔들린다면 그건 테스트가 아니다. 다음에는 '무엇을 검증할 것인가'를 먼저 정하고 테스트를 작성하는 방향으로 접근해 보고자 한다.

프로젝트가 공식적으로는 마무리되었지만, 팀원들과 논의한 끝에 Plum을 조금 더 개선해 보기로 했다. 시간의 제약 때문에 미뤄 두었던 문제들을 다시 꺼내 하나씩 시도해 보고, 기술적으로 어렵다고 느껴졌던 부분들을 중심으로 구조와 성능을 더 깊이 파고들 생각이다.

무엇보다 새로운 기능을 얹기 전에 충분한 리팩토링 기간을 확보하고자 한다. 지금까지의 리팩토링은 일정과 오류 수정에 쫓기며 진행했기 때문이다. 구조, 네이밍, 테스트까지 한 번 더 전반적으로 정리한 뒤, 그 위에 다음 버전의 Plum을 쌓아 올리고자 한다.

회고를 마무리하며

이번 프로젝트가 이전 프로젝트들에 비해 유난히 완성도가 높다고 느껴졌던 이유는, 단순히 기능을 구현했다에서 그치지 않고 테스트와 모니터링까지 시도해 보며 서비스 전체를 더 넓은 관점에서 바라봤기 때문인 것 같다. 화면에 보이는 결과물뿐 아니라, 서비스가 실제로 어떻게 동작하고, 어디서 병목이 생기고, 어떤 상황에서 문제가 터지는지를 직접 확인해 보면서 서비스 단위로 생각하는 경험을 처음으로 제대로 해 본 프로젝트였다.

끝이 났음에도 계속 개선하고 싶은 욕심이 생기고, 다음 계획을 빨리 세우고 싶다는 생각이 드는 건 이번이 처음이었다. 그만큼 기간도 길고 강도도 높았지만, 프로젝트에 대한 애정은 아직 남아있다. 배운 점이 정말 많았지만 아직 정리하지 못한 부분들도 많다. 차분히 하나씩 정리하고 다음 단계로 나아가고자 한다.

끝나지 않을 것만 같던 부스트캠프가 끝이 났다. 시간이 이렇게까지 빠르게 흘러갈 줄은 상상도 못 했고, 막상 수료하고 나니 아직 완전히 준비가 되지 않았다고 느껴진다. 앞으로 어떻게 나아가야 할지 고민도 많지만, 결국 지금까지 쌓아 온 프로젝트와 학습의 기록들을 바탕으로 스스로 방향을 만들어 가야 할 것이다.

이제는 매주 미션이 나오지도, 일정에 맞춰 이끌어 주는 구조도 없다. 앞으로의 시간은 스스로 방향을 잡아가야 하는 구간이다. 부스트캠프에서 지내온 시간을 떠올리며, 그 밀도를 잃지 않고 달려 보려 한다.

멤버십 과정 동안 매주 회고를 빠짐없이 작성해 왔는데, 어느새 22주치 기록이 쌓였다는 사실이 아직도 실감 나지 않는다. 부스트캠프 덕분에 회고의 중요성을 깨닫게 되었고, 매주 이 과정을 이어 올 수 있었다. 회고에 들인 시간은 결코 아깝지 않았고, 내가 어디까지 와 있는지, 무엇을 계속 가져가야 하는지를 확인하는 데 큰 도움이 되었다. 앞으로도 회고의 습관만큼은 꾸준히 이어 가 보려 한다.