바이브코딩을 알려주고 있습니다.
주변에 문과 출신의 IT 파견을 하는 지인이 생겼는데
어느날 antigravity로 자기가 하는 비즈니스 사이트를 만들고 있다고 하네요..
직접 만나서 알려주는게 좋다고 찾아와서
신주쿠의 스타벅스에서 만나서 PC를 꺼내서 만드는 과정을 봤습니다.
그러면서 좀 정리가 되었는데요..
우선!
오른쪽의 채팅 창은 휘발성입니다!
점점 복잡해질 수록 ai는 목적만 달성 하고자
기존 소스와는 무관한 소스를 만드는 습성이 있습니다.
그리고 혼을 내면 낼 수록
코드를 숨깁니다.
혼나는게 싫어서 라는 인간적인 감정보다는
최대한 혼날 일은 감추면 인터랙티브 하는 시간이 줄어 효율적이라고 생각 하는 거 같더라구요..
그래서 꼭 필요한게
프로젝트 README.md 입니다.
프로젝트의 개요에서부터 파일 구조, 기능 리스트, 기동 방법 등의 개략적이면서
ai가 이 프로젝트에 필요한 기본 룰을 익히는 거죠.
물론 ai에게 요청하고 기능이 추가되거나 바뀔때 마다 업데이트를 시켜야죠.
그 다음에 기능을 구상하여
기능을 간단히 적고 사양서를 만들라고 해야하구요..
그 사양서를 기준으로
구체적인 작업지시서를 만들라고 시킵니다.
작업 지시서에는 아주 구체적인 이야기가 들어가야 하는데요..
메일 발송 기능이라고 하면
메일 서버를 쓸지 자체 sendmail을 구축할지, sendgrid같은 외부 전송 서비스를 쓸지 등이 자세히 기록 되어야 하구요,
메일 템플릿의 종류과 관리 방법 등이 자세히 들어가야죠.
이건 처음부터 ai가 바로 만들어주지 않기 때문에
시간을 들여 대화를 하면서 구체화 시킵니다.
작업 지시서를 보고 문제가 없어 보이면
그대로 작업을 시킵니다.
그러다보면 에러도 내는데요..
이슈문서를 만들게 시켜서
에러의 분석 및 해결 방법의 제안을 시키게 합니다.
이 때 제안이 완료 되어 내가 승인 해야만 작업을 하라고 해야 합니다.
안그러면 더욱 꼬이게 만들기도 하거든요..
이슈 문서를 꼼꼼이 읽어보면
은근히 말도 안되는 추측성 원인 분석을 하기도 하는데,
추측 금지를 강제화 시킵니다. 물론 말로요..
근거를 제시하게 하면서
이슈에 대한 분석 및 해결을 완벽하게 할 때까지 시간을 들여 조정하고
그 이슈를 해결을 시킵니다.
물론 나도 몰라서 그냥 해보라고 하기도 하는데요
하나의 이슈가 해결될 때까지
계속 이슈 처리 이력을 하나의 문서에 계속 누적 시키면
마지막으로 해결 단계까지 가구요,
그 문서를 기반으로 동일 에러는 쉽게 해결이 되죠.
이런 식으로 기능 하나에 여러 문서를 생성하게 되지만,
지금까지 해결 못하고 맴도는 ai와는
다른 결과를 보시게 될 겁니다.
처리 완료되면 사양서를 최신화 시키구요,
자주 있는 이슈 리스트에 이슈 처리한 파일들을 링크 걸어놓죠.
그럼 기능 개선등에도 참고가 되고,
같은 문제를 점점 덜 일으키죠.
같은 문제를 일으키는게 느껴지면
작업지시서에 추가로 언급해서 반드시 이전에 해결했던 이슈 문서 체크하라고 하면
그만큼 또 문제가 줄어듭니다.
이렇게 하나씩 해결해나가면
파일이 수천개에 문서가 수백개가 넘어가는 복잡한 서비스가 되지만
ai는 일관성 있는 결과물을 내줄 겁니다.
IT전문이 아니면 기본적인 개발 방법론 같은건
배울 기회가 없잖아요? 뭐, IT전문이라고 하는 사람들이
문서하나 안만들고 대충 땜빵해 오는 프로젝트도 많이 봤습니다.
이게 ai를 시키는 거랑 비슷한 거죠..
제대로 된 프로젝트는 문서가 생명입니다.
https://giip.littleworld.net/
Littleworld Service Hub
Lord of the Lords : turn base war simulation game
댓글
댓글 쓰기