서비스 소개

'데마에칸(出前館)'은 2000년부터 서비스를 시작한 일본의 음식 배달 No.1 서비스로 2020년 당시, 아직 LINE이었던 LY Corporation에서 인수했습니다. 현재 일본의 배달 서비스 시장은 한국보다 작은데요. 그만큼 성장 여력이 많다고도 할 수 있습니다.

ABC Studio는 2021년 봄부터 데마에칸의 전체적인 리뉴얼을 진행하고 있습니다. 그중에서 'Recode'라는 이름으로, 서비스 스펙은 동일하지만 코드 베이스와 아키텍처를 100% 교체하는 작업을 진행했는데요. 이 글에서는 여러 가지 리뉴얼 방식 중 기존 코드를 새로운 코드 베이스로 교체하는 기술로 결정한 이유와 그 실행 과정을 소개하겠습니다. 아참, 프로젝트 이름을 Recode로 정했더니 Record로 잘못 쓰는 사람들이 많았습니다. 비슷한 프로젝트를 진행하실 예정이라면 다른 이름을 사용하시길 바랍니다. :)

오래된 꿈

엔지니어라면 누구나 꿈꾸는 일이 있습니다. 마법의 빗자루로 하루아침에 레거시를 청소하고, 핑거 스냅 한 번으로 모든 사용자가 최신 버전을 사용하도록 만드는 일입니다(현실에서는 그렇게 강제했다간 사용자의 절반이 사라질 수 있습니다). 왜 한 번에 갈아엎는 작업은 스펙이 아무리 명료해도 어려울까요? 비즈니스는 하루도 쉬지 않고 전진해야 하는 상황에서, 회사가 다른 시급한 사항만큼이나 기술력 향상의 가치를 알아줘야 하고, 쉽지 않을 갈아엎는 작업에 대한 프로덕트 팀 내부의 합의도 필요하고, 합의한 뒤에는 그 프로덕트 팀의 고충을 이해해 줄 경영진과 사업 팀, 마케팅 팀, QA 팀, CS 팀 등 다른 구성원들의 공감대가 필요하기 때문입니다.

앞서 열거한 주변 팀들의 희망 사항을 나열해 보면 아래와 같습니다.

경영진: GMV(gross merchandise volume) 목표치를 달성해 시장에서 이기고 주주들에게 긍정적으로 응답하고 싶다.
사업 팀: 새로운 초대형 파트너와의 계약이 임박했다. 새로운 결제 방식을 추가해 공급할 때까지 얼마나 걸리는지 알려 달라. 늦으면 그들이 경쟁사와 독점 계약할 위험이 있다(아... 글만 썼는데도 스트레스가...).
마케팅 팀: 연휴에 반값 할인 행사를 하고 싶다. 쿠폰을 대량 발급하고 메신저 광고를 진행할 것이니 접속량이 피크에 달할 것으로 예상된다.
QA 팀: 새로 작성한 코드는 버그가 많을테니 아주 오랫동안 시간을 넉넉하게 잡고 QA를 해야 할 것이다. 3개월은 어떨까?
CS 팀: 당분간 버그가 많이 나올 텐데 콜센터에서 제대로 대응하지 못할 위험이 있다.

모두가 공감할 수 있는 가치는 무엇이었을까요? 그리고 각각을 어떻게 설득할 수 있을까요? 개발자라면 누구나 레거시를 청소하고 싶을 것 같지만 과연 그럴까요? 대화해 보면 레거시 청산으로 얻을 좋은 개발 경험보다는 당장 어떻게든 비즈니스 요구 사항을 구현해 회사의 매출과 경제적 성장에 기여하는 것을 더 중요하게 생각하는 경우도 많았습니다. 그것이 좀 더 가시적인 성과이며, 이는 평가와 보상으로까지 이어지기 때문입니다. 따라서 회사 차원에서 이번 노력의 가치와 공헌을 잘 이해하고 있다고 설득해서 프로덕트 팀 내부의 합의를 이끌어 내는 것도 필요합니다. 간혹 사안을 숫자로만 이해하려고 드는 동료에게는 스토리 포인트 대비 개발 시간과 릴리스 사이클을 KPI에 직결시켜서 레거시로는 도저히 목표를 달성할 수 없다고 이야기하는 방법도 있습니다.

