'좋은 사람이 되고 싶은데 왜 이렇게 부족했던 것일까' '왜 젊은 시절 넓은 세상에서 다양한 사람들과 다양한 도전을 하지 않았던 것일까' '왜 나는 이렇게 부족한 것일까...'

'나만 이렇게 부족한 것일까?'

1년. 수많은 인연들을 만나고 새로운 도전을 해야겠다.

먼저, 앞으로 1년 간의 기록을 정리할 앱 만들기! 해외여행가기! 알바하기! 필름 카메라로 사진찍기! 앱 출시하기! 남들이 하는 것 따라하기! ...

그리고 1년 후, 그 과정이 깃든 앱 둘러보기 '기대'되는 내일을 살고 싶다.

혼자 생각을 계속 할 수록 혼자만의 생각이 정교해질 뿐이다.

혼자만 생각하다보면 어느새 색안경을 끼고 세상을 바라보게 되기에

의도와 달리 사람들과 세상에 상처를 주게 된 적이 많았다.

그래서 오늘의 목표는 여러 블로그들을 둘러보며 응원을 글을 남겨보는 것이 목표다.

새로운 소통을 도전해볼 것이다.

본 프레임워크는 스윙을 활용하여 개발자의 생산성을 높이도록 설계되었다. 아래의 사진 2 -> 4까지 변화하는 과정에서 개발자가 개발한 페이지 수정은 없다.

이 글의 목적은 같이 고민해보며 함께 앞으로 나아가는데 있다.

Github Swing Page

다루고자 하는 내용은 아래의 9가지다.

1. 버전 명명 규칙
2. 디스패처 동작 과정
3. 프레임워크를 활용한 개발자 사고 단순화
4. 레이어드 아키텍처 포트 & 어댑터 아키텍처 모듈러 아키텍처 객체 생성과 조립, 접근
5. 패키지 수준 접근과 자바 모듈 시스템
6. 가비지 컬렉션

핵심 키워드는 바로 추상화다. '내가 주체로서 어떤 역할을 어떻게 책임질 것인가' '내가 맡지 않은 영역에 대해선 누구에게 무엇을 위임할 것인가'

여러 경험을 바탕으로 나만의 답을 조심스레 내렸다. 존재하는 오류를 함께 고민해보자.

자, 그럼 시작해보자.

1. 버전 명명 규칙

SW 버전 명명 규칙을 위의 실행 사진과 함께 알아보자.

프레임워크 변화 과정

• 사진 1 -> 2: minor 변화 프레임워크: (이전 페이지, 이후 페이지) 개발 개발자: 수정 x

• 사진 2 -> 3: major 변화 프레임워크: 다크모드 개발 개발자: 호환을 위해 반드시 코드 수정

• 사진 3 -> 4: 변화 x 프레임워크: 변화 x 개발자: 커스텀 메뉴 추가 코드 단순 작성

프레임워크에 Semantic Versioning으로 이름을 붙인다면

• 1번 화면은 V1.0.0
• 2번 화면은 V1.1.0
• 3번 화면은 V2.0.0
• 4번 화면은 V2.0.0

SemVer: major.minor.patch 로 버전명을 붙이는 규칙

여기서 다루고 싶은 바는 호환성 이다.

나는 혼자서 개발할 때 SemVer를 적용하려고 했지만, 모호하게 되어 규칙이 일관되게 적용되지 않았다.

하지만, '누군가'가 사용한다는 관점으로 나누어 개발하는 순간 명확하게 major.minor.patch가 나뉘어 질 수 있었다.

버전 명명 규칙은 코드를 사용하는 다른 개발자를 배려하는 것이라고 생각한다.

2. Dispatcher 동작 과정

프레임워크가 어떻게 동작하는지 이미지를 통해 알아보자.

1. 로그인 페이지를 보고 있는 사용자가 전문가로 회원가입하려고 버튼을 누른다.

2. 로그인 페이지는 전문가 회원가입 의도를 디스패처에 전달한다.

3. 디스패처는 의도에 매핑된 페이지를 찾아 사용자에게 제공한다.

4. 사용자는 회원가입을 하지 않고 다시 홈 화면으로 이동을 선택한다.

스프링과의 비교

이 과정은 스프링을 이해하는데 도움이 된다.

스프링은 (네트워크) 요청을 받아서 (서블릿) 디스패처가 적절한 컨트롤러를 찾아서 작업을 위임한 후, 뷰를 포함해서 사용자에게 응답한다.

작업을 위임하는 과정은 후술할 레이어드 아키텍처에서 다룰 예정이다.

3. Loose Coupling

내가 이 프레임워크를 개발하고자 했던 가장 큰 목표였다.

느슨한 결합을 통한 사고 과정 단순화

이전에는 화면과 화면이 서로 너무 직접적 영향을 받았다. 한 화면이 다른 화면 객체에 접근했기 때문이다.

그래서 이 결합을 끊어내기 위해 페이지와 의도(일종의 이벤트)를 도입하였다.

그래서 화면은 이벤트만 발생시킨다.

화면 전환의 역할은 프레임워크가 수행한다.

이로 인해 개발자가 화면을 구성하는 관점을 달리할 수 있게 되었다.

따라서 위의 2 ~ 4 사진을 다시 바라보자.

• 2번 사진은 프레임워크에서 이전과 이후 기능을 추가했다.
• 3번 사진은 다크 모드를 추가했는데, 호환성이 깨져 개발자가 일부 코드를 수정해야 했지만 페이지와 의도(이벤트)는 수정이 없었다.
• 4번 사진은 프레임워크를 개발자가 좀 더 활용한 것이다.

결국 페이지와 이벤트는 단 한번도 수정할 필요가 없었다.

4. 레이어드 아키텍처

페이지 안의 구성은 다음과 같다.

페이지

• 책임: 콘텐츠 제공의 책임이 있다.
• 위임: 콘텐츠를 구성하고, 비즈니스 로직을 처리하는 역할은 없다.

컨트롤러

• 책임: UI를 구성하고 버튼에 따라 이벤트를 발생시켜 콘텐츠를 구성한다.
• 위임: 비즈니스 로직은 서비스에 맡긴다.

서비스

• 책임: 도메인 엔티티와 함께 비즈니스 로직을 처리한다.
• 위임: 네트워크 요청 등의 작업은 인프라스트럭처에 맡긴다.

인프라스트럭처

• 책임: 네트워크 요청 등 타 시스템과 작업을 수행한다.

스프링에서 흔히 볼 수 있는 아키텍처이다. 아래 레이어에 의존하기 때문에 주로 클린 아키텍처가 같이 언급된다.

번외. 포트 & 어댑터 아키텍처

아래라는 개념 대신 안과 밖이라는 개념을 활용한 아키텍처다.

난 포트 & 어댑터 아키텍처를 볼 때마다 드는 생각은 '아래의 층에 의존한다, 비즈니스 로직 영역이 핵심이다라고 하다니, 우리는 각자 동등하게 맡은 바에 충실하다. 동등하게 대우해달라.'라고 외치는 것 같았다.

내가 생각하는 포트 & 어댑터 아키텍처는 아래와 같다.

번외. 모듈러 아키텍처

모듈과 인터페이스, DI & IoC를 잘 활용한다면 빌드 스크립트 몇 줄만으로 손쉽게 모듈을 교체할 수 있다.

5. 객체 생성과 조립, 접근

다시 페이지를 구성하는 요소들을 보자.

페이지는 컨트롤러를 필요로 하고, 컨트롤러는 서비스를 필요로 하며, 서비스는 리퀘스트를 필요로 한다.

클래스들과 생성자들은 모두 패키지 수준 접근만 가능하다. 패키지 밖에선 생성과 접근이 까다롭다.

질문의 답은 아래에 있다.

• 질문 1 패키지 내에 있는 Assembler 클래스가 페이지 구성 요소들을 생성하고 조립한다.

이 과정 역시 스프링을 생각나게 한다.

객체를 생성하고 조립하는 과정을 스프링은 마법으로 보이게 한다. 이 마법을 이해하는 것이 중요하다고 생각한다.

단계적으로 생성해서 조립하는 과정을 누군가에게 맡긴다면

그 누군가는 특정 클래스의 인스턴스를 대상으로 매번 동일한 싱글톤으로 하거나, 아니면 매번 새로운 인스턴스로 하거나 또는 테스트 인스턴스로 쉽게 대체할 수 있게 하거나 인스턴스 동작에 로직을 추가하는 등 다양한 과정을 수행할 수 있다.

• 질문 2 이렇게 조립된 페이지를 외부에선 추상클래스로 접근한다.

인터페이스 또한 사용했지만 추상클래스를 사용한 이유는

인터페이스는 주로 역할을 정의하는 데 사용했고 추상클래스는 클래스 간 Has-a 관계를 정의하는 데 사용했기 때문이다.

