woohaha

[Frontend] 이벤트루프 완전 정복 - 콜스택, 마이크로태스크, 태스크큐 한 번에

woohaha — Mon, 1 Jun 2026 19:01:51 +0900

CS 면접 대비 · 프론트엔드

면접에서 "JS는 싱글스레드인데 어떻게 비동기 처리를 하나요?"라고 물어보면
이벤트루프를 설명할 수 있어야 해요.
콜스택, 태스크큐, 마이크로태스크까지 한 번에 정리해드릴게요!

// TABLE OF CONTENTS

01 JS는 싱글스레드

02 이벤트루프 구성요소

03 콜스택 (Call Stack)

04 Web APIs

05 태스크큐 vs 마이크로태스크큐

06 실행 순서 예제

07 Promise / async 실행 순서

08 면접 답변 정리

01 JS는 싱글스레드

JavaScript는 싱글스레드 언어예요.
한 번에 하나의 작업만 처리할 수 있어요.
그런데 어떻게 setTimeout, fetch 같은 비동기 작업을 처리할까요?
바로 이벤트루프(Event Loop) 덕분이에요!

핵심 개념 JS 엔진은 싱글스레드지만, 브라우저(런타임)는 멀티스레드예요.
setTimeout, fetch, DOM 이벤트 같은 비동기 작업은 Web API(브라우저)가 처리하고,
완료되면 콜백을 큐에 넣어서 JS 엔진이 나중에 실행하는 구조예요.

02 이벤트루프 구성요소

// 이벤트루프 전체 구조

Call Stack

console.log()

setTimeout()

fetch()

JS 코드 실행 공간

Web APIs

Timer (setTimeout)

HTTP (fetch/XHR)

DOM Events

브라우저가 처리

✅ Microtask Queue

Promise.then()

queueMicrotask()

MutationObserver

우선순위 높음

Macrotask Queue (Task Queue)

setTimeout 콜백

setInterval 콜백

DOM 이벤트 핸들러

우선순위 낮음

Event Loop

콜스택 비면
마이크로태스크 → 매크로태스크
순으로 콜백 가져옴

03 콜스택 (Call Stack)

함수가 호출되면 콜스택에 쌓이고, 함수가 끝나면 콜스택에서 제거돼요.
LIFO(Last In First Out) 구조예요.

콜스택 동작 예시

function c() { console.log('c'); }

function b() { c(); }

function a() { b(); }

a();

// 콜스택 변화

// [a]

// [a, b]

// [a, b, c]  ← c 실행

// [a, b]     ← c 완료 후 제거

// [a]        ← b 완료 후 제거

// []         ← a 완료 후 제거 = 콜스택 비어있음!

⚠️ 콜스택이 꽉 차면? 재귀함수가 무한히 호출되면 콜스택이 가득 차서
"Maximum call stack size exceeded" 에러가 발생해요.
이게 바로 스택 오버플로우(Stack Overflow)예요!

04 Web APIs — 비동기 작업은 브라우저가

setTimeout / setInterval

타이머 작업. 브라우저가 시간을 재고 완료되면 콜백을 태스크큐에 넣어요.

setTimeout(() => ..., 1000) → 1초 후 태스크큐에 추가

fetch / XHR

HTTP 요청. 브라우저가 네트워크 통신하고 완료 시 콜백 처리.

fetch() → 서버 응답 후 .then() 실행

DOM 이벤트

클릭, 키보드 등 이벤트. 브라우저가 감지하고 핸들러를 태스크큐에 추가.

btn.click() → onclick 핸들러 태스크큐에 추가

requestAnimationFrame

다음 렌더링 전에 실행. 애니메이션 최적화에 사용. 약 16ms(60fps) 주기.

05 태스크큐 vs 마이크로태스크큐

이벤트루프의 핵심은 우선순위예요.
콜스택이 비면 마이크로태스크큐를 먼저, 다 비운 다음 태스크큐를 처리해요.

구분	마이크로태스크큐	태스크큐 (매크로태스크)
우선순위	높음 (먼저 처리)	낮음 (나중에 처리)
포함 항목	Promise.then/catch, queueMicrotask, MutationObserver	setTimeout, setInterval, DOM 이벤트, fetch 콜백
처리 방식	큐가 완전히 빌 때까지 모두 처리	한 번에 하나씩 처리 후 렌더링
렌더링	마이크로태스크 처리 후 렌더링	매크로태스크 하나 처리 후 렌더링 가능

이벤트루프 실행 순서 ① 콜스택의 동기 코드 전부 실행
② 마이크로태스크큐 전부 처리 (Promise.then 등)
③ 렌더링 (필요한 경우)
④ 태스크큐에서 하나 꺼내 실행 (setTimeout 등)
⑤ ②~④ 반복

06 실행 순서 예제

실행 순서 퀴즈 — 출력 순서는?

console.log('1');                    // ①

setTimeout(() => {

  console.log('2');               // ⑤ 태스크큐

}, 0);

Promise.resolve().then(() => {

  console.log('3');               // ③ 마이크로태스크큐

});

Promise.resolve().then(() => {

  console.log('4');               // ④ 마이크로태스크큐

});

console.log('5');                    // ②

// 출력 순서: 1 → 5 → 3 → 4 → 2

// 단계별 실행 설명

① '1' 출력 ← 동기 코드, 콜스택에서 즉시 실행

- setTimeout 등록 ← Web API가 타이머 시작, 0ms 후 태스크큐에 콜백 추가

- Promise.then 등록 ← 마이크로태스크큐에 콜백 2개 추가

② '5' 출력 ← 동기 코드, 콜스택에서 즉시 실행

③ '3' 출력 ← 콜스택 비어있음 → 마이크로태스크큐 처리 시작

④ '4' 출력 ← 마이크로태스크큐 두 번째 콜백

⑤ '2' 출력 ← 마이크로태스크 완료 → 태스크큐에서 setTimeout 콜백 실행

07 Promise / async-await 실행 순서

async/await 실행 순서

async function main() {

  console.log('A');           // ①

  await Promise.resolve();  // await 만나면 여기서 멈추고 제어권 반환

  console.log('B');           // ④ await 이후 코드는 마이크로태스크로

}

console.log('C');               // ②

main();

console.log('D');               // ③

// 출력: C → A → D → B

// 왜냐하면...

// 1. C 출력 (동기)

// 2. main() 호출 → A 출력

// 3. await 만나서 main() 일시 중단, 제어권 반환

// 4. D 출력 (동기)

// 5. 콜스택 비어짐 → 마이크로태스크 처리 → B 출력

심화 — 중첩 Promise 실행 순서

console.log('start');                           // ①

setTimeout(() => console.log('timeout'), 0);  // ⑥ 태스크큐

Promise.resolve()

  .then(() => {

    console.log('promise 1');              // ③ 마이크로태스크

    return Promise.resolve();

  })

  .then(() => console.log('promise 2'));    // ④ 마이크로태스크

Promise.resolve()

  .then(() => console.log('promise 3'));    // ⑤ 마이크로태스크

console.log('end');                             // ②

// 출력: start → end → promise 1 → promise 3 → promise 2 → timeout

// promise 2가 3보다 늦는 이유:

// promise 1의 then에서 새 Promise를 반환하면

// promise 2는 마이크로태스크 큐 뒤로 밀림!

08 면접 답변 정리

면접 예상 Q&A

Q. JS는 싱글스레드인데 어떻게 비동기 처리를 하나요?

"JS 엔진 자체는 싱글스레드이지만, 브라우저의 Web API가

setTimeout, fetch 같은 비동기 작업을 별도로 처리합니다.

작업이 완료되면 콜백을 태스크큐에 넣고,

이벤트루프가 콜스택이 비어있을 때 큐에서 꺼내 실행합니다."

Q. Promise와 setTimeout 중 무엇이 먼저 실행되나요?

"Promise.then은 마이크로태스크큐에, setTimeout은 태스크큐에 들어갑니다.

이벤트루프는 콜스택이 비면 마이크로태스크큐를 먼저 전부 처리한 후

태스크큐를 처리하므로 Promise.then이 setTimeout보다 먼저 실행됩니다."

✅ CONCLUSION 콜스택 → JS 코드 실행 공간 (LIFO)
Web APIs → 브라우저가 비동기 작업 처리
마이크로태스크큐 → Promise.then, 우선순위 높음
태스크큐 → setTimeout, 우선순위 낮음
이벤트루프 → 콜스택 비면 마이크로 → 매크로 순으로 실행

실행 순서: 동기 → 마이크로태스크 → 렌더링 → 매크로태스크 로 기억하세요!

JavaScript 이벤트루프 콜스택 마이크로태스크 태스크큐 Promise 비동기 CS면접 프론트엔드

[JavaScript] - map filter reduce 함수

woohaha — Fri, 29 May 2026 18:15:58 +0900

코딩테스트 · JavaScript

JS 코테에서 map / filter / reduce는 거의 매번 나와요.
세 가지를 확실히 이해하고 체이닝까지 자유자재로 쓸 수 있으면
JS 코테 절반은 먹고 들어갑니다!

// TABLE OF CONTENTS

01 세 함수 핵심 요약

02 map — 변환

03 filter — 필터링

04 reduce — 축약

05 체이닝 — 연결해서 쓰기

06 실전 코테 패턴

07 forEach vs map 차이

08 한눈에 비교

01 세 함수 핵심 요약

// 세 함수의 역할

[1, 2, 3, 4, 5] → map(×2) → [2, 4, 6, 8, 10] ← 모든 요소 변환, 길이 동일

[1, 2, 3, 4, 5] → filter(짝수) → [2, 4] ← 조건에 맞는 요소만, 길이 줄어듦

[1, 2, 3, 4, 5] → reduce(합산) → 15 ← 하나의 값으로 축약

02 map — 모든 요소를 변환

map은 배열의 모든 요소를 변환해서 새 배열을 반환해요.
원본 배열은 변경되지 않고, 항상 같은 길이의 새 배열이 나와요.

map 기본 & 활용

// 기본 문법

// array.map((현재값, 인덱스, 원본배열) => 변환값)

const nums = [1, 2, 3, 4, 5];

// 모든 요소에 ×2

const doubled = nums.map(n => n * 2);

// [2, 4, 6, 8, 10]

// 객체 배열에서 특정 필드 추출

const users = [

  { name: 'Alice', age: 25 },

  { name: 'Bob',   age: 30 },

  { name: 'Carol', age: 22 },

];

const names = users.map(user => user.name);

// ['Alice', 'Bob', 'Carol']

const ageNext = users.map(user => ({

  ...user,

  age: user.age + 1  // 나이 +1

}));

// [{name:'Alice', age:26}, ...]

// 인덱스 활용

const indexed = nums.map((n, i) => `${i}번째: ${n}`);

// ['0번째: 1', '1번째: 2', ...]

map의 핵심 입력 배열 길이 = 출력 배열 길이 항상 동일!
원본 배열을 변경하지 않고 새 배열을 반환해요.
반환값이 없으면 undefined로 채워지니 주의.

03 filter — 조건에 맞는 요소만

filter는 조건(true/false)에 맞는 요소만 골라서 새 배열을 반환해요.
원본 배열보다 길이가 같거나 짧아져요.

filter 기본 & 활용

// 기본 문법

// array.filter((현재값, 인덱스, 원본배열) => true/false)

const nums = [1, 2, 3, 4, 5, 6];

// 짝수만

const evens = nums.filter(n => n % 2 === 0);

// [2, 4, 6]

// 3 이상만

const over3 = nums.filter(n => n >= 3);

// [3, 4, 5, 6]

// 객체 배열 필터링

const users = [

  { name: 'Alice', age: 25, active: true  },

  { name: 'Bob',   age: 17, active: false },

  { name: 'Carol', age: 30, active: true  },

];

// 성인 + 활성 유저만

const activeAdults = users.filter(u => u.age >= 18 && u.active);

// [{name:'Alice',...}, {name:'Carol',...}]

// 중복 제거 (indexOf 활용)

const arr = [1, 2, 2, 3, 3, 4];

const unique = arr.filter((v, i, self) => self.indexOf(v) === i);

// [1, 2, 3, 4]

04 reduce — 하나의 값으로 축약

reduce는 배열을 하나의 값(숫자, 문자열, 객체, 배열 등)으로 축약해요.
세 함수 중 가장 강력하지만 처음엔 헷갈리는 녀석이에요.

reduce 기본 — 동작 원리

// 기본 문법

// array.reduce((누적값, 현재값, 인덱스, 원본배열) => 새누적값, 초기값)

const nums = [1, 2, 3, 4, 5];

// 합계

const sum = nums.reduce((acc, cur) => acc + cur, 0);

// 0+1=1 → 1+2=3 → 3+3=6 → 6+4=10 → 10+5=15

// 결과: 15

// 최댓값

const max = nums.reduce((acc, cur) => acc > cur ? acc : cur);

// 결과: 5

// 곱 (초기값 1)

const product = nums.reduce((acc, cur) => acc * cur, 1);

// 결과: 120

reduce 심화 — 다양한 활용

// 객체로 그룹핑 (가장 많이 쓰는 패턴!)

const fruits = ['apple', 'banana', 'apple', 'cherry', 'banana', 'apple'];

const count = fruits.reduce((acc, cur) => {

  acc[cur] = (acc[cur] || 0) + 1;

  return acc;

}, {});

// { apple: 3, banana: 2, cherry: 1 }

// 2차원 배열 → 1차원 (flat)

const nested = [[1, 2], [3, 4], [5]];

const flat = nested.reduce((acc, cur) => acc.concat(cur), []);

// [1, 2, 3, 4, 5]

// 객체 배열 → 특정 키로 객체 변환

const users = [

  { id: 1, name: 'Alice' },

  { id: 2, name: 'Bob'   },

];

const userMap = users.reduce((acc, user) => {

  acc[user.id] = user;

  return acc;

}, {});

// { 1: {id:1, name:'Alice'}, 2: {id:2, name:'Bob'} }

// 파이프라인 (함수 순차 실행)

