전체 글

2024년의 방향 정리, 예약 시스템 기획과 AI 공부 사이에서

벌써 5월입니다.연초에 세운 계획을 슬슬 다시 열어봐야 할 시기인 것 같아서 이번 글에서는 올해의 방향을 한 번 정리해보려고 합니다.요즘 가장 자주 하는 고민은 시간을 어디에 쓰느냐입니다.한쪽에는 맡고 있는 예약 서비스 기획이 있고, 다른 쪽에는 꾸준히 이어가고 싶은 AI 공부가 있어요.둘 다 재미있고 둘 다 의미가 있다 보니, 오히려 "어느 하나를 줄여야 하나" 하는 마음이 들 때가 있습니다. 먼저 두 갈래를 각각 어떻게 이해하고 있는지 적어보겠습니다.첫 번째는 도메인 기획의 깊이입니다.예약 서비스는 겉으로 보면 단순해 보여도 파고들수록 정책이 많이 얽혀 있습니다.영업시간과 휴무, 서비스 소요시간, 직원별 일정, 취소 규정, 알림, 권한 같은 것들이 서로 연결되어 있어요.이걸 제대로 알아야 "이 정책을..

예약 시스템의 정산과 환불 정책, 테넌트에게 돈이 흐르는 길

예약 서비스를 기획하다 보면 결제 화면까지는 금방 그려집니다.그런데 그 돈이 그 뒤에 어디로 가는지 묻는 순간부터는 이야기가 갑자기 어려워집니다.플랫폼이 받는 돈은 얼마이고, 업장은 언제 얼마를 받는지, 고객이 취소하면 누구 몫에서 빠지는지를 정해야 하거든요.테넌트 구조의 예약 시스템에서는 이 질문이 더 무거워요.업장마다 취소 규정이 다르고, 정산을 받고 싶은 주기도 다르기 때문입니다.세금, 법률, 결제대행사(PG)의 세부 규정은 제가 단정할 수 있는 영역이 아니라서, 그런 부분은 "확인 필요"로 따로 표시해두었습니다.본문의 금액과 비율은 모두 설명을 위한 가정 예시이고, 실제 서비스의 수치가 아닙니다. 가장 단순하게 그리면 돈은 고객의 결제, 플랫폼의 수수료 차감, 테넌트로의 정산이라는 세 정류장을 지..

GPTs로 나만의 기획 보조 도구 만들어본 기록

2023년 11월에 GPTs라는 기능이 공개됐어요.코드를 쓰지 않고도 나만의 맞춤형 챗봇을 만들 수 있다는 소개였습니다.처음에는 솔직히 "결국 프롬프트를 저장해두는 기능 아닌가" 하고 가볍게 생각했어요.그런데 예약 서비스 기획을 하면서 비슷한 요청을 ChatGPT에 반복해서 붙여 넣고 있다는 걸 깨달았습니다.매번 "너는 꼼꼼한 기획 리뷰어야, 아래 문서를 읽고..." 하고 같은 문장을 복사하고 있었거든요.그 반복을 줄여보고 싶어서 몇 주 동안 이것저것 만들어봤습니다.이 글은 그 기록입니다.제품의 세부 사양을 정리하는 글은 아니고, 만들어보며 느낀 개념과 경험 위주로 적어봤어요.화면 구성이나 제한 사항은 계속 바뀌는 것 같아서, 정확한 내용은 공식 안내를 보시는 게 맞습니다. 제가 이해한 GPTs의 핵심은..

ChatGPT 1년, 공부 기록과 다음 계획

이번 주가 지나면 ChatGPT가 공개된 지 딱 1년이 됩니다.작년 이맘때 처음 접속해서 "오, 이게 되네?" 하고 신기해하던 기억이 아직 생생한데요.벌써 1년이라니 시간이 참 빠르다는 생각이 듭니다.그래서 이번 글은 새로운 기술 소식을 정리하기보다는 제가 지난 1년 동안 무엇을 공부했고, 그게 일하는 방식에 어떤 변화를 줬는지 돌아보는 기록으로 남겨보려고 합니다.거창한 성과가 있는 건 아니고, 예약 시스템 기획을 하면서 틈틈이 공부한 흔적을 모아보는 정도예요. 돌이켜보면 공부는 대략 네 단계로 이어졌습니다.처음은 그냥 써보는 것이었습니다.질문을 던지고, 글을 다듬게 하고, 아이디어를 뽑게 하면서 "어떤 일에 잘 맞고 어떤 일에 안 맞는지" 감을 잡는 시기였어요.이때 가장 크게 배운 건 그럴듯하게 틀린 ..

