[책 요약] 배달의 민족의 IT이야기, 요즘 우아한 개발(3편)

프로젝트의 계획/개발과 거의 동시에 테스트를 계획할 수 있는 조직이 현실에서 실현하기는 어렵겠지만, 가장 이상적인 조직이지 않을까 생각된다.
완벽한 기획, 버그 없는 개발, 제품의 무결성을 보장하는 QA가 없음을 인정하는 리더와 조직이 오류를 숨기지 않는 조직문화를 만드는데 매우 중요하다.
디지털화로 인해 외부시스템과의 연동성이 급격히 증가하고 있다. 무분별한 연동은 지양해야 하고 이중화와 장애격리로 장애대응력을 높여야 한다.

5. 테스트와 코드 품질 관리하기

층을 분리하는 것이 습관적으로 하는 작업이 아니라 층별로 담당해야 하는 역할을 명확히 하고 층별 의존관계를 고려해 유지보수하기 좋은 형태를 만든다는 점을 배웠습니다.

테스트를 작성할때는 최대한 예외 케이스부터, 해피케이스 순서로 다양한 경우를 커버할 수 있어야 한다는 생각이 들었습니다.

예상가능한 범위라면 확장성과 유지보수에 좋은 코드를 지향해야겠지만 불확실한 형태로 모듈을 세분화하면 오히려 복잡성을 증가시킬 수 있습니다.

2019년 배민 시스템은 생존을 위해 마이크로서비스 아키텍처로 변화를 했고 결과는 매우 성공적이었습니다.

이후 시스템별로 크게 플랫폼, 프론트서버, 앱/웹클라이언트팀으로 나누어지고 팀은 기획/개발/QA가 함께 일했습니다.

 

서버 상황과 무관하게 테스트하도록 클라이언트 QA담당자들도 목 서버의 역할을 할 수 있는 피들러, 찰스프록시 등의 도구를 활용해 테스트를 계획하고 수행하는 동시에 서버가 안정적으로 운영되도록 지원했습니다.

개발자들과 개발 문서들을 같이 확인하고 클라이언트와 협의한 사항대로 API를 호출하고 데이터를 사용할 수 있는지 클라이언트를 보지 않고도 서버에 저장된 데이터, 카바나 로그, API테스트 등으로 서버를 테스트했습니다.

서버와 클라이언트를 함께 테스트하면 이슈가 뒤섞여 정리가 어려웠습니다. 그래서 분리 테스트를 진행했습니다.

서버와 클라이언트를 각각 테스트하면 대상을 바라보는 관점이 달라 효과가 다르게 나타날 것이라고 기대했습니다.

 

프로젝트의 계획/개발과 거의 동시에 테스트 계획을 시작해야 합니다.

리팩터링 시 테스트코드의 강력함을 경험할 수 있습니다.

 

코드에서 if문이 있듯, 시나리오를 작성할 때도 특정 조건을 기준으로 분기하며 작성해 줍니다.

코드에서 if문 안에 여러 조건이 복잡하게 작성되어 있는 것을 하나씩 풀어서 분류해 봅니다.

이 과정을 통해 내가 작성했던 코드의 맹점들을 발견하게 될 수도 있습니다.

조건을 풀어서 나열하면 제 조건문이 MECE한지 검증하기도 좋습니다.

컴포넌트를 간결하게 분리한 덕분에 발주 상세페이지에서 정리되지 않은 코드에 새로운 것을 추가해야 하는 위험이 사라졌고 테스트코드가 기존 동작에 대해서 안정성을 보장해 주니 새 기능을 추가하다 발생하는 부작용 걱정을 덜 수 있게 되었습니다. 또한 기존에는 PM이 어떻게 동작하는 건지 질문을 해와도 파악하는데 시간이 오래 걸렸는데 이젠 코드를 볼 필요 없이 테스트 시나리오로 금방 파악할 수 있습니다.

먼저 우리는 해결할 수 있는 문제와 그렇지 않은 문제를 나눴습니다.

완벽한 기획은 있을 수 없고 버그 없는 개발은 불가능하며 제품의 무결성을 보장하는 QA는 없으니까요.

 

테스트오토메이션으로 구글에 검색하면 상단에 스마트베어의 테스트컴플리트와 라노렉스의 라노렉스 스튜디오 상용 도구가 검색됩니다.

UI테스트 자동화의 도입과 평가는 전문 QA팀 없이는 불가능합니다.

CI/CD에 라노렉스 스튜디오를 연동하기

 

UI테스트 자동화는 꾸준한 유지보수가 필요함을 느꼈습니다

 

