Rocky 's Blog

회고를 시작하며

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

이번 주에는 오픈 스테이지에 도전하며 다른 캠퍼들로부터 다양한 피드백을 받았다. 피드백을 통해 내가 미처 보지 못했던 불편한 흐름이나 애매한 기능들이 보였고, 그 과정에서 부족한 점을 개선하며 새로운 기능도 여러 개 추가할 수 있었다. 초반에는 남은 작업량이 많아 일정 안에 끝낼 수 있을지 걱정이 컸지만, 팀원 모두가 각자 맡은 부분을 책임감 있게 밀어준 덕분에 안정적으로 완성할 수 있었다.

한편으로는 체력적으로 슬슬 한계가 보이는 주차이기도 했다. 새벽까지 작업하는 날이 늘어나면서, 다음 날 체크인 시간에 맞춰 겨우 눈을 뜨는 패턴이 반복되었다. 힘들지만 이 프로젝트를 끝까지 잘 마무리하고 싶다는 마음이 있어서, 그 생각 하나로 버티며 최대한 집중력을 유지하려 했다.

이번 주의 작업 방식은?

오픈 스테이지를 준비하면서 사용자가 직접 써보는 상황을 여러 번 시뮬레이션했고, 그 과정에서 예상치 못한 오류나 흐름 상의 끊김을 여러 차례 발견했다. 이를 위해 팀원들과 주기적으로 전체 플로우를 점검하는 테스트를 반복했다.

실제 사용자처럼 시나리오를 따라가 보며, 발견되는 문제는 바로 이슈로 정리해 곧바로 수정하거나 다음 작업 우선순위에 반영했다. 짧은 주기로 테스트하고 바로 수정하는 방식이 개발 속도를 더 끌어올린다는 것을 느낄 수 있었다. 이런 주기적인 테스트 덕분에 마지막 데모 시간에는 눈에 띄는 치명적인 오류 없이 자연스럽게 시연을 마칠 수 있었다.

지난 주 회고의 피드백

팀 회고에 대한 피드백 반영

어떤 점이 특히 개선되었는가?

지난주에는 구현 우선순위가 조금 미흡하다는 피드백이 있었고, 팀 차원의 우선순위가 각 개인의 실제 작업 우선순위까지 충분히 연결되지 못했던 것 같다고 느꼈다. 그래서 이번 주에는 팀의 하루 단위 목표를 정하는 것에 더해, 각자 오늘 어떤 기능을 어디까지 진행할 것인지 계속해서 공유했다. 이를 통해 팀 전체의 방향과 개인의 작업 목록이 자연스럽게 맞춰지는 느낌을 받을 수 있었다.

더 나아가서

단순히 팀 목표에 맞게 진행할 뿐만 아니라, 다른 사람들의 작업 속도나 내용에 따라 유동적으로 우선순위를 제어할 수 도 있었다. 예를 들어, 백엔드에서 특정 기능이 언제쯤 마무리 될지를 예상하고, 그 기간동안 빠르게 작업을 끝낼 수 있는 일을 찾았다. 그 후, 백엔드 작업이 완성되면 이를 프론트엔드에서 연결시키는 방식으로 빠르게 작업을 이어갈 수 있었다.

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

개발자라면 서비스 완성이 먼저다.

이 주제에 대해서 팀원들과 꽤 진지하게 논의한 시간이 있었다. 오픈 스테이지가 끝난 뒤 실제 개발에 온전히 집중할 수 있었던 시간은 화요일 오후부터 목요일 밤까지였다. 이번 주까지가 기능 완성의 데드라인, 남은 한 주는 리팩토링과 개선에 집중하는 기간으로 잡혀 있었다. 한정된 시간 안에 무엇을 우선할 것인가가 중요했다.

개발 완성 vs 리팩토링

그때 우리에게 남아 있던 작업은 발표 자료 업로드 및 다운로드, 채팅, 참여도 점수 반영, AI 요약, 자잘한 오류 수정 등 필수 기능들이었다. 팀 안에서는 지금 구조를 정리하고 품질을 더 다듬을 것인가, 아니면 기능을 먼저 다 채우고 나중에 손볼 것인가를 두고 의견이 갈렸다.

다른 팀원들의 의견은, “지금 상태의 완성도가 생각보다 높지는 않다. 애매하게 이어나가기보다는 조금 더 보강한 뒤에 나아가야하지 않을까? 에 가까웠다. 내가 제안한 방향은 기능 개발을 가능한 한 이번 주 안에 끝까지 밀어붙이고, 이후 남은 기간 동안 리팩토링과 구조 개선을 집중해서 가져가자는 것이었다. 이렇게 생각한 이유는 다음과 같았다.

