요즘 바이브 코딩이 정말 대세이다. LLM부터 Agent 모드가 나오고 나서까지 코딩은 AI로 많이 대체되고 있는 상황이다.바이브 코딩을 할 때, 무엇을 알아야 할까?질 좋은 응답, 사용자의 의도에 맞는 응답 등이 있을 것이다.바이브 코딩 시 거론되는 가장 큰 문제는 두 가지다. 토큰과 AI의 고질적 버릇토큰 — 채팅이 길어질수록, 규칙이 두꺼울수록, 파일을 통째로 넣을수록 돈과 컨텍스트가 먼저 닳는다.모델의 버릇 — 추측하고, 코드를 부풀리고, 상관없는 파일을 고친다. 1. 토큰이란?토큰이란 LLM이 글을 잘라 먹는 최소 조각이다. 단어가 아니고, 글자도 아니며 모델 안의 토크나이저가 정한 단위다.토큰에는 입력토큰과 출력토큰이 있는데 아래의 예시를 확인하면 된다.사람이 보는 것로그인 실패 시 400을 ..
1. Docker란Docker란 이미지를 만들고, 그 이미지로 컨테이너를 실행·관리하는 오픈 소스 툴이다.서버마다 JDK 버전, 폰트, 설정 파일이 달랐다. “내 PC에선 되는데 서버에선 안 된다”가 일상이었다. Docker는 실행에 필요한 것을 이미지로 묶어, 어디서 켜도 같게 만든다. Docker가 하는 일 작업명령/산출결과이미지 만들기 docker build + Dockerfile 태그 달린 이미지 컨테이너 실행 docker run그 이미지로 프로세스 기동확인 docker ps, docker logs 떠 있는지, 로그 중지/삭제 docker stop / rm 프로세스만 끝. 이미지는 남음 창고에 올리기 docker pushECR 같은 레지스트리 실무에서 이 명령을 매일 손으로 치는 사람은 적다. ..
주요 흐름 (프로젝트 규칙에 따라 상이)화면 버튼/조회 → Store action → Service 메서드 (타입으로 인자/반환을 맞춤) → reqPOST / reqGET → jwt() 로 Authorization 붙임 → 서버 ← JSON 응답 ← Service가 response.data 를 그대로 반환 ← Store가 data 를 list/detail 에 넣음 ← 화면은 store.list / store.detail 만 그림1. 타입 (export interface)요청·응답 모양을 정의하는 모델이다. 화면·서비스·스토어가 같은 필드명을 쓰게 하기 위해 사용한다.export interface OrderListRequest..
맨날 모놀리식(Monolith)방식의 프로젝트만 진행하다 MSA 프로젝트를 진행하며 큰 차이를 느꼈다. 그 중, 프로세스에 따라 API 호출 방식이 다른 점이다.구분Monolith (모놀리식)MSA (마이크로서비스 아키텍처)구조하나의 통합 애플리케이션독립적인 서비스들의 집합배포 방식전체 애플리케이션을 한 번에 배포서비스 단위로 개별 배포 가능장애 영향특정 기능 장애가 전체 시스템에 영향장애가 해당 서비스에만 국한됨확장성전체 시스템을 확장해야 함필요한 서비스만 선택적으로 확장 가능데이터 관리단일 데이터베이스서비스별 독립 DB 가능개발 협업하나의 코드베이스에서 협업 → 충돌 위험팀별로 독립 서비스 담당 가능기술 스택동일한 기술 스택 사용서비스별로 다른 언어/프레임워크 사용 가능장점단순, 초기 개발 빠름, 디..
실무에서 시스템을 운영하다 보면, 데이터의 변경 이력을 엄격하게 추적하기 위해 원본 테이블과 1:1로 매칭되는 이력 테이블(_hst)을 두는 경우가 매우 흔하다.문제를 겪었던 프로젝트는 원본 테이블에 CUD(Create, Update, Delete)가 발생하면 데이터베이스 트리거(Trigger)가 백그라운드에서 돌아가고, 시퀀스(Sequence)의 NEXTVAL을 호출해 이력 테이블의 PK(이력 일련번호)를 채우며 INSERT 되는 아키텍처를 띈다.비즈니스 로직에 개입하지 않고 DB 단에서 조용하고 확실하게 이력을 남길 수 있어 자주 쓰이는 패턴이다. 그런데, 기존 시스템(AS-IS)에서 새로운 시스템(TO-BE)으로 대규모 데이터를 이관하는 과정에서 이 뻔한 구조가 거대한 폭탄으로 돌아오는 현상을 겪었..
매일 쌓이는 데이터를 조회하는 화면에서 수백만 건 이상 데이터 페이징 조회가 필요했다.단순히 SELECT * (모든 컬럼 또는 많은 컬럼들)로 페이징을 처리하면 응답 시간이 급격히 느려졌고, DB 부하도 눈에 띄게 증가했다. (화면 조회조건으로 돌릴 시 대충 10 ~ 20초 이상 걸림), 조회조건에 PK를 사용한다기 보단 기간(날짜 from ~ to)과 공통코드들을 위주로 조회하기 때문에 인덱스가 안 걸려있음.실무에서 효과가 있었던 방법은 CTE(또는 서브쿼리)로 PK만 먼저 조회한 뒤, 그 결과를 다시 조인해서 상세 컬럼을 조회하는 방식이다.이 글에서는 왜 이 방식이 빠른지에 대한 원리와 실제 SQL 예시를 정리한다.1. 기존 방식의 문제점 (모든 컬럼을 바로 조회)SELECT *FROM EMP..
배치와 온라인 시스템이 분리되어 있어서, 스프링 배치에서 온라인 API를 호출해야 되는 상황이 있었다.타 시스템을 호출하기 위해 사용했던 방법을 적어보려고 한다.API 호출하기에 많은 방법들이 있지만, Spring에서 제공하는 http 클라이언트를 사용하여 API를 호출하려고 한다.대표적으로, RestTemplate와 WebClient가 있다.POST MAN으로 테스트하듯 API 호출할 수 있으며, ui없이 java로만 요청/응답 파싱 후 처리하는 느낌이었다.1. 실무에서 외부 API URL 호출 구현 방법 - 대표적인 방법들(Java 기준, 백엔드에서 외부 API 호출)1) HttpURLConnection (JDK 기본)장점: 라이브러리 추가 필요 없음.단점: 코드가 장황하고 불편함. 커넥션/스트림 관..
1. @Transactional이란?스프링에서 데이터베이스의 트랜잭션 처리를 위해 사용하는 어노테이션이다.트랜잭션이란 한 번에 수행되어야 할 작업의 단위를 의미하고, 모두 성공하면 커밋, 하나라도 실패하면 롤백된다.트랜잭셔널 어노테이션은 보통 http 요청에서 CRUD 기능에 따라 옵션을 설정하여 사용한다.예를 들어, GET 요청은 조회 시 대부분 사용되기에 @Transactional(readOnly = true)를 사용한다.데이터는 소중하기 때문에, 삭제되거나 잘못된 작업에 의해 롤백되지 않으면 심각한 오류를 초래할 수도 있다. 2. 롤백 조건 – 왜 런타임 익셉션만 롤백할까?스프링의 기본 정책은 Unchecked Exception(즉, RuntimeException과 그 하위) 발생 시 자동 롤백하고..
