Part 7 마무리. 프로젝트 정리¶

Section ID: P7-summary Version: v2026.07.23

Part 7은 앞서 소개한 내용을 실제 프로젝트 실행과 해석으로 실습하는 구간입니다. 이 Part의 핵심은 대형 서비스를 완성하는 것이 아니라, 질문 설정, 비교, 구조 해석, 실행 기록, 운영 판단을 하나의 프로젝트 안에서 함께 묶어 왜 이런 결과가 나왔는가를 스스로 설명할 수 있게 만드는 데 있습니다.

프로젝트 파트는 특히 두 가지를 동시에 확인하게 합니다.

• 개념을 설명할 수 있는가?
• 설명한 개념을 실제 입력과 출력 변화로 확인할 수 있는가?

즉, 이 Part는 알고 있다는 감각을 직접 돌려 보고, 비교해 보고, 실패도 읽어 봤다는 상태로 바꾸는 구간입니다.

반복 가능한 프로젝트 기록으로 묶기¶

Part 7의 목적은 책 전체에서 배운 개념을 실제 프로젝트 실행과 검토 결과로 묶어, 다음 학습이 스스로 반복 가능한 형태가 되게 만드는 데 있습니다.

• 질문 설정, 기준점(baseline), 비교표, 오류 사례는 한 문서 안에서 함께 읽혀야 합니다.
• 입력 구조, 학습 결과 해석, 근거 확인, 실행 로그는 따로따로가 아니라 같은 판단 사슬로 이어져야 합니다.
• 배포·운영 판단도 마지막 부록이 아니라, 프로젝트 품질을 다시 해석하는 기록으로 함께 남아야 합니다.

남아야 할 설명 능력¶

이 Part를 마친 뒤에는 문제 정의, 기준점(baseline), 결과, 실패 기록, 다음 개선 계획을 실제 실행과 비교 결과로 남기는 흐름을 스스로 설명할 수 있어야 합니다.

이 파트에서 다룬 핵심 구조¶

Part 7의 전체 구조는 한 프로젝트 안에서 어떤 판단 요소가 함께 남아야 하는가를 기준으로 정리됩니다. 따라서 각 절은 같은 프로젝트 기록을 다른 판단 축에서 다시 점검하는 위치로 읽어야 합니다.

이 흐름을 실행과 검토 기준으로 다시 묶으면 다음처럼 정리할 수 있습니다.

이 표를 다시 가장 작게 줄이면, 각 축에서 먼저 빠지면 안 되는 기록은 다음과 같습니다.

프로젝트마다 주제가 다르더라도, 공통적으로 남아야 하는 질문은 같습니다.

1. 무엇을 풀려는가?
2. 입력과 출력은 무엇인가?
3. 데이터는 어떻게 준비했는가?
4. 기준점은 무엇인가?
5. 결과는 어떻게 확인했는가?
6. 실패와 한계는 무엇이었는가?
7. 다음 개선은 어디에서 시작해야 하는가?

반드시 기억할 개념¶

Part 7에서 꼭 가져가야 할 관점은 다음과 같습니다.

이 관점을 한 단계 더 실무적으로 바꾸면, 결과 숫자보다 무슨 입력을 넣었고 어떤 비교를 했으며 어디서 실패했는가가 더 중요할 때가 많습니다.

• 기준점(baseline) 비교 프로젝트에서는 정확도(accuracy)만이 아니라 어떤 샘플을 틀렸는가가 남아야 합니다. 즉 틀린 사례 목록 같은 기록이 있어야 다음 비교가 살아납니다.
• 텍스트 프로젝트에서는 정답/오답만이 아니라 토큰 목록, 기존 어휘 포함 비율, 사전에 없던 토큰이 남아야 합니다. 어떤 입력이 잘렸고 어떤 단어가 빠졌는지 봐야 전처리 문제를 다시 찾을 수 있기 때문입니다.
• RAG 프로젝트에서는 답변만이 아니라 검색 후보, 답변 상태, 선택한 근거 문서가 남아야 합니다. 답변이 아니라 근거 선택 과정이 품질 검토의 출발점이기 때문입니다.
• 에이전트 프로젝트에서는 성공/실패만이 아니라 권한, 승인 여부, 다음 행동이 남아야 합니다. 어떤 승인과 차단이 있었는지 알아야 실행 경로를 다시 설계할 수 있기 때문입니다.
• 배포 프로젝트에서는 배포 완료만이 아니라 실패 기록, 우선순위, 다음 조치가 남아야 합니다. 운영 기록은 완료 선언보다 다음 조치 순서가 더 중요하기 때문입니다.