팀원들의 실력을 믿고 있었기에 이번에는 내 의견을 평소보다 조금 더 강하게 밀어붙이기도 했다. 여러 논의를 거친 끝에 팀은 “우선 기능 완성”을 기준으로 방향을 정하기로 했다.

실제로는 어떻게 진행되었는가?

논의를 했던 화요일 오후부터 다음날 스크럼까지 기능 개발 속도가 눈에 띄게 빨라졌고, PR이 쌓일 정도로 모두가 집중해서 구현을 이어갔다. 목표로 생각했던 대부분의 기능들이 그날 실제로 완료되었고, 결과적으로 AI 기능을 제외한 모든 주요 기능과 리팩토링을 이번 주 안에 마무리할 수 있었다. 덕분에 다음 주에는 AI 기능 추가와 리팩토링에 집중할 수 있게 되었고, 전체적으로 더 완성도 높은 서비스와 안정적인 데모로 이어질 수 있었다.

오류가 발생했을 때 가설을 세운다.

테스트를 반복하면서 크고 작은 오류들이 계속 보였고, 이를 해결하기 위해 의식적으로 코드 한 줄보다 문제가 발생하는 상황 에 먼저 집중하려고 했다. 어떤 조건에서 문제가 생기는지, 어느 시점에서 화면이 깨지는지 등을 바탕으로 가설을 세우고 검증하는 방식을 여러 번 시도했다. 이 과정이 시간이 조금 더 걸리는 것처럼 느껴질 때도 있었지만, 근본 원인을 파악하는 데에는 훨씬 도움이 되었다.

조금 더 상황을 설명해보자면

예를 들어, 참여자의 비디오가 검은 화면으로만 보이는 문제가 있었다. 분명 다른 참여자의 카메라 수신 요청 자체는 정상적으로 이루어지고 있었기에, 서버와의 통신이나 요청 단계에서의 문제가 아니라고 판단했다. 대신 비디오가 실제로 재생 가능한 상태가 되기도 전에 재생을 시도하면서, 화면만 먼저 렌더링되어 검은 화면이 뜨는 것이라고 가설을 세웠다.

이에 따라 클라이언트 단에서 비디오가 재생 가능한 시점을 감지하고, 그 전까지는 로딩 스피너를 보여주다가 준비가 되었을 때 비디오를 재생하도록 흐름을 바꾸었다. 이렇게 바꾸고 나니 사용자 입장에서는 “멈춘 화면”이 아니라 “준비 중인 화면”으로 자연스럽게 받아들일 수 있었다.

항상 가설이 맞아 떨어지지는 않는다.

가설이 맞았던 경우도 있지만, 완전히 틀렸던 경우도 많았다. 예를 들어, 사용자가 브라우저의 다른 탭을 보고 있을 때 비디오가 멈추는 현상을 해결해 보려했다. 처음에는 “다른 탭으로 전환되는 이벤트를 감지해서 다시 재생시키면 되겠지”라고 생각했다.

하지만 실제 문제의 핵심은 브라우저가 백그라운드 탭의 리소스를 자동으로 제한하는 점이었다. 이 때문에 단순히 탭 전환 이벤트만 감지해서는 해결되지 않았고, 브라우저의 절전, 스로틀링 특성을 고려한 다른 접근이 필요하다는 것을 알게 되었다. 이 문제는 아직 완전히 해결되지 않았고, 주말 동안 관련 정책과 예외 조건을 더 조사하면서 새로운 가설을 세워 개선해 보려 한다.

오픈 스테이지에 초대합니다.

어떻게 진행했는가

이전에 예고했던 대로 오픈 스테이지를 진행했다. 내가 제안해서 시작된 자리이기도 해서 발표 자료 준비부터 실제 발표까지 준비하고자 했다. 날이 다가올수록 많은 사람들 앞에서 발표한다는 사실에 긴장도 많이 되었다. 개발이 한창 바쁜 시기였음에도 57명 정도의 캠퍼들이 참여해 주었고, 목표로 잡았던 50명을 넘길 수 있어서 그 점은 다행이었다.

발표는 기획을 가볍게 소개하는 방식으로 시작했다. 우리가 이 서비스를 만들게 된 배경, 해결하고자 했던 문제, 기존 서비스와의 차별점 등을 핵심만 뽑아서 설명했다. 이후에는 바로 시연으로 넘어가, 실제로 캠퍼들이 직접 방에 접속해 카메라를 켜고 화면 공유를 해 보면서 여러 기능을 함께 테스트하는 흐름으로 진행했다.

