Posts on 42Class

21/01/18

Mon, 18 Jan 2021 00:00:00 +0000

Meetnote 개발 회고 — 로컬 회의록 자동화 Obsidian 플러그인

Sun, 05 Apr 2026 00:00:00 +0000

왜 만들었나

회의가 끝나고 나면 항상 같은 고민이 반복됐다. “누가 뭐라고 했더라?” 회의록을 작성하자니 회의에 집중이 안 되고, 녹음만 해두면 다시 듣기가 귀찮다. 기존 SaaS 서비스들은 비용도 문제지만, 회의 내용이 외부 서버로 나가는 것 자체가 부담스러웠다.

그리고 결정적인 이유가 하나 더 있었다. 지금 모든 업무 문서를 Obsidian에서 마크다운으로 관리하고 있는데, 이건 AX(AI Transformation) 관점에서 매우 중요한 선택이었다. 마크다운은 AI 에이전트에게 전달하기 가장 좋은 포맷이다. 회의록도 마크다운으로 생성되면 별도 서비스에서 옮기는 번거로움 없이, 다른 업무 문서들과 함께 한 곳에서 관리할 수 있다. 에이전트가 과거 회의 맥락을 참조하고, 액션 아이템을 추적하고, 관련 문서를 연결하는 것까지 자연스럽게 이어진다.

그래서 만들었다. 완전히 로컬에서 동작하는 회의록 자동화 도구. 비용 0원, 오프라인 가능, GPU 가속. 그리고 결과물은 Obsidian Vault 안의 마크다운 파일.

무엇을 만들었나

Meetnote는 Obsidian 플러그인 + Python 백엔드로 구성된 로컬 회의록 자동화 도구다.

핵심 기능:

실시간 음성 인식 — Whisper large-v3-turbo, 5초 단위 스트리밍
화자 분리 — pyannote 3.1, GPU 자동 감지
화자 식별 — 임베딩 DB 기반, 회의할수록 정확도 향상
AI 요약 — Claude CLI / Ollama, 액션 아이템 자동 생성
이메일 발송 — 참석자별 회의록 HTML 메일
암호화 — AES 암호화, 자동 삭제, 감사 로그

Apple Silicon 기준 60분 회의를 약 5분 만에 처리한다.

기술 스택

영역	기술
Plugin	TypeScript, Obsidian API, Web Audio API
Backend	Python, FastAPI, WebSocket
STT	mlx-whisper (Apple Silicon), faster-whisper (CPU)
화자 분리	pyannote.audio 3.1
화자 임베딩	wespeaker-voxceleb-resnet34-LM
AI 요약	Claude CLI, Ollama
배포	Docker, GitHub Actions, GHCR

아키텍처

┌─────────────┐ WebSocket (PCM 16kHz) ┌──────────────┐
│ Obsidian │ ──────────────────────────────▶│ FastAPI │
│ Plugin │◀────────────── JSON ──────────│ Backend │
│ (TS) │ │ (Python) │
└─────────────┘ └──────┬───────┘
 │
 ┌─────────────────┼─────────────────┐
 │ │ │
 ┌─────▼─────┐ ┌──────▼──────┐ ┌──────▼──────┐
 │ Whisper │ │ pyannote │ │ Speaker │
 │ STT │ │ Diarizer │ │ Embedding │
 └───────────┘ └─────────────┘ └─────────────┘

Plugin이 Web Audio API로 마이크 음성을 캡처해서 5초 단위로 WebSocket을 통해 바이너리 전송한다. 백엔드는 Whisper로 실시간 전사하고, 녹음 종료 후 pyannote로 화자 분리를 수행한다. 전사 결과와 화자 분리 결과를 시간 기반으로 병합해서 “누가 무슨 말을 했는지” 최종 결과를 만든다.

개발 과정에서 마주친 문제들

1. MLX vs faster-whisper — 플랫폼별 분기

Apple Silicon에서는 MLX가 압도적으로 빠르지만, Linux/CUDA 환경에서는 faster-whisper가 낫다. 처음에는 하나로 통일하려 했지만, 성능 차이가 너무 커서 런타임에 플랫폼을 감지하고 분기하는 방식을 택했다.

2. 화자 분리와 전사 결과 병합

Whisper와 pyannote는 독립적으로 동작한다. 둘의 타임스탬프가 정확히 일치하지 않기 때문에, 시간 구간의 최대 겹침(temporal overlap)을 기준으로 화자를 배정했다. 같은 화자의 연속 발언은 5초 이내 간격이면 하나로 합친다.