페이지가 수행할 역할을 IPage에 정의하였고, 컨트롤러를 가져야 한다는 관계를 AbstractIPage로 정의하였다.

5. 패키지 수준 접근과 자바 모듈 시스템

위의 각 페이지 내의 구성 요소는 하나의 페이지에서만 사용된다. 이를 패키지 수준으로 접근을 제한하였다.

그렇지만 자바는 자바 9부터 자바 모듈 시스템을 지원한다.

리플렉션에 대한 접근 또한 제한하기 때문에 일장양단이 있다.

본 프레임워크의 페이지가 확장되어 클래스 간 논리적 구분이 필요해지고 여전히 페이지 외에서의 접근을 제한할 필요가 있다면 자바 모듈 시스템도 하나의 답이라고 생각한다.

6. 가비지 컬렉션

역시나 깊이있게 다루는 것은 아니지만 현재 코드 수준에서 가비지 컬렉션도 한번 들여다보자.

class Controller extends AbstractController {
// 버튼과 dispatch() 호출에 주목. 나머지 코드 생략 
    @Override
    public JPanel getLayout() {
        loginButton.addActionListener(e -> onLoginButtonClick(idField.getText(), new String(passwordField.getPassword())));
        generalUserSignUpButton.addActionListener(e -> onGeneralUserSignUpButtonClick());
        expertUserSignUpButton.addActionListener(e -> onExpertUserSignUpButtonClick());
        //생략 
        return layout;
    }

    private void onLoginButtonClick(String id, String pw) {
        if (service instanceof Service user) {
            user.login(id, pw);
            dispatcher.dispatch(new MyPage());
        }
    }

    private void onGeneralUserSignUpButtonClick() {
        dispatcher.dispatch(new GeneralUserSignUp());
    }

    private void onExpertUserSignUpButtonClick() {
        dispatcher.dispatch(new ExpertUserSignUp());
    }
}

버튼을 누를 때마다 의도(이벤트)를 생성해서 디스패치한다. 이 인스턴스는 딱 한번만 사용된다.

이 인스턴스를 메모리 영역에서 바라보자.

생성되어 디스패처에게 이벤트가 전달되면 이 이벤트에 매핑된 페이지를 사용자에게 보여준다.

이 이벤트는 참조가 없고 단 한번만 쓰이게 된다. 루트로 부터 참조가 이어지지 않는 인스턴스들은 실행 중 어떤 순간 청소된다.

청소 과정을 좀 더 들여다보면 여러 영역으로 나뉘어져서 차등적으로 청소 기회를 갖는다.

오래 살아남은 인스턴스는 이후로도 오래 살아남는다는 가설이 있기에 오래 살아남은 인스턴스들은 청소 기회를 덜 빈번하게 갖는 영역으로 옮겨진다.

저만의 생각이 정교해지는 것을 조심하기 위해 잘못된 부분들을 지적해주시면 감사하겠습니다 :)

Swing Page를 코틀린으로 전환할 프로젝트가 바로 KSwing Page다. 코틀린으로 특정 도메인(Java UI)을 다룰 수 있는 기회가 되었기 때문이다.

코틀린의 DSL 뿐만 아니라 다양한 문법을 활용하여 프레임워크과 개발자 각각에 어떠한 영향을 줄 수 있는지 그 내용들을 착실히 비교하는 글을 작성해나갈 것이다.

앞으로 어떤 부분에서 자바와 코틀린이 차이가 있는지 독자가 쉽게 체감할 수 있도록 이후의 페이지들을 채워나가는 것이 나의 새로운 목표다.

go my way

• 열정 열정
• 싹싹하게

개발, 일상 뿐만 velog에서도 삶을 돌이켜보며 패치! 패치! 해보자

난 velog에서도 도망쳤다.

블로그를 써도 비공개로 해두고, 시간이 지나서야 공개를 했다. 그래야 트렌드에서 쉽게 못 찾을 테니까

'일기는 일기장에라는 비판을 들을까' '혹시나 문제가 있는 내용은 없을까' '이것이 초래할 문제는?' '저작권 문제가 있을까?'

*수많은 걱정에 누구도 읽지 않을 공개글을 쓴 것이였다. *

사설이 길지 않도록 태도를 바로 패치해보자.

• 신중히 검토하고 바로 공개를 선택하자.
• 누군가의 글에 답글을 달자.
• 누군가 찾아올 수 있도록 하자.
• 진행중인 사진을 찍자.
• AI로 쉽게 이해할 수 있는 이미지를 올리자.
• 선 이미지, 후 설명 구조로 설명하자.
• ... (계속 패치 중)

" 누군가와 함께 해보자. "

• 목표 JDK 하나만으로 자바와 프레임워크에 대한 이해도를 높인다.

"개발자가 시스템에 로직을 전달한다"

개발자는 페이지와 이벤트, 공유 데이터 이 세가지만 고려한다. 페이지 전환의 역할은 프레임워크에 맡긴다.

• 각 페이지는 다른 페이지를 직접적으로 접근하지 않는다.
• 각 페이지는 이벤트를 발생시킬 뿐이다.
• 이벤트를 수신한 프레임워크가 페이지를 전환한다.

나의 프레임워크 근간은 다형성이다.

인터페이스와 추상 클래스를 충분히 활용하여 골격을 짜두어 개발자는 규칙에 맞게 페이지와 이벤트를 개발한다.

본 프레임워크 추상화 계층엔 이벤트 발행과 수신의 역할이 숨겨져 있다.

• 비록, 페이지 간 데이터를 전송하는 부분에서 미흡한 부분이 존재하고, 리플렉션을 사용하지 않으며, 객체의 생명 주기를 관리하지는 않는다.

• 그럼에도, 개발자가 고려해야 할 점을 줄여서 생산성을 높이도록 개발자의 로직을 가져와 전체 시스템에서 활용하기 때문에 프레임워크를 이해하는데 충분히 도움이 될 것이라고 판단하였다.

교육 계획

1. v1: 기존 JavaFX 프레임워크를 Swing으로 전환 자바 초심자를 대상으로 하였다. 최근 JDK엔 JavaFX가 포함되지 않는 경우가 많다. 인터페이스와 추상 클래스로 뼈대가 잡힌 다형성, 이벤트 발행-구독 패턴으로 페이지 간 느슨한 결합, 레이어드 아키텍처로 책임을 분리, 빌더 패턴으로 프레임워크에 개발자가 작성한 로직 등록하기 등을 보여주는데 JDK만 있도록 했다.

-> 추상화에 대한 이해도 향상

2. v2: 모듈 분리 멀티 모듈의 관점으로 프로그램을 바라보게 한다. "패키지 디폴트 대신 자바 모듈 시스템 활용?" "배포의 과정에서 모듈 분리의 장점?" "모듈 간 또는 클래스 간 의존성 관계?" 등의 질문을 던질 수 있도록 계획하였다.

-> 의존성 및 모듈화, 배포에 대한 이해도 향상

3. V3: 뒤로가기, 앞으로가기 스택을 활용하여 브라우저의 뒤로가기, 앞으로가기를 이해

-> 자료구조 활용

4. v4: 다크 모드 추가 및 직접 커스텀 메뉴 추가 다크 모드는 프레임워크 유틸로써 기능을 추가할 수 있다. 개발자의 커스텀 메뉴를 추가한다.

-> 확장성에 대한 이해도 향상

이렇게 각 단계를 계획하고 개발하였다.

단순히 프레임워크를 가져와 쓰는 것이 아니라, 프레임워크의 기초를 직접 코드로 바라보며 이해하고, 직접 만들 수 있도록 경험할 수 있길 바랐다.

나는 4학년 1학기 이후에야, 위의 내용들을 체감할 수 있었다.

모쪼록 다른 사람에게 도움이 될 수 있길 간절히 바란다. 프로그램에 대한 시야를 넓힐 수 있는 기회가 될 수 있으면 되도록..

난.. 세상과 사람에 대한 시야를 넓히고 싶다. 아 맞다.. 부족하지만 함께 개발할 수 있다면 더 좋을 것 같다:D

기존 프로그램이 1년도 넘어 기억이 가물 가물하고, 최근에 개발한 위의 각 버전이 돌아가는 것을 단순하게 테스트하였고, 스윙에 대한 이해도가 부족하여 잘못된 프로그램일 수도 있지만..

나 이번엔 자신감있게 마무리 짓는다.

1. 이전에 개발한 JavaFX 싱글 윈도우 멀티 뷰 프레임워크를 고도화
2. 위의 프레임워크를 코틀린으로 개선
3. 스마트 글래스와 AI 시대를 상상하며 토이 프로젝트 개발

깃허브에서는 위의 셋(what)에 대해 개발의 길을 나아가면서 벨로그에서는 과정(how), 수필, 도움. 셋을 담아내기로 했다.

