레벨3 회고

우테코 레벨 3를 보내고

힘들고 바쁘고 정신없었던 레벨 3가 끝났다. 처음 만난 백엔드 4명과 프론트엔드 4명이 모여 하나의 프로젝트를 진행했던 레벨 3. 오늘은 그 과정에서 내가 느꼈던 점들을 기록으로 남겨보려고 한다. 동시에 성장했다고 생각하는 부분과 개인적으로 아쉬웠던 부분도 함께 정리해보고자 한다.

⭐ 주제 선정

우리 팀은 주제 선정부터 쉽지 않았다.

초기에 내가 제안한 아이디어가 투표를 통해 선정되었는데, 막상 발표를 마친 후 구구 코치님의 "여러분 정말 하고 싶은 주제가 맞는지 다시 생각해 보세요"라는 한마디에 팀 전체가 흔들리기 시작했다.

내 아이디어는 다른 아이디어와 비슷한 득표수로 간신히 선정되었던 터라, 다른 아이디어를 지지했던 팀원들이 다시 자신들의 아이디어를 어필하기 시작했다. 내가 제안했던 것은 모임 기획자의 관점에서 편리하게 모임을 계획할 수 있는 서비스였고, 다른 팀원의 아이디어는 여행에 특화된 동선 최적화 서비스였다.

물론 다른 팀원의 서비스 아이디어도 훌륭했다. 다만 개인적으로는 페인 포인트를 느끼기 어려웠을 뿐이다. 그래서 계속된 토론과 설득을 통해 아이디어를 확정하려고 노력했다.

초반에는 팀이 절반 정도로 나뉘었던 상황이 어느 순간 7대 1 정도로 기울었고, 나 역시 지쳐서 어쩔 수 없이 양보하게 되었다. 대신 한 가지 조건을 제시했다. 여행 동선에 검증 기능이 추가된다면 나에게도 의미 있는 페인 포인트가 될 것 같다고 말했고, 모든 팀원이 동의해서 최종적으로 '동선 최적화 + 검증 기능'이 포함된 서비스로 주제를 결정하게 되었다.

📍 만장일치 룰의 탄생
이 과정에서 우리 팀만의 독특한 문화가 하나 생겼다. 바로 만장일치 룰이었다. (지금은 사라진 룰이지만 말이다.)
투표로 결정하면 소수 의견을 가진 사람들이 나중에 불만을 품을 수 있다는 우려 때문에 만들어진 룰이었다. 이후 모든 중요한 결정은 만장일치로 진행하기로 했다. 돌이켜보면 이 룰이 우리 팀의 소통 방식과 의사결정 과정을 개선하는데 큰 역할을 했던 것 같다.

⭐ 1차 & 2차 데모

시간과의 전쟁

우리 팀은 서비스 주제를 정한 후에도 상당히 오랜 기간 회의를 지속했다. 세부 기획을 위한 회의, 디자인을 위한 회의 등 다양한 논의가 이어졌지만, 좀처럼 의견이 수렴되지 않아 실질적인 구현을 시작할 수 없었다.

결국 회의는 1차 데모 전체 기간과 2차 데모 3일 전까지 계속되었고, 본격적인 개발은 데모 3일 전부터 시작하게 되었다. 그 결과 2차 데모 준비를 위해 프론트엔드 팀은 3번의 밤샘 코딩을 해야 했다. 솔직히 같은 프론트엔드 팀원들이 없었다면 버틸 수 없었을 것이다.

크로스 도메인 커뮤니케이션의 중요성

2차 데모 주간은 나에게 특히 힘들었던 시기였다. 백엔드와의 첫 협업이다 보니 의견 충돌이 발생했고, 서로 어떻게 해결해 나가야 할지 몰라 감정적으로 어려운 순간들이 있었다. 거기에 연일 이어진 밤샘 개발로 컨디션도 좋지 않았다.

가장 큰 문제는 API 설계 과정에서 프론트엔드가 참여하지 못했다는 점이다. 촉박한 일정으로 인해 백엔드와 API 설계를 충분히 논의할 시간이 없었고, 결과적으로 백엔드 중심의 API 설계가 이루어졌다.

특히 기억에 남는 것은 동선 관리 API였다. 동선 추가, 삭제, 순서 수정을 하나의 PATCH API로 통합한 설계였는데, 이로 인해 장소 목록에서 동선에 장소를 추가할 때 기존 동선의 순서 정보가 필요했다. 결과적으로 서로 독립적이어야 할 컴포넌트들이 서로의 상태를 알아야 하는 복잡한 구조가 되어버렸다.

소통에서 배운 것들

이 문제를 해결하기 위해 백엔드에게 건의했지만, 당시 서로의 커뮤니케이션이 미숙해 각자의 입장만 주장하고 상대방의 관점을 이해하려는 시도가 부족했다.

