54장. AI 기능 하나 추가해보기

이제는 내가 AI를 쓰는 것을 넘어, 내 서비스도 AI를 쓰게 만들 차례

앞에서 우리는 Claude Code와 Codex를 이용해 서비스를 만들었습니다. 기획을 정리하고, 화면을 만들고, 로그인과 CRUD를 붙이고, 배포까지 해냈습니다. 여기까지 왔다면 이미 꽤 멀리 왔습니다.

이제 한 걸음만 더 가보겠습니다. 이번에는 내가 AI로 개발하는 것이 아니라, 내 서비스 안에 AI 기능을 넣는 것입니다. 이 차이는 생각보다 큽니다. 전자는 개발 과정에서의 도움이고, 후자는 사용자가 실제로 느끼는 기능이 되기 때문입니다.

예를 들어 우리가 만든 글 기반 웹 서비스에 이런 기능을 붙일 수 있습니다.

• 사용자가 검색어를 짧게 입력하면 AI가 더 좋은 검색어로 바꿔주기

• 긴 글을 한두 문장으로 요약해주기

• 읽고 있는 글과 비슷한 글을 추천해주기

이런 기능은 거대한 AI 스타트업만 만드는 것이 아닙니다. 지금은 JavaScript와 Next.js 같은 익숙한 도구로도 충분히 시작할 수 있습니다. 웹 개발자는 모델을 직접 학습시키지 않아도, API를 통해 AI 기능을 앱에 붙일 수 있습니다.¹

이번 장의 목표는 거창한 AI 서비스를 만드는 것이 아닙니다. 작고 분명한 AI 기능 하나를 내 서비스에 안전하게 붙여보는 감각을 익히는 것입니다.

왜 작은 AI 기능부터 시작해야 할까

초보자가 AI 기능을 붙일 때 가장 흔히 하는 실수는 첫 시도부터 너무 큰 것을 만들려는 것입니다. 예를 들면 "내 서비스 전체를 AI 비서처럼 만들고 싶어요" 같은 생각입니다. 물론 멋진 목표입니다. 하지만 처음에는 거의 반드시 길을 잃습니다.

작은 기능이 좋은 이유는 명확합니다. 입력과 출력이 분명하고, 실패했을 때도 고치기 쉽고, 비용과 속도를 관리하기도 쉽기 때문입니다.

예를 들어 "게시글 요약"은 입력이 게시글 본문이고, 출력은 2~3문장 요약입니다. 범위가 좁습니다. 반면 "사용자 질문에 뭐든 답하는 서비스"는 범위가 너무 넓습니다. 어떤 질문이 들어올지 모르고, 틀린 답을 해도 문제를 찾기 어렵습니다.

그래서 이번 장에서는 큰 AI보다 작은 도우미 AI를 추천합니다. 사용자의 핵심 흐름을 방해하지 않으면서, 있으면 분명히 편해지는 기능 말입니다. 서비스에 후추를 한 꼬집 넣는 느낌입니다. 한 숟갈이 아닙니다. 후추통을 통째로 쏟아붓는 순간, 망합니다.

우리 서비스에 어울리는 AI 기능 찾기

AI 기능은 "멋져 보여서" 넣는 것이 아니라, 사용자가 어디에서 멈추는지를 보고 넣어야 합니다.

우리가 만든 글 서비스라면 사용자는 주로 이런 순간에 막힐 수 있습니다.

글을 찾고 싶은데 검색어가 잘 떠오르지 않을 때가 있습니다. 이때 AI는 검색 보조 역할을 할 수 있습니다. 예를 들어 사용자가 "로그인 안됨"이라고만 검색했는데, AI가 이를 "로그인 오류, 세션 만료, 인증 실패" 같은 관련 표현으로 넓혀줄 수 있습니다.

글이 너무 길어서 읽기 부담스러울 때도 있습니다. 이때는 AI 요약이 유용합니다. 특히 모바일에서 긴 글을 볼 때 "이 글이 무슨 내용인지 먼저 알고 싶다"는 욕구가 자주 생깁니다.

