통합 피드
모든 커뮤니티의 최신 글을 모아봅니다.
중년개발자
@loxo
#12 - JPA 실무 가이드 1부 — 입문자 기준 쉽게 이해하기(30분 JPA 정복)
JPA 실무 가이드 1부 — 입문자 기준 쉽게 이해하기 SQL을 직접 작성하던 시절, 개발자는 항상 DB 구조에 맞춰 움직여야 했습니다. 그래서 JPA는 복잡하고 어려운 기술처럼 느껴질 수 있습니다. 하지만 실무에서 제대로 사용해보면, JPA는 객체 중심으로 개발을 단순화해주는 도구입니다. 이 문서는 불필요한 이론을 걷어내고, 실무에 꼭 필요한 핵심만 정리한 30분 요약 가이드입니다. JPA가 무엇인가요? JPA (Java Persistence API, 자바 영속성 API)는 자바 객체(Object)를 데이터베이스(DB)에 저장하고 관리하는 기술입니다. 조금 더 쉽게 말하면, 우리가 객체(Object)를 만들고 값을 바꾸면 JPA가 알아서 SQL을 만들어 DB에 반영해 줍니다. 여기서 중요한 개념이 바로 ORM (Object Relational Mapping, 객체-관계 매핑) 입니다. 객체(Object)와 테이블(Table)을 연결해주는 기술이 ORM입니다. 엔티티(Entity,
0
0
1
중년개발자
@loxo
#11 - Service가 반드시 해야 할 일
Service 실무 가이드: Service가 반드시 해야 할 일 (Standard Responsibilities) Spring Boot 4 Service Layer Standard Guide "Service에만 넣어야 하는 로직과 그 이유" Service의 정의: 비즈니스 규칙의 최종 심판 Service는 단순히 Repository를 호출하는 패스스루(Pass-through)가 아닙니다. Service의 존재 이유는 "상태를 변경하기 전, 모든 규칙을 검사하고 확정 짓는 것"입니다. 트랜잭션의 시작과 끝을 책임진다 (@Transactional) Spring Boot에서 트랜잭션 경계는 Service 메서드입니다. Controller나 Repository가 아닙니다. ✅ 표준 패턴: 읽기 전용과 쓰기 분리 java @Service @RequiredArgsConstructor @Transactional(readOnly = true) // 기본은 읽기 전용 (성능 최적화) public
0
0
7
중년개발자
@loxo
#10 - Service에서 하지 말아야 할 것들
Service 실무 가이드: Service에서 하지 말아야 할 것들 Spring Boot에서 Service 레이어를 순수하게 유지하기 위한 "금지 목록" Web 기술을 Service로 가져오지 않는다 Service는 어떤 환경(Web, Console, Batch)에서도 실행 가능해야 한다. Controller가 처리해야 할 HTTP 관련 객체가 Service 메서드 파라미터나 반환값에 등장하면 안 된다. ❌ 절대 금지: Web 객체 의존 java // BAD public void createOrder(HttpServletRequest req) { ... } public ResponseEntity<Order> getOrder(Long id) { ... } ✅ 올바른 방법: POJO(Plain Old Java Object) 사용 java // GOOD public void createOrder(Long userId, CreateOrderCommand command) { ... }
0
0
7
중년개발자
@loxo
mole - 두더지가 당신의 mac 을 clean 합니다. - 강추 mo~~mo~~
Mole (macOS Cleaner) — 장점 요약 한 줄 요약 Mole는 CleanMyMac 대안으로 쓸 수 있는 오픈소스 macOS CLI 정리 도구로, 무료·투명·강력한 정리 성능이 핵심 강점이다. ✅ 주요 장점 완전 무료 & 오픈소스 구독·결제 없음 광고, 추적, 백그라운드 서비스 없음 GitHub에서 코드 전부 공개 → 신뢰도 높음 All-in-One 단일 바이너리 다음 도구들을 하나로 통합한 느낌: CleanMyMac AppCleaner DaisyDisk iStat Menus ➡ 정리, 삭제, 분석, 모니터링을 한 번에 처리 Dry-run 기반의 안전한 정리 실제 삭제 전 dry-run으로 제거 대상 미리 확인 어떤 파일이 지워지는지 100% 투명 화이트리스트로 보호 폴더 지정 가능 ➡ “모르고 중요한 파일 지워질까 봐” 불안 없음 개발자 친화적 Xcode 캐시 / DerivedData npm, yarn, Python, Docker 잔여 파일 로그·빌드 캐시 대량 정리

0
0
8
중년개발자
@loxo
#9 - Controller 코딩 레벨 에서 순서 및 설명
Controller 실무 가이드 Spring Boot에서 Controller를 실제로 어떻게 작성하는가 어노테이션, 클래스, Response 설계를 코딩 순서대로 정리한다 이 문서의 목적 Controller를 설명할 때 가장 많이 나오는 말은 이것이다. “Controller는 얇아야 한다” 하지만 실무에서는 곧바로 이런 질문이 나온다. 그래서 뭐를 쓰고, 뭐를 어디까지 작성하라는 건데? 이 문서는: Controller에서 반드시 알아야 할 클래스와 어노테이션을 실제 코딩 순서에 맞게 설명하고 특히 Response 설계를 실무 기준으로 정리한다. Controller 작성 순서 (이 순서를 지키면 흔들리지 않는다) Controller는 보통 아래 순서로 작성한다. Controller 선언 Request 매핑 정의 요청 데이터 바인딩 검증 선언 Service 위임 Response 반환 이 순서를 기준으로 하나씩 정리한다. Controller 선언에 필요한 어노테이션
0
0
9
중년개발자
@loxo
#8 - Controller에서 하면 안 되는 것들 — Spring Boot 실무 설계 기준과 코드
Controller를 입구로 설계한다는 것 Spring Boot에서 Controller를 가장 실무적으로 사용하는 기준 "의심한다"는 명제를 코드로 구현하는 방법 이 문서를 읽는 기준 1️⃣ “의심한다”는 명제를 추상적으로 말하지 않는다 의심을 구체적인 책임 목록으로 풀어낸다 → 해석 / 검증 / 자격 확인 반대로 의심과 무관한 행동을 금지 목록으로 명확히 제시한다 이렇게 하면 “Controller에서 뭘 하면 안 되는지”가 감각이 아니라 기준이 된다. 2️⃣ 가장 많이 헷갈리는 질문을 정면으로 다룬다 현장에서 반복되는 질문은 늘 같다. Service를 여러 번 호출해도 되는가? Service에서 받은 데이터를 Controller에서 편집해도 되는가? 3️⃣ Spring Boot의 ‘사상’에 맞게 정렬한다 Spring이 기대하는 Controller는 다음이 아니다. orchestration 계층 ❌ 판단 계층 ❌ 가공 계층 ❌ → 입구 계층이다. 그래서 이 문서는 마지막에 이

0
0
9
중년개발자
@loxo
똑똑해지려 하지 마라, 지워라: 일론 머스크의 생산성 알고리즘
🚀 일론 머스크의 알고리즘 — 바보 인덱스로 본 생산성 폭발 이야기 일론 머스크의 “알고리즘”은 사실 복잡한 공식이 아니라, 사람들이 괜히 어렵게 만드는 걸 끝까지 의심하는 습관에 가깝다. 아래는 머스크식 사고를 바보 인덱스 + 알고리즘 한 장 요약으로, 그리고 실제로 생산성이 어떻게 미친 듯이 올라갔는지 웃긴 일화로 풀어본다. 1️⃣ 일론 머스크 알고리즘 한 줄 요약 “왜 이걸 하고 있지?”를 끝까지 묻고, 바보 같은 이유면 전부 지워라. 자동화는 제일 마지막이다.” 이게 전부다. 2️⃣ 머스크의 5단계 알고리즘 (핵심) ① 요구사항을 의심하라 “이 요구사항, 누가 만든 거지? 천재인가, 아니면 관성인가?” 모든 요구사항은 틀렸다고 가정 “원래 이렇게 해요”는 즉시 의심 ② 가능한 한 많이 삭제하라 “삭제했는데 문제가 없다? 그럼 원래 필요 없었던 거다.” If you’re not deleting at least 10% of what you add, you’re not

0
0
8
중년개발자
@loxo
Next.js 개발 필수 설정 2가지 - AGENTS.md , MCP 설정
Next.js 에서 개발에 필수 설정 2가지 Using AI Agents with Next.js DevTools MCP AGENTS.md 설정 (압축 AGETNTS.md) 프로젝트 터미널에서 실행 bash npx @next/codemod@canary agents-md DevTools MCP json { "mcpServers": { "next-devtools": { "command": "npx", "args": ["-y", "next-devtools-mcp@latest"] } } } 보너스 Context7 MCP 사용법: prompt 이후 use context7 입력 json { "mcpServers": { "context7": { "serverUrl": "https://mcp.context7.com/mcp", "headers": { "CONTEXT7APIKEY": "무료발급" } } } }
0
0
12
중년개발자
@loxo
빗썸, 업비트, 바이낸스 시세 정보를 Stream Deck 에서 만나 보세요 - Kimchi Ticker
📊 빗썸 · 업비트 · 바이낸스 시세를 Stream Deck에서 바로 확인하세요 코인 시세 확인하느라 브라우저 열고 → 앱 켜고 → 새로고침 누르다 보니 정작 차트 보는 시간보다 한숨 쉬는 시간이 더 많아졌습니다. 그래서 그냥 만들었습니다. Stream Deck에서 바로 코인 시세를 보자고요. 🔥 Kimchi Ticker 빗썸 · 업비트 · 바이낸스 실시간 시세 플러그인 오늘 퍼블리시한 Stream Deck 전용 무료 플러그인입니다. 한국에서 실제로 많이 쓰는 거래소 기준으로: 빗썸 (KRW) 업비트 (KRW) 바이낸스 (USDT) 시세를 실시간으로 Stream Deck 버튼 위에서 바로 확인할 수 있습니다. 🤷 왜 만들었냐면요 솔직히 말하면 개인적으로 필요해서 만들었습니다. 요즘 코인 시장? 말 안 해도 아시죠. 차트 열면 기분만 더 상하고, 그래도 안 볼 수는 없고… 🥲 “어차피 볼 거면 최소한 덜 귀찮게라도 보자” 이게 시작이었습니다. 👍 이런 분들한테 특히 잘

0
0
12
중년개발자
@loxo
#11 - EXPLAIN ANALYZE(큰 테이블이 작은 테이블을 만났을 때, DB는 어떻게 행동할까?)
실행 계획을 이해하는 감각 만들기 이제부터는 EXPLAIN ANALYZE를 왜 이렇게 나왔는지 납득하는 단계로 들어간다. 숫자와 용어를 외우는 게 아니라, 데이터 크기와 접근 방식의 이야기로 이해하면 훨씬 편하다. Seq Scan이 선택되는 진짜 이유 Seq Scan은 말 그대로 테이블을 처음부터 끝까지 읽는 방식이다. 많이들 이렇게 생각한다. Seq Scan = 인덱스를 못 써서 생긴 문제 하지만 PostgreSQL 입장에서는 전혀 다르다. PostgreSQL이 Seq Scan을 고르는 논리 DB는 항상 이렇게 계산한다. 인덱스를 타면 인덱스 페이지 읽고 테이블 페이지 다시 읽고 랜덤 I/O가 많이 발생 Seq Scan을 하면 테이블 페이지를 순서대로 쭉 읽음 디스크, 캐시 입장에서 매우 효율적 그래서: 전체 row 중 많은 비율을 읽어야 한다면 인덱스가 있어도 Seq Scan이 더 빠를 수 있다 실생활 비유 책에서 단어 하나 찾기: 단어가 2~3개만 필요 → 목차(인덱스) 사용

0
0
14
중년개발자
@loxo
Codex Mac을 써보고 든 생각
충격보다는 역할 구분 이번에 OpenAI에서 Codex Mac 버전이 나왔다. 출시 타이밍도 참 버라이어티하다. 유튜브에서는 온갖 과장된 썸네일이 쏟아지고, 어제는 또 주식시장에서 IT 기업들이 대폭 흔들렸다. “AI가 다 바꾼다”, “개발자는 끝났다” 같은 말들도 다시 고개를 든다. 그래서 나도 호기심 반, 의심 반으로 Codex를 직접 설치해봤다. 그런데 솔직히 말하면, 처음 써봤을 때는 ‘그래서 뭐가 그렇게 대단한 거지?’라는 느낌이 먼저 들었다. 이미 IDE에는 잘 만든 extension들이 있고, 개발 흐름만 놓고 보면 Antigravity(안티그라비티) 쪽이 훨씬 손에 착 붙는다. 코드 작성, 수정, 흐름 끊기지 않는 개발 경험만 보면 여전히 실행자는 안티그라비티다. Codex는 좀 다르다. 이건 “IDE에 붙은 도구”라기보다는, 로컬을 건들 수 있는 채팅창을 가진 ChatGPT에 가깝다. 써보면서 느낀 미묘한 거리감 Codex는 분명히 막강하다. 파일을 읽고, 구조를

0
1
13
중년개발자
@loxo
#10 - EXPLAIN ANALYZE 제대로 읽기
PostgreSQL 성능 문제의 90%는 여기서 시작해서 여기서 끝난다 EXPLAIN ANALYZE는 처음 보면 외계어처럼 느껴지기 쉽다. 하지만 관점을 조금만 바꾸면, 이건 DB가 직접 써주는 성적표에 가깝다. 이 글에서는 "모든 숫자를 이해하려 하지 말고, 무엇을 먼저 봐야 하는지"에 집중한다. sql QUERY PLAN | -----------------------------------------------------------------------------------------------------------------------------------------------------------------+ Nested Loop (cost=0.42..14.33 rows=69 width=563) (actual time=0.087..0.198 rows=52 loops=1) | -> Index Only Scan using boards_pkey on boards b

0
0
15