초록이의 바이브코딩

글

7월, 2026의 게시물 표시

20편. 다음 목표, NOPLAN 진짜 서비스로

다음 목표, NOPLAN 진짜 서비스로 여기까지가 코딩 모르던 디자이너가 AI로 앱을 만든 이야기예요. NOPLAN은 이제 시작일 뿐입니다. 앞으로 어디로 갈지, 그 계획을 이야기하면서 이 시리즈를 마무리하려고 해요. 골프는 시작일 뿐이었다 NOPLAN은 골프 여행으로 시작했어요. 제가 제일 좋아하는 거니까요. 근데 처음부터 골프만을 위한 앱은 아니었어요. 여행에는 골프도 있고, 관광도 있고, 맛집 탐방도 있잖아요. 골프는 그중 첫 번째 시작점이었을 뿐이에요. 동선이 제일 까다로운 골프에서 통하면, 다른 여행은 더 쉬울 거라고 봤거든요. 앞으로는 골프 너머로 넓혀갈 계획이에요. 어떤 여행이든 NOPLAN을 켜고 그냥 떠날 수 있게요. 진짜 쓸 수 있는 서비스로 지금 NOPLAN은 데모에 가까워요. 후쿠오카로 고정돼 있고, 추천 정보도 제가 넣은 범위 안에 있어요. 목표는 이걸 진짜 서비스로 키우는 거예요. 여행지를 자유롭게 고르고, 더 다양한 정보가 들어가고, 실제 예약까지 이어지는 것. 갈 길이 멀지만, 여기까지 온 것처럼 하나씩 만들어가려고 해요. 코딩을 못 한다는 건 이제 핑계가 안 돼요. AI랑 같이 하면 되니까요. 이 블로그를 이어가는 이유 이 블로그는 NOPLAN을 만드는 과정을 적는 곳이에요. 앞으로도 계속 적을 거예요. 새 기능을 만들면서 막힌 이야기, AI랑 씨름한 이야기, 사람들 반응을 듣고 고친 이야기. 잘된 것만이 아니라 헤맨 것까지 다 적을게요. 저처럼 "나도 만들어보고 싶은데" 하는 사람한테, "어 나도 할 수 있겠다"는 용기가 되면 좋겠어요. 계획 없이 사는 사람이, 계획 없이 시작한 앱 만들기. 그 여정은 계속됩니다. 여기까지 오는 데 걸린 시간 첫 프롬프트를 쳤던 날부터 지금까지, 돌아보면 짧지 않은 시간이었습니다. 에러도 여러 번 만났고, 하루치 작업을 통째로 날린 날도 있었고, 이름 하나 짓는 데도 한참 걸렸어요. 그래도 결국 여기까지 왔습니다. 앞으로는 후...

자세한 내용 보기

19편. AI로 앱 만들며 알게 된 것 5가지

AI로 앱 만들며 알게 된 것 5가지 코딩 한 줄 못 하던 제가 AI로 앱을 만들었어요. 완벽하진 않지만, 진짜 작동하는 앱을요. 그 과정에서 배운 것들을 정리해봤습니다. 저처럼 시작하려는 분들한테 도움이 됐으면 해요. 1. AI는 직원이 아니라 동료다 처음엔 AI한테 "이거 해, 저거 해" 일방적으로 시켰어요. 근데 그렇게 하면 결과가 별로예요. AI는 시키는 대로 하는 도구가 아니라, 같이 만들어가는 동료에 가까웠어요. 제 의도를 전하고, AI가 방법을 제안하고, 같이 다듬는 거죠. 일방적인 지시보다 주고받는 소통이 훨씬 좋은 결과를 만들었어요. 2. 못 만드는 게 아니라 설명을 못 하는 거다 "이건 어려워서 못 만들겠지"라고 지레 포기한 게 많았어요. 근데 막상 AI한테 물어보면 되는 경우가 대부분이었어요. 문제는 "만들 수 있냐"가 아니라 "내가 원하는 걸 정확히 설명할 수 있냐"였어요. 머릿속 그림이 또렷할수록 결과가 좋았고, 막연하면 막연한 게 나왔어요. 결국 실력은 코딩이 아니라 설명하는 능력이었어요. 3. 천천히 가는 게 빠르다 급하게 한꺼번에 시키면 꼭 사고가 났어요. 그리고 그 사고 수습에 며칠이 날아갔죠. 한 번에 하나씩, 확인하면서 가는 게 답답해 보여도 제일 빨랐어요. 특히 코드를 못 고치는 비개발자한테는 "안 망가뜨리는 것"이 최고의 전략이에요. 4. 보는 눈이 코딩 실력보다 중요하다 저는 코드를 못 읽어요. 대신 "이게 좋은지 나쁜지, 편한지 불편한지"는 봐요. AI가 만든 걸 보고 어디가 어색한지 잡아내는 것. 이게 코딩 실력보다 중요했어요. 그리고 이 눈은 디자이너가 아니어도, 평소 불편함을 느낄 줄 아는 사람이면 누구나 있어요. 5. 공개해야 진짜 완성이다 내 컴퓨터 안에 있는 건 반쪽짜리예요. 사람들한테 보여주고, 반응을 듣고, 고쳐가야 진짜 완성됩니다. 무서워도 내놓으세요. 만드는 건 절...

자세한 내용 보기

18편. 사람들에게 보여준 첫 반응

