Search

Robinjoon’s Develop Blog

개발공부, 프로젝트한거 정리하는 블로그
포트폴리오(20241026)
Search
블로그 게시글

감사 로그란?

시스템 상에서 누가, 무엇을, 언제, 어디서, 어떻게 했는지 남긴 기록을 감사 로그라 한다. 쇼핑몰을 운영한다고 생각해보자. 여러명의 쇼핑몰 운영자가 상품을 추가하거나 가격이나 재고 등을 수정할 수 있을 것이다. 이때, 누군가 어떤 상품의 가격을 1원으로 수정했다고 하자. 이건 분명히 쇼핑몰에 엄청난 손해를 가지고 오는 행위다. 그런데, 그걸 어떤 직원이 했는지 알 수 없다면? 정말 난감할 것이다. 또, 쇼핑몰에서 계좌이체, 카드결제, 토스 페이, 카카오 페이, 네이버 페이를 지원한다고 하자. 이런 결제 연동 시스템은 쇼핑몰 입장에선 외부 시스템을 사용하는 것이기 때문에 비용을 내야 한다. 이때, 네이버 페이의 그런데, 실제로는 전체 고객 중 1%만 네이버 페이로 결제하는데 연동 비용이 가장 크다면? 당연히 네이버 페이 연동을 굳이 할 필요가 없을 것이다.
앞서 말한 사례들은 모두 감사 로그를 활용하는 사례들이다. 이런 사례들을 분류하면 크게 4가지 정도로 분류할 수 있다.
•
보안 및 규제 준수: 누가 언제 로그인했는지, 중요한 데이터를 언제 수정했는지 등의 기록을 통해 불법적인 접근이나 비정상적인 활동을 감지하고, GDPR, HIPAA 등 각종 규제 요건을 충족하는 데 필수적입니다. 문제가 발생했을 때 책임 소재를 파악하는 데 결정적인 증거가 됩니다.
•
문제 진단 및 추적: 시스템 오류나 비정상적인 동작이 발생했을 때, 감사 로그를 통해 어떤 순서로 이벤트가 발생했는지를 파악하여 문제의 원인을 신속하게 진단하고 해결할 수 있습니다.
•
운영 모니터링: 시스템의 주요 기능이 어떻게 사용되고 있는지, 특정 기능의 사용 빈도 등을 파적하여 서비스 개선이나 운영 전략 수립에 활용할 수 있습니다.
•
비즈니스 프로세스 검증: 특정 비즈니스 프로세스가 의도한 대로 수행되었는지 확인하고, 누락되거나 잘못된 부분이 없는지 검증하는 데 사용될 수 있습니다.
이렇기 때문에 감사 로그를 남기는 행위는 대단히 중요하다.

감사 로그와 비즈니스 로직

감사 로그는 사실상 시스템의 거의 모든 기능들에 추가적으로 붙어야 한다. 즉, 여러 기능들을 적절한 기준으로 분리하여 코드를 작성하는 일반적인 프로그래밍 방식에서, 각 기능마다 이를 따로 통합해 작성하는 것은 문제가 있다.

횡단 관심사

감사 로그 처럼 시스템 전반에 걸쳐 영향을 주고 사용되는 것을 횡단 관심사를 가진다고 표현한다.

AOP

Java + Spring 진영에서의 감사 로그

감사 로그를 남겨보자.
2025/05/25
키워드 정리중

Exposed란

Exposed - 코틀린 SQL 프레임워크

분산 트랜잭션

2PC 패턴

준비(prepare)

분산 트랜잭션에 참여하는 각 참여자(멤버 트랜잭션)에게 커밋할 준비가 되었는지 확인하는 단계다. 이 시점에 멤버 트랜잭션이 관여하는 행이나 테이블에 락이 걸린다.
각 멤버 트랜잭션은 커밋할 수 없는 상태인 경우 커밋할 수 없다는 응답(abort)을 코디네이터에게 응답하고, 커밋이 가능한 경우 가능하다는 응답(prepared)을 한다.
중요한 점은 멤버 트랜잭션의 커밋 가능 여부를 응답하는 것이지, 이 시점에 커밋이나 롤백이 진행되지 않는다는 것이다.

커밋(commit)

코디네이터가 모든 참여자에게 응답을 받았다면, 그 결과에 따라 커밋이나 롤백을 결정한다. 멤버 트랜잭션 중 하나라도 abort 응답을 했다면 롤백을 진행한다.
각 멤버 트랜잭션이 동시에 커밋이나 롤백이 되는 것이 아니라 시간 차이가 존재하게 된다. 그리고, 각 멤버 트랜잭션은 그 결과가 결정될 때 까지 락을 보유하고 있다.
한번 분산 트랜잭션의 커밋 여부가 결정된다면, 이는 그 어떤 경우에도 번복되지 않는다. 만약, 각 노드가 응답이 없다면 응답 할 때 까지 재요청을 무한히 수행한다.

단점

1.
각 멤버 트랜잭션이 오랫동안 락을 보유한다. ⇒ 지연 시간이 증가할 수 있다.
2.
NoSQL 등은 2PC 패턴을 지원하지 않는다.
분산 트랜잭션 - 2PC 패턴, Saga 패턴
2024/11/18
CS
면접질문
네트워크
작성 완료
면접 진행 과정에서 코틀린에 대해 아는 것이 있냐는 질문을 받았다. 코틀린은 전에 다른 기업 사전과제가 코틀린으로 작성해야 했기 때문에 문법을 살짝 공부한 적 있었다. 그 과정에서 느낀 현대적인 언어인 코틀린이 주는 편안함이 있었다고 말했다. 그런데 그 과정에서 코틀린과 자바를 함께 사용하는 환경에서 롬복을 사용하는데 문제가 있다는 글을 봤다는 이야기를 했다. 그리고 그 이유를 물어보셨다. 모르겠다고 하니 자바 컴파일 과정을 살펴보면 이유를 알 수 있을것이라 하셨다. 그래서 이 글을 쓴다.

자바 컴파일 과정과 롬복

자바 컴파일 과정을 한발 더 깊게 들어가면 다음과 같이 설명할 수 있다.

AST(Abstract Syntax Tree, 추상 구문 트리)

컴파일러는 본격적인 컴파일 과정 전에 소스 코드에 문법적으로, 의미적으로 문제가 없는지 확인해야 한다. 그리고 이를 위해 소스 코드를 분해해 트리 형태로 만든다. 이를 AST(Abstract Syntax Tree, 추상 구문 트리)라고 부른다. 왜 이런 자료구조를 만드는지는 컴파일러를 다루는 전문 서적이나 강의를 찾아보는 것이 좋을 듯 하다.
아무튼 핵심은 코드를 컴파일하는 과정에서 AST를 만들고 이를 활용해 실제 실행 가능한 명령어 형태로 바꾸는 것이다. 따라서, AST를 조작한다면 컴파일 과정에서 소스코드에는 없는 명령어를 추가하도록 유도할 수 있다.

어노테이션 프로세서와 롬복

자바에서 어노테이션을 컴파일 타임에 인식해 새로운 파일을 만들 수 있게 하는 공식 API다. javax.annotation.processing 패키지를 통해 제공되고, Processor 인터페이스를 구현하면 되나AbstractProcessor 추상 클래스를 상속하여 구현하는 것이 권장된다. 이 API를 통해 여러가지를 할 수 있다. Java 소스 코드를 생성하도록 할 수 있고, 필요하다면 다른 형태의 파일이 생성되게 할 수 있다.
그럼에도 불구하고, Lombok은 Java 컴파일러 내부에서 사용하는 API를 사용해 이런 제한을 넘어서 AST를 수정하는 방식으로 동작한다.

코틀린과 자바를 같이 쓸 때 컴파일 과정

코틀린과 자바를 같이 사용하는 환경에선 컴파일 과정이 조금 복잡해진다.
왜 코틀린과 자바를 같이 쓸 때 롬복이 문제가 되나?
2024/11/16
면접질문
Java
Kotlin
CS
작성 완료
얼마전 어떤 기업의 면접에서 이들의 차이를 질문받았다. 제대로 대답하지 못한 것 같아서 다시 정리해보았다.
블로킹과 논블로킹, 동기와 비동기 개념은 공통적으로 한 주체가 다른 주체에게 작업의 실행을 넘긴 상황을 구분하는 개념이다.

블로킹과 논블로킹

블로킹은 다른 주체가 작업을 끝낼 때까지 작업을 넘긴 주체가 다른 작업을 진행할 수 없는 것을 말한다.
반대로 논블로킹은 작업을 넘긴 주체가 다른 작업을 진행할 수 있는 것을 말한다.
즉, 블로킹과 논블로킹은 작업을 넘긴 주체가 넘긴 작업 말고 다른 작업을 계속 할 수 있는지 여부로 구분된다.
논블로킹의 경우에도 다른 주체에게 작업을 넘기는 순간에는 다른 작업을 할 수 없다. 하지만 보통 그 시간이 매우 짧아 작업이 끊기지 않은 것과 구분하는 것이 무의미하다.

