글을 작성하게 된 계기

최근 회사에서 일하며 기술과 비즈니스 사이에서 고민이 많았습니다. 그 과정에서 느낀 점을 정리해 보고 싶어 글을 작성하게 되었습니다.

1. 기술은 수단이지 목적이 아니다

실무를 경험하며 가장 크게 느낀 점은, 기술도 중요하지만 비즈니스는 더 중요하다 는 점입니다. 취업 전에는 새로운 기술을 빠르게 익히고 적용하는 능력이 가장 중요하다고 생각해 왔는데, 회사에서는 한정된 리소스 로 고객이 원하는 가치 를 시간 안에 제공하는 역량 이 최우선시 되기 때문입니다. 즉, 기술은 알고 있더라도, 비즈니스를 이해하지 못하면 개발자가 아무런 문제도 해결할 수 없습니다.

비즈니스를 이해하지 못해 코드 한 줄 작성하지 못할 날도 꽤 많았고, 사수님께 고민상담을 많이 했네요. 🥲

최근 유지보수를 맡았던 순수 자바 기반의 데몬 서비스 는 1.8 버전에 하드코딩된 로직으로 하루 수십만 건의 거래를 처리하고, 수익을 창출하고 있었습니다. 처음에 이를 봤을 때, 스프링부트로 새로 만들어야 겠는데? 라는 생각과, 이미 비즈니스를 잘 수행하고 있는 시스템을 무조건 오래 됐다고 개선하는게 맞을까? 하는 생각이 동시에 들었습니다. 이 과정에서 다음과 같은 고민을 하게 됐습니다.

개발자는 어떤 존재일까?
개발자는 특별한 직업일까?
개발자는 회사에서 무슨 일을 해야 하는 것일까?
꼭 좋은 코드와 좋은 시스템이 회사의 가치를 높이는 것일까?
회사원이 회사에 존재하는 이유는 무엇일까?

이 고민을 몇 주 가까이 하다가 기술은 비즈니스 가치를 실현하기 위한 도구 라는 결론에 도달하게 되었습니다. 어떤 기술을 쓰느냐보다, 현재 기술로 어디 까지 문제를 해결할 수 있고, 그것이 어떤 가치를 만들어내는가 가 더 중요하다는 생각이 들었거든요. 결국 개발자도 회사원이고, 회사원은 회사가 성장할 수 있도록 일하는 사람이며, 이를 위해서는 고객이 만족할 수 있는 서비스를 제공해야 하니까요.

물론 도구 때문에 비즈니스 성장이 발목을 잡힐 수도 있기 때문에 어떤 도구를 선택하는지도 중요합니다.

깨달음(?)을 얻은 후, 낡았다는 이유로 시스템을 개편하려고 했던 과거의 저 자신이 너무 부끄러워졌습니다. 기술은 비즈니스 가치를 실현하기 위한 도구일 뿐인데, 회사가 하고 싶은 사업보다 레거시 시스템 개편에 더 집중한 게 아닌가? 하는 생각이 들어서요.

팀원들은 20년간 못 바꾸던 시스템을 개편해서 생산성이 높아졌다고 말씀 해주셨는데, 스스로는 너무 찜찜했습니다. 🥲

2. 기술적 변화가 필요한 상황

그렇다고 새로운 기술을 학습하는 것이 중요하지 않다거나, 기존 시스템을 그대로 유지하는 것이 최선이라는 말은 아닙니다. 시스템에 장애가 자주 발생하거나 복구에 지나치게 많은 시간이 소요되는 경우, 혹은 성능 저하로 인해 비즈니스에 지장을 주는 경우 라면, 그때는 학습을 통해 기술을 습득하고 변화를 줘야 합니다. 단, 여기에는 명확한 목적과 근거, 점진적 변화, 회사의 지원 이 필요 합니다.

명확한 목적과 근거
점진적 변화
회사의 지원

2-1. 명확한 목적과 근거

시스템과 기술, 코드를 변경하기 위해서는 명확한 목적 과 근거 가 필요합니다. 명확한 목적과 근거는 현재 기술이 비즈니스의 성장을 저해하는 경우 입니다.

기능 개발/유지보수, 장애 복구 시 너무 많은 시간이 소요되는 경우요.

예를 들어, 5명으로 구성된 팀에서 운영하는 서비스에 하루 평균 10건의 장애가 발생하며, 이를 복구하는 데 평균 한 시간이 소요된다고 가정해 보겠습니다. 한 시간 동안 수천 명의 고객이 이탈하게 되고요. 이는 분명히 개선이 필요한 지점입니다. 한 명당 하루 평균 두 개의 장애를 처리해야 하며, 8시간 중, 1/4을, 장애를 대비하는 데 사용되며, 설사 해결하더라도 사용자가 이탈하니까요.

이 경우는 유지보수에 너무 많은 시간이 소요되고, 고객 이탈로 비즈니스 성장까지 저해하고 있습니다.

단순히 기술이 낡았으니 바꾸자 는 기술적 관점의 접근은 설득력 떨어집니다. 현재 시스템이 안정적으로 트래픽을 수용하고, 성능상 문제없이 비즈니스 임팩트를 지속적으로 만들어내고 있다면, 굳이 이를 개편할 이유는 없습니다. 즉, 기존 기술이 회사의 비즈니스와 성장에 발목을 잡지 않는다면 이는 개선할 필요가 없으며, 이미 충분히 훌륭한 시스템 입니다.

