알아두면 쓸데있는 IT 잡학사전

객체지향(OOP)의 Interface

그레고리오78 — Tue, 17 Mar 2026 08:15:56 +0900

1. Interface의 개요

1.1 Interface의 정의

Interface는 객체가 수행해야 할 행위(Method)의 명세(Contract) 를 정의하는 추상 타입입니다.

즉,

무엇을 할 것인가만 정의
어떻게 할 것인가는 구현 클래스가 결정

특징	설명
추상 타입	구현이 아닌 메소드 선언만 포함
다중 구현 가능	여러 클래스가 동일 Interface 구현
느슨한 결합	구현체 변경 시 영향 최소
다형성 지원	동일 인터페이스로 다양한 객체 처리

간단한 개념 예

interface Payment
   pay()

class CardPayment implements Payment
class CashPayment implements Payment

// 실제 실행 시
Payment p = new CardPayment()
Payment p = new CashPayment()

→ 동일 Interface로 다양한 객체 처리

1.2 Interface UML 표현

UML에서는 «interface» 또는 lollipop notation 으로 표현합니다.

구현 관계

UML 관계 표기

관계	UML 표기	의미
Interface	«interface»	인터페이스 정의
Implementation	Realization	클래스 구현
Method	+method()	public method

2. 개발 언어별 Interface 비교

2.1 언어별 Interface 특징

언어	Interface 지원	특징
C	직접 없음	Function Pointer로 구현
C++	추상 클래스	pure virtual function
Java	Interface 키워드	다중 구현 가능
C#	Interface 키워드	Java와 유사
VB.NET	Interface 키워드	Implements 사용
Python	ABC / Duck typing	추상 클래스 기반

2.2 Interface와 관련 Design Pattern

Interface는 대부분의 GoF Design Pattern의 핵심입니다.

Pattern	목적
Strategy	알고리즘 교체
Factory Method	객체 생성 분리
Adapter	인터페이스 변환
Proxy	접근 제어
Decorator	기능 확장

2.3 Design Pattern

① Strategy Pattern

알고리즘을 Interface로 분리하여 동적으로 교체

예제 코드

// ① Strategy 인터페이스
public interface Strategy {
    void execute();
}

// ② ConcreteStrategy A
public class StrategyA implements Strategy {
    @Override
    public void execute() {
        System.out.println("StrategyA 실행: 알고리즘 A 수행");
    }
}

// ③ ConcreteStrategy B
public class StrategyB implements Strategy {
    @Override
    public void execute() {
        System.out.println("StrategyB 실행: 알고리즘 B 수행");
    }
}

// ④ Context — Strategy를 주입받아 위임
public class Context {
    private Strategy strategy;

    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    public void setStrategy(Strategy strategy) {
        this.strategy = strategy;
    }

    public void executeStrategy() {
        strategy.execute();  // 실제 알고리즘은 Strategy에 위임
    }
}

// ⑤ Client
public class Main {
    public static void main(String[] args) {
        Context context = new Context(new StrategyA());
        context.executeStrategy();  // StrategyA 실행: 알고리즘 A 수행

        // 런타임에 전략 교체
        context.setStrategy(new StrategyB());
        context.executeStrategy();  // StrategyB 실행: 알고리즘 B 수행
    }
}

코드 설명

Context는 Strategy 인터페이스에만 의존하기 때문에 StrategyA와 StrategyB를 전혀 알지 못합니다. 덕분에 새로운 전략(StrategyC)을 추가할 때 Context를 수정할 필요 없이 인터페이스만 구현하면 됩니다 — OCP(개방-폐쇄 원칙) 준수.

setStrategy()를 통해 런타임에 알고리즘을 동적으로 교체할 수 있는 것이 이 패턴의 핵심 장점입니다. 결제 수단 선택, 정렬 알고리즘 교체, 압축 방식 변경 등 "행동을 바꿔끼워야 하는" 상황에 적합합니다.

특징

알고리즘 교체 가능
OCP(Open Closed Principle)

② Factory Method Pattern

객체 생성 로직을 Interface 기반으로 분리

예제 코드

// ① Product 인터페이스
public interface Product {
    void use();
}

// ② ConcreteProduct — Product 구현체
public class ConcreteProduct implements Product {
    private String name;

    public ConcreteProduct(String name) {
        this.name = name;
    }

    @Override
    public void use() {
        System.out.println(name + " 사용 중");
    }
}

// ③ Creator — 팩토리 메서드를 선언하는 추상 클래스
public abstract class Creator {

    // 팩토리 메서드: 서브클래스가 어떤 객체를 만들지 결정
    public abstract Product createProduct();

    // 공통 비즈니스 로직: 생성은 createProduct()에 위임
    public void doSomething() {
        Product product = createProduct();
        System.out.print("Creator.doSomething → ");
        product.use();
    }
}

// ④ ConcreteCreator — 팩토리 메서드를 오버라이드해 구체 객체 반환
public class ConcreteCreator extends Creator {

    @Override
    public Product createProduct() {
        return new ConcreteProduct("ConcreteProduct");
    }
}

// ⑤ Client
public class Main {
    public static void main(String[] args) {
        Creator creator = new ConcreteCreator();

        // 팩토리 메서드 직접 호출
        Product product = creator.createProduct();
        product.use();                 // ConcreteProduct 사용 중

        // 또는 Creator의 템플릿 메서드를 통해 간접 호출
        creator.doSomething();         // Creator.doSomething → ConcreteProduct 사용 중
    }
}

실전 예시-알람

public interface Notification {
    void send(String message);
}

public class EmailNotification implements Notification {
    @Override public void send(String message) {
        System.out.println("[EMAIL] " + message);
    }
}

public class SmsNotification implements Notification {
    @Override public void send(String message) {
        System.out.println("[SMS] " + message);
    }
}

public abstract class NotificationCreator {
    public abstract Notification createNotification();

    public void notify(String message) {
        createNotification().send(message);
    }
}

public class EmailCreator extends NotificationCreator {
    @Override public Notification createNotification() { return new EmailNotification(); }
}

public class SmsCreator extends NotificationCreator {
    @Override public Notification createNotification() { return new SmsNotification(); }
}

// Client
NotificationCreator creator = new EmailCreator();
creator.notify("주문이 완료되었습니다.");   // [EMAIL] 주문이 완료되었습니다.

creator = new SmsCreator();
creator.notify("배송이 시작되었습니다.");   // [SMS] 배송이 시작되었습니다.

③ Adapter Pattern

호환되지 않는 인터페이스 연결

예제 코드

// ① Target — Client가 기대하는 인터페이스
public interface Target {
    void request();
}

// ② Adaptee — 이미 존재하는 클래스 (인터페이스가 맞지 않음)
public class Adaptee {
    public void specificRequest() {
        System.out.println("[Adaptee] specificRequest() 실행 (기존 방식)");
    }
}

// ③ Adapter — Target을 구현하고, 내부에서 Adaptee에 위임
public class Adapter implements Target {
    private final Adaptee adaptee;

    public Adapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }

    @Override
    public void request() {
        System.out.println("[Adapter] request() 호출 → specificRequest()로 변환");
        adaptee.specificRequest();  // 인터페이스 변환 후 위임
    }
}

// ④ Client — Target만 바라보고, Adaptee의 존재를 모름
public class Client {
    private final Target target;

    public Client(Target target) {
        this.target = target;
    }

    public void doWork() {
        target.request();
    }
}

// ⑤ Main
public class Main {
    public static void main(String[] args) {
        Adaptee adaptee = new Adaptee();
        Target adapter  = new Adapter(adaptee);
        Client client   = new Client(adapter);

        client.doWork();
        // [Adapter] request() 호출 → specificRequest()로 변환
        // [Adaptee] specificRequest() 실행 (기존 방식)
    }
}

실전 예시-레거시 결제 시스템 연동

// 기존 레거시 결제 모듈 (변경 불가)
public class LegacyPaymentSystem {
    public void makePayment(String accountNo, double amount) {
        System.out.printf("[Legacy] 계좌 %s 에 %.0f원 결제%n", accountNo, amount);
    }
}

// 신규 시스템이 기대하는 인터페이스
public interface PaymentProcessor {
    void pay(String userId, int amount);
}

// 어댑터: 신규 인터페이스 → 레거시 호출로 변환
public class LegacyPaymentAdapter implements PaymentProcessor {
    private final LegacyPaymentSystem legacy;

    public LegacyPaymentAdapter(LegacyPaymentSystem legacy) {
        this.legacy = legacy;
    }

    @Override
    public void pay(String userId, int amount) {
        String accountNo = "ACC-" + userId;   // userId → 계좌번호 변환
        legacy.makePayment(accountNo, amount); // 레거시에 위임
    }
}

// Client (신규 시스템)
public class OrderService {
    private final PaymentProcessor processor;

    public OrderService(PaymentProcessor processor) {
        this.processor = processor;
    }

    public void placeOrder(String userId, int price) {
        System.out.println("주문 처리 중...");
        processor.pay(userId, price);
    }
}

// Main
PaymentProcessor adapter = new LegacyPaymentAdapter(new LegacyPaymentSystem());
OrderService service = new OrderService(adapter);
service.placeOrder("user42", 15000);
// 주문 처리 중...
// [Legacy] 계좌 ACC-user42 에 15000원 결제

3. 개발 언어별 Interface 예제

3.1 C 언어 (Function Pointer 기반)

C는 Interface가 없기 때문에 struct + function pointer 사용

#include <stdio.h>

typedef struct {
    void (*pay)(int);
} Payment;

void cardPay(int amount) {
    printf("Card Pay: %d\n", amount);
}

void cashPay(int amount) {
    printf("Cash Pay: %d\n", amount);
}

int main() {

    Payment card = { cardPay };
    Payment cash = { cashPay };

    card.pay(100);
    cash.pay(200);

}

3.2 C++ Interface

C++에서는 pure virtual function 사용

#include <iostream>
using namespace std;

class Payment {
public:
    virtual void pay(int amount) = 0;
};

class CardPayment : public Payment {
public:
    void pay(int amount) {
        cout << "Card Pay: " << amount << endl;
    }
};

int main() {
    Payment* p = new CardPayment();
    p->pay(100);
}

3.3 Java Interface

interface Payment {
    void pay(int amount);
}

class CardPayment implements Payment {

    public void pay(int amount) {
        System.out.println("Card Pay : " + amount);
    }
}

public class Main {

    public static void main(String[] args) {

        Payment p = new CardPayment();
        p.pay(100);

    }

}

3.4 C# Interface

using System;

interface IPayment
{
    void Pay(int amount);
}

class CardPayment : IPayment
{
    public void Pay(int amount)
    {
        Console.WriteLine("Card Pay " + amount);
    }
}

class Program
{
    static void Main()
    {
        IPayment p = new CardPayment();
        p.Pay(100);
    }
}

3.5 VB.NET Interface

Interface IPayment
    Sub Pay(amount As Integer)
End Interface

Class CardPayment
    Implements IPayment

    Public Sub Pay(amount As Integer) Implements IPayment.Pay
        Console.WriteLine("Card Pay " & amount)
    End Sub
End Class

Module Program

    Sub Main()

        Dim p As IPayment = New CardPayment()
        p.Pay(100)

    End Sub

End Module

3.6 Python Interface

Python은 ABC(Abstract Base Class) 사용

from abc import ABC, abstractmethod

class Payment(ABC):

    @abstractmethod
    def pay(self, amount):
        pass

class CardPayment(Payment):

    def pay(self, amount):
        print("Card Pay:", amount)

p = CardPayment()
p.pay(100)

4. Method Overload / Method Override

4.1 Method Overload의 정의

같은 이름의 메소드지만 파라미터가 다른 메소드

add(int a, int b)
add(int a, int b, int c)

4.2 Method Override의 정의

부모 클래스 메소드를 자식 클래스에서 재정의

class Parent
   run()

class Child
   run()  ← override

4.3 Method Overload와 Method Override 비교

구분	Overload	Override
목적	메소드 확장	기능 재정의
위치	동일 클래스	상속 관계
파라미터	다름	동일
반환 타입	동일/다름 가능	동일
다형성	compile time	runtime

4.4 예제 코드 (Java)

Overload

class Calc {

    int add(int a, int b) {
        return a + b;
    }

    int add(int a, int b, int c) {
        return a + b + c;
    }

}

Override

class Animal {

    void sound() {
        System.out.println("Animal Sound");
    }

}

class Dog extends Animal {

    @Override
    void sound() {
        System.out.println("Dog Bark");
    }

}

OOP 핵심 구조

SOLID 원칙은 이 4대 원칙 위에서 설계 지침으로 동작한다

TypeScript Coding Conventions

그레고리오78 — Mon, 16 Mar 2026 18:36:13 +0900

변수

의미있는 변수 이름을 사용하세요

읽는 사람으로 하여금 변수마다 어떤 점이 다른지 알 수 있도록 이름을 구별하세요.

function between(a1: T, a2: T, a3: T): boolean {
  return a2 <= a1 && a1 <= a3;
}

Good

function between(value: T, left: T, right: T): boolean {
  return left <= value && value <= right;
}

발음할 수 있는 변수 이름을 사용하세요

발음할 수 없는 이름은 그 변수에 대해서 바보 같이 소리를 내 토론할 수밖에 없습니다.

Bad `

type DtaRcrd102 = {
  genymdhms: Date;
  modymdhms: Date;
  pszqint: number;
}

Good `

type Customer = {
  generationTimestamp: Date;
  modificationTimestamp: Date;
  recordId: number;
}

동일한 유형의 변수는 동일한 단어를 사용하세요

Bad `

    function getUserInfo(): User;
    function getUserDetails(): User;
    function getUserData(): User;

Good `
```
    function getUser(): User;
```

검색할 수 있는 이름을 사용하세요

코드를 쓸 때보다 읽을 때가 더 많기 때문에 우리가 쓰는 코드는 읽을 수 있고 검색이 가능해야 합니다. 프로그램을 이해할 때 의미있는 변수 이름을 짓지 않으면 읽는 사람으로 하여금 어려움을 줄 수 있습니다. 검색 가능한 이름을 지으세요. TSLint와 같은 도구는 이름이 없는 상수를 식별할 수 있도록 도와줍니다.

Bad `
// 86400000이 도대체 뭐지? setTimeout(restart, 86400000);
Good `
// 대문자로 이루어진 상수로 선언하세요. const MILLISECONDS_IN_A_DAY = 24 * 60 * 60 * 1000; setTimeout(restart, MILLISECONDS_IN_A_DAY);

의도를 나타내는 변수를 사용하세요

Bad `
declare const users: Map<string, User>; for (const keyValue of users) { // users 맵을 순회 }
Good `
declare const users: Map<string, User>; for (const [id, user] of users) { // users 맵을 순회 }

암시하는 이름은 사용하지 마세요

명시적인 것이 암시적인 것보다 좋습니다. 명료함은 최고입니다.

Bad `
const u = getUser(); const s = getSubscription(); const t = charge(u, s);
Good `
const user = getUser(); const subscription = getSubscription(); const transaction = charge(user, subscription);

불필요한 문맥은 추가하지 마세요

클래스/타입/객체의 이름에 의미가 담겨있다면, 변수 이름에서 반복하지 마세요.

Bad `
type Car = { carMake: string; carModel: string; carColor: string; } function print(car: Car): void { console.log(${car.carMake} ${car.carModel} (${car.carColor})); }
Good ````tsmake: string;color: string;function print(car: Car): void {}
console.log(${car.make} ${car.model} (${car.color}));
}
model: string;
type Car = {

short circuiting이나 조건문 대신 기본 매개변수를 사용하세요

기본 매개변수는 short circuiting보다 보통 명료합니다.

Bad `
function loadPages(count?: number) { const loadCount = count !== undefined ? count : 10; // ... }
Good `
function loadPages(count: number = 10) { // ... }

함수

함수의 매개변수는 2개 혹은 그 이하가 이상적입니다

함수 매개변수의 개수를 제한하는 것은 함수를 테스트하기 쉽게 만들어주기 때문에 놀라울 정도로 중요합니다. 함수 매개변수가 3개 이상인 경우, 각기 다른 인수로 여러 다른 케이스를 테스트해야 하므로 경우의 수가 매우 많아집니다.
한 개 혹은 두 개의 매개변수가 이상적인 경우고, 가능하다면 세 개는 피해야 합니다. 그 이상의 경우에는 합쳐야 합니다. 두 개 이상의 매개변수를 가질 경우, 함수가 많은 것을 할 가능성이 높아집니다. 그렇지 않은 경우, 대부분 상위 객체는 하나의 매개변수로 충분할 것입니다.
많은 매개변수를 사용해야 한다면 객체 리터럴을 사용하는 것을 고려해보세요.
함수가 기대하는 속성을 명확하게 하기 위해, 구조 분해 구문을 사용할 수 있습니다. 이 구문은 몇 개의 장점을 가지고 있습니다:

어떤 사람이 함수 시그니쳐(매개변수의 타입, 반환값의 타입 등)를 볼 때, 어떤 속성이 사용되는지 즉시 알 수 있습니다.
명명된 매개변수처럼 보이게 할 때 사용할 수 있습니다.
또한 구조 분해는 함수로 전달된 매개변수 객체의 특정한 원시 값을 복제하며 이것은 사이드 이펙트를 방지하는데 도움을 줍니다. 유의사항: 매개변수 객체로부터 구조 분해된 객체와 배열은 복제되지 않습니다.
타입스크립트는 사용하지 않은 속성에 대해서 경고를 주며, 구조 분해를 사용하면 경고를 받지 않을 수 있습니다.

Bad
function createMenu(title: string, body: string, buttonText: string, cancellable: boolean) { // ... } createMenu('Foo', 'Bar', 'Baz', true);
Good
function createMenu(options: { title: string, body: string, buttonText: string, cancellable: boolean }) { // ... } createMenu({ title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true });
타입 앨리어스를 사용해서 가독성을 더 높일 수 있습니다
type MenuOptions = { title: string, body: string, buttonText: string, cancellable: boolean }; function createMenu(options: MenuOptions) { // ... } createMenu({ title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true });

함수는 한 가지만 해야합니다

이것은 소프트웨어 공학에서 단연코 가장 중요한 규칙입니다. 함수가 한 가지 이상의 역할을 수행할 때 작성하고 테스트하고 추론하기 어려워집니다. 함수를 하나의 행동으로 정의할 수 있을 때, 쉽게 리팩토링할 수 있으며 코드를 더욱 명료하게 읽을 수 있습니다. 이 가이드에서 이 부분만 자기것으로 만들어도 당신은 많은 개발자보다 앞설 수 있습니다.

Bad
function emailClients(clients: Client[]) { clients.forEach((client) => { const clientRecord = database.lookup(client); if (clientRecord.isActive()) { email(client); } }); }
Good
function emailClients(clients: Client[]) { clients.filter(isActiveClient).forEach(email); } function isActiveClient(client: Client) { const clientRecord = database.lookup(client); return clientRecord.isActive(); }

함수가 무엇을 하는지 알 수 있도록 함수 이름을 지으세요

Bad
function addToDate(date: Date, month: number): Date { // ... } const date = new Date(); // 무엇이 추가되는지 함수 이름만으로 유추하기 어렵습니다 addToDate(date, 1);
Good
function addMonthToDate(date: Date, month: number): Date { // ... } const date = new Date(); addMonthToDate(date, 1);

함수는 단일 행동을 추상화해야 합니다

함수가 한 가지 이상을 추상화한다면 그 함수는 너무 많은 일을 하게 됩니다. 재사용성과 쉬운 테스트를 위해서 함수를 쪼개세요.

Bad
function parseCode(code: string) { const REGEXES = [ /* ... */ ]; const statements = code.split(' '); const tokens = []; REGEXES.forEach((regex) => { statements.forEach((statement) => { // ... }); }); const ast = []; tokens.forEach((token) => { // lex... }); ast.forEach((node) => { // parse... }); }
Good
const REGEXES = [ /* ... */ ]; function parseCode(code: string) { const tokens = tokenize(code); const syntaxTree = parse(tokens); syntaxTree.forEach((node) => { // parse... }); } function tokenize(code: string): Token[] { const statements = code.split(' '); const tokens: Token[] = []; REGEXES.forEach((regex) => { statements.forEach((statement) => { tokens.push( /* ... */ ); }); }); return tokens; } function parse(tokens: Token[]): SyntaxTree { const syntaxTree: SyntaxTree[] = []; tokens.forEach((token) => { syntaxTree.push( /* ... */ ); }); return syntaxTree; }

중복된 코드를 제거해주세요

코드가 중복되지 않도록 최선을 다하세요. 중복된 코드는 어떤 로직을 변경할 때 한 곳 이상을 변경해야 하기 때문에 좋지 않습니다.
당신이 레스토랑을 운영하면서 재고를 추적한다고 상상해보세요: 모든 토마토, 양파, 마늘, 양념 등. 관리하는 목록이 여러개일 때 토마토를 넣은 요리를 제공할 때마다 모든 목록을 수정해야 합니다. 관리하는 목록이 단 하나일 때는 한 곳만 수정하면 됩니다!
당신은 종종 두 개 이상의 사소한 차이점이 존재한다고 생각해서 거의 비슷한 코드를 중복 작성합니다. 하지만 그 몇가지 다른 것으로 인해 같은 역할을 하는 두 개 이상의 함수를 만들게 됩니다. 중복된 코드를 제거하는 것은 조금씩 다른 역할을 하는 것을 묶음으로써 하나의 함수/모듈/클래스로 처리하는 추상화를 만드는 것을 의미합니다.
추상화를 올바르게 하는 것은 중요하며, 이것은 SOLID 원칙을 따르는 이유이기도 합니다. 올바르지 않은 추상화는 중복된 코드보다 나쁘므로 주의하세요! 좋은 추상화를 할 수 있다면 그렇게 하라는 말입니다! 반복하지 마세요. 그렇지 않으면 하나를 변경할 때마다 여러 곳을 변경하게 될 것입니다.

Bad
function showDeveloperList(developers: Developer[]) { developers.forEach((developer) => { const expectedSalary = developer.calculateExpectedSalary(); const experience = developer.getExperience(); const githubLink = developer.getGithubLink(); const data = { expectedSalary, experience, githubLink }; render(data); }); } function showManagerList(managers: Manager[]) { managers.forEach((manager) => { const expectedSalary = manager.calculateExpectedSalary(); const experience = manager.getExperience(); const portfolio = manager.getMBAProjects(); const data = { expectedSalary, experience, portfolio }; render(data); }); }
Good
class Developer { // ... getExtraDetails() { return { githubLink: this.githubLink, } } } class Manager { // ... getExtraDetails() { return { portfolio: this.portfolio, } } } function showEmployeeList(employee: Developer | Manager) { employee.forEach((employee) => { const expectedSalary = employee.calculateExpectedSalary(); const experience = employee.getExperience(); const extra = employee.getExtraDetails(); const data = { expectedSalary, experience, extra, }; render(data); }); }

당신은 중복된 코드에 대해서 비판적으로 생각해야 합니다. 가끔은 중복된 코드와 불필요한 추상화로 인한 복잡성 간의 맞바꿈이 있을 수 있습니다. 서로 다른 두 개의 모듈의 구현이 유사해 보이지만 서로 다른 도메인에 존재하는 경우, 코드 중복은 공통된 코드에서 추출해서 중복을 줄이는 것보다 나은 선택일 수 있습니다. 이 경우에 추출된 공통의 코드는 두 모듈 사이에서 간접적인 의존성이 나타나게 됩니다.

Object.assign 혹은 구조 분해를 사용해서 기본 객체를 만드세요

Bad
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean }; function createMenu(config: MenuConfig) { config.title = config.title || 'Foo'; config.body = config.body || 'Bar'; config.buttonText = config.buttonText || 'Baz'; config.cancellable = config.cancellable !== undefined ? config.cancellable : true; // ... } createMenu({ body: 'Bar' });
Good
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean }; function createMenu(config: MenuConfig) { const menuConfig = Object.assign({ title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true }, config); // ... } createMenu({ body: 'Bar' });
대안으로, 기본 값을 구조 분해를 사용해서 해결할 수 있습니다
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean }; function createMenu({ title = 'Foo', body = 'Bar', buttonText = 'Baz', cancellable = true }: MenuConfig) { // ... } createMenu({ body: 'Bar' });
사이드 이펙트와 undefined 혹은 null 값을 명시적으로 넘기는 예상치 못한 행동을 피하기 위해서 타입스크립트 컴파일러에게 그것을 허락하지 않도록 설정할 수 있습니다. 타입스크립트에서 --strictNullChecks 옵션을 확인하세요.

사이드 이펙트를 피하세요 (파트 1)

함수는 값을 가져와서 다른 값을 반환하는 것 이외에 다른 것을 할 경우 사이드 이펙트를 발생시킬 수 있습니다. 사이드 이펙트는 파일을 쓴다거나, 전역 변수를 조작한다거나, 뜻하지 않게 낯선 사람에게 당신의 전재산을 송금할 수 있습니다.
당신은 가끔 프로그램에서 사이드 이펙트를 가질 필요가 있습니다. 이전의 사례에서와 같이 당신은 파일을 써야할 때가 있습니다. 당신이 하고 싶은 것은 이것을 중앙화하는 것입니다. 특정 파일을 쓰기 위해 몇 개의 함수와 클래스를 만들지 마세요. 그것을 행하는 서비스를 단 하나만 만드세요.
중요한 것은 어떠한 구조도 없이 객체 사이에 상태를 공유하거나 어떤 것에 의해서든지 변경될 수 있는 데이터 타입을 사용하거나 사이드 이펙트가 일어나는 곳을 중앙화 하지 않는 것과 같은 위험 요소를 피하는 것입니다. 만약 그렇게 할 수 있다면, 당신은 대부분의 다른 프로그래머들보다 더욱 행복할 것입니다.

Bad
// 아래의 함수에서 참조하는 전역 변수입니다. let name = 'Robert C. Martin'; function toBase64() { name = btoa(name); } toBase64(); // 이 이름을 사용하는 다른 함수가 있다면, 그것은 Base64 값을 반환할 것입니다 console.log(name); // 'Robert C. Martin'이 출력되는 것을 예상했지만 'Um9iZXJ0IEMuIE1hcnRpbg=='가 출력됨
Good
const name = 'Robert C. Martin'; function toBase64(text: string): string { return btoa(text); } const encodedName = toBase64(name); console.log(name);

사이드 이펙트를 피하세요 (파트 2)

자바스크립트에서 원시값은 값에 의해 전달되고 객체/배열은 참조에 의해 전달됩니다. 예를 들어, 객체와 배열의 경우 어떤 함수가 쇼핑 장바구니 배열을 변경하는 기능을 가지고 있다면, 구매하려는 아이템이 추가됨으로써 cart 배열을 사용하는 다른 함수는 이 추가의 영향을 받을 수 있습니다. 이것은 장점이 될 수도 있지만 단점이 될 수도 있습니다. 최악의 상황을 상상해보겠습니다:
사용자는 네트워크 요청을 생성하고 서버에 cart 배열을 전송하는 purchase 함수를 호출하는 '구매' 버튼을 클릭합니다. 네트워크 연결 불량 때문에 purchase 함수는 요청을 재시도해야 합니다. 네트워크 요청이 시작되기 전에 사용자가 원하지 않은 아이템을 실수로 '장바구니에 추가하기' 버튼을 누르면 어떻게 될까요? 네트워크 요청이 시작되면, purchase 함수는 addItemToCart 함수가 변경한 쇼핑 장바구니 배열을 참조하고 있기 때문에 purchase 함수는 실수로 추가된 아이템을 보낼 것입니다.
훌륭한 해법은 addItemToCart 함수에서 cart 배열을 복제하고 그것을 수정하고 그 복제한 값을 반환하는 것입니다. 이는 쇼핑 장바구니 배열을 참조하고 있는 값을 들고 있는 어떤 다른 함수도 다른 변경에 의해 영향을 받지 않는 것을 보장합니다.
이 접근법에 대한 두 가지 주의사항:

실제로는 입력된 객체값을 변경하기를 원하는 경우가 있을 수 있습니다. 하지만 이러한 프로그래밍 관례를 선택할 때 당신은 이러한 경우가 매우 드물다는 것을 알게 될 것입니다. 대부분은 사이드 이펙트가 없도록 리팩토링될 수 있습니다! (Pure Function를 확인해주세요)
큰 객체를 복제하는 것은 성능 관점에서 비용이 높을 수 있습니다. 다행히도 이러한 프로그래밍 접근법을 가능하게 해주는 훌륭한 라이브러리가 있기 때문에 큰 문제는 아닙니다. 이는 수동으로 객체와 배열을 복제해주는 것만큼 메모리 집약적이지 않게 해주고 빠르게 복제해줍니다.

Bad
function addItemToCart(cart: CartItem[], item: Item): void { cart.push({ item, date: Date.now() }); };
Good
function addItemToCart(cart: CartItem[], item: Item): CartItem[] { return [...cart, { item, date: Date.now() }]; };

명령형 프로그래밍보다 함수형 프로그래밍을 지향하세요

가능하다면 이런 방식의 프로그래밍을 지향하세요.

Bad
const contributions = [ { name: 'Uncle Bobby', linesOfCode: 500 }, { name: 'Suzie Q', linesOfCode: 1500 }, { name: 'Jimmy Gosling', linesOfCode: 150 }, { name: 'Gracie Hopper', linesOfCode: 1000 } ]; let totalOutput = 0; for (let i = 0; i < contributions.length; i++) { totalOutput += contributions[i].linesOfCode; }
Good
const contributions = [ { name: 'Uncle Bobby', linesOfCode: 500 }, { name: 'Suzie Q', linesOfCode: 1500 }, { name: 'Jimmy Gosling', linesOfCode: 150 }, { name: 'Gracie Hopper', linesOfCode: 1000 } ]; const totalOutput = contributions .reduce((totalLines, output) => totalLines + output.linesOfCode, 0);

조건문을 캡슐화하세요

Bad
if (subscription.isTrial || account.balance > 0) { // ... }
Good
function canActivateService(subscription: Subscription, account: Account) { return subscription.isTrial || account.balance > 0; } if (canActivateService(subscription, account)) { // ... }

부정 조건문을 피하세요

Bad
function isEmailNotUsed(email: string): boolean { // ... } if (isEmailNotUsed(email)) { // ... }
Good
function isEmailUsed(email): boolean { // ... } if (!isEmailUsed(node)) { // ... }

타입 체킹을 피하세요

타입스크립트는 자바스크립트의 엄격한 구문적 상위 집합이며 언어에 선택적인 정적 타입 검사 기능을 추가합니다. 타입스크립트의 기능을 최대한 활용하기 위해 항상 변수의 타입, 매개변수, 반환값의 타입을 지정하도록 하세요. 그렇게 하면 리팩토링이 매우 쉬워집니다.

Bad
function travelToTexas(vehicle: Bicycle | Car) { if (vehicle instanceof Bicycle) { vehicle.pedal(currentLocation, new Location('texas')); } else if (vehicle instanceof Car) { vehicle.drive(currentLocation, new Location('texas')); } }
Good
type Vehicle = Bicycle | Car; function travelToTexas(vehicle: Vehicle) { vehicle.move(currentLocation, new Location('texas')); }

필요 이상으로 최적화하지 마세요

현대 브라우저는 런타임에서 많은 최적화를 수행합니다. 많은 시간을 최적화하는 데에 사용하고 있다면 시간 낭비입니다. 최적화가 부족한 부분을 확인할 수 있는 좋은 자료가 있습니다. 이것을 참조하여 최적화가 부족한 부분만 최적화해줄 수 있습니다.

Bad
// 예전 브라우저에서는 캐시되지 않은 `list.length`를 사용한 각 순회는 비용이 많이 들 것입니다. // `list.length`의 재계산 때문입니다. 현대 브라우저에서는 이 부분이 최적화됩니다. for (let i = 0, len = list.length; i < len; i++) { // ... }
Good
for (let i = 0; i < list.length; i++) { // ... }

필요하지 않는 코드는 제거하세요

사용하지 않은 코드는 중복된 코드만큼 나쁩니다. 당신의 코드에서 이것을 유지할 이유는 없습니다. 호출되지 않은 코드가 있다면 제거하세요! 지운 코드를 다시 확인할 필요가 있다면 버전 기록에서 볼 수 있습니다.

Bad
function oldRequestModule(url: string) { // ... } function requestModule(url: string) { // ... } const req = requestModule; inventoryTracker('apples', req, 'www.inventory-awesome.io');
Good
function requestModule(url: string) { // ... } const req = requestModule; inventoryTracker('apples', req, 'www.inventory-awesome.io');

iterator와 generator를 사용하세요

스트림과 같이 사용되는 데이터 콜렉션을 사용할 때는 generator와 iterable을 사용하세요. 몇 가지의 좋은 이유가 있습니다:

피호출자가 접근할 아이템 수를 결정한다는 의미에서 피호출자를 generator 구현으로부터 분리할 수 있습니다.
지연 실행, 아이템은 요구에 의해 스트림 처리될 수 있습니다.
for-of 구문을 사용해 아이템을 순회하는 내장 지원이 있습니다.
iterable은 최적화된 iterator 패턴을 구현할 수 있습니다.
Bad
function fibonacci(n: number): number[] { if (n === 1) return [0]; if (n === 2) return [0, 1]; const items: number[] = [0, 1]; while (items.length < n) { items.push(items[items.length - 2] + items[items.length - 1]); } return items; } function print(n: number) { fibonacci(n).forEach(fib => console.log(fib)); } // 피보나치 숫자의 첫 번째 10개 숫자를 출력합니다. print(10);
Good
// 피보나치 숫자의 무한 스트림을 생성합니다. // `generator`는 모든 숫자의 배열을 유지하고 있지 않습니다. function* fibonacci(): IterableIterator<number> { let [a, b] = [0, 1]; while (true) { yield a; [a, b] = [b, a + b]; } } function print(n: number) { let i = 0; for (const fib of fibonacci()) { if (i++ === n) break; console.log(fib); } } // 피보나치 숫자의 첫 번째 10개 숫자를 출력합니다. print(10);
map, slice, forEach 등과 같은 메소드를 연결함으로써 네이티브 배열을 비슷한 방법으로 iterable로 작업할 수 있게 하는 라이브러리가 있습니다. iterable의 발전된 조작의 사례를 위해 itiriri를 확인해주세요. (또는 비동기 iterable의 조작을 위해서 itiriri-async를 확인해주세요.)
import itiriri from 'itiriri'; function* fibonacci(): IterableIterator<number> { let [a, b] = [0, 1]; while (true) { yield a; [a, b] = [b, a + b]; } } itiriri(fibonacci()) .take(10) .forEach(fib => console.log(fib));

객체와 자료구조

타입 vs 인터페이스

합집합 또는 교집합이 필요할 때 타입을 사용하세요. extends 또는 implements가 필요할 때 인터페이스를 사용하세요. 엄격한 규칙은 없지만 당신에게 맞는 방법을 사용하세요.
타입스크립트에서 type과 interface 사이의 다른 점에 대해서 더 상세한 설명을 원한다면 이 답변을 참고하세요.

Bad
interface EmailConfig { // ... } interface DbConfig { // ... } interface Config { // ... } //... type Shape = { // ... }
Good
type EmailConfig = { // ... } type DbConfig = { // ... } type Config = EmailConfig | DbConfig; // ... interface Shape { // ... } class Circle implements Shape { // ... } class Square implements Shape { // ... }

클래스

클래스는 작아야 합니다

클래스의 크기는 책임에 의해 측정됩니다. 단일 책임 원칙에 따르면 클래스는 작아야 합니다.

Bad
class Dashboard { getLanguage(): string { /* ... */ } setLanguage(language: string): void { /* ... */ } showProgress(): void { /* ... */ } hideProgress(): void { /* ... */ } isDirty(): boolean { /* ... */ } disable(): void { /* ... */ } enable(): void { /* ... */ } addSubscription(subscription: Subscription): void { /* ... */ } removeSubscription(subscription: Subscription): void { /* ... */ } addUser(user: User): void { /* ... */ } removeUser(user: User): void { /* ... */ } goToHomePage(): void { /* ... */ } updateProfile(details: UserDetails): void { /* ... */ } getVersion(): string { /* ... */ } // ... }
Good
class Dashboard { disable(): void { /* ... */ } enable(): void { /* ... */ } getVersion(): string { /* ... */ } } // 다른 클래스에 남은 메소드를 이동시킴으로써 책임을 분산시키세요 // ...

높은 응집도와 낮은 결합도

응집도는 클래스 멤버가 서로에게 연관되어 있는 정도를 정의합니다. 이상적으로, 클래스 안의 모든 필드는 각 메소드에 의해 사용되어야 합니다. 그 때 우리는 클래스가 최대한으로 응집되어있다라고 말합니다. 이것은 항상 가능하지도 않고 권장하지 않습니다. 그러나 응집도를 높이는 것을 선호해야 합니다.
결합도는 두 클래스가 얼마나 서로에게 관련되어있거나 종속적인 정도를 뜻합니다. 하나의 클래스의 변경이 다른 클래스에게 영향을 주지 않는다면 그 클래스들의 결합도는 낮다고 말합니다.
좋은 소프트웨어 설계는 높은 응집도와 낮은 결합도를 가집니다.

Bad
class UserManager { // Bad: 각 private 변수는 메소드의 하나 혹은 또 다른 그룹에 의해 사용됩니다. // 클래스가 단일 책임 이상의 책임을 가지고 있다는 명백한 증거입니다. // 사용자의 트랜잭션을 얻기 위해 서비스를 생성하기만 하면 되는 경우, // 여전히 `emailSender` 인스턴스를 전달해야 합니다. constructor( private readonly db: Database, private readonly emailSender: EmailSender) { } async getUser(id: number): Promise<User> { return await db.users.findOne({ id }); } async getTransactions(userId: number): Promise<Transaction[]> { return await db.transactions.find({ userId }); } async sendGreeting(): Promise<void> { await emailSender.send('Welcome!'); } async sendNotification(text: string): Promise<void> { await emailSender.send(text); } async sendNewsletter(): Promise<void> { // ... } }
Good
class UserService { constructor(private readonly db: Database) { } async getUser(id: number): Promise<User> { return await this.db.users.findOne({ id }); } async getTransactions(userId: number): Promise<Transaction[]> { return await this.db.transactions.find({ userId }); } } class UserNotifier { constructor(private readonly emailSender: EmailSender) { } async sendGreeting(): Promise<void> { await this.emailSender.send('Welcome!'); } async sendNotification(text: string): Promise<void> { await this.emailSender.send(text); } async sendNewsletter(): Promise<void> { // ... } }

상속(inheritance)보다 조합(composition)을 사용하세요

Gang of Four의 디자인 패턴에 나와있듯이 할 수 있는 대로 상속보다 조합을 사용해야 합니다. 상속과 조합을 사용해야 하는 좋은 이유들은 각각 많습니다. 이 교훈에서 중요한 점은 당신의 마음이 본능적으로 상속을 추구한다면, 조합이 당신의 문제를 더 좋게 해결할 수 있을지 고민해보라는 것입니다. 어떤 경우에는 더 좋을 수 있습니다.
당신은 '언제 상속을 사용해야 할까요?' 라고 의문점을 가질 것입니다. 그것은 당면한 문제에 달려 있습니다. 조합보다 상속이 더 좋은 경우가 아래에 있습니다:

'has-a' 관계가 아닌 'is-a' 관계일 때 (사람->동물 vs 사용자->사용자 정보)
기반이 되는 클래스로부터 코드를 재사용할 수 있을 때 (사람은 모든 동물처럼 움직일 수 있습니다.)
기반이 되는 클래스를 변경하여 파생된 클래스를 전체적으로 변경하려는 경우 (모든 동물은 움직일 때 칼로리가 소비됩니다.)

Bad
class Employee { constructor( private readonly name: string, private readonly email: string) { } // ... } // `Employee`가 세금 데이터를 가지기 때문에 나쁜 에입니다. `EmployeeTaxData`는 `Employee`의 타입이 아닙니다. class EmployeeTaxData extends Employee { constructor( name: string, email: string, private readonly ssn: string, private readonly salary: number) { super(name, email); } // ... }
Good
class Employee { private taxData: EmployeeTaxData; constructor( private readonly name: string, private readonly email: string) { } setTaxData(ssn: string, salary: number): Employee { this.taxData = new EmployeeTaxData(ssn, salary); return this; } // ... } class EmployeeTaxData { constructor( public readonly ssn: string, public readonly salary: number) { } // ... }

메소드 체이닝을 사용하세요

이 패턴은 매우 유용하고 많은 라이브러리에서 공통적으로 사용하고 있습니다. 이것은 당신의 코드를 표현력이 있게 해주고 덜 장황하게 해줍니다. 이러한 이유로 메소드 체이닝을 사용해서 당신의 코드가 얼마나 명료해지는지 살펴보시길 바랍니다.

Bad
class QueryBuilder { private collection: string; private pageNumber: number = 1; private itemsPerPage: number = 100; private orderByFields: string[] = []; from(collection: string): void { this.collection = collection; } page(number: number, itemsPerPage: number = 100): void { this.pageNumber = number; this.itemsPerPage = itemsPerPage; } orderBy(...fields: string[]): void { this.orderByFields = fields; } build(): Query { // ... } } // ... const queryBuilder = new QueryBuilder(); queryBuilder.from('users'); queryBuilder.page(1, 100); queryBuilder.orderBy('firstName', 'lastName'); const query = queryBuilder.build();
Good
class QueryBuilder { private collection: string; private pageNumber: number = 1; private itemsPerPage: number = 100; private orderByFields: string[] = []; from(collection: string): this { this.collection = collection; return this; } page(number: number, itemsPerPage: number = 100): this { this.pageNumber = number; this.itemsPerPage = itemsPerPage; return this; } orderBy(...fields: string[]): this { this.orderByFields = fields; return this; } build(): Query { // ... } } // ... const query = new QueryBuilder() .from('users') .page(1, 100) .orderBy('firstName', 'lastName') .build();

인터페이스 & 타입

인터페이스 (Interface)

PascalCase를 사용합니다.
I를 접두어로 사용하지 않습니다.

이전에는 인터페이스 변수 앞에 I를 붙이는 경우가 많았는데 현재는 비관습적인 이유로 사용하지 않습니다.

// Bad
interface IFoo {
}

// Good
interface Foo {
}

타입 (Type)

PascalCase를 사용합니다.
멤버는 camelCase를 사용합니다.

// Bad
type car {
  ModelInfo: string;
}

// Good
type Car {
  modelInfo: string;
}

Type vs Interface

Union이나 Intersection이 필요할 때 Type을 사용합니다.

type Foo = number | { someProperty: number }

extends 또는 implements를 사용하고 싶을 때는 Interface를 사용합니다.

interface Foo {
  foo: string;
}

interface FooBar extends Foo {
  bar: string;
}

class X implements FooBar {
  foo: string;
  bar: string;
}

네임스페이스 & ENUM

네임스페이스 (namespace)

PascalCase를 사용합니다.

타입스크립트 팀에서 정한 약속입니다.
네임스페이스들은 정적멤버를 갖는 클래스, 클래스 이름도 PascalCase를 사용하기 때문에 동일하게 사용합니다.

// Bad
namespace foo {
}

// Good
namespace Foo {
}

enum

PascalCase를 사용합니다.
enum의 멤버에는 PascalCase를 사용합니다.

타입스크립트 팀에서 정한 약속입니다.

// Bad
enum color {
  red
}

// Good
enum Color {
  Red
}

명확하지 않은 변수 타입

any vs unknown

unknown 타입을 사용합니다.
any, unknown 타입 모두 아무때나 사용할 수 있지만 unknown 타입은 사용하는 쪽에서 방어처리를 해서 안전하게 사용이 가능합니다.
any 타입은 타입스크립트를 쓰는 의미가 없게 되버릴 수 있습니다.

const prettyPrint: string = (x: unknown) => {
  if (Array.isArray(x)) {
    return '[' + x.map(prettyPrint).join(', ') + ']'
  }
  if (typeof x === 'string') {
    return `'${x}'`
  }
  if (typeof x === 'number') {
    return String(x)
  } 
  return 'etc.'
}

x를 any로 했을 경우 map(), join()을 사용할 수 있는데 unknown일 때 x가 배열인 경우에만 map(), join()을 사용할 수 있도록 강제해줍니다.

null vs undefined

명백히 값이 없을 때에도 사용하지 않도록 합니다.
타입스크립트에서 type으로 구조를 암시할 수 있도록 합니다.

// Bad
let foo = { x: 123, y: undefined }

// Good
let foo = { x: number, y?: number } = { x: 123 }

일반적으로 undefined를 사용합니다.

return undefined

null이나 undefined 값을 갖는 객체는 truthy하게 검사합니다.

// Bad
if (error === null)

// Good
if (error)

null이나 undefined를 체크할 때 === 혹은 !==를 사용하지 않고 == 혹은 !=를 사용합니다.

null이나 undefined에는 작동하지만 다른 fasly 값들 ('', 0, false)에는 작동하지 않습니다.

// Bad
if (error !== null)

// Good
if (error != null)

SOLID

단일 책임 원칙 (SRP)

클린 코드에서 말하듯이, '클래스를 변경할 때는 단 한 가지 이유만 존재해야 합니다'. 여행갈 때 가방 하나에 많은 것을 챙기는 것과 같이, 클래스를 많은 기능으로 꽉 채우고 싶은 유혹이 있습니다. 이러한 문제는 당신의 클래스가 개념적으로 응집력이 있지 않으며 변경될 많은 이유가 존재한다는 것을 말합니다. 클래스를 변경하는 많은 시간을 줄이는 것은 중요합니다. 왜냐하면 너무 많은 기능이 한 클래스에 있고 그 안에서 하나의 기능을 수정한다면, 다른 종속된 모듈에 어떻게 영향을 줄지 이해하는 것이 어렵기 때문입니다.

Bad
class UserSettings { constructor(private readonly user: User) { } changeSettings(settings: UserSettings) { if (this.verifyCredentials()) { // ... } } verifyCredentials() { // ... } }
Good
class UserAuth { constructor(private readonly user: User) { } verifyCredentials() { // ... } } class UserSettings { private readonly auth: UserAuth; constructor(private readonly user: User) { this.auth = new UserAuth(user); } changeSettings(settings: UserSettings) { if (this.auth.verifyCredentials()) { // ... } } }

개방 폐쇄 원칙 (OCP)

Bertrand Meyer가 말했듯이, '소프트웨어 엔터티(클래스, 모듈, 함수 등)는 상속에 개방되어 있습니다. 하지만 수정에는 폐쇄되어 있습니다.' 이것이 무엇을 의미할까요? 이 원칙은 기본적으로 기존의 코드를 변경하지 않고 새로운 기능을 추가할 수 있도록 하는 것을 명시합니다.

Bad
class AjaxAdapter extends Adapter { constructor() { super(); } // ... } class NodeAdapter extends Adapter { constructor() { super(); } // ... } class HttpRequester { constructor(private readonly adapter: Adapter) { } async fetch<T>(url: string): Promise<T> { if (this.adapter instanceof AjaxAdapter) { const response = await makeAjaxCall<T>(url); // response 값을 변경하고 반환합니다. } else if (this.adapter instanceof NodeAdapter) { const response = await makeHttpCall<T>(url); // response 값을 변경하고 반환합니다. } } } function makeAjaxCall<T>(url: string): Promise<T> { // 서버에 요청하고 프로미스를 반환합니다. } function makeHttpCall<T>(url: string): Promise<T> { // 서버에 요청하고 프로미스를 반환합니다. }
Good
abstract class Adapter { abstract async request<T>(url: string): Promise<T>; // 하위 클래스와 공유하는 코드 ... } class AjaxAdapter extends Adapter { constructor() { super(); } async request<T>(url: string): Promise<T>{ // 서버에 요청하고 프로미스를 반환합니다. } // ... } class NodeAdapter extends Adapter { constructor() { super(); } async request<T>(url: string): Promise<T>{ // 서버에 요청하고 프로미스를 반환합니다. } // ... } class HttpRequester { constructor(private readonly adapter: Adapter) { } async fetch<T>(url: string): Promise<T> { const response = await this.adapter.request<T>(url); // response 값을 변경하고 반환합니다. } }

리스코프 치환 원칙 (LSP)

매우 단순한 개념을 뜻하는 어려워보이는 용어입니다. '만약 S가 T의 하위 타입이라면, T 타입의 객체는 S 타입의 객체로 대체될 수 있습니다. (예: S 타입 객체는 T 타입 객체로 치환될 수도 있습니다.) 이는 프로그램이 갖추어야할 속성(정확성, 수행되는 작업 등)을 변경하지 않아도 대체될 수 있습니다.' 더욱 어려워보이는 정의입니다.
이를 위한 최고의 설명은 다음과 같습니다. 만약 부모 클래스와 자식 클래스가 있다면, 부모 클래스와 자식 클래스는 잘못된 결과 없이 서로 교환하여 사용될 수 있습니다. 여전히 혼란스러울 수 있습니다. 고전적인 정사각형-직사각형 예제를 살펴보세요. 수학적으로, 정사각형은 직사각형입니다. 그러나 상속을 통해 'is-a' 관계로 설계한다면, 당신은 곤경에 빠질 수 있습니다.

Bad
class Rectangle { constructor( protected width: number = 0, protected height: number = 0) { } setColor(color: string): this { // ... } render(area: number) { // ... } setWidth(width: number): this { this.width = width; return this; } setHeight(height: number): this { this.height = height; return this; } getArea(): number { return this.width * this.height; } } class Square extends Rectangle { setWidth(width: number): this { this.width = width; this.height = width; return this; } setHeight(height: number): this { this.width = height; this.height = height; return this; } } function renderLargeRectangles(rectangles: Rectangle[]) { rectangles.forEach((rectangle) => { const area = rectangle .setWidth(4) .setHeight(5) .getArea(); // BAD: `Square` 클래스에서는 25를 반환합니다. 20이 반환되어야 합니다. rectangle.render(area); }); } const rectangles = [new Rectangle(), new Rectangle(), new Square()]; renderLargeRectangles(rectangles);
Good
abstract class Shape { setColor(color: string): this { // ... } render(area: number) { // ... } abstract getArea(): number; } class Rectangle extends Shape { constructor( private readonly width = 0, private readonly height = 0) { super(); } getArea(): number { return this.width * this.height; } } class Square extends Shape { constructor(private readonly length: number) { super(); } getArea(): number { return this.length * this.length; } } function renderLargeShapes(shapes: Shape[]) { shapes.forEach((shape) => { const area = shape.getArea(); shape.render(area); }); } const shapes = [new Rectangle(4, 5), new Rectangle(4, 5), new Square(5)]; renderLargeShapes(shapes);

인터페이스 분리 원칙 (ISP)

인터페이스 분리 원칙은 '클라이언트는 사용하지 않는 인터페이스에 의존하지 않는다' 라는 것입니다. 이 원칙은 단일 책임 원칙과 많은 관련이 있습니다. 이 말의 뜻은 클라이언트가 노출된 메소드를 사용하는 대신에 전체 파이를 얻지 않는 방식으로 추상화를 설계해야 한다는 것입니다. 그것은 또한 클라이언트에게 클라이언트가 실제로 필요하지 않은 메소드의 구현을 강요하는 것도 포함합니다.

Bad
interface SmartPrinter { print(); fax(); scan(); } class AllInOnePrinter implements SmartPrinter { print() { // ... } fax() { // ... } scan() { // ... } } class EconomicPrinter implements SmartPrinter { print() { // ... } fax() { throw new Error('Fax not supported.'); } scan() { throw new Error('Scan not supported.'); } }
Good
interface Printer { print(); } interface Fax { fax(); } interface Scanner { scan(); } class AllInOnePrinter implements Printer, Fax, Scanner { print() { // ... } fax() { // ... } scan() { // ... } } class EconomicPrinter implements Printer { print() { // ... } }

의존성 역전 원칙 (DIP)

이 원칙은 두 가지 필수적인 사항을 명시합니다:

상위 레벨의 모듈은 하위 레벨의 모듈에 의존하지 않아야 합니다. 두 모듈은 모두 추상화에 의존해야합니다.
추상화는 세부사항에 의존하지 않아야 합니다. 세부사항은 추상화에 의존해야 합니다.

처음에 바로 이해하기는 어려울 수 있습니다. Angular를 사용해봤다면, 의존성 주입(DI)의 형태 안에서 이 원칙의 구현을 확인해봤을 것입니다. 동일한 개념은 아니지만, DIP는 상위 레벨의 모듈이 하위 레벨의 모듈의 세부사항에 접근하고 설정하지 못하도록 지킵니다. DI를 통해서도 마찬가지로 성취할 수 있습니다. 이것의 큰 장점은 모듈 사이의 결합도를 줄일 수 있다는 것입니다. 결합도는 코드를 리팩토링하기 어렵게 하기 때문에 매우 나쁜 개발 패턴입니다.
DIP는 주로 IoC 컨테이너를 사용함으로써 달성됩니다. 타입스크립트를 위한 강력한 IoC 컨테이너의 예제는 InversifyJs입니다.

Bad
import { readFile as readFileCb } from 'fs'; import { promisify } from 'util'; const readFile = promisify(readFileCb); type ReportData = { // .. } class XmlFormatter { parse<T>(content: string): T { // XML 문자열을 T 객체로 변환 } } class ReportReader { // BAD: 특정 요청의 구현에 의존하는 것을 만들었습니다. // `parse` 메소드에 의존하는 `ReportReader`를 만들어야 합니다. private readonly formatter = new XmlFormatter(); async read(path: string): Promise<ReportData> { const text = await readFile(path, 'UTF8'); return this.formatter.parse<ReportData>(text); } } // ... const reader = new ReportReader(); await report = await reader.read('report.xml');
Good
import { readFile as readFileCb } from 'fs'; import { promisify } from 'util'; const readFile = promisify(readFileCb); type ReportData = { // .. } interface Formatter { parse<T>(content: string): T; } class XmlFormatter implements Formatter { parse<T>(content: string): T { // XML 문자열을 T 객체로 변환 } } class JsonFormatter implements Formatter { parse<T>(content: string): T { // JSON 문자열을 T 객체로 변환 } } class ReportReader { constructor(private readonly formatter: Formatter) { } async read(path: string): Promise<ReportData> { const text = await readFile(path, 'UTF8'); return this.formatter.parse<ReportData>(text); } } // ... const reader = new ReportReader(new XmlFormatter()); await report = await reader.read('report.xml'); // 또는 json 보고서가 필요한 경우 const reader = new ReportReader(new JsonFormatter()); await report = await reader.read('report.json');

TEST

개요

테스트는 배포보다 중요합니다. 테스트가 없거나 부족한 경우, 코드를 배포할 때마다 당신은 어떤 것이 작동하지 않을지 확실하지 않을 것입니다. 적절한 양의 테스트를 구성하는 것은 당신의 팀에게 달려있지만, (모든 문장과 브랜치에서) 100%의 커버리지를 가진다면 매우 높은 자신감과 마음의 평화를 얻을 것입니다. 이는 훌륭한 테스트 프레임워크뿐만 아니라, 좋은 커버리지 도구를 사용해야 한다는 것을 의미합니다.
테스트를 작성하지 않을 이유는 없습니다. 타입스크립트의 타입을 지원하는 많은 양의 좋은 자바스크립트 테스트 프레임워크가 있으므로 당신의 팀이 선호하는 것을 찾아 사용하세요. 당신의 팀에 적합한 테스트 프레임워크를 찾았다면, 당신이 만드는 모든 새로운 기능/모듈을 위한 테스트를 항상 작성하는 것을 목표로 하세요. 테스트 기반 개발(TDD)이 당신이 선호하는 방법이라면, 매우 좋습니다. 하지만 중요한 건 어떤 기능을 만들거나 기존의 것을 리팩토링하기 전에 목표하는 커버리지를 달성하는 것입니다.

TDD의 세 가지 법칙

실패하는 단위 테스트를 작성하기 전에는 실제 코드를 작성하지 마세요.
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성하세요.
실패하는 단위 테스트를 통과할 정도로만 실제 코드를 작성하세요.

F.I.R.S.T 규칙

명료한 테스트는 다음 규칙을 따라야 합니다:

Fast 테스트는 빈번하게 실행되므로 빨라야 합니다.
Independent 테스트는 서로 종속적이지 않습니다. 독립적으로 실행하든지 순서 상관없이 모두 실행하든지 동일한 결과가 나와야 합니다.
Repeatable 테스트는 어떤 환경에서든 반복될 수 있습니다. 테스트가 실패하는데에 이유가 없어야 합니다.
Self-Validating 테스트는 통과 혹은 실패로 답해야 합니다. 테스트가 통과되었다면 로그 파일을 보며 비교할 필요는 없습니다.
Timely 단위 테스트는 실제 코드를 작성하기 전에 작성해야 합니다. 실제 코드를 작성한 후에 테스트를 작성한다면, 테스트를 작성하는 것이 너무 고단하게 느껴질 것입니다.

테스트 하나에 하나의 개념을 작성하세요

또한, 테스트는 단일 책임 원칙을 따라야 합니다. 단위 테스트 하나당 하나의 assert 구문을 작성하세요.

Bad
import { assert } from 'chai'; describe('AwesomeDate', () => { it('handles date boundaries', () => { let date: AwesomeDate; date = new AwesomeDate('1/1/2015'); assert.equal('1/31/2015', date.addDays(30)); date = new AwesomeDate('2/1/2016'); assert.equal('2/29/2016', date.addDays(28)); date = new AwesomeDate('2/1/2015'); assert.equal('3/1/2015', date.addDays(28)); }); });
Good
import { assert } from 'chai'; describe('AwesomeDate', () => { it('handles 30-day months', () => { const date = new AwesomeDate('1/1/2015'); assert.equal('1/31/2015', date.addDays(30)); }); it('handles leap year', () => { const date = new AwesomeDate('2/1/2016'); assert.equal('2/29/2016', date.addDays(28)); }); it('handles non-leap year', () => { const date = new AwesomeDate('2/1/2015'); assert.equal('3/1/2015', date.addDays(28)); }); });

테스트의 이름은 테스트의 의도가 드러나야 합니다

테스트가 실패할 때, 테스트의 이름은 어떤 것이 잘못되었는지 볼 수 있는 첫 번째 표시입니다.

Bad
describe('Calendar', () => { it('2/29/2020', () => { // ... }); it('throws', () => { // ... }); });
Good
describe('Calendar', () => { it('should handle leap year', () => { // ... }); it('should throw when format is invalid', () => { // ... }); });

동시성

프로미스 vs 콜백

콜백은 명료하지 않고, 지나친 양의 중첩된 콜백 지옥을 유발할 수 있습니다.
콜백 방식을 사용하고 있는 기존의 함수를 프로미스를 반환하는 함수로 변환시켜주는 유틸리티 라이브러리가 있습니다. (Node.js를 사용한다면 util.promisify를 확인해주세요. 일반적인 목적이라면 pify, es6-promisify를 확인해주세요.)

Bad
import { get } from 'request'; import { writeFile } from 'fs'; function downloadPage(url: string, saveTo: string, callback: (error: Error, content?: string) => void) { get(url, (error, response) => { if (error) { callback(error); } else { writeFile(saveTo, response.body, (error) => { if (error) { callback(error); } else { callback(null, response.body); } }); } }); } downloadPage('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', 'article.html', (error, content) => { if (error) { console.error(error); } else { console.log(content); } });
Good
import { get } from 'request'; import { writeFile } from 'fs'; import { promisify } from 'util'; const write = promisify(writeFile); function downloadPage(url: string, saveTo: string): Promise { return get(url) .then(response => write(saveTo, response)); } downloadPage('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', 'article.html') .then(content => console.log(content)) .catch(error => console.error(error));

프로미스는 코드를 더욱 간결하게 해주는 몇몇의 헬퍼 메소드를 지원합니다:패턴설명

Promise.resolve(value)	해결(resolve)된 프로미스로 값을 변환함.
Promise.reject(error)	거부(reject)된 프로미스로 에러를 변환함.
Promise.all(promises)	전달된 모든 프로미스가 이행한 값의 배열을 이행하는 새 프로미스 객체를 반환하거나 거부된 첫 번째 프로미스의 이유로 거부함.
Promise.race(promises)	전달된 프로미스의 배열에서 가장 먼저 완료된 결과/에러로 이행/거부된 새 프로미스 객체를 반환함.

Promise.all는 병렬적으로 작업을 수행할 필요가 있을 때 유용합니다. Promise.race는 프로미스를 위한 타임아웃과 같은 것을 구현하는 것을 쉽게 할 수 있도록 도와줍니다.

프로미스보다 async/await가 더 명료합니다

async/await 구문을 사용하면 연결된 프로미스 구문보다 훨씬 더 명료하고 이해하기 쉬운 코드를 작성할 수 있습니다. async키워드가 앞에 붙여진 함수는 await 키워드에서 코드의 실행을 멈춘다는 것을 자바스크립트 런타임에게 알려줍니다.

Bad
import { get } from 'request'; import { writeFile } from 'fs'; import { promisify } from 'util'; const write = util.promisify(writeFile); function downloadPage(url: string, saveTo: string): Promise { return get(url).then(response => write(saveTo, response)); } downloadPage('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', 'article.html') .then(content => console.log(content)) .catch(error => console.error(error));
Good
import { get } from 'request'; import { writeFile } from 'fs'; import { promisify } from 'util'; const write = promisify(writeFile); async function downloadPage(url: string, saveTo: string): Promise { const response = await get(url); await write(saveTo, response); return response; } // somewhere in an async function try { const content = await downloadPage('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', 'article.html'); console.log(content); } catch (error) { console.error(error); }

에러처리

개요

에러를 던지는 것은 좋은 것입니다! 에러를 던진다는 것은 런타임이 당신의 프로그램에서 뭔가 잘못되었을 때 식별하고 현재 스택에서 함수 실행을 멈추고, (노드에서) 프로세스를 종료하며, 스택 트레이스를 콘솔에 보여줌으로써 당신에게 해당 에러를 알려주는 것을 의미합니다.

catch 절에서 에러 처리 부분을 비워두지 마세요

catch 절에서 단지 에러를 받는 것만으로는 해당 에러에 대응할 수 없습니다. 또한, 콘솔에 에러를 기록하는 것(console.log)은 콘솔에 출력된 많은 것들 사이에서 발견되지 못할 수 있기 때문에 그다지 좋은 선택은 아닙니다. 당신이 어떤 코드를 try/catch로 감쌌다면, 그 코드에서 에러가 일어날 수 있으며, 즉 에러가 발생했을 때에 대한 계획이나 장치가 있어야 한다는 것을 의미합니다.

Bad
try { functionThatMightThrow(); } catch (error) { console.log(error); } // 아래 예제는 훨씬 나쁩니다. try { functionThatMightThrow(); } catch (error) { // 에러를 무시 }
Good
import { logger } from './logging' try { functionThatMightThrow(); } catch (error) { logger.log(error); }

요청이 거부된 프로미스 객체를 무시하지 마세요

위와 같이 try/catch 절에서 받은 에러 처리 부분을 비워두면 안됩니다.

Bad
getUser() .then((user: User) => { return sendEmail(user.email, 'Welcome!'); }) .catch((error) => { console.log(error); });
Good
import { logger } from './logging' getUser() .then((user: User) => { return sendEmail(user.email, 'Welcome!'); }) .catch((error) => { logger.log(error); }); // 또는 async/await 구문을 사용할 수 있습니다: try { const user = await getUser(); await sendEmail(user.email, 'Welcome!'); } catch (error) { logger.log(error); }

서식

개요

서식은 주관적입니다. 여기에 있는 많은 규칙들과 같이 당신이 따르기 어려운 규칙은 없습니다. 중요한 점은 서식에 대해서 논쟁하지 않는 것입니다. 서식을 자동화하기 위한 도구들이 매우 많습니다. 그 중 하나를 사용하세요! 서식에 대해 논쟁하는 것은 엔지니어에게 시간과 돈 낭비일 뿐입니다. 따라야하는 일반적인 규칙은 일관적인 서식 규칙을 지켜야하는 것입니다.
TSLint라고 불리는 타입스크립트를 위한 강력한 도구가 있습니다. 이것은 코드의 가독성과 유지보수성을 극적으로 개선시키도록 도와주는 정적 분석 도구입니다. 프로젝트에 참고할 수 있는 TSLint 설정을 사용할 준비가 되었습니다:

TSLint Config Standard - 표준 스타일 규칙
TSLint Config Airbnb - 에어비엔비 스타일 가이드
TSLint Clean Code - Clean Code: A Handbook of Agile Software Craftsmanship에 영감 받은 TSLint 규칙
TSLint react - React & JSX와 관련된 lint 규칙
TSLint + Prettier - Prettier 코드 포맷터를 위한 lint 규칙
ESLint rules for TSLint - 타입스크립트를 위한 ESLint 규칙
Immutable - 타입스크립트에서 변경을 허락하지 않는 규칙

또한, 훌륭한 자료인 타입스크립트 스타일 가이드와 코딩 컨벤션을 참고해주세요.

TSLint는 deprecated되었습니다. Roadmap: TSLint -> ESLint 이슈를 확인해주세요.

일관적으로 대소문자를 사용하세요

대소문자를 구분하여 작성하는 것은 당신에게 변수, 함수 등에 대해서 많은 것을 알려줍니다. 이 규칙은 주관적이어서, 당신의 팀이 원하는 것을 선택해야 합니다. 중요한 점은 어떤 걸 선택하였든지 간에 일관적이어야 한다는 것입니다.

Bad
const DAYS_IN_WEEK = 7; const daysInMonth = 30; const songs = ['Back In Black', 'Stairway to Heaven', 'Hey Jude']; const Artists = ['ACDC', 'Led Zeppelin', 'The Beatles']; function eraseDatabase() {} function restore_database() {} type animal = { /* ... */ } type Container = { /* ... */ }
Good
const DAYS_IN_WEEK = 7; const DAYS_IN_MONTH = 30; const SONGS = ['Back In Black', 'Stairway to Heaven', 'Hey Jude']; const ARTISTS = ['ACDC', 'Led Zeppelin', 'The Beatles']; function eraseDatabase() {} function restoreDatabase() {} type Animal = { /* ... */ } type Container = { /* ... */ }
클래스, 인터페이스, 타입 그리고 네임스페이스 이름에는 PascalCase를 사용하세요.
변수, 함수 그리고 클래스 멤버 이름에는 camelCase를 사용하세요.

import 구문을 특정 순서대로 정리하세요(ESLint)

import 구문을 읽기 쉽고 명료하게 하면 당신은 현재 코드의 의존성을 빠르게 확인할 수 있습니다. 다음과 같은 import 구문 정리를 위한 좋은 방법들을 적용해보세요:

import 구문은 알파벳 순서대로 배열하고 그룹화해야 합니다.
사용하지 않은 import 구문은 제거되어야 합니다.
이름이 있는 import 구문은 알파벳 순서대로 배열해야 합니다. (예: import {A, B, C} from 'foo';)
import 하는 소스코드는 그룹 내에서 알파벳 순서대로 배열해야 합니다. (예: import as foo from 'a'; import as bar from 'b';)
import 구문의 그룹은 빈 줄로 구분되어야 합니다.
그룹은 다음 순서를 준수해야 합니다:
- 폴리필 (예: import 'reflect-metadata';)
- Node 내장 모듈 (예: import fs from 'fs';)
- 외부 모듈 (예: import { query } from 'itiriri';)
- 내부 모듈 (예: import { UserService } from 'src/services/userService';)
- 상위 디렉토리에서 불러오는 모듈 (예: import foo from '../foo'; import qux from '../../foo/qux';)
- 동일한 계층의 디렉토리에서 불러오는 모듈 (예: import bar from './bar'; import baz from './bar/baz';)
Bad
import { TypeDefinition } from '../types/typeDefinition'; import { AttributeTypes } from '../model/attribute'; import { ApiCredentials, Adapters } from './common/api/authorization'; import fs from 'fs'; import { ConfigPlugin } from './plugins/config/configPlugin'; import { BindingScopeEnum, Container } from 'inversify'; import 'reflect-metadata';
Good
import 'reflect-metadata'; import fs from 'fs'; import { BindingScopeEnum, Container } from 'inversify'; import { AttributeTypes } from '../model/attribute'; import { TypeDefinition } from '../types/typeDefinition'; import { ApiCredentials, Adapters } from './common/api/authorization'; import { ConfigPlugin } from './plugins/config/configPlugin';

타입스크립트 앨리어스를 사용하세요

tsconfig.json의 compilerOptions 섹션 안에서 paths와 baseUrl 속성을 정의해 더 보기 좋은 import 구문을 작성해주세요.
이 방법은 import 구문을 사용할 때 긴 상대경로를 작성하는 것을 피하게 도와줄 것입니다.

Bad
import { UserService } from '../../../services/UserService';

Good

// tsconfig.json
...
  'compilerOptions': {
    ...
    'baseUrl': 'src',
    'paths': {
      '@services': ['services/*']
    }
    ...
  }
...

import { UserService } from '@services/UserService';

주석

당신의 코드를 주석 처리하지 마세요

버전 관리 시스템이 존재하는 이유입니다. 사용하지 않는 코드는 기록에 남기세요.

Bad
type User = { name: string; email: string; // age: number; // jobPosition: string; }
Good
type User = { name: string; email: string; }

일기 같은 주석을 달지 마세요

버전 관리 시스템을 사용하세요! 죽은 코드, 주석 처리된 코드, 특히 일기 같은 주석은 필요 없습니다. 대신에 기록을 보기 위해 git log 명령어를 사용하세요!

Bad
/** * 2016-12-20: 이해하지 못해서 모나드를 제거함 (RM) * 2016-10-01: 특별한 모나드를 사용해 개선함 (JP) * 2016-02-03: 타입 체킹 추가함 (LI) * 2015-03-14: combine 함수를 구현함 (JR) */ function combine(a: number, b: number): number { return a + b; }
Good
function combine(a: number, b: number): number { return a + b; }

코드의 위치를 설명하는 주석을 사용하지 마세요

이건 보통 코드를 어지럽히기만 합니다. 함수와 변수 이름을 적절한 들여쓰기와 서식으로 당신의 코드에 시각적인 구조가 보이도록 하세요.
대부분의 IDE(통합 개발 환경)에서는 코드 블록을 접기/펼치기 할 수 있는 기능을 지원합니다.

Bad
//////////////////////////////////////////////////////////////////////////////// // Client 클래스 //////////////////////////////////////////////////////////////////////////////// class Client { id: number; name: string; address: Address; contact: Contact; //////////////////////////////////////////////////////////////////////////////// // public 메소드 //////////////////////////////////////////////////////////////////////////////// public describe(): string { // ... } //////////////////////////////////////////////////////////////////////////////// // private 메소드 //////////////////////////////////////////////////////////////////////////////// private describeAddress(): string { // ... } private describeContact(): string { // ... } };
Good
class Client { id: number; name: string; address: Address; contact: Contact; public describe(): string { // ... } private describeAddress(): string { // ... } private describeContact(): string { // ... } };

TODO 주석

추후에 개선을 위해 코드에 메모를 남겨야할 때, // TODO 주석을 사용하세요. 대부분의 IDE는 이런 종류의 주석을 특별하게 지원하기 때문에 해야할 일 목록을 빠르게 검토할 수 있습니다.
하지만 TODO 주석이 나쁜 코드를 작성할 이유는 아니라는 것을 명심하세요.

Bad
function getActiveSubscriptions(): Promise<Subscription[]> { // ensure `dueDate` is indexed. return db.subscriptions.find({ dueDate: { $lte: new Date() } }); }
Good
function getActiveSubscriptions(): Promise<Subscription[]> { // TODO: ensure `dueDate` is indexed. return db.subscriptions.find({ dueDate: { $lte: new Date() } }); }

참고

https://google.github.io/styleguide/tsguide.html

https://google.github.io/styleguide/tsguide.html#source-file-basics

https://paullabworkspace.notion.site/8a6058561b924c0c95eb3933e480b367

https://radlohead.gitbook.io/typescript-deep-dive/styleguide

https://techblog.woowahan.com/9804/

https://738.github.io/clean-code-typescript/

https://github.com/tipjs/javascript-style-guide

https://velog.io/@cada/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%BD%94%EB%94%A9-%EB%B0%8F-%EB%84%A4%EC%9D%B4%EB%B0%8D-%EC%BB%A8%EB%B2%A4%EC%85%98-1%ED%8E%B8

SQL Conventions

그레고리오78 — Mon, 16 Mar 2026 18:35:20 +0900

1.개요

본 가이드는 개발 단계에서 개발표준과 최적화에 고려해야 할 사항에 초점을 맞추어 내용을 기술 하였습니다.기준이 되는 데이터베이스는 MySQL로 제한하였으나 명명규칙등 일반적인 사항은 데이터베이스 시스템에 종속 되지 않으므로 본 가이드를 적용할 수 있습니다.본 문서는 아래와 같은 구조로 되어 있습니다.

2. SQL 공통 표준

2.1. SQL 명명규칙(Naming Convention)

2.1.1. ID 길이

원칙
- ID의 길이는 18바이트를 넘지 않도록 작성한다.
- 지나치게 짧은 ID는 원래 의미를 상실하기 쉬우며 가독성을 떨어뜨린다.
설명
- 각 DBMS별로 최대허용길이가 다르지만 공통으로 사용할 수 있는 길이는 18바이트이다.
- 길이가 길 경우 DBMS간의 이식성을 떨어뜨리게 된다.

2.1.2. ID 구성문자

원칙
- 알파벳과 숫자, 밑줄(underscore)외의 특수문자는 사용하지 않는다.
- 밑줄(underscore)는 연속으로 사용하지 않는다.
- ID을 명명할 때 모음을 지나치게 생략하지 않는다.
설명
- 특수문자가 들어간 ID는 가독성이 떨어진다.
- 밑줄문자(underscore)을 연속으로 사용하면 해당 코드를 읽을 때 밑줄문자가 몇 개 사용되었는지 인식하기 힘들다.

2.1.3. 대소문자 사용규칙

원칙
- 대소문자 사용원칙을 정했으면 일관성 있게 고수한다. (대문자 권장)
설명
- 대소문자 구분여부는 DBMS마다 다르다.

2.1.4. 국제 명명규칙 표준 준수

원칙
- 국제 명명규칙 표준(ISO-11179)을 준수할 것
- 국가명이나 국가코드에 대한 명명은 ISO-3166 표준을 따른다.
- 날짜 표기에 대한 형식은 ISO-8601 표준을 따른다.
- 단, 아무리 우수한 국제 표준이라도 레거시 시스템에서 관습적으로 사용하는 것을 우선하여 적용한다.
설명
- SQL과 연관된 ISO-11179
  - SQL과 연관된 ISO-11179 표준 도메인은 11179-4으로, 데이터 요소 중 스칼라(Scalar) 타입은 아래와 같은 원칙을 준수한다.
  - 국가명이나 국가코드 표준에 대한 자료는 아래를 참고한다.
  - http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm
  - 아무리 우수한 국제표준 명명규칙이라도 관행으로 굳어졌거나 관습적으로 사용하는 것 보다 우선하여 사용하지 못한다.

2.1.5. 서술적인 접두어(prefix)의 사용 자제

서술적인 접두어(prefix)는 SQL문을 읽거나 분석할 때 도움이 되지 않는 경우가 많으며 오히려 그 반대의 경우가 더 많다.

원칙
- ~~테이블 ID는 “tbl_” 등으로 시작하지 않는다.~~
- ~~컬럼ID는 해당 컬럼의 소속을 나타내기 위해 테이블ID을 접두어를 붙이지 않는다.~~
- ~~뷰(view) ID는 “vw_” 등으로 시작하지 않는다.~~
- 특정컬럼이 primary key 또는 foreign key임을 나타내기 위해 해당 컬럼의 ID을 “pk_” 또는 “pf_” 등으로 시작하지 않도록 한다.
- 특정 ID가 제약사항(constraint)임을 나타내기 위해 다음과 같은 형식의 명명규칙을 사용하지 않도록 한다.
- <table_id>_CK_<column_id>
- 트리거(trigger) ID는 “trig_” 로 시작하지 않도록 한다.
- 저장프로시저 ID는 user-defined-procedure임을 나타내기 위해 “usp_” 로 시작하지 않는다.
- 트리거 또는 저장프로시저의 ID는 <동사><목적어> 형태로 명명한다.
설명
- 각 ID을 명명할 때 해당 ID의 소속, 형식을 표현하기 위해 접두어를 붙일 경우 해당 ID의 소속 또는 형식이 바뀌면 ID자체를 변경해야 할 경우가 있는데, 이렇게 되면 일관성을 잃어버리게 된다.

2.1.6. 표준 접미어(postfix)를 지정

ID의 주체가 되는 오브젝트의 형식을 나타내는 접두어(prefix) 대신 해당 오브젝트의 속성을 나타내는 접미어(postfix)을 지정하여 사용하는 것이 낫다.
(데이터베이스 명명규칙 참조)

2.1.7. 테이블, 뷰(view)의 이름

원칙
- 집합적이면서도 대표적인 이름 또는 복수형을 사용할 것
  - 단, 1개의 row만을 유지해야 하는 테이블의 경우는 예외로 한다.
- 산업표준을 따른다.

2.1.8. 별칭(alias)

원칙
- 별칭(alias)을 사용할 때 근본이 되는 원래의 이름과 동떨어진 이름은 사용하지 않는다.
설명
- 별칭(alias, 상관관계에 의해 파생되는 이름)도 하나의 이름이며 그것의 존재 원인이 되는 근원 테이블, 컬럼 또는 수식 등이 있게 마련이다. 별칭을 사용할 때 원래의 이름과 동떨어진 이름은 유지보수가 매우 어렵게 만들게 되므로 배제하는 것이 좋으나 지엽적으로 사용할 경우는 간략한 형태로 축약하여 사용하는 것을 허용한다.

2.1.9. 관계성이 함축된 이름

원칙
- 테이블 또는 뷰간의 관계가 서로 엮일 때, 이로 인해 파생되는 엔터티에 대해 가능하면 관계성을 표현할 수 있는 이름을 사용한다.
설명
- 아래와 같이 두 개 엔터티가 관계가 함축된 엔터티의 이름은 관계성을 함축하는 이름을 사용한다.
  - ‘남자’와 ‘여자’ 엔터티가 결합된 경우
  - 나쁜 예 : ManWoman 또는 HusbandsWives
  - 좋은 예 : Marriage
  - ‘학생’과 ‘과목’ 엔터티가 결합된 경우
  - 나쁜 예 : StudentsCourses
  - 좋은 예 : Enrollments

2.1.10. 메타데이터 성격을 가진 이름

원칙
- 스키마 등에서 메타데이터 성격을 가진 오브젝트에 한해서 구조체를 나타내는 접미사를 사용할 수 있다. 예를 들면 인덱스ID의 경우 “_ix” 의 접미사를 사용한다.

2.1.11. 데이터 요소 명명 시 피해야 할 사항

원칙
- 애매한 이름은 사용하지 말 것
- 상반적인 개념의 수식어가 결합된 ID는 사용하지 말 것
- 상황에 따라 변동이 될 수 있는 ID는 사용하지 말 것
- 물리모델에서 사용하는 용어(대부분 DBMS에 종속적인 용어)는 논리모델에서 사용하지 말 것
설명
- 너무 일반적인 이름은 포괄적이어서 아무런 정보를 전달하지 못하는 경우가 많다.
  - 예 : amount, date, id
- 객체지향 프로그래밍이 몸에 밴 개발자의 경우 모든 필드에 “_id” 라는 접미사를 붙이려는 경향이 있는데, 실제 상황에서 의미가 없는 경우가 많다.
- 논리모델에서 다음과 같은 용어는 물리모델로 전환하는 단계에서 예약어로 사용되는 경우가 많으므로 피해야 한다.
  - 예 : IDENTITY, GUID, ROWID 등

2.1.12. 대소문자 사용

원칙
- 컬럼ID, 파라미터, 변수는 소문자로 작성한다.
- 위의 경우를 제외하고, 스키마(schema)에서 나오는 오브젝트의 첫 글자는 대문자로 작성한다.
- 예약어(reserved word)는 모두 대문자로 작성한다.
- Camel-Case는 사용하지 않는다.
설명
- 예약어를 대문자로 작성하는 이유는 특별히 유의해서 보게 하려는 의도를 담고 있기 때문이다.
- Camel-Case은 기존의 Hungarian notation에 익숙한 개발자를 위한 것인데(ID를 구성하는 단어의 첫 글자만 대문자로 사용하는 표기법), 실제로는 가독성(readability)를 떨어뜨리는 요인이 된다.

2.2. SQL 코딩규칙(Coding Convention)

여기서는 SQL 코딩 시 가독성 향상을 위해 지켜야 할 문자, 문장의 배치 등 외형을 중심으로 기술하였습니다.

2.2.1. 공백(space)사용

원칙
- SQL코딩 시 가급적 탭을 사용하지 말고 공백문자(space)을 사용할 것
- SQL코드의 토큰 좌우에 공백을 사용할 것
설명
- 개발자마다 선호하는 TAB-SIZE가 다르기 때문에, SQL 코드 작성시 탭(TAB)을 사용하면 실제 코드가 가독성이 떨어질 수 있다.
- 실제 예는 아래와 같다.
  - 나쁜 예 : foobar=21
  - 좋은 예 : foobar = 21

2.2.2. 줄 간격

원칙
- 한 문장 내에서는 한 줄씩만 띄어쓰기를 할 것
- 하나의 프로세스 내에서의 각 문장은 두 줄씩 띄어쓰기를 할 것

2.2.3. 들여쓰기(indentation)

원칙
- SQL을 사용할 때 한 그룹 내에서는 ‘4-space rule’을 사용할 수 도 있다. (들여쓰기는 공백 3개로 통일한다.)
- 서브쿼리(sub-query)에서는 괄호를 시작과 끝의 위치를 일치시킨다.
설명
- SQL에서의 수직 맞춤 배치는 기존의 3GL 프로그래밍과 달리 공백을 이용한 인덴테이션 보다 우선 순위가 높다.
- 서브쿼리(sub-query)에서는 괄호를 시작과 끝의 위치를 일치시키면 서브쿼리의 영역을 쉽게 파악할 수 있는 이점이 있다.

2.2.4. 일반적인 마침법의 준수

원칙
- 콤마 뒤에 공백을 집어 넣을 것
- 콤마로 분리된 ID가 여러 줄에 걸쳐 나올 때, 콤마를 라인 끝이 아닌 라인의 처음에 위치시킬 것
- 세미콜론으로 끝나는 SQL문의 마지막은 New-Line 이나 최소한 공백을 집어 넣을 것
설명
- SQL 문을 읽을 때 콤마와 마침표를 구분하기 힘들 경우가 많으므로 다음의 예와 같이 콤마 뒤에는 공백을 집어 넣는다.
- 나쁜 예
```
SELECT flobs.a,flobs.b,flobs.c,fleq.d
  FROM Flobs,Foobar,Fleq;
```
- 좋은 예
```
SELECT flobs.a, flobs.b, flobs.c, fleq.d
  FROM Flobs, Foobar, Fleq;
```
- 콤마로 분리된 ID가 여러 줄에 걸쳐 쓰여지면, 다음 예와 같이 콤마를 라인의 처음에 위치시키는 것이 보기에도 좋고 추후 SQL을 수정하기에도 수월하다.
```
SELECT flobs.a,
       flobs.b,
       flobs.c,
       fleq.d
  FROM Flobs,
       Fleq
```

2.2.5. 예약어(Reserved Word) 사용

원칙
- 예약어는 단축형이 아닌 Full-Name을 사용할 것
- 특정 DBMS에 종속적인 예약어 대신 표준 예약어를 사용할 것
설명
- 데이터 타입을 제외하고는 되도록이면 예약어는 생략하지 말고 Full-Name을 사용하는 것이 좋다. 예를 들면 “FROM”절에 “Personnel P1” 대신 “Personnel AS P1” 으로 사용하면 좋다.
- 특정 DBMS에 종속적인 예약어를 사용하면 이식성이 떨어진다.

2.2.6. SQL 수직 배치

SQL문장이 여러 줄에 걸쳐 기술되어 있을 경우, 좌우로 지그재그형태로 생긴 모양은 최대한 배제하고, 다음을 원칙으로 한다.

원칙
- SELECT(T), UPDATE(E), FROM(M), WHERE(E), AND(D), OR(R), ORDER BY(R), GROUP BY(P)의 끝 문자를 다음 SQL문의 끝 문자(SELECT(T), UPDATE(E), INSERT(T), DELETE(E))와 맞춘다.
- INSERT 및 VALUES는 동일한 위치에서 시작한다.
- 모든 컬럼은 동일한 위치에서 시작한다. (단, 컬럼 앞에 함수가 나오면 함수명의 첫 글자를 기준으로 맞춤)
- SELECT(T), UPDATE(E), INSERT(T), DELETE(E) 뒤로 바로 컬럼명이 나올 경우 다음 줄에서 앞 줄의 첫 단어의 끝(INSERT(T), UPDATGE(E), INSERT(T), DELETE(E))으로 부터 한 칸을 띄고 작성한다.
- SELECT, UPDATE, INSERT, DELETE 문의 컬럼 목록은 첫 컬럼만 제외하고 앞에 콤마(,)로 시작한다.
- INSERT 문의 경우 VALUE 절의 값들도 첫 번째 값을 제외하고 모두 콤마로 시작하되 동일한 위치로 정렬한다.
- FROM 절의 인-라인 뷰를 제외한 일반 테이블들은 콤마(,)로 구분하되 한 줄에 연속하여 기술하고 한 줄을 초과하는 경우, 줄을 바꾸어 윗줄의 첫 테이블 이름에 맞추어 시작한다.
- 인-라인 뷰의 내부의 SQL문은 시작괄호 ‘(‘ 바로 다음부터 시작하되, 위의 내용과 동일한 규칙을 적용하며 인-라인 뷰가 끝나면 괄호를 닫은 후 줄을 바꾸도록 한다.
- SQL 문의 마지막에 “;” 을 기술하여 해당 문의 끝을 표시한다.
- UPDATE 문에서 SET절의 컬럼들은 첫 컬럼만 제외하고 콤마(,)로 시작한다.

설명

일반적인 SQL 문 배치 예시
일반적인 수직배치

SELECT DISTINCT pilot
  FROM PilotSkills AS PS1
 WHERE NOT EXISTS (
        SELECT *
          FROM Hangar
         WHERE NOT EXISTS (
                SELECT *
                  FROM PilotSkills AS PS2
                 WHERE PS1.pilot = PS2.pilot
                   AND P2.plane = Hangar.plane
                )
       )
;

SELECT 문의 작성 예시

-- 예시 (2) : 주석(comment)을 SELECT 예약어 바로 다음에 배치한 예
SELECT col1,
       col2, /* Comment */
       col3
  FROM TB_SAMPLE
 WHERE col1 = 123
GROUP BY col2
HAVING SUM(col3) > 1000
ORDER BY SUM(col3)
;

-- 예시 (3): 중첩된 SQL문장의 수직배치 예
SELECT col1,
       col2, /* Comment */
       col3,
       col4,
       col5 /* Comment */
  FROM (
        SELECT col1,
               col2,
               col3
          FROM TB_SAMPLE1
         WHERE col1 BETWEEN 100 AND 200
       ) a,
       TB_SAMPLE2 b
 WHERE a.col1 = b.col1
   AND b.col2 IN (
        SELECT col1
          FROM TB_SAMPLE3
         WHERE col2 = ‘123’)
   AND b.col3 LIKE ‘A%’
;

-- 예시 (4) CASE문을 동반한 수직배치의 예
SELECT col1,
       col2,
       col3,
       CASE WHEN col4 = 'AAA' THEN col5 * 1.05
            WHEN col4 LIKE '%BB' THEN col5 * 1.1
            WHEN col4 IN ('CCC', 'DDD') THEN col5 * 1.2
            ELSE col5 * 1.3
       END AS 인상급여
  FROM TB_SAMPLE
;

-- 예시 (5): 왼쪽 괄호가 동반된 수직배치의 예
SELECT deptno
  FROM BIG_DEPT d
 WHERE NOT EXISTS (
        SELECT deptno
          FROM BIG_EMP e
         WHERE e.deptno = d.deptno
       )
;

-- 예시 (6): UNION을 동반한 수직배치의 예
SELECT deptno
  FROM BIG_DEPT d
UNION ALL
SELECT deptno
  FROM BIG_EMP e
;

-- 예시 (1) : SELECT 예약어의 ‘T’을 기준으로 수직배치를 한 예 SELECT col1, col2, /* Comment */ col3, CASE WHEN col4 = 1 THEN col4 ELSE col4,col4 / 100 END as col4, col5 /* Comment */ FROM TB_SAMPLE a WHERE col1 = 123 AND col2 like ‘A%’ AND col3 in (‘A’, ‘B’, ‘C’) ;
UPDATE 문의 작성 예시
-- 예시 (1): UPDATE 예약어의 ‘E’을 기준으로 수직배치를 한 예 UPDATE TB_SAMPLE SET col1 = 123, col2 = ‘ABC’, col3 = TO_CHAR(9936) WHERE col4 = 123 AND col5 LIKE ‘A%’ AND col6 IN (‘A’, ‘B’, ‘C’) ;

INSERT 문 작성예문

-- 예시 (2): INSERT의 VALUE 내용을 SELECT을 사용하여 처리한 예
INSERT INTO TB_SAMPLE1 (
       col1,
       col2
)
SELECT col3, /* col1 */
       col4 /* col2 */
  FROM TB_SAMPLE2
;

-- 예시 (1): INSERT 예약어의 ‘T’을 기준으로 수직배치를 한 예 INSERT INTO TB_SAMPLE ( col1, col2, col3, col4 ) VALUES ( '111', '222', '333', '444' );
o DELETE 문 작성예문
-- 예시 (1) : DELETE 예약어의 끝 문자(‘E’)을 기준으로 수직배치를 한 예 DELETE FROM TB_SAMPLE WHERE col1 = 123 AND col2 LIKE 'A%' AND col3 IN ('A', 'B', 'C') ;

2.2.7. 주석(comment) 사용

원칙
- SELECT, UPDATE, INSERT, DELETE 문에서 컬럼목록 다음에 반드시 주석(/* */)을 사용하여 프로그램ID을 기술한다.
- 원칙적으로 힌트(HINT)을 사용하는 것은 금지하지만, 불가피하게 힌트(HINT)을 사용할 경우에는 SQL문의 첫 번째 SELECT, UPDATE, INSERT, DELETE 다음에 반드시 동일한 줄에 프로그램 ID 를 /* / 을 이용하여 기술하며, /+ */ 을 이용하고 프로그램ID을 먼저 기술하고 힌트를 기술한다.

3. SQL 작성 표준

3.1. SQL 작성시 기본적인 지침

3.1.1. 표준기능의 사용

제품특성과 연관된 기능보다 표준 기능을 사용 할 것.

3.1.1.1. OUTER JOIN 표기법 (권장)

조회 시 특정 DBMS에 종속된 SQL을 사용하는 예는 바람직하지 않으며 이식에 문제를 발생시키게 된다. (위 사항은 권장 사항임)

3.1.1.2. ISO표준 기간 표기법

ISO-8601 표준 표기법인 “YYYY-MM-DD hh:mm:ss.sssss” 을 사용할 것

3.1.2. 간결한 표기법을 사용

3.1.2.1. 필요 없는 괄호의 사용

다음과 같이 불필요한 괄호는 사용하지 않는 것이 좋다.

SELECT a, b, c
  FROM Foobar
 WHERE (a = b)
   AND (c < 42)
;

3.1.2.2. CASE 문 사용시 주의 사항

CASE문은 엄밀하게 말하면 문장(statement)이 아니라 수식(expression)이기 때문에 반드시 하나의 값을 반환한다는 것에 유의할 것(만약 조건 중 만족하는 것이 없으면 묵시적으로 “ELSE NULL” 이 추가된다.
명시적으로 NULL을 반환할 때는 “CAST (NULL AS <datatype>)” 형태를 사용할 것
CASE문을 쓸 때 “<CASE operand>” 대신에 Searched CASE 수식을 사용할 것
o 바람직하지 않은 예
CASE iso_sex_code WHEN 0 THEN 'Unknown' WHEN 1 THEN 'Male' WHEN 2 THEN 'Female' WHEN 9 THEN 'N/A' ELSE NULL END
o 바람직한 예
CASE WHEN iso_sex_code = 0 THEN 'Unknown' WHEN iso_sex_code = 1 THEN 'Male' WHEN iso_sex_code = 2 THEN 'Female' WHEN iso_sex_code = 9 THEN 'N/A' ELSE NULL END
o 예외상황
- NULL 여부와 비교하는 경우는 다음과 같이 SQL을 작성하면 에러가 발생하므로 주의해야 한다.
```
CASE WHEN foo = 0 THEN ‘bar’
     WHEN foo = NULL THEN ‘no_bar’ /* error !!! */
     ELSE NULL
END
```
가능하다면 COALESCE 또는 NULLIF 을 사용하여 SQL을 깔끔하게 작성한다.
- (COALESCE, NULLIF 모두 SQL-92 표준이다)

3.1.2.3. 불필요한 비교문

다음과 같이 불필요한 비교문은 사용하지 않는다.

SELECT a, b, c
  FROM Foobar
 WHERE a = b
   AND b = c
   AND c = a
;

3.1.2.4. 수식을 간소화하여 사용

간소한 수식 예(1)
- 나쁜 예
```
SELECT a, b, c
  FROM Foobar
 WHERE a + 2 = b - 4
;
```
- 아래와 같이 작성하면 읽기에도 어려울 뿐 아니라, a 컬럼이 인덱스로 구성되어 있어도 인덱스를 활용할 수 없게 되는 경우가 있다.
- 좋은 예
- SELECT a, b, c FROM Foobar WHERE a = b – 6 ;
간소한 수식 예(2)
- 구간에 대한 조건을 AND을 사용하여 표현하는 것보다 BETWEEN을 활용하는 것이 좋다.
- (단, 인덱스를 활용할 수 있는지 여부를 먼저 고려해서 사용할 것)
간소한 수식 예(3)
- 여러 개의 값과 비교할 때 OR을 사용하여 표현하는 것보다 IN을 활용하는 것이 좋다.
중첩되어 복잡한 조건절은 CASE 수식을 사용하여 간략하게 한다.

3.1.3. 주석 사용시 주의사항

가능하면 “--“ 보다는 /* */ 을 활용하는 것이 좋다. (경우에 따라 Unary Operator인 -‘와 혼동이 되는 경우가 있기 때문이다)
Stored-Procedure 및 Function 에서의 주석
- 항상 Stored-Procedure는 첫 줄에 최소한 다음의 사항을 주석으로 표현한다. 단, 프로시저 이름은 “<동사><목적어>” 형태로 기술하는 것이 좋다.
  - SP 및 Function 명 및 목적/기능 설명
  - Input Param 명 및 설명
  - Output Param 명 및 설명
  - 변경 이력(작성일자, 이름 - 변경 내용)
  - 복잡한 제어문에는 항상 주석을 사용할 것
  - /* =========================================================================================== Name : fnConvertIntToIPv4 Desc : 정수(INT UNSIGNED)를 IPv4 주소 문자열로 변환 Params - intIPv4 : 정수로 변환된 IPv4 Return - VARCHAR : IPv4 주소 문자열 Used : fnConvertIntToIPv4(3232235777) → '192.168.1.1' History - 2025.04.09, 이명근 - 최초 구현 =========================================================================================== */

3.1.4. 옵티마이저用 힌트(Hint)의 사용자제

옵티마이저用 힌트는 DBMS에 따라 표기법이 달라서 호환이 되지 않는 경우가 많으므로 사용하지 않는 것이 좋다.
DBMS의 옵티마이저는 대부분의 개발자보다 더 적은 비용의 전략을 잘 찾아낸다.
힌트를 사용할 일이 없어지거나 인덱스가 변경되면 성능이 더 떨어지는 경우가 많다.

3.1.5. 복잡한 데이터 처리 시 SQL Stored Procedure 사용 권장

업무 처리 로직이 복잡한 데이터 처리(예: 데이터 조회 후 임시 테이블 생성하여 입력/수정/삭제 후 Target Table에 데이터 입력/수정/삭제 로직)인 경우 Stored Procedure 사용한다.Stored Procedure을 사용하면 다음과 같은 장점이 있다.

보안성 강화
- Stored Procedure을 사용하면 해당 프로시저 내부에서 허용되는 작업만 진행하게 되므로 동적SQL(Dynamic SQL)을 사용할 때보다 훨씬 안전하다. (동적 SQL을 사용하면 SQL내용을 통제할 수 있는 방법이 없다)
유지보수 용이
- Stored Procedure는 손쉽게 수정하여 업그레이드할 수 있다. (새로 DBMS에 수정하는 순간 re-compile된다)
네트워크 트래픽 감소
- 네트워크상에서 파라미터 값만 전송되므로 네트워크 전송 효율이 좋아진다.
일관성
- SQL을 모두 Stored-Procedure로만 작성하게 되면 일관성이 생기므로 추후 작업에도 생산성이 높아진다.
모듈성
- 다른 Stored-Procedure에서도 해당 프로시저를 호출하여 사용할 수 있으므로 모듈화에 적합하다.

3.1.6. UNION은 사용 자제

아직도 대부분 옵티마이저는 UNION을 최적화하는데 어려움을 겪고 있다. 따라서 가능하다면 UNION ALL 만을 사용하고 나머지는 사용하지 않는 것이 좋다.

3.1.7. 정렬과 관련된 SQL문의 남용 금지

다음과 같이 Sort 가 발생하는 SQL 문은 최대한 자제한다.

ORDER BY
GROUP BY
DISTINCT

3.1.8. WHERE 절에 긍정적 조건의 사용

비교하고자 하는 컬럼이 숫자 타입이 확실한 경우를 제외하고 비교 하고자 하는 상수 값을 숫자 타입으로 하지 않는다.
”OR” 사용을 자제하고 가급적 IN, CASE 함수를 활용한다.
IFNULL 함수는 불필요하게 사용하지 않는다.
WHERE 절의 인덱스 스캔 컬럼에 인위적인 변형을 가하지 말고 반드시 상수(변수) 쪽에 변형을 가한다.
데이터를 검색할 때 불필요한 부분은 액세스하지 말고 읽어야 하는 부분만 처리하여 효율을 높인다. ( SELECT 문에서 ‘*’을 사용하지 말고 Named Column을 사용한다. )
불필요한 Network 접근을 줄이기 위해 가능하면 SQL을 최대한 묶어서 사용한다.

3.2. SQL 작성시 기본적인 절차

3.2.1. SQL 테스트

가능한 NULL과 관련된 모든 경우의 수를 테스트할 것
CHECK() 제약사항을 모두 검사하고 테스트할 것
테이블의 크기가 커질 경우를 테스트할 것

3.2.2. SQL 수행비용 검증

개발자는 작성된 SQL 문에 대한 실행계획을 검증하는 절차를 거친다.

3.2.3. OLAP 성격의 업무 개발시 주의사항

OLTP 성격의 업무에서 아래와 같은 SQL 문에 대해서는 반드시 해당 SQL문의 개선 작업을 수행한다.

Full Table Scan
Index Fast Full Scan
Sort Merge Join

4. SQL 작성 지침

4.1. DDL(Data Definition Language) 작성 지침

4.1.1. Default 값은 데이터 타입과 일치하는 값을 사용

당연한 말이지만, 의외로 많은 개발자가 이 원칙을 지키지 않는다. 예를 들면

Decimal 데이터 타입에 정수 0(zero)을 default 값으로 사용하는 경우
(CHAR(n) 데이터 타입에 길이가 n개 보다 적은 문자 스트링을 default 값으로 사용하는 경우
TIMESTAMPE 데이터 타입에 DATE 값을 default 로 사용하는 경우

위의 경우 같은 경우 DBMS에서 원래 데이터 타입에 맞게 묵시적인 변환작업이 일어나는데, DBMS성능에 영향을 미치는 요인이 될 수 있다.

4.1.2. Data Type 중 문자 타입은 일관성을 유지

char 대신 varchar 을 사용할 것
인덱스로 지정될 가능성이 높은 컬럼은 varchar로 지정하여 사용할 것

4.1.3. 테이블 생성시 주키(Primary Key)를 가장 위에 배치

가독성을 높이기 위해 키에 해당되는 속성은 가장 위에 위치시키는 것이 좋다. 왜냐하면 키라는 의미 자체가 해당 엔터티의 대표값을 나타내기 때문이다.

4.1.4. 컬럼을 논리적인 순서로 배열 및 논리적인 그룹 지정

단, 스키마가 완성된 이후에 컬럼을 추가할 때 성능에 영향을 미치는지 고려해야 하는데, 다음 순서대로 컬럼을 배치하면 성능에 도움이 된다.

업데이트가 적게 일어나는 고정길이 컬럼
업데이트가 적게 일어나는 가변길이 컬럼
업데이트가 자주 일어나는 컬럼(들)
- 업데이트가 동시에 일어나는 성격의 컬럼이 연속되게 배치하면 좋음

4.1.5. 제약조건 이름은 명확하게 기술

제약조건은 ”CONSTRAINT <name>” 형태로 기술하는데, 제약조건 명을 기술하지 않으면 에러 상황이 발생하였을 때 시스템에서 정한 임의의 이름으로 에러메시지가 발생하므로 오류를 찾기 어렵게 되므로 제약조건의 이름은 명확하게 기술한다. 단, PRIMARY KEYS, UNIQUE, FOREIGN KEY 제약 조건에 대한 이름은 생략한다.

4.1.6. 수치형 컬럼은 범위 제약사항을 두도록 고려

데이터베이스는 기업에서 유일하게 신뢰할 수 있는 “저장소”이므로, 비즈니스 룰을 강제할 수 있는 방편으로 제약사항을 두게 된다. 대개는 테이블의 필드가 0(zero)보다 크도록 제약사항을 두는 경우가 많다.

4.1.7. 가능하면 모든 테이블이 키를 갖도록 설계

키와 관련하여 주의할 사항은 아래와 같다.

자동 채번 컬럼은 관계성 키가 아니다.
파일은 테이블이 아니다.
“좋은 키”의 속성을 살펴 볼 것
- 유일성(Uniqueness)
- 안정성(Stability)
  - 쉽게 변하지 않는 값이어야 한다.
- 친밀성(Familiarity)
- 검증성(Validation)
  - 사용자 입장에서 검증하기 용이해야 한다.
- 확인성(Verifiability)
  - 개발자 입장에서 확인하기 용이해야 한다.
- 단순성(Simplicity)

4.2. DML(Data Manipulation Language) 작성 지침

4.2.1. NULL 사용 지침

NULL을 꼭 사용해야 할 경우 비교 연산자가 아닌 'IS' 또는 'IS NOT'을 사용한다.
- 좋은 예
- IF (@var IS NOT NULL) IF (@var IS NULL)
- 나쁜 예
- IF (@var = NULL) IF (@var <> NULL) IF (@var != NULL) IF (@var > NULL )
인덱스 비교 부분에서 NULL을 사용하지 않는다.
- 좋은 예
- SELECT ord_no, ord_date, item, ord_qty FROM ORDER1T WHERE ord_date > ' ' ;
- 나쁜 예
- SELECT ord_no, ord_date, item, ord_qty FROM ORDER1T WHERE ord_date IS NOT NULL ORDER BY ord_date ;

4.2.2. IN 사용 지침

WHERE 조건에서 ‘OR’을 최대한 배제하고 IN 을 사용한다.
- 좋은 예
- SELECT emp_name FROM Employees WHERE emp_id IN (1, 2, 5) ;
- 나쁜 예
- SELECT emp_name FROM Employees WHERE ((emp_id = 1) OR (empidn = 2) OR (empidn = 5)) ;
'BETWEEN'을 사용하면 Range Scan을 수행하고, 'IN'을 사용하면 Point SCAN을 수행하므로 IN을 사용하는 것이 더 효율적이다.
- 좋은 예
- SELECT col3, col4, col5 FROM TAB1 WHERE col1 = 'A' AND col2 IN ('112', '111') ;
- 나쁜 예
- SELECT col3, col4, col5 FROM TAB1 WHERE col1 = 'A' AND col2 BETWEEN '111' AND '112' ;
UNION은 가능하면 IN으로 대체한다.
- 좋은 예
- SELECT DISTINCT useid, usetypid FROM JOIN_USER_USERTYPS WHERE usetypid IN (16, 17) ;
- 나쁜 예
- SELECT DISTINCT useid, usetypid FROM JOIN_USER_USERTYPES WHERE (usetypid = 16) UNION ALL SELECT DISTINCT useid, usetypid FROM JOIN_USER_USERTYPES WHERE (usetypid = 17) ;

4.2.3. MIN, MAX 사용 지침

최대값(또는 최소값)만 필요한 경우 ORDER BY 대신 MAX(또는 MIN) 함수를 사용한다.
- 좋은 예
- SELECT MAX(emp_id) FROM Employees ;
- 나쁜 예
- SELECT emp_id FROM Employees ORDER BY empi_d DESC ;

4.2.4. UNION, UNION ALL 사용 지침

아래와 같이 UNION ALL 구문을 활용한다.
- 좋은 예
- SELECT fname, lname, empidn FROM Employees WHERE (empidn < 10) UNION ALL SELECT fname, lname, empidn FROM Employees WHERE (empidn >= 100) ;
- 나쁜 예
- SELECT fname, lname, empidn FROM Employees WHERE (empidn < 10) UNION SELECT fname, lname, empidn FROM Employees WHERE (empidn >= 100) ;
OR 대신 아래와 같이 UNION ALL 을 활용한다.
- 좋은 예
- SELECT COUNT(*) FROM Chujgo WHERE :sw = 1 AND chuldate = '20020628' UNION ALL SELECT COUNT(*) FROM Chulgo WHERE :sw = 2 AND RTRIM(chuldate) LIKE '200206%' ;
- 나쁜 예
- SELECT COUNT(*) FROM Chulgo WHERE (:sw = 1 AND chuldate = ‘20020628’) OR (:sw = 2 AND RTRIM(chuldate) LIKE ‘200206%’) ;

4.2.5. OR 사용시 주의사항

조건문 안에 OR을 사용하면 TABLE FULL SCAN을 하게 되므로 주의해야 한다.
- 좋은 예
- SELECT chulno, custno, chuldate, uncost FROM Chulgo WHERE (:sw = 1 AND (status LIKE ‘1%’) OR (:sw = 1 AND (status LIKE ‘2%’) OR (:sw = 2 AND (status LIKE ‘3%’) ORDER BY status ;
- 나쁜 예
- SELECT chulno, custno, chuldate, uncost FROM Chulgo WHERE (:sw = 1 AND (status LIKE ‘1%’ OR status LIKE ‘2%’)) OR (:sw = 2 AND (status LIKE ‘3%’)) ORDER BY status ;

4.2.6. 부정형 사용 금지 원칙

WHERE절에 부정형을 사용하면 인덱스 스캔이 불가능하므로 긍정형으로 변형하여 사용한다.
- 좋은 예
- SELECT 'Not found' INTO :col1 FROM DUAL WHERE NOT EXISTS ( SELECT 'x' FROM EMP WHERE empno = ‘1234’ ) ;
- 나쁜 예
- SELECT 'Not found' INTO :COL1 FROM EMP WHERE empno <> '1234' ;

4.2.7. NVL 활용 원칙

총계함수 사용 시 NULL은 무시되므로 총계함수 내에서의 IFNULL함수는 필요하지 않음
- 좋은 예
- IFNULL(SUM(trn_amount), 0)
- 나쁜 예
- IFNULL(SUM(IFNULL(trn_amount, 0)), 0)

4.2.8. OUTER JOIN 활용 방안

두 개의 테이블 중 한 쪽에만 값이 있는 경우를 추출할 경우 OUTER JOIN을 활용한다.
- 좋은 예
- SELECT d.deptno FROM BIG_DEPT d LEFT OUTER JOIN BIG_EMP e ON (d.deptno = e.deptno AND e.deptno IS NULL) ;
- 나쁜 예
- SELECT deptno FROM BIG_DEPT d WHERE NOT EXISTS ( SELECT deptno FROM BIG_EMP e WHERE e.deptno = d.deptno ) ;

5. SQL 사용 지침

5.1. 인덱스(Index) 사용

5.1.1. 인덱스 사용지침

필요한 경우에만 인덱스를 생성하고, 사용되지 않는 인덱스는 모니터링 후 삭제한다.
실제 조사된 액세스 종류에 따라서 인덱스를 선정 및 검증한다.
특정 명령문을 튜닝하기 위해 인덱스를 추가로 생성할 경우 다른 SQL의 액세스 경로가 바뀔 수도 있으므로 충분한 사전 분석 작업이 필요하다.
각종 액세스 분포도가 자주 조합되어 사용되는 경우는 결합 인덱스로 생성한다.
자주 조합되어 사용되는 경우의 수를 만족할 수 있도록 인덱스간의 역할을 분담한다.(되도록 많은 access path를 수용하도록 한다)
가능한 수정이 빈번하지 않는 칼럼으로 인덱스를 선정한다.
결합 인덱스의 칼럼 순서 선정에 주의 한다. 첫 번째 칼럼이 Where 조건에 존재해야 인덱스 scan 가능하다.
반복수행(loop 내) 되는 조건은 가장 빠른 수행속도를 내게 하여야 하므로 인덱스 구성의 대상으로 최우선 고려한다.
넓은 범위(5% 이상)를 인덱스로 처리 시 random access로 인한 많은 오버헤드가 발생할 가능성이 있으므로, Table Full Scan을 고려해봐야 한다.
인덱스의 개수는 테이블의 사용 형태에 따라 적절히 생성한다. 왜냐하면 DML 작업이 많은 경우 성능저하의 원인이 될 수 있기 때문이다.
조인(join) 시에는 잘못된 인덱스 사용이 큰 부하를 가져올 수 있으므로, 인덱스 사용여부에 주의하여야 한다.

5.1.2. 인덱스 적용 원칙

5.1.2.1. 인덱스 컬럼은 원형 그대로 사용할 것

인덱스 컬럼은 비교되기 전에 변형이 일어나면 인덱스가 사용되지 않기 때문에 되도록이면 WHERE절에서 인덱스 컬럼을 원형 그대로 사용하는 것이 바람직하다.

예시(1)
- 개선 전
- SELECT dept, ename, sal FROM EMP WHERE SUBSTR(job, 1, 4) = '<st1:city w:st='on'>SALE</st1:city>' ;
- 개선 후
- SELECT dept, ename, sal FROM EMP WHERE job LIKE '<st1:city w:st='on'>SALE</st1:city>%' ;
예시(2)
- 개선 전
- SELECT empno, ename, job FROM EMP WHERE (sal * 12) = 35000000 ;
- 개선 후
- SELECT empno, ename, job FROM EMP WHERE sal = (35000000 / 12) ;
예시(3)
- 개선 전
- SELECT empno, ename, job FROM EMP WHERE CONCAT(job, dept) = 'CLERK10' ;
- 개선 후
- SELECT empno, ename, job FROM EMP WHERE job = 'CLERK' AND dept = '10' ;
예시(4)
- o 개선 전
- SELECT chr, num, var, dat FROM SAMPLET WHERE CAST(car AS INTEGER) = 10;
- o 개선 후
- SELECT chr, num, var, dat FROM SAMPLET WHERE chr = '10' ;
위의 예를 이용하여 다음과 같이 강제로 인덱스를 타지 않게 할 수 도 있다.
SELECT SUM(col1) FROM TAB1 WHERE RTRIM(status) = '90' ;

5.1.2.2. 인덱스 사용시 부정형을 사용 금지

인덱스 컬럼을 부정형(NOT, <>)으로 비교할 때도 인덱스가 사용되지 않는다.

예시(1)
- 개선 전
- SELECT 'Not found' INTO :col1 FROM EMP WHERE empno <> '1234' ;
- 개선 후
- SELECT 'Not found' INTO :col1 FROM DUAL WHERE NOT EXISTS ( SELECT ‘'X' FROM EMP WHERE empno =‘'1234' ) ;

5.1.2.3. 인덱스 컬럼을 NULL과 비교 금지

인덱스 컬럼을 NULL과 비교하여도 해당 인덱스가 사용되지 않는다.

예시(1)
- 개선 전
- SELECT ord_no, ord_date, item, ord_qty FROM ORDER1T WHERE ord_date IS NOT NULL ORDER BY ord_date ;
- o 개선 후
- SELECT ord_no, ord_date, item, ord_qty FROM ORDER1T WHERE ord_date > ' ' ; -- ord_date가 숫자 타입이면 SELECT ord_no, ord_date, item, ord_qty FROM ORDER1T WHERE ord_date > 0 ;

5.2. 뷰(View) 사용

5.2.1. 뷰(View) 명명법

뷰의 명명법은 기본적으로 테이블에 대한 명명법과 동일하다. 다만 뷰의 이름을 'vw’ 또는 'v’로 시작하는 것은 피하는 것이 좋다. 이유는 다음과 같다.

뷰를 나중에 테이블로 전환하는 경우 'vw’ 로 시작하는 이름을 모두 'tbl’로 바꾸어야 하는 병폐가 생길 수 있다.

5.2.2. 보안성을 높이려면 뷰(View)을 사용할 것

5.2.3. 데이터에 대한 검증을 위해서 뷰(View)을 사용할 것

5.2.4. 사용자의 요구로 인한 복잡성을 줄이기 위해 뷰(View)을 사용

사용자 또는 SQL 초보프로그래머를 위해 복잡한 SQL조회 결과를 뷰(View)로 미리 만들어 놓으면 추후 작업할 때 일을 대폭 줄여줄 수 있다

5.2.5. 2차 데이터를 도출할 때 뷰(View)을 사용하면 도움이 된다.

기존 테이블의 데이터를 근간으로 2차 데이터를 도출하여 사용할 때 뷰를 정의하여 사용하면 프로그래머의 부담이 줄어든다.

5.2.6. 테이블의 컬럼명이 복잡하거나 어려울 때 뷰(View)을 사용할 것

테이블의 컬럼명이 복잡하고 애매할 경우 간결한 컬럼명을 가지는 뷰를 생성하면 기존 컬럼명을 수정하지 않고도 동일한 효과를 얻을 수 있다.

5.2.7. 복잡한 제약사항을 단순화하기 위해 뷰(View)을 사용할 것

DBMS 마다 테이블에 대한 복잡한 제약사항을 지원하는데 한계가 있으며, 이 한계는 DBMS마다 다르다. 이를 극복하기 위하여 뷰(View)을 사용하면 큰 도움이 된다.

5.2.8. 뷰를 생성하려면 그에 합당한 이유가 있어야 한다.

5.2.9. 뷰를 남용하지 말 것

JAVA Coding Conventions

그레고리오78 — Mon, 16 Mar 2026 18:34:20 +0900

1. 코드 표준

1.1 코드 표준의 필요성

프로그램의 코드 표준은 다음과 같은 이유로 프로그래밍에 있어서 중요성을 지닌다.

소프트웨어의 생명주기에 있어서 비용의 80% 이상이 관리에 소요된다.
코드 표준은 소프트웨어의 가독성(Readablity)을 높여 주며 개발자로 하여금 새로운 코드를 보다 빠르고 완벽하게 이해하도록 한다.
제품으로서 소스 코드를 납품해야 할 경우 다른 제품과 마찬가지로 코드를 잘 정리하고 깔끔하게 해야 한다.
재 작업으로 발생하는 오류를 예방 할 수 있다.
이를 위해 표준이 잘 적용되도록 하기 위해서는 소프트웨어 작성자 모두가 코딩 표준을 반드시 준수해야 한다.

1.2 코드 표준이 적용될 수 없는 경우

표준 적용에 예외가 발생하는 경우에는 표준을 저해하는 잠재적인 가능성 및 표준이 적용되기 이전에 발생한 어떤 조건이나 상황 및 대처방식을 문서화 해 놓으면, 다른 사람으로 하여금 표준을 지키지 않은 코드를 이해하는데 편리성을 제공하며 코드 표준을 보다 견실히 하는데 도움이 된다.

2. 명명 규칙(Naming Rule)

2.1 일반 사항

언어 간의 혼란을 피하고 통합을 보장하려면 약어 사용과 관련된 다음 규칙을 따라야 합니다.

업무 영역에 적합하게 정의된 용어를 사용한다.
같은 유형에 명명할 때, 비슷한 명칭이나 대소문자만 다른 명칭 사용을 금지한다.
자주 사용되는 JDK의 Package와 중복되지 않도록 한다. 또한 JDK 및 각 언어에서 사용하는 키워드와 중복되지 않아야 한다.
약어 또는 축약어를 식별자 이름의 일부로 사용하지 않습니다. 예를 들어, getWin 대신 getWindow를 사용합니다.
컴퓨팅 분야에서 일반적으로 받아 들여지지 않는 Prefix는 사용을 금지한다.
적절한 경우에는 길이가 긴 구 이름 대신 잘 알려진 머리 글자어를 사용한다. 예를 들어, User Interface 대신 UI를 사용하고 On-line Analytical Processing 대신 OLAP를 사용합니다.
명칭(Class, Method 등)의 길이는 31자 이내로 한다.
동일한 변수명과 함수명을 사용하지 않는다.
명칭은 “_” 이외의 특수 문자를 사용하지 않는다.
중괄호는 시작 문장의 마지막 열에 삽입, 닫는 중괄호는 새로운 시작열에 삽입한다.(if문, else-if문, else문, for문, while문, do-while문, switch문, try-catch문)
하나의 문장이 여러 줄로 작성될 경우 아래와 같은 규칙에 의해 행을 나눈다.
- 80자 초과 시, 쉼표 다음 문자부터 새로운 행을 시작한다.
- 이전 행과 동일한 수준의 표현식과 열을 맞춘다.

int result = getEmployees(recordsFromEmployeeTable, readCount,
                          recordsToEmployeeTable, writeCount);

배열을 선언하는 경우 반드시 요소 수를 명시적으로 선언하거나 초기화에 의해 묵시적으로 결정되도록 한다.
지역 변수는 선언과 동시에 초기화 한다.

int result = 0;

숫자 리터럴을 직접적으로 소스코드 안에 삽입하지 않는다.
단항 연산자는 피연산자와 붙여 쓴다.

var++;

.(dot) 연산자를 제외한 모든 이항 연산자 전후는 공백으로 구분한다.
조건부 연산자에서 “?” 연산자 앞에 이항 연산식이 나타날 경우 괄호로 구분한다.
증감 연산자는 수식에서 다릉 연산자와 결합하여 사용하지 않는다.
3개 이상의 연산자를 사용하는 경우 괄호로 연산의 우선순위를 표현한다.
Switch-case 문에서는 반드시 default 문을 작성하고 마지막 항목에 위치한다.
For 문을 제어하는 수식에 실수 값을 사용하지 않는다.
반복문 내부에서 반복중단을 위한 break 문은 가능한 한번만 사용하도록 한다.
if ~ else if 문은 반드시 else 문으로 끝나도록 한다.
문자열 변수는 null로 초기화 하지 않는다.
문자열 비교 시 ==를 사용 하지 말고 equals()를 사용한다.

if (“company”.equals(companyName)) {
   // some code
}

클래스 맴버변수를 public으로 선언하지 않는다.
패키즈를 import 할 때 “*”를 사용하지 않는다.
광범위한 예외 클래스인 Exception을 사용하여 예외처리 하지 않는다.
예외를 처리할 때, 민감한 정보를 외부에 노출하지 않는다.
널리 알려진 축약형을 사용할 때 첫 문자만 대문자를 사용한다.

loadXmlDocument()

비슷한 이름은 사용을 배제한다.

Object persistentObject;
Object persistentObjects;

2.2 대문자 표시 스타일

식별자의 대문자 표시 스타일 규칙은 다음 세가지를 사용합니다.

2.2.1 Pascal Case

식별자의 첫 번째 문자와 연결된 각 후속 단어의 첫번째 문자를 대문자로 표시 합니다. 세개 이상의 문자로 구성된 식별자에 파스칼식을 사용할 수 있습니다.

String BackColor;

2.2.2 Camel Case

식별자의 첫 번째 문자는 소문자로 표시하고 연결된 각 후속 단어의 첫 번째 문자는 대문자로 표시합니다.

String backColor;

2.2.3 모두 대문자 표시

식별자의 모든 문자를 대문자로 표시합니다. 이 규칙은 두개 이하의 문자로 구성된 식별자에만 사용합니다.

OLAP
LDAP

열거형 및 상수 값에 모두 대문자로 표시된 문자가 자주 사용되는 기존의 관리되지 않는 기호 스키마와의 호환성을 유지하기 위해 식별자를 대문자로 표시해야 하는 경우도 있습니다.
일반적으로 이러한 기호는 해당 기호를 사용하는 어셈블리 외부에서는 표시될 수 없습니다.
다음 표에서는 대문자 표시 규칙에 대해 간단히 설명하고 여러 형식의 식별자에 대한 예를 보여 줍니다.

식별자대문자 표시 규칙예제

클래스	Pascal Case	AppDomain
열거형 형식	Pascal Case	ErrorLevel
열거형 값	Pascal Case	FatalError
이벤트	Pascal Case	ValueChange
읽기 전용 정적 필드	Pascal Case	RedValue
매서스	Camel Case	toString
패키지	Camel Case	java.io
매개변수	Camel Case	typeName
GET/SET	Camel Case	getBackColor/setBackColor

2.3 Package

Java에서는 클래스를 논리적으로 그룹화하기 위해 계층화된 Package를 통해 분류한다.
그러므로, 사전에 체계적으로 패키지를 잘 정의해 두는 것이 필수적이다.
Package의 이름을 지정하기 위한 일반적인 규칙은 국가.조직분류.회사 이름 다음에 기술 이름과 선택적 요소로 기능 및 디자인을 차례로 사용하는 것이다.
예를 들면 다음과 같이 국가.조직분류.회사명.기술-제품명.하위제품명-모듈 등을 마침표(.)를 통해 구분한다. 이때, 각 이름은 캐멀식을 사용해야 한다.

kr.co.company.[feature-technology Name].[module]

본 표준에서는 업무용 시스템에 맞게 다음과 같은 Package 구조를 따르기를 권장한다.

수준내용고정값 / 예제생략 가능

1	국가	kr, en 등	X
2	조직분류	com, co, go 등	X
3	회사	회사명	X
4	어플리케이션/시스템명	제품명, 프로젝트명 등	X
5	모듈	모듈명 등	X

2.4 Class

다음 규칙은 클래스 명명 지침을 요약한 것 입니다.

클래스 이름에는 명사 또는 명사구를 사용합니다.
파스칼식 대문자 표시 스타일을 사용합니다.
Java의 naming rule에 따라 Class의 이름은 명사를 사용하고, 첫 문자는 대문자로 시작을 하며 Internal word의 첫 번째 문자는 대문자를 사용합니다.
약어는 꼭 필요한 경우에만 사용합니다.
클래스 이름에는 클래스를 나타내는 C 등의 형식 접두사를 사용하지 않습니다. 예를 들어 CFileStream 대신 FileStream을 사용합니다.
밑줄(_)를 사용하지 않습니다.
시스템 및 서브시스템을 표시할 수 있는 Prefix를 사용하거나 Class의 특징을 나타내는 Suffix를 사용할 수 있습니다.
Prefix는 시스템의 특징을 나타내는(구별하는) 취지에서 사용합니다.
Suffix는 파일구조에서 말하는 확장자가 아니고, 클래스이름을 정할 때 이름의 끝에 들어가는 접미사로 파일의 클래스의 특징 및 해당 이름을 가진 코드들의 기능(데이터삭제, 등록, 조회 등)을 구별하는 취지에서 사용합니다.
서브시스템이 존재하는 프로젝트에서는 Prefix로 서브시스템을 나타내는 문자를 사용할 것을 권장합니다.

2.5 Interface

다음 규칙은 인터페이스 명명 지침을 요약한 것 입니다.

인터페이스 이름을 지정할 때는 명사 또는 명사구나 동작을 설명하는 형용사를 사용합니다.
예를 들어, Component라는 인터페이스 이름에서는 설명적인 명사를 사용합니다.
또한 CustomAttributeProvider라는 인터페이스 이름에서는 명사구를 사용하며, Persistable라는 이름에서는 형용사를 사용합니다.
파스칼식 대문자 표시 스타일을 사용합니다.
약어는 꼭 필요한 경우에만 사용합니다.
클래스가 인터페이스의 표준 구현인 경우 해당 클래스/인터페이스 쌍을 정의할 땐느 유사한 이름을 사용합니다. 클래스 이름에 Impl 접미사가 있는 점만 제외하고 두 이름은 동일해야 합니다.
밑줄(_)을 사용하지 않습니다.

public interface CodeService {
    // Implementation code goes here.
}

// 인터페이스
public interface CodeService {
    // Implementation code goes here.
}

// 인터페이스 구현 클래스
public class CodeServiceImpl implements CodeService {
    // Implementation code goes here.
}

2.6 Method

다음 규칙은 클래스의 멤버 메서드 명명 지침을 요약한 것 입니다.

메소드는 동사를 사용합니다.
첫 번째 문자는 소문자로 나타냅니다.
여러 단어가 조합될 경우 조합되는 단어의 첫 번째 문자는 대문자로 시작되어야 합니다.
get / set 메서드
- 클래스 멤버변수 접근(Access)을 위한 get / set 뒤에 멤버변수명을 쓰는 것을 원칙으로 합니다.
메서드 명은 동사형으로 시작하며 동사 + 목적어 형태로 기술합니다.
메서드 명은 구체적인 용어로 표기하지 않고, 일반적인 메시지 형태로 표기합니다.
- 잘못된 예) saveToDB() – DB같은 구체적인 용어를 사용하지 말고 일반적인 메시지 형태로 표기

// get / set 메서드
private String name = null;
public String getName() {
    return name;
}
public void setName(String name) {
    this.name = name;
}

// 그 밖의 메서드
create(), checkOut(), attachToDesk(), fileTransfer(), run() 등

2.7 변수

다음 규칙은 변수 명명 지침을 요약한 것 입니다.

첫 번째 문자는 소문자로 나타냅니다.
변수 및 필드 이름에는 헝가리어 표기법 접두사를 사용하지 않습니다. 단, 임시변수는 헝가리안 표기법으로 작성합니다.
여러 단어가 조합될 경우 조합되는 단어의 첫 번째 문자는 대문자로 시작되어야 합니다.
변수명의 시작을 밑줄문자(_) 또는 $ 문자로 사용하지 말아야 합니다.
변수명은 짧으면서도 충분히 의미가 느껴지도록 하고, 뇌리에 선명하게 남도록 하는 것을 정해야 합니다.
Collection type의 변수 이거나 배열인 경우 복수로 표현한다.
멤버 변수
- 멤버 변수라 함은 메서드 외부에서 정의하는 변수를 의미한다.
- final 상수 제외 : 상수에 대한 규칙은 2.8 상수 참고
- 접근자(Access Modifier)
  - 클래스의 멤버변수 영역은 protected를 원칙으로 한다.
  - Protected로 선언된 멤버변수가 하위 클래스를 제외한 다른 클래스에서 사용될 때는 get / set 메서드를 사용하도록 한다.
  - 변수의 특징에 따라 Access Modifier는 변경될 수 있다.(get / set 메서드에 대한 규칙 2.6 Method 참고)

protected int objID;
private Table tableTab;

로컬 변수라 함은 Method 내에 정의하는 변수를 의미한다.
- 로컬 변수의 첫 문자는 소문자로 사용하고, 여러 단어가 조합될 경우 조합되는 단어의 첫 번째 문자는 대문자로 시작한다.

float myWidth;
String userID;
int seq;

임시 변수라 함은 loop 문이나 condition 문에서 임시로 사용하는 변수를 의미한다.
- 임시변수는 헝가리안 표기법(Hungarian Notation)으로 작성합니다.
- 한 개의 문자로 변수명을 구성하는 것은 임시 변수인 경우에만 사용하며, 다음과 같이 정의한다.

i, j, k, l // 정수형
c, d // 문자형 임시 변수
x, y, z // 좌표
e // 예외
g // 그래픽
o // 객체
s // 문자열

2.8 상수

클래스 상수 또는 일반 상수로 정의된 변수명은 Snake Case를 사용한다. 즉, 단어 간의 밑줄문자(_)로 분리되는 대문자 사용한다.

static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;

2.9 파라미터(인자)

생성자(Constructor)나 set Method에서 멤버 필드에 값을 지정할 때, 파라미터 이름은 멤버 필드 이름과 동일하게 부여 한다.(this 키워드 사용)

public class Dude {
     private String name;
     public Dude(String name) {
        this.name = name;
     }
     public void setName(String name) {
         this.name = name;
     }
}

3. 주석 사용 지침

3.1 일반 사항

일반적으로 코드만 가지고는 정확하게 코드가 의미하는 바가 무엇인지 이해하기 힘들다.
주석(Comment)은 코드에 추가적인 설명을 달아서 코드를 보다 읽기 쉽게 만들어 준다.
여기에서는 개발자들이 준수해야 하는 주석 사용 지침을 설명한다.
코드에 장식을 하지 않는다(배너식의 주석 사용을 자제한다.)
주석은 가능한 단순하게 한다.
코드 작성 이전에 주석부터 작성한다.
‘무엇이 되었다’가 아니라 ‘무엇이 이러한 이유로 이렇게 되었다’ 식으로 작성한다.
주석 위치는 클래스의 시작, 각 메서드 선언의 바로 위에 한다.
메서드 내부에서도 단계별로 구분지어서 설명할 필요가 있을 때도 주석을 작성한다.
변수 하나의 의미를 쓰는 주석 등은 사용하지 않는다.
변수 이름을 명확하게 주어서 주석 작성의 필요를 제거한다.

3.2 주석의 종류 및 사용방법

주석의 종류사용 방법

문서화 주석		/** … */
코드구현 주석	블록주석	/* * … */
	Single-line 주석	/* */
	Trailing 주석	소스코드 + /* */
	End-of-Line 주석	//

3.2.1 기본 원칙

클래스(또는 인터페이스), 메서드, 멤버 변수의 주석으로는 JavaDoc 주석 사용을 권장한다.
메서드 안의 코드 설명 또는 로컬변수의 주석으로는 단일라인 주석만 사용한다.

3.2.2 문서화 주석

3.2.2.1 Class Comments

모든 소스의 가장 앞 부분에 다음과 같이 클래스 이름, 하는 작업, 작성일 Comments와 버전정보, 작성자를 명기한다.
여기서 작성일과 작성자의 다음의 괄호 부분엔 수정일과 수정자의 이름이 명기되며 수정일 뒤에는 수정이유를 간단하게 밝힌다.

/**
 * <pre>
 * 각종 문자열, 스트링, 데이트 형식에 따른 유틸리티
 * </pre>
 *
 * @author Company.co., Ltd
 * @version
 * <ul>
 *     <li>1.0.0 (2025.03.28) 홍길동(test@company.co.kr) - 최초 구현</li> 
 * </ul>
 * @code <pre>{@code
 * @Autowired
 * private FormatUtil formatUtil;
 * }</pre>
 * @since 2025.03.28
 */

3.2.2.2 Method Comment

/**
 * <pre>
 * 현재 실행 중인 스레드의 ClassLoader 객체를 반환하며, 만약 해당 스레드에 ClassLoader 객체가 설정되지 않은 경우, 대체 객체(defaultObject)의 클래스에 대한 ClassLoader 객체를 반환
 * </pre>
 *
 * @param defaultObject 대체 객체
 * @return the class loader
 * @code <pre>{@code
 * @Autowired
 * this.getCurrentClassLoader(params)
 * }</pre>
 * @history
 * <ul>
 *     <li>2025.03.28 홍길동(test@company.co.kr) - 최초 구현</li>
 * </ul>
 */

3.2.3 단일 라인 주석(Single Line Comment)

// 로 시작하며, 해당 라인의 끝까지 적용된다.
설명하고자 하는 코드의 바로 윗줄이나, 코드와 같은 라인의 오른쪽에 작성한다.
하나의 라인이나 한 라인의 일부를 주석처리해서 컴파일 되지 않도록 임시로 막을때로 사용된다.

public class FileStream {
    // 여기에 코드를 입력하세요.
}

3.2.4 블럭 주석(Block Comment)

/* 로 시작하여 */ 까지 적용된다.
메서드안에서는 단일라인 주석을 사용한다.
짧은 내용의 주석을 다음 라인에 기술될 코드이 들여쓰기에 맞춰서 한 라인에 표현할 수 도 있다.
만약 한 라인에 다 표현하지 못 할 경우에는 블록주석 방식을 사용한다.
한줄 또는 여러 줄을 주석처리하거나, 코드의 블록이 컴파일 되지 않게 임시로 막을 때로 사용된다.

public class FileStream {
    /*
    여기에 코드를
    입력하세요.
    */
}

3.2.5 Trailing comment

매우 짧은 주석으로 사용할 수 있는 코드로써 같은 라인에 나타낼 수 있지만 코드를 문(statement)으로부터 분리하기 위해서는 충분히 떨어져야 한다.
만일 하나 이상의 짧은 주석이 큰 덩어리의 코드로 나타날 경우 동일한 위치에서 들여쓰기를 하여야 한다.

if(a==2) {
    return true;           /* special case */
} else {
    return isPrime(a);     /* works only for odd a */
}

3.2.6 End-of-Line Comment

“//” comment delimiter는 라인 전체 또는 일부를 주석으로 처리 할 수 있으며 “//”는 문장 주석을 위한 연속한 여러 라인에 사용되어서는 안된다.
단, 코드의 특정섹션을 처리하기 위해서는 연속한 라인에 사용 되어도 무방하다.
변수선언 후 변수에 대한 설명으로 사용하거나 또는 특정라인에 대한 설명으로 사용한다.
복잡한 제어구조에서 각 제어문의 끝을 나타내기 위해서 사용한다.

for(…) {
    while(…){
        if(…) {
            switch(…) {
                 …
            } // end switch
        } // end if
    } // end while
} // end for

3.3 IntelliJ Class/Method Comment Template 설정 방법

3.3.1 Class

아래 그림과 같이 설정> 도구> JavaDoc> Templates 이동 후 Class level Regular expression 설정 변경

.+ : 목록 순서를 첫번째로 변경
개발자_이름 : 본인 이름 입력
이메일 계정 : 본인 이메일 계정

/**\n
* <pre>\n
* 여기에 설명을 작성하세요.\n
* </pre>\n
* @apiNote (선택)API 사용자(개발자)가 알아야 할 중요한 사항을 기록\n
* @implSpec (선택)구현 클래스가 반드시 따라야 할 규칙을 명시\n
* @implNote (선택)구현 방식을 변경할 때 고려해야 할 점 등을 설명\n
* @since ${.now?string('yyyy.MM.dd')}\n
* @author Company.co., Ltd\n
* @version\n
* <ul>\n
*     <li>1.0.0 (${.now?string('yyyy.MM.dd')}) 개발자_이름(이메일_계정@company.co.kr) - 최초 구현</li>\n
* </ul>\n
* @code <pre>{@code\n
*  }</pre>\n
<#if element.typeParameters?has_content>        * \n
</#if>
<#list element.typeParameters as typeParameter>
        * @param <${typeParameter.name}> the type parameter\n
</#list>
*/

3.3.2 Method

아래 그림과 같이 설정> 도구> JavaDoc> Templates 이동 후 Method level Regular expression 설정 변경

.+ : 목록 순서를 첫번째로 변경
개발자_이름 : 본인 이름 입력
이메일 계정 : 본인 이메일 계정

/**\n
 * <pre>\n
 * 여기에 Method 설명을 작성하세요.\n
 * </pre>\n
<#if element.typeParameters?has_content>         * \n
</#if>
<#list element.typeParameters as typeParameter>
         * @param <${typeParameter.name}> the type parameter\n
</#list>
<#if element.parameterList.parameters?has_content>
         *\n
</#if>
<#list element.parameterList.parameters as parameter>
         * @param ${parameter.name} the ${paramNames[parameter.name]}\n
</#list>
<#if isNotVoid>
         *\n
         * @return the ${return}\n
</#if>
<#if element.throwsList.referenceElements?has_content>
         *\n
</#if>
<#list element.throwsList.referenceElements as exception>
         * @throws ${exception.referenceName} the ${exceptionNames[exception.referenceName]}\n
</#list>
 * @code <pre>{@code\n
 * 여기에 Method 사용법을 작성하세요.\n
 * }</pre>\n
 * @history\n
 * <ul>\n
 *     <li>${.now?string('yyyy.MM.dd')} 개발자_이름(이메일_계정@company.co.kr) - 최초 구현</li>\n
 * </ul>\n
 */

4. 선언(Declaration)

4.1 Number per Line

한 라인당 하나의 선언이 추천되는데 이는 주석을 달기 좋기 때문이다.

int level; // indentation level
int size; // size of table
object currentEntry; // currently selected table entry

아래의 코드보다 위의 코드가 가독성이 편리하다.

int level, size;

다음 예처럼 서로 다른 유형을 동일라인에 표현하는 것은 피해야 한다.

int foo, fooArray[]; // wrong!

4.2 배치

선언문의 배치는 블록의 제일 앞에 배치한다.
여기서 블록이란 중괄호”{“, “}”로 둘러쌓인 모든 코드를 말한다.
선언문이 블록의 중간에 나타나는 것은 좋은 방법이 아니다.
상위 레벨의 선언을 무효화 시키는 지역선언은 배제되어야 하며 예를 들어 내부 블록내에 동일한 변수명을 선언하는 것은 좋지 않다.

int count;
…
myMethod() {
    if(condition) {
        int count = 0; // AVOID!
    }
}

4.3 클래스와 인터페이스 및 배열 선언

클래스나 인터페이스를 개발 할 때에는 다음과 같은 구성 원칙을 따른다.

메서드는 이름과 파라메터 목록이 시작되는 괄호”(“ 사이에는 공백을 두지 않는다.
열린 중괄호(opening brace, “{“)는 선언문과 같은 라인에 위치한다.
닫힌 중괄호(closing brace, “}”)는 열린 중괄호와 상응하도록 들여쓰기를 적용하되 열린 중괄호 뒤가 null 문장인 경우에는 닫힌 중괄호가 바로 대치되도록 한다.
메서드는 공백라인에 의해 분리된다.
상황에 따라서는 열린 중괄호를 선언문 다름 라인에 위치 할 수도 있다.
배열선은은 타입 바로 다음에 배열기로”[ ]”가 오게 한다.

5. 공백 및 들여쓰기

5.1 공백 라인

공백 라인은 논리적으로 관련된 코드 섹션을 분리하여 가독성을 향상 시킨다.

두줄의 공백 라인은 다음 상황에서만 사용한다.

소스파일의 섹션 구분
클래스나 인터페이스의 정의 구분

한줄의 공백 라인은 다음의 상황에서만 사용한다.

메서드의 구분
메서드 내의 지역변수와 첫 문장 구분
블록 주석 또는 단일문 주석의 앞
가독성 향상을 위해 메서드 내의 논리 섹션간의 구분
package 선언 후

5.2 공백 문자

공백 문자는 다음과 같은 상황에서 사용된다.

매개변수 목록에서 콤마(,) 다음에 공백문자를 사용한다.
“.”를 제외한 모든 Binary 연산자는 Operand로부터 공백문자를 통해 분리되며 공백문자는 단항연산자(unary), minus(“-“), increment(“++”), decrement(“--“)등과 같은 단항연산자를 operend로부터 분리해서는 안된다.
for 문 내의 표현식은 공백문자에 의해 분리되어야 한다.
형 변환에 공백문자를 사용한다.

5.3 줄 간 이어 쓰기

들여쓰기의 단위로는 공백문자(Space) 4개를 이용하며, Tabs은 4개의 공백문자로 설정하며, 한 라인에 표현되기 어려운 문장의 경우에는 다음 일반원칙에 따라 라인을 분리한다.

Comma(“,”)뒤에서 분리
연산자 다음에 분리
레벨에 있어서는 하위 레벨보다는 상위 레벨에서 분리
새 라인은 이전 동일 레벨에 있는 표현문장의 시작위치에 맞추어야 한다.
만약 위 원칙이 코드를 혼란케 하거나 오른쪽 여백을 손상케 하는 경우에는 그냥 2개의 공백문자를 이용하여 들여쓰기를 하여야 한다.
조건문 작성시 조건문이 길어질 경우 조건당 한줄로 작성한다.
If 조건절의 줄간 이어쓰기는 일반적으로 2개의 공백문자를 사용한다.

6. 기타

6.1 인스턴스와 클래스 변수에 대한 접근 허용

인스턴스 변수에 대한 public 접근은 사능한 허용해서는 안된다.
대체로 인스턴스 변수는 명시적으로 값을 설정하거나 읽혀질 필요성을 지니고 있지 않은데, 명시적으로 값이 설정 또는 읽혀질 경우는 메서드 호출의 부작용으로 발생한다.
클래스가 단순히 자료구조의 역할을 하는 경우에는 인스턴스 변수를 public으로 접근하도록 한다

6.2 클래스 변수와 메서드의 참조

클래스 변수와 클래스 메서드에 접근하기 위해 오브젝트 인터페이스는 가능한 이용해서는 안된다.

6.3 상수

숫자 상수는 직접코드화 하지 말고, 반드시 정의한 후 사용한다.
-1, 0, 1 등과 같이 for loop 에서 counter로 사용되는 상수들은 그냥 사용해도 무방하다.

6.4 변수 할당

단일문에서 여러 번수에 동일한 값을 할당 할 경우 가독성이 저하된다.
Equality operator('==')와 쉽게 혼동 될 수 있는 위치에서의 Assignment('=') 사용은 가급적 지양한다.

6.5 괄호

연산자가 복잡하게 사용 된 경우에 연산자 우선순위 문제를 해결하기 위해 괄호를 활발하게 사용하는 것을 권장한다.
이는 실상 연산자 우선순위가 개발자 본인에게는 명백히 보인다 할지라도 다른 개발자를 위한 배려를 베풀어야 한다.

6.6 기타 고려사항

여러 줄의 String을 결합할 경우 String = String + String 보다는 StringBuffer를 사용한다.
비록 크기가 작은 클라스하도 새로 인스턴스화 하지 말고 최대한 재 사용해야 좋은 성능을 얻을 수 있다.

객체지향(OOP)의 Class/Method/변수 및 일반화와 상속성

그레고리오78 — Mon, 16 Mar 2026 08:27:06 +0900

1. Class의 개요

1.1 Class의 정의

Class는 객체를 생성하기 위한 설계도(Template) 이다. 객체의 속성(Attribute) 과 행위(Method) 를 정의한다.

구성요소	설명	예시
Attribute	객체의 상태를 표현하는 데이터	name, age
Method	객체의 동작을 정의	getName(), move()
Constructor	객체 생성 시 초기화	Person()
Access Modifier	접근 제어	public, private

개념 구조

1.2 Class UML 표현

UML에서는 3단 구조로 표현한다.

접근자의 의미

기호	의미
+	public
-	private
#	protected
~	package

1.3 Class의 일반화와 상속성

일반화 (Generalization)

여러 클래스의 공통 특성을 상위 클래스에 정의하는 것

예

공통 속성

name
age
eat()

상속 (Inheritance)

기존 클래스의 속성과 메소드를 재사용하는 메커니즘

특징	설명
코드 재사용	공통 기능 재사용
확장성	기능 확장 가능
유지보수	변경 영향 최소화

1.4 일반화 및 상속 UML 표현

2. 개발 언어별 Class / Method 비교

2.1 Class 비교 및 인수 전달 방식

언어	Class 지원	인수 전달
C	없음 (struct 사용)	Value
C++	지원	Value / Reference
Java	지원	Value (객체는 reference copy)
C#	지원	Value / ref / out
VB.NET	지원	ByVal / ByRef
Python	지원	Object Reference

2.2 Method 비교

언어	Method 형태	특징
C	함수	클래스 없음
C++	Member Function	OOP 지원
Java	Instance Method	JVM 기반
C#	Method	.NET
VB.NET	Sub / Function	.NET
Python	def	동적 타입

2.3 호출 방식

방식	설명
Call by Value	값 복사
Call by Reference	주소 전달
Call by Object Reference	객체 참조 전달

2.4 데이터 타입

언어	타입
C	정적 타입
C++	정적 타입
Java	정적 타입
C#	정적 타입
VB.NET	정적 타입
Python	동적 타입

2.5 호출측 변경

전달 방식	호출자 영향
Value	변경 없음
Reference	변경 가능

3. 개발 언어별 Class / Method 예제

3.1 C 언어 예제

C는 OOP가 없으므로 struct + 함수 사용

#include <stdio.h>

typedef struct {
    char name[50];
    int age;
} Person;

void printPerson(Person p) {
    printf("Name: %s\n", p.name);
    printf("Age: %d\n", p.age);
}

int main() {
    Person p = {"Tom", 20};
    printPerson(p);
}

3.2 C++ 예제

#include <iostream>
using namespace std;

class Person {
private:
    string name;
    int age;

public:
    Person(string n, int a) {
        name = n;
        age = a;
    }

    void print() {
        cout << name << " " << age << endl;
    }
};

int main() {
    Person p("Tom",20);
    p.print();
}

3.3 Java 예제

class Person {

    private String name;
    private int age;

    public Person(String name, int age){
        this.name = name;
        this.age = age;
    }

    public void print(){
        System.out.println(name + " " + age);
    }

    public static void main(String[] args){
        Person p = new Person("Tom",20);
        p.print();
    }
}

3.4 C# 예제

using System;

class Person
{
    private string name;
    private int age;

    public Person(string name, int age)
    {
        this.name = name;
        this.age = age;
    }

    public void Print()
    {
        Console.WriteLine(name + " " + age);
    }
}

class Program
{
    static void Main()
    {
        Person p = new Person("Tom",20);
        p.Print();
    }
}

3.5 VB.NET 예제

Public Class Person

    Private name As String
    Private age As Integer

    Public Sub New(n As String, a As Integer)
        name = n
        age = a
    End Sub

    Public Sub Print()
        Console.WriteLine(name & " " & age)
    End Sub

End Class

3.6 Python 예제

class Person:

    def __init__(self, name, age):
        self.name = name
        self.age = age

    def print(self):
        print(self.name, self.age)


p = Person("Tom",20)
p.print()

4. Class 사이의 관계 (종속 / 연관)

객체지향 설계에서 클래스 관계는 다음과 같다.

관계	설명
Association	일반 연관
Dependency	종속
Aggregation	집합
Composition	합성
Inheritance	상속

UML 관계 도식

5. 개발 언어별 변수 선언 및 접근자

5.1 접근자의 개요

Access Modifier는 클래스 멤버 접근 범위를 제한한다.

목적

캡슐화
보안
유지보수성

5.2 개발 언어별 변수 선언 비교

언어	변수 선언
C	int age;
C++	int age;
Java	private int age;
C#	private int age;
VB.NET	Private age As Integer
Python	self.age

5.3 개발 언어별 접근자 비교

접근자	Java	C#	VB.NET	C++	Python
public	O	O	Public	O	기본
private	O	O	Private	O	_
protected	O	O	Protected	O	_
internal	X	O	Friend	X	X

전체 구조 요약

참고 문헌

Grady Booch, Object-Oriented Analysis and Design
Erich Gamma, Design Patterns
OMG, UML Specification
Robert C. Martin, Clean Architecture

DDD(Domain Driven Development)

그레고리오78 — Wed, 4 Mar 2026 07:32:52 +0900

1. 프로세스와 무관한 패턴과 원칙의 집합, DDD 개요

1) DDD의 정의

DDD(Domain Driven Development)는 소프트웨어의 핵심 복잡성(Core Complexity)을 해결하기 위해 도메인 모델을 중심(Model-Driven Design)으로 설계·구현하는 소프트웨어 개발 접근법이다.

이 개념은 Eric Evans가 저서 Domain-Driven Design: Tackling Complexity in the Heart of Software에서 체계화하였다.

정의 요약

비즈니스 도메인을 중심으로 모델을 설계
모델과 코드의 정합성을 유지
개발자와 도메인 전문가 간 공통 언어(UBIQUITOUS LANGUAGE) 사용
프로세스 자체가 아니라 패턴·원칙·Best Practice 집합

2) DDD의 필요성

구분	전통적 개발 방식 문제	DDD 접근
복잡성 관리	비즈니스 규칙이 분산됨	도메인 모델에 응집
요구사항 변화	변경 시 영향 범위 불명확	Aggregate 단위 변경
개발-현업 간 소통	문서 중심, 해석 차이 발생	UBIQUITOUS LANGUAGE 사용
코드 구조	CRUD 중심 설계	도메인 행위 중심 설계

DDD는 특히 다음과 같은 환경에서 효과적이다:

MSA 기반 복잡한 업무 시스템
비즈니스 규칙이 많은 금융/물류/ERP 시스템
장기 유지보수 프로젝트

2. DDD 구조도와 기본요소 및 특징

1) DDD Layered 구조도

DDD Layer Stack

계층 설명

Layer	책임	특징
Presentation	UI/API	외부 인터페이스
Application	유스케이스 orchestration	트랜잭션 제어
Domain	핵심 비즈니스 로직	Entity, Value, Aggregate
Infrastructure	DB, MQ, 외부시스템	기술 구현

핵심은 Domain Layer가 독립적이어야 한다는 점이다.

2) 도메인 모델(Domain Model)

도메인 모델은 다음을 포함한다:

Domain 객체
비즈니스 규칙
제약조건
상태 및 행위

MODEL DRIVEN DESIGN의 핵심은

모델 = 설계 = 코드 의 일치성을 유지하는 것이다.

3) DDD 기본 요소 및 특징

구분	설명
UBIQUITOUS LANGUAGE	도메인 전문가와 개발자가 공유하는 공통 언어
Bounded Context	모델의 경계를 명확히 정의
Aggregate	트랜잭션 일관성 경계
Repository	Aggregate 저장소
Domain Service	Entity로 표현하기 어려운 로직
Entity	식별자 기반 객체
Value Object	불변 객체
Domain Event	상태 변화 이벤트

4) DDD 특징

도메인 중심 설계
객체지향 설계 원칙 강화
응집도 ↑ 결합도 ↓
복잡성의 구조화
전략적 설계(Strategic Design) + 전술적 설계(Tactical Design)

5) 효과적인 모델링 구성요소

Bounded Context 명확화
Context Mapping
Aggregate 단위 설계
명확한 UBIQUITOUS LANGUAGE 정의
도메인 전문가 참여

3. DDD의 기본 구성 요소 (Tactical Pattern)

도메인 모델 기본 구성 요소 통합표

요소	정의	특징	예시
Entity	식별자를 가지는 객체	상태 변화 가능	Order
Value Object	값 자체가 의미	불변(Immutable)	Money
Aggregate	객체 묶음 단위	일관성 경계	Order + OrderLine
Repository	Aggregate 저장	인터페이스 중심	OrderRepository
Domain Service	특정 Entity에 속하지 않는 로직	Stateless	PaymentService
Factory	복잡한 생성 책임	생성 로직 캡슐화	OrderFactory
Domain Event	도메인 변화 표현	비동기 처리 가능	OrderCreated

주요 요소 상세

Entity	Value Object	Aggregate	Repository	Service
고유 ID 존재 동일성(Identity) 기반 비교 생명주기 관리	불변 객체 값 비교 부작용 최소화	Root(Entity) 중심 구성 외부는 Root만 참조 가능 트랜잭션 단위	Domain ↔ Persistence 분리 인터페이스는 Domain에 위치	특정 Entity에 귀속 불가한 로직 도메인 규칙 표현

4. DDD 적용 전제사항과 Process

1) DDD 전제사항

항목	설명
복잡한 도메인 존재	단순 CRUD 시스템은 불필요
도메인 전문가 협업 가능	UBIQUITOUS LANGUAGE 필요
장기 운영 시스템	단기 프로젝트에는 부적합
객체지향 이해도 확보	설계 역량 요구

2) DDD Process

도메인 탐색 (Domain Exploration)
UBIQUITOUS LANGUAGE 정의
Bounded Context 식별
Aggregate 설계
Repository 설계
Domain Service 정의
Infrastructure 연결

5. DDD 모델 구조와 계층 구조

1) 모델 구조

2) 계층 구조 통합 설명

구분	전략적 설계	전술적 설계
목적	도메인 경계 설정	모델 구현
구성	Bounded Context, Context Map	Entity, Value, Aggregate
관심사	시스템 전체 구조	객체 내부 구조

6. DDD 적용 시 고려사항

1) 도메인 로직 복잡성과 코드 재사용

복잡성 낮은 시스템 → 과도한 설계 위험
Generic Framework 과용 지양
도메인 중심 응집 설계 유지

MSA 환경에서는 서비스 단위 = Bounded Context로 설계하는 것이 적합

2) 도메인 로직과 유지보수 관계

항목	DDD 미적용	DDD 적용
변경 영향	광범위	Aggregate 단위
테스트	통합 테스트 중심	도메인 단위 테스트 가능
확장성	기술 중심	비즈니스 중심

결론

DDD는 단순한 설계 기법이 아니라:

복잡성 관리 전략
도메인 중심 개발 철학
모델 기반 설계(MODEL DRIVEN DESIGN)
UBIQUITOUS LANGUAGE 기반 협업 체계

특히 MSA, Spring 기반 대규모 업무 시스템 환경에서는 Bounded Context를 서비스 단위로 정립하고 Aggregate 중심 설계를 적용하는 것이 매우 효과적이다.

참고 문헌

Domain-Driven Design: Tackling Complexity in the Heart of Software – Eric Evans
Implementing Domain-Driven Design – Vaughn Vernon
Domain-Driven Design Distilled – Vaughn Vernon

ITSM(Information Technology Service Management)

그레고리오78 — Tue, 3 Mar 2026 19:01:48 +0900

1. IT서비스 관리를 위한 프레임워크, ITSM의 개요

1) ITSM의 정의

ITSM(Information Technology Service Management)은 IT 서비스를 “기술 중심(Technology-centric)”이 아닌 **서비스 중심(Service-centric)**으로 관리하기 위한 체계적 관리 프레임워크이다.

IT를 단순한 시스템 운영이 아닌 비즈니스 가치를 창출하는 서비스로 정의
프로세스 기반(Process-Oriented) 접근
품질, 비용, 위험을 통합 관리

핵심 개념: IT = 자산이 아니라 서비스

2) ITSM의 필요성

구분	전통적 IT 운영	ITSM 기반 운영
관리 관점	시스템 중심	서비스 중심
조직 구조	기능별 사일로	프로세스 중심 통합
성과 측정	시스템 가동률	SLA, 고객 만족도
목표	장애 최소화	비즈니스 가치 극대화
통제 방식	개별 부서 통제	End-to-End 통합 관리

도입 필요성

디지털 전환 가속화
SLA 기반 서비스 계약 증가
복잡한 IT 인프라 (Cloud, MSA, DevOps)
IT Governance 강화 요구

3) ITSM을 실현하기 위한 모델

구분	목적	특징
ITIL	ITSM Best Practice	프로세스 중심, 사실상 글로벌 표준
ISO/IEC 20000	ITSM 국제 표준	인증 기반
MOF	MS 기반 운영	Microsoft 중심 가이드
CMM	프로세스 성숙도	단계별 개선
CMMI	통합 성숙도 모델	조직 역량 향상
ISO/IEC 15504	프로세스 평가	SPICE 모델
eSCM	IT 아웃소싱 관리	공급자/고객 역량 평가

2. ITSM 구성도 및 구성요소

1) ITSM 구성도

IT Governance 구성도

2) ITSM 구성요소

영역	주요 프로세스
Service Strategy	서비스 포트폴리오, 재무관리
Service Design	SLA, 용량, 가용성, 보안
Service Transition	변경관리, 형상관리
Service Operation	Incident, Problem, Event
Continual Service Improvement	KPI, 성과측정, 개선

3) ITIL과 ITSM의 관계

ITSM = 개념(Concept)
ITIL = 실행 가이드라인(How-to Best Practice)

즉, ITIL ⊂ ITSM 구현 방법론

4) 전통 IT 운영 vs ITSM 비교

항목	전통 IT	ITSM
초점	기술	서비스
KPI	시스템 가동률	SLA 달성률
변화관리	사후 대응	사전 통제
고객 관점	내부 조직 중심	고객 중심

3. ITSM Framework 및 구성요소

1) ITSM Framework 구조

IT Governance 구조도

2) ITSM Framework 구성요소

영역	목표	주요 산출물
Governance	IT 통제 및 전략 정렬	IT 정책
Service Strategy	서비스 방향 설정	Service Portfolio
Service Design	서비스 설계	SLA, OLA
Service Transition	안정적 전환	Change Record
Service Operation	안정적 운영	Incident Report
CSI	지속 개선	KPI Report

4. ITIL 기반 ITSM 도입 전략

1) ITSM Best Practice, ITIL 특징

ITIL 특징:

프로세스 기반 관리
고객 중심 SLA 구조
PDCA 기반 지속 개선
벤더 중립적

2) ITSM 도입을 위한 ITIL의 역할

역할	설명
표준화	운영 프로세스 통합
품질 향상	SLA 기반 관리
위험 감소	변경 통제 강화
비용 절감	재작업 감소

3) ITSM 구축 방안 비교

구분	Big Bang	단계적 도입
리스크	높음	낮음
비용	초기 높음	분산
추천 대상	대기업	대부분 조직

4) ITSM 도입전략 Flow

프로세스 개선 Flow

5) ITSM 단계별 도입 절차

단계	주요 활동
1단계	IT 거버넌스 정립
2단계	핵심 프로세스 선정
3단계	SLA 정의
4단계	Tool 도입
5단계	KPI 기반 개선

5. ITSM 추진 장애요소 및 극복방안

장애요소	극복방안
조직 저항	경영진 후원 확보
프로세스 미정립	표준화 작업 선행
KPI 부재	측정지표 정의
도구 중심 접근	프로세스 우선 접근
인력 역량 부족	교육 및 인증

6. ITSM 구축 효과 및 고려사항

1) ITSM 구축 효과

(1) 고객/사용자 측면

SLA 기반 품질 보장
장애 대응 시간 단축
서비스 가시성 향상

(2) IT 조직 측면

운영 표준화
변경 통제 강화
비용 예측 가능성 증가
성숙도 향상 (CMMI 기반 개선 가능)

2) ITSM 구축시 고려사항

IT Governance 체계 연계
경영진 Sponsorship 확보
KPI 기반 운영
Tool 의존도 최소화
조직 문화 변화 관리

3) ITSM 발전 전망

DevOps + ITSM 통합
AI 기반 Incident 자동화
Cloud Native 환경 통합 운영
ESG 기반 IT 서비스 관리 확장

IT Governance 통합개념 구조도

결론

ITSM은 단순한 운영 개선 활동이 아니라, IT Governance 하에서 IT를 전략적 서비스 자산으로 전환하는 관리 체계이다.

특히 ITIL 기반 도입 + 성숙도 모델(CMMI) + 국제표준(ISO/IEC 20000)을 병행하면 지속 가능한 IT 서비스 품질 체계를 구축할 수 있다.

참고 문헌 / 출처

AXELOS, ITIL Official Publications
ISO, ISO/IEC 20000, ISO/IEC 15504
Carnegie Mellon University, CMM/CMMI
Microsoft, MOF Documentation
IT Governance Institute 자료

코드 스멜(Code Smell)과 리팩토링(Refactoring)

그레고리오78 — Tue, 3 Mar 2026 18:49:36 +0900

1. 코드 속 악취 제거를 통한 코드 품질 향상, 리팩토링의 개요

1) 리팩토링(Refactoring)의 정의

Refactoring에서 정의한 바에 따르면,

리팩토링(Refactoring) 이란 *“소프트웨어의 외부 동작은 변경하지 않으면서 내부 구조를 개선하는 일련의 행위”*이다.

즉, 기능(Functional Behavior)은 유지하면서

가독성(Readability)
유지보수성(Maintainability)
확장성(Extensibility)
테스트 용이성(Testability)

을 향상시키는 구조적 개선 활동이다.

2) 리팩토링의 목적

구분	설명
가독성 향상	코드 이해 시간 단축
유지보수성 향상	변경 영향 범위 최소화
확장성 확보	신규 기능 추가 비용 절감
기술부채 감소	누적된 구조적 문제 해소
테스트 용이성 개선	단위 테스트 작성 및 자동화 수월

3) 코드 스멜(Code Smell)의 정의

Martin Fowler는 코드 스멜을 다음과 같이 정의하였다.

코드 스멜(Code Smell) 이란 “코드에 잠재된 구조적 문제를 암시하는 징후”이다.

오류(Bug)는 아님
설계상의 취약점 또는 유지보수 위험 신호
방치할 경우 기술부채 증가

즉, 코드 스멜은 리팩토링의 트리거(trigger) 역할을 한다.

2. 리팩토링 개념과 주요 기법

1) 리팩토링 개념

리팩토링은 단순한 코드 정리가 아니라,

객체지향 설계 원칙(SOLID)
응집도(Cohesion) 향상
결합도(Coupling) 감소
책임 분리(SRP)

등 소프트웨어 공학 원칙 기반 구조 개선 활동이다.

2) 기능 추가 관점에서의 리팩토링 효과

리팩토링 전	리팩토링 후
기능 추가 시 기존 코드 수정 다수 발생	확장 포인트 명확
버그 발생 가능성 증가	변경 영향 범위 축소
테스트 어려움	모듈 단위 테스트 가능
복잡도 증가	구조 단순화

결론: 리팩토링은 “기능 추가 속도를 높이기 위한 선행 투자”이다.

3) 리팩토링 주요 기법

기법	설명	적용 대상
Extract Method	긴 메소드를 분리	긴 메소드
Extract Class	큰 클래스를 역할별 분리	큰 클래스
Rename Method	의미 명확화	가독성 저하
Move Method	적절한 클래스로 이동	Feature Envy
Introduce Parameter Object	매개변수 객체화	너무 많은 인수
Replace Primitive with Object	기본형을 객체화	Primitive Obsession
Inline Method	불필요한 위임 제거	과도한 추상화
Remove Duplicate Code	중복 제거	중복된 코드

3. 코드 스멜의 종류

분류	코드 스멜	설명	대표 리팩토링
구조적 문제	중복된 코드 (Duplicated Code)	동일 로직 반복	Extract Method
복잡도 문제	긴 메소드 (Long Method)	지나치게 긴 함수	Extract Method
응집도 저하	큰 클래스 (Large Class)	역할 과다	Extract Class
인터페이스 문제	너무 많은 인수 (Long Parameter List)	가독성 저하	Introduce Parameter Object
변경 취약	Divergent Class	변경 이유가 여러 개	Extract Class
변경 파급	Shotgun Surgery	작은 변경에 다수 수정	Move Method
객체 책임 위반	Feature Envy	다른 객체 데이터에 집착	Move Method
데이터 구조 문제	Data Clumps	항상 함께 전달되는 데이터 묶음	Introduce Parameter Object
설계 미성숙	Primitive Obsession	기본형 과도 사용	Replace Primitive with Object

코드 스멜 관계 개념도

Code Smell 관계도

4. Refactoring vs Re-Engineering 비교

구분	Refactoring	Re-Engineering
목적	내부 구조 개선	시스템 전면 재구성
기능 변경	없음	가능
범위	모듈/클래스 단위	시스템 단위
위험도	낮음	높음
비용	상대적 저비용	고비용
적용 시점	지속적	시스템 노후화 시

핵심 차이: Refactoring은 점진적 개선, Re-Engineering은 근본적 재구축이다.

5. Refactoring 고려사항

1) 테스트 코드 선행 확보

자동화 테스트 없이는 위험
리팩토링 = 테스트 기반 활동

2) 작은 단위로 수행

Atomic Refactoring
Commit 단위 최소화

3) CI/CD 환경 활용

정적 분석(SonarQube 등)
코드 커버리지 관리

4) 과도한 리팩토링 주의

YAGNI 원칙 고려
기능 요구사항 우선

5) 팀 차원의 합의 필요

코딩 컨벤션 통일
설계 원칙 공유

결론

코드 스멜은 설계 붕괴의 초기 신호이며, 리팩토링은 지속 가능한 소프트웨어 개발을 위한 구조적 치료 행위이다.

애자일 개발
지속적 통합(CI)
테스트 주도 개발(TDD)

환경에서 리팩토링은 선택이 아닌 필수 전략이다.

출처

Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999
Clean Code – Robert C. Martin
Working Effectively with Legacy Code – Michael Feathers
IEEE Software Engineering Body of Knowledge (SWEBOK)

CMMI (Capability Maturity Model Integration)

그레고리오78 — Tue, 3 Mar 2026 18:23:43 +0900

1. 프로세스 개선 및 내재화의 핵심, CMMI의 개요

1) CMMI의 정의

CMMI는 조직의 프로세스 성숙도(Maturity) 및 능력 수준(Capability)을 체계적으로 평가·개선하기 위한 통합 프로세스 개선 프레임워크이다.

초기에는 Software Engineering Institute(SEI, Carnegie Mellon University)에서 개발되었으며, 현재는 ISACA 산하 CMMI Institute가 관리한다.

2) 등장 배경

구분	내용
1980~1990년대	미 국방부 소프트웨어 품질 문제 발생
해결 시도	SW-CMM 개발
한계	SW, 시스템, 인력 등 모델이 분리 운영
통합 필요성	중복·비일관성 제거 필요
결과	CMMI로 통합

3) CMMI의 특징

프로세스 중심(Process-centric)
정량적 관리 강조
단계적/연속적 표현 제공
조직 전체 개선 지향
SCAMPI 기반 공식 평가 체계

4) CMMI 참조 모델과 진화

구분	모델
SW 분야	Software Capability Maturity Model (SW-CMM)
시스템 공학	Systems Engineering Capability Maturity Model (SE-CMM)
인력 관리	People Capability Maturity Model (P-CMM)
획득 관리	Software Acquisition Capability Maturity Model (SA-CMM)
통합 제품 개발	Integrated Product Development Capability Maturity Model (IPD-CMM)
통합 결과	CMMI-DEV / CMMI-SVC / CMMI-ACQ
최신	CMMI V2.0 (2018~)

2. CMMI 구성도 및 구성요소

1) 구성도 (개념)

목표 구성도 · Goal Structure

2) 구성요소

구분	설명
PA (Process Area)	개선 대상 영역
SG	PA 달성을 위한 목표
SP	SG를 위한 실행 활동
GG	조직화 수준 목표
GP	제도화 활동
Maturity Level	조직 성숙도
Capability Level	PA별 능력 수준

3. CMMI 표현방법

1) 단계적 표현 (Staged Representation)

조직 전체 성숙도 중심
5단계 성숙도 모델

성숙도 레벨

Level	명칭	특징
1	Initial	비정형
2	Managed	프로젝트 단위 관리
3	Defined	조직 표준화
4	Quantitatively Managed	정량적 관리
5	Optimizing	지속 개선

2) 연속적 표현 (Continuous Representation)

PA별 Capability Level 측정

Capability Level	의미
0	Incomplete
1	Performed
2	Managed
3	Defined
4	Quantitatively Managed
5	Optimizing

4. 단계적 vs 연속적 표현 비교

구분	Staged	Continuous
기준	조직 성숙도	PA 능력 수준
결과	Maturity Level	Capability Level
적용 방식	순차적 개선	선택적 개선
활용	대외 인증	내부 전략 개선

5. CMMI의 PA (Process Areas)

1) 레벨별 PA 구성

ML	주요 PA
2	REQM, PP, PMC, SAM, MA, CM, PPQA
3	RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR
4	OPP, QPM
5	OID, CAR

6. CMMI vs SW-CMM vs SPICE

1) SW-CMM 비교

구분	SW-CMM	CMMI
범위	SW 중심	통합 모델
구조	단계적	단계+연속
확장성	제한적	우수

2) SPICE 비교

구분	ISO/IEC 15504 (SPICE)	CMMI
성격	국제 표준	모델 프레임워크
평가	Process Capability	Maturity/Capability
활용	글로벌 인증	미국 중심 확산

7. PSP, TSP와 CMMI

1) PSP

개인 단위 프로세스 개선 방법론

결함 예방
정량적 자기관리

2) TSP

팀 단위 프로세스 체계화

역할 기반 운영
데이터 기반 관리

3) 관계도

PSP · TSP · CMMI 관계도

8. CMMI 전환 전략 및 고려사항

1) 전환 전략

단계	전략
1	현재 프로세스 진단
2	목표 레벨 설정
3	GAP 분석
4	개선 로드맵 수립
5	시범 적용 후 확산
6	SCAMPI 평가

2) 고려사항

경영진 의지
문화 저항 최소화
문서화 과잉 방지
실무 연계 강화
자동화 도구 활용

9. 적용 효과 및 향후 전망

1) 적용 효과

구분	효과
품질	결함 감소
생산성	일정 예측성 향상
비용	재작업 감소
조직	표준화 정착

2) 향후 전망 및 대응

Agile·DevOps와 통합 필요
정량 데이터 기반 프로세스 자동화
AI 기반 품질 예측
CMMI V2.0 중심 경량화 적용

참고 문헌

CMMI Institute 공식 문서
ISACA CMMI V2.0 Guide
ISO/IEC 15504
Humphrey, W.S., Managing the Software Process
SEI Technical Reports

ISO/IEC 12207 (Software Life Cycle Processes)

그레고리오78 — Thu, 26 Feb 2026 08:05:17 +0900

1. 소프트웨어 프로세스 품질 표준, ISO/IEC 12207 의 개요

1) 정의

ISO/IEC 12207은 소프트웨어 생명주기(Software Life Cycle) 전반에 걸쳐 수행해야 할 **프로세스, 활동(Activity), 태스크(Task)**를 체계화한 국제 표준이다.

→ “무엇을 수행해야 하는가(What to do)”를 정의하는 프로세스 중심 표준.

2) 등장 배경 및 필요성

1980~90년대 대규모 SI/국방 프로젝트 증가
국가·기업 간 개발 표준 상이 → 품질 불균형
ISO 9000 기반 품질경영 체계의 SW 영역 구체화 필요
계약 기반 프로젝트에서 획득자–공급자 간 공통 기준 필요

3) 특징

생명주기 전 단계 포괄
계약 중심(획득/공급 프로세스 포함)
Tailoring(조정) 가능
프로세스 기반 품질관리 체계
ISO 9000 품질경영 시스템과 연계 가능

4) ISO 12207 프로세스 구조 개요

조직·기본·지원 프로세스의 계층적 관계와 상호 작용 구조

2. ISO 12207의 구성 및 구성요소

ISO 12207은 크게 기본, 지원, 조직 생명주기 프로세스로 구성된다.

■ 통합 프로세스 표 (SDLC·품질·조직 관점 통합)

구분	프로세스	목적	SDLC 관점	품질 관점
기본	획득(Acquisition)	외부 SW 획득 관리	계획/요구	계약 품질 확보
	공급(Supply)	고객 요구 충족	개발 수행	납품 품질
	개발(Development)	SW 설계·구현	분석~구현	제품 품질
	운영(Operation)	시스템 운영	운영	서비스 품질
	유지보수(Maintenance)	변경·개선	유지	지속 품질
지원	문서화	산출물 기록	전 단계	추적성
	형상관리	변경 통제	전 단계	무결성
	품질보증(QA)	프로세스 적합성	전 단계	프로세스 품질
	검증(Verification)	산출물 검증	단계별	적합성
	확인(Validation)	사용자 요구 충족 확인	시험	사용성
	합동검토(Joint Review)	이해관계자 검토	단계별	리스크 감소
	감사(Audit)	독립적 평가	전 단계	준수성
	문제해결(Problem Resolution)	결함 처리	전 단계	품질 개선
조직	관리(Management)	프로젝트 관리	계획/통제	성과 관리
	기반구조(Infrastructure)	개발환경 제공	전 단계	효율성
	개선(Process Improvement)	프로세스 개선	조직 차원	성숙도 향상
	훈련(Training)	인력 역량 강화	조직 차원	품질 확보

■ 구성도 (개념도)

조직 · 기본 · 지원 프로세스의 계층 구조와 상호 관계

3. ISO 12207과 연관 품질모델 비교

1) QM (Quality Management) 관계

구분	목적	특징
ISO 9000	조직 품질경영체계	경영 중심
ISO 12207	SW 생명주기 프로세스 정의	수행 중심
ISO/IEC 15504 (SPICE)	프로세스 능력 평가	성숙도 측정

2) 품질평가 모델 관계도

품질경영 → SW 생명주기 → 프로세스 성숙도로 이어지는 ISO 표준 체계

3) ISO 12207 vs SPICE(15504) 비교

구분	ISO 12207	ISO 15504 (SPICE)
성격	프로세스 정의	프로세스 평가
목적	수행 기준 제시	능력 수준 측정
결과	표준 프로세스 수립	Level 0~5 등급
활용	개발 표준 수립	프로세스 개선

4. ISO 12207의 품질 특성

ISO 12207 자체는 품질 특성을 직접 정의하지는 않으나, 다음 품질 확보 체계를 지원한다.

프로세스 준수성
추적성(Traceability)
형상 무결성
검증·확인 체계
지속적 개선 체계

(참고: 제품 품질 특성은 ISO/IEC 25010 계열에서 정의)

5. ISO 12207 활용 방안 및 한계점

1) 활용 방안

SI 프로젝트 표준 프로세스 수립
공공사업 RFP 대응 체계 구축
DevOps 프로세스 정립 시 기준 프레임워크 활용
ISO 15504 기반 프로세스 성숙도 평가 연계
품질보증 조직 설계 기준

→ 특히 대규모 MSA 기반 프로젝트에서 프로세스 표준화 + DevOps 자동화 체계 수립 시 적용 가치 높음

2) 한계점

구분	내용
문서 중심	Agile/DevOps 환경과 일부 충돌
Tailoring 필요	조직 특성 반영 필수
비용 증가	중소 프로젝트에는 과도
추상적 정의	구체적 방법론은 별도 필요

■ 종합 정리

구분	핵심
성격	SW 생명주기 국제 표준
구조	기본 + 지원 + 조직 프로세스
연계	ISO9000, ISO15504
목적	프로세스 표준화 및 품질 확보
활용	공공·대규모 SI 프로젝트
한계	Agile 환경과 조정 필요

■ 참고 출처

ISO/IEC 12207:2017 Software life cycle processes
ISO/IEC 15504 (SPICE)
ISO 9000 Quality Management Systems

SLM(Service Level Management)

그레고리오78 — Wed, 25 Feb 2026 18:38:12 +0900

1. SLA 기반 및 개선을 통한 서비스 수준 관리 체계, SLM의 개요

1.1 SLM(Service Level Management)의 정의

SLM(Service Level Management)은 고객과 합의한 **SLA(Service Level Agreement)**를 기반으로 IT 서비스의 품질을 정의·측정·모니터링·개선하는 지속적 서비스 품질 관리 체계이다.

목적: 비즈니스 요구사항에 부합하는 서비스 품질 보장
기준: SLA에 명시된 서비스 수준 목표(SLO)
활동: 협의 → 정의 → 측정 → 보고 → 개선(CSI)

IT 서비스 관리 프레임워크인 ITIL 에서 SLM은 핵심 프로세스로 정의되며, 서비스 제공자와 고객 간의 신뢰 기반 운영체계를 구축하는 역할을 수행한다.

1.2 SOW, SLA, SLM의 관계

구분	SOW (Statement of Work)	SLA (Service Level Agreement)	SLM (Service Level Management)
개념	수행 업무 범위 정의 문서	서비스 품질 수준에 대한 계약	SLA를 운영·관리·개선하는 관리 체계
목적	무엇을 할 것인가	어느 수준으로 제공할 것인가	약속된 수준을 어떻게 유지·개선할 것인가
관점	프로젝트/업무 범위	품질 목표(정량 지표)	운영 관리 프로세스
예시	“24시간 모니터링 제공”	“가용성 99.9% 이상 유지”	월간 SLA 리포트, 위반 원인 분석 및 개선
책임 주체	계약 당사자	서비스 제공자	IT 운영 조직

SOW → SLA → SLM 구성도

업무 범위 정의에서 서비스 수준 계약, 운영·관리·개선 체계로 이어지는 서비스 관리 흐름

2. SLM 개념도 및 구성요소

2.1 SLM 개념도

비즈니스 요구사항에서 지속적 개선(CSI)까지 이어지는 서비스 수준 관리 사이클

2.2 SLM 구성요소

구성요소	설명	주요 산출물
서비스 카탈로그	제공 서비스 목록 및 범위 정의	Service Catalog
SLA / SLO	서비스 수준 계약 및 목표	SLA 문서
KPI	성과 측정 지표	KPI 정의서
모니터링 시스템	실시간 서비스 상태 측정	대시보드
리포팅 체계	SLA 이행 현황 보고	월간 SLA Report
개선 프로세스	위반 원인 분석 및 재발 방지	개선 계획서
지원 프로세스	Incident/Problem/Change 관리	ITSM 연계 기록

3. ITIL에 의한 SLM의 프로세스

ITIL 기준 SLM은 다음 흐름으로 운영된다.

단계	주요 활동	연계 프로세스
① 요구 분석	비즈니스 요구사항 수집	BRM
② SLA 설계	KPI/SLO 정의	Service Design
③ 합의 및 계약	고객과 SLA 협상	Supplier Management
④ 모니터링	가용성, 성능 측정	Availability / Capacity
⑤ 보고	정기 SLA 리포트 작성	Reporting
⑥ 개선	위반 분석 및 개선	CSI (Continual Service Improvement)

ITIL v3에서는 Service Design 영역에 포함되며, ITIL 4에서는 Service Value System(SVS) 관점에서 지속적 가치 창출 체계로 확장된다.

4. SLM 구축 시스템 기능

SLM 시스템은 일반적으로 다음 기능을 포함한다.

기능 영역	상세 기능
SLA 관리	SLA 등록/수정/이력관리
KPI 관리	가용성, 응답속도, MTTR 등 지표 설정
실시간 모니터링	서버, 네트워크, 애플리케이션 상태 수집
자동 경보	임계치 초과 시 알림
리포트 자동화	월간/분기 SLA 통계 보고
위반 분석	Root Cause Analysis
대시보드	경영진용 KPI 시각화
ITSM 연계	Incident/Problem/Change 자동 연동

MSA·클라우드 환경에서는 다음 도구들과 연계된다:

APM(Application Performance Monitoring)
로그 분석 시스템
Cloud Monitoring
DevOps 파이프라인

5. 효과적인 SLM 구축 방안

5.1 전략적 접근

구분	실행 방안
비즈니스 정렬	SLA를 기술 중심이 아닌 비즈니스 영향 기준으로 정의
현실적 목표 설정	측정 가능하고 달성 가능한 SLO 설정
자동화 기반 구축	수동 보고 지양, 모니터링 자동화
정기 리뷰 체계	월간 SLA Review 회의
KPI 최소화	핵심 지표 중심 관리
지속적 개선	CSI 프로세스 내재화

5.2 MSA·클라우드 환경에서의 SLM

현대 IT 환경에서는 다음 요소가 중요하다.

API Gateway 기반 응답속도 측정
Auto Scaling 환경에서의 동적 가용성 관리
SLI/SLO 기반 Site Reliability Engineering(SRE) 적용
Observability(Logging, Metrics, Tracing) 체계 확립

결론

SLM은 단순한 SLA 모니터링 활동이 아니라,

비즈니스 요구사항 → SLA 정의 → 측정 → 보고 → 개선
로 이어지는 지속적 가치 관리 체계이다.

특히 클라우드·MSA 환경에서는 정량적 지표 기반의 자동화된 SLM 체계가 필수적이며, ITIL 기반 프로세스와 DevOps 도구의 통합이 성공 요인이다.

참고 자료

ITIL Foundation Handbook
AXELOS, ITIL 4 Managing Professional
ISO/IEC 20000 (IT Service Management Standard)
Gartner IT Service Management Framework 자료

SOW (Statement of Work, 작업명세서)

그레고리오78 — Wed, 25 Feb 2026 18:29:11 +0900

※ 일반적으로 SOW는 State of Work가 아니라 Statement of Work의 약어로 사용된다.
계약 기반 IT 서비스, SI 프로젝트, 아웃소싱, 클라우드 운영계약 등에서 핵심 문서로 활용된다.

1. 서비스 수준 관리를 위한 작업명세서, SOW의 개요

1.1 SOW(Statement of Work)의 정의

SOW(Statement of Work)는 계약에 근거하여 수행될 업무 범위, 산출물, 일정, 품질 기준, 책임, 검수 기준 등을 명확히 기술한 공식 문서이다.

즉,

“무엇을, 어디까지, 어떤 기준으로, 누가 책임지고 수행하는가”를 명문화한 실행 중심 계약 문서

특히 IT 서비스 관리 및 아웃소싱 환경에서는 SOW가 SLA의 기반 문서가 된다.

1.2 SOW의 필요성

SOW는 다음과 같은 목적을 가진다.

구분	필요성	설명
범위 명확화	Scope Creep 방지	요구사항 확장 및 무분별한 변경 통제
책임 구분	책임소재 명확화	발주사/수행사 간 분쟁 예방
품질 기준 정의	서비스 기준 명확화	SLA 수립의 기준 문서
비용 통제	계약금액 합리화	추가 과업 발생 시 근거자료
일정 관리	프로젝트 통제	일정, 마일스톤 명확화
리스크 관리	사전 예방	예외사항 및 가정 명시

특히 SI·공공 프로젝트에서는 분쟁 예방 문서로서의 기능이 매우 중요하다.

1.3 SOW / SLA / SLM의 관계

SOW : 무엇을 수행할 것인가 (Work 범위 정의)
SLA : 어느 수준으로 제공할 것인가 (Service Level 정의)
SLM : SLA를 관리·측정·개선하는 활동 (관리 프로세스)

관계 구조도

구분	SOW	SLA	SLM
목적	작업 범위 정의	서비스 수준 정의	서비스 수준 관리
성격	계약 기반 실행 문서	품질 기준 문서	관리 프로세스
주요 내용	범위, 산출물, 일정, 책임	가용성, 응답시간, 장애복구	모니터링, 리포트, 개선
시점	계약 체결 시	운영 개시 전	운영 기간 동안
관점	수행 중심	품질 중심	관리·통제 중심

2. SOW의 구성 및 구성항목

2.1 SOW의 구성도

서비스 수행 범위 · 일정 · 산출물 · 기준을 정의하는 10가지 핵심 구성 요소

2.2 SOW 구성요소 및 사례

대분류	구성요소	주요 내용	예시(IT 운영/클라우드 환경)
계약 기본정보	목적 및 배경	계약 목적, 사업 배경	AWS 기반 MSA 운영
업무 범위	Scope 정의	포함/제외 범위	Gateway, Auth, Batch 운영
산출물	Deliverables	보고서, 코드, 운영문서	월간 운영보고서, 장애보고서
일정	Milestone	단계별 일정	구축 3개월, 운영 1년
역할 책임	R&R	발주사/수행사 구분	장애 1차 대응 수행사
서비스 기준	SLA 기준	가용성, 응답시간	99.9% 가용성
변경관리	Change Control	변경 요청 절차	CR 승인 후 반영
보안	Security	접근통제, 데이터보호	VPN, IAM 정책
비용	Price	정액/시간당	월 3,000만원
검수	Acceptance	검수 기준	SLA 달성률 95% 이상
리스크	Risk	가정, 예외사항	클라우드 장애 제외

2.3 관점별 SOW의 역할

① 서비스 사용자(발주사) 측면

역할	설명
기대 수준 명확화	요구사항 문서화
분쟁 방지	계약 근거 확보
비용 통제	추가 과업 통제
성과 평가	SLA 평가 기준

② 서비스 제공자(수행사) 측면

역할	설명
과업 범위 보호	과도한 요구 방지
리스크 통제	책임 범위 명확화
수익 보호	추가 작업 비용 청구 근거
운영 기준 확보	SLA 기준 설정

3. SOW 작성 시 고려사항

3.1 핵심 고려 요소

항목	고려사항
범위 명확성	모호한 표현 금지 (“적절히”, “가능한 한”)
측정 가능성	KPI는 정량적 수치로 명시
책임 구분	RACI 모델 적용 권장
변경관리	Change Request 절차 명확화
SLA 연계	SLA와 충돌하지 않도록 정합성 확보
법적 검토	계약법 및 손해배상 조항 검토
가정 명시	전제조건 및 제외사항 명확히 작성

3.2 실무적 체크리스트

업무 범위와 요구사항 명세서(RS) 일치 여부
산출물 형식까지 명시했는가?
SLA와 KPI가 정량화되어 있는가?
장애 범위 정의가 명확한가?
클라우드 사업자 책임 구분이 명확한가?
보안/개인정보 보호 조항이 포함되어 있는가?
분쟁 발생 시 기준 문장으로 사용 가능한가?

4. SOW의 전략적 중요성 (MSA·클라우드 환경 관점)

특히 다음과 같은 환경에서 SOW는 더욱 중요하다.

MSA 기반 분산 서비스 구조
AWS/Azure/Naver Cloud 혼합 환경
DevOps 기반 지속 배포 환경
24×7 글로벌 서비스 운영

이 경우 SOW에는 다음이 반드시 포함되어야 한다.

서비스별 책임 경계 (Gateway / Auth / Batch 등)
클라우드 장애 시 책임 범위
데이터 백업 및 복구 기준 (RPO / RTO)
보안 사고 대응 체계
로그 보관 정책

5. 결론

SOW는 단순한 계약 부속 문서가 아니라,

프로젝트 통제의 기준 문서이며, 서비스 품질 관리의 출발점이다.

특히 SI·공공·클라우드·MSA 환경에서는 SOW → SLA → SLM의 구조를 체계적으로 설계해야 안정적인 운영이 가능하다.

6. 참고 문헌

Project Management Institute, PMBOK Guide
AXELOS, ITIL Service Design
International Organization for Standardization, ISO/IEC 20000 (IT Service Management)
대한민국 기획재정부, 공공사업 계약지침
한국정보화진흥원(NIA), 정보시스템 구축·운영 표준 가이드

SLA(Service Level Agreement)

그레고리오78 — Wed, 25 Feb 2026 07:58:18 +0900

1. IT 서비스 수준 고객 협약서, SLA의 개요

1) SLA(Service Level Agreement)의 정의

SLA(Service Level Agreement)는 서비스 제공자(Service Provider)와 고객(Customer) 간에 IT 서비스의 품질 수준, 측정 기준, 책임 범위, 보상체계 등을 명시한 공식 계약 문서이다.

IT 서비스의 정량적 목표(SLO) 를 명시
측정 방법, 보고 방식, 위반 시 보상체계(Penalty/Service Credit) 포함
ITSM 체계 내에서 SLM(Service Level Management) 활동의 핵심 산출물

SLA는 “서비스 결과에 대한 품질 계약”이며,
SOW(Statement of Work)는 “업무 범위에 대한 수행 계약”이라는 점에서 구분된다.

2) SLA의 필요성

구분	내용
서비스 품질 명확화	가용성, 응답시간, 복구시간 등을 수치화
분쟁 예방	책임과 기준을 사전 명문화
성과 기반 운영	정량 지표 기반 서비스 관리
고객 신뢰 확보	객관적 품질 보증 체계 구축
지속적 개선 기반	KPI 기반의 품질 개선 구조 확립

2. SLA의 개념도 및 구성요소

1) SLA 개념도

2) SLA 구성요소

구분	구성요소	설명	관련 개념
계약 구조	계약 목적	서비스 범위 및 목표 정의	SOW
	서비스 범위	제공 서비스 상세 내역	ITSM
서비스 수준	SLO (Service Level Objective)	가용성 99.9% 등 정량 목표	KPI
	SLA 지표	가용성, MTTR, 응답시간 등	운영지표
관리 체계	SLM	SLA 관리 프로세스	ITIL
	측정/보고 체계	월간 보고, 대시보드 등	Monitoring
책임 및 역할	R&R 정의	발주자/수주자 책임 범위	Governance
보상체계	Penalty	위반 시 금전적 감액	Service Credit
	Incentive	목표 초과 시 보상	성과보상

3. SLA 절차 및 SLA 관리 주요지표

1) SLA 절차

단계	설명	주요 산출물
① 요구사항 수집	고객 요구 분석	SLR
② SLO 정의	정량 목표 수립	KPI 정의서
③ SLA 계약 체결	목표·보상체계 명문화	SLA 문서
④ 모니터링	실시간 지표 측정	모니터링 리포트
⑤ 평가 및 보고	월/분기 단위 평가	SLA 보고서
⑥ 개선 활동	문제 개선 및 재협상	개선계획

2) SLA 관리 주요 지표

지표	정의	산식 예
가용성(Availability)	서비스 정상 운영 비율	(총시간-장애시간)/총시간 ×100
MTTR	평균 복구 시간	총 복구시간/장애건수
MTBF	평균 고장 간격	총 운영시간/장애건수
응답시간	요청 후 응답까지 시간	평균 응답시간
처리율(Throughput)	단위시간당 처리 건수	TPS
장애 처리 준수율	SLA 목표 내 처리 비율	목표내 처리건수/총건수

4. SLA 적용에 따른 기대 효과 및 고려사항

1) SLA 적용시 기대 효과

구분	기대 효과
품질 향상	정량 기준 기반 서비스 운영
비용 관리	성과 기반 비용 지불 구조
책임 명확화	R&R 명확화로 분쟁 감소
지속 개선	KPI 기반 품질 개선 선순환

2) SLA 계약 시 발주자 고려사항

항목	고려사항
지표의 현실성	과도한 가용성 요구(예: 99.999%)는 비용 급증
측정 방법 명확화	측정 도구, 기준 시점 정의
예외 조항	천재지변, 고객 귀책 등 명확화
보상체계	과도한 페널티는 장기 협력 저해

3) SLA 계약 시 수주자 고려사항

항목	고려사항
리스크 분석	장애 발생 확률 및 영향도 분석
인프라 이중화	HA, DR 구성 필요성 검토
모니터링 체계	실시간 지표 수집 시스템 구축
패널티 대비	Service Credit 한도 설정

4) SLA의 문제점 및 해결방안

문제점	설명	해결 방안
형식적 SLA	실질적 관리 미흡	SLM 체계 강화
과도한 지표	관리 복잡성 증가	핵심 KPI 중심 설계
책임 전가	장애 원인 분쟁	RACI 명확화
비용 증가	고가용성 요구	비용-품질 균형

SLA · SOW · SLM · SLO 관계 정리

구분	의미	목적
SLA	서비스 품질 계약	품질 보증
SOW	수행 범위 계약	업무 정의
SLM	SLA 관리 활동	지속적 품질 관리
SLO	서비스 목표 지표	정량 목표

결론

SLA는 단순한 계약 문서가 아니라, ITSM 체계 내에서 서비스 품질을 정량적으로 관리하는 핵심 관리 도구이다.

SLA는 SOW와 달리 성과 중심 계약
SLM 활동을 통해 지속적 개선 수행
SLO 기반 KPI 관리가 핵심
보상체계는 리스크 관리와 직결

MSA·클라우드 환경에서는 가용성, 응답속도, 장애복구시간이 핵심 지표가 되며, Auto Scaling, 모니터링, DevOps 체계와 연계되어야 실효성 있는 SLA가 된다.

참고 및 출처

AXELOS, ITIL Service Design & Service Operation
ISO, ISO/IEC 20000 (IT Service Management)
IEEE, IEEE 610.12 Software Engineering Terminology
PMI, PMBOK Guide (SOW 관련 정의)

요구공학 (Requirement Engineering)

그레고리오78 — Tue, 24 Feb 2026 08:03:58 +0900

1. 소프트웨어 요구사항의 품질만족을 위한 통합 프레임워크, 요구공학의 개요

1.1 요구공학(Requirement Engineering)의 정의

요구공학은 이해관계자(Stakeholder)의 요구를 체계적으로 식별·분석·명세·검증하고, 개발 전 생명주기 동안 이를 관리하는 공학적 활동이다.

즉, 단순한 요구 수집이 아니라:

사용자 요구 → 시스템 요구로 구조화
기능적/비기능적 요구로 분류
명세(SRS)로 문서화
추적성과 변경통제를 포함한 전주기 관리

를 포함하는 통합 관리 프레임워크이다.

대표 표준:

IEEE 29148 (Software Requirements Specification)
ISO/IEC 12207 (Software Life Cycle Process)

2. 요구공학 프로세스의 프레임워크 및 구성요소

2.1 요구공학 프로세스 프레임워크

2.2 통합 구성요소 정리

구분	주요 활동	산출물	핵심 키워드
타당성 분석	사업성/기술성 검토	타당성 보고서	ROI, Risk
요구 추출	인터뷰, 워크숍	요구 목록	사용자 요구
요구 분석	모델링, 충돌 해결	분석 모델	기능/비기능
요구 명세	SRS 작성	소프트웨어 명세서	기준선(Baseline)
요구 검증	리뷰, 프로토타입	검증 보고서	검증가능성
요구 관리	변경통제, 추적관리	추적 매트릭스	Traceability

3. 요구공학 프로세스 단계별 상세

3.1 요구사항 타당성 분석 단계

구분	설명
기술적 타당성	기술 구현 가능 여부
경제적 타당성	비용 대비 효과
운영적 타당성	조직 적용 가능성
법·규제 타당성	규정 준수 여부

3.2 요구사항 추출 프로세스

기법	설명
인터뷰	이해관계자 직접 질의
설문	정량적 의견 수집
워크숍	공동 요구 정의
프로토타이핑	시각화 기반 요구 구체화
문서 분석	기존 시스템 분석

3.3 요구사항 관점별 분석

구분	설명	예시
사용자 요구	비전·목표 중심	“구매 승인 기능 필요”
시스템 요구	구현 가능 수준	“3단계 승인 워크플로우 구현”
기능적 요구	시스템 동작	로그인, 결제 처리
비기능적 요구	품질 속성	성능, 보안, 확장성

3.4 요구사항 명세서(SRS)의 특징

항목	설명
동의 기준	이해관계자 합의
기준선(Baseline)	변경 통제 기준 문서
명확성	중의성 제거
추적성	요구→설계→코드→테스트 연결

3.5 요구사항 명세서 작성 원리

원리	설명
명확성	애매모호 표현 금지
완전성	누락 없음
검증가능성	테스트 가능
일관성	상호 충돌 없음
수정 용이성	구조화 문서
추적 가능성	ID 기반 관리
개발 후 이용성	유지보수 활용 가능

3.6 요구사항 명세서 항목

구분	주요 내용
기능적 요구사항	시스템 동작 정의
비기능적 요구사항	성능, 보안, 가용성, 확장성, 사용성
인터페이스 요구	외부 시스템 연계
제약 조건	기술/정책/법적 제약

3.7 요구사항 검증

정의: 요구사항이 올바르게 정의되었는지 확인하는 활동

검증 기준	방법
정확성	전문가 리뷰
완전성	체크리스트
일관성	모델 검증
테스트 가능성	테스트 케이스 도출
현실성	프로토타입

3.8 요구사항 변경 관리

개요

요구사항은 프로젝트 진행 중 지속적으로 변경된다. 따라서 변경은 통제(Control)되어야 한다.

변경 관리 프로세스

단계	설명
변경 요청	Change Request 등록
영향 분석	일정/비용/품질 영향 평가
승인	CCB(Change Control Board)
반영	문서 및 시스템 수정
추적	변경 이력 관리

4. 요구공학 수행 시 고려사항 및 향후 전망

4.1 고려 사항

고려 요소	설명
이해관계자 다양성	글로벌/다부서 환경
애자일 환경	지속적 요구 변화
MSA 구조	서비스 단위 요구 분리
규제 대응	개인정보/보안 법규
자동화 도구	요구 추적 자동화

4.2 향후 전망

AI 기반 요구 자동 분석
자연어 요구 → 모델 자동 변환
DevOps 기반 요구-테스트 자동 연결
모델 기반 요구공학(MBRE) 확산
요구-코드 추적 자동화 도구 발전

요구공학 통합 정리 (핵심 요약 표)

영역	핵심 활동	주요 산출물	품질 요소	관리 요소
요구개발	추출·분석·명세·확인	SRS	명확성·완전성	기준선
요구관리	추적·변경	RTM	추적성	변경통제
요구유형	기능·비기능	요구 ID	검증가능성	영향도 분석

결론

요구공학은 단순 문서 작업이 아니라 소프트웨어 품질과 프로젝트 성공을 결정하는 핵심 공학 활동이다.

특히 MSA·DevOps·클라우드 환경에서는:

요구의 지속적 변경 관리
비기능 요구(성능·보안·확장성)의 정량화
요구-테스트 자동 연계

가 핵심 경쟁력이 된다.

참고 문헌

IEEE Std 29148-2018, Systems and Software Engineering — Life Cycle Processes — Requirements Engineering
ISO/IEC 12207
Karl Wiegers, Software Requirements
Ian Sommerville, Software Engineering
International Requirements Engineering Board CPRE Syllabus

Prototype Pattern 및 ODM(Ontology Definition Metamodel) 기반 메타 모델링

그레고리오78 — Mon, 23 Feb 2026 18:48:31 +0900

1. ODM(Ontology Definition Metamodel)의 개요

1.1 ODM의 정의

ODM(Ontology Definition Metamodel)은 Object Management Group(OMG)가 정의한 온톨로지 모델을 UML 기반으로 표현하기 위한 메타모델 표준이다.

ODM은

온톨로지를 UML 프로파일 형태로 정의
MOF 기반 메타모델 구조 사용
XMI를 통한 모델 교환 지원

즉, Semantic Web 기술과 모델 기반 개발(MDD)을 연결하는 표준이다.

1.2 Ontology의 정의

Ontology란:

특정 도메인의 개념, 관계, 제약조건을 형식적으로 정의한 명세

구성 요소:

Class (개념)
Property (속성/관계)
Individual (인스턴스)
Constraint (제약조건)

주요 기술:

1.3 ODM의 특징 · 목적 · 필요성

구분	내용	관련 표준 및 기술
정의	UML 기반 온톨로지 모델링 메타모델	UML, MOF
목적	Ontology ↔ UML 간 상호운용성 확보	XMI, XML
특징	프로파일 기반 확장	UML Profile
필요성	모델 기반 아키텍처(MDA) 환경에서 시맨틱 통합	RDF, OWL
확장성	Prototype Pattern 기반 메타모델 복제·확장 가능	MOF
제약정의	형식적 제약 조건 명세	OCL
논리표현	개념 논리 및 규칙 표현	CL

2. ODM 개념도 및 구성요소

2.1 ODM 개념도

OMG ODM Specification (ontologyDefinitionMetamodel) · MOF 2.0 기반 각 계층은 상위 계층의 언어로 기술(describe)되며, 아래로 갈수록 구체화됩니다.

2.2 ODM 계층구조 설명

메타 레벨	설명	기술
M3	메타메타모델	MOF
M2	ODM 메타모델	UML Profile
M1	도메인 온톨로지 모델	UML
M0	실제 데이터	RDF, XML

2.3 Prototype Pattern의 구성요소

Design Patterns: Elements of Reusable Object-Oriented Software 에 정의된 Prototype Pattern은 객체 복제를 통한 인스턴스 생성 패턴이다.

구성요소	설명	ODM과의 연관성
Prototype	복제 대상 인터페이스	메타클래스
ConcretePrototype	실제 구현 클래스	Ontology Class
Client	복제 요청자	모델 생성기
clone()	복제 메커니즘	메타모델 인스턴스화

ODM과 Prototype의 연결

ODM은 메타모델 기반 복제 구조
Ontology 모델은 UML Class를 기반으로 복제/확장
MOF 기반 계층은 Prototype 구조와 유사한 계층적 인스턴스화

3. ODM의 역할과 기능

3.1 ODM 기능 메커니즘 구성도

OMG ODM Specification · XMI 2.x · W3C OWL 2 / RDF 1.1 UML 표기법 → XMI 직렬화 → OWL 온톨로지 → 시맨틱 웹 서비스

3.2 ODM의 역할 및 효과

기능 영역	역할	효과	관련 기술
모델 통합	UML ↔ OWL 매핑	시스템 간 상호운용성 확보	XMI
시맨틱 확장	Ontology 기반 의미 모델링	데이터 일관성 향상	RDF
제약 정의	형식 제약 표현	모델 검증 자동화	OCL
논리 표현	개념 논리 표현	지식 추론 가능	CL
MDA 연계	CIM→PIM→PSM 확장	자동화 개발 지원	MOF
모델 재사용	Prototype 기반 모델 복제	생산성 향상	UML

4. ODM 관련 ISO 메타데이터 표준 및 구성도

ODM은 ISO/IEC 표준과 밀접한 관련이 있다.

표준	설명	ODM과의 관계
ISO/IEC 19505	UML 표준	ODM은 UML Profile 기반
ISO/IEC 19502	MOF 표준	ODM의 메타모델 기반
ISO/IEC 11179	메타데이터 레지스트리	의미 데이터 관리
ISO/IEC 19763	메타모델 프레임워크	온톨로지 관리
ISO/IEC 20944	ODM 표준	Ontology 모델링

ISO 메타데이터 계층 구조

5. 데이터 참조 모델링 (Reference Model)

Reference Model은 시스템 간 의미적 정합성을 확보하기 위한 상위 모델이다.

ODM 기반 Reference Model 구조

계층	모델 유형	설명	관련 기술
개념 모델	Conceptual	도메인 개념 정의	ER
논리 모델	Logical	관계 구조 정의	UML
시맨틱 모델	Ontology	의미·추론 가능 모델	OWL
물리 모델	Physical	저장 구조	XML

ER ↔ Ontology 비교

구분	ER 모델	Ontology 모델
목적	데이터 구조 설계	의미 표현
관계	단순 관계	추론 가능 관계
제약	구조 중심	논리 제약(OCL/CL)
표현	테이블 중심	RDF Triple

전체 통합 개념 구조도

결론

ODM은 단순한 온톨로지 정의 표준이 아니라,

MOF 기반 메타모델 확장
UML과 Semantic Web 기술 통합
Prototype Pattern과 유사한 메타계층 복제 구조
ISO 메타데이터 표준과 연계된 모델 기반 아키텍처 구성 요소

로 이해해야 한다.

특히 MDA, MDD, 지식관리, SW 현대화 관점에서 ODM은 구조적 모델링과 시맨틱 모델링을 연결하는 핵심 매개체이다.

출처

Object Management Group, Ontology Definition Metamodel (ODM) Specification
Design Patterns: Elements of Reusable Object-Oriented Software
W3C, RDF/OWL Specifications
ISO/IEC 19502 (MOF), ISO/IEC 19505 (UML), ISO/IEC 20944 (ODM)

Agile SCRUM과 XP(eXtreme Programming)

그레고리오78 — Sat, 31 Jan 2026 12:03:09 +0900

1. Agile SCRUM의 개요 및 특징

1-1. SCRUM의 개요

SCRUM은 반복적·점진적 개발을 위한 프레임워크(Framework)로, 고정된 역할(Role), 이벤트(Event), 산출물(Artifact)을 통해 복잡한 문제를 관리하는 데 초점을 둔다.

Sprint라는 짧은 개발 주기(보통 2~4주)
고객 가치 중심의 점진적 기능 제공
팀 자율성과 투명성 강조
관리·협업·의사결정 구조에 강점

✔ SCRUM은 “어떻게 코딩할 것인가”보다
“어떻게 협업하고 관리할 것인가”에 초점을 둔 방법론

1-2. SCRUM의 주요 특징

명확한 3대 역할
- Product Owner
- Scrum Master
- Development Team
정형화된 이벤트
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
투명한 백로그 기반 관리
경험적 프로세스 제어(Empiricism)
- 투명성(Transparency)
- 검사(Inspection)
- 적응(Adaptation)

2. XP(eXtreme Programming)의 개요 및 특징

2-1. 개요 (XP)

XP(eXtreme Programming)는 Agile 선언을 가장 기술적으로 극단화(eXtreme)한 방법론으로, 코드 품질·개발자 협업·즉각적인 피드백에 초점을 둔다.

요구사항 변경을 자연스러운 것으로 수용
기술 실천(Practice)을 핵심으로 함
“좋은 설계는 지속적인 리팩토링에서 나온다”는 철학

✔ XP는 “어떻게 설계하고, 어떻게 코딩할 것인가”에 가장 집중한 Agile 방법론

2-2. 주요 특징 (XP)

강력한 기술적 실천법
- Test-Driven Development (TDD)
- Pair Programming
- Continuous Integration (CI)
- Refactoring
고객과 개발자의 상시 협업
짧은 릴리즈 주기
단순한 설계(Simple Design) 지향

3. Agile SCRUM과 XP의 비교 (통합 표)

3-1. 공통점 및 차이점 비교

구분	SCRUM	XP
기본 성격	프로젝트 관리 프레임워크	개발 기술 중심 방법론
Agile 가치	고객 가치, 변화 수용, 협업	고객 가치, 변화 수용, 협업
반복 주기	Sprint (2~4주)	Iteration (1~2주)
핵심 초점	관리·협업·프로세스	코드 품질·기술 실천
역할 정의	명확 (PO, SM, Team)	비교적 단순
기술 규칙	강제하지 않음	강제 수준으로 권장
문서화	최소 필요 문서	최소 문서
변화 대응	Sprint 단위 반영	즉각적 반영
적합 팀 규모	중·대규모 팀	소규모 팀
대표 키워드	Backlog, Sprint, Review	TDD, Pair, Refactoring

4. Agile SCRUM과 XP의 장단점

4-1. Agile SCRUM의 장단점

구분	내용
장점	- 역할과 책임이 명확- 프로젝트 가시성 우수- 이해관계자 관리에 강함- 조직 확장성 우수
단점	- 기술 품질은 팀 역량에 의존- 형식적 운영 시 “회의 방법론” 전락 위험- 초기 학습 비용

4-2. XP의 장단점

구분	내용
장점	- 높은 코드 품질- 버그 감소 및 안정성 향상- 빠른 피드백과 릴리즈- 기술 부채 최소화
단점	- 개발자 숙련도 요구 높음- Pair Programming에 대한 거부감- 대규모 조직 적용 어려움

5. SCRUM + XP 결합 구성도

※ SCRUM은 프로젝트 관리 프레임워크를, XP는 구체적인 기술 실천 방법을 제공하여 상호 보완적으로 작동합니다.

✔ SCRUM = 관리 프레임워크
✔ XP = 기술 실행 엔진 → 실무에서는 SCRUM + XP 혼합 적용이 가장 안정적

6. 결론

6-1. 요약

SCRUM
- 협업과 관리에 강한 Agile 프레임워크
- SI·공공·대규모 조직에 적합
XP
- 코드 품질과 기술 실천에 특화
- 스타트업·소규모·기술 중심 조직에 적합
현대 Agile 실무
- SCRUM으로 프로젝트를 관리하고
- XP로 개발 품질을 보장하는 혼합 전략이 표준

6-2. 제언 (SI·MSA·DevOps 관점)

SI/공공 프로젝트
→ SCRUM 기반 + XP 일부 도입
MSA·DevOps 환경
→ SCRUM + XP + CI/CD 자동화
숙련 개발자 조직
→ XP 비중 확대
대규모 조직
→ SCRUM 기반 거버넌스 유지

7. 출처 및 참고문헌

Agile Manifesto
- https://agilemanifesto.org
Scrum Guide (Ken Schwaber, Jeff Sutherland)
- https://scrumguides.org
Extreme Programming Explained – Kent Beck
IEEE Software, Agile Development Practices
Martin Fowler – Agile & XP Practices
- https://martinfowler.com
PMI – Agile Practice Guide

지식검색메타모델(KDM, Knowledge Discovery Metamodel)

그레고리오78 — Sat, 31 Jan 2026 11:50:24 +0900

개요

KDM(Knowledge Discovery Metamodel)은 OMG(Object Management Group)가 표준화한 소프트웨어 지식 표현을 위한 메타모델로, 레거시 시스템 분석, 유지보수, 진단, 평가 및 소프트웨어 현대화(SW Modernization)를 체계적으로 지원하기 위해 설계되었다. KDM은 소스 코드, 데이터 구조, 아키텍처, 비즈니스 규칙 등을 기술 독립적이고 상호운용 가능한 모델로 표현함으로써 모델 기반 개발(MDD)과 자동화된 현대화를 가능하게 한다.

1. 유지보수, 진단, 평가 및 현대화를 위한 상호운용성 보장

1.1 KDM의 정의

KDM은 레거시 소프트웨어 자산을 구조적·의미적으로 분석하여 표준 메타모델(MOF 기반)로 표현하는 지식 표현 모델이다.

구분	내용
표준화 기관	OMG (Object Management Group)
기반 기술	MOF, UML, MDA
목적	레거시 시스템 이해, 분석, 현대화
적용 범위	코드, 데이터, 아키텍처, 비즈니스 로직

1.2 KDM의 필요성

기존 문제	KDM 필요성
문서 부재	코드 기반 자동 지식 추출
기술 종속성	기술 중립적 모델 제공
복잡한 레거시	구조적/계층적 모델링
현대화 리스크	사전 영향도 분석 가능

1.3 KDM의 목표

목표	설명
상호운용성	다양한 도구 간 모델 공유
재사용성	지식 자산의 장기 활용
자동화	분석·변환·이행 자동화
가시성	아키텍처 및 의존성 시각화

1.4 KDM의 특징

특징	설명
메타모델 기반	MOF 기반 구조
다계층 표현	코드~비즈니스 계층 포괄
UML 연계	UML Profile과 호환
MDA 연계	CIM/PIM/PSM 변환 지원

2. KDM의 아키텍처와 구성 요소

2.1 KDM 아키텍처 구성도

KDM은 기존 시스템의 지식을 발견하고 표현하기 위한 OMG 표준 메타모델입니다.

2.2 KDM의 주요 구성 요소

계층	설명
Code	소스 코드 구조 표현
Data	데이터베이스 및 파일 구조
Action	제어 흐름, 호출 관계
Structure	아키텍처 구조
Conceptual	비즈니스 개념
Platform	실행 환경 정보

2.3 KDM의 메타모델 계층 구조

※ KDM은 기존 소프트웨어 시스템의 지식을 추출하고 표현하기 위한 포괄적인 메타모델입니다. ※ 각 서브 메타모델은 시스템의 특정 관점(뷰)을 표현하며, 상호 연관되어 완전한 시스템 표현을 제공합니다.

3. KDM의 활용 사례 및 적용 방법

3.1 KDM을 활용한 소프트웨어 현대화 사례

As-Is	To-Be
Mainframe COBOL	Java/Spring MSA
Monolithic	Microservices
On-Premise	Cloud Native

3.2 KDM 적용 방법론

단계	설명
Reverse Engineering	코드 → KDM 모델
Knowledge Discovery	의존성·구조 분석
Target Modeling	목표 아키텍처 설계
Model Transformation	KDM → UML/DSL
Re-engineering	신규 시스템 구현

3.3 KDM 도구 및 기술

도구	기능
Eclipse MoDisco	코드 → KDM 추출
ADM Toolchain	현대화 자동화
UML Tools	모델 시각화
DSL Engines	도메인 특화 언어 변환

4. KDM의 장점과 한계

4.1 KDM의 장점

항목	내용
표준성	OMG 국제 표준
자동화	분석·변환 자동화
확장성	다양한 언어·플랫폼 지원
재사용	지식 자산 축적

4.2 KDM의 한계 및 도전 과제

한계	설명
학습 난이도	메타모델 복잡
도구 의존	상용/전문 도구 필요
실시간성	동적 분석 한계
최신 기술 대응	Cloud/Serverless 표현 한계

5. 결론 및 향후 전망

5.1 KDM의 중요성 재확인

KDM은 단순한 코드 분석 모델이 아니라, 소프트웨어 공학·아키텍처·지식관리를 통합하는 핵심 메타모델이다.

5.2 KDM의 향후 발전 방향

방향	설명
Cloud 확장	Cloud Native 메타모델 연계
AI 결합	자동 지식 추론
DSL 강화	도메인 중심 현대화
DevOps 연계	CI/CD 기반 모델 활용

5.3 출처 및 참고 문헌

OMG, Knowledge Discovery Metamodel (KDM) Specification
OMG, Architecture-Driven Modernization (ADM)
ISO/IEC 19506: KDM Standard
Eclipse MoDisco Documentation
Model Driven Architecture (MDA) Guide

SPEM(Software Process Engineering Metamodel)

그레고리오78 — Sat, 31 Jan 2026 11:16:11 +0900

핵심 키워드

OGM(= OMG), 프로세스, 메타모델, Process Structure, Process Behavior, Managed Content, Method Content, Process with Methods, Method Plugin

1. UML을 이용한 프로세스 모델링 표준, SPEM의 개요

1.1 SPEM 정의

구분	내용
정식 명칭	Software Process Engineering Metamodel
표준 기관	OMG(Object Management Group)
목적	소프트웨어 개발 프로세스와 방법론(Method)을 UML 기반으로 구조화·정형화
표준 버전	SPEM 2.0
표현 수단	UML Profile + MetaModel

SPEM은 “소프트웨어 개발 프로세스를 모델링하기 위한 메타모델”이다.

1.2 SPEM의 특징

구분	내용
UML 기반	UML Activity, Class, Package 개념을 확장
메타모델	프로세스 자체를 정의하는 상위 모델
분리 설계	Process와 Method Content 분리
재사용성	Method Plugin을 통한 조립식 구성
표준화	조직/도구 간 프로세스 상호운용성 확보

2. SPEM 메타모델의 아키텍처 및 주요 구성 요소

2.1 SPEM 메타모델 아키텍처 구성도

※ SPEM: Software & Systems Process Engineering Metamodel

2.2 주요 구성 요소 설명

구분	구성 요소	주요 하위 요소	역할 및 설명	핵심 키워드
공통기반	Core Model	RoleTaskWorkProductGuidance	SPEM의 최하위 공통 메타모델로, 모든 프로세스 및 방법 요소의 기본 단위를 정의함	Role, Task, WorkProduct
프로세스 구조	Process Structure	PhaseIterationActivityTask Use	프로세스를 단계·반복·작업 단위로 구조화하며 “무엇을 언제 수행하는가”를 정의	Process Structure
프로세스 행위	Process Behavior	Control FlowDependencyParallel FlowCondition	UML Activity 기반으로 작업 간 흐름, 병렬 처리, 조건 분기를 정의	Process Behavior
관리계층	Managed Content	Process PackageMethod Package	프로세스와 Method Content를 연결·관리하며 재사용 및 일관성을 보장	Managed Content
방법론 자산	Method Content	Task DefinitionRole DefinitionWork Product DefinitionGuidance	특정 프로세스에 종속되지 않는 재사용 가능한 방법론 자산을 정의	Method Content
프로세스 적용	Process with Methods	Task UseRole UseWork Product Use	Method Content를 실제 프로세스에 매핑하여 실행 가능한 프로세스로 구성	Process with Methods
확장·조립 단위	Method Plugin	Method ContentProcess ModelGuidance	방법론과 프로세스를 패키지화하여 프로젝트·조직 단위로 조합 및 확장 가능	Method Plugin

3. SPEM을 활용한 프로세스 모델링 방법론

3.1 프로세스 모델링 단계

단계	설명
1단계	Method Content 정의
2단계	Process Structure 설계
3단계	Process Behavior 설계
4단계	Plugin 조립
5단계	검증 및 표준화

3.2 UML 다이어그램 작성법

UML 다이어그램	SPEM 활용
Class Diagram	Role, Task, WorkProduct
Activity Diagram	Process Behavior
Package Diagram	Method Plugin 구성

3.3 사례 연구 (공공 SI 프로젝트 개발 프로세스 예)

단계	Task	산출물
분석	요구사항 분석	요구사항 정의서
설계	아키텍처 설계	설계서
개발	기능 구현	소스코드
테스트	통합 테스트	테스트 결과서

3.4 실제 프로세스 모델링 예시

※ 각 활동(Activity)은 역할(Role)에 의해 수행되며, 산출물(Work Product)을 생성합니다. ※ 개발 후 단위 테스트는 병렬로, 통합 테스트는 순차적으로 진행됩니다.

4. SPEM의 확장 및 응용

SPEM의 확장성은 Method Plugin을 중심으로, 표준 프로세스를 유지하면서도 Agile·MSA·DevOps 같은 현대 개발 패러다임을 수용할 수 있게 한다.

구분	항목	개념/구성요소	확장·적용 방식	적용 효과	대표 사례
확장 단위	Method Plugin	Method Content + Process Model + Guidance를 하나의 패키지로 구성	프로젝트·조직 단위로 Plugin을 조합하여 사용	재사용성 향상표준 프로세스 유지	Scrum PluginDevOps Plugin
확장 메커니즘	SPEM 확장 방법	UML Profile 확장Custom Task / Role 정의Process Template	조직·도메인 특화 요소를 메타모델에 추가	도메인 적합성 향상표준과 커스터마이징의 공존	공공 SI 전용 Task보안 점검 Role
조립 방식	Process with Methods	Method Content를 실제 Process에 매핑	Task Use / Role Use를 통해 실행 프로세스 구성	실행 가능 프로세스 확보	분석–설계–개발–테스트 프로세스
Agile 도메인	Agile / Scrum 적용	Sprint, Backlog, Review를 Task로 모델링	Scrum Plugin으로 반복 개발 프로세스 구성	경량 프로세스반복·적응 강화	Scrum, XP
MSA 도메인	Microservices Architecture	서비스 단위 Task 및 독립 배포 프로세스	서비스별 Plugin 구성	독립성·확장성 확보	서비스별 개발·배포
DevOps 도메인	DevOps / CI·CD	Build, Test, Deploy Task	자동화 파이프라인을 Process Behavior로 표현	배포 자동화품질 안정화	Jenkins, GitOps
공공·SI 도메인	표준 개발 방법론	단계별 산출물 중심 프로세스	발주기관 표준 프로세스 Plugin화	감사 대응 용이문서 표준화	공공 정보화 사업
조직 확장	엔터프라이즈 적용	전사 공통 Plugin + 프로젝트별 Plugin	공통/개별 프로세스 분리 운영	조직 일관성 확보	대기업 SI 조직

핵심 요약 관점

Method Plugin
→ SPEM 확장의 핵심 단위
SPEM 확장 방법
→ UML Profile + Custom 요소
응용 도메인
→ Agile · MSA · DevOps · 공공 SI까지 범용 적용

5. SPEM 도구 및 지원 환경

SPEM 도구 선택의 기준은 “표준 준수 vs 확장성 vs 비용”이며, 공공·SI 환경에서는 EPF, 엔터프라이즈 환경에서는 RMC가 가장 많이 활용된다.

구분	도구명	유형	주요 기능	활용 방법	장점	한계	적용 환경
오픈소스	Eclipse Process Framework (EPF)	SPEM 전용	Method Content 정의Process 모델링Plugin 관리	Method 작성 → Process 구성 → Plugin 조립 → 웹 퍼블리싱	무료OMG SPEM 표준 준수공공 SI 적합	UI 노후화학습 곡선	공공 SI표준 프로세스
상용	IBM Rational Method Composer (RMC)	SPEM 전용	대규모 방법론 관리조직 표준화	조직 공통 방법론 설계 및 배포	확장성 우수엔터프라이즈 적합	고비용벤더 종속	대기업엔터프라이즈
상용 UML	Enterprise Architect	UML Tool	SPEM Profile 지원UML 기반 모델링	Class/Activity Diagram으로 프로세스 표현	UML 친숙통합 모델링	SPEM 전용 기능 제한	아키텍처 중심
오픈 방법론	OpenUP	SPEM 기반 방법론	경량 개발 프로세스 제공	템플릿 기반 적용	Agile 친화적	커스터마이징 제한	중소 규모
일반 UML 도구	MagicDraw / Visual Paradigm	UML Tool	UML Profile 확장	SPEM Profile 직접 정의	자유도 높음	SPEM 관리 기능 부족	연구·교육
문서화 도구	Wiki / Web Publisher	보조	프로세스 문서 배포	SPEM 산출물 웹 게시	접근성 높음	모델링 불가	전사 공유

도구 선택 가이드 요약

상황	추천 도구
공공·SI 표준 프로세스	Eclipse EPF
대기업·엔터프라이즈	IBM RMC
UML 중심 아키텍처	Enterprise Architect
Agile 경량 적용	OpenUP
교육·연구	UML Tool + SPEM Profile

6. 결론 및 향후 연구 방향

6.1 SPEM의 장점 및 한계

장점	한계
프로세스 표준화	초기 학습 비용
재사용성	모델링 복잡
도구 독립성	경량 프로젝트엔 과도

6.2 향후 연구 및 발전 방향

Agile/DevOps 친화적 단순화
MSA·클라우드 전용 SPEM Profile
자동화 도구(Git, CI/CD) 연계
AI 기반 프로세스 추천

6.3 참고 문헌 및 자료 (출처)

OMG, SPEM 2.0 Specification
OMG 공식 문서
https://www.omg.org/spec/SPEM/
Eclipse Process Framework (EPF)
https://www.eclipse.org/epf/
Philippe Kruchten, The Rational Unified Process
ISO/IEC 12207 Software Life Cycle Processes

Docker 설치 방법

그레고리오78 — Thu, 29 Jan 2026 12:12:44 +0900

1. 설치 및 등록

1.1 Docker & Docker Compose 설치

# root 계정으로 설치
sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

1.2 시스템 서비스 등록

# root 계정으로 실행
sudo systemctl enable docker --now
sudo systemctl status docker

1.3 서비스 계정(dockeruser)을 Docker 그룹에 추가

# root 계정으로 실행
sudo usermod -aG docker dockeruser

1.4 dockeruser 계정에서 운영

docker ps
docker compose up -d
docker compose logs -f

2. Docker 기반 개발 서버 구성

2.1 Frontend 서버 디렉토리 구조

/srv/frontend
├── user-web/
│   ├── logs/
│   └── config/
├── admin-web/
│   ├── logs/
│   └── config/
└── etc-web/
    ├── logs/
    └── config/

2.1.1 Frontend 서비스 디렉토리 생성

# root 계정으로 실행
sudo mkdir -p /srv/frontend/{user-web, admin-web, etc-web}
sudo mkdir -p /srv/frontend/{user-web, admin-web, etc-web}/logs
sudo mkdir -p /srv/frontend/{user-web, admin-web, etc-web}/config

2.2 Backend 서버 디렉토리 구조

/srv/backend
├── eureka/
│   ├── logs/
│   └── config/
├── gateway/
│   ├── logs/
│   └── config/
├── service1/
│   ├── logs/
│   └── config/
├── service2/
│   ├── logs/
│   └── config/
└── etc-service/
    ├── logs/
    └── config/

2.2.1 Backend 서비스 디렉토리 생성

# root 계정으로 실행
sudo mkdir -p /srv/backend/{eureka, gateway, service1, service2, etc-service}
sudo mkdir -p /srv/backend/{eureka, gateway, service1, service2, etc-service}/logs
sudo mkdir -p /srv/backend/{eureka, gateway, service1, service2, etc-service}/config

2.3 소유권(dockeruser) 위임

sudo chown -R dockeruser:dockeruser /srv/backend

2.3.1 dockeruser 계정을 docker 그룹에 추가

sudo usermod -aG docker dockeruser

2.3.2 dockeruser 계정으로 전환

su - dockeruser
cd /srv/msa

MDA(Model Driven Architecture)

그레고리오78 — Thu, 29 Jan 2026 10:53:51 +0900

메타모델 기반의 구현 공정 자동화와 MDA의 등장 배경

MDA(Model Driven Architecture)는 **OMG(Object Management Group)**가 제안한 표준 기반의 아키텍처 접근 방식으로, 소프트웨어 개발에서 **모델(Model)**을 중심 자산(Primary Artifact)으로 삼아 분석·설계·구현·운영 전 과정을 자동화·표준화하는 것을 목표로 한다.

기존 코드 중심 개발 방식은 플랫폼 종속성, 낮은 재사용성, 기술 변화에 따른 유지보수 비용 증가라는 한계를 가졌고, 이를 해결하기 위해 MOF 기반 메타모델, UML, 모델 변환, 자동 코드 생성을 핵심으로 하는 MDA가 등장하였다.

MDA 개념 구성도

1. 메타모델 기반의 구현 공정 자동화, MDA의 개요

1.1 MDA의 정의

구분	내용
정의	모델 중심 개발을 통해 플랫폼 독립성과 자동화를 확보하는 OMG 표준 아키텍처
핵심	CIM → PIM → PSM → Code 변환
목표	상호운용성, 재사용성, 구현 자동화

1.2 MDA의 구성 요소

구성 요소	설명
MOF	메타모델 정의를 위한 메타-메타 모델
UML	시스템 모델링 표준 언어
XMI	모델 교환을 위한 XML 기반 표준
CWM	데이터웨어하우스/BI 메타모델
CIM	비즈니스 관점 모델
PIM	플랫폼 독립 모델
PSM	플랫폼 종속 모델

1.3 MDA의 주요 개념

핵심 키워드	설명
상호운용성	표준 기반 모델 교환 및 연계
재사용성	PIM 중심의 모델 재사용
구현 자동화	모델 → 코드 자동 생성
UML Profile	도메인/플랫폼 확장 메커니즘

1.4 MDA의 이점과 한계

구분	내용
이점	생산성 향상, 품질 개선, 기술 변화 대응
한계	초기 학습 비용, 도구 의존성, 복잡한 모델 관리

1.5 MDA의 적용 사례

적용 분야	사례
공공 SI	전자정부 프레임워크 모델 기반 개발
금융	Core Banking 모델 표준화
제조	PLM/ERP 연계 모델

1.6 MDA와 관련된 표준 및 프레임워크

표준	설명
OMG MDA	MDA 전체 프레임워크
UML 2.x	모델링 표준
MOF 2.x	메타모델 정의
XMI	모델 교환

1.7 MDA 도구 및 기술

도구	기술
Eclipse EMF	MOF 기반 모델 프레임워크
Papyrus	UML/MDA 모델링
MagicDraw	상용 UML/MDA 도구
AndroMDA	Java 기반 코드 생성

1.8 MDA 개발 프로세스

1.9 MDA 모델링 기법

모델링 기법	설명
UML 다이어그램	클래스, 시퀀스, 컴포넌트
UML Profile	플랫폼/도메인 확장
DSL	특정 도메인 언어

1.10 MDA와 기존 개발방식 비교

구분	기존 방식	MDA
중심 자산	코드	모델
변경 대응	어려움	용이
자동화	제한적	높음

2. MDA 기반의 MDD 개발 방법론

2.1 MDD의 정의 및 개요

MDD(Model Driven Development)는 모델을 중심으로 개발을 수행하는 방법론의 총칭으로, MDA는 그중 OMG 표준 아키텍처이다.

2.2 MDD와 MDA의 관계

구분	MDD	MDA
성격	방법론	표준 아키텍처
범위	포괄적	OMG 기반

2.3 MDD 개발 프로세스

단계	내용
모델링	도메인/시스템 모델 정의
변환	모델 간 변환
생성	코드/설정 자동 생성

2.4 MDD 모델링 기법

UML
DSL
메타모델 기반 모델링

2.5 MDD 도구 및 기술

도구	설명
Xtext	DSL 개발
Acceleo	모델 → 코드
ATL	모델 변환

2.6 MDD 적용 사례

Spring 기반 CRUD 자동 생성
DB 스키마 → Entity 자동화

3. MDA와 MDD의 통합 및 활용 방안

3.1 통합 전략

MDA 구조 위에 MDD 프로세스 적용
CI/CD와 코드 생성 연계

3.2 상호 보완적 역할

MDA	MDD
표준 구조 제공	실천 방법 제공

3.3 활용 사례

대규모 MSA 표준 모델
멀티 플랫폼(Spring, .NET) 대응

3.4 미래 전망

AI 기반 모델 생성
Low-Code/No-Code 융합

4. PIM과 PSM의 개요

4.1 PIM 정의

구분	내용
특징	기술 독립적
목적	장기적 재사용

4.2 PSM 정의

구분	내용
특징	플랫폼 반영
예	Spring Boot, JPA

4.3 PIM–PSM 관계

4.4 변환 기법

규칙 기반 변환
템플릿 기반

4.5 활용 사례

PIM → Spring/JPA PSM

5. 모델 변환 및 코드 생성 기법

5.1 모델 변환 개요

구분	내용
M2M	모델 간 변환
M2T	모델 → 텍스트

5.2 변환 도구

도구	용도
ATL	M2M
QVT	OMG 표준

5.3 코드 생성 개요

반복 코드 제거
표준화된 산출물

5.4 코드 생성 도구

도구	설명
Acceleo	M2T
AndroMDA	Java 중심

5.5 적용 사례

Entity/Repository 자동 생성

6. MDA와 MDD의 도전 과제 및 향후 연구 방향

6.1 도전 과제

과제	설명
복잡성	모델 관리 난이도
도구 종속	벤더 락인

6.2 향후 연구 방향

AI + MDA
클라우드 네이티브 모델링
DevOps 연계 모델 자동화

결론

MDA는 MOF–UML–XMI–CIM/PIM/PSM으로 이어지는 메타모델 체계를 통해 소프트웨어 개발을 구조적으로 혁신한다. MDD와 결합될 때 MDA는 단순한 이론을 넘어 실질적인 생산성 향상과 품질 확보 수단이 되며, 특히 대규모 SI·공공·MSA 환경에서 강력한 효과를 발휘한다.

참고 문헌 및 출처

OMG, Model Driven Architecture (MDA) Guide
OMG, UML 2.x Specification
OMG, MOF 2.x Specification
Schmidt, D.C., Model-Driven Engineering
Eclipse Foundation, EMF Documentation

Redis 설치 절차

그레고리오78 — Wed, 28 Jan 2026 12:01:29 +0900

1. 사전 확인

cat /etc/rocky-release
# Rocky Linux release 9.6 (Blue Onyx)

sudo dnf install -y gcc make tcl
# Redis는 C로 빌드되므로 gcc, make 필수, tcl은 설치 테스트 시 필요

2. Redis Yum Repository 등록 및 스트림 활성화

2.1 Redis Repository 등록

sudo dnf install -y https://rpms.remirepo.net/enterprise/remi-release-9.rpm

2.2 스트림 활성화

sudo dnf module reset redis -y
sudo dnf module enable redis:remi-7.2 -y

3. Redis 설치 및 버전 확인

3.1 Redis 설치

sudo dnf install -y redis

3.1 Redis 버전 확인

redis-server --version

4. Redis 설정 변경

sudo vi /etc/redis/redis.conf

bind 0.0.0.0
protected-mode no
port 6379
requirepass mypassword
daemonize yes
supervised systemd

5. Redis 서비스 등록/자동 시작 및 상태 확인

sudo systemctl enable redis --now

sudo systemctl status redis

6. 방화벽 설정, 부팅 시 자동 실행 확인

sudo firewall-cmd --permanent --add-port=6379/tcp
sudo firewall-cmd --reload

sudo systemctl is-enabled redis

MongoDB(7.0.24) 설치 절차

그레고리오78 — Wed, 28 Jan 2026 11:56:05 +0900

1. 사전 확인

cat /etc/rocky-release
# Rocky Linux release 9.6 (Blue Onyx)

2. MongoDB Yum Repository 추가

2.1 MongoDB Yum Repository 생성

# mongodb-org-7.0.repo 생성 
sudo vi /etc/yum.repos.d/mongodb-org-7.0.repo

[mongodb-org-7.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/9/mongodb-org/7.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://pgp.mongodb.com/server-7.0.asc

2.2 MongoDB 설치

sudo dnf install -y mongodb-org

3. MongoDB 환경 설정

3.1 Port 및 접속 IP 확인

sudo vi /etc/mongod.conf

net:
  port: 27017
  bindIp: 0.0.0.0

3.2 MongoDB 재시작 및 확인

# MongoDB 재시작
sudo systemctl restart mongod

# 변경 확인
sudo ss -lntp | grep mongod

3.3 방화벽 Port 변경

sudo firewall-cmd --permanent --add-port=27017/tcp
sudo firewall-cmd --reload

4. 서비스 등록, 실행, 상태 확인

4.1 MongoDB 서비스 등록

sudo systemctl enable mongod

4.2 MongoDB 실행, 중지, 재시작, 상태 확인

# 실행
sudo systemctl start mongod
# 중지
sudo systemctl stop mongod
# 재시작
sudo systemctl restart mongod
# 상태 확인
sudo systemctl status mongod

5. 접속 및 보안 설정

5.1 접속

mongosh --port 27017

5.2 버전 확인

db.version()

5.3 보안 설정

// admin 비밀번호 설정
use admin;

db.createUser({
    user: 'admin',
    pwd: 'admin_password',
    roles: [ { role: 'root', db: 'admin' } ]
  })

5.4 MongoDB 설정 변경

sudo vi /etc/mongod.conf

security:
  authorization: enabled

# mongoDB 서비스 재시작
sudo systemctl restart mongod

# mongo 서비스 접속
mongosh --port 27017 -u admin -p --authenticationDatabase admin

6. DB 생성 및 접속 계정 생성

6.1 DB 생성

// Mongo 서비스 접속
use mydatabase

6.2 mydatabase 접속 계정 생성

db.createUser({
    user: 'user_name',
    pwd: 'user_name_password',
    roles: [ { role: 'readWrite', db: 'mydatabase' } ]
  })

개발서버(RockyLinux)에 MySQL(8.x) 설치

그레고리오78 — Wed, 28 Jan 2026 11:04:08 +0900

1. Linux 버전 확인

cat /etc/rocky-release
# Rocky Linux release 9.5 (Blue Onyx)

2. MySQL Yum Repository 추가

2.1 MySQL Yum Repository 설정

# wget 설치
sudo dnf install -y wget

# MySQL RPM download
wget https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm

# MySQL RPM Install
sudo dnf install -y mysql80-community-release-el9-1.noarch.rpm

2.2 Yum Repository 확인

dnf repolist enabled | grep mysql

3. MySQL 설치

sudo dnf install -y mysql-community-server

# gpg public key 오류가 지속적으로 발생하여 gpg check 없이 설치(개발 서버만 해당)
sudo dnf install -y mysql-community-server --nogpgcheck

3.1 GPG-Key 오류 대처 방법

# GPG-KEY download
sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

# GPG-KEY download 확인
ls -al /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2022

# dnf clean & makecache
sudo dnf clean all
sudo dnf makecache

4. MySQL 서비스 시작 및 OS 재시동 시 자동 실행 설정

# mysqld server enable
sudo systemctl enable mysqld
# mysqld service start 
sudo systemctl start mysqld
# mysqld start
/etc/init.d/mysqld start
# mysqld stop
/etc/init.d/mysqld stop
# mysqld restart
/etc/init.d/mysqld restart

# 상태 확인
sudo systemctl status mysqld

5. 초기 root 비밀번호 확인 및 보안 설정

5.1 초기 비밀번호 확인

sudo grep 'temporary password' /var/log/mysqld.log

5.2 보안 설정(비밀번호 변경, 불필요 기능 제거)

sudo mysql_secure_installation
#설정 항목
# 1. root 비밀번호 변경
# 1.5.1에서 확인한 초기 비밀번호 입력 후 root 비밀번호 변경
# 2025-07-08T01:02:51.432419Z 6 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: P-!xhHB2qfkN
# 2. 익명 사용자 삭제
# 3. 원격 root 로그인 비활성화
# 4. test DB 삭제
# 5. 권한 테이블 새로고침

6. MySQL 접속 테스트

mysql -u root -p
Enter password: {{1.5.2에서 변경한 root password 입력}}

7. MySQL 기본 설정 파일 변경

sudo vi /etc/my.cnf

7.1 my.cnf 파일 변경 사항

[mysqld]
port = 3306
bind-address = 0.0.0.0
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
default_time_zone = '+00:00'
log_bin_trust_function_creators = 1

# 바이너리 로그 보관 기간 설정 (예: 7일간만 보관)
binlog_expire_logs_seconds = 604800
# 개별 로그 파일의 최대 크기 제한 (예: 500MB)
max_binlog_size = 500M

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

7.2 MySQL Service restart

# MySQL Service restart
sudo systemctl restart mysqld

7.3 설정 내용 확인

-- MySQL Console

-- 포트 확인
SHOW GLOBAL VARIABLES LIKE 'port';

-- 문자셋 확인
SHOW VARIABLES LIKE 'character_set%';

-- 타임존 확인
SHOW VARIABLES LIKE 'time_zone';

# 바인드 주소 확인 (netstat 또는 ss 명령어)
sudo ss -lntp | grep mysqld

7.4 Rocky Linux 방화벽 설정

sudo firewall-cmd --add-port=33065/tcp --permanent
sudo firewall-cmd --reload

8. MySQL DB 및 계정 생성

/* Database 생성 */
-- 업무 데이터베이스
CREATE DATABASE work_database_name
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

/* 계정 생성 */
-- 전체 관리 계정
CREATE USER 'super_user_name'@'%' IDENTIFIED BY 'super_user_name_password';
-- work_database_name 관리 계정
CREATE USER 'user_name'@'%' IDENTIFIED BY 'user_name_password';

/* 권한 추가 */
GRANT ALL PRIVILEGES ON work_database_name.* TO 'super_user_app'@'%';
GRANT ALL PRIVILEGES ON work_database_name.* TO 'user_name'@'%';

/* 권한 적용 */
FLUSH PRIVILEGES;

/* 권한 확인 */
show grants for 'super_user_name'@'%';
show grants for 'user_name'@'%';

9. MySQL 서버 용량 부족시 대처 방법

-- 현재 디스크 상황이 급하므로, 2일 전 데이터까지만 남기고 모두 삭제
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 2 DAY);

SQL Conventions

그레고리오78 — Wed, 28 Jan 2026 10:13:23 +0900

1.개요

2. SQL 공통 표준

2.1. SQL 명명규칙(Naming Convention)

2.1.1. ID 길이

원칙
- ID의 길이는 18바이트를 넘지 않도록 작성한다.
- 지나치게 짧은 ID는 원래 의미를 상실하기 쉬우며 가독성을 떨어뜨린다.
설명
- 각 DBMS별로 최대허용길이가 다르지만 공통으로 사용할 수 있는 길이는 18바이트이다.
- 길이가 길 경우 DBMS간의 이식성을 떨어뜨리게 된다.

2.1.2. ID 구성문자

원칙
- 알파벳과 숫자, 밑줄(underscore)외의 특수문자는 사용하지 않는다.
- 밑줄(underscore)는 연속으로 사용하지 않는다.
- ID을 명명할 때 모음을 지나치게 생략하지 않는다.
설명
- 특수문자가 들어간 ID는 가독성이 떨어진다.
- 밑줄문자(underscore)을 연속으로 사용하면 해당 코드를 읽을 때 밑줄문자가 몇 개 사용되었는지 인식하기 힘들다.

2.1.3. 대소문자 사용규칙

원칙
- 대소문자 사용원칙을 정했으면 일관성 있게 고수한다. (대문자 권장)
설명
- 대소문자 구분여부는 DBMS마다 다르다.

2.1.4. 국제 명명규칙 표준 준수

원칙
- 국제 명명규칙 표준(ISO-11179)을 준수할 것
- 국가명이나 국가코드에 대한 명명은 ISO-3166 표준을 따른다.
- 날짜 표기에 대한 형식은 ISO-8601 표준을 따른다.
- 단, 아무리 우수한 국제 표준이라도 레거시 시스템에서 관습적으로 사용하는 것을 우선하여 적용한다.
설명
- SQL과 연관된 ISO-11179
  - SQL과 연관된 ISO-11179 표준 도메인은 11179-4으로, 데이터 요소 중 스칼라(Scalar) 타입은 아래와 같은 원칙을 준수한다.
  - 국가명이나 국가코드 표준에 대한 자료는 아래를 참고한다.
  - http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm
  - 아무리 우수한 국제표준 명명규칙이라도 관행으로 굳어졌거나 관습적으로 사용하는 것 보다 우선하여 사용하지 못한다.

2.1.5. 서술적인 접두어(prefix)의 사용 자제

서술적인 접두어(prefix)는 SQL문을 읽거나 분석할 때 도움이 되지 않는 경우가 많으며 오히려 그 반대의 경우가 더 많다.

원칙
- ~~테이블 ID는 “tbl_” 등으로 시작하지 않는다.~~
- ~~컬럼ID는 해당 컬럼의 소속을 나타내기 위해 테이블ID을 접두어를 붙이지 않는다.~~
- ~~뷰(view) ID는 “vw_” 등으로 시작하지 않는다.~~
- 특정컬럼이 primary key 또는 foreign key임을 나타내기 위해 해당 컬럼의 ID을 “pk_” 또는 “pf_” 등으로 시작하지 않도록 한다.
- 특정 ID가 제약사항(constraint)임을 나타내기 위해 다음과 같은 형식의 명명규칙을 사용하지 않도록 한다.
- <table_id>_CK_<column_id>
- 트리거(trigger) ID는 “trig_” 로 시작하지 않도록 한다.
- 저장프로시저 ID는 user-defined-procedure임을 나타내기 위해 “usp_” 로 시작하지 않는다.
- 트리거 또는 저장프로시저의 ID는 <동사><목적어> 형태로 명명한다.
설명
- 각 ID을 명명할 때 해당 ID의 소속, 형식을 표현하기 위해 접두어를 붙일 경우 해당 ID의 소속 또는 형식이 바뀌면 ID자체를 변경해야 할 경우가 있는데, 이렇게 되면 일관성을 잃어버리게 된다.

2.1.6. 표준 접미어(postfix)를 지정

ID의 주체가 되는 오브젝트의 형식을 나타내는 접두어(prefix) 대신 해당 오브젝트의 속성을 나타내는 접미어(postfix)을 지정하여 사용하는 것이 낫다.
(데이터베이스 명명규칙 참조)

2.1.7. 테이블, 뷰(view)의 이름

원칙
- 집합적이면서도 대표적인 이름 또는 복수형을 사용할 것
  - 단, 1개의 row만을 유지해야 하는 테이블의 경우는 예외로 한다.
- 산업표준을 따른다.

2.1.8. 별칭(alias)

원칙
- 별칭(alias)을 사용할 때 근본이 되는 원래의 이름과 동떨어진 이름은 사용하지 않는다.
설명
- 별칭(alias, 상관관계에 의해 파생되는 이름)도 하나의 이름이며 그것의 존재 원인이 되는 근원 테이블, 컬럼 또는 수식 등이 있게 마련이다. 별칭을 사용할 때 원래의 이름과 동떨어진 이름은 유지보수가 매우 어렵게 만들게 되므로 배제하는 것이 좋으나 지엽적으로 사용할 경우는 간략한 형태로 축약하여 사용하는 것을 허용한다.

2.1.9. 관계성이 함축된 이름

원칙
- 테이블 또는 뷰간의 관계가 서로 엮일 때, 이로 인해 파생되는 엔터티에 대해 가능하면 관계성을 표현할 수 있는 이름을 사용한다.
설명
- 아래와 같이 두 개 엔터티가 관계가 함축된 엔터티의 이름은 관계성을 함축하는 이름을 사용한다.
  - ‘남자’와 ‘여자’ 엔터티가 결합된 경우
  - 나쁜 예 : ManWoman 또는 HusbandsWives
  - 좋은 예 : Marriage
  - ‘학생’과 ‘과목’ 엔터티가 결합된 경우
  - 나쁜 예 : StudentsCourses
  - 좋은 예 : Enrollments

2.1.10. 메타데이터 성격을 가진 이름

원칙
- 스키마 등에서 메타데이터 성격을 가진 오브젝트에 한해서 구조체를 나타내는 접미사를 사용할 수 있다. 예를 들면 인덱스ID의 경우 “_ix” 의 접미사를 사용한다.

2.1.11. 데이터 요소 명명 시 피해야 할 사항

원칙
- 애매한 이름은 사용하지 말 것
- 상반적인 개념의 수식어가 결합된 ID는 사용하지 말 것
- 상황에 따라 변동이 될 수 있는 ID는 사용하지 말 것
- 물리모델에서 사용하는 용어(대부분 DBMS에 종속적인 용어)는 논리모델에서 사용하지 말 것
설명
- 너무 일반적인 이름은 포괄적이어서 아무런 정보를 전달하지 못하는 경우가 많다.
  - 예 : amount, date, id
- 객체지향 프로그래밍이 몸에 밴 개발자의 경우 모든 필드에 “_id” 라는 접미사를 붙이려는 경향이 있는데, 실제 상황에서 의미가 없는 경우가 많다.
- 논리모델에서 다음과 같은 용어는 물리모델로 전환하는 단계에서 예약어로 사용되는 경우가 많으므로 피해야 한다.
  - 예 : IDENTITY, GUID, ROWID 등

2.1.12. 대소문자 사용

원칙
- 컬럼ID, 파라미터, 변수는 소문자로 작성한다.
- 위의 경우를 제외하고, 스키마(schema)에서 나오는 오브젝트의 첫 글자는 대문자로 작성한다.
- 예약어(reserved word)는 모두 대문자로 작성한다.
- Camel-Case는 사용하지 않는다.
설명
- 예약어를 대문자로 작성하는 이유는 특별히 유의해서 보게 하려는 의도를 담고 있기 때문이다.
- Camel-Case은 기존의 Hungarian notation에 익숙한 개발자를 위한 것인데(ID를 구성하는 단어의 첫 글자만 대문자로 사용하는 표기법), 실제로는 가독성(readability)를 떨어뜨리는 요인이 된다.

2.2. SQL 코딩규칙(Coding Convention)

여기서는 SQL 코딩 시 가독성 향상을 위해 지켜야 할 문자, 문장의 배치 등 외형을 중심으로 기술하였습니다.

2.2.1. 공백(space)사용

원칙
- SQL코딩 시 가급적 탭을 사용하지 말고 공백문자(space)을 사용할 것
- SQL코드의 토큰 좌우에 공백을 사용할 것
설명
- 개발자마다 선호하는 TAB-SIZE가 다르기 때문에, SQL 코드 작성시 탭(TAB)을 사용하면 실제 코드가 가독성이 떨어질 수 있다.
- 실제 예는 아래와 같다.
  - 나쁜 예 : foobar=21
  - 좋은 예 : foobar = 21

2.2.2. 줄 간격

원칙
- 한 문장 내에서는 한 줄씩만 띄어쓰기를 할 것
- 하나의 프로세스 내에서의 각 문장은 두 줄씩 띄어쓰기를 할 것

2.2.3. 들여쓰기(indentation)

원칙
- SQL을 사용할 때 한 그룹 내에서는 ‘4-space rule’을 사용할 수 도 있다. (들여쓰기는 공백 3개로 통일한다.)
- 서브쿼리(sub-query)에서는 괄호를 시작과 끝의 위치를 일치시킨다.
설명
- SQL에서의 수직 맞춤 배치는 기존의 3GL 프로그래밍과 달리 공백을 이용한 인덴테이션 보다 우선 순위가 높다.
- 서브쿼리(sub-query)에서는 괄호를 시작과 끝의 위치를 일치시키면 서브쿼리의 영역을 쉽게 파악할 수 있는 이점이 있다.

2.2.4. 일반적인 마침법의 준수

원칙
- 콤마 뒤에 공백을 집어 넣을 것
- 콤마로 분리된 ID가 여러 줄에 걸쳐 나올 때, 콤마를 라인 끝이 아닌 라인의 처음에 위치시킬 것
- 세미콜론으로 끝나는 SQL문의 마지막은 New-Line 이나 최소한 공백을 집어 넣을 것
설명
- SQL 문을 읽을 때 콤마와 마침표를 구분하기 힘들 경우가 많으므로 다음의 예와 같이 콤마 뒤에는 공백을 집어 넣는다.
- 나쁜 예
```
SELECT flobs.a,flobs.b,flobs.c,fleq.d
  FROM Flobs,Foobar,Fleq;
```
- 좋은 예
```
SELECT flobs.a, flobs.b, flobs.c, fleq.d
  FROM Flobs, Foobar, Fleq;
```
- 콤마로 분리된 ID가 여러 줄에 걸쳐 쓰여지면, 다음 예와 같이 콤마를 라인의 처음에 위치시키는 것이 보기에도 좋고 추후 SQL을 수정하기에도 수월하다.
```
SELECT flobs.a
       , flobs.b
       , flobs.c
       , fleq.d
  FROM Flobs
       , Fleq
```

2.2.5. 예약어(Reserved Word) 사용

원칙
- 예약어는 단축형이 아닌 Full-Name을 사용할 것
- 특정 DBMS에 종속적인 예약어 대신 표준 예약어를 사용할 것
설명
- 데이터 타입을 제외하고는 되도록이면 예약어는 생략하지 말고 Full-Name을 사용하는 것이 좋다. 예를 들면 “FROM”절에 “Personnel P1” 대신 “Personnel AS P1” 으로 사용하면 좋다.
- 특정 DBMS에 종속적인 예약어를 사용하면 이식성이 떨어진다.

2.2.6. SQL 수직 배치

SQL문장이 여러 줄에 걸쳐 기술되어 있을 경우, 좌우로 지그재그형태로 생긴 모양은 최대한 배제하고, 다음을 원칙으로 한다.

원칙
- SELECT(T), UPDATE(E), FROM(M), WHERE(E), AND(D), OR(R), ORDER BY(R), GROUP BY(P)의 끝 문자를 다음 SQL문의 끝 문자(SELECT(T), UPDATE(E), INSERT(T), DELETE(E))와 맞춘다.
- INSERT 및 VALUES는 동일한 위치에서 시작한다.
- 모든 컬럼은 동일한 위치에서 시작한다. (단, 컬럼 앞에 함수가 나오면 함수명의 첫 글자를 기준으로 맞춤)
- SELECT(T), UPDATE(E), INSERT(T), DELETE(E) 뒤로 바로 컬럼명이 나올 경우 다음 줄에서 앞 줄의 첫 단어의 끝(INSERT(T), UPDATGE(E), INSERT(T), DELETE(E))으로 부터 한 칸을 띄고 작성한다.
- SELECT, UPDATE, INSERT, DELETE 문의 컬럼 목록은 첫 컬럼만 제외하고 앞에 콤마(,)로 시작한다.
- INSERT 문의 경우 VALUE 절의 값들도 첫 번째 값을 제외하고 모두 콤마로 시작하되 동일한 위치로 정렬한다.
- FROM 절의 인-라인 뷰를 제외한 일반 테이블들은 콤마(,)로 구분하되 한 줄에 연속하여 기술하고 한 줄을 초과하는 경우, 줄을 바꾸어 윗줄의 첫 테이블 이름에 맞추어 시작한다.
- 인-라인 뷰의 내부의 SQL문은 시작괄호 ‘(‘ 바로 다음부터 시작하되, 위의 내용과 동일한 규칙을 적용하며 인-라인 뷰가 끝나면 괄호를 닫은 후 줄을 바꾸도록 한다.
- SQL 문의 마지막에 “;” 을 기술하여 해당 문의 끝을 표시한다.
- UPDATE 문에서 SET절의 컬럼들은 첫 컬럼만 제외하고 콤마(,)로 시작한다.

설명

일반적인 SQL 문 배치 예시
일반적인 수직배치

SELECT DISTINCT pilot
  FROM PilotSkills AS PS1
 WHERE NOT EXISTS (
        SELECT *
          FROM Hangar
         WHERE NOT EXISTS (
                SELECT *
                  FROM PilotSkills AS PS2
                 WHERE PS1.pilot = PS2.pilot
                   AND P2.plane = Hangar.plane
                )
       )
;

SELECT 문의 작성 예시

-- 예시 (2) : 주석(comment)을 SELECT 예약어 바로 다음에 배치한 예
SELECT col1
       , col2 /* Comment */
       , col3
  FROM TB_SAMPLE
 WHERE col1 = 123
GROUP BY col2
HAVING SUM(col3) > 1000
ORDER BY SUM(col3)
;

-- 예시 (3): 중첩된 SQL문장의 수직배치 예
SELECT col1
       , col2 /* Comment */
       , col3
       , col4
       , col5 /* Comment */
  FROM (
        SELECT col1
               , col2
               , col3
          FROM TB_SAMPLE1
         WHERE col1 BETWEEN 100 AND 200
       ) a
       , TB_SAMPLE2 b
 WHERE a.col1 = b.col1
   AND b.col2 IN (
        SELECT col1
          FROM TB_SAMPLE3
         WHERE col2 = ‘123’)
   AND b.col3 LIKE ‘A%’
;

-- 예시 (4) CASE문을 동반한 수직배치의 예
SELECT col1
       , col2
       , col3
       , CASE WHEN col4 = 'AAA' THEN col5 * 1.05
              WHEN col4 LIKE '%BB' THEN col5 * 1.1
              WHEN col4 IN ('CCC', 'DDD') THEN col5 * 1.2
              ELSE col5 * 1.3
         END AS 인상급여
  FROM TB_SAMPLE
;

-- 예시 (5): 왼쪽 괄호가 동반된 수직배치의 예
SELECT deptno
  FROM BIG_DEPT d
 WHERE NOT EXISTS (
        SELECT deptno
          FROM BIG_EMP e
         WHERE e.deptno = d.deptno
       )
;

-- 예시 (6): UNION을 동반한 수직배치의 예
SELECT deptno
  FROM BIG_DEPT d
UNION ALL
SELECT deptno
  FROM BIG_EMP e
;

-- 예시 (1) : SELECT 예약어의 ‘T’을 기준으로 수직배치를 한 예 SELECT col1 , col2 /* Comment */ , col3 , CASE WHEN col4 = 1 THEN col4 ELSE col4,col4 / 100 END as col4 , col5 /* Comment */ FROM TB_SAMPLE a WHERE col1 = 123 AND col2 like ‘A%’ AND col3 in (‘A’, ‘B’, ‘C’) ;
UPDATE 문의 작성 예시
-- 예시 (1): UPDATE 예약어의 ‘E’을 기준으로 수직배치를 한 예 UPDATE TB_SAMPLE SET col1 = 123 , col2 = ‘ABC’ , col3 = TO_CHAR(9936) WHERE col4 = 123 AND col5 LIKE ‘A%’ AND col6 IN (‘A’, ‘B’, ‘C’) ;

INSERT 문 작성예문

-- 예시 (2): INSERT의 VALUE 내용을 SELECT을 사용하여 처리한 예
INSERT INTO TB_SAMPLE1 (
       col1
       , col2
)
SELECT col3 /* col1 */
       , col4 /* col2 */
  FROM TB_SAMPLE2
;

-- 예시 (1): INSERT 예약어의 ‘T’을 기준으로 수직배치를 한 예 INSERT INTO TB_SAMPLE ( col1 , col2 , col3 , col4 ) VALUES ( '111' , '222' , '333' , '444' );
o DELETE 문 작성예문
-- 예시 (1) : DELETE 예약어의 끝 문자(‘E’)을 기준으로 수직배치를 한 예 DELETE FROM TB_SAMPLE WHERE col1 = 123 AND col2 LIKE 'A%' AND col3 IN ('A', 'B', 'C') ;

2.2.7. 주석(comment) 사용

원칙
- SELECT, UPDATE, INSERT, DELETE 문에서 컬럼목록 다음에 반드시 주석(/* */)을 사용하여 프로그램ID을 기술한다.
- 원칙적으로 힌트(HINT)을 사용하는 것은 금지하지만, 불가피하게 힌트(HINT)을 사용할 경우에는 SQL문의 첫 번째 SELECT, UPDATE, INSERT, DELETE 다음에 반드시 동일한 줄에 프로그램 ID 를 /* / 을 이용하여 기술하며, /+ */ 을 이용하고 프로그램ID을 먼저 기술하고 힌트를 기술한다.

3. SQL 작성 표준

3.1. SQL 작성시 기본적인 지침

3.1.1. 표준기능의 사용

제품특성과 연관된 기능보다 표준 기능을 사용 할 것.

3.1.1.1. OUTER JOIN 표기법 (권장)

조회 시 특정 DBMS에 종속된 SQL을 사용하는 예는 바람직하지 않으며 이식에 문제를 발생시키게 된다. (위 사항은 권장 사항임)

3.1.1.2. ISO표준 기간 표기법

ISO-8601 표준 표기법인 “YYYY-MM-DD hh:mm:ss.sssss” 을 사용할 것

3.1.2. 간결한 표기법을 사용

3.1.2.1. 필요 없는 괄호의 사용

다음과 같이 불필요한 괄호는 사용하지 않는 것이 좋다.

SELECT a, b, c
  FROM Foobar
 WHERE (a = b)
   AND (c < 42)
;

3.1.2.2. CASE 문 사용시 주의 사항

CASE문은 엄밀하게 말하면 문장(statement)이 아니라 수식(expression)이기 때문에 반드시 하나의 값을 반환한다는 것에 유의할 것(만약 조건 중 만족하는 것이 없으면 묵시적으로 “ELSE NULL” 이 추가된다.
명시적으로 NULL을 반환할 때는 “CAST (NULL AS <datatype>)” 형태를 사용할 것
CASE문을 쓸 때 “<CASE operand>” 대신에 Searched CASE 수식을 사용할 것
o 바람직하지 않은 예
CASE iso_sex_code WHEN 0 THEN 'Unknown' WHEN 1 THEN 'Male' WHEN 2 THEN 'Female' WHEN 9 THEN 'N/A' ELSE NULL END
o 바람직한 예
CASE WHEN iso_sex_code = 0 THEN 'Unknown' WHEN iso_sex_code = 1 THEN 'Male' WHEN iso_sex_code = 2 THEN 'Female' WHEN iso_sex_code = 9 THEN 'N/A' ELSE NULL END
o 예외상황
- NULL 여부와 비교하는 경우는 다음과 같이 SQL을 작성하면 에러가 발생하므로 주의해야 한다.
```
CASE WHEN foo = 0 THEN ‘bar’
     WHEN foo = NULL THEN ‘no_bar’ /* error !!! */
     ELSE NULL
END
```
가능하다면 COALESCE 또는 NULLIF 을 사용하여 SQL을 깔끔하게 작성한다.
- (COALESCE, NULLIF 모두 SQL-92 표준이다)

3.1.2.3. 불필요한 비교문

다음과 같이 불필요한 비교문은 사용하지 않는다.

SELECT a, b, c
  FROM Foobar
 WHERE a = b
   AND b = c
   AND c = a
;

3.1.2.4. 수식을 간소화하여 사용

간소한 수식 예(1)
- 나쁜 예
```
SELECT a, b, c
  FROM Foobar
 WHERE a + 2 = b - 4
;
```
- 아래와 같이 작성하면 읽기에도 어려울 뿐 아니라, a 컬럼이 인덱스로 구성되어 있어도 인덱스를 활용할 수 없게 되는 경우가 있다.
- 좋은 예
- SELECT a, b, c FROM Foobar WHERE a = b – 6 ;
간소한 수식 예(2)
- 구간에 대한 조건을 AND을 사용하여 표현하는 것보다 BETWEEN을 활용하는 것이 좋다.
- (단, 인덱스를 활용할 수 있는지 여부를 먼저 고려해서 사용할 것)
간소한 수식 예(3)
- 여러 개의 값과 비교할 때 OR을 사용하여 표현하는 것보다 IN을 활용하는 것이 좋다.
중첩되어 복잡한 조건절은 CASE 수식을 사용하여 간략하게 한다.

3.1.3. 주석 사용시 주의사항

가능하면 “--“ 보다는 /* */ 을 활용하는 것이 좋다. (경우에 따라 Unary Operator인 -‘와 혼동이 되는 경우가 있기 때문이다)
Stored-Procedure 및 Function 에서의 주석
- 항상 Stored-Procedure는 첫 줄에 최소한 다음의 사항을 주석으로 표현한다. 단, 프로시저 이름은 “<동사><목적어>” 형태로 기술하는 것이 좋다.
  - SP 및 Function 명 및 목적/기능 설명
  - Input Param 명 및 설명
  - Output Param 명 및 설명
  - 변경 이력(작성일자, 이름 - 변경 내용)
  - 복잡한 제어문에는 항상 주석을 사용할 것
  - /* =========================================================================================== Name : fnConvertIntToIPv4 Desc : 정수(INT UNSIGNED)를 IPv4 주소 문자열로 변환 Params - intIPv4 : 정수로 변환된 IPv4 Return - VARCHAR : IPv4 주소 문자열 Used : fnConvertIntToIPv4(3232235777) → '192.168.1.1' History - 2025.04.09, 이명근 - 최초 구현 =========================================================================================== */

3.1.4. 옵티마이저用 힌트(Hint)의 사용자제

옵티마이저用 힌트는 DBMS에 따라 표기법이 달라서 호환이 되지 않는 경우가 많으므로 사용하지 않는 것이 좋다.
DBMS의 옵티마이저는 대부분의 개발자보다 더 적은 비용의 전략을 잘 찾아낸다.
힌트를 사용할 일이 없어지거나 인덱스가 변경되면 성능이 더 떨어지는 경우가 많다.

3.1.5. 복잡한 데이터 처리 시 SQL Stored Procedure 사용 권장

보안성 강화
- Stored Procedure을 사용하면 해당 프로시저 내부에서 허용되는 작업만 진행하게 되므로 동적SQL(Dynamic SQL)을 사용할 때보다 훨씬 안전하다. (동적 SQL을 사용하면 SQL내용을 통제할 수 있는 방법이 없다)
유지보수 용이
- Stored Procedure는 손쉽게 수정하여 업그레이드할 수 있다. (새로 DBMS에 수정하는 순간 re-compile된다)
네트워크 트래픽 감소
- 네트워크상에서 파라미터 값만 전송되므로 네트워크 전송 효율이 좋아진다.
일관성
- SQL을 모두 Stored-Procedure로만 작성하게 되면 일관성이 생기므로 추후 작업에도 생산성이 높아진다.
모듈성
- 다른 Stored-Procedure에서도 해당 프로시저를 호출하여 사용할 수 있으므로 모듈화에 적합하다.

3.1.6. UNION은 사용 자제

아직도 대부분 옵티마이저는 UNION을 최적화하는데 어려움을 겪고 있다. 따라서 가능하다면 UNION ALL 만을 사용하고 나머지는 사용하지 않는 것이 좋다.

3.1.7. 정렬과 관련된 SQL문의 남용 금지

다음과 같이 Sort 가 발생하는 SQL 문은 최대한 자제한다.

ORDER BY
GROUP BY
DISTINCT

3.1.8. WHERE 절에 긍정적 조건의 사용

비교하고자 하는 컬럼이 숫자 타입이 확실한 경우를 제외하고 비교 하고자 하는 상수 값을 숫자 타입으로 하지 않는다.
”OR” 사용을 자제하고 가급적 IN, CASE 함수를 활용한다.
IFNULL 함수는 불필요하게 사용하지 않는다.
WHERE 절의 인덱스 스캔 컬럼에 인위적인 변형을 가하지 말고 반드시 상수(변수) 쪽에 변형을 가한다.
데이터를 검색할 때 불필요한 부분은 액세스하지 말고 읽어야 하는 부분만 처리하여 효율을 높인다. ( SELECT 문에서 ‘*’을 사용하지 말고 Named Column을 사용한다. )
불필요한 Network 접근을 줄이기 위해 가능하면 SQL을 최대한 묶어서 사용한다.

3.2. SQL 작성시 기본적인 절차

3.2.1. SQL 테스트

가능한 NULL과 관련된 모든 경우의 수를 테스트할 것
CHECK() 제약사항을 모두 검사하고 테스트할 것
테이블의 크기가 커질 경우를 테스트할 것

3.2.2. SQL 수행비용 검증

개발자는 작성된 SQL 문에 대한 실행계획을 검증하는 절차를 거친다.

3.2.3. OLAP 성격의 업무 개발시 주의사항

OLTP 성격의 업무에서 아래와 같은 SQL 문에 대해서는 반드시 해당 SQL문의 개선 작업을 수행한다.

Full Table Scan
Index Fast Full Scan
Sort Merge Join

4. SQL 작성 지침

4.1. DDL(Data Definition Language) 작성 지침

4.1.1. Default 값은 데이터 타입과 일치하는 값을 사용

당연한 말이지만, 의외로 많은 개발자가 이 원칙을 지키지 않는다. 예를 들면

Decimal 데이터 타입에 정수 0(zero)을 default 값으로 사용하는 경우
(CHAR(n) 데이터 타입에 길이가 n개 보다 적은 문자 스트링을 default 값으로 사용하는 경우
TIMESTAMPE 데이터 타입에 DATE 값을 default 로 사용하는 경우

위의 경우 같은 경우 DBMS에서 원래 데이터 타입에 맞게 묵시적인 변환작업이 일어나는데, DBMS성능에 영향을 미치는 요인이 될 수 있다.

4.1.2. Data Type 중 문자 타입은 일관성을 유지

char 대신 varchar 을 사용할 것
인덱스로 지정될 가능성이 높은 컬럼은 varchar로 지정하여 사용할 것

4.1.3. 테이블 생성시 주키(Primary Key)를 가장 위에 배치

4.1.4. 컬럼을 논리적인 순서로 배열 및 논리적인 그룹 지정

단, 스키마가 완성된 이후에 컬럼을 추가할 때 성능에 영향을 미치는지 고려해야 하는데, 다음 순서대로 컬럼을 배치하면 성능에 도움이 된다.

업데이트가 적게 일어나는 고정길이 컬럼
업데이트가 적게 일어나는 가변길이 컬럼
업데이트가 자주 일어나는 컬럼(들)
- 업데이트가 동시에 일어나는 성격의 컬럼이 연속되게 배치하면 좋음

4.1.5. 제약조건 이름은 명확하게 기술

4.1.6. 수치형 컬럼은 범위 제약사항을 두도록 고려

4.1.7. 가능하면 모든 테이블이 키를 갖도록 설계

키와 관련하여 주의할 사항은 아래와 같다.

자동 채번 컬럼은 관계성 키가 아니다.
파일은 테이블이 아니다.
“좋은 키”의 속성을 살펴 볼 것
- 유일성(Uniqueness)
- 안정성(Stability)
  - 쉽게 변하지 않는 값이어야 한다.
- 친밀성(Familiarity)
- 검증성(Validation)
  - 사용자 입장에서 검증하기 용이해야 한다.
- 확인성(Verifiability)
  - 개발자 입장에서 확인하기 용이해야 한다.
- 단순성(Simplicity)

4.2. DML(Data Manipulation Language) 작성 지침

4.2.1. NULL 사용 지침

NULL을 꼭 사용해야 할 경우 비교 연산자가 아닌 'IS' 또는 'IS NOT'을 사용한다.
- 좋은 예
- IF (@var IS NOT NULL) IF (@var IS NULL)
- 나쁜 예
- IF (@var = NULL) IF (@var <> NULL) IF (@var != NULL) IF (@var > NULL )
인덱스 비교 부분에서 NULL을 사용하지 않는다.
- 좋은 예
- SELECT ord_no , ord_date , item , ord_qty FROM ORDER1T WHERE ord_date > ' ' ;
- 나쁜 예
- SELECT ord_no , ord_date , item , ord_qty FROM ORDER1T WHERE ord_date IS NOT NULL ORDER BY ord_date ;

4.2.2. IN 사용 지침

WHERE 조건에서 ‘OR’을 최대한 배제하고 IN 을 사용한다.
- 좋은 예
- SELECT emp_name FROM Employees WHERE emp_id IN (1, 2, 5) ;
- 나쁜 예
- SELECT emp_name FROM Employees WHERE ((emp_id = 1) OR (empidn = 2) OR (empidn = 5)) ;
'BETWEEN'을 사용하면 Range Scan을 수행하고, 'IN'을 사용하면 Point SCAN을 수행하므로 IN을 사용하는 것이 더 효율적이다.
- 좋은 예
- SELECT col3 , col4 , col5 FROM TAB1 WHERE col1 = 'A' AND col2 IN ('112', '111') ;
- 나쁜 예
- SELECT col3 , col4 , col5 FROM TAB1 WHERE col1 = 'A' AND col2 BETWEEN '111' AND '112' ;
UNION은 가능하면 IN으로 대체한다.
- 좋은 예
- SELECT DISTINCT useid , usetypid FROM JOIN_USER_USERTYPS WHERE usetypid IN (16, 17) ;
- 나쁜 예
- SELECT DISTINCT useid , usetypid FROM JOIN_USER_USERTYPES WHERE (usetypid = 16) UNION ALL SELECT DISTINCT useid , usetypid FROM JOIN_USER_USERTYPES WHERE (usetypid = 17) ;

4.2.3. MIN, MAX 사용 지침

최대값(또는 최소값)만 필요한 경우 ORDER BY 대신 MAX(또는 MIN) 함수를 사용한다.
- 좋은 예
- SELECT MAX(emp_id) FROM Employees ;
- 나쁜 예
- SELECT emp_id FROM Employees ORDER BY empi_d DESC ;

4.2.4. UNION, UNION ALL 사용 지침

아래와 같이 UNION ALL 구문을 활용한다.
- 좋은 예
- SELECT fname , lname , empidn FROM Employees WHERE (empidn < 10) UNION ALL SELECT fname , lname , empidn FROM Employees WHERE (empidn >= 100) ;
- 나쁜 예
- SELECT fname , lname , empidn FROM Employees WHERE (empidn < 10) UNION SELECT fname , lname , empidn FROM Employees WHERE (empidn >= 100) ;
OR 대신 아래와 같이 UNION ALL 을 활용한다.
- 좋은 예
- SELECT COUNT(*) FROM Chujgo WHERE :sw = 1 AND chuldate = '20020628' UNION ALL SELECT COUNT(*) FROM Chulgo WHERE :sw = 2 AND RTRIM(chuldate) LIKE '200206%' ;
- 나쁜 예
- SELECT COUNT(*) FROM Chulgo WHERE (:sw = 1 AND chuldate = ‘20020628’) OR (:sw = 2 AND RTRIM(chuldate) LIKE ‘200206%’) ;

4.2.5. OR 사용시 주의사항

조건문 안에 OR을 사용하면 TABLE FULL SCAN을 하게 되므로 주의해야 한다.
- 좋은 예
- SELECT chulno , custno , chuldate , uncost FROM Chulgo WHERE (:sw = 1 AND (status LIKE ‘1%’) OR (:sw = 1 AND (status LIKE ‘2%’) OR (:sw = 2 AND (status LIKE ‘3%’) ORDER BY status ;
- 나쁜 예
- SELECT chulno , custno , chuldate , uncost FROM Chulgo WHERE (:sw = 1 AND (status LIKE ‘1%’ OR status LIKE ‘2%’)) OR (:sw = 2 AND (status LIKE ‘3%’)) ORDER BY status ;

4.2.6. 부정형 사용 금지 원칙

WHERE절에 부정형을 사용하면 인덱스 스캔이 불가능하므로 긍정형으로 변형하여 사용한다.
- 좋은 예
- SELECT 'Not found' INTO :col1 FROM DUAL WHERE NOT EXISTS ( SELECT 'x' FROM EMP WHERE empno = ‘1234’ ) ;
- 나쁜 예
- SELECT 'Not found' INTO :COL1 FROM EMP WHERE empno <> '1234' ;

4.2.7. NVL 활용 원칙

총계함수 사용 시 NULL은 무시되므로 총계함수 내에서의 IFNULL함수는 필요하지 않음
- 좋은 예
- IFNULL(SUM(trn_amount), 0)
- 나쁜 예
- IFNULL(SUM(IFNULL(trn_amount, 0)), 0)

4.2.8. OUTER JOIN 활용 방안

두 개의 테이블 중 한 쪽에만 값이 있는 경우를 추출할 경우 OUTER JOIN을 활용한다.
- 좋은 예
- SELECT d.deptno FROM BIG_DEPT d LEFT OUTER JOIN BIG_EMP e ON (d.deptno = e.deptno AND e.deptno IS NULL) ;
- 나쁜 예
- SELECT deptno FROM BIG_DEPT d WHERE NOT EXISTS ( SELECT deptno FROM BIG_EMP e WHERE e.deptno = d.deptno ) ;

5. SQL 사용 지침

5.1. 인덱스(Index) 사용

5.1.1. 인덱스 사용지침

필요한 경우에만 인덱스를 생성하고, 사용되지 않는 인덱스는 모니터링 후 삭제한다.
실제 조사된 액세스 종류에 따라서 인덱스를 선정 및 검증한다.
특정 명령문을 튜닝하기 위해 인덱스를 추가로 생성할 경우 다른 SQL의 액세스 경로가 바뀔 수도 있으므로 충분한 사전 분석 작업이 필요하다.
각종 액세스 분포도가 자주 조합되어 사용되는 경우는 결합 인덱스로 생성한다.
자주 조합되어 사용되는 경우의 수를 만족할 수 있도록 인덱스간의 역할을 분담한다.(되도록 많은 access path를 수용하도록 한다)
가능한 수정이 빈번하지 않는 칼럼으로 인덱스를 선정한다.
결합 인덱스의 칼럼 순서 선정에 주의 한다. 첫 번째 칼럼이 Where 조건에 존재해야 인덱스 scan 가능하다.
반복수행(loop 내) 되는 조건은 가장 빠른 수행속도를 내게 하여야 하므로 인덱스 구성의 대상으로 최우선 고려한다.
넓은 범위(5% 이상)를 인덱스로 처리 시 random access로 인한 많은 오버헤드가 발생할 가능성이 있으므로, Table Full Scan을 고려해봐야 한다.
인덱스의 개수는 테이블의 사용 형태에 따라 적절히 생성한다. 왜냐하면 DML 작업이 많은 경우 성능저하의 원인이 될 수 있기 때문이다.
조인(join) 시에는 잘못된 인덱스 사용이 큰 부하를 가져올 수 있으므로, 인덱스 사용여부에 주의하여야 한다.

5.1.2. 인덱스 적용 원칙

5.1.2.1. 인덱스 컬럼은 원형 그대로 사용할 것

예시(1)
- 개선 전
- SELECT dept , ename , sal FROM EMP WHERE SUBSTR(job, 1, 4) = '<st1:city w:st='on'>SALE</st1:city>' ;
- 개선 후
- SELECT dept , ename , sal FROM EMP WHERE job LIKE '<st1:city w:st='on'>SALE</st1:city>%' ;
예시(2)
- 개선 전
- SELECT empno , ename , job FROM EMP WHERE (sal * 12) = 35000000 ;
- 개선 후
- SELECT empno , ename , job FROM EMP WHERE sal = (35000000 / 12) ;
예시(3)
- 개선 전
- SELECT empno , ename ,job FROM EMP WHERE CONCAT(job, dept) = 'CLERK10' ;
- 개선 후
- SELECT empno , ename , job FROM EMP WHERE job = 'CLERK' AND dept = '10' ;
예시(4)
- o 개선 전
- SELECT chr , num , var , dat FROM SAMPLET WHERE CAST(car AS INTEGER) = 10;
- o 개선 후
- SELECT chr , num , var , dat FROM SAMPLET WHERE chr = '10' ;
위의 예를 이용하여 다음과 같이 강제로 인덱스를 타지 않게 할 수 도 있다.
SELECT SUM(col1) FROM TAB1 WHERE RTRIM(status) = '90' ;

5.1.2.2. 인덱스 사용시 부정형을 사용 금지

인덱스 컬럼을 부정형(NOT, <>)으로 비교할 때도 인덱스가 사용되지 않는다.

예시(1)
- 개선 전
- SELECT 'Not found' INTO :col1 FROM EMP WHERE empno <> '1234' ;
- 개선 후
- SELECT 'Not found' INTO :col1 FROM DUAL WHERE NOT EXISTS ( SELECT ‘'X' FROM EMP WHERE empno =‘'1234' ) ;

5.1.2.3. 인덱스 컬럼을 NULL과 비교 금지

인덱스 컬럼을 NULL과 비교하여도 해당 인덱스가 사용되지 않는다.

예시(1)
- 개선 전
- SELECT ord_no , ord_date , item , ord_qty FROM ORDER1T WHERE ord_date IS NOT NULL ORDER BY ord_date ;
- o 개선 후
- SELECT ord_no , ord_date , item , ord_qty FROM ORDER1T WHERE ord_date > ' ' ; -- ord_date가 숫자 타입이면 SELECT ord_no , ord_date , item , ord_qty FROM ORDER1T WHERE ord_date > 0 ;

5.2. 뷰(View) 사용

5.2.1. 뷰(View) 명명법

뷰를 나중에 테이블로 전환하는 경우 'vw’ 로 시작하는 이름을 모두 'tbl’로 바꾸어야 하는 병폐가 생길 수 있다.

5.2.2. 보안성을 높이려면 뷰(View)을 사용할 것

5.2.3. 데이터에 대한 검증을 위해서 뷰(View)을 사용할 것

5.2.4. 사용자의 요구로 인한 복잡성을 줄이기 위해 뷰(View)을 사용

사용자 또는 SQL 초보프로그래머를 위해 복잡한 SQL조회 결과를 뷰(View)로 미리 만들어 놓으면 추후 작업할 때 일을 대폭 줄여줄 수 있다

5.2.5. 2차 데이터를 도출할 때 뷰(View)을 사용하면 도움이 된다.

기존 테이블의 데이터를 근간으로 2차 데이터를 도출하여 사용할 때 뷰를 정의하여 사용하면 프로그래머의 부담이 줄어든다.

5.2.6. 테이블의 컬럼명이 복잡하거나 어려울 때 뷰(View)을 사용할 것

테이블의 컬럼명이 복잡하고 애매할 경우 간결한 컬럼명을 가지는 뷰를 생성하면 기존 컬럼명을 수정하지 않고도 동일한 효과를 얻을 수 있다.

5.2.7. 복잡한 제약사항을 단순화하기 위해 뷰(View)을 사용할 것

5.2.8. 뷰를 생성하려면 그에 합당한 이유가 있어야 한다.

5.2.9. 뷰를 남용하지 말 것

TypeScript Coding Conventions

그레고리오78 — Wed, 28 Jan 2026 10:11:53 +0900

변수

의미있는 변수 이름을 사용하세요

읽는 사람으로 하여금 변수마다 어떤 점이 다른지 알 수 있도록 이름을 구별하세요.

function between(a1: T, a2: T, a3: T): boolean {
  return a2 <= a1 && a1 <= a3;
}

Good

function between(value: T, left: T, right: T): boolean {
  return left <= value && value <= right;
}

발음할 수 있는 변수 이름을 사용하세요

발음할 수 없는 이름은 그 변수에 대해서 바보 같이 소리를 내 토론할 수밖에 없습니다.

Bad `

type DtaRcrd102 = {
  genymdhms: Date;
  modymdhms: Date;
  pszqint: number;
}

Good `

type Customer = {
  generationTimestamp: Date;
  modificationTimestamp: Date;
  recordId: number;
}

동일한 유형의 변수는 동일한 단어를 사용하세요

Bad `

    function getUserInfo(): User;
    function getUserDetails(): User;
    function getUserData(): User;

Good `
```
    function getUser(): User;
```

검색할 수 있는 이름을 사용하세요

Bad `
// 86400000이 도대체 뭐지? setTimeout(restart, 86400000);
Good `
// 대문자로 이루어진 상수로 선언하세요. const MILLISECONDS_IN_A_DAY = 24 * 60 * 60 * 1000; setTimeout(restart, MILLISECONDS_IN_A_DAY);

의도를 나타내는 변수를 사용하세요

Bad `
declare const users: Map<string, User>; for (const keyValue of users) { // users 맵을 순회 }
Good `
declare const users: Map<string, User>; for (const [id, user] of users) { // users 맵을 순회 }

암시하는 이름은 사용하지 마세요

명시적인 것이 암시적인 것보다 좋습니다. 명료함은 최고입니다.

Bad `
const u = getUser(); const s = getSubscription(); const t = charge(u, s);
Good `
const user = getUser(); const subscription = getSubscription(); const transaction = charge(user, subscription);

불필요한 문맥은 추가하지 마세요

클래스/타입/객체의 이름에 의미가 담겨있다면, 변수 이름에서 반복하지 마세요.

Bad `
type Car = { carMake: string; carModel: string; carColor: string; } function print(car: Car): void { console.log(${car.carMake} ${car.carModel} (${car.carColor})); }
Good ````tsmake: string;color: string;function print(car: Car): void {}
console.log(${car.make} ${car.model} (${car.color}));
}
model: string;
type Car = {

short circuiting이나 조건문 대신 기본 매개변수를 사용하세요

기본 매개변수는 short circuiting보다 보통 명료합니다.

Bad `
function loadPages(count?: number) { const loadCount = count !== undefined ? count : 10; // ... }
Good `
function loadPages(count: number = 10) { // ... }

함수

함수의 매개변수는 2개 혹은 그 이하가 이상적입니다

어떤 사람이 함수 시그니쳐(매개변수의 타입, 반환값의 타입 등)를 볼 때, 어떤 속성이 사용되는지 즉시 알 수 있습니다.
명명된 매개변수처럼 보이게 할 때 사용할 수 있습니다.
또한 구조 분해는 함수로 전달된 매개변수 객체의 특정한 원시 값을 복제하며 이것은 사이드 이펙트를 방지하는데 도움을 줍니다. 유의사항: 매개변수 객체로부터 구조 분해된 객체와 배열은 복제되지 않습니다.
타입스크립트는 사용하지 않은 속성에 대해서 경고를 주며, 구조 분해를 사용하면 경고를 받지 않을 수 있습니다.

Bad
function createMenu(title: string, body: string, buttonText: string, cancellable: boolean) { // ... } createMenu('Foo', 'Bar', 'Baz', true);
Good
function createMenu(options: { title: string, body: string, buttonText: string, cancellable: boolean }) { // ... } createMenu({ title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true });
타입 앨리어스를 사용해서 가독성을 더 높일 수 있습니다
type MenuOptions = { title: string, body: string, buttonText: string, cancellable: boolean }; function createMenu(options: MenuOptions) { // ... } createMenu({ title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true });

함수는 한 가지만 해야합니다

Bad
function emailClients(clients: Client[]) { clients.forEach((client) => { const clientRecord = database.lookup(client); if (clientRecord.isActive()) { email(client); } }); }
Good
function emailClients(clients: Client[]) { clients.filter(isActiveClient).forEach(email); } function isActiveClient(client: Client) { const clientRecord = database.lookup(client); return clientRecord.isActive(); }

함수가 무엇을 하는지 알 수 있도록 함수 이름을 지으세요

Bad
function addToDate(date: Date, month: number): Date { // ... } const date = new Date(); // 무엇이 추가되는지 함수 이름만으로 유추하기 어렵습니다 addToDate(date, 1);
Good
function addMonthToDate(date: Date, month: number): Date { // ... } const date = new Date(); addMonthToDate(date, 1);

함수는 단일 행동을 추상화해야 합니다

함수가 한 가지 이상을 추상화한다면 그 함수는 너무 많은 일을 하게 됩니다. 재사용성과 쉬운 테스트를 위해서 함수를 쪼개세요.

Bad
function parseCode(code: string) { const REGEXES = [ /* ... */ ]; const statements = code.split(' '); const tokens = []; REGEXES.forEach((regex) => { statements.forEach((statement) => { // ... }); }); const ast = []; tokens.forEach((token) => { // lex... }); ast.forEach((node) => { // parse... }); }
Good
const REGEXES = [ /* ... */ ]; function parseCode(code: string) { const tokens = tokenize(code); const syntaxTree = parse(tokens); syntaxTree.forEach((node) => { // parse... }); } function tokenize(code: string): Token[] { const statements = code.split(' '); const tokens: Token[] = []; REGEXES.forEach((regex) => { statements.forEach((statement) => { tokens.push( /* ... */ ); }); }); return tokens; } function parse(tokens: Token[]): SyntaxTree { const syntaxTree: SyntaxTree[] = []; tokens.forEach((token) => { syntaxTree.push( /* ... */ ); }); return syntaxTree; }

중복된 코드를 제거해주세요

Bad
function showDeveloperList(developers: Developer[]) { developers.forEach((developer) => { const expectedSalary = developer.calculateExpectedSalary(); const experience = developer.getExperience(); const githubLink = developer.getGithubLink(); const data = { expectedSalary, experience, githubLink }; render(data); }); } function showManagerList(managers: Manager[]) { managers.forEach((manager) => { const expectedSalary = manager.calculateExpectedSalary(); const experience = manager.getExperience(); const portfolio = manager.getMBAProjects(); const data = { expectedSalary, experience, portfolio }; render(data); }); }
Good
class Developer { // ... getExtraDetails() { return { githubLink: this.githubLink, } } } class Manager { // ... getExtraDetails() { return { portfolio: this.portfolio, } } } function showEmployeeList(employee: Developer | Manager) { employee.forEach((employee) => { const expectedSalary = employee.calculateExpectedSalary(); const experience = employee.getExperience(); const extra = employee.getExtraDetails(); const data = { expectedSalary, experience, extra, }; render(data); }); }

Object.assign 혹은 구조 분해를 사용해서 기본 객체를 만드세요

Bad
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean }; function createMenu(config: MenuConfig) { config.title = config.title || 'Foo'; config.body = config.body || 'Bar'; config.buttonText = config.buttonText || 'Baz'; config.cancellable = config.cancellable !== undefined ? config.cancellable : true; // ... } createMenu({ body: 'Bar' });
Good
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean }; function createMenu(config: MenuConfig) { const menuConfig = Object.assign({ title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true }, config); // ... } createMenu({ body: 'Bar' });
대안으로, 기본 값을 구조 분해를 사용해서 해결할 수 있습니다
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean }; function createMenu({ title = 'Foo', body = 'Bar', buttonText = 'Baz', cancellable = true }: MenuConfig) { // ... } createMenu({ body: 'Bar' });
사이드 이펙트와 undefined 혹은 null 값을 명시적으로 넘기는 예상치 못한 행동을 피하기 위해서 타입스크립트 컴파일러에게 그것을 허락하지 않도록 설정할 수 있습니다. 타입스크립트에서 --strictNullChecks 옵션을 확인하세요.

사이드 이펙트를 피하세요 (파트 1)

Bad
// 아래의 함수에서 참조하는 전역 변수입니다. let name = 'Robert C. Martin'; function toBase64() { name = btoa(name); } toBase64(); // 이 이름을 사용하는 다른 함수가 있다면, 그것은 Base64 값을 반환할 것입니다 console.log(name); // 'Robert C. Martin'이 출력되는 것을 예상했지만 'Um9iZXJ0IEMuIE1hcnRpbg=='가 출력됨
Good
const name = 'Robert C. Martin'; function toBase64(text: string): string { return btoa(text); } const encodedName = toBase64(name); console.log(name);

사이드 이펙트를 피하세요 (파트 2)

실제로는 입력된 객체값을 변경하기를 원하는 경우가 있을 수 있습니다. 하지만 이러한 프로그래밍 관례를 선택할 때 당신은 이러한 경우가 매우 드물다는 것을 알게 될 것입니다. 대부분은 사이드 이펙트가 없도록 리팩토링될 수 있습니다! (Pure Function를 확인해주세요)
큰 객체를 복제하는 것은 성능 관점에서 비용이 높을 수 있습니다. 다행히도 이러한 프로그래밍 접근법을 가능하게 해주는 훌륭한 라이브러리가 있기 때문에 큰 문제는 아닙니다. 이는 수동으로 객체와 배열을 복제해주는 것만큼 메모리 집약적이지 않게 해주고 빠르게 복제해줍니다.

Bad
function addItemToCart(cart: CartItem[], item: Item): void { cart.push({ item, date: Date.now() }); };
Good
function addItemToCart(cart: CartItem[], item: Item): CartItem[] { return [...cart, { item, date: Date.now() }]; };

명령형 프로그래밍보다 함수형 프로그래밍을 지향하세요

가능하다면 이런 방식의 프로그래밍을 지향하세요.

Bad
const contributions = [ { name: 'Uncle Bobby', linesOfCode: 500 }, { name: 'Suzie Q', linesOfCode: 1500 }, { name: 'Jimmy Gosling', linesOfCode: 150 }, { name: 'Gracie Hopper', linesOfCode: 1000 } ]; let totalOutput = 0; for (let i = 0; i < contributions.length; i++) { totalOutput += contributions[i].linesOfCode; }
Good
const contributions = [ { name: 'Uncle Bobby', linesOfCode: 500 }, { name: 'Suzie Q', linesOfCode: 1500 }, { name: 'Jimmy Gosling', linesOfCode: 150 }, { name: 'Gracie Hopper', linesOfCode: 1000 } ]; const totalOutput = contributions .reduce((totalLines, output) => totalLines + output.linesOfCode, 0);

조건문을 캡슐화하세요

Bad
if (subscription.isTrial || account.balance > 0) { // ... }
Good
function canActivateService(subscription: Subscription, account: Account) { return subscription.isTrial || account.balance > 0; } if (canActivateService(subscription, account)) { // ... }

부정 조건문을 피하세요

Bad
function isEmailNotUsed(email: string): boolean { // ... } if (isEmailNotUsed(email)) { // ... }
Good
function isEmailUsed(email): boolean { // ... } if (!isEmailUsed(node)) { // ... }

타입 체킹을 피하세요

Bad
function travelToTexas(vehicle: Bicycle | Car) { if (vehicle instanceof Bicycle) { vehicle.pedal(currentLocation, new Location('texas')); } else if (vehicle instanceof Car) { vehicle.drive(currentLocation, new Location('texas')); } }
Good
type Vehicle = Bicycle | Car; function travelToTexas(vehicle: Vehicle) { vehicle.move(currentLocation, new Location('texas')); }

필요 이상으로 최적화하지 마세요

Bad
// 예전 브라우저에서는 캐시되지 않은 `list.length`를 사용한 각 순회는 비용이 많이 들 것입니다. // `list.length`의 재계산 때문입니다. 현대 브라우저에서는 이 부분이 최적화됩니다. for (let i = 0, len = list.length; i < len; i++) { // ... }
Good
for (let i = 0; i < list.length; i++) { // ... }

필요하지 않는 코드는 제거하세요

Bad
function oldRequestModule(url: string) { // ... } function requestModule(url: string) { // ... } const req = requestModule; inventoryTracker('apples', req, 'www.inventory-awesome.io');
Good
function requestModule(url: string) { // ... } const req = requestModule; inventoryTracker('apples', req, 'www.inventory-awesome.io');

iterator와 generator를 사용하세요

스트림과 같이 사용되는 데이터 콜렉션을 사용할 때는 generator와 iterable을 사용하세요. 몇 가지의 좋은 이유가 있습니다:

피호출자가 접근할 아이템 수를 결정한다는 의미에서 피호출자를 generator 구현으로부터 분리할 수 있습니다.
지연 실행, 아이템은 요구에 의해 스트림 처리될 수 있습니다.
for-of 구문을 사용해 아이템을 순회하는 내장 지원이 있습니다.
iterable은 최적화된 iterator 패턴을 구현할 수 있습니다.
Bad
function fibonacci(n: number): number[] { if (n === 1) return [0]; if (n === 2) return [0, 1]; const items: number[] = [0, 1]; while (items.length < n) { items.push(items[items.length - 2] + items[items.length - 1]); } return items; } function print(n: number) { fibonacci(n).forEach(fib => console.log(fib)); } // 피보나치 숫자의 첫 번째 10개 숫자를 출력합니다. print(10);
Good
// 피보나치 숫자의 무한 스트림을 생성합니다. // `generator`는 모든 숫자의 배열을 유지하고 있지 않습니다. function* fibonacci(): IterableIterator<number> { let [a, b] = [0, 1]; while (true) { yield a; [a, b] = [b, a + b]; } } function print(n: number) { let i = 0; for (const fib of fibonacci()) { if (i++ === n) break; console.log(fib); } } // 피보나치 숫자의 첫 번째 10개 숫자를 출력합니다. print(10);
map, slice, forEach 등과 같은 메소드를 연결함으로써 네이티브 배열을 비슷한 방법으로 iterable로 작업할 수 있게 하는 라이브러리가 있습니다. iterable의 발전된 조작의 사례를 위해 itiriri를 확인해주세요. (또는 비동기 iterable의 조작을 위해서 itiriri-async를 확인해주세요.)
import itiriri from 'itiriri'; function* fibonacci(): IterableIterator<number> { let [a, b] = [0, 1]; while (true) { yield a; [a, b] = [b, a + b]; } } itiriri(fibonacci()) .take(10) .forEach(fib => console.log(fib));

객체와 자료구조

타입 vs 인터페이스

Bad
interface EmailConfig { // ... } interface DbConfig { // ... } interface Config { // ... } //... type Shape = { // ... }
Good
type EmailConfig = { // ... } type DbConfig = { // ... } type Config = EmailConfig | DbConfig; // ... interface Shape { // ... } class Circle implements Shape { // ... } class Square implements Shape { // ... }

클래스

클래스는 작아야 합니다

클래스의 크기는 책임에 의해 측정됩니다. 단일 책임 원칙에 따르면 클래스는 작아야 합니다.

Bad
class Dashboard { getLanguage(): string { /* ... */ } setLanguage(language: string): void { /* ... */ } showProgress(): void { /* ... */ } hideProgress(): void { /* ... */ } isDirty(): boolean { /* ... */ } disable(): void { /* ... */ } enable(): void { /* ... */ } addSubscription(subscription: Subscription): void { /* ... */ } removeSubscription(subscription: Subscription): void { /* ... */ } addUser(user: User): void { /* ... */ } removeUser(user: User): void { /* ... */ } goToHomePage(): void { /* ... */ } updateProfile(details: UserDetails): void { /* ... */ } getVersion(): string { /* ... */ } // ... }
Good
class Dashboard { disable(): void { /* ... */ } enable(): void { /* ... */ } getVersion(): string { /* ... */ } } // 다른 클래스에 남은 메소드를 이동시킴으로써 책임을 분산시키세요 // ...

높은 응집도와 낮은 결합도

Bad
class UserManager { // Bad: 각 private 변수는 메소드의 하나 혹은 또 다른 그룹에 의해 사용됩니다. // 클래스가 단일 책임 이상의 책임을 가지고 있다는 명백한 증거입니다. // 사용자의 트랜잭션을 얻기 위해 서비스를 생성하기만 하면 되는 경우, // 여전히 `emailSender` 인스턴스를 전달해야 합니다. constructor( private readonly db: Database, private readonly emailSender: EmailSender) { } async getUser(id: number): Promise<User> { return await db.users.findOne({ id }); } async getTransactions(userId: number): Promise<Transaction[]> { return await db.transactions.find({ userId }); } async sendGreeting(): Promise<void> { await emailSender.send('Welcome!'); } async sendNotification(text: string): Promise<void> { await emailSender.send(text); } async sendNewsletter(): Promise<void> { // ... } }
Good
class UserService { constructor(private readonly db: Database) { } async getUser(id: number): Promise<User> { return await this.db.users.findOne({ id }); } async getTransactions(userId: number): Promise<Transaction[]> { return await this.db.transactions.find({ userId }); } } class UserNotifier { constructor(private readonly emailSender: EmailSender) { } async sendGreeting(): Promise<void> { await this.emailSender.send('Welcome!'); } async sendNotification(text: string): Promise<void> { await this.emailSender.send(text); } async sendNewsletter(): Promise<void> { // ... } }

상속(inheritance)보다 조합(composition)을 사용하세요

'has-a' 관계가 아닌 'is-a' 관계일 때 (사람->동물 vs 사용자->사용자 정보)
기반이 되는 클래스로부터 코드를 재사용할 수 있을 때 (사람은 모든 동물처럼 움직일 수 있습니다.)
기반이 되는 클래스를 변경하여 파생된 클래스를 전체적으로 변경하려는 경우 (모든 동물은 움직일 때 칼로리가 소비됩니다.)

Bad
class Employee { constructor( private readonly name: string, private readonly email: string) { } // ... } // `Employee`가 세금 데이터를 가지기 때문에 나쁜 에입니다. `EmployeeTaxData`는 `Employee`의 타입이 아닙니다. class EmployeeTaxData extends Employee { constructor( name: string, email: string, private readonly ssn: string, private readonly salary: number) { super(name, email); } // ... }
Good
class Employee { private taxData: EmployeeTaxData; constructor( private readonly name: string, private readonly email: string) { } setTaxData(ssn: string, salary: number): Employee { this.taxData = new EmployeeTaxData(ssn, salary); return this; } // ... } class EmployeeTaxData { constructor( public readonly ssn: string, public readonly salary: number) { } // ... }

메소드 체이닝을 사용하세요

Bad
class QueryBuilder { private collection: string; private pageNumber: number = 1; private itemsPerPage: number = 100; private orderByFields: string[] = []; from(collection: string): void { this.collection = collection; } page(number: number, itemsPerPage: number = 100): void { this.pageNumber = number; this.itemsPerPage = itemsPerPage; } orderBy(...fields: string[]): void { this.orderByFields = fields; } build(): Query { // ... } } // ... const queryBuilder = new QueryBuilder(); queryBuilder.from('users'); queryBuilder.page(1, 100); queryBuilder.orderBy('firstName', 'lastName'); const query = queryBuilder.build();
Good
class QueryBuilder { private collection: string; private pageNumber: number = 1; private itemsPerPage: number = 100; private orderByFields: string[] = []; from(collection: string): this { this.collection = collection; return this; } page(number: number, itemsPerPage: number = 100): this { this.pageNumber = number; this.itemsPerPage = itemsPerPage; return this; } orderBy(...fields: string[]): this { this.orderByFields = fields; return this; } build(): Query { // ... } } // ... const query = new QueryBuilder() .from('users') .page(1, 100) .orderBy('firstName', 'lastName') .build();

인터페이스 & 타입

인터페이스 (Interface)

PascalCase를 사용합니다.
I를 접두어로 사용하지 않습니다.

이전에는 인터페이스 변수 앞에 I를 붙이는 경우가 많았는데 현재는 비관습적인 이유로 사용하지 않습니다.

// Bad
interface IFoo {
}

// Good
interface Foo {
}

타입 (Type)

PascalCase를 사용합니다.
멤버는 camelCase를 사용합니다.

// Bad
type car {
  ModelInfo: string;
}

// Good
type Car {
  modelInfo: string;
}

Type vs Interface

Union이나 Intersection이 필요할 때 Type을 사용합니다.

type Foo = number | { someProperty: number }

extends 또는 implements를 사용하고 싶을 때는 Interface를 사용합니다.

interface Foo {
  foo: string;
}

interface FooBar extends Foo {
  bar: string;
}

class X implements FooBar {
  foo: string;
  bar: string;
}

네임스페이스 & ENUM

네임스페이스 (namespace)

PascalCase를 사용합니다.

타입스크립트 팀에서 정한 약속입니다.
네임스페이스들은 정적멤버를 갖는 클래스, 클래스 이름도 PascalCase를 사용하기 때문에 동일하게 사용합니다.

// Bad
namespace foo {
}

// Good
namespace Foo {
}

enum

PascalCase를 사용합니다.
enum의 멤버에는 PascalCase를 사용합니다.

타입스크립트 팀에서 정한 약속입니다.

// Bad
enum color {
  red
}

// Good
enum Color {
  Red
}

명확하지 않은 변수 타입

any vs unknown

unknown 타입을 사용합니다.
any, unknown 타입 모두 아무때나 사용할 수 있지만 unknown 타입은 사용하는 쪽에서 방어처리를 해서 안전하게 사용이 가능합니다.
any 타입은 타입스크립트를 쓰는 의미가 없게 되버릴 수 있습니다.

const prettyPrint: string = (x: unknown) => {
  if (Array.isArray(x)) {
    return '[' + x.map(prettyPrint).join(', ') + ']'
  }
  if (typeof x === 'string') {
    return `'${x}'`
  }
  if (typeof x === 'number') {
    return String(x)
  } 
  return 'etc.'
}

x를 any로 했을 경우 map(), join()을 사용할 수 있는데 unknown일 때 x가 배열인 경우에만 map(), join()을 사용할 수 있도록 강제해줍니다.

null vs undefined

명백히 값이 없을 때에도 사용하지 않도록 합니다.
타입스크립트에서 type으로 구조를 암시할 수 있도록 합니다.

// Bad
let foo = { x: 123, y: undefined }

// Good
let foo = { x: number, y?: number } = { x: 123 }

일반적으로 undefined를 사용합니다.

return undefined

null이나 undefined 값을 갖는 객체는 truthy하게 검사합니다.

// Bad
if (error === null)

// Good
if (error)

null이나 undefined를 체크할 때 === 혹은 !==를 사용하지 않고 == 혹은 !=를 사용합니다.

null이나 undefined에는 작동하지만 다른 fasly 값들 ('', 0, false)에는 작동하지 않습니다.

// Bad
if (error !== null)

// Good
if (error != null)

SOLID

단일 책임 원칙 (SRP)

Bad
class UserSettings { constructor(private readonly user: User) { } changeSettings(settings: UserSettings) { if (this.verifyCredentials()) { // ... } } verifyCredentials() { // ... } }
Good
class UserAuth { constructor(private readonly user: User) { } verifyCredentials() { // ... } } class UserSettings { private readonly auth: UserAuth; constructor(private readonly user: User) { this.auth = new UserAuth(user); } changeSettings(settings: UserSettings) { if (this.auth.verifyCredentials()) { // ... } } }

개방 폐쇄 원칙 (OCP)

Bad
class AjaxAdapter extends Adapter { constructor() { super(); } // ... } class NodeAdapter extends Adapter { constructor() { super(); } // ... } class HttpRequester { constructor(private readonly adapter: Adapter) { } async fetch<T>(url: string): Promise<T> { if (this.adapter instanceof AjaxAdapter) { const response = await makeAjaxCall<T>(url); // response 값을 변경하고 반환합니다. } else if (this.adapter instanceof NodeAdapter) { const response = await makeHttpCall<T>(url); // response 값을 변경하고 반환합니다. } } } function makeAjaxCall<T>(url: string): Promise<T> { // 서버에 요청하고 프로미스를 반환합니다. } function makeHttpCall<T>(url: string): Promise<T> { // 서버에 요청하고 프로미스를 반환합니다. }
Good
abstract class Adapter { abstract async request<T>(url: string): Promise<T>; // 하위 클래스와 공유하는 코드 ... } class AjaxAdapter extends Adapter { constructor() { super(); } async request<T>(url: string): Promise<T>{ // 서버에 요청하고 프로미스를 반환합니다. } // ... } class NodeAdapter extends Adapter { constructor() { super(); } async request<T>(url: string): Promise<T>{ // 서버에 요청하고 프로미스를 반환합니다. } // ... } class HttpRequester { constructor(private readonly adapter: Adapter) { } async fetch<T>(url: string): Promise<T> { const response = await this.adapter.request<T>(url); // response 값을 변경하고 반환합니다. } }

리스코프 치환 원칙 (LSP)

Bad
class Rectangle { constructor( protected width: number = 0, protected height: number = 0) { } setColor(color: string): this { // ... } render(area: number) { // ... } setWidth(width: number): this { this.width = width; return this; } setHeight(height: number): this { this.height = height; return this; } getArea(): number { return this.width * this.height; } } class Square extends Rectangle { setWidth(width: number): this { this.width = width; this.height = width; return this; } setHeight(height: number): this { this.width = height; this.height = height; return this; } } function renderLargeRectangles(rectangles: Rectangle[]) { rectangles.forEach((rectangle) => { const area = rectangle .setWidth(4) .setHeight(5) .getArea(); // BAD: `Square` 클래스에서는 25를 반환합니다. 20이 반환되어야 합니다. rectangle.render(area); }); } const rectangles = [new Rectangle(), new Rectangle(), new Square()]; renderLargeRectangles(rectangles);
Good
abstract class Shape { setColor(color: string): this { // ... } render(area: number) { // ... } abstract getArea(): number; } class Rectangle extends Shape { constructor( private readonly width = 0, private readonly height = 0) { super(); } getArea(): number { return this.width * this.height; } } class Square extends Shape { constructor(private readonly length: number) { super(); } getArea(): number { return this.length * this.length; } } function renderLargeShapes(shapes: Shape[]) { shapes.forEach((shape) => { const area = shape.getArea(); shape.render(area); }); } const shapes = [new Rectangle(4, 5), new Rectangle(4, 5), new Square(5)]; renderLargeShapes(shapes);

인터페이스 분리 원칙 (ISP)

Bad
interface SmartPrinter { print(); fax(); scan(); } class AllInOnePrinter implements SmartPrinter { print() { // ... } fax() { // ... } scan() { // ... } } class EconomicPrinter implements SmartPrinter { print() { // ... } fax() { throw new Error('Fax not supported.'); } scan() { throw new Error('Scan not supported.'); } }
Good
interface Printer { print(); } interface Fax { fax(); } interface Scanner { scan(); } class AllInOnePrinter implements Printer, Fax, Scanner { print() { // ... } fax() { // ... } scan() { // ... } } class EconomicPrinter implements Printer { print() { // ... } }

의존성 역전 원칙 (DIP)

이 원칙은 두 가지 필수적인 사항을 명시합니다:

상위 레벨의 모듈은 하위 레벨의 모듈에 의존하지 않아야 합니다. 두 모듈은 모두 추상화에 의존해야합니다.
추상화는 세부사항에 의존하지 않아야 합니다. 세부사항은 추상화에 의존해야 합니다.

Bad
import { readFile as readFileCb } from 'fs'; import { promisify } from 'util'; const readFile = promisify(readFileCb); type ReportData = { // .. } class XmlFormatter { parse<T>(content: string): T { // XML 문자열을 T 객체로 변환 } } class ReportReader { // BAD: 특정 요청의 구현에 의존하는 것을 만들었습니다. // `parse` 메소드에 의존하는 `ReportReader`를 만들어야 합니다. private readonly formatter = new XmlFormatter(); async read(path: string): Promise<ReportData> { const text = await readFile(path, 'UTF8'); return this.formatter.parse<ReportData>(text); } } // ... const reader = new ReportReader(); await report = await reader.read('report.xml');
Good
import { readFile as readFileCb } from 'fs'; import { promisify } from 'util'; const readFile = promisify(readFileCb); type ReportData = { // .. } interface Formatter { parse<T>(content: string): T; } class XmlFormatter implements Formatter { parse<T>(content: string): T { // XML 문자열을 T 객체로 변환 } } class JsonFormatter implements Formatter { parse<T>(content: string): T { // JSON 문자열을 T 객체로 변환 } } class ReportReader { constructor(private readonly formatter: Formatter) { } async read(path: string): Promise<ReportData> { const text = await readFile(path, 'UTF8'); return this.formatter.parse<ReportData>(text); } } // ... const reader = new ReportReader(new XmlFormatter()); await report = await reader.read('report.xml'); // 또는 json 보고서가 필요한 경우 const reader = new ReportReader(new JsonFormatter()); await report = await reader.read('report.json');

TEST

개요

TDD의 세 가지 법칙

실패하는 단위 테스트를 작성하기 전에는 실제 코드를 작성하지 마세요.
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성하세요.
실패하는 단위 테스트를 통과할 정도로만 실제 코드를 작성하세요.

F.I.R.S.T 규칙

명료한 테스트는 다음 규칙을 따라야 합니다:

Fast 테스트는 빈번하게 실행되므로 빨라야 합니다.
Independent 테스트는 서로 종속적이지 않습니다. 독립적으로 실행하든지 순서 상관없이 모두 실행하든지 동일한 결과가 나와야 합니다.
Repeatable 테스트는 어떤 환경에서든 반복될 수 있습니다. 테스트가 실패하는데에 이유가 없어야 합니다.
Self-Validating 테스트는 통과 혹은 실패로 답해야 합니다. 테스트가 통과되었다면 로그 파일을 보며 비교할 필요는 없습니다.
Timely 단위 테스트는 실제 코드를 작성하기 전에 작성해야 합니다. 실제 코드를 작성한 후에 테스트를 작성한다면, 테스트를 작성하는 것이 너무 고단하게 느껴질 것입니다.

테스트 하나에 하나의 개념을 작성하세요

또한, 테스트는 단일 책임 원칙을 따라야 합니다. 단위 테스트 하나당 하나의 assert 구문을 작성하세요.

Bad
import { assert } from 'chai'; describe('AwesomeDate', () => { it('handles date boundaries', () => { let date: AwesomeDate; date = new AwesomeDate('1/1/2015'); assert.equal('1/31/2015', date.addDays(30)); date = new AwesomeDate('2/1/2016'); assert.equal('2/29/2016', date.addDays(28)); date = new AwesomeDate('2/1/2015'); assert.equal('3/1/2015', date.addDays(28)); }); });
Good
import { assert } from 'chai'; describe('AwesomeDate', () => { it('handles 30-day months', () => { const date = new AwesomeDate('1/1/2015'); assert.equal('1/31/2015', date.addDays(30)); }); it('handles leap year', () => { const date = new AwesomeDate('2/1/2016'); assert.equal('2/29/2016', date.addDays(28)); }); it('handles non-leap year', () => { const date = new AwesomeDate('2/1/2015'); assert.equal('3/1/2015', date.addDays(28)); }); });

테스트의 이름은 테스트의 의도가 드러나야 합니다

테스트가 실패할 때, 테스트의 이름은 어떤 것이 잘못되었는지 볼 수 있는 첫 번째 표시입니다.

Bad
describe('Calendar', () => { it('2/29/2020', () => { // ... }); it('throws', () => { // ... }); });
Good
describe('Calendar', () => { it('should handle leap year', () => { // ... }); it('should throw when format is invalid', () => { // ... }); });

동시성

프로미스 vs 콜백

Bad
import { get } from 'request'; import { writeFile } from 'fs'; function downloadPage(url: string, saveTo: string, callback: (error: Error, content?: string) => void) { get(url, (error, response) => { if (error) { callback(error); } else { writeFile(saveTo, response.body, (error) => { if (error) { callback(error); } else { callback(null, response.body); } }); } }); } downloadPage('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', 'article.html', (error, content) => { if (error) { console.error(error); } else { console.log(content); } });
Good
import { get } from 'request'; import { writeFile } from 'fs'; import { promisify } from 'util'; const write = promisify(writeFile); function downloadPage(url: string, saveTo: string): Promise { return get(url) .then(response => write(saveTo, response)); } downloadPage('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', 'article.html') .then(content => console.log(content)) .catch(error => console.error(error));

프로미스는 코드를 더욱 간결하게 해주는 몇몇의 헬퍼 메소드를 지원합니다:패턴설명

Promise.resolve(value)	해결(resolve)된 프로미스로 값을 변환함.
Promise.reject(error)	거부(reject)된 프로미스로 에러를 변환함.
Promise.all(promises)	전달된 모든 프로미스가 이행한 값의 배열을 이행하는 새 프로미스 객체를 반환하거나 거부된 첫 번째 프로미스의 이유로 거부함.
Promise.race(promises)	전달된 프로미스의 배열에서 가장 먼저 완료된 결과/에러로 이행/거부된 새 프로미스 객체를 반환함.

프로미스보다 async/await가 더 명료합니다

Bad
import { get } from 'request'; import { writeFile } from 'fs'; import { promisify } from 'util'; const write = util.promisify(writeFile); function downloadPage(url: string, saveTo: string): Promise { return get(url).then(response => write(saveTo, response)); } downloadPage('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', 'article.html') .then(content => console.log(content)) .catch(error => console.error(error));
Good
import { get } from 'request'; import { writeFile } from 'fs'; import { promisify } from 'util'; const write = promisify(writeFile); async function downloadPage(url: string, saveTo: string): Promise { const response = await get(url); await write(saveTo, response); return response; } // somewhere in an async function try { const content = await downloadPage('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', 'article.html'); console.log(content); } catch (error) { console.error(error); }

에러처리

개요

catch 절에서 에러 처리 부분을 비워두지 마세요

Bad
try { functionThatMightThrow(); } catch (error) { console.log(error); } // 아래 예제는 훨씬 나쁩니다. try { functionThatMightThrow(); } catch (error) { // 에러를 무시 }
Good
import { logger } from './logging' try { functionThatMightThrow(); } catch (error) { logger.log(error); }

요청이 거부된 프로미스 객체를 무시하지 마세요

위와 같이 try/catch 절에서 받은 에러 처리 부분을 비워두면 안됩니다.

Bad
getUser() .then((user: User) => { return sendEmail(user.email, 'Welcome!'); }) .catch((error) => { console.log(error); });
Good
import { logger } from './logging' getUser() .then((user: User) => { return sendEmail(user.email, 'Welcome!'); }) .catch((error) => { logger.log(error); }); // 또는 async/await 구문을 사용할 수 있습니다: try { const user = await getUser(); await sendEmail(user.email, 'Welcome!'); } catch (error) { logger.log(error); }

서식

개요

TSLint Config Standard - 표준 스타일 규칙
TSLint Config Airbnb - 에어비엔비 스타일 가이드
TSLint Clean Code - Clean Code: A Handbook of Agile Software Craftsmanship에 영감 받은 TSLint 규칙
TSLint react - React & JSX와 관련된 lint 규칙
TSLint + Prettier - Prettier 코드 포맷터를 위한 lint 규칙
ESLint rules for TSLint - 타입스크립트를 위한 ESLint 규칙
Immutable - 타입스크립트에서 변경을 허락하지 않는 규칙

또한, 훌륭한 자료인 타입스크립트 스타일 가이드와 코딩 컨벤션을 참고해주세요.

TSLint는 deprecated되었습니다. Roadmap: TSLint -> ESLint 이슈를 확인해주세요.

일관적으로 대소문자를 사용하세요

Bad
const DAYS_IN_WEEK = 7; const daysInMonth = 30; const songs = ['Back In Black', 'Stairway to Heaven', 'Hey Jude']; const Artists = ['ACDC', 'Led Zeppelin', 'The Beatles']; function eraseDatabase() {} function restore_database() {} type animal = { /* ... */ } type Container = { /* ... */ }
Good
const DAYS_IN_WEEK = 7; const DAYS_IN_MONTH = 30; const SONGS = ['Back In Black', 'Stairway to Heaven', 'Hey Jude']; const ARTISTS = ['ACDC', 'Led Zeppelin', 'The Beatles']; function eraseDatabase() {} function restoreDatabase() {} type Animal = { /* ... */ } type Container = { /* ... */ }
클래스, 인터페이스, 타입 그리고 네임스페이스 이름에는 PascalCase를 사용하세요.
변수, 함수 그리고 클래스 멤버 이름에는 camelCase를 사용하세요.

import 구문을 특정 순서대로 정리하세요(ESLint)

import 구문은 알파벳 순서대로 배열하고 그룹화해야 합니다.
사용하지 않은 import 구문은 제거되어야 합니다.
이름이 있는 import 구문은 알파벳 순서대로 배열해야 합니다. (예: import {A, B, C} from 'foo';)
import 하는 소스코드는 그룹 내에서 알파벳 순서대로 배열해야 합니다. (예: import as foo from 'a'; import as bar from 'b';)
import 구문의 그룹은 빈 줄로 구분되어야 합니다.
그룹은 다음 순서를 준수해야 합니다:
- 폴리필 (예: import 'reflect-metadata';)
- Node 내장 모듈 (예: import fs from 'fs';)
- 외부 모듈 (예: import { query } from 'itiriri';)
- 내부 모듈 (예: import { UserService } from 'src/services/userService';)
- 상위 디렉토리에서 불러오는 모듈 (예: import foo from '../foo'; import qux from '../../foo/qux';)
- 동일한 계층의 디렉토리에서 불러오는 모듈 (예: import bar from './bar'; import baz from './bar/baz';)
Bad
import { TypeDefinition } from '../types/typeDefinition'; import { AttributeTypes } from '../model/attribute'; import { ApiCredentials, Adapters } from './common/api/authorization'; import fs from 'fs'; import { ConfigPlugin } from './plugins/config/configPlugin'; import { BindingScopeEnum, Container } from 'inversify'; import 'reflect-metadata';
Good
import 'reflect-metadata'; import fs from 'fs'; import { BindingScopeEnum, Container } from 'inversify'; import { AttributeTypes } from '../model/attribute'; import { TypeDefinition } from '../types/typeDefinition'; import { ApiCredentials, Adapters } from './common/api/authorization'; import { ConfigPlugin } from './plugins/config/configPlugin';

타입스크립트 앨리어스를 사용하세요

Bad
import { UserService } from '../../../services/UserService';

Good

// tsconfig.json
...
  'compilerOptions': {
    ...
    'baseUrl': 'src',
    'paths': {
      '@services': ['services/*']
    }
    ...
  }
...

import { UserService } from '@services/UserService';

주석

당신의 코드를 주석 처리하지 마세요

버전 관리 시스템이 존재하는 이유입니다. 사용하지 않는 코드는 기록에 남기세요.

Bad
type User = { name: string; email: string; // age: number; // jobPosition: string; }
Good
type User = { name: string; email: string; }

일기 같은 주석을 달지 마세요

Bad
/** * 2016-12-20: 이해하지 못해서 모나드를 제거함 (RM) * 2016-10-01: 특별한 모나드를 사용해 개선함 (JP) * 2016-02-03: 타입 체킹 추가함 (LI) * 2015-03-14: combine 함수를 구현함 (JR) */ function combine(a: number, b: number): number { return a + b; }
Good
function combine(a: number, b: number): number { return a + b; }

코드의 위치를 설명하는 주석을 사용하지 마세요

Bad
//////////////////////////////////////////////////////////////////////////////// // Client 클래스 //////////////////////////////////////////////////////////////////////////////// class Client { id: number; name: string; address: Address; contact: Contact; //////////////////////////////////////////////////////////////////////////////// // public 메소드 //////////////////////////////////////////////////////////////////////////////// public describe(): string { // ... } //////////////////////////////////////////////////////////////////////////////// // private 메소드 //////////////////////////////////////////////////////////////////////////////// private describeAddress(): string { // ... } private describeContact(): string { // ... } };
Good
class Client { id: number; name: string; address: Address; contact: Contact; public describe(): string { // ... } private describeAddress(): string { // ... } private describeContact(): string { // ... } };

TODO 주석

Bad
function getActiveSubscriptions(): Promise<Subscription[]> { // ensure `dueDate` is indexed. return db.subscriptions.find({ dueDate: { $lte: new Date() } }); }
Good
function getActiveSubscriptions(): Promise<Subscription[]> { // TODO: ensure `dueDate` is indexed. return db.subscriptions.find({ dueDate: { $lte: new Date() } }); }

참고

https://google.github.io/styleguide/tsguide.html

https://google.github.io/styleguide/tsguide.html#source-file-basics

https://paullabworkspace.notion.site/8a6058561b924c0c95eb3933e480b367

https://radlohead.gitbook.io/typescript-deep-dive/styleguide

https://techblog.woowahan.com/9804/

https://738.github.io/clean-code-typescript/

https://github.com/tipjs/javascript-style-guide

https://velog.io/@cada/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%BD%94%EB%94%A9-%EB%B0%8F-%EB%84%A4%EC%9D%B4%EB%B0%8D-%EC%BB%A8%EB%B2%A4%EC%85%98-1%ED%8E%B8

JAVA Coding Conventions

그레고리오78 — Wed, 28 Jan 2026 10:09:01 +0900

1. 코드 표준

1.1 코드 표준의 필요성

프로그램의 코드 표준은 다음과 같은 이유로 프로그래밍에 있어서 중요성을 지닌다.

소프트웨어의 생명주기에 있어서 비용의 80% 이상이 관리에 소요된다.
코드 표준은 소프트웨어의 가독성(Readablity)을 높여 주며 개발자로 하여금 새로운 코드를 보다 빠르고 완벽하게 이해하도록 한다.
제품으로서 소스 코드를 납품해야 할 경우 다른 제품과 마찬가지로 코드를 잘 정리하고 깔끔하게 해야 한다.
재 작업으로 발생하는 오류를 예방 할 수 있다.
이를 위해 표준이 잘 적용되도록 하기 위해서는 소프트웨어 작성자 모두가 코딩 표준을 반드시 준수해야 한다.

1.2 코드 표준이 적용될 수 없는 경우

2. 명명 규칙(Naming Rule)

2.1 일반 사항

언어 간의 혼란을 피하고 통합을 보장하려면 약어 사용과 관련된 다음 규칙을 따라야 합니다.

업무 영역에 적합하게 정의된 용어를 사용한다.
같은 유형에 명명할 때, 비슷한 명칭이나 대소문자만 다른 명칭 사용을 금지한다.
자주 사용되는 JDK의 Package와 중복되지 않도록 한다. 또한 JDK 및 각 언어에서 사용하는 키워드와 중복되지 않아야 한다.
약어 또는 축약어를 식별자 이름의 일부로 사용하지 않습니다. 예를 들어, getWin 대신 getWindow를 사용합니다.
컴퓨팅 분야에서 일반적으로 받아 들여지지 않는 Prefix는 사용을 금지한다.
적절한 경우에는 길이가 긴 구 이름 대신 잘 알려진 머리 글자어를 사용한다. 예를 들어, User Interface 대신 UI를 사용하고 On-line Analytical Processing 대신 OLAP를 사용합니다.
명칭(Class, Method 등)의 길이는 31자 이내로 한다.
동일한 변수명과 함수명을 사용하지 않는다.
명칭은 “_” 이외의 특수 문자를 사용하지 않는다.
중괄호는 시작 문장의 마지막 열에 삽입, 닫는 중괄호는 새로운 시작열에 삽입한다.(if문, else-if문, else문, for문, while문, do-while문, switch문, try-catch문)
하나의 문장이 여러 줄로 작성될 경우 아래와 같은 규칙에 의해 행을 나눈다.
- 80자 초과 시, 쉼표 다음 문자부터 새로운 행을 시작한다.
- 이전 행과 동일한 수준의 표현식과 열을 맞춘다.

int result = getEmployees(recordsFromEmployeeTable, readCount,
                          recordsToEmployeeTable, writeCount);

배열을 선언하는 경우 반드시 요소 수를 명시적으로 선언하거나 초기화에 의해 묵시적으로 결정되도록 한다.
지역 변수는 선언과 동시에 초기화 한다.

int result = 0;

숫자 리터럴을 직접적으로 소스코드 안에 삽입하지 않는다.
단항 연산자는 피연산자와 붙여 쓴다.

var++;

.(dot) 연산자를 제외한 모든 이항 연산자 전후는 공백으로 구분한다.
조건부 연산자에서 “?” 연산자 앞에 이항 연산식이 나타날 경우 괄호로 구분한다.
증감 연산자는 수식에서 다릉 연산자와 결합하여 사용하지 않는다.
3개 이상의 연산자를 사용하는 경우 괄호로 연산의 우선순위를 표현한다.
Switch-case 문에서는 반드시 default 문을 작성하고 마지막 항목에 위치한다.
For 문을 제어하는 수식에 실수 값을 사용하지 않는다.
반복문 내부에서 반복중단을 위한 break 문은 가능한 한번만 사용하도록 한다.
if ~ else if 문은 반드시 else 문으로 끝나도록 한다.
문자열 변수는 null로 초기화 하지 않는다.
문자열 비교 시 ==를 사용 하지 말고 equals()를 사용한다.

if (“COMPANY_NAME”.equals(companyName)) {
   // some code
}

클래스 맴버변수를 public으로 선언하지 않는다.
패키즈를 import 할 때 “*”를 사용하지 않는다.
광범위한 예외 클래스인 Exception을 사용하여 예외처리 하지 않는다.
예외를 처리할 때, 민감한 정보를 외부에 노출하지 않는다.
널리 알려진 축약형을 사용할 때 첫 문자만 대문자를 사용한다.

loadXmlDocument()

비슷한 이름은 사용을 배제한다.

Object persistentObject;
Object persistentObjects;

2.2 대문자 표시 스타일

식별자의 대문자 표시 스타일 규칙은 다음 세가지를 사용합니다.

2.2.1 Pascal Case

String BackColor;

2.2.2 Camel Case

식별자의 첫 번째 문자는 소문자로 표시하고 연결된 각 후속 단어의 첫 번째 문자는 대문자로 표시합니다.

String backColor;

2.2.3 모두 대문자 표시

식별자의 모든 문자를 대문자로 표시합니다. 이 규칙은 두개 이하의 문자로 구성된 식별자에만 사용합니다.

OLAP
LDAP

식별자대문자 표시 규칙예제

클래스	Pascal Case	AppDomain
열거형 형식	Pascal Case	ErrorLevel
열거형 값	Pascal Case	FatalError
이벤트	Pascal Case	ValueChange
읽기 전용 정적 필드	Pascal Case	RedValue
매서스	Camel Case	toString
패키지	Camel Case	java.io
매개변수	Camel Case	typeName
GET/SET	Camel Case	getBackColor/setBackColor

2.3 Package

kr.co.company.[feature-technology Name].[module]

본 표준에서는 업무용 시스템에 맞게 다음과 같은 Package 구조를 따르기를 권장한다.

수준내용고정값 / 예제생략 가능

1	국가	kr, en 등	X
2	조직분류	com, co, go 등	X
3	회사	회사명	X
4	어플리케이션/시스템명	제품명, 프로젝트명 등	X
5	모듈	모듈명 등	X

2.4 Class

다음 규칙은 클래스 명명 지침을 요약한 것 입니다.

클래스 이름에는 명사 또는 명사구를 사용합니다.
파스칼식 대문자 표시 스타일을 사용합니다.
Java의 naming rule에 따라 Class의 이름은 명사를 사용하고, 첫 문자는 대문자로 시작을 하며 Internal word의 첫 번째 문자는 대문자를 사용합니다.
약어는 꼭 필요한 경우에만 사용합니다.
클래스 이름에는 클래스를 나타내는 C 등의 형식 접두사를 사용하지 않습니다. 예를 들어 CFileStream 대신 FileStream을 사용합니다.
밑줄(_)를 사용하지 않습니다.
시스템 및 서브시스템을 표시할 수 있는 Prefix를 사용하거나 Class의 특징을 나타내는 Suffix를 사용할 수 있습니다.
Prefix는 시스템의 특징을 나타내는(구별하는) 취지에서 사용합니다.
Suffix는 파일구조에서 말하는 확장자가 아니고, 클래스이름을 정할 때 이름의 끝에 들어가는 접미사로 파일의 클래스의 특징 및 해당 이름을 가진 코드들의 기능(데이터삭제, 등록, 조회 등)을 구별하는 취지에서 사용합니다.
서브시스템이 존재하는 프로젝트에서는 Prefix로 서브시스템을 나타내는 문자를 사용할 것을 권장합니다.

2.5 Interface

다음 규칙은 인터페이스 명명 지침을 요약한 것 입니다.

인터페이스 이름을 지정할 때는 명사 또는 명사구나 동작을 설명하는 형용사를 사용합니다.
예를 들어, Component라는 인터페이스 이름에서는 설명적인 명사를 사용합니다.
또한 CustomAttributeProvider라는 인터페이스 이름에서는 명사구를 사용하며, Persistable라는 이름에서는 형용사를 사용합니다.
파스칼식 대문자 표시 스타일을 사용합니다.
약어는 꼭 필요한 경우에만 사용합니다.
클래스가 인터페이스의 표준 구현인 경우 해당 클래스/인터페이스 쌍을 정의할 땐느 유사한 이름을 사용합니다. 클래스 이름에 Impl 접미사가 있는 점만 제외하고 두 이름은 동일해야 합니다.
밑줄(_)을 사용하지 않습니다.

public interface CodeService {
    // Implementation code goes here.
}

// 인터페이스
public interface CodeService {
    // Implementation code goes here.
}

// 인터페이스 구현 클래스
public class CodeServiceImpl implements CodeService {
    // Implementation code goes here.
}

2.6 Method

다음 규칙은 클래스의 멤버 메서드 명명 지침을 요약한 것 입니다.

메소드는 동사를 사용합니다.
첫 번째 문자는 소문자로 나타냅니다.
여러 단어가 조합될 경우 조합되는 단어의 첫 번째 문자는 대문자로 시작되어야 합니다.
get / set 메서드
- 클래스 멤버변수 접근(Access)을 위한 get / set 뒤에 멤버변수명을 쓰는 것을 원칙으로 합니다.
메서드 명은 동사형으로 시작하며 동사 + 목적어 형태로 기술합니다.
메서드 명은 구체적인 용어로 표기하지 않고, 일반적인 메시지 형태로 표기합니다.
- 잘못된 예) saveToDB() – DB같은 구체적인 용어를 사용하지 말고 일반적인 메시지 형태로 표기

// get / set 메서드
private String name = null;
public String getName() {
    return name;
}
public void setName(String name) {
    this.name = name;
}

// 그 밖의 메서드
create(), checkOut(), attachToDesk(), fileTransfer(), run() 등

2.7 변수

다음 규칙은 변수 명명 지침을 요약한 것 입니다.

첫 번째 문자는 소문자로 나타냅니다.
변수 및 필드 이름에는 헝가리어 표기법 접두사를 사용하지 않습니다. 단, 임시변수는 헝가리안 표기법으로 작성합니다.
여러 단어가 조합될 경우 조합되는 단어의 첫 번째 문자는 대문자로 시작되어야 합니다.
변수명의 시작을 밑줄문자(_) 또는 $ 문자로 사용하지 말아야 합니다.
변수명은 짧으면서도 충분히 의미가 느껴지도록 하고, 뇌리에 선명하게 남도록 하는 것을 정해야 합니다.
Collection type의 변수 이거나 배열인 경우 복수로 표현한다.
멤버 변수
- 멤버 변수라 함은 메서드 외부에서 정의하는 변수를 의미한다.
- final 상수 제외 : 상수에 대한 규칙은 2.8 상수 참고
- 접근자(Access Modifier)
  - 클래스의 멤버변수 영역은 protected를 원칙으로 한다.
  - Protected로 선언된 멤버변수가 하위 클래스를 제외한 다른 클래스에서 사용될 때는 get / set 메서드를 사용하도록 한다.
  - 변수의 특징에 따라 Access Modifier는 변경될 수 있다.(get / set 메서드에 대한 규칙 2.6 Method 참고)

protected int objID;
private Table tableTab;

로컬 변수라 함은 Method 내에 정의하는 변수를 의미한다.
- 로컬 변수의 첫 문자는 소문자로 사용하고, 여러 단어가 조합될 경우 조합되는 단어의 첫 번째 문자는 대문자로 시작한다.

float myWidth;
String userID;
int seq;

임시 변수라 함은 loop 문이나 condition 문에서 임시로 사용하는 변수를 의미한다.
- 임시변수는 헝가리안 표기법(Hungarian Notation)으로 작성합니다.
- 한 개의 문자로 변수명을 구성하는 것은 임시 변수인 경우에만 사용하며, 다음과 같이 정의한다.

i, j, k, l // 정수형
c, d // 문자형 임시 변수
x, y, z // 좌표
e // 예외
g // 그래픽
o // 객체
s // 문자열

2.8 상수

클래스 상수 또는 일반 상수로 정의된 변수명은 Snake Case를 사용한다. 즉, 단어 간의 밑줄문자(_)로 분리되는 대문자 사용한다.

static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;

2.9 파라미터(인자)

생성자(Constructor)나 set Method에서 멤버 필드에 값을 지정할 때, 파라미터 이름은 멤버 필드 이름과 동일하게 부여 한다.(this 키워드 사용)

public class Dude {
     private String name;
     public Dude(String name) {
        this.name = name;
     }
     public void setName(String name) {
         this.name = name;
     }
}

3. 주석 사용 지침

3.1 일반 사항

일반적으로 코드만 가지고는 정확하게 코드가 의미하는 바가 무엇인지 이해하기 힘들다.
주석(Comment)은 코드에 추가적인 설명을 달아서 코드를 보다 읽기 쉽게 만들어 준다.
여기에서는 개발자들이 준수해야 하는 주석 사용 지침을 설명한다.
코드에 장식을 하지 않는다(배너식의 주석 사용을 자제한다.)
주석은 가능한 단순하게 한다.
코드 작성 이전에 주석부터 작성한다.
‘무엇이 되었다’가 아니라 ‘무엇이 이러한 이유로 이렇게 되었다’ 식으로 작성한다.
주석 위치는 클래스의 시작, 각 메서드 선언의 바로 위에 한다.
메서드 내부에서도 단계별로 구분지어서 설명할 필요가 있을 때도 주석을 작성한다.
변수 하나의 의미를 쓰는 주석 등은 사용하지 않는다.
변수 이름을 명확하게 주어서 주석 작성의 필요를 제거한다.

3.2 주석의 종류 및 사용방법

주석의 종류사용 방법

문서화 주석		/** … */
코드구현 주석	블록주석	/* * … */
	Single-line 주석	/* */
	Trailing 주석	소스코드 + /* */
	End-of-Line 주석	//

3.2.1 기본 원칙

클래스(또는 인터페이스), 메서드, 멤버 변수의 주석으로는 JavaDoc 주석 사용을 권장한다.
메서드 안의 코드 설명 또는 로컬변수의 주석으로는 단일라인 주석만 사용한다.

3.2.2 문서화 주석

3.2.2.1 Class Comments

모든 소스의 가장 앞 부분에 다음과 같이 클래스 이름, 하는 작업, 작성일 Comments와 버전정보, 작성자를 명기한다.
여기서 작성일과 작성자의 다음의 괄호 부분엔 수정일과 수정자의 이름이 명기되며 수정일 뒤에는 수정이유를 간단하게 밝힌다.

/**
 * <pre>
 * 각종 문자열, 스트링, 데이트 형식에 따른 유틸리티
 * </pre>
 *
 * @author COMPANY.co., Ltd
 * @version
 * <ul>
 *     <li>1.0.0 (2025.03.28) 홍길동(test@company.co.kr) - 최초 구현</li> 
 * </ul>
 * @code <pre>{@code
 * @Autowired
 * private FormatUtil formatUtil;
 * }</pre>
 * @since 2025.03.28
 */

3.2.2.2 Method Comment

/**
 * <pre>
 * 현재 실행 중인 스레드의 ClassLoader 객체를 반환하며, 만약 해당 스레드에 ClassLoader 객체가 설정되지 않은 경우, 대체 객체(defaultObject)의 클래스에 대한 ClassLoader 객체를 반환
 * </pre>
 *
 * @param defaultObject 대체 객체
 * @return the class loader
 * @code <pre>{@code
 * @Autowired
 * this.getCurrentClassLoader(params)
 * }</pre>
 * @history
 * <ul>
 *     <li>2025.03.28 홍길동(test@company.co.kr) - 최초 구현</li>
 * </ul>
 */

3.2.3 단일 라인 주석(Single Line Comment)

// 로 시작하며, 해당 라인의 끝까지 적용된다.
설명하고자 하는 코드의 바로 윗줄이나, 코드와 같은 라인의 오른쪽에 작성한다.
하나의 라인이나 한 라인의 일부를 주석처리해서 컴파일 되지 않도록 임시로 막을때로 사용된다.

public class FileStream {
    // 여기에 코드를 입력하세요.
}

3.2.4 블럭 주석(Block Comment)

/* 로 시작하여 */ 까지 적용된다.
메서드안에서는 단일라인 주석을 사용한다.
짧은 내용의 주석을 다음 라인에 기술될 코드이 들여쓰기에 맞춰서 한 라인에 표현할 수 도 있다.
만약 한 라인에 다 표현하지 못 할 경우에는 블록주석 방식을 사용한다.
한줄 또는 여러 줄을 주석처리하거나, 코드의 블록이 컴파일 되지 않게 임시로 막을 때로 사용된다.

public class FileStream {
    /*
    여기에 코드를
    입력하세요.
    */
}

3.2.5 Trailing comment

매우 짧은 주석으로 사용할 수 있는 코드로써 같은 라인에 나타낼 수 있지만 코드를 문(statement)으로부터 분리하기 위해서는 충분히 떨어져야 한다.
만일 하나 이상의 짧은 주석이 큰 덩어리의 코드로 나타날 경우 동일한 위치에서 들여쓰기를 하여야 한다.

if(a==2) {
    return true;           /* special case */
} else {
    return isPrime(a);     /* works only for odd a */
}

3.2.6 End-of-Line Comment

“//” comment delimiter는 라인 전체 또는 일부를 주석으로 처리 할 수 있으며 “//”는 문장 주석을 위한 연속한 여러 라인에 사용되어서는 안된다.
단, 코드의 특정섹션을 처리하기 위해서는 연속한 라인에 사용 되어도 무방하다.
변수선언 후 변수에 대한 설명으로 사용하거나 또는 특정라인에 대한 설명으로 사용한다.
복잡한 제어구조에서 각 제어문의 끝을 나타내기 위해서 사용한다.

for(…) {
    while(…){
        if(…) {
            switch(…) {
                 …
            } // end switch
        } // end if
    } // end while
} // end for

3.3 IntelliJ Class/Method Comment Template 설정 방법

3.3.1 Class

아래 그림과 같이 설정> 도구> JavaDoc> Templates 이동 후 Class level Regular expression 설정 변경

.+ : 목록 순서를 첫번째로 변경
개발자_이름 : 본인 이름 입력
이메일 계정 : 본인 이메일 계정

/**\n
* <pre>\n
* 여기에 설명을 작성하세요.\n
* </pre>\n
* @apiNote (선택)API 사용자(개발자)가 알아야 할 중요한 사항을 기록\n
* @implSpec (선택)구현 클래스가 반드시 따라야 할 규칙을 명시\n
* @implNote (선택)구현 방식을 변경할 때 고려해야 할 점 등을 설명\n
* @since ${.now?string('yyyy.MM.dd')}\n
* @author Company.co., Ltd\n
* @version\n
* <ul>\n
*     <li>1.0.0 (${.now?string('yyyy.MM.dd')}) 개발자_이름(이메일_계정@company.co.kr) - 최초 구현</li>\n
* </ul>\n
* @code <pre>{@code\n
*  }</pre>\n
<#if element.typeParameters?has_content>        * \n
</#if>
<#list element.typeParameters as typeParameter>
        * @param <${typeParameter.name}> the type parameter\n
</#list>
*/

3.3.2 Method

아래 그림과 같이 설정> 도구> JavaDoc> Templates 이동 후 Method level Regular expression 설정 변경

.+ : 목록 순서를 첫번째로 변경
개발자_이름 : 본인 이름 입력
이메일 계정 : 본인 이메일 계정

/**\n
 * <pre>\n
 * 여기에 Method 설명을 작성하세요.\n
 * </pre>\n
<#if element.typeParameters?has_content>         * \n
</#if>
<#list element.typeParameters as typeParameter>
         * @param <${typeParameter.name}> the type parameter\n
</#list>
<#if element.parameterList.parameters?has_content>
         *\n
</#if>
<#list element.parameterList.parameters as parameter>
         * @param ${parameter.name} the ${paramNames[parameter.name]}\n
</#list>
<#if isNotVoid>
         *\n
         * @return the ${return}\n
</#if>
<#if element.throwsList.referenceElements?has_content>
         *\n
</#if>
<#list element.throwsList.referenceElements as exception>
         * @throws ${exception.referenceName} the ${exceptionNames[exception.referenceName]}\n
</#list>
 * @code <pre>{@code\n
 * 여기에 Method 사용법을 작성하세요.\n
 * }</pre>\n
 * @history\n
 * <ul>\n
 *     <li>${.now?string('yyyy.MM.dd')} 개발자_이름(이메일_계정@company.co.kr) - 최초 구현</li>\n
 * </ul>\n
 */

4. 선언(Declaration)

4.1 Number per Line

한 라인당 하나의 선언이 추천되는데 이는 주석을 달기 좋기 때문이다.

int level; // indentation level
int size; // size of table
object currentEntry; // currently selected table entry

아래의 코드보다 위의 코드가 가독성이 편리하다.

int level, size;

다음 예처럼 서로 다른 유형을 동일라인에 표현하는 것은 피해야 한다.

int foo, fooArray[]; // wrong!

4.2 배치

선언문의 배치는 블록의 제일 앞에 배치한다.
여기서 블록이란 중괄호”{“, “}”로 둘러쌓인 모든 코드를 말한다.
선언문이 블록의 중간에 나타나는 것은 좋은 방법이 아니다.
상위 레벨의 선언을 무효화 시키는 지역선언은 배제되어야 하며 예를 들어 내부 블록내에 동일한 변수명을 선언하는 것은 좋지 않다.

int count;
…
myMethod() {
    if(condition) {
        int count = 0; // AVOID!
    }
}

4.3 클래스와 인터페이스 및 배열 선언

클래스나 인터페이스를 개발 할 때에는 다음과 같은 구성 원칙을 따른다.

메서드는 이름과 파라메터 목록이 시작되는 괄호”(“ 사이에는 공백을 두지 않는다.
열린 중괄호(opening brace, “{“)는 선언문과 같은 라인에 위치한다.
닫힌 중괄호(closing brace, “}”)는 열린 중괄호와 상응하도록 들여쓰기를 적용하되 열린 중괄호 뒤가 null 문장인 경우에는 닫힌 중괄호가 바로 대치되도록 한다.
메서드는 공백라인에 의해 분리된다.
상황에 따라서는 열린 중괄호를 선언문 다름 라인에 위치 할 수도 있다.
배열선은은 타입 바로 다음에 배열기로”[ ]”가 오게 한다.

5. 공백 및 들여쓰기

5.1 공백 라인

공백 라인은 논리적으로 관련된 코드 섹션을 분리하여 가독성을 향상 시킨다.

두줄의 공백 라인은 다음 상황에서만 사용한다.

소스파일의 섹션 구분
클래스나 인터페이스의 정의 구분

한줄의 공백 라인은 다음의 상황에서만 사용한다.

메서드의 구분
메서드 내의 지역변수와 첫 문장 구분
블록 주석 또는 단일문 주석의 앞
가독성 향상을 위해 메서드 내의 논리 섹션간의 구분
package 선언 후

5.2 공백 문자

공백 문자는 다음과 같은 상황에서 사용된다.

매개변수 목록에서 콤마(,) 다음에 공백문자를 사용한다.
“.”를 제외한 모든 Binary 연산자는 Operand로부터 공백문자를 통해 분리되며 공백문자는 단항연산자(unary), minus(“-“), increment(“++”), decrement(“--“)등과 같은 단항연산자를 operend로부터 분리해서는 안된다.
for 문 내의 표현식은 공백문자에 의해 분리되어야 한다.
형 변환에 공백문자를 사용한다.

5.3 줄 간 이어 쓰기

Comma(“,”)뒤에서 분리
연산자 다음에 분리
레벨에 있어서는 하위 레벨보다는 상위 레벨에서 분리
새 라인은 이전 동일 레벨에 있는 표현문장의 시작위치에 맞추어야 한다.
만약 위 원칙이 코드를 혼란케 하거나 오른쪽 여백을 손상케 하는 경우에는 그냥 2개의 공백문자를 이용하여 들여쓰기를 하여야 한다.
조건문 작성시 조건문이 길어질 경우 조건당 한줄로 작성한다.
If 조건절의 줄간 이어쓰기는 일반적으로 2개의 공백문자를 사용한다.

6. 기타

6.1 인스턴스와 클래스 변수에 대한 접근 허용

인스턴스 변수에 대한 public 접근은 사능한 허용해서는 안된다.
대체로 인스턴스 변수는 명시적으로 값을 설정하거나 읽혀질 필요성을 지니고 있지 않은데, 명시적으로 값이 설정 또는 읽혀질 경우는 메서드 호출의 부작용으로 발생한다.
클래스가 단순히 자료구조의 역할을 하는 경우에는 인스턴스 변수를 public으로 접근하도록 한다

6.2 클래스 변수와 메서드의 참조

클래스 변수와 클래스 메서드에 접근하기 위해 오브젝트 인터페이스는 가능한 이용해서는 안된다.

6.3 상수

숫자 상수는 직접코드화 하지 말고, 반드시 정의한 후 사용한다.
-1, 0, 1 등과 같이 for loop 에서 counter로 사용되는 상수들은 그냥 사용해도 무방하다.

6.4 변수 할당

단일문에서 여러 번수에 동일한 값을 할당 할 경우 가독성이 저하된다.
Equality operator('==')와 쉽게 혼동 될 수 있는 위치에서의 Assignment('=') 사용은 가급적 지양한다.

6.5 괄호

연산자가 복잡하게 사용 된 경우에 연산자 우선순위 문제를 해결하기 위해 괄호를 활발하게 사용하는 것을 권장한다.
이는 실상 연산자 우선순위가 개발자 본인에게는 명백히 보인다 할지라도 다른 개발자를 위한 배려를 베풀어야 한다.

6.6 기타 고려사항

여러 줄의 String을 결합할 경우 String = String + String 보다는 StringBuffer를 사용한다.
비록 크기가 작은 클라스하도 새로 인스턴스화 하지 말고 최대한 재 사용해야 좋은 성능을 얻을 수 있다.

Git Branch Strategy

그레고리오78 — Tue, 27 Jan 2026 16:31:59 +0900

1. Promise & Branch Role

1.1 Promise

※ 작업을 할 때 지켜야 할 서로 간의 약속입니다.

작업 시작하기 전 {{ticket or task}} 로 Branch를 생성한다.
하나의 {{ticket or task}}은 되도록 하나의 commit으로 한다.
commit graph는 최대한 단순하게 가져간다.
서로 공유하는 branch의 commit graph는 함부로 변경하지 않습니다.
Reviewer(=Project Leaser or Part Leader or 동료)에게 꼭 Review를 받습니다.
자신의 Pull Request는 스스로 merge 합니다.

1.2 Branch Role

Branch	내용	비고
master	Source의 안전한 보관을 위한 branch	production merge 후 2주/4주 경과된 branch merge
production	Staging 테스트가 끝난 기능에 대해 운영환경에 배포하기 위한 branch
staging (option)	production merge 전 운영환경과 유사한 환경 테스트를 위한 branch
hotfix	출시 버전에서 발생한 버그를 수정하는 branch
develop	다음 출시 버전을 준비하는 branch
feature	모든 기능 구현은 feature branch에서 시작	feature/{{ticket or task no}} feature/251

2. Branch Flow(예시)

2.1 1안

2.2 2안

3. Conflict (충돌) 해결 절차

Git Conflict (충돌) 해결 절차

Git 병합 충돌의 발생 원인과 해결 방법

충돌 발생 시나리오

main 브랜치

feature 브랜치

⚠️ C와 E가 같은 파일의 같은 부분을 수정 → 충돌 발생!

⚠️ 충돌 파일 예시 (Conflict Markers)

<<<<<<< HEAD 현재 브랜치의 변경 사항 (예: main) const title = "Main Branch Title"; ======= 병합하려는 브랜치의 변경 사항 (예: feature) const title = "Feature Branch Title"; >>>>>>> feature

충돌 해결 절차

충돌 발견

merge 또는 rebase 시 충돌이 발생하면 Git이 자동으로 알려줍니다.

$ git merge feature Auto-merging file.js CONFLICT (content): Merge conflict in file.js Automatic merge failed; fix conflicts and then commit the result.

↓

충돌 파일 확인

충돌이 발생한 파일 목록을 확인합니다.

$ git status On branch main You have unmerged paths. Unmerged paths: (use "git add <file>..." to mark resolution) both modified: file.js

↓

충돌 해결 방법 선택

아래 3가지 방법 중 하나를 선택하여 충돌을 해결합니다.

충돌 해결 방법

✅ 방법 1: 현재 브랜치 변경사항 유지

현재 브랜치(HEAD)의 변경사항을 선택합니다.

$ git checkout --ours file.js $ git add file.js

✅ 방법 2: 들어오는 브랜치 변경사항 유지

병합하려는 브랜치의 변경사항을 선택합니다.

$ git checkout --theirs file.js $ git add file.js

✅ 방법 3: 수동으로 편집

파일을 직접 열어서 충돌 마커를 제거하고 원하는 대로 수정합니다.

# 1. 에디터로 파일 열기 # 2. <<<<<<<, =======, >>>>>>> 제거 # 3. 원하는 코드로 수정 $ git add file.js

충돌 해결 완료

변경사항 스테이징

해결한 파일을 스테이징 영역에 추가합니다.

$ git add <충돌해결된파일> # 또는 모든 파일 추가 $ git add .

↓

병합 커밋 생성

충돌 해결 후 병합 커밋을 완료합니다.

$ git commit -m "Merge conflict resolved" # 또는 기본 병합 메시지 사용 $ git commit

↓

원격 저장소에 푸시

해결된 내용을 원격 저장소에 반영합니다.

$ git push origin main

병합 취소 (충돌 해결 포기)

충돌 해결이 어렵거나 병합을 취소하고 싶을 때:

$ git merge --abort # 또는 rebase 중이었다면 $ git rebase --abort

충돌을 줄이는 Best Practices

자주 pull/merge: main 브랜치의 최신 변경사항을 자주 가져와 큰 충돌을 방지
작은 단위로 커밋: 작고 논리적인 단위로 자주 커밋하여 충돌 범위 최소화
코드 리뷰: Pull Request를 통해 병합 전 코드 리뷰로 충돌 예방
책임 영역 분리: 팀원들이 서로 다른 파일/모듈을 작업하도록 조율
IDE 도구 활용: VS Code, IntelliJ 등의 병합 도구 활용으로 시각적 해결
테스트 실행: 충돌 해결 후 반드시 테스트를 실행하여 정상 동작 확인

️ 충돌 해결 도구

VS Code

내장된 3-way merge 에디터로 충돌을 시각적으로 해결할 수 있습니다. "Accept Current Change", "Accept Incoming Change", "Accept Both Changes" 버튼 제공.

Git GUI Tools

GitKraken, SourceTree, GitHub Desktop 등 GUI 도구들은 충돌을 시각적으로 표시하고 쉽게 해결할 수 있는 인터페이스를 제공합니다.

git mergetool

명령줄에서 외부 병합 도구(vimdiff, meld, kdiff3 등)를 실행하여 충돌을 해결할 수 있습니다.

$ git mergetool

MySQL UTC 설정

그레고리오78 — Tue, 27 Jan 2026 16:19:37 +0900

1. 파일 다운로드 및 unzip 설치

1.1 파일 다운로드

# 다운로드 경로 이동
cd /usr/share/zoneinfo/

# 다운로드
wget https://downloads.mysql.com/general/timezone_2025b_posix_sql.zip

1.2 unzip 설치 및 압축 해제

# 설치
sudo dnf install -y unzip
# 압축 해제
unzip timezone_2025b_posix_sql.zip

2. Database

2.1 MySQL 현재 시간대 확인

SELECT @@global.time_zone, @@session.time_zone;

적용 전

+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM             | +09:00 (또는 현재 서버 시간대) |
+--------------------+---------------------+

적용 후

+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| +00:00             | +00:00              |
+--------------------+---------------------+

2.2 MySQL 설정 정보 변경

mysql config 추가

sudo vi /etc/my.cnf

아래 내용 입력

[mysqld]
default_time_zone = '+00:00'

mysql 서비스 재시작

sudo systemctl restart mysql

2.3 TimeZone 정보 설치

use mysql;
SOURCE /usr/share/zoneinfo/timezone_2025b_posix_sql/timezone_posix.sql;

2.4 데이터 저장 및 조회

조회 : TimeZone(예: 남아공 Africa/Johannesburg)을 기준으로 조회

SELECT CONVERT_TZ(CONVERT_TZ(), 'UTC', 'Africa/Johannesburg');

저장 : UTC 기준으로 저장

SELECT UTC_TIMESTAMP();

3. Spring Boot 설정

# application.yml
spring:
  jackson:
    time-zone: UTC
  datasource:
    url: jdbc:mysql://localhost:3306/your_db?serverTimezone=UTC

4. Docker 환경에서 UTC 시간 고정

대상설정 방법

Container OS 시간대	TZ=UTC 환경 변수 설정 또는 /etc/localtime 볼륨 마운트
Spring Boot Container	TZ=UTC 환경 변수 + application.yml에서 time-zone 설정

4.1 Container OS 시간대

Docker run 예시

docker run -e TZ=UTC image-file

docker-compose.yml 예시

services:
  app:
    image: your-spring-boot-app
    environment:
      - TZ=UTC

4.2 Spring Boot Container

Dockerfile 또는 docker-compose.yml 예시

services:
  spring-app:
    image: your-spring-boot-app
    environment:
      - TZ=UTC

4.3 확인 방법

docker exec -it container-name date

출력 예

Thu May  8 10:00:00 UTC 2025

Spring Cloud Netflix Eureka 구축 방법

그레고리오78 — Tue, 27 Jan 2026 16:08:13 +0900

1. Spring Cloud Netflix Eureka 개념

1.1 Eureka란?

Eureka는 Netflix OSS 기반의 Service Discovery(Server/Client) 컴포넌트로, MSA 환경에서 각 마이크로서비스의 위치(IP, Port)를 동적으로 관리합니다.

핵심 역할

서비스 등록(Register)
서비스 조회(Discovery)
헬스 체크(Heartbeat)
장애 인스턴스 제거(Self-Preservation)

1.2 Eureka 구조

Eureka 디스커리비 서비스 구조

Eureka Server (Port: 8761)

서비스 레지스트리 역할
등록된 서비스 목록 관리
30초마다 Heartbeat로 Health Check

Eureka Clients (마이크로서비스들)

User Service (8081)
Order Service (8082)
Product Service (8083)
Payment Service (8084)
각 서비스는 @EnableEurekaClient 어노테이션 사용

API Gateway (Port: 8080)

Eureka에서 서비스 목록 조회
동적 라우팅 및 로드밸런싱

동작 흐름:

서비스 등록: 각 서비스가 시작 시 Eureka에 자신의 정보 등록
Heartbeat: 30초마다 살아있음을 알림
서비스 조회: Gateway가 Eureka에서 서비스 위치 파악
동적 라우팅: 요청을 적절한 서비스로 전달

장점:

동적 서비스 발견, 로드 밸런싱, Health Check
자가 복구, 동적 확장, 무중단 배포

구분	설명
Eureka Server	서비스 목록 저장 및 관리
Eureka Client	서비스 자신을 서버에 등록
Heartbeat	주기적 상태 보고
Self-Preservation	네트워크 장애 시 서비스 보호

1.3 Eureka를 사용하는 이유 (SI·MSA 관점)

항목	설명
고정 IP 제거	Auto Scaling 환경 대응
장애 대응	Down 인스턴스 자동 제거
서비스 분리	Gateway·Client 간 결합도 감소
클라우드 친화	Docker / Kubernetes / AWS에 적합

2. IntelliJ IDEA에서 Eureka Server 프로젝트 생성 방법

2.1 프로젝트 생성 절차

IntelliJ IDEA → New Project
Spring Initializr 선택
Project 설정
- Project: Maven
- Language: Java
- Spring Boot: 3.2.x 또는 3.3.x 권장
- Group: com.example
- Artifact: eureka-server
- Packaging: Jar
- Java: 17
Dependencies 선택
- Spring Cloud Discovery → Eureka Server
- (Optional) Spring Boot Actuator
Finish

2.2 Spring Cloud 버전 설정 (중요)

pom.xml에 Spring Cloud BOM 반드시 추가해야 합니다.

Spring Boot 3.x + Spring Cloud 2023.x 조합 필수

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2023.0.1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

3. Eureka Server 애플리케이션 구성

3.1 메인 클래스 설정

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

4. application.yml 구성 예제 (Eureka Server)

4.1 단일 Eureka Server (개발·기본)

server:
  port: 8761

spring:
  application:
    name: eureka-server

eureka:
  client:
    register-with-eureka: false   # Server는 Client가 아니므로 false
    fetch-registry: false         # 단일 서버일 경우 false
  server:
    enable-self-preservation: true # 네트워크 장애 대비

4.2 운영 환경용 (권장 옵션 포함)

server:
  port: 8761

spring:
  application:
    name: eureka-server

eureka:
  instance:
    hostname: eureka-01
  client:
    register-with-eureka: false
    fetch-registry: false
    service-url:
      defaultZone: http://eureka-01:8761/eureka/
  server:
    eviction-interval-timer-in-ms: 60000
    enable-self-preservation: true

4.3 Eureka Server HA 구성 (2대 이상)

실무에서는 Load Balancer + 2~3대 Eureka Server 구성 권장

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: >
        http://eureka-01:8761/eureka/,
        http://eureka-02:8761/eureka/

5. Eureka Client (Spring Boot)

spring:
  application:
    name: order-service

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/
  instance:
    prefer-ip-address: true

6. 실무 운영 시 주의사항

항목	권장
Eureka 보안	내부망 전용
Gateway 연계	Gateway는 반드시 Eureka Client
Kubernetes	K8s 환경에서는 Eureka 대신 K8s Service 고려
장애 보호	Self-Preservation 비활성화 금지
모니터링	Actuator + /actuator/health 연계

Agile의 가치/원칙 및 전략/운영/연계

그레고리오78 — Tue, 27 Jan 2026 15:47:03 +0900

1. Agile Manifesto 4대 가치 · 12원칙 정리

1.1 Agile Manifesto 4대 가치

프로세스와 도구보다 개인과 상호작용
계약 협상보다 고객과의 협업
계획 준수보다 변화에 대한 대응
포괄적인 문서보다 작동하는 소프트웨어

1.2 Agile 12원칙 요약

고객 만족을 최우선으로 한다
요구사항 변경을 환영한다
짧은 주기로 작동하는 소프트웨어를 제공한다
비즈니스와 개발자는 매일 협업한다
동기부여된 개인 중심의 팀을 구성한다
대면 커뮤니케이션을 가장 효과적으로 본다
작동하는 소프트웨어가 진척도의 기준이다
지속 가능한 개발 속도를 유지한다
기술적 완성도와 좋은 설계를 중시한다
단순성을 추구한다
자율적인 팀에서 최상의 결과가 나온다
정기적으로 프로세스를 개선한다

2. SI·공공 프로젝트에서 Agile 적용 전략

2.1 공공·SI 프로젝트의 현실적 제약

제약 사항	설명
계약 구조	고정 범위·고정 금액
문서 요구	산출물 중심 평가
변경 관리	절차·승인 복잡
감사·감리	Waterfall 기반 기준

"순수 Agile 적용은 현실적으로 어려움"이 있다.

2.2 실무적 대안: Hybrid Agile

“관리 체계는 Waterfall, 실행은 Agile”

영역	적용 전략
요구사항	상위 요구사항 고정 + 상세 요구사항 Sprint 단위
문서	Sprint 산출물을 문서로 환원
변경	Change 요청 → Backlog 재정렬
감리	Sprint 결과물 기준 검증

3. Scrum 기반 실무 운영 예시

3.1 Scrum 기본 구성

역할	책임
Product Owner	요구사항 우선순위
Scrum Master	프로세스 관리
Dev Team	개발·테스트

3.2 실무 Sprint 운영 흐름

2주(10일) Sprint 주기

Sprint 사이클 (2주/10일):

Sprint Planning (4시간)
- Sprint Goal 설정
- User Story 선정
- Task 분해 및 추정
개발 기간 (10일)
- 설계 및 구현
- 코드 리뷰, 단위/통합 테스트
- CI/CD 파이프라인, 버그 수정
Daily Scrum (매일 15분)
- 어제 무엇을 했나?
- 오늘 무엇을 할 것인가?
- 장애물이 있나?
- 서서 진행, 같은 시간/장소
Sprint Review (2시간)
- 완성된 기능 시연
- 이해관계자 피드백
- Product Backlog 조정
Sprint Retrospective (1.5시간)
- 잘한 점 (Keep)
- 개선할 점 (Problem)
- 실행 계획 (Try)

핵심 특징:

Daily Scrum은 개발 기간 동안 매일 반복
모든 이벤트는 Time-boxed
회고 후 다음 Sprint로 순환

4. MSA·DevOps 환경에서 Agile 연계 구조

4.1 Agile + MSA 구조적 궁합

Agile 특성	MSA와의 연계
반복 개발	서비스 단위 배포
자율 팀	서비스별 독립 팀
빠른 피드백	독립 장애 영향

4.2 Agile · DevOps · MSA 통합 구조

Agile = 개발 방식, DevOps = 전달 방식, MSA = 구조적 기반

4.3 실무 기술 스택 예시

영역	기술
Gateway	Spring Cloud Gateway
Discovery	Eureka
CI/CD	Jenkins + Docker
Infra	AWS / Kubernetes
Observability	ELK, Loki, Prometheus
Config	Spring Cloud Config

Agile 개발방법론

그레고리오78 — Tue, 27 Jan 2026 15:28:19 +0900

1. 요구사항의 지속적인 변화와 단순 설계의 시작 기법, Agile 방법론의 개요

전통적인 소프트웨어 개발 환경에서는 요구사항을 초기에 명확히 정의하고 이를 기반으로 순차적으로 개발을 진행하는 방식이 주를 이루었다. 그러나 인터넷, 모바일, 클라우드 환경의 확산과 함께 비즈니스 환경이 급변하면서 요구사항은 개발 도중에도 지속적으로 변경되는 것이 일반화되었다. 이러한 변화 속에서 초기 요구사항을 고정하는 방식은 오히려 프로젝트 실패의 원인이 되었다.

Agile 방법론은 이러한 한계를 극복하기 위해 등장하였다. Agile의 핵심 전제는 “변화는 필연적이며, 변화에 대응하는 능력이 곧 경쟁력”이라는 인식이다. 따라서 Agile에서는 모든 요구사항을 처음부터 완벽히 정의하지 않고, 가장 중요한 기능부터 단순하게 설계(Simple Design) 한 뒤 반복적(iterative)으로 개선해 나간다.

즉, Agile은 다음과 같은 개발 철학을 기반으로 한다.

요구사항은 개발 과정 전반에 걸쳐 지속적으로 진화한다.
완벽한 초기 설계보다 지속적인 피드백과 개선이 중요하다.
짧은 개발 주기를 통해 빠르게 가치를 전달한다.

이러한 철학을 구체화한 것이 Agile 개발방법론이며, 이는 2001년 발표된 Agile Manifesto(애자일 선언문)를 이론적 기반으로 한다.

2. Agile 방법론의 특징 및 종류

2.1 Agile 방법론의 주요 특징

Agile은 “빠르게 만들고, 자주 검증하며, 지속적으로 개선하는 개발 방식”이다.

주요 특징	개념적 설명	실무 적용 관점
반복적·점진적 개발 (Iterative & Incremental)	짧은 주기로 설계·개발·테스트를 반복하며 기능을 점진적으로 확장	Sprint 단위로 기능을 나누어 개발 및 단계적 오픈
변화 중심 요구사항 관리	요구사항 변경을 예외가 아닌 정상 흐름으로 수용	Backlog 재정렬로 변경사항 즉시 반영
단순 설계(Simple Design)	현재 요구사항을 충족하는 최소 설계부터 시작	과도한 선설계 제거, 리팩토링 전제
작동하는 소프트웨어 우선	문서보다 실제 동작 가능한 결과물 중시	Sprint 종료 시 실행 가능한 화면·API 제공
고객과의 지속적 협업	고객·업무 담당자가 개발 과정에 직접 참여	Sprint Review를 통한 정기 피드백
자율적·협업 중심 팀	팀이 스스로 계획·추정·문제 해결 수행	PO·개발팀 간 의사결정 최소 간섭
지속 가능한 개발 속도	단기 성과보다 장기적 안정성 중시	무리한 야근 배제, Velocity 관리
품질 내재화	테스트와 품질 관리를 개발 과정에 통합	TDD, 자동화 테스트, CI 적용
투명한 진행 상황 공유	진행 상황을 실시간으로 가시화	Task Board, Burn-down Chart 활용
지속적 개선(Inspect & Adapt)	정기적 회고를 통해 프로세스 개선	Sprint Retrospective 실행

2.2 Agile 방법론의 종류

Agile은 단일 방법론이 아니라, 여러 실천 기법(Methodology)의 집합이다. 대표적인 종류는 다음과 같다.

방법론주요 특징

방법론	주요 특징
Scrum	가장 널리 사용, Sprint 기반 개발, Product Owner·Scrum Master·Development Team 역할 구분
XP (Extreme Programming)	코드 품질 강조, TDD, Pair Programming, 지속적 통합(CI)
Kanban	작업 흐름 시각화, WIP 제한, 운영·유지보수 환경에 적합
Lean Software Development	낭비 제거, 가치 중심 개발
SAFe (Scaled Agile Framework)	대규모 조직에서 Agile 확장 적용

3. Agile 방법론과 전통적 개발 방법론 비교

Agile 방법론과 전통적 개발 방법론(Waterfall 등)은 근본적인 접근 방식에서 차이가 있다.

구분	전통적 개발 방법론	Agile 방법론
요구사항	초기에 고정	지속적으로 변경 가능
개발 방식	순차적 단계 진행	반복·점진적 개발
설계	상세 설계 선행	단순 설계 후 점진적 보완
고객 참여	제한적	지속적 참여
변경 관리	비용·절차 부담 큼	자연스럽게 수용
산출물	최종 단계에서 제공	반복 주기마다 제공
리스크 대응	후반에 집중	초기부터 분산 관리

전통적 방법론은 요구사항이 명확하고 변경 가능성이 낮은 프로젝트에 적합한 반면, Agile은 불확실성과 변화가 큰 환경에서 강점을 발휘한다.

4. Agile 방법론의 적용분야 및 평가

4.1 Agile 방법론의 적용 분야

Agile 방법론은 현재 다음과 같은 분야에서 활발히 적용되고 있다.

웹·모바일 서비스 개발
클라우드 및 MSA 기반 시스템
스타트업 및 신사업 개발
DevOps·CI/CD 환경
SI 프로젝트 중 일부 모듈 또는 단계적 오픈 구조

특히 요구사항 변경이 빈번하고, 빠른 시장 반응이 필요한 서비스 개발에서 효과가 크다.

4.2 Agile 방법론의 평가

장점	한계
변화에 대한 대응력 우수 고객 만족도 향상 빠른 가치 전달 리스크 조기 발견 가능	명확한 문서 산출물이 부족할 수 있음 팀원의 숙련도에 따라 성과 편차 발생 대규모 조직에서는 관리 복잡성 증가 공공·규제 중심 프로젝트에는 적용 시 조정 필요

따라서 Agile은 모든 프로젝트에 만능 해법은 아니며, 조직 문화, 프로젝트 성격, 계약 구조를 고려한 혼합형(Hybrid) 접근이 현실적인 대안으로 평가된다.

결론적 정리

Agile 개발방법론은 단순한 개발 기법이 아니라, 변화를 수용하는 사고방식이자 조직 운영 철학이다. 지속적으로 변화하는 IT 환경 속에서 Agile은 빠른 대응력과 고객 중심 가치를 제공하지만, 성공적인 적용을 위해서는 조직 문화와 프로젝트 특성에 맞는 전략적 선택이 필요하다.

주요 출처

[공식 출처]

Agile Manifesto (2001)
- Kent Beck, Martin Fowler, Ken Schwaber 등 17인의 개발자 공동 선언
- 공식 사이트:
- https://agilemanifesto.org
Scrum Guide
- Ken Schwaber & Jeff Sutherland
- Scrum의 공식 정의 문서
- https://scrumguides.org
Extreme Programming Explained
- Kent Beck
- XP 방법론의 이론적 기반 서적

[학술·실무 참고 문헌]

Sommerville, Software Engineering
Pressman, Software Engineering: A Practitioner’s Approach
PMI, Agile Practice Guide
SAFe 공식 문서: https://scaledagileframework.com

Spring Cloud MSA 아키텍처

그레고리오78 — Tue, 27 Jan 2026 15:21:04 +0900

Spring Cloud MSA 개념도

컴포넌트별 역할 및 관계

컴포넌트	주요 역할	다른 컴포너트와의 관계
Eureka Server (Service Registry)	• 마이크로서비스 등록 및 관리 • 서비스 인스턴스 정보 저장 • 서비스 Health Check • 서비스 디스커버리 제공	• Spring Boot 서비스들: 각 서비스가 시작 시 Eureka에 자동 등록 (Eureka Client) • Gateway: Gateway가 Eureka를 조회하여 서비스 위치 파악 • 30초마다 Heartbeat로 서비스 상태 확인
Spring Cloud Gateway (API Gateway)	• 단일 진입점(Single Entry Point) • 동적 라우팅 및 로드밸런싱 • 인증/인가 처리 • Rate Limiting, Circuit Breaker	• Client: 모든 클라이언트 요청을 받는 진입점 • Eureka: Eureka에서 서비스 목록을 조회하여 동적 라우팅 • Spring Boot 서비스들: 요청을 적절한 서비스로 전달
Spring Boot Services (Microservices)	• 각 도메인별 비즈니스 로직 처리 • 독립적인 배포 및 확장 • 자체 데이터베이스 관리 • RESTful API 제공	• Eureka: 시작 시 Eureka에 자신을 등록 (@EnableEurekaClient) • Gateway: Gateway를 통해 요청을 받음 • 다른 서비스들: Feign Client로 서비스 간 통신 (Eureka 통해 서비스 검색)

동작 흐름

1. 서비스 시작: 각 Spring Boot 서비스가 시작되면 Eureka Server에 자동 등록
2. 클라이언트 요청: 클라이언트가 Gateway(8080)로 요청 전송
3. 서비스 검색: Gateway가 Eureka에서 대상 서비스의 인스턴스 정보 조회
4. 라우팅: Gateway가 로드밸런싱을 통해 적절한 서비스 인스턴스로 요청 전달
5. 응답 반환: 서비스 처리 후 Gateway를 통해 클라이언트에 응답 반환

Spring Cloud MSA 아키텍처

그레고리오78 — Tue, 27 Jan 2026 12:30:31 +0900

Spring Cloud MSA 개념도

컴포넌트별 역할 및 관계

컴포넌트	주요 역할	다른 컴포너트와의 관계
Eureka Server (Service Registry)	• 마이크로서비스 등록 및 관리 • 서비스 인스턴스 정보 저장 • 서비스 Health Check • 서비스 디스커버리 제공	• Spring Boot 서비스들: 각 서비스가 시작 시 Eureka에 자동 등록 (Eureka Client) • Gateway: Gateway가 Eureka를 조회하여 서비스 위치 파악 • 30초마다 Heartbeat로 서비스 상태 확인
Spring Cloud Gateway (API Gateway)	• 단일 진입점(Single Entry Point) • 동적 라우팅 및 로드밸런싱 • 인증/인가 처리 • Rate Limiting, Circuit Breaker	• Client: 모든 클라이언트 요청을 받는 진입점 • Eureka: Eureka에서 서비스 목록을 조회하여 동적 라우팅 • Spring Boot 서비스들: 요청을 적절한 서비스로 전달
Spring Boot Services (Microservices)	• 각 도메인별 비즈니스 로직 처리 • 독립적인 배포 및 확장 • 자체 데이터베이스 관리 • RESTful API 제공	• Eureka: 시작 시 Eureka에 자신을 등록 (@EnableEurekaClient) • Gateway: Gateway를 통해 요청을 받음 • 다른 서비스들: Feign Client로 서비스 간 통신 (Eureka 통해 서비스 검색)

동작 흐름

MSA·클라우드 환경에 적용하는 관점과 공공/SI 프로젝트 기준의 실무 체크리스트

그레고리오78 — Tue, 27 Jan 2026 12:01:50 +0900

1. MSA·클라우드 환경에서의 IT Governance 적용

1.1 전통적 IT Governance와 MSA/클라우드의 차이

구분	전통적 환경	MSA·클라우드 환경
아키텍처	모놀리식	분산형(Microservices)
인프라	온프레미스	클라우드(IaaS/PaaS/SaaS)
변경 관리	느리고 중앙집중	빈번하고 자동화
책임 구조	IT 부서 중심	제품/도메인 중심
위험 요소	단일 장애	복잡성·연쇄 장애

➡ MSA·클라우드 환경에서는 ‘통제 중심’이 아닌 ‘가드레일 기반 거버넌스’가 필요

1.2 MSA·클라우드 환경에서 IT Governance 핵심 적용 원칙

① 전략적 연계 (Strategic Alignment)

비즈니스 전략 ↔ 클라우드/MSA 전환 로드맵 연계
“왜 MSA인가?”에 대한 명확한 경영적 근거 필요

적용 예

서비스 확장성 → Auto Scaling
글로벌 서비스 → Multi-Region 설계
빠른 출시 → CI/CD + DevOps

② 가치 전달 (Value Delivery)

클라우드 비용과 성과를 연계한 FinOps 거버넌스
서비스 단위 ROI 관리

적용 포인트

서비스별 비용 태깅 (Cost Allocation Tag)
불필요한 리소스 자동 정리
SLA 기반 성능·가용성 관리

③ 위험 관리 (Risk Management)

MSA·클라우드 특유의 리스크 관리가 핵심

리스크	거버넌스 대응
서비스 간 장애 전파	Circuit Breaker, Timeout
보안 경계 붕괴	Zero Trust, API Gateway
설정 오류	IaC(Terraform)
로그 분산	중앙 로그(ELK/Loki)

④ 거버넌스 자원 관리 (Resource Management)

중앙 통제 + 팀 자율성의 균형
표준 플랫폼 제공, 구현은 팀 책임

대표 자원 관리 대상

컨테이너 표준
API 규약
공통 인증/로그/모니터링
Redis, DB, 메시징 표준

⑤ 성과 측정 (Performance Measurement)

기술 지표 → 비즈니스 지표로 연결

영역	KPI 예시
안정성	장애 건수, MTTR
민첩성	배포 빈도, 리드 타임
비용	서비스별 클라우드 비용
품질	에러율, 응답 시간

1.3 MSA·클라우드 환경 IT Governance 구조 예시

2. 공공 / SI 프로젝트 기준 IT Governance 체크리스트

2.1 공공·SI 프로젝트 특성

감사·규정·문서 중요
계약 기반 범위 관리
다수 이해관계자
운영 안정성 최우선

➡ 형식적 거버넌스가 아닌 ‘감사 대응 가능한 실질 거버넌스’ 필요

2.2 단계별 IT Governance 체크리스트

단계	Governance 목적	주요 체크 항목	핵심 산출물	책임 주체
기획 / 제안	전략적 연계 및 거버넌스 체계 수립	· IT Governance 조직 정의· 사업 목표 ↔ IT 목표 매핑· 기술·보안 표준 기준 수립· 주요 리스크 식별	· IT Governance 운영 방안서· 기술 표준 정의서· 리스크 관리 계획	발주처, PMO, CIO
분석	현황 파악 및 통제 범위 확정	· AS-IS / TO-BE 분석· EA 적용 여부 검토· 데이터 거버넌스 정의· 법·규제 준수 검토	· 업무/시스템 분석서· EA 산출물· 데이터 정책 문서	아키텍트, 분석가
설계	안정성·보안·확장성 확보	· 아키텍처 적합성 검토· 보안/접근 통제 설계· DR/BCP 설계· 성능·SLA 기준 정의	· 아키텍처 설계서· 보안 설계서· DR/BCP 계획서	아키텍트, 보안 담당
개발	품질·변경 관리	· 형상 관리 전략· 코드 리뷰·정적 분석· 보안 취약점 점검· 변경 승인 절차 운영	· 형상 관리 계획서· 개발 표준서· 변경 관리 기록	개발 리더, QA
테스트	품질 검증 및 리스크 최소화	· 통합 테스트 수행· 보안·모의해킹 테스트· 성능·부하 테스트· 사용자 검증(UAT)	· 테스트 결과 보고서· 성능 시험 보고서	QA, 발주처
구축 / 이행	운영 안정성 확보	· 운영 이관 절차 검증· 권한·계정 통제· 로그 및 감사 설정· 오픈 승인 관리	· 운영 매뉴얼· 이행 체크리스트· 오픈 승인서	운영팀, PM
운영	지속적 성과 및 개선	· SLA/KPI 모니터링· 장애·보안 사고 관리· 정기 감사 및 점검· 개선 과제 관리	· 운영 성과 보고서· 장애/보안 이력· 개선 계획서	운영팀, CIO

2.3 공공/SI 프로젝트 IT Governance 필수 산출물

IT Governance 운영 방안서
기술 표준서
아키텍처 설계서
보안 설계서
형상 관리 계획
변경 관리 절차서
장애 대응 매뉴얼
운영 KPI 정의서

3. 결론

MSA·클라우드 환경에서의 IT Governance는 “통제”가 아니라 “방향과 가드레일”을 제공하는 체계다.

특히 공공·SI 프로젝트에서는

전략적 연계의 명확성
문서 기반 책임 체계
감사 대응 가능한 실행력

이 결합되어야 형식적 거버넌스를 넘어 실효성 있는 거버넌스가 된다.

IT Governance는 기술이 아니라 조직의 성숙도와 의사결정 방식을 반영하는 거울이다.

4. 참고 / 출처

ISACA, COBIT 2019 Framework
ISO/IEC 38500:2015, Governance of IT for the organization
AXELOS, ITIL 4 Foundation
Gartner, Governing Cloud and Distributed Architectures
대한민국 행정안전부, 전자정부 표준프레임워크 아키텍처 가이드
Weill, P. & Ross, J. (2004), IT Governance

IT Governance(IT 거버넌스)

그레고리오78 — Tue, 27 Jan 2026 11:04:19 +0900

1. 서론

디지털 전환(Digital Transformation)이 가속화되면서 IT는 더 이상 단순한 지원 수단이 아니라 기업 전략을 실현하는 핵심 자산으로 자리 잡았다.

그러나 IT 투자 규모가 커질수록 실패 위험, 보안 위협, 규제 준수 문제 또한 증가하게 된다. 이러한 복잡한 환경에서 IT가 기업의 전략과 일관되게 운영되고, 투자 대비 가치를 창출하며, 위험을 통제하도록 관리하는 체계가 바로 IT Governance(IT 거버넌스)이다.

IT 거버넌스는 “IT를 누가, 어떤 기준으로, 어떤 방식으로 의사결정하고 통제할 것인가”에 대한 문제를 다루며, 경영진·IT 조직·현업 간의 역할과 책임을 명확히 정의하는 경영 프레임워크다.

2. 본론

2.1 IT Governance의 개념

IT Governance란

“기업의 목표 달성을 위해 IT가 전략적으로 정렬(Alignment)되고, 가치를 창출하며, 위험을 관리하도록 하는 의사결정 구조와 책임 체계”

를 의미한다.

이는 단순한 IT 관리(IT Management)가 아니라,

무엇을 할 것인가(방향)
누가 결정할 것인가(책임)
성과를 어떻게 측정할 것인가(통제)

를 포함하는 경영 차원의 통제 메커니즘이다.

2.2 IT Governance의 목적

목적	설명
전략적 연계	IT 전략과 기업 전략의 일관성 확보
가치 전달	IT 투자를 통해 비즈니스 가치 창출
위험 관리	보안, 장애, 규제 리스크 최소화
자원 관리	인력, 인프라, 데이터, 애플리케이션 최적 활용
성과 측정	IT 성과를 정량·정성적으로 평가

2.3 IT Governance의 핵심 키워드

키워드	정의	주요 관리 대상	적용 방식	성과 지표
전략적 연계 (Strategic Alignment)	IT 전략이 기업·사업 전략과 일관되게 정렬되도록 관리	IT 로드맵, 아키텍처, 투자 계획	· IT 중장기 로드맵 수립· EA 기반 전략 매핑· 사업 목표 ↔ IT 목표 연결	· 전략 과제 달성률· IT 과제의 사업 연계 비율
가치 전달 (Value Delivery)	IT 투자가 실제 비즈니스 가치를 창출하도록 보장	IT 투자, 서비스 성과, 비용	· ROI/TCO 분석· 서비스 단위 가치 평가· FinOps 적용	· IT 투자 대비 ROI· 운영비 절감률· 서비스 만족도
위험 관리 (Risk Management)	IT 관련 위험을 식별·통제하여 조직 피해 최소화	보안, 장애, 규제, 데이터	· 보안 정책 수립· DR/BCP 운영· 접근 통제 및 로그 감사	· 보안 사고 건수· 장애 발생률· MTTR
거버넌스 자원 관리 (Resource Management)	IT 자원을 효율적으로 배분·활용	인력, 인프라, 애플리케이션, 데이터	· 기술 표준화· 공통 플랫폼 운영· 중복 시스템 제거	· 인프라 활용률· 중복 시스템 감소율
성과 측정 (Performance Measurement)	IT 활동 성과를 정량·정성적으로 측정	KPI, SLA, 운영 지표	· KPI 정의 및 대시보드· SLA 기반 운영 평가· 정기 성과 리뷰	· SLA 준수율· 배포 빈도· 장애 대응 시간

2.4 IT Governance의 특징

구분	내용
경영 중심적	CIO/CTO뿐 아니라 CEO·이사회 관여
의사 결정 중심	기술이 아닌 “결정 구조”에 초점
표준 기반	국제 프레임워크(COBIT, ITIL 등) 활용
지속적 개선	정기적 평가 및 성숙도 관리

2.5 IT Governance의 기능 및 기술

주요 기능

IT 정책 및 표준 수립
투자 우선순위 결정
리스크 및 컴플라이언스 관리
성과 모니터링 및 보고

대표 프레임워크 / 기술

구분	내용
COBIT	IT 거버넌스 및 관리 통합 프레임워크
ITIL	IT 서비스 관리(ITSM) 표준
ISO/IEC 38500	IT 거버넌스 국제 표준
ISO 27001	정보보안 관리체계
EA(Enterprise Architecture)	비즈니스-IT 정렬 도구
KPI/BSC	성과 측정 도구

2.6 IT Governance의 장점과 단점

장점	단점
IT 투자 효율성 증대 리스크 및 장애 감소 경영진의 가시성 확보 IT와 비즈니스 간 협업 강화	초기 구축 비용과 시간 소요 문서·프로세스 중심으로 경직될 위험 조직 문화 미성숙 시 형식화 가능성

2.7 IT Governance 사례

사례 1: 글로벌 금융사

COBIT 기반 IT Governance 도입
IT 투자 심의 위원회 운영
결과: IT 프로젝트 실패율 감소, 규제 대응 강화

사례 2: 국내 대기업

EA + ITIL 기반 거버넌스 수립
중복 시스템 통합 및 표준화
결과: 운영 비용 절감, 서비스 안정성 향상

사례 3: 공공기관

ISO/IEC 38500 및 ISMS 적용
감사·보안 중심 거버넌스 강화
결과: 감사 지적 감소, 대국민 서비스 신뢰도 향상

3. 결론

IT Governance는 단순히 IT를 “관리”하는 체계가 아니라,

기업 전략을 실현하고 지속 가능한 가치를 창출하기 위한 경영 도구이다.

특히 전략적 연계, 가치 전달, 위험 관리, 자원 관리, 성과 측정이라는 다섯 가지 핵심 요소를 균형 있게 운영할 때, IT는 비용 중심 조직에서 경쟁 우위의 원천으로 전환될 수 있다.

디지털 기술이 경영의 중심이 된 오늘날, IT Governance는 선택이 아닌 필수적인 경영 역량이다.

4. 참고 / 출처

ISACA, COBIT 2019 Framework
ISO/IEC 38500:2015, Governance of IT for the organization
ITIL Foundation, AXELOS
Weill, P. & Ross, J. (2004), IT Governance: How Top Performers Manage IT Decision Rights
Gartner, IT Governance Best Practices

데이터 아키텍처(Data Architecture, DA)

그레고리오78 — Tue, 27 Jan 2026 10:35:27 +0900

1. 서론

디지털 전환(Digital Transformation)이 가속화되면서 데이터는 더 이상 단순한 저장 대상이 아니라, 비즈니스 경쟁력을 좌우하는 핵심 자산이 되었다. 그러나 많은 조직은 데이터가 여러 시스템에 분산되어 있고, 표준 없이 생성·관리되면서 품질 저하, 중복, 분석 한계 등의 문제를 겪고 있다.

이러한 문제를 해결하기 위한 체계적인 접근 방식이 바로 데이터 아키텍처(Data Architecture, DA)이다.

DA는 조직의 비즈니스 전략을 지원하기 위해 데이터를 어떻게 정의하고, 저장하고, 통합하고, 활용할 것인가를 구조적으로 설계하는 활동이다.

2. 본론

2.1 데이터 아키텍처의 정의

데이터 아키텍처(Data Architecture)란 다음을 포괄하는 개념이다.

조직의 데이터 자산에 대한 구조, 표준, 흐름, 관리 원칙을 정의하고, 이를 기반으로 데이터의 생성부터 활용까지 전 생명주기를 설계하는 아키텍처

즉, DA는 단순한 DB 설계가 아니라 비즈니스–애플리케이션–데이터를 연결하는 상위 설계 체계이다.

2.2 데이터 아키텍처의 주요 구성 요소

구분	내용	비고
데이터 모델	개념/논리/물리 데이터 모델
데이터 모준	용어, 도메인, 코드 명명 규칙
데이터 저장소	RDB, NoSQL, Data Lake, Cache
데이터 흐름	수집, 적재, 변환(ETL/ELT), 전송
데이터 통합	MDM, CDC, API, 메시징
데이터 품질	정합성, 정확성, 중복 제거
데이터 보안	접근 제어, 암호화, 마스킹
데이터 거버넌스	정책, 책임, 관리 체계

2.3 데이터 아키텍처 계층 구조

데이터 아키텍처는 일반적으로 3단계 모델링 계층으로 구성된다.

계층	목적	주요 산출물
개념 데이터 모델	비즈니스 관점 이해	엔티티, 관계
논리 데이터 모델	시스템 독립 설계	속성, 정규화
물리 데이터 모델	실제 구현	테이블 인덱스

2.4 엔터프라이즈 환경에서의 DA 유형

1) 전통적 모놀리식 환경

단일 RDB 중심
정규화된 데이터 모델
중앙 집중형 관리

2) MSA(Microservices Architecture) 환경

서비스별 독립 DB (Database per Service)
데이터 중복 허용
이벤트 기반 데이터 동기화

구분	모놀리식	MSA
DB 구조	중앙 집중	서비스별 분산
데이터 공유	중앙 집중	API / 이벤트
변경 영향	높음	작음
DA 난이도	보통	높음

2.5 데이터 아키텍처 예시 (MSA 기반)

이 구조에서 DA는 다음을 정의한다.

서비스별 데이터 소유권
공통 코드 및 참조 데이터 관리 방식
로그·이력 데이터의 저장 및 분석 흐름
트랜잭션 데이터와 분석 데이터의 분리

2.6 데이터 아키텍처와 다른 아키텍처의 관계

아키텍처	역할
비즈니스 아키텍처	업무 구조 정의
어플리케이션 아키텍처	시스템 기능 구조
데이터 아키텍처	데이터 구조 및 흐름
기술 아키텍처	인프라, 플랫폼

DA는 모든 아키텍처의 기반이며, 잘못 설계될 경우 시스템 전체의 복잡도가 급격히 증가한다.

3. 결론

데이터 아키텍처는 단순히 “DB를 잘 설계하는 일”이 아니라,

조직의 데이터 활용 능력을 결정하는 핵심 설계 활동이다.

특히 다음과 같은 환경에서는 DA의 중요성이 더욱 커진다.

MSA 기반 분산 시스템
대용량 데이터 처리 및 분석
멀티 DB(RDB + NoSQL + Cache) 환경
글로벌 서비스 및 다국어·다시간대 운영

잘 설계된 데이터 아키텍처는 다음과 같은 효과를 제공한다.

데이터 품질 향상
시스템 확장성 확보
분석 및 AI 활용 기반 마련
운영 비용 및 리스크 감소

결국 DA는 기술이 아닌 전략이며, 설계가 아닌 경영 자산이라고 할 수 있다.

참고 문헌 및 출처

DAMA International, DAMA-DMBOK 2.0 (Data Management Body of Knowledge)
Ralph Kimball, The Data Warehouse Toolkit
Martin Fowler, Patterns of Enterprise Application Architecture
TOGAF® Standard, The Open Group
Microsoft Azure Architecture Center – Data Architecture Concepts
AWS Well-Architected Framework – Data Pillar

실시간 미세먼지 확인

그레고리오78 — Tue, 16 Oct 2018 11:03:49 +0900

미세먼지가 해롭다는 것은 다들 알고 계실 것 입니다.

좋음, 나쁨, 이렇게 보는 것보다는 실시간으로 보는 것이 좋을 것 같습니다.

많은 도움이 됐으면 합니다.

도움이 되셨다면 로그인 없이 가능한

아래 하트♥공감 버튼을 꾹 눌러주세요!

[리눅스 명령어]batch

그레고리오78 — Tue, 4 Sep 2018 23:10:26 +0900

요약

시스템 부하가 일정 이하가 되면 예약 명령을 실행한다.

경로

/usr/bin/batch

사용방법

batch [-V][-q 큐이름][-f 파일명][-mv][시간]

-q queue : queue 이름을 지정한다. 큐 이름으로 a~z, A~Z가 쓰일 수 있따. 큐 이름을 지정하지 않으면 at는 a, batch는 b를 사용한다. 알파벳 순서로 뒤의 이름을 갖는 큐는 더 큰 niceness 값을 갖는다. '=' 큐는 현재 수행되는 작업에 대한 큐로 예약된다. 대문자 이름의 큐에 추가된 작업은 batch의 작업처럼 처리된다.

-m : 출력 결과가 없어도 작업이 완료되면 사용자에게 메일을 보낸다.

-f 파일명 : 스크립트 파일 등을 실행할 때 사용한다.

설명 및 예제

batch는 시스템의 평균 부하가 0.8 이하로 내려가면 예약한 내용을 실행한다. 시스템 부하가 많이 걸리는 명령을 실행할 때 유용하다. 먼저 현재 시스템의 평균 부하를 살펴보자.

평균 부하가 0 정도인 것을 확인 할 수 있다. batch를 이용해 시스템의 부하를 피해 실행할 스크립트를 등록한다. 등록 후 atq 명령어를 사용해서 예약한 작업 목록을 확인할 수 있다.

# batch -f system_backup -m now
job 9 at 2010-06-25 04:01
#atq
9 2010-06-25 04:01 b root

등록된 시간을 보고 예약한 내용을 확인할 수 있다.

[리눅스 명령어]basename

그레고리오78 — Tue, 4 Sep 2018 23:03:21 +0900

요약

경로와 확장자를 제거한 순수 파일 이름만 돌려받는다.

경로

/bin/basename

사용방법

basename [경로+파일 이름] [확장자]

경로+파일이름 : 경로를 포함한 파일 이름

확장자 : 선택 옵션으로 확장자까지 제거하고 싶을 때 사용한다. 이 확장자로 파일 이름의 맨 마지막에 오는 문자열은 삭제한다.

--help : 도움말을 출력한다.

--version : 버전 정보를 출력한다.

설명 및 예제

basename 명령어는 경로를 포함한 파일 이름을 인수로 받아, 파일 경로를 제거하고 필요에 따라서는 확장자로 삭제하여 순수하게 파일명만 남게한다.

basename을 이용하여 /etc/issue.net에서 파일 경로와 확장자를 지워보자.

쉘 스크립트 등을 작성할 때, 경로를 포함한 파일 이름을 가진 어떤 변수에서 파일 이름만 추출하여 사용하고 싶을 때 basename을 사용하면 편리하다. 시스템 변수 중 MAIL은 로그인 사용자의 mail 파일과 경로를 저장한다. 이중 로그인 사용자 명만 추출하고 싶다면 다음과 같이 할 수 있다.

관련 명령어

dirname : 경로+파일명에서 경로만 추출한다.

pwd : 지정한 파일의 절대 경로를 알려준다.

[리눅스 명령어]at

그레고리오78 — Tue, 4 Sep 2018 22:55:40 +0900

요약

명령어나 스크립트의 실행을 예약한다.

경로

/usr/bin/at

사용방법

at [옵션] [시간] [날짜] [+증가시간]

시간 날짜 : 명령어나 스크립트를 실행할 시간과 날짜를 지정한다.

+증가시간 : 앞서 명시한 시간을 기준으로 증가 시간 만큼이 지난 후 실행한다.

-m : 출력 결과가 없더라도 작업이 완료될 때 사용자에게 메일을 보낸다.

-f filename : 스크립트 파일 등을 실행해 줄 때 사용한다.

-l : 예약된 작업 목록을 보여준다. atq 명령어와 같다.

-v : 작업이 수행될 시간을 보여준다.

-d : 예약된 작업을 삭제한다.(리눅스 명령어), atrm 명령어와 같다.

-r : 예약된 작업을 삭제한다.(유닉스 명령어), atrm 명령어와 같다.

설명 및 예제

at는 명령어와 스크립트 파일을 특정 시간에 실행할 수 있도록 예약하는 기능을 한다. 즉, 시스템의 부하가 적은 시간에 실행하거나 예약된 시간에 꼭 실행해야 하는 작업을 자동으로 처리하고자 할 때 사용한다.

at으로 시행할 시간 설정

예약작업 기능이므로 시간 설정이 중요하다. at 시간 설정은 날짜와 시간을 정해주는 시간 설정과 현재 시간이나 정해진 시간에서 증가시간을 설정해 주는 방법이 있다.

증가시간을 이용한 설정

지금부터 6시간 뒤에 Control.sh 스크립트를 실행하고 싶으면 -f 옵션을 사용하여 예약 작업으로 등록한다.

# at now + 6 hours -f Control.sh

리다이렉션(<)을 이용해도 된다.

# at now + 6 hours < Control.sh

4번 예약 작업을 삭제하고 싶다면 -d 옵션 다음에 삭제할 작업번호를 지정한다.

# at -d 4

at의 사용 권한 설정

at 명령어는 at.allow와 at.deny 두 파일을 이용해 일반 사용자의 사용 권한을 지정해 줄 수 있따. /etc/at.allow 파일이 있으면 at.allow에 기록된 사용자만 at 명령어를 사용할 수 있으며, 이 파일이 없으면 /etc/at.deny에 기록되지 않은 사용자만 사용할 수 있다. 두 파일 모두 없다면 관리자만 사용할 수 있다.

관련 명령어

atq : 예약된 작업 목록을 출력한다.

atrm : 예약된 작업 목록을 삭제한다.

batch : 시스템 부하가 일정 이하일 때 명령을 실행한다.

cron : 정기적으로 예약된 작업을 수행한다.

[리눅스 명령어]arping

그레고리오78 — Tue, 4 Sep 2018 22:43:09 +0900

요약

ARP 요청을 이용한 네트워크 연결을 확인한다.

경로

/sbin/arping

사용방법

arping [option]

-c count : arping의 개수를 지정한다.

-w timeout : w 옵션 뒤 시간(초)를 지정하여 그 시간(초) 까지만 arping을 실행한다.

-I device : 이너넷 장치를 지정한다.

-s source : source IP를 지정한다.

설명 및 예제

ping의 변경으로 ICMP 패킷 대신 ARP 요청과 응답을 이용하여 해당 IP 주소의 MAC 주소를 찾거나, MAC 주소가 있을 때 IP 주소를 찾는다. 또한 ICMP 패킷을 차단한 호스트라도 단지 연결성만을 검사하고 싶은 경우라면, arping를 써도 좋다. 다음은 자신의 시스템으로 arping을 3번 보내서 확인하는 예제이다.

관련 명령어

ping : 네트워크의 연결성을 분석한다.

[리눅스 명령어]arp

그레고리오78 — Tue, 4 Sep 2018 22:36:02 +0900

요약

연결하려는 시스템의 MAC 주소를 확인한다.

경로

/sbin/arp

사용방법

arp [option]

-v : ARP 상태를 출력한다.

-t type : ARP 캐시에 올라와 있는 타입을 검색한다. ether(Enternet), ax25(AX25 packet radio)등이 있으며, ether가 기본 타입이다.

-a [host] : 등록된 호스트 중 지정한 호스트의 내용을 보여준다. 호스트를 지정하지 않으면 등록된 모든 호스트를 출력한다.

-d [host] : 지정한 호스트를 목록에서 삭제한다.

-s host hardware-address : 호스트의 하드웨어 주소. 즉, 호스트 MAC 주소를 추가한다. 이더넷 카드의 경우 6자리의 16진수로 되어 있다.

-f file : 파일에 있는 목록을 추가한다.

설명 및 예제

TCP/IP 명령어 이다. 시스템 사이의 통신에는 상대방의 MAC 주소가 필요하다. 이때 arp는 ARP를 이용하여 상대 시스템 IP에 신호를 보내 MAC 주소를 받아온다. 서브넷의 ARP 정보는 연결 효율을 높이기 위해 /proc/net/arp에 저장된다. 캐시에 저장된 정보는 추가/삭제할 수 있다. 이와 같이 저장된 ARP 캐시의 내용을 자세히 보고 싶다면 다음과 같이 실행한다.

관련 명령어

arping : 대상 주소에 ARP 패킷을 보낸다.

arpwatch : Ethernet/IP 주소의 진로를 추적한다.

arpsnmp : Ethernet/IP 주소의 진로를 추적한다.

tcpdump : 네트워크 인터페이스에서의 패킷 헤더를 출력한다.

[리눅스 명령어]arch

그레고리오78 — Mon, 3 Sep 2018 23:03:29 +0900

요약

시스템의 아키텍처를 확인한다.

경로

/bin/arch

사용방법

arch

설명 및 예제

시스템의 CPU 타입을 보여준다. x86의 인텔 계열 CPU는 i386, i486, i586, i686등으로 출력하며, 그 외는 alpha, sparc, arm m68k, mips, ppc 등과 같이 출력한다.

인텔 펜티엄 시스템에서 arch 명령어를 이용하여 CPU 타입을 확인해 보자.

# arch
i686

아래 그림은 VirtualBox Centos7 실행결과 이다.

[리눅스 명령어]apropos

그레고리오78 — Mon, 3 Sep 2018 22:59:20 +0900

요약

검색어와 관련있는 명령어를 설명과 함께 출력한다.

경로

/usr/bin/apropos

사용방법

apropos [검색어]

검색어 : 검색하고 싶은 문자열

설명 및 예제

apropos는 검색어와 관련 있는 명령어를 whatis DB에서 검색하여 간단한 설명과 함께 출력한다.

whatis는 검색어가 whatis DB의 명령어 리스트와 이름이 동일한 경우만 출력하지만, apropos는 검색어 일부가 명령어나 설명에 포함된 경우까지 모두 출력한다.

예를 들어 리눅스에서 GIMP 등의 그래픽 툴을 사용하지 않고도 비트맵 파일을 jpeg 파일로 변경할 수 있다.

그런데 그 명령어가 생각나지 않을 경우 다음과 같이 입력한다.

# apropos jpeg

apropos 명령어에 검색어로 jpeg을 사용하면, 명령어나 요약 설명에 jpeg이라는 단어가 들어있는 모든 명령어를 출력한다.

우리가 찾는 이미지를 jpeg 파일로 만들어 주는 명령어는 가장 위에 있는 cjpeg 임을 알 수 있따. 또한 반대로 jpeg 파일을 비트맵이나 그 외의 파일오 만드는 djpeg이라는 명령어가 있다는 것도 알 수 있따.

관련 명령어

man : -k 옵션을 사용하면, apropos와 같은 기능을 한다.

whatis : whatis DB에서 명령어와 일치하는 요약 내용을 검색하여 출력한다.

[리눅스 명령어]apm

그레고리오78 — Mon, 3 Sep 2018 22:48:09 +0900

요약

노트북 등 이동식 장치에서 배터리 잔여량을 보여주고, 상태에 따라 시스템을 대기/종료 시킨다.

경로

/usr/bin/apm

사용방법

access [-option]

-V, --version : 버전 정보를 출력한다.

-v, --verbose : 자세한 APM 바이오스의 버전과 전원상태 정보를 출력한다.

-m, -minutes : 배터리의 남은 시간을 출력한다.(분 단위)

-M, --monitor : 배터리 상태 정보를 계속해서 모니터하고 업데이트 한다.

-s, --suspend : 시스템을 서스펜드 상태로 만든다.

-S, --standby : 시스템을 스탠바이 상태로 만든다.

-d, --debug : 디버깅에 유용하도록 세부적인 APM 상태 정보를 출력한다.

설명 및 예제

노트북 사용자의 경우 배터리 관리는 아주 중요한 문제이다.

apm은 APM(Advanced Power Management) BIOS의 정보가 있는 /proc/apm 파일을 읽어 시스템의 전원 상태를 출력한다.

이 명령어로 배터리의 현재 잔여량을 알 수 있으며 시스템을 정지상태나 대기상태로 만들 수 있다.

노트북에서 리눅스를 사용할 때 꼭 필요한 명령어 이다.

그러면 다음과 같은 이 배터리의 남은 시간을 확인해 보자.

# apm -m
5

여기에서 5는 현재 상태에서 전원 연결 없이 배터리로 사용할 수 있는 시간을 분 단위로 나타낸 것이다.

만약에 데스크탑 환경이나 전원이 연결된 노트북에서 이 명령어를 실행 하면 다음과 같은 메세지를 출력한다.

# apm -m
apm 19AC on-line, no system battery

관련 명령어

apmd : 전원관리 데몬

[리눅스 명령어]alias

그레고리오78 — Mon, 3 Sep 2018 22:40:34 +0900

요약

복잡한 명령어와 옵션을 짧은 문자열로 바꿔준다

사용방법

alias name[=value]

설명 및 예제

옵션을 포함한 긴 명령어를 자주 사용한다면, 매번 입력하지 않고 짧은 문자열로 바꿔주는 alias를 이용한다.

예를 들어 터미널에서 rm 명령어를 이용하여 파일을 삭제할 때, 파일을 지울 것인지 다시 물어보는 옵션을 별도로 사용하지 않아도 rm 명령어가 이 옵션을 사용하고 있다. 또한 ls 명령어를 이용해 파일 목록을 보았을 때 색으로 구분되는 것은 시스템 환경에서 미리 alias로 해당 옵션을 예약해 놓았기 때문이다.

쉘을 내부 명령어 alias와 unalias를 이용하여 단축 명령어를 목록에 추가하고 삭제한다.

어떠한 명령어가 입력되면 이 명령어의 앞에서부터 문자열과 일치하는 alias된 문자열이 목록에 있는지 확인하고, 일치하면 원래의 명령어로 바꿔서 실행한다.

쉘 프롬프트에서 alias를 입력해보자. 현재 시스템에 정의된 alias 목록을 볼 수 있다.

#alias
alias cp='cp -i'
alias l. = 'ls -d .* --color=tty'
alias ll = 'ls -l --color=tty'

이전에 alias 관련 명령을 실행해본 적이 없다면, 위 내용은 운영체제에 기본 설정된 내용일 것이다.

원래 cp 명령은 복사할 파일이 이미 있는지를 고려하지 않고 덮어쓰지만, cp -i 옵션은 같은 이름의 파일이 있을 때 덮어 쓸 것인지 물어본다.

이 옵션을 사용하면 기존 파일을 무시하고 덮어쓰는 실수를 막을 수 있으므로, 운영체제에서 미리 alias를 이용하여 cp -i를 cp로 지정하였다.

그러면 cp의 alias를 삭제해보자. alias 삭제 명령은 unalias 이다.

# unalias cp

삭제 후 alias명령을 내리면 cp alias가 목록에서 사라진 것을 확인 할 수 있다.

그러면 다시 cp alias를 목록에 추가해 보자

# alias cp = 'cp -i'

다시 alias 명령으로 확인하면 추가 된 cp alias를 확인할 수 있다.

위와 같은 방법으로 자주 쓰는 명령어와 옵션을 간단한 문자열로 줄여 쓸 수 있다.

예를 들어 자주 쓰는 tar 명령과 옵션을 다음과 같이 만들어 놓으면 편리하다.

# alias tarx = 'tar xvpf'
# alias tarc = 'tar cvpf'
# alias tarz = 'tar xvpfz'

다른 명령어도 같은 방식으로 응용해 보자. 또한 alias가 설정되었어도 다음과 같은 방법으로 원래의 명령어를 사용할 수 있다.

# ＼cp

혹은

# /bin/cp

명령어 앞에 ＼(백슬래시)가 붙어 있으면 alias를 무시고 원래의 명령을 실행하라는 뜻이다.

또한 명령어가 위치한 절대 경로를 입력하여 명령어를 실행해도 alias를 무시한다.

[리눅스 명령어]access

그레고리오78 — Mon, 3 Sep 2018 22:22:49 +0900

요약

지정한 파일의 존재 유무와 권한을 확인한다.

경로

/usr/bin/access

사용방법

access [모드] [파일명]

-- help : 사용법을 출력한다.

-- version : 버전 정보를 출력한다.

설명 및 예제

현재 사용자 권한으로 지정한 파일이 존재 하는지, 읽기/쓰기/실행 권한이 있는지를 확인할 수 있다.

독립적으로 사용되기 보다는 쉘 스크립트 안에서 사용된다.

"모드" 인수에는 r(Read), w(Write), x(Execute)을 대입하여 파일에 권한이 있는지 질의할 수 있다.

r(Read), w(Write) 권한이 있는 테스트 파일을 access 명령어를 이용하여 권한을 확인해 보자

$ ls -l testfile
-rw-rw-r-- 1 gregorio78 gregorio78 @ Mar 3 01:58 testfile

현재 터미널 사용자는 gregorio78이며, 아래와 같이 testfile은 gregorio78 사용자와 그룹에 r(Read), w(Write) 권한이 있는 것을 알 수 있다.

access 명령어를 실행하면, 인수를 제대로 입력하여도 아무런 결과도 출력하지 않는다.

echo "$?" 명령어를 이용하여 access 명령어의 결과가 성공(0)했는지, 실패(1) 했는지 확인 할 수 있다.

$ access rw testfile
$ echo "$?"
0

testfile에 r(Read), w(Write) 권한은 있지만 x(Execute) 권한은 없으므로, 모든 인수를 rwx로 질의할 경우 결과는 실패(1)를 출력한다.

$ access rwx testfile
$ echo "$?"
1

모드에 대한 자세한 설명은 chmod를 참고하시기 바랍니다.

[MySQL]Insert, Update, Delete Query Generator

그레고리오78 — Tue, 21 Aug 2018 09:17:43 +0900

정보시스템을 개발하기 위해서는 데이터베이스 기반으로 개발을 해야 할 것입니다.

필자는 과거 프로젝트를 진행하면서 데이터베이스의 테이블 생성 또는 변경 시 테이블의 Insert, Update, Delete 쿼리를 지속적으로 작성했습니다.

아마 여러 개발자님들도 DBA(규모가 있는 프로젝트 인 경우) 또는 PM/PL이 추가/변경한 테이블에 대한 Insert, Update, Delete 쿼리를 필자와 마찬가지고 작성하셨을 것 이라고 생각합니다.

이 부분이 단순작업이고 귀찮은 작업입니다.

단순한 테이블 같은 경우 직접 작성하시면 되지만, 복잡한? 컬럼이 많은 테이블의 Insert/Update/Delete 쿼리를 작성하실 때는 최소 5분 정도의 시간이 걸릴 것 입니다.

이런 시간도 아깝다고 생각하여, 단순 노가다(?) 같은 작업을 자동화 하기 위해 Insert/Update/Delete 쿼리를 작성해주는 쿼리를 작성했습니다.

아래의 쿼리를 복사하셔서 &TBLNM을 테이블명으로 치환하셔서 실행하시면 MyBatis Tag와 쿼리를 작성하여 줍니다.

여러분의 개발시간을 단 5분이라도 단축해 드리고자 이렇게 공유하여 드립니다.

&BEAN_NM은 VolueObject Class Name으로 치환하시면 됩니다.

SELECT CONCAT('<!-- ', 'INSERT QUERY -->') AS QUERY UNION ALL
SELECT CONCAT('<insert id="insert" parameterClass="', IFNULL('&BEAN_NM', ''), '">') UNION ALL
SELECT CONCAT('INSERT INTO ', UPPER('&TBLNM'), ' (') UNION ALL
SELECT LEFT(COLUMN_NAMES, LENGTH(COLUMN_NAMES) - 2) AS COLUMN_NAMES
  FROM (
       SELECT CONCAT(
              IFNULL(CONCAT(COLUMN01, ', '), ''), IFNULL(CONCAT(COLUMN02, ', '), ''), IFNULL(CONCAT(COLUMN03, ', '), ''), IFNULL(CONCAT(COLUMN04, ', '), ''), IFNULL(CONCAT(COLUMN05, ', '), ''), IFNULL(CONCAT(COLUMN06, ', '), ''), IFNULL(CONCAT(COLUMN07, ', '), ''), IFNULL(CONCAT(COLUMN08, ', '), ''), IFNULL(CONCAT(COLUMN09, ', '), ''), IFNULL(CONCAT(COLUMN10, ', '), ''), 
              IFNULL(CONCAT(COLUMN11, ', '), ''), IFNULL(CONCAT(COLUMN12, ', '), ''), IFNULL(CONCAT(COLUMN13, ', '), ''), IFNULL(CONCAT(COLUMN14, ', '), ''), IFNULL(CONCAT(COLUMN15, ', '), ''), IFNULL(CONCAT(COLUMN16, ', '), ''), IFNULL(CONCAT(COLUMN17, ', '), ''), IFNULL(CONCAT(COLUMN18, ', '), ''), IFNULL(CONCAT(COLUMN19, ', '), ''), IFNULL(CONCAT(COLUMN20, ', '), ''), 
              IFNULL(CONCAT(COLUMN21, ', '), ''), IFNULL(CONCAT(COLUMN22, ', '), ''), IFNULL(CONCAT(COLUMN23, ', '), ''), IFNULL(CONCAT(COLUMN24, ', '), ''), IFNULL(CONCAT(COLUMN25, ', '), ''), IFNULL(CONCAT(COLUMN26, ', '), ''), IFNULL(CONCAT(COLUMN27, ', '), ''), IFNULL(CONCAT(COLUMN28, ', '), ''), IFNULL(CONCAT(COLUMN29, ', '), ''), IFNULL(CONCAT(COLUMN30, ', '), ''), 
              IFNULL(CONCAT(COLUMN31, ', '), ''), IFNULL(CONCAT(COLUMN32, ', '), ''), IFNULL(CONCAT(COLUMN33, ', '), ''), IFNULL(CONCAT(COLUMN34, ', '), ''), IFNULL(CONCAT(COLUMN35, ', '), ''), IFNULL(CONCAT(COLUMN36, ', '), ''), IFNULL(CONCAT(COLUMN37, ', '), ''), IFNULL(CONCAT(COLUMN38, ', '), ''), IFNULL(CONCAT(COLUMN39, ', '), ''), IFNULL(CONCAT(COLUMN40, ', '), ''), 
              IFNULL(CONCAT(COLUMN41, ', '), ''), IFNULL(CONCAT(COLUMN42, ', '), ''), IFNULL(CONCAT(COLUMN43, ', '), ''), IFNULL(CONCAT(COLUMN44, ', '), ''), IFNULL(CONCAT(COLUMN45, ', '), ''), IFNULL(CONCAT(COLUMN46, ', '), ''), IFNULL(CONCAT(COLUMN47, ', '), ''), IFNULL(CONCAT(COLUMN48, ', '), ''), IFNULL(CONCAT(COLUMN49, ', '), ''), IFNULL(CONCAT(COLUMN50, ', '), '')
              ) AS COLUMN_NAMES
         FROM (
                SELECT MAX(COLUMN01) AS COLUMN01, MAX(COLUMN02) AS COLUMN02, MAX(COLUMN03) AS COLUMN03, MAX(COLUMN04) AS COLUMN04, MAX(COLUMN05) AS COLUMN05, MAX(COLUMN06) AS COLUMN06, MAX(COLUMN07) AS COLUMN07, MAX(COLUMN08) AS COLUMN08, MAX(COLUMN09) AS COLUMN09, MAX(COLUMN10) AS COLUMN10,
                       MAX(COLUMN11) AS COLUMN11, MAX(COLUMN12) AS COLUMN12, MAX(COLUMN13) AS COLUMN13, MAX(COLUMN14) AS COLUMN14, MAX(COLUMN15) AS COLUMN15, MAX(COLUMN16) AS COLUMN16, MAX(COLUMN17) AS COLUMN17, MAX(COLUMN18) AS COLUMN18, MAX(COLUMN19) AS COLUMN19, MAX(COLUMN20) AS COLUMN20,
                       MAX(COLUMN21) AS COLUMN21, MAX(COLUMN22) AS COLUMN22, MAX(COLUMN23) AS COLUMN23, MAX(COLUMN24) AS COLUMN24, MAX(COLUMN25) AS COLUMN25, MAX(COLUMN26) AS COLUMN26, MAX(COLUMN27) AS COLUMN27, MAX(COLUMN28) AS COLUMN28, MAX(COLUMN29) AS COLUMN29, MAX(COLUMN30) AS COLUMN30,
                       MAX(COLUMN31) AS COLUMN31, MAX(COLUMN32) AS COLUMN32, MAX(COLUMN33) AS COLUMN33, MAX(COLUMN34) AS COLUMN34, MAX(COLUMN35) AS COLUMN35, MAX(COLUMN36) AS COLUMN36, MAX(COLUMN37) AS COLUMN37, MAX(COLUMN38) AS COLUMN38, MAX(COLUMN39) AS COLUMN39, MAX(COLUMN40) AS COLUMN40,
                       MAX(COLUMN41) AS COLUMN41, MAX(COLUMN42) AS COLUMN42, MAX(COLUMN43) AS COLUMN43, MAX(COLUMN44) AS COLUMN44, MAX(COLUMN45) AS COLUMN45, MAX(COLUMN46) AS COLUMN46, MAX(COLUMN47) AS COLUMN47, MAX(COLUMN48) AS COLUMN48, MAX(COLUMN49) AS COLUMN49, MAX(COLUMN50) AS COLUMN50
                  FROM (
                         SELECT ORDINAL_POSITION,
                                IF(ORDINAL_POSITION=1, COLUMN_NAME, NULL) AS COLUMN01, IF(ORDINAL_POSITION=2, COLUMN_NAME, NULL) AS COLUMN02, IF(ORDINAL_POSITION=3, COLUMN_NAME, NULL) AS COLUMN03, IF(ORDINAL_POSITION=4, COLUMN_NAME, NULL) AS COLUMN04, IF(ORDINAL_POSITION=5, COLUMN_NAME, NULL) AS COLUMN05, IF(ORDINAL_POSITION=6, COLUMN_NAME, NULL) AS COLUMN06, IF(ORDINAL_POSITION=7, COLUMN_NAME, NULL) AS COLUMN07, IF(ORDINAL_POSITION=8, COLUMN_NAME, NULL) AS COLUMN08, IF(ORDINAL_POSITION=9, COLUMN_NAME, NULL) AS COLUMN09, IF(ORDINAL_POSITION=10, COLUMN_NAME, NULL) AS COLUMN10,
                                IF(ORDINAL_POSITION=11, COLUMN_NAME, NULL) AS COLUMN11, IF(ORDINAL_POSITION=12, COLUMN_NAME, NULL) AS COLUMN12, IF(ORDINAL_POSITION=13, COLUMN_NAME, NULL) AS COLUMN13, IF(ORDINAL_POSITION=14, COLUMN_NAME, NULL) AS COLUMN14, IF(ORDINAL_POSITION=15, COLUMN_NAME, NULL) AS COLUMN15, IF(ORDINAL_POSITION=16, COLUMN_NAME, NULL) AS COLUMN16, IF(ORDINAL_POSITION=17, COLUMN_NAME, NULL) AS COLUMN17, IF(ORDINAL_POSITION=18, COLUMN_NAME, NULL) AS COLUMN18, IF(ORDINAL_POSITION=19, COLUMN_NAME, NULL) AS COLUMN19, IF(ORDINAL_POSITION=20, COLUMN_NAME, NULL) AS COLUMN20,
                                IF(ORDINAL_POSITION=21, COLUMN_NAME, NULL) AS COLUMN21, IF(ORDINAL_POSITION=22, COLUMN_NAME, NULL) AS COLUMN22, IF(ORDINAL_POSITION=23, COLUMN_NAME, NULL) AS COLUMN23, IF(ORDINAL_POSITION=24, COLUMN_NAME, NULL) AS COLUMN24, IF(ORDINAL_POSITION=25, COLUMN_NAME, NULL) AS COLUMN25, IF(ORDINAL_POSITION=26, COLUMN_NAME, NULL) AS COLUMN26, IF(ORDINAL_POSITION=27, COLUMN_NAME, NULL) AS COLUMN27, IF(ORDINAL_POSITION=28, COLUMN_NAME, NULL) AS COLUMN28, IF(ORDINAL_POSITION=29, COLUMN_NAME, NULL) AS COLUMN29, IF(ORDINAL_POSITION=30, COLUMN_NAME, NULL) AS COLUMN30,
                                IF(ORDINAL_POSITION=31, COLUMN_NAME, NULL) AS COLUMN31, IF(ORDINAL_POSITION=32, COLUMN_NAME, NULL) AS COLUMN32, IF(ORDINAL_POSITION=33, COLUMN_NAME, NULL) AS COLUMN33, IF(ORDINAL_POSITION=34, COLUMN_NAME, NULL) AS COLUMN34, IF(ORDINAL_POSITION=35, COLUMN_NAME, NULL) AS COLUMN35, IF(ORDINAL_POSITION=36, COLUMN_NAME, NULL) AS COLUMN36, IF(ORDINAL_POSITION=37, COLUMN_NAME, NULL) AS COLUMN37, IF(ORDINAL_POSITION=38, COLUMN_NAME, NULL) AS COLUMN38, IF(ORDINAL_POSITION=39, COLUMN_NAME, NULL) AS COLUMN39, IF(ORDINAL_POSITION=40, COLUMN_NAME, NULL) AS COLUMN40,
                                IF(ORDINAL_POSITION=41, COLUMN_NAME, NULL) AS COLUMN41, IF(ORDINAL_POSITION=42, COLUMN_NAME, NULL) AS COLUMN42, IF(ORDINAL_POSITION=43, COLUMN_NAME, NULL) AS COLUMN43, IF(ORDINAL_POSITION=44, COLUMN_NAME, NULL) AS COLUMN44, IF(ORDINAL_POSITION=45, COLUMN_NAME, NULL) AS COLUMN45, IF(ORDINAL_POSITION=46, COLUMN_NAME, NULL) AS COLUMN46, IF(ORDINAL_POSITION=47, COLUMN_NAME, NULL) AS COLUMN47, IF(ORDINAL_POSITION=48, COLUMN_NAME, NULL) AS COLUMN48, IF(ORDINAL_POSITION=49, COLUMN_NAME, NULL) AS COLUMN49, IF(ORDINAL_POSITION=50, COLUMN_NAME, NULL) AS COLUMN50
                           FROM INFORMATION_SCHEMA.COLUMNS
                          WHERE UPPER(TABLE_NAME) = UPPER('&TBLNM')
                            AND COLUMN_NAME NOT IN ('UPDATE_USER', 'UPDATE_DATE')
                       ) AS A
                ORDER BY ORDINAL_POSITION
              ) AS B
       ) AS C
UNION ALL
SELECT ') VALUES (' UNION ALL
SELECT LEFT(COLUMN_NAMES, LENGTH(COLUMN_NAMES) - 2) AS COLUMN_NAMES
  FROM (
       SELECT CONCAT(
              IFNULL(CONCAT('#{', LOWER(COLUMN01), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN02), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN03), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN04), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN05), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN06), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN07), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN08), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN09), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN10), '}, '), ''), 
              IFNULL(CONCAT('#{', LOWER(COLUMN11), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN12), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN13), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN14), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN15), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN16), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN17), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN18), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN19), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN20), '}, '), ''), 
              IFNULL(CONCAT('#{', LOWER(COLUMN21), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN22), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN23), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN24), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN25), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN26), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN27), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN28), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN29), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN30), '}, '), ''), 
              IFNULL(CONCAT('#{', LOWER(COLUMN31), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN32), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN33), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN34), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN35), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN36), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN37), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN38), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN39), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN40), '}, '), ''), 
              IFNULL(CONCAT('#{', LOWER(COLUMN41), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN42), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN43), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN44), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN45), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN46), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN47), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN48), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN49), '}, '), ''), IFNULL(CONCAT('#{', LOWER(COLUMN50), '}, '), '')
              ) AS COLUMN_NAMES
         FROM (
                SELECT MAX(COLUMN01) AS COLUMN01, MAX(COLUMN02) AS COLUMN02, MAX(COLUMN03) AS COLUMN03, MAX(COLUMN04) AS COLUMN04, MAX(COLUMN05) AS COLUMN05, MAX(COLUMN06) AS COLUMN06, MAX(COLUMN07) AS COLUMN07, MAX(COLUMN08) AS COLUMN08, MAX(COLUMN09) AS COLUMN09, MAX(COLUMN10) AS COLUMN10,
                       MAX(COLUMN11) AS COLUMN11, MAX(COLUMN12) AS COLUMN12, MAX(COLUMN13) AS COLUMN13, MAX(COLUMN14) AS COLUMN14, MAX(COLUMN15) AS COLUMN15, MAX(COLUMN16) AS COLUMN16, MAX(COLUMN17) AS COLUMN17, MAX(COLUMN18) AS COLUMN18, MAX(COLUMN19) AS COLUMN19, MAX(COLUMN20) AS COLUMN20,
                       MAX(COLUMN21) AS COLUMN21, MAX(COLUMN22) AS COLUMN22, MAX(COLUMN23) AS COLUMN23, MAX(COLUMN24) AS COLUMN24, MAX(COLUMN25) AS COLUMN25, MAX(COLUMN26) AS COLUMN26, MAX(COLUMN27) AS COLUMN27, MAX(COLUMN28) AS COLUMN28, MAX(COLUMN29) AS COLUMN29, MAX(COLUMN30) AS COLUMN30,
                       MAX(COLUMN31) AS COLUMN31, MAX(COLUMN32) AS COLUMN32, MAX(COLUMN33) AS COLUMN33, MAX(COLUMN34) AS COLUMN34, MAX(COLUMN35) AS COLUMN35, MAX(COLUMN36) AS COLUMN36, MAX(COLUMN37) AS COLUMN37, MAX(COLUMN38) AS COLUMN38, MAX(COLUMN39) AS COLUMN39, MAX(COLUMN40) AS COLUMN40,
                       MAX(COLUMN41) AS COLUMN41, MAX(COLUMN42) AS COLUMN42, MAX(COLUMN43) AS COLUMN43, MAX(COLUMN44) AS COLUMN44, MAX(COLUMN45) AS COLUMN45, MAX(COLUMN46) AS COLUMN46, MAX(COLUMN47) AS COLUMN47, MAX(COLUMN48) AS COLUMN48, MAX(COLUMN49) AS COLUMN49, MAX(COLUMN50) AS COLUMN50
                  FROM (
                         SELECT ORDINAL_POSITION,
                                IF(ORDINAL_POSITION=1, COLUMN_NAME, NULL) AS COLUMN01, IF(ORDINAL_POSITION=2, COLUMN_NAME, NULL) AS COLUMN02, IF(ORDINAL_POSITION=3, COLUMN_NAME, NULL) AS COLUMN03, IF(ORDINAL_POSITION=4, COLUMN_NAME, NULL) AS COLUMN04, IF(ORDINAL_POSITION=5, COLUMN_NAME, NULL) AS COLUMN05, IF(ORDINAL_POSITION=6, COLUMN_NAME, NULL) AS COLUMN06, IF(ORDINAL_POSITION=7, COLUMN_NAME, NULL) AS COLUMN07, IF(ORDINAL_POSITION=8, COLUMN_NAME, NULL) AS COLUMN08, IF(ORDINAL_POSITION=9, COLUMN_NAME, NULL) AS COLUMN09, IF(ORDINAL_POSITION=10, COLUMN_NAME, NULL) AS COLUMN10,
                                IF(ORDINAL_POSITION=11, COLUMN_NAME, NULL) AS COLUMN11, IF(ORDINAL_POSITION=12, COLUMN_NAME, NULL) AS COLUMN12, IF(ORDINAL_POSITION=13, COLUMN_NAME, NULL) AS COLUMN13, IF(ORDINAL_POSITION=14, COLUMN_NAME, NULL) AS COLUMN14, IF(ORDINAL_POSITION=15, COLUMN_NAME, NULL) AS COLUMN15, IF(ORDINAL_POSITION=16, COLUMN_NAME, NULL) AS COLUMN16, IF(ORDINAL_POSITION=17, COLUMN_NAME, NULL) AS COLUMN17, IF(ORDINAL_POSITION=18, COLUMN_NAME, NULL) AS COLUMN18, IF(ORDINAL_POSITION=19, COLUMN_NAME, NULL) AS COLUMN19, IF(ORDINAL_POSITION=20, COLUMN_NAME, NULL) AS COLUMN20,
                                IF(ORDINAL_POSITION=21, COLUMN_NAME, NULL) AS COLUMN21, IF(ORDINAL_POSITION=22, COLUMN_NAME, NULL) AS COLUMN22, IF(ORDINAL_POSITION=23, COLUMN_NAME, NULL) AS COLUMN23, IF(ORDINAL_POSITION=24, COLUMN_NAME, NULL) AS COLUMN24, IF(ORDINAL_POSITION=25, COLUMN_NAME, NULL) AS COLUMN25, IF(ORDINAL_POSITION=26, COLUMN_NAME, NULL) AS COLUMN26, IF(ORDINAL_POSITION=27, COLUMN_NAME, NULL) AS COLUMN27, IF(ORDINAL_POSITION=28, COLUMN_NAME, NULL) AS COLUMN28, IF(ORDINAL_POSITION=29, COLUMN_NAME, NULL) AS COLUMN29, IF(ORDINAL_POSITION=30, COLUMN_NAME, NULL) AS COLUMN30,
                                IF(ORDINAL_POSITION=31, COLUMN_NAME, NULL) AS COLUMN31, IF(ORDINAL_POSITION=32, COLUMN_NAME, NULL) AS COLUMN32, IF(ORDINAL_POSITION=33, COLUMN_NAME, NULL) AS COLUMN33, IF(ORDINAL_POSITION=34, COLUMN_NAME, NULL) AS COLUMN34, IF(ORDINAL_POSITION=35, COLUMN_NAME, NULL) AS COLUMN35, IF(ORDINAL_POSITION=36, COLUMN_NAME, NULL) AS COLUMN36, IF(ORDINAL_POSITION=37, COLUMN_NAME, NULL) AS COLUMN37, IF(ORDINAL_POSITION=38, COLUMN_NAME, NULL) AS COLUMN38, IF(ORDINAL_POSITION=39, COLUMN_NAME, NULL) AS COLUMN39, IF(ORDINAL_POSITION=40, COLUMN_NAME, NULL) AS COLUMN40,
                                IF(ORDINAL_POSITION=41, COLUMN_NAME, NULL) AS COLUMN41, IF(ORDINAL_POSITION=42, COLUMN_NAME, NULL) AS COLUMN42, IF(ORDINAL_POSITION=43, COLUMN_NAME, NULL) AS COLUMN43, IF(ORDINAL_POSITION=44, COLUMN_NAME, NULL) AS COLUMN44, IF(ORDINAL_POSITION=45, COLUMN_NAME, NULL) AS COLUMN45, IF(ORDINAL_POSITION=46, COLUMN_NAME, NULL) AS COLUMN46, IF(ORDINAL_POSITION=47, COLUMN_NAME, NULL) AS COLUMN47, IF(ORDINAL_POSITION=48, COLUMN_NAME, NULL) AS COLUMN48, IF(ORDINAL_POSITION=49, COLUMN_NAME, NULL) AS COLUMN49, IF(ORDINAL_POSITION=50, COLUMN_NAME, NULL) AS COLUMN50
                           FROM INFORMATION_SCHEMA.COLUMNS
                          WHERE UPPER(TABLE_NAME) = UPPER('&TBLNM')
                            AND COLUMN_NAME NOT IN ('UPDATE_USER', 'UPDATE_DATE')
                       ) AS A
                ORDER BY ORDINAL_POSITION
              ) AS B
       ) AS C
UNION ALL
SELECT ')' UNION ALL
SELECT '</insert>' UNION ALL
SELECT '' UNION ALL
SELECT CONCAT('<!-- ', 'UPDATE QUERY -->')  UNION ALL
SELECT CONCAT('<update id="update" parameterClass="', IFNULL('&BEAN_NM', ''), '">') UNION ALL
SELECT CONCAT('UPDATE ', '&TBLNM', ' SET') UNION ALL
SELECT CONCAT('       ', COLUMN_NAME, ' = #{', LOWER(COLUMN_NAME), '}, ')
  FROM INFORMATION_SCHEMA.COLUMNS
 WHERE UPPER(TABLE_NAME) = '&TBLNM'
   AND COLUMN_KEY = ''
   AND COLUMN_NAME NOT IN ('INIT_USER', 'INIT_DATE')
UNION ALL
SELECT ' WHERE' UNION ALL
SELECT CONCAT('   AND ', COLUMN_NAME, ' = #{', LOWER(COLUMN_NAME), '}, ')
  FROM INFORMATION_SCHEMA.COLUMNS
 WHERE UPPER(TABLE_NAME) = '&TBLNM'
   AND COLUMN_KEY = 'PRI'
   AND COLUMN_NAME NOT IN ('INIT_USER', 'INIT_DATE')
UNION ALL
SELECT '</update>' UNION ALL
SELECT '' UNION ALL
SELECT CONCAT('<!-- ', 'DELETE QUERY -->')  UNION ALL
SELECT CONCAT('<delete id="delete" parameterClass="', IFNULL('&BEAN_NM', ''), '">') UNION ALL
SELECT CONCAT('DELETE FROM ', UPPER('&TBLNM')) UNION ALL
SELECT ' WHERE' UNION ALL
SELECT CONCAT('   AND ', COLUMN_NAME, ' = #{', LOWER(COLUMN_NAME), '}, ')
  FROM INFORMATION_SCHEMA.COLUMNS
 WHERE UPPER(TABLE_NAME) = '&TBLNM'
   AND COLUMN_KEY = 'PRI'
   AND COLUMN_NAME NOT IN ('INIT_USER', 'INIT_DATE')
UNION ALL
SELECT '</delete>'

[mysql]insert_update_delete query generator.txt

부정적인 감정이 반드시 나쁜 것은 아니다

그레고리오78 — Fri, 10 Aug 2018 10:59:25 +0900

부정적인 감정이 반드시 나쁜 것은 아니다

외로움, 슬픔, 분노, 두려움 등 부정적인 감정이

반드시 나쁜 것만은 아닙니다.

우리가 불안이나 두려움을 느끼지 못한다면,
어떻게 목숨을 위협하는 위기상황에 대처하며
인류가 지금까지 살아남을 수 있었겠습니까.

우리의 삶에서 슬픔이나 분노가 아예 사라진다면
삶이 얼마나 무미건조하고 단조롭고 얕을 것입니까.

기쁨과 행복의 순간이
아름답고 소중하게 느껴지는 까닭도
그것을 돋보이게 하는
인생의 힘든 순간들이 있기 때문입니다.

감정이 일어나는 것은 자연스러운 일이지만
그 감정에 빠져서 끌려다니는 것은 경계해야 합니다.

데이터모델링의 개요

그레고리오78 — Thu, 2 Aug 2018 13:05:54 +0900

１. 데이터 모델링 정의

가. 데이터 모델링 탄생 배경

- 현재의 기업 정보 시스템은 데이터베이스 관리 시스템(DBMS: DataBase Management System)을 논외로 하고는 설명할 수 없을 것이다. 하지만 초창기에는 데이터의 저장 매체가 존재하지 않았으며, 기업의 정보 시스템은 저장 매체가 없는 단지 배치(Batch) 프로그램 위주의 정보 시스템이었다. 이후 파일 이나 데이터베이스 관리 시스템과 같은 데이터 저장 매체의 발전과 더불어 온라인(On-line) 데이터 처리 정보 시스템이 태동하게 되었다.

- 현재의 관계형 데이터베이스 관리 시스템이 아닌 이러한 시기의 파일이나 데이터베이스 관리 시스템(대표적인 예로 IBM의 계층형 데이터 베이스 - HDB : Hierarchical Database)의 데이터 중심의 관리 기법이 아니라 배치 프로세스에서 태동한 프로세스 중심의 데이터 관리 기법(구조적 방법론)에 의하여 정보의 고립화라는 현상을 초래하게 되었으며, 많은 기업들은 정보시스템을 유지관리 하는데 막대한 비용을 투자해야만 했던 것이다. 이에 많은 학자들은 프로세스 중심의 정보 시스템 분석, 설계 기법에 문제점이 있다고 생각하게 되었고, 진정 기업 정보시스템의 핵심은 데이터(정보)를 어떻게하면 중복없이 정확하게 유지 관리할 수 있을가에 대한 보다 근본적인 안을 제시하게 되었다. 이와 함께 기업의 경영 정보 시스템에 근본적인 문제가 설계나 개발의 문제보다는 정확한 업무의 파악(데이터에 대한 정확한 분석)이 선결되어야 한다는 결론에 이르렀으며, 이러한 환경에서 보다 현실적(실세계를 좀 더 잘 표현할 수 있는)인 관계형 데이터베이스나 개체 관계 모델링 기법(ERD:Entity Relationship Diagram)을 발전시켜 왔던것이다.

나. 모델 정의

- 일상생활에서 많이 접할 수 있는 단어인 모델(Model)은 다양한 현장에서 사용된다. 예술 분야에서 그림, 사진 등과 같은 작품의 대상이 되는 인물이나 대상을 보통 모델이라고 한다. 또한 아파트 분양을 할때 시공 회사에서 제공하는 모델 하우스는 분양을 원하는 사람들에게 아직 아파트 자체가 현존하지는 않지만 어떤 모습과 환경으로 시공자가 아파트를 건설할 것인가에 대한 정보를 제공한다. 이와 같이 모델이란 어떤 대상을 의미하는 포괄적 의미를 가지고 있다고 할 수 있으며, 특히 데이터 모델은 현실 세계에 대해 우리가 관심있어 하는 대상을 데이터베이스화 하기 위한 개념적 도구라고 정의할 수 있다.

- 아래는 모델의 일반적 의미를 실례로 설명한 내용이다.

1) 물리적 모델

- 현실에 실재하는 것이 아닌 복잡한 자동차의 모형, 대형 선박의 스케치 또는 설계도, 자동차의 모의 실험용으로 사용되는 바람 터널에서의 자동차 축소 모형 등이 물리적 모델의 실례이다.

2) 개념적 모델

- 특정 시점에 맞게 기상을 예측하기 위해서 사용되는 수리적 공식이나 원형을 파괴하지 않고 조작·수정·변경시키기 위한 경제 모형 등을 들 수 있다.

다. 모델링 정의

- 모델링이라는 단어는 실체를 나타내는 일과 모형화라는 의미로 해석된다. ‘실체를 나타낸다’의 의미는‘대상을 나타낸다’라는 말로 해석될 수도 있다. 모형화라는 의미는‘형태를 만드는 일’혹은 ‘대상을 만드는 일’이라고 해석할 수 있다. 따라서 데이터 모델링이란 사용자의 요구사항으로부터 데이터의 실체를 나타내는 일이라고 해석할 수 있을 것이다.

- 다음은 데이터 모델링의 다양한 관점에 대한 일반적 정의 사례이다.

■ 복잡한‘현실세계’를 단순화시켜 표현하는 것이다.

■ 모델이란 사물 또는 사건에 관한 양상(Aspect)이나 관점(Perspective)을 연관된 사람이나 그룹을 위하여 명확하게 하는 것이다.

- 데이터 모델링을 다시 정의하면 기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무 규칙(Business Rule)에 대하여 참(True) 또는 거짓(False)을 판별할 수 있는 사실(사실명제)을 어떻게(How), 누가(Who) 접근하는지 또한 이에 대한 전산화와는 별개의 관점에서 이를 명확하게 표현하는 추상화 기법이라 할 수 있다. 즉, 현재 업무를 파악하여 문제점을 인식하고 개선 사항을 도출하며 미래에 적합한 설계를 이끌어 내기 위해 인간이 해야 할 대부분의 결정들을 내리는 단계까지를 모두 포함하는 것이 데이터 모델링이다.

라. 데이터 모델이 제공하는 것

■ 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다.

■ 시스템의 구조와 행동을 명세화 할 수 있게 한다.

■ 시스템을 구축하는 틀을 제공한다.

■ 우리가 결정한 것을 문서화한다.

■ 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.

■ 특정 목표에 따라 다양한 상세 수준을 제공한다.

２. 데이터 모델링 필요성

- 데이터 모델링은 프로세스 모델링과 함께 시스템 개발에 있어서 중요한 두 개의 축을 이룬다. 프로세스 중심의 분석/설계 방법을 통해 설계한 데이터 모델은 업무 프로세스의 변화에 따라 영향을 많이 받기 때문에 상대적으로 업무변화에 대한 영향을 적게 받으면서 유연한 시스템을 만들기 위해 데이터 중심의 설계에 많은 관심이 모아지고 있다. 개발 방법론에 따라 다소간 차이는 있으나 데이터 모델링과 프로세스 모델링은 상호 보완적인 관점에서 이해되어야 하며 특히 데이터 모델은 시스템의 뼈대가 되기 때문에 데이터 모델링의 결과에 따라 시스템의 안정성은 많은 영향을 받게 된다고 할 수 있다. 고품질의 데이터 모델은 시스템의 안정성과 유연성, 성능 등에 미치는 영향이 크기 때문에, 고품질의 데이터 모델을 확보하기 위한 데이터 모델링은 시스템 개발에 있어서 가장 핵심적인 과정이라 할 수 있다. 데이터 모델링의 필요성은 다음과 같은 관점에서 설명될 수 있다.

가. 애플리케이션과 데이터의 통합

- 현재 기업에서는 진정한 정보 인프라 구축을 위해 데이터와 애플리케이션의 통합에 많은 노력을 기울이고 있다. 데이터 기반의 통합이 아닌 애플리케이션 코딩 차원의 통합 시도에는 너무나 많은 비용과 시간이 소요된다. 데이터를 기반으로 한 통합은 효과적이면서 동시에 저비용으로 통합 프로젝트를 안정적으로 수행하면서 성공적으로 완수하기 위한 필요조건이 되고 있다. 이로 인해 데이터 기반 통합의 핵심 요소인 데이터 모델링의 중요성은 날로 부각되고 있다.

나. 개발자들의 시스템 이해

- 개발자들은 하나의 애플리케이션에서 사용되는 데이터가 어떤 것인지 파악하고 이해하는 것뿐만 아니라 전체 시스템에서 데이터가 어떻게 상호 연관성을 가지고 유기적으로 움직이고 있는가에 대해 명확하게 이해하는데 많은 어려움을 겪고 있다. 개발자들은 그들이 개발할 시스템과 데이터에 대해 좀더 확실하게 이해하기 위해 데이터의 모형화를 필요로 한다.

1) 사용자 관점 데이터

- 프로세스 모델링과 같이 데이터 모델링은 사용자가 원하는 것의 논리적 개념과 시스템이 어떻게 그것을 제공하는지의 물리적 개념을 명확하게 나타낸다.

2) 물리적 표현 또는 사용에 관계없는 데이터 그 자체의 본질

- 물리적인 것과 논리적인 것을 구별함으로써 저장 기법, 데이터와 파일 접근 방법 그리고 데이터를 사용하는 사람과 사용법에 대한 내역 등 변화되는 물리적인 것으로부터 독립되어 조직과 사용자가 필요로 하는 필수적이고 기본적인 데이터를 정의할 수 있다.

3) 애플리케이션간 데이터 사용

- 데이터 모델링은 데이터 정의, 생명주기 정보(CRUD) 그리고 언제 어떻게 데이터가 사용되었는지를 추적할 수 있는 방법(매트릭스 분석 기법을 이용한 상호작용 분석) 등을 제공함으로써 애플리케이션을 통해 데이터가 어떻게 사용되는지를 개발자들이 쉽게 이해할 수 있도록 한다.

다. 데이터 모델링시 주의점

1) 중복(Duplication)

- 데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 준다. 이러한 지식 응용은 데이터베이스의 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

2) 비유연성(Inflexibility)

- 데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무 변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

3) 비일관성(Inconsistency)

- 데이터의 중복이 없더라도 비일관성은 발생한다. 예를 들어 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 것이다. 개발자가 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문이다. 데이터 모델링시 데이터와 데이터간 상호연관 관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있도록 해준다.

３. 데이터 모델링 단계

- 데이터 모델링은 현실 세계의 기업 업무에서 발생하는 데이터에 대하여 물리적으로 데이터베이스화하기 위해 이루어지는 과정 중의 한 단계이다. 이 데이터 모델링은 개념 데이터 모델링, 논리 데이터 모델링, 물리 데이터 모델링 등 3단계로 나눌 수 있으며, 엄밀한 의미에서는 논리 데이터 모델링 까지를 데이터 모델링의 범주로 보기도 한다.

- 개념 데이터 모델링 단계에서는 주제별로 분류 가능한 업무를 분석한 후 핵심 엔터티(Entity)를 추출하고 그들간의 관계를 정의하여 전체 데이터 모델의 골격을 생성한다. 이렇게 도출된 엔터티(업무)간의 관계를 표현하기 위해 개체-관계 다이어그램(ERD, Entity-Relationship Diagram)을 작성한다. 논리 데이터 모델링 단계에서는 개념 데이터 모델링 단계에서 정의한 핵심 엔터티와 관계를 바탕으로 상세 속성을 정의하고 식별자를 확정하며 정규화와 같은 상세화 과정을 수행한다.

- 마지막으로 물리 데이터 모델링 단계에서는 논리 데이터 모델을 기반으로 목표하는 DBMS의 특성 및 구현환경 등을 감안한 스키마(데이터 구조)를 일정한 기준과 규칙에 의해 도출하고 칼럼(Column)의 데이터 타입과 크기를 정의한다. 또한 데이터 사용량을 분석 예측하는 과정을 통해 효율적인 데이터베이스가 될 수 있도록 인덱스의 정의 및 역정규화 작업을 수행한다.

- 이러한 단계별 내용은 프로젝트 진행과도 일치한다. 물리 데이터 모델링 단계 후에 얻어진 스키마를 실제 데이터베이스로 생성하면 본격적인 애플리케이션 개발 단계로 넘어가게 된다. 그럼 각 단계에 대해 좀더 알아보자.

■TIP

1. 어떠한 데이터가 중요한가?

2. 어떻게 데이터가 표시될 것인가?

3. 어디에 데이터가 저장될 것인가?

- 우선 시스템 분석 및 설계와 데이터베이스 설계의 차이를 알아야 한다. 데이터 모델링에서는 시스템 분석보다 조직의 업무를 지원하기 위한 포괄적 데이터베이스를 개발하는데 초점이 맞춰진다. 반대로 시스템 분석에서는 데이터베이스 요구사항을 고려하기는 하지만 데이터의 흐름, 데이터 변환, 입력, 출력 설계, 데이터 처리를 위한 과정에 초점이 맞춰진다. 보통 데이터 모델링 과정은 개념적 데이터 모델링(개념 데이터 모델링), 논리적 데이터 모델링(논리 데이터 모델링), 물리적 데이터 모델링(물리 데이터 모델링) 과정을 포괄한다

가. 개념 데이터 모델링(Conceptual Data Modeling)

- 개념 데이터 모델링은 조직, 사용자의 데이터 요구사항을 찾고 분석하는데서 시작한다. 이 과정은 어떠한 자료가 중요하며 또 어떠한 자료가 유지되어야 하는지를 결정하는 것도 포함한다. 이 단계에 있어서의 주요한 활동은 핵심 엔터티와 그들 간의 관계를 발견하고, 그것을 표현하기 위해서 개체-관계 다이어그램을 생성하는 것이다. 개체-관계 다이어그램은 조직과 다양한 데이터베이스 사용자에게 어떠한 데이터가 중요한지를 나타내기 위해서 사용된다. 데이터 모델링 과정이 전 조직에 걸쳐 이루어진다면, 그것은 전사적 데이터 모델(Enterprise Data Model)이라고 불린다. 개념 데이터 모델을 통해 조직의 데이터 요구를 공식화하는 것은 두 가지의 중요한 기능을 지원한다.

첫째, 개념 데이터 모델은 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원한다. 개념 데이터 모델은 추상적이다. 그렇기 때문에 그 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다.

둘째, 개념 데이터 모델은 현 시스템이 어떻게 변형되어야 하는가를 이해하는데 유용하다. 일반적으로 매우 고립된(Stand Alone) 시스템도 간단하게 추상적 모델링을 통해서 좀더 쉽게 표현되고 설명된다.

나. 논리 데이터 모델링(Logical Data Modeling)

- 논리 데이터 모델링은 데이터 모델링 프로세스의 Input으로써 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정이라 할 수 있다. 논리 데이터 모델링의 결과로 얻어지는 논리 데이터 모델은 데이터 모델링이 최종적으로 완료된 상태라고 정의할 수 있다. 즉 물리적인 스키마 설계를 하기 전 단계의‘데이터 모델’상태를 일컫는 말이다.

- 논리 데이터 모델링의 핵심은 어떻게 데이터에 액세스하고 누가 데이터에 액세스하며, 그러한 액세스는 전산화와는 독립적으로, 다시 말해서 누가(Who), 어떻게(How) 그리고 전산화는 별개로 비즈니스 데이터에 존재하는 사실들을 인식하여 기록하는 것이며 이것은 기법으로서의 의미를 넘어 하나의 철학이라고도 할 수 있다. 특히 데이터 모델링 과정에서 가장 핵심이 되는 부분이 논리 데이터 모델링이라고 할 수 있다.

- 데이터 모델링이란 모델링 과정을 통해서 조사하고 결정한 사실을 단지 객체-관계 다이어그램이라는 그림으로 그려내는 과정을 말하는 것이 아니다. 시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무 조사를 하는 초기 단계부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는‘과정의 도구’라고 해야 할 것이다.

- 이 단계에서 수행하는 또 한가지 중요한 활동은 정규화이다. 정규화는 논리 데이터 모델 상세화 과 정의 대표적인 활동으로 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 함으로써 좀더 신뢰성있는 데이터 구조를 얻는데 목적이 있다.

- 논리 데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등을 들 수 있으며, 추가적으로 이력 관리에 대한 전략을 정의하여 이를 논리 데이터 모델에 반영함으로써 데이터 모델링을 완료하게 된다. 이에 대한 상세한 내용은 제3장 논리 데이터 모델링에서 다루게 될 것이다.

다. 물리 데이터 모델링(Physical Data Modeling)

- 데이터 모델링 과정의 세 번째 단계인 물리 데이터 모델링은 논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 다룬다. 데이터가 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의를 물리적 스키마라고 한다. 이 단계에서 결정되는 것은 테이블, 칼럼 등으로 표현되는 물리적인 저장 구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 등이 있다.

- 계층적 데이터베이스 관리 시스템 환경에서는 데이터베이스 관리자가 물리적 스키마를 설계하고 구현하기 위해서 보다 많은 시간을 투자하여야 한다. 계층적 데이터베이스 관리 시스템 환경에서의 물리적 스키마 설계의 예는 데이터의 디스크상의 위치, 색인화할 레코드, 다양한 최적화 문제 등이다.

- 이에 비해, 논리 데이터 모델은 매체에 물리적으로 구현되는 것과는 독립적으로 여겨진다. 현실적으로 물리 데이터 모델을 계층적 데이터베이스 관리 시스템에 구현하는 것은 그것이 구현될 하드웨 어와 밀접한 관계를 맺고 있다. 그러나 관계형 데이터베이스 관리 시스템의 출현으로 인해 그 초점이 개념 및 논리 데이터베이스 설계로 이동하고 있다. 그래서 관계형 데이터베이스 관리 시스템을 사용하는 조직에서는 데이터베이스 관리자가 잘 유지해야 하는 데이터 항목의 발견과 데이터 항목 간에 존재하는 논리 관계를 이해하는데 더 많은 시간을 할애한다. 관계형 데이터베이스 관리 시스템의 출현으로 인하여 물리적 데이터베이스 설계와 관련된 문제들은 많은 부분 관계형 데이터베이스 관리 시스템 소프트웨어에서 처리되고 있다.

４. 모델링 기본원칙

- 일반적으로 모델링의 방법론, 기법, 도구와 같은 개발 보조 수단의 사용 없이는 시스템이 잘 설계될 수 없을 것이라 생각하게 된다. 하지만 과거의 수많은 시스템들은 이러한 개발 보조기구의 사용없이 성공적으로 개발됐다. 물론 과거의 시스템들은 단순해서 그러할 수 있었다고 주장한다면 그 말 역시 맞는 말이다. 그러나 이러한 사실들은 여기에서 말하려는 모델링의 핵심 사항은 아니다. 프로젝트의 어려움 정도 또는 도구와 기술에 상관없이 좋은 설계를 포함한 훌륭한 시스템 개발은 다음의 단순한 단계로부터 시작한다.

■해결해야 하는 문제점들을 선별, 결정한다.

■해결책을 위한 문제점들을 구체화한다.

■시스템을 구축한다.

■실제로 구현한다.

- 시스템 개발 실패의 주요 요인을 무엇이라 생각하는가? 그것은 처음의 요구 사항을 충족시키지 못하는 설계자의 무능력을 들 수 있다. 즉 적절한 시스템이 개발되기 위해서는 요구 사항을 완전하고 정확하게 식별해야 한다. 논리 데이터 모델링은 기능 또는 조직이 사용하는 물리적 설계 구조에 관계없이 기업의 비즈니스에 존재하는 데이터의 명확한 구조 및 정의를 제시한다. 이는 최종 사용자 관점에서 바라보는 정보구조를 개념화하고 추상화시킨 데이터의 구조이다. 다음에 설명할 세 가지 최우선 원칙들은 논리 데이터 모델링의 접근 방식을 성공적으로 이끄는 토대이다.

가. 커뮤니케이션 원칙(Communication Principle)

- 요구 사항은 모든 사람들이 이해할 수 있도록 명확하게 공표됨은 물론 최종 사용자 지향적으로 분명하게 파악되는 수준으로 작성되어야 한다. 논리 데이터 모델링의 주목적은 최종 사용자 데이터에대한 뷰(View)를 개념화하고 추상화하여 시스템 설계자들에게 전달하는 것이다. 물론 커뮤니케이션 원칙이 최종 사용자들에게만 적용되는 것은 아니다. 다른 배경과 기술을 가진 많은 사람들도 논리 데이터 모형의 이해를 필요로 한다.

그룹명	필요성
최종사용자	- 개념화, 추상화, 정규화 기법을 통하여 중복없고, 데이터의 정확성을 보장하는 데이터 구조의 이해 및 사용
시스템 분석가	- 시스템에서 사용되어질 정확한 데이터의 구조 및 데이터가 갖는 업무 규칙의 이해
데이터베이스 관리자	- 논리데이터 모델의 구조와 물리 스키마(데이터의 구조)의 차이점을 이해하고, 최종 사용자에게는 데이터의 제공, 시스템 분석가에게는 물리 스키마의 제공을 위한 데이터 구조의 이해
타 프로젝트에서 작업하는 분석가	- 관련 프로젝트가 데이터를 어떻게 정의하고 있는지를 알아냄 - 인터페이스가 개발되어지고 데이터가 애플리케이션 또는 시스템 간의 고유되기 위한 데이터 구조 및 업무 규칙의 이해

- 그룹 구성원들과의 커뮤니케이션을 용이하게 하기 위해서는 두 가지의 논리 데이터 모델을 생각해 볼 수 있다. 그것은 비즈니스 지향적인 최종 사용자 데이터 모델과 기술적인 상세 데이터 모델이다. 논리 데이터 모델의 문서와 그림을 작성할 때 그 목적을 명확히 해야 한다. 왜냐하면 모델을 보는 사람들에게 기술적으로 알아보기 힘든 혼란을 주는 것은 곤란하기 때문이다. 이와 같은 명확한 정의를 통해 시스템 개발 관련자와 최종 사용자들간에 비즈니스 요구 사항이 정확히 전달되어야 한다.

나. 모델링 상세화 원칙(Granularity Principle)

- 데이터의 상세화 정도를 제시하고 조직이 사용하는 정보 구조의‘최소 공통 분모’를 제시해야 한다. 또한 복잡한 구조는 요소적인 부분들로 쪼개야 하며 불필요한 구조와 중복은 제거되어야 한다. 일반적으로 논리 데이터 모델은 너무 상세화될 필요가 없다든지 애플리케이션에 대한 상세화는 물리데이터 모델에서 이룰 수 있다라는 생각은 위험한 태도이다. 모델링의 상세화 원칙은‘데이터는 데이터의 본질과 잠재적 사용을 이해할 수 있을 만큼 상세화 되어야 한다’는 것을 의미한다.

- 사실 좋은 설계는 분석 단계(논리 데이터 모델)를 위한 상세 수준이 다른 단계(물리 데이터 모델)에서 선택된 수준만큼 상세화되어야 한다는 것을 의미한다. 많은 모델러(Modeler)들이 겪는 문제는 논리 데이터 모델에서 물리 데이터 모델로의 이동이 분해 과정이라고 오해하는 것이다. 하지만 논리 데이터 모델에서 물리 데이터 모델로의 이동은 분해가 아니라 보통 수준의 상세화에서 발생하는 변환(Transformation)이다. 즉 물리 데이터 모델링은 논리 데이터 모델에 대한 변환 과정이다.

다. 논리적 표현 원칙(Logical Representation Principle)

- 조직의 데이터에 대한 논리적 측면을 최대한 표현해야 한다. 모델은 물리적 제약 조건 없이 비즈니스를 그대로 반영해야 한다. 즉 논리 데이터 모델은 특정 아키텍처, 기술 또는 제품과 독립적이어야 한다는 것이다. 그리고 최종 사용자들이 항상 시스템 개발자들에게 가지는 주요 불만 사항은 바로 ‘이해의 부족’이다. 사용자가 원하는 것에 근거를 두지 않은 프로젝트는 실패할 확률이 높다. 또한 기존 애플리케이션에 대한 빈약한 문서화의 주요 원인 중 하나는 성급하게 물리적 설계 단계로 들어 가려 하는 분석가들의 성향 때문이다. 논리적 설계와 물리적 설계를 구별하지 못하면 프로젝트가 추구하고자 하는 물리적 선택 사항을 제한하거나 잘못된 방향으로 진행하게 된다. 이러한 문제들을 예를 통해 이해해 보자.

1) 웬만한 분석의 결과는 잘 알고 있다(지름길을 좋아하는 것)

- 어떤 이들은 여러 가지 이유(예를 들어, 자명하게 보이는 분석을 수행하는 데 시간 낭비를 줄이기 위해 또는 결과가 이미 정해져 있어서)때문에 분석을 생략하는 경우가 많다. 대부분의 경우에서 모델러들은 애플리케이션 개발 과정에서 발생할 수 있는 모든 것들을 알 수 없다. 또한 모델러들은 몇 십년내에 시스템에서 발생할 수 있는 것에 대해서도 확신하지는 못한다. 결론적으로 최적의 행동은 솔루션에 독립적인 방식으로 규칙을 따르고 문제를 문서화하는 것이다.

2) 조급하게 솔루션을 구체화하는 것

- 문제를 조사할 때 데이터베이스가 어떻게 구현되어야 하는가에 관한 기발한 아이디어가 나오기란 어렵다. 이러한 점에서 섣불리 솔루션을 구체화하는 것은 잘못된 것이다. 그 이유는 문제의 일부분만을 파악했을 때 이를 해결할 수 있는 모든 데이터가 확보된 것은 아니며 나중에 인식한 문제로부터 다른 솔루션을 발견할 수도 있기 때문이다. 또한 문제가 정확히 진술된 것이 아니기 때문에 작업물을 검토하는 다른 사람들은 솔루션이 문제를 해결하는 이유를 이해할 수 없을 것이다.

- 이것은 분석가들이 솔루션을 그들의 머리에서 없애야 한다는 것이 아니라 솔루션에 대한 좋은 생각이 표면화 되었을 때 그것을 기록하여 논리적 설계 다음에 물리 데이터 모델 설계자에게 전달하여야 한다는 것을 의미한다. 논리적 설계의 컴포넌트가 부정확하거나 빼먹었을 때 물리 데이터 모델에서 논리 데이터 모델로의 회귀는 피할 수 없다. 물리 데이터 모델 제약 조건이 명시된 경우 조차도 논리 데이터 모델은 제약 조건이 없는 것처럼 진행해야 한다. 그럼에도 불구하고 이러한 경우들이 논리적 표현 원칙을 변화시키지는 않는다. 논리 데이터 모델링이 2년짜리 프로젝트의 첫 단계이든지 수많은 2주 짜리의 반복 과정이든지에 상관 없이 원칙은 솔루션을 구체화하기 전에 문제를 이해해야 한다는 것이다.