오늘은 프로젝트 발제가 있는 날이었다. 아침부터 약간의 긴장감과 함께 어떤 주제가 나올지 기대가 되었다.
결과적으로, 나는 베이직 반이라 'ATM 프로젝트'를 맡게 되었다.
사실 평소 UI 쪽에 자신이 없다고 느꼈기에, 이번 기회가 반갑게 느껴졌다.
어쩌면 나에게 필요한 부족함을 채우기 위한 딱 맞는 과제가 아닐까 싶었다.
문제 상황 (Trouble)
가장 먼저 느꼈던 고민은 "어디서부터 구조를 잡아야 할까?" 였다.
단순히 버튼을 눌러 숫자를 바꾸는 UI가 아닌,
실제 유저 데이터를 기반으로 실시간으로 연동되고,
입출금과 저장까지 매끄럽게 이어져야 한다는 점에서 부담감이 있었다.
시도했던 것 (Attempt)
우선 UserData라는 클래스를 만들어 사용자의 이름, 현금(cash), 잔액(balance)을 담는 구조로 시작했다.
그리고 GameManager에 이 데이터를 초기화해두고, PopupBank라는 UI 컴포넌트에서 정보를 실시간으로 보여주게 했다.
그 다음부터는 아래와 같은 흐름으로 차근차근 기능을 구현해갔다:
- UI 연결 및 실시간 갱신
- Update() 루프를 사용해 변화가 생기면 UI가 바로 반영되도록 했고,
- Refresh() 함수를 통해 텍스트 갱신을 통합 관리했다.
- 입출금 기능 구현
- 정해진 금액뿐 아니라 직접 입력한 금액도 처리 가능하도록 설계했고,
- 잘못된 입력에 대한 오류 팝업 처리도 함께 구현했다.
- 데이터 저장/불러오기 기능
- GameManager에 저장 경로를 지정하고, JSON으로 유저 정보를 저장하도록 했다.
- 입출금 시 자동 저장되도록 연결해 실제로 값이 바로 반영되게 구성했다.
- 로그인 기능 확장
- PopupLogin을 새로 만들어 ID/PW 입력으로 유저 인증을 구현했다.
- UserData 구조에 userID, password 필드를 추가하면서 로그인 후 UI 전환도 적용했다.
- 리팩토링
- 유저 데이터를 직접 GameManager에서 다루던 방식을 걷어내고,
- UserDataManager 클래스를 도입해 책임을 분리했다.
- UI 쪽 접근도 전부 이 매니저를 통해 다루도록 수정했다.
해결 방법 (Solution)
구조적인 관점에서 가장 만족스러웠던 부분은 "UserDataManager 도입"이었다.
처음에는 GameManager.Instance.userData.~~ 방식으로 접근했지만,
프로젝트가 커질수록 이 구조는 강한 결합도 때문에 유지보수가 어려워질 수 있다는 판단이 들었다.
그래서 데이터를 저장하고 불러오는 책임을 따로 분리하면서
역할 분담이 명확해졌고,
기능 확장성도 좋아졌다.
알게 된 것 / 느낀 점 (Learning)
오늘의 가장 큰 수확은 "UI는 단순해 보여도 데이터 흐름을 설계하는 데 꽤 큰 고민이 필요하다"는 걸 체감한 점이다.
단순한 입출금 기능 하나를 구현하는 데도
- 데이터의 흐름이 어떻게 이동하고
- UI에 어떻게 반영되며
- 저장/불러오기까지 이어지는지에 대한 전반적인 설계가 있어야
제대로 동작한다는 걸 실감했다.
또한, 실시간 UI 갱신이나 자동 저장, 로그인 같은 기능들을 직접 구현하면서
"사용자의 행위가 시스템에 어떻게 반영되는가"를 고민할 수 있었고,
단순히 버튼을 눌러 값이 바뀌는 걸 넘어서
진짜 '사용자 경험'을 다루고 있다는 감각이 생겼다.
오늘도 조금은 더 개발자다워졌다는 기분이 든다.
내일은 이 시스템 위에 더 풍부한 사용자 흐름을 쌓아갈 수 있기를.
내일 할 일
1. PopupBank.cs 리팩토링
- Update()에서 매 프레임마다 비교하는 구조를 최적화
- UserDataManager의 이벤트 시스템 도입 고려 (OnCashChanged, OnBalanceChanged 등)
- Refresh() 호출 시점을 더 명확하게 설계하고, UI 갱신 책임 분리 검토
2. 회원가입 화면 UI 만들기
- 신규 UI 패널 PopupRegister 생성
- ID / PW / 이름 / 시작 금액 입력 필드 배치
- UserDataManager를 통한 신규 계정 생성 및 저장 처리 연결
- 로그인 화면 ↔ 회원가입 화면 전환 버튼 추가
3. 데이터 시스템 손보기
- UserDataManager 내부 구조 점검
- 여러 유저 지원 고려 시, List<UserData> 기반 구조 준비
- 파일 이름 분리 (user_{id}.json 또는 users.json 구조 고려)
- 불러오기 시 직렬화 오류 방지 처리 및 백업 저장 옵션도 고려해보기
'TIL' 카테고리의 다른 글
| TIL 67일차 - 흩어졌던 책임을 정리하며, 다시 쓰는 뼈대 (0) | 2025.06.06 |
|---|---|
| TIL 66일차 - 혼자 만든 설계 vs 요구된 설계: 그 사이의 리팩토링 (1) | 2025.06.05 |
| TIL 64일차 - "준비된 자의 코드" (0) | 2025.06.03 |
| TIL 63일차 - 무기력과 책임 사이에서 피운 성장 (1) | 2025.06.02 |
| TIL 62일차 - 오늘은 힌트 시스템과 캐릭터 모션에 집중했다 (1) | 2025.05.30 |
