전체 보기
/
/

최신순으로 보기

Search
전체 포스팅

시작하며

총대마켓 팀은 READ/WIRTE DB를 분리하며 Replication을 적용했다. Replication은 Amazon RDS 가 제공하는 기본 복제 기능을 사용해 구성했다. 관련한 AWS Docs 를 보면 복제 지연(Replication Lag)이 언급된다. 소스 인스턴스와 다른 AWS 리전에 읽기 전용 복제본을 생성할 때는 지연 시간이 증가할 수 있단 점을 감안해야 한다고 명시되어 있다.
총대마켓 팀은 소스 인스턴스와 다른 리전에 복제본을 생성했기에 지연 시간 증가를 분명 고려해야 한다. AWS Docs엔 지역 데이터 센터 간 네트워크 채널이 긴 경우 지연 시간이 발생한다고 나와있는데, 이 부분은 사용자인 내가 제어할 순 없기에 복제 지연을 어떻게 시뮬레이션해볼 수 있을지 고민했다. 복제 지연을 시뮬레이션 해보기 위해 MySQL에서 제공하는 복제를 직접 사용해 복제 환경을 구성하고, 의도적으로 1초의 지연 시간을 설정해보기로 했다.

Replication 이란?

Amazon RDS 읽기 전용 복제본

우선 현재 총대마켓 팀이 사용하고 있는 Amazon RDS 읽기 전용 복제본부터 알아보자. AWS Docs는 아래와 같이 설명하고 있다.
Amazon RDS 읽기 전용 복제본은 Amazon RDS 데이터베이스(DB) 인스턴스의 성능과 내구성을 높여줍니다. 읽기 전용 복제본을 사용하면 손쉽게 단일 DB 인스턴스의 용량 한도 이상으로 탄력적으로 스케일 아웃하여 읽기 중심의 데이터베이스 워크로드를 처리할 수 있습니다. 특정 소스 DB 인스턴스의 복제본을 여러 개 만들어 여러 데이터 사본이 요청하는 높은 애플리케이션 읽기 트래픽도 처리할 수 있습니다. 덕분에 전체 읽기 처리량이 향상됩니다. 필요한 경우 읽기 전용 복제본은 독립 실행형 DB 인스턴스로 승격될 수 있습니다. MySQL, MariaDB, PostgreSQL, Oracle 및 SQL Server 데이터베이스 엔진의 경우, Amazon RDS에서 소스 DB 인스턴스의 스냅샷을 사용해 두 번째 DB 인스턴스를 생성합니다. 그런 다음 엔진의 기본 비동기식 복제 기능을 사용해 소스 DB 인스턴스가 변경될 때마다 읽기 전용 복제본을 업데이트합니다. 읽기 전용 복제본은 읽기 전용 연결만 가능한 DB 인스턴스 역할을 수행합니다. 애플리케이션을 읽기 전용 복제본에 연결하는 방법은 DB 인스턴스에 연결하는 방법과 동일합니다. Amazon RDS는 원본 DB 인스턴스의 모든 데이터베이스를 복제합니다.
요약하자면, 읽기 전용 복제본의 장점으로 1) 탄력적 스케일 아웃 2) 높은 읽기 트래픽 처리 3) 읽기 전용 복제본의 독립 실행형 인스턴스로의 승격 을 들고 있다. 복제 방식에 대해선 1) 처음엔 스냅샷으로 인스턴스 생성 2) 이후엔 비동기 복제 기능으로 복제본 업데이트 를 들고 있다.
여기서 비동기 복제본 업데이트 부분을 더 디테일하게 알고 싶어 찾아보니, DB 엔진에 따라 복제를 다르게 구현한단 점을 알게 되었고, 총대마켓 팀이 사용 중인 MySQL에 대해선 AWS Docs에 아래와 같이 정리되어 있음을 확인했다.
•
논리적 복제를 사용함
Replication Lag 시뮬레이션 및 해결 (I/O Thread)(MySQL 8.0)
2024/10/20
INFRA
HIGHLIGHT

문제 분석

배포자동화 과정 중 OAS 파일을 제대로 업로드하려면 build를 두 번 해야만 하는 문제가 존재했습니다. 왜 build를 두 번 이상 할 때만 OAS 파일이 제대로 업로드 되는지 원인을 알기 위해 배포 서버의 JAR 파일을 열어 보았습니다. build를 한 번만 했을 땐 JAR 파일에 OAS 파일이 누락되는 걸 확인할 수 있었습니다.
이는 OAS 파일을 만드는 task가 bootJar task에 의존하고 있어 발생한 문제였습니다. processResources task에서 static 경로에 있는 파일을 읽어두고, bootJar task는 해당 파일들만 인식합니다. OAS 파일은 processRecourses task가 실행된 이후 생성됐기 때문에 JAR 파일에 누락되었습니다.

해결 과정 1

이를 해결하기 위해 먼저 단순하게 task의 순서를 조정해봤습니다. OAS 파일 관련한 task를 processResources task 보다 먼저 실행하면 해결되지 않을까 싶었는데, task들끼리 순환 참조하는 문제가 발생했습니다. 원래는 processResources -> test -> createOAS -> bootJar 순서로 의존했는데, processResources -> test -> createOAS -> processResources 의 순환 의존 관계가 형성되어 문제가 되었습니다.

해결 과정 2

다음으로 bootJar task 에 적용할 수 있는 설정들이 있나 살펴보았습니다. Gradle 공식문서를 통해 아래와 같은 코드로 기존의 순서를 유지하면서 bootJar task가 OAS 파일을 인식할 수 있게 할 수 있단 걸 알게 되었고 적용해 문제를 해결했습니다.
사실 이 방식 외에 단순히 bootJar task와 OAS 관련 task 간에 의존 관계를 끊어버리는 방식도 존재했지만 JAR 파일 빌드 과정에 OAS 파일이 필요한 경우가 저희 팀의 default 요구사항이였기에 해당 방식은 택하지 않았습니다. 만일 JAR 파일 빌드 시 OAS 파일이 빠져야 한단 요구사항이 팀에 더 중요한 상황이었다면 해당 방식을 택했으리라 생각합니다.
관련한 내용은 아래 PR에서 확인하실 수 있습니다.
JAR 파일에 OAS 파일이 누락되는 문제 어떻게 해결할까?
2024/09/20
JAVA
지난 글에서 클린 아키텍처에 대한 오해를 풀어보았다. 이번 글에선 클린 아키텍처를 실제로 어떻게 적용할 수 있을지 구체적인 활용 방안을 공유하려 한다.

