바이브 코딩으로 만든 게임입니다.
한 손으로 빠르게 할 수 있는 게임으로 기획하였습니다.
기본 기능 만드는데 7일 정도 걸렸고 피드백 받은 거 적용하는데 7일 정도 추가로 걸렸습니다.
자잘한 수정(대부분 이미지와 UI 수정)까지 포함하면 여기까지 만드는데 3주 정도 걸렸습니다.
단지 바이브 코딩 특성상 틈이 많이 남아서 이 프로젝트만 집중해서 작업한 시간은 그렇게 많지 않습니다.
프롬프트만 던져놓고 딴 작업 하면서 만들었습니다.
1. 개요
유니티6 + Visual Studio + github copilot으로 만들었습니다.
비주얼 스튜디오(Visual Studio)의 경우 '깃허브 코파일럿(github copilot)'을 설치하면 자동으로 통합되어
별도의 설정 없이 바로 사용할 수 있다는 장점이 있습니다.
손 코딩을 전혀 하지 않은 것은 아니지만 95% 정도 바이브 코딩했습니다.
대부분 GPT-5를 사용하였고 부분적으로 클로드4.5를 사용했습니다.
코딩에 강세를 보이는 건 클로드인데도 GPT-5를 사용한 이유는 GPT-5가 클로드보다 한국어를 더 잘 이해하기 때문입니다.
(2025년 10월 기준)
취향 차이라고 생각하시면 됩니다.
이것 말고도 몇 가지 이유가 더 있긴 한데 대부분은 개인 취향 문제라고 보시면 됩니다.
결국은 여러 AI를 섞어 쓰게 됩니다 ㅎㅎㅎㅎ
2. 바이브 코딩할 때 주의해야 할 것
각 AI들은 업데이트 때마다 특성이 조금씩 달라지는 경우가 있습니다.
특히 버전이 바뀌는 큰 업데이트 이후 안정성이 떨어지는 경우가 자주 있으므로 필요에 따라 다른 AI를 사용하는 것을 염두 하는 것이 좋습니다.
같은 프롬프트도 A를 가 더 잘 나오는 경우도 있고 B가 더 잘 나오는 경우가 있어서 검수할 때 취향 따라서 롤백하고 다른 AI를 이용하는 것이 좋습니다.
대부분의 바이브 코딩 툴들이 질문 직전에 복원 지점을 만들어 롤백할 수 있도록 지원하는 것으로 알고 있습니다.
Visual Studio + github copilot의 경우도 쉽게 롤백할 수 있게 되어 있습니다.
다른 방식을 사용하더라도 바로 롤백할 수 있도록 구성하는 것이 좋습니다.
3. 바이브 코딩하면서 느낀 점
모든 코드를 검수한 게 아니라서 아래 분석이 100% 완벽한 분석이 아닙니다.
유니티 프로젝트는 AI가 유니티 에디터 쪽의 정보에 접근하지 못한다는 것을 감안하고 읽으셔야 합니다.
가급적 유니티 관련된 것은 따로 적으려고 했으나 정확하게 분리되지 않았을 수 있습니다.
3-1. 일반적인 사항
유니티와 관련이 없거나 유니티에 영향이 적은 사항을 정리하였습니다.
3-1-1. 널 체크에 진심이다.
구조상 null이 나올 수 없는 상황이라도 AI는 유니티 상황을 알지 못하니 개체를 찾지 못할 때를 대비한 방어 코드를 빡세게 작성합니다.
제가 방어 코드를 빡세게 작성하는 편이라 동료들과 부하직원들한테 원성을 듣는데 그런 제가 봐도 AI들은 너무 빡세게 작성합니다.
이런 건 중간중간 확인해서 수작업해 주시는게 좋습니다.
특히 동작 자체는 되는데, 원하는 방식으로 안되어 문제를 지적하는 프롬프트를 작성하면 더 심해집니다.
빌드상으로 오류가 나는 것이 아니라서 프롬프트를 작성할 때 더 신경 써야 합니다.
3-1-2. 진단을 잘해야 한다.
잘못된 결과를 계속 맞다고 우기는 경우가 꽤 됩니다.
이게 코드가 복잡해질수록 A를 진단해야 하는데 B를 진단하고 거기서만 헤매는 경우가 많아집니다.
이런 경우 직접 코드를 분석하여 A로 진단했다는 사실을 알려줘야 정확한 수정을 합니다.
이상한 코드를 뱃는다 싶으면 대부분 진단이 잘못된 경우가 많습니다.
진단을 직접 해서 프롬프트에 넣어주면 바로 해결되는 경우가 자주 있습니다.
이런 경우 다른 AI를 써도 진단이 크게 다르지 않는 거 보면 아직은 요정도 인가보다~ 하면서 쓰고 있습니다.
(케이스 바이 케이스로 AI마다 다른 진단을 하는 경우도 있습니다.)
그래도 AI가 한 진단의 일부분이 잘못됐음을 지적하면 바로 다른 진단을 합니다.
전체 진단이 귀찮으면 부분 지적도 방법 중 하나입니다.
3-1-3. 인간의 관념과 AI의 관념은 다를 수 있다.
'앞/뒤' 같은 단어를 못 알아듣는 경우가 많습니다.
인간은 보통 진행하는 방향을 앞으로 인식하는 경우가 많지만, AI 입장에서는 그렇지 않은 것으로 보입니다.
명시적으로 '왼쪽/오른쪽' 단어를 쓰는 것이 좋습니다.
이유는 모르겠지만 가끔 이것도 알아듣지 못하는 경우가 있는데.
이럴 때는 차라리 변수 하나를 만들어서 이것을 이용하여 정방향/역방향 처리할 수 있게 해달라는 게 좋습니다.
이것이 유니티가 3D공간을 다루는 프로젝트라서 그런 건지 잘 모르겠습니다.
3D공간의 경우 캐릭터의 방향에 따라 오른쪽/왼쪽도 바뀌니 이런 게 관련있을 수 있습니다.
2D게임의 경우 카메라 기준이라고 명시하면 이런 문제가 줄지 않을까 합니다.
3-1-4. 롤백을 적극적으로 이용하자.
잘못된 결과가 나오는 프롬프트도 수정하면서 길게 대화를 한 다음
AI가 잘못된 판단하거나 내가 잘못한(혹은 빼먹은) 점을 체크하여
처음 복원 지점으로 돌리고 지금까지 정보로 프롬프트를 수정하여 다시 시도하는 것이 좋은 경우도 자주 있습니다.
이렇게 하면 긴대화 동안 수정된 코드보다 깔끔한 코드가 나오는 경우도 많고
좀 더 깔끔한 코드를 작성할 수 있도록 프롬프트를 작성하는 것이 쉽습니다.
'버전 관리 시스템'을 적극적으로 사용하는 것도 도움이 됩니다.
예> 깃의 경우 커밋을 이용하여 복원 지점 활용
3-1-5. 정보가 너무 많은 것이 독일 때가 있다.
프로젝트의 모든 코드에 AI가 접근할 수 있다는 점이 장점이지만 작은 크기의 함수나 모듈을 만들 때는 단점이 될 수 있습니다.
기획으로는 한두 개의 함수로 끝낼 수 있는 코드를 여러 구조에 걸쳐 많은 코드를 수정하는 경우가 꽤 됩니다.
이럴 때는 채팅형 AI를 사용하거나 별도 프로젝트에서 작업하는 것이 좋습니다.
예> 유틸리티 프로젝트
좋은 프롬프트 : A함수 안에서 만들어줘
3-2. 유니티 관련
유니티 프로젝트는 AI가 유니티 에디터 쪽의 정보에 접근하지 못한다는 것을 감안하고 읽으셔야 합니다.
3-2-1. 유니티 에디터의 기능은 사용하지 못한다.
바이브 코딩을 우선하다 보니 유니티의 자체 기능을 사용하지 못하는 경우가 꽤 됩니다.
- 스프라이트로 처리하는 게 더 효율적인 경우(각도기)
- 충돌 처리(코드로 직접 처리됩니다.)
유니티 물리 엔진을 사용해도 되는 경우는 유니티 에디터에서 컨트롤하는 것이 더 효율적인 경우도 있습니다.
이것도 귀찮다 싶으면 유니티의 물리엔진을 사용하지 않으면 됩니다.
3-2-2. 유니티는 에디터에 저장된 값이 우선된다.
유니티는 에디터에 저장된 값이 우선됩니다.
그러다 보니 'MonoBehaviour'를 상속받는 클래스의 변수는 에디터에서 수정할 값과 아닌 값을 명확하게 구분해야 합니다.
에디터에서 수정할 값은
public string Test1;
안 할 값은 게터/세터(getter/setter)로 선언해야 에디터에 표시되지 않습니다.
public string Test1 {get;set;}
AI는 이런 걸 구분하지 않고 가능하면 에디터에 표시하도록 합니다.
이렇게 되면 코드에서 값을 바꿔도 에디터값이 우선되어 값이 안 바뀌는데 바뀌었다고 생각하고 작업하는 경우가 자주 발생합니다.
그래서 'MonoBehaviour'를 상속받는 클래스의 멤버 변수는 프롬프트에 명시하던가 하나하나 확인해야 합니다.
안 그러면 로그 찍어보고 아차! 합니다 ㅎㅎㅎㅎ
진단을 부탁해도 AI가 에디터에 값이 고정됐을 가능성에 대해서 언급하지 않습니다.
(사람들이 자기 실수에 민감해서 그런가?)
정신 바짝 차려야 합니다 ㅋㅋㅋㅋㅋㅋ
3-2-3. 유니티 개체의 속성값을 너무 자주 초기화한다.
유니티 개체의 경우 속성값을 매번 초기화하는 코드를 많이 볼 수 있습니다.
public bool bTest = false;
public void A()
{
bTest = false;
....
}
public void B()
{
bTest = false;
....
}
바이브 코딩이 아니면 큰 문제가 아니지만 바이브 코딩에서는 속성값 초기화하는 코드가 함수마다 있는 경우도 볼 수 있습니다.
특히 유니티 에디터에 노출되는 값의 경우 처음에는 초기화 코드가 없다가 비슷한 문제가 반복되면
'3-2-2. 유니티는 에디터에 저장된 값이 우선된다.'의 문제를 의식하는 건지 초기화 코드가 붙기 시작합니다.
한번 세팅되고 건딜 필요없는 속성은 가능하면 별도로 초기화할 수 있도록 세심하게 프롬프트를 작성하든가 수작업하는 것이 좋습니다.
3-2-4. AI는 코딩을 우선한다.
코딩으로 처리하는 게 비효율적이거나 구조적으로 힘든 경우가 있는데 AI는 이런 부분을 명시적으로 물어보지 않으면 알려주지 않고 코드 수정을 우선합니다.
예> 유니티 물리엔진과 관련된 내용
잘못된 프롬프트 : 마찰력을 늘려주세요.
좋은 프롬프트 : 마찰력을 늘리기 위해 코드를 수정하는 것과 인스팩터(Inspector)를 수정하는 것중 어느 것이 더 좋은가요?
이런 경우 채팅 형 AI한테 별도로 물어보는 편이 도움 될 때도 있습니다.
결국 유니티의 구조도 숙지하고 있어야 이런 상황을 구분하고 좋은 프롬프트를 작성할 수 있습니다.
마무리
소스 : github - PublicSource : NinjaAppeared
원래 기획과 많이 달라져서 더 이상 개발하지 않는 게임입니다.
기획 자체를 게임의 완성도 보다는 바이브 코딩에 중점을 둔 프로젝트입니다.
가볍게 한 손으로 할 수 있는 게임을 표방하며 기획했는데 의도 대로 나왔는지 모르겠습니다ㅎㅎㅎㅎ
대부분의 리소스도 AI를 이용하여 만들었습니다.
Gemini를 이용하였습니다. (원래 이런 이미지는 ChatGPT를 사용했었는데 이번에는 Gemini를 사용했습니다.)
외부 리소스 :
케릭터 - Platformer Art Extended Enemies, Platformer Art (more enemies and animations) by Kenney Vleugels, License (CC0)
효과 - 64x64 Pixel Effect RPG Part 12, 750 Effect and FX Pixel All
사운드 - pixabay.com sound effects
