Part 7. 프로젝트¶

Section ID: P7-index Version: v2026.07.23

Part 7은 앞서 소개한 내용을 실제 입력, 코드 실행, 출력 비교, 오류 해석으로 실습하는 구간입니다. 여기서는 더 새로운 이론을 길게 늘리기보다, 이미 익힌 질문 설정, 비교, 구조 선택, 실행 기록 판단을 하나의 프로젝트 안에서 함께 실행하고 해석합니다.

이 Part는 특히 다음 독자에게 중요합니다.

• AI를 읽을 줄은 알지만 아직 직접 입력을 바꾸고 결과를 비교해 본 적이 적은 독자
• 예제 코드를 따라 했지만 왜 이 출력이 나왔는지, 무엇을 먼저 점검해야 하는지는 아직 모호한 독자
• LLM, RAG, 에이전트 이야기를 들었지만 실제 실행 로그와 품질 검토를 어떻게 읽어야 하는지 정리하고 싶은 독자

프로젝트가 증거로 남겨야 할 것¶

Part 7의 목적은 거대한 서비스를 완성하는 것이 아닙니다. 동시에 형식적인 따라 하기에서 멈추는 파트도 아닙니다. 오히려 다음처럼 실제로 돌려 보며 이해를 굳히는 목표를 분명히 합니다.

• 질문을 한 문장으로 닫고 입력 단위를 분명히 잡기
• 기준점(baseline)을 먼저 실행해 비교의 바닥선을 만들기
• 코드를 실제로 실행하고 출력 표, 예측 결과, 오류 사례를 함께 읽기
• 결과를 맞았다/틀렸다로만 보지 않고 왜 그런지 다시 해석하기
• 실패와 한계를 다음 실험의 수정 항목으로 정리하기
• 필요하면 실행 기록, 평가 메모, 운영 로그까지 함께 검토하기

즉, 이해한 내용을 실제 실행과 검토로 굳히는 것이 Part 7의 핵심입니다.

여기서 중요한 점은 프로젝트를 했다는 말을 코드 파일 하나나 짧은 성공 화면으로 대신하지 않는 것입니다. Part 7에서는 가능한 한 다음 같은 실행 증거와 검토 기록이 실제 프로젝트 문서 안에 함께 정리되어야 합니다.

즉, Part 7은 모델을 만들었다보다 무엇을 실제로 돌려 보았고, 무엇을 확인했고, 어디를 다시 고쳐야 하는가를 더 엄격하게 묻는 파트입니다.

Part 7의 통합 훈련 구조¶

Part 7은 하나의 프로젝트를 질문, baseline, 비교, 구조, 근거, 실행 기록, 운영 회고라는 여러 판단 축으로 다시 읽는 파트입니다. 각 절은 같은 프로젝트 문서에 무엇이 함께 남아야 하는지를 서로 다른 각도에서 드러내는 실습 묶음입니다.

이 구조를 먼저 잡아 두면 Part 7은 예제가 많아서 흩어지는 파트가 아니라, 같은 프로젝트를 여러 판단 축으로 다시 읽고 한 문서로 묶는 파트로 정리됩니다.

실습 축과 대표 위치¶

이 대응표가 중요한 이유는, Part 7이 새 이론을 따로 길게 추가하는 Part가 아니라 질문 설정, 비교, 구조 해석, 근거 확인, 운영 회고가 한 프로젝트 안에서 동시에 얽히는 자리를 다루기 때문입니다. 따라서 지금 막힌 지점이 비교 설계인지, 구조 선택과 학습 해석인지, 근거·도구·운영 판단인지 먼저 가르면 다시 펼칠 절도 더 빨리 좁혀집니다.

실습 기록의 공통 요소¶

개별 절마다 코드 블록이 다르더라도, Part 7의 실행 기록에는 대체로 같은 요소가 남습니다.

이 요소들은 각 Chapter에서 반복됩니다. 질문과 입력은 P7-1.1, 기준선과 해석은 P7-1.2, 실패 분해는 P7-4.2, 근거와 실행 로그는 P7-5.2와 P7-6.2, 운영 회고는 P7-7.2에서 다시 확인할 수 있습니다.

핵심은 코드를 실행했다에서 멈추지 않는 것입니다. Part 7은 실행 자체보다 실행 결과를 어디서 읽고 무엇을 다시 점검해야 하는가를 더 중요하게 다룹니다.