Uncle Bob 이 말하고자 하는 바

Uncle Bob의 클린 아키텍처에는 우리가 흔히 중요하다고 여기는 SRP, OCP, DIP 같은 설계 원칙들이 기저에 깔려 있다. 특히, 그는 그의 저서들에서 단일 책임 원칙(SRP)의 의미를 강조하며, 이 원칙이 단순히 “하나의 일만 해야 한다”는 것과는 다르다고 말한다. SRP는 “하나의 모듈이 변경되는 이유는 단 하나여야 한다” 또는 “하나의 모듈은 하나의 액터에 대해서만 책임을 져야 한다”라는 뜻이라고 강조한다.
그렇다면 그가 말하는 “하나의 모듈이 변경되는 이유가 하나뿐”이어야 한다는 것은 어떻게 가능할까? 바로 의존성 규칙이 이를 가능하게 한다. 이 규칙은 클린 아키텍처가 동작하는 데 가장 중요한 규칙 중 하나로, "소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다"는 것이다. 이렇게 하면 외부의 세부 구현이나 기술적 변경이 안쪽의 중요한 비즈니스 로직에 영향을 미치지 않으며, 안쪽 모듈의 변경 이유는 오직 해당 모듈 내의 비즈니스 규칙이나 정책 변화에 국한될 수 있다.
이 의존성 규칙을 지키기 위한 지침으로 그는 원 모형을 제시하며, 원의 경계를 횡단하는 방법에 대해 설명한다. 원의 경계를 횡단할 때 제어 흐름과 의존성의 방향이 명백히 반대여야 한다면, 의존성 역전 원칙(DIP)을 사용해 해결하라고 제시한다.
결국 그가 클린 아키텍처를 통해 말하고자 하는 바는 전통적인 설계 원칙들과 크게 다르지 않다. 이 점을 유의한 채, 클린 아키텍처를 활용해보자. 참고로 아래의 소제목은 Uncle Bob 블로그 속의 Clean Architecture 라는 글의 소제목과 동일하다. 클린 아키텍처에서 말하는 개념을 어떻게 코드에 적용할지 레거시 코드를 리팩토링하며 탐험해보자.

원의 경계 횡단하기 (Crossing boundaries)

원의 경계를 횡단할 때 주의할 점이 있다. 바로 제어 흐름과 의존성의 방향이 명백히 반대여야 하는 경우다. 이때엔 의존성 역전 원칙을 사용해 해결해야 한다. 예를 들어 서비스에서 리포지토리를 호출해야 하는 경우, 직접 호출하면 의존성 방향이 반대가 되기 때문에 서비스가 리포지토리의 인터페이스를 호출하도록 만들고 인터페이스를 내부 원에 둔다. 그리고 외부 원에 리포지토리의 구현체를 두는 것이다. 간단하게 설명했는데, 실제 프로젝트에 이를 적용해보자.
클린 아키텍처에서 코드 품질 향상의 근거 찾기 (with 레거시 리팩토링)
2024/09/19
DESIGN
HIGHLIGHT
내 생각이자 이 글에서 말하고 싶은 바를 한 줄로 요약하자면, “클린 아키텍처는 따라야 할 스타일이 아니라, 지향해야 할 규칙이다”라는 점이다. 관련해 하고 싶은 말이 많았어서 글이 조금 길긴 한데, 핵심만 보고 싶은 이들은 중간에 ‘덕질을 하다 답답해진 포인트’부터 읽어도 무방하다.
요즘 내 최대 관심사는 클린 아키텍처다. 오늘만해도 집에 와서 읽은 클린 아키텍처 관련한 책이 너무 설레는 배움을 줘버린 바람에 다른 해야 할일이 눈에 보이지 않게 방해했다. 클린 아키텍처를 모두가 알았으면 좋겠는 이 마음을, 글로 정리해서라도 가라앉혀 보려 한다.

클린 아키텍처를 덕질하게 된 계기

클린 아키텍처에 대한 내 관심(을 넘어선 사랑)은 레벨 3가 끝나고 찾아온 방학부터 본격적으로 시작됐다. 그 전까진 사실 클린 아키텍처에 대해선 모두가 알고 있을 유명한 원 그림 정도만 알고 있었다. 그렇다면 어쩌다 클린 아키텍처에 대한 애정 어린 탐구가 시작된걸까.

데이터베이스 주도 개발 편하고 좋은 거 아닌가요?

레벨 2에 간단한 스프링 어플리케이션을 개발하며 생각했다. “JPA 엔티티를 그대로 도메인으로 쓰는 거 너무 편하고 좋은데?ㅋㅋ”라고 말이다. 그래서 JPA 엔티티가 지키지 못하는 불변성이나 DB와의 종속성을 불편해하는 소수의 크루들을 오히려 신기해했다. 신기해서 해당 크루들이 코치에게 가서 불편함을 토로하는 걸 따라가서 구경도 했다.
앞선 소수의 크루들은 객체지향이 지켜지지 않는 걸 보며 극도의 불안함을 느껴했지만, 나는 기술에 한정해 무한한 신뢰를 오히려 의심하고 경계하는 성격이라 그동안 크루들에게 무한 추종받던 객체지향이 무너지는 걸 보고 약간의 희열을 느끼기도 했다. 그동안 배운 객체지향의 패러다임을 야금야금 깨트리는 JPA 엔티티를 보며 좋아라 했던 것이다.
당시 크루들이 내린 결론의 핵심은 “객체지향도 결국 좋은 코드를 위한 방식 중 하나일 뿐, 객체지향만이 좋은 코드는 아니다”였다. “좋은 코드를 위한 길엔 여러 가지가 있고, 개발에 진정 은탄환은 없구나.”를 느끼며 마무리한 레벨이었다.

데이터베이스 설계는 내 최대 관심사(였던 것)

클린 아키텍처에 대한 오해와 헥사고날 아키텍처에 대한 무한한 신뢰가 답답해서 쓰는 글
2024/09/05
DESIGN
HIGHLIGHT

개발 철학에 대한 고민

