스터디, 프로젝트 모임 서비스 완성도에 실시간 화상 회의를 단독으로 설계, 구현했다. WebRTC의 세 가지 구현 방식(P2P Mesh / MCU / SFU) 트레이드오프를 분석하고, SFU 중에서 LiveKit을 고른 이유, 실제 구현, 남은 기술 부채까지 정리한다.들어가며완성도는 기존 모집 플랫폼(홀라IT, OKKY 등)이 팀원 모집까지만 다루고 끊기는 한계를 보완해, 모집부터 협업 관리까지 한 서비스 안에서 완결되는 사이클을 목표로 한다.처음엔 회의를 디스코드로 진행했다. 하지만 외부 화상회의 서비스(Discord, Zoom 등)에 의존하면 두 가지 문제가 있다.도구가 분산된다: 모집은 완성도에서, 회의는 디스코드에서, 회의 데이터는 또 다른 곳에 흩어진다회의 데이터가 외부 SaaS에 종속된다: 회..

아이디어부터 v1.0까지 — 팀 회의록 자동화를 만든 기록whisper → whisper.cpp → OSS 공개까지 결과만 보면 단순하지만, 그 사이에서 배운 게 많았다.문제 찾기완성도 팀은 프로젝트 기간 내내 회의를 했다. 코어 개발 기간(3월 중순~4월 중순)에는 거의 매일, 길게는 한 시간 가까이 붙어 있었고, 실사용자 피드백 루프로 넘어간 이후로는 주 1회 정도로 줄었다.문제는 회의 자체가 아니라 그 뒤였다. 회의가 끝나면 담당자가 내용을 정리해서 각 플랫폼에 올렸는데, 정리하느라 정작 회의엔 온전히 집중을 못 했다. 게다가 기록의 품질이 담당자의 그날 컨디션에 좌우됐다. 누가 쓰느냐, 그날 얼마나 여유가 있었느냐에 따라 회의록이 들쭉날쭉했다."이거 자동화 못 하나?" 라는 의문으로 시작했다.파이..

들어가며완성도 팀에서는 회의를 자주 한다. 처음엔 담당자가 회의 중 수기로 기록했다. 그런데 문제가 있었다.담당자의 수작업이라 기록 품질이 들쭉날쭉중요한 Action Item을 놓치기도 함회의가 길어질수록 메모 담당의 부하가 커짐이걸 자동화할 수 없을까? 그렇게 시작된 게 회의 자동 기록 프로젝트다. 녹음 → 텍스트 변환(STT) → AI 요약 → 자동 배포. 구상 자체는 단순했지만, 진짜 핵심은 "어느 STT를 쓸 것인가"였다.찾아보니 STT 기술 자체는 이미 성숙해 있었다. 나는 STT를 잘 모르는 상태였는데, AI와 함께 기획을 탄탄히 잡아가려고 했다. 내가 원하는 요구사항 스펙을 먼저 정의하고, 선택지마다 트레이드오프를 하나하나 따지면서 결정했다. Google, Azure, AWS, OpenAI ..

들어가며.."이론은 알겠는데, 우리 프로젝트에 그대로 적용하는 게 정답일까?"프로젝트에서 "내 모임 카드" 컴포넌트를 구현하게 되었다. 디자인 시안을 보니 동일한 카드가 8가지 이상의 변형으로 사용되고 있었다. 진행중, 진행 완료, 리뷰 작성, 모집중, 대기중... 상단은 비슷한데 하단이 상태마다 완전히 달랐다.기존에는 메인페이지에서 사용되는 2가지의 카드 형태를 각자 구현한 뒤 나중에 리팩토링을 하려고 했지만, 바빠지면 진행하지 못할 것 같아서 미리 처음부터 좋은 구조로 잡고 싶어서 팀원과 회의를 깊게 나눴던 것 같다.결국 재사용성을 고려해서 컴파운트 형태와 같이 가기로 결론을 지었다. 원래는 두 개의 이슈로 만들었어서 한 명이 대기하거나 이슈에서 빠져야 하는 상황이 되어서 이를 기회로 삼아서 한 번도..

취업 준비를 하면서 면접 경험이 조금(아주조금) 있었지만 이번 만큼 신선한 면접은 없었던 것 같아서 회고를 작성하게 되었다. 얼떨결에 마주한 과제 전형나는 이번년도 1월부터 이력서를 회사에 제출하기 시작했다. 이제 막 졸업을 해서 사실 더 준비하고 보강해서 이력서를 제출하고 싶었지만, 지금 내 현재의 위치를 알아볼 수 있도록 최대한 빠르게 준비해서 제출하려고 했다. 취업을 본격적으로 준비한 지 한 달이 막 지났을 쯤 서류 합격 통보가 왔다. 과제에 대한 안내 메일이였다. 사실 과제가 어떤식으로 나올지 예상이 전혀 되지 않았기도 했고, 따로 준비한 적은 없었다. 과제는 생각보다 재밌었다. 이런식으로 나오는구나.. 라는 생각이 들면서 확실히 나는 코딩테스트보다 과제가 더 잘 맞는다고 느꼈다. 하지만 통과할 ..

