[구름 2월 Commit] 참여 후기 <시야가 넓은 개발자는 무엇이 다를까>

지난 14일에 구름에서 진행하는 Commit 에 다녀왔다.
매달 진행하는 것이라고 하던데, '시야가 넓은 개발자' 라는 주제에 이끌려 신청했다.
현재 LINE의 기술임원이자 일본에 상장된 자회사의 CPO이신 김영재님이 진행한 강의였다.
관련 링크 https://blog.goorm.io/commit_17th/

이번 커밋에서 기억에 남는 부분만 정리하자면 이렇다. 접은 글은 강의 내용, 일반 줄글은 내가 느낀점이다.

[한줄 요약] 뭐가 다르긴, 마음가짐이 다르지!

1. 인터페이스

인터페이스란 남들이 사용하라고 만든것이다.

나의 모든 아웃풋에는 상대방이 있다.

‘유저는 누구인가?’를 항상 생각해야 한다. 내가 오늘 작성한 코드의 유저는 누구지?? ex) 동료, 한달후의 나 등

 

코드로 말하는 영업사원의 마인드셋

• 동료를 설득할 수 없으면 유저도 설득할 수 없다. 상대의 이해부담을 낮추려는 정성을 보이자.
• 내가 뭘 시도하든(기술이든 방법론이든..) 상대방을 만족시키고 말겠다는 마음가짐

이것에 대한 자세한 방법론으로 BANEX 템플릿, 오픈소스답게 설계하기 등을 설명하셨으나 다소 어려운 부분이 있었다.
다만 여기서 내가 얻은 것은 '상대방을 고려하면 자연스레 읽기 좋은 코드를 만들게 되겠군' 이다.
 
여기서 질리도록 듣는 읽기좋은 코드가 자연스럽게 나온다.
우리가 궁극적으로 지향해야 하는 건 역시 클린코드구나 싶었고, 더 자세하게 말하자면 확장성있는 코드, 의존성 주입을 사용한 코드 등을 통해 유지보수하기 쉽고 재사용이 용이한 코드를 만들어야 하는 것이 핵심인 것 같다.
 
요즘 코드를 짜면서 드는 생각은 머리비우고 코드를 짜다가 아차 하는 순간 더러운 코드가 되어버린다는 것이다.
매 순간 어떻게 하면 상대방(협업하는 동료)을 이해시킬 수 있을까? 를 고려해야 한다. 그것이 혼자하는 프로젝트일지라도 한달 후의 내가 봤을 때 이해하기 좋은 코드로 짤 수 있도록 노력해야 한다.
매번 완벽한 클린코드를 짜기는 어렵겠지만 당장 내가 할 수 있는건, 하나의 프로젝트에서 특별히 지키기로 한 원칙이 있다면 철저히 지키는 것이다. 시간이 좀 오래 걸릴지라도 시야를 넓게 봤을 때 좋은 코드로 만들어야 한다.
요즘 계속해서 하고 있는 VAC 패턴도 관심사를 분리함으로써 결국은 유지보수하기 좋은 코드를 만드는 것이다.
 
기능만 돌아가게 하는 '코더'가 아닌 클린코드를 지향하며 개발을 하는 실력있는 '개발자'로 성장하고 싶다. 
그렇게 하려면 아직 알아가야 할 부분이 너무 많다. 파이팅!!!!..
 
 

2. 프로세스

프로세스는 프로덕트를 거치는 모두

개발자의 시야는 좁다.

나에게 개발 이슈가 오기 전에 어떤 일이 있는걸까? cs나 운영에서는 어떤 이야기들이 오가는거지? 라는 원초적인 호기심으로 다가가기

 

파이프라인을 고치는 배관공의 마인드셋

• 나는 팀의 효율에 얼마나 기여하는가?
• 컴포넌트 하나마다 응집력이 강해지고 고도화도 쉬워진다. 다만 그만큼 서로를 잇는 공백이 많아지고 역할도 점점 필요해진다.
• 누군가는 할일인데 정의하거나 측정하기 어려운일.. 내가 한다.!

[이슈트래커]

