본문 바로가기
AI 오케스트레이션 캠프/월간 회고

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

by 랩보다 AI 더 잘해지기 2026. 7. 31.
728x90

한 달 학습 요약

7월에는 SK네트웍스 Family 엔코아AI캠퍼스의 멀티 AI 에이전트 개발자 국비지원 과정을 시작했다. 첫 수업부터 16일차까지 개발 환경 구축, Git과 GitHub, Python 기초 문법, FastAPI, Supabase, Render, Streamlit 등을 순서대로 학습했다.

처음에는 개발 도구를 설치하고 터미널 명령어를 입력하는 것부터 시작했다. 이후 Python으로 프로그램의 기본 로직을 작성하고, FastAPI를 이용해 백엔드 API를 만들었다. Supabase 데이터베이스와 연결해 데이터를 저장하고, Render를 이용한 배포도 경험했다.

후반부에는 Streamlit으로 사용자가 직접 조작할 수 있는 화면을 만들었다. 마지막에는 Streamlit 프론트엔드에서 FastAPI 서버에 요청을 보내고, 데이터베이스에 저장된 상품과 고객 정보를 등록·조회·수정·삭제하는 전체 흐름을 실습했다.

한 달 동안 배운 기술이 각각 따로 존재하는 것이 아니라 다음과 같이 연결된다는 점을 알게 되었다.

Python으로 기능을 만들고 → FastAPI로 기능을 외부에 제공하고 → Supabase에 데이터를 저장하고 → Streamlit으로 사용자가 이용할 화면을 만든다.

7월은 멀티 AI 에이전트를 바로 만드는 단계라기보다, 앞으로 AI 서비스를 구현하기 위해 필요한 웹 개발의 기초 체력을 쌓은 한 달이었다.


기술별 학습 내용

1. 개발 환경과 Git·GitHub

과정 초반에는 개발을 시작하기 위한 환경을 준비했다. VS Code, Python, Git 등 필요한 프로그램을 설치하고 터미널에서 명령어를 입력하며 프로젝트를 실행하는 방법을 배웠다.

Git은 코드의 변경 기록을 저장하는 도구이고, GitHub는 Git으로 관리한 프로젝트를 온라인에서 공유하고 협업할 수 있게 해주는 서비스다.

주요하게 학습한 내용은 다음과 같다.

  • Git 저장소 생성과 프로젝트 관리
  • 파일 변경 상태 확인
  • 변경된 파일을 스테이징 영역에 추가
  • 커밋을 이용한 작업 기록 저장
  • GitHub 원격 저장소 연결
  • 코드 업로드와 내려받기
  • 브랜치를 이용한 작업 분리
  • 팀원의 코드를 합치는 협업 과정
  • 충돌이 발생하는 이유와 해결 방법

처음에는 add, commit, push, pull 같은 명령어의 차이가 헷갈렸다. 반복해서 사용하면서 Git의 작업 흐름을 조금씩 이해하게 되었다.

팀 실습에서는 개인 코드를 작성하는 것뿐 아니라 브랜치를 나누고 각자의 작업을 하나의 프로젝트로 합치는 경험도 했다. 코드를 잘 작성하는 것만큼 작업 규칙과 파일 구조를 맞추고, 팀원에게 현재 상황을 정확하게 전달하는 것이 중요하다는 점을 배웠다.

2. Python 기초 문법과 문제 해결

Python에서는 화면 출력과 사용자 입력부터 시작해 프로그램을 구성하는 기본 문법을 학습했다.

  • print()를 이용한 출력
  • input()을 이용한 입력
  • 변수와 자료형
  • 문자열 인덱싱과 슬라이싱
  • 비교 연산자와 논리 연산자
  • if 조건문
  • for, while 반복문
  • 리스트, 튜플, 딕셔너리
  • 함수의 정의와 호출
  • 클래스와 객체의 기본 개념

단순히 문법만 보는 데 그치지 않고, 자연수 입력값을 검사하는 프로그램처럼 조건문과 반복문을 이용한 문제도 직접 풀어보았다. 기존에 작성한 코드를 함수 형태로 나누면서 같은 기능을 다시 사용할 수 있도록 만드는 방법도 연습했다.

코드가 예상대로 실행되지 않을 때는 무작정 전체를 수정하기보다 입력값, 조건식, 반복문의 범위, 자료형을 하나씩 확인해야 한다는 점을 배웠다. 작은 오타나 들여쓰기 하나도 실행 결과에 영향을 줄 수 있기 때문에 오류 메시지를 읽는 습관이 중요했다.

3. FastAPI를 이용한 백엔드 개발

Python 기초를 학습한 뒤에는 FastAPI를 이용해 백엔드 서버를 만들어 보았다.

