정수의 코닥코닥

오픈클로(OpenClaw) 왜 쓰는가?

integerJI — Wed, 25 Mar 2026 16:38:33 +0900

오픈클로(OpenClaw) 왜 써야 할까

GPT vs Claude, 비용과 운영 구조 정리

이 글은 오픈클로를 사용하면서 정리한 글이다.
비전공자 기준으로 최대한 쉽게 풀어봤다.

정리 글이라 틀린 부분이 있을 수도 있다.
잘못된 내용이 있다면 댓글로 알려주면 확인 후 반영하겠다.

오픈클로가 뭐냐면

오픈클로는 AI가 컴퓨터를 직접 조작하게 만드는 시스템이다.

예를 들어

검색해서 정보를 정리해준다
웹사이트에 접속해서 클릭한다
글을 작성하고 전송까지 수행한다

이 모든 과정을 사람이 아니라 AI가 대신 처리한다.

즉,
AI를 사용하는 수준이 아니라
AI에게 일을 맡기는 구조다.

언제 쓰면 좋냐

오픈클로는 아래 같은 상황에서 특히 유용하다.

반복적인 웹 작업이 많은 경우
매일 같은 데이터를 수집해야 하는 경우
여러 단계를 거치는 작업을 자동화하고 싶은 경우
AI를 “답변 도구”가 아니라 “실행 도구”로 쓰고 싶은 경우

문제는 비용이다

오픈클로를 사용하려면
GPT나 Claude 같은 모델이 필요하다.

기존에는 대부분 토큰 기반 과금으로 운영했다.

이 구조는

요청을 보낼 때마다 비용이 발생한다
사용량이 많아질수록 비용이 계속 증가한다

특히 자동화를 실행하면 비용이 빠르게 누적된다.

실제로 사용해보면 생각보다 훨씬 많은 비용이 발생한다.

정리하면
오픈클로의 가장 큰 진입 장벽은 “비용 구조”다.

GPT vs Claude 비교

Claude

자동화 연동 시 토큰 기반 과금이 필요하다
사용량이 많아지면 요청 제한이 발생한다

장점

결과 품질이 높다
비교적 안정적인 응답을 제공한다

단점

장시간 자동화 운영에 불리하다
비용 예측이 어렵다

GPT (추천)

최근에는 GPT를 구독형 기반으로 활용하는 방식도 가능해졌다.

따라서

월 고정 비용으로 운영 가능하다
사용량이 많아도 비용 부담이 비교적 안정적이다
자동화 환경에 더 적합하다

오픈클로를 실제로 운영하려면 GPT가 더 유리하다.

클로드의 새로운 기능

최근 클로드에서도
오픈클로와 유사한 행동형 AI 기능이 출시됐다.

비전공자 입장에서는 접근성이 좋은 구조다.

하지만

자동화 기준에서는 여전히 토큰 기반 과금 구조다
사용량이 많아지면 요청 제한이 발생한다

따라서
간단한 테스트나 체험에는 적합하지만 지속적인 자동화 운영에는 한계가 있다.

그럼에도 불구하고 클로드를 고려할 이유도 있다.

새로운 기능이 빠르게 추가되고 있다
향후 더 안정적인 서비스로 발전할 가능성이 있다
보안 측면에서도 강점을 가진다

현재 기준에서는 GPT가 실용적이지만
장기적으로는 클로드도 충분히 고려할 수 있는 선택지다.

왜 맥미니를 사용하는가

오픈클로는 지속적으로 실행되어야 정상적으로 동작한다.

중간에 시스템이 종료되면 자동화도 함께 중단된다.

상시 실행 가능한 장비가 필요하다.

또한 보안 측면도 중요하다.

오픈클로는 컴퓨터를 직접 조작하는 구조이기 때문에
개인이 사용하는 파일, 사진, 문서 등에도 접근할 수 있다.

이런 이유로 메인 PC와 분리된 환경에서 운영하는 것이 안전하다.

그래서 별도의 장비인 맥미니를 따로 구성해 오픈클로 전용으로 사용하는 방식을 선택한다.

윈도우 데스크탑 단점

전력 소모가 크다
장시간 운영에 비효율적이다
하드웨어 비용이 상승하고 있다

맥미니 장점

전력 소모가 낮다
가격 대비 성능이 안정적이다
발열과 소음이 적다

이러한 이유로
오픈클로 운영 장비로 맥미니를 많이 선택한다.

실제 운영 구조

기본 구조는 다음과 같다.

집에 맥미니를 설치한다
오픈클로를 설치한다
24시간 실행 상태를 유지한다
외부에서 명령을 전달한다

명령 전달 방식

텔레그램
디스코드
n8n 같은 자동화 도구

이 구조를 구성하면
사용자는 외부에서 명령만 내리고
실제 작업은 내부 시스템이 수행한다.

단점도 있다

오픈클로는 강력하지만 단점도 분명 존재한다.

초기 설정이 어렵다
오류가 발생하면 직접 해결해야 한다
완벽하게 사람처럼 동작하지는 않는다
나의 개인 정보와 파일들의 보안이 위험하다.

따라서
완전 초보보다는
기본적인 개념을 이해한 상태에서 접근하는 것이 좋다.

정리

오픈클로는
AI를 단순한 대화 도구가 아니라
실제로 일을 수행하는 시스템으로 바꿔준다.

중요한 것은 모델 선택이다.

Claude: 체험 및 제한적 사용에 적합하다
GPT: 실제 자동화 운영에 적합하다

안정적으로 운영하려면 맥미니 같은 저전력 장비를 사용하는 것이 효율적이다.

결국 오픈클로는 단순한 자동화 도구가 아니라
AI를 실제 노동력처럼 활용하고 싶은 사람에게 맞는 도구다.

OpenClaw: access not configured.

integerJI — Tue, 17 Feb 2026 17:13:59 +0900

이 에러가 계속 뜨는 사람들에게

설정을 하며 텔레그램으로 코드를 등록하라고 올것이다.

저 인증 코드를 오픈클로에 저장하면 되는데

자꾸 등록이 안되는 것이었다.

openclaw pairing approve telegram <인증번호>

도커 안에 들어가서 명령어를 치면

OpenClaw: access not configured.

자꾸 해당 에러가 나올 것이다.

컨테이너에 들어가 보면

openclaw.mjs
package.json

해당 파일들로

openclaw 바이너리가 아니라 openclaw.mjs 실행 구조이다.

따라서

node openclaw.mjs pairing approve telegram <인증번호>

이렇게 해줘야 한다

왜 0.1 + 0.2는 0.3이 아닐까?

integerJI — Sat, 13 Dec 2025 17:23:30 +0900

최근에 유튜브를 보다 재밌는 걸 발견했다.

https://www.youtube.com/watch?v=-GsrYvZoAdA&list=LL&t=6s

코딩애플님의 영상이다.

영상에서는 자바스크립트에서 1.1 + 0.2를 계산했는데, 결과가 정확히 1.3이 아니라는 이야기가 나온다.

한번 알아보자

코드 짜보기

public class Main {

    public static void main(String[] args) {

        double a = 0.1;
        double b = 0.2;
        double sum = a + b;
        double target = 0.3;

        System.out.printf("0.1 + 0.2 계산값 : %.20f%n", sum);
        System.out.printf("      0.3 리터럴 : %.20f%n", target);

        System.out.println(sum == target);
        System.out.println(sum > target);
    }
}

0.1 + 0.2 계산값 : 0.30000000000000004000
      0.3 리터럴 : 0.30000000000000000000
false
true

프린트로 소수점 20자리까지 내려가서 보면,

두 값이 이미 다르다는 걸 확인할 수 있다.

0.1 + 0.2의 결과가 0.3보다 아주 조금 더 큰 값으로

그래서 == 비교는 실패하고,

sum > target은 true가 된다.

정말 내부 값이 다른가?

앞에서는 소수점 아래를 길게 출력해서 두 값이 다르다는 건 확인했다.

저장된 값 자체가 다른 건가?

Double.toHexString()을 사용하면

double 값을 IEEE 754 기준의

16진수 표현으로 볼 수 있다.

10진수 말고 16진수로 봐보자

System.out.println("0.1 + 0.2 (hex) : " + Double.toHexString(sum));
System.out.println("0.3       (hex) : " + Double.toHexString(target));

0.1 + 0.2 (hex) : 0x1.3333333333334p-2
0.3       (hex) : 0x1.3333333333333p-2

두 값은 아예 다른 값으로 저장되어 있었다.

0.1 + 0.2 → ...33334
0.3 → ...33333

즉, 이 문제는 출력 방식의 문제가 아니라,

처음부터 메모리에 저장된 값이 달랐던 것이다.

그래서 == 비교가 실패하는 건 당연한 결과였다.

그러면?

금액, 포인트, 정산처럼

조금의 오차도 허용되지 않는 영역에서는

double 비교 자체가 위험하다.

이럴 때는 BigDecimal을 사용하면 된다.

BigDecimal bd1 = new BigDecimal("0.1");
BigDecimal bd2 = new BigDecimal("0.2");
BigDecimal bdSum = bd1.add(bd2);
BigDecimal bdTarget = new BigDecimal("0.3");

System.out.println("BigDecimal 계산값: " + bdSum);
System.out.println("결과가 0.3과 같니? -> " + bdSum.equals(bdTarget));

BigDecimal 계산값: 0.3
결과가 0.3과 같니? -> true

BigDecimal은 부동소수점 방식이 아니라, 10진수를 그대로 표현한다.

즉, 처음부터 근사값이 아니라,

의도한 값 그대로 저장하고 계산하기 때문에 이런 문제 자체가 발생하지 않는다.

하지만 BigDecimal 쓸떄 주의해야할점이 있다.

정확한 계산이 필요할 때는 BigDecimal이 좋은 선택이지만

아래처럼 쓰면 안된다.

BigDecimal wrong = new BigDecimal(0.1);
BigDecimal correct = new BigDecimal("0.1");

System.out.println("new BigDecimal(0.1)    : " + wrong);
System.out.println("new BigDecimal(\"0.1\")  : " + correct);
System.out.println("둘이 같니? -> " + wrong.equals(correct));

new BigDecimal(0.1)    : 0.1000000000000000055511151231257827021181583404541015625
new BigDecimal("0.1")  : 0.1
둘이 같니? -> false

같은 0.1처럼 보이지만, 두 값은 전혀 다른 값이다.

new BigDecimal(0.1)은 0.1이라는 십진수를 BigDecimal로 바꾸는 게 아니라,

이미 오차가 포함된 double 0.1을 그대로 BigDecimal로 감싼 것이다.

반면,

new BigDecimal("0.1")은 사람이 의도한 십진수 0.1을 처음부터 정확하게 BigDecimal로 만든다.

BigDecimal은 만능 해결책이 아니다.

입력부터 정확해야 의미가 있다.

X new BigDecimal(double)
O new BigDecimal(String)
O BigDecimal.valueOf(double)

0.1 + 0.2 != 0.3 같은 부동소수점의 계산과 비교는

컴퓨터가 숫자를 표현하는 방식에서 비롯된, 아주 자연스러운 결과다.

다들 알맞은 방식을 쓰고 결과를 도출해내길

API 상태 코드, 어떤 기준으로 정하는게 좋을까?

integerJI — Thu, 12 Jun 2025 09:50:21 +0900

1. 들어가며

사이드 프로젝트를 진행하며 궁금한 점이 생겼다. API에서 에러가 발생하면 어떤 상태 코드를 보내야 할까?

프로젝트 팀원들과 이야기할 때마다 의견이 갈렸다. RESTful 원칙에 따라 400번대, 500번대를 사용하자는 의견과 응답을 정상적으로 받았으니 200이 맞다는 의견이 있었다.

나는 여기서 200이 맞다고 생각했다. 에러를 반환했다는 것 자체가 HTTP 통신에는 성공한 것이고, HTTP는 RFC로 정의된 표준 프로토콜인데 굳이 왜 변경해야 하는지 의문이었다. 차라리 그럴 거면 커스텀 상태코드를 만들어서 사용하는 게 낫지 않을까 생각했다.

ZeroCho님의 유튜브 영상을 보고 다시 고민이 떠올라 이번 기회에 찾아보게 되었다. 클라이언트와 서버 입장에서 각각의 논리가 다 이해되었고, 상황과 서비스에 따라서 트레이드오프를 해야 한다는 걸 깨달았다.

또한 혹시나 해서 적는건데 절대 싸우자는 의미가 아니다 !! 결론은 각자 서비스에 맞는 스타일을 쓰자. 정답은 없다.

2. HTTP 상태코드의 원칙과 현실

REST 아키텍처에서는 HTTP 상태코드를 명확하게 구분해서 사용하라고 한다. 200은 성공, 400번대는 클라이언트 오류, 500번대는 서버 오류로 말이다. 로그인 실패라면 401, 잘못된 요청이면 400을 보내는 게 원칙이다. 이론적으로는 깔끔하다. API 문서만 봐도 어떤 에러가 나올지 예측할 수 있고, 프론트엔드에서도 상태코드만 보고 처리 방향을 정할 수 있다.

하지만 실무에서는 문제가 생긴다. 4xx, 5xx 코드가 나올 때마다 모니터링 시스템에서 알람이 울린다면, 운영팀에서는 진짜 서버 장애와 단순 비즈니스 로직 실패를 구분하기 어렵다. 대표적으로 404가 있다. GET /users/123에서 404가 나왔을 때, API 엔드포인트가 없는 걸까? 아니면 API는 있지만 해당 사용자가 없는 건지 클라이언트는 구분하기 어렵다.

3. 200 vs RESTful 방식, 어떤 게 더 좋을까?

이제 두 방식의 장단점을 구체적으로 살펴보자. AI 툴과 구글링을 통해 알아보고 각 접근법의 장단점을 정리해보았다.

200 + body 에러 방식

장점으로는 개발 편의성이 크다. 모든 API가 동일한 응답 구조를 가지니까 프론트엔드에서 일관된 에러 처리 패턴을 사용할 수 있다.

단점은 HTTP 표준을 무시한다는 점이다. 브라우저나 CDN이 잘못된 응답도 성공으로 캐시할 수 있고, 히스토리를 모르는 개발자가 코드를 본다면 혼란스러워할 수 있다. 또한 웹서버 로그만으로는 실제 성공률을 파악하기 어렵다.

RESTful 방식

장점은 HTTP 표준에 부합한다는 점이다. 브라우저, 프록시, 각종 도구들이 상태코드를 보고 적절히 처리할 수 있다. API 문서도 명확해진다. "로그인 실패 시 401 반환"이라고 쓰면 모든 개발자가 이해하므로 유지보수가 용이하다. 웹서버 로그만 봐도 대략적인 성공/실패 비율을 알 수 있어 운영에 도움이 된다.

단점은 운영 복잡성이다. 정상적인 비즈니스 실패(로그인 실패, 권한 없음)와 실제 서버 장애를 구분해야 한다. 프론트엔드에서도 HTTP 레벨 에러와 비즈니스 로직 에러를 따로 처리해야 해서 코드가 복잡해진다.

실제 성능/운영 임팩트 비교

성능 면에서는 큰 차이가 없다. 둘 다 같은 HTTP 요청/응답이고, 상태코드 몇 자리 숫자 차이일 뿐이다.

결국 팀의 상황과 우선순위에 따라 선택해야 한다. 빠른 개발과 운영 단순성을 원한다면 200 방식이, HTTP 표준 준수와 명확성을 원한다면 RESTful 방식이 적합하다.

4. 마무리

이걸로 나의 결과를 통해 단정 짓기에는 무리가 있는 것 같다. 많은 프로젝트가 있고 많은 개인 사정들이 있을 것이다. 그걸 내가 이게 맞다고 글을 적기엔 어려운 부분이 많다. 그래서 다들 정답이 없나 보다. 다들 자신의 프로젝트에서 잘 쓰고 있을 것이고, 나처럼 고민하는 분에게는 이러한 이유 때문에 정답이 없구나 생각해 주시면 좋을 것 같다.

이번에 조사하면서 내 생각도 조금 바뀌었다. 처음엔 "HTTP 통신 성공했으니 200이 맞다"고 생각했는데, 사소한 프로젝트라도 규약을 지켜가며 쌓아가야 되지 않을까? 라는 생각이 들게 되었다. 앞으로는 프로젝트 초기에 팀과 상황을 고려해서 방식을 정하고, "왜 이 방식을 선택했는지" 명확한 근거를 가지고 결정하는 게 중요할 것 같다.

사내스터디 - 파티셔닝

integerJI — Thu, 15 May 2025 12:09:07 +0900

뒤끝터디 5주차 – 파티셔닝

1. 들어가며

5장에서 복제를 다루며 동일한 데이터를 여러 노드에 저장하는 방식을 배웠다. 이중화로 읽기 처리량을 높이고 장애 대응도 가능해졌지만, 여전히 데이터가 너무 많거나 요청이 너무 많은 상황은 복제만으로 감당할 수 없다.

이럴 때 등장하는 해결책이 바로 데이터 파티셔닝이다. 이번에는 파티셔닝과 다양한 기법들, 그리고 클러스터 환경에서의 재균형화 전략까지 적혀있어 읽어 보았다.

2. New – 새롭게 알게 된 개념 정리

2-1. 데이터 파티셔닝의 진짜 이유

파티셔닝을 고민하는 이유는 명확하다. 확장성이다.

단일 장비로 처리할 수 없는 수준의 데이터를 쪼개서 여러 장비에 나누고, 그에 따라 저장과 질의 부담을 분산하려는 것이다. 단순히 데이터를 나누는 것이 아니라, 어떻게 나눌지, 그리고 어디에 나눌지를 결정하는 것이 핵심이었다.

2-2. 문서 기준 보조 색인 파티셔닝

이 부분은 ID 기준으로 문서를 조회하는 방식 같았다. 파티셔닝된 환경에서 보조 색인을 어떻게 운영할지를 다루는데,
여기에 전역 색인(global index)과 지역 색인(local index) 개념이 등장한다.

전역 색인: 클러스터 전체를 아우르는 색인. 단일 색인으로 빠르게 찾을 수 있지만, 업데이트 비용이 높다.
지역 색인: 각 파티션(샤드)에 존재하는 독립 색인. 쓰기에는 유리하지만 질의 시 여러 샤드를 동시에 뒤져야 한다.

흠 ... 어렵다..

전역 색인은 ‘책 맨 뒤의 주제별 색인’처럼 한 번에 찾아볼 수 있는 구조.

반면 지역 색인은 ‘각 장의 맨 앞에 있는 소제목 목차’처럼, 해당 장만 뒤져야 하므로 찾는 범위가 제한적이다.

라고 찾아보니가 조금 나왔다. 새롭게 알게 되었지만 명확하지도 않는 부분이다.

3. Difficulty – 명확하지 않았던 부분

3-1. 전역 vs 지역 색인

색인이라는 말 자체가 SQL 인덱스처럼 느껴진다.

3-2. 파티션 재균형화

책에서 언급한 파티션 재균형화(rebalancing)는 다음과 같은 상황에서 필요하다고 한다:

질의 처리량이 늘어 CPU를 더 추가하고 싶을 때
데이터셋이 커져 디스크나 메모리 자원이 부족할 때
장비 장애로 특정 노드가 제거되어야 할 때

뭔가 스케일업/다운, 오토스케일링, L7 로드밸런서랑 비슷한 것 같다.

결국 핵심은 데이터를 어떻게 고르게 나눌 것인가, 그 과정에서 문제가 생기지 않도록 어떻게 설계할 것인가인 셈이다.

4. Amendment – 도움이 된 생각의 전환