3. 환각(Hallucination) 필터링

Whisper는 가끔 무음 구간에서 환각을 일으킨다. no_speech_prob과 compression_ratio를 기준으로 품질 필터를 넣어 해결했다. LLM 기반 전사 보정도 추가했는데, 고유명사나 전문 용어의 정확도가 체감될 정도로 올라갔다.

4. 동시 녹음 세션 처리

Transcriber와 Diarizer는 GPU 메모리를 많이 쓰기 때문에 싱글톤으로 관리한다. 하지만 여러 사용자가 동시에 녹음할 수 있어야 하므로, WebSocket 세션별로 격리하되 공유 리소스는 Lock으로 보호하는 구조로 만들었다.

5. Docker 빌드 최적화

처음 Docker 빌드는 46분이 걸렸다. PyTorch + pyannote 의존성이 무거웠기 때문이다. base 이미지와 app 이미지를 분리하고, GitHub Actions에서 base 이미지를 캐싱하는 방식으로 빌드 시간을 3분까지 줄였다. 이후 추가 최적화로 1분대까지 단축했다.

누적 학습 — 화자 임베딩 DB

가장 만족스러운 기능이다. 회의에서 새로운 화자가 감지되면 임베딩 벡터를 자동 저장한다. 다음 회의에서 코사인 유사도(임계값 0.70)로 기존 화자와 매칭한다. 회의를 할수록 화자 인식 정확도가 올라가는 구조다.

타임라인

집중적으로 작업한 건 약 일주일. 115개 커밋, 혼자서 기획부터 배포까지.

Phase 0 — MVP: 실시간 전사, 화자 분리, 요약, 암호화, RAG 검색
Phase 1 — 안정화: 버그 수정, 환각 필터, 품질 최적화
Phase 2 — UX: 사이드 패널, 화자 관리 UI, 이메일, 원클릭 설치
Phase 3 — 배포: Docker, GHA 캐싱, 온보딩 모달, 보안 강화

돌아보며

일주일이라는 짧은 기간이었지만, “내가 직접 쓸 도구"를 만드는 과정이라 몰입도가 높았다. 특히 화자 임베딩 DB의 누적 학습은 쓸수록 똑똑해지는 느낌이 있어서 뿌듯하다.

아쉬운 점은 Windows 네이티브 지원이 아직 Docker(WSL2) 의존이라는 것. 그리고 CPU 환경에서는 60분 회의 처리에 40분이 걸려서 실용성이 떨어진다.

다음 목표는 웹 기반 대시보드와 팀 단위 화자 DB 공유 기능이다.

Meetnote — 로컬 회의록 자동화

Obsidian plugin for local meeting transcription, speaker diarization, and AI summarization

GitHub에서 보기 →

21/06/25

Fri, 25 Jun 2021 00:00:00 +0000

Choose Your Own Adventure 모험, 나의 선택 - Hernan Bas

Sun, 23 May 2021 00:00:00 +0000

SPACE K SEOUL 2021.05.22

BTS RM도 다녀갔다는 Hernan Bas 전시 ㅎㅎ
강서구민은 할인도 되네요.

헤르난 바스 인터뷰
SPACE K

왜 저기까지 올라가서 뛰어 내려오는지는 알수가 없네...

RDP(Mac to Windows)환경에서 Mac OS환경과 동일한 단축키 사용하기

Sat, 22 May 2021 00:00:00 +0000

개발은 Mac OS에서 하는데 운영 데이터 조회는 Windows에서 해야 하네…

운영을 하다 보면 DB에 접근해서 데이터 확인을 해야 할 일이 빈번한데 DB에 접근 가능한 환경이 윈도우 기반인 경우가 있습니다.
개발 작업은 주로 Mac에서 진행을 하고 있고 어쩔 수 없이 RDP를 이용해 원격접속을 이용합니다.
저 같은 경우 SQL작성 시에 주로 사용하는 프로그램은 DBeaver입니다.
DBeaver는 Mac OS버전과 Windows버전이 있고 자주 사용하는 단축키는 아래 표와 같이 미묘하게 다릅니다.
그래서 두 가지 환경을 수시로 전환하면서 쿼리를 짜다보면 생산성이 떨어지고 짜증이 치밀어 오릅니다.