사람들에게 보여준 첫 반응 앱을 다 만들고 나니 떨렸어요. 이걸 사람들이 어떻게 볼까. 혼자 만들 땐 몰랐는데, 막상 보여주려니 두려웠습니다. "별로면 어쩌지?" 하는 마음이요. 공개가 제일 무서웠다 사실 만드는 것보다 보여주는 게 더 무서웠어요. 내 컴퓨터 안에 있을 땐 누가 뭐라 할 사람이 없잖아요. 근데 세상에 내놓는 순간 평가를 받게 되니까요. "이게 뭐야", "별로다" 같은 말을 들을까 봐 겁났어요. 근데 안 보여주면 아무 의미가 없잖아요. 쓰라고 만든 앱인데. 그래서 용기를 내서 SNS에 올렸어요. 만든 과정이랑 앱 화면을 같이요. 솔직하게 보여줬다 저는 "완벽한 앱"인 척 안 했어요. 오히려 솔직하게 갔습니다. "극P라서 여행 계획 짜기 싫어서 그냥 만들어버렸어요"라고요. 코딩도 모르는데 AI랑 만들었다는 것도 그대로 밝혔어요. 잘난 척이 아니라, 나 같은 사람도 만들었다는 이야기로요. 신기하게도 이 솔직함에 사람들이 반응했어요. "오 나도 극P인데", "이런 거 필요했어", "코딩 모르는데 어떻게 만들었어요?" 같은 댓글이 달렸어요. 완벽해서가 아니라 공감돼서 반응한 거예요. 반응에서 배운 것 사람들 반응을 보면서 많이 배웠어요. 내가 당연하다고 생각한 기능을 신기해하기도 하고, 내가 신경 못 쓴 부분을 불편해하기도 했어요. 혼자 만들 때는 안 보이던 것들이 남의 눈을 통해 보였습니다. 그리고 깨달았어요. 앱은 공개하고 나서가 진짜 시작이구나. 만드는 건 절반이고, 사람들 반응을 듣고 고쳐가는 게 나머지 절반이라는 걸요. 무서워도 보여주길 잘했습니다. 올리기 직전까지 망설였던 이유 스레드에 올리기 버튼을 누르기까지 한참 망설였습니다. "코딩도 모르면서 뭘 만들었다고 자랑하냐"는 말을 들을까 봐서요. 제가 만든 게 완벽하지 않다는 것도 스스로 잘 알고 있었고...

자세한 내용 보기

17편. 모바일에서도 되게 만들기

모바일에서도 되게 만들기 앱을 인터넷에 올리고 나서 폰으로 열어봤어요. 그런데 화면이 영 어색했습니다. 컴퓨터에서는 멀쩡했는데, 폰에서는 글자가 삐져나오고 버튼이 너무 작고. 사람들은 대부분 폰으로 볼 텐데 이러면 안 되잖아요. 사람들은 폰으로 본다 생각해보면 당연한 거였어요. 요즘은 여행 정보를 컴퓨터 앞에 앉아서 보는 것보다 대부분 침대에 누워서, 출퇴근길에, 폰으로 보겠죠. 근데 저는 만들 때 컴퓨터 화면만 보고 만들었어요. 그러니 컴퓨터에선 완벽한데 폰에선 엉망이었던 거죠. 큰 화면에 맞춘 걸 작은 화면에 욱여넣으니 깨질 수밖에요. 이걸 두 화면 다 잘 보이게 만드는 걸 "반응형"이라고 하더라고요. 화면 크기에 따라 알아서 모양이 바뀌는 거요. 폰 기준으로 다시 봤다 그래서 작업 방식을 바꿨어요. 폰 화면을 기준으로 확인하기 시작했습니다. AI한테 "폰에서 글자가 화면 밖으로 나가", "버튼이 너무 작아서 누르기 힘들어"처럼 폰에서의 문제를 구체적으로 말했어요. 그러면 폰 화면에 맞게 고쳐줬습니다. 이때도 직접 확인이 중요했어요. 고쳤다고 하면 진짜 폰으로 열어봤어요. 글자가 잘 들어가는지, 버튼이 누를 만한지, 스크롤이 자연스러운지. 사용자가 진짜 쓸 환경에서 봐야 진짜 문제가 보이거든요. 디자이너라서 예민했던 부분 여기서도 보는 눈이 도움이 됐어요. 폰에서 살짝 어색한 것들이 눈에 띄었거든요. 글자가 너무 빽빽하다, 버튼 사이가 좁아서 잘못 누르겠다, 위아래 여백이 답답하다. 기능은 되는데 "쓰기 불편한" 부분들이요. 이런 걸 하나하나 다듬었어요. 작은 화면일수록 이런 디테일이 더 중요해요. 공간이 좁으니까 조금만 빽빽해도 답답하게 느껴지거든요. 덜어내고, 띄우고, 키우고. 폰에서 편하게 보이도록 계속 손봤습니다. 컴퓨터에선 예뻤는데 폰에선 다 깨졌다 컴퓨터 화면에서 확인할 땐 완벽해 보였습니다. 그런데 폰으로 열어보니 버튼은 화면 밖으로 삐져나가...

자세한 내용 보기

16편. 앱을 인터넷에 올렸다, 배포

앱을 인터넷에 올렸다, 배포 지금까지 만든 앱은 제 컴퓨터 안에만 있었어요. 저만 볼 수 있었죠. 이걸 다른 사람도 쓰게 하려면 인터넷에 올려야 합니다. 이걸 "배포"라고 부르더라고요. 비개발자한테는 이것도 큰 산이었어요. 만드는 거랑 올리는 건 다른 일 앱을 만드는 것까지는 어떻게 했어요. 근데 그걸 인터넷에 올리는 건 또 다른 얘기였습니다. 제 컴퓨터에서는 잘 되는데, 이걸 어떻게 해야 다른 사람 폰에서도 열리지? 주소는 어떻게 만들지? 서버라는 게 필요하다던데 그게 뭐지? 모르는 것투성이였어요. 여기서도 방법은 똑같았어요. AI한테 물어봤습니다. "내가 만든 앱을 인터넷에 올려서 다른 사람도 쓰게 하고 싶어. 어떻게 해?" 무료로 올리는 방법이 있었다 AI가 알려준 건, 무료로 앱을 올릴 수 있는 서비스들이 있다는 거였어요. 복잡한 서버를 직접 마련할 필요 없이, 이런 서비스에 제 앱을 연결하면 인터넷 주소가 생기고 누구나 접속할 수 있게 돼요. 돈도 안 들고요. 비개발자한테는 이게 정말 다행이었습니다. 물론 연결하는 과정에서 또 에러가 났어요. 설정이 안 맞거나, 뭔가 빠졌거나. 그때마다 AI한테 증상을 말하고 하나씩 고쳤습니다. 이제는 이 과정이 익숙했어요. 에러는 과정이니까요. 내 앱에 주소가 생긴 순간 드디어 앱이 인터넷에 올라갔어요. 주소가 생겼습니다. 그 주소를 폰에 입력하니까 제 앱이 떴어요. 제 컴퓨터가 아니라 인터넷에 있는 앱이요. 이걸 다른 사람한테 보내면 그 사람도 똑같이 볼 수 있는 거예요. 신기하고 뿌듯했습니다. 코딩도 모르던 사람이 만든 앱이, 이제 세상 누구나 접속할 수 있는 진짜 앱이 된 거예요. 배포가 이렇게 간단할 줄 몰랐다 배포라는 말이 주는 무게감 때문에 시작 전엔 살짝 긴장했습니다. 서버니 도메인이니, 어려운 용어들이 잔뜩 있을 것 같았거든요. 실제로는 생각보다 간단했습니다. 코드를 깃허브에 올리고, 무료 호스팅 서비스에 연결하고, 도메인만 하나 사...

