[SK네트웍스 Family 엔코아AI캠퍼스] AI 오케스트레이션 캠프 1기_8월 2주차 회고

이번 주 학습 요약

8월 2주차에는 22일차부터 26일차까지 수업을 진행했다.

이번 주 전반부에는 지난주부터 진행했던 공공임대 청약 통합 안내 서비스 미니프로젝트를 마무리했다. 다중 이미지 업로드, 안전한 일괄 삭제, PDF·HWPX 공고문을 이용한 Gemini 자동 등록 기능을 구현하고 테스트한 뒤 최종 발표까지 진행했다.

후반부에는 다시 수업 진도로 돌아와 JWT와 RLS를 이용한 인증·권한 관리, Docker, PostgreSQL, Redis, pgvector, Ollama 등을 학습했다. 기존에는 Supabase나 Upstash처럼 외부에서 제공하는 서비스를 주로 이용했다면, 이제는 Docker를 이용해 필요한 환경을 직접 실행하고 관리하는 단계로 넘어갔다.

특히 이번 주에는 AI가 코드를 빠르게 만들어주는 것보다 AI가 만든 결과를 검증하고, 구현하기 전에 사람이 구조와 계획을 먼저 이해하는 것이 중요하다는 점을 여러 실습을 통해 느낄 수 있었다.

---

주요 학습 내용

1. 공공임대 청약 서비스 기능 보완과 미니프로젝트 마무리

미니프로젝트에서는 하나의 청약 공고에 여러 장의 사진을 등록할 수 있도록 이미지 구조를 개선했다.

단순히 업로드 가능한 이미지 개수만 늘리는 것이 아니라 업로드 용량 제한, 대표 이미지 결정, 이미지 개별 삭제, 일부 업로드가 실패했을 때 이미 저장된 파일을 정리하는 과정까지 고려했다. 사용자 화면과 관리자 화면에서도 목록에서는 대표 이미지만 보여주고 상세 화면에서 전체 이미지를 확인할 수 있도록 역할을 나누었다.

여러 공고를 한 번에 삭제할 수 있는 기능도 추가했다.

일괄 삭제는 편리하지만 실수했을 때 피해도 커질 수 있기 때문에 현재 페이지에 표시된 공고만 선택할 수 있도록 하고, 실제 삭제 전에 선택한 공고의 개수와 이름을 다시 확인하도록 구성했다.

프로젝트 마지막에는 팀원들이 구현한 기능을 하나의 서비스로 다시 확인하고 최종 발표를 진행했다.

이번 프로젝트를 통해 Streamlit, FastAPI, Supabase를 각각 사용하는 것에서 한 단계 더 나아가 프론트엔드 → 백엔드 → 데이터베이스 → Storage가 하나의 서비스에서 어떻게 연결되는지 경험할 수 있었다.

2. Gemini를 이용한 청약 공고 자동 등록

관리자가 긴 청약 공고문을 보면서 데이터를 하나씩 입력하는 반복 작업을 줄이기 위해 PDF와 HWPX 문서를 Gemini로 분석하는 기능도 만들었다.

전체 흐름은 다음과 같이 구성했다.

PDF·HWPX 업로드 → 글자와 이미지 추출 → Gemini가 청약정보 구조화 → 프로그램 검증 → 관리자가 결과 확인 → 선택한 공고만 등록

PDF는 원본 문서의 표 구조를 최대한 유지해서 Gemini가 분석하도록 하고, HWPX는 내부의 XML과 이미지 파일을 직접 추출하는 방식을 사용했다. 같은 문서처럼 보여도 파일 내부 구조에 따라 처리 방법이 달라져야 한다는 점을 배웠다.

가장 중요했던 부분은 AI가 추출한 데이터를 바로 저장하지 않는 것이었다.

Gemini가 정상적인 JSON을 만들어도 날짜나 보증금처럼 실제 내용이 틀릴 수 있기 때문에 프로그램에서 한 번 검증하고, 마지막에는 관리자가 다시 확인하도록 했다. 자동화는 사람의 판단을 없애는 것이 아니라 반복 작업을 줄여주는 방향으로 사용하는 것이 좋다는 것을 느꼈다.

3. JWT와 RLS를 이용한 인증·권한 관리

미니프로젝트가 끝난 뒤에는 서비스의 보안을 조금 더 깊게 공부했다.

화면에서 로그인하지 않은 사용자의 메뉴를 숨겼다고 해서 실제 API가 보호되는 것은 아니다. API 주소를 알고 있다면 화면을 거치지 않고 직접 요청할 수도 있기 때문이다.

이를 막기 위해 로그인에 성공하면 JWT를 발급하고 이후 API 요청마다 Authorization Header를 통해 토큰을 전달하는 구조를 학습했다.

JWT가 서버에 들어오는 사용자를 확인하는 역할이라면 RLS(Row Level Security)는 데이터베이스 안에서 어떤 사용자가 어떤 데이터에 접근할 수 있는지를 제한하는 역할로 이해했다.

Authentication → 누구인가?

Authorization → 무엇을 할 수 있는가?

RLS → 어떤 데이터까지 접근할 수 있는가?

단순히 로그인이 성공하는 것에서 끝나는 것이 아니라 서비스에는 여러 단계의 보안이 필요하다는 점을 알게 됐다.

4. Docker·PostgreSQL·Redis·로컬 LLM 환경 구성

이번 주 후반에는 Docker를 이용해 PostgreSQL과 Redis를 직접 실행했다.

Docker의 Image와 Container 개념을 배우고 Redis 컨테이너를 실행하면서 포트 연결과 컨테이너 관리 방법을 실습했다. Ollama를 이용해 Llama 같은 LLM을 로컬 환경에서 실행하는 방법도 확인했다.