크루들 봤을 때 보이는 학파들이 아래와 같다 생각했다.
(지극히 개인적인 의견임. 그 외에 수많은 학파 있을 수 있음. 당장 떠오르는 것만 정리해봄)
나는 기능 유지보수 학파에 가장 가까운 것 같다. 그렇다보니 기능 구현에 집중하고, DB 의존 개발에 별 생각 없다. 엄밀하겐 지양해야 한단 쪽에 매우 동의하지만 가장 먼저 나서서 불편해하진 않았다.
또, 당장 성능에 큰 문제 없으면 성능 개선에도 별 관심 없다. 예를 들어 2초 가량 걸리는 테스트가 개선 했을 때 0.x초 가량을 개선할 수 있다면 큰 관심 없다. 시간이 흘러 테스트가 10초 가량이 걸리게 되어 개발에 병목이 발생한다면 그제야 관심을 가진다.
내가 생각 못한 부분(ex. DB 의존 개발 하지 않기, 테스트 성능 개선하기 등)에 관심을 가지는 다른 크루들을 보며, 내가 개발자로서 부족한 건지 걱정이 되었다.

내가 잘하는 거 하기

내 철학과 취향을 생각해보고 따라가면 되겠단 결론을 내렸다. 한 사람이 하나의 철학만 가지는 건 아니다. 여러 가지 철학을 혼재해 가진다. 성장하며 다방면을 고려하게 되는 거니 당장에 하나의 철학에 기운다고 걱정할 필요 없다.
내가 가장 중요하게 여기는 것, 내가 가장 잘하는 것이 곧 내 정체성이다.
남이 대단한 걸 한다고, 나는 그걸 못했다고 아쉬워할 필요 없다. 내가 원하는 것, 내가 잘하는 것을 내 방식대로 진행하면 남들도 날 똑같이 대단하다고 생각한다.
내가 잘하는 거 하기 (with 개발 철학에 대한 고민)
2024/08/29
DIARY_MIND

문제 상황

우테코에서 인덱스와 트랜잭션에 대해 학습하며, 몇 십 만 건의 데이터를 더미 데이터로서 저장해둘 필요가 있었다. 이때, 토미(코치)가 아래와 같은 말씀을 해주셨다.
pk 포함한 insert 쿼리이니 하나의 파일 전체를 하나의 커넥션에서 실행하는 것보다, 여러 개의 파일로 나눠서 여러 커넥션을 이용해 쿼리를 병렬로 실행하면 좀 더 빠르겠죠? 이렇게 데이터가 많을 때는 텍스트 에디터를 사용하는 것보다, 리눅스 커맨드를 이용해 파일의 특정 라인을 잘라내는 것이 훨씬 빠르고 쉬울 수 있습니다.
토미가 제공해주신 파일은 아래와 같은 형태였다.

해결 1. 쉘 스크립트로 병렬 실행하기

쉘 스크립트 연습하기
1.
스크립트 생성 (sql 파일들이 있는 경로에 생성함)
2.
실행 권한 부여
3.
스크립트 실행

해결 2. GNU Parallel 이용해서 병렬 실행하기

쉘 스크립트로 insert 쿼리 병렬 실행하기
2024/08/28
DIARY_DEVELOP

Fair Scheduling

그라운드룰: 공평하게 말하기

“회의 내 deadlock과 starvation을 방지하고, fair scheduling을 추구한다”. 내가 속한 총대마켓 팀의 그라운드 룰이다. 무슨 뜻일까? 쉽게 말해 회의 속 자원인 ‘말’을 모두가 공평하게 한다는 뜻이다.
‘피로 쓰이는 안전 수칙’이란 말이 팀 그라운드룰에도 적용된다. 협업을 더 잘하기 위해 총대마켓 팀이 몸소 고군분투하며 만들어 나간 그라운드룰 제1법칙을 소개한다.
1 . 말(자원)은 모두가 공평하게

문제 정의: 말을 못 하는 사람 존재

총대마켓이 해결해야 할 문제는 운 좋게도 굉장히 이른 시점에, 우연한 계기로 드러났다. 팀을 결성한 지 2주가 조금 지난 시점에, 타 팀원이 잘 모르겠다고 질문한 내용이 마침 내가 잘 아는 내용이라 설명을 맡게 된 상황이었다.
설명하다 말이 길어졌고, 질문한 팀원이 무언갈 말하고자 한단 신호를 놓친 채 혼자만의 대화를 해버렸다. 이를 제3의 팀원이 제지했는데, 당시 해당 팀원이 사용한 언어적 표현이 조금 날카로워 아쉬웠다. 또한, 말이 길어져 이러한 상황을 만든 스스로에게도 아쉬웠다.
서론이 길어졌는데, 본론만 꺼내보자면 총대마켓이 가장 처음 마주한 문제는 아래와 같았다.
말이 길어진 사람이 있다.말이 길어질 때 이를 제지할 수단이 부족하다.
협업 잘하는 법: Fair Scheduling
2024/08/20
REVIEW

editorconfig-gradle-plugin 에 대해 알아보자

•
정의) .editorconfig 파일에 정의된 형식 규칙을 준수하는지 여부를 확인하고, 위반 사항을 수정하기 위한 Gradle 플러그인
•
기본 사용)
•
추가 설정)
•
동작 과정)

자바 파일에 대해 .editorconfig 규칙 설정하기

1.
.editorconfig 파일에서 자바 파일에 대한 형식 규칙을 정의
2.
자바 프로젝트에 .editorconfig 규칙 검사를 추가하고, check 작업에 의존하도록 설정

Reference

editorconfig-gradle-plugin
ec4j
build.gradle에 코드 포매팅 적용 (with editorconfig)
2024/07/29
DIARY_DEVELOP

논리적 오답과 비논리적 정답

감정의 회오리에 숨겨진 자아 정체성

이 이야기는 행복과 슬픔의 감정 가운데 자아 정체성을 찾아간 이야기다. 우리는 살면서 수많은 감정을 느낀다. 감정은 고민을 수반하기도 하고, 우리를 이리저리 요동하기도 한다. 감정의 회오리에 휘말렸을 때 비로소 보이는 것이 있는데, 바로 자기 자신이다. 자신을 반추하여 '나를 나답게 하는 것'(이하 자아 정체성)이 무엇인지 찾아낸다면, 앞으로 다가올 수많은 감정의 회오리 속에서 보다 매끄럽게 헤쳐 나와 평온함을 유지할 수 있다.
자아 정체성은 한 개일 수도 있고, 여러 개일 수도 있다. 평생 똑같을 수도 있고, 해가 지날 때마다 바뀔 수도 있다. 어떤 이는 평생 자아 정체성을 찾지 못할 수도 있다. 확실한 사실은 인간은 최소한 한 개의 정체성을 가진단 점과, 그 정체성을 알면 앞으로의 인생을 슬기롭게 헤쳐 나가는 데 도움이 된단 점이다.

