천천히 일하는게 가장 빨리 일하는 방법인 이유

제가 개인적으로 흠모(?)하는 한국 개발자들 중에 박종천 님이라는 분이 계신데 (한컴, 블리자드, 넥슨, 삼성전자 등을 거쳐서 지금은 몰로코라는 유니콘에서 일하고 계시죠), 그분 말씀 중에 다음 말씀이 참 경력을 쌓을수록 와닿습니다.

 

"개발자는 자기 업무 시간의 20%만 코딩에 써야 한다. 안그러면 뭔가 잘못 되고 있는 것이다."

 

제 경험을 빌어서 얘기하면, 소프트웨어 엔지니어의 업무는 다음의 다섯 단계의 프로세스로 나누어 지는 것 같습니다.

 

(a) 요구사항 분석

(b) 디자인

(c) 코딩

(d) 테스트. 디버깅 및 검증

(e) 개발 현황 보고 (sync)

 

저의 경우에는 업무가 100이라면 저 다섯개가 거의 동등한 정도 (즉, 각각 20 씩) 로 돌아가고 있는데, 굳이 저기서 20이 안맞는 경우는 (c) 코딩의 비율이 줄어들고 (e) sync가 잦고 길어지는 상황이 생기긴 합니다. 즉, 제 업무 시간의 최소한 80% 이상은 코딩을 하는 시간이 아닙니다. (d) 테스트, 디버깅 및 검증까지 쳐봐야 IDE에서 개발하는 시간은 40%를 넘지 않습니다.

 

어떤 분들은 제가 입코딩만 하는 놈이라고 여기실 수 있을 것 같은데 (요샌 그렇게 틀린 말도 아닌 것 같아서 걱정이긴 하지만...), 나름 이런 프로세스를 통해서도 저희 product 의 deadline은 거의 어겨지지 않았거나, 최소한 "코딩" 이 많이 걸려서 늘어진 적은 없습니다.

 

오늘 글에선 각각의 프로세스를 짚어보고, 왜 이렇게 꼰대 같고 답답한(?) 프로세스로 일을 해도 product이 만들어 지는지 얘기해 보겠습니다.

 

(a) 요구사항 분석

 

스티브 잡스가 한 유명한 말 중에 , "고객은 자신이 뭘 원하는지 모른다" 는 말이 있죠. 이건 개발자들에게도 당연히 해당하는 말입니다.

특히 우리의 고객들은 대부분 프로그램이 뭔지도 모르고, 그냥 쓸 뿐입니다. 그들이 원하는 것에 대해서 기획자들이 추측한걸 만들어서 가져오지만, 결국 그걸 현실로 가져오는, 즉 구현하는 것은 우리입니다. 우리 역시 기획 의도에 대해서 아주 명확한 그림을 머리속에 갖고 있어야만 합니다.

이 과정에서 우리가 파악해야 하는 것은, 기획자가 던져줬든 우리가 기획을 하는 상황이든, 결국 "고객이 우리에게 원하는 것이 무엇인지" 입니다.

구체적으로 제 예시를 들면, 저는 하달(?)이 떨어지면 일단 제가 이해하는 해당 업무에 대한 요구사항을 글로 작성해봅니다. 보통 전 1p 안으로 끊습니다. 한번의 개발 단위는 가능한 한 작게 잡기 때문입니다. 이렇게 1p 안에 글을 쓰다보면 기획의 모순을 찾아내기도 하고, 이 일이 정말 해야 하는 일지, 언제 해야 하는 일인지에 대한 판단이 가능해집니다. 즉, 짧게는 10분부터 길게는 1시간 정도 걸리는 요구사항 작성을 통해 "스케쥴링 가능한 한 단위의 일" 을 만듭니다. 만약에 안해도 되는 일이면 안해버리거나 (이걸로 버는 시간이 많습니다), 급한 일이 아니면 데드라인을 멀찍이 잡고 매니저 (혹은 스스로에게) 보고합니다.

(b) 디자인

자, 이제 이 문제는 "풀어야 하는" 문제라는 건 명확해졌습니다. 디자인 단계에서는 저 요구사항을 어떻게 해결할지 파악합니다.

크게는 코딩으로 해결이 되는 문제인지, configuration만 잘 만지면 되는 일인지, 비지니스 상의 협의가 필요한지 등등을 파악해서 문제의 해결 방법을 생각합니다. 역시 이것도 10분에서 1시간 정도를 투자합니다. 핵심 알고리즘은 pseudo code로 짜기도 합니다. 갖다 쓸 수 있는 라이브러리나 프레임워크가 있는지도 파악합니다.

가장 중요한 것은, 이 업무가 "잘 해결 됐다" 에 대한 기준을 세우는 것입니다. 그래야 나중에 "뭘 검증할건지" 명확합니다.