이 절차를 저장소 기준으로 아주 짧게 옮기면 다음처럼 시작할 수 있습니다.

1

.venv/bin/python

그리고 각 절의 코드 블록에서 사용하는 CSV나 기록 파일은 docs/assets/part-07/ 아래에 모여 있으므로, 먼저 어떤 파일을 읽는지만 확인해도 실습 맥락이 훨씬 또렷해집니다.

프로젝트를 여는 질문¶

• 프로젝트는 어디서부터 시작해야 하는가?
• 실제 입력을 어떻게 잘라 한 번의 샘플로 볼 것인가?
• 기준점(baseline)과 개선은 어떻게 비교해야 하는가?
• 딥러닝 프로젝트에서는 무엇을 눈으로 확인해야 하는가?
• RAG와 에이전트 프로젝트에서는 무엇을 품질 기준으로 삼아야 하는가?
• 배포와 운영에서는 어떤 실패 기록이 필요한가?

이 질문들을 실제 프로젝트 문서 기준으로 옮기면 다음과 같습니다.

이 최소 문서 요소를 Part 7의 실제 프로젝트 축으로 다시 쓰면 다음처럼 볼 수 있습니다.

각 축에서 먼저 붙잡아야 할 질문을 짧게 적으면 다음과 같습니다.

작은 프로젝트가 닫아야 할 실행 경계¶

이 Part는 다음 범위를 다룹니다.

• 프로젝트 목표를 세우는 방법
• 입력과 출력 정의
• 기준점(baseline)과 비교
• 결과와 한계 기록
• RAG, 에이전트, 배포 프로젝트의 기본 문서 구조

이 Part는 실전의 전체를 끝내는 파트는 아니지만, 실전으로 들어가기 전에 반드시 직접 돌려 보고 읽어야 할 장면은 분명히 다룹니다. 이 파트의 본편 축은 질문과 입력 정의, 기준점과 비교, 오류 사례와 검토, RAG와 에이전트 실행 기록, 배포와 실패 회고가 따로 떨어진 목록이 아니라 같은 프로젝트 기록 안에서 함께 남아야 하는 요소라는 점입니다. 권한, 운영, 실패 대응의 큰 그림은 본문 안에서도 P7-6.2 권한과 로그 검토, P7-7.1 배포 확인과 상태 점검, P7-7.2 장애 기록과 다음 반복 계획에서 이어집니다.

특히 이 파트에서는 다음 구분을 계속 유지합니다.

• 분석 프로젝트: 질문, 입력 단위, 요약값, 비교표가 중심
• 모델 프로젝트: 기준점(baseline), 예측 결과, 오류 사례, 수정 우선순위가 중심
• RAG/에이전트 프로젝트: 근거 문서, 도구 결과, 실행 기록, 실패 로그가 중심

이 구분은 단순한 장르 분류가 아니라, 어떤 기록을 먼저 정리해야 하는지를 정하는 기준이기도 합니다.

• 분석 프로젝트에서는 요약값보다 질문과 입력 단위가 먼저입니다.
• 모델 프로젝트에서는 정확도(accuracy)보다 비교 행과 오류 샘플이 먼저입니다.
• RAG 프로젝트에서는 답변보다 검색 근거와 답변 상태가 먼저입니다.
• 에이전트 프로젝트에서는 성공 여부보다 승인 상태와 다음 조치가 먼저입니다.
• 배포 프로젝트에서는 배포 완료보다 장애 기록과 다음 조치가 먼저입니다.

Part 7에서는 이 예시들이 각 축의 실행 장면 안에 그대로 남아 있어야 합니다. 대신 각 축에서 실제 실행 결과를 어떻게 읽을까가 바로 본문 안에 남아 있어야 합니다. 초심자가 따라 치고 끝나는 예제보다, 입력이 바뀌면 출력과 해석이 함께 바뀌는 실습이 더 중요하기 때문입니다.

이 파트가 직접 끝내지 않는 확장 과제¶

Part 7은 프로젝트 입문과 통합 훈련에 집중하므로, 다음 과제까지 직접 끝내지는 않습니다.

• 팀 단위 협업 문서와 실험 추적 체계를 어떻게 설계할 것인가?
• 더 큰 데이터셋과 더 긴 운영 로그를 어떤 기준으로 관리할 것인가?
• 배포 자동화와 권한 검토를 어느 단계까지 문서화할 것인가?

즉, Part 7은 프로젝트를 시작하고 회고하는 최소 구조를 닫는 파트이지, 모든 실무 체계를 여기서 끝내는 파트는 아닙니다.

