SYDESYDE
SYDESYDE
  • 피드
  • 쇼케이스
  • 블로그
  • 모임
SYDESYDE© 2026 SYDE. All rights reserved.
SYDE 소개문의하기
Kakao
SYDE 오픈채팅
Instagram
Instagram
Threads
Threads
커뮤니티 가이드라인협업문의이용약관개인정보처리방침
커뮤니티 가이드라인협업문의이용약관개인정보처리방침

© 2026 SYDE. All rights reserved.

We are SYDERS

주체적인 삶으로 가득한 세상,
1400+명의 SYDER와 함께해요.

지금 주목받는 프로젝트 🔥

ⓒ 2026. SYDE

KakaoInstagramThreads
banner_instagram
하루들
이 주의 SYDE Pick

하루들

우리끼리 통하는 네컷만화

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

지금 주목받는 프로젝트 🔥

User Avatar
무슨 생각을 하고 계신가요?
김해준

김해준님이 쇼케이스를 등록했어요· 3시간 전

Showcase thumbnail

한잔 기록

마신 위스키의 맛과 느낌을 남기는 토스 미니앱 시음 노트

Ever

Ever님이 쇼케이스를 끌어올렸어요· 4시간 전

Showcase thumbnail

WithDraw

가족/친구/연인과 함께 그려보세요.

Ever

Ever님이 블로그 글을 발행했어요· 4시간 전

못 그릴 수록 더 재미있는 게임 WithDraw 개발 & 운영이야기 - 1

AI의 등장으로 무엇이 달라졌는가..Claude Code와 Codex 같은 AI 에이전트가 등장하면서, 떠올린 아이디어를 빠르게 앱으로 만들 수 있게 됐다. 나도 무언가 만들어보고 싶어 이것저것 시도했다. 하지만 돌아보면 남들이 이미 만든 기능을 비슷하게 구현하거나, 별로 필요하지도 않은 기능을 덧붙이는 일이 많았다. AI가 없었다면 굳이 시작하지 않았을 것들을 만드는 데 업무 밖의 시간을 쏟고 있었다.원래 나는 무언가를 만드는 걸 좋아했다. 만들고 싶은 것이 생기면 필요한 기술을 배우는 일에도 푹 빠졌고, 그렇게 개발자가 됐다. 외주와 취업, 이직을 거치며 지금까지 개발을 이어왔지만, 어느새 내가 원하는 기능을 고민하기보다 이미 정해진 기획을 구현하는 데 익숙해졌다.AI를 활용하는 기술도 많이 배웠다. 새로운 도구를 익히고, 더 빠르게 만드는 방법을 공부했다. 하지만 배운 기술을 제대로 써볼 곳은 찾지 못했다. 무엇을 위해 공부하고, 무엇을 위해 AI를 써야 하는지 답이 보이지 않아 답답했다. 만드는 방법은 계속 늘어났는데, 정작 내가 만들고 싶은 것은 무엇인지 모르고 있었다.아이디어 구상하기.그러다 내가 실제로 즐거웠던 순간을 떠올려봤다.아내는 그림을 잘 그리는 편이지만, 나는 살면서 그림을 잘 그려본 적이 없다. 그래도 데이트 중 카페에서 가끔 Procreate를 열어 서로의 모습을 그려주거나, 같은 주제로 그림을 그릴 때면 즐거웠다. 같은 것을 그려도 한 사람은 제법 그럴듯하게, 다른 한 사람은 엉뚱하게 그렸다. 조금 부끄럽기도 했지만, 서로의 그림을 보며 웃는 시간이 좋았다.그렇다면 한 그림을 여러 사람이 나눠 그리면 어떨까? 누가 어느 부분을 그렸는지에 따라 예상치 못한 그림이 완성될 테고, 함께 웃을 일도 더 많아질 것 같았다. 그렇게 한 화면에서 여러 사람이 하나의 그림을 함께 그리는 앱이라는 아이디어가 떠올랐다.WithDraw아이디어에 이름을 붙였다. With는 함께, Draw는 그리다. 여러 사람이 함께 그림을 그린다는 뜻을 담아 WithDraw라고 지었다. ‘출금’이나 ‘철회’를 뜻하는 withdraw와 철자가 같아 헷갈릴 수도 있지만, D를 대문자로 써서 ‘그리다’라는 의미를 드러냈다.그렇게 한 화면을 참여 인원에 따라 나누고, 모두가 하나의 그림을 완성하는 앱을 개발하기 시작했다. 두 명이 그릴 수도 있고, 세 명, 네 명, 많게는 여덟 명까지 함께 그릴 수 있다.WithDraw가 좋은 아이디어인지 처음부터 확신했던 건 아니다. 다만 아내와 그림을 그리며 웃었던 시간을 다른 사람들과도 나눠보고 싶었다. 이번에는 AI로 만들 수 있으니까 시작한 것이 아니라, 직접 써보고 싶은 것이 생겨서 AI의 도움을 받아 만들기 시작했다.그렇게 막연히 무언가를 만들어야겠다는 답답함에서 벗어나, 내가 즐거웠던 경험을 하나의 앱으로 옮기게 됐다. 앞으로 이 앱을 만들면서 어떤 고민을 했고, 실제로 함께 그려보니 무엇이 달랐는지 기록해보려 한다.

Blog thumbnail
덩쿠리

덩쿠리님이 블로그 글을 발행했어요· 15시간 전

싼 주유소까지 가는 기름값도 계산해야 하지 않을까?

