개발상식/기타

기본 답변

가상화는 물리 자원을 추상화해 여러 환경이 독립적으로 사용하는 것처럼 보이게 하는 기술입니다.

CPU, 메모리, 스토리지, 네트워크 등을 논리적으로 나눠 사용할 수 있습니다.

가상머신은 가상화 기술로 만들어진 실행 환경 중 하나이며, 하이퍼바이저가 가상 하드웨어를 제공하고 그 위에서 게스트 OS를 실행합니다.

컨테이너는 VM과 다른 격리 방식으로, 호스트 OS 커널을 공유하면서 프로세스를 격리합니다. 일반적으로 VM은 독립된 커널 덕분에 격리 경계가 강한 대신 자원 비용이 크고, 컨테이너는 가볍고 배포가 빠른 대신 공유 커널을 고려해야 합니다.

핵심 키워드

• Virtualization
• Hypervisor
• Virtual Machine
• Container
• Isolation
• Namespace/Cgroup

꼬리질문

주의할 점

• 컨테이너는 VM보다 가볍지만 VM과 같은 수준의 완전한 OS 격리는 아닙니다.

기본 답변

CI는 Continuous Integration으로, 코드 변경이 자주 통합될 때 자동으로 빌드와 테스트를 수행해 문제를 빨리 발견하는 방식입니다.

CD는 Continuous Delivery 또는 Deployment로, 검증된 변경 사항을 배포 가능한 상태로 만들거나 실제 환경에 자동 배포하는 흐름입니다.

실무에서는 Git push나 PR 생성 시 테스트, 정적 분석, 빌드가 실행되고, main 브랜치 병합 후 staging 또는 production 배포 파이프라인이 동작하는 식으로 구성합니다.

핵심 키워드

• CI
• CD
• Pipeline
• Build
• Test
• Deploy

꼬리질문

주의할 점

• CI/CD는 도구 이름이 아니라 개발과 배포를 안정적으로 반복하기 위한 프로세스입니다.

기본 답변

static은 인스턴스가 아니라 클래스 자체에 속한다는 의미입니다.

Java에서 static 필드와 메서드는 객체를 생성하지 않고 클래스 이름으로 접근할 수 있고, 모든 인스턴스가 공유합니다.

상수, 유틸리티 메서드, 공유 상태 표현에 사용할 수 있지만, 전역 상태처럼 남용하면 테스트가 어려워지고 동시성 문제가 생길 수 있습니다.

핵심 키워드

• Class Level
• Static Field
• Static Method
• Shared State
• Class Loading
• Static Final

꼬리질문

주의할 점

• static final 참조 타입은 참조 재할당이 안 된다는 뜻이지 객체 내부가 항상 불변이라는 뜻은 아닙니다.

기본 답변

객체지향 프로그래밍은 데이터와 그 데이터를 다루는 행위를 객체로 묶고, 객체 간 협력으로 프로그램을 구성하는 방식입니다.

핵심 개념은 캡슐화, 추상화, 상속, 다형성입니다.

좋은 객체지향 설계는 단순히 클래스를 많이 만드는 것이 아니라, 변경에 강하고 책임이 명확한 객체들이 낮은 결합도와 높은 응집도를 갖도록 구성하는 것입니다.

핵심 키워드

• Encapsulation
• Abstraction
• Inheritance
• Polymorphism
• SOLID
• Cohesion/Coupling

꼬리질문

주의할 점

• 객체지향을 “상속을 많이 쓰는 것”으로 설명하면 좋지 않습니다. 역할, 책임, 협력이 더 중요합니다.

기본 답변

라이브러리는 개발자가 필요할 때 호출해서 사용하는 코드 모음입니다.

제어 흐름은 개발자 코드가 갖고 있습니다.

프레임워크는 애플리케이션의 기본 구조와 실행 흐름을 제공하고, 개발자는 그 안에 필요한 코드를 넣습니다.

핵심 차이는 제어의 역전입니다.

라이브러리는 내가 호출하고, 프레임워크는 프레임워크가 내 코드를 호출합니다.

핵심 키워드

• Library
• Framework
• Inversion of Control
• Control Flow
• Extension Point
• Convention

꼬리질문

주의할 점

