사이드프로젝트 실시간 피드 - SYDE 피드

미국에서 우버가 처음 나오던 무렵, 차에서 내리려는 나에게 기사님이 이렇게 말했다. 내가 제공하는 서비스가 마음에 들면 5점을, 마음에 들지 않으면 4점을 달라고. 5점 만점에 4점이 낙제인 셈이다. 별점이라는 건 다섯 개의 별로 온 세상이 같은 잣대를 쓰는 것처럼 보인다.먼저 짚자면 나부터가 일관된 리뷰어는 아니다. 기분도 많이 타고, 남들의 리뷰는 열심히 보면서 정작 내가 남기는 일은 드물고, yelp나 AirBnB처럼 실명이 걸리는 곳에서는 5점과 1점 사이를 오갈 뿐 3점과 4점을 첨예하게 나누는 세심함은 없다. 인터넷 설치를 해 준 업체가 0에서 10까지로 평가를 청해 오면, 나와 싸운 게 아닌 다음에야 어지간하면 만점을 주는 버릇도 있었고, 식당이 마음에 들지 않으면 팁을 줄이는 것으로 마음을 표현했지, 집에 와서 기어이 리뷰를 남기는 성격은 아니었다. 다섯 칸이든 열한 칸이든, 내 손에서 그 눈금은 사실상 두 칸, yes/no로만 쓰이고 있었던 셈이다. 아… 이 바이너리 인간이란…도메인마다, 그러니까 동네마다 꽤 다르다. 영화라면 IMDb 점수와 RottenTomatoes 지수처럼 분포가 넓게 펼쳐진 체계가 있고, 아마존이나 구글맵은 5점 만점의 별로 돌아간다. 그리고 우버와 AirBnB처럼 서로가 서로를 평가하는 상호 리뷰의 세계가 있는데, 이쪽은 앞의 기사님처럼 4점이 사실상 낙제가 되는 극단적인 상향 평준이 자리를 잡았다. 먹는 것이나 앱 리뷰는 또 사정이 달라서, 같은 다섯 개의 별인데 후하게 주는 기준과 짜게 주는 기준이 동네마다 갈린다.나라를 건너가면 차이는 더 벌어진다. 미국의 우버가 5점이 기본이고 4점이면 불만이라면, 한국에서는 별점이 소통의 수단이 되어 불만이면 1점을 주었다가 해결되면 5점으로 고쳐 주는 식의 쓰임이 있었고, 우리끼리는 5점을 주고서 본문에는 험한 말을 쏟는 리뷰도 낯설지 않다. 평가라는 행동은 언어가 아니라 나라의 문화에 묶여 있었다. 같은 식당 리뷰라도 한일의 평균과 분포는 달라도 너무 달랐다. 이런 편차는 먹는 것에만 있지 않아서, 같은 영화라도 국경을 넘으면 그 평균과 분포가 사뭇 다르게 그려졌다.흥미로운 건 총점 자체의 무게였다. 일본의 타베로그나 미국의 yelp는 사이트가 매기는 점수의 권위가 커서, 3점대 중반만 넘어도 손꼽히는 집으로 통했다. 반면 한국에서는 개별 리뷰는 넘쳐도 총점은 그만한 무게를 얻지 못했는데, 애초에 식당 리뷰를 남기는 데에 심리적 벽이 있어서였다. 맛없는 집을 굳이 다시 찾아가 별점을 깎는 사람은 드무니, 총점은 자연히 위로 쏠렸다.그런데 이 별점이라는 것을 주는 자리가 아니라 받는 자리에 서 보면 이야기가 사뭇 달라진다. 상호 리뷰의 세계에서는 사용자도 리뷰를 당하는 처지라, 괜히 4점을 받으면 마음이 많이 상한다. KAIST에서 겸임교수로 강의를 하던 시절, 학기가 끝나면 강의 평가가 도착했다. 부족함이 많았던 터라 각오는 했다. 별점은 평균이라는 하나의 숫자로 뭉개져 왔지만, 개별 코멘트는 낱낱이 펼쳐져 읽혔다. 불만이 글자가 되어 남는 쪽이 훨씬 오래갔다. 전체 몇 명 가운데 몇 명인지는 그리 중요하지 않았고, 블라인드나 면접 후기 사이트가 대개 칭찬보다 험담으로 북적이는 걸 떠올리면 조금 위안이 되기도 했다. 그래도 주는 쪽일 때는 두 칸으로 무심히 쓰던 잣대가, 받는 쪽이 되면 비어 있는 별 한 칸이 상처처럼 남는다.플레이스토어 고객들인 개발사들에게는 그 상처가 일상이자 업무였다. 앱의 리뷰란은 공식 커뮤니케이션 채널로 자주 쓰였다. 전용 카페나 커뮤니티를 스토어 밖에 차려 두어도 할 말은 어떻게든 리뷰로 전해진다고들 여겨서, 담당자들이 리뷰란을 열심히 관리했다. 소위 진상 손님도 왕왕 나타났는데, 배달 음식이나 식당 리뷰 쪽에서 인플루언서가 별점과 후기를 빌미로 무리한 서비스를 요구하듯, 앱 스토어에도 별점을 협상 카드로 들고 오는 이들이 있었다. 그들과 같이 해결해 보려 애쓰던 기억이 난다. 그동안 스쳐 간 수많은 Customer Success / Customer Support 분들의 노고를 떠올리면, 조용히 응원을 보내게 된다.별점 다섯 칸은 주는 입장에서는 binary 선택으로 무심히, 받는 입장에서는 빈 한 칸이 상처로, 개발사에게는 협상의 카드로. 그렇게 자리마다 나라마다 다른 말을 하고 있었다. 그런데 이 제각각인 목소리를 시스템이 받아 다루려 하면, 그 단순한 별 하나 뒤에서 그 뜻을 해석하는 쪽은 보기보다 많은 고민을 해야 했다.이 글은 '나라와 언어 사이'라는 연작의 한 편입니다. 원문과 나머지 편은 브런치에 있습니다 → https://brunch.co.kr/@chaesang/197