백엔드는 사용자가 화면에서 보낸 요청을 처리하고, 필요한 데이터를 조회하거나 저장한 뒤 결과를 돌려주는 부분이다. FastAPI는 Python으로 API 서버를 비교적 빠르게 만들 수 있도록 도와주는 프레임워크다.

실습에서는 다음과 같은 HTTP 요청 방식을 사용했다.

  • GET: 데이터 조회
  • POST: 새로운 데이터 등록
  • PUT: 기존 데이터 수정
  • DELETE: 데이터 삭제

처음에는 각 요청 방식이 단순한 문법처럼 느껴졌지만, 직접 CRUD 기능을 구현하면서 역할을 이해할 수 있었다. CRUD는 데이터를 생성하고(Create), 조회하고(Read), 수정하고(Update), 삭제하는(Delete) 기본 기능을 뜻한다.

라우터, 서비스, 스키마처럼 역할에 따라 파일을 나누는 구조도 경험했다. 모든 코드를 한 파일에 작성하는 것보다 기능별로 분리하면 코드가 길어져도 필요한 부분을 찾고 수정하기 쉬워진다는 점을 알게 되었다.

4. Supabase 데이터베이스 연동

FastAPI에서 처리한 데이터를 실제로 저장하기 위해 Supabase를 연결했다.

Supabase는 온라인에서 데이터베이스를 만들고 관리할 수 있도록 도와주는 서비스다. 서버를 종료하더라도 데이터를 유지하려면 프로그램 내부의 임시 데이터가 아니라 데이터베이스에 저장해야 한다.

고객과 상품 정보를 대상으로 다음 기능을 실습했다.

  • 새로운 데이터 등록
  • 전체 목록 조회
  • ID를 이용한 개별 조회
  • 기존 정보 수정
  • 데이터 삭제
  • 같은 ID가 입력되는 상황 확인
  • 존재하지 않는 데이터 처리

특히 상품 등록 과정에서 같은 ID를 입력해도 데이터가 계속 추가되는 문제를 경험했다. 이 과정에서 화면에서 입력값을 검사하는 것만으로는 충분하지 않을 수 있다는 점을 알게 되었다.

중복을 확실하게 막으려면 프론트엔드, 백엔드, 데이터베이스가 각각 어떤 책임을 가져야 하는지 확인해야 한다. 데이터베이스의 기본 키나 고유값 설정도 중요하고, 백엔드에서도 등록 전에 기존 데이터가 있는지 검사해야 한다.

조회는 되지만 수정할 때는 데이터가 존재하지 않는다고 나오는 문제도 있었다. 클라이언트에서 보내는 ID, API 경로, 함수의 매개변수, 백엔드의 조회 조건을 함께 확인하며 오류를 해결했다.

이 경험을 통해 화면에 보이는 오류가 반드시 화면 코드에서 시작되는 것은 아니라는 점을 배웠다. 문제가 발생하면 다음 흐름을 순서대로 확인해야 한다.

Streamlit 입력값 → 클라이언트 요청 → FastAPI 경로 → 서비스 로직 → Supabase 데이터

5. Render를 이용한 서비스 배포

로컬 컴퓨터에서 실행하던 FastAPI 서버를 Render에 배포하는 과정도 경험했다.

배포는 내 컴퓨터에서만 실행되던 프로그램을 인터넷을 통해 다른 사람도 접근할 수 있도록 만드는 과정이다. GitHub 저장소와 Render를 연결하고, 실행 명령어와 환경 변수를 설정해 서버를 올렸다.

로컬에서는 정상적으로 실행되던 코드가 배포 환경에서는 다르게 동작할 수 있다는 점도 배웠다. 파일 경로, 패키지 목록, 환경 변수, 실행 명령어처럼 로컬에서 크게 신경 쓰지 않았던 설정이 배포 과정에서는 중요했다.

Supabase와 Render를 연결해 외부에서도 데이터베이스를 사용하는 API를 실행해 본 것은 웹 서비스의 전체 구조를 이해하는 데 도움이 되었다.

6. Streamlit을 이용한 프론트엔드 구현

후반부에는 Streamlit을 이용해 웹 화면을 만들었다.

Streamlit은 Python 코드만으로 입력창, 버튼, 표, 이미지, 차트 등을 포함한 웹 화면을 만들 수 있는 도구다. HTML과 CSS를 깊게 배우지 않은 상태에서도 Python을 이용해 화면을 구성할 수 있다는 점이 흥미로웠다.

기본 위젯부터 화면 배치까지 다음 내용을 실습했다.

  • 텍스트와 제목 출력
  • 텍스트 입력창
  • 숫자 입력창
  • 선택 상자와 라디오 버튼
  • 버튼을 이용한 동작 실행
  • 이미지 출력
  • columns를 이용한 가로 배치
  • tabs를 이용한 화면 구분
  • sidebar를 이용한 메뉴 구성
  • 데이터프레임 출력
  • 간단한 설문 및 피드백 앱
  • 대시보드 화면 구성
  • 테마 설정
  • 여러 페이지를 연결한 앱 구성