행복

'나는 무엇을 할 때 행복을 느끼는 사람인가'를 정의해보면 정체성을 찾아가는 데에 도움이 된다. 인간은 자기 연민을 지니고 살기에 아무래도 슬픈 감정보단 행복한 감정에서 자신을 찾기 더 쉽다. 이때 가짜 행복을 주의해야 한다. 아래 도라의 이야기를 들어보며 가짜 행복은 무엇이고 진짜 행복은 무엇인지 알아보자.
도라는 집에서 홀로 게임을 하며 '와, 이게 행복이지!'라고 생각했다. 만족할 만큼 게임을 한 도라는 게임을 껐다. 게임을 하던 중과 달리 게임을 끈 후엔 퀭한 눈과 약간의 두통만 남긴 채 아무 생각도, 감정도 들지 않았다.도라는 우아한테크코스에서 페어와 함께 불꽃 튀는 토론을 하고 나서, 집으로 돌아가며 보람과 행복을 느꼈다. 무엇이든 해낼 수 있으리란 자신감이 쏟아져 나옴을 느끼며 '왜 이렇게 행복하지?'라고 생각했다.
누군가는 게임이 끝나고 나서도 잊을 수 없는 고양감과 자신감을 느낄 수도 있지만, 도라는 그러하지 않았다. 게임이 주는 행복은 도라의 정체성에서 우러나온 행복이 아니기 때문이다. 도라에게 1번은 가짜 행복이다.
반면, 토론은 끝나고 나서도 도라에게 장기적인 자신감을 불어넣어 줬다. 도라는 본인이 한 층 더 성장했음을 느낄 수 있었다. 도라의 내면이 원하는 무언가를 충족했기 때문이다. 그 무언가를 찾는 일은 어렵다. 하지만, 한 가지 분명한 사실은 내면이 바라는 무언가를 충족한 2번이 도라에게 진짜 행복이었단 점이다.
진짜 행복을 안겨준 '무언가'(이하 요소)를 돌아보며 우리는 정체성을 찾아나갈 수 있다. 그 요소는 굉장히 복합적일 수도 있고, 꽁꽁 감춰져 있을 수도 있다. 한 겹 한 겹 들춰 나가며 탐색해 나가야 한다. 도라의 이야기를 이어서 들어보며 그 과정을 살펴보자.
도라는 토론이 행복했던 이유로 아래와 같은 요소들이 있으리라 정리해 보았다.
네 가지 중 도라의 정체성이 무엇인지는 아직 단언하기 어렵다. 토론 외에도 도라에게 행복을 안겨준 일련의 사건들, 그리고 이어 말할 슬픔을 준 사건들을 늘어놓았을 때 보이는 공통적인 요소가 도라의 정체성이다.

슬픔

여기서 논할 슬픔은 인간이라면 누구나 느낄 사회적 슬픔이 아니다. '나는 무엇을 특히 불편해하는 사람인가'와 관련한 개인적 슬픔을 다루고자 한다. 이번에도 도라의 이야기를 들어보며 개인적 슬픔이 무엇인지 알아보자.
도라는 영화 속 비련의 주인공을 보고 눈물을 흘렸다. 옆을 보니 같이 보던 친구도 울고 있었다.도라는 논리적이지 않은 말을 할까 두려워 말을 못 꺼낸 자신을 보고 슬펐다.
소통 잘하는 법: 논리적 오답과 비논리적 정답
2024/06/20
REVIEW
외부 API를 연동하기 위해 RestClinet를 사용하던 중 아래와 같은 코드를 마주했다. 여기서 builder()가 이 글의 주제다. 결론부터 말하자면 builder 패턴은 때론 anti pattern 이 될 수 있다. 특히 POJO에선 anti pattern 으로 사용하게 될 확률이 높다. 이에 대해 Spring Framework Docs에서도 사용하고 있는데 좋은거 아니야? 라고 반문할 수 있다.

When Builder is anti-pattern

builder 패턴이 왜 문제가 될 수 있는지를 살펴보면 해당 질문에 대한 해답을 어느 정도 얻어갈 수 있다.
아래 아티클의 내용 중 핵심을 뽑아보자면 아래와 같다.

Wrong Example

사실 나는 프로젝트를 할 때 builder를 애용했었다. 예전에 내가 느꼈던 builder의 장점은 필드와 생성자가 많아졌을 때 사용하는 쪽에서 어떤 필드를 어느 순서로 집어넣어야 하는지 정해, 생성자를 잘못 사용하는 실수를 줄일 수 있단 점이었다.
실제로 new Member("이름",…"전화번호", "주소")와 같이 사용할 때, 필드가 없어졌다 추가됐다를 반복하다가 new Member("이름", …"주소", "전화번호")과 같이 사용해 두 필드의 순서를 바꿔 생성하는 실수를 한적이 있었다. 이는 컴파일 타임은 커녕, 런타임에도 잡히지 않아 나아아중에 해당 데이터를 사용할 때 겨우 알아냈던 경험이 있다.
이때 프로젝트 전반적으로 Member.builder().name("이름").phone("전화번호").address("주소")와 같이 builder 패턴을 도입해 개발자의 실수를 줄이는 데 도움을 받았었는데, 지금와서 다시 생각해보면 위 케이스의 경우 builder 패턴이나, 생성자나 어차피 런타임에 잡히지 않는단 건 동일한 데 굳이..? 싶다. 인텔리제이가 친절하게 생성자 매개변수에 대한 미리보기 기능도 지원하기에 builder만이 주는 엄청난 메리트는 없었지 않나 싶다.
POJO에서 builder 패턴의 효용성
2024/06/02
DIARY_DEVELOP
애플리케이션 로직과 도메인 로직이 각각 무엇인지에 대해 이해하고, 둘을 구분해 코드를 개선한 사례를 글로 풀어보겠습니다.

애플리케이션 로직? 도메인(비즈니스) 로직?

