즐겁게 살고 싶은 개발자

어느날 오픈코드에서 클로드가 갑자기 막혀서 간단한 오픈소스를 만들어봤다

평범한 개발자... — Fri, 26 Jun 2026 09:13:31 +0900

클로드 인증이 실패하다

지난 3월 여느 때처럼 AI 코딩 에이전트를 돌리고 있었습니다. 도구로는 opencode/oh-my-opencode(현재는 oh-my-openagent)를, 오케스트레이터 모델로는 클로드 오퍼스를 쓰고 있었습니다.

그날도 일어나자마자 자기 전에 돌려둔 작업부터 확인했습니다. 작업은 끝나 있었고, 이어서 다음 작업을 시키려는데 갑자기 클로드가 안 됐습니다. 클로드 서버가 워낙 자주 터지니까 좀 쉬었다가 다시 확인했는데, 여전히 그대로였습니다.

처음엔 opencode 버전 문제인 줄 알았는데, 확인해보니 아니었습니다. 뭔가 이상해서 opencode 깃허브 이슈에 들어가 보니, 저와 똑같은 증상을 겪는 이슈가 올라와 있었습니다.

이슈를 올린 사람이 직접 원인을 분석해서 플러그인을 새로 만들어 공유한 것도 보였습니다.

AI가 멈춰 있는 시간이 아까웠던 터라, 우선 그 플러그인부터 설치해봤는데 안 됐습니다. 그래서 문제를 해결하고 싶은 마음에 이슈를 제대로 들여다보기 시작했습니다.

버그가 아니라 정책 문제

그 플러그인을 만든 사람의 말로는, 실제로는 토큰을 교환하는 단계에서 막힌 거였고, opencode가 보내는 User-Agent가 클로드 코드와 달라 429가 난다는 분석이었습니다. 이유는 모르겠지만 제 환경에선 동작하지 않았습니다.

결국 버그가 아니라 클로드 정책 문제였습니다. Anthropic이 서드파티 OAuth 클라이언트를 토큰 단계에서 막은 거였고, opencode도 법적 요청을 받아 클로드 OAuth 지원을 제거했습니다(커밋 "Anthropic legal requests"). 이후 Anthropic은 약관에서도 클로드 구독 인증을 클로드 코드와 claude.ai 밖에서 쓰는 걸 금지했습니다.

헤더를 맞춰 로그인에 성공한 사람도 있었지만, 어차피 정책으로 막아둔 길을 우회하는 방법이었습니다.

npm으로 받은 인증 도구를 믿어도 될까

이때 이슈는 플러그인 춘추전국시대였습니다. 저를 포함하여 하루 이틀만에 '내가 만든 게 된다'는 댓글만 여러 개였습니다. 마침 경고하는 댓글도 하나 올라왔습니다. 급하게 인증 플러그인을 설치하다 보면, 누가 npm 패키지에 악성 코드를 심어도 제대로 확인하지 못하고 깔게 된다는 얘기였습니다.

저 또한 누군가 이제 막 만든 인증 토큰을 다루는 도구를 쓰는 건 조심스러웠습니다. 그래서 npm 플러그인 말고 다른 방법은 없을까 고민하게 됐습니다.

토큰을 옮기는 작은 스크립트

이슈 댓글에서 힌트를 발견했습니다. 클로드 코드가 쓰는 토큰을 꺼내 기존 opencode 클로드 인증 플러그인이 사용하고 있는 auth.json에 넣으면 동작한다는 거였습니다. 생각해보니 막힌 건 토큰 교환 API뿐이라, 이미 받아둔 토큰을 그대로 쓰면 됐습니다.

그리핀마틴도 클로드 코드 토큰을 활용한 플러그인을 만들었는데, 확인해보니 npm 설치 방식이어서 저는 스크립트로 만들어 공유하기로 했습니다.

먼저 나온 그리핀마틴 기존 내장 플러그인 방식을 대체하는 npm 방식이었지만, 저는 스크립트로 만들어 공유하기로 했습니다.

클로드 코드 인증 정보를 읽는다 (macOS Keychain 또는 ~/.claude/.credentials.json)
필드 이름을 opencode 형식에 맞게 바꾼다 (accessToken → access, expiresAt → expires …)
auth.json의 anthropic 항목에 써넣는다

{
  "anthropic": {
    "type": "oauth",
    "access": "...",
    "refresh": "...",
    "expires": 1770000000000
  }
}

근데 이 방식은 곧 제거될 예정인 opencode 내장 플러그인을 사용하는 거라 한계가 있었습니다. 그래도 대표 플러그인이 자리잡기 전까지 쓸 임시방편으로는 충분하다는 생각이 들었습니다.

마무리

단순히 한 번 복사하면 끝나는 스크립트는 아니었습니다. 토큰이 만료되면 다시 동기화해야 했고, 플랫폼마다 credentials 위치와 스케줄러도 달랐습니다. 노트북은 macOS, 회사 서버는 Linux, 회사 컴퓨터는 Windows라 세 환경을 직접 쓰면서 하나씩 고쳤습니다. 공개한 뒤로는 이슈로 버그를 올려주는 분도 있었고, macOS PATH 문제나 Linux 스케줄러를 직접 고쳐 PR을 보내준 분도 있었습니다.

위 버그를 수정해서 공유했을때 많은 이모지 반응이 있어서 놀랐었습니다.

다른 사람들의 아이디어에서 시작한 작은 스크립트였는데, 생각보다 깃허브 스타가 많이 붙어서 신기했습니다. 누군가 댓글에서 제 프로젝트를 언급해준 게 홍보가 됐던 것 같습니다.

초반에는 현재 자리잡은 플러그인인 그리핀마틴과 비슷하게 가다가, 금세 스타 개수가 벌어졌습니다. 그리고 1.3.0에서 opencode 내장 플러그인이 빠지면서, 제 오픈소스도 막을 내렸습니다. ㅎㅎ

그래도 다른 사람이 제 프로젝트에 버그를 올리고 고쳐주는 걸 처음 겪어봐서 좋았습니다.

[핫딜트래커] 핫딜 제목 데이터로 파인튜닝 해보기

평범한 개발자... — Wed, 17 Jun 2026 15:25:08 +0900

파인튜닝을 적용한 서비스를 만들어보고 싶었다

오픈 모델을 파인튜닝해서 실제 서비스 기능으로 써보고 싶었습니다.
저는 알구몬 같은 핫딜 사이트를 자주 이용하는데, 핫딜 글을 보다가 불편한 점이 있어서 여기에 파인튜닝을 붙여볼 수 있겠다는 생각이 들었습니다.

핫딜을 볼 때 가장 궁금했던 건 "이 가격이 진짜 싼가?"였습니다.

커뮤니티 핫딜 글에는 진짜 괜찮은 딜도 있지만, 업자나 바이럴 글이 섞여 있어서 애매한 딜도 꽤 많습니다.
특히 음료수, 생수, 화장지, 물티슈처럼 캔, 팩, 롤, 매수 단위가 붙는 상품은 용량과 수량 조합이 제각각이라, 가격만 봐서는 싼지 아닌지 판단하기 어려웠습니다.

이런 단위 상품들은 파인튜닝한 소형 LLM으로 단위 가격을 뽑아 데이터로 쌓아두면, 그 데이터로 핫딜인지 쉽게 구분하는 서비스를 만들 수 있겠다 싶었습니다.

핫딜 제목에서 어떤 값을 봐야 할까

보통 핫딜 게시글의 제목은 아래와 같은 포맷으로 올라옵니다.

[네이버] 코카콜라 제로 355ml 24캔 (15,900원/무료)
[11번가] 크리넥스 3겹 화장지 30m 30롤 (24,900원)
[쿠팡] LG 그램 16인치 노트북 16Z90S (1,490,000원/무료)

여기서 LLM의 역할은 두 가지입니다.

하나는 단가 계산에 쓸 값을 제목에서 뽑는 일입니다.
어디까지가 상품명인지, 행사 문구는 빼야 하는지, 500ml 20캔 같은 숫자가 단위 수치인지 수량인지를 추출합니다.

다른 하나는 서비스에서 필터링 기능을 위해 카테고리를 분류하는 것입니다.

항목	예시	왜 필요한가
상품명	코카콜라 제로	같은 상품인지 비교
상품 유형	용량, 무게, 개수, 묶음	어떤 방식으로 단가를 계산할지 결정
단위 수치	500	500ml, 100g처럼 계산에 쓰는 숫자
단위	ml, g, 개, 롤	가격을 나눌 기준
묶음 수량	20	전체 용량이나 총 개수 계산
카테고리	식품, 생활용품	검색 범위 줄이기
세부 카테고리	음료, 화장지	비슷한 상품 비교