또 어떤 글을 읽은 뒤 "비슷한 글 더 없나?"라는 생각이 들 수 있습니다. 이때는 추천 기능이 도움이 됩니다. 추천은 꼭 복잡한 머신러닝이 아니어도 됩니다. 처음에는 제목, 태그, 본문 일부를 바탕으로 AI가 관련 글 후보를 고르게 할 수 있습니다.

중요한 것은, AI가 서비스의 주인공이 아니라는 점입니다. 기존 기능을 더 쉽게 쓰게 만드는 조연으로 시작하는 편이 좋습니다.

가장 먼저 추천하는 기능: 글 요약

세 가지 중에서 처음 붙이기 가장 쉬운 것은 대개 요약 기능입니다.

이유는 단순합니다. 이미 우리 데이터베이스에 글 본문이 있고, 사용자는 결과가 아주 정확한 숫자 형태가 아니어도 어느 정도 받아들일 수 있으며, 화면에도 붙이기 쉽기 때문입니다. 글 상세 페이지에 "AI 요약 보기" 버튼 하나만 있어도 충분합니다.

흐름은 이렇습니다.

사용자가 글 상세 페이지를 엽니다. 버튼을 누르면 프론트엔드가 서버에 "이 글을 요약해줘"라고 요청합니다. 서버는 데이터베이스에서 글 내용을 읽고, AI 모델 API에 요약 요청을 보냅니다. 그리고 받은 결과를 화면에 돌려줍니다.

이 구조가 중요한 이유는 API 키를 브라우저에 직접 두면 안 되기 때문입니다. AI 모델 호출은 보통 서버에서 처리하는 편이 안전합니다. 클라이언트와 서버 중 어디에서 모델을 실행할지는 기능의 성격에 따라 달라지지만, 외부 AI API 키를 쓰는 방식이라면 서버 쪽에서 다루는 것이 기본입니다.²

프론트엔드에서 직접 할까, 서버에서 할까

여기서 한 번 짚고 넘어가야 할 중요한 질문이 있습니다. AI 기능은 프론트엔드에서 직접 실행할까요, 아니면 백엔드에서 실행할까요?

브라우저에서 직접 돌리는 방식은 장점이 있습니다. 응답이 빠르고, 경우에 따라 사용자 데이터가 서버를 거치지 않아 프라이버시에도 유리합니다. 일부 AI 기능은 오프라인에 가까운 경험도 만들 수 있습니다.²

하지만 입문 단계에서 우리가 붙일 기능은 대부분 서버 호출 방식이 더 낫습니다. 이유는 단순합니다. 설정이 쉽고, API 키를 숨길 수 있고, 모델을 바꾸기도 쉽기 때문입니다. 브라우저에서 큰 모델을 직접 돌리는 방식은 기기 성능 차이도 많이 타고, 구현 난이도도 올라갑니다.²³

그래서 이 책의 실습 서비스에서는 이렇게 생각하면 됩니다.

간단한 규칙 기반 기능이나 아주 가벼운 브라우저 모델이 아니라면, 일단 서버에서 AI를 호출하자.

초보자에게 이 원칙은 꽤 든든한 손잡이입니다.

구현 흐름을 사람 말로 먼저 이해하기

코드를 보기 전에, 먼저 사람 말로 흐름을 정리해봅시다.

첫째, 사용자가 버튼을 누릅니다. 둘째, 프론트엔드는 글 ID를 서버로 보냅니다. 셋째, 서버는 권한을 확인하고 데이터베이스에서 글 내용을 읽습니다. 넷째, 서버는 AI에게 "이 글을 초보자도 이해하기 쉽게 3문장으로 요약해줘"라고 요청합니다. 다섯째, AI의 답을 서버가 받아서 프론트엔드로 돌려줍니다. 여섯째, 화면은 그 결과를 사용자에게 보여줍니다.