각각을 아래와 같이 짧게 정의해볼 수 있습니다. 여기서 도메인 로직의 정의는 조금 추상적으로 느껴집니다.
•
애플리케이션 로직: 도메인 로직이 의사결정을 할 수 있도록 입력을 제공하거나, 그 결과를 외부 서비스, DB, UI 등에 업데이트하는 역할을 맡음
•
도메인(비즈니스) 로직: 현실 세상의 문제에 대한 의사결정을 함

애플리케이션 로직만 있고 도메인 로직은 없는 시스템 vs 애플리케이션 로직만 있고 도메인 로직은 없는 시스템

이를 좀 더 쉽게 이해하기 위해 아래 예시에 대해 소거법을 이용해 차이를 구분해보겠습니다.
[예시] 예약 가능 시간 목록 조회 API V1
애플리케이션 로직만 있고 도메 로직인이 없는 시스템은 겉으론 동작을 하는 것처럼 보이지만 그 값이 사용자가 원한 해결책이 아닐 것입니다. 예시의 API V1에선 예약이 된 시간과 안된 시간이 제대로 구분되지 않고 출력될 것입니다.
반면, 도메인만 있고 애플리케이션 로직은 없는 시스템은 문제에 대한 의사결정은 가능하지만 이에 대한 입출력 로직이 부재해 실질적으론 문제를 해결하지 못하는 시스템이 될 것입니다. 예시의 API V1에선 예약이 된 시간과 안 된 시간을 구분하는 방법은 알지만 구분할 대상과 그 결과를 보여줄 방법이 부재하는 시스템이 될 것입니다.
애플리케이션 로직과 도메인(비즈니스) 로직을 구분해 얻는 장점
2024/05/14
DIARY_DEVELOP
우테코 내 핫한 였던 DELETE 메서드에 대한 논란들을 내 생각과 함께 정리해보겠다.

1. DELETE는 멱등성을 보장하는가? 보장해주어야 하는가?

(1) DELETE는 멱등성을 보장하는가?

아래와 같은 상황에서 DELETE /reservations/1 은 멱등성을 보장한다고 말할 수 있을까?
우테코 슬랙 채널에 올라온 재밌는 이야기를 가져와봤다. 대다수의 크루들이 멱등성을 보장한다고 답했다. 이때, 한 가지 재밌는 의견을 내준 크루가 있었다.
A: 데이터가 없어서 삭제하지 못했다는 예외 상황에 대한 상태코드를 반환했을 뿐 DELETE /reservations/1은 몇 번을 반복해도 같은 결과를 도출하기 때문에 멱등성을 보장한다고 볼 수 있을 것 같습니다! 데이터의 관점에서는 삭제된다는 결과 외에는 다른 부작용이 없는 것 같습니다!
B: 저도 A와 같은 이유로 멱등성을 해치는건 아니라고 생각합니다. 다만 3번과 4번이 거의 동시에 호출되었을때의 상황 (일명 따닥 눌러서 같은 요청이 두번 호출되는 상황) 에 대해서 생각해보면 좋을것 같아요. 3번 요청에 대한 처리가 서버에서 잘 진행되어데이터가 삭제 되었어요. 200 응답이 클라이언트로 전달되는 과정에 네트워크 오류 등으로 전달되지 못하게 되었어요. 그 후 4번 요청이 서버에 전달되면 삭제할 데이터가 없어 400응답을 하겠죠. 그렇게 400 응답만이 사용자에게 전달 되게 되면, 응답을 받은 사용자는 “id=1이라는 예약이 애초에 없어 삭제되지 않았구나” 라고 질못 착각하게 되는 문제가 있을것 같아요. 따라서 두 개의 요청(따당 눌린 3, 4번의 요청)에 대해 같은 요청이었는지 여부를 판단하는 기준을 세워야 할것 같아요. 예를들어 1초 이내의 시간에 한 동일한 요청은 같은 요청으로 생각해 2번째 응답에서도 200 상태코드를 응답한다던지 하는 방법도 있을것 같아요.아래글에서는 멱등키를 헤더에 전달하는 방식을 이용해 이런 문제를 해결했다고 하네요!
여기서 B 크루의 의견이 굉장히 흥미로웠다. 서버 구현마다 다를 수 있지만, 보통 GET 요청은 멱등성을 보장하지 못하기에 위의 토스페이먼츠 글에선 멱등키를 이용해 멱등성을 보장했다. 이에 대해 B 크루는 DELETE 도 멱등키를 이용해 멱등성을 더 정교하게 보장해줄 수 있단 의견을 내놓았다. 이 의견에 대한 내 생각을 글로 정리해보겠다.

(2) 멱등성의 정의와 의의

먼저, DELETE의 멱등성에 대해 논하기 위해 멱등성의 정의부터 내리고 시작하자.
DELETE의 멱등성 보장 & DELETE의 id 검증 필요성(200, 400 status code)
2024/05/10
WEB

좋은 API란?

API는 application programming "interface"의 약자로, 응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.
이번 미션에선 HTTP API, JAVA API 정도를 사용했다. HTTP API를 이용해 웹브라우저(응용프로그램)와 저희 서버 간에 데이터를 주고받을 수 있었다. JAVA API를 이용해서 저희의 자바애플리케이션을 쉽게 구현할 수 있었다.
API도 결국엔 인터페이스이기에 API가 왜 만들어졌고 왜 쓰는지를 고민해보는건 인터페이스를 만들고 쓰는 이유를 고민해보는것과 비슷한 맥락으로 바라볼 수 있다고 생각한다. 우리는 인터페이스를 만듦으로써 구현과 사용을 분리하고 기능을 추상화하여 사용을 쉽게 만들 수 있었다. 마찬가지로 우리는 API를 만들고 사용함으로써 서로 다른 프로그램 간 추상화된 기능을 쉽게 사용하게 만들 수 있다.
결국 레벨 1에서 배웠던 좋은 코드를 짜는 법이 좋은 API를 만드는 법에도 적용된다. 의도가 분명하고 적절한 역할과 책임을 가지는 객체들에서 객체 대신 API를 대입해보면 된다.

REST API란?

REST API에 대해선 워낙 잘 정리해둔 글들이 많아서 크게 논할 건 없고, 앞서 언급한 HTTP API에 여러 가지 제약 조건이 추가된 친구 정도라고 말하고 싶다. 제약 조건을 완벽히 지키기엔 실질적으로 어렵기에, 디자인 가이드를 어느 정도 따라갔다면 보통 REST API라 부른다. REST API 디자인 가이드론 자원의 식별, 메시지를 통한 리소스의 조작, 자기서술적 메시지, 애플리케이션의 상태에 대한 엔진으로서의 하이퍼미디어 가 있다.