프로덕트 팀 외부에 Recode 프로젝트가 왜 필요한지 설득하는 일이 어려운 가장 큰 이유는 사업적으로 아무런 공헌이 없는 것처럼 보이기 때문입니다. 이때 이들을 설득할 수 있는 대표적인 방법 세 가지를 소개하겠습니다.

첫 번째는 현재 앱에서 발견된 잠재적인 보안 리스크를 강조하는 것입니다. 보안 문제는 서비스를 한순간에 의미 없게 만들 수 있을 만큼 중요한 문제이므로 분명한 보안 이슈가 있으면 크게 강조합시다.

두 번째는 Recode 다음 단계를 보여주는 것입니다. Recode 자체로는 겉으로 보이는 차이가 없기 때문에 효과를 체감할 수 없습니다. ABC Studio는 Recode 후에 진행할 수 있는 한 달 간격의 UI 리프레시를 비롯해 향후 두 번의 릴리스가 가져올 변화를 시연을 통해 보여줬습니다. 또한 Recode 덕분에 적용할 수 있게 될 UX와 신기능 등을 소개했습니다. 반년 뒤를 생각했을 때, 조금씩 앱을 수정해 나간 반년 뒤의 결과보다는 3개월 정도 기존 앱으로 버티면서 Recode한 뒤 그 결과로 나머지 3개월 동안 급격한 변화와 여러 요구 사항을 빠르게 수용한 결과가 더 좋을 것이라는 믿음을 심어 주세요.

세 번째는 역시 돈의 논리로 이야기하는 것입니다. LY Corporation은 보안을 1순위에 두고 가장 중요하게 생각하지만 그렇지 않은 회사도 많습니다. 오직 사업 관점의 KPI만 중요하게 생각하는 회사라면, Recode의 경제 효과를 간단한 수식으로 표현해 설득하는 방법이 잘 통할 수 있습니다. 이때 현재 서비스의 여러 가지 지표를 수집해 표로 정리하면 좋은데요. 버그와 크래시 발생 빈도, 사용자 피드백 자료, 서비스 품질의 네거티브 지표(로딩 시간 등), 신기능을 추가할 때 소요되는 시간 등을 정리합니다. 여기에 릴리스를 이전보다 자주 할 수 있게 되면서 얻을 수 있는 이득을 포함해 표로 정리하고 계산하면 Recode의 필요성을 효과적으로 전달할 수 있습니다. 또한 가장 민감한 방법으로 경쟁사와 비교하는 방법도 있겠습니다.

데마에칸은 일본의 상장사입니다. 또한 영업력이 강한 서비스인만큼 매출을 1순위로 생각하고 있었지만, 서비스의 품질이 좋지 않다는 공감대는 형성돼 있었습니다. 이에 프로덕트의 쇄신을 넘어 혁신이 필요하고 이를 위한 시간이 필요하다는 점은 인정하고 있었습니다. 다만 그렇다고 무작정 오래 기다리게 할 수는 없는 노릇이라서 딱 3개월만 버텨달라고 설득했습니다. 3개월은 개발 측면에서는 빠듯한 기간이었지만, 비즈니스 측면에서는 한 분기에 해당하는 기간입니다.

Recode의 특징은 기존 앱의 UI부터 동작까지 모두 동일하게 유지하면서 코드와 아키텍처를 바꾼다는 것입니다. 새로 작성하는 김에 새로운 스펙과 디자인을 적용할 수도 있지만 그렇게 하지 않은 이유로는 아래 네 가지가 있습니다.

CS 팀을 비롯한 운영 조직을 안심시킬 수 있습니다. 버전 숫자만 달라질 뿐 기존 앱과 동일하다는 말은 운영 현장에서 발생할 수 있는 혼란을 줄입니다. 또한 다음에 신규 기능을 넣기 전까지 운영에서의 버퍼 역할을 합니다.
QA 팀의 작업을 단순화할 수 있습니다. 새로운 스펙과 새로운 버그로 혼란을 주는 것이 아니라, 새로운 버그 유형에 대해서만 확인하도록 만들 수 있습니다. 이는 프로덕트 팀에서 핫픽스(hotfix)할 때 QA 팀에서 코드 품질에만 신경 쓸 수 있도록 만듭니다.
프로덕트 팀이 전체 워크플로를 안정적으로 익힐 수 있습니다. 주위 팀들과의 공개 버전 릴리스 경험을 거치면서 커뮤니케이션 방법과 릴리스 절차를 습득할 수 있습니다.
개발 팀이 자신의 코드에 확신을 가질 수 있습니다. 전체 구조를 제대로 이해하지 못한 상태에서 새로운 요구 사항을 반영해 작은 단위의 릴리스만 진행하면, 이로 인해 야기될 수 있는 버그가 발생했을 때 당황하곤 합니다. 특히 오래된 아키텍처는 더욱 쉽게 무너질 수 있습니다.