자세한 내용 보기

15편. 로고를 직접 만든 이야기

로고를 직접 만든 이야기 NOPLAN이라는 이름을 정하고, 로고를 만들었어요. 이 부분은 솔직히 제가 제일 자신 있는 영역이었습니다. 디자이너니까요. 이름만으론 부족하다 이름을 NOPLAN으로 정했지만, 글자만 덜렁 있으면 밋밋하잖아요. 이 이름에 담긴 뜻을 한눈에 보여주고 싶었어요. 핵심 메시지는 "계획은 필요 없다"였어요. 그럼 이걸 어떻게 시각적으로 보여줄까. 고민하다가 답이 나왔습니다. PLAN이라는 글자를 지워버리면 되잖아요. 취소선 하나로 메시지를 담다 NOPLAN에서 뒤쪽 PLAN 위에 취소선을 그었어요. 색은 포인트 컬러인 주황색으로요. 이 취소선 하나가 많은 걸 말해줍니다. "계획(PLAN)? 그딴 거 필요 없어." 글자를 읽기도 전에 취소선만 봐도 느낌이 와요. 계획을 지운다는 이 앱의 정체성이 로고에 그대로 담긴 거죠. 복잡한 그림도, 화려한 효과도 없어요. 그냥 글자랑 선 하나. 근데 이게 제일 강력해요. 디자인에서 가장 어려운 건 더하는 게 아니라 덜어내는 거거든요. AI랑 디자인도 같이했다 로고 콘셉트는 제가 잡았지만, 실제로 화면에 구현하는 건 AI랑 같이했어요. "NOPLAN이라고 쓰고, PLAN 부분 위에 주황색 취소선을 그어줘. 폰트는 두껍고 단단한 느낌으로." 이렇게 전했어요. 몇 번 다듬으니 원하던 로고가 화면에 나타났습니다. 콘셉트는 사람이, 구현은 AI가. 여기서도 그 분업이 통했어요. 제가 "무엇을, 왜"를 정하고 AI가 "어떻게"를 맡는 거죠. 디자이너인데 왜 로고 만드는 데 오래 걸렸을까 의외였습니다. 디자인 일을 오래 했는데도 제 브랜드 로고는 유독 오래 걸렸어요. 남의 브랜드를 만들 땐 객관적으로 보이던 게, 제 것이 되니까 계속 아쉬운 부분만 눈에 들어오더라고요. 결국 제일 단순한 방법으로 돌아갔습니다. NOPLAN이라는 글자 자체에 PLAN 부분만 주황색 취소선을 긋는 것. 폰트는 굵고 각...

자세한 내용 보기

14편. 드디어 이름을 지었다

드디어 이름을 지었다 여기까지 앱을 만들면서, 정작 이름이 없었습니다. 계속 "이 앱", "그 앱"이라고만 불렀어요. 근데 이제 이름을 지어줄 때가 됐습니다. 그리고 그 이름은, 제 이야기에서 자연스럽게 나왔어요. 이름은 본질에서 나와야 한다 디자이너로 일하면서 배운 게 있어요. 좋은 이름은 억지로 짜내는 게 아니라, 그게 뭔지에서 자연스럽게 나온다는 거예요. 그래서 처음으로 돌아가 생각했어요. 나는 이 앱을 왜 만들었지? 저는 계획을 안 짜는 사람이에요. 극P죠. 비행기 표랑 호텔만 잡고 떠나는, 계획이라곤 없는 사람. 그런 사람도 편하게 여행할 수 있게 만든 앱이 이거였어요. 계획을 대신 짜주는 앱. 계획이 없다 = NO PLAN 그 순간 단어 하나가 떠올랐어요. 계획이 없다. No Plan. 저처럼 계획 없는 사람을 위한 앱이니까, 계획이 없어도(NO) 떠날 수 있다는 뜻으로 NOPLAN. 딱 맞았어요. 제 이야기 그 자체였거든요. 이름을 억지로 멋지게 지으려고 안 했어요. 그냥 제가 어떤 사람이고 왜 이걸 만들었는지를 솔직하게 담으니, 이름이 저절로 나왔어요. NOPLAN. 계획 없는 사람들의 여행. 로고에 담은 메시지 이름을 정하고 로고를 만들었어요. 여기에 디자이너 본능이 발동했죠. NOPLAN이라는 글자에서 PLAN 위에 주황색 취소선을 그었어요. "계획(PLAN)은 지워버려"라는 뜻이에요. 계획 없이 떠나도 된다는 메시지를 한눈에 보이게요. 슬로건도 정했어요. "계획은 우리가 할게요. 당신은 떠나기만." 계획 짜기 싫어하는 사람한테 이만큼 솔깃한 말이 있을까요. 제가 듣고 싶었던 말이기도 하고요. 이름 짓기까지 걸린 시간 사실 이름을 정하는 데 가장 오래 걸렸습니다. 후보만 열 개 넘게 나왔어요. 흔한 이름들이었죠. 다 무난했지만 딱히 끌리지 않았습니다. 그러다 제 성향을 그대로 이름에 담아보자는 생각이 들었어요. 저는 계획 세우는 걸 극도로...

자세한 내용 보기

13편. 코드 백업, 이래서 중요하다