“중첩 리소스에 대한 REST API 디자인 가이드”와 “좋은 API”

위에 언급한 디자인 가이드 중 자원의 식별에 초점을 맞춰 글을 서술하겠다. 우테코 미션인 방탈출 예약 프로그램을 구현하던 중, 예약 가능한 시간이라는 자원을 API에서 어떻게 표현할지 고민이 됐다. 현재 서버의 자원을 간략히 소개하자면 예약 과 예약 시간이란 자원이 존재하고, 예약이 예약 시간을 사용하는 구조였다.
위 구조에서 나올 수 있는 시나리오는 아래와 같았다.
중첩 리소스에 대한 REST API 디자인 (with. 좋은 API란)
2024/05/04
DIARY_DEVELOP
Repository를 인터페이스화 하여 얻는 장점은 뭘까? 특히나, db가 바뀔 일 없는 상황에선 더더욱 의문이 들 수 있다. 이에 대해 내 나름대로의 근거를 찾아간 과정을 공유해보겠다.

Repository의 구현체를 Dao로 명명

우선 내 코드의 구조를 설명하자면 domain 패키지에 Repository 인터페이스가 들어가있고, Repository의 구현체는 dao 란 이름을 가진 채로 dao 패키지에 들어가있다. 이게 무슨 뚱딴지 같은 소리야? 싶은 이들은 코드로 좀 더 내 코드의 상황을 살펴보자. 이해를 돕기 위한 부분만 남기고 간략화한 코드다. 전체 코드를 보고 싶다면 아래 링크로 들어가서 볼 수 있다.
domain 패키지엔 아래 클래스들이 들어있다. 참고로, domain 패키지에 repository 인터페이스를 넣어준 이유는 repository를 도메인 객체의 컬렉션을 관리하는 개념으로 보았기 때문이다.
그리고 대망의 dao 패키지엔 아래 클래스가 들어있다. Repository의 구현체 이름을 Dao라 붙인 이유는 database에 접근하는 역할을 더 잘 표명할 수 있기 때문이다. 아래 클래스는 JdbcTemplate을 이용해 db에 쿼리를 날리고 있다.

Repository의 구현체를 다른 패키지에 둬서 얻는 장점

위와 같은 구조로 얻을 수 있는 장점으론 service가 dao 구현체를 아예 모르게 해줄 수 있단 점이 있다. 기존엔 service가 domain과 dao 패키지를 모두 살펴봤지만, 현재는 service가 domain 패키지만 알고, 구현체가 들어있는 dao 패키지는 모른다. 이를 통해 구현체를 숨길 수 있다. 그리고 지금과 같은 계층 구조에서 구현체를 숨기는 장점이 특히 두드라진다.
web / service(application service + domain service) / domain / database
Repository의 구현체를 숨겼을 때 얻을 수 있는 장점
2024/04/27
DESIGN

고민한 상황

Controller > Service > Repository 구조의 스프링 프로젝트에서 Service가 다른 Service에 의존할지, 다른 Repository에 의존할지 고민이 되는 순간이 생겼다. 코드로 보자면 아래와 같은 상황이었다.
Reservation이 ReservationTime과 연관관계를 맺고 있어 Reservation을 저장하려면 ReservationTime에 대한 조회 쿼리를 함께 날려야 했다. 이때 ReservationService 에서 ReservationTimeRepository의 findById() 함수를 이용할지, ReservationTimeService의 findById() 함수를 이용할지 고민이 되었다. 둘중 뭘 사용해도 결과는 쿼리 실행 결과는 똑같은 상황이었다. 고려할 점은 객체 간 의존성이었다.

Service에서 다른 Service 의존

ReservationService가 ReservationTimeDao를 아는 건 Controller -> Serivce -> Dao 순에서 하위 계층을 참조하고 있기에 순환참조의 위험이 없다. 그러나 중복 코드가 생길 수 있다. 지금 상황에선 ReservationTimeService 에 아래의 함수가 존재했다면, 두 Service 객체 사이에 중복 코드가 존재한다.

Service에서 다른 Repository 의존

반면, ReservationService가 ReservationTimeService를 아는 건 순환참조의 위험이 존재한다. 그러나 순환참조가 생기지 않도록 조심한다면 너무 경계할 필요는 없다. 오히려 중복 코드를 제거한단 관점에서 효율적일 수 있다. 현재 상황에선 아래와 같이 고쳐볼 수 있다.

선택의 근거

둘 중 뭐가 옳다 하는 정답은 없고, 상황마다 팀마다 다르게 선택할 거 같다. 만일 ResevationService가 사용해야 하는 ReservationTimeService의 메서드가 단순히 dao 접근만 담당하는 게 아니라 그 외의 복잡한 비즈니스 로직을 실행한다면 ReservationTimeService를 사용해 중복 코드를 줄일 거 같다. 현재 상황에선 단순히 dao 접근만 담당하는 전자에 가깝기에 ReservationService가 ReservationTimeService가 아닌 ReservationTimeRepository를 사용하는 방식을 택했다.
Service에서 다른 Service 의존 vs Repository 의존
2024/04/26
DIARY_DEVELOP
happy case만 처리하고 전부 status code로 200을 뱉을 때, 아래 4개의 코드는 같은 결과를 낸다.
Spring 4.0 introduced the @RestController annotation in order to simplify the creation of RESTful web services

ResponseBody vs ResponseEntity

다음으로 3번보단 4번을 사용하는 편이 추상화 관점에서 더 바람직하다 생각한다. 추상화 레벨을 통일하는 데 도움이 되기 때문이다.
ResponseBody, ResponseEntity, RestController 사용과 추상화
2024/04/19
DIARY_DEVELOP
Web, Service, Dao 레이어를 분리해둔 코드에 대해, 현재 database를 사용하지 않는데 레이어 분리가 꼭 필요했을지에 대해 질문 받았다.

Dao 레이어 분리

