쉬운 문제는 쉽게 풀어야 한다

서비스가 성장하면 잘 돌아가던 코드에서 조금씩 문제가 발생합니다. 어느 순간부터 어드민 조회가 느려지더니, 타임아웃으로 조회가 실패하는 현상이 발생했어요. 문제 된 쿼리에서 조인된 테이블은 4개, 쿼리 실행계획을 보니 인덱스를 타지 않고, full scan으로 동작했습니다. 이때 저는 2가지 접근 방법이 떠올랐어요. 1️⃣ SQL에 딥 다이브하여 쿼리를 개선합니다. 개발자답게 쿼리를 리팩토링해 성능을 향상시키는 거죠. 2️⃣ 문제를 사라지게 합니다. 수줍게 밝혀보자면 저는 2번, 즉 문제를 사라지게 하는 것을 선호합니다. 정말로 개선할 필요가 있는 문제인가를 먼저 확인합니다. 이 기능이 사용자의 니즈에 맞게 설계된 확인해요. 얼마나 많은 사용자가 빈번하게 사용하는지 접근 로그를 통해 사용성을 확인합니다. 이 많은 데이터를 한 화면에서 조회하는 게 정말 필요한지도 직접 물어봐요. 알고 보면 사용자가 필요로 하지 않는 데이터를 보여주느라 지나치게 조인을 많이 했을 수도 있으니까요. 최초에는 여러 가지 데이터를 보고자 기획했을 수도 있는데, 시간이 지나면서 목적과 용도가 바뀌기도 하니까요. 기획자를 나무랄 일이 아니지요. 문제 자체를 쉽게 풀고자 하는 마음은 이런 경험들 때문인데요. 힘들게 성능 향상을 했는데, 알고 보면 "음.. 사실 이 기능 별로 사용하지 않아요."라는 이야기를 들은 적이 꽤 있었거든요. 알고 보면 사용되지 않는 기능인데 고쳤던 경우도 있었구요. 문제를 어렵게 풀었다는 생각에 허탈해졌어요. 사용자가 기능을 어떻게 사용하는 지 본질을 파헤치다 보면 다르게 해결할 수 있는 경우가 많았어요. 김상욱 교수의 강연에서 '과학자의 접근법'에 대해 들었는데요. 교수님이 학생들에게 방탈출 문제를 냈대요. 학생들은 탈출하기 위해 방 안에서 열쇠를 찾습니다. 과학적인 접근법이라면 방을 4 x 4 그리드로 나누고 그 안에서 열심히 찾아봅니다. 찾지 못했어요. 그러면 더 촘촘하게 방을 8 x 8 그리드로 나눠 더 꼼꼼하게 열쇠를 찾습니다. 그래도 찾지 못하면 그때 '아 열쇠가 방 안에 없구나'라는 확신을 가지게 되고, 방문을 열어 밖에서 열쇠를 찾게 됩니다. 그중 경계 없이 생각하는 학생은 방을 촘촘하게 뒤지기 전에 문을 벌컥 열고 나가는 경우가 있대요. 그러나 과학적인 접근법은 꼼꼼하게 문제를 푸는 것이고, 이를 통해 '이 방법으로는 문제를 풀 수 없다'는 것을 확신하고 나서, 다른 방법으로 접근합니다. 우리가 푸는 문제는 대부분 과학적, 공학적인 접근법으로 가는 게 맞을 거예요. 그러나 들어가는 시간과 비용을 고려했을 때, '쉽게 풀 수 있을까?'라는 생각으로 문고리 한번 돌려볼 수도 있는 거잖아요. 키가 안에 없다고 가정하고 문을 열어보는 것은 낮은 비용으로 확인해 볼 수 있으니까요. (방탈출가서 문제 안 풀고 다른 데 가서 들쑤시고 있는 사람이 접니다. 대부분은 주어진 문제를 풀어야 풀리더라구요^^; 그래도 가끔 히트할 때가 짜릿한걸요.. ) 조인이 많은 쿼리에서 문제를 쉽게 푸는 방법은 조인을 없애는 것입니다. 정말 이 많은 테이블이 조인되어 한 번에 조회되어야 할까. select 하는 컬럼 중 어떤 것 때문에 조인하는 것일까. 그 컬럼은 정말 필요할까? 만약, 조인을 없앨 수 없는 상황이었다면 어떻게 할까요? explain으로 쿼리 실행 계획을 살펴보고, 인덱스를 추가해서 개선할 수 있을지, 쿼리 힌트를 사용해야 할지 고민해 보고 DBA에게 조언을 구할 것 같아요. 쿼리를 가장 잘 아는 사람에게 도움을 구하며 지식을 얻을 수 있으니까요. 하지만 모든 회사에 DBA가 있는 것도 아니고, 조언을 구할 수 없는 상황이 있겠죠. 우리 개발자들이 잘하는 것처럼 커뮤니티에 올려 도움을 요청할 것 같습니다. 감사하게도 개발자 문화는 열려있기 때문에 다양한 곳에서 의견을 구할 수 있습니다. 하지만 커뮤니티에 올리는 것이 버겁게 느껴질 수 있습니다. 스스로가 찾을 수 있는 최선의 방법으로 해결하되 최고의 방법이 아니라는 것은 알아두면 되지 않을까요. 현재 내가 적용할 수 있는 최선의 방법이 여기까지라는 것을 받아들입니다. 이 또한 나쁘지 않다고 생각해요. 기획자나 디자이너에게 한계점을 설명하고, 유저향 서비스라면 UI/UX로 문제를 푸는 방법을 사용합니다. 어드민 같은 내부 사용자를 위한 것이라면 사용 조건을 제약한다는 것을 알립니다. 우리는 대체로 문제를 물어뜯고 딥 다이브하는 정공법을 사용합니다. 그러나, 본격적으로 들어가기 전에 문고리 한번 돌려보면 어떨까요?