드디어 작품 완성! 테스트하고 공유까지 가보자 (6-5)

음… 드디어 “진짜 내 프로그램” 단계로 왔어.
지난 6-4에서 오류를 잡고 좀 다듬었다면, 이제 6-5에서는 완성된 프로그램을 테스트하고 결과를 공유하는 흐름으로 마무리하면 딱 좋아.

---

먼저 한 번: “완성”의 기준 정하기

사실 솔직히 말하면, 개발에서 완성은 늘 100점이 아니라 “쓸 만하게 됐네?” 에서 시작하더라.
나도 예전에 뭔가 열심히 만들고 뿌듯했는데, 정작 사용자 입력 하나에 바로 터져서… 웃기게 망가졌던 적이 있어. 😅

그래서 나는 보통 이렇게 체크해:

• 메뉴/기능이 의도대로 동작하는가?
• 입력을 잘못 넣어도(예: 숫자 말고 문자) 적절히 안내하는가?
• “종료” 같은 핵심 동작이 확실히 되는가?
• 기본적인 사용 시나리오를 다 돌려봤는가?

이 정도만 잡아도 “작품 제출 가능한” 느낌이 확 살아.

---

테스트는 “그냥 한 번”이 아니라, 시나리오로!

테스트는 거창할 필요 없고, 내가 실제로 써볼 상황을 상상해서 돌리면 돼.
나름 이게 제일 빠르고 확실하더라.

내가 주로 하는 테스트 시나리오

• 정상 입력 테스트
  • 예: 메뉴에서 1, 2, 3을 차례대로 선택하는 경우
• 경계값(좀 까다로운 입력) 테스트
  • 예: 길이가 긴 입력, 0, 음수, 빈 값 같은 케이스
• 잘못된 입력 테스트
  • 예: 숫자를 기대하는데 “abc” 넣기
• 반복 사용 테스트
  • 예: 기능을 여러 번 돌려도 이상하게 누적되진 않는지
• 종료 테스트
  • 종료 선택하면 프로그램이 깔끔하게 끝나는지

여기서 “어?” 하고 막히는 지점이 보통 다음 리팩토링 거리로 이어져서, 성장하기 딱 좋아.

---

테스트할 때 내가 저장하는 것들 (생각보다 중요)

솔직히 말하면, 테스트하다가 “아! 이건 되네!” 하고 넘기면 나중에 다시 찾기 힘들어.
그래서 나는 간단히 이런 것만 기록해:

• 입력: (예: 메뉴 3, 이름=“철수”, 나이=10)
• 결과: (예: 올바른 출력 / 에러 메시지)
• 문제점: (예: 특정 조건에서만 출력이 이상함)
• 수정 여부: (해결됨 / 다음에 수정)

별거 아닌데도, 이 기록이 있으면 다음에 고칠 때 속도가 확 빨라져.

---

자, 이제 확인! 에러 메시지는 “독자 친화적”인가?

6-4에서 오류 수정하면서 어느 정도 잡았겠지만, 마지막으로 한 번 더 눈여겨보면 좋아.

내가 체크하는 포인트는:

• 에러가 나면 사용자가 뭘 잘못했는지 알 수 있나?
• 너무 길게 쏟아져서 복잡하지 않나?
• 프로그램이 그냥 멈추지 않고 다음 행동으로 유도하나?
  • 예: “숫자를 입력해 주세요” 같은 안내

나도 예전에 에러가 터지면 그냥 콘솔에 빨간 글씨만 잔뜩 뜨는 코드로 제출(?)할 뻔했는데, 그때가 딱 “아, 이건 사용자 입장에서 너무 잔인하겠다” 싶더라. 😅

---

결과 정리: “무엇을 만들었는지” 한 문장으로 말하기

공유할 때 사람들은 사실 코드를 보기 전에 설명을 먼저 봐.
그래서 나는 작품 완성 후에 아래 질문에 답을 적어:

• 이 프로그램은 뭐 하는 거야?
• 어떤 입력을 받는 거야?
• 어떤 결과를 내는 거야?
• 사용 예시는 뭐야?

이걸 한 문장으로 정리하면 소개글이 바로 써져.

예시(형태만 참고):

• “이 프로그램은 사용자의 선택에 따라 점수를 계산하고 결과를 보여주는 간단한 콘솔 메뉴 프로그램이야.”

이렇게 말하면, 다음 사람이 “오케이, 이해됐다” 하고 넘어가더라.

---

공유는 이렇게 하면 좋아 (간단 버전)

이제 진짜 공유 단계! 공유는 꼭 거창한 게 아니고, “내가 만든 것”을 보여주기만 해도 충분히 의미 있어.

블로그/깃허브/메모 공유에서 보통 넣는 것들

• 사용 방법(짧게)
• 실행 예시(캡처 or 입력/출력 예)
• 코드의 핵심 포인트 2~3개
• 내가 겪었던 버그 한 가지(유머 섞으면 더 좋음!)

나름 팁 하나:
“내가 뭘 배웠는지”를 같이 적으면, 읽는 사람이 단순 코드를 넘어서 나의 성장을 보게 돼.

---

실패담 한 가지만 들려줄게 (나의 과거 버전)

예전에 메뉴 프로그램 만들었을 때였는데, “종료”를 선택해도 안 끝나고 계속 돌아가는 상황이 있었어.
원인은 거창한 게 아니라… 내가 while 조건을 잘못 걸어놨더라. 솔직히 말하면, 그날은 진짜 “내가 왜 여기서 멍청하게 헤매고 있지?” 싶었지.

근데 그 경험 덕분에 이후로는 무조건 마지막에:

• 종료 선택하면 실제로 끝나는지
• 루프가 정상 종료 조건을 만족하는지

이걸 테스트 리스트 최상단에 넣게 됐어. 나름 약속이랄까.

---

6-5 마무리 체크리스트

이제 아래만 통과하면, 작품 완성은 거의 끝이야.

• [ ] 정상 입력 테스트 완료
• [ ] 잘못된 입력 테스트 완료
• [ ] 경계값 테스트 완료
• [ ] 종료 테스트 완료
• [ ] 에러 메시지/안내 문구 확인 완료
• [ ] 결과 설명(한 문장) 작성 완료
• [ ] 공유용 사용 방법/예시 준비 완료

---

다음 글(7-1)로 자연스럽게 이어가자: 코드 리팩토링!

자! 여기까지 하면 프로그램은 “완성”이 됐고, 실제로 돌아가는 걸 확인했지.
근데 이제 슬슬 이런 생각이 들 거야.

• “이 부분… 그냥 굴러가긴 하는데 좀 지저분한데?”
• “중복된 코드가 보이네?”
• “함수로 쪼개면 더 깔끔할 것 같은데?”

맞아. 그래서 다음은 7-1 코드 리팩토링 이해하기로 가서,
내가 만든 프로그램을 더 보기 좋고 유지보수 쉬운 코드로 바꾸는 방법을 알아볼 거야.

그때는 “잘 만든 코드”가 아니라, “잘 관리되는 코드”가 뭔지 같이 감 잡아보자!