부록 G. 내가 만든 것을 AI 포트폴리오로 바꿉니다 — 상세 안내

AI를 쓸 줄 안다는 말은 증거가 되지 않습니다

사용한 도구 이름만 나열하기보다, 실제 결과물과 그 결과를 만들며 내린 판단을 보여줍니다.

이 부록의 기본 과제는 새로 만드는 것이 아닙니다. 이미 가진 프로젝트 하나를 골라 다음 네 질문에 답하도록 정리합니다.

1. 어떤 문제를 해결하려 했나
2. AI와 어떻게 만들었나
3. 나는 무엇을 판단했나
4. 결과를 어떻게 확인하고 개선했나

1단계. 대표 프로젝트 하나를 고릅니다

처음부터 여섯 개를 모두 앞세우지 않습니다. 내가 설명할 수 있고, 내 업무나 지원하려는 분야와 연결하기 좋은 프로젝트 하나를 고릅니다.

대표를 고를 때는 다음 세 가지를 확인합니다.

• 어떤 문제를 해결하려 했는지 내 말로 설명할 수 있는가
• 결과물과 사용한 자료·검증 기록이 남아 있는가
• 내가 정한 조건과 아직 확인하지 못한 범위를 설명할 수 있는가

다른 결과물은 대표 저장소 맨 아래 「같은 방법으로 만든 것」에 이름·해결한 질문·주소를 한 줄씩 적습니다. 실제로 완성하고 보여줄 수 있는 것만 연결합니다.

내 소재로 다시 만드는 일은 선택입니다. 아직 해보지 않았다면 「내 분야에서 실제로 해결했다」가 아니라 **「이런 문제에도 같은 방법을 적용해볼 수 있다」**고 씁니다. 재제작을 시작할 때는 아래의 꺾쇠 자리에 내 소재와 참고할 장 번호를 넣습니다.

내 분야의 문제로 다시 만들고 싶어. 〈여기에 내가 다루려는 것을 적는다〉
〈N〉장에서 만든 것과 같은 방법으로 만들어줘.
무엇이면 제대로 된 결과인지 완료 조건을 먼저 정하고, 그것을 확인하는 Test까지 같이 만들어줘.

2단계. README에 네 가지를 채웁니다

저장소를 처음 보는 사람이 README만 읽어도 무엇을 만들었는지 알 수 있게 합니다. 프로젝트 이름·한 줄 소개·결과 화면·열어보는 주소를 먼저 두고, 준비·실행 방법은 그 아래에 둡니다.

전체 복사용 골격은 Development Lab의 자료실 → 부록 G에서 연결한 templates/project-readme.md를 사용합니다. 골격을 바로 열 수 없으면 아래 요청문만 사용해도 같은 네 절을 만들 수 있습니다.

https://www.studyailab.com/develop/resources/appendix-g

골격은 내 저장소의 README.md에 적용합니다. 기존 README에 필요한 설명이 있다면 먼저 보존하고, 아래 요청으로 실제 파일과 실행 명령을 채웁니다. 골격 없이 시작할 때도 같은 요청을 사용할 수 있습니다.

README를 첫 화면 기준으로 다시 정리해줘.
맨 위에 한 줄 소개와 결과 화면, 열어보는 주소를 두고 준비와 실행은 그 아래로 내려줘.
그 아래에 「어떤 문제를 해결하려 했나」, 「AI와 어떻게 만들었나」, 「내가 판단한 것」,
「어떻게 확인하고 개선했나」 네 절을 이 순서로 만들어줘.
지금 저장소에 실제로 있는 것만 적고, 없는 것은 〈 〉로 비워둬.
설치·실행·Test 명령과 인증값 파일 이름은 이 저장소에서 직접 확인해 채워줘.

채우면 첫 화면이 이렇게 보입니다.

8장 결과물을 이 골격으로 정리한 완성 예시는 다음 저장소에서 확인할 수 있습니다.

https://github.com/buildyourownai-lab/apartment-explorer-portfolio

열어보는 주소가 없으면 빈 링크를 만들지 않습니다. 결과 파일 주소나 영상 주소를 쓰고, 그것도 없으면 결과 화면 한 장만 둡니다.

AI와 어떻게 만들었나

요청문을 전부 옮기지 않습니다. 처음 시킨 것, 결과가 달랐을 때 원인을 찾게 시킨 것, 완료 조건을 검사로 만들게 시킨 것 세 개를 docs/prompts.md에 둡니다. 온라인 templates/prompts.md를 가져다 쓰면 됩니다.

당시 요청문을 찾지 못해 기억으로 다시 적었다면 **「나중에 재구성한 요약」**이라고 표시합니다. 원래 요청과 사후 설명을 섞지 않습니다.

내가 판단한 것

AI가 구현한 부분과 내가 판단한 부분을 구분합니다. 내가 정하지 않은 조건을 내 판단처럼 쓰거나, 확인하지 않은 검사를 수행했다고 적지 않습니다.

이 프로젝트에서 내가 판단한 것을 README의 「내가 판단한 것」 절에 정리해줘.
무엇을 만들기로 했는지, 무엇이면 완료로 볼지, 무엇을 하지 않게 막았는지,
어디에서 사람이 확인하고 넘어가게 했는지를 각각 한 줄로 적어줘.
기록에 없는 것은 지어내지 말고 비워둬.

Test 파일이나 Commit을 가리킬 때는 GitHub에서 그 파일·Commit을 열고 주소를 복사해 [설명](주소) 형태로 연결합니다.

