brunch

You can make anything
by writing

- C.S.Lewis -

by AceProject Sep 06. 2018

의미 있는 개발을 하자

에이스프로젝트 데브컬쳐

개발자는 왜 항상 바쁠까. 이렇게 바쁜데 워크와 라이프의 밸런스는 어떻게 맞추며, 보다 나은 개발자가 되기 위한 '계발'은 언제 한단 말인가. 아마 현업에 종사하는 모든 개발자의 고민일 것이다. 에이스프로젝트 개발팀 역시 늘 바빴고 예전만큼은 아니지만 지금도 바쁘다. <에이스프로젝트 데브컬쳐 : 의미 있는 개발을 하자>에서는 바쁘기 때문에 해야 하는 고민, 바쁘지만 반드시 해야 하는 고민과 그 해결 방법에 대해 이야기해보고자 한다. 



기술에 빚지지 말자

만약 빚을 졌다면 빨리 갚자


기술 부채(Technical Debt)라는 개념은 워드 커닝햄(Ward Cunningham)이 처음 사용한 표현이다. 기술 문제에 봉착했을 때 근본적인 해결을 미루고 일정에 쫓겨 작업의 마무리를 우선순위로 두게 되는 것, 그래서 해결해야 하는 기술 문제들이 빚처럼 자꾸만 불어나는 것을 말한다. 이러한 기술 부채는 게임 개발에서도 흔하게 나타난다. 예를 들어 단순 작업을 반복하는 UI 구현 작업이 그렇다. 


UI 작업은 아래와 같은 프로세스로 진행된다.

1. 기획자와 상의를 마친 디자이너가 UI 컨셉을 잡고 리소스를 제작한다.

2. 툴 작업자가 툴을 이용하여 UI 툴작업을 한다.

3. 프로그래머가 코딩하여 UI 구현을 마무리한다. 


프로세스만 보면 깔끔하다. 개발자는 1, 2번은 크게 신경 쓸 것이 없고 3번도 그리 어려워 보이지 않는다. 그런데 어디서 기술 부채가 발생한다는 걸까. 초기 디자인 컨셉대로 리소스를 제작하고 계획했던 대로 배치해도 실제 구현 후 플레이를 해보면 예상하지 못한 문제점들이 발견된다. 그것도 한두 가지가 아니다. 이때부터 기획자와 디자이너로부터 잦은 수정 요청이 들어온다. 개발자들은 대개 사소한 변경이라고 생각하고 요청이 들어오면, 건건이, 그때그때! 하드코딩으로 대응하는 일이 생기는데 바로 이 과정에서 기술 부채가 발생한다. 



언제까지 단순 반복되는 UI 구현에 시간을 할애할 것인가?

방법을 찾아야 한다


UI 개발의 목표는 정해져 있다. 기획자와 디자이너가 원하는 형태로 UI가 구현되는 것. 특수한 알고리즘이나 특별한 기술이 필요하지 않다. 즉 단순 UI 구현에 드는 공수가 적으면 적을수록 개발자는 중요한 로직과 알고리즘을 연구하거나 코드 퀄리티를 향상하는 데 집중할 수 있다. 

잦은 UI 하드코딩은 개발자의 건강을 해칠 수 있습니다


소모적인 UI 하드코딩, 일명 '노가다'를 피하는 방법은 분명 있다. 일단 디자이너가 손쉽게 작업할 수 있도록 UI 툴을 개발하거나 제공하고 자주 사용하는 UI 기능은 컴포넌트화해 재사용하면 된다. 그러나 현업의 개발자들은 당장의 일정에 쫓겨 툴, 컴포넌트 개발은 뒤로 미루고 하드코딩으로 그때그때 땜빵하기 일쑤다. 대개는 이런 식으로 기술 부채, 개발자가 갚아야 하는 빚이 조금씩 불어난다. 



UI 컴포넌트 개발을 시작했다

모두에게 이로운 개발자의 '빚 청산'


에이스프로젝트는 기술 부채를 점진적으로 해결하고자 UI 컴포넌트 개발을 시작했다. 우선 최대한 기획자와 디자이너가 알아서 UI 작업을 할 수 있는 환경을 만들기로 했다. 그렇게 만들어진 컴포넌트가 cs_switch_case이다. 

이미지 출처 : https://www.guru99.com/switch-java.html


