양자내성암호 표준화 동향

양자내성암호 표준화 동향

NIST 표준 확정부터 HQC, 추가 전자서명, TLS 전환, 국내 KpqC까지

앞선 글에서는 왜 양자내성암호가 필요한지 살펴봤습니다. 이번 글에서는 한 단계 더 나아가 어떤 알고리즘이 실제 표준으로 선정되었고, 현재 표준화와 전환이 어디까지 진행되었는지를 정리합니다. 아래 내용은 2026년 10월 기준입니다.

양자내성암호 시리즈
  • INTRODUCTION - 양자내성암호의 필요성과 개념
  • 양자내성암호 표준화 동향
  • 격자 기반 문제
  • ML-KEM의 규격
  • ML-KEM의 구현
  • ML-DSA의 규격
  • ML-DSA의 구현

표준화가 왜 중요할까?

양자내성암호 알고리즘은 논문에 제안되었다고 바로 실무에 사용할 수 있는 것이 아닙니다. 안전성 분석, 구현 성능, 키와 서명 크기, 부채널 공격 대응, 다양한 플랫폼에서의 구현 가능성 등을 오랜 기간 검증해야 합니다.

STANDARDIZATION

표준화는 단순히 “좋은 알고리즘 하나를 고르는 과정”이 아니라, 여러 연구자가 장기간 공격하고 분석한 뒤 실제 시스템에서 사용할 수 있는 규격으로 확정하는 과정입니다.

현재 가장 큰 흐름은 미국 NIST의 PQC 표준화입니다. NIST는 2016년부터 공개적인 경쟁 방식으로 후보 알고리즘을 평가했고, 2024년 처음으로 3개의 PQC 표준을 공식 발행했습니다.

NIST의 첫 PQC 표준: FIPS 203·204·205

2024년 8월 13일, NIST는 다음 세 표준을 공식 발표했습니다.

표준알고리즘기반용도
FIPS 203ML-KEMModule-Lattice키 캡슐화 / 키 설정
FIPS 204ML-DSAModule-Lattice전자서명
FIPS 205SLH-DSAHash-based전자서명

이름이 조금 낯설 수 있지만, 각각 기존 공모전의 CRYSTALS-Kyber → ML-KEM, CRYSTALS-Dilithium → ML-DSA, SPHINCS+ → SLH-DSA에 해당합니다.

중요한 변화는 이제 PQC가 “연구 중인 후보 기술”만이 아니라, 실제로 사용할 수 있는 공식 암호 표준의 단계에 들어왔다는 점입니다.

현재 NIST 표준화 상황을 한눈에 보면

  • 2016NIST PQC 공개 공모 시작
  • 2022Kyber, Dilithium, Falcon, SPHINCS+ 등 표준화 대상 선정
  • 2024.08FIPS 203·204·205 발행
  • 2025.03HQC를 추가 KEM 표준화 대상으로 선정
  • 2026.05추가 전자서명 공모에서 9개 후보가 3라운드 진출
  • 현재FN-DSA(Falcon) 표준 FIPS 206 개발 및 추가 표준화 작업 진행

왜 ML-KEM이 있는데 HQC를 또 선정했을까?

NIST는 2025년 3월, 4라운드 KEM 후보 중 HQC를 추가 표준화 대상으로 선정했습니다. HQC는 ML-KEM을 대체하기 위한 알고리즘이 아니라 백업 역할을 하는 두 번째 KEM입니다.

PRIMARY KEMML-KEM

격자 기반. 현재 NIST가 일반적인 용도로 우선 권고하는 표준 KEM입니다.

BACKUP KEMHQC

부호 기반. ML-KEM과 다른 수학적 문제에 기반해 알고리즘 다양성을 확보합니다.

암호 표준을 하나의 수학적 가정에만 의존시키면, 향후 해당 기반 문제에서 예상하지 못한 취약점이 발견될 때 위험이 커질 수 있습니다. 그래서 NIST는 서로 다른 수학적 기반을 가진 알고리즘을 함께 확보하려고 합니다.

HQC는 아직 FIPS로 최종 발행된 상태가 아닙니다.

2026년 10월 현재 HQC는 표준화 대상으로 선정된 상태이며, NIST는 최종 표준을 2027년경 발표할 계획이라고 설명하고 있습니다. 따라서 현재 실무 전환의 중심은 여전히 ML-KEM입니다.

전자서명도 추가 후보를 계속 찾고 있다

전자서명의 경우 이미 ML-DSA와 SLH-DSA가 표준화되었고, Falcon 기반의 FN-DSA도 FIPS 206으로 개발 중입니다.

하지만 NIST는 여기서 멈추지 않고 추가 전자서명 알고리즘 공모를 진행하고 있습니다. 특히 ML-DSA와 다른 수학적 기반을 가진 전자서명을 확보해 알고리즘 다양성을 높이는 것이 중요한 목적입니다.

2026년 5월 NIST는 다음 9개 알고리즘을 3라운드 후보로 선정했습니다.

3라운드 후보주요 계열
FAEST대칭키 / 영지식 계열
HAWK격자 기반
MAYO다변수 기반
MQOM영지식 계열
QR-UOV다변수 기반
SDitH영지식 계열
SNOVA다변수 기반
SQIsign아이소제니 기반
UOV다변수 기반

즉 PQC 표준화는 끝난 것이 아닙니다. 첫 번째 실사용 표준은 이미 나왔지만, 백업 알고리즘과 다양한 전자서명 후보에 대한 검증은 계속 진행 중입니다.

표준 선정 다음 단계: 실제 프로토콜에 넣기

암호 알고리즘이 FIPS로 표준화되었다고 해서 인터넷의 모든 통신이 자동으로 PQC로 바뀌는 것은 아닙니다. TLS, VPN, PKI, 인증서, HSM, 라이브러리 등 실제 시스템이 새 알고리즘을 사용할 수 있도록 별도의 프로토콜 표준과 구현 작업이 필요합니다.

이 과정에서 많이 사용되는 방식이 Hybrid 방식입니다. 기존 ECDH와 PQC 알고리즘을 동시에 사용해 두 결과를 결합합니다.

HYBRID KEY AGREEMENT

기존 알고리즘과 PQC 알고리즘을 함께 사용해, 둘 중 적어도 하나가 안전하면 전체 키 설정의 안전성을 유지하도록 설계하는 전환 방식입니다.

2026년 8월 IETF는 TLS 1.3에서 사용할 X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024를 정의한 RFC 10024를 Standards Track으로 발행했습니다.

표준화의 초점이 이제 “어떤 PQC를 고를 것인가”에서 “기존 인터넷과 인프라에 어떻게 안전하게 전환할 것인가”로 이동하고 있습니다.

국내: KpqC도 최종 후보 선정에서 표준화 단계로

국내에서도 한국형 양자내성암호 확보를 위해 KpqC 양자내성암호 국가공모전이 진행되었습니다. 2025년 1월 최종 4개 알고리즘이 선정되었습니다.

구분알고리즘기반 문제
공개키암호 / 키설정NTRU+격자 기반
공개키암호 / 키설정SMAUG-T격자 기반
전자서명HAETAE격자 기반
전자서명AIMer영지식 + 대칭키 기반

그리고 2026년 4월 KpqC 연구단은 NTRU+와 SMAUG-T의 KS 제정 제안이 제출되었고, AIMer와 HAETAE도 향후 표준 제정 제안을 위한 검토가 진행 중이라고 안내했습니다.

국내 표준화에서 볼 점

NIST 표준을 그대로 사용하는 것과 별개로, 국내에서도 자체 알고리즘을 확보하고 표준화하려는 작업이 진행되고 있습니다. 이는 알고리즘 다양성뿐 아니라 국내 암호 기술 생태계와 구현 역량 확보 측면에서도 의미가 있습니다.

지금 시점의 표준화 흐름을 정리하면

01 · STANDARD첫 표준은 이미 확정

ML-KEM, ML-DSA, SLH-DSA는 2024년 공식 FIPS가 되었습니다.

02 · DIVERSITY알고리즘 다양성 확보

HQC와 추가 전자서명 후보를 통해 한 종류의 수학적 문제에 대한 의존을 줄이고 있습니다.

03 · MIGRATION실제 시스템 전환

TLS와 PKI 등 기존 프로토콜에 PQC를 적용하기 위한 하이브리드 전환이 진행 중입니다.

04 · KOREA국내 표준화 진행

KpqC 최종 4종이 선정되었고 일부 KEM은 KS 제정 제안 단계로 이동했습니다.

2026년의 핵심

양자내성암호는 더 이상 “언젠가 사용할 미래 암호”만이 아닙니다. 표준 선정 단계에서 실제 전환과 배포 단계로 넘어가고 있습니다.

다음 글에서는 현재 PQC 표준에서 가장 중심적인 위치를 차지하고 있는 ML-KEM과 ML-DSA를 이해하기 위해, 먼저 격자 기반 문제(Lattice-based Problem)가 무엇인지 살펴보겠습니다.

참고 자료

REA: 코딩 에이전트와 함께하는 리버스 엔지니어링
Reverse Engineering

REA: 코딩 에이전트와 함께하는 리버스 엔지니어링

바이너리와 실행 중인 프로그램을 분석하고, AI 코딩 에이전트가 동작 원리를 설명하도록 돕는 REA를 쉽게 정리합니다.

AI 코딩 에이전트는 이제 코드를 작성하는 것을 넘어, 프로그램 내부를 분석하고 왜 그렇게 동작하는지 설명하는 역할까지 확장되고 있습니다.

