[UNIKER] 3회차 라이브 강의 정리 ㅡ AI 서비스와 API 연결, Codex exec로 MVP의 AI 기능을 검증하는 법

이번 UNIKER 1기 세 번째 라이브 강의에서는 ‘AI 서비스와 API 연결’을 주제로, 사용자의 입력이 실제 AI 결과로 이어지는 서비스 구조를 배웠다.

지난 강의까지는 사용자 흐름과 핵심 화면을 정의하고, Codex를 활용해 작동하는 프로토타입을 만드는 데 집중했다. 이번 강의에서는 한 단계 더 나아가 AI 기능을 실제 서비스 안에서 어떻게 연결하고 검증할 것인가를 다뤘다.

강의에서 1회차의 PRD·사용자 문제·핵심 기능, 2회차의 화면·API 계약·Mock 데이터·검증에 이어, 이번 3회차를 AI 기능 정의, AI API 연결, 로컬 Codex exec 데모로 연결하고 있었다.

강의에 앞서 살펴본 최근 Codex 업데이트

이번 강의는 본격적인 API 설명에 앞서, 최근 ChatGPT와 Codex에 추가된 업데이트를 살펴보는 것으로 시작했다.

AI 도구는 한 달 단위도 아니라 한 주 사이에도 기능과 사용 방식이 달라질 만큼 빠르게 발전하고 있다. 강사님께서는 이러한 변화를 강의자료에도 계속 반영하고 있었고, 별도로 제작한 Codex 활용 가이드에도 최신 내용을 추가했다고 설명해 주셨다.

특히 인상 깊었던 업데이트는 Codex가 별도의 개발 도구로만 존재하는 것이 아니라, ChatGPT 데스크톱 앱 안에서 더 자연스럽게 연결되는 방향으로 발전하고 있다는 점이었다.

강의자료에서는 다음과 같은 변화가 소개됐다.

• ChatGPT 데스크톱 앱 안에서 Codex 사용
• Markdown과 코드 바로 편집
• 선택한 부분에 주석을 남겨 수정 요청
• GitHub Pull Request 차이와 리뷰 피드백 확인
• 여러 저장소를 하나의 프로젝트에서 관리
• 작업 상태와 진행 과정 표시 개선

이전에는 AI에게 코드를 생성해 달라고 요청하고 결과를 복사하는 느낌이 강했다면, 이제는 프로젝트와 파일, GitHub 협업 흐름 전체가 하나의 작업 환경 안으로 들어오고 있었다.

내가 CampusLog를 개발하며 사용했던 방식도 이러한 변화와 연결된다. 단순히 코드를 만들어 달라고 요청한 것이 아니라 Codex가 프로젝트 문서를 읽고 브랜치를 만든 뒤 코드를 수정하고, 테스트와 커밋, Push, Pull Request까지 이어서 처리하도록 사용하고 있기 때문이다.

AI 에이전트는 점점 ‘코드를 알려주는 도구’보다 개발 업무의 일부를 실제로 수행하는 작업자에 가까워지고 있다는 생각이 들었다.

작업에 맞는 모델을 선택하는 세 가지 기준

이번 강의에서 기억에 남은 내용 중 하나는 모델 선택 기준이었다.

Sol, Terra, Luna. 강의에서는 모델을 무조건 가장 강력한 것으로 선택하는 것이 아니라 작업 난이도와 비용, 기다릴 수 있는 시간에 따라 구분해야 한다고 설명했다.

Sol — 가장 어려운 문제

Sol은 복잡한 코딩, 컴퓨터 사용, 연구, 보안처럼 속도보다 정확도가 중요한 작업에 적합하다.

예를 들면 다음과 같다.

• 원인을 알기 어려운 복잡한 버그
• 여러 파일에 영향을 주는 리팩터링
• UI를 포함한 최종 검증
• 보안이나 데이터 마이그레이션
• 처음 보는 대규모 코드베이스 분석