여기서 중요한 포인트는 두 가지입니다.

하나는 AI에게 원본 전체를 아무 생각 없이 던지지 않는 것입니다. 너무 긴 텍스트는 비용이 늘고 속도도 느려집니다. 필요한 길이만 보내는 습관이 좋습니다.

다른 하나는 AI의 출력도 검증 대상이라는 점입니다. 요약 결과가 비어 있거나 너무 길거나 엉뚱하면 그대로 보여주지 말고, 다시 시도하거나 기본 메시지를 보여줘야 합니다.

즉, AI는 마법 상자가 아니라 외부 서비스입니다. 잘 쓰면 훌륭하지만, 실패할 수도 있습니다. 이 관점이 중요합니다.

요약 기능의 가장 단순한 버전

처음 버전은 최대한 작게 갑니다.

글 상세 페이지에 버튼 하나를 둡니다. 버튼 이름은 "AI로 요약 보기" 정도면 충분합니다. 버튼을 누르면 로딩 상태를 보여줍니다. 서버가 요약을 만들어 주면 카드 형태로 결과를 렌더링합니다.

프롬프트는 길게 쓸 필요가 없습니다. 오히려 짧고 명확한 편이 낫습니다.

예를 들면 이런 식입니다.

"다음 글을 한국어로 2~3문장으로 요약해줘. 과장하지 말고, 원문에 없는 내용은 추가하지 마. 초보자도 이해하기 쉬운 표현을 써줘."

이 한 줄만으로도 꽤 괜찮은 결과가 나옵니다. 중요한 것은 화려한 문장이 아니라 출력 형식을 통제하는 것입니다. 문장 수, 언어, 말투, 금지사항 정도만 정해도 안정감이 크게 올라갑니다.

그리고 서버에서는 응답을 받은 뒤 이런 식으로 한 번 더 정리합니다. 앞뒤 공백을 제거하고, 너무 길면 자르고, 비어 있으면 실패로 처리합니다. AI는 똑똑하지만, 마지막 문단에 갑자기 기분이 좋아져서 쓸데없이 한 마디를 더할 수도 있습니다. 그런 것은 서비스 쪽에서 다듬어야 합니다.

검색 보조 기능은 어떻게 붙일까

요약 다음으로 추천하는 것은 검색 보조입니다.

이 기능은 "검색을 대신해주는 AI"가 아닙니다. 사용자가 입력한 검색어를 더 잘 찾히는 표현으로 바꿔주는 보조 장치입니다. 예를 들어 사용자가 "배포 안됨"이라고 검색했을 때, AI가 "배포 실패, 빌드 오류, 환경변수 문제" 같은 관련 검색 후보를 만들어 줄 수 있습니다.

이 기능의 좋은 점은, 기존 검색 시스템을 바꾸지 않아도 된다는 것입니다. 지금 있는 검색 로직 앞단에 AI를 살짝 끼우기만 하면 됩니다.

흐름은 이렇습니다. 사용자가 검색창에 입력합니다. 서버는 그 문장을 받아 관련 키워드 몇 개를 생성합니다. 그리고 원래 검색어와 AI가 만든 확장 키워드를 함께 사용해 데이터베이스를 검색합니다.

여기서 아주 중요한 규칙이 있습니다. AI가 검색 결과를 직접 결정하게 하지 말고, 검색어 후보만 제안하게 하자는 것입니다. 검색 결과의 최종 판정은 여전히 우리 서비스의 검색 로직이 담당해야 합니다. 이 방식이 더 예측 가능하고 디버깅도 쉽습니다.

즉, AI에게 심판을 맡기지 말고 해설자를 맡기는 편이 낫습니다.

추천 기능은 생각보다 단순하게 시작할 수 있다

추천이라고 하면 많은 사람이 갑자기 겁을 먹습니다. "이건 넷플릭스나 하는 거 아닌가요?"라는 반응이 나옵니다. 하지만 입문 단계의 추천은 그렇게 거대할 필요가 없습니다.

