본문 바로가기

개발/Java || Spring9

객체 지향 설계 원칙 (SOLID) - SRP / OCP 단일 책임 원칙 (SRP / Single Responsibility Principle)하나의 클래스는 하나의 책임만 가져야 합니다. 즉, 하나의 클래스는 하나의 기능에 집중해야한다는 것입니다.그 예로, 맥가이버 칼을 들 수 있습니다.이 칼은 실생활에서는 휴대성과 활용성이 뛰어납니다.하지만, 소프트웨어 관점에서는 하나의 객체가 많은 기능을 담당합니다.  (칼, 맥주/와인 오프너 ...)여러 기능을 책임지고 있기 때문에 기능을 수정하면 같은 객체 내의 다른 기능에게 이슈가 전파될 가능성이 있습니다.즉, SRP는 이 기능의 변경이 이루어질 때 연쇄(파급) 효과가 적어야 합니다. 개방-폐쇄 원칙 (OCP / Open-Closed Principle)기존의 코드를 수정하지 않고 기능을 추가할 수 있도록 설계해야 합.. 2024. 5. 30.
큰일났다. 톰캣 로그에서 갑자기 한글이 보이지 않는다. 간단한? 개요 우리 회사의 핵심 상품(도메인)은 웹메일이다. 그중에서도 내가 속한 팀은 클라우드 인프라 기반의 웹메일 서비스 SaaS 운영 및 개발이다. (기타 모든 잡일...) 내가 입사 전 막연히 생각했던 것보다 웹메일 서비스는 파일의 I/O가 너무 잦고 크고 많다. 단순 EML을 열람하는 것부터 일반/대용량 첨부파일 다운로드, 드라이브에 저장되는 파일 UL/DL, 기타 등등 KB부터 시작해서 GB까지! (종종 어떤 고객들은 100GB 단위도 올리게 해달라 한다.) 그러다 보니, 서비스 규모가 커지니 슬슬 파일 다운로드를 할 때 서비스가 느려져서 VOC가 자주 인입됐다. 문제의 시발점 🫤 "아 이제 안 되겠다. 부하가 있는 서비스는 별도 서버로 옮깁시다." "근데 지금 CentOS7이 EOS 되기 직.. 2023. 10. 19.
여러분의 getter는 안녕하신가요? 저는 공공 클라우드 환경에서의 웹서비스를 개발 및 운영하고 있습니다. 그러다 보니 보안인증(CSAP) 유지를 위해 KISA에게 매년 인프라와 소스코드를 검사받습니다. (어릴 적 숙제 검사 느낌) 그중 소스 취약점에 대한 이야기인데요, 보안인증 중 처음 맡아본 소스 취약점 항목에서 생각지도 못했던 getter에서 문제가 발생했습니다. 바로 우리가 잘 알고 있는 객체지향 프로그래밍(OOP)의 특징 중 하나인 캡슐화에 대한 내용입니다. 취약점의 이름은 [Public 메서드부터 반환된 Private 배열]. 즉, Private으로 선언된 변수에 대해 Public으로 선언된 getter를 통해 배열에 대한 참조를 변경할 수 있다는 취약점입니다. 왜 우리는 캡슐화를 잘 지켰다고 생각했을까? private으로 선언된.. 2023. 7. 2.
Entity, DTO 그리고 VO Entity와 DTO, 그리고 VO는 뭐가 다른 걸까? 학과에서 처음 개발 언어를 학습할 때부터 막연히 사용해 오던 VO(Value Object). 여태까지는 그냥저냥 사용해 왔었다. 회사에서도 객체는 vo로 퉁치고, DTO, Entity는 딱히 사용하는 걸 못 봤기 때문이다. 하지만, 최근 Spring Boot에 대해 학습을 하다 보니 항상 마주하던 녀석들이었다. 그동안 나는 왜 이 녀석들을 제대로 학습하지 않았을까? 1. Entity Entity란, 데이터베이스의 특정 테이블과 1:1로 일치하는 클래스이다. Entity는 테이블에 존재하는 컬럼만을 속성으로 가져야 한다. 상속을 받거나, 구현체가 돼서는 안 된다. 또한, 절대 컨트롤러의 Request/Response에서 사용해선 안된다. - Sprin.. 2023. 3. 15.
03. 멀티 모듈 프로젝트 구성하기 왜 멀티 모듈로 구성할까? 일반적으로 하나의 웹사이트는 여러 가지 기능이 있다. 웬만한 웹사이트를 예시로 들어도, 아래와 같은 항목은 기본적으로 지원한다. 사용자 생성/삭제/수정 게시판 생성/삭제/수정 관리자 관리 이 모든 기능들을 하나의 프로젝트에서 관리한다면 생각만 해도 복잡할 것이다. 기능이 적을 땐 물론 간편하고 쉽게 쉽게 개발할 수 있다. 하지만 서비스의 규모가 커졌을 땐? 뒤늦게 아차! 싶더라도 기존 방식으로 개발할 수밖에 없다. 왜냐고? 당장 서비스의 규모가 급속도로 커지는데 저것들을 리팩토링 하기엔 전혀 기회비용이 맞지 않는다. 하지만 이를 하나의 패키지에서 모두 관리하게 되면 굉장히 복잡할 것이다. 그렇다고 모듈마다 하나의 단일 프로젝트로 따로 만든다면 그것도 리소스가 불필요하게 소모된다.. 2023. 3. 12.
02. 프로젝트를 깃허브에 연동하기 앞서 만든 스프링부트 프로젝트를 깃허브와 연동합니다. 깃을 연동하는 이유는 물론 버전관리를 통한 소스코드 관리 용이성을 위함입니다. 1. 깃허브 레파지토리 생성 먼저, 깃허브 내 Public Repository를 생성해줍니다. 딱히 상업용 목적이 없기 때문에 Private Repository를 생성할 이유가 없습니다. 2. 프로젝트 연동 Github Bash를 통한 CLI 연동을 수행합니다. 2-1. 프로젝트 디렉토리로 이동 초보자도 알기 쉽게 windows 명령어로 예시를 작성하겠습니다. 2-2. 깃허브 사용자 설정 추가 앞으로 사용해야할 계정의 정보를 입력해줍니다. 2-3. 깃허브 초기화 디렉토리 내에 .git 파일을 생성해줍니다. 2-4. 깃허브 레파지토리 연동 git remote add 명령어를 .. 2023. 3. 12.