처음에는 공용 덱이라는 규칙만으로도 꽤 재미있는 게임이 나올 것 같았다.그런데 실제 전투 규칙을 만들다 보니 한 가지가 마음에 걸렸다.좋은 카드를 뽑았을 때 할 수 있는 일이 상대를 여러 번 공격하는 것뿐이라면, 결국 숫자가 높은 카드를 뽑는 쪽이 유리한 게임이 되지 않을까?물론 카드 운이 승부에 영향을 주는 것은 자연스럽다. 하지만 운이 좋지 않았다는 이유만으로 할 수 있는 일이 별로 없다면, 플레이어가 고민할 여지도 줄어든다.그래서 카드를 뽑은 뒤에 무엇을 할지 결정하는 과정이 재미있었으면 했다.같은 행동 횟수라도 선택은 달라야 한다초기 전투 규칙은 공격을 중심으로 구성되어 있었다.영웅을 움직여 상대를 공격하고, 행동을 반복하면서 고유 능력을 충전하는 방식이었다.하지만 모든 영웅이 공격에만 집중한다면 결국 어느 영웅으로 더 많은 피해를 줄 수 있는지가 가장 중요한 판단이 될 것 같았다.그래서 영웅마다 전투에서 맡는 역할을 조금 더 분명하게 나누었다.Guard는 상대를 공격할 수도 있지만 아군에게 방어막을 부여할 수 있고, Medic은 공격 대신 체력을 회복할 수 있도록 했다. Gunner는 공격에 특화된 영웅으로 남겼다.이렇게 바꾸니 같은 행동 기회를 얻어도 여러 선택이 가능해졌다.지금 공격을 집중하면 상대 영웅을 쓰러뜨릴 수 있을지도 모른다. 하지만 다음 턴의 공격을 버티기 위해 아군을 보호하는 편이 나을 수도 있다.당장 체력을 회복할 것인지, 조금 위험하더라도 공격을 이어갈 것인지도 고민해야 한다.여기에 영웅별 능력 충전까지 고려하면 선택은 더 달라진다.같은 영웅을 계속 행동시켜 다음 능력을 준비할 수도 있고, 여러 영웅에게 행동을 나누어 당장의 전투 상황을 정리할 수도 있다.어느 쪽이 항상 정답이어서는 안 된다고 생각했다.지금 당장 유리한 행동과 다음 상황을 준비하는 행동 사이에서 고민하는 것.이런 선택들이 쌓여서 전투의 흐름을 만들어갔으면 했다.상대도 내가 무엇을 준비하는지 알고 있다SAME DECK에서는 다음 카드의 순서를 제외하면 전투에 필요한 정보 대부분을 서로 확인할 수 있다.영웅들의 체력은 물론이고, 누가 고유 능력을 사용할 준비가 되었는지도 상대에게 보인다.내가 Gunner의 공격을 준비하고 있다면 상대도 그 사실을 알고 있다.그렇다면 상대는 Gunner를 먼저 쓰러뜨리려고 할 수도 있고, 공격을 견딜 수 있도록 아군을 보호할 수도 있다.나는 또 상대가 그렇게 대응할 가능성을 생각해야 한다.하지만 상대가 어떤 선택을 할 수 있는지 안다고 해서 실제로 무엇을 할지까지 알 수 있는 것은 아니다.상대가 공격할 거라고 예상해 방어에 행동을 사용했는데, 정작 상대는 다른 영웅의 능력을 준비할 수도 있다.반대로 공격을 이어갈 거라고 생각했던 상대가 갑자기 회복에 집중할 수도 있다.이렇게 서로의 행동을 보면서 다음 수를 예상하는 과정이 생긴다.여기에 다음 카드가 무엇인지 알 수 없다는 점까지 더해진다.상대가 다음 턴에 충분한 행동 기회를 얻을지, 예상하지 못한 특수 카드가 등장할지는 확실하지 않다.결국 상대가 무엇을 할 수 있는지와 실제로 무엇을 하게 될지는 다른 문제다.그 차이에서 심리전이 만들어졌으면 했다.SWAP이 남아 있다면특히 SWAP은 전투 중의 판단을 조금 이상하게 만드는 카드다.SWAP이 등장하면 두 플레이어가 조종하는 영웅 진영이 서로 바뀐다. 영웅의 체력과 충전 상태 등은 그대로 유지되고, 조종하는 플레이어만 달라진다.이 규칙을 생각하다 보니 평소라면 손해일 행동도 경우에 따라 고민할 수 있겠다는 생각이 들었다.예를 들어 Gunner는 다른 아군 영웅을 공격할 수 있다.보통은 아무 이유 없이 아군을 공격할 필요가 없다.그런데 공용 덱에 SWAP이 남아 있다면 어떨까?지금 아군을 공격해 체력을 줄여두었는데 이후 SWAP이 등장한다면, 그 영웅들을 상대가 조종하게 된다.반대로 SWAP이 등장하지 않으면 내가 내 영웅을 공격한 손해만 남는다.Medic에게도 비슷한 상황이 있다.Medic은 평소에는 아군을 회복하고 적을 공격하지만, 충전된 고유 능력은 선택한 대상이 아군인지 적인지에 관계없이 체력을 회복시킨다.그래서 상대 영웅에게 일부러 회복 능력을 사용하는 것도 가능하다.당장은 상대에게 도움을 주는 행동이다. 하지만 이후 SWAP이 등장하면 내가 조종하게 될 영웅을 미리 회복시킨 셈이 된다.물론 이 역시 SWAP이 나오지 않는다면 상대만 도와준 결과가 된다.이런 행동이 항상 좋은 전략이라는 뜻은 아니다. 오히려 대부분의 상황에서는 무리한 선택일 수도 있다.하지만 재미있다고 느꼈던 건 이런 고민 자체였다.SWAP이 나올지도 모른다는 이유로, 지금 손해를 감수할 수 있을까?카드가 언제 나올지 모르기 때문에 확실한 계산은 어렵다.그렇다고 SWAP이 남아 있다는 사실을 완전히 무시할 수도 없다.이처럼 아직 등장하지 않은 카드가 현재의 선택에 영향을 주는 상황을 만들고 싶었다.모든 행동을 자유롭게 뒤집을 수 있도록 만든 것은 아니다. 초기에는 여러 영웅이 아군을 공격할 수 있었지만, 역할을 정리하면서 아군 공격은 Gunner에게만 남겼다. Medic의 적 대상 회복 역시 충전된 고유 능력을 사용할 때만 가능하다.이런 제한 속에서 가끔 예상 밖의 선택이 가능하다는 점이 마음에 들었다.예상하지 못한 상황이 항상 재미있는 것은 아니다그렇지만 개발을 진행하면서 예상 밖의 상황이 많이 발생한다고 반드시 재미있는 것은 아니라는 생각도 하게 됐다.CHAOS 카드는 전투의 흐름을 크게 바꾼다.하지만 플레이어가 제대로 행동해보기도 전에 전투 상황부터 뒤집힌다면 어떨까?물론 그것 역시 공용 덱에서 일어날 수 있는 일이다.다만 게임이 시작되자마자 이런 상황이 발생하는 것이 항상 좋은 경험인지는 고민할 필요가 있었다.그래서 최근에는 양쪽 플레이어가 먼저 영웅을 움직이고 전투를 시작할 기회를 확보하는 방향으로 초반 드로우 규칙을 조정해 시험하고 있다.무작위성을 없애려는 것은 아니다.오히려 플레이어가 어떤 행동을 선택하고, 그 결과를 바탕으로 다음 상황을 예상하기 시작했을 때 CHAOS 카드가 등장하는 편이 더 흥미로울 수도 있다고 생각했다.REVIVE의 규칙을 조정했던 것도 비슷한 이유였다.쓰러진 영웅을 부활시키는 효과는 분명 강력해 보인다. 하지만 살아난 영웅이 상대의 다음 공격에 곧바로 쓰러진다면, 실제로는 별다른 선택을 해보지 못할 수도 있다.그래서 부활한 영웅에게 일시적인 보호막을 부여하도록 변경했다.부활 자체가 끝이 아니라, 부활 이후에도 전투를 이어갈 기회가 있었으면 했기 때문이다.이런 조정들이 모두 정답인지는 아직 모른다.실제로 플레이하면서 재미와 밸런스를 계속 확인해야 하고, 필요하다면 규칙도 다시 바꿀 생각이다.다만 규칙을 바꿀 때마다 계속 돌아보게 되는 질문은 비슷했다.이 변화가 플레이어에게 더 재미있는 선택을 만들어주는가?운과 선택 사이에서처음에는 하나의 덱을 공유한다는 아이디어가 재미있을 것 같아서 SAME DECK을 만들기 시작했다.지금도 공용 덱은 게임의 가장 중요한 특징이다.하지만 게임을 만들면서 단순히 같은 덱을 사용한다는 사실만으로는 충분하지 않다는 생각을 하게 됐다.운 좋게 많은 행동 기회를 얻더라도 어떻게 사용하느냐에 따라 결과가 달라지고, 불리한 상황에서도 상대의 다음 선택을 예상하며 대응할 여지가 있었으면 한다.때로는 상대가 내 생각을 읽고 다른 행동을 할 수도 있고, 전혀 예상하지 못했던 카드 한 장으로 계획이 틀어질 수도 있다.그렇더라도 나중에 돌아봤을 때 다른 선택을 해볼 수 있었겠다고 느낄 만한 게임이면 좋겠다.카드를 잘 뽑아서 이기는 것도 재미있지만, 상대보다 한 수 앞서 생각해서 이기는 순간이 더 재미있었으면 한다.SAME DECK은 지금도 그런 방향으로 규칙을 다듬고 있다.

