용어

--amend: 방금 만든 커밋을 지우지 않고, 거기에 빠뜨린 파일이나 메시지를 더해 같은 자리에 다시 덮어쓰는 명령이다. 새 커밋을 쌓는 대신 마지막 커밋 하나를 고쳐 쓴다. 이미 다른 사람이 받아 간 커밋을 amend 하면 그 사람이 가진 기록과 내 기록이 서로 어긋난다.
--check: 검사 스크립트를 실제로 고치지 않고 지금 상태가 최신인지만 확인하고 끝내게 만드는 명령행 인자다. 어긋난 곳을 찾으면 실패로 끝나서 그 뒤에 이어지는 배포 같은 자동화를 멈추게 한다. 같은 스크립트를 이 옵션 없이 돌리면 보통 실제로 파일을 고치거나 다시 만든다.
--debug: 프로그램을 돌릴 때 붙이는 옵션이다. 붙이면 스프링 부트가 자동 구성 판정 결과를 로그 끝에 전부 찍어 준다. 이 페이지의 271 · 157 · 114 가 거기서 나왔다.
-ea · -da: 자바 프로그램을 실행할 때 assert 문이 실제로 검사를 할지 정하는 JVM 옵션이다. -ea(enable assertions)를 주면 assert 문이 조건을 검사해서, 거짓이면 AssertionError를 던진다. -da(disable assertions)를 주거나 아무 옵션도 안 주면 assert 문은 아무 일도 하지 않고 그냥 지나간다 — 기본값이 꺼짐이다.
.dockerignore: Docker가 이미지를 만들 때 담지 않을 파일·폴더 목록을 적어 두는 파일이다. .gitignore와 비슷한 역할이지만 대상이 Git 커밋이 아니라 Docker 이미지라는 점이 다르다. 여기 적힌 경로는 빌드 컨텍스트 안에 있어도 이미지 안으로 복사되지 않는다.
.gitattributes: 파일마다 Git이 다르게 처리해야 할 규칙을 적어 두는 설정 파일이다. 줄바꿈 문자를 통일하거나 특정 파일을 다른 언어로 취급하게 하는 규칙을 여기에 적는다. 사람이 하나하나 맞추지 않아도 저장소를 내려받는 모든 컴퓨터에 같은 규칙이 적용된다.
.gitignore: 저장소에 커밋하지 않을 파일 이름을 적어 두는 설정 파일이다. 여기 적힌 이름이나 패턴에 맞는 파일은 git add를 해도 올라가지 않는다. 비밀번호나 토큰처럼 저장소에 남으면 안 되는 값을 담은 파일을 여기 적어 둔다.
/proc: 커널이 지금 상태를 파일인 것처럼 보여 주는 가짜 폴더다. ls -l /proc/self/fd 를 치면 지금 열어 둔 것이 나온다. 디스크에 진짜 파일이 있는 것은 아니다.
16진수: 숫자를 0–9 다음에 a(10) b(11) c(12) d(13) e(14) f(15)까지 16개 글자로 적는 방법이다. 두 자리면 「앞자리 × 16 + 뒷자리」다 — 41은 4 × 16 + 1 = 65, 1d는 1 × 16 + 13 = 29. 바이트 두 개로 적은 수는 「앞 바이트 × 256 + 뒤 바이트」다 — 00 41은 65, 01 00은 256. 바이트 하나가 정확히 두 자리라서 파일을 볼 때 쓴다. 앞에 붙은 0x는 16진수라는 표시다.
1단 (CLAUDE.md): 코딩 표준이 AI에게 닿는 통로를 층으로 나눌 때 가장 위에 있는 자리다. CLAUDE.md처럼 세션을 시작할 때마다 판단 없이 통째로 읽히는 자리를 가리키고, 그 아래 스킬(모델이 부르기로 판단해야만 읽힌다)·rules(정해진 경로의 파일을 다룰 때만 본문이 끼워진다)와 구분된다. 「말하지 않으면 기본값으로 어기게 되는 것」을 이 자리에 둔다.
1단 · 2단 · 3단: 이 블로그의 코딩 표준이 AI 도구에 전달되는 세 단계를 가리키는 말이다. 1단은 CLAUDE.md처럼 항상 읽히는 「항상 적용」 규칙이고, 2단은 특정 파일 경로를 건드릴 때만 불려오는 「규칙」(.claude/rules)이고, 3단은 특정 작업을 할 때만 불려오는 「절차」(.claude/skills)다. 뒤로 갈수록 평소에는 안 보이다가 필요한 순간에만 불려온다.
3-way handshake: TCP 연결을 열 때 주고받는 세 번의 인사다(SYN → SYN+ACK → ACK). 이 셋이 끝나야 연결이 선다.
3계층 구조: 코드를 역할에 따라 Controller · Service · Repository 세 층으로 나누는 구조다. 요청을 받는 일, 업무 규칙을 처리하는 일, DB 를 다루는 일을 각자 다른 층이 맡고, 위층은 바로 아래층만 부른다 — Controller 가 Repository 를 직접 부르지 않고 꼭 Service 를 거친다. 그래서 한 층의 내부를 바꿔도 다른 층은 거의 영향을 받지 않는다.
404: 「그런 주소가 없다」는 HTTP 상태 번호다. 200은 성공, 400은 「보낸 값이 잘못됐다」, 405는 「주소는 있는데 그 방식(GET · POST 등)은 안 받는다」는 뜻이다.
== 과 .equals(): 둘 다 "같다"를 검사하지만 보는 것이 다르다. ==는 기본형(int, long 등)이면 값을, 객체면 참조(객체가 저장된 주소)를 비교한다. 두 객체가 내용은 같아도 new로 따로 만들어졌다면 ==는 false다. .equals()는 클래스가 정의한 기준으로 "내용이 같은가"를 비교한다 — BigDecimal·String 같은 타입은 값이 같으면 true를 돌려주도록 이미 구현돼 있다. 그래서 숫자나 문자열 같은 객체를 비교할 때는 ==가 아니라 .equals()를 쓴다.
@Autowired: 필드나 생성자에 붙여서 「이 자리에 필요한 빈을 스프링이 찾아서 넣어 달라」고 요청하는 표시다. 생성자가 하나뿐이면 이 표시를 안 붙여도 스프링이 알아서 넣어 주기 때문에, 요즘은 생성자 주입에서는 거의 생략한다.
@BatchSize: 연관된 데이터를 한 건씩 따로 조회하지 않고, 정해 둔 개수만큼 묶어 IN 쿼리 한 번으로 가져오게 하는 JPA 설정이다. size를 10으로 두면 게시글 10개에 딸린 댓글을 한 개씩 10번 조회하는 대신 IN (1,2,...,10) 같은 쿼리 한 번으로 묶어서 가져온다. join fetch 없이 N+1 문제를 줄이는 방법 중 하나다.
@Bean: 내가 직접 쓴 메서드가 돌려주는 객체를 빈으로 등록해 달라고 알리는 표시다. @Component 가 클래스 전체에 붙어 "이 클래스를 통째로 빈으로 만들어라"라고 말하는 것과 달리, @Bean 은 메서드에 붙어 "이 메서드가 만든 결과물을 빈으로 써라"라고 말한다. 내가 수정할 수 없는 남의 클래스를 빈으로 등록할 때 주로 쓴다.
@Builder: Lombok 이 제공하는 표시로, 객체를 만들 때 .name("철수").age(10) 처럼 필드 이름을 하나씩 붙여 가며 만들 수 있게 해 준다. 생성자에 값을 순서대로 늘어놓는 방식과 달리, 어떤 값이 무엇인지 이름으로 바로 알아볼 수 있고 일부 필드만 채워 만들기도 쉽다.
@Cell: 이 블로그의 표준이 API 테스트 계약을 표로 관리하려고 만든 애너테이션이다. enum 상수 하나에 붙여서 그 상수가 표의 어느 칸(행·열)에 해당하는지와 기대 결과를 적어 둔다. endpoint(주소)·actor(누가)·state(어떤 상태)·expect(기대 결과) 네 값을 받는다. 자바 표준 애너테이션이 아니라 이 블로그가 직접 정의한 것이다.
@Component: 이 클래스를 빈으로 만들어 달라고 표시하는 가장 기본적인 애너테이션이다. @Service, @Controller, @Repository 는 사실 이 표시를 속에 품고 있는 좀 더 구체적인 표시들이다 — 역할 이름만 다를 뿐 "빈으로 만들어라"는 뜻은 같다.
@Configuration: 이 클래스 안의 @Bean 메서드들이 Spring이 관리하는 빈을 만드는 설정 클래스라는 표시다. Spring이 애플리케이션을 시작할 때 이 표시가 붙은 클래스를 찾아 그 안의 메서드를 호출해 빈을 등록한다.
@CreatedBy: JPA Auditing이 제공하는 표시로, Entity가 처음 저장될 때 "누가 만들었는가"를 AuditorAware가 돌려준 값으로 자동으로 채워 준다. 같은 계열로 수정한 사람을 채우는 @LastModifiedBy가 있다.
@Data: Lombok이 제공하는 표시로, @Getter·@Setter·@ToString·@EqualsAndHashCode·@RequiredArgsConstructor를 한 번에 붙인 것과 같은 효과를 낸다. 애너테이션 하나만 붙이면 조회·수정 메서드, 문자열 표현, 같음 비교, 생성자까지 전부 자동으로 생긴다. final 필드에는 수정 메서드를 만들지 않고 그 필드를 생성자가 받는다.
@Getter: Lombok 이 제공하는 표시로, 클래스의 모든 필드에 대해 get으로 시작하는 조회 메서드를 자동으로 만들어 준다. private final int status 필드가 있으면 getStatus() 메서드를 손으로 적지 않아도 컴파일할 때 생겨난다.
@Id · @GeneratedValue: Entity 클래스에서 어느 필드가 테이블의 기본 키(PK)인지 표시하는 애너테이션이다. `@Id`는 "이 필드가 그 행을 구별하는 값이다"를 알려주고, `@GeneratedValue`를 함께 붙이면 값을 직접 넣지 않아도 DB가 저장할 때 번호를 자동으로 매겨 준다.
@JsonCreator · @JsonProperty: Jackson이 JSON을 자바 객체로 되돌릴 때 생성자나 필드 이름을 어떻게 맞출지 알려주는 애너테이션이다. @JsonCreator는 「역직렬화할 때 이 생성자를 써라」, @JsonProperty는 「이 값은 JSON의 이 이름과 짝이다」라는 뜻이다. 필드 이름이 JSON 키와 다르거나 생성자가 여러 개라 Jackson이 헷갈릴 때 붙인다.
@LastModifiedDate · @PreUpdate: Entity의 시간 필드를 자동으로 채워주는 두 가지 방법이다. @LastModifiedDate(@CreatedDate도 같은 계열)는 Spring Data JPA Auditing 기능이 Entity가 저장·수정될 때마다 알아서 채워 주는 애너테이션이고, @PreUpdate는 JPA 표준이 제공하는 콜백으로 UPDATE 쿼리가 나가기 직전에 메서드 하나가 자동으로 실행되게 한다. 둘 다 "수정 시각을 기록한다"는 같은 목적을 서로 다른 방식으로 이룬다.
@NoArgsConstructor: Lombok이 제공하는 표시로, 아무 값도 받지 않는 생성자(기본 생성자)를 자동으로 만들어 준다. `access = AccessLevel.PRIVATE`을 함께 붙이면 그 생성자를 클래스 밖에서는 못 쓰게 막아, "이 기본 생성자는 프레임워크 전용이고 직접 쓰지 말라"는 뜻으로 쓴다.
@OneToMany · cascade · orphanRemoval: 부모 Entity가 자식 컬렉션의 생명주기까지 대신 관리하게 만드는 설정이다. @OneToMany는 "이 필드가 자식 여러 개를 담는 컬렉션"이라는 뜻이고, cascade = CascadeType.ALL은 부모를 저장·삭제할 때 자식도 같이 저장·삭제하라는 뜻이며, orphanRemoval = true는 컬렉션에서 자식을 빼기만 해도(부모와 연결이 끊기면) 그 자식 행을 DB에서 지우라는 뜻이다.
@Override: 메서드 위에 붙여 "이건 인터페이스나 부모 클래스에 있는 메서드를 다시 구현한 것이다"라고 표시하는 애너테이션이다. 안 붙여도 동작은 같지만, 붙여 두면 이름이나 매개변수를 잘못 적었을 때 컴파일러가 바로 알려준다 — 원래 메서드와 모양이 다르면 "이건 재정의가 아니다"라고 에러를 낸다.
@PathVariable: 주소 안에 박힌 값을 메서드 인자로 받는 표시다. /test/5 에서 5 를 꺼내 준다. 주소의 앞부분은 클래스에 붙인 @RequestMapping("/test") 에서 오고, 뒷부분은 메서드에 붙인 @GetMapping("/{step}") 에서 온다 — 둘이 이어 붙어 /test/{step} 이 된다.
@PreAuthorize: 메서드가 시작되기 전에 「이 사람이 이걸 호출할 권한이 있는가」를 검사하는 표시다. @PreAuthorize(「hasRole('ADMIN')」)을 붙이면 관리자 권한이 없는 사람이 호출했을 때 메서드 코드가 한 줄도 실행되지 않고 바로 막힌다.
@RequestBody: 요청과 함께 온 JSON 본문을 자바 객체로 바꿔서 메서드 인자로 받는 표시다. 손님이 보낸 글(JSON)을 내가 정한 양식(DTO 클래스)에 맞춰 자동으로 옮겨 적어 주는 것과 같다.
@RequestParam: 주소의 물음표 뒤에 붙은 값을 메서드 인자로 받는 표시다. /orders?item=book 에서 book 을 꺼내 준다.
@RequiredArgsConstructor: Lombok 이 제공하는 표시로, final 로 선언한 필드만 받는 생성자를 자동으로 만들어 준다. 생성자를 손으로 적지 않아도, 그 생성자를 보고 의존성 주입이 이뤄진다는 점은 똑같다.
@RestControllerAdvice: 모든 Controller 에서 발생한 예외를 한곳에서 받아 처리하는 클래스에 붙이는 표시다. 이 클래스를 Advice 라고 부른다. 안에서 @ExceptionHandler 를 붙인 메서드로 "이 예외가 나면 이렇게 응답한다"를 정해 두면, Controller 마다 try-catch 를 반복해서 쓰지 않아도 된다.
@Schema: Swagger 문서에 그 필드의 설명을 적어 두는 애너테이션이다. description에 사람이 읽을 설명을, nullable 같은 속성에 그 필드의 특성을 적으면 Swagger 화면과 OpenAPI 문서에 그대로 나타난다. 코드에는 영향을 주지 않고 문서에만 쓰인다.
@Slf4j: Lombok 이 제공하는 표시로, 로그를 남길 때 쓰는 log 라는 이름의 필드를 자동으로 만들어 준다. 이 표시가 없으면 Logger log = LoggerFactory.getLogger(이 클래스.class) 를 직접 써야 하는데, @Slf4j 를 클래스에 붙이면 그 줄 없이 바로 log.warn(...), log.error(...) 를 쓸 수 있다.
@StepScope: 스프링이 빈을 하나만 만들어 공유하지 않고, Step이 실행될 때마다 새 인스턴스를 만들게 하는 표시다. Partitioner가 나눈 파티션마다 다른 값(코드 A, 코드 B...)을 가져야 하는 Reader 같은 빈에 붙인다. 이 표시가 없으면 모든 파티션이 같은 인스턴스를 공유해서 값이 서로 뒤섞인다.
@Transactional: 메서드나 클래스에 붙이는 표시다. 붙은 메서드가 시작될 때 트랜잭션을 열고, 끝나면 커밋하고, 도중에 예외가 나면 되돌린다. 그 일을 하는 코드는 내 클래스가 아니라 프록시 안에 있다.
Accept: 요청을 보내는 쪽이 「나는 이런 형식을 받을 수 있다」고 적어 보내는 항목이다. */* 는 아무거나 좋다는 뜻이고, text/html 이면 HTML을 달라는 뜻이다.
accept 큐: 악수가 끝난 연결들이 accept() 로 꺼내지기를 기다리는 줄이다. 서버 프로그램이 바빠서 늦게 꺼내 가면 여기에 쌓인다.
actuator: 스프링 부트가 붙여 주는 관리용 주소 묶음이다. /actuator/health 처럼 서버 상태를 들여다보는 주소가 여기 들어 있고, 내가 만든 표가 아니라 별도의 표가 답한다.
additionalContext: Claude Code의 훅이 도구를 부르기 직전에 JSON 응답 안에 실어 보낼 수 있는 글이다. 사람 화면에만 찍히는 보통 출력과 달리, 이 값은 Claude가 다음 판단을 할 때 실제로 읽는 내용으로 들어간다.
Ajax: 페이지 전체를 다시 불러오지 않고, 자바스크립트로 필요한 데이터만 서버에 요청해서 화면 일부만 바꾸는 방식이다. 검색어를 입력할 때마다 페이지가 깜빡이지 않고 목록만 바뀌는 게 Ajax 덕분이다. fetch는 요즘 Ajax 요청을 보낼 때 가장 많이 쓰는 함수다.
Alertmanager · 알림 규칙: Prometheus가 「이 숫자가 이 조건을 넘었다」고 판단하면 그 소식을 메일이나 메신저로 사람에게 보내는 도구다. 그 조건을 적어 둔 것이 알림 규칙이다. 예를 들어 「CPU 사용률이 5분 동안 90%를 넘으면 알린다」를 알림 규칙으로 적어 두면, 조건에 걸릴 때마다 Alertmanager가 정해 둔 곳으로 알림을 보낸다.
ALTER TABLE: 이미 만들어진 테이블의 구조를 바꾸는 SQL 문이다. ALTER TABLE orders ADD COLUMN phone_number VARCHAR(20) 처럼 쓰면 orders 테이블에 컬럼을 하나 추가한다. 컬럼을 지우거나 타입을 바꿀 때도 이 문으로 한다.
AOP: 트랜잭션이나 로그처럼 여러 곳에 똑같이 들어가야 하는 일을, 원래 코드는 그대로 두고 밖에서 감싸 붙이는 방식이다. 스프링은 그 감싸는 일을 프록시로 한다. 「AOP 프록시」는 그렇게 만들어진 프록시라는 뜻이다.
API: 프로그램끼리 기능을 빌려 쓰게 정해 둔 창구다. 식당 메뉴판과 비슷하다 — 안에서 음식을 어떻게 만드는지 몰라도 메뉴판에 적힌 대로 주문하면 음식이 나온다. 웹에서는 보통 주소로 요청을 보내면 정해진 형식의 응답이 돌아오는 방식을 뜻한다.
APM: 프로그램 안에서 어떤 요청이 어느 코드를 거치며 얼마나 걸렸는지 하나하나 추적해 보여주는 도구다. 메트릭이 「지금 CPU가 몇 퍼센트다」처럼 뭉뚱그린 숫자를 보여준다면, APM은 「이 요청 하나가 DB 조회에서 300ms, 외부 API 호출에서 200ms 걸렸다」처럼 요청 하나의 속을 들여다본다. Application Performance Monitoring의 줄임말이다.
App Router (Next.js): Next.js가 제공하는 라우팅 방식이다. `app/` 폴더 밑의 폴더 구조가 그대로 주소가 된다 — `app/about` 폴더를 만들면 `/about` 주소가 자동으로 생긴다. 그 폴더 안에 `layout.js`·`page.js`처럼 정해진 이름으로 파일을 두면 Next.js가 역할을 자동으로 알아본다.
application.yml: Spring Boot가 켜질 때 가장 먼저 읽어 들이는 설정 파일이다. DB 주소, 로그 수준, JPA 옵션처럼 환경이 바뀔 때마다 달라지는 값을 여기 적어 두면, 코드를 고치지 않고 이 파일만 바꿔서 동작을 바꿀 수 있다. YAML 형식으로 적는다.
ArchUnit: 패키지 구조나 의존 방향 같은 설계 규칙을 테스트 코드로 검사하는 도구다. 「domain 패키지는 api 패키지를 참조하면 안 된다」 같은 규칙을 코드로 적어 두면, 누군가 그 규칙을 어기는 import를 추가하는 순간 테스트가 실패해서 바로 알아챌 수 있다.
aspectj: 메서드를 감싸는 일을 하는 다른 라이브러리다. 이것이 클래스패스에 있으면 스프링은 감쌀 대상을 더 잘게 고를 수 있는 그쪽 장치를 함께 쓰고, 없으면 상속만으로 감싼다(CGLIB). 이 실측에서는 넣지 않았다.
AuditorAware: JPA Auditing이 @CreatedBy·@LastModifiedBy 필드를 채울 때 "지금 누가 이 작업을 하고 있는가"를 물어보는 창구다. 이 인터페이스를 구현해 Bean으로 등록해 두면, Entity가 저장될 때마다 JPA Auditing이 이걸 불러 그 값을 받아 간다.
AuthenticationEntryPoint · AccessDeniedHandler: Spring Security 가 인증·인가 실패를 처리하라고 정해 둔 두 자리다. AuthenticationEntryPoint는 로그인하지 않은 사람이 왔을 때(인증 실패), AccessDeniedHandler는 로그인은 했지만 권한이 없는 사람이 왔을 때(인가 실패) Spring Security가 대신 불러 준다. 둘 다 직접 구현한 클래스를 등록해 두면, 그 실패가 났을 때 내가 원하는 모양으로 응답을 써서 돌려줄 수 있다.
AUTO_INCREMENT: 새 행을 넣을 때 DB가 기본 키 값을 1씩 자동으로 늘려 채워 주는 컬럼 설정이다. id 컬럼에 이 설정을 걸어 두면 INSERT 문에 id 값을 직접 적지 않아도 DB가 알아서 다음 번호를 매겨 넣는다. 그래서 그 번호는 행을 실제로 넣어 본 뒤에야 알 수 있다.
B-tree: 대부분의 DB 인덱스가 속에 쓰는 나무 모양의 자료 구조다. 값을 크기 순서대로 가지를 타고 내려가며 찾기 때문에 데이터가 아무리 많아도 비교 몇 번 만에 원하는 값 근처에 도달한다. 전화번호부를 반으로, 또 반으로 쪼개며 찾아가는 방식과 비슷하다.
Base64: 이진 데이터나 특수 문자가 섞인 값을 영문자·숫자·기호 몇 개만으로 이루어진 문자열로 바꾸는 인코딩 방식이다. 암호화가 아니라 모양만 바꾸는 것이라 누구나 원래 값으로 되돌릴 수 있다. URL이나 JSON처럼 특정 문자를 쓰면 안 되는 자리에 복잡한 값을 안전하게 끼워 넣을 때 쓴다.
BasicErrorController: 스프링 부트가 기본으로 넣어 주는 에러 응답 컨트롤러다. /error 주소를 맡고, 내가 에러 페이지를 만들지 않아도 404 응답에 본문이 붙는 이유가 이것이다. 여기로 한 번 더 돌아도 응답 번호는 404 그대로이고 본문만 채워진다.
bci: 명령이 메서드 코드의 몇 번째 바이트에서 시작하는지다. 명령마다 길이가 달라서(iload_1은 1바이트, if_icmpgt 19는 3바이트) 번호가 건너뛴다. 화면의 pc는 지금 실행하는 명령의 bci다.
Bean Validation: DTO 필드에 "이 값은 이래야 한다"는 규칙을 애너테이션으로 붙여 두면 자동으로 검사해 주는 기능이다. @NotNull 은 "값이 비면 안 된다", @Valid 는 "이 객체에 붙은 규칙들을 지금 검사하라"는 뜻이다. 규칙을 어기면 메서드 코드가 시작되기도 전에 에러 응답이 나간다.
Bearer 토큰: 이 토큰을 들고 있는 사람이면 누구든 인증된 것으로 인정하는 방식의 토큰이다. 요청을 보낼 때 `Authorization: Bearer 토큰값` 형태로 헤더에 실어 보내고, 서버는 그 토큰만 보고 로그인된 사람인지 확인한다.
BindException: Spring이 @ModelAttribute로 요청 값을 객체 필드에 채우다가 실패했을 때 던지는 예외다. 타입이 안 맞거나 @Valid·@Validated로 붙인 검증 규칙을 어긴 값이 와도 이 예외로 올라온다. Controller 메서드 본문이 실행되기도 전에 걸러지므로, 이걸 잡으면 어떤 필드가 왜 틀렸는지 400과 함께 배열로 돌려줄 수 있다.
BitSet: 여러 개의 참/거짓 값을 boolean 배열 대신 비트(0과 1) 하나하나로 묶어 들고 있는 자바 컬렉션이다. 참/거짓 값 1개를 저장하는 데 boolean은 보통 1바이트(8비트)를 쓰지만 BitSet은 실제로 1비트만 써서, 값이 많을 때 메모리를 훨씬 적게 쓰고 비트 연산(AND·OR 등)으로 집합 연산도 빠르게 할 수 있다.
Blob: 텍스트나 바이너리 데이터를 파일처럼 다룰 수 있게 묶어 놓은 자바스크립트 객체다. new Blob([내용], {type: 「MIME 타입」})처럼 만들면 그 내용에 어떤 종류의 데이터인지를 붙여 하나의 파일 비슷한 덩어리로 만든다. 서버에 파일로 보내거나 다운로드 링크를 만들 때 쓴다.
blob 해시: Git이 파일 하나의 내용만 가지고 계산해서 붙이는 고유한 식별값이다. 내용이 한 글자라도 다르면 이 값도 달라지므로, 두 폴더의 blob 해시를 하나씩 맞춰 보면 파일을 직접 열어 보지 않고도 내용이 똑같은지 다른지 알 수 있다.
BOM: 파일 맨 앞에 몇 바이트를 더 붙여서 "이 파일은 UTF-8로 저장했다"고 알려 주는 표시다(Byte Order Mark). Windows PowerShell 5.1처럼 이 표시가 없으면 파일을 시스템 기본 문자셋(한국어 환경이면 CP949)으로 읽는 프로그램이 있는데, 그 상태에서 UTF-8로 적힌 한글은 파일을 여는 순간부터 깨진 글자로 읽힌다.
cAdvisor: 컨테이너 하나하나가 CPU·메모리·네트워크를 얼마나 쓰는지 재서 Prometheus가 가져갈 수 있는 형태로 내보내는 도구다. 서버 전체가 아니라 컨테이너 단위로 쪼개서 보여주기 때문에, 여러 컨테이너 중 어떤 것이 자원을 많이 쓰는지 가려낼 수 있다.
cascade: 부모 엔티티에 가해진 저장·삭제 같은 작업을 자식 엔티티에도 그대로 이어서 적용하라고 JPA에 거는 설정이다. `cascade = CascadeType.ALL`을 걸어두면 부모를 저장할 때 자식도 함께 INSERT되고, 부모를 지우면 자식도 함께 지워진다. 이 설정이 없으면 자식은 따로 저장하거나 지워야 한다.
CFS · EEVDF: 리눅스의 기본 스케줄러 이름이다. 오래 CFS 였고 지금은 EEVDF(Earliest Eligible Virtual Deadline First)다. 읽고 있는 7.3-rc4 도 EEVDF 인데 파일 이름과 구조체 이름은 아직 fair.c · cfs_rq 라, 이름만 보면 CFS 로 착각하기 쉽다.
CGLIB: 클래스를 상속한 자식 클래스를 프로그램이 도는 중에 만들어 내는 라이브러리다. 스프링이 프록시를 만들 때 쓰는 방법 중 하나다. 이름 끝의 $$ 는 사람이 짓는 이름과 겹치지 않게 기계가 붙이는 표시이고, 마지막 0 은 그 클래스로 몇 번째 만든 자식인지를 뜻한다.
cgroup: 프로세스 묶음이 쓸 수 있는 자원(CPU · 메모리 · I/O)에 상한을 거는 장치다. 도커가 --memory 로 거는 제한이 이것이다.
Checked · Unchecked 예외: 자바의 예외는 둘로 나뉜다. Checked 예외(`Exception`을 바로 상속한 것)는 메서드 선언에 `throws`를 적어야 하고, 부르는 쪽도 `try-catch`로 잡거나 자기도 `throws`로 넘겨야 한다 — 컴파일러가 강제한다. Unchecked 예외(`RuntimeException`을 상속한 것)는 그런 강제가 없어서, 안 잡고 그냥 둬도 컴파일이 된다.
CI: 코드가 저장소에 올라올 때마다 사람이 손으로 확인하지 않아도 자동으로 빌드하고 테스트를 돌려 주는 방식이다. Continuous Integration(지속적 통합)을 줄인 말이다. 테스트가 실패하면 그 자리에서 바로 알려 주기 때문에, 문제가 있는 코드가 모르는 채로 쌓이는 것을 막아 준다.
claim.md: 증명 폴더(proofs/<슬러그>/) 안에 두는 파일 중 하나로, 실험을 돌리기 전에 먼저 쓴다. 증명하려는 주장을 한 문장으로 적고, 근거 종류 중 무엇에 해당하는지와 이 실험이 어떤 표준 글을 받치는지, 그리고 어떤 결과가 나오면 주장이 틀린 것으로 보는지(반증 조건)를 미리 적어 둔다. 결과를 보기 전에 반증 조건을 먼저 적어 둬야 나중에 어떤 수치가 나와도 주장에 맞춰 읽지 않을 수 있다.
claude -p: Claude Code를 대화창 없이 한 번만 돌리는 실행 방식이다. 프롬프트 하나를 명령줄로 흘려 넣으면 Claude가 그 요청을 처리한 결과만 출력하고 끝난다. 사람이 옆에서 주고받지 않아도 되므로, 어떤 입력에 Claude가 실제로 무엇을 받는지 스크립트로 재현해 재는 실험에 쓴다.
Claude Code: 터미널 안에서 돌아가는 Anthropic의 에이전트 도구다. 파일을 읽고 고치고, 명령을 실행하고, 결과를 확인하는 일을 사람이 시키는 대로 스스로 이어서 한다. 이 블로그의 글도 대부분 Claude Code와 대화하며 정한 내용을 담는다.
CLAUDE.md: 프로젝트마다 두는, Claude Code가 작업을 시작하기 전에 항상 읽는 안내 파일이다. 이 저장소가 무엇인지, 글을 어떻게 써야 하는지, 지켜야 할 규칙이 무엇인지가 여기 적혀 있다. 매번 똑같이 설명해야 했던 내용을 한 번만 적어 두고 계속 참조하게 만든 것이다.
CLI: 마우스로 누르는 화면 없이, 글자로 된 명령을 입력해 프로그램을 실행하는 방식이다. Command Line Interface(명령줄 인터페이스)의 줄임말로, 터미널에 명령을 쳐서 프로그램을 돌리는 진입점을 가리킨다.
Clock: 지금 몇 시인지 알려주는 자바 객체다. 코드에서 직접 Instant.now()를 불러 지금 시각을 구하면 테스트를 돌릴 때마다 실행 시각이 달라져 검증이 어렵다. Clock을 하나 두고 그것을 통해서만 지금 시각을 얻게 하면, 테스트에서는 고정된 시각을 주는 가짜 Clock으로 바꿔 끼울 수 있다.
Closes #N: 커밋 메시지에 Closes #38 처럼 적어 두면, 그 커밋이 main 브랜치에 들어가는 순간 GitHub가 38번 이슈를 자동으로 닫아 주는 규칙이다. 사람이 이슈 화면에 따로 들어가 닫기 버튼을 누르지 않아도 되고, 어느 커밋이 그 이슈를 닫았는지도 이슈 화면에 그대로 남는다.
Codex: OpenAI가 만든, Claude Code와 비슷한 역할을 하는 에이전트 도구다. 이 저장소에서는 overlay 이미지를 그리는 것처럼 Claude Code가 직접 하지 않기로 정한 일을 대신 맡기는 데 쓴다.
Command: Service로 들어가는 입력 중 상태를 바꾸는(쓰기) 요청만 담는 그릇이다. 조회(읽기) 요청을 담는 Query와 짝을 이룬다 — 이름만 보고도 그 메서드가 데이터를 바꾸는지 아닌지 알 수 있게 나눈 것이다. CreateOrderCommand처럼 Service 메서드 하나에 필요한 값을 묶어 전달하는 역할만 하고, 스스로 값을 검증하거나 판단하지 않는다.
Comparator: 두 객체 중 무엇을 앞에 둘지 정하는 규칙을 담은 인터페이스다. compare(a, b)가 음수면 a가 앞, 양수면 b가 앞, 0이면 순서가 같다는 뜻이다. 비교 기준을 따로 안 넘기면 그 타입이 원래 가진 compareTo()(자연 순서)를 대신 쓴다.
Content-Type: 본문이 어떤 형식으로 적혀 있는지 알려주는 헤더다. application/json 이면 JSON이고, text/html 이면 HTML이라는 뜻이다. 받는 쪽은 이 값을 보고 본문을 어떻게 읽을지 정한다.
Controller: 바깥에서 온 요청을 제일 먼저 받는 창구다. 가게로 치면 주문을 받는 카운터 직원과 같다 — 손님(요청)이 뭘 원하는지 듣고, 그 일을 처리할 담당자(Service)에게 넘긴 뒤, 돌아온 결과를 다시 손님에게 전달한다. @RestController 나 @Controller 를 붙인 클래스가 이 역할을 한다.
CopyOnWriteArrayList: 쓰기(추가·삭제)가 일어날 때마다 내부 배열 전체를 복사해서 새 배열로 통째로 바꿔치기하는 리스트다. 읽는 스레드는 그 순간 이미 있던 배열만 보기 때문에, 쓰는 중이어도 동기화 없이 안전하게 읽을 수 있다. 쓰기가 드물고 읽기가 훨씬 많은 멀티스레드 상황에 맞고, 쓰기가 잦으면 매번 배열을 통째로 복사하는 비용 때문에 느려진다.
COUNT 쿼리: 조건에 맞는 행이 몇 개인지 개수만 세어서 돌려주는 쿼리다. SELECT COUNT(*) FROM orders WHERE status = 1 은 상태가 1인 주문이 몇 건인지 세라는 뜻이다. 전체 페이지 수를 보여 주는 페이징 화면에서, 실제 데이터를 가져오는 쿼리와 별도로 이 쿼리가 한 번 더 나가는 경우가 많다.
CPU: 명령을 실제로 실행하는 부품이다. x86(대부분의 PC) · ARM(휴대폰, 요즘 Mac)처럼 종류마다 알아듣는 명령이 다르다.
CQRS: 명령(Command, 상태를 바꾸는 요청)과 조회(Query, 상태를 읽기만 하는 요청)를 서로 다른 타입이나 경로로 나누는 설계 방식이다. 하나의 메서드가 쓰기와 읽기를 섞어서 하면 "이 메서드를 부르면 데이터가 바뀌는지"를 코드만 보고 알기 어려운데, 이름이나 타입으로 미리 갈라두면 그 구분이 바로 보인다.
CRUD: 데이터를 다루는 네 가지 기본 동작을 묶어 부르는 말이다. Create(만들기)·Read(읽기)·Update(고치기)·Delete(지우기)의 앞 글자를 땄다.
CSRF: 사용자가 로그인해 둔 사이트에, 그 사용자 몰래 다른 사이트가 요청을 대신 보내게 만드는 공격이다(Cross-Site Request Forgery). 이를 막기 위해 서버는 페이지를 보낼 때마다 CSRF 토큰이라는 임의의 값을 같이 주고, 그 뒤에 오는 요청에 같은 토큰이 실려 있는지 확인한다. 공격자는 이 토큰 값을 알 수 없어서 요청이 거부된다.
CSS: HTML로 만든 화면의 생김새(색, 크기, 배치)를 정하는 언어다. HTML이 「제목이다, 버튼이다」 같은 역할을 정한다면, CSS는 그 제목을 얼마나 크게, 무슨 색으로 보여줄지를 정한다.
CSS 변수: CSS 안에서 값을 한 곳에 저장해 두고 여러 군데서 재사용하는 방법이다. 이름을 하나 지어 색이나 크기 같은 값을 거기에 담아 두면, 다른 곳에서는 그 이름만 불러서 같은 값을 쓸 수 있다. 값을 바꿀 때 CSS 전체를 뒤지는 대신 그 이름 하나만 고치면 된다.
CTA: 방문자가 다음 행동을 하도록 유도하는 버튼이나 바다. "Call To Action"을 줄인 말이다. "상담 신청하기"·"지금 문의하기"처럼 다음에 눌러야 할 행동을 눈에 띄게 보여주는 자리를 가리킨다.
curl: 주소로 요청을 한 번 보내 보는 명령어 프로그램이다. 브라우저를 열지 않고 터미널에서 서버를 찔러 볼 때 쓴다. 이 페이지의 요청 실측은 전부 curl 로 보낸 것이다.
DAG: 방향 비순환 그래프(Directed Acyclic Graph)의 줄임말이다. 간선에 방향이 있고(A에서 B로만 갈 수 있고 B에서 A로는 못 간다), 그 방향을 따라가도 다시 출발점으로 돌아오는 사이클이 생기지 않는 그래프다. 작업 순서처럼 「A를 끝내야 B를 시작할 수 있다」 같은 선행 관계를 표현할 때 쓴다.
DataAccessException: Spring이 여러 DB 기술(JPA·JDBC·MyBatis 등)에서 나는 예외를 한데 묶어 두려고 만든 상위 예외다. 기술마다 원래 던지는 예외 클래스가 다른데, Spring이 그 예외들을 가로채 이 계열의 예외로 바꿔(번역해) 다시 던져 준다. 그래서 Service 코드는 지금 쓰는 DB 기술이 JPA인지 MyBatis인지 몰라도 이 예외 하나만 잡으면 된다.
DataSource: DB에 연결하는 길을 들고 있는 객체다. 이것이 있어야 SQL을 보낼 수 있다. 나는 만든 적이 없고, H2 를 의존성에 적은 것만으로 자동 구성이 만들어 줬다.
DATETIME: 연·월·일·시·분·초를 함께 저장하는 DB 컬럼 타입이다. 자바의 Instant나 LocalDateTime 값을 DB에 저장할 때 이 타입의 컬럼에 담기는데, 어느 시간대 기준인지는 컬럼 자체가 보장하지 않아서 저장하고 읽는 양쪽이 같은 기준을 쓰기로 맞춰 둬야 한다.
DB: 데이터를 표 모양으로 저장해 두고 꺼내 쓰게 해 주는 별도의 프로그램이다. 표 하나에 줄이 쌓이고, 무엇을 넣거나 꺼내려면 SQL 로 말을 걸어야 한다. 프로그램이 꺼져도 남는다는 것이 변수와 다른 점이다.
DB 스키마: 테이블에 어떤 컬럼이 있고 각 컬럼이 어떤 타입인지, PK·FK·unique 제약이 무엇인지 정해 둔 DB의 설계도다. 자바의 클래스가 객체가 가질 필드를 정의하듯 스키마는 테이블이 가질 데이터 모양을 정의한다. JPA의 Entity는 보통 이 스키마 한 장과 1대1로 맞춰 만든다.
DB 연결 세션: 애플리케이션이 DB와 연결을 한 번 맺은 뒤, 그 연결 하나가 살아 있는 동안 유지되는 상태다. 같은 DB에 붙은 연결이라도 세션마다 시간대 같은 설정값을 다르게 가질 수 있어서, 세션의 시간대를 맞춰 두지 않으면 같은 값을 넣어도 연결마다 다른 시점으로 해석된다.
DBA: Database Administrator의 줄임말로, DB 서버 자체를 설치·설정·관리하는 사람이다. 애플리케이션 코드를 짜는 사람과는 역할이 달라서, DB 서버의 시간대나 접속 설정 같은 걸 애플리케이션 코드와 상관없이 바꿀 수 있다.
DDL: Data Definition Language의 줄임말로, 테이블을 만들고(`CREATE TABLE`) 컬럼을 더하거나 바꾸고(`ALTER TABLE`) 지우는(`DROP TABLE`) 것처럼 DB의 구조 자체를 정의하는 SQL 문들을 가리킨다. 데이터를 읽고 쓰는 SQL(`SELECT`·`INSERT` 등)과 달리, DDL은 테이블이 어떤 모양인지를 결정한다.
ddl-auto: Hibernate가 애플리케이션이 뜰 때 스키마를 어떻게 다룰지 정하는 설정값이다. update로 두면 Entity를 보고 테이블을 자동으로 만들거나 고치고, validate로 두면 Entity와 실제 스키마가 맞는지 대조만 하고 다르면 뜨지 않으며, none으로 두면 스키마에 아무 일도 하지 않는다.
DELETE (HTTP): 그 주소가 가리키는 대상을 지우라는 HTTP 메서드다. DELETE /users/1 은 1번 사용자를 지우라는 요청이다. SQL의 DELETE 문과 이름은 같지만 이쪽은 요청의 종류를 가리키고, SQL 쪽은 테이블에서 행을 지우는 명령문이다.
DELETE (SQL): 이미 있는 행을 지우는 SQL 문이다. DELETE FROM users WHERE id = 1 은 id가 1인 행 하나를 지우라는 뜻이고, WHERE 없이 쓰면 테이블의 모든 행이 지워진다. 자식 행이 여럿이면 보통 한 문장이 아니라 행마다 DELETE가 하나씩 나간다.
dispatch: 들어온 요청을 어디로 보낼지 골라 넘기는 일이다. DispatcherServlet 의 이름이 여기서 왔다. 로그의 「"ERROR" dispatch for GET "/error"」는 「에러 때문에 /error 로 한 번 더 넘겼다」는 뜻이다.
DispatcherServlet: 스프링 MVC 의 서블릿 하나다. 모든 요청이 먼저 여기로 들어오고, 여기서 어느 메서드가 답할지 골라 부른 뒤 결과를 응답으로 만든다. 7단계와 8단계가 그 안을 본다.
dmesg: 커널이 남긴 기록을 보는 명령이다. 누가 OOM 으로 죽었는지 같은 것이 여기 찍힌다.
DNS: 도메인 이름을 IP 주소로 바꿔 주는 전화번호부 같은 시스템이다. 브라우저에 example.com 을 치면, 먼저 DNS에게 「이 이름의 IP가 뭐냐」고 물어보고 받은 IP로 실제 연결을 건다.
Docker: 프로그램을 실행에 필요한 코드·라이브러리·설정과 함께 하나로 포장해, 어느 컴퓨터에서 실행해도 똑같이 돌아가게 해 주는 도구다. 「내 컴퓨터에서는 되는데 서버에서는 안 된다」는 문제가 환경 차이 때문에 생기는데, Docker는 포장한 그대로 실행해 그 차이를 없앤다.
Docker Compose: 컨테이너 여러 개를 한 파일에 적어 두고 한 번에 띄우거나 내리는 도구다. 서버 컨테이너와 DB 컨테이너를 따로따로 실행 명령으로 켜는 대신, docker-compose.yml 하나에 둘을 적어 두면 명령 한 번으로 둘 다 뜨고 서로 통신할 수 있게 연결된다.
DOM: 브라우저가 HTML 문서를 읽어서 메모리 안에 나무 모양으로 만들어 둔 것이다. 태그 하나하나가 나무의 가지 하나가 되고, 자바스크립트는 이 나무를 조작해서 화면을 바꾼다. 화면에 글자를 추가하거나 버튼 색을 바꾸는 일은 결국 DOM을 건드리는 일이다.
Domain: 주문·회원처럼 이 프로그램이 다루는 실제 개념을 자바 객체로 옮겨 둔 것이다. DB 테이블과 모양이 비슷할 때가 많지만 같지는 않다 — Entity 가 "DB 에 어떻게 저장할지"를 맡는다면, Domain 은 "이 개념이 지켜야 할 규칙"(예: 주문 금액은 0보다 작을 수 없다)을 자기 안에 담는다.
DPR: 화면의 물리적인 점(픽셀) 수를 CSS가 쓰는 점(픽셀) 수로 나눈 값이다. Device Pixel Ratio를 줄인 말이다. DPR이 3이면 CSS에서 1px이라고 적어도 실제 화면에서는 3×3개의 물리 점으로 그려진다. 그래서 기기의 물리 해상도를 CSS 폭으로 바꾸려면 이 값으로 나눠야 한다.
DTO: 계층과 계층 사이에서 데이터만 담아 옮기는 그릇이다. Data Transfer Object 의 줄임말이다. 택배 상자처럼 안에 든 값을 옮기는 것이 전부고, 상자 스스로 판단하거나 계산하는 로직은 넣지 않는다. Controller 가 받는 요청 값, 돌려주는 응답 값이 보통 DTO 형태다.
E2E 테스트: 사용자가 화면에서 버튼을 누르는 것부터 서버와 DB를 거쳐 결과가 화면에 다시 뜨는 것까지, 전체 과정을 처음부터 끝까지 실제로 흉내 내 보는 테스트다. End-to-End(끝에서 끝까지)의 줄임말이고, 부분이 아니라 전체 흐름이 끊기지 않는지를 확인한다.
Eden · Survivor · Old: Eden은 새 객체가 태어나는 칸, Survivor는 GC에서 살아남은 객체가 옮겨 가는 칸, Old는 여러 번 살아남아 나이가 찬 객체가 옮겨 가는(승격) 칸이다. Eden과 Survivor를 합쳐 Young이라 부르고, Young만 치우는 GC가 Young GC다.
Entity: DB 테이블 한 줄을 자바 클래스 하나로 옮겨 그린 것이다. 클래스에 @Entity 를 붙이면 "이 클래스는 이 테이블과 짝이다"라고 자바와 DB를 이어주는 도구에 알려 주는 셈이고, 그 도구가 필드 하나하나를 테이블의 칼럼과 연결해 준다. 그래서 Entity 의 모양은 테이블 구조를 그대로 따라간다.
EntityManager: JPA가 영속성 컨텍스트를 직접 다루는 저수준 창구다. persist()는 새 객체를 영속 상태로 등록해 INSERT가 나가게 하고, merge()는 분리된 객체의 값을 영속 객체에 복사해 올린다. Spring Data의 save() 메서드는 내부에서 이 EntityManager를 불러, id가 없으면 persist를, id가 있으면 merge를 대신 호출해 준다.
enum: 미리 정해 둔 값들 중 하나만 가질 수 있게 만드는 자바의 타입이다. 예를 들어 요일을 문자열 "월"·"화"로 다루면 오타를 내도 컴파일러가 못 잡아내지만, enum Day { MON, TUE, ... } 로 만들면 그 일곱 개 외의 값은 아예 적을 수가 없다.
EOF: 파일이나 입력이 끝났다는 신호다. End Of File을 줄인 말이다. 프로그램이 따옴표나 괄호의 짝을 찾는 도중에 짝을 못 찾은 채 파일이 끝나 버리면 "unexpected EOF"처럼 에러로 나타난다.
epoch 시간: 1970년 1월 1일 00:00:00(UTC)를 기준으로 그때부터 몇 초(또는 밀리초)가 지났는지로 시각을 표현하는 방식이다. 연·월·일 같은 사람이 읽는 형식이 아니라 정수 하나로 시각을 나타내므로, 시간대 변환 없이 그대로 비교하거나 저장하기 쉽다.
Error Boundary: 자식 컴포넌트에서 에러가 나도 화면 전체가 하얗게 멈추지 않도록, 그 부분만 대신 보여줄 화면을 정해 두는 React 컴포넌트다. 자바의 try-catch와 비슷한 역할을 화면 단위로 한다고 보면 된다. 에러가 나면 정해 둔 「문제가 생겼습니다」 같은 화면을 대신 보여주고 나머지 화면은 그대로 유지된다.
Error 계열: 자바의 실패는 Throwable 아래에서 Exception과 Error 둘로 크게 나뉜다. Exception은 try-catch로 잡아서 복구를 시도할 수 있는 실패고, Error는 OutOfMemoryError(메모리 바닥)·StackOverflowError(재귀가 너무 깊어짐)처럼 프로그램이 정상적으로 계속 돌 수 없는 더 심각한 상황이다. Error는 보통 잡지 않는다 — 잡아도 되돌릴 방법이 없다.
ErrorCode · ErrorCodeException: 실패 하나하나에 붙이는 분류 값과, 그 값을 담아 운반하는 예외다. ErrorCode는 HTTP 상태 코드·도메인·일련번호를 묶어 둔 enum 상수이고, Service나 Domain이 실패를 발견하면 ErrorCodeException.of(ErrorCode.XXX) 형태로 던진다. 호출부는 이 예외 타입 하나만 잡고, 실제로 무슨 실패인지는 안에 든 ErrorCode로 구분한다.
ETag · If-None-Match: 서버가 응답마다 붙이는 「이 내용의 지문」 같은 값이 ETag다. 클라이언트는 다음에 같은 걸 요청할 때 이 값을 If-None-Match 헤더에 실어 보낸다. 서버가 보니 지문이 그대로면 본문을 다시 안 보내고 「바뀐 거 없다」만 돌려줘서 대역폭을 아낀다.
exec: 프로세스의 알맹이를 다른 프로그램으로 덮어쓰는 시스템 콜이다. 껍데기(PID)는 그대로이고 안에서 도는 것만 바뀐다.
ExecutionContext: Spring Batch가 Job이나 Step이 진행되는 동안 쓰는 값을 담아 두는 상자다. Partitioner가 "이 파티션은 코드 A를 맡는다" 같은 값을 여기에 넣어 두면, 그 파티션에서 실행되는 Reader나 Processor가 그 값을 꺼내 쓴다. Step이 끝난 뒤 다음 단계로 넘길 값(처리 건수 등)을 남겨 두는 용도로도 쓴다.
EXPLAIN: 쿼리를 실제로 실행하지 않고, DB가 그 쿼리를 어떤 순서와 방법으로 처리할지 미리 보여 주는 명령이다. 인덱스를 쓰는지, 테이블을 처음부터 끝까지 다 훑는지(풀 스캔) 같은 걸 이 결과로 확인한다. 쿼리가 느릴 때 어디가 문제인지 찾는 첫 단계로 쓴다.
fetch: 자바스크립트에서 서버에 요청을 보내고 응답을 받는 기본 함수다. 브라우저에 내장돼 있어서 따로 설치하지 않아도 쓸 수 있다. 주소를 인자로 넘기면 그 주소로 요청을 보내고, 응답이 오면 그걸로 다음 일을 하게 해 준다.
fetch (Git): 원격 저장소에 새로 생긴 커밋을 내 컴퓨터로 받아오는 일이다. 받아오기만 하고 내 브랜치에 바로 합치지는 않아서, 받아온 뒤에 직접 비교하거나 병합해야 한다. 다른 사람이 올린 변경을 내 저장소에서 보려면 먼저 이 일을 해야 한다.
Figma: 화면 디자인을 그리고 공유하는 도구다. 디자이너가 Figma로 화면 모양을 그려 두면, 개발자는 그걸 보고 같은 모양이 되도록 코드를 짠다. 색상·간격 같은 값을 디자인 토큰으로 관리하는 기능도 있다.
filesort: DB가 인덱스 순서를 그대로 못 쓰고 결과를 따로 메모리나 디스크에서 다시 정렬하는 작업이다. ORDER BY에 쓴 컬럼에 맞는 인덱스가 없을 때 주로 일어나고, EXPLAIN 결과에 이 단어가 보이면 정렬 때문에 느려지고 있다는 신호다. 이름과 달리 요즘 DB는 디스크 파일이 아니라 메모리에서 처리하는 경우가 많다.
final: 자바에서 변수에 한 번 값을 넣으면 다시는 다른 값으로 바꿀 수 없게 막는 키워드다. `private final String name;`처럼 필드에 붙이면, 생성자에서 값을 한 번 넣은 뒤로는 그 필드에 `name = "다른값"`처럼 다시 대입하는 코드가 컴파일조차 되지 않는다.
FK: 한 테이블의 컬럼이 다른 테이블의 PK를 가리키게 걸어 두는 제약이다. orders 테이블의 user_id 컬럼이 users 테이블의 id를 가리키게 해 두면, 그 주문이 어느 회원 것인지 DB가 직접 추적하고 존재하지 않는 회원 번호는 애초에 못 넣게 막는다. 참조당하는 행을 지우려 하면 FK 제약에 걸려 거절된다.
flush: 영속성 컨텍스트에 모아 둔 변경 내용을 DB로 실제로 내보내는 일이다. 객체 값을 바꿔도 그 순간 바로 SQL이 나가지 않고 모아 뒀다가, 커밋 직전 같은 시점에 한꺼번에 내보낸다. 트랜잭션을 커밋하면 자동으로 일어나지만, 커밋 전에 DB 반영 결과가 필요하면 코드에서 직접 부를 수도 있다.
folio: 요즘 커널이 페이지 여러 장을 한 덩어리로 다루려고 도입한 단위다. 예전 코드의 page 자리에 folio 가 들어간 곳이 많다.
force push: 내가 가진 기록으로 원격 저장소의 기록을 강제로 덮어써 올리는 푸시다. 보통 푸시는 원격에 없는 내 커밋만 더하지만, force push는 원격에 이미 있는 커밋을 지우고 내 것으로 바꿔치기한다. 다른 사람이 그 지워진 커밋을 이미 받아 갔다면 그 사람의 기록과 영영 어긋난다.
fork: 지금 프로세스를 그대로 복제해 하나 더 만드는 시스템 콜이다. 복제본은 부모와 거의 같지만 PID 가 다르다.
FormData: HTML 폼의 입력값과 파일을 함께 묶어 서버로 보낼 수 있게 만든 자바스크립트 객체다. new FormData(폼 엘리먼트)로 만들면 그 폼 안의 모든 input 값이 자동으로 담기고, 텍스트뿐 아니라 파일도 그대로 전송할 수 있다. 문자열로만 이루어진 .serialize()와 달리 파일 입력(input type="file")도 포함한다.
front matter: 마크다운 글 맨 위에 줄 세 개짜리 구분선으로 둘러싸 적어 두는, 그 글에 대한 정보 묶음이다. 제목·날짜·카테고리처럼 본문은 아니지만 글을 분류하고 화면에 보여 줄 때 필요한 값들을 여기에 적는다. Jekyll 같은 도구가 이 부분을 읽어서 글 목록이나 페이지 제목을 자동으로 만들어 준다.
G1: JDK 21의 기본 GC 이름이다. 힙을 같은 크기 영역으로 나눠 쓰고 비운다.
GC: 더는 쓸 수 없게 된 객체의 자리를 되찾는 JVM의 일이다(7단계). 방식이 여러 가지이고 JDK 21은 보통 G1을 쓴다. 어떤 참조로도 닿을 수 없는 객체는 다시 쓸 방법이 없어서 치워도 된다.
Git: 여러 사람이 같은 코드를 고치면서도 누가 언제 무엇을 왜 바꿨는지를 전부 기록해 두는 프로그램이다. 파일을 저장할 때마다 그 순간의 모습을 통째로 찍어 두는 사진첩과 비슷해서, 예전 모습으로 언제든 되돌아갈 수 있다. 저장소·커밋·브랜치 같은 개념들이 전부 Git이 다루는 것들이다.
Git Bash: 윈도우에 Git을 설치할 때 함께 깔리는, 리눅스 명령(bash·sed·grep 등)을 윈도우에서도 그대로 쓸 수 있게 해 주는 터미널 프로그램이다. 윈도우 자체 명령 프롬프트와 달리 리눅스 셸 문법을 쓰므로, 리눅스 서버에서 돌릴 스크립트를 윈도우에서 먼저 똑같이 돌려볼 때 쓴다.
git diff: 지금 고친 내용이 이전 모습과 어디가 다른지 줄 단위로 보여 주는 명령이다. 지운 줄과 새로 넣은 줄을 서로 다른 표시로 구분해서 보여 주기 때문에 무엇이 바뀌었는지 한눈에 비교할 수 있다. 커밋하기 전에 실수로 엉뚱한 줄을 고치지 않았는지 확인할 때 쓴다.
git log: 지금까지 쌓인 커밋을 시간 순서로 보여 주는 명령이다. 누가 언제 무엇을 커밋했는지, 커밋 메시지는 무엇이었는지를 목록으로 확인할 수 있어서, 코드가 왜 지금 모양이 됐는지 되짚을 때 쓴다.
git reset: 지금 가리키는 위치를 과거의 다른 커밋으로 되돌리는 명령이다. `--hard` 옵션을 붙이면 그 사이에 작업 트리에 쌓인 변경 내용까지 전부 지운다. 되돌린 뒤에는 그 사이의 커밋과 변경을 다시 꺼낼 방법이 없을 수 있어서, 무엇을 버리는지 먼저 확인하고 써야 한다.
git subtree: 다른 저장소의 파일들을 복사해 지금 저장소 안의 한 폴더로 통째로 가져오는 Git 기능이다. 가져온 뒤에도 원래 저장소와 연결이 끊기지 않아서, 나중에 그쪽에 생긴 변경을 다시 끌어와 반영할 수 있다. 폴더 하나를 다른 프로젝트에도 똑같이 두고 싶을 때, 별도 저장소로 쪼개지 않고 이 방법으로 밀어내기도 한다.
GitHub: Git으로 관리하는 저장소를 인터넷에 올려 두고 여러 사람이 함께 보고 고칠 수 있게 해주는 서비스다. 저장소를 호스팅하는 것 말고도 이슈·Pull Request·Project 보드처럼 협업에 필요한 기능을 같이 제공한다.
GitHub Actions: GitHub에 코드를 푸시하거나 PR을 올리는 것 같은 사건이 생기면 자동으로 정해진 작업을 실행해 주는 GitHub의 기능이다. 이렇게 자동으로 도는 작업 묶음을 워크플로라고 부르고, 테스트 돌리기·빌드하기·배포하기 같은 일을 사람 손 없이 하게 만들 때 쓴다. 어떤 사건에 어떤 작업을 돌릴지는 저장소 안의 설정 파일에 미리 적어 둔다.
GitHub Copilot: 마이크로소프트가 만든 AI 코드 자동완성 도구다. 코드를 치는 동안 다음 줄을 추천해 주는 것이 기본 역할이고, 프로젝트 폴더에 지침 파일을 두면 그 내용을 참고해서 추천한다.
GitHub Pages: GitHub 저장소 안의 파일을 그대로 인터넷에서 볼 수 있는 웹사이트로 만들어 주는 GitHub의 무료 기능이다. 저장소에 HTML이나 Jekyll로 만든 사이트를 올려 두면 GitHub이 그걸 빌드해서 주소 하나로 공개해 준다. 이 블로그도 GitHub Pages로 배포된다.
Gradle: 자바 코드를 컴파일하고, 필요한 라이브러리를 내려받고, 실행 파일로 묶는 과정을 자동으로 해 주는 빌드 도구다. build.gradle 파일에 어떤 라이브러리가 필요한지 적어 두면 Gradle이 알아서 내려받아 연결해 준다.
Grafana: Prometheus 같은 곳에 쌓인 숫자를 그래프로 그려 보여 주는 화면 도구다. 숫자만 쌓여 있으면 사람이 읽기 어려운데, Grafana로 여러 그래프를 한 화면에 모아 두면 서버 상태를 한눈에 보고 이상을 알아챌 수 있다.
grep: 텍스트 파일 여러 개에서 특정 글자나 패턴이 들어간 줄만 찾아 보여 주는 명령이다. 파일을 하나하나 열어 눈으로 훑는 대신, 찾는 말을 넣으면 그 말이 있는 줄과 파일 이름을 바로 알려 준다.
Groovy: 자바 가상머신(JVM) 위에서 도는 프로그래밍 언어다. 문법이 자바와 비슷하지만 세미콜론을 생략할 수 있고, 괄호나 따옴표 없이 메서드를 호출하는 등 더 자유로운 표기를 허용한다. Jenkins의 Jenkinsfile과 Gradle의 build.gradle이 이 언어로 작성된다.
H2: 파일이나 메모리에서 도는 작은 DB다. 따로 설치하지 않고 의존성 한 줄로 쓸 수 있어서 연습에 자주 쓴다.
HandlerMethod: 스프링이 지금 요청을 실제로 처리할 Controller의 메서드를 가리키는 객체다. 핸들러 매핑이 끝나야 만들어지므로, 405·415처럼 주소에 맞는 메서드 자체를 아직 못 찾은 실패에서는 이 객체가 없다.
HandlerMethodArgumentResolver: Controller 메서드의 파라미터를 Spring이 어떻게 채울지 직접 정의하게 해 주는 인터페이스다. @RequestBody나 @PathVariable처럼 Spring이 기본으로 제공하는 파라미터 채우기 방식에, 내가 만든 타입을 위한 방식을 하나 더 추가할 때 이걸 구현한다.
HEAD (Git): 지금 체크아웃해서 보고 있는 커밋을 가리키는 포인터다. 보통 지금 작업 중인 브랜치의 가장 최근 커밋을 가리킨다. HEAD~1처럼 쓰면 HEAD가 가리키는 커밋에서 한 단계 전 커밋을 뜻하고, HEAD~2는 두 단계 전을 뜻한다.
Hibernate: JPA라는 규칙을 실제로 구현해 동작시키는 라이브러리다. 객체를 저장하라고 하면 SQL을 만들어 DB로 보내고, DB에서 읽어 온 행을 다시 객체로 바꿔 돌려준다. Spring Boot에서 JPA를 쓰면 보통 이 라이브러리가 뒤에서 일한다.
HTTP: 브라우저와 서버가 주고받는 말의 규칙이다. GET /test 처럼 「무엇을(방식) 어디에(주소)」를 적어 보내고, 서버는 상태 번호와 본문을 돌려준다. 방식은 GET(가져오기) · POST(보내기) 말고도 PUT · PATCH(고치기) · DELETE(지우기)가 있다.
HTTP 메서드(GET·POST·PUT·PATCH): 요청이 서버에게 「무엇을 하고 싶은지」 알려주는 단어다. GET은 가져오기, POST는 새로 만들기, PUT은 전체를 통째로 바꾸기, PATCH는 일부만 고치기를 뜻한다. 주소가 같아도 메서드가 다르면 서버는 다른 동작을 한다.
HTTP 상태 코드: 응답 맨 앞에 붙는 세 자리 번호로, 요청이 어떻게 됐는지 한눈에 알려준다. 2로 시작하면 성공, 4로 시작하면 「보낸 쪽 잘못」, 5로 시작하면 「서버 쪽 잘못」이다. 본문을 다 읽지 않아도 이 번호만 보고 성공인지 실패인지 먼저 판단할 수 있다.
HTTP 요청 · 응답: 브라우저가 서버에게 보내는 메시지가 요청이고, 서버가 돌려주는 메시지가 응답이다. 요청에는 무엇을 어디로 보내는지(메서드·주소)가 담기고, 응답에는 성공인지 실패인지를 나타내는 상태 코드와 결과가 담긴다. 둘은 항상 짝이다 — 요청 없이 응답만 오는 일은 없다.
HttpApiResponse: 이 저장소가 API 응답을 전부 감싸서 보내는 공통 봉투 타입이다. 성공 여부(success)·HTTP 상태·코드·메시지·실제 데이터를 한 모양으로 묶어, 클라이언트가 성공과 실패를 매번 다른 구조로 파싱하지 않고 한 가지 방식으로만 읽게 한다. HTML을 내려주는 Web 컨트롤러에는 쓰지 않는다 — 봉투에 담을 JSON이 아니라 화면 자체를 돌려주기 때문이다.
HttpClient (java.net.http): 자바 표준 라이브러리에 들어 있는, 진짜 HTTP 요청을 보내는 도구다. MockMvc 처럼 서블릿 컨테이너를 거치지 않고 흉내만 내는 것이 아니라, 실제로 떠 있는 서버에 네트워크로 요청을 보낸다. 그래서 서블릿 컨테이너까지 올라가는 경로를 그대로 재려는 실험에서 쓴다.
HttpMessageNotReadableException: Spring이 요청 본문을 읽어 자바 객체로 바꾸는 과정(역직렬화)에서 실패했을 때 던지는 예외다. 요청 본문이 JSON 형식이 아니거나, 괄호가 안 맞거나, 숫자가 와야 할 자리에 문자열이 와서 애초에 DTO를 만들 수조차 없을 때 생긴다. DTO는 만들어졌지만 필드 값이 규칙에 안 맞는 경우(Bean Validation 실패)와는 다른 예외다.
hydration: 서버가 미리 만들어서 보낸 HTML에, 브라우저에서 자바스크립트가 붙어서 버튼 클릭 같은 동작을 할 수 있게 되는 과정이다. SSR로 받은 화면은 처음엔 그림처럼 보이기만 하고 눌러도 반응이 없는데, hydration이 끝나야 눌렀을 때 실제로 동작한다. 마른 화면에 물을 부어 다시 살아나게 한다는 뜻에서 나온 이름이다.
I/O: 프로그램이 자기 메모리 밖과 데이터를 주고받는 일이다. 디스크에서 파일을 읽거나 네트워크로 다른 서버와 요청·응답을 주고받는 것이 모두 I/O다. CPU 연산보다 훨씬 느려서, 느린 코드의 병목은 대부분 여기서 생긴다.
infra: 도메인 패키지 안에서 DB·외부 API처럼 실제 기술과 맞닿는 부분을 담는 계층이다. Repository 인터페이스를 실제로 구현한 클래스, Entity, Mapper가 여기 산다. domain 계층은 infra가 무엇으로 구현됐는지 모르고, infra가 domain 쪽을 향해 의존한다.
InnoDB: MariaDB·MySQL이 기본으로 쓰는 스토리지 엔진이다. 트랜잭션과 외래 키를 지원한다. 보조 인덱스의 리프에 행의 물리 주소 대신 기본 키(PK) 값을 담아 두는 구조라서, 보조 인덱스로 찾아낸 결과는 사실 PK 값이고 그걸로 실제 행을 한 번 더 찾아간다.
inode: 파일 하나의 정보를 모아 둔 커널 안의 기록이다. 크기 · 주인 · 권한 비트가 여기 있고, 파일 이름은 여기 없다(이름은 디렉터리가 들고 있다). 파일 항목들에서 「알맹이」라고 부르는 것이 이것이다.
INSERT: 테이블에 새 행을 하나 추가하는 SQL 문이다. INSERT INTO users (id, age) VALUES (1, 20) 은 users 테이블에 id와 age를 채운 행을 하나 새로 넣으라는 뜻이다. 자바 코드에서 객체 하나를 새로 저장하면 보통 이 문이 나간다.
instanceof 패턴 매칭: `if (t instanceof ErrorCodeException e)`처럼 instanceof 뒤에 바로 변수 이름을 적는 문법이다. "t가 ErrorCodeException 타입이면, 그 값을 e라는 새 변수에 담아라"는 뜻이다. 예전 자바는 instanceof로 타입만 확인한 뒤 (ErrorCodeException) t로 따로 형변환해야 했는데, 이 문법은 타입 확인과 형변환을 한 번에 하면서 바로 쓸 수 있는 변수까지 만들어 준다.
Instant: 시간을 "1970년 1월 1일부터 몇 초·나노초가 지났는가"로 표현하는 자바 클래스다. 어느 나라, 어느 시간대에서 보든 같은 순간을 가리키므로 "사건이 실제로 언제 일어났는가"를 나타내는 용도로 쓴다. 나노초 단위까지 가지고 있어서, DB가 더 거친 단위(마이크로초 등)로만 저장하면 그 차이만큼 값이 달라질 수 있다.
IP: 어느 기계로 보낼지를 가르는 번호(주소)와 그 규약이다. 127.0.0.1 은 특별히 「내 기계 자신」을 뜻한다.
ItemReader · ItemProcessor · ItemWriter: Spring Batch 의 한 Step 안에서 각자 역할을 맡는 세 부품이다. ItemReader 는 데이터를 한 건씩 읽어 오고, ItemProcessor 가 그 한 건을 검증하거나 다른 타입으로 바꾸고, ItemWriter 가 가공된 데이터를 chunk 단위로 모아 한 번에 저장한다. 세 역할을 나눠 두면 DB 가 아니라 파일에서 읽어 오는 식으로 한쪽만 바꾸기 쉽다.
Jackson (ObjectMapper): 자바 객체와 JSON을 서로 바꿔 주는 라이브러리다. ObjectMapper는 그 안에서 실제로 변환을 담당하는 클래스 이름이다. 스프링은 이 라이브러리를 기본으로 내장하고 있어서, 따로 설정하지 않아도 요청·응답의 JSON 변환이 자동으로 일어난다.
jar: 여러 클래스 파일을 하나로 묶은 압축 파일이다. 압축 파일이라 안에 폴더와 파일이 들어 있고, 클래스 말고 설정 파일도 같이 넣을 수 있다. 남이 만든 라이브러리는 보통 jar 하나로 받는다. 이 페이지에서 「모듈」이라고 부르는 것도 jar 하나를 말한다.
JavaBeans 관례: 자바 클래스의 조회·설정 메서드 이름을 짓는 오래된 약속이다. 필드 값을 꺼내는 메서드는 `getXxx()`(boolean이면 `isXxx()`), 값을 넣는 메서드는 `setXxx()`로 짓는다. Lombok의 `@Getter`나 Jackson의 기본 직렬화 같은 도구들이 바로 이 이름 규칙을 보고 "이건 꺼내는 메서드구나"를 알아채므로, 이름을 다르게 지으면 그 도구들이 메서드를 못 알아본다.
javac: JDK에 든 Java 컴파일러다. .java 파일을 읽어 .class 파일을 만든다. javac 자신도 Java로 짠 프로그램이다.
javac의 여섯 단계: parse(토큰으로 자르고 나무로 쌓기) → enter(클래스 · 메서드 이름 등록) → attribute(이름마다 정체 찾기) → flow(흐름 오류 검사) → desugar(편의 문법 풀기) → generate(바이트 쓰기). 화면 위 줄의 영어 이름이 이것이다.
Javadoc: 자바 코드에서 클래스나 메서드 위에 /** ... */ 로 적는 주석이다. 코드 옆에 그대로 적혀 있어 코드를 볼 때 같이 보이고, 도구로 뽑으면 사람이 읽기 좋은 문서로도 만들 수 있다. 「왜 이렇게 만들었는지」·「어떤 한계가 있는지」 같은 산문을 코드 가까이에 남겨 두는 자리로 자주 쓰인다.
JavaScript: 브라우저 안에서 돌아가는 프로그래밍 언어다. HTML이 화면의 뼈대, CSS가 꾸밈이라면, JavaScript는 버튼을 누르면 무슨 일이 일어나는지 같은 동작을 담당한다. 서버 쪽에서도 Node.js라는 실행 환경으로 같은 언어를 쓸 수 있다.
jdb · javap: JDK에 든 도구다. javap는 .class 파일을 사람이 읽게 풀어 보여 주고, jdb는 실행을 원하는 줄에서 멈춰(중단점) 변수 값을 읽는 디버거다.
JDBC: 자바 프로그램이 어떤 종류의 DB든 같은 방식으로 연결하고 SQL을 주고받을 수 있게 정해 둔 표준 규격이다. MariaDB든 PostgreSQL이든 이 규격을 따르는 드라이버만 있으면 자바 코드는 거의 같은 방법으로 연결해 쓸 수 있다. Hibernate나 MyBatis 같은 도구도 내부에서는 결국 이 규격으로 DB와 통신한다.
JdbcTemplate: SQL 한 줄을 보내고 결과를 받아 오는 일을 대신해 주는 객체다. 만들려면 DataSource 가 먼저 있어야 한다.
JDK: Java로 개발하고 실행하는 데 필요한 것을 한 묶음으로 나눠 주는 것이다. 개발 도구(javac 등) · 표준 라이브러리(String 등) · JVM이 들어 있고, OS · CPU 조합마다 따로 있다.
Jekyll: 마크다운으로 쓴 글들을 모아 정적인 HTML 웹사이트로 만들어 주는 프로그램이다. 글마다 서버에서 매번 새로 만드는 것이 아니라, 미리 전부 HTML 파일로 만들어 두고 그 파일을 그대로 보여 주는 방식이다. GitHub Pages가 이 Jekyll을 기본으로 지원해서, 이 블로그도 Jekyll로 빌드된다.
Jenkins · Jenkinsfile: 코드가 올라올 때마다 빌드·테스트·배포를 자동으로 실행해 주는 서버 프로그램이다. 사람이 매번 손으로 빌드하고 배포하지 않도록 「코드가 올라오면 이 순서대로 실행해라」를 Jenkinsfile이라는 파일에 적어 두면, Jenkins가 그 순서를 대신 실행한다.
JIT: 자주 도는 코드를 실행 도중에 그 CPU의 기계어로 번역해 두는 JVM의 부품이다. C1은 빨리 번역하고, C2는 오래 걸려도 더 빠른 기계어를 만든다. 번역은 따로 도는 컴파일러 스레드가 해서, 번역하는 동안에도 프로그램은 기존 방식으로 계속 돈다.
JNI: C · C++ 코드와 Java 코드가 서로를 부르는 통로다. 런처는 C, JVM은 C++, JDK의 일부는 Java로 짜서 서로 부를 때 이 통로를 쓴다.
JobParametersValidator: Spring Batch의 Job이 시작되기 전에 전달받은 파라미터를 검사하는 인터페이스다. 여기서 검사를 통과하지 못하면 Job이 아예 시작되지 않는다. HTTP 요청에서 Controller 메서드가 실행되기 전에 걸러내는 Bean Validation과 같은 자리를 배치 쪽에서 맡는다.
JobRepository: Spring Batch가 Job과 Step이 어디까지 처리됐는지, 몇 건을 건너뛰었는지 같은 실행 기록을 DB 테이블에 남기고 읽어 오는 저장소다. 이 기록이 있어서 배치가 중간에 멈춰도 어디서부터 다시 시작할지 알 수 있다.
JOIN: 서로 다른 두 테이블을 연결해서 한 번에 조회하는 SQL 문법이다. orders 테이블과 users 테이블을 user_id와 id로 JOIN하면 주문과 그 주문을 한 회원의 이름을 쿼리 한 번으로 같이 가져올 수 있다. JOIN이 없으면 테이블마다 따로 쿼리를 날려서 코드에서 다시 합쳐야 한다.
join fetch: 연관된 데이터를 지연 로딩으로 나중에 따로 가져오지 않고, 처음 조회하는 쿼리에 조인을 포함시켜 한 번에 같이 가져오는 JPQL 문법이다. 주문과 그 주문의 상품 목록을 join fetch로 같이 가져오면 쿼리 한 번으로 둘 다 채워진다. N+1 문제를 피하는 대표적인 방법이지만, 컬렉션 두 개 이상을 동시에 join fetch하면 행 수가 곱해져 늘어나는 문제가 있다.
JPA: 자바 코드에서 메서드 하나만 부르면 그 뒤에서 SQL을 만들어 DB에 보내주는 표준 규칙이다. save나 findById 같은 메서드를 부르면 JPA가 객체 모양을 보고 INSERT나 SELECT를 알아서 만들어 실행한다. 이 규칙을 실제로 구현해 동작시키는 라이브러리가 Hibernate다.
JPA Auditing: Spring Data JPA가 Entity를 저장·수정할 때 생성 시각·수정 시각·작성자 같은 값을 코드로 직접 채우지 않아도 자동으로 채워 주는 기능이다. @CreatedDate·@LastModifiedDate·@CreatedBy 같은 애너테이션을 필드에 붙이고 설정만 켜면 동작한다.
JPQL: 테이블이 아니라 자바 객체(Entity)를 대상으로 적는 JPA의 조회 언어다. SQL은 SELECT * FROM orders 처럼 테이블 이름을 쓰지만 JPQL은 select o from Order o 처럼 클래스 이름을 쓴다. JPA가 이 JPQL을 실제 DB에 맞는 SQL로 바꿔서 실행한다.
jQuery: DOM을 다루기 번거롭던 시절에 많이 쓰이던 자바스크립트 라이브러리다. 짧은 코드로 화면 요소를 찾고 클릭 같은 동작을 연결할 수 있게 해 줬다. 지금은 브라우저 자체 기능과 React 같은 도구가 그 역할을 대신하면서 쓰임이 줄었다.
JSON: 데이터를 글자로 적는 형식이다. {"total": 1} 처럼 중괄호와 따옴표로 적는다. 자바 객체를 이 형식으로 바꿔 내보내는 일은 스프링이 대신 한다.
JSON-LD: 검색 엔진이 페이지 내용을 사람 대신 기계로 읽게끔 JSON 형식으로 적어 넣는 구조화 데이터다. 예를 들어 가게 정보를 LocalBusiness라는 정해진 틀에 맞춰 페이지 안에 적어 두면, 검색 결과 화면에 영업시간이나 평점 같은 정보가 바로 나타난다.
JSONL: 한 줄에 JSON 데이터 하나씩을 적는 파일 형식이다. 보통 JSON은 파일 하나에 값 전체를 한 덩어리로 담지만, JSONL은 줄마다 독립된 JSON이라 파일 전체를 읽지 않고 한 줄씩 끊어 처리할 수 있다. 데이터가 계속 추가되는 목록을 저장할 때 자주 쓴다.
JSX: 자바스크립트 코드 안에 HTML 비슷한 문법을 섞어 쓸 수 있게 해 주는 문법이다. div 태그를 그냥 코드 안에 쓰면 실제로는 자바스크립트 함수 호출로 변환된다. React에서 화면 모양을 코드로 적을 때 거의 항상 이 문법을 쓴다.
JUnit(@Test): 자바 코드로 테스트를 짤 때 쓰는 도구다. 메서드 위에 @Test를 붙이면 그 메서드가 테스트 하나로 인식되고, 빌드 도구(Gradle·Maven)가 @Test 붙은 메서드를 전부 찾아 한 번에 실행해 결과를 모아 보여준다.
JVM: 바이트코드를 읽어 그 컴퓨터에서 실행해 주는 프로그램이다. JDK에 든 JVM의 이름은 HotSpot이고 C++로 짰다.
JVM 명세: .class 파일의 형식과 JVM 명령의 뜻을 정한 공식 문서다(The Java Virtual Machine Specification). §1.2는 그 문서의 1장 2절이라는 뜻이다.
JVM 스택 · 프레임: JVM 스택은 스레드마다 하나씩 있는 메서드 호출 기록이다. 메서드를 부르면 그 메서드의 작업 공간인 프레임이 하나 쌓이고, 메서드가 끝나면 빠진다. 프레임 안에 지역 변수 칸과 피연산자 스택이 들어 있다.
LCP: 최장 공통 접두사(Longest Common Prefix)의 줄임말이다. 두 문자열을 앞에서부터 한 글자씩 비교했을 때 똑같은 글자가 이어지는 구간의 길이를 뜻한다. 예를 들어 「apple」과 「apply」는 앞의 app까지 같아서 LCP가 3이다. 접미사 배열과 함께 쓰면 정렬된 접미사들 사이의 공통 부분을 미리 알 수 있어서 부분 문자열 검색을 빠르게 할 수 있다.
LIMIT · OFFSET: 쿼리 결과 중 몇 번째부터 몇 개만 끊어서 가져오는 SQL 문법이다. OFFSET은 앞에서 몇 개를 건너뛸지, LIMIT은 그다음 몇 개를 가져올지를 정한다. LIMIT 10 OFFSET 20 은 21번째 행부터 10개만 가져오라는 뜻으로, 페이징에서 한 페이지 분량을 끊어 올 때 쓴다.
LocalDateTime: 연·월·일·시·분·초만 가지고 있는 자바 클래스다. Instant와 달리 어느 시간대 기준인지 정보가 없어서, 같은 LocalDateTime 값이라도 어느 나라에서 읽느냐에 따라 다른 순간을 가리킬 수 있다. 그래서 전 세계 어디서든 같은 순간을 정확히 가리켜야 하는 사건 시점에는 쓰지 않는다.
localhost: 지금 이 컴퓨터 자신을 가리키는 주소다. http://localhost:18080 은 「내 컴퓨터의 18080 포트」라는 뜻이라, 밖으로 나가지 않고 같은 컴퓨터 안에서 오간다.
localStorage: 브라우저가 각 웹사이트마다 따로 마련해 둔 저장 공간이다. localStorage.setItem(키, 값)으로 데이터를 저장하면 탭을 닫거나 컴퓨터를 재부팅해도 지워지지 않고 남아 있고, localStorage.getItem(키)으로 다시 꺼내 쓴다. 서버로 전송되지 않고 그 브라우저 안에만 저장된다는 점이 쿠키와 다르다.
Location (헤더): 응답이 가리키는 다른 자원의 주소를 담는 헤더다. 새로 만든 자원을 돌려줄 때는 그 자원을 조회할 수 있는 주소를, 접수한 작업을 돌려줄 때는 그 작업의 진행 상태를 확인할 수 있는 주소를 담는다.
Logger · LoggerFactory: 프로그램이 도는 동안 무슨 일이 있었는지 콘솔이나 파일에 기록(로그)으로 남기는 도구다. LoggerFactory.getLogger(클래스.class)로 그 클래스 전용 Logger 객체를 하나 만들고, logger.info(...)·logger.error(...)처럼 불러서 기록을 남긴다. System.out.println과 달리 레벨을 나눠 찍고, 나중에 어느 레벨까지 볼지 끄고 켤 수 있다.
Lombok: 자바 클래스에서 반복해서 써야 하는 코드(get 메서드, 생성자 등)를 대신 써 주는 도구다. 클래스에 애너테이션 하나만 붙이면 컴파일할 때 그 코드를 자동으로 채워 넣어 준다. 그래서 눈에 보이는 소스 코드는 짧아도 실제로 실행되는 코드에는 그 메서드들이 들어 있다.
LSM: Linux Security Module. rwx 검사를 통과한 뒤에 한 번 더 묻는 자리다. SELinux · AppArmor 가 여기에 꽂혀 「그래도 안 된다」고 말할 수 있다.
lsof: 지금 어느 프로그램이 무엇을 열어 두고 있는지 보여 주는 명령이다.
LTS: Long Term Support의 줄임말로, 다른 버전보다 오래 패치와 보안 업데이트를 받는 버전이라는 뜻이다. 기능이 가장 먼저 들어오는 버전이 아니라, 운영 환경에서 오래 믿고 쓸 수 있도록 지원 기간을 약속한 버전을 고를 때 이 표시를 본다.
main(): 자바 프로그램이 시작되는 메서드다. java 명령으로 프로그램을 돌리면 이 메서드의 첫 줄부터 실행된다.
Mapper · MapperResult · MapperParam: infra 계층에서 DB 값을 Service가 쓰는 Domain 객체로 바꿔 주는 타입들이다. Mapper는 Entity나 MapperResult처럼 DB에서 가져온 값을 Domain으로 바꾸는 클래스다(예 OrderEntityMapper). MyBatis를 쓰는 쪽은 입력과 출력을 아예 다른 타입으로 나누는데, 쿼리에 보내는 입력 값이 MapperParam이고 SQL 결과를 그대로 받는 값이 MapperResult다. 셋 다 infra 밖으로 나가지 않는다.
MariaDB · MySQL: 널리 쓰이는 오픈소스 DB 두 가지다. MariaDB는 MySQL에서 갈라져 나온 것이라 기본 SQL 문법과 쓰는 법이 거의 같고, 둘 중 하나로 배운 것은 대부분 다른 쪽에도 그대로 통한다. 이 블로그의 실측은 주로 MariaDB로 한다.
Maven: Gradle과 같은 일(컴파일·라이브러리 내려받기·실행 파일로 묶기)을 하는 빌드 도구다. pom.xml이라는 파일에 필요한 라이브러리를 적어 두는 방식이 Gradle과 다르다. 보통 한 프로젝트에는 둘 중 하나만 쓴다.
MCP: AI 에이전트가 Jira·Figma·Google Drive 같은 외부 도구나 서비스에 정해진 방식으로 접속할 수 있게 해 주는 공통 규격이다. Model Context Protocol의 줄임말이고, 이 규격을 따르는 연결을 붙이면 에이전트가 그 서비스의 기능을 직접 부를 수 있게 된다.
merge (JPA): 영속성 컨텍스트 밖으로 나간 객체를 다시 영속 상태로 올리는 JPA 메서드다. 넘긴 객체를 그대로 쓰는 게 아니라 같은 식별자를 가진 영속 객체를 새로 찾아오거나 만들어서 값만 옮겨 담고, 그렇게 만든 새 객체를 돌려준다. 그래서 이 메서드가 돌려준 객체와 처음에 넘긴 객체는 서로 다른 인스턴스다.
metadata (Next.js): 페이지의 제목·설명처럼 브라우저 탭과 검색 엔진에 쓰이는 정보를 내보내는 Next.js App Router의 기능이다. 파일에서 metadata라는 이름으로 객체를 내보내면 Next.js가 그 값을 읽어 head 태그 안의 title·meta 태그를 자동으로 만든다.
Mock(모의 객체): 진짜 객체 대신 쓰는 가짜 객체다. 테스트에서 DB나 외부 서버에 실제로 연결하면 느리고 불안정하니까, 「이 메서드를 부르면 이 값을 돌려줘라」라고 미리 정해 둔 가짜로 바꿔치기해서 진짜 연결 없이도 코드가 맞게 동작하는지 확인한다.
MockMvc: 실제로 서버를 띄우지 않고도 Controller 에 가짜 요청을 보내 테스트해 볼 수 있게 해 주는 도구다. 「/orders 로 GET 요청을 보내면 응답 번호가 200이 나오는가」처럼, 진짜 HTTP 통신 없이도 Controller 가 요청을 제대로 처리하는지 코드로 확인할 수 있다.
ms: 밀리초. 1,000분의 1초다. 508ms 는 0.508초다.
MultipleBagFetchException: 한 JPQL 쿼리 안에서 List 타입인 자식 컬렉션 두 개 이상을 동시에 join fetch하려 할 때 Hibernate가 실행 자체를 거부하며 던지는 예외다. 컬렉션 두 개를 한 번에 조인하면 두 컬렉션의 조합만큼 행이 곱해져 늘어나는데(카티션 곱), Hibernate는 List에서는 이 상태를 정리할 방법이 없어 아예 막는다. 컬렉션 타입을 Set으로 바꾸면 예외는 사라지지만 곱해진 행을 DB가 그대로 보낸 뒤 애플리케이션이 조용히 중복을 제거하므로, 근본적인 해법은 하나만 join fetch하고 나머지는 따로 조회하는 것이다.
MyBatis: SQL을 직접 써서 DB와 데이터를 주고받게 도와주는 라이브러리다. JPA처럼 SQL을 자동으로 만들어 주지 않고, 개발자가 SQL문을 미리 써 두면 그 자리에 파라미터를 채워 보내고 결과를 객체에 담아 돌려준다. 복잡한 조회를 손으로 정확히 제어하고 싶을 때 주로 쓴다.
N+1 문제: 목록을 조회하는 쿼리 1번 뒤에, 그 목록 각각에 딸린 연관 데이터를 가져오느라 목록 개수(N)만큼 쿼리가 추가로 나가는 문제다. 주문 10건을 조회한 뒤 주문마다 딸린 상품을 지연 로딩으로 하나씩 가져오면 쿼리가 1 + 10번 나간다. 쿼리 한 번으로 끝낼 일이 N번 더 나가 느려지는 게 문제라서, join fetch 같은 방법으로 미리 한 번에 가져와 막는다.
new와 생성자 호출: 바이트코드에서 new는 힙에 필드가 0인 빈 객체만 만든다. 생성자는 invokespecial 명령이 따로 부른다. invokespecial은 생성자처럼 「바로 이 메서드」를 정확히 부를 때 쓰는 명령이다 — 보통 메서드를 부르는 invokevirtual은 실행 중에 객체의 실제 타입을 보고 고른다. 생성자 이름은 바이트코드에서 <init>이다.
Next.js: React를 바탕으로 만든 프레임워크다. 페이지 라우팅, 서버 사이드 렌더링, 정적 export 같은 걸 React만 쓸 때보다 훨씬 적은 설정으로 할 수 있게 해 준다. 폴더 구조 자체가 라우트가 되는 것이 특징이다 — app/about 폴더를 만들면 /about 주소가 생긴다.
node_exporter: 서버(컨테이너가 아니라 서버 자체)의 CPU·메모리·디스크 상태를 재서 Prometheus가 가져갈 수 있는 형태로 내보내는 프로그램이다. cAdvisor가 컨테이너 단위를 본다면, node_exporter는 그 컨테이너들이 올라가 있는 서버 자체를 본다.
node_modules: npm이 설치한 패키지 파일들이 모이는 폴더다. package.json에 적어 둔 라이브러리를 npm install로 받으면 전부 이 폴더 안에 풀린다. 프로젝트마다 따로 생기고 용량이 크게 불어나는 경우가 많아서, Git이나 Docker 이미지에는 보통 담지 않는다.
NOT NULL 제약: 그 컬럼에는 빈 값(NULL)을 넣을 수 없게 막는 DB 규칙이다. created_at TIMESTAMP NOT NULL 처럼 쓰면 그 컬럼을 비워둔 채 행을 저장하려 할 때 DB가 저장을 거절한다.
npm install (devDependency): package.json에 적힌 라이브러리를 내려받아 설치하는 명령이다. --save-dev 옵션을 붙이면 그 라이브러리를 devDependency로 적어 두는데, 이건 코드를 실행할 때는 필요 없고 개발하거나 빌드할 때만 쓰는 도구라는 뜻이다.
npm 워크스페이스: 여러 패키지를 한 저장소 안에서 관리하면서 서로를 마치 설치된 라이브러리처럼 가져다 쓸 수 있게 해 주는 npm 기능이다. 각 패키지가 package.json을 따로 가지면서도 install은 한 번에 하고, 공용 모듈을 복사하지 않고 그대로 참조할 수 있다.
Object: 모든 클래스의 맨 위 부모 클래스다. extends를 안 쓴 클래스의 부모는 Object이고, 그래서 어떤 객체든 Object 타입으로 받을 수 있다.
OOM Killer: Out Of Memory Killer. 메모리가 정말 없을 때 커널이 프로세스 하나를 골라 강제로 죽이는 장치다. 자바 쪽 OutOfMemoryError 와 다르다 — 그쪽은 JVM 이 던지는 예외이고, 이쪽은 프로세스가 통째로 사라진다.
oom_score: 어느 프로세스를 죽일지 고르는 점수다. 달라고 한 양이 아니라 실제로 붙여 둔 양(RSS)에 스왑과 페이지 표 크기를 더해 매긴다.
OpenAPI · Swagger: API의 생김새(주소·메서드·주고받는 데이터 형식)를 문서로 정리해 두는 규칙이 OpenAPI이고, 그 문서를 사람이 보기 좋은 화면으로 보여주는 도구가 Swagger다. 코드를 안 읽어도 이 화면만 보면 어떤 요청을 보내야 하는지 알 수 있다.
Optional: 값이 있을 수도 없을 수도 있다는 걸 타입으로 드러내는 상자다. 메서드가 그냥 객체를 돌려주면 "값이 없을 때 null 이 온다"는 걸 코드만 보고는 알기 어렵다. Optional<User> 처럼 상자에 담아 돌려주면, 쓰는 쪽이 "비어 있을 수도 있구나"를 바로 알고 값이 없을 때 할 일(.orElseThrow() 등)을 적게 된다.
orca: 여러 AI 에이전트를 터미널 여러 개에 띄워 두고 작업트리·브랜치·질문과 응답을 관리해 주는 오케스트레이션 CLI 도구다. 에이전트가 작업 중 멈춰 사람에게 물어야 할 때 그 요청을 쌓아 두고, 사람이 답할 때까지 기다리게 해 준다. 이 저장소는 여러 에이전트를 동시에 굴릴 때 이 도구 위에서 돈다.
ORDER BY: 쿼리 결과를 특정 컬럼 기준으로 정렬해서 돌려주는 SQL 문법이다. ORDER BY created_at DESC 는 만든 시각이 최신인 것부터 보여 달라는 뜻이다. ORDER BY가 없으면 DB가 어떤 순서로 돌려줄지 보장하지 않는다.
origin (Git): 내가 복제해 온 원격 저장소를 가리키는 기본 이름이다. git clone으로 GitHub의 저장소를 내려받으면 Git이 그 원래 주소에 자동으로 origin이라는 이름을 붙여 둔다. 그래서 git push origin main처럼 origin에 있는 main 브랜치로 보낸다는 식으로 쓴다.
OrNull 접미사: 필드나 매개변수 이름 끝에 OrNull 을 붙여서 그 값이 null 일 수 있다는 걸 이름만 보고 알게 하는 규칙이다. idOrNull 이라고 적어두면 주석이나 타입을 따로 보지 않아도 "이 값은 없을 수도 있다"는 게 드러난다. 반대로 OrNull 이 안 붙은 필드는 항상 값이 있어야 한다는 뜻이다.
orphanRemoval: 부모 엔티티가 들고 있는 자식 컬렉션에서 자식 하나를 빼면(리스트에서 제거하면) DB에서도 그 자식 행을 자동으로 지워 주는 설정이다. `orphanRemoval = true`를 걸면 자식 객체를 더 이상 아무도 참조하지 않는 순간 "고아"로 보고 삭제 SQL을 내보낸다. 걸지 않으면 컬렉션에서 빼도 DB에는 그대로 남는다.
OS: Windows · Linux · macOS처럼 프로그램을 돌려 주는 바탕 프로그램이다. 파일을 여는 요청 방법 같은 것이 OS마다 다르다.
OSR: 한 번 불려 오래 도는 반복문을, 도는 도중에 번역본으로 옮겨 태우는 방법이다(On-Stack Replacement).
package-private: 접근 제어자(public·private 등)를 아무것도 안 적었을 때 생기는 기본 접근 범위다. 같은 패키지 안에서는 어디서든 쓸 수 있지만, 다른 패키지에서는 보이지 않는다. public 처럼 전부에게 열지도 않고 private 처럼 그 클래스 안에만 가두지도 않는, 패키지를 경계로 삼는 중간 단계다.
Page · PageRequest: Spring Data가 제공하는 페이징 결과·조건 타입이다. `PageRequest.of(page, size)`는 "몇 번째 페이지를 몇 개씩 달라"는 조건을 만들고, 그 조건으로 조회하면 결과가 `Page<T>`에 담겨 돌아온다. `Page<T>`는 그 페이지의 데이터 목록뿐 아니라 전체 개수(`getTotalElements()`) 같은 페이징 정보도 함께 가지고 있다.
PagingResult: 목록을 페이지 단위로 끊어 조회한 결과를 담는 그릇이다. 이번 페이지의 데이터 목록(content)과 함께 몇 번째 페이지인지(page), 한 페이지에 몇 건인지(size), 전체가 몇 건인지(totalCount)를 같이 담는다. ServiceResult·ServiceResults와 달리 Service뿐 아니라 Repository도 만들고 반환한다 — 페이징 메타는 조회 그 자체에서만 나오기 때문이다.
PAM: Pluggable Authentication Modules. 우분투에서 비밀번호를 확인하는 쪽 장치다. 커널이 아니라 사용자 공간에 있고, 커널은 그 결과만 받아 자격증명을 바꾼다.
Partitioner: Spring Batch에서 하나의 작업을 여러 조각(파티션)으로 나누는 역할을 맡는 인터페이스다. partition 메서드가 "이름 → ExecutionContext" 짝을 여러 개 만들어 반환하면, Spring Batch가 그 짝의 개수만큼 Step을 독립된 조각으로 실행한다. 몇 개로 나눌지는 Partitioner를 부르는 쪽이 gridSize라는 숫자로 정해 준다.
permitAll: Spring Security 설정에서 특정 주소를 "로그인 없이도 누구나 들어올 수 있다"고 여는 설정이다. requestMatchers("/orders").permitAll() 처럼 쓰면 그 주소는 인증 검사를 거치지 않고 바로 통과된다. 로그인 화면이나 회원가입처럼 애초에 로그인하지 않은 사람도 써야 하는 주소에 붙인다.
PID: 프로세스마다 붙는 번호다. ps 가 줄마다 보여 주는 첫 칸이고, 셸에서 echo $$ 로 자기 번호를 볼 수 있다.
PK: 테이블 안에서 행 하나하나를 서로 구별해 주는 값이다. 한 반 안에서 아무도 안 겹치게 매기는 출석 번호와 같다. 보통 id 컬럼에 1씩 자동으로 늘어나는 번호를 넣어 PK로 쓰고, 한 테이블에는 PK가 하나만 있을 수 있다.
PlatformTransactionManager: 스프링에서 트랜잭션을 실제로 열고 커밋하고 롤백하는 객체의 인터페이스다. Spring Batch의 Step은 청크 하나를 처리할 때마다 이 객체를 통해 트랜잭션을 열고, 그 청크의 쓰기가 끝나면 커밋한다.
Playwright: 브라우저를 사람 대신 자동으로 조작해 E2E 테스트를 해 주는 도구다. 코드로 「이 버튼을 누르고, 이 글자가 보이는지 확인해라」를 적어 두면, Playwright가 실제 브라우저를 띄워 그대로 따라 하고 결과가 맞는지 확인해 준다.
POJO: Plain Old Java Object 의 줄임말이다. 특별한 기술에 묶이지 않은 "그냥 평범한 자바 객체"라는 뜻이다 — 어떤 틀의 클래스를 반드시 물려받아야 하거나 특정 기술 없이는 못 돌아가는 게 아니라, 필드와 메서드만 가진 순수한 자바 클래스다. 그래서 테스트하기 쉽고 다른 곳에 옮겨 쓰기도 쉽다.
Poller (Tomcat): 톰캣의 NIO 연결 처리 부품이다. Acceptor가 받은 연결을 non-blocking 소켓으로 바꿔 Poller에 등록하면, Poller는 그 소켓에 읽을 데이터가 생기는 순간(OPEN_READ)을 감지해 작업 스레드로 넘긴다.
PostgreSQL: 오픈소스로 만들어진 DB 중 하나다. SQL로 데이터를 저장하고 조회한다는 기본은 MariaDB·MySQL과 같지만 세부 문법과 기본 동작이 조금씩 다르다. 어떤 DB를 쓰느냐에 따라 같은 뜻의 SQL도 쓰는 법이 달라질 수 있다.
PR: 내 브랜치에서 고친 내용을 통합 브랜치에 합쳐 달라고 요청하는 것이다. Pull Request를 줄인 말이고, 코드를 바로 합치지 않고 다른 사람이 먼저 코드 리뷰를 할 수 있게 하는 자리다. 리뷰에서 문제가 없으면 그때 머지해서 통합 브랜치에 반영한다.
PreparedStatement: 자바에서 SQL 문장 하나를 실행할 때 JDBC가 만드는 객체다. SQL 틀을 미리 짜 두고 값만 바꿔 여러 번 실행할 수 있게 해 준다. 이 객체가 몇 개 만들어졌는지 세면 실제로 DB에 보낸 SQL 문장이 몇 개였는지 알 수 있다.
principal: Authentication 객체 안에 담긴 "로그인한 사람이 누구인가"를 나타내는 값이다. 로그인 방식(아이디·비밀번호, JWT, 소셜 로그인)에 따라 실제로 들어가는 타입이 다르다 — 숫자 ID 문자열만 들어 있을 수도, 사용자 정보를 담은 객체 전체가 들어 있을 수도 있다.
Prometheus: 서버와 프로그램의 상태를 숫자로 주기적으로 모아 쌓아 두는 도구다. 「CPU가 몇 퍼센트 쓰였나」, 「요청이 초당 몇 번 왔나」 같은 숫자를 일정 간격마다 가져다 시간순으로 저장하고, 나중에 그래프로 보거나 이상하면 알림을 보내는 데 쓴다.
Promise: 자바스크립트에서 나중에 끝날 작업의 결과를 담아 두는 객체다. `fetch(...)`처럼 시간이 걸리는 작업은 결과를 바로 돌려주지 못하는 대신 Promise를 돌려주고, `.then(결과 => 할 일)`로 그 결과가 오면 할 일을 이어 붙인다. `.then()`을 여러 번 이어 붙이는 것을 Promise 체이닝이라고 부른다.
PromQL: Prometheus에 쌓인 메트릭한테 「이 숫자를 보여 달라」고 묻는 질의 언어다. SQL이 DB 테이블에 조건을 걸어 데이터를 뽑아내는 것처럼, PromQL은 쌓인 메트릭에 조건을 걸어 「최근 5분간 평균 CPU 사용률」 같은 값을 계산해 낸다.
props: 부모 컴포넌트가 자식 컴포넌트에게 넘겨주는 값이다. 메서드를 호출할 때 인자를 넘기는 것과 비슷하다 — 부모가 값을 적어 보내면 자식 컴포넌트 안에서 그 값을 props로 받아서 쓴다. 자식 쪽에서는 props를 직접 바꾸지 않고 받은 그대로 읽기만 한다.
pty: 터미널 화면을 흉내 내어 프로그램이 사람과 대화하듯 입출력을 주고받을 수 있게 해 주는 가상 장치다. pseudo-terminal의 줄임말이다. 어떤 프로세스에 pty가 붙어 있으면 터미널 화면이 떠 있다는 뜻이고, 없으면 화면 없이 백그라운드로만 도는 상태라는 뜻이다.
Python: 자바와는 다른 문법을 쓰는 프로그래밍 언어다. 중괄호 { } 대신 들여쓰기로 코드 블록을 가르고, 줄 끝에 세미콜론을 안 붙인다. 변수를 쓸 때 자바의 int나 String 같은 타입 선언을 안 적어도 되고, 리스트는 대괄호 [ ]로 만든다. 이 블로그에서 Python 코드가 나오면 자바와 다른 점만 그 자리에서 짚어준다.
React: 화면을 작은 조각(컴포넌트) 단위로 나눠서 만들고 조립하는 자바스크립트 라이브러리다. 데이터가 바뀌면 화면에서 바뀐 부분만 찾아서 자동으로 다시 그려 준다. 버튼, 목록, 카드 같은 화면 조각을 각각 컴포넌트로 만들어 재사용한다.
record: 값을 담아 옮기기만 하는 클래스를 짧게 쓰게 해 주는 자바 문법이다. record Point(int x, int y) 한 줄만 적으면 생성자·get 메서드 등이 자동으로 생긴다. 한번 만들면 값을 못 바꾸게 되어 있어서, DTO 처럼 「데이터만 옮기면 되는」 자리에 자주 쓴다.
refreshContext: run() 안의 한 걸음이다. 자동 구성을 정하고 빈을 전부 만들고 톰캣까지 올리는 일이 이 한 걸음 안에서 일어난다. 이름은 「다시 채운다」는 뜻이지만 처음 띄울 때도 같은 메서드를 쓴다 — 「다시」로 읽지 않는다.
Repository (Spring): DB 에 데이터를 저장하거나 꺼내오는 일만 맡는 창구다. Service 는 「이 조건에 맞는 데이터를 달라」고만 말하고, 실제로 SQL 을 날리고 결과를 객체로 바꾸는 일은 Repository 가 한다. 그래서 Service 코드는 DB 가 MySQL 이든 다른 것이든 몰라도 된다.
ResponseEntity: Controller 메서드가 돌려주는 값을 감싸는 상자로, 응답 본문뿐 아니라 응답 번호(200·404 등)와 헤더까지 함께 담을 수 있다. 그냥 객체만 돌려주면 응답 번호가 항상 200으로 고정되는데, ResponseEntity.status(201).body(값) 처럼 쓰면 상황에 맞는 응답 번호를 직접 고를 수 있다.
REST API: API를 만드는 방식 중 하나다. 다루는 대상 하나를 주소 하나로 가리키고, 그 대상에 무엇을 할지는 HTTP 메서드(GET·POST·PUT·DELETE)로 나눈다. GET /users/1 은 1번 사용자를 가져오고 DELETE /users/1 은 1번 사용자를 지운다 — 주소는 같아도 메서드가 다르면 하는 일이 다르다.
RestClientException 계열: RestTemplate·RestClient로 외부 API를 부를 때 스프링이 던지는 예외 집안이다. 맨 위에 RestClientException이 있고, 연결이 안 되거나 응답이 늦으면 그 아래 ResourceAccessException이, 상대가 4xx·5xx 상태 코드로 응답하면 그 아래 RestClientResponseException이 난다. 상태 코드는 정상인데 응답 본문을 객체로 바꾸다 실패하면 이 둘 중 어디에도 안 걸리고 RestClientException 그대로 올라온다.
RFC: 인터넷 프로토콜이나 데이터 형식을 국제적으로 합의해 적어 둔 표준 문서다. HTTP의 각 메서드가 "무엇을 해야 하는가"도 RFC 문서가 정의한다 — PATCH가 "일부만 고치는 요청"이라는 뜻도 그 RFC에 적혀 있다.
root: 번호가 0 인 계정이다. 권한 검사를 거의 다 통과해서 무엇이든 할 수 있다. 우분투를 설치하면 처음부터 있는 계정이고, 내 계정과는 별개다.
RSS: 실제로 물리 메모리가 붙어 있는 양이다. VmRSS · anon-rss 도 같은 것을 가리킨다. 달라고만 한 양(VmSize)과는 다르다.
run(): SpringApplication.run(...) 을 말한다. 스프링 부트 프로그램의 main() 이 부르는 단 한 줄이고, 이 한 줄이 끝나면 서버가 요청을 받을 수 있는 상태가 된다.
rwx: 읽기(r) · 쓰기(w) · 실행(x) 권한이다. 주인 · 그룹 · 나머지 셋으로 나뉘어 아홉 자리가 된다 — ls -l 의 rw-r--r-- 가 그것이다.
SecurityContext: Spring Security가 "지금 요청을 보낸 사람이 누구로 인증됐는가"를 담아 두는 저장소다. 로그인 필터가 인증에 성공하면 그 결과를 여기 넣어 두고, 이후 코드 어디서든 SecurityContextHolder.getContext()로 꺼내 쓸 수 있다.
SELECT: 테이블에서 조건에 맞는 행을 꺼내 오는 SQL 문이다. SELECT * FROM users WHERE id = 1 은 users 테이블에서 id가 1인 행을 전부 가져오라는 뜻이다. 조회만 하고 데이터를 바꾸지는 않는다.
SELinux: LSM 에 꽂히는 보안 모듈 가운데 하나다. 프로세스와 파일에 붙은 이름표(label)를 보고 정책표와 맞춰 허용 여부를 정한다.
Service: Controller 가 넘긴 일을 실제로 처리하는 담당자다. 「주문을 넣는다」면 재고를 확인하고 DB 에 기록하는 등 진짜 업무 절차가 여기 들어간다. @Service 를 붙인 클래스가 이 역할을 맡고, 이 계층을 묶어 「서비스 계층」이라고 부른다.
ServiceResult: Service 메서드가 Domain을 곧바로 돌려주지 않고 한 겹 감싸는 그릇이다. 지금은 안에 값 하나(data)만 들어 있지만, 나중에 페이징 개수처럼 값 말고 더 알려줘야 할 정보가 생겨도 Service의 반환 타입 모양을 바꾸지 않고 이 그릇 안에 추가할 수 있다. 단건은 ServiceResult, 여러 건은 ServiceResults를 쓴다.
ServletException: 서블릿 컨테이너가 서블릿을 실행하다가 문제가 생겼을 때 던지는 예외다. 서블릿 안에서 던진 예외를 서블릿 컨테이너가 이 타입으로 감싸 다시 던지는 경우가 있어서, 원래 어떤 예외였는지는 이 예외의 cause(원인)를 봐야 알 수 있다.
SessionFactory: Hibernate가 DB와 연결을 맺고 끊는 방법을 통째로 알고 있는 객체다. 어떤 DB에 어떻게 붙을지, 쿼리를 어떻게 만들지 같은 설정을 한 번 만들어 두면, 실제 DB 작업을 할 때마다 이 객체에서 연결(Session)을 하나씩 꺼내 쓴다. 보통 애플리케이션 전체에서 하나만 만들어 두고 계속 재사용한다.
setter: 객체 안의 필드 값을 밖에서 바꿀 수 있게 열어 주는 메서드다. 보통 `setName(String name)`처럼 `set`으로 시작하고, 호출하면 그 순간 필드 값이 바뀐다. 생성자와 달리 객체를 만든 뒤에도 아무 때나 호출할 수 있어서, 언제 어떤 상태로 바뀌었는지 코드 전체를 봐야 알 수 있게 만든다.
setuid: 프로세스의 uid 를 바꾸는 시스템 콜이다. 로그인 프로그램이 root 로 시작해 확인을 마친 뒤 내 uid 로 내려앉을 때 쓴다.
sk_buff: 커널이 네트워크 패킷 하나를 담아 나르는 구조체다. 계층을 오르내리는 동안 같은 것이 계속 전달된다.
SkipListener: Spring Batch에서 아이템 하나가 skip될 때마다 불리는 콜백 인터페이스다. 읽기·처리·쓰기 중 어느 단계에서 skip이 났는지에 따라 onSkipInRead·onSkipInProcess·onSkipInWrite 중 하나가 불린다.
SpEL: Spring Expression Language의 줄임말로, 문자열 안에 #{ } 를 써서 그 안의 식을 스프링이 실행 시점에 계산하게 하는 문법이다. #{stepExecutionContext['code']} 라고 쓰면 "지금 실행 중인 Step의 ExecutionContext에서 code라는 키의 값을 꺼내라"는 뜻이다.
Spotless(코드 포매터): 코드의 들여쓰기·줄바꿈·import 순서 같은 모양을 자동으로 맞춰 주는 도구다. 사람마다 코드 모양을 다르게 쓰면 같은 파일을 여러 명이 고칠 때마다 줄바꿈 차이로 diff가 지저분해지는데, Spotless를 빌드 과정에 끼워 두면 모양이 안 맞는 코드를 자동으로 고치거나 빌드를 막는다.
Spring: 자바로 서버를 만들 때 쓰는 큰 도구 상자다. 빈을 만들어 대신 관리해 주고, 요청이 오면 알맞은 메서드로 연결해 주는 등 반복해서 짜야 할 일들을 미리 해 둔 틀이다. 나는 이 틀 위에 내 코드만 올려놓으면 된다.
Spring Batch: 대량의 데이터를 한꺼번에 처리하는 작업(예: 매일 밤 전체 회원에게 포인트를 적립하는 일)을 안전하게 돌리기 위한 틀이다. 전체 작업을 Job 이라 부르고, Job 은 여러 Step 으로 나뉜다. 한 Step 은 데이터를 한 건씩 읽는 게 아니라 chunk(묶음) 단위로 읽고 처리하고 저장해서, 도중에 실패해도 어디까지 처리했는지 알 수 있다.
Spring Boot: Spring 을 바로 쓸 수 있게 설정까지 미리 끝내 둔 상품이다. 원래 Spring 만 쓰면 어떤 부품을 쓸지, 어떻게 연결할지 하나하나 적어야 하는데, Spring Boot 는 많이 쓰는 조합을 기본값으로 정해 둬서 의존성만 추가하면 바로 서버가 뜬다.
Spring Data: 저장소(Repository) 인터페이스 코드를 직접 짜지 않아도 되게 해 주는 Spring의 기능이다. `findByStatus(status)`처럼 메서드 이름만 정해 두면, 그 이름을 읽고 "status 컬럼으로 조회하는 쿼리구나"라고 해석해 실제 쿼리를 대신 만들어 실행해 준다. JPA와 묶어 쓰면 Spring Data JPA라고 부른다.
Spring Security: "이 요청을 보낸 사람이 누구인지"(인증)와 "이 사람이 이 작업을 해도 되는지"(인가)를 처리해 주는 Spring 의 부가 기능이다. 로그인 확인, 권한에 따라 주소별로 접근을 막는 일 등을 내가 직접 다 짜지 않고 정해진 방식대로 설정만 하면 되게 해 준다.
SQL: DB에 무엇을 하라고 보내는 말이다. select count(*) from orders 는 「orders 표에 줄이 몇 개냐」는 뜻이고, insert into orders 는 「orders 표에 줄을 하나 넣어라」는 뜻이다.
SQL 인젝션: 사용자가 보낸 값이 검증 없이 SQL 문자열에 그대로 이어 붙여져서, 원래 의도한 조건이 아니라 공격자가 심어 넣은 다른 명령으로 바뀌어 실행되는 보안 문제다. 값을 문자열로 그대로 이어 붙이는 자리가 있으면 그 자리가 공격이 들어올 수 있는 통로가 되는데, 그 통로를 주입 표면이라고 부른다.
SSR (서버 사이드 렌더링): 브라우저가 아니라 서버에서 미리 화면(HTML)을 완성해서 보내 주는 방식이다. 브라우저는 빈 페이지를 받아 자바스크립트로 채우는 대신, 이미 내용이 채워진 페이지를 받아서 바로 보여준다. 처음 화면이 뜨는 속도와 검색 엔진이 내용을 읽기 쉬운 점이 장점이다.
static 초기화: 클래스의 static 필드에 값을 넣고 static { } 블록을 도는 일이다. 클래스마다 처음 쓰기 직전에 한 번만 한다.
StepExecutionListener: Spring Batch의 한 Step이 시작하기 전과 끝난 뒤에 불리는 콜백 인터페이스다. 웹 요청에서 DispatcherServlet이 모든 요청을 거쳐 가듯, 배치에는 DispatcherServlet이 없는 대신 이 리스너가 그 Step을 지나는 모든 실행을 거쳐 간다. 그래서 Step이 끝난 뒤 실패 목록을 모아 로그로 남기는 자리로 쓴다.
strace: 프로그램이 커널에 무슨 부탁을 하는지 옆에서 받아 적어 주는 명령이다.
su: 다른 계정으로 갈아타는 명령이다. sudo 가 명령 하나만 그 권한으로 돌리는 것과 다르다.
sudo: 명령 하나를 root 권한으로 실행하는 명령이다. sudo useradd 처럼 앞에 붙여 쓴다.
super: 자식 클래스 안에서 부모의 메서드를 부를 때 쓰는 말이다. 자식이 place() 를 덮어쓰고 그 안에서 원래 구현을 부르려면 super.place() 라고 적는다.
task: 커널이 CPU 를 나눠 줄 때 세는 단위 하나다. 커널 눈에는 프로세스든 스레드든 똑같이 task 하나다.
task_struct: 커널이 실행 흐름 하나를 나타내는 기록이다. 커널에게는 프로세스와 스레드가 둘 다 이것이고, 무엇을 공유하느냐만 다르다.
TaskExecutor: 스프링이 작업을 다른 스레드에 맡길 때 쓰는 인터페이스다. ThreadPoolTaskExecutor는 그 구현체 중 하나로, corePoolSize(기본으로 띄워 둘 스레드 수)·maxPoolSize(바빠졌을 때 최대로 늘릴 수 있는 스레드 수)·queueCapacity(스레드가 모두 바쁠 때 작업을 대기시킬 큐의 크기)를 설정해서 만든다.
Tasklet: Spring Batch에서 Step 하나를 ItemReader·ItemProcessor·ItemWriter 조합이 아니라 직접 짠 코드 한 덩어리로 실행하고 싶을 때 쓰는 인터페이스다. execute 메서드 한 번의 실행이 그 Step 전체를 맡는다. 데이터를 한 건씩 읽고 쓰는 처리가 아니라 "집계 결과를 모아 보고서 하나를 만든다"처럼 한 번만 실행하면 되는 작업에 쓴다.
TCP: 끊기지 않고 순서가 지켜지는 연결을 만들어 주는 규약이다. HTTP 가 그 위에서 돈다.
Testcontainers: 테스트를 실행할 때 진짜 DB를 Docker 컨테이너로 잠깐 띄웠다가 테스트가 끝나면 지워 주는 자바 라이브러리다. 가짜 DB가 아니라 실제로 쓰는 것과 같은 DB로 테스트하므로 DB마다 다르게 동작하는 부분까지 믿고 검증할 수 있다. 테스트를 돌릴 때마다 컨테이너를 새로 띄우므로 이전 테스트가 남긴 데이터에 영향받지 않는다.
TestExecutionListener: 테스트가 시작하기 전과 끝난 뒤에 끼어들어 추가 작업을 할 수 있게 해 주는 스프링의 확장 지점이다. 테스트를 대신 실행하지는 않고 테스트가 도는 것을 옆에서 지켜보다가, 끝났을 때 "이 테스트가 어느 계약과 연결됐고 통과했는지" 같은 정보를 모아 처리하는 자리로 쓴다.
Thymeleaf: Spring Boot에서 서버가 HTML을 만들어 브라우저로 내려보낼 때 쓰는 템플릿 엔진이다. th:text, th:if 같은 속성을 HTML 태그에 붙여 두면, 서버가 그 자리에 실제 데이터를 채워 완성된 HTML을 만든다. 브라우저가 아니라 서버에서 미리 완성된 HTML을 만들어 보낸다는 점이 React 같은 방식과 다르다.
TLB: CPU가 가상 주소를 실제 물리 주소로 바꿀 때마다 매번 느린 변환 과정을 반복하지 않도록, 최근에 바꾼 주소 몇 개를 기억해 두는 작은 캐시다. Translation Lookaside Buffer의 줄임말이다.
TypeHandler: MyBatis가 자바 값과 DB 컬럼 값을 서로 바꿀 때 쓰는 변환기다. SQL에 넣을 자바 값을 DB가 알아듣는 형태로 바꾸고, DB에서 읽은 값을 다시 자바 타입으로 되돌리는 역할을 한다. JPA가 Hibernate 안에서 이 변환을 자동으로 해 주는 것과 달리, MyBatis는 자바 타입과 DB 타입이 기본으로 안 맞을 때 이 변환기를 직접 지정해야 한다.
TypeScript: JavaScript에 타입을 붙일 수 있게 확장한 언어다. 자바의 변수처럼 「이 값은 숫자다, 이 값은 문자열이다」를 미리 적어 두면, 실행하기 전에 타입이 안 맞는 실수를 미리 잡아 준다. 코드는 결국 JavaScript로 변환돼서 브라우저에서 돌아간다.
uid · gid: 계정 번호(uid)와 그룹 번호(gid)다. 커널은 이름이 아니라 번호로 사람을 가른다 — id 를 치면 uid=1000(tghan) 처럼 둘 다 보인다. euid 는 권한을 볼 때 쓰는 번호로, 보통은 uid 와 같지만 sudo 처럼 잠깐 남이 될 때만 달라진다.
umask: 새로 만드는 파일에서 미리 빼 둘 권한이다. 프로그램이 0666 으로 달라고 해도 실제로는 rw-r--r-- 가 되는 것이 이것 때문이다.
unique 제약: 한 컬럼(또는 몇 개 컬럼을 묶어)에 같은 값이 두 번 들어오지 못하게 막는 DB 규칙이다. 이메일 컬럼에 unique 제약을 걸어 두면, 이미 쓰이는 이메일로 가입하려 할 때 애플리케이션 코드가 막지 않아도 DB가 저장을 거절한다. PK는 항상 unique 제약을 포함하지만, PK가 아닌 컬럼에도 따로 걸 수 있다.
UPDATE (SQL): 이미 있는 행의 값을 바꾸는 SQL 문이다. UPDATE users SET status = 1 WHERE id = 1 은 id가 1인 행의 status를 1로 바꾸라는 뜻이고, WHERE 없이 쓰면 테이블의 모든 행이 다 바뀐다. JPA를 쓰면 더티체킹이 이 문을 대신 만들어 보내 준다.
UPSERT: UPDATE와 INSERT를 합쳐 부르는 말이다. 먼저 UPDATE를 시도해서 바뀐 행이 있으면(이미 데이터가 있으면) 그대로 끝내고, 바뀐 행이 0건이면(데이터가 없으면) 그때 INSERT로 새로 넣는다. 같은 데이터를 여러 번 보내도 중복으로 쌓이지 않게 해 준다.
URI: 자원 하나의 위치를 가리키는 주소 표기법이다. /orders/42 처럼 도메인 뒤의 경로만 적을 수도 있고, https://api.example.com/orders/42 처럼 전체 주소를 적을 수도 있다.
UseCase: 「이 프로그램으로 할 수 있는 일 하나」를 가리키는 말이다 — 예를 들어 「주문하기」, 「주문 취소하기」가 각각 하나의 UseCase 다. 코드에서는 보통 인터페이스로 만들어 Controller 가 이것만 보고 Service 를 부르게 하고, 실제 처리 절차는 그 인터페이스를 구현한 Service 클래스 안에 둔다.
UUID: 전 세계 어디서 만들어도 거의 겹치지 않는 긴 무작위 값이다. UUID.randomUUID()를 부르면 자바가 매번 새 값 하나를 만들어 준다. 번호를 1부터 순서대로 매기지 않아도 되고, 누가 어디서 몇 개를 만들었는지 몰라도 서로 안 겹친다는 것만 보장되면 될 때(추적 키, 임시 식별자 등) 쓴다.
VARCHAR: 길이가 정해지지 않은 문자열을 담는 DB 컬럼 타입이다. VARCHAR(20)이면 최대 20자까지 담을 수 있고, 실제로 들어간 글자 수만큼만 공간을 쓴다. 이름 · 코드처럼 길이가 저마다 다른 문자열 컬럼에 흔히 쓴다.
VFS: Virtual File System. 디스크가 무엇이든 · USB 든, 종류가 달라도 똑같은 open · read 로 다루게 해 주는 층이다. 자바의 인터페이스와 같은 자리다.
Vite 환경변수 (import.meta.env): Vite로 빌드한 프로젝트에서 환경변수를 읽는 문법이다. `process.env` 대신 `import.meta.env.VITE_API_BASE_URL`처럼 쓰고, 이름이 VITE_로 시작하는 환경변수만 이렇게 읽을 수 있다. `import.meta.env.MODE`는 지금 실행 중인 환경 이름(development·production 등)을 담고 있다.
vma: 주소 몇 번부터 몇 번까지는 이 프로세스가 써도 된다고 커널이 적어 둔 한 줄이다. 달라고만 하고 아직 안 쓴 메모리는 이 줄만 있고 실제 메모리는 안 붙어 있다.
VmSize: 프로세스가 달라고 해서 잡아 둔 주소의 총량이다. 실제로 메모리가 붙어 있는 양(RSS)과 다르고, 보통 훨씬 크다.
VO: Value Object의 줄임말이다. 값 자체가 그 객체의 정체성이 되는 객체로, 같은 값을 가지면 같은 것으로 취급한다. DTO가 계층과 계층 사이에서 데이터를 실어 나르는 상자라면, VO는 그렇게 옮겨 온 값을 가지고 애플리케이션 안에서 실제로 쓰는 값 그 자체를 표현한다.
WHERE: 쿼리에서 어떤 행만 대상으로 할지 조건을 적는 자리다. WHERE id = 1 은 id가 1인 행만 고르라는 뜻이고, SELECT뿐 아니라 UPDATE·DELETE에도 붙여서 조건에 맞는 행만 바꾸거나 지운다. WHERE를 빼고 UPDATE나 DELETE를 쓰면 테이블의 모든 행이 대상이 된다.
XML: 데이터를 꺾쇠 괄호로 감싼 태그로 적는 형식이다. `<name>값</name>`처럼 여는 태그와 닫는 태그 사이에 값을 넣는다. HTML과 비슷한 모양이고, 설정 파일이나 테스트 결과 보고서처럼 구조가 있는 데이터를 저장할 때 쓴다.
YAML: 들여쓰기로 설정값을 계층 구조로 적는 글자 형식이다. GitHub Actions의 워크플로나 스프링 설정 파일처럼, 사람이 읽기 쉬운 형태로 옵션을 적어 두고 프로그램이 그걸 읽어 동작을 결정할 때 쓴다.
µs: 마이크로초, 100만분의 1초다. ms(밀리초)는 1,000분의 1초, ns(나노초)는 10억분의 1초다. System.nanoTime()은 ns로 돌려줘서 1,000으로 나누면 µs가 된다.
가상 메모리: 프로세스가 보는 주소다. 실제 물리 메모리 주소와 다르고, 커널이 둘을 이어 준다. 그래서 -Xmx4g 로 잡아도 그 순간 물리 메모리를 4GB 쓰지는 않는다.
객체: new로 힙에 만든 덩어리다. 필드 값을 담는다.
게이트: 배포하기 전에 반드시 통과해야 하는 검사 관문이다. 검사 하나라도 실패하면 배포 자체가 진행되지 않게 막아서, 문제가 있는 코드나 어긋난 내용이 그대로 공개되는 것을 미리 차단한다. 그냥 알려만 주고 넘어가는 경고와 달리, 게이트는 실패하면 실제로 멈춘다.
격리 수준: 여러 트랜잭션이 동시에 도는 동안 한 트랜잭션이 다른 트랜잭션이 아직 커밋 안 한 변경을 얼마나 볼 수 있는지 정해 두는 DB 설정이다. 엄격하게 막을수록 서로 안 보여서 안전하지만 그만큼 기다리는 일이 늘고, 느슨하게 풀수록 빠르지만 남이 중간에 바꾼 값을 보게 될 수 있다. MariaDB는 REPEATABLE READ라는 수준을 기본으로 쓴다.
경쟁 상태: 두 개 이상의 스레드가 같은 데이터를 동시에 건드릴 때, 실행 순서에 따라 결과가 달라져 버리는 상황이다. 예를 들어 두 스레드가 동시에 같은 숫자를 1씩 늘리면, 운이 나쁘면 한 번만 늘어난 것처럼 결과가 나온다. 동기화(자물쇠)로 한 번에 하나씩만 건드리게 막아서 이 문제를 피한다.
계약: 무엇을 통과로 보고 무엇을 실패로 볼지를 미리 글로 정해 둔 약속이다. API 계약이면 요청과 응답이 어떤 모양이어야 하는지를, 테스트 계약이면 어떤 조건에서 어떤 결과가 나와야 하는지를 미리 정해 둔다. 계약이 있으면 구현을 보지 않고도 계약 문장만으로 통과와 실패를 가를 수 있다.
계층: 받은 바이트를 순서대로 처리하는 단계들이다. 아래층이 자기 머리말을 떼고 나서야 위층이 본다 — 랜 카드 → IP → TCP → 소켓 차례로 넷이다.
구조체: 값 여러 개를 한 덩어리로 묶어 둔 것이다. C 에는 클래스가 없어서 이렇게 쓴다 — 메서드 없이 필드만 있는 자바 클래스라고 보면 된다. C 에서 a->b 는 자바의 a.b 와 같다(안에 든 것을 꺼낸다).
구현체: 인터페이스가 적어 둔 약속(메서드 목록)을 실제 코드로 채운 클래스다. 인터페이스가 「이런 메서드가 있어야 한다」는 설계도라면, 구현체는 그 설계도대로 실제로 동작하게 만든 물건이다. 같은 인터페이스를 여러 구현체가 각자 다른 방식으로 채울 수 있다.
그래프 (자료구조): 여러 개의 점과 그 점들을 잇는 선으로 관계를 표현하는 자료구조다. 점을 노드(또는 정점)라 하고, 점과 점을 잇는 선을 간선(또는 엣지)이라 한다. 지하철 노선도에서 역이 노드고 역과 역 사이 선로가 간선인 것과 같은 모양이다. 친구 관계, 길찾기, 글과 글 사이의 링크처럼 「무엇이 무엇과 연결되어 있는가」를 다룰 때 쓴다.
근거 종류: 표준 글에 적은 주장이 어떤 성격인지에 따라 나눈 네 가지 분류다. 「기술 사실」(예: 인덱스를 걸면 빠르다)은 같은 데이터로 있을 때와 없을 때를 돌려 비교해서 증명하고, 「안 비교」(예: 안 C가 안 A보다 낫다)는 같은 기능을 두 가지 방법으로 만들어 비교해서 증명하고, 「에이전트 규칙」(예: 이 탐색 규칙이 유리하다)은 같은 과제를 규칙이 있을 때와 없을 때로 여러 번 돌려 비교해서 증명하고, 「명세 사실」(예: 상태 코드 412의 뜻)은 공식 문서를 인용하고 최소 예제로 확인해서 증명한다.
글로브 (glob): 파일 경로를 하나하나 다 적지 않고 기호로 뭉뚱그려 찾는 방법이다. `*`는 그 자리에 오는 이름 하나를 가리키고, `**`는 그 밑에 폴더가 몇 겹 있든 전부를 가리킨다. `**/api/**/*.java`라고 쓰면 어디에 있든 이름이 `api`인 폴더 아래의 모든 `.java` 파일을 가리킨다.
기계어: CPU가 바로 알아듣는 명령이다. CPU 종류마다 다르다.
기능 플래그: 코드는 이미 배포해 두고, 그 기능을 보여줄지 말지를 설정값 하나로 켜고 끄는 장치다. 화면은 다 만들어서 배포했지만 기능 플래그를 꺼 두면 사용자에게는 아직 안 보인다. 그래서 "배포했다"와 "사용자가 쓸 수 있다"가 서로 다른 시점이 될 수 있다.
기동: 프로그램을 띄워서 요청을 받을 수 있는 상태가 되기까지를 말한다. 「기동 시간」은 그 사이에 걸린 시간이고, 「기동 로그」는 그동안 프로그램이 찍어 낸 글이다.
낙관적 락: 누가 동시에 고칠 일은 많지 않을 것이라 가정하고, 저장하는 순간에만 충돌 여부를 확인하는 방식이다. 행마다 버전 번호(@Version)를 두고, 저장할 때 자신이 읽었던 버전이 지금도 맞는지 확인해서 다르면 실패로 처리한다. 미리 잠그지 않아 평소에는 빠르지만, 충돌이 잦은 곳에서는 실패하고 다시 시도하는 비용이 늘어난다.
네이티브 쿼리: JPQL이 아니라 그 DB가 실제로 쓰는 SQL 문법을 그대로 적는 쿼리다. JPA가 대신 SQL을 만들어 주는 걸 쓰지 않고, 그 DB에서만 되는 함수나 복잡한 문법이 필요할 때 직접 SQL을 적어 쓴다. nativeQuery를 true로 표시해서 JPA에게 이건 번역하지 말고 그대로 보내라고 알려준다.
네임스페이스: 프로세스에게 보이는 것(파일 시스템 · 네트워크 · 프로세스 목록)을 따로 떼어 주는 장치다. 컨테이너가 자기만의 세상을 갖는 것이 이것 덕이다.
능력: root 가 가진 힘을 여러 조각으로 쪼개 놓은 것이다. 예를 들어 CAP_DAC_OVERRIDE 조각 하나만 있으면 rwx 검사를 건너뛸 수 있다. root 가 무엇이든 되는 것은 이 조각을 전부 갖고 있어서다.
다형성: 같은 이름의 메서드를 불러도 실제로 어떤 자식 클래스의 객체인지에 따라 다르게 동작하는 성질이다. 예를 들어 부모 타입 변수에 어떤 자식 객체를 담아 두느냐에 따라, 똑같은 메서드 호출이 자식마다 다른 결과를 낸다. 호출하는 쪽은 부모 타입만 알면 되고, 실제로 어떤 자식이 동작하는지는 신경 쓰지 않아도 된다.
단위 테스트: 클래스나 메서드 하나처럼 가장 작은 단위를 떼어서 혼자 검증하는 테스트다. DB나 다른 서버에 연결하지 않고 그 메서드 하나만 돌려 보기 때문에 빠르고, 메서드 하나가 입력에 맞는 출력을 내는지만 확인한다.
더티체킹: JPA가 영속성 컨텍스트에 올라온 객체의 값이 처음 조회했을 때와 달라졌는지 스스로 비교하는 일이다. 달라진 값이 있으면 저장 메서드를 따로 부르지 않아도 커밋 시점에 UPDATE문을 알아서 만들어 보낸다. 그래서 JPA로 조회한 객체는 값만 바꿔도 DB에 저장된다.
데이터 바인딩: 화면에 보이는 값과 코드 안의 변수를 서로 연결해 두는 것이다. 변수 값이 바뀌면 화면도 따라 바뀌고, 양방향 바인딩이면 반대로 사용자가 화면에서 입력한 값도 변수에 바로 반영된다. 이 연결이 없으면 변수를 바꿀 때마다 화면 어디를 고쳐야 하는지 직접 찾아 손으로 바꿔야 한다.
덱 (Deque): 양쪽 끝 모두에서 넣고 뺄 수 있는 자료구조다. 보통의 리스트는 한쪽 끝(맨 뒤)에서 넣고 빼는 게 자연스럽지만, 덱은 앞에서도 뒤에서도 O(1)로 넣고 뺄 수 있다. 자바의 ArrayDeque가 이 구조를 배열(원형 버퍼)로 구현한 클래스다.
도메인 (업무 영역): 주문·상품·회원처럼 서로 독립적으로 움직이는 업무 영역 하나를 가리키는 말이다. 보통 패키지 하나가 도메인 하나에 대응하고, 그 안에 Controller·Service·Domain·Entity가 함께 들어간다. Domain 클래스(업무 규칙을 담은 자바 객체 하나)와 헷갈리기 쉬운데, 여기서 도메인은 그 클래스들을 묶은 더 큰 단위를 가리킨다.
도메인 (주소): example.com 처럼 사람이 외우기 쉽게 지은 서버 주소다. 컴퓨터끼리는 실제로 IP라는 숫자 주소로 통신하는데, 숫자는 외우기 어려워서 이름을 대신 쓰고 DNS가 그 이름을 IP로 바꿔 준다.
도메인 드리븐: 코드를 역할이 아니라 도메인(업무 단위)으로 먼저 나누고, 그 안에 api·application·domain·infra 같은 계층을 두는 아키텍처다. 여러 Domain 객체를 하나로 묶은 단위가 애그리거트이고, Domain이 업무 규칙을 담는다. 역할부터 먼저 나누는 3계층 구조와 대비된다.
동기화 (스레드): 여러 스레드가 같은 데이터를 동시에 건드리면 값이 꼬일 수 있어서, 한 번에 하나의 스레드만 건드리게 순서를 맞추는 것이다. 자물쇠를 걸어서 한 스레드가 데이터를 쓰는 동안 다른 스레드는 기다리게 만드는 방식을 많이 쓴다. 동기화를 안 하면 두 스레드가 동시에 같은 값을 고쳐서 결과가 꼬이는 경쟁 상태가 생긴다.
동시성: 같은 일이 겹쳐서 한꺼번에 일어나는 성질이다. 같은 버튼을 두 번 빠르게 눌러 같은 요청이 서버에 동시에 두 번 들어가는 것도 동시성 문제고, 여러 스레드가 같은 데이터를 동시에 건드리는 것도 동시성 문제다. 둘 다 순서를 하나로 정해 두지 않으면 결과가 꼬인다는 같은 성질에서 나온다.
드라이버 (DB): 자바 프로그램과 특정 DB 사이에서 실제로 연결을 맺고 SQL과 결과를 주고받는 소프트웨어다. PostgreSQL용 드라이버, MariaDB용 드라이버처럼 DB 종류마다 따로 있다. JDBC라는 공통 규격을 따르므로, 자바 코드는 어떤 드라이버가 붙어 있든 같은 방식으로 호출할 수 있다.
디렉터리 엔트리: 디렉터리 안에 든 「이름 → inode 번호」 한 줄이다. 파일 이름은 파일 자신이 아니라 디렉터리가 들고 있다.
디렉티브: HTML 태그 안에 속성처럼 적어서 "이 요소를 이렇게 다뤄라"라고 템플릿 엔진이나 프레임워크에 지시하는 문법이다. 예를 들어 x-show="open"이라고 적으면 "open 값이 참일 때만 이 요소를 보여라"라는 뜻이 된다. 일반 HTML 속성과 다르게, 디렉티브는 그 값을 자바스크립트 코드로 해석해서 실행한다.
디바운스: 짧은 시간 안에 같은 동작이 여러 번 일어나도 마지막 한 번만 실행하게 미루는 기법이다. 검색창에 글자를 입력할 때마다 서버에 요청을 보내면 타이핑 한 글자마다 요청이 나가는데, 디바운스를 걸면 타이핑을 멈추고 일정 시간이 지난 뒤에야(예를 들어 300밀리초) 한 번만 요청을 보낸다. setTimeout으로 예약해 두었다가 다시 입력이 들어오면 clearTimeout으로 취소하는 방식으로 구현한다.
디스크: 전원을 꺼도 내용이 남는 저장 장치다. 대신 메모리보다 훨씬 느리다.
디자인 시스템: 버튼 모양, 색깔, 글자 크기 같은 화면 규칙을 한곳에 정리해 둬서 여러 화면과 여러 사람이 같은 모양을 쓰게 만든 것이다. 디자이너와 개발자가 매번 「이 버튼은 무슨 색이었지」를 묻지 않고 정해진 규칙을 그대로 가져다 쓴다.
디자인 토큰: 디자인 시스템에서 색, 간격, 글자 크기 같은 값에 이름을 붙여 둔 것이다. 파란색이라는 값을 코드 여러 곳에 그대로 쓰는 대신 이름 하나로 불러 쓰면, 나중에 그 색을 바꿀 때 이름이 가리키는 값 하나만 고치면 된다. CSS 변수는 이 토큰을 코드에서 실제로 꺼내 쓰는 방법 중 하나다.
라벨 (GitHub): 이슈나 PR에 색깔 있는 꼬리표를 붙여 종류를 구분하는 기능이다. 버그나 문서처럼 무엇에 관한 것인지, 또는 급함처럼 중요도를 표시할 수 있다. 라벨로 걸러 보면 지금 열려 있는 이슈 중 어떤 종류가 몇 개인지 한눈에 볼 수 있다.
라우트 (웹): 주소(경로)와 그 주소에서 보여줄 화면이나 처리를 짝지어 둔 것이다. /about 이면 소개 페이지를 보여주고 /users/1 이면 1번 사용자 페이지를 보여주는 식으로, 어느 주소에 무엇을 연결할지 정해 둔 규칙 전체를 라우팅이라 하고 그 규칙 하나하나를 라우트라 한다.
라우트 그룹 (Next.js): 폴더 이름을 괄호로 감싸 만드는 Next.js의 분류 단위다. (auth)처럼 괄호로 감싼 폴더는 주소에는 전혀 나타나지 않고, 그 묶음에 속한 라우트들에게만 같은 layout을 적용하고 싶을 때 쓴다.
라이브러리 파일: 다른 프로그램이 불러다 쓰는 코드 파일이다. JVM은 실행 파일이 아니라 라이브러리 파일(Linux libjvm.so, Windows jvm.dll)로 들어 있어서, 런처가 이 파일을 불러와 안의 함수를 부른다.
람다: 이름 없는 함수를 짧게 적는 문법이다. (a, b) -> a + b 처럼 「매개변수 -> 실행할 식」 모양으로 쓴다. 메서드 하나짜리 인터페이스를 구현하려고 클래스를 따로 만드는 대신, 그 자리에서 바로 동작만 적어 넘길 수 있다.
러너: 기동이 다 끝난 뒤 한 번 도는 내 코드다. ApplicationRunner 를 구현한 클래스에 @Component 를 붙여 두면 스프링이 찾아서 부른다. 서버가 뜬 다음에 돌기 때문에 기동 시간에는 들어가지 않는다. 이 페이지의 실측값 중 여럿을 이 러너가 찍었다.
런처: 터미널에서 치는 java 프로그램이다. JVM 자체가 아니라 C로 쓴 작은 실행 파일이다.
런큐: CPU 하나마다 있는, 지금 돌 준비가 된 task 들의 줄이다. 스케줄러는 이 줄에서 다음에 돌릴 것을 고른다.
레지스터: CPU 안에 있는 아주 작고 빠른 저장 칸이다. 지금 계산 중인 값과 「다음에 실행할 줄이 어디인지」가 여기 들어 있다.
레지스트리: 이미지를 올려 두고 내려받는 저장소다. Git으로 친 코드를 GitHub에 올려 두듯, 만든 이미지를 레지스트리에 올려 두면 다른 서버에서 그 이미지를 내려받아 똑같은 컨테이너를 띄울 수 있다. Docker Hub가 누구나 쓰는 공개 레지스트리고, 회사마다 자기만 쓰는 사설 레지스트리를 두기도 한다.
로그 레벨(INFO·WARN·ERROR): 로그 한 줄이 얼마나 심각한 소식인지 나타내는 등급이다. INFO는 그냥 무슨 일이 있었다는 기록이고, WARN은 문제가 될 수도 있지만 아직 멈추지는 않았다는 뜻이고, ERROR는 뭔가 실패했다는 뜻이다. 레벨을 나눠 두면 평소에는 INFO를 꺼 두고 WARN·ERROR만 보는 식으로, 급할 때 읽을 로그를 줄일 수 있다.
로그 한 줄 읽는 법: 로그는 프로그램이 도는 동안 스스로 찍어 내는 글이다. 한 줄이 이렇게 생겼다 — 「2026-09-18T09:03:25.247 INFO 29760 --- [main] o.s.boot.tomcat.TomcatWebServer : Tomcat initialized with port 18080」. 맨 앞이 시각이고(화면의 25.247 은 여기서 초와 밀리초만 뗀 것), 대괄호 안이 그 줄을 찍은 스레드 이름, 그다음이 찍은 클래스, 콜론 뒤가 내용이다.
롤링 릴리스(rolling release): 정해진 지원 기간 없이 새 기능이 나올 때마다 계속 다음 버전으로 올라가는 배포 방식이다. 기능을 가장 먼저 받아볼 수 있지만, 그 버전 자체를 오래 운영 환경에 묶어 둘 목적으로 만들어지지는 않는다. 오래 지원을 약속한 LTS 버전과 반대되는 개념이다.
롤링 해시: 문자열의 해시값을 한 글자씩 밀어가며 앞의 해시값으로부터 빠르게 다음 해시값을 계산하는 방법이다. 매번 부분 문자열을 처음부터 다시 해시하지 않고, 맨 앞 글자를 빼고 새 글자를 더하는 식으로 계산하므로 한 글자 이동할 때마다 상수 시간만 든다. 라빈-카프 알고리즘이 이 방식으로 패턴과 같은 길이의 모든 부분 문자열의 해시를 빠르게 비교한다.
리눅스 서비스(systemd): 리눅스가 컴퓨터를 켤 때 자동으로 실행하고, 죽으면 다시 살리는 프로그램 단위다. systemd가 이 서비스들을 관리하는 프로그램이고, 서비스 하나하나는 .service 파일에 「무엇을 어떻게 실행할지」를 적어 둔다. 서버 프로그램을 매번 터미널에서 손으로 켜지 않고 서비스로 등록해 두면 재부팅해도 알아서 켜진다.
리다이렉트: 명령어의 출력을 화면 대신 파일로 보내는 기호다. `echo hello > out.txt`라고 쓰면 화면에 안 찍히고 out.txt 파일에 저장된다. `>`는 파일을 새로 덮어쓰고, `>>`는 파일 끝에 이어 붙인다.
리베이스: 한 브랜치에서 쌓은 커밋들을 다른 브랜치의 최신 지점 위로 옮겨 다시 쌓는 일이다. 머지처럼 두 기록을 합친 흔적을 남기지 않고, 마치 처음부터 그 지점에서 시작해 순서대로 작업한 것처럼 기록을 한 줄로 만든다. 이미 다른 사람과 공유한 커밋을 리베이스하면 그 사람의 기록과 어긋날 수 있어 주의해야 한다.
리팩토링: 겉으로 보이는 동작은 그대로 둔 채 코드의 속 구조만 손보는 일이다. 기능을 추가하거나 버그를 고치는 것과는 다르다 — 리팩토링 전후로 프로그램이 하는 일은 같아야 하고, 중복을 줄이거나 이름을 더 명확하게 바꾸는 식으로 다음에 읽고 고치기 쉽게 만드는 것이 목적이다.
리프 (B-tree): B-tree의 맨 아래층에 있는 노드로, 실제 값이 최종적으로 저장되는 자리다. 뿌리에서 가지를 타고 내려가다 보면 마지막에 닿는 칸이라 나뭇잎이라는 뜻의 리프라고 부른다. 리프들은 양옆으로 서로 연결되어 있어서, 리프 하나를 찾은 뒤 옆으로 이어가면 정렬된 순서대로 쭉 읽을 수 있다.
리프레시 토큰: 로그인 상태를 오래 유지하려고 따로 두는 토큰이다. 실제 인증에 쓰는 토큰(액세스 토큰)은 수명이 짧아 자주 만료되는데, 그때마다 다시 로그인하지 않도록 리프레시 토큰으로 새 액세스 토큰을 발급받는다. 리프레시 토큰마저 만료되거나 실패하면 그때는 정말 다시 로그인해야 한다.
리플렉션: 프로그램이 돌아가는 중에 「이 클래스는 어떤 필드와 메서드를 가졌는가」를 스스로 들여다보고, 심지어 이름만 가지고 그 메서드를 부를 수도 있게 해 주는 기능이다. Spring 이 내가 만든 클래스를 미리 알지 못해도 애너테이션을 보고 빈으로 만들어 주입할 수 있는 이유가 이것이다.
릴리스 · 태그: 특정 시점의 코드를 여기까지가 몇 번째 버전이라고 이름 붙여 못 박아 두는 것이다. 태그는 어떤 커밋에 v1.2.0 같은 버전 이름표를 붙이는 것이고, 릴리스는 그 태그에 설명과 파일을 더해 GitHub에 정식으로 공개하는 것이다. 이 버전표가 있으면 나중에 그때 그 버전으로 정확히 돌아가거나 비교할 수 있다.
마크다운: 글자 앞에 간단한 기호를 붙여 제목·굵은 글씨·목록 같은 모양을 표현하는 글쓰기 방식이다. 워드프로세서처럼 버튼을 눌러 꾸미는 대신 글자로 직접 표시를 남기기 때문에, 순수한 텍스트 파일로도 글의 모양을 그대로 저장할 수 있다. 이 블로그의 글도 전부 마크다운(.md) 파일로 쓴다.
매크로: 컴파일하기 전에 글자를 그대로 바꿔치기하는 장치다. 함수처럼 생겼지만 함수가 아니라, C 에서 짧은 코드를 이름 하나로 줄여 쓸 때 쓴다.
머리말: 바이트 덩어리 앞에 붙어 「누가 어디로 보냈는지」를 적어 둔 부분이다. 층마다 자기 머리말을 하나씩 붙이고, 받는 쪽은 자기 것만 떼어 낸다.
머지: 서로 다른 브랜치에서 각각 고친 내용을 하나로 합치는 일이다. 두 사람이 각자 다른 종이에 적은 내용을 한 장으로 옮겨 붙이는 것과 비슷하다. 같은 줄을 양쪽에서 다르게 고쳤으면 충돌이 생겨 사람이 직접 어느 쪽을 남길지 정해야 한다.
메모리: 전원이 꺼지면 사라지는 대신 아주 빠른 저장 공간이다. 프로그램이 도는 동안 쓰는 값은 전부 여기 있다.
메서드 참조: 이미 있는 메서드를 람다 대신 그대로 넘기는 문법이다. OrderItemDomain::getSubtotal 은 item -> item.getSubtotal() 과 같은 뜻이고, "이 타입의 이 메서드를 그대로 써라"를 :: 으로 줄여 쓴 것이다. 스트림의 map 처럼 함수를 인자로 받는 자리에 자주 쓴다.
메트릭: 서버나 프로그램의 상태를 나타내는 숫자 하나다. CPU 사용률, 요청 처리 시간, 에러 발생 횟수 같은 것들이 메트릭이고, 이 숫자들을 시간마다 모아 두면 「언제부터 느려졌는지」, 「언제 에러가 늘었는지」를 그래프로 확인할 수 있다.
명령 이름 읽는 법: 앞 글자는 값의 타입(i = int, a = 참조)이고, 뒤는 하는 일이다 — load는 칸 → 스택, store는 스택 → 칸, const는 상수 올리기, add는 더하기, inc는 칸의 값을 제자리에서 올리기(iinc 2, 1 = 칸 2에 1 더하기). _1 같은 꼬리는 칸 번호나 값이다. if_icmpgt는 int 둘을 비교(cmp)해 앞의 값이 크면(gt) 점프한다. 화면의 「줄 3」은 그 명령이 소스 몇째 줄에서 나왔는지다.
명령행 인자: 프로그램을 띄울 때 명령 뒤에 붙이는 말이다. --server.port=18080 처럼 적으면 그 값이 프로그램에 그대로 전달된다. main(String[] args) 의 args 에 담겨 들어온다.
모듈: java.base처럼 패키지 여러 개를 묶은 큰 단위다. JDK 자신이 모듈로 나뉘어 있다(Java 9부터).
문맥 교환: CPU 가 돌리던 task 를 멈추고 다른 task 로 갈아타는 일이다. 레지스터와 메모리 지도를 바꿔 끼우므로 공짜가 아니다.
문법 나무: 토큰을 「클래스 안에 메서드, 메서드 안에 문장」처럼 포함 관계대로 쌓은 구조다. 바깥 것이 위, 안쪽 것이 아래에 온다.
물리 메모리: 실제로 꽂혀 있는 RAM 이다.
뮤테이션 (테스트): 테스트가 실제로 뭔가를 지키고 있는지 확인하는 방법이다. 코드를 일부러 한 줄 망가뜨려 보고(예를 들어 `>`를 `>=`로 바꾸는 식), 그래도 테스트가 통과하면 그 테스트는 그 코드를 지키고 있지 않다는 뜻이다. 망가뜨렸을 때 테스트가 실패해야만 그 테스트가 제 역할을 하는 것이다.
미디어 쿼리: 화면 크기나 종류에 따라 다른 CSS를 적용하게 해 주는 문법이다. 화면 너비가 일정 기준보다 좁을 때만 적용되는 스타일을 따로 정해 둘 수 있다. 휴대폰과 컴퓨터에서 같은 페이지가 다르게 보이는 것은 대부분 이 문법 덕분이다.
바이트: 컴퓨터가 다루는 가장 작은 덩어리 단위로, 0부터 255 사이의 숫자 하나다. 파일도, 네트워크로 오가는 글자도 결국 바이트의 나열이다. B는 바이트, KB는 약 1,000바이트, MB는 약 100만 바이트다. 「바이트가 도착했다」는 아직 글자로 읽기 전, 숫자 덩어리 상태로 도착했다는 뜻이다.
바이트코드: javac가 .class 파일에 쓰는 JVM 명령이다. 어느 CPU의 기계어도 아니어서, JVM이 읽어 실행한다.
반응형 (Reactive): 데이터가 바뀌는 순간 그 데이터를 쓰고 있는 화면이 자동으로 다시 그려지는 방식이다. 개발자가 "화면을 다시 그려라"라고 직접 명령하지 않아도, 변수 값만 바꾸면 그 값을 쓰는 곳이 알아서 갱신된다.
반증 조건: 실험을 돌리기 전에 미리 적어두는, 「이런 결과가 나오면 이 주장은 틀린 것으로 본다」는 기준이다. 결과를 보고 나서 기준을 정하면 어떤 숫자가 나와도 주장이 맞는 것처럼 끼워 맞출 수 있어서, 실험을 시작하기 전에 먼저 적어둔다.
배포: 고친 코드나 글을 실제로 사람들이 볼 수 있는 곳에 올려서 반영하는 일이다. 내 컴퓨터에서만 보이던 변경이 배포를 거치고 나면 실제 서비스나 공개된 주소에서도 똑같이 보이게 된다. 배포 전에 검사를 통과해야만 배포가 진행되게 막아 두는 장치를 게이트라고 한다.
배포본 (코딩 표준): 이 저장소의 coding-standards 폴더 내용이 복사되어 나가는, 별도의 공개 저장소를 가리키는 말이다. 이 저장소(원본)에서 규칙 파일을 고치면 GitHub Actions가 그 내용을 그 공개 저장소로 밀어내 새 버전을 만들고, 다른 프로젝트들은 설치 스크립트로 그 공개 저장소에서 최신 버전을 받아 쓴다. 즉 배포본은 다른 프로젝트가 실제로 내려받아 쓰는, 원본에서 한 단계 떨어진 사본이다.
백로그: accept 큐에 쌓일 수 있는 연결 수의 상한이다. 넘치면 새 연결이 거절되거나 버려진다. 주의 — 연결 하나하나에도 「백로그」라는 이름의 임시 대기 줄이 따로 있는데, 이름만 같고 다른 것이다.
버퍼: 프로그램이 미리 잡아 두는 메모리 자리다. 커널이 읽은 내용을 여기다 부어 준다 — 자바로 치면 read 에 넘기는 byte 배열이다.
번들 (Bundle): 여러 자바스크립트 파일을 브라우저가 한 번에 받기 좋게 하나(또는 몇 개)의 파일로 묶은 것이다. 브라우저는 페이지를 열 때 이 번들을 통째로 내려받아야 그 안의 코드를 실행할 수 있다. 그래서 번들에 실리는 코드가 많을수록 페이지가 뜨는 데까지 걸리는 시간이 늘어난다.
번역 단계: PrintCompilation 로그가 붙이는 번호다. 0 = 인터프리터, 1 = C1 번역(기록 없이), 3 = C1 번역 + 실행 기록, 4 = C2 번역. 2(C1 번역 + 호출 횟수만 세기)는 이번 실행에 나오지 않았다.
벌크 연산: Domain 객체를 하나씩 만들지 않고, DB에 UPDATE나 DELETE 같은 SQL을 직접 보내 여러 행을 한 번에 바꾸는 작업이다. 빠르지만 Domain이 지키는 업무 규칙 검사를 건너뛰기 때문에, 그 검사가 필요 없는 자리에서만 쓴다.
보일러플레이트: 매번 거의 똑같은 모양으로 반복해서 써야 하는 코드를 가리키는 말이다. 로직 자체는 특별할 게 없는데 양식을 맞추느라 손이 가고, 비슷한 파일이나 줄 수만 늘어나는 코드를 이렇게 부른다.
볼륨 (Docker): 컨테이너가 지워져도 데이터가 남게 해 주는 저장 공간이다. 컨테이너 안에만 파일을 저장하면 그 컨테이너를 지울 때 데이터도 같이 사라지는데, 볼륨에 저장하면 데이터가 컨테이너 바깥(호스트 컴퓨터)에 남아 다음 컨테이너가 이어서 쓸 수 있다. DB처럼 데이터를 지키면 안 되는 컨테이너에 꼭 붙인다.
분리(detached) 상태: JPA가 더 이상 추적하지 않는 객체의 상태다. DB에서 막 꺼낸 객체는 영속 상태라 값만 바꿔도 트랜잭션이 끝날 때 자동으로 저장되지만(더티체킹), 트랜잭션이 끝났거나 new로 직접 새로 만든 객체는 분리(준영속) 상태라 값을 바꿔도 JPA가 모르고 아무 일도 일어나지 않는다.
불변 객체: 한 번 만들어지면 내용을 절대 바꿀 수 없는 객체다. 값을 바꾸고 싶으면 그 객체를 고치는 대신, 바뀐 값을 가진 새 객체를 만들어서 돌려준다. 여러 스레드가 동시에 같은 객체를 봐도 아무도 값을 바꾸지 않으니 경쟁 상태가 생길 걱정이 없다. 자바의 String이 대표적인 불변 객체다.
불변식 (Invariant): 프로그램이 실행되는 동안, 또는 어떤 코드 구간의 앞과 뒤에서 항상 참이어야 하는 조건이다. 예를 들어 정렬 함수가 끝난 뒤에는 배열이 항상 오름차순이어야 한다는 것도 불변식이고, 생성자가 끝난 뒤에는 객체의 필드 값이 항상 정해진 범위 안에 있어야 한다는 것도 불변식이다. 이 조건이 깨졌다는 건 코드 어딘가에 논리적인 실수가 있다는 뜻이다.
브랜치: 저장소 안에서 원래 코드는 그대로 둔 채 따로 떨어져 나가 고칠 수 있게 만든 갈래다. 새 기능을 만들다가 망가뜨려도 원래 갈래에는 영향이 없다. 다 고친 뒤에는 머지로 원래 갈래에 다시 합친다.
블록: 디스크에 쓸 때 한 번에 잡는 최소 덩어리다. 보통 4096바이트라, 두 줄만 든 디렉터리도 크기가 4096 으로 찍힌다.
블록 장치: 디스크처럼 정해진 크기 덩어리 단위로 읽고 쓰는 장치다.
비관적 락: 누가 동시에 고칠 수도 있다고 가정하고, 읽는 순간부터 행을 잠가 다른 트랜잭션이 못 건드리게 막는 방식이다. 잠근 트랜잭션이 끝날 때까지 다른 트랜잭션은 그 행을 고치려는 작업에서 기다려야 한다. 충돌을 미리 막아 안전하지만, 잠긴 동안 다른 작업이 멈춰 있어야 해서 그만큼 느려질 수 있다.
비동기 처리: 어떤 일을 시켜 놓고 결과가 끝날 때까지 기다리지 않은 채 다음 일을 먼저 하는 방식이다. 음식을 주문하고 나와서 자리로 바로 가는 것과 비슷하다 — 음식이 되는 동안 멈춰 서서 기다리지 않는다. 반대로 끝날 때까지 멈춰서 기다리는 방식은 동기 처리라고 한다.
빅오 표기: 입력이 커질 때 걸리는 시간이나 쓰는 메모리가 얼마나 늘어나는지를 거칠게 표시하는 방법이다. 정확한 초 단위 시간을 재지 않고 「입력이 2배가 되면 시간도 2배가 되는지, 제곱이 되는지」만 본다. O(1)은 입력 크기와 상관없이 항상 같은 시간이 걸린다는 뜻이고, O(n)은 입력이 늘어난 만큼 시간도 늘어난다는 뜻이고, O(log n)은 입력이 늘어나도 시간은 아주 조금씩만 늘어난다는 뜻이고, O(n²)은 입력이 늘어난 만큼의 제곱으로 시간이 늘어난다는 뜻이다.
빈: 스프링이 대신 만들어서 들고 있다가 필요한 곳에 넣어 주는 객체다. 내가 new 로 만들지 않고 「이게 필요하다」고만 적으면 스프링이 찾아서 넣는다.
빈 후처리기: 빈이 만들어진 직후에 끼어들어 손을 보는 부품이다. 통이 빈을 하나 만들 때마다 한 번씩 부른다. 4단계에서 프록시로 감쌀지 정하는 것이 이 자리다.
빌드: 소스 파일을 컴파일해 실행 파일이나 라이브러리로 만드는 일이다.
빌드 도구: 소스 코드를 컴파일하고, 필요한 라이브러리를 내려받고, 테스트를 돌리고, 실행 파일로 묶는 과정을 한 명령으로 처리해 주는 프로그램이다. 이 과정을 사람이 손으로 하면 라이브러리 하나를 빼먹거나 순서를 틀리기 쉬운데, 빌드 도구에 한 번 적어 두면 같은 과정이 매번 똑같이 돌아간다. 자바에서는 Gradle과 Maven이 많이 쓰인다.
사용자 공간: 커널이 아닌 쪽이다. 내가 실행하는 프로그램은 전부 여기 있고, 여기서는 디스크나 메모리를 직접 못 만진다. 무언가 하려면 시스템 콜로 커널에 부탁해야 한다.
사일런스 (알림): 이미 아는 문제 때문에 당분간 알림을 받지 않게 꺼 두는 설정이다. 예를 들어 서버 점검 중에는 CPU가 일부러 오르내리는데, 그때마다 알림이 울리면 진짜 문제와 구분이 안 된다. 사일런스를 걸어 두면 정한 시간 동안 그 알림만 잠잠해지고, 조건 자체는 지워지지 않아 시간이 지나면 다시 작동한다.
상각 (amortized): 한 번의 연산이 어쩌다 비싸더라도 여러 번 반복했을 때 평균을 내면 싸진다는 뜻이다. 예를 들어 배열이 꽉 찼을 때 한 번은 전체를 복사하는 비싼 작업이 들지만, 그 비용을 그 사이 쌓인 싼 연산들에 나눠서 생각하면 1건당 평균은 O(1)이 된다.
상속: 이미 있는 클래스를 물려받아 새 클래스를 만드는 것이다. 자식은 부모가 가진 메서드를 그대로 갖고, 필요한 것만 다시 쓴다.
상수 풀: .class 파일마다 하나씩 있는 이름표 목록이다. 클래스 이름 · 메서드 이름 · 문자열에 번호를 붙여 모아 두고, 명령은 이름 대신 #7처럼 번호만 든다. 파일마다 따로라 같은 #13도 파일마다 가리키는 것이 다르다.
상태 (React): 컴포넌트가 기억하고 있다가 바뀌면 화면을 다시 그리게 만드는 값이다. 자바의 필드값과 비슷하지만, 이 값이 바뀌면 React가 자동으로 화면을 다시 그린다는 점이 다르다. 버튼을 누른 횟수, 입력창에 적힌 글자 같은 것이 보통 상태로 관리된다.
생성자: 객체를 만들 때 불리는 메서드다. 클래스 이름과 같은 이름을 쓴다. 여기에 적은 것이 곧 「이 객체가 있으려면 무엇이 먼저 있어야 하는가」가 된다.
서버: 요청을 받아서 처리해 주는 쪽이다. 클라이언트가 「이거 해줘」라고 요청을 보내면, 서버는 그 일을 처리하고 결과를 응답으로 돌려준다. 식당으로 치면 손님이 클라이언트, 주방이 서버다.
서브에이전트: 에이전트가 어떤 일을 직접 하지 않고 따로 떼어 내 맡기는, 또 다른 에이전트다. 일을 맡긴 쪽은 서브에이전트가 끝낸 결과만 받아 보고, 그 과정에서 서브에이전트가 읽은 자잘한 내용까지는 떠안지 않는다. 한 번에 여러 일을 동시에 시키거나, 긴 조사를 따로 떼어 둘 때 쓴다.
서블릿: 자바에서 HTTP 요청 하나를 받아 응답을 만드는 표준 부품이다. 톰캣은 서블릿을 부르는 방법만 알고, 그 안에서 무슨 일을 하는지는 모른다.
서블릿 컨테이너: 서블릿을 실행하고 관리하는 서버 프로그램이다. 톰캣이 대표적인 예다. 요청이 오면 그 요청을 처리할 서블릿을 찾아 실행시키고, 서블릿이 만든 응답을 다시 클라이언트로 돌려보낸다.
선언적 (Declarative): "어떻게 할지" 순서를 하나하나 적지 않고 "무엇이 되어야 하는지"만 적어 두는 방식이다. 예를 들어 "이 값이 참이면 이 요소를 보여라"라고 HTML에 적어 두면, 화면을 언제 보여주고 숨길지는 라이브러리가 알아서 처리한다. 반대로 "버튼을 누르면 이 요소를 찾아서 보이게 하고, 다른 버튼을 누르면 다시 찾아서 숨겨라"처럼 절차를 하나하나 적는 방식은 명령형이라 부른다.
선택자 (CSS): CSS 규칙을 어떤 HTML 요소에 적용할지 고르는 부분이다. `.card`처럼 점으로 시작하면 클래스 선택자로, `class="card"`가 붙은 요소를 고른다. `div`나 `body`처럼 태그 이름만 쓰면 요소 선택자로, 그 태그를 쓰는 요소를 전부 고른다.
선택지 장부: 표준 하나를 정할 때 검토했던 방법(안)을 채택 여부와 상관없이 전부 글에 남기는 방식이다. 안 하나마다 「무엇인지」, 「그 안을 택하면 어떤 모양이 되는지」, 「얻는 것」, 「버린 이유(또는 고른 이유)」 네 가지를 적는다. 고른 안만 남기면 나중에 이미 버린 안을 또 검토하게 되기 때문에, 버린 안과 그 이유까지 함께 남긴다.
세션: 로그인 한 번으로 묶이는 프로세스 무리다. 터미널을 닫으면 그 세션에 매달린 것들이 함께 정리된다.
셸: 명령을 받아 실행해 주는 프로그램이다. 우분투 기본은 bash 이고, 터미널에서 보이는 $ 앞이 그것이다.
셸 스크립트: 터미널에 한 줄씩 치는 명령어들을 파일 하나에 모아서 순서대로 실행하게 만든 것이다. bash는 명령어를 입력받아 실행해 주는 프로그램(셸) 중 널리 쓰이는 것이고, 셸 스크립트는 그 bash가 한 줄씩 읽어서 실행하는 파일이다. 매번 손으로 치는 대신 파일 하나를 실행해서 같은 명령어 묶음을 반복한다.
소스 줄 표시: 화면의 「JDK 27 소스 · Attr.java L5387」은 JDK 소스 저장소의 파일 이름과 줄 번호(L = Line)다. 그 스텝이 말하는 일이 실제로 적힌 곳이다. →는 「이 코드가 다음 코드를 부른다」, ·는 「그리고 여기도」(나란히 본 곳), 쉼표는 같은 파일의 여러 줄, …는 긴 폴더 경로를 줄인 것이다. L 대신 0xb2처럼 적힌 값은 그 파일에서 찾을 명령 번호다. .java는 Java, .c · .h는 C, .cpp · .hpp는 C++ 파일이고, .template은 빌드할 때 내용을 채워 넣는 틀 파일이다. 소스는 최신 개발본(JDK 27)을 봤고 실행은 설치된 JDK 21로 했다 — 두 버전 사이에 줄 위치나 세부가 다를 수 있다.
소켓: 두 프로그램이 네트워크로 연결됐을 때 그 연결의 양쪽 끝이다. 프로그램은 이 손잡이를 붙잡고 바이트를 주고받는다. 자바의 Socket 객체 뒤에 커널의 소켓이 있다.
스냅숏: 트랜잭션이 시작된 순간의 DB 모습을 그대로 찍어 둔 것이다. 격리 수준에 따라 트랜잭션은 자기가 시작할 때 찍힌 스냅숏만 보고, 그 뒤 다른 트랜잭션이 고치고 커밋해도 자기 눈에는 처음 그대로 보인다. 그래서 같은 트랜잭션 안에서 같은 값을 두 번 읽어도 항상 같은 값이 나온다.
스레드: 프로그램 안에서 따로 도는 실행 흐름(일꾼) 하나다. 같은 프로그램의 스레드들은 메모리를 함께 쓰고, 여럿이면 여러 일을 동시에 한다. main 메서드도 스레드 하나에서 돌고, 웹 서버는 요청 하나를 스레드 하나가 맡아 끝까지 처리한다. 자바의 Thread 하나가 보통 커널 스레드 하나와 짝을 이룬다.
스레드 풀: 미리 만들어 둔 스레드를 모아 두고 빌려 주는 곳이다. 요청이 오면 여기서 하나를 꺼내 쓰고, 끝나면 없애지 않고 돌려준다. 이름은 http-nio-18080-exec-2 처럼 붙는데, 로그에는 앞이 잘려 io-18080-exec-2 로 찍히기도 한다.
스왑: 물리 메모리가 모자랄 때 잘 안 쓰는 페이지를 디스크로 옮겨 두는 것이다.
스케줄러 클래스: 고르는 규칙이 다른 묶음들이다. 커널은 급한 쪽(실시간)부터 차례로 훑어 돌릴 것이 있는 묶음을 찾고, 보통 프로그램은 제일 마지막 묶음이 받는다.
스크레이프 (Prometheus): Prometheus가 설정해 둔 주기마다 대상 서버의 /metrics 주소에 직접 접속해서 그 안에 적힌 숫자를 가져오는 일이다. 대상이 Prometheus에게 보내 주는 게 아니라 Prometheus가 매번 찾아가서 가져온다(Pull 방식). scrape_configs에 적어 둔 대상마다 이 일을 반복한다.
스키마 마이그레이션: DB 스키마를 바꾸는 작업(컬럼 추가, 테이블 생성 등)을 SQL 파일로 적어 두고 순서대로 하나씩 적용해 나가는 방식이다. 코드를 Git으로 버전 관리하듯 스키마가 바뀐 이력을 파일로 남겨서 누가 언제 무엇을 바꿨는지 추적하고, 다른 환경에도 같은 순서로 적용할 수 있다. Flyway가 이 작업을 자동으로 해 주는 도구 중 하나다.
스킬 (Claude Code): Claude Code에게 이런 일은 이 순서대로 하라고 미리 적어 둔 작업 절차 묶음이다. 매번 같은 설명을 반복하지 않아도, 정해진 상황이 오면 이 절차를 불러와 따르게 한다. 코딩 스탠다드 중에서도 무엇이 맞는 코드인가보다 이 일을 어떤 순서로 하는가에 가까운 규칙이 여기 담긴다.
스택: 접시를 쌓듯 위에 올리고 위에서 꺼내는 구조다. 나중에 올린 것을 먼저 꺼낸다. JVM은 이 구조를 두 곳에 쓴다 — 스레드(프로그램 안에서 따로 도는 실행 흐름)마다 메서드 호출 기록을 쌓는 JVM 스택, 그리고 명령이 계산용 값을 올리고 꺼내는 피연산자 스택(5단계).
스택 트레이스: 에러가 어디서 났는지 코드가 호출된 순서대로 쭉 찍어 보여주는 기록이다. 메서드 A가 B를 부르고 B가 C를 부르다 C에서 에러가 나면, 스택 트레이스는 C부터 거슬러 올라가 B, A까지 누가 누구를 불렀는지를 줄줄이 보여준다. 에러 메시지만으로 어디가 문제인지 모를 때 이 순서를 따라가며 원인을 찾는다.
스텁: 테스트에서 진짜 협력자 대신 세워두는 가짜 대역이다. 진짜 UseCase나 Repository를 부르는 대신 "이렇게 호출되면 이 값을 돌려줘라"고 미리 정해둔 가짜 객체를 대신 끼운다. 진짜가 하는 검증(인증, DB 제약 등)은 전혀 거치지 않고 정해둔 값만 그대로 돌려주므로, 스텁이 통과시켰다고 해서 그 규칙이 실제로 지켜지는지 확인된 것은 아니다.
스테이징: 커밋하기 전에 이번 커밋에 포함할 파일을 따로 골라 두는 단계다. git add 명령으로 파일을 스테이징에 올리고, 커밋하면 그때 스테이징에 올라간 파일만 기록된다. 고친 파일이 여러 개여도 그중 일부만 골라 커밋할 수 있게 해 준다.
스트림: 리스트 같은 컬렉션의 데이터를 for 문 없이 한 줄로 걸러내고 변형하는 방법이다. list.stream().filter(x -> x > 0).map(x -> x * 2) 처럼 "조건에 맞는 것만 거르고(filter), 하나씩 바꾼다(map)"를 이어 붙여 적는다. 반복문을 직접 쓰지 않아도 "무엇을 할지"만 적으면 된다.
스프링 컨텍스트: 스프링이 만든 모든 빈을 담아 두고 관리하는 큰 상자(ApplicationContext)다. 서버가 뜰 때 이 상자를 채우는 과정을 "컨텍스트를 부팅한다"고 하는데, 설정을 읽고 빈을 전부 만들어 서로 연결하는 작업이라 시간이 걸린다. 테스트에서 `@SpringBootTest`처럼 실제 스프링 환경을 띄우는 테스트는 이 컨텍스트도 함께 부팅한다.
슬러그: 글 주소(URL)에 들어가는, 영문 소문자와 하이픈으로만 이루어진 짧은 이름이다. 예를 들어 애그리거트 경계라는 글의 슬러그는 aggregate-boundary-standard처럼 짓는다. 한글 제목 그대로 주소에 쓰면 복잡해지기 때문에, 주소에는 이 슬러그를 대신 쓴다.
슬로우 쿼리: 정해 둔 시간보다 오래 걸린 쿼리를 가리키는 말이다. 기준을 300ms로 정했다면 300ms 넘게 걸린 쿼리를 슬로우 쿼리라고 부르고, DB 설정으로 그런 쿼리만 따로 로그에 남기게 할 수 있다. 어떤 쿼리가 느린지 찾아 인덱스를 추가할 때 쓰는 신호다.
시간 복잡도: 어떤 코드가 입력 크기에 따라 연산을 몇 번쯤 하는지를 나타낸 것이다. 컴퓨터마다 실제로 걸리는 시간(초)은 다르지만, 「입력이 10배가 되면 연산 횟수가 몇 배가 되는지」는 코드 구조만 보고 알 수 있다. 이걸 적을 때 빅오 표기를 쓴다 — 리스트를 한 번씩 훑는 코드는 O(n)이고, 이중 for문으로 모든 쌍을 비교하는 코드는 O(n²)이다.
시계열: 시간 순서대로 쌓인 숫자 데이터다. 「1분마다 잰 CPU 사용률」처럼 같은 종류의 숫자를 시간 간격마다 하나씩 기록해 늘어놓은 것이고, 이걸 선으로 이으면 시간이 지나면서 어떻게 바뀌었는지가 그래프로 보인다. Prometheus가 메트릭을 저장하는 방식이 이것이다.
시스템 콜: 프로그램이 커널에게 일을 시키는 창구다. 파일 열기 · 스레드 만들기처럼 커널만 할 수 있는 일은 전부 이 창구를 지난다. 자바의 FileInputStream 도 결국 이 창구를 부른다.
신장 트리: 그래프의 모든 노드를 연결하면서 사이클이 생기지 않게 고른 간선들의 모음이다. 노드가 N개면 간선은 항상 N-1개가 된다. 간선마다 가중치가 있을 때 그 가중치 합이 가장 작은 신장 트리를 최소 신장 트리(MST)라 하고, 크루스칼이나 프림 알고리즘으로 찾는다.
신호: 커널이 프로세스에게 보내는 짧은 알림이다. SIGKILL 은 「지금 죽어라」이고 프로세스가 거절할 수 없다. SIGSEGV 는 「잘못된 주소를 건드렸다」다. 터미널에서 Ctrl+C 를 누르는 것도 신호 하나를 보내는 일이다.
실행 기록: 단계 3 코드가 돌면서 모으는 통계다 — 어느 분기로 자주 가는지, 반복이 몇 번 도는지 같은 것. C2는 이 기록을 보고 자주 가는 길 위주로 기계어를 짠다.
실행 중에 만드는 클래스: 자바는 .java 파일을 컴파일해 클래스를 만드는 것이 보통이지만, 클래스 파일의 바이트 배열만 있으면 프로그램이 도는 중에도 그것을 클래스로 읽어들일 수 있다. CGLIB 은 「OrderService 를 상속한 자식」에 해당하는 바이트 배열을 그 자리에서 만들어 건네준다. 그래서 내 프로젝트를 뒤져도 그 .java 파일은 없다.
심링크: 실제 파일이나 폴더가 있는 곳을 가리키기만 하는 바로가기 파일이다. 심링크 자체에는 내용이 없고, 그 안에는 "진짜는 여기 있다"는 경로만 적혀 있다. 그래서 가리키는 대상이 지워지거나 옮겨지면 심링크는 그 사실을 모른 채 빈 경로를 가리키게 된다.
아리맘 프로젝트: 이 블로그의 코딩 스탠다드를 실제로 적용해 쓰고 있는 서비스 프로젝트(백엔드는 Spring)다. 표준이 실제 코드에서 어떻게 동작하는지 재 볼 때(실측) 이 프로젝트의 코드와 기록을 근거로 쓴다.
안건 이슈: 이 블로그 저장소에서 아직 정하지 못했거나, 기존 규칙 두 개가 서로 부딪히는 지점을 적어두는 GitHub 이슈다. coding-standard 라벨을 붙이고, 정한 적이 아예 없으면 「미정의」, 기존 규칙끼리 서로 어긋나면 「모순」이라는 라벨을 추가로 붙인다. 새 표준으로 그 지점을 정리하면 이슈를 지우지 않고, 어떤 표준이 닫았는지만 남긴 채 닫는다.
압축 (Claude Code): 대화가 길어져 컨텍스트 창이 꽉 찼을 때, Claude Code가 지금까지 오간 내용을 요약해서 분량을 줄이는 일이다. 전부 잊어버리는 것이 아니라 핵심만 남기고 나머지를 간추리는 방식이라, 대화를 이어 갈 수는 있지만 세세한 내용은 사라질 수 있다.
애그리거트: 항상 함께 바뀌어야 하는 Domain 객체들을 하나로 묶은 덩어리다. 예를 들어 "주문"과 그 안의 "주문 항목들"은 따로 저장하면 둘이 어긋날 수 있어서 한 덩어리로 묶어 함께 저장하고 함께 꺼낸다. 이 덩어리의 대표 하나(여기서는 주문)를 통해서만 안쪽 데이터를 바꾸게 해서, 묶음 전체가 항상 일관된 상태를 유지하게 한다.
애너테이션: @ 로 시작해 클래스나 메서드에 붙이는 표시다. 그 자체로는 아무 일도 하지 않는다. 여기서 읽는 쪽은 스프링이다 — 스프링이 기동할 때 내 클래스들을 훑으며 이 표시를 찾아 보고 무엇을 할지 정한다.
애너테이션 프로세서: 컴파일 도중에 끼어들어 애너테이션을 읽고 코드를 더해 주는 프로그램이다. javac에는 이 프로그램을 끼워 넣을 자리가 있고, Lombok은 그 자리에 들어가 @Getter·@Setter 같은 표시를 보고 실제 코드를 만들어 넣는다.
약속 (원칙): 표준에 적힌 규칙 중에서, 반대로 정해도 프로그램이 똑같이 잘 동작하는 규칙이다. 예를 들어 「변수 이름은 camelCase로 쓴다」는 반대로 「snake_case로 쓴다」고 정해도 코드는 똑같이 동작한다. 이런 규칙은 옳고 그름을 실험으로 증명하지 않는다 — 모두가 같은 방식을 쓰기로 통일하는 것 자체가 목적이기 때문이다.
얕은 복사 · 깊은 복사: 객체를 복사하는 두 가지 방법이다. 얕은 복사는 객체 안에 다른 객체를 가리키는 참조가 있을 때 그 참조(가리키는 주소)만 그대로 복사해서, 원본과 복사본이 속은 같은 객체를 함께 보게 된다. 깊은 복사는 안에 있는 객체까지 전부 새로 만들어 복사해서, 원본을 고쳐도 복사본은 영향을 안 받는다. 어느 쪽을 썼는지 모르고 복사본인 줄 알고 고쳤다가 원본까지 같이 바뀌는 사고가 자주 난다.
어댑터: 서로 모양이 다른 두 쪽을 코드 하나가 중간에서 맞춰 주는 역할이다. 110V 플러그를 220V 콘센트에 꽂게 해 주는 전원 어댑터와 같은 생각이다. 트래커마다 이슈를 표현하는 방식이 다를 때, 어댑터가 그 차이를 흡수해서 나머지 코드는 트래커 종류를 몰라도 되게 만든다.
어서션(assert): 테스트 코드에서 「이 값이 이거여야 맞다」고 단정 짓는 코드 한 줄이다. assertEquals(5, 결과)처럼 적으면 실제 결과가 5가 아닐 때 테스트가 실패로 처리되고 어디서 틀렸는지 알려준다. 테스트는 결국 이 단정 한 줄 한 줄이 전부 맞는지를 모아서 보는 것이다.
에이전트 (AI): 사람이 시킨 일을 스스로 판단해 가며 여러 단계로 나눠 끝까지 수행하는 AI 프로그램이다. 한 번 묻고 한 번 답하는 것과 달리, 파일을 찾아 읽고 코드를 고치고 결과를 확인하는 과정을 스스로 이어 간다. Claude Code가 이런 에이전트를 실제로 움직이게 해 주는 도구 중 하나다.
엔드포인트: API에서 요청을 받는 주소 하나를 가리키는 말이다. GET /users/1 이라면 /users/1 이 엔드포인트고, 서버 하나에는 이런 엔드포인트가 여러 개 있다. 자바 코드에서는 보통 메서드 하나가 엔드포인트 하나와 짝을 이룬다.
역직렬화: 직렬화의 반대다. JSON처럼 줄로 늘어선 글자를 받아서 다시 자바 객체로 되돌리는 일이다. 스프링에서는 요청 본문으로 들어온 JSON을 Jackson(ObjectMapper)이 역직렬화해서 자바 객체로 만들어 준다.
연결: 브라우저 하나가 서버에 붙어 있는 줄 하나다. 붙어 있다고 해서 그 순간 일을 시키고 있는 것은 아니다 — 아무것도 안 보내고 열려만 있는 연결도 많다. 그래서 「붙어 있을 수 있는 연결 수」와 「동시에 처리할 수 있는 요청 수」는 다른 수다.
연결 리스트: 자료 하나하나(노드)가 다음 자료의 위치(참조)를 들고 줄줄이 이어진 자료구조다. 기차 칸들이 다음 칸과 연결 고리로만 이어져 있는 것과 비슷하다. 배열과 달리 중간에 자료를 끼워 넣거나 뺄 때 뒤의 자료를 전부 밀 필요가 없지만, 몇 번째 자료인지 바로 찾아가려면 앞에서부터 하나씩 따라가야 한다.
영속성: 프로그램이 꺼져도 데이터가 사라지지 않고 남아 있는 성질이다. 변수에 담긴 값은 메서드가 끝나면 사라지지만, DB에 저장한 값은 프로그램을 다시 켜도 그대로 남는다. 객체를 DB에 저장해 이 성질을 갖게 만드는 일을 JPA나 MyBatis 같은 도구가 맡는다.
영속성 컨텍스트: JPA가 지금 트랜잭션에서 다루는 객체들을 모아 두는 임시 보관소다. 한 번 조회해서 들어온 객체를 다시 조회하면 DB에 또 가지 않고 여기 있는 걸 그대로 돌려주고, 객체 값을 바꾸면 여기 보관된 원래 값과 달라진다. 이 차이를 나중에 DB에 반영하는 과정이 더티체킹이다.
영역: G1 GC가 힙을 같은 크기로 나눈 칸이다. 이번 실행은 1MB짜리 32칸이었다.
예외 번역: 아래 계층에서 터진 예외를 그대로 위로 흘려보내지 않고, 그 계층에 맞는 다른 예외로 바꿔서 던지는 일이다. 예를 들어 DB 쪽에서 난 예외를 Service 가 그대로 Controller 에 넘기면 Controller 가 DB 기술을 알아야 하는데, Service 가 "주문을 찾을 수 없음" 같은 업무 예외로 바꿔 던지면 위 계층은 아래 기술을 몰라도 된다.
오리진 (웹) · CORS: 오리진은 「주소(스킴·호스트·포트)가 전부 같은 범위」를 말한다. 브라우저는 기본적으로 한 오리진의 페이지가 다른 오리진의 서버에 요청 보내는 것을 막는데, 이걸 풀어 주는 서버 쪽 허락이 CORS다. 서버가 응답 헤더에 「이 오리진은 허락한다」고 적어 주면 브라우저가 그 응답을 페이지에 넘겨준다.
오버로딩: 이름이 같고 인자 타입이 다른 메서드 여러 개다. System.out의 타입인 PrintStream에는 println이 10개 있다.
오버헤드: 원래 하려던 일 말고 그걸 하기 위해 추가로 드는 시간이나 자원이다. 예를 들어 검증 코드를 넣으면 검증 자체가 오버헤드이고, 그게 0이라는 말은 그 코드가 실행 시점에 아무 비용도 더 들지 않는다는 뜻이다.
오탐: 실제로는 문제가 없는데 검사 도구가 문제가 있다고 잘못 알리는 것이다. 화재가 안 났는데 화재경보기가 울리는 것과 같다. 오탐이 잦으면 진짜 문제가 생겼을 때도 또 오탐이겠지 하고 넘기게 되는 것이 위험하다.
옵티마이저 (쿼리): DB 안에서 쿼리 하나를 어떤 순서와 방법으로 처리할지 직접 결정하는 부분이다. 같은 쿼리라도 인덱스를 여러 개 쓸 수 있으면 그중 무엇을 고를지, 테이블을 통째로 훑을지 인덱스를 탈지를 옵티마이저가 판단한다. 이 판단은 테이블 통계(행 수, 값의 분포)를 보고 하므로, 통계가 오래되면 엉뚱한 쪽을 고를 수 있다.
요청 매핑 애너테이션: Controller 메서드에 붙여 "어떤 주소로, 어떤 방식(GET·POST 등)의 요청이 오면 이 메서드를 부른다"를 정하는 표시들이다. @GetMapping("/orders")은 GET 방식으로 /orders 에 온 요청만, @PostMapping 은 POST 요청만 받는다. @RequestMapping 은 둘을 합쳐 방식까지 직접 지정하거나, 클래스에 붙여 공통 주소 앞부분을 정할 때 쓴다.
요청 본문 · 응답 본문: 요청이나 응답에서 주소나 상태 코드 다음에 오는 실제 데이터 부분이다. 택배로 치면 운송장(주소·보낸 사람)이 헤더이고, 상자 안에 든 물건이 본문이다. 보통 JSON 형식으로 적는다.
워크스페이스: 에디터에서 지금 열어 둔 프로젝트 폴더를 하나의 작업 단위로 묶어 부르는 말이다. VS Code 같은 도구에서 폴더 하나를 열면 그 폴더와 그 안의 설정이 함께 워크스페이스가 된다.
워크트리: 같은 저장소의 기록을 공유하면서도, 브랜치마다 따로 작업 폴더를 꺼내 둘 수 있게 하는 기능이다. 보통은 저장소 하나에 작업 폴더도 하나지만, 워크트리를 쓰면 브랜치마다 작업 폴더를 따로 디스크에 꺼내 두고 동시에 열어 둘 수 있다. 여러 작업을 번갈아 체크아웃하지 않고 동시에 두고 싶을 때 쓴다.
원형 버퍼: 배열을 양 끝이 이어진 원처럼 다루는 구조다. 앞에서 빼고 뒤에서 넣을 때 요소들을 한 칸씩 밀지 않고, 시작과 끝 위치를 가리키는 인덱스만 돌려 가며 써서 양 끝 삽입·삭제를 O(1)로 처리한다.
웹훅: 어떤 일이 일어났을 때 서버가 미리 등록해 둔 다른 서버의 주소로 먼저 요청을 보내 알려주는 방식이다. 보통은 클라이언트가 서버에 물어봐야 답을 받지만, 웹훅은 반대로 사건이 생긴 쪽이 먼저 알려준다. 결제가 끝났을 때 결제 회사가 내 서버로 「결제 끝났다」는 요청을 보내 주는 식이다.
유니온 타입: 이 값은 A 타입이거나 B 타입이라고 적는 TypeScript 문법이다. `User | null`은 User이거나 null이라는 뜻이고, `'USER' | 'ADMIN'`처럼 정해진 문자열 중 하나만 올 수 있다고 적을 때도 쓴다.
유니온-파인드: 여러 원소를 그룹으로 묶고 두 원소가 같은 그룹에 속하는지를 빠르게 확인하는 자료구조다. union 연산은 두 원소가 속한 그룹을 하나로 합치고, find 연산은 어떤 원소가 속한 그룹의 대표를 찾는다. 그래프에 간선을 하나씩 추가하면서 사이클이 생기는지 확인할 때 쓰는데, 크루스칼 알고리즘이 이 방식으로 최소 신장 트리를 만든다.
의도 메서드: 객체의 상태를 바꾸는 메서드 이름을 setter(예컨대 setQuantity)처럼 값만 넣는 모양으로 짓지 않고, changeQuantity처럼 무엇을 하려는지가 드러나게 짓는 방식이다. setter는 아무 값이나 받아 검증 없이 덮어쓰기 쉽지만, 의도 메서드는 이름이 허용하는 범위의 변경만 하도록 메서드 안에서 막을 수 있다.
의존성: 내 프로그램이 돌아가려면 있어야 하는 남의 코드다. build.gradle 에 한 줄 적으면 그 jar 를 받아 클래스패스에 넣어 준다. 이 실측에서 적은 것은 다섯 줄이다 — webmvc(웹 서버와 컨트롤러) · actuator(상태 확인용 주소) · thymeleaf(HTML 만들기) · jdbc(DB 연결) · h2(작은 DB).
의존성 역전: 위 계층이 아래 계층의 실제 클래스가 아니라 인터페이스만 보고 부르게 만드는 원칙이다. 예를 들어 Service 가 Repository 의 구현체 대신 Repository 인터페이스만 알게 하면, DB 를 바꿔 구현체를 새로 만들어도 Service 코드는 한 줄도 안 바뀐다. 의존성 주입은 이 원칙을 실제로 코드에서 이뤄지게 해 주는 방법이다.
의존성 주입: 빈이 필요로 하는 다른 빈을 스프링이 찾아서 넣어 주는 일이다. 나는 생성자에 「무엇이 필요한가」만 적는다. 자바는 클래스 파일 안에 생성자의 매개변수 타입까지 적어 두기 때문에, 스프링은 프로그램이 도는 중에도 그것을 읽어 「무엇이 필요한지」를 알아낼 수 있다.
이더넷: 랜선 한 구간에서 바로 옆 기계에게 넘길 때 쓰는 규약이다. 네트워크에서 제일 아래층이다.
이미지 (Docker): 컨테이너를 만드는 설계도다. 운영체제 일부·프로그램·설정 파일이 층(레이어)으로 쌓여 하나로 굳어 있고, 이 설계도 하나로 똑같은 컨테이너를 몇 개든 찍어낼 수 있다. 이미지 자체는 고칠 수 없고, 바꾸려면 새 이미지를 다시 만든다.
이벤트 리스너: 클릭·키 입력처럼 어떤 일(이벤트)이 일어나길 기다리다가, 실제로 일어나면 미리 정해 둔 코드를 실행하는 함수다. `addEventListener`로 요소에 걸어 두며, 더 쓸 일이 없어지면 `removeEventListener`로 떼어내야 한다. 떼지 않으면 그 요소가 화면에서 사라진 뒤에도 코드가 메모리에 남아, 더는 있으면 안 되는 시점에 실행될 수 있다.
이슈 (GitHub): GitHub에서 아직 해결 못 한 문제나 앞으로 할 일을 하나씩 적어 두는 카드다. 버그 보고, 기능 제안, 아직 정하지 못한 질문까지 전부 이슈로 남길 수 있고, 각 이슈는 번호와 제목을 가진다. 문제가 해결되면 이슈를 닫고, 그걸 해결한 커밋이나 PR과 연결해 두기도 한다.
이진 탐색: 정렬된 목록에서 원하는 값을 찾을 때, 가운데 값과 비교해서 찾는 범위를 절반씩 줄여나가는 방법이다. 가운데 값이 찾는 값보다 크면 앞쪽 절반만, 작으면 뒤쪽 절반만 다시 본다. 처음부터 끝까지 하나씩 보는 것(O(n))보다 훨씬 빠르게(O(log n)) 찾지만, 목록이 미리 정렬되어 있어야 한다.
이펙트 (React): 컴포넌트가 화면을 그린 뒤에 한 번 더 실행하는 코드다. useEffect로 적는다. 서버에 데이터를 요청하거나 타이머를 거는 것처럼, 화면 바깥의 것과 맞춰야 하는 일을 여기서 한다.
인덱스: 책 뒤에 있는 찾아보기와 같은 역할을 하는 DB 안의 자료 구조다. 찾아보기가 없으면 원하는 내용을 찾으려 책을 처음부터 끝까지 넘겨야 하듯, 인덱스가 없는 컬럼으로 조회하면 DB가 테이블의 모든 행을 다 훑어야 한다. 자주 조건으로 쓰는 컬럼에 인덱스를 걸어 두면 그 컬럼으로 찾을 때 훨씬 빨라지지만, 데이터를 쓸 때마다 인덱스도 같이 갱신해야 해서 쓰기는 그만큼 느려진다.
인코딩: 같은 바이트를 어떤 규칙으로 글자로 읽을지 정하는 약속이다. 보내는 쪽과 읽는 쪽이 다른 규칙을 쓰면 한글이 깨져 보인다. 그래서 요청을 읽기 전에 이것부터 정한다.
인터럽트: 하드웨어가 CPU 를 툭 쳐서 돌던 일을 멈추고 커널 코드로 넘기는 일이다. 커널이 남의 프로그램 중간에 끼어들 수 있는 거의 유일한 방법이다.
인터셉터: 필터와 비슷하게 요청을 가로채 공통 작업을 하는 부품이지만, 필터보다 한 단계 안쪽 — Spring 이 「이 요청은 어느 Controller 메서드로 간다」를 정한 뒤에 끼어든다. 그래서 필터와 달리 「어느 메서드로 가는 요청인가」까지 알고 판단할 수 있고, Controller 호출 전·후·완료 후 세 시점에 각각 코드를 넣을 수 있다.
인터페이스: "이런 메서드가 있어야 한다"는 약속만 적어 두고 실제 코드는 적지 않는 틀이다. 전자제품의 규격 콘센트와 비슷하다 — 콘센트 모양(약속)만 맞으면 어떤 회사의 전자제품(구현체)을 꽂아도 된다. 코드를 쓰는 쪽은 인터페이스만 보고 부르고, 실제로 어떤 구현체가 꽂혀 동작하는지는 몰라도 된다.
인터프리터: 바이트코드를 한 명령씩 읽고 해석하며 실행하는 방식이다. 어디서나 돌지만 느리다. 처음 실행되는 코드는 모두 인터프리터로 돈다.
자격증명: 프로세스가 「누구로서」 도는지를 담은 커널 안의 값이다(struct cred). uid · gid · 가진 권한이 여기 있고, 로그인은 이것을 갈아 끼우는 일이다.
자기 호출: 한 객체 안에서 this 로 자기 자신의 다른 메서드를 부르는 것이다. 밖에서 부르는 호출은 프록시가 먼저 받지만, 이미 원래 구현 안으로 들어온 뒤의 자기 호출은 프록시를 지나갈 일이 없다. 그래서 그 메서드에 @Transactional 을 붙여도 아무 일이 일어나지 않는다.
자동 구성: 내가 설정을 안 적어도 스프링 부트가 지금 클래스패스에 무엇이 있는지 보고 알아서 켜 주는 설정이다. 2단계가 이것만 다룬다.
자물쇠: 여럿이 같은 자료를 동시에 고치면 망가지므로, 한 번에 하나만 들어가게 잠가 두는 장치다. 쥔 쪽이 풀어야 기다리던 쪽이 들어간다.
작업 트리: 저장소를 체크아웃해서 실제로 디스크에 풀어 둔 파일들이다. 커밋하기 전에 내가 고친 내용은 먼저 이 작업 트리에 쌓인다. Git이 기록으로 가진 커밋들과 달리, 지금 눈에 보이고 편집기로 열어 고치는 파일 그 자체를 가리킨다.
장부: 예전에 이 블로그에서 「아직 정하지 않은 것」을 모아두던 페이지였다. 지금은 이 방식을 그만두고 전부 GitHub 이슈(안건 이슈)로 옮겼지만, 옛날 글에는 「장부 38번」처럼 번호로 남은 참조가 있다. 그 번호는 옮겨진 이슈 본문 끝의 「옛 장부 번호」를 보고 찾는다.
재귀: 메서드가 자기 자신을 다시 호출하는 것이다. 큰 문제를 「더 작은 같은 모양의 문제 + 더는 쪼갤 수 없는 아주 작은 경우」로 나눌 수 있을 때 쓴다. 자기 자신을 끝없이 부르면 멈추지 않고 계속 호출되므로, 가장 작은 경우(종료 조건)를 먼저 적어서 거기서 호출을 멈추게 한다.
저장소: 한 프로젝트의 모든 파일과, 그 파일들이 지금까지 어떻게 바뀌어 왔는지의 기록을 전부 담아 두는 폴더다. 영어로는 리포지토리(repository)라고 하고 줄여서 repo라고도 부른다. 내 컴퓨터에 있는 저장소를 로컬 저장소, GitHub 같은 곳에 올려 둔 저장소를 원격 저장소라고 나눠 부른다.
전 인자 생성자: 클래스의 필드를 하나도 빠뜨리지 않고 전부 매개변수로 받는 생성자다. 기본 생성자(아무 값도 안 받는 생성자)와 반대로, 이 생성자를 쓰면 객체를 만드는 순간 모든 필드 값이 채워진다. 손으로 적을 수도 있고, Lombok의 `@AllArgsConstructor`가 자동으로 만들어 줄 수도 있다.
전이 의존: build.gradle에 직접 적은 의존성이 자기한테 필요한 다른 jar를 데려오는 것이다. 예를 들어 spring-web 하나만 적어도 그게 쓰는 다른 jar들이 같이 클래스패스에 들어온다. 그래서 jar 하나를 뺄 때 그 jar만 빠지는지, 그 jar가 데려온 것까지 같이 빠지는지를 구분해야 한다.
전제조건·사후조건: 전제조건(precondition)은 메서드가 실행을 시작할 때 이미 참이어야 하는 조건이고, 사후조건(postcondition)은 메서드가 끝났을 때 참이어야 하는 조건이다. 둘 다 「이 메서드를 쓰려면 이게 맞아야 하고, 쓰고 나면 이게 보장된다」는 일종의 약속이다. 약속이 깨졌다는 건 호출하는 쪽이 잘못 썼거나(전제조건), 메서드 내부 로직이 틀렸다는(사후조건) 뜻이다.
접근성 (aria): 시각 장애가 있거나 마우스를 쓰기 어려운 사람도 화면을 쓸 수 있게 만드는 것을 접근성이라 한다. aria 속성을 붙이면, 화면을 눈으로 못 보고 음성으로 듣는 사람에게 이 버튼이 무엇을 하는 버튼인지 알려줄 수 있다. 버튼에 그림 아이콘만 있고 글자가 없을 때 특히 필요하다.
접두사 코드: 어떤 글자의 코드가 다른 글자 코드의 앞부분으로 겹치지 않게 만든 이진 코드다. a가 01이면 다른 글자는 01로 시작하는 코드를 받지 않는 식이다. 그래야 코드를 이어 붙인 비트열만 보고도 어디서 한 글자가 끝나고 다음 글자가 시작하는지 구분 기호 없이 알 수 있다. 허프만 코딩이 글자가 나오는 빈도를 보고 이 조건을 만족하는 코드를 자동으로 만들어준다.
접두사-접미사 테이블: KMP 문자열 검색에서 패턴 문자열의 각 위치마다 그 위치까지의 부분 문자열에서 접두사와 접미사가 몇 글자까지 겹치는지를 미리 계산해 둔 표다. 패턴 매칭 중 글자가 어긋나면 처음부터 다시 비교하지 않고 이 표를 보고 몇 칸을 건너뛸지 바로 알 수 있어서, 텍스트를 다시 훑지 않고 선형 시간으로 검색할 수 있다. 실패 함수 또는 부분 일치 테이블이라고도 부른다.
정규식: 문자열 안에서 원하는 패턴을 찾거나 바꿀 때 쓰는 특수한 표기법이다. 예를 들어 \d+는 숫자 하나 이상을, .*는 아무 문자나 0개 이상을 뜻한다. 보통의 문자열 비교로는 「숫자로 시작하는 줄」 같은 조건을 표현하기 어려운데, 정규식은 이런 패턴을 짧은 한 줄로 적을 수 있다.
정렬 안정성: 정렬했을 때 값이 같은 원소들의 원래 순서가 그대로 유지되는 성질이다. 예를 들어 이름이 같은 학생 두 명을 성적순으로 정렬해도, 정렬 전에 더 앞에 있던 학생이 정렬 후에도 더 앞에 남아 있으면 「안정 정렬」이다. 여러 기준으로 순서대로 다시 정렬해야 할 때(이름순으로 정렬한 걸 다시 성적순으로 정렬하는 경우) 이 성질이 깨지면 앞서 해둔 정렬 결과가 사라진다.
정적 export (정적 사이트): 서버가 매 요청마다 화면을 새로 만드는 대신, 미리 모든 페이지를 HTML 파일로 만들어 두는 방식이다. 방문자는 이미 만들어진 파일을 그대로 받기만 하면 되니 서버가 할 일이 거의 없다. Next.js 같은 프레임워크에서 빌드할 때 이 파일들을 한꺼번에 뽑아내는 것을 정적 export라고 한다.
정적 분석: 코드를 실행하지 않고 코드 자체만 읽어서 문제를 찾는 검사다. 테스트는 코드를 실제로 돌려서 결과를 확인하지만, 정적 분석은 돌리지 않고도 쓰지 않는 변수가 있다거나 null이 될 수 있는데 확인을 안 했다 같은 것을 미리 짚어낸다.
정적 파일: HTML · 이미지처럼 프로그램이 만들지 않고 그대로 내보내는 파일이다. static · public 같은 폴더에 두면 주소로 바로 받을 수 있다. 이 파일을 맡는 표는 /** 를 잡는데, /** 는 「아무 주소나 다」라는 뜻의 표기다. 모든 주소에 걸리므로 순서상 가장 마지막에 본다.
정적(static): 객체를 먼저 만들지 않아도 클래스 이름만으로 바로 부를 수 있게 하는 자바 키워드다. `OrderDomain.create(...)`처럼 `new`로 객체를 만드는 과정 없이 `클래스이름.메서드이름()` 형태로 바로 호출한다. 정적 팩토리 메서드는 이 성질을 이용해 "생성자 대신 이 메서드로만 객체를 만들어라"고 유도하는 메서드다.
제네릭: 클래스나 메서드가 다룰 타입을 나중에 끼워 넣을 수 있게 빈칸으로 남겨 두는 문법이다. List<String> 에서 <String> 이 그 빈칸을 채운 자리다. 빈칸을 안 쓰면 아무 타입이나 다 들어가서 꺼낼 때마다 원래 뭐였는지 확인해야 하는데, 제네릭을 쓰면 "이 상자엔 문자열만 들어간다"를 컴파일러가 미리 확인해 준다.
제네릭 와일드카드 (? extends): List<? extends Number> 처럼 <> 안에 구체적인 타입 대신 물음표를 쓰는 문법이다. "Number 이거나 Number를 상속한 어떤 타입"이라는 뜻으로, 정확히 어떤 타입인지는 모르지만 그 상한선만 정해 둔다. Chunk<? extends OrderBulkMapperParam> 이라고 쓰면 실제로 담기는 타입이 OrderBulkMapperParam 자신이든 그 자식이든 상관없이 받아들이겠다는 선언이다.
조건 애너테이션: 자동 구성 클래스에 붙어 「언제 켤지」를 적어 두는 표시다. @ConditionalOnClass 는 그 클래스가 클래스패스에 있을 때, @ConditionalOnMissingClass 는 없을 때 켠다. @ConditionalOnMissingBean 은 「내가 같은 종류의 빈을 이미 만들어 뒀으면 켜지 않는다」는 뜻이다 — 내가 직접 만든 것이 자동 구성에 덮이지 않게 해 준다.
종료 코드: 프로그램이 끝나면서 남기는 숫자 하나다. 0 이면 잘 끝난 것이고, 셸에서 echo $? 로 읽는다.
주장 (원칙): 표준에 적힌 규칙 중에서, 반대로 정하면 실제로 결과가 달라지는 규칙이다. 예를 들어 「인덱스를 건다」와 「안 건다」는 조회 속도가 다르게 나온다. 약속(원칙)과 달리 정말 맞는지 실험으로 증명해야 하고, 그 과정과 결과를 증명 글에 남긴다.
중첩 클래스: 클래스 안에 또 클래스를 넣은 것이다. AopAutoConfiguration.ClassProxyingConfiguration 처럼 점으로 이어 부르는데, 점 앞이 바깥 클래스이고 점 뒤가 그 안에 든 클래스다. 그래서 둘이 같은 파일에 나란히 있다.
증명 글: 표준 글에 적힌 주장(예: 「인덱스를 걸면 빠르다」)이 실제로 맞는지 직접 돌려서 확인한 과정을 적은 글이다. 돌리기 전에 「이러면 틀린 것으로 본다」는 기준(반증 조건)을 먼저 적어두고, 실험 설계와 결과, 예상과 달랐던 점까지 적는다. 결과는 사람이 손으로 요약하지 않고 돌린 스크립트가 그대로 써서, 불리한 수치가 숨겨지지 않게 한다.
지역 변수 칸: 프레임 안에서 매개변수와 지역 변수를 담는 번호 붙은 칸이다. static 메서드는 0번 칸부터 매개변수를 넣는다(main이면 0번이 args).
지연 로딩: 연관된 데이터를 조회 시점에 바로 가져오지 않고, 실제로 그 값을 쓰는 순간에 가져오는 방식이다. 주문 객체를 조회할 때 딸린 상품 목록까지 바로 가져오지 않고, 나중에 그 목록을 실제로 불러 쓰는 순간에야 쿼리가 나간다. 반대로 조회할 때 연관 데이터까지 한 번에 다 가져오는 것은 즉시 로딩이다.
직교: 두 가지가 서로 영향을 안 주고 따로 정해도 되는 관계다. 원래 수학에서는 「직각으로 만난다」는 뜻인데, 소프트웨어에서는 「한쪽을 바꿔도 다른 쪽이 안 흔들린다」는 뜻으로 쓴다. 예를 들어 두 설정값이 직교하면, 하나를 바꿔도 다른 하나는 그대로 둬도 된다 — 서로 독립적이기 때문이다.
직렬화: 자바 객체처럼 메모리에 있는 데이터를 줄로 늘어선 글자나 바이트로 바꾸는 일이다. 객체는 그대로 네트워크로 보낼 수 없어서, 보내기 전에 JSON 같은 형식으로 바꿔야 한다. 이 변환을 직렬화라고 한다.
참조: 객체가 어디 있는지 가리키는 값이다. 객체 타입 변수에는 객체가 아니라 참조가 들어간다. JVM 안에서는 객체의 위치를 나타내지만, Java 코드에서는 그 숫자를 직접 볼 수 없다.
체크섬: 오는 길에 바이트가 바뀌지 않았는지 보려고 같이 실어 보내는 검사용 숫자다.
체크아웃: 저장소 안에서 지금 보고 있는 브랜치나 특정 커밋을 다른 것으로 바꿔 끼우는 일이다. 책장에서 다른 버전의 책을 꺼내 펼치는 것과 비슷해서, 체크아웃하면 작업 폴더의 파일들이 그 시점의 모습으로 바뀐다. 다른 브랜치로 옮겨가 작업하려 할 때 가장 먼저 하는 일이다.
최종 일관성: 데이터를 저장하는 여러 곳이 지금 당장은 서로 값이 달라도, 시간이 조금 지나면 결국 같은 값으로 맞춰진다는 약속이다. 한 트랜잭션으로 묶어 "지금 이 순간 반드시 똑같다"를 보장하는 방식과 반대다. 애그리거트를 나눠 각각 따로 저장하면 중간에 한쪽만 저장되고 실패하는 틈이 생기는데, 이 틈을 허용하는 대신 나중에 재시도나 보정으로 맞춘다.
추상화: 복잡한 세부 동작은 안에 감추고, 바깥에는 꼭 필요한 것만 보이게 만드는 것이다. 자동차를 운전할 때 엔진이 어떻게 폭발을 일으켜 바퀴를 돌리는지 몰라도 핸들과 페달만 쓰면 되는 것과 같다. 코드에서는 [인터페이스](/term/interface)나 메서드 뒤에 구현을 숨겨서, 그걸 쓰는 쪽은 안이 어떻게 바뀌어도 신경 쓰지 않게 만드는 것을 말한다.
충돌: 같은 파일의 같은 부분을 서로 다른 브랜치에서 다르게 고쳐서, Git이 어느 쪽을 남겨야 할지 모르겠다며 합치기를 멈추는 상황이다. 풀이나 머지를 하다가 생기고, 충돌이 난 파일을 열어 보면 어느 부분이 어느 쪽 내용인지 표시가 되어 있다. 사람이 직접 둘 중 하나를 고르거나 합쳐서 다시 커밋해야 끝난다.
캐시 (HTTP): 한 번 받은 응답을 다시 쓰려고 보관해 두는 것이다. 매번 서버에 새로 묻지 않고 보관해 둔 것을 쓰면 더 빠르고 서버 부담도 준다. 대신 원본이 바뀌었는데 캐시가 그걸 모르면 낡은 내용을 보여주는 문제가 생겨서, ETag 같은 장치로 확인한다.
캐시 미스: CPU가 필요한 데이터를 L1·L2 같은 빠른 캐시에서 찾지 못해, 그보다 훨씬 느린 메인 메모리(RAM)까지 가서 가져와야 할 때 생기는 지연이다. 메모리 안에서 값들이 서로 멀리 떨어져 있을수록 자주 일어난다.
커널: 컴퓨터가 켜져 있는 동안 늘 돌고 있는 프로그램 하나다. 파일을 만들고 지우는 일, 프로그램을 띄우는 일은 내 프로그램이 직접 못 하고 전부 커널에 부탁한다. 터미널에 친 명령이 실제로 무언가를 하는 순간은 늘 커널 안이다.
커넥션 풀: DB 연결을 모아 두고 빌려 주는 곳이다. 여기서 주의할 것이 하나 있다 — 풀이라는 그릇이 만들어지는 것과 DB 에 실제로 연결을 맺는 것은 다른 일이고, 연결은 처음 달라고 할 때 그때 맺어지기도 한다. 이 실측에서 쓴 것은 HikariCP 다.
커넥터: 톰캣 안에서 포트 하나를 맡는 부품이다. 그 포트로 들어온 연결을 받아 요청으로 만들어 넘긴다. 만들어지는 것과 실제로 포트를 여는 것은 따로다.
커밋 (Git): 지금까지 고친 내용을 여기까지가 한 묶음이라고 정해 저장소에 기록하는 일이다. 사진을 찍듯 그 순간의 파일 모습을 통째로 남기고, 누가 왜 고쳤는지 설명하는 한 줄 메시지를 같이 붙인다. 나중에 문제가 생기면 이 기록을 거슬러 올라가 어느 커밋에서부터 잘못됐는지 찾을 수 있다.
커밋 훅: 커밋이 만들어지기 직전이나 직후에 자동으로 실행되는 작은 프로그램이다. pre-commit 훅은 커밋이 되기 전에 실행돼서, 코드 형식이 규칙에 안 맞거나 검사가 실패하면 그 자리에서 커밋 자체를 막을 수 있다. 사람이 매번 검사를 기억해 돌리지 않아도 되게 해 준다.
커버링 인덱스: 쿼리가 필요로 하는 컬럼을 전부 담고 있는 인덱스다. 보통 인덱스로 행의 위치를 찾은 다음 테이블 본문까지 다시 읽어야 하는데, 인덱스 안에 필요한 컬럼이 다 있으면 테이블 본문을 읽지 않고 인덱스만 보고 끝낸다. EXPLAIN 결과의 Extra에 Using index라고 뜨면 이 경우다.
커서 (페이징): 목록을 끊어서 가져올 때 지금까지 어디까지 읽었는지를 가리키는 값이다. 페이지 번호 대신 마지막으로 읽은 행의 위치를 기억해 두고, 다음 요청에서 그 값을 그대로 보내면 그다음 행부터 이어서 가져온다. 중간에 행이 추가되거나 지워져도 이미 지나간 위치를 기준으로 삼기 때문에 결과가 밀리지 않는다.
컨테이너 (Docker): Docker 이미지를 실제로 실행한 상태다. 프로그램 하나를 자기만의 작은 방에 넣어 돌리는 것과 비슷해서, 그 안에서는 자기 파일과 네트워크만 보이고 다른 컨테이너나 호스트 컴퓨터와 섞이지 않는다. 같은 이미지로 컨테이너를 여러 개 띄울 수 있고, 컨테이너 하나를 지워도 이미지는 그대로 남는다.
컨텍스트 창: AI가 한 번에 기억하고 참고할 수 있는 대화와 글의 최대 분량이다. 토큰 단위로 정해져 있어서, 대화가 길어져 이 한도를 넘으면 맨 앞부분부터 AI가 더 이상 보지 못하게 된다. 그래서 긴 작업을 할 때는 꼭 필요한 내용만 남기고 나머지는 요약하거나 떼어 내는 식으로 관리해야 한다.
컬럼: 테이블의 세로줄 하나, 즉 모든 행이 공통으로 갖는 항목 하나다. users 테이블이라면 id, name, email이 각각 컬럼이고, 행 하나하나는 그 컬럼들에 맞는 값을 채운 사람 한 명의 정보다.
컴파일: 사람이 쓴 소스 코드를 컴퓨터가 실행할 수 있는 형태로 번역하는 일이다. 그 일을 하는 프로그램이 컴파일러다.
컴파일 로그 읽는 법: 「30 3 Warm3::add」는 「프로그램 시작 후 30ms에 · 번역 단계 3으로 · Warm3 클래스의 add 메서드 번역을 시작했다」다. 시각은 번역이 끝난 때가 아니라 시작한 때다. ::는 「클래스의 메서드」라는 C++식 표기다. %가 붙으면 OSR 번역본이고, @18은 그 반복문의 조건 검사 명령 bci다. 끝에 made not entrant가 붙은 줄은 그 번역본을 폐기했다는 뜻이다. 실제 로그에는 번역 번호와 메서드 크기도 찍히는데 화면에서는 줄였다.
컴포넌트 (React): 화면의 한 조각을 재사용할 수 있게 함수로 만들어 둔 것이다. 버튼 하나, 카드 하나처럼 반복해서 쓰이는 모양을 컴포넌트로 만들어 두면 여러 화면에서 같은 코드를 다시 쓰지 않고 가져다 쓸 수 있다. React에서는 보통 자바스크립트 함수 하나가 컴포넌트 하나다.
컴포넌트 스캔: 내 시작 클래스가 있는 패키지 아래를 훑어 @Component · @Service · @RestController 같은 표시가 붙은 클래스를 찾아 빈으로 만드는 일이다. 그래서 시작 클래스의 위치가 곧 훑는 범위가 된다.
케밥 케이스 · 스네이크 케이스: 여러 단어로 된 이름을 한 덩어리로 적는 방식이다. kebab-case는 단어 사이를 하이픈(-)으로 잇는다(order-item). snake_case는 밑줄(_)로 잇는다(order_item). 어느 쪽을 쓰든 프로그램은 똑같이 동작하고, 같은 저장소 안에서 한 가지로 통일하는 것 자체가 목적이다.
코드 리뷰: 다른 사람이나 나 자신이 PR로 올라온 코드를 머지하기 전에 미리 읽어 보고 의견을 남기는 일이다. 잘못된 부분이나 더 나은 방법을 댓글로 지적해서, 문제가 있는 코드가 통합 브랜치에 그대로 들어가는 것을 막는다. 지적받은 부분을 고쳐 다시 커밋하면 같은 PR 안에서 리뷰가 이어진다.
코딩 스탠다드: 이 블로그에서 「코드가 어떤 모양이어야 하는지」를 정해서 적어놓은 글의 한 종류다. 예를 들어 「DTO는 생성자로만 만든다」처럼 구체적인 규칙과, 왜 그렇게 정했는지 이유를 함께 적는다. 글마다 짝이 되는 규칙 파일(.claude/rules·.claude/skills)이 따로 있어서, AI 에이전트가 코드를 쓸 때는 이 글이 아니라 그 규칙 파일만 보고 바로 따른다.
코퍼스: 검색이나 분석의 대상이 되는 글·문서 전체 묶음이다. 이 저장소에서는 블로그에 쌓인 글 전체를 가리킨다. 코퍼스가 커진다는 건 검색 대상이 되는 글이 그만큼 많아진다는 뜻이다.
콘텐츠 협상: 요청이 받을 수 있다고 한 형식과 서버가 내보낼 수 있는 형식을 맞춰 하나를 고르는 일이다. 로그의 Using '…', given […] and supported […] 한 줄이 그 결과다. supported 에 적힌 application/*+json 은 「json 으로 끝나는 형식 전부」를 뜻하는 표기이고, 겹치는 것이 여럿이면 앞에 적힌 것이 뽑힌다.
쿠버네티스(K8s): 컨테이너를 여러 대의 서버에 나눠 띄우고, 그중 몇 개가 죽으면 자동으로 다시 띄워 주는 관리 도구다. 컨테이너가 몇 개뿐일 때는 Docker만으로 충분하지만, 수십수백 개로 늘면 사람이 일일이 상태를 보고 재시작하기 어려워지는데 쿠버네티스가 그 일을 대신 맡는다. K8s는 k와 s 사이의 글자 수(8개)를 줄여 쓴 표기다.
쿠키: 서버가 브라우저에게 「이거 저장해 뒀다가 다음에 올 때 같이 보내」라고 넘겨주는 작은 데이터 조각이다. 로그인 상태를 기억하는 데 많이 쓴다 — 로그인에 성공하면 서버가 쿠키를 내려주고, 브라우저는 같은 사이트에 요청할 때마다 그 쿠키를 자동으로 같이 보낸다.
쿼리: DB에 「이런 데이터를 달라」 또는 「이렇게 바꿔라」라고 보내는 요청 한 건이다. SELECT로 데이터를 가져오는 것도, INSERT로 새 행을 넣는 것도 전부 쿼리 하나다. 코드 한 줄이 쿼리 하나로 이어지기도 하고, 연관 데이터를 따로 가져오면 쿼리가 여러 번 나가기도 한다.
쿼리 파라미터: 주소 끝에 물음표를 붙이고 그 뒤에 적는 조건값이다. /users?page=2 에서 page=2 가 쿼리 파라미터고, 「2페이지를 보여달라」는 뜻이다. 여러 개를 보낼 때는 &로 잇는다.
큐: 먼저 넣은 것이 먼저 나오는 자료구조다(FIFO, First In First Out). 줄을 서는 것과 같다 — 먼저 줄을 선 사람이 먼저 나간다. 나중에 넣은 것을 먼저 꺼내는 스택과 반대 순서다.
클라이언트: 연결을 거는 쪽이다. 받는 쪽은 서버라고 부른다.
클라이언트 컴포넌트 (Next.js): Next.js의 App Router에서 컴포넌트는 기본적으로 서버에서만 실행되는 서버 컴포넌트다. 파일 맨 위에 use client 지시문을 적으면 그 컴포넌트는 브라우저에서도 실행되는 클라이언트 컴포넌트가 된다. useState 같은 훅이나 버튼 클릭 같은 상호작용은 클라이언트 컴포넌트에서만 쓸 수 있다.
클래스 로더: .class 파일을 찾아 메모리에 올리는 것이다. JDK에는 셋이 있다 — JVM 안에 C++로 든 부트 로더, Java 객체인 플랫폼 로더와 App 로더(시스템 클래스 로더). JDK 클래스용과 내 클래스용이 나뉘어 있고, 내 클래스용 로더는 보통 JDK용 로더(부모)에게 먼저 물어본다 — 내 클래스가 String 같은 JDK 클래스 이름을 흉내 내도 JDK 쪽이 쓰이게 하기 위해서다.
클래스 리터럴: ExampleApplication.class 처럼 클래스 이름 뒤에 .class 를 붙인 것이다. 객체가 아니라 「클래스 그 자체」를 값으로 넘기는 표기이고, run() 에 넘기면 「이 클래스를 시작점으로 삼아라」는 뜻이 된다.
클래스패스: 자바가 클래스(.class 파일)를 찾는 곳의 목록이다. 내가 만든 클래스와 build.gradle 에 적어 받아 온 jar 들이 전부 여기 들어간다. 따로 정하지 않으면 지금 폴더다. 「클래스패스에 있다」는 「그 클래스를 쓸 수 있다」는 뜻이다.
클론: 저장소 전체를 처음부터 끝까지 디스크의 새 자리에 통째로 복사해 오는 일이다. 클론해 오면 원본 저장소와는 독립된 폴더가 생기고, 그 안에서 따로 브랜치를 체크아웃하고 작업할 수 있다. 워크트리와 달리 `.git` 기록도 별도로 복사되므로 한쪽에서 생긴 문제가 다른 쪽에 번지지 않는다.
타임 슬라이스: 한 task 가 한 번에 CPU 를 쥐고 있을 수 있는 시간이다.
타입 가드: 함수의 반환 타입을 값 is 타입 형태로 적어서, 그 함수가 true를 돌려주면 TypeScript가 그 뒤부터 값을 그 타입으로 믿고 다루게 해 주는 문법이다. `function isApiError(error: any): error is ApiError`라면, 이 함수가 true를 돌려준 자리부터는 error를 ApiError 타입으로 다룰 수 있다.
테스트(자동 테스트): 코드가 원하는 대로 동작하는지 사람이 손으로 확인하는 대신, 코드로 짜 둬서 실행 한 번에 검증하는 것이다. 예를 들어 「2 더하기 3을 더하면 5가 나와야 한다」를 코드로 적어 두면, 코드를 바꿀 때마다 매번 손으로 눌러 보지 않고 실행만 하면 맞는지 틀리는지 바로 안다.
테이블: 데이터를 가로세로 칸으로 정리해 담아 두는 곳이다. 엑셀 시트 하나를 떠올리면 되는데, 세로줄이 컬럼이고 가로줄이 행이다. DB 하나 안에 users, orders처럼 이런 테이블이 여러 개 들어간다.
템플릿 엔진: HTML 문서 안에 자리를 비워 두고, 그 자리에 서버가 가진 값을 채워 완성된 화면을 만들어 주는 도구다. Controller가 JSON 대신 완성된 HTML 문서를 돌려줘야 할 때 쓴다.
토크나이저 · 파서: 토크나이저는 글자를 토큰으로 자르는 javac 부품이고, 파서는 토큰을 문법 나무로 쌓는 부품이다.
토큰: public, Hello, { 처럼 뜻이 있는 가장 작은 글자 덩어리다.
토큰 (AI): AI 모델이 글을 읽고 쓸 때 다루는 가장 작은 단위 조각이다. 단어 하나가 토큰 하나가 되기도 하고, 긴 단어나 한글은 여러 토큰으로 쪼개지기도 한다. AI를 쓰는 비용이나 한 번에 넣을 수 있는 글의 길이는 글자 수가 아니라 이 토큰 수로 정해진다.
토큰 (인증): 로그인한 뒤 「이 사람이 맞다」는 것을 매번 증명하기 위해 서버가 내려주는 문자열이다. 비밀번호를 요청마다 다시 보내는 대신 이 토큰을 실어 보내면 서버가 토큰만 확인하고 누구인지 알아본다. AI가 글의 양을 셀 때 쓰는 토큰과는 다른 뜻이다.
톰캣: 바깥에서 온 HTTP 요청을 받아 내 자바 코드에 넘겨주고, 내가 돌려준 값을 다시 바깥으로 내보내는 부품이다. 따로 설치해 띄우는 프로그램이 아니라 내 프로그램 안에서 자바 객체로 만들어진다 — 그래서 다른 빈들과 똑같이 통 안에서 만들어진다.
통: 빈을 만들어 담아 두는 곳이다. 제대로 된 이름은 애플리케이션 컨텍스트이고, 이 페이지에서는 통이라고 부른다. 여기서 「무엇이 필요하다」는 요청을 받아 담긴 빈을 꺼내 준다.
통합 브랜치: 여러 브랜치에서 고친 내용이 최종적으로 모이는 중심 갈래다. 보통 main이나 dev라는 이름을 쓰고, 여기 있는 코드가 실제로 배포되는 기준이 된다. 다른 브랜치에서 작업을 마치면 PR이나 머지를 거쳐 이 브랜치로 합친다.
통합 테스트: 클래스 여러 개나 DB처럼 실제로 연결된 것들을 함께 묶어 돌려 보는 테스트다. 단위 테스트가 메서드 하나만 따로 떼어 본다면, 통합 테스트는 그 메서드들이 실제로 연결돼 있을 때도 제대로 맞물려 돌아가는지 확인한다. 그만큼 준비가 더 들고 느리다.
트래커: 해야 할 일이나 아직 풀리지 않은 문제를 목록으로 모아 관리하는 도구다. GitHub의 이슈도 트래커의 한 종류이고, Jira처럼 회사에서 따로 쓰는 전문 트래커도 있다. 트래커에 적힌 항목은 보통 열림과 닫힘 상태를 가지고, 누가 맡았는지도 같이 적어 둔다.
트랜잭션: DB 작업 여러 개를 한 묶음으로 묶는 것이다. 「연다」는 DB 에 「지금부터 하는 것들을 한 묶음으로 봐 달라」고 말해 두는 일이고, 다 성공하면 커밋(묶은 작업을 확정해 DB 에 진짜로 반영), 하나라도 실패하면 롤백(전부 없던 일로 되돌림)한다.
트리 (자료구조): 한 뿌리에서 가지가 뻗어나가듯, 위에서 아래로 갈라지는 모양의 자료구조다. 맨 위의 점을 루트(뿌리)라 하고, 한 점에서 아래로 뻗은 점들을 자식이라 한다. 컴퓨터의 폴더 구조(폴더 안에 폴더)나 회사 조직도가 이 모양이다. 그래프의 한 종류인데, 길이 갈라지기만 하고 다시 합쳐지거나 둘러 돌아오지 않는다는 점이 다르다.
특수 파일 (Next.js App Router): Next.js의 App Router에서 파일 이름 자체가 역할을 정하는 예약된 이름들이다. page.js는 그 폴더 주소의 화면을 그리고, layout.js는 그 폴더와 하위 폴더 전체를 공통으로 감싸는 틀을 그린다. 페이지마다 따로 불러오지 않아도 폴더 안에 이 이름으로 파일을 두기만 하면 Next.js가 자동으로 적용한다.
특이도 (CSS): 같은 요소에 CSS 규칙 여러 개가 동시에 걸릴 때 어느 것을 적용할지 정하는 점수다. 클래스 선택자(`.card`)끼리는 특이도가 같고, id 선택자(`#card`)는 클래스보다 높고, 요소 선택자(`div`)는 클래스보다 낮다. 특이도가 같으면 CSS 파일을 불러온(import) 순서상 나중 것이 이긴다.
파이프: 한 명령어의 출력(화면에 찍히는 결과)을 다음 명령어의 입력으로 그대로 이어주는 기호 `|`다. `cat file.txt | grep hello`라고 쓰면 file.txt의 내용을 화면에 찍는 대신 grep hello 명령어로 바로 넘겨서, 그 안에서 hello가 들어간 줄만 걸러낸다. 중간에 파일을 안 만들고도 여러 명령어를 한 줄로 이어 쓸 수 있다.
파이프라인 (CI/CD): 코드가 올라온 뒤 빌드, 테스트, 배포까지 거치는 일련의 자동화된 단계다. 공장의 컨베이어 벨트처럼 코드가 한쪽 끝으로 들어가면 정해진 단계를 순서대로 거쳐 반대쪽 끝에서 배포까지 끝난 상태로 나온다. CI(지속적 통합)는 앞쪽의 빌드·테스트를, CD(지속적 배포)는 뒤쪽의 배포를 가리킨다.
파일 디스크립터: 프로세스가 무언가를 열고 받는 번호표다. 프로세스마다 따로 있는 표의 몇 번째 칸인지를 뜻한다 — ls -l /proc/self/fd 로 그 표가 보인다. 파일만의 것이 아니다. 소켓도 파이프도 같은 표에 걸리고, 그래서 read · write 가 셋 모두에 똑같이 통한다.
파일 시스템: 디스크에 파일을 어떤 모양으로 늘어놓을지 정한 방식이다. 우분투 기본은 ext4 다. VFS 덕에 어느 것을 쓰든 ls · rm 같은 명령은 똑같이 통한다.
판정 (supported · refuted · inconclusive): 증명 글이 표준의 주장을 실험으로 확인한 뒤 내리는 세 가지 결론 중 하나다. supported는 미리 정한 반증 조건을 통과해 주장이 뒷받침된 것이고, refuted는 그 조건에 걸려 주장이 틀렸다고 밝혀진 것이고, inconclusive는 뒷받침도 반증도 하지 못한 것이다. 결과가 refuted여도 숨기지 않고, 그 표준 글에 「반증」이라고 그대로 적는다.
패키지 이름: java.lang.System에서 java.lang은 System이 들어 있는 패키지(클래스를 묶는 폴더 같은 것)다. .class 파일 안에서는 점 대신 /를 써서 java/lang/System으로 적는다.
패킷: 네트워크로 오가는 바이트 덩어리 하나다. 「누가 어디로 보냈는지 적은 앞부분(머리말) + 진짜 내용(알맹이)」으로 되어 있다.
페이지: 메모리를 나누는 기본 단위다. 보통 4KB 이고, 커널은 메모리를 이 덩어리 단위로 다룬다.
페이지 캐시: 한 번 읽은 파일 내용을 메모리에 남겨 두는 곳이다. 다음에 같은 자리를 읽으면 디스크에 가지 않는다. 자바 쪽 캐시가 아니라 커널이 들고 있는 것이라, 프로세스가 죽어도 남는다.
페이지 폴트: 가상 주소에 닿았는데 물리 페이지가 아직 안 붙어 있을 때 일어나는 일이다. 커널이 그때 페이지를 붙여 준다 — 오류라는 이름이지만 정상 동작이다.
페이지 표: 가상 주소가 실제 메모리의 어디인지 적어 둔 표다. CPU 는 주소를 만질 때마다 이 표를 본다. 이 표의 자리가 비어 있으면 페이지 폴트가 난다.
페이징: 결과가 많을 때 전부 한 번에 보내지 않고 몇 번째 페이지처럼 묶어서 나눠 보내는 방식이다. 게시판에서 1페이지에 20개씩 끊어 보여 주는 것과 같다. Spring Data에서는 몇 번째 페이지와 한 페이지 크기를 담는 Pageable로 요청하고, 결과와 전체 개수·페이지 수를 담은 Page로 돌려받는다.
포인터: 덩어리 자체가 아니라 그 덩어리가 놓인 자리를 적어 둔 쪽지다. 쪽지를 건네면 덩어리를 옮기지 않고도 같은 것을 가리킬 수 있다. 자바에서 객체를 변수에 담는 것과 같은 자리다.
포커스: 지금 이 순간 키보드 입력을 받을 차례인 화면 요소가 어디인지를 가리키는 상태다. 입력칸을 클릭하면 그 칸이 포커스를 갖고, 그 상태에서 키보드로 글자를 치면 그 칸에 들어간다. Tab 키를 누르면 포커스가 다음 요소로 옮겨간다.
포트: 한 컴퓨터 안에서 어느 프로그램에게 줄지 가르는 번호다. 주소가 건물이라면 포트는 호수다. ssh 는 22번, 웹은 보통 80·443번을 쓴다. Spring Boot 실측에서는 8080을 다른 프로그램이 이미 쓰고 있어서 --server.port=18080 으로 18080을 썼다.
폴링: 누가 알려줄 때까지 기다리지 않고, 일정한 간격으로 "지금 어떤가"를 직접 계속 물어보는 방식이다. 10초마다 "새 메일 왔어?"를 서버에 묻는 식이다. 물어보는 쪽이 계속 일을 해야 하고, 묻는 간격 사이에 생긴 일은 다음에 물어볼 때까지 모른다.
표준 입출력: 프로그램이 뜰 때 자동으로 받는 번호표 셋이다. 0 은 내가 치는 글자가 들어오는 곳, 1 은 화면에 찍히는 곳, 2 는 오류가 찍히는 곳이다. 자바의 System.out.println 이 1 번으로 나간다.
푸시: 내 컴퓨터(로컬 저장소)에 쌓아 둔 커밋을 GitHub 같은 원격 저장소로 올려 보내는 일이다. 커밋만 해 두고 푸시하지 않으면 그 기록은 내 컴퓨터 안에만 있고 다른 사람은 볼 수 없다. 푸시해야 비로소 다른 사람이나 배포 과정이 그 변경을 볼 수 있다.
풀: 원격 저장소에 쌓인 새 커밋을 내 컴퓨터(로컬 저장소)로 받아 와 지금 브랜치에 합치는 일이다. 다른 사람이 먼저 푸시해 둔 내용을 내 작업 폴더에도 반영하고 싶을 때 쓴다. 받아 온 내용이 내가 고친 부분과 겹치면 충돌이 날 수 있다.
프레임워크: 코드를 어디에 어떻게 두어야 하는지까지 미리 정해 둔 틀이다. 내가 빈 종이에서 시작하는 게 아니라, 이미 그려진 빈칸에 내 코드를 채워 넣는 것에 가깝다. 그래서 큰 흐름(언제 내 코드를 부를지)은 틀이 쥐고 있고, 나는 그 안에서 세부 내용만 짠다.
프로세스: 돌고 있는 프로그램 하나다. ps 가 줄마다 보여 주는 것이 프로세스이고, 각각 번호(PID)가 있다.
프로토콜: 주고받을 때 지킬 규칙이다. 먼저 무엇을 보내고 어떤 답을 기다릴지를 양쪽이 미리 맞춰 둔 것이다 — TCP 도 IP 도 프로토콜 하나다.
프록시: 원본을 대신 받아 주는 객체다. 겉모습은 원본과 같아서 쓰는 쪽은 눈치채지 못하고, 안에서 원본의 일을 시키기 전후에 일을 더 한다.
프롬프트: AI에게 무엇을 해 달라고 건네는 입력 문장이다. 질문이든 지시든 상관없이, AI가 읽고 반응하는 재료가 되는 글 전체를 가리킨다. 같은 질문이라도 프롬프트를 어떻게 적느냐에 따라 AI의 답이 달라진다.
프롬프트 캐시: 같은 내용을 다시 보낼 때 AI가 처음부터 다시 읽지 않도록, 앞서 보낸 프롬프트를 서버에 잠시 저장해 두는 기능이다. 매 턴 똑같이 들어가는 지침 파일 같은 부분이 캐시에 올라가 있으면, 다음 턴부터는 그 부분을 다시 읽는 비용이 훨씬 싸진다.
피연산자 스택: 프레임 안의 작은 스택이다. 계산하는 동안 값을 잠깐 올려 둔다. 최대 몇 칸이 필요한지는 javac가 컴파일할 때 계산해 .class 파일에 적어 둔다(javap 출력의 stack= 값).
필드: 객체나 구조체 안에 든 변수 하나다. 자바에서는 객체의 필드, C(리눅스 커널)에서는 구조체의 필드라고 부른다.
필터: 요청이 내 코드에 닿기 전에 먼저 거쳐 가는 부품이다. 글자 인코딩을 정하거나 시간을 재는 것처럼, 모든 요청에 공통으로 해야 할 일을 여기서 한다. order 값이 작을수록 먼저 거친다.
필터 체인 (Spring Security): Spring Security 가 요청을 검사하려고 줄줄이 세워 둔 필터들의 묶음이다. 한 요청이 Controller 에 닿기 전에 이 줄을 하나씩 통과하면서 「로그인은 했는가」, 「토큰은 유효한가」 같은 검사를 차례로 거친다. 중간에 하나라도 막으면 뒤 필터와 Controller 는 아예 불리지 않는다.
하네스: 본래는 테스트 코드를 자동으로 돌려주는 틀을 뜻하는 말이다. 이 블로그에서는 「AI 에이전트가 글 전체를 처음부터 끝까지 읽지 않고, 필요한 부분(섹션)만 찾아서 꺼내 쓰게 해주는 구조」를 가리키는 말로도 쓴다.
하드 링크: 같은 inode 를 가리키는 이름을 하나 더 만든 것이다. 이름이 둘이어도 알맹이는 하나이고, 이름이 다 떨어져야 알맹이가 없어진다.
하트비트: 「나 아직 살아 있다」는 신호를 일정한 간격으로 계속 보내는 방식이다. 신호가 끊기면 그 주체가 멈췄거나 죽었다고 판단한다. 사람의 심장 박동처럼 일정하게 뛰는 모습에서 이름을 따왔다.
해시: 비밀번호를 그대로 적지 않고 되돌릴 수 없게 뭉개 놓은 글자 덩어리다. 맞는지 보려면 들어온 비밀번호를 같은 방법으로 뭉개서 견준다 — 그래서 파일을 훔쳐도 원래 비밀번호는 안 나온다.
해시 테이블: 키(이름표)로 값을 빠르게 찾아주는 자료구조다. 키를 숫자로 뭉개는 계산(해시 함수)을 거쳐 그 숫자가 가리키는 칸에 값을 넣어두면, 나중에 같은 키로 같은 칸을 바로 찾아가 값을 꺼낸다. 목록을 처음부터 끝까지 뒤지지 않아도 돼서 찾는 속도가 거의 O(1)이다. 자바의 HashMap이 이 구조로 만들어져 있다.
핸들러 매핑: 「이 주소는 이 메서드」를 적어 둔 표다. 기동할 때 만들어지고, 요청이 오면 DispatcherServlet 이 이 표를 보고 부를 메서드를 고른다. 표는 하나가 아니라 여럿이고 보는 순서가 정해져 있다. 이 페이지에서 「표 1 · 표 2 · 표 3」이라고 부르는 것이 이것이다.
행(row): 테이블에 저장된 데이터 한 건이다. users 테이블의 행 하나는 회원 한 명의 정보를 담고, 컬럼이 그 정보의 항목(이름, 이메일 등)이라면 행은 그 항목에 실제 값이 채워진 한 줄이다. SELECT로 테이블을 조회하면 조건에 맞는 행이 여러 개 돌아온다.
헤더 (HTTP): 요청이나 응답의 본문 앞에 붙어서 부가 정보를 적는 자리다. 택배의 운송장과 같다 — 누가 보냈는지, 내용물이 무슨 형식인지, 언제 다시 확인해야 하는지 같은 것을 적는다. Content-Type, Cookie 같은 이름이 모두 헤더의 한 종류다.
호스트: 네트워크에 연결된 컴퓨터 한 대, 또는 그 컴퓨터를 가리키는 이름이나 주소다. 주소 example.com 에서 호스트는 example.com 부분이고, 포트는 그 컴퓨터 안의 특정 프로그램을 가리키는 번호다. localhost는 「지금 이 컴퓨터」를 가리키는 특별한 호스트 이름이다.
호출량 한도(rate limit) · Retry-After: 서버가 같은 클라이언트의 요청을 짧은 시간 안에 너무 많이 받으면 그 이상은 거절하는 제한이다. 한도에 걸리면 보통 429 같은 상태 코드로 응답하는데, 언제 다시 보낼 수 있는지까지 알려주는 서버는 응답 헤더에 Retry-After 로 남은 시간을 싣는다. 이 값이 없으면 클라이언트는 언제 풀리는지 알 방법이 없다.
화면 읽기 도구: 화면을 눈으로 보지 않고 소리로 듣는 사람을 위해 화면의 글자와 버튼 이름을 읽어 주는 프로그램이다. 시각 장애가 있는 사람이 주로 쓰고, 영어로는 스크린 리더(screen reader)라고 부른다. 버튼에 aria-label이나 role 같은 값을 붙여 두면 이 도구가 그 값을 읽어서 사용자에게 알려 준다.
화살표 함수: 화살표(=>)를 써서 함수를 짧게 적는 자바스크립트 문법이다. `function` 키워드 없이 `(매개변수) => 실행할 코드` 형태로 "이 값을 받으면 이 일을 한다"를 적는다. 예를 들어 `res => res.json()`은 `res`를 받아서 `res.json()`을 실행하고 그 결과를 돌려주는 함수다.
환경 (OS·개발 환경): 프로그램이 실제로 돌아가는 바탕을 말한다. 운영체제(OS)가 Windows인지 Linux인지, 설치된 프로그램의 버전이 무엇인지, 어떤 설정값을 쓰는지 같은 것들을 통틀어 환경이라 부른다. 「내 컴퓨터에서는 되는데 다른 컴퓨터에서는 안 된다」는 문제는 대부분 이 환경이 서로 다른 것이 원인이다.
환경변수: 컴퓨터가 들고 있는 「이름=값」 쌍이다. 프로그램을 고치지 않고도 밖에서 값을 바꿔 넣을 수 있어서, 설정 파일 대신 쓰기도 한다.
훅: 커널이 「여기서 한 번 물어본다」고 미리 비워 둔 자리다. 보안 모듈이 그 자리에 자기 검사를 꽂아 두면, 커널이 그 지점을 지날 때마다 불러 준다.
훅 (Git·Claude Code): 어떤 일이 벌어지는 특정 시점에 자동으로 끼어들어 정해진 동작을 실행하게 걸어 두는 장치다. Git에서는 커밋 같은 동작 전후에 끼어들고, Claude Code 같은 에이전트 도구에서는 답을 멈출 때처럼 정해진 시점에 끼어들어 검사나 알림을 실행한다. 사람이 매번 손으로 하던 일을 그 시점마다 자동으로 돌게 만드는 것이 목적이다.
히스토리: 저장소에 쌓인 커밋들을 시간 순서로 이어 놓은 전체 기록이다. 어느 시점에 누가 무엇을 왜 고쳤는지가 이 기록에 그대로 남는다. 커밋을 되돌리거나 덮어쓰면 이 기록 자체가 바뀌므로, 이미 다른 사람이 본 히스토리를 고치면 그 사람이 가진 기록과 어긋난다.
힙: new로 만든 객체가 들어가는 JVM의 메모리 영역이다. 모든 스레드가 함께 쓰고, 더는 쓰지 않는 객체는 GC가 치운다. int 같은 지역 변수 값은 힙이 아니라 프레임의 칸에 들어간다.
힙 (자료구조): 부모 노드가 자식 노드보다 항상 크거나(최대 힙) 항상 작은(최소 힙) 완전 이진 트리다. 배열 하나에 그대로 담을 수 있어서 트리를 따로 만들지 않고도 맨 위 값(가장 크거나 가장 작은 값)을 바로 꺼낼 수 있고, 값을 넣거나 맨 위 값을 꺼낼 때마다 트리 높이만큼만 자리를 바꾸면 되므로 둘 다 O(log n)이 걸린다. 힙 정렬은 이 자료구조에서 맨 위 값을 하나씩 꺼내 정렬한다. JVM이 객체를 담는 메모리 영역인 [힙](/term/heap)과는 이름만 같고 다른 개념이다.

자신만의 철학을 만들어가는 중입니다.

최상단으로 이동했습니다!