PROJ.ACT

최신 아티클 — 2026.03.17

AI 에이전트 팀으로 SEO 블로그 쓰는 법: 아이디에이션부터 발행까지

"AI로 블로그 글 쓴다고요? 그럼 다 똑같은 글 아닌가요?" 이 말, 한 번쯤 들어봤거나 속으로 생각해본 적 있으실 겁니다. AI가 써준 글은 뭔가 매끈하긴 한데 영혼이 없다는 느낌. 쓴 사람의 목소리가 안 들린다는 느낌. 그 걱정, 저도 처음엔 똑같이 했어요. 그런데 직접 AI 에이전트 팀으로 블로그 워크플로우를 만들어보고 나서 생각이 바뀌었습니다. 핵심은 AI가 글을 대신 써주는 게 아니라는 것이었거든요. 제가 발견한 건 조금 달랐습니다. 어떻게 에이전트를 구성했고, 어떤 과정을 거쳐 글이 만들어지는지 하나씩 풀어볼게요. 아이디에이션 대화로 시작하기 바이브코딩을 하다 보면 자연스럽게 Claude 같은 AI와 대화하면서 코드를 짜게 됩니다. 블로그도 마찬가지더라고요. 글을 "생성"해달라고 요청하는 게 아니라, 글의 방향을 함께 고민하는 대화를 먼저 하는 겁니다. 아이디에이션 에이전트와 나누는 대화가 바로 그런 과정입니다. "이 주제에 대해 직접 겪은 에피소드가 있나요?" "다른 글들과 차별화할 수 있는 본인만의 시각이 뭔가요?" "독자에게 가장 전하고 싶은 메시지 한 가지는요?" 이 질문들에 답하다 보면 머릿속에 흩어져 있던 생각들이 정리됩니다. 대화가 끝날 때쯤엔 주제가 뾰족해지고, 글의 핵심 메시지가 잡혀 있어요. 그리고 그 대화에서 나온 제 생각들이 고스란히 글에 녹아드니까 오리지널리티가 유지됩니다. AI가 생성한 글이 아니라, AI와 함께 만든 내 글인 거죠. 에이전트팀 구성 소개 이 워크플로우는 네 개의 에이전트가 역할을 나눠 맡는 구조입니다. 각자 잘하는 일에만 집중하게 하면 결과물 품질이 확실히 올라가더라고요. ideation 에이전트 : 편집장 역할 사용자와 1:1 대화를 나누며 글감을 발굴합니다. 단순히 주제를 제안하는 게 아니라 경험과 시각을 끌어내는 질문을 던지죠. 대화하면서 keyword-researcher 에이전트에게 키워드 가능성도 실시간으로 검증합니다. 주제가 확정되면 ideation.md에 대화 내용과 사용자 시각을 저장합니다. keyword-researcher 에이전트 : SEO 분석가 Google Ads Keyword Planner MCP와 연동해서 키워드 데이터를 가져옵니다. 검색량, 경쟁도, KGR(Keyword Golden Ratio)을 분석해서 실제로 노출될 가능성이 있는 키워드를 선별하죠. Claude MCP 블로그 세팅에서 이 에이전트가 가장 실용적인 차이를 만들어냅니다. 결과는 keywords.md에 저장됩니다. content-writer 에이전트 : 글쓰기 담당 ideation.md와 keywords.md를 읽고 글을 씁니다. 사용자가 아이디에이션 대화에서 공유한 경험담과 시각을 반드시 글에 반영하도록 설계되어 있어요. Nano Banana 2 MCP로 이미지도 함께 생성합니다. seo-reviewer 에이전트 : 품질 검수 완성된 글을 SEO 관점에서 점검합니다. 키워드 밀도, 제목 길이, 메타 설명, 이미지 alt text까지 체크리스트대로 리뷰하고 점수를 매깁니다. 7점 이상이면 승인, 미달이면 content-writer에게 수정 요청을 보냅니다. 실제 워크플로우: 아이디에이션부터 발행까지 seo-pipeline 에이전트가 전체 과정을 조율합니다. 실제로 어떻게 흘러가는지 단계별로 설명할게요. 1단계: 아이디에이션 (ideation 에이전트) 가장 먼저, 그리고 가장 중요한 단계입니다. ideation 에이전트에게 "바이브코딩 관련해서 글 써보고 싶은데"라고 꺼내면 대화가 시작됩니다. 에이전트는 일방적으로 주제 목록을 나열하는 게 아니라 질문을 던지면서 제 경험을 끌어냅니다. "최근에 AI 도구 쓰면서 아 이거 좋다 싶었던 순간이 있었어요?"처럼요. 이 대화 과정에서 주제가 구체화되고, 어떤 각도로 쓸지, 누구에게 전달하고 싶은지가 잡힙니다. 이게 나중에 글의 오리지널리티로 이어지는 핵심입니다. 2단계: 키워드 리서치 (keyword-researcher 에이전트) 주제가 잡히면 keyword-researcher가 키워드 데이터를 조사합니다. KGR이 0.25 이하인 골든 키워드를 우선 찾고, 메인 키워드와 보조 키워드 조합을 제안합니다. 이 블로그 글의 경우 "AI 에이전트 블로그 자동화"가 메인 키워드로 선정됐어요. 3단계: 글 작성 + 이미지 생성 (content-writer 에이전트) content-writer는 ideation.md와 keywords.md를 읽고 글 작성을 시작합니다. SEO 구조(제목에 키워드 포함, H2/H3 소제목 배치, 메타 설명 등)를 지키면서, 동시에 아이디에이션에서 수집한 제 경험과 시각을 도입부와 본문에 녹입니다. 이미지는 Nano Banana 2 MCP로 자동 생성되어 images/ 폴더에 저장됩니다. 4단계: SEO 리뷰 (seo-reviewer 에이전트) 완성된 글을 SEO 체크리스트로 점검합니다. 리뷰 결과는 REVIEW.md에 저장되고, 수정이 필요하면 content-writer에게 피드백이 전달됩니다. 최대 2라운드 안에 승인됩니다. 5단계: 노션 퍼블리시 SEO 리뷰까지 통과하면 Notion MCP로 자동 발행됩니다. 이미지도 외부 URL로 변환해서 노션 페이지에 깔끔하게 올라갑니다. AI 에이전트 블로그 자동화, 직접 써보니 솔직히 처음엔 반신반의했습니다. "AI가 쓴 글은 다 비슷비슷하다"는 말이 계속 머릿속에 맴돌았거든요. 직접 써보니까 아이디에이션 대화에서 나온 제 생각이 글에 잘 녹아들어 있더라고요. 거기에 제 말투까지 학습시켜보니, 나의 오리지널리티가 반영된 높은 품질의 글을 훨씬 쉽게 작성할 수 있게 됐습니다. 결과물을 봐도 마찬가지예요. 제 경험담이 들어가고, 제가 강조하고 싶은 포인트가 반영되어 있으니까 AI 같은 느낌이 확실히 적습니다. 지금 읽고 계신 이 글도 대부분 이 에이전트 팀과 함께 작성한 글이에요. 바이브코딩으로 Claude Code를 쓰면서 개발 속도가 빨라진 것처럼, 블로그도 AI 에이전트 팀을 쓰면서 퀄리티는 유지하되 속도가 붙는 느낌입니다. 마무리: AI가 대신 쓰는 게 아니라, 함께 만드는 것 AI 에이전트 팀과 함께 일한다는 건 결국 나의 생각과 결정들이 핵심이라는 뜻입니다. 어떤 주제로 쓸지, 어떤 각도에서 풀어갈지, 무엇을 강조할지, 이 모든 판단은 여전히 사람의 몫이에요. 에이전트들은 그 판단을 실행하고 구조화하는 역할을 할 뿐입니다. 블로그 글쓰기뿐 아니라 어떤 작업이든 AI 에이전트 팀을 구성할 때 이 원칙은 같다고 생각해요. 내 생각이 명확할수록, 에이전트 팀의 결과물도 좋아집니다. 나만의 에이전트 팀을 만들어보고 싶다면, 먼저 AI와 최대한 많은 대화를 나눠보세요. 내가 원하는 게 뭔지, 어떤 과정이 필요한지를 대화하면서 정리하는 겁니다. 그게 충분히 정리됐다면 "이걸 도와줄 에이전트 팀을 만들어줘"라고 요청해보세요. 생각보다 금방 나만의 워크플로우가 만들어질 겁니다.