안녕하세요 하루들입니다!하루들은 우리끼리 통하는 일상을 네컷만화로 나누는 서비스예요. 만화를 만들고, 다시 찾아보고, 누군가에게 보여주는 경험에서 가장 중요한 건 결국 만화 자체인데요.화면에 제목과 버튼이 먼저 나타나더라도, 정작 그림이 보이지 않으면 이야기를 읽을 수 없어요.그런데 실제로 사용자에게서 이미지가 너무 늦게 뜬다는 피드백을 받았어요. 만화를 보러 들어왔는데 이미지를 기다리는 시간이 길었던 거죠. 저희는 이 기다림부터 줄여보기로 했어요.이번 글에서는 하루들의 이미지 로딩을 어떻게 살펴봤고, 어떤 기준으로 이미지 형식과 크기를 바꾸었는지 이야기해보려고 해요.하루들에서는 무엇이 빨라야 할까?성능을 개선한다고 하면 먼저 점수나 로딩 시간을 떠올리기 쉬워요. 하지만 저희는 그전에, 사용자가 어떤 순간에 기다리고 있는지부터 정하고 싶었어요.이번에 고른 흐름은 네컷만화 상세 화면에서 목록으로 돌아오는 과정이에요. 만화 한 편을 보고 돌아왔다면, 다음에 볼 만화도 바로 고를 수 있어야 하니까요.예전에 홈 화면에 있던 이 목록은 지금은 "네컷 모아보기" 탭으로 옮겨져 있어요. 측정 기준도 아래와 같이 정했답니다.목록 이동 버튼을 누른 순간부터, 목록 위쪽 썸네일 3개가 모두 표시될 때까지.단순히 화면이 나타나는 순간이 아니라, 실제로 만화를 알아보고 고를 수 있는 순간을 기준으로 삼은 거예요. 썸네일은 화면에 완전히 보이는 3개를 기준으로 했어요.모바일에서 만화를 확인하는 상황을 고려해, 다음 조건으로 측정했어요.도구: PC의 Chrome 개발자도구화면: iPhone SE 프리셋네트워크: Slow 4GCPU: 4배 느림목록으로 돌아왔는데, 약 23초를 기다렸다개선 전에는 같은 흐름으로 3번 측정했어요. 썸네일 3개가 모두 나타날 때까지 약 24.00초, 23.16초, 23.15초가 걸렸고, 중앙값은 약 23.2초였어요.다음 만화를 고르기까지 수십 초를 기다려야 했던 거예요.저희는 이 시간을 3회 측정 중앙값 기준 3초 이하로 줄이는 것을 목표로 잡았어요. 빠르게 느껴지는지 막연하게 판단하기보다, 개선 후에 같은 행동을 다시 측정하고 목표에 도달했는지 확인하고 싶었거든요.원인을 찾을 때는 Chrome의 Network와 Performance를 함께 봤어요.Network: 이미지가 얼마나 많이, 얼마나 오래 전송되는지 확인Performance: 버튼을 누른 뒤 실제 화면에 이미지가 나타나는 순간을 확인이미지를 다 받아오는 시간과 사용자가 볼 수 있는 시간은 다를 수 있으니까요.Network에서 정상적으로 받아온 이미지 4개를 살펴보니, 각각의 요청에 약 20~30초가 걸렸어요. 목록으로 돌아올 때도 이미지가 다시 전송되고 있었고요.저희는 먼저 이미지 하나를 보여주는 데 필요한 데이터부터 줄여보기로 했어요.작은 썸네일에도 큰 원본이 필요할까?기존에는 목록과 상세 화면 모두 1024×1024 PNG 이미지를 사용하고 있었어요. 만화를 크게 펼쳐보는 화면과, 여러 편 중 하나를 고르는 작은 썸네일이 같은 이미지를 받아오고 있었던 거죠.하지만 두 화면에서 이미지가 하는 역할은 달랐어요.목록: 그림을 알아보고 어떤 만화인지 고를 수 있어야 해요.상세: 대사와 그림의 선까지 읽을 수 있어야 해요.그래서 모든 화면에 같은 원본을 보내는 대신, 용도에 맞는 이미지를 따로 만들기로 했어요.백엔드에서는 cwebp를 사용해 PNG를 WebP로 변환하고, 목록용과 상세용 이미지를 각각 생성하도록 바꿨어요. 프론트엔드에서도 화면에 맞는 이미지를 사용하도록 적용했습니다.용도변경 전변경 후목록 썸네일1024×1024 PNG240×240 WebP만화 상세1024×1024 PNG960×960 WebP어디까지 줄여도 괜찮을까?물론 용량만 줄일 수는 없었어요. 하루들에서 이미지가 핵심이어서 빠르게 뜨더라도 화질 저하로 인해 만화를 읽기 어려워지면 의미가 없으니까요.만화 상세 화면이미지 크기를 정할 때는 화면에 표시되는 크기와 DPR을 함께 고려했어요. DPR은 화면에서 사용하는 픽셀과 실제 화면 픽셀 사이의 비율이에요.예를 들어 DPR 2에서는 화면에 390px 너비로 보여줄 이미지에 780px 정도의 해상도가 필요하다고 볼 수 있어요. 상세 화면의 최대 표시 크기가 390×390 CSS px라서, 그보다 여유 있는 960×960px을 선택했어요.목록 화면(썸네일)목록은 당시 표시 너비가 약 130px이었어요. 여기서는 대사를 자세히 읽기보다 화질지 좋지 않더라도 그림을 알아보고 만화를 선택하는 역할이 더 중요하다고 봤어요.그래서 240×240px을 후보로 두고 실제 표시 크기에서 원본과 변환본의 화질, 용량을 비교했어요. 모든 화면에 가장 선명한 이미지를 보내기보다, 그 화면에서 필요한 역할을 유지하는 쪽으로 기준을 세운 거예요.화질은 팀원들과 함께 확인했어요상세 이미지의 화질은 팀원들에게도 의견을 물었어요. 원본과 WebP를 나란히 놓고 의도적으로 비교하지 않는 이상 차이를 느끼기 어렵다는 의견을 받았어요.이를 바탕으로 원본의 화질을 그대로 유지하기보다, 만화를 읽는 데 지장이 없는 수준에서 전송량과 기다리는 시간을 줄이기로 했어요.아래는 같은 만화의 원본 PNG와 상세용 960px WebP예요.원본 1024×1024 PNG상세용 960×960 WebP이미지는 가벼워졌고, 기다림도 짧아졌다변경 후에는 이미지 전송량과 목록 표시 시간을 다시 확인했어요. 먼저 결과를 정리하면 다음과 같아요.확인한 항목개선 전 관찰개선 후 관찰표본 이미지당 평균 전송량약 1,102kB약 13.1kB목록 이미지 개별 요청 시간약 20~30초3회 모두 1초 이내목록 복귀 후 썸네일 3개 표시중앙값 약 23.2초중앙값 약 3.23초전송량과 이미지 요청 시간확보한 PNG 6장과 WebP 썸네일 4장의 전송량을 비교했어요. 서로 다른 표본의 평균을 비교한 값이지만, 확보한 표본에서는 이미지당 평균 전송량이 약 98.8% 작았어요.목록의 정상 이미지 4개를 대상으로 요청 시간도 3회 확인했어요. 개선 후에는 측정한 모든 이미지 요청이 1초 이내에 완료됐어요. 앞서 약 20~30초가 걸렸던 요청과는 차이가 컸죠.사용자가 만화를 고를 수 있기까지의 시간같은 기준으로 3번 측정한 결과 약 3.18초, 3.25초, 3.23초가 걸렸어요. 중앙값은 약 3.23초였고요.처음 정한 3초 목표보다는 약 0.23초 길었어요. 이미지 요청은 1초 안에 끝났지만, 사용자가 기다리는 전체 시간은 아직 목표에 도달하지 못한 거예요.상세 화면에서도 추가로 살펴봤어요서비스에 남아 있는 서로 다른 만화 두 편을 비교했어요.PNG: 요청 시간 약 10.77초, 전송량 약 1,402.1kB (3회 측정 중앙값)WebP: 요청 시간 약 0.94초, 전송량 약 54.9kB (1회 관찰)다음에는 무엇을 덜 기다리게 할까?이미지를 가볍게 만든 뒤에도 목록으로 돌아올 때 월간 목록 조회 API는 매번 한 번씩 호출되고 있었어요.만화를 새로 만들거나 삭제하지 않았다면 같은 목록을 다시 보여줘도 되는데, 데이터를 다시 기다리고 있었던 거예요.그래서 다음에는 같은 달의 조회 결과를 재사용하는 캐싱을 검토하려고 해요. 다만 무조건 저장된 데이터를 쓰는 것은 아니에요.새로 조회해야 하는 상황도 함께 정해야 해요.만화가 새로 생성되거나 삭제됐을 때이미지 URL이 만료됐을 때아직 이 캐싱은 적용하지 않았어요. 적용한 뒤에는 같은 조건과 요청을 차단하지 않은 정상 목록에서 다시 측정할 계획이에요.만화를 실제로 볼 수 있는 순간까지이번 작업을 하면서 하루들에서 중요한 성능은 화면이 나타나는 속도만이 아니라, 사용자가 만화를 실제로 볼 수 있을 때까지의 시간이라는 걸 다시 느꼈어요.이 경험을 기준으로 측정하니, 큰 이미지의 전송 부담과 목록 데이터를 다시 기다리는 문제를 나눠서 볼 수 있었고요.이미지 요청이 빨라진 것만으로 처음 세운 목표를 달성한 건 아니었어요. 앞으로도 같은 질문을 기준으로, 남은 시간을 줄여가려고 해요.목록으로 돌아와 만화를 고를 수 있기까지, 얼마나 기다리는가?일상을 네컷만화로 나누는 즐거움이 기다림에 가려지지 않도록, 하루들을 계속 다듬어갈게요. 그 과정도 함께 공유하겠습니다!더 자세한 내용이 궁금하다면GitHub Wiki: 측정 과정과 세부 수치이미지 최적화 적용 PR