동기와 비동기

동기는 넘긴 작업의 결과를 기다리는 것을 말하고 비동기는 넘긴 작업의 결과를 기다리지 않는 것을 말한다.
작업을 넘긴 주체가 결과를 기다리는 동안 다른 작업을 하는지 여부는 동기 비동기를 구분하는데 영향을 주지 않는다. 따라서 아래 두 도식은 모두 동기다.
동기 + 블로킹(좌), 동기 + 논블로킹(우)
비동기는 넘긴 작업의 결과를 특별히 기다리지 않는다. 따라서 비동기 작업의 결과를 처리하는 콜백 함수를 미리 지정하는 방식으로 후속 처리를 진행한다. 예를 들어 Java 에서는 CompletableFuture 를 이용해 비동기로 작업을 처리할 수 있다.
블로킹 논블로킹 동기 비동기
2024/11/15
면접질문
CS
작성 완료

성능 테스트

성능이란

도서 실무로 배우는 시스템 성능 최적화에선 성능을 다음과 같이 정의한다.
고객의 특정 업무를 대상으로 운영환경하에서 고객이 수긍할 수 있는 응답시간 내에 처리할 수 있는 거래량
동일한 도서에서 다음과 같은 구절도 나온다.
응답시간은 사용자의 특성과 환경에 따라 요구하는 수준이 다르므로 동일한 응답 시간에 대해 고객마다 만족도는 다르게 나타난다. 이는 모든 시스템과 사용자에게 일률적으로 적용할 수 있는 응답시간의 기준은 없다는 것을 의미한다.
또 다른 도서 전문가가 알려주는 웹 퍼포먼스 튜닝에선 부하 테스트의 계획 단계에서 제시한 개요에는 시나리오가 포함된다. 시나리오의 내용은 다음과 같다.
어떤 부하를 가할지 결정 (어떤 동작을 하는 사용자를 몇 %로 가정하는가) 여러 시나리오를 준비하거나 동시에 병렬로 진행 예 : 로그인 → 달력 표시 → 예약 범위 선택 → 확인 화면 → 예약 실행이라는 동작을 하는 사용자 중 다시 한 번 실행하는 사용자가 5%
위 두 내용을 종합했을 때 서비스 개발자가 테스트해야 할 성능은 서비스 사용자가 서비스를 제대로 사용하기 위해 필요한 응답시간을 만족하면서 처리할 수 있는 거래량이다.

성능의 평가

도서 실무로 배우는 시스템 성능 최적화에선 TPS의 T에 대해 다음과 같이 언급한다.
TPS(Trsansaction Per Second)의 T를 고객의 업무 처리 건수가 되는 것이 고객과의 의사소통을 위해서나 업무 시스템을 평가하는 데 적합하다. 그러나, 시스템을 설계하고 분석하는 엔지니어 입장에서는 서버가 인식하는 트랜잭션 또한 시스템을 이해하고 개선 방향을 수립하는데 중요한 의미를 가진다.
요청 사용자 수가 증가하면 서버가 처리 해야할 요청이 많아지므로 응답시간이 점점 늘어난다. 하지만, 시스템 자원의 여유가 많다면 응답시간의 증가 폭 보다 처리하는 요청 수 증가 폭이 더 커서 TPS가 점점 늘어난다. 그러다가 시스템의 CPU의 약 70%정도를 사용하는 시점에서 시스템의 자원이 부분적으로 부족해 TPS는 일정 수치 내외를 유지한다. 최종적으로 CPU의 약 90%정도를 사용하는 지점부터는 시스템의 자원이 부족해 TPS가 떨어지게 된다.
TPS 증가가 멈추는 지점을 임계점이라 한다. 일반적으로 임계점에서의 동시 요청자 수를 늘리는 것을 목표로 하지만, 서비스의 특성에 따라 TPS가 일정하게 유지되는 구간을 늘리는 것을 목표로 하기도 한다.
성능 테스트
2024/10/06
팀 프로젝트
프로그래밍 일반
운영
작성 완료

무중단 배포 환경에서 신규 버전의 배포

배포 환경 가정

1.
10대의 WAS 서버가 있다. 한번의 배포란, 특정 빌드 파일을 10대의 서버에 순차적으로 새 버전을 실행시키는 것을 말한다.
2.
데이터베이스는 하나의 Source DB와 하나의 Replication DB로 이중화 되어있다.
3.
데이터베이스의 스키마 변경은 미리 작업을 해두었다. 즉, 데이터베이스는 언제든 구버전의 기능과 신버전의 기능을 위해 준비되어있다.
4.
배포는 각 WAS에 순차적으로 진행되는 Rolling 방식이다.
5.
배포 도중 언제라도 사용자는 서비스를 사용할 수 있어야 한다.
6.
신규 버전은 구버전에서 제공하지 않던 기능을 제공하는 것이 아니라 내부 구현이 변경된 것이라 프론트엔드 레벨의 변경은 없다.

첫번째 생각

기존 버전에서 생성한 데이터가 데이터베이스에 있을테니, 신규 버전의 쓰기와 읽기 기능, 기존 버전의 읽기 기능이 포함된 중간 버전을 먼저 배포해야 한다. 그리고 모든 서버에 중간 버전이 배포되면 기존 버전의 읽기 기능이 삭제된 신규 버전을 배포하면 된다.

문제점

1.
5번째 서버에 빌드 파일이 배포되는 시점에, 1 ~ 4번째 서버에는 중간 버전이 배포가 되어있다. 따라서, 그 시점에 사용자의 쓰기 요청이 1 ~ 4번째 서버에서 처리된다면 데이터베이스에는 신규 버전의 형태로 데이터가 쓰인다. 그런데, 동일한 사용자의 조회 요청이 6 ~ 10번째 서버에서 처리된다면 이 서버들에는 아직 신규 버전의 읽기가 불가능하므로 적절한 응답을 보내줄 수 없다.
신규 버전을 배포하기 위해 몇번의 배포가 필요할까?
2024/09/20
면접질문
CS
운영
작성 완료

Redis 보다 HTTP 최적화가 먼저다

더 높은 처리량을 보여주기 위해 별도의 덩치가 큰 기술을 도입하는 경우가 있다. 이는 아마도 덩치 큰 기업들에서 이런 기술을 도입해 자신들이 처한 문제를 해결하는 것을 보았기 때문이다. 그 대표적인 것으로 Redis를 뽑았지만 Redis 말고도 뭐 많다. 하지만, 이런 기술들을 도입하기 전에 기초적인 HTTP 레벨에서의 성능 향상을 꾀하지 않는다면 순서가 잘못된 것이다. 그런 의미에서 이번에 HTTP 레벨에서 성능을 향상시키기 위한 기술들이 무엇이 있는지 알아보았다.

HTTP 성능 최적화

HTTP 압축

Accept-Encoding 헤더를 통해 클라이언트가 수용할 수 있는 압축 알고리즘을 나열한다. 그리고 서버에서 이 알고리즘 중 하나를 선택해서 적용하고 Content-Encoding 헤더를 통해 클라이언트에 알려준다.
대표적인 알고리즘으로 gzip 알고리즘이 있다. 물론 이 알고리즘을 직접 구현할 필요는 없고 서버 프로그램(톰캣, nginx 등)에서 지원하며 이를 설정하면 된다.
Spring Boot를 사용한다면 공식 문서에 나와있는 다음 설정을 통해 간편하게 적용할 수 있다.

Vary 헤더

압축과 직접적으로 관련있는 헤더는 아니지만, 압축을 하게 되면 반드시 설정해야 하는 헤더라 설명을 넣어봤다. 이 헤더는 요청의 URL 이나 메서드가 아닌 다른 헤더가 응답에 영향을 주었다면 이를 명시하는 헤더다. 이는 캐시의 키를 생성할 때 사용된다. 즉, 압축을 하므로 이 헤더에 Accept-Encoding 을 값으로 설정해야 한다.

리소스 최적화

HTTP 성능 높이는 방법들
2024/09/06
CS
네트워크
우테코
작성 완료

자바의 Thread

자바에서 스레드 기술은 태초의 Thread 클래스에서 부터 시작했다. 이후 이를 한 층 더 추상화하고, 스레드 풀을 쉽게 만들게 해주는 API가 추가되고, 스레드를 외부에서 종료시킬 수 있는 API가 추가되었다. 그리고 자바 스레드 기술의 최신 버전이 Virtual Thread다. 막 어려운 개념은 아니고, Process 로 동시성을 처리하다가 버거워서 Thread가 등장한 것 처럼, Thread로 동시성을 처리하기 버거워서 Virtual Thread가 등장한 것이다. 성능 향상을 불러오는 근본적인 이유도 같다.

