필자는 직접 부딪히고, 많이 구현하고, 많이 실패했다!
그래서 아주 천천히 늘었다..
그 과정 자체가 의미 없지는 않았다.
천천히했기에 알게된 것도 많기 때문이다.
작은 노하우지만, 새로 배우는 사람들이 빨리 늘었으면 하는 마음에 작성한다.
ㅎ-ㅎ
일단 팩트는,
무작정 개발하는 것만으로는 생각보다 빨리 늘지 않는다...!
개발은 일이다. 공부가 아니다!!
새로운 장르를 개발하는 것은 공부와 개발이 겸한다고 할 수 있지만,
본인이 하는 작업이 대부분 UI, 시스템 보조라면 당장 주어진 일을 하는 것보다 조금 돌아가더라도 공부를 하는 것을 강력히 추천한다.
왜 무작정 개발만 해서는 한계가 빨리 올까
대부분 이렇게 작업한다.
- 일단 만든다
- 돌아가면 넘어간다
- 꼬이면 나중에 고친다
- 급하면 또 덧댄다
- 결국 코드가 무거워진다
이 방식은 초반에는 빠르다.
뭔가가 보이고, 작동도 하고, 성취감도 빨리 온다.
그래서 실력이 늘고 있다고 느끼기 쉽다. (일을 했다는 생각도 들고)
그런데 프로젝트가 조금만 길어지면 문제가 생긴다.
(진짜 무조건 생긴다 진짜루)
- 기능 하나를 바꾸면 다른 기능이 깨진다
- 어디를 고쳐야 할지 감이 잘 안 온다
- 코드가 점점 읽기 싫어진다
- 리팩토링이 무서워진다
- 다시 만드는 편이 더 빠르다는 생각이 든다
이쯤 되면 사실 구현 경험은 쌓였는데,
정작 구조를 보는 눈은 충분히 자라지 않은 경우가 많다.
개발 실력은 단순히 많이 만든다고 느는 것이 아니라,
왜 이렇게 만들었는지 설명할 수 있을 때 훨씬 빠르게 는다.
누구나 다 아는 얘기
이제는 AI가 대부분의 작업을 해줄 수 있다.
- 보일러플레이트 작성
- 반복 코드 생성
- 기초적인 시스템 초안 작성
- 리팩토링 방향 제안
- 특정 기능 구현 예시 제공
이 정도는 정말 빠르다.
그래서 그냥 결과만 보면, 개발자가 직접 하나하나 짜는 것이 비효율적으로 느껴질 때도 있다. (근데 진짜 비효율적인 것 같음)
그런데 여기서 아주 중요한 문제가 있다.
AI는 대신 구현해줄 수는 있어도, 대신 책임져주지는 않는다.
AI가 준 코드는 프로젝트 구조와 안 맞을 수 있고,
없는 클래스를 멋대로 가정할 수도 있고,
겉으로는 맞아 보여도 나중에 확장성이 망가질 수도 있다.
그래서 AI 시대일수록 더 중요한 것은 다음과 같다.
- 지금 내가 무엇을 만들고 있는지 명확히 설명하는 능력
- 기능의 책임을 나누는 능력
- 구조의 한계를 미리 떠올리는 능력
- 결과물이 맞는지 검증하는 능력
즉, 앞으로 더 중요한 개발자는
“코드를 오래 치는 사람”보다
잘 생각하고, 잘 지시하고, 잘 검토하는 사람이다.
그럼 진짜로 어떻게 해야 할까
여기서 가장 현실적인 질문이 나온다.
그래서 뭘 해 내가.
이 질문에 답하지 못하면, 아무리 좋은 말도 결국 공허해진다.
그래서 아래에는 내가 실제로 중요하다고 생각하는 방향을 최대한 현실적으로 정리해보려 한다.
1. 구조 공부를 따로 할 필요 없다.
구조 공부를 하라고 하면,
처음부터 아키텍처 책만 읽거나 거대한 설계론부터 파는 경우가 많다.
그런데 나는 이걸 아주 강하게 권장하지는 않는다.
재미가 없기 때문이다.
그리고 재미가 없으면 오래 못 간다.
구조 공부는 당장 하고 있는 프로젝트에 적용하는 방식이 제일 좋다.
예를 들어 어떤 기능을 만들기 전에,
먼저 엉성해도 좋으니 노드를 펼쳐서 다이어그램을 그려보는 것이다.
- 이 기능은 누가 입력을 받는가
- 어떤 데이터가 필요한가
- 어디서 상태가 바뀌는가
- UI는 어디까지 알아야 하는가
- 어떤 클래스가 어떤 책임을 가져야 하는가
정답처럼 완벽한 그림이 아니어도 괜찮다.
중요한 것은, 구현 전에 한 번이라도 구조를 머릿속에서 꺼내보는 과정이다.
아무리 생각해도 구조가 너무 어렵고 막막하다면,
그럴 때는 AI를 활용해도 좋다.
다만 “이거 해줘”로 끝내지 말고,
“이 구조를 짜기 위한 계획을 같이 세워달라”고 요청하는 편이 훨씬 도움이 된다.
조급하게 구현부터 들어가지 않았으면 좋겠다.
대부분 그렇게 시작한 코드는 결국 다시 쓰게 된다.
프로젝트가 길어질수록 이 리스크는 정말 커진다.
더 이상, "내가 짠 게 아니라..AI가.." 라는 말은.. 하지 말자..
2. 디자인 패턴도 적당히
디자인 패턴을 먼저 깊게 파야 하나 고민하는 사람도 많다.
내 생각은 비교적 단순하다.
아무것도 모른다면,
잘 정리된 포스트 하나 정도 읽는 것으로도 충분하다.
처음부터 패턴 자체를 목적으로 공부하면,
현실 프로젝트에 어떻게 적용해야 하는지 잘 안 보일 때가 많다.
그래서 나는 보통 이렇게 권하고 싶다.
- 패턴은 아주 가볍게 훑는다
- 프로젝트를 먼저 만든다
- 만들다가 “아, 이런 상황에서 이 개념이 필요했구나”를 느낀다
- 그때 다시 돌아가서 정리한다
이 흐름이 훨씬 오래 남는다고 생각!
3. 유니티를 잘하려면?
유니티를 잘하고 싶은데 C#을 먼저 파야 하는지,
아니면 유니티 기능을 먼저 익혀야 하는지 묻는 질문도 정말 많다.
내 생각은 둘 중 하나만 고르는 방식은 좋지 않다.
AI가 도출한 C# 코드를 이해하지 못한다면,
결국 개발의 제어권을 가져오기 어렵다.
그렇다고 C# 문서를 처음부터 끝까지 달달 외우는 것도 비효율적이다.
그래서 추천하는 방식은 이렇다.
- 필요한 기능을 먼저 정한다
- 직접 구현하거나 AI와 함께 구현해본다
- 모르는 문법이 나오면 그때 정리한다
- 동시에 유니티 쪽 기능과 컴포넌트도 같이 배운다
유니티는 엔진 이해도가 생산력 차이를 크게 만든다.
그래서 모르는 기능이 있을 때는 AI에게 이렇게 물어보는 것도 좋다.
“이 기능을 만들 건데, 도움이 될 만한 Unity 컴포넌트나 세팅이 있을까?”
이 질문 하나만 잘 해도,
쓸데없이 직접 구현하다가 돌아가는 시간을 꽤 줄일 수 있다!! 진짜임!!
4. 문법은 아는데 구조가 약하다면, 문제 해결 훈련이 필요할 수 있다
문법은 꽤 아는데 구조가 잘 안 잡히는 사람도 많다.
이 경우에는 단순히 패턴을 더 보는 것으로 해결되지 않을 때가 있다.
왜냐하면 구조를 생각하는 힘은 결국
문제를 나누고, 조건을 보고, 흐름을 예상하는 힘과 연결되기 때문이다.
나는 이런 경우
간단한 알고리즘 문제 풀이도 꽤 도움이 된다고 생각한다.
여기서 중요한 것은 고난도 알고리즘을 정복하라는 뜻이 아니다.
오히려 간단한 문제라도 좋다.
- 입력과 출력이 무엇인지 파악하기
- 조건을 분리하기
- 예외 케이스를 생각하기
- 해결 순서를 정리하기
이런 연습은 구조를 생각하는 습관과 꽤 닮아 있다.
문제 해결 능력은 결국 개발 전체의 기반이 된다.
5. 성장 여부는 정량적으로 잘 안 보일 수도 있다
혼자 공부하다 보면 이런 생각이 든다.
내가 진짜 늘고 있는 게 맞나?
솔직히 말하면, 이건 꽤 애매하다.
명확한 점수처럼 보이지 않을 때가 많다.
그래도 내가 느끼기에는 성장의 신호는 분명 있다.
- 예전보다 코드를 덜 무서워하게 된다
- 처음 보는 코드도 조금씩 읽힌다
- 막혀도 완전히 멈추지 않고 다음 행동을 떠올릴 수 있다
- “하니까 되네”라는 감각이 생긴다
이 자신감은 생각보다 중요하다.
다음 단계로 넘어갈 때 필요한 에너지가 되기 때문이다.
6. 구현 전에 생각하는 시간은 아깝지 않다
예전에는 구현과 설계의 비중을 8:2 정도로 생각했다.
당시에도 스터디를 진행하면 "헤엑-"하는 리액션이었는데..
지금은 조금 과장해서 말하면,
구현 전에 9.9까지 생각해도 괜찮다고 생각한다.
특히 지금은 AI와 함께 사고를 확장할 수 있다.
내가 문제를 던지고, AI가 가능한 구조를 제안하고,
그걸 보면서 다시 내가 반박하거나 수정할 수 있다.
이 과정을 충분히 거치면 구조는 훨씬 선명해진다.
그리고 그렇게 나온 코드는 결국 내 것이 된다.
생각을 오래 했다고 해서 느린 게 아니다.
나중에 다시 쓰는 시간을 줄였다면, 오히려 훨씬 빠른 것이다!
7. 작은 기능도 결국은 설계가 필요하다
“큰 기능은 설계해야 하는 거 알겠는데, 작은 기능도 그래야 하나요?”
내 생각은 예스예스다.
큰 기능이든 작은 기능이든, 결국은 설계가 필요하다.
다만 거창하게 할 필요는 없다.
큰 기능은 뼈대를 먼저 설계하고,
그다음 모듈 단위로 나누면 된다.
그리고 그렇게 나뉜 작은 기능도 최소한 이 정도는 명세해야 한다.
- 어떤 기능이 들어가는가
- 어떤 입력을 받는가
- 어떤 결과를 내는가
- 어디까지를 책임지는가
즉, 작은 기능이라고 해서 생각 없이 만들 수 있는 것은 아니다.
작을수록 더 명확하게 정의하는 습관이 중요하다.
8. “일단 만들고 나중에 리팩토링”은 맞지만, 아무 생각 없이 만들라는 뜻은 아니다
이 부분은 오해가 생기기 쉬워서 조금 조심해서 말하고 싶다.
나는 “일단 만들고 나중에 리팩토링” 자체는 좋은 방식이라고 생각한다.
특히 초반부터 너무 일찍 세부 리팩토링에 들어가면
오히려 확장성이 막히거나, 기획 변경에 취약해질 수도 있다!
하지만 이 말이
“구조를 생각하지 말고 일단 막 만들어라”는 뜻은 전혀 아니다.
정리하면 이렇게 보는 편이 맞다.
- 구현 전에 뼈대와 책임은 생각한다
- 세부 구현은 일단 굴려본다
- 실제로 써보면서 불편한 지점을 찾는다
- 그다음에 리팩토링한다
즉,
설계는 먼저, 과한 정리는 나중
이 정도 감각이 현실적으로 좋다고 생각한다.
9. 어디까지 분리해야 하는지는 결국 경험으로 익힌다
분리하라고 하면 또 이런 질문이 생긴다.
어디까지 쪼개야 과한 게 아닌가요?
이건 정말 경험의 영역이 크다.
처음부터 정답을 맞히기 어렵다.
그래서 오히려 초반에는
될 수 있을 때까지 잘게 쪼개보는 연습도 도움이 된다.
그러다 보면 어느 순간 느껴진다.
- 여기서 더 쪼개면 오히려 흐름이 끊긴다
- 여기까지는 나누는 게 편하다
- 이 둘은 결국 같이 움직인다
- 이건 분리했더니 관리가 쉬워졌다
그렇게 하나씩 감각이 쌓인다.
결국 중요한 건, 남이 정한 절대 기준보다
내가 왜 나눴는지 설명할 수 있는가다.
일단 좀 쪼개고 생각하자..
코드 열어봤는데 2천줄이면 눈물난다.
10. 클래스가 책임이 많은지 판단하려면, 이름과 실제 역할이 맞는지 보자
클래스가 너무 많은 책임을 지고 있는지 헷갈릴 때는
생각보다 단순한 기준이 도움이 된다.
이 클래스의 이름과 실제 하는 일이 어울리는가?
이 질문만 해도 꽤 많은 것이 보인다.
예를 들어 이름은 PlayerMotor인데
- 입력도 받고
- 이펙트도 재생하고
- 체력도 깎고
- 애니메이션도 바꾸고
- UI도 갱신한다면
이건 이름과 책임이 이미 맞지 않는 경우다.
특히 Manager, Controller 같은 이름은 조심해야 한다.
이름 자체가 넓어서, 마음만 먹으면 뭐든 우겨 넣을 수 있기 때문이다.
내가 선호하는 기준은 이렇다.
Manager는 절대 무거워지지 않는 편이 좋다Controller는 여러 기능을 라우팅하는 정도가 적당하다
예를 들어
PlayerMotor, PlayerEffect, PlayerAttack이 있고,
PlayerController가 그 흐름을 조율하는 정도라면 비교적 납득 가능한 구조다.
11. 유니티에서는 UI와 게임 로직을 처음부터 분리하는 편이 좋다
UI와 게임 로직을 언제부터 분리해야 하냐는 질문에는
나는 꽤 단호한 편이다.
처음부터 분리하는 편이 좋다.
UI는 보여주는 역할에 가깝고,
게임 로직은 상태를 바꾸는 역할에 가깝다.
이 둘이 섞이기 시작하면 수정할 때 정말 피곤해진다.
특히 유니티에서는 UI가 쉽게 로직을 먹어버린다.
버튼 이벤트 하나에서 이것저것 다 처리하다 보면
나중에는 화면을 바꾸는 코드인지, 게임을 바꾸는 코드인지 구분이 안 되기도 한다.
처음부터 완벽할 필요는 없지만,
최소한 UI는 표현 쪽, 로직은 데이터와 상태 쪽이라는 감각은 유지하는 게 좋다.
미리 연습해서 버릇을 들여놓는 것이 좋다.
이제 PlayerHpBar가 PlayerHP를 들고있는..... 실수(?)는 하지말자..ㅠ
12. ScriptableObject는 아주 좋은 도구지만, 런타임 데이터와 혼동하면 위험하다
ScriptableObject는 유니티에서 정말 유용한 도구다.
그래서 나는 꽤 자주 쓰는 편을 권한다.
특히 이런 경우에 잘 맞는다.
- 변하면 안 되는 설정값
- 데이터 테이블
- 정의 목록
- 프리셋 성격의 값
다만 주의할 점도 분명하다.
ScriptableObject는 보통 변하면 안 되는 데이터 컨테이너처럼 쓰는 경우가 많다.
그래서 런타임에 이 값을 직접 바꾸는 습관은 정말 조심해야 한다.
즉, SO는 잘 쓰면 강력하지만
“현재 상태”와 “정적 정의”를 헷갈리면 오히려 큰 실수가 된다.
13. 매니저가 많아지는 구조는 대체로 조심하는 편이 좋다
혼자 작업할 때는 싱글톤과 매니저가 정말 매력적으로 느껴진다.
어디서든 접근 가능하고, 빠르게 개발할 수 있기 때문이다.
그런데 프로젝트가 길어질수록
가장 먼저 규칙이 무너지기 쉬운 곳도 이런 구조다.
- 이 매니저도 저걸 안다
- 저 매니저도 이걸 바꾼다
- 서로 참조가 꼬인다
- 결국 누가 진짜 책임자인지 모호해진다
그래서 나는 매니저가 많아지는 구조를 그다지 선호하지 않는다.
특히 장기 프로젝트라면 더 그렇다.
매니저가 필요 없다는 말은 아니지만,
쉽게 만들 수 있다고 쉽게 늘리면 나중에 관리가 무너질 가능성이 크다는 건 꼭 기억해두면 좋겠다.
14. AI가 코드를 짜준다고 해서, 꼭 내가 다 직접 구현해봐야 하는 것은 아니다
이제는 이런 질문도 자연스럽다.
AI가 코드를 짜주는데, 굳이 내가 하나하나 구현해봐야 하나요?
솔직히 말하면,
반드시 그럴 필요는 없다고 생각한다.
예전처럼 모든 걸 손으로 처음부터 끝까지 작성하는 경험만이 정답은 아니다.
지금은 더 효율적인 방법이 분명 존재한다.
다만 정말 중요한 전제가 있다.
구조를 모르는 것은 큰 문제다.
내가 직접 다 타이핑하지 않았더라도,
- 이 코드가 왜 필요한지
- 어디에 붙는지
- 어떤 책임을 가지는지
- 나중에 어디서 터질 수 있는지
이 정도는 이해하고 있어야 한다.
즉, 직접 구현을 안 할 수는 있어도
직접 판단은 할 수 있어야 한다.
15. AI에게는 “기능”만이 아니라 “규칙”도 같이 줘야 한다
AI에게 일을 시킬 때 결과가 들쭉날쭉한 이유는
대부분 요구사항이 흐리기 때문이다.
단순히 “이 기능 만들어줘”보다
아래를 같이 명세하는 편이 훨씬 좋다.
- 어떤 기능을 원하는지
- 어떤 클래스 구조를 유지해야 하는지
- 어떤 컴포넌트를 써야 하는지
- 어떤 것은 하지 말아야 하는지
- 기존 코드와 어디까지 맞춰야 하는지
즉, AI에게는 기능만 주는 게 아니라
작업 규칙과 금지사항까지 같이 주는 습관이 중요하다.
16. AI가 준 코드가 맞는지 보는 기준도 결국 구조다
AI가 준 코드가 맞는지 틀린지 판단하는 기준은
결국 구조를 아는가에 달려 있다고 생각한다.
구조를 이해하고 있다면,
- 이 책임이 왜 여기에 있지?
- 이건 UI가 알 필요가 없는데?
- 이 클래스가 너무 많은 걸 하는데?
- 이 참조 방향이 이상한데?
이런 위화감이 비교적 빨리 보인다.
반대로 구조 감각이 없으면,
겉으로 돌아간다는 이유만으로 그대로 붙이기 쉬워진다.
그래서 결국 공부는 더 중요해진다.
17. AI를 잘 쓰는 개발자와 그냥 복붙하는 개발자의 차이
재미있게도, AI를 잘 쓰는 개발자도 결국 복붙은 한다.
차이는 복붙 그 자체가 아니라,
그걸 이해하고 관리하느냐에 있다.
- 왜 이 구조인지 알고 붙이는가
- 어디까지 믿고 어디부터 검증할지 아는가
- 프로젝트 규칙 안에 맞게 통제하는가
- 문제 생겼을 때 원인을 추적할 수 있는가
이 차이가 정말 크다.
그냥 “일단 해”라고 던지는 것과,
구조를 알고 책임을 쥔 채 활용하는 것은 전혀 다르다.
마무리
당장 급한 일을 처리하기 위해서 많은 업무량을 처리하는 것은 장기적으로 봤을 때 본인에게 그리고 무엇보다 팀에게 좋지 않다.
차라리 "나 공부해야 해서 업무량 조절해줘"라는 것이 내게는 더 도움이 된다.
(물론 저 스탠스는 팀바팀이라.. 정답처럼은 말 할 수 없어도 적어도 내가 조타를 잡고 있는 팀에서는 저렇게 말해주면 오히려 고맙다.)
예전보다 코드를 덜 무서워하게 된다
처음 보는 코드도 조금씩 읽힌다
막혀도 완전히 멈추지 않고 다음 행동을 떠올릴 수 있다
“하니까 되네”라는 감각이 생긴다
뭐야 이거 나잖아?
넌 이제 조만간이다