<img src="https://image.until.blog/grandff/article/1718942598885" alt="until-638"><p></p><h2>나처럼 육아에 바쁜 아빠들을 위한 앱.</h2><hr><p>주말에 아이랑 집에만 있으면 "정말" 시간이 안간다. 집밖에 아이와 갈만한 곳을 찾는 것도 생각보다 복잡하고 어려운 과제가 된다. 나같은 경우, 여러 포털사이트나 소셜미디어를 뒤져보곤 한다. 물론 유용한 정보를 자주 찾진 못했다. born to be 집돌이 태생이여서 어느 지역에 뭐가 유명한지도 모르고, 네비를 봐도 길을 헤매는 내가 여기가 어딘지 정확히 찾을리가... 이렇게 모르다 보니 장소를 찾는데도 시간이 많이 걸리고 후기까지 찾으면 주말이 다 지나가버렸다.</p><p>언제인지 기억은 안나지만, '어렸을 때부터 아이와 여행을 많이 다니고, 아빠의 육아참여가 자녀의 발달에 더 좋다'는 글을 봤다. 그래서인지 더더욱 아이와 어디 갈지를 고민하던 찰나에 나와 같은 생각을 가진 부모님들이 있지 않을까 싶었다. 아이와 함께 할 수 있는 활동에 관심이 많음에도 불구하고, 필요한 정보를 찾는 데 있어서 어려움을 겪는 경우가 많은 분들을 위한 서비스를 만들어볼까하고 시작한게 <strong>아랑아랑</strong> 프로젝트다. <strong>아이와 함께 갈 만한 여행지나 놀이 공간 정보를 모아 손쉽게 찾을 수 있는 앱</strong>을 목표로 시작하게 되었다.</p><p></p><h2>1인 팀 결성.</h2><hr><blockquote><p>나에겐 참 안타까운 일이지만 내 주변에 사이드 프로젝트를 하는 사람도 없고, 육아를 하는 사람도 없다. 강제로 1인 팀을 할 수 밖에 없었다.</p></blockquote><p>당시 회사에서 개발 사업이 WBS 기준 중후반 정도 왔을 때고, 개발 완료 시기까지 7개월 가량 남은 시점이었다. 아직 개발 사업이 진행 중이고, 육아와 집안일까지 해야해서 사이드 프로젝트에 사용할 시간을 그야말로 쥐어짜내야했었다. (출근 전 1시간, 점심시간 1시간, 애들 재우고 30분)</p><p></p><h2>시장분석.</h2><hr><blockquote><p>'<strong>오늘 하루</strong>' 갈 수 있는 여행지를 제공하되 공공데이터와 나만의 데이터를 결합하는 방향으로 잡았다.</p></blockquote><p>내가 생각하는 서비스는 시장에 이미 3~4개 정도 있었다. 장단점이 각각 있겠지만, 내가 주목한건 <strong>혼자서 만들고 운영할 수 있는 서비스인가</strong> 라는 것이다. 다른 서비스들처럼 주변 숙박업소의 할인정보를 제공하고, 예약 시 추가 할인 혜택을 주거나, SNS 홍보 자료도 작성하고.. 이런 작업을 본업을 하면서 하기엔 불가능인게 뻔했다. 그래서 아래처럼 방향을 잡고 시작했다.</p><h3>1. 무조건 당일 치기</h3><p>우리 가족은 일단 1박을 선호하지 않는다. 여름휴가나 겨울방학이나 특별한 시즌이 아니면 무조건 차로 갈 수 있는 당일치기 장소를 선호했다. 그래서 '오늘 하루'에 다녀올 수 있는 곳 위주로 정보 제공과 추천을 하려했고, 당연히 위치 정보 기반으로 서비스를 구성했다.</p><h3>2. AI 활용</h3><p>이번 사이드프로젝트를 하면서 유독 공공데이터를 많이 봤는데, 지자체마다 운영하는 공공데이터는 정확도가 너무 떨어졌다. 물론 관광공사에서 제공하는 데이터를 가지고 어느정도 활용이 가능했으나 실시간으로 변하는 정보(예를 들어 꽃구경이나 휴관일 정보 등)는 실시간 정보가 필요했다. 일일이 찾을 수는 없기에 자동화 프로세스가 필요했고, Langchain을 이용해 정보를 찾아 요약하는 프로세스를 구성했다.</p><h3>3. 디자인은 무리무리무리무리무리무리</h3><p>초등학생 때 미술학원을 다녔는데, 당시 선생님이 하셨던 말이 아직도 기억 난다.</p><p><em>" 색칠만 하면 그림이 이상해지네 ... ? "</em></p><p>색조합만 했다하면 카레가 똥이 되는 마법을 부렸고, 성인이 되어서도 나아지진 않았다. 그래서 디자인시스템을 참고하는 방향으로 했고, 스포카 디자인 가이드를 많이 참조했다. 화면은 와이어프레임만 그리고, dribble, mobbin, wwit 등 참고할만한 화면을 보면서 자체 디자인을 했다.</p><p></p><h2>시~작!</h2><hr><p>사이드 프로젝트가 처음은 아니지만 그렇다고 계속 유지해본 사이드 프로젝트가 있는 것도 아니였다. 지난번 부족한 점이 무엇인고하니 <strong><u>문서화</u></strong>를 전혀 하지 않았다. 그때만 하더라도 주니어(지금도 마음만은 주니어)여서 문서의 중요성을 얕잡아보고 코드만 바라보는 바보천치였다.</p><p>이번에는 동일한 실수를 하지 않겠다는 의미에서 기획부터 시작해서 사소한것 하나하나 문서로 시작해서 문서로 끝나는 작업을 많이 했다. 당시 회사 프로젝트가 진행 중이였고, 사이드 프로젝트 개발 기간이 길어지면 출시하기 어렵다고 판단해서 '<strong>8개월</strong>'로 개발 기간을 잡았다.</p><img src="https://image.until.blog/grandff/article/1718948390050" alt="until-641"><p>앱 이름은 '<strong>아빠와 아이가 함께 하는 여행</strong>' 이라는 의미로 '<strong>아랑아랑</strong>' 이라고 지었다.</p><img src="https://image.until.blog/grandff/article/1718948374179" alt="until-640"><p>지금 다시 보니 시스템 구성도가 참 저렴하게 그렸지만 아무튼 위와 같았다.</p><blockquote><h3>Front-end</h3><p>flutter를 사용하고 앱만 제공할거라 웹 버전은 고려하지 않았다.</p><h3>Back-end</h3><p>Spring Boot를 주로 사용하고 (MVC), LLM, 데이터 수집 등은 FastAPI를 사용했다.</p><h3>Cloud Infra</h3><p>최초 구축 시 NHN Cloud를 사용했고, CI/CD는 github action을 사용했다.</p></blockquote><p>개발하는 중간에 디자인을 바꿔 재개발하거나 테스트 중 발견한 수많은 오류 때문에 이거 진짜 가능? 이라는 생각까지 들었지만 정신 단디 차리고 최초 버전을 출시하는데 성공했다.</p><p></p><h2>아랑아랑 출시.</h2><hr><img src="https://image.until.blog/grandff/article/1718948746716" alt="until-642"><p>최초 출시 화면이다. 출시 후 노마드코더와 렛플에도 홍보글을 올렸다. 보통 내가 만든 서비스는 내 주변 지인한테 츄라이츄라이를 하는게 국룰이던데, 육아를 하는 사람이 나 혼자더라... 그래서 서비스 홍보를 직접 해야했었는데 이때부터 사이드 프로젝트를 벗어나 제2업무를 하게 된 것 같다. (그것도 수익이 거의 발생 안하는) 늘어나지 않는 사용자를 보며 추가 개발과 버그 수정을하며 앱을 계속 고쳐나갔다.</p><p></p><h2>출시 했다고 끝난게 아니란다.</h2><hr><h3>1. 비용 줄이기</h3><p>처음에 NHN Cloud로 백엔드 단을 배포해서 사용했는데, 유지비용이 너무 많이 들었다. 대안을 찾다보니 Serverless로 가능한 <strong>Google Cloud Run</strong>을 알게 되서 인프라를 이쪽으로 옮겼고, 현재까지도 만족하며 사용 중이다. Cloud Run에서 도커로 배포하는 옵션을 설정하면 레포지토리에 있는 도커파일을 읽어다가 자동으로 배포해줘서 특히 편했다.</p><h3>2. 직접 홍보하기</h3><p>홍보 채널을 찾으면서 인스타그램만한게 없었다. 인스타그램같은 SNS에서 여행지 정보 찾는걸 대체하기 위해 만들었지만 아이러니하게 홍보를 인스타그램에서 해야하는 상황이 왔다. 단순히 홍보 채널로만 이용하기엔 뭔가 심심한 면이 있어서 아이랑 다녀온 여행 후기도 같이 올리면서 아랑아랑의 창구로 사용하고 있다. 물론 인스타와 앱 서비스 운영을 병행하니 할일도 두배로 늘어났지만 이를 통해 유입되는 신규 사용자도 있어 홍보 효과를 톡톡히 봤다.</p><h3>3. UI/UX 개편</h3><p>최초 출시에는 여행지 카테고리가 20개였는데, 이게 사용자 입장에서 선택도 애매하고, 관리하는 입장에서도 확인 어려워 카테고리를 8개로 압축시켰다. 직접 사용을 계속 하다보니 사용자에게 계속 터치를 강요하는 UX로 구성되어 있었다. 그래서 사용자가 찾기 전에 서비스에서 위치나 취향에 맞게 데이터를 제공하는 방식으로 변경했다. 위치 기반은 유지하면서 날씨에 맞는 여행지를 추천하거나, 지역별로 특정 테마에 맞게 여행지를 취합해 정보를 제공하게 수정했다.</p><h3>4. AI 기능 강화</h3><p>처음에는 Chat-gpt를 사용해 해당 여행지 정보를 찾거나 검색 API를 사용해 정보를 요약하는 수준으로만 활용했는데, 할루시네이션 이슈가 심했고 답변을 생성하는데 너무 오래 걸렸다. 그래서 랭체인으로 사용자가 자주 접속하는 시간대 직전에 자주 찾는 여행지에 대한 최근 정보를 요약해서 제공하는 걸로 수정했다.</p><h3>5. 사용자 참여 유도</h3><p>사용자가 사용을 하지 않으면 아무리 질좋은 서비스라도 의미가 없기에 마일리지 서비스를 통해 활동에 대한 보상을 부여해서 참여를 유도했다.</p><p></p><h2>계속 개발하고 고치고 유지하며 느낀점.</h2><hr><img src="https://image.until.blog/grandff/article/1718950471330" alt="until-643"><img src="https://image.until.blog/grandff/article/1718950485876" alt="until-644"><p>마일리지 기능까지 추가하고나서야 최소한으로 구현이 필요한 것들은 모두 추가했다. 첫 출시 이후 7개월이나 더 시간을 썼으니 1년 넘게 운영하면서 개발을 해왔다. 아직까지 많은 유저수를 확보하진 못했지만 내가 끝까지 만들고 유지하는 서비스라 그런지 애착이 가서 끊임 없이 들여다보고 개선하고 있다.</p><p></p><p>이 사이드 프로젝트를 하면서 내 스스로 기회를 만들었다고 생각이 든다.</p><p>어떻게 하면 아이디어를 구체화할지, 어떻게 하면 더 효율적인 환경을 구축할지, 어떻게 하면 사용자들이 클릭하게 되는 서비스나 포스팅을 올릴지, 어떻게 하면 서비스 품질을 높일지.. 다양한 고민을 하면서 이것저것 찾아보게 되고, 보는 시야를 어제보다 더 넓어지는 기회를 얻었다고 생각한다.</p><p>나보다 훨씬 뛰어난 분들이 많아 감히 왈가왈부 하긴 그렇지만, 그래도 감히!! 말할 수 있다.</p><p><strong><u>사이드 프로젝트.. 당장해!!!</u></strong></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><hr><p></p><p></p>

