P1-16.3 프로젝트(project)로 검증하는 방법¶
Section ID:
P1-16.3Version:v2026.07.20
P1-16.2에서는 업무 자동화와 검색을 업무 흐름 관점에서 봤습니다. 이제 학습과 실무 적용을 작은 프로젝트(project)로 검증하는 방법을 정리합니다.
AI를 이해했다는 느낌은 빠르게 생깁니다. 그러나 실제로 이해했는지는 작은 산출물을 만들어 봐야 드러납니다.
이 절에서는 프로젝트(project), 성공 기준(success criteria), 평가(evaluation), 기록(record), 실패 유형(failure type)을 중심으로 앞선 학습 문서화와 업무 자동화 흐름을 작은 검증 가능한 프로젝트로 바꾸는 방식을 정리합니다. 알고리즘 구현과 대규모 서비스 개발은 후속 Part에서 다룹니다.
여기서는 Part 1을 마친 뒤 어떤 방식으로 작은 프로젝트를 설계하고 검증할지 다룹니다. 특정 알고리즘 구현이나 대규모 서비스 개발은 후속 Part에서 다룹니다.
| 주제 | 이 절에서 볼 질문 |
|---|---|
| 프로젝트 범위(scope) | 너무 큰 목표를 어떻게 줄일 것인가? |
| 성공 기준(success criteria) | 무엇이 되면 성공이라고 볼 것인가? |
| 평가(evaluation) | 결과가 맞는지 어떻게 확인할 것인가? |
| 기록(record) | 실패와 수정 과정을 어떻게 남길 것인가? |
프로젝트로 이해를 검증하는 기준¶
- 작은 프로젝트(project)를 질문 하나에서 시작해야 하는 이유를 설명할 수 있습니다.
- 성공 기준(success criteria)과 평가(evaluation) 기준을 먼저 적는 습관을 설명할 수 있습니다.
- 실패 기록이 학습 자료가 된다는 점을 프로젝트 회고 관점에서 말할 수 있습니다.
세 가지 기준¶
여기서는 “프로젝트를 해 보자”를 막연한 말로 두지 않고, 학습 검증 단위로 줄입니다. 본문을 읽을 때 기준이 되는 세 가지 관점은 다음과 같습니다.
| 기준 | 왜 중요한가 | 이 절에서 필요한 이해 수준 |
|---|---|---|
| 작은 프로젝트는 기술 이름보다 질문 하나에서 시작해야 한다는 점 | 시작 범위를 과하게 키우는 실수를 줄여 줍니다. | “RAG를 만들자”보다 “내 문서 모음에서 관련 절을 찾을 수 있는가?”처럼 묻는다고 이해합니다. |
| 성공 기준(success criteria)을 먼저 적어야 한다는 점 | 결과 평가가 감각에만 머무르지 않게 해 줍니다. | 몇 개 질문에서 맞아야 하는지, 무엇을 실패로 볼지 먼저 정한다고 이해합니다. |
| 실패 기록이 학습 자료가 된다는 점 | 프로젝트를 단순 성공/실패로만 보지 않게 해 줍니다. | 검색 실패, 출처 누락, 과도한 생성 같은 유형을 남긴다고 이해합니다. |
작은 프로젝트는 질문 하나에서 시작한다¶
좋은 입문 프로젝트는 기술 이름에서 시작하지 않습니다. 질문 하나에서 시작합니다.
나쁜 시작: RAG를 만들자.
더 나은 시작: 내가 쓴 학습 문서 모음에서 관련 Section을 찾아 답하게 만들 수 있는가?
질문이 구체적이면 필요한 기술도 자연스럽게 좁아집니다.
| 질문 | 필요한 구성 |
|---|---|
| 내 문서에서 관련 절을 찾을 수 있는가? | 임베딩, 벡터 검색 |
| 검색된 문서를 근거로 답할 수 있는가? | RAG, 출처 표시 |
| 답변 오류를 줄일 수 있는가? | 평가 질문, 원문 확인 |
| 반복 작성 절차를 줄일 수 있는가? | 템플릿, 자동화 스크립트 |
성공 기준을 먼저 적는다¶
프로젝트가 실패하는 흔한 이유는 성공 기준(success criteria)이 없기 때문입니다.
목표: 문서 기반 질문 답변을 만든다.
부족한 목표: 잘 답하면 된다.
더 나은 목표: 질문 20개 중 16개 이상에서 관련 Section 링크를 포함한다. 출처 없는 단정 문장을 만들지 않는다. 없는 내용을 물으면 모른다고 답한다.
AI 프로젝트의 성공 기준에는 정확도만 넣지 않습니다. 근거 표시, 보안, 비용, 지연 시간, 사용자의 검토 가능성도 포함해야 합니다.
실패 기록이 학습 자료가 된다¶
AI 프로젝트에서는 실패가 자주 발생합니다. 중요한 것은 실패를 지우는 것이 아니라 유형화하는 것입니다.
| 실패 유형 | 기록할 내용 |
|---|---|
| 검색 실패 | 관련 문서를 못 찾은 이유 |
| 환각(hallucination) | 없는 내용을 만든 위치 |
| 근거 누락 | 출처 없이 단정한 문장 |
| 권한 문제 | 접근하면 안 되는 자료가 섞인 상황 |
| 비용 문제 | 호출 수, 토큰, 지연 시간 |
실패 기록은 다음 프로젝트의 요구사항(requirement)이 됩니다.
실패를 기록한다. 반복되는 실패를 분류한다. 검증 기준을 바꾼다. 작은 수정 후 다시 테스트한다.
체크리스트¶
- AI 프로젝트를 기술 이름이 아니라 중심 질문으로 시작해야 함을 설명할 수 있다.
- 성공 기준(success criteria)을 먼저 적어야 함을 설명할 수 있다.
- 평가(evaluation)에 근거 표시, 비용, 지연 시간, 보안 조건을 포함할 수 있다.
- 실패 기록이 다음 요구사항(requirement)이 된다는 점을 설명할 수 있다.
중심 질문,성공 기준,평가 방식,실패 기록을 나누어 AI 프로젝트를 검증 가능한 학습 단위로 설명할 수 있다.
출처와 참고 자료¶
- NIST, AI Risk Management Framework, 확인 날짜: 2026-07-19.
- OWASP, 2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps, OWASP GenAI Security Project, 확인 날짜: 2026-07-19.
- U.S. Department of Education, Artificial Intelligence and the Future of Teaching and Learning, 2023, 확인 날짜: 2026-07-19.