• 전사적으로 사용가능해야 함.(모든 팀원이 볼 수 있도록)
• 개발자가 이슈트래커를 잘 쓰는 기준은? 웹브라우저에서 적게 열어볼수록 잘쓰는 것이다.
• 절대 상태를 손으로 바꾸지 말고 커밋메세지로 바뀌게 한다.
• IDE 안에서 이슈트래커 제어하기 IDE와 이슈트래커의 연동은 중요하다. 이를 통해 나의 상태를 주변에게 솔직하게 반영할 수 있다. 내 상태가 개발중으로 뜨면 진짜 개발중인거다 라는 확신을 준다.
• 이슈만 봐도 코드의 영향을 자연스럽게 습득할 수 있고 나의 집중력도 올라간다.

[김영재님이 추구하는 방법론] - 커밋메세지 주도 개발

• 아침에 출근 시 나는 오늘 몇개 커밋을 올릴거야 라는 것을 이슈트래커에 다 쓰기
• 이슈를 커밋 수준까지 잘게 나누자. ex) profile API, NicknameLengh 20에서 10까지 조정
• 이렇게 되면 다른 팀에서도 닉네임 validation이 어디서 일어나는가?를 알 수 있다.

 
이부분은 내가 개발자로 일하게 되면 더 와닿을 부분이라는 생각이 든다.
프로세스에 대한 부분은 그동안 많이 고려하지는 않았던 것 같다. 그래서 좀 반성이 되었다.
이슈 관리같은 경우도 개발 예정, 개발중, 개발 완료를 표시하지 않고 개발이 완료되었을 때 비로소 이슈를 생성해서 바로 개발 완료를 표시한 경우가 많았다. 이렇게 되면 사실 이슈의 의미가 퇴색된다.
팀원들이 지금 내가 뭘 개발하고 있는지를 알아야 원활하게 협업이 가능한데 개발을 다한 다음 이슈를 만들어버리면 소통이 안된다.
지금이야 개인이나 소규모로 하는 프로젝트여서 크게 상관은 없겠지만 이런 습관은 꼭 고쳐야겠다. 
또한 나의 성장 뿐만 아니라 팀의 성장, 효율을 위해서도 기여할 필요가 있음을 느꼈다. 우린 함께하는 팀이니꽈!
 

3. 캐퍼시티

함께하는 모두를 품는다. 모든일, 모든시간, 모든갈등...

요즘 개발문화에서 중요하게 나오는 키워드는 성장이다. 하지만 꼭 성장해야하나?
성장? 그보다는 용량 키우기!

핫한 키워드를 공부 안하면 성장 아닌것 같다는 압박감, 동료처럼 뭐라도 해야 한다는 불안감, 뭐가 성장인지 모르지만 성장을 해야만 한다는 부담감..

 

그보다는 지금 하는일을 더 긴 호흡으로 지치지 않게 하는 지속가능성에 집중해야 한다.

 

4. Q&A 시간에 인상적이었던 것

좋은 엔지니어는?

기술 종교를 버리자!

신발을 고르듯이 기술을 고르는 마인드셋.

상황에 맞추어 최선의 선택을 하는 것이다. 어떤 언어나 기술이든 2개월이면 익숙해진다는 마인드셋을 갖자.

 
이 부분은 내 생각과 일치해서 다행이라고 생각했다. 어차피 기술은 계~~속 바뀐다. 여기서 기술 종교가 생겨버리면(리액트 짱짱맨~ 이런거 ㅋㅋ) 그것에 매몰되고 매번 그것만 쓸줄 아는 사람이 된다. 그렇다고 해서 내가 할줄아는 언어나 기술이 많은 것도 아니지만 요즘은 최대한 열린 마음으로 받아들이려고 하는 것 같다.
 
 
 
영재님이 이렇게 본인과 팀을 위하는 마인드셋으로 팀을 이끌었다는 생각에 정말 멋있었다.
또한 본인은 리더라는 단어를 싫어한다고 하셨는데 이끌기보다 함께한다고 표현하셨다. 그리고 실제로 팀원들간의 소통도 자유롭고 피드백도 많이 받으시는 듯 했다. 그래서인지 지금 팀원들과 10년을 함께하셨다고 했다.
 
또 내가 평소 생각하던 부분과 일맥상통하는 것도 있어서(물론 나는 아직 햇병아리지만) 더욱 뜻깊었던 시간이었다.
이렇게 수평적인 개발문화를 추구하는 멋진 리더의 팀에 들어가고 싶다. 그리고 나도 언젠간 그런 리더가 되면 좋겠다 ㅎㅎ