카페 창업으로 알아보는 프로젝트 모듈화

시작하기

프로젝트를 개발하다 보면 코드의 규모가 커져서 유지보수하기 어려워지는 경우가 많습니다. 이러한 문제를 해결하기 위해 모듈화가 등장하게 되었습니다. 모듈화란 프로젝트를 여러 개의 독립된 모듈로 분리하여 개발하는 방법을 말합니다.

모듈화는 소프트웨어 개발에서 중요한 개념이지만, 모듈화를 적용했을때의 장점이 와닿지 않아 중요성을 이해하기 어려울 수 있습니다. 따라서 이번 글에서는 카페 창업과 관련된 비유를 통해 모듈화의 필요성과 적용 시 장점에 대해 알아보겠습니다.

카페 창업

여러분은 이제 카페를 창업하는 사장입니다. 창업 자금이 제한적이지만, 열심히 커피를 만들어서 규모를 점차 확장하고, 결국에는 성공적인 사업가로 거듭나려는 큰 꿈을 품고 있습니다. 처음에는 작은 규모의 카페에서 스스로 모든 업무를 수행하면서 시작할 것입니다. 여러분은 카페 창업을 통해 어떻게 모듈화와 유사한 원리가 작동하는지에 대한 깊은 통찰력을 얻게 될 것입니다. 이제 시작해봅시다.

카페 창업의 초반

처음에는 모든 것을 혼자서 처리해야 합니다. 프랜차이즈 업무와 카페 운영 업무를 모두 동시에 진행하며, 이 모든 업무를 조절하고 효율적으로 운영해야 합니다. 오픈 준비에도 시간이 걸리지만 작은 규모라 손님 수도 적어서 아직까지는 딱히 문제가 없습니다. 시간도 널널하고 평소보다 조금만 더 부지런하면 되니까요.

• 카페 주인: “이 카페는 나 혼자 운영하니까 힘들지만, 아직은 모든 일을 제어할 수 있어. 프랜차이즈 업무와 카페 업무 모두 나 혼자서 맡아. 하지만 손님이 많지 않아서 버틸 만해.”

업무 확장과 협업의 필요

카페가 성장하면서 더 많은 손님을 받게 되면, 한 사람으로는 모든 일을 처리하기 어려워집니다. 그래서 직원을 추가 고용하여 프랜차이즈 업무와 카페 운영 업무를 분리합니다. 이렇게 업무를 나눔으로써 일의 속도는 더 빨라집니다. 물론, 서로 다른 업무를 담당하게 되므로 소통이 중요해집니다. 하지만 공통된 지침과 요청서를 통해 효율적으로 소통할 수 있습니다. 더욱 중요한 것은 한 사람의 업무 부담이 줄어든다는 것입니다.

만약 두 명의 직원이 동일한 업무를 하고 있었다면, 새로운 업무가 추가될 때 교육과 훈련이 필요했을 것입니다. 이 때, 한 명의 직원이 숙련되지 못하거나 과중한 교육으로 인해 도망친다면 카페 운영에 차질이 생길수 있습니다.

• 매니저: “저는 프랜차이즈 업무를 담당하고, 다른 분은 카페 운영 업무를 맡아요. 이렇게 업무를 분리하니 더 효율적으로 일할 수 있어요. 서로의 업무에 대해 잘 모르지만 공통된 지침을 통해 원활하게 소통해요.”

업무의 더 자세한 분리

카페의 규모가 커지면서 업무를 더 자세하게 분리하게 됩니다. 프랜차이즈 업무, 재고 관리, 카페 운영 업무로 나누어집니다. 이제 직원들은 각자 독립적으로 움직입니다. 이전 보다 각 직원에게 업무를 추가하거나 뺄 때 더 편리합니다. 또한 매장 오픈 준비 시간이 크게 단축됩니다.

• 매장 관리자: “프랜차이즈 업무 직원, 재고 관리 직원, 카페 운영 직원으로 업무가 나눠져 있어요. 이렇게 업무를 나누니 업무를 추가하거나 뺄 때 훨씬 편하고, 매장 오픈 준비 시간도 줄었어요. 각 인원의 업무가 독립적으로 움직이니 더 효율적이에요.”