REA(Reverse Engineer Anything)는 프로그램에서 함수, 디컴파일 코드, 호출 관계 등을 찾아 코딩 에이전트에 전달하고, 에이전트가 이를 사람이 이해하기 쉬운 설명으로 바꾸도록 돕는 도구입니다.

ANALYZE

프로그램 분석

바이너리와 실행 중인 프로그램의 내부 구조를 살펴봅니다.

EXPLAIN

자연어 설명

어셈블리와 디컴파일 결과를 사람이 이해할 수 있는 규칙으로 바꿉니다.

REBUILD

동작 재구현

찾아낸 규칙을 바탕으로 작은 프로그램이나 비슷한 동작을 다시 만들 수 있습니다.

REA 공식 사이트

REA는 무엇을 해주는가?

리버스 엔지니어링은 소스 코드를 직접 보는 대신, 실행 파일이나 실제 동작을 분석해 내부 로직을 추론하는 작업입니다.

기존 방식

어셈블리 분석
→ 함수 호출 추적
→ 조건 분기 확인
→ 계산 방식 추론
→ 동작 재구현

REA를 사용하면 이 과정에서 필요한 정보를 코딩 에이전트가 직접 활용할 수 있습니다.

“이 프로그램은 왜 이렇게 동작해?”
사용자의 질문
      ↓
REA가 프로그램 분석
      ↓
함수 / 디컴파일 코드 / 호출 관계 제공
      ↓
코딩 에이전트가 해석
      ↓
자연어 설명 또는 재구현

예제 1: Chrome 공룡 게임은 왜 점점 빨라질까?

REA 공식 사이트의 예제에서는 Chrome 공룡 게임을 분석해 다음 설정을 찾습니다.

SPEED = 6
ACCELERATION = 0.001
MAX_SPEED = 13

즉 게임은 속도 6에서 시작해 업데이트마다 0.001씩 빨라지고, 최대 13까지 증가합니다.

if (this.currentSpeed < this.config.MAX_SPEED) {
    this.currentSpeed += this.config.ACCELERATION;
}

REA는 이런 규칙을 실제 프로그램에서 찾아내고, 코딩 에이전트가 이를 바탕으로 동작을 설명하거나 다시 구현할 수 있게 합니다.


예제 2: Windows 계산기의 % 버튼

Windows 계산기에서는 같은 % 버튼도 연산에 따라 다르게 동작합니다.

200 + 10% = 220
200 × 10% = 20

곱셈에서는 10%를 0.1로 바꾸지만, 덧셈에서는 먼저 200의 10%인 20을 계산한 뒤 더합니다.

if (operation == multiply || operation == divide) {
    percent = current / 100;
} else {
    percent = current * previous / 100;
}

즉 바이너리 내부의 분기와 계산을 찾아 사람이 이해할 수 있는 규칙으로 복원하는 것이 핵심입니다.


기존 Ghidra·IDA와 무엇이 다른가?

기존 방식

Binary
  ↓
Ghidra / IDA
  ↓
Assembly / Decompiled Code
  ↓
사람이 직접 분석

REA + 코딩 에이전트

Binary
  ↓
REA
  ↓
Assembly / Decompiled Code
  ↓
AI Coding Agent
  ↓
설명 / 재구현

REA가 Ghidra나 IDA를 완전히 대체한다기보다, 코딩 에이전트가 리버스 엔지니어링 결과를 활용할 수 있게 해주는 연결 계층에 가깝습니다.


어떤 프로그램을 분석할 수 있을까?

자료에서는 REA가 다음과 같은 범위를 다룬다고 설명합니다.

Native Binary

.exe
.dll
native executable
library

JavaScript / Electron

Modules
Routes
IPC
Native Dependencies

Browser / Runtime

실행 중인 브라우저나 프로세스의 동작을 관찰하고 여러 실행 결과를 비교하는 분석도 가능합니다.


왜 주목받고 있을까?

기존 리버스 엔지니어링에는 Assembly, Calling Convention, Memory Layout, Decompiler, Debugger, Binary Format 같은 지식이 많이 필요했습니다.

하지만 REA와 코딩 에이전트를 함께 사용하면 사용자는 자연어로 질문할 수 있습니다.

“이 프로그램의 속도 증가 규칙을 찾아줘.”

“이 버튼이 왜 이렇게 동작하는지 설명해줘.”

“원래 동작을 재현한 작은 프로그램을 만들어줘.”
리버스 엔지니어링의 인터페이스가 “어셈블리를 직접 읽는 작업”에서 “AI에게 무엇을 분석할지 지시하고 결과를 검증하는 작업”으로 이동하고 있습니다.

법적·윤리적 주의점

리버스 엔지니어링은 기술적으로 가능한 것과 법적으로 허용되는 것이 다를 수 있습니다.

비교적 명확한 활용 예
  • 자신이 소유한 프로그램 분석
  • 개발이 중단된 소프트웨어 보존
  • 호환성 연구
  • 버그 원인 분석
  • 교육 및 연구

반면 상용 독점 소프트웨어를 분석해 동일한 제품을 복제하거나 DRM·라이선스 보호를 우회하면 저작권·계약·접근통제 관련 문제가 생길 수 있습니다.

REA가 분석을 쉽게 해준다고 해서 모든 분석과 재구현이 자동으로 허용되는 것은 아닙니다.

개발 문화에는 어떤 영향을 줄까?

REA와 같은 도구는 리버스 엔지니어링의 진입장벽을 크게 낮출 수 있습니다.

디컴파일
→ 함수 분석
→ 이름 추론
→ 로직 복원
→ 코드 재작성

개인 개발자도 예전보다 쉽게 오래된 프로그램이나 게임의 동작을 분석할 수 있습니다. 반대로 문제를 직접 풀어가는 과정과 전문성이 약해질 수 있다는 우려도 있습니다.


정리

REA는 리버스 엔지니어링 도구와 AI 코딩 에이전트를 연결해 프로그램의 내부 동작을 자연어로 이해할 수 있게 해주는 도구입니다.

“이 프로그램은 왜 이렇게 동작해?”
        ↓
REA가 실제 프로그램 분석
        ↓
관련 코드와 호출 정보 제공
        ↓
코딩 에이전트가 해석
        ↓
설명 / 수정 / 재구현

Chrome 공룡 게임의 속도 증가 규칙이나 Windows 계산기의 % 동작처럼, 실제 프로그램의 내부 규칙을 찾아내고 설명할 수 있다는 점이 REA의 특징입니다.

앞으로 리버스 엔지니어링의 중심은 “어셈블리를 직접 읽는 능력”만이 아니라, “AI에게 무엇을 분석시킬지 정하고 결과를 검증하는 능력”으로 넓어질 수 있습니다.

접근성은 높아지지만, 상용 소프트웨어 분석과 재구현에서는 라이선스와 법적 범위를 함께 확인해야 합니다.

REA 공식 사이트
ZTNA를 선택할 때 봐야 할 것
Security Architecture

ZTNA를 선택할 때 봐야 할 것: ‘문을 지킬 것인가, 문 자체를 숨길 것인가’

Public Edge와 Private Edge의 차이, 그리고 ZTNA와 SASE를 평가할 때 실제로 확인해야 할 보안 구조를 정리합니다.

최근 금융권을 포함해 외부에 공개된 업무시스템을 겨냥한 공격이 늘어나면서, ZTNA(Zero Trust Network Access)와 SASE(Secure Access Service Edge)에 대한 관심도 높아지고 있습니다.

이 기사에서 던지는 핵심 질문은 간단합니다.

외부 접근을 통제하는 것만으로 충분한가, 아니면 공격자가 기업의 접속 지점 자체를 발견하기 어렵게 만들어야 하는가?

기사는 이를 ‘임금님의 투명 갑옷’과 ‘해리포터의 투명 망토’에 비유합니다.

보안뉴스 원문 기사 보기 ↗
PUBLIC EDGE

문은 강화하지만 위치는 보입니다

Public IP와 포트가 외부에 노출될 수 있어 게이트웨이 자체가 공격 표면이 될 수 있습니다.

PRIVATE EDGE

문 자체를 외부에서 숨깁니다

내부 시스템이 인터넷에서 직접 연결을 받지 않도록 해 Attack Surface 자체를 줄이는 방식입니다.


인바운드 ZTNA: 문은 강화했지만 위치는 보입니다

기존의 인바운드 ZTNA는 대체로 다음과 같은 구조를 가집니다.

Internet
   ↓
Public IP
   ↓
IPS / WAF
   ↓
ZTNA Gateway
   ↓
Internal Service
용어 설명

IPS (Intrusion Prevention System): 네트워크 트래픽에서 공격 패턴이나 비정상 행위를 탐지하고, 필요하면 패킷 차단이나 세션 종료까지 수행하는 침입방지 시스템입니다.

WAF (Web Application Firewall): SQL Injection, XSS, 비정상 HTTP 요청처럼 웹 애플리케이션 계층의 공격을 탐지·차단하는 방화벽입니다.

ZTNA Gateway: 사용자 신원, 장치 상태, 접근 정책을 확인한 뒤 허가된 애플리케이션에만 접근하도록 중개하는 접점입니다.

이 구조에서는 사용자 인증과 접근 제어를 적용하고, IPS나 IP 차단을 통해 알려진 공격을 걸러낼 수 있습니다.

문제는 기업의 접속 관문이 되는 Public IP와 포트가 여전히 인터넷에 노출될 수 있다는 점입니다.

