1년간의 조직 개선 여정 #1

글 앞에 번호를 붙이는 것을 그만두기로 했다. 처음에는 몇 번째 글을 쓰는지 의식하려고 했지만, 별 의미가 없다는 생각이 든다.

가장 싫어하는 여름이 다시 돌아왔고, 현재 직장에서 만 1년이라는 시간이 흘렀다. 원래는 이 1년을 정리하며 200줄 가량의 글을 썼는데, 푸념만 늘어놓게 되어 모두 지웠다. 대신 핵심적인 두 가지 성과에 대해서만 정리해보려 한다.

체계 없는 조직에 최소한의 체계 만들기

첫 번째는 체계가 전혀 없던 조직에 기본적인 시스템을 구축한 것이다. 내 기준으로 판단했을 때 이 조직의 체계는 제로가 아닌 마이너스에 가까웠다.

 

노션 기반 업무 관리 시스템 구축

기존에는 누가 어떤 일을 어떻게 하는지 모르는데 회사는 굴러가는 상황이었다. 노션을 도입해 데이터베이스로 업무관리부터 자산관리, 고객사 관리까지 기본 기능들을 만들어냈다. 칸반보드와 간트차트, 업무 플로우를 구상했고, 현재는 팀원들이 잘 따라와 주어 이슈 트래킹이 어느 정도 되고 있다.

개선 후에는 누가 어떤 일을 했고 어느 정도 시간을 들였으며, 어떤 레벨의 업무까지 각 동료가 할 수 있는지 판단할 수 있게 되었다. 그에 따라 업무 배분과 성장 방향으로 가이드를 해줄 수 있는 기반이 마련되었다.

 

주간 업무 회의 및 Sprint 도입

매주 주간 업무 회의를 진행하며 각자 어떤 업무를 어떻게 진행했는지, 어려움은 없었는지 공유하기 시작했다. 인원이 많지 않은 조직임에도 서로가 어떤 일을 하는지 몰랐던 상황에서, 처음 회의를 진행할 때 무엇을 어떻게 해야 할지 몰라하던 팀원들의 모습이 아직도 기억에 남는다.

매일 stand-up meeting이나 scrum을 하지 않고 주간 단위로 진행하는 이유는 현재 단계에서 daily meeting이 업무 복잡성만 늘린다고 판단했기 때문이다. 도움이 되는 것은 분명하지만 당장 도입할 필요는 없다고 생각했고, 언젠가는 조직이 성숙해지면 도입할 계획이다.

Sprint도 함께 도입했는데, 워낙 고쳐야 할 것이 많다 보니 현재는 1주 단위로 운영하고 있다. 앞으로 제품이 완성되어 감에 따라 2주 단위나 조직 수준에 맞춰 유연하게 변경할 생각이다.

 

점진적 개선 전략

CI/CD부터 클라우드 서비스 관리, 자산관리까지 정말 많은 것을 조금씩 손댔다. 여기서 핵심은 한 번에 하나씩 몰아치듯 하지 않았다는 점이다. 동료들이 접해보지 않은 환경을 억지로 만들어 업무 부담을 가중시키지 않으려 노력했다.

일부러 여러 개를 조금씩 나눠서 진행한 이유는 모든 문제를 인지할 수 있도록 하는 효과가 있다고 판단했기 때문이다. 고쳐야 할 것이 너무 많은데 하나씩 잡아가면 언제 끝날지 모른다. 우선 문제들을 펼쳐놓고 지속적으로 퍼블릭하게 공유하며 개선해나가는 방식을 선택했다.

물론 모든 것이 성공적이지는 않았다. 우리 팀만 이렇게 체계를 갖춰 일하고 있어 아쉬움이 크다. 하지만 조직장이 바뀌는 시점에서 "우리는 이렇게 하고 있다"는 것을 보여줌으로써 더 큰 변화의 필요성을 어필할 수 있었고, 실제로 그 덕분에 조직 차원에서 추가적인 액션을 취할 필요가 없었다.

스파게티 코드를 체계적인 아키텍처로

두 번째는 코드 작성 컨벤션과 아키텍처 개선이다. 기존 소스코드는 전형적인 SI성 코드로, 각자 따로 노는 구조였다. 테크니컬 리더가 손보지 않은 프로젝트는 아무리 작은 프로젝트라도 스파게티가 될 수밖에 없다는 것을 다시 한번 깨달았다.

 

프론트엔드 개선

백엔드와 프론트엔드를 명확하게 분리하고 React 기반으로 하나씩 개선해나갔다. Next.js 프로젝트를 터보레포 기반으로 모놀리식 처리했으며, React Query, Zustand 등을 도입하면서 나 역시 학습했다.

처음에는 Tailwind CSS를 사용했지만 적응이 어려워 현재는 MUI 기반으로 변경하고 있다. 웹 퍼블리싱에 대한 부담이 생각보다 너무 컸고, UI 개발 역량이 부족한 상황에서 그 부분에 시간을 쏟으면 제품 개발 속도가 날 수 없었기 때문이다.

 

백엔드 아키텍처 개선

도메인 단위 업무 성격이 매우 크다고 판단해 DDD 기반의 클린 아키텍처로 과감한 리팩토링을 했다. 완벽하게 유지되는 것은 아니지만 기본 형태는 남아있어, 다른 개발자가 갑자기 파악해야 하더라도 금방 이해할 수 있는 코드가 되었다.

 