AI 에이전트를 회사 일에 붙여 본 분이라면 비슷한 벽을 만났을 거예요. 모델은 똑똑한데 우리 회사 데이터가 어디에 어떻게 있는지는 모릅니다. 그래서 다들 온톨로지가 필요하다고 하는데, 막상 그래프와 형식 문법을 익히려면 막막하죠.제네시스랩 유대훈 CTO님은 다른 길을 택했습니다. 회사는 10년 가까이 딥러닝을 연구했고, 채용 면접 분석 서비스 뷰인터 HR로 알려져 있어요. 지금은 기업용 에이전트 빌더 에이전트리아와 그 안의 지식 기능 슬립박스를 만들고 있습니다. 빌더 조쉬 채널의 HOW I AI 팟캐스트에서 유대훈 CTO님과 이야기 나눴고, 조쉬의 뉴스레터에 정리한 내용 중 직접 만드는 사람이 가져다 쓸 만한 대목만 추렸어요.1. 프롬프트 몇 개 고치는 데 1~2주가 걸렸다시작은 내부 병목이었습니다. 현업 전문가가 필요를 짚으면 AI 연구원이 스트림릿으로 프로토타입을 만들고, 서비스 개발팀이 다시 다듬어 배포했어요. 유대훈 CTO님에 따르면 이 세 팀이 얽히다 보니 프롬프트 몇 개로 끝날 일도 1~2주가 걸렸다고 합니다.그래서 현업이 프롬프트와 지식 체계를 직접 설정하고, 문제가 생기면 연구팀과 같은 화면을 보며 그 자리에서 고치는 도구를 먼저 만들어 봤어요. 어떤 건 하루 만에 테스트할 수 있었고, 그 경험이 범용 에이전트 빌더로 이어졌습니다. AI는 배포한 순간부터가 시작이라는 게 그의 말이에요. 사용자는 만든 사람이 원하는 대로 쓰지 않으니까요.2. 온톨로지는 흩어진 시스템의 지도유대훈 CTO님이 정의한 온톨로지는 거창하지 않습니다. 어떤 데이터는 어느 DB의 어느 테이블에 어떻게 접근하고, 어떤 데이터는 어느 시스템의 API를 불러야 하는지 모아 둔 지도예요. 에이전트는 그 지도를 보고 데이터를 찾아갑니다.모든 데이터를 한곳에 옮겨 그 위에 온톨로지를 쌓는 방식도 있지만, 거의 실시간으로 동기화하려면 큰 인프라가 들어요. 데이터 주권을 중요하게 여기는 중견기업도 많고요. 그래서 있는 시스템을 최대한 그대로 쓰는 쪽을 골랐다고 합니다.3. 형식 문법 대신 마크다운 글로문제는 온톨로지 문법이 개발자에게도 너무 어렵다는 거였어요. 그러다 클로드 스킬이 파일을 영리하게 다루는 걸 보고 마크다운이 사람과 AI 모두에게 다루기 좋다고 봤고, 안드레 카파시가 공유한 LLM 위키를 보며 연결 방법을 찾았습니다.안드레 카파시가 GitHub에 공개한 LLM 위키. LLM이 마크다운 위키를 직접 쓰고 이어 붙이는 방식을 설명한다. 이미지 출처 : GitHub다만 유대훈 CTO님의 경험으로는 목차가 200개를 넘으면 성능이 떨어졌대요. 그래서 목차는 트리로 만들어 DB로 관리하고, 그 내용을 다시 마크다운으로 렌더링해 에이전트에 넣습니다. 관계는 그래프 대신 페이지 속 문장으로 씁니다. 계약 관계든 공장과 라인의 관계든 말로 설명해 두면 LLM이 뒤에서 컴파일해 준다는 거예요. 그렇게 나온 이름이 제텔카스텐의 영어 이름, 슬립박스입니다.4. 용어의 정의와 하면 안 되는 일을 적는다DB를 인제스트하면 먼저 테이블 이름과 컬럼 이름을 보고, 약칭이라 알아보기 힘들면 데이터 일부를 샘플링해 뜻을 추정합니다. 유대훈 CTO님은 온톨로지의 앞단이 결국 그 분야에서 쓰는 용어와 그 정의라고 했어요. '이 용어는 이런 뜻'이라고 주면 LLM은 그때부터 그 뜻으로 받아들인다고요.하면 안 되는 일도 적습니다. 센서 데이터처럼 계속 쌓이는 테이블은 실수로 전체를 조회하면 메모리가 터지니, '누적 시계열이니 기간 필터를 걸어라' 같은 금칙을 남겨요. 자동으로 만든 페이지가 틀렸다면 노션이나 옵시디언 쓰듯 사람이 그 자리에서 고치면 됩니다.인제스트로 만든 페이지에 남은 조회 금칙. 누적 시계열 테이블은 기간 필터 없이 전체를 조회하지 말라고 적혀 있다. 이미지 출처 : 빌더 조쉬 YouTube5. 잘 바뀌었는지는 질문과 테스트로법률 문서처럼 글자 하나도 바뀌면 안 되는 자료는 원문을 그대로 잘라 넣고, 나머지는 토픽으로 나눠 트리 목차를 만듭니다. 변환이 잘 됐는지는 먼저 중요한 포인트를 직접 물어보고, 다음엔 벌크 테스트로 정답과 계속 비교해 확인해요. 테스트 입력을 만들기 어려우면 가칭 제로클릭 에이전트가 합성 데이터로 채팅 테스트를 대신 돌리고, 끝나면 에이전트를 어떻게 고치면 좋을지 가이드까지 준다고 합니다.에이전트리아 공식 문서의 인제스트 두 방식. 합성은 핵심을 재구성해 슬립을 만들고, 원문 보존은 규정이나 계약서처럼 정확성이 중요한 문서의 원문을 그대로 넣는다. 이미지 출처 : 에이전트리아 문서6. 바뀌는 주기로 RAG와 나눠 쓴다임베딩을 버린 건 아닙니다. 다만 몇천 쪽짜리 PDF를 임베딩해 뒀는데 임베딩 모델을 바꾸면 일부만 바꿀 수 없고 전부 다시 해야 해요. 에이전트를 돌리다 지식을 바로 고쳐야 하는 경우라면 고칠 때마다 다시 임베딩해야 하고요.그래서 기준은 바뀌는 주기입니다. 1년에 한 번 바뀌는 자료는 RAG가 빠르고 좋고, 주나 월 단위로 고치는 지식은 슬립박스로 글로 씁니다. 형식을 갖춘 온톨로지가 꼭 필요하면 이미 있는 시스템과 연결해요.7. Text-to-SQL에서 막힐 때는 한두 줄을 보탠다유대훈 CTO님에 따르면 최근 한 고객사는 똑같은 사업자 번호가 테이블마다 다른 뜻이었다고 합니다. 프롬프트에 다 넣기엔 양이 너무 많았지만, 테이블마다 페이지가 있으니 거기에 한두 줄만 넣으면 됐어요. 현업이 '이 데이터로는 못 하겠다' 싶을 때 빠진 부분만 글로 써 주는 것, 그게 에이전트를 빠르게 배포한 뒤 안정적으로 만들어 가는 방법이라고 봤습니다.테이블마다 뜻이 다른 사업자 번호. 프롬프트에 다 넣는 대신 해당 테이블 페이지에 한두 줄만 적는다. 이미지 출처 : 원인터뷰를 바탕으로 조쉬의 뉴스레터 재구성마지막으로 그는 AI가 아무리 뛰어나져도 책임은 사람이나 기업이 지게 될 거라고 했어요. 문제가 생기면 사람이 들어가 과정을 보고 고칠 수 있어야 한다는 거죠. 에이전트리아가 과정마다 입력값과 출력값을 다 볼 수 있게 해 둔 것도 디버깅을 위해서라고 합니다.딜 현황 보고 시연과 인제스트 화면, 인터뷰 전체 문답은 뉴스레터에 정리해 두었습니다.https://maily.so/josh/posts/10z37pnvolw조쉬의 뉴스레터는 AI와 함께 일하는 창업가·빌더의 인터뷰를 매주 보내 드려요.구독: https://maily.so/josh

