프레임워크가 구조를 정해 줄 때

공공 과제 웹 부분을 맡았다. eGovFramework 를 쓰게 돼 있어서 파일을 어디 두는지와 계층을 어떻게 나누는지와 이름을 어떻게 짓는지가 전부 규정돼 있었다.

처음엔 답답했다.

Open Table of contents

정해진 게 많았다

컨트롤러  → 요청 받기만
서비스    → 로직
DAO       → DB 접근
VO        → 데이터 전달

계층마다 할 일이 정해져 있고 넘나들면 안 된다. Controller 에서 DB 를 직접 부르는 것은 금지이고 Service 를 거쳐야 한다.

화면에 값 하나를 더 뿌리려는데 손댈 파일이 넷이었다. VO 에 필드를 넣고 mapper XML 을 고치고 Service 와 Controller 를 거쳐야 한다. 각 계층은 Spring 빈으로 올라가고 서로를 주입받는 형태라 중간을 건너뛸 수가 없다.

한 줄이면 될 것을 파일 네 개를 만들어야 했다.

몇 주 지나고 나서 다르게 느껴졌다.

어디를 봐야 하는지 안다. 화면이면 JSP 이고 조회면 mapper XML 이며 계산이면 Service 라 찾아 헤맬 필요가 없다. 파일 이름 규칙까지 정해져 있어서 찾는 데 몇 초밖에 안 걸렸다.

다른 사람 코드가 낯설지 않다. Controller 와 Service 의 짜임이 같으니 누가 짰든 비슷하다.

그리고 논쟁이 없다. 이것을 어디에 둘까를 안 정해도 되고 이미 정해져 있다. 세 번째가 생각보다 컸는데 여럿이 하는 프로젝트에서 구조 논쟁은 시간을 많이 먹는다.

단순한 것도 복잡해진다. 값 하나 조회하는 데 Controller 와 Service 와 DAO 와 VO 를 거치고 손에 익어도 파일 수가 줄지는 않는다.

틀에 안 맞는 요구도 있다. 실시간 처리나 배치 같은 것은 이 구조와 안 맞는데 억지로 맞추면 이상해진다.

최신 기법을 못 쓰는 것도 있다. eGovFramework 가 정한 버전과 방식이 있다. 만드는 기능이 작을수록 계층을 거치는 손해가 크게 느껴졌다.

전부 틀 안에서 하려니 안 되는 것이 나와서 기준을 정했다.

틀 안에서 되면 틀 안에서 한다     조금 번거로워도
안 되면 벗어나되 격리한다         그 부분만 따로 두고 경계를 명확히
벗어난 이유를 적는다              왜 여기만 다른지

실제로 벗어난 것이 두 군데였는데 하나는 대용량 처리이고 하나는 외부 시스템 연동이었다. 둘 다 별도 디렉터리에 두고 README 에 왜 Service 를 안 거쳤는지 적었다.

빈으로 안 올리면 주입도 못 받으므로 필요한 것은 직접 들고 있어야 했다. 이 판단이 맞았는지는 아직 모르겠고 그 코드를 다른 데서 부를 일이 생기면 다시 계층 안으로 넣어야 할 수도 있다.

관례는 문서보다 코드에서 배웠다. eGovFramework 문서가 두꺼워서 다 읽을 수 없었고 비슷한 기능의 Controller 를 찾아 그 구조를 따라 하는 것이 빨랐다.

문서에서 못 찾던 관례가 코드에는 있었다. 다만 기존 코드가 관례를 어긴 부분도 있어서 여러 곳을 보고 다수를 따랐다.

이 경험으로 정한 것이 있다.

사람이 여럿이고 오래갈 프로젝트   틀이 있는 게 낫다
혼자 하거나 짧은 프로젝트         틀이 부담이다
요구가 틀과 안 맞는 부분이 많다   틀을 바꾸거나 안 쓴다

혼자서 짧게 만들고 끝낼 것이면 VO 부터 Controller 까지 넷을 고치는 비용만 남는다. 여럿이 오래 만지면 반대가 되고 어디를 볼지 정해져 있는 것이 매번 읽는 시간을 줄인다.

이번 과제는 인수인계가 두 번 있었고 넘겨받은 사람이 헤맨 시간이 짧았던 것이 이 구조의 값이었다.

이 틀이 이 프로젝트에 맞는가를 먼저 보는 것이 맞았다. 틀 자체의 좋고 나쁨이 아니라.