위클리도다 162
251219
라운 | CEO
1. 이번주 회고
지금은 완벽한 계획보다 빠른 실행과 수정이 중요한 시대다. 6개월 전의 전략이 지금은 맞지 않을 수 있고, 어제의 방법이 오늘은 통하지 않을 수 있다. 그에 맞춰 인재의 정의가 바뀌고 있다. 유연하게 변화하는 것이 제일 중요한 역량이다.
조직관리 방식도 변화해야한다. 개인의 능력치에 대한 피드백보다 팀과 어떻게 더 잘 소통하고 협업할 수 있을지가 필요하다. 피드백을 투명하고 명확하게 주면 바뀌는 사람들이 있다. 구체적이고 건설적인 피드백을 줄 수 있다면, 많은 경우 본인도 몰랐던 패턴을 인식하고 바꾸려고 노력한다.
일다 | CTO
1. 이번주 회고
오늘은 지난 11월 18일에 있었던 Cloudflare 장애에 대해 이야기해 보고자 한다.
지난 11월 18일, Cloudflare에서 광범위한 장애가 발생했다. Cloudflare는 인터넷의 대략 1/5의 트레픽을 담당하고 있는데, 이 장애로 인해 ChatGPT, X(Twitter)를 포함한 수많은 서비스에도 접속 장애가 발생했다. 우리도 예외는 아니었다. 우리는 오래 전부터 수많은 Cloudflare 서비스를 사용해 왔다. CDN, 캐시, WAF, DDoS 방어 및 로드 밸런싱 등등 인프라의 많은 부분을 Cloudflare에 의존하고 있었기에, 이번 장애로 인해 많은 영향을 받았다.
그날의 기억
고장이 생긴 것은 대략 오후 8시 반 쯤이었다. 어느 순간부터 서비스 접속이 안 됐고, 퇴근 시간 후인데도 고객센터로 많은 문의가 쏟아졌다. 나는 그 때 중국에 있었는데, 조치를 취하려 가상사설망을 연결해서 설정을 바꾸려 했지만 Cloudflare 대시보드가 아예 열리지 않는 상태였다. Cloudflare서비스를 사용하는 기업들은 보통 도메인 네임서버를 Cloudflare로 설정하는 방식으로 Cloudflare 서비스를 사용하는데, Cloudflare에 도메인 네임서버까지 맡기다 보니 Cloudflare 자체에 고장이 생기면 기존 도메인을 backup 서버로 바로 연결하기가 쉽지 않다. 게다가 이런 대규모 장애 때 Cloudflare 대시보드도 로그인이 안 되는 상태가 되면, 사실상 조치할 방법이 없다. 장애 시간이 길어지면 아예 nameserver를 바꾸는 방법도 있는데, 이런 장애는 보통 몇 시간이면 해결돼서 바꾸기에도 애매하다(네임서버 변경은 최대 48시간 걸릴 수 있다). ChatGPT 그리고 X(Twitter)도 이번 장애를 겪은 것을 보면, 그들 또한 이런 Cloudflare의 단기간의 대규모 장애에 대응할 좋은 방법이 없거나, 혹은 지출이 너무 크고 이득이 거의 없어, 이런 몇 년에 한번 나고 몇 시간 만에 끝나는 사고는 받아들일 수 있다고 생각하는 것 같다. 다행히 그 때 우리 팀원 분들이 빠르게 고장을 파악하고 고객 안내를 잘 하셨고, 그 과정에서 우리 서비스 접속이 됐다 안됐다 여러 번 반복한 끝에 대략 2 시간 만에 회복해서 정상적으로 접속/이용이 가능해졌다. 그날 퇴근 후인데도 늦게까지 고객안내를 하신 팀원 분들께 감사하다.
Cloudflare의 고장 보고서에서 우리가 무엇을 배웠는가
Cloudflare이 이미 블로그에 그날 고장의 원인에 대해 자세히 소개했으므로 여기서는 세부적인 타임라인을 반복하는 대신 Cloudflare이 공개한 정보에서 우리가 얻을 수 있는 교훈에 대해 이야기해 보자.
1. 변하지 않을 것 같은 전제조건도 명문화하여 관리해야 한다. 시스템에서의 각종 상한치, 데이터 구조, 유일성 등 “이건 절대 바뀌거나 틀릴 리 없어”라고 믿었던 요소들이 시스템이 진화하면서 깨지는 순간, 그것은 사고로 이어진다. 이러한 요소들을 사람의 기억에 의존하기보다 ‘협정’으로 명문화하고, 데이터 생성/분배/로딩 단계에서 자동으로 검증되도록 만드는 것이 훨씬 안전하다.
2. 설정과 권한 변경은 코드 변경과 동일하게 취급해야 한다. 코드는 현미경으로 들여다보듯 엄격하게 리뷰하면서도 설정 변경에 대해 상대적으로 가볍게 여기는 태도가 잠재적 위험 요소가 될 수도 있다. 중요한 설정의 변경도 반드시 버전 관리, Gray release, 롤백, 그리고 검증 절차를 갖추는 것이 좋다.
3. 외부 입력은 기본적으로 신뢰하지 않아야 한다(여기에 내부 시스템 생성값도 포함된다). 다른 시스템에서 넘어오는 데이터라도 언제든 중복되거나, 커지지거나, 잘리거나, 포맷이 깨질 수 있다. 이를 100% 믿고 “여기는 오류 안 생기겠지”하고 그냥 넘기면 안 된다.
4. 프로덕션 환경에서 Panic 하지 말자. 이것은 개발에서 항상 강조되는 부분인데 cloudflare같은 규모의 회사가 이것을 지키지 않았다는 게 사실 조금 믿기지 않았다. 오류가 나는 것 그 자체가 무서운 일이 아니다. 무서운 건 오류가 시스템 전체를 한꺼번에 무너뜨리는 것이다.
번외. Rust의 unwrap()에 관하여: 함수 이름이 생각보다 중요할지도. 이번 사고에서 500 오류가 발생한 직접적 원인은 panic였다. Cloudflare가 공개한 정보를 보면, .unwrap()라는 방식을 사용했다. 이는 “실패하면 Panic하라”는 것이다. 만약 unwrap()이 get_or_panic()과 같은 panic이 들어간 이름이었더라면 어땠을까 하는 생각이 든다. 불길해서라도 수정하지 않았을까(웃음).
가예 | 디자이너
1. 이번주 회고
지난 2달여간 시즌성 템플릿 디자인을 촘촘하게 제작해서 무료로 제공해주는 스프린트를 집중적으로 진행 했었다.
해당 스프린트의 가설의 시작은 카나페의 TTC를 줄이기 위함이었다. TTC가 긴 이유를 파악해보았을때 시즌 이벤트에 도입해보고 싶지만, 도입 전 결과 입증 및 테스트를위해 빠른 실험을 진행하기에는 디자인과 기획 리소스 측면을 고려하다가 이탈하는것이 크다고 판단되었기 때문이다. 이를 잡기 위해 이벤트 디자인과 리워드 셋팅이 다 구상된 이벤트로 즉석당첨 이벤트를 제공하면, 도입전 효과를 빠르게 실험적으로 테스트 해보고, 결정에 도움이 되기 위함이었다.
이는 어느정도 맞기도 하고 틀리기도한 결과를 가져왔다. 디자인 리소스를 줄여주는것은 맞았으나, 이는 LTV가 낮은 브랜드의 니즈를 더 충족했고, 그결과 많은 신규회원을 끌어왔지만, 리소스 대비 매출적 성과는 낮은편이었다.
하지만 틀린 스프린트는 없다! 최대한 리소스를 줄여나가고 적은 임팩트를 확장시켜보는 방향으로 다음주를 보내고자 한다.
2. 자랑하고 싶은 것
창현 | BI Engineer
1. 이번주 회고
연말파티와도 같이 프로젝트, 세일즈, 데이터 업무 등이 몰아쳐서 진행되고 있다. 어느 부분에서는 예상치 못한 성과를, 어느 부분에는 새로운 시작과 기대감을, 어느 부분에서는 아쉬움과 동시에 개선 아이디어를 주고 있다. 하지만 하나 분명한 것은, 스모어는 단순 제품적 측면 뿐만 아니라 여러 방면에서 진화하고 있다는 것이다.
잠시 이번 회고에서는 내가 꿈꿨던 스모어의 비전에 대해서 얘기해보고자 한다. 물론 매출적 성과, 제품적 성과 비전도 있지만 그보다 더 꿈꿨던 것은, 스모어 콘텐츠를 특별한 목표를 가지고 있지 않는 대중들이 우리가 평범하게 볼 수 있는 장소 (혹은 채널)에서 정말 일상의 일부와 같이 플레이하는 모습을 보는 것이었다. 지금의 스모어는, 특정 목표를 가진 브랜드에서 이용하기에 그 목표에 부합하는 유저들만이 플레이하는 경우가 많다 (물론 이것이 나쁘다는 것은 절대 아니다) 하지만, 지금 진행하는 프로젝트가 잘 완료되어 스모어를 대중속으로 스며들게 할 수만 있고 그것을 우리 뿐만 아니라 여러 회사, 브랜드들에서 눈치채기 시작한다면 스모어는 폭발적으로 성장할 것이다. 영화관에서 나오는 QR 혜택 광고를 찍었더니 스모어가 나오고, 정말 랜덤한 곳에서 걸린 현수막 QR 코드를 찍었더니 스모어가 나오는, 그러한 “일상 속의 스모어”가 내가 꿈꾸는 스모어의 최종 비전이다.
2. 자랑하고 싶은 것
잠꾸러기 레오~
민교 | 마케터
1. 이번주 회고
이번 주는 오랜만에 카나페와 스모어 관련 블로그 콘텐츠 제작에만 집중하는 시간을 가졌다. 과거 주 4-5개의 블로그를 작성하던 시기와 비교했을 때 가장 크게 체감했던 변화는 작업 프로세스와 글의 목표 설정 방식이 많이 효율화 되었다는 것이다. 클로드를 활용해 콘텐츠 작성 시간을 대폭 단축하면서도, 각 글이 정보 전달을 넘어 실질적인 비즈니스 성과로 이어질 수 있는지를 중심으로 고민하고 기획했다. 특히 업셀링 가능성과 매출 전환 가능성을 핵심 기준으로 삼아, 고객의 구매 여정에서 의사결정에 영향을 줄 수 있는 요소들을 콘텐츠에 포함하는 데 주력했는데 이 지점이 예전에 ToFu 위주 글을 쓰는 데에만 매몰되었던 때와 많은 발전이 있었다고 생각한다. 앞으로도 블로그 콘텐츠 업무를 할 때는 작성 효율성과 더불어 각 콘텐츠의 비즈니스 기여도를 명확히 설정하고, 이를 기반으로 우선순위를 판단하는 습관을 잃지 말아야겠다!
현수 | 풀스택
1. 이번주 회고
이번 주는 카나페에 컴포넌트와 아키텍처 구조를 뜯어고치는 작업을 했다. 카나페는 SaaS툴이고 고객이 원하는 맞춤 서비스 또는 기능을 끊임없이 추가 개발하고 개선하며 성장해왔다. 그렇기 때문에 일반적인 웹사이트와는 다르게 부분적인 추가 개발이 매우 활발하게 이루어졌다.
원래 되어있던 카나페의 코드 내부구조는 빠른 개발이 가능한 훌륭한 아키텍처를 가지고 있지만 아쉬운 점도 분명히 많았다. 특히 위에 서술했던 활발하게 진행되던 추가되는 기능 개발 또는 오류 개선으로 인해 무언가 방은 항상 깨끗하고 청결하게 하지만 물건들은 여기저기 분류가 안되고 흩어져있는 느낌을 받았다.
“지금 이거 큰 오류인데 바쁘니까 야그니인지 드라이인지 뭔지 그런거 지킬 시간 없어!”, “데드라인이 코 앞이고 일단 돌아가게만 하고 나중에 정리하자” 는 200% 공감하고 나 또한 그렇다. 아주 예전에 코딩을 처음 공부할 때 다른 시니어 개발자의 코드를 보면서 “어 왜 이렇게 작성하셨지?” 라는 생각을 자주했었는데, 지금 생각해보니 아주 오만한 생각이였다고 반성할 만큼 스타트업의 실제 업무에서 매 번 완벽한 클린코드를 작성하는 것은 불가능에 가깝다. (세상에 완벽한 클린코드는 없기도 하고)
그래서 이번 코드 정리는 바쁜 저녁 시간대 요리를 아주 맛있게 만들고 고객이 만족하는 사이에 쌓여있던 설거지와 그릇 정리를 하는 느낌을 받았다. 나중에 그릇과 조리 도구들이 예쁘게 정리되어 있으면 또 다른 요리를 시작할 때 빠르고 기분 좋게, 어쩌면 더 나아가 맛있는 요리를 만들 수 있는 에너지가 될 수 있을 것 같다.