어디서부터 시작할까?

서비스의 전체 아키텍처 중 어느 한 부분을 잘라내서 완전히 재구성하는 일에는 여러 가지 접근법이 있습니다. 가장 핵심적인 부분부터 새롭게 구성하기도 하고, 반대로 종단부터 진행하기도 합니다. 이에 대한 판단은 현재 서비스가 처한 시급도와 영향도, 안정성, 그리고 사업 관점에서의 요구 사항에 따라 다르겠습니다. 데마에칸의 경우를 일부 소개하면 아래와 같습니다.

컴포넌트	회원 서비스	주문 서비스	배달 서비스	사내 관리	프런트 앱	배달 앱	가맹점 앱
요구 사항 시급도	낮음	높음	낮음	중간	높음	중간	낮음
보안 위험	중간	낮음	낮음	낮음	낮음	높음	높음
팀 체계	부족	적당	부족	적당	충분	부족	부족
아키텍처	부족	적당	부족	부족	적당	부족	부족
...

여느 음식 배달 서비스가 그러하듯 데마에칸의 사용자는 크게 세 그룹으로 나눌 수 있습니다. 음식을 주문하는 사용자와 가맹점주, 그리고 라이더입니다. 이를 데마에칸에서는 각각 프런트, 가맹점, 배송원이라고 부릅니다. ABC Studio에서는 현재 상황을 정리한 위 표를 참고해 가맹점과 배송원 앱을 우선적으로 살펴보며 이해한 뒤 쇄신하기로 결정했습니다. 이와 같이 결정한 이유는 두 사용자 그룹은 기존에 이미 CS 센터에서 직접 연락할 수 있을 정도의 관계를 형성해 놓았고(데마에칸의 라이더는 지역 거점에서 직접 계약으로 고용함), 서비스의 특성상 다분히 기능적인 앱이었기 때문입니다. 한편으로, 사용자가 많고 운영 업무가 많아 영향 범위가 너무 컸던 프런트는 아직 서비스를 전체적으로 깊이 이해하지 못한 상황이었기에 Recode 대상에서 제외했습니다.

기술 측면에서 가맹점 앱과 배송원 앱은 모두 통상적인 iOS/Android 앱이었습니다. 즉, 앱이 4개입니다. 가맹점 앱은 태블릿 단말용으로 Xamarin으로 개발돼 있었습니다. 배송원 앱은 통상적인 모바일 앱으로 React Native(이하 RN)로 개발돼 있었습니다. 참고로 프런트는 RN과 Expo로 개발돼 있었습니다. 참 신기했습니다. 각각 다른 외주사가 개발했는데 모두 멀티 플랫폼을 염두에 두고 각양각색으로 구현해 놓은 상태였습니다.

가맹점 앱은 주문받는 기능에 충실한 앱이고, 배송원 앱은 배달 기능에 충실한 앱입니다. 충실하다는 말은 그 기능 외에 다른 기능은 없다는 뜻입니다. 그에 따라 시나리오가 비교적 단순해서 절대적인 스펙의 양은 적은 편이었지만, 인생이 스펙대로 흘러가지 않듯 스펙의 구현체는 호락호락하지 않았습니다. 앞서 말씀드렸듯 두 사용자 그룹의 앱은 기술 셋부터 구조까지 ABC Studio에서 희망하는 형태와는 큰 차이가 있었습니다. ABC Studio는 네이티브 앱 개발에 강한 팀입니다. Flutter는 능숙하게 다루지만 Xamarin과 RN 경험은 전무했습니다. 코드를 전달받아 어찌어찌 빌드는 성공했고, 전체 흐름을 이해하기 위해 주요 프로토콜을 모방한 테스트 서버도 구축했습니다. 이제 대강의 흐름은 이해했으니, 이참에 새 기술도 익히고 코드도 개선해 볼까요?