공격자는 Shodan과 같은 인터넷 스캐너를 이용해 시스템의 존재와 열린 포트를 확인할 수 있습니다. ZTNA 게이트웨이나 보안 장비 자체에 취약점이 있다면 그 장비가 새로운 공격 표면이 될 수 있습니다.


Private Edge: 공격 표면 자체를 줄입니다

기사에서 대안으로 제시하는 방식은 Private Edge 기반 SASE입니다.

User
  ↓
SASE POP
  ↓
ZTNA / IPS / SWG / CASB / DLP
  ↓
Private Backbone
  ↓
Outbound Connector
  ↓
Internal Service
용어 설명

SASE POP (Point of Presence): 사용자가 접속하는 SASE 사업자의 네트워크 거점입니다. 인증과 보안 정책 적용이 이 지점에서 수행될 수 있습니다.

Private Backbone: 사업자가 관리하는 사설·전용 네트워크 구간을 의미합니다.

Outbound Connector: 내부망에서 SASE 서비스 방향으로 먼저 아웃바운드 연결을 생성하는 구성요소입니다. 외부에서 내부망으로 직접 인바운드 연결을 열지 않는 것이 핵심입니다.

핵심은 내부 업무시스템이 인터넷에서 직접 연결을 받지 않는 구조입니다.

내부 커넥터가 먼저 SASE 서비스로 연결을 만들고, 사용자는 SASE의 인증과 보안 정책을 통과한 뒤에만 내부 애플리케이션에 접근합니다.

즉, 단순히 공격을 차단하는 것을 넘어 공격자가 직접 접근할 수 있는 Attack Surface 자체를 줄이는 것이 핵심입니다.


ZTNA와 SASE는 같은 개념이 아닙니다

ZTNA는 주로 누가 어떤 애플리케이션에 접근할 수 있는가를 통제하는 기술입니다. 반면 SASE는 여러 네트워크·보안 기능을 하나의 서비스 형태로 통합합니다.

  • ZTNA: 사용자와 장치 기반 접근 제어
  • SWG: 웹 트래픽 필터링
  • CASB: SaaS 사용과 데이터 흐름 통제
  • DLP: 중요정보 유출 방지
  • IPS: 공격 탐지와 차단
용어 설명

SWG (Secure Web Gateway): 웹 접속을 중계하면서 악성 URL, 위험 사이트, 다운로드 파일, 정책 위반 요청 등을 검사합니다.

CASB (Cloud Access Security Broker): SaaS·클라우드 서비스 사용을 가시화하고 사용자별 접근 정책과 데이터 이동을 통제합니다.

DLP (Data Loss Prevention): 주민번호, 계좌번호, 기밀 문서 같은 중요정보가 외부로 유출되는 것을 탐지하고 차단합니다.

따라서 인증에 성공했다고 해서 보안이 끝나는 것은 아닙니다. Zero Trust 환경에서는 접속 전 인증뿐 아니라 접속 이후의 트래픽과 데이터 흐름까지 지속적으로 검사해야 합니다.


CISO가 확인해야 할 핵심 질문

1
기업의 실제 Public IP와 인바운드 포트가 외부에 그대로 노출되는가?
2
게이트웨이나 보안 장비가 침해되었을 때 내부 시스템으로 직접 접근할 수 있는 구조인가?
3
인증 이후에도 IPS, SWG, CASB, DLP 등을 통해 트래픽과 데이터 흐름을 검사하는가?

여기에 MFA, Device Posture, 최소 권한, 마이크로 세그멘테이션, 공급자 장애 대응, SASE 사업자 자체의 보안 수준도 함께 확인해야 합니다.

추가 용어

MFA (Multi-Factor Authentication): 비밀번호 외에 OTP, 인증 앱, 생체정보 등 두 가지 이상의 인증 요소를 함께 요구하는 방식입니다.

Device Posture: OS 패치, 백신, 디스크 암호화, 루팅·탈옥 여부 등 접속 단말의 보안 상태를 평가하는 개념입니다.

Micro-segmentation: 내부망을 작은 보안 구역으로 나눠 침해 시 다른 시스템으로의 횡적 이동을 제한하는 방식입니다.


Private Edge가 ‘침투 불가능’을 의미하지는 않습니다

Private Edge를 강하게 강조하더라도 이 부분은 신중하게 볼 필요가 있습니다.

Private Edge ≠ Zero Risk

Public IP를 제거하더라도 다음과 같은 위험은 여전히 존재합니다.

  • 계정 탈취
  • 세션 탈취
  • 잘못된 IAM 정책
  • Endpoint 감염
  • Connector 취약점
  • SASE 공급망 공격
  • 내부자 위협
인터넷에서 기업 내부 시스템으로 직접 접근할 수 있는 공격 표면을 크게 줄이는 아키텍처

보안 용어 한눈에 정리

ZTNA

사용자와 장치를 검증하고 허가된 애플리케이션 단위로 접근시키는 Zero Trust 접근 기술입니다.

SASE

ZTNA, SWG, CASB, DLP 등의 네트워크·보안 기능을 클라우드 서비스 형태로 통합하는 아키텍처입니다.

IPS

네트워크 공격 패턴과 이상 행위를 탐지하고 실시간으로 차단하는 침입방지 시스템입니다.

WAF

SQL Injection, XSS 등 웹 애플리케이션 계층 공격을 막는 방화벽입니다.

SWG

웹 접속을 검사해 악성 사이트, 위험 파일, 정책 위반 트래픽을 차단합니다.

CASB

클라우드·SaaS 사용을 가시화하고 사용자·데이터 접근 정책을 제어합니다.

DLP

중요정보가 이메일, 웹, 클라우드 등을 통해 외부로 유출되는 것을 탐지·차단합니다.

MFA

비밀번호 외에 추가 인증 요소를 요구해 계정 탈취 위험을 줄입니다.

Device Posture

접속 단말이 조직의 보안 기준을 충족하는지 평가하는 정책 조건입니다.

Micro-segmentation

내부 시스템 간 이동을 세밀하게 제한해 침해 확산을 줄이는 네트워크 분리 방식입니다.


정리

기존 보안이 주로 “들어오는 공격을 얼마나 잘 탐지하고 차단할 것인가”에 집중했다면, Private Edge 기반 SASE는 “기업의 실제 업무시스템을 인터넷에서 직접 보이지 않게 만들 수 있는가”까지 고려합니다.

결국 중요한 것은 ZTNA라는 이름 자체가 아니라 Attack Surface를 얼마나 줄일 수 있는지, 인증 이후에도 최소 권한과 트래픽 검사, 데이터 보호를 지속적으로 적용할 수 있는 구조인지입니다.

Zero Trust는 단순히 문지기를 강하게 만드는 보안 모델이 아닙니다.
노출되는 문을 최소화하고, 그 문을 통과한 이후의 행동까지 계속 검증하는 보안 모델로 이해하는 것이 가장 정확합니다.
정적 라이브러리, 동적 라이브러리, 그리고 macOS Framework의 차이
Developer Notes

정적 라이브러리, 동적 라이브러리, 그리고 macOS Framework의 차이

.a, .dylib, .framework를 링크 시점·배포 방식·메모리 사용·패키징 구조 관점에서 비교합니다.

C/C++이나 macOS 개발을 하다 보면 .a, .dylib, .framework 같은 파일을 자주 만나게 됩니다.

겉으로 보면 모두 “다른 프로그램의 기능을 가져다 쓰기 위한 라이브러리”처럼 보이지만, 실제로는 링크되는 시점과 배포 방식, 메모리 사용 방식, 패키징 구조가 서로 다릅니다.

STATIC

정적 라이브러리

.a

빌드 시 필요한 라이브러리 코드가 실행 파일 내부에 포함됩니다.

DYNAMIC

동적 라이브러리

.dylib

실행 시 동적 로더가 별도 라이브러리를 찾아 메모리에 로드합니다.

BUNDLE

macOS Framework

.framework

바이너리, 헤더, 리소스, 메타데이터 등을 하나의 Bundle로 묶습니다.

구분 정적 라이브러리 동적 라이브러리 Framework
대표 확장자.a.dylib.framework
실제 코드가 앱에 포함되는가OX내부 바이너리에 따라 다름
링크 시점빌드 시빌드 + 실행 시내부 바이너리에 따라 다름
별도 배포 필요보통 XO보통 O
여러 프로세스 간 코드 공유X가능동적 Framework라면 가능
헤더/리소스 포함XXO
버전 관리 구조별도 구현dylib 자체 지원Bundle 구조로 지원
macOS 친화성일반적일반적매우 높음

1. 먼저 라이브러리란 무엇인가?

프로그램을 작성하다 보면 모든 기능을 직접 구현하지는 않습니다.

예를 들어 다음과 같은 함수를 여러 프로그램에서 사용한다고 해보겠습니다.

int add(int a, int b);
int subtract(int a, int b);

이 코드들을 하나의 라이브러리로 만들어 두면 여러 프로그램이 공통으로 사용할 수 있습니다.

math library
 ├─ add()
 ├─ subtract()
 └─ multiply()

       ↓ 사용

Application A
Application B
Application C

문제는 이 라이브러리 코드를 최종 실행 파일에 어떻게 연결할 것인가입니다.

여기서 정적 링크와 동적 링크가 나뉩니다.


2. 정적 라이브러리란?

정적 라이브러리(Static Library)는 빌드할 때 필요한 라이브러리 코드를 실행 파일 안에 포함시키는 방식입니다.

Unix/macOS에서는 일반적으로 다음 확장자를 사용합니다.

libcrypto.a
libmath.a
libfoo.a

.a는 archive를 의미합니다.