삶을 바로잡으며 내가 무엇을 하고 싶고 어떻게 이를 올바르게 추구할 수 있을지 함께 고민하며 나아가고자 한다.

1년간 다시 삶을 패치하기로 했다.

• 열정 열정
• 싹싹하게
• 정중하게
• 처음부터 조금씩 다가가기

내 삶엔 열정이 없었다.

무엇을 하고 싶은지, 무엇을 좋아하는지 몰랐던 시절이 있었다.

그 시절엔 그저 정해진 레일을 따라 살았다.

데미안을 읽고 내가 무엇을 좋아하는지 찾고 노력하기 시작했다. 틀렸을지라도 내가 가야할 길을 주변 사람들에 알리고 도움을 얻었다.

내가 걸어가던 길에 만난 사람들이 모두 선생님이었고, 함께 고민하며 소중한 인연들을 맺어나갔다.

무엇을 찾았고, 그런대로 노력하였기에 안주했나 보다 '무엇'을 찾으려는 노력만 있었을 뿐, '어떻게'란 답을 찾으려는 노력은 부족했다는 것을 지난 1년간 깨달았다.

아니, 어떻게란 답에 다가가는 과정에서 내가 걸어가는 길에 함께 고민한 사람이 없었다.

'내가 놓친 것은 없을까?' '내가 달리 바라보아야했던 것은 아닐까?'

나의 길을 걸어가며 마주친 모든 인연들은 모두 선생님이었다.

무엇에 대한 길을 찾는 과정에서 수많은 선생님들을 만나 나의 답을 찾아가기 시작했었다면

이제는 어떻게 그 길을 나아가야할지 고민하기 시작했다. '무엇'에 대한 나의 답을 찾는 과정이 1년 걸렸다.

'어떻게'에 대한 나의 답을 찾고 걸어갈 1년을 다짐했다.

열정적으로 싹싹하게 알바를 하고 그 모범의 귀감이 되는 선생님을 본받도록 노력하면서 나의 길을 걸어가기로 했다.

무엇을 찾아가는 과정에서는 강철의 연금술사의 명대사를, 어떻게에 대해 나의 답을 찾아가는 과정에서는 전자오락수호대의 명대사를.

매뉴얼이 패치에게 말했던 것처럼..

나는 나의 삶을 바로잡고자 한다. 이전에 그랬던 것처럼

배경

나의 육각형 아키텍처를 위해 컨트롤러에 인터페이스를 두기로 했다. 그 과정에서 여러 질문들이 생기고, 잘못된 지식들이 교정되었다.

나의 육각형 아키텍처 설계 과정에서

1. 컨트롤러에 인터페이스 설계
2. 인터페이스 모듈과 구현체 모듈 분리