2026.03.17·4분 읽기·아티클

바이브코딩, 나만 어려워?

코딩 없이 앱 만들기, 정말 되는 걸까? 나는 디자이너 출신이다. 웹 코딩을 10년 했고, 최근에는 바이브 코딩으로 모바일 앱까지 직접 만들었다. 그 과정에서 확신하게 된 것이 하나 있다. "바이브 코딩을 잘하려면 코딩을 어느 정도는 알아야 한다." 간단한 건 코딩 몰라도 된다. 랜딩 페이지 하나, 간단한 계산기 정도는 자연어만으로 충분하다. 하지만 데이터베이스를 붙이고, 로그인을 구현하고, 결제까지 연결하려면 이야기가 완전히 달라진다. AI가 제대로 고쳤는지, 확인할 수 없는 불안감 자연어로 요청하면 AI가 뭘 어떻게 바꿨는지 확인하기 어렵다. 건드리면 안 되는 로직을 건드렸는지, 기존에 만들어둔 기능이 망가지진 않았는지. 코드를 읽을 줄 모르면 매번 직접 하나하나 테스트하는 수밖에 없다. 코드를 보고 로직을 파악할 줄 알면 이런 실수를 훨씬 줄일 수 있다. 제품이 커져도 퀄리티를 유지하는 핵심 능력이다. 실제로 Veracode 분석에 따르면 AI가 생성한 코드의 45%에서 보안 결함이 발견됐고, 보안 취약점은 사람이 작성한 코드보다 2.74배 높았다. 아마존도 AI 코딩 도입 후 일주일에 크리티컬 사고 4건을 기록했다. 코드를 검증할 줄 모르면 이런 문제를 그냥 넘기게 된다. AI 코딩 한계는 결국 사용하는 사람의 지식에 달려 있다. 코드를 알면 AI에게 정확한 지시를 내릴 수 있다 코드를 이해하는 수준으로 알아두면 바이브코딩 실력이 확 달라진다. 예를 들어 UI를 수정하고 싶을 때, "하단 확인 버튼의 모서리를 좀 더 부드럽게 둥글려줘"라고 말하는 대신, 해당 코드 블록을 멘션하면서 **"이 버튼의 border-radius를 12px로 변경해줘"**라고 할 수 있다. "부드럽게"는 해석의 여지가 있다. 하지만 "12px"는 답이 하나다. 지시가 명확하면 AI가 정확히 알아듣는다. 바이브코딩 코딩 지식이 있으면 이런 소통이 자연스럽게 가능해진다. 바이브코딩 공부, 최소한 이것만은 알아두자 변수, 함수, 반복문. 코드가 어떻게 작성되어 있고 어떻게 연결되어 있는지. 실행 순서가 어떻게 되는지는 파악할 수 있어야 한다. 전부 외울 필요 없다. 코드를 읽고 "이 함수가 저 데이터를 받아서 처리하는구나" 정도만 이해하면 충분하다. 이 정도만 알아도 AI가 작성한 코드에서 문제를 발견하거나, 수정 방향을 잡는 게 훨씬 수월해진다. 프린트문 하나면 디버깅이 달라진다 AI에게 "프린트문을 활용해 로그를 자세히 남겨달라"고 요청해보자. 디버깅할 때 정말 큰 도움을 받을 수 있다. 어디서 에러가 나는지, 어떤 값이 넘어오는지 로그로 바로 확인할 수 있다. 코드를 완전히 이해하지 못해도 문제 지점을 좁혀나갈 수 있다. 코딩 없이 앱 만들기를 시도하는 사람이라면 이 방법부터 익혀두자. 코드를 몰라도 쓸 수 있는 가장 강력한 디버깅 도구다. 점진적으로 배우면 된다 한꺼번에 다 배울 필요 없다. 처음엔 HTML 태그 이름만. 그다음엔 CSS 속성. 그다음엔 JavaScript 변수와 함수. AI가 작성한 코드를 읽으며 하나씩 배워가면 된다. 계속 자연어로만 하려다 보면 지치기 마련이다. 같은 요청을 세 번, 네 번 반복하면서 원하는 결과가 안 나올 때의 피로감. 코드 용어를 조금만 알아도 이 과정이 훨씬 줄어든다. 그것이 바이브코딩 공부의 시작이다. 결론 바이브 코딩은 강력하다. 하지만 코딩 지식 없이는 AI 코딩 한계에 금방 부딪힌다. "코드를 읽을 줄 알면, 바이브 코딩은 10배 더 강력해진다." 지금 당장 AI가 작성한 코드를 한 줄씩 읽어보자. 모르는 부분은 AI에게 설명해달라고 하면 된다. 그것이 바이브코딩 실력을 키우는 첫걸음이다.

2026.03.17·2분 읽기·아티클

잡부 디자이너가 살아남는다

