전투적 고백: 저는 과거에 조금씩 프로그래밍을 해봤지만, 그 분야에서는 매우 실수했습니다. 그래서 새로운 직업을 찾았습니다. 이는 매우 오래된 일이라서, 저는 당연히 개발자가 아닙니다.

지난 며칠간 작은 모델과 코딩 관련 어려움을 다루는 게시물이 몇 개 올라왔는데, 제가 성공적으로 사용해본 방법을 공유하고 싶었습니다. 이 글은 '이 프레임워크를 사용하세요'나 '이 에이전트가 그 일을 했습니다'라는 식의 글이 아닙니다. 기억해두세요, 저는 개발자가 아니며 현대 개발 전략이나 그런 것들을 배우지 않았습니다. 만약 실제 프로그래머 여러분에게 이 내용이 뻔하다면 저를 용서하고 넘어가 주시고, 만약 멍청하게 들린다면... 잘 작동하니까요.

나를 위한 'vibe-coding'을 바꾼 것은 LLM 이 매우 철저한 테스트를 작성하고 실행하게 한 것입니다. 이전에 제가 뭔가 잘못하고 있었는지 모릅니다만, LLM 이 이를 추천하지 않았습니다(GLM 5, Kimi K2.5, Gemini 3.0 Pro, Claude Sonnet...). 하지만 점점 더 사람들이 테스트와 반복적 개발 (iterative development) 을 언급하는 것을 보았는데, 제 시스템으로는 이를 구현할 수 없었습니다. 결국 LLM 에게 테스트 작성을 프롬프트로 주자, 테스트를 작성하고 각 변경 사항마다 이 테스트들을 실행하며 수정을 가했습니다. 이를 통해 Qwen 3.6 35B 로 Kimi K2.5 (테스트 전 obviously...) 보다 훨씬 더 나은 작업을 수행할 수 있었습니다.

이전에는 LLM 에게 기능을 추가하거나 문제를 고쳐달라고 요청하면, 다른 것이 어떤 식으로든 깨지거나 수정되는 일이 발생했습니다. 이는 Claude Sonnet 4.5 와 Kimi K2.5 에서도 마찬가지였습니다. 반면 Qwen3.5 122b, 27b, 35B 는 완전히 쓸모없었습니다. 이 테스트를 도입한 이후로는 Kimi K2.5 (Moonshot API 를 통해) 가 항상 반쯤 제대로 된 상태로 남기던 기능들이 정상적으로 작동하게 되었습니다. 그리고 이는 Qwen 3.6 35B 로 이루어졌습니다.

수정: LLM 을 이용해 작업한 것들:

• Python 으로 작성된 디스코드 봇
• 도커화된 MCP 서버
• 아내를 위한 도커화된 주간 식사 계획 앱 (이는 Qwen 3.6 35B 로 광범위하게 수행되었습니다).