Introduction
- 오늘도 아이스 아메리카노로 회사의 뜨거운 불맛을 이겨내고 있었습니다. 금융권 서비스는 정기적으로 금감원, 금보원 등 여러 금융 관련 기관에서 취약점 점검을 받습니다. 이때 모바일 앱 개발자라면,
.apk혹은ipa를 전달하여 취약점 점검을 할 수 있도록 준비해야 합니다. - 책무에 맞게 저는 파일을 전달했으나, 정상 기동되지 않고 있었습니다. 이전에 하던 업무와 동일하게 처리했음에도 불구하고.
- 그래서 이
짜릿한경험에 대해 공유하고자 이 글을 작성했습니다.
Summary
Print문에 적힌 에러를 통해 유추했습니다. 그리고 그것으로 서버 이슈임을 진단했고 문제를 해결했습니다.
Approach
제가 담당하던 iOS Project에서 이전과 동일한 프로젝트를 실행했더니 갑자기 앱이 종료되고 있었습니다. UI에 노출된 메시지는 다음과 같습니다.
"무결성 검증에 실패했습니다."
그래서 다음 절차대로 디버깅을 시작합니다.
- 로그 분석
- 내부 프로젝트 점검
- 외부 프로젝트 점검
1. 로그 분석
SDK의 동작 시점(혹은 메모리 할당 시점)을 찾아서 Breakpoint를 앞뒤로 추가합니다. 그리고 그 사이에 발생한 로그를 확인합니다.
여러 로그가 있었지만, 그 중에서 가장 의심되는 것을 선택했습니다.
MSG : <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>503 Service Unavailable</title>
</head><body>
<h1>Service Unavailable</h1>
<p>The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.</p>
</body></html>503: 503은 HTTP 통신에서 주로 서버 에러일 때 오는 응답코드중 하나입니다. 그 중에서도 "Service Unavailable" 은 일시적으로 서비스를 제공할 수 없음을 나타내곤 합니다.- 나머지 설명: 503의 에러에 대해서 설명하는 내용 입니다.
2. 내부 프로젝트 점검
만약 내부 프로젝트의 이슈로 인해 해당 SDK에 에러가 있는지 확인해 보았습니다. SDK 제공업체 측 문서를 했습니다. 1000이라는 에러가 현재 출력되고 있었는데, 문서에는 해당 에러 메시지는 없었습니다. 이런 경우 사실 바로 전화를 해보는게 속편합니다. 다만, 전화는 전화대로 해보고 동시에 문제도 해결해야 시간을 아낄 수 있습니다. 퇴근시간 엄수
그 다음으로 플랫폼 특성을 보기로 했습니다. iOS의 경우, 특정 Domain 접근을 막습니다. 그리고 HTTP 통신은 기본적으로 하지 못하도록 합니다. 혹시 그 부분이 문제가 되진 않을까 생각했습니다. (이미 서버 응답이 왔기에, 이 부분은 문제가 될 가능성이 아주 낮습니다만, 혹시나 확인해봤습니다.)
info.plist 파일에서 설정 중 App Transport Security Settings를 찾습니다. 그리고 거기서 Allow Arbitrary Loads라는 항목이 없다면 추가해서 "YES"로 설정합니다.
이렇게 했으나, 여전히 문제는 재발하고 있었습니다. 그래서 내부 프로젝트에서 점검할 사항은 모두 확인했다고 판단했습니다.
3. 외부 프로젝트 점검
이제 서버를 점검해보고자 했습니다. 그리고 서버 모니터링 툴을 통해 확인했고, 역시 오류가 검출되고 있었습니다. 이 에러를 해결하고 정상적으로 동작했습니다. 관련 내용은 Problem에서 자세히 설명하겠습니다.
Problem
서버의 일시적인 응답 불능 상태로 인한 버그
503 에러로, "Service Unavilable" 상태입니다. 이 에러는 서버의 인스턴스는 있으나, 모종의 이유(리소스 없음, 과부하, 다른 작업중... 등)로 일시적으로 요청을 처리할 수 없는 상태를 의미합니다. 만약 서버 인스턴스 자체가 없었다면 아마도 404 에러가 출력되었을 확률이 높습니다.
실제로 회사 내 모니터링 툴을 확인해보니, 실제로 "Crash...." 와 같은 에러가 있었습니다.
Solution
서버 재기동
해결방법은 클라이언트에서는 없었습니다. 서버 재기동 후, 정상적인 Request - Response를 주고받았고, 앱 무결성 서버와도 지장 없이 통신할 수 있었습니다.
Reflection
- 이번 문제는 "서버의 응답 상태"에 의해 발생한 문제입니다. 하지만, 에러의 발생 지점은 클라이언트입니다. 그래서 최초에는 이 에러를 해결하기 위해 내부 프로젝트의 설정을 뒤져보고 소스코드상 오류가 없는지 검토하는 데 많은 시간을 쏟았습니다.
- SDK다 보니, 내부 코드는 볼 수 없는 영역이 많이 있어서 더욱 어려움을 겪었습니다.
- 이 사건 이후 느낀 점은 다음과 같습니다.
에러의 발생 가능성을 상상하는 것이 중요하고, 최초 개발 시점에 이 에러에 대해 미리 핸들링할 줄 아는 것이 "노하우(=짬)"가 아닐까?
- 프론트엔드/백엔드를 나누는 것은 담당자이지, 개발자라면 둘 다 알아야 하는 이유를 느낄 수 있는 경험이었습니다.
