brunch

매거진 코드스테이츠 Code States

라이킷 2 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 코드스테이츠 Code States Jun 14. 2019

드디어 우리에게도 개발 문화라는 것이 생겼어요.

개발자가 되기 전 내가 상상한 개발회사는 이럴 줄 알았다.

개발자가 되기 전 내가 상상한 개발회사는 이럴 줄 알았다. 말도 안되는 내 상상 이었지만..

1. 회사 코드는 내가 혀를 내두를 정도로 깔끔하게 짜여 져 있을 것이다.
2. 그런 코드를 작성하는 시니어 개발자가 나를 인도 해줄 것이다.
3. 그런 환경에서 내가 작성한 코드는 날카로운 피드백과 함께 점점 더 고쳐 질 것이다.
4. 그렇게 열심히 하다보면 머지않아 나도 그런 코드를 짜고 있을 것이다.

사실 지금 내가 일 하고 있는 지금의 회사는 위의 조건들 과는 다소 거리가 좀 있었다. (지금은 대부분의 회사는 위의 조건과 거리가 멀 것이란걸 알고있다.)

지금의 회사에서 엔지니어 인턴 과정을 하면서, 내가 작성했던 코드는 리뷰 없이 내가 merge를 했으며, 프로젝트를 스크래치 부터 시작 했기 때문에 깔끔한 코드를 볼 수도 없었다. 그래서 당연하게도 나는 Best Practice를 본적이 없기 때문에, 내 코드에 대한 의문을 항상 가지고 있었으며, 3개월이 지나도 딱히 내 코드가 나아진다는 생각이 들지도 않았다. 그래서 나는 ‘앞으로 내가 취업할 회사는 위 조건들이 갖추어져 있을 거야!’ 라고 막연하게 생각 했었다. 그런데 하루는 개발 블로그와 React 관련 서적으로 유명하신 벨로퍼트 님의 세션을 들었는데, 내 뒷통수를 엄청 강하게 때린 충고가 있었다.

주니어 개발자 라서 못해요… 라는 것은 아주 나쁜 변명이에요!

내가 지금의 회사에서 한번 열심히 해보겠노라 하고 결심 했던 계기 중 가장 큰 원인이 아닐까 싶다. 위에서 나열 했던 내 상상들은

“시니어 개발자와 이미 완벽한 회사 코드”

가 없으면 이루어 질 수 없는 것들 이었다. 막연하게

“나는 주니어니까 시니어만 잘 따라 가면 돼!”

라고 생각했나 보다.

주니어라고 못한다고? 이봐, 해봤어? 출처 : https://steemit.com/kr-writing/@moont0/3jdfmt

그렇게 나는 지금의 회사에서 내 첫 개발자 커리어를 시작했다. 뒷통수를 강하게 맞고 일을 시작 했지만, 사실 내가 엔지니어 인턴을 하면서 했던 개발 문화는 내가 직원으로 일한다고 해서 크게 다르지 않았다. 여전히 내 코드를 봐줄 사람은 없었고, 그렇게 나는 늘 짜던 코드를 짜고 있었다.

2019년이 다가왔다. 우리 회사에도 많은 변화가 있었다. 2~3명(이지만, 업무 100% 개발은 아니었기에 더 적은)의 개발자 분과 함께 진행 하던 프로젝트는 어느덧, CSE(Codestates Software Engineer) 포함 8명의 개발 팀이 꾸려졌다. 그래서 그런지 우리 개발팀도 개발문화 라는 것을 도입할 시기가 왔다고 판단을 했다.

그렇게 처음 도입한 개발 문화의 큰 틀은 다음과 같다.

1. Daily Standup

매일은 힘들지만 일주일의 대부분은 우리 도메인 팀은 밥 먹기 15분 전 스크럼 보드를 보면서 자신은 무엇을 진행 하고 있고, 보드에서 어떤 카드를 가져갈 것이며, 어떤 어려움을 겪고 있는지, 혹시 내가 아는 주제라면 도움을 줄 수 있는 그런 생산적인 대화를 딱 15분만 한다. 이 것도 길어지면 회의가 되고 스트레스가 되기 때문이다. 점심시간 15분 전을 잡은 이유도 길게 끌고 가고 싶지 않아서다. 우리는 Daily Standup으로 프로젝트의 진행에 대한 맥락(context)을 머리 속에 유지하고 간다.

길게 얘기 하지마! 딱 15분이야!

2. 코드 리뷰

우리도 코드 리뷰라는 것이 생겼다. 더 이상 내가 작성한 코드를 내가 머지 할 일은 별로 없다. 머지않아 없어 질 것이라고 생각한다. 코드 리뷰는 주 2회 실시하며, 이때는 주로 3일 정도 쌓였던 PR(Pull Request)에 대해서 자신의 코드는 자신이 설명을 하고 피드백을 받으며, 다른 팀원이 작성한 코드는 유심히 살펴보며 의문점을 제시한다. 내가 작성한 코드가 리뷰 없이 머지 되는 일은 거의 없기 때문에 내가 작성한 코드를 반드시 누가 본다고 생각하고 한번 더 생각하고 코드를 작성 하게 되는 효과를 가지게 된다.

음 .. 도통 모르겠지만 잘 짜셨네요!

3. Planning Pocker

우리는 Agile & Scrum 이라는 방법론으로 프로젝트를 진행한다. 매 스프린트 단위를 일주일로 잡고, 매 스프린트 첫날 우리 팀은 스프린트 미팅을 한다. 사실 이것은 매주 해왔던 방식이기 때문에, 특별할 것은 없지만 여기서 우리는 storypoint를 보다 객관적으로 판단하기 위해서 Planning Pocker 라는 것을 한다.

3시간만에 하신다구요? 대단하시네요 ..

위 처럼 피보나치 숫자로 구성된 카드를 가지고 우리는 해당 과업이 몇 시간이 걸릴 것인가? 에 대한 개인 견해를 카드로 제출한다. 팀원 들이 제출한 카드를 바탕으로, 통일이 되었다면 해당 시간으로 storypoint를 산정하고, 의견이 갈린다면, 의견이 갈린 사람들 끼리 서로 설득의 과정을 거쳐서 되도록 이면 보수적으로 시간을 산정한다. 물론 이런 과정을 거친다고 해서 정확한 storypoint를 산정하는 것은 힘들겠지만, 분명 우리의 storypoint 하나 하나에는 각 팀원의 의견이 담겨있다.

마무리 하며..

위에 그럴 듯 하게 작성 했지만 사실 우리 팀은 아직 개발 적으로 좀 더 성숙해져야 할 부분이 분명히 있다. 아니 많다. 위에서 존재하는 우리 팀의 개발 문화가 아직은 익숙하게 자리 잡지 않았으며, 아직 CI / CD 와 같은 시스템도 전혀 구축 되어있지 않을 뿐더러, 아직도 내 코드가 좋은 코드 인것 같지도 않다. 하지만 적어도 이런 핑계는 대지 않는다