이 장을 정리하면서 서버 부하 분산 구조(L7 Load Balancing와 비교하면 이해가 더 쉬웠다.

L7에서 사용자의 요청을 여러 서버로 분산하듯
파티셔닝은 데이터를 여러 노드로 나눠 저장하고 처리한다.

결국 데이터든 요청이든, 분산의 목적은 같다. 병목을 피하고, 고르게 나누며, 장애 대응까지 고려하는 구조.

이 시점에서 데이터베이스는 단순 저장소가 아니라, 설계와 인프라의 연장선이라는 생각이 들었다.

5. 마무리

이번 장에서는 대용량 데이터셋을 더욱 작은 데이터셋으로 파티셔닝하는 방법을 살펴봤다.

저장하고 처리할 데이터가 너무 많아 장비 한 대로 처리할 수 없다면, 파티셔닝이 필요하다. 파티셔닝의 목적은 핫스팟 없이 데이터와 질의 부하를 여러 장비에 고르게 분산하는 것이다. 그렇게 하려면 데이터에 적합한 파티셔닝 방식을 선택해야 하고, 클러스터의 노드가 추가되거나 제거될 때 파티션 재균형화가 수행되어야 한다.

이건 마치 서버에서 L7 로드밸런서를 통해 요청을 분산하는 구조와도 유사하게 생각하니 알기 쉬웠다.

사내스터디 - 데이터 모델과 질의 언어

integerJI — Thu, 24 Apr 2025 17:59:38 +0900

뒤끝터디 2주차 – 데이터 모델과 질의 언어

1. 들어가며

이번 챕터에서는 데이터 모델과 질의 언어에 대해 다룬다.

사실 평소에 개발을 하며 데이터베이스 구조에 대해 깊게 고민할 기회가 많지는 않다.

MSSQL을 중심으로 정형화된 모델만 사용해 온 입장에서, 이번 장은 모델링과 시스템 설계 전반을 다시 생각해보게 하는 내용이었다.

관계형 모델의 태생적 한계와 이를 보완하기 위해 등장한 다양한 비관계형 DB의 목적, 그리고 각각의 데이터 모델이 사용되는 맥락에 대해 살펴볼 수 있었다.

2. New – 새롭게 알게 된 개념 정리

2-1. 계층 구조로 쌓이는 데이터 모델

대부분의 애플리케이션은 데이터 모델이 단일 계층이 아니라 여러 계층 위에 얹힌 구조다.

예를 들어 도메인 객체 → JSON → 관계형 테이블처럼 여러 표현 방식이 존재하며,

이러한 계층 간의 전환이 중요한 이슈가 된다고 설명한다.

각 계층마다 하위 관점에서 상위 데이터를 어떻게 표현하고 매핑하느냐가 설계 포인트다.

2-2. NoSQL의 등장 배경

NoSQL은 단순히 ‘SQL을 쓰지 않는다’기보다는 ‘SQL만 고집하지 않는다(Not Only SQL)’라는 의미에 가깝다.

책에서는 NoSQL이 등장하게 된 이유를 아래와 같이 정리하고 있다.

매우 큰 데이터셋을 다루거나 높은 쓰기 처리량이 필요할 때 확장성이 더 뛰어남
상용 관계형 DB의 높은 라이선스 비용에 비해, 오픈소스 도입을 선호하는 흐름
관계형 모델이 표현하기 어려운 질의 요구사항 존재
고정된 스키마 구조에 대한 불만 → 유연하고 동적인 스키마 요구

결국 현실적인 문제에서 출발한 해결책이라는 점에서, 비즈니스와 맞닿아 있는 기술이라 느껴졌다.

2-3. 다중 저장소 지속성 (Polyglot Persistence)

이 개념은 처음 알게 되었는데, 이미 실무에서는 무의식 중에 사용하고 있었다.

사용자 정보는 MSSQL, 로그는 MongoDB, 캐시는 Redis처럼

하나의 시스템에 서로 다른 특성을 가진 DB를 병렬적으로 사용하는 것을 의미한다.

각 데이터 모델의 강점을 조합하는 방식으로 이해할 수 있다.

2-4. 문서형 vs 그래프형 데이터베이스

문서형(Document): 각 문서가 독립적이며, 문서 간 연관이 거의 없는 경우에 적합. 예: 주문 내역, 게시글
그래프형(Graph): 모든 데이터 간 연결이 중요할 때 적합. 예: 소셜 관계망, 추천 시스템

데이터의 연관성 정도에 따라 데이터 모델이 달라질 수 있다는 점이 실무에서도 도움이 될 만한 기준이었다.

2-5. 트리플 저장소 / SPARQL

지식 그래프나 의미론적 웹에서 사용하는 RDF 기반의 데이터 저장소.

SPARQL은 이를 질의하는 언어로, 일반적인 CRUD와는 다소 결이 다르다.

이 챕터에서는 간단한 용도만 소개되며, 깊은 이해보다는 개념 위주의 정리였다.

3. Difficulty – 명확하게 이해되지 않았던 부분

3-1. 임피던스 불일치 (Impedance Mismatch)

객체지향 시스템과 관계형 데이터베이스 모델 간의 간극을 설명하는 용어다.

예를 들어, User 객체 내부에 Address 클래스가 포함되어 있다면

RDB에서는 이걸 별도 테이블로 나눠 외래키로 연결해야 한다.

그 과정에서 데이터 표현 방식과 흐름이 자연스럽지 않게 되며, 이 전환 자체가 개발자에게 부담이 된다.

ORM이 존재하는 이유이기도 하다.

아직도 이 개념이 정확히 “어디까지를 임피던스 불일치라 부르나?”에 대해선 감이 확 오진 않았다.

하지만 객체지향과 RDB의 구조적 차이를 표현하는 용어로는 적절하다는 생각이다.

3-2. 트리 구조 → 관계형 모델의 역사

초기에는 계층적 트리 모델로 데이터를 표현했지만, 다대다 관계 표현이 어렵고 유연성이 떨어졌다.

이를 해결하기 위해 관계형 모델이 등장했다는 설명이 있었는데, 이 흐름을 시간 순으로 정리하면 다음과 같다.

트리 구조 모델: 단방향 계층 관계 표현에는 적합하지만 유연성이 부족
관계형 모델: 모든 데이터를 릴레이션으로 추상화 → 조인을 통한 유연한 질의 가능
비관계형 모델: 관계형이 해결하지 못하는 성능/확장성/표현력 문제를 해결하기 위해 등장

이 관점은 단순한 기술 비교를 넘어, 시스템 아키텍처 설계의 배경 논리를 제공한다.

4. 각 데이터 모델별 특성 정리

구분 관계형 DB (MSSQL) 비관계형 DB (MongoDB)

구조	고정된 스키마	유연한 JSON 기반 문서 구조
트랜잭션	강력한 ACID 지원	트랜잭션보다는 가용성과 속도 중시
확장성	수직 확장 중심	수평 확장에 유리
장점	복잡한 조인 가능, 성숙한 툴 생태계	빠른 쓰기, 자유로운 구조, 유연한 개발
단점	구조 변경이 번거롭고 유연성 떨어짐	조인 연산이 약하고 관계 표현이 제한적

5. 마무리

이번 챕터는 단순한 CRUD 중심의 사고에서 벗어나,

“왜 이 모델을 쓰는가”, “우리 서비스는 어떤 데이터 구조가 맞는가” 같은 질문을 던지게 만든다.

데이터베이스 선택은 결국 기술이 아니라 요구사항에서 출발한다는 점에서

각 모델의 배경과 쓰임새를 알아두는 게 꽤 중요하다는 생각이 들었다.

글또10기 회고, 글쓰는 또라이가 세상을 바꾼다

integerJI — Sun, 30 Mar 2025 22:37:54 +0900

글또와 함께한 3년

2022년 5월, 글또 7기로 첫 발을 내디뎠다. 그리고 2025년 3월, 글또 10기를 끝으로 나의 글또 여정은 잠시 마무리된다.

글또와의 만남은 우연이었다. 인스타그램 알고리즘이 이끌어준 인연.

당시 나는 2~3년 차 개발자로, 성장에 목말라 있던 시기였다. 다양한 스터디와 커뮤니티를 기웃거리며 나에게 맞는 ‘성장의 환경’을 찾고 있었고, 그 무렵 성윤님의 게시글을 통해 ‘글또’라는 개발자 글쓰기 커뮤니티를 알게 되었다.

오잉 원래 이렇게 간단한 글이었나? 뭔가 엄청 화려했던거같은데 .. ㅋㅋ

받은 따뜻함을 나누고 싶다

7기 다짐글

8기 회고글

10기 다짐글

7기 때 나는 주도적인 학습보다는 ‘해야 하니까 하는’ 느낌에 가까웠다.

의무적으로 참여했기에 깊이 몰입하지 못했던 것도 사실이다.

그렇게 어영부영 8기를 맞이했고, 그때 CS 스터디를 통해 전환점을 맞이했다.

소극적이던 나에게 스터디 멤버들은 따뜻하게 다가와 주었고,

그들과 함께하면서 글또 활동의 진짜 재미를 느낄 수 있었다.

특히 스터디 안의 운영진 분들이, 적응하지 못하던 나를 자연스럽게 이끌었고 그분들을 보며 운영진이라는 역할을 동경하게 되었다.

나도 내가 받은 따뜻함을 다른 사람들에게 나누고 싶다는 생각에 9기 운영진을 지원하게 되었다.

하지만 9기 운영진 활동은 마음처럼 쉽지 않았다.

회사 일이 갑자기 바빠지면서 글또 참여가 점점 줄어들었고,

결국 9기의 다짐글과 회고글도 남기지 못한 걸 보면, 그 점은 지금도 마음에 아쉬움으로 남아 있다.

그래서 10기를 시작할 때는 다시 처음처럼 해보자는 마음으로 삶의 지도와 다짐글을 조심스럽게 꺼내 적었다.

운영진으로서 목표했던 ‘따뜻함 나누기’, 그리고 —과거의 나처럼 망설이는 분들을 이끌어주는 일—

그 다짐을 안고, 마지막 기수였던 10기에서 최선을 다해 활동하기를 다짐했다.

글또를 하는 사람에서 함께하는 사람으로

글또를 하며 다양한 사람들을 만나고, 함께 시간을 나누었다.

그 과정에서 나도 자연스럽게 성장할 수 있었다.

어느 날, 누군가 내게 물었다.

“그렇게 모임도 만들고 사람들 만나서… 얻는 게 뭐야?”

생각해 보니, 나는 누군가의 행복한 기억 속에 조금이라도 남는 사람이 되고 싶었던 것 같다.

힘들 때 떠올릴 수 있는 기억 중 하나가 나와 함께한 순간이면 좋겠다는 마음.

그게 내가 모임을 주최하는 이유다.

물론 준비는 쉽지 않다. 하지만 커피챗 후기나 슬랙에서 웃는 사람들 모습을 보면,

그 행복이 고스란히 전해진다.

9기에는 운영진으로 ‘고민 상담소’를 진행했고,

10기에는 팟캐스또, 썰매·스키, 김장, 관악또, 마인크래프트, 보드게임 모임 등 정말 다양한 활동을 해보았다.

모두 즐거운 기억이었다.

그리고 그 안에서 나는 정말 글또와 함께 ‘살아갔다’고 느낄 수 있었다.

10기, 마지막을 준비하며

글또를 하며 수많은 사람들을 만났다. 함께 웃고, 함께 성장하며 남긴 사진들과 추억이 참 많다.

떠오르는 이름도 정말 많지만, 누구 하나 쉽게 적을 수 없을 만큼 모두 소중하고 감사한 인연이었다.

못 본 지 오래된 분들도 문득 그립다.

혹시 이 글을 읽으며 ‘혹시 나인가?’ 생각했다면,

맞다. 그 주인공은 바로 당신이다. 정말 고맙습니다.

글또를 만들고 이끌어주신 성윤님께도 진심으로 감사드린다.

아직 미성숙했던 나는 글또라는 작은 사회 안에서 함께하고, 부딪히며 조금씩 성장할 수 있었다.

10기를 거치며 다양한 활동을 해보았고,

그 안에서 어느 순간부터는 좀 더 진중하게 배우고, 성장하고 싶다는 마음이 자라났다.

2주에 한 번씩, 어떻게든 글을 써냈다.

부족하더라도 기술적인 글에도 도전했고,

그 시간들이 쌓이며 내 안의 태도와 시선이 천천히 변하기 시작했다.

요즘 나는 토플을 공부하고 있다.

처음엔 단순한 호기심으로 시작했지만,

함께 공부하는 사람들의 간절함과 진심을 보며

나도 다시 배움 앞에 겸손해지는 법을 배우는 중이다.

회고도 그랬다.

처음엔 마음을 꺼내 쓰는 게 부끄럽고 어색했지만,

시간이 지나고 나서도 오래 남는 건

결국 감정이 담긴 기록이라는 걸, 이제는 안다.

이제 나는 마지막을 준비하며

조금 더 단단한 사람으로 성장할 거라고 믿는다.

글또를 함께 만든 성윤님,

늘 곁에서 응원해 준 운영진 분들,

모자란 나를 따뜻하게 대해준 모든 분들,

그리고 스치듯 만나 인사 나눈 모든 글또분들에게

진심으로 감사의 마음을 전하며 이 회고를 마친다.

너무 많다.. 고성,, 판교제육,, 강남구청 템플스테이, 간단 캠핑 ㅠ

redis를 사용하여 원하는 데이터 백업하기

integerJI — Sun, 16 Mar 2025 23:40:34 +0900

최근 글또 활동을 하며 마인크래프트를 즐기고 있다.

GCP를 사용해 서버를 열고 사용자와 함께 즐기고 있는데 같은 데이터 직군분께서 마크 데이터를 활용하여 통계를 내주시고는 하는데 이는 마크 서버에서 특정 데이터를 백업하고, 추출해야 하는 번거로움이 있었다.

기존에는 크론탭을 이용해 정해진 시간마다 백업을 수행했다. 하지만 이는 불필요한 데이터까지 백업하게 되어 비효율적이었다. 따라서 실제 접속이 발생한 시간대만 백업하는 방식이 필요했고, 이 문제를 해결하기 위해 Redis를 도입했다. Redis를 활용하면 접속 상태를 실시간으로 감지하고 특정 조건에서만 백업을 실행할 수 있어, 불필요한 백업을 줄이고 서버 리소스를 절약할 수 있다. 이 과정을 적어보며 redis를 설치 & 적용하며 수행했던 명령어와 느낀 점을 적어본다.

크론탭으로 특정 시간마다 이렇게 데이터를 백업을 하고 있었다.

이를 개선할 수 있는 방법은 무엇이 있을까? 고민을 하다 이 김에 redis를 사용해볼까? 하여 도전해 보기로 하였다.

현재 마크 서버에는 이렇게

특정 사용자가 로그인을 하면 스레드에 알림을 주는 파이썬 스레드가 돌고있다.

이를 이용해서 사용자가 접속하여 접속 인원이 1명 이상인 날짜 + 사용자가 퇴장하여 접속 인원이 0명이 된 날짜의 데이터만 백업을 하면 좋을 것 같았다.

이렇게 될 경우 특정지어서 데이터 분석에 효과를 줄 수 있지 않을까 ?! 싶다.

1. 레디스 설치

sudo apt install redis -y

sudo systemctl status redis

레디스를 설치하고 실행상태를 확인해보자.

2. Hello, Redis

pip install redis

import redis

# Redis 서버 연결
r = redis.Redis(host='localhost', port=6379, decode_responses=True)

# 테스트 데이터 저장
r.set("test_key", "Hello from Python!")
print(r.get("test_key"))

사용 중인 python 가상환경에 redis를 설치하고 서버에 연결하여 key를 가져와본다.

3. redis 함수 삽입

    for player in new_players:
        redis_client.lpush("mc_players", player)  # Redis 리스트에 플레이어 추가

특정 플레이어가 접속하면 Redis에 플레이어 추가

    for player in left_players:
        redis_client.lrem("mc_players", 1, player)  # Redis 리스트에서 제거

플레이어가 퇴장하면 레디스에서 플레이어 제거

여기서 가운데 인자인 1은

Redis의 LREM 명령어 중 리스트에서 특정 값을 제거할 때 사용한다.

redis_client.lrem(name, count, value)

가운데 count가 의미하는 값은

count 값	동작 방식
0	리스트에서 해당하는 모든 값을 제거
1	왼쪽(0번째)의 값 부터 일치하는 값을 제거
-1	오른쪽(맨뒤)의 값 부터 일치하는 값을 제거
N	왼쪽부터 N개의 일치하는 값을 제거

이 정도이다.

추가로 모든 플레이어가 나가면 백업을 실행할 수 있게 함수를 추가한다.

if redis_client.llen("mc_players") == 0:
    last_backup_time = redis_client.get("last_backup")

    if last_backup_time:
        last_backup_time = datetime.datetime.strptime(last_backup_time, "%Y-%m-%d %H:%M")
        now = datetime.datetime.now()
        
        if (now - last_backup_time).total_seconds() < 3600:
            print("최근 1시간 내에 백업이 실행되어 실행하지 않음.")
        else:
            print("백업 스크립트 실행 중...")
            subprocess.run(["backup_script.sh"])
            redis_client.set("last_backup", now.strftime("%Y-%m-%d %H:%M"))
    else:
        print("백업 스크립트 실행 중...")
        subprocess.run(["backup_script.sh"])
        redis_client.set("last_backup", datetime.datetime.now().strftime("%Y-%m-%d %H:%M"))

특정 플레이어 리스트가 0이 되면 특정 sh 파일을 실행하여 백업을 진행한다.

서버를 관리하며 백업을 실행해 보자!

마무리.

따로 백업 스크립트를 사용하거나 크론탭으로 감지하여 실행해 볼 수 있었지만 간단하게 진행하는 미니 프로젝트 용으로는 redis를 사용해 보며 도입해 보면 좋을 것 같았다. 그래서 이번 서버의 경우 서버 접속 감지가 기존에도 사용이 되고 있었으며 특정 스크립트를 통해 백업 트리거가 목적이었다. 따라서 접속 상태를 리스트(LPUSH/LREM)로 간단하게 관리가 가능하고 메모리 기반으로써 실시간 응답속도가 빠른 redis를 도입한 이유이다.

만약 게임 서버에서 활동되는 모든 이벤트를 저장한 뒤 분석 도구와 연결하거나 여러 서버를 동시에 운영한다면 대용량 서비스인 kafka를 이용하는 것도 좋아 보인다.

마라톤 회고, 부제 : 완주 못한 마라톤은 실패한 마라톤인가?

integerJI — Sun, 2 Mar 2025 22:28:27 +0900

새는 날고 물고기는 헤엄치고 인간은 달린다. 피크닉 전시회 중

들어가며

나는 달리기를 한다. 좋아하지는 않지만, 군대에서 처음 뛰어본 마라톤은 나의 스트레스를 해소하는 운동으로 이용되기 시작했다. 나는 평소에 생각이 많다. 업무를 하며, 일상을 살며 다양한 생각이 머릿속을 떠나지 않는다. 머리가 복잡해질 때, 혹은 다른 안 좋은 네이티브한 생각들로 머릿속이 가득 찰 때, 나는 뛰러 나가기 시작한다. 심장 소리와 나의 호흡을 느끼며 오래 달리다 보면, 생각이 사라진다(하지 못한다). 그리고 깨끗하고 맑은 생각으로 뇌를 초기화한다. 그렇게 마라톤을 시작하게 되었다.

실패와 성공

첫 실패의 쓴맛은 나를 더 강하게 만들었다. 2023년 마라톤에 도전했을 때, "의지와 정신력만 있으면 풀마라톤을 뛸 수 있을 거야"라는 자만심으로 충분히 완주할 수 있을 거라 생각했다. 하지만 완주에 실패하고 말았다. 당연하게도 의지와 정신력만으로는 완주를 할 수 없었고 연습량과 마라톤을 참가하는 나의 나쁜 마음가짐을 생각하며 나를 더욱 열심히 준비하게 만들었다.

그렇게 2024년, 다시 한 번 마라톤에 도전하게 되었다. 이번에는 2023년과는 다르게 나름 열심히 준비했다. 식단부터 시작해, 격주로 진행하는 장거리 훈련, 글리코겐 로딩까지, 그리고 주변 사람들에게 열심히 말을 하며 나만의 동기부여를 만들었다. 그렇게 완주에 성공할 수 있었다. 이 도전을 통해 나는 앞으로 무엇이든 해낼 수 있을 것 같다는 자신감을 얻었고 해외 마라톤이라는 2025년 오사카 마라톤에 다시 도전할 수 있었다.

그리고, 다시 실패(?)

2025년 2월 24일, 나는 해외 마라톤에 참가했다. 실패와 성공의 경험을 통하여 해외 마라톤을 경험해 보고 싶었다. 그렇게 참가를 결정하며 눈 내리는 추웠던 2월, 해외 마라톤에 참가하게 되었다.

해외 마라톤은 정말 색다른 경험이었다. 한국은 응원 문화가 매우 파이팅 넘치고 열기가 대단하다면, 일본은 비교적 조용하고 차분한 분위기였다. 음식도 정말 다양하게 제공되었고, 마라톤 운영이 너무 깔끔하고 체계적이라는 생각이 들었다. (이것이 바로 세계 6대 마라톤 보유국의 운영 스타일인가?) 날씨도 많이 추웠고, 연습도 충분히 하지 못했기 때문에 완주가 어려울 거라 예상했다. 하지만 뛰면서 제공되는 간식들 (빵, 과자, 사탕, 바나나, 에너지 음료 등)이 끊임없이 에너지를 공급해 주어 지치지 않게 만들었다.

그러나 피니시 라인이 까지 7km를 남겨두고, 비행기 시간이 부족해 결국 포기하고 집으로 돌아가게 되었다.

아니, 그저 경험일 뿐

완주를 하지 못한 마라톤은 정말 실패한 마라톤일까? 이제 그렇게 생각하지 않는다. '실패'는 단순히 목표를 달성하지 못한 것일 수 있지만, 그 과정에서 나는 오히려 더 넓은 세상을 보고, 나의 한계를 시험하며, 쉽게 얻을 수 없는 값진 경험을 얻을 수 있었다.

마라톤 회고를 적는 이유는 무엇일까? 그 이유는 간단하다. 인생은 마라톤과 같다. 첫 취업 후 실패와 좌절을 경험하고, 그것을 딛고 일어나 성공을 맛보며 자만하기까지, 마라톤 대회에 참가하면서 이것은 내가 살아온 길과 다르지 않다는 것을 느꼈다.

다양한 경험을 통하여 누구는 더 빨리 겪을 수 있고 누구는 조금 더 늦게 겪을 수 있다. 하지만 이 또한 마라톤과 똑같다. 사람들은 모두 다르다. 페이스, 호흡, 근육량, 성별 등 염색체 하나하나 다르다. 그렇기에 남들과 비교하지 않고 나의 길을 걸을 수 있지 않을까?

정리하며

이 경험은 2025년, 나에게 가장 큰 선물 같았다. 이 도전을 통해 나는 새로운 용기를 얻었고, 그 용기가 나를 한 걸음 더 나아가게 만들었다. 이제는 성공과 실패를 하더라도 도전할 수 있는 용기를 갖게 되었으며 마라톤도, 인생도 결국은 목표를 향해 달려가는 긴 여정이며 목표 지점에 다다르는 순간, 그것이 바로 내 인생의 골인선이 될 것이다.

성장이 없는 실패는 결국 상처만 남는다. 실패는 누구에게나 찾아올 수 있는 경험이고, 상처는 결국 아물고 나면 더 강해진다. 누구나 원하는 목표를 이루지 못할 수 있다. 마라톤을 뛰며 모르는 사람들의 응원을 받으면서, 낯선 곳에서 같은 한국인을 만나 "한국인 파이팅!"을 외치며 서로를 응원하는 그 순간들. 그 순간은 내가 목표를 향해 도전하고 있다는 것만으로도 큰 의미가 있다. 인생도 마찬가지다. 실패와 좌절을 겪더라도, 그건 그저 잠시일 뿐. 조금만 더 기다리면, 언제든지 다시 일어날 수 있다. 털어놓지 않아도, 그 안에 응원하고 지지해 주는 사람들이 있을 거니까.

새로 얻은 깨닳음과 다짐을 잊지 않게 회고를 작성해 본다.

Apache Kafka를 실행해보자

integerJI — Sun, 16 Feb 2025 22:22:22 +0900

1. 들어가며

최근 회사 프로젝트에서 클라이언트와 실시간으로 데이터를 저장해야하는 일이 생겼다. 이 데이터를 보다 효율적으로 처리하기 위해 Apache Kafka를 도입하게 되었고 Kafka를 도입하기 전 Kafka의 개념과 주요 특징, 그리고 로컬에서 실행해보았다.

2. Apache Kafka란?

Kafka는 대량의 데이터를 빠르고 안정적으로 전송하는 분산 스트리밍 플랫폼이다. 링크드인에서 개발되었으며, 현재는 실시간 로그 수집, 이벤트 스트리밍, 데이터 파이프라인 구축 등의 다양한 용도로 사용된다.

Kafka의 기본적인 구조는 다음과 같다:

Producer: 데이터를 Kafka로 보내는 역할
Broker: 데이터를 저장하고 관리하는 서버
Consumer: Kafka에서 데이터를 가져가는 역할
Topic: 데이터가 저장되는 논리적인 공간
Partition: Topic을 여러 개의 작은 단위로 나누어 병렬 처리 가능하게 함\

AWS에서 제공하는 카프카 대기열

그리고 게시-구독

3. Kafka의 특징

3.1. 높은 처리량과 확장성

Kafka는 분산 처리 기반으로 작동하기 때문에, 데이터 양이 증가해도 성능이 크게 저하되지 않는다.

Topic을 여러 Partition으로 나누어 Consumer가 병렬 처리 가능
다수의 Broker로 클러스터를 구성해 수평 확장 가능

3.2. 내결함성(Fault-Tolerance)

Kafka는 Replicas를 지원하여 하나의 Broker가 다운되더라도 데이터 손실 없이 서비스 운영이 가능하다.

기본적으로 Leader-Follower 구조를 유지하며 안정성 확보
장애 발생 시 자동으로 다른 노드가 리더 역할을 수행

3.3. 실시간 데이터 처리

Kafka Streams 또는 Spark Streaming 같은 기술과 결합하면 실시간 데이터 분석이 가능하다.

실시간 사용자 행동 분석, 실시간 모니터링, 로그 분석 등

4. Kafka 로컬 실행

Kafka를 간단하게 사용해 보려고 한다. 윈도우 환경에서 간단하게 한번 실행해 보자.

테스트 환경

Kafka 버전: Apache Kafka 3.9.0
Java : Java 17

4.1 다운로드

다운로드 -> https://kafka.apache.org/downloads

Apache Kafka

Apache Kafka: A Distributed Streaming Platform.

kafka.apache.org

현재 카프카 홈페이지에서 최신 버전인 3.9.0 버전의 Scala 2.12를 설치해 준다.

그 다음 받은 압축 파일을 아무 경로에 풀어준다.

4.2 zookeeper 실행

zookeeper.properties 파일 수정

E 드라이브의 특정 경로에 카프카를 설치하였는데

프로퍼티 설정을 바꿔주어야한다.

추가로

mkdir E:\Developer\kafka\data\zookeeper

디렉터리를 하나 더 생성해준 뒤

/e/Developer/kafka/bin/windows
./zookeeper-server-start.bat /e/Developer/kafka/config/zookeeper.properties

실행해보면 ..

zookeeper 구동 성공!

zookeeper는 Kafka 를 실행시키기 위해 꼭 필요하다. 하지만 3.3.0 이상 버전부터는 zookeeper

GPT의 힘을 빌려 Zookeeper가 필요한 이유를 찾아보면

✅ Kafka가 Zookeeper를 필요로 하는 이유

Broker 등록 및 상태 모니터링
Leader Election (리더 선출)
Topic 및 Partition 메타데이터 저장
Consumer Group 관리 및 오프셋 저장

라고한다.

4-3. Kafka 실행

Kafka도 실행하기 전 프로퍼티를 손봐줘야한다.

새로운 bash 창을 열어서

/e/Developer/kafka/config/server.properties

로그를 저장하는 디렉터리 경로를 바꿔주자.

그 다음 알맞게 폴더도 생성 !

mkdir E:\Developer\kafka\data\kafka-logs

kafka를 실행해 보자.

./kafka-server-start.bat /e/Developer/kafka/config/server.properties

4-4. Topic 생성 및 테스트

bash 창을 새로 열어 토픽을 생성하자.

cd /e/Developer/kafka/bin/windows #kafka 폴더 이동
./kafka-topics.bat --create --topic test-topic --bootstrap-server localhost:9092 --partitions 1 --replication-factor 1 #kafka 토픽 생성
./kafka-topics.bat --list --bootstrap-server localhost:9092 #kafka 토픽 목록 확인

Kafka에서 데이터를 송수신하려면 Topic을 먼저 만들어야한다.

토픽 생성 후 "Created topic test-topic"가 나오면 성공이다.

4-5. Producer 실행 (메시지 전송)

새로운 bash 창을 또 열어서 메시지를 전송해보자

 ./kafka-console-producer.bat --topic test-topic --bootstrap-server localhost:9092
hihi kafka
test message
message test one two

Kafka는 메시지를 Consumer가 가져가기 전까지는 별다른 응답을 주지 않는다.

4-6. Consumer 실행 (메시지 수신)

./kafka-console-consumer.bat --topic test-topic --from-beginning --bootstrap-server localhost:9092

1번 bash 창이 메시지 전송 bash이다. 2번이 방금 입력한 메시지 수신 명령어!

수신 명령어를 치면 로그가 쭈르륵 올라오며 1번에서 보낸 메시지가 정상적으로 노출이 되는것을 볼 수 있다!!

5. 결론

Kafka를 도입하기 위해 구동시켜보았다. 확실히 이미지로 로드맵을 보는 것보다 직접 구동시키며 동작하는 과정을 보니 이해하기가 더 쉬웠다. Topic에서부터 Producer, Consumer까지 메시지가 이동되는 게 상당히 흥미로웠다.

최근 마인크래프트 서버를 운영하면서 Kafka를 활용한 실험을 진행할 계획이다. Kafka를 통해 서버와 클라이언트 간의 비동기 메시지 처리를 테스트하고, 실시간 데이터 전송 및 로그 수집을 자동화하는 방법을 탐색해볼 것이다. 이를 통해 Kafka의 확장성과 비동기 처리 모델이 게임 서버에서 어떻게 활용될 수 있는지 검증할 예정이다. 이를 바탕으로 앞으로 더 발전된 구조로 개선하고 실 업무에 도입할 생각이다. 재밌을 것 같다.

Kotlin 런타임 시간 개선하기

integerJI — Sun, 2 Feb 2025 16:14:07 +0900

이전 글 : Kotlin으로 Chunk 사용하기, Spring와 얼마나 다를까?

해당 글에서 이어집니다.

0. 런타임 시간을 줄일 수는 없을까?

문득 공부를 해보고 궁금해졌다. 코틀린 런타임 시간은 줄일 수 없을까? 줄일 수 있다면 어떤 방법이 있는지 알아보고 기존 소스를 개선할 수 있는점은 없을까하여 추가로 수정해보았다.

1. Kotlin Reflection (kotlin-reflect) 제거

kotlin-reflect는 주로 리플렉션 기능 (KClass, KProperty, KFunction 등)을 사용할 때 필요하지만, 현재 코드에서는 사용하지 않는다. 지워도 되는 이유는 아래의 이유가 있다.

클래스 정보를 동적으로 조회하지 않음 (::class 사용 없음)
프로퍼티나 함수 호출에 call() 같은 리플렉션 기능을 사용하지 않음
어노테이션을 런타임에 조회하는 코드가 없음
Spring Batch와 관련된 모든 컴포넌트가 일반적인 @Bean으로 사용됨

따라서 kotlin-reflect를 제거함으로써 런타임 실행을 줄일 수 있다.

But. 이럴 경우에는 필요할 수 있다.

만약 이후에 Kotlin 데이터 클래스의 copy(), toString(), equals(), hashCode() 같은 함수들을 리플렉션으로 처리하는 프레임워크(Jackson, Spring Validation, DI 등) 를 사용하게 되면, 다시 필요할 수 있다.
Spring에서 @ConfigurationProperties를 사용할 경우, 내부적으로 kotlin-reflect를 필요로 할 수 있다.

2. Kotlin Object 인스턴스 최적화

현재 data class 및 일반 클래스를 많이 사용하면 실행 시 객체가 계속 생성되면서 메모리를 많이 차지할 수 있다.

Kotlin에서는 object 키워드를 사용하면 싱글톤 객체를 생성할 수 있어, 불필요한 인스턴스 생성을 방지하고 메모리 사용량을 최적화할 수 있다. 이를 통해 동일한 기능을 수행하는 클래스의 반복적인 인스턴스 생성을 줄이고, 보다 효율적인 메모리 관리가 가능해진다.

어떤 부분을 object로 바꿔야 할까?

상수 값들을 담고 있는 객체
한 번만 생성되어야 하는 공통적인 함수/설정 값
불필요하게 매번 생성되는 고정 데이터
Mapper 또는 RowMapper 같은 반복 호출되는 객체

2-1. SQL Query / 설정값을 object로 관리

AS-IS

@Bean
fun itemReader(): JdbcCursorItemReader<InputType> {
    return JdbcCursorItemReaderBuilder<InputType>()
        .name("jdbcItemReader")
        .dataSource(dataSource)
        .sql("SELECT id, name, value, created_at FROM test_table") //   쿼리가 매번 객체로 생성됨
        .rowMapper { rs, _ ->
            InputType(
                rs.getString("name"),
                rs.getInt("value"),
                rs.getTimestamp("created_at").toLocalDateTime()
            )
        }
        .build()
}

기존 코드에서는 SQL 쿼리 문자열이 itemReader() 메서드가 호출될 때마다 새로운 객체로 생성된다. 동일한 SQL 문장이 반복적으로 메모리에 할당되는 상황

TO-BE

object QueryConstants {
    const val SELECT_TEST_TABLE = "SELECT id, name, value, created_at FROM test_table"
}

@Bean
fun itemReader(): JdbcCursorItemReader<InputType> {
    return JdbcCursorItemReaderBuilder<InputType>()
        .name("jdbcItemReader")
        .dataSource(dataSource)
        .sql(QueryConstants.SELECT_TEST_TABLE) //   문자열 객체 재사용
        .rowMapper { rs, _ ->
            InputType(
                rs.getString("name"),
                rs.getInt("value"),
                rs.getTimestamp("created_at").toLocalDateTime()
            )
        }
        .build()
}

object를 활용하여 SQL 쿼리를 상수로 선언하면, 애플리케이션 실행 중 단일 객체로 유지되며 JVM에서 재사용된다. 이를 통해 문자열 객체의 반복 생성을 방지하고, 메모리를 보다 효율적으로 사용할 수 있다.

2-2. RowMapper를 object로 최적화

AS-IS

.rowMapper { rs, _ ->
    InputType(
        rs.getString("name"),
        rs.getInt("value"),
        rs.getTimestamp("created_at").toLocalDateTime()
    )
}

rowMapper 람다가 itemReader() 호출 시마다 새롭게 생성된다. 이로 인해 불필요한 람다 인스턴스가 계속 생성되며, 메모리 사용이 증가.

TO-BE

object InputTypeRowMapper : RowMapper<InputType> {
    override fun mapRow(rs: ResultSet, rowNum: Int): InputType {
        return InputType(
            rs.getString("name"),
            rs.getInt("value"),
            rs.getTimestamp("created_at").toLocalDateTime()
        )
    }
}

@Bean
fun itemReader(): JdbcCursorItemReader<InputType> {
    return JdbcCursorItemReaderBuilder<InputType>()
        .name("jdbcItemReader")
        .dataSource(dataSource)
        .sql(QueryConstants.SELECT_TEST_TABLE)
        .rowMapper(InputTypeRowMapper) //   같은 객체를 계속 사용
        .build()
}

RowMapper를 object로 정의하여 싱글톤으로 관리하여 동일한 객체 재사용

2-3. ItemProcessor를 싱글톤 object로 변경

AS-IS

@Bean
fun itemProcessor(): ItemProcessor<InputType, OutputType> {
    return ItemProcessor { input ->
        OutputType(
            name = input.name.uppercase(),
            value = input.value * 2,
            createdAt = input.createdAt
        )
    }
}

기존 코드에서는 itemProcessor()가 호출될 때마다 새로운 ItemProcessor 인스턴스가 생성된다. 이는 불필요한 객체 할당 되는 중

TO-BE

object BatchItemProcessor : ItemProcessor<InputType, OutputType> {
    override fun process(input: InputType): OutputType {
        return OutputType(
            name = input.name.uppercase(),
            value = input.value * 2,
            createdAt = input.createdAt
        )
    }
}

@Bean
fun itemProcessor(): ItemProcessor<InputType, OutputType> = BatchItemProcessor

ItemProcessor를 object로 정의하여 싱글톤으로 관리, 동일한 객체를 재사용

2-4. PerformanceStepListener를 object로 변경

AS-IS

@Bean
fun step1(
    jobRepository: JobRepository,
    transactionManager: PlatformTransactionManager
): Step {
    return StepBuilder("step1", jobRepository)
        .chunk<InputType, OutputType>(1000, transactionManager)
        .reader(itemReader())
        .processor(itemProcessor())
        .writer(itemWriter())
        .listener(PerformanceStepListener()) //   매번 새로운 인스턴스 생성
        .allowStartIfComplete(false)
        .build()
}

PerformanceStepListener가 step1() 호출 시마다 새로운 인스턴스로 생성 중

TO-BE

// as-is
class PerformanceStepListener : StepExecutionListenerSupport()

// to-be
object PerformanceStepListener : StepExecutionListenerSupport()

class로 되어있는 PerformanceStepListener를 object로 바꾼다.

@Bean
fun step1(
    jobRepository: JobRepository,
    transactionManager: PlatformTransactionManager
): Step {
    return StepBuilder("step1", jobRepository)
        .chunk<InputType, OutputType>(1000, transactionManager)
        .reader(itemReader())
        .processor(itemProcessor())
        .writer(itemWriter())
        .listener(PerformanceStepListener) //   같은 객체를 재사용
        .allowStartIfComplete(false)
        .build()
}

인스턴스를 재사용

3. JdbcPagingItemReader를 사용해서 페이징 처리

@Bean
fun itemReader(): JdbcCursorItemReader<InputType> {
    return JdbcCursorItemReaderBuilder<InputType>()
        .name("jdbcItemReader")
        .dataSource(dataSource)
        .sql(QueryConstants.SELECT_TEST_TABLE)
        .rowMapper(InputTypeRowMapper) //   같은 객체를 계속 사용
        .build()
}

object BatchItemProcessor : ItemProcessor<InputType, OutputType> {
    override fun process(input: InputType): OutputType {
        return OutputType(
            name = input.name.uppercase(),
            value = input.value * 2,
            createdAt = input.createdAt
        )
    }
}

기존에는 JdbcCursorItemReader를 사용하여 한 번에 모든 데이터를 읽어오는 방식이다. 이 경우, 대용량 데이터를 처리할 때 메모리 사용량이 급격히 증가하는데 특히, 전체 데이터를 커서 기반으로 한꺼번에 메모리에 로드하기 때문에, 데이터 크기가 커질수록 OutOfMemory(메모리 부족)이 발생한다.

이 부분을 수정해보자

@Bean
fun itemReader(): JdbcPagingItemReader<InputType> {
    val pagingQueryProvider = SqlPagingQueryProviderFactoryBean().apply {
        setDataSource(dataSource)
        setSelectClause("id, name, value, created_at")
        setFromClause("from test_table")
        setSortKey("id") // 정렬 필수
    }.getObject()!!

    return JdbcPagingItemReaderBuilder<InputType>()
        .name("jdbcPagingItemReader")
        .dataSource(dataSource)
        .fetchSize(1000) // ✅ 한 번에 가져오는 개수 줄이기
        .rowMapper(InputTypeRowMapper)
        .queryProvider(pagingQueryProvider)
        .build()
}

object BatchItemProcessor : ItemProcessor<InputType, OutputType> {
    override fun process(input: InputType): OutputType = input.run {
        OutputType(
            name.uppercase(), // ✅ 기존 객체를 사용하여 최소한의 데이터 변경
            value * 2,
            createdAt
        )
    }
}

JdbcPagingItemReader를 사용하여 페이징 단위로 데이터를 가져오도록 변경하면, 한 번에 로드되는 데이터 개수를 제한할 수 있어 메모리 사용량을 효과적으로 줄일 수 있다.

실제로 효율적인지 확인해보자.

4. 어플리케이션 실행

페이징을 적용하기 전 JdbcCursorItemReader를 사용한 기존 방식에서는 실행 시간이 빠르지만, 메모리 사용량이 높고 CPU 활용도가 낮은 특징이 있었다.

chunk 크기	실행 시간(ms)	CPU 사용률 (%)	메모리 사용량 (MB)
1000	74689	0.09	143.88
5000	52788	0.01	117.95

과연 페이징 처리를 하면 어떻게 변할까?

4-1. chunk 1000, fetch size 1000

=== Batch Step Performance Metrics ===
Step Name: step1
Execution Time: 238215 ms
CPU Usage: 0.02 %
Memory Usage: 62.34 MB
Items Read: 1500000
Items Written: 1500000
======================================

오 ... chunk 1000일 경우 cpu와 memory 사용률이 눈에 뛰게 줄어들었다.

근데 .. 시간이 너무 오래걸린다. 아무래도 페이징 처리를 하다보니 이렇게 된 것 같다.

fetchSize를 올리고 스레드를 사용하여 병렬 처리를 해보기로 하였다.

4-2. chunk 1000, fetch size 5000

=== Batch Step Performance Metrics ===
Step Name: step1
Execution Time: 187629 ms
CPU Usage: 0.02 %
Memory Usage: 38.21 MB
Items Read: 1500000
Items Written: 1500000
======================================

chunk를 키워보자

fetchSize를 5000으로 증가하면서 실행 시간이 줄어들었고, 메모리 사용량도 감소하였다. 데이터 읽기 속도가 향상되었지만 여전히 시간이 오래 걸린다.

4-3. 변경 데이터 확인

chunk 크기	fetch size	실행 시간(ms)	CPU 사용률 (%)	메모리 사용량 (MB)
1000	1000	238215 (3분)	0.02	62.34
1000	5000	187629	0.02	38.21
5000	1000	161150	0.02	43.36
5000	5000	162954	0.13	69.71

사실 이쯤 되면 시간이 너무 오래 걸려서 이렇게 굳이 페이징 처리를 해야하나?

페이징 처리는 메모리 최적화에는 유리하지만, 실행 시간이 길어질 수 있다.사용 목적에 맞게 적절한 chunkSize와 fetchSize를 조절해야 하며, 무조건 페이징이 최적의 방법은 아니라고 생각이 든다.

5. 후기

사실 아직까지 코틀린을 써야 하는 이유가 명확하지 않다. 코틀린의 장점과 단점을 함께 비교해 보면 메모리 최적화나 객체 재사용 측면에서는 유리하지만, 실행 시간이 길어지는 문제가 있다. 이러한 점을 고려할 때, 특정 상황에서는 자바가 더 적합할 수도 있겠다고 생각한다.

저번에 공부한 것을 기반으로 메모리 점유률, cpu 사용률을 계산할 수 있어서 이것저것 해보고있었는데 흠,, 오늘의 결과는 조금 아쉽긴 하다. 물론 내가 올바른 방법으로 테스트를 한게 아닐 수도 있다. 그래도 기존과는 다른 접근 방식을 시도하면서 새로운 시각을 얻을 수 있어서 뿌듯하긴 하다. 다음에는 코틀린 말고 Java에 더 집중해서 공부를 해볼까 한다.

Kotlin으로 Chunk 사용하기, Spring와 얼마나 다를까?

integerJI — Sun, 19 Jan 2025 20:29:46 +0900

https://integer-ji.tistory.com/440

Spring Boot 3.x에서 Chunk 사용해서 데이터 read, write 사용률 알아보기

0. Chunk를 사용하는 이유는 뭘까?메모리 관리에 용이전체 데이터를 한 번에 로드하지 않고 설정된 Chunk 크기만큼 메모리에 유지시킨다. 대용량 데이터 처리 시에도 OutOfMemoryError를 방지할 수 있다

integer-ji.tistory.com

0. Kotlin과 차이가 있을까?

저번주에는 Spring Boot에서 Java 17을 이용해 Chunk의 메모리 사용량을 알아보았다.

여기서 궁금한 점.

Kotlin에서 Java 소스를 그대로 사용하게 된다면 과연 메모리 사용율은 어떻게 변할까?

큰 차이가 있을지 궁금하여 시도해 보았다.

1. 프로젝트 설정

1-1. 사용된 언어와 라이브러리 버전

kotlin 1.9.25
spring boot 3.3.6

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-batch:3.3.6")
    implementation("org.springframework.boot:spring-boot-starter-jdbc:3.3.6")
    implementation("org.jetbrains.kotlin:kotlin-reflect")
    compileOnly("org.projectlombok:lombok:1.18.36")
    runtimeOnly("com.microsoft.sqlserver:mssql-jdbc:12.6.4.jre11")
    annotationProcessor("org.projectlombok:lombok:1.18.36")
    testImplementation("org.springframework.boot:spring-boot-starter-test:3.3.6")
    testImplementation("org.springframework.batch:spring-batch-test:5.1.2")
    testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher:1.10.5")
}