대규모 매장의 층별 분리

이제는 매장이 공장 수준으로 커졌습니다. 그래서 업무를 더 자세하게 나누고 층을 분리했습니다. 예를 들어, 3층은 사무실로 사용되며 제품 발주 팀, 가맹비 입금 팀, 신메뉴 교육 팀이 있는 층입니다. 2층은 창고로 사용되며 청소 팀, 재고 정리 팀, 제품 진열 팀이 있는 층입니다. 1층 매장에서는 커피 만들기 팀, 서빙 팀, 주문 받기 팀이 있습니다.

이렇게 층과 팀을 나눔으로써 여러 가지 장점이 있습니다. 신규 인력을 추가할 때 해당 층에 바로 배치할 수 있고, 퇴사 인력이 발생해도 유관 부서를 빠르게 정리할 수 있습니다. 각 팀은 자신의 파트를 준비하기만 하면 되므로 매장 오픈 준비 시간이 획기적으로 줄어듭니다. 또한, 공통으로 사용하는 기기와 자원은 한 곳에서 관리하기가 편리하며, 각 층의 팀이 통째로 교체되더라도 서로 통신하는 방식이 동일하다면 문제가 없습니다.

• 매장 매니저: “매장이 이렇게나 커졌어요. 이제는 층마다 업무를 독립적으로 나눠서 진행하고 있어요. 신규 인력이 추가되어도 해당 층에 바로 편입시키고, 퇴사 인력도 더 빨리 대응할 수 있어요. 매장 오픈 준비도 훨씬 효율적이에요. 공통으로 사용하는 기기와 자원은 한 곳에서 관리하기 편해서 관리도 간편해요.”

팀 별 연관성(종속성)

상호 연관 관계

이번에는 팀간의 관계에 대해서 알아보도록 합시다. 우리는 카페를 효율적으로 운영하기 위해 카운터 직원을 대체할 키오스크를 도입했습니다. 바리스타는 이를 통해 주문을 받았죠.

돈을 아끼기위해 키오스크를 썼더니 처음에는 주문 방식이 매우 비효율적이었습니다. 바리스타는 주문을 처리하기 위해 영수증 출력 방법과 같은 키오스크의 사용 방법을 알아야했고, 키오스크는 주문을 받기 위해 바리스타의 작업 방식이나 만들 수 있는 커피 종류를 알아야 했습니다.

둘 다 서로에게 의존하며, 업무를 진행하기 위해서는 상호적인 협력이 필요했습니다. 그러나 바리스타가 출근하지 않으면 키오스크는 동작할 수 없고, 키오스크에 문제가 생기면 바리스타는 주문을 받을 수 없게 됩니다. 또한 주문이 들어올 때마다 바리스타가 키오스크까지 확인하러 가야 하는 번거로움도 있었습니다. 어떻게 하면 둘 사이를 원활하게 소통시킬수 있을까요?

해결 방법은 생각보다 간단합니다. 둘 사이를 연결하는 주문 시스템을 도입하는 겁니다. 이를 통해 서로간의 연결이 최소화 됩니다. 예를 들어, 키오스크와 바리스타 팀은 커피 주문을 처리해야 할 때가 있습니다. 그래서 우리는 공통적인 규격을 통해 이러한 팀 간의 참조를 끊어버립니다. 이러한 규격을 통해 키오스크와 바리스타 팀은 서로의 업무를 알 필요가 없고, 컴퓨터가 중간에서 주문을 관리합니다.

이러한 공통 규격을 통해 팀 간의 연관성을 제거할 수 있습니다. 각 팀은 자신의 업무를 독립적으로 수행하면서 공통 규격을 준수하여 소통합니다. 이렇게 하면 업무 추가나 변경이 더 쉬워지며, 팀 간의 협력이 원활해집니다.

커피 주문 플로우

그러면 구체적인 사례를 보도록 합시다. 위의 그림은 커피를 주문하는 과정이고 아래와 같은 순서로 진행됩니다.

• 고객이 주문을 하면 키오스크가 주문을 받아서 주문 시스템으로 전송합니다.

• 그리고 주문 시스템이 바리스타 팀에게 주문서를 보냅니다.

• 바리스타 팀은 커피를 만들기 시작합니다.

