통합 피드
모든 커뮤니티의 최신 글을 모아봅니다.
중년개발자
@loxo
조명 밖에서 빛나는 사람들
세상이 공평한가, 아니면 태어날 때 이미 많은 것이 결정되는가. 이 질문은 아마도 인류가 오래전부터 반복해온 질문일 것이다. 플라톤은 인간의 영혼과 재능이 선천적으로 다르게 주어진다고 보았고, 장자는 각자가 타고난 본성에 따라 자연스럽게 살아가는 것을 이야기했다. 반면 존 로크는 인간을 ‘백지(tabula rasa)’로 보며 환경과 경험의 힘을 강조했다. 결국 이 논쟁은 아직도 끝나지 않았다. 우리는 매일 상위 0.0001%의 사람들을 본다. TV와 유튜브, 뉴스는 끊임없이 유명 연예인과 스포츠 스타를 비춘다. 그들은 압도적인 재능, 외모, 운, 타이밍을 갖춘 것처럼 보인다. 하지만 화면에 비치지 않는 수많은 사람들 속에도, 노래를 놀라울 만큼 잘 부르지만 무대에 서지 않는 사람, 체육관 한쪽에서 묵묵히 운동을 즐기며 누구보다 정확한 폼을 가진 사람, 코드를 짜는 일상 속에서 조용히 아름다운 구조를 설계하는 개발자, 아이 한 명을 누구보다 따뜻하게 키워내는 부모, 동네에서 20년째
0
0
8
중년개발자
@loxo
#13 - JPA 실무 가이드 2부 - FK, PK 관리
JPA 실무 가이드 2부: 연관관계와 복합키의 모든 것 Spring Boot 4 & PostgreSQL 환경에서의 실용주의(Pragmatic) 고급 매핑 "왜 객체를 넣으면 ID가 저장될까요? 원리를 파헤칩니다." 연관관계의 핵심: "객체는 외래키(FK)를 모른다" 데이터베이스(DB) 세상에서는 "외래키(FK)"를 사용해 테이블을 연결합니다. 하지만 객체 세상에서는 "참조(Reference)"를 사용해 연결합니다. DB: SELECT FROM orders WHERE member_id = 1 Java: order.getMember() JPA의 역할은 이 패러다임의 불일치를 해결하는 것입니다. 우리가 order.setMember(member)라고 하면, JPA가 알아서 INSERT INTO orders (member_id) VALUES (1)로 통역해 줍니다. @ManyToOne 단방향: 실무 최강의 조합 가장 많이 쓰는 패턴은 "다대일(N:1) 단방향"입니다. 주문(Order)
0
0
17
중년개발자
@loxo
구름 위에서 생각한 존재란
하늘 위에서 본 구름은 하나의 덩어리처럼 보이지만, 자세히 보면 능선과 골짜기가 있고, 밀도 차이가 있으며, 끊임없이 형태를 바꾸고 있다. 그 장면은 하나의 질문을 던진다. 이 구름은 과연 ‘하나’인가, 아니면 수많은 조건이 잠시 만든 형상인가? 구름의 골짜기 — 관계 속에서 드러나는 형상 구름은 스스로 존재하는 실체가 아니다. 수증기, 온도, 기압, 바람이라는 조건이 잠시 맞물려 나타난 결과다. 구름은 독립적 존재가 아니라 조건들의 만남이 만든 잠정적 형상이다. 인간 역시 마찬가지일 수 있다. 개인의 성격과 삶은 고정된 실체라기보다 환경, 관계, 기억, 시대적 조건이 얽혀 형성된 하나의 패턴일지도 모른다. 뭉치고 흩어짐 — 무상(無常) 구름은 모였다가 흩어진다. 형태는 유지되는 듯 보이지만 실제로는 끊임없이 재배열된다. 산도 침식되고 이동한다. 감정도 잠시 머물다 사라진다. 관계도 생성과 소멸을 반복한다. 형태는 있지만, 영원한 형태는 없다. 우리가 ‘고정’이라 부르는 것은 변화
0
0
18
중년개발자
@loxo
Antigravity 100% 활용 가이드
Antigravity 100% 활용 가이드: AI Agent와 함께하는 코딩의 미래 "단순한 챗봇이 아닙니다. 당신의 주니어 개발자이자, 든든한 페어 프로그래밍 파트너입니다." Antigravity의 정체성 (Identity) 🚀 Agentic Mode란? 기존의 AI 코딩 도구(Copilot 등)가 단순히 "코드 자동 완성"이나 "질문 답변"에 그쳤다면, Antigravity는 "목표를 주면 스스로 계획하고, 실행하고, 검증하는" 자율형 에이전트(Autonomous Agent)입니다. 핵심 철학 (3단계 사고 과정): Planning (계획): 무작정 코드를 짜지 않습니다. 먼저 요구사항을 분석하고 implementation_plan.md를 만들어 당신과 합의합니다. Execution (실행): 합의된 계획에 따라 코드를 작성하고 수정합니다. Verification (검증): 작성한 코드가 제대로 동작하는지 테스트하고, 그 결과를 walkthrough.md로 보고합니다. 핵심
0
0
19
중년개발자
@loxo
65줄로 LLM 똑똑하게 만들기 - AI 가 스스로 판단하는것 막기
65줄로 LLM 똑똑하게 만들기 AI를 사용하다 보면 스스로 판단하여 임의로 실행하고, 다시 원복(Revert)하는 일이 다반사여서 항상 작업할 때마다 계속 버전 관리를 스스로 하고 있는데, 아래 글의 프롬프트를 보니 어느 정도는 예방주사가 되지 않을까 하여 소개합니다. 출처 CLAUDE.md Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed. Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment. Think Before Coding Don't assume. Don't hide confusion. Surface tradeoffs. Before implementing: State your assumptions explicitly.
0
0
16
중년개발자
@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
17
중년개발자
@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
22
중년개발자
@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
24
중년개발자
@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
23
중년개발자
@loxo
#9 - Controller 코딩 레벨 에서 순서 및 설명
Controller 실무 가이드 Spring Boot에서 Controller를 실제로 어떻게 작성하는가 어노테이션, 클래스, Response 설계를 코딩 순서대로 정리한다 이 문서의 목적 Controller를 설명할 때 가장 많이 나오는 말은 이것이다. “Controller는 얇아야 한다” 하지만 실무에서는 곧바로 이런 질문이 나온다. 그래서 뭐를 쓰고, 뭐를 어디까지 작성하라는 건데? 이 문서는: Controller에서 반드시 알아야 할 클래스와 어노테이션을 실제 코딩 순서에 맞게 설명하고 특히 Response 설계를 실무 기준으로 정리한다. Controller 작성 순서 (이 순서를 지키면 흔들리지 않는다) Controller는 보통 아래 순서로 작성한다. Controller 선언 Request 매핑 정의 요청 데이터 바인딩 검증 선언 Service 위임 Response 반환 이 순서를 기준으로 하나씩 정리한다. Controller 선언에 필요한 어노테이션
0
0
23
중년개발자
@loxo
#8 - Controller에서 하면 안 되는 것들 — Spring Boot 실무 설계 기준과 코드
Controller를 입구로 설계한다는 것 Spring Boot에서 Controller를 가장 실무적으로 사용하는 기준 "의심한다"는 명제를 코드로 구현하는 방법 이 문서를 읽는 기준 1️⃣ “의심한다”는 명제를 추상적으로 말하지 않는다 의심을 구체적인 책임 목록으로 풀어낸다 → 해석 / 검증 / 자격 확인 반대로 의심과 무관한 행동을 금지 목록으로 명확히 제시한다 이렇게 하면 “Controller에서 뭘 하면 안 되는지”가 감각이 아니라 기준이 된다. 2️⃣ 가장 많이 헷갈리는 질문을 정면으로 다룬다 현장에서 반복되는 질문은 늘 같다. Service를 여러 번 호출해도 되는가? Service에서 받은 데이터를 Controller에서 편집해도 되는가? 3️⃣ Spring Boot의 ‘사상’에 맞게 정렬한다 Spring이 기대하는 Controller는 다음이 아니다. orchestration 계층 ❌ 판단 계층 ❌ 가공 계층 ❌ → 입구 계층이다. 그래서 이 문서는 마지막에 이
0
0
20
중년개발자
@loxo
똑똑해지려 하지 마라, 지워라: 일론 머스크의 생산성 알고리즘
🚀 일론 머스크의 알고리즘 — 바보 인덱스로 본 생산성 폭발 이야기 일론 머스크의 “알고리즘”은 사실 복잡한 공식이 아니라, 사람들이 괜히 어렵게 만드는 걸 끝까지 의심하는 습관에 가깝다. 아래는 머스크식 사고를 바보 인덱스 + 알고리즘 한 장 요약으로, 그리고 실제로 생산성이 어떻게 미친 듯이 올라갔는지 웃긴 일화로 풀어본다. 1️⃣ 일론 머스크 알고리즘 한 줄 요약 “왜 이걸 하고 있지?”를 끝까지 묻고, 바보 같은 이유면 전부 지워라. 자동화는 제일 마지막이다.” 이게 전부다. 2️⃣ 머스크의 5단계 알고리즘 (핵심) ① 요구사항을 의심하라 “이 요구사항, 누가 만든 거지? 천재인가, 아니면 관성인가?” 모든 요구사항은 틀렸다고 가정 “원래 이렇게 해요”는 즉시 의심 ② 가능한 한 많이 삭제하라 “삭제했는데 문제가 없다? 그럼 원래 필요 없었던 거다.” If you’re not deleting at least 10% of what you add, you’re not
0
0
22