<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>도담도담 on monkshark.dev</title><link>https://monkshark.github.io/tags/%EB%8F%84%EB%8B%B4%EB%8F%84%EB%8B%B4/</link><description>Recent content in 도담도담 on monkshark.dev</description><generator>Hugo -- gohugo.io</generator><language>ko</language><lastBuildDate>Mon, 20 Jul 2026 13:00:00 +0900</lastBuildDate><atom:link href="https://monkshark.github.io/tags/%EB%8F%84%EB%8B%B4%EB%8F%84%EB%8B%B4/index.xml" rel="self" type="application/rss+xml"/><item><title>#4 - 피치가 망한 날 파이널에 올라갔다</title><link>https://monkshark.github.io/p/dodam-final-pitch/</link><pubDate>Mon, 20 Jul 2026 13:00:00 +0900</pubDate><guid>https://monkshark.github.io/p/dodam-final-pitch/</guid><description>&lt;p&gt;만드는 건 끝났다. 남은 건 보여주는 일이었는데, 그게 제일 먼저 망했다.&lt;/p&gt;
&lt;h2 id="중간-피치가-안-됐다"&gt;&lt;a href="#%ec%a4%91%ea%b0%84-%ed%94%bc%ec%b9%98%ea%b0%80-%ec%95%88-%eb%90%90%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;중간 피치가 안 됐다
&lt;/h2&gt;&lt;p&gt;우리 순서는 중간쯤이었다. 그리고 기술적인 문제로 피치가 원활하게 진행되지 않았다.&lt;/p&gt;
&lt;p&gt;해커톤에서 이건 흔한 사고다. 흔하다는 게 위로가 되지는 않는다. 대회 내내 만든 결과물을 몇 분 안에 전달하는 자리인데, 그 몇 분이 제 기능을 못 하면 앞의 며칠이 심사위원에게 도달하지 않는다. 코드가 돌아가는지와 코드가 돌아가는 걸 보여줄 수 있는지는 다른 문제라는 걸, 그날 몸으로 배웠다.&lt;/p&gt;
&lt;p&gt;피치가 끝나고 나서 팀 분위기가 좋을 리 없었다.&lt;/p&gt;
&lt;h2 id="한-번-더"&gt;&lt;a href="#%ed%95%9c-%eb%b2%88-%eb%8d%94" class="header-anchor"&gt;&lt;/a&gt;한 번 더
&lt;/h2&gt;&lt;p&gt;그런데 주최측에서 기회를 줬다. 마미톡 트랙 피치가 다 끝난 뒤 마지막에 한 번 더 하라고.&lt;/p&gt;
&lt;p&gt;재도전도 같은 팀원이 다시 올라가서 했다. 이게 결과적으로 좋게 굴렀다. 화면을 직접 그린 사람이 그 화면을 설명하니까 설명과 데모가 어긋나지 않았다. 플로팅 버튼이 왜 필요한지, 쿠팡을 나가지 않는 몇 초가 왜 중요한지가 기능 나열이 아니라 장면으로 전달됐다.&lt;/p&gt;
&lt;p&gt;그리고 한 번 더 한다는 건 두 번째라는 뜻이기도 했다. 처음 올라갔을 때 어디서 말이 꼬였는지 아는 상태로 같은 피치를 다시 하는 거라, 앞의 사고가 리허설 노릇을 했다. 사고가 없었으면 이 피치는 없었을 거다. 그건 좀 이상한 계산이다.&lt;/p&gt;
&lt;h2 id="파이널-피치-준비하세요"&gt;&lt;a href="#%ed%8c%8c%ec%9d%b4%eb%84%90-%ed%94%bc%ec%b9%98-%ec%a4%80%eb%b9%84%ed%95%98%ec%84%b8%ec%9a%94" class="header-anchor"&gt;&lt;/a&gt;파이널 피치 준비하세요
&lt;/h2&gt;&lt;p&gt;발표가 끝나자마자 마미톡 관계자분이 오셔서, 파이널 피치를 준비하라고 했다.&lt;/p&gt;
&lt;p&gt;그 말이 무슨 뜻인지 나는 단번에 알아챘다. 2023에 나가봤기 때문이다. 파이널 피치에 올라간다는 건 최소한 트랙 1위라는 뜻이다.&lt;/p&gt;
&lt;p&gt;작년의 3등이 여기서 정보로 돌아왔다. 그때는 그냥 신기하고 벅찬 경험이었는데, 1년 뒤에는 대회가 어떻게 굴러가는지 아는 사람이 되어 있었다. 같은 자리에 두 번 가는 일의 값이 이런 데 있구나 싶었다.&lt;/p&gt;
&lt;h2 id="결과"&gt;&lt;a href="#%ea%b2%b0%ea%b3%bc" class="header-anchor"&gt;&lt;/a&gt;결과
&lt;/h2&gt;&lt;p&gt;트랙 1위였다. 나중에 POSTECH 총장상까지 받았다.&lt;/p&gt;
&lt;h2 id="오래-남은-건-시상식이-아니었다"&gt;&lt;a href="#%ec%98%a4%eb%9e%98-%eb%82%a8%ec%9d%80-%ea%b1%b4-%ec%8b%9c%ec%83%81%ec%8b%9d%ec%9d%b4-%ec%95%84%eb%8b%88%ec%97%88%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;오래 남은 건 시상식이 아니었다
&lt;/h2&gt;&lt;p&gt;그런데 지금 이 대회를 떠올릴 때 제일 먼저 나오는 장면은 시상식이 아니다.&lt;/p&gt;
&lt;p&gt;며칠 전에 팀원과 거의 다투듯이 했던 그 대화다. 데이터가 없는 성분 앞에서 뭘 보여줄 거냐를 두고 오래 얘기했던 자리. 결론이 났을 때는 별거 아닌 것처럼 지나갔는데, 남은 건 그쪽이었다.&lt;/p&gt;
&lt;p&gt;상은 그날의 결과물에 주어진다. 그 대화는 결과물이 어떤 물건이 될지를 정했다. 도담도담을 다시 만든다고 해도 나는 같은 자리에서 같은 선택을 할 거고, 그게 이 프로젝트에서 내가 가져가는 전부다.&lt;/p&gt;
&lt;p&gt;모델한테 모른다고 말할 능력을 준 것. 그게 제일 잘한 일이었다.&lt;/p&gt;</description></item><item><title>#3 - 모른다고 말할 수 있게 만들기</title><link>https://monkshark.github.io/p/dodam-say-i-dont-know/</link><pubDate>Mon, 20 Jul 2026 12:00:00 +0900</pubDate><guid>https://monkshark.github.io/p/dodam-say-i-dont-know/</guid><description>&lt;p&gt;파이프라인에 빈 칸이 하나 있었다. 로컬 데이터베이스에도 없고 식약처 가이드라인에도 걸리지 않는 성분이 나오면 뭘 보여줄 것인가.&lt;/p&gt;
&lt;h2 id="그냥-ai-한테-맡기자"&gt;&lt;a href="#%ea%b7%b8%eb%83%a5-ai-%ed%95%9c%ed%85%8c-%eb%a7%a1%ea%b8%b0%ec%9e%90" class="header-anchor"&gt;&lt;/a&gt;그냥 AI 한테 맡기자
&lt;/h2&gt;&lt;p&gt;팀원 하나가 말했다. 모델이 알아서 그럴듯한 답을 만들게 하면 되지 않냐고.&lt;/p&gt;
&lt;p&gt;틀린 말로 들리지 않는다는 게 문제였다. 데모에서는 그쪽이 확실히 낫다. 심사위원 앞에서 제품을 스캔했는데 &amp;ldquo;정보가 없습니다&amp;quot;가 뜨면 그건 실패한 데모처럼 보인다. 빈 화면보다 뭐라도 나오는 게 낫다는 논리는, 적어도 해커톤의 문법 안에서는 합리적이다.&lt;/p&gt;
&lt;h2 id="비대칭"&gt;&lt;a href="#%eb%b9%84%eb%8c%80%ec%b9%ad" class="header-anchor"&gt;&lt;/a&gt;비대칭
&lt;/h2&gt;&lt;p&gt;나는 반대했다.&lt;/p&gt;
&lt;p&gt;임산부가 이 앱을 믿고 장바구니에 담는다. 틀린 답을 보여주면, 그 사람은 그게 틀렸는지 모른 채로 결제하고 며칠 뒤에 먹는다. 나는 그 사람이 누군지도 모르고, 앱은 아무 일 없었다는 듯 다음 화면으로 넘어간다.&lt;/p&gt;
&lt;p&gt;그 비대칭이 무서웠다. 이 앱이 잘못했을 때 대가를 치르는 쪽과, 잘못한 걸 아는 쪽이 다르다. 앱은 절대 모른다. 사용자만 안다. 그것도 나중에, 혹은 영영 모른 채로.&lt;/p&gt;
&lt;p&gt;일반적인 서비스라면 틀린 추천은 불편으로 끝난다. 여기서는 아니었다. 우리가 고른 사용자와 고른 주제가 그런 자리였다.&lt;/p&gt;
&lt;h2 id="답이-없는-것과-틀린-답이-있는-것"&gt;&lt;a href="#%eb%8b%b5%ec%9d%b4-%ec%97%86%eb%8a%94-%ea%b2%83%ea%b3%bc-%ed%8b%80%eb%a6%b0-%eb%8b%b5%ec%9d%b4-%ec%9e%88%eb%8a%94-%ea%b2%83" class="header-anchor"&gt;&lt;/a&gt;답이 없는 것과 틀린 답이 있는 것
&lt;/h2&gt;&lt;p&gt;설득은 쉽지 않았다. 결과물이 당장 덜 화려해 보이니까.&lt;/p&gt;
&lt;p&gt;그래서 계속 같은 걸 물었다. 답이 없는 것과 틀린 답이 있는 것 중 뭐가 더 위험하냐고.&lt;/p&gt;
&lt;p&gt;답이 없으면 사용자는 다른 방법을 찾는다. 검색하거나, 의사한테 묻거나, 그냥 담지 않는다. 판단이 사용자에게 되돌아간다. 틀린 답이 있으면 사용자는 찾기를 멈춘다. 이미 답을 받았다고 생각하니까. 우리가 제일 하면 안 되는 일은 사용자의 탐색을 끊고 그 자리에 잘못된 확신을 놓는 거였다.&lt;/p&gt;
&lt;p&gt;비어 있는 화면은 정직하다. 채워진 화면은 정직할 수도 있고 아닐 수도 있는데, 사용자는 그 둘을 구분할 방법이 없다.&lt;/p&gt;
&lt;h2 id="모른다고-말하도록-파인튜닝했다"&gt;&lt;a href="#%eb%aa%a8%eb%a5%b8%eb%8b%a4%ea%b3%a0-%eb%a7%90%ed%95%98%eb%8f%84%eb%a1%9d-%ed%8c%8c%ec%9d%b8%ed%8a%9c%eb%8b%9d%ed%96%88%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;모른다고 말하도록 파인튜닝했다
&lt;/h2&gt;&lt;p&gt;결국 데이터가 부족하거나 희귀 성분이 나오면, 모델이 추론을 멈추고 데이터 없음이라고 말하도록 파인튜닝했다.&lt;/p&gt;
&lt;p&gt;말로는 한 줄인데, 이게 기본 동작의 반대라는 게 핵심이다. 언어 모델은 빈칸을 채우도록 만들어진 물건이다. 모르는 걸 물어도 뭔가는 내놓는다. 그럴듯함을 만드는 게 그 모델의 일이니까. 그래서 모른다는 출력은 가만히 두면 안 나온다. 명시적으로 가르쳐야 나온다.&lt;/p&gt;
&lt;p&gt;우리가 준 건 지식이 아니라 경계였다. 여기까지가 네가 아는 범위고, 그 밖에서는 말을 멈춰라.&lt;/p&gt;
&lt;h2 id="화려함-하나를-포기했다"&gt;&lt;a href="#%ed%99%94%eb%a0%a4%ed%95%a8-%ed%95%98%eb%82%98%eb%a5%bc-%ed%8f%ac%ea%b8%b0%ed%96%88%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;화려함 하나를 포기했다
&lt;/h2&gt;&lt;p&gt;이 결정으로 데모에서 보여줄 수 있는 그림 하나를 잃었다. 어떤 걸 찍어도 답이 나오는 앱이라는 그림.&lt;/p&gt;
&lt;p&gt;대신 앱이 거짓말을 안 하게 만들었다. 도담도담이 뭔가를 안전하다고 말하면 그건 근거가 있어서 말한 거고, 모른다고 말하면 정말 모르는 거다. 이 두 문장이 항상 참이어야 앱이 임산부에게 쓰일 자격이 있다고 생각했다.&lt;/p&gt;
&lt;h2 id="돌아보면"&gt;&lt;a href="#%eb%8f%8c%ec%95%84%eb%b3%b4%eb%a9%b4" class="header-anchor"&gt;&lt;/a&gt;돌아보면
&lt;/h2&gt;&lt;p&gt;기술적으로 어려운 결정은 아니었다. 어려웠던 건 곧 심사를 받는 상황에서, 심사에 덜 유리한 쪽을 고르는 일이었다.&lt;/p&gt;
&lt;p&gt;지금도 이 프로젝트에서 내가 제일 잘한 일을 하나만 꼽으라면 이걸 꼽는다. 모델한테 모른다고 말할 능력을 준 것.&lt;/p&gt;</description></item><item><title>#2 - 장바구니에 담기 전에 쓰이려면</title><link>https://monkshark.github.io/p/dodam-floating-scan/</link><pubDate>Mon, 20 Jul 2026 11:00:00 +0900</pubDate><guid>https://monkshark.github.io/p/dodam-floating-scan/</guid><description>&lt;p&gt;아이디어가 정해지고 기획자 셋이 화면 흐름을 짜는 동안, 나는 아키텍처를 그렸다. 이 편에서 내린 결정은 두 개다. 둘 다 같은 질문에서 나왔다. 이 앱이 실제로 쇼핑하는 도중에 쓰일까.&lt;/p&gt;
&lt;h2 id="앱을-여는-순간-진다"&gt;&lt;a href="#%ec%95%b1%ec%9d%84-%ec%97%ac%eb%8a%94-%ec%88%9c%ea%b0%84-%ec%a7%84%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;앱을 여는 순간 진다
&lt;/h2&gt;&lt;p&gt;첫 번째 결정은 화면 전환 없이 스캔할 수 있어야 한다는 것이었다.&lt;/p&gt;
&lt;p&gt;동선을 그려보면 답이 빤하다. 쿠팡에서 제품 상세 페이지를 보고 있다. 스크롤을 내리면 원재료 명세가 나오는데, 읽어도 판단이 안 선다. 여기서 앱을 떠올린다고 치자. 쿠팡을 나가서, 우리 앱을 찾아서, 열고, 제품명을 다시 타이핑하고, 검색하고, 결과를 보고, 다시 쿠팡으로 돌아와서 아까 보던 페이지를 다시 찾는다. 이 과정을 장바구니에 담을 때마다 반복할 사람은 없다. 한 번은 한다. 두 번째부터 안 한다.&lt;/p&gt;
&lt;p&gt;앱을 나가게 만드는 순간 진다. 쇼핑은 흐름이고, 흐름이 끊기면 사용자는 확인을 포기하지 앱으로 돌아오지 않는다.&lt;/p&gt;
&lt;p&gt;그래서 플로팅 버튼을 만들었다. 어떤 화면 위에도 떠 있고, 누르면 그 자리에서 화면을 캡처해 제품명을 인식한다. 쿠팡을 나가지 않는다. 앱으로 들어가는 게 아니라 앱이 따라다니는 쪽이다.&lt;/p&gt;
&lt;p&gt;이 결정의 부수 효과가 하나 더 있었다. 쇼핑몰을 안 가린다는 것. 쿠팡이든 마켓컬리든 네이버 검색 결과든, 화면에 제품명이 떠 있으면 그대로 스캔된다. 쇼핑몰마다 API 연동을 뚫었으면 대회 기간 안에 한 곳도 못 붙였을 거고, 붙인 그 한 곳 밖에서는 아무 쓸모도 없었을 거다.&lt;/p&gt;
&lt;h2 id="매번-클라우드로-보내면-느리고-비싸다"&gt;&lt;a href="#%eb%a7%a4%eb%b2%88-%ed%81%b4%eb%9d%bc%ec%9a%b0%eb%93%9c%eb%a1%9c-%eb%b3%b4%eb%82%b4%eb%a9%b4-%eb%8a%90%eb%a6%ac%ea%b3%a0-%eb%b9%84%ec%8b%b8%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;매번 클라우드로 보내면 느리고 비싸다
&lt;/h2&gt;&lt;p&gt;두 번째는 속도와 비용이었다.&lt;/p&gt;
&lt;p&gt;스캔할 때마다 클라우드로 올려서 판정을 받아오면 구조는 단순하다. 대신 매 요청이 왕복 지연을 먹고, 요청 수만큼 돈이 나간다. 장바구니 채우면서 열 개를 확인하면 열 번을 기다린다. 앞에서 플로팅 버튼으로 아낀 시간을 여기서 다시 토해내는 셈이다.&lt;/p&gt;
&lt;p&gt;그래서 단계를 나눴다. 로컬 SQLite 로 1차 매칭을 건다. 이미 아는 성분이면 클라우드까지 안 가고 그 자리에서 답이 나온다. 위해성이 걸리는 경우에만 다음 단계로 넘긴다. 그때는 식약처 가이드라인을 근거로 RAG 를 태우고, 생성과 비판과 조율로 역할을 나눠 세 번 검증한다.&lt;/p&gt;
&lt;pre class="mermaid" style="visibility:hidden"&gt;flowchart TD
 A[플로팅 버튼 화면 캡처] --&gt; B[제품명 인식]
 B --&gt; C{로컬 SQLite 매칭}
 C --&gt;|아는 성분| D[즉시 판정]
 C --&gt;|위해성 의심| E[식약처 가이드라인 RAG]
 E --&gt; F[생성]
 F --&gt; G[비판]
 G --&gt; H[조율]
 H --&gt; I[판정]&lt;/pre&gt;&lt;p&gt;여기서 중요한 건 세 번 검증한다는 사실 자체가 아니라, 세 번을 아무 때나 돌리지 않는다는 쪽이다. 흔한 성분 하나 확인하는 데 검증 세 바퀴를 돌리면 그건 정확한 게 아니라 느린 거다. 판단이 어려운 자리에만 비용을 몰아줬다.&lt;/p&gt;
