잘하는 개발자?

잘하는 개발자? 요약
운좋게도 내 기량을 발휘해 해결할 수 있는 일들이 많이 있었다. 그리고 투명하게 내가 어떤일을 어떻게 하고있으며 얼마나 걸릴 것 같은지 다양한 채널로 공유한게 도움이 되었던 것 같다.

---

들어가며
회식이 있었을 때, 감사하게도 팀 동료분들로부터 [참 잘한다] [신입답지 않다] 등의 칭찬을 들었다. 순간 우쭐한 마음이 들긴 했지만.. 앞으로도 계속 이 퍼포먼스를 뽑아낼 수 있도록 하는게 중요할 것 같다는 생각이 들어서, 칭찬과 함께 말씀해주셨던 것들과 어떻게 이런 평가를 받을 수 있었을까? 라고 나름 생각해본 것들을 정리해둔다.

 

---

환경과 운
일단 운이 좋았다. 내가 들어갔을 당시 프로젝트는 몇개월째 딜레이되고 있었고. 구현율은 넉넉하게 잡아도 50% 정도의.. 말 그대로 뼈대만 간신히 잡힌 상태에서 각 파트간 갈등은 최고조에 달해 터지기 직전의 상황이었는데. 이런 상황이 흔한건 아니니까,  운 좋게도 나는 이런 상황에 강했고 덕분에 내 기량을 충분히 보여줄 기회가 있었다고 생각한다.

가령 이런 상황이다. 내가 들어온 당시에 미구현된 페이지들이 두자릿수 정도 되었는데(=한두 페이지 말고는 아무것도 없었다는 것이다!!). 개발쪽 인력은 이펙트를 5픽셀정도 오른쪽으로 밀 수 있다 or 없다를 논쟁하는데에 몇시간씩 소모되고있었고.. 덕분에 솔리드하게 구현된 파츠 없이 프레임만 얹어져있어서, 들고가봐야 피드백을 받아봤자인 상황만 나오고. 내용적 진척은 없는데, 피드백방향도 명료하게 잡히질 않으니 기획의 근본을 뒤흔드는 결정들이 추가되고 근본이 계속 흔들릴때마다 작업물을 갈아엎는 작업자들의 사기도 점점 깎이는.. 이런 네거티브 피드백이 축적되는 상황에서. 나는, 들어온지 몇 주 째 일도 안주고 어차피 반쯤 방치하고 있겠다.. 일주일 정도 각잡고 미구현 페이지들의 더미를 만들어 메인 브랜치에 푸시해버렸었다.

이를 통해 두가지 효과가 일어나길 바랬는데, 하나는 피상적인 미구현항목에 대한 여러 가늠들을 명료하게 할 수 있도록 돕는 하나의 기준점을 만드는 것이었다. "스테이터스 창 만들기"라는 문장에서는 "그냥 데이터 UI에다가 뿌려주면 되는거잖아"라는 가늠밖엔 할 수 없지만. 일단 창이 허접하게나마 생기고 나면, 여기 들어가는 데이터가 이게 맞는지, 누락된 것들은 없는지, 다른 페이지로 연결될 필요는 없는지 등을 가늠해보고 결정할 수 있으니까.. 좀 더 생산적인 의논이 가능해지길 바랬다.
그리고 다른 하나는 아직 의욕이 있는 사람들에게 지금 뭔가 되어가고 있다는 느낌을 주고싶었다. 사람은 시각적인 부분, 그 중에서 시각적이고 + 만질수 있는 부분들이 생겨날 때 진척감을 느끼고 UI는 이런 느낌을 주기에 정말 최적의 수단이었어서 이를통해 사람들이 지금 뭔가 되어가는 듯한  그래서 아직 의욕있는 사람이 계속 힘낼 수 있는 상황을 만들고 싶었다.

 

---

투명함
두번째는 작업적 투명성을 높이려는 행동이 도움이 되었던게 아닐까 생각하는데.. 우선 나는 작업기간을 다음과 같은 기준으로 어림한다.

• 구현의 경우 + 기본 1시간
  • 새롭게 구현해야 하는가(참고할만한 다른 모듈이 없는가)? + 1시간
  • 완전히 새로운 유형의 컴포넌트인가? + 1시간
  • 새로운 유형의 프리팹을 만들어야 하는가? + 1시간
  • 구조부터 설계가 들어가야 하는가? + 3시간
• 수정의 경우 + 기본 1시간
  • 문제 발생 원인을 가늠하지 못하고 있는가? + 2시간
  • 처음 발견된 종류 or 영역의 문제인가? + 2시간

여기서 각 항목별로 시간을 합산한 뒤 * 3 정도를 해서 "~~~ 정도 시간이 걸릴 것 같다"고 미리 이야기하는 편이다. 그리고 왜 그정도 시간이 걸릴 것 같은지 합산된 이유 중에서 가장 대표적인 것(= 내가 챌린지로 느끼는 것)을 꼽아서 한두마디 정도 설명을 붙인다. (ex. "새로 스킬 창을 만드는 건 반나절(6시간 = (1 + 1) * 3) 정도 걸릴 것 같습니다.")

이 때, 시간을 들은 상대방의 반응을 보고 이 작업의 우선순위를 정한다. (보통 소요시간을 산정해서 말씀드려야 할 일이 있는 작업들은 우선순위가 높기때문에 먼저 쳐내게 된다) 그리고 만약 "빌드 테스트 때문에 조금 빨리 넣어주실 수 있어요?" 등과 같이 더 빨리 진행해야 하는 상황이 온다면, 진짜 필요한 기능만 추려서 다시 산정해서 알려드린다. (ex. "(빌드테스트니까 실 데이터의 정합성보다는 상호작용 여부가 더 중요하므로) 그러면 화면 전환이랑, 상세보기, 닫기까지만 넣는다면 점심먹기 전까지 어떻게든 해볼 수 있을 것 같습니다.")

그리고 작업한 내용들은 아주 작은 기능 단위로 쪼개서 브랜치에 올리는데. 이렇게 하면 지난 커밋내역을 뒤져야 할 때, 필요한 부분을 찾아내기가 편해지고. 각 커밋별 변경내역이 한정되어있기 때문에, 그 수정내역만 되돌리면 되니까 비교적 롤백하기 편해진다. 그리고 마지막으로 팀원들이 히스토리를 쭉 읽어올라가면서 내가 어떤 작업들을 하고 있는지 알 수 있게 된다. (이렇게 쪼개는 습관은, 깃을 터미널로 쓸땐 잘 없었는데 회사에서는 소스트리를 쓰다보니 시각적으로 히스토리가 바로 보여서 자연스럽게 이렇게 남기게 되는 것 같다.)

---

마치며

초반에 티타임을 가지며 "이곳은 노력해도 (금전적인)보상은 커녕 알아주지조차 않는 곳"이라는 이야기를 들었는데.. 그래도 이렇게 같이 일하는 누군가는 알아주었고 인정해 주었다(그리고 인정받는 것은 기분이 좋다). 참.. 기분이 이상하다. 앞으로도 열심히 해야지 하하