예를 들어 상세 페이지에서 지금 보고 있는 글의 제목과 본문 일부를 AI에게 보내고, 데이터베이스에서 뽑아온 최근 글 10개 목록을 함께 보낼 수 있습니다. 그리고 이렇게 요청하는 겁니다.

"현재 글과 주제가 비슷한 글 3개를 골라줘. 각 후보의 ID 중에서만 선택하고, 관련 이유를 한 줄씩 알려줘."

그러면 AI는 후보 중에서 관련 있는 글을 골라줄 수 있습니다. 이 방식은 완벽한 개인화 추천은 아니지만, 입문 서비스에서 충분히 쓸 만합니다.

다만 여기에도 원칙이 있습니다. AI에게 데이터베이스 전체를 뒤지게 하지 말고, 우리가 먼저 좁힌 후보군 안에서 고르게 하자는 것입니다. 그래야 비용도 줄고 속도도 관리됩니다.

AI 기능은 "한 번에 완성"보다 "한 단계씩 확장"이 중요하다

초보자가 AI 기능을 붙일 때는 보통 이렇게 커집니다.

처음에는 "요약 버튼 하나"였는데, 곧 "자동 제목 생성", "태그 생성", "추천", "댓글 답변", "챗봇", "문서 검색"까지 한꺼번에 넣고 싶어집니다. 그러면 갑자기 서비스가 똑똑해지는 대신, 개발자는 정신이 흐려집니다.

좋은 순서는 이렇습니다.

먼저 버튼을 누를 때만 동작하는 수동 기능을 만듭니다. 그다음 결과 품질을 확인합니다. 이후에 캐시를 붙여서 같은 글은 다시 호출하지 않게 합니다. 그다음에만 자동 실행 여부를 고민합니다.

예를 들어 글 요약 기능의 발전 순서는 이렇게 잡을 수 있습니다.

처음에는 사용자가 버튼을 눌렀을 때만 요약합니다. 다음 단계에서는 한 번 생성한 요약을 데이터베이스에 저장합니다. 그다음에는 글이 수정되면 요약을 다시 생성하게 만듭니다. 마지막으로 목록 화면에서도 짧은 요약을 보여줄지 판단합니다.

이런 순서로 가면, 매 단계마다 서비스는 실제로 더 좋아집니다. 반대로 처음부터 자동화 욕심을 내면 디버깅 난이도만 올라갑니다.

비용과 속도를 무시하면 AI 기능은 금방 짐이 된다

AI 기능은 멋지지만 공짜 슈퍼파워는 아닙니다. 호출할수록 비용이 들고, 응답 시간이 길어질 수도 있습니다. 그래서 입문자일수록 언제 AI를 부를지를 잘 정해야 합니다.

예를 들어 글 상세 페이지를 열자마자 무조건 요약을 생성하는 것보다, 사용자가 버튼을 눌렀을 때만 생성하는 편이 훨씬 안전합니다. 실제로 필요할 때만 쓰기 때문입니다.

또 같은 글을 매번 다시 요약하면 낭비입니다. 한 번 생성한 결과를 저장해두고 재사용하는 방식이 좋습니다. 추천도 마찬가지입니다. 매 클릭마다 새로 계산하지 말고, 일정 시간 동안은 같은 결과를 써도 괜찮습니다.

속도도 중요합니다. 사용자는 검색창에서 10초를 기다리지 않습니다. 검색 보조처럼 자주 호출되는 기능은 특히 더 짧고 가볍게 설계해야 합니다. 필요하다면 "AI 검색 확장 사용" 같은 토글을 두는 것도 방법입니다.

AI 기능은 성능이 좋을수록 사랑받는 것이 아니라, 기다릴 만한 가치가 있을 때 사랑받습니다.

실패했을 때의 화면이 더 중요하다

AI 기능은 성공 화면만 생각하고 만들면 안 됩니다. 오히려 실패했을 때가 더 중요합니다.