사이드프로젝트를 개발하고, 런칭하고, 운영하고, 개선하면서 느낀 점을 주저리주저리 적어봤습니다.

아랑아랑 개발 후기(+1년간 유지하면서)

CodingTest

혹시 좋은 방법이나 공부하신 포스팅이 있다면 공유부탁드려요! 
아직 초보인지라 배울점이 많습니다 ㅎㅎ!

너무... 힘들게 푸시는게 아닐까요..ㅎㅎ

글또 10기

<blockquote><p>글또 10기의 1주차 글입니다.</p></blockquote><hr><p> 나는 글을 쓰는 걸 좋아한다. 아니, 정확히 말하자면 기록하는 걸 좋아한다. 일기를 쓰는 것도, 책을 읽고 난 후 느꼈던 감정이나 떠오른 생각들을 독후감으로 남기는 것도, 그리고 마음에 들었던 문장이나 시를 적어두는 일도 나에겐 중요한 일상의 한 부분이다. 나는 내가 경험한 것들을 글로 남겨놓고, 그 글을 나중에 다시 읽으면서 그때의 나를 되돌아보는 걸 좋아한다.</p><p>처음 일기를 쓰기 시작한 이유는 과거를 잊기 싫었기 때문이다. 시간이 지나면서 내 기억 속에서 희미해져 갈 나날들이 아쉬웠다. 내가 살아온 그 순간들이 아무런 흔적 없이 사라지는 게 두려웠고, 그래서 그 기억들을 붙잡아 두고 싶어 기록을 시작했다. 책을 읽고 느꼈던 감정과 생각들도 마찬가지다. 책 한 권을 다 읽고 나면 그때의 나는 분명히 어떤 생각들을 하고 있었고, 그 순간의 나를 만든 무언가가 있었을 것이다. 그 감정들이 잊히는 게 아까워서, 그리고 그 순간의 나를 글로 남기고 싶어서 독후감을 쓴다.</p><p></p><p>내가 좋아하는 것을 기록한다는 건 단순히 기억을 남기는 게 아니다. 그것은 나와 내가 좋아하는 것들 사이의 대화를 이어가는 일이다. 내가 좋아하는 인플루언서가 썼던 말이 이를 관통한다.</p><blockquote><p>그래서 나는 글을 쓴다. 기억이라는 전기신호를 활자에 매어두고 두고 두고 복기하는 거야. 이 순간의 나는 어떤 찰나들 위에 얹어진 시간인건지<br>삶이 멈추지 않고 뻗어나가는 그래프라면 나의 그래프를 가만히 잘라 적분하는거야</p></blockquote><p>내 삶의 그래프를 적분한다는 대목이 특히나 좋았다. 나도 내가 살아온 순간들을 그렇게 기록하고 있는 게 아닐까 생각했다. 마치 멈추지 않고 흘러가는 시간 속에서 나를 지나치는 순간들을 붙잡아 두려는 것처럼.</p><p>시간이란 것은 그저 스쳐 지나갈 뿐이다. 내가 특별히 기록하지 않으면 그 순간들은 마치 없었던 것처럼 사라져버린다. 하지만 내가 글을 통해 그 순간을 붙잡아 두면, 그때의 내가 무엇을 느꼈는지, 어떤 생각을 하고 있었는지를 나중에 다시 들여다볼 수 있다. 그 순간의 내가 누구였는지, 어떤 책을 읽었고 어떤 사건을 경험했으며, 어떤 감정으로 그 시간을 살았는지를 빼곡하게 기억하고 싶은 것이다. 그리고 그 기록은 나에게 내가 어떤 사람인지, 내가 무엇을 소중하게 여기는지를 되새기게 해준다.</p><p></p><p>이번에 '글또'에서 글을 쓰게 되면서도 나는 같은 마음을 가지고 있다. 이 활동을 통해 내가 느꼈던 것들, 생각했던 것들을 하나하나 기록하며 그 순간들을 간직하고 싶다. 글을 쓰는 일이 단순한 표현의 수단이 아니라, 나 자신과 내가 살아가는 시간에 대한 기록이라는 사실을 다시금 느끼고 있다. 나는 나의 글을 통해 내가 어떤 사람인지, 그리고 나를 둘러싼 세상이 어떤 모습으로 다가왔는지를 계속해서 탐구해나가고 싶다. 글을 쓰는 동안 나는 그때의 나와 마주하고, 그 순간의 나를 다시 기억 속으로 불러온다.</p><p>이렇게 기록하고 남기는 일은, 나에게 단순한 취미를 넘어 나 자신을 이해하는 중요한 방식이다. 나는 글을 통해 나 자신을 더 잘 알 수 있고, 더 깊이 이해할 수 있다고 믿는다. 그래서 나는 오늘도 글을 쓴다. 그리고 이 순간도, 잊히지 않도록 글 속에 담아두려 한다.</p>

