두개의 물류 센터 오픈을 동시에 지원한 방법

• 주의 1. 이 글은 소속 회사의 입장을 대변하지 않습니다.
• 주의 2. 이 글에는 늘 그렇듯이 현명함 보다는 멍청함이 묻어 있습니다.
• 주의 3. 선택한 방법과 주장하는 바가 옳지 않을 수 있습니다.
• 주의 4. 위의 이유로 예고없이 삭제될 수 있습니다.
• 주의 5. 수정할 사항이 있다면 댓글에 남겨주세요. 검증 후 본문을 업데이트 하겠습니다.

배경

가끔 개발자들이 완벽한 프로덕트를 위해 무언가를 늦춰야 한다고 이야기합니다. 맞습니다. 가끔은 시간 보다는 품질이 중요할 때가 있습니다. 하지만 대부분의 사업은 충분한 시간이 오히려 적이 되는 경우도 많습니다.(소속 회사의 사정을 말하는게 아닙니다) 프로덕트, 또는 서비스는, 그 가치가 지속 가능하기 위해서 이윤을 남겨야 하거나 그것을 벌어들이는 도구일 수 밖에 없습니다. 그런데 가끔은 그런 것들을 망각하는 경우도 많은 것 같습니다.
 
 
시간이 많지 않은 상황에서 우리는 두개의 센터를 연달아 가동시켜야 할 상황이 되었고 저와 우리 팀, 전체의 조직이 해당 목표를 달성하기 위하여 힘차게 뛰어야 했습니다. 지금은 두개의 센터가 잘 기능하고 있습니다. (너무 감사하게도... 아직 보완할 점은 엄청 많지만...) 그러면 어떻게 동시에 진행할 수 있었을까요?!

섣부른 추상화 대신 아주 작은 교집합 찾아내기

제가 회사에서 수행하는 업무는 물류 도메인에 필요한 프론트엔드 개발을 지원하는 것입니다. 이번 센터 오픈 지원을 진행하면서 새롭게 개발이 필요한 영역은 '피킹 프로세스'였습니다. 피킹 프로세스는 물류 센터에 보관하고 있는 상품을 패킹(출고할 수 있는 상태로 만드는 절차)할 수 있도록 만드는 전처리라고 생각해주시면 됩니다. 할당된 물품들을 물류 창고에 보관되어 있는 곳들을, 동선에 따라 지나가며 토트(상품을 담는 바구니)에 지정된 상품을 담아서 약속된 장소로 이동시켜주는 절차입니다. 이를 위해 작업자들은 스캐너 기능이 있는 PDA 기기를 이용하며, 우리 팀은 해당 기기에 사용할 어플리케이션을 개발하는 업무를 맡게 되었습니다.
 
 
그런데 왜 그런 비슷한 일을 하는 시스템을 별도로 개발하게 됐을까요?! 앞서 설명한 핵심 요건은 같았지만 그 절차가 매우 달랐기 때문입니다. 이럴 때 우리는 많은 고민을 하지만 저와 팀은 한개의 어플리케이션을 만들어 서로 다르게 사용하는 것이 위험할 수 있다는 판단을 했습니다.

1. 실무에 투입되기 전 섣부른 추상화를 하여 더욱 복잡도를 향상시키는 행위를 하지말자.
2. 사용성이 비슷해지면 어느 하나를 말라죽이고 이관하는 행위가 더 쉬울 것이다.

위의 두가지가 가장 큰 이유였습니다. 많은 개발자 분들이 효율성을 위해 하나를 만들어 여러 곳에서 사용합니다. 재사용성을 프로그래밍의 미덕으로 생각하고 아직 현장에서 사용하지도 않은 로직을 하나로 개발하여 여러 분기를 만들어냅니다. 물론 이는 중요합니다. 그리고 이것이 나쁘다는 의미는 아닙니다. 하지만 이미 사용중인 어플리케이션에 사용자의 피드백이 어느 정도 예측되는 기능을 넣는것과 아직 사용하지 않은, 앞으로 현장에서 많은 피드백을 수용해야 할 어플리케이션에 개발자들이 예측한 기능을 포함시키는 행위는 많이 다르다는 것을 경험했습니다.
 
 
어플리케이션 사용을 시작하며 개발자들이 예측한 사용자들의 사용 방법이나 프로세스는 늘 예상을 빗나가거나 교묘히 다르기 마련입니다. 두개의 어플리케이션을 따로 개발하면서 저와 팀은 사용자들의 요구사항이 오픈 전과 그 후가 매우 다를것이라 판단한 이유입니다. 만약 우리의 예측이 다르면 적정한 시기에 하나를 닫고 다른 하나를 확장하는 것이, 하나의 어플리케이션을 모든 분기 처리의 다른 부분을 포함한 또 다른 어플리케이션으로 분리하는 것 보다 고통스러운 부분이 덜하다고 판단하였습니다.
 
 
그래서 우리는 더이상 쪼갤 수 없는 단위의 기능들을 열거하고 그 기능들을 만들고 또 로그인 페이지와 같이 공통으로 사용할 수 밖에 없는 단위들을 찾아내며 컴포넌트들의 조합을 만들었습니다. 라이브러리 제작을 하기로 결정했습니다.

아토믹 디자인 패턴

글의 시작 부분에서 언급했듯이 동시에 하나의 목적을 가진 두개의 어플리케이션을 개발할 수 밖에 없는 상황이었기에 저는 효율적인 방법을 찾아보았습니다. 그래서 별개의 절차에서 아주 작은 단위로 재사용이 될수밖에 없는 컴포넌트들을 제작하여 그것을 별개의 어플리케이션에서 가져다 쓰고 나머지는 어플리케이션의 구현부에서 다름을 장착하기로 결정했습니다.
 
 
완벽하고 또 베스트 프랙티스라고 할만한 수준은 아니지만, 목적에 합당한 수단으로 아토믹 디자인 패턴을 이용하기로 하였고 그것을 결정하고 약속하기 위해 팀원들과 많은 회의를 거쳤습니다.
 
 
여러가지 스캔과 입력상황을 대비하여 많은 수의 input 컴포넌트들을 만들었고 그것들을 각각의 page에 잘 조합하거나 또 꼭 동시에 쓸만한 것들은 조금 더 큰 단위의 컴포넌트를 만들어 개발을 진행했습니다.
 
 
비록 아직 추가해야되거나 지원해야 할 기능들이 많지만 우리는 적기에 어플리케이션을 완성할 수 있었고 각 센터의 요구사항에 충족되도록 수정하거나 확장할 수 있게 되었습니다.

마무리

솔직히 포스팅한지 너무나 오랜 공백이 있었고, 또 기억에 남는 일이었기에 글을 남기는거여서 여러분들이 읽기 재밌거나 유익한 내용이 아닐수는 있습니다. 하지만 간단하지만 복잡해지는 로직들을 보면서 우아한 방법으로 여러 곳에서 사용하게 만드는 것 보다 때로는 단순하지만 안전하게 코드베이스를 관리하는 방법도 있다는 말씀을 전달하고 싶었습니다.
 
 
현장의 피드백을 충분히 적용하고 그 후에 발견된 공통된 규칙으로도, 우리는 우아하게 시스템을 관리할 수 있습니다.(물론 제가 많이 부족하여 내린 결론일 수 있습니다.)