gpt 5.5 이상이 되어야 코딩용으로 쓸만하고
그 미만은 글쎄올시다 ㅎㅎ
ai 환각을 잡는 방법이 있어
1. 사람이 일일이 검토. 그러나 ai 출력물이 너무 많아서 시간 오래걸림. 이럴 바에 ai 안 쓰고 사람이 하고 말지 ㅎㅎ
2. 사람이 기초 기획/설계를 하고 ai한테 검토시킴. 이거 정말 효율적임. 그러다 코딩을 시킨다. 그러면 결과물 좋다. 그런데 버그 있음. 어느 세월에 사람이 검토를 하냐고 ㅎㅎ
3. ai한테 검토시키면 추정으로 버그 있다고 하는 경우 많음. 버그임을 100% 검증을 못함.
4. ai가 말한 버그를 재현할 수 있는 테스트 코드를 작성하라.
이것이 별미임 ㅎㅎ 해보니까 대부분의 버그를 재현한다. 그런데 해도해도 재현 못하는 버그 있음. 그.경우 버그가 아니라 간주하면 됨.(그런데 진짜루 버그일 수도 있음)
5. 주의사항, 드물게 테스트 코드도 환각으로 작성하는 경우 있음. 따라서 코딩하는 ai랑, 검토하는 ai랑 컨텍스트가 달라야 함. 무슨 말이냐면, 같은 모델 gpt를 사용할 경우, 코드 작성은 웹gpt, 코드 리뷰는 codex 이렇게 나누라는 얘기.
또는, 장기기억 가능을 disable시키고,
웹gpt 대화창 1에서 코드 작성시키고
대화창2에서 코드 리뷰시키는 방법도 있으나 속도가 허벌나게 느리므로 이 방법은 비추
6. glm 5.2의 경우 그 정도까지 아직 써보1지 못하여 아직 입꾹닫.
7. 질문 안 받음. 내가 아직 ai에 대해 아는게 없거든 ㅎㅎ
내 생각엔 테스트 코드를 온갖 경우에 다 깔아두는 것도 비효율적임. LLM으로 테스트까지 과하게 생성하면 토큰이 그대로 금전 비용이고, 생성된 테스트를 읽고 고치고 깨질 때마다 유지보수하는 시간까지 추가로 듦. 특히 사소한 UI나 영향도 낮은 로직까지 전부 테스트로 덮으려 하면 실제 기능 구현보다 테스트 관리 비용이 더 커질 수 있음. 결제, 권한, 데이터 손상처럼 터지면 치명적인 부분만 빡세게 잡고, 나머지는 실제 사용 중 발견되면 그때 고치는 게 더 싸고 빠름. 예전 프로그램들도 지금처럼 자동화 테스트를 촘촘하게 깔지 않고 대체로 그렇게 굴러갔음.
회귀 테스트를 두는 거지