Platform Thread

기존의 자바 Thread 인스턴스다. 이들은 운영체제가 제공하는 스레드를 살짝 감싸서 구현된다. 또한, 생성될 때부터 종료될 때까지 운영체제가 제공하는 스레드에 종속된다. 따라서 Platform Thread개수는 자바가 동작하는 운영체제의 OS Thread 개수에 제한된다.
운영체제는 스레드에 독립적인 스택 메모리 공간을 주고 그 외에도 여러 자원을 할당한다. 따라서, Platform Thread를 사용하는 것은 자바가 동작하는 운영체제의 제한에 크게 영향을 받는다. 대신, CPU 위주의 작업이던, IO 위주의 작업 모두 적절히 수행할 수 있다.

Virtual Thread

가상 스레드 역시 Thread 클래스의 인스턴스다. 다만, Platform Thread와 다르게 운영체제 스레드에 종속되지 않는다. 물론 실행은 운영체제의 스레드 위에서 실행된다.
운영체제 스레드에 종속되지 않기 때문에 Virtual Thread가 blocking I/O 를 사용하면 그 Virtual Thread만 블로킹 될 뿐, 운영체제 스레드는 블로킹 되지 않고 다른 Virtual Thread를 실행한다. 따라서, 컨텍스트 스위칭 비용이 JVM 레벨에서만 발생한다. 이로 인해 더 높은 처리량을 가질 수 있다.
하지만, CPU 연산 위주의 작업을 할때는 Virtual Thread가 적합하지 않다. Virtual Thread는 blocking I/O 상황에서 발생하는 Context Switching 비용을 줄여 높은 처리량을 가지는 것이지, 작업 실행 속도 자체가 빨라지는 것이 아니다.

Virtual Thread의 실행

Virtual Thread의 간략한 라이프 사이클
Virtual Thread도 결국 운영체제 위에서 동작하기 때문에 운영체제의 스레드가 Virtual Thread를 실행한다. 따라서 Virtual Thread는 런타임에 동적으로 몇개의 Platform Thread에 매핑되어 작업을 수행한다. 이 mapping 되는 것을 마운트라고 부르고, 마운트된 Platform Thread를 Carrier라고 부른다.
Virtual Thread가 I/O 등 블로킹 작업을 요청하면 마운트가 해제된다. 따라서 Thread 스케줄러가 다른 Virtual Thread 를 마운트 하여 실행할 수 있다. 나중에 Virtual Thread의 블로킹 작업이 완료되면 스케줄러에 제출되고 스케줄러가 이를 마운트한다.

Virtual Thread Pinning

Java Virtual Thread
2024/08/24
Java
CS
면접질문
IT최신이슈
작성 완료

생각하게 된 계기

기본적인 레지스트리인 도커 허브에선 무료 플랜에선 프라이빗 레지스트리를 하나만 제공한다. 또 다른 서비스인 깃허브 패키지 역시 무료 플랜에선 용량과 트래픽 제한이 있다. 다른 상용 서비스들도 여럿 있지만, 프라이빗 레지스트리를 위해선 돈을 지불해야 한다. 반면, 직접 운영하는 경우 서버 임대 비용을 제외하면 별도의 비용이 발생하지 않는다. 따라서, 직접 레지스트리를 운영하는 방법에 대해 학습할 가치가 있다고 판단했다.

구축 과정

최종적으로 구현된 자체 레지스트리 웹페이지
위와 같은 레지스트리 웹페이지를 만든 과정을 소개한다.

레지스트리 컨테이너 띄우기

도커에서 공식적으로 레지스트리 라는 이미지를 제공한다. 이는 도커 레지스트리를 이미지로 만든 것으로 이를 이용해 컨테이너를 띄우면 레지스트리를 사용할 수 있다.
compose.yml

레지스트리에 https 적용하기

도커에서 레지스트리가 https 적용이 되어있지 않은 경우 거부하는 것이 기본 설정이다. 예외 설정을 할 수 있지만, 레지스트리를 따로 운영하는 이유가 보안 때문이므로 앞뒤가 맞지 않는다. 따라서 https 를 적용해야 한다고 생각했다.
레지스트리에 https를 적용하는 방법도 있다. 하지만, 추후 웹 UI 도 붙일 것이고 이 곳에도 https 를 적용해야 하는 것이 자명했다. 따라서 https 적용하는 것을 분리하여 nginx를 추가하고 리버스 프록시와 https 를 적용하는 것이 나을 것이라 판단했다. 아래는 이에 따라 변경된 compose.yml 이다.
compose.yml
도커 레지스트리 직접 운영하기
2024/08/18
Docker
보안
운영
작성 완료

Spring Data JPA 쓰니까 쿼리가 이상해졌어!

아니 이걸 왜 다 따로 불러와?

Spring Data JPA 를 이용해 사용자의 예약 목록을 조회하는 페이지에 접근했더니 다음과 같은 쿼리들이 발생했다.(스압 주의)
발생한 SQL
자신의 예약 정보를 조회하기 위해서는 그저 예약, 회원, 예약 시간, 테마 테이블을 모두 join 해서 한번에 쿼리를 작성하면 된다. 비록 쿼리가 복잡해지긴 하겠지만, 저 많은 쿼리를 다 따로 데이터베이스에 전송하면서 생기는 오버헤드보다는 아마 나을 것이다.

fetch type

JPA 에서는 @ManyToOne 과 같이 연관관계를 설정하는 어노테이션에 fetch 옵션을 제공해준다. 이 옵션은 FetchType.LAZY 와 FetchType.EAGER 중 하나로 설정할 수 있다.
LAZY 옵션은 연관 데이터가 실제로 필요한 시점에 조회해와라! 라는 옵션이고, EAGER 옵션은 연관관계를 무조건 조회해와라! 라는 옵션이다. LAZY 옵션은 연관관계의 id 값만 조회해오고, 실제로 연관 데이터가 필요할 때 이 id를 이용해 select 쿼리를 이용해 데이터를 조회한다. 반면, EAGER 옵션은 어차피 모든 연관 데이터를 조회할 것이기 때문에 처음부터 모든 데이터를 조회해온다.
이 옵션은 EntityManager.find 를 호출할 때 적용된다.

Spring Data JPA 너는 참 재밌는 친구구나!

JPA에서는 보다 객체에 가까운 형태의 언어인 JPQL 을 지원한다. JPQL은 연관관계를 이용하여 쿼리를 표현하기 때문에 SQL보다 훨씬 깔끔하고 읽기 좋다. 이를 통해 보다 쉽게 쿼리를 작성하고, JPA 의 구현체가 이 JPQL 을 적절히 번역하여 SQL 로 실행시킨다. JPQL 명령어중 fetch join 이 있는데, 이를 사용하여 쿼리를 작성하면 모든 연관 데이터가 한번에 조회된다.

Query Method

JPQL은 기존의 SQL에 비해 편리하지만 여전히 쿼리를 작성해야 한다. Spring Data JPA에서는 이를 한층 더 편하게 사용할 수 있도록 Query Method 라는 기능을 제공한다. 적절한 규칙을 지켜서 메서드 이름을 정한다면, 그 규칙에 따라 생성된 JPQL이 실행되는 구조다.

@Query

N + 1 문제의 원인과 해결방법
2024/05/27
Java
Spring
우테코
JPA
DB
작성 완료

Wait, You Want Me to Delete All My Code?

During Woowahan Tech Course Level 2, Mission 3, I encountered a requirement to modify existing code that used JdbcTemplate to utilize Spring Data JPA instead. And in the mission briefing, Coach Brown said this:
Unfortunately, you’ll need to delete your existing JdbcTemplate code!
Would You Only Be Happy if You Take It All?

How Can I Change My Code the Least?

I faced a similar dilemma back in Level 1. At that time, there was indeed an issue with my code, but I wanted to fix it with minimal changes. I remember talking to Coach Gugu back then, and Gugu said this:
The easiest solution is to just overhaul it.
I understood that it would be wise to address issues at their root, as leaving them unresolved might cause bigger problems down the line. I was stubborn, didn’t heed Gugu's advice, spent a day trying to work around it, and ended up overhauling it anyway. I wasted both time and failed to reach my goal. Now, halfway through Level 2, I stand at a similar crossroads.
Humans may repeat their mistakes, but without taking chances, there’s no growth. This time, I’m determined to achieve substantial gains with minimal changes.

Can’t I Just Add extends JpaRepository<Domain, Long>?

Initially, I thought I could simply add extends JpaRepository<Reservation, Long> and be done.
If I simply add extends JpaRepository<Reservation, Long> to the interface, it would look like this:
Let’s Easily Swap JdbcTemplate with JPA
2024/05/15
우테코
Java
Spring
작성 완료

