휴먼에러가 가장 어려웠어요.
빌드에러, 런타임에러, 휴먼에러 3천왕 중 최강 이야기.
개발을 하다보면 피할 수 없는 것
개발을 하다 보면 많은 에러를 만나게 됩니다.
- 빌드, 컴파일 하는데 실패하는 에러 — 빌드 에러
- 애플리케이션이 실행 중 종료하는 에러 — 런타임 에러
- 보기엔 아무 문제 없는데 무언가 안되는 에러 — 휴먼 에러
빌드 에러는 에러 메시지를 가지고 힌트를 얻어 해결을 하게 되며, 런타임 에러는 강제 종료 시 발생하는 backtrace 로그나 기타 로그 메시지를 가지고 해결을 시도하게 됩니다.
그렇다면 휴먼 에러는 대체 무엇이고, 왜 어려운 것일까요?
휴먼 에러
휴먼 에러는 개발자가 만들어낸 코드가 기대하는 역할과 다르게 동작하는 문제라고 이이기할 수 있습니다. 물론 빌드 에러와 런타임 에러 모두 개발자가 만들어낸 코드 만들어내는 문제이고, 에러를 기대하지 않음은 같지만요.
흔히 개발자가 의도를 가지고 동작하게 만든 코드가 동작을 안 하거나 다르게 하는 경우를 일컫습니다. 이를 지칭하는 정확한 용어가 있는지는 모르겠지만 일종의 버그 중 하나이지요.
어떤 작업이 하나씩 수행되어야 하는데, 두 개씩 수행되는 예라든지 흔하게 발생할 수도 있어요.
어려움에 빠진 동료 이야기
휴먼 에러가 어려운 이유 중에 하나는 명확한 에러 메시지가 없다는 것입니다. 최근에 팀 내 다른 서비스를 맡은 동료가 버그가 있는데 해결을 못하고 있어 이를 도와주었던 이야기를 각색했습니다.
CAPTAIN 서비스 담당자(이하 C): 사일런트 푸시가 동작을 안 해요. 도와주실 수 있나요?
MINT 서비스 담당자(이하 M): 어? MINT에서는 잘 동작하니까 코드 참고해 보세요.
C: 같은 시스템 델리게이트 함수를 사용하는데, 호출이 안되고 있어요.
M: 그렇다면 애플리케이션 설정을 비교해서 확인해 보아요.
C: 차이점이 없는데 동작을 안 해요.
M: 같이 봅시다. (페어 프로그래밍 잠시) 오, 진짜 동작을 안하네요. (하나씩 비교 확인해도 찾지 못함.)
C: 푸시는 동작하는데, 사일런트 푸시만 동작을 안 해요.
M: 이미 동작하는 서비스 코드에서는 찾기 어려우니, 검증하기 위한 샘플 앱을 만들어서 확인해 보는 게 어떨까요? 여기서 동작하면 작성한 코드 문제 외에 차이점을 확인해 볼 수 있어요.
C: (확인 후에) 샘플은 동작하는데, C 서비스에서만 안 하네요.
M: (때마침 급한 일 끝남) 저도 볼게요. 확인한 샘플 프로젝트 코드 공유해 주세요.
(살펴보고, 페어 프로그래밍 중)
M: 제가 샘플 앱 코드를 이렇게 고쳐서 쓰니 동작을 안 하던데요. 동작했던 형태로 다시 함께 볼까요?
C: 제가 코드를 덜 바꿔 드렸었나 봐요. 이렇게 했었어요. (탁탁탁)
M: 어? 이거 왜 여기 있어요??????? 이 코드를 기능 별로 정리하다가 그랬나 본데요!
C: 오! 이거였군요!
어떤가요? 간단한 대화 같지만 저 사이에는 며칠~몇 주라는 시간이 흘렀습니다. 우선순위가 낮았던 일이라 다른 일과 병행하고 코드의 문제인지 환경의 문제인지 테스트의 문제인지 번갈아 가면서 확인하다 보니 시간이 오래 걸렸던 일이죠.
iOS에서 Push 관련 기능은 UNUserNotificationCenterDelegate로 구현하여 동작하고 있습니다.
여기 개발자 문서에 나온 함수들이죠.
그런데! 여기서 잠깐, 위에서 우리는 ‘사일런트 푸시’를 이야기했습니다. 따라서 푸시 기능 구현의 코드에 사일런트 푸시 delegate의 구현 코드가 작성되어 있었는데요.
개발자 문서를 마저 볼까요?
차이점을 찾으셨나요? 그렇다면 훌륭한 동료 및 개발자 조건을 달성한 셈입니다.
기능 단위로 코드를 작성한다는 생각에 사일런트 푸시와 푸시 기능을 함께 모았지만, 사일런트 푸시의 응답을 구현하는 코드는 UIApplicationDelegate에 속해있었습니다. 다른 델리게이트가 필요하였으니 당연하게 호출되지 않아 동작을 하지 않았던 일이죠.
여기서 샘플 앱은 소스 파일을 여럿 만들지 않고, 하나에 모두 작성해서 동작을 했던 것이었습니다. (저는 이걸 다시 C 서비스 코드를 참고해서 재작성했더니 동작 안 하는 환경을 만들었습니다.)
마치며
휴먼 에러는 코드 작성자 본인이 찾기 어려운 경우가 많습니다. 본인의 의도에 매몰되어 코드를 읽다 보면 틀린 점을 찾기 어려운 셈인데요. 이러한 경우에는 팀 동료를 찾아보세요. 페어 프로그래밍이 특히 유효합니다. 내 눈에는 어려운 내용이 동료와 함께 코드를 보면서 설명하거나 찾아보면, 다른 사람의 눈에는 어려운 문제가 아닐지도 모릅니다.
코드 또한 사람이 작성한 글의 하나입니다. 컴퓨터에게 일을 시키기 위함이 주 목적이나, 많은 시간 다른 사람(또는 미래의 자신)이 읽어야 하는 글입니다. 간결하게 컴퓨터에게 시킬 일만 작성해도 좋지만, 팀에서 정한 코드 컨벤션에서 벗어나지 않는다면 되도록 사람이 읽기 좋은 코드, 이해하기 좋은 코드로 작성해 보는 것을 추천드립니다.
코드를 이해하는 데에는 문서도 좋고 주석도 좋지만, 역시 잘 작성된 코드 원문만 한 게 없으니까요.