• 주문이 완료되면 주문 시스템이 알림벨로 완료 메시지를 전송합니다.

• 알림벨이 손님에게 커피가 준비되었다고 알려줍니다.

• 고객은 본인이 주문한 커피를 받아갑니다.

주문 시스템이라는 공통 규격을 통해 키오스크, 바리스타, 알림벨 사이의 비효율적인 연관 관계가 사라집니다.

만약 서로 간의 연관 관계, 즉 [종속성]이 강력하다면 어떤 문제가 발생할까요? 키오스크나 알림벨 디바이스가 교체될 때 바리스타가 사용법을 다시 배워야하거나 바리스타가 변경되면 만들수 있는 커피에 대해서 일일히 입력해줘야하는다는 문제가 발생합니다. 또한 제과/제빵과 같은 새로운 팀을 추가하기도 어렵습니다. 원활한 소통과 유지 보수를 위해 공통의 규격을 사용하는건 상당히 중요합니다.

원두 주문 플로우

이번에는 조금 더 복잡한 사례입니다. 위의 그림은 매장의 원두가 떨어져서 바리스타가 본사에 주문을 하는 과정입니다. 층 별로 창고와 사무실이 나눠져 있기 때문에 바리스타는 공통된 규격인 재고 관리 시스템으로 새로운 원두를 요청합니다.

어떤식으로 본사에 발주를 요청하는지 바리스타는 몰라도 됩니다. 따라서 재고 담당 직원이나 본사 매니저가 변경이 되어도 업무하는데는 큰 지장이 없습니다. 결국 바리스타에게는 원두가 필요하고, 이러한 업무는 공통의 규격을 통해 유기적으로 진행됩니다.

프로그램에 적용해보기

카페의 규모가 확장되는 것은 프로그램의 크기가 커지는 것과 유사합니다. 카페의 팀은 모듈에, 층은 프로그램의 다양한 레이어에 해당한다고 볼 수 있습니다. 모듈화를 통해 이루어지는 소프트웨어 개발의 장점들이 카페 운영에도 적용됩니다. 카페에서 팀과 층을 나누는 것이 어떻게 모듈화와 대응되는지 살펴보겠습니다.

코드 재사용성

• 카페 : 공통으로 사용되는 집기 등이 한 곳에서 효율적으로 관리됩니다. 이것은 집기의 재사용성과 관리의 효율을 높이고 단순화합니다. 굳이 공통의 집기가 아니더라도 각각의 팀은 재사용이 가능합니다. 회계팀에서 만들어놓은 법인 카드 청구서를 통해 재고 관리팀이나 청소팀에서 비품을 주문할 수도 있습니다.

• 개발 : 모듈화를 통해 공통적인 기능을 분리하면, 이후에 다른 프로젝트에서도 해당 모듈을 재사용할 수 있습니다. 이는 개발 시간을 단축시키고 효율적으로 개발할 수 있는 장점을 제공합니다.

유지보수 용이성

• 카페 : 신규 인원이 추가되었을 때 해당 층에 쉽게 배치할 수 있습니다. 퇴사 인원이 발생했을 때도 유관 부서가 명확하게 구분되어 있어서 문제를 신속하게 해결할 수 있습니다. 한 층의 인원이 전면적으로 변경되더라도 각자의 역할과 규격을 유지하므로 문제가 발생하지 않습니다.

• 개발 : 프로그램에 새로운 모듈을 추가하거나 기존의 모듈을 제거할 때 모듈화가 되어있다면 종속성의 영향이 적어 빠른 작업이 가능합니다. 즉, 유지 보수가 효율적으로 이루어집니다. 이것은 모듈이 독립적으로 동작할 수 있도록 구성되어 있을 때의 이점과 관련이 있습니다.

빌드 시간 단축

• 카페 : 각 팀이 자신의 업무에만 집중하면 되기 때문에 매장 오픈 준비 시간이 크게 단축됩니다. 이것은 빌드 시간을 줄이는 데 도움이 됩니다.

