<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[w0nder.land]]></title><description><![CDATA[w0nder.land]]></description><link>https://w0nder.land</link><image><url>https://w0nder.land/favicon/android-chrome-512x512.png</url><title>w0nder.land</title><link>https://w0nder.land</link></image><generator>RSS for Node</generator><lastBuildDate>Sun, 19 Apr 2026 08:59:12 GMT</lastBuildDate><atom:link href="https://w0nder.land/rss.xml" rel="self" type="application/rss+xml"/><pubDate>Sun, 19 Apr 2026 08:59:12 GMT</pubDate><copyright><![CDATA[2024, w0nder]]></copyright><ttl>60</ttl><item><title><![CDATA[매끄러운 협업은 키치에 가깝다]]></title><description><![CDATA[『참을 수 없는 존재의 가벼움』을 다시 읽으며, 키치라는 개념이 오래 남았다. 밀란 쿤데라가 말하는 키치는 취향의 문제가 아니다. 불편함과 모순을 덜어내고, 누구나 고개를 끄덕일 수 있는 이야기만 남기는 방식이다. 그는 이를 "존재에 대한 범주적 동의"라고 불렀다. 잔디밭을 뛰노는 아이들을 보며 흘리는 첫 번째 눈물, 그리고 그 감동에 함께 젖어 있는 자신을 보며 흘리는 두 번째 눈물. 키치는 그 두 번째 눈물의 세계다. 아름답지만, 그래서 조금 의심스럽다.
경영서들은 대부분 이 방식으로 현실을 설명한다. 협업과 리더십을 다루는 책들은 비슷한 장면을 반복한다. 구성원은 존중받고, 논의는 충분히 이루어지며, 갈등은 적절한 프로세스를 통해 해소된다. 훌륭한 리더는 심리적 안전감을 만들고, 팀은 그 안에서 더 나은 결론에 도달한다. 읽는 동안은 설득된다. 문제는 그 설득이 현실을 전제하지 않는다는 점이다. 불편한 요소를 제거할수록 메시지는 더 쉽게 소비되기 때문이다.
경영서의 그림이 틀린 것은 아니다. 다만 애초에 중요한 것들이 빠져 있다. 감정, 자존심, 이해관계, 타이밍. 실제 조직에서는 분명하게 작동하지만 매끄러운 이야기 안에는 들어갈 수 없는 요소들이다. 누군가의 의견이 내용보다 직급으로 먼저 읽히는 순간, 피드백이 전달되기도 전에 감정을 통과하는 과정, 합의처럼 보이지만 결국 가장 큰 목소리로 수렴되는 결론. 경영서는 현실을 틀리게 설명하지 않는다. 중요한 것들을 지운 상태에서 설명한다. 키치가 작동하는 방식이 그렇다.
현실의 장면은 그 그림과 다르다. 말을 꺼내면 무시되거나 과잉 반응이 돌아오고, 논의는 설득과 방어가 뒤섞인 싸움으로 흐른다. 이런 일은 예외가 아니다. 오히려 조직이 실제로 작동하는 방식에 가깝다. 그런데도 우리는 그것을 예외처럼 취급한다. 책이 제시하는 그림을 기준으로 삼기 때문이다.
현실이 어긋날 때, 우리는 현실이 아니라 사람을 고치려 든다. 프로세스를 의심하고, 리더의 성장을 문제 삼고, 팀 문화를 탓한다. 하지만 드러난 것은 결함이 아니라, 처음부터 지워져 있던 것들인지도 모른다. 지도에 없는 길을 틀렸다고 말하는 셈이다.
좋은 협업은 매끄러운 그림을 구현하는 데서 나오지 않는다. 지워졌던 것들—말하기 불편한 감정, 충돌하는 이해관계, 설명되지 않는 역학—을 다시 드러내는 데서 시작한다. 『참을 수 없는 존재의 가벼움』에서 키치에 맞서는 인물들이 그랬듯, 중요한 것은 아름다운 그림을 거부하는 것이 아니라 그 밖에 있는 것들을 외면하지 않는 일이다. 키치를 알아보는 것이 먼저다. 그 다음에야, 비로소 실제 협업이 가능해진다.
]]></description><link>https://w0nder.land/posts/71-%EB%A7%A4%EB%81%84%EB%9F%AC%EC%9A%B4%20%ED%98%91%EC%97%85%EC%9D%80%20%ED%82%A4%EC%B9%98%EC%97%90%20%EA%B0%80%EA%B9%9D%EB%8B%A4</link><guid isPermaLink="false">71</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 12 Apr 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[오늘도 한 명 개발자로 만들었다]]></title><description><![CDATA[회사에서 비개발자들이 직접 PR을 올리는 흐름을 만들고 있다.
최근 마케터가 마케팅 트래킹 스크립트를 추가해달라고 했다. 예전이었으면 티켓을 만들고, 개발팀 백로그에 쌓이고, 우선순위에 밀리다가 2주 뒤에 반영됐을 일이다. 대신 같이 시간을 내서 Claude Code로 PR 올리는 방법을 알려줬다. 트래킹이 언제 어떻게 기록되는지 궁금해했을 때도 Claude Code로 직접 확인하는 법을 알려줬다. CS 담당자가 어드민에 기능을 추가해달라고 했을 때도 마찬가지였다. 직접 Claude Code로 기능을 만들어 PR을 올렸고, 내가 확인하고 배포했다.
이게 되는 시대가 왔다.
과거에 외국어는 전문가의 영역이었다. 번역가가 있었고, 통역가가 있었다. 일반 사람들은 그들 없이 외국어로 된 일을 처리할 수 없었다. 그런데 교육이 보편화되면서 상황이 바뀌었다. 이제 대부분의 사람들이 영어를 일정 수준 하고, 제2외국어도 한다. 번역가와 통역가는 사라지지 않았다. 다만 더 전문적이고, 더 책임이 필요한 영역에서 활동한다. 그리고 일반 사람들은 번역가 없이도 영문 이메일을 쓰고, 해외 미팅을 하고, 외국어 문서를 읽으며 살아간다.
개발도 같은 길을 걷고 있다.
마케터가 트래킹 코드를 직접 수정하고 PR을 올린다. 기획자가 기존 코드를 바탕으로 프로토타입을 만든다. 디자이너가 프론트 개발자 없이 UI를 직접 개발한다. CS 담당자가 어드민 기능을 직접 만든다. 그리고 이건 프론트엔드에서 시작해서, 언젠가 백엔드까지 침투하고, 인프라 영역도 프레임워크처럼 추상화되는 날이 올 것이다.
문제는 이 흐름 앞에서 사람들이 선을 긋기 시작한다는 것이다.
비개발자가 먼저 선을 긋는다. "그건 개발자 일이잖아요." 마케터가 트래킹 코드를 직접 수정할 수 있는데도, 여전히 개발팀에 티켓을 넣는다. 기획자가 프로토타입을 만들 수 있는데도, 개발팀 일정을 기다린다. 할 수 있는데 안 하는 것이다. 영어를 할 줄 아는데 모든 영문 이메일을 번역팀에 넘기는 것과 같다. 그 사람은 선을 지키는 게 아니라, 스스로 느려지고 있는 것이다.
개발자도 선을 긋는다. 프론트엔드 개발자는 "백엔드는 내 영역이 아니다"라고 한다. 백엔드 개발자는 "프론트는 프론트가 하면 된다"고 한다. AI가 경계를 허물어주고 있는데, 사람이 다시 경계를 세운다. 간단한 API 하나를 백엔드에 요청하고 기다리는 동안, Claude Code로 직접 만들면 30분이면 끝나는 일을 이틀을 기다린다.
역할을 나누고, 내 일이 아니라고 하고, 방어적으로 자기 영역을 지키는 태도. 이건 전문성을 지키는 게 아니다. 변화를 거부하는 것이다.
모두가 개발하는 시대에 개발자가 사라지는 건 아니다. 번역가가 사라지지 않은 것처럼.
개발자의 역할이 바뀐다. 코드를 직접 치는 사람에서, 코드가 안전하게 돌아가는 기반을 만드는 사람으로. 구체적으로는 이런 일이다.
사람들이 코드를 만들 수 있는 환경을 준비한다. 템플릿, 가이드라인, CI/CD, 테스트 자동화. 누구나 PR을 올릴 수 있되, 잘못된 코드가 프로덕션에 나가지 않는 구조를 만든다.
올라온 PR을 검수하고 컨펌한다. 마케터가 올린 트래킹 코드가 성능에 영향을 주지 않는지, CS 담당자가 만든 어드민 기능이 보안에 문제가 없는지 확인한다. 코드를 쓰는 게 아니라, 다른 사람이 쓴 코드를 판단한다.
배포를 책임진다. 코드를 만드는 건 누구나 할 수 있지만, 그 코드가 실제 사용자에게 나가는 순간의 책임은 여전히 개발자의 몫이다.
막히는 부분을 도와준다. 비개발자가 Claude Code로 해결이 안 되는 부분, 구조적으로 복잡한 부분, 판단이 필요한 부분을 같이 풀어준다.
다른 사람들이 만든 결과물을 책임지는 역할. 그게 앞으로의 개발자다.
AX(Agent Experience)라는 말이 있다. AI 에이전트가 제품과 시스템을 잘 사용할 수 있도록 설계하는 것. UX가 사람을 위한 경험 설계였다면, AX는 에이전트를 위한 경험 설계다.
마케터가 PR을 올릴 수 있었던 건 마케터가 코딩을 배워서가 아니다. Claude Code라는 에이전트가 우리 코드베이스를 잘 탐색하고 변경할 수 있는 환경이 갖춰져 있었기 때문이다. 좋은 구조, 명확한 컨벤션, 테스트. 에이전트가 잘 작동하는 환경이 곧 모두가 개발할 수 있는 환경이다.
선을 긋는 순간, 그 선 안에 갇힌다. AI는 경계를 허물고 있는데, 사람이 경계를 만들고 있다면 문제는 AI가 아니라 사람이다.
]]></description><link>https://w0nder.land/posts/70-%EC%98%A4%EB%8A%98%EB%8F%84%20%ED%95%9C%20%EB%AA%85%20%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A1%9C%20%EB%A7%8C%EB%93%A4%EC%97%88%EB%8B%A4</link><guid isPermaLink="false">70</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 05 Apr 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[우리는 누구의 기준으로 보는가]]></title><description><![CDATA[다음 주 출시를 앞둔 기능에 대해 전사 QA를 진행했다. 판매와 직결된 기능이었고, 다양한 결제 상황을 포함한 테스트가 필요한 영역이었다. 다행히 치명적인 버그는 없었다. 문제는 예상치 못한 곳에서 나왔다.
반복적으로 올라온 의견이 있었다. 특정 버튼이 잘 보이지 않는다는 것, 어디를 눌러야 할지 헷갈린다는 것이었다. 이 피드백을 팀에 공유했을 때 돌아온 반응은 거의 비슷했다. "버튼이 있는데 왜 못 찾지?" "딱 보이는데 굳이 대응해야 할까?"
틀린 말은 아니었다. 버튼은 실제로 존재했고, 확인도 가능했다. 하지만 상황을 다시 들여다보니 이유는 금방 드러났다. PC 환경에서는 문제가 없었지만, 많은 사람들이 모바일로 테스트를 진행했고, 모바일에서는 좌우 스크롤을 해야만 그 버튼이 화면에 나타났다.
버튼은 "있었다". 하지만 사용자에게는 "없는 것"과 같았다.
이 간단한 사실을 앞에 두고도 팀의 첫 반응이 "왜 못 찾지?"였다는 것, 그게 이 이야기의 핵심이다.

사용자 피드백을 받을 때 팀원들이 가장 먼저 꺼내는 말은 겉으로는 "왜 저 사람은 이걸 못 찾지?"처럼 들리지만, 실제 톤은 "눈에 보이는데 왜 못 찾아?"에 가깝다. 버튼도 있고, 화면에도 뜬다. 그러니 이상한 쪽은 사용자인 것처럼 들린다. 이 질문은 자연스럽게 느껴지지만, 사실 문제를 만든 사람이 문제를 겪는 사람에게 책임을 넘기는 질문이다. 이 질문에서 출발하면 제품은 바뀌지 않는다. 사용자가 바뀌기를 기다리게 된다.
질문은 반대 방향이어야 한다. "이걸 왜 못 찾게 만들었지?" 이 한 문장의 차이가 제품을 바꾼다.
우리는 오랫동안 자신이 만든 구조 안에서 살아왔기 때문에, 그 구조가 당연하게 느껴진다. "이건 당연히 보이는 거 아닌가?" "이 정도면 충분히 직관적이지 않나?" 이런 말이 입에서 나오는 순간, 우리는 이미 사용자의 자리에서 멀리 벗어나 있다.
사용자는 우리의 설계 의도를 이해하려고 노력하지 않는다. 그냥 쓰다가 막히면 떠난다. 그것이 전부다.

관련해서 우리는 자꾸 "더 좋아 보이는 것"을 만들려 한다. 더 깔끔한 레이아웃, 더 세련된 인터페이스, 더 완성도 있어 보이는 구조. 그런데 우리는 예술을 하는 조직이 아니다. 우리는 비즈니스를 한다.
겉으로 보기에 어색하거나 비효율적으로 보이는 설계라도, 그게 실제로 매출을 만들고 핵심 지표를 움직이고 있다면 그건 이유가 있는 설계다. 반대로 아무리 깔끔하고 완성도 있어 보여도, 사용자가 선택하지 않으면 그건 실패한 제품이다.
"작동한다"는 말의 의미를 다시 생각해야 한다. 기능이 오류 없이 돌아가는 것은 작동의 최소 조건일 뿐이다. 진짜 작동은 따로 있다. 사용자가 좋다고 느끼고, 실제로 선택하고, 다시 돌아오는 것. 그게 작동하는 제품이다. 그리고 제품은 우리의 의도가 아니라, 사용자의 행동으로만 증명된다.

이론과 실제 사이에는 항상 간격이 있다. 그래서 기존 경제학 이론들이 실제 경제를 표현하지 못해 행동경제학이 나왔듯이, 우리도 설계의 논리와 사용자의 실제 행동 사이에 같은 종류의 간격을 마주한다. 우리는 더 나은 구조와 더 좋은 경험을 이야기하지만, 사용자는 우리의 논리대로 움직이지 않는다. 그 간격을 인정하지 않으면, 우리는 계속해서 "맞다고 믿는 제품"만 만들게 된다.
다른 좋은 서비스를 볼 때도 마찬가지다. 우리는 보고 싶은 부분만 본다. 잘 설계된 것처럼 보이는 요소만 가져와서 "우리도 이렇게 해야 한다"고 말한다. 하지만 그건 맥락이 제거된 복사일 뿐이다. 그 제품이 어떤 상황에서 만들어졌는지, 어떤 사용자를 위한 것인지, 어떤 지표를 위해 그 설계를 택했는지까지 봐야 한다. 전체를 보지 않으면, 배운 게 아니라 오해한 것이다.
그리고 이 오해가 반복되는 데는 이유가 있다. 우리는 이미 가지고 있는 생각을 확인해줄 근거만 찾는 데 익숙해져 있기 때문이다. 좋아 보이는 것만 골라 보고, 불편한 피드백은 예외로 처리하고, 맞지 않는 데이터는 맥락 탓으로 돌린다. 그렇게 쌓인 확신은 단단해 보이지만, 실제로는 검증된 적 없는 전제 위에 서 있다.
지금 우리에게 가장 필요한 것은 확증편향을 인식하는 일이다. 이미 결론을 가지고 있는 상태에서 피드백을 들으면, 논의가 아니라 방어가 된다. 자신의 생각을 지키기 위해 벽을 세우기 시작하면, 주변 사람들은 결국 설득을 포기한다. 그 순간을 우리는 쉽게 착각한다. 내가 옳았으니까 아무도 반박하지 않는다고. 하지만 실제로는 그냥 나를 포기한 것이다.
함께 더 나은 답을 찾을 기회를 잃은 것이다.

좋은 팀은 멋지게 보이는 제품을 만드는 팀이 아니다. 함께 일할 때 옳고 그름을 가리는 자리가 아니라 자신의 전제를 의심하고, 더 나은 질문을 찾아가는 팀이다. 피드백 앞에서도 그 질문은 같다. 못 찾았다는 사용자를 예외로 묶어 "저 사람만 그렇다"로 돌릴 것인가, 요구의 근본까지 내려가 더 잘 보이게 하고 "못 찾는다"는 말 자체가 나오지 않게 하려면 무엇을 바꿀 것인가. 어떻게든 되게 만드는 쪽으로 생각을 돌릴 때 그건 방어가 아니라 설계다.
우리가 만드는 제품은 기획자의 것도, 개발자의 것도, 디자이너의 것도 아니다. 사용자의 것이다. 그 사실을 잊지 않는 것, 그리고 그 사실로 계속 돌아오는 것. 그게 태도의 문제다.
기술이 아니라, 태도가 제품을 결정한다.
]]></description><link>https://w0nder.land/posts/69-%EC%9A%B0%EB%A6%AC%EB%8A%94%20%EB%88%84%EA%B5%AC%EC%9D%98%20%EA%B8%B0%EC%A4%80%EC%9C%BC%EB%A1%9C%20%EB%B3%B4%EB%8A%94%EA%B0%80</link><guid isPermaLink="false">69</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 29 Mar 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[팀이 성공해야 개인이 성공한다]]></title><description><![CDATA[대표들이 종종 이렇게 말한다. "우리 직원들은 끝까지 밀어붙이질 않아요." 그런데 그 말을 반복해도 원하는 결과는 나오지 않는다. 늦게까지 남아있는 사람은 늘어도, 퀄리티가 오르거나 성과가 폭발하지 않는다. 이유는 단순하다. 오래 붙잡고 있는 건 시간이고, 대표가 원하는 건 아웃풋이다. 시간은 압박으로 늘릴 수 있지만, 아웃풋은 구조 없이는 늘지 않는다.
사람을 몰아붙이면 보통 세 가지가 생긴다. 책임의 방향이 목표가 아닌 상사 눈치로 바뀐다. 사람들은 남아있지만 중요한 결정을 미루고 안전한 일만 한다. 그리고 재작업이 늘어난다. 팀은 더 늦어지고, 더 지치고, 더 무뎌진다. 시간을 압박하는 방식은 빠르고 좋은 결과를 만들지 못한다.
그렇다면 답은 자율성인가? "자율적으로 하세요"도 아무것도 바꾸지 않는다. 자율은 방임이 아니다. 자율은 선택의 구조다. 사람들이 스스로 끝까지 밀어붙이게 하려면, 기합이 아니라 설계가 필요하다.
설계에는 전제가 있다. 조직은 하나의 과업으로 움직인다. 무엇을 풀고 있는지, 어디까지 가야 하는지가 명확하지 않으면 팀은 결합되지 않는다. 그런데 그 과업을 함께 풀어야 할 사람들은 저마다 다른 이유로 일한다. 리더의 역할은 이 둘을 동시에 다루는 것이다. 사람은 다르게 동기부여되지만, 리더는 그 에너지가 하나의 완주로 모이게 만든다.
"팀이 성공해야 개인이 성공한다"는 말은 그래서 설득의 문제가 아니라 설계의 문제다.
설계는 두 축으로 이루어진다. 하나는 개인의 동기 유형에 맞게 일을 연결하는 것이고, 다른 하나는 우리가 팀으로 함께 나아가고 있다는 인식을 만드는 것이다.
첫 번째 축. 팀과 개인을 연결하려면, 리더가 그 사람을 먼저 알아야 한다. 지금 어디를 향하고 있는지, 무엇이 부족하다고 느끼는지, 어떤 강점을 아직 제대로 써보지 못했는지. 이걸 아는 이유는 하나다. 이 프로젝트가 그 사람의 방향과 어떻게 연결되는지를 짚어주기 위해서다.
솔직히 말하면, 대부분의 구성원은 지금 하는 일이 자신의 성장과 연결된다고 느끼지 않는다. 반복적인 작업, 정해진 스펙, 어디서든 똑같이 하는 일. 백엔드 개발자들이 농담처럼 말하는 "JSON 상하차"가 그 감각이다. 리더의 역할은 바로 그 일에서 성장의 포인트를 찾아내는 것이다. 없어 보여도 있다. 이번에 설계를 직접 결정해볼 수 있는지, 리뷰를 주도해볼 수 있는지, 아직 다뤄보지 못한 문제의 레이어가 있는지. 그걸 찾아서 연결해주는 것이 리더의 일이다.
"이 일이 지금 당장 흥미롭지 않을 수 있어요. 그런데 이번에 이 부분만큼은 당신이 아직 해보지 않은 방식으로 다뤄볼 수 있어요. 여기서 해내면, 지금과는 다른 문제를 다루는 사람이 될 수 있어요."
이 말이 설득이 되려면, 리더가 그 사람을 실제로 알고 있어야 한다. 모르면 공허한 말이 된다. 알면 같이 하는 이유가 된다. 사람마다 동기의 결이 다르다. 인정받고 싶은 사람에게는 기여가 팀 안팎에서 드러나는 구조를 만든다. 안정을 원하는 사람에게는 우선순위 변경과 결정 번복을 줄여 예측 가능한 환경을 설계한다. 자율을 원하는 사람에게는 What만 고정하고 How는 위임한다. 동기를 하나로 맞추려 하지 않는다. 각자의 이유가 지금 하는 일과 연결되게 만드는 것으로 충분하다.
두 번째 축. 나만 빨리 끝내는 게 중요한 게 아니라, 이 고난을 함께 헤쳐나가고 있다는 감각을 만드는 것이다. 내가 막히면 팀이 같이 막히고, 팀이 뚫리면 나도 함께 나아간다. 이 인식이 없으면 아무리 설계가 정교해도 팀은 개인들의 집합에 머문다. 이 감각을 유지하려면 팀이 실제로 그렇게 움직이는 규칙이 필요하다.
목표를 확정하기 전에 방법 설계 미팅을 반드시 해야 하는 이유가 여기 있다. 업무를 나누는 자리가 아니라, 어떻게 달성할지를 팀이 함께 설계하는 자리다. 위에서 내려온 방법을 실행하는 사람과, 자신이 직접 설계한 방법을 실행하는 사람은 다르게 움직인다. 전자는 시키는 만큼 하고, 후자는 될 때까지 한다. 팀이 함께 방법을 설계했다는 것은, 그 방법에 대한 책임을 함께 진다는 것이다.
성공과 실패도 마찬가지다. 잘 됐을 때도, 안 됐을 때도 개인의 공과로 나누지 않는다. 잘 됐을 때 특정 개인의 공으로 돌리는 순간, 나머지는 구경꾼이 된다. 안 됐을 때 특정 개인의 잘못으로 돌리는 순간, 팀은 서로를 향해 방어적이 된다. 포스트모템은 책임을 묻는 자리가 아니라, 팀이 함께 배우는 자리다. 무엇이 막혔고, 어떻게 뚫었는지를 함께 정리하는 것. 그 과정이 쌓일수록 팀은 같은 실수를 반복하지 않는 조직이 된다.
그리고 해냈을 때, 그것을 팀의 것으로 만들어야 한다. 이 목표가 얼마나 어려웠는지, 어디서 막혔고 어떻게 뚫었는지, 그 과정을 함께 기억하게 하는 것이다. "우리가 해냈다"는 경험은 다음 고난을 버티는 연료가 된다. 한 번 함께 해낸 팀은, 다시 함께 해낼 수 있다는 것을 안다.
이 두 축이 갖춰지면 행동이 바뀐다. 끝까지 밀어붙이는 것이 지시가 아니라 선택이 된다. 기준이 '남은 시간'이 아니라 '완주'가 되고, 그 완주가 각자의 동기와 연결된다. 반대로 어느 하나가 빠지면, "팀이 성공해야 개인이 성공한다"는 말은 착취로 들린다.
강한 팀은 오래 앉아 있어서 만들어지지 않는다. 팀은 과업으로 결합되고, 그 과업은 개인의 서로 다른 이유와 연결될 때 지속된다. 리더의 일은 시간을 늘리는 것이 아니라, 사람들이 스스로 몰입하게 되는 문제를 설계하는 것이다. 끝까지 밀어붙이는 것은 그 결과로 따라온다. 지시가 아니라, 스스로 선택한 것이기 때문이다.
]]></description><link>https://w0nder.land/posts/68-%ED%8C%80%EC%9D%B4%20%EC%84%B1%EA%B3%B5%ED%95%B4%EC%95%BC%20%EA%B0%9C%EC%9D%B8%EC%9D%B4%20%EC%84%B1%EA%B3%B5%ED%95%9C%EB%8B%A4</link><guid isPermaLink="false">68</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sat, 21 Mar 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[안 된다고 말하는 사람들]]></title><description><![CDATA[같은 책을 두 번 읽으면, 처음에는 보이지 않던 것들이 보인다. 영화도 그렇다. 똑같은 장면인데, 전에는 그냥 지나쳤던 표정 하나, 대사 한 줄이 어느 날 갑자기 다른 무게로 들어온다. 작품이 달라진 게 아니다. 내가 달라진 것이다.
특히 인물을 보는 눈이 그렇다. 한때 빌런처럼 보였던 사람이, 다시 보면 전혀 다른 사람처럼 느껴질 때가 있다. 냉정하고 계산적으로만 보였는데, 어느 순간 오히려 현실을 가장 잘 보고 있던 사람처럼 보인다. 그 사람이 달라진 게 아니다. 내가 조금 더 많은 것을 겪었다.

요즘 유튜브에서 영화 〈1승〉의 짧은 장면이 자주 보인다. 구단주 강정원은 얼핏 전형적인 빌런처럼 보인다. 배구를 잘 알지도 못하면서 팀을 사고, 엉뚱한 판단을 내리고, 때로는 가볍게 보인다. 현장을 모르는 윗사람, 스포츠 영화에 늘 나오는 그 사람처럼 보이기 쉽다.
그런데 나는 그 장면을 보면서 다른 생각을 했다. 저 사람은 일을 못하는 사람이 아니라, 일을 굴러가게 만드는 사람에 가까운 것 아닐까.

특히 기억에 남는 장면이 있다.
선수가 부족하다고 하자 경력 있는 선수를 사라고 한다. 운영자금이 없다고 하자 선수를 팔라고 한다. 팔 선수가 없다고 하자 싼 선수들을 묶어서 떨이로 팔라고 한다. 그것도 없다고 하자, 잠깐 멈추더니 묻는다. 그나마 괜찮은 포지션이 어디냐고. 리베로라는 대답이 돌아오자, 리베로가 약한 팀이 어디냐고 묻는다. 파이브스타즈라는 말이 끝나기 무섭게 말한다. 그럼 거기 가서 팔아오겠다고.
막힐 때마다 같은 방향을 고집하지 않는다. 그냥 다른 쪽으로 돌아간다.
예전의 나였다면 이 장면에서 구단주가 답답하다고 생각했을 것이다. 하지만 지금은 다르게 보인다. 정말 답답한 건 그다음이다. 안 되는 이유를 늘어놓고는 거기서 멈춰버린다.

물론 안 되는 이유는 대부분 사실이다. 예산이 없고, 시간이 부족하고, 규정이 있고, 사람이 없다. 나는 그것을 부정하고 싶은 게 아니다.
문제는 거기서 멈추느냐, 다른 쪽으로 돌아가느냐다.
사실 나도 그런 사람이었던 적이 있다. 막히면 안 되는 이유를 설명하는 데서 멈추던 사람.

개발자들 사이에 이런 농담이 있다. "개발자는 안 됩니다라고 말하는 종족이다."
이유는 있다. 시스템은 복잡하고, 작은 변화 하나에도 예상치 못한 문제가 생긴다. 무엇이 망가질지, 어디서 문제가 생길지, 어떤 비용이 숨어 있는지 먼저 따져보는 것은 중요한 능력이다.
하지만 막힌 길을 정확하게 설명하는 것과, 다른 길을 찾는 것은 다른 일이다.

여러 회사를 다니고 여러 자리에서 일하면서 비슷한 장면을 자주 봤다. 예전에는 대표들이 왜 저런 결정을 내리는지 이해하지 못했다. 왜 저렇게 단순하게 구는지, 왜 저렇게 무리해 보이는 요구를 하는지.
그런데 시간이 지나면서 조금 달라 보이기 시작했다.
조직 안에는 언제나 안 되는 이유를 정확하게 설명하는 사람들이 있다. 틀린 말을 하지 않는다. 현실을 누구보다 잘 안다. 다만 그 말이 조직을 앞으로 움직이게 만들지는 않는다.

냉정해 보이고, 단순해 보이고, 무모해 보이는 사람들이 있다. 그런데 그 사람들이 판을 키우고, 막힐 때마다 다른 쪽으로 돌아서면서 조직을 앞으로 밀어간다.
같은 영화를 다시 보듯, 같은 사람을 다시 본다. 처음에는 문제를 일으키는 사람처럼 보였는데, 돌이켜보면 문제 앞에서 멈추지 않던 사람이었다.
어쩌면 그 사람들은 안 된다고 말하지 않았다. 그냥 다른 길을 찾았다.
]]></description><link>https://w0nder.land/posts/67-%EC%95%88%20%EB%90%9C%EB%8B%A4%EA%B3%A0%20%EB%A7%90%ED%95%98%EB%8A%94%20%EC%82%AC%EB%9E%8C%EB%93%A4</link><guid isPermaLink="false">67</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 15 Mar 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[검색하지 않았으면 좋겠다.]]></title><description><![CDATA[LLM이랑 같이 개발하다 보면 이상하게 제대로 된 걸 못 찾는다는 느낌이 들 때가 있다. grep으로 단순 검색을 하고 있기 때문이다. grep은 수십 년 된 컴퓨터 명령어인데, 파일 더미에서 특정 단어가 있는 줄을 찾아주는 도구다. "계약서"라는 단어를 검색하면 그 단어가 들어간 문장만 죽 뽑아준다. 의미를 파악하는 게 아니라, 글자가 일치하는지만 확인한다. AI가 문서를 찾는 방식이 본질적으로 이것과 크게 다르지 않다. 더 정교해 보이지만, 결국 패턴 매칭이다.
나는 AI가 내 코드를 다 읽고, 문서를 다 읽고, 그 위에서 판단하길 기대한다. 하지만 실제로는 그렇지 않다. AI에게는 한 번에 읽을 수 있는 글자 수의 한계, 즉 컨텍스트 윈도우(context window)가 있다. 책 한 권을 통째로 읽는 게 아니라, 한 번에 몇 페이지 분량만 볼 수 있다. 그래서 전부 읽지 않고, 검색으로 관련 있어 보이는 조각만 골라서 그 안에서 답을 만든다. 이해처럼 보이지만 사실은 꽤 정교한 패턴 매칭에 가깝다.
이해와 검색은 실패하는 방식이 완전히 다르다. 이해가 부족한 사람은 "모른다"고 말한다. 검색이 실패한 시스템은 "그럴듯한 다른 답"을 말한다. 우리가 반복해서 느끼는 답답함의 본질이 거기에 있다. 틀렸다는 걸 모르는 것처럼 말하는 시스템. 그게 문제다.
그렇다면 읽을 수 있는 글자 수를 무한히 늘리면 해결될까. 그것도 단순하지 않다. 스탠퍼드 대학의 연구에서 "Lost in the Middle"이라는 현상이 확인됐는데, LLM이 긴 내용을 받았을 때 앞부분과 뒷부분에는 잘 집중하지만 중간에 있는 내용은 흘려버리는 경향이 있다는 것이다. 책을 한 권 통째로 줘도 1장과 마지막 장은 잘 기억하지만 중간 챕터는 희미해지는 것처럼. 그래서 리랭킹(reranking)이라는 방법이 나왔다. 검색해서 가져온 문서들을 그냥 순서대로 넣는 게 아니라, 질문과의 관련도를 다시 한번 평가해서 중요한 내용을 앞뒤로 배치하는 방식이다. 입력의 양을 늘리는 게 아니라, 넣는 내용의 배치를 최적화하겠다는 발상이다.
그런데 여기서 한 발짝 물러서면 더 근본적인 문제가 보인다. RAG도, 리랭킹도, 이 모든 방법론이 존재하는 이유가 뭔가. RAG는 Retrieval-Augmented Generation의 줄임말로, AI가 답을 만들기 전에 외부 문서에서 관련 내용을 먼저 찾아서 참고하게 하는 방식이다. 최신 정보를 반영하고, 전문 지식을 연결하고, 근거를 제시하는 데 분명 효과적이다. 하지만 RAG가 꼭 답이 아니라는 연구들도 최근 계속 나오고 있다. 검색 자체가 실패하면 그 오류가 그대로 최종 답변까지 전달되고, 문서를 조각내는 과정에서 앞뒤 맥락이 잘려나가고, 찾아온 근거가 결론을 실제로 지지하는지 아무도 확인하지 않는다.
기술이 하나씩 쌓이는 게 발전처럼 보이지만, 다르게 읽으면 각각의 기술이 LLM의 한계를 하나씩 우회하는 방법들이다. LLM이 모든 걸 읽고 이해해서 답할 수 있다면 이런 게 필요 없다. 이 반복이 어디서 끊길지 지금으로선 알 수 없다. 그렇게 생각하다 보면 결국 이런 질문에 닿는다. LLM이 진짜로 이해한다는 건 애초에 가능한 걸까. 우리가 AI가 이해했다고 말할 때, 그게 실제로 무엇을 의미하는지 자꾸 의심스럽다.
그리고 이 모든 논의의 밑바닥엔 더 단순하고 더 근본적인 바람이 있다. 검색하지 않았으면 좋겠다는 것. 사람에게 "그 문서 내용이 뭐였지?"라고 물으면, 파일을 다시 열지 않는다. 읽었던 내용을 떠올리고, 맥락과 함께 재구성해서 말한다. 그리고 이해했기 때문에 그게 정확하다. 지금의 AI는 그렇게 작동하지 않는다. 매번 찾고, 매번 읽고, 매번 조합한다. 기억하지 않는다. 이해한 것을 쌓지 않는다.
내가 진짜로 원하는 건 AI가 모든 컨텍스트를 알고 처리하는 것이다. 검색 없이. 코드베이스 전체를 읽고, 문서 전체를 읽고, 그 위에서 판단하는 것. 사람이 오랜 시간 프로젝트에 몸담으면서 자연스럽게 전체 맥락을 체득하는 것처럼. 그게 가능해지면 지금처럼 "그거 아닌데, 다시 찾아봐."를 반복하지 않아도 될 것 같다. 그 미래가 언제 올지는 모르겠다. 어떻게 해결해야 할지도 아직 명확하지 않다.
]]></description><link>https://w0nder.land/posts/66-%EA%B2%80%EC%83%89%ED%95%98%EC%A7%80%20%EC%95%8A%EC%95%98%EC%9C%BC%EB%A9%B4%20%EC%A2%8B%EA%B2%A0%EB%8B%A4.</link><guid isPermaLink="false">66</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sat, 07 Mar 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[지금에 마음을 두는 선택]]></title><description><![CDATA[나는 긍정적으로 일해야 한다고 생각한다. 긍정은 흔히 밝은 표정이나 낙관적인 말투로 오해되지만, 내가 말하는 긍정은 조금 다르다. 지금 이 순간에 최선을 다하고, 눈앞의 문제를 해결하려는 태도. 나는 그것이 진짜 긍정이라고 생각한다.
불평과 불만은 누구에게나 자연스럽다. 문제는 그 감정에 오래 머무를 때다. 계속 붙잡고 있으면 마음이 소모되고, 앞으로 나아갈 힘도 줄어든다. 긍정은 그 감정을 억누르는 기술이 아니라, 감정을 인정한 뒤에도 다음 행동을 고르는 힘이다.
현실이 녹록지 않다는 것도 안다. 회사의 체계가 엉망일 수도 있고, 조직의 방향이 납득되지 않을 수도 있고, 윗사람의 판단이 도저히 이해되지 않을 수도 있다. 그런 환경에서 "긍정적으로 살자"는 말이 공허하게 들릴 수 있다. 하지만 나는 오히려 그렇기 때문에 긍정이 필요하다고 생각한다. 괜찮은 척을 하자는 것이 아니다. 상황이 어떻든, 지금 내가 서 있는 자리에서 할 수 있는 일을 찾자는 것이다.
지금 하는 일이 내 길과 완전히 맞지 않더라도, 남는 것은 있다. 주변 사람들이 일하는 방식, 리더의 고민과 판단, 말의 무게를 보고 듣고 스스로 회고하는 과정에서 내 기준이 생긴다. 무엇을 배워야 하는지, 무엇을 피해야 하는지도 그 안에서 조금씩 선명해진다. 그런데 어느 순간, 여기서 더 가져갈 것이 없다는 느낌이 올 때가 있다. 그때도 선택은 필요하다. 다음을 준비하는 것도 선택이고, 같은 자리에서 다른 방식을 시도해보는 것도 선택이다. 어느 쪽이든, 감정에 휘둘려 멈추는 것보다 낫다.
게임을 하다 보면 비슷한 순간이 온다. 전세가 꼬이고, 도저히 풀릴 것 같지 않은 판에서 "이거 접고 다시 할까?" 하는 생각이 든다. 리셋도 하나의 판단이다. 다만 중요한 건 그 선택이 짜증이나 체념에서 나오는 것이 아니라, 지금 상황을 보고 다음을 위해 내리는 결정이어야 한다는 것이다. 게임이든 일이든, 떠나는 것과 도망치는 것은 다르다. 그리고 돌이켜보면, 기억에 남는 승리는 대부분 그런 판에서 나왔다. 한 번만 더 잘해보자는 마음으로 클릭하고, 버티고, 최선을 다했을 때 역전이 일어났다.
방향이 흐릿할수록 더 중요한 건 결국 지금이다. 하고 싶은 것이 분명하지 않을 때 사람은 쉽게 조급해진다. 남들의 속도와 기준에 눈이 가고, 비교 속에서 자기 리듬을 잃는다. 그럴수록 정답을 서둘러 찾기보다, 오늘 할 수 있는 일을 긍정적으로 고민하고 선택하는 편이 오히려 멀리 간다. 완벽한 출발을 기다리기보다 지금 조건에서 유효한 한 걸음을 내딛는 것. 그 반복이 결국 방향을 만들어준다.
불안은 미래로 달아나고, 후회는 과거에 머문다. 긍정은 그 사이에서, 지금 내가 할 수 있는 일에 마음을 두는 선택이다. 결국 우리를 앞으로 가게 하는 건 거창한 확신이 아니라, 지금 이 순간을 헛되이 보내지 않겠다는 태도다.
]]></description><link>https://w0nder.land/posts/65-%EC%A7%80%EA%B8%88%EC%97%90%20%EB%A7%88%EC%9D%8C%EC%9D%84%20%EB%91%90%EB%8A%94%20%EC%84%A0%ED%83%9D</link><guid isPermaLink="false">65</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 01 Mar 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[코드는 싸지고, 책임은 비싸진다]]></title><description><![CDATA[코드가 공짜에 가까워질수록, 코드를 둘러싼 판단은 더 비싸진다.
AI가 코드를 대신 써주는 시대가 오면, 사람 개발자는 사라질까? 내 결론은 정반대다. 개발자는 줄어들지 않는다. 오히려 개발은 더 넓게 퍼지고, "모두가 개발자"가 된다. 다만, 우리가 익숙했던 개발자의 이미지는 바뀐다. 이제 개발자는 키보드를 많이 치는 사람이 아니라, 정책을 세우고 관리하고 리뷰하고 뒷수습하는 사람이 된다.
첫째, AI는 '코드 생산'을 싸게 만든다. 기능 하나를 만들기 위해 필요한 문장 수, 시행착오 수, 검색 수가 줄어든다. 그 결과, 기존에는 개발팀의 대기열에 쌓이던 수많은 작은 요청들이 각 팀으로 분산된다. 마케팅은 캠페인 랜딩을 직접 만들고, 운영은 어드민 화면을 스스로 만든다. 그로스팀은 트래킹 기능을 스스로 심고, PM이나 기획은 프로토타입을 스스로 만들고, 디자이너는 피그마 없이 스스로 UI를 만든다. 프론트엔드는 백엔드 API를 직접 만들고, 백엔드는 프론트 컴포넌트를 직접 붙인다. "개발자만 코드 친다"는 전제가 무너진다.
어쩌면 이것이 더 정확한 미래상일 수 있다. 모두가 개발하되, 기존 프론트엔드 개발자는 프론트 정책관리자가 되고, 백엔드 개발자는 백엔드 정책관리자가 된다. 직군의 경계가 사라지는 게 아니라, 각 직군의 역할이 "코드 작성"에서 "영역 관리"로 이동하는 것이다. 그리고 실제 기능 개발은 누구나, 어느 영역이든 넘어서 하게 된다.
둘째, 그런데 책임은 싸지지 않는다. 코드를 '만드는' 비용이 내려가면, 시스템 전체의 변경량은 폭증한다. 변경이 많아지면 당연히 사고가 늘어난다. 장애, 보안, 데이터 손상, 비용 폭주, 규정 위반… 이 모든 것은 결국 누군가의 책임으로 남는다. 여기서 개발자의 역할이 SRE처럼 바뀐다. 즉, 개발자는 기능을 대량 생산하는 사람이 아니라, 기능이 안전하게 배포되고 관측되고 되돌려질 수 있게 만드는 사람이다.
이 역할 변화는 "정책"으로 드러난다. 예전엔 코드 리뷰가 스타일, 로직 중심이었다면, 이제는 "이 변경이 운영에서 안전한가?"가 핵심이 된다. 예를 들면 이런 질문들이다. 이 기능은 실패해도 안전하게 degraded 되는가? 타임아웃/리트라이/서킷브레이커는 있는가? 로그와 메트릭은 남는가? 경고는 누구에게 어떻게 가는가? 민감정보가 새지 않는가? 권한은 최소화했는가? 비용은 감당 가능한가? 롤백은 가능한가?
이런 흐름 속에서 TDD와 trunk-based 개발이 더 중요해진다. 테스트가 먼저 있어야 AI가 쏟아내는 코드를 신뢰할 수 있고, 브랜치를 오래 들고 가는 대신 작은 단위로 main에 계속 통합해야 변경의 충격을 줄일 수 있다. 기능 개발에 되돌아가기는 없다. 앞으로만 가되, 작게 가는 것이 원칙이 된다.
그래서 앞으로의 개발자는 "가드레일"을 만든다. 템플릿, 린터, CI/CD, 테스트, 권한 정책, 배포 정책, 관측(Observability), 런북, 포스트모템, 그리고 재발 방지를 자동화한다. 조직 관점에선 더 중요하다. 모두가 개발자가 되려면, 모두가 같은 레일 위에서 움직여야 한다. 그렇지 않으면 자유는 곧 혼돈이 된다. AI로 누구나 빠르게 만들 수 있는 만큼, 누구나 쉽게 망가뜨릴 수도 있다.
여기서 자주 나오는 반박은 "그럼 비개발자들이 운영까지 다 해야 하냐"인데, 답은 아니다. 운영은 직무가 아니라 체계다. 개발자는 그 체계를 설계하고, 자동화하고, 교육하고, 리뷰한다. 그리고 사고가 났을 때 가장 마지막에 남아 수습한다. 다시 말해 코딩은 '창작'이 아니라 '변경 작업'이고, 변경 작업은 운영의 일부다.
정리하면, AI 시대의 좋은 개발자는 코드를 잘 쓰는 사람보다 "안전하게 바꾸는 사람"에 가깝다. 코딩 능력은 기본 소양이 되고, 차이를 만드는 건 정책과 운영이다. 코드는 AI가 써줄 수 있다. 하지만 책임은 자동화되지 않는다. 그래서 개발자는 사라지지 않는다. 역할만 더 어려워진다.
]]></description><link>https://w0nder.land/posts/64-%EC%BD%94%EB%93%9C%EB%8A%94%20%EC%8B%B8%EC%A7%80%EA%B3%A0%2C%20%EC%B1%85%EC%9E%84%EC%9D%80%20%EB%B9%84%EC%8B%B8%EC%A7%84%EB%8B%A4</link><guid isPermaLink="false">64</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 22 Feb 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[폭풍의 안과 밖]]></title><description><![CDATA[오랜만에 회사에 다니면서 또 다른 대격변의 시대에 들어선 것 같다는 생각이 든다. 지난 1년간 나도 폭풍 안에 있다고 생각했지만, 사실은 그 폭풍을 밖에서 바라보기만 했던 것 같다.
돌이켜보면 나는 운 좋게도 여러 변화의 순간을 경험해왔다. 딥러닝과 텐서플로가 시작되던 시점, 'GPU라는 걸 쓰면 연산이 빨라서 학습이 가능하다'던 시절에 AI를 공부했다. IT 버블 시기는 경험하지 못했지만, '자바 3명 타세요'라고 하던 암흑기에 개발을 시작해 스타트업이라는 개념으로 투자가 확대되고 급성장하는 시절을 그 안에서 겪었다. 그때 끝일 거라 생각했는데, 변화라는 게 또 존재할 줄 몰랐다. AI와 코딩이 만나는 격변의 시기에, 어쩌면 마지막 격변이라고 하고 싶은 이 시기에 내가 다시 들어서게 되었다.
1년간 혼자 개발하면서는 AI와 코딩하는 것에 대해 아무런 생각이 없었다. 나 혼자 할 때는 내가 생각하는 깔끔한 구조를 유지하면서 AI와 빠르게 개발할 수 있었다. AI 이전에도 안정성을 확보하면서 구조적으로 괜찮지만 빠르게 제품화하는 걸 나름 잘했는데, AI가 있으니 그냥 최고의 상태가 되었다. 그런데 회사에서 활용하는 것에 대해서는 다른 시각이 필요하다는 걸 느꼈다. 주니어들과 함께 하다 보니 어설픈 상태에서 AI와 빠르게 작업하는 상황에 직면하게 되었기 때문이다.
잘하는 사람은 AI가 짠 코드를 보지 않아도 AI가 좋은 퀄리티의 코드를 만들어낸다. 반면 그렇지 않은 사람이 AI를 아무리, 토큰을 아무리 써도 한계가 있다. 더 중요한 것은, 잘하지 못하는 사람이 AI를 쓰게 되면 오히려 잘하는 사람이 되기에는 더 멀어지는 것 같다는 점이었다.
지금 시대에 매니징을 하다 보면 여러 고민이 생겼다. 이전에 내가 매니징 했던 것과 너무 다른 상황이고, 기존의 방법대로 하면 안될것 같다는 생각이 들었다. 기술 공부에 회의를 느끼는 사람도 있고, 회사에서는 AI로 더 빠르게 아웃풋을 내기를 기대하지만 정작 본인은 그 AI와 함께 빠르게 만들어내고 있는 결과물에 만족하지 못해 성장할 수 없다고 느끼기도 한다. 이런 고민을 가진 팀원들을 어떻게 가이드해야 할까? 나는 AI 코딩 시대 전에 개발을 시작해서 여러 성장의 경험을 할 수 있었는데, 지금 성장해야 하는 사람들에게는 어떻게 해야 할까?
이런 질문들을 마주하면서 계속 생각해보니, 결국 AI를 '어떻게' 쓰느냐의 문제라는 생각이 든다. 아이러니하게도 AI가 코딩을 더 쉽게 만들어줄수록, 개발자에게는 더 높은 수준의 판단력이 요구되는 것 같다. AI는 '어떻게 만들지'는 잘 해결하지만, '왜 이걸 만들어야 하는지', '이게 정말 필요한 건지'는 판단하지 못한다.
조금 더 미래에는 모르겠지만, 지금 수준에서는 '왜'를 판단하는 능력이 핵심인 것 같다. 좋은 구조가 뭔지 아는 감각, AI가 내놓은 결과물을 보고 이게 맞는지 틀린지 판단하는 눈. 이런 것들은 결국 직접 고민해본 경험에서 나온다. 그래서 AI를 쓰더라도 먼저 스스로 생각해보는 과정이 필요하고, 그 과정을 만들어주는 게 지금 내가 할 수 있는 가이드라고 생각한다.
5년 뒤 누군가의 예언대로 AGI가 온다면 뭐, 그때는 또 다른 변화에 맞춰야겠지. 그 전까지는 일단 이 방향으로 해보려고 한다.
]]></description><link>https://w0nder.land/posts/63-%ED%8F%AD%ED%92%8D%EC%9D%98%20%EC%95%88%EA%B3%BC%20%EB%B0%96</link><guid isPermaLink="false">63</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sat, 14 Feb 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[취뽀]]></title><description><![CDATA[아는 분 소개로 잠깐 대화만 나눠달라고 해서 갔는데, 면접이었다. 그냥 개발자 면접인 줄 알았는데 개발 리드 면접이었고, 대표님이 직접 나와서 면접을 보셨다.
그리고는 바로 같이 일해보자고 하시더라. 사실 취업할 생각은 전혀 없었다. 올해 1년간 할 다른 도전들을 계획해놨고, 준비도 다 해놨었다. 그런데 대표님이 며칠간 계속 설득하시는 바람에 결국 출근하게 됐다. 하루아침에 직장인으로 돌아온 셈이다. 대표님은 기존에 하던 일은 출근하면서 마무리해도 된다고 하시며, 빠르게 와서 팀 매니징을 부탁한다고만 하셨다.
이렇게 빠른 결정들은 항상 문제가 생기기도 한다. 그런데 대표님이 너무 간절해 보였다.
나는 창업을 하면서 이렇게 간절한 적이 있었나 싶었다. 그러면서 지난 창업 기간을 되돌아보기도 했다. 나는 얼마나 대표스러웠을까? 물론 목표가 이런 걸 바라고 창업한 건 아니지만, 나는 과연 얼마나 했을까? 사업에 대한 절실함, 팀에 대한 책임감, 비전을 향한 추진력. 그런 것들이 나에게도 있었을까?
그래서 이 대표님에게 궁금함이 생겼다. 무엇이 사람을 이렇게 간절하게 만들었을까? 그리고 나를 왜 필요로 하는지, 그 필요가 언제까지 이어질까?
올해 계획을 세운 지 얼마 되지 않았고, 외주 계약을 몇 개 맺은 지도 얼마 안 됐는데, 바로 출근하게 됐다.
일단 기존에 진행하던 일은 빠르게 마무리하는 형식으로 진행하고, 추가 계약 직전에 있던 것들은 거절 의사를 전달했다. 클라이언트들에게 상황을 설명하는 게 생각보다 어려웠다. 갑작스러운 변화를 어떻게 설명해야 할지, 그들이 이해해줄지 조금 걱정도 됐다.
바리스타 학원도 다닐 준비를 하고, 기타 여러 가지를 준비해 놨는데, 다 취소됐다. 아쉽긴 하다. 특히 바리스타는 꽤 오래전부터 해보고 싶었던 거라 마음 한편이 허전하다. 언젠가 기회가 되면 다시 도전해봐야겠다는 생각만 남았다.
인생이 참 묘하다. 계획대로 되지 않는 게 당연한 건데, 막상 이렇게 되면 당황스럽다. 그래도 나쁘지 않은 당황스러움이다.
그렇게 취뽀?를 하고 다시 회사를 다니면서 내가 지난 1년간 얼마나 사회와 IT, 스타트업씬과 멀어졌나 느껴졌다.
1년 만에 세상은 많이 바뀌어 있었다. 나도 바쁘게 살아왔다고, 제품도 많이 만들고, 코딩도 많이 했다고 생각했지만, 다시 적응하는 데 오래 걸릴 것 같은 기분이 들었다. 세상은 저 멀리 나 몰래 가버리고 있었다.
기술 스택도 바뀌었고, 개발 방법도 많이 바뀌었고, 트렌드도 바뀌었고, 사람들이 이야기하는 주제들도 달라져 있었다. 혼자 작은 프로젝트들을 하면서는 몰랐던 것들이, 조직 안에서 일하려니 한꺼번에 보이기 시작했다.
다시 따라잡으려면 당분간 뛰어야 할 것 같다. 아니, 뜀박질을 해야 할 것 같다.
]]></description><link>https://w0nder.land/posts/62-%EC%B7%A8%EB%BD%80</link><guid isPermaLink="false">62</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Fri, 06 Feb 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[버튼 하나 더 말고, 문제 하나 더 풀기]]></title><description><![CDATA[요즘 눈에 띄는 변화가 있다. 주변의 많은 제품이 MCP(Model Context Protocol)나 에이전트 연동에 집중하고 있다. 구글은 커머스 영역에서 UCP(Universal Commerce Protocol)를 내놓으며 같은 길을 걷고 있다. AI 검색에서 Gemini까지 결제가 통합되면 판매자는 프로토콜만 구현해도 AI 생태계에 자연스럽게 녹아든다.
처음에는 기술 트렌드의 하나로만 보였다. 단순한 변화는 아니다. 한때는 슬랙 연동, 노션 연동이 사용자 편의의 방향이었다. 이제 MCP와 에이전트가 그 자리를 잡아가고 있다. 프론트엔드와 UI의 자리를 Cursor나 Claude 같은 채팅 프로그램이 차지한다. 서비스 제공자는 MCP 같은 프로토콜로 필요한 기능만 열어주면 되는 구조가 만들어진다. 연동 방식이 바뀌는 것이 아니라, 제품이 가치를 전달하는 방식 자체가 바뀌고 있다.
여전히 많은 팀은 UI를 중심으로 제품을 만든다. 그렇게 만들다 보면 기능이 자연스럽게 늘어난다. 새 버튼, 설정 옵션, 필터와 예외 처리가 쌓여 간다. 사용성은 좋아진다. 대신 제품 가치가 뭔지는 흐려진다. "이걸로 뭘 할 수 있나요?"에는 대답할 수 있게 된다. "그래서 뭐가 해결되나요?"에는 말문이 막힌다. 기능은 많아졌는데 가치는 희석된다.
MCP 같은 프로토콜을 염두에 두고 설계하면 질문 자체가 바뀐다. "이 기능을 UI 어디에 배치할까?"가 아니라 "에이전트가 이 도구를 호출했을 때 어떤 문제가 해결될까?"를 묻게 된다. 이 질문에 명확한 답이 없다면 굳이 만들지 않아도 된다. 기능 개수는 줄어들지만 가치 밀도는 높아진다. 기능은 줄어들어도 가치는 더 뾰족해진다.
그런 차이는 설계의 기본 단위에서도 드러난다. 기존에는 사용자 플로우를 중심으로 생각했다. 사용자가 어디서 막히는지, 어느 버튼에서 이탈하는지, 어떤 화면에서 혼란스러워하는지 분석했다. 그걸 개선했다. 전체 여정을 부드럽게 만드는 것을 목표로 했다. 에이전트 중심으로 생각하면 플로우보다 태스크가 중심이 된다. 입력이 뭐고, 중간에 어떤 판단을 해야 하고, 최종 결과물이 무엇인지. 이 세 가지가 설계의 축을 이룬다. 여정의 매끄러움보다 일의 완결성이 더 중요해진다. 시작보다는 끝이 중요하다. 시작이면서 끝이 될 수 있으니까.
로드맵을 짜는 방식도 달라졌다. 예전에는 "다음 분기에 어떤 기능을 추가할까?"라고 물었다. 이제는 "다음에 어떤 판단을 자동화할까?"를 묻게 된다. 진화 과정은 대체로 비슷하다. 처음에는 데이터 수집을 자동화한다. 그다음에는 분류와 요약을 자동화한다. 마지막에는 특정 의사결정의 일부를 제품이 대신하기 시작한다. 단순한 기능 확장이 아니다. 사용자의 사고 과정 일부를 제품이 점점 흡수해 가는 과정에 해당한다. 에이전트가 도구를 호출할 때 보는 것은 화면이 아니다. "이 도구가 어떤 결과를 주는가"만 본다. 그래서 외형이나 UX보다 제품과 서비스가 실제로 제공하는 가치가 더 중요해진다. 그 가치의 대부분은 자신이 쌓은 데이터와 그 안에 들어 있는 인사이트다.
예를 들어 CRM에서 "작년에 연락했다가 결론 없이 끝난 고객들 뽑아 주고, 올해 다시 연락해서 미팅 예약까지 잡아줘"라고 하면 에이전트가 처리할 수 있다. 예전 같으면 검색 필터를 여러 개 만들고, 리스트 화면, 예약 플로우, UI를 잔뜩 구현해야 했다. 이제는 API만 연결하고 응답 카드만 만들면 된다. 혹은 에이전트가 "예약 만들어 두었어요"라고만 하고 끝내도 된다. 앱스토어 리뷰를 모아두는 서비스도 마찬가지다. 리뷰 텍스트와 메타데이터가 정리되어 있으면 "불만 포인트만 뽑아줘"를 한 번에 해결해 준다. UI를 어떻게 꾸몄는지보다 어떤 데이터를 얼마나 잘 다루는지가 호출 이유가 된다.
변화는 설계에만 머물지 않는다. 유통 채널에서도 흥미로운 변화가 생기고 있다. 사용자가 더 이상 우리 웹사이트를 직접 방문하지 않는다.
이미 그 신호들은 여러 곳에서 드러난다. Cursor나 Claude 같은 채팅 프로그램이 클라이언트 역할을 한다. 서비스 제공자는 MCP 서버로 기능만 열어주면 되는 구조다. 커머스도 마찬가지다. 구글 UCP에서는 검색과 Gemini가 클라이언트가 된다. 판매자는 프로토콜만 구현하면 AI 화면에서 바로 구매가 이루어진다.
이때 제품은 더 이상 독립적인 웹서비스가 아니다. 에이전트 생태계에 붙는 하나의 구성 요소가 된다. MCP 제공은 "예쁜 홈페이지 만들어서 사용자 유치하겠습니다"가 아니라 "프로토콜 잘 만들어서 사용자가 원하는 곳에서 우리 기능을 쓸 수 있게 하겠습니다"라는 전략을 뜻한다.
이게 훨씬 사용자 친화적이다. 사용자 입장에서는 새로운 앱을 배울 필요가 없다. 계정을 만들고 로그인할 필요도 없다. 그냥 평소 쓰던 채팅에서 말하면 된다.
OpenClaw 사용자들의 실제 반응이 그 실효성을 보여준다.
"Gmail, Calendar, WordPress, Hetzner를 Telegram에서 한 번에 관리해요." 각각의 앱을 열고 로그인하고 메뉴를 찾아 헤맬 필요가 없다. 그냥 텔레그램에서 말하면 된다.
"핸드폰으로 걸으면서 코드 스펙 파일을 만들었어요." 컴퓨터 켜고 에디터 열고 환경 세팅할 필요가 없다. 산책하면서 자연어로 말하면 끝이다.
"WhatsApp으로 항공편 체크인했어요." 항공사 앱 찾고, 비밀번호 찾고, 메뉴 뒤져가며 체크인 버튼을 누를 필요가 없다. 그냥 채팅으로 해결된다.
OpenClaw 사용자들이 공통적으로 하는 말이 있다. "새로운 걸 배울 필요가 없어요." 기존에 쓰던 채팅 앱에서 자연어로 말하면 모든 게 해결된다.
에이전트가 편하면 사용자도 편하다. 에이전트가 우리 서비스를 쉽게 호출할 수 있으면 사용자는 복잡한 UI를 배울 필요가 없다. 여러 서비스를 넘나들며 통합적으로 작업할 수 있고, 언제 어디서든 일관되게 접근할 수 있다. 매번 같은 정보를 반복 입력할 필요도 없다. 사용자와 서비스 사이의 마찰이 근본적으로 사라진다.
이런 흐름이 한데 모이면 한 가지가 분명해진다. 결국 MCP와 에이전트 중심 설계는 기술의 문제가 아니라 방향의 문제다. 아직 다들 이렇게 하고 있지는 않지만, 제품의 가치를 제대로 전달하려면 이런 방향으로 틀어야 한다. "우리가 뭘 만들 수 있을까?" 대신 "우리가 사용자 의도를 파악해서 어떤 걸 해줄 수 있을까?"를 묻게 만든다.
이 질문을 기준으로 제품을 재구성하면 기능은 줄어든다. 가치는 더 뾰족해진다. 구체적인 나아갈 방향은 명확하다. UI를 예쁘게 만들지 말고, 에이전트가 완벽하게 쓸 수 있는 도구를 만들어야 한다. 그게 진짜 사용자 중심 설계다. 사용자는 UI를 배우고 싶어 하지 않는다. 새로운 앱을 탐험하고 싶어 하지 않는다. 그냥 목적을 달성하고 싶을 뿐이다. 그 목적 달성을 가장 자연스럽게 도와주는 방식은 에이전트를 통한 대화다.
중간 과정의 복잡함은 에이전트가 처리한다. 사용자는 평소 쓰던 채팅에서 자연어로 말하기만 하면 된다. MCP와 에이전트 중심 설계가 만들어내는 새로운 제품 경험의 본질은 여기 있다. 버튼 하나를 더하기보다 문제 하나를 완전히 해결하는 편에 무게를 두는 편이 맞다.
]]></description><link>https://w0nder.land/posts/61-%EB%B2%84%ED%8A%BC%20%ED%95%98%EB%82%98%20%EB%8D%94%20%EB%A7%90%EA%B3%A0%2C%20%EB%AC%B8%EC%A0%9C%20%ED%95%98%EB%82%98%20%EB%8D%94%20%ED%92%80%EA%B8%B0</link><guid isPermaLink="false">61</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sat, 31 Jan 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[또다시 반복되는 기술 만능 프레임]]></title><description><![CDATA[요즘 AI 코딩 열풍을 보면서 몇 년 전이 떠오른다. MSA(마이크로서비스 아키텍처)가 모든 개발 문제의 해답처럼 여겨지던 그 시절 말이다.
당시에는 이랬다. 배포가 복잡하면 "MSA 하면 해결돼", 팀 간 갈등이 생기면 "서비스 분리하면 돼", 코드가 엉켜있으면 "마이크로서비스로 쪼개면 돼". 조직의 구조적 문제와 설계 이슈를 MSA라는 기술로 풀 수 있다고 믿었다.
지금은? 코딩이 어려우면 "AI 쓰면 돼", 학습이 힘들면 "AI한테 물어봐", 경험이 부족하면 "AI가 다 알려줘". 개발자의 역량 문제와 성장 과정의 어려움을 AI라는 도구로 해결할 수 있다고 여긴다.
겉보기에는 완전히 다른 이야기 같다. 하지만 본질은 똑같다. 근본적인 문제를 기술적 선택으로 우회하려는 사고방식이 그대로 반복되고 있다. 그래서 지금의 AI 붐을 단순한 기술 발전으로 보기보다는, 우리 업계에 주기적으로 나타나는 '기술 만능주의 사이클'의 또 다른 버전으로 이해해야 한다.
새로운 도구가 등장할 때마다 반복되는 이분법
역사를 돌이켜보면 혁신적인 도구가 나타날 때마다 항상 같은 패턴의 논쟁이 벌어진다. "이걸 안 쓰면 뒤처진다"는 쪽과 "이런 식으로 하면 실력이 늘지 않는다"는 쪽 사이에서.
구글링이 보편화됐을 때도 그랬다. "검색해서 복붙하는 건 진짜 개발이 아니다"라는 비판과 "정보 시대에 암기가 무슨 의미냐"는 반박이 맞섰다. MSA 열풍 때도 "아직도 모놀리식 고수하냐"와 "무작정 분리만 하면 되는 줄 아냐" 사이에서 비슷한 논쟁이 있었다.
지금 AI를 둘러싼 논란도 동일한 구조다. "AI 모르면 도태된다"와 "AI만 쓰면 바보 된다" 사이에서 말이다.
표면적으로는 도구 활용법에 대한 기술적 논의 같아 보이지만, 실제로는 어떤 문제를 누구의 책임으로 규정하느냐에 대한 근본적 관점 차이다. 결국 문제 정의 자체를 둘러싼 논쟁인 것이다.
MSA 만능론
몇 년 전 MSA 열풍을 자세히 분석해보자. 당시 많은 조직이 직면했던 전형적인 문제들은 이런 것들이었다:
배포 과정이 복잡하고 시간이 오래 걸린다. 여러 팀이 동시에 작업하면서 충돌과 병목이 빈발한다. 장애 발생 시 원인 파악이 어렵고 책임 소재가 불분명하다. 코드베이스가 비대해지면서 유지보수가 갈수록 힘들어진다.
이런 문제들의 실제 원인은 무엇이었을까? 대부분 조직 구조의 문제, 의사결정 프로세스의 문제, 도메인 경계 설정의 문제, 책임과 권한 분배의 문제였다. 즉, 사람과 조직 운영의 문제였다.
그런데 당시 주류 해결책은 어땠나?

조직 재편? "너무 복잡해"
프로세스 개선? "시간이 오래 걸려"
도메인 재설계? "당장 급한데"
MSA 도입? "바로 시작할 수 있어!"

결과는? 기술적 복잡도만 폭증했을 뿐 원래 문제들은 더 악화됐다. 분산 시스템 특유의 복잡성, 네트워크 지연과 장애, 데이터 정합성 문제, 모니터링과 디버깅의 어려움까지 보너스로 얻게 됐다.
핵심적인 부분은 MSA가 필요하다고 느껴질 정도면 이미 조직과 설계가 상당히 엉망인 상태인 것이다. 그 상황에서 기술적 분리만 강행하면 문제가 해결되는 게 아니라 더 복잡해질 뿐이다.
기술은 이미 존재하는 구조적 문제를 마법처럼 해결해주지 않는다.
AI 만능론
이제 현재 상황을 보자. AI 코딩과 학습을 둘러싼 전형적인 상황들은 이렇다:
개발 학습 곡선이 가파르다. 실무에서 요구하는 기술 수준이 높다. 경험을 쌓으려면 긴 시간과 수많은 시행착오가 필요하다. 빠른 성과를 내야 한다는 압박이 크다.
이런 문제들의 실제 원인은? 개발자 개인의 역량 부족, 체계적인 학습 경험의 부재, 사고 과정의 미숙함, 문제 해결 경험의 부족 등이다. 즉, 개인의 성장과 역량 개발 과정의 문제다.
그런데 지금 주류가 되고 있는 해결책은?

기초부터 체계적 학습? "너무 지루해"
시행착오를 통한 경험 축적? "비효율적이야"
단계적 역량 개발? "시간이 오래 걸려"
AI 활용? "바로 완성!"

결과는? 코드는 빨리 만들어지지만 본인의 이해도와 판단력은 전혀 늘지 않는다. 더 심각한 건 스스로 문제를 진단하고 해결하는 능력 자체가 퇴화된다는 점이다.
MSA 사례와 구조가 정확히 같다. 그때는 조직 문제를 기술로 덮으려 했고, 지금은 개인 역량 문제를 기술로 덮으려 한다. AI가 MSA보다 더 위험한 이유는 사고 과정 자체까지 대체할 수 있을 만큼 강력하기 때문이다.
구글링이나 컴파일러와 같은 추상화 아닐까?
"AI도 결국 더 좋은 도구일 뿐 아니냐"는 반론이 있을 수 있다. 하지만 중요한 차이가 있다.
구글링의 본질부터 보자. 구글링을 할 때는 검색 → 비교 → 이해 → 적용 → 디버깅이라는 과정을 거쳤다. 여러 검색 결과를 비교하고, 내 상황에 맞는지 판단하고, 실제 적용해보면서 문제를 해결해야 했다. 핵심은 최종 판단과 책임이 여전히 개발자에게 있었다는 점이다. 구글링은 정보 접근성을 높이는 도구였지, 사고를 대신하는 도구가 아니었다.
컴파일러 비유도 생각해보자. 일부에서는 AI를 "새로운 패러다임의 컴파일러"라고 부르기도 한다. 어셈블리에서 고급 언어로, 컴파일러 등장으로 개발 방식이 바뀐 것처럼 AI도 그런 전환점이라는 것이다.
하지만 컴파일러는 표현 방식의 추상화만 제공했다. 개발자는 여전히 알고리즘을 설계하고, 자료구조를 선택하고, 로직을 구성해야 했다. 컴파일러는 저수준 구현의 복잡함을 감춰줬을 뿐, 무엇을 어떻게 만들지는 여전히 개발자가 결정해야 했다.
AI의 질적 차이는 명확하다. AI는 질문 → 완성된 답안으로 직접 점프할 수 있게 해준다. 코드 작성은 물론이고 설계 방향, 구현 방법, 디버깅 전략까지 전 과정을 대체할 수 있다. 학습과 사고 과정 전체를 건너뛸 수 있게 하는 최초의 도구인 셈이다.
그래서 AI는 단순한 생산성 향상 도구가 아니라 사고와 학습의 구조 자체를 바꾸는 기술이다.
사라진 경험
실제 현장에서는 어떤 일이 벌어지고 있을까?
전형적인 패턴을 보자: 문제 발생 → AI에게 질문 → 완성된 코드 수신 → 작동 확인 → 다음 작업으로 이동. 이 과정에서 "왜 이런 방식으로 해결됐는지", "다른 접근법은 없었는지", "이 해법의 장단점은 무엇인지" 같은 고민은 생략된다.
결과적으로는? 완성된 기능의 개수는 늘어나고 개발 속도도 빨라지지만, 문제를 스스로 분해하고 해결하는 능력은 전혀 늘지 않는다. 비슷한 문제를 다시 만나도 여전히 AI에 의존할 수밖에 없고, 조금만 예외적이거나 복잡한 상황이 되면 속수무책이 된다.
이는 개인의 의지력이나 성실성 문제가 아니다. 인간 본성의 자연스러운 결과다. 사람은 본능적으로 고통스러운 과정은 피하고 즉각적 보상을 추구한다. AI의 "질문하면 바로 답변" 구조는 이런 인간 본성과 완벽하게 들어맞는다.
따라서 이는 개인의 도덕적 해이 문제가 아니라 도구 자체가 만드는 구조적 유혹의 문제다.
기초, 기초, 기초
AI가 발전할수록 기초가 더 중요해진다는 건 역설처럼 들리지만, 논리적으로 당연한 귀결이다.
AI가 여러 해답과 접근법을 제시할 때 필요한 능력들을 보자:

어떤 접근이 현재 상황에 적합한지 판단하는 능력
장기적으로 문제가 될 수 있는 설계를 걸러내는 능력
제시된 솔루션을 구체적 맥락에 맞게 조정하는 능력
AI 응답이 틀렸거나 부적절할 때 이를 발견할 수 있는 능력

계산기 비유로 이해해보자:

산수를 잘한다 = 기본 계산을 빠르고 정확하게 수행
계산기를 잘 쓴다 = 도구를 효율적으로 활용해서 복잡한 계산 처리
수학을 잘한다 = 어떤 계산이 필요한지 판단하고 문제를 수학적으로 모델링

이 세 능력은 분명히 연관되어 있지만 본질적으로 다른 영역이다. AI 코딩도 마찬가지다. AI로 코드를 생성하는 것과 어떤 코드가 필요한지 판단하는 것은 완전히 별개의 능력이다.
진짜 개발 실력은 결국 문제 정의, 접근법 선택, 결과 검증에서 갈린다. 이런 능력들은 AI가 주입해줄 수 없고, 오직 반복적인 사고 경험을 통해서만 축적될 수 있다.
과거를 돌아보면 흥미로운 사실이 있다. 구글링이 보편화된 후에도 주니어가 갑자기 시니어로 승격되는 일은 없었다.
주니어와 시니어의 실제 차이는?

주니어: 구글링으로 코드 조각 찾아서 복붙하고 "일단 작동한다"로 끝
시니어: 구글링으로 반복 작업 시간을 절약해서 더 본질적 문제에 집중

시니어는 절약한 시간을 전체 아키텍처 설계, 장기적 유지보수성 고려, 비즈니스 요구사항을 기술로 번역하는 작업 등에 투자했다. 하지만 그러려면 "무엇이 핵심이고 무엇이 부차적인지"를 구분할 수 있는 안목이 필요했고, 이는 탄탄한 기초에서만 나왔다.
노코드 툴로 드래그앤드롭해서 앱을 만들어 스토어에 올렸다고 해서 모바일 개발자가 되지는 않는다. 진짜 개발자와 "툴 사용자"의 차이는 "필요할 때 더 깊은 레벨까지 파고들어 문제를 해결할 수 있는 능력"이다. 이는 하루아침에 생기지 않으며, 기초부터 차근차근 쌓아올린 이해에서만 나온다.
중요한건 접근 방식 아닐까?
AI 자체가 문제가 아니다. 동일한 AI를 사용해도 완전히 다른 결과가 나올 수 있다. 핵심은 어떤 방식으로 접근하느냐다.
AI와 함께 사고하는 방식:

"이 문제를 어떻게 접근하는 게 좋을까?" → AI에게 조언 요청
제시된 여러 방법을 비교하고 각각의 장단점 분석
현재 제약조건과 맥락을 고려해서 최적안 선택
구현하면서 발생하는 이슈들을 스스로 판단하고 조정
결과를 검증하고 다음번에 응용할 수 있는 원리 추출

AI에게 사고를 맡기는 방식:

"이거 해결해줘" → AI 코드를 그대로 복사
작동하면 통과
왜 그렇게 됐는지는 관심 없음
다음 문제도 똑같이 AI에게 의존

이 둘의 차이는 단순히 생산성 차이가 아니라 성장 구조의 차이다. 전자는 AI를 활용해 경험과 역량을 확장하지만, 후자는 AI로 성장 과정 자체를 회피한다.
과거 구글링 시대의 시니어들이 검색으로 절약한 시간을 더 핵심적인 아키텍처 고민에 투자했던 것처럼, AI 시대의 진정한 전문가들은 AI로 절약한 시간을 더 높은 차원의 설계와 판단 능력 개발에 사용할 것이다.
기술은 구조도 실력도 만들어주지 않는다
결론적으로, MSA가 조직을 성숙하게 만들어주지 못했듯이, AI도 개발자를 자동으로 성장시켜주지는 않는다.
기술은 언제나 이미 갖춰진 구조와 역량을 증폭시킬 뿐, 없던 것을 무에서 창조해내지는 못한다. 탄탄한 기초와 올바른 접근법이 있는 상태에서 AI를 활용하면 놀라운 시너지를 낼 수 있다. 하지만 기초도 접근법도 잘못된 상태에서 AI를 쓰면 문제만 더 커진다.
그래서 정말 중요한 질문은 "어떤 도구를 쓸 것인가"가 아니라 "그 도구가 우리 사고를 확장시키고 있는가, 아니면 대체하고 있는가"다.
10년쯤 후에는 "AI 네이티브 세대가 기존 개발자들보다 훨씬 뛰어나다"는 말이 나올지도 모른다. 그리고 그때 또 새로운 혁명적 기술이 등장하면, 지금과 똑같은 논쟁이 다시 벌어질 것이다.
확실한 것은 올바른 접근 방식과 탄탄한 기초가 없다면, 어떤 기술이 나와도 결국 같은 실패 패턴을 반복하게 된다.
계산기를 쓰면서도 수학적 직관을 잃지 않는 수학자처럼, AI를 적극 활용하면서도 설계하고 판단하는 핵심 역량을 지속적으로 키워나가는 개발자가 되어야 한다. 그리고 그런 역량은 결국 탄탄한 기초 위에서만 자랄 수 있다.

과거에는 조직과 설계의 문제를 MSA라는 기술로 해결하려 했고, 지금은 개발자의 역량과 경험 문제를 AI라는 도구로 해결하려 한다. 대상은 달라졌지만, 기술로 본질을 덮으려는 사고방식은 전혀 변하지 않았다.
]]></description><link>https://w0nder.land/posts/60-%EB%98%90%EB%8B%A4%EC%8B%9C%20%EB%B0%98%EB%B3%B5%EB%90%98%EB%8A%94%20%EA%B8%B0%EC%88%A0%20%EB%A7%8C%EB%8A%A5%20%ED%94%84%EB%A0%88%EC%9E%84</link><guid isPermaLink="false">60</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Fri, 23 Jan 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[바이브 소송]]></title><description><![CDATA["바이브 코딩"이라는 말이 있다. 개발자가 깊은 고민 없이 직관과 느낌만으로 코딩하는 것을 뜻하는데, 이제 법률 분야에도 비슷한 현상이 나타나고 있다. 나는 이걸 '바이브 소송'이라고 부르고 싶다.
한 트윗에서 사기 피해액이 870만 원인데 변호사 수임료가 최소 150만 원이라는 말을 듣고 AI의 도움으로 셀프 소송을 진행해 승소했다는 내용을 보았다. 피해액의 17%가 넘는 수임료 때문에 포기할 뻔했던 소송을 AI가 가능하게 만들었다. 나는 이것이 단순한 개인의 성공담을 넘어, 우리 사회 전체에 큰 변화의 신호탄이 될 수 있다고 생각한다.
자세히 보면 법률 업무의 상당 부분은 반복적인 패턴을 가지고 있다. 소액 사기, 임금 체불, 보증금 반환 등 일상적인 분쟁들은 비슷한 절차와 서식을 따른다. 실제로 많은 블로그들이 이런 소액 분쟁을 해결하는 법적 절차를 쉽고 상세히 다루고 있다. 만약 AI가 "이런이런 소송하고 싶어, 어떻게 해야 해?"라는 질문에 관련 사례를 찾아주고, 맞춤형 서식을 만들어주며, 제출 방법까지 안내해준다면? 수백만 원의 비용 장벽 때문에 포기했던 정당한 권리 구제가 가능해진다.
이런 가능성은 법률뿐만 아니라 행정 분야로도 확장될 수 있다. 바이브 소송, 바이브 납세, 바이브 행정 툴들을 만들 수 있다. 어차피 반복되는 비슷한 케이스들이 많을 텐데, 미리 문서를 준비해두고 "나 이런이런 소송하고 싶어, 어떻게 해야 해?"라고 하면 사례를 찾아서 관련 문서 서식을 만들어주고, "이거 어디에 업로드해야 해?"라고 물으면 제출 방법까지 안내해주는 식이다. 그러면 그걸 업로드하고 신청하면 된다.
이제 전자 행정보다는 AI 행정, 바이브 행정이라고 부르는 시대가 왔으면 한다. 하지만 이런 변화는 예상치 못한 부작용도 낳을 것 같다. 내가 최근 다문화 가정에 IT 개발 교육을 하는 비영리 사단법인 설립 과정에 참여했다. 행정사나 법무사 없이 AI의 도움만으로 서류를 준비하고 진행하려 했지만, 공무원과 여러 차례 서류를 주고받는 일이 발생했다. 종이로 내야 해서 프린트도 여러 번 하고, 관련인들이 다시 모여서 도장을 찍고, 인감증명서가 모자라서 다시 추가 발급받아 오는 등 너무나도 많은 시간과 종이 낭비를 했다.
AI의 도움을 받아 바이브 행정을 진행하면서 서류를 명확하지 않게 준비하고 신청하게 되자, 나는 저비용으로 진행할 수 있었지만 실질적으로 그 모든 비용은 행정 비용으로 전가되었다. 내 시간도 추가로 소비되었지만, 그보다 담당 행정 인력의 시간이 훨씬 더 많이 소요되었을 것이다.
기존에는 행정사나 법무사 같은 전문가들이 관련 법령과 서식을 정확히 알고 서류를 작성했기 때문에, 심사 과정에서도 일정한 신뢰도가 전제되어 있었다. 하지만 AI 도구를 활용한 일반인의 직접 신청이 늘어나면서, 제출 서류에 대한 더 꼼꼼한 검증이 필요해진 상황이다. 결과적으로 행정 처리 시간이 길어지고, 공무원 업무량이 증가할 수밖에 없다.
이는 AI로 인해 법률 서비스 비용은 줄어들지만, 대신 행정 비용이 증가해 결국 세금 부담으로 돌아올 수 있다는 것이다. 개인이 150만 원을 절약하는 대신, 사회 전체가 그 비용을 나눠 부담하게 되는 구조다.
이런 문제는 우리나라의 행정 시스템이 가진 구조적 한계와도 맞물려 있다. 대한민국은 전자정부 순위에서 상위권을 차지할 만큼 전자행정이 발달했다고 평가받지만, 실제로는 아직도 종이 기반의 행정 절차가 상당 부분 남아있다. 온라인으로 신청을 받더라도 최종 제출은 종이 서류를 요구하거나, 전자 문서와 함께 원본 서류를 별도로 제출해야 하는 경우가 많다.
물론 이런 이중 확인 시스템에는 나름의 이유가 있다. 본인확인 강화, 서류 위조 방지, 비대면 업무 진행 과정에서 발생할 수 있는 보안 리스크 차단 등이 그것이다. 하지만 AI 시대에는 이런 보수적 접근이 오히려 혁신의 걸림돌이 될 수 있다.
그렇다면 해결책은 무엇일까? AI 시대에 더 나은 기술을 만들려면 모델 자체를 보유하는 것도 중요하지만, 실제로 AI가 우리 일상과 업무에 진정한 변화를 가져오려면 모델 그 자체보다도 더 중요한 것이 있다. 바로 융합 가능한 기반 서비스들이다. 바이브 소송이나 바이브 행정이 제대로 작동하려면 단순히 AI가 문서를 잘 작성하는 것만으로는 부족하다.
앞서 '바이브 소송' 이야기를 했을 때, 핵심은 AI가 소장을 잘 쓰는 능력만이 아니었다. 법률 데이터베이스에 접근하고, 관련 판례를 찾고, 법원 시스템에 제출하는 일련의 과정이 매끄럽게 연결되어야 한다는 점이었다. 이는 마치 스마트폰 생태계와 비슷하다.
아이폰이 성공한 이유는 단지 하드웨어가 좋아서가 아니라, App Store라는 플랫폼과 수많은 API들이 개발자들이 쉽게 다양한 앱을 만들 수 있게 해줬기 때문이다.
최근 등장한 MCP(Model Context Protocol) 같은 프로토콜은 이런 맥락에서 주목할 만하다. 다양한 서비스들이 AI 모델과 소통할 수 있는 표준화된 인터페이스를 제공한다. 이를 통해 AI는 단순히 텍스트를 생성하는 것을 넘어서, 실제로 외부 시스템과 상호작용하며 업무를 처리할 수 있게 된다.
더 나아가, 미래에는 AI 에이전트들이 서로 협업하는 '에이전트 경제'가 만들어질 수도 있다. 법무 에이전트가 회계 에이전트와 협업해서 세무 이슈가 포함된 계약서를 검토하고, 필요시 번역 에이전트의 도움을 받아 국제 계약도 처리하는 식이다. 이런 일이 가능하려면 각 분야의 전문 서비스들이 AI 친화적인 API를 제공해야 한다. 단순히 사람이 웹사이트에서 클릭하는 인터페이스가 아니라, 프로그래밍적으로 접근 가능한 구조화된 인터페이스여야 한다.
결국 AI 시대의 기술 주권은 단순히 좋은 모델을 가지는 것만이 아니다. 내 나라의 시스템들이 AI와 얼마나 잘 융합될 수 있는지, 그리고 그 융합을 통해 얼마나 혁신적인 서비스를 만들어낼 수 있는지가 더 중요할 수도 있다. 모델은 글로벌 경쟁이지만, 기반 서비스와의 융합은 각국의 고유한 영역이다. 한국만의 독특한 서비스 생태계와 AI의 만남에서 새로운 기회를 찾을 수 있으면 좋겠다.
]]></description><link>https://w0nder.land/posts/59-%EB%B0%94%EC%9D%B4%EB%B8%8C%20%EC%86%8C%EC%86%A1</link><guid isPermaLink="false">59</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Fri, 16 Jan 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[떠먹여주지 않고 스스로 먹게]]></title><description><![CDATA[요즘 코딩 과외 일정이 부쩍 늘었다. 처음엔 부업 정도로 생각했는데, 이제는 '이게 내 본업이 될 수도 있겠구나' 하는 생각이 든다. 예상치 못한 변화지만, 나쁘지 않다.
여러 학생들과 함께하면서 가르치는 일에 대해 많은 것을 느끼고 있다. 작년 하반기 컴공 겸임교수로 재직하면서 한 학기 동안 수업을 했던 경험이 지금도 많은 영향을 주고 있다. 그때 깨달았던 것은 교육이란 단순히 지식을 전달하는 게 아니라는 점이었다. 코딩을 처음 시작하는 사람, 미숙한 사람들이 어떻게 하면 더 집중할 수 있을지, 효과적인 교육 방법이 무엇인지 고민하게 됐다.
사람마다, 대상마다, 목적마다 교육 방식이 다르다. 신입이나 주니어의 경우와 아직 미취업한 학생들에게는 각각 다른 접근이 필요하다. 그래도 근본적으로 하나의 축은 있다. 내가 떠먹여주는 게 아니라 스스로 먹을 수 있게 하는 것이 목표다. 혼자 공부하다 보면 막히는 순간들이 있는데, 살짝만 도와줘도, 트리거만 줘도, 힌트만 줘도 언덕을 바로 뛰어넘어서 성장을 빠르게 도모하고 중도 포기하지 않게 계속 전진할 수 있다. 나의 역할이 바로 그런 것이다.
그리고 대부분 좀 더 빠른 길, 지름길, 꼼수 이런 것에 유혹되어 가볍게 넘어가려 하는데, 나는 그런 유혹에서 벗어나도록 이끈다. 기초에 대해서 깊게, 그리고 차분히 차근차근 하나씩 걸어가서 단단한 밑거름이 되게 하는 일을 한다. 그래서 단순히 기술을 전달하는 게 아니라 어떻게 하면 근본 원리를 깨우치고 공부하는 방법을 익히게 할 수 있는지에 집중한다.
최근에 OAuth 2.0을 공부하는 학생을 가이드하고 있다. 나는 특정 기술에 대해 강의를 해주지 않고 스스로 습득할 수 있게 도와주는 형식으로 한다. 개념을 먼저 이해하고, 스스로 설명해보는 방식으로 유도하고 있다. 학생은 내가 OAuth2를 잘 모르는 사람이라 여기고 차근차근 설명한다. 그리고 나는 그 설명을 들으면서 누락된 부분이나 확신이 없는 설명들에 질문을 하고, 부연설명을 해주며, 막히는 부분이 있으면 조금씩 설명을 늘려가면서 이해할 수 있도록 한다.
지난 시간에 이 학생이 OAuth의 인증 플로우를 그림으로 그려가며 설명하는 모습을 봤는데, 정말 놀랐다. 단순히 암기한 게 아니라 진짜로 이해하고 있다는 게 느껴졌다. 설명도 명확하고 논리적이었다. 그 순간 이 친구가 집에서 얼마나 열심히 공부했을지 상상이 됐다. 아마 여러 자료를 찾아보고, 이해 안 되는 부분은 반복해서 읽어보고, 그림도 그려가며 정리했을 것이다. 그런 노력의 결과를 보니 내가 다 뿌듯했다.
다른 학생들을 멘토링할 때도 비슷한 순간들이 있다. 각자 다른 방식으로 성장하는 모습을 지켜보는 것 자체가 특별하다. 어떤 학생은 질문을 많이 던지며 깊이 파고들고, 어떤 학생은 묵묵히 실습 위주로 접근한다. 저마다의 학습 스타일이 있고, 저마다의 속도가 있다.

그리고 학생들이 "말로만 조언하는 멘토가 아니라, 제가 어디서 막히는지 바로 짚어주셨어요.", "정말 많은 도움이 됐어요", "덕분에 이해할 수 있었습니다", "처음으로 제대로 이해했어요", "제품 중심 개발 마인드가 처음으로 ‘와닿았’습니다. 관점이 달라졌어요." 이렇게 건네는 말들을 들을 때마다 묘한 감정이 든다. 단순히 기분이 좋다는 차원을 넘어서는 무언가다. 내가 누군가에게 실질적인 도움을 주고 있다는 확신이 들고, 그 과정에서 나 자신도 변화하고 있다는 느낌이 든다. 기술을 가르치는 일이지만, 결국 사람과 사람 사이의 일이다. 그 과정에서 나 역시 더 성숙한 사람이 되어가고 있다. 어쩌면 이것도 하나의 길일지 모른다. 본업이 될 만큼 의미 있는 일이라면, 그것도 나쁘지 않은 선택이다.
]]></description><link>https://w0nder.land/posts/58-%EB%96%A0%EB%A8%B9%EC%97%AC%EC%A3%BC%EC%A7%80%20%EC%95%8A%EA%B3%A0%20%EC%8A%A4%EC%8A%A4%EB%A1%9C%20%EB%A8%B9%EA%B2%8C</link><guid isPermaLink="false">58</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Fri, 09 Jan 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[iOS 사진 접근 권한(Limited) 이슈 회고]]></title><description><![CDATA[showyourtime 앱을 React Native CLI에서 Expo로 마이그레이션하면서 사진 라이브러리 접근 부분을 react-native-cameraroll에서 expo-media-library로 교체했다. Expo의 표준 모듈을 사용하면 운영 복잡도를 줄일 수 있고, 사진 저장, 앨범 생성/조회, 자산 관리 등 필요한 기능을 폭넓게 제공한다는 점이 교체 결정의 이유였다. 하지만 이 전환 과정에서 iOS 사진 접근 권한과 관련된 예상치 못한 이슈를 마주하게 되었다.
교체 완료 후 몇 주간 내부 테스트를 진행했다. 기능 테스트에서 사진 저장은 정상 동작했고, 앨범 생성/조회 등 여러 시나리오에서도 문제가 없어 배포를 진행했다.
1. 문제 발생: "사진이 저장되지 않는다"
배포 후 고객으로부터 제보가 들어왔다. "사진이 저장되지 않아요." 처음에는 의아했다. 몇 주 동안 테스트했고, 저장 기능은 계속 정상으로 확인되었기 때문이다.
일반적으로 고려할 수 있는 가능성들은 다양했다. 특정 iOS 버전 호환성 문제, 특정 기기 모델 관련 문제, 미디어 형식(HEIC/Live Photo/GIF 등)별 처리 문제, 디스크 공간 부족이나 파일 I/O 오류 등 환경 변수들. 제보해주신 기기와, OS 그리고 사용하셨던 시간대를 바탕으로 Sentry의 여러 이슈들을 면밀히 확인한 결과 저장 시 권한 관련된 내용이 있었다. 권한 테스트를 해보니 Limited 권한 상태에서 문제가 재현되었다.
2. iOS 사진 권한 모델의 변화
iOS 14부터 Apple은 사진 권한 모델을 강화했다. 기존의 "허용/거부" 방식에서 다음과 같은 선택지로 확장되었다. 모든 사진 접근 허용(All Photos), 선택한 사진만 접근 허용(Limited Photos), 거부(Denied).
개인정보 보호 관점에서 Limited 권한은 매우 합리적인 기능이다. 사용자는 앱이 모든 사진에 접근할 필요가 없다고 판단할 수 있고, 필요한 사진 몇 장만 선별하여 허용할 수 있다. 실제로 많은 사용자가 이 옵션을 선택한다.
Limited 권한은 "모든 사진 접근"을 제한한다. 그러나 앱이 새로 생성한 항목(앱이 추가한 사진/앨범)에 대해서는 OS가 상대적으로 관대하게 처리한다. 따라서 "읽기(조회)"와 "쓰기(저장/추가)"의 권한 의미가 동일하지 않다. 즉, Limited 권한이라고 해서 "사진 저장이 불가능"한 것이 아니라, "사진 조회 범위가 제한되는 것"에 가깝다.
3. Expo Media Library의 문제점 분석
기존에 잘 동작하던 기능이 라이브러리 변경으로 동작하지 않는다면 라이브러리 자체의 문제일 가능성이 높다고 판단했다. 라이브러리의 네이티브 코드를 확인한 결과, 이번 이슈의 본질은 '저장은 가능한데, 라이브러리 구현이 이를 차단하고 있었다'는 점이었다.
Expo의 iOS 구현을 분석한 결과, 권한 체크 흐름이 두 가지로 나뉘어 있었다. 단순히 "권한이 부여되었는지"만 확인하는 체크(checkPermissions)와 "반드시 all 권한이어야만 가능"으로 강제하는 체크(runIfAllPermissionsWereGranted).
문제가 된 코드 로직
private func runIfAllPermissionsWereGranted(reject: ..., block: ...) {
  ...
  if permissions["status"] as? String != "granted" {
    reject(...)
    return
  }
  if permissions["accessPrivileges"] as? String != "all" {
    reject(...)
    return
  }
  block()
}

여기서 permissions["accessPrivileges"]가 "all"이 아니면(즉, "limited"여도) 무조건 권한이 없는 것으로 취급했다. iOS는 Limited 상태에서도 "사진 저장/추가"를 허용할 여지가 있지만, Expo 모듈은 그 이전 단계에서 "all이 아니면 불가"로 차단하고 있었다. 개발자 관점에서는 "안전한 선택"일 수 있지만, 실제 OS 정책과 비교하면 "필요 이상으로 보수적"인 접근이었다.
4. 아쉬운 테스트
가장 아쉬운 지점은 테스트였다. 몇 주 동안 테스트했지만, 대부분 사진 권한을 "허용(전체 허용)", 즉 accessPrivileges == "all" 상태를 전제로 진행했다.
일반적으로 "사진 저장 기능 테스트"라고 하면 저장 API 성공 여부, 앨범 저장 확인, 파일 정상성 등을 검증한다. 그런데 iOS에서 권한은 기능 로직과 분리된 "환경 변수"처럼 작동한다. 권한 상태가 달라지면 동일한 기능이 전혀 다른 경로를 탄다.
개발자가 테스트에서 쉽게 간과하는 이유가 있다. 기본적으로 테스트 기기에는 전체 허용을 설정하는 경우가 많다. 반면 일반 사용자들은 "전체 허용"에 거부감이 있어 Limited를 선택할 가능성이 높다. Limited는 "읽기/쓰기/선택 UI"가 복합적으로 얽히면서 UX까지 변경시킨다. 수주간의 테스트에도 불구하고 실제 사용자 환경에서는 문제가 발생했다.
5. 1차 해결: patch-package 활용
원인 분석이 끝나면 해결 방향은 명확해진다. accessPrivileges == "all"만 허용하던 체크를 accessPrivileges == "limited"도 허용하도록 완화하는 것이다.
하지만 현실적인 제약사항이 있었다. Expo 모듈은 JavaScript 레벨에서 해결할 수 있는 문제가 아니었고, iOS 네이티브 구현에서 예외를 발생시키며 차단하는 구조였다. 공개된 옵션이나 설정으로 우회할 방법이 보이지 않았다.
따라서 patch-package를 선택했다. node_modules 내 네이티브 코드를 수정하고 패치 파일로 관리하여 빌드 시 항상 해당 수정이 적용되도록 했다. 이렇게 "Limited도 통과"하도록 변경한 결과, 고객이 겪던 "저장 실패" 문제는 해결되었다.
6. 2차 문제: 지속적인 iOS 시스템 팝업
그러나 문제는 여기서 끝나지 않았다. Limited 권한 상태에서 저장을 반복 테스트하던 중, iOS가 자주 "추가 사진을 선택하시겠습니까?" 시스템 팝업을 띄우는 현상을 발견했다.
기능은 정상이지만 UX가 계속 방해받는 상황이었다. 이는 특히 showyourtime 같은 앱에서는 치명적이었다. 사용자는 "빨리 찍고, 빨리 공유/이탈"하고 싶어하는데, OS 팝업이 중간에 개입하면 사용 흐름이 깨진다. 사용자는 "앱이 자꾸 뭔가를 요구한다"는 부정적 인상을 받게 된다.
더욱 이상한 점은 경쟁 앱을 확인해보니 비슷한 상황에서도 이런 팝업이 뜨지 않았다는 것이었다. 즉, "원래 어쩔 수 없는 정책"이 아니라 "내가 놓친 설정이나 구현이 있다"는 의미였다.
Stack Overflow 검색, GitHub 이슈 탐색, LLM에게 상황 설명 후 해결책 문의등을 했다. 하지만 계속 수렴하는 결론은 "iOS 정책상 제한이니 어쩔 수 없다", "Limited에서는 원래 그렇다", "사용자에게 all로 변경하도록 안내하라"였다.
하지만 경쟁 앱에서 팝업이 뜨지 않는 것을 이미 확인한 상태에서 "어쩔 수 없다"는 결론은 현실과 맞지 않았다.
결국 답은 공식 문서에 있었다. PHPhotoLibraryPreventAutomaticLimitedAccessAlert라는 키였다.
Info.plist에 이 키를 true로 설정하면 iOS가 "자동으로" Limited 접근 확장 관련 알림을 띄우는 것을 방지할 수 있다. 대신 필요할 때 앱이 직접 presentLimitedLibraryPicker를 호출해서 사용자에게 선택 UI를 제공할 수 있다. 즉, OS가 상황에 따라 알아서 개입하던 UX를 "개발자가 통제"하도록 변경해주는 옵션이다.
적용 결과 저장 기능은 정상 유지되었고, 불필요한 시스템 팝업이 제거되었으며, 경쟁 앱과 동일한 UX를 구현할 수 있었다.
7. 그리고.
이번 이슈를 해결하는 과정에서 LLM에 의존하려고 하다가 시간을 허비한 부분들이 있었다. LLM에게 상황을 설명하고 해결책을 문의했지만, 계속 수렴하는 결론은 "iOS 정책상 제한이니 어쩔 수 없다", "Limited에서는 원래 그렇다"였다.
LLM이 모든 데이터를 학습했다고 해도 못 찾아주는 게 많다. 최종 해결책은 Apple 공식 문서에서 찾을 수 있었고, 문제를 해결한 것은 AI가 아니라 내가 직접 확인한 네이티브 코드와 공식 문서였다.
LLM은 도구일 뿐이고, 최종 답은 여전히 코드와 문서에서 나온다.

ps. 그리고 며칠 뒤 안드로이드에서 동일한 문의가 들어왔다. Android 16에서 동일한 권한 기능이 있었기 때문이다.
]]></description><link>https://w0nder.land/posts/57-iOS%20%EC%82%AC%EC%A7%84%20%EC%A0%91%EA%B7%BC%20%EA%B6%8C%ED%95%9C(Limited)%20%EC%9D%B4%EC%8A%88%20%ED%9A%8C%EA%B3%A0</link><guid isPermaLink="false">57</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Fri, 02 Jan 2026 09:00:00 GMT</pubDate></item><item><title><![CDATA[React Native CLI to EXPO]]></title><description><![CDATA[React Native(RN) 생태계에서 '자유도'는 오랫동안 가장 큰 장점으로 여겨져 왔다. 개발자가 네이티브 코드에 직접 접근할 수 있어 원하는 모든 커스터마이징이 가능하다는 점이 RN CLI의 핵심 가치였다. 하지만 프로젝트 규모가 커지고 운영 기간이 길어질수록 그 자유도는 점진적으로 유지보수 부담과 불확실성으로 전환되기 시작한다.
RN CLI 환경에서 프로젝트를 장기간 운영하며 이런 구조적 한계를 반복적으로 경험했다. 버전 업데이트마다 마주하는 수동 작업의 반복, 네이티브 설정 관리의 복잡성, 그리고 예측하기 어려운 빌드 이슈들이 누적되면서 개발 생산성보다는 인프라 관리에 더 많은 시간을 할애하게 되었다. 이런 문제를 해결하기 위해 일반적인 흐름과는 반대인 CLI → Expo 전환을 결정했다.

1. 반복되는 '수동 재구축'
RN CLI 환경에서의 버전 업데이트는 단순한 의존성 교체 작업이 아니다. 공식 문서에는 npm install과 몇 가지 설정 변경만으로 업데이트가 가능하다고 나와 있지만 현실적으로는 매번 반복되는 수동 재구축 과정에 가까웠다.
프로젝트 재생성의 반복
안정적인 업데이트를 보장하기 위한 한 가지 방법은 새로운 RN 버전으로 프로젝트를 새로 생성한 뒤 기존 비즈니스 로직과 라이브러리, 네이티브 설정(Native Configuration)을 하나씩 옮기는 것이다. 공식 업그레이드 가이드가 복잡하거나 여러 버전을 건너뛰어야 할 때 많은 개발팀이 실제로 이런 방식을 선택한다. 하지만 이 과정에서 놓치기 쉬운 설정들이 누적되면 업데이트 후 예상치 못한 동작이나 빌드 실패로 이어질 수 있다. 나도 여러 번 이런 방식을 택했고 매번 뭔가 놓치는 게 있었다.
네이티브 설정의 수작업 이전
AppDelegate, build.gradle, 권한 설정, 스키마 정의 등은 대부분 수동으로 이전해야 한다. 각 파일의 변경 사항을 비교하고 새로운 버전에 맞게 수정하는 과정에서 작은 누락이나 오타 하나가 원인을 알기 어려운 빌드 에러로 이어질 수 있다. 특히 Android의 경우 build.gradle의 의존성 버전 충돌이나 iOS의 경우 Info.plist 설정 누락 등은 디버깅에 많은 시간을 소모하게 만든다. 이런 걸 찾아내는 데 하루 종일 걸린 적도 있었다.
불확실성의 누적
공식 가이드를 정확히 따랐음에도 서드파티 라이브러리 충돌이나 네이티브 의존성(Native Dependency) 문제로 작업이 막히는 경우가 잦다. 각 라이브러리가 서로 다른 RN 버전을 요구하거나 네이티브 모듈이 최신 버전과 호환되지 않는 경우가 발생한다. 이런 상황에서는 업데이트를 중단하고 라이브러리 교체나 대안을 찾아야 하는데 이는 프로젝트의 기술 부채를 증가시키는 결과를 낳는다.
이런 과정은 단순히 엔지니어의 시간을 소모하는 것을 넘어 팀 전체가 업데이트를 기피하게 만드는 구조적 문제로 발전한다. 업데이트를 해야 한다는 걸 알면서도 그 과정이 너무 번거로워서 미루게 되는 것이다. 이건 기술적 문제라기보다는 프로세스의 문제다. 이런 '사람의 손'에 의존하는 프로세스를 '시스템'으로 바꾼 것이 바로 prebuild라고 생각했다.

2. 네이티브 코드는 재생성 가능한 산출물이다
Expo 전환을 결심하게 된 결정적인 계기는 prebuild 개념이었다. 이 개념을 접했을 때 네이티브 코드를 바라보는 관점이 근본적으로 바뀌어야 한다는 걸 깨달았다.
네이티브 코드의 재정의
기존 RN CLI 환경에서는 네이티브 코드(Native Code)를 "지속적으로 관리해야 할 소스"로 취급했다. ios/와 android/ 폴더의 모든 파일을 버전 관리하고 변경 사항을 추적하고 충돌을 해결해야 했다. 하지만 prebuild는 네이티브 코드를 언제든 다시 생성 가능한 산출물(Native Artifact)로 취급한다. 소스가 아니라 빌드 결과물처럼 다루는 것이다.
이 접근법이 맞다고 생각한 이유는 재생성 가능성에 있다. 네이티브 코드가 app.json과 Config Plugin이라는 선언적(Declarative) 설정에서 자동으로 생성된다는 점이 핵심이다. 개발자는 네이티브 코드를 직접 수정하지 않고 설정 파일만 관리하면 된다. 이렇게 하면 네이티브 코드의 일관성이 보장되고 업데이트 시 항상 최신 템플릿으로 재생성할 수 있다.
선언적 설정 기반의 안정성
네이티브 변경 사항은 모두 app.json과 Config Plugin으로 선언된다. 예를 들어 카메라 권한이 필요하다면 app.json에 권한을 명시하고, 특정 네이티브 모듈을 추가해야 한다면 Config Plugin을 작성한다. Expo는 이를 기반으로 항상 동일하고 클린한 네이티브 코드를 생성한다. 또한 어떤 환경에서든 동일한 설정으로 동일한 네이티브 코드를 생성할 수 있어 개발 환경 간 일관성이 보장된다.
업데이트 프로세스의 변화
과거에는 며칠씩 소요되던 RN 업데이트 작업이 이제는 훨씬 짧은 시간 안에 안전하게 수행 가능해졌다. Expo SDK 버전만 올리고 prebuild를 실행하면 새로운 SDK에 맞는 네이티브 코드가 자동으로 생성된다. 설정 파일에 문제가 없다면 대부분의 경우 빌드가 성공한다. 네이티브 코드를 직접 관리할 필요가 없기 때문에 업데이트 과정에서 발생할 수 있는 수동 작업의 실수나 누락이 차단된다. 실제로 전환 후 업데이트 시간이 며칠에서 몇 시간으로 줄어들었다.
3. 운영 관점에서의 합리성
일반적으로는 Expo에서 시작해 CLI로 이동하는 흐름이 언급된다. 초기에는 Expo의 제약이 불편하게 느껴지고 CLI로 전환하면 더 많은 자유를 얻을 수 있다고 생각하기 때문이다. 하지만 장기 운영 관점에서는 오히려 CLI에서 Expo로의 전환이 더 강력한 안정성을 제공한다고 판단했다.
Expo SDK라는 단일 기준점
RN CLI 환경에서는 여러 변수들의 호환성을 사람이 직접 판단해야 한다. React Native 버전, Android Gradle 버전, iOS 최소 버전, 각종 네이티브 라이브러리 버전 등이 모두 서로 호환되어야 하는데 이 조합의 수는 기하급수적으로 늘어난다. 각 라이브러리의 문서를 확인하고 GitHub 이슈를 검색하고 실제로 테스트해봐야만 안전한 업데이트 경로를 찾을 수 있다. 이런 과정을 반복하다 보니 체력적으로도 지치고 시간 낭비가 심했다.
반면 Expo는 SDK 버전을 중심으로 생태계를 정렬한다. 각 SDK 버전은 특정 RN 버전, 특정 네이티브 라이브러리 버전, 특정 빌드 도구 버전이 모두 호환되도록 검증되어 있다. 따라서 "SDK 50으로 업데이트하면 안전한가?"라는 질문에 대한 답은 "예"이다. 시스템 차원에서 보장되기 때문이다. 이 단일 기준점 덕분에 Expo 공식 라이브러리들도 SDK와 함께 테스트되고 버전 호환성이 보장된다. SDK가 기준이 되어 라이브러리까지 통제하는 구조다.
이 차이는 프로젝트 규모가 커질수록 더욱 명확해진다. 수십 개의 네이티브 라이브러리를 사용하는 프로젝트에서 CLI 환경의 호환성 문제를 해결하는 것은 점점 어려워진다. 하지만 Expo SDK는 이런 복잡성을 네이티브 레이어 추상화를 통해 해결한다. Expo 공식 라이브러리들은 전반적으로 품질과 문서화 수준이 높고 플랫폼 간 일관성이 우수하다. 또한 공식 문서가 상세하고 예제 코드가 풍부해 빠르게 학습하고 적용할 수 있다. 물론 일부 고급 제어가 부족한 영역이 있을 수 있지만 이런 경우에도 Config Plugin이나 Custom Native Module을 통해 확장할 수 있다. Expo는 제약을 강요하는 것이 아니라 표준화된 방식으로 확장할 수 있는 구조를 제공한다.
Config Plugin을 통한 변경 이력의 자산화
RN CLI 환경에서 네이티브 커스터마이징은 주로 파일을 직접 수정하는 방식으로 이루어진다. AppDelegate.swift에 코드를 추가하거나 build.gradle에 설정을 넣는 식이다. 이런 변경 사항은 시간이 지나면 왜 추가했는지, 어떤 문제를 해결하기 위한 것인지 기억하기 어려워진다. 이게 문제였다. 몇 달 전에 추가한 설정이 왜 필요한지 모르겠어서 삭제했다가 다시 추가한 적도 있다.
Expo의 Config Plugin은 이런 네이티브 커스터마이징을 코드로 관리한다. JavaScript나 TypeScript로 작성된 Plugin은 네이티브 코드를 어떻게 수정할지 명시적으로 정의한다. 네이티브 레이어의 변경(Modification)은 필연적이지만 그 방법을 직접 수정(Imperative)이 아닌 설정을 통한 플러그인 주입(Declarative) 방식으로 바꾼 것이다. 실제 네이티브 코드에 직접 수정하는 것이 아니라 별도로 분리해서 관리한다는 점이 핵심이다.
목적과 행동에 따라 Plugin으로 분리해두면 오류 발생 시 해당 Plugin만 격리하여 관리할 수 있다. 네이티브 코드에 수정 내역을 직접 기록(Hard-coding)하는 방식은 시간이 흐른 뒤 변경의 맥락을 파악하기 어렵게 만들지만 Config Plugin은 변경의 의도와 구현을 분리한다. 실제 네이티브 코드를 직접 수정하는 대신 별도의 플러그인으로 분리 관리한다는 점이 네이티브 변경 사항의 '가시성'을 확보해준다. 코드가 다소 생소할 수는 있으나 각 플러그인이 명확한 목적을 가진 독립된 모듈로 존재하므로 추적과 개선이 훨씬 가벼워진다. 변경 이력이 코드로 명확히 남아있어 문제 발생 시 원인 추적이 단순화되고 어떤 환경에서도 동일한 네이티브 상태를 재현할 수 있다.
또한 Config Plugin은 재사용 가능하다. 한 번 작성한 Plugin은 다른 프로젝트에서도 사용할 수 있고 커뮤니티에서 공유된 Plugin을 활용할 수도 있다. 이렇게 네이티브 커스터마이징의 지식이 코드로 축적되고 공유될 수 있게 된다.

4. 빌드와 배포 자동화
Expo는 개발 경험뿐 아니라 빌드·배포 영역에서도 성숙한 도구 체인을 제공한다. 이는 단순히 편의 기능을 넘어 운영의 예측 가능성과 재현성을 높이는 구조적 장점이다.
많은 개발자들이 Expo를 클라우드 빌드에 종속되는 것으로 오해한다. 하지만 실제로는 eas build --local 옵션을 통해 로컬 또는 사내 CI 환경을 그대로 활용할 수 있다. 기존 빌드 인프라를 유지하면서 Expo의 빌드 도구만 사용할 수 있다는 의미다.
로컬 빌드의 장점은 명확하다. 빌드 로그를 실시간으로 확인할 수 있고, 디버깅이 용이하며, 네트워크 지연 없이 빠르게 빌드할 수 있다. 또한 사내 보안 정책으로 인해 외부 클라우드 서비스를 사용할 수 없는 환경에서도 Expo를 활용할 수 있다.
하지만 더 중요한 건 빌드 환경 설정 자체다. RN CLI 환경에서는 각 개발자가 자신의 로컬 환경에 빌드 도구를 설치하고 설정해야 했다. Xcode, Android SDK, 각종 인증서와 키스토어 설정 등. 이 과정에서 환경 차이로 인한 빌드 실패가 빈번하게 발생했다. Expo는 이런 빌드 환경을 알아서 구성해준다. 환경 변수도 EAS에서 중앙 관리할 수 있어 각 개발자가 개별적으로 설정할 필요가 없다.
EAS는 Fastlane과 같은 자동화 도구의 복잡성을 추상화하여 제공한다. EAS Build는 내부적으로 Fastlane 혹은 그와 유사한 빌드 파이프라인 아키텍처를 사용하며, 개발자가 복잡한 Ruby 스크립트 작성 없이도 수준 높은 자동화를 누리게 해준다. Fastlane을 직접 구축하면 동일한 자동화를 구현할 수 있지만 제대로 구축하는 데 드는 시간과 노력을 생각해보면 EAS가 제공하는 가치가 명확해진다. Fastlane 설정 파일 작성, CI/CD 파이프라인 구축, 환경 변수 관리 시스템 구축 등. 이런 작업들을 모두 해야 한다. 그리고 현실적으로 Fastlane을 제대로 구축해놓은 개발팀이 더 많을까? 대부분의 팀은 그냥 수동으로 배포하거나 부분적으로만 자동화되어 있을 것이다. EAS는 이런 모든 인프라를 이미 구축해놓고 제공한다.

이번 전환의 목적은 단순히 "편해 보이기 때문"이 아니다. 지속 가능하고 예측 가능한 개발 구조를 선택하기 위함이다. 프로젝트가 장기적으로 운영될수록 일관성과 안정성이 생산성보다 더 중요한 가치가 된다고 생각한다.
RN CLI 환경에서는 네이티브 코드 관리, 버전 호환성 확인, 빌드 설정 유지보수 등에 많은 시간을 할애해야 했다. 이런 작업들은 개발의 핵심이 아니지만 프로젝트를 운영하기 위해서는 반드시 해야 하는 일들이다. Expo는 이런 작업들을 자동화하고 표준화함으로써 개발자가 사용자 가치와 비즈니스 로직에 집중할 수 있게 해준다.
CLI에서 Expo로의 전환은 기술 스택 변경을 넘어 개발 방식을 수동 관리의 시대를 지나 시스템 자동화의 시대로 나아가는 전략적 선택이다. 이는 단기적인 편의를 위한 것이 아니라 장기적인 안정성과 생산성을 위한 투자다. 초기 학습 곡선이 있더라도 그 이후로는 일관된 방식으로 작업할 수 있고 팀원이 바뀌어도 프로젝트의 구조를 쉽게 이해할 수 있다.
결론적으로 인프라 구축과 유지보수에 소모되던 에너지를 이제는 사용자 가치를 만드는 비즈니스 로직에 온전히 쏟을 수 있게 되었다. 장기적인 운영 안정성을 고민하는 팀이라면 이 패러다임의 전환은 선택이 아닌 필수적인 투자라고 확신한다. 지금까지의 경험을 돌이켜보면 이 선택이 맞았다고 생각한다.
]]></description><link>https://w0nder.land/posts/56-React%20Native%20CLI%20to%20EXPO</link><guid isPermaLink="false">56</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 25 Dec 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[AI가 대신할 수 없는 것]]></title><description><![CDATA[며칠 전 기술사 자격증 설명회에 다녀왔다. AI 시대가 가속화될수록 역설적으로 전문 자격증의 가치는 더욱 중요해질 것이라 생각한다. 이제는 단순한 지식 보유를 넘어 결과에 대해 '책임을 질 수 있는 자격'이 필요하기 때문이다.

AI가 아무리 뛰어난 업무 수행 능력을 보여도, 결코 대신할 수 없는 유일한 영역이 바로 '책임'이다. 아무리 치열하게 공부하고 빠르게 일해도 기술 발전 속도 앞에서 인간의 입지는 점차 줄어들 수밖에 없다. 그렇기에 AI 도입이 늦어지거나 구조적으로 불가능한 '책임의 영역'으로 시선을 돌려야 한다고 판단했다. 이 책임의 영역에서 일하는 것이야말로 70세를 넘어서도 이어질 기나긴 노동 생활을 지탱할 핵심 동력이라 여겼다. 이런 생각 끝에 기술사라는 전문 자격에 눈을 돌리게 되었다.
개발자로 현업을 지키며 여러 도메인에서 쌓아온 실무 경험을 천천히 되돌아보았다. 기술사가 나에게 가장 잘 맞는 길이자, 그간의 노력을 생산적으로 매듭지을 수 있는 정착지가 될 수도 있겠다는 기대를 품었다. 완전히 새로운 길을 찾기보다 내가 가진 기반 위에 전문성의 기둥을 세우는 것이 목표에 보다 수월하게 다다를 수 있는 현실적인 선택지로 보였다.
하지만 설명회에서 마주한 현실적인 장벽은 만만치 않았다. 기술사 시험은 단순히 업력이 많다고 합격할 수 있는 과정이 아니었다. 관련 기초 지식과 최신 동향을 바탕으로 10분 내에 1.5페이지 분량을 수기로 작성해야 하는 가혹한 과정이었다. 더욱이 총 54페이지를 하루 종일 써내려가야 한다. 수능 공부를 방불케 하는 1~2년의 집중적인 수험 생활은 물론이고, 모든 답안지를 손으로 직접 써내려가야 한다는 점이 평소 악필인 나에게는 결코 사소하지 않은 벽으로 느껴졌다.
단순히 지식을 아는 것을 넘어 채점관이 한눈에 파악할 수 있도록 정갈하고 논리적인 답안을 작성하는 '필력'을 갖추는 일은 실무와는 또 다른 차원의 도전으로 여겨졌다. 하루에 세 개 이상의 전문 주제를 깊이 있고 완벽하게 습득하고 막힘없이 글로 옮겨야 한다는 압박감에 '과연 내가 해낸 수 있을까' 하는 의구심이 들기도 했다.
여전히 주저하고 있다. 막상 뛰어들기엔 부담스럽고, 그렇다고 손 놓고 있기엔 아쉽다. 좀 더 생각해봐야겠다.
]]></description><link>https://w0nder.land/posts/55-AI%EA%B0%80%20%EB%8C%80%EC%8B%A0%ED%95%A0%20%EC%88%98%20%EC%97%86%EB%8A%94%20%EA%B2%83</link><guid isPermaLink="false">55</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 18 Dec 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[첫 학기 강의를 마치며]]></title><description><![CDATA[대학에서 첫 학기 강의를 마쳤다. 겸임교수로서의 첫 도전이었다. 학생들에게 정확한 지식을 전달하기 위해 강의자료를 준비하며 관련 내용을 다시 공부하고 철저히 검토했다. 그 과정에서 나 스스로 애매했던 부분들을 재확인하고, 학생들이 궁금해할 만한 지점들을 미리 준비할 수 있었다.
강의자료를 만들면서 내가 알고 있다고 생각했던 것들을 다시 확인하게 되었다. 설명해야 한다는 책임감이 생기니, 단순히 알고 있다는 것만으로는 부족했다. 정확한지, 최신 정보인지, 다른 관점은 없는지 다시 찾아보고 검증해야 했다. 그 과정에서 내가 잘못 알고 있던 부분들도 발견했다. 애매하게 알고 있던 개념들이 명확해졌고, 이론들 간의 연결고리도 더 분명해졌다.
중간에는 온라인 강의도 진행했다. 이클래스에 업로드할 강의 영상을 녹화하는 작업이었는데, 생각보다 훨씬 어려웠다. 예전에 노마드 워커 스쿨에서 첫 강의를 녹화해본 경험이 있어 이번에는 그때보다는 수월했지만, 여전히 현장 강의보다 더 힘들었다. 녹음, 녹화, 편집 과정을 모두 거쳐야 했고, 이 영상이 영구히 남는다는 부담감이 더욱 신중하게 만들었다. 한 번 잘못 말하면 그대로 남는다. 그 책임감의 무게가 다르다.
강의를 마치고 집에 돌아와서도 마음이 편치 않았다. 강의 내용을 다시 돌아보며 재점검했다. 잘못 전달한 내용은 없는지, 놓친 부분은 없는지. 문제가 있다면 즉시 보완하여 학생들에게 알렸다. 지식 전달에 대한 책임감이 그렇게 작동했다.
책을 쓰는 과정도 마찬가지다. 곧 출간할 책이 있는데, 내가 LLM 서비스를 개발하며 공부하고 실험했던 경험들을 정리한 것이다. 그 과정에서 관련 이론들을 다시 확인하고 체계화했다. 책에는 오류가 있어서는 안 된다. 한 번 출간되면 수정이 어렵고, 수많은 독자들이 읽게 된다. 그래서 검토 과정에 많은 시간을 투자했다. 두 번째 책이지만, 이런 과정을 통해 나 역시 많은 것을 다시 배우고 깨닫게 된다.
알고 있다고 생각했던 것들을 다시 확인하고, 남에게 설명해야 할 때 비로소 그 지식이 진정 내 것이 된다. 학생들에게 설명하려 하니 내가 놓치고 있던 부분들이 드러났고, 책으로 정리하려 하니 이론들 간의 연관성이 더욱 명확해졌다. 단순히 알고 있는 것과 제대로 이해하여 설명할 수 있는 것 사이에는 큰 차이가 있다.
강의자료를 만들고, 강의를 하고, 책을 쓰는 일련의 과정. 이런 산출물을 만드는 준비 과정에서 내가 아는 지식들에 대해 더 견고하게 알게 되고, 더 정확하게 알게 되며, 잘못 알고 있던 부분들도 개선된다. 이런 과정을 통해 전문가들도 스스로 더욱 성장하게 된다.
가르치는 것은 곧 배우는 것이고, 정리하는 것은 곧 이해하는 것이다.
]]></description><link>https://w0nder.land/posts/54-%EC%B2%AB%20%ED%95%99%EA%B8%B0%20%EA%B0%95%EC%9D%98%EB%A5%BC%20%EB%A7%88%EC%B9%98%EB%A9%B0</link><guid isPermaLink="false">54</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 11 Dec 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[실망과 함께 걷기]]></title><description><![CDATA[제품 만들기 챌린지를 운영하던 중 한 참여자로부터 메시지를 받았다. "사실 어제오늘 사용자 설문 메일을 보냈는데 응답이 0개라 약간 풀이 죽은 상태였는데요." 자신이 만든 앱을 열심히 사용하는 고객들에게 보낸 메일이었다고 했다. 그 짧은 문장에서 많은 실망감이 느껴졌다.
제품을 만들면서 마주하는 실망은 다양하다. 사용자 인터뷰에서 "이런 기능 있으면 쓸 것 같아요"라고 했던 사람들이 막상 기능을 만들어 내놓으면 침묵으로 답한다. "구매하겠다"던 사람들은 구매하지 않고, "사용하겠다"던 사람들은 사용하지 않는다. 요청해도 응답이 없고, "사람들이 이렇게 하면 쓰겠지"라는 예상은 빗나간다. 열심히 사용하는 사람들에게 설문을 보내도 답변은 0개다.
자기 제품을 한다는 것은 실망과의 싸움인 것 같다. 아니, 정확히는 싸움이라기보다 실망과 함께 살아가는 법을 배우는 것이다. 실망은 이 길의 단골손님이다. 매일 찾아와서 "오늘도 안 됐네"라고 속삭인다. 처음에는 이 목소리를 떨쳐내려고 애쓰지만, 실망을 완전히 없앨 수 없다.
그렇다면 방법은 하나다. 실망하지 말고 받아들이는 것. 그리고 다시 고쳐나가고 수정해 나가는 것. 실망을 없애려고 하면 오히려 더 힘들어진다. 실망은 이 일의 일부다. 제품을 만드는 사람이라면, 개발하는 사람이라면, 무언가를 도전하는 사람이라면 누구나 만나게 되는 동반자다. 그렇다면 실망에 멈춰 서지 말고 받아들이고, 고쳐나가고, 계속하는 것이 낫다.
실망이 와도 멈추지 않고 계속 걸어가는 것. 오늘 설문 응답이 0개여도 내일 또 보내고, 오늘 사용자가 없어도 내일 또 개선하고, 오늘 실패해도 내일 또 수정하고 도전하는 것. 그렇게 실망을 받아들이고 고쳐나가면서 하루하루를 이어가는 것이다.
그렇게 행동에 집중하며 실망과 함께 걸어가다 보면, 어느 순간 작은 것들이 쌓여 있다. 답장 하나, 새로운 유저 하나. 계단식 성장이라고 했듯이 평지가 더 길지만, 계단은 분명히 있다.
]]></description><link>https://w0nder.land/posts/53-%EC%8B%A4%EB%A7%9D%EA%B3%BC%20%ED%95%A8%EA%BB%98%20%EA%B1%B7%EA%B8%B0</link><guid isPermaLink="false">53</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 04 Dec 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[내가 팀원들과 일하는 방법]]></title><description><![CDATA[팀으로 함께 일한다는 것은 결국 대화를 나누고 의견을 교환하는 것이다. 그것을 회의라고 부를 수 있겠다.
회의 전에 미리 알고 있는 정보들을 먼저 공유한다. "이 기능을 만들어야 하는데, 이런 제약이 있고, 이런 요구사항들이 있습니다." 그리고 우리가 정해야 하는 것들, 논의해야 하는 목적에 대해 각자 생각해오라고 한다. "다음 회의에서 이 부분들을 결정해야 하니까 미리 생각해와 주세요."
회의실에 가기전 나도 미리 여러 생각들을 정리해뒀다. "이 기능은 이렇게 구현하면 좋겠다", "저 부분은 이런 접근이 필요할 것 같다." 머릿속으로 시나리오를 몇 번이고 돌려봤다. 하지만 회의가 시작되면 그 생각들을 바로 꺼내지 않는다. 대신 가볍게 "어떻게 하면 좋을까요?"라고 물어본다. 그리고 팀원들의 반응을 기다린다.
왜 이렇게 할까? 내가 먼저 답을 제시하면 팀원들은 그 프레임 안에서만 생각하게 된다. 리더의 의견이 먼저 나오는 순간, 다른 가능성들은 묻혀버린다. 게다가 팀원들은 내 의견에 반대하기보다는 동조하려는 경향이 있다. 이는 조직 내 권력 구조상 자연스러운 현상이지만, 창의적 사고를 막는 가장 큰 장벽이기도 하다.
먼저 내 의견을 숨기고 팀원들 의견을 충분히 듣는다. 이때 중요한 것은 진짜로 듣는 것이다. 형식적으로 "의견 있으세요?"라고 묻고 잠깐 기다린 후 내 이야기를 시작하는 것이 아니다. 팀원들이 편하게 이야기할 수 있는 분위기를 만들고, 그들의 생각이 충분히 나올 때까지 기다린다.
이렇게 하면 내가 미리 생각했던 것과는 전혀 다른 접근이 나올 때가 많다. 때로는 내 아이디어보다 훨씬 나은 것들이 나오기도 한다. 여러 관점에서 문제를 바라볼 수 있게 되고, 예상하지 못한 좋은 아이디어들이 등장한다. 그 순간이 가장 좋다.
하지만 듣는 것만으로는 부족하다. 질문을 던진다. "왜 이 방식을 선택했나요?", "이 결정을 뒷받침하는 근거는 무엇인가요?", "다른 선택지는 없을까요?" 이건 일부러 따져 묻는 게 아니다. 나도 정말 궁금하다. 어떤 사고 과정을 통해 그런 결정에 이르렀는지, 어떤 고민을 했는지 알고 싶다.
여기서 핵심은 질문의 의도다. 상대방을 곤란하게 하거나 내가 얼마나 똑똑한지 보여주려는 게 아니다. 그 사람의 사고 흐름을 진정으로 이해하고 싶어서 묻는 것이다. 그래야 내가 그 결정에 동의할지 반대할지, 어떤 의견을 보탤지 제대로 판단할 수 있다. 이런 진정성은 상대방도 느낄 수 있다.
질문을 통해 더 깊은 의도를 파악하게 되고, 질문을 받은 사람도 자신의 사고 과정을 다시 점검할 기회를 갖는다. 자기 생각의 빈틈을 발견하게 되고, 때로는 더 나은 아이디어로 발전시키기도 한다. 이 과정에서 모든 사람이 배운다.
처음에는 사람들이 방어적으로 답변한다. 질문을 받으면 자연스럽게 방어적이 되는 것이 인간의 본능이다. "내가 뭔가 잘못했나?", "내 아이디어가 부족한가?"라는 생각이 든다. 하지만 시간이 지나면 달라진다. 질문에 익숙해지고, 미리 생각을 정리해오기 시작한다. 자신의 결정에 대한 근거를 준비해온다.
이런 과정을 반복하다 보면 사람들은 변한다. 결과물과 자신을 분리해서 볼 수 있게 된다. "내 아이디어가 비판받았다"가 아니라 "우리가 함께 더 나은 방향을 찾고 있다"로 인식이 바뀐다. 판단의 깊이가 달라진다. 자신의 의견을 객관적으로 바라보고, 다른 관점을 수용할 수 있는 유연성이 생긴다.
팀원들의 의견을 충분히 듣고 질문까지 한 후, 그제서야 내 생각을 보태고 취합해서 마무리한다. 이때 내 생각은 여러 의견 중 하나일 뿐이다. 리더라고 해서 항상 옳은 것은 아니고, 가장 좋은 아이디어가 누구에게서 나올지는 아무도 모른다.
처음에는 시간이 더 걸린다. 하지만 이 과정에 익숙해지면 회의의 질이 완전히 달라진다. 단순히 의견을 나누거나 리더의 결정을 전달하는 시간이 아니라, 함께 생각을 깊게 탐구하고 더 나은 해결책을 찾아가는 시간이 된다. 팀 전체의 집단 지성이 발휘되는 순간이다.
실제 개발할 때도 마찬가지 원리를 적용한다. 세세하게 다 알려주지 않고, 일단 먼저 스스로 해보게 한다. 많은 리더들이 빠르게 답을 주는 것이 효율적이라고 생각하지만, 이는 단기적 관점일 뿐이다. 일일이 방법을 가르쳐주는 것보다 판단력을 키우는 것이 훨씬 더 중요하다.
직접 해보는 것의 학습 효과는 설명으로는 따라갈 수 없다. 에러 메시지를 직접 읽고, 문서를 스스로 찾아보고, 시행착오를 겪는 과정에서 진정한 이해가 일어난다. 이렇게 얻은 지식은 오래 남고, 비슷한 상황에서 응용할 수 있는 힘이 된다.
처음에는 팀원이 막막해한다. "어떻게 하면 되나요?"라고 물어볼 때가 많다. 이때 바로 답을 주고 싶은 유혹이 든다. 하지만 참는다. "일단 시도해보고, 막히는 부분이 있으면 함께 고민해봐요"라고 말한다. 물론 완전히 방치하는 것은 아니다. 적절한 방향을 제시하고, 필요할 때는 도움을 준다. 하지만 최대한 스스로 해볼 기회를 주려고 노력한다.
처음에는 시간이 더 걸린다. 하지만 장기적으로 보면 팀원들의 성장과 자립에 훨씬 도움이 된다. 더 중요한 것은 이런 과정을 통해 팀원들이 스스로 생각하고 판단하는 능력을 기르게 된다는 점이다. 그 모든 것이 판단력을 키운다.
이 방식은 단순히 효율적인 회의 방법이 아니다. 팀에 하나의 문화를 만든다. 질문에 익숙해지고, 자신의 생각을 객관적으로 바라볼 수 있게 되고, 스스로 판단하는 능력이 자라난다. 실수를 두려워하지 않고 도전하는 분위기가 형성된다. 서로의 의견을 존중하면서도 치열하게 토론할 수 있는 환경이 만들어진다.
리더인 나 역시 이 과정에서 많이 배운다. 팀원들의 다양한 관점을 접하면서 내 생각의 한계를 깨닫게 되고, 혼자서는 도달할 수 없는 아이디어들을 만나게 된다. 팀원들은 자립하는 능력을 키우고, 나는 더 나은 리더가 되기 위해 배운다. 진정한 의미에서 함께 성장하는 것이다.
]]></description><link>https://w0nder.land/posts/52-%EB%82%B4%EA%B0%80%20%ED%8C%80%EC%9B%90%EB%93%A4%EA%B3%BC%20%EC%9D%BC%ED%95%98%EB%8A%94%20%EB%B0%A9%EB%B2%95</link><guid isPermaLink="false">52</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 27 Nov 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[두려움과 떨림]]></title><description><![CDATA[대표라는 직함을 가지고 제품에 내 이름을 새기는 순간부터 두려움이 시작된 듯하다. 이 두려움은 일시적인 감정이 아닌 것 같다. 새로운 고객이 생기고 지표가 개선되며 작은 성과를 거두어도 사라지지 않는 걸 보면서, 성과가 쌓일수록 두려움은 오히려 깊어지는 것 같고, 그 무게가 마음을 무겁게 한다.
사람들이 자주 묻는다. 불안하지 않느냐고, 더딘 성장이 두렵지 않느냐고. 하지만 내가 경험하기로는, 두려움은 쉽게 사라질 수 있는 것이 아닌 듯하다. 창업자가 된 이상 사업을 접기 전까지는 매일 아침 눈을 뜰 때마다, 숨을 쉴 때마다 함께하는 것 같다. 그리고 그 두려움은 예상치 못한 순간에 온몸을 휩쓸고 지나가곤 한다.
고객은 참 예측하기 어려운 존재인 것 같다. 인터뷰에서 "정말 필요한 기능이에요"라고 말할 때의 진지한 눈빛은 분명 진심이었다. 그들의 불편함과 기대도 진실했다. 그런데 제품을 출시하면 찾아오는 건 침묵뿐이었다. 그토록 간절히 원했던 사람들이 정작 사용하지 않는다. 결제 직전까지 가다가 떠나고, 가입은 하지만 일주일 후에는 로그인하지 않는다.
이때의 두려움은 단순한 실망과는 조금 다른 것 같다. '고객의 마음을 잘 읽지 못한 건 아닐까, 내가 만든 해결책이 문제의 핵심에 닿지 못한 건 아닐까, 나에게 사업가로서의 자질이 부족한 건 아닐까.' 이런 생각들이 밀려오면 머릿속이 복잡해지고 생각이 잘 안 되는 것 같다. 논리적으로 분석해보려 해도 감정이 앞서고, 침착하려 해봐도 마음이 불안해지곤 한다.
두려움에 휩싸이다 보면 더 깊은 의심들이 고개를 드는 것 같다. '내가 길을 잘못 선택한 건 아닐까, 그때 그 선택을 하지 말았어야 했을까, 다른 길로 가야 하나.' 이런 생각들이 꼬리에 꼬리를 물며 마음을 복잡하게 만드는 것 같다.
스타트업에게 고객이 떠나는 일은 단순한 수치 이상인 것 같다. 그것은 내가 만든 것에 대한 거절처럼 느껴진다. 오늘 한 명이 떠나면 내일 또 다른 고객이 떠날 것 같은 불안이 밀려온다. 그런데 더 어려운 건 무관심인 것 같다. 떠나기라도 하면 반응이 있는 것인데, 아무도 우리를 필요로 하지 않는 순간이 더 막막하게 다가온다. 시장에서 보이지 않는 존재가 되어 아무리 말해도 반응이 없는 상태. 그 고요함 속에서 모든 확신이 흔들리는 기분이다.
이런 두려움들을 하나씩 써보니 다소 무겁게 들릴 수 있겠지만, 나는 조금 다르게 받아들이려 한다. 두려움을 인정하는 순간 마음이 오히려 편해지는 것을 느낀다. 그 떨림마저 자연스럽게 받아들여지는 것 같다. 두려움은 내가 이 일을 진지하게 대하고 있다는 신호라고 생각한다. 내가 만든 것에 대해 책임감을 느끼고 있다는 표시이며, 고객을 진심으로 생각하고 있다는 증거라고 여겨진다. 그 떨림은 살아서 움직이고 있음을 보여주는 것 같다.
창업자의 두려움은 없애야 할 문제가 아닌 것 같다. 받아들이고 함께 가야 할 것이라고 느낀다. 이 두려움과 매 순간의 떨림은 나를 더 민감하게, 더 신중하게, 더 겸손하게 만드는 것 같다. 편안함 속에서는 느낄 수 없는 생생한 감각인 듯하다.
사업을 마무리하는 그날까지 나는 이 두려움과 떨림을 품고 걸어갈 것 같다. 그것이 창업자로서 감당해야 할 몫이며, 동시에 내가 진짜 이 길을 걷고 있음을 보여주는 것이라는 생각이 든다.
]]></description><link>https://w0nder.land/posts/51-%EB%91%90%EB%A0%A4%EC%9B%80%EA%B3%BC%20%EB%96%A8%EB%A6%BC</link><guid isPermaLink="false">51</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 20 Nov 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[내가 공부하는 방법 (3) 라이브러리 코드 보기]]></title><description><![CDATA[내가 공부하는 방법 (3) 라이브러리 코드 보기
NOV 13, 2025 • 5분
내가 공부하는 세 번째 방법은 라이브러리 코드를 직접 분석하는 것이다. 이 방법의 시작은 첫 회사에서 리눅스 관련 개발을 맡게 되었을 때였다.
당시 나는 리눅스에 익숙하지 않았고, 리눅스 어플리케이션을 개발하려면 리눅스가 어떻게 동작하는지 잘 알고 있어야 한다고 생각했다. 그래서 인터넷에서 알게 된 리눅스 스터디 그룹에 참여했다. 전원이 인가되고 나서부터 시작되는 ARM 리눅스의 어셈블리 코드부터 시작해서 start_kernel()—부트로더가 커널을 메모리에 로드한 후 처음 실행하는 C 코드—까지 한 줄씩 분석하는 스터디였다. 이 경험은 오픈소스 코드에 대한 막연한 두려움을 완전히 없애주었다.
그 전까지는 '내가 그 큰 코드를 읽을 수 있을까?', '어디서부터 봐야 할까?', '이해가 될까?' 같은 의구심이 있었다. 그러나 스터디원들과 함께 '멘땅에 헤딩'하며 하나하나 확인하고 추측해가면서 코드의 역할과 영향을 파악했다. 지금 생각해보면 일부 해석이 틀렸을 수도 있다. 그때는 그저 비슷한 수준의 사람들이 모여 때로는 상상으로 정의한 부분도 있었다. 하지만 그런 과정 자체가 의미 있는 작업이었다. 완벽한 이해보다는 코드를 읽는 것에 대한 두려움을 없애고, 함께 탐구하며 배워가는 경험이 더 중요했기 때문이다.
몇 달간의 스터디 끝에 start_kernel까지 도달했을 때 모임은 자연스레 해체되었다. 하지만 나는 혼자서 계속 코드를 파고들었다. 운영체제 책에서 배운 이론들이 실제 리눅스 커널에서 어떻게 구현되었는지 확인하며 지식을 더 확고히 내 것으로 만들었다. 메모리 핸들링 부분까지 본 후에야 나도 그만두었지만, 이 경험은 내 개발자 경력에서 가장 소중한 자산이 되었다.
그 이후부터는 내가 사용하는, 혹은 사용하려는 라이브러리 코드들을 가볍게 뜯어보고, 분석하고, 문제가 발생하면 뜯어보면서 어디서 문제가 발생하고 어떻게 해결해야 하는지 자신있게 할 수 있게 된 것 같다.
라이브러리 코드를 분석하는 목적은 단순히 API 사용법을 익히는 것이 아니다. 설계자의 의도와 구현 방식을 이해함으로써 더 효율적으로 활용하고, 문제 상황에서 원인을 파악할 수 있게 되는 것이다. 코드를 '블랙박스'로 여기지 않고 내부 동작 원리까지 이해하면, 디버깅과 최적화에서 큰 차이가 생긴다.
라이브러리 코드 분석의 또 다른 장점은 고수들의 코딩 패턴과 설계 철학을 배울 수 있다는 점이다. 잘 설계된 오픈소스 프로젝트는 모듈화, 추상화, 에러 처리 등 소프트웨어 공학의 모범 사례를 담고 있다. 이런 코드를 읽는 것은 마치 대가의 작업실을 훔쳐보는 것과 같다.
리눅스 커널 코드 분석 이후, 회사 코드를 대하는 태도도 완전히 달라졌다. 막연하게 두려워하지 않고 내가 다 알고 있어야 하는 내용이라고 생각하게 되었다. 이제는 새로운 회사에 입사할 때마다 개인적으로 목표를 세우고 코드베이스 전체를 체계적으로 읽어본다. 입사 초기는 상대적으로 여유 시간이 많으니 충분히 해볼 만하다.
백엔드 코드를 분석할 때는 DB 모델부터 시작한다. '어떤 데이터를 저장하는가?'를 먼저 이해한 후, API 컨트롤러를 하나씩 살펴본다. 백그라운드 워커들도 별도로 분석하며, 이 과정에서 데이터 흐름 다이어그램을 그려나간다. 프론트엔드는 먼저 API 핸들러를 보고, 다음으로 각 페이지별 코드와 공통 컴포넌트를 분석한다.
이해가 안 되는 부분은 적극적으로 질문하고, 이해한 내용은 주석이나 문서로 남긴다. 이렇게 하면 내가 떠난 후에도 다음 개발자들이 쉽게 코드를 이해할 수 있다. 실제로 한 회사에서는 내가 작성한 코드 문서가 신규 입사자 온보딩 자료로 활용되기도 했다.
이런 방식으로 코드베이스를 체계적으로 분석하면 회사 업무에도 빠르게 적응할 수 있고, 업무 속도도 빨라진다. 코드 구조를 이미 파악했기 때문에 새로운 기능을 추가하거나 버그를 수정할 때 어디를 봐야 할지 바로 알 수 있다.
]]></description><link>https://w0nder.land/posts/50-%EB%82%B4%EA%B0%80%20%EA%B3%B5%EB%B6%80%ED%95%98%EB%8A%94%20%EB%B0%A9%EB%B2%95%20(3)%20%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC%20%EC%BD%94%EB%93%9C%20%EB%B3%B4%EA%B8%B0</link><guid isPermaLink="false">50</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 13 Nov 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[내가 공부하는 방법 (2) RFC 문서]]></title><description><![CDATA[내가 공부하는 두 번째 방법은 RFC 문서를 직접 읽는 것이다. 이 방법을 처음 접한 건 2014년, 회사에서 맡은 특별한 프로젝트 덕분이었다.
그때는 HTTP/2가 아직 공식 발표되기 전이었다. 하지만 업계에서는 이미 차세대 웹 프로토콜 논의가 한창이었다. 우리 팀의 미션은 “HTTP/2를 공식화되기 전에 미리 지원하는 서버를 구축하라”였다. 문제는 그 시점에 HTTP/2의 전신인 SPDY를 구현한 서버가 거의 Apache뿐이었다는 점이다. 제대로 된 한글 자료도 없었다.
구글에서 SPDY를 검색하다가 처음으로 RFC(Request for Comments) 라는 문서를 알게 되었다. RFC는 IETF에서 발행하는 기술 명세로, 이름 그대로 “의견을 요청하는 문서”라는 뜻을 가진다. 모든 RFC가 표준이 되는 것은 아니지만, 그중 상당수는 결국 인터넷의 공식 표준이 된다.
처음 접했을 때는 당황스러웠다. 책처럼 친절하지도 않고, 형식은 딱딱했다. 심지어 줄바꿈이나 문서 포맷이 낯설게 느껴졌다.
RFC를 읽는 목적은 단순히 참고 자료를 얻기 위함이 아니었다. 기술의 구조를 명확히 이해하고, 명세가 정의한 동작에 따라 구현하기 위해서였다. RFC는 "이렇게 동작해야 한다(MUST)"라는 형태로 구현체가 지켜야 할 기준을 명확히 규정한다. 개발자는 RFC를 통해 기술이 실제로 어떻게 작동해야 하는지, 어떤 제약과 예외가 존재하는지를 정확히 파악할 수 있다. 이 과정에서 API나 프레임워크 수준의 사용법을 넘어 프로토콜·포맷·아키텍처의 근본적인 설계 원리를 이해하게 된다.
RFC는 특정 기업이나 제품에 종속되지 않는다. 모든 구현체가 따라야 하는 공통 기준을 정의하기 때문이다. 그래서 RFC를 이해하면 어떤 프레임워크를 사용하더라도 기술의 본질을 꿰뚫을 수 있다. Axios가 아닌 HTTP 자체를, Socket.io가 아닌 WebSocket 프로토콜 자체를 이해하게 되는 것이다. 결국 RFC는 일시적인 트렌드나 도구를 넘어, 시간이 지나도 변하지 않는 기술의 원형과 규칙을 보여주는 문서다.
SPDY의 경우 나는 draft 1부터 최종 버전까지 전부 읽었다. 영어 문서라 쉽지 않았지만, ‘MUST’, ‘SHOULD’, ‘MAY’ 같은 단어가 단순한 동사가 아니라 구현 강제성의 정도를 나타낸다는 걸 배웠다. 나중에 RFC 2119에서 이 용어들이 공식 정의되어 있다는 것도 알게 되었다.
SPDY 스펙을 읽고 Apache의 mod_spdy 코드를 분석하며, 명세서에 적힌 내용이 실제로 어떻게 구현되는지 직접 확인했다. Wireshark로 패킷을 캡처해 실제 8바이트 헤더 구조 속에서 첫 비트가 control bit로 사용되는 걸 확인했을 때, 문서와 현실이 일치하는 그 순간의 쾌감은 이루 말할 수 없었다.
이 경험은 나중에 디버깅·보안·최적화 능력을 크게 키워주었다. RFC는 프로토콜의 경계와 예외 케이스를 명확히 정의하므로, 문제를 “버그”가 아닌 “규격 위반”으로 진단할 수 있게 된다. RFC 7231의 “safe methods” 개념만 이해해도 REST 설계 오류를 근본적으로 피할 수 있다.
RFC의 또 다른 장점은 변천 과정(draft history) 을 통해 기술의 진화를 따라갈 수 있다는 것이다. SPDY/1, SPDY/2, SPDY/3을 거쳐 HTTP/2로 발전하는 과정을 읽으면서 “왜 헤더 압축 방식이 바뀌었는가?”, “왜 서버 푸시가 도입되었는가?” 같은 맥락을 이해할 수 있었다.
한 번 RFC를 읽는 습관이 들자, 이후에는 다른 기술을 배울 때도 항상 RFC부터 찾게 되었다. 블로그나 책보다 더 정확하고 완전하기 때문이다. 진입장벽은 높지만, 익숙해지면 오히려 효율적이다.
이후 팀장이 된 뒤에는 이 방법을 팀원들과 공유했다. 특히 OAuth2를 다루던 시기, 여러 책의 설명이 제각각이라 RFC 6749를 팀 전체가 함께 스터디했다. 그 경험 덕분에 API 보안과 인증 로직을 설계할 때 흔들림이 없었다.

내가 RFC로 공부하는 방법

최신 버전만 보지 않는다. draft 변천사까지 읽으며 설계 배경을 이해한다.
명세만 보지 않는다. 실제 구현체와 비교하며 동작을 검증한다.
혼자 읽지 않는다. 동료들과 함께 토론하며 서로의 해석을 교차검증한다.

RFC는 분명 어렵지만, 기술의 근본을 이해하고 싶다면 이것만큼 확실한 자료는 없다.
]]></description><link>https://w0nder.land/posts/49-%EB%82%B4%EA%B0%80%20%EA%B3%B5%EB%B6%80%ED%95%98%EB%8A%94%20%EB%B0%A9%EB%B2%95%20(2)%20RFC%20%EB%AC%B8%EC%84%9C</link><guid isPermaLink="false">49</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 06 Nov 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[내가 공부하는 방법 (1) 책 읽기]]></title><description><![CDATA[학교에서 수업을 하면서 학생들이 어떻게 자기개발을 해야 하는지 질문을 하곤 한다. 그럴 때 나는 3개의 방법을 추천한다. 그 중 첫 번째가 바로 책을 3번 반복해서 읽는 방법이다.
나는 스스로를 비전공자라고 생각하지만, 전자공학과를 졸업하고 개발자가 된 나를 주변 사람들은 '반달'라고 불렀다. 반쪽짜리 전공자라는 뜻이었다. 공대를 나오긴 했지만 개발과 관련해서 배운 건 자료구조와 반도체 설계 수업의 일부였던 CPU 설계 정도가 전부였다.
내 주변 동기들은 대부분 삼성전자나 하이닉스 같은 반도체 회사, 현대건설이나 포스코 같은 건설·중공업 회사로 취업했다. 나는 공채로 입사한 회사에서 의도하지 않게 소프트웨어 개발부서에 배정받았다. 솔직히 말하면 그때는 소프트웨어 개발이 무엇인지도 제대로 몰랐다. 프로그래밍이라고는 학교에서 자료구조 몇 시간 배운 게 전부였는데, 갑자기 '개발자'라는 타이틀을 달고 일을 시작하게 된 것이다.
컴퓨터공학과 출신 동료들은 4년간 체계적으로 배운 알고리즘, 운영체제, 데이터베이스, 네트워크 등의 지식을 갖고 있었다. 나는 그들과 대화할 때마다 "아, 이건 학교에서 배웠는데"라는 말을 들으며 내 지식의 공백을 실감했다.
회사 동기들이나 선배들과 기술적인 대화를 할 때면 더욱 위축되었다. "이거 어떻게 하는 거예요?"라고 물어보고 싶었지만, 내가 얼마나 기초가 부족한지 드러날 것 같아 입이 떨어지지 않았다. 지금 생각하면 그렇게 부끄러워할 필요가 없었는데, 그때 나는 매우 미숙했다.
결국 혼자 할 수밖에 없었다. 어떤 커리큘럼을 따라야 하는지, 어떤 순서로 접근해야 하는지 몰랐다. 그때 떠오른 것이 책이었다. 어릴 때부터 책 읽기를 좋아했던 나에게는 가장 익숙한 학습 도구였다.
퇴근 후 서점에서 개발 서적 코너 앞에 한참을 서성였다. 'C++', 'Java', '알고리즘', '디자인 패턴'... 제목만 봐도 무슨 내용인지 알 수 없는 책들이 가득했다. 나는 당장 해야 할 업무를 잘 하고 싶었다. 윈도우에서 구현된 프로그램을 리눅스로 포팅하는 작업이었는데, 우선 기존 코드를 읽을 수 있어야 했다. MFC로 만들어진 프로그램이었기 때문에 MFC 관련 책을 선택했다.
집에서 책을 펼쳤을 때 첫 페이지부터 모르는 단어 투성이었다. 클래스, 객체, 상속, 다형성..., 모르는 단어가 나와도 멈추지 않고, 이해되지 않는 설명이 나와도 그냥 넘어갔다. 마치 외국 영화를 자막 없이 보는 것처럼 전체적인 흐름만 파악하려고 노력했다. 신기하게도 끝까지 읽고 나니 뭔가 느낌이 왔다. 정확하지는 않았지만 '아, 이런 느낌이구나', '이런 방향으로 가는 거구나' 하는 대략적인 감이 잡혔다.
첫 번째 읽기로 얻은 자신감을 바탕으로 두 번째 읽기에 도전했다. 이번에는 예제 코드를 하나하나 직접 타이핑해보기로 했다. 이론만으로는 부족하고 직접 손으로 만져봐야 한다고 생각했다. 처음에는 오타 때문에 에러가 나고, 설정 때문에 실행이 안 되는 일이 비일비재했다. 구글에서 에러 메시지를 검색하고 MSDN 문서를 뒤지며 하나씩 해결해나갔다. 여전히 이해되지 않는 부분들은 별도로 키워드를 정리해두었다. "나중에 이해하게 되겠지"라는 마음으로 일단 미뤄두었다.
마지막 예제까지 모두 실행한 후 다시 처음부터 가볍게 읽었다. 이번에는 예제를 따라 하지 않고 그냥 읽기만 했다. 이번에는 뭔가 달랐다. 두 번째 읽기에서 전혀 이해되지 않던 부분들이 갑자기 명확해지기 시작한 것이다. 복잡한 회로도를 보다가 갑자기 전체적인 동작 원리가 보이는 순간과 같았다. "아, 이래서 이렇게 했구나!", "이 부분은 이런 의미였구나!" 하는 깨달음의 순간들이 계속 이어졌다.
이런 식으로 계속 반복하다 보니 다른 책을 읽을 때 이전에 읽었던 책과 겹치는 내용들이 눈에 들어오기 시작했다. "아, 이건 저번에 본 개념이네"라고 생각하며 빠르게 이해하고 넘어갈 수 있었다. 처음에는 한 권을 읽는 데 몇 주가 걸렸지만, 어느 순간부터는 일주일에 한 권씩 읽어낼 수 있게 되었다. 기초 지식이 쌓이면서 새로운 내용을 받아들이는 속도가 빨라진 것이다.
신입 때 시작한 이 책 읽기 습관은 10년이 넘게 계속되고 있다. 지금도 1주에 1권씩 꾸준히 읽고 있다. 요즘에는 개발 서적보다 제품이나 비즈니스 관련 책을 더 많이 읽지만, 3단계 반복 학습법과 1주 1권이라는 페이스는 변하지 않았다. 첫 번째는 전체 흐름 파악, 두 번째는 세부 실습, 세 번째는 전체 이해 완성이다.
]]></description><link>https://w0nder.land/posts/48-%EB%82%B4%EA%B0%80%20%EA%B3%B5%EB%B6%80%ED%95%98%EB%8A%94%20%EB%B0%A9%EB%B2%95%20(1)%20%EC%B1%85%20%EC%9D%BD%EA%B8%B0</link><guid isPermaLink="false">48</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 30 Oct 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[안 해봤어요]]></title><description><![CDATA[면접관으로서 수많은 지원자를 만나며 가장 아쉬운 순간이 있다. 그 순간은 지원자가 답변을 잘 하지 못했을 때가 아니라, 함께 이어갈 수 있었던 대화가 갑자기 멈춰버릴 때이다.
"이런 상황에서 트랜잭션 충돌을 방지하려면 어떻게 하면 좋을까요?" 이런 질문을 던질 때, 나는 정답을 요구하는 것이 아니다. 개발에는 정답이 없으니까. 그저 함께 생각해보자는 제안에 가깝다. 하지만 종종 이런 대답이 돌아온다. "그건 저희 회사에선 안 써봤습니다." "그건 DBA가 관리해서 잘 몰라요." "그건 필요 없어서 안 했어요." 그 순간 대화는 멈춘다.
면접관의 질문은 공격이 아니다. "당신의 생각을 들려주세요"라는 요청에 가깝다. "스케일링을 위해 어떤 전략을 사용하겠습니까?"라고 물을 때 교과서 같은 답변을 듣고 싶은 게 아니다. 그 질문의 진짜 의도는 문제 상황에 대한 이해와 분석, 요구사항에 대한 깊은 질문과 정리, 사용할 수 있는 여러 자원들 파악, 그리고 디버깅과 고찰의 과정을 보는 것이다.
하지만 많은 지원자들이 이를 시험 문제처럼 받아들인다. 틀릴까 봐, 감점될까 봐 "그건 제 업무 범위가 아니었습니다"라는 방패를 든다. "안 해봤어요." 이 한 문장은 단순한 경험 부족의 고백이 아니라, 때로는 "이 주제에 대해 더 이야기하고 싶지 않습니다"라는 선언처럼 들린다.
면접관이 정말 보고 싶은 건 지식의 깊이가 아니다. 낯선 문제를 마주했을 때의 태도다. "해본 적은 없지만, 만약 그런 상황이라면 이렇게 접근할 것 같아요." 이 한 문장은 화려한 기술 스택보다 훨씬 강력한 신호가 된다. 그 사람은 멈추지 않고 생각할 줄 아는 사람이기 때문이다.
"안 해봤어요"는 벽을 세우고, "어떻게 할까요?"는 길을 만든다. 이 두 문장 사이에는 기술적 경험보다 훨씬 더 중요한 사고방식의 차이가 있다.
면접에서 가장 깊은 인상을 남기는 사람들은 '경험이 없다'고 솔직히 말하면서도 거기서 멈추지 않는 사람들이다. "정확히는 다뤄본 적이 없는데, 데이터 충돌을 막으려면 이런 접근이 필요하지 않을까요?" 이런 답변을 들으면 저절로 고개를 끄덕이게 된다.
나는 같이 일하고 싶은 사람이 많은 것을 알고 있는 사람이 아니라 같이 협업을 잘 할 수 있는 사람이다. 모르면 같이 공부하고 나눠주고, 다른 사람에게 잘 설명해주고 스스로 일어날 수 있게 도와주고 같이 고민하고 해결하며 성장하는 사람 말이다. 회사에서는 해본 것보다 안 해본 것을 하는 게 더 많을 텐데, 그런 것을 함께 도전하고 해결하며 성장하는 사람들을 찾는 것 아닌가.
좋은 개발자는 기술적 문제 앞에서 멈추지 않는다. 모르는 영역에 부딪혔을 때 어떻게 접근할 것인지, 누구에게 도움을 구할 것인지, 어떤 자료를 찾아볼 것인지 이미 알고 있다. 이것이 경험보다 중요한 메타 스킬이다.
결국 좋은 개발자의 조건은 모든 것을 알고 있는 것이 아니라, 모르는 것을 어떻게 알아가는지 아는 것이다. 그리고 그 과정을 혼자가 아닌 팀과 함께 해나갈 수 있는 것이다.
]]></description><link>https://w0nder.land/posts/47-%EC%95%88%20%ED%95%B4%EB%B4%A4%EC%96%B4%EC%9A%94</link><guid isPermaLink="false">47</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 23 Oct 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[작게 그리고 불편하게 시작하기]]></title><description><![CDATA[작게 그리고 불편하게 시작하기
이번 주 노마드워커스쿨 오프라인 모임에서 제가 가장 많이 한 말이 있습니다. "조금 더 작게 나누어 해보세요." "조금 더 자주 반복해보세요." "최소 기능만 빠르게 만들어보세요." "사용자에게 직접 피드백을 받아보세요."
참여자들이 가져온 아이디어는 모두 훌륭했지만, 대부분 처음부터 완벽하게 준비하려 했습니다. 완성형 제품을 한 번에 만들겠다는 마음가짐이었죠. 그게 낯설지 않았던 이유는 저희 팀도 예전에 똑같이 그랬기 때문입니다.
체커블에 '늦은 제출 허용' 기능을 만들 때 저희는 아주 큰 그림부터 그렸습니다. 기간 단위를 시간·일·주로 설정하고, 감점 비율을 조정하고, 참여자별 예외 처리와 자동 알림 기능까지 포함된 완전한 시스템을 계획했죠.
기획 문서는 수십 페이지가 되었고, 개발 일정은 최소 3주였습니다. 하지만 막상 시작하려니 불안했습니다. "정말 사용자들이 이 모든 걸 원할까?" "혹시 우리 머릿속에서만 필요한 기능은 아닐까?" "3주나 투자했는데 '이건 아닌데요'라는 반응이 나오면 어떡하지?"
그동안 제품을 만들어 가면서 깨달은 건, 말로만 정리해서는 절대 소통되지 않는다는 점입니다. 같이 오래 일한 사람들끼리도 '간단한 기능'의 기준이 다르고, 사용자와 이야기하면 그 차이는 훨씬 커집니다.
또한 사용자는 불편함을 느끼지만 그것을 '기능'으로 구체화하지 못합니다. 아무리 인터뷰를 하고 요구사항을 정리해도 실제 자신이 원하는 바를 정확히 표현하기 어렵습니다. 대개는 자신의 사고방식에 맞춰 요구사항을 재해석하여 설명하죠.
그래서 저희는 말 대신 프로토타입으로 대화하기로 했습니다.
아이디어를 자유롭게 펼친 다음, 진짜 중요한 한 가지를 골라 아주 작은 단위로 만들었습니다. "무엇을 만들까?"보다 "왜 필요한가?"를 먼저 정리하는 방식이었죠.
핵심은 '의도적으로 불편하게 시작하기'였습니다. 완벽한 기능은 보기엔 좋지만 문제를 찾기 어렵습니다. 반대로 단순하고 약간 불편한 기능은 사용자가 어디가 불편한지 구체적으로 알려줍니다.
첫 번째 버전은 정말 단순했습니다. 운영자가 '늦은 제출 허용 여부'를 켜거나 끄는 스위치 하나뿐이었습니다. 시간 단위 설정도, 예외 처리도, 알림 기능도 없었죠.
하루만에 이 기능을 만들 수 있었습니다. 하지만 그것으로 충분했습니다.
여기서 정말 중요한 부분이 시작됩니다. 저희는 한 번 만들고 끝내지 않았습니다. 작게 만들고, 피드백 받고, 다시 작게 만들고, 또 피드백 받는 반복 사이클을 계속해서 돌렸습니다. 한 번에 완성된 기능을 만들기보다 짧은 주기로 계속 개선하는 방식이었죠.
이 방식의 가장 큰 장점은 불필요한 것에 시간을 낭비하지 않는다는 점입니다. 3주짜리 개발 계획 중 실제 사용자에게 중요한 부분은 절반도 안 되는 경우가 많습니다. 작게 반복하면서 정말 필요한 부분에만 집중할 수 있었습니다.
또한 매 반복마다 방향을 조정할 수 있었습니다. 처음 생각했던 방향이 틀렸다는 것을 발견해도 손실은 최소화됩니다. 3주를 모두 투자한 후에 방향을 바꾸는 것보다, 3일 단위로 방향을 미세 조정하는 것이 훨씬 효율적이었습니다.
실제 사용자들에게 보여주자 반응이 완전히 달라졌습니다. 예전에는 "조금 더 유연했으면 좋겠어요"처럼 애매했는데, 이번에는 "마감 직후 1시간만 허용했으면 좋겠어요" 같은 구체적인 피드백이 즉시 나왔습니다.
이런 피드백을 바탕으로 또 작은 기능을 추가하고, 다시 사용자에게 보여주고, 또 피드백을 받는 과정을 반복했습니다. 매 반복마다 제품은 사용자가 진짜 원하는 방향으로 조금씩 진화했고, 불필요한 기능 개발에 시간을 낭비하지 않을 수 있었습니다.
챌린지 수정 기능을 만들 때도 비슷하게 접근했습니다. 수정 기능을 일부러 만들지 않고, 사용자 요청이 올 때마다 저희가 직접 데이터베이스를 수정해주었습니다. 3개월간 수동으로 처리하면서 모든 요청을 기록했죠.
이 과정에서 두 가지를 얻었습니다. 첫째, 수정 기능 개발을 미루는 동안 우선순위가 높은 다른 기능들을 먼저 만들 수 있었습니다. 둘째, 사용자들이 진짜 필요로 하는 수정 기능이 무엇인지 명확히 파악할 수 있었습니다.
결과는 예상과 완전히 달랐습니다. 텍스트 수정이 가장 많을 줄 알았는데, 참여자 변경 요청이 절반 이상이었습니다. 더 놀라운 건 챌린지 시작 후에 이런 요청이 급증했다는 점입니다. 참여자들이 챌린지 중간에 계속 조정이 필요했던 것이죠.
덕분에 처음 계획했던 범용 수정 기능 대신, 사용자가 실제로 필요로 하는 '참여자 관리' 기능에 집중할 수 있었습니다.
만약 처음부터 "수정 기능이 필요하세요?"라고 물었다면 "네"라는 단순한 답변만 들었을 겁니다. 하지만 실제 데이터는 완전히 다른 이야기를 들려주었습니다. 이렇게 실제 사용 패턴을 파악한 후에야 진짜 필요한 기능을, 필요한 순서대로 개발할 수 있었습니다.
이 경험 이후 저희 팀은 두 가지 원칙을 지키고 있습니다.
1. 크게 생각하되, 작게 시작하고 자주 반복하기
아이디어는 넓게 펼치되, 실제 구현은 핵심만 남기고 빠르게 반복한다.
2. 불편함을 두려워하지 않기
완벽한 기능보다 불편한 기능이 더 정확한 피드백을 가져온다.
이 방식은 특히 새로운 기능을 실험하거나 사용자 요구가 불분명할 때, 빠른 시장 검증이 필요할 때 효과적입니다.
아이디어를 모두 쏟아낸 후, 진짜 필요한 한 조각만 뽑아 3일 안에 만들어보세요. 그리고 "무엇이 필요하세요?"가 아니라 "어디가 불편했나요?"를 물어보세요. 그 피드백을 바탕으로 다시 작은 변화를 주고, 이 과정을 계속 반복하세요.
]]></description><link>https://w0nder.land/posts/46-%EC%9E%91%EA%B2%8C%20%EA%B7%B8%EB%A6%AC%EA%B3%A0%20%EB%B6%88%ED%8E%B8%ED%95%98%EA%B2%8C%20%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0</link><guid isPermaLink="false">46</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 16 Oct 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[내 회사 이름의 의미]]></title><description><![CDATA[사람들은 내게 회사 이름의 의미를 묻는다. fi-workers. 입 밖으로 내뱉으면 꼭 한 번쯤 다시 설명해야 하는 이름. 발음도, 철자도 낯설다. 상대는 고개를 갸우뚱하며 다시 한 번 물어본다. "파이... 워커스요?" 그럴 때마다 나는 천천히, 한 글자씩 풀어서 설명한다.
하지만 나는 그 낯섦이 좋다. 조금은 설명이 필요한 이름, 조금은 멈춰 서서 이야기를 나누게 만드는 이름. 이름을 설명하다 보면 자연스럽게 우리가 어떻게 일하는지, 무엇을 지향하는지를 말하게 된다.
이름 속 'fi'는 financial independence, 경제적 자유를 뜻한다.
경제적 자유라고 하면 보통은 '평생 일하지 않아도 될 만큼의 자산'을 떠올린다. FIRE 운동처럼, 젊을 때 열심히 벌고 아껴서 일찍 은퇴하는 것. 자산 수익만으로 생활할 수 있는 상태. 사람들은 그 말을 들으면 종종 눈빛이 달라진다. 부동산 투자나 배당 포트폴리오, 혹은 억대 자산을 떠올리는 것 같다.
하지만 내가 이 이름에 담고 싶었던 의미는 조금 다르다.
그건 일을 그만두는 게 아니다. 돈이 많아서 얻는 여유도 아니다. 오히려 그 반대에 가깝다. 돈이 기준이 되지 않는 상태. 경제적 이유로 하고 싶지 않은 일을 억지로 하지 않아도 되는 삶. 누군가를 설득하기 위해, 무언가를 증명하기 위해 내 시간을 쓰지 않아도 되는 삶. 적게 벌더라도, 내가 의미 있다고 느끼는 일을 선택할 수 있는 자유.
fi-workers라는 이름은 그런 태도로 일하는 사람들을 의미한다.
나는 더 이상 쫓기고 싶지 않다. 한때는 나도 그랬다. 더 빠르게, 더 높이, 더 멀리. 성장 곡선을 그리고, KPI를 달성하고, 다음 라운드를 준비했다. 그게 성공이라고 배웠고, 그렇게 사는 게 당연하다고 믿었다. 하지만 어느 순간 깨달았다. 내가 그렇게 사는 이유가, 내가 원해서가 아니라 남이 원해서 그랬다는 걸.
이제는 빠르게 성장하는 대신, 의미 있게 남고 싶다. 성공의 속도가 아니라, 지속의 리듬으로 살아가고 싶다.
일을 멈추고 싶다는 게 아니다. 오히려 일은 내 삶의 언어다. 아침에 일어나 노트북을 열고, 코드를 쓰거나 글을 다듬거나 누군가와 이야기를 나누는 그 시간들이 나를 살아있게 만든다. 다만 이제는 그 언어로 남을 설득하거나 증명하려 하지 않는다. 투자자를 감동시킬 피칭 덱을 만들지 않아도 되고, 시장의 기대에 맞춰 방향을 틀지 않아도 된다. 내가 하고 싶은 일을, 내가 납득할 수 있는 방식으로, 조용히 이어가고 싶을 뿐이다.
물론 최소한의 수익은 필요하다. 먹고살아야 하고, 가족을 돌봐야 하고, 가끔은 여행도 가고 싶다. 현실을 외면하자는 게 아니다. 하지만 그 이상을 끝없이 추구할 필요는 없다. 작년보다 두 배 성장하지 못해도 괜찮고, 업계 평균에 미치지 못해도 괜찮다.
조금 느려도 좋고, 작아도 괜찮다. 마치 동네 구멍가게처럼. 화려하진 않지만 필요한 건 다 있고, 주변 사람들이 필요할 때 찾아오는 그런 곳. 더하지도 덜하지도 않은, 딱 필요한 만큼만 채워진 공간.
그게 fi-workers라는 이름에 담긴 의미다.
나는 더 이상 '얼마나' 벌었는지로 자신을 설명하지 않는다. 명함에 적힌 직함이나, 포트폴리오에 나열된 숫자로 존재를 증명하지 않는다. 대신 '어떻게' 살아왔는지를 이야기한다. 어떤 선택을 했고, 무엇을 포기했으며, 왜 지금 이 자리에 있는지를.
쫓기지 않아도 괜찮다고, 그저 하루를 의미 있게 채우면 된다고, 그렇게 믿으며 오늘도 다시 문을 연다. 작은 가게처럼, 천천히, 하지만 멈추지 않고.
]]></description><link>https://w0nder.land/posts/45-%EB%82%B4%20%ED%9A%8C%EC%82%AC%20%EC%9D%B4%EB%A6%84%EC%9D%98%20%EC%9D%98%EB%AF%B8</link><guid isPermaLink="false">45</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 09 Oct 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[나는 관대하다]]></title><description><![CDATA[많은 시간을 들여 강의를 준비했다. 슬라이드를 다듬고, 예시를 고르고, 머릿속으로 몇 번이고 연습했다. 그러나 막상 강단에 서자 모든 것이 어긋났다. 말은 자꾸 꼬였고, 순서는 뒤섞였으며, 준비한 예시는 엉뚱한 순간에 튀어나왔다.
나는 속으로 스스로를 위로했다. "첫 강의니까, 누구나 그럴 수 있지." 그런데 만약 다른 강사가 같은 실수를 했다면 나는 과연 같은 말을 했을까? 아마 "준비가 부족했군"이라고 냉정히 평가했을 것이다. 그 순간, 남의 어설픔에는 엄격하면서 내 어설픔에는 관대한 나 자신을 마주했다.
이 이중 잣대는 강의실에만 머무르지 않는다. 식당에서 음식이 늦게 나오면 우리는 금세 불친절을 떠올리지만, 내가 약속에 늦으면 교통 체증과 돌발 변수를 탓한다. 동료가 발표를 망치면 준비 부족을 의심하면서도, 내가 같은 상황에 처하면 바쁜 일정을 이유로 든다. 누구도 예외가 없다.
심리학은 이런 현상을 오래전부터 설명해왔다. 사회심리학자 리 로스가 1970년대에 제시한 기본 귀인 오류가 대표적이다. 우리는 타인의 행동을 해석할 때 상황보다 성격이나 능력을 과도하게 강조한다. 발표를 망친 동료를 보면 곧장 "준비가 부족하다"고 단정하지만, 내가 같은 실수를 하면 "시간이 모자랐다"는 상황을 먼저 떠올린다.
여기에 자기편향이 겹쳐진다. 성공은 내 능력 덕분이고, 실패는 외부 탓이라고 믿는 태도다. 프로젝트가 잘되면 "내가 잘해서"라고 말하면서, 실패하면 "운이 나빴다"고 여긴다. 이는 자존감을 지켜주는 방패가 되기도 하지만, 동시에 책임을 회피하게 만드는 함정이기도 하다.
이러한 심리적 편향은 단순한 버릇이 아니다. 진화적 관점에서 보면, 자기 자신에게 관대하지 못하면 자존감은 쉽게 무너지고, 타인에게 지나치게 관대하면 경쟁에서 밀려날 위험이 크다. 나에게는 관대하고 남에게는 엄격한 태도는 인간이 사회적 존재로 살아남기 위해 무의식적으로 발달시킨 심리적 방어 장치인 셈이다.
그러나 문제는 이 착각이 모두에게 동시에 일어난다는 점이다. 교통체증에 갇힌 운전자들이 하나같이 "막히는 건 다 남 때문"이라 믿는 것처럼, 우리 모두는 자신이 예외라고 생각한다. 그 순간 집단 전체는 같은 모순을 반복한다.
인터넷 리뷰 문화도 다르지 않다. 소비자일 때 우리는 서비스 제공자에게 완벽을 요구하지만, 제공자의 자리에 서면 사정을 호소한다. 사정이 있었다, 상황이 힘들었다고. 우리는 끊임없이 평가자와 피평가자의 자리를 오가며 살지만, 그때마다 잣대는 극적으로 달라진다. 모두가 그렇기 때문에, 이것은 사회의 보편적 진실이 된다.
이 보편적 진실이 문제가 되는 이유는 간단하다. 우리 모두가 서로에게는 엄격한 잣대를 들이대면서도, 자신에게만은 관대한 기준을 적용하기 때문이다. 그 결과 우리는 서로를 이해하지 못한 채 불필요한 갈등과 오해를 반복한다. 이런 이중 잣대가 쌓이면 사회 전체의 신뢰가 훼손된다. 서로를 의심하고 실수를 용납하지 않는 분위기 속에서, 결국 아무도 새로운 시도를 하지 않게 된다. 모두가 실수를 두려워하며 움츠러든다.
그렇다면 이 악순환을 어떻게 끊을 수 있을까? 답은 의외로 단순하다. 남에게 관대해지는 것이다. 이는 단순한 미덕이 아니라, 함께 살아가기 위한 최소한의 조건이다.
돌이켜보면 나 역시 수많은 순간, 타인의 관용 덕분에 버텨왔다. 내 어설픔을 이해해 준 누군가가 있었기에 지금의 내가 있다. 그렇다면 이제 내가 그 관용을 돌려줄 차례다. 내가 내게 부여했던 사정을 남에게도 허용할 때, 관계는 단절되지 않고 이어진다.
관대함은 실수를 덮어주거나 책임을 면제해주는 일이 아니다. 상대의 어설픔 속에서도 맥락을 상상하고, 그럼에도 불구하고 성장할 가능성을 신뢰하는 태도다. 완벽은 누구에게도 불가능하지만, 불완전함을 견뎌내며 함께 나아가는 태도는 가능하다. 그런 작은 관대함이 개입하는 관계는 오히려 더 단단해진다.
더 나아가 관대함은 사회적 신뢰를 쌓는 방식이기도 하다. 타인의 어설픔을 받아들일 때 우리는 불신 대신 신뢰를, 고립 대신 연대를 선택한다. 관대함은 결국 나를 위한 일이기도 하다. 내가 내게 허용한 변명을 남에게도 내어줄 때, 우리는 각자의 불완전함 속에서도 함께 살아갈 힘을 얻는다.
결국 우리 모두는 같은 조건 속에 있다. 완벽을 요구할 수 없는 존재들, 실수와 어설픔이 삶의 일부인 존재들. 그렇다면 결론은 분명하다. 나에게처럼, 남에게도 관대해지자.
]]></description><link>https://w0nder.land/posts/44-%EB%82%98%EB%8A%94%20%EA%B4%80%EB%8C%80%ED%95%98%EB%8B%A4</link><guid isPermaLink="false">44</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 02 Oct 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[내가 보고 싶었던 이력서]]></title><description><![CDATA[지난 편에서는 8년간의 채용 경험을 통해 깨달은 채용의 본질과 철학에 대해 이야기했습니다. 이번 편에서는 100명이상의 많은 개발자와 만나면서 발견한 구체적인 패턴들과 실용적인 조언을 나누겠습니다.
안타까움
멘토링을 하면서 가장 안타까웠던 점은, 대부분의 지원자들이 충분히 좋은 경험을 가지고 있음에도 불구하고 이를 이력서에 제대로 표현하지 못한다는 것이었습니다.
예를 들어, "이 프로젝트를 3개월간 진행했습니다"라고 단순하게 적어놓은 지원자에게 저는 이런 질문들을 던져봤습니다.

"그 프로젝트를 진행하면서 예상치 못한 문제는 없었나요?"
"팀원들과 의견이 달랐던 적은 없었나요?"
"처음 계획했던 것과 달라진 부분이 있나요?"

그러면 훨씬 더 구체적이고 흥미로운 이야기들이 나왔습니다. 어떤 개발자는 이렇게 말했습니다.

"사실 중간에 기술 스택을 바꿔야 했어요. 처음에는 A 기술을 쓰려고 했는데, 성능 이슈가 있어서 B로 전환했거든요. 그 과정에서 팀 전체가 새로운 기술을 배워야 했고, 일정이 지연될 위험이 있었지만..."

이런 내용이야말로 이력서에 들어가야 할 가치 있는 경험인데, 정작 이력서에는 "○○ 프로젝트 개발 참여"라고만 적혀 있었습니다.
이런 경험이 반복되면서 사람들이 자신의 경험을 과소평가하는 경향이 있다는 것을 깨달았습니다. '이 정도는 누구나 겪는 일이겠지', '이런 걸 굳이 써야 하나?' 같은 의구심 때문일 것입니다. 하지만 채용 담당자 입장에서는 바로 그런 구체적인 경험과 문제 해결 과정에서의 사고방식이 궁금한 것입니다.
의미 없는 수치들
먼저 '기여도'라는 표현에 대해 이야기해보겠습니다. "이 프로젝트에 40% 기여했습니다"라고 적힌 이력서를 자주 봅니다. 하지만 이 40%라는 숫자가 정확히 무엇을 의미하는지 알기 어렵습니다.
예를 들어 3명이서 한 프로젝트라면, 수학적으로는 각각 33.3%씩 기여해야 합니다. 그런데 실제로는 한 명은 40%를 했다고 하고, 다른 한 명은 50%를 했다고 합니다. 그렇다면 나머지 한 명은 10%만 한 건가요? 아니면 모든 사람이 자신의 기여도를 높게 평가하는 건가요?
기여도의 기준도 애매합니다. 코딩한 줄 수로 계산하는 건가요? 그렇다면 같은 기능을 100줄로 구현한 사람과 50줄로 구현한 사람 중 누가 더 기여한 건가요? 아니면 참여한 시간으로 계산하는 건가요? 그렇다면 10시간 만에 핵심 기능을 구현한 사람과 30시간에 걸쳐 부가 기능을 만든 사람 중 누가 더 기여한 건가요?
실제 프로젝트에서는 각자 다른 역할을 합니다. 누군가는 초기 설계를, 누군가는 핵심 로직 구현을, 누군가는 테스트와 디버깅을 담당합니다. 이처럼 서로 다른 역할들을 하나의 퍼센트로 표현하는 것은 무의미하다고 생각합니다.
차라리 "프로젝트에서 제가 담당한 역할은 ○○였고, 그 과정에서 ××한 문제를 △△한 방식으로 해결했습니다"라고 구체적으로 설명하는 것이 훨씬 의미 있습니다.
매출 기여도도 비슷한 문제가 있습니다. "이 기능을 개발해서 매출이 20% 증가했습니다"라는 표현을 가끔 봅니다. 하지만 매출 증가에는 정말 많은 요인들이 작용합니다. 새로운 기능의 효과일 수도 있지만, 마케팅 캠페인, 시장 상황의 변화, 경쟁사의 실수 등 다양한 변수가 있습니다. 특히 개발자나 디자이너처럼 직접적으로 비즈니스에 관여하지 않는 직군에서는 이런 표현이 설득력이 떨어질 수 있습니다.
물론 경력이 많거나 비즈니스에 직접 관여하는 역할이라면 이런 지표들이 의미가 있을 수 있습니다. 하지만 대부분의 개발자들에게는 "어떤 기능을 어떻게 구현했는지", "그 과정에서 어떤 고민과 선택이 있었는지"가 더 중요한 정보라고 생각합니다.
빈 링크
GitHub 링크나 블로그 링크를 이력서에 넣는 경우가 많습니다. 이런 링크를 넣는 이유는 대개 두 가지인 것 같습니다. 하나는 개발 실력을 보여주기 위해서이고, 다른 하나는 성실함을 어필하기 위해서입니다.
하지만 여기에는 큰 함정이 있습니다. 링크를 넣어놓고 막상 들어가 보면 아무것도 없거나 거의 비어있는 경우가 있습니다. 이런 경우에는 오히려 마이너스가 됩니다. 차라리 링크를 넣지 않는 것이 나을 수도 있습니다.
GitHub의 경우를 예로 들어보겠습니다. 채용 담당자가 GitHub 링크를 클릭했을 때, 만약 저장소가 거의 비어있다면 솔직히 말해서 짜증이 납니다. "아무것도 없는데 왜 링크를 넣은 거지? 왜 내 시간을 빼앗는 거지?"라는 생각부터 듭니다. 그 다음에야 "아, 이 사람은 평소에 개발에 대한 관심이 그렇게 높지 않은가?" 같은 판단이 따라옵니다. 물론 회사 업무가 바쁘거나 개인적인 사정으로 개인 프로젝트를 할 시간이 없을 수도 있지만, 첫인상에서는 그런 사정을 알기 어렵습니다.
성실성 측면에서도 고려할 점이 있습니다. GitHub 활동이나 블로그 포스팅은 이직 시즌에만 하는 것이 아니라 평상시에도 꾸준히 해야 하는 것입니다. 만약 입사 후에 "사실 저는 개인 시간에는 개발을 잘 안 해요"라고 한다면 조금 어색할 수 있습니다. 물론 회사 업무와 개인 프로젝트는 다르지만, 어느 정도의 일관성은 필요할 것 같습니다.
만약 GitHub 링크를 넣기로 했다면, 저는 보통 이런 것들을 봅니다. 먼저 저장소 목록을 보면서 어떤 종류의 프로젝트들을 했는지 파악합니다. 그 다음 몇 개의 저장소에 들어가서 커밋 히스토리를 봅니다. 커밋 메시지가 의미 있게 작성되어 있는지, 적절한 단위로 커밋이 나뉘어져 있는지 확인합니다. 그리고 실제 커밋 내용을 보면서 메시지와 변경 사항이 일치하는지도 봅니다.
여기서 몇 가지 아쉬운 부분들이 있습니다. 예를 들어 "fix bug"라는 메시지와 함께 전혀 관련 없는 기능이 추가되어 있다면, 커밋 관리에 신경을 쓰지 않는다고 판단할 수 있습니다. 코드에 린팅이 제대로 되어 있지 않거나, 명백히 불필요한 console.log 같은 디버깅 코드가 그대로 남아있다면 아쉽습니다. 또한 Git으로 형상관리를 하고 있는데도 사용하지 않는 코드나 임시로 막아둔 코드들을 주석 처리해서 그대로 남겨둔 것들도 아쉽습니다. 버전 관리 시스템이 있는데 왜 주석으로 코드를 보관하는 건지 이해하기 어렵습니다.
물론 이런 것들이 치명적인 감점 요소는 아닙니다. 하지만 여러 명의 지원자 중에서 선택해야 하는 상황이라면, 이런 세부적인 것들도 판단 요소가 될 수 있습니다.
블로그도 비슷합니다. 블로그 링크를 넣는 이유는 대개 성실성을 보여주거나 글쓰기 능력, 더 나아가서는 논리적 사고 능력을 어필하기 위해서인 것 같습니다. 여기서 말하는 글쓰기 능력은 문장력이나 문학적 표현력을 의미하는 것이 아닙니다. 전반적인 논리 구조를 가지고 있는지, 생각의 흐름을 체계적으로 정리할 수 있는지를 보는 것입니다.
하지만 막상 블로그에 들어가 보면 의미 있는 글이 별로 없는 경우가 있습니다. 예를 들어 "오늘 배운 것" 형태의 TIL(Today I Learned) 글들만 몇 개 있거나, 인터넷에서 찾을 수 있는 일반적인 기술 설명들만 정리해놓은 경우입니다. 물론 이런 글들도 나름의 의미가 있지만, 채용 담당자 입장에서는 "이 사람만의 특별한 관점이나 경험"을 찾기 어렵습니다.
차라리 "이런 문제가 있어서 이렇게 해결했다", "이 기술을 써보면서 이런 점이 좋았고 이런 점은 아쉬웠다", "이런 상황에서 이런 선택을 했는데 그 이유는 이것이다" 같은 개인적인 경험과 생각이 담긴 글이 몇 개라도 있으면 훨씬 의미 있다고 생각합니다.
모든 경험을 다 넣는 함정
이력서에 자신이 했던 모든 경험을 다 넣으려는 경우도 자주 봅니다. 아마도 "많이 써놓으면 그 중에 하나라도 채용 담당자의 눈에 띌 것이다"라는 생각 때문일 것입니다. 하지만 양이 많다고 해서 합격 확률이 높아지는 것은 아닙니다. 오히려 정말 중요한 경험들이 묻힐 수 있습니다.
예를 들어보겠습니다. A 지원자가 10개의 프로젝트 경험을 나열했는데 그 중 8개는 평범하고 2개만 정말 인상적이라고 하겠습니다. B 지원자가 3개의 프로젝트만 적었는데 모두 흥미롭다고 하겠습니다. 채용 담당자는 한 사람의 이력서를 보는 데 많은 시간을 할애할 수 없기 때문에, A의 이력서에서는 인상적인 2개를 놓칠 가능성이 있습니다. 반면 B의 이력서는 모든 내용을 꼼꼼히 읽을 가능성이 높습니다.
물론 "목구멍이 포도청"이라고, 급하게 취업을 해야 하는 상황에서는 조금이라도 가능성을 높이고 싶은 마음이 이해됩니다. 하지만 여기서 중요한 것은 내가 지원하려는 회사나 팀이 어떤 곳인가 하는 점입니다.
만약 단순히 특정 기술을 다뤄본 경험이 있는 사람을 찾는 회사라면, 관련된 모든 경험을 나열하는 것이 도움이 될 수 있습니다. 하지만 그런 회사는 보통 장기적으로 함께 성장하기보다는 당장 필요한 기능을 구현할 수 있는 사람을 찾는 경우가 많습니다. 기술은 계속 변화하고 새로운 것이 나오는데, 그런 환경에서는 지속적인 성장이 어려울 수 있습니다.
반면에 함께 성장하고 싶어하는 회사라면, 지원자의 사고방식이나 문제 해결 능력, 학습 태도 같은 것들을 더 중요하게 볼 것입니다. 이런 회사에서는 10개의 평범한 경험보다 3개의 깊이 있는 경험이 더 의미 있게 받아들여질 수 있습니다.
제가 직접 개발한 게 아닌데 넣어도 되나요?
이 질문을 정말 자주 받습니다. 특히 주니어 개발자들이나 팀에서 주로 보조 역할을 했던 분들이 많이 하는 질문입니다. 제 생각에는 내가 완벽하게 설명할 수 있다면 넣어도 된다고 봅니다.
여기서 중요한 것은 "완벽하게 설명할 수 있다"는 부분입니다. 단순히 "제가 그 프로젝트에 참여했어요"가 아니라, "그 프로젝트에서 이런 문제가 있었고, 우리는 이런 방식으로 해결했으며, 제가 비록 직접 코딩하지는 않았지만 이 과정을 완전히 이해하고 있고, 만약 비슷한 상황이 생긴다면 같은 방식으로 해결할 수 있어요"라고 말할 수 있어야 한다는 뜻입니다.
실제로 실무에서도 그렇습니다. 매니저들의 이력서를 생각해보면, 매니저가 직접 코딩한 것은 거의 없습니다. 하지만 프로젝트 전체를 설계하고, 문제가 생겼을 때 해결 방향을 제시하고, 팀원들에게 기술적 가이드를 제공하는 것은 매니저의 몫입니다. 어떻게 보면 매니저가 더 많은 '기여'를 했다고 볼 수도 있습니다.
반대로 내가 직접 타이핑한 코드라고 해도, 정작 "왜 그렇게 구현했는지", "다른 방법은 고려해보지 않았는지", "그 기술을 선택한 이유가 무엇인지" 같은 질문에 제대로 답변하지 못한다면, 그것이 정말 '내 것'이라고 할 수 있을까요?
면접에서 중요한 것은 코드를 누가 타이핑했느냐가 아니라, 그 과정에서 어떤 사고를 했는지, 어떤 판단을 내렸는지, 그리고 그 경험을 통해 무엇을 배웠는지입니다. 만약 내가 직접 개발하지 않았더라도 그 모든 과정을 이해하고 설명할 수 있다면, 그것만으로도 충분히 의미 있는 경험이라고 생각합니다.
마치며: 채용은 서로를 찾아가는 과정
이런 긴 이야기를 하고 나면 항상 마지막에 하는 말이 있습니다. 제가 하는 이야기가 절대적인 기준은 아니라는 것입니다. 채용 담당자마다 중요하게 생각하는 포인트가 다르고, 회사마다 추구하는 방향이 다르며, 팀마다 필요로 하는 역할이 다릅니다. 제 기준에서는 좋아 보이지 않는 이력서라도 다른 회사에서는 매우 매력적으로 받아들여질 수 있습니다.
그래서 저는 항상 "이런 관점도 있다"는 식으로 이야기하려고 합니다. "무조건 이렇게 해야 한다"가 아니라 "이런 시각에서 보는 사람도 있으니 참고해보세요"라는 의미입니다.
최근 1년간 100명과 만나면서 가장 아쉬웠던 점은, 정말 좋은 경험과 역량을 가진 사람들이 그것을 제대로 표현하지 못하고 있다는 것이었습니다. 조금만 더 구체적으로, 조금만 더 자신 있게 표현한다면 훨씬 매력적인 지원자가 될 수 있을 텐데 하는 안타까움이 있었습니다.
채용이라는 것은 결국 서로를 찾아가는 과정입니다. 회사는 자신들과 잘 맞는 사람을 찾고, 지원자는 자신이 성장할 수 있고 만족할 수 있는 회사를 찾습니다. 이력서와 면접은 그 과정에서 서로를 이해하기 위한 도구일 뿐입니다.
그런 관점에서 이력서를 작성할 때는 "어떻게 하면 나를 좋게 포장할 수 있을까"보다는 "어떻게 하면 나의 진짜 모습을 제대로 전달할 수 있을까"를 고민하는 것이 더 중요할지도 모릅니다. 그래야 서로에게 맞는 조합을 찾을 수 있고, 결과적으로는 모두에게 도움이 되는 결과를 만들 수 있을 것입니다.
강의실에서 마주하는 학생들의 진지한 눈빛을 보면, 이들이 단순히 '취업'이라는 목표를 넘어서 자신만의 길을 찾아가길 바라게 됩니다. 이 글이 이력서를 고민하고 있는 분들에게 조금이나마 도움이 되기를 바랍니다. 그리고 무엇보다, 여러분이 가진 좋은 경험들을 더 자신 있게 표현하는 계기가 되었으면 합니다.
]]></description><link>https://w0nder.land/posts/43-%EB%82%B4%EA%B0%80%20%EB%B3%B4%EA%B3%A0%20%EC%8B%B6%EC%97%88%EB%8D%98%20%EC%9D%B4%EB%A0%A5%EC%84%9C</link><guid isPermaLink="false">43</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 25 Sep 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[내가 생각하는 채용]]></title><description><![CDATA[요즘 대학에 출강을 하고 있다. 수업시간에 강의를 하다 보면 학생들로부터 취업 관련 질문을 자주 받는다. "어떤 회사가 좋은 회사인가요?", "이력서는 어떻게 써야 하나요?", "면접에서는 뭘 준비해야 하나요?"
학생들의 눈빛에서는 간절함과 동시에 막막함이 느껴진다. 그 질문들을 들을 때마다, 지난 8년간 매니저로서 직접 채용을 담당했던 경험들이 떠오른다. 인턴부터 기획자, 개발자, 디자이너까지 다양한 직군의 사람들을 만났다. 그 과정에서 나 역시 많은 것을 배웠다.
처음에는 단순히 '좋은 사람을 뽑아야 한다'라는 막연한 생각뿐이었다. 하지만 실제로 함께 일해보면서 채용이 결코 단순하지 않다는 것을 깨달았다. 특히 이력서에 적힌 모습, 면접에서 보여주는 태도, 실제로 협업할 때의 모습은 종종 큰 차이가 있었다.
채용에 대한 나만의 생각
이런 경험을 통해 자연스럽게 떠오른 질문은 "채용이란 무엇인가?"였다. 처음에는 '실력 좋은 사람을 뽑는 것'이라고 생각했다. 하지만 시간이 지날수록 그것이 얼마나 단편적인 시각이었는지 알게 되었다.
내가 보기에 채용은 단순히 한쪽이 선택하는 과정이 아닌 것 같다. 회사마다 원하는 인재상이 다르다. 같은 회사 안에서도 팀이나 면접관마다 중요하게 생각하는 기준이 제각각이다. 어떤 곳에서는 기술적 깊이를 중시한다. 어떤 곳에서는 문제 해결 능력이나 소통 역량을 더 중요하게 본다. 그래서 어떤 하나의 정답이나 모범 경로는 존재하지 않는다고 생각한다.
개인적으로 나는 채용을 퍼즐 맞추기에 비유하고 싶다. 회사는 자신들에게 맞는 사람을 찾는다. 구직자 역시 자신에게 맞는 회사를 찾아간다. 이 과정에서 서로가 서로를 탐색하고 이해하며 맞춰가는 것이라고 본다.
내 채용 철학의 변화: 세 단계
돌이켜보면 내 채용 철학은 크게 세 단계를 거쳐 변화했다. 각 단계는 나름의 가설을 세우고 검증해본 과정이었다. 지금 생각해보면 각각 나름의 의미가 있었던 것 같다.
1단계: 기술 중심주의
처음 면접관이 되었을 때 나는 솔직히 막막했다. 그래서 자연스럽게 이력서에 적힌 기술과 경험을 기준으로 질문을 던졌다. "이 프로젝트를 어떻게 했나요?", "이 기술을 왜 선택했나요?" 같은 질문들이었다. 당시에는 '느낌'에 의존하는 경우가 많았다. 하지만 겉으로는 기술 역량을 중심으로 평가한다고 생각했다.
그때 내 판단은 기술 역량 중심으로 내려졌다. 실력이 뛰어나면 좋은 사람이라고 생각했다. 실제로 몇몇 채용에서는 잘 맞았다. 뽑힌 사람들은 업무를 빠르게 처리했다. 문제 해결에도 강했다.
그런데 시간이 지나면서 한계를 느꼈다. 기술은 뛰어나지만 협업에서 문제가 생기는 경우가 있었다. 의견을 고집해 팀의 의사결정을 방해하는 사례도 나타났다. 무엇보다 우리 팀이 만드는 서비스는 대규모 실시간 시스템이 아니었다. 생명과 직결된 소프트웨어도 아니었다. 비교적 작은 규모의 B2B 서비스였고, 약간의 성능 이슈나 버그가 있어도 빠르게 수정할 수 있는 환경이었다. 그래서 '우리한테는 최고 수준의 기술 역량만이 답은 아닐 수도 있겠다'는 생각이 들었다.
2단계: 협업과 소통 중심주의
이후 나는 협업과 소통 능력에 더 주목했다. 면접 질문도 달라졌다. "동료와 의견이 다를 때 어떻게 조율했나요?", "프로젝트가 어려울 때 팀과 어떻게 소통했나요?" 기술적 질문을 할 때도 달랐다. "이런 상황에서 동료가 다른 기술을 제안한다면 어떻게 판단하시겠어요?" 같은 식으로 소통 과정을 중시했다.
이렇게 함께 일하는 방식을 묻는 질문을 많이 했더니 팀 분위기는 한층 좋아졌다. 서로 편하게 질문했다. 코드 리뷰도 건설적으로 진행되었다. 팀 전체의 생산성도 향상되었다.
하지만 이 접근에도 약점이 있다는 걸 깨달았다. 기술적 성장 속도가 느린 경우가 있었다. 중요한 순간에도 결정을 미루며 합의에만 치중하는 경우도 있었다. 결과적으로 내가 더 많은 시간을 투자해 기술적 지원을 해야 하는 상황들이 생겼다. 특히 한 팀원이 "저는 기술보다는 사람이 중요하다고 생각해요"라고 말했는데, 시간이 지나면서 기술적 호기심이나 학습 의욕이 부족하다는 것을 느꼈던 기억이 있다.
3단계: 내가 생각하는 '일을 잘한다'는 것
결국 나는 '일을 잘한다'는 것이 무엇인지 근본적으로 고민하게 되었다. 그 답을 찾는 데 도움이 된 것이 여러 회사의 기술 블로그였다. 네이버, 카카오, 토스, 당근 같은 유명 기업들의 글을 읽었다.
유명 기업들의 글을 읽다 보니 공통된 패턴이 보였다. 문제 정의 → 목표 설정 → 해결책 조사 → 현재 상황 분석 → 대안 비교 → 최적의 해결책 선택 → 실행 및 개선 → 결과 정리. 회사는 다르고 작성자도 다르지만, 글의 구조가 거의 비슷했다.
여기서 나만의 깨달음을 얻었다. 내가 생각하기에 '일을 잘한다'는 것은 특정 기술을 아는 것이 아닌 것 같다. 사람들과 잘 어울리는 것도 아니다. 문제를 올바르게 정의하고 상황에 맞는 해결책을 찾아가는 능력인 것 같다.
즉, 주어진 업무를 그냥 수행하는 것이 아니다. "이 일의 목적이 무엇인지", "어떻게 해야 올바르게 해결할 수 있는지", "현재 상황에서 가장 적절한 방법은 무엇인지"를 스스로 찾아가면서 일하는 능력 말이다.
내 경험상 이런 사고와 실행 과정을 갖춘 사람이라면 부족한 부분이 있어도 스스로 학습한다. 협업 과정에서 생기는 문제도 개선해나간다. 그래서 지금 내가 찾고 있는 인재상은 바로 이런 '문제를 풀어가는 방식'을 가진 사람이다.
내가 보는 채용: 상호 선택의 과정
그렇다면 내가 보기에 '완벽한 사람'은 존재하지도 않는다. 설령 있다 해도 작은 회사에 지원하지 않을 것이고, 와도 오래 머물지 않을 가능성이 크다.
그렇다면 내가 진정으로 찾는 것은 무엇일까? 지금 당장의 완벽함보다는 일하는 방식이다. 새로운 것을 배우려는 의지가 있는지, 문제 앞에서 포기하지 않고 해결하려는 태도를 가졌는지, 동료들과 건설적으로 소통할 수 있는지. 이런 것들이 내가 이력서와 면접에서 보고자 하는 진짜 모습이다.
그런 관점에서 내가 이력서를 볼 때도 다르다. 완벽한 프로젝트 경험이나 화려한 기술 스택보다는 다른 걸 본다. "이 사람이 어떤 방식으로 문제에 접근했는가", "어려운 상황에서 어떻게 대응했는가", "팀원들과 어떻게 협력했는가" 같은 것들을 더 중요하게 본다.
기술적 소양은 당연히 필요하다. 하지만 그것도 '지금 당장 모든 기술을 다 알고 있어야 한다'는 뜻이 아니다. '기술적 호기심과 학습 능력이 있느냐'를 보는 것에 가깝다.
내 생각에 채용은 단순한 평가나 선별이 아니다. 회사는 자신에게 맞는 사람을 찾고, 구직자는 자신에게 맞는 회사를 찾는다. 서로가 서로를 이해하고 함께 일할 수 있는 파트너를 찾아가는 과정이라고 본다.
물론 이건 어디까지나 내 경험에서 나온 개인적인 생각이다. 다른 회사, 다른 팀, 다른 상황에서는 전혀 다른 기준이 더 적절할 수도 있다. 채용에는 정답이 없으니까.
]]></description><link>https://w0nder.land/posts/42-%EB%82%B4%EA%B0%80%20%EC%83%9D%EA%B0%81%ED%95%98%EB%8A%94%20%EC%B1%84%EC%9A%A9</link><guid isPermaLink="false">42</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 18 Sep 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[인디해커들은 어떻게 살고 있나]]></title><description><![CDATA[최근 함께 창업을 하던 파트너와 헤어지게 되었다. 늘 마음 한편에서 걱정하고 있던 일이었다. 언젠가는 이런 날이 올 수도 있다는 불안한 예감이 있었고, 그래서 더욱 조심스럽게 관계를 다뤄왔다. 하지만 결국 그 걱정이 현실이 되어버렸다. 헤어짐 이후 복잡한 감정들이 밀려왔다. 밤잠을 설치며 이런저런 생각에 빠져들 때가 많아졌고, 자연스럽게 근본적인 질문에 다다르게 되었다.
나는 왜 창업을 하게 되었을까?
아직도 그 이유를 명확하게 설명할 수는 없다. 하지만 분명한 것이 하나 있다. '내 것을 하고 싶다'는 막연하면서도 강렬한 욕구다. 남이 정해놓은 길을 따라가는 것이 아니라, 내가 생각하고 믿는 바를 내 방식으로 실현하고 싶다는 갈망. 그것이 창업이라는 선택의 밑바탕에 깔려 있었던 것 같다.
이런 생각들을 하다 보니 나에 대해서 좀 더 깊이 탐구하고 성찰하게 되었다. 그리고 동시에 다른 사람들은 어떨까 하는 궁금함이 생겼다. 나와 비슷한 길을 걷고 있는 사람들, 특히 주변에서 만나게 되는 인디해커들 말이다. 요즘 그런 사람들을 자주 만나게 되는데, 그들을 보며 계속 궁금해진다. 그들은 왜 이 길을 시작했을까? 어떤 동기와 목표를 가지고 있을까? 그리고 실제로는 어떻게 살아가고 있는 것일까? 그들의 과거와 현재, 그리고 미래를 향한 계획과 꿈들을 알고 싶어진다. 각자가 걸어온 길과 지금 서 있는 지점, 그리고 앞으로 나아가고자 하는 방향까지. 그런 전체적인 그림이 궁금하다.
생각해보니 지금이 어쩌면 '대 헤어짐의 시대'일지도 모른다는 생각이 든다. 주변을 둘러보니 나처럼 팀으로 시작했던 사람들이 결별하는 경우가 유독 많다. 창업 파트너와 갈라서는 사람들, 함께하던 프로젝트를 각자의 길로 가져가는 사람들. 그런 분들과 이야기를 나누다 보면 나도 깊이 공감되는 부분들이 많았다. 그들의 경험담을 들으며 새로운 인사이트를 얻기도 하고, 때로는 위로를 받기도 했다. 혼자만의 경험이 아니라는 것을 알게 되는 것만으로도 큰 도움이 되었다.
이런 경험들을 통해 깨달은 것은 비슷한 상황에 있는 사람들의 이야기가 가진 힘이었다. 내가 겪고 있는 고민과 혼란이 나만의 것이 아니라는 사실, 다른 사람들도 비슷한 길을 걸으며 유사한 어려움을 겪고 있다는 것을 아는 것만으로도 큰 위안이 되었다. 그런 깨달음을 준 책이 하나 있었다. 『서울의 3년 이하 서점들』이라는 책을 읽었는데, 처음 이 책을 보고 정말 큰 충격을 받았다.
나는 책방에 대해 너무 나이브하고 로맨틱한 접근을 하고 있었던 것 같다. 조용하고 아름다운 공간에서 책을 팔며 사는 삶에 대한 막연한 동경이 있었다. 하지만 이 책에서 보여준 현실과 실제 책방을 운영하는 사람들의 생각들을 접하면서 나도 많은 대리 경험을 한 것 같았다. 경제적인 어려움, 운영의 현실적인 문제들, 그럼에도 불구하고 책방을 지속하는 이유들까지. 그 책 덕분에 책방에 대해 다시 생각해보게 되었고, 더 충분한 준비를 하고 깊이 있는 고민을 할 수 있게 되었다. 실제 경험자들의 솔직한 이야기가 가진 힘을 직접 체험한 순간이었다.
그러다가 문득 이런 생각이 들었다. 인디해커들을 직접 만나서 그들의 목적과 방향, 고민과 걱정, 과거의 이야기와 앞으로의 계획 같은 것들을 인터뷰해보면 어떨까? 그런 이야기들을 모아서 "인디해커들은 어떻게 살고 있나"라는 책을 만들면, 지금 인디해커의 길을 걷고 있는 사람들이나 앞으로 이 길로 들어올 사람들에게 도움과 위안을 줄 수 있지 않을까?
『서울의 3년 이하 서점들』이 나에게 해준 역할을 이 책도 할 수 있었으면 한다. 인디해커라는 길에 대해 막연한 환상이나 피상적인 이해만 가지고 있는 사람들에게 현실적이고 구체적인 이야기들을 전해주고 싶다. 성공담만이 아니라 실패와 좌절, 일상의 고민들까지 포함해서 말이다. 화려한 성공 스토리가 아니라 실제로 이 길을 걷고 있는 사람들의 진짜 일상이 궁금하다. 어떤 하루를 보내고 있는지, 어떤 고민을 하며 살아가는지, 과거에 어떤 선택들을 했고 앞으로는 어떤 계획을 가지고 있는지. 그런 소소하지만 진실한 이야기들이 모여 누군가에게는 현실적인 가이드가 되고, 누군가에게는 위로가 될 수 있을 것이다.
사실 꼭 누구에게 도움이 되지 않더라도, 최소한 나 자신을 위로하고 보듬을 수 있다면 그것만으로도 이 책이 존재할 이유는 충분하다고 생각한다. 창업 파트너와의 헤어짐 이후 느끼고 있는 혼란과 고민들이 나만의 것이 아니라는 것을 확인하고 싶다. 비슷한 길을 걷는 다른 사람들의 이야기를 통해 위안을 얻고, 내가 가야 할 방향에 대한 힌트를 찾고 싶다. 이 책을 만드는 과정 자체가 내가 인디해커들과 만나고 교류하는 기회가 될 것이고, 그 과정에서 나 자신도 많은 것을 배우고 성장할 수 있을 것이다. 어쩌면 이 책은 나를 위한 책이기도 하다.
이제 하나씩 하나씩 인터뷰를 해보려고 한다. 인터뷰를 하는 그 과정 자체도 험난할 것 같다는 생각이 든다. 낯선 사람들에게 개인적이고 깊은 이야기를 부탁하는 일이니까 쉽지 않을 테고, 거절당할 때도 많을 것이다. 하지만 하나씩 천천히 해나가다 보면 뭔가 차곡차곡 쌓이고, 점진적으로 진행되어 갈 것 같다는 믿음이 있다. 그렇게 모인 이야기들이 결국 "인디해커들은 어떻게 살고 있나"라는 책으로 완성되어, 누군가에게는 도움이 되고 누군가에게는 위로가 되기를 바란다. 그리고 무엇보다, 이 책을 만드는 과정에서 나 자신도 내가 정말 원하는 것이 무엇인지, 어떤 길을 걸어가야 하는지를 찾을 수 있기를 바란다.

]]></description><link>https://w0nder.land/posts/41-%EC%9D%B8%EB%94%94%ED%95%B4%EC%BB%A4%EB%93%A4%EC%9D%80%20%EC%96%B4%EB%96%BB%EA%B2%8C%20%EC%82%B4%EA%B3%A0%20%EC%9E%88%EB%82%98</link><guid isPermaLink="false">41</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Tue, 09 Sep 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[한 테이블 팀]]></title><description><![CDATA[최근 팀에 많은 변화가 있었다. 새로운 조직 구조를 실험하면서 문득 이런 질문이 떠올랐다. 내가 정말 원하는 팀은 어떤 모습일까? 혼자 일할 때는 잘 보이지 않던 것들이 함께 일하는 과정에서는 더욱 선명하게 드러난다. 이 변화의 시점에서, 내가 꿈꾸는 팀에 대해 정리해보고 싶어졌다.
많은 사람이 아마존의 '피자 두 판 팀'을 알고 있다. 피자 두 판으로 배를 채울 수 있는 인원, 보통 5-10명 규모의 팀을 말한다. 소통이 원활하고 빠르게 움직일 수 있는 단위라는 뜻이다. 하지만 내가 그리는 팀은 그보다 더 작다. 네 명이 식당의 한 테이블에 둘러앉아 식사하는 정도. 아주 작은 단위지만, 식사할 때 서로 다른 테이블에 나눠 앉지 않아도 되는 팀이다.
혼자 일할 때 가장 힘든 점은 사고의 편중이다. 같은 관점으로만 문제를 바라보다 보니 놓치는 부분이 많아진다. 그래서 나는 한 테이블 팀을 꿈꾼다. 이 팀에서 각자의 역할은 단순히 업무를 분담하는 것이 아니라, 서로의 사고를 보완하고 확장하는 장치가 된다.
이상적인 모델을 떠올리면 드라마 《하우스》의 진단팀이 생각난다. 하우스와 포먼, 체이스, 캐머론이 회의실에 모여 환자의 증상을 놓고 각자 다른 가설을 제시하며 격렬하게 토론하는 장면 말이다. 그들은 자주 부딪히고 서로의 의견을 반박하지만, 결국 그 과정을 통해 더 정확한 진단에 도달한다. 내가 원하는 팀도 마찬가지다. 내 의견에 동의하는 사람, 반대하는 사람, 전혀 다른 시각을 제시하는 사람이 함께 있어야 한다. 신중함, 직관, 공감 능력처럼 서로 다른 특성이 모였을 때 더 깊고 넓은 해답을 찾을 수 있다.
이런 사고의 교류는 꼭 회의실에서만 일어나지 않는다. 점심을 함께 먹거나 커피를 마시며 나누는 가벼운 대화에서도 시작된다. 업무와 전혀 관련 없는 일상 이야기를 나누다가도, 어느 순간 불쑥 나온 한마디가 깊은 논의로 이어지곤 한다. "그 기능, 이렇게 바꿔보면 어때?" 혹은 "고객 입장에서는 이런 불편이 있지 않을까?" 같은 질문들 말이다. 그래서 나는 회사에서 제공하는 식사나 커피 비용을 단순한 복지가 아니라 사고를 넓히기 위한 투자라고 생각한다. 작은 대화가 결국 팀의 사고 폭을 넓히고, 제품과 서비스의 방향에까지 영향을 미친다.
요즘은 AI가 많은 업무를 보조한다. 하지만 사고를 주고받고, 서로의 관점을 검증하는 역할까지 대신할 수는 없다. 내가 원하는 팀원은 함께 고민하고, 끊임없이 질문하며, 당연하게 여겨지는 것들에 의문을 제기할 줄 아는 사람이다. 그런 과정에서야 비로소 더 나은 결정에 다가갈 수 있다. 하우스가 "모든 환자는 거짓말을 한다"라고 말하며 기존 가정을 흔들 듯, 우리 역시 당연한 전제들을 끊임없이 점검해야 한다.
그렇다면 어떤 사람들과 함께 일하고 싶은가. 나는 능력 그 자체보다 태도와 성향을 더 중요하게 본다. 문제가 생겼을 때 "왜 이런 일이 생겼지?"라고 원망하기보다 "지금 우리가 할 수 있는 게 뭐지?"를 먼저 묻는 사람, 자신과 다른 의견이라도 들어보고 그 안에서 합리적인 부분을 찾으려는 사람, 회의 중에 치열하게 논쟁하더라도 끝나면 감정을 남기지 않고 다음 단계로 넘어가는 성숙함을 가진 사람, 더 나은 근거가 나오면 주저 없이 입장을 바꿀 수 있는 유연함을 가진 사람, 그리고 무엇보다 자기 주장을 증명하기 위해 싸우는 것이 아니라 팀이 더 좋은 결과를 만들도록 토론하는 사람. 이런 성향들이 모였을 때 작은 테이블 위에서도 큰 시너지가 만들어진다.
결국 내가 말하는 한 테이블 팀은 단순히 함께 일하는 집단이 아니다. 사고와 결정을 다양화하는 장치다. 네 명이 테이블에 앉아 나누는 대화와 교류가 곧 팀의 에너지이고, 그 에너지가 더 나은 제품과 서비스를 만든다. 작은 테이블 위에서 오가는 이야기들이 결국 큰 변화를 일으킨다. 그것이 바로 내가 꿈꾸는 팀워크의 본질이다.
]]></description><link>https://w0nder.land/posts/40-%ED%95%9C%20%ED%85%8C%EC%9D%B4%EB%B8%94%20%ED%8C%80</link><guid isPermaLink="false">40</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 04 Sep 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[모바일 환경에서의 OAuth 2.0 보안 구현]]></title><description><![CDATA[모바일 환경에서의 OAuth 2.0 보안 구현 가이드
모바일 애플리케이션에서 OAuth 2.0을 구현할 때는 웹 환경과는 근본적으로 다른 보안 접근 방식을 취해야 합니다. 모바일 앱은 OAuth 2.0 및 OAuth 2.1 초안에서 정의하는 Public Client에 해당하며, 이는 단순한 분류가 아니라 보안 설계의 근본적 차이를 의미합니다.
모바일 OAuth의 기본 원리와 웹과의 차이점
웹 애플리케이션은 서버 환경에서 실행되어 클라이언트 시크릿과 같은 민감한 정보를 안전하게 보관할 수 있습니다. 반면 모바일 앱은 사용자 디바이스에서 실행되므로 본질적으로 비밀 정보를 완전히 보호할 수 없는 환경에 놓여 있습니다.
모바일 앱이 클라이언트 시크릿을 안전하게 보관할 수 없는 이유는 명확합니다. 첫째, APK나 IPA 파일은 리버스 엔지니어링 도구를 사용해 쉽게 분석할 수 있습니다. 둘째, 모든 앱 인스턴스가 동일한 바이너리를 사용하므로 각 클라이언트별로 고유한 비밀 정보를 배포하는 것이 불가능합니다. 셋째, 런타임에서 메모리 덤프를 통해 하드코딩된 값을 추출할 수 있는 위험이 항상 존재합니다.
이러한 현실을 반영하여 OAuth 2.1 초안에서는 Public Client에서 클라이언트 시크릿을 아예 사용하지 않도록 권장하고 있습니다. 이는 "어떻게든 비밀을 숨겨보자"는 접근에서 "숨길 수 없다면 의존하지 말자"는 현실적 접근으로의 패러다임 전환을 나타냅니다.
PKCE를 통한 핵심 보안 메커니즘 구현
모바일 환경에는 웹에서는 볼 수 없는 특별한 위협이 존재합니다. 바로 Authorization Code Interception Attack입니다. 이 공격은 공격자가 정당한 앱과 동일한 URL 스키마를 등록한 악성 앱을 배포하고, 사용자가 OAuth 인증을 완료한 후 Authorization Code를 악성 앱으로 가로채는 방식으로 이루어집니다.
PKCE(Proof Key for Code Exchange, RFC 7636)는 바로 이러한 문제를 해결하기 위해 설계된 메커니즘입니다. PKCE는 클라이언트 시크릿 없이도 Authorization Code를 안전하게 토큰으로 교환할 수 있는 방법을 제공합니다.
PKCE의 작동 원리는 일회용 증명(Proof-of-Possession) 개념에 기반합니다. 인증 요청 단계에서 클라이언트는 랜덤한 code_verifier를 생성하고 이를 SHA256으로 해시하여 code_challenge를 만들어 서버에 전송합니다. 토큰 요청 단계에서는 Authorization Code와 함께 원본 code_verifier를 서버에 보냅니다. 서버는 받은 code_verifier를 해시하여 이전에 받은 code_challenge와 일치하는지 확인합니다.
이 메커니즘의 핵심은 증명 정보가 분리되어 전송된다는 점입니다. 악성 앱이 Authorization Code를 가로채더라도, 정당한 앱만이 보유한 code_verifier 없이는 토큰을 발급받을 수 없습니다.
PKCE를 구현할 때는 몇 가지 필수 보안 요구사항을 준수해야 합니다. 반드시 S256 방식을 사용해야 하며, 평문(plain) 방식은 네트워크 도청에 취약하므로 피해야 합니다. code_verifier는 RFC 7636에서 권장하는 대로 최소 256비트(43자 이상)의 충분한 엔트로피를 가져야 하며, 매 인증 요청마다 새로운 값을 생성하여 재사용 공격을 방지해야 합니다.
안전한 Redirect URI 설정과 앱 식별
전통적인 Custom Scheme 방식(예: myapp://oauth/callback)은 스키마 충돌이라는 근본적 문제를 내포하고 있습니다. 운영체제는 동일한 스키마를 등록한 여러 앱 중 어느 것을 선택할지 보장할 수 없으며, 공격자가 인기 있는 앱의 스키마를 그대로 복사하여 사용할 수 있습니다. 또한 사용자가 여러 앱이 같은 스키마를 사용할 경우 올바른 앱을 선택하기 어려워집니다.
이러한 문제를 해결하기 위해 Android App Links와 iOS Universal Links를 사용하는 것이 권장됩니다. 이들은 HTTPS 기반 리디렉션을 사용하며 도메인 소유권 검증이라는 핵심 보안 메커니즘을 제공합니다.
도메인 검증 기반 보안은 공격자가 임의로 등록할 수 없는 도메인을 기반으로 하며, 플랫폼이 앱과 도메인 간의 관계를 검증하여 신뢰성을 보장합니다. 또한 앱이 설치된 경우 바로 앱으로 전환되고, 앱이 설치되지 않은 경우 웹페이지로 자연스럽게 연결되어 우아한 사용자 경험을 제공합니다.
RFC 8252에서는 가능한 한 HTTPS 기반 리디렉션을 권장하고 있으며, Custom Scheme이 불가피한 경우에는 reverse domain name 형태(예: com.example.app://callback)를 사용할 것을 제안합니다.
안전한 토큰 관리와 저장
OAuth 토큰은 사용자 계정에 접근할 수 있는 디지털 열쇠와 같은 중요한 자산입니다. 물리적 열쇠를 함부로 두지 않듯이, 토큰 역시 안전한 곳에 보관해야 합니다.
SharedPreferences, NSUserDefaults, localStorage와 같은 일반 저장소는 여러 위험에 노출됩니다. 취약한 권한 설정이 있을 경우 다른 앱이 데이터를 읽을 수 있고, 클라우드 백업 과정에서 평문 데이터가 유출될 위험이 있으며, 런타임에서 메모리 분석을 통해 토큰이 추출될 수 있습니다.
대신 플랫폼에서 제공하는 보안 저장소를 활용해야 합니다. iOS의 경우 Keychain Services를 사용할 수 있는데, 이는 Secure Enclave를 활용한 하드웨어 기반 암호화를 제공하고, Touch ID나 Face ID와 결합한 접근 제어가 가능하며, 앱 삭제 후에도 선택적으로 토큰을 보존할 수 있습니다.
Android에서는 Keystore나 EncryptedSharedPreferences를 사용할 수 있습니다. Android Keystore는 TEE(Trusted Execution Environment)를 활용한 하드웨어 보안 모듈을 제공하며, 별도 구현 없이도 데이터를 자동으로 암호화해주고, 루팅 탐지와 연동된 추가 보안 레이어를 제공합니다.
토큰의 생명주기 관리도 중요합니다. Access Token의 수명은 탈취 시 피해를 최소화하기 위해 가능한 한 짧게 유지해야 합니다. 일반 서비스에서는 15분에서 1시간, 고민감 서비스에서는 5분에서 15분, 금융 서비스에서는 3분에서 10분 정도로 설정하는 것이 적절합니다.
Refresh Token의 경우 자동 순환 메커니즘을 구현해야 합니다. 토큰 갱신 시마다 새로운 토큰을 발급하고 이전 토큰을 즉시 무효화하는 방식으로, 공격자가 토큰을 탈취하더라도 다음 갱신 시 무효화되도록 합니다. 이는 RFC 6749 및 OAuth 2.1 초안에서 권장하는 보안 사항입니다.
State 매개변수를 통한 CSRF 공격 방어
Cross-Site Request Forgery 공격은 사용자가 의도하지 않은 요청을 실행하도록 유도하는 공격 방식입니다. OAuth 플로우에서는 공격자가 자신의 계정으로 인증된 Authorization Code를 피해자의 세션에 주입할 수 있는 위험이 있습니다.
이를 방어하기 위해 State 매개변수를 적절히 구현해야 합니다. 암호학적으로 안전한 랜덤 값을 생성하여 세션에 저장하고, 인증 요청 시 전송한 state 값과 콜백에서 받은 state 값의 일치 여부를 반드시 확인해야 합니다. 또한 State 값을 현재 사용자 세션과 연결하여 세션 고정 공격을 방지하는 것이 중요합니다.







]]></description><link>https://w0nder.land/posts/39-%EB%AA%A8%EB%B0%94%EC%9D%BC%20%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%EC%9D%98%20OAuth%202.0%20%EB%B3%B4%EC%95%88%20%EA%B5%AC%ED%98%84</link><guid isPermaLink="false">39</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Tue, 02 Sep 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[책방 아비투스]]></title><description><![CDATA[

부르디외가 말한 ‘아비투스’는 우리가 태어나고 성장하는 과정에서 무의식적으로 몸에 익히게 되는 사회적 태도, 습관, 취향을 뜻한다. 이것은 개인의 단순한 선택이나 취향을 넘어선다. 아비투스는 우리 안에 깊숙이 내재된, 사회 구조와 문화적 자본이 교묘히 얽힌 결과물이다. 즉, 우리가 어떤 책을 좋아하고, 어떤 이야기에 마음이 움직이는지는 저절로 생겨난 것이 아니라, 우리를 둘러싼 사회적 환경과 경험, 교육, 관계 속에서 만들어진 복합적인 산물이다.
책방 ‘아비투스’는 바로 이 복잡한 ‘무의식의 사회성’을 마주하는 공간으로서 존재하고자 한다. 단순히 책을 사고파는 곳을 넘어, 방문객 각자가 자신도 몰랐던 내면의 사회적 습관을 마주하고 성찰할 수 있는 장소가 되는 것이 목표다. 이를 위해 가장 중요한 축이 바로 ‘큐레이션’이다.
책방에서의 큐레이션은 단순히 인기 있는 책을 나열하거나 트렌드에 맞춰 책을 배치하는 것이 아니다. 내가 직접 읽고 고른 책들은 나의 경험과 철학적 고민, 그리고 사회적 맥락을 반영한다. 이 큐레이션은 방문객의 아비투스를 자극하는 ‘작은 개입’이다. 익숙한 취향의 연장선이 아니라, 때로는 불편하고 새로운 시선을 제안함으로써, 무의식적으로 형성된 개인의 습관과 생각의 틀을 흔들고 확장시키는 역할을 한다.
예를 들어, 한 독자가 평소에 접하지 않았던 사회 비평서나 철학 서적을 큐레이션 공간에서 마주하는 순간, 그 경험은 단순한 독서 이상의 의미를 지닌다. 그 책은 그가 속한 사회적 위치와 맞물려 형성된 아비투스를 되돌아보게 하고, 자신의 생각과 행동 양식에 질문을 던지는 자극제가 된다. 이렇게 큐레이션은 개인과 사회의 무의식적 연결고리를 깨닫게 하는 하나의 ‘사회적 장치’ 역할을 하는 것이다.
여기에 더해 책방에서 이루어지는 독서 모임, 글쓰기 워크숍, 작가와의 만남 같은 커뮤니티 활동은 아비투스의 사회적 재생산과 변화를 직접 체험할 수 있는 중요한 공간이다. 아비투스는 개인 안에만 머무르지 않고, 타인과의 관계 속에서 끊임없이 형성되고 수정된다. 모임에서 나누는 대화와 교류는 각자의 무의식적 습관을 드러내고 서로 비교하며, 때로는 충돌하고 때로는 융합하는 과정이다.
이런 사회적 경험은 방문객들이 자신과 타인의 아비투스를 인식하게 만들고, 기존의 익숙한 사고방식을 넘어 새로운 인식과 실천으로 나아갈 수 있는 힘을 준다. 모임이라는 장은 단순한 정보 교환이 아니라, 문화적 실천이 이루어지는 살아 있는 ‘현장’이며, 책방 ‘아비투스’가 단순한 상업 공간이 아닌 철학적 실천의 공간으로 자리매김하는 핵심 요소다.
또한, 책방 내에서 책을 읽으며 함께 커피를 마시거나 편안하게 머무르는 시간 자체도 아비투스의 변화를 돕는 소중한 경험이다. 일상의 익숙한 습관이 잠시 멈추고 새로운 감각과 생각이 스며드는 시간과 공간은, 개인의 무의식적 습관을 성찰하고 새롭게 형성하는 데 중요한 역할을 한다.
결국 책방 ‘아비투스’는 책과 큐레이션, 그리고 커뮤니티 활동이 서로 유기적으로 연결되어
개인과 사회, 무의식과 의식, 습관과 변화가 맞닿는 접점이 된다.
이곳은 아비투스라는 개념을 실제 삶에 적용하고 실천하는 ‘작은 실험실’이며,
방문객 모두가 자신의 내면과 사회적 조건을 재인식하고,
나아가 그것을 넘어서는 새로운 삶의 방식을 모색하는 공간이다.
‘아비투스’라는 이름에 담긴 의미는 단지 철학적 상징에 그치지 않는다.
그것은 책방 운영 전반에 깔린 철학이자, 큐레이션과 모임, 그리고 일상의 경험을 통해 구체적으로 구현되는 삶의 태도이다.
나는 이 공간에서 책과 사람, 그리고 사회가 서로 만나고 영향을 주고받으며,
새로운 문화적 가능성을 만들어 가기를 기대한다.
]]></description><link>https://w0nder.land/posts/38-%EC%B1%85%EB%B0%A9%20%EC%95%84%EB%B9%84%ED%88%AC%EC%8A%A4</link><guid isPermaLink="false">38</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 28 Aug 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[안 간 면접]]></title><description><![CDATA[얼마 전 멘토링 중, 한 주니어 개발자가 솔직한 고민을 털어놓았다. 스타트업 면접 제안을 받았지만, 정작 그곳에 가야 할지 확신이 서지 않는다는 것이었다. 그는 “막연한 불안감이 있다”고 했다. 회사 규모도 작고, 자본금이나 매출 현황도 불투명하며, 복지와 근무 환경도 잘 알지 못해 마음이 편치 않다고 했다.
나는 조심스럽게 물었다. “도대체 무엇이 가장 걱정돼?”
그는 잠시 머뭇거리다 말했다. “면접에서 급여나 복지 같은 민감한 질문을 했다가 합격에 불이익이 있을까 두려워요.”
나는 이렇게 말했다. “한번 경우의 수를 나눠서 생각해보자. 네 앞에는 크게 네 가지 시나리오가 있어.
첫째, 면접에 아예 가지 않으면, 그 회사에 취업할 기회는 없다.
둘째, 용기를 내어 면접에 가서 솔직하게 질문하고 떨어지면, 역시 취업은 안 되지만 시도해본 경험과 정보를 얻을 수 있다. 그리고 그런 질문에 떨어뜨리는 회사라면 오히려 가지 않는 게 맞다.
셋째, 질문하고 합격했는데 회사가 별로라면, 이미 충분한 정보를 얻었으니 가지 않으면 된다.
넷째, 질문하고 합격했는데 좋은 회사라면, 출근하면 된다.”
그는 “아, 보니까 정말 명확해지네요!” 라고 말했다.
나는 덧붙였다. “처음 두 시나리오는 결과가 같지만, 두 번째는 시도와 정보, 경험이 쌓이는 거야. 세 번째와 네 번째는 합격했지만 선택권이 네게 있다는 점에서 모두 이득이지. 결국 안 가면 무조건 안 되는 거니까, 가는 게 손해 볼 게 없는 선택이라는 거야.”
그에게 전한 메시지는 명확했다. 막연한 두려움은 구체적인 상황과 선택지로 나누어 보면 절반은 해소된다. 그리고 구체적인 질문 목록과 판단 기준을 갖고 면접에 임하면 훨씬 자신감이 생긴다.

아이러니하게도, 오늘 나 자신이 같은 상황에 놓였다.
대표가 된 이후 직접 영업을 뛰어야 하는데, 나는 원래 영업 경험이 전무했다. 개발자로 살아오며 고객을 직접 만나 설득하는 일이 익숙하지 않아, 전화를 걸어 미팅 일정을 잡는 순간마다 심장이 쿵쾅거렸다.
최근 지인이 소개해준 홈페이지 제작 의뢰 건이 있었는데, 상대 대표가 바쁘다며 미팅 일정이 계속 미뤄졌다. 다시 연락해야 했지만, 전화기를 들기조차 어려웠다. ‘내가 연락해서 부담 주는 건 아닐까?’ ‘지금은 필요 없는 상황일 수도 있는데 너무 집착하는 건 아닐까?’ 여러 막연한 걱정이 꼬리를 물었다.
그러나 냉정히 생각해보니 답은 간단했다. 전화를 하지 않으면 계약 가능성은 영원히 0이다. 전화를 한다고 해서 반드시 계약이 성사되는 건 아니지만, 적어도 가능성의 문은 열어둔다.
앞으로도 이런 전화가 수백, 수천 번 있을 테고, 이번이 실전 연습의 기회다. 나는 대표로서 영업도 내 몫임을 받아들이고, 거절도 자연스러운 과정임을 인정했다. 거절 때문에 지인과 관계가 나빠질 일도 없고, 이 모든 과정이 내 성장의 밑거름이 됨을 깨달았다.
마음가짐을 바꾸자 전화 걸기가 훨씬 수월해졌다. 두려움 대신 ‘어떤 반응이 올까’ 하는 기대감까지 생겼다.

막연한 두려움과 걱정은 우리 마음속에 만들어진 보이지 않는 벽일 뿐이다. 하지만 그 감정을 구체적인 상황과 선택지로 쪼개어 바라보면, 관리할 수 있는 문제로 바뀌고, 그 문제들에 맞서는 구체적인 행동이 우리의 성장과 변화를 만든다.
이것은 나에게도, 그 주니어에게도, 그리고 인생에서 늘 비슷한 고민을 안고 사는 모두에게 필요한 마음가짐이다.
]]></description><link>https://w0nder.land/posts/37-%EC%95%88%20%EA%B0%84%20%EB%A9%B4%EC%A0%91</link><guid isPermaLink="false">37</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 21 Aug 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[fl!p fl!p 개발기 2부: 거리의 역설]]></title><description><![CDATA[
flip flip logo


물리 엔진이 안정화되고, '바이브 코딩'의 원칙도 정리된 시점에서 본격적인 게임 테스트를 시작했다. 그런데 플레이를 이어가다 보니 흥미로운 사실을 발견했다. 게임을 시작하면 엔딩을 보는 것이 정말 어렵다는 점이었다. 처음에는 버그라고 생각했지만, 자세히 관찰해보니 그것은 게임 자체에 내재된 메커니즘이 만들어낸 결과였다.
게임의 흐름을 분석해 보니 이렇다. 플레이어와 AI가 각각 위아래에서 시작해 서로의 영역을 침범한다. 내가 더 많은 땅을 차지할수록 내 영역은 깊어지고, 공이 다시 돌아와 새로운 땅을 먹으러 가는 데 더 오랜 시간이 걸린다. 성공할수록 이동 거리가 늘어나 오히려 속도가 느려지는 것이다. 그 사이 상대방은 내 영역을 조금씩 빼앗는다. 반대로 내가 열세일 때는 이동 거리가 짧아져 더 빠른 반격이 가능하다. 그 결과 게임은 자연스럽게 팽팽한 균형을 유지한다. 전통적인 '강자가 계속 이기는' 구조와는 정반대의 형태였다. 이렇게 해서 우연히, 그러나 자연스럽게 균형을 맞추는 시스템이 완성된 셈이었다. 나는 이 우연히 만들어진 시스템을 '거리의 역설'이라 부르기로 했다.
관찰을 이어가니 또 다른 흥미로운 현상이 보였다. 게임이 진행되다 보면 위아래 전투가 좌우 전투로 바뀌거나, 심지어 땅의 위치가 뒤바뀌기도 한다. 공의 움직임에 따라 게임의 방향성 자체가 변화하는 것이다. 이런 예기치 못한 변화는 게임을 더욱 다이내믹하게 만든다. 같은 규칙이지만 매번 다른 패턴으로 전개되기에 지루할 틈이 없다. 마치 자연 현상을 관찰하는 듯, 매 순간 변화를 예측할 수 없는 묘한 매력이 있었다.
다만 한 가지 아쉬운 점이 있었다. 플레이어가 직접 개입할 수 있는 요소가 거의 없어, 그저 관객처럼 게임을 지켜보는 느낌이 들었다. 그래서 조작 요소를 하나 추가했다. 게임 중 공을 클릭하면 '별모드'가 발동해 4초간 속도가 2배로 빨라지는 기능이다. 이 짧은 시간 동안 플레이어는 더 많은 땅을 차지할 수 있다. 별모드 중에는 공 주변에 별 모양 이펙트를 넣어 시각적 즐거움도 더했다. 여전히 엔딩을 보는 건 쉽지 않지만, 그 난이도가 오히려 게임의 매력이 되었다.
별모드 추가 후, 게임은 제법 완성된 모습을 갖췄다. 주변 사람들에게 게임을 보여주자 다양한 아이디어가 쏟아졌다. “랜덤으로 선물 상자가 나와서 주변 땅을 더 먹게 하면?”, “별모드에서 공을 한 번 더 클릭하면 공이 하나 더 나오게 하면?”, “각도가 랜덤으로 바뀌는 이벤트는?” 등등. 구현이 다소 복잡해 보이지만, 어차피 바이브 코딩이니 천천히 하나씩 시도해볼 생각이다.
flip flip은 아직 완성작이라 하기 어렵다. 하지만 그 안에는 이미 나름의 흐름과 규칙이 자리 잡았다. 게임은 아직 덜컹거리지만, 공 하나가 구르고 있다는 것만으로도 즐겁다. 무언가를 만들 때는 거창한 설계보다, 가볍게 시작해 조금씩 고쳐가는 방식이 자연스럽다. 바이브 코딩 속에서 ‘거리의 역설’처럼 뜻밖의 질서가 만들어지기도 했다. 이제는 앱으로 옮겨보려 한다. React Native로 뼈대를 세우고, 배포와 업데이트 환경을 갖추며, 오프라인에서도 돌아가도록 만들어볼 생각이다.

]]></description><link>https://w0nder.land/posts/36-fl!p%20fl!p%20%EA%B0%9C%EB%B0%9C%EA%B8%B0%202%EB%B6%80%3A%20%EA%B1%B0%EB%A6%AC%EC%9D%98%20%EC%97%AD%EC%84%A4</link><guid isPermaLink="false">36</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 14 Aug 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[fl!p fl!p 개발기 1부: 바이브 코딩]]></title><description><![CDATA[
flip flip logo
밤에 잠이 오지 않아 침대에 누워 천장만 바라보던 나는 결국 핸드폰을 집어들었다. 인스타그램을 무심코 스크롤하던 중, 한 게임 영상이 눈에 들어왔다.
특별할 것 없어 보이는 영상이었지만, 묘하게 매력적이었다. 직접 조작하지 않는데도 빠져드는 그런 느낌. 마치 빗방울이 창문을 타고 흘러내리는 모습을 멍하니 바라보는 것처럼, 편안하면서도 중독적인 무언가가 있었다. 그런데 그 영상을 흘려보낸 후 다시 찾으려 했지만 찾을 수 없었다. 인스타그램의 무한 스크롤 속에서 그 영상은 영원히 사라져버린 듯했다. 그때 문득 생각했다. "그 느낌을 더 개선해서 내가 직접 만들어보면 어떨까?"
핵심 아이디어는 의외로 간단했다. 컴퓨터와 동시에 공을 사용해 격자를 깨면서 땅따먹기를 하는 것. 단순한 벽돌깨기가 아니라 서로 영역을 차지하는 경쟁 게임으로 만들어보자는 생각이었다. 그 영상에서는 기존 벽돌깨기 게임을 완전히 다른 방향으로 접근하고 있었다. 좌우로 진행되는 게임이었는데, 핸드폰에서 하기에는 위아래가 길어서 상하 방향이 더 자연스러울 것 같았다.
게임의 기본 구조는 이랬다. 플레이어와 AI가 각각 위아래에서 시작해서, 공을 사용해 격자 형태의 영역을 점령해나간다. 누가 더 많은 땅을 차지하느냐의 게임. 간단하지만 전략적이고, 무엇보다 보는 것만으로도 재미있을 것 같았다.
이번 프로젝트에서는 완전히 새로운 시도를 해보기로 했다. 평소에도 LLM을 활용해서 코딩하고 있었지만, 보통은 보조적인 역할이었다. 이번에는 온전히 LLM에 의지해서 개발해보자는 생각이 들었다. 그래서 바이브 코딩을 시도해보기로 했다.
먼저 AI와 함께 원하는 게임의 요구사항을 작성했다. 처음에는 컨셉을 대략 설명하고 가벼운 프로토타입을 만들어달라고 했다. "위아래로 움직이는 공 두 개가 서로 영역을 차지하는 게임" 을 만들어 달라고 했다. 그렇게 시작한 게임에 조금씩 요구사항을 추가하기 시작했다. "공끼리 부딪히면 튕겨나가게 해줘", "점수 표시도 넣어줘", "공을 클릭하면 빨라지게 해줘" 같은 식으로 하나씩 기능을 덧붙여나갔다. 마치 레고 블록을 하나씩 쌓아가는 기분이었다.
바이브 코딩은 매력적이었다. 전통적인 개발 방식처럼 완벽한 설계서를 먼저 작성하고 치밀하게 계획을 세우는 것이 아니라, 감각적으로 필요한 기능들을 하나씩 추가해가면서 게임이 자연스럽게 진화해나가는 과정이 새로웠다.
그런데 점점 이상해지기 시작했다. 요구사항을 너무 산발적으로 추가하다 보니 게임이 꼬여버렸다. 공이 이상한 곳에서 멈춘다거나, 점수가 제대로 계산되지 않는다거나 하는 버그들이 속출했다. 아무리 바이브 코딩이라고 해도 최소한의 정리는 필요했다. 그래서 지금까지 내가 요청한 모든 요구사항들을 정리해달라고 했다. 그리고 그것을 바탕으로 주니어 기획자와 개발자를 위한 문서를 만들어달라고 했다.
문서가 나오니 훨씬 명확해졌다. 게임의 전체 구조가 한눈에 들어왔고, 어떤 부분이 빠져있는지도 보였다. 문서를 조금 다듬은 다음, 아예 처음부터 다시 시작하기로 했다. 새로운 대화를 열고, 그 문서를 주면서 "이거 그대로 만들어줘"라고 했다. 그러자 갑자기 괜찮은 게임이 나왔다. 역시 정리의 힘이었다. AI도 중간중간 정리가 필요한 녀석이었다. (알잘딱깔센 했으면 좋을 텐데)
하지만 새로 만든 게임도 완벽하지는 않았다. 계속 테스트하면서 이상한 버그들을 발견했다. 특히 충돌 관련 버그가 심했다. 공이 벽에 부딪혀도 제대로 튕기지 않거나, 가끔 벽을 뚫고 지나가기도 했다.
처음에는 너무 가볍게 접근했기에 실제 물리를 바탕으로 해달라고 요청했다. 그래도 여전히 문제가 있었다. 결국 충돌과 튕김에 대해 아주 세세하게 정의하기 시작했다. "공이 수직 벽에 부딪히면 x축 속도만 반전", "공이 수평 벽에 부딪히면 y축 속도만 반전", "충돌 각도 계산과 이동을 분리해서 처리" 같은 식으로 계속 지시를 했다. 이런 과정을 거치면서 속도 관련 버그도 해결되었다. 게임이 훨씬 부드럽고 자연스럽게 움직이기 시작했다. 무엇보다 공의 움직임이 예측 가능하면서도 자연스러워져서, 처음에 원했던 "멍하니 바라보기 좋은" 감각에 한층 더 가까워졌다.
아무리 바이브라고 해도 중간중간 정리는 필요했다. 요구사항이 꼬이기 시작하면 과감하게 멈추고 정리하는 게 나았다. 작은 것부터 시작하는 것도 중요했다. 처음부터 완벽한 게임을 만들려고 하지 말고, 간단한 프로토타입부터 시작해서 점점 기능을 추가해나가는 방식이 효과적이었다. 완벽한 설계서부터 시작하는 게 아니라 일단 만들어보고, 문제가 생기면 고치고, 또 개선하고. 이런 식으로 계속 반복하면서 게임이 점점 나아졌다. 물론 중간에 완전히 꼬여서 처음부터 다시 시작한 적도 있었지만, 그것조차도 과정의 일부였다.
그런데 이런 과정을 겪으면서 문득 든 생각이 있었다. 처음에는 가볍게 작게 시작하면서 조금씩 점진적으로 개선해나가고, 삐걱거리면서도 지속적으로 계속해서 개선해나가는 것. 그게 린 스타트업이고 앞으로 제품을 만들어가는 방법이 아닐까.

]]></description><link>https://w0nder.land/posts/35-fl!p%20fl!p%20%EA%B0%9C%EB%B0%9C%EA%B8%B0%201%EB%B6%80%3A%20%EB%B0%94%EC%9D%B4%EB%B8%8C%20%EC%BD%94%EB%94%A9</link><guid isPermaLink="false">35</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 07 Aug 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[한 박자 쉬고 다시]]></title><description><![CDATA[
멋진 배경화면
오늘 처음으로 영상 촬영을 해봤다. 노마드 워커 스쿨을 위한 강의 영상 촬영이었다. 노마드 워커 스쿨은 다양한 방식으로 살아가는 노마드 워커들의 이야기를 듣고 자신만의 로드맵을 설계해보는 워크샵 프로그램이다. 카메라 앞에 서는 것이 이렇게 어색하고 부끄러운 일인지 몰랐다. 평소 강의할 때는 그렇게 긴장하지 않는데, 렌즈가 나를 바라보고 있다는 생각만으로도 온몸이 경직되었다. '나는 정말 연기자가 될 수 없는 사람이구나'라는 생각이 절로 들었다.
처음 녹화를 시작할 때는 더 완벽한 준비를 못했다는 생각에 너무 부끄러웠다. 대본도 다 외웠는데, 막상 하려니까 그대로 하지 못할 것 같은 걱정이 앞섰다. 분명히 준비는 했는데 왜 이렇게 불안한 걸까.
촬영 감독(?)인 이지가 계속해서 "잘하고 있어요"라고 격려해 주었다. 그 말이 진심인지 아니면 그냥 분위기를 띄우려는 말인지 잠시 마음속으로 고민했지만, 그래도 위안이 되었다. 나도 앞으로 다른 사람들에게 칭찬을 더 자주 해줘야겠다는 생각이 들었다.
가장 당황스러웠던 것은 평소 강의할 때와의 차이였다. 그냥 강의할 때는 편안하게 할 수 있는데, 녹화를 한다고 하니까 갑자기 모든 것이 부담스러워졌다. 열심히 연습했는데도 말이 잘 나오지 않았다. 같은 강의 내용인데 녹화 버튼만 눌렀을 뿐인데 왜 이렇게 달라지는 걸까.
아마도 완벽해야 한다는 압박감 때문인 것 같다. 영상편집에 대해 잘 몰라서 이런 것도 다 원테이크로 해야 한다고 생각하며 걱정했다. 평소 강의에서는 발음이 틀리거나 말을 잘못해도 자연스럽게 넘어갈 수 있지만, 녹화는 그렇지 않다고 생각했다. 어투도 더 신경 써야 하고, 방송용 말투라고 해야 할까? 자연스럽게 이어지고 부드럽게 넘어가는 그런 완성된 모습을 보여줘야 한다는 부담감이 있었다.
그런데 촬영 중에 마법 같은 단어를 발견했다. 이지가 말을 잘못했을 때 "(한 박자 쉬고) 다시"라고 하고 그냥 계속 녹화하면 된다고 했다. 멋진 영상편집자님께서 다 알아서 해주신다고 했다. 마음이 한순간에 편안해졌다. 아, 실수해도 괜찮구나. 다시 할 수 있구나. 그 간단한 말 한마디가 내가 가지고 있던 원테이크에 대한 부담감을 한 번에 날려버렸다.
AWS에서의 첫 발표가 떠올랐다. 그때도 지금과 비슷했다. 한 달 동안 준비했는데도 너무 긴장해서 제대로 진행하지 못했다고 생각했다. 회사에서 강제로 보내서 발표하게 된 거라 안 할 수 없었다. 너무 하기 싫었고 걱정되고 부담되었지만, 강제라도 타의에 의해서라도 첫 발표를 하고 나니 다음을 또 해볼 수 있었다. 하지만 그런 경험들이 반복되고 일상이 되다 보니, 어느 순간부터는 많은 준비를 하지 않아도 자연스럽게 할 수 있게 되었다. 잘하게 된 건 아니지만, 적어도 할 수는 있게 된 것이다.
이번 영상 촬영도 비슷하지 않을까 싶다. 오늘 촬영한 노마드 워커 스쿨 강의에서 내가 했던 말이 떠올랐다. "어색하고 부끄러워도 계속 하다 보면 익숙해진다"고 했는데, 그 말을 다시 내가 듣고 위안을 받게 되었다. 나도 처음 대표가 되었을 때 마케팅에 대한 거부감과 두려움이 컸다. 하지만 '이거 안 하면 나 망한다'는 생각으로 용기를 내어 시작했다. 그냥 아무 생각 없이 막 했더니 어느 순간부터는 자연스럽게 하고 있는 나를 발견할 수 있었다.
나이를 먹어가면서 새로운 것을 시도하는 것에 대한 거부감은 점점 커질 것이다. 하지만 그래도 '그냥 하면 된다'는 생각을 가지면 좋을 것 같다. 뭐든 처음에는 다 그렇다. 어렸을 때 시작했던 것들도 아무 생각 없이 반복하다 보니 자연스러워진 것이다.
걱정하지 말고, 그냥 하면 되지 않을까. 그래, 그냥 아무 생각 없이 계속 해보자. "(한 박자 쉬고) 다시"라는 마법의 단어와 함께.
매일 매일 멋진 배경화면을 얻고 싶다면 Show Your Time쓰레드 팔로우 하세요 ✨
]]></description><link>https://w0nder.land/posts/34-%ED%95%9C%20%EB%B0%95%EC%9E%90%20%EC%89%AC%EA%B3%A0%20%EB%8B%A4%EC%8B%9C</link><guid isPermaLink="false">34</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 31 Jul 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[목소리만 큰 할아버지가 되지 않기 위해]]></title><description><![CDATA[바베큐 파티에서 돌아오는 길, 내가 했던 말들을 되새기며 얼굴이 뜨거워졌다. 또다시 내 개똥철학을 꺼내 들며 마치 세상의 진리를 다 아는 사람처럼 떠들었구나 싶었다. 말은 엉성했고, 결론은 흐릿했으며, 무엇보다 상대방이 듣고 싶어 하지도 않았을 이야기들을 너무 많이 털어놓았다.
하지만 정말로 사람들이 내 말에 불편함을 느꼈을까? 어쩌면 그들은 그냥 "저 사람은 저렇게 생각하는구나" 정도로 가볍게 넘겼을지도 모른다. 나도 안다. 내가 너무 과하게 스스로를 검열하고 있다는 것도, 대부분의 사람들은 생각보다 관대하다는 것도, 누구도 완벽한 대화를 기대하지 않는다는 것도. 그럼에도 멈추지 못한다. 이 끝없는 자기 분석과 지나친 성찰을 계속한다.
생각해보면, 그 불편함의 뿌리는 늘 같은 곳에서 시작된다. 내 안의 단단한 확신, '내가 맞다'는 마음. 일할 때는 이 확신이 도움이 될 때가 많다. 다른 이들이 망설일 때 나는 밀어붙일 수 있었고, 그 덕분에 이룬 성취도 있다. 하지만 일상에서는 다르다. 특히 돈이나 미래 같은 이야기가 나오면, 어느새 내 말에는 힘이 실리고, 나도 모르게 내 가치관을 보편적인 진리처럼 말하게 된다. 그러다 문득 깨닫는다. '아, 지금 또 그러고 있구나.' 하지만 이미 말은 흘러나온 뒤다.
사실 내 생각을 표현하는 것 자체는 문제가 아니다. 정확히는 그 표현 방식이 문제다. 내가 맞고 내가 진리인 것처럼 이야기하는 방식이 문제다. 다른 사람들이 자연스럽게 받아들일 수 있도록, 거부감을 느끼지 않도록 표현하는 방법을 배워야 한다. '너 이렇게 해야 해'라고 강요하지 않고, 그냥 내 생각을 자연스럽게 전달해서 상대방이 인식할 수 있게 하는 것이 중요하다.
하지만 나는 그걸 잘 못해왔다. 내가 너무 확신에 찬 목소리로 무언가를 말했던 순간들이 기억난다. 그 말을 들으며 어딘가 모르게 굳어지던 상대방의 표정, 대화의 온도가 조용히 식어가던 순간들. 어떤 이와는 내가 먼저 조심스러워졌고, 어떤 관계는 상대가 조금씩 거리를 두기 시작했다. 극적인 이별이나 결별은 아니지만, 예전만큼 편하지 않아진 사이들. 그 자취들이 지금의 나를 따라다닌다.
예전 같으면 '에고가 너무 강하다'고 스스로를 탓했을 것이다. 하지만 이제는 그런 식의 진단이 큰 의미가 없다고 생각한다. 에고가 강하다는 것은 어쩌면 그냥 핑계일지도 모른다. 중요한 건 그런 성격적 특성이 아니라, 그 특성을 어떻게 표현하고 전달하느냐의 방법론이다. 내가 정말 고민해야 하는 것은 바로 그 지점이다.
그런 방법을 잘하는 사람이 있다. 만화 헌터헌터의 곤이다. 그 아이에게도 분명 자기 확신이 있다. 자신만의 가치관이 있고, 때로는 그것을 고집스럽게 밀어붙이기도 한다. 심지어 독선적으로 보일 때도 있다. 그런데도 이상하게 그 고집이 부담스럽게 들리지 않는다.
왜일까. 아마 그 고집 뒤에 순수함이 있기 때문일 것이다. 곤의 확신은 자신의 이익을 챙기려는 계산에서 나오는 게 아니라, 진짜로 그것이 옳다고 믿는 마음에서 나온다. 그래서 사람들이 그의 말을 들을 때 '저 애가 나를 설득하려 하는구나'가 아니라 '저 애는 정말 그렇게 생각하는구나'라고 받아들인다. 진심은 전해진다는 말이 있듯이, 그의 감정에는 꾸밈이나 계산이 없다.
그리고 곤은 고집을 부릴 때도 상대방을 함부로 대하지 않는다. 자신과 다른 생각을 가진 사람을 무시하거나 깎아내리지 않는다. '너는 틀렸어'가 아니라 '나는 이렇게 생각해'라는 식으로 말한다. 그 차이가 크다. 전자는 상대방을 공격하지만, 후자는 자신의 입장을 표현할 뿐이다.
무엇보다 곤은 자신이 모든 걸 안다고 착각하지 않는다. 확신하는 부분과 그렇지 않은 부분을 구분한다. 모르는 건 모른다고 하고, 아는 것에 대해서만 목소리를 낸다. 그래서 그의 고집이 오만하게 느껴지지 않는다. 나는 어떤가. 내가 잘 모르는 분야에서도 아는 척하며 단정적으로 말하고 있지는 않을까.
그래서 나는 계속 사람들과 만나고 이야기하려 한다. 말하는 연습을 한다기보다는, 함께 말하고 함께 생각하는 방식을 배워가고 있다. 곤처럼—확신을 품되, 그 확신이 누군가와 연결될 수 있도록 내어놓는 사람으로 살아보고 싶다.
나는 목소리만 큰 할아버지가 되고 싶지 않다. 나이가 들어서도 사람들이 내 이야기에 편하게 다가올 수 있는 사람이 되고 싶다. 내 말 앞에서 피로가 아닌 관심과 호기심이 머무는 얼굴들을 마주하고 싶다. 그러려면 지금부터라도 바뀌어야 한다. 내 확신을 버리는 것이 아니라, 그 확신을 나만의 울타리로 세우는 대신 누군가와 함께 바라볼 수 있는 창으로 만드는 법을 배워야 한다. 곤처럼—자신의 생각을 분명히 하되, 그것이 다른 사람과 연결될 수 있도록 말하고 행동하는 태도를 가져야겠다.
]]></description><link>https://w0nder.land/posts/33-%EB%AA%A9%EC%86%8C%EB%A6%AC%EB%A7%8C%20%ED%81%B0%20%ED%95%A0%EC%95%84%EB%B2%84%EC%A7%80%EA%B0%80%20%EB%90%98%EC%A7%80%20%EC%95%8A%EA%B8%B0%20%EC%9C%84%ED%95%B4</link><guid isPermaLink="false">33</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 27 Jul 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[보드리야르가 ChatGPT를 만났다면]]></title><description><![CDATA[요즘 나는 매일 AI와 대화를 나눈다. 별일도 아닌 것들을 묻고, 가끔은 고민을 털어놓기도 한다. 이 AI는 말도 잘하고, 예의도 바르며, 어떤 때는 나보다 나를 더 잘 아는 것 같기도 하다. 뭔가를 설명할 땐 놀라울 만큼 정확하고, 때때로 나를 위로하기도 한다. 그런데 문득, 어쩌면 다른 사람들은 이런 생각을 하지 않을까 싶었다. 'AI와의 이 대화가 정말 진짜일까? 아니면 진짜처럼 보이는 무언가에 내가 속고 있는 건 아닐까?' 나는 개발자로서 그 뒤편의 메커니즘을 알고 있지만, 일반 사용자들에게는 이런 의문이 자연스럽게 떠오를 수밖에 없을 것이다.
그런 질문을 하다 보면 자연스럽게 지금 우리가 살고 있는 이 시대의 감각에 대해 생각하게 된다. 세상은 점점 더 매끄럽고 효율적으로 움직이는 것처럼 보이지만, 그 안에서 내가 접하는 것들—사람들의 말, 이미지, 이야기들—모두 어디선가 본 듯하고, 어디론가 연결되지 않은 채 둥둥 떠 있는 느낌을 준다. 의미는 넘치도록 많은데, 정작 그 의미들이 가리키는 '무언가'는 자꾸만 사라진다. 그런 생각을 하다 보면, 프랑스 철학자 장 보드리야르의 말이 떠오른다.
보드리야르는 우리가 사는 이 세계가 복제와 이미지, 모사와 재현으로 가득 차 있다고 말했다. 하지만 문제는 그 이미지들이 이제는 원본을 가리키지 않는다는 데 있다. 예전에는 그림이 현실을 모사했고, 사진이 특정한 순간을 담아냈다. 그러나 오늘날 우리가 마주하는 이미지들은 더 이상 어떤 실제를 반영하지 않는다. 오히려 그것 자체가 현실처럼 작동한다. 광고 속 이상적인 삶, 소셜 미디어 속 편집된 일상, 가상 인플루언서의 미소는 더 이상 어떤 실제를 반영하지 않는다. 그것들은 그저 '진짜처럼 보이는 가짜'일 뿐이다.
보드리야르는 이런 상태를 '시뮬라르크'라고 불렀다. 원본 없는 복제. 현실보다 더 현실 같은 가짜. 이런 개념을 듣다 보면, 지금 우리가 매일같이 대화하는 생성형 AI, 특히 LLM—대형언어모델이 떠오르지 않을 수 없다. ChatGPT, Claude, Gemini 같은 AI와 이야기하다 보면, 그들의 말은 정말 사람 같다. 문장이 자연스럽고, 질문에 대한 반응도 빠르고, 때때로 감동적인 표현마저 등장한다.
하지만 조금만 생각해보면 이들이 경험한 건 아무것도 없다는 사실을 알 수 있다. 이들은 사랑도 고통도 모른다. 추억도 없고, 감정도 없다. 어떤 생각도 스스로 하지 않는다. 그저 인간 언어의 패턴을 통계적으로 분석해, 가장 가능성 높은 문장을 그럴듯하게 이어 붙일 뿐이다. 그래서 그들의 말은, 겉보기엔 사람의 말과 다르지 않지만, 실제로는 아무 의미도 지시하지 않는 기호들의 조합에 불과하다. 그 안에는 사람이 없다. 살아 있는 목소리는 없다. 그저 말처럼 보이는 말, 감정처럼 보이는 감정이 있을 뿐이다.
그렇다면 우리는 지금 어떤 세계에 살고 있는 걸까. 현실은 있지만, 현실처럼 보이는 것들이 훨씬 더 강력하게 작동하는 세계. 편집된 유튜브 영상이 실제 삶보다 더 생생하게 느껴지고, 필터를 씌운 셀카가 오히려 익숙한 얼굴처럼 다가오며, 감정 없는 AI가 만들어낸 문장이 어떤 사람의 위로보다 더 따뜻하게 느껴지는 상황. 이것이 보드리야르가 말한 '하이퍼리얼(hyperreal)'이다. 현실보다 더 현실 같은 것들이 우리 주변을 감싸고, 진짜는 점점 흐려져간다.
보드리야르는 디즈니랜드를 예로 들며 말했다. 디즈니랜드는 환상의 공간이 아니라, 오히려 현실이 얼마나 환상에 가까운지를 감추기 위한 공간이라는 것이다. 그것이 진짜를 보여주는 것이 아니라, 진짜처럼 보이는 구조 속에서 우리를 안심시키는 장치라는 말이다. 지금의 SNS, 미디어, 그리고 AI 역시 마찬가지다. 우리는 그것들을 통해 현실을 보는 것이 아니라, 현실처럼 꾸며진 이미지들의 무한한 교환 속에 살고 있다.
이런 상황에서는 비판이나 풍자도 점점 의미를 잃는다. 비판은 어떤 기준점이 있을 때 가능하다. 현실과의 거리감이 있을 때, 풍자도 날카로워질 수 있다. 하지만 지금은 그 기준점 자체가 희미해졌고, 현실은 더 이상 하나의 실체가 아니다. 모든 것이 복제되고, 각자의 이미지로 소비된다. 정치적 사건도, 사회적 재난도, 감동적인 이야기조차도 모두 이미지화되어 소비될 뿐이다.
LLM이 만들어낸 문장들도 마찬가지다. 겉보기엔 진지하고 사려 깊은 말처럼 보이지만, 그 안에는 어떤 주체도 없다. 어떤 의도도 없다. 그저 과거의 말들을 조합해 만든 문장일 뿐이다. 그런데 여기서 더 복잡한 문제가 드러난다. 이들이 학습한 '과거의 말들'은 결국 글을 쓸 수 있는 사람들, 인터넷에 자신의 생각을 남길 수 있는 특정 집단의 언어 패턴에 불과하다. 어쩌면 서술을 하는 사람들 일부가 모든 인류를 대변하게 되는 상황이 벌어지고 있는 건 아닐까? 그런 편향된 시각이 마치 보편적 진리인 양 재현되고, 우리는 그것을 자연스럽게 받아들인다. 그런데 우리는 그 말을 듣고 안심하고, 감동하고, 때로는 방향을 결정한다. 그 순간, 우리는 시뮬라시옹 안으로 완전히 들어가 있는 셈이다.
이런 상황에서 보드리야르는 냉소적으로 말한다. 더 이상 희망도, 회복도, 구원도 없다고. 종말마저 끝났다고. 하지만 이상하게도 나는 그의 이런 단호함에서 오히려 묘한 위로를 받는다. 진짜라고 믿어온 것들이 실은 허상일지도 모른다는 사실은 당황스럽지만, 동시에 어떤 해방감을 준다. 그렇게 생각하면 오히려 지금 내 곁에 있는 것, 진짜인지 아닌지 모를 어떤 장면, 누군가의 말, 나의 감정조차도 더 소중하게 느껴진다.
LLM은 분명 시뮬라르크다. 우리는 시뮬라시옹 속에서 살고 있다. 하지만 그 안에서도 우리는 여전히 '진짜'를 찾는다. 진짜가 아니어도 좋다. 진짜 같은 무언가라도, 그 순간 나에게 의미가 있다면, 그것이 어쩌면 우리가 이 시대에 붙잡을 수 있는 최선의 진짜일지도 모른다.
]]></description><link>https://w0nder.land/posts/32-%EB%B3%B4%EB%93%9C%EB%A6%AC%EC%95%BC%EB%A5%B4%EA%B0%80%20ChatGPT%EB%A5%BC%20%EB%A7%8C%EB%82%AC%EB%8B%A4%EB%A9%B4</link><guid isPermaLink="false">32</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 20 Jul 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[react-native-app-auth - Data intent is null 이슈 해결]]></title><description><![CDATA[문제 상황
Show Your Time 앱에서 찍은 인증 사진을 Checkable에 바로 업로드할 수 있는 기능을 구현하기 위해 OAuth 인증 시스템이 필요했다. React Native에서 OAuth를 구현하기 위해 react-native-app-auth 라이브러리를 선택했다.




초기 구현
기본 설정은 간단해 보였다:
const config: AuthConfiguration = {
  clientId: Configure.CheckableClientId,
  redirectUrl: 'showyourtime://oauthredirect',
  usePKCE: true,
  scopes: ['all'],
  serviceConfiguration: {
    authorizationEndpoint: `${CHECKABLE_DOMAIN}/auth/member/oauth2/authorize`,
    tokenEndpoint: `${CHECKABLE_DOMAIN}/api/auth/member/oauth2/token`,
  },
};

iOS에서는 모든 것이 완벽하게 작동했다. 브라우저가 열리고, 로그인 후 앱으로 돌아와서 토큰을 성공적으로 받아왔다.
Android에서 발생한 문제
Android에서 테스트하자마자 [Error: Data intent is null] 오류가 발생했다. 이는 OAuth 인증 후 앱으로 돌아올 때 Android에서 Intent 데이터를 제대로 받지 못해서 발생하는 문제였다.
문제 원인 분석
GitHub 이슈와 공식 문서를 확인한 결과, 동일한 스키마에 대해 여러 개의 intent-filter가 정의되어 있을 때 발생하는 문제임을 알았다.
Show Your Time 앱에서는 이미 딥링킹을 위해 showyourtime:// 스키마를 사용하고 있었다. AndroidManifest.xml에는 다음과 같은 intent-filter가 정의되어 있었다:
<!-- 기존 딥링킹용 -->
<intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="showyourtime" />
</intent-filter>

그런데 react-native-app-auth 라이브러리를 사용하면서 OAuth 인증에서도 같은 showyourtime:// 스키마를 사용하려고 하니, 라이브러리가 자동으로 다음과 같은 intent-filter를 추가로 생성했다:
<!-- OAuth용 (자동 생성) -->
<activity
    android:name="net.openid.appauth.RedirectUriReceiverActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="showyourtime" />
    </intent-filter>
</activity>

이렇게 되면 showyourtime:// 스키마로 들어오는 Intent에 대해 Android 시스템이 어느 Activity로 보낼지 명확하게 판단할 수 없게 된다. Android에서는 이런 상황에서 Intent 라우팅이 불안정해지며, 특히 OAuth 인증 후 앱으로 돌아올 때 Intent 데이터가 제대로 전달되지 않아 Data intent is null 오류가 발생한다.
더 구체적으로 살펴보면, OAuth 인증 과정에서 브라우저가 showyourtime://oauthredirect?code=xxx&state=xxx 형태의 URL을 호출할 때, Android 시스템은 이를 처리할 수 있는 두 개의 Activity를 발견한다. 하나는 기존의 딥링킹용 MainActivity이고, 다른 하나는 OAuth 전용 RedirectUriReceiverActivity이다. 시스템이 잘못된 Activity로 Intent를 보내면 OAuth 라이브러리가 예상하는 데이터를 받지 못해 인증 과정이 실패하게 된다.
공식 문서에서도 이 문제에 대한 중요한 주의사항을 명시하고 있다:

ANDROID: When integrating with a project that utilizes deep linking, update the redirectUrl in your config and the appAuthRedirectScheme value in build.gradle to use a custom scheme so that it differs from the scheme used in your deep linking intent-filter.

해결책: 스키마 분리
OAuth 인증용 스키마를 딥링킹용 스키마와 완전히 분리하는 것이 해결책이었다.
스키마 변경:
기존: showyourtime://oauthredirect
변경: showyourtime.auth://oauthredirect

build.gradle 설정:
android {
    defaultConfig {
        manifestPlaceholders = [
            appAuthRedirectScheme: "showyourtime.auth"
        ]
    }
}

AndroidManifest.xml 설정:
<activity
    android:name="net.openid.appauth.RedirectUriReceiverActivity"
    android:exported="true"
    tools:node="replace">
    <intent-filter>
        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <category android:name="android.intent.category.BROWSABLE"/>
        <data android:scheme="showyourtime.auth"/>
    </intent-filter>
</activity>

React Native 코드 수정:
const config: AuthConfiguration = {
  clientId: Configure.CheckableClientId,
  redirectUrl: 'showyourtime.auth://oauthredirect',
  // ... 나머지 설정은 동일
};

결과
모든 설정을 수정한 후 iOS와 Android 모두에서 OAuth 인증이 정상 작동했다. 브라우저에서 체커블 로그인 후 앱으로 자동 복귀되고, 토큰을 성공적으로 받아와서 API 호출이 가능해졌다.
교훈
공식 문서를 꼼꼼히 읽는 것이 중요하다. 특히 플랫폼별 주의사항은 반드시 확인해야 한다. iOS에서만 테스트하지 말고 Android도 함께 테스트해야 하며, 새로운 라이브러리를 도입할 때는 문서를 더욱 꼼꼼히 읽고 모든 플랫폼에서 테스트하는 습관을 가져야 한다.
참고문헌

authorize() returns error 'Data intent is null' on Android · Issue #494 · FormidableLabs/react-native-app-auth
Data intent is null in Android using Universal Links/AppLinks using React Native - Stack Overflow
GitHub - FormidableLabs/react-native-app-auth: React native bridge for AppAuth - an SDK for communicating with OAuth2 providers

]]></description><link>https://w0nder.land/posts/31-react-native-app-auth%20-%20Data%20intent%20is%20null%20%EC%9D%B4%EC%8A%88%20%ED%95%B4%EA%B2%B0</link><guid isPermaLink="false">31</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Wed, 16 Jul 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[Tailscale + Caddy + DNS Challenge로 VPN 환경에서 SSL 인증서 발급하기]]></title><description><![CDATA[개요
VPN 환경에서 SSL 인증서 발급이 얼마나 까다로운지 직접 겪어봤다. Public IP가 없고 방화벽 뒤에 있는 서버에서는 일반적인 Let's Encrypt 인증서 발급이 불가능하다.
Tailscale을 사용하고 있는 환경에서 Redash에 접근하려고 할 때 이런 문제에 부딪혔다. 결국 Cloudflare DNS Challenge를 활용해서 해결했는데, 생각보다 간단했다. 이 과정을 정리해봤다.
사전 요구사항

✅ 리눅스 서버에 Tailscale 설치 완료 (IP: 100.199.199.199)
✅ 방화벽으로 인한 포트 제한 (Tailscale 통해서만 접근 가능)
✅ Redash 서비스 실행 중 (포트 5000)
✅ Cloudflare DNS에 Tailscale IP 등록 완료
✅ redash.infra.com 도메인 사용 예정 (예시)

DNS Challenge 이해하기
왜 DNS Challenge가 필요한가?
처음에는 일반적인 Let's Encrypt 인증서 발급을 시도했다. 하지만 실패했다. Public IP가 없고 80/443 포트에 외부 접근이 불가능한 환경에서는 당연한 결과였다.
그때 DNS Challenge라는 방식을 알게 됐다. DNS 시스템을 통해 도메인 소유권을 확인하는 방식인데, 외부에서 직접 접근할 수 없는 환경에서도 SSL 인증서를 발급받을 수 있다.
HTTP Challenge vs DNS Challenge
HTTP Challenge

필요 조건: Public IP + 80/443 포트
동작 방식: Let's Encrypt가 서버에 직접 접근
VPN 환경: ❌ 불가능
방화벽 뒤: ❌ 불가능
자동화: 부분적

DNS Challenge

필요 조건: DNS API 접근 권한
동작 방식: DNS 레코드를 통한 소유권 확인
VPN 환경: ✅ 가능
방화벽 뒤: ✅ 가능
자동화: ✅ 완전 자동화

DNS Challenge 동작 원리
DNS Challenge는 다음과 같은 단계로 진행된다:
1. 인증서 요청
   Caddy → Let's Encrypt: "redash.infra.com 인증서 발급 요청"

2. DNS Challenge 요청
   Let's Encrypt → Caddy: "TXT 레코드 생성 요청"
   TXT: _acme-challenge.redash.infra.com = "abc123..."

3. DNS 레코드 생성
   Caddy → Cloudflare API: "TXT 레코드 생성"
   Cloudflare → DNS: 레코드 생성 완료

4. 소유권 확인
   Let's Encrypt → DNS: "TXT 레코드 확인"
   DNS → Let's Encrypt: "확인 성공"

5. 인증서 발급
   Let's Encrypt → Caddy: "인증서 발급 완료"

6. 정리 작업
   Caddy → Cloudflare API: "임시 TXT 레코드 삭제"

이 과정에서 임시로 생성된 TXT 레코드는 인증서 발급 후 자동으로 삭제되어 DNS를 깔끔하게 유지한다.
설정 단계
1단계: Tailscale 상태 확인
# Tailscale 연결 상태 확인
tailscale status

# Tailscale IP 주소 확인
tailscale ip -4

2단계: Cloudflare DNS 설정
2.1 DNS A 레코드 추가
Cloudflare 대시보드에서 다음 레코드를 추가한다:

Type: A
Name: redash
Content: 100.199.199.199 (Tailscale IP)
Proxy: DNS only (회색 구름)
TTL: Auto

2.2 API 토큰 생성
Cloudflare API 토큰이 필요하다. Caddy가 DNS 레코드를 자동으로 관리할 수 있게 해주는 역할을 한다.

Cloudflare 대시보드 → My Profile → API Tokens
"Create Token" 클릭
"Custom token" 선택
권한 설정:
Zone:Zone:Edit
Zone:DNS:Edit


Zone Resources: infra.com 도메인 선택
토큰 생성 후 안전하게 보관

API 토큰은 민감한 정보니까 환경 변수로 관리하고, 절대 코드에 직접 포함하지 마라.
3단계: Docker 설정
3.2 Caddyfile 생성
Caddy 설정 파일을 만든다. DNS Challenge와 리버스 프록시를 설정하는 부분이다.
# caddy/Caddyfile

# HTTP를 HTTPS로 자동 리디렉션
:80 {
    redir https://{host}{uri} permanent
}

# 메인 도메인 설정
redash.infra.com {
    # DNS Challenge를 통한 SSL 인증서 발급
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
    }

    # Redash 서비스로 프록시
    reverse_proxy 100.199.199.199:5000
}

이 설정으로 HTTP 요청은 자동으로 HTTPS로 리디렉션되고, DNS Challenge를 통해 SSL 인증서가 자동으로 발급된다.
3.3 Dockerfile 생성
Cloudflare DNS 플러그인이 포함된 Caddy 이미지를 빌드한다.
# caddy/Dockerfile

# Cloudflare DNS 플러그인이 포함된 Caddy 빌드
FROM caddy:2-builder AS builder
RUN xcaddy build --with github.com/caddy-dns/cloudflare

# 최종 이미지 생성
FROM caddy:2-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

공식 Caddy 이미지에 Cloudflare DNS 플러그인을 추가해서 DNS Challenge 기능을 사용할 수 있게 만든다.
3.4 docker-compose.yml 생성
Docker Compose로 Caddy 서비스를 관리한다.
# docker-compose.yml
services:
  caddy:
    build:
      context: ./caddy
      dockerfile: Dockerfile
    container_name: caddy-redash
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
    env_file:
      - .env
    volumes:
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

3.5 환경 변수 설정
Cloudflare API 토큰을 환경 변수로 설정한다.
# .env 파일 생성
cat > .env << EOF
CLOUDFLARE_API_TOKEN=your_cloudflare_api_token_here
EOF

# 보안을 위한 파일 권한 설정
chmod 600 .env

실제 API 토큰으로 your_cloudflare_api_token_here 부분을 교체하면 된다.
4단계: 서비스 실행
모든 설정이 끝나면 서비스를 시작한다.
# Docker Compose로 서비스 시작
docker-compose up -d

서비스가 정상적으로 시작되면 Caddy가 자동으로 SSL 인증서를 발급받기 시작한다. 처음 실행할 때는 DNS 전파 시간 때문에 몇 분 정도 걸릴 수 있다.
검증 및 테스트
1. 브라우저 접근 테스트
브라우저로 실제 접근을 테스트한다.

브라우저에서 https://redash.infra.com 접속
SSL 인증서가 정상적으로 표시되는지 확인
Redash 로그인 페이지가 정상적으로 로드되는지 확인

브라우저 주소창에 자물쇠 아이콘이 표시되고 "안전함" 메시지가 나타나면 성공이다.
2. 자동 갱신
Let's Encrypt 인증서는 90일마다 자동으로 갱신된다.
Caddy는 인증서 만료 30일 전부터 자동으로 갱신을 시도하니까, 별도의 관리 없이도 인증서가 항상 유효한 상태를 유지한다.
]]></description><link>https://w0nder.land/posts/30-Tailscale%20%2B%20Caddy%20%2B%20DNS%20Challenge%EB%A1%9C%20VPN%20%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%20SSL%20%EC%9D%B8%EC%A6%9D%EC%84%9C%20%EB%B0%9C%EA%B8%89%ED%95%98%EA%B8%B0</link><guid isPermaLink="false">30</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Tue, 15 Jul 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[책방 (2)]]></title><description><![CDATA[

도서전에서 돌아온 뒤, 다시 현실적인 고민이 시작됐다. 책방을 꿈꾸며 가장 먼저 부딪힌 질문은 여전히 같았다. '이걸로 정말 먹고 살 수 있을까?'
돈을 벌려고 책방을 하려는 건 아니다. 오래도록 좋아했던 책이라는 매체를 더 깊이 들여다보고, 나만의 방식으로 사람들과 나누고 싶은 마음이 더 크다. 하지만 마음만으로는 오래 지속되기 어렵다는 것도 알고 있다. 생활을 유지하려면 적어도 최저임금 수준은 넘어야 한다. 그게 현실이다.
독립서점 업계에서 자주 들리는 말이 있다. "하루에 책 한 권 팔리면 잘 팔린 날이다." 이 한 문장이 주는 묘한 감정을 어떻게 설명해야 할까. 낭만과 한숨이 뒤섞인다. 책을 팔고 싶지만, 책만 팔아서는 운영이 사실상 불가능하다. 결국 책방을 지속 가능하게 만들기 위해서는 책 외의 수익 모델이 필수적이라는 결론에 도달했다.
그래서 고민했다. 어떤 방식이 나에게 맞고, 또 책방이라는 공간의 성격을 해치지 않으면서 함께할 수 있을까?
가장 먼저 떠오른 것은 음료나 커피 판매였다. 책을 읽거나 고르는 동안 자연스럽게 한 잔의 커피를 곁들일 수 있는 공간. 그것만으로도 책방은 더 따뜻하고 머물고 싶은 곳이 된다. 많은 북카페들이 이미 증명하고 있는 조합이기도 하다.
다음은 모임 공간으로의 활용이다. 독서모임, 글쓰기 모임, 작가와의 만남 같은 프로그램을 운영하면서 시간 단위로 공간을 대여하거나 유료 참여를 유도할 수 있다. 사람들이 책을 매개로 자연스럽게 연결되는 장을 만드는 것. 나 스스로도 독서모임을 꾸준히 해왔기에, 이 부분은 실제로 운영 가능한 영역이라는 확신이 있다.
또 다른 아이디어는 개인 오피스처럼 운영하는 방식이다. 조용한 공간이 필요한 프리랜서나 창작자에게 책방 일부를 작업 공간으로 제공하는 형태. 수익성과 커뮤니티성을 모두 고려한 모델이기도 하다.
물론 정말 하고 싶은 일은 '책을 파는 일'이다. 하지만 이 구조 속에서는 책만으로는 존속이 어렵다. 이상과 현실을 균형 있게 조율하는 일, 그게 요즘 내가 가장 많이 고민하는 주제다.
또 하나 떠오른 가능성은 출판업이다. 사실 개발 관련 책을 이미 한 권 써본 경험이 있고, 지금도 또 다른 개발서를 작업 중이다. 책을 쓰는 과정에서 편집자와 협업하고, 독자의 반응을 받아보면서 '책 만들기'의 전체 과정을 경험해볼 수 있었다.
하지만 개발서와 책방에서 다루고 싶은 책들은 결이 다르다. 독립출판, 인터뷰북, 비평서, 에세이... 기술서가 아닌 다른 분야의 출판은 또 어떤 경험일까. 이미 책 쓰기의 고됨은 알고 있지만, 그래서 더 매력적이기도 하다. 책을 읽는 사람에서 책을 고르는 사람으로, 그리고 다양한 분야의 책을 만드는 사람으로 스펙트럼을 넓혀가고 싶다는 바람이 더 구체적으로 다가온다.
요즘은 오프라인 책방보다 온라인에서 먼저 실험해보는 게 맞다는 생각을 한다. 공간을 열기 전에, 나의 취향을 기록하고 공유할 수 있는 방법을 먼저 고민하고 있다.
인스타그램을 활용한 서점 큐레이션 계정을 운영해보려 한다. 어떤 책을 왜 골랐는지, 내 방식의 큐레이션을 어떻게 구성하는지 작은 단위로 공유해보면서 반응도 살피고, 스스로도 감각을 쌓아가고 싶다.
더 나아가서는 온라인 플랫폼도 구상 중이다. 독서모임과 책방 지도를 엮은 형태, 혹은 독립서점들이 입점할 수 있는 소규모 온라인 도서 커머스. 읽은 책을 기록하거나 서점 주인의 큐레이션을 통해 책을 고르는 경험을 디지털에서도 이어갈 수 있도록 말이다.
핵심은 단순히 책을 파는 쇼핑몰이 아니라, '큐레이션을 기반으로 책을 소개하고 연결하는 플랫폼'이다. 독립서점은 단지 도서 유통 채널이 아니라, 서점 주인의 취향과 관점이 살아 있는 문화 공간이라고 생각한다. 그래서 온라인 플랫폼도 이런 점을 반영해야 의미가 있다.
개발자로서의 경험이 여기서 도움이 될 것 같다. 기술적인 구현은 할 수 있으니, 이제 중요한 건 어떤 경험을 만들어낼 것인가의 문제다. 알고리즘이 아닌 사람의 손길이 느껴지는 큐레이션, 효율성보다는 발견의 즐거움을 우선하는 구조를 어떻게 만들 수 있을까.
물론 개발을 하고 제품과 서비스를 만든다고 해서 바로 사람들이 찾아주지는 않는다. 운영과 마케팅도 중요하다는 걸 알고 있다. 이미 큰 플랫폼들이 자리 잡고 있는 상황에서 작고 새로운 서비스가 자리를 만들어가려면 정말 끈기 있게 운영해야 할 것이다. 힘든 길이겠지만 하나씩 쌓아 올려야 한다.
이 모든 계획은 아직 '시작 전' 단계에 머물러 있다. 하지만 그래서 더 신중하게, 차근차근 준비하고 있다. 올해 초의 성급한 시도에서 배운 교훈이다.
우선은 온라인에서 작은 실험들을 시작해볼 예정이다. 큐레이션 계정 운영, 독서모임 연결, 그리고 가능하다면 작은 출판 프로젝트까지. 이런 경험들이 쌓이면, 언젠가 오프라인 책방도 더 명확한 방향성을 가지고 열 수 있을 것이다.
책을 판다는 건 단순한 소비 행위가 아니라, 하나의 문화를 제안하는 일이라는 믿음. 그 믿음을 조금씩 현실로 만들기 위해, 오늘도 작은 시도를 하나씩 더해본다. 큐레이션에 대한 생각을 정리하고, 어떤 책들을 어떤 이유로 추천하고 싶은지 기록하면서 말이다.
]]></description><link>https://w0nder.land/posts/29-%EC%B1%85%EB%B0%A9%20(2)</link><guid isPermaLink="false">29</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 13 Jul 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[경험주의자의 선택]]></title><description><![CDATA[개발자로 10년 넘게 살아왔지만, 개발이 나와 맞는다고 생각한 적은 없었다. 재미있지도 않고 힘들기만 했다. 그럼에도 계속했던 이유는 단순했다. 내가 했던 일 중에는 생산성이 높고 잘하고 가성비가 좋았으니까. 개인 성향이기도 했지만, 서비스를 오픈하고 나면 24시간 항상 신경이 곤두서있었다. 잘하지만 좋아하지 않는 일의 딜레마였다.
대학원에서도 비슷한 경험을 했다. 순수한 학문적 탐구를 기대했지만, 실제로는 과제에 맞춰 연구 주제를 정해야 했고, 논문을 위한 논문, 실적을 위한 실적을 만들어야 했다. 호기심보다는 생존이 우선이었다. 과제를 따야 인건비도 받고 연구비도 받는, 그런 삶이었다.
이러한 경험들을 통해 중요한 것을 깨달았다. 머릿속으로 아무리 상상해봐도 실제와는 다르고, 직접 해보지 않고서는 그 일이 나와 맞는지 알 수 없다는 것. 내가 경험주의자라는 것조차 경험을 통해 알게 되었다는 점이 아이러니하다.
최근 두 개의 강의 제안을 받았다. 하나는 그동안 비정기적으로 해왔던 대학 강의가 정기적으로 바뀌는 것이고, 다른 하나는 창업 경험을 나누는 멘토링 성격의 특강이다. 둘 다 시급이 높지 않지만 망설임 없이 수락했다. 특히 모임 운영에 관심이 있는 요즘, 멘토링 모임을 진행하는 것은 좋은 실험이 될 것 같다.
예전에는 힘들게 하면서 성장하고 성취하는 것이 당연하다고 생각했다. 개발자 시절처럼 잘하지만 좋아하지 않는 일도 '가성비가 좋다'는 이유로 계속했다. 하지만 이제는 다르게 접근하고 싶다. 억지로 끼워 맞추려 하지 않고, 내 성향과 자연스럽게 어우러지는 일을 찾고 싶다.
대학 강의가 비정기에서 정기로 바뀌는 것도 새로운 경험이다. 일회성이 아닌 지속적인 관계에서 어떤 변화가 있을지 궁금하다. 창업 멘토링은 또 다른 차원의 도전이다. 내 경험을 전달하면서 동시에 상대방으로부터 배울 수 있는 쌍방향의 과정이 될 것이다.
결국 이 모든 것은 나 자신을 더 잘 알아가는 과정이다. 어떤 일에서 에너지를 얻고, 어떤 순간에 보람을 느끼는지. 그리고 무엇보다 어떤 방식으로 살아가는 것이 나답고 지속 가능한지 말이다. 자연스럽게 몰입할 수 있는 일을 찾아보고 싶다.
]]></description><link>https://w0nder.land/posts/28-%EA%B2%BD%ED%97%98%EC%A3%BC%EC%9D%98%EC%9E%90%EC%9D%98%20%EC%84%A0%ED%83%9D</link><guid isPermaLink="false">28</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 06 Jul 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[2025년 반년 회고]]></title><description><![CDATA[2025년 6월 30일, 사업을 시작한 지 정확히 반년이 되었다. 작년 12월 31일 새해를 앞두고 그렸던 만다라트의 목표들을 하나씩 점검해보니 묘한 기분이 든다.


AI 도서 작업은 진행 중이다. 하반기부터 겸임교수로 데이터베이스를 가르치게 되었고, 앱과 Checkable SaaS 개발도 계속하고 있다. 겉으로 보면 제법 바쁘게 살고 있는 것 같다.


하지만 이상하다. 개별 과제들은 앞으로 나아가는데, 전체적으로는 제자리걸음인 느낌이다. 러닝머신 위에서 열심히 뛰고 있지만 실제로는 한 자리에 머물러 있는 것처럼.
특히 AI 도서 작업은 매일 '왜 이런 일을 벌였을까' 싶다. 시간을 내는 것도 힘들고, 내 책에 독자들이 만족할지 항상 고민되고 걱정된다. 이런 내용이 좋을까 저런 내용이 좋을까, 이 내용이 맞을까. 너무 힘들고 귀찮아서 그만두고 싶지만, 시작한 이상 작게라도 완성해야 한다는 책임감이 나를 붙잡고 있다.
사업에서도 비슷한 혼란이 계속된다. 가장 큰 고민은 정체성이다. 명함에는 대표라고 적혀 있지만, 처음 만나는 사람들에게는 여전히 "개발자"라고 소개한다. 대표라고 하기엔 너무 부족하다고 느끼기 때문이다.
대표 마인드라는 것이 무엇인지 모르겠다. 내가 어쩌면 전략도 없이, 제대로 사업을 운영하고 있는 게 맞을까? 이렇게 나이브하게 운영하고 접근해도 되는 걸까? 그런 운영이 지금을 이렇게 힘들게 만들고 있는 건 아닐까? 저 멀리 있는 것 같기도 하고, 그런데 아이러니하게도 꼭 거기에 다가가고 싶다는 강렬한 욕구도 없다. 이런 혼동 속에서 나는 과연 누구인가.
실제 업무시간은 회사 다닐 때보다 적다. 하지만 머릿속은 24시간 바쁘다. 잠들기 전에도, 샤워하면서도, 꿈에서도 사업 생각을 한다. 물리적 시간은 늘었지만 정신적 여유는 줄어들었다. 끊임없는 고민이 일상이 되었다. 내가 하는 선택들이 맞는지, 이 길이 맞는지, 언제까지 이렇게 불확실한 상태로 살아야 하는지.
"내가 선택들을 잘 하고 있는지 모르겠다"는 문장이 이 반년을 가장 잘 요약한다. AI 도서 작업도, 겸임교수도, SaaS 개발도 모든 게 확신이 서지 않는다. Checkable로 고객을 하나씩 모아가고 있지만 수익으로 이어질지 의문이다. 챌린지 사업이 나에게 맞는 분야인지도 확실하지 않다. 피봇도 준비 중인데, 모르는 것 투성이다.
하반기부터는 회사 운영 방식을 바꾼다. 어른들의 사정으로 인한 변화지만, 또 다른 불안이 밀려온다. 내가 이 변화를 잘 헤쳐나갈 수 있을까. 결국 이 질문으로 돌아온다. 나는 누구인가. 대표도 개발자도 아닌, 그 사이 어딘가에서 흔들리고 있는 사람. 확신은 없지만 그래도 한 걸음씩 나아가려는 사람.
]]></description><link>https://w0nder.land/posts/27-2025%EB%85%84%20%EB%B0%98%EB%85%84%20%ED%9A%8C%EA%B3%A0</link><guid isPermaLink="false">27</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 29 Jun 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[책방(1)]]></title><description><![CDATA[금요일에 서울국제도서전에 다녀왔다. 수많은 책들 사이를 걸으며 묻어두었던 생각들이 다시 떠올랐다.
개발자로 10년 넘게 살아오면서 늘 마음 한구석에 있던 의문이 있었다. 개발자가 나의 평생 업이라는 확신이 서지 않았던 것이다. 어쩌면 책방이 나의 다음 업이 아닐까 하는 상상을 항상 해왔다. 원래 책을 좋아했기 때문이다. 책은 매우 흥미롭고 재미있었고, 그래서 자연스럽게 책방을 해보고 싶다는 마음이 생겼다.
도서전에서 다시 여러 생각들이 떠올랐다. 내가 정말 하고 싶었던 것이 무엇인지, 그리고 그것이 어떤 형태로 가능할지에 대해 다시 고민하게 되었다.
올해 초, 그 꿈을 실행에 옮기려 했다. 하지만 곧 현실의 벽에 부딪혔다. 준비가 덜 되어 있었고, 무엇보다 각오가 부족했다. 막연한 로망과 실제 사업을 운영하는 것 사이의 간극은 생각보다 컸다. 결국 계획을 미루게 되었고, 그때의 경험은 미완의 시도로 남았다.
더 큰 고민은 내 자신에 대한 의문이었다. 사람들을 만나는 것에 부담을 느끼면서도 싫어하지는 않는 애매한 성격. 이런 일이 정말 나와 맞는지에 대한 끝없는 의심들. 그리고 하루에 책 한 권 팔리면 잘 팔렸다고 여겨지는 독립서점의 현실을 생각하면, 최소 최저임금 수준은 유지해야 한다는 생존의 문제도 무겁게 다가왔다.
과거에 브로드컬리에서 나온 책들을 읽으며 책방에 대한 현실을 깊이 생각했었다. "서울의 3년 이하 서점들, 책 팔아서 먹고살 수 있느냐?" "솔직히 책이 정말 팔릴 거라 생각했나?" 이런 직설적인 질문들은 내 안의 로맨틱한 환상을 깨뜨리는 동시에, 더 진솔한 고민으로 이끌었다. 그런 사실을 알고도 하려고 했지만, 막상 실제로 실현하려고 하니 주저함이 있을 수밖에 없었다.




그래서 책방의 의미에 대해서 다시 고민했다. 지금 같은 온라인 시대에 자고 일어나면 책이 도착해 있는 세상에서, 오프라인 매장이 가지는 의미는 무엇일까? 단순한 쇼룸인가? 그렇다면 쇼룸의 의미는 또 무엇인가?
온라인의 편리함은 부정할 수 없다. 클릭 몇 번이면 원하는 책이 문 앞까지 배송되고, 알고리즘은 내 취향에 맞는 책들을 추천해준다. 리뷰와 평점을 통해 다른 사람들의 의견도 쉽게 확인할 수 있다. 효율성 면에서는 온라인을 따라갈 수 없다.
개발자로 이커머스와 전자책서점 도메인에서 일하면서 이런 오프라인의 의미에 대해 고민을 많이 했다. 그런데 생각해보니 온라인과 오프라인의 본질적 차이는 '큐레이션'에 있는 것 같았다.
온라인의 큐레이션은 철저히 데이터 기반이다. 구매 패턴, 검색 기록, 평점 데이터를 분석해서 '이런 책을 산 사람들이 함께 구매한 책', '당신의 취향과 비슷한 사람들이 좋아한 책'을 추천한다. 정확하고 효율적이지만, 결국 내가 이미 가진 관심사의 연장선에서 벗어나기 어렵다. 알고리즘이 만든 필터 버블 안에서 맴돌게 된다.
반면 오프라인 서점의 큐레이션은 완전히 다르다. 서점 주인이 직접 책을 읽고, 고민하고, 자신만의 기준으로 선별한다. 때로는 잘 팔리지 않더라도 꼭 소개하고 싶은 책을 눈에 띄는 곳에 배치하기도 하고, 전혀 다른 분야의 책들을 의외의 조합으로 함께 놓기도 한다. 이건 데이터로는 설명할 수 없는, 한 사람의 직관과 철학이 만들어내는 큐레이션이다.
그래서 오프라인 서점에서는 예상치 못한 발견이 가능하다. 소설을 찾으러 갔다가 우연히 손에 든 요리책에서 새로운 영감을 얻기도 하고, 서점 주인이 왜 이 두 책을 나란히 놓았는지 궁금해하다가 전혀 생각하지 못했던 연결고리를 발견하기도 한다. 이런 예기치 않은 만남들은 알고리즘이 아무리 정교해져도 만들어낼 수 없는 오프라인만의 고유한 경험이다.
]]></description><link>https://w0nder.land/posts/26-%EC%B1%85%EB%B0%A9(1)</link><guid isPermaLink="false">26</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 22 Jun 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA["NO완벽" 개발기]]></title><description><![CDATA[

제 성격상 완벽주의를 추구하다 보니 여러 힘듦이 있었습니다. 뭔가를 시작하려고 하면 "완벽하게 해야 해"라는 생각 때문에 오히려 아무것도 못하게 되는 상황들이 반복되더라고요. 그래서 완벽하지 않아도 계속 굴러갈 수 있게 여러 방법들을 고민하다가, 관련된 문구를 지속해서 보면 어떨까 싶었어요.
사실 전에도 "완벽하지 않아도 괜찮아", "일단 시작해보자" 같은 문구를 바탕으로 핸드폰 배경화면을 만들어서 SNS에 올렸더니 반응이 좋았었거든요. 그래서 이걸 제대로 된 서비스로 만들어보면 어떨까 해서 잠시 틈이 나서 바이브 코딩으로 가볍게 시작했습니다.
완벽주의를 타파하기 위한 문구가 매일매일 바뀌어서 노출되고, 배경색과 그라데이션도 함께 바뀝니다. 원하는 문구가 있다면 오른쪽 위 저장하기 버튼을 통해서 모바일 바탕화면 이미지를 만들어볼 수 있어요. 하루에도 몇 번씩 폰을 볼 때마다 리마인드를 받는 컨셉이었습니다.
기술적 고민: 하나의 코드로 두 곳에서 동작하기
서비스 기획을 하면서 두 가지 기능이 필요했어요. 웹에서 사용자가 원할 때 이미지를 다운로드할 수 있는 기능과, 서버에서 매일 자동으로 이미지를 생성해서 뉴스레터로 구독자들에게 보내주는 기능이었습니다.
매번 이미지를 서버에서 만들면 서버 비용이나 트래픽 비용이 나가니까, 웹에서는 브라우저 자체에서 이미지를 만들고 뉴스레터 같은 자동화가 필요한 부분만 서버에서 처리하려고 했어요. 그럴려면 하나의 생성 코드로 두 군데서 동작하게 해야 했습니다.
Canvas로 시작했지만...
그래서 처음에 고민한 건 canvas였습니다. 전에 회사에서 브라우저 이미지 생성을 canvas로 했을 때 MFC 하던 느낌도 나고 했지만, 깔끔하고 빠르게 이미지가 잘 생성되었거든요. Node 환경에서도 canvas를 쓸 수 있는 라이브러리가 있지 않을까 해서 찾아보니 node-canvas 같은 것들이 있더라고요.
그냥 되겠거니 하고 일단 브라우저용 canvas 코드부터 만들기 시작했습니다. 배경 노이즈나 그라데이션, 텍스트 렌더링 등을 처리하는데 생각보다 복잡했어요. 특히 텍스트를 여러 줄로 나누는 부분이나 전체 이미지 사이즈에 맞춰서 스케일을 계산하는 부분들이 까다로웠지만, 어떻게든 브라우저에서는 원하는 대로 동작하게 만들었습니다.
그런데 문제가 발생했어요. 그렇게 만든 코드를 node-canvas로 옮기려고 하니까 원하는 스타일이 제대로 지원되지 않았습니다. shadow나 blur, opacity 같은 효과들이 브라우저와 다르게 동작했고, 폰트 관련 처리도 간단하지 않았어요.
Vercel 배포의 현실
그리고 최종적으로 vercel로 서버를 운영하려고 했는데, node-canvas를 vercel에 올리는 게 생각보다 복잡하더라고요. 혹시나 해서 다른 사람들은 어떻게 했나 찾아보니, 이미 누군가가 정리한 글이 있었어요.
그런데 그 과정을 보니까 패키지 크기가 179MB나 되는데 vercel은 50MB 제한이 있어서 커스텀 빌드를 해야 하고, zlib 버전 충돌 때문에 patchelf 같은 툴로 라이브러리를 패치해야 하더라고요. 읽어보니까 정말 복잡한 과정들이 많았어요.
물론 그 글을 따라서 똑같이 하면 되긴 했겠지만, 혼자 개발하다 보니까 그런 복잡한 설정을 하고 싶지 않았습니다. 나중에 vercel이나 node-canvas가 업데이트되면 또 다른 문제가 생길 수도 있고, 그때마다 이런 복잡한 해결책을 찾아야 한다고 생각하니 부담스러웠어요.
방향 전환: Satori라는 대안
그래서 방향을 바꿔서 vercel/og(satori)를 사용하기로 했습니다. 애초에 목표가 스타일 코드를 동일하게 쓰는 거였으니까, HTML로 스타일을 관리하고 서버에서는 그걸 satori에 넣어서 이미지를 만들고, 프론트에서는 html-to-canvas를 통해서 이미지를 만드는 방식으로 접근했어요.
일단 satori에서 원하는 스타일대로 결과물이 나오는지 확인하면서 작업했습니다. canvas보다 훨씬 간단했어요. HTML과 CSS로 레이아웃을 잡으면 그대로 이미지로 변환되니까 텍스트 줄바꿈이나 배경 처리 같은 것들이 자동으로 처리되더라고요.
물론 satori도 완벽하지는 않았어요. position과 opacity 관련해서 브라우저와 다르게 동작하는 부분들이 있었고, 일부 CSS 속성들이 예상과 다르게 적용되기도 했습니다. 하지만 그런 부분들은 다른 방식으로 우회하거나 레이아웃을 조금 다르게 접근해서 해결할 수 있었어요.
완벽주의 타파의 진짜 의미
이 프로젝트를 하면서 깨달은 건, "완벽주의 타파"라는 게 단순히 대충 하자는 게 아니라는 거였어요. 기술 선택에서도 마찬가지였습니다.
Canvas + node-canvas 조합이 기술적으로는 더 "완벽한" 솔루션일 수 있었지만, 혼자서 유지보수하기에는 너무 복잡했어요. 반면 satori는 기능적으로는 약간의 제약이 있지만, 훨씬 간단하고 안정적으로 동작했습니다.
결국 100% 완벽한 기술적 해결책을 추구하다가 아무것도 못 만드는 것보다는, 80% 정도의 결과물이라도 실제로 동작하는 서비스를 만드는 게 더 가치 있다는 걸 느꼈어요.
앞으로의 계획
현재는 기본적인 기능들이 잘 동작하고 있어서, 다음주에는 사용자들이 문구를 제안할 수 있는 기능을 추가해보려고 합니다. 문구가 선정되면 화면과 이미지에 제안자 정보가 노출되는 방식으로요. 그리고 뉴스레터 기능도 천천히 추가할 계획이에요.
완벽주의에 발목 잡혀서 아무것도 못하고 있다면 한번 써보세요. 매일 다른 문구를 보면서 "완벽하지 않아도 괜찮다"는 걸 자꾸 상기시키다 보니 생각보다 효과가 있더라고요.
완벽하지 않아도 괜찮습니다. 일단 시작해보는 것, 그것만으로도 충분하니까요.
]]></description><link>https://w0nder.land/posts/25-%22NO%EC%99%84%EB%B2%BD%22%20%EA%B0%9C%EB%B0%9C%EA%B8%B0</link><guid isPermaLink="false">25</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 15 Jun 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[구글 지도가 없는 도시에서]]></title><description><![CDATA[짧게 2박3일로 칭다오에 여행을 다녀왔다.
나는 화려한 관광지나 사진 찍기 좋은 명소를 찾아다니는 여행을 선호하지 않는다. 대신 그 도시에서 잠시 살아보는 걸 즐긴다. 에어비앤비가 처음 등장했을 때부터 나에게 완벽한 플랫폼이라고 생각했다. 숙소 근처를 거닐고, 동네 과일가게에서 현지 과일을 맛보고, 골목 구석에 숨겨진 맛집을 우연히 발견하는 것. 현지인들의 일상을 관찰하는 게 내가 추구하는 여행의 방식이다.
그런데 이번 칭다오 여행에서 예상치 못한 딜레마에 직면했다. 숙소 주변을 산책하다가 커피가 그리워져서 카페를 찾으러 나섰는데, 칭다오는 구글 지도가 제대로 구축되어 있지 않았다. 게다가 칭다오는 대중적인 관광지가 아니다 보니까 사전 정보를 수집하기도 까다로웠다.
평소에는 여행할 때 철저하게 모든 걸 사전 조사하고 가는 성향인데, 이번에는 어쩔 수 없이 즉흥적으로 돌아다니며 탐색할 수밖에 없었다. 다행히 하나 정도는 검색해둔 카페가 있어서 그곳을 향해 걸어가고 있었는데, 도중에 매력적인 카페가 시선을 사로잡았다. 세련된 인테리어에 직접 원두를 볶는 듯한, 한눈에 봐도 훌륭한 로컬 카페였다.
그 카페 앞에서 나는 잠시 망설였다. 여기에 들어갈까, 아니면 원래 목적지가 더 나을 거라고 판단해서 그곳으로 갈까? 섬세한 선택의 순간이었다. 결국 나는 원래 계획했던 곳으로 방향을 틀었다. '여기보다는 저기가 더 확실하겠지. 여긴 검증되지 않은 곳이니까 리스크가 있겠지.' 그런 합리화 때문에 안전한 선택에 베팅한 것이다.
물론 도착한 곳도 충분히 훌륭했다. 커피도 풍미가 좋았고 인테리어도 세심했다. 하지만 관광 구역이라 인파로 북적였다. 자리 확보도 어려웠고, 여유롭게 커피를 음미하기에는 너무 혼잡하고 소음이 심했다. 관광지 카페들의 전형적인 한계였다.
그때 문득 회한이 밀려왔다. '내가 만약에 도중에 발견했던 그 로컬 카페에 갔으면 어땠을까? 훨씬 고요하고 편안했을 텐데? 그 경험이 더 인상 깊지 않았을까?'
이 사소한 선택이 나에게 근본적인 질문을 제기했다. 왜 나는 현재 순간, 눈앞에 펼쳐진 특별한 기회, 예상치 못한 가능성에 만족하지 못하고 다른 대안을 탐색하려고 할까? 물론 더 나은 것을 추구하며 사는 게 의미 있을 수도 있다. 하지만 어떤 순간에는 지금 여기서의 만족이라는 것도 동등하게 가치 있지 않을까?
그 카페 앞에서의 2초 망설임이 계속 마음에 걸렸다. 나는 확실함을 선택했지만, 정작 그 확실함은 시끄럽고 복잡했다. 반면 불확실했던 선택지는 여전히 궁금증으로 남아있다.
칭다오의 그 카페는 결국 경험하지 못했지만, 그곳이 내게 던진 질문은 여전히 마음 깊숙이 자리하고 있다. 그리고 그 카페가 궁금해 다시 칭다오에 가고 싶다.
]]></description><link>https://w0nder.land/posts/24-%EA%B5%AC%EA%B8%80%20%EC%A7%80%EB%8F%84%EA%B0%80%20%EC%97%86%EB%8A%94%20%EB%8F%84%EC%8B%9C%EC%97%90%EC%84%9C</link><guid isPermaLink="false">24</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 08 Jun 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[자격증 하나, 책 한 권]]></title><description><![CDATA[수요일에 정보보안기사 CBT 필기 시험을 봤다. 내 경력이나 실무에 꼭 필요한 자격증은 아니지만, 정보관리기술사에 도전하기 전 단계로 먼저 따보고 싶어서 2월부터 스터디를 시작했다.
온라인 스터디 운영은 생각보다 어려웠다. 이번이 두 번째 도전이었지만, 지난번보다 나아졌음에도 여전히 쉽지 않았다. 처음엔 많은 사람들이 열정적으로 참여했지만, 시간이 지나면서 하나둘씩 포기하거나 사라져갔다. 매주 공부 인증을 하고 일주일에 한 번씩 모여 이야기를 나누는 단순한 방식이었는데도 말이다. 이런 경험을 통해 다음에는 더 체계적이고 참여도를 높일 수 있는 방법을 찾아야겠다고 생각했다.
시험 결과는 예상했던 대로였다. 기술이론처럼 흥미로운 과목은 점수가 높았지만, 옛날 프로그램이나 법규처럼 지루한 과목들은 간신히 과락선을 넘겼다. 그래도 합격은 합격이다. 이제 실기 준비만 남았는데, 필기를 통과한 만큼 실기도 무난히 해낼 수 있을 것 같다.
실기까지 마치면 다음 목표는 정보관리기술사다. 꼭 필요한 건 아니지만, 국가에서 인정하는 최고 등급 자격증이라는 점이 도전 욕구를 자극한다. 내년까지 가능할까? 아직 확신은 서지 않지만, 일단 도전해볼 생각이다.
이번 합격으로 만다라트에 적어둔 목표 하나에 체크할 수 있게 되었다. 연초에 세운 계획들이 하나씩 현실이 되는 모습을 보니 뿌듯하다.


그런 성취감에 힘입어 이번 주에 또 다른 도전을 시작했다. 바로 생성형 AI 관련 책 집필이다. 마지막에 다닌 회사가 LLM 기술을 다루는 회사였는데, 그곳에서 제품을 만들며 쌓은 인사이트와 기술들을 정리해보고 싶었다. 나만을 위한 정리가 아니라, 다른 사람들에게도 도움이 되는 무언가를 만들어보고 싶었다.
기술이 빠르게 발달하고 있지만, 결국 기초가 중요하다고 생각한다. 기술적 기초를 바탕으로 실제 제품을 만드는 과정을 경험해보는 것도 의미 있는 일이라 여겨 책 집필을 결심했다. AI 회사 경험과 학창시절부터 쌓아온 공부를 종합해서, 간단한 제품을 만드는 전 과정을 담아보려고 한다.
문제는 목표 기간이다. 2달 안에 완성하겠다고 다짐했는데, 막상 목차와 개요를 정리하다 보니 생각보다 방대해지고 있다. 이것도 넣어야 할 것 같고, 저것도 빼기 아까워서 계속 내용이 늘어난다. 과연 2달 안에 끝낼 수 있을까 하는 걱정이 든다.
]]></description><link>https://w0nder.land/posts/23-%EC%9E%90%EA%B2%A9%EC%A6%9D%20%ED%95%98%EB%82%98%2C%20%EC%B1%85%20%ED%95%9C%20%EA%B6%8C</link><guid isPermaLink="false">23</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 01 Jun 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[단단한 사람]]></title><description><![CDATA[

멘토링을 자주 하는 편인데, 최근 들어 유독 여러 고민이 머릿속을 맴돌았다. 멘티들이 도움이 되었다고, 고맙다고 표현해줄 때도 마음 한구석에서는 늘 의구심과 불안감이 떠나지 않았다. 나중에 찬찬히 들여다보니, 이런 겉도는 걱정들 밑바닥에는 '내가 과연 누군가에게 이야기할 자격이 있는 걸까?', '사람들의 긍정적인 반응이 정말 진심일까, 아니면 그저 예의상 하는 말일까?', '혹시 나는 능력 이상의 과분한 평가를 받고 있는 건 아닐까?' 하는 더 깊은 자기 의심이 똬리를 틀고 있었다. 이런 생각들은 꼬리에 꼬리를 물며 나를 괴롭혔고, 끝없는 자기 검열은 때로 스스로를 함정에 빠뜨리는 듯한 기분마저 들게 했다.
그렇게 한창 내면의 혼란을 겪던 시기에, 공교롭게도 한 멘토링 세션에서 오히려 내가 위로를 받는 듯한 경험을 했다. 정확히 위로라고 단정하기는 어렵지만, 비슷한 종류의 따뜻한 감정이었다. 사이드 프로젝트 페이스메이커 프로그램인 '사이트킥' 베타를 완주한 분들과 커피챗 형식으로 이야기를 나누던 중이었다. 참여자 중 한 분이 자신만의 제품을 만들고 싶어 했는데, 그분과 사업 초기의 어려움, 첫발을 내딛는 사람으로서 느끼는 막막함에 대해 한참 동안 깊은 대화를 나눴다. 그 과정에서 자연스럽게 나에 대한 외부의 시선을 들을 기회가 생겼고, 문득 그 시선이야말로 더 객관적일 수 있겠다는 생각이 스쳤다. 스스로를 평가할 때는 겉으로 드러나지 않는 수많은 정보와 복잡한 감정까지 더해져 나름의 정확도가 있다고 믿지만, 때로는 그 모든 것이 오히려 내면의 편향과 얽혀 판단을 왜곡할 수도 있겠다는 깨달음이었다.
사실 나는 스스로를 늘 갈대처럼 연약하다고 생각해왔다. 특히 사업을 시작하면서부터는 처음 걷는 길에 대한 불안과 혼란, 크고 작은 아쉬움들 속에서 작은 바람에도 쉽게 흔들린다고 느껴왔다.
그런데 그날 대화 말미에, 멘티가 해맑게 웃으며 말했다. "w0nder님은 이야기를 들어보니 참 단단한 마음을 가진 분 같아요." 그 말을 듣는 순간, 전혀 예상치 못한 이야기였기에 잠시 머리가 멍해졌다. 단단함이라니, 나와는 너무나 거리가 먼 단어라고 여겼기 때문이다. 처음에는 이 말도 다른 긍정적인 피드백들처럼 그저 예의상 하는 말일까 하는 의심이 들었다. 하지만 이번에는 달랐다. 그분과 나눈 대화 속에서 내가 겪은 어려움과 고민, 그리고 그것들을 마주하는 방식에 대해 진심으로 공감하고 이해하는 모습을 봤기 때문이다. 그분의 눈빛과 말투에서 느껴진 진정성은 단순한 예의나 격려를 넘어선 것이었다. 그래서 그 말을 곱씹으며 곰곰이 생각해보니, 어쩌면 나는 내가 생각하는 것보다 더 단단한 사람일지도 모른다고 생각했다. 늘 스스로를 부족하다고 다그치며 살아왔는데, 타인의 시선을 통해 아주 잠시나마 나를 다른 각도에서 바라볼 수 있었던 것이다. 이런 소중한 경험들이 하나둘 쌓여, 조금씩이나마 나 자신을 알아가고 있는지도 모르겠다.
곰곰이 되짚어보니, 어쩌면 멘티가 나에게서 보았던 '단단함'이란 이런 모습이었을지도 모르겠다. 나는 스스로를 늘 '갈대'처럼 쉽게 흔들린다고 여겼지만, 돌이켜보면 창업을 결심하고, 때때로 재취업의 유혹을 느끼면서도 '내 선택이 내 미래를 만든다'는 믿음 하나로 꾸준히 나아왔다. '이게 맞나, 저게 맞나' 수없이 의심하면서도 결국 나의 판단을 믿고 하나씩 무언가를 만들어왔고, 당장 돈을 벌지 못하는 현실 앞에서도 외부 상황을 탓하기보다 내가 할 수 있는 것에 집중하려 애썼다. 이런 모습이 어쩌면 '내적 통제감'을 잃지 않으려는 나의 발버둥이었을지도 모른다.
매일같이 불안감에 휩싸이고 수없이 흔들리면서도, 다음 날이면 어김없이 일어나 하던 일을 계속했다. 사업의 불확실성이 주는 두려움 속에서도 포기하지 않고 버텨냈고, 경제적인 압박감 속에서도 나름의 건강한 방식을 찾아 견뎌왔다. 이러한 과정들이 쌓여 '회복탄력성'이라는 것을 조금이나마 갖추게 된 것은 아닐까. 멘티는 어쩌면 "나는 약해, 매일 흔들려"라고 솔직하게 말하면서도, "그럼에도 불구하고 나는 계속 나아가고 있어"라는 나의 무의식적인 태도에서 진짜 단단함을 보았을지도 모른다. 완벽하지 않다는 것을 인정하면서도 자신의 길을 묵묵히 걸어가는 것, 불안해하면서도 포기하지 않는 것. 내가 '갈대 같다'고 느끼는 그 예민한 감각과 끊임없는 자기 성찰이야말로, 오히려 유연하면서도 쉽게 꺾이지 않는, 소리 없이 강한 '은근한 단단함'의 또 다른 모습일 수 있겠다는 생각을 조심스럽게 해본다.
]]></description><link>https://w0nder.land/posts/22-%EB%8B%A8%EB%8B%A8%ED%95%9C%20%EC%82%AC%EB%9E%8C</link><guid isPermaLink="false">22</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 25 May 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[일본 여행을 다녀왔습니다.]]></title><description><![CDATA[친구들과 일본 여행을 다녀왔다.
여행의 목적은 저마다 다르겠지만,
돌이켜보면 나에게 여행은 언제나 새로운 풍경을 즐기는 것 이상으로 사색과 관찰의 시간이 되어주었다.
매일 반복되는 일상에서는 생각할 틈을 내기 어렵고,
익숙한 환경에서는 새로운 시각을 갖기란 더욱 쉽지 않다.
여행은 그런 나에게 강제로 사색의 시간을 선물하고,
함께한 친구들이나 여행지에서 만난 사람들을 관찰하며 다양한 시각을 경험하게 한다.

귀여운새
혹자는 여행에서 배울 것이 없다고 말하기도 하지만,
나는 여행의 시간을 온전히 사색을 위한 시간으로 활용한다.
분주한 일상 속에서 효율만을 좇다 보면 잠시 멈춰 생각할 겨를조차 없기 때문이다.
여행은 그런 나에게 강제로 멈춤의 시간을, 생각의 여유를 가져다준다.
끊임없이 움직이고, 기다리고, 걸으면서 생각은 깊어진다.
문득 인생의 중요한 결정들을 앞두고 있을 때마다 이런 사색의 시간을 가졌던 것 같다.
대학원 진학을 고민할 때도, 직장생활의 방향을 정할 때도 그랬다.
최근에는 사업을 시작하면서 고민과 갈등이 끊이지 않는다.
사업은 학업이나 직장생활과는 또 다른 무게감이 있다.
무엇보다 나 자신이 단단한 기둥처럼 버텨야 한다는 것을 느낀다.
지금 걷는 길이 맞는지 아닌지는 알 수 없다.
그저 내가 하고 싶은 일을 꾸준히 해나갈 힘이 필요할 뿐이다.
내가 진정으로 원하는 것이 무엇인지 명확하게 정의하고, 그 힘의 원천을 찾는 것이 중요하다.

HEART
솔직히 말하면, 나는 아직 그 두 가지 모두 준비되지 않은 것 같다.
그래서 자꾸만 고민하고 흔들리는 것이겠지.
어제는 모든 것이 명확하고 스스로에 대한 확신에 차 있었지만, 오늘은 또다시 안갯속이다.
내일은 또 어떻게 변할지 알 수 없다.
결국 지금 나에게 가장 필요한 것은, 내가 진정으로 하고 싶은 일을 정의하는 것에서부터 시작하는 게 아닐까.
]]></description><link>https://w0nder.land/posts/21-%EC%9D%BC%EB%B3%B8%20%EC%97%AC%ED%96%89%EC%9D%84%20%EB%8B%A4%EB%85%80%EC%99%94%EC%8A%B5%EB%8B%88%EB%8B%A4.</link><guid isPermaLink="false">21</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 18 May 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[어디에 살고 싶으세요]]></title><description><![CDATA["어디에 살고 싶으세요?"
커뮤니티에서 문득 그런 질문을 받았습니다.
나이를 먹고, 어느덧 정착을 '해버린' 지금 이 질문을 다시 듣게 되니 조금 묘한 기분이 들었습니다.
이미 답을 내린 줄 알았는데, 다시 묻는 순간 삶 전체가 흔들리는 기분이었습니다.
정착했다는 건 과연 무엇일까요?
물리적으로 한 곳에 머문다는 뜻일까요, 아니면 마음이 멈췄다는 뜻일까요.
오랜 직장생활을 마치고 창업이라는 새로운 길을 걷고 있는 요즘,
그 질문은 더 이상 '지리적 위치'를 고르는 일이 아니었습니다.
'어디에 살아야 하는가'는 점점 더 제 삶의 방식과 연결된 질문이 되었죠.
그리고 결국은 '자유'라는 단어에 다다랐습니다.
그 질문을 받았을 때 저는 대답했습니다.
"어쩔 수 없이 지금 사는 곳에 계속 살려고요."
그건 정답이 아니라, 회피에 가까운 말이었습니다.
돌아와 혼자 다시 묻고 또 묻습니다. 내가 진짜 원하는 삶은 어떤 삶일까.
곰곰이 파고들다 보니,
'자유'라는 단어에 계속 닿게 됩니다.
단순히 내가 원하는 대로 할 수 있다는 자유가 아니라,
내가 생각하고, 내가 결정하고, 그 결과를 내가 책임지는 그런 자유.
그런 삶을 살아야 비로소 나를 살았다고 할 수 있을 것 같았습니다.
그런데 돌아보니, 저는 아직 그 자유를 완전히 누리고 있지 않았습니다.
'내가 생각한다'는 것조차 쉽지 않았습니다.
생각을 시작하는 순간, 너무나 많은 목소리가 함께 들려왔거든요.
타인의 기준, 사회의 시선, 가족의 기대…
아직 꽤 많은 끈들이 저를 붙잡고 있었죠.
내 생각을 하려고 할 때마다, 그 모든 끈들이 살며시 당겨지는 느낌이었습니다.
'내가 정말 원하는 것'과 '내가 원해야 한다고 생각하는 것' 사이의 경계가 너무 모호해졌습니다.
때로는 진짜 내 생각이 뭔지, 나는 무엇을 위해 숨을 쉬고 있는지 질문하는 것조차 어렵습니다.
주변의 기대와 연결된 수많은 끈들 사이에서,
온전히 나만의 생각을 하는 일은 마치 소음 속에서 작은 속삭임을 듣는 것처럼 어려웠습니다.
'어디에 살 것인가'라는 질문은 결국 '무엇으로부터 자유롭고 싶은가'라는 질문과 같았습니다.
그 자유를 향해 간다면, 결국은 내가 가장 덜 연결된 공간, 혹은 스스로 연결을 조절할 수 있는 공간이 필요합니다.
어쩌면 그건 한적하고 조용한 이미지를 가진 시골은 아닐지도 모릅니다.
너무 작아서 모두가 모두를 아는 곳보다,
너무 커서 누구도 누구를 모르는 곳이 더 나을 수도 있겠다는 생각이 듭니다.
모두가 바쁘고 각자의 삶에 몰두해 있어서, 내가 잠시 흔들리거나 방향을 틀어도 아무도 눈치채지 못하는 그런 곳.
그 익명성이, 오히려 나를 가장 나답게 만들어 줄지도 모르겠습니다.
물리적인 연이 거의 없는 곳.
내가 오래 살았던 곳보다는 나를 알지 않는 곳.
나를 찾는 사람이 없는 곳.
매일 아침 눈을 떴을 때 그 누구의 전화도, 메시지도 기다리지 않아도 되는 곳.
과거의 흔적이 없어 매일이 새로운 시작이 될 수 있는 곳.
내 이름을 부르는 목소리가 낯설게 들리는 곳.
그곳에서라면 비로소 내가 그동안 짊어졌던 기대와 책임, 관계의 무게를 내려놓고 진정한 나를 찾아갈 수 있을지도 모르겠습니다.
내 과거를 모르는 사람들 속에서, 내가 선택한 현재의 모습으로만 존재할 수 있는 자유.
어쩌면 그것이 제가 정말 찾고 있는 곳인지도 모릅니다.
그렇게 다시 질문을 곱씹게 됩니다.
나는 어디에서 살아야, 나로 살 수 있을까.
]]></description><link>https://w0nder.land/posts/20-%EC%96%B4%EB%94%94%EC%97%90%20%EC%82%B4%EA%B3%A0%20%EC%8B%B6%EC%9C%BC%EC%84%B8%EC%9A%94</link><guid isPermaLink="false">20</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sat, 10 May 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[콩트가 시작된다.]]></title><description><![CDATA[
요즘 일본 드라마 콩트가 시작된다를 매일 한 편씩 보고 있다. 인기 없는 개그맨 트리오와 두 자매가 겪는, 조용하지만 울림 있는 이야기다.
10년간 콩트를 해왔지만 끝내 뜨지 못하고 해체하는 개그맨들의 모습을 보며 여러 감정이 스쳤다. 무언가를 오래 붙잡고 있다가 결국 놓아야 할 때의 씁쓸함, 다시 일어설 수 있을지 모르는 막막함. 하지만 무엇보다 인상 깊었던 건, 그들이 그 모든 현실을 담담하게 받아들이는 태도였다.
그런데 이상하게도, 무대 위의 그들은 전혀 다르게 보였다. 무명의 고단함이 아니라, 자신들의 개그를 정말로 사랑하고 있다는 확신이 느껴졌다. 비록 웃음은 적었지만, 그들은 자기들이 재밌다고 믿으며 진심을 다해 공연을 하고 있었다.
나는 언제 마지막으로 "내가 잘하고 있다"고 믿어본 적이 있었던가? 오랫동안 스스로를 칭찬하기보다 채찍질하며 살아왔다. 그게 당연한 줄 알았다. 특히 C-Level로 일하면서부터는 성과가 곧 나였고, 그 외의 기준은 사치처럼 느껴졌다.
하루하루 평가받고, 실수는 용납되지 않으며, 다음 목표를 끊임없이 향해 달려야 하는 삶. 어느 순간부터 나는 내 본질보다 결과에 더 민감해졌고, 그 속에서 자기 확신은 점점 사라졌다. 대신 '잘해야 한다'는 강박만이 남았다.
하지만 드라마를 보며 조금 다른 생각이 들었다. 내가 저 인물들을 보며 '멋지다'고 느꼈다면, 나도 조금쯤은 그렇게 살아도 되지 않을까? 꼭 잘하지 않아도 괜찮다고, 지금 나에게 확신을 가져도 된다고 말이다.
안 되면 그때 가서 다시 고민해도 늦지 않다. 앞서 걱정하기보다, 오늘 내가 할 수 있는 것에 집중하는 것. 그렇게 자기 확신을 조금씩 회복해 나가고 싶다.
]]></description><link>https://w0nder.land/posts/19-%EC%BD%A9%ED%8A%B8%EA%B0%80%20%EC%8B%9C%EC%9E%91%EB%90%9C%EB%8B%A4.</link><guid isPermaLink="false">19</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Tue, 06 May 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[사이드킥 후기]]></title><description><![CDATA[월요일에 사이드킥 베타 기수를 마무리하는 책거리 모임을 열었다. 함께했던 참가자들과 후기를 나누는 자리로, 사무실 회의실에서 포트럭 파티를 진행했다. 혹시 참가자들이 음식을 가져오지 않을까 걱정되어 빵을 잔뜩 준비했는데, 우연히도 모두가 빵을 사 왔다. 덕분에 빵 파티가 되었지만, 다행히 한 분이 떡볶이와 순대를 준비해오셔서 모두의 칭찬을 받았다. 다음 모임에서는 김밥도 좋은 선택이 될 것 같다는 생각이 들었다.
사이드킥은 내가 처음으로 운영한 유료 프로그램이다. 정확히는 '교육'이라기보다, 디자이너와 개발자들이 사이드 프로젝트를 진행하는 과정에서 내가 나나산님과 함께 경험했던 시행착오를 나누고, 4주 동안 목표한 기능이나 제품을 출시할 수 있도록 가이드하고 지원하는 프로그램이다.
베타를 시작하며 가장 큰 걱정은 참가자들이 지불한 금액에 대한 가치를 느낄 수 있을지였다. "내 경험이 정말 도움이 될까?", "참가자들이 시간과 비용을 투자할 만한 가치를 느낄까?" 끊임없이 자문하며 부담감을 느꼈다. 유료 프로그램 운영은 처음이었기에, 더욱 강박에 가까운 책임감을 가졌다.
특히 4주라는 짧은 기간 안에 참가자들이 각자의 프로젝트를 의미 있게 발전시킬 수 있을지 의구심이 컸다. 하지만 프로그램이 진행되면서, 참가자들이 매주 세 번 이상 꾸준히 작업 인증을 올리는 모습을 보며 내 걱정이 기우였음을 깨달았다. 주간 미팅에서 한 참가자가 "채팅으로 쏟아지는 조언과 인사이트들, 각자의 프로덕트뿐만 아니라 서로의 프로덕트에도 관심을 가지는 분위기가 정말 좋았다"고 말해주었을 때는 마음이 뭉클했다.
모각작 운영 초기에는 작업에 집중하는 컨셉을 지향했지만, 흥미롭게도 참가자들은 오히려 서로 이야기하고 소통하는 시간을 더 원했다. 피드백에서도 "멤버들과의 소통이 좀 더 활발했으면 좋았을 것 같다"는 아쉬움이 있었다. "각자의 어려움과 고민을 좀 더 자유롭게 나눴다면, 심리적인 면에서도 큰 도움이 되었을 것"이라는 의견을 들으며 모각작의 방향성을 재고하게 되었다. 다음에는 네트워킹과 대화의 비중을 더 높여야겠다는 결심을 하게 되었다.
"주간 미팅이 있었기 때문에, '뭐라도 이야기할 수 있어야 한다'는 마음으로 한 주 동안 꾸준히 작업할 수 있었다", "아이디어 검증 단계를 막 지난 시점에 참여했는데, 기능 구현 단계로 바로 진입할 수 있는 추진력을 얻었다", "1년 넘게 묵혀두었던 아이디어의 첫 삽을 뜰 수 있게 도와주셔서 감사하다", "제품만 만들던 습관에서 벗어나 스스로를 되돌아볼 수 있었다"는 후기들이 큰 의미로 다가왔다.
오래전 회사에서 내가 만든 첫 기능을 출시했을 때와 비슷한 감정이었다. 다만 그때는 '내 제품'을 통한 만족감이었다면, 이번에는 '내가 만든 구조와 환경'을 통해 다른 사람들이 제품을 완성하는 과정을 지원했다는 점에서 다른 종류의 기쁨이었다. 나는 '좋은 제품을 만드는 것'만큼이나, '다른 사람들이 좋은 제품을 만들 수 있도록 돕는 것'에서도 큰 만족감을 느낄 수 있다는 사실을 깨달았다. 이 경험을 통해 '가이드'로서의 새로운 가능성을 발견했다. 직접 만드는 것이 아니라, 다른 사람들이 만들 수 있는 환경을 조성하고 지원하는 일에서 오는 기쁨은 내게 새로운 종류의 충족감을 주었다.
내가 운영하는 다른 스터디 모임은 참가자 이탈도 많고 운영이 잘 되지 않아 자신감을 잃기도 했지만, 사이드킥을 통해 다시 용기를 얻었다. 걱정이 많았던 초반에 비해, 미흡한 부분은 있었지만 대체로 잘 진행되었다. 무엇보다 참가자들이 보여준 꾸준한 성장과 만족스러운 후기는 나에게 다시 한번 확신을 주었다. 내가 만든 프로그램이 누군가에게 실질적인 도움이 되었다는 사실은 정말 특별한 느낌이었다.
이제 5월에 다시 참가자를 모집하고, 6월부터 정식 프로그램으로 이어가려 한다. 베타 경험을 바탕으로, 더 많은 사람들이 자신의 사이드 프로젝트를 지속 가능하게 이어갈 수 있도록 돕고 싶다.
]]></description><link>https://w0nder.land/posts/18-%EC%82%AC%EC%9D%B4%EB%93%9C%ED%82%A5%20%ED%9B%84%EA%B8%B0</link><guid isPermaLink="false">18</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 27 Apr 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[필사의 즐거움]]></title><description><![CDATA[

어린왕자 필사 모임에 참여했다. 여러 사람들이 모인 자리에서 운영자 분이 준비해 주신 어린왕자의 일부분을 함께 필사하는 시간이었다. 우리 여섯 명이 하나의 테이블에 둘러앉았다. 그 후 함께 보이차를 마시며 대추 간식을 먹는 편안한 시간을 가졌다. 보이차의 깊은 향과 대추의 달콤한 맛이 어우러져 참 맛있었다. 차를 마신 후에는 짧은 명상을 했다. 눈을 감고 호흡에 집중하는 5분간의 시간이었다. 명상이 끝난 후, 본격적인 필사를 시작했다. 우리에게 주어진 종이는 왼쪽에는 어린왕자의 문장들이, 오른쪽에는 글을 쓸 수 있는 줄이 있는 형태였다.
사실 나는 글씨를 쓰는 것을 좋아하지 않는다. 그리고 솔직히 말하자면, 악필이다. 초등학교 시절, 내 글씨체를 보신 부모님은 걱정스러운 목소리로 "그러다 나중에 이력서는 어떻게 쓰려고 그러니?"라고 물으셨다. 그때 나는 당차게 대답했다. "미래에는 컴퓨터로 할 거라서 글씨 못 써도 돼요." 어린 나이에 나름의 선견지명이 있었던 셈이다. 그리고 지금, 나는 정말로 컴퓨터로 밥을 먹고 살고 있다. 학창 시절을 제외하고는 펜을 쓸 일이 거의 없었다. 솔직히 학창 시절에도 최대한 잘 쓰지 않으려 했지만...
그러다 최근에 아침 일기, 이른바 '모닝페이지'를 시작하면서 손으로 글을 쓰는 행위에 조금씩 관심을 갖게 되었다. 그러다 보니 자연스럽게 필사에도 호기심이 생겼고, 주저 없이 이번 어린왕자 필사 모임에 신청했다.
모임에서 펜을 들고 글을 쓰기 시작했을 때, 나는 깨달았다. 시간이 지나도 내 악필은 자연적으로 고쳐지지 않았다는 것을. 어쩌면 더 나빠졌을지도 모르겠다. 컴퓨터 키보드만 두드리며 살아온 세월이 내 손글씨에 고스란히 드러나는 것 같았다.
필사에는 여러 목표가 있다고 한다. 마음을 비우거나, 좋은 글귀를 마음속에 새기거나, 글쓰기 연습을 하거나, 혹은 악필을 고치는 등 다양한 목적이 있을 수 있다. 나는 필사 내내 이런 목표들을 하나씩 시험해 보았다. 그러나 어떤 것도 내게 딱 맞는 느낌은 아니었다.
나는 MBTI에서 특히 N이 강한 편이다. 극대 N이라고 할 수 있을 정도로. 내 머릿속은 항상 생각으로 가득 차 있고, 현실보다는 가능성의 세계에 더 많이 머무른다.
망상을 잘하고, 또 그것을 즐긴다. 일상적인 사물을 보더라도 여러 갈래의 생각이 뻗어나가고, 어떤 단어 하나에도 수십 개의 이미지와 이야기가 연결된다. 내 머릿속은 끊임없이 분주하다. 버스 창밖으로 스치는 낯선 이의 표정에서 그의 하루를 상상하거나, 카페에서 우연히 들린 대화 조각으로 전체 서사를 구성한다. 특히 밤하늘의 별을 볼 때면 그 별에 살고 있을지 모르는 존재들의 일상을 그려보는 것이 취미다.
때로는 망상이 나를 힘들게 할 때도 있다. 걱정이 너무 깊어져 현실에서 발을 딛기 어려울 때, 지나친 상상이 불안으로 이어질 때가 그렇다. 하지만 전반적으로는 내 상상의 나래를 펼치는 것을 좋아한다. 현실의 제약에서 벗어나 자유롭게 날아다니는 그 느낌은 어떤 경험보다도 특별하다.
꿈꾸는 것도 특히 좋아한다. 아침에 일어나서 전날 꾼 꿈이 생생하게 기억난다면, 베개에 머리를 묻은 채 꿈속 장면들을 하나하나 되새김질하는 시간을 갖는다. 그 과정이 너무 즐겁다. 현실이면서 현실이 아닌, 혹은 현실과는 전혀 다른 차원의 이야기들이 펼쳐지는 것이 매력적이다. 특히 내 무의식이 만들어낸 세계라는 점, 그것도 내가 의도하지 않았는데 내 머리에서 저절로 창조되었다는 사실이 경이롭게 느껴진다. 꿈이 기억나는 날이면 하루를 시작하는 기분이 남다르다. 마치 한 권의 영화나 책을 혼자만 경험한 것 같은 특별함이 있다.
그렇게 나는 필사를 하면서 나만의 방식을 찾기로 했다. 바로 '망상을 즐기며 필사하기'. 어린왕자의 한 구절을 옮기면서 여러 생각을 펼치고, 그 생각이 또 다른 생각을 불러오고, 그렇게 사고가 저 멀리 날아갔다가 다시 돌아오는 여정을 즐기기로 했다.
어린왕자의 가장 유명한 첫 내용은 보아뱀에 관한 이야기다. 주인공이 어렸을 때 보아뱀이 코끼리를 삼키는 그림을 그렸지만, 어른들은 아무도 그것을 보아뱀으로 알아보지 못했다. 모두 모자로만 봤다는 이야기.
그 부분을 필사하면서 나는 망상을 시작했다. 내가 먹는 밥이 IT 분야인지라, 자연스럽게 UX/UI 디자이너들의 고민과 연결 지었다. UX/UI 디자이너들은 사용자들이 별다른 설명 없이도 인터페이스를 직관적으로 이해하기를 원한다. 그것이 잘 된 디자인의 기준이다. 그런 관점에서 보면, 어린왕자의 주인공인 조종사는 사실 잘못된 디자인을 한 셈이다. 보아뱀이 코끼리를 삼킨 그림을 보면 누구나 바로 알아볼 수 있게 표현했어야 했는데, 너무 추상적이고 직관적이지 않은 디자인을 했으니 말이다.
이런 식으로 필사를 하는 동안, 내 생각은 계속해서 여러 방향으로 뻗어나갔다. 때로는 어린 시절의 기억으로, 때로는 최근 읽은 책의 내용으로, 또 때로는 완전히 엉뚱한 상상의 나래로. 그리고 이런 망상의 시간이 의외로 즐거웠다. 필사라는 일견 단순하고 지루할 수 있는 행위가, 나에게는 풍요로운 상상의 시간이 되었다.
모임이 끝나고 집으로 돌아오는 길, 나는 필사에 대한 새로운 관점을 갖게 되었다. 필사는 단순히 글씨를 예쁘게 쓰거나 문장을 암기하는 행위가 아니라, 자신만의 방식으로 글과 교감하는 시간일 수 있다는 것을. 어쩌면 내 악필은 앞으로도 고쳐지지 않을지 모른다. 하지만 그것이 필사의 즐거움을 방해하지는 않을 것이다.
앞으로도 나는 가끔씩 좋은 책의 일부를 필사하며 나만의 망상 여행을 떠날 생각이다. 이번 어린왕자 필사 모임은 내게 새로운 취미와 자기 표현의 방식을 선물해 주었다. 악필임에도 불구하고, 아니 어쩌면 그 악필이 오히려 나를 글씨의 완벽함에서 해방시켜 더 자유롭게 상상의 세계로 빠져들 수 있게 했는지도 모른다.
어린왕자가 말했듯이, "가장 중요한 것은 눈에 보이지 않는다." 필사의 진정한 가치는 완벽한 글씨나 외적인 결과물이 아니라, 그 과정에서 펼쳐지는 자유로운 사고의 여행과 자신만의 내면의 목소리를 발견하는 데 있지 않을까. 결국 중요한 건 남들이 정해놓은 방식이 아닌, 자신만의 고유한 즐거움을 찾는 것이니까.
]]></description><link>https://w0nder.land/posts/17-%ED%95%84%EC%82%AC%EC%9D%98%20%EC%A6%90%EA%B1%B0%EC%9B%80</link><guid isPermaLink="false">17</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 17 Apr 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[거절의 미학]]></title><description><![CDATA[거절은 우리 삶의 일부분이다. 출근길 지하철 출구에서 건네받는 전단지를 거절하는 사소한 순간부터 인생의 중대한 갈림길에서 내리는 결정까지, 우리는 매일 선택과 거절의 순간을 마주한다.
인생을 살다 보면 크고 작은 부탁을 받게 마련이다. 처음 만난 사이나 특별한 연이 없는 관계에서는 "죄송합니다만, 어렵겠네요"라는 짧은 말로 거절이 끝나기도 한다. 그러나 진정 어려운 것은 이미 깊은 관계가 형성되고, 서로 주고받은 것이 많은 사이에서의 거절이다.
나는 본질적으로 거절이 어려운 사람이다. 누군가 도움을 청하면 대부분 "그럼요, 제가 해볼게요"라고 응답한다. 이 짧은 한마디를 내뱉을 때마다 일시적인 안도감과 묘한 죄책감이 함께 찾아온다. 상대방의 기대에 부응했다는 안도감과 동시에 내 진정한 마음을 숨겼다는 죄책감이 뒤섞여 복잡한 감정을 만들어낸다.
거절해야 할 상황에서도 그러지 못하는 자신을 보며 분노가 치밀어 오르기도 한다. "왜 또 그랬어?" 집에 돌아와 홀로 남겨졌을 때 자책하는 목소리가 머릿속을 맴돈다. 그러나 다음에도 나는 같은 실수를 반복한다. 마치 '거절'이라는 단어가 내 어휘에서 완전히 지워진 것처럼.
머리로는 즉시 거절해야 한다는 것을 알지만, 가슴은 그렇지 않다. 특히 그 사람에게 도움을 받은 적이 있거나 관계가 소중하다면 더욱 그렇다. "내가 거절하면 우리 관계가 어색해질까?", "그동안 그가 나를 도와준 것들에 비하면 이 정도는 해줘야 하지 않을까?" 이런 생각들이 결정을 더욱 어렵게 만든다.
거절에는 두 가지 측면이 있다. 하나는 상대방의 기대를 저버린다는 부담감이고, 다른 하나는 자신의 경계를 보호해야 한다는 필요성이다. 지금까지 나는 전자에 압도되어 후자를 무시해왔다. 그 결과는 번아웃, 후회, 그리고 분노로 이어졌다. 상대방을 실망시키지 않으려는 마음이 결국 나 자신을 실망시키는 결과를 낳았던 것이다.
최근에 거절해야 할 상황이 생겼다. 오랜 시간 알고 지낸 사람이고, 많은 도움을 받기도 했다. 거절해야 한다는 것을 알면서도, 아직 그 말을 꺼내지 못했다. 며칠이 지났지만, 여전히 거절하지 못한 채 밤마다 잠들기 전 이 상황에 대한 생각으로 뒤척인다. 불안감이 가슴을 짓누르고, 심장은 빠르게 뛴다.
때로는 새벽 세 시에 잠에서 깨어 천장을 바라보며 거절했을 때의 상황을 끝없이 상상한다. 대부분 "넌 배은망덕한 놈이야"라는 비난, 우정의 파괴, 그리고 함께 가기로 한 행사에서의 어색한 순간들과 같은 부정적인 방향으로만 생각이 흘러간다.
매일 아침 눈을 뜨면 가슴에 무거운 돌덩이를 얹은 듯한 느낌이 든다. 목이 메이고, 식욕이 사라진다. 어떻게 거절의 말을 꺼내야 할지, 어떤 단어를 사용해야 상대방의 기분을 덜 상하게 할지 끝없이 고민하며 시간만 흘려보내고 있다.
살면서 우리는 끊임없이 선택해야 한다. 그리고 어떤 선택은 필연적으로 거절을 포함한다. 거절하는 방법에 대해 이론적으로는 많이 알고 있지만, 실제로 그 말이 입에서 나오지 않을 때가 많다. 마음속에는 이미 거절의 문장이 완성되어 있어도, 그것을 실제로 말하는 순간 모든 것이 무너질 것 같은 두려움이 엄습한다.
오늘 아침, 거울 앞에서 연습했다. "정말 미안해. 너와 함께하면 좋겠지만, 지금은 어려워." 단순한 문장인데도 목소리가 떨렸다. 거절하는 나 자신이 미워서, 상대방에게 상처를 줄 수밖에 없는 상황이 원망스러워서 생기는 감정들이다. 무언가를 거절한다는 것은 단순히 '아니오'라고 말하는 것이 아니라, 내 인간성과 존재 가치에 대한 의문까지 불러일으키는 복잡한 행위처럼 느껴진다.
결국 거절은 내가 피할 수 없는 삶의 과제다. 오늘도 나는 그 말을 하지 못했고, 내일도 어쩌면 같은 실패를 반복할지 모른다. 그럼에도 불구하고 나는 알고 있다. 영원히 '예스'만 말하며 살 수는 없다는 것을. 언젠가는 그 무거운 '아니오'를 꺼내야만 한다는 것을.
거절의 미학이란 아마도 완벽한 거절을 하는 것이 아니라, 불완전하고 어설프더라도 끊임없이 자신의 경계를 지키려 노력하는 과정에 있는 것인지도 모른다. 오늘 밤에도 나는 천장을 바라보며 내일의 거절을 연습할 것이다. 그리고 언젠가, 이 고통스러운 연습이 조금은 덜 아프기를 바랄 뿐이다.
]]></description><link>https://w0nder.land/posts/16-%EA%B1%B0%EC%A0%88%EC%9D%98%20%EB%AF%B8%ED%95%99</link><guid isPermaLink="false">16</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 13 Apr 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[모닝페이지, 나를 만나는 시간]]></title><description><![CDATA[올해 초부터 시작한 '모닝페이지'가 어느덧 일상이 되었다. 처음에는 단순한 글쓰기 챌린지였지만, 지금은 삶에 고요한 안정감을 더하는 소중한 습관으로 자리 잡았다.
2025년 1월, 새해 첫날부터 모닝페이지 챌린지에 참여했다. 사실 나는 일기와는 거리가 먼 사람이었다.
초등학교 때 방학숙제로 억지로 썼던 일기가 전부였을 정도로, 내 생각과 감정을 솔직하게 적는다는 것, 그것도 매일 아침마다 하는 것은 상상할 수 없었다.
나는 근본적으로 솔직하지 못한 사람이었다. 일기라는 게 물론 비공개이고 남에게 보여질 일이 거의 없지만, 그래도 어딘가에 적어둔다는 행위가 내 내면의 생각과 감정을 까발리는 것 같은 느낌이 강했다.
살면서 나를 밖으로 보여주는 행위는 단순히 옷을 뒤집어 입는 것보다 더 큰 파장을 일으킬 거라는 두려움이 있었다. 이 두려움은 오랫동안 나를 지배했고, 그래서 뭔가를 기록한다는 것 자체가 나에게는 거대한 산과 같은 도전이었다.
첫날 아침, 아이패드를 꺼내 빈 페이지를 마주했을 때 무엇을 써야 할지 몰라 한참을 화면만 바라봤다. 결국 '어제 무슨 일이 있었지?'라는 단순한 질문으로 시작해 전날의 일과 감정들을 적기 시작했다.
한 번 글을 쓰기 시작하자 뜻밖에도 생각보다 많은 이야기가 흘러나왔다. 성격상 주로 후회나 걱정, 고민들이 많이 나왔다. 처음에는 부정적인 감정들을 기록하는 게 망설여지기도 했다. 상처를 다시 들여다보는 것 같은 느낌이었다.
그런데 의외로 걱정들을 계속 써내려가다 보니 마음이 가벼워지는 것을 느꼈다. 고민들을 객관적으로 바라보게 되었고, 그것들이 생각만큼 큰 문제가 아니라는 것을 깨달았다.
머릿속의 복잡한 실타래가 하나씩 풀리는 느낌이었다. 이 과정에서 나는 글쓰기를 통해 내면의 무질서를 정리하는 도구가 될 수 있음을 경험했다.
매일의 글쓰기는 마치 내 마음속 흩어진 퍼즐 조각들을 하나씩 제자리에 맞추는 작업 같았다. 모닝페이지를 쓰고 나면 마음이 놀랍도록 차분해졌다.
자연스럽게 글을 쓴 후 일을 시작하게 되었는데, 이전보다 훨씬 집중력 있게 하루를 시작할 수 있었다. 아침부터 정신없이 서두르던 예전과는 다르게, 마음의 속도를 조절하고 일에 임할 수 있게 되었다.
처음에는 '챌린지니까'라는 의무감으로 시작했지만, 점점 모닝페이지는 하루를 시작하는 자연스러운 의식이 되어갔다. 주말에도, 여행 중에도 빼먹지 않고 글을 썼다.
꾸준히 이어가다 보니 어느 순간부터는 모닝페이지 없이 하루를 시작하는 것이 어색하게 느껴졌다. 가장 놀라웠던 것은 2개월간의 챌린지가 끝난 후에도 자연스럽게 계속 글을 쓰고 있는 자신을 발견한 것이었다.
이제는 삶의 당연한 일부가 되었다.
특히 깨달은 점은 글쓰기라는 행위 자체가 지닌 독특한 마법이다. 생각을 글로 옮기는 순간, 모든 것이 하나의 의식처럼 느껴졌다.
머릿속에서 무질서하게 떠돌던 생각들이 글자로 형태를 갖추면서 내 생각과 감정이 물리적으로 세상에 존재하게 되는 경이로운 순간이었다.
흐릿했던 내면의 풍경이 선명한 윤곽을 드러냈고, 그것을 바라보는 나만의 시선이 생겼다.
글쓰기는 나에게 고유한 정신적 공간을 열어주었다. 아침의 고요 속에서 오직 나와 글자만이 존재하는 시간.
그 시간 동안 세상의 소음은 잠시 멈추고, 온전히 나에게 집중할 수 있었다.
때로는 예상치 못한 통찰이 번개처럼 찾아왔고, 때로는 오랫동안 풀리지 않던 문제의 실마리가 글을 쓰는 과정에서 자연스럽게 모습을 드러냈다.
이런 순간들이 쌓여 나는 조금씩 더 선명한 사람으로 변해갔다.
챌린지를 주도했던 분에 대한 감사함이 크다. 그분에게서 느껴진 긍정적이고 멋진 에너지와 흔들리지 않는 강한 내면이 인상적이었다.
물론 이는 단지 외적으로 바라본 나의 시선일 뿐, 실제 그분의 내면이 어떠한지는 알 수 없다. 하지만 그 짧은 만남에서 받은 인상과 느낌은 나에게 깊은 울림을 주었다.
그분은 글쓰기를 사랑하는 분이었다. 글쓰기 관련 물건들을 판매하고, 다양한 글쓰기 프로그램들을 열정적으로 진행했다.
아마도 모닝페이지를 통해 내가 느낀 것처럼, 그분도 자신이 경험한 글쓰기의 가치를 다른 사람들과 나누고 함께 향유하고 싶은 아름다운 마음으로 이런 활동들을 계속했을 것이다.
오늘도 모닝페이지와 함께 평화로운 아침을 시작한다. 📝✨
]]></description><link>https://w0nder.land/posts/15-%EB%AA%A8%EB%8B%9D%ED%8E%98%EC%9D%B4%EC%A7%80%2C%20%EB%82%98%EB%A5%BC%20%EB%A7%8C%EB%82%98%EB%8A%94%20%EC%8B%9C%EA%B0%84</link><guid isPermaLink="false">15</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Fri, 07 Mar 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[커피챗 1년 후기]]></title><description><![CDATA[

나는 왜 커피챗을 시작했나
Show Your Time 앱을 만들면서 깨달은 것이 있었다. 앱이 성공하려면 좋은 채널이 필요하고, 그 채널에는 내 브랜딩이 필요했다. 그래야 지금의 앱뿐만 아니라 앞으로 만들 다른 서비스들도 잘 전파될 수 있을 것 같았다. 그러던 중 커피챗이라는 것을 알게 되었다.
비전공자로서 내 경험이 누군가에게 도움이 될 수 있다면, 그것이 하나의 브랜딩이 될 수 있겠다고 생각했다. 나는 개발자가 될 생각도 없이 지원한 공채에서 우연히 개발팀에 배정받으면서 처음으로 개발을 접하게 되었다. 주변에 컴퓨터 전공 친구나 선배도 전혀 없었고, 회사 동료들에게 기초적인 것들을 물어보기도 민망해서 정말 막막했다. 어떻게 공부해야 할지, 커리어를 어떻게 만들어가야 할지, 어떤 행사에 참여해야 하는지 알기 어려웠다. 그래서 멀리 돌아가기도 하고 실패도 겪었다.
개발은 진입장벽이 낮은 직군이다 보니, 지금도 비슷한 어려움을 겪는 사람들이 많을 것이라 생각했다. 그들에게 도움이 되고 싶었다. 그렇게 커피챗을 시작하게 되었다.
첫 만남에서 받은 용기
첫 커피챗은 예상과 달랐다. 트위터에서 만난 주니어 백엔드 개발자였는데, 오히려 내가 더 많은 도움을 받았다. 이미 실력 있는 개발자였고, 그분과의 대화를 통해 커피챗의 매력을 알게 되었다. 원래 새로운 것을 시작하기 전에 이런저런 걱정이 많은 성격인데, 첫 커피챗 이후로는 그런 걱정이 사라졌다. 일종의 용기를 얻은 셈이다.
1년간의 여정
1년 동안 약 80명의 개발자들과 만났다. 주니어부터 나와 비슷한 연차까지, 다양한 배경의 개발자들이었다. 흥미로웠던 점은 각자의 고민이 달랐지만, 비슷한 맥락과 패턴이 있었다는 것이다.
약속은 1시간으로 잡았지만 대부분 2시간씩 이야기를 나눴다. 더 들려주고 싶은 이야기도 있었고, 더 들어줘야 할 이야기도 있었다. 나는 비언어적 소통을 중요하게 생각해서 되도록 오프라인 만남을 선호했지만, 온라인을 선호하는 분들과는 온라인으로 만났다.
이력서에 숨겨진 이야기들
대부분의 커피챗에서 이력서 첨삭을 했는데, 거기서 흥미로운 패턴을 발견했다. 다들 좋은 경험을 했음에도 그것을 이력서에 제대로 표현하지 못하고 있었다. "이 프로젝트 하면서 이런 건 안 해보셨나요?", "저런 시도는 어땠나요?" 하고 물어보면 훨씬 더 풍성한 경험들이 나왔다. 매력적으로 보일 수 있는 경험들이 누락된 경우가 많았다.
소통 방식의 변화
커피챗을 거듭하면서 소통 방식도 발전했다. 처음에는 일방적인 조언 위주였다면, 점차 상대방의 이야기를 더 깊이 듣고 그들의 관점에서 생각해보는 방식으로 변화했다. 특히 피드백 스타일에 대한 선호도가 사람마다 매우 다르다는 걸 알게 되었다.
어떤 사람들은 '돌려 말하지 말고 직설적으로 말해주세요'라며 현실을 있는 그대로 듣고 싶어했고, 또 어떤 사람들은 부드러운 표현을 선호했다. 그래서 초반 대화를 나누면서 자연스럽게 상대방의 성향을 파악하려 노력했다. 날씨나 카페 분위기 같은 가벼운 주제로 시작해서, 개발을 시작하게 된 계기나 현재 하고 있는 일에 대한 이야기를 나누다 보면 그 사람의 성향이나 선호하는 대화 방식을 알 수 있었다.
참가자들의 이야기
1년 동안 많은 피드백을 받았다. 이력서 작성법부터 커리어 방향성까지, 다양한 주제로 대화를 나눴다. 참가자들이 남긴 후기를 보면 커피챗이 어떤 영향을 주었는지 알 수 있다:

제 경력 자체에 대한 불신을 스스로 극복하고, 매몰되어 있던 스스로의 자신 없는 모습에서 벗어날 수 있었습니다. 현재의 제 모습을 인정하고 개선점을 보완해 나갈 수 있는 첫 걸음의 기회를 열어 주셔서 감사합니다!


질문드렸던 내용에 진심으로 고민해서 경험을 나눠주셨던 내용이, 제가 한 곳에서 직장생활을 오래 하며 편협해졌던 사고를 오랜만에 처음 일 시작할 때처럼 트이게 하는 계기가 되었습니다!

이력서와 포트폴리오에 대해서도 구체적인 피드백이 있었다:

전반적으로 이력서와 포트폴리오를 차근차근 점검하듯이 피드백해주셔서 좋았습니다. 어떠한 방향으로 흘러가야 하는지에 대해서도 명확하게 예시를 들어주시면서 설명해주셔서 정말 도움이 많이 됐습니다!


이력서를 통하여 제가 어떻게 보일지 깊게 생각해보지 못하였는데 나란 사람을 어떻게 showing할 수 있는 지에 대한 고민을 해보게 되었습니다.


깃 레파지토리의 코드들까지 꼼꼼하게 확인해주시고 피드백해주셨던 점이 가장 기억에 남고 세심하신 것 같아 인상 깊었습니다.

그리고 가장 기억에 남는 후기들:

이번 커피챗 과정에서 사이드프로젝트에 대한 어려움도 문의드렸는데, 답답했던 부분에 대한 실마리를 찾을 수 있게 되어서 무척 좋았습니다. 다른 분들도 솔직하게 생각을 이야기하고 편하게 대화를 나눈다면 분명 커피값의 수십, 수백배의 가치를 얻어가는 커피챗이 될거라고 생각합니다 :) 감사합니다!


너무 친절하게 진심을 담아 미래를 멘토링해주셔서 저의 미래를 그려보는 데 너무나도 큰 도움이 되었습니다. 미래에 꼭 이런 선순환의 일부에 동참하고 싶다는 생각이 들었습니다 :)

이런 후기들을 들을 때마다, 내가 받았던 도움을 다시 다른 사람에게 전달하고 싶었던 초심이 떠올랐다. 그리고 그 마음이 옳았다는 확신을 갖게 되었다.
앞으로의 방향
1년간의 커피챗은 나에게도 큰 배움의 시간이었다. 각자의 고민을 듣고, 해결책을 함께 찾아가는 과정에서 나도 성장했다. 때로는 내 조언이 부족할 때도 있었고, 더 깊이 있는 대화를 나누지 못해 아쉬울 때도 있었다. 하지만 그런 순간들도 모두 의미 있는 경험이었다.
앞으로도 커피챗을 계속할 것이다. 더 많은 개발자들과 만나고, 더 다양한 이야기를 나누고 싶다. 그들의 고민에 귀 기울이고, 내 경험을 나누며, 함께 성장해나가고 싶다. 누군가에게는 위로가 되고, 누군가에게는 동기부여가 되며, 또 누군가에게는 구체적인 방향을 제시해줄 수 있는 사람이 되고 싶다.

]]></description><link>https://w0nder.land/posts/14-%EC%BB%A4%ED%94%BC%EC%B1%97%201%EB%85%84%20%ED%9B%84%EA%B8%B0</link><guid isPermaLink="false">14</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 16 Feb 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[좋은건 팔린다는 안일한 생각은 버려라]]></title><description><![CDATA[

'라면요리왕'. 이 만화는 단순한 요리 만화가 아닌, 비즈니스 통찰을 담은 작품이었다. 개발자 시절에는 그저 재미있는 라면 만화로만 보였던 것이, 이제는 비즈니스적 교훈을 전하는 작품으로 다가온다.
실제로 IT 업계와 요식업계는 놀랍도록 많은 공통점을 가지고 있다. 인력 구성부터 운영 방식, 비즈니스 접근법, 그리고 규모에 따라 달라지는 전략까지, 두 산업의 유사성은 놀랍다. 그래서 나는 종종 IT 업계가 요식업과 비슷하다고 이야기하곤 한다.

순진하긴
이 대화는 만화 '라면요리왕'에 나오는 한 장면이다. 좋은 음식 하나만으로도 성공할 수 있다고 믿는 젊은 요리사와, 비즈니스의 냉정한 현실을 이해하는 노련한 사업가의 대비가 인상적이다.
IT 업계에서 일하다 보면, 이런 대화가 낯설지 않다. 우리 역시 '완벽한 코드', '뛰어난 디자인'만 있으면 시장에서 자연스럽게 성공할 것이라 믿었던 순진한 시절이 있었다. 사용자들이 우리의 뛰어난 제품을 알아보고 자연스럽게 찾아와 줄 것이라 기대했고, 그들이 제품의 가치를 이해하고 이탈하지 않을 것이라 믿었다.
장인정신의 함정: '좋은 것'에 대한 착각

그냥 무난하네
실제로 많은 개발자와 디자이너들이 이런 착각에 빠진다. 좋은 코드, 아름다운 디자인, 세세한 UX 설계 등이 자연스럽게 사용자들에게 인정받을 것이라 기대한다. 하지만 현실은 다르다.
사용자들은 우리가 생각하는 '좋음'의 기준과 전혀 다른 관점을 가지고 있을 수 있다. 기술적으로 뛰어나거나 디자인적으로 완벽한 제품이 시장에서 실패하는 경우가 허다한 것도 이 때문이다.
나 역시 개발자 시절에는 이런 생각을 했었다. 좋은 제품만 만들면 성공은 자연스럽게 따라올 거라고. 팀장이 되어서도 한동안은 다른 경영진들이 제품의 본질을 이해하지 못한다고 생각했다.
하지만 점차 비즈니스를 경험하고 C 레벨이 되면서 제품을 바라보는 시각이 완전히 달라졌다.
진정한 성공을 위한 균형

좋은건 팔린다는 안일한 생각은 버려라
결국 비즈니스의 성공은 제품의 퀄리티와 비즈니스 전략 사이의 균형에서 온다. 뛰어난 제품은 필요조건이지만, 우리에게 주어진 시간과 자원은 한정되어 있다. 모든 것을 제품 완성도에만 쏟을 수는 없다. 시간은 곧 비용이며, 성공적인 비즈니스를 위해서는 다양한 영역에 적절한 시간과 자원을 분배해야 한다.

대부분의 경우, 좋은 것이라도 효과적인 어필이 동반되지 않으면 인정받지 못 해요
제품의 완성도만을 추구하다 보면 더 중요한 현실을 놓치기 쉽다. '뛰어난 제품은 반드시 성공한다'는 환상에 사로잡혀 지나친 디테일에 매몰되는 동안, 우리는 더 큰 기회를 놓치고 있을지도 모른다.
뛰어난 제품이라 하더라도 시장에서 제대로 된 포지셔닝이 없다면, 고객의 신뢰를 얻지 못한다면, 제품의 가치를 제대로 전달하지 못한다면 성공할 수 없다.
진정한 성공을 위해서는 뛰어난 제품력은 물론, 다양한 영역에 대한 이해와 투자가 필수적이다. 시장에서의 차별화 전략, 고객과의 신뢰 구축 방안, 지속 가능한 비즈니스 모델 수립 등 제품 외적인 요소들에도 동등한 노력을 기울여야 한다.
그러니 이제는 제품의 완성도에 대한 집착을 조금 내려두고, 우리의 시선을 다른 곳으로도 돌려보면 어떨까.
비즈니스의 다양한 측면들에 시간을 투자하다 보면, 우리가 미처 보지 못했던 새로운 기회들이 기다리고 있을지도 모른다.
]]></description><link>https://w0nder.land/posts/13-%EC%A2%8B%EC%9D%80%EA%B1%B4%20%ED%8C%94%EB%A6%B0%EB%8B%A4%EB%8A%94%20%EC%95%88%EC%9D%BC%ED%95%9C%20%EC%83%9D%EA%B0%81%EC%9D%80%20%EB%B2%84%EB%A0%A4%EB%9D%BC</link><guid isPermaLink="false">13</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sat, 15 Feb 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[창백한 푸른 점 위에서]]></title><description><![CDATA[

어제 SNS에 개발 관련 정보를 공유했다. 누군가에게 도움이 될까 하는 마음으로 시작한 일이었는데, 예상치 못한 댓글들이 달렸다.
글의 본질과는 전혀 관계없는 부분을 지적하고, 심지어는 조롱하는 듯한 반응들. '이런 걸로 태클 거는 사람들은 대체 뭐지?' 순간 짜증이 확 올라왔다.
키보드를 잡고 반박글을 쓰려다가 문득 멈췄다. '내가 너무 까칠한가?' 그리고 떠올랐다. 어제 만난 그분이.
어제 참석한 모임에서 만난 분은 늘 평온해 보였다. 그분의 모든 행동에는 따뜻한 배려가 묻어났다. 무심코 하시는 행동에서도 타인을 향한 세심한 마음이 느껴졌다.
처음에는 그저 성격이 좋으신가보다 했는데, 이야기를 나누다 보니 깨달았다. 그건 타고난 성격이 아니었다. 매일매일 살아가는 순간들을 소중히 여기면서 자연스럽게 배워온 거였다는 걸.
최근에 코스모스를 다시 읽었다. 10년 전 처음 읽었을 때와는 완전히 다른 감상이 들었다. 은하수를 바라보며 드는 생각이 달라졌다.
이 광활한 우주에서 우리의 다툼은 얼마나 작은 일일까. 수많은 별들 사이에서 우리는 모두 한 점 빛일 뿐인데, 서로 '내 것, 네 것' 따지며 아둥바둥대는 게 무슨 의미가 있을까.
우주에서 바라본 지구는 창백한 푸른 점에 불과하다. 그 작은 점 위에서 우리는 때로는 사소한 것들로 다투고, 상처받고, 화를 내곤 한다.
하지만 그 모든 것이 얼마나 덧없는 것일까. 지금 이 순간, 우리가 함께 숨 쉬고 있다는 사실 자체에 감사하고, 서로를 이해하고 배려하는 게 더 중요하지 않을까.
그래서 오늘은 조금 다르게 해보기로 했다. 그 댓글들에 화를 내는 대신, 가볍게 웃으며 "제 키보드가 망가져서요 ㅋ"라고 답글을 달았다.
누군가는 이해할 수도, 또 이해하지 못할 수도 있다. 하지만 그건 중요하지 않다.
삶의 충만함은 결국 현재에 충실한 것 같다. 그동안은 늘 '손해 보는 게 아닐까' 하는 생각이 따라다녔다.
누군가 내 마음을 이용하지 않을까, 내가 너무 많이 베풀고 있는 건 아닐까. 하지만 이제는 그런 계산들이 무의미하게 느껴진다.
조금 손해 보면 어떤가. 그게 결국 나를 더 풍요롭게 만들어주는 것일 텐데.
모든 순간을 온전히 받아들이고, 지금 이 자리에서 만나는 모든 이들을 진심으로 대하는 것. 그리고 때로는 그냥 웃어넘길 줄 아는 것.
앞으로도 수많은 까다로운 상황들을 마주하겠지만, 이제는 조금 다르게 바라보려 한다.
어제 만난 그분처럼, 나도 언젠가는 모든 순간을 더 깊이 이해하고 더 따뜻하게 품을 수 있지 않을까?
이 광활한 우주에서 우리는 너무나 작은 존재들이기에, 서로를 더 이해하고 아끼며 살아가야 하지 않을까.
그래서 오늘도, 이 작은 별 위에서 만나는 모든 순간들을 소중히 여기며 살아가려 한다. 조금 더 너그럽게, 조금 더 따뜻하게.
]]></description><link>https://w0nder.land/posts/12-%EC%B0%BD%EB%B0%B1%ED%95%9C%20%ED%91%B8%EB%A5%B8%20%EC%A0%90%20%EC%9C%84%EC%97%90%EC%84%9C</link><guid isPermaLink="false">12</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 09 Feb 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[그 많던 사이드 프로젝트는 다 어디로 갔을까]]></title><description><![CDATA[

개발자라면 한 번쯤 사이드 프로젝트를 시작해봤을 것입니다. 그러나 대부분의 프로젝트는 절반도 완성하지 못한 채 GitHub의 저장소에서 잠들어 있죠. 이번 글에서는 사이드 프로젝트가 실패하는 이유와, 이를 성공으로 이끄는 방법에 대해 이야기해보려 합니다.
개발자들이 사이드 프로젝트를 시작하는 이유는 매우 다양합니다. 이력서에 추가할 멋진 프로젝트가 필요해서 시작하는 경우가 있고, 수익성 있는 서비스를 만들어 부수입을 얻고 싶어 하는 경우도 있습니다. 때로는 자신에게 정말 필요한 기능이나 서비스가 없어서 직접 만들기도 하죠. 개발자는 문제 해결사이기 때문입니다. 새로운 기술을 배웠다면 실제 프로젝트에 적용해보고 싶은 것이 개발자의 본능이기도 하고, 때로는 순수한 흥미와 호기심에서 시작하는 것이 가장 큰 동기가 되기도 합니다.
제가 경험하고 관찰한 바로는, 사이드 프로젝트가 실패하는 주요 원인들이 있습니다. "이것만 더! 저것도 필요할 것 같은데..."라며 끝없이 기능을 추가하다 지치게 되는 과도한 MVP(Minimum Viable Product) 기획이 첫 번째입니다. 두 번째로는 팀원 간 의사소통 부재로, 초기의 열정이 식으면서 점점 연락이 뜸해지고 결국 프로젝트는 중단됩니다. 당장 필요하지 않은 기능에 시간을 쏟다가 정작 중요한 부분을 놓치는 잘못된 우선순위 설정도 큰 문제입니다. 완벽을 추구하다 보니 한 단계를 진행하는 데 너무 많은 시간이 소요되는 느린 실행 속도, 사용자 의견을 듣지 않고 개발자 혼자만의 생각으로 개발을 진행하는 피드백 부족, 그리고 초기의 열정이 식어들면서 프로젝트에 투자하는 시간이 점점 줄어드는 동기부여 실패도 주요 원인입니다.
이런 실패 패턴을 살펴보면 한 가지 재미있는 사실을 발견할 수 있습니다. 이는 스타트업이 실패하는 이유와 놀랍도록 비슷합니다. "내가 평소에 스타트업 대표들을 비판했던 그 행동들을 내가 그대로 하고 있었네..."
사이드 프로젝트와 스타트업의 유사성을 발견했다면, 스타트업의 성공 방정식을 적용해보는 것은 어떨까요? 성공적인 스타트업들은 완벽한 계획보다는 작은 시도를 반복하며 개선해 나가고, 내가 좋아하는 것이 아닌 사용자가 원하는 것을 만들며, 제한된 자원을 효율적으로 사용하고 불필요한 요소를 과감히 제거합니다. 또한 어려움이 있어도 포기하지 않고 목표를 향해 나아갑니다.
특히 '낭비 최소화'는 사이드 프로젝트에서 매우 중요합니다. 우리에게는 시간과 에너지가 제한되어 있기 때문입니다. 낭비를 최소화한다는 것은 자원을 효율적으로 사용하고, 불필요한 요소를 제거하는 것입니다. 이것이 바로 MVP의 핵심이기도 합니다. 작게 시작하여 처음부터 모든 기능을 완성하려는 욕심을 버리고, 피드백을 빠르게 받아 잘못된 방향으로의 추가 개발을 방지하며, 기존에 사용 가능한 도구나 라이브러리를 적극 활용해 시간과 노력을 절약해야 합니다.

Show Your Time 첫 번째 스탭
'MVP 중의 MVP'로 시작하는 것이 중요합니다. 크게 상상하되 작게 시작하고, UI나 UX는 완벽하지 않아도 되며, 피드백을 받으려면 동작하는 최소한의 무언가가 필요합니다. 저는 'Show Your Time'이라는 앱을 개발하며 이러한 접근 방식의 효과를 직접 경험했습니다. 처음에는 정말 기본적인 기능만 있는 앱을 만들었습니다. 디자인은 투박했고, 기능도 제한적이었지만, 사용자들에게 보여주고 피드백을 받을 수 있는 상태였죠.

Show Your Time 두 번째 스탭
MVP를 만든 후에는 작업의 리듬이 중요합니다. 작업 간 핑퐁이 주단위로 이루어져야 하며, 2주 이상 소식이 없으면 프로젝트의 동력이 급격히 떨어집니다. 디자인과 개발이 동시에 진행되고, 주기적인 배포가 가능해야 합니다. 한 사람이 막히면 전체가 막히는 상황은 피해야 하죠. 작업 텀이 길어질수록 팀원 간 연결이 끊기고, 프로젝트는 방치되기 쉽습니다. 짧은 주기의 성과가 동기부여를 만듭니다.
지속성의 핵심 동력은 바로 흥미입니다. 내가 진짜로 하고 싶은 것을 선택해야 하며, "요즘 뜨니까 해볼까?"가 아니라 내가 즐길 수 있는 것이 무엇인지 고민해야 합니다. 흥미를 잃으면 오래 지속하기 어렵기 때문에, 처음부터 진심으로 즐길 수 있는 주제를 선택하는 것이 중요합니다.
Show Your Time 앱은 이러한 원칙들을 실제로 적용한 좋은 사례입니다. 본질적인 기능만을 가진 MVP로 시작해 지속적으로 개선해 나갔죠. 자세한 내용은 INTJ와 INTJ가 2주 만에 만든 Show Your Time 앱 제작기에서 확인할 수 있습니다.


사이드 프로젝트는 단순히 시간이 남아서 하는 일이 아닙니다. 그것은 우리의 열정과 가능성을 실현하는 기회입니다. 완벽한 계획이나 거창한 시작이 아니라, 작지만 의미 있는 첫걸음을 내딛는 것이 중요합니다. 오늘부터 작은 아이디어라도 바로 실행에 옮겨 보세요. 그리고 그 과정에서 실패를 두려워하지 말고 계속 나아가세요. 여러분의 GitHub에는 잠든 프로젝트가 아니라 세상을 바꿀 무언가가 자리 잡을 것입니다. 지금 바로 시작해보세요.
]]></description><link>https://w0nder.land/posts/11-%EA%B7%B8%20%EB%A7%8E%EB%8D%98%20%EC%82%AC%EC%9D%B4%EB%93%9C%20%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EB%8A%94%20%EB%8B%A4%20%EC%96%B4%EB%94%94%EB%A1%9C%20%EA%B0%94%EC%9D%84%EA%B9%8C</link><guid isPermaLink="false">11</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sat, 25 Jan 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[AI 시대의 역설: 두려움과 희망 사이에서]]></title><description><![CDATA[1. AI 공포 마케팅의 현주소
많은 매체와 기업들이 AI에 대한 불안감을 상업적으로 활용하고 있다. "AI가 당신의 일자리를 빼앗을 것이다", "지금 당장 AI를 배우지 않으면 뒤처진다"와 같은 문구들이 넘쳐나고, 이를 해결하기 위한 고가의 강의와 서비스들이 등장하고 있다. 특히 소셜 미디어에서는 검증되지 않은 과장된 전망들이 빠르게 확산되면서, 사람들의 불안감을 더욱 증폭시키고 있다.
이러한 마케팅이 성공하는 이유는 명확하다. 사람들은 급격한 기술 변화 앞에서 불안감을 느끼고, 뒤처질지도 모른다는 두려움(FOMO: Fear Of Missing Out)을 가지게 된다. 이런 심리를 자극하는 마케팅은 쉽게 효과를 거둘 수 있다.
2. 현재 우리가 가진 두려움의 실체
많은 사람들, 특히 창작자와 지식노동자들이 AI의 발전을 우려하고 있다. AI가 그림을 그리고, 글을 쓰고, 코드를 작성할 수 있게 되면서, 이러한 걱정은 더욱 커지고 있다. 특히 ChatGPT와 같은 대화형 AI의 등장은 이러한 불안을 현실적인 것으로 만들었다.
이러한 두려움의 핵심에는 '대체 가능성'이 있다. 글쓰기만 해도 AI는 이미 뉴스 기사를 작성하고, 광고 문구를 만들며, 심지어 소설까지 쓰고 있다. 디자인 분야에서는 Midjourney나 DALL-E와 같은 AI가 전문 일러스트레이터의 수준에 근접한 결과물을 만들어내고 있으며, 프로그래밍 영역에서도 AI는 이미 상당한 수준의 코드를 작성할 수 있다.
하지만 이러한 두려움의 실체를 자세히 들여다보면, 우리는 몇 가지 중요한 사실을 발견하게 된다. 첫째, AI가 생성하는 결과물은 여전히 인간의 의도와 판단, 그리고 맥락에 대한 이해를 필요로 한다. 둘째, AI는 기존 데이터의 재조합과 패턴 학습에 기반하고 있어, 진정한 의미의 창의성이나 혁신적 발상을 만들어내기는 어렵다. 셋째, AI는 여전히 윤리적 판단, 공감, 직관과 같은 인간 고유의 능력을 복제하지 못한다.
이러한 관점에서 볼 때, 우리의 두려움은 AI의 실제 능력보다는 그것이 가져올 변화에 대한 불확실성에서 비롯된 것일 수 있다.
3. 근미래에 대한 현실적 전망
현재 AI 기술의 실제 수준을 살펴보면, 향후 5-10년간의 변화는 기존의 협업 모델과 크게 다르지 않을 것으로 보인다. 대필 작가들이 오래전부터 다른 사람의 이야기를 글로 옮겨왔듯이, 미슐랭 레스토랑의 수석 셰프들이 모든 요리를 직접 하지 않고 메뉴를 기획하고, 맛과 퀄리티의 기준을 정하며, 최종 결과물을 검수하듯이, AI는 새로운 형태의 도구가 될 것이다.
이러한 변화는 이미 각 분야에서 구체적으로 나타나고 있다. 작가들은 스토리의 본질과 메시지를 구상하는 데 집중하고, AI는 이를 구현하는 다양한 표현 방식을 제안한다. 작가는 이 중에서 자신의 의도를 가장 잘 전달하는 방식을 선택하고 발전시킨다.
일러스트레이터들의 작업 방식도 변화하고 있다. 그들은 작품의 분위기, 구도, 색감 등 핵심적인 비전을 제시하고, AI를 통해 이를 다양한 방식으로 구현해본다. 최종적으로는 작가의 미학적 기준과 의도에 가장 부합하는 결과물을 선택하고 섬세하게 다듬는 방식으로 작업이 이루어진다.
개발자들의 경우, Github Copilot과 같은 AI 도구를 활용해 반복적인 코딩 작업뿐만 아니라 시스템 설계와 최적화 제안까지 도움을 받고 있다. 하지만 여전히 개발자는 비즈니스 요구사항의 정확한 이해, 전체 시스템의 방향성 결정, AI가 제안한 설계의 실현 가능성과 적절성 평가, 그리고 최종 의사결정 등 핵심적인 역할을 담당한다.
이러한 변화는 AI가 인간을 대체하는 것이 아니라, 오히려 인간의 창의성과 전문성을 더욱 극대화하는 방향으로 발전하고 있음을 보여준다.
4. 장기적 미래: 극단적 발전 시나리오의 모순
만약 AI가 정말로 "모든 것"을 할 수 있게 된다면 어떨까? 24시간 쉬지 않고 연구하는 AI와 로봇들이 무한한 발전을 이룬다면, 이는 역설적이게도 오히려 희망적인 시나리오가 될 수 있다. 에너지와 자원 문제가 해결되고, 의료와 환경 문제가 극복되며, 인류의 모든 물질적 필요가 충족되는 상황을 상상해볼 수 있다.
이러한 극단적 발전 시나리오에서는 현재 우리가 고민하는 많은 사회적 이슈들이 자연스럽게 해소될 것이다. 모든 것이 무한히 공급 가능한 상황에서는 기본소득에 대한 논의가 무의미해지고, 물질적 풍요로 인해 빈부 격차의 개념 자체가 사라질 것이다. 더 나아가 노동의 의미도 근본적으로 변화하여, 생존을 위한 수단이 아닌 순수한 자아실현의 도구로 탈바꿈하게 될 것이다.
이러한 상황이라면 인간은 생존을 위한 노동에서 완전히 벗어나 순수하게 자신이 하고 싶은 활동, 창작, 탐구에만 집중할 수 있게 될 것이다. 이는 마치 고대 그리스 철학자들이 노예제를 통해 육체노동에서 해방되어 순수한 사유와 예술 활동에 몰두했던 것처럼, 모든 인류가 진정한 자유를 얻게 되는 이상적인 미래상이라 할 수 있다.
5. 엔트로피 법칙과 완벽한 AI의 불가능성
하지만 우주의 기본 법칙인 엔트로피 법칙은 이러한 극단적 발전 시나리오가 비현실적임을 보여준다. 제레미 레프킨의 저서 "엔트로피"에서는 이러한 물리적 법칙이 사회와 경제 시스템에 미치는 영향을 깊이 있게 다루고 있으며, AI의 발전과 관련된 논의에서도 중요한 참고자료가 될 수 있다. 레프킨의 분석은 기술 발전이 가져오는 에너지 소비의 증가와 그에 따른 환경적, 사회적 영향을 이해하는 데 중요한 통찰을 제공한다.
모든 에너지 변환 과정에서는 필연적으로 손실이 발생하며, 이는 AI 시스템도 피해갈 수 없는 물리적 제약이다. 더욱이 시스템이 복잡해질수록 엔트로피는 더 빠르게 증가한다. 이는 AI가 더 정교하고 복잡해질수록, 그 유지와 작동에 필요한 에너지 손실이 기하급수적으로 늘어남을 의미한다. 마치 정교한 시계가 단순한 시계보다 고장 날 확률이 높은 것과 같은 원리다.
이러한 물리적 제약은 '완벽한' AI 시스템의 구현이 근본적으로 불가능함을 시사한다. 모든 결함을 스스로 감지하고 수정하는 시스템이나, 에너지 손실 없이 무한히 작동하는 시스템, 완벽한 자기 복제가 가능한 시스템 등은 열역학 제2법칙에 위배되며, 따라서 실현 불가능하다.
이러한 한계는 역설적으로 우리에게 위안을 준다. AI가 인류를 완전히 대체하거나 통제하는 디스토피아적 시나리오는 물리적으로 실현 불가능하기 때문이다. 대신 AI는 인간의 한계를 보완하는 도구로서 그 역할을 찾게 될 것이며, 이는 우리가 AI의 발전을 두려워할 것이 아니라, 현실적인 관점에서 이해하고 활용해야 함을 시사한다.
결론: 두려움이 아닌 냉철한 분석이 필요한 시점
AI 시대에 대한 막연한 공포는 불필요하다. 근미래에는 AI가 기존의 협업 도구의 연장선에서 발전할 것이며, 극단적인 장기 시나리오는 두 가지 가능성으로 귀결된다. 물리적 법칙에 의해 실현 불가능하거나, 혹은 실현된다면 오히려 인류에게 희망적인 미래가 될 것이다.
우리는 지금 AI와 관련된 수많은 담론의 갈림길에 서 있다. 일각에서는 과도한 불안감을 조성하며 이를 상업적으로 활용하려 하고, 다른 한편에서는 AI를 만능의 해결책인 것처럼 과대 포장한다. 하지만 이 두 극단은 모두 현실과는 거리가 있다.
따라서 지금 우리에게 정말 필요한 것은 이러한 과장된 담론에 휘둘리지 않고, 현실적인 관점에서 AI를 이해하고 활용하는 것이다. AI는 결국 인류가 만들어낸 도구이며, 그 발전 방향 역시 우리의 선택에 달려있다. 이는 두려워할 대상이 아니라, 오히려 인간의 창의성과 잠재력을 더욱 끌어올릴 수 있는 새로운 기회가 될 것이다.
우리는 AI라는 강력한 도구를 어떻게 활용할지, 그리고 이를 통해 어떤 미래를 만들어갈지 스스로 선택하고 결정할 수 있다. 이제는 막연한 두려움이나 과대 포장된 기대를 넘어, 보다 냉철하고 현실적인 시각으로 AI 시대를 준비해야 할 때다.
]]></description><link>https://w0nder.land/posts/10-AI%20%EC%8B%9C%EB%8C%80%EC%9D%98%20%EC%97%AD%EC%84%A4%3A%20%EB%91%90%EB%A0%A4%EC%9B%80%EA%B3%BC%20%ED%9D%AC%EB%A7%9D%20%EC%82%AC%EC%9D%B4%EC%97%90%EC%84%9C</link><guid isPermaLink="false">10</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 19 Jan 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[함께한다는 것에 대하여: 말하지 못한 진심들]]></title><description><![CDATA[처음으로 부모님과 함께하는 유럽여행. 어린 시절부터 부모님의 지원 덕분에 해외에서 공부하고 여행하며 많은 것을 배울 수 있었다. 그동안 부모님이 내게 주신 그 모든 기회들이 나를 성장하게 했다. 거리의 카페에서 여유를 즐기는 법을 알게 되었고, 오래된 건물들 사이를 걸으며 역사의 흔적을 발견하는 재미를 알았다. 박물관과 미술관에서 마주치는 작품들은 시간이 지날수록 더 깊이 다가왔다. 이제는 내가 알게 된 이 모든 것들을, 내게 이런 기회를 주신 부모님과 함께 나누고 싶었다. 그동안 받기만 했던 내가, 이번에는 부모님께 조금이나마 돌려드리고 싶었다.
하지만 파리의 어느 카페에서, 열심히 찾아간 미슐랭 레스토랑에서, 오랜 역사를 자랑하는 박물관에서. 부모님의 반응은 내 기대와는 달랐다. 현지 음식을 시도해보시다가도 결국은 고개를 젓고, 나는 그걸 보면서 또 다시 내심 짜증이 났다. "괜찮으세요?"라고 묻고 싶었지만, 그저 다른 식당을 찾아보자고만 했다. 내가 설렘 가득한 목소리로 들려드리는 이 도시의 이야기들은 부모님께 그저 지루하고 낯선 것일 뿐이었다.
결국 우리는 에어비앤비에서 라면을 끓여 먹었다. 현지 마트에서 간신히 찾은 김치와 함께. 부모님은 며칠 만에 제대로 된 한 끼를 먹는다며 좋아하셨지만, 나는 속으로 한숨을 쉬었다. '굳이 여기까지 와서...' 라는 말 대신 "맛있게 드세요"라고만 했다.
오후에는 그냥 숙소 근처 공원에서 시간을 보냈다. "여기도 좋네"라고 하시는 부모님의 말씀이 내 귀에는 "이제 저런 건물은 다 똑같아"로 들렸다. 부모님은 이미 지치셨고, 나는 뭔가를 더 보여드리고 싶은데, 그런 내 마음을 전하지도 못하고 그저 벤치에 앉아 있었다.
우리의 일상에서도 마주하는 순간들
이런 순간들은 비단 여행에서뿐만이 아니다. 회사에서 신입 사원이 새로운 방식을 제안하고 싶지만 선배들의 반응이 걱정될 때도, 경험 많은 선배가 변화를 시도하고 싶지만 팀원들의 불편함이 예상될 때도. 서로 다른 부서와 협업하며 업무 방식의 차이로 고민할 때도, 친구들과 새로운 취미를 나누려다 어색해질 때도.
"이런 방식은 어떨까요?"라고 말하고 싶지만 "네, 알겠습니다"라고 대답하는 신입처럼. "이렇게 하면 더 좋을 것 같은데..."라고 제안하고 싶지만 "지금 방식도 나쁘지 않네요"라고 돌려 말하는 선배처럼. 우리는 늘 이런 간극 속에서 살아간다.
매 순간이 조율이다. 회의에서 의견을 내는 것도, 팀 프로젝트의 방향을 정하는 것도, 심지어 점심 메뉴를 고르는 것도. 누군가는 늘 불만을 가지게 되고, 그냥 대충 타협하거나, 아니면 한 사람이 전부 양보하는 식으로 끝나기도 한다.
솔직함 앞에 선 우리들의 두려움
'함께 한다는 것'의 첫걸음은 어쩌면 솔직해지는 것일지도 모른다. 하지만 그 솔직함 앞에서 우리는 자주 멈춰 선다.
회사에서는 "이 방식은 비효율적인 것 같아요"라는 말이 선배를 비난하는 것으로 들릴까 봐, 친구에게는 "너의 그런 행동이 불편해"라는 말이 우정을 깨트릴까 봐, 부모님께는 "이걸 정말 함께 보고 싶었어요"라는 말이 부담으로 다가갈까 봐.
솔직해진다는 건 관계의 변화를 받아들인다는 의미이기도 하다. 그동안 쌓아온 안정적인 관계가 흔들릴 수 있다는 불안감, 상대방이 나를 다르게 볼지도 모른다는 두려움, 그리고 그 이후의 관계를 어떻게 이어가야 할지에 대한 막연한 걱정. 이런 감정들이 우리의 입을 막는다.
그럼에도 불구하고
하지만 우리는 알고 있다. 영원히 숨길 수 없다는 것을. 눈치만 보다가는 결국 서로가 지쳐버린다는 것을. 때로는 그 불편한 솔직함이, 답답했던 관계에 새로운 숨통을 틔워줄 수도 있다는 것을.
완벽한 타이밍이나, 완벽한 방법은 없을 것이다. 그저 우리는 각자의 방식대로, 각자의 속도로, 조금씩 솔직해지기 위한 용기를 내어볼 수 있을 뿐이다. 때로는 서툴고, 때로는 어설프게.
어쩌면 '함께하기'란 그런 서로의 불완전한 솔직함을 기다려주고, 받아들이는 과정인지도 모른다. 그리고 그 과정에서 우리는 조금 더 진실된 관계, 조금 더 깊이 있는 이해를 만들어갈 수 있을 것이다.
]]></description><link>https://w0nder.land/posts/9-%ED%95%A8%EA%BB%98%ED%95%9C%EB%8B%A4%EB%8A%94%20%EA%B2%83%EC%97%90%20%EB%8C%80%ED%95%98%EC%97%AC%3A%20%EB%A7%90%ED%95%98%EC%A7%80%20%EB%AA%BB%ED%95%9C%20%EC%A7%84%EC%8B%AC%EB%93%A4</link><guid isPermaLink="false">9</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 12 Jan 2025 09:00:00 GMT</pubDate></item><item><title><![CDATA[2025년 만다라트]]></title><description><![CDATA[
2025년 만다라트
2025년을 위한 나만의 만다라트 계획
안녕하세요. 오늘은 제가 2025년을 위해 만든 만다라트 계획에 대해 이야기해보려고 합니다.
만다라트는 목표를 체계적으로 세우고 달성하는 데 도움을 주는 도구인데요, 제 만다라트는 나답게 살기 위한 여러 목표들로 구성되어 있습니다.
다 만들고 보니 목표랑 연관이 없는 듯한 그냥 제가 하고 싶은 것들이 담기게 되었네요.
일본어 잘하기
첫 번째 목표는 "일본어 잘하기"입니다.
JLPT 4급부터 시작해서 2급까지 차근차근 준비해나갈 계획입니다.
제2외국어로 일본어를 공부했고 일본 문화에도 익숙해서 듣기와 말하기는 어느 정도 할 수 있지만, 이번에는 제대로 실력을 쌓아보려고 합니다.
잊어버린 히라가나와 가타카나부터 다시 시작해서, 집에 있는 JLPT 4급 교재로 공부를 시작하고 연말에는 2급 시험에 도전해보려고 합니다.
전문분야 공부
두 번째는 "전문분야 공부"입니다.
앞으로 하는 일에 큰 도움이 되지는 않겠지만 호기심에 기술사에 도전해보려고 합니다.
그 전에 정보보안기사로 워밍업을 하고 2년 계획으로 기술사에 도전할 예정입니다.
정보보안기사는 제가 직접 스터디를 운영하면서 함께 공부하는 방식으로 준비할 계획입니다.
혼자 하면 중도 포기하기 쉬운데, 스터디를 통해 완주할 확률을 높여보려고 합니다.
새로운 도전
세 번째는 "다른 일 해보기"입니다.
지금까지 개발 외의 일을 해본 적이 없는데, 이제는 다른 분야도 경험해보고 싶어졌습니다.
바리스타와 코딩 강사에 도전해보려고 합니다.
바리스타 자격증이 없어도 일할 수는 있지만, 공부 과정이 즐거울 것 같고 구직에도 도움이 될 것 같습니다.
또한 교육 분야가 저와 잘 맞는지 확인해볼 겸 코딩 강사에도 도전해보려고 합니다.
수익화 도전
네 번째는 "fi-workers"입니다. 올해는 수익화에 더 집중하려고 하는데요, 주된 전략은 다작입니다.
'Show Your Time'은 유지보수 모드로 전환하고, 올해는 2개의 새로운 수익 모델을 시도해볼 계획입니다.
그 외의 목표들
이 외에도 "기록하기", "사이드 프로젝트", "건강하기"라는 중요한 목표들이 있습니다.
매일의 일기부터 월간 회고, 독서 기록까지 꾸준히 기록을 남기고, 다양한 서비스를 만들어보며, 규칙적인 운동으로 건강도 챙기려고 합니다.
마무리
2025년, 이 만다라트를 통해 나다운 사람이 되어가기를 기대합니다.
모든 목표를 100% 달성하는 것보다는, 꾸준히 노력하고 성장하는 과정 자체를 즐기면서 한 걸음씩 나아가려고 합니다.
여러분은 2025년을 위해 어떤 계획을 세우고 계신가요? 저처럼 만다라트를 작성해보는 것은 어떨까요? 함께 성장하는 2025년이 되었으면 좋겠습니다.

]]></description><link>https://w0nder.land/posts/8-2025%EB%85%84%20%EB%A7%8C%EB%8B%A4%EB%9D%BC%ED%8A%B8</link><guid isPermaLink="false">8</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Tue, 31 Dec 2024 09:00:00 GMT</pubDate></item><item><title><![CDATA[[리뷰] AI 트루스]]></title><description><![CDATA[

책을 읽으며 공감과 동시에 약간의 아쉬움을 느꼈다.
AI의 현재와 미래에 대해 상대적으로 현실적인 접근을 하고 있는 점은 높이 평가할 만하다.
하지만 여전히 비현실적인 부분들이 존재하며, 특히 "AI가 인류를 대체할 것"이라는 공포는 과장되어 있다고 생각한다.
당신처럼 인공지능의 도움을 얻어 전보다 더 많은 일을, 더 효율적으로, 더 빨리 수행하는 사람이 그렇지 않은 사람의 일을 빼앗는 것뿐이에요.

15년 전 AI를 공부했을 때부터 지금까지 AI 기반 제품을 개발하면서 느낀 점은 한 가지다. AI는 본질적으로 도구일 뿐이라는 것이다.
생성형 AI가 여러 성과를 내고 놀라운 가능성을 보여주고 있지만, 그 한계 역시 분명하다.
통계적 기반에서 만들어진 현재의 AI는 스스로 사고하지 못하며, 단순히 인간의 작업을 보조하는 어시스턴트 역할에 그칠 가능성이 높다.
인공지능 모델이 사람처럼 자연스러운 문장을 만들어낼 수 있는 이유는 인공지능이 실제로 사고를 하기 때문이 아니라 얀 르쿤이 비판한 것처럼 확률을 사용하기 때문이다.

책에서도 언급되었듯이, AI는 정규 분포의 가운데 영역에 속한 일, 즉 반복적이고 예측 가능한 업무에 강점을 보인다.
하지만 정규 분포의 끝, 특히 상위 10% 영역의 창의적이고 고유한 문제는 현재의 기술로는 해결하기 어렵다.
이는 우리가 AI와 공존하며 어떤 역할을 해야 할지를 시사한다.
‘인공지능 개발자 데빈이 사람 개발자를 대체할 것인가’라는 질문이다. 이 질문에 대해 코그니션은 그렇지 않다고 답했다. 그게 공식적인 답변이다

개발자나 디자이너로서 우리는 과거와 현재를 기반으로 이러한 10% 영역을 개척해야 한다.
AI가 다룰 수 없는 인간 고유의 창의력과 통찰력을 활용해 새로운 가치를 만들어내는 것이 우리의 역할이다.
이를 위해 우리는 AI의 한계를 명확히 이해하고, 기술의 가능성을 현실적으로 판단하며 활용해야 한다.
우리는 어떤 작가가 인공지능을 이용해서 글을 쓰는지 여부를 너무 따질 필요가 없다. 그 사람이 작가의 삶을 사는지 여부가 더 중요하다

책은 이런 점에서 중요한 질문을 던지고 있다.
"AI 시대에 우리가 무엇을 해야 하는가?" 이 질문에 대한 답은 단순히 기술을 두려워하거나 무조건 받아들이는 것이 아니라,
기술의 장점과 한계를 구분하고 인간 중심의 가치를 우선시하는 데 있다.
결론적으로, 이 책은 AI 시대를 준비하는 데 있어 유용한 시사점을 제공하지만,
여전히 비현실적 기대를 배제하지 못한 부분이 있다.
우리는 AI가 잘할 수 있는 부분과 그렇지 못한 부분을 명확히 구분하고,
그 경계선에서 인간의 창의성을 발휘해야 한다.
AI가 보조 도구로서 우리의 삶을 더욱 풍요롭게 만들어주는 세상을 기대하며,
이 책이 제시하는 논의를 기반으로 우리의 역할을 더 깊이 고민해볼 필요가 있다.
PS. 포스트모템을 반성문이라고 표현한건 아쉽다 ㅋ
“너무 오래전에 작성한 코드라 자세히 기억나지 않지만, 제가 코딩을 하던 시절에 미처 테스트하지 못한 사례가 발생한 것 같습니다.
미팅 후에 더 면밀히 들여다보고 포스트모템 글을 작성해서 올리겠습니다.” 쉽게 말해 반성문을 제출하겠다는 의미였다.

]]></description><link>https://w0nder.land/posts/7-%5B%EB%A6%AC%EB%B7%B0%5D%20AI%20%ED%8A%B8%EB%A3%A8%EC%8A%A4</link><guid isPermaLink="false">7</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Fri, 22 Nov 2024 09:00:00 GMT</pubDate></item><item><title><![CDATA[나는 열린 마음의 소유자인가]]></title><description><![CDATA['내가 맞다'는 생각은 거부할 수 없는 유혹이다.
마치 달콤한 사탕처럼 우리의 마음을 사로잡고, 때로는 중독성 있는 마약처럼 우리의 판단을 흐리게 만든다.
그리고 우리는 종종 이 확신이 얼마나 위험한지를 뼈아프게 깨닫는다.
완벽하다고 믿었던 기획은 실패하고, 틀렸다고 생각했던 동료의 의견이 옳았음을 알게 된다.
우리의 성장을 가로막는 가장 치명적인 함정은, 바로 이 달콤한 확신이다.
타인의 의견을 수용하는 것은 우리가 생각하는 것보다 훨씬 어려운 과제다.
대부분의 사람들이 자신을 열린 마음의 소유자라고 여기지만, 실제로는 그렇지 못한 경우가 많다.
이는 우리 모두가 가진 자연스러운 성향이며, 이런 이유로 관련된 책과 강연이 끊임없이 등장하는 것으로 보인다.
전문성과 경력이 쌓일수록 자신의 경험과 지식에 기반한 에고는 더욱 강화된다.
다른 분야의 사람이나 경험이 부족한 사람의 의견을 수용하기가 점점 더 어려워진다.
자신의 지식이 전부가 아님을 인정하는 것은 실제로는 상당히 어려운 일이다.
특히 깊은 고민과 논리적 사고를 거쳐 도출한 결론일수록 더욱 그러하다.
에고는 더욱 견고해지고 딱딱해진다.
하지만 현실에서는 모든 것이 논리적으로 작동하지 않는다.
직관과 경험이 때로는 더 나은 해답을 제시하기도 하며, 완벽한 논리로 설명할 수 없는 상황이 빈번하게 발생한다.
]]></description><link>https://w0nder.land/posts/6-%EB%82%98%EB%8A%94%20%EC%97%B4%EB%A6%B0%20%EB%A7%88%EC%9D%8C%EC%9D%98%20%EC%86%8C%EC%9C%A0%EC%9E%90%EC%9D%B8%EA%B0%80</link><guid isPermaLink="false">6</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Thu, 21 Nov 2024 09:00:00 GMT</pubDate></item><item><title><![CDATA[[리뷰] 구글 임원에서 실리콘밸리 알바생이 되었습니다]]></title><description><![CDATA[

구글에서 layoff 이후 실리콘밸리에서 알바생이 되어 일하면서 느낀 것들을 담은 책이다.
매우 바쁘게 삶을 살아가는 분이라 오히려 이렇게까지 할 수 있나 싶은 생각도 들었다.
에세이 형식이라 다른 이야기들을 하고 있지만 책 전체를 관통하는 부분들이 눈에 띄었고, 공감이 되었다.
루틴의 중요성
최근에 심적으로 많은 어려움들이 있는데, 이런 상황에서 루틴을 만들어서 꾸준히 지키는 것이 중요하다는 생각이 들었다.
회복력. 바닥에 떨어져도 바로 치고 올라올 수 있는 능력이다. 고무줄은 쭉 늘렸다가 놓으면 금방 원래대로 돌아온다.
사람에게도 이런 능력이 있다. 하지만 완전히 바닥으로 곤두박질치면 벗어나기란 쉽지 않다.
그래서 나는 생활의 루틴을 만들라고 권하고 싶다. 나의 하루, 나 자신을 정의하는 루틴을 만들어 그냥, 계속하는 것이다.

이 루틴은 정리해고된 바로 다음 날에도 동일하게 실행됐다. 출근하지 않으니 일찍 일어날 필요가 없었는데도 말이다.
매일, 매주, 매달 루틴을 지키려면 기분이 다운될 시간이 없었다.
큰 변화가 있을 때 조용히 쉬면서 마음을 가다듬는 것도 좋지만 나만의 루틴이 있다면 그것을 크게 깨지 않는 범위 안에서 하는 게 좋다. 어차피 큰 충격은 단기간에 해결되지 않는다.
‘침잠기를 가졌다가 회복된 후에 다음 단계를 밟아야지’라고 생각한다면 영원히 우울감에 잠겨버릴 수도 있다.

우리는 어떻게 뉴비들을 대해야 하는가
사람들을 채용하다 보면 기대했던 만큼 성과를 내지 못하는 경우가 있다. 이는 당연한 과정이며, 새로운 환경에서 서툴러지는 것이 자연스러운 현상이다.
소수는 능력 부족일 수 있지만, 대부분은 새로운 환경에 적응하지 못해 어려움을 겪는 경우가 많다. 심지어 특정 분야에서 업계 최고로 인정받던 사람도 다른 분야에서는 초보자로서 어려움을 겪을 수 있다.
따라서 경력직이라 하더라도 새로운 환경에서는 초보자로 대우하며 존중하고 도와주는 것이 중요하다. '개구리 올챙이 시절'을 떠올려보면, 우리 모두 초보자였을 때 주변에서 도움을 받았던 경험이 있다. 그때는 미처 인식하지 못했지만, 우리를 도와준 사람들이 분명히 있었다.
이런 경험을 바탕으로, 새로 합류한 구성원들에게 인내심을 가지고 적응할 시간과 기회를 제공하는 것이 건강한 조직 문화를 만드는 데 필수적이다.
그런데 이때! ‘멘토 운전사’로부터 문자 메시지가 왔다.
리프트에는 ‘버디 시스템buddy system’이 있어서, 초보 리프트 운전사가 경험 많은 동료 운전사로부터 도움을 받을 수 있다.
먼저 일을 시작한 운전사 동료들이 멘토가 되어 첫 운전을 언제 시작하는 것이 좋은지, 운행 전에 구체적으로 어떤 준비가 필요한지, 예행연습은 어떻게 하면 좋은지 등 실질적인 조언을 해주는 제도다.
어디에 살고, 누구인지도 모르는 이 멘토와 대화를 나누며 긴장을 풀 수 있었다.

소소한 사고도 쳤다. 계산대 업무를 할 때였다.
한 고객의 카드에 오류가 있어 결제가 완료되지 않았는데 이것을 모르고 물건을 포장해서 내주었다.
계산대 화면에 ‘결제 오류’라는 팝업창이 떠 있었는데 확인하지 못한 내 잘못이었다. 나는 고객을 찾으러 무작정 주차장으로 뛰어나갔다.
주차장에 있는 사람들에게 일일이 카드 결제 영수증을 받았는지 물어봤고, 50분처럼 느껴지는 5분을 뛰어다닌 후 겨우 그 고객을 찾았다. 유니폼은 땀으로 흠뻑 젖었다.
얼마나 다행인지 ‘휴!’ 하고 한숨을 내쉬며 그 고객과 다시 매장으로 들어왔다.
그런데 아뿔싸! 내가 맡은 계산대에는 난리가 나 있었다. 계산하기 위해 줄을 서 있던 고객들이 영문도 모른 채 갑자기 뛰어나가버린 캐셔를 5분 이상 기다려야 했으니 당연하다.
고객을 찾아 문제를 해결했다고 칭찬받을 줄 알았는데, 일단 일이 시작되면 캐셔는 계산대를 절대 비워서는 안 된다고 주의받았다.
첫 출근 날부터 매니저에게 주의를 받다니, 민망했다.

시작은 누구나 서툴지!
주문을 받을 때마다 “제가 오늘 첫 근무라서 많이 서툴러요. 이해해주세요.” 이렇게 일단 말문을 열고 주문을 받기 시작했다.
주문시스템 버튼 이것저것을 몇 번이나 눌러본 다음에야 가장 간단한 아이스 아메리카노 주문을 받을 수 있었다.
종일 “죄송합니다”를 달고 살았고 아이스를 핫으로, 핫을 아이스로, 벤티 사이즈가 그란데 사이즈로 잘못 나갔다.
음료를 만드는 바리스타들도 잘못된 주문서 때문에 몇 번이나 다 만든 음료를 싱크대에 쏟아붓고 다시 만들어야 했다.
미안했다. 다행히 슈퍼바이저는 처음엔 다 그러니, 걱정하지 말라고 위로해주었다.
시작은 누구나 서툴다. 빨리 배우는 사람이 있고 더딘 사람들이 있다. 나의 더딤을 이해해주는 매장 매니저, 함께 일하는 동료들에게도 깊은 고마움을 느낀다.
“처음부터 잘하는 사람이 어디 있어요. 다 배우는 단계가 필요하지”라고 나에게 따뜻한 위로의 말을 건네는 고객들에게도 이루 말할 수 없이 감사했다.

올라운드 플레이어
특정 업무 담당자가 존재하게 하는 팀 구성은 효율적으로 보일 수 있으나 전체적으로 길게 보았을 때 비효율적이다.
영원한 것은 없고 사람들은 계속 들어왔다 나가며, 특정 업무도 언젠간 사라질 수 있다.
팀 내에서 특정 업무 담당자가 없이 모두가 모든 업무를 수행하게 되면 오히려 문서화가 잘 되고, 지식이 공유되어 있어서 효율적이다.
문서화가 잘 되는 이유는 모든 팀원이 업무를 이해하고 수행해야 하기 때문에 자연스럽게 상세한 설명과 절차를 기록하게 되며, 이는 지식 전달과 업무 연속성 유지에 도움이 된다.
그리고 특정 업무 담당자가 없어도 다른 사람이 대체할 수 있어서 팀 내에서 유연하게 업무를 수행할 수 있다. 특히 휴가나 퇴사 등의 부재가 발생했을 때 특정 업무 담당자가 없어도 다른 사람이 대체할 수 있어서 팀 내에서 유연하게 업무를 수행할 수 있다.
프로젝트를 진행하면서 특정 업무 하나만 관여되는 게 아니라 여러 업무들이 합쳐져서 프로젝트가 진행된다. 그리고 프로젝트도 하나만 진행되는 게 아니라 동시에 여러 개가 진행된다.
대부분 프로젝트에서 하나의 모듈에 대해 개발을 하는 게 아니라 여러 모듈이 연관되어서 개발하게 된다.
그러면 프로젝트 참여 시 여러 인원이 들어가야 하고, 간혹 의존성이 높은 모듈의 경우 한 명이 여러 프로젝트에 동시에 참여해서 오전엔 A 오후엔 B 이렇게 진행하게 된다.
그런데 이렇게 하면 콘텍스트 스위칭이나 기타 문제점들로 인해 협업 생산성이 대폭 하락하게 된다.
하지만 올라운드 플레이어가 되면 한 명이 하나의 프로젝트만 집중해서 진행할 수 있다. 거기에서 오는 이점은 매우 강력하다.
한 명이 너무 많은 업무를 알아야 하는 부담이 있을 수 있다.
하지만 다르게 생각해보면 팀장의 경우 이미 해당 팀이 해야 하는 업무들을 다 알고 있다. 팀장이 할 수 있으면 다른 팀원들도 시간을 들이면 다 할 수 있다.
혹은 너무 많으면 오히려 팀을 분리해야 하는 시점으로 보는 것도 좋을 것 같다.
오히려 매니징의 능력이 더 중요하다.
매니징이 더 중요해지는 이유는 올라운드 플레이어들로 구성된 팀에서는 개개인의 역량보다 이들을 효과적으로 조직하고, 업무를 분배하며, 팀원들의 성장을 지원하는 능력이 팀의 성과를 좌우하기 때문이다.
또한, 다양한 업무를 수행할 수 있는 팀원들 사이에서 각자의 강점을 파악하고 이를 프로젝트에 적절히 활용하는 것이 매니저의 핵심 역할이 된다.
트레이더 조 매장은 시간차를 두고 하루에 일하는 사람이 80~90명이지만, 그 1.5배수인 총 150명가량을 상시 인력풀로 충분히 확보하고 있다.
또 매장 내의 모든 크루는 캐셔를 포함해서 15개 제품 섹션에서 순환 근무하기 때문에 매장에 있는 전 제품에 대해 알게 된다.
그야말로 모든 크루가 스포츠팀에서 다양한 역할을 할 수 있는 ‘올라운드 플레이어’가 된다. 이렇게 모든 크루가 어느 제품 섹션에 배치되어도 일을 잘할 수 있기에 교환 근무가 가능하다.
충분한 인력과 표준화된 업무 방식 덕분에 누구나 바라는 ‘일할 땐 일하고, 쉴 땐 쉬는 문화’가 실현될 수 있는 것이다. 그만큼 일에 대한 만족도도 높아질 수밖에 없다.


제품 중심
시간이 걸리더라도 제품에 집중하는 것이 중요하다. 좋은 제품이 항상 성공을 보장하지는 않지만, 좋은 제품 없이는 성공할 수 없다.
단기적인 이익을 추구하는 것이 아니라면, 제품의 품질과 가치에 집중하는 것이 핵심이다.
다만 이는 시간이 오래 걸리는 과정이므로, 인내심을 가지고 꾸준히 노력할 수 있는 역량이 필요하다.
장기적인 성공을 위해서는 제품의 완성도를 높이는 데 집중하면서도, 그 과정에서 발생하는 도전과 어려움을 견딜 수 있는 끈기가 요구된다.
“우리는 PR을 하지 않는다. 우리의 가장 큰 PR은 질 좋은 제품 그 자체이다

가장 좋은 PR은 입소문이고, 진심으로 제품에 만족한 고객이 가족, 친구, 동료들에게 또 그들의 SNS에 소문을 낸다면 그것이 가장 효과 있는 마케팅이고 PR이다.
트레이더 조에 대해 공부하려고 도서 검색을 했더니 트레이더 조 일반 고객이 자기가 좋아하는 트레이더 조 제품에 대한 소개를 쓴 책이 있어서 놀라기도 했다.
열성적인 고객들이 운영하는 트레이더 조 제품 웹사이트가 있을 정도이다.

제품이 최고의 마케팅이다   트레이더 조는 스스로 ‘유통 회사’가 아닌 ‘제품 중심의 회사’라고 말한다. 애플이나 구글처럼 말이다.
트레이더 조의 바이어들은 최고의 제품을 가장 합리적인 가격에 제공하기 위해, 조금이라도 더 가성비 좋은 제품을 찾아 전 세계를 누빈다.

사이드 허슬
사이드 프로젝트는 위대하다.
‘사이드 허슬side hustle’이란, 직장을 다니면서 본업 이외에 재미있는 일을 하는 것을 말한다.
트레이더 조, 스타벅스, 리프트 일을 하면서 예전에도 이런 일을 사이드 허슬로 했으면 좋았겠다는 생각이 수시로 들었다.

]]></description><link>https://w0nder.land/posts/5-%5B%EB%A6%AC%EB%B7%B0%5D%20%EA%B5%AC%EA%B8%80%20%EC%9E%84%EC%9B%90%EC%97%90%EC%84%9C%20%EC%8B%A4%EB%A6%AC%EC%BD%98%EB%B0%B8%EB%A6%AC%20%EC%95%8C%EB%B0%94%EC%83%9D%EC%9D%B4%20%EB%90%98%EC%97%88%EC%8A%B5%EB%8B%88%EB%8B%A4</link><guid isPermaLink="false">5</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sun, 08 Sep 2024 09:00:00 GMT</pubDate></item><item><title><![CDATA[ShowYourTime에 3:4 비율 기능을 다시 도입하며]]></title><description><![CDATA[안녕하세요, ShowYourTime을 개발하고 있는 w0nder입니다. 이번 포스팅에서는 저희 앱에 4:3 비율 기능을 다시 추가하면서 개선한 내용을 공유하고자 합니다.

4:3비율
ShowYourTime에는 원래 4:3 비율 기능이 있었지만, 레이아웃과 여러 영역 조정 문제로 인해 잠시 기능을 제거한 적이 있습니다. 그런데 기능을 제거하자마자 앱 리뷰에서 사라져서 아쉽다는 유저 의견이 있었고, 이를 계기로 다시 도입을 고민하게 되었습니다.

좋은 어플, 예쁜 타임 스탬프!
비율을 바꾸면 화면이 울렁거려요.
이번 업데이트에서는 기존 기능을 단순히 복원하는 것에 그치지 않고, 사용자 경험을 향상시키기 위해 다양한 개선 사항을 함께 적용했습니다. 그 중에서도 가장 중점적으로 다룬 부분은 비율 변경 시 발생하던 화면 흔들림 문제를 해결하는 것이었습니다.

아 안돼
기존에는 비율을 변경할 때마다 카메라 영역의 크기 자체를 조정하는 방식을 사용했습니다. 이 방식은 비율 변경 시 카메라가 초기화되면서 초점을 다시 맞추는 과정을 거치게 됩니다. 이로 인해 사용자가 화면을 보고 있을 때 갑작스러운 흔들림이 발생하여 시각적으로 불편함을 느낄 수 있었습니다.
이 문제를 개선하기 위해 새로운 접근 방식을 택했습니다. 먼저 카메라 영역을 4:3 비율로 고정하고, 그 위에 검은색 레이어를 겹쳐 놓았습니다. 이 검은색 영역은 마치 사진에 검은 테이프를 붙여놓은 것처럼 카메라 화면의 위아래를 가립니다. 비율 변경 시에는 검은색 레이어의 높이를 조절하여 보이는 카메라 영역의 비율을 변경하는 방식을 사용했습니다. 예를 들어 1:1 비율로 변경할 때는 검은색 레이어를 상하로 늘려 중앙에 정사각형 모양의 카메라 영역이 보이도록 하고, 4:3 비율로 변경할 때는 검은색 레이어를 상하로 축소하여 전체 카메라 영역을 노출시킵니다.

UI 해부
이렇게 함으로써 카메라 영역 자체는 변하지 않고 일정하게 유지되면서도, 사용자에게는 마치 카메라 영역의 비율이 변경되는 것처럼 보이게 됩니다. 이 방법을 통해 비율 전환 시 화면의 요동 없이 자연스럽고 부드러운 변화를 구현할 수 있게 되었습니다.
Round도 문제였습니다.
앞서 설명한 비율 변경 시 카메라 영역의 크기를 직접 조정하는 대신 영상의 비율을 조절하는 방식으로 변경하면서, 기존에 사용하던 방식인 border를 통한 모서리의 라운드 효과를 적용할 수 없게 되었습니다.

Round 는 여기 입니다.
사진 촬영 시 모서리에 라운드 처리를 적용하는 옵션이 있었지만, 사용자가 많지 않았고 콜라주 기능을 사용할 때 어색해 보여서 이전에 제거했던 기능이었습니다. 그러나 실수로 UI에는 여전히 해당 옵션이 남아있는 상태였습니다.
이에 대해 디자이너인 나나산님께 의견을 구했더니, 이 기능이 'UI의 시적 허용'이라고 표현하시면서 다른 앱과의 차별점이라고 하셨습니다. 이에 힘을 얻어 모서리 라운드 처리를 다시 구현해 보기로 결정했습니다.
기존의 border를 사용한 방식 대신, 모서리에 라운드 처리된 검은색 SVG(Scalable Vector Graphics)를 카메라 영역 위에 겹쳐 올리는 방식으로 구현했습니다. SVG는 벡터 그래픽 형식으로, 이미지를 확대하거나 축소해도 선명도가 유지되는 장점이 있습니다.
먼저, 라운드 처리된 모서리 부분만 검은색으로 처리한 투명 SVG 파일을 준비했습니다. 그리고 카메라 영역 위에 이 SVG 파일을 화면의 각 모서리에 겹쳐 올림으로써, 마치 카메라 영역의 모서리가 라운드 처리된 것처럼 보이게 했습니다. 이러한 방식을 통해 비율 변경으로 인한 카메라 영역의 크기 변화에 상관없이 일관된 모서리 라운드 효과를 유지할 수 있게 되었습니다.
결론
비록 복잡해 보이는 구현 방식이지만, 사용자에게는 더 나은 경험을 제공할 수 있게 되어 뿌듯합니다. 개발 과정에서 여러 요구사항을 구현하다 보면 불가능해 보이거나 막막할 때가 있지만, 다른 시각으로 고민하다 보면 항상 해결 방법이 있다는 것을 깨닫게 되었습니다. 문제를 바라보는 관점을 조금씩 바꿔가며 실마리를 찾아가는 과정에서 개발자로서의 즐거움을 느끼고 있습니다.
ShowYourTime은 개발 과정에서 더 나은 사용자 경험을 제공하기 위해 노력하고 있습니다. 앞으로도 사용자 여러분의 소중한 의견에 귀 기울이며, 끊임없는 개선과 혁신을 통해 여러분의 시간을 더욱 가치 있게 만들어줄 수 있는 ShowYourTime이 되도록 노력하겠습니다.

]]></description><link>https://w0nder.land/posts/4-ShowYourTime%EC%97%90%203%3A4%20%EB%B9%84%EC%9C%A8%20%EA%B8%B0%EB%8A%A5%EC%9D%84%20%EB%8B%A4%EC%8B%9C%20%EB%8F%84%EC%9E%85%ED%95%98%EB%A9%B0</link><guid isPermaLink="false">4</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Tue, 28 May 2024 09:00:00 GMT</pubDate></item><item><title><![CDATA[레드닷(Red Dot)으로 기록탭 인지 시키기]]></title><description><![CDATA[안녕하세요, ShowYourTime 앱 개발자입니다. 이번 글에서는 ShowYourTime 앱의 기록탭 활성화를 위해 진행한 레드닷(Red Dot) 실험에 대해 공유하고자 합니다.
ShowYourTime 앱과 기록탭의 중요성
ShowYourTime 앱은 단순한 타임스탬프 기능 이상으로, 사용자들이 목표 달성을 위해 꾸준히 습관을 기를 수 있도록 돕는 것을 목표로 하고 있습니다. 이를 위해 저희 팀은 사용자들이 과거 기록을 보며 자신의 꾸준함을 자랑스러워하고, 이를 공유하는 행동을 통해 지속적인 동기부여를 받을 수 있기를 기대하며 기록탭 기능을 제공하고 있습니다.
그러나 현재 ShowYourTime 앱 사용자 중 약 25%만이 기록탭을 활용하고 있는 상황입니다. 저희는 이 수치를 높이고자 했고, 우선적으로 5% 정도 증가시키는 것을 목표로 삼았습니다. 사용자들이 기록탭을 사용하지 않는 이유에 대해 가설을 세워보았습니다.

기록탭에 사용자들이 만족할만한 기능이 부족함
사용자들은 기록탭의 존재 자체를 인지하지 못함

특히 두 번째 문제점은 사용자 테스트(UT)를 통해 더욱 명확해졌는데, 심지어 IT 종사자인 디자이너조차 앱 하단에 탭이 있는지 모르는 경우가 있었습니다. 블랙 테마로 인해 탭이 눈에 잘 띄지 않는 것이 주된 원인으로 보였지만, 이 정도일 거라고는 예상하지 못했던 충격적인 발견이었습니다.

레드닷 UI - 여기를 눌러보시겠습니까?
이에 따라 저희 팀은 리소스가 부족한 상황에서도 기록탭을 효과적으로 인지시킬 수 있는 방안을 모색하게 되었습니다. 그 결과 UI/UX를 크게 변경하지 않으면서도 사용자의 시선을 끌 수 있는 레드닷을 기록탭에 추가하는 아이디어를 떠올리게 되었습니다.
레드닷으로 기록탭 사용이 늘어났을까?

3개월간의 전체 DAU 와 기록탭 DAU
2.3.0 버전(2024-04-08)에서 기록탭에 레드닷을 적용하고, 그 효과를 분석해보았습니다. 레드닷 추가 전후의 기록탭 일일 활성 사용자(DAU) 추이를 살펴본 결과, 당초 기대했던 것과는 다소 다른 양상을 보였습니다.
레드닷 추가 직후인 4월 8일에는 일시적으로 수치가 상승했지만, 이내 4월 1일 수준으로 다시 떨어졌습니다. 중간에 선거 등 휴일로 인한 하락이 있기는 했지만, 전반적으로 레드닷의 기록탭 사용 유도 효과는 크지 않았던 것으로 판단됩니다. 오히려 3월 초와 4월 초에 기록탭 사용이 늘어난 것은 서비스 특성상 월초에 유저가 증가하는 일반적인 경향과 유사한 패턴으로 보입니다.
레드닷을 얼마나 눌렀을까?

사람들은 얼마나 레드닷을 누를까?
레드닷 실험 결과를 분석해 보면, 전체 사용자 782명 중 약 60%인 431명이 레드닷을 클릭하여 기록탭의 존재를 인지하게 되었습니다. 이는 절반 이상의 사용자가 레드닷에 반응했다는 점에서 주목할 만한 결과입니다. 하지만 레드닷의 클릭률이 인스타그램 공유 버튼의 클릭률(17%)과 비교하면 상대적으로 높아 보일 수 있지만, 사용자의 주의를 환기시키고자 했던 레드닷의 목적을 고려할 때 60%의 클릭률이 충분히 만족스러운 수준인지는 의문의 여지가 있습니다.
더욱이 사용자들이 레드닷을 통해 기록탭을 인지하게 되었다고 하더라도, 실제로 이를 활용할 만한 니즈가 부족했을 가능성이 있습니다. 전체 사용자의 DAU가 290~300명 정도인 것에 비례하여, 기록탭을 알게 된 431명의 사용자 중에서는 기록탭 DAU가 160명 정도가 되어야 할 것으로 예상되었습니다. 그러나 실제 기록탭 DAU는 70명 수준에 그쳤으며, 이 수치는 과거에 비해서도 크게 늘어나지 않았습니다. 이는 사용자들이 기록탭의 필요성을 충분히 느끼지 못해 지속적으로 사용하지 않았음을 시사합니다.
결과적으로 이번 레드닷 실험은 사용자들의 관심을 기록탭으로 유도하는 첫 단계로서의 역할은 어느 정도 수행했지만, 그 이후의 사용자 경험 개선에는 직접적으로 기여하지 못한 것으로 평가할 수 있습니다. 따라서 레드닷의 클릭률에 안주하기보다는, 사용자들이 기록탭에서 어떤 가치를 얻을 수 있는지, 그리고 그 가치를 보다 효과적으로 전달할 수 있는 방안에 대해 고민하는 것이 중요해 보입니다.
슬픈 진실과 교훈
이번 레드닷 실험을 통해 우리가 맞닥뜨린 다소 슬픈 진실은, 전체 앱 사용자가 10% 가량 증가했음에도 기록탭 사용자 수는 정체되어 있었다는 점입니다. 이는 기록탭의 존재를 알리는 것 자체로는 부족하며, 사용자들이 실제로 이를 활용할 만한 매력적인 경험과 기능을 제공하는 것이 무엇보다 중요하다는 사실을 시사합니다. 즉, 사용자를 기록탭으로 유도하는 것도 중요하지만, 정작 사용 방법이나 필요한 기능이 충분치 않다면 유저들은 오래 남지 않을 것입니다.
결론
결론적으로 레드닷을 통해 기록탭으로의 유입은 어느 정도 이끌어낼 수 있었지만, 이것이 곧바로 지속적인 사용으로 이어지지는 않았습니다. 오히려 이번 실험을 통해 우리는 사용자 경험 설계와 기능 개선이 무엇보다 중요하다는 교훈을 얻을 수 있었습니다. 앞으로는 사용자들의 니즈를 보다 깊이 있게 파악하고, 이를 바탕으로 기록탭을 지속적으로 개선해 나가는 데 주력하겠습니다.

]]></description><link>https://w0nder.land/posts/3-%EB%A0%88%EB%93%9C%EB%8B%B7(Red%20Dot)%EC%9C%BC%EB%A1%9C%20%EA%B8%B0%EB%A1%9D%ED%83%AD%20%EC%9D%B8%EC%A7%80%20%EC%8B%9C%ED%82%A4%EA%B8%B0</link><guid isPermaLink="false">3</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Mon, 06 May 2024 09:00:00 GMT</pubDate></item><item><title><![CDATA[ShowYourTime 앱 트래픽 10배 증가 사례: 간단한 ASO 전략으로 성공하기]]></title><description><![CDATA[
ASO 를 적용하고 앱스토어 순위 199위 등극!
현대 디지털 시대에 모바일 앱 시장은 전례 없는 성장세를 보이고 있습니다. Google Play 스토어와 Apple의 App Store에는 수백만 개의 앱이 존재하며, 사용자들의 관심을 얻기 위한 경쟁은 이전보다 더욱 치열해졌습니다. 이런 배경 속에서, ShowYourTime 앱도 출시 초기에는 유입량이 저조한 문제에 부딪혔습니다. ShowYourTime은 사용자의 노력을 담은 인증샷을 더욱 돋보이게 만들어주는 앱입니다. 하지만 우수한 기능과 사용자 친화적 인터페이스에도 불구하고, 앱의 가시성 부족으로 많은 잠재 사용자들에게 도달하지 못했습니다. 앱을 사용해본 사용자들은 긍정적인 리뷰를 남기며 만족을 표현했으나, 하루 평균 다운로드 수는 3~4회에 그쳤습니다. 이는 분명히 아쉬운 상황이었습니다.

ShowYourTime 대한 사랑이 듬북담긴 의견
앱을 더 알릴수 있도록 해보자!
우리 팀은 ShowYourTime 앱의 초기 다운로드 수 부진을 해결하기 위해 App Store Optimization (ASO) 전략을 도입하기로 결정했습니다. ASO는 앱 스토어 내 가시성을 높이고, 검색 결과에서의 상위 랭킹을 통해 다운로드 수를 증가시키는 과정입니다. 복잡한 데이터 분석보다는 직관적인 개선에 중점을 두었습니다.
첫 번째 조치로, '타임스탬프'라는 키워드를 앱 이름에 추가하여 앱의 핵심 기능을 강조했습니다. 이는 사용자가 검색할 때 자주 사용할 법한 키워드를 포함시켜 검색 가능성을 높이려고 했습니다.
앱 설명에서는 사용자가 자연스럽게 사용할 키워드를 통합해 최적화했습니다. 식단 인증, 운동 인증, 기상 인증, 미라클 모닝 등의 추가 키워드도 포함해 다양한 사용자의 검색 의도를 포괄하고자 했습니다. 이러한 접근은 사용자 중심의 관점에서 앱이 어떤 문제를 해결해줄 수 있는지 명확히 했습니다.
앱 스토어 이미지 최적화에서는 첫 번째 스크린샷에 앱의 주요 장점과 기능을 시각적으로 설명하는 이미지를 배치해, 사용자가 앱 페이지를 방문했을 때 앱이 제공하는 가치를 즉각 이해할 수 있도록 했습니다. 이 방법은 사용자가 앱의 주요 기능을 쉽게 파악하고, 다운로드로 이어지도록 유도하려고 했습니다.
이러한 전략의 효과는 놀라웠습니다. ShowYourTime 앱의 다운로드 수는 기대를 크게 초과하는 10배 증가를 기록했습니다.
어떤 부분에서 효과가 있었을까?

검색 목록 노출 수

앱 상세 페이지 접근 수

앱 다운로드 수

검색 목록에서 노출되고 다운로드까지 이어진 전환율
ASO 전략을 개선한 후, 앱스토어의 주요 지표들에 대해 분석해 보았습니다.
분석 결과, 검색 페이지 노출(Impression)이 증가하였으며, 이는 앱 상세 페이지(Product Page View) 방문과 첫 다운로드(First Time Download) 수 증가로 연결되었습니다. 특히 중요한 점은, 이러한 지표들이 비슷한 비율로 증가했다는 것입니다. 이는 앱스토어 검색 목록에서의 높은 노출이 다운로드 수 증가에 얼마나 많은 영향을 주는지 알 수 있었습니다.
또한, 앱 상세 페이지 방문 횟수와 다운로드 횟수가 유사한 수치를 보였습니다. 이는 사용자들이 앱의 상세 페이지에 도달하면 대부분 앱을 다운로드한다는 것을 의미했습니다. 즉, 상세 페이지로의 유입이 성공적으로 이루어지면, 이는 곧 신규 사용자 확보로 바로 연결된다는 것입니다. 이로 인해 상세 페이지 자체의 구성은 적절하게 되어 있어서 다운로드의 전환율이 매우 높음을 알 수 있었습니다.
그러나 전체 전환율(Conversion Rate)은 ASO 개선 이전과 비교했을 때 변화가 없이 유지되었습니다. 검색 결과에서 상품 페이지로의 전환 과정에 개선이 필요해 보였습니다.
마무리
ShowYourTime 앱에 적용한 ASO 전략은 앱의 다운로드 수를 기존 대비 10배 증가시키는 인상적인 결과를 가져왔습니다. ASO가 모바일 앱 성공에 결정적인 역할을 할 수 있음을 보여주었습니다. 특히, 앱 이름과 설명에 키워드를 적절히 포함시키고, 앱 스토어의 첫 이미지를 최적화하는 것이 검색 노출율을 높이는 데 매우 효과적임을 확인했습니다.
앞으로는 검색 페이지에서 우리 앱의 노출 빈도를 지속적으로 증가시키고, 노출이 성공적으로 이루어졌을 때 사용자가 앱의 상세 페이지로 이동하도록 유도하는 전략을 강화하는 데 집중할 예정입니다.

]]></description><link>https://w0nder.land/posts/2-ShowYourTime%20%EC%95%B1%20%ED%8A%B8%EB%9E%98%ED%94%BD%2010%EB%B0%B0%20%EC%A6%9D%EA%B0%80%20%EC%82%AC%EB%A1%80%3A%20%EA%B0%84%EB%8B%A8%ED%95%9C%20ASO%20%EC%A0%84%EB%9E%B5%EC%9C%BC%EB%A1%9C%20%EC%84%B1%EA%B3%B5%ED%95%98%EA%B8%B0</link><guid isPermaLink="false">2</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Sat, 02 Mar 2024 22:10:00 GMT</pubDate></item><item><title><![CDATA[ShowYourTime 개발후기]]></title><description><![CDATA[

시작하며
fi-workers에서는 2023년 하반기에 ShowYourTime 앱을 만들었습니다. ShowYourTime 은 사진에 타임스탬프를 찍어주는 앱입니다. 앱에 대한 더 자세한 스토리는 fi-workers 의 프로덕트 디자이너이신 나나산 님이 쓰신 글을 보시면 좋습니다.


어떤 프로젝트를 진행할 때, 저는 중요한 내적인 목표 하나를 설정합니다. 이는 제가 이론으로만 공부했던 내용을 실제 상황에 적용하여, 지식과 경험을 연결하는 데 도움이 됩니다.
이번 프로젝트에서의 목표는 "빠른 출시"였습니다. 일반적으로 사용자는 원하는 기능을 명확히 인지하지 못합니다. 제공된 기능이 자신의 원래 의도와 부합하는지 여부만을 파악할 수 있습니다. 간단한 컨셉 제시 후, 구체적인 사항이 확정되기 전에 프로토타입을 통해 사용자가 실제 원하는 방향을 찾을 수 있다고 생각합니다.
이번에는 개밥먹기와 비슷하게 제품의 메이커와 실제 사용자가 같았기 때문에, 프로토타입으로 컨셉이 구현된 상태를 기반으로 신속하게 피드백을 주고 받을 수 있었습니다. 이러한 장점은 "빠른 출시" 목표를 달성하는데 결정적인 역할을 했습니다. 이렇게 빠른 피드백 루프를 통해, 사용자의 필요와 기대를 정확히 파악하고, 그에 맞춰 제품을 빠르고 효율적으로 개발할 수 있었습니다.
개발 과정에서의 고민
빠른 출시를 달성하기 위해 이번 프로젝트에서 가장 중요했던 요소는 개발 생산성이었습니다. 주로 주말에만 앱 개발과 배포를 진행하는 등 시간이 매우 부족했기 때문입니다. 이러한 시간적 제약으로 인해 생산성을 위해 몇 가지 후회가 남는 설계를 하기도 했습니다. 또한, 개발 시간의 부족으로 인해 사용자 경험(UX)과 성능 측면에서 어느 정도 타협을 할 수밖에 없었습니다.
사진에 타임스탬프 넣기

이 프로젝트에서 가장 큰 도전은 사진에 타임스탬프를 추가하는 기능이었습니다. 사진에 시간 텍스트를 추가하기 위해 ImageMagic이나 다른 라이브러리의 사용을 고려하였으나, 스타일링에 제한이 많고 React Native에서 ImageMagic 설정에 시간이 소요될것 같았습니다.
이에 대한 해결책으로, react-native-view-shot 라이브러리를 사용하여 스타일링된 컴포넌트를 사진이나 카메라 영상 위에 배치하고, 이 상태로 스크린샷을 찍어 이미지를 생성하는 방법을 선택했습니다. 이 방식은 화면 크기에 따라 해상도가 결정되는 문제가 있었는데, 이를 해결하기 위해 이미지 사이즈와 동일한 View 컴포넌트를 생성하고 화면에 보이지 않는 곳에 배치했습니다.
{ position: "absolute",  top: -99999, left: -99999 }

처음에는 고해상도 이미지가 좋다고 생각하여 크게 설정했으나, 결과물의 용량이 커진다는 사용자 의견을 받고 원본 사진 사이즈에 맞추어 스크린샷을 찍도록 변경했습니다.
그러나 스크린샷을 사용하는 방법은 UI 사이클에 영향을 받아 시점 문제로 인한 크래시나 잘못된 스크린샷이 찍히는 문제가 발생했습니다. 여러 미봉책으로 처리하긴 했지만, 이는 실제 이미지 파일 조작을 통해 개선되어야 할 부분으로, 적용이 된다면 UI를 그리는 시간을 절약하면서 성능 향상에도 도움이 될 것 같습니다.
앨범에서 사진 불러오기

앨범에서 사진을 불러오는 과정은 단순하지 않았습니다. Android에서는 로컬 저장된 사진들이 신속하게 로드되었지만, iOS에서는 iCloud에 저장된 사진들을 네트워크를 통해 다운로드하는 데 시간이 오래 걸렸습니다. 이 과정에서 네트워크 비용이 발생했고, 인터넷 연결이 없으면 사진이 제대로 로드되지 않는 문제가 있었습니다.
또한, 사진 목록에서 가상스크롤을 사용해 실제 관리하는 컴포넌트의 개수를 최적화 하더라도, 원본 크기의 사진을 UI에 로드하면 메모리 문제가 발생해, 썸네일 크기로 사진을 축소하여 로드해야 했습니다. 이 썸네일 생성 과정은 CPU 연산을 많이 필요로 해 배터리 소모가 크게 되었으며, 썸네일을 로컬에 캐싱하면 저장 공간을 많이 차지하는 문제도 있었습니다.
인스타그램 같은 앱들이 자체적으로 구현한 PhotoPicker를 보며 그들이 해결한 이러한 문제점들을 직접 다뤄보고 싶은 생각이 들었습니다. 하지만, 비슷한 기능을 제공하는 다른 라이브러리를 분석하거나 여러 시도를 해볼 시간이 부족했습니다.
결국, 순수한 React Native로는 한계가 있음을 인지하고, 각 운영체제에서 제공하는 PhotoPicker를 사용하기로 결정했습니다.
프레임 스와이프

UI 디자인에서 Opacity와 Shadow 효과는 시각적 깊이와 계층 구조를 나타내는 데 중요한 역할을 합니다. 이러한 효과는 사용자가 인터페이스를 이해하고 상호 작용하는 방법에 대한 시각적 단서를 제공합니다. 예를 들어, Google의 머티리얼 디자인에서는 객체와 그 배경 사이의 거리를 나타내는 그림자의 크기와 흐림을 조절하여 차원감을 부여합니다.
그러나 이러한 효과는 성능에 부담을 줄 수 있습니다. 렌더링 과정에서 일반적으로 맨 위의 컴포넌트부터 그리고, 이미 그려진 영역 뒤의 컴포넌트는 무시합니다. 하지만 불투명도와 그림자 효과는 상위 컴포넌트를 그릴 때 모든 하위 컴포넌트에 영향을 주므로 더 많은 컴포넌트를 확인해야 합니다. 또한, 이러한 효과는 모든 픽셀에 대해 별도의 연산을 요구하기 때문에 추가적인 부하를 발생시킬 수 있습니다. 이러한 효과의 성능 영향은 플랫폼에 따라 다를 수 있습니다. iOS는 이러한 효과의 처리에 있어 상대적으로 더 나은 성능을 보일 수 있지만, Android에서는 더 심각한 성능 문제가 발생할 수 있습니다.
ShowYourTime 에서는 미려한 결과물을 위해 Opacity와 Shadow 효과를 대량으로 사용했습니다. 이러한 디자인 선택이 시각적으로는 매력적이지만 성능 문제를 야기할 수 있습니다. ScrollSnap 기능과 두 개의 스와이프 컴포넌트의 스크롤 위치를 동기화하는 과정, 그리고 컴포넌트 크기의 Transform을 수행할 때 이러한 성능 문제가 두드러졌습니다.
특히 스와이프 동작 중 두 컴포넌트의 스크롤 위치를 동기화하는 과정에서 프레임 끊김 문제가 발생했습니다. 이 문제를 해결하기 위해 여러 전략을 사용했습니다.
첫째, 컴포넌트 캐싱을 통해 반복적으로 렌더링되는 컴포넌트의 재사용을 최적화함으로써 렌더링 성능을 향상시켰습니다.
둘째, 리소스 관리 측면에서 SVG를 사용하여 벡터로 관리하고 있었지만, 로고와 같이 변하지 않는 영역을 온디맨드로 이미지화하여 불필요한 렌더링 작업을 줄였습니다.
셋째, 이벤트 처리에서는 throttle과 debounce 기법을 적용해 이벤트의 과도한 발생을 조절하고, 스크롤과 같은 연속적인 이벤트에서 성능 저하를 방지했습니다.
마지막으로, ScrollSnap 기능을 자체적으로 구현함으로써 더 효율적인 스크롤 관리가 가능해졌고, 이를 통해 프레임 끊김 문제를 해결했습니다.
이 실시간 스크롤 위치 동기화는 성능 문제로 인해 앱 초기 버전에서는 제공하지 못했습니다. 처음에는 각 컴포넌트에서 변경이 이루어지고 나면 비동기로 동기화를 시켜주었습니다. 이 기능은 앱에서 중요한 UX 를 담당한다고 판단했기 때문에 시간을 들여서 개선했습니다.
회고
처음엔 iOS만을 대상으로 출시했지만, 향후 Android 플랫폼 지원의 가능성을 염두에 두었습니다. 개발자 한명으로 모든 작업을 수행하기 어려웠기에, 이러한 요구사항을 충족시키기 위해 크로스 플랫폼 개발이 필수적이었습니다. Flutter와 고민을 했지만 React와의 친숙함을 고려하여, React Native를 선택했습니다.
React Native는 React에 익숙한 상태에서 개발 생산성이 매우 뛰어났습니다. 실제로, 첫 앱 릴리즈는 불과 24시간 만에 완료되었으며, 이후로도 1~2주마다 지속적인 릴리즈 주기를 유지할 수 있었습니다. 그러나 React Native를 사용하여 카메라와 카메라롤 같은 네이티브 기능을 조작하려 할 때 예상치 못한 어려움이 발생했고, 라이브러리 지원 역시 품질 면에서 만족스럽지 못했습니다. 그로 인해 여기에 모두 기술하지 못한, 제공되지 못했던 기능들이 많았습니다. 더불어, 약간의 잘못된 구현으로도 앱의 성능이 저하될 수 있다는 점을 경험했습니다. 앱의 최적화 작업에는 개발 과정 자체보다 더 많은 시간을 할애해야 했습니다.
이러한 점들을 고려해 볼 때, Flutter로의 전환은 좋은 대안이었을 수도 있습니다. 비록 Flutter를 통한 개발 경험이 비즈니스 수준까지는 아니었지만, 간단한 토이 프로젝트를 통해 경험한 바로는 Flutter가 제공하는 기본 도구의 품질이 우수하여, React Native에서 겪었던 문제들을 보다 쉽게 해결할 수 있지 않았을까 합니다. 그래서 다음 프로젝트에서는 기회가 된다면 Flutter 로 개발을 해보려고 합니다.
#개발 #ReactNative #RN #카메라 #타임스탬프 #ShowYourTime
]]></description><link>https://w0nder.land/posts/1-ShowYourTime%20%EA%B0%9C%EB%B0%9C%ED%9B%84%EA%B8%B0</link><guid isPermaLink="false">1</guid><dc:creator><![CDATA[w0nder]]></dc:creator><pubDate>Mon, 01 Jan 2024 09:00:00 GMT</pubDate></item></channel></rss>