20260728_바이브코딩_어떻게 내가 원하는 형태의 기획을 생성할 것인가_생성되는 바이브코딩 기능을 제한하거나 기능 구체화 할 수 있는 다양한 방법들 존재

기획자가 개발을 알아야 하는 이유 : 기획자가 개발의 언어를 이해할 수 있어야 협업이 원활하게 진행됨!

file:///C:/Users/amy%20hyewon%20lee/%EA%B0%95%EB%8F%997%EA%B8%B0%20AI%20PM%20%EA%B3%B5%EB%B6%80%EC%9E%90%EB%A3%8C/PM%EC%9D%84%EC%9C%84%ED%95%9C%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D.html

✅ 하는 것

서비스의 구조 이해 — 화면 뒤에서 무슨 일이 일어나는지
개발자와 같은 언어로 대화하기
일정·비용·제약을 이해한 현실적인 기획

“이 데이터를 저장하는 방식이면, 이렇게 하면 되나요?” (커뮤니케이션 비용을 줄이기 위한 소통방식)

데이터 여정을 이해하는 것은 협업을 위한 핵심이라 할 수 있음 데이터 처리와 관련된 백엔드 설계 자체가 달라져야 하는 부분인지 등에 대한 이해가 아주 중요

프론트엔드는 어느 순간으로는 react가 거의 다 먹음 flutter 툴도 있지만 요즘은 ai는 거의 react로 만들어내곤 함.

백엔드

비밀번호를 암호화하는 식으로 변화함(양자컴퓨팅과 결합됨) 200 ok라는 응답은 200은 ok라는 의미이다.

최근은 대다수 클라우드로 세팅하는데 aws gcp 데이터센터의 매우 큰 서버 임대하고는 하는데 임대비용내면서 서버를 사용하고 있다.

트래픽이 몰렸을 경우 요청이 많이 몰렸다는 의미

[데이터베이스]는 아주 크고 아주 튼튼한 엑셀이다 테이블 형태로 데이터가 쌓인다(정형데이터) 한 행은

웹으로 낼까 앱으로 낼까 =>정답은 없고 트레이드 오프만 있음

웹은 개발비용이 낮음(1벌 개발) 웹은 설치도 안해도 됨 플러터가 하이브리드 같은 언어임. 어느정도로 최적화까지는 아니나 하나로 웹까지도 개발가능

웹뷰는 웹으로 만든 것을 껍데기만 앱으로 씌운 상태 웹기반에서 앱도 필요한 경우 웹뷰

입고수량등은 백엔드에서 api 를 가져오는 것: 기능을 가져와서 사용하는 것 그 기능 api가 있나요라는 질문 중요 로그인을 보냈을 때 돌려받는다 데이터 관련해서 성공적으로 완수되는지의 문제 다른 상황에 대한 다른 화면으로 3개 만들어야 한다는 설계문제

상태코드를 통해 다른 문구, 다른 행동으로의 설계필요 만들 모든 기능 : CRUD 의 조합이다!

데이터베이스를 읽어올 때 Read

JSON : 데이터의 형태 JSON의 전체 내용이 데이터임 목록은 []로 묶임 {}가 하나의 묶음

실제 의도한 내용들이 잘 왔다갔다 하는지 확인하기 위해 F12의 개발자도구 창을 띄워서 확인함.

에러 문구와 실패화면을 어떻게 정할지 기획의 영역에 들어있다.

그래서 기획서를 이렇게 바꾼다. 깃,깃헙은 다른 사람들과 협업할 때 셋팅이 반드시 필요함. 스테이징에서 오류가 안나도 운영에서 오류가나기도 하는데 dev에 올라왔는가?라는 질문은 각자 했던 작업이 합쳐졌냐는 용어

핫픽스는 주로 게임 도메인에서 많이 활용하는 단어 롤백은 아주 큰 문제 생겼다는 의미

배포(화요일,수요일 쯤 배포하게 됨) - 배포 후 안정화 buffer(베타테스트 등 close테스트)- 이후 오픈

