Typhoon

Hello World

Tue, 14 Apr 2026 00:00:00 GMT

I work as a Global Engineer at Metsakuur, a Korean security company specializing in facial recognition. My role covers backend, infrastructure, and ML — whatever the situation calls for.

Tech Stack

Area	Tech
Machine Learning	PyTorch, TensorFlow, YOLO, Paddle OCR, Tesseract
Backend	Spring Boot, Go, FastAPI, Express, Ruby on Rails
Frontend	Svelte (preferred), React
Languages	Python, Go, Java, TypeScript, Rust, Dart
Infrastructure	On-premise, Proxmox, Ubuntu, Arch Linux, Docker, LXC

What I'll write about

Posts come from problems I've actually run into.

Software Engineering — design decisions, tradeoffs, debugging logs
ML / AI — practical Vision AI work
Infrastructure — homeserver, on-premise, Linux
Global engineering — multilingual systems, working with international clients

I write in both Korean and English.

GitHub · jungwooshin.97@gmail.com

Hello World — 블로그를 시작하며

Tue, 14 Apr 2026 00:00:00 GMT

Metsakuur에서 글로벌 엔지니어로 일하고 있다.

Metsakuur는 얼굴인식 보안 솔루션을 다루는 한국 소재 회사다. 국내 업무와 해외 고객사 요구사항에 맞는 시스템을 만들고, 사내 개발에서 글로벌 표준 준수도 담당한다. 특정 포지션에 묶이지 않고 백엔드, 인프라, ML까지 상황에 따라 커버한다.

Tech Stack

분야	기술
Machine Learning	PyTorch, TensorFlow, YOLO, Paddle OCR, Tesseract
Backend	Spring Boot, Go, FastAPI, Express, Ruby on Rails
Frontend	Svelte (선호), React
Languages	Python, Go, Java, TypeScript, Rust, Dart
Infrastructure	On-premise, Proxmox, Ubuntu, Arch Linux, Docker, LXC

이 블로그에서 다룰 것들

주로 실제로 부딪힌 문제들을 쓴다.

Software Engineering — 설계 결정, 트레이드오프, 삽질 기록
ML / AI — 실무 Vision AI 적용 경험
Infrastructure — 홈서버, 온프레미스, 리눅스
Global engineering — 다국어 환경, 해외 고객사 협업

포스트는 한국어와 영어 둘 다 올릴 예정이다.

GitHub · jungwooshin.97@gmail.com

Proxmox에서 LXC로 홈서버 서비스 분리하기

Tue, 14 Apr 2026 00:00:00 GMT

서비스를 하나씩 VM으로 돌리다 보면 메모리가 금방 바닥난다. 서비스 5개에 VM 5개, RAM은 32GB인데 여유가 없다. LXC로 바꾸고 나서 같은 서버에 서비스를 두 배 이상 올렸다.

VM 대신 LXC를 쓰는 이유

VM은 게스트 OS 전체를 띄운다. 커널도 따로, 메모리도 따로. Ubuntu VM 하나에 최소 512MB는 잡아야 한다.

LXC는 호스트 커널을 공유한다. 컨테이너 안에서는 독립된 환경처럼 보이지만 실제로는 호스트의 커널 위에서 돌아간다. RAM 사용량이 훨씬 적다. Nginx만 돌리는 컨테이너라면 50-100MB면 충분하다.

격리 수준은 VM보다 낮다. 커널을 공유하기 때문에 커널 취약점은 컨테이너를 통해 호스트에 영향을 줄 수 있다. 홈서버에서 내부 서비스만 돌린다면 이 정도 트레이드오프는 감수할 수 있다.

Proxmox에서 LXC 만들기

먼저 컨테이너 템플릿을 받는다. Proxmox 웹 UI에서 Datacenter → node → local → CT Templates에서 다운로드하거나, 터미널에서:

pveam update
pveam available | grep ubuntu
pveam download local ubuntu-24.04-standard_24.04-2_amd64.tar.zst

컨테이너 생성은 웹 UI 우상단 Create CT 버튼. 설정할 것들:

