Paperwork와 반복작업은 개발자를 힘들게한다

개발자로 일하는게 힘든 이유

우리가 보기에 개발자는 하루종일 알수없는 프로그래밍 언어로 어려워 보이는 코드를 작성하는 사람으로 보이지만, 사실 개발자들을 힘들게 하는 것은 따로있다. 바로 문서작업과 반복적인 작업들인데 정작 코드 작성보다 더 힘들다. 마치 인테리어 공사를 하면 자르고 붙이는 일보다 자재를 옮기는 일이 더 많고 고된 것 처럼 개발자의 업무시간은 보통 생각하는 것 과는 다르게 채워진다. 기본이 되는 개발업무시간은 전체에 절반을 조금 넘는 정도의 비율을 차지하고 나머지 시간은 각각 절반씩 문서작업과 반복되는 작업요청을 수행하는데 보내게 된다. 하지만 이는 이상적인 경우를 예로 든 것이며 SI등 몇몇 경우에는 문서작업과 개발시간 비중이 3:1까지 커지는 경우도 있다. 여러 사람과 함께 업무하는 현대의 개발환경 특성상 작성해야 할 문서는 점점 많아지고 제 때 해내지 못하면 나중에 몰아서 해야하기때문에 큰 부담이 아닐 수 없다. 게다가 여러 협업부서에서 수정요청하는것들은 매번 급하다고 하니 이를 무시할수도 없는 지경이다. 그래서 개발자들은 코딩보다 페이퍼워크와 반복작업이 더 힘들다.

개발자가 작성해야되는 문서들이 어떤것들이 있길래 문서작업에 시간이 그렇게 많이 든다고 하는걸까? 개발 코드 자체도 가독성있게 작성해야하는 일종의 문서이지만, 이를 제외하고도 API문서, 장애보고서, 배포 및 운영에 관련된 문서, 기술관련 수많은 자료들이 있다. 만약 특정 기관에서 인증이나 감사를 받게된다면 해당 기관이 원하는 문서들을 모두 준비해야 하니 정말 버거운 양의 작성할 것들이 있다.

작성할 문서의 종류가 많다는 것 외에도 문서작업이 힘든 이유가 있다. 우선 글쓰기 자체에 대한 부담감이 있다. 기술에 관련된 문서이고 이를 기준으로 가까이는 협업부서, 멀리는 외부협력사와 일하게 될텐데 잘못 작성된 부분이 있으면 고치는데 큰 비용이 들게 된다. 매번 코드가 바뀌게 될 때마다 관리하고 있는 문서들을 최신화해야한다. 문서의 종류가 많을수록 많은 시간이 소요되는건 당연한 일이다. 또 다른 직군들과 마찬가지로 정말 필요한 문서들 외에도 형식을 맞추기 위해 생산되는 문서들이 있다. 그래서 정작 작성된 이후에 읽히지 않는 문서일 경우가 있다. 그런 문서를 작성하고 있노라면 내가 대체 왜 이런 일을 해야 하는지 의문스러운 기분이 든다.

사소하지만 매번 반복되는 작업들 역시 개발자들을 많이 힘들게 한다. "이런 건 자동화할 수 있지 않나요?"라는 말이 나올 법한 작업들이 여전히 많이 존재한다. 특히 서비스가 커질수록 이런 반복 작업은 더욱 늘어나는 경향이 있다.

가장 흔한 반복 작업은 데이터나 리소스의 수정이다. 예를 들어 기획팀에서 "이벤트 배너 문구를 수정해주세요", "이 상품의 가격을 바꿔주세요"와 같은 요청을 하는 경우다. 단순해 보이는 이런 작업도 개발자에게는 코드를 수정하고, 테스트하고, 배포하는 전체 프로세스를 거쳐야 하는 번거로운 일이다. 특히 이런 요청이 하루에도 여러 번 들어온다면 개발자의 업무 흐름은 계속해서 끊길 수밖에 없다.

비슷한 화면이나 기능을 반복해서 만드는 작업도 있다. "이 페이지랑 똑같은 기능을 하는데 이 부분만 다르게 만들어 주세요"라는 요청은 겉보기에는 간단해 보이지만, 실제로는 기존 코드를 복사하고 수정하는 과정에서 분명 개발자의 손을 타는 부분들이 생기기 마련이다. 이런 작업이 쌓이다 보면 나중에는 비슷하지만 조금씩 다른 코드가 여러 곳에 존재하게 되어 유지보수가 어려워진다.

레거시 코드 유지보수도 대표적인 반복 작업이다. 오래된 코드를 수정할 때마다 같은 문제를 반복해서 마주치게 된다. "이 부분을 수정하면 저쪽이 깨질 것 같은데..."라는 불안감과 함께 작업해야 하는 것이다. 특히 문서화가 제대로 되어있지 않은 레거시 코드는 매번 같은 코드를 처음부터 분석해야 하는 경우도 많다.