이전 글과 동의.

1-2. 테이블 생성 및 데이터 Insert (mssql)

이전 글과 동의.

2. 배치 생성

Chunk를 사용하여 데이터를 Read, Write 하는 함수를 만듭니다.

package com.kin.batch.config

import com.kin.batch.listener.PerformanceStepListener
import com.kin.batch.model.InputType
import com.kin.batch.model.OutputType
import org.springframework.batch.core.Job
import org.springframework.batch.core.Step
import org.springframework.batch.core.job.builder.JobBuilder
import org.springframework.batch.core.repository.JobRepository
import org.springframework.batch.core.step.builder.StepBuilder
import org.springframework.batch.item.ItemProcessor
import org.springframework.batch.item.database.JdbcBatchItemWriter
import org.springframework.batch.item.database.JdbcCursorItemReader
import org.springframework.batch.item.database.builder.JdbcBatchItemWriterBuilder
import org.springframework.batch.item.database.builder.JdbcCursorItemReaderBuilder
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.springframework.transaction.PlatformTransactionManager
import javax.sql.DataSource

@Configuration
class BatchConfig(private val dataSource: DataSource) {

    @Bean
    fun batchJob(
        jobRepository: JobRepository,
        transactionManager: PlatformTransactionManager
    ): Job {
        return JobBuilder("batchJob", jobRepository)
            .start(step1(jobRepository, transactionManager))
            .build()
    }

    @Bean
    fun step1(
        jobRepository: JobRepository,
        transactionManager: PlatformTransactionManager
    ): Step {
        return StepBuilder("step1", jobRepository)
            .chunk<InputType, OutputType>(1000, transactionManager)
            .reader(itemReader())
            .processor(itemProcessor())
            .writer(itemWriter())
            .listener(PerformanceStepListener())
            .allowStartIfComplete(false)
            .build()
    }

    @Bean
    fun itemReader(): JdbcCursorItemReader<InputType> {
        return JdbcCursorItemReaderBuilder<InputType>()
            .name("jdbcItemReader")
            .dataSource(dataSource)
            .sql("SELECT id, name, value, created_at FROM test_table")
            .rowMapper { rs, _ ->
                InputType(
                    rs.getString("name"),
                    rs.getInt("value"),
                    rs.getTimestamp("created_at").toLocalDateTime()
                )
            }
            .build()
    }