디자인 단계에서도 역시 모순이 발견되거나, 내 힘만으로는 풀 수 없는 문제이거나 여러 상황이 발생합니다. 그러면 다시 요구사항으로 돌아가거나, 디자인을 한번 더 하거나, 그냥 안하기도 합니다. 이렇게 또 시간을 아낍니다.

(c) 코딩

 

이제 코딩을 시작합니다. 저에겐 어떤 문제를 어떻게 풀지, 그걸 왜 푸는지도 명확하게 존재합니다. 이제 풀어야죠.

코딩을 하다보면, 역시 디자인 단계에서 놓친 모순을 발견하게 되거나, 막상 내가 코딩을 잘 못해서 못풀겠는 문제, 그냥 현실적으로 환경 세팅이 이상해서 생기는 문제 등 다양한 문제를 발견합니다. 그러면 다시 (a) 요구사항 분석, (b) 디자인으로 가거나, 아니면 역시 안해버리기도 합니다. (할지 안할지를 빠르게 결정하는게 되게 중요합니다)

코딩은 보통 하루에 2시간, 길면 더 길어지는 경우도 있습니다.

여기에서, 아니, 20% 시간인데 왜 2시간이냐, 10분에서 1시간이어야 하는거 아니냐, 라고 생각하실 수 있겠습니다만, 사실 여기까지 오는데 (a)와 (b)에서 안하게 되거나 미루는 일, 핑퐁하는 일등이 발생해 해당 단계들을 N번을 돌게 됩니다. 즉, 나중에 따지고 보면 각각에 할당된 시간은 20% 정도 됩니다.

(d) 테스트. 디버깅 및 검증

 

테스트, 디버깅 및 검증을 합니다. 반복이긴 한데, 역시 평가에서 모순이 발생하기도 하고, 테스트 자체가 난이도가 높은 경우도 있습니다. 얘도 그래서 2시간 정도 잡습니다.

(e) 개발 현황 보고 (sync)

 

개발한 내용을 공유합니다. 공유의 방법은 세가지입니다.

1. (a)-(d)까지의 스토리를 커밋하고, 커밋 메시지에 (a)-(d)까지 거치면서 모두가 알아야 할 내용들에 대해 작성합니다. 보통 커밋메시지 작성하는데 10분 정도는 투자합니다. 그 후에 PR을 던집니다.

2. 코드리뷰를 합니다. 제가 작성한 코드를 보여주고 피드백을 받습니다. 저도 다른 사람 코드 보고 피드백을 줍니다. 이것도 역시 10분 정도를 잡습니다.

3. 회의를 합니다. 제가 제일 싫어하는게 회의인데 (...) 회사에서 올라갈수록 회의는 피할 수가 없습니다. 최대한 빨리 끝내기 위해 회의 준비를 착실히 해가고, 빨리 끝내고 다른 일 하러 갑니다. 짧으면 회의는 5분, 길면 1시간까지도 합니다. (더 길어질 것 같으면, 그냥 다음 일정 있다고 하고 나갑니다)

 

제가 일하는 방식이 되게 답답해 보일 수는 있겠습니다만, 덕분에 저는 실수를 많이 하는 타입임에도 불구하고 일에서는 실수가 거의 없습니다.

일을 빨리 하는게 멋있어 보일 순 있는데, 빨리 하다 실수한번 하면 속도가 50% 느려지고, 한번 더 하면 66.6%가 느려집니다. 즉, 빨리 하다 한두번 실수하느니, 애초에 내 속도의 33.3% 정도로 찬찬히 일을 하면 같은 퍼포먼스를 내면서 스트레스를 덜 받을 수 있습니다. 애초에 스트레스를 덜 받으면 더 일을 잘 할 수 있게 되기도 하니, 더 좋고요.

일을 느리게 하면 좋은 점 중 하나는, 동료들과의 관계가 좋아집니다. 계속 빨리 빨리 바쁘게 일하면 동료들과 잡담도 못하고, 동료들도 나로 인해 프레셔를 느끼게 될 가능성도 있습니다. 팀워크를 위해서라도 전체 일하는 속도를 낮추는게 여러모로 도움이 된다고 생각합니다.

 

읽어주셔서 감사드리고, 질문은 댓글이나 huhahahot@gmail.com  으로 보내주시면 답변 드릴 수 있는 내용은 답변 드리도록 하겠습니다.

 

P.S.

최근에 엄청 바빴어서 주말도 없이 일하다가, 매니저한테 한국은 설날이라고 말하고 어제부터 오랜만에 쉬다보니 생각나서 엄청 오랜만에 okky에 왔네요. 저에게 메일로 고민상담도 많이 보내주시고 해서, 제가 조그만 도움이라도 되는 것 같아 기쁜 나날들을 덕분에 보냈던 것 같습니다.

 

새해 복 많이 받으시고, 원하시는 일들이 다 이루어지길 바랍니다!

 

아카이빙

https://okky.kr/article/1151022