- DB에 있는 값을 꺼내와서 사용을 해야 할 때 많이 사용되는 객체는 vo와 dto가 있다. 거의 동일한 역할로 사용이 되고 있지만 미세한 차이가 있기 때문에 그 부분에 대해서 알아보고 ORM기술 중 하나인 JPA를 사용할 때 접할 수 있는 Entity까지 살펴보자.
[ Value Object ]
- 먼저 vo라고 많이 불리는 Value Object에 대해 알아보도록 하자.
데이터 그 자체로 의미있는 것을 담고 있는 객체
Read-Only의 속성을 가져야 함
한 개 또는 그 이상의 속성들을 묶어서 특정 값을 나타내는 객체를 의미
객체 내부의 값이 동일한지 확인을 위해 Equals & Hash code 메서드를 재정의해함
[ Data Transfer Object ]
- vo와 비슷한 개념으로 많이 사용되고 dto라고 불리는 Data Transfer Object에 대해 알아보자.
전송되는 데이터의 컨테이너를 의미
Layer 간의 통신 용도로 오가는 객체를 말하기도 함
비즈니스 로직이 dto내부에 존재하기도 함
데이터의 변경이 가능함
[ Entity ]
- JPA를 많이 사용해봤다면 DB와 데이터 통신을 위해 많이 사용했을 Entity에 대해서 알아보자.
JPA가 관리하는 클래스
JPA를 사용해서 DB 테이블과 매핑 시 반드시 @Entity 어노테이션을 붙여야 함
기본 생성자가 필수로 필요함
Setter를 사용하기 보다는 바꿔줄 필드에 대해 변경 메서드를 정의해서 사용함
VO와 DTO의 속성을 거의 비슷하게 가지고있는 객체라고 생각이 된다.
(본 포스팅은 JPA관련 포스팅이 아니므로 이쯤에서 마무리하겠다.)
[ 개인적인 생각 ]
VO와 DTO를 상황과 의미에 맞게 잘 사용을 해주는 것이 좋다고 생각한다. 해당 객체의 역할을 생각하지 않고 VO로 통일을 해서 쓴다거나 DTO로 통일을 해서 사용을 해도 프로그래밍을 하는데 전혀 지장이 없지만 의미론적인 부분에서 이질감이 생기고 클린 코딩에서 멀어진다고 생각이 된다.
과거 폭포수 모델(Waterfall Model)을 많이 사용했다고 한다. 폭포수 방법론은 다음 단계를 진행하기 전 현재 단계를 완료해야 다음 단계로 넘어갈 수 있는 방법론입니다. 폭포수 모델의 장점은 복잡성이 낮고 진행 과정을 세분화 하여 관리가 용이하며 과거부터 계속 사용해 오던 방법이기에 사례가 풍부하며 전체 과정에 대한 이해가 용이합니다.
하지만 소프트웨어가 커지면서 요구사항의 구체화가 어려워졌고, 초반에 예상치 못한 큰 오류의 발생 시에 전체 설계를 뒤엎어야 된다는 단점도 있습니다.
요즘 프로그램을 살펴보면 단순하게 A = B와 같은 방식으로 작동하지 않습니다. 프로그램 안에 수없이 많은 로직이 존재하며 처음 기획(계획)과 중간 구현 혹은 테스트 단계에서 치명적으로 작동할 수 있는 부분이 생길 수도 있습니다. 그렇기 때문에 폭포수 방법론도 과거와 현재는 다른 양상을 띄고 있는 부분도 있습니다.
첨부 1
첨부 1을 보면 알 수 있는 과거에는 개발을 진행한 후 테스트를 하며 디버깅을 하는 등 하나로 이어지는 폭포수의 모양을 했다고 봐도 무방합니다. 하지만 최근 폭포수 모델의 경우 간략하게 본다면 에자일과 거의 비슷한 양상을 띄고 있는 것을 확인할 수 있습니다.
개발을 모두 끝낸 후 테스팅을 하며 디버깅을 할 경우 큰 문제에 직면했을 때 해결 방안을 찾는데 오랜 시간이 걸릴 수 있습니다. 하지만 특정 프로세스 개발을 완료하고 테스트를 진행하면서 오류의 오차범위를 줄이고 계획에 맞게끔 수정을 하면서 갈 수 있다는 점이 장점입니다. 그렇다면 저렇게 현대화된 폭포수를 쓰면 되지 않냐라고 하실 수도 있는데 이에 대해 알아보기 전에 에자일에 대해 짚고 넘어가도록 하겠습니다.
[ 에자일 방법론 ]
에자일 방법론은 에자일의 가치에 대해 먼저 알아볼 필요가 있습니다.
개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
작동하는 소프트웨어가 포괄적인 문서보다 우선
고객과의 협업이 계약 협상보다 우선
변화에 대응하는 것이 계획을 따르는 것보다 우선
위의 4가지가 에자일을 통해 개발을 하면서 어디에 가치를 두어야 할지 잡아주는 지표와 같습니다.
에자일은 보다 효율적인 개발과 협업을 위해서도 사용을 하지만 소프트웨어를 잘 만들고 클라이언트의 요구를 맞추며 변화를 두려워하지 않고 대응하며 개인 간의 상호작용을 중요하게 여기고 있습니다.
에자일 프로세스라는 것이 워터풀과 같이 정해져 있는 프로세스를 지칭하는 것이 아닌 Agile (기민한, 좋은 것을 빠르고 낭비 없게 만드는 것) 말 그대로를 의미합니다. 하지만 어느 정도의 중요한 프로세스가 있습니다.
스프린트
일반적으로 1~2주 정도의 단위로 기간을 잡으며 정해진 기간 동안 정해진 만큼의 프로젝트를 완료하는 것을 반복하여 프로젝트를 마무리하도록 하는 방법입니다.
워터풀의 경우 프로젝트의 데드라인을 제일 중요시 여기지만 에자일에서는 에자일 속도. 즉, 스프린트가 얼마나 빠르게 잘 반복되고 있냐를 중요하게 여깁니다.
스크럼
럭비의 스크럼에서 나온 단어로 잠시 럭비 룰을 보고 넘어가자면 경기중 반칙이 생기면 경기를 멈추고 반칙 장소에서 다시 경기를 재개합니다. 그때 공을 뺏기 위해 여러 명의 선수들이 뭉쳐있는 모습을 보고 협력하는 팀원의 모습과 비슷하다고 하여 단어를 스크럼으로 정했다고 합니다.
스크럼의 경우 이미 충분한 경험이 있는 전문가 그룹의 경우 적절합니다. 각 스토리의 포인트를 예측하는데 이견이 많이 발생하지 않을 것이기 때문인데 그렇지 않고 기술개발을 한다면 칸반 보드의 사용이 더욱 효율적일 것입니다.
마지막으로 장점은
점진적으로 테스트할 수 있어서 버그를 더 빠르게 발견할 수 있다.
수정과 변경에 유연하다.
프로젝트를 시작할 때 계획에 버리는 시간을 줄일 수 있다.
서비스가 더 빨리 출시된다.
[ 폭포수 VS 에자일 ]
사실 회사에서 실무를 한다면 개발 이외에도 여러 변수가 생기기 마련입니다. 그런 변수들 때문에 에자일을 도입하는 것이 어려울 수도 있다고 생각합니다. 하지만 에자일의 4가지 가치를 생각하고 TDD와 같은 방법론을 조금씩 도입해가며 전체적인 프로세스를 에자일로 바꿔나가는 것이 좋은 소프트웨어를 더욱 빠른 시간에 정교하게 만들어 나갈 수 있다고 생각합니다.
단순하게 혼자 하는 개발에서는 어떤 방법을 써도 개인의 실력만 좋다면 좋은 결과물이 빠르게 나오겠지만 협업의 경우 항상 모든 팀원에 완벽할 수는 없기 때문에 여러 방법론이 나온다고 생각합니다. 결국 저희 개발자들은 좋은 소프트웨어를 빠른 시간에 정교하게 만들어내는 것이 중요하기 때문에 각각의 상황에 맞게 방법론을 선택하는 것이 좋지 않을까라고 생각합니다.
클라이언트로부터 http 요청을 받아들이고 html문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램
정적 콘텐츠를 제공하는 서버
정적 컨텐츠 : 단순 html, css, javascript, 이미지 파일 등 즉시 응답 가능한 콘텐츠
동적 콘텐츠 요청을 받으면 was에게 요청을 넘기고 결과를 받아주는 역할을 함
대표적인 웹 서버 : apache
[ WAS (Web Application Server)]
주로 동적 콘텐츠를 다루며 DB 서버와 같이 동작
웹 서버로부터 받은 요청(동적 컨텐츠 요청)을 처리
동적 컨텐츠 : 자주 변경되거나 사용자마다 다른 결과를 보여줘야 할 때( ex > 은행 잔고, 마이 페이지 등...)
웹 서버와 웹 컨테이너가 합쳐진 형태
DB 조회, 다양한 로직 처리가 필요한 동적 콘텐츠 제공
JSP, Sevlet구동 환경 제공
대표적인 WAS : tomcat
[ 둘 중 하나만 사용해도 상관없을까? ]
위의 설명을 보면 was만 사용을 해도 상관없지 않을까라고 생각할 수도 있다. 하지만 was의 주요 역할은 DB에서 가지고 온 데이터를 어떠한 로직 처리를 통해 사용자에게 보여주는 역할을 하는데 정적 콘텐츠까지 was가 담당하게 되면 서버의 부하가 커지기 때문에 기능을 분리시켜 서버의 부하를 줄여야 한다. 또한 was가 모든 기능을 수행하면 처리 시간이 효율적이지 못하다는 단점이 생긴다.
[ 최근 동향? ]
서버의 부하를 줄이기 위해 사용되는 방법 중 하나는 요즘 많이 사용되는 vue.js / react.js가 있다. 클라이언트의 컴퓨터 사양이 높아짐에 따라 서버의 부하를 줄이고 클라이언트가 조금 더 많은 기능을 수행하는 것이다. 하지만 이 또한 단점이 있다. 바로 javascript의 파일 용량이 커지면서 처음 페이지에 들어갈 때 페이지 렌더에 시간이 오래 걸릴 수 있다는 것이다. 여러 가지 처리를 할 수도 있겠지만 여기서는 자세히 다루지 않겠다.