• 개발 : 모듈화를 통해 앱을 여러 개의 모듈로 분리하면, 필요한 모듈만 빌드하여 테스트하거나 배포할 수 있습니다. 또한 안드로이드의 Compose나 iOS 의 SwiftUI 등과 같은 네이티브 언어로 구성된 선언형 UI는 프리뷰 로딩을 위해 컴파일이 필요한데, 빌드 시간을 단축시킴으로써 개발자의 생산성을 높이는 빠른 개발이 가능해집니다.

결론

결론적으로, 카페 규모가 작은 경우에는 하나의 직원만 고용해도 운영이 가능하지만, 규모가 커질수록 비효율적이며 유지 보수 측면에서도 어려워집니다. 이와 마찬가지로, 소프트웨어 개발에서도 초기에는 모듈화를 강조하지 않더라도 프로그램 규모가 커지면서 모듈화가 매우 중요한 역할을 하게 됩니다. 이러한 관점에서 모듈화는 소프트웨어 개발에서 필수적인 작업 중 하나입니다.

모듈화는 코드 개발 시 발생할 수 있는 코드의 복잡도와 유지보수의 어려움을 해결할 수 있는 좋은 방법입니다. 모듈화를 통해 코드의 재사용성을 높이고, 유지보수를 용이하게 하며, 빌드 시간을 단축시킬 수 있습니다. 따라서, 개발에 모듈화를 적용하여 효율적인 개발을 할 수 있도록 노력해야 합니다.

Medium

성공적으로 새로운 기술을 도입하는 방법

개발자들은 업무를 진행하면서 퍼포먼스를 올릴수 있는 방법에 대해서 끊임없이 고민하고 연구한다. 몇 줄의 코드를 수정하거나 적절한 알고리즘을 도입하는 것으로도 유의미한 변화를 만들어 낼 수도 있지만, 때에 따라서는 새로운 기술을 도입해야하는 경우도 있다. 간단하게는 신규 라이브러리의 적용 부터, 크게는 자동화 프로세스의 구축이나 아키텍쳐의 변경까지, 그 종류는 매우 다양하다.

그러나 이를 성공적으로 수행하기 위해서는 단순히 기술 적용을 위한 난이도만 고려해서는 안된다. 혹시 회사에서 새로운 것을 시도해보려고 하는데 번번히 실패한 경험이 있지 않은가? 나는 꼭 필요한 것이라고 생각하고 시도했는데 생각보다 잘 풀리지 않아 포기한 경험이 있는가? 그렇다면 다음과 같이 성공적으로 새로운 기술을 도입하는 몇 가지 절차와 방법에 대해 주목해보자.

꼭 필요한 기술인지 다시 확인해보자

규모가 큰 회사일수록 신규로 도입되는 기술에 대한 검증이나 리스크 관리가 철저하게 진행되지만, 인원이 적은 소규모 기업이나 스타트업에서는 몇명의 의사 결정이 기술적인 방향성을 좌우하게 된다. 따라서 한가지 장점에만 매몰되어 잘못된 선택을 하게 된다면 많은 체력 소모와 자원 낭비가 뒤따르게 되므로 신중하게 결정하도록 해야한다.

많은 개발자들이 컨퍼런스나 기술 블로그등으로 새로운 기술을 접했을 때 장점만 보고 도입을 결정하는 실수를 범한다. 기술 도입을 통해 현재 맞닥뜨리고 있는 많은 문제들이 마법처럼 해결될것이라고 생각한다. 그러나 프로젝트에 기술적 환경이 뒷받침되지 않아 적용 불가능하거나, 막상 적용해 보니 검토가 충분치 않아 장점보다 단점이 많은 상황이 되어버릴 수도 있다. 또한 해당 기술을 도입하는데 리소스 낭비가 너무 심해 정작 중요한 작업들을 처리할수 없게 되어 버린다. 따라서 아래의 항목들을 확인해보고 다시 한번 필요한 기술인지 검증해 볼 필요가 있다.

1. 기술을 도입할수 있는 환경이 구축되었는지
2. 해당 기술의 장/단점은 무엇인지, 어떤 문제들을 해결할수 있는지
3. 해당 기술을 도입하는것 보다 우선 순위가 더 높은 작업은 없는지
4. 기술 도입 이후 유지보수/추가 적인 인력의 소모가 없는지

토이 프로젝트로 검증하자

