Rocky 's Blog

회고를 시작하며

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

최종 발표를 앞둔 이번 주는 그야말로 정신없이 지나갔다. 주말 내내 진행했던 리팩토링을 월요일까지 마무리하고, 여러 시나리오로 테스트를 반복하면서 드러나는 오류들을 하나씩 잡아 나갔다. 테스트를 돌릴 때마다 예상하지 못했던 엣지 케이스가 계속 튀어나와서, “이 정도면 충분하겠지”라는 생각을 감히 하기 어려울 정도였다.

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

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

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

그래서 이 서비스가 왜 필요한지, 기존 강의 환경에서 어떤 불편함을 해소하는지, 그리고 다른 서비스와 비교했을 때 어떤 차별점이 있는지를 청중이 자연스럽게 느낄 수 있도록 구성하고자 했다.

지난 주 회고의 피드백

팀 회고에 대한 피드백 반영

어떤 점을 계속 이어나갔는가?

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

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

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

어떤 점을 개선했는가?

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

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

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

구조에 대한 고민

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

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

말로 뱉어보는 연습

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

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

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

최종 발표를 어떻게 진행했는가?

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

발표가 끝난 뒤에는 곧바로 AI 요약 기능을 실행해 두고, 요약이 생성되는 동안 QnA를 받는 방식으로 시간을 설계했다. 덕분에 QnA가 활발하게 이어지는 동안 요약이 완료되어, 대화가 마무리될 즈음 자동으로 생성된 요약본을 함께 확인하는 꽤 만족스러운 타이밍을 만들 수 있었다.

어떤 피드백을 받았는가

감사하게도 많은 분들이 적극적으로 의견을 남겨 주어서, 이후 개선 방향을 잡는 데 큰 도움이 되었다. 전반적인 완성도와 안정성에 대해 좋은 평가를 해 주신 분들이 많아서 놀라면서도, 동시에 그동안의 노력이 인정받은 듯해 꽤 뿌듯했다. 동시에 추가되면 좋을 기능, 사용성 측면에서 아쉬웠던 부분처럼 구체적인 피드백도 다양하게 받아서, 다음 단계에서 어떤 기능을 우선순위에 둘지 더 또렷하게 정리할 수 있었다.

어떤 긍정적인 피드백을 받았는가?

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

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

제스처 인식과 강의 몰입도 관련 기능에 대한 반응도 인상적이었다. 실제 발표에서는 캠퍼들이 제스처를 적극적으로 사용해 주면서 분위기도 훨씬 가벼우면서도 집중도는 더 높아지는 효과가 있었다.

어떤 점이 부족했는가?

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

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

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

이번 프로젝트에서 가장 좋았던 부분은?

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

이번 프로젝트에서 아쉬운 부분은?

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

또 하나의 아쉬움은 테스트 코드에 대한 고민이 충분하지 못했다는 점이다. 변화하는 요구사항과 리팩토링에 맞춰 테스트 코드를 자주 고치다 보니, 어느 순간 이게 정말 우리가 믿을 수 있는 테스트인가?라는 의문이 들었다. 테스트의 핵심은 구현이 아니라 변하지 않는 기대 행동을 검증하는 것인데, 구현 변경에 따라 테스트가 자꾸 같이 흔들리는 상황은 올바른 방향이 아니라는 생각이 들었다. 테스트 코드에서 무엇을 검증해야 하는지, 어떤 수준까지 보장해야 하는지가 더 중요하다는 점을 생각해보고 적용해보고자 한다.

앞으로의 계획은 어떻게 되는가?

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

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

회고를 마무리하며

길고긴 시간이 끝이 났다.

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

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

부스트캠프도 끝이 났다.

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

이제는 매주 미션이 나오거나, 일정에 맞춰 끌어 주는 사람이 없다. 그만큼 앞으로의 시간은 혼자 이겨내야 하는 구간이 될 텐데, 부스트캠프 생활을 떠올리며 이 악물고 달려 보고자 한다.

22주간의 회고

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