→ Plum 오픈스테이지 발표자료

테스트 목표

지난주 회고 시간에 오픈 스테이지에서 달성하고 싶은 테스트 목표를 미리 정리해 두었다. 당시 세웠던 목표는 다음과 같았다.

실제로 잘 이루어졌는가?

이 기준들을 세울 때는 나름 수치도 있고, 성공/실패를 분명하게 나눌 수 있어서 꽤 탄탄하다고 생각했었다. 하지만 실제로 테스트를 해 보니, 생각보다 허점이 많았다는 것을 금방 깨달았다. 예를 들어 “95% 이상이 5초 내 접속”이라는 기준은, 모든 사용자가 동시에 링크를 클릭하고 바로 접속을 시도한다는 전제를 깔고 있었다. 현실에서는 누군가는 늦게 접속하는 상황들도 있을텐데, 이런 실제 맥락을 목표에 반영하지 못한 것이다.

지금 돌아보면 목표 설정 자체의 방향을 잘못 잡았다는 생각이 든다. 어떤 상황을 가정하고, 어떤 조건 안에서 측정할지, 그 데이터를 어떻게 모을지에 대한 고민이 부족했다. 피드백을 모으기 위해 구글 폼을 만들고 실시간으로 응답을 받기는 했지만, 정작 중요한 사용 행동과 맥락을 충분히 수집하지 못한 점이 많이 아쉬웠다

자신감이 바닥을 찍다.

전체적으로만 보면 나름 나쁘지 않았다고도 생각이 들었다. 많은 인원이 한 번에 들어왔음에도 서버가 버텨 주었고, 기본적인 흐름이 돌아간다는 점에서는 어느 정도 가능성을 확인했다. 다만, 세부적으로 들어가면 개선해야 할 문제들이 정말 많이 보였다. 특히 화상 연결과 관련된 부분을 내가 전담하다 보니, 화면에서 바로 드러나는 대부분의 문제들이 곧 내 작업과 직결되어 있다는 느낌이 강했다.

캠퍼들이 남겨 준 피드백과 직접 다시 돌려 본 화면을 보면서, 한두 가지 이슈를 발견하기 시작하니 그동안 눈에 들어오지 않았던 허점들이 연달아 보이기 시작했다. 그냥 조금 아쉽다 수준이 아니라, 내가 너무 많은 부분을 대충 넘긴 것은 아닌가 싶은 순간도 있었다.

인프라, 서버, 다른 프론트 영역 모두 각자 자리에서 잘 버텨 주었는데, 괜히 내가 팀원들의 발목 잡은 건 아닌가 하는 생각에 자신감이 꽤 많이 떨어졌다. 결국 내 파트가 무너지면 다른 사람들이 만들어 온 기능과 구조를 제대로 보여줄 수 없기 때문이다.

그래도 어쩌겠는가 이어가야한다.

그렇다고 해서 계속 자책만 할 수는 없었다. 감정적인 부분은 잠시 뒤로 밀어두고, 지금 당장 손대야 할 문제부터 하나씩 정리하기로 했다. 일단 오픈 스테이지에서 반복적으로 언급되거나, 실제 사용성에 크게 영향을 주는 이슈들을 가장 높은 우선순위로 올렸다. 피드백을 쭉 읽어보며 특히 많이 거론된 항목들을 중심으로 “무조건 고쳐야 하는 것”과 “추후 개선해도 되는 것”을 구분했다.

화상 강의 서비스 특성상 카메라 화면에 대한 요구와 불편함이 가장 많았다. 그래서 “사용자가 언제, 어떤 상황에서 불편함을 느끼는가”를 기준으로 기능과 인터랙션을 다시 살펴보았다. 예를 들어, 카메라가 켜지는 시점, 비디오가 준비되기 전의 화면, 네트워크가 살짝 불안정할 때의 처리 등 세세한 부분을 하나씩 손봤다. 동시에 예외 처리가 허술했던 부분들을 점검하며 오류 상황에서 어떤 메시지를 보여줄지, 어느 수준까지 자동 복구를 시도할지를 고민했고, 이 과정에서 전체적인 에러 처리 흐름과 구조를 조금 더 단단하게 만들고자 했다.

어떻게 바뀌었는가

오픈 스테이지 이후 다음 데모까지는 실제로 이틀 반 정도밖에 시간이 없었다. 그 짧은 시간 동안 팀원들이 적극적으로 붙어 주어, 눈에 띄는 에러들은 대부분 정리하고 몇몇 기능은 추가 개선까지 이어갈 수 있었다. 서로가 맡은 영역을 명확히 나누되, 공통으로 필요한 부분은 짧게 논의하고 바로 작업에 들어가면서 속도를 최대한 끌어올렸다.