코드 백업, 이래서 중요하다 만든 걸 날려본 적 있으세요? 저는 있습니다. 그것도 며칠치를요. 그날 이후로 저는 "저장"에 집착하게 됐어요. 한 번 크게 데였다 앞서 규칙 어기고 작업을 통째로 날린 이야기를 했었죠. 그때 진짜 뼈아팠던 건, 돌아갈 곳이 없었다는 거예요. 만약 "며칠 전 잘 되던 상태"가 어딘가 저장돼 있었다면, 거기로 돌아가면 됐을 거예요. 근데 저는 그걸 안 해놨어요. 그래서 망가진 순간, 복구할 방법이 없었습니다. 그때 깨달았어요. 만드는 것만큼 중요한 게 저장해두는 거구나. 저장이란 게 뭔가 코딩하는 사람들은 작업한 걸 단계마다 저장해둔대요. "지금까지 잘 됐다" 싶은 지점을 기록으로 남겨두는 거죠. 디자인 작업도 백업이 필수에요. 그러면 나중에 뭔가 망가져도 그 지점으로 돌아갈 수 있어요. 게임 세이브 포인트랑 비슷해요. 보스 깨기 전에 저장해두면, 죽어도 거기서 다시 시작하잖아요. 코드도 똑같습니다. 잘 되는 지점마다 저장해두면, 망가져도 거기서 다시 시작할 수 있어요. 저는 이걸 AI한테 맡겼어요. "지금 잘 되니까 이 상태를 저장해줘"라고요. 그러면 AI가 알아서 기록을 남겨줍니다. 비개발자한테 더 절실하다 이것도 결국 비개발자한테 더 중요한 이야기예요. 개발자는 망가져도 코드를 읽고 직접 고칠 수 있어요. 근데 저는 못 하잖아요. 그러니 "망가지면 저장해둔 지점으로 돌아가는 것"이 유일한 복구 방법입니다. 그래서 저는 이제 좀 잘 됐다 싶으면 무조건 저장부터 해요. 큰 기능 하나 완성하면 저장, 잘 작동하는 거 확인하면 저장. 귀찮아도 이게 저를 살립니다. 사고는 항상 "저장 안 한 날" 나거든요. 백업 없이 날렸던 그날, 또 한 번 Plan Mode 사건 이후에도 비슷한 일이 한 번 더 있었습니다. 이번엔 저장을 깜빡한 채로 큰 수정을 시도했다가, 되돌리려니 되돌릴 지점 자체가 없었어요. ...

자세한 내용 보기

12편. AI가 자꾸 다른 델 건드릴 때

AI가 자꾸 다른 델 건드릴 때 분명 한 군데만 고쳐달라고 했는데, 멀쩡하던 다른 기능이 망가져 있습니다. AI랑 일하면서 제일 자주, 제일 답답했던 문제예요. "여기만 고쳐"라고 했는데 예를 들어 "버튼 색만 바꿔줘"라고 합니다. 그러면 색은 바뀌는데, 어쩐 일인지 옆에 있던 기능이 안 되는 거예요. 건드리지도 않은 곳이요. 처음엔 이게 너무 황당했어요. "나는 색만 바꾸라고 했는데 왜 저게 망가져?" 코딩을 모르니 이유도 모르겠고, 그냥 답답하기만 했죠. 알고 보니 코드는 여기저기 연결되어 있어서, 한 곳을 건드리면 다른 곳에 영향이 갈 수 있대요. AI가 고치는 과정에서 의도치 않게 다른 부분을 건드리는 거죠. 대처법을 찾았다 이 문제는 몇 가지 방법으로 줄였어요. 첫째, 고치기 전에 범위를 못 박았습니다. "다른 건 절대 건드리지 말고 이것만 고쳐"라고 분명히 말해요. 그러면 확실히 사고가 줄어요. 둘째, 고친 다음에 다른 기능도 확인했어요. 색만 바꿨어도 옆 버튼, 계산 기능까지 한 번씩 눌러봐요. 망가진 게 있으면 바로 알 수 있으니까요. 셋째, 한 번에 하나씩만 고쳤어요. 역시 이 규칙이 답이었어요. 여러 개를 동시에 안 건드리니, 뭔가 망가져도 방금 그것 때문인 걸 바로 알죠. 백업의 소중함을 또 느꼈다 그래도 가끔은 망가집니다. 그때를 대비해 작업한 걸 저장해두는 게 정말 중요해요. 뭔가 크게 망가졌을 때 "아까 잘 되던 상태로 돌아가자"가 가능하려면, 그 상태가 어딘가 저장돼 있어야 하잖아요. 이 백업 이야기는 다음 글에서 제대로 다룰 만큼 중요해요. 한 번 크게 데인 적이 있거든요. 매번 겪는 딜레마 AI한테 "이것만 고쳐줘"라고 해도 가끔 다른 부분까지 손을 댑니다. 나쁜 의도는 아니에요. AI 입장에서는 더 낫게 만들려고 하는 거지만, 저는 이미 완성해둔 다른 부분이 흔들리는 게 제일 무섭습니다. ...

자세한 내용 보기

11편. 드래그로 일정 순서 바꾸기

드래그로 일정 순서 바꾸기 일정을 짜다 보면 순서를 바꾸고 싶을 때가 있어요. 아침에 가려던 곳을 오후로, 첫째 날 일정을 둘째 날로. 이걸 손가락으로 끌어서(드래그) 옮길 수 있게 만들고 싶었습니다. 근데 이게 생각보다 훨씬 어려웠어요. 욕심이 부른 도전 사실 이 기능은 없어도 됐어요. 위아래 화살표 버튼으로 순서를 바꾸게 해도 되니까요. 근데 욕심이 났습니다. 요즘 앱들은 다 손가락으로 끌어서 옮기잖아요. 그게 훨씬 직관적이고 편하거든요. 디자이너로서 "이왕이면 제대로" 하고 싶었어요. 그래서 AI한테 도전적으로 시켰습니다. "일정 카드를 마우스로 클끌어서 순서를 바꿀 수 있게 만들어줘." 쉽게 안 됐다 이건 정말 한 번에 안 됐어요. 처음엔 카드가 끌리긴 하는데 엉뚱한 자리에 놓이고, 다음엔 끌다가 화면이 멈추고, 또 다음엔 모바일에서만 안 되고. 에러의 연속이었어요. 제일 고생한 기능 중 하나입니다. 그때마다 증상을 정확히 말해줬어요. "카드를 끌어서 두 번째 자리에 놓으려는데 자꾸 맨 아래로 가", "데스크탑에선 되는데 폰에선 안 끌려." 이렇게요. 그러면 AI가 하나씩 고쳐줬습니다. 포기하고 싶을 때 버틴 이유 솔직히 중간에 "그냥 화살표 버튼으로 할까" 싶었어요. 너무 안 되니까요. 근데 버텼습니다. 이게 되면 앱이 훨씬 좋아질 걸 아니까요. 그리고 한 단계씩 증상을 말하고 고치다 보니, 결국 됐어요. 손가락으로 부드럽게 카드가 옮겨지는 걸 봤을 때 진짜 뿌듯했습니다. 어려운 기능일수록 됐을 때 보람이 커요. 그리고 "안 되면 AI랑 같이 하나씩 고치면 된다"는 자신감도 생겼고요. 드래그 기능, 제일 오래 걸린 이유 지금까지 만든 기능 중에 시간이 가장 오래 걸린 게 이 드래그 기능이었습니다. 카드를 옮기는 것 자체는 금방 됐는데, 문제는 순서를 바꾸면 이동 시간과 전체 일정표가 전부 다시 계산돼야 한다는 점이...