갈아엎자 ㅆ (←웃는 눈 모양입니다)

아닙니다. 바닥부터 새로 개발하는 게 낫다고 판단했습니다. 소프트웨어에서 기술 셋은 둘째입니다. 아키텍처와 코드 품질이 첫째입니다. 기존 앱은 보안 문제도 있었고, 현대적인 구조가 아닌 가장 기초적인 구조였기에 앞으로의 요구 사항을 수용하기에는 무리가 있다고 판단했습니다. 사용한 라이브러리들도 이젠 모두 구 버전이 된 상태였습니다. 이런 오래된 버전의 라이브러리들은 대체로 보안에 취약하고, 최신 OS 플랫폼을 지원하려고 할 때 발목을 잡습니다. 우리는 앞으로의 요구 사항에 대응하기 위해 보다 많은 기능을 매끄럽게 소화할 수 있는 UI와 UX, 높은 안정성을 확보하길 원했고, 협업과 단위 테스트를 보다 적극적으로 수행하길 원했습니다. 이에 네이티브 코드로 새롭게 갈아엎기로 결정하고, 앱 4개(가맹점 앱(iOS/Android) + 배송원 앱(iOS/Android))를 개발하기로 결정했습니다.

연유를 알 수는 없었지만 기획서가 온전하게 보존돼 있지 않아서 코드를 추적하고 버튼을 하나씩 터치해 보면서 기획서를 복각하는 과정을 거쳐야 했습니다. 구멍 난 스펙부터 새롭게 작성했고, 디자인도 Figma로 페이지 하나하나를 복각했습니다. 이처럼 기획서 복각부터 개발까지 2개월 반, 그리고 3주의 QA 기간을 거치는 작업을 Recode라는 이름의 프로젝트로 진행했습니다.

Xamarin과 RN의 Recode 경험을 공유드리자면, 변환은 Xamarin이 훨씬 수월했습니다. 왜냐하면 앱 구조는 네이티브 앱을 존중하는 형태이면서 언어와 개발 환경만 Microsoft C#으로 변주했기 때문입니다. 그래서 Xamarin 지식이 없어도 네이티브 개발자가 코드를 읽는 데에는 무리가 없었습니다. 하지만 RN은 파일의 구성부터 문법까지 아주 달라서 손이 많이 가는 편이었습니다.

품질 요구 사항

소프트웨어의 품질을 평가하는 기준으로는 유지 보수성, 확장성, 재사용성 등 여러 가지가 있습니다. 그중 어디에 무게 중심을 둘지에 따라 소프트웨어의 설계부터 구조는 물론 빌드 파이프라인까지 달라질 수 있는데요. Recode 프로젝트에서 중요하게 생각한 품질 속성은 아래와 같습니다¹.

보안: 앱의 DB로 Realm을 이용하고 있었는데 이를 SecureStorage로 옮기는 로직을 추가했으며, 그 외에도 단말과 서버 사이의 데이터 갱신 관계 재정립을 가장 중요한 품질 요구 사항으로 정했습니다. 또한 업데이트했을 때 다시 로그인하는 불편이 없도록 기존 인증 토큰을 비롯한 로컬 데이터의 부드러운 전이와 활용을 필수 테스트 항목으로 넣었습니다.
재사용성: ABC Studio는 네이티브 앱 개발에 강한 팀이지만, 동시에 4개의 앱을 개발해야 하는 상황에서 인원은 한정돼 있었기에 부분적으로 멀티 플랫폼을 고려해 보기로 했습니다. 하지만 Flutter처럼 UI 레이어를 포함한 모든 스택을 공용하는 것보다는 UI 레이어는 네이티브 개발을 존중해 앱 디자인의 완성도를 높이고, 라이브러리는 공용으로 사용할 수 있는 기술을 살펴보기로 했습니다.
테스트 가능성: 대부분의 현대적인 아키텍처는 테스트를 보다 잘 할 수 있는 방향으로 발전하고 있습니다. 뷰와의 명확한 분리를 넘어 최근의 선언적(declarative) 문법처럼 코드로 뷰를 구축하는 기술도 모두 테스트를 보다 용이하게 하려는 의도입니다. Recode 프로젝트에서도 이에 발을 맞추기로 했는데요. 예를 들어 Android는 Jetpack Compose, LiveData, MVVM(model-view-viewmodel) 아키텍처 등을 적극적으로 활용하기로 했습니다.
안정성: 조사해 보니 기존 앱은 안정성 체크가 전혀 이뤄지지 않고 있었습니다. Google Analytics를 적용해 놓긴 했지만 아무도 모니터링하지 않고 있었습니다. 이를 개선하기 위해 접근 계정을 정리하고, 담당자를 재정의하고, 알림 체계를 정리하고, 크래시 수치의 KPI 설정을 하는 작업이 필요했습니다.

