AI 직무를 준비하는 취업 준비생의 포트폴리오를 여러 개 이어서 살펴보면 비슷한 장면이 반복되는 경우가 많습니다. PDF 문서를 넣어 질문에 답하는 RAG 챗봇, 사용자의 요청에 맞춰 여행 일정을 만들어주는 생성형 AI 서비스, 뉴스나 논문을 요약하는 LLM 프로젝트, 여러 도구를 호출하는 AI 에이전트까지 기술 주제는 조금씩 달라도 프로젝트 소개 화면만 보면 비슷하게 느껴질 수 있습니다. 처음에는 사용한 모델과 프레임워크가 최신이어서 잘 준비된 프로젝트처럼 보입니다. 그런데 왜 이 문제에 AI가 필요했는지, 기존 방식에서는 무엇이 불편했는지, 결과가 좋아졌다고 판단한 기준이 무엇인지, 실패했던 질문을 어떻게 분류하고 수정했는지를 확인하면 설명이 짧아지는 경우가 있습니다. 결과적으로 LangChain을 사용했다, 벡터 DB를 연결했다, 에이전트를 구현했다는 기술 목록은 남지만 프로젝트를 만든 사람의 판단은 잘 보이지 않습니다. 반대로 주제 자체는 흔한 문서 검색 AI여도 프로젝트의 인상이 확실히 다른 경우가 있습니다. 사용자가 어떤 상황에서 검색에 실패하는지 먼저 조사하고, 기존 키워드 검색의 문제를 정리한 뒤 RAG를 적용했으며, 질문 유형별 테스트 셋을 만들고 검색 정확도와 답변 근거성을 비교한 프로젝트입니다. 이후 실패 사례를 검색 문제와 생성 문제로 나누고 chunking이나 검색 방식을 변경한 뒤 같은 질문으로 다시 검증했다면 프로젝트의 설명 깊이는 크게 달라집니다. 최근 생성형 AI 개발 도구에서도 이런 평가 중심 접근은 점점 중요하게 다뤄지고 있습니다. Google Cloud의 Gen AI Evaluation은 모델이나 애플리케이션을 특정 사용 사례에 맞는 자체 평가 기준으로 비교할 수 있도록 지원하며, 모델 선택과 프롬프트 변경, RAG 구조 개선 등 개발 과정 전반에서 평가를 활용하는 방향을 제시합니다. 따라서 AI 프로젝트를 비슷해 보이지 않게 만드는 방법은 남들이 사용하지 않은 모델을 찾는 것만으로 해결되지 않습니다. 같은 LLM과 같은 프레임워크를 사용해도 어떤 문제를 선택했고, 무엇을 성공으로 정의했으며, 실패를 어떤 기준으로 분석해 다시 개선했는지가 다르면 프로젝트의 성격도 달라집니다. AI 포트폴리오의 차별점은 기술 이름보다 문제정의 → 평가 → 실패 분석 → 개선 → 재평가라는 판단 과정이 얼마나 구체적으로 남아 있는가에서 만들어집니다.
이번 글에서는 AI 프로젝트가 비슷해 보이지 않게 만드는 방법을 문제정의, 평가, 개선 세 가지 기준으로 나누어 정리하겠습니다.
문제정의는 AI 기능을 만들기 전에 무엇을 해결하려는 프로젝트인지 구체화하는 단계입니다
- 좋은 AI 프로젝트는 모델보다 먼저 누구의 어떤 문제가 불편한지를 보여줄 수 있어야 합니다
AI 프로젝트를 시작할 때 RAG를 공부하기 위해, 에이전트를 만들어보기 위해, 생성형 AI를 사용하기 위해라는 기술 목표부터 정하는 경우가 있습니다. 학습 목적으로는 의미가 있지만 취업 포트폴리오에서는 기술을 사용한 이유보다 해결하려는 문제가 먼저 보여야 프로젝트의 방향이 선명해집니다.
문제정의 단계에서는 다음 내용을 연결해서 볼 수 있습니다.
- 실제 사용자가 누구인지 구분합니다.
- 사용자가 기존에 어떤 방식으로 문제를 해결했는지 정리합니다.
- 기존 방식에서 시간이 오래 걸리거나 오류가 발생하는 지점을 찾습니다.
- AI가 개입해야 할 업무와 기존 방식이 더 적합한 업무를 나눕니다.
- 프로젝트가 해결하려는 범위를 지나치게 넓히지 않습니다.
- 최종적으로 달라져야 할 사용자 경험이나 업무 결과를 정의합니다.
예를 들어 회사 문서를 검색하는 RAG 챗봇이라는 프로젝트보다 신입 직원이 200페이지가 넘는 사내 규정에서 휴가·출장·경비 규정을 찾는 시간을 줄이는 문서 질의 서비스라고 정의하면 테스트해야 할 질문도 달라집니다. 휴가 일수와 신청 절차, 출장비 기준처럼 실제 업무 질문을 만들 수 있고 어떤 문서를 정확하게 찾아야 하는지도 정할 수 있습니다. 이런 구조가 있으면 프로젝트의 중심이 RAG 기술에서 실제 사용자의 정보 탐색 문제로 이동합니다.
- 기술 중심 프로젝트와 문제 중심 프로젝트는 같은 기능을 만들어도 설명 방식이 달라집니다
AI 포트폴리오가 비슷해 보이는 가장 큰 이유 중 하나는 결과 화면을 중심으로 소개하기 때문입니다. 챗봇 화면과 프롬프트, 사용 모델을 보여주는 방식만 반복되면 프로젝트의 차이가 기술 스택 정도로만 보일 수 있습니다.
- 기술 중심 설명: LLM과 벡터 DB를 이용해 문서 질의응답 챗봇을 구현했습니다.
- 문제 중심 설명: 규정 문서에서 원하는 내용을 찾기 어려운 사용자의 검색 문제를 줄이기 위해 질의응답 구조를 설계했습니다.
- 기능 중심 설명: 파일 업로드와 질문, 답변 생성 기능을 구현했습니다.
- 업무 중심 설명: 여러 규정 문서 가운데 질문과 관련된 근거를 찾고 출처까지 함께 확인할 수 있도록 구성했습니다.
- 성과 중심 설명: 답변이 생성되는 데 성공했습니다.
- 검증 중심 설명: 자주 발생하는 질문을 테스트 셋으로 만들고 검색 실패와 생성 오류를 각각 측정했습니다.
같은 RAG를 만들었더라도 두 번째 방식에서는 왜 필요한 시스템인지와 어떤 결과를 검증해야 하는지가 자연스럽게 이어집니다. 포트폴리오에서는 기술을 사용했다는 사실보다 기술을 선택하게 된 문제의 구조가 먼저 보여주는 편이 차별화에 도움이 됩니다.
- 문제 범위를 좁히면 평가와 개선도 구체적으로 만들 수 있습니다
AI 프로젝트의 주제가 너무 넓으면 기능은 많아지지만 각 기능의 완성도를 판단하기 어려워질 수 있습니다. 모든 질문에 답하는 AI 비서보다 한정된 업무나 사용자 상황을 대상으로 설계하면 무엇을 테스트해야 하는지도 훨씬 명확해집니다.
프로젝트 범위를 잡을 때는 다음 내용을 확인할 수 있습니다.
- 사용자의 핵심 질문 유형을 몇 가지로 분류합니다.
- 반드시 정확해야 하는 업무를 별도로 구분합니다.
- 프로젝트가 답하지 않아도 되는 범위를 정의합니다.
- 입력 데이터의 출처와 범위를 제한합니다.
- 성공 사례뿐 아니라 실패하기 쉬운 상황도 예상합니다.
- 프로젝트 초기 버전에서 해결할 범위를 우선순위로 나눕니다.
예를 들어 대학 입시 정보를 모두 답하는 AI보다 특정 대학의 최신 모집요강에서 전형별 지원 자격과 면접 여부를 찾아주는 서비스처럼 범위를 좁히면 데이터와 평가 기준도 구체적으로 만들 수 있습니다. 잘못된 연도 자료를 사용하는 문제와 모집요강에 없는 정보를 생성하는 문제처럼 실제 실패 유형도 정의할 수 있습니다. 결국 문제정의를 좁히는 것은 프로젝트 규모를 작게 만드는 일이 아니라 무엇을 잘해야 하는 시스템인지 선명하게 만드는 과정입니다.
- AI를 사용하는 이유와 사용하지 않는 영역까지 설명하면 설계 판단이 더 잘 드러납니다
AI를 활용하는 프로젝트라고 해서 모든 기능을 LLM으로 처리해야 하는 것은 아닙니다. 정확한 계산이나 확정적인 값 조회처럼 기존 코드와 데이터베이스 쿼리가 더 적합한 영역도 있을 수 있습니다.
- 자연어 해석이 필요한 영역: 사용자의 다양한 표현을 이해하고 질문 의도를 분류하는 데 AI를 활용할 수 있습니다.
- 문서 요약이 필요한 영역: 여러 문장에서 핵심 내용을 압축하고 설명하는 데 생성 모델을 사용할 수 있습니다.
- 정확한 수치 계산 영역: 계산식과 프로그램 로직을 이용해 결과를 결정하는 편이 안정적일 수 있습니다.
- 정형 데이터 조회 영역: SQL이나 API를 이용해 필요한 값을 직접 조회하고 AI는 결과 설명에 활용할 수 있습니다.
- 중요한 실행 영역: AI가 판단하더라도 최종 실행 전에는 규칙이나 사람의 승인 단계를 둘 수 있습니다.
이렇게 역할을 구분하면 AI를 많이 사용한 프로젝트보다 AI가 필요한 부분을 판단해 적용한 프로젝트에 가까워집니다. 문제정의 단계에서부터 AI가 해야 할 일과 기존 시스템이 담당할 일을 구분한 이유가 남아 있다면 면접에서도 기술 선택의 근거를 설명하기 쉽습니다.
평가는 결과가 좋아 보이는지를 넘어서 프로젝트의 성공과 실패를 객관적으로 설명하는 기준입니다
- AI 프로젝트에서는 기능 구현보다 먼저 무엇을 성공으로 볼지 정할 필요가 있습니다
생성형 AI 프로젝트는 결과 문장이 자연스럽기 때문에 몇 개의 예시만 보고 잘 작동한다고 판단하기 쉽습니다. 하지만 실제 사용에서는 질문 표현이 달라지고 데이터가 부족한 상황도 발생하기 때문에 일부 성공 사례만으로 품질을 판단하기 어렵습니다.
평가 단계에서는 다음 내용을 연결해서 볼 수 있습니다.
- 실제 사용 상황을 반영한 테스트 질문을 만듭니다.
- 반드시 성공해야 하는 핵심 사례를 별도로 구분합니다.
- 답변이 없어야 하는 질문도 포함합니다.
- 모델 결과에서 어떤 품질을 평가할지 정합니다.
- 수정 전후 동일한 테스트 셋을 사용합니다.
- 자동 평가와 사람이 직접 확인할 항목을 나눕니다.
예를 들어 문서 기반 Q&A 프로젝트라면 답변이 자연스러운가만 평가하기보다 질문과 관련된 문서를 찾았는지, 답변이 해당 문서에 근거하는지, 필요한 내용을 빠뜨리지 않았는지를 각각 볼 수 있습니다. Microsoft Foundry도 생성형 AI 평가에서 Relevance와 Groundedness, Task Completion 같은 최종 결과 평가뿐 아니라 에이전트의 Tool Selection과 Tool Call Accuracy처럼 실행 과정 자체를 별도로 평가할 수 있도록 구성하고 있습니다. 이런 평가 기준이 있으면 포트폴리오에서 잘 동작했다는 표현을 무엇이 어느 조건에서 잘 동작했는지로 바꿀 수 있습니다.
- 데모 성공과 평가 완료는 확인하는 범위에서 차이가 있습니다
AI 프로젝트를 시연할 때는 정상적으로 답하는 질문을 선택하기 쉽습니다. 포트폴리오에서는 데모 화면과 별도로 여러 유형의 입력에서 결과를 확인한 과정이 있어야 프로젝트의 신뢰도가 높아집니다.
- 데모 성공: 준비된 몇 개의 질문에서 원하는 답변이 생성됩니다.
- 기본 평가: 서로 다른 질문 유형에서도 일정한 품질이 유지되는지 확인합니다.
- 경계 사례 평가: 오타와 모호한 표현, 정보가 부족한 질문을 포함합니다.
- 실패 평가: 의도적으로 시스템이 어려워하는 질문을 테스트합니다.
- 회귀 평가: 모델이나 프롬프트를 수정한 뒤 기존에 잘되던 질문이 나빠지지 않았는지 확인합니다.
예를 들어 식당 추천 AI가 강남 맛집 추천에는 잘 답하더라도 예산과 음식 제한, 위치와 영업시간 조건이 함께 들어오면 결과가 달라질 수 있습니다. 따라서 프로젝트 소개에서는 가장 잘 나온 답변 하나보다 여러 조건에서 품질이 어떻게 달라지는지 확인한 과정이 더 중요한 자료가 될 수 있습니다.
- 평가 데이터가 있으면 모델과 프롬프트 선택에도 근거가 생깁니다
AI 프로젝트에서 모델이나 프롬프트를 변경할 때 느낌으로 결과를 비교하는 경우가 많습니다. A 모델이 더 자연스럽다는 판단만으로는 왜 최종 구성을 선택했는지 설명하기 어렵습니다.
프로젝트에서는 다음과 같은 비교를 남길 수 있습니다.
- 동일한 질문 세트로 여러 모델의 결과를 비교합니다.
- 프롬프트 변경 전후의 성능 차이를 확인합니다.
- RAG에서는 검색 설정별 결과를 비교합니다.
- 응답 품질과 함께 지연시간과 비용도 기록합니다.
- 특정 유형의 질문에서 어떤 설정이 강한지 구분합니다.
- 최종 선택에서 품질과 운영 조건의 균형을 설명합니다.
Google Cloud의 현재 생성형 AI 평가 도구도 Groundedness와 Instruction Following, 요약 품질처럼 목적에 맞는 여러 평가 지표를 적용할 수 있고, pairwise 비교를 이용해 두 모델이나 설정의 결과를 직접 비교하는 방식도 제공합니다. 따라서 최신 모델이라 선택했다보다 테스트 셋에서 품질과 속도, 비용을 비교한 뒤 현재 조건을 선택했다는 설명이 훨씬 설득력 있는 포트폴리오가 됩니다.
- 하나의 평균 점수보다 실패 유형을 나누는 평가가 개선 방향을 찾는 데 도움이 됩니다
AI 프로젝트의 성능을 하나의 정확도 숫자로 표현하면 보기에는 간단합니다. 하지만 동일한 점수라도 어떤 문제에서 실패했는지에 따라 개선 방법은 완전히 달라질 수 있습니다.
- 검색 실패: 필요한 정보가 있는데 관련 문서를 찾지 못했습니다.
- 생성 실패: 필요한 정보가 주어졌지만 모델이 잘못된 내용을 만들었습니다.
- 지시 이행 실패: 답변 내용은 맞지만 요구한 형식이나 제한을 지키지 못했습니다.
- 도구 선택 실패: 에이전트가 필요한 API 대신 다른 도구를 선택했습니다.
- 데이터 부족: 시스템 안에 질문에 답할 수 있는 정보 자체가 없습니다.
- 과도한 응답: 답할 수 없는 상황에서도 모델이 확정적인 내용을 생성했습니다.
Microsoft의 에이전트 평가 체계도 최종 결과만 확인하지 않고 Tool Selection, Tool Input Accuracy, Tool Output Utilization, Tool Call Success처럼 실행 과정의 실패를 나누어 평가합니다. 이런 분류가 포트폴리오에 포함되면 정확도를 개선했다보다 어떤 실패가 많았고 어디를 수정해야 했는지 판단한 과정을 더 구체적으로 보여줄 수 있습니다.
개선은 기능을 계속 추가하는 것이 아니라 실패 원인을 찾아 같은 기준으로 다시 검증하는 과정입니다
- 개선 과정은 처음 버전에서 어떤 문제가 발견되었는지가 먼저 보여야 합니다
AI 프로젝트 포트폴리오에서 완성된 최종 화면만 보여주면 프로젝트가 처음부터 잘 작동한 것처럼 보입니다. 하지만 실제 엔지니어링 경험은 처음 결과에서 문제를 찾고 원인을 분석해 수정한 과정에서 더 잘 드러날 수 있습니다.
개선 과정에서는 다음 내용을 연결할 수 있습니다.
- 초기 버전의 평가 결과를 기록합니다.
- 실패한 질문을 유형별로 분류합니다.
- 가장 자주 발생하거나 영향이 큰 문제를 우선합니다.
- 한 번에 여러 요소보다 원인과 관련된 부분을 수정합니다.
- 변경 이후 같은 테스트 셋으로 다시 평가합니다.
- 개선된 항목과 새롭게 악화된 항목을 함께 확인합니다.
예를 들어 RAG 프로젝트에서 답변 오류가 많다고 해서 바로 모델을 교체할 필요는 없습니다. 검색 결과를 확인했더니 필요한 문서가 아예 들어오지 않았다면 chunking이나 embedding, 검색 방식부터 검토하는 것이 더 적절할 수 있습니다. 이렇게 개선 순서를 설명하면 포트폴리오에서 문제를 발견하고 원인을 좁혀 해결한 엔지니어링 사고가 드러납니다.
- 기능 추가와 품질 개선은 프로젝트가 좋아지는 방식에서 차이가 있습니다
AI 프로젝트를 발전시킨다고 하면 음성 기능과 이미지 업로드, 에이전트와 새로운 모델을 계속 추가하기 쉽습니다. 하지만 기능이 많아져도 기존 핵심 문제의 품질이 개선되지 않았다면 포트폴리오의 깊이가 반드시 커지는 것은 아닙니다.
- 기능 추가 중심: 새로운 모델이나 화면, 외부 API를 추가해 할 수 있는 일을 넓힙니다.
- 품질 개선 중심: 기존 핵심 기능이 실패하는 상황을 줄입니다.
- 성능 개선 중심: 응답시간과 처리량, 비용을 줄이면서 품질을 유지합니다.
- 안정성 개선 중심: 오류와 타임아웃, 잘못된 도구 호출을 처리합니다.
- 운영 개선 중심: 로그와 평가 데이터를 수집해 실제 사용 이후에도 문제를 찾을 수 있게 합니다.
예를 들어 여행 AI에 이미지 생성 기능을 추가하는 것보다 기존 추천 기능이 폐업한 장소를 제시하거나 사용자의 예산 조건을 자주 무시한다면 그 문제를 먼저 개선하는 편이 프로젝트 목적과 더 직접적으로 연결될 수 있습니다. 따라서 포트폴리오에서는 버전이 올라갈수록 기능 수가 늘어났다는 설명보다 핵심 실패가 어떻게 줄었는지를 보여주는 것이 좋습니다.
- 개선 전후를 같은 조건으로 비교하면 변경 효과를 구체적으로 설명할 수 있습니다
AI 프로젝트에서는 프롬프트 한 줄을 바꾸거나 검색 조건을 조금 수정해도 결과가 크게 달라질 수 있습니다. 하지만 변경 전과 다른 질문을 사용하면 실제로 개선되었는지 판단하기 어렵습니다.
개선 기록에는 다음 내용을 포함할 수 있습니다.
- 변경 전 기준 점수를 남깁니다.
- 동일한 테스트 질문을 유지합니다.
- 수정한 변수와 수정 이유를 기록합니다.
- 개선된 질문과 여전히 실패하는 질문을 나눕니다.
- 새롭게 발생한 회귀 사례가 있는지 확인합니다.
- 품질뿐 아니라 비용과 응답시간 변화도 함께 기록합니다.
예를 들어 RAG의 chunk size를 변경한 뒤 기존 실패 질문 20개 가운데 몇 개가 개선되었는지 확인하면 변경 효과를 설명할 수 있습니다. 반대로 검색 품질은 좋아졌지만 콘텍스트가 길어져 응답시간과 비용이 크게 증가했다면 그 부분도 프로젝트의 중요한 판단 자료가 됩니다. Microsoft Foundry는 생성형 AI 애플리케이션의 개발 단계뿐 아니라 배포 전 평가와 운영 단계의 모니터링, 로그·트레이스·평가 지표를 함께 활용하는 관측 구조를 제시합니다. AI 품질을 한 번 측정하고 끝내기보다 전체 수명주기에서 반복해서 확인하는 접근입니다. 이런 방식으로 포트폴리오를 구성하면 개선이 단순한 수정 기록이 아니라 가설 → 변경 → 재평가라는 실험 과정으로 보입니다.
- 한계와 다음 개선 방향까지 설명하면 프로젝트가 더 완성도 있게 보입니다
포트폴리오에서는 프로젝트의 좋은 결과만 보여주고 싶은 마음이 생길 수 있습니다. 하지만 AI 프로젝트에서는 모든 입력에서 완벽하게 동작한다고 주장하는 것보다 현재 구조가 약한 상황을 알고 있는 편이 기술 이해를 더 잘 보여줄 수 있습니다.
- 현재 한계 확인: 어떤 질문과 데이터에서 성능이 떨어지는지 설명합니다.
- 원인 추정: 모델과 데이터, 검색, 프롬프트 가운데 어느 영역과 관련이 있는지 구분합니다.
- 현재 대응: 프로젝트 범위 안에서 적용한 완화 방법을 정리합니다.
- 남은 문제: 아직 충분히 해결하지 못한 조건을 명확하게 남깁니다.
- 다음 실험: 추가 데이터와 평가 기준, 새로운 검색 방식 등 다음 검증 방향을 정리합니다.
예를 들어 검색 정확도가 100%가 아니다는 한계보다 표현이 매우 짧은 질문에서 의미 유사도가 낮아 관련 문서가 상위 검색되지 않는 문제가 남아 있다고 설명하면 훨씬 구체적입니다. 이후 키워드와 벡터 검색을 결합하거나 query rewriting을 비교하는 것이 다음 개선 방향이 될 수 있습니다. 포트폴리오에서 이런 부분까지 남아 있으면 프로젝트가 완성된 기능을 자랑하는 자료에서 벗어나 현재 시스템을 이해하고 다음 실험까지 설계할 수 있는 사람의 작업 기록으로 보이게 됩니다.
- conclusion
AI 프로젝트가 서로 비슷해 보이는 것은 같은 LLM과 같은 프레임워크를 사용하기 때문만은 아닙니다. 많은 프로젝트가 최종 기능과 기술 스택만 보여주고 그 기술을 선택하기 전의 문제와 적용 이후의 평가, 실패를 분석하고 수정한 과정은 생략하기 때문에 비슷하게 보이는 경우가 많습니다. 문제정의에서는 프로젝트를 AI 챗봇, RAG, 에이전트처럼 기술 이름으로 시작하기보다 누가 어떤 상황에서 무엇 때문에 불편한지를 좁히는 과정이 필요합니다. 문제가 구체적이면 필요한 데이터와 기능이 달라지고 테스트해야 할 질문도 자연스럽게 만들어집니다. 평가에서는 결과가 자연스럽게 보인다는 느낌보다 성공과 실패를 구분할 기준이 필요합니다. 실제 사용 상황을 반영한 질문을 만들고 관련성과 정확성, Groundedness와 Task Completion처럼 프로젝트 목적에 맞는 기준을 적용하면 모델과 프롬프트, 검색 방식의 선택에도 근거가 생깁니다. 주요 생성형 AI 플랫폼에서도 결과뿐 아니라 검색과 도구 호출, 작업 완료 여부까지 다양한 평가 기준을 제공하는 방향으로 발전하고 있습니다. 개선에서는 새로운 기능을 계속 추가하기보다 실패한 결과를 유형별로 나누는 과정이 중요합니다. 검색 문제인지와 생성 문제인지, 데이터가 부족한 것인지와 모델이 지시를 따르지 못한 것인지를 구분하고 동일한 테스트 셋으로 수정 전후를 비교해야 어떤 변경이 실제 효과를 만들었는지 설명할 수 있습니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 프로젝트가 해결하려는 사용자와 업무 문제가 구체적인지 확인합니다.
- AI를 사용하는 이유와 기존 방식으로 처리할 영역이 구분되어 있는지 살펴봅니다.
- 기능 구현 전에 성공과 실패를 판단할 평가 기준이 있는지 확인합니다.
- 실제 사용 상황을 반영한 평가 데이터셋을 구성했는지 점검합니다.
- 실패 사례를 모델과 데이터, 검색 등 원인별로 나누었는지 살펴봅니다.
- 변경 전후를 동일한 기준으로 재평가하고 한계까지 기록했는지 확인합니다.
AI 프로젝트 차별화 흐름은 다음과 같이 연결할 수 있습니다.
- 사용자 문제 발견 → 기존 방식 분석 → AI 적용 필요성 판단 → 프로젝트 범위 축소 → 초기 버전 구현 → 테스트 질문 구성 → 성공 기준 정의 → 기준 성능 측정 → 실패 사례 수집 → 실패 유형 분류 → 원인 가설 설정 → 모델·데이터·검색·프롬프트 수정 → 동일 테스트 셋 재평가 → 회귀 확인 → 비용·속도 비교 → 남은 한계 정리 → README와 실험 기록 문서화 → 포트폴리오와 면접 연결
결국 AI 포트폴리오를 다르게 만드는 것은 흔하지 않은 프로젝트 이름이 아닙니다. 문제정의에서는 왜 이 문제를 AI로 해결하려 했는지 보여주고, 평가에서는 무엇을 좋은 결과로 판단했는지 증명하며, 개선에서는 어떤 실패를 발견하고 어떤 근거로 수정했는지를 남길 수 있어야 합니다. 이 세 과정이 하나의 프로젝트 안에서 이어져 있다면 흔한 챗봇이나 RAG, 에이전트 주제라도 사용한 기술보다 판단과 실험, 문제 해결 과정이 먼저 보이는 포트폴리오로 만들 수 있습니다.