5명이 같은 코드를 동시에 고친다면 -> git을 통해 기록 보존가능 git은 코드의 게임 세이브 시스템 커밋은 기능 완성 후 저장 망하면 이전 세이브로 로드 모든 기록이 남는다 :누가 언제 무엇을 왜 바꿨는지 히스토리 남는다.(버젼관리)

메인 브런치에서 -다른 브랜치 사이에 검증을 하면서 다른 사람들의 브랜치 작업 후 메인 원본에 합칠 수 있게 함 어떤 기능이 업데이트 되었는지 update 라고 확인가능하도록 한다. 5개의 각각의 브랜치가 합쳐지도록 한다.

[pr] 머지를 할 수 있도록 검토해주세요

pr review 를 통해 확인함 보통은 기술리드나 cto가 코드검토하며 원본관리를 함(PR review)

ISSUE 할 때 어떻게 작성하는지 재현방법을 보통은 자세히 써 준다.

재현방법을 자세하게 써 줘야 계속 해보면서 개발자가 흐름 이해 가능 기대 동작도 자세히 써 주는게 중요 앱환경도 자세히 써 주는게 아주 중요함 어떤 환경이라고 써 주는게 아주 중요함.

[좋은 이슈의 3요소]

재현 방법 - 따라하면 나도 겪을 수 있게
기대 동장 - 원래는 어때야 하는지
환경,증거 - 기기 버젼, 스크린샷

원격 저장소를 통째로 복사해서 시작하는 것 중요 PULL : 동료 커밋을 내 로컬로 다운로드 PUSH 자체는 내가 만든 것을 올린 것. MERGE는 전체 팀코드에 합류됨

Conflict - 사람이 결정해야 함. conflict 해결하다가 오류가 많이 나기 때문에 최대한 안 나게 하는 것이 좋다. pull받았을때와 충돌하게 됨

part3 좋은 기획서는 개발자가 더 물어보는 기획서 기획서의 빈틈을 줄여가는게 아주 중요하다!!

화면 상태에 따라 화면을 4개 만들어야 하는 것

가입 성공하면 어디로 가는지 실패하면 어디로 가는지 이런 모든 화면을 고심하는 것이 아주 중요 “만들때”->“목적” 을 꼭 언급하는 것이 매우 중요 어떤식으로 흘러가는지를 이해하는 것이 매우 매우 중요함

기획자가 왜 설정값을 알아야 하는가? 설정을 아는 기획자로서 temperature는 ai의 창의성에 대한 부분임.

구글ai스튜디오 구글/플레이그라운드

[ai studio를 이용한 통제변인 실험] ai studio에서 compare mode 활용해서 알아보기 보통은 stable한 상태의 모델을 써야 갑자기 중단되는 상황이 안 생김.

복잡한 모델은 더 많은 에너지를 쓰고 속도도 보다 많이 걸림/ 적합한 상황에 골라 쓰는것이 적절 학습을 언제까지 한 것인지도 확인가능 틀리면 안되는 분야인지, 속도가 더 중요할지 등 고려해서 모델 선정=지연시간x품질x단가 최적화

(pdf 상에서 글자부분을 가져올 때)ctrl shift v 누르면 복사한 것이 글자로 들어가게 됨

아래PRD를 서비스기획자의관점에서리뷰해줘. 다음항목으로나누어분석해줘. -문제정의가명확한가? -핵심가치제안이충분한가? -MVP 기능이적절한가? -빠진요구사항은없는가? -사용자경험측면에서개선할점은? -개발전에반드시보완해야할 부분은? -각 항목마다근거와개선방향을 함께설명해줘. [PRD] +같이 PRD 파일도 넣어서 비교해보기.

[System prompt] 말투가 5분만에 무너질 때 ->지시를 사용자 메세지에만 넣었기 때문에 반말도 계속 써버리게 되는 것. 모든 turn에 사용하도록 : 일종의 하네스 엔지니어링 업무매뉴얼의 모습

가상의 시스템 프롬프트 맞춤형 시스템 프롬프트를 만들 수 있음