자세한 내용 보기

10편. 거리·시간·비용 자동 계산법

거리·시간·비용 자동 계산법 이 앱의 진짜 핵심은 자동 계산이었어요. 장소들을 일정에 담으면 그 사이 거리가 얼마고, 이동에 얼마나 걸리고, 1인당 비용이 얼마인지 알아서 나오는 것. 제가 제일 귀찮아하던 그 "계산"을 앱이 대신해주는 거죠. 이게 제일 만들고 싶었던 기능 사실 이 기능 때문에 앱을 만들기 시작한 거예요. 여행 계획이 귀찮은 이유의 대부분이 이 "계산" 때문이거든요. 여기서 저기까지 얼마나 걸리지? 택시비는 얼마지? 넷이 가면 1인당 얼마지? 이걸 일일이 찾고 더하는 게 너무 싫었어요. 그러니 이 기능만 제대로 되면 앱의 절반은 완성인 셈이었습니다. 그만큼 공을 들였어요. 숫자가 틀리면 안 된다 여기서 제일 신경 쓴 건 정확성이었어요. 다른 건 좀 어설퍼도 넘어가지만, 돈 계산이 틀리면 앱을 믿을 수 없게 되잖아요. 그래서 AI한테 계산 기능을 만들게 한 다음, 검증을 엄청 했어요. 일부러 여러 경우를 넣어봤습니다. 한 명일 때, 네 명일 때, 장소를 더 넣었을 때, 뺐을 때. 그때마다 숫자가 제대로 바뀌는지 직접 확인했어요. 8번 글에서 말한 "증명해봐"가 여기서 진짜 빛을 발했어요. "이 숫자가 맞는지 보여줘"라고 계속 시켰거든요. 비개발자라서 오히려 꼼꼼했다 신기한 게, 코딩을 모르니까 오히려 더 꼼꼼하게 확인하게 됐어요. 개발자면 코드를 보고 "로직이 맞네" 하고 넘어갈 수도 있을 텐데, 저는 코드를 못 보잖아요. 그러니 실제로 숫자를 넣어보고 결과로만 판단해야 했어요. 사용자가 진짜 겪을 상황 그대로 테스트한 거죠. 결과적으로 이게 더 안전했어요. 사용자 입장에서 계속 확인하니까, 사용자가 만날 문제를 미리 잡아낼 수 있었거든요. 숫자 하나 바꾸는 게 왜 이렇게 어려웠을까 말로는 간단해 보였습니다. "인원수 바꾸면 1인당 금액도 자동으로 바뀌게 해줘." 그런데 막상 만들어보니 숙박비, 렌터카비처럼 ...

자세한 내용 보기

9편. 여행 타입 고르면 일정이 바뀐다

여행 타입 고르면 일정이 바뀐다 앱의 핵심은 이거였어요. 사용자가 누구냐에 따라 추천이 달라지는 것. 가족 여행이랑 친구 여행이 같을 순 없잖아요. 출장이랑 놀러 가는 것도 완전히 다르고요. 그래서 "어떤 여행이냐"를 고르면 그에 맞게 일정이 바뀌게 만들고 싶었습니다. 말로 설명하기는 쉬운데 머릿속 그림은 명확했어요. "여행을 고르면 친구랑 갈 만한 곳, 출장을 고르면 격식 있는 곳이 추천되게." 근데 이걸 어떻게 앱으로 만들지는 막막했습니다. 코딩을 모르니까 "이게 기술적으로 가능한 건가?"부터 의문이었어요. 그래서 일단 AI한테 물어봤습니다. "여행이랑 출장 두 가지 버튼을 만들고, 어떤 걸 고르냐에 따라 추천이 달라지게 하고 싶어. 가능해?" 그랬더니 "가능하다"며 방법을 설명해줬어요. 역시 일단 물어보는 게 답이었습니다. 하나씩 쪼개서 만들었다 큰 기능이라 한 번에 안 만들었어요. 규칙대로 쪼갰습니다. 먼저 "여행 / 출장" 두 버튼만 만들었어요. 잘 눌리는지 확인. 그다음 버튼을 고르면 그 선택이 저장되게 했어요. 확인. 그다음 선택에 따라 다른 목록이 나오게 했어요. 확인. 이렇게 한 단계씩 가니까 중간에 막혀도 어디가 문제인지 바로 알 수 있었어요. 만약 한 번에 다 만들었으면 또 7번 글처럼 사고 났을 거예요. 디자이너라 신경 쓴 부분 기능만 되면 끝이 아니었어요. 고르는 경험도 중요했습니다. 버튼을 눌렀을 때 "내가 이걸 골랐구나"가 한눈에 보여야 해요. 그래서 선택한 버튼은 주황색으로 바뀌고, 안 고른 건 차분하게 두는 식으로 만들었어요. 누르면 색이 휙 바뀌면서 깜빡이지 않게, 부드럽게요. 이런 작은 디테일이 "쓰기 편한 앱"과 "그냥 되는 앱"의 차이를 만든다고 믿어요. 왜 하필 여행과 출장으로 나눴을까 처음엔 그냥 인원, 박수, 골프 여부만 물어보...

자세한 내용 보기

8편. AI한테 작동 증명시키는 법

