[개발자적 마인드] 백엔드의 관점

회사에 입사하고 1주일이 지났다.

그간 사내 핵심 비즈니스에 대해 이해하고, DB 구조 살펴보고, 코드 살펴보느라 정신없이 시간을 보냈다.

그러던 와중에 개발팀 요청사항 중 한 건을 맡아서 담당하게 되었다.

 

어드민 사이트 (CRM)의 데이터 일괄 변경 처리 기능을 추가하는 작은 태스크였는데,

이것을 확인했을 때 내가 할 수 있겠다 싶어 동료분께 말씀드렸고, 승인을 받았다.

 

처음에는 아무것도 모른 채 코드를 쭉 살펴보는데, 기존에 있는 api를 그대로 활용해도 될 것 같은 느낌이 든 것이다.

그래서 request body의 파라미터 스키마 검사하는 부분만 살짝 수정하여(새롭게 추가되는 데이터를 반영) PR을 올렸고, 로직은 변경할 필요 없이 결과가 잘 반영되는 것 같아서 내가 일을 마무리한 줄 알았다.

 

지금 생각해보면 왜 그랬지? 생각도 들고, 너무 성급하게 모든 것을 단정지어 판단했었다는 반성을 하게 된다.

개발자라면 당연히 발생 가능한 모든 케이스에 대해 면밀히 확인하고, 직접 하나 하나 파 가면서 알아봐야 했는데, 그러지 않은 것이다.

그리고 이 글의 핵심인 백엔드적 개발자의 관점을 전혀 투영하지 않고 처리했다.

 

물론 기존의 코드가 legacy 형태로 이루어져 있었고, 테스트 코드도 없었으며 관련 DB 테이블들 역시 json 컬럼으로 도배된 난해한 상황이었으나,

이는 개선해야 하는 부분이지, 내가 안일하게 개발할 핑계거리가 되지 않는다.

PO님께 혼나고조언을 듣고 나의 처리방식의 문제점에 대해 곰곰히 짚어보았다.

 

첫번째. 클라이언트를 고려하지 않았다.

요청사항이 새로운 기능 추가인데, 기존의 url endpoint 로 처리하게끔 했다.

만약, 요청사항이 바뀌거나, 코드 리팩토링을 해야 하는 경우, 기존 endpoint 가 바라보는 api로 해결이 되지 않는 경우엔 새로운 api 를 만들어 대응해야 한다. 새로운 api를 만든다는 것은 새로운 endpoint를 만드는 것이고 그러면 클라이언트 측에서도 새로운 endpoint로 변경 작업을 수행해야 한다. 이는 명백한 사이드 이펙트이다. 서버 단에서만 처리하면 될 일을 클라이언트에서 불필요한 작업을 유발하는 것이다. 클라이언트가 실제 고객에게 보여지는 부분을 담당한다면, 서버는 클라이언트 대상으로 작업물을 서비스한다. 서버는 클라이언트가 충분히 예측 가능한 범위 내에서 api를 디자인하고, 서버에서 일어나는 수많은 수정사항은 되도록 클라이언트가 모르게끔 한다. 

 -> 따라서 해당 요청사항에 명세된 기능만을 수행하는 api endpoint를 따로 작성하여 추후 수정사항이 생겨도 클라이언트에서 불필요한 변경사항이 발생하지 않게끔 구조화했다.

 

두번째. 비즈니스로직을 코드단에서 이해하지 않았다.

요청사항은 데이터를 일괄적으로 변경할 수 있는 기능 추가이다. 예를 들어, user 객체의 회원등급(일반회원, vip회원 등)을 일괄적으로 변경하는 기능이라고 가정했을 때, 내가 처리한 방법은 말 그대로 DB 상에서 user 테이블의 회원등급 컬럼을 수정하는 것 그 이상도 그 이하도 아니었다. 내가 간과한 것은, 해당 수정사항이 비즈니스 전반에 걸쳐 어떤 영향을 미치는지 확인하지 않은 것이다.

예를 들어 vip 회원들을 관리하는 테이블이 따로 있다고 가정했을 때, 일반 회원을 vip회원으로 변경하면 앞서 말한 vip회원 관리 테이블에 해당 유저 데이터를 넣어줬어야 한다. 즉 직접적인 수정이 가해지는 테이블 뿐 아니라 그 테이블과 연관관계에 있는 다른 테이블 혹은 데이터를 확인하고, 어떻게 비즈니스 적으로 연관되어 있는지 코드레벨에서 파악 후 대응했어야 됐던 것이다. 이는 테스트 코드의 중요성과도 어느 정도 일관성을 지니는 것 같은데, 테스트 코드를 잘 작성하는 것이 베스트이나, 피차 그러지 못하는 상황(서비스 확장이 급한 상황, 레거시 바다속에서 작업하지만 리팩토링 할 시간이 없는 상황 등..)에서는 개발자로서 비즈니스 도메인에 대한 명확한 이해를 기반으로 데이터 간 유기관계를 잘 파악하여 해당 서비스의 목적과 플로우에 적절히 부합하게끔 비즈니스 로직을 작성한다.

-> 따라서 새로운 api를 만들면서 기획팀과 소통하며 명확한 비즈니스 로직을 작성하기 위해 요구사항, 예상 결과, 예외 케이스, 운영 절차, 예상 부작용 등을 구체화하였고, 코드 단에서도 이해하기 위해 기존 코드 중 관련된 부분들을 살펴보며 전체적인 그림을 파악하고자 하였다. (아직 파악할게 많다..)

 

클라이언트 개발에 비해 백엔드 개발 경험이 부족해서 미숙한 판단을 했던 것 같다. 그래도 1주일 동안 개발자로서 많은 것을 배운 것 같다. 이는 단순히 백엔드적 지식이 아니라 개발자로서 마음가짐에, 혹은 사고방식에 더 근접한 것 같다.

원래는 혼자 개발하거나 창업의 일환으로 개발하면서 기술적 완성도 보다는 밖으로 보여지는 부분, 퍼포먼스 이런 것을 더 중요시 했는데, 여러 부서, 여러 사람과 작업하다 보니 이러한 세심함이 실무에서 얼마나 중요한지 깨달은 것 같기도 하다.