모델 호출이 실패할 수도 있습니다. 응답이 늦을 수도 있습니다. 사용량 제한에 걸릴 수도 있습니다. 출력이 엉뚱할 수도 있습니다. 이런 상황은 이상한 일이 아니라 흔한 일입니다.

그래서 화면은 이렇게 설계하는 편이 좋습니다.

로딩 중에는 "요약을 만드는 중입니다"처럼 현재 상태를 보여줍니다. 실패하면 "지금은 요약을 만들 수 없어요. 잠시 후 다시 시도해 주세요"라고 안내합니다. 가능하면 다시 시도 버튼도 둡니다. 그리고 AI 결과가 없어도 서비스 핵심 기능은 여전히 동작해야 합니다.

이 원칙이 중요합니다. AI는 없어도 서비스가 굴러가야 한다는 것입니다. AI가 메인 엔진이 아니라 보조 엔진인 동안은 특히 그렇습니다.

프롬프트는 길이보다 구조가 중요하다

AI 기능을 붙이기 시작하면 프롬프트를 엄청 길게 쓰고 싶어질 수 있습니다. 하지만 처음에는 구조가 더 중요합니다.

좋은 프롬프트는 대개 네 가지를 분명히 합니다. 역할, 입력, 출력 형식, 금지사항입니다.

예를 들어 요약 기능이라면 이런 구조면 충분합니다.

당신은 초보자를 위한 한국어 요약 도우미다. 아래 글을 2문장으로 요약하라. 원문에 없는 내용을 추가하지 말고, 과장 표현을 쓰지 말라. 결과는 순수 텍스트로만 반환하라.

이 정도면 충분히 강합니다. 여기에 "존댓말로 써줘", "한 문장당 40자 안팎으로 줄여줘" 같은 제한을 조금씩 더할 수 있습니다.

그리고 프롬프트 자체도 버전 관리 대상입니다. 처음 결과가 애매하면 코드를 다 뜯어고치기 전에, 프롬프트를 먼저 조금 조정해보는 습관이 좋습니다.

Claude Code와 Codex는 여기서도 여전히 좋은 동료다

재미있는 점은, 서비스 안에 AI 기능을 넣는 순간에도 Claude Code와 Codex의 역할이 끝나지 않는다는 것입니다.

예를 들어 Claude Code에게는 이렇게 시킬 수 있습니다. "Next.js 프로젝트에 게시글 요약 API 라우트를 추가하고, 서버에서만 AI API 키를 사용하게 해줘. 실패 상태와 로딩 UI까지 포함해줘." 그러면 기능 뼈대를 빠르게 만들 수 있습니다.

Codex에게는 이렇게 요청할 수 있습니다. "이 요약 기능에서 보안상 위험한 부분이 있는지 리뷰해줘. API 키 노출 가능성, 과도한 호출, 에러 처리 누락을 중심으로 봐줘." 그러면 구현 뒤 점검에도 도움을 받을 수 있습니다.

즉, AI 기능을 서비스에 넣는다고 해서 개발용 AI 도구를 졸업하는 것이 아닙니다. 오히려 개발하는 AI와 서비스가 제공하는 AI를 함께 다루게 되는 것입니다.

이 지점이 바로 이번 장의 핵심입니다.

조금 더 욕심내고 싶다면: 에이전트보다 도구형 AI부터

생성형 AI를 다루는 도구들은 점점 더 복잡한 흐름을 만들 수 있게 해줍니다. JavaScript 생태계에서는 LangChain.js 같은 도구를 사용해 모델, 도구 호출, 검색, 에이전트 흐름을 구성할 수도 있습니다.⁴

하지만 처음부터 에이전트를 만들 필요는 없습니다. 초보자에게는 단일 입력 → 단일 출력 구조가 가장 좋습니다.

예를 들면 이런 순서가 좋습니다.