멀티 플랫폼 기술 도입 - KMM(Kotlin Multiplatform Mobile)

하이브리드 앱을 비롯해 Xamarin과 RN, Flutter 등의 멀티 플랫폼 기술이 충분히 검증된 지금 상황에서(물론 검증된 것이지 성숙한 것은 아니지만), 플랫폼은 다르지만 UX가 거의 동일한 기능 중심의 앱을 완전히 다른 코드 베이스로 개발한다는 것은 비효율적입니다. ABC Studio는 문자열 리소스를 빌드 타임에 동일하게 싱크하는 것과 같은 몇 가지 공용화 기술을 적용하고 있는데요. 이번에 새로 시도한 것은 KMM이었습니다. KMM을 선택할 때 아래와 같은 점을 기대했습니다.

JetBrains는 Android/iOS 전용 IDE를 만들고 있으니 코드뿐만 아니라 전체적인 개발 경험까지 신경 쓸 것이다.
Kotlin 언어를 만드는 회사인 만큼 발전 가능성이 높다.
대부분의 기술은 두 플랫폼에 통용되는 새로운 언어를 제시하지만, KMM은 Android에서는 온전한 네이티브이므로 학습 비용과 위험도가 낮다.
가장 나중에 창안된 멀티 플랫폼 기술이니 만큼 과거의 시행착오들을 고려했을 것이다.
라이브러리만 공용으로 사용하는 정도로 선을 그을 수 있어서 네이티브 UI의 반응성과 표현력을 존중할 수 있다.

ABC Studio에서는 KMM을 도입하면서 공통 기능 일부를 라이브러리화해서 그중 5개를 GitHub에 오픈소스로 공개했습니다(참고). 하지만, 릴리스 후 3개월 동안 운영해 본 지금 시점에서 글을 작성하며 돌아보니, KMM에 아직 부족한 점이 있다는 것을 깨달았습니다. 만드는 애플리케이션이 복잡해 질수록, iOS와의 결합성이 부족해서 디버깅 시행착오가 늘어나는 경험을 하고 있기 때문입니다. 아키텍처가 아무리 멋져도 성숙도는 별개의 문제라는 점을 느낍니다.

"누구나 그럴싸한 아키텍처를 그릴 수는 있다. 에러 메시지에 얻어맞기 전까진" - 어느 개발자의 명언

QA

QA 과정에서는 기존 앱과 Recode 앱이 완벽히 동일하게 작동하는지를 3주간 테스트했습니다. 전문 QA 인력이 두 개의 폰을 나란히 놓고 시나리오에 따라 버튼을 하나씩 누르면서 테스트하는 과정을 거쳤습니다. 코드와 기획 수준에서 제대로 복각했다고 해도 개발 팀과 완전히 구분된 QA 팀에서 검증하는 작업은 필수입니다.

검증 결과 코드 수준에서는 동일하다고 생각했는데 예상보다 다르게 동작하는 부분이 많았습니다. 특히 RN과 네이티브 UI는 그래픽 처리에서 폰트를 비롯한 여러 그래픽 컴포넌트의 크기가 서로 다르게 계산돼 글상자에서 텍스트가 넘치는 정도가 다른 경우가 많았습니다. 기존 앱의 버그도 많이 발견됐는데요. 그중에는 이미 스펙화된 버그도 있었기에 이를 존중할지 말지 매번 논의를 거쳐야 했습니다. 또한 배달 서비스는 드라이버들의 주문 수주 경쟁에 민감했기에 전문적인 QA 인력이 없다면 경험하기 어려운 경쟁 상태(race condition)도 많았습니다. 이에 따라 원래 QA 기간을 3주로 계획했지만 실제로는 한 달가량 소요됐습니다.

Update API는 영원히 사용된다