CampusLog에 적용한다면 AI 추천 결과가 실제 경험과 무관한 내용을 생성하는 문제처럼, 여러 파일과 로직을 함께 추적해야 하는 작업에 적합하다.

Terra — 일상적인 개발의 기본값

Terra는 품질과 속도의 균형을 맞춘 모델이다.

일반적인 기능 개발, 테스트 작성, 일상적인 버그 수정처럼 대부분의 개발 작업에 사용할 수 있다.

CampusLog에서는 다음과 같은 작업이 여기에 해당한다.

• 경험 CRUD 기능 수정
• 입력 검증 추가
• 컴포넌트 분리
• API Route 수정
• 테스트 코드 작성
• 작은 UI 동작 개선

특별히 난도가 높거나 단순하지 않다면 Terra를 기본값으로 두는 방식이 효율적이다.

Luna — 빠르고 가벼운 작업

Luna는 빠른 반복과 정리, 탐색처럼 깊은 추론이 필요하지 않은 작업에 적합하다.

예를 들면 다음과 같다.

• 문서 정리
• 작은 문구 수정
• 코드 위치 탐색
• 파일 구조 확인
• 간단한 설명 작성
• 초기 아이디어 조사

작업이 명확하고 범위가 작다면 무거운 모델을 사용할 필요가 없다.

결국 중요한 것은 최고 성능의 모델 하나만 고집하는 것이 아니라 다음 세 가지를 함께 보는 것이다.

작업의 난이도 + 실패했을 때의 비용 + 기다릴 수 있는 시간

 

이 기준은 개발팀 운영에서도 중요하다. 간단한 문구 수정까지 가장 무거운 모델로 처리하면 속도와 사용량을 낭비하고, 반대로 전체 구조를 건드리는 작업에 가벼운 모델을 사용하면 잘못된 수정이 더 큰 비용으로 돌아올 수 있다.

모델보다 먼저 결정해야 하는 생각의 깊이

강의에서는 모델 선택과 함께 Reasoning Effort, 즉 AI가 문제를 얼마나 깊이 생각하도록 할 것인지도 설명했다.

생각의 깊이는 대략 다음과 같이 구분할 수 있었다.

Low

작은 문구 수정이나 범위가 명확한 질문, 간단한 문서 정리에 적합하다.

Medium

일상적인 개발의 기본값이다. 속도와 결과 품질 사이에서 균형이 좋다.

High 또는 Max

원인이 모호한 버그, 처음 보는 저장소, 여러 파일에 걸친 수정처럼 깊은 분석이 필요한 작업에 적합하다.

Ultra

여러 하위 에이전트가 병렬로 처리할 수 있는 매우 복잡한 과제에 사용한다. 다만 사용량이 빠르게 줄어들 수 있으므로 꼭 필요한 경우에만 선택해야 한다.

여기서 기억해야 할 원칙은 간단했다.

처음부터 가장 높은 단계로 시작하지 말고, 기본값으로 실행한 뒤 결과가 부족할 때 한 단계씩 높인다.

 

나 역시 Codex를 사용하면서 어려운 작업일수록 무조건 가장 높은 설정을 선택해야 한다고 생각한 적이 있었다. 하지만 이번 강의를 통해 작업의 크기와 위험도에 맞춰 모델과 추론 강도를 조절하는 것도 개발자의 중요한 판단이라는 것을 배웠다.

AI를 사용했다고 모두 AI 서비스는 아니다

이번 강의의 핵심은 AI 기능과 AI 서비스를 구분하는 것이었다.

강의자료에서는 AI 서비스를 다음과 같이 설명했다.

사용자의 입력을 받아 AI가 판단하거나 생성하고, 그 결과가 서비스 화면 안에서 실제 기능처럼 작동하는 서비스

 

즉, 프롬프트를 입력하고 AI의 답변을 받아오는 것만으로는 충분하지 않다.

AI 서비스에는 다음 흐름이 있어야 한다.