정적 라이브러리는 여러 개의 object file을 묶어 놓은 파일이라고 이해하면 쉽습니다.

foo.c
  ↓ compile
foo.o

bar.c
  ↓ compile
bar.o

foo.o + bar.o
      ↓
   libtest.a

그리고 프로그램을 빌드할 때 linker가 필요한 코드를 가져옵니다.

main.o
   +
libtest.a
   ↓
Linker
   ↓
my_app

최종적으로 필요한 라이브러리 코드가 my_app 내부에 들어갑니다.

실제로는 라이브러리 전체가 복사되는가?

“정적 라이브러리를 링크하면 .a 전체가 실행 파일에 복사된다.”

라고 설명하지만 엄밀하게는 약간 다릅니다.

일반적으로 linker는 .a 안에 들어 있는 object file 중에서 필요한 심볼을 제공하는 object를 선택해 링크합니다.

libmath.a

add.o
subtract.o
matrix.o
fft.o

프로그램이 add()만 사용한다면 모든 코드가 반드시 포함되는 것은 아닙니다.


3. 정적 라이브러리의 장점

가장 큰 장점은 배포가 단순하다는 것입니다.

my_app

안에 필요한 라이브러리 코드가 이미 포함되어 있다면 실행할 때 별도로 libfoo.dylib를 찾아야 할 필요가 없습니다.

따라서 실행 환경에서 다음과 같은 문제가 줄어듭니다.

Library not loaded

또한 특정 버전의 라이브러리가 실행 파일 안에 고정되므로, 개발 당시 사용한 버전의 영향을 비교적 안정적으로 유지할 수 있습니다.


4. 정적 라이브러리의 단점

반대로 실행 파일이 커질 수 있습니다.

App A
 └─ Library Code

App B
 └─ Library Code

App C
 └─ Library Code

각 실행 파일에 라이브러리 코드가 들어갑니다.

또 하나의 중요한 단점은 라이브러리를 수정하면 애플리케이션을 다시 링크해야 한다는 것입니다.

libfoo.a 수정
   ↓
Application 재빌드/재링크 필요

5. 동적 라이브러리란?

동적 라이브러리(Dynamic Library)는 라이브러리 코드를 실행 파일 내부에 넣지 않고 별도의 라이브러리 파일로 유지하는 방식입니다.

macOS   → libfoo.dylib
Linux   → libfoo.so
Windows → foo.dll
Application
     │
     │ 참조
     ▼
libfoo.dylib
“이 프로그램은 실행할 때 libfoo가 필요하다”

라는 의존 관계가 실행 파일에 기록됩니다.


6. 동적 라이브러리는 언제 연결되는가?

동적 라이브러리라고 해서 컴파일/링크 단계에서 아무것도 하지 않는 것은 아닙니다.

소스 코드
   ↓
Compiler
   ↓
Object File
   ↓
Linker
   ↓
Executable

linker는 “이 함수는 libfoo.dylib에서 제공된다”라는 정보를 실행 파일에 기록합니다.

그리고 프로그램 실행 시 macOS의 동적 로더인 dyld가 실제 라이브러리를 찾아 메모리에 로드합니다.

Application 실행
        ↓
       dyld
        ↓
필요한 dylib 검색
        ↓
라이브러리 로드
        ↓
Symbol 연결
        ↓
프로그램 실행

7. 동적 라이브러리의 장점

App A ─┐
App B ─┼──→ libfoo.dylib
App C ─┘

여러 프로그램이 하나의 라이브러리를 사용할 수 있습니다.

그래서 디스크 공간을 절약할 수 있고, 조건이 맞으면 라이브러리의 코드 페이지를 여러 프로세스가 메모리에서 공유할 수도 있습니다.

또한 라이브러리를 앱과 분리하여 관리할 수 있습니다.


8. 동적 라이브러리의 단점

가장 대표적인 문제는 런타임 의존성입니다.

dyld: Library not loaded: ...

프로그램을 실행했는데 dylib가 없거나 버전·ABI가 호환되지 않으면 실행 자체가 실패할 수 있습니다.


9. macOS의 @rpath는 왜 자주 등장할까?

@rpath/libfoo.dylib

@loader_path
@executable_path

이것들은 dyld가 동적 라이브러리의 실제 위치를 찾는 데 사용합니다.

MyApp.app
├── Contents
│   ├── MacOS
│   │   └── MyApp
│   └── Frameworks
│       └── libfoo.dylib

실행 파일에는 라이브러리 경로가 @rpath/libfoo.dylib처럼 기록될 수 있습니다.


10. 그렇다면 macOS Framework란?

.framework는 동적 라이브러리의 다른 이름일까?

그렇지 않습니다.

Framework는 본질적으로 Bundle, 즉 정해진 디렉터리 구조를 가진 패키지입니다.

라이브러리 바이너리 + 헤더 + 리소스 + 메타데이터 등을 하나의 디렉터리에 패키징한 형태
MyFramework.framework/
├── MyFramework
├── Headers/
│   ├── MyFramework.h
│   └── Crypto.h
├── Modules/
│   └── module.modulemap
├── Resources/
│   └── Info.plist
└── Versions/

11. Framework 안의 MyFramework는 무엇인가?

Framework 디렉터리 안의 MyFramework가 실제 실행 코드가 들어 있는 Mach-O 바이너리입니다.

Framework
   │
   ├─ Dynamic Framework
   │
   └─ Static Framework

그래서 .framework = dynamic library라고 이해하면 정확하지 않습니다.

Framework는 패키징 형식, Static/Dynamic은 링크 방식에 대한 개념입니다.


12. .dylib와 Framework의 차이

동적 Framework를 예로 들면 실제 코드의 동작 방식은 .dylib와 상당히 비슷합니다.

하지만 Framework는 관련된 파일까지 함께 묶을 수 있다는 차이가 있습니다.

/usr/local/lib/libcrypto.dylib
/usr/local/include/crypto.h
/usr/local/share/crypto/...
Crypto.framework/
├── Crypto
├── Headers/
├── Modules/
├── Resources/
└── Info.plist

13. Framework가 제공하는 가장 큰 장점

Framework의 가장 큰 장점은 라이브러리에 필요한 구성요소를 하나의 논리적인 단위로 묶을 수 있다는 것입니다.

┌───────────────────────┐
│ MyFramework.framework │
│                       │
│ Binary                │
│ Headers               │
│ Resources             │
│ Modules               │
│ Metadata              │
└───────────────────────┘

14. 세 가지를 구조로 비교하면

정적 라이브러리

libfoo.a
    │
    │ Build
    ▼

┌─────────────────┐
│ Application     │
│                 │
│ App Code        │
│ +               │
│ Library Code    │
└─────────────────┘

동적 라이브러리

┌─────────────────┐
│ Application     │
└────────┬────────┘
         │ Runtime
         ▼
┌─────────────────┐
│ libfoo.dylib    │
└─────────────────┘

Dynamic Framework

Application
     │ Runtime
     ▼
Foo.framework
│
├── Foo            ← Dynamic Mach-O binary
├── Headers
├── Modules
├── Resources
└── Info.plist

15. Static Framework는 어떻게 동작할까?

Foo.framework
       │ Build
       ▼

Application Binary
 ├─ App Code
 └─ Foo Code

.framework는 포장 방식이고, Static / Dynamic은 링크 방식입니다.


16. 핵심 개념을 두 축으로 생각하면 쉽다

질문 1. 코드를 어떻게 링크하는가?

Static
vs
Dynamic

질문 2. 라이브러리를 어떻게 패키징하는가?

.a
.dylib
.framework
                    Packaging
                        │
       ┌────────────────┴───────────────┐
       │                                │
     Library                         Framework
       │                                │
  ┌────┴────┐                      ┌────┴────┐
Static    Dynamic                Static    Dynamic
 .a        .dylib              Framework Framework

17. 각각 언제 사용하는 것이 좋을까?

정적 라이브러리는 다음 상황에서 유리합니다.

  • 외부 파일 의존성을 최소화하고 싶을 때
  • 배포 구조를 단순하게 만들고 싶을 때
  • 라이브러리 버전을 애플리케이션과 완전히 고정하고 싶을 때
  • 작은 라이브러리이고 여러 프로세스에서 공유할 필요가 없을 때

동적 라이브러리는 다음과 같은 경우에 적합합니다.

  • 여러 프로그램이 동일한 라이브러리를 공유할 때
  • 실행 파일 크기를 줄이고 싶을 때
  • 라이브러리를 독립적으로 관리할 필요가 있을 때
  • 플러그인이나 런타임 로딩 구조가 필요한 경우

Framework는 특히 Apple 플랫폼에서 다음과 같은 경우 유용합니다.

  • 라이브러리 코드와 헤더를 함께 배포해야 할 때
  • 이미지, 설정 파일 등 리소스가 필요한 라이브러리일 때
  • Swift/Objective-C 모듈 형태로 제공할 때
  • Apple 플랫폼의 Bundle 및 코드 서명 체계와 통합해야 할 때

18. 장단점을 한 번에 비교하면

항목 Static Library Dynamic Library Framework
대표 형태.a.dylib.framework
본질정적 코드 묶음동적 공유 라이브러리Apple Bundle
코드 포함 시점빌드 시실행 시 로드Static/Dynamic에 따라 다름
실행 파일 크기커질 수 있음상대적으로 작음타입에 따라 다름
별도 파일 의존성적음있음Dynamic이면 있음
메모리 코드 공유어려움가능Dynamic이면 가능
라이브러리 단독 업데이트어려움가능Dynamic이면 가능
배포 편의성높음경로 관리 필요Apple 환경에서 높음
Header 포함일반적으로 별도일반적으로 별도가능
Resource 포함일반적으로 별도일반적으로 별도가능
macOS Bundle 지원XXO