해결책을 찾기 위해 코치님들과 1on1 면담을 진행했고, 여기서 중요한 깨달음을 얻었다. 프론트엔드의 입장을 백엔드에게 이해시키려면, 먼저 백엔드의 입장을 이해하려는 노력이 필요하다는 것이었다. 분명 백엔드도 그렇게 API를 설계한 나름의 이유가 있었을 텐데, 나는 그들의 관점을 들어보려 하지 않고 우리 입장만 이해해주길 기대했던 것 같다.

이후 다시 대화를 시도하려 했지만, 다음날 백엔드에서 별도의 삭제/등록 API를 만들어주겠다고 제안해와서 새로운 소통 방식을 실험해볼 기회는 놓치게 되었다.

디자인 시스템 구축의 즐거움

한편으로는 정말 즐거웠던 경험도 있었다. 처음으로 디자인 작업에 직접 참여하면서 Figma를 본격적으로 사용해본 것이다.

색상을 변수로 관리하는 방법, 디자인 시스템을 Figma에 구축하여 활용하는 방법, 컴포넌트 단위로 디자인해서 재활용하는 방법 등을 익히는 과정이 정말 흥미로웠다. 이 과정을 통해 내가 왜 프론트엔드 개발자가 되기로 결심했는지(화면을 그리는 재미, 사용자와 직접 소통하는 느낌) 다시 한번 확인할 수 있었다.

핵심 기능 미완성의 아쉬움

2차 데모까지의 가장 큰 사건은 핵심 기능을 구현하지 못한 채로 데모를 진행한 것이었다. 기획서에서 검증 기능을 핵심 기능으로 제시했음에도 불구하고, 정작 해당 기능은 구현하지 못했다.

물리적인 시간 부족도 원인이었지만, 돌이켜보면 목 데이터를 활용해서라도 기능의 동작을 보여줬어야 했다. 이는 데모가 끝나고 코치님들의 피드백을 통해 깨달은 부분이다.

공통 컴포넌트 개발

프론트엔드 팀은 이 시기에 공통 컴포넌트 라이브러리를 개발했다. 프로젝트 전반에서 재사용할 수 있는 컴포넌트를 미리 구축하자는 목적으로 Text, Flex, Card, Input, Modal 등의 컴포넌트를 만들었다.

하지만 프로젝트를 진행하면서 급하게 설계한 공통 컴포넌트는 오히려 개발 효율을 떨어뜨릴 수 있다는 것을 체감했다. 시간에 쫓겨 설계하다 보니 실제 사용 시 필요한 기능이 빠져있거나, 사용하기 불편한 부분들이 있었다.

대표적인 예로 Flex 컴포넌트에서 너비와 높이를 숫자 타입으로만 받도록 설계해서, "100%"와 같은 상대적 크기 옵션을 사용할 수 없는 문제가 있었다. 이런 경험을 통해 컴포넌트 설계에는 충분한 사전 기획과 다양한 사용 사례에 대한 고려가 필수적임을 깨달았다.

⭐ 3차 & 4차(런칭) 데모

지도 시각화

우리는 동선 시각화와 검증 서비스를 기획했지만, 2차 데모까지는 지도 없이 개발을 진행했다. 검증 기능을 더 핵심으로 여겼기 때문이다. 하지만 3차 데모에서는 지도 시각화를 핵심 기능으로 설정했다.

특히 기존 디자인이 지도 영역을 고려해서 만들어졌는데 정작 지도가 없어서 매우 어색한 UI로 2차 데모를 진행했던 터라, 드디어 우리가 처음 구상했던 서비스의 모습을 제대로 구현할 수 있다는 기대감이 컸다.

지도 API로는 카카오맵을 선택했다. 원래 네이버맵을 고려했지만, 백엔드에서 네이버맵의 무료 플랜이 향후 폐지될 가능성이 있다는 정보를 찾아와서 카카오맵으로 방향을 틀었다.

카카오맵 도입 후 장소를 마커로 표시하고, 동선에 추가된 마커들을 선으로 연결하는 기능을 개발했다. 처음에는 구현 가능성에 대해 막막함이 있었지만, 카카오의 공식 문서가 매우 체계적으로 정리되어 있어서 실제 구현에는 큰 어려움이 없었다. 지도가 추가되면서 비로소 우리 서비스의 UI가 완성된 모습을 갖추게 되었다.

CD 도입

2차 데모 요구사항에는 CI 구현이 포함되어 있어 미리 구현해뒀지만, CD는 프론트엔드 요구사항에 없어서 구현하지 않았다. 그런데 3차 데모 준비 중 백엔드 팀에서 CD 구현을 제안했다.