이 예시 축들은 Part 7 안에서 이미 충분히 펼쳐져 있으므로, 각 절의 본문 예시가 질문 -> 실행 -> 비교 -> 해석 -> 회고 흐름을 바로 보여 주도록 유지하는 것이 더 중요합니다.

오해하기 쉬운 지점¶

이 Part에서 특히 조심할 오해는 다음과 같습니다.

• 프로젝트는 성공 사례 모음만 남기면 된다고 생각하기 쉽습니다.
• 결과 숫자 하나만 높으면 프로젝트가 잘 끝났다고 오해하기 쉽습니다.
• 예제를 한 번 실행했다고 해서 바로 실제 구조를 이해한 것은 아닙니다.
• 코드가 실행된 것과, 문제 정의가 타당한 것은 같은 말이 아닙니다.
• LLM 프로젝트에서 답변이 한두 번 잘 나온다고 평가가 끝난 것은 아닙니다.
• 운영 실패를 기록하지 않으면 다음 개선이 어려워집니다.

즉, 프로젝트는 한 번 됐다를 증명하는 문서가 아니라 다음 반복이 가능하다를 증명하는 문서여야 합니다.

프로젝트 회고가 다시 확인할 실행 경계¶

Part 7은 프로젝트 입문 구조를 설명하는 데 집중했습니다. 따라서 목표 설정, 구현, 평가, 회고, 운영 기록은 다루지만, 대규모 인프라와 장기 운영 체계 전체를 여기서 끝내지는 않습니다.

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

Part 7은 다음 과제까지 직접 끝내지는 않습니다.

• 어떤 주제를 다음 실제 프로젝트로 확장할 것인가?
• 평가와 실패 기록을 팀 단위 문서로 어떻게 키울 것인가?
• 운영과 배포를 어디까지 자동화하고 어디서 사람 검토를 둘 것인가?

즉, Part 7은 책의 종착점이라기보다 이후 자율 프로젝트의 출발점에 해당합니다.

이 질문들은 이미 Part 7 안에서 작은 형태로 예고되었습니다.

• 기준점(baseline) 비교는 더 큰 실험 추적 체계로 커질 수 있습니다.
• 기존 어휘 포함 비율과 OOV 기록은 더 정교한 토큰화기(tokenizer) 실험으로 이어질 수 있습니다.
• RAG의 근거 부족 상태 기록은 더 엄격한 평가 파이프라인으로 이어질 수 있습니다.
• agent의 운영 보류와 승인 필요 도구 기록은 실제 운영 정책 문서로 확장될 수 있습니다.
• 배포의 실패 기록은 팀 단위 장애 회고 문서의 씨앗이 됩니다.

다음 학습으로 넘어가기 전에 확인할 질문¶

• 각 프로젝트에서 문제 정의와 출력 기준을 한 문장으로 설명할 수 있는가?
• 기준점(baseline)과 개선안을 분리해 기록했는가?
• 데이터 준비와 분리 과정을 다시 실행할 수 있는가?
• 결과를 수치, 비교표, 사례로 함께 읽었는가?
• 실패 사례와 개선 계획을 남겼는가?
• LLM 프로젝트라면 검색, 도구 호출, 권한, 로그, 실패 대응을 함께 점검했는가?

프로젝트 문서를 실제로 다시 펼쳐 볼 때는 아래 산출물 체크도 함께 확인해야 합니다.

• 실행 요약이나 검토 요약이 있는가?
• 샘플별 비교표, 테스트 기록, 평가 기록처럼 샘플별 기록이 남아 있는가?
• 선택 근거, 검색 후보처럼 근거 기록이 남아 있는가?
• 실행 기록과 실패 기록처럼 운영 흐름이 남아 있는가?

이 점검을 더 짧게 다시 읽으면 다음과 같습니다.

프로젝트 문서에 남는 최소 절차¶

Part 7에서 반복해 본 실습은 다음 실제 프로젝트에서도 거의 같은 최소 절차로 다시 나타납니다.