package com.example.a;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {

    private final InputAdapterInterface controller;

    @Autowired
    public Application(InputAdapterInterface controller) {
        this.controller = controller;
    }

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

앞선 블로그의 내용처럼 육각형 아키텍처를 설계하고 있었다. 이 과정에서 황당무계한 질문들이 이어졌다.

마법처럼 스프링을 사용하고 있었기 때문이다. main 실행부터 차근 차근 간단하게 둘러보자

1. main 실행까지

1. 클래스 로더가 바이트 코드를 로드한다.
2. 바이트 코드를 검증한다.
3. 메서드 영역에서 static 블록, 변수를 초기화 준비한다.
4. 실행 엔진이 main을 실행하기 위해 Main 클래스에 처음으로 참조가 발생한다.
5. static 초기화를 수행한다.
6. main 메서드를 실행한다.
7. SpringApplication.run()을 통해 IoC 컨테이너를 초기화한다.

2. 스프팅 컨텍스트 초기화부터

SpringBootApplication 어노테이션

• Configuration - 빈 정의
• ComponentScan - 특정 패키지와 하위 패키지의 빈 스캔
• EnableAutoConfiguration - 자동 설정

1. Bean 어노테이션으로 빈을 정의한다.
2. 특정 루트 패키지로 부터 스테레오 타입, java 코드 등의 빈을 스캔한다.
3. AOP에 대해 리플렉션을 활용하여 프록시를 생성하고 컨텍스트에 등록한다.
4. 빈의 정의대로 IoC 컨테이너가 빈을 생성하고 조립하고 생성한다.
5. 내장된 톰캣에 대해서도 자동으로 DispatcherServlet를 설정한다.
6. JMS, DB에 대한 설정도 자동으로 구성한다.

3. 서블릿 컨테이너 실행부터

1. 서블릿 컨테이너가 실행된다.
2. 서블릿 컨테이너는 쓰레드를 활용하여 http 요청을 받고 디스패처 서블릿에 전달한다.
3. 디스패처 서블릿은 적절한 컨트롤러 메서드를 찾는다.
4. 요청이 컨트롤러에서 처리되기 전 인터셉트되어서 먼저 처리된다.
5. 요청에 매핑되는 컨트롤러 메서드에 요청이 전달된다.
6. 객체들과 외부 시스템들의 상호작용으로 작업을 수행한다.

추가 과정

추가로 개발과 테스트, 배포, 모니터링, 성능 테스트 등도 함께 다루어 개발과 관련된 일련의 과정을 함께 볼 수 있도록 작성했다.

1. 코드 작성, 통합 및 테스트

• 의존성을 명시하고 객체 생성 및 주입은 DI 프레임워크에게 맡긴다.

• 개발 중 테스트를 작성한다.
• 코드 통합 가능 및 테스트 통과 여부 확인은 CI 툴에 맡긴다.

1. 요청에 매핑되는 클래스, 메서드를 작성한다.
2. 로직을 처리하는 클래스를 작성한다.
3. 외부 시스템에 요청하는 클래스를 작성한다.
4. Mock 객체 등을 활용하여 단위 테스트, 통합 테스트를 작성한다.
5. 코드 통합이 적절한지 확인하고 통합하는 과정을 자동화한다.
6. 수정된 코드가 테스트를 통과하는지 확인하는 과정을 자동화한다.

2. 배포

1. jar 파일을 만든다.
2. 원격 서버에서 jar를 실행한다.
3. 컨테이너를 통해 jar를 실행할 수 있다.
4. 컨테이너 오케스트레이션을 통해 인스턴스를 관리한다.

3. 모니터링

1. 성능 메트릭을 측정한다.
2. HW 리소스, 성능 메트릭을 시각화한다.
3. 로그를 모니터링한다.

4. 성능 테스트

1. 부하테스트를 진행한다.
2. 응답 시간을 측정한다.
3. HW 리소스를 측정한다.

5. 성능 향상

1. 더 좋은 사양의 cpu, memory, disk를 고려한다.
2. 지역성을 활용한 알고리즘, 로직 등을 활용하여 HW 성능을 이끌어낸다.
3. 유효한 이전의 데이터를 캐시로 활용한다.
4. 상황에 맞는 RAID, file system를 고려한다.
5. 애플리케이션 수준의 큐나 메시지 큐 등을 대기열, 캐시 등으로 활용한다.
6. 효율적인 네트워크 프로토콜을 선택한다.
7. IO 작업에는 비동기 논블로킹을 고려한다.
8. Garbage Collection 등 런타임 성능 최적화를 고려한다.
9. SQL를 최적화한다.
10. RDB, NoSQL 등 적절한 데이터베이스를 고려한다.
11. 조회, 수정, 삭제, 삽입의 빈도를 고려하여 DB 인덱스를 설정한다.
12. 큰 문제를 작은 문제로 나누어 멀티 쓰레드로 처리한다.
13. 복합적인 작업을 나누어 생산자, 소비자 쓰레드, 블로킹 큐로 처리한다.
14. 인스턴스를 여럿으로 확장하여 작업을 분산 처리한다.
15. 불변성과 함수형 프로그래밍, 현재 상태 조작과 명령형 프로그래밍을 고민한다.

6. 보안

1. 기밀성, 가용성, 무결성을 고려한다.
2. 공개키 알고리즘으로 임시 대칭키를 교환하여 기밀성을 신경쓴다.
3. 이중화를 위해 멀티 노드로 운용하여 SPoF를 방지하고 노드 장애를 대비한다.
4. 해시 함수를 활용하여 무결성을 보장한다.
5. 재전송 공격을 방지하기 위해 타임 스탬프를 고려한다.
6. 비밀번호는 salt와 해시함수를 활용하여 저장한다.
7. 역할을 부여하여 인가 여부를 확인한다.

7. 운영 시 문제 해결 과정

1. 코드 로직을 확인한다.
2. 라이브러리, 의존성 sw 버전을 확인한다.
3. 설정 파일, 환경 변수를 확인한다.
4. 현재 블로그처럼 프레임워크의 동작 과정을 확인한다.
5. 공유 자원에 대한 멀티 쓰레드를 확인한다.
6. 로그를 확인한다.
7. HW 리소스를 확인한다.
8. JVM를 확인한다.
9. 다른 프로세스들을 확인한다.
10. 배치 처리인지 확인한다.
11. DB나 다른 외부 시스템 문제인지 확인한다.
12. 네트워크를 확인한다.

8. 문서화

1. 계획, 요구 사항 정의, 설계를 산출물로 작성한다.
2. 운영 장애를 기록해둔다.
3. 회의록을 작성한다.
4. 다음 회의에서 이전 희의록을 바탕으로 진행 사항을 점검한다.
5. 변경 사항을 추적한다.
6. JavaDoc으로 다른 사람이 코드를 쉽게 이해할 수 있도록 작성한다.
7. 문서들을 최신화한다.

9. AI 활용

1. 반복적인 형식의 틀을 작성하는데 활용한다.
2. 문서 최신화, 주석 작성 등 문서 관리에 활용한다.

10. AI 개발 (지도 학습)

1. AI 허브나 허깅 페이스 등으로 데이터와 모델을 조사한다.
2. 입력 데이터를 가공한다.
3. 출력 데이터(라벨링 데이터)를 가공한다.
4. 어떻게 벡터로 표현할 지 고민한다.
5. 학습 모델을 구축한다.
6. 비용 등을 고려하여 학습을 위한 다양한 서비스들을 고민한다.
7. 이미 학습된 모델을 가지고 있는 데이터로 다듬는다.(파인 튜닝, 미세 조정)

11. 포트폴리오

1. 발표와 결과에 대한 동영상, 사진을 찍어둔다.
2. 위의 항목들을 도전해본다.

적다보니..

'스프링 동작 과정을 간단하게 이해하자' 에서 '코드 개발, 배포, 운영까지 스프링을 다루는데 도움이 되는 것까지' 를 넘어 '학교 다닐 때 해보았으면..' 에 다다랐다.

위의 항목들 중 실제로 많이 경험해본 것은 '7. 운영 시 문제 해결 과정'이다. 멀티 쓰레드를 제외하고 조금씩 경험해본 것 같다.

그 외의 항목들은 해본 것, 해볼 것 그리고 단순 글자들로 섞여있다. 교문을 나설 때가 되어서야 비로소 보이기 시작했다. 나와 달리 컴퓨터 과학이 중요하다고 하는 것을 프로젝트에 적용할 수 있길 바란다.

문제 해결 과정 경험이 가장 많은 것은 삶의 과정이 문제를 해결하는 과정이고,

이루지 못 한 것이 많은 것은 삶을 살아가는 의미지 않을까

초보적으로 MSA로 전환하는 과정을 통해 육각형 아키텍처를 이해해보기로 한다. 육각형 아키텍처를 시작하게 된 경험부터 차근 차근 시작해보자.

보통 시작은

레이어드 아키텍처

대부분 Layered Architecture를 바탕으로 스프링 프로젝트를 시작하게 된다. 그런데 개발하다보면 육각형 아키텍처가 등장한다.

해결하고자 하는 도메인 문제를 다루는 비즈니스 로직 계층이 핵심이라고 생각했다. 레이어드 아키텍처는 비즈니스 로직이 영속성 계층 변화에 영향을 받는다.

영속성 계층에 의존하지 않는 육각형 아키텍처 설계를 보고 혹했다. 그렇게 단순하게 도전했다.

'인터페이스를 두고 영속성 계층에 대한 의존성 역전' 이 생각 하나로 프로젝트들을 진행했다.

여러 경험을 돌이켜보니 나만의 표현으로 육각형 아키텍처를 정의했다.

본격 시작 전,

의존성 주입과 모듈

육각형 아키텍처를 설명하기전에 의존성 주입과 모듈 분리를 먼저 살펴보자

Spring의 의존성 주입

• 의존성 주입 프레임워크를 활용한다면? 인터페이스와 구현체를 모듈로 분리한다면 쉽게 구현체를 바꿀 수 있다. 빌드 시스템에서 의존하는 구현체 모듈만 수정하면 되기 때문이다.

• 의존성 주입 프레임워크가 없다면? 실제 생성하고 주입하는 코드를 개발자가 작성해야 한다. 구현체를 바꿀 때 이 역시 수정해야 한다는 점이 핵심이다.

모듈 분리

• 인터페이스 모듈과 구현체 모듈 분리 위에서처럼 인터페이스와 구현체를 모듈로 분리한다면 DI 프레임워크를 활용하여 손쉽게 구현체를 바꿀 수 있다.

• 작은 규모의 핵심에 집중 여러 계층에 아우르는 의존성을 제거할 수 있다. 필요없는 책임을 다루지 않도록 도와준다.

이제 Spring 의존성 주입과 모듈 분리를 활용하여 유연한 육각형 아키텍처를 설계해보자

본론, 내가 생각하는

육각형 아키텍처는?

• 각 모듈은 인터페이스로 통신한다.

• 개발자는 '요청 접수', '도메인 로직 처리', '요청' 단위로 모듈을 구성한다.

DI 프레임워크를 활용한다면,

• 개발자는 타 모듈에 접근하기 위해 인터페이스 모듈만 활용한다. DI 프레임워크가 구현체 모듈을 활용하여 생성, 주입한다.

1. 요청 접수 다른 도메인에서 보낸 요청을 접수한다. 요청 방식은 HTTP, RSocket, 메서드 호출 등 다양하다.

2. 도메인 로직 처리 해당 도메인에서 처리할 수 있는 작업을 처리한다.

3. 요청 다른 도메인에 요청한다. DB 드라이버나 파일시스템 시스템콜, 네트워크 통신, 메서드 호출 등이 있다.

그리고 이들을 조합하는 과정에서 인터페이스를 사이에 둔다. 조합을 바꾸게 된다면 빌드 시스템에서 의존성을 수정한다.

이제 레이어드 아키텍처부터 MSA 전환까지 다루어보자.

레이어드 아키텍처에서 MSA 까지

1. 인터페이스는 -><-로 표현
2. Spring의 DI 컨테이너 활용
3. 각자 판단에 따라 모듈로 판단
4. 육각형 아키텍처 용어 대신 가급적 이전 설계 용어 활용
5. service는 다른 서버, 마이크로서비스 등을 의미

레이어드 아키텍처1

Spring MVC와 JPA를 활용한 초기 설계 Browser -><- controller -> business 로직 -> JPA repository -><- MySQL

어떤 인터페이스에 주목할까?

네트워크, 운영체제 수준의 인터페이스도 있지만, 아래의 두 인터페이스에 주목할 수 있다.

• REST API : Browser와 controller 사이
• JDBC : repository 구현체와 MySQL 사이

레이어드 아키텍처2

영속성을 추상화한 설계 Browser -><- controller -> business 로직 -> adpater -> service

MySQL 대신 service?

• MySQL이 아니라 HashMap, 또다른 DB, 마이크로서비스 등이 될 수 있다.

JPA 리포지토리 대신 출력 어댑터?

• MySQL이 아닐 수 있고, MySQL이라도 MyBatis를 활용할 수 있다.

작성된 인터페이스 코드는 없다.

• 다섯 단위 간에 있는 인터페이스는 REST API 하나다.

육각형 아키텍처

모듈 사이에 인터페이스를 둔 설계 Browser -><- controller -><- business 로직 -><- adpater -><- service

보다 유연하게 로직 전환

• 타 모듈에 접근하기 위해 인터페이스를 활용한다. 구현체 모듈 의존성만 수정하면 된다.

MSA

Browser를 추상화한 설계 service -><- controller -><- business 로직 -><- adpater -><- service

Browser 대신 service?

• 브라우저가 아니라 다른 서비스가 요청할 수 있다.

용어 정리

• 요청 -><- 요청 접수 -><- 로직 처리 -><- 요청 -><- 요청 접수

다시 모놀리식 서버

service를 도메인으로 타 domain -><- 요청 접수 -><- 로직 처리 -><- 요청 -><- 타 domain

service 대신 도메인?

• 외부 마이크로서비스 코드를 모놀리식 서버 내의 도메인으로 통합한다.

사실은 ..

MSA 전환은 위의 과정처럼 쉽게 진행되지 않는다.

크게 네가지

1. 네트워크
   • 네트워크 통신 실패는? '재시도 로직? 서킷 브레이커?'
   • 네트워크 통신으로 인한 지연 시간은?
2. 데이터베이스
   • 테이블 관계를 유연하게 설정 가능한가?
   • 테이블을 나누게 되면서 조인에 대한 성능 하락은?
   • ACID 트랜잭션은? '분산 트랜잭션? 보상 작업?'
3. 특정 인스턴스
   • 관찰가능성은?
4. 인스턴스 간 관계
   • 비동기? 동기? 이벤트 기반?

이러한 일련의 복잡성이 발생하기 때문에 이에 대한 성숙한 시스템과 서비스를 충분히 고려하고 종합하여 시스템을 설계한 후 전환해야 한다.

그렇지만

Layered Architecture 기반 Monolithic Server를 DI 프레임워크와 멀티 모듈, 육각형 아키텍처를 활용하여 전환하는 과정, 더 나아가서 적절하다면 MSA로 전환하고 이러한 복잡성을 다룰 수 있는 데 이 글이 도움이 될 수 있다고 생각한다.

잘못된 내용 알려주시면 감사하겠습니다! :)