    @Bean
    fun itemProcessor(): ItemProcessor<InputType, OutputType> {
        return ItemProcessor { input ->
            OutputType(
                name = input.name.uppercase(),
                value = input.value * 2,
                createdAt = input.createdAt
            )
        }
    }

    @Bean
    fun itemWriter(): JdbcBatchItemWriter<OutputType> {
        return JdbcBatchItemWriterBuilder<OutputType>()
            .dataSource(dataSource)
            .sql("INSERT INTO processed_table (name, value, created_at) VALUES (:name, :value, :createdAt)")
            .beanMapped()
            .build()
    }
}

나머지는 이전 글과 동일하다.

3. 메모리 체크 함수

package com.kin.batch.listener

import org.springframework.batch.core.ExitStatus
import org.springframework.batch.core.StepExecution
import org.springframework.batch.core.listener.StepExecutionListenerSupport
import java.lang.management.ManagementFactory
import com.sun.management.OperatingSystemMXBean
import java.time.Duration
import java.time.Instant
import java.time.LocalDateTime
import java.time.ZoneId

class PerformanceStepListener : StepExecutionListenerSupport() {

    private val runtime: Runtime = Runtime.getRuntime()

    override fun afterStep(stepExecution: StepExecution): ExitStatus {
        // 시작 시간과 종료 시간 가져오기
        val startTime: LocalDateTime = stepExecution.startTime ?: LocalDateTime.now()
        val endTime: LocalDateTime = stepExecution.endTime ?: LocalDateTime.now()

        // Instant 변환
        val startInstant: Instant = localDateTimeToInstant(startTime)
        val endInstant: Instant = localDateTimeToInstant(endTime)

        // 실행 시간 계산 (밀리초)
        val executionTimeMs: Long = Duration.between(startInstant, endInstant).toMillis()

        val cpuUsage: Float = getCpuUsage()
        val memoryUsage: Double = getMemoryUsage()

        printPerformanceMetrics(stepExecution, executionTimeMs, cpuUsage, memoryUsage)
        return stepExecution.exitStatus
    }

    private fun localDateTimeToInstant(localDateTime: LocalDateTime): Instant {
        return localDateTime.atZone(ZoneId.systemDefault()).toInstant()
    }

    private fun getCpuUsage(): Float {
        return try {
            val osBean: OperatingSystemMXBean =
                ManagementFactory.getPlatformMXBean(OperatingSystemMXBean::class.java)

            // 첫 번째 샘플링
            val startTime: Long = System.nanoTime()
            val startCpuTime: Double = osBean.processCpuTime.toDouble()

            // 100ms 대기
            Thread.sleep(100)

            // 두 번째 샘플링
            val endTime: Long = System.nanoTime()
            val endCpuTime: Double = osBean.processCpuTime.toDouble()

            // CPU 사용률 계산
            val elapsedTime: Long = endTime - startTime // 나노초
            val cpuUsage: Double = (endCpuTime - startCpuTime) / (elapsedTime * osBean.availableProcessors)

            // 퍼센트 단위로 변환
            (cpuUsage * 100).toFloat()
        } catch (e: Exception) {
            e.printStackTrace()
            0.0f // 오류 시 기본값
        }
    }

    private fun getMemoryUsage(): Double {
        // JVM 메모리 사용량 측정 (MB)
        val usedMemory: Long = runtime.totalMemory() - runtime.freeMemory()
        return usedMemory / (1024.0 * 1024.0) // MB 단위로 변환
    }

    private fun printPerformanceMetrics(
        stepExecution: StepExecution,
        executionTimeMs: Long,
        cpuUsage: Float,
        memoryUsage: Double
    ) {
        System.out.printf(
            """
                === Batch Step Performance Metrics ===
                Step Name: %s
                Execution Time: %d ms
                CPU Usage: %.2f %%
                Memory Usage: %.2f MB
                Items Read: %d
                Items Written: %d
                ======================================
                """.trimIndent(),
            stepExecution.stepName,
            executionTimeMs,
            cpuUsage,
            memoryUsage,
            stepExecution.readCount,
            stepExecution.writeCount
        )
    }
}

이전 글과 동의.

4. 배치 수행

테스트는 Java와 마찬가지로 1,500,000건으로 테스트를 진행해 보았다.

mssql을 사용했고 서버는 docker container로 올렸다.

이번에는 배치 수행 전 평시 상태를 체크해 보았다.

평온하다.

평온한 도커에 돌을 던져보자

4-1. 애플리케이션 수행

=== Batch Step Performance Metrics ===
Step Name: step1
Execution Time: 74689 ms
CPU Usage: 0.09 %
Memory Usage: 143.88 MB
Items Read: 1500000
Items Written: 1500000
======================================

앗 Java 보다 자원을 많이 쓴 거 같은데?

도커 DB CPU는 74% 정도 사용했다.

(java는 80% 넘게 사용됐다.)

청크를 높여보자

chunk 5000

=== Batch Step Performance Metrics ===
Step Name: step1
Execution Time: 52788 ms
CPU Usage: 0.01 %
Memory Usage: 117.95 MB
Items Read: 1500000
Items Written: 1500000
======================================

마찬가지로 메모리 사용량이 되게 높다.

CPU는 77.68%

애플리케이션의 메모리를 정리해 본다면

chunk 크기	실행 시간(ms)	CPU 사용률 (%)	메모리 사용량 (MB)
1000	74689	0.09	143.88
5000	52788	0.01	117.95

흠 정리를 해보자.

5. 마무리

5-1. 비교 정리

실행 시간

* Java (chunk 1000): 80,352ms

* Kotlin (chunk 1000): 74,689ms

Kotlin이 약 7% 더 빠른 실행 속도를 보임

애플리케이션 메모리 사용

* Java (chunk 1000): 48.31MB

* Kotlin (chunk 1000): 143.88MB

Kotlin이 약 3배 더 많은 메모리를 사용

DB CPU 사용률

Java: 최대 80% 이상

Kotlin: 최대 74%

Kotlin이 DB CPU를 조금 더 효율적으로 사용

5-2. 정리

DB 서버의 리소스 사용과 전반적인 실행 속도에서는 kotiln이 더 우세한 성능을 보였다. 하지만 어플리케이션 메모리 사용량에서는 Java가 더 효율적이었다. 이 이유는 kotiln이 런타임 라이브러리가 크기때문에 많이 사용되는 거라고 추정된다.

그리고 kotiln을 사용하는데 정말 편했다. 나는 Python과 Java를 사용하고 있는데 딱 두개의 장점을 섞어놓은 듯한 느낌을 받았다. 특히 java에서 만든 소스 그대로 kotiln에서 사용하는게 너무 편했다

5-3. 짧은 회고

kotiln을 연구하는 이유는 많은 회사에서 kotiln을 도입한 이유를 알고 싶었고 이미 고착화된 java를 버리고 kotiln으로 넘어가야하나?라는 의문점에 답변을 하고싶었다.

그렇게 Java와 Kotiln을 비교해가며 사용해보니 각각의 장점을 알 수 있었다. 또한 이러한 연구방식은 처음 시도해 보는데 CPU, 메모리의 사용량을 알기위해 라이브러리도 처음 써보고 Docker 컨테이너를 사용해서 상태분석도 해봤다. 물론 이게 옳지 않을 수도 있다. 하지만 이러한 방향성을 잡은 지금으로써는 더 다듬어가며 앞으로의 연구에 도움이 될 것 같아서 많이 뿌듯하다.

Spring Boot 3.x에서 Chunk 사용해서 데이터 read, write 사용률 알아보기

integerJI — Tue, 24 Dec 2024 14:28:16 +0900

0. Chunk를 사용하는 이유는 뭘까?

메모리 관리에 용이
- 전체 데이터를 한 번에 로드하지 않고 설정된 Chunk 크기만큼 메모리에 유지시킨다.
- 대용량 데이터 처리 시에도 OutOfMemoryError를 방지할 수 있다.
- Garbage Collection 부하가 감소된다.
2. 트랜잭션 관리
- Chunk 단위로 트랜잭션 처리가 되기 때문에 전체적인 프로세스 안정성에 향상된다.
3. 성능 최적화
- JDBC Batch 처리와 결합하여 데이터베이스 작업에 최적화한다.
- 네트워크 통신 횟수를 감소시킨다.
- 데이터베이스에 부하를 분산시킨다.

크게 이 3가지로 보인다.

나는 회사 프로젝트에서 대용량 데이터를 조금 더 효율적으로 다루어 보기 위해 테스트를 진행해 보았다.

1. 프로젝트 설정

1-1. 사용된 언어와 라이브러리 버전

Java 17
spring boot 3.3.6

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-batch:3.3.6'
	implementation 'org.springframework.boot:spring-boot-starter-jdbc:3.3.6'
	compileOnly 'org.projectlombok:lombok:1.18.36'
	runtimeOnly 'com.microsoft.sqlserver:mssql-jdbc:12.6.4.jre11'
	annotationProcessor 'org.projectlombok:lombok:1.18.36'
	testImplementation 'org.springframework.boot:spring-boot-starter-test:3.3.6'
	testImplementation 'org.springframework.batch:spring-batch-test:5.1.2'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher:1.10.5'
}

1-2. 테이블 생성 및 데이터 Insert (mssql)

-- 테스트 데이터를 저장할 테이블
CREATE TABLE test_table (
    id BIGINT IDENTITY PRIMARY KEY, -- 자동 증가 ID
    name NVARCHAR(100),             -- 이름
    value INT,                      -- 랜덤 값
    created_at DATETIME             -- 생성 날짜
);

-- 처리된 데이터를 저장할 테이블
CREATE TABLE processed_table (
    id BIGINT IDENTITY PRIMARY KEY, -- 자동 증가 ID
    name NVARCHAR(100),             -- 변환된 이름
    value INT,                      -- 변환된 값
    created_at DATETIME             -- 생성 날짜
);

-- 대용량 데이터 삽입
SET NOCOUNT ON;

DECLARE @Counter INT = 1;

WHILE @Counter <= 300000
BEGIN
    INSERT INTO test_table (name, value, created_at)
    VALUES (
        CONCAT('TestName_', @Counter),        -- 고유한 이름
        ABS(CHECKSUM(NEWID()) % 10000),       -- 랜덤 값 (0~9999)
        DATEADD(SECOND, @Counter, GETDATE()) -- 고유한 생성 날짜
    );
    SET @Counter = @Counter + 1;
END;

2. 배치 생성

Chunk를 사용하여 데이터를 Read, Write 하는 함수를 만듭니다.

package com.home.batch.config;

import com.home.batch.listener.PerformanceStepListener;
import com.home.batch.model.InputType;
import com.home.batch.model.OutputType;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.item.ItemProcessor;
import org.springframework.batch.item.database.JdbcBatchItemWriter;
import org.springframework.batch.item.database.JdbcCursorItemReader;
import org.springframework.batch.item.database.builder.JdbcBatchItemWriterBuilder;
import org.springframework.batch.item.database.builder.JdbcCursorItemReaderBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

import javax.sql.DataSource;

@Configuration
public class BatchConfig {

    private final DataSource dataSource;

    public BatchConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Bean
    public Job batchJob(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
        return new JobBuilder("batchJob", jobRepository)
                .start(step1(jobRepository, transactionManager))
                .build();
    }

    @Bean
    public Step step1(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
        return new StepBuilder("step1", jobRepository)
                .<InputType, OutputType>chunk(1000, transactionManager)
                .reader(itemReader())
                .processor(itemProcessor())
                .writer(itemWriter())
                .listener(new PerformanceStepListener())
                .allowStartIfComplete(false)
                .build();
    }

    @Bean
    public JdbcCursorItemReader<InputType> itemReader() {
        return new JdbcCursorItemReaderBuilder<InputType>()
                .name("jdbcItemReader")
                .dataSource(dataSource)
                .sql("SELECT id, name, value, created_at FROM test_table")
                .rowMapper((rs, rowNum) -> new InputType(
                        rs.getString("name"),
                        rs.getInt("value"),
                        rs.getTimestamp("created_at").toLocalDateTime()
                ))
                .build();
    }

    @Bean
    public ItemProcessor<InputType, OutputType> itemProcessor() {
        return input -> new OutputType(
                input.getName().toUpperCase(),
                input.getValue() * 2,
                input.getCreatedAt()
        );
    }

    @Bean
    public JdbcBatchItemWriter<OutputType> itemWriter() {
        return new JdbcBatchItemWriterBuilder<OutputType>()
                .dataSource(dataSource)
                .sql("INSERT INTO processed_table (name, value, created_at) VALUES (:name, :value, :createdAt)")
                .beanMapped()
                .build();
    }
}

하나씩 알아보자

2-1. Step

@Bean
public Step step1(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
    return new StepBuilder("step1", jobRepository)
            .<InputType, OutputType>chunk(1000, transactionManager)
            .reader(itemReader())
            .processor(itemProcessor())
            .writer(itemWriter())
            .listener(new PerformanceStepListener())
            .allowStartIfComplete(false)
            .build();
}

chunk를 100으로 설정한다.

reader -> processor -> writer 하나의 묶음으로 동작한다.

listener을 통하여 메타데이터를 확인한다.

allowstartIfComplete를 false로 설정하여 완료된 Step은 재실행되지 않도록 한다.

2-2. reader

@Bean
public JdbcCursorItemReader<InputType> itemReader() {
    return new JdbcCursorItemReaderBuilder<InputType>()
            .name("jdbcItemReader")
            .dataSource(dataSource)
            .sql("SELECT id, name, value, created_at FROM test_table")
            .rowMapper((rs, rowNum) -> new InputType(
                    rs.getString("name"),
                    rs.getInt("value"),
                    rs.getTimestamp("created_at").toLocalDateTime()
            ))
            .build();
}

test_table 테이블에서 데이터를 조회한다.

테스트를 위해 30만 건 Insert.

2-3. processor

@Bean
public ItemProcessor<InputType, OutputType> itemProcessor() {
    return input -> new OutputType(
            input.getName().toUpperCase(),
            input.getValue() * 2,
            input.getCreatedAt()
    );
}

로직 수행을 위해 read에서 읽은 데이터를 변환한다.

name는 대문자로, value는 두배로 증폭.

2-4. writer

@Bean
public JdbcBatchItemWriter<OutputType> itemWriter() {
    return new JdbcBatchItemWriterBuilder<OutputType>()
            .dataSource(dataSource)
            .sql("INSERT INTO processed_table (name, value, created_at) VALUES (:name, :value, :createdAt)")
            .beanMapped()
            .build();
}

작업 완료된 데이터를 processed_table에 inert를 진행한다.

3. 메모리 체크 함수 생성

배치가 수행되는 동안 애플리케이션의 메모리를 체크합니다.

package com.home.batch.listener;

import org.springframework.batch.core.ExitStatus;
import org.springframework.batch.core.StepExecution;
import org.springframework.batch.core.listener.StepExecutionListenerSupport;

import java.lang.management.ManagementFactory;
import com.sun.management.OperatingSystemMXBean;
import java.time.Duration;
import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;

public class PerformanceStepListener extends StepExecutionListenerSupport {

    private final Runtime runtime;

    public PerformanceStepListener() {
        this.runtime = Runtime.getRuntime();
    }

    @Override
    public ExitStatus afterStep(StepExecution stepExecution) {
        LocalDateTime startTime = stepExecution.getStartTime() != null
                ? stepExecution.getStartTime()
                : LocalDateTime.now();

        LocalDateTime endTime = stepExecution.getEndTime() != null
                ? stepExecution.getEndTime()
                : LocalDateTime.now();

        Instant startInstant = localDateTimeToInstant(startTime);
        Instant endInstant = localDateTimeToInstant(endTime);

        long executionTimeMs = Duration.between(startInstant, endInstant).toMillis();

        float cpuUsage = getCpuUsage();
        double memoryUsage = getMemoryUsage();

        printPerformanceMetrics(stepExecution, executionTimeMs, cpuUsage, memoryUsage);
        return stepExecution.getExitStatus();
    }

    private Instant localDateTimeToInstant(LocalDateTime localDateTime) {
        return localDateTime.atZone(ZoneId.systemDefault()).toInstant();
    }

    private float getCpuUsage() {
        try {
            OperatingSystemMXBean osBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);
            long startTime = System.nanoTime();
            double startCpuTime = osBean.getProcessCpuTime();

            Thread.sleep(100); // 100ms 대기

            long endTime = System.nanoTime();
            double endCpuTime = osBean.getProcessCpuTime();

            return (float) ((endCpuTime - startCpuTime) / (endTime - startTime) * 100 / osBean.getAvailableProcessors());
        } catch (Exception e) {
            e.printStackTrace();
            return 0.0f;
        }
    }

    private double getMemoryUsage() {
        return (runtime.totalMemory() - runtime.freeMemory()) / (1024.0 * 1024.0);
    }

    private static void printPerformanceMetrics(StepExecution stepExecution, long executionTimeMs, float cpuUsage, double memoryUsage) {
        System.out.printf("""
                === Batch Step Performance Metrics ===
                Step Name: %s
                Execution Time: %d ms
                CPU Usage: %.2f %%
                Memory Usage: %.2f MB
                Items Read: %d
                Items Written: %d
                ======================================
                """,
                stepExecution.getStepName(),
                executionTimeMs,
                cpuUsage,
                memoryUsage,
                stepExecution.getReadCount(),
                stepExecution.getWriteCount()
        );
    }
}

3-1. StepExecutionListenerSupport

public class PerformanceStepListener extends StepExecutionListenerSupport

Spring Batch의 StepExecutionListenerSupport를 상속받아 Step 실행 이후(afterStep)에 특정 작업을 수행할 수 있도록 확장했다.

3-2. runtime

public PerformanceStepListener() {
    this.runtime = Runtime.getRuntime();
}

JVM 메모리 정보를 얻기 위해 Java의 Runtime 인스턴스를 사용

3-3. afterStep

@Override
public ExitStatus afterStep(StepExecution stepExecution) {
    LocalDateTime startTime = stepExecution.getStartTime() != null
            ? stepExecution.getStartTime()
            : LocalDateTime.now();

    LocalDateTime endTime = stepExecution.getEndTime() != null
            ? stepExecution.getEndTime()
            : LocalDateTime.now();

    Instant startInstant = localDateTimeToInstant(startTime);
    Instant endInstant = localDateTimeToInstant(endTime);

    long executionTimeMs = Duration.between(startInstant, endInstant).toMillis();

    float cpuUsage = getCpuUsage();
    double memoryUsage = getMemoryUsage();

    printPerformanceMetrics(stepExecution, executionTimeMs, cpuUsage, memoryUsage);
    return stepExecution.getExitStatus();
}

private Instant localDateTimeToInstant(LocalDateTime localDateTime) {
    return localDateTime.atZone(ZoneId.systemDefault()).toInstant();
}

private float getCpuUsage() {
    try {
        OperatingSystemMXBean osBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);
        long startTime = System.nanoTime();
        double startCpuTime = osBean.getProcessCpuTime();

        Thread.sleep(100); // 100ms 대기

        long endTime = System.nanoTime();
        double endCpuTime = osBean.getProcessCpuTime();

        return (float) ((endCpuTime - startCpuTime) / (endTime - startTime) * 100 / osBean.getAvailableProcessors());
    } catch (Exception e) {
        e.printStackTrace();
        return 0.0f;
    }
}

private double getMemoryUsage() {
    return (runtime.totalMemory() - runtime.freeMemory()) / (1024.0 * 1024.0);
}

실행 시간 계산
- Step의 시작 시간(startTime)과 종료 시간(endTime)을 기반으로 실행 시간을 계산
- 시작/종료 시간이 null인 경우, 현재 시간을 사용
CPU 사용량 계산
- OperatingSystemMXBean 사용
- osBean.getProcessCpuTime()과 시스템 시간(System.nanoTime())을 사용하여 CPU 사용 시간 측정
- Thread.sleep(100). Cpu 사용량을 계산하기 위해 100ms 대기
- CPU 사용률 = CPU 사용 시간 차이 ÷ 시스템 시간 차이 ÷ CPU 코어 수 × 100
메모리 사용량 계산
- Runtime 객체 사용
- totalMemory(): JVM에 할당된 총 메모리
- freeMemory(): JVM에서 사용 가능한 메모리
- 사용 메모리 = 총 메모리 - 사용 가능한 메모리
- 계산 결과를 MB 단위로 변환(/ (1024.0 * 1024.0))
4. 결과 출력
- 계산된 값들을 print로 찍어낸다.

4. 배치 수행

1,500,000건으로 테스트를 진행해 보았다.

mssql을 사용했고 서버는 docker container로 올렸다.

4-1. 어플리케이션 수행 (chunk 1000)

=== Batch Step Performance Metrics ===
Step Name: step1
Execution Time: 80352 ms
CPU Usage: 0.01 %
Memory Usage: 48.31 MB
Items Read: 1500000
Items Written: 1500000
======================================

chunk 1000건으로 수행하면

1,500,000만 건 기준으로

Cpu는 0.01%, Memory는 48MB 사용된 부분을 알 수 있다

execution time도 80초, 하지만 1천 단위로 끊어 썼기 때문에 더 안정적이라 생각된다.

이 정도면 많이 양호하다 생각된다

4-2. 도커 상태 확인

평시

데이터를 삽입하기 위해 잠깐 Cpu가 튀긴 했지만 무난한 수준이다.

배치 수행 후 (chunk 1000)

Cpu 사용도 Max 80% 이하이다.

양호하다고 생각된다.

메모리 사용율도 양호한데?

청크를 높여보자

chunk 5000

=== Batch Step Performance Metrics ===
Step Name: step1
Execution Time: 52986 ms
CPU Usage: 0.01 %
Memory Usage: 85.33 MB
Items Read: 1500000
Items Written: 1500000
======================================

시간은 빨리 처리 되었지만 메모리가 많이 먹는다.

cpu는 아까부터 0.01인데 저부분은 확인해 봐야겠다.

-> 정말 CPU를 안쓴 것이었다.

Cpu가 조금 더 오르긴 하다.

85%까지 올랐다.

어플리케이션의 메모리를 정리해 본다면

chunk 크기	실행 시간(ms)	CPU 사용률 (%)	메모리 사용량 (MB)
1000	80352	0.01	48.31
5000	52986	0.01	85.33

5. 마무리

