회사를 옮기고나서 새로운 시도, 프로세스, 사람들과 일을 하고 있다. 1년 정도 새로운 프로세스를 적용하면서 느낀바가 커서 관련해서 정리를 준비하고 있었는데 홍민희님이 있는 스포카에서 굉장히 비슷한 시도를 하고 이를 경험한 디자이너가 정리한 글을 봤다. 디자이너 입장에서의 글이 나왔으니 나는 개발자 입장에서 느낀 바를 정리해 보곘다.

도입 동기

"커밋 권한 없이는 아무것도 할 수 없다."라는 생각을 개인적으로 오랫동안 가지고 있었다. 변화를 추구하는데 그 변화를 다른 사람의 손을 빌어서야만 달성할 수 있다면 좋은 결과를 보기 힘들 것이다. 개발 과정에서는 결과물을 직접 수정할 수 있다면 쉽게 해결할 수 있는 일을 누군가의 손을 빌어서 해야 하기 때문에 번거롭고 힘들게 진행되는 일들이 많다. 오픈 직전에 개발자한테 집중되는 엄청난 스트레스부터 QA의 부재로 생기는 테스트 공백까지, 실제 결과물에 접근할 수 있는 기회를 공유하고 확대한다면 보다 더 나은 품질의 제품을 만들 수 있을 것이라는 믿음이 있었다.

특히나 내가 있는 팀은 빠른 구현, 빠른 피드백을 모토로 삼고 있었기 때문에 같이 만든다는 생각에 대한 공감대가 이미 형성되어 있었다. 그래서 자연스럽게 협업에 대한 문제가 코드 커밋까지 연결이 되었다. 어느날 디자이너가 자신이 직접 디자인을 고칠 수 없겠냐는 질문을 해 왔고 그 즉시 모든 팀원에게 코드 작성 환경을 설정해 줬다. 일정이 바빠서 발생한 일이기는 하지만 나로서는 강요를 통해서가 아닌 스스로의 변화를 이끌어 냈다는 점에서 굉장한 성공이었다.

개발 환경 설치

애당초 모든 사람들이 코딩을 하는 모습을 꿈꾸고 있었기 때문에 최소한의 설정으로 개발 환경을 구축할 수 있게 아주 단순하게 개발 스펙을 잡았다. 개발 환경은 Apache + PHP고 데이터는 DB도 안쓰고 파일에 저장을 했다. 그래서 MAMP와 Github for Mac 설치하고 클론 받고 약간의 설정만 해주면 바로 개발 할 수 있는 환경이 갖춰졌다. 팀에서 제작하는 페이지의 특성도 단순한 환경 설정을 가능하게 해줬다. 윈도우에서 AP(M)과 Git을 설치하는데 좀 애를 먹었지만 큰 문제는 아니었다.

코드 저장소는 Git을 사용했고 master 브랜치를 개발 브랜치로 썼다. 사람들에게 Git 명령어는 하나도 안알려주고 Github 클라이언트에서 수정된 코드 diff를 보고 커밋 메시지 작성하고 싱크하는 정도까지만 알려줬다. 거창하게 코드 관리 전략을 이해하기 보다는 코드 수정에 집중하기를 바랬기 때문이다. 터미널을 열어야 하는 작업은 다 내가 직접 해줬다. 의외로 이정도의 지식만 가지고도 코드를 수정하고 공유하는데 문제가 전혀 없었다. UX 전문가인지 개발자인지 헷갈릴 정도로 코드를 빠르게 습득하는 팀 동료도 한몫했다.

도입 과정

우리팀은 4명이고 개발 1, 디자인 1, UX 2로 구성되어 있었다. 처음에는 디자이너가 서체 크기와 색상 변경하는 정도의 코드를 커밋했다. 사실 PSD로 디자인된 화면을 각종 기기에 올려보면 서체가 다르기 때문에 느낌이 조금씩 다르다. 그러한 부분을 실제 단말기에서 보고 직접 수정을 하니 훨씬 더 좋은 결과물이 나왔다.

UX 중 한명은 PM으로 콘텐츠 데이터를 주로 변경했고 다른 한명은 애니메이션과 화면 효과 등을 수정했다. 컴퓨터는 잘 다루지만 프로그래밍에 대한 경험이 없기 때문에 처음에는 시간이 좀 걸렸지만 나중에는 JS 라이브러리도 직접 찾아서 적용하고 효과가 괜찮은 라이브러리를 며칠씩 파더니 결국 직접 수정;;해서 프로젝트에 적용하기까지 했다.