• 프레임워크와 라이브러리의 차이는 크기보다 제어 흐름의 주도권입니다.

기본 답변

Call by value는 함수 호출 시 값이 복사되어 전달되는 방식이고, call by reference는 변수의 참조 자체가 전달되어 함수 안에서 원본 변수에 영향을 줄 수 있는 방식입니다.

Java는 항상 call by value입니다.

객체를 넘길 때도 객체 자체가 아니라 객체를 가리키는 참조값이 복사되어 전달됩니다.

그래서 객체 내부 상태 변경은 보이지만, 매개변수에 새 객체를 대입해도 호출자의 참조가 바뀌지는 않습니다.

핵심 키워드

• Call by Value
• Call by Reference
• Reference Value
• Java
• Mutable Object
• Parameter Passing

꼬리질문

주의할 점

• Java를 call by reference라고 말하면 면접에서 지적받기 쉽습니다.

기본 답변

순수함수는 같은 입력에 항상 같은 출력을 반환하고, 외부 상태를 변경하는 side effect가 없는 함수입니다.

함수형 프로그래밍은 이런 순수함수와 불변성을 바탕으로 예측 가능하고 조합하기 쉬운 코드를 작성하려는 패러다임입니다.

순수함수는 테스트가 쉽고 동시성 환경에서도 안전하게 다루기 좋습니다.

하지만 실제 애플리케이션은 I/O, DB, 네트워크처럼 side effect가 필요하므로 이를 격리하고 관리하는 것이 중요합니다.

핵심 키워드

• Pure Function
• Side Effect
• Immutability
• Higher-order Function
• Referential Transparency
• Functional Programming

꼬리질문

주의할 점

• 함수형 프로그래밍은 side effect를 완전히 없애는 것이 아니라 제어 가능한 경계로 밀어내는 데 의미가 있습니다.

기본 답변

MVC는 Model, View, Controller로 역할을 나누는 아키텍처 패턴입니다.

Model은 데이터와 비즈니스 규칙, View는 사용자에게 보여지는 화면, Controller는 사용자의 입력을 받아 Model과 View를 연결하는 역할을 합니다.

관심사를 분리해 유지보수성을 높이고, 화면과 비즈니스 로직의 결합을 줄이는 것이 목적입니다.

핵심 키워드

• Model
• View
• Controller
• Separation of Concerns
• Spring MVC
• Presentation Layer

꼬리질문

주의할 점

• Spring MVC에서 Controller에 비즈니스 로직을 모두 넣으면 MVC의 장점을 살리기 어렵습니다.

기본 답변

디자인 패턴은 자주 반복되는 설계 문제에 대한 검증된 해결 방법입니다.

코드 조각이라기보다 객체 간 역할과 관계를 설명하는 설계 언어에 가깝습니다.

대표적으로 생성 패턴의 Singleton, Factory, Builder, 구조 패턴의 Adapter, Decorator, Proxy, 행위 패턴의 Strategy, Observer, Template Method 등이 있습니다.

핵심 키워드

• Design Pattern
• Singleton
• Factory
• Strategy
• Observer
• Proxy

꼬리질문

주의할 점

• 패턴은 무조건 적용하는 것이 아니라 문제 상황이 있을 때 선택하는 도구입니다.

기본 답변

GC는 Garbage Collection으로, 더 이상 사용되지 않는 객체를 자동으로 찾아 메모리를 회수하는 기능입니다.

개발자가 직접 메모리를 해제하지 않아도 되어 메모리 관리 오류를 줄일 수 있습니다.

GC는 보통 root에서 도달 가능한 객체를 살아 있는 객체로 보고, 도달할 수 없는 객체를 수거 대상으로 판단합니다.

Java에서는 힙 영역의 객체가 주요 관리 대상입니다.

핵심 키워드

• Garbage Collection
• Heap
• GC Root
• Reachability
• Mark and Sweep
• Reference Counting

꼬리질문

주의할 점

• GC가 있다고 메모리 누수가 사라지는 것은 아닙니다. 불필요한 참조를 계속 들고 있으면 수거되지 않습니다.

기본 답변

32비트와 64비트는 CPU가 한 번에 처리할 수 있는 레지스터 크기와 주소 표현 능력과 관련이 있습니다.