Command	Mac OS	Windows	RDP(Mac to Windows)
Home	⌘ + ←	Fn(Win) + ←	Fn(Mac) + ←
End	⌘ + →	Fn(Win) + →	Fn(Mac) + →
Page Up	⌘ + ↑	Fn(Win) + ↑	Fn(Mac) + ↑
Page Down	⌘ + ↓	Fn(Win) + ↓	Fn(Mac) + ↓
Copy	⌘ + C	Ctrl + C	⌘ + C
Paste	⌘ + V	Ctrl + V	⌘ + V
Cut	⌘ + X	Ctrl + X	⌘ + X
Undo	⌘ + Z	Ctrl + Z	⌘ + Z
한영전환	Right ⌘	한/영	Right ⌥

Mac OS 환경의 단축키와 RDP(Mac to Windows) 환경의 단축키를 맞추고 싶다!!

RDP(Mac to Windows) 에서 한참동안 작업하다가 단축키가 손에 익은 상태에서 Mac OS로 돌아오면 버벅대고 Mac OS에서 한 동안 로컬 개발하다가 RDP(Mac to Windows) 에서 운영하면 또 버벅대고.. 하여간 환경 전환 때마다 계속 버벅이게 됩니다.

도저히 이렇게는 못해먹겠다 싶어 방법을 찾아보았습니다.
단축키를 한 쪽 환경에 맞춰야 겠다고 생각했고, 자주 사용하는 Mac OS환경에 단축키를 맞추기로 했습니다.

먼저 한/영 전환부터

저는 Mac OS에서 한영전환을 우측 **Right ⌘**키를 사용하고 있습니다.
지금은 Mac을 사용하고 있지만 예전에 오랫동안 Windows를 사용 했었습니다.
스페이스 바로 우측 옆에 키가 한영전환으로 사용되는 거에 너무 익숙합니다.
그래서 맥을 사용 하면서도 처음부터 그렇게 매핑해두고 사용하고 있습니다.
딱히 Mac을 사용할 때 우측 **Right ⌘**키를 사용하는 경우가 거의 없기도 하구요.

하지만 RDP(Mac to Windows) 에서는 한영전환이 **Right ⌥**키로 매핑됩니다.
바로 한 칸 차이 지만 실제 몰두 해서 타이핑 할 때 요 한칸 차이 땜에 엄청 버벅이고 있더군요.
그래서 Karabiner를 이용해 RDP전용 Profile을 하나 만들고 해당 Profile에선 **Right ⌘**키와 **Right ⌥**키를 서로 스위칭 했습니다.

Karabiner Profile 추가

한영전환 Key Remapping

한영전환 변경 후 Key Mapping 상태

Command	Mac OS	Windows	RDP(Mac to Windows)	Karabiner RDP Profile
Home	⌘ + ←	Fn(Win) + ←	Fn(Mac) + ←
End	⌘ + →	Fn(Win) + →	Fn(Mac) + →
Page Up	⌘ + ↑	Fn(Win) + ↑	Fn(Mac) + ↑
Page Down	⌘ + ↓	Fn(Win) + ↓	Fn(Mac) + ↓
Copy	⌘ + C	Ctrl + C	⌘ + C
Paste	⌘ + V	Ctrl + V	⌘ + V
Cut	⌘ + X	Ctrl + X	⌘ + X
Undo	⌘ + Z	Ctrl + Z	⌘ + Z
한영전환	Right ⌘	한/영	Right ⌥	Right ⌘

RDP Client tool 옵션의 한계 그리고 Fn(Mac)키와 ⌘키를 스위칭

Mac을 사용하면서 Copy,Paste 등은 항상 ⌘+C,⌘+V를 사용합니다.
RDP Client에서도 이 부분을 잘 알고 있어서인지, Client tool에서 옵션으로 제공합니다.

RDP Client 설정 (참고로 RDP(Mac to Windows) 에서 **⌘**키는 Windows Key로 인식합니다.)

하지만 아쉽게도 ⌘ + 방향키 조합으로 Home,End,Page Up,Page Down을 사용하는 부분까지는 지원되지 않습니다.
애초에 목적은 RDP(Mac to Windows) 에서도 Mac OS와 완전히 동일한 단축키 구성을 맞추는 것입니다.
그래서 Fn(Mac) 키와 Left ⌘ 키를 스위칭 했습니다.

Fn(Mac) 과 Left ⌘ 스위칭