사용자 입력
→ AI 처리
→ 구조화된 결과
→ 서비스 화면
→ 사용자의 다음 행동

 

예를 들어 CampusLog의 AI 추천 기능은 단순히 “이 경험을 추천합니다”라는 문장을 생성하는 것이 아니다.

• 사용자가 활용 목적과 문항을 입력한다.
• 저장된 경험을 AI가 비교한다.
• 적합한 경험을 순위별로 추천한다.
• 추천 이유와 부족한 근거를 설명한다.
• 과장 위험을 표시한다.
• 사용자가 자소서나 면접 답변 작성으로 이어갈 수 있게 한다.

AI를 사용했다는 사실보다 중요한 것은 AI를 통해 사용자가 얻는 결과가 실제로 달라지는가이다.

강의자료의 표현처럼 AI 서비스는 “AI를 썼다”가 아니라 사용자가 얻는 결과 화면이 달라지는 서비스라고 이해할 수 있었다.

AI 기능을 만드는 세 가지 방법

강의에서는 AI 기능을 구현하는 방법을 크게 세 가지로 구분했다.

AI API 사용

OpenAI, Anthropic, Gemini처럼 이미 만들어진 AI 모델을 API로 호출하는 방식이다.

사용자가 서비스를 이용할 때마다 서버가 AI API에 요청을 보내고 결과를 받아온다. 외부 사용자가 계속 사용하는 공개 서비스라면 일반적으로 이 구조가 적합하다.

Codex exec 사용

터미널이나 CI 환경에서 Codex 에이전트를 비대화형으로 한 번 실행하는 방식이다.

AI 기능의 입력과 출력이 제대로 작동하는지 빠르게 검증하거나, 반복 작업과 자동화에 활용할 수 있다.

직접 모델 제작

직접 데이터를 수집하고 모델을 학습한 뒤 서버에 배포하는 방식이다.

가장 높은 자유도를 가질 수 있지만 데이터, 인프라, 학습 비용과 운영 역량이 필요하기 때문에 이번 프로젝트의 범위에서는 제외됐다.

 

이번 UNIKER 프로젝트에서는 서비스의 최종 운영은 AI API, 빠른 기능 구현과 검증은 Codex exec를 활용하는 방향으로 정리할 수 있었다.

API는 요청과 응답의 약속이다

API라는 단어는 처음 들으면 복잡하게 느껴질 수 있지만, 강의에서는 이를 주문 과정에 비유했다.

• 사용자 화면은 주문서를 작성하는 손님
• 우리 서버는 주문서를 정리하는 직원
• AI API는 결과를 만드는 전문가

사용자는 화면에서 필요한 내용을 입력한다. 서버는 이 입력을 AI가 이해할 수 있는 요청으로 정리하고 API 키를 이용해 AI 서비스에 전달한다. AI는 정해진 형식으로 결과를 반환하고, 서버는 이를 화면에 보여준다.

사용자 화면
→ 우리 서버
→ AI API
→ 우리 서버
→ 결과 화면

 

여기서 핵심은 단순히 무엇을 보낼지 정하는 것이 아니라, 어떤 형태로 결과를 받을지까지 미리 약속하는 것이다.

예를 들어 AI가 매번 자유로운 문장으로 답하면 화면에서 결과를 안정적으로 보여주기 어렵다. 반면 다음과 같은 JSON 구조를 정해두면 카드나 배지, 경고 문구로 쉽게 연결할 수 있다.

 

{
  "recommendations": [
    {
      "title": "추천 경험 제목",
      "reason": "이 경험을 추천하는 이유",
      "missingEvidence": ["추가로 필요한 근거"],
      "overclaimRisk": "과장 가능성"
    }
  ]
}

 

결국 API 설계는 AI에게 질문을 잘하는 것만이 아니라, 화면이 사용할 수 있는 결과 구조를 정하는 일이다.

API 키는 반드시 서버가 보관해야 한다

강의에서 실무적으로 중요했던 내용은 API 키 보안이었다.