UX/UI 디자이너로 입사했는데 배너 만들고, PPT 디자인하고, 콘텐츠 제작까지 하고 있다면. "나는 디자이너인데 왜 이런 일까지 해야 하지?" 이런 불만, 한 번쯤은 가져봤을 것이다. 잡부 디자이너라는 말이 자조 섞인 표현으로 쓰이는 이유다. 그러나 이제 잡부의 세상이 왔다. AI 시대에 디자이너가 살아남으려면, 오히려 그 잡부력이 핵심 경쟁력이 된다. 팀은 줄어들고, 할 일은 늘어난다 AI가 생산성을 끌어올리면 조직 규모는 자연스럽게 작아진다. 스타트업이든 대기업이든 비용 최적화는 항상 최우선 과제다. AI로 같은 아웃풋을 더 적은 인원으로 낼 수 있다면, 회사는 당연히 그 방향으로 움직인다. 이건 예측이 아니라 이미 일어나고 있는 일이다. 결과적으로 각 팀에 디자이너 한두 명으로 충분한 시대가 온다. 5명이 하던 일을 1~2명이 해내야 하는 구조다. 그런데 여기서 오해하면 안 된다. 일이 줄어드는 게 아니다. 한 명이 관리해야 하는 업무 범위가 훨씬 넓어지는 것이다. 디자인뿐 아니라 기획, 마케팅, 콘텐츠, 심지어 간단한 개발까지. 조직이 작아질수록 한 사람이 커버해야 하는 영역은 넓어진다. 결국 디자이너 생존의 조건이 바뀌고 있다. "다 해야 한다"는 말의 진짜 의미 나는 회사에서 필요한 내부 도구를 직접 만든 적이 있다. 개발팀에 요청하기 애매한 규모의 도구들, 콘텐츠 자동화, 마케팅 소재 제작까지. 처음에는 어쩌다 보니 하게 된 일들이었는데, 지금은 이게 오히려 강점이 됐다. 바이브코딩 덕분이다. AI 코딩 도구를 쓰기 시작하면서 "이건 개발자한테 맡겨야지"라는 선이 사라졌다. 내가 원하는 걸 직접 만들 수 있게 됐다. 이게 얼마나 큰 변화인지는 직접 써본 사람만 안다. "다 해야 한다"는 말은 단순히 힘들다는 뜻이 아니다. 컨트롤타워가 되어야 한다는 뜻이다. 디자인 언어를 이해하면서 개발과 마케팅도 조율할 수 있는 사람. 이런 사람이 조직에서 가장 살아남기 어렵지 않은 포지션이 된다. 회사에서 못 살아남으면 회사에서 살아남지 못하면 취업도 더 어려워진다. 당연한 말 같지만, 현실이 그렇다. 수요는 줄고 공급은 그대로거나 늘어난다. 포트폴리오가 아무리 좋아도 "이것만 할 수 있는 사람"이라면 채용 우선순위에서 밀린다. AI 시대에 디자이너로서 경쟁력을 갖추려면 디자인 외의 무기가 있어야 한다. 결국 도달하는 결론은 하나다. 나만의 것을 만들어야 한다. 누군가의 팀에 속하지 않아도 혼자 돌릴 수 있는 나만의 프로덕트, 나만의 사업. 잡부 디자이너가 가야 할 방향 나만의 것을 가지고 사업화하는 것. 이게 잡부 디자이너가 가야 할 방향이라고 생각한다. 제품을 직접 만들고, 마케팅하고, 콘텐츠로 알리고. 이 모든 걸 혼자 또는 소수로 돌릴 수 있어야 한다. 거창한 팀이 없어도 된다. 오히려 작을수록 빠르게 움직일 수 있다. 이게 가능해진 이유가 바이브코딩이다. 디자이너가 앱을 만들고, 콘텐츠 파이프라인을 자동화하고, 마케팅 도구를 직접 구축할 수 있는 시대가 됐다. 없던 가능성이 열린 게 아니라, 원래 있었지만 진입 장벽이 너무 높았던 영역이 낮아진 것이다. 지금 당장 해야 할 것 디자인 실력은 기본이다. 거기에 더해야 한다. 마케팅 감각을 키워라 : 내가 만든 것을 어떻게 알릴지 생각하는 습관 개발 기초를 익혀라 : 바이브코딩 도구 하나쯤은 지금 당장 써봐야 한다 나만의 프로젝트를 시작해라 : 회사 일과 별개로, 내 이름으로 만드는 무언가 "언젠가 해야지"가 아니다. AI가 생산성을 올려주는 속도만큼, 조직 규모가 줄어드는 속도도 빠르다. 잡부 디자이너가 살아남는 시대다. 바이브코딩이라는 도구가 있으니, 지금 시작해보자.

2026.03.17·2분 읽기·아티클

디자이너가 바이브코딩 강의를 했더니, 결과는?