19. macOS에서 실제 파일을 확인하는 방법

어떤 파일이 정적인지 동적인지 헷갈린다면 macOS의 file 명령어를 사용할 수 있습니다.

file MyFramework.framework/MyFramework

또 실행 파일이 어떤 동적 라이브러리에 의존하는지 보고 싶다면:

otool -L MyApp
MyApp:
    @rpath/MyFramework.framework/Versions/A/MyFramework
    /usr/lib/libSystem.B.dylib

처럼 나온다면 MyApp이 해당 Framework를 동적으로 참조하고 있다는 것을 알 수 있습니다.


20. 마지막으로 가장 중요한 구분

Static Library
Dynamic Library
Framework

사실은 세 가지가 같은 레벨의 개념이 아닙니다.

Static과 Dynamic은 “코드를 어떻게 링크할 것인가”의 차이입니다.

Static
→ Build Time에 코드 포함

Dynamic
→ Runtime에 별도 Binary 로드

반면 Framework는 “코드와 관련 자료를 어떻게 묶어서 배포할 것인가”에 대한 Apple의 Bundle 형식입니다.

                 Library / Module

          ┌────────────┴────────────┐
          │                         │
      Link 방식                 Packaging 방식
          │                         │
    ┌─────┴─────┐            ┌──────┴──────┐
    │           │            │             │
 Static      Dynamic      .a/.dylib    Framework
한 문장으로 정리하면:
정적 라이브러리는 코드를 애플리케이션 안에 넣고, 동적 라이브러리는 실행 시 외부 코드를 불러오며, macOS Framework는 라이브러리 바이너리와 헤더·리소스·메타데이터 등을 하나의 Bundle로 묶기 위한 패키징 구조입니다.

'공부' 카테고리의 다른 글

git: 공유 repository 서브트리(subtree)  (0) 2026.07.15
Gemini 3.1 Flash TTS와 VoxCPM2  (0) 2026.04.16
Git 3.0의 SHA-256 전환, 정말 필요한가?
GIT · SECURITY · TECH REVIEW

Git 3.0의 SHA-256 전환,
정말 필요한 변화일까?

Git 3.0에서는 새로운 저장소의 기본 객체 해시를 SHA-1에서 SHA-256으로 변경하는 방향이 추진되고 있습니다. 하지만 Git 생태계 전체를 바꾸면서까지 얻을 수 있는 실질적인 보안 효과가 충분한지를 두고 반론도 나오고 있습니다.

1 이 글이 던지는 질문
원문의 핵심 질문은 간단합니다. “SHA-1에 보안상 약점이 있다는 이유만으로 Git의 객체 주소 체계 전체를 SHA-256으로 바꾸는 것이 과연 최선의 해결책인가?” 라는 것입니다.
SECURITY

SHA-1에는 약점이 있다

의도적으로 같은 해시를 갖는 두 데이터를 만들어 내는 Collision Attack 연구가 실제로 존재합니다.

REAL WORLD

하지만 현실적인 공격인가?

글쓴이는 실제 소프트웨어 공급망 공격에서는 계정 탈취나 패키지 관리자의 권한 탈취가 훨씬 쉬운 공격 경로라고 주장합니다.

MIGRATION

전환 비용은 매우 크다

저장소, 커밋 ID, 링크, 서명, 서브모듈, 각종 라이브러리와 개발 도구가 영향을 받을 수 있습니다.

2 Git은 왜 SHA-1을 사용하는가?

Git은 Content-Addressable Storage 구조를 사용합니다.

Git은 파일의 이름만으로 데이터를 관리하지 않습니다. 파일이나 커밋의 내용을 해시한 결과를 해당 객체를 찾기 위한 ID처럼 사용합니다.

파일 내용 ↓ SHA-1 계산 ↓ Object ID ↓ Git Object Database에서 데이터 식별

커밋도 서로 해시로 연결됩니다.

각 커밋에는 이전 커밋의 정보가 포함되기 때문에 과거 객체가 변경되면 뒤에 이어지는 커밋들의 해시값도 연쇄적으로 달라집니다.

Commit A ↓ Commit B ↓ Commit C A 변경 → A의 Hash 변경 → B 변경 → C 변경
3 그렇다면 SHA-1은 왜 문제가 되었을까?
SHA-1이 흔히 “깨졌다(Broken)”고 표현되는 이유는 아무 해시에서 원본을 쉽게 복원할 수 있기 때문이 아니라, 공격자가 특수하게 설계한 서로 다른 데이터에 대해 같은 SHA-1 값을 만들어 내는 Collision Attack이 가능하다는 연구 결과가 나왔기 때문입니다.
4 Collision과 Second-Preimage는 다르다
COLLISION ATTACK

두 파일을 처음부터 함께 설계

공격자가 정상 파일과 악성 파일을 미리 준비하고, 서로 다른 두 파일이 동일한 해시값을 갖도록 만드는 공격입니다.

정상 파일 A ─┐ ├─ 동일 HASH 악성 파일 B ─┘
SECOND-PREIMAGE

이미 존재하는 파일의 해시에 맞춤

기존의 정상 파일을 본 뒤, 그것과 정확히 동일한 해시를 갖는 새로운 악성 파일을 만드는 공격입니다.

기존 정상 파일 HASH = ABC123 ↓ 공격자가 새 파일 제작 악성 파일 HASH = ABC123
원문에서는 Second-Preimage 공격이 훨씬 위협적인 형태지만, SHA-1에 대해 이런 공격을 현실적인 비용으로 수행할 수 있는 상황은 알려져 있지 않다는 점을 강조합니다.
5 글쓴이가 보는 실제 보안 문제
01

GitHub·패키지 저장소 계정 탈취

관리자의 계정을 탈취할 수 있다면 복잡한 해시 충돌을 만들 필요 없이 정상적인 저장소에 악성 코드를 직접 올릴 수 있습니다.

02

오픈소스 프로젝트 관리자 공격

널리 사용되는 프로젝트의 관리자 권한을 얻거나 사회공학을 통해 프로젝트를 넘겨받는 것이 해시 충돌 공격보다 훨씬 간단할 수 있습니다.

03

소프트웨어 공급망 공격

이미 신뢰받는 패키지나 의존성에 악성 코드를 삽입하면 해당 패키지를 사용하는 수많은 시스템으로 악성 코드가 자연스럽게 전파될 수 있습니다.

6 “Git에서 신뢰의 기준은 어디인가?”
원문에서 가장 중요한 주장은 Git의 Hash는 데이터 무결성을 제공하지만, 우리가 코드를 신뢰하는 근본적인 이유 자체는 아니라는 것 입니다.

중요한 질문은 “이 파일의 SHA-1이 무엇인가?”보다 “이 코드를 어디에서 가져왔는가?”에 가깝다는 것입니다.

원문의 Linus Torvalds 인용과 글쓴이의 논지를 쉽게 풀어쓴 표현
우리가 코드를 신뢰하는 과정 공식 GitHub Repository ↓ Repository 관리자 계정 ↓ Authentication / Access Control ↓ Commit / Release ↓ 사용자가 코드 다운로드 Hash는 이 과정의 무결성을 보조하지만 신뢰의 유일한 근거는 아니다.
7 Git 3.0에서는 무엇이 달라질까?
원문이 설명하는 Git 3.0의 핵심 변화는 새로운 저장소의 기본 Object Hash Algorithm을 SHA-1에서 SHA-256으로 전환하는 것입니다.
현재 SHA-1 160 bit 40자리 Hex Hash Git 3.0의 새로운 기본 SHA-256 256 bit 64자리 Hex Hash
8 왜 전환 비용이 크다고 보는가?
영향 영역 원문에서 제기하는 문제
Repository 호환 SHA-1 저장소와 SHA-256 저장소가 서로 다른 Object Format을 사용하게 됩니다.
Commit ID 해시 알고리즘이 바뀌면 동일한 내용이라도 기존 Commit Hash가 그대로 유지되지 않습니다.
기존 링크 이메일, Slack, 문서 등에 남아 있는 SHA-1 Commit URL을 처리하기 위한 호환 문제가 발생할 수 있습니다.
서명 기존 SHA-1 Object ID를 기준으로 만들어진 서명의 마이그레이션 문제가 발생할 수 있습니다.
Submodule 서로 다른 Hash Format의 저장소를 함께 사용하는 과정에서 추가적인 호환 처리가 필요할 수 있습니다.
개발 도구 Git Hash는 40자리라고 가정한 스크립트나 내부 시스템을 수정해야 할 수 있습니다.
Git Libraries Git 자체와 달리 서드파티 Git 구현체와 라이브러리는 SHA-256 지원 수준이 서로 다를 수 있습니다.
9 글쓴이가 제안하는 다른 방법

Object ID와 보안 검증 Hash의 역할을 분리하자

글쓴이는 SHA-1을 Git 객체를 찾기 위한 주소로 계속 사용하되, 실제로 신뢰가 필요한 Commit이나 Tag에는 SHA-256 등으로 계산한 별도의 Tree Hash를 추가하고 그것까지 전자서명하는 방식을 제안합니다.

SHA-1 기존 Git Object ID
객체를 찾기 위한 주소
+
SHA-256 별도의 Content Hash
실제 내용 무결성 검증
10 이 방법의 논리는 무엇일까?