API 키는 AI 서비스를 호출할 수 있는 비밀 출입카드와 같다. 따라서 사용자의 브라우저나 공개된 GitHub 저장소에 노출돼서는 안 된다.

API 키는 다음과 같은 위치에 보관해야 한다.

• 로컬 개발 환경의 .env.local
• Vercel의 Environment Variables
• 서버 내부 환경변수

반대로 다음과 같은 방식은 피해야 한다.

• NEXT_PUBLIC_이 붙은 환경변수
• 프론트엔드 코드에 API 키 작성
• GitHub 저장소에 키 커밋
• 브라우저에서 AI API 직접 호출

사용자는 비밀 출입카드를 볼 필요가 없다. 사용자는 우리 서버에 요청하고, API 키를 가진 서버가 AI를 호출해야 한다.

브라우저 → 우리 서버 → AI API

 

이 구조는 단순한 구현 방식의 차이가 아니라 서비스 보안의 기본 원칙이다.

JSON 응답만큼 중요한 화면 상태

AI API를 연결하면 성공 결과만 생각하기 쉽다. 하지만 실제 서비스에서는 AI 응답이 느리거나, 잘못된 형식으로 오거나, 호출 자체가 실패할 수 있다.

강의에서는 결과 화면을 다음 세 가지 상태로 나누어 설명했다.

성공

정상적인 JSON 결과를 받아 카드나 문장으로 보여준다.

로딩

AI 응답에는 시간이 걸릴 수 있으므로 버튼을 비활성화하고, 현재 처리 중임을 사용자에게 알려야 한다.

실패

API 오류, JSON 파싱 실패, 사용량 초과 등이 발생했을 때 샘플 결과나 재시도 버튼을 제공해야 한다.

이번 강의에서 가장 기억에 남은 메시지는 다음이었다.

AI가 실패해도 서비스 화면은 멈추면 안 된다.

 

CampusLog에도 그대로 적용할 수 있는 원칙이다.

AI 추천이 실패했을 때 단순히 흰 화면이나 에러 코드만 보여주는 것이 아니라,

• 기존 입력을 유지하고
• 재시도 버튼을 제공하며
• 마지막 정상 결과를 보존하고
• 필요하면 Mock 결과를 보여주는 것

까지 설계해야 한다.

AI의 성능뿐 아니라 실패했을 때 사용자가 무엇을 할 수 있는지가 서비스 품질을 결정한다.

AI API 서비스별 특징

강의에서는 대표적인 AI API와 플랫폼도 함께 살펴봤다.

OpenAI

텍스트, 이미지, 음성, 코드 생성과 구조화된 출력까지 하나의 API 안에서 폭넓게 다룰 수 있다.

사용자 답변 분석, 추천 카드 생성, JSON 결과 생성처럼 CampusLog에 필요한 기능과 잘 맞는다.

Anthropic Claude

긴 문서 분석, 글쓰기, 추론, 코딩에 강점이 있다.

자기소개서 피드백이나 리서치 요약, 정책 문서 분석 등에 활용할 수 있다.

Gemini

Google 생태계와 연결하기 좋고 텍스트와 이미지 등 멀티모달 입력을 처리할 수 있다.

이미지 설명, 자료 요약, 검색형 응답 등에 활용할 수 있다.

Replicate

다양한 공개 모델을 API로 빠르게 실행할 수 있다.

이미지 생성, 배경 제거, 영상 변환처럼 특정 모델을 실험할 때 유용하다.

Hugging Face

모델과 데이터셋을 탐색하고 공개 데모를 확인할 수 있는 AI 커뮤니티 플랫폼이다.

원하는 기능을 직접 만들기 전에 유사 모델과 데모가 존재하는지 조사하기 좋다.

ElevenLabs

음성 합성, 음성 인식, 보이스 디자인에 특화돼 있다.

면접 연습 음성이나 캐릭터 목소리, 음성 안내 서비스 등에 활용할 수 있다.

