혼자 하는 것이 편하지만, 함께 해야 잘할 수 있다.
개인적으로 뭔가에 몰입해 있을 때 열심히 하게 되고, 스트레스도 안 받고, 시간도 빠르게 가고, 마음도 편하고, 즐거움까지 느끼기도 한다. 그런데 이렇게 좋은 점이 많은 몰입에는 함정이 있다.
"소프트웨어 장인 정신 이야기" 에서 로버트 C. 마틴은
몰입된 상태에서 만들어 낸 코드가 꽤 엉망인 편인 것을 발견하곤 한다.
그래서 요즘은 몰입에 빠지지 않으려 노력한다.
짝프로그래밍은 몰입에 빠지지 않을 수 있는 좋은 방법이다.
라고 말한다.
혼자서 열심히 하다 보면 잘못된 방향으로 열심히 갈 수 있는 위험이 존재하는 것 같다. 그래서 짝프로그래밍을 통해 동료의 피드백을 받아보면서 방향을 보정하는 노력이 필요한 것 같다.
회의가 없는 날에 몰입해서 개발하려고 재택을 하는 경우가 있다. 그리고 오후에 PR을 요청하는데 이런 PR을 보면
왜 이렇게 했을까?
다른 더 좋은 방법이 있는데...
너무 많이 추상화를 했네.
맥락의 공유 없이 너무 많이 나가서 이해하기 어렵네
이런 생각이 드는 경우가 많다. 짧게 일하며 동료의 피드백을 통해 방향이 맞는지 고민하는 과정이 빠졌다는 생각이 든다.
속도 = 속력 x 방향
속도가 성과라면 속력은 열심히 몰입해서 일하는 것 같다. 그런데 여기에 방향이 곱해진다. 즉 방향이 잘 못되면 몰입해서 열심히 한 것을 되돌리고 다시 좋은 방향으로 하는 것이 나은 경우가 발생한다. 잘못된 방향으로 전속력으로 달린다면 어떻게 될까? 아마 큰 피해가 있을 것이다.
위 기사는 경주마가 주변을 못 보고 경주에 몰입하도록 좋은 성적을 냈다는 내용이다. 경주마의 방향은 기수가 알려준다. 하지만 우리는 우리의 방향을 스스로, 또 동료들과 정해야 한다.
. 토끼굴의 함정
몰입해서 일할 때의 또 다른 문제로 토끼 굴에 빠지는 경우가 있다. 토끼굴은 켄트벡이 Tidy Firstd에서 예를 든 것으로
루이스 캐럴의 "이상한 나라의 앨리스"에서 따온 은유
앨리스는 토끼굴에 빠지면서 이상한 나라로 들어감
이상한 나라에서 앨리스는 종종 실제로 중요치 않은 일에 관심을 빼앗기 곤 함
토끼굴에 빠진다는 말은, 이와 같이 다른 곳에 관심을 두고 낭비하게 되는 것을 뜻 함
우리도 몰입해서 뭔가를 하다 보면 본래 하려던 업무 외에 다른 것에 빠져서 시간을 보낸다. 예를 들어 기능 변경을 하려 다고 당장은 필요치 않은 개선 업무로 많은 시간을 보내는 것, 필요 이상으로 과하게 추상화, 성능 최적화 등을 하는 것 등이 포함된다.
위 그림처럼
1. 본래 업무를 수행하다 보면
2. 추가적으로 할 일이 생길 수 있다.
3. 이때 추가적으로 생긴 일이 본래 업무 수행을 위해서 반드시 필요한 것(blocker)라면 새로 발견한 일부터 처리해야겠지만, 대부분의 경우는 그렇지 않아서 백로그에만 기록하고 본래 업무를 진행하는 것이 맞는 경우가 많다.
4. 본래 업무를 완료한 후에 백로그에서 다시 우선순위를 고려해서 할 일을 선정하는 것이 맞다.
5. 이러다 보면 지속적으로 우선순위에서 밀려서 리소스를 배정받지 못하는 일이 있는데 그런 일은 지우는 것이 맞다(나는 이것을 "아사(餓死 / starvation) 기반 개발"이라고 표현한다). 정말 중요한 일이라면 다시 백로그에 들어오고 높은 우선순위로 처리될 것이다.
주의. 이때 2번에서 뭔가를 발견했다고 바로 그리 가면 토끼굴에 빠지게 된다.
이러한 토끼 굴에 빠지는 것도 몰입해서 한 번에 너무 많은 시간을 투자해서 발생하는 것 같다.
뽀모도르는 25분 동안 지금 일에 집중해서 일하고, 25분이 지나면 5분 정도를 쉬면서 중간중간 다른 일도 처리하는 방법이다. 자세한 내용은 인터넷에서 많이 찾아볼 수 있을 것이다.
"소프트웨어 장인 정신 이야기" 에서 로버트 C. 마틴은 뽀모도르에 대해서 다음과 같이 설명한다.
전화가 왔을 때 뽀모도르를 마치고 연락하겠다고 말하라
업무 중단 상황을 최대한 빨리 해소하고 일로 복귀하라
휴식 시간이 끝난 후에 방해의 원인이었던 일(전화 등)을 처리하라
뽀모도르 사이의 시간이 길어질 수 있음
하루를 마쳤을 때 완료한 뽀모도르의 수를 측정하면 이것인 생산성임
업무를 뽀모도르 단위로 추산하고 하루를 뽀모도르 할당으로 계획
꽤 효과적인 방법이라고 생각한다.
나는 최근에 아이폰 뽀모도르 앱을 사용하기 시작했는데 꽤 괜찮다(App Store에서 제공하는 Flow - 뽀모도로, 집중, 시간관리, 공부 타이머).
켄트벡은 Is Extreme Collaboration Remotely Possible? 에서 생산적 우연성에 대해 다음과 같이 이야기한다.
공동의 공간에 함께 앉아 있으면 생산적인 우연성이 촉진는데 다음과 같은 경우들이 있다.
- 내가 옴짝달싹 못하고 있는 것을 보고 누군가 도와주려고 다가온다.
- 내가 기여할 수 있는 대화를 우연히 듣게 된다.
- 고객이 놀라운 방식으로 시스템을 사용하는 것을 보게 된다.
사무실에서 일을 하다 보면 내가 도울 수 있는 것에 대해 동료들이 고민하는 것을 들을 때가 있다. 이때 서로를 도울 기회가 생기고 실제로 도움을 주고받는다. 이런 경우 또한 몰입의 함정을 벗어날 수 있는 좋은 경우라고 생각한다.
얼마 전에 사무실에서 두 개발자들의 대화를 들었는데 생산적 우연성을 유발하는 대화였다(그때 그분들이 생산적 우연성에 대해서 알고 있었는지는 모르겠다).
영희님 우리 어디서 짝프로그래밍을 할까요? 자리에서 하면 좀 시끄러울 것 같으니 회의실에서 할까요?
철수님 그냥 자리에서 하시죠. 그럼 다른 분이 우리 얘기를 듣고 도와줄 수도 있잖아요!
정말 멋진 시도라고 생각했었다.
고무 오리 디버깅은 개발자가 자신의 코드를 설명하며 문제를 해결하는 방법 중 하나로 알려져 있다. 개발자는 실제로 고무 오리나 동료에게 자신의 코드를 설명하는 과정을 통해 문제를 더 명확하게 이해하게 되고, 그 과정에서 스스로 해결책을 발견하는 경우가 많다.
이 용어는 “The Pragmatic Programmer”라는 책에서 유래되었으며, 고무 오리 디버깅을 위해 개발자가 책상에 고무 오리를 놓고 그 오리에게 문제를 설명하는 장면을 묘사한 데서 비롯되었다.
동료에게 문제를 설명하다가 해결책이 떠오르는 경우도 같은 맥락에서 이해할 수 있습니다. 문제를 설명하면서 자신의 사고 과정을 다시 한번 정리하고 명확히 하게 되면서, 그 과정에서 놓쳤던 부분을 깨닫거나 새로운 해결책을 떠올리게 되는 것이다.
참 신기한 경우다. 물어보려고 설명하다가 그 설명이 끝나기도 전에 스스로 해결책이 생각이 나니 말이다.
이 방법 또한 몰입의 함정에서 빠져나올 수 있는 좋은 방법 중 하나이다.
경주마처럼 앞만 보고 달리는 것, 앨리스처럼 몰입을 하다가 토끼굴에 빠지는 것 등은 과한 몰입으로 인한 것이다.
이 글에서 해결책으로 언급한 뽀모도로, 생산적 우연성, 고무 오리 등은
너무 오래 한 가지에 혼자만 몰입하지 말고 동료와 피드백을 주고받으며 협업을 하면 더 좋은 결과를 얻을 수 있다
는 것을 내포한다.
업무 수행, 특히 소프트웨어 개발은 다양한 사람들과의 협업을 기반으로 한다는 점이 중요하다고 생각한다.
혼자 몰입해서 뭔가를 열심히 하는 것은 하기는 쉽다. 하지만 좋은 결과를 얻기는 어렵다.
동료와 협업을 통해 뭔가를 해결하는 것은 혼자 하는 것에 비하면 어렵다. 아무래도 개발자들은 다른 사람에게 내 생각, 내 코드를 보여주면서 일하기보다는 혼자 하는 것이 편하다. 하지만 다양성이 결핍되고, 몰입으로 인한 손해를 생각한다면 처음에는 불편하더라도 동료와 협업을 통해 성과를 만드는 것을 노력해야 한다고 생각한다.