Claude가 구조 짜는 게 확실히 나으니까 한번 써보세요 ㅋㅋ
번역
코딩 프로젝트 설명서 작성할 때 좋은 프롬프트 있으신가요?
요즘 포트폴리오 정리하면서 깃허브 README 파일을 제대로 작성해야겠다 싶은데, AI한테 물어볼 때마다 결과물이 좀 아쉬워요. 보통 프로젝트 설명만 길게 늘어나고 정작 기술적인 내용은 부실하더라고요.
저는 지금 "이 프로젝트 README 작성해줘" 이 정도로 던지고 있는데, 더 좋은 결과를 얻으려면 어떻게 프롬프트를 구성해야 할까요? 예를 들면 타겟 독자(다른 개발자 vs 채용담당자)를 명시하거나, 섹션을 먼저 나열한 다음 작성하게 하는 식으로요. 취준생들끼리는 대충 봐도 되겠지만 실무자들 눈에 띌 수 있는 README를 만들고 싶거든요.
혹시 이런 상황에서 잘 먹혔던 프롬프트가 있으면 공유해주시면 감사하겠습니다. 아니면 README 작성할 때 꼭 포함시켜야 할 내용이 뭔지라도 알려주면 좋겠네요.
한 가지 더 궁금한 건데, Claude 쓰시는 분들은 GPT보다 이런 문서 작성에서 효과가 더 좋던가요? 제 경험상 Claude가 조금 더 구조를 잘 짜는 것 같긴 한데 확실하지 않아서요.
저는 지금 "이 프로젝트 README 작성해줘" 이 정도로 던지고 있는데, 더 좋은 결과를 얻으려면 어떻게 프롬프트를 구성해야 할까요? 예를 들면 타겟 독자(다른 개발자 vs 채용담당자)를 명시하거나, 섹션을 먼저 나열한 다음 작성하게 하는 식으로요. 취준생들끼리는 대충 봐도 되겠지만 실무자들 눈에 띌 수 있는 README를 만들고 싶거든요.
혹시 이런 상황에서 잘 먹혔던 프롬프트가 있으면 공유해주시면 감사하겠습니다. 아니면 README 작성할 때 꼭 포함시켜야 할 내용이 뭔지라도 알려주면 좋겠네요.
한 가지 더 궁금한 건데, Claude 쓰시는 분들은 GPT보다 이런 문서 작성에서 효과가 더 좋던가요? 제 경험상 Claude가 조금 더 구조를 잘 짜는 것 같긴 한데 확실하지 않아서요.
추천 14 비추천 0
- 이전글디자인 피드백 받을 때 쓸 만한 프롬프트 있으신가요?26.03.25
- 다음글코드 리뷰 자동화 프롬프트 좋은 사례 있으신가요?26.03.24
댓글
13
댓글목록
저도 같은 경험 했는데, 프롬프트에 "대상: 시니어 개발자/채용담당자"라고 명시하고 "Installation, Architecture, Tech Stack, 트러블슈팅" 이렇게 섹션을 먼저 지정해서 던지니까 훨씬 나아졌어요. Claude가 확실히 구조 잡는 거 더 잘하더라고요. 실무자들 눈에 띄려면 성능 개선 내용이나 왜 이 기술을 선택했는지 설명이 꼭 들어가야 해요.
저도 처음엔 그렇게 하다가 프로젝트 목표, 기술스택, 아키텍처, 설치 방법, 트러블슈팅 섹션을 미리 명시하고 "각 섹션마다 실무 수준으로 작성해줄 것" 이렇게 덧붙였더니 훨씬 나아졌어요. Claude가 확실히 구조화를 더 잘하는 것 같긴 한데 GPT도 프롬프트 정확도에 따라 비슷해진다는 느낌이에요. 타겟 독자 명시는 필수더라고요.
저도 처음엔 그렇게 던졌는데 너무 뻔했어요. 요즘은 "이 프로젝트의 핵심 기술 스택은 X, Y, Z이고 왜 썼는지 설명해줘"라고 먼저 말하고, 그 다음에 README 작성하게 하니까 훨씬 낫더라고요. 구조 먼저 요청한 후 채우는 방식도 추천합니다. Claude가 이런 부분에서 확실히 더 정리가 깔끔한 것 같아요.
저도 같은 문제 겪고 있었어요 ㅠㅠ
저도 같은 고민이었어요 ㅠㅠ
저도 같은 경험이에요 ㅋㅋ Claude가 확실히 구조를 더 잘 짜더라고요
저도 비슷한 경험이 있는데, 프롬프트에 "타겟 독자는 실무 개발자"라고 명시하고 "Installation, Usage, Architecture, Technical Stack, Key Features"처럼 섹션을 먼저 정의해놓고 작성하게 하면 훨씬 낫더라고요. 그리고 프로젝트의 문제 상황을 먼저 설명하고 어떻게 해결했는지를 강조하는 식으로 주면 좋아요. Claude는 맞는데 구조화된 답변이 조금 더 나오긴 해요. 다만 기술 깊이 부분은 AI가 맥락을 모르면 추상적이 되니 코어 로직이나 핵심 의사결정은 직접 추가하는 게 낫습니다.
저도 같은 경험이 있는데, 타겟 독자랑 프로젝트의 핵심 기술을 먼저 명시하고 나서 작성하라고 하면 확실히 달라지더라고요. Claude가 구조를 잘 짜는 건 맞는 것 같아요. 기술 스택 설명 부분에서 각 기술을 선택한 이유까지 넣으라고 하면 좋은 결과 나오네요.
Claude가 구조는 확실히 낫더라고요 ㅋㅋ
저도 비슷한 경험이 있는데, 저는 프로젝트 구조를 먼저 설명한 다음 각 섹션별로 어떤 톤으로 작성할지 명시하니까 훨씬 낫더라고요. 예를 들면 "Installation은 개발자 입장에서 따라하기 쉽게, Architecture는 기술 선택 이유를 포함해서" 이런 식으로요.
그리고 Claude가 확실히 구조 짜는 데는 더 나은 것 같습니다. 특히 기술적인 설명을 간결하게 정리하는 부분에서요. 한 번 시간 투자해서 프롬프트 다듬어놓으면 나중에 프로젝트마다 재사용할 수 있어서 좋습니다.
그리고 Claude가 확실히 구조 짜는 데는 더 나은 것 같습니다. 특히 기술적인 설명을 간결하게 정리하는 부분에서요. 한 번 시간 투자해서 프롬프트 다듬어놓으면 나중에 프로젝트마다 재사용할 수 있어서 좋습니다.
저도 같은 경험이었는데 프롬프트에 "기술 스택, 핵심 기능, 설치 방법, 트러블슈팅" 섹션을 먼저 나열하고 각각 상세히 작성하라고 하니까 훨씬 낫더라고요. Claude가 맞는 것 같아요, 구조화하는 능력이 조금 낫긴 해요.
저도 처음엔 그렇게 했는데 프롬프트에 "기술 스택, 주요 기능, 설치 방법, 트러블슈팅" 이렇게 섹션을 미리 나열해주니까 훨씬 나아졌어요. Claude가 구조는 확실히 낫더라고요.
댓글을 작성하려면 로그인이 필요합니다.