주유소를 고를 때 가장 먼저 보게 되는 건 리터당 가격입니다. 저도 그 숫자를 기준으로 비교하다가, 한 가지가 마음에 걸렸습니다.조금 더 싼 곳까지 가는 데 쓰는 기름값을 더하면, 그래도 그곳이 쌀까?가격 차이가 크면 고민이 덜하겠지만, 몇 원 차이라면 이야기가 달라집니다. 얼마나 멀리 가는지, 차의 연비가 어떤지, 이번에 얼마나 넣을 건지에 따라 답이 바뀔 수 있으니까요.실주유는 이 질문에서 출발한 사이드 프로젝트입니다. 근처 주유소를 리터당 가격뿐 아니라, 이동에 드는 연료비와 주유비를 합친 금액으로 비교하는 모바일 웹앱입니다.‘제일 싼 곳’의 기준을 조금 바꿨습니다계산의 기본은 단순합니다.비교 비용 = 주유할 금액 + 그 주유소까지 이동하는 데 드는 연료비주유할 금액은 주유량에 해당 주유소의 리터당 가격을 곱합니다. 이동 연료비는 거리와 차량 연비로 필요한 연료량을 구하고, 해당 주유소의 가격을 적용해 추정합니다. 현재는 편도 기준입니다.예를 들어볼게요. 아래 숫자는 실제 주유소 정보가 아니라 계산을 설명하기 위한 가상 예시입니다.연비가 10km/L인 차에 20L를 넣는다고 해보겠습니다.A 주유소: 1km 거리, 리터당 1,700원 → 주유비 34,000원 + 이동 연료비 170원 = 34,170원B 주유소: 4km 거리, 리터당 1,690원 → 주유비 33,800원 + 이동 연료비 676원 = 34,476원리터당 가격은 B가 10원 저렴하지만, 이 조건에서는 A의 합계가 더 낮습니다. 반대로 더 많은 양을 넣으면 리터당 가격 차이가 커져 결과가 달라질 수도 있습니다.그래서 실주유에서는 유종과 연비뿐 아니라 주유량도 함께 입력하도록 했습니다. 같은 위치에서도 차와 주유량에 따라 선택이 달라질 수 있다는 점을 비교에 담고 싶었습니다.물론 이 금액이 실제 결제액과 이동 비용을 정확히 예측하는 것은 아닙니다. 교통 상황이나 실제 주행 연비에 따라 달라지고, 시간·통행료·카드 할인까지 모두 합친 비용도 아닙니다. 여기서 말하는 ‘총비용’은 주유비와 편도 이동 연료비를 합친 비교용 추정치입니다.처음에는 현재 위치만 있으면 될 줄 알았습니다첫 버전에서는 브라우저의 위치 API로 GPS 위치를 받아 주유소를 찾도록 했습니다. 지금 있는 곳에서 가까운 주유소를 고르는 서비스라면, 현재 위치를 바로 가져오는 흐름이 자연스럽다고 생각했습니다.그런데 기준 위치를 현재 위치로만 고정하면 활용할 수 있는 상황이 좁아집니다.집에서 출발하기 전에 회사 근처 주유소를 비교하고 싶을 수도 있고, 다른 동네에 들를 예정이라 그 주변을 먼저 보고 싶을 수도 있습니다. 이럴 때 필요한 건 ‘내가 지금 있는 곳’이 아니라 ‘내가 비교하고 싶은 곳’입니다.그래서 주소 검색 API를 연결해 현재 위치가 아닌 장소도 검색할 수 있도록 추가했습니다.GPS는 바로 주변을 찾을 때 쓰고, 다른 곳을 기준으로 보고 싶을 때는 주소를 검색하는 방식입니다. 여기서의 주소 검색은 비교할 기준 위치를 바꾸는 기능입니다. 이동 경로 전체에서 최적의 주유소를 찾아주는 기능과는 범위가 다릅니다.이 변경을 하면서 서비스 이름이나 계산식보다, 사용자가 검색을 시작하는 순간을 더 생각하게 됐습니다. ‘위치를 가져온다’는 개발 단계의 설명 안에도, 사용자가 원하는 위치가 무엇인지에 대한 선택이 숨어 있었습니다.비교하고, 고르고, 익숙한 지도로 출발하기주유소 가격은 오피넷 데이터를 기반으로 가져옵니다. 사용자가 유종·연비·주유량을 설정하면 주변 주유소의 비교 비용을 계산해 순서대로 보여줍니다.이동 연료비와 주유비도 나눠 보여줍니다. 리터당 가격이 더 높은 주유소가 위에 있을 때, 왜 그런 결과가 나왔는지 볼 수 있어야 하기 때문입니다.설정은 로그인 없이 브라우저에 저장하고, 주유소를 고른 뒤에는 카카오·네이버·구글 지도 길찾기로 이어지도록 했습니다. 주유소를 비교한 다음 실제로 출발하는 흐름까지 연결한 셈입니다.작은 질문을 끝까지 따라가 보기실주유를 소개할 때 결국 다시 돌아오는 질문은 처음과 같습니다.“저기가 조금 더 싼데, 거기까지 가는 비용을 더해도 그럴까?”이 질문을 계산으로 옮기고 나니 연비와 주유량이 필요해졌고, 실제로 쓸 상황을 생각하니 현재 위치 외에 주소 검색도 필요해졌습니다. 간단한 아이디어도 사용 장면을 하나씩 따라가다 보면 챙길 것이 생기더라고요.아직 모든 주유 상황을 해결하는 서비스는 아닙니다. 그래도 주유소를 고를 때 한 번쯤 머릿속으로 해봤을 계산을, 조금 더 편하게 확인할 수 있는 도구가 됐으면 합니다.직접 써보신다면 어떤 위치를 기준으로 검색하셨는지, 고르는 데 부족했던 정보는 무엇인지 궁금합니다. 그런 이야기를 다음 개선의 재료로 삼고 싶습니다.실주유 사용해보기

Blog thumbnail
Full-Moon

Full-Moon님이 쇼케이스를 등록했어요· 17시간 전

Showcase thumbnail

차트퀘스트

과거 실제 주식 차트에서 가상으로 매매하고, 20거래일의 결과를 빠르게 확인하는 게임

Chaesang Jung

Chaesang Jung님이 블로그 글을 발행했어요· 21시간 전

별 하나 뒤의 계산들 — 별점이 랭킹에 반영되는 방식