karabiner Complex Modification을 이용하여 Copy,Paste 등 자주 사용하는 단축키만 Remapping

Fn(Mac) 키와 Left ⌘ 키가 스위칭 됨에 따라 Fn(Mac)+C,Fn(Mac)+V로 바뀌어 버린 Copy,Paste를 karabiner Complex Modification기능을 이용해 ⌘+C,⌘+V 로 재설정 해주었습니다.
스위칭을 하지 않고 ⌘+방향키 를 Home,End,Page Up,Page Down으로 매핑해줄수도 있습니다.
하지만 ⌘+방향키조합은 이미 Mac OS에서 사용하는 단축키라서 스위칭 후 Fn키에 매핑하는 방식으로 진행했습니다.
설정방법은 아래 링크와 캡처화면 및 코드 참고하시어 진행하시면 됩니다.

karabiner에서 제공하는 문서입니다. complex modifications example

이미 저장소엔 여러 사람들이 올려 둔 karabiner Complex Modification Rule이 있습니다. Rule Repostory

Rule은 Json형태로 구성됩니다. Rule Generator

아래 코드는 제가 작성해서 적용한 cut, copy, paste, undo Rule의 code입니다.

{
 "title": "RDP cut, copy, paste, undo",
 "rules": [
 {
 "description": "Fn+x > Cmd+x",
 "manipulators": [
 {
 "from": {
 "key_code": "x",
 "modifiers": {
 "mandatory": [
 "fn"
 ]
 }
 },
 "to": [
 {
 "key_code": "x",
 "modifiers": [
 "command"
 ]
 }
 ],
 "type": "basic"
 }
 ]
 },
 {
 "description": "Fn+c > Cmd+c",
 "manipulators": [
 {
 "from": {
 "key_code": "c",
 "modifiers": {
 "mandatory": [
 "fn"
 ]
 }
 },
 "to": [
 {
 "key_code": "c",
 "modifiers": [
 "command"
 ]
 }
 ],
 "type": "basic"
 }
 ]
 },
 {
 "description": "Fn+v > Cmd+v",
 "manipulators": [
 {
 "from": {
 "key_code": "v",
 "modifiers": {
 "mandatory": [
 "fn"
 ]
 }
 },
 "to": [
 {
 "key_code": "v",
 "modifiers": [
 "command"
 ]
 }
 ],
 "type": "basic"
 }
 ]
 },
 {
 "description": "Fn+z > Cmd+z",
 "manipulators": [
 {
 "type": "basic",
 "from": {
 "modifiers": {
 "mandatory": [
 "fn"
 ]
 },
 "key_code": "z"
 },
 "to": [
 {
 "key_code": "z",
 "modifiers": [
 "command"
 ]
 }
 ]
 }
 ]
 }
 ]
}

이 코드는 아래 링크로 Generator에 바로 접근할 수도 있습니다.
RDP cut, copy, paste, undo

생성한 룰은 Install하여 Karabiner에 적용합니다.

설정 후 Mac OS 와 RDP Profile모든 단축키 구성이 같아졌습니다.

Command	Mac OS	Windows	RDP(Mac to Windows)	Karabiner RDP Profile
Home	⌘ + ←	Fn(Win) + ←	Fn(Mac) + ←	⌘ + ←
End	⌘ + →	Fn(Win) + →	Fn(Mac) + →	⌘ + →
Page Up	⌘ + ↑	Fn(Win) + ↑	Fn(Mac) + ↑	⌘ + ↑
Page Down	⌘ + ↓	Fn(Win) + ↓	Fn(Mac) + ↓	⌘ + ↓
Copy	⌘ + C	Ctrl + C	⌘ + C	⌘ + C
Paste	⌘ + V	Ctrl + V	⌘ + V	⌘ + V
Cut	⌘ + X	Ctrl + X	⌘ + X	⌘ + X
Undo	⌘ + Z	Ctrl + Z	⌘ + Z	⌘ + Z
한영전환	Right ⌘	한/영	Right ⌥	Right ⌘

이제 모든 설정이 끝났습니다.
앞으로는 원격접속시에는 Karabiner Profile을 RDP Profile로 변경해서 사용하면 Mac OS와 완전히 동일한 단축키 구성으로 사용할 수 있습니다.

karabiner Profile 전환의 불편함