디자이너가 바이브코딩 코스를 하면 반응이 어떨까? 12명의 수강생을 모시고 최근 4주간. 매 주 3시간씩 진행했던 "바입빌딩 1기"를 마무리하며 회고를 작성해본다. 원래 강의할 생각은 없었다.. 사시 처음에는 강의를 할 생각은 없었다. 직접 만든 독서 기록앱 Quollect로 작게나마 수익을 얻게 되었고, 이 경험을 지난 7월 12일, 프롬이라는 디자이너 커뮤니티에서 공유하게 되었다. 프롬 디자이너 커뮤니티 오프라인 첫 발표! 약 40여 명의 디자이너분들이 들으러 와주셨는데 끝나고 정말 많은 관심과 질문을 주셨다. 뒷풀이 자리에서도 바이브 코딩으로 제품 만드는 것에 대한 질문을 엄청 받았다. 그날 밤 집에 오면서, 더 많은 디자이너들에게 이 이야기를 소개해보고 싶었다. 자료를 정말 열심히 만든게 아깝기도 했고 😂 그래서 개인적으로 같은 내용이되, 그날 받은 질문들을 고려해 내용을 보완하고 이번에는 웨비나로 한 번 더 발표를 할 계획을 세우고 웨비나를 소개하는 랜딩페이지를 만든 뒤, 디자이너 커뮤니티 몇 군데에 공유했다. [웨비나 소개 페이지] 디자이너 혼자 바이브 코딩으로 앱 제작부터 수익까지! 목표 날짜는 7월 30일이었고, 바이브코딩 관련된 질문을 자유롭게 주고 받을 수 있도록 별도의 오픈 카톡방도 만들어서 공유했다. 이름은 바입 코딩 클럽, 아래 링크를 통해 입장할 수 있다. 바입코딩클럽 오픈 카톡방 두 건의 유료 강연 요청과 코스를 해봐야겠다는 생각 해당 링크를 뿌려놓고 나니 며칠 뒤 AI 커뮤니티를 운영하시는 리더 두 분이 각 커뮤니티를 위해 동일한 내용의 발표를 해줄 수 있냐고 요청을 해오셨다. 하나는 7월 19일, 다른 하나는 7월 22일. 살다보니 내가 돈을 받고 강연을 할 날이 오다니, 조금 실감나진 않았지만 두 건의 발표를 하면서 더 많은 질문을 받았고, 직접 만든 오픈 카톡방에도 점점 더 많은 사람들이 들어와 300명이 넘었다. 많은 분들이 구체적인 내용을 최대한 공유드렸음에도 여전히 "어떻게"를 질문하셨고, 이야기로 전하는 것을 넘어 바이브 코딩으로 제품을 만드는 과정을 함께하는 코스를 만들어봐야겠다는 생각까지 이르렀다. 지난 10년간 코딩하는 디자이너로서 제품을 만들어오며 공부했던 모든 것을 압축해, 바이브코딩으로 제품을 만드는 기본 사이클을 직접 경험시켜주는 그런 강의. 나의 목표는 강의를 듣고 나면 "이제 나도 바이브 코딩으로 내 제품을 만들 수 있겠다"는 자신감을 심어드리는 것이다. 그리고 그 강의를 7월 30일, 마지막 웨비나에서 공개하고 강의는 8월 9일에 시작해 4주간 매 주 3시간씩 진행하기로 했다. 강의 커리큘럼 준비와 공개, 그리고 12석 매진 7월 30일, 프롬 디자이너와 함께 웨비나를 진행했고 프롬 디자이너 웨비나 계정 제약상 100명 인원제한이 있어 100분과 함께 웨비나를 시작했고, 마지막에 강의를 공개했다. 강의 가격 책정에 많은 고민이 있었지만 여러 고민 끝에 40만원으로 책정했다. [바입빌딩] 바이브코딩으로 앱 제작부터 수익까지! 적지 않은 금액이라 과연 12명이 다 채워질까 싶었는데 강의 전날 8월 8일, 남은 두 자리가 모두 채워져 총 12 자리가 만석 상태로 8월 9일 강의를 시작할 수 있었다. 4주 동안 무엇을 다뤘나? [1주차] 서비스 구성 요소, 코딩 기본의 이해, 그리고 바로 바이브코딩 실습 : 120 슬라이드 첫 주차에는 전반적인 서비스 개발에 필요한 요소들과 각 요소들의 관계를 알아보고, 코드를 어느정도 읽을 수 있는 능력을 기르기 위한 코딩의 기본 개념들을 학습한 뒤 바로 바이브 코딩으로 Todo 앱을 제작했다. 이날 준비한 슬라이드는 120장이었다 😂 서비스 구조의 이해 위 이미지는 직접 정리한 서비스 개발에 필요한 요소와 관계도다. 바이브코딩으로 코딩 자체에 대한 장벽은 낮아졌지만 내가 원하는 서비스를 만들기 위해 무엇이 필요한지 모르면 어떤 질문, 어떤 요청을 해야할지 알기 어렵다. 따라서 나는 전체적인 구조를 알고 진행하는 것이 매우 중요하다고 생각해서 이 장표를 만들었고, 강의를 진행하면서 종종 이 장표를 다시 들고와 우리가 어떤 부분을 건드리고 있는 것인지 설명하며 진행했다. 나중에 본인의 서비스를 만들더라도 이를 지도처럼 사용해주신다면 더할 나위없이 보람찰 것 같다. 단도직입, 바이브코딩 실습! 바이브코딩을 배우러 왔으니 첫 날부터 뭔가 직접 구현해보는 경험이 동기부여에 좋을거라고 생각해서 첫날부터 Todo 앱을 만드는 실습을 진행했다. 시간과 좀 더 매끄러운 코스 진행을 위해 디자인은 미리 준비해두었고, 첫 날 환경설정으로 많은 분들이 헤메시기도 했지만 강의 끝나고 다같이 카페로 이동해 도와드린 결과 대부분 화면 구현을 하실 수 있었다. [2주차] 앱 기획 과정과 수요 확인, Github 과 Supabase Google 로그인 구현 : 149 슬라이드 1주차 수업에서 내 생각보다 환경 설정과 코딩에 대한 기본 개념을 많이 힘들어하셨다. 환경 설정이 힘들거라는 얘기를 듣긴 했지만 내 상상 이상이었고, 한 분씩 봐드리다보니 시간이 생각보다 많이 소요됐다. 2주차 강의때 부터는 본인이 각자 만들고 싶은 서비스를 만드는 방식으로 진행하려고 했었는데 그것 보다 간단한 것부터 기본 개념을 더 확실히 익히는 것이 중요한 상황이라고 판단됐다. 그래서 기획에 대한 내용은 이론으로 진행하고 본인 서비스 기획은 별도로 진행하는 것으로 양해를 구한 뒤, 4주차 까지 원래 다루고자 했던 내용들을 모두 Todo 앱에 적용하는 방향으로 강의를 재구성했다. 그래서 이 날은 프로젝트 관리를 위한 Github 사용법을 다루고, 이제는 필수인 간편 로그인을 구현하는 실습을 위주로 진행했다. 2주차 슬라이드는 149장이었다 😂 Github이 무엇인지, 어떻게 작동하는 것인지, 그리고 왜 필요한지에 대해 다루고 실제 Github으로 Todo 프로젝트를 관리하는 실습을 진행했다. Supabase에서 Google 로그인을 구현하기 위해 Google Cloud Console 을 직접 설정해보는 실습도 진행했다. Google Cloud Console의 수많은 버튼과 메뉴에 다들 조금은 버거워했지만 결국 대부분 구글 로그인까지 성공할 수 있었다. [3주차] 데이터베이스와 사용자 행동데이터, 이해와 활용 : 132 슬라이드 데이터베이스 이해와 활용 모든 서비스가 데이터베이스가 필요한 것은 아니지만 데이터베이스를 사용해야할 경우, 서비스를 직접 운영하는 관점에서는 데이터베이스의 구조를 잘 알고 있는 것이 중요하다. 그렇다면 데이터베이스의 테이블과 컬럼, 그리고 다른 테이블과 어떻게 관계 맺어 사용하는지 등을 알아야한다. 따라서 3주차에는 관계형 데이터베이스에 대한 이해를 시작으로, 실습 Todo 앱에 필요한 요소들을 고려해 테이블 컬럼을 구성하고, AI를 통해 전달받은 SQL 코드를 활용해 테이블 생성, 그리고 실제 앱 기능과 데이터베이스를 연결해 Todo 아이템 생성시 데이터베이스에 잘 추가되는 것 까지 실습을 진행했다. AI는 우리가 어떤 생각을 하는지 정확히 알지 못하기 때문에 꼭 필요하지 않은 것들도 넣어서 코드를 작성하는 경우가 많다. 간단한 프로젝트라면 문제 없겠지만, 내가 오래 끌고갈 제품이라면 직접 한 번 읽고 불필요한 것은 제거해달라고 재요청하는 것이 제품에 대한 장악력을 갖는 것에 많은 도움이 되며 개인적으로는 꼭 필요한 과정이라고 생각한다. 사용자 행동 데이터의 이해와 앰플리튜드 붙여보기 처음 바이브코딩을 하게되면 높은 확률로 사용자 행동 데이터까지 다룰 여유는 없을 것이다. 당장 기능 개발하는 것만도 버겁기 때문인데, 서비스를 운영하다보면 어느 순간에는 사용자가 내 서비스를 "잘 쓰고 있는지" 궁금할 때가 온다. DAU, MAU, 리텐션등 구글 애널리틱스만 붙여도 많은 데이터들을 볼 수 있지만, 앱에 들어와서 사용자들이 어떤 행동을 하고 있는지를 알고 싶은 때가 온다면, 그 때가 바로 이벤트 단위 트래킹이 필요한 순간이다. 서비스 개발에 아주 필수는 아니지만 강의에 넣었고, 이 부분은 과제로 내드렸다. (많은 분들이 조금 지쳐계셔서 과제 체크를 빡세게 하진 않았지만.. 몇 분은 준비한 슬라이드를 하나씩 따라하시면서 이벤트 수집에 성공하셨다!) [4주차] Admob 광고의 이해와 활용, 그리고 배포와 결제 상품 붙이기 : 256 슬라이드 😂 드디어, 바로 어제 끝난 대망의 마지막 주차 강의. 기획부터 제작까지 많은 시간과 노력을 들인 서비스가 그냥 나의 심리적 만족으로 끝나면 너무 아쉽다. 많은 분들이 앱을 만들어서 어떻게 돈을 벌 수 있는지 궁금해하셨고, 가장 흔하고 우리도 가장 쉽게 시도해볼 수 있는 것이 바로 광고이기 때문에 커리큘럼에 넣게 되었다. Admob의 이해와 Admob 붙이기 웹은 Adsense를 사용하고 모바일은 Admob으로 광고를 붙인다. 실습은 모바일앱을 만드는 과정이기 때문에 Admob을 기준으로 어떤 과정을 통해 앱 제작자에게 수익이 돌아갈 수 있는지 큰 그림을 먼저 설명했다. 무엇이든 큰 그림을 알고 세부 내용을 파악하면 길을 잃지 않는다. 큰 그림을 파악한 뒤에는 광고 성과 파악을 위한 기본 적인 용어와 개념들을 다뤘다. 제품 고도화에 시간을 쏟는 것도 물론 중요하지만, 광고가 내 서비스의 주 수익원이라면 광고를 통해 내가 얼마를 벌 수 있을지 가늠해가면서 서비스 방향성을 고민하는 것 또한 중요하기 때문이다. Admob 에는 총 6가지 다양한 광고를 붙일 수 있는데, 각 광고의 특징을 알아 본 뒤, 결과적으로 Todo 앱에는 하단 배너와 앱 오픈 광고 두 가지를 붙이는 실습을 진행했다. 배포와 앱 결제 상품 붙이기 (RevenueCat 활용) 이제 열심히 만든 앱을 앱스토어와 플레이스토어에 테스트를 거친 뒤 배포할 때이다. 테스트와 배포는 애플 개발자 계정 연 99달러, 구글 개발자 계정 평생 25달러의 비용이 발생하기 때문에 실습으로 진행하지 못했지만, 배포 과정을 눈으로 익히실 수 있도록 내용을 준비했다. 또한 인앱 결제나 광고 제거 상품등 구독 결제 상품이 필요할 때를 대비해 구글 플레이와 앱스토어 코드를 따로 직접 관리하지 않고 RevenueCat을 사용해 모두 관리하는 방법도 다루었다. Admob 관련 내용은 79 슬라이드에서 끝났는데, 배포와 결제 상품 붙이는 과정에 App developer, App Store Conect, Google Cloud Console, Google Play Console, 그리고 RevenuCat 웹사이트까지 여기저기 절차가 복잡하다보니 256슬라이드까지 만들게 되었다 😂 아무래도 전달할 내용이 많았다보니 실습 시간은 상대적으로 적었는데, 그럼에도 강의 들으시면서 테스트 광고를 붙이신 분들도 계셨다. 너무 감사했던 수강하신 분들의 피드백들, 그리고 마무리 누군가 가르친다는 것이 쉽지 않다는 것을 알고는 있었고, 그래서 많이 노력했지만 정말 쉽지 않았다. 더 쉽게 전달할 방법은 없었을지, 어떻게 했었어야했을지 등 반성하게 되는 부분이 있음에도 수강하신 분들이 고마움을 표현해주시고 격려해주신 덕분에 더 열심히 할 수 있었던 것 같다. 이번 강의를 만들면서 약속했던 것이 "이제 나도 바이브 코딩으로 내 제품을 만들 수 있겠다" 하는 자신감을 심어드리는 것이었는데 이야기 나눠보니 그래도 80% 이상은 그렇게 느끼시는 것 같다. 강의가 끝나서 더 소통이 없어질까봐 아쉬워하시는 분들이 계신것 같아 디스코드 채널은 열어두고 소통을 이어나가기로 했다. 2기는 언제 열리나요? 2기는 언제 열거냐는 질문도 종종 받고 있는데, 사실 강의 하면서 나도 너무 힘들다보니 2기는 못하겠다 싶었는데, 수강하신 분들의 응원과 격려로 아마 2기까지는 하게될 것 같다. 시점은 고민중이지만 너무 멀지 않은 미래로 생각중이다. 더 재미있게 쓰고 싶었는데.. 지난 시간을 기록하는 목적이 더 크다보니 건조하게 쓰여진 것 같아 조금은 아쉽지만, 아주 오랜만에 쓰게 된 이번 블로그 글을 이만 맺어본다.