예를 들어 중요한 Release Tag를 서명할 때 기존 SHA-1 정보와 별도로 전체 Tree의 SHA-256 값을 함께 기록한다고 생각할 수 있습니다.

Git Object ID SHA-1 + Tree Content Hash SHA-256 + Digital Signature ↓ 중요한 Release의 내용 검증
이런 구조라면 Git의 기존 Object ID 체계를 유지하면서도, 중요한 콘텐츠에 대해서는 SHA-1과 별개의 강한 무결성 검증 수단을 추가할 수 있다는 것이 글쓴이의 주장입니다.
11 이 글을 읽을 때 주의할 점

이 글은 Git 프로젝트의 공식 결론이 아닙니다.

SHA-1에 Collision 관련 보안 문제가 존재한다는 사실과, SHA-256 전환이 필요한지에 대한 정책적·공학적 판단은 구분할 필요가 있습니다. 원문은 SHA-1의 약점을 부정하기보다는 “그 위험을 줄이기 위해 Git 생태계 전체를 SHA-256 Object Format으로 전환하는 것이 비용 대비 가장 좋은 방법인가?”라는 반론을 제시하는 글입니다.

한 줄로 정리하면

이 글의 핵심은 “SHA-1은 완벽하게 안전하다”가 아닙니다. 오히려 “Git 객체를 찾기 위한 Hash와 코드를 신뢰하기 위한 보안 수단을 굳이 하나로 묶어야 하는가?” 라는 질문에 가깝습니다.

Git 3.0의 SHA-256 전환은 보안을 강화하려는 방향이지만, 원문의 글쓴이는 그 과정에서 발생할 수 있는 저장소 호환성, Commit ID 변경, 기존 링크, 서명, Submodule, 라이브러리 및 개발 도구의 광범위한 변경 비용을 지적합니다.

그래서 Git 전체를 SHA-256으로 바꾸는 대신 SHA-1은 Content Address로 유지하고, 중요한 콘텐츠에는 SHA-256 등의 독립적인 검증 Hash와 전자서명을 추가하자 는 것이 이 글의 대안입니다.

Mercury Voice와 Diffusion LLM 정리
AI MODEL · VOICE AGENT

Mercury Voice
빠른 음성 AI를 위한 Diffusion LLM

Mercury Voice는 복잡한 추론과 도구 호출을 수행하면서도 사람과 자연스럽게 대화할 수 있을 정도로 낮은 응답 지연시간을 목표로 한 음성 에이전트용 확산 언어모델입니다.

1 Mercury Voice는 무엇인가?
기존 음성 AI는 보통 빠르면 단순하고, 복잡하게 추론하면 느려지는 문제가 있습니다. Mercury Voice는 이 두 가지를 동시에 해결해 “빠르게 반응하면서도 추론할 수 있는 음성 AI”를 목표로 합니다.
FAST

빠른 첫 응답

사용자가 말을 끝낸 뒤 첫 답변을 내기까지의 시간을 매우 짧게 유지하는 데 초점을 맞춥니다.

REASONING

추론 가능

단순 문답을 넘어 복잡한 조건 판단이나 여러 단계의 업무 처리를 수행할 수 있습니다.

AGENT

도구 호출

예약 시스템, CRM, 결제 시스템 등 외부 서비스와 연결해 실제 업무를 수행할 수 있습니다.

2 Diffusion LLM(dLLM)이란?

기존 Autoregressive LLM

GPT 계열에서 널리 사용하는 방식으로, 앞에서 생성한 토큰을 바탕으로 다음 토큰을 하나씩 생성합니다.

저는 ↓ 오늘 ↓ 서울에 ↓ 갑니다
→

Diffusion LLM

처음부터 완성된 문장을 한 토큰씩 만드는 대신, 불완전한 토큰 집합을 여러 단계에 걸쳐 동시에 수정하며 최종 문장을 만들어 갑니다.

[불완전한 답변] ↓ 여러 토큰 동시 수정 ↓ 문맥과 표현 정제 ↓ 최종 답변
3 확산 모델이 왜 빠를 수 있을까?
01

토큰을 반드시 하나씩 만들 필요가 없음

Autoregressive 모델은 다음 토큰을 생성하기 전에 이전 토큰 생성이 끝나야 합니다. 반면 dLLM은 여러 위치를 동시에 수정할 수 있어 더 많은 연산을 병렬화할 수 있습니다.

02

GPU 병렬 처리와 잘 맞는 구조

GPU는 여러 연산을 동시에 수행할 때 효율적입니다. 여러 토큰을 병렬적으로 업데이트하는 구조는 이런 GPU의 특성을 활용하기 좋습니다.

03

긴 프롬프트에서도 낮은 지연시간을 목표

음성 에이전트에는 업무 규칙, API 호출 방법, 고객 대응 정책 등 긴 시스템 프롬프트가 들어갈 수 있습니다. Mercury Voice는 이런 환경에서도 낮은 응답 지연을 목표로 설계됐습니다.

4 음성 서비스에서는 왜 속도가 중요한가?
사람이 전화로 대화할 때 상대방이 말을 끝낸 뒤 AI가 오랫동안 아무 말도 하지 않으면 대화 흐름이 깨집니다. 그래서 음성 AI에서는 전체 처리량보다 “언제 첫 말을 시작하는가”가 매우 중요합니다.
320ms Mercury Voice 중앙값 TTFAT
750ms p95 TTFAT
500ms 자연스러운 대화의 목표 기준
5 TTFAT와 p95는 무엇인가?
T

TTFAT · Time To First Answer Token

사용자가 말을 끝낸 뒤 AI가 추론을 마치고 실제로 들려줄 첫 단어를 생성하기까지 걸리는 시간입니다. 짧을수록 대화가 자연스럽게 느껴집니다.

95

p95 · 95번째 백분위수

요청의 약 95%가 해당 시간 안에 처리된다는 뜻입니다. 평균 속도가 빨라도 일부 요청에서 수초씩 지연된다면 전화 서비스 품질은 크게 떨어질 수 있습니다.

6 어디에 활용될 수 있나?
분야 활용 예시
드라이브스루 주문 변경, 메뉴 확인, 할인 적용, 추가 메뉴 추천 등을 실시간으로 처리
금융 상담 결제 계획 협상, 고객 이의 처리, 내부 정책 확인 및 관련 시스템 호출
콜센터 고객 문의를 이해하고 CRM·예약·주문 시스템과 연동해 실제 업무까지 수행
예약 서비스 항공편·호텔·병원 예약 조회, 일정 변경 및 조건 확인
7 주요 사양과 가격
항목 내용
모델 구조 Diffusion LLM
컨텍스트 128K tokens
최대 출력 최대 50K tokens
추론 강도 Low / Medium / High
정가 입력 $0.40 / 100만 토큰
출력 $1.50 / 100만 토큰
출시 할인가 입력 $0.20 / 100만 토큰
출력 $0.75 / 100만 토큰
API OpenAI API 호환 엔드포인트 지원
8 OpenAI API 호환이 중요한 이유
기존 서비스가 OpenAI API 형태로 구축돼 있다면, 시스템 전체를 새로 만들기보다 API 주소와 모델 설정을 변경하는 방식으로 비교적 쉽게 Mercury Voice를 연결할 수 있습니다. LiveKit, Pipecat, Vapi, Retell 등의 음성 AI 프레임워크와도 연동할 수 있습니다.
9 벤치마크를 볼 때 주의할 점

숫자는 회사가 공개한 자체 테스트 결과입니다.

  • 320ms, 5.9배 빠르다는 등의 수치는 인셉션이 수행한 특정 테스트 환경에서 나온 결과입니다.
  • 모든 서비스 환경에서 동일한 성능이 나온다는 의미는 아닙니다.
  • 실제 음성 AI 서비스의 지연시간에는 STT, 네트워크, 데이터베이스, Tool API, TTS 등의 시간이 추가됩니다.
  • 따라서 모델 TTFAT가 320ms라고 해서 전체 전화 시스템 응답 시간이 반드시 320ms라는 뜻은 아닙니다.

한 줄로 정리하면

Mercury Voice의 핵심은 단순히 “빠른 음성 AI”가 아니라, 기존의 순차적인 Autoregressive 생성 방식 대신 여러 토큰을 병렬적으로 정제하는 Diffusion LLM 구조를 활용해 추론 능력과 낮은 지연시간을 동시에 확보하려는 시도 라는 점입니다.

독자 AI 파운데이션 모델 개편 논의 정리
AI POLICY · ISSUE BRIEF

독자 AI 파운데이션 모델,
중단이 아니라 ‘개편·확장’ 논의

정부가 기존 독자 AI 파운데이션 모델 프로젝트를 중단하고 대규모 특수목적법인(SPC)을 설립한다는 보도가 나왔지만, 과학기술정보통신부는 중단이나 SPC 설립 모두 아직 확정되지 않았다고 설명했습니다. 핵심은 국내 AI 개발 역량을 어떻게 효과적으로 결집할 것인지에 있습니다.

1 무슨 일이 있었나?
핵심부터 보면, 독파모 중단과 SPC 설립은 확정된 정책이 아닙니다.
과기정통부는 최상위급 AI 모델 개발을 위해 재원을 집중할 필요성에는 공감하지만, 기존 프로젝트 중단이나 SPC 설립 여부는 아직 결정되지 않았다고 밝혔습니다.
01 · 보도

“독파모 중단·SPC 설립” 보도

일부 언론에서 기존 독자 AI 파운데이션 모델 사업을 중단하고 대규모 SPC를 통해 프런티어급 AI 개발로 전환한다는 내용이 보도됐습니다.