3단계. 검증 기록을 만들고 공개 전 검사합니다

「확인했습니다」에서 끝내지 않고, 실제로 무엇을 실행했고 어떤 결과가 나왔는지 적습니다. 온라인 templates/verification.md를 docs/verification.md로 가져가 다음 다섯 가지를 채웁니다.

• 완료 조건
• 실제로 실행한 검사와 명령
• 통과·실패 결과
• 처음 결과에서 고친 것
• 데이터 기준일과 확인한 날짜

docs/verification.md를 만들어줘.
검사를 지금 한 번 돌리고, 완료 조건과 그것을 확인하는 검사, 방금 나온 결과,
데이터 기준일과 돌린 날짜를 표로 적어줘.
만드는 동안 실패했다가 고친 것이 있으면 무엇을 고쳤는지도 한 줄씩 적어줘.
결과에는 실제로 돌려서 나온 값만 적어줘. 실행하지 못한 검사는
별도의 「확인하지 못한 범위」에 이름과 이유를 적어줘.

실행하지 못한 검사는 성공 기록에 넣지 않습니다. 별도의 「확인하지 못한 범위」에 이름과 이유를 적으면 어디까지 검증했는지 구분할 수 있습니다.

이제 자료를 공개할 준비가 됐는지 확인합니다. 준비 상태를 검사하라는 요청은 저장소를 실제로 공개하라는 승인이 아닙니다.

이 저장소를 공개해도 되는 상태인지 확인해줘.
API Key나 환경변수 파일, 개인정보, 사용 조건이 불확실한 자료가 들어 있으면 먼저 알려줘.
지금 파일만 보지 말고 지난 Commit에 들어간 적이 있는지도 확인해줘.

Key가 Commit에 들어갔다면 현재 파일에서 지우는 것으로 끝나지 않습니다. 공개하지 않은 상태에서 부록 D에 따라 키의 노출 여부를 판단하고 정리합니다. 이미 노출됐다면 기록 정리보다 키 폐기·비활성화를 먼저 진행합니다.

4단계. 공개하고 대표 결과물로 보이게 합니다

기본은 비공개입니다. 검사 결과를 보고 해당 저장소를 공개하기로 결정했을 때만 공개 범위를 바꿉니다. 대상을 분명히 지정해 공개하라고 한 지시는 그 자체가 공개 승인입니다. 같은 승인을 거듭 요구할 필요는 없지만, 다른 저장소나 영상까지 공개하라는 뜻으로 넓히지는 않습니다.

직접 바꿀 때는 GitHub 저장소의 Settings → Danger Zone에서 Change repository visibility를 찾습니다. 저장소 이름과 공개 범위를 확인하고 진행합니다. 삭제 항목과 혼동하지 않도록 메뉴의 위치보다 이름을 확인합니다.

저장소 공개와 웹서비스·영상 공개는 별개입니다. 각각의 공개 상태와 접속 가능 여부를 확인합니다. 공개한 파일은 다른 사람이 복사할 수 있으므로, 나중에 비공개로 돌리는 것만으로 이미 전달된 사본까지 회수할 수는 없습니다.

저장소를 열기 전에도 대표 결과물이 보이게 하려면 세 자리만 정리합니다.

프로필 README와 Social preview까지 꾸미는 선택 절차는 온라인 부록 G의 guides/github-profile.md에 있습니다. Markdown 표기가 낯설면 같은 폴더의 guides/markdown.md에서 필요한 여덟 형식만 확인합니다.

보여주는 순서도 정해둡니다

처음 보여줄 때는 다음 순서를 기본으로 삼습니다. 상대가 궁금해하는 내용부터 설명하되, 실제 결과와 내 판단을 기록으로 이어 보여줍니다.

1. 실제로 열리는 결과물 주소
2. README의 「내가 판단한 것」
3. 더 묻는다면 docs/verification.md와 Test·Commit

[!원칙] AI를 할 줄 안다고 말하지 말고, 만든 것을 보여주세요.

내가 확인한 근거만 나의 기록으로 남깁니다

튜터 진도는 편의를 위한 요약입니다. 다른 사람에게 보여줄 때는 실제 결과물·검사·변경 기록으로 돌아갈 수 있어야 합니다. 교재의 장별 명세와 저자의 검증 화면이 내 경험을 증명하지는 않습니다. 직접 만든 부분, 힌트로 해결한 부분, 완성본으로 재개한 부분, 실행하지 못한 환경을 구분해 적습니다.

“정답을 알려줘”는 설명 요청이고, “이 방법으로 고쳐줘”는 수정 요청입니다. README에는 AI가 작성한 코드의 양보다 사람이 선택한 목표·완료 기준·권한 경계·검증 방법을 보여줍니다. 공개 전에는 현재 파일과 과거 커밋의 비밀값·개인 자료를 확인하고, 검사 요청을 공개 승인으로 오해하지 않습니다.

AI 대화와 자동답글도 확인한 범위로 설명합니다

주식 챗봇은 어떤 기존 조회 기능을 사용하고 어떤 근거를 보여주는지 설명합니다. 자동답글은 대상·시작 시각·처리 조건·중복 방지와 중단 시험을 보여줍니다. 로컬에서 한 기능, 실제 계정에서 확인한 기능, 아직 공개하지 않은 기능을 구분하고 확인하지 않은 운영 범위를 넓혀 쓰지 않습니다.