AI한테 작동 증명시키는 법 AI는 일을 끝내면 "다 됐습니다"라고 말합니다. 그 말을 곧이곧대로 믿으면 안 돼요. 저는 그걸 여러 번 데이고 나서 배웠습니다. "됐다"는 말을 믿었다가 처음엔 AI가 "기능 추가 완료했습니다"라고 하면 그런 줄 알았어요. 그래서 확인도 안 하고 다음 작업으로 넘어갔죠. 문제는 나중에 터졌습니다. 한참 뒤에 그 기능을 써보니 작동을 안 하는 거예요. 분명 "됐다"고 했는데. 그제야 거슬러 올라가 보면, 사실은 안 되고 있었던 거였어요. 그걸 모르고 그 위에 계속 쌓아 올린 거죠. 이러면 나중에 한꺼번에 무너집니다. 어디서부터 안 됐는지 찾기도 힘들고요. 그래서 "증명"을 요구하기 시작했다 이후로 저는 AI가 "됐다"고 하면 이렇게 말합니다. "진짜 되는지 보여줘. 작동하는 걸 증명해줘." 그러면 AI가 실제로 그 기능을 테스트해보고 결과를 보여줍니다. 버튼을 눌렀을 때 진짜 반응하는지, 숫자 계산이 맞게 나오는지, 화면이 제대로 바뀌는지. 말로만 "됐다"가 아니라 눈으로 확인할 수 있게요. 이 한 마디가 정말 많은 사고를 막아줬어요. "됐어?"가 아니라 "증명해봐"가 핵심입니다. 확인은 결국 내 몫이다 물론 최종 확인은 제가 직접 합니다. AI가 "된다"고 보여줘도, 제가 직접 눌러보고 써봐야 안심이 돼요. 코딩을 모르니까 코드로는 확인 못 합니다. 대신 사용자 입장에서 확인할 수 있어요. 실제로 버튼 눌러보고, 정보 넣어보고, 결과가 제대로 나오는지 보는 거죠. 사실 이게 제일 확실한 검증이에요. 진짜 쓰는 사람처럼 써보는 거니까요. "됐다고 말만 하지 말고" 라고 말하게 된 이유 처음엔 AI가 "완료했습니다"라고 하면 그런가 보다 하고 넘어갔습니다. 그런데 막상 제가...

자세한 내용 보기

7편. Plan Mode 안 썼다가 다 날린 날

Plan Mode 안 썼다가 다 날린 날 규칙을 정해놓고도 안 지킬 때가 있습니다. 사람이니까요. 저도 그랬어요. 그리고 그날, 며칠 동안 만든 걸 통째로 날렸습니다. 급한 마음이 화를 불렀다 그날따라 마음이 급했어요. 기능을 빨리 추가하고 싶어서 규칙을 건너뛰었습니다. 원래는 "계획부터 짜고, 한 번에 하나씩"이 제 규칙이었어요. 근데 그날은 그냥 한꺼번에 다 시켜버렸습니다. "이 기능 넣고, 저 화면도 바꾸고, 이 부분도 고쳐줘." 빨리 끝내고 싶었거든요. AI는 시키는 대로 다 했습니다. 그런데 그 과정에서 잘 되던 기능들이 줄줄이 망가졌어요. 하나를 고치니 다른 게 깨지고, 그걸 고치니 또 다른 게 깨지고. 되돌릴 수도 없었다 더 큰 문제는 되돌릴 수가 없었다는 거예요. 한 번에 너무 많은 걸 바꿔서, 어느 시점으로 돌아가야 할지도 몰랐습니다. 코드를 읽을 줄 알면 문제 부분만 고쳤겠지만 저는 못 하잖아요. 결국 며칠 작업한 걸 포기하고 이전 상태로 돌아가야 했어요. 그 순간 진짜 허무했습니다. 동시에 뼈저리게 깨달았어요. 규칙은 괜히 만든 게 아니구나. 그날 이후로 바뀐 것 이 일을 겪고 나서 저는 규칙을 진짜로 지키기 시작했습니다. 아무리 급해도 "계획부터 짜줘. 코드는 쓰지 마"로 시작해요. 그리고 한 번에 하나씩만 시킵니다. 기능 하나 넣고, 잘 되는지 확인하고, 그다음. 답답할 만큼 천천히 가지만, 이게 결국 제일 빠릅니다. 망가뜨리고 다시 만드는 시간보다, 처음부터 천천히 제대로 가는 시간이 훨씬 짧거든요. 비개발자한테는 특히 그래요. 고칠 능력이 없으니 애초에 안 망가뜨리는 게 답입니다. 그날 정확히 무슨 일이 있었냐면 한창 재미가 붙어서 이것저것 한꺼번에 고쳐달라고 했습니다. 버튼 색도 바꾸고, 레이아웃도 손보고, 계산 로직도 같이 건드려달라고요. Plan Mode 없이 그냥 다 던졌어요. 결과는 총체적 난국이었습니다. 버튼은 바뀌었는데 레이아웃이 깨졌...

자세한 내용 보기

6편. AI 코드, 한 번에 되는 일은 없다

AI 코드, 한 번에 되는 일은 없다 AI한테 시키면 코드가 뚝딱 나옵니다. 그래서 처음엔 이렇게 생각했어요. "이거 그냥 갖다 쓰면 되겠네?" 순진한 생각이었습니다. 처음 만난 에러 첫 화면을 만들고 신나서 실행해봤어요. 그런데 화면이 안 떴습니다. 하얀 화면만 덩그러니. 분명 AI가 코드를 다 만들어줬는데 왜 안 되는 거지? 코딩을 아는 사람이면 코드를 읽고 "아 여기가 문제구나" 했겠죠. 근데 저는 코드를 못 읽잖아요. 화면만 보고 "안 된다"는 사실만 알 뿐이었어요. 순간 막막했습니다. 이러면 앞으로 어떻게 만들지? 그냥 AI한테 다시 물어봤다 방법이 없으니 AI한테 그대로 말했어요. "화면이 하얗게만 나오고 아무것도 안 보여." 그랬더니 AI가 "이런 이유일 수 있다"며 원인을 찾아주고, 고친 코드를 다시 줬습니다. 적용했더니 이번엔 화면이 이상하게 떴어요. 그때 깨달았습니다. AI도 한 번에 완벽한 코드를 주지 않는다는 걸. 대신 뭐가 안 되는지 말해주면 같이 고쳐나갈 수 있다는 것도요. 중요한 건 "에러가 났다"가 끝이 아니라 시작이라는 점이었어요. 에러는 실패가 아니라 과정이다 처음엔 에러가 날 때마다 "내가 뭘 잘못했나" 싶어서 위축됐어요. 근데 하다 보니 알겠더라고요. 에러는 그냥 만드는 과정의 일부입니다. 개발자들도 에러를 수도 없이 만난대요. 그걸 하나하나 고쳐가면서 완성하는 거죠. 코딩을 모르는 저도 똑같았어요. 다만 제가 직접 못 고치니까, AI한테 증상을 정확히 말해주는 게 제 역할이었습니다. "이 버튼을 눌렀더니 아무 반응이 없어", "글자가 화면 밖으로 삐져나와" 처럼요. 의사한테 어디가 아픈지 설명하듯이요. 세 번째 에러에서 알게 된 것 처음 에러가 떴을 때는 당황했습니다. 두 번째, 세 번째 에러가 연달아 뜨니까 "이거 잘못 만...

