현업 선배님들, 로직을 짤 때 "DB 조회를 최소화 하기 vs 유지보수 생각하기" 어떻게들 고려하시나요?

Question

개발하면서 아직도 정답을 못 찾겠는 점이 있습니다.바로 &#34;DB조회를 최소화하여 로직을 작성&#34; 하느냐?아니면 &#34;DB조회를 여러 번 수행하더라도, 유지보수성 좋게 로직을 작성&#34; 하느냐 입니다.DB I/O가 '많이' 발생하면 안 좋은 거로 알고 있습니다.그래서 웬만해서 메모리에 적재시킨 다음 핸들링하는 방향으로 많이들 개발하시는데,정말 고민인 점은DB조회를 최소화하기 위해서는 유지보수가 좋은 코드가 작성되진 않습니다.그런데 DB 조회를 좀 여러 번 하게 되면, 파트가 확실히 분리되니까 유지보수성에 좋은 코드가 되는 것 같습니다.기능만 동작하면 되지 않냐라는 관점에서 보면 정답은 없겠지만, 나라면 어떻게 할 것이다라는 다들 기준이 있을 거라 생각이 듭니다.예를 들어 현재 회사에서 계층삭제를 수행할 때,기준이 되는 pk 기준으로 DB에서 계층적으로 조회를 해옵니다.그 이유는 client에 적재된 데이터 기준 삭제를 요청하려 할 때, 다른 트랜잭션에 의해 client쪽이 갱신되었으나, 삭제하는 쪽에는 반영되지 않아 이를 맞춰주기 위함이라고 합니다.(당연히 무결성 제약에 걸려서 삭제는 안 되겠지만, 사용자에게 에러 메시지를 반환하는 것보다 삭제 요청하면 삭제가 되게끔 해야 한다 봅니다.)그래서 락을 걸어놓고 db에서 계층적으로 다시 조회를 수행하는데요,이때 조회되는 데이터들에 대해 유효성 검사를 수행해야 합니다.방법은 2가지가 있었는데계층적으로 조회하면서 조회하는 데이터들 개별적으로 if문으로 유효성 검증유효성에 위배되는 항목들을 조회하는 쿼리를 한번 수행하여 위배 항목들 조회이게 유효성에 위배되는 것 1개만 있어도 throw를 던지는 거라면 1번 방법이 효율적이겠지만그게 아니라 2번 방법이 효율적이라고 하십니다.처음 제 생각에는 최대한 DB I/O를 줄이는 것이 무조건적으로 좋은 줄 알았는데,사실 걸려있는 인덱스에 대해 잘 조회만 되면 크게 성능적으로 이슈는 없다고 하시는데아직도 &#34;어떨 때 어떤 방법이 효율적인가?&#34;의 기준을 잡기가 아직 어렵습니다.선배님들의 조언 부탁드립니다!

엽토군 · Answer

짧은 경험으로 직관하고 있는 부분입니다만, DB read 자체가 문제가 되는 상황은, 정말 그 상황이 터졌을 때 가서 걱정하셔도 됩니다.SELECT는 비용이 쌉니다. 트랜잭션 문제만 해결하고 인덱스만 잘 쓰면 됩니다.반면 코드의 유지보수성은 상당히 중요한 문제입니다. 많은 쿼리빌더가 $user->posts()->deleted()->with('comments')같은 간단한 코드를 4~5회의 연속된 SELECT로 해결합니다. 그렇게 했을 때 얻는 이득이 더 크기 때문입니다. "사용자가 삭제한 글들을 댓글과 함께 불러오기" 같은 걸 구현할 때는, 쿼리 횟수는 그다지 중요한 문제가 아니곤 합니다.주어진 문제만 놓고 보면 전형적인 글삭제후 글목록보기 문제 같은데 이 경우에도 그냥 다시 SELECT하는 게 낫습니다."계층적으로 조회하면서 조회하는 데이터들 개별적으로 if문으로 유효성 검증"이라는 작업은 만들고 계신 애플리케이션에서 전반적으로 흔히 하고 있는 작업이 아닐 겁니다. 단지 여기서의 삭제 후의 재조회라는 맥락 때문에 굳이 도입하는 절차일 겁니다. 버그나 장애는 보통 이렇게 저 혼자 특이하게 처리하는 곳에서 발생합니다. 그런 차원에서 피하는 게 좋습니다.애초에 그 재조회는 다른 조회와 구분될 필요가 없을 겁니다. 있더라도 약간의 부가 정보만 필요한 뭐 그런 정도일 거라고 예상됩니다. 그런 의미에서도 절차는 일반적일 필요가 있고, 모르긴 몰라도 "유효성에 위배되는 항목들을 조회하는 쿼리를 한번 수행하여 위배 항목들 조회"하는 게 좀더 일반화된 절차일 것으로 예상됩니다.써놓고보니 이게 맞나 싶고 쑥스럽군요! 정정해 주시면 감사합니다.

charlatan · Answer

계층적으로 조회한다는 말이 어떤 의미인지 모르겠지만 트리 형태의 데이터라고 하면 어차피 select for update 로 락을 걸었다면 한번 조회해오는 편이 훨씬 좋을 것 같은데요? 여러 번 조회하는 것이 어떻게 유지보수성이 좋은지는 잘 모르겠네요?

자읭식과읭 · Answer

