Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
Tags
- Rag
- AWS Network
- Java
- MySQL
- golang
- aws vpc
- PETERICA
- AWS EKS
- CKA 기출문제
- SRE
- 코틀린 코루틴의 정석
- LLM
- aws
- 기록으로 실력을 쌓자
- Claude
- docker
- go
- kotlin coroutine
- Network
- 오블완
- Kubernetes
- kotlin
- tucker의 go 언어 프로그래밍
- 정보처리기사 실기 기출문제
- AI
- 공부
- Spring
- CKA
- 티스토리챌린지
- 바이브코딩
Archives
- Today
- Total
목록ssot (1)
피터의 개발이야기
TL;DR좋은 문서는 대화를 보관하는 기록이 아니라, 다음 대화를 더 정확하게 만드는 컨텍스트다.AI와 긴 프로젝트를 진행할 때 결과가 흔들리는 이유는 코딩 능력만의 문제가 아니다.서비스의 목적, 사용자 경험, 기술, 데이터, 기능을 한꺼번에 다루면 제안과 결정이 섞이고 무엇이 기준인지 모호해진다.PRD, UX, 기술 스택, 데이터베이스, 도메인, API는 서로 다른 결정을 나누어 담는 문서다.이 문서들을 SSOT와 MECE 원칙으로 정리하면 사람과 AI가 같은 기준을 볼 수 있다.문서가 할루시네이션을 완전히 제거하지는 않지만, 충돌하는 정보와 불필요한 추측이 발생할 가능성을 줄여 준다. ㅁ 들어가며AI를 활용 방법에 대한 질문을 많이 받는다. 단순히 AI에게 아이디어를 설명하고 “서비스로 만들어 줘”라..
AI/바이브코딩
2026. 7. 25. 13:00