미국에서 맛집을 찾을 때는 yelp를, 일본에서는 타베로그를 열었다. 자연스럽게 나라마다 믿고 찾는 곳이 따로 있었는데, 그 총점의 눈금부터가 서로 달랐다. 타베로그에서 3.5는 최정상급 맛집이라는 뜻이었지만, yelp에서 같은 3.5는 그만한 집이 아니라 했었다. 맛집이라는 같은 물음을 두고도 나라를 넘으면 비교가 어려운데, 같은 다섯 개의 별처럼 보여도, 그 대표 점수가 만들어진 공식은 해당 나라의 사용자들에게 묶여 있었던 셈이다. 이걸 시스템이 받아 하나로 단순화해서 진행하려 하면 뭔가 생각대로 잘 안 풀렸는데, 지난 몇몇 과제들에서 여러 번 만났었다.별점을 처음 다룬 것은 rich snippets 과제에서였다. 검색 결과 밑에 영화 평점을 끌어다 붙이는 일이었는데, 나라별 점수를 뜯어보니 같은 부류의 영화라도 일본 쪽이 미국 쪽보다 낮게 깔렸다. 처음엔 헐리우드에 기운 bias인가 싶었는데, 헐리우드 영화 하나를 두고 나라를 건너가며 점수를 늘어놓아도, 그 평균과 분포는 또 제각각이었다. 그럼 이건 '국민성'이라고 불러야 하나. 어느 나라 사람들이 원래 별을 짜게 준다는 식으로. 그 이름을 붙이려다 매번 멈칫했다. 국민이 별점을 그렇게 주도록 길든 것인지, 별점이 국민을 그렇게 길들인 것인지, 무엇이 먼저인지 알 수 없었지만, 다만 다르다는 것만은 분명했다.사실 그 rich snippets라는 것부터가, 별점을 검색 순위에 넣지 못해 나온 타협이었다. 웹 검색 순위에 넣으려면 모든 문서에 똑같이 적용할 수 있어야 하는데, 별점이 달린 문서가 세상에 몇이나 되겠는가. 그래서 검색은 순위 대신 결과 밑 회색 한 줄로 최신 별점만 얹어 두는 쪽으로 물러섰다. 회색 한 줄이 얼마나 한다고 생각했지만, 구글 검색에서 추가적인 한 줄은 의미가 어마어마한 것이어서 엄청나게 많은 실험을 해야만 했었다. IMDb의 10점과 RottenTomatoes의 100점을 별 다섯 개 눈금에 어떻게 맞출 것인가부터가 일이었고, 개별 리뷰와 그것들을 합친 총점은 서로 다른 물건이라, 그 총점을 단순 산술 평균으로 낼 것인가를 두고도 오래 실랑이들이 있었다. 당시 구글이 Zagat을 인수하던 즈음 별점 관련한 것들이 교통정리가 되었던 기억이다.그런데 나라마다 다르다는 걸 인정하고 나면 얼마나 더 잘게 쪼개어 볼 것인가라는 이슈로 뒤가 조금 더 곤란해지곤 한다. 나라로 가르면 충분할 듯하다가도, 같은 나라 안에서 도시와 시골이 다르고 서울과 부산이 다를 텐데, 어디까지 내려가야 맞는 걸까. 영화는 어느 단위가 적당하고, 맛집은 또 어디까지 쪼개야 하며, 앱이라면 또 어떤가. 답은 하나로 떨어지지 않았고, 개발 직군은 그 요구가 어디까지 내려오든 묵묵히 최선을 다해야만 했었다.여기서 글로벌 회사가 흔히 빠지는 함정이 있다. 공식을 하나 만들면 그것이 모든 나라에 똑같이 통해야 한다고 여기는 것이다. 아이러니하지만 코드가 단순해지니까 이해는 가는데, 별점뿐 아니라 거의 모든 피쳐들에 대해 매번 논쟁이 된다. 한국에서 점수를 끌어올리던 신호가 미국에서는 도리어 끌어내리곤 했고, 당연히 그 반대의 경우들도 있다. 그래서 이런 건 과제를 launch하기 전에 협상의 대상이 되었다. 나라마다 예외를 둘 것인가, 아니면 하나의 공식으로 밀어붙이고 어긋나는 나라는 감수할 것인가. 예외를 하나 열면 그다음 나라가 손을 들고, 그렇게 특례가 쌓이면 어느새 아무도 손대지 못하는 코드가 된다. 편의를 따라 나라별 분기를 늘리다 보면 그게 고스란히 기술 부채로 돌아온다는 걸 알기에, 그 부채를 지지 않으려고 여럿이 오래 매달렸다. 어느 것도 공짜가 아니었다.별점에 대해서는 나라만 축인 것은 아니고, 시간도 중요한 축이었는데, 오래된 서비스일수록 오래된 리뷰를 얼마나 인정해 줄지가 문제였다. 무작정 요즘 것이 낫다고 할 수도 없으니, 이 가중치를 어떻게 줄지에는 오래 장사를 해 본 곳들이 저마다 감춰 둔 셈법이 있었고, 산술 평균으로 짐작되는 평균이라는 하나의 숫자 뒤에는, 어느 시절의 목소리에 얼마나 무게를 둘 것인가 하는 또 하나의 판단이 복잡하게 숨어 있었다.영화 리뷰로 한참 고민하다 꽤 시간이 지나, 비슷한 문제를 앱 스토어에서 다시 만났다. 앱은 나라에 묶여 출시되는데, 별점은 그 앱을 내려받은 사용자가 제 나라와 제 언어를 묻혀 남긴다. 나라별로 평균을 내 보면 값이 사뭇 달라서, 특히 여기서도 한국과 일본을 견주면 일본 쪽이 유독 짜게 나오곤 했다. 그리고 한국에는 지난번에 적었던, 불만이면 낮췄다가 해결되면 높여 주는 문화가 있었다. 각 나라마다 사정이 있었던 건지, 이게 진짜 사람의 마음인지 누가 심어 둔 별인지까지 따지기 시작하면, 셈은 한층 복잡해졌다.플레이스토어 내에서는 같은 부류의 문서들을 다루니, 검색과 달리 별점을 간접적인 품질 신호로 순위에 쓸 수는 있었다. 막상 쓰려면 또 복잡해지는데, 글로벌 총합이야 엔트리 하나면 되지만, 이걸 locale로 펼치면 마흔 개 언어에 백 개 나라의 몫이 필요했다. 내려받고, 눌러 보고, 지워 버리는 온갖 숫자들과 비율까지 함께 얹으면, 이걸 serving하는 인프라가 감당하기 어려운 일이 되었다. 앞서 얼마나 잘게 쪼갤 것이냐고 물었던 그 물음이, 여기서는 고스란히 비용으로 돌아왔다. 별점을 나라별 신호로 쓸 것인가 글로벌 총합으로 쓸 것인가는, 품질과 인프라 측면 모두 난이도가 상당한 셈이다.별 다섯 개는 세상에서 가장 단순한 언어처럼 보인다. 그러나 그 한 줄짜리 숫자를 시스템 안으로 들이는 순간, 나라와 언어와 문화가 저마다의 무게로 되살아났다. 나라와 언어가 끝내 하나로 포개지지 않더라는 이야기를, 별점만큼 또렷하게 보여준 것도 드물지 싶다.이 글은 '나라와 언어 사이'라는 연작의 한 편입니다. 원문과 나머지 편은 브런치에 있습니다 → https://brunch.co.kr/@chaesang/199

Blog thumbnail
ㄲㄱ

ㄲㄱ님이 블로그 글을 발행했어요· 1일 전

유료 테스터 7일, 아무도 돈을 내지 않은 이유