아니 내 코드 다 지우라고?

우테코 레벨 2 3번째 미션을 수행하면서 기존의 JdbcTemplate을 사용한 코드를 Spring Data JPA를 이용하도록 수정하라는 요구사항을 만났다. 그리고 미션을 소개하는 시간에 코치 브라운이 이렇게 말했다.
아쉽지만 기존에 있던 JdbcTemplate 코드는 지우세요!
꼭 그렇게 다 가져가야만 속이 후련하십니까? ㅠㅠㅠㅠ

어떻게 하면 내 코드를 최대한 덜 바꿀까?

레벨 1때도 비슷한 고민을 했다. 그때는 지금의 코드에 어떤 문제가 있었지만, 코드를 최대한 조금 수정하고 문제를 해결하고 싶어했다. 당시에 코치 구구와 이야기 했었는데 구구는 이런식으로 말했다.
지금 엎는게 제일 쉬운 방법이에요.
나중에 지금 덮어둔 문제가 큰 문제가 될 수 있으니 미리 싹을 뽑아놓는 것이 좋다는 취지로 이해했다. 그리고 결국 구구의 말을 듣지 않고 고집부리다가 하루를 날리고 결국 엎었다. 시간도 날리고 목표도 이루지 못한 것이었다. 시간은 흘러 레벨 2의 절반이 지나간 지금, 다시 선택의 갈림길 앞에 섰다.
인간은 같은 실수를 반복한다지만, 시도를 하지 않으면 발전도 없을 것이다. 이번에는 반드시 적은 수정으로 큰 이득을 얻어보고 싶었다.

그냥 extends JpaRepository<Domain, Long> 붙이면 안되나?

처음에는 단순히 extends JpaRepository<Reservation, Long>만 붙이면 되는줄 알았다.
만약 단순히 인터페이스 뒤에 extends JpaRepository<Reservation, Long> 를 붙여준다면,
JdbcTemplate 를 JPA로 손쉽게 갈아껴보자
2024/05/15
우테코
Java
Spring
작성 완료

처음 요청을 처리하는 곳은 DispatcherServlet 이다

HTTP 요청을 택배로 비유한다면 DispatcherServlet 는 물류센터에 비유할 수 있다. “(특별한 요청을 위해)보내다”라는 의미의 Dispatch 라는 단어가 붙은 대로 DispatcherServlet은 HTTP 요청을 처리하는 담당 클래스(= 핸들러)에게 HTTP 요청을 보내는 역할을 한다. Spring MVC 는 HttpServlet 을 이용해 클라이언트의 요청을 처리해 응답한다. DispatcherServlet은 Spring이 HttpServlet 을 구현한 구현체다.

DispatcherServlet이 처리해야 하는 작업들

우리가 @Controller 혹은 @RestController 어노테이션을 이용해 만든 컨트롤러에게 HTTP 요청의 처리를 위임해야 한다. 이를 위해선 다음 작업들이 수행되어야 한다.
1.
어떤 컨트롤러 객체를 사용해야 하는지 결정
2.
어떤 메서드를 사용해야 하는지 결정
3.
메서드를 호출하기 위한 매개변수 생성
4.
메서드의 반환값을 HTTP 응답에 적절히 표현

어떤 컨트롤러 객체를 사용해야 하는지 결정 : HandlerMapping

컨트롤러의 인스턴스는 Spring이 시작되면서 복잡한 과정을 통해 생성되어 Spring 컨테이너 내부에서 관리된다.
즉, 컨트롤러 객체는 이미 존재한다.
이 많은 컨트롤러 객체 중 어떤 컨트롤러 객체를 사용해야 하는지 결정하는 것이 HandlerMapping 이다.
HandlerMapping 은 인터페이스로 Spring과 Spring Boot 내부에 여러 구현체가 있다.
Spring Web MVC 동작 구조 - 대체 내 컨트롤러를 어떻게 실행할까?
2024/05/08
Java
Spring
우테코
작성 완료

의존

어떤 요소 A가 동작하기 위해서 다른 요소 B가 필요하다면, A가 B를 의존한다.
Ladder가 동작하기 위해서는 List<Line> 이 필요하다. 즉, Laddder는 List와 Line을 의존한다.
정말 간단하게 자바에서 import 하는 모든 것을 의존한다고 보면 된다. 단, 그게 전부는 아니다.
이하의 글에서 A 를 의존을 하는 쪽, B를 의존 대상 이라 표현한다.

주입

주입의 사전적 의미는 다음과 같다.
의존성 주입

개요

sealed 키워드에 대해 이해하기 위해서는 자바에서 인터페이스와 추상 클래스, 구체 클래스를 이용한 상속 구조를 이해하고 있어야 한다. 이 포스트는 독자가 이를 이미 이해하고 있다고 가정하고 작성했다.
Java 15에 Preview 로 추가되어 Java 17에 정식 기능으로 포함된 상위 클래스(혹은 인터페이스)에서 자신을 상속(구현)하는 클래스(인터페이스)를 제한하는 기능이다.

도입 배경

인터페이스, 추상 클래스, 구체 클래스를 이용한 견고한 코드

java-ladder
woowacourse
사다리 게임 미션의 요구사항 중 사다리에 대한 제약 조건이 있다.
•
사다리 타기가 정상적으로 동작하려면 라인이 겹치지 않도록 해야 한다.
사다리가 랜덤으로 생성되는 것이 타당하지만, 랜덤은 테스트하기 어렵기 때문에 랜덤으로 결정되는 부분을 외부에서 주입할 수 있도록 하는 것이 테스트에 유리하다. 아래는 이를 위한 인터페이스다.
List.of(true) = |-----| , List.of(true,flase,true) = |-----| |-----| 이런 라인과 대응된다.
랜덤으로 Boolean을 집어넣는 구현체를 다음과 같이 작성할 수 있다.
테스트 코드에서는 랜덤이 아니라 지정할 수 있도록 코드를 구현할 것이다. 그런데, 지금 구조에서는 이런 테스트 구현체가 fixInvalidBridges 와 비슷하게 true가 연속해서 나오지 않도록 강제할 수 없다.
sealed , non-sealed
2024/03/16
Java
우테코
작성 완료
아래 글에서 타입, 클래스, 역할, 책임 등의 용어는 객체지향의 사실과 오해 라는 도서를 참고하자.

객체를 어떻게 분류할 수 있을까?

타입(혹은 클래스)가 역할이 동일한 객체를 모은 집합이라면, DTO, VO의 개념은 여러 타입에 부여된 역할이 얼마나 비슷한지에 따른 분류다.
어떤 객체가 DTO 인가? 라는 질문은 그 객체가 속한 타입이 DTO 라는 분류에 속하는가? 라는 질문을 간단히 표현한 것이다.

어떤 역할을 하는 객체가 DTO 일까?

DTO는 데이터 전달 객체다

DTO 는 Data Transfer Object 의 약자다. 직역하면 데이터 전달 객체이다. 즉, 데이터를 전달하는 역할을 가진 객체를 DTO 라고 부른다.
DTO 는 데이터를 전달하는 역할을 가진 객체를 말한다.
데이터를 전달하는 역할을 수행하기만 하면 그것을 DTO라고 부를 수 있다. 즉, 도메인 로직이 구현된 객체를 데이터의 전달에 사용했다면, 그 객체는 DTO라고 할 수 있다.

레이어의 경계를 넘어갈 때 사용하는 것이 DTO다?

누군가는 MVC 패턴, 레이어드 아키텍처 등의 여러 패턴에서 정의한 영역 간의 데이터를 주고 받을 때 사용하는 것이 DTO 라고 말하기도 한다. 이는 DTO의 정의를 편협한 시각에서 내린 것이다.
아키텍처는 나도 만들 수 있다. 따라서 영역이라는 것도 내가 내맘대로 정의할 수 있다.

DTO가 가지면 좋은 특성

하지만, DTO로 분류된 객체가 데이터를 효과적으로 전달하기 위해 가지면 좋은 특징은 분명히 있다.
DTO vs VO
2024/03/08
Java
프로그래밍 일반
작성 완료

HTTP 1.1의 문제점

HoL Blocking