자세한 내용 보기

5편. AI랑 첫 화면 디자인하기

AI랑 첫 화면 디자인하기 앱을 만들 때 가장 먼저 손댄 건 첫 화면이었습니다. 사람이 앱을 열고 처음 보는 화면. 여기서 "오 괜찮은데?" 싶어야 다음으로 넘어가거든요. 반대로 첫인상이 별로면 그냥 닫아버립니다. 그래서 첫 화면에 제일 공을 들였어요. 어떤 느낌으로 만들지부터 정했다 저는 화려한 걸 싫어합니다. 버튼이 번쩍거리고, 색이 요란하고, 여기저기 글자가 가득한 화면은 보기만 해도 피곤해요. 그래서 방향을 정했습니다. 최대한 덜어내자. 꼭 필요한 것만 남기고 나머지는 다 비우자. 배경은 눈이 편한 베이지색, 글씨는 차분한 검정, 포인트 색은 딱 하나 주황색만. 이렇게 정해두고 시작했어요. 이건 제가 평소에 좋아하는 디자인 철학이기도 합니다. "적게, 그러나 더 좋게." 요소를 더할 이유를 찾지 말고, 뺄 이유를 찾는 거죠. AI한테 어떻게 시켰나 방향을 정했으니 AI한테 전했습니다. 이렇게요. "첫 화면을 만들어줘. 배경은 따뜻한 베이지색. 가운데에 앱 이름을 크게. 그 아래에 한 줄짜리 슬로건. 맨 아래에 시작하기 버튼 하나. 색은 검정과 주황만 써. 화려하지 않고 차분하게." 그랬더니 꽤 그럴듯한 게 나왔어요. 물론 한 번에 완벽하진 않았습니다. 글자가 너무 크거나, 버튼 위치가 어색하거나. 그때마다 "이름을 조금 작게", "버튼을 더 아래로" 하면서 고쳐갔어요. 디자이너의 눈이 빛나는 순간 여기서 제 일이 큰 도움이 됐습니다. AI가 만들어준 화면을 보면 어디가 어색한지 바로 보이거든요. "여백이 답답하다", "글자 간격이 너무 좁다", "이 색이 살짝 탁하다" 같은 걸 잡아낼 수 있어요. 이건 코딩 실력이 아니라 보는 눈의 문제입니다. 그리고 그 눈은 꼭 디자이너가 아니어도, 평소 예쁜 걸 좋아하고 불편한 걸 못 견디는 사람이면 누구나 가질 수 있어요. 저는 그저 "이...

자세한 내용 보기

4편. 무료로 앱 만들 수 있을까

무료로 앱 만들 수 있을까 앱을 만들기로 했을 때 가장 먼저 든 생각은 "돈 얼마나 들까?"였습니다. 개발자를 쓰면 수백만 원, 외주를 맡겨도 만만치 않잖아요. 근데 결론부터 말하면, 저는 거의 돈을 들이지 않고 시작했습니다. 무료 도구만으로도 충분히 시작할 수 있어요. 시작은 무료로 충분하다 AI한테 앱을 만들게 하는 도구들, 대부분 무료로 써볼 수 있는 범위가 있습니다. 처음 감을 잡고 "이게 되는구나" 확인하는 데는 무료로 충분해요. 저도 무료로 시작했습니다. 어느 정도 해보고 "이거 진짜 되겠다" 싶은 가능성이 보였을 때, 그때 월 정액으로 바꿨어요. 처음부터 돈 낼 필요 없습니다. 일단 공짜로 해보고, 될 것 같으면 그때 투자해도 늦지 않아요. 그런데 여기서 진짜 조심할 게 있습니다 무료 도구를 찾다가 제가 크게 당한 일이 있어요. 돈을 뜯겼습니다. 그래서 이건 꼭 짚고 넘어가려고 해요. AI 도구를 쓰려고 검색을 하잖아요. 예를 들어 "Claude"나 "ChatGPT"를 검색창에 칩니다. 그러면 검색 결과 맨 위에 광고로 뜨는 가짜 사이트들이 있어요. 진짜 로고랑 거의 똑같이 생겨서 현혹되기 딱 좋습니다. 저는 그걸 진짜인 줄 알고 들어갔다가 결제까지 해버렸어요. 알고 보니 공식 사이트가 아니었고, 환불도 제대로 안 됐습니다. 결국 은행에 해외 결제 분쟁 신청까지 했어요. 결과가 어떻게 나올지는 아직 모릅니다. "GPT for Google" 같은 이름을 단 가짜 확장 프로그램이나 서비스도 많아요. 공식인 척하지만 아닌 것들이요. 가짜에 안 당하는 법 제가 당하고 나서 정리한 원칙입니다. 1. 검색 결과 맨 위 "광고" 표시된 건 일단 의심하세요. 진짜 공식 사이트는 광고를 안 띄우는 경우가 많아요. 광고 딱지가 붙은 맨 위 결과는 가짜일 가능성이 있습니다. 2. 공식 주소를 직접 확인하세요. Cl...

자세한 내용 보기

3편. AI랑 '규칙'부터 정한 이유

AI랑 '규칙'부터 정한 이유 AI한테 일을 맡기다 보니 문제가 생겼습니다. 분명 잘 되고 있었는데, 어느 순간 앱이 와장창 망가져 있는 거예요. 어디서부터 잘못된 건지도 모르겠고, 되돌릴 수도 없고. 멘붕이 왔습니다. AI는 시키면 시키는 대로 다 한다 문제의 원인은 이거였어요. AI는 제가 시키면 의심 없이 다 합니다. 좋아 보이지만 위험해요. 제가 "이 기능도 추가하고, 저것도 바꾸고, 이것도 고쳐줘"라고 한꺼번에 시키면, AI는 그걸 다 한 번에 처리합니다. 그러다 하나가 꼬이면 어디서 꼬였는지 찾을 수가 없어요. 코딩을 모르는 저는 더더욱요. 사람과 일할 때는 "이거 한꺼번에 하면 위험한데요?"라는 말을 듣잖아요. AI는 그런 말 없이 그냥 합니다. 그래서 멈출 지점을 제가 정해줘야 했어요. 그래서 규칙을 만들었다 이대로는 안 되겠다 싶어서 AI와 일하는 규칙을 정했습니다. 핵심은 세 가지예요. 첫째, 계획부터 짜고 코드는 나중에. 뭔가 만들기 전에 AI한테 "코드 쓰지 말고 계획부터 말해줘"라고 합니다. 계획이 맞으면 그때 코드를 짜게 해요. 바로 코드부터 짜면 엉뚱한 길로 가버리거든요. 둘째, 한 번에 하나씩만. 여러 개를 동시에 시키지 않습니다. 기능 하나 만들고, 잘 되는지 확인하고, 그다음 거. 이렇게 하면 뭔가 망가져도 방금 한 게 원인이니까 바로 찾아요. 셋째, 확인 전에는 다음으로 안 넘어간다. "됐어?"가 아니라 "진짜 되는지 보여줘"라고 합니다. 대충 넘어가면 나중에 한꺼번에 터져요. 규칙이 비개발자한테 더 중요한 이유 개발을 아는 사람이면 망가져도 코드를 읽고 고칠 수 있어요. 근데 저는 못 합니다. 코드를 못 읽으니까요. 그래서 저 같은 비개발자한테는 "망가지지 않게 하는 것"이 "망가진 걸 고치는 것"보다 훨씬 중요해요. 애초에 한 번에 하나씩, 확인하면서 ...