모두 한꺼번에 새 버전으로 업데이트하도록 강제 업데이트 설정을 하고 싶었지만, 전국적인 서비스이고 가맹점주와 배송원의 생계가 걸려 있는 서비스라서 그렇게 과감하게 할 수는 없었습니다. 대신 레거시 API 서버 스펙의 강제 업데이트 기능에서 사용자 ID를 현(県, 우리나라의 도 단위 정도) 단위로 나눠 설정한 뒤 CS 팀과 조율하며 업데이트를 진행하고 있습니다.

서버에서 강제 업데이트 명령을 보냈음에도 앱에서 업데이트에 실패하는 데는 여러 가지가 이유가 있는데요. 그중에는 단말을 셋업할 때 영업 사원이 Apple 혹은 Google 계정에 대신 가입해 준 뒤 로그아웃됐거나, 아르바이트가 무슨 메시지인지 몰라서 꺼버리는 등의 현실적인 이유도 있습니다.

그럼에도 앱과 통신하는 API 서버라면 꼭 갖추어야 할 기능이 강제 업데이트 기능입니다. 레거시 API 서버의 여러 프로토콜 중 유일하게 끝까지 활용되는 기능이기도 합니다. 그러므로 앱을 처음 서비스하는 곳이라면 시작부터 앱과 API 서버에 강제 업데이트 스펙을 정의하고 구현하면 좋습니다.

강제 업데이트는 여러 방법으로 구현할 수 있습니다. OS에서 플랫폼 API 수준으로도 제공하는데요. 간혹 스토어 계정을 로그아웃했거나 스토어 앱이 구 버전인 경우에는 동작하지 않을 때가 있으니 서버 수준에서도 제어할 수 있어야 합니다. 이번 경우처럼 지역 단위로 업데이트하는 경우나 사업자 단위로 구분해야 하는 경우를 대비해 로그인한 사용자의 ID 단위로 필터링할 수 있는 여지를 마련해 두면 좋습니다. 또한 앱에서 강제 업데이트 UX를 구현할 때 단순히 UI를 덮는 팝업만 구현하면 내부적으로는 정상 작동 상태라며 서버와 정상적으로 통신하는 경우가 있습니다. 따라서 앱에서도 기능 일부는 확실히 정지시키도록 구현하는 것이 바람직하겠습니다.

이번에는 다행히 레거시 서버에서 사용자 ID 단위로 강제 업데이트를 조절할 수 있게 돼 있어서 CS 팀의 부담도 적절히 조절할 수 있었습니다.

릴리스, 그 후

Recode 프로젝트의 흥미로운 점은, 릴리스 후에 바뀌었다는 것을 전혀 눈치채지 못하는 사용자가 많을수록 성공이라는 점입니다. 네. 성공적으로 아무도 눈치채지 못했습니다. Recode 후 프로덕트 팀의 릴리스 사이클은 정상적으로 돌기 시작했습니다. 팀에서 가장 원했던 아키텍처와 기술 셋으로 구현했고, 보안 문제도 해소했습니다. 3주 간격으로 릴리스하고 가끔 핫픽스도 하면서, HeadVer에 따라 지금까지 10번 넘게 헤드 숫자를 올리며 칙칙폭폭 나아가고 있습니다.

Recode는 2보 전진을 위한 1보 후퇴입니다. 한 번 시작하면 3개월간 아무런 요구 사항도 구현할 수 없습니다. 이 시기를 잘 버티려면 개발 팀 내부는 물론 다른 여러 팀들과 사업적으로 전략을 논의해 합의도 이끌어 내야 합니다. 넘어야 할 허들이 많습니다.

그럼에도 Recode 프로젝트를 시작한 이유는 아키텍처에 대한 개발 팀의 확신을 얻기 위해서였습니다. 소프트웨어 개발의 건전성을 판단하는 기준에는 여러 가지가 있겠지만, 그중에서도 아키텍처에 대한 개발 팀의 확신은 다른 어떤 것보다도 중요합니다. 그 확신이 있어야 높은 품질의 소프트웨어를 주기적으로 릴리스할 수 있습니다. Recode는 이와 같은 확신을 얻기 위한 과격하지만 가장 확실한 방법입니다.

품질 요구 사항에 대한 자세한 내용은 제가 번역한 2021년 개발 서적 베스트셀러, '개발자에서 아키텍트로'의 89 페이지를 참고하시기 바랍니다.

일본 1위 배달 앱, 바닥부터 다시 짠다 - Recode 프로젝트

댓글