HTTP 는 TCP 위에서 구현된다. TCP는 신뢰성 있는 연결을 보장하는 프로토콜이다. 따라서, 연결과 해제 과정에서 확인 절차를 위해 많은 네트워크 통신이 발생한다. 즉, 한번의 TCP 연결에서 많은 데이터를 주고 받아야 TCP 연결과 해제 비용을 아낄 수 있다.
HTTP/1.1 은 HTTP 1.0이 한번의 TCP 연결에서 한번의 HTTP 요청과 응답만 처리하는 것을 개선하기 위해 파이프 라인 (큐)를 사용해 여러 HTTP 요청을 순차적으로 전송하고, 이에 대한 응답 역시 순차적으로 받을 수 있게 했다.
Head of Line Blocking = “맨 앞 차는 뭐하는거야?!”
HTTP/1.1에서는 여러개의 HTTP 요청을 하나의 TCP 연결에서 보낼 수 있지만, 요청 된 순서대로 그 응답을 받아 처리해야 하는 제약이 있다. 따라서, 먼저 보낸 HTTP 요청이 어떤 이유로 인해 처리하는데 오래 걸리면, 뒤의 요청이 이를 기다려야 한다.
이를 타계하기 위해 비교적 크기가 큰 이미지들을 하나로 붙인 이미지를 요청하고, 브라우저에서 스크립트 코드나 CSS를 이용해 잘라서 사용하는 등 별의 별 방법을 동원해 사용했다.
실제 네이버에 접속하면 가져오는 이미지

HTTP/2

HTTP/2의 목표

HTTP/2 는 처리량의 증가와 하위 호환을 목표로 했다.
HTTP/2는 앞서 설명한 HTTP/1.1의 문제점을 해결해, 더 짧은 시간에 더 많은 요청을 처리할 수 있어야 하면서도, 사용 편의성을 위해 제공되는 기능이나 핵심 개념(예: HTTP 메서드, 상태 코드, URI, 헤더 필드)은 변경되지 않아야 했다.
이런 목표를 달성하기 위해 HTTP 2는 새로운 레이어를 도입했다. 바이너리 프레이밍 레이어가 바로 그것이다.

바이너리 프레이밍 레이어

[네트워크] HTTP/2 - 새로운 구조
2024/03/02
CS
작성 완료

등장 배경

자바 코드는 쓸데 없이 장황하다! ⇒ 바꿔 보자!
자바에서 좌표 평면 상의 위치를 표현하기 위한 클래스인 Point 클래스를 작성한다고 해보자. 당연히 내부에 x 와 y 좌표를 나타내는 필드 변수가 있을 것이다. 또한, 올바른 동등 비교를 위해서는 equals와 hashCode도 재정의해야 한다. 그리고 단순히 좌표 값들을 전달하는 용도로 Point를 사용한다면 getter도 정의해야 한다. 따라서, 아래와 같은 코드가 작성된다.
이런 코드에는 몇가지 문제가 있다.
1.
개발자가 이들을 재정의 하는 것을 까먹을 수 있다.
2.
IDE 를 이용해 이런 반복적인 코드를 쉽게 생성할 수 있지만, 그것이 Point 가 단순한 값의 전달 용 클래스 인 것을 알기 쉽게 해주지 않는다.
이런 문제를 “간결한 코드”로 해결 하기 위해 Record가 추가되었다.

Record를 사용해야 하는 경우

Record 는 단순한 값의 집합을 표현하는 클래스를 작성하는데 사용하는 것이 좋다.

문법

예를 들어 앞선 Point 클래스를 Record로 변경한다면 다음과 같은 코드로 작성할 수 있다.
Record
2024/02/27
Java
작성 완료

한 것

페어 프로그래밍

두명이 짝을 지어, 하나의 컴퓨터를 이용해 한명(드라이버)은 코드를 직접 작성하면서 자신의 의도를 설명하고, 다른 한명(네비게이터)은 드라이버의 코드와 의도에 의문을 제시하며 함께 프로그래밍을 하는 방법.

알게 된 것

getter에 대하여

객체 지향 프로그래밍에서는 객체의 공개된 행동(메서드)을 통한 객체 사이의 의사소통으로 프로그램을 전개한다. 따라서, 객체 내부의 상태를 그대로 공개하는 getter는 객체지향 프로그래밍에서 지양한다.
그런데, 정말 getter는 무조건 피해야하는 걸까?
이번 미션에서는 자동차가 이동했다면, 실제로 이동했는지 확인해야 할 필요가 있었다. 하지만, 자동차의 위치를 getter로 가져오지 않으면서 이를 확인하고 싶었다. 이를 위해 나는 equals() 를 재정의 하였고, 다음과 같은 테스트 코드를 작성했다.
그리고 이에 대해 다음과 같은 리뷰를 받았다.
여러 경로를 통해 얻은 getter를 지양해야 하는 이유는 크게 두가지로 정리할 수 있었다.
1.
객체의 내부 상태를 노출한다. ⇒ 다른 객체의 내부 상태에 의존하는 코드를 작성할 수 있다.
2.
객체를 이상한 상태로 만들 가능성이 있다. ⇒ 참조형 데이터의 특성상 객체의 내부 상태를 외부에서 변경하게 될 수 있다.
[우테코] 레벨 1 자동차 경주 회고
2024/02/20
우테코
Java
작성 완료

버스트

프로세스의 실행은 CPU에 의해 명령어가 실행되는 것과, 입출력장치를 통한 작업을 기다리는 것을 반복하는 것이다. 이때, CPU에 의해 명령어가 실행되는 동안의 시간을 CPU 버스트라고 하고, 입출력 작업을 수행하는 동안의 시간을 IO 버스트라고 한다.
일반적으로 CPU 버스트는 매우 짧다. 아래 그래프는 일반적인 프로세스의 실행부터 종료까지 발생한 CPU 버스트의 빈도를 나타낸 그래프다. 물론, 프로세스마다 이런 그래프는 다 다르게 나타난다. 연산이 위주인 프로세스는 더 긴 CPU 버스트를 보일 것이다. 어쨋든 이런 분포는 스케줄링 알고리즘을 선택하는데 중요한 기준이 된다.

스케줄링 알고리즘 기초

스케줄링은 아래 4가지 상황에서 발생한다.
1.
실행중인 프로세스가 실행 상태에서 대기 상태로 전환될 때. (입출력 발생, 자식 프로세스 종료 대기 등)
2.
프로세스가 실행 상태에서 준비 완료 상태로 전환될 때. (인터럽트 발생)
3.
프로세스가 대기 상태에서 준비 완료 상태로 전환될 때. (입출력 종료)
4.
실행중인 프로세스가 종료될 때.
1번과 2번 상황에선 스케줄링이 무조건 발생한다. 그런데, 2번과 3번 상황의 경우 현재 실행중인 프로세스를 그대로 수행할 수 있는 상황이기 때문에 스케줄링이 발생하지 않아도 된다.

선점 스케줄링

2번과 3번 상황 중 적어도 어느 하나의 상황이 발생했을 때 스케줄링이 일어나는 알고리즘.
선점 스케줄링은 결국, 현재 실행중인 프로세스를 강제로 일시중지하고 다른 프로세스를 실행하는 것이다. 따라서 여러 프로세스가 공유하는 자원을 일시중지 대상인 프로세스가 접근하고 있다면 공유자원에 대한 프로세스간의 동기화문제를 해결해야 한다. 가령 일시 중지 대상의 프로세스가 공유 자원에 쓰기 작업을 하는 도중에 일시중지되고, 다른 프로세스가 이를 읽게 된다면 잘못된 상태의 공유 자원을 읽게 될 수 있다. 같은 이치로 모든 프로세스가 공유하는 커널영역의 어떤 변경을 유발하는 시스템 콜을 수행중인 프로세스를 일시중지하게 되면 문제가 발생할 수 있다. 따라서, 선점 스케줄링을 지원하려면 운영체제는 이런 문제가 발생하지 않도록 신경써야 한다.
[OS] CPU 스케줄링
2024/01/26
CS
작성 완료

쓰레드

프로세스보다 작은 실행 흐름의 최소 단위이다. CPU의 기본 단위라 할 수 있다. 모든 프로세스는 최소 한개의 쓰레드를 가진다.
프로그램이 점점 복잡한 작업을 수행하게 되면서, 논리적으로 하나의 프로그램에 속한 작업들을 동시에 수행할 필요가 있게 되었다. 예를 들면 웹 서버의 경우 동시에 여러 사용자의 요청을 처리해야 하므로 각 사용자의 요청을 처리하는 작업을 동시에 수행해야 한다. 이를 위해 요청이 들어올 때 마다 새로운 프로세스를 만들어서 이를 수행하게 할 수 있다. 하지만, 프로세스를 새로 생성하는 것은 비용이 큰 일이고, 이렇게 생성된 프로세스가 수행하는 일이 기존에 있던 프로세스와 거의 같기 때문에 생성 비용, 컨텍스트 스위칭 비용이 크게 낭비되는 것이다.
이 외에도 여러 작업이 동시에 수행되면서, 서로 데이터를 공유해야 하는 상황이 발생하면, 앞선 포스트에서 정리한 방법들을 이용해 프로세스간 통신을 해야 하는데, 이 역시 비용이 크다.
이런 이유로 “프로세스 내부에 더욱 작은 작업의 흐름” 이라는 개념이 필요해졌다. 그것이 쓰레드다. 쓰레드는 별도의 실행 흐름을 가지기 때문에 별도의 레지스터와 스택 영역, 프로그램 카운터를 가지지만, 코드영역, 자료영역, 힙 영역은 프로세스 레벨에서 공유한다.
쓰레드의 개념이 등장하게 되면서, 결국 앞선 포스트에서 이야기한 스케줄의 대상이 프로세스가 아니라 쓰레드가 된다.

