[ICCAS 2023] 'Pattern Breaker' 프로젝트 후기

gogori6565·2023년 9월 15일

ICCAS

목록 보기
2/2
  1. 프로젝트 간단 소개
  2. 개발 진행 시 어려웠던 점
  3. 좋았던 점 / 아쉬웠던 점

1. 프로젝트 간단 소개 📚

깃허브 주소 ✔ https://github.com/gogori6565/ICCAS-2023-1-ICCASTAIR

2. 개발 진행 시 어려웠던 점 😥

(👉 = 어떻게 해결하려고 노력했는가?)

#1 게임에는 변수가 많다는 것

게임 개발은 처음이었다. 다른 웹/앱 개발도 변수는 늘 존재하지만 유독 게임이라는 특성 상 '변수'를 고려해야 할 일이 많았던 것 같다. 아무래도 가장 사용자와 긴 시간 많은 상호작용을 교류하는 서비스이니 만큼 사용자의 행동 패턴을 예상하고 변수를 처리해야 할 일이 많아 고려사항이 많았던 게 처음에는 막막하게 느껴졌던 것 같다.

👉 그리하여 노션(Notion)에 게임 개발 프로세스를 정리해서 체계적으로 개발하였다. 이렇게 하니 빼먹는 기능도 없고 개발 과정이 뚜렷하게 보여서 개발 진행과정 속도가 균일하게 빨랐다.

#2 큰 용량 프로젝트의 깃허브 관리

이번 프로젝트를 계기로 팀 프로젝트 깃허브 관리하는 능력이 많이 오른 것 같다. 내 깃허브에 레파지토리를 파서 관리하기 위해 브랜치를 나눠서 main(master)으로 병합하는 브랜치 전략에 대해 공부하고 팀원들과 개발을 진행하면서도 같이 깃허브에 대해 많은 공부를 진행하였던 게 도움이 되었다.

깃허브 관리에서 부딪혔던 문제 중 기억에 남는 것은 '대용량 프로젝트 관리'였다. 게임 특성 상 용량이 크기 때문에 기존의 레파지토리를 관리하던 방식으로는 대용량 파일을 관리할 수 없었다. (Github에서 Push 할 때는 50MB부터 Warning을 표시하고 100MB부터 Error가 발생)

👉Git LFS (Large File Storage) 라는 기능을 사용하였다. Git LFS는 대용량 파일을 별도의 서버에 올리고, 원래 위치에는 포인터를 남긴다. 즉, 파일은 서버에서 받지만 포인터 덕분에 pull, push를 정상적으로 진행할 수 있게 하는 기능이다.

#3 파이어베이스와의 동기/비동기 처리

'분명 연동을 성공해서 가져왔는데 왜 일부는 가져오고 일부는 못가져오지?' 개발 중에 속으로 가장 많이 했던 질문이다.

파이어베이스는 데이터 입력/가져오기 시 동기/비동기 를 고려해야한다.
코드 순서대로 작동하는 기존의 C 방식과는 달리 데이터가 완전히 이동되었을 때 다음 함수/변수가 실행되게 순서를 생각해서 짜야하는 게 어려웠다.

👉 사실 파이어베이스의 '동기/비동기'의 존재를 알았다는 것이 그 모든 문제들의 해결이라고 말할 수 있겠다. 그때그때 코드의 진행 조건에 따라 다르게 해결을 했지만 주로 검색 결과 해결방법은 async await을 적절히 사용하는 것이었다.

비동기를 포함한 함수 앞에 async를 붙여주고 비동기로 진행되는 함수 앞에는 await을 붙여주면 비동기의 결과값을 얻은 후에 다음 단계가 진행된다.


3. 프로젝트 하면서 좋았던 점 / 아쉬웠던 점 😉

좋았던 점

#1 적극적인 팀원들과의 협력

프로젝트를 성공시킬 의지를 가지고 지원하여 합격한 사람들과 모여서 프로젝트를 진행하여 다들 열심히 프로젝트에 임해주었던 게 가장 좋았던 기억이다.

무엇보다 의도적으로 다른 학교, 다른 과로 팀을 구성하여 프로젝트를 시작했음에도 불구하고 모두 열정적으로 그리고 배려심 넘치게 서로 협력하여 주어서 그 부분이 좋았고, 막내임에도 불구하고 팀장을 맡은 나를 잘 따라와주고 응원해준 팀원들에게 고맙다.

앞으로의 프로젝트들도 이렇게 자기 스스로 열심히 하고자하는 의지를 가진 팀원들과 일하고 싶다.

#2 큰 경험을 얻다 (개발의 모든 프로세스를 경험해 본 것)

EKC2023 포스터 발표장에서 심사위원 한 분이 이렇게 말씀하셨다. '취직해서도 개발의 모든 프로세스를 경험해보는 게 쉽지 않다. 이번 프로젝트가 굉장히 큰 경험인 것이다.'

계획, 분석, 설계, 구현, 테스트(사용자 테스트는 못했지만) 까지. 프로젝트가 완성되기 까지의 모든 과정을 경험해보고 가장 크게 깨달은 것은 <사용자 경험(UX)을 디자인하는 것의 중요성>인 것 같다. 단순히 기막힌 아이디어, 완성도 높은 개발이 제품(혹은 비즈니스) 성공에 영향을 끼치는 것이 아니라 얼마나 대상이 되는 사용자가 이해하고, 즐기고, 유용하게(도움이 되게) 사용할 수 있을까에 집중해서 개발을 진행하는 것이 제품의 완성도를 높이는 방법임을 깨달았다.

IT 분야는 나아갈 수 있는 직업이 정말 많다. 내가 앞으로 어떤 직업을 가지게 될 지는 아직 모르지만 어떤 직업(IT분야)을 가지게 되어도 이번 경험이 그 일에 도움이 되는 경험적 지식을 얻게 해주었다고 생각한다.

아쉬웠던 점

#1 실제 사용자 테스트의 어려움

의료용 기능성 게임으로서 대상자는 '환자'이고, 우리 게임의 대상자는 '강박증 환자'이다. 일반적인 게임이라면 아는 사람들에게 테스트를 부탁하면 되지만 이 게임은 대상자가 뚜렷해 환자의 피드백이 필요했고 그렇기에 테스트에 한계가 있었던 게 아쉽다.

실제 환자들에게 적용해보고 피드백을 받아 게임을 발전시켰으면 더 의미있는 프로젝트가 되었을 것 같다.

#2 '디지털 치료제'라는 주제에 부딪힌 전문적인 한계

마찬가지로 '의료용' 게임이라는 것이 목적이기 때문에 우리의 개발적 전문지식으로는 게임에 채울 수 없는 '의학 지식'이 필요했고, 그것이 부족하여 실제 '효과성'을 효과적으로 입증할 방법이 없었다는 것이 아쉬웠다.

피드백을 받을 때마다 혹은 평가를 할 때마다 '이게 그래서 치료 효과가 있어?' 라는 물음에 실제 의학적 판단(혹은 환자 테스트)이 있었다면 자신있게 '네!'를 외쳤겠지만 그럴 수 없었다는 게 아쉽다.

👉 대신에 그렇기에 이 게임의 의학적 치료효과를 최대한 증명해 내기 위해 뒷받침할 근거 자료(논문, 신뢰도 있는 의학 글)를 찾는 데에 많은 노력을 기울였다.

profile
나대로 열심히 하다보면 또 어딘가에 닿아있겠지 p(´∇`)q

0개의 댓글