그런데 여기까지 진행하고 보니 Karabiner의 Profile 전환이 불편해졌습니다.
항상 상단바의 아이콘을 클릭하여 Profile을 전환 해야 했습니다.

항상 상단 바로 이동해서 Profile을 변경하는 건 너무 불편하다.

상단 바에 Profile명은 기본으로 노출 되지 않습니다.(옵션을 변경해야 합니다.)

Profile 전환도 Complex Modification을 이용하여 단축키 지정이 가능합니다.
Karabiner cli명령어를 이용하여 프로필 전환 단축키를 만들 수 있었습니다.
아래는 제가 Profile 전환에 사용한 Rule입니다.

Switch profile (RDP -> Default)

{
 "title": "Change Profile",
 "rules": [
 {
 "description": "Press left-shift+caps_lock to enable default profile",
 "manipulators": [
 {
 "type": "basic",
 "from": {
 "modifiers": {
 "mandatory": [
 "left_shift"
 ]
 },
 "key_code": "caps_lock"
 },
 "to": [
 {
 "shell_command": "'/Library/Application Support/org.pqrs/Karabiner-Elements/bin/karabiner_cli' --select-profile 'Default'"
 }
 ]
 }
 ]
 }
 ]
}

Switch profile (RDP -> Default)

Switch profile (Default -> RDP)

{
 "title": "Change Profile",
 "rules": [
 {
 "description": "Press left-shift+caps_lock to enable RDP profile",
 "manipulators": [
 {
 "type": "basic",
 "from": {
 "modifiers": {
 "mandatory": [
 "left_shift"
 ]
 },
 "key_code": "caps_lock"
 },
 "to": [
 {
 "shell_command": "'/Library/Application Support/org.pqrs/Karabiner-Elements/bin/karabiner_cli' --select-profile 'RDP'"
 }
 ]
 }
 ]
 }
 ]
}

Switch profile (Default -> RDP)

여기까지 해서 **RDP(Mac to Windows)**환경에서 Mac OS환경과 완전히 동일하게 단축키를 맞추는 작업을 마쳤습니다.
저와 비슷한 상황을 겪고 계신 분이 있으시면 도움이 되었으면 좋겠습니다.

Spring DATA JPA in MySQL에서 Pessimistic Lock(비관적 락) 처리

Wed, 03 Feb 2021 00:00:00 +0000

WMS운영 중 비정상적인 락 처리 현상이 있어 확인한 결과 공유드립니다. Spring DATA JPA in MySQL에서 Pessimistic Lock(비관적 락) 처리

락 어논테이션으로 처리 : @Lock(LockModeType.PESSIMISTIC_WRITE)
쓰기,읽기 모두 lock를 거는 방식이지만 실제로는 읽기에 대핸 lock이 걸리지 않음
읽기도 lock을 걸려면, 해당 row에 접근하는 select 쿼리에 모두 for update구문을 걸어줘야 함(@Lock(LockModeType.PESSIMISTIC_WRITE))
해당 락은 row level lock이지만 mysql innoDB의 락 처리 방식은 인덱싱 되지 않은 조건으로 선별 된 row에 대해선 row level로 락은 잡지 못함
mysql innoDB는 인덱싱 범위에 대해서 락을 잡는 방식으로 인덱싱 되지 않은 조건으로 선별 된 select결과는 row가 아닌 테이블이 락이 걸리는 현상이 발생됨
락을 걸어야 하는 데이터 셋의 검색조건은 인덱싱된 컬럼을 기준으로 잡아야 함
JPA에서 lock scope범위에 따라 릴레이션 된 모델들도 함께 락이 잡히게 됨
대상 테이블만 락의 범위로 잡으려면 scope를 지정해줘야 함
락 범위 어논테이션으로 처리 : @QueryHints(value = {@QueryHint(name = “javax.persistence.lock.scope”, value = “NORMAL”)})

JPA N+1튜닝과정에서 선언한 배치 사이즈와 다르게 쿼리 분할 되어 수행되는 이유

Mon, 01 Feb 2021 00:00:00 +0000

JDBC preparedstatement의 캐싱 방식

먼저 이 현상을 설명하려면 JDBC의 preparedstatement의 캐싱 방식을 알아야 합니다.
preparedstatement는 in절이 들어가는 select 쿼리에 대해 각 경우를 모두 캐싱합니다.

# 데이터가 1개 들어올 때 : where xxx in (?)
# 데이터가 2개 들어올 때 : where xxx in (?,?)
# 데이터가 n개 들어올 때 : where xxx in (?,?, ...)

