Source: Dev.to

5일 만에 초보자가 AI 애플리케이션 10개를 만들었습니다 – 실제로 일어난 일

주의: 이 글은 제가 5일 동안 만든 10개의 AI 프로젝트에 대한 회고이며, 성공과 실패 모두를 솔직하게 다룹니다.

📅 개요

• 기간: 2023년 7월 1일 ~ 7월 5일 (5일)
• 목표: 하루에 하나씩, 총 10개의 AI 기반 애플리케이션을 만들고 배포하기
• 기술 스택:
  • 프론트엔드: React, Next.js, Tailwind CSS
  • 백엔드: Node.js, Express, FastAPI
  • AI 서비스: OpenAI GPT‑3.5, DALL·E, Stable Diffusion, Whisper, Replicate, Hugging Face 모델
  • 배포: Vercel, Railway, Render, Docker

🛠️ 만든 애플리케이션 리스트

📖 하루별 진행 상황

Day 1 – AI 챗봇

• 목표: 기본적인 질문‑답변이 가능한 웹 기반 챗봇 만들기
• 성과: OpenAI API 키만으로 30분 안에 프론트엔드와 백엔드 연결 완료
• 문제점: 토큰 비용이 예상보다 빨리 소진됨 → 해결책: max_tokens와 temperature 파라미터 조정

Day 2 – 이미지 생성기

• 목표: 텍스트 프롬프트를 입력하면 DALL·E 2가 이미지를 반환
• 성과: Next.js API 라우트에 DALL·E 호출 로직 구현, Vercel에 배포 (2시간)
• 문제점: 이미지 로딩 속도가 느림 → 해결책: Cloudflare 이미지 캐시 사용

Day 3 – 음성 텍스트 변환

• 목표: 마이크 입력을 받아 Whisper API로 실시간 전사
• 성과: Web Audio API와 Whisper를 연결, 1분당 5달러 이하 비용 유지
• 문제점: 브라우저 호환성 이슈 (Safari) → 해결책: MediaRecorder fallback 구현

Day 4 – 코드 자동 완성

• 목표: 사용자가 코드를 입력하면 Codex가 자동 완성 제안
• 성과: Monaco Editor와 Codex API 연동, VS Code와 비슷한 UX 제공
• 문제점: 긴 코드 블록에서 응답 지연 → 해결책: 요청당 코드 길이 제한 및 프롬프트 최적화

Day 5 – 텍스트 요약기

• 목표: 긴 기사나 논문을 한 문단으로 요약
• 성과: GPT‑3.5 summarize 프롬프트 템플릿 완성, 200자 이하 요약 정확도 85% 달성
• 문제점: 비정형 텍스트(표, 코드) 처리 미흡 → 해결책: 사전 전처리 파이프라인 추가

Day 6 – 스타일 변환

• 목표: 사진을 특정 화가 스타일(예: 반 고흐)로 변환
• 성과: Replicate에서 제공하는 Stable Diffusion 모델 호출, 결과물 2초 내 반환
• 문제점: GPU 할당량 초과 → 해결책: 이미지 해상도 512×512로 제한

Day 7 – 감정 분석기

• 목표: 트윗이나 리뷰 텍스트의 감정을 긍정/부정/중립으로 분류
• 성과: Hugging Face distilbert-base-uncased-finetuned-sst-2-english 모델 사용, 정확도 92%
• 문제점: 한글 텍스트 지원 부족 → 해결책: KoBERT 모델로 교체 (다음 프로젝트에 적용)

Day 8 – 추천 시스템

• 목표: 사용자가 좋아할 영화를 예측하고, 이유를 GPT‑3.5가 설명
• 성과: 간단한 협업 필터링 구현 후, GPT‑3.5에 “왜 이 영화를 추천했는가?” 프롬프트 전달
• 문제점: 데이터셋이 작아 과적합 위험 → 해결책: MovieLens 100k 데이터셋으로 확장

Day 9 – AI 작곡가

• 목표: 텍스트 설명(“잔잔한 피아노 멜로디”)을 입력하면 음악 파일 생성
• 성과: Google Magenta MusicVAE와 OpenAI MusicLM API 조합, 30초 길이 MP3 생성 성공
• 문제점: 라이선스 문제(상업적 사용 제한) → 해결책: 로컬 모델로 전환 검토

Day 10 – 자동 번역기

• 목표: 10개 언어 간 실시간 번역 제공
• 성과: GPT‑3.5 translate 프롬프트 활용, UI에 언어 선택 드롭다운 구현
• 문제점: 긴 문장 번역 시 토큰 제한 초과 → 해결책: 문장을 청크 단위로 나눠 순차 번역

🏆 주요 교훈

1. API 비용 관리가 가장 중요

   • 토큰당 비용을 실시간으로 모니터링하고, max_tokens와 temperature를 조절하면 예산 초과를 방지할 수 있다.

2. 프롬프트 엔지니어링은 개발 속도를 좌우

   • 같은 모델이라도 프롬프트를 어떻게 구성하느냐에 따라 응답 품질과 비용이 크게 달라진다.