2025.08.31·7분 읽기·아티클

인간 vs AI 디자인 대결, 인간의 압승!

얼마 전 흥미로운 대결이 있었다. 사람과 AI의, 정확히 말하면 두 사람이 각각 Webflow와 Lovable이라는 AI 툴을 써서 45분 동안 랜딩페이지를 만드는 대결. Webflow는 12년차 디자이너인 DesginJoy의 Brett, Lovable은 19살의 마케터인 Henrik. 폴리마켓에서 20만달러 베팅액이 걸린 이 대결을 4만 명이 넘는 사람들이 지켜봤고, 결과는 Webflow와 Brett의 압승. (사실 Brett은 Webflow쪽 사람도 아니고, 이 대결에서 Henrik이 이겼다면 Webflow만 큰 타격을 받았을것 같다. 다행히 Brett이 승리해서 Webflow도 이득을 좀 보지 않았을까.) 대결을 본 뒤 나의 한 줄 결론은, "디자이너가 앞으로도 중요한 역할을 하게 될 것"이다. 이 대결이 왜 시작되었고, 어떻게 진행되었는지 기록해본다. 도대체 왜 하게 된 걸까? Lovable의 Henrik은 자사 제품 기능을 설명하면서 X에 트윗을 하나 남긴다 "Webflow는 공식적으로 끝났다" "Webflow is officially dead" Webflow를 자주 사용하는 Brett은 이를 보고 한 마디 한다 "그럼 1시간 라이브 대결을 하자." "Let's do an one hour live stream of us both building a website." Henrik은 피하지 않고 좋다며 수락했다. 본격적인 대결 진행을 위해 정확히 어떤 과정이 있었는진 모르지만, 진행은 Tommy Geoco가 맡고, 그가 운영하는 Youtube 채널에서 생중계 하기로 되었다. 그리고 베팅 사이트에서 이 이벤트에 대한 판돈이 몇 억으로 커질만큼 주목을 받았다. 흥미진진했던 대결 진행 과정 그냥 아무 랜딩페이지나 만들 수 없기 때문에 진행팀이 주제와 제약 조건들을 정하고, 이를 대결 시작 시점에 공개하는 방식으로 진행되었다. [주제] 휴머노이드 로봇을 만드는 회사와 그 제품을 소개하는 랜딩페이지 제작 [규칙] 45분간 진행, 5분 설명, 15분 투표 어떤 툴이든 사용해도 되나, 미리 만들어진 템플릿 사용 금지 제공된 문구, 이미지 사용은 선택사항 아래 4개 중 2개 구현 필수 뉴스레터 구독 폼 데모 요청 폼 애니메이션 적용된 고객 후기 캐러셀 애니메이션 적용된, 타사 제품 비교 화면 이렇게 룰 설명이 끝나고 대결이 시작되었다. 두 사람의 작업 방식 초반에 강했던 Henrik 다들 알겠지만 생성형 AI는 한 번에 마음에 드는 결과물이 나오지 않는다. 이 때문에 Henrik은 Lovable을 여러 탭에 열어 둔 뒤 동일한 프롬프트를 입력하는 방식으로 작업을 시작했다. 시작한지 5분도 안돼서 그럴듯한 랜딩페이지가 나왔다. Hero 섹션의 3D 로봇이 마우스 움직임에 따라 고개를 돌리는 인터랙션까지 한 번에 구현하는 Lovable의 능력이 놀라웠고, 이때까지만 해도 Brett은 여전히 빈 캔버스에 몇 가지 요소를 그려넣고 있던 상황이라 Lovable이 이기는건가 싶었다. [5분 경과된 시점의 Henrik의 작업물] [5분 경과된 시점의 Brett의 작업물] 시간이 갈수록 디자이너의 힘을 보여준 Brett 그러나 Henrik의 랜딩페이지는 처음 Lovable이 만들어준 느낌에서 많이 개선되지 못했다. Henrik은 Lovable의 코드에 문제가 생겨서 그것을 고치느라 시간을 많이 썼다고 했지만, 여기에 더불어 Henrik이 디자이너가 아니기 때문에 왔던 한계라고도 생각된다. 반면 Brett은 전체적인 브랜드 톤을 결정하고, 요소들간의 시각적 균형을 계속해서 조정해나가는 모습을 보여줬다. Brett의 랜딩페이지는 시각적으로 깔끔함을 유지하면서도 시간이 갈 수록 개선되며 완성도가 높아지는 과정을 볼 수 있었다. [완성된 Henrik의 랜딩페이지] [완성된 Brett의 랜딩페이지] 결과는 Brett의 압승 Brett은 진행자들 투표와 시청자들 투표에서도 모두 앞섰고 만장일치로 승리했다. 오디언스 투표는 744명이 참여했고, 무려 82%가 넘는 득표율이었다. Brett은 투표로 승리가 확정 되어서야 조금은 편안한 표정을 보였다. 4만명이 지켜보는 가운데서 디자인을 한다는건 나로선 상상도 할 수 없는 일인데 정말 대단하고, 고생했고, 잘했다. 디자이너들은 대체 될 수 없다. 이 대결을 보면서 많은 생각이 들었다. 결론은 앞으로도 디자이너가 중요한 역할을 맡을것은 당분간 확실해보인다. 어떤 메세지를 담고 강조할지, 그것을 시각적으로 어떻게 드러낼지 등등 더 많은 요소들을 복합적으로 생각하고 이끌어나가는 것은 AI가 대체하기 어렵다. 이미 많이들 얘기하는 것 처럼 AI 또한 툴일 뿐, 그걸 활용하는 사람의 능력이 중요한 것이다. 그러나 디자이너는 홀로 서기를 준비해야한다 문제는, 디자이너가 필요한 것은 맞지만 지금 처럼 많이 필요하진 않을 것이다. 1인당 할 수 있는 일이 늘어나면서 팀 규모는 점점 작아진다. 이 흐름은 막을 수 없다. 디자인을 정말 끝까지 파서 디자인으로 1인자가 되는 방법도 있겠지만 AI를 손, 발로 활용하며 시간을 만들고, 그 시간에는 마케팅이나 개발 역량을 키우는 것이 좋은 방향이라고 생각한다. 당연히 꼭 IT분야가 아니어도 된다. 중요한 것은 AI 발전으로 올 세상을 대비해야한다는 것이다. AI 제품들이 쏟아지는 요즘, 정말 재미있는 이벤트였다. 실제 영상을 보고싶은 사람들을 위해 주요 시점을 정리해뒀다. 1️⃣ 규칙 설명 2️⃣ 대결 시작 3️⃣ 작업 설명 4️⃣ 투표 후 소감

