엑셀 업로드 기능 잘 못 개발하면 나중에 피본다.

서비스를 사용하는 사용자가 있으면, 서비스를 관리하는 관리자가 있다. 관리자가 사용하는 기능은 사용자가 원하는 기능보다 우선순위가 낮게 되는 경우가 많다. 그래도 매번 개발자를 통해서 진행되는 업무가 잦아지면 효율화를 위해 관리자 기능을 개발하게 된다.

엑셀 업로드는 대량으로 컨텐츠를 추가하거나, 사용자를 추가할때 자주 사용된다. 하지만 꽤나 무서운 기능이고, 제대로 QA를 하지 않으면 서비스 자체를 망쳐버린다.

PM이라면 프론트엔드 / 백엔드 / 데이터베이스 정도의 용어엔 익숙할 것이고, 데이터베이스의 데이터를 백엔드에서 적절히 가져와서 프론트엔드에 넘겨주는 API에 대해서도 익숙할거다. 원칙적으로는 프론트엔드는 백엔드가 주는 데이터를 믿어선 안되고, 백엔드도 프론트엔드가 넘겨주는 데이터를 믿어서는 안된다. 그렇기에 양쪽에 모두 검증하는 로직을 추가하고, 약속과 다른 데이터가 왔을때에 에러를 내며, 약속하지 않은 데이터가 데이터베이스에 들어가는 것은 무조건 막는다.

하지만 좋은게 좋은거라고 마치 편의점에서 담배를 살 때 모든 사람에게 신분증검사를 하지 않듯이, 편의상, 일정상 이런 검증로직은 빠질때가 많고, 그중에서 제일 빠지기 쉬운게 엑셀로 업로드된 대량의 데이터에 대한 검증이다. 프론트엔드는 백엔드를 믿고 엑셀파일을 보내고, 백엔드도 프론트엔드도 믿고 엑셀에 있는 내용을 그대로 데이터베이스에 올린다. 모두가 약속만 잘 지킨다면 아무일이 없겠지만, 악의가 없어도 실수가 생기고 작은 실수, 예를 들면 빈 셀이 하나 들어간다거나, 문장부호가 잘못되었다거나 하나씩 밀려쓴다거나 하는 크고 작은 실수가 분명히 생긴다.

이런 데이터가 데이터베이스에 들어가면, QA하기도 어렵고 버그를 인식해도 재현하기도 어렵다. 아마 특정한 데이터를 사용하는 사용자에게서만 발생하기에, 간헐적이고 개발팀에 리포트를 해도 재현이 안된다는 소리가 나온다.

엑셀 업로드 기능은 편리하긴 한데, 그만큼 검증로직도 빡세게 걸어야 되고 최소한 잘못된 데이터가 올라가지 않게 해야되며, 제대로 하려면 어떤 row가 문제가 되는지 정도도 알 수 있게 개발을 해야한다.