회사 프로젝트에서 사용하는 방식에서 문제가 생겨 다른 방법을 찾아보다 chunk는 얼마나 효율이 좋을지 증명하기 위해 해당 글을 작성해 보았다.

chunk를 적용하지 않은 버전을 올리지는 않았지만 회사 프로젝트에서 사용하던 방식과 위의 로직을 적용한 버전으로 비교하면 성능이 개선되었기는 했다.

이제 이 연구를 바탕으로 업무에 적용해 결과를 도출할 계획이다.

추가로 코프링을 이용하여 더 넓은 지식을 습득하고 최적의 방식을 도출해 낼 수 있을 것 같다.

OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended

integerJI — Tue, 10 Dec 2024 13:49:24 +0900

해당 에러는 jdk 17 이상 버전에서 gradle를 실행할때 경고문으로 발생한다

OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended

tasks.named('test') {
    useJUnitPlatform()
    jvmArgs '-Xshare:off'
}

jvmArgs '-Xshare:off'

해당 문구를 넣어주자.

spring batch 5.0 JobBuilderFactory, StepBuilderFactory

integerJI — Sun, 24 Nov 2024 10:36:41 +0900

'org.springframework.batch.core.configuration.annotation.StepBuilderFactory' is deprecated since version 5.0.0 and marked for removal

'org.springframework.batch.core.configuration.annotation.JobBuilderFactory' is deprecated since version 5.0.0 and marked for removal

Spring Batch 5.0 이상부턴 JobBuilderFactory, StepBuilderFactory을 사용하려면 해당 경고문이 나온다.

https://github.com/spring-projects/spring-batch/wiki/Spring-Batch-5.0-Migration-Guide

Spring Batch 5.0 Migration Guide

Spring Batch is a framework for writing batch applications using Java and Spring - spring-projects/spring-batch

github.com

공식 문서를 보면

JobBuilderFactory

// Sample with v5
@Configuration
@EnableBatchProcessing
public class MyJobConfig {

    @Bean
    public Job myJob(JobRepository jobRepository, Step step) {
        return new JobBuilder("myJob", jobRepository)
                .start(step)
                .build();
    }

}

StepBuilderFactory

// Sample with v5
@Configuration
@EnableBatchProcessing
public class MyStepConfig {

    @Bean
    public Tasklet myTasklet() {
       return new MyTasklet();
    }

    @Bean
    public Step myStep(JobRepository jobRepository, Tasklet myTasklet, PlatformTransactionManager transactionManager) {
        return new StepBuilder("myStep", jobRepository)
                .tasklet(myTasklet, transactionManager) // or .chunk(chunkSize, transactionManager)
                .build();
    }

}

이렇게 사용하라고 가이드가 나온다.

정리하자면

JobBuilderFactory -> JobRepository

Mac m1 docker Mssql 설치하기

integerJI — Fri, 22 Nov 2024 18:59:27 +0900

Mssql은 말 그대로 Microsoft SQL Server이다.

따라서 Mac Os에서는 지원이 안되지만

docker를 설치하여 mssql을 사용할 수 있다.

1. Docker-desktop 다운받기

https://www.docker.com/products/docker-desktop/

Docker Desktop: The #1 Containerization Tool for Developers | Docker

Docker Desktop is collaborative containerization software for developers. Get started and download Docker Desktop today on Mac, Windows, or Linux.

www.docker.com

해당 사이트에서 본인의 OS에 맞게 docker을 설치해주자

2. Mssql image 다운받기

docker desktop를 실행하고 좌측 하단의 terminal을 열어 명령어를 입력해 주어야 한다.

https://hub.docker.com/r/microsoft/mssql-server

hub.docker.com

공식 문서를 보면

docker pull mcr.microsoft.com/mssql/server:2022-latest

해당 이미지를 사용하라고 가이드를 주지만 이 image는 mac m1 arm64 칩에서는 사용하지 못한다..

* image may have poor performance or fail if run via emulation

아래의 이미지를 다운받자

docker pull mcr.microsoft.com/azure-sql-edge:latest

azure-sql은 경고 문구가 뜨지 않는 모습을 볼 수 있다.

이제 안쓰는 이미지는 지우고 컨테이너를 실행시키자

3. 컨테이너 실행

docker run --cap-add SYS_PTRACE -e 'ACCEPT_EULA=1' -e 'MSSQL_SA_PASSWORD=$PASSWORD' -p 1433:1433 --name mssql -d mcr.microsoft.com/azure-sql-edge

$PASSWORD 대신에 패스워드를 입력하자.

1. 8자리 이상

2. 대문자, 소문자, 숫자 및 특수 문자 중 3가지 이상을 포함해야 한다.

아니게 될 경우 이런 에러를 볼 수 있다. -> https://integer-ji.tistory.com/435

컨테이너를 실행해 보면

정상 작동하는 모습을 볼 수 있다.

3. DB 관리툴 dbeaver 다운받기

https://dbeaver.io/

DBeaver Community | Free Universal Database Tool

DBeaver Universal Database Tool DBeaver Community is a free cross-platform database tool for developers, database administrators, analysts, and everyone working with data. It supports all popular SQL databases like MySQL, MariaDB, PostgreSQL, SQLite, Apach

dbeaver.io

DB 관리툴로 편하신거 쓰시면 됩니다.

jetbrains사의 datagrip / ms사의 azure 등등

저는 DBeaver으로 진행하겠습니다.

SQL Server 선택

Host : localhost

Port : 1433 (mssql 기본 포트)

Database : master

Authentication : SQL Server Authentication

Username : sa (mssql 기몬 username)

Password : 컨테이너 실행하며 설정하였던 password 입력

Test Connection ... 클릭

연결 성공!

이제 맥북에서 mssql을 사용하시면 됩니다.

docker permission denied while trying to connect to the docker daemon socket

integerJI — Wed, 20 Nov 2024 08:07:13 +0900

docker containers를 실행하는데 해당 에러가 났다.

권한이 없어서 이런거니 권한을 주면 된다.

/var/run/docker.sock 파일 권한 변경

sudo chmod 666 /var/run/docker.sock

ERROR: Unable to set system administrator password: Password validation failed. The password does not meet SQL Server password policy requirements because it is not complex enough. The password must be at least 8 characters long and contain characters fro

integerJI — Tue, 19 Nov 2024 14:29:51 +0900

ERROR: Unable to set system administrator password: Password validation failed. The password does not meet SQL Server password policy requirements because it is not complex enough. The password must be at least 8 characters long and contain characters from three of the following four sets: Uppercase letters, Lowercase letters, Base 10 digits, and Symbols.

이 에러는 mssql을 설치할 때 발생한다.

아래의 조건을 만족 시켜야 정상적으로 db가 만들어질 것이다.

1. 최소 8자 이상.

2. 대문자, 소문자, 숫자 및 특수 문자 중 3가지 이상을 포함해야 합니다.

rest docs RequestDocumentation requestParameters Cannot resolve symbol 'requestParameters' 이슈

integerJI — Wed, 13 Nov 2024 13:40:57 +0900

rest docs 프로젝트를 사용하고 있는데

spring 버전 업을 하고 난 뒤

Cannot resolve symbol 'requestParameters'

해당 이슈가 발생되며 requestParameters를 사용할 수 없었다.

queryParameters를 사용해서 해결

퍼실리테이션 테크닉

integerJI — Fri, 8 Nov 2024 09:51:23 +0900

회사에서 학습 동아리를 하고있다.

한 권으로 끝내는 퍼실리테이션 테크닉을 읽고 3장 부분을 요약해보았다!

퍼실리테이션 테크닉: 제 3장 요약

1. 여행자와 가이드의 마음가짐

이 장에서는 워크숍이나 조직 활동에서 필요한 퍼실리테이터의 자세와 기술을 다루고있다. 새로운 문화와 관습을 받아들이는 열린 마음이 중요하다고 생각되는 장이었다.

주의해야 할 6가지 행동

1.1. 공감

공감은 타인의 감정을 이해하고 공유하는 능력입니다. 공감의 네 가지 단계는 다음과 같습니다:

공감 A: 타인의 고통 인지와 해결 의지
동조 B: 타인의 감정 이해와 공명
연민 C: 타인의 감정에 동화
호의 D: 타인의 안녕과 행복 기원

공감 능력을 향상시키기 위한 세 가지 방법:

자신을 들여다보기
타인을 이해하기
타인과 연결되기

1.2. 적극적 경청

적극적 경청은 공감 능력을 기르는 핵심입니다. 경청의 10가지 규칙을 실천하세요.

1.3. 겸손

겸손한 태도를 기르기 위한 7일 트레이닝 방법을 소개합니다.

1.4. 다른 말로 표현하기

상대방의 말을 다양한 방식으로 재표현하는 기술을 익히세요:

메아리: 상대방의 말을 반복
거울: 자신의 단어로 재표현
요약: 들은 내용을 종합
명료화: 말을 더 명확하게 만들기

1.5. 질문하기

강력한 질문 기법을 활용하세요:

만약에 질문
미래를 예상하는 질문
주어진 정보에 대한 질문

1.6. 침묵과 중립성

침묵의 가치를 이해하고, 중립성을 유지하는 방법을 배웁니다.

2. 훌륭한 조직 이끌기

효과적인 퍼실리테이션을 위한 추가 팁:

적절한 에너지 수준 유지하기
명확하고 참여를 유도하는 지시 만들기
적절한 유머 사용하기
즉흥적 대응 능력 기르기

즉흥의 기본 요소

신뢰
경청
효율성
존중
단순성
수용

이러한 기술과 태도를 습득하고 실천함으로써, 더 효과적인 퍼실리테이터가 될 수 있다고 설명하고 있습니다.

3장을 공부하며 제일 인상 깊었던 내용은 적극적 경청이다.

공감능력을 기른다는 것 자체가 경청하는 자세를 기르는 것이며 이는 곧 집단에 큰 이해와 공감을 이끌어 낼 수 있는 단계라고 생각된다.

흑백요리사 철가방요리사 식당 도량 동파육, 어향가지튀김 후기

integerJI — Thu, 7 Nov 2024 16:45:37 +0900

https://naver.me/GlVbCkgI

도량 : 네이버

방문자리뷰 272 · 블로그리뷰 631

m.place.naver.com

경복궁역 3번출구에 있는 중식당 "도량"에 다녀왔다.

도량은 현재 캐치테이블과 현장예약을 받고 있었는데

현장예약은 새벽에 가서 줄서도 겨우 먹을까 말까 한다고 한다

근데 우연히도 .. 운이 좋게도 !!! 캐치테이블에서 예약을 성공해버렸다 !!!

예약 성공 후 바로 달려갔다

11시 예약이라 11시 땡 하고 도착했는데 그래도 웨이팅 하시는 분들이 조금 계셨다.

아마 현장 웨이팅 아침 일찍 하고 입장대기하고 있는 것 같았다.

뭘 먹을까 고민을 정말 많이했다.

유튜브 성시경의 먹을텐데에 따르면 훠궈와 함께 동파육을 먹었는데

훠궈를 먹을것인가 다른 메뉴를 먹을것인가 너~~~무 고민이었다.

결국 내가 선택한 메뉴는 ,,

동파육과 어향가지튀김과 마라샹궈!!!

동파육은 정말 입에 넣자마자 고기가 녹는 느낌이 너무 환상적이었다.

고기가 이렇게 요리가 된다고?!?!의 깜짝놀랄맛

청경채도 익힘정도가 아주 굿이었다

다음은 어향가지인데 이 친구가 진짜 맛있었다.

단순하게 가지튀김을 생각했지만

가지안에 새우살의 크기들과 맛, 익힘이 너무 좋았고

처음 씹었을때의 새우향과 육즙, 그리고 중간에는 부드러운 식감의 새우들이 너무 환상적이었다.

거기다 칠리?느낌의 소스는 튀김의 느끼한 맛을 잡아주며 달달한 맛까지 나서 음식의 조화가 뛰어나다고 생각했다.

오늘의 Best Pick였다.

마지막으론 샹궈!

ㅎ.. 2명이서 갔는데 많이도 먹었다.

샹궈는 조금 평범한? 느낌이었다.

아직 나는 마라 초보인데 먹을만 했고 뭔가 마라향이 강하진 않았던거같다.

음 ~ 마라샹궈는 Not Bad 나쁘지 않았다.

3가지 음식을 먹으면서 느낀건

동파육은 확실히 이러한 음식이 식으면 고기가 질겨지고 조금 차가워진 반면

어향가지 튀김은 식어도 너무 맛있었다.

개인적인 순서로는 1. 어향가지튀김 2. 동파육 3. 마라샹궈 인데

동파육은 식기 전에 다 먹어버리면 그만이니까 ^.^

어향가지튀김과 동파육은 꼭 추천하는 메뉴인 것 같다.

마지막으론 집가는 길에 이쁜 경복궁 길을 보며 마무리

그리고 첫 번째 오블완 완료!

2024 JTBC 풀 마라톤을 완주하며 회고

integerJI — Wed, 6 Nov 2024 11:28:35 +0900

11월 3일 JTBC에서 주최하는 풀 마라톤에 참가했다.

풀 마라톤은 참가는 처음이 아니지만 두 번째 참가하며 느낀 점과 내가 풀 마라톤을 뛴 이유, 그리고 달리기를 하는 이유를 잊지 않기 위해 회고글을 적는다.

풀 마라톤을 하게 된 이유

나는 생각이 많다. 그래서 생각을 멈추는 법을 잘 몰랐는데, 군대에서 시작한 마라톤과 주기적인 달리기를 통해 몸이 너무 힘들면 생각하지 않게 된다는 것을 알게 되었다. 이 후로는 집 앞 하천을 뛰며 머릿속을 비우고 리프레시하는 것을 습관처럼 하게 되었다.

시간이 흘러 10km 달리기가 익숙해졌을 무렵, 풀 마라톤에 도전하고 싶어졌다. 그렇게 작년 2023 JTBC 풀 마라톤에 참여하게 되었는데 이때의 나는 나의 장거리 페이스도 모르고 아무 준비도 안된 상태에서 안되면 말고 식으로 참여하게 되었다. 결국 26km 즈음에서 무릎의 통증을 이기지 못해 중도에 포기하게 되었다. 작년의 포기한 기억이 있어서 이번 2024 마라톤에서는 악으로 깡으로 버티며 꼭 완주하고 싶었다.

회사에는 보디빌딩 대회에 나가시는 분이 있었다. 그분은 음식과 술을 좋아했지만, 목표가 생기니 모든 것을 끊고 식단과 자기 관리를 통해 대회에서 우승까지 하셨다. 그 모습을 보고 '나는 지금 이 마라톤 대회를 진심으로 대하고 있을까?' 하는 의문이 들며 그 순간 이렇게 살다가는 작년처럼 실패할 것 같다는 느낌이 들었다.

10월부터는 최대한 약속을 줄이고 운동에만 전념했다. 달리기에 익숙한 몸 상태를 만들며 대회 2주 전에는 30km 장거리 훈련도 하며 내 페이스를 천천히 익혀 나아갔다. 그렇게 긴장 속에서 대회날을 맞이했다.

마라톤을 진행하며

E조 그룹 출발 대기를 하며 완주 후 내 모습은 어떨까 상상을 하였다. 나는 이때까지만 해도 드디어 끝났구나, 내가 해냈구나 하는 감동과 함께 눈물이 흘러나올 줄 알았다. 또한 혼자 참가했기에, '혼자서도 할 수 있다'를 되뇌며 끝까지 달려야겠다고 생각했다. 게다가 30km 이상의 거리를 달린 경험이 있었으니 나 자신을 믿자고 다짐했다.

하지만 실제로는 전혀 달랐다. 나는 혼자 뛰었다고 생각했지만, 아침 일찍부터 코스 옆에서 응원해 주는 러닝 크루들, 응원가 힘내라는 말을 건네는 할머니, 할아버지, 아이들 등 남녀노소 가리지 않고 응원해 주는 분들 덕에 큰 힘을 얻었다. 특히 30km를 넘어서부터 너무 힘들었는데, 러닝 크루들의 하이파이브를 받을 때마다 힘이 솟아났고, 배번표의 내 이름을 보고 이름을 불러주며 파이팅을 외칠 때는 정말로 큰 힘이 됐다.

이날은 살면서 가장 많은 응원을 받은 날이라고 생각한다. 나는 혼자 뛰었지만, 그분들 덕분에 함께 달린 느낌이었다. 한계가 올때마다 물, 콜라, 레몬즙, 상쾌환 등 에너지 드링크를 주시며 힘을 나게 해 주시고, 쥐가 날 것 같으면 준비해 둔 파스를 뿌려주며 근육을 풀어주셨다. 정말로 응원해 주시는 모든 분들 덕분에 완주할 수 있었다.

마지막 300m에서 피니시 라인이 보일 때는 아드레날린이 폭발하며 아프고 힘든 것도 잊은 채 냅다 달렸다. 이 순간만큼은 도파민과 힘이 넘쳤다. 그렇게 완주한 뒤 감동의 눈물이 아닌 기쁨의 웃음이 나왔다. 드디어 해냈구나!

완주를 하고 느낀 점

무엇이든 해낼 수 있다는 생각이 든다. 앞으로 삶에서 이보다 더 힘든 일도 많겠지만, 마라톤을 뛰었던 경험을 되새기며 역경을 헤쳐나갈 수 있다고 믿는다. 무엇보다 할 수 있다는 자신감과 해낼 수 있다는 나에 대한 확신이 붙었다. 달리면서 나는 내가 누구인지, 무엇을 잘하고 무엇을 못했는지, 최근의 삶을 돌아보며 끊임없이 생각했다. 다른 사람들은 계속 묻는다. 왜 뛰냐고, 하지만 좋은 걸 어떡하나 뛰는 게 좋다. 뛰면서 생각하지 못한 범위를 생각하며 머릿속을 비우며 리프레시하는 게 좋다.

마라톤을 한번 뛰고 나니 완주 당시엔 다시는 하고싶진 않았지만 어느 정도 회복하고 나니 또 한 번 뛰어보고 싶다 ㅎㅎ

Java와 Kotlin, 컴파일 속도 차이가 많이날까?

integerJI — Tue, 29 Oct 2024 16:26:49 +0900

프로젝트 환경 설정

Java

Kotlin

함수 작성

모두 동일하게 동작하는 함수를 호출한다

Java

public class Main {
    public static void main(String[] args) {
        long sum = 0;
        for (int i = 1; i <= 1_000_000; i++) {
            sum += i;
        }
        System.out.println("Sum: " + sum);
    }
}

Kotlin

fun main() {
    var sum = 0L
    for (i in 1..1_000_000) {
        sum += i
    }
    println("Sum: $sum")
}

빌드시간 확인

Java

3번 진행 Java 평균 BUILD SUCCESSFUL in 1XXms

Kotlin

3번 진행 Kotlin 평균 BUILD SUCCESSFUL in 2XXms

Java가 조금 더 빠르긴 하다.

왜 이렇게 차이가 나는가

Java

자바의 경우 Gradle Build를 수행할 때 Task가 적은 반면

Kotiln

Kotiln의 경우는 Task가 조금 더 많은걸 볼 수 있다.

물론 프로젝트를 계속 사용하고 어플리케이션이 무거워질수록 차이는 있겠지만

초기 구축만으로 확인한 사실은 빌드 시간의 차이가 있다는 것을 알게 되었다.

Kotlin을 알아보자

integerJI — Sun, 27 Oct 2024 00:44:25 +0900

현재 회사에서는 Java를 사용한다. 나중에 Kotlin을 사용할 때를 대비하기 위하여 코틀린은 자바에 비하여 무엇이 좋고 기업에서 왜 사용하는지 궁금하여 알아보았다.

코틀린의 장점

1. 간결함

코틀린은 자바보다 구문이 간단하다. 이로 인하여 코드를 더 쉽게 짤 수 있고 유지보수 차원에서도 유용하게 적용된다.

간단하게 예를 들자면 아래의 함수는 리스트의 짝수의 합을 구하는 코드이다.

Java

import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6);

        int sumWithForEach = calculateSumWithForEach(numbers);
        System.out.println("Sum with for-each: " + sumWithForEach);

        int sumWithStream = calculateSumWithStream(numbers);
        System.out.println("Sum with stream: " + sumWithStream);
    }

    public static int calculateSumWithForEach(List<Integer> numbers) {
        int sum = 0;
        for (int number : numbers) {
            if (number % 2 == 0) { // 짝수 확인
                sum += number;
            }
        }
        return sum;
    }

    public static int calculateSumWithStream(List<Integer> numbers) {
        return numbers.stream()
                      .filter(number -> number % 2 == 0)
                      .reduce(0, Integer::sum);
    }
}

Kotlin

fun main() {
    val numbers = listOf(1, 2, 3, 4, 5, 6)
    val sum = numbers.filter { it % 2 == 0 }.sum()
    println(sum)
}

Java의 경우 코드의 스타일, 처리방식에 따라 for-each와 stream으로 작성할 수 있다.

하지만 이보다 더 간결하게 함수를 만든다.

2. NullPointException의 안정성

코틀린은 기본적으로 null을 허용하지 않는다. 변수를 선언할 때 기본적으로 non-null로 지정되기 때문에 null과 관련된 예외 처리나 오류가 컴파일 단계에서 줄어들고, 코드 작성도 훨씬 간결해진다.

Java

public String getUpperCaseName(Person person) {
    return Optional.ofNullable(person)
        .map(Person::getName)
        .map(String::toUpperCase)
        .orElse("");
}

Kotlin

fun getUpperCaseName(person: Person?): String {
    return person?.name?.uppercase() ?: ""
}

코틀린에서는 ?. 연산자를 사용해 null 여부를 간단하게 체크하고, ?: 연산자로 기본 값을 지정할 수 있다. 자바는 Optional을 사용해 널 안정성을 확보할 수 있지만, 코틀린의 null 처리 방식이 더 직관적인 장점이 있다.

* NullPointerException 발생 포인트 예시

Java

public String getUpperCaseName(Person person) {
    return person.getName().toUpperCase();
}

자바에서는 Optional을 사용하지 않고 null 체크를 하지 않으면 person가 없을 때 NullPointerException이 발생

Kotiln

fun getUpperCaseName(person: Person?): String {
    return person?.name?.uppercase() ?: "이름 없음"
}

person이나 name이 null일 경우 ?. 연산자가 null을 반환하며, ?: 연산자를 통해 "이름 없음"을 반환

코틀린의 단점

1. 컴파일 속도