쓰레드의 장점

1.
응답성 : 프로그램이 수행하는 작업들을 여러 쓰레드로 나누게 되므로, 사용자 응답성이 증가한다. 모바일 어플리케이션에서 서버와 통신하는 동안 다른 쓰레드가 화면을 랜더링할 수 있다.
2.
자원 공유 : 앞선 포스트에서 다룬 공유 메모리 설정 같은 것이 없어도, 쓰레드사이에는 메모리를 공유하므로 자원 공유가 쉽다.
3.
경제성 : 쓰레드는 프로세스 레벨에서 다른 쓰레드와 자원을 공유하기 때문에, 새로운 쓰레드를 생성하고, 컨텍스트 스위칭을 하는 비용이 프로세스의 그것보다 적다.
4.
다중 처리기에서 이익 : 하나의 프로그램이 하나의 프로세스로 동작한다면, CPU가 여러개 있어도 하나의 CPU에서만 실행되므로 아무 장점을 누릴 수 없다. 하지만, 쓰레드는 서로 다른 CPU에서 실행될 수 있으므로 병렬성이 향상된다.

쓰레드 컨트롤 블록(TCB)

프로세스의 메타 정보를 PCB 라는 형태로 표현하는 것 처럼, 쓰레드 역시 그 메타 데이터를 TCB라는 형태로 메모리에 저장해야 한다.
PCB가 TCB의 리스트를 가리키고 있는 구조가 된다.
[OS] 쓰레드
2024/01/26
CS
작성 완료

프로세스

메인 메모리에 적재되어 실행중인 프로그램이다.
여러 종류의 디스크에 저장된 프로그램 파일들은 CPU를 이용해 연산을 수행해야 하고, 각종 입출력장치와 데이터를 주고 받으며 동작해야 한다. 그런데, CPU의 동작 속도에 비해 디스크의 동작 속도가 느리기 때문에 CPU가 디스크에 저장되어있는 프로그램 코드를 직접 읽는 것은 아주 비효율적이다. 따라서, 비교적 용량이 작지만, 디스크에 비해 훨씬 동작 속도가 빠른 저장장치를 “메인 메모리” 라는 이름으로 중간에 두어 사용한다. 처음에 메모리에 프로그램의 코드와 기타 데이터를 미리 옮겨두고, CPU는 메인 메모리에서 코드를 읽어 CPU가 덜 낭비되게 된다.

메모리 구조

프로세스의 실행 코드와 각종 데이터는 메모리에 저장된다. 운영체제는 프로세스에 할당할 메모리를 적절한 용도로 구분하는 것이 유용할 것이다. 그렇게 운영체제는 메모리를 다음과 같은 구조로 할당한다.
•
스택 : 함수의 매개변수 및 지역변수, 함수 종료 후 복귀 주소 등 임시로 데이터를 저장하는 영역이다.
•
힙 : 프로세스 실행 도중에 할당되는 메모리 영역으로, 이 곳의 주소를 스택에서 참조하는 형태로 사용된다.
•
데이터 : 전역변수, 정적 변수가 저장된다.
•
텍스트 : 프로세스가 실행해야 하는 명령어가 저장되는 영역이다.

PCB(프로세스 컨트롤 블록)

프로세스의 메타데이터를 표현한 자료구조다.
PCB에는 프로세스의 상태, 프로세스의 식별자, 프로세스가 사용하는 입출력장치 목록, 프로그램 카운터(다음에 실행할 명령어의 주소), cpu 레지스터 정보 등 운영체제가 프로세스의 실행을 위해 필요로 하는 정보를 포함한다.
이런 정보들은 당연히 메인 메모리에 저장되며, 아주 중요한 정보이므로 사용자 영역이 아니라 커널 영역에 저장한다.
[OS] 프로세스
2024/01/21
CS
작성 완료

매직값 반환하기

매직값이란, 함수의 반환 타입에 부합하면서 특별한 의미가 부여된 값을 말한다.
예를 들어, 회원의 나이를 반환하는 함수 getAge()에서 회원의 나이가 등록되지 않은 경우 -1을 반환하는 경우가 매직값을 이용한 경우다.

매직값은 위험하다

매직값은 결국 그 함수의 내부 코드를 분석하거나, 관련 문서를 읽어야만 그 의미를 알고 그 함수를 호출하는 코드에서 이를 적절히 처리할 수 있다. 그렇지 않은 경우 문제가 생길 수 있고, 그 문제를 찾기조차 힘들 것이다.
아래 코드는 회원의 통계를 담당하는 클래스에서, 회원의 평균 나이를 계산하는 코드다.
값이 없음을 표현하는 여러가지 방법

도메인과 엔티티

도메인

소프트웨어가 동작하는 영역을 말한다. 즉, 소프트웨어를 통해 해결해야 하는 문제 영역이 도메인이다.
예를 들어 ATM에 탑재되어있는 소프트웨어의 도메인은 계좌, 은행, 카드 등이라고 할 수 있다.
Chat GPT와 함께 하는 도메인 영역이란?

도메인 로직

도메인 영역에서 해결해야 하는 구체적인 문제를 해결하기 위한 논리. 당연히 프로그램의 소스 코드와 마크업 코드로 구현된다.
은행의 예시를 들면, “송금을 하기 위해서는 송금할 금액보다 계좌의 잔액이 많거나 같아야 하고, 송금을 하는 계좌에서 잔액이 줄어들고 그만큼 송금 대상이 되는 계좌의 잔액이 증가해야 한다. 이 일련의 과정은 부분적으로 완료될 수 없고 모두 성공하거나 실패해야 한다.” 라는 논리가 도메인 로직의 일부가 될 것이다. 이를 코드로 표현하면 대충 아래와 같을 것이다.

엔티티

관계형 데이터베이스의 엔티티를 자바의 클래스로 표현했을 때, 그 클래스를 엔티티 클래스라고 하고, 그 인스턴스를 엔티티라 한다.
즉, 아래와 같이 JPA를 사용하는 상황에서 엔티티는 다음과 같이 생겼다. 아래 코드를 명확히 이해할 필요는 없다. 중요한 것은 아래 코드는 관계형 데이터베이스의 엔티티를 추상화한 자바 클래스라는 것이다.

도메인 로직을 엔티티에서 분리하는 것이 더 좋은 설계인가?

도메인과 엔티티의 분리
2024/01/15
팀 프로젝트
Java
아키텍처
작성 완료
Load more
Search
독서록

준비 실행 검증 패턴을 사용한 단위 테스트 구성법

3장 : 단위 테스트 구조
단위 테스트
2024/04/02

단위 테스트의 정의

1.
작은 코드 단위를 테스트,
2.
빠르게 수행하고,
3.
격리된 방식으로 처리하는 자동화된 테스트
격리가 무엇인지에 대한 의견 차이가 디트로이트 학파와 런던 학파를 나눈다.
격리에 대한 의견 차이는 테스트 단위에 대한 차이로 이어진다.

런던 학파

테스트 대상 시스템을 협력자에서 격리하는 것 ⇒ 테스트 대상 클래스의 모든 의존성을 테스트 대역(test double)로 대체해야 한다. ⇒ 장점 : 테스트가 실패하면 어디가 고장난건지 확실히 알 수 있다, 객체 그래프(객체 사이의 의존성을 그래프로 그린 것)을 중간에 끊어내고 테스트를 더 간단하게 할 수 있다.
단위 = 단일 클래스
테스트 대역 = 불변 의존성 제외한 모든 의존성

디트로이트 학파

단위 테스트를 격리하는 것 ⇒ 공유 의존성을 데스트 대역으로 대체하는 것
공유 의존성 : 테스트 간에 공유되고 서로의 결과에 영향을 미칠 수 있는 수단을 제공하는 의존성. 정적 가변 필드, 데이터베이스 등이 이에 해당된다. 비공개 의존성 : 공유하지 않는 의존성 프로세스 외부 의존성 : 애플리케이션 실행 프로세스 외부에서 실행되는 의존성. 보통은 공유 의존성이나, 꼭 공유 의존성인 것은 아니다. 예를 들어 데이터베이스는 프로세스 외부 의존성이지만, 테스트마다 컨테이너를 이용해 다른 데이터베이스를 실행시킨다면 공유 의존성은 아니다.
2장 단위 테스트란 무엇인가?
단위 테스트
2024/04/02

그룹화

