개발

이론으로 배운 Kubernetes와 실무 Kubernetes는 완전히 다른 생물이었습니다.삽질한 기록을 그대로 남깁니다.800시간짜리 클라우드 교육에서 Kubernetes를 배웠어요.kubectl get pods, kubectl apply -f, Deployment/S

문자열이 주어졌을 때, 대문자는 소문자로, 소문자는 대문자로 변환하는 문제이다.문자열의 각 문자를 하나씩 확인하면서,해당 문자가 대문자인지 소문자인지 판별한 후 변환하면 된다.자바에서는 문자열을 바로 수정할 수 없기 때문에,toCharArray()를 사용해 char 배

1970년대까지 각 제조사(IBM, DEC 등)가 자사 프로토콜만 사용해 서로 다른 장비끼리 통신이 불가능했다.이를 해결하기 위해 ISO(국제표준화기구)가 1984년 OSI(Open Systems Interconnection) 모델을 제정했다.목적 : 네트워크 통신을

Spring의 IoC와 DI IoC란? (Inversion of Control, 제어의 역전) 한 줄 정의 "객체의 생성과 관리를 개발자가 아닌 Spring 컨테이너가 담당한다" 문제 상황 먼저 보기 Spring 없이 순수 Java로 코드를 작성하면 이렇게 됩니다

1. 도입 — 왜 Spring MVC를 배우는가 > > Spring MVC는 단순한 웹 프레임워크가 아니라 > “요청 처리 표준 구조”를 제공한다. > > 실무에서는 > > 유지보수성 > 확장성 > 테스트 용이성 > 2. 전체 흐름 한 번에 잡기 (핵심 그림 1장) >

챕터 02 요약브라우저 (chat-model.html)↓ POST /ai/chat-modelAiController.java↓ @AutowiredAiService.java↓OpenAI APIHomeController → 어떤 HTML 페이지를 보여줄지 결정AiContro