앱을 40개 정도 만들면 그중에 뭐 하나라도 터지거나 반응이 있을 줄 알았습니다. 하지만 현실은, 앞으로 100개든 1000개를 만들더라도 세상은 내 앱을 몰라볼 것만 같은 두려움에 의욕도 떨어졌습니다. 주변 SNS를 살펴보면 비슷한 고민을 하시는 분도 많이 봤습니다. 대부분 글의 내용이 “개발보다 마케팅이 힘들다”, “알리기가 힘들다”, “마케팅이 진짜 허들이다” 이런 이야기였습니다. 그러면 내 앱은 정말 괜찮은데 마케팅을 잘 못해서 이 상황이라는 결론에 도달했습니다.하지만 저는 광고를 태우기 바로 직전에 또 다른 두려움이 머릿속에 떠올랐습니다. 마케팅을 하면 당연히 사람들이 많이 다운받겠지만, 그대로 앱을 다 삭제해 버릴지도 모른다는 생각이었습니다. 그래서 유효한 타겟 유저들에게 콜드메일을 돌리면서 조금씩 활성 유저를 늘려야겠다는 생각도 했고요.이때 지금 뭘 측정해보면 좋을지를 알게 되었는데, 그게 바로 Carrying Capacity였습니다.Carrying Capacity(캐링 캐패시티)는 원래 생태학에서 유래한 용어로, 특정 환경이 지속 가능하게 감당하거나 수용할 수 있는 ‘한계 수용 능력’을 뜻합니다. 최근에는 비즈니스 및 프로덕트(서비스) 분야에서도 제품의 본질적인 성장 체력을 뜻하는 핵심 지표로 활발히 쓰입니다.그래서 마케팅을 하든, 유효할 것 같은 타겟에게 앱을 전달하든 상관없이, 나의 프로덕트의 한계 수용 능력을 살펴보는 것이 중요해 보였습니다. 왜냐하면 돈을 쏟아부어도 다 빠져나가 버린다면 돈을 바닥에 버린 게 될 테니까요. 어느 정도는 Carrying Capacity를 확인해야 막연하게 불안해지지 않습니다.결국 나눗셈 하나였습니다개념은 거창한데 계산은 허무할 정도로 단순합니다.Carrying Capacity = 주기당 신규 유입 사용자 수 ÷ 주기당 이탈률예를 들어 보겠습니다. 하루에 신규 사용자가 10명 들어옵니다. 한 달이면 300명이죠. 그리고 한 달 뒤에 남아 있는 사람이 80%, 즉 이탈률이 20%라고 해봅시다.300 ÷ 0.2 = 1,500명이 앱은 1,500명 근처에서 멈춥니다. 오늘 사용자가 400명이든 900명이든, 지금의 유입과 지금의 이탈이 유지되는 한 이 앱은 1,500명 언저리로 수렴합니다. 그 위로도 안 가고, 아래로도 안 갑니다.여기서 잠깐 멈추고 한번 생각해 보시면 좋겠습니다. 광고를 태워서 신규 유입을 3배로 늘리면 어떻게 될까요?CC는 4,500명이 됩니다. 좋습니다. 그런데 광고를 끄면요? 유입이 원래대로 돌아가고, 앱은 다시 1,500명으로 천천히 미끄러집니다. 광고는 CC를 올린 게 아니라, 돈을 넣는 동안만 CC를 빌린 것입니다.반대로 이탈률을 20%에서 10%로 낮추면 CC는 3,000명이 됩니다. 신규를 두 배로 늘린 것과 똑같은 효과인데, 차이가 하나 있습니다. 이건 광고를 끄든 말든 남습니다.제가 이 나눗셈 앞에서 좀 서늘했던 이유분자는 돈으로 살 수 있습니다. 분모는 못 삽니다.그런데 저를 포함해서 “마케팅이 어렵다”고 말할 때, 우리는 거의 언제나 분자 이야기만 하고 있었습니다. 어떻게 알릴 것인가, 어디에 노출할 것인가, 얼마를 쓸 것인가. 나눗셈의 위쪽 절반만 붙들고 몇 달을 보낸 셈입니다.“내 앱은 괜찮은데 마케팅을 못해서 안 되는 것”이라는 진단이 왜 그렇게 매력적이었는지도 그제야 보였습니다. 그 진단은 제품에 무죄를 선고해 주거든요. 제 경험상, 어떤 진단이 나를 편안하게 만든다면 한 번쯤 의심해 볼 만합니다. 게다가 이 진단에는 더 큰 문제가 있었습니다. 반증할 방법이 없다는 것. “마케팅을 못해서”라는 가설은 광고비를 다 쓰고 실패한 뒤에도 “광고를 잘못 집행해서”로 무한히 도망갈 수 있습니다.Carrying Capacity가 좋았던 건 그걸 틀릴 수 있는 형태의 문장으로 바꿔 줬기 때문입니다. “내 앱은 지금 1,500명짜리 그릇이다.” 이건 재보면 맞는지 틀리는지 알 수 있습니다.욕조 이야기시스템 사고 쪽에서 자주 쓰는 비유가 있습니다. 도넬라 메도우즈가 『Thinking in Systems』에서 저량(stock)과 유량(flow)을 설명할 때 드는 욕조 비유입니다. 욕조에 담긴 물의 양은 수도꼭지와 배수구가 함께 정합니다. 수도꼭지를 아무리 세게 틀어도 배수구가 열려 있으면 물은 어느 높이에서 멈춥니다. 그 높이가 Carrying Capacity입니다.피터 센게가 정리한 시스템 원형 중에 ‘성장의 한계(Limits to Growth)’라는 게 있는데, 요지는 이겁니다. 성장이 멈췄을 때 사람들은 성장 엔진을 더 세게 돌리려 하지만, 정작 필요한 건 성장을 막고 있는 제약을 찾아 없애는 것이다.광고비는 성장 엔진을 세게 돌리는 쪽입니다. 리텐션은 제약을 없애는 쪽이고요. 저는 지난 몇 년간 앱 개수를 늘리는 방식으로 엔진만 계속 세게 돌리고 있었던 것 같습니다. 40개는 사실 40번의 같은 시도였지, 40번의 다른 실험은 아니었습니다.그런데 이탈률은 어떻게 재나요여기서 많이들 막힙니다. 저도 막혔고요.정석은 코호트입니다. 신규 사용자를 주 단위(또는 월 단위)로 묶어놓고, 1주 뒤·2주 뒤·4주 뒤에 그 그룹의 몇 %가 아직 앱을 열고 있는지 봅니다. Firebase든 Amplitude든, App Store Connect의 유지율 지표든, 이미 붙여둔 게 하나쯤은 있을 겁니다.그런데 이 지점에서 저는 제가 자주 빠지는 함정을 하나 발견했습니다. 정확하게 재려다가 이번 주에 아무것도 재지 않는 것.이탈률의 정의를 뭘로 할지, 앱 실행만으로 활성으로 볼지, 푸시로 들어온 건 세야 할지... 이런 걸 고민하다 보면 일주일이 그냥 갑니다. 거친 숫자라도 이번 주에 손에 쥐는 편이 훨씬 낫습니다. 어차피 우리가 알고 싶은 건 1,500명인지 1,530명인지가 아니라, 1,500명인지 15,000명인지니까요. 자릿수만 맞아도 다음 행동이 완전히 달라집니다.숫자가 나오면 셋 중 하나입니다1. CC가 지금 사용자 수보다 훨씬 크다. 그릇은 큰데 아직 안 찬 상태입니다. 이 경우엔 마케팅이 정답이 맞습니다. 부으면 담깁니다. 마음 놓고 태우셔도 됩니다.2. CC가 지금 사용자 수와 비슷하다. 평형에 도달했습니다. 여기서 쓰는 광고비는 물이 새는 욕조에 물을 붓는 일입니다. 이때 할 일은 광고 집행이 아니라 배수구를 찾는 겁니다.3. CC를 계산할 수 없다. 가장 흔한 경우입니다. 그리고 역설적으로 지금 할 일이 가장 명확한 경우이기도 합니다. 계산할 수 없다는 건, 우리가 지금까지 프로덕트의 상태를 모르는 채로 의사결정을 해왔다는 뜻이니까요. 저는 3번이었습니다.불안이 두려움으로 바뀌는 순간심리학에서 불안(anxiety)과 두려움(fear)을 구분할 때, 두려움에는 대상이 있고 불안에는 대상이 없다고 이야기합니다. 대상이 없기 때문에 불안은 다룰 수가 없습니다. 그냥 계속 안개처럼 깔려 있죠. “100개를 만들어도 안 될 것 같다”는 건 전형적인 불안입니다.측정의 진짜 효용은 여기 있었습니다. 측정은 불안을 두려움으로 바꿔 줍니다.“내 앱은 1,500명이 한계다”라는 문장은 처음 보면 절망적입니다. 그런데 이 문장은 막연한 절망보다 훨씬 낫습니다. 대상이 생겼으니까요. 1,500이라는 숫자는 곧바로 다음 질문을 만들어 냅니다. 이 1,500을 3,000으로 만들려면 이탈률을 절반으로 줄여야 하는구나. 그러면 사람들은 대체 어디서 나가고 있지? 첫날인가, 3일째인가, 아니면 특정 화면인가?그리고 이 질문들에는 답을 해볼 수 있습니다.숫자는 어디가 아픈지만 알려줍니다다만 Carrying Capacity가 알려주는 건 ‘어디가’ 아픈지까지입니다. ‘왜’ 아픈지는 절대 알려주지 않습니다.이탈률 20%라는 숫자는 그 20%가 왜 떠났는지 한마디도 해주지 않습니다. 그래서 저는 이 계산 다음에 할 일을 이렇게 정했습니다. 떠난 사용자 5명과 이야기해 보는 것. 정량은 상처의 위치를, 정성은 상처의 이유를 알려줍니다. 둘 중 하나만 있으면 대개 엉뚱한 곳을 고치게 됩니다.이 지표의 함정도 적어둡니다솔직하게 한계도 적는 게 맞을 것 같습니다.CC는 예측이 아니라 거울입니다. “지금 상태가 그대로 유지된다면”이라는 무거운 가정 위에 서 있는 숫자입니다. 미래를 맞히려고 쓰는 게 아니라 현재를 보려고 쓰는 겁니다.바이럴이 있으면 모델이 달라집니다. 사용자가 사용자를 데려오는 구조라면 유입이 사용자 수에 비례하기 때문에 단순 나눗셈으로는 안 잡힙니다.앱이 여러 개면 앱마다 따로 재야 합니다. 40개의 평균 CC 같은 건 아무 의미가 없습니다. 오히려 40개 중 CC가 가장 높은 하나를 찾는 데 쓰는 게 낫습니다. 어쩌면 이게 제 경우엔 가장 큰 쓸모일지도 모르겠습니다. 40개를 다 살릴 게 아니라 어느 하나에 집중할지를 고르는 자.가장 위험한 함정은, 재는 게 목적이 되는 겁니다. 대시보드를 예쁘게 만드는 데 2주를 쓰고 정작 이탈률은 하나도 안 줄이는 상황. 저는 이걸 여러 번 해봤습니다.이번 주에 해볼 만한 것거창하게 안 하고 각각 30분씩 잡고 이렇게 해보려 합니다.앱 하나를 고른다. 클립 키보드가 가장 활발하니 이걸 골랐습니다.월 신규 유입 수와 30일 잔존율을 찾는다. 정확하지 않아도 됩니다. 자릿수만 맞으면 됩니다.나눠본다. 그리고 그 숫자를 현재 사용자 수 옆에 나란히 적어둔다.떠난 사용자 5명에게 말을 건다. 여기까지 하면, 적어도 “지금 뭘 해야 할지 모르겠다”는 상태에서는 벗어납니다.마지막으로 하나만 여쭤보고 싶습니다지금 여러분의 프로덕트는 몇 명을 담을 수 있나요?이 질문에 숫자로 답할 수 없다면, 아마 광고비를 쓰기 전에 해야 할 일이 하나 남아 있는 겁니다. 저처럼 40개를 만들고 나서 이 나눗셈을 하지 마시고, 지금 만들고 계신 그 앱에서 먼저 해보시면 좋겠습니다.10분이면 됩니다. 저는 그 10분이 지난 2년보다 많은 걸 알려줬습니다.