인프라 및 데이터베이스 개선

Redis, MongoDB, PostgreSQL을 도입하고 MariaDB 사용을 중단했다. MariaDB에서 PostgreSQL로 전환한 가장 큰 이유는 솔루션의 멀티테넌시 요구사항 때문이었다. PostgreSQL의 schema 기반 격리와 Row Level Security(RLS) 기능이 고객별 데이터 분리에 훨씬 효과적이었다.

또한 복잡한 집계 쿼리와 분석 작업이 많은 솔루션 특성상 PostgreSQL의 윈도우 함수, CTE(Common Table Expression), 고급 인덱싱(GIN, GiST) 등이 성능상 큰 이점을 제공했다. JSON/JSONB 지원도 API 응답 캐싱이나 유연한 설정 데이터 저장에 매우 유용했다. MariaDB는 이런 고급 기능들이 제한적이거나 성능이 아쉬워서 솔루션의 복잡한 요구사항을 만족시키기 어려웠다.

 

인프라 환경은 Jenkins를 도입하고 사내 개발서버를 이용해 VM pool을 구성했다. Ubuntu에 Cockpit으로 모니터링과 VM 관리를 하면서 Jenkins 빌드 풀로 활용했다. AWS 환경은 EC2, RDS, ALB를 기본으로 세팅했다. MSA 기반으로 도메인별 분리 개발을 진행했는데, 패키지 제품 특성상 도메인별 배포가 유리하지만 그에 따른 복잡성 증가는 여전히 고민거리다.

 

Slack 기반 통합 모니터링 시스템

업무 효율성을 높이기 위해 Slack을 도입하고 webhook을 통한 다양한 모니터링 시스템을 구축했다. GitHub push notification, Jenkins 빌드 상태, AWS 개발환경 자동 On/Off 기능 등을 연동해 실시간으로 개발 현황을 파악할 수 있게 되었다.

특히 AWS 개발환경의 자동 On/Off 기능은 비용 절감과 함께 개발자들이 불필요한 인프라 관리에 신경 쓰지 않아도 되게 만들었다. 이러한 webhook 기반 notification 시스템을 통해 팀원들이 개발 프로세스의 각 단계를 실시간으로 공유하게 되면서, 업무 투명성이 크게 향상되었고 문제 발생 시 빠른 대응이 가능해졌다.

 

처음에는 어려워하던 팀원들도 어느 정도 클라우드 기반 서비스를 다룰 기회가 생겨 만족해하는 것 같다. 다만 전체 팀원이 주니어 개발자이고 신입급도 있어서 새로운 환경에 적응하는 과정에서 시행착오가 많았다. 잘못 작성하는 문서도 많았고 잘못된 코딩도 많았지만, 조금씩 고쳐가는 모습이 보였고 지금은 처음보다 훨씬 나아졌다.

물론 저항도 있었다. 한 가지 일을 하는데도 부가적으로 해야 할 것들이 많다 보니 답답함을 느끼는 팀원들이 있었다. 하지만 본인이 같은 문제에 대응할 때 본인이나 동료가 남긴 기록을 보며 더 빠르게 문제를 해결하는 경험을 스스로 겪으면서 저항감이 사라지기 시작했다.

1년간의 깨달음과 앞으로의 과제

이 글에는 실제로 진행한 변화의 일부만 담았다. 어떻게 보면 10년 넘는 경력의 총정리라는 생각으로 전체적으로 바꾸었고, 아직도 시행착오를 겪고 있지만 계속 개선해나갈 생각이다.

1년간 가장 어려웠던 점은 첫 회사이자 주니어, 신입 레벨인 동료들과 함께 일하는 것이었다. 다른 회사를 경험해보지 못한 이들은 내가 하는 것이 정말 맞는 건지 의심하는 경우도 있었고, 그 부분을 최대한 배려하며 맞춰가며 잘 따르도록 이끄는 게 정말 어려웠다. 다른 회사 사례나 주변 사례를 많이 공유했고, 필요한 아티클도 자주 소개해줬다.

예상과 달랐던 부분은 동료들의 발전 속도였다. 체계적으로 일하는 것도 버거운데 업무도 버거워했던 것 같다. 사람들은 자기가 일하던 방식으로만 하는 것에 익숙할 수밖에 없는 상황이었다.

앞으로 더 해야 할 것은 보안적인 부분과 기술적 고민들이다. 지금까지 내린 결정들이 정말 맞는지 아직 확신이 서지 않는다. 솔루션 제품이라 즉각적인 피드백을 받기 어려운 것도 있다. 특히 MSA 기반 개발이 잘한 선택인지도 고민이다. 도메인별 분리와 패키징에는 도움이 되지만 그에 따른 복잡성 증가를 어떻게 해결할지가 과제다. 모놀리식으로 바꾸기에는 패키지 관리가 더 어려울 것 같아 딜레마에 빠져있다.

남들이 보면 "이정도는 어느 회사나 다 되어 있잖아"라고 할 수 있지만, 그렇지 않은 곳도 분명 있다. 다음 글에서는 조금 더 구체적인 이야기를 풀어보려 한다.