완벽하다고 말할 수는 없지만, 최소한 이전보다 훨씬 덜 어색하고 끊김이 적은 흐름이 만들어졌다고 느꼈다. 실제 데모 시연에서도 10명 정도의 캠퍼들과 함께 다시 테스트를 진행했는데, 훨씬 안정적이라는 반응을 들을 수 있었다.

테스트의 중요성

이번 경험을 통해 사용성 테스트가 얼마나 영향력있는지 느꼈다. 실제 사용자들이 들어와 직접 써 보는 과정을 눈앞에서 지켜보면서, 우리가 아무렇지 않게 넘겼던 부분들이 다른 사람에게는 충분히 불편하고 낯설게 느껴질 수 있다는 것을 느꼈다. 기능이 동작하는지만 보는 것이 아니라, 사용자가 그 기능을 “어떻게 경험하는지”를 확인하는 과정이 필수라는 것을 깨달았다.

특히 좋았던 점은, 테스트 → 문제 정리 → 개선 → 다시 테스트라는 사이클이 생각보다 강력했다는 것이다. 해야 할 일과 목표가 테스트를 통해 매우 구체적으로 드러나니, 무엇부터 손대야 하는지 헤매지 않고 빠르게 작업에 들어갈 수 있었다. 이런 사이클을 프로젝트 전반에 계속 적용한다면, 단순히 버그를 줄이는 수준을 넘어서 개발 속도와 서비스 품질을 동시에 끌어올릴 수 있을 것이라 느꼈다.

말로 내뱉어 보자

말을 조리있게 하는 연습이 필요하다.

오픈스테이지를 통해 가장 크게 느낀 점은, 발표 자체보다 질의응답 시간에 질문에 제대로 답변하지 못했다는 점이다. 내가 알고 있는 내용인데도, 질문을 받는 순간 말이 꼬이고 핵심이 전달되지 않았다. 특히 그날 아침에 팀원들과 이야기 나누며 정리했던 내용까지도 막상 질문을 받고 나니 흐릿하게 떠오르면서, 머릿속 생각과 입 밖으로 나오지 않았다.

어떻게 개선할 생각인가?

이전 몇 주 동안은 혼자서도 설명을 소리 내어 뱉어 보며 연습을 했었는데, 프로젝트가 바빠지면서 조금씩 느슨해진 것 같다. 단순히 내용을 아는 것에 그치지 않고, 핵심은 무엇인지 생각해보고 이를 소리내어 뱉어보는 연습을 반복해보려 한다.

진짜 문제는 내가 이해하고 있는 내용을 상대 입장에서 구조화해서 설명하지 못하는 부분이다. 이를 위해 복잡한 생각은 글로 먼저 정리하고, 문장은 최대한 짧고 간결하게 쪼개어 말하는 연습을 해보려 한다. 주어진 상황과 문제에 맞추어 내가 어떤 방법을 시도했고 그에 따른 결과를 논리적으로 말할 수 있도록 해보고자 한다. 개발자는 단순히 코드로 작성하는 것이 끝이 아니라는 생각이 들었다.

구조에 대한 고민

어떤 구조가 적절할까

구조에 대한 고민은 매번 프로젝트를 할 때마다 반복되는 이슈였다. 설계가 뒷받침이 되지 못하다보니 구조가 엉망이고 부족한 부분이 많았다. 이번에도 비슷한 패턴을 겪었지만, 그만큼 “다음 번에는 같은 실수를 줄이고 싶다”는 마음이 더 강해졌다. 이번 경험을 토대로 다음 프로젝트에서는 초반부터 구조를 더 의식적으로 설계해 보고 싶다는 생각이 들었다.

다른 팀원이 이해할 수 있을까?

몇 번 구조를 바꾸어 보면서 가장 먼저 든 생각은, “이건 나만 이해할 수 있는 구조가 아닌가?” 하는 의문이었다. 예를 들어, 처음에는 하나의 역할이라고 생각하며 관련된 여러 기능들을 한 파일 안에 몰아넣은 적이 있었다. 나는 계속 코드를 만지다 보니 “이 기능은 여기 있을 거야”라고 자연스럽게 추론할 수 있었지만, 과연 다른 팀원이 봐도 같은 방식으로 예상할 수 있을까 하는 걱정이 들었다.