2025.03.08·3분 읽기·아티클

디자인 4, 소프트 스킬 6

"일을 잘한다" 라고 하면 어떤 능력이 가장 중요할까? 프로덕트 디자이너 입장에서 볼 땐 아래와 같은 능력을 꼽을 수 있겠다. 디자인 감각이 좋음 손이 빠름 복잡한 화면도 정리를 잘 함 개발시 변수도 고려해서 디자인 함 주로 위와 같은 하드 스킬(Hard Skill)들이 먼저 떠오른다. 이런 하드 스킬들은 중요하다. 저 하드 스킬들을 고루 갖춘 사람도 많지 않을 뿐더러, 같이 일해보면 "일 잘하네" 말이 절로 나온다. 근데 디자인은 잘 하는데 의사소통이 어려운 사람들이 있다. 이런 경우, 일을 잘 한다고 볼 수 있을까? 많은 사람들이 직장에서 일보다는 관계로 힘들어한다. 나도 지난 10년간 일해보니 디자인 보다는 이를 기획자, 개발자들이 받아들일 수 있도록 만드는 것이 더 중요하고 어려운 일이더라. 체감 중요도는 디자인 4, 소프트스킬 6이다. 문제는 이걸 디자인 공부할 땐 아무도 안알려주고, 알려줄 수도 없다는 것이다. 디자인은 혼자 열심히 찾아보고 연습하면 되지만 관계는 혼자 연습할 수 없으니까. 내가 생각하는 일이 되게 만드는 사람들의 태도, 소프트 스킬 3가지 이렇다. 1. 자신의 의견을 고집하지 않는다 경험이 아무리 많아도 자신이 틀릴 수 있다고 생각한다. 그리고 더 좋은 아이디어가 나오면 기꺼이 받아들인다. 이런 태도를 보이면 다른 사람들은 그를 편안하게 느끼고 의견이 있을 때 편하게 말할 수 있다. 좋은 아이디어가 묻히지 않는다. 2. 감정을 긁는 말을 하지 않는다 같은 말을 하더라도 기분 나쁘게 하는 사람이 있다. 그러나 나를 도와주는 동료들, 나와 같은 목표를 향해 일하는 사람들의 기분을 나쁘게 해서 좋을게 전혀 없다. 우리나라의 존댓말 문화가 커뮤니케이션 비용을 올린다는 말이 있다. 동의한다. 죄송하지 않은데도 죄송하다고 말할 때도 많다. 동의한다. 그러나 일이 되도록 만들기 위해 필요하다면 기꺼이 그렇게 하는 것이 현명하다. 공손하고 부드러운 것은 약함의 표시가 아니다. 3. 경계 없이 일한다 일을 하다보면 누가 맡아야하는지 애매한 영역의 일들이 생긴다. 서로 바쁘기도 하고 책임 지기 싫어하는 상황이라면 자연스레 일이 지연되기 마련이다. "일이 되도록 만드는 것"에 초점을 맞추는 사람들은 이런 일을 맡는 것에 거리낌이 없다. 그리고 이런 태도는 팀 동료들에게 전이된다. 팀 전체가 경계없이 서로 돕는 문화를 만들어갈 수 있다. 일을 잘하기 위해서는 하드 스킬도 중요하지만, 결국 "일이 되도록 만드는 것"이 더 중요하다. 자신의 의견을 고집하지 않고, 팀에 긍정적인 분위기가 유지되도록 하면서, 경계 없이 일하는 것. 지금 일하면서 관계로 인해 어려움을 겪고 있다면, 위 세 가지 태도를 점검해 보자. 자연스레 문제들이 해결되고 일은 진척될 것이다.

2025.02.21·2분 읽기·아티클

Quollect, 수요 검증과 리드 확보를 위한 랜딩페이지 배포 🚀