02 · 정부 설명

“아직 정해진 바 없다”

과기정통부는 프로젝트 중단과 SPC 설립 모두 확정된 사항이 아니라고 설명했습니다.

03 · 현재 방향

통합·개편·확장 검토

기존 사업을 백지화한다기보다는, 최상위급 AI 개발에 필요한 자원을 집중할 수 있도록 기존 구조를 개편·확장하는 방향이 논의되고 있습니다.

2 왜 개편 이야기가 나오는가?
현재 구조

여러 개발팀이 경쟁하는 구조

  • 복수의 국내 기업·연구팀이 각각 모델 개발
  • 정부가 GPU·데이터 등 개발 자원 지원
  • 단계 평가와 경쟁을 통해 정예팀 선별
  • 각 팀의 기술적 독자성과 경쟁 촉진
→
개편 논의

국가적 AI 역량을 더 크게 결집

  • 최상위급 모델 개발에 충분한 연산자원 확보
  • 정부·기업·연구기관 간 협력 확대
  • GPU뿐 아니라 데이터와 인재도 함께 확보
  • 글로벌 최상위 모델과의 기술 격차 축소
3 전문가가 지적한 핵심 문제
A

AI 개발 역량의 분산

최병호 고려대 AI연구소 교수는 국가 단위의 AI 개발에서 기업 간 경쟁 방식만을 적용하는 데 한계가 있으며, 프런티어급 모델을 위해 역량을 결집할 필요가 있다고 평가했습니다.

B

GPU만 확보해서는 부족

대규모 AI 모델 개발에는 연산 자원뿐 아니라 고품질 학습 데이터를 확보·정제·생산하는 체계적인 데이터 인프라가 함께 필요합니다.

C

핵심 AI 연구 인재 확보

연구자를 국내에 유지하고 산업계와 연구 현장에서 충분한 보상을 제공하기 위한 제도적 지원도 중요한 과제로 제시됐습니다.

4 기존 독파모와 개편 논의의 차이
구분 기존 독자 AI 파운데이션 모델 현재 거론되는 개편 방향
개발 구조 여러 정예팀이 각각 독자 모델을 개발하고 단계별 평가를 받는 경쟁형 구조 국가 차원의 인프라·자본·연구 역량을 보다 집중적으로 활용하는 방안 검토
핵심 목표 글로벌 수준의 국내 독자 AI 파운데이션 모델 확보 글로벌 최상위권의 프런티어급 AI 개발 역량 확보
연산 자원 참여 기업과 연구팀에 GPU 등 개발 자원을 지원 더욱 대규모의 연산자원을 집중적으로 투입하는 방향이 논의됨
데이터 모델 개발을 위한 고품질 공동활용 데이터 지원 지속적인 데이터 확보·정제·생산을 위한 데이터 팩토리 수준의 체계 필요성 제기
인재 기업·연구기관별 연구 인력 중심 핵심 연구자 확보와 유지, 보상 및 제도 개선의 중요성이 강조됨
SPC 현재 프로젝트의 기본 구조는 아님 하나의 방안으로 보도됐지만 정부는 설립 여부가 확정되지 않았다고 설명
5 기사에서 구분해서 봐야 할 부분

FACT CHECK

  • “독파모가 중단된다” → 확정 아님. 과기정통부는 중단이 아니라 개편·확장 차원의 논의라고 설명했습니다.
  • “5조원 규모 SPC가 만들어진다” → 확정 아님. SPC 설립 여부 자체가 아직 정해지지 않았습니다.
  • “프런티어 AI는 반드시 1조 파라미터 이상이다” → 정부 공식 기준 아님. 기사에 등장한 전문가가 제시한 기술적 견해로 보는 것이 정확합니다.
  • 핵심 논점은 모델 크기만이 아닙니다. 연산 자원, 데이터, 인재 및 대규모 AI 시스템 운영 역량을 함께 확보하는 것이 중요하다는 지적입니다.

한 줄로 정리하면

이번 논의는 “독파모를 폐기하고 새로운 사업을 시작한다” 기보다는, 기존 독자 AI 개발 사업을 바탕으로 국내의 GPU·데이터·인재·자본을 얼마나 더 효과적으로 결집해 최상위급 AI 개발로 확장할 것인가 에 관한 논의에 가깝습니다.

※ 정리 기준: AI타임스 기사 및 과학기술정보통신부의 공개된 사업 방향

 

Product & Web Tools

설치·가입 없이 브라우저에서 끝내는 무료 유틸리티 모음, 'UtilPick'

일상 업무나 개발 작업 중 자주 찾는 자잘한 도구 100개를 브라우저 탭 하나에 모아둔 유용한 웹 서비스, UtilPick(유틸픽)을 소개합니다.

 

1

UtilPick의 3대 핵심 특징

🔒
100% 로컬 브라우저 처리
입력 텍스트나 업로드 파일이 외부 서버로 전송되지 않고 사용자 브라우저 내부에서만 연산되어 개인정보 유출 걱정이 없습니다.
⚡
무설치 & 무가입
별도의 프로그램 다운로드나 회원가입 로그인 절차 없이, 웹사이트에 접속하자마자 즉시 원하는 기능을 사용할 수 있습니다.
🖥️
올인원 단일 화면
이곳저곳 검색하며 웹사이트를 찾아 헤맬 필요 없이, 한 화면에서 100가지 유틸리티를 한 번에 전환하며 처리할 수 있습니다.
🛡️ 개인정보 및 보안 안심: "서버로 데이터를 전송하지 않는다"는 점 덕분에 문서 변환이나 코드 포맷팅 등 민감할 수 있는 텍스트 작업도 부담 없이 안전하게 다룰 수 있습니다.
2

9개 분야, 총 100개 유틸리티 구성 현황

각 카테고리별로 실무와 일상에서 손이 많이 가는 도구들이 체계적으로 분류되어 있습니다.

📝 텍스트 6
🖼️ 이미지 20
📄 PDF · 문서 14
🎬 영상 · 오디오 6
💻 개발자 도구 13
💰 금융 · 계산기 17
⏱️ 시간 · 생산성 8
🖥️ 기기 테스트 7
🧩 생활 · 기타 9
3

대표적으로 자주 쓰이는 도구들

평소 북마크에 분산되어 있던 필수 기능들이 빠짐없이 탑재되어 있습니다.

글자수 세기 이미지 압축 PDF 합치기 · 나누기 · 비교 QR 코드 생성 JSON 포맷터 정규식(RegEx) 테스트 자막 편집 퇴직금 · 부가세 계산기 모니터 불량화소 테스트

 

AI Architecture & Context Optimization

코딩 에이전트의 망각 방지 기술 'fast-jev-compaction'과 초고속 결정 모델 'System One (Jev)' 분석

Part 1. fast-jev-compaction: 요약하지 않고 로그만 지우는 에이전트 압축 기술

1

배경: "요약(Summary)"이 유발하는 코딩 에이전트의 치명적 망각

Claude Code 등 코딩 에이전트는 컨텍스트 창이 가득 차면 오래된 대화를 LLM으로 요약해 용량을 확보합니다. 하지만 요약은 필연적으로 정보의 손실을 동반합니다.

  • 발생하는 부작용: 정확한 오류 로그, 파일의 절대 경로, 실행 명령어, 사용자의 "이 파일은 절대 건드리지 마" 같은 중요 제약 조건이 요약 과정에서 통째로 소실될 수 있습니다.
  • 그 결과 에이전트가 이미 읽었던 파일을 다시 읽거나 금지된 경로를 수정하는 등 오작동을 일으킵니다.
2

해결책: 요약하지 않고, "불필요한 도구 호출 기록만 선별 삭제"

fast-jev-compaction은 대화 텍스트를 재작성하지 않고, 원문은 그대로 둔 채 다시 볼 필요가 없는 오래된 도구 실행(Tool Use)과 방대한 결과(Tool Result)만 핀셋으로 골라 삭제합니다.

  • 지시/대화 텍스트: 사용자와 주고받은 내용은 100% 원문 그대로, 순서 그대로 보존됩니다.
  • 삭제 대상을 고르는 기준 (Jev 모델 활용):
    • TypeSafe AI의 Jev(문장 생성 대신 확률을 계산하는 가벼운 System One 모델)를 활용합니다.
    • 전체 문맥을 바탕으로 호출 단위마다 다음 2가지 질문을 던집니다:
      1. 이 도구 호출 이력이 앞으로의 작업에 여전히 중요한가?
      2. 그 결과(로그, 파일 내용 등)가 원본 그대로 유지되어야 하는가? (다시 실행하는 것으로 대체할 수 없는가?)
  • 판정에 따른 3단계 처리:
    1. 둘 다 중요함: 호출과 결과 모두 유지
    2. 호출 사실만 중요함: 호출은 남기고 결과는 앞 300자만 남긴 뒤 잘라냄 (필요 시 재실행 안내 문구 첨부)
    3. 둘 다 중요하지 않음: 호출과 결과 모두 삭제
3

기존 Claude Code 기본 압축과의 비교

구분 Claude Code 기본 압축 fast-jev-compaction
처리 방식 오래된 대화 전체를 LLM이 요약문으로 재작성 대화는 그대로 두고 불필요한 도구 로그만 골라 삭제
대화 원문 보존 요약문 속에 흡수되어 사라짐 손대지 않고 100% 유지
판단 주체 일반 LLM 가벼운 결정 모델인 Jev의 확률 연산
안전장치 (Fallback) 없음 Jev 호출 실패나 압축률 미달(25% 미만) 시 기본 요약 방식으로 자동 복귀
4