예를 들어 선수의 컨디션을 표시해야 한다고 하자. 컨디션은 아주 좋음, 좋음, 보통, 나쁨, 아주 나쁨 5단계로 나뉘어 있고, 선수 컨디션 상태에 따라 선수카드에서 각각 다른 이미지를 보여줘야 한다. 


일반적인 경우에는 디자이너가 5개의 컨디션을 표시하는 이미지를 개발자에게 전달하고, 개발자는 switch-case 또는 if문 등으로 하드코딩을 할 것이다. 여기에 종류가 많아지면 많아지는 대로 또 하드코딩을 한다. 물론 파일명을 센스 있게 맞춰 손쉽게 만드는 방법도 있으나 이것 역시 다 개발자의 공수다. 


할 일이 왜 자꾸 늘어나지?


이런 작업도 개발자의 손을 거치지 않고 디자이너가 직접 할 수 있게 만든 컴포넌트가 cs_switch_case이다. 디자이너가 UI툴에 switch_case 컴포넌트를 넣어 각각의 case에 따른 UI작업을 직접 분기할 수 있다. 개발자는 switch_case에 변수 연결만 해놓으면 표시할 상태 종류가 많든 적든 신경 쓰지 않아도 된다. 이 외에도 반복적으로 사용하는 UI 기능은 최대한 컴포넌트화해 똑같은 걸 매번 구현하지 않도록 했다.



기획자, 개발자, 디자이너 모두에게 이로운 컴포넌트를 만들어 보자


컴포넌트 개발로 개발자의 단순 작업이 대폭 줄었다. 남는 시간에는 자연스럽게 설계와 코드 퀄리티 향상에 집중할 수 있었다. 프로젝트 일정에 쫓겨 기술에 빚지는 일 대신에 개발 퀄리티 업과 안정화를 선택한 것이다. 사실 컴포넌트화 하느라 일정이 얼마나 미뤄졌냐고 물으면 정확히 수치화해서 말하긴 어렵다. 다만 장기적으로 봤을 때 일정에서 그다지 손해를 본 것 같지는 않다는 게 내부적인 판단이다. 하드코딩 대응 시간이 매일 누적된다고 생각하면 말이다. 


디자이너들도 UI 컴포넌트를 적극 활용했다. 직접 수정과 확인 작업을 할 수 있기 때문에 개발자의 작업 완료만 기다리는 무의미한 시간이 사라진 것. 결론적으로 UI 컴포넌트 도입 후 모두에게 더 효율적인 개발 프로세스를 갖추게 되었다. 



의미 있는 개발을 하자


결국 개발자가 단순 노가다 작업을 피하고 중요도가 높은 작업에 몰두할 수 있어야 '더 좋은 게임'을 만들 수 있다. '의미 있는 개발'의 문제는 비단 지금 개발하고 있는 게임을 잘 만드는 것에서 그치지 않는다. 개발자 개개인의 성장과 관계가 있는 일이다.


에이스프로젝트의 개발 문화는 첫째, '의미 있는 개발을 하자'는 것이다. UI 구현도 물론 중요하다. 개발자의 커리어 단계 상 UI 구현을 거치는 시기도 필요하다. 그러나 앞으로 스페셜리스트로 성장하려면 단순 반복 개발에 시간을 너무 허비하면 안 된다. 기업의 입장에서도 마찬가지다. 당장의 일손이 달린다고 해서, 근본적인 문제를 해결하지 않고 'UI 구현할 클라이언트 개발자 채용'만 계속해서 내걸어서는 안 된다. 에이스프로젝트는 모든 개발자가 경력에 관계없이 의미 있는 개발을 하기 원한다. 그리고 그런 준비가 된 사람과 함께 일하고 싶다. 




<개발자와 디자이너를 이롭게 하는 UI작업> NDC 강연 바로가기

UI 작업 개선에 대한 자세한 설명은 NDC 리플레이에서 확인해 볼 수 있다




에이스프로젝트 데브컬쳐 칼럼은 효율적이고 합리적인 개발 문화, 더 나은 개발자가 되기 위한 노력과 그 과정에 대한 내용이 연재됩니다. 



writer. 클라이언트개발팀 디렉터 안현석





매거진의 이전글 문화를 '함께' 만든다는 것

매거진 선택

키워드 선택 0 / 3 0
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari
;