프론트엔드에서 Spring까지: 화면 뒤의 흐름을 맡게 됐다

React 프론트엔드에 집중하던 시기 이후 팀 개편과 함께 잇다 SM 프로젝트에 합류했다. Spring 백엔드와 MyBatis 매퍼까지 보게 되면서 맡는 범위가 넓어졌다. 기술 목록에 백엔드를 추가한 일보다, 화면의 결과를 설명해야 하는 범위가 달라진 일이 더 크게 남았다.

API 응답 이전에도 제품의 결정이 있었다

프론트만 볼 때는 응답 데이터를 받아 화면을 만드는 것이 작업의 중심이었다. 백엔드를 맡자 같은 응답을 만들기 위해 어떤 조건으로 조회하고, 어떤 상태를 제외하고, 어떤 권한을 검사하는지까지 따라가야 했다. 화면의 숫자 하나도 SQL의 조건과 서비스 로직을 거쳐 만들어졌다.

이 경험은 API를 설계할 때 도움이 됐다. 프론트에서 조합하기 어려운 응답을 직접 겪어 봤기 때문에, 소비자가 무엇을 다시 계산해야 하는지 보였다. 그렇다고 화면마다 별도 응답을 무한히 만드는 것이 답은 아니었다. 화면 편의와 도메인 규칙의 일관성 사이에서 경계를 잡아야 했다.

전체를 본다는 말의 비용

Spring의 의존성 주입과 서비스 구조, MyBatis XML 매퍼를 실무에서 익혀야 했다. 프론트·백엔드를 모두 만질 수 있다는 것은 유연함이지만, 동시에 어느 쪽도 대충 넘길 수 없다는 뜻이었다. SQL이 맞아도 권한이 빠지면 문제가 되고, API가 맞아도 UI가 실패를 숨기면 사용자는 잘못된 결과를 받아들인다.

지금이라면 변경 하나를 화면, 요청, 서비스, 쿼리, 응답의 순서로 짧게 추적하겠다. 모든 코드를 문서화하려는 것이 아니라 어느 계층이 규칙을 책임지는지 적어 두는 것이다. 같은 검사를 여러 곳에 복제하기 전에 최종 판단의 위치를 정하겠다.

유지보수에서 배운 완료의 기준

운영 프로젝트에서는 새 기능이 보이는 것만으로 일이 끝나지 않았다. 기존 사용자가 하던 일이 계속 되어야 했다. 당시 부족했던 테스트와 에러 처리에 대한 아쉬움도 이 환경에서 더 분명해졌다. 다시 한다면 수정한 경로뿐 아니라 같은 쿼리나 서비스를 공유하는 화면을 함께 확인하겠다.

이 전환으로 모든 분야의 전문가가 된 것은 아니다. 대신 문제가 화면 밖에 있을 때 어디를 따라가야 하는지 알게 됐다. 풀스택이라는 말보다 내게 중요한 변화는 사용자 행동 하나가 데이터에 도달하고 다시 화면으로 돌아오는 흐름을 설명할 수 있게 된 것이었다.

관련 기록: 셈웨어에서 잇다 SM으로 이어진 경험