핫딜 정답 데이터셋 만들기

크롤링해서 데이터를 수집하는 과정은 스킵하겠습니다.

수집된 데이터는 클로드코드를 이용해서 일차적으로 파싱하고, 결과를 직접 검수했습니다.

먼저 수집한 핫딜 제목들을 보고, 어떤 형태의 데이터가 많이 나오는지 분포를 정리했습니다.

단품형: 노트북, 선풍기 (개당 판매)
용량형: 500ml, 1.5L
중량형: 100g, 2kg
수량형: 24캔, 30롤, 20개입
모델명과 숫자가 섞인 상품
쿠폰, 무료배송, 행사 문구가 섞인 제목

그 다음 제목을 JSON 필드로 나누는 작업을 진행했습니다.

{
  "title": "코카콜라 제로 500ml 24개",
  "product_type": "volume",
  "product_name": "코카콜라 제로",
  "unit_value": 500,
  "unit": "ml",
  "quantity": 24,
  "category": "식품",
  "subcategory": "음료"
}

모델 정하기

현재 제 파인튜닝 환경은 RTX 5090입니다. 그래서 이 장비에서 무난하게 학습할 수 있는 소형 모델을 후보로 봤습니다.

조건은 아래와 같습니다.

RTX 5090 32GB에서 QLoRA 학습이 가능할 것
한국어 또는 다국어 제목을 어느 정도 처리할 수 있을 것
Unsloth, PEFT 같은 파인튜닝 도구에서 다루기 어렵지 않을 것

이 기준으로 7B~14B 정도의 모델을 후보로 잡았습니다.

Solar Mini
Qwen3 8B
Qwen3 14B
SKT A.X
EXAONE
EEVE-Korean

하나만 골라 파인튜닝하기보다는, 후보가 다 소형 모델이고 학습 데이터도 적어서 Unsloth 같은 최적화된 라이브러리를 쓰면 금방 학습이 끝나기 때문에, 모든 모델을 전부 학습하고 같은 테스트셋에서 비교했습니다.

파인튜닝 결과

train set: 4,830 rows
test set: 1,188 rows
schema: product_type, product_name, unit_value, unit, quantity, category, subcategory
training: QLoRA
evaluation: temperature=0

모델	모두 맞춘 비율	상품명	단위 수치	단위	수량	카테고리	세부 카테고리
EEVE-Korean LoRA	70.1%	90.5	96.3	96.6	93.9	93.7	82.8
EXAONE LoRA	65.6%	83.8	96.1	96.7	94.2	96.1	85.4
SKT A.X LoRA	64.6%	83.6	94.4	95.2	93.9	95.8	85.8
Qwen3 14B LoRA	64.4%	84.7	94.5	95.2	93.3	95.9	85.1
Solar Mini LoRA	63.7%	84.3	94.3	95.0	93.7	96.0	84.4
Qwen3 8B LoRA	62.7%	83.2	94.3	94.8	93.8	95.5	83.8

파인튜닝 결과 각 모델들의 단위, 수량, 카테고리 점수는 다 비슷했고, 상품명만 EEVE-Korean이 유독 높았습니다.

다른 항목이 다 비슷하다 보니, 상품명에서 점수가 높았던 EEVE-Korean이 모두 맞춘 비율도 가장 높게 나온 것 같습니다.

결론

핫딜트레커 서비스에서는 카테고리보다 상품명, 스펙이 중요했고, 그 기준에서 EEVE-Korean을 선택하는 게 가장 적합하다고 생각했습니다.
카테고리 점수가 낮긴 하지만, 이는 학습 데이터가 쌓일수록 어느 정도 보완될 것이라 봤습니다.

다음 글에서는 서비스를 며칠 운영하며 쌓인 데이터로, 모델이 약한 부분과 자주 틀리는 케이스를 찾아 개선해본 과정을 정리해보겠습니다

[Spring boot] @Transactional은 어떻게 동작할까? (+ 트랜잭션이 동작하지 않는 이유)

평범한 개발자... — Thu, 7 Oct 2021 16:44:09 +0900

여러분은 Spring 프레임워크를 사용하면서 @Transactional 어노테이션을 자주 사용해봤을 것입니다. 하지만 정확히 어떻게 동작하는지 그 원리를 제대로 이해하고 있나요?

최근 기술 면접에서 다음과 같은 질문을 받았습니다.

하나의 클래스에 두 개의 메소드가 있다고 가정합니다. 둘 중 하나의 메소드에만 @Transactional 어노테이션이 선언되어 있습니다. 그런데 선언되지 않은 메소드에서 선언된 메소드를 호출하면 트랜잭션이 동작하지 않습니다. 그 이유는 무엇인가요?

코드로 보면 다음과 같습니다.

@Service
public class OrderService {

    // @Transactional이 없는 메서드
    public void processAndCreateOrder(Order order) {
        validateOrder(order);
        createOrder(order); // 같은 클래스 안에서 호출
    }

    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
    }
}

processAndCreateOrder가 createOrder를 호출하니 트랜잭션이 적용될 것 같지만, 실제로는 적용되지 않습니다. 그 이유가 이 글의 핵심입니다.

처음에는 트랜잭션 전파(propagation)와 관련된 질문이라고 생각했지만, 면접관의 의도는 그게 아니었습니다. 결국 제대로 답하지 못했고, 트랜잭션 어노테이션이 어떻게 동작하는지 원리부터 설명해 보라는 추가 질문을 받았습니다.

솔직히 프록시 객체를 통해 실행된다는 점 정도만 알고 있을 뿐, 자세한 원리는 설명하지 못했습니다. 개발자로서 TDD, DDD, 클린 코드, 아키텍처, JPA 등 다양한 개념을 공부해 왔지만, 정작 가장 자주 사용하는 어노테이션의 원리를 제대로 몰랐다는 사실이 조금 부끄러웠습니다.

그래서 이번 기회를 통해 Spring @Transactional 어노테이션의 원리와, 자주 놓치기 쉬운 함정들을 정리해 보고자 합니다.

1. Spring AOP와 동적 프록시의 동작 원리

Spring의 AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍)는 핵심 비즈니스 로직과 부가 기능(트랜잭션, 로깅 등)을 명확히 분리하여 관리할 수 있도록 해주는 기술입니다. Spring은 프록시 객체를 이용해 부가 기능을 메소드 호출 전후에 주입합니다.

즉, 메소드 호출이 발생하면 프록시 객체가 호출을 중간에서 가로채어 부가 기능을 추가하는 형태입니다.

그런데 이 프록시는 두 가지 방식으로 만들어집니다. 어떤 방식이 쓰이는지가 뒤에 나올 함정과도 연결되니 짚고 넘어가겠습니다.

JDK Dynamic Proxy: 대상 클래스가 인터페이스를 구현하고 있을 때 사용됩니다. 인터페이스를 기반으로 프록시를 만듭니다.
CGLIB Proxy: 인터페이스가 없을 때 사용됩니다. 대상 클래스를 상속받아 프록시를 만듭니다.

원래 Spring은 인터페이스가 있으면 JDK, 없으면 CGLIB을 쓰는 방식이었지만, Spring Boot 2.0부터는 기본적으로 CGLIB을 사용합니다. 상속 기반이다 보니, 뒤에서 이야기할 final 관련 제약도 여기서 생깁니다.

2. @Transactional 어노테이션 적용 원리

Spring은 @Transactional을 발견하면 다음 구성 요소를 빈으로 등록합니다.

BeanFactoryTransactionAttributeSourceAdvisor: 어떤 메서드에 트랜잭션을 적용할지 판단하는 Advisor입니다.
TransactionInterceptor (Advice): 실제 트랜잭션 로직(시작, 커밋, 롤백)을 수행하는 핵심입니다.

프록시 객체가 메서드를 호출하면, 어드바이저 체인을 거쳐 TransactionInterceptor가 동작하며 트랜잭션이 관리됩니다.

TransactionInterceptor가 하는 일을 조금 더 풀어보면 이렇습니다.

flowchart TD
    S["트랜잭션 시작 (begin)"] --> C["target 메서드 실행"]
    C -->|정상 반환| CM["커밋 (commit)"]
    C -->|"RuntimeException / Error"| RB["롤백 (rollback)"]
    C -->|"체크 예외 (IOException 등)"| CM2["커밋 — 함정 주의"]