32비트는 주소를 32비트로 표현하므로 이론적으로 4GB 주소 공간을 가집니다.

64비트는 훨씬 큰 주소 공간을 표현할 수 있습니다.

64비트 환경은 더 큰 메모리를 사용할 수 있고 레지스터와 명령어 셋 차이로 성능상 이점도 있을 수 있지만, 포인터 크기가 커져 메모리 사용량이 늘 수 있습니다.

핵심 키워드

• 32-bit
• 64-bit
• Address Space
• Pointer Size
• Register
• 4GB

꼬리질문

주의할 점

• 가상 주소 공간 한계와 실제 물리 RAM 사용 한계를 구분해야 합니다.

기본 답변

인증은 사용자가 누구인지 확인하는 과정이고, 인가는 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 확인하는 과정입니다.

예를 들어 로그인은 인증이고, 관리자 페이지 접근 가능 여부를 판단하는 것은 인가입니다.

보안 설계에서는 두 단계를 명확히 분리해야 합니다.

핵심 키워드

• Authentication
• Authorization
• Principal
• Role
• Permission
• OAuth

꼬리질문

주의할 점

• OAuth를 로그인 프로토콜이라고만 말하면 부족합니다. 인증은 OIDC까지 함께 설명하는 것이 정확합니다.

기본 답변

JWT는 당사자 사이에 claim을 전달하기 위한 JSON 기반 토큰 형식입니다. 인증 방식 그 자체라기보다 인증·인가 시스템에서 access token 등의 표현 형식으로 사용할 수 있습니다.

서명된 compact JWS 형태는 보통 header.payload.signature 세 부분으로 구성되며 서명으로 위변조 여부를 확인합니다. JWT는 암호화된 JWE나 중첩 형태로도 표현될 수 있습니다.

JWT를 사용한다고 시스템이 자동으로 stateless해지는 것은 아닙니다. 서버 저장소 없이 서명과 claim만 검증하도록 설계할 수 있지만, 폐기 목록·세션·refresh token을 관리하면 서버 상태가 생깁니다.

발급 후 만료 전까지 강제 폐기가 어려울 수 있고 탈취 시 위험하므로 만료 시간, key 관리, refresh token, 저장 위치와 폐기 정책을 신중히 설계해야 합니다.

핵심 키워드

• JWT
• Header
• Payload
• Signature
• Access Token
• Refresh Token

꼬리질문

주의할 점

• 일반적인 서명형 JWT payload는 Base64URL 인코딩됐을 뿐 암호화된 것이 아닙니다. 민감 정보를 넣지 않아야 하며 기밀성이 필요하면 JWE 같은 암호화 형식을 사용해야 합니다.
• 서명이 유효하다는 사실만으로 현재 사용자 상태, 권한, 토큰 폐기 여부까지 자동으로 보장되지는 않습니다.

기본 답변

암호화는 데이터를 권한 없는 사람이 읽을 수 없도록 변환하는 기술입니다.

크게 대칭키 암호화와 비대칭키 암호화로 나눌 수 있습니다.

대칭키는 같은 키로 암호화와 복호화를 수행해 빠르고, 비대칭키는 공개키와 개인키 쌍을 사용해 키 교환이나 전자서명에 유리합니다.

비밀번호 저장에는 복호화 가능한 암호화가 아니라 해시와 salt, 느린 KDF를 사용해야 합니다.

핵심 키워드

• Symmetric Encryption
• Asymmetric Encryption
• Hash
• Salt
• KDF
• TLS

꼬리질문

주의할 점

• 직접 암호 알고리즘을 만들거나 검증되지 않은 방식으로 조합하면 위험합니다.

기본 답변

문자열 인코딩은 문자를 컴퓨터가 저장하고 전송할 수 있는 바이트로 변환하는 규칙입니다.

ASCII, EUC-KR, UTF-8, UTF-16 등이 대표적입니다.

UTF-8은 유니코드 문자를 가변 길이 바이트로 표현하며, ASCII와 호환되고 웹에서 널리 사용됩니다.

인코딩이 맞지 않으면 한글 깨짐 같은 문제가 발생합니다.

핵심 키워드

• Character Set
• Encoding
• Unicode
• UTF-8
• ASCII
• Base64