3. 배포 파이프라인을 미리 설정하라

   • Vercel, Railway, Render 등 무료 티어를 활용하면 하루에 여러 번 배포해도 비용이 발생하지 않는다.

4. 에러 핸들링을 자동화

   • API 호출 실패 시 재시도 로직과 사용자 친화적인 오류 메시지를 미리 구현해 두면 디버깅 시간이 절반으로 줄어든다.

5. 다양한 언어와 프레임워크에 익숙해지는 좋은 기회

   • React → Next.js → FastAPI → Docker까지 전 과정을 경험하면서 풀스택 역량이 크게 향상되었다.

📚 앞으로 할 일

• 한글 지원 강화: 현재 대부분의 모델이 영어에 최적화돼 있어, KoBERT, KoGPT 등 한국어 전용 모델을 도입할 계획이다.
• CI/CD 파이프라인 구축: GitHub Actions와 Docker Hub를 연동해 자동 테스트와 배포를 구현한다.
• 비용 최적화: 모델 별 토큰 사용량을 분석하고, 필요 시 로컬 오픈소스 모델(예: LLaMA, Stable Diffusion)로 전환한다.
• 커뮤니티 피드백 수집: 각 애플리케이션에 간단한 설문을 삽입해 사용자 경험을 정량화하고, 개선 포인트를 도출한다.

🙏 마무리

5일이라는 짧은 기간에 10개의 AI 프로젝트를 만들면서 **“가능성은 무한하지만, 현실적인 제약(비용, 시간, 인프라)도 존재한다”**는 것을 몸소 체험했다. 초보자라면 처음부터 완벽한 제품을 만들려 하기보다, 작은 목표를 정하고 빠르게 실험하고, 피드백을 받아 개선하는 루프를 반복하는 것이 가장 효과적이다.

“시작이 반이다.” – 오늘도 새로운 AI 아이디어를 실험해 보세요!

사흘 전 나는 API가 무엇인지에 대해 읽고 있었다.

4일 차가 되자 나는 내 컴퓨터에서 로컬로 실행되는 작동하는 RAG 애플리케이션을 갖게 되었다 — 외부 서버에 아무것도 보내지 않고, 내가 제공한 문서를 사용해 질문에 답변할 수 있는 애플리케이션이다.

그게 어떻게 된 건지 아직도 확신이 서지 않지만, 그 느낌이 사라지기 전에 적어두고 싶다.

이것이 여정에서 차지하는 위치

저는 IBM Applied AI Developer Professional Certificate를 중간 단계에 있습니다. 5과목과 6과목에서 모든 것이 바뀌었습니다 — 개념을 이해하는 단계에서 실제로 무언가를 구축하는 단계로. 5일 동안 10개의 프로젝트를 진행했습니다.

Note: 이것은 강좌 리뷰가 아닙니다. 실제로 구축했을 때의 느낌을 기록한 것입니다.

Source:

코스 5 — Flask와 백엔드 개발

나는 백엔드가 관리 가능할 것이라고 생각하고 시작했다.

• 대학 1학년 때 MERN‑stack 모듈에서 Node.js를 배웠다. 라우팅, 요청, 서버가 작동하는 방식 같은 기본을 기억하고 있었다. 기본이 있기에 어느 정도 자신감이 있었다.
• 고려하지 못한 점: 그 첫 해 이후로 백엔드를 전혀 건드리지 않았다. 관심이 완전히 프론트엔드로 옮겨갔다. 2년 동안 UI를 작성하고, 가끔 친구들의 디버깅을 도와주며 다른 모든 것은 잊혀졌다.

그래서 Flask가 등장했을 때, 내가 생각했던 것만큼 Node를 기억하고 있지는 않았다. 기억하고 있던 것은 개념—백엔드가 어떻게 작동해야 하는지—이었다. 문법이 완전히 달랐음에도 불구하고 그 개념만으로 적응할 수 있었다.

단위 테스트의 놀라움

수업에서 단위 테스트가 언급되는 것을 보았지만 항상 머리 속에서 “나중에 신경 쓸게”라고 넘겨버렸다. 코스 5에서 비로소 처음으로 그 의미를 이해했다:

• 무엇을 확인하는가 – 각 코드 조각이 기대대로 동작하는지.
• 왜 중요한가 – 회귀를 초기에 잡아낸다.
• 테스트 작성이 추가 작업이 아닌 이유 – 실제 소프트웨어를 작성하는 과정의 일부이다.

개인적인 일화

졸업 연도에 캠퍼스 채용을 진행하던 중, 한 기업이 해커톤을 통해 나를 선발하고 최종 면접을 잡았다. 그들은 내가 테스트 역할에 편한지 물었다.

나는 테스트에 대해 잘 모르고 프론트엔드, 웹 개발, 혹은 AI 쪽을 선호한다는 답을 했다.

그 결과 제안을 받지 못했다.

두 해 뒤 Flask 단위 테스트 모듈을 수강하면서, 그 면접에서 가볍게 넘겼던 것이 바로 테스트였으며, 그것이 결국 기회를 놓친 원인이라는 것을 비로소 깨달았다.