이게 의미가 있을까 싶은 순간들이 있었다. 그 순간들은 다시 내 앞에 나타났고 한 발걸음 더 내딛을 수 있었다. 그 한 발걸음은 세상을 다르게 바라볼 수 있게 했다.

1. 비속어 우회 탐지 모듈 개발

2022.07 ~ 2022.08

직접 벡터 할당에서 부터 시작

다른 사람들은 퍼셉트론이나 학습 모델들을 다루고자 했다.

나는 모델이 무엇인지, 퍼셉트론이 무엇인지 도저히 이해가지 않았다. 나는 기초부터 다지자라는 생각이었다. '그 기초가 튼튼한 토대가 되겠지'

자모음에 벡터를 직접 할당하였다. 비슷하게 생긴 자모음, 문자, 숫자는 코사인 유사도가 높게 벡터를 할당하였다.

비속어가 담긴 말뭉치와 타겟 단어의 코사인 유사도를 비교했고 일정 수치 이상이면 비속어로 판단했다.

이 결과물은 파이썬으로 몇 줄 안되었다.

의미가 있을까..?

벡터와 코사인 유사도를 떠올리고, 스칼라 값으로 자모음을 다루다가, 자모음에 벡터를 할당하여 다루는 고된 여정의 결과물은 남들이 보기에는 별 것 없어 보였다.

2. 검색엔진 시도

2023.07 ~ 2023.08

이전보다 더 깊게

Indexing, Ranking, Querying를 이해하는 것부터 어려웠다. 그렇지만 Ranking은 반가운 부분이었다. TF-IDF로 벡터를 표현하여 코사인 유사도로 문서와 사용자 쿼리 문장에 대한 유사도 순위를 매길 수 있었다.

의미가 있을까..?

거대한 검색엔진에 비해 초라한 수준의 검색기였다. 최신 학습 모델을 다루지는 않고 이런 고전적이고 기초적인 검색을 다루는 것이 의미있을까?

3. 학대 피해 아동을 위한 sw 개발

2023.02 ~ 2023.11

일단 개발은 했는데..

이렇게 긴 시간 프로젝트를 한 적은 처음이었다. 그것도 팀장이었다.

프로젝트 진행 중 모종의 계기로 뒤늦게 삶의 가치관을 찾기 시작하였다. '난 나의 삶을 어떻게 살고 싶은 걸까?'

삶의 가치관을 확립한 순간도, 가치관을 실천한 순간도 아니었기에 팀장으로서 잘 수행했는지 자신이 없다.

다른 사람과의 경험 뿐만 아니라 기술적인 측면으로도 마찬가지였다.

일단 개발은 했는데..

JavaScript

우리는 채팅이 많으니 네트워크 IO 처리에 이점이 있다는 내용을 보고 자바스크립트로 시작했다.

개발하다보니 타입스크립트와 NestJS를 만났다. 여전히 자바스크립트를 이해하지 못 했기에 비동기로 동작할 때 난 대처할 수 없었다.

Promise, async, await은 이해가지 않았다. 난 gpt한테 의지할 수 밖에 없었다. 무력했다.

MSA

학습 모델을 활용하는 경우 독립된 다른 서비스로 개발하였다. 파이썬 기반의 기술 스택을 선정하고 개발하였다. 이때는 멋모르고 MSA라고 생각하고 진행했다.

Container

정확히는 기억나지 않지만, 그 때 당시에는 CI/CD로 배포하기 위해 컨테이너가 필요한 줄 알았다.

그래서 컨테이너를 다루기 시작했다. 0.0.0.0이 아닌 로컬 호스트로 실행해서 팀원과 고생한 한달이 생각난다.

개발은 했다.

막막한 순간 순간들을 넘기고 동작이 잘 되어 기뻤지만 마음이 복잡한 순간들이었다.

gpt한테 의존하는 무력한 순간이었고, 개발로는 미래가 없어보였고, 컨테이너나 DevOps에 대한 진로 고민은 생겼고, 내가 나아간 것은.. 또다시 한 발자국이었다.

4. 기존 검색기에 다양한 시도

2023.12 ~ 2024.02

딱 한 발자국

가용성을 위한 과정과 의미 검색 반영, 성능 테스트 등 다양한 시도를 도전해보고 배우고 싶었다.

컨테이너 오케스트레이션, Apache JMeter, Jira, 프로메테우스, 그라파나 등 다양하게 한 발자국 나아갔다. DB 이중화, 캐싱 등은 발을 내딛지조차 못 했다.

이전보다 더 깊게

단순한 TF-IDF가 아니라 의미를 반영할 수 있었다. 드디어 허깅페이스에 있는 BERT와 같은 최신 학습 모델들을 직접 사용해 보았다.

벡터를 직접 다루는 것에서 TF-IDF처럼 전문적으로 벡터를 다루는 것을 거쳐, 학습된 모델을 활용할 수 있게 되었다.

의미가 있을까..?

학습된 모델을 직접 개발한 것도 아니고, 멀티 클러스터에 멀티 노드로 진행한 것도 아니고, 제대로 부하테스트 성능 결과를 분석한 것도 아니고, 제대로 운영하고 시각화해서 모니터링한 것도 아니였다.

그렇기에 과거에 적힌 블로그 글들을 지울까 고민을 정말 많이 했다. 그렇지만, 그것은 다른 의미를 지니고 있었기에 남기기로 했다.

5. 동아리 지원

2024년 초

일상에서 새로운 도전

삶의 가치관을 확립하고 삶을 살아있게 살아가고 싶어졌다. 그렇게 동아리를 새롭게 도전했다. 자소서에는 확립된 삶의 가치관을 담았다. 면접에 갔지만 떨어졌다.

6. 다른 사람들의 삶을 둘러보며

동아리 지원 이후 얼마되지 않아

가치관 실천의 계기

수업에서 다른 사람들의 자소서를 보게 되었다. 나는 가치관을 문자로 작성했고, 다른 사람들은 저마다의 가치관이 담긴 삶을 담아내었다.

또다시 나에게 부끄러운 순간이었다. 동아리 면접에서 삶의 가치관을 실천하지 않은 삶을 평가받은 것이라고 생각했다. 동아리를 도전하고 탈락한 것은 다행이었다.

삶의 가치관을 실천할 때, 비로소 자유로워지고 삶의 의미를 찾을 수 있다고 생각하게 되었다.

내 삶의 가치관을 실천하는 것은 주변 인연들에게 이 마음이 담긴 인사와 관심뿐이었다.

이 인사만으로도 나는 삶의 의미를 찾기 시작했고, 주변 사람들에게도 변화를 주기 시작했다. 이렇게 스쳐지나가는 인연을 맺기 시작했다.

다만 여기에 반드시 한줄을 꼭 남겨야 할 것은 관성에 의해 본래의 마음가짐을 잊지 말자

7. 취업 지원

2024.12

채용 공고를 둘러보며

여러 삶의 가치관은 확립하고 있는데 직업관은 없었다.

취업 지원서를 작성할 때도 직업에 대한 뚜렷한 목표는 없었다. 면접 자기소개도 삶의 가치관과 그에 대한 노력을 말하는 것을 생각했다.

채용 공고를 보기 위해 둘러보던 중 단순 명문화된 미션과 비전이 아니라 회사의 가치관이 담긴 채용 공고 페이지들을 보게 되었다.

그곳에 담겨있는 실천 의지와 노력에서 느껴지는 인상은 회사에서 추구하는 가치관이 확고하게 느껴졌다.

미션, 비전이 아닌 가치관. 사람이 아닌 회사. 이에 대해 생각하게 되었다.

나의 개발자로서의 가치관을 확립하게 된 계기였다. 다시 올해 초로 돌아가서 살아온 삶의 과정을 살펴보고 개발자로서의 마음가짐을 다져보자

8. 블록체인 활용 의료 관리 SW 개발

2024.02 ~ 2024.06

또다시 새로운 도전?!

블록체인에 의료 데이터 해시값을 저장해보기로 했다. 의료 질의응답에 대한 맞춤형 설명을 위해 RAG 또한 기획하였다. 육각형 아키텍처를 도입하고자 하였다.

의미가 있을까..?

블록체인