테스트 역시 반복적인 작업 중 하나다. 새로운 기능을 추가하거나 기존 기능을 수정할 때마다 동일한 테스트를 반복해야 한다. 자동화된 테스트 환경이 구축되어 있지 않다면, 개발자는 매번 수동으로 같은 테스트를 반복해야 한다.

이러한 반복 작업이 발생하는 주된 이유는 자동화의 부재다. 당장 급한 일을 처리하느라 자동화할 시간을 내지 못하거나, 자동화 도구를 도입하는 데 필요한 비용과 시간을 투자하지 않는 경우가 많다. 또한 시스템이 복잡해지면서 생기는 기술 부채나, 효율적이지 못한 프로세스도 반복 작업을 만드는 원인이 된다.

이러한 반복 작업과 문서화 부담을 줄이기 위한 좋은 해결책들이 있다. 하지만 현실에서는 여러 제약으로 인해 쉽게 도입하기 어려운 경우가 많다. 많이 알려진 해결 방안과 그 한계를 함께 살펴보자.

가장 먼저 생각할 수 있는 것은 문서 자동화 도구의 도입이다. 예를 들어 API 문서의 경우 Swagger나 Spring Rest Docs 같은 도구를 사용하면 코드에서 직접 문서를 생성할 수 있다. 코드가 변경될 때마다 문서도 자동으로 업데이트되니 문서의 최신성을 유지하기 좋다. 하지만 이런 도구를 도입하려면 초기 설정에 시간이 필요하고, 개발자들이 새로운 도구 사용법을 익혀야 한다. 당장 바쁜 프로젝트 일정 속에서 이런 시간을 내기는 쉽지 않다.

반복적인 데이터 수정 작업은 관리자 페이지를 만들어 해결할 수 있다. 개발자가 아닌 담당자가 직접 데이터를 수정할 수 있게 되면 개발자의 업무 부담이 크게 줄어든다. 하지만 관리자 페이지 개발에는 상당한 공수가 필요하다. 또한 데이터 수정 권한을 주는 것에 대한 보안 이슈나, 잘못된 수정으로 인한 장애 가능성도 고려해야 한다.

테스트 자동화도 중요한 해결책이다. CI/CD 파이프라인을 구축하고 자동화된 테스트를 작성하면 반복적인 테스트 작업을 줄일 수 있다. 하지만 테스트 코드 작성에는 많은 시간이 필요하고, 때로는 실제 코드보다 더 많은 시간이 들기도 한다. 게다가 레거시 시스템에 테스트 자동화를 적용하는 것은 더욱 어려운 과제다.

이처럼 기술적인 해결책들이 존재하지만, 현실에서는 시간과 비용의 제약, 조직 문화의 한계, 기존 시스템의 복잡성 등으로 인해 쉽게 도입하기 어렵다. 특히 중소규모 조직에서는 당장의 개발 일정을 맞추는 것이 더 시급한 과제인 경우가 대부분이다. 결국 개발자들은 이상적인 해결책을 알면서도 현실적인 제약 속에서 반복 작업을 계속해야 하는 상황에 놓이게 된다.

개발자들의 이러한 고충을 이해했다면, 우리 기획자가 도울 수 있는 부분은 어떤것들이 있을까.

첫째, 불필요한 문서 작업을 줄여줄 수 있다. 개발자에게 문서를 요청할 때는 "이 문서가 정말 필요한가?"를 한 번 더 생각해보자. 기획 단계에서 우리가 조금 더 상세한 문서를 작성하면, 개발자가 따로 작성할 필요가 없는 경우도 많다. 특히 화면 설계나 기능 명세는 기획 문서에 잘 정리해두면 개발자가 다시 작성할 필요가 없다.

둘째, 반복 작업이 발생하지 않도록 기획 단계에서 고민하자. "이 데이터를 매번 수동으로 수정해야 하나요?", "관리자가 직접 입력해야 하나요?", "이런 수정사항이 자주 발생할까요?"와 같은 질문을 미리 던져보면 좋다. 자주 발생할 것 같은 작업은 관리자 페이지나 자동화 도구 개발을 기획 단계에서 제안할 수 있다.

마지막으로, 개발자의 시간을 보호하는 문화를 만들어가자. 사소해 보이는 수정사항이라도 모아서 한 번에 요청하기, 긴급하지 않은 수정은 다음 배포까지 기다리기, 장애 상황이 아닌 경우 야간/주말 작업 최소화하기 등이다. 이는 단순히 개발자의 편의를 위한 것이 아니라, 결과적으로 더 나은 품질의 결과물을 만들어내는 지름길이다.

우리의 이런 마음이 개발자들의 큰 힘이 될 수 있다. 그들이 진짜 개발에 집중할 수 있는 환경을 만드는 것, 그것이 기획자가 할 수 있는 가장 큰 도움이라고 생각한다.