&lt;h2 id="순조로웠다"&gt;&lt;a href="#%ec%88%9c%ec%a1%b0%eb%a1%9c%ec%9b%a0%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;순조로웠다
&lt;/h2&gt;&lt;p&gt;여기까지는 계획대로 굴러갔다. 화면 흐름이 나왔고, 파이프라인이 섰고, 데모에서 보여줄 그림이 그려졌다.&lt;/p&gt;
&lt;p&gt;문제는 그 다음이었다. 이 파이프라인에는 아직 답하지 않은 칸이 하나 남아 있었다. 로컬에도 없고 가이드라인에도 없는 성분이 나오면 뭘 보여줄 것인가.&lt;/p&gt;
&lt;p&gt;그 칸을 두고 팀에서 제일 오래 다퉜다. 다음 편은 그 얘기다.&lt;/p&gt;</description></item><item><title>#1 - 3등의 기억으로 다시 갔다</title><link>https://monkshark.github.io/p/dodam-why-again/</link><pubDate>Mon, 20 Jul 2026 10:00:00 +0900</pubDate><guid>https://monkshark.github.io/p/dodam-why-again/</guid><description>&lt;p&gt;도담도담은 임산부가 쿠팡 같은 온라인 쇼핑몰에서 제품 하나를 보고 있을 때, 그게 지금 먹어도 되는 건지 대신 읽어주는 앱이다. 정션 아시아 2024 해커톤에서 만들었고 트랙 1위를 받았다. 이 시리즈는 그 기록이다.&lt;/p&gt;
&lt;h2 id="3등이-남긴-것"&gt;&lt;a href="#3%eb%93%b1%ec%9d%b4-%eb%82%a8%ea%b8%b4-%ea%b2%83" class="header-anchor"&gt;&lt;/a&gt;3등이 남긴 것
&lt;/h2&gt;&lt;p&gt;고1 때 정션 아시아 2023에 처음 나갔다. 첫 해커톤이었고 3등을 받았다.&lt;/p&gt;
&lt;p&gt;지금 돌아보면 등수 자체보다 규모가 컸다. 처음 나간 대회가 그 정도 판이라는 게 비현실적이었고, 그래서 카타르시스도 컸다. 그 감각이 1년을 갔다. 2024 지원서를 쓸 때는 고민할 게 없었다. 서류가 통과했고, 다시 대회장에 갔다.&lt;/p&gt;
&lt;h2 id="트랙-세-개-앞에서"&gt;&lt;a href="#%ed%8a%b8%eb%9e%99-%ec%84%b8-%ea%b0%9c-%ec%95%9e%ec%97%90%ec%84%9c" class="header-anchor"&gt;&lt;/a&gt;트랙 세 개 앞에서
&lt;/h2&gt;&lt;p&gt;가서 보니 트랙이 셋이었다.&lt;/p&gt;
&lt;p&gt;경상북도와 마미톡 트랙은 임산부용 애플리케이션을 참고해 새로운 서비스를 만드는 것이었고, 그중에서도 안전한 식품이 중심이었다. 포스코홀딩스 트랙은 택시에 IoT 센서를 달아 모은 도시 정보로 포항시를 위한 서비스를 만드는 것. 애플 디벨로퍼 아카데미 트랙은 DO GOOD 이라는 큰 주제였다.&lt;/p&gt;
&lt;p&gt;팀원들과 얘기하면서 하나씩 지웠다. 포스코홀딩스는 데이터부터 무거워서 대회 기간 안에 형태가 나올 것 같지 않았다. 애플 쪽은 반대 이유였다. 사실상 자유 주제라 범위가 너무 넓었고, 넓다는 건 좋은 조건 같지만 시간이 없을 때는 오히려 독이다. 뭘 만들지 정하는 데만 하루를 쓰게 된다.&lt;/p&gt;
&lt;p&gt;남은 건 마미톡이었다. 트랙은 정해졌는데 아이디어가 없었다.&lt;/p&gt;
&lt;h2 id="아이디어-없이-보낸-첫날"&gt;&lt;a href="#%ec%95%84%ec%9d%b4%eb%94%94%ec%96%b4-%ec%97%86%ec%9d%b4-%eb%b3%b4%eb%82%b8-%ec%b2%ab%eb%82%a0" class="header-anchor"&gt;&lt;/a&gt;아이디어 없이 보낸 첫날
&lt;/h2&gt;&lt;p&gt;첫날은 트랙만 정하고 아무것도 안 했다. 팀원들끼리 밖을 돌아다니고 놀았다.&lt;/p&gt;
&lt;p&gt;지금 와서 변명하자면 그게 최악의 선택은 아니었다. 책상 앞에서 안 나오는 아이디어는 두 시간 더 앉아 있어도 안 나온다. 다만 그때는 그렇게 태연하지 못했다. 하루가 통째로 날아가는 감각은 계속 있었다.&lt;/p&gt;
&lt;h2 id="포켓지니에서-왔다"&gt;&lt;a href="#%ed%8f%ac%ec%bc%93%ec%a7%80%eb%8b%88%ec%97%90%ec%84%9c-%ec%99%94%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;포켓지니에서 왔다
&lt;/h2&gt;&lt;p&gt;나랑 친구는 게임을 좋아해서, 밖에 나가면 무조건 포켓몬고를 켰다. 그날도 켰다.&lt;/p&gt;
&lt;p&gt;그러다 포켓지니를 썼다. 포켓몬고 써드파티 앱인데, 잡은 포켓몬을 일일이 따져보지 않아도 이게 쓸 만한 개체인지 아닌지를 그 자리에서 알려준다. 원래대로면 수치를 읽고 계산해야 알 수 있는 걸, 눌러서 바로 답으로 받는다.&lt;/p&gt;
&lt;p&gt;거기서 걸렸다.&lt;/p&gt;
&lt;p&gt;임산부가 온라인 쇼핑몰에서 겪는 게 정확히 같은 구조 아닌가. 원재료 명세는 이미 상세 페이지에 다 적혀 있다. 정보가 없는 게 아니다. 문제는 그걸 읽어도 위험한지 안전한지 판단이 안 선다는 것이다. 알레르기 유발 성분이나 조심해야 할 물질은 상세정보 맨 아래 깨알 같은 글자 속에, 심지어 이미지 안에 박힌 채로 섞여 있고, 정작 그 정보를 가장 정확히 해석해야 할 사람에게는 해석할 지식이 없다.&lt;/p&gt;
&lt;p&gt;읽을 수 있는 정보와 판단할 수 있는 정보는 다르다. 포켓지니가 게임에서 하는 일을, 훨씬 더 중요한 자리에서 하면 됐다.&lt;/p&gt;
&lt;h2 id="다섯-명"&gt;&lt;a href="#%eb%8b%a4%ec%84%af-%eb%aa%85" class="header-anchor"&gt;&lt;/a&gt;다섯 명
&lt;/h2&gt;&lt;p&gt;팀은 나까지 다섯 명이었다. 기획자 셋, 디자인과 피치를 맡은 팀원 하나, 개발은 나 혼자였다. 아이디어는 내가 냈다.&lt;/p&gt;
&lt;p&gt;기획자 셋이 그 아이디어를 받아 구체화했다. 화면 흐름을 짜고, 사용자가 실제로 뭘 누르고 뭘 보게 될지를 정리했다. 나는 그동안 아키텍처를 그렸다.&lt;/p&gt;
&lt;p&gt;개발이 혼자라는 건 결정이 빠르다는 뜻이기도 하고, 잘못 그으면 되돌릴 사람이 없다는 뜻이기도 했다. 그래서 첫 결정을 신중하게 골랐다. 다음 편은 그 얘기다.&lt;/p&gt;</description></item></channel></rss>