오픈소스인데 역공학부터? 안드로이드 소스 공개가 늦을 때 생기는 비용

핵심 요약

• bionic은 안드로이드에서 메모리·문자열 처리 같은 기본 기능을 제공하는 C 라이브러리 등을 담은 프로젝트입니다.
• 실행 파일에 대응하는 소스 공개가 늦어지면 개발자는 버그 분석에 필요한 단서를 제때 얻기 어렵습니다.
• 역공학으로 동작을 확인할 수는 있지만, 변경 이유와 버그가 수정됐는지까지 알아내려면 추가 검증이 필요합니다.
• 소스가 언제 공개되는지, 어떤 배포 버전에 해당하는지 알아야 오픈소스를 실제 개발에 활용하기 쉽습니다.

오픈소스에서 버그를 만나면 코드를 열어 확인하면 된다고 생각하기 쉽습니다. 하지만 내 휴대폰에서 실행되는 버전의 소스가 아직 공개되지 않았다면 바로 확인할 수 없습니다. 소스가 늦게 공개되는 만큼 개발자가 디버깅에 더 많은 시간을 써야 할 수 있습니다.

bionic은 왜 앱 개발자에게도 중요할까요

AOSP는 Android Open Source Project의 약자입니다. 안드로이드의 오픈소스 기반을 개발하고 공개하는 프로젝트입니다. 그 안에 있는 bionic은 C 표준 라이브러리와 수학 라이브러리, 동적 링커 등을 포함합니다. 동적 링커는 프로그램이 실행될 때 필요한 라이브러리를 연결하는 구성 요소입니다.

앱 개발자가 이런 내부 구성까지 늘 들여다볼 필요는 없습니다. 다만 C나 C++로 작성한 네이티브 코드를 쓰는 앱에서는 이런 구성 요소를 살펴봐야 할 때가 있습니다. 앱이 어떤 코드를 실행하는지 따라가다 보면 메모리 할당이나 문자열 처리 같은 기본 동작에서 bionic을 거칠 수 있기 때문입니다.

이런 기반 코드에 문제가 생겨도 겉으로는 앱 오류처럼 보일 수 있습니다. 개발자는 자신의 코드가 잘못됐는지, 운영체제 쪽 동작이 달라졌는지부터 구분해야 합니다. 이때 기기에서 실행 중인 버전과 맞는 소스가 중요한 단서가 됩니다.

소스가 늦으면 원인을 찾기 전에 할 일이 하나 더 생깁니다

가령 운영체제를 업데이트한 뒤 같은 입력을 넣었는데, 네이티브 코드의 처리 결과가 달라졌다고 해보겠습니다. 실제 사건을 옮긴 사례는 아닙니다. 소스 공개가 늦어지면 어떤 부담이 생기는지 설명하기 위한 가정입니다.

개발자는 먼저 문제를 재현하고 앱에서 코드를 잘못 사용한 곳은 없는지 확인합니다. 그러고도 원인을 찾지 못해 bionic의 특정 함수까지 의심하게 됐다면, 업데이트 전후의 구현을 비교해보고 싶을 겁니다.

그런데 새 실행 파일에 대응하는 소스가 없다면 두 버전을 비교하기 어렵습니다. 공개된 코드를 아무리 읽어도 기기에서 확인한 동작이 왜 나오는지 설명하지 못할 수 있습니다.

이때 쓸 수 있는 방법 중 하나가 역공학입니다. 완성된 실행 파일을 분석해 내부에서 어떻게 동작하는지 거꾸로 알아내는 작업입니다. 기계어를 사람이 읽을 수 있는 형태로 풀어 보거나, 실행 중인 프로그램의 값을 추적해 조건 분기와 함수 호출을 확인합니다.

원래라면 소스에서 변경된 부분을 읽고 찾았을 단서를 실행 파일에서 복원하는 셈입니다. 버그를 고치기도 전에 무엇이 달라졌는지 알아내는 데 별도로 시간을 써야 합니다.

동작을 알아내도 검증은 끝나지 않습니다

역공학으로도 버그의 원인을 찾을 수 있습니다. 다만 실행 파일에는 원래 소스에 있던 주석이나 코드를 바꾼 이유가 그대로 남아 있지 않습니다. 컴파일러가 코드를 최적화하면서 코드 형태가 달라지기도 합니다.

특정 조건에서 함수가 어떻게 동작하는지 알아냈더라도 더 확인할 내용이 있습니다. 어느 변경부터 이 동작이 생겼고 의도한 결과였는지 알아야 합니다. 다른 버전에서는 이미 수정됐는지도 확인해야 합니다. 소스와 변경 이력이 있으면 따라가며 확인할 내용을 개발자가 따로 찾아야 하는 겁니다.

그렇다고 원인을 섣불리 단정해서는 안 됩니다. 공개 소스와 기기의 동작이 다르다는 사실만으로 소스 공개 지연을 원인으로 단정할 수는 없습니다. 제조사가 적용한 수정이나 빌드 설정 차이도 확인해야 합니다.

코드가 공개돼 있어도 그 코드가 어떤 배포 버전에 해당하는지 알 수 있어야 합니다. 둘 사이의 관계가 불분명하면 소스가 공개된 뒤에도 엉뚱한 버전의 코드를 들여다보며 시간을 보낼 수 있습니다.

공개 시점도 오픈소스의 실용성을 결정합니다

소스 공개가 늦어지면 개발자는 코드를 기다리는 데만 시간을 쓰는 게 아닙니다. 원인을 확신하지 못해 임시 우회 코드를 넣거나, 여러 운영체제 버전에서 추가로 시험해야 할 수 있습니다. 다른 팀이 같은 문제를 만나면 비슷한 분석을 처음부터 반복할 수도 있습니다.

저는 이 과정에서 검증 비용의 이동에 주목하게 됩니다. 배포된 코드에 맞는 소스를 늦게 확인할수록 외부 개발자는 이미 만들어진 코드의 동작을 다시 알아내는 데 시간을 씁니다. 분석 도구가 부족하거나 운영체제를 다뤄본 경험이 적은 팀이라면 이 작업이 더 큰 부담이 될 수 있습니다.

개발자가 공개된 소스를 유용하게 쓰려면 필요한 시점에 배포 버전과 맞는 코드를 찾을 수 있어야 합니다. 여기에 변경 이력을 따라가며 알려진 문제의 수정 상태까지 확인할 수 있다면, 같은 내용을 다시 조사하는 수고도 줄어듭니다.

문제가 생겼을 때 해당 코드를 바로 확인할 수 있다는 점은 오픈소스의 장점입니다. 안드로이드 소스 공개를 평가할 때도 개발자가 실제 배포 버전을 얼마나 쉽게 검증할 수 있는지 살펴봐야 합니다. 코드가 공개됐는지뿐 아니라, 문제를 해결하는 데 필요한 순간에 그 코드를 찾아 쓸 수 있었는지도 평가 기준이 됩니다.