Collectors.groupigBy

특정 기준에 따라 스트림의 요소를 그룹화 하여 Map으로 만들 수 있다.
만약, 위와 같이 분류된 각각의 리스트에 필터링을 걸고 싶다면, Collectors.filtering()을 사용할 수 있다.
예를 들어 가격이 1000 이상인 것만 남기고 싶다면 다음과 같이 하면 된다.
만약, 위와 같이 분류된 각각의 리스트에 map 을 적용하고 싶다면, Collectors.mapping을 사용할 수 있다.
위와 같이 코드를 작성하면 이름 리스트가 value인 map이 생성된다.
두번째 인자로 또 다른 groupBy를 넣으면, 여러 수준의 그룹화가 가능하다.

분할

Collectors.partitioningBy

6장 : 스트림으로 데이터 수집
IT / 언어
모던 자바 인 액션
정리 완료
2024/02/26

필터링

filter 메서드

Predicate 를 이용해 특정 조건에 맞는 요소만 남기는 필터링이 가능하다.
단, 별도의 연산을 추가하지 않는다면, filter 메서드는 모든 요소에 대해 검사하기 때문에 전체 순회가 발생한다.

distinct 메서드

equals 메서드와 hashCode 메서드로 결정되는 동일한 요소는 하나만 포함하도록 필터링한다.
equals 와 hashCode가 적절하게 정의되어있지 않으면 의도대로 동작하지 않을 수 있기 때문에 주의해야 한다.

스트림 슬라이싱

stream의 일부 영역을 잘라낸 stream을 얻는 메서드 들이다.

takeWhile & dropWhile

Predicate를 이용해 각각 조건에 맞지 않는 요소가 처음 나왔을 때까지 탐색한 요소를 포함하는 stream, 조건에 맞지 않는 요소가 처음 나왔을 때까지 탐색한 요소를 제외한 steream 을 생성한다.
만약, totalMenus가 이미 가격 순으로 오름차순 정렬되었다면 위 코드를 통해 가격이 3000 미만인 메뉴가 선택될 것이다.
5장 : 스트림 활용
IT / 백엔드
IT / 언어
모던 자바 인 액션
정리 완료
2023/09/18 → 2023/09/24

스트림 이란?

자바 8에서 새로 추가된 API 로, 선언형으로 컬렉션을 다룰 수 있게 해주고, 손쉽게 병렬처리를 할 수 있도록 해주는 API이다.

스트림의 우수성

다음 코드는 스트림 없이 작성한 저칼로리의 요리를 반환하는 코드다.
기존의 프로그래밍에 익숙한 사람은 금방 이해할 수 있지만, 임시 변수들도 여럿 사용되었고, 장황한 코드가 많다.
아래는 Stream을 이용한 코드다.
훨씬 알아보기 쉬운 코드가 작성되었다. 심지어 stream() 대신 parallelStream() 을 호출하면 알아서 멀티코어에서 실행된다.

스트림의 정의와 특징

스트림은 ‘데이터 처리 연산을 지원하도록 소스에서 추출된 연속된 요소’로 정의할 수 있다.
•
연속된 요소 : 컬렉션처럼 스트림은 특정 형식의 요소의 집합에 대한 인터페이스이다. 컬렉션과 다른 점은 요소 저장이나 접근 연산이 아닌, 표현 계산식이 주를 이룬다. 즉, 컬렉션은 데이터 그 자체가 주제이고, 스트림은 계산이 주제이다.
•
소스 : 스트림은 컬렉션, 배열, I/O 자원 등의 데이터 소스로부터 데이터를 소비한다. 데이터 소스의 요소 순서를 유지한다.
•
데이터 처리 연산 : 함수형 프로그래밍에서 일반적으로 제공하는 연산과 데이터베이스와 비슷한 연산을 제공한다. filter, map, reduce, find, sort 등의 연산을 통해 데이터를 조작할 수 있다. 이런 연산들은 순차적으로 혹은 병렬적으로 실행할 수 있다.
4장 : 스트림 소개
IT / 백엔드
IT / 언어
모던 자바 인 액션
정리 완료
2023/09/11 → 2023/09/17
4

람다 표현식

람다 표현식 이란?

익명함수를 단순화 한 것. 람다 표현식을 사용하면 동작 파라미터를 이용하는 코드를 더 쉽고 간결하게 작성할 수 있다.

람다 표현식의 구조

•
매개변수 리스트
•
화살표
•
람다 바디

함수형 인터페이스

람다 표현식은 함수형 인터페이스를 표현하는 문맥에서만 사용할 수 있다.
함수형 인터페이스란 추상 메서드를 한개만 가지는 인터페이스이다. 디폴트 메서드나 정적 메서드와는 무관하다.
람다 표현식은 결과적으로 함수형 인터페이스를 구현한 클래스의 인스턴스로서 동작한다.

람다식 활용 : 실행 어라운드 패턴

초기화&준비 코드와 정리&마무리 코드가 실제 작업 코드 앞뒤에 등장하는 형태의 패턴을 실행 어라운드 패턴이라 한다.
3장 : 람다 표현식
IT / 백엔드
IT / 언어
모던 자바 인 액션
정리 완료
2023/09/09
7장부터 11장은 설계 원칙을 다룬다. SOLID 말이다. 이 원칙은 중간 수준의 소프트웨어 구조가 변경에 유연하고, 이해하기 쉽고, 많은 소프트웨어 시스템에 사용할 수 있는 컴포넌트의 기반이 된다. 중간수준이라는 것은 이 원칙을 모듈 수준에서 작업할 때 적용할 수 있다는 뜻이다. 코드 수준보다 조금 상위의 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는데 도움을 준다.
SRP 원칙은 모듈이 단 하나의 일만 해야 한다는 의미가 아니다. 이런 원칙은 더 낮은 수준 즉, 코드 수준에서 사용된다.

SRP 원칙

SRP 원칙의 정의

단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다.
소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. 변경의 이유는 곧 시용자와 이해관계자를 가리킨다. 따라서 SRP는 다음과 같이 바꿔 말할 수 있다.
하나의 모듈은 하나의, 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다.
시스템이 같은 방식으로 변경되기 원하는 사람이 여러명일 수 있기 때문에 이는 집단으로 표현해야 한다. 이를 액터(actor)라고 하자.
하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.
모듈은 쉽게 소스파일이라 생각하면 된다. 만일 코드가 소스 파일에 저장되지 않는다면 모듈은 단순히 함수와 데이터 구조로 구성된 응집된 집합이다.

SRP를 위반하는 징후

우발적 중복

Employee 클래스에 calcutePay(), reportHours(), save()메서드가 있다. 이 클래스는 SRP 원칙을 위배한다.
•
calcutePay() : 회계팀에서 기능을 정의 ⇒ CFO에게 보고를 위해 사용
•
reportHours() : 인사팀에서 기능을 정의 ⇒ COO에게 보고를 위해 사용
7장 : SRP, 단일 책임 원칙
IT / 이론
클린아키텍처
2023/06/07

함수형 프로그래밍 개요

함수형 프로그래밍은 사례로 설명하는 것이 가장 좋다.
자바에서 0부터 9까지의 수의 제곱을 출력하려면 이렇게 한다.
함수형 언어인 클로저를 이용하면 이렇게 한다.
•
range 함수는 0 부터 시작해서 끝이 없는 정수 리스트를 반환한다.
•
map 함수는 range 함수가 반환한 리스트를 제곱을 반환하는 익명함수를 이용해 끝이 없는 정수 제곱 리스트를 생성한다.
•
제곱된 리스트는 take 함수로 전달되고, 10 개만 선택되어 println 함수에 전달된다.
눈여겨 봐야 할 것은 자바에서는 i 가 매번 변했지만, 클로저에서는 어떤 순간에도 변수의 값이 변경되지 않았다는 점이다. 즉, 함수형 언어에서 변수는 변경되지 않는다.

불변성과 아키텍처

변하지 않는다면 경합 조건, 교착상태 조건, 동시 업데이트 등이 발생할 수 없다. 당연한 말이지만, 어떤 변수도 갱신되지 않는다면 경합 조건이나 동시 업데이트가 발생할 수 없고, 락이 가변적이지 않으면 교착상태 역시 발생할 수 없다.
다수의 스레드와 프로세스로 인해 발생하는 문제는 가변 변수가 없으면 생기지 않는다.
물론, 현실적으로 가변 변수 없이 시스템을 만드는 것은 불가능하기 때문에 타협해야 한다.

가변 컴포넌트와 불변 컴포넌트의 분리

6장 : 함수형 프로그래밍
IT / 이론
클린아키텍처
정리 완료
2023/05/14

객체지향이 무엇인가?