백엔드 개발자들이 직접 프론트엔드를 테스트해보고 싶은데, 매번 프론트엔드에 배포를 요청하기 어려워서 아쉽다는 의견을 제시했다. 프론트엔드 팀에는 CD 구현 경험이 있는 사람이 없어 우선순위를 뒤로 미뤘었는데, 백엔드의 요청을 받아들여 이번 기간에 구현하기로 결정했다.

다행히 백엔드 팀원 중 한 명이 도움을 주어서 어렵지 않게 구현할 수 있었다. AWS CodePipeline을 활용해 CD를 구성했다. GitHub Actions를 활용한 방법도 많이 찾아볼 수 있었지만, 우리 상황에서는 AWS 액세스 키를 발급받을 수 없어서 CodePipeline이 최적의 선택이었다.

처음에는 복잡해 보였지만 레퍼런스 문서들을 참고하며 단계별로 접근하니 생각보다 수월하게 구현할 수 있었다. 이 경험을 통해 DevOps 영역에 대한 이해도가 한층 높아졌다.

토스트 컴포넌트

사용자에게 피드백을 제공하기 위한 수단으로 토스트 컴포넌트를 개발했다. 장소 추가, 삭제 등 사용자 액션에 대한 성공/실패 피드백을 명확히 전달하기 위해서였다.

레벨 2 미션에서 토스트 컴포넌트를 구현해본 경험이 있어서 기본 설계는 어렵지 않았다. 하지만 이번에는 여러 개의 토스트가 동시에 표시될 수 있는 형태로 구현하고 싶었다.

가장 고민이 되었던 부분은 각 토스트의 타이머를 어떻게 관리할지였다. 기존에는 하나의 토스트만 있어서 새로운 토스트가 생기면 기존 토스트와 타이머를 제거하고 새로운 것을 실행하는 단순한 방식이었다. 하지만 이번에는 여러 개의 토스트와 타이머를 개별적으로 관리해야 했다.

두 가지 방식을 고민했다:

개별 타이머 방식: Map을 통해 각 토스트별로 독립적인 타이머 관리
순차 타이머 방식: 이전 토스트 타이머가 끝나면 다음 토스트 타이머 실행

결국 사용자 경험을 고려해 개별 타이머 방식을 선택했다. 사용자가 연속으로 액션을 취했을 때 즉각적인 피드백을 받을 수 있어야 한다고 판단했기 때문이다.

디자인 전면 개편

4차 데모(런칭 데이)를 앞두고 디자인을 전면적으로 개편했다. 기존 디자인에 대한 피드백으로 "각 영역의 구분이 명확하지 않아서 어떤 역할을 하는 UI인지 파악하기 어렵다"는 의견을 받았기 때문이다.

이를 해결하기 위해 각 영역을 시각적으로 명확히 구분하고, 기존에 조화롭지 못했던 색상 시스템도 전면 수정했다. 특히 화면이 작은 노트북에서 동선 목록에 장소가 하나만 보이는 치명적인 문제가 있어서, UI 배치를 전면 재구성하는 작업도 함께 진행했다.

개편 과정에서는 영역별 통합과 구분의 균형을 맞추는 데 집중했다. 관련성이 있는 기능들은 조화롭게 통합하되, 서로 다른 역할을 하는 영역들은 명확히 구분할 수 있도록 시각적 포인트를 만들었다. 최종 목표는 사용자가 UI만 보고도 각 영역의 기능을 직관적으로 파악할 수 있도록 하는 것이었다.

⭐ 레벨 3에서 얻은 것과 아쉬웠던 부분

진정한 협업의 가치

레벨 3를 통해 얻은 가장 큰 성과를 꼽으라면 단연 진정한 협업 경험이라고 말하고 싶다.

물론 프로젝트를 처음부터 끝까지 완주하는 경험도 중요하지만, 나에게는 다른 사람들과 함께 만들어가는 과정이 가장 값진 경험이었다. 프로젝트 완성이나 기술적 도전은 혼자서도 이룰 수 있는 영역이라고 생각한다. 하지만 같은 목표를 가진 8명이 모여 두 달 동안 하나의 프로젝트 완성을 위해 협력하는 경험은 실무에 나가지 않으면 얻기 어려운 귀중한 경험이다. 특히 모든 팀원의 최우선순위가 프로젝트 성공이라는 상황은 더욱 특별했다.

물론 많은 어려움도 있었다. 동료와 감정적으로 힘들었던 순간들도 있었지만, 그런 경험을 통해 갈등을 건설적으로 해결하는 방법을 배울 수 있었다.