st.set_page_config()는 다른 Streamlit 명령보다 먼저 실행해야 한다는 규칙도 오류를 통해 알게 되었다. 코드는 문법만 맞으면 되는 것이 아니라 프레임워크가 요구하는 실행 순서와 사용 규칙도 지켜야 한다.

7. Streamlit과 FastAPI 연결

마지막 단계에서는 Streamlit 화면과 FastAPI 서버를 연결했다.

Streamlit에서 입력한 상품이나 고객 정보를 클라이언트 함수로 전달하고, 클라이언트가 FastAPI API에 HTTP 요청을 보내도록 구성했다. FastAPI는 요청을 처리한 뒤 Supabase에 데이터를 저장하거나 조회하고, 그 결과를 다시 Streamlit 화면에 표시했다.

고객과 상품 관리 화면에서는 다음 기능을 구현했다.

  • 전체 목록을 표로 출력
  • ID를 입력해 한 건 조회
  • 이름, 나이, 가격 등의 정보 수정
  • ID를 기준으로 데이터 삭제
  • 처리 결과를 JSON이나 메시지로 출력
  • API 요청 실패 시 오류 내용 확인

프론트엔드, 백엔드, 데이터베이스를 각각 배울 때는 기능이 분리되어 보여 다소 막연했다. 하지만 하나의 CRUD 프로그램으로 연결하고 나니 각 기술이 어떤 역할을 담당하는지 명확해졌다.


실습 및 문제 해결

7월에는 코드를 작성하는 시간만큼 오류를 해결하는 시간도 많았다.

대표적으로 경험한 문제는 다음과 같다.

  • Git 브랜치와 파일 상태가 예상과 다르게 나타나는 문제
  • Python의 입력값과 자료형이 맞지 않아 발생한 오류
  • Streamlit 명령어의 실행 순서 문제
  • API 주소와 엔드포인트가 일치하지 않는 문제
  • 클라이언트 함수와 백엔드 함수의 매개변수가 다른 문제
  • 동일한 ID의 상품이 계속 등록되는 문제
  • 조회는 되지만 수정에서는 데이터가 없다고 나오는 문제
  • 로컬 환경과 배포 환경의 설정 차이
  • 여러 파일로 분리한 뒤 import 경로가 맞지 않는 문제

초반에는 오류가 발생하면 전체 코드가 잘못되었다고 생각하기 쉬웠다. 한 달 동안 여러 문제를 해결하면서 오류가 발생한 위치와 데이터가 이동하는 경로를 먼저 확인하는 습관이 조금씩 생겼다.

특히 CRUD 실습에서는 프론트엔드 화면만 봐서는 원인을 알 수 없었다. 실제로 전달되는 ID와 요청 데이터, API 주소, 백엔드 응답, 데이터베이스 상태를 차례로 확인해야 했다.

오류를 해결할 때는 다음 순서가 도움이 되었다.

  1. 오류 메시지를 끝까지 읽는다.
  2. 어느 파일과 어느 줄에서 발생했는지 확인한다.
  3. 입력한 값과 실제 전달된 값이 같은지 살펴본다.
  4. 함수 이름과 매개변수를 비교한다.
  5. API 경로와 HTTP 요청 방식을 확인한다.
  6. 데이터베이스에 실제 데이터가 저장되어 있는지 확인한다.
  7. 수정 후 같은 기능을 다시 실행해 본다.

정답 코드를 바로 보는 것보다 직접 입력하고 실행 결과를 확인한 뒤 문제를 고치는 과정에서 더 많은 것을 이해할 수 있었다.


한 달 전체 회고

7월 수업을 시작할 때는 Python의 기초 문법부터 다시 정리하는 단계였다. 한 달이 지난 지금은 아직 도움과 복습이 필요하지만, Python으로 작성한 기능을 API로 만들고 데이터베이스와 연결한 뒤 웹 화면에서 사용할 수 있는 단계까지 경험했다.

가장 크게 달라진 점은 각각의 기술을 바라보는 방식이다.

처음에는 Git, Python, FastAPI, Supabase, Render, Streamlit이 서로 다른 수업 주제로 느껴졌다. 지금은 하나의 서비스를 만들기 위해 역할을 나누어 맡는 기술이라는 점을 이해하게 되었다.

  • Git과 GitHub는 코드의 기록과 협업을 담당한다.
  • Python은 프로그램의 기본 로직을 작성한다.
  • FastAPI는 요청을 받아 기능을 실행한다.
  • Supabase는 데이터를 저장하고 관리한다.
  • Render는 서버를 외부에서 사용할 수 있게 한다.
  • Streamlit은 사용자가 조작할 화면을 만든다.