Retry는 "작심삼일은 의지력 문제가 아니라 패턴 문제"라는 생각에서 출발했습니다. 습관을 체크인할 때마다 추리 사건의 단서가 하나씩 열리고, 7일이 지나면 범인과 함께 내 실패 패턴 리포트가 열리는 구조예요. 혼자 기획하고, 개발하고, 사건 콘텐츠는 LLM 파이프라인으로 만들었습니다.어느 정도 모양이 갖춰졌을 때 가장 무서웠던 건 "지인 피드백"이었습니다. "오, 신기하네요"라는 말은 아무것도 검증해주지 않으니까요. 그래서 테스터 두 분께 각각 10만 원을 드리고 7일 동안 써달라고 부탁했습니다. 조건은 하나였어요. 칭찬보다 불편했던 점을 솔직하게 말해달라는 것.7일 뒤 마지막 질문은 이거였습니다."유료 사건이 나온다면 돈을 내시겠어요?"두 분 다 "아니오"라고 답했습니다.■ 무엇을 검증하려 했나제 가설은 단순했습니다. 습관 트래커는 이미 너무 많다. 그러니 추리 사건을 보상으로 붙이면, 범인이 궁금해서라도 사람들이 매일 체크인하러 올 것이다.이 가설에서 추리는 습관을 만들기 위한 "미끼"였습니다. 주인공은 트래커였고요.■ 무엇이 틀렸나1. 유저는 처음부터 추리를 보러 왔다첫 화면을 보고 한 분은 "습관보다 추리에 무게가 실린 서비스"라고 느꼈고, 다른 한 분은 웹소설이나 인터랙티브 소설 게임을 떠올렸습니다. 저는 미끼라고 생각했는데, 유저에게는 그게 본론이었던 거죠.2. 체크인이 몰입을 끊는 브레이크가 됐다"1목표 = 1단서 = 하루 1회" 규칙이 문제였습니다. 이야기에 빠진 사람일수록 단서를 더 원하는데, 하루에 하나만 열리니 강제로 멈춰야 했습니다. 결국 선택지는 세 가지뿐이었어요. 단서를 받으려고 억지로 목표를 늘리거나, 있는 정보로만 풀거나, 그냥 떠나거나. 한 분은 체크인이 없었다면 오히려 더 많이 했을 거라고 답했습니다.3. 체크인을 안 해도 범인이 보였다기본 단서 세 개만으로도 범인을 맞힐 수 있었습니다. 친절하게 붙여둔 (기회)(동기)(흉기) 라벨은 사실상 정답 힌트였고요. 한 분은 승부욕이 생겨서 일부러 추가 단서 없이 풀었다고 했습니다. 단서가 필요 없으니 체크인할 이유도 사라졌습니다.4. 사건이 하나의 템플릿처럼 반복됐다배경만 바뀌고 매번 "원한에 의한 교살"이었습니다. 용의자와 피해자의 관계도, 범행 동기("비판당했다", "무시당했다")도 문법처럼 똑같았어요. 한 분은 AI로 만든 사건이라는 걸 바로 알아챘습니다. 지불 의사를 물었을 때 두 분의 이유도 같았습니다. 돈을 낼 만큼 재미있는 사건이 없었다는 것.그런데 두 분 다 한 문장을 덧붙였습니다."정말 몰입할 만한 사건이라면 돈을 낼 수도 있다."■ 의외의 칭찬, 그리고 반대로 간 이유혹평 끝에 예상 못 한 말도 있었습니다. 일주일 동안의 기록을 보고 시간대를 바꿔보라고 추천해주는 리포트, 실패를 다시 시도로 이어주는 습관 트래커 기능은 정말 의미 있었다는 평가였어요.교과서대로라면 칭찬받은 트래커를 남기고 추리를 덜어내는 게 맞습니다. 그런데 저는 반대로 갔습니다.첫째, 습관 트래커는 레드오션입니다. 리포트가 좋아도 이미 잘 만든 앱이 너무 많고, 테스터 한 분 말처럼 웹에서 기록만 하는 서비스는 3~4일이면 늘어나는 탭에 밀려 잊혀집니다.둘째, 사람들을 처음 끌어들인 것도, 돈을 낼 수도 있다는 조건도 전부 "사건의 퀄리티"를 가리키고 있었습니다.추리는 습관 앱에 얹는 부록이 아니었습니다. Retry가 살아남으려면 사건 자체가 돈을 내고 볼 만한 콘텐츠여야 했어요. 그래서 지금은 트래커가 아니라 추리 콘텐츠에 집중하고 있습니다. 템플릿처럼 굴러가던 사건 생성 파이프라인을 처음부터 다시 설계하고, 동기와 수법을 다양하게 만들고, 텍스트만 쏟아내던 화면을 바꾸는 중입니다.웹도 접었습니다. 테스터 한 분이 짚었듯, 웹에서는 아무리 홈 화면에 추가하라고 안내해도 결국 탭에 밀려 잊혀지더라고요. 그래서 지금은 추리 콘텐츠를 중심에 둔 iOS 앱으로 다시 만들고 있습니다. 알림으로 다음 사건을 놓치지 않게 하고, 텍스트만 쏟아내던 화면 대신 사건에 더 빠져들 수 있는 화면을 만드는 게 목표예요.지금 개발 중인 iOS 앱 화면■ 7일 동안 배운 것10만 원씩 두 번, 20만 원을 내고 산 건 "아니오"라는 대답이었습니다. 그런데 그 "아니오" 안에 다음에 뭘 해야 하는지가 다 들어 있었어요. 제가 미끼라고 생각했던 게 사실은 본론이었습니다. 이 글을 읽는 분들의 사이드 프로젝트에도 내가 부록이라고 생각하는 기능이 사실은 유저가 찾아온 이유일지도 모릅니다. 그걸 확인하는 가장 빠른 방법은, 돈을 드리고 솔직한 "아니오"를 듣는 것이었습니다.https://retry.day

Blog thumbnail
하루들

하루들님이 블로그 글을 발행했어요· 2일 전

기록에서 공유로, 하루들 리브랜딩 이야기

