애자일이 만든, 쉼없이 달리는 개발자들

개발 페러다임의 변화가 우리에게 준것

보통의 IT기업에서 직장생활을 하는 개발자 아무개를 상상해보자. 매일 아침 눈을뜨면 스마트폰 알림을 확인한다. 혹시나 슬랙 장애방에 이슈가 올라오진 않았는지 체크하고 가슴을 쓸어내린다. 출근해서 어제 요청온 회의에 들어갔더니 ‘긴급‘하게 이번주까지 새로운 기능을 추가하라는 지시가 탑다운으로 내려왔다고 한다. 한창 업무를 진행하고 저녁에 있을 코드 배포를 준비한다. 이용자가 많은 시간을 피해 반영시간을 정하다보니 배포는 항상 업무시간과는 묘하게 어긋나있다. 안정적으로 반영을 마치고 집에돌아와 쉬면서도 오늘 반영한 내용중에 놓친것은 없는지 걱정이 된다.

우리 일터는 예전에 비해 일하는 템포가 많이 빨라졌다. MVP(Minimum Viable Product, 최소 기능 제품)와 애자일 업무방식은 어느새 유행을 넘어 표준이 되었다. 데일리 스크럼으로 아침을 열고 매주 무언가를 꾸준히 생산해내는 이 업무방식은 개발자를 효과적으로 ‘착즙’하는 방법이라고 생각한다.

CI/CD(지속적 통합/배포) 환경의 도입으로 개발자는 하루에도 수차례 코드를 배포할 수 있게 되었다. 이는 빠른 개발과 반영을 가능하게 했지만, 동시에 실시간 모니터링과 즉각적인 대응이 필수가 되었다. 개발자는 이제 코드를 작성하는 것을 넘어 운영 환경을 실시간으로 관찰하고, 문제가 발생하면 즉시 해결해야 하는 부담을 안게 되었다.

예전에 보편적이었던 워터폴 방식과 일하는 사람 입장에서 많이 다를 수 밖에 없다. 매 주 혹은 격주로 마감이 있다는건 사실 큰 압박으로 다가온다. 마감으로 인해 일을 미루지 않아 매 스프린트마다 결과물을 낼 수 있지만, 매 납기마다 사람은 ‘갈려‘나간다. 기획과 개발 모두 완전하지 않은 초기 단계에서 일단 만들어보고 구체화시키는 업무 방식은 매 주기마다 제품이 발전하고 변화에 유연하게 대처할 수 있지만 그만큼 구성원들이 힘들다.

또한 현대의 개발 환경에서는 다양한 이해관계자들과의 커뮤니케이션이 크게 증가했다. 개발자는 기획자, 디자이너뿐만 아니라 비즈니스 부서, 고객 지원팀, 그리고 때로는 직접 고객과도 소통해야 한다. 이러한 커뮤니케이션은 제품의 품질을 높이는 데 도움이 되지만, 동시에 개발에 집중할 수 있는 시간을 줄이는 요인이 된다.

DevOps 프로젝트에서 매주 마감이 있는 삶을 장기간 지속하다보면 기술 부채에 대한 불안감도 높아진다. 기술 부채란 현재의 요구사항 달성을 위해 미래의 품질이나 유지보수성을 희생하는것을 뜻한다. 시간 압박은 개발자들이 코드의 품질보다 속도에 집중하게 만드는 주요한 요소다. 이는 제품의 안 좋은 영향을 미칠 뿐 아니라 유능한 인재 유입을 막는 걸림돌로도 작용할 수 있다.

개발자 개인으로 봤을때 빨라진 업무 템포는 삶의 여유를 앗아간다. 여유가 없으니 새로운 업계 기술을 학습할 시간을 가지는 것도 어려워진다. 새로운 기술을 학습하는것을 좋아하고, 또 해야하는 일이 프로그래머 일인데, 업무 스타일이 오히려 그들의 성장을 막을수도 있는 것이다.

이에 대비되는 워터폴방식은 매 단계마다 계획된 기간이 있고 그 일정동안 안정적으로 계획된 해당Task만 수행하게 된다. 유연하게 요구사항을 수용하거나 변화에 대처할 수 없지만 노동자 입장에서 업무를 분산해 계획적으로 삶을 살아가는데 도움이 된다. 물론 워터폴 모델 프로젝트에서 일정을 빠듯하게 산정하지 않는다면 애자일방식보다 더 ‘갈려’나가는 경우도 많이 있지만 말이다.

언제 어떻게 당당하게 쉴 것인가?

애자일 방식으로 일하더라도 이번 스프린트에 담을 개발 요건을 담을 때 현실적으로 생각해야 한다. 개발자들은 코드를 작성하는 것 외에도 많은 일을 한다. 코드 리뷰, 테스트, 문서화, 장애 대응 등 순수 개발 시간 외의 업무도 상당하다. 또한 기술 부채를 해결하고 새로운 기술을 학습할 시간도 필요하다. 이런 시간들을 스프린트 계획에 명시적으로 포함시켜야 한다. “이번 스프린트는 기술 부채 해결에 집중하겠습니다”라고 당당하게 말할 수 있어야 한다.

기획자도 버퍼가 필요하다

새 차를 구입하면 1,000km 정도는 길들이기 운전을 한다. 엔진과 변속기가 최적의 상태로 자리 잡도록 하기 위해서다. 소프트웨어도 마찬가지다. 새로운 기능이 추가되면 사용자들의 반응을 보고, 발생하는 문제들을 해결하고, 시스템이 안정화되는 시간이 필요하다. 기획자들도 이 시간을 활용해 다음 기능을 더 깊이 고민하고, 사용자 피드백을 수집하며, 개선점을 찾아야 한다. 이런 버퍼 시간은 낭비가 아니라 더 나은 제품을 만들기 위한 필수적인 과정이다. 개발자들이 충분한 시간을 갖고 기술부채 해결과 리펙토링을 할 때 기획자는 제품을 한 걸음 떨어져 바라보면서 발전 방향을 고민해야 한다. 새로운 것이 떠오르지 않아도, 분명 깊은 생각은 어떤 방식으로든 제품에 좋은 영향을 줄 것이다.

달라진 환경에도 모두가 행복한 개발 문화를 만들자

빠른 개발과 잦은 배포가 현대 소프트웨어 개발의 표준이 된 것은 부정할 수 없는 현실이다. 하지만 이것이 우리 기획자와 개발자들의 삶의 질을 희생해야 한다는 뜻은 아니다. 현실적인 일정 산정, 기술 부채 해결을 위한 시간 확보, 학습과 성장을 위한 여유, 그리고 안정화를 위한 버퍼 시간 등을 통해 지속 가능한 개발 문화를 만들어갈 수 있다. 이는 개발자와 기획자 모두의 노력이 필요한 일이다. 결국 행복한 개발자가 좋은 제품을 만들고, 이는 회사의 성공으로 이어진다는 것을 잊지 말아야 한다.