데이로그, 업무능력향상의 지름길

인터넷 검색보다는 더 생산적으로 하자. 접했던 문제와 발견한 해결책의 로그를 유지하자. 문제가 나타나면 "이봐 전에 이걸 본 있는데, 어떻게 고쳤는지 실마리가 없어."라고 말하는 대신, 과거에 사용했던 해결책을 재빨리 찾아볼 수 있다.

(출처 : <애자일 프랙티스> P199~200, 인사이트)

프로그래머 혹은 개발자들은 매일 어떤 코드를 만들고 수정하길 반복한다. 문제가 생기면 그 문제를 해결하기 위해 주변에 물어 보거나 검색을 하여 자신과 비슷한 경험을 한 사람들이 문제를 어떻게 해결했는 지 찾는다. 운이 좋다면 인터넷 검색을 통해 답을 찾을 수도 있지만 대개의 경우 다른 의견이나 아이디어를 읽는 정도로 끝난다. 정말 원하는 것은 해결책인데 말이다.

가끔 아무 면이나 펴서 읽곤 하는 책(애자일 프랙티스)의 한 꼭지에서 '데이로그(daylogs)'가 그 해결책을 발견하는 비결이 될 수 있다고 했다. 가급적 검색 가능한 형태로 간단하게 어떤 문제의 발생 이유와 해결 방안을 기록해 두고 또한 다른 작업자들과 그 내용을 공유함으로써 해결책에 더 빨리 접근할 수 있다는 것이다. 전적으로 이 의견에 공감하며 지금도 많은 개발자들이 이런 일을 하고 있다. 가장 대표적인 것이 위키위키와 같은 도구나 각종 개발 로그를 이용하는 것이다. 조금 불편하긴 하지만 블로그와 게시판을 통해 이런 일을 하는 경우도 많다.

그런데 개발자 그룹을 제외한 다른 부문에서 데이로그를 사용하는 경우는 매우 드문 것 같다. 특히 사무직군의 경우 데이로그는 커녕 일일업무 보고를 제대로 작성하는 경우도 많지 않은 것 같다. 데이로그의 이점은 설명할 필요없이 명확함에도 많은 분야에서 데이로그가 적극적으로 이용되지 않는 이유는 무엇일까. 업무 특성의 차이 때문이 아닐까 한다. 기술 개발이나 엔지니어링 분야는 어떤 완성된 상품을 만드는 것이 목표로 보이지만 실제로 상품화는 업무의 일부분에 불과하다. 특정한 사용 요구(specification)에 맞춰서 상품을 만드는 일조차 조건에 대한 개발 보다는 조건을 만족시키지 못하는 문제를 해결하는 일이 대부분이다. A라는 조건에 맞게 동작하는 기능을 개발하기 위해 단지 A-n개 만큼 코드를 생산하는 것이 아니라 '동작하지 않는 상황'이나 '동작해서는 안되는 상황'에 맞는 코드를 생산해야 한다. 또한 그렇게 생산된 코드가 제데로 동작하지 않는 경우 문제를 해결해야 한다. 결국 '조건에 맞게 동작하는 기능'을 개발하는 것보다 수 배 혹은 수십 배 많은 개발 요소가 숨어 있다. 때문에 개발자 그룹은 매순간 새로운 해결 방법을 찾아야 하고 데이로그는 그런 반복되는 업무 특성에 적합하다.

반면 대부분의 사무직은 매 순간 해결해야 할 문제가 발생하기 보다는 주어진 환경에 맞게 행동하는 것이 중요하다. 개발팀에서 일정이 지연되었고 그로 인해 상품화가 지연되었다는 것을 인지한 재무회계팀에서 해야 할 일은 새로운 일정을 만들고 예산을 책정하고 결재를 요청하는 것이다. 이 과정은 새로운 것이 아니다. 새로운 양식이나 토론이 필요하지 않고 단지 새로운 데이터와 수치, 판단이 필요할 뿐이다. 이 업무를 새롭게 배워야 하는 초보자라면 모를까 수없이 이런 업무를 반복한 사람에게 데이로그가 필요한 것은 아니다. 물론 재무회계팀에게 새로운 상황이 닥쳐올 수도 있다. 조직이 변경되었거나 상품화 이후 판매 조직이 변동되었다면 새로운 일정과 예산을 청구하고 현재 일정과 예산을 변경시키는 방법과 시간이 바뀌는 경우가 있다. 이럴 때 재무회계팀은 새로운 양식과 흐름을 만들어야 하고 본격적인 토론과 연구가 필요하다. 그런데 이것은 데이로그로 해결되는 문제가 아니다.

나는 가끔 개발자 그룹에서 제기하는 좋은 아이디어 - 이번 경우엔 데이로그 - 를 참조하여 개발자 그룹이 아닌 다른 분야에 적용하는 방안을 생각한다. 그리고 대개의 경우 '적합하지 않음'이라는 결론에 도달한다. 일반 사무직의 경우 개발자 그룹과 달리 데이로그를 매번 작성해야 할 정도로 잦은 문제가 발생하지 않는다. 일반 사무직은 그런 이유로 업무에서 발생하는 문제에 대해 보수적으로 대할 수 밖에 없다. 어떤 문제가 발생할 때 개발자 그룹은 그 문제 자체를 업무로 이해하는 반면 일반 사무직은 데이터의 오류나 사람의 문제로 판단하게 된다. 개발자 그룹은 문제가 발생했을 때 과거에도 이와 비슷한 문제가 발생했는지 의심하기 시작하지만 일반 사무직은 문제가 발생했다는 자체를 의심하게 된다.

데이로그는 개발자 그룹이나 그와 비슷한 속성을 가진 그룹에게 매우 유용하고 훌륭한 툴이다. 그러나 그렇지 않은 업무를 수행하는 사람들에겐 불필요하고 심지어 업무를 방해하는 도구가 되기도 한다. 하나의 도구가 모든 사람에게 이롭게 작동하는 게 바람직하겠지만 그렇지 않다는 걸 인정하는 것도 매우 중요하다.