나는 기억을 적는다.

🖥 백엔드

<h1><strong>들어가기 전에</strong></h1><p>Nest.js는 Node.js 진영에서 널리 쓰이고 있는 서버 프레임워크이다.</p><p>그리고 이런 서버를 클라우드 환경에 배포하기 위해서는 AWS EC2, Oracle Cloud 등의 컴퓨팅 인스턴스 위에 올리는 방법이 정석이겠다.</p><p>&nbsp;</p><p>하지만 Nest.js는 서버리스를 지원하고, Vercel은 서버리스를 지원한다.<br>이를 이용해서 무료로 간단히 Vercel에 서버를 배포할 수 있다.</p><p></p><h1>방법</h1><p>방법 자체는 간단하다. 프로젝트 최상단에&nbsp;<code spellcheck="false">vercel.json</code>을 만들고 다음과 같이 작성한다.</p><pre spellcheck="false"><code class="language-json">{
  "version": 2,
  "builds": [
    {
      "src": "src/main.ts",
      "use": "@vercel/node"
    }
  ],
  "routes": [
    {
      "src": "/(.*)",
      "dest": "src/main.ts",
      "methods": [
        "GET",
        "POST",
        "PUT",
        "DELETE"
      ]
    }
  ]
}</code></pre><p><span>그 후 </span><code spellcheck="false">npm install -g vercel</code><span> 을 실행한 후, 프로젝트 최상단 경로에서 </span><code spellcheck="false">vercel .</code><span>를 실행하면 완성된다.</span></p><p></p><h1>트러블 슈팅</h1><h2>Cannot find module</h2><img src="https://image.until.blog/octoping/article/1730787106060.png" data-width="75%" data-align="center" alt="1972"><p><span>배포를 했지만 다음과 같은 오류가 떠서 처음에 큰 고생을 했다.</span></p><p><span>Vercel에서 로그를 확인해보니 아래와 같은 에러 로그가 있었다.</span></p><pre spellcheck="false"><code class="language-log">2023-08-18T17:52:14.322Z	undefined	ERROR	Cannot find module 'src/infra/prisma/PrismaService'
Require stack:
- /var/task/src/feed/feed.module.js
- /var/task/src/app.module.js
- /var/task/src/main.js
2023-08-18T17:52:14.323Z	undefined	ERROR	Did you forget to add it to "dependencies" in `package.json`?
RequestId: 059dec36-4319-4851-9c23-3ecf01978f18 Error: Runtime exited with error: exit status 1
Runtime.ExitError</code></pre><img src="https://image.until.blog/octoping/article/1730787132600.png" data-width="100%" data-align="center" alt="1974"><p>분명 잘 존재하는 모듈을 발견하지 못하고 있다고 에러가 떴다.</p><p>왜;;인지 도저히 알기가 어려워 많이 헤맸는데, 문제는 내 import 문에 있었다.</p><pre spellcheck="false"><code class="language-typescript">import { PrismaService } from '@/infra/prisma/PrismaService';</code></pre><p>다음과 같이 path alias를 사용해서 절대 경로로 import 하는 경우 Vercel이 경로를 인식을 못하는 이슈였다.</p><p></p><p><code spellcheck="false">src/infra/prisma/PrismaService</code>&nbsp;처럼 @를 안 쓰고 절대경로로 쓰더라도 마찬가지였다. 상대경로로 작성해야 한다!</p><p></p><h2>Swagger 페이지 404 에러 (검증 못 해봄)</h2><p><span>다른 페이지는 잘 나오지만 Swagger 페이지만 아무것도 안 나오는 이슈 (404 에러)가 발생한다.</span></p><pre spellcheck="false"><code>Uncaught ReferenceError: SwaggerUIBundle is not defined
    at window.onload</code></pre><p>개발자 도구를 켜보면 이런 로그가 나온다.</p><p>C# 쪽 스웨거에서도 한번 제보된 문제이긴 하다. swagger ui 파일이 서버리스에 올라가기에는 너무 크다는 이슈다.</p><a data-type="bookmark" href="https://stackoverflow.com/questions/63363123/swagger-ui-bundle-js-too-large-for-aws-lambda-and-alb" target="_blank"><div class="content"><div><div class="title">swagger-ui-bundle.js too large for AWS Lambda and ALB</div><div class="description">Updated to .NET Core 3.1 and the latest version of Swashbuckle but found the swagger UI wasn't working correctly.  The swagger-ui-bundle.js was failing to load with a 502.  Tracked this down to a A...</div></div><div class="href">https://stackoverflow.com/questions/63363123/swagger-ui-bundle-js-too-large-for-aws-lambda-and-alb</div></div><img src="https://cdn.sstatic.net/Sites/stackoverflow/Img/apple-touch-icon@2.png?v=73d79a89bded"></a><p>따로 CDN에 swagger js나 css를 올려놓고, 서버리스에 올리는 대신 받아오는 방식으로 사용해볼 수 있겠다는 생각인데.</p><p></p><pre spellcheck="false"><code class="language-typescript">const CSS_URL = "cdnjs.cloudflare.com/ajax/libs/swagger-ui/4.1.0/swagger-ui.min.css";
