UIpac

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

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

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

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

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

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

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

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

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

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

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

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

RAG 개념 공부, 문서 검색과 생성을 붙이는 구조

요즘 AI 관련 글을 읽다 보면 RAG라는 말이 정말 자주 나옵니다.Retrieval-Augmented Generation, 우리말로 하면 "검색으로 보강한 생성" 정도가 되겠네요.처음에는 이름이 어렵게 느껴졌는데, 공부해 보니 아이디어 자체는 꽤 단순했어요.모델이 모르는 내용을 찾아서 읽게 한 뒤에 답하게 하는 구조입니다.예약 서비스에 자주 묻는 질문(FAQ) 응답을 붙인다면 어떻게 쓸 수 있을지를 떠올리며 공부한 내용을 정리해 봅니다.직접 서비스에 적용해 본 이야기가 아니라, 개념을 이해하고 아이디어를 그려본 기록이라는 점을 먼저 말씀드려요. ChatGPT 같은 모델은 학습한 데이터를 바탕으로 답합니다.그래서 아무리 똑똑해도 모르는 것이 두 종류 있어요.하나는 학습 이후에 생긴 새로운 정보이고, 다른..

권한 모델 기획, 테넌트 관리자·직원·고객의 역할 나누기

예약 시스템에는 생각보다 다양한 종류의 사람이 들어옵니다.업장을 운영하는 사장님, 현장에서 일하는 직원, 예약하는 고객, 그리고 서비스 전체를 관리하는 플랫폼 운영자까지요.이들이 한 시스템을 같이 쓰기 때문에 "누가 무엇을 볼 수 있고, 무엇을 바꿀 수 있는가"를 정리하는 권한 모델이 꼭 필요해집니다.기획 초반에는 "사장님은 다 되고 직원은 일부만 되고"처럼 감으로 정리하기 쉬운데, 막상 화면과 데이터를 하나씩 따져보면 이야기가 복잡해져요.이번 글은 권한 모델을 기획하면서 제가 정리해 본 순서를 기록한 것입니다. 권한을 사람마다 하나하나 부여하면 관리가 금방 무너집니다.그래서 많은 서비스가 쓰는 방식이 역할 기반 접근 제어, 줄여서 RBAC예요.사람에게 직접 권한을 주는 대신 "역할"을 만들고, 역할에 ..

예약 노쇼를 줄이는 정책 설계, 보증금·리마인드·취소 규정

예약 서비스를 기획하면서 운영하시는 분들 이야기를 들어보면, 거의 빠지지 않고 나오는 하소연이 노쇼입니다.예약해 놓고 아무 연락 없이 오지 않는 고객 때문에 빈 시간이 생기고, 그 시간은 되돌릴 수 없으니까요.예약 시스템이 단순히 "예약을 받는 도구"를 넘어서려면, 이 문제를 어떻게 줄여줄 수 있는지가 중요한 기능이라는 생각이 들었어요.이번 글은 노쇼를 줄이기 위한 정책 선택지를 정리하고, 고객 경험과 어떻게 균형을 잡을지 고민한 내용입니다.숫자는 모두 설명을 위한 가정입니다. 노쇼의 비용은 "그 시간의 매출이 사라진다"에서 끝나지 않는다고 느꼈어요.가상의 예를 들어볼게요.커트와 염색을 하는 작은 미용실에서 염색 예약 한 건이 노쇼가 났다고 해보겠습니다.염색은 두세 시간짜리라서, 그 시간 동안 직원은 대..

노코드 AI 도구, 업무에 쓸 만한 것들 써보기

올해 들어 "AI 기능이 들어갔다"는 도구가 하루가 멀다 하고 쏟아지고 있어요.문서 도구에도, 메모 앱에도, 디자인 도구에도 AI 버튼이 하나씩 생기는 중입니다.기획 일을 하면서 코드를 쓰지 않고도 쓸 수 있는 AI 도구들을 몇 달간 이것저것 써봤는데, 막상 정리해 보니 제품 이름보다 "어떤 종류의 일에 맞는가"가 훨씬 중요했어요.그래서 이번 글에서는 특정 제품을 추천하기보다 종류별로 써본 소감을 적고, 제가 도입 여부를 판단하는 기준을 정리해 보려고 합니다.도구들은 빠르게 바뀌어서, 이 글의 내용도 몇 달 뒤엔 달라질 수 있다는 점은 미리 말씀드립니다. 글 요약과 정리 도구 가장 먼저, 그리고 가장 오래 쓰게 된 종류입니다.긴 글이나 자료를 붙여 넣고 "핵심을 다섯 줄로 요약해줘", "항목별로 정리해..

테넌트별 요금제와 기능 제한 설계

예약 시스템을 업장마다 따로 쓰는 구조(테넌트)로 기획하다 보면, 어느 시점엔 반드시 "그럼 요금제는 어떻게 나누죠?"라는 질문을 만나게 됩니다.요금제는 가격표만의 문제가 아니라서, 어떤 기능을 누구에게 열어줄지, 한도를 넘으면 어떻게 할지가 함께 정해져야 해요.창업을 정리하던 시기에 가격과 수익 모델을 공부했던 기억이 있는데, 실제 테넌트 구조에 얹어서 생각해 보니 훨씬 구체적인 설계 문제가 되더라고요.이번 글은 요금제를 어떤 단위로 쪼갤지, 변경과 해지 때는 어떤 정책이 필요한지 정리한 기록입니다.금액이나 수치는 모두 설명을 위한 가정입니다. 요금제를 설계할 때 저는 제한을 두 종류로 구분하면 훨씬 정리가 쉬웠어요.첫째는 기능 플래그입니다.어떤 기능을 쓸 수 있는지 없는지를 켜고 끄는 성격이에요.예를..

프롬프트 엔지니어링 공부 노트, 자주 쓰는 패턴 정리

ChatGPT를 쓰기 시작한 지 몇 달이 지나면서, 같은 질문인데도 결과가 들쭉날쭉한 경험을 자주 하게 됐어요.어떤 날은 놀랄 만큼 정리가 잘 되어 나오고, 어떤 날은 엉뚱한 방향으로 흘러갑니다.그래서 "내가 뭘 다르게 썼지?"를 되짚어 보다가 프롬프트 작성법을 따로 공부하기 시작했습니다.이번 글은 공부하면서 정리한 패턴 다섯 가지와, 제가 직접 써본 예, 그리고 한계를 적어둔 노트입니다.전문가가 쓴 글은 아니고, 기획 일을 하면서 써보고 남긴 기록이라고 생각해 주세요. 공부하다 보니 좋은 프롬프트의 조건이 좋은 요구사항 정의서와 비슷하다는 생각이 들었어요.누가 읽는지, 무엇을 원하는지, 어떤 형식으로 받고 싶은지, 하지 말아야 할 것은 무엇인지가 빠지면 결과가 흔들립니다.사람 개발자에게 "예약 알림 좀..