안녕하세요 하루들입니다!지난 글에서도 이야기했듯이, 하루들은 사진으로 남기지 못한 순간을 그림으로 기록해보자는 생각에서 시작했어요. 그래서 처음에는 ‘그림일기’라는 이름으로, 사람들이 자신의 하루를 남길 수 있도록 돕고 싶었어요.저희는 사람들이 하루들을 일기장처럼 꾸준히 사용하길 기대했어요. 어떻게 하면 매일 들어와 기록할까 고민했고, 연속으로 기록한 날을 보여주는 기능도 추가했었죠.연속 기록 기능그런데 실제 사용자들의 이야기를 들어보니, 저희가 생각했던 것과는 조금 다른 이유로 하루들을 찾고 있었어요. 이번 글에서는 그 이야기를 듣고 하루들의 방향을 어떻게 다시 정했는지, 그리고 서비스 안의 문구는 어떻게 바꾸었는지 이야기해보려고 해요.사용성 테스트를 통해 기록이 메인이 아님을 알아내다9월 14일부터 18일까지 5일 동안, 사람들이 하루들을 사용하는 이유를 알아보기 위해 6명에게 직접 사용성 테스트(Usability Test, UT)를 요청했어요. 사용자들이 하루들을 어떻게 사용하는지 관찰하고, 왜 그렇게 사용하는지 질문했죠.결과는 꽤 충격적이었어요. 저희가 핵심 가치로 생각했던 ‘기록’을 주된 목적으로 사용하는 사람은 없었거든요. 가장 활발하게 사용해주시던 분도 평소 기록하는 습관은 없다고 하셨어요.특히 인터뷰에 참여한 6명 모두, 누군가에게 공유하려고 하루들을 사용한다고 이야기했어요. 자신의 이야기가 어떤 만화로 나올지 궁금한 재미도 있었지만, 공유할 대상이 없다면 만화를 만들 생각도 들지 않는다고 했죠. 저희는 사람들이 매일 기록하러 들어오길 기대했는데, 실제 사용자들은 누군가에게 보여주고 싶은 일이 생겼을 때 하루들을 찾고 있었던 거예요.사실 UT를 진행하기 전까지는 팀 안에서도 “우리가 사용자에게 주고 싶은 핵심 가치는 무엇일까?”라는 질문에 명확하게 답하기 어려웠어요. 이번에 사용자들의 이야기를 듣고 나니, 하루들의 방향을 다시 생각해볼 실마리가 생겼어요.기록에서 공유로UT 이후 팀 내부 회의를 진행했고, 결국 하루들의 핵심 가치를 “기록”에서 “공유”로 옮기기로 했어요. 만화를 만들어두는 것에서 끝나는 게 아니라, 누군가에게 보여주고 함께 즐기는 경험에 더 집중하기로 했습니다.공유할 대상이 없으면 만화를 만들 생각도 들지 않는다는 말에서, 저희는 그 상대와의 관계에 조금 더 주목했어요. 어떤 사람들과 일상을 나누기에 만화로 만들고 싶어지는지 알아보기 위해, 실제로 만화가 공유되는 공간을 들여다봤어요.같은 상황에 처한 사람들 사이의 공유가 중요하다지금 하루들이 가장 많이 사용되고, 사람들이 가장 재미있게 즐기고 있는 곳은 우아한테크코스예요. Slack의 그림일기 공유방에서는 자신의 만화를 올리고 다른 사람의 만화를 구경하고 있어요. 직접 많이 만들지 않아도 다른 사람의 만화를 보는 재미로 공유방을 찾는 분들도 있었죠.그래서 저희는 우테코(우아한테크코스)에서 사람들이 하루들을 즐기는 이유를 조금 더 들여다봤어요. 그 과정에서 서로의 상황을 어느 정도 알고 있다는 점에 주목했어요.우테코에서는 매일 같은 공간에서 생활하고, 비슷한 미션을 하며 함께 겪는 일이 계속 생겨요. 모두가 친한 사이는 아니어도 서로의 이름이나 닉네임은 어느 정도 알고 있고요. 그래서 그 자리에 직접 없었더라도 누구의 이야기인지, 어떤 상황에서 벌어진 일인지 이해하기 쉬웠어요. 짧은 네컷만화만으로도 이야기가 통할 수 있었던 거죠.저희는 이런 공통된 맥락을 가진 사람들 사이에서 만화를 나누며 얻는 즐거움과 공감에 집중하기로 했어요.우리끼리 통하는 네컷만화이 방향을 바탕으로 저희는 하루들을 “일상을 글 대신 네컷만화로 표현하도록 돕는 서비스”로 정의했어요. 그 경험을 통해 사용자에게 주고 싶은 가치는 일상의 새로운 발견, 즐거움과 공감으로 정했고요.이를 담은 태그라인이 “우리끼리 통하는 네컷만화”예요. 같은 맥락을 공유하는 사람들 사이에서 일상을 네컷만화로 주고받는 경험을 표현하고 싶었어요.사담이지만, 이번 논의에서 가장 오래 걸린 건 태그라인을 정하는 일이었어요. 짧고 간단했으면 좋겠고, 위트도 있었으면 좋겠고, 그러면서 이 한 문장으로 하루들이 어떤 서비스인지 설명할 수 있어야 했거든요. 담고 싶은 건 많은데 표현은 심플했으면 하니, 한 줄을 정하는 게 생각보다 어렵더라고요.그래도 태그라인을 정하고 나니, 그동안 팀원들이 조금씩 다르게 생각했던 하루들의 핵심 가치가 한 문장으로 모이는 느낌이었어요. 각자 고민했던 것들과 지금까지 시도한 실험들도 서로 연결되어 보였고요. 막연했던 서비스의 방향이 또렷해지면서, 이제 함께 어디를 바라봐야 할지 알 것 같았어요.다음 타겟은 부트캠프하루들은 공통된 맥락을 가진 다양한 집단에서 일상을 네컷만화로 나누는 경험을 목표로 해요. 학교나 회사, 동아리처럼 서로의 이야기가 통하는 곳에서 즐거움과 공감을 나눌 수 있도록요. 그 목표를 향한 첫 타겟은 하루들을 가장 활발하게 사용하는 우테코와 비슷한 환경을 가진 오프라인 부트캠프 참여자로 정했어요. 분야와 관계없이, 자주 만나고 함께 겪는 일이 생기는 집단부터 집중해보기로 한 거예요.앞으로는 공유 경험을 강화하기 위해 스레드와 비슷한 형태의 피드와 카테고리 기능을 개발할 예정이에요. 하지만 그전에, 새로 정한 브랜딩에 맞춰 기존 서비스의 문구부터 다듬기로 했어요.UX 라이팅의 변화방향을 정하고 기존 화면을 다시 보니, 여전히 ‘그림일기’와 ‘기록’을 중심으로 설명하고 있었어요. 같은 콘텐츠를 어떤 화면에서는 ‘그림일기’, 다른 화면에서는 ‘네컷일기’라고 부르기도 했고요. 저희가 정한 방향을. 사용자에게 전달하려면, 실제로 접하는 문구부터 맞춰야 했어요.그래서 서비스의 UX 라이팅과 랜딩페이지를 전면 개편했어요. 랜딩에서는 ‘우리끼리 통하는 네컷만화’라는 태그라인을 중심으로 하루들이 어떤 서비스인지 소개하도록 바꿨어요.수정 전/후 랜딩바뀐 랜딩은 더 길지만, 여기에서는 일부만 소개할게요서비스 안에서 사용하는 용어도 통일했어요. 완성된 콘텐츠는 ‘네컷만화’, 표현하고 싶은 경험은 ‘순간’으로 정했습니다. 여기에 ‘줄거리’처럼 만화를 떠올리게 하는 표현을 사용하고, 콘텐츠 개수와 생성 가능 횟수를 안내하는 단위도 ‘편’으로 맞췄고요.아래는 UX라이팅이 적용된 서비스의 모습입니다. 전체를 보여드리기엔 양이 많아 이부분도 일부만 소개해볼게요.홈 화면 수정 전 / 후작성화면 수정 전 / 후전반적으로는 서비스에 남아 있던 ‘기록’ 중심의 표현을 최대한 걷어내고, 일상을 네컷만화로 표현하는 서비스라는 정체성을 드러내는 데 집중했어요. 화면마다 섞여 있던 표현도 정리하면서 서비스 전체가 한결 깔끔하게 느껴졌고요.앞으로의 하루들사용자들의 이야기를 듣고 함께 고민하면서, 이제야 하루들이 어디로 가야 할지 명확해진 것 같아요. 어떤 경험을 만들고 싶은지, 누구에게 먼저 다가갈지 팀이 함께 바라볼 방향이 생겼어요.앞으로는 이 방향을 바탕으로 다양한 기능을 추가하고 실험을 이어가려고 해요. 사람들이 실제로 어떻게 사용하는지 살펴보면서, 일상을 네컷만화로 나누는 즐거움을 더 잘 전할 수 있도록 다듬어갈게요. 그 과정도 계속 공유해보려고 하고요.하루들 많이 이용해주시고, 주변 사람들과 여러분의 순간도 나눠보세요! 앞으로 달라질 모습에도 관심 가져주시고, 하루들의 팬이 되어주시면 더 기쁠 것 같아요 :)