여기서 눈여겨볼 점이 하나 있습니다. 트랜잭션이 롤백되는 것은 기본적으로 RuntimeException이나 Error가 발생했을 때뿐입니다. 이 부분은 함정과 직결되니 아래에서 다시 다루겠습니다.

3. 클래스 내부 호출 시 트랜잭션이 동작하지 않는 이유

이제 면접에서 받았던 질문의 답입니다.

하나의 클래스 내부에서 메서드를 직접 호출하면, 프록시 객체를 거치지 않고 원본 객체(this)를 직접 호출합니다. 프록시를 거치지 않으니 AOP의 어드바이저 체인도 타지 않고, 결국 트랜잭션도 적용되지 않습니다.

외부 호출: 프록시 → TransactionInterceptor → 원본 객체 (트랜잭션 적용)
내부 호출: 원본 객체(this) 직접 호출 (트랜잭션 미적용)

flowchart TD
    subgraph ext["외부 호출 — 트랜잭션 O"]
        A[호출자] --> P[프록시 객체]
        P --> I["TransactionInterceptor (begin tx)"]
        I --> M1["원본 객체.createOrder()"]
    end
    subgraph self["내부 호출 — 트랜잭션 X"]
        M2["원본 객체.processAndCreateOrder()"] -->|"this.createOrder()"| M3["원본 객체.createOrder() (프록시 미경유)"]
    end

즉, @Transactional이 붙어 있어도 같은 클래스 안에서 this로 부르면 아무 소용이 없습니다.

덧붙이면, 내부 호출은 트랜잭션 적용뿐 아니라 propagation에도 영향을 줍니다. REQUIRES_NEW를 붙인 메서드를 내부 호출로 부르면, 프록시를 거치지 않으니 새 트랜잭션은 만들어지지 않습니다.

4. 그 외 자주 놓치는 함정

내부 호출 말고도, 프록시 기반이라는 특성 때문에 조용히 트랜잭션이 안 걸리는 경우가 몇 가지 더 있습니다.

1) private 메서드에는 적용되지 않습니다

프록시가 가로챌 수 있는 메서드에만 트랜잭션이 적용되기 때문에, private 메서드에 @Transactional을 붙여도 조용히 무시됩니다. 에러도 나지 않아서 오히려 더 위험합니다.

예전에는 public 메서드에만 적용됐지만, Spring 6.0(Spring Boot 3.0)부터는 클래스 기반 프록시(CGLIB)에서 protected, package-private 메서드도 지원됩니다. 다만 private은 여전히 제외입니다.

2) 체크 예외는 기본적으로 롤백되지 않습니다

많이들 놓치는 부분입니다. @Transactional은 기본적으로 RuntimeException과 Error에만 롤백합니다. IOException 같은 체크 예외가 터지면 롤백되지 않고 그대로 커밋됩니다. 체크 예외에도 롤백이 필요하면 직접 명시해야 합니다.

@Transactional(rollbackFor = Exception.class)
public void createOrder(Order order) {
    orderRepository.save(order);
}

3) final 클래스/메서드는 프록시를 만들 수 없습니다

CGLIB은 대상 클래스를 상속해서 프록시를 만드는데, final 클래스나 final 메서드는 상속과 오버라이드가 불가능합니다. 그래서 프록시가 만들어지지 않고 트랜잭션도 적용되지 않습니다.

5. 해결 방법

내부 호출 문제를 푸는 방법은 여러 가지가 있는데, 저는 아래 순서로 고려하는 것을 권합니다.

1) 트랜잭션 메서드를 다른 빈으로 분리 (권장)

가장 깔끔하고 근본적인 방법입니다. 트랜잭션이 필요한 메서드를 별도 클래스로 옮기면, 호출이 자연스럽게 프록시를 거치게 됩니다.

@Service
public class OrderService {

    private final OrderProcessor orderProcessor;

    public void processAndCreateOrder(Order order) {
        validateOrder(order);
        orderProcessor.createOrder(order); // 다른 빈 → 프록시 경유
    }
}

@Service
public class OrderProcessor {

    private final OrderRepository orderRepository;

    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
    }
}

2) 자기 자신을 주입받아 사용

구조를 바꾸기 어렵다면, 스프링 컨텍스트를 통해 자기 자신(프록시)을 주입받아 호출할 수 있습니다. @Lazy를 붙이는 이유는 자기 자신을 주입할 때 생기는 순환 참조 문제를 피하기 위해서입니다.

@Service
public class OrderService {

    private final OrderRepository orderRepository;

    @Autowired
    @Lazy
    private OrderService self;

    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
    }

    public void processAndCreateOrder(Order order) {
        validateOrder(order);
        self.createOrder(order); // 프록시를 통해 호출
    }
}

3) 그 외

TransactionTemplate으로 트랜잭션을 코드에서 직접 여는 방법
AopContext.currentProxy()로 현재 프록시를 얻는 방법 (@EnableAspectJAutoProxy(exposeProxy = true) 필요)

상황에 따라 쓸 수 있지만, 개인적으로는 가능하면 1번처럼 설계로 푸는 쪽을 선호합니다.

마무리

지금까지 Spring @Transactional의 동작 원리와, 내부 호출을 비롯해 자주 놓치는 함정들을 살펴봤습니다.

돌이켜보면 그때 저는 문제 자체를 제대로 이해하지 못했습니다. 매일 쓰던 어노테이션인데, 정작 어떻게 동작하는지는 모르고 있었던 것입니다. 이번에 정리하면서 그 부분을 처음으로 제대로 들여다봤습니다.

REST, RESTful, REST API에 대한 오해와 진실

평범한 개발자... — Tue, 5 Oct 2021 10:38:28 +0900

서론

백엔들 개발자라면 누구나 한 번쯤은 본 유명한 발표자료입니다.

그런 REST API로 괜찮은가

발표에서의 핵심내용은 아래와 같습니다.

오늘날 대부분의 "REST API"는 사실 REST를 따르지 않고 있다.
REST의 제약조건을 만족하지 않고 있기 때문이다.

해당 발표로, 우리가 잘못 알고있는 상식들을 바로잡는데 크게 기여했다고 생각합니다.

그러나 아직까지도 각종 블로그 포스팅글에 REST, RESTful, REST API, RESTful API 등의 용어들이 마치 웹 서비스용 API 라는 하나의 뜻으로 정의되어 남용 및 혼용되는 경우를 많이 봅니다.

뭐, 대충 뜻만 통하면 되는거 아닌가...? 라고 생각이 들다가도,

REST의 창시자인 Roy Fielding이 개인 블로그를 통해, REST API라 불리는 것들이 REST 규약을 위반하고 있으니, 규약을 지키거나 다른 단어를 선택하라고 말합니다.

고로 창시자의 뜻을 이어받아, 우리가 알고있는 REST에 대한 잘못된 상식 이를 바로 잡기위한 글을 써보려고 합니다.

레츠고!

대표적인 오해 6가지

1. REST는 웹 서비스 API 정의를 위한 아키텍처이다.

REST는 웹 서비스 API를 정의할 때 이해하기 쉽고 사용하기 쉬운 URL을 만드는 규칙이 아닙니다.

놀랍게도 REST의 개념이 처음 등장한 Roy Fielding의 논문은 2000년에 출간되었고, 이 시대에는 우리가 흔히 알고있는 웹 서비스 API가 존재하지 않았습니다.

Roy Fielding은 HTTP/1.0 (1991~~1995), HTTP/1.1 (1995~~1999)의 주요 저자 중 한명이고,
수십 년의 변화를 견딜 수 있고, 독립적으로 진화하는 시스템을 만들기 위해 REST를 설계했다고 합니다.

자세한 내용은 인터뷰를 통해 확인할 수 있습니다.

REST의 정확한 정의는 분산형 하이퍼미디어 시스템을 위한 아키텍처 스타일이라고 논문에 나와있습니다. REST 아키텍처가 잘 적용된 대표적인 예시는, 우리 모두가 잘 알고있는 웹사이트 입니다.

2. REST는 HTTP 표준을 기반으로 구현한다.

REST는 어떤 구현체가 아니라, 아키텍처 스타일입니다. 그리고 REST는 특정 네트워크 프로토콜에 국한되지 않습니다.

물론 REST가 HTTP 문제점을 해결하기 위해 만든 아키텍처이고, 실제로 REST의 규약들은 웹 환경에 최적화 되어있습니다. 그러나 웹은 REST 스타일 아키텍처가 잘 적용된 하나의 예시이고, 핵심은 분산 하이퍼 미디어 시스템에 있다고 논문 일부에 설명되어있습니다.