중요한 것은 어떤 서비스가 가장 유명한지를 비교하는 것이 아니라, 우리가 원하는 출력 유형과 비용, 구현 난이도에 따라 선택하는 것이다.

MVP 단계에서는 비용보다 먼저 흐름을 검증해야 한다

AI API는 대부분 호출량이나 토큰 사용량에 따라 비용이 발생한다.

문제는 개발 중에도 문구를 조금 수정하거나 화면을 반복해서 확인할 때마다 호출 비용이 쌓일 수 있다는 점이다.

따라서 강의에서는 MVP 단계에서 다음 순서를 권장했다.

Mock 데이터로 화면 검증
→ Codex exec로 실제 AI 결과 확인
→ 필요한 순간에만 API 호출
→ 운영 단계에서 서버 API로 전환

 

AI 기능을 처음부터 완전한 운영 구조로 만들기보다, 먼저 사용자의 입력이 결과 화면으로 이어지는 흐름이 유용한지를 확인해야 한다.

아무리 뛰어난 AI를 연결해도 사용자가 입력해야 할 내용이 불명확하거나 결과 화면이 이해하기 어렵다면 좋은 서비스가 될 수 없다.

CampusLog 역시 AI 모델의 성능만 높이는 것보다,

• 어떤 경험 데이터를 입력으로 사용할지
• 추천 결과에 무엇을 보여줄지
• 사용자가 다음에 무엇을 할 수 있을지
• 잘못된 추천을 어떻게 발견할지

를 먼저 검증하는 것이 중요하다.

Codex exec는 ‘주문서 맡기기’에 가깝다

이번 강의에서 가장 새롭게 배운 개념은 Codex exec였다.

일반적인 Codex 사용은 대화창에서 여러 차례 이야기를 주고받으며 작업을 수정하는 방식이다. 반면 Codex exec는 채팅창을 열지 않고, 터미널에서 하나의 요청을 전달한 뒤 최종 결과를 받는다.

프롬프트 준비
→ codex exec 실행
→ 결과 출력
→ JSON 또는 파일로 저장

 

강의에서는 이를 ‘주문서 맡기기’에 비유했다.

화면에서 조건을 선택하면 서비스가 프롬프트 주문서를 만든다. 사용자는 이 주문서를 터미널의 Codex exec에 전달한다. Codex는 한 번 작업한 뒤 JSON 결과를 반환하고, 그 결과를 다시 서비스 화면의 카드에 적용한다.

Codex exec가 유용한 경우는 다음과 같다.

• 반복 가능한 한 번짜리 작업
• 문서나 데이터 정리
• CI 내부 자동화
• AI 기능의 입출력 검증
• 해커톤 시연용 MVP
• 결과를 파일이나 JSON으로 연결하는 작업

그러나 외부 사용자가 계속 이용하는 서비스의 백엔드로 바로 사용하는 것은 운영 복잡도가 커질 수 있다.

API와 Codex exec의 차이

강의 내용을 정리하면 둘의 차이는 다음과 같다.

AI API

서비스 서버가 AI 회사의 API를 호출한다.

• 외부 사용자의 반복 요청 처리
• API 키와 비용 관리
• 오류와 사용량 제한 처리
• 공개 서비스 운영에 적합

Codex exec

터미널이나 스크립트에서 Codex를 비대화형으로 실행한다.

• 로컬 MVP
• 내부 기능 검증
• 반복 작업 자동화
• 시연과 프로토타입에 적합

Codex exec를 클라우드에서 실행하는 것도 가능하지만, 그렇게 하려면 인증, Git 작업공간, sandbox, timeout, 대기열, 동시 실행, 로그 관리가 필요해진다.

따라서 강의에서 제시한 기준은 명확했다.

MVP와 시연은 exec, 실제 운영은 API

 

이번 프로젝트 역시 최종 해커톤 현장에서 기능을 시연하는 것이 목표이기 때문에, 처음부터 복잡한 공개 운영 환경을 만들기보다 Codex exec로 핵심 AI 기능이 실제로 작동한다는 것을 증명하는 방향이 적합하다.

