<div id="readability-page-1" class="page"><div><p>프로젝트 개발 초기에 여러 고민들이 생긴다. 그리고 결정해야 한다. </p>
<p>작은 문제로 치부하고 넘어가면 나중에 큰 골칫덩이가 되어 돌아오며 반대로 여러 상황을 가정하고 확장성을 고려하여 시간을 투자했다가 오버 엔지니어링과 시간 낭비로 이어질 수 있다.<br>특히 빠르게 의사결정하고 결과물을 만들어야 하는 회사에서는 오래 검토하고 논의할 시간(또는 동료)조차 없다. </p>
<p>현재 시스템에서 개발/운영하며 아쉬운 부분이 많이 생각날 수 있다. 개발자라면 누구나 "새롭게 만든다면 잘할 수 있을 텐데"라고 생각한 적이 있을 것이다. 그럼에도 정작 새롭게 만든 시스템이 완벽하게 릴리즈 되어 유지되는 케이스는 본 적 없다. 한 번 만든 시스템이 완벽하다면 개발자라는 직업은 사라지지 않았을까? </p>
<p>그럼에도 절대 양보할 수 없는 부분들이 있다. </p>
<p>그동안 프로젝트를 셋업, 진행하며 마주한 고민들, 생각하고 결정한 것들을 정리한다. 그 안에는 대부분 지키지 못하는 확고한 기준과 취향이 존재할 수 있다.<br>족보가 아니다. 완벽한 것은 없다. 다만 내가 잘 준비되어 있는지가 더 중요하다.</p>
<h3>1. 테스트 케이스</h3>
<p>개발에 있어서 '나중에'는 잘 지켜지지 않는다. 내가 지킬 수 있다면 반대로 상황이 그러지 못할 때가 있다. 논란의 여지 따위는 없다. 반드시 작성한다. </p>
<h3>2. 요청/응답 클래스 모델화, 분리</h3>
<p>http 통신 시 요청, 응답 클래스는 분리하는 게 좋다. 나쁜 예로 JPA Entity를 응답 클래스로서 활용하면 비즈니스 로직이 서비스 도메인에 침범할 수 있다. 이는 조금만 프로젝트가 커져도 비즈니스와 Client 응답 사이에 의존 관계가 생겨 분리하기가 쉽지 않으며 사이드 이펙을 확인하기도 어렵다.<br>메시지의 요청, 응답 값이 명시적이지 못하면 개발자는 모든 로직을 파악하고 어떤 값이 담길 수 있는지 알아내야 한다.<br>이와 관련하여 최악의 케이스를 경험한 적이 있다. 서버에서 받아온 값을 Map에 담아 몇 가지 가공한 뒤 바로 Client로 응답하는 코드를 수정해야 했다.<br>케이스를 모르니 테스트를 만들 수 없었을뿐더러 사이드 이펙 또한 전혀 알 수 없었다. 결국 운영서버에서 Tcp dump로 송수신되는 데이터 셋을 뽑아내야 했다.<br>이후에 응답 클래스를 만들고 Class로 모두 분리시켰다.<br>단순 코딩만 10초면 할 일이 1시간 넘어 끝났다. </p>
<h3>3. 데이터베이스 분리</h3>
<p>(정말 서비스가 별개이지 않는 한) 서비스를 여러 개로 쪼개 각기 다른 데이터베이스를 보는 서비스로 만들지 않는다.<br>프로젝트 관리 / 배포 / 이슈 추적 / 아키텍처 / 인프라 / 커뮤니케이션 등의 비용이 증가한다.<br>가능한 모노리틱스 형태로 만들고 패키지 분리를 잘해보도록 노력한다.</p>
<h3>4. 리소스 값 설정 분리.</h3>
<p>코드 안에 문자열("")이 들어가면 생각해보자. 이걸 설정 파일로 분리할 수 없을지.. 하다 못해 상수로 만드는 건 어떨지.<br>대부분의 웹 프레임워크는 설정 기능을 지원하기 때문에 가능하면 이를 이용하도록 한다.<br>외부와 통신하기 위한 API 주소, timeout, 인증 키 등이 하드코딩되어있다면 여러 곳에서 복사되어있을 수 있다. 한 번 수정하려고 하면 모두 찾아내어 replace 하는 일이 없도록 한다. </p>
<h3>5. 환경 분리</h3>
<p>local, dev, production에 대한 분리는 확실하게 하자. 가능하다면 staging까지 잘 분리한다. 처음부터 잘 분리하지 않으면 나중에 가서 굉장히 곤란해진다. 로컬, 개발, 운영에 대한 경계가 모호해지며 테스트하기 힘들어진다. 나의 테스트가 누군가의 테스트를 침범하는 경우도 생긴다. 가능하면 각 환경에 맞는 property를 이용하도록 한다. 로컬에서 베타, 베타에서 운영 데이터를 조작하는 경우가 없도록 한다.<br>처음에는 별거 아닌 것처럼 느껴져도 나중에 가서 프로덕트 릴리즈 커브를 급격하게 증가시키는 요인이다. </p>
<h3>6. 웹 프레임워크 선택</h3>
<p>경량 프레임워크를 선호하는 경우를 많이 봤다. 처음 시작은 나쁘지 않을 수 있다. 하지만 이는 큰 함정이 숨어있어 조심해야 한다. 과연 현재 진행하는 프로젝트가 경량에서 중량급으로 넘어가는 걸 대비하고 변경할 수 있는 개발자/팀이 얼마나 있을까? 개발자 기술력에 대한 의심만이 아니다. 그때는 회사에 대한 설득력도 있어야 한다. 당신 회사 대표에게 "지금 당장 비즈니스를 멈추고 웹 프레임워크를 변경해야 합니다."고 설득할 수 있을까?<br>그렇기 때문에 내가 본모습은 이미 중량(?) 프레임워크/언어에서 제공되거나 과거에 했던 고민들을 재차 검토해가며 library 폴더에 자신만의 코드를 끼워 넣는 모습이었다.<br>'경량'이 주는 의미가 무엇인지 잘 생각해보자. 빠르게 코드를 변경, 반영하고 애플리케이션을 구동하고, 프로세스가 cpu, 메모리를 적게 차지하고.. 그런 것 인가?</p>
</div></div>