CT ID: 100번대부터. VM ID와 겹치지 않게.
Hostname: 서비스 이름으로. nginx, gitea, grafana 식으로.
Template: 방금 받은 걸로.
Disk: 서비스에 따라 8-20GB면 대부분 충분하다.
CPU / Memory: 처음엔 넉넉하게 주고 모니터링 보면서 줄인다.
Network: vmbr0 브릿지에 연결하고 고정 IP 할당.

네트워크 설정

컨테이너마다 고정 IP를 주는 게 관리하기 편하다. Ubuntu 컨테이너라면 Netplan으로:

# /etc/netplan/10-lxc.yaml
network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.110/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

서비스별로 IP 대역을 정해두면 나중에 보기 편하다:

192.168.1.100-109 — 인프라 (Nginx, DNS)
192.168.1.110-119 — 모니터링 (Grafana, Prometheus)
192.168.1.120-129 — 앱 서비스

호스트 디렉토리 마운트

데이터는 컨테이너 밖에 두는 게 낫다. 컨테이너를 날려도 데이터는 남는다.

웹 UI → 컨테이너 → Resources → Add → Mount Point로 bind mount 추가하거나, /etc/pve/lxc/[CTID].conf에 직접:

mp0: /data/gitea,mp=/opt/gitea/data

컨테이너 재시작하면 적용된다. 호스트의 /data/gitea가 컨테이너 안 /opt/gitea/data로 연결된다.

실제 구성

현재 홈서버에서 돌리는 구성:

CT ID	서비스	RAM	역할
100	nginx	128MB	리버스 프록시
101	postgres	512MB	공용 DB
110	grafana	256MB	모니터링 대시보드
111	prometheus	256MB	메트릭 수집
120	gitea	256MB	Git 서버
121	nextcloud	512MB	파일 서버

전부 합쳐도 RAM 2GB 언저리다. VM으로 했다면 최소 8-10GB는 썼을 거다.

서비스가 죽거나 업데이트할 때 해당 컨테이너만 재시작하면 된다. 다른 서비스에 영향이 없다. 이게 분리의 핵심이다.

LXC는 홈서버에서 서비스를 운영하는 가장 실용적인 방법이다. Docker도 좋지만 Proxmox를 이미 쓰고 있다면 LXC가 더 자연스럽다. 관리 포인트도 적고 오버헤드도 낮다.

JPA orphanRemoval — Remove from collection, delete from DB

Tue, 14 Apr 2026 00:00:00 GMT

Add orphanRemoval = true to a @OneToMany, and JPA will automatically issue a DELETE when you remove a child entity from the parent's collection.

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
private List<OrderItem> items = new ArrayList<>();

One line — order.getItems().remove(item) — and the OrderItem is gone from the database on transaction commit. No explicit em.remove() needed.

orphanRemoval vs CascadeType.REMOVE

They sound similar but trigger on different events.

CascadeType.REMOVE fires when the parent entity is deleted:

em.remove(order); // → also deletes all its items

orphanRemoval fires when a child is removed from the parent's collection — even if the parent still exists:

order.getItems().remove(item); // → item deleted from DB, order stays

In practice, most relationships that need one need both. Using cascade = CascadeType.ALL covers the parent-deletion case while orphanRemoval = true handles collection removal.

How it works

JPA's dirty checking tracks changes to your collections within a persistence context. At flush time (before commit), it compares the current state of the collection to the snapshot taken when the entity was loaded. Any entity that disappeared from the collection is treated as an orphan and scheduled for deletion.

Gotchas

Don't share orphanRemoval children

orphanRemoval implies exclusive ownership. If another entity or relationship also references the same child, you'll get unexpected deletes. It's only safe when one parent fully owns the child's lifecycle.

Replacing the whole collection deletes everything

// Dangerous: all existing items become orphans → all deleted
order.setItems(newItems);

// Safe: mutate the existing collection
order.getItems().clear();
order.getItems().addAll(newItems);

Swapping the collection reference via setter marks every previous item as orphaned. If that's not what you want, always mutate in place.

Bidirectional relationships need both sides disconnected

