프로덕트 디자이너인데 Git과 Github을 배우라고?
배워서 좋은 건 아주 많고 나쁜 건 하나도 없다.
누군가 "지금 회사를 다니면서 배운 것 중 가잔 값진 게 뭐냐?"라고 물으면 큰 고민 없이 Git과 Github을 배운 거라고 답할 것이다.
이전에도 종종 퍼블리싱 일을 하면서 혼자 Git pages를 만든 경험이 있지만 지금처럼 이슈를 만들고, PR을 올리고, 리뷰를 받고, 테스트 서버에 머지하는 과정을 경험해보지는 못했다. (최근에는 감격스럽게도 커밋수가 600개를 돌파했다!) 하지만 개발자 문화가 강한 회사에 다니다 보니 Git을 보다 깊게 접하게 되었는데 상당히 매력적인 툴이다. (핵심인 버전 관리를 제외하고도 말이다.)
장하다 커밋 600개 돌파한 나 자신...본론으로 들어가서 Git과 Github 그리고 소개하진 않았지만 개발자 문화에 적응하면서 얻은 점은 아래와 같다.
이슈 파일링을 통한 문제점 대한 명확한 이해
뛰어난 개발자들이 만든 Styled(SCSS. CSS) 코드를 내 것으로 만들기
Github을 통한 마일스톤 관리
이슈 파일링을 통한 문제점에 대한 명확한 이해
Github으로 이슈를 파일링 하기 시작하면 '이게 어떤 문제인지, 해결책은 무엇인지' 등을 고민해볼 수 있다.
Github에는 이슈 파일링 기능이 있다. 현재 프로덕트에 어떤 문제가 있는지 리포트하고, 이를 고치기 위한 이후 패치를 기다리는 것이다. 이슈를 파일링 할 때는 명확하게 문제점을 기술하고(문제의 종류), 누가 고쳐야 하는지를 할당하며, 언제까지 고쳐야 하는지 적는다 (이번 마일스톤에서 할 건지, 이후 마일스톤에서 할 건지, hotfix인지 등)
이슈 파일링 과정을 통해서 풀고자 하는 문제에 대해 깊게 생각해볼 수 있다. 이 문제가 단순히 스타일링의 문제인지, UX 설계의 문제인지 혹은 서버나 클라이언트 수준의 버그인지 등
그리고 이렇게 이슈를 파일링 하면 다른 개발자나 디자이너들이 보고 이 이슈에 대한 의견을 제시한다. Wontfix(고치지는 것에 동의하지 않음) 라벨이 달릴 수도 있고, 보다 급한 이슈라 Critical 라벨이 달릴 수도 있다. ( 종종 나는 매우 급한 문제라고 생각했지만 다른 팀원이 보기에는 그렇지 않은 경우도 있고, 나는 대수롭지 않게 생각한 문제이지만 다른 개발자가 보기에는 굉장히 크리티컬 한 문제일 수도 있다. )
부가적으로 각 디자인 컴포넌트들의 명확한 이름을 알 수 있다. 개발자는 특정 컴포넌트를 WelcomeModal이라고 부르는데 디자이너는 WelcomePopup이라고 불러 생기는 미묘한 커뮤니케이션 오류를 확실히 줄일 수 있다.
뛰어난 개발자들이 만든 Styled(SCSS. CSS) 코드를 내 것으로 만들기
대학교 2학년 때부터 퍼블리싱을 해왔지만 다른 개발자가 짠 CSS 코드를 볼 기회는 많지 않다. 심지어 경력 있는 개발자가 다른 개발자의 리뷰까지 받아 작성된 스타일링 코드들은 거의 황금알이다. 평소에 프로덕트를 만들면서 궁금했던 레이아웃을 만드는 방법, 마이크로 인터랙션을 거는 방법 등을 코드를 보면서 배울 수 있다니 이런 기회가 또 어디 있을까.
나였다면 walk around로 만들었을 스타일을 개발자들이 깔끔한 styeld 코드로 만들어 내는 걸 보면 "아.. 이렇게 하는 거였구나"하고 배울 때가 많다.
여기서 더 나아가면 개발자들이 짠 스타일 코드를 직접 리뷰해보는 경험도 쌓을 수 있다.
처음에 회사에 들어갔을 때 회사의 Guru 개발자님이 했던 "명작을 한 번도 안 읽어본 사람이 어떻게 좋은 소설을 쓸 수 있을까요?"라는 말의 의미를 이제는 조금 이해할 수 있을 것 같다.
--
이어짐