누구에게 가장 효과적인가?

  • 적합한 작업: 대규모 코드베이스 탐색, 테스트/빌드 로그를 수십 번 반복 확인하는 도구 호출 중심의 장시간 코딩 세션 (대화 용량의 대부분이 도구 결과물이므로 극적인 용량 확보 가능).
  • 비추천 / 한계점:
    • 일반적인 텍스트 잡담 및 아이디어 회의 중심 세션 (도구 호출이 없어 줄일 데이터가 부재).
    • 대화 전체 내용이 외부(TypeSafe 엔드포인트)로 전송되면 안 되는 엄격한 보안·폐쇄망 환경.

Part 2. System One (Jev): 초고속 결정 모델 아키텍처

1

Jev는 무엇인가요?

"글(문자열)을 써내는 대신, 프로그램이 즉시 사용할 수 있는 '타입이 정해진 결정과 확률'만을 초고속·초저비용으로 계산해 내는 함수형 인공지능 모델"

 

기존 LLM이 "말을 잘하는 만능 작가"라면, Jev는 복잡한 소프트웨어 파이프라인 안에서 "예/아니오, 점수 매기기, 선택지 고르기"만을 번개처럼 수행하는 초경량 판정기입니다.

2

왜 기존 LLM 대신 새로운 모델이 필요한가요?

소프트웨어 시스템 안에서 자동으로 결정을 내릴 때 기존 생성형 LLM을 사용하면 다음 한계에 부딪힙니다.

  1. 지연 시간과 낭비: 단어를 하나씩 순차적으로 생성(Auto-regressive)하므로 응답에 수 초~수십 초 소요.
  2. 억지 구조화의 한계: JSON 스키마를 강제해도 출력 포맷이 깨지거나 환각(Hallucination)이 완전히 사라지지 않음.
  3. 새로운 사후 학습 패러다임: RLCD (보정된 결정을 위한 강화학습)
    • RLHF: 사람이 선호하는 챗봇 응답 생성 훈련.
    • RLVR: 정답이 명확한 수학/코딩 추론 훈련.
    • RLCD: 텍스트 생성을 포기하고, "높은 확률을 준 결정이 실제로도 높은 정답률을 갖도록(확률 보정)" 훈련하여 자동화 신뢰도 극대화.
3

기존 LLM vs System One (Jev) 비교

비교 항목 기존 생성형 LLM (ChatGPT 등) System One (Jev)
출력 형태 긴 텍스트 문자열 (JSON 파싱 필요) 타입이 정해진 구조화된 값 + 보정된 확률
샘플링 방식 단어를 하나씩 이어붙이는 순차적 생성 여러 질문을 한 번에 쏘는 병렬 처리
응답 속도 3초 ~ 수십 초 70밀리초 ~ 500밀리초 (0.07~0.5초)
비용 (입력/출력) 100만 토큰당 수 달러 / 출력 비용 비쌈 100만 토큰당 $0.042 (200배 이상 저렴) / 출력 비용 사실상 무료
환각(오류) 위험 스키마 불일치 및 거짓 정보 발생 가능 구조적으로 스키마 이탈 및 환각 불가 (0%)
4

Jev가 제공하는 3가지 기본 질문 요소 (Primitives)

소프트웨어의 원시 자료형(Boolean, Int 등)처럼, Jev는 3가지 기본 연산 질문만 받습니다. 병렬 처리를 통해 한 번에 수십 개를 동시에 던져도 즉시 처리됩니다.

Choice
주어진 목록 중 가장 알맞은 하나를 선택 (예: 문의 분류 = 결제 / 배송 / 환불)
Score
정해진 기준에 따라 상태를 채점 (예: 이상 거래 위험도 점수 산출)
Noul
진술이 참인지 거짓인지 판정하여 0~1 사이 확률 반환 (예: "이 로그는 침해 사고인가?")
💡 권장 설계 패턴 (원자적 질문 분할):
"이 스타트업을 종합 평가해줘"라고 한 번에 묻지 않고, 시장성(Score), 기술성(Score), 대표자 이력(Noul)을 쪼개서 병렬로 물어본 뒤, 프로그램 코드에서 가중치를 더해 합산합니다.
5

실전 활용 사례 및 실무적 의미

  • 스마트홈 / 로봇 / 실시간 게임: 초당 수십 번씩 상태를 질의해야 하는 환경(Doom 플레이 봇, 스마트홈 명령어 분류)에서 수십 밀리초 만에 결정을 내려 실시간 제어가 가능합니다.
  • LLM과의 완벽한 협업 (투기적 팬아웃):
    • 앞단에서 Jev가 0.1초 만에 요청의 종류를 분류하고 불필요한 호출을 걸러냅니다.
    • 복잡한 작문이나 긴 추론이 진짜 필요한 10~20%의 요청만 기존 무거운 LLM(Claude, GPT)으로 넘겨 시스템 전체의 속도를 높이고 API 비용을 수백 배 절감합니다.

 

Developer Tools & macOS

Homebrew 주요 업데이트: 대규모 성능 향상, 보안 내재화 및 BrewUI 출시

1

성능 최적화: 더 빨라진 설치 및 업그레이드 속도

  • 동시성(Concurrency) 확대: 패키지 준비 및 다운로드(install, reinstall, upgrade, bundle) 과정이 병렬로 실행되어 패키지 대기 시간이 획기적으로 줄어듭니다. 진단 명령어인 brew config와 brew tap-info 역시 병렬 수집 방식으로 개편되었습니다.
  • API 메타데이터 직접 활용: brew fetch 실행 시 복잡한 포뮬러 코드를 전부 파싱하지 않고, 원격 API 메타데이터에서 다운로드 위치를 즉시 조회합니다.
  • 캐시 정리 및 시작 오버헤드 단축: brew cleanup의 중복 디스크 스캔을 제거하고 서브프로세스 호출을 최소화하여 기본 명령어 응답 속도를 개선했습니다.
2

보안 강화 및 취약점 검사 기능 내장

🔍 brew vulns 기본 탑재: 서드파티 탭 없이도 OSV.dev 데이터베이스를 연동하여 현재 로컬에 설치된 패키지들의 알려진 보안 취약점을 즉시 스캔할 수 있습니다.
  • 샌드박스 및 설치 보호 강화:
    • 빌드 격리: 빌드 작업 중 사용자 홈 디렉터리 접근을 원천 차단하여 개인 데이터 혼입을 방지합니다.
    • 파이프라인 분리: 네트워크가 필요한 다운로드 단계와 네트워크가 차단된 읽기 전용 설치 단계를 명확히 분리하는 마이그레이션이 진행 중입니다.
    • Linux 보안 모듈 전환: Bubblewrap 대신 커널 내장 모듈인 Landlock 기반 샌드박스로 전환되었습니다.
  • 루비 임의 코드 실행 축소 (*_steps 도입):
    • 패키지 정의에서 자유로운 루비 스크립트를 수행하던 post_install 및 Cask의 *flight 훅이 폐기(Deprecated) 처리됩니다.
    • 서명 및 검증이 가능한 선언형 구조인 *_steps로 전환되며, 공식 탭은 즉각 반영되고 서드파티 탭은 2027년 12월까지 유예 기간을 가집니다.
3

macOS 및 하드웨어 지원 정책 변화

⚠️ 인텔(Intel x86_64) Mac 지원 축소 (Tier 3 강등)
인텔 Mac은 공식 사전 빌드 바이너리(Bottle) 지원이 중단되어 소스 직접 빌드가 요구될 수 있습니다. 2027년 9월 1일부로 인텔 Mac 지원이 공식 종료될 예정이며, 사용자에게는 MacPorts 등의 대안 사용을 권장합니다.
* 사유: Apple(macOS 27 인텔 지원 종료) 및 GitHub(2027 가을 인텔 러너 종료)의 인프라 지원 중단에 따른 결정
  • 최소 버전 상향: macOS Catalina(10.15) 지원이 공식 제거되어 최소 macOS Big Sur(11) 이상이 필요합니다.
  • 최신 OS 완전 지원: Apple Silicon 환경의 최신 macOS Golden Gate 27을 Tier 1 등급으로 전면 지원합니다.
4

공식 그래픽 인터페이스 'BrewUI' 출시

Official GUI App
BrewUI for macOS

CLI 환경에 익숙하지 않은 사용자나 시각적인 패키지 관리를 원하는 사용자를 위한 공식 앱이 출시되었습니다. GUI 액션을 취할 때 백그라운드에서 실행되는 실제 터미널 명령어를 함께 노출하여 CLI 학습을 자연스럽게 유도합니다.

설치 명령어: brew install homebrew-app
(요구 사양: macOS Tahoe 26 이상)
5

주요 명령어 및 Cask 편의성 개선

brew install --dry-run
실제 디스크 변경 없이 포뮬러와 캐스크의 설치 예정 항목과 의존성 트리를 미리 점검합니다.
brew info 상태 표기 개선
설치 불가능한 패키지(⊘)와 단순 미설치 패키지(✘) 상태를 아이콘으로 명확하게 구분합니다.
brew services .env 파일 지원
$HOMEBREW_USER_CONFIG_HOME/services/<formula>.env에 환경 변수를 영구 저장하여 업그레이드 후에도 구성을 유지합니다.
brew link / unlink 플래그
--cask 및 --formula 플래그를 통해 재설치 없이도 바이너리 심볼릭 링크 연결을 간편하게 온/오프할 수 있습니다.

+ Recent posts