정확하겐 아래와 같이 레이어를 분리해뒀다.
•
Web : request/responseDTO로 웹과 상호작용
•
Service : request/responseDTO를 domain으로 매핑해 웹과 데이터저장공간 사이를 연결
•
Dao : domain으로 데이터저장공간과 상호작용
이때, Dao는 아래와 같은 꼴이었다. 후에 save, delete, find 동작이 List 콜렉션이 아닌 database 를 대상으로 동작하게 리팩토링 할 예정이었다.
꼭 database가 아닌 메모리 내 데이터저장공간을 대상으로도 레이어 분리는 의미가 있다 생각했다. List 같은 자료구조를 사용하여 데이터를 관리하는 경우에도, 작성해둔 각 레이어의 역할이 퇴색되지 않기 때문이다.
특히 Service 레이어를 넣을지 말지에 대해서 고민을 좀 했었는데, 메모리 내 데이터저장공간을 memoryDao로 다루기로 한 이상 dao와 web 사이를 연결해주는 중간 계층(Service)을 넣는 편이 코드를 간결하게 유지하는데 도움이 된다 판단했다.
오버엔지니어링과 Dao 레이어 분리
2024/04/18
DIARY_DEVELOP
아래 코드에 대해 Dao인데 Repository 어노테이션을 사용한 이유에 대해 질문 받았다.
일단 왜 위의 코드가 Dao인지부터 궁금할 수 있는데, 추후 save, delete, find 동작이 List 콜렉션에 대해 동작하는 게 아니라 database에 대해 동작하게 리팩토링할 계획이라 Dao라고 이름 붙여뒀다.

Repository 어노테이션의 역할

스프링 빈으로 등록하고 싶어서 별 고민없이 사용했었는데, @Repository 어노테이션의 역할을 살펴보니 현재 코드에선 불필요하단 점을 깨달아 @Component 어노테이션으로 변경해주었다. 현재 코드에선 database와 관련한 예외를 변환할 일이 없기 때문이다. 스프링 빈으로 등록시키는 건 @Component 어노테이션으로 충분하다.
•
@Repository 의 역할

Dao와 Repository 어노테이션 (with 공식문서)

다만, 후에 database를 적용한다면 Dao여도 @Repository을 붙이는 게 말이 아예 안되진 않을 거 같다.
Dao 클래스에 Repository 어노테이션을 붙여도 될까
기본적인 웹 요청을 처리할 수 있는 프로그램을 페어와 만들며, DTO 사용과 관련한 컨벤션에 대해 논의했다. 크게 1) API마다 서로 다른 DTO를 사용할지, 하나의 DTO를 사용할지와 2) DTO의 네이밍 컨벤션에 대해 논의했다.

Web 계층의 DTO

Spring Boot 프레임워크를 사용해 웹 요청을 받고 응답하도록 했다. 이때, Spring Boot에서 제공하는 @Controller, @RequetsMapping 어노테이션을 사용해 요청을 처리하는 Web 계층이 만들어졌다. 완성된 Web 계층의 코드는 아래와 같다.
여기서 웹 요청을 받고 응답할 때 사용하는 매개체인 Json으로 파싱되는 객체가 ~Response, ~Request 로 끝나는 객체들이다. 그리고 이 객체들은 DTO들이다.

API마다 서로 다른 DTO를 사용할지, 하나의 DTO를 사용할지

Json으로 파싱되는 객체를 앞으로 편의를 위해 API의 응답값이라 부르겠다. 실제론 API의 요청값 혹은 응닶값으로 사용된다.

API들마다 서로 다른 DTO를 응답값으로 사용하는게 더 적합한 상황

API의 응답값으로 도메인 객체를 사용하면 어떻게 될까? API 응답값으로 도메인을 사용할 경우, 해당 도메인에 관련된 API들은 전부 도메인에 의존하게 된다. 만일 도메인의 필드가 하나라도 변경되면, 클라이언트한테 제공하는 인터페이스인 API들이 일파만파 영향을 받게 된다.
Web 계층의 DTO와 네이밍 컨벤션
2024/04/16
WEB
우테코 미션을 하다보면, 추상클래스를 쓸 때도 있고 인터페이스를 쓸 때도 있다. 둘의 차이를 내 생각과 함께 면밀히 정리해보겠다. 용어 정의에 바탕한 이론을 다루는 글임을 미리 밝힌다. 학창 시절 교수님께 배웠던 C++의 추상클래스와 비교하며 원론적인 정의를 내려보겠다.

1. Dynamic Method Dispatch (vs. Dynamic Binding)

먼저, Dynamic Method Dispatch 라는 개념을 통해 추상 이란 용어에 대해 이해해보자. 긴 용어로 들으면 뭐지 싶을 수 있는데, 해석해보면 어렵지 않다. “동적으로 호출할 메서드를 결정한다”라는 뜻이다. 반댓말론 Static Method Dispatch 가 있다. 이는 “정적으로 호출할 메서드를 결정한다”라는 뜻이다.
정적이라 함은 컴파일 시점에 컴파일러가 특정 메서드를 호출할 것을 명확히 알고 있는 경우를 의미하고, 동적이라 함은 컴파일러는 어떤 메서드를 호출해야 하는 지 모르고 런타임 시점에 호출할 메서드를 결정하는 경우를 의미한다.
그렇다면 어떻게 해야 동적으로 메서드 호출을 결정할 수 있을까? 바로, 인터페이스나 추상 클래스에 정의된 추상 메서드를 사용하면 된다. 같은 클래스를 상속하고 있는 여러 클래스 중 어느 서브 클래스를 사용할 것인가를 런타임 시점까지 미룸으로서, 클래스 재사용성을 높이는 것이다.
여기까지 읽고 나면 이거 Dynamic Binding 이랑 완전 똑같은 거 아니야? 싶을 수 있다. 허나, Dynamic Method Dispatch 와 Dynamic Binding 은 엄밀히 말하자면 다른 개념이다. 아래 링크로 들어가보면 깔끔하게 이를 정의내려주는데, 요약하자면 Dynamic Binding은 런타임 시점에 특정 메서드 구현을 결정하는 메커니즘이고, Dynamic Method Dispatch는 Dynamic Binding을 사용해 런타임 시점에 특정 메서드 구현을 결정하고 이를 찾아 호출하는 과정까지를 포함한다고 한다.
Dynamic dispatch is different from late binding (also known as dynamic binding). Name binding associates a name with an operation. A polymorphic operation has several implementations, all associated with the same name. Bindings can be made at compile time or (with late binding) at run time. With dynamic dispatch, one particular implementation of an operation is chosen at run time. While dynamic dispatch does not imply late binding, late binding does imply dynamic dispatch, since the implementation of a late-bound operation is not known until run time.
Dynamic Binding(==late binding)과 Dtnamic Method Dispatch의 차이에 대해 더 자세히 알고 싶은 사람은 아래 글도 추천한다.
Abstract class vs Interface (virtual function vs abstract method)
2024/03/25
JAVA
3월 18일, 벌써 우테코에서 한 달이 지났습니다. 한 달 간 자동차 경주 게임, 사다리 게임, 블랙잭 게임 총 세 가지 미션을 진행했습니다. 미션을 진행하며 생각한 내용들을 정리해보겠습니다.
+
4월 13일, 레벨 1의 마지막 미션인 체스 게임까지 완료한 시점에서 해당 글을 이어 작성해보겠습니다. 레벨 1 기간 동안 생긴 저의 개발 철학과 기준들을 작성하려 합니다.