블록체인을 검색기처럼 아주 단순히 개발해보았다. 블록체인이라고 부르기도 어려운 수준이긴 했지만 노력했다. 프로젝트에 사용되지는 않았지만 개인적으로 개발했다.

육각형 아키텍처

DB에 의존하는 비즈니스 로직 방향을 역전하고자 도입하였다. 전문적이지 않았기에 자신이 없었다.

이전보다 더 깊게

한편, 검색이 RAG로 새롭게 등장하였다. LLM의 환각과 최신화되지 않은 문제에 대한 완화책으로 등장하는 RAG. 고전적이고 기초적인 검색의 경험이 최신의 RAG에 대한 이해를 높였다.

조금씩 조금씩 나아가고 있었다.

9. 기존 서버에 대한 새로운 시도

2024.07 ~ 2024.09

또다시 새로운 도전?!

기존의 서버를 대대적으로 감축하고 여러 새로운 시도를 도전했다. 또한, 그에 대한 일반 유저 기능 포함 운영자 프론트엔드 개발을 시도했다.

이전보다 더 깊게!

육각형 아키텍처

육각형 아키텍처의 DTO 의존성, 엔티티 간의 유연한 관계 설정 등 육각형 아키텍처에 좀 더 심도있게 다가갔다.

멀티 모듈 도입

JavaFX에서 멀티 모듈을 적용했고, 이는 백엔드에서 모듈러 아키텍처 시도로 이어졌다.

이는 중도에 포기하고 이후 MSA 전환 프로젝트가 진행되었지만, 그 자체로 모듈러 모놀리식에 대한 첫 발자국이 되었다.

스프링

JavaFX에서 스프링을 도입했고, 스프링의 정체성에 대해 생각해보게 되는 계기가 되었다.

병렬 프로그래밍

중도 개발 중단이 되기는 했지만, 부하테스트에 대한 AtomicInteger와 CompletableFuture, 로그 분석에 대한 생산자와 소비자 쓰레드, 블로킹 큐에 대해서도 고려해볼 수 있는 순간이 되었다.

10. 스칼라 시도

2024.10

또다시 새로운 도전?!

간결한 표현, 불변성, 분산 병렬 컴퓨팅 등 스칼라에 매료되었다.

그래서 창시자가 작성한 책을 고민 끝에 구매하며 빠르게 훑어보고 개발하고자 했다.

그런데 팀원과 같이 고민하기 어려웠던 타입스크립트, 팀원과 같이 할 수 있는 MSA 프로젝트, 취업 시기에 쉽게 볼 수 없는 스칼라 등 도전에 대한 마음을 금방 접게 되었다.

이전보다 더 깊게!

Java의 방향성?

Java switch 표현식과 instanceof가 보였다. 이것은 스칼라에 대한 패턴 매칭을 떠오르게 했다.

또한 Java의 함수형 인터페이스, 람다, 스트림을 넘어서 Record, switch 표현식, instanceof는 함수형 프로그래밍에 대한 의지를 보여주는 것인가 생각하게 만들었다.

고차함수와 리플렉션

이후, 스칼라의 경험은 최근에 블로그 글로 다시 등장했다. 스칼라에서 잠시 마주친 고차함수와 함께 Java의 리플렉션, 프레임워크를 들여다 볼 수 있었다.

한편, 컨테이너

한편, 모던 리눅스에 대해서 알게 되는 활동도 이 시기에 도전했다. 그로 인해 알게 된 것은 cgroups와 namespace였다.

cgroups를 통해 cpu, memory, network를 제어하고, namespace를 통해 프로세스 목록에 대한 가시성을 제어한다는 것을 알게 되었다.

이전의 컨테이너 경험은 현재의 리눅스에 대한 이해도를 높일 수 있는 경험이 되었다.

11. MSA 전환

2024.11 ~ 현재

또다시 새로운 도전?!

팀원들과 MSA에 대해 알아보기 위해 또다시 새로운 도전장을 내밀었다.

이전에는 여러 서비스만 있으면 되는 줄 알았다. 네트워크 성능, 통신 실패, DB ACID, 관찰 가능성 등 복잡한 인스턴스 관리를 고려하지 못 했기에 이번에는 MSA의 복잡성과 장점을 판단할 수 있는 시간이 되길 기대하고 있다.

또, CI/CD에 k6를 통합하고 팀원과 공유하려는 새로운 도전을 하고자 한다.

이전보다 더 깊게

최근에 블로그에 작성한 JVM 성능 테스트를 위한 JIT 컴파일, 자바스크립트 엔진의 동작과 JavaFX, 고차 함수와 리플렉션에 대한 글을 돌이켜보면 확실히 조금씩 나아가고 있다고 확신한다.

좀 더 풀어내고 싶지만 문장력이 한계에 다다라서 여기쯤 마무리 짓기로 했다.

의미가 있을까..?

라는 질문은 매번 던지게 된다.

깊이 없는 도전으로 끝났을지라도 의미없는 과정은 아니였다.

벡터 직접 할당, 고전적 기초 검색기, 컨테이너, MSA, 자바스크립트, JavaFX 등 내 과거는 다시 내 앞에 나타났다.

그리고 다시 등장할 때는 나를 좀 더 성장하게 만들었다. 절대 의미 없는 시간은 없었다.

언제가는 다시 돌아왔고 한 발자국 나아갔고 그 한 발자국은 세상을 다르게 바라볼 수 있게 했다.

개발자로서의 가치관?

아무리 사소한 도전이라도 의미없는 도전이 아니다.

삶을 바꿀 수 있기에 도전은 신중해야 하지만, 아무리 사소한 도전이라도 의미없는 도전은 없다.

+
"세상을 넓게 바라보고, 사람을 깊이있게 이해하자."

로직을 전달..?

간단하게 Reflection과 고차함수의 일부분을 바라보고 Spring의 IoC와 AOP를 이해해보자

작성 시점에 없는 코드 실행?

고차함수

고차함수는 함수를 매개변수로 받을 수 있다. 그럼 작성 당시 없는 함수를 매개변수로 전달받아 실행할 수 있다.

function framework(future_action) {
  future_action(1)
}

now = a => a + 1;
framework(now)

Reflection

리플렉션은 실행 중에 클래스와 메서드를 조회하고 실행할 수 있다. 그럼 작성 당시 없는 클래스를 실행하고, 메서드를 수정하여 실행할 수 있다.

Object framework(String futureClassName) throws Exception {
    Class<?> clazz = Class.forName(futureClassName);
    Object obj = clazz.getDeclaredConstructor().newInstance();
    return obj
}

Spring의 AOP도 고차함수를 통해 이해?

고차 함수

function aop(전처리 함수, 후처리 함수, future_action) {
  전처리 함수()
  future_action()
  후처리 함수()
}

또는

function aop(전처리_함수)(후처리_함수)(future_action) {
  전처리_함수()
  future_action()
  후처리_함수()
}

start = 트랜잭션_시작_로직
end = 트랜잭션_끝_로직

transaction = aop(start)(end)

transaction(비즈니스_로직)

Reflection

Object aop(Method method, Object[] args) throws Throwable {
    // 전처리
    Object result = method.invoke(target, args);
    // 후처리
    return result;
}

이제 다시 Spring의 동작 과정을 이해해보자

개발자는 처리해야 할 로직만 작성한다. 로직을 처리하는 것은 프레임워크가 담당한다. 객체를 적절히 생성하여 원하는 곳에 주입하는 것도, 메서드 로직 전후로 원하는 관심사를 수행하는 것도 프레임워크가 담당한다.

기존에 수행하던 생성부터 결과값을 직접 다루는 과정과는 전혀 다르다. 하지만 처음 맞닥뜨렸을 때 보기에는 비슷하다. 어떻게 작동하는지 혼란스러운 것은 당연할 수 있다.

미리 작성된 코드에 개발자가 작성한 로직을 넘겨주면 미리 작성된 코드가 로직을 알아서 처리한다.

틀린 내용 알려주시면 감사하겠습니다! :)

GUI를 다루는 JavaFX와 브라우저에서 동작하는 JavaScript 엔진을 살펴보고 나서 Node.js의 동작 과정도 이해해보자.

간단하게 바라보자

싱글 쓰레드만 고려해보자

JavaFX

1. 버튼 클릭과 같은 이벤트가 발생하면 큐에 순차적으로 저장된다.
2. 이벤트 루프가 큐에서 차례로 이벤트 핸들러를 활용하여 이벤트를 처리한다.

JavaScript

1. DOM 작업과 같은 이벤트가 발생하면 누군가에게 작업을 맡기고, 작업의 결과를 큐에 순차적으로 저장한다.
2. 이벤트 루프가 콜 스택이 비어있는지 확인하고, 비어있다면 큐에 있는 작업의 결과를 콜 스택에서 처리한다.

좀 더 들여다보자

멀티 쓰레드도 고려해보자