The modern Web is one instance of a REST-style architecture. Although Web-based
applications can include access to other styles of interaction, the central focus of its
protocol and performance concerns is distributed hypermedia

3. REST는 HTTP 프로토콜을 활용하는 아키텍처이다.

2번과 비슷한 내용입니다. REST는 프로토콜과 관련이 없는 아키텍처이지만, 제약조건 때문에 헷갈릴 수 있습니다.

REST의 제약조건을 살펴보면 아래와 같습니다.

Client–server architecture
Statelessness
Cacheability
Layered system
Code on demand (optional)
Uniform interface

제약조건의 자세한 내용은 위키피디아나 논문 챕터 5.1부터 확인할 수 있습니다.

HTTP에 대해 공부를 하신 분들이라면 이거 HTTP에 대한 내용이 아닌가? 라는 생각이 드실텐데, 그 이유가 바로 HTTP는 REST 아키텍처 스타일이 반영된 프로토콜이기 때문입니다.

REST는 HTTP/1.0 → HTTP/1.1로 넘어오면서 반영됐습니다.

HTTP와 REST의 관계?

그렇다고해서 HTTP가 REST라는 이야기가 아닙니다. HTTP는 REST 아키텍처 스타일이 반영되었기 때문에, HTTP를 이용하여 REST 제약조건이 잘 지켜진 RESTful 시스템을 쉽게 만들 수 있다는 것이 핵심입니다.

다른 네트워크 프로토콜을 이용하여 REST 아키텍처를 따르는 시스템을 만든다면 그 또한 RESTful 시스템입니다.

4. REST와 RESTful은 같은 말이다.

RESTful은 공식적인 단어도, REST의 창시자가 만든 단어도 아닙니다. (논문에 RESTful이란 단어는 등장하지 않습니다.)

다만, REST의 제약조건을 모두 따르는 시스템을 RESTful, 혹은 RESTful 시스템이라고 전 세계적으로 무언의 약속을 한 것같습니다.

앞에서도 언급한 웹사이트 는 REST의 제약조건을 모두 따르기 때문에 RESTful 이라 할 수 있습니다.

5. REST API는 HTTP 메서드를 사용하여 검색, 생성, 업데이트, 삭제한다.

반복하지만 REST는 특정 네트워크 프로토콜에 국한되는 개념이 아닙니다.

REST API는 REST의 제약조건을 따르는 API 이다. 정도로 나타낼 수 있고, HTTP 메서드를 사용하여 검색, 생성, 업데이트, 삭제한다. 라는 내용은 단순히 HTTP RPC의 일부입니다.

6. /customer 또는 /cusrtomer/1과 같은 리소스에 대해 알기쉬운 URL를 정의하는 것이 REST 제약 조건에 해당하며 RESTful API라 부른다.

REST와 관련이 없는 내용입니다. 아마 이런 내용이 널리 퍼지게된 이유 중 하나가 마이크로소프트 REST API 가이드 라인 때문이지 않을까 싶네요.

7장에 아래와 같은 내용이 있습니다.

인간은 URL을 쉽게 읽고 구성할 수 있어야 한다.

REST 가이드 라인에 이런 내용이 있으니, 해당 내용이 REST의 제약 조건이라고 착각하게 만들었나봅니다.

REST를 이해하기 어려운 이유

1. REST라는 단어가 남용되고 있다.

우리가 처음 접하게 되는 REST API, RESTful API라는 용어는 대부분 웹 서비스 API 정의를 위한 아키텍처 정도로 생각합니다.

수 많은 블로그에 나와있는 내용들을 보면서, REST는 HTTP 메소드와 알기 쉬운 URL을 통해 쉽고 편하게 사용할 수 있는 사용자 API를 만들기 위한 아키텍처 혹은 제약사항 정도로 이해하게 됩니다.

2. REST라는 단어를 직역하여 이해하려고 한다.

REST는 Representational state transfer의 줄임말이며, 번역기나 사전을 통해 직역하면 대표 상태 이전 혹은 표현 상태 이전 인데, REST의 제약사항을 보았을때 표현 상태 전송이 더 어울리는것 같습니다.

REST를 웹 서비스 API 정의를 위한 아키텍처로 알고있는 상태에서 REST의 풀네임의 직역 및 정의를 읽게되다면 서로 매칭이 안되니까, 무슨 말인지 이해못하는게 당연하지 않나 생각됩니다.

REST는 왜 만들어졌는가?

REST를 왜 만들었는지 그 의도와 해결하기 위한 고민을 알게되면 이해하기 쉽습니다.

Roy Fielding은 수십 년의 변화를 견딜 수 있는 시스템을 만들고 싶어 하였고, 그 시스템을 만들기 위해 끊임없는 질문과 고민을 하였습니다.

웹을 손상시키지 않고 HTTP를 어떻게 발전시킬 수 있을까?
시대가 바뀌면서 확장성 및 일관성 문제는 어떻게 해결할 수 있을까?
Web과 같은 분산 하이퍼미디어 시스템이 생겨난다면 서로 어떻게 연결해야 할까?

이런 고민끝에 만들어진게 REST이고, REST가 반영된 프로토콜이 HTTP이며, 이 HTTP를 이용하여 웹이 서로 통신합니다. 그래서 우리는 여전히 최신 웹브라우저를 통해 80~90년대에 만들어진 웹사이트에 접속할 수 있습니다.

인터넷에서 가장 오래된 웹사이트 15개

REST를 꼭 알아야할까?

Roy Fielding의 PPT 발표 자료 마지막에 나와있습니다.

시스템 전체를 제어할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 논쟁하는 데 시간을 낭비하지 마세요.

라고 합니다.

진정한 REST API에 대해 알고싶다.

Roy Fielding 개인 블로그 글 (REST API는 하이퍼텍스트 기반이어야 합니다.)
을 통해 사람들이 자주 위반하는 룰 6가지 정도를 설명합니다.

그리고 REST, REST API, RESTful API에 관한 사람들의 질문에 대한 답글 또한 최대한 길게 풀어서 설명합니다.

제가 설명하는것 보단, 해당 글을 번역해서 쭉 읽는게 훨씬 더 도움이 될 것 같습니다.

결론

공부하면서 REST가 무엇인지 정확하게 알게되었습니다.

API를 개발하는 백엔드 개발자로써, REST는 저랑 상관 없는 단어라는 것을 알게되었습니다.

그리고 수 십년을 내다본 Roy Fielding이란 인물을 매우 존경하게 되었습니다.

[참고]
https://www.infoq.com/articles/roy-fielding-on-versioning/
https://deview.kr/2017/schedule/212
http://slides.com/eungjun/rest#/69
https://twobithistory.org/2020/06/28/rest.html#fnref:6
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf
https://stackoverflow.com/questions/2190836/what-is-the-difference-between-http-and-rest
https://news.ycombinator.com/item?id=7201871
https://en.wikipedia.org/wiki/Representational_state_transfer
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
https://shoark7.github.io/programming/knowledge/what-is-rest

GitLab CI/CD + SSH 공개키를 이용한 자동배포

평범한 개발자... — Tue, 14 Sep 2021 15:20:47 +0900

Start

Gitlab + AWS 연동에 관한 글을 참 많지만.. 저처럼 IDC 서버를 사용하는 사람들에겐 해당하지 않는 내용이라..

자료도 많지 않고, 설명이 부실한 글들이 많아서 직접 정리해봅니다.

무작정 따라하는것 보다, 공개키를 이용한 SSH 접속의 전체적인 흐름을 이해하고 읽는 것이 훨씬 더 도움됩니다.

SSH 공개키 인증을 사용하여 접속하기

Process

클라이언트 키쌍 생성 (공개키-비밀키)
- 패스워드 입력 없이 SSH 접속하기 위함.
- 패스워드 대신 공개키 및 비밀키 사용.
Gitlab Variables 등록
- 배포할 서버의 IP 혹은 도메인 주소 (노출돼도 상관없으면 스크립트에 직접 넣어도 됩니다.)
- SSH 비밀키 (생성한 키의 비밀키)
- (옵션) 배포 서버의 SSH 공개키 (주의: 생성한 키의 공개키가 아님)
  - known_hosts로 등록하기 위함
  - 서버의 SSH 공개키는 /etc/ssh 경로에 있으며, ssh 설치 시 생성됨
배포 서버에 공개키 등록 (생성한 키의 공개키)
- ~.ssh/authorized_keys 파일에 등록.
- SSH 클라이언트 접속 시, 등록되어있는 공개키의 해당하는 비밀키를 가지고 있다면 접속을 허용해줍니다.
Gitlab 스크립트 작성
자동 배포 확인