"Quollect" 라는 이름의 독서 기록 앱을 만들고 있다. 디자인을 어느정도 마치고 이제 개발에 들어가려는데, 수요 재확인과 리드 확보를 위해 랜딩페이지를 만들었다. Quollect의 랜딩페이지 구경하기 독서 기록을 하려고 여러가지 앱을 사용해봤다. 무려 14개 🫨 근데 마음에 꼭 드는 앱이 없었다. 아래는 내가 14개의 앱을 비교평가 하기 위해 만든 분석표. 내가 원하는 건 딱 두 가지 인데, 쉽고 간편한 기록 적당한 통계 일단 기록이 있어야 통계도 보여줄 수 있다. 근데 사용해본 앱들 중 두 세 개 외에는 모두 문장 기록 뎁스가 너무 깊어서 불편했다. 책 읽는 흐름을 방해하지 않도록, 문장 기록은 최대한 간편해야한다. 통계도 없는 앱들이 많았다. 있더라도 디자인이 아쉬웠다. 독서를 하는 디자이너들도 많고 개발자들도 많을텐데.. 그리고 시중에 많은 앱들이 나와있는데 이렇게 마음에 드는 것이 없다니? 그래서 직접 만들기 시작했다. 기록과 통계에 집중하면서, 단순하고 사용성 좋은 앱을 만드는 것이 목표. 랜딩페이지, 수요의 검증과 리드 확보 보통 제품 아이디어는 머리속에 존재한다. 그리고 생각 해볼 땐 너무 좋은 아이디어라 굳이 수요 검증을 안해도 대박 날 것 같은 느낌이 든다. 나도 그런 생각에 먼저 디자인하고 개발구조를 어떻게 짤지 생각했다. 그러다가 나를 정신차리게 만든 하나의 Thread 포스트. 맞다. 살 사람이 없는데 제품을 만들면 뭐하나? 이승건 대표도 토스를 만들기 전에 여러번 실패하면서 계속 랜딩페이지로 수요 검증을 했다고 하니까. 사실 독서 기록 앱에 대한 수요 조사를 직접 하진 않았지만, 수요가 있다는 것을 확인하긴 했다. 어떤 개발자분이 독서 기록 앱을 만든다는 글에 엄청난 반응을 보고 굳이 내가 직접 하지 않아도 될것 같다는 생각을 했다. 그리고 14개의 앱을 사용해보면서 사람들이 남긴 앱 리뷰를 보면서도, 수요는 충분하다고 생각했다. 그럼에도 굳이 랜딩페이지를 만든 이유는 두 가지다 한 번 더 수요를 직접 확인하기 위함 리드를 확보하기 위함 제품을 잘 만드는 것도 중요하지만 고객에게 잘 닿는 것도 중요하다. 보통은 마케팅을 후순위로 생각하지만, 사실 마케팅은 제품 제작 전 단계에 이미 실행되어야한다. 시장에서의 어떤 포지션, 키워드를 선점할지 정하고, 그에 맞는 방향으로 제품을 개발해야하기 때문이다. Quollect의 랜딩페이지 구경하기 이것이 어제 하루 동안 만든 랜딩페이지다. Quollect를 시작하게 된 이유와 그려뒀던 화면들을 예쁘게 정리해 특징들을 나열. 랜딩페이지의 목적은 수요 확인과 리드 확보이므로 간단하게 노션과 Tally를 사용했다. 폭발적으로 빨리 늘고 있진 않지만 27분이 출시 알림을 신청해주셨다. 🔥 일단 개별 잠재 고객이 보여주는 반응은 너무 좋고, 리드가 폭발적으로 늘지 못하는 것은 도달율이 높지 않아서 그런 것 같다고 생각된다. 일단 제품 개발은 계속 해도 될것 같다는 생각. Quollect 인스타 계정 이렇게 모은 리드들, 반응을 보인 잠재 고객들을 팬으로 만드는 것이 중요하다. 앞으로 AI로 인해 제품간 퀄리티 차이가 줄어들면, 더 정이 가는 제품에 정착할 가능성이 높다. 그런 측면에서 제품 개발을 하면서도 고객들과 유대감을 쌓는 것이 중요하다. 인스타 계정에도 간단한 제품 컨셉 자료들을 올려두었고, 이제는 제작과정을 공유하면서 잠재 고객들과 소통하는 채널로 사용해 볼 예정이다. 이제 열심히 만들 일만 남았다 🔥

2025.02.08·2분 읽기·제작 과정

폰트 확장자별 크기와 용도 정리!

폰트는 확장자에 따라 용도와 크기가 다르다. 앱이나 웹사이트를 만들 때 용량이 큰 폰트를 포함하면 로딩 속도나 성능에 영향을 미칠 수 있다. 요즘은 시스템 폰트를 사용하거나 CDN을 이용해 별다른 고민 없이 폰트를 적용할 수 있지만, 앱이 오프라인 상태에서도 작동해야 하는 경우에는 폰트를 직접 포함해야 할 수도 있다. 그런 상황을 맞이한 누군가를 위해 폰트 확장자별 크기와 용도를 정리해본다. Thread에 짧은 글로 썼더니 반응이 좋아 롱폼으로도 정리한다. 결론부터 말하자면 구형 기기를 지원할 필요 없을 경우 .woff2 하나면 충분하다. Woff2를 쓰는데도 크게 느껴진다면? 한글 폰트같은 경우, .woff2를 써도 용량이 크게 느껴질 수도 있다. 잠시 영문과 한글폰트의 아주 기본적인 차이에 대해 얘기해보자면 이렇다. 영문 폰트는 대소문자와 숫자, 특수문자까지 포함해도 약 100자로 구성되지만, 한글은 자주 사용되는 최소 상용자인 2,350자를 포함해야 해서 용량이 크다. 근데 한자는? 상용자만 2만개가 넘는다 😂 근데 만약 이걸 두께별로 Regular, Medium, Bold를 만든다면? 모두 다 디자이너들이 직접 눈으로 봐가며 균형을 맞춰야한다. 그래서 한글은 본문용으로 균형이 잘 잡힌 폰트를 만들려면 1-2년씩 걸린다. 중국은 너무 압도적인 개수 탓인지 기술이 엄청 발달했다. 사실 돈이 많이 되지 않을텐데 이런 곳에 돈을 투자하는 문화는 좀 배울필요가 있다. 어쨌든, 이야기가 길었다. 결국 한글 폰트는 용량이 크니까 최대한 용량 작은 것을 찾아써야한다는 말이다. 근데 만약 woff2를 쓰는데도 용량이 크게 느껴진다면? subset을 활용하는 방법이 있다. 아래 방법으로 더 최적화해보자. Subset으로 폰트 파일 크기 더 최적화 하기 Subset이란 기존 폰트 파일에서 필요한 문자만 포함한 좀 더 작은 셋의 폰트 파일을 말한다. 예를 들면 중국어 폰트에 너무 많은 글자들이 있어서 폰트 파일 하나만 100메가가 넘어가는 경우라면, 서비스에 사용되는 폰트들만 추려서 작은 셋의 폰트 파일을 만드는 것이다. 출시 이후부터 많은 사랑을 받고 있는 Pretendard도 일본어 폰트인 JP 버전을 보면 한자가 많다보니 subset을 지원하고 있다 이 파일들 중 원하는 글자를 포함한 폰트들을 모아서 폰트 파일 합쳐주는 서비스를 이용해 커스텀 서브셋 폰트를 만들어 이용할 수 있다. 예를 들면 transfonter 같은 곳이 있다. 사실 앱 만들 때에는 시스템 폰트를 쓰는것이 좋다고 생각한다 😂 폰트도 신경쓰기 시작하면 참 번거롭다. 사람들이 폰트 때문에 서비스를 쓰거나 쓰지 않거나 하진 않기 때문에, 정말 브랜딩이 너무 중요한 것이 아니라면 사용성과 앱 개발의 편의를 위해 시스템 폰트를 쓰는 것을 추천한다.

2025.02.03·2분 읽기·아티클

일론의 위대한 제품을 만드는 5단계