새로운 기술의 도입은 언제나 보수적으로 접근해야한다. 검토가 충분치 않은 기술은 마치 검역이 안된 외래종과 같아서 기존 생태계를 교란시키는 악영향을 미칠수 있다.

이러한 ‘검역’의 절차를 대신할수 있는 것이 바로 토이 프로젝트이다. 대부분의 기술이 적용을 위한 훌륭한 문서들을 제공하고 있지만, 실제 적용 단계에서는 문서에 없는 문제들이 발생해서 우리들을 괴롭힌다. 이를 해결하기 위해서 적용을 목표로 하고 있는 코드와 유사한 토이 프로젝트를 생성하여 선행적으로 기술을 사용해 봐야한다. 이를 통해 장단점을 명확하게 하고, 현재 타겟 프로젝트의 구조 내에서 발생할수 있는 문제를 작은 단위로 체험할수 있게 된다. 또한 토이 프로젝트는 고려해야할 코드의 양이 적기 때문에 좀 더 빠르게 테스트해 볼 수 있으며, 이렇게 테스트한 코드는 다른 개발자들을 설득하거나 구조를 설명할 수 있는 훌륭한 샘플이 된다.

기술 도입의 공감을 얻자

기술을 적용하기 위해서는 ‘왜’ 라는 물음이 충족되어야한다. 다시 말해 왜 이 기술을 도입해야하며, 이로 인해 우리가 얻을수 있는 것들이 무엇인지 명확해야한다는 뜻이다. 만약 이것이 충족되지 않는다면 작업을 진행할수 없을 뿐더러, 시작하게 되더라도 적절한 지원을 받지 못하고 많은 리스크를 떠앉게 된다.

공감을 얻어야할 대상은 크게 두 부류로 나뉘는데 첫번째는 같은 개발자 동료들이다. ‘이미 중요한 이슈들이 많은데’, ‘굳이 저 기술을 도입해야해?’ 등 부정적인 의견이 지배적인 상황에서는 효과적으로 작업을 진행할 수 없다. 따라서 앞서 언급한 검토 단계에서 정리된 장단점과 파급 효과를 정리해 동료들에게 공유하자. 이 단계에서 의견 교환은 단방향이 아니라 양방향으로 진행되어야한다. 중요한점은 설득이 아닌 논의의 자리라는 것이다. 이렇게 수렴한 동료 의견 중, 그들이 우려하는 부분을 끝내 해결하지 못한다면 기술을 재검토하거나 기술 방향성을 바꿔볼 필요가 있다. 이를 모두가 수긍할 수 없더라도 논의를 통해 장기적인 방향성을 확인할수 있다면 다음에는 더 적절한 기술을 찾아낼수도 있다.만약 이 과정이 훌륭하게 진행되어 다수의 동의와 공감을 얻어냈을 경우 기술 도입은 일사천리로 진행될 것이다.

두번째는, 경영진이나 PM 등의 비개발자 직군이다. 만약 기술 도입의 범위가 작다면 비개발자 직군에게 공감을 얻을 필요 없이 기능 조직 내에서 빠르게 의사 결정을 해서 업무를 진행하면 된다. 그러나 범위와 리소스가 큰 작업의 경우 일정을 관리하는 비개발자 직군에게 협조를 요청해야한다. 당연한 이야기지만 기술 도입에 따른 장단점을 개발자적인 시각에서만 풀어내면 비개발자 직군은 필요성에 대해 공감하지 않을것이다. 그보다는 회사의 입장에서, 다시 말해 비즈니스 관점에서 생각해보는것이 경영진을 설득하는데 더 효과적이다. 예를 들어, 아키텍쳐를 변경해서 코드 간의 종속성과 빌드 시간을 줄이고 도메인 로직의 응집력을 높이고 싶다는 의견은 경영진이나 비개발자의 시각에서 전혀 와닿지 않을 것이다. 그보다는 신기술 도입을 통해 안정성과 피쳐의 개발 속도가 높아지고 결과적으로 빠른 개발 주기를 통해 시장을 선점하거나 많은 기획을 검증해볼수 있다는 설명이 이전의 내용들보다 효과적으로 작용할 수 있을것이다.