코틀린은 자바보다 컴파일 속도가 조금 더 걸릴 수 있다. 코틀린에서 기본적으로 제공하는 안정성과 추가 기능들, 또한 Null 관련 검사를 자동으로 수행하며 이 과정에서 컴파일 속도가 늦춰질 수 있다.

컴파일 속도가 정말 차이날까? 궁금해서 새로운 프로젝트를 만나 기본 동일한 설정에서 테스트해 보았다.

--> https://integer-ji.tistory.com/427

2. 자바와의 호환성

코틀린의 큰 장점으로는 자바와 호환이 잘되는 점을 뽑는다. 하지만 아이러니 하게도 자바가 가지고 있는 모든 라이브러리나 프레임워크가 코틀린을 100% 지원을 장담하진 않는다. 이 부분에서 필요한 라이브러리가 적용이 안될 경우 제한사항이 발생할 수 있다.

느낀점

코틀린을 살펴본 결과, 생산성과 가독성 면에서 확실한 장점이 느껴진다. 코드가 더 간결해져 유지보수에 유리하고, 널 안정성 덕분에 런타임 오류를 줄일 수 있는 건 큰 장점이라 생각한다.

또한, 코틀린의 문법은 안드로이드, JavaScript와 같은 다른 플랫폼 언어들과 유사하다 느꼈는데 이 점은 개발 인력이 부족한 스타트업이나 다양한 플랫폼을 제공해야 하는 초기 구축 단계에서 큰 장점으로 발휘하지 않을까 생각한다.

하지만 이미 자바로 구축되어 몇십 년 이상 서비스되는 곳에서는 코틀린을 도입하기 어려울 것 같다는 생각이 들었다. 코틀린을 자바 프로젝트에 추가할 경우 생길 수 있는 호환성 문제와 의존성 관리의 복잡성도 고려해하며 새로운 이슈가 발생될 때 대응이 어렵다는 점도 크게 느껴진다.

결론적으로, 코틀린의 장점을 잘 이해하고 필요할 때를 대비하되, 현재 환경에서는 자바의 깊이를 더해가는 것도 좋은 선택이라고 생각이 된다.

최종정리

코틀린이라는 언어를 직접 사용해 보기 전의 전반적이 느낌을 적어 보았다. 하지만 여기서 끝내지 않고 더 공부를 해가 보면 충분히 장점과 단점이 더 많이 나올 것이다. 그때 다시 이 글을 보며 회고를 작성하면 좋을 것 같다.

글또 10기, 삶의 지도, 주저리주저리, 목표, 다짐

integerJI — Fri, 11 Oct 2024 10:48:10 +0900

글또를 시작한 지 7기, 8기, 9기를 넘어 10기에 참여하게 되었다. 2년이란 시간이 흐른 지금 삶의 지도를 작성하여 나의 인생을 되돌아보고 이번 10기에는 어떤 다짐과 목표를 가지고 활동할지 적어본다.

나의 삶의 지도

할 수 있는 것

학창시절 메이플 스토리라는 게임을 접하여 매크로를 만들며 처음 코딩을 해보았다. 그때 당시에는 매크로를 USB에 담에 판매를 했던 것으로 기억한다. 나는 그 돈이 너어어무 아까워 내가 직접 만들어 버렸고 이를 통해 코딩에 대해 처음 접하게 되었다. 그 이후로는 게임을 하기 위해 코딩을 시작하게 되었다.

할 수 있는 것의 한계

14년도에는 컴퓨터 공학이 인기 과목이 아니었다. 모두 화공, 기공을 가는 시대였지만 내가 할 수 있는 건 컴퓨터 밖에 없었다. 나는 컴공으로 전문대학에 입학하고 군대를 가게 되었다. 그런데 이게 웬걸, 군대에 들어가 보니 이세돌과 알파고의 바둑싸움을 통하여 컴퓨터 공학에 대한 인기가 상승하고 있었다. 설상가상으로 비트코인이 등장하고 IT에 지원이 빵빵해져 버려 취업이 잘 될 것이라는 오만이 생겨버렸다. 하지만 내가 좋아하지도 않고 할 수 있는 일을 이용해서 취업하기엔 모자람이 너무 많았다. 그렇게 취준에 실패하게 된다.

나의 강점 찾기

취업이 안될때를 대비하여 편입을 준비했었다. 취업 서류는 다 떨어졌지만 편입 원사 하나만 붙어 편입을 하게 되었고 더 넓은 세상을 접하게 되었다. 첫 1학년때에는 갑작스럽게 바뀐 학교에 적응도 못하고 성적도 바닥이었다. 공부는 물론 재미도 없었다. 하지만 이왕 대학생활을 즐기고 싶던 나는 편입한 사람들을 모아 편입 단톡방을 만들어 편입생들끼리 학교 생활을 즐기는 모임을 만들었다. 이렇게 대학생활을 즐기고 그러다 보니 교수님과도 친해지게 되어 교수님들의 제자(선배들)를 소개받기도 하였다.

하고 싶은 것

4학년 때엔 선배를 통하여 멋쟁이 사자처럼이라는 동아리에 들어가 운영진을 하며 처음으로 개발에 대한 공부를 본격적으로 시작하였다. Python Django를 통하여 비 전공자 학생들에게 코딩을 알려주는 동아리였다. 나는 동아리 운영진으로써 부끄럽지 않게 열심히 공부하게 되었고 현재의 이 블로그도 탄생하게 되었다. 동아리 운영, 코딩 경험을 쌓으며 내가 좋아하는 것이 개발이라는 것을 알게 되어 좋아하는 일을 하니 취업 준비는 너무 수월하게 되었다. 그렇게 교수님의 추천을 받고 한 SI 회사에 들어가게 된다.

이렇게 나의 인생이 시작되었다.

삶의 지도를 작성하고 느낀 나

삶의 지도를 작성하니 내가 이루고자 하는 목표와 방향을 다시 한번 상기시켜 주는 계기가 되었다. 내 목표는 세상 사람들이 모두 행복했으면 좋겠다. 그러기 위해 나는 무엇을 할 수 있을까? 내가 좋아하는 일을 찾아 추진하며 사람들에게 도움과 행복을 주고 싶다. 글또 7,8,9기를 하였지만 잘 적응을 하지 못하였다. 글 제출 또한 활발하게 하지 못했다. 하지만 커피챗과 여러 모임을 통하여 사람들을 알게 되었고 그로 인해 자극도 받으며 많은 도움을 받게 되었다. 이번 글또의 마지막 10기에서는 내가 받은 배품을 나누고 싶다. 그렇게 나의 강점인 커뮤니케이션과 퍼실리테이션 테크닉을 활용하여 많은 경험을 나누고 싶다.

이번 10기의 목표

채널 활발히 활동하기

- 나의 체력이 남을 때까지 채널에서 활발히 활동을 해볼 것이다.

큰 모임 주최해 보기

- 많은 인원을 모아 좋은 경험과 추억을 만들고 싶다.

라디오 진행해 보기

- 피식대학의 피식쇼처럼 간단하게 라이브 인터뷰 방송을 진행해보고 싶다

글 제출 많이 하기 (최대한)

- 처음부터 올 제출을 바라면 목표에 다가가기 어렵다. 나는 나를 잘 안다. 최대한 많이 제출하는 것을 목표로 삼겠다.

나에게 관심을 표현해 준 분들에게 커피라도 대접하기

- 모르는 사람에게 관심을 표현한다는 것은 생각보다 어려운 것이다. 이 어려운 일을 해내 주셨으니 기념으로 커피챗을 하며 이야기를 나누고 싶다.

sdk 만들어보기

integerJI — Wed, 7 Aug 2024 17:47:42 +0900

이 알람 시스템은 나는 정말 유용하게 사용하고 있다.

이를 더 확장해서 SDK로 만들면 어떨까?!

좋은 SDK를 만들기 위해서는 유연성과 확장성이 좋아야 한다

지금의 내 프로젝트의 문제점을 파악해보자

1. 패키지 구조 및 네이밍

현재 나의 구조 상태이다.

API, billing라는 명칭을 사용하였는데

sdk라는 걸 명확하게 하기 위해 com.sdk.notification으로 바꾸어 준다.

2. Application 제거

Applicationd을 통해서 Spring Boot를 시작시킨다.

이는 내 SDK가 특정 프로젝트의 애플리케이션 설정과 분리되어야 하는 이유는 독립성 때문이다. 다양한 환경과 프로젝트에서 사용될 수 있어야 하기 때문에 애플리케이션 초기화 코드는 포함되지 않는 것이 좋다.

결론

구조가 이렇게 바뀔 듯싶다.

오늘은 우선 구조까지만 바꾸고 추가로 채널 ID도 직접 받아야겠다.

또한 이 알림에서 에러가 나서 기존의 서비스에 영향이 가면 안 되기 때문에 이러한 상황도 고려를 해봐야겠다.

슬랙으로 알람 쏘기 2

integerJI — Tue, 6 Aug 2024 16:40:21 +0900

이제 회사에서 슬랙이 아닌 팀즈를 사용한다구 한다 ...

이 김에 이 프로젝트를 디벨롭하여 여러가지 플랫폼의 웹훅을 받을까 한다.

implementation 'com.slack.api:slack-api-client:1.40.0'

기존에 해당 버전은 보안 이슈가 있었다고한다.

버전을 올리자니 Boot 버전이랑 안맞고 ...

그래서 그냥 버리고 RestTemplate로 진행할까 한다

어차피 팀즈도 써야하니

우선 간단하게 만들어 보았다.

처음에는 슬랙 service 하나, Teams Service 하나 만들다보니

그러면 플랫폼 별로 다 만들건 아니지 않나? 라는 생각이 들어서

정신차리고 하나의 Service로 묶어 관리를 하려고 하였다.

더 좋고 깔끔한 방법이 있을 것 같은데 조금 더 찾아보려고한다

우선 서비스는 이상 무 !

슬랙으로 알람 쏘기

integerJI — Mon, 5 Aug 2024 17:36:38 +0900

서비스를 제공하는 입장에서 사람이라면(?) 어쩔수 없이 서비스 장애가 날 수 밖에 없다고 생각한다.

장애를 예밤하기 위해 Qa 검증을 진행하고, 다양한 경험을 쌓아 미연에 방지를 해야한다고 생각한다.

하지만 정말 본의아니게 어쩔수 없는 상황 (방화벽, 다른 업체 제공, 경험 부족 등)으로 발생되는 상황을 좀 더 빠르게 캐치하고 대처하면

조금 더 좋은 서비스를 제공할 수 있지 않을까

우선 업무에도 사용하고 폰에도 깔려있지만 카톡과는 확실하게 Work / Life가 구분되어있는 슬랙을 사용하겠다 .

incoming-webhook을 사용하여 특정 시점에 메시지 제목을 발송하면 어떨까?

implementation 'com.slack.api:slack-api-client:1.40.0'

슬랙 API를 Gradle로 연동을 해 보았다 .

간단하게 테스트 용으로

    private final Slack slackClient = Slack.getInstance();

    public void sendMessage(String title) {
        try {
            slackClient.send("https://hooks.slack.com/services/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", WebhookPayloads.payload(p -> p
                    .text(title) // 메시지 제목
            ));
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

전송!

잘 작동하는 것 같다.

이제 이거를 더 디벨롭 하면서 어떻게 하면 좋알까 생각해 보아야겠다.

레디스(Redis) 알아보기

integerJI — Sun, 7 Jan 2024 23:11:57 +0900

Redis란?

Redis는 빠르고 간편한 오픈 소스 DB이다. 주로 메모리에 데이터를 저장하여 높은 성능을 제공하며, 캐싱, 세션 관리, 메시지 브로커 등에 활용된다. 기본적으로 키-값 형태로 데이터를 저장한다.

Redis의 특징
- 메모리 기반의 데이터 저장
  레디스는 데이터를 주로 메모리(RAM)에 저장하여 빠른 읽기와 쓰기 속도를 제공한다. 이는 디스크 기반의 데이터베이스보다 높은 성능을 실현할 수 있다. 메모리 기반의 저장은 주로 캐싱 및 높은 처리량이 필요한 실시간 응용 프로그램에서 효과적으로 사용되지만 아무래도 휘발성 메모리에 저장하기 때문에 백업을 효율적으로 잘 해두어야 한다.
- 키-값 구조
  레디스는 간단한 키-값 구조로 데이터를 저장한다. 각 데이터는 고유한 식별자인 "키"와 그에 대응하는 "값"으로 이루어져 있어서 데이터를 빠르게 검색하고 관리할 수 있다. 그리고 익숙하다!
- 다양한 데이터 타입:
  레디스는 다양한 데이터 타입을 지원한다. 문자열, 리스트, 셋, 해시, 정렬된 집합 등 다양한 데이터 구조를 활용할 수 있으며 이는 사용자가 다양한 형태의 데이터를 저장하고 조작할 수 있게 해주어 유연한 활용이 가능하다
사용하는 주요 이유
- 캐싱 시스템
  레디스는 자주 사용되는 데이터를 빠르게 제공하기 위한 캐싱 시스템으로 활용된다. 매번 계산하거나 디스크에서 읽어오는 데 소요되는 시간을 절약하고, 자주 업데이트되지 않는 데이터를 메모리에 저장하여 높은 성능을 유지할 수 있다.
- 세션 관리
  애플리케이션에서 사용자 세션을 효과적으로 관리하기 위해 레디스를 사용할 수도 있다. 사용자 로그인 정보나 세션 데이터를 안정적으로 저장하고 검색하여 빠르게 세션을 관리할 수 있다.
- 메시지 브로커로의 활용
  레디스는 경량 메시지 브로커로 활용될 수 있다. 다른 시스템 간의 비동기 통신을 지원하며, 메시지 큐 형태로 메시지를 보내고 받아서 분산 시스템에서 유용하게 활용된다. 이로 인해서 로그 정보나 알림 메시지를 메시지 브로커를 통해 전송하여 중요한 이벤트나 상태 변화에 대한 정보를 실시간으로 수집하거나 통지할 수 있어 좋다.
정리하자면 어디서 레디스를 쓰는게 좋을까?
- 높은 읽기 및 쓰기 성능이 필요한 경우
  레디스는 메모리 기반의 저장소를 사용하여 빠른 읽기 및 쓰기 성능을 제공하기 때문에 응답 시간이 중요한 실시간 응용 프로그램이나 캐싱 시스템에서 효과적으로 사용된다. 제 생각으론 대용량 데이터를 빠르게 조회하는 곳에서 쓰면 확실히 좋은 것 같다.
- 데이터 분석 및 실시간 이벤트 처리:
  실시간 데이터 처리와 분석이 필요한 경우, 레디스는 메모리 기반의 특성으로 빠른 속도로 데이터를 처리할 수 있어 적합 다. 이는 실시간 대시보드, 이벤트 로깅, 분산 메시지 브로커 등에 활용될 수 있고 다양한 데이터 활용이 가능하다.
레디스의 단점
- 데이터의 영속성 부재
  레디스는 주로 메모리 기반의 데이터베이스로서, 전원이 꺼지거나 서버가 재시작되면 데이터가 손실될 수 있다... 이는 데이터의 영속성이 보장되지 않으며 주기적인 스냅샷 백업이나 AOF(Append-Only File) 등 잘 대비를 해야한다.
- 용량 제한
  레디스는 메모리 기반의 저장소로 용량이 제한되어 있다. 매우 큰 데이터셋을 다루기에는 부적합하며, 대용량의 데이터를 다루기 위해서는 메모리를 확장하는 대신 다른 데이터베이스 시스템을 고려해야 할 수도..있다.
- 복잡한 쿼리 처리 부족
  레디스는 기본적으로 간단한 키-값 구조이기 때문에 다양한 쿼리나 복잡한 데이터 연산을 처리하는 데는 적합하지 않을 수 있다. 관계형 데이터베이스 시스템보다는 데이터 모델이 단순하고 직관적인 편이며 잘 고려하고 도입을 해야한다.
- 단일 스레드 구조
  레디스는 단일 스레드로 동작한다. 그래서 동시에 명령어를 처리하는 데에는 한계가 있다. 이는 다중 코어를 활용하지 못하고 단일 코어의 성능에 의존한다는 의미이며, 몇몇 CPU 바운드 작업에 대한 처리 속도를 제한할 수도 있다.

각 솔루션에 따라 레디스를 정말 잘 활용할 수 있다고 생각한다. 단점이 뭐가 있을까? 하고 여러가지를 알아 보았지만 단점에 걸리지 않는 정도이고 효율적으로 사용한다면 레디스는 충분히 좋은 시스템이라고 생각한다.

이번에는 글쓰기 연습 겸 정리하면서 글을 적어보았다. 분명 저번 글까지만 해도 잘 쓰고 있다고 생각했는데 막상 적고 나니까 어렵다!

NoSql이란? by gpt

integerJI — Sun, 10 Dec 2023 20:53:46 +0900

GPT를 사용하여 한번 더 공부하고 정리를 해보았다.

NoSQL 소개
- NoSQL이란?
  NoSQL은 "Not Only SQL"의 약자로, 관계형 데이터베이스 이외의 다양한 데이터 모델을 지원하는 데이터베이스를 말한다. 이는 유연한 데이터 구조와 대용량 데이터 처리에 적합하며, 전통적인 테이블 기반의 관계형 데이터베이스의 제약을 벗어나려는 목적에서 등장한 이력이 있다.
- 관계형 데이터베이스와의 차이점
  관계형 데이터베이스는 정해진 스키마에 따라 데이터를 저장하는 반면, NoSQL은 스키마가 유동적이고 데이터 모델이 다양하다. NoSQL은 확장성과 빠른 읽기/쓰기 속도에 중점을 둬, 특히 대규모 분산 시스템에서 효과를 발휘한다.
- NoSQL의 주요 특징과 장단점
  주요 특징: 유연한 데이터 모델, 확장성, 분산 처리, 다양한 데이터 모델 지원
  장점: 대용량 및 비정형 데이터 처리, 수평 확장 용이, 높은 성능
  단점: 일관성 및 트랜잭션 지원이 상대적으로 부족, 학습 곡선이 높을 수 있음
NoSQL 데이터 모델
- 키-값 스토어 (Key-Value Store)
  키-값 스토어는 간단한 데이터 모델을 가지고 있어서 효율적인 데이터 검색과 쓰기에 특화되어 있다. 각 데이터는 고유한 키와 연결되어 있으며, 이를 통해 데이터에 접근하거나 갱신할 수 있고 주로 단순한 조회 및 저장에 사용된다.
- 문서 지향 데이터베이스 (Document-Oriented Database)
  문서 지향 데이터베이스는 데이터를 문서 형식으로 저장한다. 주로 JSON 또는 BSON 형태를 사용하며, 중첩된 구조로 데이터를 표현하며 이 모델은 복잡한 데이터 구조를 효과적으로 다룬다. 관련 데이터를 함께 저장하여 쿼리 성능을 향상시킬 수 있다.
- 왜 그래프 데이터베이스인가? (Graph Database)
  그래프 데이터베이스는 노드(Node)와 엣지(Edge)로 이뤄진 그래프 모델을 사용하여 데이터를 표현합니다. 관계형 데이터베이스보다 뛰어난 관계 표현과 탐색이 가능하며, 소셜 네트워크, 추천 시스템 등에서 강점을 보입니다. 복잡한 연결 관계를 다룰 때 특히 유용합니다.
- 컬럼 패밀리 데이터베이스 (Wide-Column Store)
  컬럼 패밀리 데이터베이스는 로우보다는 칼럼을 중심으로 데이터를 저장한다. 이는 대규모 분산 데이터베이스에서 성능 향상을 가져오는데, 필요한 칼럼만 읽어오기 때문에 빠른 읽기 속도를 제공하며, 대용량 데이터에 대한 효과적인 스토리지를 지원한다.
데이터 모델 선택 기준
- 데이터 모델 선택의 중요성
  데이터 모델 선택은 데이터베이스를 구축할 때 가장 중요한 결정 중 하나이다. 선택한 데이터 모델에 따라 데이터의 구조, 유연성, 쿼리 효율성 등이 크게 영향을 받으며 올바른 데이터 모델을 선택하는 것은 향후 확장성과 유지보수에 매우 중요한 역할을 한다.
- 어떤 상황에서 어떤 NoSQL 데이터베이스를 선택해야 하는가?
  키-값 스토어: 간단한 조회 및 저장이 필요한 경우, 예를 들어 세션 관리나 캐싱에 적합
  문서 지향 데이터베이스: 복잡한 데이터 구조를 다루거나 중첩된 데이터가 필요한 경우, 예를 들어 블로그 포스트, 제품 카탈로그 등
  그래프 데이터베이스: 복잡한 관계를 다루어야 하는 경우, 예를 들어 소셜 네트워크에서의 친구 관계, 네트워크 구조 등에 적합
  컬럼 패밀리 데이터베이스: 대용량 데이터를 다루거나 읽기 성능이 중요한 경우, 예를 들어 로그 데이터, 시계열 데이터 등
- 예시를 통한 실제 적용 사례
  전자상거래 플랫폼에서는 제품 정보와 주문 정보를 각각 문서 지향 데이터베이스와 키-값 스토어에 저장할 수 있다. 제품 정보는 복잡한 구조를 갖고 있을 수 있고, 주문 정보는 효율적인 조회와 저장이 중요하기 때문입니다. 또한, 소셜 미디어 플랫폼에서는 사용자 간의 관계를 그래프 데이터베이스로 효과적으로 관리할 수 있습니다.
NoSQL 쿼리 언어 및 API
- NoSQL 데이터베이스에서의 쿼리 언어
  예시로 MongoDB는 문서 지향 데이터베이스로, JSON 형식의 쿼리를 사용한다.
  ex) { "author": "John Doe" }와 같은 쿼리로 작성자가 John Doe인 문서를 찾을 수 있다.
- RESTful API, GraphQL 등 NoSQL에서의 데이터 검색 및 조작 방법
  대부분의 NoSQL 데이터베이스는 RESTful API 또는 GraphQL을 통해 데이터에 접근하고 조작할 수 있다.
  
  RESTful API 예시: MongoDB에서는 HTTP GET, POST, PUT, DELETE 등의 메서드를 사용하여 데이터를 읽거나 쓸 수 있으며 /articles 엔드포인트로 모든 글을 얻거나, /articles/{id}로 특정 글을 얻을 수 있다.
  
  GraphQL 예시: GraphQL을 사용하면 클라이언트가 필요한 데이터만 요청할 수 있다.
  ex) "특정 글의 제목과 작성자"를 요청하는 쿼리라면