6. 시행착오 겪으며 성장하기

가정의 달 프로젝트가 끝나고 배운 것을 하나만 꼽자면(물론 VoC 덕분에 얻은 인사이트도 많았지만) 모든 상황을 전부 알고 대처할 수는 없겠지만 프로젝트를 진행하면서 있을 파급력과 이슈들에 대해 더 깊이 고민해야 한다입니다.

외부시스템 연동은 직접 개발하고 운영하는 것에 비해서 비교적 간단한 연동 작업으로 높은 수준의 서비스를 이용할 수 있으며 비용 측면에서도 직접 구축하고 운영하는 것보다 훨씬 저렴합니다.

하지만 이런 외부시스템은 우리의 통제 범위 밖에 있는 불안 요소이기도 합니다.

따라서 신중하게 검토하고 도입해야 합니다.

 

외부시스템 연동 시 주의할 점

의존성제거
벤더이중화
이중화를 할 경우 9:1 혹은 8:2의 비율로 전환 대상 서비스와도 상시로 트래픽을 주고받아서 연동상태를 늘 체크하도록 하는 것이 좋습니다.
장애격리
외부시스템의 장애가 연동과 관련 없는 부분으로 전파되지 않도록 장애를 격리하는 것이 중요합니다.
미작동감내
장애회피가 불가능한 경우 장애상황을 빠르게 인지하도록 모니터링을 강화하고 해당 서비스 담당 부서에 빠르게 확인할 수 있는 핫라인을 운영하는 등의 추가 조치가 필요합니다.

 

장애는 서비스의 성장, 서비스의 변화 등 다양한 과정 중에서 발생하는 성장통이기 때문에 장애가 발생하는 것을 원천적으로 차단할 방법은 없습니다. 그렇기에 빠르고 적절히 장애에 대응해 신뢰도 하락을 최소화하는 일이 중요합니다. 장애가 발생하더라도 영향범위를 최소화하고 빠르게 복구하며 고객에게 적절한 정보를 제공하고 같은 불편을 겪지 않도록 조치를 하는 모든 과정이 고객의 신뢰를 지키는 방법입니다.

장애는 시스템 알람으로 탐지할 수도 있고 고객센터로 인입되는 문의를 통해서도 인지할 수 있습니다.

몇 년 전까지는 모노리틱구조(하나의 애플리케이션에 모든 비즈니스 로직이 다 들어가 있는 구조)로 인해서 모든 엔지니어가 이 채널의 알람에 민감하게 반응했지만 현재는 마이크로서비스 아키텍처에 맞게 문제가 있는 도메인(예를 들어 주문, 리뷰, 결제 등)을 호출하면 각 담당자에게 온콜이 가도록 분리 운영 합니다.

최초로 장애공지를 할 때는 확인된 최소의 정보만 가지고 빠르게 공지하도록 권고합니다.

- 장애등급, 장애기간(11:40~), 고객영향, 장애원인, 조치내역

장애대응 시 반드시 장애복구와 장애전파를 같은 사람이 하지 않도록 가이드합니다.

장애공지 후에 장애전파와 장애복구가 동시에 진행됩니다.

장애복구에서 중요한 것은 서비스 정상화이며 대부분의 경우 서비스정상화는 원인파악보다 우선됩니다.

장애복구
- 장비증설, 롤백, 핫픽스, 장비교체

 

장애후속조치

장애보고서에는 장애발생시각, 탐지시각, 종료시각, 장애탐지방법, 장애발생지점, 장애복구방법, 대응과정 중의 시간별액션, 장애원인, 재발방지대책 등이 포함됩니다. 이중 가장 중요한 항목은 장애원인분석과 제발방지대책 수립입니다.

장애를 감추고 숨기기보다는 함께 해결하고 함께 고민하는 것이 장애대응의 가장 중요한 핵심이며 그렇게 할 수 있는 조직이 건강한 조직이라고 생각합니다.

 

MariaDB의 바이너리로그는 데이터 수정과 관련된 모든 정보가 담겨 있는 파일인데 크게 두 가지 중요한 목적이 있다고 합니다.
- 리플리케이션구성, 데이터복구작업

 

DB 엑스트라백업은 퍼코나가 개발한 백업 도구입니다. 엔진데이터를 그대로 복사하는 물리적 백업 방식입니다.

보안편향적 사고를 주의해야 한다. 어렵겠지만 사용성까지 고려한 이해하기 쉽고 안전한 방법을 적절히 제시할 수 있다면 구성원의 보안 준수 행동에 긍정적인 영향을 줄 수 있습니다.