hibernate의 batch_size에 의한 캐싱 방식

위의 방식으로 캐시되는 경우 데이터가 많아질수록 많은 케이스를 캐싱해야 해서 성능에 문제가 발생합니다.
그래서 하이버네이트는 최적화를 위해 캐싱케이스를 줄이는 방식으로 수행됩니다.
줄이는 방식은 프로젝트에 선언 된 기본배치사이즈 (hibernate.default_batch_fetch_size: 100) 를 기준으로 절반씩 나눠가면서 캐싱합니다.
그리고 자주사용할 것으로 예상되는 1~10 사이는 모두 캐싱 하게됩니다.
in절 항목값을 100으로 잡을 때, 기존 preparedstatement 방식에 의하면 총 100개의 케이스를 캐싱해두게 됩니다.
하이버네이트의 방식으로 하게 되면 14개로 줄어듭니다.
(1,2,3,4,5,6,7,8,9,10,12, 25,50,100)

N+1이슈가 발생한 쿼리가 있고 총 데이터가 83건이면 83번의 동일한 쿼리가 나가는 상황일겁니다.
현상 튜닝을 위해 hibernate.default_batch_fetch_size: 100 으로 설정 후 조회합니다.
예상으로는 쿼리는 한번 나가고 in절 항목이 83개가 들어간 쿼리를 기대합니다.
하지만 실제로는 캐싱된 케이스에 의해 아래와 같이 총 3번의 동일한 쿼리가 나가게 됩니다.

in절 항목이 50으로 캐싱된 쿼리 한 번
in절 항목이 25로 캐싱된 쿼리 한 번
in절 항목이 8으로 캐싱된 쿼리 한 번

83개 항목이 분리 요청 된 실제 예

 select
 product0_.id as id1_38_0_,
 product0_.created_by as created_2_38_0_,
 product0_.created_date as created_3_38_0_,
 product0_.last_modified_by as last_mod4_38_0_,
 product0_.last_modified_date as last_mod5_38_0_,
 product0_.code as code6_38_0_,
 product0_.name as name7_38_0_,
 product0_.product_group_code as product_8_38_0_,
 product0_.product_type as product_9_38_0_
 from
 product product0_
 where
 product0_.id in (
 ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
 )
2020-08-07 17:33:30,948 DEBUG [XNIO-1 task-1] SQL:
 select
 product0_.id as id1_38_0_,
 product0_.created_by as created_2_38_0_,
 product0_.created_date as created_3_38_0_,
 product0_.last_modified_by as last_mod4_38_0_,
 product0_.last_modified_date as last_mod5_38_0_,
 product0_.code as code6_38_0_,
 product0_.name as name7_38_0_,
 product0_.product_group_code as product_8_38_0_,
 product0_.product_type as product_9_38_0_
 from
 product product0_
 where
 product0_.id in (
 ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
 )
2020-08-07 17:33:30,969 DEBUG [XNIO-1 task-1] SQL:
 select
 product0_.id as id1_38_0_,
 product0_.created_by as created_2_38_0_,
 product0_.created_date as created_3_38_0_,
 product0_.last_modified_by as last_mod4_38_0_,
 product0_.last_modified_date as last_mod5_38_0_,
 product0_.code as code6_38_0_,
 product0_.name as name7_38_0_,
 product0_.product_group_code as product_8_38_0_,
 product0_.product_type as product_9_38_0_
 from
 product product0_
 where
 product0_.id in (
 ?, ?, ?, ?, ?, ?, ?, ?
 )

최적화 전략

위와 같이 하이버네이트는 최적화 전략으로 수행됩니다.
3번의 캐싱된 쿼리가 수행되는 것은 정상적인 부분이며 하이버네이트에서 권장하는 기본전략입니다.
참고로, 선언한 (hibernate.default_batch_fetch_size: 100 ) 사이즈 만큼 in절 항목을 발생시키고 싶다면 설정파일에 hibernate.batch_fetch_style: dynamic을 추가하시면 됩니다.
하지만 이 방식은 캐싱되지 않은 케이스로 쿼리가 수행되므로 권장하지 않는 방식이라고 합니다.

21/01/11

Mon, 11 Jan 2021 00:00:00 +0000

아직 앱이 익숙하지 않네.

21/01/04

Mon, 04 Jan 2021 00:00:00 +0000