결국 한 파일이나 한 모듈이 맡는 역할을 더 분명히 나누고, 개발자가 코드를 열었을 때 “이 정도 위치와 책임은 예측 가능하다”라고 느낄 수 있는 선까지만 책임을 부여하고자 했다. 예전에 시니어 피드백 시간에 “다른 사람이 코드를 예측 가능하게 만드는 것이 좋은 구조”라는 이야기를 들었던 기억을 떠올리며, 나 혼자 편한 구조가 아니라 팀이 함께 이해할 수 있는 구조를 목표로 다시 리팩토링을 진행하고 있다.

스스로의 기준이 있다면?

스스로에게 이거 굳이 이렇게까지 나눈 이유가 뭐지? 라는 질문을 계속 던졌다. 설계를 해 두고 나서는, 예전에 피드백을 주셨던 시니어 분의 목소리를 떠올리며 왜 이렇게 했는지, 이 선택의 장점은 무엇인지 를 질문 형태로 스스로에게 던져 보았다. 그때 명확하게 대답하지 못하거나, 스스로 납득이 가지 않는다면 주저하지 않고 다시 지우고 처음부터 다시 설계했다.

적어도 설명 가능한 구조를 만들자는 기준을 세우고자 했다. 단순히 폴더를 잘게 쪼개거나 파일을 늘리는 것이 아니라, 각 조각이 어떤 이유로 존재하는지 스스로 납득할 수 있어야 한다는 점을 계속 상기했다.

앞으로의 방향성

경험이 더 많앗더라면, 쓸 수 있는 패턴과 예시가 더 쌓여 있었더라면, 이번 구조도 훨씬 빠르고 체계적으로 잡아갈 수 있었을 것 같다. 이런 점에서 왜 다른 사람들의 코드를 보고, 다양한 설계 방식을 접하고, 검증된 패턴을 공부하는 일이 중요한지 느꼈다. 지금 내가 만든 구조는 어디까지나 많이 어설픈 초안에 불과하다는 생각도 든다.

구조는 하나의 정답이 아닌, 프로젝트의 성격과 서비스의 요구사항에 맞게 계속 조정되어야 한다고 생각한다. 그래서 일정 수준의 지식과 실제 서비스에 대한 이해, 그리고 적절한 타협이 합쳐져야 비로소 튼튼한 구조가 된다고 생각한다.

이번 프로젝트가 끝난 뒤에는, 내가 어떤 생각으로 어떤 구조를 시도했는지, 어떤 부분에서 단점이 드러나 실패했는지를 꼭 정리해 보려 한다. 언젠가 비슷한 고민을 할 때 조금 더 단단한 기준을 가지고 선택할 수 있기를 바라면서 말이다.

회고를 마무리하며

거의 반죽음

얼마 안남았다는 생각 때문인지, 마음은 계속 앞으로 달려가는데 몸이 따라오지 못하는 느낌이다. 해내야 한다. 다른 팀원들이 그동안 쌓아 온 작업들을 제대로 보여주고 싶은데, 그러기 위해서는 내가 맡은 부분을 끝까지 책임지고 잘 마무리해야 한다. 가끔은 집에 방음벽을 설치해 두고, 소리라도 지르고 나오고 싶다는 생각이 들 정도로 마음에 여유가 없다. 그래도 아직 시간이 남아 있는 만큼, 남은 기간 동안 할 수 있는 최선을 끝까지 다 쏟아붓고 싶다.

소소하지 않은 회식

부스트캠프가 끝난 뒤, 여운이 남아 있을 때 캠퍼들과 한 번 제대로 얼굴을 보고 인사 나누고 싶다는 마음이 있었다. 처음에는 정말 소소하게, 지금 팀원들과 이전 팀 팀원 정도만 여쭤보고 10명 안팎으로 모이면 좋겠다고 생각했다. 그런데 인원을 모으다 보니 어느새 10명을 훌쩍 넘어서 20명 정도까지 늘어났다.

이왕 이렇게 된 김에 예전에 스쳐 지나갔던 캠퍼분들께도 한 번씩 연락을 드려 보기로 했다. 늘 이름이나 캠 화면에서 보면 반가웠지만 정작 인사를 나눌 기회는 많지 않았고, 기억에 남는 순간들을 웃으면서 함께 이야기해 보고 싶었다.

그렇게 한 명, 두 명씩 연락을 드리다 보니 결국 50명 넘는 인원이 모이게 되었다. 지방에서 올라오신다는 분들을 보고는 놀랍기도 하고, 동시에 감사하기도 했다. 다들 정말 치열하게 달려온 시간들이었기에, 이 자리만큼은 시간이나 작업 걱정없이 편하게 웃고 떠들며 즐기고 갔으면 좋겠다.