중요한것은 기술적인 근거가 중요하지 않다는 뜻이 아니라 설득하고 공감을 얻어낼 대상이 누군가에 따라서 전략을 다르게 취해야한다는 것이다. 우리의 언어가 아닌 상대방의 언어로 변환하여 의견을 전달하는것이 이 단계의 핵심이다.

1. 동료 개발자들에게 공감을 얻어내자. 부정적인 의견이 있더라도 논의를 통해 긍정적인 방향성으로 유도해내자.
2. 비개발자 직군을 설득해야하는 경우, 비즈니스 적인 관점에서도 기술 도입을 해야하는 이유를 찾아보자

분할 정복하자

적용 범위가 큰 경우 대다수의 개발자들은 범위내 변경사항을 최소화 시키면서 기술을 적용시키고 싶어한다. 예를 들어, 대규모 레거시를 걷어내고 새로운 아키텍쳐를 적용하는 작업을 가정해보자. 개발자에게 이상적인 작업 환경은 새로운 프로젝트를 생성하여 기존 프로젝트를 새 아키텍쳐에 맞게 이관하는 것이다.

그러나 현실적으로 코드의 양이 너무나도 많을것이므로 이렇게 할수도 없을뿐더러, 진행한다고 해도 작업 기간 동안에는 정상적으로 서비스 운영이 어렵다. 회사 측면에서는 정상적으로 서비스를 운영하면서 기술을 도입하길 원한다. 비유하자면 우리는 날아가는 로켓위에 올라타 로켓의 부품을 교체하면서 목표까지 안정적으로 도달하는 방법을 연구해야한다.

가장 심플한 방법은 작은 단위 부터 적용해 나가는 것이다. 모든 기술을 한번에 적용하려는 욕심을 버리고 가장 작은 단위부터 수정을 시작한다. 예를 들어 e-커머스 앱을 모듈화 한다면 가입-결제-구매-유저 등의 패키지를 순차적으로 적용해나가는 것이다. 기간과 그에 따른 마일스톤을 정해 하나씩 처리해나간다면 결국 초기에 설정한 목표에 도달할수 있을것이다.

또한, 이렇게 큰 범위의 수정 사항이 적용되고 있는 동안에는 다른 수정사항이나 기술 도입을 최대한 지양한다. 하나의 기술이 완전히 모든 코드에 적용된 다음 새로운 기술을 도입해야한다. 그렇지 않으면 진행 상황 체크가 어려우며 각 파일 마다 코드 작성 방식이 다른 혼란한 결과가 초래될 것이다.

다시 한번 강조하지만, 당장 레거시를 걷어내고 새로운 기술이 적용된 안락한 코드 위에서 빠르게 개발하는 것을 원하더라도, 계획대로 차근차근 적용해나가는것이 중요하다. 때로는 멀리가는 것처럼 보여도 그 길이 지름길 일 수 있다.

결과를 공유하자

성공적으로 기술을 도입했다면, 이에 그치지 않고 팀원들에게 결과를 공유하는것이 좋다. 이 때, 기술 도입 전/후의 퍼포먼스 상승 효과나 개선에 대한 객관적인 수치들이 포함되면 더욱 효과적이다.

이를 통해 긍정적인 평가를 받을 수 있으며, 다음 작업에서도 선례가 만들어져 좀 더 원활하게 업무를 진행할수 있는 선순환이 만들어진다. 열심히 작업을 했는데 그 결과를 자축하며 묻어버리기에는 너무 아깝다. 따라서 본인이 만들어 낸 결과를 적극적으로 공유하도록 하자.

결론

모든 내용들이 너무 기본적인 내용들이라 시시하다고 생각할수도 있다. 그러나 많은 개발자들이 이 내용들을 무시하고 오로지 본인이 해결하고 싶은 부분에만 집중하기 때문에, 신기술 도입이 번번히 실패로 끝나는 경우를 보았다.

물론, 각 회사의 상황에 따라 기술 도입에 대한 난이도가 천차만별이겠지만 적어도 챙길수 있는 부분은 잘 준비해서 전략적으로 움직이는게 중요하다고 생각한다. 따라서, 개인적 경험에 기반하여 쓴 이 글이 많은 개발자들에게 조금이나마 도움이 될 수 있었으면 좋겠다.