부트캠프/본캠프

[내일배움캠프_2025SEP16] 1차 모의면접, DataManager 및 Data 관련 정립

Young_A 2025. 9. 16. 23:29

목차

    1차 모의면접, DataManager 및 Data 관련 정립

     

    오늘은 좀 구체적으로 눈에 띄는 작업은 하지 못할 것 같다.

    우선은 데이터 모델들을 정립하고 데이터베이스 관계를 정립해야한다.

    그 후 구현하고나서 이제껏 임시로 사용하고 있던 각종 임시테이블, 임시 데이터들을 정리하여 데이터베이스에서 뽑아 사용할 수 있도록 해야한다.

     

    마이너한 부분으로는 애니메이션 파라미터들을 상수로 변경하는 것.

    Run 애니메이션을 ChaseAction에 적용하고 이동방향에 따라 x축 변경을 하는 것이 필요하다.

    Node 추상화를 거친 애들을 abstract으로 다시 (new 키워드로 생성을 못하도록) 막아주는 작업도 필요하다.


    1차 모의면접

    생각보다 더 면접 같은 질문들을 많이 해주셔서 놀랐다.

    CS 예상 문제 범위를 집어주시길래 그 문제들만 테스트하실 줄 알았는데..

    그래서 더 좋긴 했다.

     

    아무튼 연습이 현저히 부족했고, 그래서 아쉬웠다.

     

    피드백은

    자기소개 시 장점들이 많다.

    해외 공부, 해외 개발 경력, 강점을 임팩트 있게 주는 방법을 고민해보면 좋을 것 같다.

    캐나다 가고 싶은가요? 에 가고싶슴니다! 는 너무 탈주하고 싶은 모양새. 파견근무가 있다면 자신있습니다. 정도로만.

     

    그리고 팀원들끼리 면접 후기를 공유하면서 나온 얘기는

    ~ 인 것 같습니다, ~라고 생각합니다는 너무 자신감이 없는 것 같다.

    팀원 분이 제안해주신 ~라고 이해하고 있습니다. 정도가 괜찮을 것 같다.


    직렬화를 이렇게 많이 사용해도 될까?

    현재 추상클래스를 [SerializeReference] 속성을 이용해 인스펙터에서 확인할 수 있게끔하는 바꾸고 있다.

    [Serializable] 속성을 부여하는 데,

    무엇이든 인스펙터에 보여지게끔 하는 방법들은 에디터 성능에 영향을 준다는 것을 인지하고 있었다.

     

    다만, 빌드 후 게임 플레이 성능에는 영향을 주진 않는지가 궁금했다.

    인스펙터에서 값을 변경하지 않고, 확인하는 용도로만 사용하려는데, 이로 인해 빌드된 게임의 성능까지 저하되는 것은 아닐지 궁금했다.

     

    정확히는, #if UNITY_EDITOR를 쓰는 것처럼, [Seriazliable]도 에디터에서만 작동하도록 조치를 취해야하는지 궁금했던 것 같다.

    에디터 환경 vs 빌드 후 런타임 환경 동작

    유니티 에디터는 [Serializable] 속성이 붙은 클래스의 필드를 읽어와 인스펙터 GUI에 실시간으로 렌더링한다.

    이 과정은 순전히 개발 편의를 위한 기능으로 데이터를 불러오고 화면에 그리는 오버헤드가 발생할 수 밖에 없다.

    따라서 클래스와 직렬화 대상이 많아질수록 이 오버헤드는 커져 에디터의 성능 저하를 일으킬 수 있다.

     

    게임이 빌드된 이후로는 인스펙터 창이 존재하지 않기 때문에 [Serializable] 속성은 데이터를 파일에 저장하고 메모리로 불러오는데 필요한 표식의 역할을 한다.

    에디터처럼 데이터를 화면에 그리는 과정이 없으니, 속성 자체로 인한 성능 저하는 거의 발생하지 않는다.

     

    따라서 [Serializable]은 주로 개발 단계에서만 성능에 영향을 미치며, 최종 빌드된 게임의 런타임 성능과는 직접적인 연관이 없을 것 같다는 결론을 내렸다.

    [Serializable] 속성의 두가지 역할은 분리되어있다.

    [Serializable] 속성이 가진 두가지 역할

    1. 에디터에서의 시각화(GUI) 기능
    2. 런타임에서의 데이터 직렬화(저장/로드) 기능

    들은 서로 분리되어있다.

     

    이로인해 에디터 성능과 빌드 후 성능은 별개라는 점을 이해할 수 있었다.

    개발 환경은 느려질 수 있으나 최종 게임의 성능까지 나빠지는 것이 아닐 수 있다.

    다만 인스펙터에서 보기만 할 용도라면 [Serializable]을 남용하기 보다는, 필요한 데이터만 [SerializeField] 혹은

    생각할 점

    앞으로 직렬화가 필요할 경우

    • 직렬화의 목적을 먼저 생각하기. -> 이 데이터가 에디터에서 수정/저장될 필요가 있는가?
    • 필요 최소한의 직렬화 지향하기 -> [SerializeField]를 이용해 특정 필드만 인스펙터에 노출하는 방식을 우선적으로 채택하기

    위와 같은 점들을 주의하며 진행하면 좋을 것 같다.


    DataManager 구조 설계 및 구현

    드디어 약간 숙원사업 같은.. 데이터 매니저를 정립했다.

    구현까지 진행했지만, 현재 기획테이블에서 생성된 데이터를 갖고있지 않기 때문에 그 부분은 내일 데이터 받아서 진행하면 된다.


    느낀점

    면접! 힘들었다!

     

    몬스터팀에 새로 합류한 팀원의 BT 이해도를 확인하기 위해 마치 선생님처럼 가르쳐달라고 했고, 이를 통해 이해도 확인할 수 있었다.

    더해서 내가 작성한 부분들을 알려드리는 부분도 있었는데, 알려드리면서 고치고 싶은 점들도 너무 많이 보였고, 무엇보다 내가 왜 이걸 이렇게 했더라??가 또 떠오르지 않아서 생각이 이리저리 휘둘리는 느낌이 들었다.

    어제 느꼈던 것처럼 "왜"라는 생각을 그때마다 정리해야하는데.. 쉽진 않겠지만 노력해보자.


    내일 학습 할 것은 무엇인지

    오늘 야근? 야작? 시간에 제작된 스킬 세개를 넣어서 돌려봤는데,

    생각해보니까 SkillSelectorNode를 따로 제작해서 Tick을 Override 해줬어야 했던 것 깜빡했다.

    현재 모든게 Reset되면서 모든 SkillSequenceNode들의 쿨다운이 한꺼번에 리셋되는 상황이 발견됨. Tick()에서 Reset을 빼야한다.

     

    오늘 못한,

    애니메이션 파라미터 상수 해시 값으로 처리하기.

    Run 애니메이션 (ChaseAction에 적용)과 좌우플립 구현하기.

    그리고 마이너한거긴 하지만 abstract SkillSequenceNode에서 Initialize를 생성자에서 호출한번 해주면 깔끔할 것 같다.

     

    그리고 시간이 남으면 Dash까지 하는 걸로!