에어4 구매기념~

Mac에서 WSL로 자유롭게 접근하기(ssh와 Port Forwarding)

Mon, 03 Aug 2020 00:00:00 +0000

WSL에서 SSH 서버 세팅하기

wsl을 설치하면 기본적으로 ssh서버가 세팅되어 있습니다.
하지만 왜 인지는 모르겠으나 wsl에 기본으로 세팅되어 있는 ssh서버는 정상적으로 작동 하지 않습니다.
기본 세팅되어 있는 ssh서버는 제거하고 갈끔하게 새로 세팅하는 것이 좋을 것 같습니다.
일단 제 WSL을 Ubuntu 18.04 배포판이라 apt를 사용하여 설치하겠습니다.

apt 패키지 매니저부터 update & upgrade하고 진행하겠습니다.

sudo apt-get update && sudo apt-get upgrade -y

기본으로 세팅되어 있는 ssh 서버를 제거합니다.

sudo apt-get purge openssh-server

ssh 서버를 재설치 합니다.

sudo apt-get install openssh-server

Windows에서 WSL로 Port Forwarding

작성 중

WSL SSH서버 / Port Forwarding script 실행 스케쥴러 등록

Windows10 PC도 여전히 개발작업에 사용 중이고 수시로 온/오프 하는 랩탑이라서 매번 포트포워딩 잡아주고 ssh서버 실행해주는게 번거로웠습니다.

bash.exe -c "sudo service ssh start"
powershell.exe -ExecutionPolicy Bypass -File D:\wsl2-network.ps1

wsl2-network.ps1 : 파일안에 $ports 변수에 포워딩할 포트 지정

$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';

if( $found ){
 $remoteport = $matches[0];
} else{
 echo "The Script Exited, the ip address of WSL 2 cannot be found";
 exit;
}

#[Ports]

#All the ports you want to forward separated by coma
$ports=@(80,443,10000,3000,5000,22);


#[Static ip]
#You can change the addr to your ip config to listen to a specific address
$addr='0.0.0.0';
$ports_a = $ports -join ",";


#Remove Firewall Exception Rules
iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' ";

#adding Exception Rules for inbound and outbound Rules
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $ports_a -Action Allow -Protocol TCP";
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalPort $ports_a -Action Allow -Protocol TCP";

for( $i = 0; $i -lt $ports.length; $i++ ){
 $port = $ports[$i];
 iex "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr";
 iex "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteport";
}

SSH 서버 세팅하기

WSL환경에서 맥으로 작업환경 옮기면서 SSH접속이 되면 편할 거 같아서 세팅한건데 맥에서 wsl로 ssh 접근 필요하신 분은 사용하시면 될 듯 합니다.

링크(https://www.tuwlab.com/ece/29302) 참조하셔서 wsl에 ssh 서버 설치하시고 첨부 한 zip파일 받으셔서 route.bat 파일 시작프로그램에 넣으시면 됩니다.

route.bat : 파일안에 파워셀스크립트 파일 경로 자신의 경로대로 변경 필요

Docker 개발환경 성능 비교

Sat, 13 Apr 2019 00:00:00 +0000

도커 성능 테스트라고는 하지만 각 개발환경 호스트의 파일시스템에 따른 도커볼륨 I/O 속도 테스트 인 것 같다.

WSL + Docker Desktop for Windows

eeee

aaaa

이 환경에선 초반에 버그도 많았고, 사용하면서 많은 인내심이 필요했다. (작년쯤엔 wsl2테스트 해보려고 윈도우 인사이더 프로그램으로 진행하다가 O/S도 한번 날려 먹고….)

사용하다 보니 점차 안정화 되고, Visual Studio Code에서 원격개발 Extension도 나오면서 속도가 좀 아쉽긴 했어도 그럭저럭 개발환경으로서 사용할만 했다.

WSL2 + Docker Desktop for Windows

Pages가 다른 블로그 플랫폼 보다 편한 것 같아서 마음에 든다. 다른 사람들도 같이 많이 사용했으면 좋겠다는 생각이 든다.

YFM에서 정의한 제목을 이중 괄호 구문으로 본문에 추가할 수 있다. 이 글의 제목은 {{ page.title }}이고 마지막으로 수정된 시간은 {{ page.last_modified_at }}이다.

Mac OS + Docker Desktop for Mac

Mac OS + Docker Desktop for Mac(edge)