자세한 내용 보기

2편. AI한테 뭐라고 시켜야 할까

AI한테 뭐라고 시켜야 할까 바이브 코딩이라는 걸 알게 됐을 때, 바로 이거다 싶었습니다. 내가 코드를 짜는 게 아니라 AI한테 말로 시키면 AI가 코드를 짜준다니. 코딩을 모르는 저한테는 딱 맞는 방식이었어요. 그래서 앱 만들기를 시작했습니다. 근데 막상 AI 앞에 앉으니 5분 동안 아무것도 못 했어요. 뭐라고 해야 할지 몰랐거든요. "앱 만들어줘"라고 하면 될까? 처음엔 막연하게 생각했어요. AI가 똑똑하다니까 "여행 일정 앱 만들어줘" 하면 뚝딱 나오는 거 아닌가? 안 됩니다. 정확히는, 뭔가 나오긴 하는데 제가 원하던 게 아니에요. 너무 막연하게 시키면 AI도 막연하게 답합니다. 이건 사람과 일하는 거랑 똑같았어요. "알아서 잘해줘"라고 하면 절대 알아서 잘 안 되잖아요. 사람과 소통하던 방식 그대로 여기서 제 일이 의외로 도움이 됐습니다. 저는 디자인 회사를 운영하면서 동시에 국내 대기업에서도 일하고 있습니다. 양쪽에서 매일 수많은 사람들과 소통해요. 디자이너와, 개발자와, 협력업체와. 일의 방향을 잡고, 의도를 전하고, 결과를 맞춰가는 게 제 일상입니다. AI와 일하는 게 딱 그거였어요. 사람과 소통하듯 하면 되더라고요. 좋은 결과를 얻으려면 상대에게 의도를 정확히 전해야 합니다. "알아서 잘"은 사람한테도 AI한테도 안 통해요. 대신 "이런 목적으로, 이런 느낌으로, 여기엔 이걸 넣어달라"고 구체적으로 전하면 AI도 그만큼 정확하게 답합니다. 막연하게 말고, 구체적으로 예를 들어 "첫 화면 만들어줘"가 아니라 이렇게요. "첫 화면에 앱 이름을 크게 넣고, 그 아래에 슬로건 한 줄, 맨 아래에 시작하기 버튼 하나. 배경은 베이지색, 글씨는 검정, 버튼은 주황색으로." 디자이너에게 시안을 요청하듯 구체적으로 전하니까 훨씬 제가 원하던 것에 가까운 게 나왔어요. 디자이너라서 다행이었던 점 제 직업이...

자세한 내용 보기

1편. 코딩 모르는 디자이너, AI로 앱 만들기

코딩 모르는 디자이너, AI로 앱 만들기 저는 여행 갈 때 계획이 없습니다. 비행기 표 끊고, 호텔 예약하고, 끝. 공항에서 호텔까지 어떻게 가는지, 호텔 근처에 뭐가 맛있는지, 그런 건 가서 생각합니다. 아니, 사실 가서도 잘 안 찾아봐요. 전형적인 P. 그것도 극P입니다. 그런 제가 여행 "계획" 앱을 만들기 시작했습니다. 좀 웃기죠. 계획이라면 질색하는 사람이 계획 짜주는 앱이라니. 근데 바로 그래서 만들기로 한 겁니다. 사실 여행을 잘 못 다녔습니다 솔직히 말하면 저는 여행 경험이 많지 않습니다. 일에 치여 살다 보니 다니는 건 거의 출장뿐이었어요. 제대로 마음먹고 떠나는 여행은 손에 꼽습니다. 그러니 여행 계획이라는 걸 세워본 적도 거의 없어요. 그렇다고 여행을 싫어하는 건 아닙니다. 오히려 좋아해요. 호텔 수영장에서 피맥 한잔하다가 더우면 물에 풍덩 들어가는 거, 그런 여유를 정말 좋아합니다. 동시에 현지 로컬 음식점을 찾아가거나 그 지역에서만 할 수 있는 액티비티를 즐기는 것도 좋아하고요. 문제는, 그런 걸 제가 직접 찾아서 계획해본 적이 없다는 거예요. 늘 누가 "여기 가자" 하면 따라가는 쪽이었습니다. 일행이 짜온 일정에 몸을 싣는 거죠. 혼자였으면 호텔에만 있다 왔을지도 몰라요. 계획이 싫은 게 아니라, 짜는 과정이 싫은 거였다 곰곰이 생각해봤습니다. 저는 왜 여행 계획을 못 짤까요? 여행지에서 뭘 하기 싫은 게 아닙니다. 로컬 맛집도 가고 싶고, 좋은 코스로 다니고 싶어요. 근데 그걸 위해 검색하고, 비교하고, 동선 짜고, 시간 계산하는 그 과정이 너무 막막한 겁니다. 가고 싶은 곳 하나 정하려 해도 거기까지 가는 길, 근처에서 밥 먹을 곳, 숙소에서의 거리, 다음 날 일정까지 다 따로 찾아서 머릿속에서 조립해야 합니다. 그 순간 "아 그냥 누가 짜줬으면" 소리가 나옵니다. 저 같은 사람 분명 많을 거예요. 떠나고 싶은 마음은 있는데, 그 앞에 놓인 귀찮은 준비...

자세한 내용 보기