1. 클라이언트 키쌍 생성

ssh-keygen 명령어를 이용하여 키쌍을 생성합니다.
- Windows 10이나 대부분 리눅스는 기본적으로 설치가 되어있는데, 없으면 설치하면 됩니다.
- cmd 창에 ssh-keygen 명령어를 입력하고, 엔터를 쭉쭉 눌러주면 C:Users\계정\.ssh\ 경로에 키쌍이 생성됩니다.
- ssh-keygen 명령어의 기본 값은 아래와 같습니다.
  - RSA 3072 비트 (SHA256)
  - 키 생성 경로: ~.ssh\
    - 윈도우, 리눅스 동일
    - 비밀키 (id_rsa)
    - 공개키 (id_rsa.pub)
  - 키에 패스워드를 지정하지 않음.

2. Gitlab Variables 등록

Settings -> CI/CI -> Variables -> Add variable
저는 이미 변수를 등록해놓은 상태입니다.

비밀키 등록
- Key
  - 스크립트에서 사용할 변수명
- Value
  - 아까 생성한 비밀키(id_rsa)를 붙여넣습니다.
- Type
  - File로 변경

서버 IP or 도메인 등록

(Option) 배포 서버의 SSH 공개키 등록

서버에 접속하여, /etc/ssh/ssh_host_*.pub 파일들을 확인합니다.
보통 ssh-server를 설치하면 3개의 키쌍이 생성되는데, 이 중 아무 공개키를 사용해도 무관합니다.

아래와 같이 변수로 등록해줍니다. (서버 IP주소 입력 후 한칸 띄어야 합니다.)
만약 포트가 22번이 아니라면 [IP주소]:포트 형태로 입력합니다.
- ex) [111.111.111.111]:2243 ssh-ed25519 AAAA.........JJJ
이 과정은 하지 않아도 되지만, 하는 이유와 하지않으면 어떤 문제가 있는지 설명합니다.

키를 등록하는 이유

서버에 처음 SSH 접속 시 아래와 같은 메시지를 많이 보셨을겁니다.

로컬에 서버의 키가 등록 되어있지 않은데, 이 서버를 신뢰할 수 있다면 로컬에 서버키를 추가 후 SSH 접속을 하고, 그렇지 않다면 접속하지 않습니다.
키를 추가하게 되면 다음부터 이 서버에 접속할 때 마다, 서버에 대한 인증을 위해 로컬에 저장되어있는 키를 이용하여 인증하는 과정을 거칩니다.
이런 과정을 통해 중간자 공격을 예방하여 안전하게 SSH 접속이 가능합니다.

Gitlab 변수로 등록하는 이유

SSH 클라이언트를 사용하는 우리 입장에서는, 엔터를 치거나 마우스 클릭으로 등록을 하면 됩니다.
그러나, 빌드 할 때마다 매번 새로운 도커 이미지가 생성되고 콘솔에서 조작이 불가능한 Gitlab에서는 스크립트를 통해 서버키를 미리 등록함으로써 해당 과정을 생략할 수 있습니다.

이 과정을 하지 않으면?

공개키 등록 대신에, ssh 설정으로 이 서버키 등록 과정을 생략하고 SSH 접속을 할 수 있습니다.
바로 Host Key Checking을 비활성화 하는 것인데요,
이 옵션을 추가하게 되면, 처음 접속할 때 공개키 등록 없이 바로 SSH 접속이 가능하게 되지만, 중간자 공격에 취약할 수 있습니다.

3. 배포 서버에 공개키 등록

키쌍으로 생성한 공개키를 서버의 ~/.ssh/authorized_keys 파일에 등록합니다.
- 많이 실수하는 부분인데, SSH로 접속할 계정의 홈디렉토리/.ssh 폴더입니다.
- 일반 유저계정으로 SSH 접속할건데, /root/.ssh/authorized_keys 파일을 수정하면 안됩니다.
공개키 등록 방법
1. 직접 등록
  - vi와 같은 편집기를 통해 공개키 복사 및 붙여넣기 합니다.
2. ssh-copy-id 명령어 이용
  - 윈도우
    - 윈도우는 ssh-copy-id 명령어가 없기 때문에, 다른 명령어로 대체합니다.
    - type $env:공개키위치 | ssh 계정@IP "cat >> .ssh/authorized_keys"
    - 만약 Windows에서 키쌍을 생성했다면 공개키의 경로는 C:\Users\계정\.ssh\id_rsa.pub 입니다.
    - 위 명령어를 수행하면 공개키값을 변수에 담아서 SSH 접속 후, .ssh/authorized_keys에 붙여 넣게됩니다.
    - 서버에 접속 후 authorized_keys을 확인해보면 공개키값이 잘 들어가있는 것을 확인 할수 있습니다.
  - 리눅스계열
    - 리눅스는 간단합니다. ssh-copy-id 계정@IP
    - 해당 명령어를 입력하면 ~/.ssh 폴더에 있는 공개키를 해당 서버에 등록합니다.

4. 스크립트 작성

프로젝트 최상위 폴더에 .gitlab-ci.yml 파일을 생성합니다.
아래 스크립트 내용 붙여넣습니다.

stages:
    - build
    - deploy

image: java:8-jdk # jdk8 도커 이미지 사용 (배포환경에 따라 변경할 것)

cache:
    paths: # .gradle 캐시 적용
        - .gradle/wrapper
        - .gradle/caches