제가 기술이 오래 됐다고 무조건 개편하려는 실수를 했기 때문에 더 와닿고 반성됩니다. 🙇

개선할 때도 항상 비용을 고려하며 진행해야 합니다. 우리에게 주어진 시간은 한정돼 있으니까요. 아무리 기술적으로 더 나은 선택이라 해도, 그것을 구현하는 데 드는 시간과 인력이 과도하게 소모된다면 오히려 다른 중요한 기회를 놓칠 수 있습니다. 결국 모든 개선은 비용이 얼마나 들었고, 그로 인해 무엇을 얻었는지 에서 자유로울 수 없죠.

더 빠르고 안정적인 구조로 개선 할 수 있는 여지가 있다면. 그리고 그것이 장기적으로 유지보수성과 생산성을 향상시킬 수 있다면. 혹은 기술적인 한계로 인해 비즈니스가 하고 싶은 일을 하지 못하는 상황 이라면 변화해야 합니다. 단, 기술 변화나 도입 여부는 장애 빈도, 대응 속도, 개발 생산성, 비즈니스 확장성 등 비즈니스를 기준으로 판단 하며, 이 과정에서 현실 적합성을 고려해야 하고요.

2-2. 점진적 변화

간단한 코드 변경은 괜찮지만, 시스템을 변경할 때는 점진적으로 개선해야 합니다. 예를 들어, PG사에서 결제 시스템을 새로 만든다고 하면 이는 회사를 새로 만든다는 것 과 비슷하죠. 여기에는 수많은 비즈니스 정책, 고객별 커스터마이징 등 회사가 오랜 기간 축적해 온 문맥이 담겨 있으니까요. 이를 무작정 처음부터 다시 만든다면 기존 시스템이 해결하고 있는 수많은 예외 케이스와 비즈니스 룰을 모두 다시 정의하고 구현해야 합니다.

When you throw away code and start from scratch, you are throwing away all that knowledge.

만약 이 과정에서 테스트 코드 없이, 일정에 맞춰 빠르게 기능 구현만 한다면 기존 시스템보다 더 위험한 폭탄이 될 수도 있습니다. 기존 시스템은 수많은 장애와 시행착오를 거치며 안정화되어 온 결과물인데, 안정적인 장치도 없이 이를 새로 만든다는 것은 과거의 모든 리스크를 감수하는 것과 비슷하니까요. 오히려 기술 부채만 더 남길 수도 있죠. 따라서 변화가 필요할 때는 점진적으로, 부분적으로 개편하며, 이를 통제할 수 있는 수단을 마련하며 점진적으로 진행해야 합니다.

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise

2-3. 회사의 지원

마지막으로, 시스템 개편은 반드시 회사의 지원 이 있을 때만 진행해야 합니다. 단순히 개인이나 팀원의 의지로는 어렵고, 팀 또는 전사 차원의 명확한 지원과 공감대가 있어야 합니다. 하루에 일할 수 있는 시간은 한정되어 있고, 개발자에게는 이미 주어진 유지보수, 신규 기능 개발 등의 업무가 있기 때문입니다. 조직이 리소스를 투입하고 우선순위를 조정해 주지 않는다면, 기존 업무와 충돌하거나 애매하게 진행되다 멈추기 쉽습니다.

입사 초, 개편 중 엎어진 프로젝트가 수 십개라는 이야기를 들었을 때, 이해를 못했는데 업무를 하다보니 알겠더라고요.

기술적 변화는 이상적인 방향일 수 있지만, 현실적인 실행력은 결국 조직의 의지와 리소스 배분에서 나오기 때문에, 이를 간과한 채 시작하는 개편은 오히려 팀 전체에 부담만 가중시키는 결과를 초래할 수 있습니다. 정말 필요한 변화라면, 그 중요성을 조직에 설득하고 공식적인 동의를 얻어야 합니다. 따라서 명확한 근거가 있을 때, 점진적으로, 회사의 지원을 받고 이를 진행해야 합니다.

명확한 근거가 있을 때 개편을 진행한다.
점진적으로 시스템을 개편한다.
회사의 지원이 없다면 하지 않는다.

3. 정리

최근 회사에서 봤던 순수 자바 데몬 과 메인 시스템을 마이크로 서비스로 개편하는 것, 개발 일정이 딜레이 되는 것 등을 보고 겪고 있는데, 정말 많은 생각이 들고 있습니다. 기술과 시스템, 코드가 가장 중요하다고 생각했는데, 개발자로서 가장 중요하게 여기고 있던 것들이 깨지고 있어서요. 그렇다고 변화가 잘못 됐다거나, 학습을 하지 않겠다는 의미는 전혀 아닙니다. 비즈니스에 조금 더 관심을 가지고, 이를 어떻게 기술로 해결할 수 있을지에 집중하며 이 과정에서 최선의 기술적 선택을 할 수 있도록 노력해야겠다는 생각이 듭니다.

기술도 중요하지만 비즈니스는 더 중요하다

글을 작성하게 된 계기

1. 기술은 수단이지 목적이 아니다

2. 기술적 변화가 필요한 상황

2-1. 명확한 목적과 근거

2-2. 점진적 변화

2-3. 회사의 지원

3. 정리

Further Reading

IntelliJ Connection Read-Only 설정하기

ISO Week Numbering: ISO 주와 일반 주의 차이점

Git History 관리 중 발생한 충돌 해결기