swaggerUI.setup(specs, { customCssUrl: CSS_URL })</code></pre><p>이런 방식으로 사용해볼 수 있다는 듯 하다.</p><a data-type="bookmark" href="https://github.com/swagger-api/swagger-ui/issues/8461#issuecomment-1497927943" target="_blank"><div class="content"><div><div class="title">When deploying swagger on vercel on nodejs it does not show UI · Issue #8461 · swagger-api/swagger-ui</div><div class="description">This is How it does look like this and I do not know how to fix this issue. Q&amp;A (please complete the following information) OS: M1 Pro Browser" Chrome, Safari Version: 22 Method of installation: np...</div></div><div class="href">https://github.com/swagger-api/swagger-ui/issues/8461#issuecomment-1497927943</div></div><img src="https://opengraph.githubassets.com/3d796af99bd52776acde541aa8b0f43379af9c671dc58fe420ea1314dd1a51a4/swagger-api/swagger-ui/issues/8461"></a><p></p><h1>TMI</h1><p>실제로 until을 처음 개발할 당시에 서버비를 줄이기 위해 다음 방법으로 한동안 개발했었다..</p><p>지금은 AWS + Kotlin Spring으로 넘어갔지만, 그래도 당시에 고려했던 점들을 몇 가지 적어본다.</p><p></p><ol><li><p>NestJS의 경우 서버 실행 초기에 bootstrap하는 과정을 거치는데, 이걸 api가 들어올 때마다 해야한다면 꽤 무거운 작업일 수밖에?</p><p></p></li><li><p>서버리스로 구성할 경우 api가 들어올 때마다 함수가 실행되는 꼴이므로, 트래픽이 몰리는 경우 DB의 커넥션 풀을 굉장히 잡아먹을 가능성이 높다. 이는 서버리스의 고질적 문제이긴 하다.</p><ul><li><p>프로젝트의 persistence 라이브러리로 채택한 Prisma의 경우 이런 문제를 해결해준다고 공식 사이트에 적혀는 있다. 하지만 좀 걱정된다</p><img src="https://image.until.blog/octoping/article/1730788287259.png" data-width="100%" data-align="center" alt="1976"></li></ul></li></ol><p><br></p><p></p>