[AI Temperature] 출력의 무작위성을 제어하는 값 =>2로 갈수록 과감한 단어들도 사용 0~2.0 사이로 설정가능 무작위성을 높인다고 볼 수 있다

[top P] TOP P는 다음 토큰 후보를 누적 확률 상위 p까지만 남기고 그 안에서 뽑는 방식. temperature와 함께 다양성을 조절하는 도구. 99로 가면 대부분 다양성 포용

temperature를 높이면 높일수록 낮은 순위 후보도 선택 다양한 후보(cf. 다양한 후보라는 것이 더 적절한 창의적인 답이 나올 거라는 의미는 아님. 무작위성이 높아지는 것)

ex top-p 0.8로 정하면 자주 나오는 더 적절한 것으로 생각되는 답변 80% 아래는 아예 안나오도록 잘라냄.

top-p는 품질관리 재배치의 문제. 수학, 추론작업에서 예상치 못한 부적절성이 나올 수 있는 부분에 대한 경고

top-p를 조절하니 생각하지 못한 또다른 답변도 나오는 것을 확인가능했음.

[토큰] 토큰은 ai세계의 글자수이자, 화폐

-output length(maxoutputTokens) 문장 중간에서 아예 잘린다. 짧게 답해달라는 의미와 아예 다르다.

카드뉴스 콘텐츠 생성 ai-카드뉴스 콘텐츠 길이에 맞는 500자 내외 api 비용 절감을 위해 ex 아이디어 1,000개 입력해줘 이런식을 방지위해.

짧은 답변이 필요한 경우 -배송이 언제 오나요에 대한 대답은 평균 배송기간은 2~3일 정도로 충분. 다만 output length는 시스템 프롬프트로 ai가 생성하는 답변길이를 애초에 적용시켜두는 것이 좋다 (500자내외로만 해달라고 해두고) output length로 480자로 해달라고 하는 식으로

[stop sequence]-이 단어가 나오면 멈춰라 의도치 않게 잘리기 때문에 주의 필요

stop sequence 위치는 여기임.

stop sequence는 갑자기 덜렁 답이 잘려버리는 단점이 있다. 그래서 system instruction으로 적용하는것과 함께 적용하는게 좋겠다. csv를 생성하세요. 끝날 때는 end_of_csv로 끝내라는 표현 등으로 구획생성에 합당 =>어떤 식으로 출력을 하게 할 것인가를 충분히 고민한다면 좋을것.

[thinking level] 추론 깊이의 손잡이 고민을 길게 하면 할 수록 비용도 많이 출력되게 된다. 데이터 분석 리포트 등으로 추론이 많이 필요한 부분에만 high로 설정하는 것이 적절함. 토큰을 줄일 때 애초에 문서작성을 진행하거나 구체적 내용 요청하지 않은 경우에 기본 답변양 절반 정도로 짧게 대답해줘 정도도 괜찮은 표현인듯.

[structured Output]

data 타입에 있어서 예측가능성 높이기 이렇게 정리가 되어야 오른쪽 화면이 나온다. {
“type”: “object”,
“properties”: {
   “recipe_name”: {
     “type”: “string”
   },
   “servings”: {
     “type”: “integer”
   },
   “ingredients”: {
     “type”: “array”,
     “items”: {
       “type”: “string”
     }
   },
   “steps”: {
     “type”: “array”,
     “items”: {
       “type”: “string”
     }
   }
},
“required”: [
   “recipe_name”,
   “servings”,
   “ingredients”,
   “steps”
]
}

[ “recipe_name”, “servings”, “ingredients”, “steps” ]

[function calling] get weather라는 함수 선언하려고 함. [
{
“name”: “get_weather”,
“description”: “특정 도시의 현재 날씨(하늘 상태와 기온)를 조회한다. 사용자가 날씨, 기온, 우산 필요 여부 등을 물을 때 사용한다.”,
“parameters”: {
“type”: “object”,
“properties”: {
“city”: { “type”: “string”, “description”: “도시 이름 (예: Seoul, Busan)” }
},
“required”: [“city”]
}
}
]