[pr] 사용자가 있는 Gemini 웹앱 출시하기

[사용자가 있는 Gemini 웹앱 출시하기] 지오 미션 제출합니다. by JuHyeong424 · Pull Request #8 · woowacourse/gemini-canvas-mission

[사용자가 있는 Gemini 웹앱 출시하기] 지오 미션 제출합니다. by JuHyeong424 · Pull Request #8 · woowacourse

 

미션에 대한 pr을 받았다.

 

주요 pr 내용은 다음과 같다.

 

1. 프롬프트 작성 시 요구사항을 번호 등으로 구조화하는 것이 좋은가?

리뷰어의 답변: 아주 좋다.

• 목적에 따른 프롬프트 차이: 창의적인 아이디어가 필요할 때는 대화형이 좋지만, 정해진 방향의 구체적인 코드를 원할 때는 요구사항과 제약사항을 상세히 구조화(항목화)하는 것이 훨씬 적합히다.
• 권장 구조: 단순히 1, 2번으로 나누는 것을 넘어 PR 템플릿처럼 구체적인 카테고리를 나누는 것을 추천한다.
  • 예시 카테고리: 앱의 목표, 주요 기능, 제약사항/주의사항, UI 형태, 엣지케이스 등

---

2. 기계가 이해하기 어려운 '스타일(가독성 등)'을 한 번에 지정하는 방법은?

리뷰어의 답변: 구체적인 '포맷 규칙'과 '예시'를 함께 제공해라.

• 스타일을 매번 지적하기보다는, 처음에 문제/해설이 출력될 포맷과 예시를 프롬프트에 명시하면 과정을 크게 단축할 수 있다.
• 적용 예시:
  • 규칙 지정: "코드나 명령어가 포함되면 무조건 가로 스크롤이 가능한 코드 박스로 렌더링하라."
  • 예시 제공: 원하는 출력 형태의 샘플 코드를 직접 프롬프트에 포함하여 AI가 똑같이 따라 하도록 유도.

3. 초기 뼈대(핵심 기능 vs 세부 기능)는 어디까지 작성해야 하는가?

리뷰어의 답변: 정답은 없으며, '시간'과 '프로젝트 상황'에 따라 유연하게 조절해야 한다.

• 기본 원칙: 결과물만 본다면, 초기 프롬프트에 세부 시나리오(UI/UX 등)가 상세하게 들어갈수록 서비스의 퀄리티는 확실히 올라간다. 질문자님이 세부 기능까지 덧붙인 접근 방식 자체는 결과적으로 좋았다.
• 상황별 조절 팁 (리뷰어의 제안): 제한된 시간(코드 확인, 테스트 등)을 고려하여 뼈대의 양을 조절해야 한다.
  • 시간이 남을 때: 뼈대에 세부 사항과 엣지케이스(창 크기 조절, 네트워크 에러 처리 등)를 더 꼼꼼히 보완한다.
  • 시간이 부족할 때: 뼈대의 양(디테일)을 늘리기보다는, 현재 있는 내용을 최대한 '구조화'하는 데 집중한다.

요약하자면:

프롬프트는 구체적인 항목(목표, 기능, 예외처리 등)으로 나누어 구조화하고, 스타일은 규칙과 예시로 한 번에 통제하며, 프롬프트의 디테일 수준은 주어진 시간과 상황에 맞게 유연하게 조절하라.