코스 5에서 진행한 프로젝트

• Finance Tracker
• Sentiment Analyzer
• Emotion Detector

이 프로젝트들은 내가 실제 프론트엔드와 Flask 백엔드를 처음 연결하고, AI 출력이 전체가 아니라 하나의 기능으로 애플리케이션에 어떻게 녹아드는지를 직접 확인한 첫 사례들이다.

Course 6 — Building GenAI‑powered applications

This is where the ten projects came together:

• Image Captioner
• Chatbot
• Voice Assistant
• Meeting Assistant
• Translation Assistant
• Job Application Coach (the one I want to spend the most time on)

The BlenderBot problem

The chatbot in the course used the BlenderBot model from Meta. In my experience, it was not BlenderBot – it was BlunderBot.

• Responses were off — sometimes irrelevant, sometimes just strange.
• I spent time trying to figure out if I’d built it wrong before I realized the model itself was the issue.

Lesson learned: the model matters as much as the application around it.

The translation app detour

The IBM translation API I was supposed to use wasn’t accessible from my setup, so I forged my own path:

1. Speech‑to‑text: Whisper
2. Text‑to‑speech: Piper

What I didn’t know going in:

• Piper requires downloading an ONNX model file separately. The app broke until I found and added the file.
• Japanese voice models weren’t available in my configuration.
• The audio format Piper produced wasn’t compatible with the frontend.

Each of those was a small wall. I tackled them one by one, and the final app worked. It wasn’t the one the course intended — but it was mine.

The LangChain version issue

The course imports used langchain.chains. In the current version of LangChain that module has moved to langchain_classic. The course materials hadn’t been updated.

• The application simply wouldn’t run. No obvious error pointed to the real cause.
• I eventually fixed it by either downgrading the package or updating every import. I chose the latter and updated the imports.

This is exactly the kind of thing that doesn’t come up in passive learning. You only hit it when you’re actually building something.

개인 RAG 애플리케이션

RAG – Retrieval‑Augmented Generation – 은 AI 애플리케이션이 응답을 생성하기 전에 사용자 자체 문서에서 관련 정보를 검색하는 것을 의미합니다. 모델이 학습된 내용에만 의존하는 것이 아니라, 사용자가 제어하는 소스에서 정보를 가져옵니다.

이 프로젝트를 구축하는 느낌은 다른 프로젝트들과 달랐습니다:

• 실제 AI 시스템이 어떻게 구조화되는지 직접 볼 수 있었던 첫 번째 프로젝트였습니다 — 질문에 답하는 모델만이 아니라 파이프라인 전체였습니다.

• 파이프라인 흐름:

  1. 문서가 들어감 →
  2. 처리됨 →
  3. 저장됨 →
  4. 검색됨 →
  5. 모델이 이를 사용해 응답함.

• 모든 것이 로컬에서, 프라이빗하게, 그리고 내 제어 하에 실행됩니다.

그 아키텍처 덕분에 이전 강의들에서만 설명되던 내용이 실제로 와닿았습니다.

솔직한 부분 — 이 글에서 가장 중요한 단락

대부분은 가이드된 프로젝트였습니다. 나는 지침을 따르고 제공된 코드를 시작점으로 사용했습니다.

• 가능한 곳마다 직접 버전을 만들었습니다.
• API를 교체하고, 프론트엔드를 바꾸고, 문제를 일으켰다가 고쳤습니다.

가이드된 부분에서도 실제 구현은 수동적인 학습이 숨기는 차이를 드러냅니다. LangChain 임포트를 읽는 것만으로는 오류가 발생했을 때 무슨 일이 일어나는지 알 수 없습니다. RAG를 개념적으로 이해하는 것만으로는 파이프라인을 구축할 때 실제로 어떤 느낌인지 알 수 없습니다.

코드가 실행되지 않을 때만 자신이 모르는 것을 알게 됩니다.

Day 5 – 속도를 늦추며 정리하기

Day 5는 빠르게 만드는 것보다 속도를 늦추는 데에 더 중점을 둡니다.

• 지금까지 배운 모든 것을 다시 살펴보고 — 작업을 검토하고, 빈틈을 메우며, 단순히 넘어가지 않고 더 깊이 이해하려고 합니다.
• 또한 AI 에이전트와 실용적인 딥러닝이라는 다음 주제를 탐색하기 시작합니다.

Jumping into another structured path, I want to build something independently first.

No tutorials. No step‑by‑step course.

Just a real problem, curiosity, and the tools I’ve learned so far.

다음은

Phase one는 완료되었습니다. 기반은 마련되었습니다.

Phase two는 가이드 없이 구축하는 것입니다. 여기서 실제로 무엇이 걸렸는지 알게 될 것입니다. 진행하면서 — 작동하지 않는 부분도 포함해서 — 작성하겠습니다.

지금까지 가이드 프로젝트를 만든 적이 있다면, 언제부터 자신의 작업처럼 느껴졌나요? 특정 순간이 있었나요, 아니면 점차적으로였나요?

댓글에 남겨 주세요. 저는 진심으로 그 경계가 어디인지 파악하려고 합니다. 👇