논란은 많지만 정말 배울점이 많은 사람. 세상을 자신의 놀이터로 생각하는 사람인 것 같다. 수 많은 실패를 통해 정리한, 일론의 위대한 제품을 만들기 위한 5단계를 보고 두고두고 보고싶어 글로 남긴다. 일론의 위대한 제품을 만들기 위한 5단계. 순서가 매우 중요하니 꼭 단계를 순서대로 거칠 것. #1. 필수 사항들이 정말 필수 인지 의심하라 "필수 사항들을 덜 멍청하게 만들어라" 라고 표현하는데, 프로젝트를 진행하기 위해 필수 사항이라고 정리한 것들 중 필수가 아닌 것들이 분명히 있을 것이므로 이를 의심해야한다고 한다. 특히 사람들은 똑똑한 사람이 정리한 것은 쉽게 믿는데 아무리 똑똑해도 실수를 하므로 정말 모든 것이 필요한지 항상 의심할 것. 그리고 필수가 아닌 것은 제거할 것. #2. 부품이든 프로세스든 최대한 줄여라 "혹시 모르니"라는 생각은 버리자. 제거한 것의 10%를 다시 넣어야하는 상황이 올 때 까지 줄인다. 그런 상황이 오지 않으면 충분히 제거하지 않은 것이다. #3. 단순화, 최적화 하라 1,2 단계를 꼭 거친 후 최적화 해야한다. 꼭 필요하지 않은 것을 최적화하는 것에 시간 낭지하면 안 된다. #4. 빨리 해라 필수적인 것들만 남겨 단순 & 최적화 했다면 이제 빨리 실행하라. #5. 자동화 하라 할 수 있는 모든 것을 자동화해라. 일론은 많은 것들을 만들면서 단순화, 혹은 자동화를 먼저 하는 등의 실수를 수 없이 했다고 한다. 제품을 만들다보면 이것도 저것도 필요할 것 같다는 생각에 사족이 많이 붙는다. 그럴수록 정말 필요한 것, 핵심적인 것이 무엇인지 다시 생각하고 군더더기를 걷어내는 과정이 필요하다. 아래는 영상 원문

2025.02.01·1분 읽기·아티클

디자이너의 만다라트 제작기

디자이너가 만든 세상에서 가장 아름다운 만다라트는 기획부터 제작까지 이틀이 걸렸다. 혹시 모르시는 분들을 위해 제품 링크를 첨부한다. 디자이너의 만다라트 써보기 서버도 안쓰고 비교적 간단한 앱이지만 GPT를 사용해서(Cursor 아니고 GPT 4o) 얼마나 빠르게 제품을 만들 수 있을지 확인했던 아주 중요한 경험이다. 후기로 한 마디 하자면, 일단 본인이 프로덕트 디자이너인데 코딩 배우길 망설여 왔다면 이제는 꼭 코드의 기본을 배우고 AI 작성해주는 코드를 읽는 연습을하자. 정말 다른 세상이 펼쳐질 것이다. 제작 과정, 이제 시작한다. 총 8단계다. #1. 동료가 만다라트 얘길 꺼냄 1월 2일 목요일, 회사에서 동료들과 점심을 먹으며 신년 계획을 나누다 만다라트 얘기가 나왔다. 얘기는 많이 들었으나 작성해 본 적은 없어서 찾아보니 모두 투박한 템플릿들 뿐. 새해 나의 목표 중 하나가 "작은 제품 여럿 만들기"라서, 만다라트를 만들되 심미성과 사용성을 극대화해보자 생각함. #2. 디자인 시작 같은 날 저녁, 퇴근 후 디자인 시작. 만다라트 기본 구조에 파스텔 톤의 색을 입히고 필요한 기능들을 고려하며 빠르게 시안 잡음. 만다라트 그리드가 크기도 하고 계획은 주로 큰 화면으로 할 것 같아서 모바일은 제외. #3. GPT와 개발 시작 같은 날 밤, React + 개인 개발 템플릿으로 개발 시작. 간단한 것들, 템플릿에 수정이 필요한 것들은 직접 했지만 귀찮은 것들은 모두 GPT를 시켰다. 만다라트는 가운데 그리드 셀들이 바깥 그리드의 중앙 셀의 값들과 같은 값을 갖도록 로직을 짜야한다. GPT에게 시켰봤더니 가운데 그리드 셀들 데이터 안에 Nested 된 그리드가 있는 형식으로 구성해줬다. 근데 개발 복잡도만 올라가서 그냥 9개의 그리드 데이터를 단순하게 펼쳐 만들었다. (설명을 잘 한건지 모르겠지만 암튼 GPT 코드가 이 로직 짤 때 별로 도움되지 않았단 얘기 😂) 그러나 그 외에는 정말 많은 도움을 받았다. #4. Firebase로 호스팅 1월 3일 금요일 퇴근 후부터 토요일 저녁까지 생각했던 모든 기능을 개발했다. 사이드 프로젝트는 빨리 끝내지 않으면 마음의 짐이 되므로 속도가 생명. 그래서 익숙한 Firebase로 호스팅 했다. 데이터베이스도 안쓰기 때문에 비용 걱정은 없다 Firebase 프로젝트 생성하고 프로젝트 세팅해준 뒤 배포하면 끝. #5. 도메인 구입 토요일 밤, projact.kr 도메일을 가비아에서 구입. 프로젝트마다 도메인을 사는 대신 하나만 사고 subdomain을 활용해 다양한 프로젝트 도메인 비용을 아끼려고 했다. projact 오타난것 아니냐는 얘기를 종종 듣고 있는데, project 는 너무 비쌌고 project + act 를 합친거라고 생각하니 나쁘지 않았다. "프로젝트를 실행한다"는 의미로 읽히는 것 같아서 그렇게 의미 부여했다 😂 #6. Firebase & 도메인 연결 더 늦은 토요일 밤, Firebase에 mandalart.projact.kr 로 커스텀 도메인을 추가했다. Firebase에서 제공하는 DNS 정보를 가비아 내 도메인 DNS Record에 추가하면, Firebase로 호스팅 한 나의 프로젝트가 mandalart.projact.kr 에도 호스팅 된다. 원래 여기에서 끝나야 정상인데 SSL 인증서가 발급되지 않아 "위험한 사이트" 낙인이 찍혀있었다. Thread에 관련 글을 올렸다가 귀인이 나타나셔서 Cloudflare의 존재를 알려주셨고, 가비아 대신 Cloudflare로 DNS를 관리하도록 변경하니 밤 11시쯤, 인증서 문제가 해결되었다. (너무 감사드립니다 @back.chanhee 님 🙇🏻‍♂️) #7. 제품 출시 영상 제작 SSL 인증서 발급을 기다리며 출시 포스팅에 올릴 영상을 준비. 저작권 문제 없는 Youtube Audio Library에서 음악을 고르고 영상을 촬영 한 뒤, Premier Pro로 컷 편집해서 마무리 . #8. 제품 출시 포스팅 & 홍보 밤 늦은 시간이라 일요일 아침, Thread에 출시 포스팅. 제작 기간만 따지면 목요일 밤부터 토요일 밤까지 만 이틀만에 2025년 첫 제품인 "디자이너의 만다라트"가 완성되었다. 느낀점 직접 구현 시 드는 시간이 아까워 못했던 것들은 GPT와 하니 마구 해볼 수 있어서 새로운 개발 지식을 많이 배웠다. 모바일은 막아뒀다보니 일단 링크를 쉽게 저장할 수 있도록 카톡 공유 기능도 추가했는데 이것 또한 재미있는 배움이었다. 역시 새로운 것을 도전할 때 배움이 생긴다. 이번 해, 다양한 것들을 만들고 도전 하면서 또 많은 것들을 배울 수 있기를.

2025.01.30·3분 읽기·제작 과정