서체를 수정하던 디자이너는 각종 여백이나 아이콘 이미지를 변경하기 시작했고 PNG 압축에 Data uri 변환까지 해서 CSS에 반영하게 되었다. 애니메이션 라이브러리를 적용하던 UXer는 CSS3 Keyframe Animation을 만들기 시작했고 각종 라이브러리를 수정하거나 기능을 만들어서 화면 효과를 적용하기에 이르렀다. 화면 네비게이션이 들어가는 버튼을 새로 만들어서 추가하기도 했다. 이렇게 몇개의 프로젝트를 진행하면서 커밋하는 코드양도 많아지고 코드 품질도 매우 향상되었다.

조직개편이 되면서 기존에 같이 일하던 디자이너는 옆팀으로 가고 새로운 디자이너가 합류하게 되었다. 개인적으로는 새로운 디자이너가 동등한 코드 기여을 할지 불안한 상황이었다. 하지만 왠걸, 이번에는 서체 변경 뿐만 아니라 웹폰트 적용, 스프라이트 이미지 제작해서 기존 코드 참조해서 숫자를 이미지 폰트로 바꾸는 작업까지 해치웠다. 이러한 작업방식이 일부 특별한 사람들만 가능한 일이 아니라는 생각을 할 수 있게 되었다. 디자이너 중에서도 상당히 많은 수가 구현에 관심을 가지고 있다.

배운것

디자이너에게서 코딩할 기회를 빼앗은 이후로 업무 프로세스는 퇴화했다고 생각한다. 간단한거 하나 고치려고 해도 기획 - 디자인 - 프론트 - 백엔드 순의 폭포수 모델에서 벗어날 수가 없었다. 아무리 애자일한다고 떠들어 대도 코드가 폭포수로 흐르는 상황에서는 개발 프로세스의 혁신을 기대하기 어려웠다.

하지만 그렇다고 디자이너들이 기술을 등한시하고 있지는 않았다. 직접 뭔가 만드려고 하는 욕구는 매우 강했고 HTML, CSS 같은 구현과 관련된 기술 공부도 꾸준히 해오고 있었다. 다만 개발자들이 길을 열어주지 않았을 뿐이다. 지금의 디자이너는 심지어 왜 기존에는 이렇게 직접 수정할 수 있는 방법을 열어주지 않았는지 모르겠다고까지 했다. 코드를 같이 작성한다는 일이 쉬운일은 아니지만 그렇다고 불가능한 일도 아니다.

그리고 하려는 마음만 있으면 의외로 코딩은 매우 쉽다.

앞으로

사실 이 실험은 디자이너 만을 위한 실험은 아니었다. 답답한 업무 프로세스 개선을 위한 첫걸음이었다. 개방된 업무 환경이 실제로 얼마나 큰 변화를 일으키는지 확인해 보려는 실험이었고 결과적으로 많은 것을 배웠다. R&R을 명확히 규정하는 것도 중요하지만 작은 조직에서는 적절히 책임과 권한을 이양해서 보다 더 창의적인 결과물을 만들어 낼 수 있다는 점을 확인했다. 모두가 같은 지향점을 유지할 때 업무 효율이 크게 향상되는 것을 보았고 그러기 위해서는 역할의 분담 보다는 태스크 분담이 훨씬 효과적이리라 생각된다.

좋은 문화, 개방과 공유는 업무 프로세스와 직접적으로 연결되어야 한다. 모든 업무 진행과 코드 변경 내역을 공유하고 서로 계속해서 피드백을 주고 받을 수 있어야 한다. 미완성이나 버그를 두려워하지 말고 피드백을 못받거나 너무 늦게 받는 일을 두러워해야 한다. 그래야 다 같이 성장하고 좋은 품질의 제품을 유지할 수 있다.

이를 위해서는 기록이 무엇보다도 중요하다. 회의 같이 휘발되어 없어지는 일에는 되도록 시간을 할애하지 않고 지속 가능성있는 일에 시간을 많이 투자해야 한다. 정리를 위한 기록이 아니라 진행을 위한 기록이 되어야 한다. 앞으로는 말이아닌 글로 의사소통하는 방법을 실험해 보고자 한다.