위클리도다 161
251212
라운 | CEO
1. 이번주 회고
회복탄력성이야말로 스타트업에서 가장 중요한 재능이다.
스타트업은 거절의 연속이다
투자자 100명에게 메일을 보내면 95명은 답장조차 없다. 3명은 정중히 거절하고, 2명이 미팅을 잡는다. 그 2명 중 1명은 미팅 전날 취소한다. 남은 1명을 만나면 '좋은데 아직 이르다'는 말을 듣는다. 첫 번째 직원을 뽑는 데 6개월이 걸린다. 두 번째 직원은 3개월 만에 퇴사한다. 믿었던 공동창업자가 떠난다. 출시한 기능을 아무도 쓰지 않는다. 일년동안 개발한 제품이 시장에서 외면받는다. 확신했던 가설이 데이터로 부정당한다. 어제 칭찬하던 고객이 오늘 해지한다. 이게 일상이다.
예외가 아니라 기본값이다. 문제는 이 거절들이 추상적이지 않다는 것이다.
구체적이고, 개인적이며, 반복적이다.
내 아이디어를, 내 능력을 내 자신을 거절당하는 느낌이다. 매일 반복적으로.
무너지는것은 어쩔 수 없다. 속상한 감정을 느끼지 않는 방법은 없는것같다.
하지만 누군가는 실패 후 재충전에 3일이 필요하다. 누군가는 3시간이면 된다. 이 차이가 1년이면 10배 이상의 시도 횟수 차이를 만든다. 10배 더 많은 시도는 10배 더 많은 학습을 의미한다. 10배 더 많은 학습은 결국 다른 차원의 결과를 만든다.
회복탄력성이 높은 사람은 실패를 개인화하지 않는다. 내 아이디어가 거절당했다를 나는 쓸모없다로 번역하지 않는다. 감정적 충격을 받지만 그것이 행동을 멈추게 하지 않는다. 어떻게 보면, 실패에서 회복하는게 아니라 실패를 통과하는것같다. 하나의 문이 닫힐 때, 아직 두드려보지 않을 문이 10개 있다는 사실을 보는것이다.
하드스킬을 습득하는게 너무 쉽고 각 직군별 진입장벽이 거의 사라지고 있는 요즘, 함께 일하고 싶은 사람에 대한 유일한 기준은 회복탄력성으로 좁혀지고 있는 것 같다.
일다 | CTO
1. 이번주 회고
지난 한 주간 React 서버 컴포넌트(RSC)를 둘러싼 보안 사고가 연이어 발생했다. 서버 측 원격 코드 실행(RCE)으로 이어질 수 있는 고위험 취약점이 발견된 데 이어, 서비스 거부(DoS) 및 소스 코드 유출 관련 취약점까지 총 4개의 보안 취약점이 공개되었다. 오늘 이 글에서는 사건의 타임라인과 영향 범위를 간략히 회고하고, 왜 내가 항상 핵심 비즈니스 로직에서 React 서버 컴포넌트를 사용하는 것을 권장하지 않았는지를 설명하려고 한다.
1. 사건 타임라인 (요약)
2025-12-03: 원격 코드 실행 취약점 (CVE-2025-55182) 공개
React 공식 팀은 서버 컴포넌트가 네트워크 요청 페이로드를 처리하는 과정에서 불안전한 역직렬화(Unsafe Deserialization) 문제가 있음을 공개했다. 공격자는 로그인하지 않은 상태에서도 극도로 세밀하게 조작된 요청을 통해 서버 측에서 임의의 코드를 실행시킬 수 있었다. 공식적인 해결책은 패치가 적용된 버전으로 업그레이드하는 것이었다. 이 취약점은 서버 컴포넌트에 의존하는 프레임워크에도 영향을 미쳤다. 예를 들어, 앱 라우터(App Router) 환경에서 서버 컴포넌트를 사용하는 Next.js 또한 영향을 받았으며, 이에 대한 수정 버전이 배포되었다.
2025-12-05: 방어 조치와 연쇄 작용
리스크를 빠르게 완화하기 위해 여러 서버리스 플랫폼 및 보안 업체들이 방어 규칙을 배포했다. 이 과정에서 Cloudflare는 웹 방화벽(WAF) 정책을 배포 및 조정하던 중 서비스 중단 사고를 일으켜 Cloudflare를 사용하는 웹사이트 중 대략 1/4이 다운되는 일을 겪기도 했다. 이는 긴급한 보안 조치조차 리스크를 초래할 수 있음을 보여주는 사례였다.
2025-12-11: 서비스 거부 및 소스 코드 유출 취약점 추가 발견 (총 3개)
대략 일주일 이후 React 공식 팀은 세 가지 새로운 취약점이 추가로 발견됐다고 공개했다. 그 중 두 개는 서비스 거부(DoS) 취약점(고위험도)이고, 나머지 하나는 소스 코드 유출 취약점으로, 여전히 모두 서버 컴포넌트에서 발생했다. React팀은 이전에 배포된 패치가 불완전했음을 인정하며, 완전히 문제를 해결하기 위해서는 더 최신의 버전으로 업그레이드해야 한다고 설명했다.
2. 영향 범위와 현실적 리스크
이번 사건에서 강조해야 할 사실은 두 가지다.
2.1. 공격의 접점이 '서버 컴포넌트(RSC)가 네트워크 요청을 서버 실행으로 변환하는 메커니즘' 그 자체에서 발생한다. 관련 엔드포인트가 공용 네트워크에 노출하고 있고, 실행 환경이 파일 시스템 접근 권한, 내부 네트워크 접근 권한 혹은 높은 시스템 권한을 가지고 있다면 취약점의 파괴력은 더 높아진다.
2.2. 제시간이 패치를 하는 서비스는 생각보다 많지 않다. 취약점이 공개된 후에도 인터넷상에는 업데이트되지 않은 서버들이 장기간 존재하며, 자동화된 스크립트 기반 공격 또한 빠르게 확산된다.
3. 핵심 비즈니스에 서버 컴포넌트(RSC) 사용을 권장하지 않는 이유
나는 서버 컴포넌트가 나올 때부터 “함부로 쓰면 안 되겠다”는 생각을 했다. 쓰지 않는 이유는 "신기술이 싫어서"가 아니라, 다음과 같은 엔지니어링 리스크에 대한 어떤 직감이 있었기 때문이다.
3.1 신뢰 경계가 모호하고, 코드 리뷰/보안 검사의 난이도가 올라간다
전통적인 아키텍처에서 백엔드 진입점은 라우터, 컨트롤러, 인터페이스 서비스 등으로 명확하게 구분된다. 반면 서버 컴포넌트는 일부 서버 측 기능을 '컴포넌트/함수' 의 맥락 안에 배치한다. 이는 개발 팀(특히 전통적인 백엔드 개발 경험이 적은 경우)이 "이 코드가 곧 백엔드 진입점이며, 외부 요청이 직접 도달할 수 있는 공격 접점"이라는 사실을 간과하게 만들기 쉽다. 진입점이 명시적으로 한 곳이 모여 있지 않으면, 코드 리뷰 과정에서 권한 검증, 입력값 검증, 에러 처리, 민감 정보 출력과 같은 보안 사항을 놓칠 가능성이 커진다.
3.2 프로토콜 및 직렬화 복잡도로 인한 시스템적 리스크
자세히 보면, 서버 컴포넌트(RSC)는 꽤나 복잡한 요청/응답 프로토콜과 컴파일 결과물에 의존한다. 보안 관점에서 '복잡한 프로토콜 + 역직렬화/인코딩·디코딩' 조합은 사실 고위험 영역이다. 단기간에 여러 취약점이 연속으로 발견되었다는 것은, 이 기술의 구현이 여전히 급격히 변화하고 있으며 보안 성숙도가 기술의 확산 속도를 따라가지 못하고 있음을 어느 정도 설명할 수 있다.
3.3 "뷰(View) 근처에서 백엔드 로직 작성"을 유도하는 구조
서버 컴포넌트와 서버 함수(Server Function)의 개발 경험은 프론트엔드 개발자가 컴포넌트 근처에서 데이터 접근 및 비즈니스 로직을 처리하도록 자연스럽게 유도하는 것이다. 백엔드 보안 경험이 부족한 팀원에게 이는 다음과 같은 오남용 확률을 현저히 높일 가능성이 있다.
* 민감한 설정이나 시크릿 키 값을 응답에 '무심코' 포함시키는 실수
* 데이터베이스 쿼리와 사용자 입력을 직접 결합 (SQLi 리스크 초래 등)
* 지나치게 상세한 에러 메시지나 내부 구조 정보를 응답으로 반환하는 실수
3.4 유지보수 관점: 패치 주기와 플랫폼 의존성 심화
핵심 비즈니스 로직이 '프레임워크 내장 서버 기능' 위에서 구동될 때, 고위험 취약점이 발생하면 업그레이드 기간은 촉박해지고, 롤백은 어려워지며, 파급 효과는 커진다. 이에 반해 백엔드 기능을 독립된 서비스로 분리하고 프론트엔드 프레임워크를 단순히 UI 라이브러리로만 한정한다면, ‘하나의 프레임워크의 취약점이 시스템 전체 사고로 이어질 확률'을 현저히 낮출 수 있다.
4. 그러면 어떻게 해야 할까?
서버 컴포넌트가 "절대 사용해서는 안 되는 기술"이라는 뜻은 아니다. 하지만 최근의 보안 이슈 발생 빈도와 리스크 집중도를 고려할 때, 이를 핵심 비즈니스의 풀스택 기반으로 삼는 것은 보수적인 선택이 아니라 할 수 있다. 나는 지금 이 시점에 대다수의 팀에게는 명확한 프론트엔드-백엔드 경계, 확실한 진입점, 그리고 감사 가능한 권한 모델이 장기적으로 더 신뢰할 수 있는 선택지라고 생각한다.
가예 | 디자이너
1. 이번주 회고
이번 주는 고객과의 소통 그 자체가 핵심이었다. 새로운 리드를 얻는 일은 늘 중요했지만, 그보다 더 집중한 건 이전에 접점을 만들었던 리드들을 다시 들여다보며 진짜 지금 우리의 제안을 가장 잘 받을 만한 고객을 선별하는 일이었다.
그동안 넓게 퍼져 있던 타깃을 조금 더 정교하게 좁히고, 각 고객사가 필요로 할 만한 형태로 제안을 수정해가면서 접근해갔다.
카나페는 TTC가 긴 서비스라서, Not Now와 이탈을 제대로 구분하는 게 무엇보다 중요하다.
결국 이를 해결할 수 있는 방법은 두 가지밖에 없다. 관찰과 적절한 시점에 적절한 이유로 다시 제안하는 것. 고객이 필요한 타이밍은 결국 고객 내부에서 만들어지는 것이니까, 내가 할 수 있는 건 흐름을 읽고 맞는 순간에 다시 손을 건네는 일이다. 물론 이 과정에서 차가운 온도를 느끼긴 하지만..! 온도를 올려가는 방법에 감각을 잡아가는중이다.
이를 세일즈뿐만 아니라 고객의 시선이 닿는 모든곳에 설계하고 녹여내고싶다는 뜨거운(?)생각을 한 한 주 였다.
2. 자랑하고 싶은 것
레오의 셀카!
두쫀쿠를 드디어 먹었다!
디카를 선물 받았다!
창현 | BI Engineer
1. 이번주 회고
데이터 활용/데이터 분석은 어디까지가 발전할 수 있는지에 대한 고민이 큰 요즘이다. 물론 성과 분석, 미래 예측, 회고, 액션 모수 선정 등 데이터는 수많은 곳에서 사용될 수 있지만, 어느 순간부터 데이터가 들어가는/작용하는 영역에 한계가 보일 때가 있다. 어쩌면 한계일 수도 있고, 어쩌면 정말 데이터 기반 시스템 구축이 모두 완료되었기 때문에 관련해서는 이제 유지/보수 작업 혹은 자동화만 필요하고 다른 시간에 데이터 외 업무를 진행할 수 있게 된 긍정적인 신호일 수도 있다. 다만, 최근 스모어 내 데이터를 이용해서 Data Science Project (예측, 분류 모델)를 진행해보고 싶은 열망이 조금 있다. 예전에 이탈 유저 예측 모델 기반 이탈 방지 스프린트를 진행하긴 했었지만 모델 제작을 위한 데이터가 부족하여 큰 효과를 보진 못했던 것 같다 (+ 정확한 성과 추적도 쉽지 않았다). 올해 스모어의 매출과 가입자가 증가하면서 새로운 고객 분류 / 행동 예측 모델을 해보는 것도 유의미할 것 같다. 어떤 순간에 유저에게 어떤 액션을 취해야 구매로 이어지는지 알아내는 것. 이것을 알아내는 것이 데이터와 매출의 최고 콜라보레이션일 것이다.
2. 자랑하고 싶은 것
I am the 구움과자 마스터. 공식 한국제빵제과협회가 인정한 구움과자 마스터가 바로 나야나.
민교 | 마케터
1. 이번주 회고
번역이나 문서 요약은 GPT가, 글 작성은 클로드가, 이미지 생성은 나노바나나가, 그리고 PPT 제작은 젠스파크가 너무나도 '잘'해주는 시대에 살고 있다. GPT를 업무에 처음 활용하기 시작했던 2023년까지만 해도 퀄리티 측면에서 부족한 점이 더러 보였는데, 지금은 어떤 제작물이든 10분 정도만 검수하면 바로 세상에 내보낼 수 있을 정도로 완성도가 높아졌다. (물론 그만큼 나를 포함한 사람들의 프롬프트 작성 실력이 늘어난 것도 있다)
사실 이런 시대가 오면 '나는 뭘 고유하게 잘 해낼 수 있을까' 매일 걱정될 줄 알았다. 하지만 막상 겪어보니 AI 때문에 스스로 할 수 있는 게 없어졌다는 생각보다, 오히려 AI 덕분에 뭐든 못 할 게 없다는 생각이 든다. 불순물을 체에 걸러내듯 ROI가 높지 않은 작업들 (단순 이메일 작성, ToFu 글 작성, 섬네일 제작 등)은 AI가 처리해주니, 오히려 잘 걸러진 알맹이만 고민하면 된다는 느낌을 자주 받는다.
이젠 고객이 어떤 메시지에 귀 기울일지, 어떻게 휴먼 터치를 해야 할지, 어떻게 기획을 쌓아 올려야 리소스를 줄일 수 있을지에만 집중하면 된다. 사실 이것이야말로 AI 발전과 상관없이 가장 중요한 본질이기 때문에, AI 활용 빈도가 점점 늘어나는 게 아직은 즐거운 요즘이다.
현수 | 풀스택
1. 이번주 회고
최근 백엔드 서버에 비동기를 담당하는 Celery라는 라이브러리를 활용한 스프린트를 진행했는데 예전 에 다수의 Worker 프로세스와 메세지 큐를 통해 비동기를 지원한다는 Django의 Celery의 개념이 대부분 백엔드를 node.js를 사용했던 나에게는 굉장히 생소하게 다가왔던 기억이 있다.
물론 시간이 흐르고, Django 서버에 비동기에 대해서는 어느정도 파악하고 Celery 개념과 이론도 충분하게 인지하고 있었지만 이번 스프린트는 관련한 난이도가 꽤 높은 작업이여서 이런저런 애로사항을 마주쳤으며 지원하는 세부적인 옵션 또한 미리 파악하지 못해 꽤나 애를 먹어버렸다.
개발이라는게 개념을 알고 실제로 한 두번 만들어보는 것(클론 코딩 등)도 충분히 도움이되지만 그것보다 여러 경험과 상황에 노출이 되고 이를 해결하는 과정을 겪는게 개발 실력을 빠르게 올리는 치트키가 된다고 생각한다.
그리고 나는 개발을 시작한지 꽤 오래 시간이 지났지만 아직 이런 “종합적인 경험치” 측면에서는 갈 길이 멀다고 느꼈다.
그래서 이번 주말은 AI에 기대지 말고 깊이 생각해보며 개발 공부를 할 예정이다!