챕터 03프롬프트란?(2. Prompt 클래스 구성요소(3. 메시지 역할 (Message Role)(4. 정적 텍스트 vs 동적 텍스트 (프롬프트 템플릿)(5. 프롬프트 엔지니어링 기법 6가지 (중요도 순)( - 01. 퓨-샷 프롬프트( - 02. 생각의 사슬

핵심 질문 하나로 전부 이해하기"로그인 상태를 누가 기억하나?"핵심 차이 — stateful vs stateless(2. 세션 방식 — 서버가 기억(3. 쿠키 vs 세션 스토리지 — 헷갈리는 개념 정리(4. JWT 방식 — 클라이언트가 증명서를 들고 다님(5. Reac

영속성 컨텍스트 = 엔티티를 저장하고 관리하는 “메모리 공간”JPA(“객체 ↔ DB 테이블 매핑”)는 Entity를 DB에서 조회할 때 영속성 컨텍스트(Persistence Context)라는 공간에 올려서 관리함EntityManager가 영속성 컨텍스트를 생성하고 관

LLM은 기본적으로 자유형식 텍스트를 반환함같은 질문을 해도 응답 형식이 매번 다를 수 있음자바 애플리케이션에서 이 텍스트를 파싱해서 사용하려면 매우 번거롭고 불안정함세 응답 모두 같은 질문에 대한 답이지만 형식이 전혀 다름Java 코드로 파싱하려면 응답 패턴마다 분기

먼저 ACID, Lock 이 뭐냐 -> (사용할 기술 선택 시 알아야하는 개념임.)트랜잭션 내 작업은 전부 성공 or 전부 실패, 중간 상태 없음내부 구현: Undo Log — 작업 전 상태를 로그에 기록, 실패 시 해당 로그로 롤백트랜잭션 전후로 DB가 정의된 규칙(

이번에는 Deploy-gate 프로젝트를 분석하면서 전체적인 구조와 프로젝트가 해결하려는 문제부터 파악해보았다.Deploy-gate는 CI/CD 환경에서 배포를 수행하기 전에 해당 사용자가 특정 Stack을 배포할 권한이 있는지 확인하고, 필요한 경우 다른 사용자의 승

오늘은 Deploy-gate의 핵심 기능 중 하나인 Claims 기반 인가를 살펴보았다.먼저 인증(Authentication)과 인가(Authorization)의 차이를 다시 정리했다.Deploy-gate에서 중요한 것은 두 번째인 인가다.Deployer Entity를

오늘은 ApprovalController를 중심으로 API 요청이 실제로 어디까지 전달되는지 분석했다.Controller에는 다음과 같은 API가 정의되어 있다.각 API의 역할을 나눠보면 다음과 같다./approval/check를 보면 Controller에서 모든 판

오늘은 /approval/check 요청 이후 실제 권한 판단을 수행하는 ApprovalCheckService를 분석했다.check() 메서드의 흐름은 다음과 같다.먼저 사용자 정보를 조회한다.사용자가 존재하지 않는 경우에는 DENIED를 반환한다.그다음 배포 대상 S

오늘은 Deploy-gate의 정책 구조를 분석하면서 객체지향의 상속과 다형성을 살펴봤다.기본 정책 클래스는 추상 클래스로 정의되어 있다.그리고 실제 정책은 이를 상속한다.승인이 필요하지 않은 정책이다.승인자가 한 명 필요한 정책이다.두 명의 승인이 필요한 정책이다.만

오늘은 여러 ApprovalPolicy 구현체 중 실제로 어떤 정책을 사용할지 결정하는 ApprovalPolicyResolver를 분석했다.프로젝트에는 다음과 같은 Policy 구현체가 존재한다.이 객체들은 모두 Spring의 @Component로 등록되어 있다.App

오늘은 실제 승인 요청이 어떻게 생성되고 상태가 변경되는지를 분석했다.승인 요청은 ApprovalRequest Entity로 관리된다.주요 상태는 다음과 같다.처음 승인 요청을 생성하면 PENDING 상태가 된다.승인자가 필요한 승인 수를 모두 충족하면가 된다.거부하면

오늘은 승인자가 실제로 승인하거나 거부하는 과정에서 사용되는 ApprovalVote를 분석했다.승인 요청 자체와 승인자의 투표 기록은 별도로 관리한다.즉,과를 분리해서 저장한다.ApprovalVote에는 다음과 같은 Unique Constraint가 존재한다.따라서 같

오늘은 Deploy-gate의 승인 이력 관리 구조를 분석했다.배포 승인 시스템에서는 현재 승인 여부만 아는 것으로 충분하지 않다.를 나중에 확인할 수 있어야 한다.프로젝트에서는 이를 위해 ApprovalLog Entity를 별도로 둔다.주요 데이터는 다음과 같다.예를

오늘은 지금까지 분석한 내용을 GitHub Actions Workflow와 연결해 전체 흐름으로 정리했다.프로젝트의 deploy-example.yml에는 실제 CI/CD 환경에서 Deploy-gate를 어떻게 호출할 수 있는지 예제가 구성되어 있다.SmallAppSta

디자인 예시안

title: "멀티클라우드 견적 자동화 1편 — 프로젝트를 시작한 이유"tags: Spring Boot, React, 사이드프로젝트, 아키텍처series: 멀티클라우드 견적 자동화 시스템이전에 다루던 도메인은 VMware·Citrix·Nutanix 같은 온프레미스 멀티

title: "멀티클라우드 견적 자동화 2편 — 벤더 3사 가격 API를 하나의 인터페이스로 묶기"tags: Spring Boot, Java, API 연동, 설계series: 멀티클라우드 견적 자동화 시스템AWS, Azure, GCP의 가격 조회 API는 인증 방식,

series: 멀티클라우드 견적 자동화 시스템이 프로젝트의 핵심 기능은 "4vCPU / 16GB 이상인 인스턴스 중 가장 싼 것을 찾는다"입니다. 그런데 Azure Retail Prices API는 가격만 주고 스펙을 주지 않습니다.vCPU도, 메모리도 없습니다. 스펙

series: 멀티클라우드 견적 자동화 시스템1편에서 "견적 요청마다 벤더 API를 직접 호출하지 않는다"는 원칙을 정했다고 했습니다. 속도 문제도 있었지만, 더 중요한 이유는 따로 있었습니다.AWS, Azure, GCP API를 모두 동시에 정상 상태로 유지하는 건

series: 멀티클라우드 견적 자동화 시스템견적을 화면에서 비교하는 것까지는 만들었는데, 실제 영업 현장에서는 그 결과를 고객에게 보낼 파일로 만들 수 있어야 의미가 있습니다. 그래서 워크로드 스펙, 벤더별 비교표, 절감액 요약을 담은 A4 1장짜리 PDF 견적서 기

series: 멀티클라우드 견적 자동화 시스템기능을 다 만들고 Playwright로 화면 전체를 훑어보던 중, 이상한 장면을 발견했습니다. 가격 데이터가 아직 수집되지 않은 리전(tokyo)으로 견적을 냈는데, 금액 칸은 전부 -로 비어 있으면서도 AWS 행에 "최저가

series: 멀티클라우드 견적 자동화 시스템이 시리즈의 마지막 편은 성공담이 아니라 정직한 중간 점검입니다. 기능은 다 만들었고 테스트도 24건이 통과하지만, 그게 "배포해도 안전하다"는 뜻은 아니라는 걸 스스로 짚고 넘어가려고 합니다.로컬 개발은 H2(인메모리)로

네트워크 보안장비를 다루는 기업의 기술영업 직무는 공공기관 입찰 대응이 핵심 업무 중 하나다. 입찰공고에 딸린 제안요청서(RFP)에는 "처리성능 10Gbps 이상", "국제 보안인증 등급 EAL2 이상", "특정 기관 보안적합성 검증필" 같은 요구사항이 수십 줄로 박혀

이 프로젝트의 진짜 어려운 부분 1편에서 이 프로젝트의 핵심은 "외부 API 연동"이 아니라 "요구사항과 제품 스펙을 대조하는 판정 로직"이라고 했다. 이번 글은 그 판정 로직, 즉 매칭 엔진을 어떻게 설계했는지 정리한다. 가장 먼저 부딪힌 문제는 이거였다. >

이 프로젝트는 계층형(controller/service/repository를 최상위로 분리)이 아니라 도메인별 수직 분리를 택했다.각 도메인 패키지 안에 domain / dto / repository / service / controller가 다 들어있다. 도메인이 4

MVP를 완성하고 나서 저장소를 공개하기로 했을 때, 코드가 잘 동작한다는 것과 별개로 한 가지를 다시 점검해야 했다. 실제 연동 대상 서비스의 명칭, 예시 데이터에 들어간 제품명·기관명이 코드 곳곳에 남아있었다. 개발 중에는 실제 값을 써야 테스트하기 편하지만, 공개

MVP를 완성하고 나서 저장소를 공개하기로 했을 때, 코드가 잘 동작한다는 것과 별개로 한 가지를 다시 점검해야 했다. 실제 연동 대상 서비스의 명칭, 예시 데이터에 들어간 제품명·기관명이 코드 곳곳에 남아있었다. 개발 중에는 실제 값을 써야 테스트하기 편하지만, 공개

이 프로젝트의 테스트는 두 계층으로 나뉜다.H2 기반 단위/통합 테스트 (47건) — Docker 없이 몇 초 안에 끝난다. 평소 개발 중에는 이것만 돈다.MySQL 8 기반 호환성 테스트 (Testcontainers) — 실제 운영 DB에서만 드러나는 방언 차이를 잡

MVP를 완성하고 나서 저장소를 공개하기로 했을 때, 코드가 잘 동작한다는 것과 별개로 한 가지를 다시 점검해야 했다. 실제 연동 대상 서비스의 명칭, 예시 데이터에 들어간 제품명·기관명이 코드 곳곳에 남아있었다. 개발 중에는 실제 값을 써야 테스트하기 편하지만, 공개

관심종목이 여러 개가 되면서, 매번 앱을 켜서 시세를 확인하는 게 번거로워졌습니다. 목표가에 도달하면 확인하러 가는 게 아니라, 조건을 걸어두면 알아서 알려주는 도구가 있으면 그 시간을 아낄 수 있겠다는 생각에서 시작했습니다.처음부터 목표를 "데모용 토이 프로젝트"가

프로젝트를 시작할 때 토스증권 Open API의 실제 계정 키가 없었습니다. 공식 문서도 엔드포인트 목록만 나열돼 있을 뿐, 요청/응답 스키마 상세는 확인할 방법이 없었습니다.이럴 때 가장 흔한 실수는 "문서가 갖춰질 때까지 기다리는 것"입니다. 그 대신 외부 의존성의

1단계 MVP가 목표가 조건 하나만 지원했다면, 이번 단계는 실제 매매 판단에 쓸 만한 조건들을 채우는 작업입니다.목표가 하나만으로는 부족했습니다. 실사용에 더 유용한 조건들을 우선순위로 추가했습니다.목표가 이상 도달 (PRICE_ABOVE)목표가 이하 도달 (PRIC

기능이 어느 정도 쌓인 시점에서, 백엔드 단위 테스트가 0개였습니다. 이 시점에 몰아서 테스트를 작성했는데, 단순히 "기능이 맞는지 확인"하는 것 이상으로 실제 버그 2건을 찾아냈습니다.기능을 하나씩 추가하는 초기 단계에서는 요구사항 자체가 자주 바뀝니다. 이 시점에

이 글의 코드/로그 예시는 전부 실제 값을 가짜 값으로 치환했습니다. client_id, client_secret, 계좌번호, 서버 IP 등 실제 값은 본문에 포함되지 않습니다.Mock으로 전 기능을 완성한 뒤, 실제 토스증권 계좌와 연동을 시작했습니다. 공식 문서는

이 글의 응답 예시 값(금액, 종목명, 거래량 등)은 전부 가짜 값입니다. 실제 계좌 데이터가 아닙니다.인증과 URL 문제를 해결하고 나니, 이번엔 응답 자체가 예상과 다른 문제들이 이어졌습니다. 문서에 스키마가 없으니, 모든 걸 실제 호출로 확인해야 했습니다.보유종목

실연동이 동작하기 시작한 뒤, 코드를 다시 훑어보면서 "동작은 하는데 품질이 떨어지는 지점"을 스스로 점검했습니다. 이번 편은 그 과정에서 고친 두 가지입니다.PriceAlertScheduler는 알림 규칙마다 getQuote()를 호출했습니다. 같은 종목에 규칙이 2

이 글은 보안과 직접 관련된 내용을 다룹니다. 어떤 문제가 있었고 어떻게 고쳤는지는 설명하지만, 진단용 엔드포인트가 실제로 반환하는 응답 내용이나 실제 계좌 데이터는 포함하지 않습니다.기능이 아니라, 당장 눈에 보이지 않는 운영 관점의 문제 세 가지를 정리한 편입니다.

시리즈 마지막 편입니다. 남은 기능 세 가지를 짧게 정리하고, 프로젝트 전체를 돌아봅니다.보유종목, 관심종목, 알림까지는 있었지만 "지금 체결 대기 중인 주문이 뭐가 있나"를 볼 방법이 없었습니다. 조회 전용 API가 있길래 읽기 전용 엔드포인트 하나를 추가했습니다.여

시리즈: Subhelp — iOS 구독 관리 앱 개발기이번 글: 문제 정의, 기술 스택, 아키텍처 결정, 프로젝트 셋업Subhelp는 흩어진 구독 결제를 한곳에 모아, 언제·얼마가 빠져나가는지 미리 알려주는 iOS 앱입니다.모으기 — 모든 구독을 한 화면에 등록보여주기

시리즈: Subhelp — iOS 구독 관리 앱 개발기이번 글: 결제일·금액 계산 로직, 단위 테스트, CI에서 테스트 돌리기1월 31일에 시작한 월결제를 "이전 결제일 + 1개월"로 반복 계산하면 날짜가 밀립니다.2월에 28일로 한 번 잘리면, 그다음부터는 28일을

시리즈: Subhelp — iOS 구독 관리 앱 개발기이번 글: 로컬 알림 전략, 알림 권한 타이밍, App Group으로 위젯과 데이터 공유, 딥링크iOS는 앱 하나당 대기 중인 로컬 알림을 최대 64개까지만 허용합니다. 구독이 많으면 금방 넘칩니다.구독마다 다음 결

시리즈: Subhelp — iOS 구독 관리 앱 개발기이번 글: 기획서 반영(MVP 1), 무료체험 규칙을 Domain에 넣기, 폼 구조, 상세 화면, 온보딩, 접근성기본 기능을 만든 뒤 기획서를 받아 비교해 보니, 이미 만든 동작을 바꿔야 하는 부분이 있었습니다.출시

시리즈: Subhelp — iOS 구독 관리 앱 개발기이번 글: 통계 탭(MVP 2), 결제 캘린더, 비싼 구독 순위, 연간 결제 예고, 정렬·필터, type-check 시간 초과 트러블슈팅탭은 홈 / 구독 / 통계 / 설정 4개가 됐고, 홈에 있던 카테고리 차트는 통

시리즈: Subhelp — iOS 구독 관리 앱 개발기이번 글: 계정 삭제 요건, Supabase Edge Function, 비밀 키 관리, 개인정보 라벨, 회고App Store는 계정을 만들 수 있는 앱이라면 앱 안에서 계정 삭제 기능을 제공하라고 요구합니다. App

"왜 이 파드가 죽어?"라고 물으면, 에이전트가 조회만 해서 원인 후보와 근거를 보여주는 도구를 만들었다.쿠버네티스에서 장애가 나면 늘 같은 루틴을 반복한다.명령어 네 개를 오가면서 단서를 머릿속으로 이어 붙여야 한다. 익숙하면 금방이지만, 주니어 시절의 나는 어디부터

🔗 사이트: https://dlwldp.github.io/Awscal/🔗 GitHub: https://github.com/dlwldP/Awscal처음 AWS에 뭔가를 올려보려고 할 때마다 같은 벽에 부딪혔다.공식 Pricing Calculator는

🔗 사이트: https://dlwldp.github.io/Awscal/🔗 GitHub: https://github.com/dlwldP/Awscal📝 1편: 초보자용 AWS 비용 계산기를 만들었다 (MVP · 직접 계산기 · 토스 스타일 디자인)1

하고 싶은 일을 고르면 맞는 AI 툴 2~3개를 이유와 함께 비교해주는 비개발자용 선택 도우미."AWS 얼마야?"의 자매 프로젝트입니다.사이트: https://dlwldp.github.io/which-ai/예시 데이터로 둘러보기: https://dlw

1편에서는 "목적을 고르면 AI 툴 2~3개를 추천해주는 사이트"의 뼈대(추천 규칙, 화면, 배포, 주간 점검)를 만들었습니다. > 2편은 그 뒤의 이야기입니다. 개발자용 버전으로 넓힌 과정과, AI에게 툴 정보를 모아 달라고 하기 전에 정한 보안 규칙을 정리했습니다.

🔗 사이트: https://dlwldp.github.io/Awscal/ > 🔗 GitHub: https://github.com/dlwldP/Awscal > 📝 1편: 초보자용 AWS 비용 계산기를 만들었다 (MVP · 직접 계산기 · 토스 스타일 디자인) > 📝

"AWS 얼마야?" 4편 — 읽기 쉽게 다듬고, v2 로드맵을 끝내다 > 🔗 사이트: https://dlwldp.github.io/Awscal/ > 🔗 GitHub: https://github.com/dlwldP/Awscal > 📝 1편: 초보자용 AWS 비용