const pipeline = [x => x + 1, x => x * 2, x => x - 3];

const result = pipeline.reduce((acc, fn) => fn(acc), 5);

// 5 → +1=6 → ×2=12 → -3=9

⚠️ 초기값 꼭 넣으세요! 초기값 없이 빈 배열에 reduce 하면 TypeError 발생!
항상 .reduce((acc, cur) => ..., 초기값) 형태로 쓰는 게 안전해요.
초기값이 숫자면 0, 배열이면 [], 객체면 {}

05 체이닝 — 연결해서 쓰기

세 함수를 체이닝(chaining)으로 연결하면 복잡한 작업도 한 줄에 처리할 수 있어요.

체이닝 패턴

const students = [

  { name: 'Alice', score: 85, pass: true  },

  { name: 'Bob',   score: 42, pass: false },

  { name: 'Carol', score: 91, pass: true  },

  { name: 'Dave',  score: 73, pass: true  },

];

// 합격자 이름만 추출 (filter → map)

const passNames = students

  .filter(s => s.pass)           // 합격자만

  .map(s => s.name);             // 이름 추출

// ['Alice', 'Carol', 'Dave']

// 합격자 점수 합계 (filter → map → reduce)

const passTotal = students

  .filter(s => s.pass)           // 합격자만

  .map(s => s.score)             // 점수만

  .reduce((acc, cur) => acc + cur, 0); // 합산

// 85 + 91 + 73 = 249

// 합격자 평균 점수

const passScores = students.filter(s => s.pass).map(s => s.score);

const avg = passScores.reduce((a, b) => a + b, 0) / passScores.length;

// 83

06 실전 코테 패턴

코테 자주 나오는 패턴

━━━ 패턴 1: 문자열 뒤집기 ━━━

'hello'.split('').reverse().join(''); // 'olleh'

━━━ 패턴 2: 특정 조건 개수 세기 ━━━

const arr = [1, 2, 3, 4, 5];

const evenCnt = arr.filter(n => n % 2 === 0).length; // 2

━━━ 패턴 3: 배열 합계 / 평균 ━━━

const sum = arr.reduce((a, b) => a + b, 0);       // 15

const avg = sum / arr.length;                           // 3

━━━ 패턴 4: 최댓값 / 최솟값 ━━━

const max = arr.reduce((a, b) => Math.max(a, b));  // 5

const min = arr.reduce((a, b) => Math.min(a, b));  // 1

// 또는

Math.max(...arr); // 5 (스프레드 연산자)

━━━ 패턴 5: 중복 제거 ━━━

const dup = [1, 2, 2, 3, 3];

[...new Set(dup)];                                     // [1, 2, 3]

dup.filter((v, i, s) => s.indexOf(v) === i);          // [1, 2, 3]

━━━ 패턴 6: 빈도수 계산 ━━━

const words = ['a', 'b', 'a', 'c', 'b', 'a'];

const freq = words.reduce((acc, w) => {

  acc[w] = (acc[w] || 0) + 1;

  return acc;

}, {});

// { a: 3, b: 2, c: 1 }

━━━ 패턴 7: 객체 배열 정렬 ━━━

const sorted = students

  .filter(s => s.pass)

  .sort((a, b) => b.score - a.score)  // 점수 내림차순

  .map(s => s.name);

// ['Carol', 'Alice', 'Dave']

07 forEach vs map — 헷갈리는 차이

forEach vs map 차이

// forEach — 반환값 없음 (undefined)

const result1 = [1, 2, 3].forEach(n => n * 2);

// result1 = undefined ← 새 배열 안 만들어짐!

// map — 새 배열 반환

const result2 = [1, 2, 3].map(n => n * 2);

// result2 = [2, 4, 6] ← 새 배열!

// forEach 는 부수효과(side effect)가 목적일 때

[1, 2, 3].forEach(n => console.log(n));  // ✅ 출력용

[1, 2, 3].forEach(n => arr.push(n * 2));  // ✅ 외부 배열 채울 때

// map 은 변환 결과를 사용할 때

const doubled = [1, 2, 3].map(n => n * 2);  // ✅

[1, 2, 3].map(n => console.log(n));          // ❌ 반환값 무시, forEach 써야

08 한눈에 비교

구분	map	filter	reduce
목적	변환	필터링	축약
반환값	새 배열	새 배열	단일 값 (뭐든 가능)
결과 길이	원본과 동일	같거나 짧음	하나
콜백 반환	변환된 값	true / false	새 누적값
초기값	없음	없음	필수 권장!
주요 사용	데이터 변환	조건 필터	합계, 그룹핑

✅ CONCLUSION map → 모든 요소 변환, 길이 동일
filter → 조건 맞는 것만, 길이 줄어듦
reduce → 하나의 값으로 축약, 가장 강력

코테에서 filter → map → reduce 체이닝 패턴을 자유자재로 쓸 수 있으면
JS 배열 관련 문제는 거의 다 해결할 수 있어요!

JavaScript map filter reduce 배열메서드 코딩테스트 체이닝

[개발 도구 및 환경] 전자정부프레임워크

woohaha — Mon, 25 May 2026 13:40:58 +0900

개발 도구 · 환경

전자정부프레임워크(eGovFrame) 기반 프로젝트에서
요청이 들어오면 어떤 순서로 처리되는지 한 번에 정리해봤어요.
Controller → Service → Mapper → XML → DB → 다시 돌아오는 전체 흐름이에요.

// TABLE OF CONTENTS

01 전체 요청/응답 흐름

02 VO / DTO 란?

03 Controller

04 Service / ServiceImpl

05 Mapper (DAO)

06 MyBatis XML Mapper

07 전체 예제 코드

08 핵심 어노테이션 정리

01 전체 요청 / 응답 흐름

사용자가 버튼을 누르면 서버에서 이런 순서로 처리돼요.

// 요청 흐름 (Request)

브라우저 요청 → Controller → Service
(Interface) → ServiceImpl
(구현체) → Mapper
(Interface) → XML
(SQL) → DB

브라우저 응답 ← Controller ← ServiceImpl ← Mapper ← XML ← DB

※ 데이터는 VO(Value Object)에 담겨 각 레이어 사이를 이동해요.

레이어드 아키텍처 이 구조를 레이어드 아키텍처(Layered Architecture)라고 해요.
각 레이어는 바로 아래 레이어에만 의존하고, 역할이 명확히 분리돼 있어요.
Controller(화면 처리) → Service(비즈니스 로직) → Mapper(DB 처리)

02 VO / DTO — 데이터를 담는 그릇

레이어 간에 데이터를 주고받을 때 사용하는 데이터 전달 객체예요.

VO / DTO Value Object / Data Transfer Object

VO (Value Object) — DB 테이블 컬럼과 매핑되는 객체. getter/setter 보유.
DTO (Data Transfer Object) — 레이어 간 데이터 전달용. VO와 혼용하는 경우 많음.
전자정부프레임워크에서는 보통 VO 하나로 통일해서 씀.

EmpVO.java — VO 예시

public class EmpVO {

  // DB 컬럼과 매핑되는 필드

  private String empId;   // EMP_ID

  private String empNm;   // EMP_NM

  private String deptCd;  // DEPT_CD

  private int    salary;   // SALARY

  // 검색 조건용 필드 (DB에 없어도 OK)

  private String searchNm;

  private String searchDept;

  // getter / setter

  public String getEmpId() { return empId; }

  public void setEmpId(String empId) { this.empId = empId; }

  // ... 나머지 getter/setter 생략

}

camelCase ↔ snake_case 자동 변환 MyBatis는 DB 컬럼명 EMP_NM을 VO 필드 empNm으로 자동 매핑해줘요.
설정에서 mapUnderscoreToCamelCase=true로 설정하면 돼요.
이 설정 없으면 XML에서 resultMap으로 수동 매핑해야 해요.

03 Controller — 요청의 시작점

Controller 요청 수신 → Service 호출 → 결과 반환

역할: HTTP 요청을 받아 Service를 호출하고 결과를 View(JSP)나 JSON으로 반환.
비즈니스 로직은 절대 Controller에 넣으면 안 돼요 → Service에 위임!

EmpController.java

@Controller

@RequestMapping("/emp")

public class EmpController {

  @Autowired

  private EmpService empService; // Service 주입

  // 사원 목록 조회 (JSP 반환)

  @RequestMapping("/list.do")

  public String selectEmpList(EmpVO empVO, ModelMap model) {

    List<EmpVO> list = empService.selectEmpList(empVO);

    model.addAttribute("empList", list);

    return "emp/empList"; // JSP 경로

  }

  // 사원 저장 (JSON 반환)

  @RequestMapping("/insert.do")

  @ResponseBody

  public Map<String, Object> insertEmp(@RequestBody EmpVO empVO) {

    Map<String, Object> result = new HashMap<>();

    try {

      empService.insertEmp(empVO);

      result.put("result", "success");

    } catch (Exception e) {

      result.put("result", "fail");

    }

    return result;

  }

}

04 Service / ServiceImpl — 비즈니스 로직

Service Interface + 구현체로 분리하는 이유

Service (Interface) — 무엇을 할 수 있는지 선언만 해요.
ServiceImpl (구현체) — 실제 비즈니스 로직을 구현해요.
인터페이스로 분리하면 구현체 교체, 테스트, 트랜잭션 AOP 적용이 쉬워요.

EmpService.java (Interface)

public interface EmpService {

  // 무엇을 할지만 선언 — 구현은 ServiceImpl에서

  List<EmpVO> selectEmpList(EmpVO empVO);

  EmpVO selectEmpDetail(EmpVO empVO);

  void insertEmp(EmpVO empVO);

  void updateEmp(EmpVO empVO);

  void deleteEmp(EmpVO empVO);

}

EmpServiceImpl.java (구현체)

@Service("empService")

public class EmpServiceImpl implements EmpService {

  @Autowired

  private EmpMapper empMapper; // Mapper 주입

  @Override

  public List<EmpVO> selectEmpList(EmpVO empVO) {

    return empMapper.selectEmpList(empVO);

  }

  @Override

  @Transactional // 트랜잭션 적용!

  public void insertEmp(EmpVO empVO) {

    // 비즈니스 로직 — 여러 작업을 하나의 트랜잭션으로

    empMapper.insertEmp(empVO);

    empMapper.insertEmpHist(empVO); // 이력도 함께 저장

  }

}

@Transactional 위치 @Transactional은 ServiceImpl 메서드에 붙여요.
붙이면 해당 메서드 안의 모든 DB 작업이 하나의 트랜잭션으로 묶여요.
예외 발생 시 자동 ROLLBACK, 정상 종료 시 자동 COMMIT!

05 Mapper (DAO) — DB 연결 인터페이스

Mapper SQL 실행을 담당하는 인터페이스

MyBatis에서 Mapper Interface는 선언만 하면 돼요.
실제 SQL은 XML 파일에 작성하고, MyBatis가 자동으로 연결해줘요.
메서드명 = XML의 id값과 일치해야 해요.

EmpMapper.java (Interface)

@Mapper // MyBatis Mapper 선언

public interface EmpMapper {

  // 메서드명 = XML의 id와 반드시 일치!

  List<EmpVO> selectEmpList(EmpVO empVO);

  EmpVO selectEmpDetail(EmpVO empVO);

  void insertEmp(EmpVO empVO);

  void insertEmpHist(EmpVO empVO);

  void updateEmp(EmpVO empVO);

  void deleteEmp(EmpVO empVO);

}

⚠️ Mapper vs DAO 옛날 방식은 DAO 클래스를 직접 만들어서 SqlSession으로 SQL을 호출했어요.
MyBatis 3.x 이후부터는 Mapper Interface만 선언하면 MyBatis가 자동으로 구현체를 만들어줘요.
전자정부프레임워크 구버전 프로젝트에서는 아직 DAO 방식을 쓰는 경우도 있어요.

06 MyBatis XML Mapper — 실제 SQL 작성

XML SQL을 Java 코드와 분리해서 관리

SQL을 Java 코드 밖에 XML로 관리해서 SQL 변경 시 Java 코드를 건드리지 않아도 돼요.
namespace = Mapper 인터페이스 경로, id = 메서드명과 일치해야 해요.

EmpMapper.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"

  "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<!-- namespace = Mapper 인터페이스 전체 경로 -->