1. 질문을 한 문장으로 적습니다.
2. 입력 파일이나 입력 단위를 먼저 고정합니다.
3. 기준점(baseline)을 먼저 실행합니다.
4. 개선안이나 후속 구조를 같은 입력 위에서 비교합니다.
5. 실행 요약, 비교표, 오류 사례, 실패 기록 중 무엇이 남았는지 확인합니다.
6. 사실 -> 해석 -> 다음 질문 또는 실패 범주 -> 다음 조치 형태로 회고를 남깁니다.

이 여섯 줄만 지켜도 Part 7의 핵심은 대부분 다시 살아납니다.

같은 절차를 Part 7의 대표 위치와 연결하면 다음처럼 볼 수 있습니다.

대표 Section을 다시 열 때는 설명만 다시 읽지 말고 같은 역할의 실습 지점까지 같이 확인합니다. 예를 들어 비교 실험이 막히면 P7-2.3, 입력 표현 선택이 막히면 P7-3.3, 표현 정보 손실이 막히면 P7-4.4, RAG 검색 품질 점검이 막히면 P7-5.5, 운영 등급 판단이 막히면 P7-7.4, 실행 인수인계가 막히면 P7-7.5에서 값을 바꿔 본 뒤 회고 문장을 다시 적는 방식으로 복귀할 수 있습니다.

즉, 현재 막힌 단계는 같은 역할을 맡는 대표 Section과 바로 대조할 수 있습니다. 실습 절까지 포함하면 설명만 다시 읽는 것이 아니라 값을 바꾸고 결과를 다시 적는 수준으로 복귀할 수 있습니다.

Part 7을 마치며¶

프로젝트 파트의 목적은 거대한 결과물을 만드는 데 있지 않습니다. 오히려 실제 실행과 비교를 통해 내가 무엇을 이해했고, 무엇이 아직 불안정한지를 드러내는 데 있습니다.

이 Part를 마치면 독자는 다음 단계를 스스로 설계할 수 있어야 합니다.

• 더 큰 데이터셋으로 확장하기
• 더 적절한 평가 지표를 붙이기
• RAG 품질을 비교 실험하기
• 에이전트 권한과 로그 정책을 더 정교하게 다듬기
• 운영 비용과 실패 대응을 별도 문서로 분리하기

즉, Part 7은 끝이라기보다 이제부터는 스스로 프로젝트를 만들어 다시 배우는 단계로 넘어가는 출발점입니다.

가장 짧게 정리하면 Part 7의 결론은 다음 한 문장으로 묶을 수 있습니다.

좋은 프로젝트 문서는 한 번 돌아간 코드보다 먼저, 왜 그런 결과가 나왔는지 다시 읽을 수 있는 비교와 기록을 남긴다.

이 요약에 남는 재점검 기준¶

프로젝트를 하나 끝냈는데 무엇을 남겨야 했는지 흔들릴 때는 아래 기준이 실제 기록으로 남았는지 다시 보면 됩니다.

• 구현은 했지만 질문, 기준점(baseline), 실패 기록이 함께 남았는지 확신이 서지 않는 경우
• RAG, 에이전트, 배포 프로젝트에서 무엇이 공통 기록 요소였는지 다시 묶어 보고 싶은 경우
• 다음 실제 프로젝트로 넘어가기 전에 어떤 회고 문장을 남겨야 하는지 정리하고 싶은 경우

이때는 세부 절로 다시 흩어지기 전에 무엇을 풀었는가, 무엇을 기록했는가, 다음에 무엇을 바꿀 것인가를 먼저 다시 확인하면 됩니다.

이 요약에서 가장 먼저 확인해야 할 기준을 세 줄로 줄이면 다음과 같습니다.

• 지금 내 프로젝트에는 질문 한 문장과 입력 단위가 남아 있는가?
• 기준점(baseline)과 비교 결과가 같은 입력 위에서 남아 있는가?
• 오류 사례나 실패 기록이 다음 조치와 함께 남아 있는가?

체크리스트¶

• 각 프로젝트 축에서 먼저 남겨야 하는 기록을 한 줄씩 다시 적을 수 있는가?
• 기준점(baseline), 비교표, 실패 기록이 왜 Part 7 전체의 공통 기준인지 설명할 수 있는가?
• RAG/에이전트/배포에서 운영 관점 기록이 왜 필요한지 다시 말할 수 있는가?
• 다음 실제 프로젝트에서 바로 가져갈 회고 형식을 정리할 수 있는가?

출처와 참고 자료¶

이 문서는 Part 7 전체 내용을 요약한 자체 정리입니다. 외부 자료를 직접 인용하지 않았습니다.