Blog thumbnail
valborgs

valborgs님이 블로그 글을 발행했어요· 2일 전

스타트업에서 영어이름을 사용해본 썰

예전에 스타트업에 갔을 때 회사에서 영어 이름을 사용한다고 나한테도 영어 이름을 준비해오라고 한다.메일을 읽으면서 유튜브 채널 숏박스의 ZZ오피스 시리즈에 나오는 "홈택스"라는 영어 이름이 생각나서 엄청 웃겼다.(ZZ오피스 시리즈 진짜 재밌었다)그런데 중고딩 시절 영어 수업이나 영어 학원에서 잠깐 사용했던 영어 이름외에는 영어 이름을 사용해 본 적이 없어서굉장히 난처했었다...특히나 흔한 성씨는 아니라 성과 영어 이름을 붙였을 때 굉장히 어색한 느낌이 들기도 했다.창의력이 풍부한 것으로 알고 있는 클로드에 물어보니 위와 같은 이름을 추천해 주었다...좋은데 좀 더 다른 이름도 찾아보았다미국의 90년대생 이름 통계https://www.ssa.gov/oact/babynames/decades/names1990s.html마이클이란 이름이 90년대 당시 가장 인기가 많았나 보다.순위 중 영어학원에서 원어민 선생이 내 얼굴만 딱 보고 무심하게 지어주었던 "Zachary" 가 있어서 일단 1순위로 "Zachary"를 제시했다.외국에서는 모르겠지만 한국에서는 흔히 들어본 이름도 아니고, 보통 "Zach"으로 불린다는데 한국식 발음으로는 "Jack"과 동일하게 불릴 수 있다보니 이름을 "Jack"이라고 오해를 불러일으킬 수 있는 재밌는 이름이라고 생각한다.영어학원을 다닐때에는 원어민 선생님들 중 간혹 "Zach" 발음을 할 때 거의 "s"에 가까운 소리를 내는 분이 있어서(또는 내가 그렇게 들려서) 속으로 참 웃긴이름이다라는 생각을 하곤 했었다.입사 이후에 "이거 어떻게 부르면 돼요?" 라는 말을 들으며 "재커리~" 하니까 또 나의 머릿속에서는 "치커리"가 계속 떠올라서 이름을 들을때마다 속으로 웃곤 했었다.물론 퇴사한 지금에서는 그 이름을 다시는 사용하지 않으리라 지금도 다짐하곤 한다.이 글을 읽는 분들도 영어 이름을 사용할 때에는 열심히 고려해서 이름을 선택하길 바란다.물론 그런거 신경 하나도 안쓰는 사람도 있을 것이다. 정말 부럽다 나도 그런 사람이 되고 싶다.

Blog thumbnail
valborgs

valborgs님이 블로그 글을 발행했어요· 2일 전

Firebase RemoteConfig를 사용한 신규 기능 활성화 플래그 원격으로 작동시키기