객체지향을 “데이터와 함수의 조합” 이나 “실제 세계를 모델링 하는 새로운 방법” 으로 설명하는 것은 부족하고 모호한 설명이다.
객체지향을 캡슐화, 상속, 다형성을 통해 설명하는 경우도 있다. 이것이 객체지향의 본질인지 알기 위해선 이것들이 무엇인지를 알아야 한다.

캡슐화

캡슐화는 데이터와 함수를 응집하고, 구분선을 그어 외부에선 내부의 데이터는 은닉되고, 일부 함수들만이 공개되는 것이다.
캡슐화는 객체지향 프로그래밍에 국한된 개념이 아니다. 물론, 객체지향 언어에서 캡슐화를 쉽게 할 수 있는 도구들을 제공해주지만, 동시에 캡슐화를 불안전하게 만든다.
C언어에서도 .h 와 .c 를 분리해서 정보를 감추는 것이 가능하다. 오히려 자바에서의 private, public 을 이용한 캡슐화보다 더 강력하다.
point.h 에 struct 를 선언하고, struct 포인터를 만드는 함수를 선언하고, struct 를 사용하는 함수를 선언한 뒤, point.c 에서 이들을 정의하면, point.h를 include해서 사용하는 main.c 에서는 구조체의 내부에 접근할 수 없다. 심지어, point.c 를 변경하고 싶으면 변경한 뒤 point.c 만 컴파일하면 main.c 은 건들 필요가 없다.

결론

캡슐화는 객체지향의 본질이 아니다.

상속

상속은 결국 변수와 함수를 감싸 하나의 유효범위로 묶어서 재정의하는 것이다.
객체지향 언어는 상속을 편하게 그리고 안전하게 할 수 있도록 해준다. 하지만, 상속이 객체지향 프로그래밍에 국한된 개념은 아니다. C 언어에서도 구조체와 함수 포인터, 형변환을 사용해 상속을 구현 할(흉내 낼) 수 있다. 다만, 이런 방법은 프로그래머가 이를 의도적으로 따라야만 잘 작동한다는 단점이 있다. 객체지향 언어는 상속을 쉽게 할 수 있도록 해준다.

다형성

다형성은 다양한 것으로 하나의 것을 할 수 있는 것이다. STDIN, STDOUT 이 그 예시
5장 : 객체지향 프로그래밍
IT / 이론
클린아키텍처
정리 완료
2023/05/13

데이크스트라의 발견

모든 프로그램은 순차, 분기, 반복으로 표현할 수 있다.

기능적 분해

모듈을 기능적으로 나누는 것을 의미한다.
거대한 문제 기술서를 받아도, 문제를 고수준의 기능들로 분해할 수 있고, 이렇게 분해된 모듈은 제한된 제어구조(순차, 분기, 반복)를 이용해 표현할 수 있다. 이를 토대로 70~80년대에 구조적 분석, 구조적 설계같은 기법이 등장해서 인기를 끌었다.
구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 분해하고, 이를 테스트를 통해 세부 기능들이 거짓(잘못된)임을 증명하려고 시도한다. 테스트를 모두 통과하면 목표에 부합할 만큼 충분히 참이라고 여긴다.

구조적 프로그래밍의 가치

구조적 프로그래밍의 가치는 프로그래밍에서 반증 가능한 단위를 만들어내는 것에 있다.
현대적 언어에서 아무 제약 없는 goto 문장을 지원하지 않는 이유이고, 아키텍처 관점에서 기능적 분해를 최고의 실천법 중 하나로 여기는 이유다.
소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록 만들기 위해 분주히 노력해야 한다.
4장 : 구조적 프로그래밍
IT / 이론
클린아키텍처
정리 완료
2023/05/13
소프트웨어 아키텍처는 코드로부터 시작한다. 코드는 언어와 프로그래밍 패러다임이 발전하면서 변화했다. 따라서, 소프트웨어 아키텍처를 이야기 하기 위해서는 프로그래밍 패러다임을 이야기 해야 한다.

구조적 프로그래밍

구조적 프로그래밍은 무분별한 goto가 해롭다는 사실에서 출발한다. if/then/else do/while/for 등의 구조를 이용해 goto 대체한다.
구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다.

객체지향 프로그래밍

함수 호출 스택 프레임을 힙 영역으로 옮겨 함수에서 선언된 지역변수를 오래 유지시키는 아이디어에서 등장했다. 이 과정에서, 클래스, 생성자, 인스턴스 변수, 메서드 등의 개념이 생겼다.
객체지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다.

함수형 프로그래밍

수학의 람다 계산법을 프로그래밍에 도입한 것이다. 람다 계산법의 기초가 되는 개념은 기본적으로 심볼의 값이 변경되지 않는다는 불변성이다.
함수형 프로그래밍은 할당문에 대해 규칙을 부과한다.
각 패러다임은 프로그래머로부터 뭔가를 뺏어갔다. 더이상 뺐을게 없기 때문에 새로운 패러다임은 등장하지 않을 것.

패러다임과 아키텍처

객체지향의 다형성을 이용해 아키텍처의 경계를 넘어간다.
함수형 프로그래밍을 통해 데이터의 위치와 접근 방법에 대한 규칙을 부과한다.
3장 : 패러다임 개요
IT / 이론
클린아키텍처
2023/05/11
소프트웨어 시스템은 이해당사자에 행위와 아키텍처 라는 두가지 가치를 제공한다.
개발자는 두가지를 모두 챙겨야 하지만, 현실은 두가지중 덜 중요한 것을 챙기기 위해 중요한 것을 버리는 경우가 많다.

행위

프로그래머는 기능 명세서나 요구사항 문서를 구체화하고, 소프트웨어가 어떤 행위를 하도록 만든다. 소프트웨어가 이를 위반하면 고치는 것이 프로그래머가 해야 할 일이다.
그러나 이런 일이 프로그래머가 해야할 일의 전부가 아니다.

아키텍처

소프트웨어는 soft(부드러운)와 ware(제품)의 합성어다. 즉, 소프트웨어는 ‘부드러움을 지니도록’ 만들어졌다. 부드러움을 지닌다는 것은 변경하기 쉬워야 한다는 말이다.
변경사항 적용의 어려움은 변경의 범위에 비례해야 하고, 변경되는 형태와는 관련이 없어야 한다. 아키텍처는 형태에 독립적이어야한다.

기능과 아키텍처 중 더 중요한 가치

업무 관리자(시스템 사용자)는 당장 원하는 기능이 동작하는 것을 더 중요하게 여길 것이다. 하지만, 개발자는 이 의견에 동조해서는 안된다. 변경이 가능하면 기능이 잘 동작하도록 수정할 수 있기 때문.

아이젠하워 매트릭스

긴급한 문제가 아주 중요한 경우와, 중요한 문제가 아주 긴급한 경우는 거의 없다. 행위는 긴급하지만 매번 높은 중요성을 가지지 않는다. 아키텍처는 중요하지만 즉각적인 긴급성은 가지지 않는다.
우선순위
1.
중요O 긴급O
2.
중요O 긴급X
2장 : 두가지 가치에 대한 이야기
IT / 이론
클린아키텍처
정리 완료
2023/05/10
4
소프트웨어가 동작하도록 하는 것은 쉽다. 소프트웨어를 올바르게 만드는 것은 매우 어렵다. 제대로 만든 시스템 설계와 아키텍처는 아주 적은 인력으로 새로운 기능을 추가하거나 유지보수 할 수 있도록 해준다.

설계와 아키텍처.

설계를 저수준으로, 아키텍처를 세부사항에서 분리된 고수준의 것으로 구분하는 것은 무의미하다. 저수준의 세부사항과 고수준의 구조 모두 소프트웨어 전체 설계의 구성요소이기 때문. 둘은 개별로 존재할 수 있는 것이 아니고, 둘을 구분짓는 경계도 뚜렷하지 않다.

좋은 소프트웨어 설계의 목표

필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화 하는 데 있다.
설계 품질을 재는 척도는 고객의 요구를 만족시키는데 드는 비용을 재는 척도와 같다. 즉, 기능을 추가할 때 마다 비용이 증가한다면 나쁜 설계다.
코드 정리를 나중으로 미루는 개발자는 결코 코드를 정리하지 않는다. 이것이 반복되고 쌓이면 생산성은 0을 향해 수렴한다.
지저분한 코드는 장기적인 시각에서는 물론 단기적인 시각에서도 항상 깔끔한 코드보다 생산성이 낮아진다.
빨리 가는 유일한 방법은 제대로 가는 것이다.

결론

소프트웨어 아키텍처의 품질을 진지하게 고민하는 것을 하루라도 빨리 하는 것이 좋다.
비용을 최소화하고, 생산성은 최대화 하려면 시스템 아키텍처의 속성을 알아야 한다.
1장 : 설계와 아키텍처란?
IT / 이론
클린아키텍처
정리 완료
2023/04/23
4
Made with