요약 기능을 붙입니다. 그다음 검색 보조를 붙입니다. 그다음 추천을 붙입니다. 이후에 정말 필요할 때만 "여러 단계를 스스로 판단해서 움직이는 AI"를 고민합니다.

에이전트는 멋지지만, 대부분의 입문 서비스는 그 전에 할 일이 많습니다. 기본 CRUD가 흔들리는데 AI가 자율주행을 시작하면, 개발자는 조수석에서 비명을 지르게 됩니다.

실전 체크리스트: 이번 주에 정말 붙여볼 수 있는 형태

이번 장을 읽고 바로 실습한다면, 가장 추천하는 버전은 다음과 같습니다.

상세 페이지에 "AI 요약 보기" 버튼을 추가합니다. 서버 API 라우트 하나를 만듭니다. 글 본문을 읽어 2~3문장 요약을 생성합니다. 결과를 화면에 보여줍니다. 로딩 상태와 실패 메시지를 넣습니다. 같은 글에 대해 이미 생성된 요약이 있으면 재사용합니다.

여기까지면 충분합니다. 정말 충분합니다.

이 한 기능만으로도 독자는 중요한 경험을 하게 됩니다. 외부 AI API를 서버에서 안전하게 호출하는 법, 프론트엔드와 서버를 연결하는 법, 실패를 대비하는 법, 비용과 응답 시간을 생각하는 법, 그리고 AI 결과를 맹신하지 않는 법까지 모두 배웁니다.

작아 보이지만, 실제로는 아주 많은 것을 배우는 기능입니다.

AI 기능을 붙였을 때 생기는 가장 큰 변화

이 장의 시작에서 말했듯, 이번 챕터의 핵심은 "내가 AI를 써서 개발한다"에서 "내 서비스가 AI를 사용한다"로 넘어가는 순간입니다.

이 변화는 생각보다 큽니다. 이제 당신은 단순히 AI 도구의 사용자만이 아닙니다. AI를 제품 기능으로 설계하는 사람이 됩니다.

이때부터는 질문이 달라집니다.

"어떤 프롬프트가 잘 먹히지?"만 묻지 않게 됩니다. 대신 "사용자는 언제 이 기능을 원하지?", "실패하면 어떤 경험이 되지?", "이 기능은 비용 대비 가치가 있나?", "AI가 틀렸을 때 서비스는 어떻게 안전해지지?" 같은 질문을 하게 됩니다.

바로 그 질문들이 제품을 더 서비스답게 만듭니다.

작은 AI 기능 하나를 붙여보는 일은, 단순히 새로운 기술을 써보는 체험이 아닙니다. 이제 당신은 기능을 만들 뿐 아니라, 지능을 설계하는 사람이 되기 시작한 것입니다.

마무리: 작게 붙이고, 분명하게 검증하자

처음 AI 기능을 붙일 때 기억할 것은 딱 세 가지입니다.

작게 시작하세요. 요약, 검색 보조, 추천처럼 범위가 분명한 것부터 붙이세요.

서버에서 안전하게 다루세요. API 키와 호출 비용, 실패 상황을 반드시 관리하세요.

결과를 믿기 전에 검증하세요. AI의 문장은 자연스러워 보여도, 항상 맞는 것은 아닙니다.

이 원칙만 지켜도, 당신의 서비스는 한 단계 더 살아 있는 느낌을 갖게 됩니다. 그리고 독자는 아마 이런 감각을 얻게 될 것입니다.

"아, 이제 나는 AI로 개발하는 사람을 넘어서, AI가 들어간 서비스를 만드는 사람으로 가고 있구나."

그 감각이면 충분합니다. 아니, 사실은 꽤 대단합니다.

참고

¹JavaScript 개발자를 위한 생성형 AI

²Integrating JavaScript with AI models: what your web app can do today that used to require backend logic

³A Practical Guide to Using AI in Your JavaScript App

⁴LangChain.js for Beginners: A Free Course to Build Agentic AI Apps with JavaScript