저도 비슷한 고민이 있었는데, 시간복잡도가 같으면 최대한 유지보수하기 편하게 짜는게 좋은 거라는 방향으로 비스무리하게 방향 잡은거 같아요

캐티 · Answer

메모리 대역폭은 I/O가 아니더나요 .. 정답은 없지만 메모리에 모두 올린다는 것은 잘못되었을 수 있어요. 지속적으로 전체 테이블 또는 일부 레코드집합 메모리를 접유하면 일반적으로 나쁘며 리프레시를 하게되면 전체 동기화 .. 메모리 대역폭이 부족하여 병목현상이 쉽게 발생할 여지가 있어요. 이러면 망했지 않나요.

Henry-77 · Answer

정답이 있다기 보다는 상황에 따라 밸런스를 찾아야죠.예를 들어 1번 조회와 100번 조회는 성능 차이가 많이 납니다.

장독깨기 · Answer

한 번의 쿼리로 할 수 있는 일을 여러 번의 쿼리로 나누어 하는 것은 성능 문제를 야기 시킬 수 있습니다.바람직하지 않습니다. 성능은 기능 다음으로 중요한 요소입니다.많은 분들이 코드 관점에서 유지보수성을 얘기하는데요,유지 보수성은 개발자 관점이 아니라 사용자 관점입니다.가령, 한 번의 쿼리로 할 수 있는 일을 여러 번의 쿼리로 했다면,데이터가 많이 쌓였을 경우 성능 문제가 생길 수 있습니다. 유지보수성에 문제가 생긴거죠.그니까, 유지보수성에 좋은 코드라 생각한 것이 유지 보수에 문제를 발생 시킨 겁니다.그리고, 유지 보수는 사용자의 요구를 추가적으로 반영하는 것 입니다.이는 코드의 관점이 아니라, 구조의 관점입니다.즉, 유연하고 확장 가능하게 구조화 되어 있는가 이 부분이 중요한거죠.물론, 쉽게 간편하게 짤 수 있는 코드를 복잡하고 어렵게 짠다면 이 부분은 문제가 있습니다.뭐 암튼, 유지보수를 너무 코드 관점으로만 보지 않는 것이 어떨까 합니다. :)

토토땅 · Answer

이견이 많이 있을 문제라고 생각하는데 전 개인적으로 성능보단 유지보수성이 더 중요하다고 생각합니다.제 짧은 경험으로는 보통 성능상의 이슈가 발생하면 전반적인 성능이 이슈가 되기보다는 특정 부분 때문에 문제가 되는 경우가 많았습니다. 그러니까 예를 들어 기능이 100개가 있다고 하면 기능 100개가 각각 0.1초씩 걸리던 프로그램의 기능 100개가 각각 0.2초로 소요시간이 늘어 전체 프로그램의 소요시간이 2배가 되었다고 해서 당장 문제가 되진 않습니다. 그보다는 자주 사용하는 기능 1,2개가 0.1초 걸리다가 0.5초가 걸리면 문제가 되곤 하죠. 물론 장기적으로 전자의 경우가 후자의 경우보다 더 크리티컬한 경우라서 발생하지 않도록 경계해야하겠습니다. 후자는 집중해서 1,2부분만 수정하면 되지만 전자는 모든 프로그램을 전체적으로 개선해야하니까요.기본적으로는 유지보수성에 더 중점을 두되 성능이 더 중요하다고 판단되는 부분에는 성능 위주로 프로그램을 구현하는 것이 적절하지 않겠느냐는 의미입니다. 성능이 더 중요하다고 판단되는 부분이 어느 부분이냐는 프로그램마다 다르겠지만 대시보드나 기본적으로 사용자들이 자주 접근하는 부분이 되겠네요.물론 사용자들이 자주 접근하는 부분들이 더 많은 기능개선이 이루어질 것이고 자주 유지보수를 해야하는 부분에 유지보수성보다 성능 위주로 구현이 된다는 점이 이율배반적이긴 하지만 저흰 개발자이기 이전에 회사원이고 그 관점에서 유지보수성 좋은 코드를 구현하는 것도 (개발자 입장에선) 중요하지만 프로그램이 사용자 입장에서 쾌적하게 잘 동작하는 것이 더 중요하니까요.그런 관점에서 삭제 같은 경우는 자주 사용하지 않는다고 생각하면 그 부분에서는 유지보수성 위주로 구현해도 괜찮지 않나라는 생각을 해봅니다.회사원이라서 프로그램이 사용자 입장에서 잘 동작하는 것이 중요하다고 해놓고 갑자기 자주 사용하지 않는 기능이라고 유지보수성 위주로 구현을 하느냐라고 하시면 반대로 회사 입장에서 상대적으로 사용자에게는 조금 나쁜 UX(조금 느린 속도)를 제공하더라도 개발 시간을 줄일 수 있다면 그것은 그것 나름대로 적절한 균형을 맞춘 것이 아닐까 하는 생각을 해봅니다. 저 같은 경우에도 자주 안 쓰는 설정이나 삭제 같은 부분은 약간은 느려도 그냥 그려러니 하고 쓰기도 해서 자주 안 쓰는 기능의 경우에는 사용자도 약간의 아량을 베풀어주지 않나 싶습니다. 하루에 10번씩 사용하는 기능이 그러면 짜증나겠지만요.

현업 선배님들, 로직을 짤 때 "DB 조회를 최소화 하기 vs 유지보수 생각하기" 어떻게들 고려하시나요?

7개의 답변

Q&A 목록