호돌맨의 블로그

JuHyun Lee

프로젝트 개발 초기에 여러 고민들이 생긴다. 그리고 결정해야 한다. 
작은 문제로 치부하고 넘어가면 나중에 큰 골칫덩이가 되어 돌아오며 반대로 여러 상황을 가정하고 확장성을 고려하여 시간을 투자했다가 오버 엔지니어링과 시간 낭비로 이어질 수 있다.
특히 빠르게 의사결정하고 결과물을 만들어야 하는 회사에서는 오래 검토하고 논의할 시간(또는 동료)조차 없다. 
현재 시스템에서 개발/운영하며 아쉬운 부분이 많이 생각날 수 있다. 개발자라면 누구나 "새롭게 만든다면 잘할 수 있을 텐데"라고 생각한 적이 있을 것이다. 그럼에도 정작 새롭게 만든 시스템이 완벽하게 릴리즈 되어 유지되는 케이스는 본 적 없다. 한 번 만든 시스템이 완벽하다면 개발자라는 직업은 사라지지 않았을까? 
그럼에도 절대 양보할 수 없는 부분들이 있다. 
그동안 프로젝트를 셋업, 진행하며 마주한 고민들, 생각하고 결정한 것들을 정리한다. 그 안에는 대부분 지키지 못하는 확고한 기준과 취향이 존재할 수 있다.
족보가 아니다. 완벽한 것은 없다. 다만 내가 잘 준비되어 있는지가 더 중요하다.
1. 테스트 케이스
개발에 있어서 '나중에'는 잘 지켜지지 않는다. 내가 지킬 수 있다면 반대로 상황이 그러지 못할 때가 있다. 논란의 여지 따위는 없다. 반드시 작성한다. 
2. 요청/응답 클래스 모델화, 분리
http 통신 시 요청, 응답 클래스는 분리하는 게 좋다. 나쁜 예로 JPA Entity를 응답 클래스로서 활용하면 비즈니스 로직이 서비스 도메인에 침범할 수 있다. 이는 조금만 프로젝트가 커져도 비즈니스와 Client 응답 사이에 의존 관계가 생겨 분리하기가 쉽지 않으며 사이드 이펙을 확인하기도 어렵다.
메시지의 요청, 응답 값이 명시적이지 못하면 개발자는 모든 로직을 파악하고 어떤 값이 담길 수 있는지 알아내야 한다.
이와 관련하여 최악의 케이스를 경험한 적이 있다. 서버에서 받아온 값을 Map에 담아 몇 가지 가공한 뒤 바로 Client로 응답하는 코드를 수정해야 했다.
케이스를 모르니 테스트를 만들 수 없었을뿐더러 사이드 이펙 또한 전혀 알 수 없었다. 결국 운영서버에서 Tcp dump로 송수신되는 데이터 셋을 뽑아내야 했다.
이후에 응답 클래스를 만들고 Class로 모두 분리시켰다.
단순 코딩만 10초면 할 일이 1시간 넘어 끝났다. 
3. 데이터베이스 분리
(정말 서비스가 별개이지 않는 한) 서비스를 여러 개로 쪼개 각기 다른 데이터베이스를 보는 서비스로 만들지 않는다.
프로젝트 관리 / 배포 / 이슈 추적 / 아키텍처 / 인프라 / 커뮤니케이션 등의 비용이 증가한다.
가능한 모노리틱스 형태로 만들고 패키지 분리를 잘해보도록 노력한다.
4. 리소스 값 설정 분리.
코드 안에 문자열("")이 들어가면 생각해보자. 이걸 설정 파일로 분리할 수 없을지.. 하다 못해 상수로 만드는 건 어떨지.
대부분의 웹 프레임워크는 설정 기능을 지원하기 때문에 가능하면 이를 이용하도록 한다.
외부와 통신하기 위한 API 주소, timeout, 인증 키 등이 하드코딩되어있다면 여러 곳에서 복사되어있을 수 있다. 한 번 수정하려고 하면 모두 찾아내어 replace 하는 일이 없도록 한다. 
5. 환경 분리
local, dev, production에 대한 분리는 확실하게 하자. 가능하다면 staging까지 잘 분리한다. 처음부터 잘 분리하지 않으면 나중에 가서 굉장히 곤란해진다. 로컬, 개발, 운영에 대한 경계가 모호해지며 테스트하기 힘들어진다. 나의 테스트가 누군가의 테스트를 침범하는 경우도 생긴다. 가능하면 각 환경에 맞는 property를 이용하도록 한다. 로컬에서 베타, 베타에서 운영 데이터를 조작하는 경우가 없도록 한다.
처음에는 별거 아닌 것처럼 느껴져도 나중에 가서 프로덕트 릴리즈 커브를 급격하게 증가시키는 요인이다. 
6. 웹 프레임워크 선택
경량 프레임워크를 선호하는 경우를 많이 봤다. 처음 시작은 나쁘지 않을 수 있다. 하지만 이는 큰 함정이 숨어있어 조심해야 한다. 과연 현재 진행하는 프로젝트가 경량에서 중량급으로 넘어가는 걸 대비하고 변경할 수 있는 개발자/팀이 얼마나 있을까? 개발자 기술력에 대한 의심만이 아니다. 그때는 회사에 대한 설득력도 있어야 한다. 당신 회사 대표에게 "지금 당장 비즈니스를 멈추고 웹 프레임워크를 변경해야 합니다."고 설득할 수 있을까?
그렇기 때문에 내가 본모습은 이미 중량(?) 프레임워크/언어에서 제공되거나 과거에 했던 고민들을 재차 검토해가며 library 폴더에 자신만의 코드를 끼워 넣는 모습이었다.
'경량'이 주는 의미가 무엇인지 잘 생각해보자. 빠르게 코드를 변경, 반영하고 애플리케이션을 구동하고, 프로세스가 cpu, 메모리를 적게 차지하고.. 그런 것 인가?

모던 레거시가 되지 않기 위한 노오오력

댓글