팀 협업에 대한 생각도 달라졌다. 개인 실습에서는 내 코드만 실행되면 되지만, 팀 프로젝트에서는 파일명, 함수명, 브랜치, 폴더 구조, API 규칙을 함께 맞춰야 한다. 내가 작성한 코드를 다른 사람이 이해할 수 있도록 설명하는 능력도 개발 과정의 일부라는 점을 느꼈다.

아직 코드를 처음부터 혼자 설계하거나 오류의 원인을 바로 찾는 수준은 아니다. 하지만 오류가 생겼을 때 무작정 겁을 먹기보다 어느 단계에서 문제가 생겼는지 나누어 살펴볼 수 있게 되었다. 이번 달의 가장 큰 성과는 많은 문법을 외운 것이 아니라, 하나의 프로그램이 만들어지는 전체 흐름을 직접 경험한 것이라고 생각한다.


KPT 회고

Keep|계속 유지할 점

첫째, 코드를 직접 입력하고 실행 결과를 확인하는 학습 방식을 유지하고 싶다. 눈으로 읽을 때는 이해한 것 같아도 직접 작성하면 오타, 들여쓰기, 자료형, 함수 연결 등 놓친 부분이 드러났다.

둘째, 오류가 발생했을 때 해결 과정을 기록하는 습관을 이어가고 싶다. 같은 오류를 다시 만났을 때 기록을 참고하면 훨씬 빠르게 해결할 수 있다.

셋째, 하루 동안 배운 내용을 회고로 정리하는 습관을 유지하고 싶다. 글로 설명하는 과정에서 제대로 이해한 부분과 아직 모호한 부분을 구분할 수 있었다.

Problem|아쉬웠던 점

수업에서 여러 기술을 빠르게 배우다 보니 코드를 따라가는 데 집중하고, 각 코드가 왜 필요한지 충분히 이해하지 못한 부분이 있었다.

Git 명령어, FastAPI의 파일 구조, HTTP 요청 방식, Streamlit과 API 사이에서 데이터가 이동하는 과정은 반복적인 복습이 더 필요하다.

오류가 발생했을 때 한 번에 여러 부분을 수정하려는 경우도 있었다. 이렇게 하면 어떤 변경으로 문제가 해결되었는지 알기 어렵기 때문에 앞으로는 하나씩 확인하고 수정해야 한다.

수업과 개인 일정이 함께 이어지면서 체력과 복습 시간을 관리하는 것도 쉽지 않았다. 배운 양을 모두 복습하려 하기보다 중요한 내용을 정해 꾸준히 확인하는 방식이 필요하다.

Try|다음 달에 시도할 점

다음 달에는 수업에서 작성한 코드를 그대로 다시 보는 것에 그치지 않고, 기능을 조금씩 바꾸어 혼자 구현해 보고 싶다.

예를 들어 고객과 상품 CRUD에서 사용한 구조를 다른 데이터에 적용해 보거나, 입력값 검증과 예외 처리를 추가해 볼 수 있다.

또한 다음 내용을 중점적으로 복습할 계획이다.

  • Git 브랜치 생성부터 병합까지 다시 실습하기
  • Python 함수와 클래스 구조 복습하기
  • HTTP 요청과 응답의 흐름 정리하기
  • FastAPI의 router, schema, service 역할 구분하기
  • Supabase의 기본 키와 중복 데이터 처리 이해하기
  • Streamlit과 FastAPI 사이의 데이터 전달 과정 복습하기
  • 오류 메시지를 보고 원인을 찾는 연습하기
  • 완성한 기능을 다른 사람에게 쉽게 설명해 보기

다음 달 계획

8월에는 지금까지 배운 기초 기술을 반복해서 사용하면서 코드의 구조를 더 정확하게 이해하는 것이 목표다.

단순히 코드를 실행하는 것에서 끝내지 않고, 다음 질문에 스스로 답할 수 있도록 복습하고 싶다.

  • 이 파일은 왜 필요한가?
  • 이 함수는 어떤 값을 받아서 무엇을 돌려주는가?
  • 데이터는 어느 순서로 이동하는가?
  • 오류가 발생하면 어느 부분부터 확인해야 하는가?
  • 팀원이 내 코드를 사용할 때 필요한 정보는 무엇인가?

멀티 AI 에이전트를 구현하려면 AI 모델에 대한 이해뿐 아니라 데이터를 주고받는 API, 정보를 저장하는 데이터베이스, 사용자가 이용할 화면, 협업을 위한 Git이 모두 필요하다.

7월에는 그 기반이 되는 도구를 처음부터 하나씩 연결해 보았다. 아직 익숙하지 않은 부분도 많지만, 첫 달에 경험한 시행착오를 바탕으로 다음 달에는 조금 더 스스로 생각하고 구현할 수 있는 단계로 나아가고 싶다.

댓글