JavaFX

멀티 쓰레드로 작업을 처리할 수 있다. GUI 공유 자원 접근 문제로 UI 표현은 싱글 쓰레드만이 담당한다. 멀티 쓰레드의 작업의 결과를 큐에 삽입한다. 삽입된 큐를 처리하는 과정은 위와 같다.

JavaScript

엔진 밖에 있는 별도의 쓰레드로 비동기 작업을 수행한다. 작업의 결과를 싱글 쓰레드로 처리해야 하기 때문에 처리된 작업 결과를 큐에 삽입한다. 삽입된 큐를 처리하는 과정은 위와 같다.

표현을 정리해보자

JavaFX

이벤트 발생 시 큐에 이벤트를 삽입한다. 비동기 백그라운드 쓰레드들로 발생한 이벤트는 Platform.runLater()를 통해 큐에 저장된다. 이벤트 루프를 통해 순차적으로 이벤트 핸들러를 실행하여 큐에 저장된 이벤트를 처리한다.

JavaScript

동기적으로 콜 스택을 처리한다. 비동기 IO 작업이 발생하면 자바스크립트 엔진 밖에 있는 web API들에 작업을 맡긴다. 작업의 결과, 콜백 함수는 큐에 삽입되고 콜 스택이 비어있다면 이벤트 루프가 큐에 저장된 콜백 함수를 콜 스택에서 실행하도록 한다.

Node.js

비동기 IO 작업이 발생하면 백그라운드 쓰레드 풀에 작업을 맡긴다. 작업을 마치면 그 결과를 큐에 저장한다. 콜 스택이 비어있다면 이벤트 루프가 큐에 저장된 콜백 함수를 콜 스택에서 실행하도록 한다.

이때의 백그라운드 쓰레드 풀은 libuv 라이브러리를 통해 다루어진다. 비동기 IO 작업에 특화되어있다.

JavaFX를 다루면서 JavaScript 동작 과정도 이해할 수 있을 것 같아서 정리했는데 잘못된 내용 알려주시면 감사하겠습니다! :)

이번 글은 질문 글이다. 답은 없고 오히려 질문을 찾아가는 과정이다.

테이블들이 흩어진다면?

테이블 간의 관계를 유연하게 식별자로 설정하여 여러 마이크로서비스에 테이블들을 나누어 다룬다면 어떠한 점을 고려해보아야할까?

1. 조회 성능

여러 서비스 단위로 나눈다면 네트워크 통신 시간을 고려해야 한다. 조인을 DBMS가 아닌 애플리케이션 수준에서 다루어야 한다.

2. ACID 트랜잭션

이전에는 하나의 DBMS로 비교적 단순하게 ACID를 수행할 수 있었다. 여러 서비스로 나누어진다면 어떻게 해야 할까?

또 무엇을 고려해야 할까? 지금 생각나는 것은 잠금이다.

3. 잠금

잠금에선 어떠한 문제가 있을까?

과연 MSA가 이러한 문제를 넘어서는 장점이 있을까?

저와 함께 질문을 찾고 그 질문에 대해 생각해보는 시간을 가져보는 것을 어떨까요? :)

그냥 Apache JMeter 실행하면 안돼?

안된다.

요청 수 100이 1000보다 오래?

팀원이 부하테스트 진행 중 요청 수를 100에서 1000으로 늘렸는데 100이 더 오래 걸렸다고 한다.

왜일까?

원인 후보는 여러 가지가 있겠지만, 나는 JVM 동작 과정이 먼저 생각났다. 다른 팀원은 Spring의 쓰레드 생성 과정 등 Spring에 대한 이해도 필요하다고 알려주었다. (이것은 생각조차 못 했다.)

또한 쓰로틀링 등의 HW 실행 속도의 문제일 수도 있다. 프로세스 간의 hw 리소스에 대한 자원 경쟁도 고려해야 한다. 윈도우에서 서버 응답 시간이 수만배 이상 느려진 문제를 겪었던 경험도 있었기에 원인을 찾는 것은 쉽지 않을 것이라 예측된다.

HW부터, OS, 실행 프로세스, JVM, Spring, Apache JMeter까지 문제의 원인을 찾는 것은 험난 할 것으로 예상된다. 가장 가능성이 있는 JVM, Spring, Apache JMeter로 원인을 한정하고 문제의 원인을 찾아보고자 한다.

해당 포스트에서는 JVM의 일부 JIT 컴파일 이해를 다루어 보기로 했다.

JIT 컴파일?

JVM의 JIT 컴파일러가 실행 중에 바이트코드를 네이티브 코드로 변환하여 수행한다. 즉, 처음에는 인터프리터 방식으로 실행하지만 실행 중에 자주 실행하는 바이트코드를 최적화하여 네이티브 코드로 변환한다.

가상 머신의 인터프리터 방식에 비해 네이티브 코드로 실행하는 과정이 더 빠르다.

따라서 초기 실행 속도와 최적화된 코드 둘 중 어느 코드로 실행하는지에 따라 실행 속도가 다르다. 신중히 고려해야 예측 가능한 결과를 취할 수 있다.

어떻게 해야 할까?

아직 팀원들과 답을 찾고 있지만, 현재 생각중인 방안은 프로그램을 충분히 실행하여 네이티브 코드로 변환된 이후에 성능 테스트를 실행하는 것을 고려하고 있다.

왜 자바는 JIT 컴파일?

C, C++ AOT 컴파일

Java는 한번 작성 후 어디서든 실행하는 것을 목표로 하였다. C, C++ 언어는 실행하는 컴퓨터 시스템에 맞추어 컴파일해야 한다. 각 네이티브 코드는 다르기 때문에 컴파일된 코드는 다른 시스템에서 작동하지 않을 수 있다.

자바의 인터프리터 방식

이에 자바는 인터프리터 방식을 선택하였다. 바이트코드인 중간 코드로 변환하고, 이를 JVM이 설치되어 있으면 실행될 수 있도록 하였다.

하지만 인터프리터 방식은 한줄 씩 가상 머신이 해석하고 다시 네이티브로 실행하게 된다. 속도의 측면에서 이점이 낮다.

자바의 JIT 컴파일

인터프리터 실행 속도에 대한 비효율로 인해 실행 중에 네이티브 코드로 변환한다. 자바는 이러한 이유로 느리게 시작하게 된다.

자바의 AOT 컴파일

자바의 초기 실행 속도를 더 빨리 할 수 있도록 자바도 AOT 컴파일을 지원한다. 처음부터 네이티브로 실행하니 JIT 보다 성능이 좋다고 할 수 있을까?

그렇다고 단정하기는 어렵다.

JIT 컴파일은 단순히 실행 중에 네이티브로 컴파일하는 것이 아니다. 실행 통계를 반영하여 최적화한 후 동적 컴파일이 수행된다.

실행할수록 최적화가 점차 진행되어 실행 속도가 더 빨라질 수 있다. 최적화가 적용되지 않는 경우는 인터프리터 방식으로 실행된다.

그럼 CI/CD에선?

JIT 컴파일은 느리게 시작한다. 여러번 재시작하는 CI/CD에서는 최적화가 되어도 최적화 전으로 돌아가기 쉽다. 그렇기 때문에 AOT 컴파일을 고려하는 것이 합리적일 수 있다.

그럼 JVM에선 JIT만 고려?

Garbage Collection?

안타깝게도 Garbage Collection역시 JVM 실행에 중요한 요소이다. 성능이 개선되고는 있지만 여전히 stop the world에 대해 고려해보아야 한다.

Garbage Collection은 성능 평가에서 고려해야 할 중요한 요소로 판단된다. 이것은 좀 더 알아보고 기회가 된다면 작성하기로 한다.

틀린 내용은 수정해주시면 감사하겠습니다 :D

다시 시작

이번 글에선 이전의 블로그를 반성해보고 새로운 작성 기준을 담기로 했다.

블로그를 쓰는 동기

다양한 시도를 도전하며 다른 사람들에게 도움이 될 수 있도록 블로그를 시작한다.

누군가가 볼 땐 당연한 동기라고 생각할 수 있지만, 이전의 동기와 다르다.

이전에는 목표를 많이 계획하고 실패하는 과정을 담아내려고 했다. 나의 작은 발걸음이 누군가에겐 높은 벽으로 보이고 싶지 않았기 때문이었다. 누구나 할 수 있다는 작은 위로가 되기를 바랐다. 그 위로가 흔들리는 마음을 다잡을 수 있는 기회가 되기를 바랐다.

하지만 그 글을 다시 읽어보니 다른 사람들이 읽기 어려운 글이였다. 많이 생략된 개인 일기에 가까웠다.

수정하고 싶은 마음이 많지만, 그때의 동기가 담긴 그 나름대로의 모습을 그대로 두고 싶었다.