```
query {
  article(id: "123") {
    title
    author
  }
}
```
- NoSQL 데이터 모델에 따른 쿼리 예시
  그래프 데이터베이스에서는 사용자 간의 관계를 탐색하기 위해 특정 노드와 연결된 다른 노드를 조회하는 쿼리를 작성할 수 있다. 예를 들어, "A 사용자의 친구 목록"을 조회하는 그래프 데이터베이스의 쿼리는
```
MATCH (a:User)-[:FRIEND]->(friend:User)
WHERE a.username = 'A'
RETURN friend.username
```

여러가지 글을 잘 쓰는 방법을 찾아보고 있다. 확실히 GPT가 있으니 조금 더 편한거 같긴 하다. 다음부터는 GPT로 먼저 글을 작성해보고 그 다음 한번 더 내가 써보는 형식으로 바꿔봐야겠다.

NoSQL이란?

integerJI — Sun, 10 Dec 2023 20:27:06 +0900

NoSQL이란

비관계형 데이터베이스를 말한다. 일반적인 관계형 데이터 모델을 지양하고 많은 분산된 데이터를 저장, 조회하는데 특화되어 있으며 스키마 없이 사용이 가능한 점이 큰 특징이며 기존의 RDBMS(Relational DataBase Management System) 형태의 관계형 데이터베이스의 한계를 극복하기 위해 만들어졌다.

RDBMS와 NoSql의 차이

	RDBMS	NoSql
장점	* 정해진 스키마에 따라 데이터를 저장하여 명확한 데이터 구조를 보장한다. * 관계는 각 데이터를 중복없이 한 번만 저장할 수 있다.	* 스키마가 없기때문에 자유로운 데이터 구조를 가질 수 있다. * 언제든 데이터를 조정하고 새로운 필드를 추가하기 자유롭다. * 데이터 분산에 용이하며 성능 향상을 위한 Saclue-up 또는 Scale-out도 가능하다.
단점	* 시스템이 커질 수록 테이블간의 JOIN이 많아져 쿼리가 복잡해질 수 있다. * 스키마로 인하여 데이터가 유연하지 못하며 스키마가 변경될 경우 번거로워진다.	* 데이터 중복이 발생할 수 있다. 중복된 데이터가 수정될 경우 모든 컬렉션에서 수행이 되어야 한다. * 스키마가 존재하지 않기 때문에 명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정이 어려울 수 있다.

NoSql은 어떤 상황에서 사용을 할까

1. 비구조화 데이터를 다루어야 할 때

- 일반적으로 행과 열의 형태로 표현하기 어려운 데이터들을 다룰 때 사용하면 좋다.

2. 대량의 데이터를 읽기, 쓰기를 할 때

- 수평 확장성을 제공하여 분산 아키텍처에서 쉽게 확장할수 있다.

3. 유연한 스키마가 필요한 경우

- RDBMS의 경우 사전에 데이터 모델을 정의해야 하지만 NoSql은 스키마가 동적이거나 유연하여 데이터 모델을 쉽게 변경할 수 있다.

4. 큰 규모의 분산 시스템

- 수많은 서버에 데이터를 분산하고있고 클라우드 환경에서의 확장성이 중요한 경우 유리한 점을 가지고 있다.

5. 빠른 개발 및 서비스 출시가 필요한 경우

- 초기 개발 단계의 스키마가 자주 변경될 경우 매우 유용하다.

6. 다양한 종류의 데이터 모델이 필요한 경우

- 다양한 데이터 모델을 지원하여 키-값 저장소, 문서 저장소, 그래프 데이터베이스 등 다양한 유형의 데이터를 다룰 수 있다.

알아보면서 들었던 나의 생각

우선 NoSql이 어떤것인지에 대하여 간단하게 알아보았다. 하지만 왜인지 아직 실감이 안나는 것일까? NoSql의 MongoDB를

사용해서 프로젝트를 직접 해가면서 장단점을 찾아가 보아도 좋을 것 같다.

GPT로 글을 한번 더 적어보기

https://integer-ji.tistory.com/419

GPT로 글을 적어 보았다. 확실히 간결하게 글이 작성이 되었고 또 이해가 더 쉽게 되었다.

앞으로는 GPT로 글을 한번 적어보고 나의 스타일로 한번 더 적어보면서 글을 써보면 더 좋을 것 같다!!

* 리마인드

- RDBMS (MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle Database 등)

- DBMS : DataBase Management System

- Sql : Strucured Query Language

* 참고

https://code-lab1.tistory.com/53

python mysqlclient 2.2.x 버전 설치 시 에러

integerJI — Sun, 17 Sep 2023 17:37:32 +0900