꼬리질문

주의할 점

• Base64는 보안 목적의 암호화가 아닙니다.

기본 답변

Git은 분산 버전 관리 시스템입니다.

파일의 변경 이력을 commit 단위로 저장하고, branch를 통해 여러 작업 흐름을 독립적으로 진행할 수 있습니다.

중앙 서버 없이도 로컬 저장소에 전체 이력을 가지고 작업할 수 있으며, 원격 저장소와 push/pull/fetch로 동기화합니다.

핵심 키워드

• Repository
• Commit
• Branch
• Merge
• Rebase
• Remote

꼬리질문

주의할 점

• 이미 공유된 브랜치를 함부로 rebase하고 force push하면 협업자 이력을 망가뜨릴 수 있습니다.

기본 답변

단위 테스트는 함수나 클래스처럼 작은 테스트 경계를 빠르고 독립적으로 검증합니다. 통합 테스트는 데이터베이스, 메시지 브로커, 프레임워크 설정처럼 여러 구성 요소의 실제 협력을 확인하고, E2E 테스트는 사용자 요청부터 최종 응답까지 배포된 시스템의 전체 흐름을 검증합니다.

단위 테스트의 “단위”가 반드시 메서드 하나를 뜻하지는 않습니다. 외부에서 관찰할 수 있는 행위와 계약을 경계로 잡고, 느리거나 제어하기 어려운 의존성만 테스트 더블로 대체해야 리팩터링에 강한 테스트가 됩니다. 반대로 SQL, 트랜잭션, 직렬화처럼 실제 기술의 동작이 중요한 경계는 통합 테스트로 확인해야 합니다.

테스트 피라미드는 빠른 단위 테스트를 넓게 두고 비용이 큰 통합·E2E 테스트를 핵심 경로에 집중하라는 경험칙입니다. 고정된 비율보다 장애 위험, 변경 빈도와 외부 의존성의 중요도를 기준으로 조절하며, 서비스 사이의 요청·응답 스키마나 이벤트 계약은 계약 테스트로 각 서비스를 모두 실행하지 않고도 호환성을 검증할 수 있습니다.

좋은 자동 테스트는 같은 입력에서 반복 가능한 결과를 내고 서로의 실행 순서나 공유 상태에 의존하지 않아야 합니다. 시간, 난수, 네트워크, 공유 DB와 비동기 타이밍을 제어하고 테스트별 데이터를 격리해야 병렬 실행과 실패 재현이 쉬워집니다. 다만 실제 환경과 지나치게 동떨어진 가짜 구현만 사용하면 잘못된 확신을 줄 수 있으므로 속도와 현실성 사이의 균형이 필요합니다.

핵심 키워드

• Unit Test
• Integration Test
• E2E Test
• Test Pyramid
• Test Double
• Determinism
• Test Isolation
• Contract Test

꼬리질문

주의할 점

• 테스트 개수나 커버리지만으로 결함 탐지 능력을 판단하면 안 됩니다.
• DB를 Mock으로 대체한 테스트만으로 실제 쿼리와 트랜잭션을 검증할 수는 없습니다.
• 테스트 사이에 실행 순서 의존성이나 공유 상태가 생기면 개별 실행은 통과해도 전체·병렬 실행에서 실패할 수 있습니다.

기본 답변

직렬화는 메모리의 데이터나 객체 상태를 저장·전송 가능한 텍스트 또는 바이트 표현으로 바꾸는 과정이고, 역직렬화는 그 표현을 프로그램이 사용할 데이터로 복원하는 과정입니다. HTTP 메시지, 이벤트, 캐시와 파일처럼 프로세스나 시간의 경계를 넘을 때 사용하므로 메모리 객체 구조와 전송 형식을 같은 것으로 보면 안 됩니다.

JSON은 사람이 읽기 쉽고 다양한 환경에서 지원되지만 필드 이름이 반복되어 크기가 커지고 숫자 타입이나 날짜 표현을 별도로 합의해야 할 수 있습니다. Protocol Buffers 같은 스키마 기반 이진 형식은 보통 더 작은 payload와 빠른 처리를 기대할 수 있지만 스키마와 생성 코드 관리가 필요합니다. 실제 성능은 데이터 형태, 압축, 파서 구현과 네트워크 비용에 따라 달라지므로 대표 데이터로 크기와 CPU 사용량을 측정해야 합니다.