이전의 부족함을 보완해서 새롭게 도전하는 내용들로 써내려가려고 한다.

세가지 보완

1. 하나의 글에 내용을 온전히 담아내자. 이전에는 한 시리즈에서 작은 단위로 글을 나누어 이어나갔다. 어느 하나의 글만 보아서는 이해가 어려웠다. 이번에는 하나의 글만 보아도 이해할 수 있도록 작성하려한다.

2. 관련 내용을 충실히 담아내자. 이전에는 부족함을 여실히 드러내려고 했다. 내용 자체가 부족하여 지식을 얻기는 어려웠다. 이번에는 여러 관련 내용들을 충실히 담아내어 배워가는 것이 있도록 작성하려한다.

3. 내가 아닌 다른 사람의 시선에서 글을 작성하자. 이전에는 나의 시선으로 작성하다보니 생략된 부분이 많았다. 생략된 부분이 많다 보니 의도와 달리 읽힐 여지가 많았다. 남이 가질 의문, 호기심을 가지고 그에 대한 자문자답을 진행해보고자 한다.

결국 다른 사람들이 이해하기 쉬운 글을 작성하여 도움이 되는 글을 작성하고자 한다.

MSA, 성능 분석 등 다양한 시도들을 진행해보고 도움이 될 수 있는 글을 작성할 수 있기를 희망한다. :)

검색기 운영 여정을 마무리 짓는 글

프로젝트가 끝나고 돌아온 후기에 대해 작성해보고자 합니다.

많은 욕심을 가지고 시작했고 많이 노력했지만 많이 못 했습니다.

그래도 팀원들과 많은 것을 배우며 소중한 순간들이었습니다.

위안과 위로에 대한 소망

이 블로그를 작성하는 것은 누군가에게는 위안과 위로가 되었으면 하는 소망에서 작성하게 되었습니다.

제가 한 보잘 것 없는 순간들이 누군가에게는 큰 벽이라고 느낄 수 있다고 생각되었습니다. 제가 다른 사람들을 보며 좌절을 많이 하고 용기를 내지 못 했기 때문입니다.

그래도 용기를 내어 커다란 벽과 같았던 것들에 도전했고, 발 한자국 내딛었습니다. 정말 많이 노력해서 발 한자국 내딛는 것에 불과했지만 중요한 것들을 알게 되었습니다.

커다란 벽이 아니라 커다란 산이었다는 것, 그리고 나의 발 한자국은 누군가에겐 큰 벽처럼 느껴질 것이라는 것

다른 사람들도 저의 고군분투하는 과정을 보며 위로되기 소망합니다. 제가 헤르만 헤세 '데미안'의 싱클레어를 보고 '나만 방황하는 것은 아니구나.'라고 위안을 얻었던 것처럼..

지금부터 저는 새로운 출발을 하고자 합니다. 너무나도 부족한 것에 좌절하고 자신감을 잃었지만 그저 씩씩하게 마음을 다잡고 나아가고자 합니다. 부족한 첫 장을 읽어주셔서 감사합니다 :D

함께 고민하는 순간

'보지 못 한 것은 무엇일까? 잘못 보았던 것은 아닐까?' '잘 왔으니 그대로 나아갈까? 옆길로? 되돌아갈까? 아니면 ... 잠시 멈춰설까?'

함께 고민하는 순간을 가지고 싶은 마음과 함께 velog를 시작하였다. velog에서 나의 과정을 남들과 공유하고 배워가고 싶었다.

또다른 목표가 생겼다.

"남들에게 작은 위안을 줄 수 있는 글을 쓰고 싶다."

내가 내딛은 작은 발걸음들이 누군가에게는 큰 벽이라고 느낄 수 있다고 생각되었다. 내가 다른 사람들의 프로젝트들을 보며 좌절했었기 때문이었다. '아, 나도 저런 활동을 해야 하는데.. 할 수 있을까..?'

커다란 벽과 같았던 것들에 도전해서 커다란 산에 발 한자국 내딛었다. 한 발자국 내딛는 것에 불과했지만 중요한 것들을 알게 되었다.

가장 중요한 것은

커다란 벽이 아니라 커다란 산이었다는 것, 그리고 나의 한 발자국은 누군가에겐 큰 벽처럼 느껴질 것이라는 것

다른 사람들도 나의 과정을 보며 위로와 위안, 격려가 되기를 희망한다. 위로를 얻고 다시 의지를 다질 수 있길 희망한다.

방황하던 내가 헤르만 헤세 '데미안'의 싱클레어를 보고 '나만 그러는 것은 아니구나..'라고 위안을 얻은 것처럼..

언젠가 나도

나의 산의 정상에 오르지 않을까? 지금은 어디로 가야할 지 모르기 때문에 이리 저리 도전을 하고 있지만, 그 모든 순간들이 결국 나의 삶 등반을 위해 나를 만들어가는 여정이라고 생각한다.

50여일간 NLP 모델 적용부터, 개발, 컨테이너, 오케스트레이션, 부하테스트, 모니터링 등 다양하게 경험해보았습니다.

그 과정에서 계획했던 것들 중 진행하지 못 한 것들이 많았습니다. 데이터베이스 이중화, MongoDB, Redis, 로그 관리 등을 하지 못 하였습니다. 진행한 것들도 단순하게 다룬 것에 불과해서 아쉬움 보단 불안함이 컸습니다.

일단은 여기서 잠시 마무리를 지으려고 합니다. 다른 급한 것들을 먼저 하고 이후에 두고 간 것들을 돌이켜와서 다시 시도하고 깊이있게 진행하고 싶습니다. 검색기 추가 개발, 이중화와, Redis, MongoDB를 꼭 해보고 싶습니다.

한편, 팀원분들과 여러 가지 내용들을 공유하면서 다양한 경험들도 하였습니다. 프로젝트에 대한 협업이 이루어졌기 보단 스터디식으로 진행되었는 아쉬움도 있지만 같이 하였기에 흔들지 않고 즐겁게 여기까지 올 수 있었다고 생각합니다. 소중한 순간이었습니다.

1. 남기고 가는 것들 MHA, Redis, MongoDB, 로그 관리, k8s 전과정 적용

2. 진행한 것들 k8s에 기존 검색기 적용, 스케일링, 모니터링, 부하테스트

3. 하고 싶은 것들 검색엔진 개발, 데이터베이스 이중화, Redis, MongoDB, 성능 비교

마무리 지으면서

다양한 경험들을 할 수 있는 소중한 기회였습니다. 불안한 마음도 있지만 다음에 좀 더 노력해보며 더 발전한 모습이 되길 희망하고 있습니다.

더 심도있게 진행할 계획은 아직 없고
완전 마무리 된 것 같습니다.

그렇지만 이때의 경험은 이 순간에 끝난 것이 아니라
이후에도 계속 이어지고 있습니다.

현재는 Java에서 부하테스트에 대한 이상 수치를 해결하기 위해 
JVM, Spring, Apache JMeter를 이해하려고 앞두고 있습니다.

깊이는 없었더라도 
중요한 여정이었습니다. :D

안정적 운영을 위해 각 노드들의 자원 사용량을 모니터링하고 싶어서 계획하였습니다. 부하테스트 시, 노드의 상태를 관찰해보고 싶었습니다.

실습 과정

팀원을 따라 해당 부분을 진행하여 실습 과정을 따라하였습니다.

1. 파이썬 파일에서 측정 대상 설정 측정 대상: 요청 처리 시간, 문서 수, 오류 발생 횟수 rank service에서 처리하는 과정에 대해 측정 대상을 설정하였습니다.

2. 로컬로 prometheus, grafana 실행 1) 측정하고 싶은 대상을 prometheus.yml로 작성 2) 그라파나로 프로메테우스 연동 3) 대시보드 표현

두고 가는 것

k8s에 Prometheus, Grafana 적용 redis, mongoDB 등 로컬로 다양하게 진행 후 다시 k8s로 돌아오기로 하였습니다. 이번 실습 때 바로 적용하려 했지만 그것이 쉽지 않았습니다.

k8s에 적용하는 과정에서 어려움을 겪는 가장 큰 이유는 다루어야 할 것이 너무 많아져 문제가 발생했을 때 원인 후보가 많아졌기 때문입니다.

하나 하나 줄여가는 과정을 하기에도 많은 과정이 뒤따르기 때문에 일단 로컬로 다른 과정들을 진행한 뒤에 다시 k8s에 적용하기로 마음먹었습니다.

마무리 지으면서

실행하는 것을 넘어서 부하테스트하고 모니터링까지 다양하게 적용해보았습니다.

다양하게 경험해보는 것은 좋았지만 하나 하나 깊이 없이 둘러본 것에 불과한 것 같아 불안한 마음이 듭니다.

깊이있게 다룰 하나를 정해서 노력해보아야겠다는 생각을 하게 되었습니다.