<mapper namespace="com.example.emp.mapper.EmpMapper">

  <!-- 목록 조회 -->

  <select id="selectEmpList" parameterType="EmpVO" resultType="EmpVO">

    SELECT EMP_ID, EMP_NM, DEPT_CD, SALARY

    FROM   EMP

    WHERE  1=1

    <if test="searchNm != null and searchNm != ''">

      AND EMP_NM LIKE '%' || #{searchNm} || '%'

    </if>

    <if test="searchDept != null and searchDept != ''">

      AND DEPT_CD = #{searchDept}

    </if>

    ORDER BY EMP_ID

  </select>

  <!-- 단건 조회 -->

  <select id="selectEmpDetail" parameterType="EmpVO" resultType="EmpVO">

    SELECT EMP_ID, EMP_NM, DEPT_CD, SALARY

    FROM   EMP

    WHERE  EMP_ID = #{empId}

  </select>

  <!-- 등록 -->

  <insert id="insertEmp" parameterType="EmpVO">

    INSERT INTO EMP (EMP_ID, EMP_NM, DEPT_CD, SALARY)

    VALUES (#{empId}, #{empNm}, #{deptCd}, #{salary})

  </insert>

  <!-- 수정 -->

  <update id="updateEmp" parameterType="EmpVO">

    UPDATE EMP

    <set>

      <if test="empNm != null">EMP_NM = #{empNm},</if>

      <if test="salary != 0">SALARY = #{salary},</if>

    </set>

    WHERE EMP_ID = #{empId}

  </update>

  <!-- 삭제 -->

  <delete id="deleteEmp" parameterType="EmpVO">

    DELETE FROM EMP WHERE EMP_ID = #{empId}

  </delete>

</mapper>

#{} vs ${} 차이 #{empId} → PreparedStatement 방식. SQL Injection 방지! ← 항상 이걸 써야 해요
${empId} → 값을 문자열로 직접 삽입. SQL Injection 위험! ORDER BY 컬럼명 등 특수한 경우에만 사용

07 전체 예제 — 조회 요청 흐름 추적

"사원 목록 조회" 요청이 들어왔을 때 각 레이어를 거치는 순서를 코드로 추적해볼게요.

요청 흐름 추적 — Step by Step

/* ① 브라우저 → /emp/list.do 요청 */

GET /emp/list.do?searchNm=홍&searchDept=10

/* ② Controller — 요청 파라미터 자동 바인딩 */

@RequestMapping("/list.do")

public String selectEmpList(EmpVO empVO, ModelMap model) {

  // empVO.searchNm = "홍", empVO.searchDept = "10" 자동 세팅

  List<EmpVO> list = empService.selectEmpList(empVO); // ③ Service 호출

  model.addAttribute("empList", list);

  return "emp/empList";

}

/* ③ ServiceImpl — 비즈니스 로직 */

public List<EmpVO> selectEmpList(EmpVO empVO) {

  return empMapper.selectEmpList(empVO); // ④ Mapper 호출

}

/* ④ MyBatis — Mapper Interface → XML SQL 실행 */

-- 동적 쿼리 생성 (searchNm, searchDept 조건 추가됨)

SELECT EMP_ID, EMP_NM, DEPT_CD, SALARY

FROM   EMP

WHERE  1=1

AND    EMP_NM LIKE '%홍%'

AND    DEPT_CD = '10'

ORDER BY EMP_ID

/* ⑤ DB 실행 → 결과 → EmpVO 리스트로 자동 매핑 */

/* ⑥ Controller → ModelMap에 담아 JSP로 전달 */

/* ⑦ JSP에서 ${empList}로 렌더링 → 브라우저 응답 */

08 핵심 어노테이션 정리

어노테이션	위치	역할
@Controller	Controller 클래스	Spring MVC 컨트롤러 등록
@RequestMapping	Controller 메서드	URL 매핑
@ResponseBody	Controller 메서드	반환값을 JSON으로 직렬화
@RequestBody	파라미터	요청 Body(JSON)를 VO로 변환
@Service	ServiceImpl 클래스	Spring Bean으로 등록
@Transactional	ServiceImpl 메서드	트랜잭션 적용
@Mapper	Mapper 인터페이스	MyBatis Mapper 등록
@Autowired	필드/생성자	Spring Bean 자동 주입 (DI)
@Component	일반 클래스	Spring Bean으로 등록 (범용)

✅ CONCLUSION Controller → URL 받아서 Service 호출
Service(Interface) → 무엇을 할지 선언
ServiceImpl → 실제 비즈니스 로직 + 트랜잭션
Mapper(Interface) → SQL 메서드 선언
XML → 실제 SQL 작성
VO → 레이어 간 데이터 이동 그릇

이 흐름을 머릿속에 그릴 수 있으면 전자정부프레임워크 프로젝트 어디서든 길을 잃지 않아요!

09 MyBatis에서 프로시저 / 펑션 호출

복잡한 비즈니스 로직이 DB 프로시저로 구현된 경우
MyBatis XML에서 statementType="CALLABLE"로 호출할 수 있어요.

Oracle 프로시저 호출

EmpMapper.xml — 프로시저 호출

<!-- Oracle 프로시저 호출 -->

<update id="callSalaryUpdate"

         parameterType="EmpVO"

         statementType="CALLABLE">

  {CALL SP_SALARY_UPDATE(

    #{deptCd,    mode=IN,  jdbcType=VARCHAR},

    #{rate,      mode=IN,  jdbcType=NUMERIC},

    #{resultCnt, mode=OUT, jdbcType=NUMERIC}

  )}

</update>

<!-- Oracle 펑션 호출 -->

<select id="callGetDeptName"

         parameterType="EmpVO"

         statementType="CALLABLE"

         resultType="String">

  {#{deptNm, mode=OUT, jdbcType=VARCHAR} =

    CALL FN_GET_DEPT_NAME(#{deptCd, mode=IN, jdbcType=VARCHAR})}

</select>

EmpMapper.java — 프로시저 메서드 선언

@Mapper

public interface EmpMapper {

  // 프로시저 호출 — OUT 파라미터는 VO에 담겨 반환

  void callSalaryUpdate(EmpVO empVO);

  // 펑션 호출

  void callGetDeptName(EmpVO empVO);

}

EmpServiceImpl.java — 프로시저 결과 사용

@Transactional

public void processSalaryUpdate(EmpVO empVO) {

  // 프로시저 호출

  empMapper.callSalaryUpdate(empVO);

  // OUT 파라미터 값은 호출 후 VO에 자동으로 세팅됨

  int resultCnt = empVO.getResultCnt();

  System.out.println("처리건수: " + resultCnt);

}

OUT 파라미터 처리 핵심 프로시저의 OUT 파라미터는 VO 필드에 자동으로 세팅돼요.
VO에 OUT 파라미터 받을 필드를 미리 선언해두면 MyBatis가 자동으로 채워줘요.
mode=OUT으로 선언한 필드는 호출 후 VO.getXxx()로 꺼내쓰면 됩니다.

10 넥사크로 → Spring → DB 전체 흐름

ERP 넥사크로 화면에서 조회 버튼을 누르면 어떤 경로로 흘러가는지 정리해봤어요.

// 넥사크로 → Spring MVC → MyBatis → DB 전체 흐름

넥사크로
transaction() → JSP or
Controller → Service
Impl → Mapper
Interface → XML
(SQL/SP) → DB
(Oracle)

넥사크로 → JSP 트랜잭션 → Controller 흐름

/* ① 넥사크로 화면 — transaction() 호출 */

function btn_search_onclick(obj, e) {

  this.transaction(

    "selectList",

    "/emp/list.do",          // Controller URL

    "ds_search",             // 보낼 Dataset (검색조건)

    "ds_list",               // 받을 Dataset (결과)

    "callback_selectList"    // 응답 후 콜백함수

  );

}

/* ② Controller — 넥사크로 Dataset 파싱 */

@RequestMapping("/emp/list.do")

public ModelAndView selectEmpList(HttpServletRequest request,

                                   HttpServletResponse response) {

  // 넥사크로 Dataset → VO 변환

  NexacroUtil nexacroUtil = new NexacroUtil(request, response);

  DataSet ds_search = nexacroUtil.getDataSet("ds_search");

  EmpVO empVO = new EmpVO();

  empVO.setSearchNm(ds_search.getString(0, "SEARCH_NM"));

  empVO.setSearchDept(ds_search.getString(0, "DEPT_CD"));

  // Service 호출

  List<EmpVO> list = empService.selectEmpList(empVO);

  // 결과 → 넥사크로 Dataset으로 변환 후 응답

  nexacroUtil.addDataSet("ds_list", list);

  nexacroUtil.sendData();

  return null;

}

/* ③ ServiceImpl → Mapper → XML → DB → 결과 반환 */

/* ④ 넥사크로 콜백에서 ds_list 자동 바인딩 → Grid 표시 */

넥사크로에서 프로시저 결과 받기

/* 넥사크로 — 저장 버튼 클릭 */

function btn_save_onclick(obj, e) {

  this.transaction(

    "saveSalary",

    "/emp/salaryUpdate.do",

    "ds_param",  // 보낼 Dataset (deptCd, rate)

    "ds_result", // 받을 Dataset (처리건수 등)

    "callback_save"

  );

}

/* 콜백 — 프로시저 OUT 파라미터 결과 확인 */

function callback_save(id, errorCode, errorMsg) {

  if (errorCode < 0) {

    alert("저장 실패: " + errorMsg);

    return;

  }

  // ds_result에서 처리건수 확인

  var resultCnt = this.ds_result.getColumn(0, "RESULT_CNT");

  alert(resultCnt + "건 처리 완료!");

}

⚠️ 넥사크로 + Spring 주요 주의사항 넥사크로 Dataset 컬럼명은 대문자 언더스코어 (EMP_NM) 형태가 많아요.
Java VO는 카멜케이스 (empNm) → 변환 코드 또는 MyBatis 설정 필요.
NexacroUtil은 프로젝트마다 커스텀 유틸이라 코드가 다를 수 있어요.
트랜잭션은 반드시 ServiceImpl에 @Transactional로 걸어야 프로시저 오류 시 롤백돼요.

Spring MyBatis 전자정부프레임워크 Controller Service Mapper VO MVC패턴 eGovFrame

[Network] TCP vs UDP 완전 정복 - 3-Way Handshake부터 실사용 예시까지

woohaha — Sat, 23 May 2026 08:07:23 +0900

CS 면접 대비 · 네트워크

면접에서 "TCP와 UDP의 차이를 설명해주세요"는 네트워크 단골 질문이에요.
개념부터 3-Way Handshake, 실제 사용 예시까지 한 번에 정리해드릴게요.

// TABLE OF CONTENTS

01 TCP / UDP 핵심 요약

02 TCP — 연결 지향

03 3-Way Handshake

04 4-Way Handshake (연결 종료)

05 TCP 특징 — 흐름/혼잡 제어

06 UDP — 비연결 지향

07 TCP vs UDP 비교

08 면접 답변 정리

01 TCP / UDP 핵심 요약

⚡ 핵심 한 줄 요약

TCP 신뢰성 보장 — 연결 후 순서 보장, 재전송, 느리지만 정확

UDP 속도 우선 — 연결 없이 전송, 손실 가능, 빠르지만 불확실

02 TCP — 연결 지향 프로토콜

TCP(Transmission Control Protocol)는 데이터를 정확하게, 순서대로 전달해요.
통신 전 연결을 맺고, 통신 후 연결을 끊는 과정이 있어요.

TCP 특징

연결 지향 (3-Way Handshake)
데이터 순서 보장
손실 시 자동 재전송
흐름 제어 / 혼잡 제어
1:1 통신 (유니캐스트)
속도 상대적으로 느림

TCP 헤더 구조

출발지 포트 (16bit)
목적지 포트 (16bit)
시퀀스 번호 — 순서 보장
확인 응답 번호 (ACK)
플래그 (SYN/ACK/FIN/RST)
체크섬 — 오류 검출

03 3-Way Handshake — 연결 수립

TCP 연결을 맺을 때 3번의 메시지를 주고받는 과정이에요.
서로의 존재를 확인하고 통신 준비가 됐음을 확인해요.

// 3-Way Handshake (연결 수립)

Client Server

SYN ────────────→ ① "나 연결하고 싶어!" (SYN=1, seq=x)

←──────────── SYN + ACK ② "OK! 나도 준비됐어!" (SYN=1, ACK=x+1, seq=y)

ACK ────────────→ ③ "확인! 이제 통신하자!" (ACK=y+1)

✅ 연결 수립 완료 → 데이터 전송 시작

SYN / ACK 플래그 의미 SYN (Synchronize) = 연결 요청. 시퀀스 번호 동기화
ACK (Acknowledgment) = 수신 확인. "잘 받았어!" 응답
FIN (Finish) = 연결 종료 요청
RST (Reset) = 강제 연결 초기화

04 4-Way Handshake — 연결 종료

TCP 연결을 끊을 때는 4번의 메시지가 필요해요.
양쪽 모두 데이터 전송이 끝났음을 확인해야 하기 때문이에요.

// 4-Way Handshake (연결 종료)

Client Server

FIN ────────────→ ① "나 이제 보낼 거 없어" (FIN)

←──────────── ACK ② "알겠어, 잠깐만" (ACK) — 서버 아직 보낼 수 있음

←──────────── FIN ③ "나도 다 보냈어" (FIN)

ACK ────────────→ ④ "확인! 연결 끊자" (ACK)

✅ 연결 종료 완료 → TIME_WAIT 상태 후 완전 종료

⚠️ TIME_WAIT 상태 클라이언트는 마지막 ACK를 보낸 후 바로 종료하지 않고 TIME_WAIT 상태로 잠시 대기해요.
이유: 마지막 ACK가 유실됐을 때 서버가 FIN을 재전송하면 받아서 처리하기 위함.
TIME_WAIT 기간: 보통 2 × MSL (Maximum Segment Lifetime) = 약 60~120초

05 TCP 특징 — 흐름 제어 & 혼잡 제어

흐름 제어 (Flow Control)

수신측이 처리할 수 있는 속도보다 송신측이 너무 빠르게 보내는 것을 방지해요.
수신 버퍼 크기를 알려주는 윈도우 크기(Window Size)로 제어해요.

흐름 제어 / 혼잡 제어 개념

━━━ 흐름 제어 (Flow Control) ━━━

수신측 버퍼: 65535 bytes (Window Size)

-- 수신측이 "나 이만큼만 받을 수 있어"라고 알림

-- 송신측은 Window Size 이내에서만 전송

-- 슬라이딩 윈도우 방식으로 동적 조절

━━━ 혼잡 제어 (Congestion Control) ━━━

-- 네트워크 자체가 혼잡할 때 전송량 줄이기

-- 패킷 손실 감지 → 전송 속도 감소

-- 알고리즘: Slow Start → Congestion Avoidance

-- 처음엔 천천히 → 점점 빠르게 → 손실 발생 → 다시 줄이기

06 UDP — 비연결 지향 프로토콜

UDP(User Datagram Protocol)는 연결 없이 일단 보내고 보는 방식이에요.
손실이 발생해도 재전송하지 않아서 빠르지만 신뢰성이 없어요.

// UDP 전송 — 확인 없이 그냥 보냄

패킷1 전송 → 수신 ✅

패킷2 전송 → 손실 ← 재전송 없음, 그냥 무시

패킷3 전송 → 수신 ✅

UDP 특징

비연결 지향 (핸드셰이크 없음)
데이터 순서 보장 안 됨
손실 시 재전송 없음
빠른 전송 속도
1:1 / 1:N(멀티캐스트) 가능
헤더 크기 작음 (8byte)

UDP 헤더 구조

출발지 포트 (16bit)
목적지 포트 (16bit)
길이 (16bit)
체크섬 (16bit)
총 8byte — TCP(20byte+)보다 훨씬 작음
오버헤드 최소화

07 TCP vs UDP 한눈에 비교

구분	TCP	UDP
연결 방식	연결 지향 (3-Way Handshake)	비연결 지향
신뢰성	보장 (재전송, 순서 보장)	미보장
속도	상대적으로 느림	빠름
헤더 크기	20~60 byte	8 byte
흐름 제어	있음	없음
혼잡 제어	있음	없음
통신 방식	1:1 (유니캐스트)	1:1 / 1:N 가능
사용 예시	HTTP, HTTPS, FTP, 이메일	스트리밍, 게임, DNS, VoIP

실제 사용 예시

TCP 사용 — 정확성이 중요할 때

HTTP/HTTPS FTP 이메일(SMTP) 파일 다운로드 SSH DB 통신

UDP 사용 — 속도가 중요할 때

YouTube 스트리밍 온라인 게임 DNS 조회 VoIP (인터넷 전화) 화상회의 DHCP

UDP인데 왜 유튜브는 끊기지 않나요? UDP는 패킷이 손실돼도 재전송 없이 그냥 넘어가요.
스트리밍에서 1~2 프레임 손실은 화질 저하나 잠깐 끊기는 정도고 치명적이지 않아요.
반면 TCP면 손실 시 재전송 대기 → 전체적인 지연(버퍼링)이 더 심해져요.
최근 HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용해요.

08 면접 답변 정리

면접 예상 Q&A

Q. TCP와 UDP의 차이를 설명해주세요.

"TCP는 연결 지향 프로토콜로 3-Way Handshake를 통해

연결을 맺고 데이터의 신뢰성과 순서를 보장합니다.

UDP는 비연결 지향으로 연결 과정 없이 데이터를 전송하며

속도가 빠르지만 신뢰성은 보장하지 않습니다.

HTTP, 파일 전송처럼 정확성이 중요할 때는 TCP를,

스트리밍, 게임처럼 속도가 중요할 때는 UDP를 사용합니다."

Q. 3-Way Handshake를 설명해주세요.

"클라이언트가 SYN을 보내고, 서버가 SYN+ACK로 응답하면

클라이언트가 ACK를 보내 연결을 수립합니다.

이 과정으로 양측이 서로 통신 준비가 됐음을 확인해요."

✅ CONCLUSION TCP = 신뢰성 / UDP = 속도로 기억하세요.
면접에서 3-Way Handshake 순서 (SYN → SYN+ACK → ACK)와
각각의 사용 사례(HTTP vs 스트리밍)까지 말할 수 있으면 충분해요.
여유가 있다면 TIME_WAIT, 흐름 제어, HTTP/3의 QUIC까지 언급하면 플러스!

네트워크 TCP UDP 3-Way Handshake 4-Way Handshake CS면접 흐름제어 혼잡제어

[SQL] BEGIN/END 다중쿼리 완전 정복 - 트랜잭션, 커서, 프로시저

woohaha — Mon, 18 May 2026 19:42:17 +0900

SQL · 코딩테스트 / 실무

SQL에서 여러 쿼리를 묶어서 실행하거나, 조건에 따라 분기하거나,
반복 처리하는 방법들이 있어요.
BEGIN, 다중 DML, 프로시저 기초까지 한 번에 정리해드릴게요.

// TABLE OF CONTENTS

01 BEGIN / END 블록

02 다중 DML 트랜잭션

03 SAVEPOINT 부분 롤백

04 IF / CASE 조건 분기

05 LOOP / WHILE 반복

06 커서 (CURSOR)

07 프로시저 기초

08 DB별 문법 비교

01 BEGIN / END 블록

여러 SQL 문장을 하나의 블록으로 묶는 구조예요.
트랜잭션 제어, 조건 분기, 예외 처리 등을 함께 쓸 수 있어요.

Oracle — BEGIN..END (PL/SQL) MySQL — BEGIN..END MSSQL — BEGIN..END

BEGIN / END 기본 구조

━━━ Oracle PL/SQL ━━━

BEGIN

  UPDATE ACCOUNT SET BALANCE = BALANCE - 1000 WHERE ID = 'A';

  UPDATE ACCOUNT SET BALANCE = BALANCE + 1000 WHERE ID = 'B';

  COMMIT;

EXCEPTION

  WHEN OTHERS THEN

    ROLLBACK;

    DBMS_OUTPUT.PUT_LINE('오류: ' || SQLERRM);

END;

/

━━━ MySQL ━━━

START TRANSACTION;

BEGIN

  UPDATE ACCOUNT SET BALANCE = BALANCE - 1000 WHERE ID = 'A';

  UPDATE ACCOUNT SET BALANCE = BALANCE + 1000 WHERE ID = 'B';

END;

COMMIT;

━━━ MSSQL ━━━

BEGIN TRANSACTION

BEGIN TRY

  UPDATE ACCOUNT SET BALANCE = BALANCE - 1000 WHERE ID = 'A';

  UPDATE ACCOUNT SET BALANCE = BALANCE + 1000 WHERE ID = 'B';

  COMMIT TRANSACTION

END TRY

BEGIN CATCH

  ROLLBACK TRANSACTION

END CATCH

DB별 예외 처리 키워드 Oracle → EXCEPTION WHEN OTHERS THEN
MySQL → DECLARE ... HANDLER FOR SQLEXCEPTION (프로시저 내)
MSSQL → BEGIN TRY ... END TRY / BEGIN CATCH ... END CATCH

02 다중 DML 트랜잭션 — 묶어서 처리

여러 INSERT / UPDATE / DELETE를 하나의 트랜잭션으로 묶어
전부 성공하거나 전부 실패하게 만드는 패턴이에요.

// 다중 DML 트랜잭션 흐름

BEGIN → INSERT → UPDATE → DELETE → COMMIT ✅

BEGIN → INSERT → UPDATE → ERROR! → ROLLBACK ❌ ← 전부 취소

실무 패턴 — 주문 처리 (Oracle PL/SQL)

DECLARE

  V_ORDER_ID  NUMBER;

  V_STOCK     NUMBER;

BEGIN

  -- 1. 재고 확인

  SELECT STOCK_QTY INTO V_STOCK

  FROM   PRODUCT

  WHERE  PROD_CD = 'P001'

  FOR UPDATE; -- 배타락 획득

  IF V_STOCK < 1 THEN

    RAISE_APPLICATION_ERROR(-20001, '재고 부족');

  END IF;

  -- 2. 주문 생성

  INSERT INTO ORDERS (ORDER_ID, PROD_CD, QTY, STATUS)

  VALUES (SEQ_ORDER.NEXTVAL, 'P001', 1, '주문완료');

  -- 3. 재고 차감

  UPDATE PRODUCT

  SET    STOCK_QTY = STOCK_QTY - 1

  WHERE  PROD_CD = 'P001';

  -- 4. 주문 이력 기록

  INSERT INTO ORDER_HIST (PROD_CD, ACTION, ACT_DT)

  VALUES ('P001', '주문', SYSDATE);

  COMMIT; -- 전부 성공 시 확정

EXCEPTION

  WHEN OTHERS THEN

    ROLLBACK; -- 하나라도 실패하면 전부 취소

    DBMS_OUTPUT.PUT_LINE(SQLERRM);

END;

/

03 SAVEPOINT — 부분 롤백

트랜잭션 중간에 체크포인트를 설정해서 특정 지점까지만 롤백할 수 있어요.

Oracle MySQL MSSQL — SAVE TRANSACTION

SAVEPOINT 활용

-- Oracle / MySQL

BEGIN

  INSERT INTO LOG_TABLE VALUES ('작업시작', SYSDATE);

  SAVEPOINT SP1; -- 체크포인트 1 설정

  UPDATE EMP SET SALARY = SALARY * 1.1 WHERE DEPT_CD = '10';

  SAVEPOINT SP2; -- 체크포인트 2 설정

  UPDATE EMP SET SALARY = SALARY * 1.2 WHERE DEPT_CD = '20';

  -- 20번 부서 업데이트만 취소하고 싶을 때

  ROLLBACK TO SP2; -- SP2 이후만 취소 (SP1까지는 유지)

  COMMIT; -- INSERT + 10번 부서 UPDATE만 반영

END;

/

-- MSSQL은 문법이 다름

BEGIN TRANSACTION

  SAVE TRANSACTION SP1

  UPDATE EMP SET SALARY = SALARY * 1.1 WHERE DEPT_CD = '10'

  ROLLBACK TRANSACTION SP1 -- SP1으로 부분 롤백

COMMIT

04 IF / CASE — 조건 분기

PL/SQL / T-SQL에서 조건에 따라 다른 SQL을 실행하는 구조예요.

IF / CASE 조건 분기 — DB별 비교

━━━ Oracle PL/SQL ━━━

DECLARE

  V_SCORE NUMBER := 85;

  V_GRADE VARCHAR2(10);

BEGIN

  IF V_SCORE >= 90 THEN

    V_GRADE := 'A';

  ELSIF V_SCORE >= 80 THEN   -- ELSE IF 아닌 ELSIF!

    V_GRADE := 'B';

  ELSIF V_SCORE >= 70 THEN

    V_GRADE := 'C';

  ELSE

    V_GRADE := 'F';

  END IF;

  DBMS_OUTPUT.PUT_LINE('등급: ' || V_GRADE);

END;

/

━━━ MySQL ━━━

IF V_SCORE >= 90 THEN

  SET V_GRADE = 'A';

ELSEIF V_SCORE >= 80 THEN   -- ELSEIF (붙여서)

  SET V_GRADE = 'B';

ELSE

  SET V_GRADE = 'F';

END IF;

━━━ MSSQL ━━━

IF @SCORE >= 90

  SET @GRADE = 'A'

ELSE IF @SCORE >= 80    -- ELSE IF (띄어서)

  SET @GRADE = 'B'

ELSE

  SET @GRADE = 'F'

⚠️ DB별 키워드 차이 Oracle → ELSIF (E 없음)
MySQL → ELSEIF (공백 없음)
MSSQL → ELSE IF (공백 있음)
헷갈리는 포인트니까 꼭 기억해두세요!

05 LOOP / WHILE — 반복 처리

반복문 — DB별 비교

━━━ Oracle — 3가지 반복문 ━━━

-- 1. LOOP (무한 루프 + EXIT)

DECLARE I NUMBER := 1;

BEGIN

  LOOP

    DBMS_OUTPUT.PUT_LINE(I);

    I := I + 1;

    EXIT WHEN I > 5; -- 탈출 조건

  END LOOP;

END;

/

-- 2. WHILE LOOP

DECLARE I NUMBER := 1;

BEGIN

  WHILE I <= 5 LOOP

    DBMS_OUTPUT.PUT_LINE(I);

    I := I + 1;

  END LOOP;

END;

/

-- 3. FOR LOOP (범위 반복)

BEGIN

  FOR I IN 1..5 LOOP   -- 1부터 5까지

    DBMS_OUTPUT.PUT_LINE(I);

  END LOOP;

END;

/

━━━ MySQL / MSSQL — WHILE ━━━

-- MySQL

SET @I = 1;

WHILE @I <= 5 DO

  INSERT INTO TEST VALUES (@I);

  SET @I = @I + 1;

END WHILE;

-- MSSQL

DECLARE @I INT = 1

WHILE @I <= 5

BEGIN

  INSERT INTO TEST VALUES (@I)

  SET @I = @I + 1

END

06 커서 (CURSOR) — 행 단위 처리

SELECT 결과를 한 행씩 순서대로 처리할 때 사용해요.
보통 집합 연산으로 처리 불가능할 때 커서를 써요.

커서 — Oracle PL/SQL

DECLARE

  -- 커서 선언

  CURSOR C_EMP IS

    SELECT EMP_ID, EMP_NM, SALARY

    FROM   EMP

    WHERE  DEPT_CD = '10';

  V_EMP_ID  EMP.EMP_ID%TYPE;

  V_EMP_NM  EMP.EMP_NM%TYPE;

  V_SALARY  EMP.SALARY%TYPE;

BEGIN

  OPEN C_EMP; -- 커서 열기

  LOOP

    FETCH C_EMP INTO V_EMP_ID, V_EMP_NM, V_SALARY; -- 한 행씩 가져오기

    EXIT WHEN C_EMP%NOTFOUND; -- 더 이상 행 없으면 탈출

    -- 행별 처리 로직

    UPDATE EMP

    SET    SALARY = V_SALARY * 1.1

    WHERE  EMP_ID = V_EMP_ID;

  END LOOP;

  CLOSE C_EMP; -- 커서 닫기

  COMMIT;

END;

/

-- FOR 커서 (더 간단한 방식)

BEGIN

  FOR REC IN (SELECT EMP_ID, SALARY FROM EMP WHERE DEPT_CD = '10') LOOP

    UPDATE EMP SET SALARY = REC.SALARY * 1.1 WHERE EMP_ID = REC.EMP_ID;

  END LOOP; -- OPEN/FETCH/CLOSE 자동 처리!

  COMMIT;

END;

/

⚠️ 커서 성능 주의 커서는 행 단위로 처리하므로 대량 데이터에는 매우 느려요.
가능하면 집합 기반 SQL(UPDATE/INSERT SELECT)로 대체하는 게 훨씬 빨라요.
커서는 행별로 다른 로직이 필요할 때만 사용하세요.

07 프로시저 기초 (Stored Procedure)

자주 쓰는 SQL 로직을 DB에 저장해두고 이름으로 호출하는 방식이에요.
ERP 개발에서 복잡한 마감 처리나 배치 작업에 많이 사용해요.

프로시저 생성 & 호출 — DB별 비교

━━━ Oracle ━━━

CREATE OR REPLACE PROCEDURE SP_SALARY_UPDATE (

  P_DEPT_CD  IN  VARCHAR2,    -- 입력 파라미터

  P_RATE     IN  NUMBER,

  P_CNT      OUT NUMBER      -- 출력 파라미터

)AS

BEGIN

  UPDATE EMP

  SET    SALARY = SALARY * (1 + P_RATE / 100)

  WHERE  DEPT_CD = P_DEPT_CD;

  P_CNT := SQL%ROWCOUNT; -- 영향받은 행 수

  COMMIT;

EXCEPTION

  WHEN OTHERS THEN

    ROLLBACK;

    RAISE;

END;

/

-- 호출

DECLARE V_CNT NUMBER;

BEGIN

  SP_SALARY_UPDATE('10', 10, V_CNT);

  DBMS_OUTPUT.PUT_LINE('처리건수: ' || V_CNT);

END;

/

━━━ MySQL ━━━

DELIMITER //

CREATE PROCEDURE SP_SALARY_UPDATE(

  IN  P_DEPT_CD VARCHAR(10),

  IN  P_RATE    DECIMAL(5,2),

  OUT P_CNT     INT

)

BEGIN

  UPDATE EMP

  SET    SALARY = SALARY * (1 + P_RATE / 100)

  WHERE  DEPT_CD = P_DEPT_CD;

  SET P_CNT = ROW_COUNT();

END//

DELIMITER ;

-- 호출

CALL SP_SALARY_UPDATE('10', 10, @CNT);

SELECT @CNT;

━━━ MSSQL ━━━

CREATE PROCEDURE SP_SALARY_UPDATE

  @DEPT_CD VARCHAR(10),

  @RATE    DECIMAL(5,2),

  @CNT     INT OUTPUT

AS

BEGIN

  UPDATE EMP

  SET    SALARY = SALARY * (1 + @RATE / 100)

  WHERE  DEPT_CD = @DEPT_CD

  SET @CNT = @@ROWCOUNT

END

-- 호출

EXEC SP_SALARY_UPDATE '10', 10, @CNT OUTPUT

08 DB별 문법 한눈에 비교

구분	Oracle	MySQL	MSSQL
블록 시작	BEGIN	BEGIN	BEGIN
변수 선언	DECLARE 섹션	DECLARE 안에서	DECLARE @변수
변수 할당	V := 값	SET V = 값	SET @V = 값
조건 분기	IF / ELSIF / END IF	IF / ELSEIF / END IF	IF / ELSE IF / END
반복문	LOOP / WHILE / FOR	WHILE DO / END WHILE	WHILE BEGIN END
예외 처리	EXCEPTION WHEN	DECLARE HANDLER	TRY / CATCH
프로시저 호출	프로시저명()	CALL 프로시저명()	EXEC 프로시저명
출력	DBMS_OUTPUT.PUT_LINE	SELECT '값'	PRINT '값'

✅ CONCLUSION BEGIN/END로 여러 SQL을 묶고, COMMIT/ROLLBACK으로 트랜잭션을 제어해요.
조건 분기는 IF/ELSIF, 반복은 LOOP/WHILE/FOR, 행별 처리는 커서를 사용해요.
자주 쓰는 로직은 프로시저로 저장해두면 재사용성이 높아져요.
ERP 개발에서는 Oracle PL/SQL로 복잡한 마감/정산 로직을 많이 구현하니 익혀두면 유용해요!

SQL PL/SQL BEGIN 트랜잭션 SAVEPOINT 커서 프로시저 Oracle MySQL MSSQL

[SQL] 서브쿼리 완전 정복 - 스칼라/인라인뷰/EXISTS/상관 서브쿼리 한 번에

woohaha — Wed, 13 May 2026 19:51:53 +0900

SQL · 코딩테스트

서브쿼리는 쿼리 안에 또 다른 쿼리를 넣는 것이에요.
위치에 따라 스칼라, 인라인 뷰, 중첩 서브쿼리로 나뉘고
각각 쓰임새가 달라요. 코테와 실무 모두 자주 나오니 확실히 정리해봐요!

// TABLE OF CONTENTS

01 서브쿼리란?

02 스칼라 서브쿼리 (SELECT)

03 인라인 뷰 (FROM)

04 중첩 서브쿼리 (WHERE)

05 IN / NOT IN

06 EXISTS / NOT EXISTS

07 상관 서브쿼리

08 서브쿼리 vs JOIN

01 서브쿼리란?

서브쿼리는 SQL 문장 안에 포함된 또 다른 SELECT 문이에요.
위치에 따라 이름과 동작 방식이 달라져요.

서브쿼리 위치별 종류

SELECT EMP_NM,
       (SELECT DEPT_NM FROM DEPT WHERE DEPT_CD = E.DEPT_CD) AS DEPT_NM  -- ① 스칼라
FROM  (SELECT * FROM EMP WHERE SALARY > 3000000) E                     -- ② 인라인뷰
WHERE EMP_ID IN (SELECT EMP_ID FROM AWARD WHERE YEAR = 2024);             -- ③ 중첩(WHERE)
    

① SELECT절 → 스칼라 서브쿼리 ② FROM절 → 인라인 뷰 ③ WHERE절 → 중첩 서브쿼리

02 스칼라 서브쿼리 — SELECT절

단 하나의 값(1행 1열)을 반환하는 서브쿼리예요.
SELECT절에 넣어서 컬럼처럼 사용해요.

SELECT절

스칼라 서브쿼리

-- 사원별 부서명 조회 (JOIN 대신 스칼라 서브쿼리)

SELECT E.EMP_NM,

       E.SALARY,

       (SELECT D.DEPT_NM

        FROM   DEPT D

        WHERE  D.DEPT_CD = E.DEPT_CD) AS DEPT_NM,

       (SELECT AVG(SALARY) FROM EMP) AS AVG_SAL  -- 전체 평균 급여

FROM   EMP E;

-- 결과: 각 행마다 서브쿼리 1번씩 실행

-- ⚠️ 행이 많으면 성능 주의!

⚠️ 스칼라 서브쿼리 주의사항 반드시 1행 1열만 반환해야 해요. 2행 이상 반환 시 오류 발생!
결과가 없으면 NULL을 반환해요.
각 행마다 서브쿼리가 실행되므로 데이터가 많으면 JOIN으로 대체하는 게 성능상 유리해요.

03 인라인 뷰 — FROM절

FROM절에 서브쿼리를 넣어 가상 테이블처럼 사용하는 방식이에요.
복잡한 쿼리를 단계별로 처리할 때 유용해요.

FROM절

인라인 뷰

-- 부서별 평균 급여보다 많이 받는 사원 조회

SELECT E.EMP_NM, E.SALARY, T.AVG_SAL

FROM   EMP E

JOIN  (SELECT DEPT_CD,

              AVG(SALARY) AS AVG_SAL

        FROM   EMP

        GROUP BY DEPT_CD) T ON E.DEPT_CD = T.DEPT_CD

WHERE E.SALARY > T.AVG_SAL

ORDER BY E.DEPT_CD;

-- Oracle에서는 인라인뷰에 ORDER BY 사용 시 ROWNUM과 함께 쓰는 경우 많음

SELECT *

FROM  (SELECT EMP_NM, SALARY,

              ROW_NUMBER() OVER(ORDER BY SALARY DESC) AS RN

        FROM   EMP) T

WHERE T.RN <= 3; -- 급여 TOP 3

NOTE 인라인 뷰는 반드시 별칭(Alias)을 붙여야 해요.
WITH절(CTE)로 대체하면 가독성이 더 좋아요.
FROM (서브쿼리) T ← T가 인라인뷰 별칭

04 중첩 서브쿼리 — WHERE절

WHERE 조건에 서브쿼리를 넣어 동적으로 조건값을 생성하는 방식이에요.

WHERE절

중첩 서브쿼리 — 단일행 / 다중행

━━━ 단일행 서브쿼리 (=, >, < 사용) ━━━

-- 전체 평균 급여보다 많이 받는 사원

SELECT EMP_NM, SALARY

FROM   EMP

WHERE  SALARY > (SELECT AVG(SALARY) FROM EMP);

━━━ 다중행 서브쿼리 (IN, ANY, ALL 사용) ━━━

-- 2024년 수상 경력 있는 사원

SELECT EMP_NM

FROM   EMP

WHERE  EMP_ID IN (SELECT EMP_ID FROM AWARD WHERE YEAR = 2024);

-- ANY: 하나라도 만족하면 TRUE

WHERE  SALARY > ANY (SELECT SALARY FROM EMP WHERE DEPT_CD = '10');

-- = MIN(서브쿼리 결과) 보다 큰 값

-- ALL: 모두 만족해야 TRUE

WHERE  SALARY > ALL (SELECT SALARY FROM EMP WHERE DEPT_CD = '10');

-- = MAX(서브쿼리 결과) 보다 큰 값

05 IN / NOT IN

IN / NOT IN 활용

-- IN: 서브쿼리 결과 중 하나라도 일치하면

SELECT EMP_NM

FROM   EMP

WHERE  DEPT_CD IN (SELECT DEPT_CD FROM DEPT WHERE LOC = '서울');

-- NOT IN: 서브쿼리 결과에 없는 것만

SELECT EMP_NM

FROM   EMP

WHERE  EMP_ID NOT IN (SELECT EMP_ID FROM RETIRED_EMP);

-- ⚠️ NOT IN + NULL 함정!

-- 서브쿼리 결과에 NULL이 하나라도 있으면 NOT IN은 항상 FALSE!

WHERE  EMP_ID NOT IN (1, 2, NULL)  -- ← 결과 없음! NULL 때문에

-- 해결: NOT EXISTS 사용 또는 IS NOT NULL 조건 추가

⚠️ NOT IN + NULL 함정 서브쿼리 결과에 NULL이 포함되면 NOT IN은 항상 빈 결과를 반환해요.
NULL과의 비교는 항상 UNKNOWN이기 때문이에요.
해결책: NOT EXISTS를 사용하거나 WHERE 컬럼 IS NOT NULL 추가

06 EXISTS / NOT EXISTS

서브쿼리 결과가 존재하는지 여부만 확인하는 방식이에요.
행이 존재하면 TRUE, 없으면 FALSE를 반환해요.

EXISTS / NOT EXISTS

-- EXISTS: 주문이 있는 고객만 조회

SELECT C.CUST_NM

FROM   CUSTOMER C

WHERE  EXISTS (

         SELECT 1  -- 값이 뭐든 상관없음, 존재 여부만 체크

         FROM   ORDERS O

         WHERE  O.CUST_ID = C.CUST_ID

       );

-- NOT EXISTS: 한 번도 주문 안 한 고객

SELECT C.CUST_NM

FROM   CUSTOMER C

WHERE  NOT EXISTS (

         SELECT 1

         FROM   ORDERS O

         WHERE  O.CUST_ID = C.CUST_ID

       );

서브쿼리 결과를 전부 가져온 후 비교
결과가 적을 때 유리
NULL 포함 시 NOT IN 주의
외부 쿼리와 독립적으로 실행

EXISTS

조건 만족하는 행 발견하는 즉시 중단
결과가 많을 때 유리 (Early Exit)
NULL 문제 없음
외부 쿼리 각 행마다 실행 (상관 서브쿼리)

07 상관 서브쿼리 (Correlated Subquery)

외부 쿼리의 컬럼을 서브쿼리 안에서 참조하는 방식이에요.
외부 쿼리의 각 행마다 서브쿼리가 실행돼요.

상관 서브쿼리 패턴

-- 같은 부서에서 자신보다 급여가 높은 사람이 있는 사원

SELECT E1.EMP_NM, E1.SALARY, E1.DEPT_CD

FROM   EMP E1

WHERE  EXISTS (

         SELECT 1

         FROM   EMP E2

         WHERE  E2.DEPT_CD = E1.DEPT_CD  -- 외부 쿼리 참조!

         AND    E2.SALARY > E1.SALARY

       );

-- 부서별 최고 급여자 조회 (상관 서브쿼리)

SELECT EMP_NM, DEPT_CD, SALARY

FROM   EMP E1

WHERE  SALARY = (

                SELECT MAX(SALARY)

                FROM   EMP E2

                WHERE  E2.DEPT_CD = E1.DEPT_CD  -- 외부 행의 DEPT_CD 참조

                );

-- UPDATE에서의 상관 서브쿼리

UPDATE EMP E

SET    DEPT_NM = (SELECT DEPT_NM FROM DEPT D WHERE D.DEPT_CD = E.DEPT_CD);

상관 서브쿼리 vs 일반 서브쿼리 일반 서브쿼리 = 독립적으로 실행, 결과를 외부 쿼리에 전달 (1번만 실행)
상관 서브쿼리 = 외부 행마다 반복 실행 (N번 실행) → 데이터 많으면 느림
상관 서브쿼리는 JOIN이나 윈도우 함수로 대체하면 성능이 좋아지는 경우가 많아요.

08 서브쿼리 vs JOIN — 언제 뭘 쓸까?

같은 결과, 다른 방식 비교

━━━ 서브쿼리 방식 ━━━

SELECT EMP_NM

FROM   EMP

WHERE  DEPT_CD IN (SELECT DEPT_CD FROM DEPT WHERE LOC = '서울');

━━━ JOIN 방식 ━━━

SELECT E.EMP_NM

FROM   EMP E

JOIN   DEPT D ON E.DEPT_CD = D.DEPT_CD

WHERE  D.LOC = '서울';

━━━ 서브쿼리가 유리한 경우 ━━━

-- 존재 여부만 확인할 때 (EXISTS)

-- 집계 결과를 조건으로 쓸 때 (AVG, MAX 등)

-- 가독성이 중요할 때

━━━ JOIN이 유리한 경우 ━━━

-- 연결된 테이블의 컬럼도 SELECT해야 할 때

-- 대용량 데이터 조회 성능이 중요할 때

-- 옵티마이저가 더 효율적인 실행계획 세울 수 있음

구분	서브쿼리	JOIN
가독성	직관적, 단계적으로 이해 쉬움	익숙해지면 간결
성능	상관 서브쿼리는 N번 실행	보통 더 빠름 (옵티마이저 최적화)
연결 컬럼 조회	스칼라로만 가능 (1열 제한)	여러 컬럼 자유롭게 조회
존재 여부 확인	EXISTS로 빠르게 처리	DISTINCT 필요한 경우 있음
집계 조건	HAVING 없이 WHERE에서 처리 가능	별도 처리 필요

✅ CONCLUSION 서브쿼리는 위치(SELECT/FROM/WHERE)와 반환 형태(단일행/다중행)로 구분해요.
EXISTS는 NULL 안전하고 Early Exit으로 IN보다 대용량에서 유리해요.
상관 서브쿼리는 편리하지만 성능 주의 → JOIN이나 윈도우 함수로 대체 고려!
코테에서는 인라인 뷰 + 집계 서브쿼리 패턴이 특히 자주 나와요.

SQL 서브쿼리 스칼라서브쿼리 인라인뷰 EXISTS 상관서브쿼리 코딩테스트

[DB] 정규화 완전 정복 - 1NF부터 BCNF까지, 반정규화까지 한 번에

woohaha — Tue, 12 May 2026 18:14:39 +0900

CS 면접 대비 · 데이터베이스

DB 설계 면접에서 "정규화가 뭔가요?"는 단골 질문이에요.
1NF부터 BCNF까지, 왜 하는지부터 실제 예시까지 한 번에 정리해드릴게요.

// TABLE OF CONTENTS

01 정규화란? — 왜 해야 하나

02 이상현상 3가지

03 1NF — 원자값

04 2NF — 부분 함수 종속 제거

05 3NF — 이행 함수 종속 제거

06 BCNF

07 반정규화

08 면접 답변 정리

01 정규화란?

정규화는 데이터 중복을 최소화하고 데이터 무결성을 보장하기 위해
테이블을 올바른 구조로 분리하는 과정이에요.
1NF → 2NF → 3NF → BCNF 순서로 단계적으로 적용해요.

정규화가 필요한 이유 정규화 안 된 테이블은 이상현상(Anomaly)이 발생해요.
데이터 중복 → 업데이트 시 일부만 변경 → 데이터 불일치
→ 시스템 신뢰성 하락 → 서비스 장애 원인이 돼요.

02 이상현상 3가지

정규화가 안 된 아래 테이블을 예시로 설명할게요.

// 정규화 전 — 문제 있는 테이블

주문ID	고객ID	고객명	고객주소	상품코드	상품명	수량
1001	C01	홍길동	서울	P01	노트북	1
1002	C01	홍길동	서울	P02	마우스	2
1003	C02	김철수	부산	P01	노트북	1

① 삽입 이상 (Insertion Anomaly)

새 고객을 등록하려면 주문도 함께 있어야 해요.
주문 없이는 고객 정보만 넣을 수가 없어요.

② 갱신 이상 (Update Anomaly)

홍길동 주소가 바뀌면 2개 행을 모두 수정해야 해요.
하나라도 빠뜨리면 같은 사람의 주소가 달라지는 불일치 발생.

③ 삭제 이상 (Deletion Anomaly)

1003 주문을 삭제하면 김철수 고객 정보도 함께 사라져요.
주문 기록과 고객 기록이 결합돼 있기 때문이에요.

03 1NF — 원자값 (Atomic Value)

1NF 제1 정규형

모든 컬럼의 값은 원자값(더 이상 분해할 수 없는 단일 값)이어야 해요.
반복 그룹이나 다중값 컬럼이 있으면 1NF 위반이에요.

// 1NF 위반 — 다중값 컬럼

주문ID	고객명	주문상품 (다중값!)
1001	홍길동	노트북, 마우스, 키보드
1002	김철수	노트북

// 1NF 적용 후 — 원자값으로 분리

주문ID	고객명	주문상품
1001	홍길동	노트북
1001	홍길동	마우스
1001	홍길동	키보드
1002	김철수	노트북

04 2NF — 부분 함수 종속 제거

2NF 제2 정규형

1NF를 만족하면서 모든 비기본키 컬럼이 기본키 전체에 완전 함수 종속되어야 해요.
기본키의 일부에만 종속되는 부분 함수 종속을 제거해야 해요.
※ 기본키가 단일 컬럼이면 2NF는 자동으로 만족돼요.

// 2NF 위반 — PK: (주문ID, 상품코드) 복합키인데 부분 종속 발생

주문ID (PK)	상품코드 (PK)	수량	상품명 ⚠️	고객명 ⚠️
1001	P01	1	노트북 (상품코드에만 종속)	홍길동 (주문ID에만 종속)
1001	P02	2	마우스	홍길동
1002	P01	1	노트북	김철수

// 2NF 적용 후 — 테이블 분리

주문_상품 테이블

주문ID	상품코드	수량
1001	P01	1
1001	P02	2
1002	P01	1

상품 테이블

상품코드	상품명
P01	노트북
P02	마우스

주문 테이블

주문ID	고객명
1001	홍길동
1002	김철수

05 3NF — 이행 함수 종속 제거

3NF 제3 정규형

2NF를 만족하면서 기본키가 아닌 컬럼이 다른 비기본키 컬럼에 종속되면 안 돼요.
A → B → C 형태의 이행 함수 종속을 제거해야 해요.

// 3NF 위반 — 주문ID → 고객ID → 고객주소 (이행 종속)

주문ID (PK)	고객ID	고객주소 ⚠️	주문일
1001	C01	서울 (고객ID에 종속)	2024-01-15
1002	C01	서울 (중복!)	2024-02-01
1003	C02	부산	2024-02-10

// 3NF 적용 후 — 이행 종속 제거

주문 테이블

주문ID	고객ID	주문일
1001	C01	2024-01-15
1002	C01	2024-02-01
1003	C02	2024-02-10

고객 테이블

고객ID	고객주소
C01	서울
C02	부산

06 BCNF — 보이스-코드 정규형

BCNF Boyce-Codd 정규형

3NF보다 강한 조건. 모든 결정자(Determinant)는 후보키여야 해요.
3NF를 만족해도 BCNF를 위반하는 경우가 있어요.

// BCNF 위반 예시 — 학생-과목-교수 테이블

학생ID (PK)	과목명 (PK)	담당교수 ⚠️
S01	데이터베이스	김교수 (과목명에 종속, but 교수가 과목 결정)
S02	데이터베이스	김교수
S01	알고리즘	이교수

NOTE 담당교수 → 과목명으로 결정되는데, 담당교수는 후보키가 아니에요.
이 경우 교수-과목 테이블을 분리해서 BCNF를 만족시켜요.
실무에서 3NF까지는 꼭 하고, BCNF는 상황에 따라 적용해요.

07 반정규화 (De-normalization)

정규화를 하면 테이블이 많아지고 JOIN이 늘어나 조회 성능이 떨어질 수 있어요.
이럴 때 의도적으로 중복을 허용해서 성능을 높이는 것이 반정규화예요.

구분	정규화	반정규화
목적	데이터 무결성 / 중복 제거	조회 성능 향상
JOIN	많음	적음
중복	없음	의도적 허용
수정 비용	낮음 (한 곳만 수정)	높음 (여러 곳 수정)
사용 상황	OLTP (트랜잭션 중심)	OLAP (분석/조회 중심)

⚠️ 반정규화 적용 기준 반정규화는 성능 문제가 실제로 발생한 후 고려해야 해요.
처음부터 반정규화하면 데이터 불일치 위험이 높아요.
정규화 먼저 → 성능 측정 → 필요한 부분만 반정규화가 올바른 순서예요.

08 정규화 단계 한눈에 정리

정규형	조건	제거 대상
1NF	모든 컬럼이 원자값	다중값, 반복 그룹
2NF	1NF + 완전 함수 종속	부분 함수 종속
3NF	2NF + 비이행 종속	이행 함수 종속
BCNF	3NF + 결정자 = 후보키	후보키가 아닌 결정자

✅ 면접 답변 핵심 "정규화는 데이터 중복을 제거하고 무결성을 보장하기 위해 테이블을 분리하는 과정입니다.
1NF(원자값) → 2NF(부분 종속 제거) → 3NF(이행 종속 제거) 순으로 적용하며,
실무에서는 3NF까지 적용하고, 조회 성능이 필요한 경우 반정규화를 고려합니다."

데이터베이스 정규화 1NF 2NF 3NF BCNF 반정규화 CS면접

[ERP] 구매/영업/재고 모듈 완전 정복 - P2P·O2C 흐름부터 재고 평가까지

woohaha — Mon, 11 May 2026 20:08:31 +0900

ERP · 구매 / 영업 / 재고 모듈

ERP의 꽃은 모듈 간 연계예요.
구매 → 재고 → 영업이 어떻게 연결되는지 흐름을 이해하면
개발할 때 전체 그림이 보이고 훨씬 수월해져요.

// TABLE OF CONTENTS

01 전체 모듈 연계 흐름

02 구매 모듈 — P2P 흐름

03 구매 모듈 — 핵심 용어

04 재고 모듈 — 재고 관리

05 재고 모듈 — 핵심 용어

06 영업 모듈 — O2C 흐름

07 영업 모듈 — 핵심 용어

08 재고 평가 방법

09 모듈 간 전표 자동화

10 개발 시 주의사항

01 전체 모듈 연계 흐름

ERP에서 구매/재고/영업은 독립된 모듈이지만 데이터가 서로 연결돼요.
한 모듈의 처리 결과가 다음 모듈의 입력이 되는 구조예요.

// 구매 → 재고 → 영업 → 회계 연계 흐름

발주 (구매) → 입고 → 재고 증가 → 수주 (영업) → 출하 → 재고 감소 → 회계 전표

※ 입고 → 매입채무 발생 / 출하 → 매출채권 발생 → 회계 모듈 자동 연동

02 구매 모듈 — P2P 흐름

Purchase to Pay. 구매 요청부터 대금 지급까지의 전체 흐름이에요.

STEP 1 구매 요청 (PR — Purchase Request)

현장/부서에서 필요한 물품 구매를 요청.
요청자 → 구매팀으로 승인 흐름. 예산 체크 포함.

PR구매요청예산체크

STEP 2 견적 / 협력사 선정

협력사에 견적 요청(RFQ). 가격/납기/품질 비교 후 선정.
중견기업은 승인된 협력사(Approved Vendor) 목록에서만 선정.

RFQ견적협력사

STEP 3 발주 (PO — Purchase Order)

협력사에 정식으로 주문. 발주서(PO) 발행.
품목/수량/단가/납기일 확정. 계약의 효력 발생.

PO발주서납기일

STEP 4 입고 (GR — Goods Receipt)

물품 수령 후 수량/품질 검사. 입고 처리 시 재고 자동 증가.
PO와 수량 대조(3-Way Matching).

GR입고검사재고증가

STEP 5 세금계산서 수취 & 지급

협력사로부터 세금계산서 수취 → 매입채무 확정.
지급기일에 맞춰 계좌이체/어음 지급 → 채무 소멸.

매입채무세금계산서지급

03 구매 모듈 — 핵심 용어

단가 계약

협력사와 특정 기간/물품의 단가를 미리 계약.
발주 시 단가 계약에서 자동 적용. 매번 견적 불필요.

A사 볼트 2024년 연간 단가: 500원/개

3-Way Matching

PO(발주) - GR(입고) - Invoice(세금계산서) 3개를 대조해서 일치 시에만 지급 승인.
부정 지급 방지의 핵심.

반품 (Return)

입고 후 불량/오배송 발견 시 협력사에 반품.
반품 처리 시 재고 자동 감소 + 매입채무 취소.

MRP (자재소요계획)

생산 계획 기반으로 필요 자재를 자동 계산해 발주 제안.
제조업 ERP의 핵심 기능.

완제품 100개 생산 → 부품 A 300개 필요 → 자동 발주 제안

발주 잔량

발주는 했지만 아직 입고되지 않은 수량.
발주량 - 입고량 = 발주잔량. 재고 예측에 사용.

검수 (Inspection)

입고 물품의 수량·품질 확인 절차.
전수검사/샘플검사 선택. 불합격 시 반품 처리.

04 재고 모듈 — 재고 수량 흐름

재고는 입고되면 늘고, 출고되면 줄어요.
ERP에서는 모든 재고 변동이 자동으로 기록돼야 해요.

// 재고 수량 계산 구조

기초재고 100개 + 입고 +50개 - 출고 -30개 - 반품출고 -5개 + 반품입고 +3개 = 기말재고 118개

재고 이동 유형

-- 재고 증가 이동

구매 입고    -- 협력사로부터 입고

생산 입고    -- 생산 완료 제품 입고

판매 반품    -- 고객이 반품한 물품 입고

재고 조정(+) -- 실사 후 수량 증가 조정

-- 재고 감소 이동

판매 출고    -- 고객에게 출하

생산 출고    -- 생산에 원자재 투입

구매 반품    -- 협력사에 반품

폐기         -- 불량/유효기간 만료

재고 조정(-) -- 실사 후 수량 감소 조정

-- 재고 이동 (증감 없음)

창고 간 이동 -- A창고 → B창고 (회사 내부)

로케이션 이동 -- 같은 창고 내 위치 변경

05 재고 모듈 — 핵심 용어

안전재고 (Safety Stock)

수요 변동·납기 지연에 대비한 최소 보유 재고량.
안전재고 이하로 떨어지면 발주 알림 발생.

안전재고 50개 → 재고 45개 → 발주 알림!

재주문점 (ROP)

발주를 트리거하는 재고 수준.
일평균 사용량 × 리드타임 + 안전재고로 계산.

일 10개 사용, 리드타임 5일 → ROP = 50+안전재고

로케이션 (Location)

창고 내 물품이 보관된 위치.
동-열-단 체계로 관리. 바코드/QR로 조회.

A동-3열-2단 → A-03-02

LOT / 배치 관리

동일 생산 배치를 LOT 번호로 묶어 추적.
불량 발생 시 해당 LOT 전체 추적 가능. 식품/의약품 필수.

LOT: 20241215-001 → 불량 발생 시 해당 LOT 전량 회수

재고 실사 (Physical Inventory)

실제 재고 수량과 시스템 수량을 대조하는 작업.
차이 발생 시 재고 조정 처리. 보통 월/분기/연 1회.

가용재고

실제 사용 가능한 재고량.
현재고 - 예약재고(출하 예정) + 발주잔량(입고 예정).

현재고 100 - 예약 30 + 발주잔량 50 = 가용 120

06 영업 모듈 — O2C 흐름

Order to Cash. 수주부터 대금 수령까지의 전체 흐름이에요.

STEP 1 견적 (Quotation)

고객 요청에 따라 가격/납기/조건을 제시.
견적 유효기간 내 수주 전환 가능.

견적서유효기간단가

STEP 2 수주 (SO — Sales Order)

고객의 정식 주문 접수. 재고 예약 발생.
가용재고 확인 후 납기 확정. 신용 한도 체크.

SO재고예약신용한도

STEP 3 출하 지시 / 피킹

창고에 출하 지시. 피킹(Picking) = 재고 위치에서 물품 꺼내기.
패킹(Packing) → 운송장 출력.

피킹패킹운송장

STEP 4 출하 (Delivery)

물품 발송. 출하 처리 시 재고 자동 감소.
매출 전표 자동 생성 → 회계 연동.

출하재고감소매출전표

STEP 5 세금계산서 발행 & 수금

전자세금계산서 발행 → 매출채권 확정.
수금 처리 시 매출채권 소멸. 미수금 관리 중요.

매출채권수금미수금

07 영업 모듈 — 핵심 용어

고객 (Customer)

영업 거래처. 신용한도, 결제조건, 담당 영업사원 등을 관리.
고객 코드로 모든 거래 이력 추적.

신용한도 (Credit Limit)

고객의 최대 외상 허용 금액.
수주 시 자동 체크. 한도 초과 시 수주 보류 또는 경고.

신용한도 5천만원 → 미수금 4천+신규 2천 = 초과!

납기 (Delivery Date)

고객에게 약속한 물품 도착 날짜.
납기 준수율이 영업 KPI. 재고/생산 계획과 연동.

수주 잔량

수주는 됐지만 아직 출하되지 않은 수량.
수주량 - 출하량 = 수주잔량. 생산/재고 계획 기준.

반품 (Sales Return)

고객이 불량/오배송 등으로 반품.
반품 입고 처리 → 재고 증가 + 매출 취소 전표.

채권 연령 분석

미수금을 30일/60일/90일 이상으로 구분 관리.
장기 미수금은 대손 처리 위험 → 집중 관리 대상.

08 재고 평가 방법

같은 품목도 언제 얼마에 샀냐에 따라 재고 단가가 달라져요.
평가 방법에 따라 매출원가와 재고자산 금액이 달라지므로 중요해요.

재고 평가 방법 비교 (볼트 100개 예시)

-- 입고 내역

1월: 50개 @ 1,000원 = 50,000원

2월: 50개 @ 1,200원 = 60,000원

총 100개, 총 110,000원

3월에 60개 출고

━━━ 선입선출법 (FIFO) ━━━

-- 먼저 들어온 것부터 먼저 나감

출고원가: 1월 50개(50,000) + 2월 10개(12,000) = 62,000원

기말재고: 2월 40개 × 1,200 = 48,000원

━━━ 총평균법 ━━━

-- 전체 평균 단가로 계산

평균단가: 110,000 ÷ 100개 = 1,100원

출고원가: 60개 × 1,100 = 66,000원

기말재고: 40개 × 1,100 = 44,000원

━━━ 이동평균법 ━━━

-- 입고 때마다 평균 재계산

-- 실시간 단가 관리. ERP에서 가장 많이 사용

실무에서는 국내 중견기업은 대부분 총평균법 또는 이동평균법을 사용해요.
선입선출법은 식품/의약품처럼 유통기한 관리가 필요한 업종에서 주로 사용해요.
재고 평가 방법은 회계 정책으로 정해두면 함부로 바꾸기 어려워요.

09 모듈 간 전표 자동 생성

ERP의 핵심 가치는 업무 처리 시 회계 전표가 자동으로 생성되는 것이에요.

모듈 처리	자동 생성 전표	차변	대변
구매 입고	매입 전표	재고자산	매입채무
구매 반품	역분개 전표	매입채무	재고자산
판매 출하	매출 전표	매출채권	매출 / 부가세
판매 반품	역분개 전표	매출 / 부가세	매출채권
재고 폐기	재고 조정 전표	재고폐기손실	재고자산

10 개발 시 핵심 주의사항

재고 수량 동시성 문제 동시에 여러 사용자가 같은 품목을 출고 처리하면 재고가 마이너스가 될 수 있어요.
출고 처리 시 FOR UPDATE(배타락)로 해당 재고 행을 잠그고 처리해야 해요.
재고 수량은 절대 마이너스가 되면 안 돼요 → 출고 전 가용재고 체크 필수!

이력 관리 필수 모든 재고 변동은 이동 이력 테이블에 기록해야 해요.
현재 수량만 저장하면 "언제 왜 줄었냐"를 추적할 수 없어요.
LOT 관리 품목은 LOT 별 수량까지 이력 추적이 필요해요.

모듈 간 트랜잭션 처리 출하 처리 시 재고 감소 + 매출 전표 생성이 하나의 트랜잭션으로 처리돼야 해요.
재고는 줄었는데 전표가 안 생기거나, 전표는 생겼는데 재고가 안 줄면 데이터 불일치 발생.
모듈 간 연계 처리는 반드시 COMMIT / ROLLBACK으로 묶어서 처리하세요.

✅ CONCLUSION 구매/재고/영업은 데이터가 서로 연결된 하나의 흐름이에요.
구매 입고 → 재고 증가 → 영업 출하 → 재고 감소 → 회계 전표 자동 생성.
개발할 때 이 흐름을 항상 머릿속에 그리면 어떤 모듈을 개발해도 길을 잃지 않아요!

ERP 구매모듈 영업모듈 재고모듈 P2P O2C 재고평가 MRP LOT관리

[DB] 트랜잭션 완전 정복 - ACID, 격리 수준, 데드락까지 한 번에

woohaha — Sun, 10 May 2026 11:50:21 +0900

CS 면접 대비 · 데이터베이스

DB 면접에서 "트랜잭션이 뭔가요?", "ACID가 뭔가요?"는 거의 필수 질문이에요.
개념부터 격리 수준, 실제 SQL까지 한 번에 정리해드릴게요.

// TABLE OF CONTENTS

01 트랜잭션이란?

02 ACID 특성

03 COMMIT / ROLLBACK

04 격리 수준 4단계

05 동시성 문제 3가지

06 락(Lock) 개념

07 데드락

08 면접 답변 정리

01 트랜잭션이란?

트랜잭션은 하나의 논리적 작업 단위예요.
여러 DB 작업을 묶어서 전부 성공하거나 전부 실패하게 만드는 것이 핵심이에요.

가장 유명한 예시 — 계좌 이체 A 계좌에서 100만원 출금 → B 계좌에 100만원 입금

만약 출금은 됐는데 입금 중 오류가 나면? → 돈이 사라짐!
트랜잭션으로 묶으면 → 입금 실패 시 출금도 자동 취소(ROLLBACK)

// 트랜잭션 흐름

BEGIN → UPDATE (출금) → UPDATE (입금) → COMMIT ✅ ← 모두 성공 시

BEGIN → UPDATE (출금) → ERROR 발생 → ROLLBACK ❌ ← 실패 시 전부 취소

02 ACID 특성

트랜잭션이 보장해야 하는 4가지 특성이에요. 면접에서 하나씩 설명할 수 있어야 해요.

Atomicity — 원자성

트랜잭션 내 작업은 전부 성공하거나 전부 실패해야 해요.
"쪼갤 수 없다"는 원자의 특성에서 유래.

계좌이체: 출금+입금 모두 성공 OR 모두 취소

Consistency — 일관성

트랜잭션 전후로 DB가 항상 일관된 상태를 유지해야 해요.
무결성 제약조건(PK, FK, NOT NULL 등)을 항상 만족.

이체 후 A+B 잔액 합계는 이체 전과 동일해야 함

Isolation — 격리성

동시에 실행되는 트랜잭션이 서로 영향을 주지 않아야 해요.
격리 수준(Isolation Level)으로 조절 가능.

A가 이체 중일 때 B는 중간 상태를 보면 안 됨

Durability — 지속성

COMMIT된 트랜잭션은 시스템 장애가 나도 영구적으로 반영돼야 해요.
WAL(Write-Ahead Logging)로 보장.

COMMIT 후 서버 다운돼도 데이터는 보존됨

03 COMMIT / ROLLBACK / SAVEPOINT

트랜잭션 제어 명령어

-- 트랜잭션 시작 (Oracle은 자동 시작, MySQL은 명시적)

BEGIN; -- MySQL/MSSQL

-- Oracle은 첫 DML부터 자동으로 트랜잭션 시작

-- 작업 수행

UPDATE ACCOUNT SET BALANCE = BALANCE - 1000000 WHERE ACCT_ID = 'A';

UPDATE ACCOUNT SET BALANCE = BALANCE + 1000000 WHERE ACCT_ID = 'B';

-- 성공 시: 영구 반영

COMMIT;

-- 실패 시: 전체 취소

ROLLBACK;

-- SAVEPOINT: 부분 롤백 지점 설정

SAVEPOINT SP1;

UPDATE ACCOUNT SET BALANCE = BALANCE - 500000 WHERE ACCT_ID = 'A';

SAVEPOINT SP2;

UPDATE ACCOUNT SET BALANCE = BALANCE + 500000 WHERE ACCT_ID = 'C';

-- SP2 이후만 취소 (SP1까지의 작업은 유지)

ROLLBACK TO SP2;

COMMIT; -- SP1~SP2 작업만 반영

⚠️ AUTO COMMIT 주의 MySQL은 기본적으로 AUTO COMMIT = ON이에요.
즉, DML 실행 즉시 자동 COMMIT → ROLLBACK 불가!
트랜잭션을 직접 제어하려면 SET autocommit = 0; 또는 BEGIN;으로 시작해야 해요.
Oracle은 AUTO COMMIT이 기본 OFF예요.

04 격리 수준 4단계 (Isolation Level)

트랜잭션 간의 격리 정도를 4단계로 설정할 수 있어요.
격리 수준이 높을수록 정합성 ↑, 동시성 ↓이에요.

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read	성능
READ UNCOMMITTED	발생	발생	발생	최고
READ COMMITTED	방지	발생	발생	높음
REPEATABLE READ ★	방지	방지	발생	보통
SERIALIZABLE	방지	방지	방지	최저

DB별 기본 격리 수준 MySQL InnoDB → REPEATABLE READ (기본값)
Oracle → READ COMMITTED (기본값)
MSSQL → READ COMMITTED (기본값)
대부분의 서비스는 READ COMMITTED 또는 REPEATABLE READ를 사용해요.

05 동시성 문제 3가지

① Dirty Read — 더티 리드

아직 COMMIT 안 된 데이터를 다른 트랜잭션이 읽는 것이에요.

TX1: UPDATE BALANCE = 5000 (아직 COMMIT 안 함)

TX2: SELECT BALANCE → 5000 읽음 (Dirty Read!)

TX1: ROLLBACK → BALANCE 원래대로

TX2: 5000이라는 잘못된 값으로 작업함

② Non-Repeatable Read — 반복 불가 읽기

같은 트랜잭션 내에서 같은 쿼리를 두 번 실행했는데 결과가 달라지는 것이에요.

TX1: SELECT BALANCE → 3000

TX2: UPDATE BALANCE = 5000 → COMMIT

TX1: SELECT BALANCE → 5000 (값이 바뀜!)

-- 같은 TX1인데 두 번 조회 결과가 다름

③ Phantom Read — 팬텀 리드

같은 트랜잭션 내에서 같은 조건으로 조회했는데 없던 행이 생기거나 사라지는 것이에요.

TX1: SELECT COUNT(*) WHERE AGE > 20 → 5건

TX2: INSERT (AGE=25) → COMMIT

TX1: SELECT COUNT(*) WHERE AGE > 20 → 6건

-- 없던 행이 생김 (Phantom!)

06 락(Lock) 개념

동시성 문제를 해결하기 위해 DB는 락(Lock)을 사용해요.

락 종류 및 사용법

━━━ 공유락 (Shared Lock / S-Lock) ━━━

-- 읽기 락. 여러 트랜잭션이 동시에 읽기 가능

-- 공유락 걸린 동안 쓰기(배타락) 불가

SELECT * FROM ACCOUNT WHERE ACCT_ID = 'A' LOCK IN SHARE MODE; -- MySQL

SELECT * FROM ACCOUNT WHERE ACCT_ID = 'A' FOR SHARE; -- MySQL 8.0+

━━━ 배타락 (Exclusive Lock / X-Lock) ━━━

-- 쓰기 락. 해당 row를 혼자 독점

-- 다른 트랜잭션의 읽기/쓰기 모두 대기

SELECT * FROM ACCOUNT WHERE ACCT_ID = 'A' FOR UPDATE; -- 배타락

━━━ FOR UPDATE 실무 활용 ━━━

-- 잔액 조회 후 차감할 때 중간에 다른 TX가 끼어들지 못하게

BEGIN;

SELECT BALANCE FROM ACCOUNT WHERE ACCT_ID = 'A' FOR UPDATE;

UPDATE ACCOUNT SET BALANCE = BALANCE - 1000 WHERE ACCT_ID = 'A';

COMMIT;

07 데드락 (DeadLock)

두 트랜잭션이 서로 상대방의 락이 풀리기를 기다리는 무한 대기 상태예요.

데드락 발생 시나리오

TX1: A 락 획득 → B 락 요청 (대기 중...)

TX2: B 락 획득 → A 락 요청 (대기 중...)

-- TX1은 TX2가 B를 놓길 기다리고

-- TX2는 TX1이 A를 놓길 기다림

-- → 영원히 대기 = DeadLock!

━━━ 예방 방법 ━━━

-- 1. 항상 같은 순서로 락 획득

TX1: A 락 → B 락 (순서 고정)

TX2: A 락 → B 락 (같은 순서)

-- 2. 락 타임아웃 설정

SET innodb_lock_wait_timeout = 30; -- 30초 후 자동 포기

-- 3. 트랜잭션을 짧게 유지

-- 락 보유 시간을 최소화

⚠️ DB의 데드락 감지 DB는 데드락을 자동으로 감지하고, 두 트랜잭션 중 하나를 강제 종료(ROLLBACK)해요.
어떤 트랜잭션을 종료할지는 DB가 판단해요 (보통 더 적은 작업을 한 쪽).
애플리케이션 코드에서는 데드락 오류를 잡아서 재시도 로직을 구현해야 해요.

08 면접 답변 정리

면접 예상 Q&A

Q. 트랜잭션이란 무엇인가요?

"DB에서 하나의 논리적 작업 단위로, 여러 쿼리를 묶어

전부 성공하거나 전부 실패하게 보장하는 것입니다.

ACID 특성을 만족해야 하며 COMMIT/ROLLBACK으로 제어합니다."

Q. ACID를 설명해주세요.

"A(원자성): 전부 성공 or 전부 실패

C(일관성): 트랜잭션 전후 DB 무결성 유지

I(격리성): 동시 트랜잭션 간 독립성 보장

D(지속성): COMMIT 후 장애에도 영구 보존"

Q. 격리 수준에 대해 설명해주세요.

"READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE

순으로 격리 수준이 높아지며, 정합성은 높아지고 동시성은 낮아집니다.

MySQL InnoDB 기본값은 REPEATABLE READ입니다."

✅ CONCLUSION 트랜잭션은 ACID + COMMIT/ROLLBACK + 격리 수준 세트로 기억하세요.
면접에서 Dirty Read / Non-Repeatable Read / Phantom Read 세 가지 동시성 문제까지 언급하면
확실히 차별화됩니다. 데드락 방지법도 알아두면 플러스!

데이터베이스 트랜잭션 ACID 격리수준 DeadLock CS면접 COMMIT ROLLBACK

[ERP] 회계 모듈 완전 정복 - 전표부터 재무제표까지 업무 흐름 총정리

woohaha — Sat, 9 May 2026 21:01:56 +0900

ERP · 회계 모듈

인사/급여 모듈에 이어 이번엔 ERP 회계 모듈을 정리해봤어요.
회계는 전표, 계정과목, 결산 같은 용어가 낯설어서 처음엔 어렵게 느껴지는데,
흐름을 먼저 이해하면 개발이 훨씬 쉬워져요.

// TABLE OF CONTENTS

01 회계 기본 개념

02 계정과목 체계

03 전표 (분개) 구조

04 전표 유형

05 매입/매출 흐름

06 월마감 & 결산 흐름

07 재무제표 종류

08 부가세(VAT) 처리

09 원가 모듈 연동

10 개발 시 주의사항

01 회계 기본 개념

회계는 기업의 모든 경제적 거래를 기록하고 보고하는 시스템이에요.
ERP 회계 모듈은 이 모든 거래를 자동으로 전표로 변환하는 게 핵심이에요.

복식부기

모든 거래를 차변(Debit)과 대변(Credit) 양쪽에 동시 기록.
차변 합계 = 대변 합계 → 항상 균형 유지.

현금 수령 → 차변: 현금 / 대변: 매출

차변 (Debit)

전표의 왼쪽. 자산 증가 / 부채·자본 감소 / 비용 발생을 기록.

현금 받음 → 차변: 현금(자산↑)

대변 (Credit)

전표의 오른쪽. 자산 감소 / 부채·자본 증가 / 수익 발생을 기록.

현금 받음 → 대변: 매출(수익↑)

발생주의

현금 수수 시점이 아닌 거래 발생 시점에 인식.
중견기업 이상은 모두 발생주의 적용.

12월 납품 → 1월 수금이어도 12월 매출

차변/대변 쉽게 외우기 차변 = 돈 나갈 때 / 자산 늘 때 / 비용 생길 때
대변 = 돈 들어올 때 / 부채 늘 때 / 수익 생길 때
헷갈리면 "차변은 왼쪽, 자산·비용은 차변에서 증가"로 기억하세요.

02 계정과목 체계

모든 거래는 계정과목(Account)으로 분류돼요.
ERP에서는 계정과목 코드 체계를 처음에 잘 설계해야 나중에 고생이 없어요.

계정과목 분류 체계

━━━ 재무상태표 계정 (B/S) ━━━

자산 (Assets)

  유동자산: 현금, 보통예금, 매출채권, 재고자산

  비유동자산: 건물, 기계장치, 토지, 소프트웨어

부채 (Liabilities)

  유동부채: 매입채무, 미지급금, 예수금, 단기차입금

  비유동부채: 장기차입금, 퇴직급여충당부채

자본 (Equity)

  자본금, 이익잉여금, 기타포괄손익

━━━ 손익계산서 계정 (P&L) ━━━

수익 (Revenue)

  매출, 영업외수익, 이자수익

비용 (Expense)

  매출원가, 급여, 임차료, 감가상각비, 이자비용

매출채권 (AR)

물건을 팔았는데 아직 못 받은 돈. 외상매출금.
Accounts Receivable. 자산 계정.

납품 완료, 대금은 30일 후 수령 예정

매입채무 (AP)

물건을 샀는데 아직 안 낸 돈. 외상매입금.
Accounts Payable. 부채 계정.

원자재 구매, 대금은 다음달 지급 예정

미지급금

영업 외 거래에서 발생한 미지급액.
매입채무는 영업 거래, 미지급금은 그 외 거래.

PC 구입 후 미지급, 광고비 미지급

선급금 / 선수금

선급금 = 먼저 준 돈 (자산) / 선수금 = 먼저 받은 돈 (부채).
계약금이 대표적인 예.

계약금 10% 선수령 → 선수금(부채)

예수금

직원 급여에서 공제해 보관 중인 돈.
소득세, 4대보험 등. 나중에 국세청/공단에 납부.

급여 공제 소득세 → 예수금(부채)

감가상각

건물·기계 등 유형자산의 가치를 내용연수에 걸쳐 비용으로 배분.
현금 지출 없는 비용.

5천만원 기계 → 5년 정액법 → 연 1천만원 비용

03 전표 (분개) 구조

모든 거래는 전표(Journal Entry)로 기록돼요.
차변 합계와 대변 합계가 반드시 일치해야 해요.

예시 1 — 제품 외상 판매 (100만원)

구분	계정과목	적요	차변	대변
차변	매출채권	A사 제품 판매	1,000,000	-
대변	매출	A사 제품 판매	-	909,091
대변	부가세예수금	VAT 10%	-	90,909
합계			1,000,000	1,000,000

예시 2 — 급여 지급 (300만원)

구분	계정과목	적요	차변	대변
차변	급여	3월 급여	3,000,000	-
대변	예수금(소득세)	원천세	-	150,000
대변	예수금(4대보험)	보험료	-	270,000
대변	보통예금	실수령액 이체	-	2,580,000
합계			3,000,000	3,000,000

04 전표 유형

일반전표

일반적인 회계 거래 기록.
수동으로 입력하거나 타 모듈에서 자동 생성.

매입전표

구매/매입 시 발생하는 전표.
구매 모듈에서 입고 처리 시 자동 생성.

매출전표

판매/매출 시 발생하는 전표.
영업 모듈에서 출하 처리 시 자동 생성.

급여전표

인사 모듈 급여 마감 후 자동 생성.
부서별 급여 비용 배분까지 처리.

결산전표

월/연 결산 시 수동 또는 자동 생성.
감가상각, 충당금, 선급비용 안분 등.

역분개 전표

잘못된 전표를 취소할 때 반대 방향으로 생성.
삭제 대신 역분개로 이력 보존.

05 매입 / 매출 흐름

매출 흐름 (Order to Cash)

// 매출 O2C 흐름

수주 (영업) → 출하/납품 → 세금계산서 발행 → 매출 전표 생성 → 대금 수령 → 채권 소멸

매입 흐름 (Purchase to Pay)

// 매입 P2P 흐름

발주 (구매) → 입고 처리 → 세금계산서 수취 → 매입 전표 생성 → 대금 지급 → 채무 소멸

세금계산서

VAT 포함 거래의 증빙 서류. 전자세금계산서 의무 발행(일정 규모 이상).
공급가액 + 부가세 명시.

계산서

VAT 면세 거래 증빙. 면세 품목(농산물, 의료 등).
부가세 없이 공급가액만.

채권 관리 (AR)

매출 후 수금 관리. 채권 잔액 = 매출액 - 수금액.
연령 분석(30일/60일/90일 이상)으로 부실채권 관리.

채무 관리 (AP)

매입 후 지급 관리. 지급 기일 관리가 핵심.
어음, 현금, 계좌이체 등 지급 수단 다양.

06 월마감 & 결산 흐름

STEP 1 전표 입력 마감

해당 월의 모든 거래 전표 입력 완료 확인.
마감 후 해당 월 전표 수정/추가 불가. 오류 발견 시 역분개로 처리.

전표마감기간잠금

STEP 2 결산 조정 전표

감가상각비 계상, 선급비용 안분, 충당금 설정 등 결산 조정 전표 생성.
대부분 자동 계산 후 검토.

감가상각선급비용안분충당금

STEP 3 부가세 신고 자료

분기별 부가세 신고(1/4/7/10월). 매출세액 - 매입세액 = 납부세액.
전자세금계산서 합계표 홈택스 연동.

부가세신고홈택스연동

STEP 4 재무제표 생성

재무상태표(B/S), 손익계산서(P&L), 현금흐름표 자동 생성.
경영진 보고용 및 외부 감사 자료.

재무상태표손익계산서감사

STEP 5 월마감 확정

월마감 확정 후 해당 월 완전 잠금.
다음 달 시작 잔액(이월잔액) 자동 생성.

월마감이월잔액기간잠금

07 재무제표 종류

재무상태표 (B/S)

특정 시점의 자산 = 부채 + 자본 현황.
Balance Sheet. "이 회사 재산이 얼마냐?"

2024-12-31 기준 자산 100억, 부채 60억, 자본 40억

손익계산서 (P&L)

일정 기간의 수익 - 비용 = 이익 현황.
Profit & Loss. "이 기간에 얼마 벌었냐?"

2024년 매출 50억 - 비용 42억 = 영업이익 8억

현금흐름표

실제 현금의 유입/유출 현황.
이익이 나도 현금이 없으면 부도 → 흑자도산 방지.

자본변동표

자본의 변동 내역. 배당, 유상증자, 당기순이익 등.
중견기업 이상은 4가지 재무제표 모두 작성 의무.

08 부가세(VAT) 처리

부가세 계산 구조

-- 매출 시 (부가세 10% 포함)

공급가액: 1,000,000원

부가세:     100,000원 (매출세액 — 국가에 납부)

합계:   1,100,000원 (거래처로부터 수령)

-- 매입 시 (부가세 10% 포함)

공급가액: 500,000원

부가세:      50,000원 (매입세액 — 환급 가능)

합계:     550,000원 (거래처에 지급)

-- 분기 부가세 납부액

납부세액 = 매출세액 - 매입세액

납부세액 = 100,000 - 50,000 = 50,000원 납부

부가세 예수금

매출 시 거래처로부터 받은 부가세. 부채 계정.
분기별로 국세청에 납부해야 하는 돈.

부가세 대급금

매입 시 거래처에 지급한 부가세. 자산 계정.
매출세액에서 공제(환급)받을 수 있는 돈.

과세 / 면세

과세 = VAT 10% 부과 (대부분 재화·용역)
면세 = VAT 없음 (농산물, 의료, 교육 등)

영세율

수출 거래. VAT 0% 적용. 매입세액은 전액 환급.
수출 기업에서 자주 나오는 개념.

09 원가 모듈 연동

중견기업 이상은 원가 모듈이 회계 모듈과 연동돼요.
제품 하나를 만드는 데 얼마가 들었는지를 정확하게 계산하는 게 목적이에요.

직접재료비

제품 생산에 직접 들어가는 원자재 비용.
구매 → 입고 → 생산 투입 흐름으로 추적.

직접노무비

생산 작업자 인건비. 작업시간 × 시간당 임률.
인사 모듈 급여와 연동.

제조간접비

전력비, 감가상각비 등 직접 추적 어려운 비용.
배부 기준(작업시간, 기계시간)으로 제품에 안분.

매출원가

판매된 제품의 원가.
매출 - 매출원가 = 매출총이익.
재고 평가 방법(선입선출, 평균법)에 따라 달라짐.

10 개발 시 핵심 주의사항

전표 수정 이력 반드시 보존 확정된 전표는 삭제가 아닌 역분개로 처리해야 해요.
전표 이력이 없으면 감사 시 문제가 돼요.
전표 상태(임시/확정/역분개)를 플래그로 관리하고, 확정 후에는 수정 불가 로직 필수.

차변 합계 = 대변 합계 검증 전표 저장 시 반드시 차대 밸런스 체크 로직 넣어야 해요.
차변 합계 ≠ 대변 합계이면 저장 자체를 막아야 합니다.
회계 데이터 정합성의 가장 기본 원칙이에요.

기간 잠금 처리 마감된 회계 기간에는 전표 입력/수정 불가 처리해야 해요.
PERIOD_LOCK 테이블로 기간별 잠금 상태를 관리하고,
전표 저장 시 해당 기간 잠금 여부를 반드시 체크해야 해요.

✅ CONCLUSION 회계 모듈 핵심은 전표 → 원장 → 재무제표 흐름이에요.
타 모듈(인사/구매/영업)과 자동 전표 연동이 ERP 회계의 핵심 가치고,
차대 밸런스 / 전표 이력 / 기간 잠금 세 가지는 개발 시 절대 빠트리면 안 돼요!

ERP 회계모듈 전표 분개 계정과목 부가세 결산 재무제표 매입채무 매출채권