스키마를 진화시킬 때는 기존 필드의 이름·타입·의미를 함부로 바꾸지 않고 새 필드는 선택적으로 추가하는 것이 안전합니다. 필드 번호를 사용하는 이진 형식에서는 기존 번호를 재사용하지 말고 제거한 번호를 예약해야 하며, 소비자는 알 수 없는 필드를 허용하고 누락된 필드의 기본 동작을 정의해야 합니다. 새 작성자의 데이터를 옛 독자가 읽는 forward compatibility와 옛 데이터를 새 독자가 읽는 backward compatibility를 각각 확인해야 합니다.

역직렬화 입력은 신뢰 경계로 취급해야 합니다. 허용할 타입과 필드를 제한하고 payload 크기, 중첩 깊이, 컬렉션 길이와 처리 시간을 제한하며 복원된 값에 업무 규칙 검증을 다시 적용해야 합니다. 특히 임의 타입을 생성하거나 실행 훅을 호출하는 네이티브 객체 역직렬화는 신뢰할 수 없는 데이터에 사용하지 않는 것이 원칙입니다.

핵심 키워드

• Serialization
• Deserialization
• JSON
• Binary Format
• Wire Format
• Schema Evolution
• Backward Compatibility
• Forward Compatibility

꼬리질문

주의할 점

• 직렬화는 암호화가 아닙니다.
• 신뢰할 수 없는 입력의 임의 객체 역직렬화는 코드 실행이나 자원 고갈 취약점을 만들 수 있습니다.
• “이진 형식이 항상 더 빠르다”는 가정 대신 실제 payload와 운영 환경에서 측정해야 합니다.

기본 답변

API 계약에는 URL과 HTTP 메서드뿐 아니라 요청·응답 필드의 이름, 타입과 필수 여부, 상태 코드, 오류 형식, 정렬·페이지네이션 규칙과 데이터의 의미도 포함됩니다. 서버가 변경된 뒤에도 기존 클라이언트가 수정 없이 의도대로 동작해야 하위 호환성이 유지됩니다.

선택 필드 추가는 일반적으로 호환 가능하지만 엄격한 역직렬화기나 전체 필드 일치를 가정한 소비자는 깨질 수 있습니다. 새 enum 값, nullable 변경, 기본값이나 단위 변경도 문법상 타입이 같아 보여도 기존 분기와 업무 의미를 깨뜨릴 수 있습니다. 삭제, 이름·타입 변경과 의미 재사용처럼 계약을 깨는 변경은 별도 버전이나 단계적 이전이 필요합니다.

버전은 /v2 같은 URI, 전용 헤더, 또는 Accept와 vendor media type을 이용한 content negotiation으로 표현할 수 있습니다. URI 방식은 눈에 잘 보이고 라우팅·캐시가 단순하지만 리소스 URL이 버전에 묶이고, 헤더·미디어 타입 방식은 URL을 유지할 수 있지만 브라우저 확인과 운영 도구 설정이 복잡해질 수 있습니다. 팀과 소비자 환경에 맞는 한 가지 정책을 일관되게 적용해야 합니다.

Breaking change를 배포할 때는 새 버전을 병행하고 구버전 사용량과 소비자별 이전 상태를 관찰해야 합니다. 폐기 예정과 종료 시점을 문서·응답 헤더 등으로 알리고, 계약 테스트와 실제 트래픽 분석으로 예상하지 못한 소비자를 확인하며, 충분한 유예 기간과 롤백 경로를 둔 뒤 구버전을 종료합니다.

핵심 키워드

• API Contract
• Backward Compatibility
• Breaking Change
• Versioning
• Deprecation
• Contract Test
• Content Negotiation
• Sunset Policy

꼬리질문

주의할 점

• URL 버전만 올린다고 데이터 의미의 호환 문제가 자동으로 해결되지는 않습니다.
• 너무 많은 버전을 장기간 유지하면 보안과 운영 비용이 커집니다.
• 서버 관점의 스키마 비교만으로 호환성을 단정하지 말고 실제 소비자의 역직렬화와 업무 분기를 확인해야 합니다.