Prompt에서 JSON까지 이어지는 흐름

Codex exec를 활용한 로컬 MVP 흐름은 다음과 같았다.

1. 화면 입력

사용자가 지역, 목적, 조건과 같은 값을 선택한다.

CampusLog라면 활용 목적, 지원 문항, 직무 정보가 될 수 있다.

2. 주문서 만들기

화면에서 선택한 값을 바탕으로 Codex에 전달할 프롬프트를 만든다.

3. 한 번 실행

사용자가 프롬프트를 복사해 터미널에서 Codex exec를 실행한다.

4. 결과 붙이기

Codex가 반환한 JSON을 화면에 적용해 카드나 분석 결과로 보여준다.

이 방식은 완전한 자동화는 아니지만, AI 기능의 핵심 계약을 빠르게 검증할 수 있다.

사용자의 입력이 달라지면 결과도 달라지는지, JSON이 화면에 맞는 구조로 생성되는지, 파싱 실패 시 어떻게 대응할지를 확인할 수 있기 때문이다.

JSON은 화면에 붙일 때만 필요하다

AI에게 항상 JSON으로 답하도록 요구할 필요는 없다.

단순히 사람이 읽고 복사하는 결과라면 일반 문장으로도 충분하다. 하지만 결과를 코드가 읽어 카드나 표로 자동 표시해야 한다면 JSON 구조가 필요하다.

강의에서는 다음 요소를 구분했다.

• 일반 출력: 사람이 읽는 문장
• --json: 실행 과정 이벤트를 JSON 형태로 출력
• --output-schema: 최종 결과의 구조를 고정
• 결과 파일: 최종 JSON을 파일로 저장

중요한 것은 JSON 자체를 사용하는 것이 목적이 아니라, 화면이 필요로 하는 데이터 구조를 안정적으로 보장하는 것이다.

 

CampusLog의 추천 결과라면 다음과 같은 계약을 먼저 정해야 한다.

• 추천 경험은 정확히 몇 개인가
• 추천 이유가 반드시 포함되는가
• 근거 부족 항목은 배열인가
• 과장 위험은 어떤 형식인가
• 존재하지 않는 경험을 추천하지 않는가

출력 계약이 명확할수록 AI 결과를 서비스 화면에 연결하기 쉬워진다.

권한과 보안을 함께 생각해야 한다

Codex exec는 실제 파일과 터미널 환경에 접근할 수 있기 때문에 권한 설정이 중요하다.

강의에서는 기본적으로 읽기 전용 환경에서 시작하고, 파일 수정이 필요한 경우에만 권한을 넓히는 방식을 권장했다.

• 기본은 read-only
• 파일을 수정해야 할 때만 workspace-write
• 전체 접근 권한은 격리된 환경에서만 사용
• API 키와 개인정보를 프롬프트에 포함하지 않기
• 브라우저가 임의로 로컬 명령을 실행하지 못하게 하기

AI에게 일을 맡긴다고 해서 모든 권한을 한 번에 열어주는 것은 안전하지 않다.

사람에게 업무를 위임할 때도 필요한 문서와 권한만 전달하듯, AI 에이전트에도 최소 권한 원칙을 적용해야 한다.

CampusLog에 적용해 본다면

이번 강의 내용은 우리 팀의 CampusLog 개발에도 바로 적용할 수 있다.

현재 CampusLog에는 사용자가 자신의 경험을 기록하고, AI가 경험을 분석하거나 지원 목적에 맞는 경험을 추천하는 기능이 있다.

이를 이번 강의의 흐름으로 정리하면 다음과 같다.

사용자 입력

• 지원 목적
• 자기소개서 또는 면접 문항
• 지원 직무
• 저장된 경험 목록

AI 작업

• 질문의 핵심 역량 분석
• 경험별 관련도 비교
• 추천 경험 순위 생성
• 근거 부족 여부 확인
• 과장 가능성 탐지