NestJS를 서버리스로 배포해서 무료로 사용해봅시다

NestJS 서버를 서버리스로 Vercel에 배포하기

AI/LLM

<div data-youtube-video=""><iframe width="640" height="480" allowfullscreen="true" autoplay="false" disablekbcontrols="false" enableiframeapi="false" endtime="0" ivloadpolicy="0" loop="false" modestbranding="false" origin="" playlist="" src="https://www.youtube.com/embed/Ustm9JBoDcM" start="0"></iframe></div><p>오늘의 회고를 쓰기 전, 금방 구운 군고구마같이 어제 발표된 아주 따끈따끈한 AI 소식을 살펴보자.</p><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://deepmind.google/discover/blog/genie-2-a-large-scale-foundation-world-model/">Google DeepMind에서 새롭게 발표한 Genie2</a>를 확인해보겠나?! 😙 이게 뭐야? 정말 어메이징하다.</p><p>이 모델을 통해 <strong>단 1장의 이미지로 3D 환경을 생성할 수 있는 기술</strong>이 탄생했다. 이렇게 생성된 환경은 사람이 직접 게임처럼 플레이하거나, AI 에이전트를 훈련하고 평가하는 데 활용될 수 있다고 한다.</p><p></p><blockquote><p>오늘의 회고를 시작한다. 최근 패스트캠퍼스에서 1+1 블프 할인을 하길래 LLM과 MLOps 강의를 결제했다 💰 열심히 해보자구 -!</p></blockquote><h2>생성형 AI란?</h2><p>AI가 일을 하려면, 일을 시켜야한다! &gt; 명령을 줘야한다 &gt; <strong>텍스트</strong> 형태로! [입력]</p><p>출력은 텍스트, 이미지, 오디오, 의사결정 등으로 가능하다.</p><ul><li><p>텍스트 ex) 번역, 요약, Q&amp;A, 맞춤법 교정, 코드 리뷰</p></li></ul><ul><li><p>의사결정</p><ol><li><p>Prediction ex) 주식 예측</p></li><li><p>Anomaly Detection ex) 튀는 값이 있다면, 정상인지 아닌지 / 게임에서 플레이어가 공격을 해야하는지 공격하지 말아야하는지</p></li></ol></li><li><p>오디오 ex) Text To Speech, Speech To Text : Whisper / AI 상담원, 수업 녹음을 텍스트로 변환</p><p></p></li></ul><blockquote><p>참고 💬</p><ul><li><p>LLM ex) ChatGPT은 생성형 AI의 하위에 속해있음</p></li><li><p>Anomaly Detection은 별도의 모델이 있어서 추후에 생성형 AI를 쓰는게 좋을지, 별도의 모델을 쓰는게 좋을지 비교해볼 예정</p></li></ul></blockquote><h2>LLM vs SLM</h2><p><strong>LLM</strong>(Large Language Model)과 <strong>SLM</strong>(Small Language Model)</p><p></p><ul><li><p>파라미터 크기</p><ul><li><p>SLM(1,500만개 이하: 적음), LLM(수천억 개 이상: 많음)</p></li></ul></li><li><p>하드웨어 요구사항</p><ul><li><p>SLM(Mobile 장치 프로세스 사용 가능), LLM(방대한 데이터로 학습, GPU 필요)</p></li><li><p><strong>LLM API를 서비스화하는 기업에서도 GPU를 씀</strong></p></li></ul></li><li><p>배포</p><ul><li><p>SLM(자원이 제한된 환경에서 배포 가능), LLM(상당한 인프라 요구, 클라우드 사용)</p></li></ul></li><li><p>훈련 시간</p><ul><li><p>SLM(일주일), LLM(수개월)</p></li></ul></li><li><p>소유권</p><ul><li><p>SLM(누구나, 대부분 오픈소스), LLM(제조사)</p></li></ul></li><li><p>라이선스</p><ul><li><p>SLM(오픈소스, 코드 투명O), LLM(필요, 코드 투명X)</p></li></ul></li><li><p>비용</p><ul><li><p>SLM(대부분 무료), LLM(유료)</p></li></ul></li><li><p>유연성</p><ul><li><p><strong>SLM(특정 도메인에 집중)</strong>, LLM(다목적 사용가능)</p></li></ul></li></ul><blockquote><p>참고 💬</p><p>현재 기업추세는 어떨까? LLM에서 SLM으로 옮겨가는 추세 : 우리 기업만의 특화된 모델을 가지고 싶어! <strong>SLM을 가지고 파인튜닝을 할거야! </strong>SLM 관련 모델 많이 나오고 있음</p></blockquote><ul><li><p>장단점</p><ul><li><p>SLM</p><ol><li><p>장점 : 적은 하드웨어 자원 사용, 속도 빠름, 수월한 커스터마이징</p></li><li><p>단점 : 상대적으로 낮은 수준의 문맥 이해, 결과에 대한 낮은 품질</p></li></ol></li><li><p>LLM</p><ol><li><p>장점 : 높은 수준의 문맥 이해, 결과에 대한 높은 품질 보장, 상대적으로 낮은 편향 문제</p></li><li><p>단점 : 많은 하드웨어 자원 필요, 사용에 대한 비용 발생, 속도 느림</p></li></ol></li></ul></li></ul><p></p><p>어떤 기준으로 선택해야할까?</p><ul><li><p>높은 수준의 품질, 사람과 대화하는 것과 같은 수준의 서비스가 필요한가? 예 : LLM, 아니오 : SLM</p></li><li><p>SLM같은 경우, API만 가져다가 쓰는 것이 아니라 추가 데이터로 학습시켜 도메인에 더 특화된 모델을 만드는 것이 일반적</p></li><li><p>LLM같은 경우, <strong>RAG를 이용한 LLM을 도입</strong>해야함</p></li></ul><p></p>