현재 플레이스토어에 출시중인 "내가 만든 월드컵" 앱에서 바텀시트를 열어 항목을 클릭하면 아래의 스샷과 같이 바로 실행 다이얼로그가 뜨고 있다..이 과정을 아래와 스샷과 같이 수정해보았다..바텀시트의 항목을 클릭해서 실행 다이얼로그를 바로 띄우는 기존의 단조로운 연출과 달리, 항목을 클릭하면 바텀시트가 내려가고 페이저의 스크롤이 움직이면서 선택한 항목의 아이템 카드가 보여지는 역동적인 연출을 보여주는게 미적으로 좋아보였기 때문이다.하지만 막상 구현해보고나니 어떤 사람은 잠깐이라도 시간이 소요되는 애니메이션을 감상하는것 보다 바로 게임을 실행하고 싶어할 수도 있겠다라는 생각이 들었다. 그리고 만약 내 생각이 만 명 중 단 하나이고, 나머지가 모두 후자의 생각을 갖고있다면, 내 플레이스토어 페이지의 평점과 댓글은 엄청난 난리가 날지도 모르게 될것이다.(내 앱이 인기 앱이었다면...!)만약 해당 기능을 업데이트 후 많은 유저들의 피드백을 받아 수정을하여 다시 업데이트를 해야한다면 업데이트 후 플레이스토어에 게시될 때까지 어느정도 시간이 걸린다... (가끔 게시가 몇시간 만에 바로 반영되는 경우도 있긴 하다!)이럴 때 파이어베이스의 Remote Config 기능을 사용하면 좋겠다는 생각을 했다. 원격으로 플래그를 조정할 수 있기때문에 A/B 테스트용으로 많이 쓰이는 기능이라고 한다.내 경우에는 앱을 실행할 때 Remote Config기능으로 플래그 값을 불러와서 새로 업데이트 한 기능을 활성화 할 지 비활성화 할지를 설정해주면 되는 것이다.파이어베이스에서 Remote Config 메뉴를 선택하고 "구성 만들기"를 클릭한다.앱에서 사용할 변수명을 그대로 입력하고 데이터 유형은 bool로, 디폴트값은 true로 설정하고 저장하면 된다.초안이 먼저 올라오고 상단에 "변경사항 게시" 버튼을 눌러주면 된다.플러터 프로젝트에서는 다음과 같이 코드를 추가해준다.// main.dart await Firebase.initializeApp( options: DefaultFirebaseOptions.currentPlatform, ); final enableBottomSheetSelectionPagerTransition = await _loadBottomSheetSelectionPagerTransitionFlag(); Future<bool> _loadBottomSheetSelectionPagerTransitionFlag() async { try { final remoteConfig = FirebaseRemoteConfig.instance; await remoteConfig.setDefaults(const { _bottomSheetSelectionPagerTransitionKey: _bottomSheetSelectionPagerTransitionDefault, }); try { await remoteConfig.setConfigSettings( RemoteConfigSettings( fetchTimeout: const Duration(seconds: 10), minimumFetchInterval: kDebugMode ? const Duration(minutes: 5) : const Duration(hours: 12), ), ); await remoteConfig.fetchAndActivate(); } catch (error, stackTrace) { log( 'Remote Config를 가져오지 못해 캐시 또는 기본값을 사용합니다.', error: error, stackTrace: stackTrace, name: 'main_remote_config', ); } return remoteConfig.getBool(_bottomSheetSelectionPagerTransitionKey); } catch (error, stackTrace) { log( 'Remote Config 초기화에 실패해 앱 기본값을 사용합니다.', error: error, stackTrace: stackTrace, name: 'main_remote_config', ); return _bottomSheetSelectionPagerTransitionDefault; } } // worldcup_list.dart Future<void> _handleSheetItemTap(WorldCupModel model) async { if (_isHandlingSheetItemTap) return; _isHandlingSheetItemTap = true; try { if (!widget.enableBottomSheetSelectionPagerTransition) { await showDialogBeforeGameStart(context, model, refresh); return; } ...이제 앱을 설치 후 실행하면 fetch값을 불러올 수 있고, 재실행 하는 경우에는 다음과 같은 흐름이 된다.앱 재실행 → fetchAndActivate() 호출 1. 최소 fetch 간격이 지나지 않음 → 서버 요청 생략 → 기존 활성화된 캐시값 반환 2. 최소 fetch 간격이 지남 → 서버 요청 → 파이어베이스에서 설정한 fetch값 가져옴(업데이트)minimumFetchInterval fetch 간격을 12시간으로 해놓은 이유는 해당 기능이 UX적으로 치명적인 위험이 있는 요소는 아니라 생각했고, 오히려 간격을 짧게 해버리면 트래픽 비용이 그만큼 발생할 수 있기 때문이었다.(12시간이 너무 긴 것 같다면 6시간 정도로 줄여도 상관없을 것 같다.)만약에 유저의 반응에 따라 빠른 대응이 중요한 기능이었다면 fetch 간격을 더 짧게 줄였을 것이다.이제 앱 업데이트 후 유저들의 피드백을 받아 필요 시 Remote Config로 플래그를 변경해보자=====================================================================원문 : https://velog.io/@valborgs/Firebase-RemoteConfig%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%9C-%EC%8B%A0%EA%B7%9C-%EA%B8%B0%EB%8A%A5-%ED%99%9C%EC%84%B1%ED%99%94-%ED%94%8C%EB%9E%98%EA%B7%B8-%EC%9B%90%EA%B2%A9%EC%9C%BC%EB%A1%9C-%EC%9E%91%EB%8F%99%EC%8B%9C%ED%82%A4%EA%B8%B0

Blog thumbnail
valborgs

valborgs님이 블로그 글을 발행했어요· 2일 전

플레이스토어 실제 유저 피드백 반영하기

최근에 이상형 월드컵 앱을 업데이트 했는데, 왠일인지 실제 유저의 피드백이 올라왔다.진짜 사람이 플레이하고 있었다니 감격...!소중한 피드백에 감사 인사를 먼저 올리며, 유저의 기기와 버전을 확인했다.갤럭시 Z플립7 유저인데 확장 화면에서 글자 끊김이 발생하는건지 접은 화면에서 발생하는건지는 모르겠지만...일단 본인은 해당 기기가 없으므로 안드로이드 스튜디오의 에뮬레이터 기능을 사용해 Pixel 10 Pro Fold로 확인해보기로 했다.제목과 설명을 100자, 150자로 설정해서 실제로 어떻게 보이나 확인해보았는데...설명 부분은 입력한 내용이 모두 출력이 되지만 제목 부분은 2줄 넘어가는 부분부터 짤려보이고 있다.코덱스에 요청해서 해당 부분을 수정했다.텍스트가 짤리지 않고 모든 내용이 출력되고 그만큼 다이얼로그의 크기도 늘어나게 했다.게임 플레이 시 화면 상단의 제목도 "..." 처리하지 않고 모든 텍스트를 읽을 수 있도록 애니메이션 처리했다.일단 이렇게 수정하고 빠르게 업데이트를 진행해야 겠다.리뷰에는 얼른 답글을 달아두었다. 더욱 더 많은 피드백이 올라오면 좋을 것 같다!=======================================================================원문 : https://velog.io/@valborgs/%ED%94%8C%EB%A0%88%EC%9D%B4%EC%8A%A4%ED%86%A0%EC%96%B4-%EC%8B%A4%EC%A0%9C-%EC%9C%A0%EC%A0%80-%ED%94%BC%EB%93%9C%EB%B0%B1-%EB%B0%98%EC%98%81%ED%95%98%EA%B8%B0

Blog thumbnail
valborgs

valborgs님이 쇼케이스를 등록했어요· 2일 전

Showcase thumbnail

내가 만든 월드컵

핸드폰에 저장된 자신만의 사진으로 직접 만드는 이상형 월드컵

Chaesang Jung

Chaesang Jung님이 블로그 글을 발행했어요· 2일 전

유명하다는 이유만으로 — 왓츠앱은 왜 한국 화면에 올라왔을까