서로의 의견을 존중하고 양보하는 과정도 경험했다. 우리 팀은 처음부터 서로의 의견을 존중하는 분위기가 형성되어 있어서 좋았다. 더 나아가 더 나은 결과를 위해 자신의 아이디어나 의견을 기꺼이 양보하는 팀원들을 보면서 많은 것을 느꼈다. 개인의 생각보다 팀 전체를 위한 의사결정을 우선시하는 자세는 쉽게 배울 수 없는 귀중한 교훈이었다.

크로스 도메인 소통 능력의 성장

프로젝트 초반에는 프론트엔드 관점에서만 생각하며 백엔드와 논의했던 것 같다. 그 결과 서로 감정적으로 어려워지는 상황을 목격하기도 했고, 이것이 문제라는 것을 인식하게 되었다.

코치님들과의 면담을 통해 다른 포지션과 효과적으로 소통하는 방법을 배울 수 있었다. 가장 중요한 깨달음은 내 입장을 이해받고 싶다면 먼저 상대방의 입장을 이해하려는 노력이 선행되어야 한다는 것이었다. 백엔드가 특정 방식으로 API를 설계한 데는 분명한 이유가 있었을 텐데, 나는 그들의 관점을 들어보려 하지 않고 우리 입장만 이해해달라고 요구했던 것 같다.

아쉬웠던 부분들

코드 품질 vs 기능 구현의 딜레마

가장 아쉬운 부분은 코드 품질이다. 정해진 기간 내에 기능 구현을 완료하고 런칭해야 하는 일정 때문에, 코드 품질보다는 기능 구현에 더 집중할 수밖에 없었다.

평소 추구하던 클린 코드나 재사용 가능한 구조보다는 "일단 작동하는 코드"를 우선시해야 하는 상황이 많았다. 물론 레벨 4에서 리팩토링 기회가 있다는 이야기를 들었지만, 그래도 처음부터 좋은 구조로 개발했으면 어땠을까 하는 아쉬움이 남는다.

라이브러리 도입에 대한 보수적 접근

또 다른 아쉬움은 라이브러리 도입에 대해 지나치게 보수적으로 접근했다는 점이다. 특히 상태 관리 라이브러리의 경우, 팀에서 "필요성을 체감하기 전까지는 도입하지 말자"는 의견이 모여서 아예 사용하지 않기로 했다.

하지만 프로젝트 중반에 분명히 상태 관리의 복잡성을 체감했음에도 불구하고 도입하지 못했다. 기존 로직을 라이브러리로 마이그레이션하는 것에 대한 부담감과 새로운 라이브러리 학습에 대한 러닝 커브를 우려했기 때문이다.

돌이켜보면 나중에 도입하나 처음부터 도입하나 결국 같은 공수가 필요할 텐데, 왜 그 선택을 하지 못했을까 하는 아쉬움이 크다. 이 경험을 통해 적절한 시점에서의 기술적 의사결정의 중요성을 깨달았다.

⭐ 마무리

두 달이라는 시간 동안 정말 많은 것을 느끼고 배웠다. 힘들었던 순간들도 있었지만, 좋았던 경험이 아쉬운 부분보다 압도적으로 많았고, 무엇보다 즐겁게 프로젝트를 완주할 수 있었다는 것이 가장 큰 성과다.

함께했기에 가능했던 성장

무엇보다 훌륭한 팀원들을 만날 수 있어서 행복했다. 각자 다른 배경과 강점을 가진 팀원들과 함께 하나의 목표를 향해 달려가는 과정에서, 내 부족한 부분들을 객관적으로 발견할 수 있었고 동시에 새로운 나의 모습도 찾을 수 있었다.

예상치 못한 발견

이번 프로젝트를 통해 가장 뜻밖이었던 발견은 내가 팀을 리딩하는 것을 즐긴다는 사실이었다. 지금까지 리더십 경험이 거의 없었고, 내가 이런 역할을 좋아할 것이라고는 전혀 예상하지 못했다.

주제 선정부터 시작해서 팀의 의견을 조율하고, 문제 상황에서 해결책을 찾기 위해 적극적으로 나서는 과정들이 부담스럽기보다는 오히려 즐거웠다. 아마 이번 프로젝트가 없었다면 평생 알지 못했을 나의 모습일지도 모른다.

이 경험을 통해 앞으로의 커리어에서도 단순히 개발 역량뿐만 아니라 팀을 이끌어가는 역할에 대한 가능성을 발견할 수 있었다.

레벨 4를 향한 기대

이런 소중한 경험들을 바탕으로 방학 동안 프로젝트를 되돌아보고 부족했던 부분들을 보완해서, 레벨 4에서는 한층 성장한 모습으로 임할 수 있을 것 같다.

특히 코드 품질 개선과 기술적 도전, 그리고 더 효과적인 팀 협업 방식을 실험해볼 수 있는 레벨 4가 벌써부터 기대된다.