멀티모달이 왔다, 이미지를 이해하는 모델로 무엇을 할 수 있나

이번 가을에 가장 눈에 띄는 소식은 이미지를 함께 이해하는 모델이 실제로 쓸 수 있는 형태로 나오기 시작했다는 점이었습니다.그동안 ChatGPT를 쓰면서 글자로만 대화하는 데 익숙해져 있었는데요.사진을 한 장 올리고 "이게 뭐야?" 하고 묻는 장면이 현실이 된다는 게 꽤 낯설면서도 설레었습니다.저는 요즘 예약 시스템 기획을 하면서 AI 공부를 같이 하고 있어서, 이런 소식이 나오면 늘 같은 질문으로 돌아옵니다."이게 예약 서비스에서는 어디에 쓰일 수 있을까?"오늘은 아직 확정된 사실보다는 공부하면서 정리한 생각이 많다는 점을 먼저 말씀드리고 시작하겠습니다. 멀티모달은 말 그대로 여러 형태의 정보(글, 이미지, 소리 등)를 함께 다루는 것을 말합니다.이번에 화제가 된 것은 그중에서도 이미지를 입력으로 받아..

예약 데이터에서 놓치기 쉬운 것, 시간대·중복 예약·동시성

예약 시스템 기획서를 쓰다 보면 정상 흐름은 꽤 매끈하게 정리됩니다.고객이 시간을 고르고, 예약이 생성되고, 알림이 나가고, 방문하면 끝나는 흐름이에요.그런데 개발자와 이야기를 하다 보면 "그럼 두 명이 동시에 같은 시간을 누르면요?" 같은 질문이 나오고, 그제야 기획서에 비어 있던 부분이 보이곤 합니다.이 글은 제가 예약 데이터를 기획하면서 놓치기 쉽다고 느낀 세 가지인 동시성, 시간대, 이력 보관을 정리한 기록입니다. 가장 먼저 만나는 문제가 동시성입니다.가정 예시를 들어볼게요.미용실 디자이너 한 분의 오후 3시 슬롯이 하나 남아 있습니다.고객 A와 B가 거의 같은 순간에 이 슬롯을 보고 예약 버튼을 누릅니다.두 사람 모두 화면에서는 "예약 가능"으로 보였기 때문에, 시스템이 아무 장치 없이 둘 다 ..

생성형 AI 저작권과 윤리, 공부하며 정리한 쟁점

생성형 AI를 공부하다 보면 기술 이야기만큼 자주 만나는 주제가 저작권과 윤리입니다.서비스에 AI 기능을 넣는다면 이 문제를 피해갈 수 없을 것 같아서, 기사와 공개된 논의를 읽으며 쟁점을 정리해보았습니다.먼저 분명히 해둘 점이 있습니다.저는 법률 전문가가 아니고, 이 글은 공부한 내용을 정리한 메모일 뿐 법률 자문이 아닙니다.이 분야는 아직 논의 중인 부분이 많아서, 실제 서비스에 적용할 때는 반드시 전문가의 검토와 최신 공식 안내를 확인해야 한다고 생각해요. 가장 먼저 눈에 띄는 쟁점은 모델이 무엇으로 학습했느냐입니다.이미지나 글을 생성하는 모델은 방대한 데이터로 학습하는데, 그 안에 창작자가 만든 작품이 들어 있을 수 있다는 점이 논란의 중심이에요.창작자 입장에서는 허락 없이 자신의 작품이 학습에 ..

챗봇으로 예약 받기, 자연어 예약 시나리오 기획

예약 서비스를 기획하다 보면 한 번쯤 이런 상상을 하게 됩니다.고객이 폼을 채우는 대신 "다음 주 목요일 저녁에 두 명 자리 있어요?"라고 말하면 알아서 예약까지 이어지면 좋겠다는 상상이에요.LLM을 공부하면서 이 상상이 꽤 현실적인 범위에 들어왔다고 느꼈고, 그래서 시나리오를 기획 문서 수준으로 한 번 그려봤습니다.이 글은 제가 정리한 구조와, 그 과정에서 가장 중요하다고 느낀 책임 분리에 대한 기록입니다. 자연어로 예약을 받는 일을 분해해보면, 결국 필요한 정보를 모으는 일입니다.예약 한 건이 성립하려면 최소한 어떤 서비스인지, 날짜와 시간은 언제인지, 몇 명인지, 누구에게 연락하면 되는지가 필요해요.이 필요한 항목들을 흔히 슬롯이라고 부르고, 고객 발화에서 슬롯을 채워 나가는 방식을 슬롯 채우기라고..