build:
    stage: build
    before_script:
        - chmod +x ./gradlew # gradlew 실행권한 부여 (초기 권한 666 [-rw-rw-rw-])
    script:
        - ./gradlew build
    artifacts: 
        paths:
            - build/libs/*.jar    # build의 결과물인 jar파일을 artifacts로 지정. 
        expire_in: 1 week    # 1주일 동안 보관

deploy-to-server:
    stage: deploy
    before_script:
        - mkdir -p ~/.ssh
        - eval $(ssh-agent -s) # ssh-agent 백그라운드 실행

        ###############################################
        # 공개키 등록을 안했다면 Host Key Checking 비활성화 옵션 추가 (중간자 공격 위험)       
        # - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" >> ~/.ssh/config'    

        # 공개키 등록을 했다면 known_hosts 등록 및 권한 변경
        # - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
        # - chmod 644 ~/.ssh/known_hosts
        ###############################################

        - chmod 600 "$SSH_KEY" # 개인키 파일 권한변경 
        - ssh-add "$SSH_KEY"   # SSH 개인키 추가
    script:
        # SSH를 이용한 원격 파일 업로드
        - scp build/libs/*.jar 계정명@"$DEPLOY_SERVER_IP":~/BUILD_PATH/build.jar
        # 원격 스크립트 실행
        - ssh 계정명@"$DEPLOY_SERVER_IP" /BUILD_PATH/start.sh

아래는 서버에서 실행 할 원격 스크립트 파일 내용입니다.

단순히 기존 프로세스가 있으면 kill 후 재실행, 없으면 그냥 실행합니다.

#!/bin/sh
cd ~/BUILD_PATH
PID=$(ps -ef|grep build.jar|grep -v grep|awk '{print $2}')
if [ "$PID" == "" ]; then
  echo "no process exist"
else
  echo "process id (${PID}) killed"
  kill -9 ${PID}
fi
echo "Program Start"
nohup java -jar build.jar 1 > /dev/null 2>&1 &

5. 자동 배포 확인

Gitlab으로 Push 하여 CI/CD를 동작시킵니다.
별다른 문제 없이 성공하였다면, 서버에 접속하여 프로세스가 동작하는지 확인합니다.

MariaDB에는 'innodb buffer pool instances' 변수 설정이 없다...?

평범한 개발자... — Mon, 13 Sep 2021 09:15:53 +0900

최근 innodb buffer pool 설정 관련해서 찾아보다가 알게된 사실입니다.

MriaDB 10.5 변경사항에 innoDB 성능 항샹 내용 중 Multiple buffer pool Remove가 있습니다.
상식적으로 생각해봤을때 멀티로 동작하는게 무조건 성능이 좋다고 생각이 드는데, 지운 이유가 무엇일까요? 궁금해서 조금 찾아봤습니다.

innodb_buffer_pool_instances 변수 설명을 확인해보니, 10.5.1부터 해당 변수의 값이 비활성화되고 10.6.0부터 제거되었습니다.
제거된 이유는 단 한줄로 표시하였네요.

버퍼 풀을 분할하는 본래의 이유가 사라졌다.

왜인지 이유는 자세하게 설명을 안해주네요.. 궁금하게 참...
먼저 multiple buffer pool을 사용하는 이유 부터 알아보면

multiple buffer pool을 사용 이유

MySQL 공식 홈페이지에 잘 설명되어있습니다. (원문)
*다른 스레드가 캐시된 페이지를 읽고 쓸 때 경합을 줄임으로써 동시성을 향상시킬 수 있다. *가 핵심.

이유만 들어보면 엄청난 성능 향상이 있을것 같은데... 왜 없앴을까요??

지라 이슈 제기

지라 이슈 제기: Remove multiple InnoDB buffer pool instances
요약
- MySQL 5.5.5 버전부터 multiple buffer pools 도입 이후 뮤텍스 대신 rw-locks를 사용하도록 MySQL 5.6.2에 수정 과 같은 버퍼 풀간 뮤텍스 경합을 줄이기 위해 다수의 수정이 있었음
- multiple page cleaner threads use a lot of CPU on idle server 문제 검토 중 multiple buffer pools이 정말 성능향상에 도움이 되는지 궁금
- 그리고 뮤텍스 관련 MySQL 8.0.0 기능 추가되면서 MariaDB도 비슷한 작업을 수행해야한다고 이슈 제기.
  - 그러나 multiple buffer pools 과 page cleaners를 지원하기 위해 모든 코드를 지우는 것을 고려해야 한다 생각하고,
  - 향후 multiple buffer pools이 필요할 경우, 처음부터 잘 설계해야된다고 함.
- 결론은 single instance buffer pools과 multiple buffer pools의 성능을 비교해서, 단일 인스턴스 버퍼 풀이어도 성능 저하가 없다면 코드를 단순화 해야된다고 주장

다시 한번 정리 (뇌피셜로 분석한 제 생각입니다...)

multiple buffer pools 도입 이후 버퍼 풀간 뮤텍스 경합을 줄이기 위해 다수의 수정으로 코드가 복잡해져있는 상태에서
MySQL의 Mutex 분할 기능을 도입하기엔 설계 문제로 불가능하고 판단,
multiple buffer pools로 인해 생기는 성능 이슈도 있으니
single buffer pools과 multi buffer pools의 성능의 큰 차이가 없다면 기존 코드를 제거하여 single buffer pools로 가자!

2년간 이어진 기나긴 테스트...

지라 댓글 히스토리를 쭉 보니까, 거의 2년에 걸쳐서 테스트는 진행되었고 그 과정이 쉽지 않았다는게 느껴집니다.
single buffer pools 에서 생기는 병목현상을 다른 방향으로 해결하기 위해 여러 수정이 있었고,
결국 single buffer pools으로도 multiple 만큼 성능을 발휘하도록 만들었다고 하네요.

MySQL의 innodb buffer pool instances는?

percona의 CTO가 innodb buffer pool instances 관련 테스트 글을 작성하였습니다.

innodb_buffer_pool_instances 라는 매개변수가 어떤 값으로 설정해야 좋은지 나쁜지 애매모호하여 다양한 시나리오에서 테스트를 진행했다고 합니다.
- 서버 사양은 cpu core 80개, 메모리 188GB
- innodb_buffer_pool_instances를 1, 2, 4, 8, 16, 32, 64 로 설정하여 테스트 진행
- 첫 테스트는 innodb_buffer_pool_size를 25GB로, 두번째 테스트는 140GB로 설정

해당글의 결론은 아래와 같습니다.

높은 처리량과 적은 변동성을 고려하였을 때 64가 최선의 선택이지만, 그렇다고 무작정 이 값을 추천할 수 없다. (하드웨어 및 부하량에 따라 다름)
1-4는 처리량에 대한 변동성이 크기 때문에 8부터 테스트를 진행하여 최적의 값을 찾는걸 추천.

나의 생각

설정 값에 대한 정답은 없다. 하드웨어 사양 및 환경에 따라 다 다르고, 다양한 설정값으로 밴치마크를 하여 직접 비교해보는 것이 정답인듯 합니다.
시간이 된다면 MariaDB 10.6 vs MySQL8의 innodb_buffer_pool_instances 관련 성능 비교글을 작성해보고 싶네요.

SSH 공개키 인증을 사용하여 접속하기

평범한 개발자... — Mon, 13 Sep 2021 09:14:47 +0900

1. 공개키 암호화란?

공개 키 암호 방식은 암호 방식의 한 종류로 사전에 비밀 키를 나눠가지지 않은 사용자들이 안전하게 통신할 수 있도록 한다.
공개 키 암호 방식에서는 공개 키와 비밀 키가 존재하며, 공개 키는 누구나 알 수 있지만 그에 대응하는 비밀 키는 키의 소유자만이 알 수 있어야 한다.
공개 키는 보안 타협 없이 공개적으로 배포가 가능하다.
공개 키 암호를 구성하는 알고리즘은 대칭 키 암호 방식과 비교하여 비대칭 암호라고 부르기도 한다.
위키백과

공개키-개인키(비밀키)가 한 쌍으로 이루어져 있는 키 쌍이라 합니다.
공개키는 누구나 가질 수 있고, 개인키는 개인이나 중요한 사람만이 가지고 있습니다.

이런 특성을 이용하여 공개키 방식으로 암호화 및 인증에 사용됩니다.

메시지를 공개키로 암호화하면 개인키를 가지고 있는 사람만이 메시지를 복호화하여 메시지를 확인 할 수 있습니다. 개인키를 탈취당하지 않는 이상, 암호화된 메시지가 유출되어도 다른 사람이 절대 읽을 수 없습니다.

2. SSH 공개키 접속

SSH는 기본적으로 사전에 설정된 패스워드를 입력하여 접속하지만, 공개키 암호화에 사용되는 키 쌍을 가지고 접속할 수 있는 기능을 제공합니다.

사전에 자신의 공개키를 서버에 나눠주고, SSH 접속 시 개인키를 이용하여 사용자를 증명하는 원리로 로그인하게 됩니다.

아래는 ssh 접속 과정을 나타낸 시퀀스 다이어그램 입니다.

3. SSH 공개키 접속 방법

3.1 및 3.2는 공개키를 이용한 SSH 접속 방법을 설명하기 앞서 기본적으로 알아야할 사전지식입니다.

3.1 SSH 클라이언트 (사용자)

클라이언트 키 쌍
- ssh-keygen 명령어를 이용하여 공개키 및 개인키 생성
- 키 쌍을 생성하게 되면 기본적으로 아래 경로에 생성됨
  - ~/.ssh/id_rsa (개인키)
  - ~/.ssh/id_ras.pub (공개키)
- 서버의 authorized_keys 파일에 생성된 사용자 공개키를 제공해야 함
~/.ssh/known_hosts 파일
- 사용자가 처음 서버에 로그인 할 때, 연결을 진행하면 서버의 공개키가 해당 파일에 기록됨
  3.2 SSH 서버 (호스트)
서버 키 쌍
- 서버에서 openssh-server를 설치하는 과정에 자동 생성
  - /etc/ssh/ssh_host_ras_key (개인키)
  - /etc/ssh/ssh_host_ras_key.pub (공개키)
- 클라이언트가 서버에 처음 연결 시도 시 해당 공개키를 클라이언트에게 제공. 클라이언트는 known_hosts 파일에 서버의 공개키를 저장
~/.ssh/authorized_keys 파일
- 해당 파일에 로그인할 클라이언트의 공개키가 기록되어있어야 함

3.3 SSH 공개키 접속

3.3.1 클라이언트 키 쌍 생성

아래 명령어를 이용하여 RSA 알고리즘 키 쌍 생성
$ ssh-keygen -t rsa
별 다른 설정이 필요하지 않으므로, 엔터를 계속 누르면 현재 로그인되어있는 사용자의 홈디렉토리 .ssh 폴더 밑에 키 쌍이 생성 됨

3.3.2 공개키 전송

리눅스계열에서는 공개키를 복사하는 명령어 ssh-copy-id 를 사용
- $ ssh-copy-id USER@remote-host
- 예) $ ssh-copy-id lee@192.168.0.15
- -i 옵션을 사용하지 않으면, 현재 로그인 되어있는 계정의 .ssh/id_rsa.pub 파일을 전송 (기본값)
- 공개키 파일이 다른 경로에 있다면 -i 옵션을 이용하여 별도의 경로를 지정해야 함
  - $ ssh-copy-id -i /home/test/key/key.pub lee@192.168.0.15
윈도우에서는 ssh와 cat을 이용한 명령어 조합을 이용
- type $env:공개키경로 | ssh USER@remote-host "cat >> .ssh/authorized_keys"
- 예) type $env:C:\Users\LDB.ssh\id_rsa.pub | ssh lee@192.168.0.15 "cat >> .ssh/authorized_keys"

3.3.3 로그인

공개키 방식으로 SSH 접속 시 -i 옵션 생략 시, 아래 경로에 있는 개인키로 접속을 시도
- 윈도우: USER_NAME\.ssh\id_rsa
- 리눅스: USER_NAME/.ssh/id_rsa
만약 개인키의 위치가 다르거나 AWS의 pem 파일인 경우 -i 옵션 이용
- $ssh -i KEY_PATH\key.pem USER@remote-host
- $ssh -i KEY_PATH\id_rsa USER@remote-host

3.3.4 키 파일 권한 문제 (Permissions are too open)

개인키를 windows <-> linux간 FTP로 복사하다가 발생하는 권한 문제입니다.
ssh에 사용되는 각 종 파일들 (설정파일,공개키,개인키 등)은 보안적인 이슈로 인해 아래 사진과 같이 권한이 정해져있습니다.

위 사진을 보면 Mandatory Permission 이라고 정해진 권한이 있는데, 개인키 파일과 설정파일은 꼭 600으로 설정이 되어있어야 한다는 뜻입니다. (600은 소유자만 읽고 쓸 수 있는 권한)
만약 600이 아니라면 chmod 명령어를 통해 권한을 수정하면 됩니다.

만약 윈도우에서 발생했다면 해당 파일에 대한 상속 권한을 비활성화 시키고, 현재 윈도우 계정만 개인키 파일에 접근할 수 있도록 설정을 변경해줍니다.

자세한 방법은 윈도우10 SSH 접속시 PEM 파일 퍼미션 에러 해결방법 글을 참고하시면 됩니다.

[참고]

[Mysql/MariaDB] 밀리세컨드 저장이 안되는 문제

평범한 개발자... — Sun, 28 Mar 2021 13:11:29 +0900

밀리세컨드 저장이 안되는 근본적인 이유는 하나입니다.

"데이터베이스 버전 문제"

MySQL은 5.6.4부터,

MariaDB는 5.3부터

밀리세컨드/마이크로세컨드 단위를 지원합니다.

MariaDB의 경우, 호환성을 위해 10.1.2 버전부터 MySQL과 동일한 포맷 및 변수를 사용합니다.
mariadb.com/kb/en/server-system-variables/#mysql56_temporal_format

그러나, 버전이 지원함에도 불구하고 Spring boot 설정 문제로 인하여 밀리세컨드 저장이 안되는 경우가 있습니다.

이 경우에는, DB에 직접 쿼리를 실행하면 밀리세컨드가 저장 되지만,

JDBC를 통해서 저장하게되면 밀리세컨드가 저장되지 않는 아주 난감한 상황게 빠지게 되죠.

저장이 안되는 이유는 크게 2가지 입니다.

1. Dialect 설정 문제

잘못된 Dialect 설정으로 해당 기능을 사용하지 못하는 경우입니다.

예를들어, 데이터베이스 버전이 MySQL 8.0인데,

아래와 같이 MySQL5(5.5)로 설정하게되면 ORM에서 MySQL 5.5 버전을 기준으로 쿼리를 작성하게 됩니다.

spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialect

5.5버전에서는 마이크로세컨드를 지원하지 않으니 당연히 저장이 안되겠죠

자세한 내용은 아래 글을 참고하시면 됩니다.

[Spring boot] JPA Dialect(방언) 설정에 관하여

2. Connector 문제

데이터베이스는 MariaDB인데 MySQL Connector 사용하는 경우입니다.

(MySQL을 사용하는데 MariaDB Connector를 사용하는 경우는 아마 없겠죠..?)

MySQL과 MariaDB는 서로 호환이 되기 때문에 Connector를 크게 신경쓰지 않는 분들이 계실텐데요.

실제로 동작시켜보면 MySQL Connector를 사용할 경우, MariaDB 10.4.7을 MySQL 5.5.5로 감지하게 됩니다.

3. 결론

초급 혹은 신입개발자가 혼자서 초기 프로젝트를 구성하다보면,

Spring boot 설정파일이나 pom 또는 gradle 코드를 구글링하여 그대로 쓰는 경우가 있습니다.

설정이나 라이브러리는 하나하나 공부해서 직접 설정하는것이 실력향상에 도움도되고

오류가 발생했을때 원인을 찾는것이 훨씬 쉬워질 것입니다.

[참고]

issues.alfresco.com/jira/browse/MNT-17613

mariadb.com/kb/en/changes-improvements-in-mariadb-53/

mariadb.com/kb/en/microseconds-in-mariadb/

2020년 회고

평범한 개발자... — Sun, 10 Jan 2021 18:53:55 +0900

2dongdong.tistory.com/14?category=730705

2020년 목표

훈련소 다녀오고 여행갔다가 한 주 보내니 벌써 1월의 절반이 지나갔네요. 2020년도 목표를 따로 다이어리에 적긴 했지만, 블로그를 제대로 운영해보고자 글을 남겨봅니다. 남들 처럼 이쁘게 꾸

2dongdong.tistory.com

1. 운동

주 3회를 목표로 하였으며, 코로나 때문에 중간중간 끊기긴 했지만 지금 까지 꾸준히 진행 중이다.

재작년 12월 훈련소를 다녀온 이후,

골격근량 3.7kg 증가, 체지방량 4.7kg 감소했다.

되돌아보면 몸이 정말 많이 바뀌었다. 왜소했던게 큰 컴플랙스 였는데, 덩치가 많이 커져서 뿌듯하다.

2. 공부

- 영어회화는 완전한 실패로 끝났다. 처음 한, 두달 열심히 했지만 동기부여가 생기지 않아 깔끔하게 포기!

- 책읽기는 정말 자기전 하루에 한 장 읽는 것을 목표로 해도, 실천하지 못했다. 자기전에 자꾸 유튜브를 보게된다.

정말 유튜브를 삭제해야하나 싶다! 아으~~!

- 카메라 공부는 틈틈히 했다. 책을 사서 참고 해보기도 하고, 인터넷 글도 많이 읽었다. 2019년도에는 카메라 공부, 2020년도는 사진찍는법에 대해 많이 배웠다. 연말에는 영상찍는법을 벼락치기로 배워서 여자친구 언니 결혼식 영상을 찍고 편집하여 하나의 작품을 만들었다.

- 개발공부는 대략적으로 정리하면 아래와 같다.

. Vue.js 입문책: 완독

. 스프링부트와 AWS로 혼자 구현하는 웹 서비스: 완독

. RealMySQL: 필요한 부분만 읽는 중. index, partitioning을 주로 읽은 듯

. 마이크로서비스 아키텍처 구축: 완독

. 디자인패턴 책 3권: 1권으로는 이해가안가서 3권을 돌려보는 중, 대부분 읽긴 했지만 정리가 필요함..

위 공부를 통해 얻은 것.

1. Vue.js로 만든 간단한 웹서비스 (Front 보단 Back에 더 집중..)

. gitlab+ aws S3 + CodeDeploy를 연동해서 테스트 자동화, 배포 자동화 시스템을 구현했다.

. 도메인을 적용(무료)하였다.

2. 테이블 만들 때, 쿼리를 작성할 때 인덱스부터 고민한다.

3. 대용량처리를 어떻게 하는지 구체적으로 알고 싶었는데, 가려운 부분이 해소됐다.

. 실제로 구축해보고 싶은데, 마땅한 자원이 없다... 로컬로 가상머신으로 해야하나?

4. 처음부터 디자인패턴을 설계해서 코드 짜는 레벨은 아니지만, 코드를 짜다가 반복되는 부분이 생기거나, 나중에 기능이 추가되거나 유지보수를 고려해서 기존코드의 수정을 최소화 시키는 방법 또는 아에 독립적으로 분리시켜서 어떻게 패턴화 할지 많이 고민하게 된다.

3. 경험한 것 혹은 이룬 것

1. 꾸준히 운동하기

2. 공부하기 (꾸준히는 안함)

3. 눈썹 문신 (진작 했어야함)

4. 국내여행 (전주,공주,삼남길,청주,춘천,소요산)

5. 아울렛 쇼핑에 눈을 떴다. (다신 백화점 안간다...)

6. 턱걸이 최대 10개 가능

7. 커플링을 맞췄다.

8. 다양한 데이트 (사격, 스포츠몬스터, 출사, 비건데이트, 커플여행)

9. 결혼식 영상 찍기+편집 (뜻깊은 선물을 줘서 기분이 좋다)

10. 카러플 레전드 티어 달성?

11. 후지필름 카메라를 사고 인생샷을 많이 찍은 것.

4. 시원하게! 플랙스하게 지른 것

1. 후지필름 카메라: 2020년 한 해의 추억을 이 카메라로 담았다. 너무 잘 샀다.

2. 자브라 75T: QCY시리즈 쓰다가 큰맘먹고 지른 것. 정말 잘 쓰고있음.

3. 갤럭시S20: 말도안되는 스팩에 정말 잘 만든 핸드폰... 많이 안팔려서 안타까울 뿐

4. 지오지아 롱패딩: 따뜻하고 옷 자체는 좋은데, 백화점에서 산게 가장 큰 실수. 너무 비싸게주고 샀다.

5. 아울렛 가서 산것들: 정장, 코트, 바지, 셔츠.. 등등 눈돌아가서 막 산거같다. 합해서 100만원 나온듯.

6. 2070 Super + 32인치 144hz QHD 모니터: 게임하는데 몰입감이 한 층 더해졌다.

7. 마샬 스탠모어2 스피커: 음질 좋고 파워 빵빵한 스피커. 직구로 싸게 샀다. 음악감상 + 인테리어용

나름 평소에 알뜰하게 살고있다고 생각했는데, 되돌아보니 전혀 아니네

그래도 딱 필요한 거 샀다고 생각한다...

5. 결론

바쁘게 산 날도 있고, 무기력하게 보낸 날도 많았다. 무기력하게 보낸 날은 시간을 그냥 흘려보낸거같아 많이 후회했다.

그래도 되돌아보니 열심히 살았었구나 생각한다.

다만, 블로그에 글을 많이 못쓴게 흠이다.

메모장에 써야할 글과 주제를 수십개 적어놨는데, 줄지않고 늘어나기만한다. 마이너스 요소임..

2020년을 점수로 평가하자면 10점 만점에 7점!

2021년도를 완벽하게 보낼거라 생각하지 않는다. 딱 1점만 올려서 8점의 해를 보내보자.

[Vue.js] - HTML5 WebSocket(웹 소켓) 소스코드 및 데모 사이트

평범한 개발자... — Fri, 13 Nov 2020 16:43:03 +0900

웹소켓 클라이언트가 필요해서 bootstrap+vuejs로 간단하게 만들어봤습니다.

jQuery에서 vuejs로 넘어오면서 익숙하지 않은게 힘들었는데, 조금씩 익숙해지니 개발하는데 훨씬 편리함을 느끼네요.

웹소켓 또한 이벤트핸들러와 메소드로 간단히 만들 수 있습니다.

핵심 부분은 아래가 전부입니다.

  ...
  //소켓 연결
  this.socket = new WebSocket(this.address)
  ...
  this.socket.onopen = 소켓 연결 이벤트 헨들러
  ...
  this.socket.onerror = 소켓 에러 이벤트 헨들러
  ...
  this.socket.onmessage = 데이터 수신 이벤트 헨들러
  ...
  this.socket.onclose = 소켓 해제 이벤트 헨들러
  ...
  // 소켓 데이터 전송
  this.socket.send("메시지") 
  ...
  // 소켓 종료
  this.socket.close()

아래는 자바 스크립트 전체 소스코드 입니다.

  methods: {
    connect () {
      if (this.socket === undefined || this.socket.readyState === 3) {
        this.socket = new WebSocket(this.address)
        this.socket.onopen = () => {
          this.logs.push({ type: 'INFO', msg: 'CONNECTED' })
          this.disabled = false
        }
        this.socket.onerror = () => {
          this.logs.push({ type: 'ERROR', msg: 'ERROR:' })
        }
        this.socket.onmessage = ({ data }) => {
          this.logs.push({ type: 'RECV', msg: 'RECV:' + data })
        }
        this.socket.onclose = (msg) => {
          this.logs.push({ type: 'ERROR', msg: 'Closed (Code: ' + msg.code + ', Message: ' + msg.reason + ')' })
        }
      }
    },
    sendMessage () {
      if (this.selected === 'plain') {
        this.logs.push({ type: 'SENT', msg: 'SENT:' + this.message })
        this.socket.send(this.message)
      } else if (this.selected === 'json') {
        this.logs.push({ type: 'SENT', msg: 'SENT:' + JSON.stringify(this.json) })
        this.socket.send(JSON.stringify(this.json))
      }
    },
    disconnect () {
      if (this.socket.readyState === 1) {
        this.socket.close()
        this.logs.push({ type: 'INFO', msg: 'DISCONNECTED' })
        this.disabled = true
      }
    }
  }

Vue를 포함한 모든 소스 코드는 깃허브에 있습니다.

깃허브 주소: github.com/lehdqlsl/vue-websocket-client

실제 서버에 올려서 구동시킨 데모 화면입니다. 아래 URL에 누르면 해당 웹페이지로 접속 가능합니다.

접속주소: vue-websocket.ga/

그리고 Location 부분에 아래 에코서버에 연결하여 간단하게 테스트해 볼 수 있습니다.

wss://echo.websocket.org

즐겁게 살고 싶은 개발자

어느날 오픈코드에서 클로드가 갑자기 막혀서 간단한 오픈소스를 만들어봤다

클로드 인증이 실패하다

버그가 아니라 정책 문제

npm으로 받은 인증 도구를 믿어도 될까

토큰을 옮기는 작은 스크립트

마무리

[핫딜트래커] 핫딜 제목 데이터로 파인튜닝 해보기

파인튜닝을 적용한 서비스를 만들어보고 싶었다

핫딜 제목에서 어떤 값을 봐야 할까

핫딜 정답 데이터셋 만들기

모델 정하기

파인튜닝 결과

결론

[Spring boot] @Transactional은 어떻게 동작할까? (+ 트랜잭션이 동작하지 않는 이유)

1. Spring AOP와 동적 프록시의 동작 원리

2. @Transactional 어노테이션 적용 원리

3. 클래스 내부 호출 시 트랜잭션이 동작하지 않는 이유

4. 그 외 자주 놓치는 함정

5. 해결 방법

마무리

REST, RESTful, REST API에 대한 오해와 진실

서론

대표적인 오해 6가지

1. REST는 웹 서비스 API 정의를 위한 아키텍처이다.

2. REST는 HTTP 표준을 기반으로 구현한다.

3. REST는 HTTP 프로토콜을 활용하는 아키텍처이다.

HTTP와 REST의 관계?

4. REST와 RESTful은 같은 말이다.

5. REST API는 HTTP 메서드를 사용하여 검색, 생성, 업데이트, 삭제한다.

6. /customer 또는 /cusrtomer/1과 같은 리소스에 대해 알기쉬운 URL를 정의하는 것이 REST 제약 조건에 해당하며 RESTful API라 부른다.

REST를 이해하기 어려운 이유

1. REST라는 단어가 남용되고 있다.

2. REST라는 단어를 직역하여 이해하려고 한다.

REST는 왜 만들어졌는가?

REST를 꼭 알아야할까?

진정한 REST API에 대해 알고싶다.

결론

GitLab CI/CD + SSH 공개키를 이용한 자동배포

Start

Process

1. 클라이언트 키쌍 생성

2. Gitlab Variables 등록

3. 배포 서버에 공개키 등록

4. 스크립트 작성

5. 자동 배포 확인

MariaDB에는 'innodb buffer pool instances' 변수 설정이 없다...?

multiple buffer pool을 사용 이유

지라 이슈 제기

다시 한번 정리 (뇌피셜로 분석한 제 생각입니다...)

2년간 이어진 기나긴 테스트...

MySQL의 innodb buffer pool instances는?

나의 생각

SSH 공개키 인증을 사용하여 접속하기

1. 공개키 암호화란?

2. SSH 공개키 접속

3. SSH 공개키 접속 방법

3.1 SSH 클라이언트 (사용자)

3.2 SSH 서버 (호스트)

3.3 SSH 공개키 접속

3.3.1 클라이언트 키 쌍 생성

3.3.2 공개키 전송

3.3.3 로그인

3.3.4 키 파일 권한 문제 (Permissions are too open)

[Mysql/MariaDB] 밀리세컨드 저장이 안되는 문제

1. Dialect 설정 문제

2. Connector 문제

3. 결론

2020년 회고

1. 운동

2. 공부

3. 경험한 것 혹은 이룬 것

4. 시원하게! 플랙스하게 지른 것

[Vue.js] - HTML5 WebSocket(웹 소켓) 소스코드 및 데모 사이트