1. 자동차 경주 게임

(1) SOLID 의존 관계 역전 원칙

문제가 된 코드는 아래와 같았습니다다.
이 방식의 문제는 명확했습니다. Cars에서 Car를 생성할 때 fromRandomGenerator를 사용하고 있는 상황에선, 후에 Cars에서 Car를 생성할 때 다른 Generator도 사용하고 싶다면 (하다못해 메서드를 추가하는 식으로라도) Cars의 코드가 변경되어야 합니다. 결국 상위 모듈(사용하는 쪽)인 Cars가 하위 모듈(기능 제공하는 쪽)인 Car의 영향을 받습니다.
SOLID 원칙 중 하나인 의존관계 역전 원칙은 상위 모듈이 하위 모듈에게 의존하지 않도록 설계하라 합니다. 다시 말하자면, 상위 모듈은 하위 모듈의 구현에 의존해서는 안 됩니다. 대신 하위 모듈이 상위 모듈에서 정의한 추상 타입에 의존해야 합니다. 이를 위해선 Cars가 fromRandomGenerator, fromXXXGenerator 를 사용하는 현재 구조가 아닌, Car가 Cars에서 제공하는 Generator에 의존해야 합니다. 여기서 의존하는 건 어떻게 표현해야 할까요?
의존성 주입(DI)이라는 디자인 패턴으로 이해하면 쉽습니다.
1.
생성자 주입
2.
프로퍼티 주입
레벨 1 기간동안 생긴 나의 개발 철학과 기준 (Java, OOP)
2024/03/18
JAVA

Inheritance(상속)

•
정의) 기존에 정의되어 있는 클래스의 필드와 메서드를 물려받아 새로운 클래스를 생성하는 기법
•
장점)
•
단점)

Composition(조합)

•
정의) 전체를 표현하는 클래스가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용하는 방법
•
구현) 조합하고 싶은 클래스의 인스턴스를 새로운 클래스의 private 필드로 참조하고, 인스턴스의 메서드를 호출하는 방식으로 구현
•
특징)

Inheritance vs Composition

•
상속의 목적 고려하기: 클라이언트 관점에서 두 객체가 동일한 행동을 할 것이라 기대하는가? O(상속)/X(조합)
•
상속의 대상 고려하기: 상속을 고려하는 두 객체가 IS-A 관계인가? O(상속)/X(조합)
•
상속이 적절하게 사용되면 조합보다 강력하고, 개발하기도 편리함
Inheritance vs Composition
2024/03/11
DIARY_DEVELOP

우아한테크코스는 내게 어떤 존재일까: 개발자의 천국

2월 13일, 우아한테크코스 6기 백엔드 과정을 시작하고서 3주간 정신 없는 나날들이 흘렀다.
욕심이 많았기에 더욱 정신 없었다.
우아한테크코스라는 소중한 기회를 절대 허투루 쓰고 싶지 않아서, 하루 하루 최선을 다했다.
우아한테크코스라는 이름 자체가 기회라는 말이 절대 아니다.
내가 실제로 겪은 우아한테크코스의 생태계는 정말 기회의 땅이었다.
마치, 개발자들의 천국에 온 느낌이었다.
초등학생이 된 것 마냥, 집에 와서 매일 부모님께 오늘은 또 얼마나 재밌고 행복했는지를 쫑알댔다.
어느 부분이 행복했는지를 나열하자면 한도 끝도 없지만 딱 한 마디로 정리하자면 토론광들이 모인 곳이라서다.
나는 ‘왜?’ 라는 질문이 많은 사람이다. ‘왜?’ 라는 질문에서 시작해서 사고를 확장해 나가는 게 참 재밌다.
그렇기에 강의식 학습보단 실제로 겪어보며 배우는 걸 훨씬 좋아한다.
우아한테크코스는 내게 어떤 곳인가
2024/03/04
REVIEW

정의

•
트리에서 임의의 두 노드 선택했을 때, 두 노드가 각각 자신을 포함해 거슬러 올라가면서 부모 노드를 탐색할 시 처음 공통으로 만나게 되는 부모 노드
•
트리에서 두 노드 u, v가 있을 때, u이거나 u의 조상이면서 동시에 v이거나 v의 조상인 노드들 중 가장 깊은 노드

특징

•
최소공통조상을 구하는 방식은 일반적인 방식과 빠르게 구하는 방식이 있음

과정 (일반적인 방식)

1.
루트 노드부터 탐색을 시작해서 각 노드의 부모 노드와 깊이를 저장
2.
선택된 두 노드의 깊이가 다른 경우, 더 깊은 노드의 노드를 부모 노드로 1개씩 올려 주면서 같은 깊이로 맞춰줌. 이때, 두 노드가 같으면 해당 노드가 최소공통조상이므로 탐색 종료
3.
깊이가 같은 상태에선 동시에 부모 노드로 올라가면서 두 노드가 같은 노드가 될 때까지 반복함. 이때, 처음 만나는 노드가 최소공통조상

과정 (빠르게 구하는 방식)

•
정의) 서로의 깊이를 맞춰주거나 같아지는 노드를 찾을 때 기존에 한 단계씩 올려주는 방식(일반적인 방식)에서 2k2^k 단계씩 올라가 비교하는 방식으로 변경한 것
•
특징) 기존에 자신의 부모 노드만 저장해 놓던 방식(일반적인 방식)과 달리 2k2^k 번째 위치의 부모 노드까지 저장해 둬야함
1.
부모 노드 저장 배열 만들기
2.
선택된 두 노드의 깊이 맞추기 (깊이를 한 단계씩이 아닌 2K2^K 단위로 넘어가면서 맞춤)
최소 공통 조상
2024/02/08
SUB PAGE
Load more