개발자 일지 #3: 누가 사용하면 나타나는 버그

Source: Dev.to

직장에서 코드는 전혀 바뀌지 않았다. 바뀐 것은 고객이 데이터를 입력하는 방식이다. 그리고 이 때문에 기존 테스트가 잡지 못한 문제가 깨졌다.
E2E를 처음부터 만들게 된 동기는 특정 문제 때문이었다.
앱에 접근해서 깨야 했다. 단위 테스트가 잡을 수 있는 고립된 논리 오류가 아니었다. 실제 데이터가 실제 흐름에서 결합되어 화면에만 나타나는 잘못된 결과를 만들었다. 고객은 우리보다 먼저 그곳에 도달했다.
이것은 코드 테스트로는 해결되지 않는 문제 유형이다. 문제는 코드에 있는 것이 아니라 코드, 데이터, 환경 간의 상호작용에 있다. 가장 빠르게 사전에 포착하는 방법은 사용자가 하는 그대로 전체 흐름을 실행해 보는 것이다.
주요 제품 흐름을 커버하는 스모크 테스트와 여러 환경에서 실행하도록 설정하고, nightly가 깨질 때 Slack으로 알림을 보내도록 했다.
가장 유용한 부분은 테스트 자체가 아니라, 고객이 보고하기 전에 알 수 있다는 점이다.

내가 유지하고 있는 별도 프로젝트에서 주말을 자동 이미지 크롭 작업을 구축하는 데 보냈다.
처음 아이디어는 객체 감지가 내장된 imgproxy Pro를 사용하는 것이었다. 내가 가진 다양한 이미지에 충분히 정확하지 않았다. 그래서 Rekognition을 사용했는데, 이는 바운딩 박스를 반환한다. 제어는 더 가능하지만 바운딩 박스는 한계가 있다: 사각형이다. 객체는 사각형이 아니다.
그때 rembg를 발견했다. 다른 방식을 한다. 영역을 지정하는 대신, U2Net이라는 네트워크를 사용해 픽셀 단위로 마스크를 만든다. 이 네트워크는 전경 분할을 위해 훈련되었다. 결과는 훨씬 우수했다 — 객체 자체를 잘라내고, 그 주위에 박스를 만들지 않는다.

이를 Lambda에 올리는 과정이 이번 주를 가장 느리게 만들었다. 모델이 Lambda 프로세스에서 접근 가능해야 했는데, /root에 두었더니 Lambda가 읽지 못했다. /opt로 옮기고 chmod 755를 적용했다. NUMBA가 읽기 전용 디렉터리에 캐시를 쓰려 하자, NUMBA_CACHE_DIR=/tmp 로 지정했다. 큰 이미지에서 OOM이 발생해 메모리를 2048 MB로 늘렸다. 각각 배포 사이클을 한 번씩 거쳐야 적용됐다.

최종 파이프라인은 레이어별로 다른 승인 기준을 두었다: 먼저 엄격한 기준의 rembg. 통과하지 못하면 rembg를 더 유연한 기준으로 적용한 Rekognition을 병렬로 실행. 어느 것도 통과하지 못하면 수동 검토. 어떤 ML 접근도 100 % 케이스를 커버하지 못한다 — 아키텍처가 이를 고려한다.
그 위에 만든 리뷰 UI는 결과물이다: 폴백이 인간이라면 괜찮은 인터페이스가 필요하다. 폴백이 곧 기능이 되었다.

이전 내용이 궁금하면 #0과 #1은 dev.to에 있다. #2는 좀 더 여유로운 한 주였고 LinkedIn에만 올렸다.