이 파트를 읽고 나면 생겨야 할 이해¶

Part 7을 읽고 나면 독자는 다음 정도의 감각을 가져야 합니다.

• 프로젝트는 구현보다 먼저 질문과 기준점을 정해야 한다.
• 입력 단위와 기준선이 흔들리면 뒤의 결과 해석도 흔들린다.
• 기준점(baseline)과 개선 비교가 없는 모델 결과는 해석이 약하다.
• LLM 프로젝트는 답변 예시뿐 아니라 검색 실패, 도구 실패, 권한, 로그까지 함께 읽어야 한다.
• 프로젝트 회고는 실패를 숨기는 문서가 아니라 다음 반복을 준비하는 문서다.

이 다섯 줄을 가장 짧게 묶으면 다음과 같습니다.

프로젝트는 코드를 한 번 실행하는 일이 아니라, 왜 그런 결과가 나왔는지 다시 읽을 수 있게 만드는 일이다.

프로젝트 기록의 공통 기준¶

Part 7의 각 프로젝트는 가능한 한 다음 흐름으로 정리합니다.

• 문제 정의
• 데이터 또는 입력
• 접근 방법
• 구현
• 결과
• 한계와 개선점
• 출처와 참고 자료

이 형식은 기계적인 템플릿이라기보다, 프로젝트를 다시 실행하고 다시 읽을 수 있게 만드는 최소 공통 구조입니다. 다만 실제 본문에서는 형식 이름보다 실행 장면이 먼저 보여야 합니다. 예를 들어 결과 절이라면 점수 한 줄보다 비교표와 오류 사례가 먼저 보여야 하고, 구현 절이라면 긴 코드보다 입력과 출력이 어떻게 바뀌는지가 먼저 보여야 합니다.

생성형 AI 관련 프로젝트에서는 여기에 다음 항목이 자주 추가됩니다.

• 근거 문서 또는 검색 결과
• 도구 호출 결과 또는 실행 로그
• 자동 평가 결과
• 사람 검토 메모
• 실패 시 실행 기록 또는 대체 조치 기록

이 공통 기준을 실제 기록으로 다시 읽으면 다음과 같습니다.

이 질문들을 더 실전적으로 줄이면 다음처럼도 점검할 수 있습니다.

완료 기준¶

• 프로젝트를 질문, 입력, 구현, 결과, 회고 흐름으로 정리할 수 있다.
• 기준점(baseline)과 개선 모델의 차이를 실제 비교 결과로 설명할 수 있다.
• RAG와 에이전트 프로젝트에서 품질과 운영 관점을 함께 읽을 수 있다.
• 실패 기록과 다음 개선 계획을 프로젝트 결과 안에 남길 수 있다.

가장 짧게 줄이면 Part 7의 완료 기준은 다음 한 문장으로 묶입니다.

실제로 돌려 본 프로젝트를 다시 실행하고 다시 해석할 수 있는 기록을 남길 수 있어야 한다.

이 파트에서 남아야 하는 판단 기준¶

Part 7을 읽고 난 뒤에도 아래 기준이 기록으로 남지 않았다면, 이 Part의 실습 축이 아직 충분히 닫히지 않은 것입니다.

• 결과 숫자는 남기는데 기준점(baseline), 오류 사례, 회고 메모가 빠지는 경우
• RAG나 agent를 설명하면서도 근거 기록, 실행 기록, 권한 기록이 함께 남지 않는 경우
• 배포 이후 무엇을 확인하고 무엇을 실패 기록으로 남겨야 하는지 기준이 흔들리는 경우

이 경우에는 새 기능을 더 붙이기 전에 질문 -> 실행 -> 평가 -> 회고 구조를 다시 고정하는 편이 맞습니다.

체크리스트¶

• 프로젝트 목표를 한 문장으로 다시 적을 수 있는가?
• 기준점(baseline), 비교표, 오류 사례, 실패 기록 중 무엇이 빠졌는지 바로 말할 수 있는가?
• RAG와 agent에서 근거/도구/권한 기록을 분리해 읽을 수 있는가?
• 다음 반복을 위한 회고 문장을 각 프로젝트 축마다 남길 수 있는가?

출처와 참고 자료¶

이 문서는 Part 7의 목적과 학습 경로를 정리한 자체 개요입니다. 외부 자료를 직접 인용하지 않았습니다.