바이브코딩과 하네스 엔지니어링
하네스 엔지니어링 결론부터 말하면 개발 기획자는 별도로 할것 없이 기존에 하던데로 그냥 하면 됩니다.
이것, 저것, 문제가많네~ 이런식으로 특정하지 않는 형태로 이쁘게 만들어줘 하는 방식이 문제가 있는것으로 이렇게 언급하는 방식은 현재 사람도 의도 파악을 정확히 모르기 때문에 원하는 결과가 나오지 않습니다.
문제가 많아 - 어떤 문제가 많은지 구첵적으로 알려 줘야 해결 가능.
이렇게 해석해도 큰 무리가 없는것으로 어떤 문제가 있는지 명확하게 알려줘야 개선이 되고 같은 문제가 생기지 않습니다.
예를 들면.
1) 상태값 기록을 위해서 테이블에 시간과 현재 상태 기록해서 체크하는것을 만들어 달라고 했더니 만들긴 잘 만들었습니다.
아... 그런데 날짜를 유닉스 타임스템프로 넣었네... 내가 보려면 다시 변환해서 봐야 하는데....
2) 그리고 이미지 포맷 초기에 원본에 해당하는 비트맵 이미지만 필요하니 그에 맞게 프로그램 하랬더니
테이블에서 비트맵 컬럼만 남기고 나머진 다 없애버림.
아... 다음 단계의 프로그램에서 필요한 png, jpg 같은 컬럼 삭제 하면 안되는데 ...
3) 복제 잘못되서 복구 하려는데 reset 하라길레 그거하면 안되는데 .... 이때 눈치 챘어야 하는데..
자주 하는게 아니라서 세밀히 봤어야 했는데 .... 그 다음 알려준게 완전 날려 먹는 명령...
이런 복구가 테스트 단계에서의 이전 데이터 무시하고 복구인가 기존 데이터 유지하면서 복구인가에 따라 다른데 딸각 하면 해결 되는게 아니라 딸각으로 더 큰 문제가 발생 할 수 있습니다.
위와 같은 문제가 발생 하지 않으려면 명확하게 말을 해줘야 문제가 발생 하지 않습니다.
그리고 앞으로 무엇을 할것인지 왜? 하는지 사람에게 설명 하는것 처럼 해야 되는것으로 흔히 발생 할 수 있는 문제를 예상해 보면
사람은 기존의 회사의 분위기는 기존에 하던 방식이 있기 때문에 몇가지 명확하지 않은것도 당연히 그렇게 하는것으로 인식하고
진행이 가능한데. Ai는 그렇지 않기 때문에 다 언급을 해줘야 되는 것입니다.
-- 2026.07.04 추가 --
이렇게 저렿게 만들어 주세요 그러면 이렇게 저렿게 잘 되게 만들어 줍니다.
그나마 어제 수정했더니 다른게 안되서 또 수정하고 초기에 명확하게 잘 해야 됩니다.
그럴려면 많이 알아야 되고 많이 알려면 공부와 시행착오 그리고 이를 위한 기간이 필요 합니다.
어제 있었던일인데 속도에 대한 개념없이 되게만 만들어서 고치라고 했습니다.