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

About this offer

대상 기간 : 2026-09-21 ~ 2026-09-23 (5~7일차) | 형식 : 4L | 작성일 : 2026-09-28 Liked 1주차에는 파이썬과 Git처럼 어느 정도 알고 있던 내용을 다시 배우는 부분이 많아서, 예습과 복습은 필요했지만 크게 무리하지 않는 선에서 혼자 보충하고 머릿속에 구조화해 나갈 수 있었다. 반면 2주차에는 처음 배우는 FastAPI 와 웹 프레임워크의 구조가 본격적으로 등장했다. 생각보다 훨씬 많은 시간이 필요했지만, 이해되지 않는 부분을 그냥 넘기지 않고 질문을 계속 쪼개서 다시 확인했다. 5일차 에는 FastAPI의 요청·응답 구조 와 경로·쿼리 매개변수 를 배우며 도서 목록 API를 구현해봤다. limit=0 과 /tasks/99 를 비교해 422 와 404 가 발생하는 지점을 구분하고, total 과 실제 반환되는 items 가 왜 다를 수 있는지도 직접 계산하며 확인했다. 처음 접하는 내용이었지만, 큰 흐름과 구조를 내 언어로 바꾸어 기록하고 그림으로 순서를 그려보면서 비교적 높은 이해도로 마무리했다고 생각한다. 6일차 에는 Pydantic 요청 검증, 응답 모델, 의존성 주입 이 한꺼번에 등장하면서 지금까지의 일일학습 중 가장 오랜 시간이 걸렸다. 학습하다가 회의감이 들 정도로 막히기도 했지만 정리를 포기하지 않고, 파이썬의 함수와 클래스 구조까지 되돌아가 다시 확인하려 노력했다. 6일차 당일에는 세부 코드를 전부 설명하지 못했어도, 이후 카페 주문 API를 다시 살펴보며 요청 모델·응답 모델·내부 기록의 역할을 구분하고 전체 흐름을 다시 연결할 수 있었다. 7일차 에는 비동기 처리, 외부 API, 예외 처리, 미들웨어, CORS 처럼 새로운 용어와 구조가 더해졌다. 수업 중에는 한 번 흐름을 놓친 뒤 코드를 따라 적기 바빴고, 트러블슈팅이 발생했을 때 이유를 이해하지 못한 채 AI에게 묻고 수정하기도 했다. 그래도 이후 질문을 작은 단위로 쪼개 다시 정리하면서, 당일에는 이유를 몰랐던 오류가 왜 발생했는지 설명할 수 있게 됐다. 추석 연휴 동안 완전히 쉬기보다 매일 조금씩이라도 학습하려고 했다. 6일차 카페 주문 API 와 7일차 상품 목록 페이지 API 를 다시 복습하면서, 5~7일차의 내용이 각각 떨어진 기능이 아니라 요청 한 건이 들어와 검사되고 처리된 뒤 응답으로 나가는 하나의 흐름이라는 점을 조금씩 연결할 수 있었다. 연휴가 없었다면 수업 진도를 따라가는 것만으로도 벅찼을 것 같지만, 쉬는 동안 부족했던 부분을 다시 볼 수 있었던 것이 다행이었다고 생각한다. 왕복 3시간의 출퇴근과 9시부터 6시까지 이어지는 교육, 캠퍼스에서의 자율학습 루틴에도 아직 적응하는 중이다. 부족한 점은 많지만, 첫 주보다 생활과 학습 리듬을 조금씩 만들어가고 있다는 점에서는 앞으로가 더 기대된다. Lacked 1주차에는 이미 접해본 파이썬과 Git을 중심으로 학습했기 때문에 모르는 부분을 혼자 보충하고 구조화하는 것이 가능했다. 하지만 2주차에는 FastAPI라는 웹 프레임워크 자체를 익혀야 했고, 클라이언트의 요청부터 서버의 검증과 처리, 응답까지 이어지는 전체 흐름도 함께 이해해야 했다. 여기에 실제 서비스에서는 각 기능이 왜 필요한지, 서비스 기획과는 어떻게 연결되는지까지 생각하려 하니 확실히 더 많은 시간 투자가 필요했다. 5일차에는 개념 이해도를 ‘상’이라고 생각했지만, 실제로 API를 실행하고 PR을 제출하는 과정에서는 서버 상태, 터미널 작업 위치, Git/GitHub 절차를 매 단계 AI에게 확인했다. 개념을 안다고 느끼는 것과 실제로 혼자 실행하는 것 사이에는 아직 간극이 있었다. 자기 지식에 대한 확신이 부족해 작업 과정 하나하나가 늦어지는 문제도 있었다. 6일차에는 “모델 객체를 함수에 전달한다”는 문장에서 막혀 파이썬의 함수와 클래스까지 다시 돌아가야 했다. 요청 모델과 응답 모델을 왜 따로 만드는지, 내부 기록과 공개 응답을 왜 분리하는지, 의존성 함수는 누가 언제 실행하는지 등이 한꺼번에 겹치면서 확실히 멘붕이 왔다. 모델과 함수를 관련 있다는 이유로 같은 클래스 안에 넣으려 했던 것처럼, 코드의 소속과 역할을 나누는 기준도 아직 부족했다. 7일차에는 비동기·외부 API가 예외·미들웨어·CORS보다 어렵게 느껴졌다. async def , 코루틴, await , 이벤트 루프, 블로킹·논블로킹처럼 비슷해 보이는 용어가 한꺼번에 등장했고, 코드도 점점 길어졌다. 큰 흐름은 잡았지만 실습 코드를 보면서 모든 줄의 입력, 실행 시점, 반환값을 바로 설명할 수 있는 수준은 아니었다. 수업 중 실습을 따라가고 당일 내용을 모두 복습하는 것만으로는 시간이 부족했다. 새로운 주제의 구조를 모르는 상태에서 정규 수업에 들어가면, 초반에 한 번 흐름을 놓친 뒤 뒤의 코드까지 계속 따라가기 어려워지는 문제가 있었다. 6~7일차에 특히 이 문제가 크게 드러났다. Learned 5일차에는 클라이언트와 서버, HTTP 요청·응답, GET과 POST, REST의 기본 설계 원칙을 배웠다. 경로 매개변수는 자원 하나를 특정하고, 쿼리 매개변수는 목록을 검색·필터링·정렬·페이지 처리하기 위한 조건이라는 기준을 익혔다. 요청 값의 형식이나 범위가 잘못되면 422 , 형식과 범위는 맞지만 실제 데이터가 없으면 404 가 된다는 것을 알게 됐다. offset 과 limit 은 조건에 맞는 결과 중 실제로 보여줄 구간을 정한다. total 은 이 범위를 적용하기 전에 조건에 맞았던 전체 개수다. 처음에는 limit=1 이면 total 도 1이라고 생각했지만, 포장 주문이 2개라면 한 건만 반환되더라도 total 은 2라는 것을 예시로 계산하면서 정정했다. 6일차에는 요청 검증, 의존성 주입, 응답 모델이 요청 처리 흐름의 서로 다른 위치에서 작동한다는 것을 배웠다. 요청 모델은 클라이언트가 보낸 본문을 경로 함수 실행 전에 검사하고, 의존성 함수는 여러 경로가 함께 사용하는 쿼리와 공통 준비물을 만든다. 응답 모델은 경로 함수가 처리한 결과 중 클라이언트에게 공개하기로 약속한 필드만 내보낸다. 카페 주문 API에서는 클라이언트가 menu_name , quantity , takeout 을 보내고, 서버가 id , status , staff_note 를 추가한다. 이 중 staff_note 는 내부 기록에만 보관하고 응답에는 포함하지 않는다. 생성·상세 응답과 목록 응답의 필드도 서로 다르기 때문에 각각의 공개 응답 모델이 필요하다. 요청 모델과 응답 모델은 단순히 클래스를 여러 개 만드는 것이 아니라, 들어오는 데이터와 나가는 데이터의 계약을 분리하기 위한 구조라는 점을 이해했다. 두 목록 경로는 같은 의존성 함수를 사용해 status , takeout , offset , limit 을 받는다. Depends(get_order_filters) 처럼 함수 자체를 전달해두면 FastAPI가 요청 시점에 호출하고, 검증된 결과를 경로 함수에 넣어준다. 메뉴별 목록은 먼저 경로의 menu_name 으로 주문을 고른 뒤 같은 공통 조건을 적용한다. 카페 주문 API를 다시 확인하면서 정상 생성은 201 , 잘못된 수량은 422 , 존재하는 주문 상세 조회는 200 , 없는 주문은 404 가 되는 것을 확인했다. response_model 을 통해 내부의 staff_note 가 응답에서 제외되는 것도 확인했다. 처음에는 각각의 상태 코드와 모델을 따로 외웠지만, 지금은 요청이 어느 단계에서 실패했는지에 따라 결과가 달라진다고 이해하고 있다. 7일차에는 비동기가 한 작업 자체를 빠르게 만드는 것이 아니라, 외부 응답을 기다리는 동안 다른 요청을 처리할 수 있게 하는 실행 방식이라는 것을 배웠다. async def 함수를 호출하면 바로 결과가 나오는 것이 아니라 코루틴 객체가 만들어지고, await 해야 함수가 실행되어 반환값을 받을 수 있다. 비동기 함수 안에서도 time.sleep() 같은 블로킹 코드를 사용하면 이벤트 루프 전체를 막을 수 있기 때문에, async def 라고 썼다는 사실만으로 비동기 처리가 완성되는 것은 아니다. 상품 목록 페이지 API에서는 우리 API의 page 와 size 를 외부 API의 skip 과 limit 으로 변환한다. 외부 API의 응답은 외부 응답 모델로 먼저 검사하고, 그중 필요한 필드만 우리 공개 응답 모델로 옮긴다. 외부의 title 을 우리 응답의 name 으로 바꾸고, 이미지·리뷰·내부 메타데이터는 공개하지 않는다. 이는 6일차에 배운 “내부 기록과 공개 응답의 분리”를 외부 데이터에도 적용한 구조였다. 외부 API를 호출할 때 우리 FastAPI는 브라우저 앞에서는 서버지만, 외부 API 앞에서는 HTTP 클라이언트가 된다. 외부 응답 시간 초과는 504 , 연결 실패·외부 오류 상태·예상과 다른 JSON 구조는 502 로 구분한다. 입력 검증 실패 422 , 업무상 존재하지 않는 데이터 404 , 외부 서비스 문제 502·504 처럼 실패가 발생한 위치에 따라 상태 코드가 달라진다는 흐름도 연결할 수 있었다. 결국 5~7일차에 배운 내용은 요청 한 건의 흐름 위에 놓는 게 핵심인 것 같다. 클라이언트가 값을 보내면 입력 검증이 먼저 이루어지고, 필요한 공통 조건은 의존성 함수가 준비한다. 경로 함수가 내부 로직이나 외부 API 호출을 수행하고, 예외는 실패 위치에 맞게 처리된다. 마지막에는 응답 모델이 공개 범위를 제한하며, 미들웨어는 이 요청과 응답의 앞뒤에서 공통 처리를 담당한다. Longed for 정규 수업이 끝난 뒤 복습만 빠르게 따라가는 방식에서 한 단계 더 나아가고 싶다. 퇴근길에는 다음 날 자료의 소제목을 먼저 훑고, 이미 아는 것 / 처음 보는 것 / 이전 흐름과 연결되는 부분 으로 짧게 나누어 적어봐야겠다. 완전히 이해하려 하지 않고, 다음 날 무엇을 배우는지에 대한 지도라도 먼저 만들어둔 상태로 들어가야 흐름을 빠르게 따라갈 수 있을 것 같다. 수업 중 새로운 기능이 나오면 문법부터 전부 이해하려 하지 않고, 먼저 요청 → 입력 검증 → 의존성 → 경로 함수 → 내부·외부 처리 → 예외 → 응답 모델 중 어디에 놓이는 기능인지 표시한다. 전체 지도에서 위치를 먼저 잡은 뒤 세부 코드를 보는 순서로 접근한다. 복습할 때는 그날 배운 코드를 처음부터 끝까지 다시 보는 것보다, 가장 막힌 개념 하나를 골라 정상 요청과 실패 요청을 각각 한 번씩 실행한다. 실행 전 예상 상태 코드와 응답을 먼저 적고, 실제 결과와 다른 부분만 다시 확인해볼 것. AI에게 코드를 요청하거나 수정하게 할 때는 먼저 목표, 입력, 출력, 검증 규칙, 상태 코드, 수정 범위를 직접 정리한다. 생성된 코드는 요청 범위를 벗어나지 않았는지, 배우지 않은 문법이 추가되지 않았는지, 내부 필드가 공개되지 않는지, 정상·실패 요청 결과가 계약과 일치하는지를 확인한다. “AI가 짜준 코드”가 아니라 “내가 이해하고 검증한 코드”로 남기는 것을 계속 연습하고자 한다. 아직 모든 코드를 백지에서 완성하거나 한 줄씩 바로 설명할 수 있는 단계는 아니다. 우선은 요청 한 건이 들어와 응답으로 나가기까지의 흐름을 놓치지 않고, 각 모델과 함수가 왜 그 위치에 있는지를 설명할 수 있는 수준을 단단하게 만들고 싶다. 이 기반을 바탕으로 다음 주의 API 테스트와 CRUD 통합에서는 새로운 내용을 따라가는 데만 급급하지 않고, 앞서 배운 FastAPI 구조를 실제 기능 안에서 반복해서 적용해보고 싶다. 📎 2주차 (9월 4주차) 일일회고 velog <5일차> FastAPI 설치 및 매개변수 <6일차> 요청 검증-응답모델-의존성 <7일차> 비동기처리-예외처리-미들웨어-CORS #FastAPI #웹프레임워크 #API구현