26일차에는 PostgreSQL과 Redis를 Docker에서 직접 실행하고 pgvector도 살펴봤다.

pgvector는 텍스트를 Vector 형태로 저장하고 질문과 가까운 데이터를 검색할 수 있기 때문에 앞으로 배우게 될 RAG에서도 중요한 역할을 하게 된다. Redis에서는 빠른 데이터 처리뿐 아니라 TTL과 Pub/Sub 같은 기능도 다시 정리했다.

기존 프로젝트의 데이터베이스도

Frontend → FastAPI → Supabase PostgreSQL

구조에서

Frontend → FastAPI → Docker PostgreSQL

구조로 변경하는 연습을 진행했다.

---

실습 및 문제 해결

이번 주에는 기능 구현뿐만 아니라 여러 오류를 직접 해결하면서 배운 내용도 많았다.

다중 이미지 업로드에서는 일부 파일만 저장된 상태에서 오류가 발생할 경우 Storage에 필요 없는 파일이 남을 수 있었다. 그래서 업로드가 중간에 실패하면 이미 올라간 파일도 다시 삭제하는 예외 처리가 필요했다.

Docker 설치 과정에서는 가상화가 활성화되어 있어도 WSL이나 Virtual Machine Platform 등의 설정 때문에 Docker가 정상적으로 실행되지 않는 문제를 경험했다. 단순히 화면에 표시되는 오류만 보는 것이 아니라 관련된 환경설정을 하나씩 확인하면서 원인을 줄여나가야 했다.

PostgreSQL 컨테이너에 접속할 때도 인터넷에서 본 명령어를 그대로 사용하는 것이 아니라 실제 .env와 Docker Compose에 설정된 Container 이름, 사용자 이름, Database 이름 등을 먼저 확인해야 했다.

이전에는 오류가 발생하면 바로 AI에게 해결을 요청하는 경우가 많았는데, 이번 주에는 로그와 환경설정, 기존 코드의 구조를 먼저 확인하는 습관이 중요하다는 것을 많이 느꼈다.

---

KPT 회고

Keep

기능을 만들고 끝내지 않고 실제 사용자 입장에서 여러 예외 상황까지 테스트한 방식은 계속 유지하고 싶다.

특히 AI 자동 등록 결과를 바로 저장하지 않고 프로그램 검증과 관리자 확인 단계를 넣었던 것처럼, AI가 만들어준 결과도 한 번 더 확인하는 습관을 가져가려고 한다.

GitHub에서도 Issue → Branch → 구현 → Test → Pull Request → Merge 흐름으로 기능을 나누어 작업하면서 변경 이유와 테스트 결과를 기록한 것이 프로젝트를 정리하는 데 도움이 됐다.

Problem

이번 주 후반에는 JWT, RLS, Docker, PostgreSQL, Redis, Ollama처럼 새로운 개념이 한꺼번에 많이 등장하면서 각각의 역할이 처음에는 헷갈렸다.

Docker 환경에서는 Windows, WSL, Container, Image, Port, 환경변수 등 여러 설정을 함께 확인해야 해서 오류의 원인을 찾는 데 시간이 걸렸다.

AI 코딩 도구를 사용하면 코드는 빠르게 만들어지지만, 만들어진 코드를 모두 이해하지 못하면 프로젝트 구조가 조금만 달라져도 직접 수정하기 어려울 수 있다는 점도 느꼈다.

Try

앞으로는 큰 기능을 AI에게 바로 구현시키기보다 다음 순서를 지키면서 작업해 보려고 한다.

현재 프로젝트 분석 → 구현 계획 작성 → PLAN.md 확인 → 사람이 계획 검토 → 구현 → 변경된 코드 다시 공부

이번 PostgreSQL 마이그레이션에서도 AI가 만든 계획 안에 실제 환경설정과 다른 값이 들어간 경우가 있었기 때문에, 계획 단계부터 사람이 검토하는 과정이 중요했다.

또한 AI 없이도 기존 코드를 참고해 간단한 FastAPI Router, Service, Database 구조를 직접 연결해보면서 기본기를 계속 연습하고 싶다.

---

다음 주 계획

다음 주부터는 이번에 구성한 Docker PostgreSQL, Redis, Ollama 등의 환경을 바탕으로 LLM과 AI Agent 관련 내용을 본격적으로 공부하게 될 것 같다.

특히 앞으로 RAG나 Agent를 배우기 전에 이번 주에 나온 개념들을 한 번 더 정리하려고 한다.

• JWT와 RLS의 역할 구분
• Docker Image와 Container
• PostgreSQL 기본 사용법
• Redis의 TTL과 Pub/Sub
• pgvector와 Vector 검색
• Ollama와 LLM의 차이
• FastAPI의 Router → Service → Database 흐름
• AI 코딩 도구를 사용할 때 계획부터 작성하는 습관

8월 2주차는 미니프로젝트를 끝내는 동시에 새로운 Chapter를 시작한 한 주였다.

지난주까지는 Streamlit, FastAPI, Supabase를 연결해서 “기능을 어떻게 만들까?”에 집중했다면, 이번 주부터는 “사용자를 어떻게 인증할까?”, “데이터를 어떻게 보호할까?”, “서비스를 어떤 환경에서 실행할까?”까지 생각하는 단계로 넘어간 느낌이다.

아직 Docker나 인증·권한 관련 내용은 익숙하지 않지만, 단순히 화면에서 기능이 작동하는 것만 보는 것이 아니라 서비스 전체 구조를 조금씩 이해해가고 있다.