임베딩과 벡터 검색, 따라 해본 기록

RAG를 공부하다 보면 어느 설명에서나 "임베딩"이라는 단어가 먼저 튀어나옵니다.처음에는 용어만 익숙해지고 실제로 무슨 일이 일어나는지는 와닿지 않았어요.그래서 개념 설명을 읽고, 작은 예제를 따라 해보고, 그 내용을 기획자가 이해할 수준으로 다시 적어보기로 했습니다.개발자가 아니라서 코드를 깊게 다루지는 않았고, 어떤 입력이 들어가서 어떤 출력이 나오는지 흐름을 확인하는 데 집중했습니다. 임베딩을 한 문장으로 말하면, 글의 의미를 숫자들의 나열(벡터)로 바꾸는 것입니다.모델에 문장을 넣으면 수백에서 수천 개 정도의 숫자가 나오는데, 이 숫자들이 그 문장의 의미를 좌표처럼 나타냅니다.핵심은 의미가 비슷한 문장일수록 좌표가 가깝게 놓이도록 만들어진다는 점이에요.예를 들어 아주 단순하게 숫자를 세 개로 줄여..

예약 시스템 어드민 화면, 정보 구조부터 잡기

예약 시스템 기획을 하다 보면 고객이 보는 예약 화면에 신경이 먼저 가기 쉽습니다.그런데 막상 서비스가 돌아가기 시작하면 매일 가장 오래 들여다보는 건 운영하시는 분들이 쓰는 어드민 화면이에요.예약이 아무리 잘 들어와도, 어드민에서 확인하고 고치고 처리하는 일이 불편하면 서비스는 금방 외면받습니다.이 글에서는 어드민 화면을 그리기 전에 정보 구조부터 잡으면서 정리한 생각을 기록해봅니다. 처음에는 기능 목록을 그대로 메뉴로 만들었습니다.예약 관리, 고객 관리, 서비스 관리, 직원 관리, 통계, 설정 같은 식이에요.틀린 구조는 아니지만, 이대로 두면 운영자의 하루와 메뉴가 맞지 않는다는 걸 곧 알게 됐습니다.그래서 운영하시는 분이 하루에 하는 일을 순서대로 적어봤습니다.가정 예시로 동네 미용실 원장님의 하루..

LLM의 환각, 기획 단계에서 정해둘 것들

ChatGPT를 쓰다 보면 그럴듯하지만 사실이 아닌 답을 만나는 순간이 반드시 옵니다.없는 논문을 실제 있는 것처럼 인용하거나, 존재하지 않는 기능을 자신 있게 설명하는 식이에요.흔히 이런 현상을 환각(hallucination)이라고 부릅니다.개인이 대화창에서 쓸 때는 "확인해보면 되지" 하고 넘어갈 수 있지만, 서비스 안에 넣는다면 이야기가 달라집니다.이 글에서는 제가 공부하면서 "개발에 들어가기 전에 기획이 먼저 정해둬야 한다"고 느낀 것들을, 예약 안내 챗봇을 가정해서 정리해봅니다. 환각이 있다는 사실 자체보다, 어디에서 그것이 문제가 되는지를 구분하는 게 먼저라고 생각했습니다.모델이 지어낸 말이 "무해한 틀림"인지, 사용자의 돈이나 시간에 영향을 주는 "해로운 틀림"인지가 다르기 때문이에요.예약 ..

예약 알림 설계, 알림톡·문자·푸시 선택 기준

예약 시스템을 기획하면서 처음에는 알림을 "나중에 붙이는 부가 기능" 정도로 생각했습니다.그런데 예약 흐름을 한 줄로 그려보니, 알림이 빠지면 흐름이 이어지지 않는 지점이 생각보다 많더라고요.예약이 잘 됐는지 고객이 믿을 수 있는 것도, 노쇼가 줄어드는 것도, 운영하시는 분이 새 예약을 놓치지 않는 것도 결국 알림이 맡는 일이었습니다.이번 글에서는 알림을 언제, 어떤 채널로, 어떤 문구로 보낼지 정리하면서 세운 기준을 기록해봅니다. 채널을 고르기 전에 "언제 알려야 하는가"부터 적는 게 순서가 맞다고 느꼈습니다.채널은 나중에 바꿀 수 있지만, 시점이 빠져 있으면 서비스 경험에 구멍이 나기 때문이에요.예약 한 건의 생애주기를 따라가며 적어보면 대략 이런 목록이 나옵니다.예약 완료 직후에는 "예약이 접수되었..