기존에 공통 컴포넌트를 구현하면 사실 재사용성이나 확장성을 깊게 고려하지 않고 당장 필요한 상황에 맞게 모달을 설계하곤 했다. 하지만 이는 실제 서비스를 운영하며 쏟아지는 다양한 요구사항에 부딪히면 한계를 드러낸다.실무에서는 어떤식으로 Modal이라는 공통 컴포넌트를 설계할까? Compound Component Pattern으로 어떻게 유연하게 컴포넌트를 설계하고, Promise 기반의 명령형 API로 모달을 통제하는지, Modal 컴포넌트를 만들면서 경험한 과정을 적어보려한다.왜 컴파운드 컴포넌트(Compound Component)인가?기존에 만들던 Modal 컴포넌트는 이런 형태였다.해당 모달에는 title, content, hasCancelButton만 필요했다. 하지만 이러한 방식은 다음과 같은 ..

그동안 내가 해왔던 일마지막 프로젝트 이후 많은 일들이 있었다. 네이버 부스트캠프에 지원했다가 떨어졌고, 의성에 가서 한달동안 바이브코딩을 하면서 소중한 동료들도 얻었고, 넥토리얼에 지원했다가 떨어졌다가, 마지막으로 우테코에 지원했다가 떨어졌다. 너무 불안했고, 자존감이 바닥나기 시작했다. 내가 개발자가 될 수 있는 머리인가? 우테코 미션에서 다른 사람들이 추상화 레벨과 같은 고수준의 지식 토크가 이어지는걸 볼 때, 미션 설계를 깔끔하게 잘하는 고수들을 볼 때마다 포기하고 싶었다. 자존감도 낮아지고, 내가 지금까지 공부한 내용이 다 부정당하는 느낌이 들어서 인프런의 장현석 멘토님께 멘토링을 신청했다. 여태까지의 나의 배경지식과 궁금한 질문들을 여쭤봤고 친절하게 모든 질문에 대한 답변을 주셨다. 멘토링을..

Reser On Do는 사용자가 자신만의 체험 활동을 등록하고, 다른 사용자들이 이를 예약할 수 있는 서비스이다.이번 프로젝트는 Next.js를 사용하지 않고 React로 진행했다. 처음 써보는 Lighthouse 사용기팀원들과 함께 기능 구현을 다 하고 배포를 진행했다. 그리고 해당 배포 사이트에서 Lighthouse를 사용해봤는데, 리포트는 아주아주 참담했다. 특히 LCP(최대 콘텐츠풀 페인트) 수치는 사용자가 페이지를 이탈하고도 남을 만큼 길었다. 원인은 명확했다. 이는 크기가 작은 사진을 올릴 때는 몰랐는데 업로드한 고용량 이미지가 아무런 처리 없이 그대로 렌더링되고 있었기 때문이다. Next.js를 사용했을 땐, Image컴포넌트를 통해 이미지가 최적화되었는데, React 프로젝트에서는 직접 최..

이번 프로젝트는 ?Winedoojan은 다양한 와인 정보를 쉽게 탐색하고, 사용자들이 직접 리뷰를 남기며, 구매 여부를 판단할 수 있도록 돕는 와인 리뷰 플랫폼이다.“와인 고르기 어렵다”는 인식에서 출발하여, 와인에 대한 진입 장벽을 낮추고 정보 큐레이션을 제공하는 것이 핵심 목표였다.이번 프로젝트는 이전 기초 프로젝트와 다르게, 완벽하고 꼼꼼한 컨벤션을 구축하기보다, 필요한 최소한의 컨벤션만 정리해서 실행하는 방식으로 진행했다.나는 와인 상세페이지 구현을 맡았고, 처음으로 Next.js 기반으로 프로젝트를 진행해보았다. 특히, SSR을 상세페이지에 적용해보고 싶었다. 이제 개발 과정을 살펴보자. Optimistic UI를 TanstackQuery 없이 직접 구현해보기상세 페이지 구현 중, 사용자 댓글의..

🧑🏻‍💻 첫 팀 프로젝트를 마치고 – 회고록 이 글은 제가 처음으로 팀 프로젝트를 마치고,그 안에서 느낀 부족함과 배운 점들을 정리한 기록입니다.언젠가 이 글을 다시 보며 “이때의 고민이 내 발판이었구나”라고 웃을 수 있으면 좋겠습니다. 😊🤔 팀원과의 마찰 혹은 위기는 없었을까?팀원과의 마찰은 없었지만, 조금 스트레스를 받은 적이 있었다. 컴포넌트를 설계할 때, 유연성과 재사용성 사이의 트레이드오프에 대한 개념이 없었던 시점이었고, 초반에는 일단 "재사용성 좋게 만들면 되지 않나? 기능이 추가되면 그때 수정하면 되지 않을까?" 라는 생각으로 접근했었다. 그 결과, 내가 작성한 코드에 달렸던 리뷰는, "1가지의 UI에만 대응할 수 있기에 공통 컴포넌트가 아닌, 그냥 컴포넌트다." 라는 리뷰가 있었..