출력

• 추천 경험 Top 3
• 추천 이유
• 활용 가능한 근거
• 보완해야 할 정보
• 과장 위험
• 다음 행동

실패 상태

• JSON 파싱 실패
• 추천 결과가 없는 경우
• 존재하지 않는 경험을 추천한 경우
• AI 응답이 지나치게 일반적인 경우
• 실행 또는 사용량 제한 실패

이번 강의를 통해 현재 CampusLog의 AI 기능도 단순히 결과를 생성하는 데서 끝나서는 안 된다는 점을 다시 확인했다.

AI가 왜 그 경험을 추천했는지, 어떤 정보가 부족한지, 사용자가 다음에 무엇을 해야 하는지까지 보여줘야 실제 취업 준비를 돕는 서비스가 될 수 있다.

OpenAI Build Week 해커톤에 도전해 보고 싶다는 생각

강의 중 OpenAI Build Week와 같은 해커톤 이야기도 나왔다.

상금이 현금으로 제공되는 대회이기도 하지만, 더 중요한 것은 우리 삶에 실제로 도움이 되는 앱을 만들어 제출하는 자리라는 점이었다.

이 이야기를 들으면서 현재 개발하고 있는 CampusLog도 충분히 확장 가능성이 있다고 느꼈다.

대학생은 프로젝트, 대외활동, 봉사, 공모전 등 다양한 경험을 쌓지만 시간이 지나면 구체적으로 무엇을 했고 어떤 성과를 냈는지 잊어버리기 쉽다. 취업 준비를 시작한 뒤에야 과거 경험을 다시 복원하려고 하면 근거가 부족하거나 내용이 과장되기 쉽다.

CampusLog는 이러한 문제를 해결하기 위해,

• 활동 중 기록을 축적하고
• 활동 종료 후 하나의 경험으로 정리하며
• AI가 STAR 구조와 역량을 분석하고
• 지원 문항에 맞는 경험을 추천하는 서비스

를 목표로 하고 있다.

단순한 AI 챗봇이 아니라 사용자가 자신의 경험을 장기적으로 관리하고, 필요한 순간에 근거 있는 답변으로 활용하도록 돕는다는 점에서 ‘우리 삶에 도움이 되는 앱’이라는 해커톤 주제와도 잘 맞을 수 있다고 생각했다.

이번 UNIKER 프로젝트에서 MVP를 완성한 뒤 실제 사용자 테스트와 문제 검증을 보완해, 비슷한 AI 해커톤에도 도전해 보고 싶다.

이번 강의를 통해 얻은 핵심 인사이트

이번 강의에서 얻은 가장 큰 인사이트는 세 가지였다.

첫째, 가장 강력한 모델이 항상 가장 좋은 선택은 아니다

작업의 난이도와 위험도, 기다릴 수 있는 시간에 따라 Sol, Terra, Luna와 추론 강도를 조절해야 한다.

AI를 잘 활용한다는 것은 가장 비싼 모델을 선택하는 것이 아니라, 작업에 맞는 도구와 설정을 고르는 것이다.

둘째, AI 기능은 입력과 출력의 계약으로 설계해야 한다

AI에게 자유롭게 답하게 한 뒤 화면에 억지로 끼워 맞추는 것이 아니라, 어떤 값을 입력하고 어떤 구조로 결과를 받을지 먼저 정의해야 한다.

좋은 프롬프트는 화면과 서비스 흐름에서 시작된다.

셋째, AI가 실패해도 서비스는 계속 작동해야 한다

AI 응답은 느려질 수 있고, JSON이 깨질 수도 있으며, 사용량 제한에 걸릴 수도 있다.

따라서 로딩, 실패, 빈 결과, 재시도, Mock 결과와 같은 대체 상태가 반드시 필요하다.

AI 서비스의 완성도는 정상적인 결과뿐 아니라 실패했을 때의 사용자 경험에서도 드러난다.