포트폴리오 제작기 6 - Unity Assistant로 코딩하며 느낀 점

Unity Assistant로 코딩해보기

이번에는 Unity Assistant를 이용해서 프로젝트 코드를 작성해보고 있다. 단순한 에셋 배치나 이미지 생성이 아니라, 실제 게임 로직과 UI 구조에 들어가는 코드를 AI에게 맡겨보는 단계다.

처음 요청할 때는 MVVM 스타일로 작성해달라고 분명히 말했다. UI와 데이터, 동작 로직을 적당히 분리하고, View가 모든 것을 직접 처리하지 않도록 구성하고 싶었기 때문이다. 포트폴리오 프로젝트라서 결과물이 돌아가는 것도 중요하지만, 코드 구조가 읽기 좋고 유지보수하기 쉬운지도 중요하다고 생각했다.

기대와 달랐던 결과

하지만 실제로 나온 코드는 기대와 달랐다. 겉으로는 MVVM처럼 보이도록 이름을 붙였지만, 내용을 보면 View 쪽에 로직이 섞여 있거나, ViewModel이 해야 할 일을 다른 클래스가 대신 처리하는 식이었다.

내가 기대한 흐름은 View <-> ViewModel <-> Model이었다. View는 화면 표시와 입력 전달에 집중하고, ViewModel이 상태와 동작을 정리한 뒤, Model과 데이터를 주고받는 구조를 원했다. 그런데 AI가 만든 코드에서는 이런 맥락이 지켜지지 않았다. View에서 바로 Model을 편집하는 코드가 들어가 있었고, 그 순간 MVVM을 적용하려던 이유가 흐려졌다.

AI에게 "MVVM 스타일로 작성해줘"라고 말한다고 해서 그 구조를 끝까지 지켜주는 것은 아니었다. 처음 몇 줄은 그럴듯하게 시작하지만, 기능을 붙이다 보면 금방 편한 방식으로 흘러가 버렸다. 결국 내가 원했던 구조와 실제 생성된 코드 사이에는 차이가 꽤 있었다.

결국 직접 수정 중

그래서 지금은 생성된 코드를 그대로 쓰지 않고, 직접 한땀 한땀 수정하고 있다. View에서 빠져야 할 로직을 ViewModel로 옮기고, 데이터 변경 흐름을 정리하고, 클래스 역할이 섞인 부분을 다시 나누는 식이다.

AI가 만들어준 코드는 완전히 쓸모없는 것은 아니었다. 초안을 빠르게 만들고, 어떤 기능이 필요한지 대략적인 형태를 잡는 데에는 도움이 되었다. 하지만 그 코드를 그대로 프로젝트에 넣으면 나중에 더 큰 문제가 될 수 있겠다는 생각이 들었다.

예를 들어 이런 코드도 있었다.

public void Apply(Transform target)
{
    if (isLocalSpace)
    {
        target.localPosition = position;
        target.localEulerAngles = rotation;
        target.localScale = scale;
    }
    else
    {
        target.position = position;
        target.eulerAngles = rotation;
        target.localScale = scale;
    }
}

이 코드는 내 의도에서는 파라미터가 필요 없는 코드였는데, AI가 Transform target을 추가해두었다. 겉으로 보면 그럴듯해 보이지만, 실제 구조에서는 해당 객체가 이미 적용 대상을 알고 있어야 하는 상황이었다. 이런 식으로 AI가 임의로 파라미터를 늘리면 호출부도 같이 복잡해지고, 클래스가 가져야 할 책임도 흐려진다.

해당 함수는 저장된 값을 자기 자신에게 적용하는 내용이기 때문에 파라미터가 필요 없다. 그래서 아래처럼 고쳤다.

public void Apply()
{
    if (isLocalSpace)
    {
        transform.localPosition = position;
        transform.localEulerAngles = rotation;
        transform.localScale = scale;
    }
    else
    {
        transform.position = position;
        transform.eulerAngles = rotation;
        transform.localScale = scale;
    }
}

이렇게 바꾸면 호출하는 쪽에서 별도의 Transform을 넘길 필요가 없고, 함수의 책임도 더 분명해진다. AI가 만든 코드를 그대로 따라가기보다, 프로젝트 구조에 맞지 않는 부분은 과감하게 정리해야 한다.

AI 코드는 항상 확인해야 한다

이번 작업을 하면서 다시 느낀 점은, AI가 작업한 코드는 항상 확인해야 한다는 것이다. 특히 아키텍처나 설계 패턴처럼 코드 전체의 방향을 잡는 부분은 더 그렇다.

문법이 맞고 실행이 된다고 해서 좋은 코드가 되는 것은 아니다. MVVM처럼 역할 분리가 중요한 구조에서는, 코드가 어디에 위치해야 하는지와 어떤 클래스가 어떤 책임을 가져야 하는지가 훨씬 중요하다. 이 부분은 AI가 자주 흐트러뜨릴 수 있어서 사람이 계속 확인해야 한다.

결국 AI는 코딩을 대신 끝내주는 도구라기보다, 초안을 빠르게 만들어주는 보조 도구에 가깝다. 결과물을 그대로 믿기보다는, 내가 원하는 구조에 맞는지 계속 읽고 고치면서 사용해야 한다.

이번 경험 덕분에 Unity Assistant를 쓸 때의 기준도 조금 더 분명해졌다. 작은 기능의 초안이나 반복적인 코드 작성에는 도움을 받을 수 있지만, 프로젝트 구조를 결정하는 코드는 반드시 직접 검토하고 수정해야 한다.

번외: 토큰 소모 속도

요즘 느끼는 또 다른 문제는 토큰 소모 속도다. 예전에는 한 달간 사용해도 토큰이 꽤 남아 있었는데, 지금은 하루 이틀만 작업해도 거의 다 소진된다.

느낌으로는 빠르게 줄어드는 정도가 아니라 거의 증발한다는 표현이 더 맞는 것 같다. AI를 이용해서 코드 작성, 수정, 검토를 반복하다 보면 생각보다 훨씬 빠르게 토큰이 사라진다. 그래서 이제는 AI에게 모든 과정을 계속 맡기기보다, 필요한 부분을 더 좁게 정해서 요청하는 방식도 고민해야 할 것 같다.