item.setOrder(null);            // remove child's FK reference
order.getItems().remove(item);  // remove from parent's collection

Skipping either side can cause dirty checking to miss the change. The clean way is to encapsulate this in helper methods:

@Entity
public class Order {
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<OrderItem> items = new ArrayList<>();

    public void addItem(OrderItem item) {
        items.add(item);
        item.setOrder(this);
    }

    public void removeItem(OrderItem item) {
        items.remove(item);
        item.setOrder(null);
    }
}

Keep items private, expose only addItem and removeItem. External code never touches the collection directly.

Use orphanRemoval = true when the child's lifecycle is fully owned by the parent — if removing it from the collection means it should no longer exist, this is exactly the right tool.

JPA orphanRemoval — 컬렉션에서 제거하면 DB에서도 지워진다

Tue, 14 Apr 2026 00:00:00 GMT

@OneToMany에 orphanRemoval = true를 붙이면, 부모 컬렉션에서 자식 엔티티를 제거할 때 JPA가 자동으로 DELETE 쿼리를 날린다.

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
private List<OrderItem> items = new ArrayList<>();

order.getItems().remove(item) 한 줄이면 트랜잭션 커밋 시 해당 OrderItem이 DB에서 삭제된다.

CascadeType.REMOVE와 차이

헷갈리는 지점이다.

CascadeType.REMOVE: 부모 엔티티가 삭제될 때 자식도 같이 삭제된다.

// order를 삭제하면 → items도 삭제
em.remove(order);

orphanRemoval: 부모의 컬렉션에서 자식이 빠질 때 삭제된다. 부모가 살아있어도.

// order는 살아있고, items 컬렉션에서만 제거 → DB에서 삭제
order.getItems().remove(item);

둘을 같이 쓰면 두 경우 모두 처리된다. 대부분 같이 쓴다.

동작 원리

JPA dirty checking이 핵심이다. 트랜잭션 안에서 영속성 컨텍스트가 컬렉션 변화를 추적한다. 커밋 전 flush 시점에 컬렉션에서 빠진 엔티티를 감지하고 DELETE를 실행한다.

직접 em.remove(item)을 호출하지 않아도 된다. 컬렉션 조작만으로 충분하다.

주의할 점

자식 엔티티가 다른 곳에서도 참조되면 안 된다

orphanRemoval은 "이 자식은 이 부모만 소유한다"는 전제다. 같은 자식 엔티티를 다른 부모나 다른 연관관계가 참조하고 있으면 예상치 못한 삭제가 발생한다.

컬렉션 교체 시 주의

// 위험: 기존 컬렉션의 모든 항목이 orphan으로 처리돼 전부 삭제된다
order.setItems(newItems);

// 안전: 기존 컬렉션을 유지하며 수정
order.getItems().clear();
order.getItems().addAll(newItems);

setter로 컬렉션 통째로 교체하면 기존 항목이 전부 orphan으로 처리돼 삭제된다. 의도한 게 아니라면 컬렉션 내부를 수정하는 방식을 써야 한다.

양방향 연관관계에서 양쪽 모두 끊어야 한다

// 한쪽만 끊으면 dirty checking이 제대로 작동 안 할 수 있다
item.setOrder(null);            // 자식의 외래키 참조 제거
order.getItems().remove(item);  // 부모 컬렉션에서 제거

실수하기 쉬운 부분이라 보통 연관관계 편의 메서드로 묶어둔다.

실용적인 패턴

@Entity
public class Order {
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<OrderItem> items = new ArrayList<>();

    public void addItem(OrderItem item) {
        items.add(item);
        item.setOrder(this);
    }

    public void removeItem(OrderItem item) {
        items.remove(item);
        item.setOrder(null);
    }
}

addItem과 removeItem으로 양방향 연관관계를 한 곳에서 관리한다. 외부에서 직접 컬렉션을 건드리지 않게 한다.

orphanRemoval = true는 자식 엔티티의 생명주기를 부모에게 완전히 위임할 때 쓴다. 컬렉션에서 빼면 지워져야 하는 관계라면 붙여두면 된다.