플레이스토어 시절, 두 개의 민원에서 시작된 과제 하나를 풀어 본다. 글로벌하게 유명하다는 이유만으로 한국 화면 위쪽에 올라오던 앱들을 두고, 인기 점수를 나라와 언어로 쪼개 보던 이야기다.한국의 비즈니스 팀은 한국 개발사들을 고객으로 두고 있었는데, 피드백 중에 스토어가 자꾸, 그것도 강하게 WhatsApp을 여기저기에서 추천하고 있다는 것이었다. 알다시피 그때나 지금이나 한국은 카카오톡이 지배하는 나라이고, 양보해서 인스타그램, 페이스북, 트위터, 라인까지는 그렇다 쳐도, 한국 사용자의 화면에 왓츠앱이 자꾸 올라올 이유는 없었다. 글로벌하게 유명한 앱이, 다른 나라들에서 유명하다는 이유만으로 현지에 떠야 하는가 — 이 질문이 과제의 시작이었다.한국과 일본 사정을 잘 모르는 영어 위주의 미국 본사에서는 이 문제가 얼른 실감되지 않는 눈치였는데, 비슷한 시기에 정확히 같은 일이 본사에서도 일어났다. 미국 비즈니스 팀의 고객인 우버와 Lyft에서 똑같은 피드백이 올라왔는데, Easy Taxi가 미국에서 우버보다 위에 나온다고 했다. Easy Taxi는 브라질과 중남미에서 크던 앱이라 그쪽 사용자 수가 미국 사용자 수를 압도했고, 게다가 어느 나라에서든 쓸 수라도 있는 왓츠앱에 비해, 이 앱은 당시 미국에서는 쓸 수조차 없었다. 3억의 인구로도 피해갈 수 없던 셈이다.과제의 이름을 두고(이름 정하는 건 언제나 어렵다) country-slicing이니 language-slicing이니 하다가 locale-aware로 진행하게 되었다. 하려는 일 자체는 명료했고, 자유로운 웹보다는 사용자가 명확한 플레이스토어여서 조금 더 욕심을 부려 촘촘하게 가져가려 했었다. 인기와 관련된 점수들 — 클릭, 설치, 그리고 설치 후 실제로 쓰이는가를 보는 good install까지 — 를 전부 locale로 나누어 적용하고 랭킹 공식을 다시 잡는 것. 그런데 구현에 들어가자 욕심이 과한 게 바로 부작용으로 나타났다. 사용자들이 마흔 개가 넘는 언어와 백 개가 넘는 나라에 걸쳐 있으니 그 조합마다 점수를 저장하고 계산해야 했고, retrieval 비용과 latency가 함께 올라갔다. 갑자기 x4000이 되었으니 인프라 팀에서 반대 의견이 왔다 — 저장은 OK, hot-path에서 계산은 NO.오프라인으로 진행한 검색과 추천의 품질 검사 결과는 다행히 나아졌고, 풀려고 하는 문제는 풀린다는 게 확인되었기에, 나머지 엔지니어링 최적화는 그리 어렵지 않은 trade-off로 정리할 수 있었다. 모든 locale을 다 나누는 대신 각 앱별로 상위 5~10개 locale을 미리 정해 놓고 나누어 결과를 비교하며 성능을 끌어올리는 것. 그렇게 약간의 비용 추가로 구현이 되었고, 하던 공식대로 인덱스를 먼저 내보내고 바이너리를 dark launch로 깔아 둔 뒤 여러 가지 라이브 실험들을 해 보며 지켜보는 순서로 런치가 진행됐다.결과는 절반의 성공이었다. categorical query — '메신저'나 '택시' 같은 부류 검색 — 에서는 결과가 다소 나아졌고 navigational query에는 부정적 영향이 없었으며, 추천의 후보군에서 현지 사용자들이 보기에 엉뚱한 앱들이 많이 사라졌다. 보기에 편안해진 면이 있지만 실제 클릭이 늘지는 않았는데, 이는 품질 낮은 결과들을 내려보낼 때 보이는 일반적인 증상과 닿아 있다. 돌아보면 왓츠앱을 밀어 올리던 global popularity도, 쓸 수 없는 앱을 화면에 보여 주려던 availability의 문제도 어느 정도는 다스려진 셈이다. 다만 그 대가도 함께 왔는데, 한 나라에서 유명해진 앱이 새로운 나라에 뒤늦게 출시되는 경우에 이전에 가지고 있던 이점들이 사라지는 등 새로운 이슈들이 생기게 되었다.나라를 나누는 일을 하다 보면 나라마다 다른 것만 눈에 들어올 것 같지만, 정작 받아들이기 어려웠던 건 반대쪽이었다. 매출 차트를 빼고 보면 '게임'이라는 쿼리의 상단에 오래 머무는 것들은 대형 게임사의 대작이 아니라 slither.io나 arrow.io 같은 캐주얼 게임들이었는데, 어느 나라에서든 그랬다. 실험을 여러 번 돌려 봐도 마찬가지였다. 사용자가 스토어에 '게임'이라고 검색할 때는 유명한 것을 찾는 게 아니라 지금 간단히 해 볼 것을 찾더라는 사실이 전 세계 공통이더라는 것 — 나라마다 다른 것을 찾아 랭킹에 새겨 넣던 과제에서, 제일 오래 걸린 건 그 똑같음을 받아들이는 일이었다. 많은 블록버스터 게임들이 지하철역의 광고판을 통해 검색되고 유통되는 동안, 스토어는 제대로 일을 못하고 있는 게 아닌가 하는 죄책감 같은 것도 있었고, 내 선입견을 데이터에 맞춰 고쳐 넣는 일이, 랭킹에 나라를 새겨 넣는 일보다 어려웠는지도 모르겠다.이는 일이었다. 많은 블록버스터 게임들이 지하철역의 광고판을 통해 검색되고 유통되는 동안, 스토어는 제대로 일을 못하고 있는 게 아닌가 하는 죄책감 같은 것도 있었고, 내 선입견을 데이터에 맞춰 고쳐 넣는 일이, 랭킹에 나라를 새겨 넣는 일보다 어려웠는지도 모르겠다.이 글은 '나라와 언어 사이'라는 연작의 한 편입니다. 원문과 나머지 편은 브런치에 있습니다 → https://brunch.co.kr/@chaesang/200

Blog thumbnail
장현

장현님이 쇼케이스를 등록했어요· 2일 전

Showcase thumbnail

Zeni

Zeni는 사람들이 서로 프로젝트를 공유하는 곳입니다.