(env) int@intui-MacBookAir potenday-309 % pip install mysqlclient             
Collecting mysqlclient
  Using cached mysqlclient-2.2.0.tar.gz (89 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error
  
  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [24 lines of output]
      /bin/sh: pkg-config: command not found
      /bin/sh: pkg-config: command not found
      Trying pkg-config --exists mysqlclient
      Command 'pkg-config --exists mysqlclient' returned non-zero exit status 127.
      Trying pkg-config --exists mariadb
      Command 'pkg-config --exists mariadb' returned non-zero exit status 127.
      Traceback (most recent call last):
        File "/Users/int/Development/workspace/potenday-309/env/lib/python3.9/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/Users/int/Development/workspace/potenday-309/env/lib/python3.9/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/Users/int/Development/workspace/potenday-309/env/lib/python3.9/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 118, in get_requires_for_build_wheel
          return hook(config_settings)
        File "/private/var/folders/gz/nfvkk1c10m3d7dy7_bwzy43m0000gn/T/pip-build-env-48994rpk/overlay/lib/python3.9/site-packages/setuptools/build_meta.py", line 355, in get_requires_for_build_wheel
          return self._get_build_requires(config_settings, requirements=['wheel'])
        File "/private/var/folders/gz/nfvkk1c10m3d7dy7_bwzy43m0000gn/T/pip-build-env-48994rpk/overlay/lib/python3.9/site-packages/setuptools/build_meta.py", line 325, in _get_build_requires
          self.run_setup()
        File "/private/var/folders/gz/nfvkk1c10m3d7dy7_bwzy43m0000gn/T/pip-build-env-48994rpk/overlay/lib/python3.9/site-packages/setuptools/build_meta.py", line 341, in run_setup
          exec(code, locals())
        File "<string>", line 154, in <module>
        File "<string>", line 48, in get_config_posix
        File "<string>", line 27, in find_package_name
      Exception: Can not find valid pkg-config name.
      Specify MYSQLCLIENT_CFLAGS and MYSQLCLIENT_LDFLAGS env vars manually
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

python에서 mysql을 사용하려고 pip를 이용해 mysqlclient를 설치하다 에러가 났다.

분명 다른 프로젝트에서는 잘 작동하였는데 찾아보니까 간단하였다.

2.2.0 버전이 2023년 6월 릴리스 되었으며 해당 버전 이후부터는 pkg-config 패키지를 container에 설치해야 한다.

맥북에 brew를 사용하여 pkg-config를 설치하자

brew install mysql pkg-config

설치를 완료하고 다시 mysqlclient를 설치하면

pip install mysqlclient

잘 설치된다.

근황

integerJI — Mon, 11 Sep 2023 17:04:57 +0900

근황 List Up

- DDD 9기가 끝났다. 운영진으로써 첫 기수였는데 좋았따.

- 비사이드 포텐데이를 한번 더 참여하기로 하였다. (309) 1등 꼭할꺼야

- 서핑에 대한 취미를 가지게 되었다. 서핑좋아

- 일본여행 갈 준비를 하고있다. 추석 연휴가 너무 길어졌다.

비사이드 포텐데이 후기 - 10일만에 서비스 배포하기

integerJI — Tue, 15 Aug 2023 00:13:52 +0900

많은 사이드 프로젝트를 해보았지만 결국 끝은 열정이 식어버렸다.

지금의 나는 번아웃과 슬럼프를 포장한 게으름에 빠져있었고 예전의 모습을 찾기 위해 다양한 프로그램을 찾고 있었다.

찾는 중 마침 기획을 할 수 있는 학교 후배와 함께 비사이드 포텐데이라는 10일에 걸쳐 서비스를 출시하는 프로그램을 발견하게 되었고

비사이드에서 연결해 준 디자이너와 함께 우승 상금과 성장을 초점으로 백엔드와 프론트엔드 개발자로서 다시 한번 경쟁에 참여하게 되었다.

https://bside.best/potenday

비사이드 : IT 프로젝트 경험을 통해 성장하세요!

bside.best

(8월 4일 ~ 8월 13일까지 총 10일에 걸쳐 서비스를 출시하는 비사이드 포텐데이 308기!)

결과는?

결론부터 말하자면 1등은 하지 못하였다. 하지만 좋은 경험이었고 짧은 시간 안에 많은 포퍼먼스를 보여줘야 하여 나 자신을 더욱더 채찍질 하였다. 프론트엔드와 백엔드 동시에 개발을 하며 기술을 더욱 더 고도화시키고 싶었지만 시간에 쫓겨 결국 있는 백엔드 소스를 활용하였다. 하지만 디자이너와 피그마로 소통을 진행하며 한 픽셀 한픽셀 맞춰가는 방법을 알았고 그 덕분에 화면이 너무 이쁘게 나와 뿌듯해하며 개발을 하여서 너무 즐거웠다.

아쉬운 점?

이번에 아쉬운 점은 오히려 API 소스로는 있는 소스를 활용하다 보니 급하게 치는 느낌을 많이 받았다. 그러다 보니 API는 금방 끝나 화면에 집중하게 되었고 기획자보다는 디자이너와 소통을 더 많이 하였던 것 같으며 기획의 의도, 서비스의 핵심 목표를 파악하지 못한고 서비스를 만든 것이 너무 아쉬웠다.

후기!

디자이너와 프런트엔드 개발자 사이에 소통이 어떤 식으로 이루어지는지 배운 것 같다. 보통 API 개발을 진행하다 보면 기획자 분들과 더 많이 이야기를 나누었지 사실 디자이너와는 많이 나누지는 못하였다. 하지만 이번 기회를 통해 어떠한 방식으로 소통하는지 조금은 이해가 되는 시간이었다. 또한 개발에 대한 자신감과 재미를 찾은 것 같다. 사실 너무 재밌었다. 좋은 팀원을 만나 그런 것도 있겠지만 내가 개발을 시작한 이유를 다시 한번 생각하고 돌아보는 계기가 되어 너무 좋았다. 앞으로 있을 FitNote 고도화와 개인적으로 공부하고 있는 서비스에 개발한 항목을 적용시키지는 못하겠지만 나의 정신적인 성장을 통해 더 잘할 수 있을 거란 생각이 들어 너무 좋다.

앞으로는?!

역시 고도화 작업과 리펙터링이다! 마감시간에 맞추느라 미쳐 신경 쓰지 못한 부분을 고칠 거다. 소스 단에서는 중복되는 항목을 공통화시키며 앞으로 구한다면(?) 진행될 클라이언트 단과의 협업을 위해 Rest API 형식으로 깔끔하게 바꿀 예정이다!

~~http://atee.kr~~

Atee

atee.kr

현재는 과금이슈로 닫아두었습니다 :(

[회고] 글또

integerJI — Sun, 16 Jul 2023 22:59:53 +0900

6개월간의 진행된 글또8기의 활동이 끝이 났다.

6개월 동안 나는 무엇을 하였는가? 회고를 진행해 보고자 한다.

1. 활동을 시작하며 나의 목표를 이루었는가?

아직은 적응하는 단계라고 생각이 되었다. 따라서 나의 첫 목표는 꼭 모든 글을 제출하지 않더라도 꾸준히 글을 쓰는 것이었다. 이것에 대하여는 목표를 이루었다고 생각한다. 새로운 cs 스터디를 진행하며 자연스럽게 글을 쓰게 되었고 이전에 끝내지 못한 글을 마무리하였다. 이 부분에 있어서는 충분히 성공적이라고 생각한다.

2. 떳떳한 활동을 하였는가?

사실 이번에는 글을 썼지만 제출을 많이 하지는 않았다. 왜냐하면 나의 글의 수준이 높다고 생각하지도 않았으며 남에게 떳떳하게 보여주기에는 많이 모자라다고 생각이 되었기 때문이다. 하지만 다른 사람들과의 운동, 조찬모임, 동네모임, 스터디 등 다양한 활동을 하며 나의 생각을 넓히는 좋은 기회가 되었다고 생각한다.

3. 앞으로는?

유튜브를 보다 이런 영상을 보았다. 뇌를 확장시키는 글쓰기 방법 다음에 내 전공 분야에 대한 글을 쓰게 된다면 그때를 대비하여 끄적끄적이라도 나의 생각을 확장시킬 생각이다. 이제 육체적인 성장과 함께 뇌의 성장을 기대하려고 하고 있다.

4. End Credits

활동하며 썼던 글

1. DDD 8기의 마무리와 새로운 시작

2. 인덱스를 타지 않는 쿼리

3. chat gpt 활용

4. 로드 밸런싱(Load Balancing)

5. kakao tech meet 후기, AI와 Chat GPT..

6. Django Jenkins 자동 배포하기 - ec2 docker 설치하기

7. Django Jenkins 자동 배포하기 - docker에 Jenkins 설치하기

8. REST와 RESTful

이상 새로운 시작을 기대하며 글을 마친다.

Cannot run program catalina.sh (in directory bin): error=13, Permission denie

integerJI — Tue, 11 Jul 2023 13:09:24 +0900

Cannot run program catalina.sh (in directory bin): error=13, Permission denie

맥북에서 인텔리제이와 tomcat을 연결한 뒤 run을 할 경우 생기는 에러이다.

이는 새로 받은 톰캣의 권한이 없기 때문에 발생한다.

이러할 경우 자신의 설치(혹은 압축 해제 한) 톰캣 경로의 bin 파일로 가서 catilna.sh의 권한을 775로 바꾸어 주면 된다!

sudo chmod 775 catalina.sh

REST와 RESTful

integerJI — Sat, 10 Jun 2023 20:01:35 +0900

채용 공고를 보다 보면 “Rest API 개발 우대” 라는 항목을 쉽게 볼 수 있다.

그렇다면 여기서 Rest API는 무엇인가? 그리고 RestFul과는 어떤 차이가 있는지 궁금해서 공부해 보았다.

REST
1. Rest의 정의
  - REpresentational State Transfer라고 불린다.
  - 소프트웨어 개발 아키텍처의 한 방식.
  - 동작 위치는 네트워크 상 클라이언트와 서버 사이의 통신 방식 중 하나이다.
2. 개념
  - 리소스 : 각각의 서비스가 제공하는 개별 항목마다 리소스가 존재한다.
  - 상태전달 : 클라이언트와 서버의 통신은 주로 HTTP 통신을 이용한다.
  - 메소드 : 대표적인 4가지를 사용한다. (GET, POST, PUT, DELETE)
  - 표현 방식 : JSON, XML, HTML등의 형식으로 표현하며 클라이언트에서는 이를 처리한다.
3. 장점과 단점
  - Hypermedia API의 기본 원칙을 따르면서 충분한 범용성을 보장한다.
  - http 프로토콜을 활용하여 http의 캐싱 기능을 이용하여 응답을 캐시로 받을 수 있다. 이로인해 성능도 개선된다.
  - 다양한 디자인 서비스에서 발생할 수 있는 문제를 간결한 아키텍처 스타일로 문제를 최소화 할 수 있다.
  단점
  - Url 대신 헤더 값을 데이터로 전달할 때 어렵게 느껴질 수 있다.
  - 구형 브라우저 같은 경우 Put와 Delete 메서드를 사용할 수 없다.
  - 큰 방향은 아키텍처 스타일로서의 원칙을 가이드 해주지만 세부적인 구현 방식은 개발자마다 다를 수 있어 일관성이 부족할수도있다.
  - pushState를 지원하지 않는다.
4. 장점
5. 필요한 이유
  - 어플리케이션의 분리와 통합
  - 다양한 클라이언트의 등장 (웹, 안드로이드, ios..)
  - 고유한 리소스가 있기 때문에 용이한 업데이트 및 유지보수
REST API
1. REST API의 정의와 특징
  - REST 아키텍처 기반으로 API를 구현한 것
  - REST의 유연함이 마이크로서비스 아키텍처에서 컴포넌트와 어플리케이션을 연결하는 일반적인 방법으로 부상하게 되었다.
2. REST API 디자인 원칙
  - 균일한 인터페이스 : REST API는 사용자의 이름이나 이메일 주소 등의 동일한 데이터 조각이 오직 하나의 URI 에 속함을 보장해야한다.
  - 클라이언트-서버 디커플링 : REST API 디자인에서 클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 한다.
  - Stateless : REST API는 서버측 세션을 필요로 하지 않으며 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없다.
  - 캐싱 가능성 : 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 하며 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 한다.
  - 계층 구조 아키텍처 : REST API는 엔드 애플리케이션 또는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 한다.
  - 코드 온디맨드 : 특정한 경우에는 응답에 실행 코드(예: Java 애플릿)를 포함할 수도 있다. 경우에 코드는 요청 시에만 실행되어야 한다.
RESTful
1. RESTful의 개념
  - RESTful은 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
  - RESTful은 REST를 REST답게 쓰기 위한 방법으로 누군가가 공식적으로 발표한 것은 아니다.
  - 여기서 ful은 full의 줄임말이다.
2. RESTful 하지 못한 경우
  - CRUD 기능을 모두 POST로만 처리하는 API
  - route에 resource, id 외의 정보가 들어가는 경우(/post/1)

요약하자면, REST는 아키텍처 스타일로서 네트워크 기반 시스템에서의 통신을 설명하는 개념이며, RESTful은 REST 원칙을 따르는 웹 서비스를 나타냅니다. RESTful 서비스는 REST 아키텍처 원칙을 준수하여 설계되어 클라이언트와 서버 간의 상호 작용을 용이하게 합니다.

참고 문서 :

https://www.ibm.com/kr-ko/topics/rest-apis

https://github.com/WeareSoft/tech-interview/blob/master/contents/network.md#rest와-restful의-개념

[CI/CD] Django Jenkins 자동 배포하기 - docker에 Jenkins 설치하기 (7)

integerJI — Sun, 28 May 2023 21:38:37 +0900

[CI/CD] Django Jenkins 자동 배포하기 - Django 프로젝트 생성 (1) : https://integer-ji.tistory.com/379
[CI/CD] Django Jenkins 자동 배포하기 - Ec2 Ubuntu 22.04 설치 (2) : https://integer-ji.tistory.com/380
[CI/CD] Django Jenkins 자동 배포하기 - Ec2 모바엑스텀 접속하기 (3) : https://integer-ji.tistory.com/381

[CI/CD] Django Jenkins 자동 배포하기 - Aws Ec2 Django 프로젝트 배포하기 (4) : https://integer-ji.tistory.com/383

[CI/CD] Django Jenkins 자동 배포하기 - ngnix, gunicorn으로 Django 서버 기동하기 (5) : https://integer-ji.tistory.com/385

[CI/CD] Django Jenkins 자동 배포하기 - ec2 docker 설치하기 (6) : https://integer-ji.tistory.com/407

1. 젠킨스 이미지 다운

docker pull jenkins/jenkins:lts

docker pull 명령어를 이용하여 jenkins 이미지를 다운받아줍니다.

lts는 jdk8로 설치한다는 의미이며 다른 jdk 버전이 필요 시 jdk11, jdk17로 바꾸어 입력하면 됩니다.

2. jenkins 이미지 실행

docker images

명령어를 사용하면 다운 받았던 이미지를 볼 수 있다.

이미지를 삭제하려면

docker rmi [image id]

로 지우기

docker run -d -p 8190:8080 -v /var/jenkins_home --name jenkins -u root jenkins/jenkins:lts

설치된 이미지를 8190 port로 실행시킨다.

ps 명령어를 통해 확인해 보면 잘 실행된 모습을 볼 수 있다.

3. ec2 인스턴스의 인바운드 규칙 추가

ec2에서 보안그룹의 규칙에서 인바운드 규칙을 추가해준다.

사용자 지정의 TCP, 방금 전 docker images를 실행 시킨 8190

4. 접속하기

http://자신의ec2Ip:8190

해당 Url로 들어오면 실행 된 jenkins를 볼 수 있다.

4-1. jenkins 비밀번호 확인

docker ps

# docker ps로 실행 된 컨테이너 ID 확인

docker logs 78ae895e0c35

# 해당 컨테이너 ID의 로그 확인

로그를 쭉 확인해 보면 Jenkins가 실행될 때 비밀번호를 알려준다.

해당 비밀번호를 입력!

"Install suggested plugins"

클릭!

설치 기다리기 ...

관리자 계정 생성 후 !

접속하시면 끝입니다!

이제 다음 시간엔 자신이 만든 프로젝틀을 자동 빌드할 수 있게 설정해보겠습니다.

[Ubuntu] docker gpg key 에러

integerJI — Wed, 17 May 2023 23:02:32 +0900

인터넷을 따라 하다 보면 gpg key 할 때 에러가 발생할 수 있다.

이는 서버에 gpg key가 등록된 건지 확인할 수 없을 때 발생한다.

Hit:1 http://...ubuntu.com/ubuntu jammy InRelease
Hit:2 http://...ubuntu.com/ubuntu jammy-updates InRelease                      
Hit:3 http://...ubuntu.com/ubuntu jammy-backports InRelease                    
Hit:4 https://download.docker.com/linux/ubuntu bionic InRelease                                        
Hit:5 http://security.ubuntu.com/ubuntu jammy-security InRelease                                       
Reading package lists... Done
W: https://download.docker.com/linux/ubuntu/dists/bionic/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

도커를 설치하다 해당 W가 나온다면 도커 설치를 위해 gpg키를 저장할 때 새로운 위치에 저장이 되어야 한다는 뜻이다.

이는 서버에 gpg key가 등록된 건지 확인할 수 없을때 발생한다.

해당 명령어를 통해 키를 다시 등록하자!

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg

[CI/CD] Django Jenkins 자동 배포하기 - ec2 docker 설치하기 (6)

integerJI — Wed, 17 May 2023 22:11:22 +0900

[CI/CD] Django Jenkins 자동 배포하기 - Aws Ec2 Django 프로젝트 배포하기 (4) : https://integer-ji.tistory.com/383

[CI/CD] Django Jenkins 자동 배포하기 - ngnix, gunicorn으로 Django 서버 기동하기 (5) : https://integer-ji.tistory.com/385

우분투 서버 준비

나중에 여러가지 사용할 것을 대비하여 docker를 이용해 젠킨스를 설치할겁니다.

우선 도커부터 설치!

스토리지는 도커에 설치할 이미지들을 대비하여 프리티어의 최고 용량으로 설정(개인적인판단)

우분투 서버 접속

ubuntu가 시작되었습니다!

명령어를 통해 apt-get 업데이트

sudo apt-get update

apt가 https를 통해 패키지를 설치할 수 있도록 설정

sudo apt install apt-transport-https 
sudo apt install ca-certificates 
sudo apt install curl 
sudo apt install software-properties-common

이제 도커에서 제공하는 gpg 키를 추가합니다.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg

만약 키를 잘못 등록하거나 우분투 버전에 맞지 않게 옛날 키를 적용하게 된다면

https://integer-ji.tistory.com/408

도커 설치 중 에러

Hit:1 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy InRelease Hit:2 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy-updates InRelease Hit:3 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy-backports InRelease Hit:4 https://do

integer-ji.tistory.com

해당 에러가 나올 수 있습니다.

공식 repository 추가

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"

마지막으로 apt를 다시 업데이트 해줍니다.

sudo apt-get update

이제 마지막으로

도커를 설치해주자

sudo apt install docker-ce

sudo docker run hello-world

hello-world run을 해보면 올바른 명령어를 보내준다.

하지만 명령어를 도커 명렁어 모두 sudo를 넣어주어야 한다.

도커 그룹에 사용자를 넣어주자.

서버에 도커 그룹이 있는지 확인

sudo groupadd docker

사용자에게 그룹 추가

sudo usermod -aG docker ubuntu

현재 세션에 도커에 대한 그룹 변경 사항 적용!

newgrp docker

그러면 sudo 명령어 없이 사용이 가능 합니다!

kakao tech meet 후기, AI와 Chat GPT..

integerJI — Thu, 11 May 2023 20:07:17 +0900

5월 11일 카카오에서 열리는 첫 번째 tech meet가 열렸는데 단 100명만 당첨이 되는 행사에 당첨이 되어 다녀왔다!!

첫 번째 kakao tech meet에서는 "AI(인공지능)" 주제로 진행이 되었다.

https://tech.kakao.com/2023/04/26/kakao-tech-meet-1-speakers/

제1회 kakao tech meet 발표자와 발표 내용을 소개합니다!

안녕하세요! 지난 글에서 kakao tech meet 행사를 소개하고 그 시작이 될 제1회 행사의 정보를 공유드렸는데요, 이번 글에서는 제1회 행사에서 지식과 경험을 나눠주실 크루들과 발표 내용을 간단히

tech.kakao.com

카카오 사옥에서 반기는 tech meet 가는 길

카카오 판교아지트 지하 1층 세미나홀

귀여운 최고심라이언 스티커도

(1) ChatGPT로 바뀐 개발자의 일상 이야기

첫 번째로 robin님의 강연이 시작되었다.

시작할 때 첫 ppt 설명을 해주시고 이 ppt는 AI가 만든 발표자료입니다. 라고 하셔서 정말 깜짝 놀랐다.

전혀 의심이 안들었고 자연스러웠기 때문이다.

오히려 살짝 (?) 하는 부분이 있었지만 그 부분이 더 사람이니까~ 하고 넘어갈 수 있는 부분이어서 더 기억에 남는 것 같다.

robin님은 내가 생각하지 못한 AI의 이용법을 알려주었다.

AI 도구를 활용하여 효율적으로 업무를 좀 더 효율적으로 바꿔보고 싶었다.

(2) 실전! 인공지능 챗봇 개발

두 번째는 dennis님의 챗봇 개발 이야기였다.

클라우드와 AI를 합쳐 시너지를 더 낼 수 있는 예시와 챗봇 개발 사례와 동작 원리 등 알기 쉽게 설명해주셔서 너무 좋았다.

특히 아직도 기억에 남는 그림이 있다.

예전 개발자는 java, python 등 여러가지 무기(웨폰)을 사용하는 다양한 웨폰 마스터가 있었다면

이제는 AI(마법)을 사용한 마검사(?)가 존재한다는 이야기의 그림이었다.

정말 공감되었고 재미있었다.

(3) Nocode, Serverless cloud Services for Generative AI : monokode stein

세 번째 강의는 andrew님의 강연이었다.

정말 대단하신 것 같다. 말이 안나온다

2022년에 진행 된 kakako if 페이지가 andrew님이 소개한 monokode 서비스를 이용해 만든 페이지란걸 보고

정말 빠른 시간 안에 개발자란 직종에 닥쳐올 미래가 무서웠다. ..

간단하게 말하자면 피그마와 비슷한 툴을 이용하여 디자인을 하면 그 디자인이 바로 반응형 퍼블리싱이 되는 것이었다.

매번 부트스트랩을 이용해 웹페이지를 조립해가던 나의 입장에선 너무 혁신적인 서비스였다 ..monokode가 출시된다면 정말 꼭 이용할 것 같다.

kakao tech meet를 통해서 카카오란 대기업에서 생각하는 AI와 활용방법을 접할 수 있어서 정말 좋았다.

첫 tech meet인도 성공적으로 끝난 것 같았다. 다음에는 네트워킹 시간도 조금 있었으면 좋겠다.

AI를 나쁘게만 생각하지 말고 충분히 컨트롤하고 이용할 수 있다면 업무 효율이 훨씬 늘어날 것 같다.

하지만 제일 중요한건 AI를 이용할 수 있는 베이스다.

최근에는 chat gpt를 이용해 코드 받았을 때 버그가 발생하면 디버그 시간이 더 오래걸렸다.

이러한 불상사를 막기 위해 자신의 실력을 더 키워야 한다고 생각한다.

로드 밸런싱(Load Balancing)

integerJI — Wed, 10 May 2023 22:09:56 +0900

로드 밸런싱(Load Balancing)

서비스의 규모가 커지고 서버 한대로는 서비스 운영이 어려울 때, 대처할 수 있는 방법은 크게 두 가지 입니다.

Scale-up : 기존 서버의 성능을 업그레이드한다.
Scale-out : 기존 서버와 동일하거나 낮은 성능의 서버로 증설한다.

각 서비스 별 상황에 맞게 처리를 해야 한다.

여기서 Scale-out 방식을 채택하였다면 여러 대의 서버로 트래픽을 균등하게 분산해 주는 로드밸런싱 작업이 반드시 필요하다.

로드밸런싱이란?

클라이언트에서의 트래픽으로 인해 서버에 가해지는 부하를 분산 시켜주는 장치이다.

클라이언트와 서버 또는 네트워크 허브 사이에 위치한다.

로드밸런싱의 알고리즘

Round Robin (라운드로빈 방식)
- 서버에 들어온 요청을 순서대로 돌아가며 각 서버에 균등하게 분배하는 방식.
- 여러 대의 서버가 동일한 스펙을 가지고 있다면 사용하기 적합하다.
IP Hash (IP 해시 방식)
- 클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리한다.
- 사용자의 IP를 해싱하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.
Least Connection (최소 연결 방식)
- 요청이 들어온 시점에 가장 적은 트래픽을 처리하고 있는 서버에 우선 적으로 트래픽을 분배한다.
Least Response Time (최소 리스폰 타임)
- 서버의 현재 연결 상태와 응답 시간을 모두 고려하여 트래픽을 분배한다.

로드밸런싱의 대표적인 4가지 알고리즘이다. 한 가지 더 추가를 하자면 가중 라운드 로빈 방식으로 서버마다 가중치를 설정하여 부하를 분배하는 방식이다.

이 알고리즘을 통하여 OSI의 7계층 중 L4, L7에 로드밸런싱을 구축한다.

로드밸런싱 L4, L7

	L4	L7
네트워크 계층	Layer 4 전송계층(Transport Layer)	Layer 7 응용계층(Application Layer)
특징	TCP/UDP 포트 정보를 바탕으로 작동 네트워크 계층이나 전송계층의 정보를 바탕으로 트래픽을 분산	TCP/UDP를 포함하여 HTTP의 Url, Ftp의 파일명, 쿠키 정보 등을 바탕으로 작동 (TCP/UDP를 확인할 수는 있지만 응용계층에서 프로토콜 기반의 정보를 처리하려면 L4가 낫다.)
장점	1. 데이터를 보지 않고 패킷 레벨에서만 트래픽을 분산하기 때문에 속도가 빠르고 효율적이다. 2. 데이터의 내용을 복호화 할 필요가 없어 안전하다. 3. L7보다는 가격이 저렴하다.	1. 상위 계층에서 로드를 분산하기 때문에 훨씬 더 섬세한 라우팅이 가능하다. 2. 캐싱 기능을 사용할 수 있다. 3. 비정상적인 트래픽을 사전에 필터 할 수 있어 서비스의 안정성이 높아진다.
단점	1. 패킷의 내용을 볼 수 없기 때문에 섬세한 라우팅이 불가능하다. 2. 사용자의 IP가 수시로 바뀌는 경우 연속적인 서비스를 제공하기 어렵다.	1. 패킷의 내용을 복호화 해야 하기 때문에 높은 비용을 지불해야 한다. 2. 클라이언트가 로드밸런서와 인증서를 공유하기 때문에 공격자가 로드밸런서를 통해서 클라이언트 데이터에 접근할 경우 보안상 위험성이 존재한다.

chat gpt 활용

integerJI — Sun, 19 Mar 2023 18:56:40 +0900

방금 글을 쓰고 추가로 요즘 핫한 chat GPT에게 이 글에 대해서 물어봤는데 이런 답변을 받았다.

나는 gpt를 이런식으로 활용하고 있는데 정말 좋은 것 같다.

다음에는 게시글을 쓰기 전에 먼저 확인받고 질 좋은 글을 써야겠다.

[mssql] 인덱스를 타지 않는 쿼리

integerJI — Sun, 19 Mar 2023 17:15:00 +0900

Mssql을 사용하며 Index를 타지 않는 Query를 정리해 보자

도움 된 블로그!

hckcksrl

isstory83

1. where 컬럼의 가공, 함수, 연산, 형변환 금지

SELECT
	[buy_id]
    , [product_id]
    , [create_date]
FROM
	[dbo].[pmt_product_buy]
WHERE 
	CONVERT(DATE, [create_date]) < '2022-01-01'

해당 쿼리는 create_date 컬럼에 대한 Index를 타지 않는다.

convert 함수를 통하여 변형이 되었기 때문에 create_date와는 다른 컬럼이 된다.

개선 방법은

SELECT
	[buy_id]
    , [product_id]
    , [create_date]
FROM 
	[dbo].[pmt_product_buy]
WHERE 
	[create_date] BETWEEN '2022-01-01' AND '2022-03-01'

다른 함수를 사용하여 데이터를 조회해야 한다.

2. Like 검색 시 문자열 앞에 % 사용 금지

SELECT
	t1.*
FROM
	[dbo].[pmt_product_info] t1
WHERE
	[product_price] LIKE '%3%'

문자열 앞에 %가 붙게 될 경우 product_price 컬럼의 인덱스와는 무관하게 전체 풀스캔을 타게 된다.

부득이하게 대용량의 모든 테이블을 조회할 경우에는 차라리 where을 통하여 한번 데이터를 필터링한 후 조회를 하거나

카프카와 검색 엔진을 사용하여 조회하면 좋다.

3. Null 조건의 사용

SELECT
	t1.*
FROM
	[dbo].[pmt_product_info] t1
WHERE
	[product_price] is null

where절에 null을 사용할 경우 인덱스와 무관하게 풀 스캔을 하게 된다.

4. not(부정문)을 사용할 경우

SELECT
	t1.*
FROM
	[dbo].[pmt_product_info] t1
WHERE
	[product_price] != 3000

부정문을 사용할 경우 index를 타지 않는다.

한 값에 대한 부정이 아닌 범위를 지정하여 검색하는 게 좋다.

SELECT
	t1.*
FROM
	[dbo].[pmt_product_info] t1
WHERE
	[product_price] < 3000 and [product_price] > 3000

5. in, or 연산

SELECT
	t1.*
FROM
	[dbo].[pmt_product_info] t1
WHERE
	[product_price] in (3000, 1500, 1000)

in 조건을 사용할 경우 항상 인덱스를 타지 않는 것이 아니라 in 조건 안에 포함되는 데이터가 많을 경우 데이터베이스가 판단하여 테이블을 풀스캔을 한다고 한다..;;

이 부분은 매우 흥미로운 부분이었다.

or 조건의 사용은

SELECT
	t1.*
FROM
	[dbo].[pmt_product_info] t1
WHERE
	([product_price] = 3000 or [product_price] = 1500 or [product_price] = 1000)

or의 경우 인덱스를 사용하지 못한다. 참이 하나라도 있으면 참이기 때문에 풀 스캔을 타게 된다.

2023.09.25 추가

DISTINCT가 낮은 경우 인덱스를 만드는게 아니라 전체에서 찾는게 더 빠르기 때문에 인덱스를 안만드는게 좋다.

(ex 사전을 열었는데 남성과 여성의 확률이 50%일 경우 굳이 찾을 필요가 없어서 전체 테이블을 스캔)

6. 복합인덱스일 경우의 인덱스 호출 순서

SELECT
	[buy_id]
    , [product_id]
    , [create_date]
FROM 
	[dbo].[pmt_product_buy]
WHERE 
	[product_price] = 3000
	and [create_date] BETWEEN '2022-01-01' AND '2022-03-01'

복합 인덱스의 경우 인덱스의 순서가 product_price, create_date일 경우 순서대로 조건을 걸어야 한다.

이 부분도 되게 흥미로웠다.

참고 : tothek님의 블로그

해당 블로그를 보면서 더 공부를 해야겠다.

7. 올바르지 않은 데이터 타입 조회

SELECT
	[buy_id]
    , [product_id]
    , [create_date]
FROM 
	[dbo].[pmt_product_buy]
WHERE 
	[product_price] = '3000'

product_price 컬럼의 경우 Int 타입이다.

하지만 String 타입의 값을 넣어 조회를 할 경우 인덱스를 타지 않을 수 있다.

---

어떤 분야든 파고들면 끝이 없는 것 같다.

그래도 다행인 건 모르는 지식을 알아가는 게 재미있어서 다행이다.

부족한 부분을 채우기 위해 GPT에게 물어봐서 팩폭도 맞았다. https://integer-ji.tistory.com/404

DDD 8기의 마무리와 새로운 시작

integerJI — Sun, 12 Feb 2023 22:31:57 +0900

DDD 8기 프로젝트를 마무리하며 회고를 적어 보았다.

https://integer-ji.tistory.com/399

DDD 8기 중간회고

DDD 8기 중간회고 2022년 10월부터 시작 한 DDD 8기 원티드에서 모집 한 DDD 동아리란 "dynamic designer developer"의 약자이다. 현업에 종사하고 있는 디자이너와 개발자를 연결해 줘 다양한 네트워킹과 프

integer-ji.tistory.com

우리의 서비스 간단 소개

자연스럽게 우리의 일상 속에서 불편한 점을 해결하기 위해 들어갔다.

우리 팀(안드2, 서버 1, 디자이너 2) 모두 운동에 관심이 많았고 PT를 받으며 공통적으로 불편한 점이 있었다.

오히려 PT운동을 받으면서 운동하는 입장이 아닌 트레이너 입장의 앱을 만들기로 하였다.

트레이너를 위한 멋진 앱 FitNote

~~2월 중 플레이스토어에 출시 예정이다!~~

2월 8일 출시 완료 되었다!

4월 28일 ver0.0.1 업데이트 완료

내가 한 일은?

나는 FitNote에서 서버파트였다. Python Django 프레임 워크를 사용하여 restful api로 개발을 진행하였고 서버는 Nginx를 통해 gunicorn을 사용하였다.

나의 성장 정리

나는 지금까지 restful를 사용해 개발을 해본 적이 없었다. 따라서 Front, AOS, IOS 등 모두 혼자 개발을 진행해 왔고 혼자 개발을 해왔다. 그러다 보니 Front, IOS, Android에 API를 던져줄 때 머릿속에서 어떤 식으로 데이터를 주어야 되는지 익숙하지 않았다.

하지만 이번 프로젝트를 통하여 타 직군과의 소통을 알게 되었고 다른 직군의 고충을 통하여 좀 더 유하게 데이터를 전달해 줄 수 있지 않을까?라는 성장을 했다는 느낌이 든다!

앞으로의 방향과 새로운 시작

나는 이 프로젝트를 꼭 출시를 시킬 것이다. 팀원들과 함께 끝을 보기로 하였으며 모두 개인의 성장을 위해 여러 가지 실험을 할 예정이다. 무엇보다 이제 사이드 프로젝트에서만 사용하던 Python을 그만하고 Java에 집중할 생각이다. Java와 함께 Kotlin을 사용하여 리펙토링 후 서버도 Docker Stack를 사용하여 좀 더 지금의 기술을 깊게 파고들 생각이다.

기술을 사용하며 진정한 개자가 될때까지 파이팅!

브런치먹기

integerJI — Sun, 5 Feb 2023 19:33:57 +0900

주말의 시작을 빨리 하기 위해 주찬 모임에 참가해 보았다.

장소는

카페413프로젝트
서울 강남구 논현로97길 19-11
https://naver.me/FQaIaP4Z

카페413프로젝트 : 네이버

방문자리뷰 633 · 블로그리뷰 1,255

m.place.naver.com

카페413프로젝트로 역삼역 근처에 있었다.

입구부터 귀여운 고양이가 반겨주었다.

조찬 모임에서의 주요 내용은 이번 한 주는 어떠하게 보내었는지, 한주를 돌아보는 회고의 이야기로 모이게 되었다.

과연 이번주의 나는 어땠을까?

분명 그 당일이나 혹은 다음날 생각하고 다짐한 게 있을 것이다.

하지만 역시 그 다짐은 그날에 했던 다짐일 뿐 전혀 기억나지 않았었다.

모인 사람들과 이야기를 하며 자신을 돌아보니 잊었던 다짐을 다시 생각나게 하는 좋은 자리였다.

소세지 베이컨 오믈렛

이야기하다 보니 브런치가 나왔다.

각자의 고민을 털어놓고 공유하는 좋은 자리였다.

모두 잘 되었으면 좋겠다.

fatal: unable to access '': SSL certificate problem: unable to get local issuer certificate

integerJI — Mon, 30 Jan 2023 20:12:00 +0900

fatal: unable to access '': SSL certificate problem: unable to get local issuer certificate

SSL 인증서가 필요 없는 항목을 clone할 때 해당 에러가 나온다면

git config --global http.sslVerify false

이 명령어를 사용하여 SSL 옵션을 false 시켜주면 된다.

DDD 8기 중간회고

integerJI — Sun, 15 Jan 2023 21:13:18 +0900

DDD 8기 중간회고

2022년 10월부터 시작 한 DDD 8기

원티드에서 모집 한 DDD 동아리란 "dynamic designer developer"의 약자이다.

현업에 종사하고 있는 디자이너와 개발자를 연결해 줘 다양한 네트워킹과 프로젝트를 만들 수 있게 도와주는 동아리이다.

벌써 DDD가 시작한지 중간 이상이 지났다.

나는 지금까지 어떤걸 얻었을까 회고하는 시간을 가져 보았다.

* 시작할때의 다짐

첫 다짐은 나 자신의 성장이다. 또한 이직을 한 뒤 현업에 뒤처지지 않고 빠르게 적응하기 위한 디자이너, WEB/APP 개발자와의 소통력 향상을 목표로 시작하게 되었다.

* 지금은?

많이 좋아진 것 같다. 디자이너와 소통하는 법과 디자이너가 사용하는 툴의 이해하게 되었고 디자인을 보며 API를 어떤 식으로 개발해야 할지 생각해 볼 수 있는 좋은 기회였다.

또한 나는 Android 팀에 배정 되어 AOS 개발자와 소통하였는데 지금까지는 나 혼자 WEB까지 개발하며 편하게 API를 만들고 프레임워크에만 의존을 하였는데 이번 기회로 프레임워크의 커스텀, 프레임워크에 의존하지 않고 직접 만드는 방법 등 다른 직군과의 개발적 소통을 알게 되었다. 이 부분이 있어서 나에게 가장 좋은 부분이었다.

* 아쉬운점

프로젝트를 진행하며 실제 출시를 위해 제일 익숙 한 Python Django를 사용하여 API/Server 개발을 진행하였다. 하지만 이제 Java 언어를 쓰며 백엔드 개발을 시작한 지 4년 차가 되었다. 더 이상 사이드 프로젝트를 Python으로 진행하는 게 아니라 나의 직무 기술을 더 깊이 있게 배우고 싶은 욕망이 생기게 되었다. 또한 이제 Python보단 Java가 익숙하다 ㅎㅎ..

* 앞으로의 방향성

진행하고 있는 프로젝트를 기반으로 Java로 다시 만들어 보고 싶다. Java를 이용하여 기본 틀을 만들고 다시 새롭게 Java 프로젝트를 참여하고 싶다.

세상은 넓고 나는 우물 안의 개구리란 걸 알게 되었다. 하지만 그만큼 세상에는 지식이 많다는 뜻으로 생각이 된다. 그 지식을 알아갈 생각에 기대가 되며 너무 재밌을 것 같다. 빨리 많은 걸 알고 싶어 지는 회고였다.

재해발생 4단계 순서

integerJI — Mon, 19 Dec 2022 09:45:05 +0900

재해발생 4단계 순서로써는

1. 현장조사
2. 구조요청
3. 상태파악 후 조치
4. 안정화

이다.

현장조사 후 구조 요청이 진행 된다.

ImportError: Could not import 'rest_framework_jwt.authentication.JSONWebTokenAuthentication' for API setting 'DEFAULT_AUTHENTICATION_CLASSES'. ImportError: cannot import name 'smart_text' from 'django.utils.encoding'

integerJI — Sat, 12 Nov 2022 20:41:51 +0900

ImportError: Could not import 'rest_framework_jwt.authentication.JSONWebTokenAuthentication' for API setting 'DEFAULT_AUTHENTICATION_CLASSES'. 
ImportError: cannot import name 'smart_text' from 'django.utils.encoding'

JWT를 Django에서 사용하며 생긴 에러입니다.

해당 에러는 Django 버전이 4버전 이상일 경우 발생됩니다.

rest_framework_jwt 해당 프레임워크 말고 "rest_framework_simplejwt"을 사용해줍니다.

여기서 -> 변경

djangorestframework-simplejwt pip도 설치해줍니다.

pip install djangorestframework-simplejwt

기존에 rest_framework_jwt 사용하던 소스도 모두 정리하여 줍니다.

이상!