쿼리 및 응답 형태를 데이터베이스에서 읽어와 실행하는 로직, 정말 괜찮은 방식인가요?

Question

제 의지와 관련 없이 이 방식을 몇 달 째 사용중에 있습니다만....제 머리로는 아직까지 이 방식을 왜 고집하시는걸까.. 라는 상황이어서 다른 의견을 들어보고자 합니다.로직을 간단하게 풀면 이렇습니다.프론트에서 API 호출 시 type 같은 범용 파라미터에 특정 단어를 담아 날리면쿼리가 모아져 있는 테이블로 가서 해당 type을 찾고, 해당 type에 해당하는 쿼리를 읽어와동적으로 실행 뒤 또 다른 데이터 베이스 테이블에 미리 정의 된 데이터 형태로 변환 후 응답합니다.여기에 특정 조건을 추가하면, 그냥 그 쿼리로 읽힌 테이블의 모든 데이터를 반환합니다.여기서 끝이면 다행이지만... 또 파라미터를 더 던질 수 있고, 그에 따라 응답 형태는.. 조금씩 바뀝니다.일종의 &#34;한방 API&#34; 라는 느낌이라고 보시면 될 것 같습니다.어떤 쿼리를 실행할 것인가 부터, 어떤 응답 형태를 사용할 것인가 까지 모두 데이터베이스의 테이블로 관리를 합니다.이런 한방 API가 과연 지향해도 좋은 방식인가.. 라는 난관인데,그래서 직접 질문을 한 결과무조건 쓰는건 아니고, 어떻게 확장 될 지 모르는 부분에만 쓰는거다.만약 신규로 연동해야 장치가 늘어난다면, 정보를 제공하기 위해 매 번 API를 다시 만들어야 한다. 이건 그럴 필요가 없다.그렇게 API를 새로 만들면 다시 테스트도 해야하고, 배포까지 새로 해야한다. 번거롭게 그럴 필요가 있는가?그런 상황에는 화면만 새로 만들고, API Type만 바꿔서 보내면 모든게 해결 된다.라는 답변을 받았습니다.어떻게 보면 맞는 말 이지만서도, 이걸 디버깅 또는 수정해야 하는 상황에는 눈앞이 깜깜해집니다.코드가 굉장히 많은 if 분기와 map 등으로 구성 되어 있는 것도 문제이지만,더 큰 문제는 테이블 레벨까지 쫓아 올라가기 전까지는 디버깅이 사실상 불가능 한 수준이라는 점?전부 동적으로 이뤄지도록 하기 위해 Object 객체로 사실상 도배가... 되어 있습니다.응답 데이터 형태라도 정해져 있으면 다행이지만, 그 역시 테이블을 사용하여 동적으로 관리되고 있습니다.꼭 이런 문제 외에도.. 사용 할 지 안할지도 모르는 굉장히 많은 필드를 응답에 내려주는 것 (트래픽 이슈)퍼포먼스 이슈등등..위에 언급 된 문제만 놓고 봐도, 이 문제들을 상회할 만큼 효과가 좋은 방식인가? 를 아직 모르겠습니다...여기에 더해 제가 들은 답변에는 언급되지 않았지만, 신규 장치가 정말 발생 한다면신규 장치에 해당 하는 쿼리도 테이블에 추가해야하고, 응답 형태까지 새로 작성하여 테이블에 추가해야 합니다.이 과정에 오타, 누락 등의 문제가 자주 발생하지만 문제가 될 것 없다라는 느낌입니다..

olivahn · Answer

대부분의 SI 개발자들이 신봉하는 방식 중 하나입니다.가장 큰 장점은, 요구사항이 변경되었을 때 코드를 고치고 배포를 다시하는 작업을 안해도 된다는 것입니다. 오직 쿼리만 보고, 쿼리만 수정하면 되니까요.갑사에 이리저리 휘둘리는 SI의 환경을 생각하면 꽤 합리적이라는 생각이 들때도 종종 있긴 합니다.하지만 말씀하신대로 유지보수의 관점으로 들어가면 정말 속에서 천불이 올라오고 입에서는 쌍욕이 나오는 개발방식이기도 합니다. 뭘 알아볼수가 있어야 버그를 고치건, 코드를 개선하건 할텐데 당최 한눈에 알아볼수가 없고, 반드시 디버그 모드로 실행을 시켜서 브레이크포인트를 잡아 한땀한땀 메모리를 뒤져야 겨우 흐름을 알 수 있으니까요.제가 SI 출신 개발자들을 정말 부정적으로 보는 이유중 하나기도 합니다. 대부분 개발을 그런식으로 하시거든요.동료의 DX와 생산성을 지옥 밑바닥으로 끌어내리는, 같이 일하는 동료에 대한 배려가 없는 개발방식이라고 생각합니다.본인들 개발할때는 편하기야 더럽게 편하겠죠 ㅎㅎㅎ 자기들이 짠 쿼리만 툭툭건들면 될테니까요. 하지만 정작 시간이 좀 지나면 본인들도 본인들이 작성한 쿼리를 못알아보죠. 아... 어차피 납품하고 떠나는 입장이고, 유지보수는 SM 인원들이 하니 상관없을라나요? 그런 관점으로 보면 굉장히 합리적이긴 하네요.

장독깨기 · Answer

무슨 상황인지는 모르겠지만, 모든 API 를 그런 식으로 할 수는 없을 겁니다.그러나, 일부 API 가 로직은 단순하지만, 주고 받을 필드가 변경이 잦을 경우,변경이 있을 때 마다 그걸 고치는 것 보다, 테이블에 동적으로 정의해서 사용하면,좀 더 유용하게 처리할 수 있는 방식 같기도 합니다.그러나, 예외가 많아서 조건 문이 덕지덕지 붙는다면 별로 유용한 방식은 아니겠지요.그리고, SI 에 대해 이상한 오해를 하는 사람이 많아서요, ㅎㅎ저거 대부분 SI 개발자들이 신봉하는 방식 아닙니다. 저렇게 만드는거 더 골치 아파요.

쿼리 및 응답 형태를 데이터베이스에서 읽어와 실행하는 로직, 정말 괜찮은 방식인가요?

2개의 답변

Q&A 목록