"구조 잘 짜는 사람이 코딩도 잘 하긴 한다."
클러스터링 기법
의존성 높은 기능들을 논리적인 단위로 쪼개는 방법이라고 한다.
흔히 알고있는 객체별로 기능을 나누는 것이라고 보임.
SOLID를 아는 개발자는 평소에 해오던 방식이다.
구현할 기능을 나눔으로써 AI가 부분에 집중하는 것에 도움을 준다. (할루시네이션 감소)
개발자가 해야 할 것은 큰 기능(Player, Enemy등)을 정의하고, 작은 기능들로 나누어서 설명해내는 것이다.
물론 이것도 AI에게 맡길 수 있다면 좋겠지만 나로서는 아직 좋은 방법이 떠오르진 않는다.
게임에선 여러 클래스가 하나의 대상을 구성하기 때문에 더 중요하다고 볼 수 있다.
이 과정이 시간이 좀 걸리고 이 과정조차도 AI에게 맡기면 좋겠지만, 우선은 구조화 능력을 키우기 위해선 직접 하는게 좋다고 생각한다.
직접 디버깅 하는 스킬도 앞으론 계속 중요하겠지만(메모리의 데이터를 직접 보는 경우가 종종 있음), 일어날 오류의 종류를 미리 파악해놓고 테스트 코드를 만들어놓게 하는 능력도 중요할 것 같다.
유니티 개발자 취업
신규 채용이 줄어들고 있긴 하지만, 게임 시장에서의 점유율은 아직 상당하다.
게임이 많이 나오는 만큼 그 게임을 유지시키는 것에도 사람이 계속 필요할 것이라고 생각은 된다.
(호황은 아니라서 취업난은 계속될 것 같다.)
동시에 작금 필요한 인재상은 1년 사이에 많이 바뀌었다고 생각한다.
코드만 잘 작성하는 개발자를 더 이상 필요로 하지 않는다.
코드는 AI 에이전트들이 시니어만큼 뛰어나게 잘 작성하기 때문.
AI에게 적절한 명령(ex)클러스터링)을 내리고, 예측 가능하고 안정적인 결과물을 내는 것이 중요해졌다.
속도는 AI가 보장해주니 큰그림을 잘 그리는 사람이 필요해진 것.
(잘 생각해보면 구조 잘 짜는 사람이 코딩도 잘 하긴 한다.)
자신도 예측하지 못하는 결과물을 내는 개발자가 필요할까,
아니면 구조를 설계하고 그 구조대로 결과물까지 내는 개발자가 필요할까...
최적화 지식이 아직은 중요하다고 생각한다.
물론 최적화도 언젠가는 AI가 가져갈 영역이겠지만 아직은 개발자가 지녀야할 기본 소양이라고 생각한다.
자신이 설계한 구조의 어느 곳에서 누수가 나는지 알아채는 사람.
그래픽 렌더링에서 마음에 들지 않는 부분을 캐치할 수 있는 사람이 필요하다.
결국 개발자로서 가져야할 태도는 예나 지금이나 변하지 않았다.
자기가 뭘 만드는지 알고있고 새로운 흐름에 어떻게든 타고들어가는 것.
클러스터링 어떻게 적용하나?
적용하는 좋은 방법이 있는지도 궁금해져 몇 가지를 제미나이에게 물어봤다.
클러스터링의 예시를 알고싶어. 어떤 형태로 나오는지도 알고싶음. 사람들이 만든 결과물들 조사해서 알아봐봐.
클러스터링의 예시
제미나이가 알려준 예시를 요약하면 아래와 같다.
클러스터링 예시 (플레이어 설계)
클러스터: 입력
역할: 유저 키보드 마우스 입력값 감지 및 변수 저장
형태: InputSystem 기반 스크립트
클러스터: 이동
역할: 캐릭터 위치 이동
형태: 일반 컴포넌트흔히 말하는 간단한 설계문과 같다.
내가 이해한 클러스터링은 하나의 큰 기능을 나눠지지 않는 여러개의 클래스로 구분하는 것이다.
요지는 '하나의 작은 기능'의 범위를 간단히 개념화하는 것.
클러스터는 클래스에 대한 최소 묶음이고 방향성이기 때문에 최대한 간결하면 좋겠다.
기능의 자세한 내용은 구현 계획에 작성하면 된다.
하나의 폴더에 각 클러스터의 md 파일을 만든다거나,
하나의 md 파일에 클러스터를 여러개 두어야겠다.
에이전트의 부담을 줄이려면 player_cluster.md에 여러개 클러스터를 써놓는다거나 하면 좋지 않을까?
좀 더 자세하게
위에서 내가 생각한 것을 그대로 제미나이에게 전달해서 의견을 물어봣다.
판단을 필요로 한 두 부분은 적합하다고 판단해주었음.
요지는 '하나의 작은 기능'의 범위를 간단히 개념화하는 것.
클러스터링을 '무엇을 만드는지에 대한 범위의 경계선'으로 정의하고,
나눠지지 않는 클래스라고 한 것은 단일책임 원칙에 부합한다.
만드는 기능에 대한 최소한의 정의라고 하는 것도 적합하다.
대략적인 방향을 내가 작성(맡기거나)해서 상세 구현 계획에 쓰일 수 있겠다.
최대한 간결하면 좋겠다.
기능의 자세한 내용은 구현 계획에 작성하면 된다.
내가 말한 방식도 좋다고 하지만, 처음에는 모든 클러스터들을 한 md에 묶어주는 것이 좋다고 한다.
노션에 제목1 - 제목2,제목2 정리하듯이.
그런데 프로젝트 규모가 커지면 클러스터를 각 md로 분리하라고 한다.(의문)
클러스터는 애초에 간결할 수 밖에 없지 않나?
AI가 말한 것은 '전체클러스터.md'에 들어가는 클러스터 종류가 너무 많아지면 결국 나누는 것이 낫다는 것 같다.
이건 그냥 내 방식을 정하는게 나아보임.
아무튼 클러스터는 내가 작성하고 그것을 계획 단계에서 하나의 기능에 대한 명세서 md로 만들어달라고 명령하는 것이 나아보임.
그리고 계속 수정하고.
이외에도 @을 사용해서 쳐다볼 파일을 지정해준다거나, 메모리 뱅크 패턴을 사용하는 방법도 있다고 한다.
AI를 사용하지 않으면 제자리에 멈추는 것 같은 시대가 됐다.
취업도 안되는데 참 막막하고 길을 잃은 것 같은 심정이다.
그래도 좋게 생각하면 나처럼 작업 속도가 좀 느린 사람에게는 구조화에 좀 더 신경쓸 수 있는 시기가 온 것이 아닐까?
