가온 위키 - 사용자 기여 [ko]

라이믹스

2026-08-21T06:21:30Z

Gaon12: 로고 안나오던 문제 수정

{{소프트웨어 정보
| 이름 = 라이믹스
| 로고 = [[파일:rhymix.png|width=auto]]
| 설명 = 현 라이믹스의 로고
| 원작자 = [[XpressEngine|XE]] 개발팀 및 기여자
| 개발자 = (주)포에시스
| 발표일 = 2015년 12월 18일
| 최신 버전 = 2.1.36
| 최신 버전 출시일 = {{날짜/출력|2026-08-12}}
| 프로그래밍 언어 = [[PHP]]
| 종류 = 오픈소스 [[CMS]] 및 웹 프레임워크
| 라이선스 = GNU GPL v2 계열
| 웹사이트 = [https://rhymix.org rhymix.org]
| 전작 = [[XpressEngine|XpressEngine 1.x]]
}}
영어 문서는 [[Rhymix|Rhymix]] 문서를 참고할 수 있다.

{{틀:인용문|Rhyme + Remix {{틀:=}} "RHYMIX"!}}

[https://rhymix.org 라이믹스 공식 홈페이지] · [https://rhymix.org/manual 공식 매뉴얼] · [https://github.com/rhymix/rhymix GitHub 저장소] · [https://github.com/rhymix/rhymix-docs 공식 문서 저장소]

== 개요 ==
'''라이믹스'''(Rhymix)는 [[XpressEngine|XpressEngine 1.x]]를 기반으로 갈라져 나온 PHP 기반의 오픈소스 [[CMS]] 및 웹 프레임워크이다. 공식 홈페이지에서는 라이믹스를 “오픈소스 CMS 및 프레임워크”로 소개하며, 모듈과 테마를 이용하여 홈페이지, 커뮤니티, 게시판, 서비스형 웹사이트 등을 구성할 수 있다고 설명한다.<ref name="official-home">[https://rhymix.org 라이믹스 공식 홈페이지]</ref>

프로젝트는 2015년 12월 18일에 시작되었으며, 현재는 대전에 소재한 (주)포에시스(Poesis Inc.)가 개발과 유지보수를 맡고 있다.<ref name="about">[https://rhymix.org/about 라이믹스 소개]</ref>

라이믹스는 기존 XE 1.x와의 호환성을 상당 부분 유지하면서도, 보안 패치, PHP 최신 버전 대응, 성능 개선, 관리자 기능 개선, 확장성 개선 등을 꾸준히 반영하는 방향으로 개발되고 있다. 공식 GitHub 저장소의 설명에 따르면 라이믹스는 XE 기반 자료의 호환성을 최대한 유지하면서도, 더 빠르고 안전하며 사용자와 개발자가 소통하기 쉬운 CMS를 지향한다.<ref name="github-readme">[https://github.com/rhymix/rhymix rhymix/rhymix GitHub 저장소]</ref>

이름은 rhyme(운율)과 remix(재조합)를 결합한 것으로, 기존 XE 생태계를 단순히 보존하는 데 그치지 않고 필요한 부분을 다시 섞고 개선한다는 의미를 담고 있다. 공식 소개 문서는 라이믹스가 온라인에서 무언가를 만들어내는 모든 “메이커”를 지원하는 것을 목표로 하며, 설치와 운영 과정에서 대부분의 사용자가 터미널 명령을 입력할 필요가 없어야 한다는 원칙을 내세운다고 설명한다.<ref name="about" />

라이선스는 GNU GPL v2 계열이다. 라이믹스 공식 저장소와 공식 홈페이지 모두 GPLv2를 명시하고 있으며, 공식 매뉴얼에는 GPL 라이선스에 따른 사용자, 개발자, 디자이너의 권리와 의무가 별도 문서로 정리되어 있다.<ref name="license">[https://rhymix.org/manual/contrib/license GPL: 개발자, 디자이너, 사용자 등의 권리와 의무]</ref>

== 역사 ==
라이믹스는 XE 1.x의 소스 코드를 기반으로 시작된 프로젝트이다. XE가 보안 패치 중심으로 유지되는 동안, 실제 운영자와 개발자들이 필요로 하던 개선 사항을 더 적극적으로 반영하기 위해 XETOWN 커뮤니티를 중심으로 포크가 논의되었다. 프로젝트의 공식 시작일은 2015년 12월 18일이다.<ref name="about" />

초기에는 명확한 이름이 정해지지 않아 XETOWN Fork, XETOWN CMS, XETOWN Core 등으로 불렸으며, 2016년 1월 GitHub 이슈에서는 XETOWN REMIX, 줄여서 XTR이라는 이름도 논의되었다.<ref name="issue31">[https://github.com/rhymix/rhymix/issues/31 XETOWN 프로젝트에서 정리해야 될 사항들]</ref> 이후 프로젝트명은 라이믹스(Rhymix)로 정착하였다.

라이믹스라는 이름은 Rhyme과 Remix를 결합한 말로 설명된다. 기존 XE 생태계를 단순히 보존하는 데 그치지 않고, 필요한 부분을 다시 섞고 개선한다는 의미를 담고 있다.

=== 라이선스 전환 ===
라이믹스는 포크 과정에서 XE가 사용하던 LGPL v2.1 대신 GPL v2를 채택하였다. 공식 매뉴얼은 이 전환의 취지를 개발자의 권리를 일부 제한하는 대신 사용자의 권리를 보호하기 위한 것으로 설명한다.<ref name="license" />

이 선택은 두 프로젝트 사이에 단방향 관계를 만들었다. LGPL은 GPL로의 전환을 허용하므로 라이믹스는 XE의 코드를 가져올 수 있지만, 반대 방향은 성립하지 않는다. 또한 라이믹스의 확장 기능을 사용하는 모듈과 애드온은 모두 GPL이어야 하며, 판매하더라도 구매자에게 암호화하지 않은 원본 소스 코드를 제공해야 한다. 자세한 내용은 [[라이믹스/라이선스]] 문서를 참고할 수 있다.<ref name="license" />

=== 저장소 이력 ===
라이믹스는 포크 시점에 저장소 이력을 새로 시작하지 않고 XE의 커밋 기록을 그대로 이어받았다. 이 때문에 공식 저장소에는 XE 시절부터 누적된 약 21,000건의 커밋이 남아 있다. 2026년 8월 기준 저장소의 스타는 297개, 포크는 134개이다.<ref name="github-readme" />

== 특징 ==
=== XE와의 관계 ===
라이믹스는 XE 1.x를 기반으로 하지만, 단순한 보안 패치판이라기보다는 XE 1.x의 구조와 생태계를 이어받아 적극적으로 개선한 별도 프로젝트에 가깝다. 공식 저장소에서도 라이믹스가 XpressEngine의 소스 코드를 기반으로 하며, 기존 XE 서드파티 자료와의 호환성을 최대한 보장하려 한다고 설명한다.<ref name="github-readme" />

다만 라이믹스는 XE와 완전히 같은 소프트웨어가 아니다. PHP 요구 버전, 서버 환경, 관리자 설정, 보안 정책, 일부 서드파티 자료의 동작 방식에서 차이가 있다. 특히 XE에서 라이믹스로 업그레이드한 뒤에는 다시 XE로 되돌릴 수 없으므로, 이전 전에 반드시 파일과 데이터베이스를 백업해야 한다.<ref name="xe-upgrade">[https://rhymix.org/manual/introduction/xe-upgrade XE 1.x에서 업그레이드]</ref>

두 소프트웨어의 구체적인 차이는 [[라이믹스/XE와의 차이점]] 문서에 정리되어 있다.

=== 프레임워크 구조 ===
라이믹스는 CMS인 동시에 자체 프레임워크를 갖추고 있다. 공식 매뉴얼의 클래스 및 함수 명세에는 Cache, Config, Cookie, DB, DateTime, Debug, Exception, Formatter, HTTP, i18n, Image, Korea, Lang, MIME, Mail, Pagination, Password, Push, Queue, Request, Router, SMS, Security, Session, Storage, Template, Timer, UA, URL 등의 코어 클래스가 정리되어 있으며, 파일 내용·파일명·HTML·IP·미디어를 검사하는 필터 클래스도 별도로 제공된다.<ref name="manual-index">[https://rhymix.org/manual 라이믹스 매뉴얼]</ref>

이 가운데 Queue는 메일 발송이나 푸시 알림처럼 시간이 오래 걸리거나 외부 서비스와 연계되는 작업을 비동기로 처리하는 데 쓰이며, Router는 짧은주소 처리를 담당한다. 확장 기능 제작 문서에는 DB 쿼리 연산자와 라우터 사용법이 별도 항목으로 수록되어 있다.<ref name="manual-index" />

=== 템플릿 문법 v2 ===
라이믹스는 2.1.8부터 새로운 템플릿 문법인 템플릿 문법 v2를 프리뷰 형태로 제공한다.<ref name="release-218">[https://rhymix.org/news/424 Rhymix 2.1.8 Release Notes]</ref> 이 문법은 Blade 문법을 기반으로 하되 라이믹스의 구조에 맞게 여러 지시자를 추가한 것으로, Blade의 <code>@auth</code>, <code>@can</code> 같은 지시자를 라이믹스의 권한 체계에 맞게 재해석하여 게시판 관리자 여부나 댓글 작성 권한 등을 간단히 확인할 수 있다.<ref name="template-v2">[https://rhymix.org/manual/theme/template_v2 템플릿 문법 v2]</ref>

파일 확장자는 <code>.html</code>과 <code>.blade.php</code> 중에서 선택할 수 있으며, 후자를 사용하면 대부분의 편집기에서 Blade 플러그인을 통해 문법 강조와 자동 완성을 이용할 수 있다. 기존 v1 문법 가운데 검증된 요소는 그대로 유지되어 두 문법을 섞어 쓸 수도 있다.<ref name="template-v2" /> 2.1.8 릴리즈 노트는 이 문법이 프리뷰 단계이며 2.2에서 정식 지원될 예정이라고 안내하였다. 자세한 문법은 [[라이믹스/매뉴얼/템플릿 문법 v2]] 문서를 참고할 수 있다.<ref name="release-218" />

=== 활발한 업데이트 ===
라이믹스는 새 기능, 버그 수정, 보안 패치가 꾸준히 이루어지는 프로젝트이다. 공식 매뉴얼은 라이믹스를 운영하는 사이트가 자주 업데이트할 준비를 해야 한다고 안내한다.<ref name="update">[https://rhymix.org/manual/introduction/update 라이믹스 업데이트]</ref>

공식 홈페이지와 뉴스 게시판에서는 각 정식 버전의 릴리즈 노트와 변경 파일을 제공한다.<ref name="newslist">[https://rhymix.org/news/category/177 라이믹스 릴리즈 노트 목록]</ref>

=== 공식 문서와 커뮤니티 ===
공식 문서는 [https://rhymix.org/manual 라이믹스 공식 매뉴얼]과 [https://github.com/rhymix/rhymix-docs rhymix-docs 저장소]에서 확인할 수 있다. 공식 문서에는 설치 환경, 설치 방법, 업데이트, XE 1.x에서 업그레이드, 서드파티 자료 호환성, nginx 설정, 도메인 변경, 확장 기능 제작, 테마 제작, 코어 개발 참여 방법 등이 정리되어 있다.<ref name="docs-repo">[https://github.com/rhymix/rhymix-docs rhymix/rhymix-docs]</ref>

질문과 토론은 공식 홈페이지의 커뮤니티, Q&A, 팁·튜토리얼 게시판과 XETOWN 등을 통해 이루어진다. 공식 홈페이지에는 프론트엔드 포럼도 별도로 운영되고 있다.<ref name="frontend">[https://rhymix.org/frontend 라이믹스 프론트엔드 포럼]</ref> 이 밖에 자료실과 쇼케이스도 운영되고 있어, 모듈, 애드온, 스킨, 레이아웃, 에디터, 테마 패키지 등을 확인할 수 있다.<ref name="pds">[https://rhymix.org/pds 라이믹스 자료실]</ref><ref name="showcase">[https://rhymix.org/showcase 라이믹스 쇼케이스]</ref>

== 버전 ==
라이믹스의 버전별 변경 사항은 공식 홈페이지의 [https://rhymix.org/news 뉴스 및 릴리즈 노트]에서 확인할 수 있다. 정식 버전은 압축 파일 형태로 제공되며, 이전 정식 버전 사용자를 위한 변경 파일 묶음도 함께 제공된다.<ref name="newslist" /> 가온 위키에도 버전별 릴리즈 노트가 [[라이믹스/릴리즈 노트]] 아래에 개별 문서로 정리되어 있다. 버전 번호 체계는 [[라이믹스/버전]] 문서를 참고할 수 있다.

=== 최근 릴리즈 ===
{| class="wikitable"
! 버전 !! 공개일 !! 보안 패치 !! 주요 내용
|-
| [[라이믹스/릴리즈 노트/2.1.36|2.1.36]] || 2026년 8월 12일 || 포함 || 2.1 개발 종료 및 2.2 준비 전환 발표
|-
| [[라이믹스/릴리즈 노트/2.1.35|2.1.35]] || 2026년 7월 8일 || 포함 || URL 파라미터 검증 취약점 수정
|-
| [[라이믹스/릴리즈 노트/2.1.34|2.1.34]] || 2026년 6월 26일 || 포함 || 쉬운설치 도입
|-
| [[라이믹스/릴리즈 노트/2.1.33|2.1.33]] || 2026년 5월 12일 || 포함 || 썸네일 생성 SSRF 취약점 수정
|-
| [[라이믹스/릴리즈 노트/2.1.32|2.1.32]] || 2026년 4월 1일 || 포함 || 애드온 관리 기능 RCE 취약점 수정
|-
| [[라이믹스/릴리즈 노트/2.1.31|2.1.31]] || 2026년 2월 26일 || 포함 || 확장 변수 IDOR 취약점 수정
|-
| [[라이믹스/릴리즈 노트/2.1.30|2.1.30]] || 2026년 2월 10일 || || 관리자 대시보드 검색 결과 개수 표시 등
|-
| [[라이믹스/릴리즈 노트/2.1.29|2.1.29]] || 2025년 12월 18일 || || 이미지 처리 메모리 계산 최적화
|}

=== 2.1 개발 종료와 2.2 ===
2026년 8월 12일 공개된 2.1.36 릴리즈 노트에서 개발진은 라이믹스 2.1을 긴급한 보안 패치 외에는 더 이상 업데이트하지 않고, 2.2 준비에 집중하겠다고 밝혔다. 2.2의 공개 일정과 주요 기능 로드맵은 별도로 공지할 예정이라고 안내되었다.<ref name="release-2136">[https://rhymix.org/news/1953194 Rhymix 2.1.36 Release Notes]</ref>

앞서 2.1.8 릴리즈 노트에서는 프리뷰로 제공되던 템플릿 문법 v2가 2.2에서 정식 지원될 예정이라고 안내된 바 있다.<ref name="release-218" />

=== Development Snapshot ===
공식 홈페이지에서는 정식 다운로드와 별도로 Development Snapshot도 제공한다. Development Snapshot은 개발 중인 최신 코드를 빠르게 사용할 수 있다는 장점이 있지만, 정식 버전에 비해 안정성이 낮을 수 있으므로 운영 사이트에 적용할 때는 주의해야 한다.<ref name="install">[https://rhymix.org/manual/introduction/install 라이믹스 설치]</ref>

== 설치 환경 ==
라이믹스를 설치하려면 공식 매뉴얼에서 제시하는 최소 사양을 만족해야 한다. 2026년 8월 기준 공식 문서의 주요 요구 사항은 다음과 같다.<ref name="requirements">[https://rhymix.org/manual/introduction/requirements 설치 환경]</ref> 자세한 내용은 [[라이믹스/매뉴얼/설치 환경]] 문서를 참고할 수 있다.

{| class="wikitable"
! 구분 !! 요구 사항
|-
| PHP || PHP 7.4 이상, PHP 8.2 이상 권장
|-
| 데이터베이스 || MySQL 5.7 이상 또는 MariaDB 10.6 이상
|-
| 필수 PHP 모듈 || curl, gd, iconv 또는 mbstring, json, openssl, PDO_MySQL, SimpleXML, Zend OPcache
|-
| 권장 PHP 모듈 || apcu, exif, fileinfo, intl, zip
|-
| 웹서버 설정 || Apache의 mod_rewrite 권장. nginx는 별도 rewrite 설정 필요
|-
| 쓰기 권한 || files 폴더에 쓰기 권한 필요
|-
| PHP 메모리 제한 || 최소 128MB, 대용량 이미지 처리 시 256MB 권장
|}

XE는 오래된 PHP 버전에서도 동작하는 경우가 있었지만, 라이믹스는 PHP 7.4 이상이 필요하다. 따라서 XE에서 라이믹스로 넘어오는 경우에는 PHP 버전, 데이터베이스 버전, PHP 확장 모듈, files 폴더 권한을 먼저 확인해야 한다.<ref name="xe-upgrade" />

== 설치 ==
라이믹스 설치는 공식 홈페이지에서 최신 정식 버전 또는 Development Snapshot을 다운로드한 뒤, 웹서버의 문서 루트에 업로드하여 진행할 수 있다. 압축 파일을 FTP 또는 SFTP로 업로드한 뒤 서버에서 압축을 풀거나, 로컬에서 압축을 푼 뒤 전체 파일을 업로드할 수 있다.<ref name="install" />

Git을 사용할 수 있는 서버라면 GitHub 저장소를 직접 clone하는 방식도 가능하다.

<syntaxhighlight lang="console">
git clone https://github.com/rhymix/rhymix.git
</syntaxhighlight>

Git으로 설치하면 이후 업데이트를 비교적 쉽게 적용할 수 있다. 다만 SSH 접속과 git 사용이 가능해야 하며, 서버 환경에 따라 권한 설정을 별도로 확인해야 한다. 웹호스팅과 가상 서버별 구체적인 설치 절차는 [[라이믹스/설치]] 문서를 참고할 수 있다.

설치 과정에서는 데이터베이스 접속 정보, 테이블 접두사, 최고관리자 계정, 표준 시간대, SSL 사용 여부 등을 입력한다. 대한민국 사용자를 대상으로 운영하는 사이트라면 표준 시간대는 일반적으로 Asia/Seoul을 사용한다.<ref name="install" />

== 업데이트 ==
라이믹스는 보안 패치와 버그 수정이 수시로 이루어지므로, 운영 사이트는 정기적으로 업데이트하는 것이 좋다. 공식 매뉴얼은 크게 두 가지 업데이트 방법을 안내한다.<ref name="update" />

=== 새 버전 덮어쓰기 ===
최신 버전의 압축 파일을 내려받아 기존 라이믹스 설치 경로에 덮어쓰는 방식이다. 라이믹스의 설정, 첨부파일, 캐시, 사용자 데이터 등은 주로 files 폴더와 데이터베이스에 저장되므로, 일반적인 업데이트 과정에서 코어 파일을 덮어써도 사이트 데이터가 삭제되지는 않는다.

다만 코어 파일을 직접 수정한 경우에는 수정 내역이 사라질 수 있으므로 주의해야 한다. 코어 파일을 직접 고치는 방식은 업데이트 충돌을 만들기 쉬우므로, 가능하면 모듈, 애드온, 스킨, 이벤트 핸들러 등 확장 기능으로 처리하는 것이 좋다.

=== git으로 업데이트 ===
Git으로 설치한 경우 다음 명령으로 현재 브랜치의 최신 코드를 받을 수 있다.

<syntaxhighlight lang="console">
git pull
</syntaxhighlight>

코어 파일을 수정하지 않았다면 이 방식이 가장 간단하다. 수정한 파일이 있는 경우에는 git stash, 별도 브랜치, merge 등을 이용하여 충돌을 관리해야 한다. 충돌 표시가 남아 있는 파일을 방치하면 화면이 비정상적으로 출력되거나 기능이 동작하지 않을 수 있으므로, 업데이트 후에는 반드시 <code>git status</code>를 확인하는 것이 좋다.

== XE 1.x에서 업그레이드 ==
XE 1.x 사이트는 일반적으로 라이믹스 코어 파일을 기존 XE 설치 경로에 덮어쓰는 방식으로 업그레이드할 수 있다. 공식 매뉴얼은 XE 코어 업데이트와 유사한 방식으로 진행할 수 있다고 설명한다.<ref name="xe-upgrade" />

다만 업그레이드 전에 다음 사항을 반드시 확인해야 한다.

* XE 1.8 미만 버전에서 라이믹스로 직접 업그레이드하는 것은 지원하지 않는다. 먼저 XE 1.8 이상, 가능하면 최신 XE 1.11 계열로 올린 뒤 라이믹스로 넘어가는 것이 권장된다.
* 라이믹스로 변환한 뒤에는 다시 XE로 돌아갈 수 없다.
* FTP 계정의 파일 전체와 데이터베이스를 각각 백업해야 한다.
* 관리자 계정으로 로그인한 상태에서 작업하는 것이 안전하다.
* 업그레이드 후 관리자 화면에서 표시되는 모듈 업데이트와 테이블 생성을 모두 완료해야 한다.
* 모든 업데이트 후 캐시파일 재생성을 실행해야 한다.
* 서드파티 자료의 호환성을 점검해야 한다.
* 라이믹스 2.1 이상에서는 관리자 대시보드에서 불필요한 옛 XE 코어 파일을 정리할 수 있다.<ref name="xe-upgrade" />

== 모듈, 애드온, 스킨 ==
라이믹스는 모듈, 애드온, 위젯, 레이아웃, 스킨, 에디터, 테마 패키지 등 다양한 확장 요소를 통해 기능과 디자인을 추가할 수 있다. 공식 자료실에서도 이러한 자료를 종류별로 분류하여 제공한다.<ref name="pds" />

모듈은 게시판, 회원, 포인트, 쇼핑몰 등 비교적 독립적인 기능 단위를 담당한다. 애드온은 페이지 처리 과정의 특정 지점에 개입하여 부가 기능을 수행하는 방식으로 동작하며, 자세한 내용은 [[라이믹스/애드온]] 문서를 참고할 수 있다. 스킨과 레이아웃은 화면 출력과 디자인을 담당하며, 에디터와 에디터 컴포넌트는 글쓰기 환경을 확장한다.

불필요한 애드온을 많이 활성화하면 사이트 속도와 유지보수에 영향을 줄 수 있다. 따라서 사용하지 않는 확장 기능은 비활성화하거나 삭제하고, 오래된 자료는 PHP 버전과 라이믹스 버전 호환성을 확인한 뒤 사용하는 것이 좋다.

=== 가온 위키의 모듈 문서 ===
가온 위키에는 개별 모듈을 다루는 문서가 별도로 작성되어 있다.

* [[라이믹스/모듈/Reaction]] — 게시물 반응 모듈
* [[라이믹스/모듈/소셜 로그인]] — 코어에서 분리된 소셜 로그인 모듈
* [[라이믹스/모듈/구충제]]

라이믹스의 동작을 방해하여 차단된 자료는 [[라이믹스/블랙리스트]] 문서에 정리되어 있다.

=== 쉬운설치 ===
2026년 6월 26일 공개된 [[라이믹스/릴리즈 노트/2.1.34|2.1.34]]부터는 '''쉬운설치''' 기능이 지원된다. 관리자 화면에서 공식 자료실의 자료를 FTP 접속 없이 바로 설치할 수 있는 기능이다.<ref name="easyinstall">[https://rhymix.org/news/1948052 쉬운설치 지원을 시작합니다]</ref>

쉬운설치 목록에 노출되는 자료는 공개·무료 자료 가운데 2025년 12월 이후 릴리즈 시스템을 이용해 등록하거나 갱신한 것, 또는 기존에 등록된 자료 중 설치 파일을 릴리즈로 변환한 것으로 한정된다. 설치 경로가 표준과 다른 테마 패키지와 기타 분류는 대상에서 제외된다.<ref name="easyinstall" />

목록 갱신에는 시간이 걸린다. 자료 API가 10~15분마다, Cloudflare 캐시가 5~10분마다, 개별 사이트가 4시간마다 갱신되므로, 새로 올라온 자료가 쉬운설치 화면에 나타나기까지 최대 4시간 30분가량 걸릴 수 있다.<ref name="easyinstall" />

공식 공지는 쉬운설치를 이용할 때 신뢰할 수 있는 개발자의 자료만 설치할 것을 권고한다. 서드파티 코드는 사이트의 모든 데이터에 접근할 수 있고 외부로 전송하는 것도 가능하므로, npm이나 Packagist에서 발견된 악성 패키지 사례와 같은 위험이 존재한다는 것이다.<ref name="easyinstall" />

== 서드파티 자료 호환성 ==
라이믹스는 XE 1.x 자료와의 호환성을 최대한 유지하려 하지만, 모든 서드파티 자료가 항상 정상 동작하는 것은 아니다. 특히 오래된 모듈이나 애드온은 PHP 최신 버전, 라이믹스의 보안 정책, 코어 기능 변화와 충돌할 수 있다.

공식 문서에는 XE에서 라이믹스로 업그레이드할 때 점검해야 할 서드파티 자료 호환성 체크리스트가 정리되어 있다.<ref name="thirdparty">[https://rhymix.org/manual/introduction/thirdparty-checklist 서드파티 자료 호환성 체크리스트]</ref> 예를 들어, 과거 XE용으로 쓰이던 일부 메일 발송, 자동 로그인, 멀티도메인, SEO 관련 기능은 라이믹스 코어 또는 시스템 설정에 흡수되었다. 반대로 일부 오래된 애드온은 더 이상 필요하지 않거나 정상적으로 작동하지 않을 수 있다.

라이믹스로 이전한 뒤에는 다음 항목을 점검하는 것이 좋다.

* 관리자 화면의 시스템 설정
* 보안 설정과 세션 관련 설정
* 메일 발송 설정
* 멀티도메인 설정
* SEO 설정
* 자동 로그인 관련 기능
* 게시판, 회원, 포인트, 커뮤니케이션 등 주요 모듈
* 오래된 애드온의 필요 여부
* PHP 8.x 환경에서 발생하는 경고 또는 오류

== 보안 ==
=== 취약점 식별 체계 ===
라이믹스는 자체 취약점 식별 번호인 RVE를 부여하여 관리한다. 번호는 연도와 일련번호를 조합한 형태로, 릴리즈 노트에 취약점 유형과 함께 표기된다.<ref name="newslist" />

2026년에는 확장 변수를 통한 IDOR, 애드온 관리 기능의 원격 코드 실행, 썸네일 생성 과정의 SSRF, 데이터 들여오기 모듈의 SSRF 및 정보 유출, 애드온 관리와 쉬운설치 모듈의 경로 탐색, 폼 전송 시 외부 URL 리다이렉트, URL 파라미터 검증 미비, referrer 헤더를 이용한 반사형 XSS, 모듈 관리자의 권한 초과 접근 등이 RVE-2026-1부터 RVE-2026-20 사이의 번호로 처리되었다.<ref name="release-2136" /><ref name="release-2134">[https://rhymix.org/news/1948042 Rhymix 2.1.34 Release Notes]</ref>

일부 취약점에는 한국인터넷진흥원(KISA)이 부여한 KVE 번호가 함께 표기된다. 데이터 들여오기 모듈의 SSRF에는 KVE-2026-0992가, 쉬운설치 모듈의 경로 탐색에는 KVE-2026-1185가, 모듈 관리자 권한 관련 취약점에는 KVE-2026-1661, KVE-2026-1662, KVE-2026-1666이 각각 부여되었다.<ref name="release-2136" /><ref name="release-2134" />

RVE 번호별 상세 목록과 대응 KVE 번호는 [[라이믹스/보안]] 문서에 정리되어 있다. 라이믹스의 동작을 방해하는 서드파티 자료는 블랙리스트로 처리될 수 있으며, 해당 내역은 [[라이믹스/블랙리스트]] 문서에서 확인할 수 있다.

=== 보안 관련 개선 ===
취약점 수정 외에도 보안을 강화하는 변경이 함께 이루어지고 있다. 2.1.34에서는 비밀번호 찾기 요청을 세션당 1분에 한 번으로 제한하고, 보안 설정에서 세션 ID 갱신을 제어할 수 있도록 하였다.<ref name="release-2134" /> 2.1.36에서는 로그인 비밀번호 입력란에 <code>autocomplete="off"</code>를 적용하고, 회원 정보나 비밀번호가 변경되면 세션 ID를 갱신하도록 하였으며, Guzzle 라이브러리를 최신 보안 패치 버전으로 갱신하였다.<ref name="release-2136" />

=== 버그 및 취약점 제보 ===
일반적인 버그나 개선 제안은 [https://github.com/rhymix/rhymix/issues GitHub 이슈]에 등록할 수 있다. 이슈를 등록할 때는 실행 환경, 라이믹스 버전, PHP 버전, 운영체제, 브라우저, 오류 메시지, 스크린샷, 재현 가능한 URL 등을 함께 제공하는 것이 좋다.<ref name="github-guide">[https://rhymix.org/manual/contrib/github GitHub 이슈 및 PR 작성]</ref>

보안 취약점은 공개 이슈에 올리지 말고 [mailto:devops@rhymix.org devops@rhymix.org]로 제보해야 한다. 공식 저장소와 공식 문서 모두 보안 취약점은 공개적으로 언급하지 말고 개발진에게 비공개로 알려 달라고 안내한다.<ref name="github-readme" /><ref name="github-guide" />

== 공식 자료실과 생태계 ==
라이믹스 공식 홈페이지에는 자료실이 운영되고 있다. 자료실은 모듈, 애드온, 위젯, 레이아웃, 스킨, 에디터, 에디터 컴포넌트, 테마 패키지, 기타 자료 등으로 분류된다.<ref name="pds" />

또한 쇼케이스 게시판에서는 라이믹스를 기반으로 제작된 사이트나 서비스 사례를 확인할 수 있다.<ref name="showcase" /> 라이믹스는 커뮤니티 사이트, 정보 공유 사이트, 기업 홈페이지, 자체 서비스 구축 등 다양한 용도로 사용할 수 있다.

공식 채널 외에도 이용자들이 운영하는 문서·정보 사이트가 있다. 라이믹스 가이드는 변경 내역과 레퍼런스를 별도로 정리하고 있으며,<ref name="rxguide">[https://rhymix-guide.github.io 라이믹스 가이드]</ref> 라이믹스 꿀팁은 활용 팁과 프로젝트 관련 글을 모아 두고 있다.<ref name="rxtip">[https://rxtip.kr 라이믹스 꿀팁]</ref>

== 로고와 BI ==
라이믹스의 공식 로고와 BI 가이드는 공식 홈페이지의 BI Guide에서 제공한다. 이 문서에는 로고 사용 원칙, 공식 색상, 글꼴, 아이콘, PNG·SVG·AI 원본 파일, PDF 가이드 등이 정리되어 있다.<ref name="bi">[https://rhymix.org/bi Rhymix BI Guide]</ref>

BI Guide에 따르면 Rhymix의 이름과 로고는 (주)포에시스가 소유하며, 오픈소스 문화와 프로젝트 발전에 기여하는 방향으로 사용하는 것을 원칙으로 한다. 로고는 공식 색상 조합과 형태를 왜곡하지 않는 범위에서 사용해야 한다.<ref name="bi" />

=== 로고 변천 ===
{| class="wikitable"
| [[파일:rhymix.png|300px]]
| [[파일:rhymix_old.png|300px]]
|-
! 현 라이믹스의 로고
! 예전 라이믹스의 로고
|}

== 개발 참여 ==
라이믹스의 개발은 GitHub에서 이루어진다. 버그 제보, 기능 제안, 코드 기여는 GitHub 이슈와 Pull Request를 통해 진행할 수 있다. 공식 문서는 이슈 작성 전에 같은 문제가 이미 등록되어 있는지 검색하고, 서버 환경과 라이믹스 버전, PHP 버전, 오류 메시지, 재현 방법 등을 함께 제공하도록 안내한다.<ref name="github-guide" />

Pull Request를 작성할 때는 공식 코딩 규칙을 참고해야 한다. 라이믹스 코어 코드는 지원하는 모든 PHP 버전에서 정상 동작해야 하며, 사소한 경고나 deprecated 오류도 방치하지 않는 것을 목표로 한다.<ref name="coding">[https://rhymix.org/manual/contrib/coding-standards 코딩 규칙]</ref>

== XE Admin Help ==
XE 시절 관리자 화면에는 오래된 XE Admin Help 문서가 포함되어 있었다. 그러나 해당 문서는 XE의 오래된 버전을 기준으로 작성되어 최신 라이믹스의 화면과 기능을 설명하기에 적합하지 않았다.

라이믹스에서는 오래된 XE 매뉴얼을 제거하고, 공식 문서를 별도 저장소와 공식 홈페이지 매뉴얼로 관리하는 방향으로 정리하였다.<ref name="old-manual">[https://github.com/rhymix/rhymix/pull/1073 오래된 XE 매뉴얼 삭제 PR]</ref> 현재는 [https://rhymix.org/manual 공식 매뉴얼]과 [https://github.com/rhymix/rhymix-docs rhymix-docs 저장소]를 참고하는 것이 좋다.

== 관련 문서 ==

* [[XpressEngine]]
* [[XETOWN]]
* [[라이믹스/버전]]
* [[라이믹스/릴리즈 노트]]
* [[라이믹스/보안]]
* [[라이믹스/라이선스]]
* [[라이믹스/XE와의 차이점]]
* [[라이믹스/XE에서 넘어오기]]
* [[라이믹스/매뉴얼]]
* [[라이믹스/매뉴얼/설치 환경]]
* [[라이믹스/매뉴얼/라이믹스 업데이트]]
* [[라이믹스/매뉴얼/도메인 변경]]
* [[라이믹스/라우터]]
* [[라이믹스/애드온]]
* [[라이믹스/블랙리스트]]
* [[라이믹스/모듈/Reaction]]
* [[라이믹스/모듈/구충제]]
* [[라이믹스/버그]]
* [[라이믹스/설치]]
* [[라이믹스/Next 라이믹스]]
* [[라이믹스/모듈/소셜 로그인]]

== 외부 링크 ==

* [https://rhymix.org 라이믹스 공식 홈페이지]
* [https://rhymix.org/about 라이믹스 소개]
* [https://rhymix.org/manual 라이믹스 공식 매뉴얼]
* [https://rhymix.org/news 라이믹스 릴리즈 노트]
* [https://rhymix.org/pds 라이믹스 자료실]
* [https://rhymix.org/showcase 라이믹스 쇼케이스]
* [https://rhymix.org/frontend 라이믹스 프론트엔드 포럼]
* [https://rhymix.org/bi Rhymix BI Guide]
* [https://github.com/rhymix/rhymix 라이믹스 GitHub 저장소]
* [https://github.com/rhymix/rhymix-docs 라이믹스 공식 문서 저장소]
* [https://xetown.com XETOWN]

== 각주 ==
<references />

[[분류:CMS]]
[[분류:PHP 소프트웨어]]
[[분류:오픈소스]]
[[분류:라이믹스]]

라이믹스/애드온

2026-08-21T06:03:11Z

Gaon12: 새 문서. 애드온의 동작 방식과 호출 지점, 파일 구조, 코어 기본 애드온 정리

{{틀:상위문서|라이믹스}}

== 개요 ==
'''애드온'''(addon)은 [[라이믹스]]와 [[XpressEngine|XE]]에서 페이지가 처리되는 과정의 특정 지점에 끼어들어 동작을 바꾸거나 기능을 덧붙이는 확장 요소이다. 게시판이나 회원처럼 독립적인 기능 단위를 담당하는 [[XpressEngine/모듈|모듈]]과 달리, 애드온은 자체 화면이나 URL을 갖지 않고 이미 진행 중인 요청에 개입한다.

이 때문에 애드온은 비교적 작은 코드로 사이트 전반에 영향을 주는 기능을 구현할 수 있다. 본문의 URL을 자동으로 링크로 바꾸거나, 접속 통계를 기록하거나, 출력 직전의 HTML에 스크립트를 삽입하는 것이 대표적인 예이다.

== 동작 방식 ==
애드온은 요청 처리 과정에서 코어가 정해 둔 '''호출 지점'''(<code>called_position</code>)마다 실행된다. 애드온 파일은 매번 전체가 실행되며, 파일 안에서 현재 호출 지점이 무엇인지 확인한 뒤 필요한 시점에만 동작하도록 작성한다.

라이믹스 코어가 사용하는 호출 지점은 다음 네 가지이다.

{| class="wikitable"
! 호출 지점 !! 시점 !! 코어 내 위치
|-
| <code>before_module_init</code>
| 모듈이 초기화되기 전. 요청 처리의 가장 이른 단계이다.
| <code>classes/module/ModuleHandler.class.php</code>
|-
| <code>before_module_proc</code>
| 모듈의 실제 처리가 시작되기 전
| <code>classes/module/ModuleObject.class.php</code>
|-
| <code>after_module_proc</code>
| 모듈의 처리가 끝난 뒤. 처리 결과를 가공할 수 있다.
| <code>classes/module/ModuleObject.class.php</code>
|-
| <code>before_display_content</code>
| 최종 HTML이 출력되기 직전
| <code>classes/display/DisplayHandler.class.php</code>
|}

실제 애드온 코드는 대체로 다음과 같은 형태를 띤다.

<syntaxhighlight lang="php">
if ($called_position == 'after_module_proc' && Context::getResponseMethod() == 'HTML')
{
// 이 지점에서만 수행할 작업
}
</syntaxhighlight>

관리자 화면이나 검색엔진 크롤러에서는 동작할 필요가 없는 경우가 많으므로, <code>Context::get('module') != 'admin'</code>이나 <code>!isCrawler()</code> 같은 조건을 함께 확인하는 것이 일반적이다.

== 파일 구조 ==
애드온은 라이믹스 설치 경로의 <code>addons</code> 폴더 아래에 애드온 이름과 같은 폴더를 만들어 배치한다.

<syntaxhighlight lang="text">
addons/
└─ 애드온이름/
├─ 애드온이름.addon.php ← 실행되는 본체
└─ conf/
└─ info.xml ← 이름, 설명, 제작자, 설정 항목 등
</syntaxhighlight>

<code>conf/info.xml</code>에는 여러 언어의 이름과 설명을 함께 넣을 수 있다. 코어에 포함된 애드온의 경우 한국어, 영어, 일본어, 중국어 등 여러 언어의 제목과 설명이 등록되어 있다.

== 코어 기본 애드온 ==
라이믹스는 다음 애드온을 코어에 포함하여 배포한다.

{| class="wikitable"
! 애드온 !! 설명
|-
| <code>adminlogging</code> || 관리자 활동 기록
|-
| <code>autolink</code> || 본문에 포함된 URL을 자동으로 링크로 변환
|-
| <code>counter</code> || 접속 정보 기록. 이 애드온을 켜야 접속 통계가 수집된다
|-
| <code>member_extra_info</code> || 회원 확장 정보 처리
|-
| <code>photoswipe</code> || 이미지 클릭 시 확대 보기 제공
|-
| <code>point_level_icon</code> || 포인트 등급 아이콘 표시
|}

이 밖에 XE 시절 서드파티로 배포되던 본문 내 이미지 조절, 이미지 리사이즈, 리캡챠 등의 기능도 라이믹스 코어에 포함되어 있다. 자세한 내용은 [[라이믹스/XE와의 차이점]] 문서를 참고하자.

== 설치와 관리 ==
애드온은 <code>관리자 페이지 → 고급 → 애드온</code>에서 사용 여부를 설정한다. 애드온마다 PC와 모바일에서의 사용 여부를 따로 지정할 수 있고, <code>conf/info.xml</code>에 설정 항목이 정의된 경우 관리자 화면에서 값을 입력할 수 있다.

새 애드온을 추가할 때는 FTP 또는 SFTP로 <code>addons</code> 폴더에 업로드한다. 이때 <code>addons/이름/이름/파일들</code>처럼 폴더가 이중으로 중첩되지 않도록 주의해야 한다.

[[라이믹스/릴리즈 노트/2.1.34|2.1.34]] 이상에서는 공식 자료실에 등록된 자료를 관리자 화면에서 바로 설치하는 쉬운설치 기능을 이용할 수도 있다.<ref name="easyinstall">[https://rhymix.org/news/1948052 쉬운설치 지원을 시작합니다]</ref>

== 사용할 수 없는 애드온 ==
XE 시절 널리 쓰이던 애드온 가운데 상당수는 라이믹스에서 사용할 수 없다. 같은 기능이 이미 코어에 들어가 있거나, 코어와 충돌하여 다른 기능의 동작을 방해하기 때문이다. 이러한 자료는 블랙리스트로 처리되어 활성화되지 않는다.

블랙리스트에 오른 애드온과 그 대체 방법은 [[라이믹스/블랙리스트]] 문서에 정리되어 있다.

== 주의사항 ==
애드온은 요청 처리 과정에 매번 개입하므로, 활성화된 애드온이 많아질수록 페이지 처리 시간이 늘어난다. 사용하지 않는 애드온은 비활성화하거나 삭제하는 것이 좋다.

또한 오래된 애드온은 최신 PHP에서 경고나 오류를 발생시킬 수 있다. 특히 PHP 8.x는 이전 버전에서 경고 수준이던 문제를 오류로 처리하므로, 오래된 자료를 사용할 때는 라이믹스 버전과 PHP 버전 호환성을 먼저 확인해야 한다.

애드온은 사이트의 모든 요청을 거쳐 가므로 사이트 데이터 전반에 접근할 수 있다. 신뢰할 수 있는 출처의 자료만 설치하는 것이 바람직하다.<ref name="easyinstall" />

== 같이 보기 ==

* [[라이믹스]]
* [[라이믹스/블랙리스트]]
* [[라이믹스/XE와의 차이점]]
* [[XpressEngine/모듈]]
* [[XpressEngine/애드온]]
* [[XpressEngine/애드온/언어 자동 선택]]
* [[XpressEngine/애드온/ZipperUpper!]]

== 각주 ==
<references />


[[분류:라이믹스]]

XpressEngine/모듈

2026-08-21T06:03:08Z

Gaon12: '같이 보기' 문단 추가. 애드온 색인 및 라이믹스 블랙리스트 연결

== 개요 ==
[[XpressEngine]]와 [[라이믹스]]에서 모듈은 핵심 기능을 확장하고 특정 목적을 수행하기 위해 독립적으로 개발되어 통합되는 소프트웨어 컴포넌트를 의미한다. 이는 마치 레고 블록처럼, 사용자가 필요에 따라 기능을 추가하거나 제거하여 웹사이트를 맞춤형으로 구축할 수 있도록 지원한다. 모듈은 XpressEngine의 기본 구조를 변경하지 않으면서도 다양한 기능을 제공함으로써 플랫폼의 유연성과 확장성을 크게 향상시킨다. 핵심 기능 외에도 게시판, 회원 관리, 쇼핑몰, 캘린더 등 다양한 기능을 모듈 형태로 제공하여 사용자는 자신의 웹사이트 목적에 맞는 기능만을 선택적으로 사용할 수 있다. 이러한 모듈화된 구조는 코드의 재사용성을 높이고, 각 기능별로 독립적인 개발 및 유지보수를 가능하게 하여 전체 시스템의 안정성과 효율성을 증대시키는 중요한 역할을 수행한다.

모듈은 코어 시스템과 긴밀하게 상호작용한다. 모듈은 XE 코어에서 제공하는 다양한 API와 이벤트 시스템, 훅(Hook) 등을 활용하여 플랫폼의 기능을 확장하거나 변경한다. 예를 들어, 특정 이벤트가 발생했을 때 특정 모듈이 반응하여 추가적인 작업을 수행하도록 설정할 수 있다. 이러한 이벤트 기반 아키텍처는 모듈 간의 결합도를 낮추고 유연성을 높여준다. 다양한 종류의 모듈이 존재하며, 각 모듈은 특정 역할과 기능을 수행한다. 예를 들어, 위젯 모듈은 웹사이트의 특정 영역에 다양한 정보를 표시하는 기능을 제공하고, 회원 모듈은 사용자 계정 관리 및 인증 기능을 담당하며, 게시판 모듈은 사용자들이 글을 작성하고 공유할 수 있는 공간을 제공한다.

== 모듈 찾기 및 설치 ==
=== 모듈 찾기 ===
사용자는 자신의 목적과 필요한 기능에 맞춰 적절한 모듈을 선택하는 것이 중요하다. <del>[https://xe1.xpressengine.com/download XE 공식 자료실]</del><ref>현재 이미지(미리보기) 출력 안됨에 따라 [[Rhymix Auto Install Repository]] 사용 권장</ref>나 [https://rhymix.org/pds 라이믹스 자료실], 외부 저장소 등을 통해 다양한 모듈을 찾아볼 수 있다. 각 모듈은 기능 설명, 호환성 정보<ref>중요한 부분인데, 라이믹스에서만 지원한다던지, 특정 코어/PHP 버전 등이 적혀져 있으므로 반드시 확인해야 한다.</ref>, 사용자 리뷰, 개발자 정보 등을 포함한 상세 정보를 제공하므로, 사용자는 이러한 정보를 꼼꼼히 확인하여 자신의 환경에 적합한 모듈을 선택해야 한다. 특히 호환성 정보는 현재 사용하고 있는 코어 버전과 모듈이 제대로 작동하는지 확인하는 데 매우 중요하다. 사용자 리뷰는 다른 사용자들이 해당 모듈을 사용하면서 경험한 장단점을 파악하는 데 도움이 되며, 개발자 정보는 모듈에 문제가 발생했을 경우 지원을 받을 수 있는 연락처를 제공한다.

=== 모듈 설치 ===
설치 전에 해당 모듈이 호환되는지 확인해야 한다. 가령 코어 버전을 지원하지 않는 경우나<ref>대부분 최신버전을 요구하기 때문에 코어를 최신버전으로 업데이트 하면 된다.</ref><ref>다만 예전에 릴리즈된 모듈의 경우에는 구버전 코어 버전을 요구하며 최신 버전에서는 오류가 날 수 있다. 이 때에는 코어 버전을 낮추기 보다는 모듈을 수정하는 것을 권장한다.</ref>, PHP 버전을 지원하지 않는 경우<ref>특히 5.x에서 7.x로 업그레이드 시 [[라이믹스/사양#PHP 7.2 이상에서의 문제|BaseObject 오류]]가 발생할 수 있고, 8.x에서는 더욱 엄격하여 배열을 요구하지만 구버전에서는 오류가 아닌 경고나 알림 수준이었던 것이 오류를 뿜으므로 필요한 부분들을 수정해야 한다.</ref>

==== 쉬운 설치(비권장) ====
<code>관리자 페이지 → 고급 → 쉬운 설치</code>에서 모듈을 설치할 수 있다. 다만 현재는 쉬운 설치 서버가 종료 됨에 따라 [[Rhymix Auto Install Repository]]를 사용해야 한다. 사용 방법은 해당 문서 참고하자.

==== 수동 설치(권장) ====
FTP 클라이언트 프로그램을 사용하여 [[XpressEngine]] 또는 [[라이믹스]]가 설치된 경로로 이동한 뒤, <code>modules</code> 폴더 안에 모듈 폴더를 업로드하면 된다. 이때, 폴더 구조가 ''''모듈명/모듈명/파일들''''처럼 이중으로 중첩되지 않도록 주의해야 한다.

==== 설치 마무리 ====
파일 업로드를 한 뒤에는 관리자 페이지에서 'DB 테이블 생성'과 '설정 완료하기' 버튼을 눌러 설치를 마무리한다.

== 모듈 설정 ==
설치된 모듈의 설정을 하기 위해서는 <code>관리자 페이지 → 고급 → 설치된 모듈</code><ref><code>/index.php?module=admin&act=dispModuleAdminContent</code> 경로</ref>에서 원하는 모듈을 선택하면 설정 페이지로 들어가진다. 해당 화면에서 모듈을 설정할 수 있다.

각 모듈은 고유한 설정 옵션을 제공하며, 사용자는 관리자 페이지의 모듈 설정 인터페이스를 통해 이러한 옵션들을 변경하여 모듈의 동작 방식을 원하는 대로 조정할 수 있다. 모듈 설정 인터페이스는 일반적으로 직관적인 UI를 제공하여 사용자가 쉽게 이해하고 설정할 수 있도록 구성되어 있다. 주요 설정 항목은 모듈의 기능에 따라 다양하며, 예를 들어 게시판 모듈의 경우 게시판 이름, 접근 권한, 디자인 테마 등을 설정할 수 있고, 회원 모듈의 경우 회원 가입 시 필요한 정보, 로그인 방식, 회원 등급 등을 설정할 수 있다. 사용자는 자신의 웹사이트 운영 목적과 특정 요구사항에 맞춰 이러한 설정 값들을 변경함으로써 모듈을 최적화하여 활용할 수 있다. 모듈 개발자는 다양한 사용 사례를 고려하여 설정 옵션을 설계하므로, 사용자는 제공되는 옵션들을 충분히 이해하고 활용하는 것이 중요하다.

== 기능 활용 ==
다양한 모듈들은 각각 특화된 기능을 제공하며, 사용자는 이러한 기능을 활용하여 자신의 웹사이트를 풍부하게 만들 수 있다. 예를 들어, 게시판 모듈을 통해 공지사항, 자유게시판, 질문답변 등 다양한 형태의 게시판을 생성하고 운영할 수 있으며, 회원 모듈을 통해 사용자 가입, 로그인, 정보 수정 등의 기능을 제공하여 회원제 서비스를 운영하거나 사용자별 맞춤 콘텐츠를 제공할 수 있다. 폼 관리 모듈을 사용하면 문의 양식, 설문 조사 등 다양한 형태의 웹 폼을 쉽게 제작하고 관리할 수 있으며, [[라이믹스/모듈/누리고|쇼핑몰 모듈]]을 통해 온라인 상거래 기능을 웹사이트에 추가하여 상품 판매 및 결제 시스템을 구축할 수 있다.

== 모듈 개발 ==
효율적인 모듈 개발을 위해서는 적절한 개발 환경을 설정하는 것이 첫 번째 단계이다. 개발자는 통합 개발 환경(IDE), PHP 버전 등 필요한 도구 및 환경을 갖추어야 한다. 일반적으로 PHP는 XE나 라이믹스가 요구하는 특정 버전을 사용하는 것이 중요하며, IDE는 코드 작성, 디버깅 등을 편리하게 수행할 수 있도록 지원한다. 개발자는 구조에 맞춰 필요한 파일들을 구성해야 한다. 기본적인 파일 구조는 모듈의 이름에 따라 디렉토리가 생성되고, 그 안에 컨트롤러, 모델, 뷰 관련 파일, 설정 파일, 언어 파일 등이 포함된다. 이러한 기본 파일 구조를 이해하고 개발 환경을 올바르게 설정하는 것은 효율적인 모듈 개발의 기초가 된다.

=== 모듈의 MVC 패턴 ===
주로 모델-뷰-컨트롤러(MVC) 패턴을 기반으로 이루어진다. 모델은 데이터베이스와의 상호작용을 담당하며, 뷰는 사용자에게 보여지는 화면을 생성하고, 컨트롤러는 사용자 요청을 처리하고 모델과 뷰를 연결하는 역할을 수행한다. 개발자는 모듈 개발 시 데이터베이스 스키마를 설계하고 관리하는 방법을 이해해야 하며, 필요에 따라 새로운 테이블을 생성하거나 기존 테이블을 수정할 수 있어야 한다. MVC 패턴을 기반으로 개발하면 코드의 구조화 및 유지보수가 용이해지고, 각 역할별로 코드를 분리하여 개발 효율성을 높일 수 있다.

=== 훅 ===
개발자들이 플랫폼의 다양한 기능을 활용할 수 있도록 풍부한 API를 제공한다. 개발자는 이러한 API를 통해 데이터베이스 쿼리, 설정 관리, 사용자 인증 등 다양한 작업을 수행할 수 있다. 예를 들어, XE 코어에서 제공하는 DB 관련 API를 사용하여 모듈에서 필요한 데이터를 저장하거나 조회할 수 있으며, 설정 관리 API를 통해 모듈 설정을 저장하고 불러올 수 있다. 또한, 강력한 기능 중 하나인 이벤트 시스템과 훅(Hook)을 활용하면, 특정 이벤트 발생 시 모듈의 특정 기능을 실행하거나, XE 코어의 특정 기능을 변경하거나 확장할 수 있다. 만약 특정 핵심 기능 확장을 위한 API 지원이 부족할 경우, 개발자는 <s>우회적인 방법을 모색하거나 XE 코어 수정까지 고려해야 할 수 있다.</s> 코어 개발진에게 문의해야 한다. 코어 수정의 경우 코어 업데이트 시 문제가 생길 수도 있기 때문이다. 최대한 코어 수정을 하지 않는 방향으로 개발해야 한다.

=== 보안 및 최적화 ===
모듈 개발 시 보안과 성능은 매우 중요한 고려 사항이다. 개발자는 SQL 인젝션, XSS(Cross-Site Scripting) 등 웹 애플리케이션에서 발생할 수 있는 다양한 보안 취약점을 예방하고 안전한 코딩 가이드라인을 준수해야 한다. 예를 들어, 사용자로부터 입력받는 데이터는 반드시 적절하게 검증하고 필터링하여 보안 위협을 방지해야 한다. 또한, 모듈의 성능 최적화를 위해 불필요한 데이터베이스 쿼리를 줄이거나 캐싱 기술을 적용하는 등의 노력을 기울여야 한다. 성능 저하는 사용자 경험에 부정적인 영향을 미칠 수 있으므로, 개발 단계부터 보안과 성능을 최우선으로 고려하여 모듈을 개발해야 한다.

== 같이 보기 ==

* [[XpressEngine/애드온]] — 애드온은 모듈과 달리 자체 화면 없이 페이지 처리 과정에 개입한다
* [[라이믹스/애드온]]
* [[라이믹스/블랙리스트]] — 라이믹스에서 사용할 수 없는 모듈과 애드온

== 각주 ==
<references />


[[분류:XpressEngine]] [[분류:라이믹스]] [[분류:XpressEngine/모듈]] [[분류:라이믹스/모듈]]

라이믹스/애드온

2026-08-21T06:00:06Z

Gaon12: 새 문서. 애드온의 동작 방식과 호출 지점, 파일 구조, 코어 기본 애드온 정리

{{틀:상위문서|라이믹스}}

== 개요 ==
'''애드온'''(addon)은 [[라이믹스]]와 [[XpressEngine|XE]]에서 페이지가 처리되는 과정의 특정 지점에 끼어들어 동작을 바꾸거나 기능을 덧붙이는 확장 요소이다. 게시판이나 회원처럼 독립적인 기능 단위를 담당하는 [[XpressEngine/모듈|모듈]]과 달리, 애드온은 자체 화면이나 URL을 갖지 않고 이미 진행 중인 요청에 개입한다.

이 때문에 애드온은 비교적 작은 코드로 사이트 전반에 영향을 주는 기능을 구현할 수 있다. 본문의 URL을 자동으로 링크로 바꾸거나, 접속 통계를 기록하거나, 출력 직전의 HTML에 스크립트를 삽입하는 것이 대표적인 예이다.

== 동작 방식 ==
애드온은 요청 처리 과정에서 코어가 정해 둔 '''호출 지점'''(<code>called_position</code>)마다 실행된다. 애드온 파일은 매번 전체가 실행되며, 파일 안에서 현재 호출 지점이 무엇인지 확인한 뒤 필요한 시점에만 동작하도록 작성한다.

라이믹스 코어가 사용하는 호출 지점은 다음 네 가지이다.

{| class="wikitable"
! 호출 지점 !! 시점 !! 코어 내 위치
|-
| <code>before_module_init</code>
| 모듈이 초기화되기 전. 요청 처리의 가장 이른 단계이다.
| <code>classes/module/ModuleHandler.class.php</code>
|-
| <code>before_module_proc</code>
| 모듈의 실제 처리가 시작되기 전
| <code>classes/module/ModuleObject.class.php</code>
|-
| <code>after_module_proc</code>
| 모듈의 처리가 끝난 뒤. 처리 결과를 가공할 수 있다.
| <code>classes/module/ModuleObject.class.php</code>
|-
| <code>before_display_content</code>
| 최종 HTML이 출력되기 직전
| <code>classes/display/DisplayHandler.class.php</code>
|}

실제 애드온 코드는 대체로 다음과 같은 형태를 띤다.

<syntaxhighlight lang="php">
if ($called_position == 'after_module_proc' && Context::getResponseMethod() == 'HTML')
{
// 이 지점에서만 수행할 작업
}
</syntaxhighlight>

관리자 화면이나 검색엔진 크롤러에서는 동작할 필요가 없는 경우가 많으므로, <code>Context::get('module') != 'admin'</code>이나 <code>!isCrawler()</code> 같은 조건을 함께 확인하는 것이 일반적이다.

== 파일 구조 ==
애드온은 라이믹스 설치 경로의 <code>addons</code> 폴더 아래에 애드온 이름과 같은 폴더를 만들어 배치한다.

<syntaxhighlight lang="text">
addons/
└─ 애드온이름/
├─ 애드온이름.addon.php ← 실행되는 본체
└─ conf/
└─ info.xml ← 이름, 설명, 제작자, 설정 항목 등
</syntaxhighlight>

<code>conf/info.xml</code>에는 여러 언어의 이름과 설명을 함께 넣을 수 있다. 코어에 포함된 애드온의 경우 한국어, 영어, 일본어, 중국어 등 여러 언어의 제목과 설명이 등록되어 있다.

== 코어 기본 애드온 ==
라이믹스는 다음 애드온을 코어에 포함하여 배포한다.

{| class="wikitable"
! 애드온 !! 설명
|-
| <code>adminlogging</code> || 관리자 활동 기록
|-
| <code>autolink</code> || 본문에 포함된 URL을 자동으로 링크로 변환
|-
| <code>counter</code> || 접속 정보 기록. 이 애드온을 켜야 접속 통계가 수집된다
|-
| <code>member_extra_info</code> || 회원 확장 정보 처리
|-
| <code>photoswipe</code> || 이미지 클릭 시 확대 보기 제공
|-
| <code>point_level_icon</code> || 포인트 등급 아이콘 표시
|}

이 밖에 XE 시절 서드파티로 배포되던 본문 내 이미지 조절, 이미지 리사이즈, 리캡챠 등의 기능도 라이믹스 코어에 포함되어 있다. 자세한 내용은 [[라이믹스/XE와의 차이점]] 문서를 참고하자.

== 설치와 관리 ==
애드온은 <code>관리자 페이지 → 고급 → 애드온</code>에서 사용 여부를 설정한다. 애드온마다 PC와 모바일에서의 사용 여부를 따로 지정할 수 있고, <code>conf/info.xml</code>에 설정 항목이 정의된 경우 관리자 화면에서 값을 입력할 수 있다.

새 애드온을 추가할 때는 FTP 또는 SFTP로 <code>addons</code> 폴더에 업로드한다. 이때 <code>addons/이름/이름/파일들</code>처럼 폴더가 이중으로 중첩되지 않도록 주의해야 한다.

[[라이믹스/릴리즈 노트/2.1.34|2.1.34]] 이상에서는 공식 자료실에 등록된 자료를 관리자 화면에서 바로 설치하는 쉬운설치 기능을 이용할 수도 있다.<ref name="easyinstall">[https://rhymix.org/news/1948052 쉬운설치 지원을 시작합니다]</ref>

== 사용할 수 없는 애드온 ==
XE 시절 널리 쓰이던 애드온 가운데 상당수는 라이믹스에서 사용할 수 없다. 같은 기능이 이미 코어에 들어가 있거나, 코어와 충돌하여 다른 기능의 동작을 방해하기 때문이다. 이러한 자료는 블랙리스트로 처리되어 활성화되지 않는다.

블랙리스트에 오른 애드온과 그 대체 방법은 [[라이믹스/블랙리스트]] 문서에 정리되어 있다.

== 주의사항 ==
애드온은 요청 처리 과정에 매번 개입하므로, 활성화된 애드온이 많아질수록 페이지 처리 시간이 늘어난다. 사용하지 않는 애드온은 비활성화하거나 삭제하는 것이 좋다.

또한 오래된 애드온은 최신 PHP에서 경고나 오류를 발생시킬 수 있다. 특히 PHP 8.x는 이전 버전에서 경고 수준이던 문제를 오류로 처리하므로, 오래된 자료를 사용할 때는 라이믹스 버전과 PHP 버전 호환성을 먼저 확인해야 한다.

애드온은 사이트의 모든 요청을 거쳐 가므로 사이트 데이터 전반에 접근할 수 있다. 신뢰할 수 있는 출처의 자료만 설치하는 것이 바람직하다.<ref name="easyinstall" />

== 같이 보기 ==

* [[라이믹스]]
* [[라이믹스/블랙리스트]]
* [[라이믹스/XE와의 차이점]]
* [[XpressEngine/모듈]]
* [[XpressEngine/애드온/언어 자동 선택]]
* [[XpressEngine/애드온/ZipperUpper!]]

== 각주 ==
<references />


[[분류:라이믹스]]

라이믹스/설치

2026-08-21T06:00:04Z

Gaon12: 브랜치 목록 현행화(develop·next 삭제, v2.2 추가). 압축 파일 설치·웹 설치 절차·설치 후 작업·문제 해결 문단 추가. files 퍼미션 707 권장으로 변경

{{인용문|라이믹스는 PHP로 만들어져 있습니다.<br>PHP는 국내외 대부분의 웹호스팅 서버에서 간단히 업로드하거나 압축을 풀기만 하면 별도의 서버 설정 없이 곧바로 사용이 가능하다는 장점이 있기 때문에, 전세계적으로 가장 많이 사용되는 CMS들은 대부분 PHP로 만들어져 있습니다.|[https://www.github.com/rhymix/rhymix-docs/tree/master/ko%2Fintroduction%2Finstall.md 라이믹스 문서 중]}}

==목표==
[[라이믹스]]를 설치해보자.

==필수사양==
아파치, PHP, MySQL과 같은 필수 설치요소는 [[LAMP]] 문서 등을 확인하자.

나머지 필요한 PHP 확장기능들과 퍼미션, php.ini 설정은 [[라이믹스/매뉴얼/설치 환경]] 문서를 확인하자.

요약하면 PHP 7.4 이상(8.2 이상 권장), MySQL 5.7 이상 또는 MariaDB 10.6 이상이 필요하다.<ref name="requirements">[https://rhymix.org/manual/introduction/requirements 설치 환경 - 라이믹스 매뉴얼]</ref>

==설치 방법 선택==
공식 매뉴얼은 세 가지 방법을 안내한다.<ref name="install">[https://rhymix.org/manual/introduction/install 라이믹스 설치 - 라이믹스 매뉴얼]</ref>

{| class="wikitable"
! 방법 !! 필요 조건 !! 특징
|-
| 정식 버전 압축 파일 || FTP/SFTP만 있으면 됨 || 가장 무난하다. 대부분의 웹호스팅에서 사용 가능
|-
| Development Snapshot || FTP/SFTP만 있으면 됨 || 개발 중인 최신 코드. 정식 버전보다 빠르게 수정이 반영되지만 안정성은 낮다
|-
| git || SSH 접속과 git 사용 가능 || 이후 업데이트가 가장 편하다. 브랜치 선택도 가능
|}

운영 중인 사이트라면 정식 버전을 쓰는 것이 좋다. Development Snapshot은 정식 버전에 아직 반영되지 않은 수정이 필요할 때 선택하되, 자주 업데이트할 각오를 해야 한다.<ref name="install" />

==브랜치==
git으로 설치할 경우 브랜치를 고를 수 있다. 2026년 8월 기준 공식 저장소의 브랜치는 다음과 같다.<ref name="repo">[https://github.com/rhymix/rhymix rhymix/rhymix - GitHub]</ref>

{| class="wikitable"
! 브랜치 !! 설명
|-
| <code>master</code> || 기본 브랜치. 최신 정식 버전이 반영된다. 특별한 이유가 없다면 이것을 쓰자
|-
| <code>v2.2</code> || 다음 버전인 2.2를 준비하는 브랜치. 개발 중이므로 운영 사이트에는 적합하지 않다
|-
| <code>v2.1</code> || 2.1 버전대 유지보수 브랜치
|-
| <code>v2.0</code> || 2.0 버전대 유지보수 브랜치
|-
| <code>v1.9</code> || 1.9 버전대 유지보수 브랜치. 이미 지원이 종료되었다
|}

:※ 과거에는 <code>develop</code>과 <code>next</code> 브랜치를 사용했으나 현재는 존재하지 않는다. <code>next</code>는 2.0 준비용으로 쓰이던 브랜치로, 자세한 내용은 [[라이믹스/Next 라이믹스]] 문서를 참고하자.

:※ [[라이믹스/릴리즈 노트/2.1.36|2.1.36]]을 기점으로 2.1은 긴급 보안 패치 외에는 업데이트되지 않으며, 개발의 초점이 2.2로 옮겨졌다.<ref name="release-2136">[https://rhymix.org/news/1953194 Rhymix 2.1.36 Release Notes]</ref>

==파일 다운로드==
===압축 파일로 다운로드===
[https://rhymix.org 공식 홈페이지]에서 최신 정식 버전 또는 Development Snapshot을 내려받는다. 두 가지 방법이 있다.<ref name="install" />

* 로컬에서 압축을 풀고 전체 파일을 FTP/SFTP로 업로드
* 압축 파일을 업로드한 뒤 SSH로 접속해 서버에서 압축 해제

서버에서 압축을 푸는 편이 훨씬 빠르고 안전하다. FTP 프로그램은 파일이 수천 개에 달할 경우 일부를 누락하는 경우가 있으므로, 로컬에서 풀어 올렸다면 업로드가 온전히 끝났는지 확인해야 한다.<ref name="install" />

서버에서 압축을 풀면 <code>rhymix</code> 폴더가 생기므로 그 안의 내용을 상위 폴더로 옮겨야 한다. 이때 <code>.htaccess</code> 같은 '''숨김 파일이 빠지지 않도록 주의'''해야 한다.<ref name="install" />

===git으로 다운로드(추천)===
대부분의 웹호스팅이나 [[가상 서버|VPS]]에서는 git을 지원하기 때문에 git을 사용하면 다운로드 및 업그레이드가 수월하다.

git으로 다운로드를 받으면, 브랜치도 선택이 가능하기 때문에 권장합니다. 브랜치 선택은 <code>git clone -b 브랜치명 https://github.com/rhymix/rhymix</code> 입니다.

====웹 호스팅====
웹 호스팅에서는 public_html 과 같은 폴더에 파일을 넣어 사용하는 식인데, <code>git clone</code>는 폴더 생성 후 폴더 안에 다운로드를 받는 방식이라 "<nowiki>example.com/rx</nowiki>" 이런 형식으로 사용해야 하기 때문에, 루트 폴더로 이동하는 방식으로 설명합니다.

<syntaxhighlight lang='console'>
user@server:/public_html # git clone https://github.com/rhymix/rhymix rx
user@server:/public_html # cd rx
user@server:/public_html/rx # cp -r * ../
user@server:/public_html/rx # cd ..
user@server:/public_html # rm -rf rx
user@server:/public_html # mkdir files
user@server:/public_html # chmod -R 707 files
</syntaxhighlight>

rx 폴더에 다운로드 받은 뒤, rx 폴더 안에 있는 모든 파일(폴더)들을 상위 폴더로 복사 후, rx 폴더로 이동하는 방식으로 진행합니다.

:※ <code>cp -r *</code>는 <code>.git</code>, <code>.htaccess</code> 같은 숨김 파일을 복사하지 않는다. <code>.htaccess</code>는 짧은주소 사용에 필요하므로 <code>cp -r rx/.htaccess ./</code> 처럼 따로 옮기거나, <code>cp -a rx/. ./</code>를 사용하자.

====가상서버====
/var/www/html을 라이믹스가 설치할 폴더로 설정합니다.

<syntaxhighlight lang='console'>
root@gaon:~ # cd /var/www
root@gaon:/var/www # git clone https://github.com/rhymix/rhymix html
root@gaon:/var/www # cd html
root@gaon:/var/www/html # mkdir files
root@gaon:/var/www/html # chmod -R 707 files
</syntaxhighlight>

<code>git clone</code> 이후 files 폴더를 생성 후 권한을 줍니다.

files 폴더에는 첨부파일이나 각종 설정 파일들이 생성되는 곳입니다.

==files 폴더 권한==
<code>files</code> 폴더에는 첨부파일, 설정 파일, 캐시가 저장되므로 웹서버가 쓸 수 있어야 한다. 퍼미션은 '''707 또는 777'''로 설정한다.

가능하면 707을 먼저 시도하자. 777은 같은 서버의 다른 사용자도 파일을 읽고 쓸 수 있게 되므로, 707로 동작한다면 굳이 777을 줄 이유가 없다.

<syntaxhighlight lang='console'>
root@gaon:/var/www/html # chmod -R 707 files
</syntaxhighlight>

설치 경로에 쓰기 권한이 있으면 설치 과정에서 files 폴더가 자동으로 생성된다. 최근에는 PHP 실행 권한을 FTP 계정과 일치시켜 두는 호스팅이 많아 별도 설정이 필요 없는 경우도 있다.<ref name="install" />

==웹 설치==
파일을 올린 뒤 브라우저로 설치 경로에 접속하면 설치 마법사가 시작된다. 과정은 네 단계이다.<ref name="install" />

# '''사용권 동의''' — GPL 라이선스에 동의해야 다음으로 넘어간다. 언어는 화면 하단에서 언제든 바꿀 수 있다.
# '''설치 환경 확인''' — PHP 버전과 필수 모듈, 퍼미션을 점검한다. <code>mod_rewrite</code>는 선택 사항이므로 없어도 설치는 진행된다.
# '''DB 정보 입력''' — 데이터베이스 종류와 접속 정보를 입력한다. 대개 <code>localhost</code>에 포트는 <code>3306</code>이다. 테이블 접두사는 <code>rx</code> 또는 <code>xe</code>를 권장한다.
# '''관리자 계정 생성''' — 최고관리자 계정과 사용 가능한 이메일 주소를 입력한다. 표준 시간대는 국내 사이트라면 <code>Asia/Seoul</code>을 선택한다. SSL 사용 여부와 사이트 잠금도 이 단계에서 설정할 수 있다.

설치에는 10~30초 정도 걸린다. 완료되면 화면의 설정 아이콘을 통해 관리자 페이지로 들어갈 수 있다.<ref name="install" />

:※ [[XpressEngine|XE]]는 설치 언어 선택과 FTP 정보 입력을 포함해 여덟 단계를 거쳤다. 두 설치 과정의 차이는 [[라이믹스/XE와의 차이점#설치 페이지|라이믹스/XE와의 차이점]] 문서에 정리되어 있다.

==설치 후==
* '''짧은주소''' — Apache는 <code>mod_rewrite</code>와 <code>.htaccess</code>가 있어야 하고, nginx는 rewrite 설정을 직접 넣어야 한다.
* '''크론''' — 메일 발송이나 푸시 알림의 비동기 처리(Queue)를 쓰려면 크론 설정이 필요하다. 웹호스팅 환경이라면 웹크론을 따로 걸어야 한다. 불필요한 데이터를 지우는 정리 스크립트도 함께 등록해 두면 좋다. [[라이믹스/매뉴얼/Crontab 설정 방법]] 문서를 참고하자.
* '''캐시''' — <code>apcu</code>가 설치되어 있으면 관리자 화면에서 캐시로 지정해 성능을 올릴 수 있다.
* '''업데이트''' — 라이믹스는 보안 패치가 잦으므로 설치 직후 최신 버전인지 확인하자. 방법은 [[라이믹스/매뉴얼/라이믹스 업데이트]] 문서를 참고하자.

==문제 해결==
* '''HTTP 500 오류 / BaseObject 오류''' — 서드파티 자료가 PHP 7.2부터 사라진 <code>Object</code> 클래스를 쓰는 경우이다. 해결 방법은 [[라이믹스/매뉴얼/설치 환경#PHP 7.2 이상에서의 문제|설치 환경]] 문서를 참고하자.
* '''첨부파일 업로드 실패''' — <code>files</code> 폴더 퍼미션을 확인하자.
* '''화면이 깨지거나 일부 파일이 없다는 오류''' — FTP 업로드 중 파일이 누락되었을 가능성이 크다. 서버에서 압축을 푸는 방식으로 다시 시도하자.
* '''짧은주소만 404''' — <code>.htaccess</code>가 업로드되지 않았을 가능성이 크다. 숨김 파일이 포함되었는지 확인하자.
* XE에서 넘어오는 경우라면 [[라이믹스/XE에서 넘어오기]] 문서를 참고하자. 새로 설치하는 것과 절차가 다르다.

==같이 보기==

* [[라이믹스]]
* [[라이믹스/매뉴얼]] — 이 문서는 매뉴얼의 '라이믹스 설치' 항목을 겸한다
* [[라이믹스/매뉴얼/설치 환경]]
* [[라이믹스/매뉴얼/라이믹스 업데이트]]
* [[라이믹스/XE에서 넘어오기]]
* [[라이믹스/XE와의 차이점]]
* [[라이믹스/버전]]

==각주==
<references />


[[분류:라이믹스]]

라이믹스/보안

2026-08-21T06:00:01Z

Gaon12: 새 문서. RVE 취약점 식별 체계와 2026년 취약점 목록, KISA KVE 연계 내역 정리

{{틀:상위문서|라이믹스}}

이 문서는 [[라이믹스]]의 보안 취약점 대응 체계와 연도별 취약점 내역을 정리한다. 각 릴리즈의 전체 변경 사항은 [[라이믹스/릴리즈 노트]] 문서와 그 하위 문서를 참고할 수 있다.

== 취약점 식별 체계 ==
라이믹스는 취약점이 확인되면 자체 식별 번호인 '''RVE'''를 부여하고, 수정 사항을 정식 버전 릴리즈 노트에 공개한다. 번호는 연도와 일련번호를 조합한 <code>RVE-연도-번호</code> 형식이다.

보안 패치가 포함된 릴리즈는 공식 릴리즈 노트 제목에 <code>SECURITY</code>가 표시되며, 가온 위키의 릴리즈 노트 문서에서도 '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>''' 표시로 구분하고 있다.

=== KISA 연계 ===
상당수의 취약점은 한국인터넷진흥원(KISA)의 제보로 확인되며, 이 경우 KISA가 부여하는 '''KVE''' 번호가 릴리즈 노트에 함께 표기된다. 하나의 RVE 항목에 여러 개의 KVE 번호가 대응되는 경우도 있다.

== 2026년 취약점 ==
{| class="wikitable"
! RVE !! 내용 !! KVE !! 수정 버전
|-
| RVE-2026-1 || 확장변수를 통해 임의의 파일을 참조할 수 있는 문제 (IDOR) || || [[라이믹스/릴리즈 노트/2.1.31|2.1.31]]
|-
| RVE-2026-2 || SVG 파일 업로드를 통한 XSS 취약점 || KVE-2026-0227 || [[라이믹스/릴리즈 노트/2.1.31|2.1.31]]
|-
| RVE-2026-3 || 애드온 관리 화면을 통한 RCE 취약점 || || [[라이믹스/릴리즈 노트/2.1.32|2.1.32]]
|-
| RVE-2026-4 || 게시판 API를 통해 상담글 내용이 노출될 수 있는 문제 || || [[라이믹스/릴리즈 노트/2.1.32|2.1.32]]
|-
| RVE-2026-5 || ID/PW 찾기 메일을 통해 피싱을 할 수 있는 문제 || || [[라이믹스/릴리즈 노트/2.1.32|2.1.32]]
|-
| RVE-2026-6 || 이미지 변환에 사용하는 외부 프로그램을 통한 command injection 취약점 || KVE-2026-0437 || [[라이믹스/릴리즈 노트/2.1.32|2.1.32]]
|-
| RVE-2026-7 || 썸네일 생성 기능을 통해 내부 정보에 접근할 수 있는 문제 (SSRF) || KVE-2026-0726<br />KVE-2026-0784 || [[라이믹스/릴리즈 노트/2.1.33|2.1.33]]
|-
| RVE-2026-8 || 세션 ID가 갱신되지 않는 문제 || KVE-2026-0728 || [[라이믹스/릴리즈 노트/2.1.33|2.1.33]]
|-
| RVE-2026-9 || 자동 링크(autolink) 애드온의 XSS 취약점 || KVE-2026-0796<br />KVE-2026-0842<br />KVE-2026-0903 || [[라이믹스/릴리즈 노트/2.1.33|2.1.33]]
|-
| RVE-2026-10 || 외부 페이지를 통한 잠재적 RCE 취약점 || KVE-2026-0796 || [[라이믹스/릴리즈 노트/2.1.33|2.1.33]]
|-
| RVE-2026-11 || Photoswipe 애드온의 XSS 취약점 || KVE-2026-0840 || [[라이믹스/릴리즈 노트/2.1.33|2.1.33]]
|-
| RVE-2026-12 || 권한 없는 파일을 임의로 삭제할 수 있는 문제 || KVE-2026-0868 || [[라이믹스/릴리즈 노트/2.1.33|2.1.33]]
|-
| RVE-2026-13 || 폼 제출 후 외부 URL로 리다이렉트시킬 수 있는 문제 || || [[라이믹스/릴리즈 노트/2.1.34|2.1.34]]
|-
| RVE-2026-14 || 데이터 들여오기(importer) 모듈의 외부 요청을 통한 SSRF 및 정보유출 가능성 || KVE-2026-0992 || [[라이믹스/릴리즈 노트/2.1.34|2.1.34]]
|-
| RVE-2026-15 || 애드온 관리 기능을 통한 path traversal 취약점 || || [[라이믹스/릴리즈 노트/2.1.34|2.1.34]]
|-
| RVE-2026-16 || 기존 쉬운설치 모듈의 path traversal 취약점 || KVE-2026-1185 || [[라이믹스/릴리즈 노트/2.1.34|2.1.34]]
|-
| RVE-2026-17 || URL 파라미터 검증 허점으로 인한 open redirect, XSS, CSRF 취약점 || || [[라이믹스/릴리즈 노트/2.1.35|2.1.35]]
|-
| RVE-2026-18 || 쿼리 오류 발생 시 모듈의 권한 설정을 우회할 수 있는 문제 || || [[라이믹스/릴리즈 노트/2.1.35|2.1.35]]
|-
| RVE-2026-19 || referrer 헤더를 통한 반사형 XSS 취약점 || || [[라이믹스/릴리즈 노트/2.1.36|2.1.36]]
|-
| RVE-2026-20 || 문서 및 댓글 권한을 가진 모듈 관리자가 제한된 설정에 접근할 수 있는 문제 || KVE-2026-1661<br />KVE-2026-1662<br />KVE-2026-1666 || [[라이믹스/릴리즈 노트/2.1.36|2.1.36]]
|}

=== 실제 악용이 확인된 사례 ===
RVE-2026-17은 앞서 수정된 RVE-2026-13과 관련된 추가 패치인데, [[라이믹스/릴리즈 노트/2.1.35|2.1.35]] 릴리즈 노트에서는 이전 버전 공개 후 실제로 악용을 시도하는 사례가 발견되고 있다며 빠른 패치를 권고하였다. 공개된 취약점은 패치 공개 이후 오히려 악용 위험이 높아지므로, 보안 패치가 포함된 릴리즈는 가능한 한 즉시 적용하는 것이 좋다.

RVE-2026-18의 경우, 문제가 되는 시점에서 쿼리 오류가 발생하면 안전을 위해 모든 접근을 차단하도록 동작이 변경되었다. 이 때문에 쿼리 오류를 유발하는 서드파티 자료를 사용하는 사이트에서는 업데이트 후 오류가 전체 화면으로 나타날 수 있다.

== 보안 강화 조치 ==
개별 취약점 수정 외에도 보안을 강화하는 변경이 함께 이루어지고 있다.

* [[라이믹스/릴리즈 노트/2.1.34|2.1.34]] — 비밀번호 찾기 요청을 세션당 1분에 한 번으로 제한. 보안 설정에서 세션 ID 갱신을 제어할 수 있도록 함
* [[라이믹스/릴리즈 노트/2.1.36|2.1.36]] — 로그인 비밀번호 입력란에 <code>autocomplete="off"</code> 적용. 회원정보 또는 비밀번호 변경 시 세션 ID 갱신. Guzzle 라이브러리를 최신 보안 패치 버전으로 갱신

== 서드파티 자료의 위험 ==
공식 자료실의 쉬운설치 안내는 서드파티 코드가 사이트의 모든 데이터에 접근할 수 있고 이를 외부로 전송하는 것도 가능하다는 점을 명시하고 있다. npm이나 Packagist에서 발견된 악성 패키지 사례를 들어, 신뢰할 수 있는 개발자의 자료만 설치할 것을 권고한다.<ref name="easyinstall">[https://rhymix.org/news/1948052 쉬운설치 지원을 시작합니다]</ref>

라이믹스의 동작을 방해하는 자료는 블랙리스트로 처리될 수 있다. 자세한 내용은 [[라이믹스/블랙리스트]] 문서를 참고할 수 있다.

== 취약점 제보 ==
보안 취약점은 공개 이슈에 등록하지 말고 [mailto:devops@rhymix.org devops@rhymix.org]로 제보해야 한다. 공식 저장소와 공식 문서 모두 취약점을 공개적으로 언급하지 말고 개발진에게 비공개로 알려 달라고 안내한다.<ref name="github-readme">[https://github.com/rhymix/rhymix rhymix/rhymix GitHub 저장소]</ref><ref name="github-guide">[https://rhymix.org/manual/contrib/github GitHub 이슈 및 PR 작성]</ref>

일반적인 버그와 개선 제안은 [https://github.com/rhymix/rhymix/issues GitHub 이슈]에 등록한다.<ref name="github-guide" />

== 같이 보기 ==

* [[라이믹스]]
* [[라이믹스/릴리즈 노트]]
* [[라이믹스/버전]]
* [[라이믹스/버그]]
* [[라이믹스/블랙리스트]]

== 각주 ==
<references />


[[분류:라이믹스]] [[분류:라이믹스/버전]]

라이믹스/버전

2026-08-21T05:59:58Z

Gaon12: 2.1.34·2.1.36 항목 추가. 2.1 개발 종료와 2.2 준비 문단 신설

== 개요 ==
[[라이믹스]]의 버전 번호 체계와 주요 버전대의 변화를 설명하는 문서이다. 각 버전의 구체적인 변경 사항은 [[라이믹스/릴리즈 노트]] 문서를 참고한다.

라이믹스는 [[XpressEngine|XE]] 1.8 버전을 기반으로 가지치기하여 시작한 CMS 및 프레임워크이다.<ref name="github-readme">[https://github.com/rhymix/rhymix rhymix/rhymix - GitHub]</ref> 초창기에는 XE 1.x와의 호환성과 업그레이드 경로를 고려하여 1.x 버전대를 사용했으나, 이후 독자적인 개발 방향이 강화되면서 2.x 버전대를 사용하고 있다.

== 버전 번호 체계 ==
라이믹스의 정식 릴리즈는 일반적으로 <code>주 버전.부 버전.패치 버전</code> 형식의 세 자리 버전 번호를 사용한다. 예를 들어 [[라이믹스/릴리즈 노트/2.1.36|2.1.36]]은 2.x 계열의 2.1 버전대에서 36번째 패치 릴리즈에 해당한다.

{| class="wikitable"
! 구분 !! 예시 !! 설명
|-
| 주 버전
| <code>2</code>
| 큰 구조 변화, 주요 호환성 변화, 장기 개발 방향의 전환이 있을 때 올라간다.
|-
| 부 버전
| <code>1</code>
| 같은 주 버전 안에서 기능, 지원 환경, 내부 구조가 비교적 크게 바뀔 때 올라간다.
|-
| 패치 버전
| <code>36</code>
| 버그 수정, 보안 패치, 기능 개선, 호환성 개선 등이 포함될 때 올라간다.
|}

보안 패치가 포함된 릴리즈의 경우 릴리즈 노트 제목에 <code>SECURITY</code>가 함께 표시된다.<ref name="release-2133">[https://rhymix.org/news/1940576 Rhymix 2.1.33 Release Notes SECURITY]</ref>

== 배포 형태 ==
=== 정식 버전 ===
정식 버전은 일반 사용자가 운영 환경에서 사용하는 것을 전제로 배포되는 안정 릴리즈이다.<ref>가온 위키에도 릴리즈 노트가 있으므로 [[라이믹스/릴리즈 노트]] 문서를 확인하자.</ref>

=== Development Snapshot ===
Development Snapshot은 개발 중인 최신 소스 코드를 배포한 것으로, 정식 버전보다 빠르게 수정 사항을 반영할 수 있다. 다만 개발 중인 코드이므로 정식 버전보다 예기치 않은 문제가 발생할 가능성도 있다. 라이믹스 매뉴얼에서도 사용자가 원하는 업데이트 주기와 안정성 요구에 따라 정식 버전 또는 Development Snapshot을 선택하도록 안내하고 있다.<ref name="install-manual">[https://rhymix.org/manual/introduction/install 라이믹스 설치 - 라이믹스 매뉴얼]</ref>

== XE 버전과의 관계 ==
라이믹스는 XE 1.8 버전을 기반으로 시작되었기 때문에 초기에는 XE 1.x 계열과 밀접한 관계가 있었다.<ref name="github-readme" /> 1.9.x 버전대까지는 XE와의 호환성을 고려하여 XE와 비슷한 버전 번호를 사용하였다.<ref>[https://github.com/rhymix/rhymix/issues/856#issuecomment-311232043 GitHub rhymix/rhymix 이슈 #856 댓글]</ref>

이후 XE 1.10.x의 릴리즈 계획이 취소되고,<ref name="xe-110-cancel">[https://xe1.xpressengine.com/devlog/23254107 XE Core 1.10의 PHP 지원 버전 변경 안내 - 취소]</ref> XE는 1.11.x 버전대로 넘어갔지만 라이믹스는 XE의 버전 번호를 그대로 따르지 않고 독자적인 버전 체계를 유지하였다. 그 결과 라이믹스는 <code>2.0.0</code>부터 본격적으로 자체 2.x 버전대를 사용하게 되었다.

== 주요 버전대 ==
{| class="wikitable"
! 버전대 !! 주요 릴리즈 !! 성격
|-
| <code>1.9.x</code>
| <code>1.9.13</code>
| XE 1.x 계열과의 호환성을 중시하던 버전대이다. <code>1.9.13</code>은 1.9.x 사용자를 위한 보안 패치 백포트 릴리즈였으며, 1.x 버전대의 보안 패치 백포트 지원은 2021년 말 종료될 예정이라고 공지되었다.<ref name="release-1913">[https://rhymix.org/news/264 Rhymix 1.9.13 Release Notes SECURITY]</ref>
|-
| <code>2.0.x</code>
| <code>2.0.0</code>
| 독자적인 2.x 버전대의 시작이다. <code>2.0.0</code>은 2020년 12월 18일 정식 릴리즈되었으며, DB 연동 기능 강화, 게시판 기능 강화, PHP 8.0 호환성 개선 등 여러 변화가 포함되었다.<ref name="release-200">[https://rhymix.org/news/132 Rhymix 2.0.0 Release Notes]</ref>
|-
| <code>2.0.x</code>
| <code>2.0.24</code>
| PHP 7.0 및 7.1을 지원하는 마지막 2.0.x 릴리즈이다. 이후 릴리즈는 PHP 7.2 이상을 요구하며, PHP 7.4 이상 사용이 권장되었다.<ref name="release-2024">[https://rhymix.org/news/348 Rhymix 2.0.24 Release Notes]</ref>
|-
| <code>2.1.x</code>
| <code>2.1.0</code>
| 2023년 6월 21일 릴리즈된 2.1 버전대의 첫 정식 버전이다. 초기 2.1 버전대는 PHP 7.2 이상에서 사용할 수 있었으며, PHP 7.4 이상이 권장되었다.<ref name="release-210">[https://rhymix.org/news/356 Rhymix 2.1.0 Release Notes]</ref>
|-
| <code>2.1.x</code>
| <code>2.1.20</code>
| 설치 환경이 PHP 7.4 이상으로 변경되었다. PHP 7.4 미만에서는 더 이상 작동하지 않는다고 공지되었다.<ref name="release-2120">[https://rhymix.org/news/515 Rhymix 2.1.20 Release Notes]</ref>
|-
| <code>2.1.x</code>
| <code>2.1.34</code>
| 관리자 화면에서 공식 자료실의 자료를 FTP 없이 설치하는 쉬운설치 기능이 도입되었다.<ref name="release-2134">[https://rhymix.org/news/1948042 Rhymix 2.1.34 Release Notes SECURITY]</ref>
|-
| <code>2.1.x</code>
| <code>2.1.36</code>
| 2026년 8월 기준 최신 정식 버전이다. 이 릴리즈를 기점으로 2.1 버전대는 긴급 보안 패치 외에는 더 이상 업데이트되지 않으며, 개발의 초점이 2.2 준비로 옮겨졌다.<ref name="release-2136">[https://rhymix.org/news/1953194 Rhymix 2.1.36 Release Notes SECURITY]</ref>
|}

== 2.1 개발 종료와 2.2 ==
{{날짜/출력|2026-08-12}}에 공개된 [[라이믹스/릴리즈 노트/2.1.36|2.1.36]] 릴리즈 노트에서 개발진은 2.1 버전대를 긴급한 보안 패치 외에는 더 이상 업데이트하지 않고, 2.2 준비에 집중하겠다고 밝혔다. 2.2의 공개 일정과 주요 기능 로드맵은 별도로 공지할 예정이라고 안내되었다.<ref name="release-2136" />

앞서 [[라이믹스/릴리즈 노트/2.1.8|2.1.8]]에서 프리뷰로 도입된 템플릿 문법 v2가 2.2에서 정식 지원될 예정이라고 안내된 바 있다.<ref name="release-218">[https://rhymix.org/news/424 Rhymix 2.1.8 Release Notes]</ref>

== 버전 선택 ==
일반적인 운영 환경에서는 공식 홈페이지에서 제공하는 최신 정식 버전을 사용하는 것이 권장된다. 특히 릴리즈 노트에 <code>SECURITY</code>가 표시된 버전은 보안 취약점 수정이 포함되어 있으므로 가능한 한 빠르게 업데이트하는 것이 좋다.

반면 Development Snapshot은 최신 변경 사항을 빠르게 반영할 수 있다는 장점이 있으나, 개발 중인 코드가 포함될 수 있으므로 운영 환경에 적용할 때에는 충분한 테스트와 백업이 필요하다.<ref name="install-manual" />

== 같이 보기 ==

* [[라이믹스]]
* [[라이믹스/릴리즈 노트]]
* [[라이믹스/보안]]
* [[XpressEngine]]

== 각주 ==
<references />



[[분류:라이믹스]]
[[분류:라이믹스/버전]]

라이믹스/버그

2026-08-21T05:59:55Z

Gaon12: 버그 상태 요약표 추가. CKEditor 붙여넣기 문제의 해결 내역(2020-12, 기본 제거 플러그인 목록) 반영. 누락되어 있던 <references /> 및 분류 추가

==이 문서는?==
[[라이믹스]]에 있는 버그들에 대해 서술합니다.

아직 해결되지 않은 '''보안 이슈'''는 이곳에 올리지 마시고 [mailto:devops@rhymix.org devops@rhymix.org]에 메일을 보내세요.

먼저 라이믹스를 최신 버전으로 업데이트 하고, 아직 해결되지 않은 경우에만 따라하세요.



버전별로 수정된 내용은 [[라이믹스/릴리즈 노트]] 문서에서, 보안 취약점은 [[라이믹스/보안]] 문서에서 확인할 수 있다.

==버그 목록==
{| class="wikitable"
! 버그 !! 보고된 버전 !! 상태 !! 해결 시점
|-
| 다국어 설정 버튼 미작동 || 1.9.3~1.9.6 || 해결됨 || 1.9.7 이후 재현되지 않음
|-
| CKEditor 붙여넣기 불가 || 1.9.x~2.0.x || 해결됨 || 2020년 12월. 문제 플러그인이 기본 제거 목록에 포함됨
|-
| 휴지통 이동 시 포인트 미회수 || 1.9.x 이하 || 해결됨 || 2018년 12월 패치
|-
| 모듈 선택 불가 || 1.9.9 || 해결됨 || 2018년 12월 패치
|-
| 로그인 시 무한 리디렉션 || 2.0.24 || 해결됨 || 2023년 3월 패치. 2.1.0 이후 해당 없음
|}

'''이 문서에 정리된 버그는 현재 모두 해결된 상태이다.''' 아래 문단에 남아 있는 수동 수정 방법은 당시의 기록이며, 최신 버전에서는 적용할 필요가 없다.

{{인용문|코어 파일을 직접 수정하면 이후 업데이트에서 충돌이 발생하거나 수정 내역이 사라질 수 있다. 아래의 수동 패치는 기록으로만 참고하고, 실제로는 최신 버전으로 업데이트하여 해결하자.}}

==다국어==
===다국어 설정 버튼 미작동===
;상태: '''해결됨''' (1.9.7 이후 재현되지 않음)

다국어 설정 후, 문구를 입력한 뒤, '저장 및 사용' 버튼을 누르면 아무 일도 일어나지 않는다. 다국어 정보는 저장되는 것으로 보아, 불러와 사용하는 것이 안되는 것 같다. [https://xetown.com/qna/970639 xetown 다국어 문제 제기 글]

1.9.3에서는 되는 것으로 보아 굳이 사용을 해야 한다면 [[깃허브]]에 이슈를 등록하고 기다리거나, 구버전을 사용해야 할 것 같다.(구버전의 사용은 왠만해서는 사용하지 말자. 보안적 취약점이나 버그들이 있으니깐.)

해당 버그는 1.9.7 이후에는 재현되지 않는다.

==CKEditor==
===단축키를 제외한 다른 방법으로의 붙혀넣기 불가능?===
;상태: '''해결됨''' (2020년 12월 13일 이슈 종료)

키보드의 ctrl + v의 붙혀넣기가 되지 않는다. 'Your browser doesn't allow you to paste this way. Press 컨트롤+V to paste.' 라는 메시지가 출력된다. [https://github.com/rhymix/rhymix/issues/1128 깃허브 이슈 #1128]

[[XpressEngine|XE]]에서도 동일 문제가 발생하였지만, 문제의 플러그인을 빼고 재빌드 해서 문제는 사라졌다.

라이믹스는 [[CKEditor]]를 순정 상태로 사용한다.<ref>라이믹스에 포함된 서드파티 플러그인들은 유지보수 용이성을 위해 최대한 순정 상태를 유지한 채 공식 지원되는 설정만 조정하여 사용하는 것을 원칙으로 하므로, contextmenu를 빼고 빌드할 계획은 없다고 밝혔다. [https://github.com/rhymix/rhymix/issues/1128#issuecomment-449964979 깃허브 기진곰님 답변]</ref> 따라서 재빌드 대신 에디터 설정의 '플러그인 제거' 항목으로 처리하는 방식을 택했다.

====현재 상태====
2018년 12월에 등록된 이슈는 2020년 12월 13일에 종료되었다. 개발자는 최근 버전 기준으로 contextmenu 및 연관 플러그인이 '''플러그인 제거 설정에 기본으로 입력되어 있다'''고 밝혔다.<ref name="issue1128">[https://github.com/rhymix/rhymix/issues/1128 깃허브 이슈 #1128 - ckeditor contextmenu 플러그인 제거]</ref>

실제로 현재 코어는 다음 플러그인을 기본으로 제거한다.<ref name="editor-class">[https://github.com/rhymix/rhymix/blob/master/modules/editor/editor.class.php modules/editor/editor.class.php]의 <code>remove_plugins</code> 기본값</ref>

* <code>liststyle</code>
* <code>tabletools</code>
* <code>tableselection</code>
* <code>contextmenu</code>
* <code>exportpdf</code>

따라서 새로 설치한 사이트에서는 이 문제가 발생하지 않는다.

====수동 설정을 해 둔 경우====
'''플러그인 제거 항목을 직접 지정해 둔 사이트에서는 수동 설정이 기본값보다 우선하므로, 최신 버전을 쓰더라도 이 문제가 계속 나타날 수 있다.'''<ref name="issue1128" />

오래 운영한 사이트에서 붙여넣기 문제가 남아 있다면 <code>관리자 페이지 → 에디터 설정</code>의 '플러그인 제거' 칸을 확인하고, 위 목록이 빠져 있다면 추가하자.

====과거의 대응 방법====
패치 이전에는 다음과 같이 대응했다. 현재는 필요하지 않다.

* '''설정으로 해결''' — 에디터 설정의 '플러그인 제거' 칸에 contextmenu와 이를 필요로 하는 플러그인 이름을 직접 입력했다.<ref>[https://xetown.com/qna/1019453#comment_1019543 xe타운 웹지기님의 댓글]</ref> 지금은 이 값이 기본으로 들어 있다.
* '''수정본 CKEditor 사용''' — [[XETOWN]] 포인트 마켓에 문제 플러그인을 제거한 CKEditor 파일이 올라온 적이 있다.<ref>[https://xetown.com/point_contents/1200775 XETOWN 포인트 마켓 - CKEditor 붙여넣기 버그 픽스] / [http://archive.is/oSVS4 archive.is 박제]</ref> 코어 파일을 갈아끼우는 방식이라 업데이트 시 덮어써지고 CKEditor 보안 업데이트를 따로 챙겨야 하므로 권장되지 않았다.

==휴지통-포인트==
===문서나 댓글을 휴지통에 보내더라도 포인트가 회수되지 않는 버그===
;상태: '''해결됨''' (2018년 12월 13일 패치)

문서나 댓글 작성시 포인트를 주도록 설정한 후, 문서/댓글을 작성 뒤 휴지통으로 이동시키면 포인트가 회수되지 않는다. [https://xetown.com/questions/1125365 xetow 문제 제기글] 이건 [[XpressEngine|XE]]에서부터 있었던 고전적인 버그다.

패치를 통해 해결되었다. [https://github.com/rhymix/rhymix/commit/f58be6185e61fc9bce0eab3ab1388b7d7d7580ef f58be61 커밋], [https://github.com/rhymix/rhymix/commit/4158d946061d57206870491a061b9ec9e345ce3a 4158d94 커밋]

==모듈 선택==
===모듈 선택이 되지 않는 버그===
;상태: '''해결됨''' (2018년 12월 29일 패치)

아래의 수동 수정 방법은 패치 이전에 쓰이던 것이다. 최신 버전에는 이미 반영되어 있으므로 그대로 따라 하면 안 된다.

1.9.9 버전에서 기존에 [[XpressEngine/모듈/CafeXE|CafeXE]] 모듈을 사용하였다면 모듈 선택이 되지 않는 버그가 발생했다. 기존에 [[XpressEngine/모듈/CafeXE|CafeXE]] 모듈을 사용하지 않았더라도 문제가 발생 할 수 있는데, 멀티사이트 기능의 흔적을 점진적으로 들어내고 있기 때문이다.<ref>[https://xetown.com/topics/1136515#comment_1136664 xetown 기진곰님 답변]</ref>

site_srl이 0이 아닌 경우, 목록에서 안 보일 수 있다.<ref>[https://xetown.com/topics/1136515#comment_1136573 xetown 기진곰님 답변]</ref>

===module.view.php 수정===
'''./modules/module/module.view.php''' 파일을 수정한다.
====수정 전====
8번째 줄을 삭제한다.
<syntaxhighlight lang="PHP" highlight="8" start='41' line>

/**
* @brief Select a module
*/
function dispModuleSelectList()
{
// Get a list of modules at the site
$args = new stdClass;
$output = executeQueryArray(isset($query_id) ? $query_id : 'module.getSiteModules', $args);

$mid_list = array();
$oModuleModel = getModel('module');
</syntaxhighlight>

====수정 후====
8번째 줄을 삭제한 모습
<syntaxhighlight lang="PHP" start='41' line>

/**
* @brief Select a module
*/
function dispModuleSelectList()
{
// Get a list of modules at the site
$args = new stdClass;

$mid_list = array();
$oModuleModel = getModel('module');
</syntaxhighlight>

===getSiteModules.xml===
'''./modules/module/queries/getSiteModules.xml''' 파일을 수정한다.

쿼리에 조인이 들어간 것을 미처 패치 못하여 [[라이믹스/버그#module.view.php 수정|module.view.php 수정]] 이후에 패치를 진행하였다. [https://github.com/rhymix/rhymix/commit/7e80ab2c62420820fe16823c518de7a914e0ab8f 깃허브 라이믹스 - Fix #1130 ignore site_srl in getSiteModules query]

====수정 전====
3, 12, 22~26번째 줄을 삭제한다.
<syntaxhighlight lang="XML" highlight="3,12,22-26" start='1' line>
<query id="getSiteModules" action="select">
<tables>
<table name="sites" />
<table name="modules" />
<table name="module_categories" alias="module_categories" type="left join">
<conditions>
<condition operation="equal" column="module_categories.module_category_srl" default="modules.module_category_srl" />
</conditions>
</table>
</tables>
<columns>
<column name="sites.domain" />
<column name="modules.site_srl" />
<column name="modules.module" />
<column name="modules.module_category_srl" />
<column name="modules.layout_srl" />
<column name="modules.mid" />
<column name="modules.browser_title" />
<column name="modules.module_srl" />
<column name="module_categories.title" alias="category" />
</columns>
<conditions>
<condition operation="equal" column="sites.site_srl" var="site_srl" />
<condition operation="equal" column="sites.domain" var="site_keyword" pipe="and" />
<condition operation="equal" column="sites.site_srl" default="modules.site_srl" pipe="and" />
</conditions>
<navigation>
<index var="sort_index1" default="modules.module" order="asc" />
<index var="sort_index2" default="modules.mid" order="asc" />
</syntaxhighlight>

====수정 후====
3, 12, 22~26번째 줄을 삭제하고 난 뒤의 코드

<syntaxhighlight lang="XML" start='1' line>
<query id="getSiteModules" action="select">
<tables>
<table name="modules" />
<table name="module_categories" alias="module_categories" type="left join">
<conditions>
<condition operation="equal" column="module_categories.module_category_srl" default="modules.module_category_srl" />
</conditions>
</table>
</tables>
<columns>
<column name="modules.site_srl" />
<column name="modules.module" />
<column name="modules.module_category_srl" />
<column name="modules.layout_srl" />
<column name="modules.mid" />
<column name="modules.browser_title" />
<column name="modules.module_srl" />
<column name="module_categories.title" alias="category" />
</columns>
<index var="sort_index1" default="modules.module" order="asc" />
<index var="sort_index2" default="modules.mid" order="asc" />
</syntaxhighlight>

== 로그인 상태에서 로그인 페이지로 이동 시 무한 리디렉션 ==
;상태: '''해결됨''' (2023년 3월 패치, [[라이믹스/릴리즈 노트/2.1.0|2.1.0]] 이후 해당 없음)

* 이 문제는 문제 발생 시기의 최신 버전이던 [[라이믹스/릴리즈 노트/2.0.24|라이믹스 2.0.24]]에서 발생하던 버그입니다.
{{내용 보기|기여자 목록|본 내용은 CC BY-SA 4.0으로 가져온 내용입니다. [https://xetown.com/questions/member_info?member_srl{{=}}138191 톰캣], [https://xetown.com/questions/member_info?member_srl{{=}}1047 YJSoft]이 기여한 내용입니다.}}

로그인 버튼을 2번 누르고 로그인을 시도하면 <code>www.example.dom 에서 리디렉션한 횟수가 너무 많습니다.</code> 라는 메시지가 뜬다.

=== 해결 방법 ===
[https://github.com/rhymix/rhymix/commit/755883245b059374facfd5b5a8de2c15ac0a3f3d 2023년 3월 14일]과 [https://github.com/rhymix/rhymix/commit/bc2d46b36ec01f11822c1f5bece85f2a16daf6e8 3월 23일] 두 커밋으로 수정되었다. 두 번째 커밋에서는 가입 URL 등 같은 문제가 생길 수 있는 경로가 추가로 처리되었다.

이 수정은 [[라이믹스/릴리즈 노트/2.1.0|2.1.0]]에 포함되었으므로 2.1.0 이상에서는 별도 조치가 필요 없다.

==버그 제보==
새로 발견한 버그는 [https://github.com/rhymix/rhymix/issues 깃허브 이슈]에 등록할 수 있다. 등록할 때는 실행 환경, 라이믹스 버전, PHP 버전, 운영체제, 브라우저, 오류 메시지, 재현 방법을 함께 적는 것이 좋다.<ref name="github-guide">[https://rhymix.org/manual/contrib/github GitHub 이슈 및 PR 작성 - 라이믹스 매뉴얼]</ref>

'''보안 취약점은 공개 이슈에 올리지 말고''' [mailto:devops@rhymix.org devops@rhymix.org]로 제보해야 한다.<ref name="github-guide" /> 자세한 내용은 [[라이믹스/보안]] 문서를 참고하자.

==같이 보기==

* [[라이믹스]]
* [[라이믹스/보안]]
* [[라이믹스/릴리즈 노트]]
* [[라이믹스/블랙리스트]]
* [[라이믹스/XE와의 차이점]]

==분기==
{{퍼온문서|라이믹스|4513||가온 위키}}

==각주==
<references />


[[분류:라이믹스]]

라이믹스/매뉴얼/확장 기능 제작/라우터 사용법

2026-08-21T05:59:53Z

Gaon12: 넘겨주기 생성. 정본 문서인 라이믹스/라우터로 연결

#넘겨주기 [[라이믹스/라우터]]

라이믹스/매뉴얼/템플릿 문법 v2

2026-08-21T05:59:50Z

Gaon12: 새 문서. Blade 기반 템플릿 문법 v2

{{틀:상위문서|라이믹스/매뉴얼}}

== 개요 ==
'''템플릿 문법 v2'''는 [[라이믹스/릴리즈 노트/2.1.8|라이믹스 2.1.8]]부터 프리뷰 형식으로 제공되고, '''라이믹스 2.2부터 정식 지원'''할 템플릿 문법이다.<ref name="v2">[https://rhymix.org/manual/theme/template_v2 템플릿 문법 v2 - 라이믹스 매뉴얼]</ref>

Laravel Blade 문법을 기반으로 하되, 라이믹스의 구조와 기능에 맞게 여러 지시자(directive)가 추가되었다. 기존 v1 문법 중 안정성과 편리함이 검증된 요소도 상당수 그대로 유지되어 두 문법을 섞어 쓸 수 있다.<ref name="v2" />

다만 '''Laravel Blade를 그대로 가져다 쓰는 것이 아니다.''' PHP 지원 범위, 서로 다른 출처의 모듈과 스킨을 조합하는 라이믹스의 특성, <code>Context</code> 변수 참조 방식, v1 문법 유지 등의 이유로 Laravel의 코드를 그대로 쓰기 어려워, "Blade 스타일"의 문법만 차용하고 컴파일러는 자체 구현하였다. 따라서 세부 해석 방식에 차이가 있을 수 있다.<ref name="v2" />

이 문서에서는 공식 매뉴얼의 표현을 따라 Blade 스타일 문법을 '''v2 정규 문법''', v1과 호환되는 문법을 '''v1 호환 문법'''으로 부른다. 두 문법은 충돌하지 않지만, 가능하면 v2 정규 문법만 쓰는 것이 권장된다.<ref name="v2" />

== 버전 표기 ==
확장자가 <code>.blade.php</code>인 파일은 모두 v2로 인식한다. VSCode, PHPStorm, IntelliJ 등 대부분의 편집기에서 Blade 플러그인을 설치하면 문법 강조와 자동 완성을 쓸 수 있다.<ref name="v2" />

확장자가 <code>.html</code>인 파일에서 v2 문법을 쓰려면 최상단에 버전을 표기해야 한다.

<syntaxhighlight lang="html">
@version(2)
</syntaxhighlight>

<syntaxhighlight lang="html">
<config version="2" />
</syntaxhighlight>

== v1과의 차이 ==
=== 문법 비교 ===
v1의 조건문·루프문에서 좌우의 주석을 지우면 Blade 지시자와 거의 같은 형태가 된다. 라이믹스가 차기 템플릿 문법으로 Blade를 채택한 이유 중 하나다.<ref name="v2" />

<syntaxhighlight lang="html">
@if ($condition)
<div class="comment">{{ $comment }}</div>
@endif
</syntaxhighlight>

<syntaxhighlight lang="html">

<div class="comment">{$comment}</div>

</syntaxhighlight>

=== 문맥에 맞는 자동 이스케이프 ===
템플릿에서 출력하는 '''모든 데이터는 자동으로 escape되며, 이를 일괄 해제하는 옵션은 제공하지 않는다.''' 필요한 곳에서만 <code>noescape</code> 필터나 <code>{!! $var !!}</code> 문법으로 개별 해제한다. 이미 escape된 데이터를 이중 인코딩하지는 않는다.<ref name="v2" />

<code><nowiki><script></nowiki></code> 태그 안에서는 문맥을 자동으로 인식하여 HTML이 아닌 JS 문법에 맞게 escape한다. 예를 들어 <code><</code>는 HTML 문맥에서 <code>&lt;</code>, JS 문맥에서 <code><</code>로 변환된다.<ref name="v2" />

=== 일관성 있는 Context 참조 ===
v1에서는 <code><nowiki><?php ?></nowiki></code>로 PHP 코드를 직접 쓰면 <code>Context</code>를 참조하지 않는 로컬 변수가 생겨 <code>{@ ...}</code> 문법의 변수와 연동되지 않는 불편이 있었다. v2에서는 템플릿에서 쓰는 모든 변수가 항상 일관되게 <code>Context</code>를 참조한다.<ref name="v2" />

=== 제거된 문법 ===
XE 1.4.4 이후 수많은 템플릿 해석 오류의 원인이 되어 온 <code><nowiki><block></nowiki></code> 가상 태그, <code>loop</code> 속성, <code>cond</code> 속성을 '''지원하지 않는다.''' 사용하면 출력물에 소스가 그대로 남거나 오류가 발생할 수 있다.<ref name="v2" />

<code><nowiki><include></nowiki></code>의 <code>cond</code> 속성과 <code>|cond=""</code> 문법은 계속 지원하지만, <code>@class</code>, <code>@style</code>, <code>@selected</code> 등으로 바꾸는 것이 권장된다.

== 데이터 출력 ==
표준은 중괄호 두 쌍이다. v1처럼 한 쌍만 써도 되지만, 중괄호 바로 안쪽에 공백이 있으면 안 된다.

<syntaxhighlight lang="html">
{{ $var }}
{{ $oDocument->getNickName() }}
</syntaxhighlight>

한 쌍만 쓰면 클로저처럼 중괄호가 포함된 코드를 쓸 수 없고, 중괄호 안에서 줄바꿈을 할 수 없다.

=== 단일 중괄호가 금지되는 위치 ===
v1 호환 문법은 일반적인 CSS·JS 문법과 충돌하는 경우가 많아, '''라이믹스 2.1.22부터 CSS·JS 문맥에서는 허용하지 않는다.''' 아래 위치에서는 반드시 중괄호 두 쌍을 써야 한다.<ref name="v2" />

* <code><nowiki><script></nowiki></code> 태그 안
* <code><nowiki><style></nowiki></code> 태그 안
* <code>onclick</code> 등 이벤트 핸들러 속성 안
* <code>pattern</code> 속성 안 (2.1.25~)
* <code><nowiki><a href="javascript:..."></nowiki></code> 등 JS를 쓰는 속성 안
* 모든 태그의 <code>style</code> 속성 안

=== 변수의 유효 범위 ===
템플릿의 변수는 모두 <code>Context</code>와 연동된다. 모듈이나 위젯에서 <code>Context::set('foo', $value)</code>로 설정했거나 <code>$_GET['foo']</code>로 들어온 값을 템플릿에서 <code>$foo</code>로 참조할 수 있고, 반대로 템플릿에서 <code>$foo</code>를 조작하면 다른 자료에서 <code>Context::get('foo')</code>로 바뀐 값을 읽을 수 있다. 즉 <code>Context</code>를 공용 상태 저장소로 쓴다.<ref name="v2" />

다음은 <code>Context</code>와 연동되지 않는다.

* 변수와 함께 인클루드한 템플릿 안의 변수
* <code>$_SERVER</code>, <code>$_SESSION</code>, <code>$GLOBALS</code> 등 초전역변수
* <code>Template</code> 인스턴스를 가리키는 <code>$this</code>
* 변수 앞에 <code>\</code>를 붙인 <code>\$foo</code> — 로컬 변수가 된다. 클로저를 선언할 때도 이 방법을 써야 한다

<syntaxhighlight lang="html">
{{ implode(', ', array_map(function(\$i) { return \$i * 1000; }, $list)) }}
</syntaxhighlight>

:※ 템플릿 컴파일러가 내부적으로 쓰는 로컬 변수는 <code>$__tmp</code>처럼 '''언더바 두 개로 시작'''하는 것이 많다. 충돌을 피하려면 그런 이름은 쓰지 말자.<ref name="v2" />

=== 출력 필터 ===
v1과 같은 출력 필터를 지원하며, <code>|</code> 좌우에 공백을 허용하는 점이 다르다. 필터명과 옵션은 <code>:</code>로 구분한다.

<syntaxhighlight lang="html">
{{ $var|lower|escape }}
{{ $timestamp|date:'n/j H:i' }}
</syntaxhighlight>

{| class="wikitable"
! 필터 !! 기능 !! 옵션
|-
| autoescape || 자동 escape (이중 인코딩 안 함) ||
|-
| autolang || 자동 escape하되 언어코드는 escape하지 않음 ||
|-
| escape || 강제 escape (이중 인코딩) ||
|-
| escapejs || JS 문자열에 넣을 수 있는 형태로 escape ||
|-
| noescape || escape하지 않음 ||
|-
| json || JSON으로 인코딩 (<code>@json</code> 권장) ||
|-
| strip / strip_tags || <code>strip_tags()</code> ||
|-
| trim || <code>trim()</code> ||
|-
| urlencode || <code>rawurlencode()</code> ||
|-
| lower / upper || 대소문자 변환 ||
|-
| nl2br || 개행을 <code><nowiki><br></nowiki></code>로 변환 ||
|-
| join || 배열을 문자열로 합침 || 구분자 (기본 <code>,</code>)
|-
| date || 타임스탬프 포맷 || 포맷 (기본 <code>Y-m-d H:i:s</code>)
|-
| format / number_format || 천 단위 쉼표 || 소수점 자릿수 (기본 0)
|-
| shorten / number_shorten || <code>123.4K</code> 형태로 표시 || 소수점 자릿수 (기본 2)
|-
| link || 문자열을 링크로 표시 || 링크 텍스트
|}

<code>|</code>를 필터가 아닌 뜻으로 쓸 때는 <code>||</code> 연산자, 문자열 안의 <code>'|'</code>, <code>\|</code> 이스케이프 세 가지만 허용된다.<ref name="v2" />

== 조건문과 루프문 ==
PHP의 대체 문법(alternative syntax)에 <code>@</code>를 붙인 형태가 원칙이다. <code>@if</code>와 괄호 사이를 띄어도 되고, <code>@endif</code>를 <code>@end</code>로 줄여도 된다.

<syntaxhighlight lang="html">
@if ($condition1)
<div class="foo"></div>
@elseif ($condition2)
<div class="bar"></div>
@else
<div class="baz"></div>
@endif
</syntaxhighlight>

{{인용문|괄호를 쓰는 Blade 스타일 지시자는 모두 정규식(PCRE)으로 해석된다. 복잡한 자료 구조를 즉석에서 선언하거나 문자열 안에 괄호를 넣어 해석을 방해하면 v1의 <code>loop</code>, <code>cond</code> 속성처럼 오작동할 수 있다. 복잡한 자료 구조는 따로 선언한 뒤 변수만 넘기자.}}

=== forelse ===
if문과 foreach문을 결합한 형태로, 배열이 비었을 때 표시할 내용을 쉽게 지정한다. 중간 지시자가 <code>@else</code>가 아니라 '''<code>@empty</code>'''임에 유의해야 한다.

<syntaxhighlight lang="html">
@forelse ($array as $key => $val)
<div class="item">{{ $val->name }}</div>
@empty
<div class="noitem">항목이 없습니다.</div>
@endforelse
</syntaxhighlight>

=== 루프 변수 ===
<code>@foreach</code>, <code>@forelse</code>에서 <code>$loop</code> 변수를 쓸 수 있다.

{| class="wikitable"
! 속성 !! 타입 !! 의미
|-
| <code>$loop->index</code> || int || 현재 인덱스 (0부터)
|-
| <code>$loop->iteration</code> || int || 현재 반복 횟수 (1부터)
|-
| <code>$loop->remaining</code> || int || 남은 횟수
|-
| <code>$loop->count</code> || int || 총 반복 횟수
|-
| <code>$loop->first</code> || bool || 첫 번째 항목인가
|-
| <code>$loop->last</code> || bool || 마지막 항목인가
|-
| <code>$loop->even</code> / <code>odd</code> || bool || 짝수·홀수번째인가
|-
| <code>$loop->depth</code> || int || 중첩 루프의 깊이 (1부터)
|-
| <code>$loop->parent</code> || object 또는 null || 상위 루프 변수
|}

<code>@for</code>, <code>@while</code>, <code>@switch</code>도 지원하며 <code>@continue</code>, <code>@break</code>, <code>@default</code>를 쓸 수 있다.

=== 라이믹스 전용 조건문 ===
Blade 10.x의 조건문은 <code>@hasSection</code>을 제외하고 모두 지원하며, <code>@auth</code>와 <code>@can</code> 등은 라이믹스의 권한 체계에 맞게 재해석되었다. 마치는 지시자는 모두 <code>@end</code>로 줄일 수 있다.<ref name="v2" />

{| class="wikitable"
! 지시자 !! 조건
|-
| <code>@admin</code> || 최고관리자
|-
| <code>@auth</code> || 로그인한 회원
|-
| <code>@auth('admin')</code> || 최고관리자
|-
| <code>@auth('manager')</code> || 게시판 관리자
|-
| <code>@guest</code> || 로그인하지 않음
|-
| <code>@can('view')</code> || <code>$grant->view</code> 권한 있음
|-
| <code>@cannot('view')</code> || 해당 권한 없음
|-
| <code>@canany(['view', 'write_comment'])</code> || 나열한 권한 중 하나 이상 있음
|-
| <code>@desktop</code> || PC
|-
| <code>@mobile</code> || 모바일
|-
| <code>@isset($foo)</code> / <code>@unset($foo)</code> / <code>@empty($foo)</code> || Context 변수의 존재 여부
|-
| <code>@env('foo')</code> || 환경변수 존재
|}

:※ <code>@mobile</code>의 판정 기준이 바뀌었다. '''2.1.21 이전'''은 모바일 뷰 설정과 <code>m</code> 파라미터의 영향을 받았지만, '''2.1.22 이후'''는 접속한 User-Agent와 "태블릿도 모바일 취급" 설정만 따른다.<ref name="v2" />

== 템플릿 인클루드 ==
경로는 현재 파일 기준 상대경로이다. 여러 디렉터리를 거슬러 올라가야 한다면 <code>^</code>로 라이믹스 설치 디렉터리 기준 경로를 쓸 수 있다. 리소스 로딩에서도 마찬가지다.

<syntaxhighlight lang="html">
@include ('dir/filename')
@include ('^/common/tpl/default_layout')
</syntaxhighlight>

=== 조건부 인클루드 ===
* <code>@includeIf</code> — 파일이 있을 때만 인클루드하고, 없어도 오류를 내지 않는다
* <code>@includeWhen</code> — 조건이 참일 때만
* <code>@includeUnless</code> — 조건이 거짓일 때만

=== 변수 전달과 컴포넌트 ===
인클루드할 때 연관배열이나 오브젝트를 함께 넘기면, '''인클루드된 템플릿은 <code>Context</code>를 참조하지 않고 전달받은 데이터만 쓴다.''' 없는 키를 참조하면 경고가 발생한다. 이를 이용해 외부 변수에 영향받지 않는 독립적인 컴포넌트를 만들 수 있다.<ref name="v2" />

<syntaxhighlight lang="html">
@include ('B', ['title' => '제목', 'content' => '내용'])
</syntaxhighlight>

자식 템플릿은 부모의 변수를 상속받으며, 직접 전달받은 변수가 우선한다. 다만 인클루드된 템플릿이 <code>Context::get()</code>으로 외부 데이터에 접근하는 것을 막지는 않는다. 그런 시도가 눈에 잘 띄게 될 뿐이다.<ref name="v2" />

== 리소스 로딩 ==
<code><nowiki><script></nowiki></code>나 <code><nowiki><link></nowiki></code>로 직접 불러올 수도 있지만, <code>@load</code>로 코어에 맡기면 CSS·JS 압축 및 합치기와 자동 연동되고, SCSS·LESS가 자동 컴파일되며, 로딩 순서 조절과 언로딩이 가능하다.<ref name="v2" />

<syntaxhighlight lang="html">
@load ('styles.css')
@load ('styles.css', 'print', 20)
@load ('css/styles.scss', $vars)
</syntaxhighlight>

파라미터 순서는 파일명, media, 로딩 순서, 변수이다. media와 로딩 순서는 생략할 수 있으나 각각 문자열과 정수여야 하며 변수를 쓸 수 없다.

JS도 같은 문법이되 <code>media</code> 대신 <code>type</code>을 넘기며, 변수 전달 기능은 없다. <code>head</code>(기본값)는 본문 로딩 전, <code>body</code>는 본문 로딩 후 실행된다.

v1 호환 문법은 각 파라미터의 역할이 더 분명하게 드러나므로 굳이 피할 필요는 없다.<ref name="v2" />

<syntaxhighlight lang="html">
<load src="^/modules/foo/bar/styles.scss" media="screen" vars="$vars" />
<load target="../../../styles.css" index="-3" />
</syntaxhighlight>

== HTML 속성 도우미 ==
=== @class와 @style ===
배열을 넘기면 단순 값은 그대로, 키/값 형태는 값이 참일 때만 출력된다.

<syntaxhighlight lang="html">
<div @class([
'project-item',
'project-complete' => $is_complete,
'featured' => $is_featured,
])></div>
</syntaxhighlight>

<code>@style</code>도 같은 방식이지만, 꼭 필요한 경우가 아니면 스타일은 별도 CSS·SCSS 파일에 쓰는 것이 권장된다.<ref name="v2" />

=== 불리언 속성 ===
<code>@checked</code>, <code>@selected</code>, <code>@disabled</code>, <code>@readonly</code>, <code>@required</code>를 쓸 수 있다.

<syntaxhighlight lang="html">
<input type="checkbox" @checked($is_checked)>
<option value="1" @selected($val == 1)>ONE</option>
</syntaxhighlight>

지원하지 않는 속성에 조건을 걸어야 한다면 v1의 <code>|cond=""</code> 문법이나 if문을 쓴다.

== PHP 코드와 주석 ==
<syntaxhighlight lang="html">
@php
Hello::world();
$foo = 'bar';
@endphp
</syntaxhighlight>

v1의 <code>{@ ... }</code> 문법도 쓸 수 있으나 중괄호가 포함된 코드는 작성할 수 없다.

일반 HTML 주석은 결과물에 그대로 출력된다. 출력되지 않는 주석은 다음과 같이 쓴다.

<syntaxhighlight lang="html">
{{-- 이 주석은 출력되지 않습니다 --}}

</syntaxhighlight>

== 그 밖의 지시자 ==
{| class="wikitable"
! 지시자 !! 기능
|-
| <code>@use</code> || 긴 클래스명을 alias로 줄여 쓴다
|-
| <code>@csrf</code> || 폼에 CSRF 토큰 필드를 자동 주입한다
|-
| <code>@json</code> || JSON으로 출력한다
|-
| <code>@lang('msg_file_not_found')</code> || 번역문을 불러온다. <code>@lang('file.msg_...')</code>처럼 모듈을 지정할 수도 있다
|-
| <code>@url('act', 'dispMemberInfo')</code> || URL을 생성한다. 배열로 넘길 수도 있다
|-
| <code>@widget('content', $args)</code> || 위젯을 삽입한다
|-
| <code>@dump</code> / <code>@dd</code> || 변수를 출력한다. <code>@dd</code>는 출력 후 중단한다
|-
| <code>@once ... @endonce</code> || 한 번만 실행한다
|-
| <code>@error ... @enderror</code> || 오류 처리
|-
| <code>@verbatim ... @endverbatim</code> || 안쪽의 지시자를 해석하지 않고 그대로 출력한다
|-
| <code>@push</code> / <code>@prepend</code> / <code>@stack</code> || 여러 곳에서 모은 내용을 한 지점에 출력한다
|-
| <code>@fragment ... @endfragment</code> || 템플릿의 일부만 잘라내어 렌더링한다
|}

== 미지원 기능 ==
Blade 10.x의 기능 중 '''템플릿 상속과 컴포넌트화 관련 지시자는 적용되지 않았다.''' <code>@extends</code>, <code>@yield</code>, <code>@section</code>, <code>@show</code>, <code>@inject</code>, <code>@slot</code> 등이 여기에 해당한다.<ref name="v2" />

공식 문서가 밝힌 이유는 이렇다. 하나의 개발팀이 하나의 코드베이스를 관리한다고 가정하는 대다수 웹 프레임워크와 달리, 라이믹스는 각 모듈과 스킨을 독립적으로 개발하고 배포할 수 있어야 한다. 전문 개발자가 아닌 사용자와 자료 제작자가 많은데, 스킨에서 쓸 컴포넌트 하나를 만들려고 별도 <code>.php</code> 파일에서 클래스를 선언하거나 터미널에서 명령을 실행해야 하는 개발 방식은 받아들이기 곤란하다는 것이다.<ref name="v2" />

따라서 Laravel Blade의 컴포넌트 설계는 라이믹스와 맞지 않다고 판단하여, 적절한 대안이 마련될 때까지 적용을 보류하였다. 대신 [[#변수 전달과 컴포넌트|인클루드시 변수 전달]] 기능으로 상당히 독립적인 컴포넌트를 구현할 수 있으며, 복잡한 기능이 필요하다면 위젯을 활용하는 것이 권장된다.<ref name="v2" />

== 같이 보기 ==

* [[라이믹스/매뉴얼]]
* [[라이믹스/릴리즈 노트/2.1.8]]
* [[라이믹스/매뉴얼/라이믹스 프레임워크]] — Template 클래스
* [[라이믹스/버전]]

== 출처 ==
이 문서는 라이믹스 공식 매뉴얼의 [https://rhymix.org/manual/theme/template_v2 템플릿 문법 v2] 문서를 바탕으로 작성되었다. 공식 매뉴얼은 CC BY-SA 4.0 라이선스로 배포된다.<ref name="docs-license">[https://github.com/rhymix/rhymix-docs rhymix-docs 저장소] README에 "이 매뉴얼은 CC-BY-SA 4.0 라이선스에 따라 배포됩니다"라고 명시되어 있다.</ref>

전체 지시자 목록과 상세한 예제는 공식 매뉴얼을 참고하자.

== 각주 ==
<references />


[[분류:라이믹스]] [[분류:라이믹스/매뉴얼]]

라이믹스/매뉴얼/설치 환경

2026-08-21T05:59:47Z

Gaon12: MariaDB 최소 버전을 10.1에서 10.6으로 정정(공식 요구사항 기준). PHP 8.2 권장 명시, 출처 각주 추가

== 개요 ==
[[라이믹스]]를 설치하고 운영하기 위해 필요한 시스템 요구사항을 정리한 문서입니다. 기본적으로 웹 서버(예: Apache, Nginx) 같은 필수 요소는 당연히 있어야 하니 여기선 생략했습니다.<ref>웹 서버가 없으면 PHP 파일을 실행할 수 없기 때문.</ref>

== 퍼미션 ==
라이믹스 설치 루트 폴더 안의 '''files''' 폴더 퍼미션은 707 또는 777로 설정해야 합니다. 설치 경로에 쓰기 권한이 있으면 설치 중 자동으로 files 폴더가 생성되지만, 권한이 없으면 직접 폴더를 만들고 퍼미션을 조정해야 합니다.

== PHP ==
=== 버전 ===
[[라이믹스]] 설치에는 PHP 7.4 이상이 필요하며, PHP 8.2 이상을 권장합니다.<ref name="requirements" />

==== PHP 7.2 이상에서의 문제 ====
PHP 7.2 이상에서는 일부 서드파티 모듈 때문에 '''BaseObject''' 오류가 발생할 수 있습니다. 기존에 사용되던 <code>Object</code> 클래스가 PHP 7.2부터 지원되지 않아 'Fatal error'(HTTP 500 오류)가 뜨는 경우가 생깁니다.
이 문제는 [[XpressEngine|XE]]에서도 공통적으로 나타나는 현상으로, [https://www.xpressengine.com/devlog/23249915 XE 공식 공지]에 따르면 <code>Object</code>를 <code>BaseObject</code>로 바꿔야 해결됩니다.<del>손이 좀 가는 작업</del> 에디터에서 찾아바꾸기 기능을 활용하면 편리합니다.<ref>단, 'new Object'나 'extends Object'처럼 앞에 다른 단어가 붙은 경우만 변경해야 함. [https://xetown.com/questions/1164680#comment_1164942 기진곰님 댓글 참고]</ref>

리눅스 환경이라면 아래 명령어로 쉽게 일괄 변경 가능합니다.
<syntaxhighlight lang="console">
root@gaon:/var/www/html/# find ./ -name "*.php" -exec sed -i 's/return\snew\sObject/return new BaseObject/g' {} \;
root@gaon:/var/www/html/# find ./ -name "*.php" -exec sed -i 's/extends\sObject/extends BaseObject/g' {} \;
</syntaxhighlight>
다만, [[XpressEngine/모듈/타임라인|타임라인]] 모듈처럼 예외적인 경우는 명령어가 적용되지 않을 수 있으니, 이런 경우엔 직접 수정해야 합니다. 타임라인 모듈이라면 <code>./modules/timeline/timeline.admin.model.php</code> 파일의 44번째 줄에서 <code>Object</code>를 <code>BaseObject</code>로 바꾸면 됩니다.

=== 필수 PHP 모듈 ===
라이믹스 설치에 반드시 필요한 PHP 모듈은 다음과 같습니다:
* <code>curl</code>
* <code>gd</code>
* <code>iconv</code> 또는 <code>mbstring</code>
* <code>json</code>
* <code>openssl</code>
* <code>PDO_MySQL</code>
* <code>SimpleXML</code>
* <code>Zend OPCache</code>

=== 권장 PHP 모듈 ===
설치는 필수가 아니지만 성능 개선이나 특정 기능에 유용한 모듈들입니다:
* <code>apcu</code> (캐시로 성능 향상)
* <code>exif</code> (이미지 자동 회전)
* <code>fileinfo</code> (첨부파일 보안 검사)
* <code>intl</code> (한글 도메인 처리 효율성)
* <code>zip</code> (향후 필수로 바뀔 가능성 있음)
* <code>mod_rewrite</code> (Apache에서 짧은 주소 사용 시, 선택 사항)

=== php.ini 설정 ===
* '''<code>upload_max_filesize</code> < <code>post_max_size</code> < <code>memory_limit</code>''' 순으로 설정값이 커야 합니다.<ref>[[라이믹스/XE와의 차이점#대용량 업로드|대용량 업로드]] 지원 때문에 업로드 용량이 10MB 이상이면 제한이 거의 없음.</ref>
* <code>session.auto_start</code>는 반드시 꺼져 있어야 합니다:
<syntaxhighlight lang="ini">
session.auto_start = off
</syntaxhighlight>
* <code>memory_limit</code>은 최소 128M 이상으로 설정되어 있어야 합니다.

== MySQL/MariaDB ==
MySQL은 5.7 이상, MariaDB는 10.6 이상이 필요합니다.<ref name="requirements">[https://rhymix.org/manual/introduction/requirements 설치 환경 - 라이믹스 매뉴얼]</ref>

과거 공식 문서에서는 MariaDB 10.1 이상을 권장했으나, 현재 기준은 10.6 이상으로 상향되었습니다. 스토리지 엔진은 InnoDB, 문자 인코딩은 utf8mb4를 사용해야 4바이트 문자(이모지 등)를 저장할 수 있습니다.

== 각주 ==
<references />

== 같이 보기 ==

* [[라이믹스]]
* [[라이믹스/설치]]
* [[라이믹스/매뉴얼]]


[[분류:라이믹스]] [[분류:라이믹스/매뉴얼]]

라이믹스/매뉴얼/서드파티 자료 호환성 체크리스트

2026-08-21T05:59:44Z

Gaon12: 새 문서. XE에서 이전할 때 점검할 서드파티 자료 정리

{{틀:상위문서|라이믹스/매뉴얼}}

== 개요 ==
[[XpressEngine|XE 1.x]]에서 [[라이믹스]]로 옮긴 뒤 점검해야 할 서드파티 자료를 정리한 문서이다.<ref name="checklist">[https://rhymix.org/manual/introduction/thirdparty-checklist 서드파티 자료 호환성 체크리스트 - 라이믹스 매뉴얼]</ref>

XE의 모듈, 애드온, 레이아웃, 위젯은 대부분 라이믹스에서 그대로 동작한다. 다만 XE 시절 별도 자료로 쓰이던 기능 가운데 상당수가 라이믹스 코어에 흡수되었기 때문에, 이전 후에는 해당 자료를 제거하고 관리자 화면에서 설정을 다시 확인해야 한다.

이전 절차 자체는 [[라이믹스/XE에서 넘어오기]] 문서를, 차단된 자료 목록은 [[라이믹스/블랙리스트]] 문서를 참고하자.

== 코어에 흡수된 기능 ==
{| class="wikitable"
! XE 시절 자료 !! 라이믹스에서의 위치 !! 확인할 점
|-
| 고급 메일러 모듈
| 시스템 설정 → 알림
| 외부 API와 SMTP 발송 기능이 코어로 흡수되었다. 기존 설정은 자동 변환되지만 발송 방식이 제대로 잡혀 있는지 확인해야 한다
|-
| 자동 로그인 모듈
| 코어 기능
| 각 회원이 회원정보 화면에서 자동 로그인 기기를 직접 관리한다. '''업그레이드 후 기존 세션이 만료되므로 전 회원이 다시 로그인해야 한다'''
|-
| 멀티도메인 모듈
| 시스템 설정 → 사이트 설정
| 도메인 설정이 자동 변환된다. 모든 도메인이 정확히 옮겨졌는지 확인하자
|-
| SEO 모듈
| 시스템 설정 → SEO 설정
|
|-
| 오류 기록 모듈
| 시스템 설정 → 디버그 설정
| 오류와 성능 정보를 이곳에서 확인할 수 있다
|}

== 지원하지 않는 자료 ==
{| class="wikitable"
! 자료 !! 상태 !! 대응
|-
| 홈페이지·카페 모듈
| 멀티도메인 기능과 충돌하여 지원하지 않는다
| 이 기능이 꼭 필요하다면 XE 1.x에 남는 편이 낫다
|-
| CAPTCHA · CAPTCHA Member 애드온
| 최근 라이믹스에서 동작하지 않는다
| recaptcha 애드온으로 이전
|-
| reCAPTCHA 애드온
| XE타운 배포판이 라이믹스 내장 버전으로 대체될 수 있다
| 설정과 비밀 키가 그대로인지 확인
|-
| jQuery CDN 관련 애드온
| 외부 CDN을 통한 로드를 지원하지 않는다
| 스크립트 호환성을 유지하기 위한 조치이다
|-
| 회원 커뮤니케이션 애드온
| 커뮤니케이션 모듈에 통합되었다
| 별도 설치가 필요 없다
|-
| 모바일 XE 애드온
| 더 이상 사용되지 않는다
|
|}

== 이전 후 점검 항목 ==
공식 문서가 안내하는 확인 사항이다.<ref name="checklist" />

* 메일 발송 설정이 올바르게 표시되는지
* 모든 도메인이 정확히 변환되었는지
* reCAPTCHA 설정과 비밀 키가 정상 동작하는지
* 세션 보안 옵션이 적절히 설정되었는지
* 스크립트 압축 설정 조정이 필요한지

이 밖에 다음 항목도 함께 확인하는 것이 좋다.

* 자동 로그인이 정상 동작하는지 (기존 세션은 만료된다)
* 게시판, 회원, 포인트, 커뮤니케이션 등 주요 모듈이 정상인지
* 더 이상 필요 없어진 오래된 애드온이 켜져 있지는 않은지
* PHP 8.x 환경에서 경고나 오류가 나오지 않는지

== 코어 파일을 수정하는 자료 ==
라이믹스는 XE와 외부 구조는 같지만 내부 구조가 크게 달라졌다. 따라서 '''XE의 코어 파일을 직접 고치는 방식의 자료는 정상 동작하지 않을 수 있다.''' 동작하지 않는 정도를 넘어 라이믹스의 다른 기능을 방해하는 자료는 블랙리스트로 차단된다.

== 같이 보기 ==

* [[라이믹스/매뉴얼]]
* [[라이믹스/XE에서 넘어오기]]
* [[라이믹스/XE와의 차이점]]
* [[라이믹스/블랙리스트]]
* [[라이믹스/애드온]]

== 각주 ==
<references />


[[분류:라이믹스]] [[분류:라이믹스/매뉴얼]]

라이믹스/매뉴얼/라이믹스 프레임워크

2026-08-21T05:59:40Z

Gaon12: 새 문서. 코어·예외·필터·레거시 클래스와 공통 상수 정리

{{틀:상위문서|라이믹스/매뉴얼}}

== 개요 ==
'''라이믹스 프레임워크'''는 모듈과 테마 등을 구동하는 핵심 기능을 제공하는 부분이다. 일부 기능은 모듈에 위임하지만, 프레임워크에 포함된 대부분의 클래스와 함수는 특정 모듈에 종속되지 않고 독립적으로 쓸 수 있다.<ref name="framework">[https://rhymix.org/manual/reference/framework 라이믹스 프레임워크 - 라이믹스 매뉴얼]</ref>

크게 네 부분으로 이루어져 있다.<ref name="framework" />

# <code>Rhymix\Framework</code> 네임스페이스에 속한 클래스
# [[XpressEngine|XE 1.x]]에서 물려받은 레거시 전역 클래스
# 전역 함수
# 공통 상수

레거시 클래스는 서드파티 자료의 하위 호환성을 위해 남아 있으나 점차 <code>Rhymix\Framework</code>로 흡수되고 있으며, 이미 껍데기만 남아 별칭 역할만 하는 것도 있다. '''장기적으로 <code>Context</code>를 제외한 모든 전역 클래스는 지원이 중단될 예정이다.'''<ref name="framework" />

== 코어 클래스 ==
<code>Rhymix\Framework</code> 네임스페이스에 속한 클래스이다. 이름 뒤에 (*)가 붙은 것은 인스턴스를 만들어 사용하고, 나머지는 <code>static</code>으로 사용한다.<ref name="framework" />

{| class="wikitable"
! 클래스 !! 설명
|-
| Cache || 처리 속도 향상을 위한 캐시 처리
|-
| Calendar || 달력 UI 제작에 쓰는 유틸리티 함수
|-
| Config || 시스템 설정의 로딩, 변환, 저장
|-
| Cookie || 쿠키 생성과 조회
|-
| DateTime || 날짜·시간 형식 변환과 표준 시간대 처리
|-
| DB (*) || DB 접속과 관리, XML 쿼리 및 커스텀 쿼리 실행
|-
| Debug || 디버그 관련 기능
|-
| Exception (*) || 라이믹스 공통 예외 클래스. <code>\Exception</code>을 상속한다
|-
| Formatter || 텍스트와 HTML의 상호 변환, SCSS 컴파일, 압축 및 합치기
|-
| HTTP || API 호출, 크롤링, 파일 다운로드 등 외부 리소스 가져오기
|-
| i18n || 표준화된 국가 및 언어 목록 제공
|-
| Image || 이미지 포맷 감지 및 변환
|-
| Korea || 국내 전화번호 유효성 확인과 형식 변환 등
|-
| Lang (*) || 다국어 기능
|-
| Mail (*) || 이메일 발송
|-
| MIME || 파일 타입 파악과 확장자 처리
|-
| Pagination || 페이지 분할 유틸리티
|-
| Password || 여러 형식의 비밀번호 암호화와 검증
|-
| Push (*) || 푸시 알림 발송
|-
| Queue || 비동기 작업의 생성, 관리, 실행. 실행에는 크론 설정이 필요하다. [[라이믹스/매뉴얼/Crontab 설정 방법]] 참고
|-
| Request (*) || 하나의 HTTP 요청을 표현. <code>Router</code>가 이 클래스의 인스턴스를 반환한다
|-
| Router || 짧은주소 처리. [[라이믹스/라우터]] 문서 참고
|-
| Security || 랜덤 문자열 생성, 암호화, 전자서명, CSRF 방어
|-
| Session || 세션 처리
|-
| SMS (*) || SMS 발송
|-
| Storage || 파일과 디렉터리를 안전하게 다루는 유틸리티
|-
| Template (*) || 템플릿 로딩, 컴파일, 출력. [[라이믹스/매뉴얼/템플릿 문법 v2]] 참고
|-
| Timer || 작업 소요 시간 측정
|-
| UA || <code>User-Agent</code> 해석과 그에 따른 구분
|-
| URL || URL 해석과 변환
|}

== 예외 클래스 ==
<code>Rhymix\Framework\Exceptions</code> 네임스페이스에 있다. 모두 <code>Rhymix\Framework\Exception</code>을 상속하며 용도에 따라 골라 쓴다.<ref name="framework" />

{| class="wikitable"
! 클래스 !! 용도
|-
| DBError || DB 접속 오류 등
|-
| FeatureDisabled || 사용할 수 없는 기능
|-
| InvalidRequest || 잘못된 요청
|-
| MustLogin || 로그인이 필요함
|-
| NotPermitted || 권한이 없음
|-
| QueryError || DB 쿼리 오류
|-
| SecurityViolation || 보안 정책상 허용되지 않음
|-
| TargetNotFound || 대상을 찾을 수 없음
|}

== 필터 클래스 ==
<code>Rhymix\Framework\Filters</code> 네임스페이스에 있다. 신뢰할 수 없는 외부 입력값을 처리하는 최전방에 위치하여 라이믹스의 보안에서 핵심적인 역할을 한다.<ref name="framework" />

{| class="wikitable"
! 클래스 !! 역할
|-
| FileContentFilter || 업로드된 파일의 내용에 따른 상세 필터링
|-
| FilenameFilter || 파일명 필터링
|-
| HTMLFilter || XSS 방지를 위한 HTML 태그 및 속성 필터링
|-
| IpFilter || IP 주소 필터링 (허용·차단 목록)
|-
| MediaFilter || iframe 등으로 본문에 삽입된 외부 미디어의 URL 필터링
|}

== 그 밖의 네임스페이스 ==
* <code>Rhymix\Framework\Drivers</code> — 메일, SMS 발송이나 서버 환경별 캐시 사용을 위한 드라이버가 용도별로 분류되어 있다.
* <code>Rhymix\Framework\Helpers</code> — 프레임워크의 다른 영역에서 필요할 때 임의로 선언하여 쓰는 도우미 클래스.
* <code>Rhymix\Framework\Parsers</code> — 템플릿과 쿼리를 비롯한 여러 파일을 해석하여 적절한 형태로 변환한다.<ref name="framework" />

== 레거시 클래스 ==
XE 1.x부터 존재해 온 전역 클래스이다.<ref name="legacy">[https://rhymix.org/manual/reference/legacy 레거시 클래스 - 라이믹스 매뉴얼]</ref>

{| class="wikitable"
! 클래스 !! 설명
|-
| BaseObject || 모듈, DB 쿼리, 이벤트 핸들러 등의 반환값을 담는 데 사용
|-
| Context || 요청의 전반적인 환경 관리, 전역변수 관리, 응답 작성 메소드 제공
|-
| FrontEndFileHandler || HTML 응답에 사용할 CSS, JS 리소스 관리
|-
| ModuleHandler || 모듈 라이프사이클 관리
|-
| ModuleObject || 모든 모듈 클래스의 기초가 되는 클래스
|-
| DisplayHandler || 응답 렌더링
|-
| FileHandler || 대부분 <code>Storage</code>로 대체 가능하나 일부 기능이 유지되고 있다
|-
| Mobile || 대부분 <code>UA</code>로 대체 가능하나 일부 기능이 유지되고 있다
|}

:※ <code>BaseObject</code>는 PHP 7.2부터 <code>Object</code>가 예약어가 되면서 이름이 바뀐 것이다. 오래된 서드파티 자료에서 발생하는 관련 오류는 [[라이믹스/매뉴얼/설치 환경#PHP 7.2 이상에서의 문제|설치 환경]] 문서를 참고하자.

== 공통 상수 ==
=== 실행 환경 ===
설치 경로, 버전, 접속 환경 정보가 필요할 때는 다른 파일을 해석하거나 <code>$_SERVER</code> 같은 전역변수를 참조하기보다 아래 상수를 쓰는 것이 권장된다.<ref name="framework" />

{| class="wikitable"
! 상수 !! 설명
|-
| <code>RX_VERSION</code> || 라이믹스 버전
|-
| <code>RX_MICROTIME</code> || 실행 시작 시간 (유닉스 타임스탬프, 마이크로초까지)
|-
| <code>RX_TIME</code> || 실행 시작 시간 (유닉스 타임스탬프, 정수)
|-
| <code>RX_BASEDIR</code> || 설치된 서버 파일시스템 절대경로 (마지막 슬래시 있음)
|-
| <code>RX_BASEURL</code> || 설치된 URL의 절대경로 (마지막 슬래시 있음)
|-
| <code>RX_REQUEST_URL</code> || 현재 요청 URL에서 <code>RX_BASEURL</code>을 제외한 나머지
|-
| <code>RX_CLIENT_IP</code> || 현재 방문자의 IP 주소
|-
| <code>RX_CLIENT_IP_VERSION</code> || 방문자 IP가 IPv4면 <code>4</code>, IPv6면 <code>6</code>
|-
| <code>RX_SSL</code> || 현재 요청이 SSL/TLS를 사용하면 <code>true</code>
|-
| <code>RX_POST</code> || 현재 요청이 POST면 <code>true</code>
|-
| <code>RX_WINDOWS</code> || 윈도우 서버면 <code>true</code>
|}

=== 문서 상태값 ===
문서나 댓글의 상태를 표현하는 값이다. 현재 <code>PUBLIC</code>과 <code>SECRET</code>이 코어에 구현되어 있고, 나머지는 서드파티 자료가 공통으로 쓰도록 미리 선언해 둔 표준이다.<ref name="framework" />

{| class="wikitable"
! 상수 !! 값 !! 상수 !! 값
|-
| <code>RX_STATUS_TEMP</code> || 0 || <code>RX_STATUS_CENSORED</code> || 5
|-
| <code>RX_STATUS_PUBLIC</code> || 1 || <code>RX_STATUS_CENSORED_BY_ADMIN</code> || 6
|-
| <code>RX_STATUS_SECRET</code> || 2 || <code>RX_STATUS_DELETED</code> || 7
|-
| <code>RX_STATUS_EMBARGO</code> || 3 || <code>RX_STATUS_DELETED_BY_ADMIN</code> || 8
|-
| <code>RX_STATUS_TRASH</code> || 4 || <code>RX_STATUS_OTHER</code> || 9
|-
| <code>RX_STATUS_PRIVATE</code> || 10 || ||
|}

이 밖에 <code>DIGITS</code>, <code>XDIGITS</code>, <code>ALPHABETS</code>, <code>UPPER</code>, <code>LOWER</code> 같은 문자 범위 상수와 <code>CR</code>, <code>LF</code>, <code>CRLF</code> 개행 문자 상수가 선언되어 있다.<ref name="framework" />

=== XE 호환용 상수 ===
<code>__XE__</code>, <code>__XE_VERSION__</code>, <code>_XE_PATH_</code>, <code>Y</code>, <code>N</code> 등 XE 시절의 상수도 호환을 위해 제공되지만, '''더 이상 사용하지 않는 것이 권장된다.'''<ref name="framework" />

== 같이 보기 ==

* [[라이믹스/매뉴얼]]
* [[라이믹스/라우터]]
* [[라이믹스/애드온]]
* [[라이믹스/매뉴얼/설치 환경]]

== 각주 ==
<references />


[[분류:라이믹스]] [[분류:라이믹스/매뉴얼]]

라이믹스/매뉴얼/라이믹스 설치

2026-08-21T05:59:38Z

Gaon12: 넘겨주기 생성. 정본 문서인 라이믹스/설치로 연결

#넘겨주기 [[라이믹스/설치]]

라이믹스/매뉴얼/nginx 설정 방법

2026-08-21T05:59:35Z

Gaon12: 새 문서. nginx rewrite 설정 방법

{{틀:상위문서|라이믹스/매뉴얼}}

== 개요 ==
아파치는 라이믹스에 포함된 <code>.htaccess</code> 파일만으로 짧은주소를 쓸 수 있지만, nginx는 <code>.htaccess</code>를 통한 설정 변경을 지원하지 않으므로 서버 설정을 직접 손봐야 한다.<ref name="nginx">[https://rhymix.org/manual/introduction/nginx nginx 설정 방법 - 라이믹스 매뉴얼]</ref>

== rewrite 규칙 내려받기 ==
라이믹스가 제공하는 rewrite 규칙 파일을 <code>snippets</code> 폴더에 넣어 두고 사이트 설정에서 인클루드하는 방식이 편하다.

<syntaxhighlight lang="console">
curl https://raw.githubusercontent.com/rhymix/rhymix/master/common/manual/server_config/rhymix-nginx.conf > /etc/nginx/snippets/rhymix.conf
</syntaxhighlight>

== 사이트 설정 ==
Ubuntu는 <code>/etc/nginx/sites-enabled/default</code>, CentOS는 <code>/etc/nginx/conf.d/default.conf</code>에 기본 설정 파일이 생성된다. 이 파일을 고치거나 같은 폴더에 다른 이름의 파일을 만들어 아래 내용을 넣는다.<ref name="nginx" />

<syntaxhighlight lang="nginx">
server {
listen 80 default; # 다른 파일을 만들어 쓰는 경우 default 삭제
root /var/www/html; # 라이믹스를 설치할 경로 (반드시 최상단에 위치해야 한다)
server_name _; # 사용할 도메인을 여기에 적어도 된다
index index.html index.htm index.php; # index.php가 반드시 포함되어야 한다
client_max_body_size 32m; # 업로드 허용 용량

include snippets/rhymix.conf; # 라이믹스 rewrite 규칙 인클루드

# location 구문을 쓰는 다른 설정은 반드시 rewrite 규칙보다 나중에 선언해야 한다
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.2-fpm.sock; # 유닉스 소켓으로 연동하는 경우
include snippets/fastcgi-php.conf;
}
}
</syntaxhighlight>

주의할 점이 세 가지 있다.<ref name="nginx" />

* <code>root</code>는 반드시 <code>server</code> 블록 최상단에 있어야 한다.
* <code>index</code>에 <code>index.php</code>가 포함되어야 한다.
* '''<code>location</code>을 쓰는 다른 설정은 라이믹스 rewrite 규칙보다 뒤에 와야 한다.'''

라이믹스는 분할 업로드를 지원하므로 <code>client_max_body_size</code>가 10MB 정도만 넘으면 업로드 용량은 사실상 제한이 없어진다.<ref name="nginx" />

=== 라이믹스 2.0 이상에서의 주의 ===
'''라이믹스 2.0부터는 rewrite 규칙 안에 <code>location / { try_files ... }</code> 블록이 이미 포함되어 있다.''' 사이트 설정에 같은 블록을 또 넣으면 오류가 발생하므로 넣지 말아야 한다.<ref name="nginx" />

== PHP-FPM 연동 경로 확인 ==
PHP 버전에 따라 소켓 경로가 달라진다. 아래 명령으로 확인할 수 있다.<ref name="nginx" />

<syntaxhighlight lang="console">
# Ubuntu 계열
grep -r "listen =" /etc/php/8.2/fpm/pool.d

# CentOS 계열
grep -r "listen =" /etc/php-fpm.d
</syntaxhighlight>

로컬 포트로 연동하는 경우에는 소켓 대신 <code>fastcgi_pass 127.0.0.1:9000;</code>을 사용한다.

== 배포판별 참고 ==
=== Ubuntu ===
비교적 최신 버전의 nginx가 패키지로 제공되므로 그대로 설치하면 된다.

<syntaxhighlight lang="console">
apt-get install nginx
</syntaxhighlight>

최근 Ubuntu에서는 잡다한 설정 파일을 <code>/etc/nginx/snippets</code> 폴더에 넣는 것이 관례이다.<ref name="nginx" />

=== CentOS ===
기본 제공되는 nginx 버전이 낮으므로 [https://nginx.org/en/linux_packages.html nginx 공식 홈페이지]의 RPM 저장소를 사용해 최신 버전을 설치하는 것이 좋다.

CentOS에는 <code>snippets</code> 폴더 관례가 없지만, <code>conf.d</code> 폴더에 rewrite 규칙을 넣으면 인클루드 순서가 어긋나 오류가 날 수 있다. Ubuntu처럼 <code>snippets</code> 폴더를 만들어 쓰는 편이 낫다.<ref name="nginx" />

== 적용과 확인 ==
설정을 바꾼 뒤에는 nginx를 다시 시작해야 한다.

<syntaxhighlight lang="console">
nginx -t # 문법 검사
service nginx restart
</syntaxhighlight>

재시작에서 오류가 나면 <code>/var/log/nginx/error.log</code>를 확인하자.<ref name="nginx" />

== 같이 보기 ==

* [[라이믹스/매뉴얼]]
* [[라이믹스/설치]]
* [[라이믹스/매뉴얼/설치 환경]]
* [[라이믹스/라우터]]

== 각주 ==
<references />


[[분류:라이믹스]] [[분류:라이믹스/매뉴얼]]

라이믹스/매뉴얼/XE 1.x에서 업그레이드

2026-08-21T05:59:32Z

Gaon12: 넘겨주기 생성. 정본 문서인 라이믹스/XE에서 넘어오기로 연결

#넘겨주기 [[라이믹스/XE에서 넘어오기]]

라이믹스/매뉴얼/Crontab 설정 방법

2026-08-21T05:59:29Z

Gaon12: 새 문서. 정리 스크립트와 비동기 작업(Queue) 실행 방법

{{틀:상위문서|라이믹스/매뉴얼}}

== 개요 ==
[[라이믹스]]에서 cron을 사용하는 경우는 크게 두 가지이다.

# '''정리 스크립트''' — 쌓인 불필요한 데이터를 정기적으로 지운다. 하루 한 번 정도 실행한다.
# '''비동기 작업(Queue) 실행''' — 메일 발송이나 푸시 알림을 백그라운드에서 처리한다. 1분 간격 등 짧은 주기로 실행한다.

공식 매뉴얼의 Crontab 설정 방법 문서는 앞쪽만 다루므로,<ref name="crontab">[https://rhymix.org/manual/misc/crontab Crontab 설정 방법 - 라이믹스 매뉴얼]</ref> 이 문서에서는 두 가지를 함께 정리한다.

윈도우 서버는 지원하지 않는다.<ref name="crontab" />

== 정리 스크립트 ==
사이트를 운영하다 보면 탈퇴한 회원의 정보, 삭제된 사진의 섬네일, 확인하지 않은 알림 같은 불필요한 데이터가 쌓인다. 이런 데이터를 정기적으로 지우면 디스크 공간을 아끼고 서버를 쾌적하게 유지할 수 있다.<ref name="crontab" />

라이믹스는 이를 위한 PHP-CLI 스크립트를 제공한다. 다량의 데이터를 지우는 데 시간이 오래 걸릴 수 있어 '''웹에서는 실행할 수 없다.'''<ref name="crontab" />

=== 실행 방법 ===
스크립트는 각 모듈의 <code>scripts</code> 폴더에 있으며, 라이믹스 설치 경로에서 다음 형식으로 실행한다.<ref name="crontab" />

<syntaxhighlight lang="console">
php index.php 모듈명.스크립트명 [변수]
</syntaxhighlight>

예를 들어 60일 이상 지난 알림을 지우려면 다음과 같이 실행한다.

<syntaxhighlight lang="console">
php index.php ncenterlite.cleanNotifications 60
</syntaxhighlight>

=== 스크립트 목록 ===
{| class="wikitable"
! 스크립트 !! 하는 일 !! 기본값
|-
| <code>file.cleanGarbageFiles</code>
| 파일만 올리고 글 작성을 취소하여 남은 파일, 대용량 업로드가 중단되어 남은 파일 등을 지운다
| 10일
|-
| <code>file.cleanThumbnails</code>
| 오래된 섬네일 이미지를 지운다
| 90일
|-
| <code>module.cleanMiscLogs</code>
| 메일·SMS 발송 로그, 푸시 발송 로그, 스팸필터 로그 등 여러 모듈이 만드는 잡다한 로그를 일괄 삭제한다
| 30일
|-
| <code>ncenterlite.cleanNotifications</code>
| 오래된 알림을 지운다
|
|-
| <code>file.cleanEmptyDirs</code>
| 첨부파일·회원정보·섬네일 폴더에 남은 빈 폴더를 지운다
|
|}

'''<code>file.cleanThumbnails</code>는 주의해야 한다.''' 오래된 글의 섬네일도 보여줘야 하는 웹진형 게시판을 운영한다면 쓰지 말자. 지운 섬네일을 다시 만드는 데 더 많은 서버 자원이 든다.<ref name="crontab" />

<code>file.cleanGarbageFiles</code>도 주의가 필요하다. 일부 서드파티 자료는 파일 업로드 후 문서에 정상적으로 연결하지 않고 <code>isvalid=N</code> 상태로 방치하는데, 이런 파일이 삭제될 수 있다.<ref name="crontab" />

=== crontab 설정 예제 ===
여러 스크립트를 동시에 실행하면 과부하가 걸릴 수 있으므로, 방문자가 적은 시간대에 시간차를 두고 실행하자. 매일 정해진 시각에 백업한다면 백업 직전에 정리하는 것이 편하다.<ref name="crontab" />

'''빈 폴더를 지우는 스크립트를 맨 마지막에 실행하면 효과적이다.''' 앞선 스크립트들이 파일을 지우면서 빈 폴더가 생기기 때문이다.

<syntaxhighlight lang="text">
05 05 * * * php /설치경로/index.php file.cleanGarbageFiles >> /설치경로/files/cron.log 2>&1
10 05 * * * php /설치경로/index.php file.cleanThumbnails >> /설치경로/files/cron.log 2>&1
15 05 * * * php /설치경로/index.php module.cleanMiscLogs >> /설치경로/files/cron.log 2>&1
15 05 * * * php /설치경로/index.php ncenterlite.cleanNotifications >> /설치경로/files/cron.log 2>&1
20 05 * * * php /설치경로/index.php file.cleanEmptyDirs >> /설치경로/files/cron.log 2>&1
</syntaxhighlight>

== 비동기 작업 실행 ==
라이믹스는 메일 발송, 푸시 알림처럼 시간이 오래 걸리거나 외부 서비스와 연동하는 작업을 비동기로 처리하여 응답 속도를 개선하는 기능을 제공한다. 관리자 화면의 <code>비동기 작업</code> 항목에서 설정한다.

:※ 관리자 화면은 이 기능을 '''실험적인 기능'''으로 안내하고 있다. 호스팅 환경에 따라서는 안정적으로 작동하지 않을 수도 있다.

'''이 기능을 켜기만 해서는 동작하지 않는다.''' 외부 스케줄러가 일정한 주기로 처리 스크립트를 호출해 주어야 한다.

=== 관리자 설정 항목 ===
{| class="wikitable"
! 항목 !! 설명
|-
| 비동기 작업 사용 || 체크를 해제하면 더 이상 작업을 접수하지 않는다
|-
| 비동기 드라이버 || 작업을 관리할 방법. Redis 등 일부 드라이버는 서버에 해당 기능이 설치되어 있어야 한다
|-
| 호출 간격 || 스크립트를 호출할 주기(분). 모든 작업은 호출 간격과 무관하게 실시간으로 처리되지만, 간격이 짧으면 장애 발생 시 빠르게 복구된다
|-
| 프로세스 갯수 || 여러 프로세스를 동시에 실행해 처리 용량을 늘린다. 고성능 단독 서버가 아니라면 1을 유지하는 것이 권장된다
|-
| 웹크론 오류 표시 || 에러 로그를 확인하기 어려운 환경에서 웹크론 오류를 화면에 표시한다
|}

=== crontab으로 실행 ===
처리 스크립트는 <code>common/scripts/cron.php</code>이며, CLI에서는 <code>common.cron</code>이라는 이름으로 호출한다.

<syntaxhighlight lang="text">
* * * * * php /설치경로/index.php common.cron
</syntaxhighlight>

호출 간격을 1분으로 설정했다면 위와 같이 매분 실행한다. 스크립트는 설정한 호출 간격만큼 실행된 뒤 스스로 종료되므로, 앞선 실행이 끝나기 전에 다음 실행이 겹치지 않는다.

=== systemd timer로 실행 ===
crontab 대신 systemd timer를 사용해도 된다. 관리자 화면의 안내도 crontab, systemd timer, 웹크론을 나란히 제시하고 있다.

=== 웹크론으로 실행 ===
SSH를 쓸 수 없는 웹호스팅 환경에서는 외부 웹크론 서비스로 URL을 호출하는 방법을 쓸 수 있다. 정리 스크립트와 달리 이 스크립트는 네트워크를 통한 직접 호출을 지원한다.

<syntaxhighlight lang="text">
https://사이트주소/common/scripts/cron.php?key=발급된키
</syntaxhighlight>

<code>key</code> 값은 관리자 화면의 비동기 작업 설정에서 확인할 수 있다. 키가 맞지 않으면 <code>403 Forbidden</code>과 함께 <code>Invalid key</code>가 반환된다. 정상적으로 처리되면 <code>OK</code>가 출력된다.

웹크론을 쓸 때는 다음을 유의해야 한다.

* '''호출 간격이 php.ini의 실행 시간 제한(<code>max_execution_time</code>)을 넘지 않도록''' 해야 한다. 서버의 현재 값은 관리자 화면에 표시된다.
* '''웹크론으로 호출한 경우에는 멀티프로세싱을 지원하지 않는다.''' 프로세스 갯수를 2 이상으로 설정해도 하나만 실행된다.

== 실행 계정 ==
'''평소 웹서버를 실행하는 계정으로 crontab을 설정해야 한다.''' 보통 <code>apache</code>, <code>nginx</code>, <code>www-data</code> 등이다.<ref name="crontab" />

다른 계정이나 <code>root</code>로 실행하면 나중에 사이트에서 퍼미션 문제가 생기거나 캐시 파일이 꼬일 수 있다. 어느 계정을 써야 할지 모르겠다면 <code>files/config/config.php</code> 파일이나 <code>files/cache</code> 폴더의 소유자를 확인하자.<ref name="crontab" />

<syntaxhighlight lang="console">
ls -l files/config/config.php
</syntaxhighlight>

== 로그 확인 ==
위 예제를 따르면 실행 결과가 <code>files/cron.log</code>에 기록된다. '''crontab 설정 후 며칠간은 이 파일을 확인하며 정상 작동 여부를 점검하자.'''<ref name="crontab" />

<syntaxhighlight lang="console">
tail -f /설치경로/files/cron.log
</syntaxhighlight>

로그 파일이 무한정 커지지 않도록 logrotate를 함께 설정해 두면 좋다.

== 그 밖의 스크립트 ==
<code>common/scripts</code> 폴더에는 예전 이름의 스크립트 파일들(<code>clean_old_thumbnails.php</code> 등)도 남아 있다. 공식 매뉴얼의 일부 설명은 아직 이 이름을 사용한다.

또한 <code>module.updateAllModules</code> 스크립트가 있는데, 이는 모든 모듈의 업데이트를 수행하는 것으로 정기 실행용이 아니다. cron에 등록하지 말자.

== 같이 보기 ==

* [[라이믹스/매뉴얼]]
* [[라이믹스/매뉴얼/라이믹스 프레임워크]] — Queue 클래스
* [[라이믹스/설치]]
* [[라이믹스/매뉴얼/설치 환경]]

== 출처 ==
이 문서의 정리 스크립트 부분은 라이믹스 공식 매뉴얼의 [https://rhymix.org/manual/misc/crontab Crontab 설정 방법] 문서를 바탕으로 작성되었다. 공식 매뉴얼은 CC BY-SA 4.0 라이선스로 배포된다.<ref name="docs-license">[https://github.com/rhymix/rhymix-docs rhymix-docs 저장소] README에 "이 매뉴얼은 CC-BY-SA 4.0 라이선스에 따라 배포됩니다"라고 명시되어 있다.</ref>

비동기 작업 부분은 라이믹스 코어 소스([https://github.com/rhymix/rhymix/blob/master/common/scripts/cron.php common/scripts/cron.php], <code>common/framework/Queue.php</code>, <code>modules/admin/lang/ko.php</code>)를 확인하여 작성하였다.

== 각주 ==
<references />


[[분류:라이믹스]] [[분류:라이믹스/매뉴얼]]

라이믹스/매뉴얼

2026-08-21T05:59:26Z

Gaon12: 정본이 있는 항목을 해당 문서로 직결. 중복된 '개요' 문단 정리. 미작성 항목을 '작성 예정'으로 분리

== 개요 ==
[[라이믹스]]의 설치, 개발, 운영을 정리한 문서이다. 각 항목은 개별 문서로 작성되어 있다. 내용은 [https://rhymix.org/manual Rhymix 매뉴얼]과 [https://rhymix.org/community Rhymix 커뮤니티], 자체 작성 문서를 기반으로 구성되어 있다.

이 색인의 항목 가운데 일부는 매뉴얼 트리 밖에 정본 문서가 있다. 그런 항목은 정본 문서로 바로 연결되며, 매뉴얼 경로로 들어와도 넘겨주기를 통해 같은 곳에 도착한다.

아직 가온 위키에 작성되지 않은 항목은 아래 [[#작성 예정|작성 예정]] 문단에 공식 매뉴얼 링크와 함께 모아 두었다.

== 시작하기 ==
* [[라이믹스/매뉴얼/설치 환경]] — [[라이믹스/사양]]에서 넘어온다
* [[라이믹스/설치|라이믹스 설치]]
* [[라이믹스/매뉴얼/라이믹스 업데이트]]
* [[라이믹스/XE에서 넘어오기|XE 1.x에서 업그레이드]]
* [[라이믹스/매뉴얼/서드파티 자료 호환성 체크리스트]]
* [[라이믹스/매뉴얼/nginx 설정 방법]]
* [[라이믹스/매뉴얼/도메인 변경]]

== 확장 기능 제작 ==
* [[라이믹스/애드온]] — 애드온 구조와 호출 지점
* [[라이믹스/라우터|라우터 사용법]]

== 테마 제작 ==
* [[라이믹스/매뉴얼/템플릿 문법 v2]] — 2.2부터 정식 지원

== 클래스 및 함수 명세 ==
* [[라이믹스/매뉴얼/라이믹스 프레임워크]] — 전체 개요
** [[라이믹스/매뉴얼/라이믹스 프레임워크#코어 클래스|코어 클래스]] — <code>Rhymix\Framework</code> 네임스페이스의 클래스 30종
** [[라이믹스/매뉴얼/라이믹스 프레임워크#예외 클래스|예외 클래스]]
** [[라이믹스/매뉴얼/라이믹스 프레임워크#필터 클래스|필터 클래스]]
** [[라이믹스/매뉴얼/라이믹스 프레임워크#레거시 클래스|레거시 클래스]]
** [[라이믹스/매뉴얼/라이믹스 프레임워크#공통 상수|공통 상수]]

== 코어 개발 참여 ==
* [[라이믹스/라이선스|GPL: 개발자, 디자이너, 사용자의 권리와 의무]]
* [[라이믹스/버그]] — 알려진 버그와 제보 방법
* [[라이믹스/보안]] — 취약점 대응 체계와 제보 방법

== 기타 정보 ==
* [[라이믹스/매뉴얼/Crontab 설정 방법]] — 정리 스크립트와 비동기 작업 실행

== 관련 문서 ==
* [[라이믹스/버전]] — 버전 번호 체계
* [[라이믹스/릴리즈 노트]] — 버전별 변경 사항
* [[라이믹스/블랙리스트]] — 차단된 서드파티 자료
* [[라이믹스/XE와의 차이점]]

== 작성 예정 ==
아래 항목은 아직 가온 위키에 문서가 없다. 당분간은 공식 매뉴얼을 참고하자. 문서를 작성한 뒤에는 위의 해당 문단으로 옮기면 된다.

=== 확장 기능 제작 ===
* 개요 — [https://rhymix.org/manual/plugin/intro 공식 매뉴얼]
* DB 쿼리 operator — [https://rhymix.org/manual/plugin/dbquery/operation 공식 매뉴얼]

=== 테마 제작 ===
* 개요 — [https://rhymix.org/manual/theme/intro 공식 매뉴얼]
* 템플릿 문법 v1 — [https://rhymix.org/manual/theme/template_v1 공식 매뉴얼]

=== 테마 제작 ==
* [[라이믹스/매뉴얼/템플릿 문법 v2]] — 2.2부터 정식 지원

== 클래스 및 함수 명세 ===
* 코어 클래스별 상세 문서 — 공식 매뉴얼에도 "자세한 정보 추가 예정" 상태인 항목이 많다
* 전역 함수 — [https://rhymix.org/manual/reference/functions 공식 매뉴얼]
* 프론트엔드 라이브러리 (전역 함수, 레거시 전역 함수, String 확장)

=== 코어 개발 참여 ===
* GitHub 이슈 및 PR 작성 — [https://rhymix.org/manual/contrib/github 공식 매뉴얼]
* 코딩 규칙 — [https://rhymix.org/manual/contrib/coding-standards 공식 매뉴얼]

=== 기타 정보 ===
* IP 주소 및 대역 표기 방식
* 표준 시간대 처리 방식
* 포토스와이프 연동하기
* 모바일 앱 푸시 연동하기
* 네모의 꿈 레이아웃 주제 색상

== 외부 링크 ==
* [https://rhymix.org/manual 라이믹스 공식 매뉴얼]
* [https://github.com/rhymix/rhymix-docs rhymix-docs 저장소]


[[분류:라이믹스]] [[분류:라이믹스/매뉴얼]]

라이믹스/릴리즈 노트/2.1.36

2026-08-21T05:59:23Z

Gaon12: 새 문서. 2.1.36 릴리즈 노트

2026년 08월 12일에 등록된 릴리즈 노트입니다.

{{인용문|라이믹스 2.1 버전대의 보안패치 및 버그수정 릴리즈로, 이후 개발의 초점은 2.2 준비로 옮겨집니다.}}

== 보안취약점 수정 ==
* [RVE-2026-19] referrer 헤더를 통한 반사형 XSS 취약점
* [RVE-2026-20] 문서 및 댓글 권한을 가진 모듈 관리자가 제한된 설정에 접근할 수 있는 문제
** KISA에서 알려 주셨습니다. (KVE-2026-1661, KVE-2026-1662, KVE-2026-1666)
* Guzzle 라이브러리를 최신 보안 패치가 적용된 버전으로 갱신

== 보안 강화 ==
* 로그인 화면의 비밀번호 입력란에 <code>autocomplete="off"</code> 적용
* 회원정보 또는 비밀번호가 변경된 경우 세션 ID를 갱신하도록 변경

== 기능 개선 ==
* 게시판 목록에서 존재하지 않는 페이지 번호나 분류 번호를 요청한 경우, 빈 목록 대신 404를 반환하도록 변경
** 검색엔진이 의미 없는 페이지를 수집하지 않도록 하기 위한 조치이다.
* 쉬운설치 패키지의 PHP 버전 요구 사항 감지 기능 개선

== 버그 수정 ==
* 일부 PNG 파일 처리 과정에서 발생하던 문제 수정
* 위젯 페이지 편집 시 발생하던 문제 수정
* argon2id 해시 검증이 정상적으로 이루어지지 않던 문제 수정
* 음수 페이지 번호를 요청한 경우의 처리 수정

== 이후 계획 ==
개발진은 이 릴리즈를 기점으로 라이믹스 2.1에 대해 긴급한 보안 패치 외에는 더 이상 업데이트를 진행하지 않고, 2.2 준비에 집중하겠다고 밝혔다. 2.2의 공개 일정과 주요 기능 로드맵은 별도로 공지할 예정이다.

:※ [[라이믹스/릴리즈 노트/2.1.8|2.1.8]]에서 프리뷰로 도입된 템플릿 문법 v2는 2.2에서 정식 지원될 예정이라고 안내된 바 있다.

== 같이 보기 ==
* [[라이믹스/릴리즈 노트]]
* [[라이믹스/릴리즈 노트/2.1.35]]
* [[라이믹스/보안]]
* [[라이믹스/버전]]

== 외부 링크 ==
* [https://rhymix.org/news/1953194 Rhymix 2.1.36 Release Notes]

== 각주 ==
<references />


[[분류:라이믹스]] [[분류:라이믹스/버전]]

라이믹스/릴리즈 노트

2026-08-21T05:59:20Z

Gaon12: 2.1.36 항목 추가

== 개요 ==
[[라이믹스]]의 각 버전별 릴리즈 노트를 정리한 문서이다. 각 버전은 '''라이믹스/릴리즈 노트/버전''' 형식으로 개별 문서화되어 있다. 릴리즈 노트는 [https://rhymix.org/news 라이믹스 릴리즈 노트]에서 가져왔다.

보안 패치가 포함된 경우, 문서 끝에 '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>''' 표시가 붙어 있다. 보안 패치가 있는 경우 업데이트를 적극 권장한다.

== 2.0.x대 버전 ==
[https://xetown.com/rxe_issue/995249 xe 1.10 버전 취소]와 상관없이 아래 변경 사항은 적용된다. 라이믹스를 사용하려면 반드시 PHP 7.0 이상으로 업그레이드해야 한다.

* '''DB 지원 축소:''' [[MySQL]], [[MariaDB]]만 지원.
* '''DB 접속 방식 변경:''' mysql 방식으로 접속하는 경우 자동으로 mysqli 방식으로 변경.
* '''(중요) 지원 PHP 버전 변경:''' PHP 7.0 이상만 사용 가능.
* '''xcache 지원 중단:''' PHP 7.0에서 xcache가 작동하지 않으므로 지원 중단.
* '''기타:''' 자세한 내용은 [https://xetown.com/rxe_issue/908643 라이믹스 버전 및 PHP 버전 변경 예고]를 참고.

자체 버전은 2.0부터 시작된 것으로 보인다.<ref>[https://xetown.com/topics/908643 이전 타운 글]에서 라이믹스 자체 버전의 시작 버전은 2.0.0이라고 했다.</ref>

[https://xetown.com/topics/1404227#comment_1404308 xetown 댓글]을 통해 2020년 가을 안으로 출시될 예정임이 언급되었다.

이후 2.0을 위한 [https://github.com/rhymix/rhymix/tree/next next 브랜치]가 생성되었다. [https://github.com/rhymix/rhymix/issues/1303#issuecomment-636482471 이슈 답변]에 따르면, 검증되지 않은 패치도 적용해 추가 패치로 안정성을 확보하는 방식으로 운영될 예정이다.

2020년 10월 2일, develop 버전이 2.0.0-alpha로 출시되었다. [https://github.com/rhymix/rhymix/commit/0d8d2a6ac0d7e282be81cb61935b4f623c771cb1 0d8d2a6 커밋]

[[라이믹스/Next 라이믹스|Next 라이믹스]]에 적용된 기능들이 그대로 이어졌다. 일부 모듈 설정 관련 버그가 존재한다. [https://xetown.com/questions/1483717 관련 제보글]

<hr>

정식 릴리즈된 2.0.x 버전들의 릴리즈 노트는 아래 문서들을 참고하자:

* [[라이믹스/릴리즈 노트/2.0.0]]
* [[라이믹스/릴리즈 노트/2.0.1]]
* [[라이믹스/릴리즈 노트/2.0.2]]
* [[라이믹스/릴리즈 노트/2.0.3]]
* [[라이믹스/릴리즈 노트/2.0.4]]
* [[라이믹스/릴리즈 노트/2.0.5]]
* [[라이믹스/릴리즈 노트/2.0.6]]
* [[라이믹스/릴리즈 노트/2.0.7]]
* [[라이믹스/릴리즈 노트/2.0.8]]
* [[라이믹스/릴리즈 노트/2.0.9]]
* [[라이믹스/릴리즈 노트/2.0.10]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.0.11]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.0.12]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.0.13]]
* [[라이믹스/릴리즈 노트/2.0.14]]
* [[라이믹스/릴리즈 노트/2.0.15]]
* [[라이믹스/릴리즈 노트/2.0.16]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.0.17]]
* [[라이믹스/릴리즈 노트/2.0.18]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.0.19]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.0.20]]
* [[라이믹스/릴리즈 노트/2.0.21]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.0.22]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.0.23]]
* [[라이믹스/릴리즈 노트/2.0.24]]

== 2.1.x대 버전 ==
2.1.0은 {{날짜/출력|2023-06-21}}에 릴리즈되었다. 자세한 내용은 [[라이믹스/릴리즈 노트/2.1.0]]을 참고하자.

라이믹스 2.1 버전 정보는 [https://xetown.com/topics/1582580 기진곰님의 글]을 통해 확인할 수 있다.

=== 소셜 로그인 지원 ===
<s>[[XpressEngine/모듈/SocialXE|SocialXE]]를 통해 소셜 계정 로그인을 지원했으나, 해당 기능이 코어에 통합될 예정이었다.</s>

그러나 [https://xetown.com/topics/1716524 XE타운 게시판]에 따르면, 소셜 로그인 기능은 2.1 버전에 포함되지 않고 [https://github.com/rhymix/rhymix-sociallogin 별도 모듈]로 제공된다.

=== PHP 최소 버전 변경 ===
PHP 최소 지원 버전이 기존 7.0에서 <s>7.2</s> 7.3으로 변경되었다. 권장 버전도 7.4로 상향되었다.

=== 브라우저 지원 범위 ===

==== 모든 기능 지원 ====
* Chrome, Edge, Firefox 최신 버전
* 최신 macOS 또는 iOS 기반의 Safari
* 3년 이내 출시된 Android 기본 브라우저 및 웹뷰

==== 최소 기능 지원 ====
* Internet Explorer 11 (Windows 10 한정)
* 3년 이내 출시된 macOS 또는 iOS 기반 Safari
* 6년 이내 출시된 Android 기본 브라우저 및 웹뷰
* 그 외 Chromium 기반 브라우저 (웨일, 오페라 등)

==== 공식적으로 미지원 ====
* Internet Explorer 11 (Windows 8.1 이하)
* Internet Explorer 10 이하 모든 버전
* 위 나열된 범위 외 브라우저

=== 쉬운 설치 지원 ===
[[라이믹스/릴리즈 노트/2.1.34|2.1.34]] 버전부터는 라이믹스 공식 홈페이지의 자료실과 연동된 쉬운 설치 기능이 지원된다.

정식 릴리즈된 2.1.x 버전의 릴리즈 노트는 아래 문서들을 참고하자:

* [[라이믹스/릴리즈 노트/2.1.0]]
* [[라이믹스/릴리즈 노트/2.1.1]]
* [[라이믹스/릴리즈 노트/2.1.2]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.3]]
* [[라이믹스/릴리즈 노트/2.1.4]]
* [[라이믹스/릴리즈 노트/2.1.5]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.6]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.7]]
* [[라이믹스/릴리즈 노트/2.1.8]]
* [[라이믹스/릴리즈 노트/2.1.9]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.10]]
* [[라이믹스/릴리즈 노트/2.1.11]]
* [[라이믹스/릴리즈 노트/2.1.12]]
* [[라이믹스/릴리즈 노트/2.1.13]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.14]]
* [[라이믹스/릴리즈 노트/2.1.15]]
* [[라이믹스/릴리즈 노트/2.1.16]]
* [[라이믹스/릴리즈 노트/2.1.17]]
* [[라이믹스/릴리즈 노트/2.1.18]]
* [[라이믹스/릴리즈 노트/2.1.19]]
* [[라이믹스/릴리즈 노트/2.1.20]]
* [[라이믹스/릴리즈 노트/2.1.21]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.22]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.23]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.24]]
* [[라이믹스/릴리즈 노트/2.1.25]]
* [[라이믹스/릴리즈 노트/2.1.26]]
* [[라이믹스/릴리즈 노트/2.1.27]]
* [[라이믹스/릴리즈 노트/2.1.28]]
* [[라이믹스/릴리즈 노트/2.1.29]]
* [[라이믹스/릴리즈 노트/2.1.30]]
* [[라이믹스/릴리즈 노트/2.1.31]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.32]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.33]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.34]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.35]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/2.1.36]]<ref>2.1 버전대의 사실상 마지막 기능 릴리즈. 이후 2.1은 긴급 보안 패치만 제공된다.</ref> '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''

== 1.9.x대 버전 ==
* [[라이믹스/릴리즈 노트/1.9.10]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/1.9.11]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/1.9.12]] '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''
* [[라이믹스/릴리즈 노트/1.9.13]]<ref>1.9.x대 버전의 마지막 지원 버전.</ref> '''<i class="fas fa-exclamation-triangle" style="color: red;">보안패치</i>'''

== 분기 ==
{{퍼온문서||||라이믹스|https://www.gaonwiki.com/w/index.php?title=%EB%9D%BC%EC%9D%B4%EB%AF%B9%EC%8A%A4&oldid=107716}}

== 각주 ==
<references />


[[분류:라이믹스]] [[분류:라이믹스/버전]]

라이믹스/라이선스

2026-08-21T05:59:17Z

Gaon12: 새 문서. GPL 라이선스 정책과 확장 기능 개발자·구매자의 권리와 의무 정리

{{틀:상위문서|라이믹스}}

이 문서는 [[라이믹스]]의 라이선스 정책을 다룬다. 라이믹스 자체에 대한 설명은 [[라이믹스]] 문서를 참고할 수 있다.

== 개요 ==
라이믹스는 GNU GPL v2 계열 라이선스로 배포된다.<ref name="github-readme">[https://github.com/rhymix/rhymix rhymix/rhymix GitHub 저장소]</ref> 기반이 된 [[XpressEngine|XpressEngine 1.x]]가 LGPL v2.1을 사용하던 것과 달리, 라이믹스는 포크 과정에서 GPL v2를 채택하였다. 공식 매뉴얼은 이 선택의 취지를 개발자의 권리를 일부 제한하는 대신 사용자의 권리를 보호하기 위한 것으로 설명한다.<ref name="license">[https://rhymix.org/manual/contrib/license GPL: 개발자, 디자이너, 사용자 등의 권리와 의무]</ref>

== LGPL에서 GPL로 ==
LGPL은 GPL로의 라이선스 전환을 허용한다. 이 때문에 라이믹스는 XE의 소스 코드를 가져와 사용할 수 있지만, 반대로 GPL인 라이믹스의 코드를 LGPL 소프트웨어가 가져가는 것은 성립하지 않는다. 포크 이후 두 프로젝트 사이에는 코드가 한 방향으로만 흐르는 관계가 형성되었다.<ref name="license" />

== 사용자의 권리와 의무 ==
웹사이트에 라이믹스를 사용하는 것만으로는 소스 코드를 공개할 의무가 생기지 않는다. 상업용 홈페이지를 만들거나, 라이믹스의 소스 코드를 직접 수정하거나, 확장 기능을 만들어 사용하더라도 이를 타인에게 배포하지 않고 자신이 운영하는 사이트에서만 쓴다면 공개 의무가 없다.<ref name="license" />

또한 사용자는 GPL 자료와 다른 라이선스의 자료를 함께 사용할 수 있으며, 개인적으로 사용하는 코드는 자유롭게 고칠 수 있다.<ref name="license" />

== 확장 기능 개발자의 의무 ==
라이믹스의 확장 기능을 사용하는 모듈과 애드온은 GPL이어야 한다. LGPL에서는 확장 기능 제품의 라이선스를 개발자가 선택할 수 있었지만, GPL에서는 선택의 여지가 없다.<ref name="license" />

=== 판매와 소스 코드 제공 ===
GPL은 유료 판매를 금지하지 않는다. 공식 매뉴얼은 GPL 라이선스의 확장 기능을 판매할 수 있으며, 워드프레스 테마 시장이 그러한 방식으로 유지되고 있다고 설명한다.<ref name="license" />

다만 판매하는 경우 개발자는 구매자에게 암호화하지 않은 원본 소스 코드를 제공해야 한다. 소스 코드를 불특정 다수에게 공개할 의무까지 있는 것은 아니지만, 적어도 구매자에게는 수정 가능한 형태로 전달해야 한다. 이는 개발자와 연락이 끊긴 뒤에도 구매자가 다른 개발자에게 유지보수를 맡길 수 있도록 하기 위한 것이다.<ref name="license" />

=== 구매자의 권리 ===
소스 코드를 제공받은 사용자는 그 코드를 수정하거나 제3자에게 재배포할 수 있으며, 개발자는 이를 막을 수 없다.<ref name="license" />

=== 주문 제작물 ===
특정 고객을 위해 개발한 코드는 사용자 규정을 따른다. 개발자는 해당 고객에게만 소스 코드를 제공하면 되고, 이를 공개적으로 배포할 의무는 없다.<ref name="license" />

=== 유지보수 의무 ===
무료로 배포한 자료에는 유지보수 의무가 따르지 않는다. 유료로 판매한 경우의 사후 지원 범위는 구매자와의 계약에 따른다.<ref name="license" />

== 스킨과 레이아웃 ==
HTML, CSS, JavaScript, 이미지, 아이콘, 글꼴 등은 GPL의 적용 대상이 아니다. 이러한 자료는 라이믹스의 내부 함수를 직접 호출하는 방식으로 동작하지 않기 때문이다. 따라서 스킨이나 레이아웃을 제작한 디자이너는 다른 라이선스를 선택할 수 있다.<ref name="license" />

다만 스킨이나 레이아웃이라도 라이믹스의 내부 함수를 호출하여 기능을 추가하는 경우에는 확장 기능으로 간주될 수 있다. 모듈이나 애드온에 스킨이 포함된 경우, 스킨 부분에만 별도의 라이선스를 적용하는 사례도 있다.<ref name="license" />

== 관련 문서 ==

* [[라이믹스]]
* [[라이믹스/XE와의 차이점]]
* [[XpressEngine]]

== 외부 링크 ==

* [https://rhymix.org/manual/contrib/license GPL: 개발자, 디자이너, 사용자 등의 권리와 의무]
* [https://github.com/rhymix/rhymix 라이믹스 GitHub 저장소]

== 각주 ==
<references />


[[분류:라이믹스]]

라이믹스/XE와의 차이점

2026-08-21T05:59:14Z

Gaon12: 라이선스·실행 환경·코어 흡수 기능·지원 중단 자료·프레임워크 구조·업그레이드 제약 문단 추가. 누락되어 있던 <references /> 추가

==설치 페이지==
XE를 설치할때의 디자인과 몇몇 부분이 다르다. 비교를 위해 XE의 설치 과정은...
* 설치 언어 선택
* 사용권 동의
* 설치 조건 확인
* FTP 정보 입력(경우에 따라 생략 가능)
* DB 선택
* DB 정보 입력
* 환경 설정(시간대 설정)
* 관리자 정보 입력
위 과정을 거친다.

하지만 라이믹스는 생략 가능한 FTP 정보 입력을 포함한 8 과정보다 적은 4 과정만 거친다.

라이믹스의 설치 과정은 아래와 같다.
* 사용권 동의
* 설치 환경 확인
* DB 정보 입력
* 관리자 계정 생성
===과정 합침===
라이믹스 설치 과정은 4 과정만 거치기 때문에, [[XpressEngine|XE]]의 8 과정들 중 일부를 합쳤다.
====설치 언어 선택====
설치 언어 선택 부분은 언제든 바꿀 수 있도록 하단에 선택 할 수 있도록 하였다. 따라서 설치 중간에 언어를 변경 할 수 있다.
====사용권 동의====
설치 언어 선택 부분이 하단 선택으로 분리되었기 때문에 라이믹스에서는 사용권 동의 부분이 맨 첫번째로 나온다. 또한 XE의 사용권 동의 내용과 다른데, 단순히 XE를 라이믹스로 바꾼것 외에도 아래의 부분이 다르다.

내용 최상단에 '''Copyright © Developers and Contributors'''가 적혀져 있다.

또한 XE의 사용권 동의 부분 4 번째, 6 번째 문단이 없다.
====설치 조건 확인와 FTP 정보 입력====
설치 조건 확인 부분은 [[라이믹스/사양]]에 적혀져 있는 사양대로 수정이 되어져 있다. 그리고 FTP 정보 입력 부분은 삭제되어 있다.<ref>관리자 페이지 > 설정 > FTP 설정 에서 설정이 가능하기 때문에 빠진 것 같다.</ref>

====DB 선택과 DB 정보 입력====
DB 선택, DB 정보 입력 부분이 합쳐져 있다. 맨 처음에는 DB 종류(XE에서는 DB 선택), 바로 아래에 DB 정보 입력 부분이 있다.

물론 라이믹스는 DB를 MySQL이나 MariaDB밖에 선택 할 수 없다. 거기에 innoDB(mysqli)를 사용 할 수 있다면, 선택을 mysql로 하더라도 자동으로 mysqli로 설정된다.

==관리자 페이지==
관리자 페이지가 다르다. 2018년 08월 14일 관리자 페이지 디자인 변경 PR(Pull Request)이 받아 들여짐으로써 디자인이 변경되었다. [https://github.com/rhymix/rhymix/pull/1056 참고]

pc 화면<br/>
[[파일:라이믹스_관리자_페이지_변경1후(pc).png|300px]]<br/>

모바일 화면<br/>
[[파일:라이믹스_관리자_페이지_변경1후(모바일).jpg|150px]]<br/>

==서드 파티(Third Party) 모듈의 포함==
여러 서드 파티(Third Party) 모듈들이 포함되어져 있다. 포함 되어져 있는 서드 파티 모듈(애드온 포함)은 아래와 같다.
* PhotoSwipe (애드온)
* 본문 내 이미지 조절 애드온 (애드온)
* 이미지 리사이즈 (애드온)
* 리캡챠 (애드온)
* 고급 메일 발송 모듈 (메일 및 SMS 관리) (모듈)
* 알림센터 Lite (모듈)<ref>XE에도 해당 모듈이 있지만 코어에 포함되어 있지 않다.[https://www.xpressengine.com/index.php?mid=download&package_id=21374711 xe 공식 홈페이지-다운로드에 있는 알림센터 lite]는 XE 용으로 라이믹스에서
사용하기에는 부적절하다.</ref>

==네모의 꿈 프로젝트==
네모의 꿈 프로젝트가 진행중이다. [https://github.com/rhymix/rhymix/projects 깃허브 프로젝트 페이지] 현재 네모의 꿈 스킨이 적용된 부분은 아래와 같다.

* [https://github.com/rhymix/rhymix/tree/master/layouts/simple_world 레이아웃]
* [https://github.com/rhymix/rhymix/tree/master/modules/communication/skins/simple_world 커뮤니케이션 모듈 스킨]
* [https://github.com/rhymix/rhymix/tree/5683ba7bba709bff2cf48339ac4f1f6347cbf414/modules/message/skins/simple_world 메시지 모듈 스킨]
* [https://github.com/rhymix/rhymix/tree/5683ba7bba709bff2cf48339ac4f1f6347cbf414/modules/member/skins/simple_world 회원 모듈 스킨]

==지원 DB==
XE가 지원하고 있는 DB는 다음과 같다. (순서대로 지원하는 것은 아님.)
* MySQL
* MariaDB
* Cubrid
* MS-SQL

다만 라이믹스는 MySQL과 MariaDB만 지원하며, MariaDB의 사용을 권장하고 있다. 그 외의 DB로 설치가 불가능하다.

==CKEditor==
XE는 커스텀 된 [[CKEditor]]<ref>붙혀넣기 버그 수정을 위해 몇몇 플러그인 제거</ref>가 포함되어 있지만, 라이믹스는 [[CKEditor]]가 커스텀 되어 있지 않습니다!

이 때문에 버그가 생기는데요. 자세한 내용은 [[라이믹스/버그#단축키를 제외한 다른 방법으로의 붙혀넣기 불가능?|라이믹스/버그 문서의 '단축키를 제외한 다른 방법으로의 붙혀넣기 불가능?' 문단을 확인하자]]

==대용량 업로드==
관리자에 한하여 "php.ini" 파일에 설정되어 있는 용량(upload_max_filesize) 이상의 크기의 파일도 업로드가 가능하다!

다만 아래의 경우, 업로드에 실패 할 수 있다.
* 업로드 하려는 파일의 용량이 서버에서 사용 가능한 용량보다 큰 경우(용량 초과) → 서버의 용량을 늘린다.
* '''max_input_time''' 와 '''max_execution_time''' 의 시간이 업로드 시간보다 짧은 경우 → 시간을 늘려준다.
* 32비트 서버에서 2기가 이상의 파일을 업로드 하는 경우→ 64비트 서버로 갈아타자 ([https://xetown.com/questions/661540#comment_661544 xetown 기진곰님 답변])
* 디스크 파티션 포맷이 처리 할 수 있는 용량 이상의 파일 업로드인 경우 (특히 FAT32) → 다른 파티션 포맷으로 설정하자(백업 필수!)

: (참고) 파티션 포맷 별 파일 최대 용량
{| class="wikitable"
! align="center" | 포맷명 !! 용량 한계
|-
| align="center" | FAT32 || align="center" | 4GB
|-
| align="center" | NTFS || align="center" | 16TB(이론)/2TB(실질적)
|-
| align="center" | exFAT || align="center" | 64ZB<ref>GB→TB→PB→EB→ZB</ref>(이론)/512TB(실질적)
|}

==권한 부분==
게시판 설정 등에서 권한 관리를 보면 '''가입한 사용자'''와 '''로그인 사용자''' 둘이 있다. 가입한 사용자는 카페XE 등 멀티사이트에 가입한 사용자를 의미하나, 해당 기능을 사용하지 않는 경우 가입한 사용자와 로그인한 사용자는 사실상 같다.

라이믹스에서는 멀티사이트 기능이 [https://github.com/rhymix/rhymix/pull/728 지원 중단]됨에 따라 그 둘을 합쳐 '''로그인 사용자'''로 통일하였다.

==db 설정 참고 파일의 차이==
XE는 db 설정된 값(db 아이디, 비밀번호 등)을 참고하는 파일은 '''./files/config/db.config.php'''이다. 그에 반면에 라이믹스는 '''./files/config/config.php''' 파일이다.

라이믹스에도 db.config.php 파일이 있지만 XE와의 호환성<ref>기존 XE 애드온, 모듈들 중에서 해당 파일을 참고하는 경우를 위해 남겨두는 것이다.</ref>을 위해 만들어 둔것일 뿐, 직접 참고하지는 않는다.

==이미지 파일 최적화==
기존 XE나 라이믹스는 이미지 파일의 크기를 줄이거나, 휴대폰으로 세로모드로 찍었던 사진을 원상태로 돌리기 위해서는 [[XpressEngine/모듈/이미지프로세스|이미지프로세스]] 모듈을 사용했어야 했지만, 이제는 라이믹스 코어에서 지원한다!

* 업로드시 설정한 크기보다 업로드하는 크기가 크면, 자동으로 크기를 조절.
* 용량 큰 BMP 파일 업로드시 JPG로 자동 변환. (PHP 7.2 이상 필요)<ref>GD 라이브러리가 BMP를 지원하는 버전이 7.2 버전부터이므로, 7.2 이상만 사용 가능</ref>
* [[클라우드플레어]]나 구글 [[PageSpeed]]를 사용하면 JPG를 WebP로 지 맘대로 바꾸는데, 바뀐 WebP를 JPG로 다시 변환.<ref>WebP는 크롬 기반 브라우저가 아니라면 열수 없는 변태적인(?) 파일이기 때문에, 다른 브라우저들과의 호환성을 위해 다시 바꾼다.</ref>
* 휴대폰에서 세로모드로 찍은 사진을 자동 회전시킴. (EXIF 확장모듈 필요)
* 위의 3가지 변환 작업시 적용할 JPG 화질 설정 가능.
* 허용 확장자 설정 문법이 *.gif;*.jpg;*.png 에서 gif,jpg,png 로 대폭 간소화.<ref>기진곰님은 해당 패치의 설명으로 '''"파일 업로드 라이브러리에서 요구하는 문법을 사람이 직접 볼 필요는 없잖아요?"'''라고 남겼다.</ref>
* 전체 설정 외에도 게시판 설정으로도 조절 가능.

이 [https://xetown.com/topics/1250476 기습패치]는 2019년 08월 01일 1.9.9.3 마스터 브랜치에 릴리즈 되었다.

==커스텀 쉬운설치 서버 지원==
XE는 쉬운설치 서버를 공식 홈페이지만 지원한다. 그래서 쉬운설치 서버가 불안정해 접속이 되지 않으면 설치가 되지 않는다.

물론 쉬운설치를 권장하는 것은 아니지만, 공식 홈페이지 서버 백업용 사이트를 추가하여 안정성을 높이는 등을 할 수 있다.

XE는 코어 수정이 있어야 하지만, 라이믹스는 [https://github.com/rhymix/rhymix/pull/1381 PR]을 통해 코어 수정 없이 관리자 페이지에서 관리 할 수 있게 되었다.

==라이선스==
XE 1.x는 LGPL v2.1을, 라이믹스는 GPL v2를 사용한다. 공식 매뉴얼은 이 전환의 취지를 개발자의 권리를 일부 제한하는 대신 사용자의 권리를 보호하기 위한 것으로 설명한다.<ref name="license">[https://rhymix.org/manual/contrib/license GPL: 개발자, 디자이너, 사용자 등의 권리와 의무]</ref>

LGPL은 GPL로의 전환을 허용하므로 라이믹스는 XE의 코드를 가져올 수 있지만, 반대 방향은 성립하지 않는다. 또한 라이믹스의 확장 기능을 사용하는 모듈과 애드온은 모두 GPL이어야 하며, 판매하더라도 구매자에게 암호화하지 않은 원본 소스 코드를 제공해야 한다. 자세한 내용은 [[라이믹스/라이선스]] 문서를 참고하자.<ref name="license" />

==실행 환경==
{| class="wikitable"
! 구분 !! XE 1.x !! 라이믹스
|-
| [[PHP]] || 5.3 이상에서 동작 || 7.4 이상 필요, 8.2 이상 권장
|-
| 데이터베이스 || MySQL, MariaDB, Cubrid, MS-SQL || MySQL 5.7 이상 또는 MariaDB 10.6 이상
|-
| 필수 PHP 확장 || 상대적으로 적음 || curl, gd, iconv 또는 mbstring, json, openssl, PDO_MySQL, SimpleXML, Zend OPcache
|}

자세한 요구 사항은 [[라이믹스/매뉴얼/설치 환경]] 문서를 참고하자.<ref name="requirements">[https://rhymix.org/manual/introduction/requirements 설치 환경 - 라이믹스 매뉴얼]</ref>

==코어에 흡수된 기능==
XE 시절 별도 자료로 설치하던 다음 기능은 라이믹스 코어에 포함되어 있다. 해당 자료는 제거하고 관리자 화면에서 설정을 확인해야 한다.<ref name="thirdparty">[https://rhymix.org/manual/introduction/thirdparty-checklist 서드파티 자료 호환성 체크리스트]</ref>

{| class="wikitable"
! XE 시절 자료 !! 라이믹스에서의 위치 !! 비고
|-
| 고급 메일러 모듈 || 시스템 설정 → 알림 || 외부 API와 SMTP 발송 기능이 흡수됨. 설정은 자동 변환되나 발송 방식을 확인해야 한다
|-
| 자동 로그인 모듈 || 코어 기능 || 사용자가 회원정보 화면에서 기기를 직접 관리한다. 업그레이드 후 기존 세션이 만료되어 재로그인이 필요하다
|-
| 멀티도메인 모듈 || 시스템 설정 → 사이트 설정 || 도메인 설정이 자동 변환된다
|-
| SEO 모듈 || 시스템 설정 → SEO 설정 ||
|-
| 오류 기록 모듈 || 시스템 설정 → 디버그 설정 || 오류 추적 기능이 대체되었다
|}

==지원이 중단된 자료==
다음 자료는 라이믹스에서 정상 동작하지 않거나 더 이상 필요하지 않다.<ref name="thirdparty" />

{| class="wikitable"
! 자료 !! 상태 !! 대응
|-
| 홈페이지·카페 모듈 || 멀티도메인 기능과 충돌하여 미지원 || 이 기능이 필요하면 XE 1.x에 남는 것이 권장된다
|-
| 캡차·캡차 회원 애드온 || 최근 라이믹스에서 동작하지 않음 || recaptcha 애드온으로 이전
|-
| jQuery CDN 관련 애드온 || 외부 CDN을 통한 로드를 지원하지 않음 || 스크립트 호환성 유지를 위한 조치이다
|-
| 회원 커뮤니케이션 애드온 || 커뮤니케이션 모듈에 통합 || 별도 설치가 필요 없다
|-
| 모바일 XE 애드온 || 사용되지 않음 ||
|}

==프레임워크 구조==
라이믹스는 CMS 기능과 별개로 자체 프레임워크 클래스를 제공한다. 공식 매뉴얼의 클래스 및 함수 명세에는 Cache, Config, Cookie, DB, DateTime, Debug, Exception, Formatter, HTTP, i18n, Image, Korea, Lang, MIME, Mail, Pagination, Password, Push, Queue, Request, Router, SMS, Security, Session, Storage, Template, Timer, UA, URL 등이 정리되어 있으며, 파일 내용·파일명·HTML·IP·미디어를 검사하는 필터 클래스도 별도로 제공된다.<ref name="manual-index">[https://rhymix.org/manual 라이믹스 매뉴얼]</ref>

이 가운데 Queue는 메일 발송이나 푸시 알림처럼 시간이 오래 걸리는 작업의 비동기 처리에, Router는 짧은주소 처리에 쓰인다. 라우터에 대해서는 [[라이믹스/라우터]] 문서를 참고하자.<ref name="manual-index" />

라이믹스 2.0에서는 데이터베이스 연동이 크게 개편되어, XML을 거치지 않는 직접 쿼리 실행과 외부 데이터베이스 접근이 가능해졌고 PDO 기반 기능이 제공된다.<ref name="release-200">[https://rhymix.org/news/132 Rhymix 2.0.0 Release Notes]</ref>

==템플릿 문법==
라이믹스는 [[라이믹스/릴리즈 노트/2.1.8|2.1.8]]부터 Blade 문법을 기반으로 한 템플릿 문법 v2를 프리뷰로 제공한다. Blade의 <code>@auth</code>, <code>@can</code> 같은 지시자가 라이믹스의 권한 체계에 맞게 재해석되어 있으며, 확장자는 <code>.html</code>과 <code>.blade.php</code> 중 선택할 수 있고 기존 v1 문법과 섞어 쓸 수 있다.<ref name="template-v2">[https://rhymix.org/manual/theme/template_v2 템플릿 문법 v2 - 라이믹스 매뉴얼]</ref> 자세한 문법은 [[라이믹스/매뉴얼/템플릿 문법 v2]] 문서를 참고하자. 2.2에서 정식 지원될 예정이다.<ref name="release-218">[https://rhymix.org/news/424 Rhymix 2.1.8 Release Notes]</ref>

==업그레이드 제약==
* XE 1.8 이상에서만 라이믹스로 직접 업그레이드할 수 있다. 그 이전 버전은 먼저 XE 1.8, 가능하면 1.11로 올려야 한다.<ref name="xe-upgrade">[https://rhymix.org/manual/introduction/xe-upgrade XE 1.x에서 업그레이드 - 라이믹스 매뉴얼]</ref>
* '''라이믹스로 전환한 뒤에는 XE로 되돌릴 수 없다.'''<ref name="xe-upgrade" />
* FTP 파일과 데이터베이스를 각각 백업해야 한다. 공식 매뉴얼은 검증되지 않은 백업 스크립트나 호스팅 업체의 백업 기능에 의존하지 말고 phpMyAdmin처럼 직접 접근하는 도구를 쓸 것을 권한다.<ref name="xe-upgrade" />
* 이전 도구(마이그레이션 도구)는 안정성과 호환성 문제로 어떤 경우에도 권장되지 않는다.<ref name="xe-upgrade" />

구체적인 절차는 [[라이믹스/XE에서 넘어오기]] 문서를 참고하자.

==기타==
다른 것들은 추가 바람.

==분기==
{{퍼온문서|라이믹스|4734||가온 위키}}

==같이 보기==
* [[라이믹스]]
* [[라이믹스/라이선스]]
* [[라이믹스/XE에서 넘어오기]]
* [[라이믹스/매뉴얼/설치 환경]]
* [[XpressEngine]]

==각주==
<references />

라이믹스 블랙리스트

2026-08-21T05:59:12Z

Gaon12: 넘겨주기 대상 수정. 존재하지 않는 문단(라이믹스#라이믹스 블랙리스트) 대신 라이믹스/블랙리스트로 연결

#넘겨주기 [[라이믹스/블랙리스트]]

라이믹스

2026-08-21T05:59:08Z

Gaon12: 정보상자 적용, 최신 버전 2.1.36 반영. 라이선스 전환·저장소 이력·프레임워크 구조·템플릿 문법 v2·보안·쉬운설치 문단 추가. 하위 문서 연결 정리 및 마크다운 링크 오류 수정

{{소프트웨어 정보
| 이름 = 라이믹스
| 로고 = rhymix.png
| 설명 = 현 라이믹스의 로고
| 원작자 = [[XpressEngine|XE]] 개발팀 및 기여자
| 개발자 = (주)포에시스
| 발표일 = 2015년 12월 18일
| 최신 버전 = 2.1.36
| 최신 버전 출시일 = {{날짜/출력|2026-08-12}}
| 프로그래밍 언어 = [[PHP]]
| 종류 = 오픈소스 [[CMS]] 및 웹 프레임워크
| 라이선스 = GNU GPL v2 계열
| 웹사이트 = [https://rhymix.org rhymix.org]
| 전작 = [[XpressEngine|XpressEngine 1.x]]
}}
영어 문서는 [[Rhymix|Rhymix]] 문서를 참고할 수 있다.

{{틀:인용문|Rhyme + Remix {{틀:=}} "RHYMIX"!}}

[https://rhymix.org 라이믹스 공식 홈페이지] · [https://rhymix.org/manual 공식 매뉴얼] · [https://github.com/rhymix/rhymix GitHub 저장소] · [https://github.com/rhymix/rhymix-docs 공식 문서 저장소]

== 개요 ==
'''라이믹스'''(Rhymix)는 [[XpressEngine|XpressEngine 1.x]]를 기반으로 갈라져 나온 PHP 기반의 오픈소스 [[CMS]] 및 웹 프레임워크이다. 공식 홈페이지에서는 라이믹스를 “오픈소스 CMS 및 프레임워크”로 소개하며, 모듈과 테마를 이용하여 홈페이지, 커뮤니티, 게시판, 서비스형 웹사이트 등을 구성할 수 있다고 설명한다.<ref name="official-home">[https://rhymix.org 라이믹스 공식 홈페이지]</ref>

프로젝트는 2015년 12월 18일에 시작되었으며, 현재는 대전에 소재한 (주)포에시스(Poesis Inc.)가 개발과 유지보수를 맡고 있다.<ref name="about">[https://rhymix.org/about 라이믹스 소개]</ref>

라이믹스는 기존 XE 1.x와의 호환성을 상당 부분 유지하면서도, 보안 패치, PHP 최신 버전 대응, 성능 개선, 관리자 기능 개선, 확장성 개선 등을 꾸준히 반영하는 방향으로 개발되고 있다. 공식 GitHub 저장소의 설명에 따르면 라이믹스는 XE 기반 자료의 호환성을 최대한 유지하면서도, 더 빠르고 안전하며 사용자와 개발자가 소통하기 쉬운 CMS를 지향한다.<ref name="github-readme">[https://github.com/rhymix/rhymix rhymix/rhymix GitHub 저장소]</ref>

이름은 rhyme(운율)과 remix(재조합)를 결합한 것으로, 기존 XE 생태계를 단순히 보존하는 데 그치지 않고 필요한 부분을 다시 섞고 개선한다는 의미를 담고 있다. 공식 소개 문서는 라이믹스가 온라인에서 무언가를 만들어내는 모든 “메이커”를 지원하는 것을 목표로 하며, 설치와 운영 과정에서 대부분의 사용자가 터미널 명령을 입력할 필요가 없어야 한다는 원칙을 내세운다고 설명한다.<ref name="about" />

라이선스는 GNU GPL v2 계열이다. 라이믹스 공식 저장소와 공식 홈페이지 모두 GPLv2를 명시하고 있으며, 공식 매뉴얼에는 GPL 라이선스에 따른 사용자, 개발자, 디자이너의 권리와 의무가 별도 문서로 정리되어 있다.<ref name="license">[https://rhymix.org/manual/contrib/license GPL: 개발자, 디자이너, 사용자 등의 권리와 의무]</ref>

== 역사 ==
라이믹스는 XE 1.x의 소스 코드를 기반으로 시작된 프로젝트이다. XE가 보안 패치 중심으로 유지되는 동안, 실제 운영자와 개발자들이 필요로 하던 개선 사항을 더 적극적으로 반영하기 위해 XETOWN 커뮤니티를 중심으로 포크가 논의되었다. 프로젝트의 공식 시작일은 2015년 12월 18일이다.<ref name="about" />

초기에는 명확한 이름이 정해지지 않아 XETOWN Fork, XETOWN CMS, XETOWN Core 등으로 불렸으며, 2016년 1월 GitHub 이슈에서는 XETOWN REMIX, 줄여서 XTR이라는 이름도 논의되었다.<ref name="issue31">[https://github.com/rhymix/rhymix/issues/31 XETOWN 프로젝트에서 정리해야 될 사항들]</ref> 이후 프로젝트명은 라이믹스(Rhymix)로 정착하였다.

라이믹스라는 이름은 Rhyme과 Remix를 결합한 말로 설명된다. 기존 XE 생태계를 단순히 보존하는 데 그치지 않고, 필요한 부분을 다시 섞고 개선한다는 의미를 담고 있다.

=== 라이선스 전환 ===
라이믹스는 포크 과정에서 XE가 사용하던 LGPL v2.1 대신 GPL v2를 채택하였다. 공식 매뉴얼은 이 전환의 취지를 개발자의 권리를 일부 제한하는 대신 사용자의 권리를 보호하기 위한 것으로 설명한다.<ref name="license" />

이 선택은 두 프로젝트 사이에 단방향 관계를 만들었다. LGPL은 GPL로의 전환을 허용하므로 라이믹스는 XE의 코드를 가져올 수 있지만, 반대 방향은 성립하지 않는다. 또한 라이믹스의 확장 기능을 사용하는 모듈과 애드온은 모두 GPL이어야 하며, 판매하더라도 구매자에게 암호화하지 않은 원본 소스 코드를 제공해야 한다. 자세한 내용은 [[라이믹스/라이선스]] 문서를 참고할 수 있다.<ref name="license" />

=== 저장소 이력 ===
라이믹스는 포크 시점에 저장소 이력을 새로 시작하지 않고 XE의 커밋 기록을 그대로 이어받았다. 이 때문에 공식 저장소에는 XE 시절부터 누적된 약 21,000건의 커밋이 남아 있다. 2026년 8월 기준 저장소의 스타는 297개, 포크는 134개이다.<ref name="github-readme" />

== 특징 ==
=== XE와의 관계 ===
라이믹스는 XE 1.x를 기반으로 하지만, 단순한 보안 패치판이라기보다는 XE 1.x의 구조와 생태계를 이어받아 적극적으로 개선한 별도 프로젝트에 가깝다. 공식 저장소에서도 라이믹스가 XpressEngine의 소스 코드를 기반으로 하며, 기존 XE 서드파티 자료와의 호환성을 최대한 보장하려 한다고 설명한다.<ref name="github-readme" />

다만 라이믹스는 XE와 완전히 같은 소프트웨어가 아니다. PHP 요구 버전, 서버 환경, 관리자 설정, 보안 정책, 일부 서드파티 자료의 동작 방식에서 차이가 있다. 특히 XE에서 라이믹스로 업그레이드한 뒤에는 다시 XE로 되돌릴 수 없으므로, 이전 전에 반드시 파일과 데이터베이스를 백업해야 한다.<ref name="xe-upgrade">[https://rhymix.org/manual/introduction/xe-upgrade XE 1.x에서 업그레이드]</ref>

두 소프트웨어의 구체적인 차이는 [[라이믹스/XE와의 차이점]] 문서에 정리되어 있다.

=== 프레임워크 구조 ===
라이믹스는 CMS인 동시에 자체 프레임워크를 갖추고 있다. 공식 매뉴얼의 클래스 및 함수 명세에는 Cache, Config, Cookie, DB, DateTime, Debug, Exception, Formatter, HTTP, i18n, Image, Korea, Lang, MIME, Mail, Pagination, Password, Push, Queue, Request, Router, SMS, Security, Session, Storage, Template, Timer, UA, URL 등의 코어 클래스가 정리되어 있으며, 파일 내용·파일명·HTML·IP·미디어를 검사하는 필터 클래스도 별도로 제공된다.<ref name="manual-index">[https://rhymix.org/manual 라이믹스 매뉴얼]</ref>

이 가운데 Queue는 메일 발송이나 푸시 알림처럼 시간이 오래 걸리거나 외부 서비스와 연계되는 작업을 비동기로 처리하는 데 쓰이며, Router는 짧은주소 처리를 담당한다. 확장 기능 제작 문서에는 DB 쿼리 연산자와 라우터 사용법이 별도 항목으로 수록되어 있다.<ref name="manual-index" />

=== 템플릿 문법 v2 ===
라이믹스는 2.1.8부터 새로운 템플릿 문법인 템플릿 문법 v2를 프리뷰 형태로 제공한다.<ref name="release-218">[https://rhymix.org/news/424 Rhymix 2.1.8 Release Notes]</ref> 이 문법은 Blade 문법을 기반으로 하되 라이믹스의 구조에 맞게 여러 지시자를 추가한 것으로, Blade의 <code>@auth</code>, <code>@can</code> 같은 지시자를 라이믹스의 권한 체계에 맞게 재해석하여 게시판 관리자 여부나 댓글 작성 권한 등을 간단히 확인할 수 있다.<ref name="template-v2">[https://rhymix.org/manual/theme/template_v2 템플릿 문법 v2]</ref>

파일 확장자는 <code>.html</code>과 <code>.blade.php</code> 중에서 선택할 수 있으며, 후자를 사용하면 대부분의 편집기에서 Blade 플러그인을 통해 문법 강조와 자동 완성을 이용할 수 있다. 기존 v1 문법 가운데 검증된 요소는 그대로 유지되어 두 문법을 섞어 쓸 수도 있다.<ref name="template-v2" /> 2.1.8 릴리즈 노트는 이 문법이 프리뷰 단계이며 2.2에서 정식 지원될 예정이라고 안내하였다. 자세한 문법은 [[라이믹스/매뉴얼/템플릿 문법 v2]] 문서를 참고할 수 있다.<ref name="release-218" />

=== 활발한 업데이트 ===
라이믹스는 새 기능, 버그 수정, 보안 패치가 꾸준히 이루어지는 프로젝트이다. 공식 매뉴얼은 라이믹스를 운영하는 사이트가 자주 업데이트할 준비를 해야 한다고 안내한다.<ref name="update">[https://rhymix.org/manual/introduction/update 라이믹스 업데이트]</ref>

공식 홈페이지와 뉴스 게시판에서는 각 정식 버전의 릴리즈 노트와 변경 파일을 제공한다.<ref name="newslist">[https://rhymix.org/news/category/177 라이믹스 릴리즈 노트 목록]</ref>

=== 공식 문서와 커뮤니티 ===
공식 문서는 [https://rhymix.org/manual 라이믹스 공식 매뉴얼]과 [https://github.com/rhymix/rhymix-docs rhymix-docs 저장소]에서 확인할 수 있다. 공식 문서에는 설치 환경, 설치 방법, 업데이트, XE 1.x에서 업그레이드, 서드파티 자료 호환성, nginx 설정, 도메인 변경, 확장 기능 제작, 테마 제작, 코어 개발 참여 방법 등이 정리되어 있다.<ref name="docs-repo">[https://github.com/rhymix/rhymix-docs rhymix/rhymix-docs]</ref>

질문과 토론은 공식 홈페이지의 커뮤니티, Q&A, 팁·튜토리얼 게시판과 XETOWN 등을 통해 이루어진다. 공식 홈페이지에는 프론트엔드 포럼도 별도로 운영되고 있다.<ref name="frontend">[https://rhymix.org/frontend 라이믹스 프론트엔드 포럼]</ref> 이 밖에 자료실과 쇼케이스도 운영되고 있어, 모듈, 애드온, 스킨, 레이아웃, 에디터, 테마 패키지 등을 확인할 수 있다.<ref name="pds">[https://rhymix.org/pds 라이믹스 자료실]</ref><ref name="showcase">[https://rhymix.org/showcase 라이믹스 쇼케이스]</ref>

== 버전 ==
라이믹스의 버전별 변경 사항은 공식 홈페이지의 [https://rhymix.org/news 뉴스 및 릴리즈 노트]에서 확인할 수 있다. 정식 버전은 압축 파일 형태로 제공되며, 이전 정식 버전 사용자를 위한 변경 파일 묶음도 함께 제공된다.<ref name="newslist" /> 가온 위키에도 버전별 릴리즈 노트가 [[라이믹스/릴리즈 노트]] 아래에 개별 문서로 정리되어 있다. 버전 번호 체계는 [[라이믹스/버전]] 문서를 참고할 수 있다.

=== 최근 릴리즈 ===
{| class="wikitable"
! 버전 !! 공개일 !! 보안 패치 !! 주요 내용
|-
| [[라이믹스/릴리즈 노트/2.1.36|2.1.36]] || 2026년 8월 12일 || 포함 || 2.1 개발 종료 및 2.2 준비 전환 발표
|-
| [[라이믹스/릴리즈 노트/2.1.35|2.1.35]] || 2026년 7월 8일 || 포함 || URL 파라미터 검증 취약점 수정
|-
| [[라이믹스/릴리즈 노트/2.1.34|2.1.34]] || 2026년 6월 26일 || 포함 || 쉬운설치 도입
|-
| [[라이믹스/릴리즈 노트/2.1.33|2.1.33]] || 2026년 5월 12일 || 포함 || 썸네일 생성 SSRF 취약점 수정
|-
| [[라이믹스/릴리즈 노트/2.1.32|2.1.32]] || 2026년 4월 1일 || 포함 || 애드온 관리 기능 RCE 취약점 수정
|-
| [[라이믹스/릴리즈 노트/2.1.31|2.1.31]] || 2026년 2월 26일 || 포함 || 확장 변수 IDOR 취약점 수정
|-
| [[라이믹스/릴리즈 노트/2.1.30|2.1.30]] || 2026년 2월 10일 || || 관리자 대시보드 검색 결과 개수 표시 등
|-
| [[라이믹스/릴리즈 노트/2.1.29|2.1.29]] || 2025년 12월 18일 || || 이미지 처리 메모리 계산 최적화
|}

=== 2.1 개발 종료와 2.2 ===
2026년 8월 12일 공개된 2.1.36 릴리즈 노트에서 개발진은 라이믹스 2.1을 긴급한 보안 패치 외에는 더 이상 업데이트하지 않고, 2.2 준비에 집중하겠다고 밝혔다. 2.2의 공개 일정과 주요 기능 로드맵은 별도로 공지할 예정이라고 안내되었다.<ref name="release-2136">[https://rhymix.org/news/1953194 Rhymix 2.1.36 Release Notes]</ref>

앞서 2.1.8 릴리즈 노트에서는 프리뷰로 제공되던 템플릿 문법 v2가 2.2에서 정식 지원될 예정이라고 안내된 바 있다.<ref name="release-218" />

=== Development Snapshot ===
공식 홈페이지에서는 정식 다운로드와 별도로 Development Snapshot도 제공한다. Development Snapshot은 개발 중인 최신 코드를 빠르게 사용할 수 있다는 장점이 있지만, 정식 버전에 비해 안정성이 낮을 수 있으므로 운영 사이트에 적용할 때는 주의해야 한다.<ref name="install">[https://rhymix.org/manual/introduction/install 라이믹스 설치]</ref>

== 설치 환경 ==
라이믹스를 설치하려면 공식 매뉴얼에서 제시하는 최소 사양을 만족해야 한다. 2026년 8월 기준 공식 문서의 주요 요구 사항은 다음과 같다.<ref name="requirements">[https://rhymix.org/manual/introduction/requirements 설치 환경]</ref> 자세한 내용은 [[라이믹스/매뉴얼/설치 환경]] 문서를 참고할 수 있다.

{| class="wikitable"
! 구분 !! 요구 사항
|-
| PHP || PHP 7.4 이상, PHP 8.2 이상 권장
|-
| 데이터베이스 || MySQL 5.7 이상 또는 MariaDB 10.6 이상
|-
| 필수 PHP 모듈 || curl, gd, iconv 또는 mbstring, json, openssl, PDO_MySQL, SimpleXML, Zend OPcache
|-
| 권장 PHP 모듈 || apcu, exif, fileinfo, intl, zip
|-
| 웹서버 설정 || Apache의 mod_rewrite 권장. nginx는 별도 rewrite 설정 필요
|-
| 쓰기 권한 || files 폴더에 쓰기 권한 필요
|-
| PHP 메모리 제한 || 최소 128MB, 대용량 이미지 처리 시 256MB 권장
|}

XE는 오래된 PHP 버전에서도 동작하는 경우가 있었지만, 라이믹스는 PHP 7.4 이상이 필요하다. 따라서 XE에서 라이믹스로 넘어오는 경우에는 PHP 버전, 데이터베이스 버전, PHP 확장 모듈, files 폴더 권한을 먼저 확인해야 한다.<ref name="xe-upgrade" />

== 설치 ==
라이믹스 설치는 공식 홈페이지에서 최신 정식 버전 또는 Development Snapshot을 다운로드한 뒤, 웹서버의 문서 루트에 업로드하여 진행할 수 있다. 압축 파일을 FTP 또는 SFTP로 업로드한 뒤 서버에서 압축을 풀거나, 로컬에서 압축을 푼 뒤 전체 파일을 업로드할 수 있다.<ref name="install" />

Git을 사용할 수 있는 서버라면 GitHub 저장소를 직접 clone하는 방식도 가능하다.

<syntaxhighlight lang="console">
git clone https://github.com/rhymix/rhymix.git
</syntaxhighlight>

Git으로 설치하면 이후 업데이트를 비교적 쉽게 적용할 수 있다. 다만 SSH 접속과 git 사용이 가능해야 하며, 서버 환경에 따라 권한 설정을 별도로 확인해야 한다. 웹호스팅과 가상 서버별 구체적인 설치 절차는 [[라이믹스/설치]] 문서를 참고할 수 있다.

설치 과정에서는 데이터베이스 접속 정보, 테이블 접두사, 최고관리자 계정, 표준 시간대, SSL 사용 여부 등을 입력한다. 대한민국 사용자를 대상으로 운영하는 사이트라면 표준 시간대는 일반적으로 Asia/Seoul을 사용한다.<ref name="install" />

== 업데이트 ==
라이믹스는 보안 패치와 버그 수정이 수시로 이루어지므로, 운영 사이트는 정기적으로 업데이트하는 것이 좋다. 공식 매뉴얼은 크게 두 가지 업데이트 방법을 안내한다.<ref name="update" />

=== 새 버전 덮어쓰기 ===
최신 버전의 압축 파일을 내려받아 기존 라이믹스 설치 경로에 덮어쓰는 방식이다. 라이믹스의 설정, 첨부파일, 캐시, 사용자 데이터 등은 주로 files 폴더와 데이터베이스에 저장되므로, 일반적인 업데이트 과정에서 코어 파일을 덮어써도 사이트 데이터가 삭제되지는 않는다.

다만 코어 파일을 직접 수정한 경우에는 수정 내역이 사라질 수 있으므로 주의해야 한다. 코어 파일을 직접 고치는 방식은 업데이트 충돌을 만들기 쉬우므로, 가능하면 모듈, 애드온, 스킨, 이벤트 핸들러 등 확장 기능으로 처리하는 것이 좋다.

=== git으로 업데이트 ===
Git으로 설치한 경우 다음 명령으로 현재 브랜치의 최신 코드를 받을 수 있다.

<syntaxhighlight lang="console">
git pull
</syntaxhighlight>

코어 파일을 수정하지 않았다면 이 방식이 가장 간단하다. 수정한 파일이 있는 경우에는 git stash, 별도 브랜치, merge 등을 이용하여 충돌을 관리해야 한다. 충돌 표시가 남아 있는 파일을 방치하면 화면이 비정상적으로 출력되거나 기능이 동작하지 않을 수 있으므로, 업데이트 후에는 반드시 <code>git status</code>를 확인하는 것이 좋다.

== XE 1.x에서 업그레이드 ==
XE 1.x 사이트는 일반적으로 라이믹스 코어 파일을 기존 XE 설치 경로에 덮어쓰는 방식으로 업그레이드할 수 있다. 공식 매뉴얼은 XE 코어 업데이트와 유사한 방식으로 진행할 수 있다고 설명한다.<ref name="xe-upgrade" />

다만 업그레이드 전에 다음 사항을 반드시 확인해야 한다.

* XE 1.8 미만 버전에서 라이믹스로 직접 업그레이드하는 것은 지원하지 않는다. 먼저 XE 1.8 이상, 가능하면 최신 XE 1.11 계열로 올린 뒤 라이믹스로 넘어가는 것이 권장된다.
* 라이믹스로 변환한 뒤에는 다시 XE로 돌아갈 수 없다.
* FTP 계정의 파일 전체와 데이터베이스를 각각 백업해야 한다.
* 관리자 계정으로 로그인한 상태에서 작업하는 것이 안전하다.
* 업그레이드 후 관리자 화면에서 표시되는 모듈 업데이트와 테이블 생성을 모두 완료해야 한다.
* 모든 업데이트 후 캐시파일 재생성을 실행해야 한다.
* 서드파티 자료의 호환성을 점검해야 한다.
* 라이믹스 2.1 이상에서는 관리자 대시보드에서 불필요한 옛 XE 코어 파일을 정리할 수 있다.<ref name="xe-upgrade" />

== 모듈, 애드온, 스킨 ==
라이믹스는 모듈, 애드온, 위젯, 레이아웃, 스킨, 에디터, 테마 패키지 등 다양한 확장 요소를 통해 기능과 디자인을 추가할 수 있다. 공식 자료실에서도 이러한 자료를 종류별로 분류하여 제공한다.<ref name="pds" />

모듈은 게시판, 회원, 포인트, 쇼핑몰 등 비교적 독립적인 기능 단위를 담당한다. 애드온은 페이지 처리 과정의 특정 지점에 개입하여 부가 기능을 수행하는 방식으로 동작하며, 자세한 내용은 [[라이믹스/애드온]] 문서를 참고할 수 있다. 스킨과 레이아웃은 화면 출력과 디자인을 담당하며, 에디터와 에디터 컴포넌트는 글쓰기 환경을 확장한다.

불필요한 애드온을 많이 활성화하면 사이트 속도와 유지보수에 영향을 줄 수 있다. 따라서 사용하지 않는 확장 기능은 비활성화하거나 삭제하고, 오래된 자료는 PHP 버전과 라이믹스 버전 호환성을 확인한 뒤 사용하는 것이 좋다.

=== 가온 위키의 모듈 문서 ===
가온 위키에는 개별 모듈을 다루는 문서가 별도로 작성되어 있다.

* [[라이믹스/모듈/Reaction]] — 게시물 반응 모듈
* [[라이믹스/모듈/소셜 로그인]] — 코어에서 분리된 소셜 로그인 모듈
* [[라이믹스/모듈/구충제]]

라이믹스의 동작을 방해하여 차단된 자료는 [[라이믹스/블랙리스트]] 문서에 정리되어 있다.

=== 쉬운설치 ===
2026년 6월 26일 공개된 [[라이믹스/릴리즈 노트/2.1.34|2.1.34]]부터는 '''쉬운설치''' 기능이 지원된다. 관리자 화면에서 공식 자료실의 자료를 FTP 접속 없이 바로 설치할 수 있는 기능이다.<ref name="easyinstall">[https://rhymix.org/news/1948052 쉬운설치 지원을 시작합니다]</ref>

쉬운설치 목록에 노출되는 자료는 공개·무료 자료 가운데 2025년 12월 이후 릴리즈 시스템을 이용해 등록하거나 갱신한 것, 또는 기존에 등록된 자료 중 설치 파일을 릴리즈로 변환한 것으로 한정된다. 설치 경로가 표준과 다른 테마 패키지와 기타 분류는 대상에서 제외된다.<ref name="easyinstall" />

목록 갱신에는 시간이 걸린다. 자료 API가 10~15분마다, Cloudflare 캐시가 5~10분마다, 개별 사이트가 4시간마다 갱신되므로, 새로 올라온 자료가 쉬운설치 화면에 나타나기까지 최대 4시간 30분가량 걸릴 수 있다.<ref name="easyinstall" />

공식 공지는 쉬운설치를 이용할 때 신뢰할 수 있는 개발자의 자료만 설치할 것을 권고한다. 서드파티 코드는 사이트의 모든 데이터에 접근할 수 있고 외부로 전송하는 것도 가능하므로, npm이나 Packagist에서 발견된 악성 패키지 사례와 같은 위험이 존재한다는 것이다.<ref name="easyinstall" />

== 서드파티 자료 호환성 ==
라이믹스는 XE 1.x 자료와의 호환성을 최대한 유지하려 하지만, 모든 서드파티 자료가 항상 정상 동작하는 것은 아니다. 특히 오래된 모듈이나 애드온은 PHP 최신 버전, 라이믹스의 보안 정책, 코어 기능 변화와 충돌할 수 있다.

공식 문서에는 XE에서 라이믹스로 업그레이드할 때 점검해야 할 서드파티 자료 호환성 체크리스트가 정리되어 있다.<ref name="thirdparty">[https://rhymix.org/manual/introduction/thirdparty-checklist 서드파티 자료 호환성 체크리스트]</ref> 예를 들어, 과거 XE용으로 쓰이던 일부 메일 발송, 자동 로그인, 멀티도메인, SEO 관련 기능은 라이믹스 코어 또는 시스템 설정에 흡수되었다. 반대로 일부 오래된 애드온은 더 이상 필요하지 않거나 정상적으로 작동하지 않을 수 있다.

라이믹스로 이전한 뒤에는 다음 항목을 점검하는 것이 좋다.

* 관리자 화면의 시스템 설정
* 보안 설정과 세션 관련 설정
* 메일 발송 설정
* 멀티도메인 설정
* SEO 설정
* 자동 로그인 관련 기능
* 게시판, 회원, 포인트, 커뮤니케이션 등 주요 모듈
* 오래된 애드온의 필요 여부
* PHP 8.x 환경에서 발생하는 경고 또는 오류

== 보안 ==
=== 취약점 식별 체계 ===
라이믹스는 자체 취약점 식별 번호인 RVE를 부여하여 관리한다. 번호는 연도와 일련번호를 조합한 형태로, 릴리즈 노트에 취약점 유형과 함께 표기된다.<ref name="newslist" />

2026년에는 확장 변수를 통한 IDOR, 애드온 관리 기능의 원격 코드 실행, 썸네일 생성 과정의 SSRF, 데이터 들여오기 모듈의 SSRF 및 정보 유출, 애드온 관리와 쉬운설치 모듈의 경로 탐색, 폼 전송 시 외부 URL 리다이렉트, URL 파라미터 검증 미비, referrer 헤더를 이용한 반사형 XSS, 모듈 관리자의 권한 초과 접근 등이 RVE-2026-1부터 RVE-2026-20 사이의 번호로 처리되었다.<ref name="release-2136" /><ref name="release-2134">[https://rhymix.org/news/1948042 Rhymix 2.1.34 Release Notes]</ref>

일부 취약점에는 한국인터넷진흥원(KISA)이 부여한 KVE 번호가 함께 표기된다. 데이터 들여오기 모듈의 SSRF에는 KVE-2026-0992가, 쉬운설치 모듈의 경로 탐색에는 KVE-2026-1185가, 모듈 관리자 권한 관련 취약점에는 KVE-2026-1661, KVE-2026-1662, KVE-2026-1666이 각각 부여되었다.<ref name="release-2136" /><ref name="release-2134" />

RVE 번호별 상세 목록과 대응 KVE 번호는 [[라이믹스/보안]] 문서에 정리되어 있다. 라이믹스의 동작을 방해하는 서드파티 자료는 블랙리스트로 처리될 수 있으며, 해당 내역은 [[라이믹스/블랙리스트]] 문서에서 확인할 수 있다.

=== 보안 관련 개선 ===
취약점 수정 외에도 보안을 강화하는 변경이 함께 이루어지고 있다. 2.1.34에서는 비밀번호 찾기 요청을 세션당 1분에 한 번으로 제한하고, 보안 설정에서 세션 ID 갱신을 제어할 수 있도록 하였다.<ref name="release-2134" /> 2.1.36에서는 로그인 비밀번호 입력란에 <code>autocomplete="off"</code>를 적용하고, 회원 정보나 비밀번호가 변경되면 세션 ID를 갱신하도록 하였으며, Guzzle 라이브러리를 최신 보안 패치 버전으로 갱신하였다.<ref name="release-2136" />

=== 버그 및 취약점 제보 ===
일반적인 버그나 개선 제안은 [https://github.com/rhymix/rhymix/issues GitHub 이슈]에 등록할 수 있다. 이슈를 등록할 때는 실행 환경, 라이믹스 버전, PHP 버전, 운영체제, 브라우저, 오류 메시지, 스크린샷, 재현 가능한 URL 등을 함께 제공하는 것이 좋다.<ref name="github-guide">[https://rhymix.org/manual/contrib/github GitHub 이슈 및 PR 작성]</ref>

보안 취약점은 공개 이슈에 올리지 말고 [mailto:devops@rhymix.org devops@rhymix.org]로 제보해야 한다. 공식 저장소와 공식 문서 모두 보안 취약점은 공개적으로 언급하지 말고 개발진에게 비공개로 알려 달라고 안내한다.<ref name="github-readme" /><ref name="github-guide" />

== 공식 자료실과 생태계 ==
라이믹스 공식 홈페이지에는 자료실이 운영되고 있다. 자료실은 모듈, 애드온, 위젯, 레이아웃, 스킨, 에디터, 에디터 컴포넌트, 테마 패키지, 기타 자료 등으로 분류된다.<ref name="pds" />

또한 쇼케이스 게시판에서는 라이믹스를 기반으로 제작된 사이트나 서비스 사례를 확인할 수 있다.<ref name="showcase" /> 라이믹스는 커뮤니티 사이트, 정보 공유 사이트, 기업 홈페이지, 자체 서비스 구축 등 다양한 용도로 사용할 수 있다.

공식 채널 외에도 이용자들이 운영하는 문서·정보 사이트가 있다. 라이믹스 가이드는 변경 내역과 레퍼런스를 별도로 정리하고 있으며,<ref name="rxguide">[https://rhymix-guide.github.io 라이믹스 가이드]</ref> 라이믹스 꿀팁은 활용 팁과 프로젝트 관련 글을 모아 두고 있다.<ref name="rxtip">[https://rxtip.kr 라이믹스 꿀팁]</ref>

== 로고와 BI ==
라이믹스의 공식 로고와 BI 가이드는 공식 홈페이지의 BI Guide에서 제공한다. 이 문서에는 로고 사용 원칙, 공식 색상, 글꼴, 아이콘, PNG·SVG·AI 원본 파일, PDF 가이드 등이 정리되어 있다.<ref name="bi">[https://rhymix.org/bi Rhymix BI Guide]</ref>

BI Guide에 따르면 Rhymix의 이름과 로고는 (주)포에시스가 소유하며, 오픈소스 문화와 프로젝트 발전에 기여하는 방향으로 사용하는 것을 원칙으로 한다. 로고는 공식 색상 조합과 형태를 왜곡하지 않는 범위에서 사용해야 한다.<ref name="bi" />

=== 로고 변천 ===
{| class="wikitable"
| [[파일:rhymix.png|300px]]
| [[파일:rhymix_old.png|300px]]
|-
! 현 라이믹스의 로고
! 예전 라이믹스의 로고
|}

== 개발 참여 ==
라이믹스의 개발은 GitHub에서 이루어진다. 버그 제보, 기능 제안, 코드 기여는 GitHub 이슈와 Pull Request를 통해 진행할 수 있다. 공식 문서는 이슈 작성 전에 같은 문제가 이미 등록되어 있는지 검색하고, 서버 환경과 라이믹스 버전, PHP 버전, 오류 메시지, 재현 방법 등을 함께 제공하도록 안내한다.<ref name="github-guide" />

Pull Request를 작성할 때는 공식 코딩 규칙을 참고해야 한다. 라이믹스 코어 코드는 지원하는 모든 PHP 버전에서 정상 동작해야 하며, 사소한 경고나 deprecated 오류도 방치하지 않는 것을 목표로 한다.<ref name="coding">[https://rhymix.org/manual/contrib/coding-standards 코딩 규칙]</ref>

== XE Admin Help ==
XE 시절 관리자 화면에는 오래된 XE Admin Help 문서가 포함되어 있었다. 그러나 해당 문서는 XE의 오래된 버전을 기준으로 작성되어 최신 라이믹스의 화면과 기능을 설명하기에 적합하지 않았다.

라이믹스에서는 오래된 XE 매뉴얼을 제거하고, 공식 문서를 별도 저장소와 공식 홈페이지 매뉴얼로 관리하는 방향으로 정리하였다.<ref name="old-manual">[https://github.com/rhymix/rhymix/pull/1073 오래된 XE 매뉴얼 삭제 PR]</ref> 현재는 [https://rhymix.org/manual 공식 매뉴얼]과 [https://github.com/rhymix/rhymix-docs rhymix-docs 저장소]를 참고하는 것이 좋다.

== 관련 문서 ==

* [[XpressEngine]]
* [[XETOWN]]
* [[라이믹스/버전]]
* [[라이믹스/릴리즈 노트]]
* [[라이믹스/보안]]
* [[라이믹스/라이선스]]
* [[라이믹스/XE와의 차이점]]
* [[라이믹스/XE에서 넘어오기]]
* [[라이믹스/매뉴얼]]
* [[라이믹스/매뉴얼/설치 환경]]
* [[라이믹스/매뉴얼/라이믹스 업데이트]]
* [[라이믹스/매뉴얼/도메인 변경]]
* [[라이믹스/라우터]]
* [[라이믹스/애드온]]
* [[라이믹스/블랙리스트]]
* [[라이믹스/모듈/Reaction]]
* [[라이믹스/모듈/구충제]]
* [[라이믹스/버그]]
* [[라이믹스/설치]]
* [[라이믹스/Next 라이믹스]]
* [[라이믹스/모듈/소셜 로그인]]

== 외부 링크 ==

* [https://rhymix.org 라이믹스 공식 홈페이지]
* [https://rhymix.org/about 라이믹스 소개]
* [https://rhymix.org/manual 라이믹스 공식 매뉴얼]
* [https://rhymix.org/news 라이믹스 릴리즈 노트]
* [https://rhymix.org/pds 라이믹스 자료실]
* [https://rhymix.org/showcase 라이믹스 쇼케이스]
* [https://rhymix.org/frontend 라이믹스 프론트엔드 포럼]
* [https://rhymix.org/bi Rhymix BI Guide]
* [https://github.com/rhymix/rhymix 라이믹스 GitHub 저장소]
* [https://github.com/rhymix/rhymix-docs 라이믹스 공식 문서 저장소]
* [https://xetown.com XETOWN]

== 각주 ==
<references />

[[분류:CMS]]
[[분류:PHP 소프트웨어]]
[[분류:오픈소스]]
[[분류:라이믹스]]

XpressEngine/애드온

2026-08-21T05:59:05Z

Gaon12: 새 문서. 애드온 색인

== 개요 ==
[[XpressEngine]]와 [[라이믹스]]에서 '''애드온'''(addon)은 페이지가 처리되는 과정의 정해진 지점에 끼어들어 동작을 바꾸거나 기능을 덧붙이는 확장 요소를 말한다.

[[XpressEngine/모듈|모듈]]이 게시판이나 회원처럼 독립적인 기능 단위를 맡고 자체 화면과 URL을 갖는 것과 달리, 애드온은 자기 화면이 없다. 이미 진행 중인 요청에 개입할 뿐이다. 이 때문에 비교적 적은 코드로 사이트 전반에 영향을 주는 기능을 만들 수 있다는 것이 장점이자, 잘못 만들면 사이트 전체가 느려지거나 깨질 수 있다는 것이 단점이다.

본문의 URL을 자동으로 링크로 바꾸거나, 접속 통계를 기록하거나, 출력 직전의 HTML에 스크립트를 끼워 넣는 것이 대표적인 쓰임이다.

== 동작 방식 ==
애드온 파일은 요청 처리 과정에서 코어가 정해 둔 '''호출 지점'''마다 통째로 실행된다. 그래서 애드온은 파일 안에서 <code>$called_position</code> 값을 확인하여 필요한 시점에만 동작하도록 작성한다.

{| class="wikitable"
! 호출 지점 !! 시점
|-
| <code>before_module_init</code> || 모듈이 초기화되기 전. 요청 처리의 가장 이른 단계
|-
| <code>before_module_proc</code> || 모듈의 실제 처리가 시작되기 전
|-
| <code>after_module_proc</code> || 모듈의 처리가 끝난 뒤. 처리 결과를 가공할 수 있다
|-
| <code>before_display_content</code> || 최종 HTML이 출력되기 직전
|}

실제 코드는 대체로 이런 형태이다.

<syntaxhighlight lang="php">
if ($called_position == 'after_module_proc' && Context::getResponseMethod() == 'HTML')
{
// 이 지점에서만 수행할 작업
}
</syntaxhighlight>

관리자 화면이나 검색엔진 크롤러에서는 동작할 필요가 없는 경우가 많으므로, <code>Context::get('module') != 'admin'</code>이나 <code>!isCrawler()</code> 같은 조건을 함께 확인하는 것이 일반적이다.

== 파일 구조 ==
애드온은 설치 경로의 <code>addons</code> 폴더 아래에 애드온 이름과 같은 폴더를 만들어 배치한다.

<syntaxhighlight lang="text">
addons/
└─ 애드온이름/
├─ 애드온이름.addon.php ← 실행되는 본체
└─ conf/
└─ info.xml ← 이름, 설명, 제작자, 설정 항목
</syntaxhighlight>

<code>conf/info.xml</code>에는 여러 언어의 제목과 설명을 함께 넣을 수 있다.

== 애드온 찾기와 설치 ==
=== 찾기 ===
[https://rhymix.org/pds 라이믹스 자료실]이나 [[Rhymix Auto Install Repository]], 개발자의 깃허브 저장소 등에서 찾을 수 있다. XE 공식 자료실은 현재 이미지 출력이 되지 않는 등 관리가 되지 않고 있다.

자료를 고를 때는 호환성 정보를 반드시 확인하자. 오래된 애드온은 최신 PHP에서 동작하지 않거나, 라이믹스에서 블랙리스트로 차단되어 있을 수 있다.

=== 설치 ===
FTP 클라이언트로 설치 경로의 <code>addons</code> 폴더에 애드온 폴더를 업로드한다. 이때 <code>addons/이름/이름/파일들</code>처럼 폴더가 이중으로 중첩되지 않도록 주의해야 한다.

업로드한 뒤 <code>관리자 페이지 → 고급 → 애드온</code>에서 사용으로 설정해야 실제로 동작한다. PC와 모바일에서의 사용 여부를 따로 지정할 수 있다.

라이믹스 [[라이믹스/릴리즈 노트/2.1.34|2.1.34]] 이상에서는 공식 자료실에 등록된 자료를 관리자 화면에서 바로 설치하는 쉬운설치를 이용할 수도 있다.

== 가온 위키의 애드온 문서 ==
{| class="wikitable"
! 애드온 !! 제작자 !! 라이선스 !! 라이믹스 블랙리스트
|-
| [[XpressEngine/애드온/언어 자동 선택|언어 자동 선택]] || [[기진곰]] || LGPL v2 || 등재됨 (코어에 같은 기능 있음)
|-
| [[XpressEngine/애드온/ZipperUpper!|ZipperUpper!]] || [[기진곰]] || LGPL v2 || 등재됨 (코어에 스크립트 합치기 기능 있음)
|-
| [[XpressEngine/애드온/검색어 오타수정 애드온|검색어 오타수정 애드온]] || 즈베즈다 || GPL v2 || 등재되지 않음
|}

== 라이믹스에서의 주의 ==
XE 시절 널리 쓰이던 애드온 가운데 상당수는 라이믹스에서 사용할 수 없다. 같은 기능이 이미 코어에 들어가 있거나, 코어와 충돌하여 다른 기능의 동작을 방해하기 때문이다. 이러한 자료는 블랙리스트로 처리되어 활성화되지 않는다.

블랙리스트에 오른 애드온과 대체 방법은 [[라이믹스/블랙리스트]] 문서에 정리되어 있다.

또한 애드온은 요청 처리 과정에 매번 개입하므로, 활성화된 애드온이 많아질수록 페이지 처리 시간이 늘어난다. 사용하지 않는 애드온은 비활성화하거나 삭제하자.

라이믹스의 애드온 구조에 대한 자세한 설명은 [[라이믹스/애드온]] 문서를 참고하자.

== 같이 보기 ==

* [[XpressEngine]]
* [[XpressEngine/모듈]]
* [[라이믹스]]
* [[라이믹스/애드온]]
* [[라이믹스/블랙리스트]]


[[분류:XE 애드온]]

XpressEngine/모듈/소셜XE

2026-08-21T05:59:02Z

Gaon12: 이중 넘겨주기 해소. 최종 대상인 라이믹스/모듈/소셜 로그인으로 직결

#넘겨주기 [[라이믹스/모듈/소셜 로그인]]

틀:상위문서

2026-08-21T05:58:47Z

Gaon12: 새 틀. 하위 문서 상단에 상위 문서를 표시

<includeonly><templatestyles src="틀:상위문서/styles.css" /><div class="gw-hatnote" role="note">'''상위 문서''': [[{{{1}}}]]{{#if:{{{2|}}}| · [[{{{2}}}]]}}{{#if:{{{3|}}}| · [[{{{3}}}]]}}</div></includeonly><noinclude>
하위 문서 최상단에 붙여 상위 문서를 표시하는 틀이다. 상위 문서는 최대 3개까지 지정할 수 있다.

스타일은 [[틀:상위문서/styles.css]]에 분리되어 있으며 Codex 디자인 토큰을 사용하므로 다크 모드에서 자동으로 색이 바뀐다.

== 사용법 ==
<pre>{{틀:상위문서|라이믹스}}</pre>
<pre>{{틀:상위문서|라이믹스|XpressEngine}}</pre>

== 변수 ==
{| class="wikitable"
! 변수 !! 설명 !! 필수
|-
| 1 || 상위 문서 이름 || 필수
|-
| 2 || 두 번째 상위 문서 || 선택
|-
| 3 || 세 번째 상위 문서 || 선택
|}

== 사용하는 문서 ==
* [[라이믹스/라이선스]]
* [[라이믹스/보안]]
* [[라이믹스/릴리즈 노트]]
* [[라이믹스/XE와의 차이점]]

[[분류:틀]]
[[분류:안내 틀]]
</noinclude>

틀:상위문서/styles.css

2026-08-21T05:58:23Z

Gaon12: 틀:상위문서 전용 스타일. Codex 디자인 토큰 사용

/* 틀:상위문서 전용 스타일
Codex 디자인 토큰을 사용하므로 다크 모드에서 자동으로 색이 바뀐다. */

.gw-hatnote {
margin: 0 0 0.6em 0;
padding: 0.4em 0.8em;
border-left: 4px solid var( --border-color-base, #a2a9b1 );
background-color: var( --background-color-neutral-subtle, #f8f9fa );
color: var( --color-base, #202122 );
font-size: 0.92em;
}

유니코드

2026-08-20T07:39:08Z

Gaon12: 시작

== 개요 ==
'''유니코드'''(Unicode)는 전 세계에서 사용되는 문자, 기호, 이모지 등을 컴퓨터에서 일관되게 표현하고 다루기 위해 만든 '''국제 문자 인코딩 표준'''이다. 쉽게 말하면, 전 세계 모든 언어의 글자 하나하나에 고유한 번호(코드)를 붙여서, 어떤 컴퓨터·운영체제·프로그램에서도 같은 문자를 같은 방식으로 주고받을 수 있게 만든 규칙이라고 보면 된다.

과거에는 나라마다, 심지어 회사마다 자기들만의 문자 인코딩 방식(EUC-KR, Shift-JIS, ASCII 등)을 따로 썼기 때문에, 서로 다른 인코딩으로 만든 문서를 열면 글자가 깨지는 일이 흔했다. 이런 '''문자 깨짐(모지바케, 몬스터 텍스트)''' 문제를 근본적으로 해결하기 위해 등장한 것이 유니코드다.

유니코드는 [[유니코드 컨소시엄]](Unicode Consortium)이라는 비영리 단체가 관리하며, 애플·구글·마이크로소프트·IBM 등 주요 IT 기업들이 회원사로 참여하고 있다.

== 역사 ==
* '''1987년''': 제록스와 애플의 엔지니어들이 각 나라의 문자 인코딩을 통합하자는 아이디어를 처음 논의하기 시작했다.
* '''1991년 10월''': 유니코드 1.0.0 버전이 정식으로 발표되었다. 당시에는 모든 문자를 2바이트(16비트, 최대 65,536자)로 표현하면 충분할 것이라고 생각했다.
* '''1992년 6월''': 1.0.1 버전에서 [[CJK 통합 한자]](CJK Unified Ideographs), 즉 한자 영역이 처음 정의되었다.
* '''1993년 6월''': 1.1 버전에서 기존에 들어가 있던 한글 2,350자에 4,306자가 추가로 할당되었다.
* '''1996년 7월''': 2.0 버전이 발표되면서 이른바 '''한글 대이동 사건'''이 벌어졌다. 한국 측의 요청으로 기존 한글 배치를 전부 삭제하고, 현대 한글로 조합 가능한 '''11,172자 전체'''를 U+AC00~U+D7A3 영역에 새로 배치했다. 이 사건 이후로 "한번 할당된 문자의 코드는 다시는 옮기지 않는다"는 원칙이 확립되었다.
* 그 후로도 3.0(1999), 4.0(2003), 5.0(2006), 6.0(2010, 이모지 최초 지원), 8.0(2015), 10.0(2017), 13.0(2020) 등 문자 집합을 계속 확장해 왔다.
* '''2025년 9월''': [[유니코드 17.0]]이 발표되었다. 이 시점 기준 최신 정식 버전이다.
* '''2026년 9월 16일(예정)''': [[유니코드 18.0]] 출시가 유니코드 기술위원회(UTC) 제188차 회의에서 공식 승인되었다. 특이하게도 그동안 화요일에 맞춰 오던 정기 릴리스 관행을 깨고 처음으로 '''수요일'''에 출시되는데, 릴리스 관리팀은 "월요일이 공휴일과 겹치는 경우가 많아 화요일 배포가 번거롭다"는 이유를 들었다. 원래 인도 북동부 쿠르말리어 표기에 쓰이는 '''치소이 문자(Chisoi script)'''도 포함될 예정이었으나 막판에 이번 릴리스에서 제외되었다.

== 왜 만들어졌는가 ==
유니코드 이전에는 다음과 같은 지역별 인코딩이 난립했다.
* 한국: EUC-KR, [[완성형]]/[[조합형]]
* 일본: Shift-JIS, EUC-JP
* 중국: GB2312, Big5(대만)
* 영어권: ASCII, ISO-8859 계열

문제는 같은 코드 번호라도 인코딩에 따라 전혀 다른 문자를 가리킨다는 점이었다. 예를 들어 한국어 EUC-KR로 작성된 문서를 일본어 Shift-JIS로 읽으면 글자가 전혀 다른 문자로 뒤바뀌어 버렸다. 인터넷이 전 세계로 퍼지면서 이 문제는 더 이상 무시할 수 없는 수준이 되었고, "전 세계 모든 문자에 겹치지 않는 고유 번호를 하나씩 부여하자"는 발상에서 유니코드가 탄생했다.

== 구조 ==
=== 코드 포인트 ===
유니코드에서 문자 하나하나에 부여된 고유 번호를 '''코드 포인트'''(code point)라고 부른다. 표기할 때는 'U+' 뒤에 16진수를 붙여서 쓴다. 예를 들어 알파벳 대문자 A는 U+0041, 한글 '가'는 U+AC00이다.

현재 유니코드는 U+0000부터 U+10FFFF까지, 총 '''1,114,112개'''의 코드 포인트 공간을 가지고 있다. 이 중 실제로 문자가 할당된 것은 일부이고 나머지는 앞으로 새 문자를 위해 비워둔 공간이거나, 사용자가 자유롭게 쓸 수 있는 [[사용자 정의 영역]](Private Use Area)이다.

=== 평면(Plane) ===
유니코드 공간은 편의상 65,536개(0x10000)씩 묶어 총 17개의 '''평면'''(plane)으로 나눈다.
{|class="wikitable"
! 평면 번호 !! 범위 !! 이름 !! 설명
|-
| 0 || U+0000~U+FFFF || 기본 다국어 평면(BMP) || 한글, 한자, 라틴 문자 등 실생활에서 가장 많이 쓰는 문자 대부분이 위치
|-
| 1 || U+10000~U+1FFFF || 보조 다국어 평면(SMP) || 고대 문자, 이모지, 수학 기호 다수
|-
| 2 || U+20000~U+2FFFF || 보조 표의 문자 평면(SIP) || 잘 쓰이지 않는 CJK 확장 한자
|-
| 3 || U+30000~U+3FFFF || 제3 표의 문자 평면(TIP) || 추가 한자 확장 영역
|-
| 14 || U+E0000~U+EFFFF || 보조 특수 목적 평면(SSP) || 언어 태그 등 특수 제어용
|-
| 15~16 || U+F0000~U+10FFFF || 사용자 정의 영역(PUA) || 표준에 없는 문자를 개인/조직이 임의로 정의해 쓰는 공간
|}

=== 인코딩 방식: UTF-8, UTF-16, UTF-32 ===
유니코드는 "어떤 문자에 어떤 번호를 매길지"를 정한 표준일 뿐이고, 그 번호를 실제로 컴퓨터 메모리에 몇 바이트로 어떻게 저장할지는 별도로 정해야 한다. 이를 위한 대표적인 인코딩 방식이 세 가지 있다.

* '''UTF-8'''
** 문자에 따라 1바이트에서 4바이트까지 가변적으로 사용한다.
** 영어(ASCII) 문자는 기존 ASCII와 완전히 호환되게 1바이트로 저장되고, 한글이나 한자는 보통 3바이트가 필요하다.
** 웹 페이지, 이메일, 대부분의 프로그래밍 언어 소스코드 등 인터넷 환경에서 사실상 표준으로 자리잡았다.
* '''UTF-16'''
** 대부분의 문자를 2바이트로, 기본 다국어 평면을 벗어나는 문자(이모지 등)는 [[서로게이트 페어]](surrogate pair)를 이용해 4바이트로 저장한다.
** 자바(Java), 자바스크립트, 윈도우 내부 문자열 처리 등에서 많이 사용된다.
* '''UTF-32'''
** 모든 문자를 예외 없이 고정 4바이트로 저장한다.
** 구조가 단순하지만 저장 공간을 많이 차지해서 실제로는 잘 쓰이지 않는다.

=== BOM(Byte Order Mark) ===
파일 맨 앞에 붙어서 이 파일이 어떤 인코딩(UTF-8/UTF-16LE/UTF-16BE)으로 저장되었는지, 그리고 바이트 순서(엔디언)가 어떤지 알려주는 표식이다. UTF-8에서는 필수는 아니지만, 특히 윈도우 메모장 등에서 자동으로 붙이는 경우가 있어 프로그램에 따라 파일 맨 앞에 이상한 문자가 나타나는 원인이 되기도 한다.

== 한글과 유니코드 ==
현대 한글은 초성 19개, 중성 21개, 종성(받침 없음 포함) 28개의 조합으로 총 '''11,172자'''를 만들 수 있으며, 이 글자들은 앞서 언급한 '''한글 대이동 사건''' 이후 U+AC00부터 U+D7A3까지 순서대로 빠짐없이 배정되어 있다.

특정 한글 글자의 코드는 다음 공식으로 계산할 수 있다.
코드값 = (초성 순번 × 588) + (중성 순번 × 28) + 종성 순번 + 44032(=0xAC00)

이 외에도 유니코드에는 옛한글 자모를 표현하기 위한 '''한글 자모 확장-A/B''' 영역과, 현대 한글에 쓰이지 않는 낱자를 위한 '''한글 호환 자모''' 영역이 따로 마련되어 있어, 훈민정음 창제 당시의 옛한글까지도 이론적으로는 표현이 가능하다.

== 이모지와 유니코드 ==
[[이모지]] 역시 유니코드 표준의 일부로 관리된다. 2010년 10월 발표된 유니코드 6.0에서 처음으로 이모지가 정식 지원되었으며, 이는 원래 일본 이동통신사에서 쓰이던 이모지와의 호환성을 확보하기 위한 목적이 컸다. 이후 매 버전마다 새로운 이모지가 꾸준히 추가되고 있으며, 다가올 유니코드 18.0에도 '금이 간 얼굴', '유성' 등 새로운 이모지들이 공개된 바 있다.

다만 유니코드 표준 자체는 이모지의 '''코드 포인트'''(어떤 번호를 쓸지)만 규정할 뿐, 실제로 그 이모지가 어떤 모양으로 그려질지는 애플, 구글, 삼성 등 각 플랫폼 제조사가 자체적으로 디자인한다. 그래서 같은 이모지라도 아이폰과 갤럭시에서 모양이 다르게 보이는 것이다.

== 유니코드 버전 변천사 ==
{|class="wikitable"
! 버전 !! 발표 시기 !! 주요 내용
|-
| 1.0 || 1991년 10월 || 최초 발표
|-
| 2.0 || 1996년 7월 || 한글 대이동, 4바이트 확장 개념 도입
|-
| 3.0 || 1999년 9월 || 여러 고대 문자 체계 추가
|-
| 4.0 || 2003년 4월 || 표의 문자 확장
|-
| 5.0 || 2006년 7월 || 다수의 소수 문자 체계 추가
|-
| 6.0 || 2010년 10월 || '''이모지 최초 정식 지원'''
|-
| 8.0 || 2015년 6월 || 이모지 피부색 표현(스킨톤) 도입
|-
| 10.0 || 2017년 6월 || 비트코인 기호 등 추가
|-
| 13.0 || 2020년 3월 || 코로나19 관련 이모지 다수 추가
|-
| 15.0 || 2022년 9월 || 신규 문자 및 이모지 추가
|-
| 16.0 || 2024년 9월 || 신규 문자 및 이모지 추가
|-
| '''17.0''' || '''2025년 9월''' || '''현재 기준 최신 정식 버전'''
|-
| 18.0(예정) || 2026년 9월 16일 || 최초로 수요일 릴리스, 신규 문자·이모지 추가 예정
|}

== 장점과 한계 ==
=== 장점 ===
* 전 세계 거의 모든 문자 체계를 하나의 표준으로 통일해, 서로 다른 언어 간 문서 교환이 훨씬 쉬워졌다.
* ASCII와 하위 호환되는 UTF-8 덕분에 기존 영어 기반 시스템과의 호환성 문제가 크지 않다.
* 웹 표준(HTML, XML), 대부분의 최신 운영체제와 프로그래밍 언어가 기본적으로 유니코드를 지원한다.

=== 한계와 논란 ===
* '''한중일 통합 한자(Han unification)''' 문제: 한국, 중국, 일본, 대만에서 모양이 조금씩 다른 한자를 유니코드에서는 하나의 코드로 통합해버린 경우가 있어, 특정 지역의 한자 글꼴을 정확히 표현하기 어렵다는 비판이 있다.
* 유니코드 표준이 계속 확장되면서 예전에는 존재하지 않던 문자, 기호, 이모지가 새 버전마다 계속 추가되기 때문에, 오래된 시스템이나 폰트에서는 최신 문자가 깨져 보이거나 네모(▢, '두부')로 표시되는 경우가 흔하다.
* 서로게이트 페어, 결합 문자(combining character), 정규화(NFC/NFD) 등 개념이 복잡해서, 프로그래밍할 때 문자열 길이 계산이나 자르기에서 실수가 자주 발생한다.

== 관련 문서 ==
* [[ASCII]]
* [[UTF-8]]
* [[EUC-KR]]
* [[완성형]]
* [[조합형]]
* [[이모지]]
* [[한글]]
* [[문자 인코딩]]

[[분류:문자 인코딩]]
[[분류:유니코드]]

Svelte

2026-07-31T06:32:45Z

Gaon12: 문서 최신화

{| class="wikitable" style="float:right; margin-left:10px; text-align:center;"
|-
! colspan="2" | Svelte
|-
| colspan="2" | [[파일:Svelte Logo.svg|150px]]
|-
! '''개발자'''
| [[리치 해리스]] 외 Svelte 코어팀
|-
! '''최초 출시'''
| [[2016년]]
|-
! '''최신 버전'''
| Svelte 5.x (Runes 기반)
|-
! '''장르'''
| 컴파일러 기반 프론트엔드 프레임워크
|-
! '''라이선스'''
| [[MIT 라이선스|MIT]]
|}

== 개요 ==
'''Svelte'''(스벨트)는 [[자바스크립트]] 진영의 프론트엔드 프레임워크로, [[2016년]] [[리치 해리스]](Rich Harris)가 처음 발표했다. [[리액트]]나 [[뷰]] 같은 기존 프레임워크가 브라우저에서 런타임에 [[가상 DOM]]을 돌려가며 화면을 갱신하는 것과 달리, Svelte는 '''빌드 시점(컴파일 타임)'''에 컴포넌트 코드를 분석해서 DOM을 직접 조작하는 순수 자바스크립트 코드로 미리 변환해버린다. 그래서 "프레임워크가 아니라 컴파일러"라는 표현이 자주 따라붙는다.

결과물에 프레임워크 런타임 코드가 거의 딸려오지 않기 때문에 번들 크기가 작고, 초기 로딩과 인터랙션 반응 속도가 빠른 편이라 개발자들 사이에서 평가가 꾸준히 좋다. 실제로 State of JS 설문에서 매년 만족도 최상위권에 이름을 올리는 프레임워크이기도 하다.

== 역사 ==
* '''2016년''' - 리치 해리스가 Svelte 1을 공개. 당시엔 실험적인 프로젝트에 가까웠다.
* '''2019년''' - Svelte 3 출시. 반응형 문법(`$:`)과 단일 파일 컴포넌트(`.svelte`) 형태가 자리 잡으며 사실상 지금 알려진 Svelte의 원형이 완성됐다.
* '''2022년''' - 풀스택 메타프레임워크 '''SvelteKit'''이 정식 1.0으로 출시. [[Next.js]], [[Nuxt.js]]의 경쟁 상대로 언급되기 시작.
* '''2024년 10월''' - '''Svelte 5''' 정식 출시. 반응성 모델을 통째로 갈아엎은 '''Runes'''(룬) 시스템을 도입하면서 사실상 프레임워크의 두 번째 챕터가 시작됐다. 동시에 SvelteKit도 2.x로 올라가며 Runes를 정식 지원.
* 이후 마이너 업데이트가 꾸준히 이어지고 있으며, 2026년 기준 Svelte는 5.5x 버전대, SvelteKit은 2.5x 버전대에서 유지보수되는 중이다.<ref>커뮤니티 개발 블로그 및 패키지 트래킹 사이트 기준(2026년 상반기 시점 관측치이며, 정확한 최신 버전은 npm 등에서 직접 확인 필요).</ref>

== 특징 ==
* '''컴파일러 기반''' - [[가상 DOM]]을 아예 쓰지 않는다. 빌드 시점에 "이 상태가 바뀌면 이 DOM 노드의 이 부분만 갱신하면 된다"는 코드를 정적으로 만들어버리기 때문에, 런타임에 변경 사항을 비교(diffing)하는 과정 자체가 없다.
* '''작은 번들 크기''' - 프레임워크 런타임을 거의 가져가지 않다 보니, 같은 기능을 구현해도 결과물 JS 용량이 리액트/뷰 대비 작게 나오는 경우가 많다.
* '''단일 파일 컴포넌트''' - `.svelte` 확장자 하나에 마크업(HTML), 스타일(CSS), 로직(JS/TS)을 다 몰아넣는 구조. 파일 하나만 열면 컴포넌트의 전부를 볼 수 있어서 진입장벽이 낮다는 평이 많다.
* '''문법이 HTML에 가까움''' - JSX처럼 별도 문법을 배울 필요 없이, 순수 HTML에 약간의 확장 문법(`{ }`, `{#if}`, `{#each}` 등)만 얹은 형태라 처음 접해도 낯설지 않다.
* '''Runes 기반 명시적 반응성'''(Svelte 5~) - 아래 문단 참고.

== 주요 개념 ==
=== 컴포넌트 기본 구조 ===
<syntaxhighlight lang="svelte">
<script>
let name = 'Svelte';
</script>

<h1>Hello {name}!</h1>

<style>
h1 {
color: purple;
}
</style>
</syntaxhighlight>

=== Runes: Svelte 5의 반응성 재설계 ===
Svelte 4까지는 `let count = 0;` 처럼 그냥 변수를 선언하고 대입하면 컴파일러가 "어? 이 변수는 반응형이네" 하고 '''암묵적으로''' 알아서 추적해주는 방식이었다. 편하긴 한데, 프로젝트가 커지면 "이게 왜 리렌더링이 안 되지?" 같은 디버깅이 골치 아파지는 단점이 있었다.

Svelte 5에서는 이걸 뒤엎고, `$state`, `$derived`, `$effect`, `$props` 같은 '''룬(rune)'''이라는 특수 키워드를 코드에 직접 명시하는 방식으로 바꿨다. "이 변수는 반응형으로 쓸 거다"라고 개발자가 직접 선언하는 셈이라, 코드만 봐도 어디가 반응형인지 한눈에 파악할 수 있게 됐다는 게 코어팀의 설명이다. 이 룬들은 함수 호출이 아니라 컴파일러가 알아보는 특수 문법이며, `.svelte` 파일 밖에서도(`.svelte.js`, `.svelte.ts`) 사용할 수 있어 상태 로직을 컴포넌트 바깥으로 분리하기도 훨씬 쉬워졌다.

<syntaxhighlight lang="svelte">
<script>
// Svelte 4 스타일 (구문법, 여전히 하위 호환됨)
let count = 0;
$: doubled = count * 2;
</script>

<script>
// Svelte 5 Runes 스타일
let count = $state(0);
let doubled = $derived(count * 2);
</script>

<button onclick={() => count++}>
Count: {count}, Doubled: {doubled}
</button>
</syntaxhighlight>

이벤트 바인딩 문법도 `on:click`에서 표준 DOM 속성에 가까운 `onclick`으로 바뀌는 등 세부적인 변화가 있다. 다만 Svelte 코어팀은 하위 호환성을 강하게 신경 써서, 기존 Svelte 4식 컴포넌트도 강제 마이그레이션 없이 그대로 동작하도록 설계했다. 덕분에 기존 프로젝트는 새 컴포넌트에만 룬을 적용하는 식으로 점진적으로 넘어갈 수 있다.

=== Props ===
<syntaxhighlight lang="svelte">
<script>
// Svelte 5
let { message } = $props();
</script>

<p>{message}</p>
</syntaxhighlight>

=== 반복문/조건문 ===
<syntaxhighlight lang="svelte">
{#if count > 0}
<p>양수입니다</p>
{:else}
<p>0 이하입니다</p>
{/if}

{#each items as item}
<li>{item}</li>
{/each}
</syntaxhighlight>

== SvelteKit ==
'''SvelteKit'''은 Svelte 위에서 돌아가는 풀스택 메타프레임워크로, [[Next.js]]나 [[Nuxt.js]]의 포지션과 비슷하다. 파일 기반 라우팅, 서버사이드 렌더링(SSR), 정적 사이트 생성(SSG), API 라우트, 폼 액션(form actions) 등을 기본 제공한다.

Svelte 5와 함께 SvelteKit 2로 넘어오면서 내부적으로도 Runes에 맞춰 API가 정리됐다. 예를 들어 예전에는 `$app/stores`에서 스토어를 가져와 `$page` 처럼 접두사 `$`를 붙여 구독하는 방식이었는데, 지금은 `$app/state`에서 가져온 객체(`page.url.pathname` 등)를 접두사 없이 바로 반응형 값처럼 쓰는 식으로 바뀌었다. `$app/stores` 쪽은 사실상 지원 종료(Deprecated) 수순을 밟고 있다.

<syntaxhighlight lang="bash">
npx sv create my-app
cd my-app
npm install
npm run dev
</syntaxhighlight>

== 생태계 및 위상 ==
[[리액트]]나 [[뷰]]에 비하면 라이브러리, 커뮤니티 규모, 채용 시장에서의 존재감은 여전히 작은 편이다. 다만 "번들 크기와 런타임 성능이 생태계 크기보다 중요한" 프로젝트 — 예를 들어 인터랙티브 대시보드, 임베디드 위젯, 경량 SaaS 내부 툴 등 — 에서는 꾸준히 대안으로 거론된다. UI 컴포넌트 라이브러리, 테스트 도구, 인증/배포 관련 생태계도 SvelteKit 2 시점에서 예전보다 많이 성숙해졌다는 평가가 나온다.

== 장단점 ==
=== 장점 ===
* 컴파일 타임 최적화 덕분에 런타임 오버헤드가 거의 없다.
* HTML에 가까운 직관적인 문법으로 진입장벽이 낮다.
* 결과물 번들이 가볍다.
* Runes 도입 이후 반응형 흐름이 명시적이라 디버깅·코드리뷰가 수월해졌다는 평가.
* Svelte 5 컴포넌트와 구 Svelte 4 컴포넌트가 공존 가능해 점진적 마이그레이션이 가능하다.

=== 단점 ===
* [[리액트]]·[[뷰]] 대비 여전히 작은 생태계와 구인 시장.
* Runes라는 새 개념을 다시 학습해야 해서, 기존 Svelte 사용자에게도 러닝커브가 새로 생긴다.
* 대규모 레거시 코드베이스에서는 Svelte 4→5 전환 자체가 별도 작업량으로 발생할 수 있다.

== 여담 ==
* Svelte의 마스코트는 [[고슴도치]]를 형상화한 캐릭터다.
* State of JS 설문 조사에서 만족도 최상위권 프레임워크로 여러 해 동안 꾸준히 언급되고 있다.
* "컴파일러가 프레임워크다"라는 캐치프레이즈로 자주 소개되며, 리액트의 가상 DOM 접근법과 자주 비교 대상이 된다.

== 관련 문서 ==
* [[자바스크립트]]
* [[리액트]]
* [[뷰]]
* [[Next.js]]
* [[Nuxt.js]]
* [[리치 해리스]]

== 참고 자료 ==
* Svelte 공식 웹사이트: [https://svelte.dev Svelte.dev]
* SvelteKit 공식 웹사이트: [https://kit.svelte.dev SvelteKit.dev]

<references/>

[[분류:웹 프레임워크]] [[분류:프론트엔드]] [[분류:자바스크립트]]

시그마 세븐e

2026-07-31T06:20:15Z

Gaon12: 정보상자 정보를 업데이트하고, 개요, 소속 성우 목록, 과거 소속 성우, 관련 사이트 및 분류를 추가 및 정리했습니다.

{{정보상자/회사
|구분 = 성우 매니지먼트
|이름 = 시그마 세븐e
|이름/일어 = シグマ・セブンe
|이름/영어 = SIGMA SEVEN E Co., Inc.
|약칭 = 시그마 세븐e, Σ7e
|약칭/일어 = シグマセブンe, Σ7e
|하는 일 = 성우, 나레이터 매니지먼트 등
|설립시기/년 = 2009
|설립시기/월 = 10
|설립시기/일 = 1
|폐쇄시기/년 =
|폐쇄시기/월 =
|폐쇄시기/일 =
|주소 = 도쿄도 미나토구 아카사카 7번가 10-17 폰테아카사카 빌딩 3층
|공식사이트 = https://sigma7e.com/
|블로그 =
|트위터 =
}}
'''시그마 세븐e'''{{원|シグマ・セブンe}}는 [[시그마 세븐]]의 자회사인 성우·나레이터 매니지먼트 회사이다.

== 개요 ==
2009년 10월 1일 시그마 세븐의 자회사로 설립되었다. 대표이사는 우라베 에츠타로(浦部悦太郎).<ref>{{언어|일}} [https://sigma7e.com/ 시그마 세븐e 공식 사이트 – 회사 개요]</ref> 소속 성우 대부분이 시그마 세븐 부속 양성소 출신이며, 제2회 이후의 시그마 세븐 공개 오디션 합격자들도 이 회사에 소속되는 구조를 취하고 있다.<ref>{{언어|일}} [https://ja.wikipedia.org/wiki/シグマ・セブンe 일본어 위키백과 "シグマ・セブンe" 항목]</ref> 관련 회사로 [[시그마 세븐]], 시그마 세븐 페이스(シグマ・セブンフェイス)가 있으며, 세 회사 모두 도쿄도 미나토구 아카사카 소재의 같은 사옥(폰테아카사카 빌딩)을 사용한다.

== 소속되어 있는 성우 ==
※ 아래 명단은 2026년 7월 기준 시그마 세븐 공식 사이트에 게재된 정보를 바탕으로 작성되었다.<ref>{{언어|일}} [https://sigma7.co.jp/ 시그마 세븐 공식 사이트 – Σ7e 소속 탤런트 목록]</ref>

=== 남자 성우 ===
{{분할 시작|2}}
* [[아에 야스토모]]
* [[아카이시 다카시]]
* [[아키야마 다이세이]]
* [[안도 리오]]
* [[이하라 쇼]]
* [[오카도 아오이]]
* [[오쿠자와 나오토]]
* [[오노 쿄스케]]
* [[카네마루 켄타]]
* [[카미조 타카요시]]
* [[키다 소요무]]
* [[쿠로이와 타쿠마]]
* [[쿠와지마 리쿠]]
* [[쿠와나 코헤이]]
* [[사카모토 카즈야]]
{{분할|2}}
* [[사쿠라이 쇼고]]
* [[사노 노부아키]]
* [[스가와라 신스케]]
* [[다케다 아츠시]]
* [[츠카모토 마사히로]]
* [[츠루 료]]
* [[나카무라 코세이]]
* [[니시지마 잇키]]
* [[하다 쿄타]]
* [[반 세이야]]
* [[후쿠시마 세이야]]
* [[후지모토 코노스케]]
* [[혼고 케이스케]]
* [[마키자키 타쿠미]]
* [[미야베 유마]]
* [[야마구치 유타]]
* [[와타나베 료]]
{{분할 끝}}

=== 여자 성우 ===
{{분할 시작|2}}
* [[아사히 세리카]]
* [[아리타 마미]]
* [[이노우에 히카리]]
* [[이마호리 아즈사]]
* [[에노모토 메이]]
* [[엔도 마유]]
* [[카도히라 유키]]
* [[카미무라 아사히]]
* [[카미야 아리사]]
* [[칸자키 유미카]]
* [[키타세 아야노]]
* [[키모토 케이코]]
* [[쿠니히로 스즈카]]
* [[코사카 유나]]
* [[코자키 유나]]
* [[코야마 나츠키]]
* [[시오카와 노도카]]
* [[시부야 히하루]]
* [[시미즈 사라]]
* [[시라카바 히토미]]
{{분할|2}}
* [[스즈미야 나츠키]]
* [[타치바나 마리카]]
* [[치카이시 준카]]
* [[치스가 하루카]]
* [[츠지 사키]]
* [[나카노 유나]]
* [[나카무라 유키코]]
* [[나미키 사쿠라]]
* [[니시오 유미]]
* [[닛타 하루카]]
* [[하세가와 미키]]
* [[핫토리 리나]]
* [[하야시 사키]]
* [[후쿠시마 란제]]
* [[후지 사야]]
* [[후지사키 노노카]]
* [[후지노 코코로]]
* [[후루타 아야코]]
* [[호리카와 사츠키]]
* [[혼다 리리코]]
* [[미야카와 시호]]
* [[미야구치 모모카]]
* [[모가키 마오]]
* [[야기타 유키에]]
* [[야마가미 유리에]]
* [[야마사키 코코로]]
* [[야마나카 치히로]]
{{분할 끝}}

== 과거에 소속되어 있던 성우 ==
=== 남자 성우 ===
* [[타마루 아츠시]] - 現 [[마우스 프로모션]] 소속
* [[치바 쇼야]] - 現 [[토이즈팩토리]] 소속

=== 여자 성우 ===
* [[이시하라 카오리]] - 現 [[스타일큐브]] 소속<ref>{{언어|일}} [https://ja.wikipedia.org/wiki/石原夏織 일본어 위키백과 "石原夏織" 항목]</ref>

== 주석 ==
<references />

== 관련 사이트 ==
* {{언어|일}} [https://sigma7e.com/ 시그마 세븐e 공식 사이트]
* {{언어|일}} [https://sigma7.co.jp/ 시그마 세븐 공식 사이트]

[[분류:2009년 설립된 일본 회사]]
[[분류:일본의 성우 사무소]]
[[분류:시그마 세븐]]

틀:정보상자/회사/설명문서

2026-07-31T06:19:44Z

Gaon12: 설명 최신화

== 사용법 ==
<pre>
{{정보상자/회사
|구분 =
|이름 =
|이름/일어 =
|이름/영어 =
|약칭 =
|약칭/일어 =
|하는 일 =
|설립시기/년 =
|설립시기/월 =
|설립시기/일 =
|폐쇄시기/년 =
|폐쇄시기/월 =
|폐쇄시기/일 =
|주소 =
|공식사이트 =
|블로그 =
|트위터 =
}}
</pre>

[[분류:정보상자 틀]]

시그마 세븐

2026-07-31T06:19:11Z

Gaon12: 영어명칭과 공식 사이트 URL을 수정하고, 소속 성우 목록과 관련 회사 정보를 추가 및 정리함

== 성우 매니지먼트 ==
{{정보상자/회사
|구분 = 성우 매니지먼트
|이름 = 시그마 세븐
|이름/일어 = シグマ・セブン
|이름/영어 = SIGMA SEVEN, Inc.
|약칭 = 시그마 세븐, Σ7
|약칭/일어 = シグマセブン, Σ7
|하는 일 = 성우, 나레이터 매니지먼트 등
|설립시기/년 = 1988
|설립시기/월 = 3
|설립시기/일 = 3
|폐쇄시기/년 =
|폐쇄시기/월 =
|폐쇄시기/일 =
|주소 = 도쿄도 미나토구 아카사카 7번가 10-17 폰테아카사카 빌딩 3층
|공식사이트 = https://sigma7.co.jp/
|블로그 =
|트위터 =
}}
'''시그마 세븐'''{{원|シグマ・セブン}}은 [[도쿄 배우 생활 협동조합]] 출신으로 나레이션 업무를 중심으로 활동하던 [[마키 다이스케]]·[[쿠보타 히토시]] 등이 중심이 되어 1988년 3월 3일에 설립한 성우·나레이터 매니지먼트 회사이다. 초대 사장은 이노우에 미노루(井上実). TV 프로그램 나레이션, CM 나레이션, VP 나레이션 등 나레이션 관련 업무를 폭넓게 담당하는 것이 특징이며, 일본예능매니지먼트사업자협회(日본芸能マネージメント事業者協会) 및 일본성우사업자협의회(日본声優事業社協議会) 회원사이다.<ref>{{언어|일}} [https://ja.wikipedia.org/wiki/シグマ・セブン 일본어 위키백과 "シグマ・セブン" 항목]</ref>

관련 회사인 디·오·에이(D.O.A)가 주관하는 성우 양성소 'The·성우숙(The・声優塾)' 출신 성우들(야스모토 히로키 등)이 다수 소속되어 있으며, 2010년 4월부터는 The·성우숙이 시그마 세븐 부속 양성소로 편입되었다. 이후 별도의 부속 양성소인 '시그마 세븐 성우 양성소(シグマ・セブン声優養成所)'가 운영 중이다.

2009년 10월 1일 자회사 [[시그마 세븐e]]가 설립되었으며, 남성 다재다능 인재(俳優/모델 겸업 등)를 다루는 '시그마 세븐 페이스(シグマ・セブンフェイス)' 역시 관련 회사로 운영되고 있다.

== 소속되어 있는 성우 ==
※ 아래 명단은 2026년 7월 기준 공식 사이트에 게재된 정보를 바탕으로 작성되었다.<ref>{{언어|일}} [https://sigma7.co.jp/ 시그마 세븐 공식 사이트 – 소속 탤런트 목록]</ref>

=== 남자 성우 ===
{{분할 시작|2}}
* [[이노우에 고우]]
* [[이노즈메 이쿠토]]
* [[우스이 다카야스]]
* [[우치다 다카히로]]
* [[오타 사토리]]
* [[오바타 켄지]]
* [[카쿠타 레오나]]
* [[쿠보타 히토시]]
* KOUSAKU
* [[코하라 마사카즈]]
* [[사이토 다카시]]
* [[사이토 모이치]]
* [[시이나 카즈마]]
* [[시오노 준지]]
* [[시라이시 마사키]]
{{분할|2}}
* [[스에히로 노리유키]]
* [[스즈키 타쿠로]]
* [[스야마 아키오]]
* [[타이라 켄]]
* [[타카기 타츠야]]
* [[타카다 벤]]
* [[타사카 히데키]]
* [[토카이치 슈에츠]]
* [[나구모 다이스케]]
* [[니시다 코지]]
* [[네기시 아키라]]
* [[하시모토 마사야]]
* [[하마 켄토]]
* HARRY
* [[하리야 케이주]]
{{분할|2}}
* [[히라노 요시카즈]]
* [[후쿠토쿠 하지메]]
* [[마키 다이스케]]
* [[마츠모토 야스노리]]
* [[마나카 료]]
* [[미즈시마 타츠오]]
* [[무라스기 아키히코]]
* [[메구로 코스케]]
* [[모리 신]]
* [[야스모토 히로키]]
* [[야마모토 쇼타]]
* [[와카스기 토루]]
* [[와카모토 노리오]]
* [[와카야마 아키히사]]
{{분할 끝}}

=== 여자 성우 ===
{{분할 시작|2}}
* [[아시자와 아키코]]
* [[아라이다 마사키]]
* [[안자이 유카리]]
* [[이시이 시오리]]
* [[이시카와 미유키]]
* [[이치노세 카나]]
* [[이마이 키미카]]
* [[우치카와 아이]]
* [[오가메 아스카]]
* [[오타케 후유미]]
* [[오구라 케이코]]
* [[오니츠카 아야코]]
* [[오마타 요시에]]
* [[카토 미유키]]
* [[키타하라 쿠니카]]
* [[쿠리타 히즈루]]
* [[쿠로카와 아키코]]
* [[코타니 나오코]]
* [[코바야시 사나에]]
* [[코마츠 아키코]]
* [[사카타 카요]]
* [[사토 아야카]]
* [[시미즈 아야나]]
* [[신조 세이카]]
* [[스기야마 나미에]]
* [[스기야마 유코]]
* [[소네 키요미]]
{{분할|2}}
* [[타카기 레이코]]
* [[타카시 마이코]]
* [[타카다 미호]]
* [[타카노 나오코]]
* [[타카모토 메구미]]
* [[타마가와 사키코]]
* [[츠노 시노]]
* [[츠노 마사이]]
* [[테라사와 모모카]]
* [[토기 미쿠루]]
* [[토리이 마야]]
* [[나가타니 요시코]]
* [[나카니시 유미코]]
* [[나키리 마리나]]
* [[니시 아스카]]
* [[니시노 마스미]]
* [[하타케야마 미와코]]
* [[히노 마리]]
* [[후쿠 에미코]]
* [[호소야 미유]]
* [[마키노 요시나]]
* [[마츠이 미도리]]
* [[마츠오 요시코]]
* [[마츠시타 마오]]
* MAYU
* [[마릴린 야마다]] (야마다 마리에)
{{분할|2}}
* [[미즈사와 후미에]]
* [[무나카타 나오]]
* [[모모모리 스모모]]
* [[야스다 미오]]
* [[유카나]]
* [[요코오 마리]]
* [[요시이 케이코]]
* [[요시다 유리]]
* [[와타나베 쿠미코]]
* [[와타나베 토모미]]
* [[와타베 사유미]]
{{분할 끝}}

== 과거에 소속되어 있던 성우 ==
※ 퇴사·이적 사유가 확인된 주요 인물만 정리하였다.

=== 남자 성우 ===
* [[나카무라 유이치]] - 現 [[인텐션]] 소속<ref>{{언어|일}} [https://intention-k.com/profile/yuichi_nakamura 인텐션 공식 사이트 – 나카무라 유이치 프로필]</ref>
* [[노지마 히로후미]] - 現 [[아오니 프로덕션]] 소속<ref>{{언어|일}} 노지마 히로후미 공식 X(트위터) 프로필</ref>
* [[야스무라 마코토]]
* [[요시노 히로유키]]

=== 여자 성우 ===
* [[미즈키 나나]] - 2021년 9월 30일 퇴사, 10월 1일부로 신설 사무소 [[StarCrew]]로 이적<ref>{{언어|일}} [https://ja.wikipedia.org/wiki/水樹奈々 일본어 위키백과 "水樹奈々" 항목]</ref>
* [[후쿠엔 미사토]] - 現 [[StarCrew]] 소속<ref>{{언어|일}} [https://ja.wikipedia.org/wiki/福圓美里 일본어 위키백과 "福圓美里" 항목]</ref>
* [[이시하라 카오리]] - 現 [[스타일큐브]] 소속<ref>{{언어|일}} [https://ja.wikipedia.org/wiki/石原夏織 일본어 위키백과 "石原夏織" 항목]</ref>
* [[이노우에 마리나]]
* [[오구라 유이 (아이돌 성우)|오구라 유이]] - 이후 클레어보이스 → 프리랜서 → 저스트 프로 → 아토믹 몽키 순으로 이적<ref>{{언어|일}} [https://dic.pixiv.net/a/シグマ・セブン 픽시브 백과사전 "シグマ・セブン" 항목]</ref>

== 관련 회사 ==
* [[시그마 세븐e]] - 2009년 10월 설립된 자회사. Σ7e 소속 성우를 관리한다.
* 시그마 세븐 페이스(シグマ・セブンフェイス) - 다재다능 인재(모델·배우 겸업) 매니지먼트 자회사.
* 시그마 세븐 성우 양성소(シグマ・セブン声優養成所) - 부속 성우 양성 기관.

== 주석 ==
<references />

== 관련 사이트 ==
* {{언어|일}} [https://sigma7.co.jp/ 시그마 세븐 공식 사이트]
* {{언어|일}} [https://sigma7e.com/ 시그마 세븐e 공식 사이트]

[[분류:1988년 설립된 일본 회사]]
[[분류:일본의 성우 사무소]]

틀:정보상자/회사

2026-07-31T06:18:39Z

Gaon12: {{#if:...}} 뒤에 구분자 |가 빠져 있어서, 그 아래 있는 |-(행 구분자)와 |(셀 구분자)가 #if 함수의 인자 구분 파이프로 먹혀버리는 문제 수정

<includeonly>{| class="wikitable" style="width:100%; float:right; clear:right; margin-left:10px; font-size:90%;"
|-
! colspan="2" style="background:#003366; color:#fff; font-size:110%;" | {{{이름}}}
{{#if:{{{로고|}}}|
{{!}}-
{{!}} colspan="2" style="text-align:center;" {{!}} [[파일:{{{로고}}}{{!}}200px]]
}}
|-
! colspan="2" style="background:#e6e6e6;" | 회사 정보
|-
! style="width:30%;" | 정식 명칭
| {{{이름}}}
{{#if:{{{이름/일어|}}}|
{{!}}-
! 일본어 표기
{{!}} {{{이름/일어}}}
}}
{{#if:{{{이름/영어|}}}|
{{!}}-
! 영어 표기
{{!}} {{{이름/영어}}}
}}
{{#if:{{{약칭|}}}|
{{!}}-
! 약칭
{{!}} {{{약칭}}}{{#if:{{{약칭/일어|}}}| ({{{약칭/일어}}})}}
}}
{{#if:{{{구분|}}}|
{{!}}-
! 구분
{{!}} {{{구분}}}
}}
{{#if:{{{하는 일|}}}|
{{!}}-
! 하는 일
{{!}} {{{하는 일}}}
}}
{{#if:{{{설립시기/년|}}}|
{{!}}-
! 설립
{{!}} {{{설립시기/년}}}년{{#if:{{{설립시기/월|}}}| {{{설립시기/월}}}월}}{{#if:{{{설립시기/일|}}}| {{{설립시기/일}}}일}}
}}
{{#if:{{{폐쇄시기/년|}}}|
{{!}}-
! 폐쇄
{{!}} {{{폐쇄시기/년}}}년{{#if:{{{폐쇄시기/월|}}}| {{{폐쇄시기/월}}}월}}{{#if:{{{폐쇄시기/일|}}}| {{{폐쇄시기/일}}}일}}
}}
{{#if:{{{주소|}}}|
{{!}}-
! 주소
{{!}} {{{주소}}}
}}
{{#if:{{{공식사이트|}}}|
{{!}}-
! 공식 사이트
{{!}} [{{{공식사이트}}} 바로가기]
}}
{{#if:{{{블로그|}}}|
{{!}}-
! 블로그
{{!}} [{{{블로그}}} 바로가기]
}}
{{#if:{{{트위터|}}}|
{{!}}-
! 트위터
{{!}} [{{{트위터}}} 바로가기]
}}
|}
[[분류:회사 정보상자를 사용하는 문서]]
</includeonly><noinclude>
{{정보상자/회사/설명문서}}
</noinclude>

틀:정보상자/회사

2026-07-31T06:12:35Z

Gaon12: 회사 정보상자 틀을 위키 표 형식으로 변경하고 구조를 개선했습니다.

<includeonly>{| class="wikitable" style="width:100%; float:right; clear:right; margin-left:10px; font-size:90%;"
|-
! colspan="2" style="background:#003366; color:#fff; font-size:110%;" | {{{이름}}}
{{#if:{{{로고|}}}|
|-
| colspan="2" style="text-align:center;" | [[파일:{{{로고}}}|200px]]
}}
|-
! colspan="2" style="background:#e6e6e6;" | 회사 정보
|-
! style="width:30%;" | 정식 명칭
| {{{이름}}}
{{#if:{{{이름/일어|}}}
|-
! 일본어 표기
| {{{이름/일어}}}
}}
{{#if:{{{이름/영어|}}}
|-
! 영어 표기
| {{{이름/영어}}}
}}
{{#if:{{{약칭|}}}
|-
! 약칭
| {{{약칭}}}{{#if:{{{약칭/일어|}}}| ({{{약칭/일어}}})}}
}}
{{#if:{{{구분|}}}
|-
! 구분
| {{{구분}}}
}}
{{#if:{{{하는 일|}}}
|-
! 하는 일
| {{{하는 일}}}
}}
{{#if:{{{설립시기/년|}}}
|-
! 설립
| {{{설립시기/년}}}년{{#if:{{{설립시기/월|}}}| {{{설립시기/월}}}월}}{{#if:{{{설립시기/일|}}}| {{{설립시기/일}}}일}}
}}
{{#if:{{{폐쇄시기/년|}}}
|-
! 폐쇄
| {{{폐쇄시기/년}}}년{{#if:{{{폐쇄시기/월|}}}| {{{폐쇄시기/월}}}월}}{{#if:{{{폐쇄시기/일|}}}| {{{폐쇄시기/일}}}일}}
}}
{{#if:{{{주소|}}}
|-
! 주소
| {{{주소}}}
}}
{{#if:{{{공식사이트|}}}
|-
! 공식 사이트
| [{{{공식사이트}}} 바로가기]
}}
{{#if:{{{블로그|}}}
|-
! 블로그
| [{{{블로그}}} 바로가기]
}}
{{#if:{{{트위터|}}}
|-
! 트위터
| [{{{트위터}}} 바로가기]
}}
|}
[[분류:회사 정보상자를 사용하는 문서]]
</includeonly><noinclude>
== 사용법 ==
<pre>
{{정보상자/회사
|구분 =
|이름 =
|이름/일어 =
|이름/영어 =
|약칭 =
|약칭/일어 =
|하는 일 =
|설립시기/년 =
|설립시기/월 =
|설립시기/일 =
|폐쇄시기/년 =
|폐쇄시기/월 =
|폐쇄시기/일 =
|주소 =
|공식사이트 =
|블로그 =
|트위터 =
}}
</pre>
[[분류:정보상자 틀]]
</noinclude>

등차중항

2026-07-31T05:48:39Z

Gaon12: 등차중항 문서의 내용을 확장하고 구조를 정리했습니다.

{{틀:수열의 중항}}

<div style="text-align:center;">
<big><big>'''<math>b=\frac{a+c}{2}</math>'''</big></big>
</div>

'''등차중항'''은 세 수가 차례로 [[등차수열]]을 이룰 때 가운데에 놓인 수를 말한다.

세 수 <math>a</math>, <math>b</math>, <math>c</math>가 이 순서대로 등차수열을 이루면 다음 관계가 성립한다.

:<math>\boxed{2b=a+c}</math>

따라서 가운데 수 <math>b</math>는 양쪽 두 수 <math>a</math>와 <math>c</math>의 평균과 같다.

:<math>\boxed{b=\frac{a+c}{2}}</math>

== 정의 ==
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 이 순서대로 등차수열을 이룬다고 하자.

이때 가운데에 있는 수 <math>b</math>를 <math>a</math>와 <math>c</math>의 '''등차중항'''이라고 한다.

등차수열에서는 이웃한 두 항의 차가 일정하므로 다음 식이 성립한다.

:<math>b-a=c-b</math>

이 식을 정리하면 등차중항의 기본 성질을 얻는다.

:<math>2b=a+c</math>

따라서

:<math>b=\frac{a+c}{2}</math>

이다.

즉, 등차중항은 양쪽 두 수의 [[산술평균]]이다.

== 기본 성질 ==
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등차수열을 이루면 다음 식들이 모두 성립한다.

:<math>b-a=c-b</math>

:<math>2b=a+c</math>

:<math>b=\frac{a+c}{2}</math>

이 세 식은 서로 같은 내용을 서로 다른 형태로 나타낸 것이다.

* <math>b-a=c-b</math>는 이웃한 두 항의 차가 같다는 뜻이다.
* <math>2b=a+c</math>는 가운데 수의 두 배가 양쪽 두 수의 합과 같다는 뜻이다.
* <math>b=\frac{a+c}{2}</math>는 가운데 수가 양쪽 두 수의 산술평균이라는 뜻이다.

== 증명 ==
=== 공차를 이용한 증명 ===
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등차수열을 이룬다고 하자.

이 등차수열의 [[공차]]를 <math>d</math>라고 하면

:<math>b=a+d</math>

이고,

:<math>c=a+2d</math>

이다.

이제 <math>a</math>와 <math>c</math>의 합을 계산하면

:<math>a+c=a+(a+2d)=2a+2d</math>

이다.

한편 <math>b=a+d</math>이므로

:<math>2b=2(a+d)=2a+2d</math>

이다.

따라서

:<math>2b=a+c</math>

가 성립한다.

양변을 <math>2</math>로 나누면

:<math>b=\frac{a+c}{2}</math>

를 얻는다.

=== 이웃한 항의 차를 이용한 증명 ===
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등차수열을 이루면 이웃한 두 항의 차가 같다.

따라서

:<math>b-a=c-b</math>

이다.

양변에 <math>a+b</math>를 더하면

:<math>2b=a+c</math>

가 된다.

양변을 <math>2</math>로 나누면

:<math>b=\frac{a+c}{2}</math>

이다.

따라서 등차중항은 양쪽 두 수의 산술평균과 같다.

== 역도 성립함 ==
세 수 <math>a</math>, <math>b</math>, <math>c</math>에 대하여

:<math>b=\frac{a+c}{2}</math>

가 성립한다고 하자.

양변에 <math>2</math>를 곱하면

:<math>2b=a+c</math>

이다.

이 식을 정리하면

:<math>b-a=c-b</math>

를 얻는다.

따라서 <math>a</math>에서 <math>b</math>로 증가한 양과 <math>b</math>에서 <math>c</math>로 증가한 양이 같다. 그러므로 세 수 <math>a</math>, <math>b</math>, <math>c</math>는 차례로 등차수열을 이룬다.

따라서 다음 두 명제는 서로 동치이다.

* <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등차수열을 이룬다.
* <math>b=\frac{a+c}{2}</math>가 성립한다.

== 등차중항을 구하는 방법 ==
두 수 <math>a</math>와 <math>c</math> 사이에 등차중항 <math>b</math>를 넣으려면 다음 공식을 사용한다.

:<math>b=\frac{a+c}{2}</math>

계산 과정은 다음과 같다.

# 양쪽 두 수 <math>a</math>와 <math>c</math>를 더한다.
# 그 합을 <math>2</math>로 나눈다.
# 계산한 값이 등차중항 <math>b</math>이다.
# 필요하다면 두 차 <math>b-a</math>와 <math>c-b</math>가 같은지 확인한다.

== 예제 ==
=== 예제 1 ===
<math>3</math>과 <math>11</math> 사이에 등차중항 <math>b</math>를 넣는다고 하자.

등차중항의 공식에 따라

:<math>b=\frac{3+11}{2}</math>

이다.

따라서

:<math>b=\frac{14}{2}=7</math>

이다.

실제로

:<math>7-3=4</math>

이고,

:<math>11-7=4</math>

이므로 <math>3</math>, <math>7</math>, <math>11</math>은 공차가 <math>4</math>인 등차수열이다.

=== 예제 2 ===
세 수 <math>-5</math>, <math>x</math>, <math>9</math>가 차례로 등차수열을 이룬다고 하자.

등차중항의 성질을 이용하면

:<math>x=\frac{-5+9}{2}</math>

이다.

따라서

:<math>x=\frac{4}{2}=2</math>

이다.

실제로

:<math>2-(-5)=7</math>

이고,

:<math>9-2=7</math>

이므로 세 수의 공차는 <math>7</math>이다.

=== 예제 3 ===
세 수 <math>2x-1</math>, <math>7</math>, <math>3x+2</math>가 차례로 등차수열을 이룬다고 하자.

가운데 수의 두 배는 양쪽 두 수의 합과 같으므로

:<math>2\cdot7=(2x-1)+(3x+2)</math>

이다.

식을 정리하면

:<math>14=5x+1</math>

이므로

:<math>5x=13</math>

이고,

:<math>x=\frac{13}{5}</math>

이다.

=== 예제 4 ===
<math>4</math>, <math>10</math>, <math>16</math>이 등차수열인지 확인해 보자.

가운데 수 <math>10</math>과 양쪽 두 수의 평균을 비교하면

:<math>\frac{4+16}{2}=\frac{20}{2}=10</math>

이다.

가운데 수가 양쪽 두 수의 평균과 같으므로 <math>4</math>, <math>10</math>, <math>16</math>은 차례로 등차수열을 이룬다.

== 수직선에서의 의미 ==
수직선 위에서 <math>a</math>와 <math>c</math>를 나타내는 두 점을 생각해 보자.

등차중항

:<math>b=\frac{a+c}{2}</math>

는 두 점 <math>a</math>와 <math>c</math>의 정확한 가운데에 놓인다.

따라서 <math>a\le c</math>인 경우 다음 두 거리가 같다.

:<math>b-a=c-b</math>

즉, 등차중항은 수직선에서 양쪽 두 수의 중점에 해당한다.

== 여러 개의 등차중항 ==
두 수 <math>a</math>와 <math>c</math> 사이에 등차중항을 하나가 아니라 여러 개 넣을 수도 있다.

예를 들어 <math>a</math>와 <math>c</math> 사이에 세 수를 넣어 전체가 다섯 항인 등차수열을 만든다고 하자.

:<math>a,\ x_1,\ x_2,\ x_3,\ c</math>

전체 항의 수가 <math>5</math>이므로 공차 <math>d</math>는

:<math>d=\frac{c-a}{4}</math>

이다.

따라서 세 등차중항은 다음과 같다.

:<math>x_1=a+d</math>

:<math>x_2=a+2d</math>

:<math>x_3=a+3d</math>

일반적으로 <math>a</math>와 <math>c</math> 사이에 <math>n</math>개의 등차중항을 넣으면 전체 항의 수는 <math>n+2</math>이고, 공차는 다음과 같다.

:<math>d=\frac{c-a}{n+1}</math>

이때 <math>k</math>번째 등차중항은

:<math>x_k=a+kd \qquad (1\le k\le n)</math>

이므로

:<math>x_k=a+\frac{k(c-a)}{n+1}</math>

로 나타낼 수 있다.

== 등비중항과의 비교 ==
등차중항과 [[등비중항]]은 모두 세 수로 이루어진 수열의 가운데 항이지만, 사용하는 연산이 다르다.

{| class="wikitable"
! 구분 !! 등차중항 !! 등비중항
|-
| 수열의 종류 || [[등차수열]] || [[등비수열]]
|-
| 기본 관계 || <math>b-a=c-b</math> || <math>\frac{b}{a}=\frac{c}{b}</math>
|-
| 중항의 성질 || <math>2b=a+c</math> || <math>b^2=ac</math>
|-
| 중항을 구하는 공식 || <math>b=\frac{a+c}{2}</math> || <math>b=\pm\sqrt{ac}</math>
|-
| 양수인 경우 || <math>b=\frac{a+c}{2}</math> || <math>b=\sqrt{ac}</math>
|-
| 관련된 평균 || [[산술평균]] || [[기하평균]]
|-
| 주로 사용하는 연산 || 덧셈과 나눗셈 || 곱셈과 제곱근
|}

등차중항은 양쪽 두 수의 '''합'''을 이용하여 구하고, 등비중항은 양쪽 두 수의 '''곱'''을 이용하여 구한다.

== 주의할 점 ==

* 등차중항은 양쪽 두 수를 더한 뒤 반드시 <math>2</math>로 나누어야 한다.
* <math>\frac{a+c}{2}</math>는 <math>a+\frac{c}{2}</math>와 다르다.
* 음수가 포함되어 있어도 같은 공식을 사용할 수 있다.
* <math>a</math>와 <math>c</math>가 같으면 등차중항도 같은 값이다. 예를 들어 <math>5</math>, <math>5</math>, <math>5</math>는 공차가 <math>0</math>인 등차수열이다.
* 세 수가 등차수열인지 확인할 때에는 <math>b-a=c-b</math> 또는 <math>2b=a+c</math>를 사용할 수 있다.
* 등차중항은 두 실수 <math>a</math>, <math>c</math>에 대하여 항상 하나만 존재한다.

== 같이 보기 ==

* [[등차수열]]
* [[공차]]
* [[산술평균]]
* [[등비중항]]
* [[등비수열]]
* [[기하평균]]
* [[수열]]

[[분류:수열]]
[[분류:등차수열]]
[[분류:평균]]

등비중항

2026-07-31T05:45:27Z

Gaon12: 수식과 공백을 정리하고 불필요한 공백을 제거했습니다.

{{틀:수열의 중항}}

<div style="text-align:center;">
<big><big>'''<math>b^2=ac</math>'''</big></big>
</div>

'''등비중항'''은 세 수가 차례로 [[등비수열]]을 이룰 때 가운데에 놓인 수를 말한다. 세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등비수열을 이루면 다음 관계가 성립한다.

:<math>\boxed{b^2=ac}</math>

즉, 가운데 수 <math>b</math>의 제곱은 양쪽 두 수 <math>a</math>와 <math>c</math>의 곱과 같다.

== 정의 ==
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 이 순서대로 등비수열을 이룬다고 하자.

이때 가운데에 있는 수 <math>b</math>를 <math>a</math>와 <math>c</math>의 '''등비중항'''이라고 한다.

세 수가 등비수열을 이루므로 일정한 수 <math>r</math>에 대하여 다음과 같이 나타낼 수 있다.

:<math>b=ar</math>
:<math>c=ar^2</math>

여기서 <math>r</math>은 이 등비수열의 [[공비]]이다.

== 기본 성질 ==
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등비수열을 이루면 다음 식이 성립한다.

:<math>b^2=ac</math>

따라서 양쪽의 두 수 <math>a</math>, <math>c</math>를 알고 있다면 등비중항 <math>b</math>는 다음 식을 만족한다.

:<math>b=\pm\sqrt{ac}</math>

다만 <math>a</math>, <math>b</math>, <math>c</math>를 양수로 제한하는 경우에는 양의 값만 사용하므로 다음과 같다.

:<math>b=\sqrt{ac}</math>

이때 <math>\sqrt{ac}</math>를 두 양수 <math>a</math>와 <math>c</math>의 [[기하평균]]이라고 한다.

== 증명 ==
=== 공비를 이용한 증명 ===
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등비수열을 이룬다고 하자.

공비를 <math>r</math>이라고 하면

:<math>b=ar</math>

이고,

:<math>c=br=ar^2</math>

이다.

이제 <math>b</math>를 제곱하면

:<math>b^2=(ar)^2=a^2r^2</math>

이다.

한편 <math>a</math>와 <math>c</math>를 곱하면

:<math>ac=a\cdot ar^2=a^2r^2</math>

이다.

따라서

:<math>b^2=ac</math>

가 성립한다.

=== 비의 성질을 이용한 증명 ===
<math>a</math>, <math>b</math>, <math>c</math>가 차례로 등비수열이고 각 분모가 <math>0</math>이 아니라고 하자.

등비수열에서는 이웃한 두 항의 비가 일정하므로

:<math>\frac{b}{a}=\frac{c}{b}</math>

이다.

양변에 <math>ab</math>를 곱하면

:<math>ab\cdot\frac{b}{a}=ab\cdot\frac{c}{b}</math>

이고, 이를 정리하면

:<math>b^2=ac</math>

를 얻는다.

이 증명은 나눗셈을 사용하므로 <math>a\ne0</math>, <math>b\ne0</math>인 경우에 사용할 수 있다. <math>0</math>이 포함된 경우까지 다루려면 공비를 이용한 증명이 더 적절하다.

== 예제 ==
=== 예제 1 ===
세 수 <math>2</math>, <math>6</math>, <math>18</math>은 차례로 등비수열을 이룬다.

공비는

:<math>\frac{6}{2}=\frac{18}{6}=3</math>

이다.

가운데 수의 제곱과 양쪽 두 수의 곱을 각각 계산하면

:<math>6^2=36</math>

이고,

:<math>2\cdot18=36</math>

이다.

따라서

:<math>6^2=2\cdot18</math>

이 성립한다.

=== 예제 2 ===
<math>3</math>과 <math>12</math> 사이에 양의 등비중항 <math>x</math>를 넣는다고 하자.

그러면

:<math>3,\ x,\ 12</math>

가 차례로 등비수열을 이루므로

:<math>x^2=3\cdot12</math>

이다.

따라서

:<math>x^2=36</math>

이고, 양의 등비중항을 구하는 것이므로

:<math>x=6</math>

이다.

실제로

:<math>\frac{6}{3}=\frac{12}{6}=2</math>

이므로 <math>3</math>, <math>6</math>, <math>12</math>는 공비가 <math>2</math>인 등비수열이다.

=== 예제 3 ===
세 수 <math>4</math>, <math>x</math>, <math>25</math>가 차례로 등비수열을 이룬다고 하자.

등비중항의 성질에 따라

:<math>x^2=4\cdot25=100</math>

이다.

따라서

:<math>x=\pm10</math>

이다.

실제로 다음 두 수열은 모두 등비수열이다.

:<math>4,\ 10,\ 25</math>

이 수열의 공비는 <math>\frac{5}{2}</math>이다.

:<math>4,\ -10,\ 25</math>

이 수열의 공비는 <math>-\frac{5}{2}</math>이다.

따라서 실수 전체에서 생각하면 등비중항은 두 개가 될 수 있다. 그러나 양의 등비중항만을 구하는 문제에서는 <math>10</math>만 답으로 사용한다.

== 등비중항을 구하는 방법 ==
두 수 <math>a</math>, <math>c</math> 사이에 등비중항 <math>b</math>를 넣으려면 다음 순서로 계산한다.

# 등비중항의 성질 <math>b^2=ac</math>를 세운다.
# 양쪽 두 수를 곱하여 <math>b^2</math>의 값을 구한다.
# 제곱근을 구하여 <math>b</math>의 값을 결정한다.
# 문제에서 양수만 요구하는지 확인한다.

예를 들어 <math>8</math>과 <math>18</math>의 양의 등비중항을 구하면

:<math>b^2=8\cdot18=144</math>

이므로

:<math>b=\sqrt{144}=12</math>

이다.

== 등차중항과의 비교 ==
등비중항은 [[등차중항]]과 형태가 다르다.

등차수열 <math>a</math>, <math>b</math>, <math>c</math>에서는 가운데 수의 두 배가 양쪽 두 수의 합과 같다.

:<math>2b=a+c</math>

따라서 등차중항은

:<math>b=\frac{a+c}{2}</math>

이다.

반면 등비수열 <math>a</math>, <math>b</math>, <math>c</math>에서는 가운데 수의 제곱이 양쪽 두 수의 곱과 같다.

:<math>b^2=ac</math>

양수인 경우의 등비중항은

:<math>b=\sqrt{ac}</math>

이다.

즉, 등차중항은 양쪽 두 수의 '''합'''과 관련되고, 등비중항은 양쪽 두 수의 '''곱'''과 관련된다.

== 주의할 점 ==

* <math>\frac{b}{a}=\frac{c}{b}</math>에서 공비는 <math>a</math>가 아니라 <math>r</math>이다.
* 비를 이용한 증명에서는 분모가 되는 <math>a</math>와 <math>b</math>가 <math>0</math>이 아니어야 한다.
* <math>b^2=ac</math>에서 제곱근을 구하면 일반적으로 <math>b=\pm\sqrt{ac}</math>이다.
* 모든 수가 양수라고 주어진 경우에는 <math>b=\sqrt{ac}</math>만 사용한다.
* 실수 범위에서 등비중항이 존재하려면 <math>ac\ge0</math>이어야 한다.
* <math>b^2=ac</math>가 성립하더라도 <math>0</math>이 포함된 특별한 경우에는 세 수가 실제로 등비수열을 이루는지 별도로 확인해야 한다.

== 같이 보기 ==

* [[등비수열]]
* [[공비]]
* [[기하평균]]
* [[등차중항]]
* [[산술평균]]
* [[수열]]

[[분류:수열]]
[[분류:등비수열]]
[[분류:평균]]

등비중항

2026-07-31T05:43:47Z

Gaon12: 문서 구조를 개편하고 내용을 추가, 정리함. 잘못된 계산값 수정

{{틀:수열의 중항}}

<div style="text-align:center;">
<big><big>'''<math>b^2=ac</math>'''</big></big>
</div>

'''등비중항'''은 세 수가 차례로 [[등비수열]]을 이룰 때 가운데에 놓인 수를 말한다. 세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등비수열을 이루면 다음 관계가 성립한다.

:<math>\boxed{b^2=ac}</math>

즉, 가운데 수 <math>b</math>의 제곱은 양쪽 두 수 <math>a</math>와 <math>c</math>의 곱과 같다.

== 정의 ==
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 이 순서대로 등비수열을 이룬다고 하자.

이때 가운데에 있는 수 <math>b</math>를 <math>a</math>와 <math>c</math>의 '''등비중항'''이라고 한다.

세 수가 등비수열을 이루므로 일정한 수 <math>r</math>에 대하여 다음과 같이 나타낼 수 있다.

:<math>b=ar</math>
:<math>c=ar^2</math>

여기서 <math>r</math>은 이 등비수열의 [[공비]]이다.

== 기본 성질 ==
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등비수열을 이루면 다음 식이 성립한다.

:<math>b^2=ac</math>

따라서 양쪽의 두 수 <math>a</math>, <math>c</math>를 알고 있다면 등비중항 <math>b</math>는 다음 식을 만족한다.

:<math>b=\pm\sqrt{ac}</math>

다만 <math>a</math>, <math>b</math>, <math>c</math>를 양수로 제한하는 경우에는 양의 값만 사용하므로 다음과 같다.

:<math>b=\sqrt{ac}</math>

이때 <math>\sqrt{ac}</math>를 두 양수 <math>a</math>와 <math>c</math>의 [[기하평균]]이라고 한다.

== 증명 ==
=== 공비를 이용한 증명 ===
세 수 <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등비수열을 이룬다고 하자.

공비를 <math>r</math>이라고 하면

:<math>b=ar</math>

이고,

:<math>c=br=ar^2</math>

이다.

이제 <math>b</math>를 제곱하면

:<math>b^2=(ar)^2=a^2r^2</math>

이다.

한편 <math>a</math>와 <math>c</math>를 곱하면

:<math>ac=a\cdot ar^2=a^2r^2</math>

이다.

따라서

:<math>b^2=ac</math>

가 성립한다.

=== 비의 성질을 이용한 증명 === <math>a</math>, <math>b</math>, <math>c</math>가 차례로 등비수열이고 각 분모가 <math>0</math>이 아니라고 하자.

등비수열에서는 이웃한 두 항의 비가 일정하므로

:<math>\frac{b}{a}=\frac{c}{b}</math>

이다.

양변에 <math>ab</math>를 곱하면

:<math>ab\cdot\frac{b}{a}=ab\cdot\frac{c}{b}</math>

이고, 이를 정리하면

:<math>b^2=ac</math>

를 얻는다.

이 증명은 나눗셈을 사용하므로 <math>a\ne0</math>, <math>b\ne0</math>인 경우에 사용할 수 있다. <math>0</math>이 포함된 경우까지 다루려면 공비를 이용한 증명이 더 적절하다.

== 예제 ==
=== 예제 1 ===
세 수 <math>2</math>, <math>6</math>, <math>18</math>은 차례로 등비수열을 이룬다.

공비는

:<math>\frac{6}{2}=\frac{18}{6}=3</math>

이다.

가운데 수의 제곱과 양쪽 두 수의 곱을 각각 계산하면

:<math>6^2=36</math>

이고,

:<math>2\cdot18=36</math>

이다.

따라서

:<math>6^2=2\cdot18</math>

이 성립한다.

=== 예제 2 === <math>3</math>과 <math>12</math> 사이에 양의 등비중항 <math>x</math>를 넣는다고 하자.

그러면

:<math>3,\ x,\ 12</math>

가 차례로 등비수열을 이루므로

:<math>x^2=3\cdot12</math>

이다.

따라서

:<math>x^2=36</math>

이고, 양의 등비중항을 구하는 것이므로

:<math>x=6</math>

이다.

실제로

:<math>\frac{6}{3}=\frac{12}{6}=2</math>

이므로 <math>3</math>, <math>6</math>, <math>12</math>는 공비가 <math>2</math>인 등비수열이다.

=== 예제 3 ===
세 수 <math>4</math>, <math>x</math>, <math>25</math>가 차례로 등비수열을 이룬다고 하자.

등비중항의 성질에 따라

:<math>x^2=4\cdot25=100</math>

이다.

따라서

:<math>x=\pm10</math>

이다.

실제로 다음 두 수열은 모두 등비수열이다.

:<math>4,\ 10,\ 25</math>

이 수열의 공비는 <math>\frac{5}{2}</math>이다.

:<math>4,\ -10,\ 25</math>

이 수열의 공비는 <math>-\frac{5}{2}</math>이다.

따라서 실수 전체에서 생각하면 등비중항은 두 개가 될 수 있다. 그러나 양의 등비중항만을 구하는 문제에서는 <math>10</math>만 답으로 사용한다.

== 등비중항을 구하는 방법 ==
두 수 <math>a</math>, <math>c</math> 사이에 등비중항 <math>b</math>를 넣으려면 다음 순서로 계산한다.

# 등비중항의 성질 <math>b^2=ac</math>를 세운다.

# 양쪽 두 수를 곱하여 <math>b^2</math>의 값을 구한다.

# 제곱근을 구하여 <math>b</math>의 값을 결정한다.

# 문제에서 양수만 요구하는지 확인한다.

예를 들어 <math>8</math>과 <math>18</math>의 양의 등비중항을 구하면

:<math>b^2=8\cdot18=144</math>

이므로

:<math>b=\sqrt{144}=12</math>

이다.

== 등차중항과의 비교 ==
등비중항은 [[등차중항]]과 형태가 다르다.

등차수열 <math>a</math>, <math>b</math>, <math>c</math>에서는 가운데 수의 두 배가 양쪽 두 수의 합과 같다.

:<math>2b=a+c</math>

따라서 등차중항은

:<math>b=\frac{a+c}{2}</math>

이다.

반면 등비수열 <math>a</math>, <math>b</math>, <math>c</math>에서는 가운데 수의 제곱이 양쪽 두 수의 곱과 같다.

:<math>b^2=ac</math>

양수인 경우의 등비중항은

:<math>b=\sqrt{ac}</math>

이다.

즉, 등차중항은 양쪽 두 수의 '''합'''과 관련되고, 등비중항은 양쪽 두 수의 '''곱'''과 관련된다.

== 주의할 점 ==

* <math>\frac{b}{a}=\frac{c}{b}</math>에서 공비는 <math>a</math>가 아니라 <math>r</math>이다.
* 비를 이용한 증명에서는 분모가 되는 <math>a</math>와 <math>b</math>가 <math>0</math>이 아니어야 한다.
* <math>b^2=ac</math>에서 제곱근을 구하면 일반적으로 <math>b=\pm\sqrt{ac}</math>이다.
* 모든 수가 양수라고 주어진 경우에는 <math>b=\sqrt{ac}</math>만 사용한다.
* 실수 범위에서 등비중항이 존재하려면 <math>ac\ge0</math>이어야 한다.
* <math>b^2=ac</math>가 성립하더라도 <math>0</math>이 포함된 특별한 경우에는 세 수가 실제로 등비수열을 이루는지 별도로 확인해야 한다.

== 같이 보기 ==

* [[등비수열]]
* [[공비]]
* [[기하평균]]
* [[등차중항]]
* [[산술평균]]
* [[수열]]

[[분류:수열]]
[[분류:등비수열]]
[[분류:평균]]

하야마 하야토

2026-07-10T01:29:24Z

Gaon12: 인물상, 개요, 애니메이션 및 게임 정보, 관련 전개, 주석을 추가하고 프로필 정보를 정리함

== 캐릭터 ==
{{캐릭터 정보
|성별 = 남
|이름 = 하야마 하야토
|이름/일어 = 葉山隼人
|이름/요미카타 = はやまはやと
|이름/영어 = Hayama Hayato
|이명 =
|이명/일어 =
|이명/영어 =
|속성 = 고등학생, 축구부, 인기인, 리더, 조정자
|등장작품 = 역시 내 청춘 러브코메디는 잘못됐다.
|CV = [[콘도 타카시]]
|종족 = 인간
|국적 =
|연령 =
|신분 = 소부고교 2학년 F반, 축구부
|생일/년 =
|생일/월 = 9
|생일/일 = 28
|혈액형 = B
|신장 =
|체중 =
|가슴 =
|허리 =
|엉덩이 =
|컵 =
|별명 = 하야토, 하야토 군
|능력 = 대인관계 조율, 집단 통솔, 운동 능력
|특기 = 축구, 기타
|취미 = 독서, 영화감상, 풋살, 기타, 해양 스포츠
|거주지 =
|가족관계 =
|이미지 컬러 =
|캐릭터송 =
|공식 인기투표 =
|국내명 = 하야마 하야토
|등장작품/국내 = 역시 내 청춘 러브코메디는 잘못됐다.
|CV/국내 =
}}

'''하야마 하야토'''(葉山隼人)는 [[와타리 와타루]]의 [[라이트 노벨]] 《[[역시 내 청춘 러브코메디는 잘못됐다.]]》에 등장하는 인물이다. [[히키가야 하치만]]과 같은 소부고교 2학년 F반의 학생이며, 축구부에 소속된 인기인이다.<ref name="tbs-kan">[https://www.tbs.co.jp/anime/oregairu/character/chara08.html TV 애니메이션 《역시 내 청춘 러브코메디는 잘못됐다. 완》 공식 홈페이지: 하야마 하야토.]</ref> TV 애니메이션판의 성우는 [[콘도 타카시]]이다.<ref name="tbs-cast">[https://www.tbs.co.jp/anime/oregairu/staffcast/ TV 애니메이션 《역시 내 청춘 러브코메디는 잘못됐다. 완》 공식 홈페이지: 스태프 & 캐스트.]</ref>

작중에서는 뛰어난 외모, 성적, 운동 실력, 원만한 성격을 두루 갖춘 학생으로 묘사된다. 반에서는 [[미우라 유미코]], [[토베 카케루]], [[에비나 히나]], 오오카, 야마토 등과 함께 이른바 상위권 그룹을 형성하고 있으며, 그 안에서도 중심 인물에 가깝다. 하야마는 누구에게나 밝고 친절하게 대하지만, 동시에 자신에게 기대되는 “좋은 사람”의 역할을 쉽게 내려놓지 못하는 인물이기도 하다.

공식 프로필상 별명은 “하야토”, “하야토 군”이며, 생일은 9월 28일, 혈액형은 B형이다. 특기는 축구와 기타, 취미는 독서, 영화감상, 풋살, 기타, 해양 스포츠이다. 좌우명은 [[스티브 잡스]]의 말인 ''Your time is limited, so don't waste it living someone else's life.''이다.<ref name="tbs-1st">[https://www.tbs.co.jp/anime/oregairu/1st/chara/ TBS TV 애니메이션 《역시 내 청춘 러브코메디는 잘못됐다.》 1기 공식 홈페이지: 캐릭터 정보.]</ref>

== 개요 ==
하야마는 작품 안에서 [[히키가야 하치만]]의 대척점에 가까운 인물로 배치된다. 하치만이 인간관계의 모순을 냉소적으로 파악하고, 때로는 자기 자신을 희생하거나 악역으로 만드는 방식으로 문제를 해결하려 한다면, 하야마는 가능한 한 현재의 분위기와 관계를 유지하려 한다. 이 때문에 두 사람은 같은 문제를 보더라도 서로 다른 결론에 도달하는 경우가 많다.

그는 반 안팎에서 인망이 높고, 주변 사람들의 기대를 자연스럽게 받아들이는 위치에 있다. 겉으로는 이상적인 리더처럼 보이지만, 실제로는 자신을 향한 기대와 타인의 시선에 강하게 얽매여 있다. 하야마가 문제를 분명하게 해결하기보다 균형을 유지하는 쪽을 택하는 이유도 여기에 있다. 그는 누군가를 노골적으로 배제하거나 상처 입히는 것을 꺼리지만, 반대로 누구 한 사람을 선택하거나 확실한 결론을 내리는 일도 피하려 한다.

이러한 성향 때문에 하야마는 단순한 “완벽한 인기인”이 아니라, 작품의 주요 주제인 “진짜 관계”와 “겉으로 유지되는 관계”의 긴장을 보여 주는 인물로 기능한다. 그는 주변 사람들의 기대에 부응하는 데 능숙하지만, 그 기대가 자신을 옥죄고 있다는 사실도 인식하고 있다.

== 인물상 ==
=== 겉으로 드러나는 모습 ===
하야마는 친절하고 사교적인 성격의 소유자이다. 반 친구들과 무리 없이 어울리며, 갈등이 생기면 분위기를 부드럽게 만들거나 중재하려 한다. 축구부 소속답게 운동 능력도 뛰어나고, 성적도 우수한 편으로 묘사된다. 이러한 요소들은 그를 반 안에서 눈에 띄는 존재로 만들며, 주변 인물들이 그에게 자연스럽게 의지하게 만드는 원인이 된다.

하치만은 하야마가 주변 분위기와 인간관계를 자연스럽게 정돈하는 모습을 두고, 리얼충 특유의 기술인 “The Zone”처럼 표현한다.<ref>원작 제2권.</ref> 이는 하야마가 단순히 인기가 많은 인물이라는 뜻을 넘어, 집단 안에서 사람들의 발언과 감정, 위치를 조율하는 능력을 갖추고 있음을 보여 준다.

=== 내면과 약점 ===
하야마의 가장 큰 특징은 “기대에 부응하려는 태도”이다. 그는 주변에서 요구하는 이상적인 친구, 이상적인 리더, 이상적인 남학생의 모습을 계속 수행한다. 그러나 이 태도는 동시에 그의 약점이 된다. 그는 모두가 납득할 수 있는 답을 찾으려 하지만, 그런 답이 존재하지 않는 상황에서는 오히려 결정을 미루거나 모호한 태도를 보인다.

특히 누군가의 감정이 직접적으로 얽힌 문제에서 하야마는 명확한 선택을 피하려 한다. 이 때문에 미우라, 토베, 에비나 등으로 이루어진 그룹의 균형은 겉으로는 유지되지만, 내부의 감정과 불안은 해소되지 않은 채 남는다. 하야마는 그 불안을 알고 있으면서도, 관계가 깨지는 순간을 두려워하기 때문에 쉽게 움직이지 못한다.

=== 하치만과의 대비 ===
하야마와 하치만은 모두 인간관계를 관찰하는 능력이 뛰어나지만, 문제 해결 방식은 정반대에 가깝다. 하야마는 관계를 유지하기 위해 상처를 최소화하려 하고, 하치만은 관계의 모순을 드러내거나 자신이 악역이 되는 방식으로 문제를 끝내려 한다. 하야마는 하치만의 판단력과 행동력을 어느 정도 인정하지만, 하치만이 스스로를 깎아내리는 방식에는 강한 거부감을 보인다.

이 대비는 작품 전체에서 중요한 의미를 지닌다. 하치만의 방식은 빠르고 확실하지만 주변 사람에게 상처를 남기며, 하야마의 방식은 온건하고 안정적으로 보이지만 문제의 본질을 덮어 두기 쉽다. 두 사람은 서로의 결점을 알고 있으며, 그렇기 때문에 단순한 우정이나 적대 관계로 정리하기 어렵다.

== 작중 행적 ==
=== 초반부 ===
초반의 하야마는 반에서 가장 눈에 띄는 인기인으로 등장한다. 그는 하치만과 같은 반이지만, 인간관계의 위치는 정반대에 있다. 하치만이 교실에서 고립된 인물이라면, 하야마는 친구들과 자연스럽게 어울리며 반 분위기를 이끄는 인물이다.

처음에는 하치만의 성을 “히키타니”라고 잘못 부르는 듯한 모습을 보이기도 한다. 이 호칭은 초반에는 개그 요소처럼 사용되지만, 이후 두 사람의 거리감과 인식 변화를 보여 주는 장치로도 기능한다. 이야기가 진행될수록 하야마는 하치만을 더 정확히 의식하고, “히키가야”라고 부르는 장면이 늘어난다.

=== 치바촌 합숙 ===
치바촌 합숙 에피소드에서 하야마는 [[츠루미 루미]]의 문제와 마주한다. 루미는 또래 아이들 사이에서 고립되어 있으며, 하야마는 이를 대화와 배려를 통해 해결하려 한다. 그러나 하치만은 집단의 구조 자체를 이용하는 극단적인 방식으로 문제를 처리한다.<ref>원작 제4권.</ref>

이 사건은 하야마와 하치만의 차이를 선명하게 보여 준다. 하야마는 하치만의 방식이 효과적이었다는 사실을 부정하기 어렵지만, 그것을 올바른 해결이라고 받아들이지 못한다. 그는 하치만이 자신을 희생하거나 악역으로 만드는 방식에 불쾌감을 느끼며, 이후에도 비슷한 태도를 반복적으로 보인다.

=== 수학여행과 토베의 고백 문제 ===
수학여행 에피소드에서는 [[토베 카케루]]가 [[에비나 히나]]에게 고백하려는 문제가 중심이 된다. 토베의 고백은 단순한 연애 문제가 아니라, 하야마 그룹 전체의 균형을 흔들 수 있는 사건이다. 토베가 고백하고 거절당할 경우, 지금까지 유지되던 친구 관계가 어색해질 수 있기 때문이다.

하야마는 이 위험을 알고 있으면서도, 직접적으로 토베를 막거나 에비나의 마음을 드러내려 하지 않는다. 결국 하치만은 자신이 에비나에게 고백하는 형식을 취해 상황을 무산시키고, 토베의 고백이 실제로 이루어지는 일을 막는다.<ref>원작 제7권.</ref> 하야마는 하치만이 그룹의 균형을 지킨 사실을 이해하지만, 동시에 하치만이 스스로를 희생한 방식에 분노와 불편함을 드러낸다.

이 사건은 하야마가 지키고 싶어 하는 관계의 한계를 보여 준다. 그는 모두가 상처받지 않는 결말을 바라지만, 그런 결말을 만들기 위해 직접 손을 더럽히는 일에는 망설인다. 반면 하치만은 스스로 상처를 떠안는 방식으로 관계의 붕괴를 막는다. 두 사람의 차이는 이 에피소드에서 더욱 깊어진다.

=== 진로와 소문 ===
작중 후반부에는 학교 안에서 하야마와 [[유키노시타 유키노]]가 사귀고 있다는 소문이 퍼진다. 이 소문은 하야마의 진로 문제와 연결되어, 미우라가 봉사부에 의뢰를 하게 되는 계기가 된다. 하야마는 자신의 진로를 분명히 밝히지 않으며, 주변 사람들의 기대와 추측 속에 놓인다.<ref>원작 제10권.</ref>

이 에피소드에서 하야마는 자신에게 주어진 기대가 얼마나 큰지, 그리고 그 기대를 거스르기 어려워한다는 점을 보여 준다. 그는 스스로 선택하고 있다고 말하는 듯하지만, 실제로는 주변 사람들의 시선과 과거의 관계에 크게 영향을 받는다. 또한 유키노시타 가와의 인연, 하치만에 대한 경쟁심, 미우라의 감정이 겹치며 하야마의 복잡한 내면이 드러난다.

=== 최종부 ===
최종부에서 하야마는 하치만, 유키노, 유이가하마 유이의 관계가 변화하는 과정을 주변에서 지켜보는 위치에 선다. 그는 여전히 집단의 균형과 분위기를 중시하지만, 이전보다 하치만의 행동을 더 분명하게 의식한다. 하야마는 하치만의 방식을 싫어하면서도, 그가 결국 자신이 피하려 했던 선택을 해내는 인물이라는 사실을 인정한다.

하야마의 서사는 명확한 승패나 성장 서사로 정리되기보다, “기대받는 사람”이 끝까지 짊어지는 부담을 보여 주는 방향으로 마무리된다. 그는 하치만과 완전히 화해하거나 대립하는 인물이 아니라, 하치만과 다른 방식으로 청춘의 불완전함을 드러내는 인물로 남는다.

== 대인 관계 ==
=== 히키가야 하치만 ===
같은 반 학생이자 하야마와 가장 뚜렷하게 대비되는 인물이다. 하야마는 하치만을 완전히 배척하지 않으며, 오히려 그의 관찰력과 문제 해결 능력을 인정한다. 그러나 하치만이 자신을 악역으로 만들거나 일부러 상처받는 방식으로 문제를 해결하는 것에는 강한 거부감을 보인다. 두 사람은 서로를 불편하게 여기면서도 무시할 수 없는 관계이다.

=== 유키노시타 유키노 ===
어릴 적부터 알고 지낸 사이이다. 두 사람은 서로의 과거를 어느 정도 알고 있지만, 현재의 관계는 편안하지 않다. 하야마는 유키노에게 쉽게 다가가지 못하고, 유키노 역시 하야마에게 거리를 둔다. 이는 과거에 있었던 일과 유키노시타 가를 둘러싼 관계가 두 사람 사이에 남아 있기 때문이다.

=== 유키노시타 하루노 ===
유키노의 언니로, 하야마와는 오래전부터 알고 지낸 사이다. 하루노는 하야마의 성격과 약점을 잘 파악하고 있으며, 종종 그의 태도나 선택을 떠보듯이 대한다. 하야마는 하루노에게 예의를 갖추지만, 완전히 편안해하지는 않는다. 하루노 앞에서 하야마는 평소의 완벽한 리더 이미지가 흔들리는 모습을 보이기도 한다.

=== 미우라 유미코 ===
같은 반의 중심 그룹에 속한 인물이다. 미우라는 하야마에게 강한 호감과 신뢰를 보이며, 하야마 역시 미우라를 가볍게 대하지 않는다. 그러나 하야마는 미우라의 감정에 명확한 답을 주기보다는, 그룹 전체의 관계가 유지되는 쪽을 택하는 경우가 많다. 이 때문에 미우라의 감정은 작품 안에서 하야마 그룹의 불안정성을 드러내는 요소가 된다.

=== 토베 카케루 ===
하야마 그룹의 일원이다. 토베는 밝고 가벼운 성격으로 그룹의 분위기를 띄우며, 하야마를 친구이자 리더처럼 따른다. 하야마는 토베의 행동을 조율하거나 제지하는 역할을 맡는 경우가 많다. 수학여행 에피소드에서는 토베의 고백 문제가 하야마 그룹의 균형을 흔드는 핵심 사건으로 작용한다.

=== 에비나 히나 ===
하야마 그룹의 일원이다. 에비나는 독특한 취향과 관찰력을 지닌 인물로, 그룹 안의 미묘한 감정선을 알고 있으면서도 겉으로는 가볍게 넘기는 태도를 보인다. 하야마는 에비나를 포함한 그룹 전체의 관계가 무너지지 않도록 조정자 역할을 하지만, 에비나 역시 하야마가 모든 문제를 해결할 수 없다는 사실을 알고 있다.

=== 유이가하마 유이 ===
같은 반 학생이며, 하야마 그룹과 봉사부 사이에 걸쳐 있는 인물이다. 유이는 하야마 일행과 자연스럽게 어울릴 수 있는 사교성을 갖고 있지만, 동시에 봉사부의 일원으로서 하치만과 유키노의 문제에도 깊이 관여한다. 이 때문에 유이는 하야마가 유지하려는 교실의 관계와, 하치만이 추구하는 “진짜”의 관계 사이를 이어 주는 위치에 놓인다.

=== 이시키 이로하 ===
후배이자 학생회장이다. 하야마에게 호감을 보이는 인물 중 하나이며, 하야마의 인기와 영향력을 잘 알고 있다. 하야마는 이로하에게 직접적으로 깊게 관여하지는 않지만, 이로하가 하치만과 봉사부에 접근하는 계기 중 하나로 하야마에 대한 관심이 작용한다.

== 작중 역할과 주제성 ==
하야마는 작품에서 “잘 적응한 사람”의 얼굴을 하고 있지만, 실제로는 타인의 기대에 얽매인 인물이다. 그는 하치만처럼 사회적 관계를 냉소적으로 끊어내지 못하고, 유키노처럼 정면으로 부딪히지도 못한다. 대신 하야마는 관계가 유지되는 상태를 가장 안전한 답으로 선택한다.

이러한 태도는 장점이자 한계이다. 하야마가 있기 때문에 그의 그룹은 쉽게 무너지지 않고, 반의 분위기도 안정적으로 유지된다. 그러나 그가 갈등을 덮어 두기 때문에, 그룹 내부의 문제는 근본적으로 해결되지 않는다. 미우라의 호감, 토베의 고백, 에비나의 회피, 유키노와의 과거, 하치만에 대한 경쟁심은 모두 하야마가 완전히 정리하지 못한 문제들이다.

하야마는 하치만의 반대편에 있는 것처럼 보이지만, 두 사람은 모두 인간관계의 불완전함을 알고 있다는 점에서 닮아 있다. 차이는 그 불완전함을 어떻게 처리하느냐에 있다. 하치만은 관계를 망가뜨리더라도 진실에 가까운 결론을 끌어내려 하고, 하야마는 진실을 흐리더라도 관계가 유지되는 상태를 지키려 한다.

== 애니메이션 및 게임 ==
TV 애니메이션 《역시 내 청춘 러브코메디는 잘못됐다. 완》 공식 홈페이지에서는 하야마가 하치만의 클래스메이트이자 축구부 소속의 인기인으로 소개된다.<ref name="tbs-kan" /> 성우는 시리즈 전반에서 [[콘도 타카시]]가 담당하였다.<ref name="tbs-cast" />

게임판에서는 《역시 게임에서도 내 청춘 러브코메디는 잘못됐다.》 계열 작품에 등장한다. 2023년 4월 27일에는 Nintendo Switch 및 PlayStation 4용 게임 《역시 게임에서도 내 청춘 러브코메디는 잘못됐다. 완》이 발매되었으며, 해당 공식 홈페이지의 캐릭터 목록에서도 하야마는 “하치만의 클래스메이트, 축구부 소속의 인기인”으로 소개된다.<ref name="mages-game">[https://oregairu.mages.co.jp/character.html Switch/PS4 《역시 게임에서도 내 청춘 러브코메디는 잘못됐다. 완》 공식 홈페이지: 캐릭터.]</ref>

== 관련 공식 전개 ==
원작 본편은 제14권으로 완결되었다.<ref name="shogakukan-14">[https://shogakukan-comic.jp/news/21758 小学館コミック, 《역시 내 청춘 러브코메디는 잘못됐다.》 완결권 발매 기념 기사, 2019년 11월 20일.]</ref> 이후에도 외전, 게임, 애니메이션 관련 전개가 이어졌다. 2026년 기준 가가가문고 15주년 특설 사이트에서는 《역시 내 청춘 러브코메디는 잘못됐다.》의刊行 15주년과 전 세계 누계 1500만 부 돌파가 공지되었고, 관련 기획으로 《결 3》 발매 예정 및 15주년 기념 무크 발매 등이 안내되었다.<ref name="gagaga-15th">[https://gagagabunko.jp/special/oregairu/15th/ 가가가문고 《역시 내 청춘 러브코메디는 잘못됐다.》 15주년 특설 사이트.]</ref>

== 기타 ==

* 성우는 [[콘도 타카시]]이다.
* 축구부 소속이며, 운동과 학업 양쪽에서 뛰어난 인물로 묘사된다.
* 공식 프로필상 생일은 9월 28일, 혈액형은 B형이다.<ref name="tbs-1st" />
* 공식 프로필상 취미는 독서, 영화감상, 풋살, 기타, 해양 스포츠이며, 특기는 축구와 기타이다.<ref name="tbs-1st" />
* 좌우명은 [[스티브 잡스]]의 “Your time is limited, so don't waste it living someone else's life.”이다.<ref name="tbs-1st" />
* 하치만과는 정반대의 방식으로 인간관계를 바라보는 인물이며, 작품의 주제인 “진짜”와 “겉으로 유지되는 관계”를 드러내는 데 중요한 역할을 한다.
* 작중에서 하야마가 유지하려는 그룹의 안정성은 미우라, 토베, 에비나 등 주변 인물의 감정과 맞물리며 여러 사건의 원인이 된다.

== 주석 ==
<references />

[[분류:역시 내 청춘 러브코메디는 잘못됐다.]]
[[분류:남자 캐릭터]]
[[분류:고등학생 캐릭터]]
[[분류:축구부 캐릭터]]
[[분류:리더 캐릭터]]
[[분류:생일/9월 28일]]
[[분류:혈액형 B형]]

미디어위키/문법/넘겨주기

2026-07-09T07:03:50Z

Gaon12: 넘겨주기 문서에 대한 상세한 설명과 예시, 하드/소프트 넘겨주기, HTTP 상태 코드, 관리 설정 등을 추가했습니다.

==개요==
이 문서는 위키 문법 도우미 문서 중 [[도움말:위키 문법/3단계#넘기기 문서|넘겨주기 문서]]에 대해 자세히 알아보는 문서입니다.

넘겨주기 문서란 특정 문서 제목으로 접속한 사용자를 다른 문서로 안내하는 문서입니다. 예를 들어 어떤 주제가 여러 이름으로 불리거나, 약어·정식 명칭·띄어쓰기 차이·대소문자 차이·옛 문서명과 새 문서명이 함께 쓰이는 경우에 사용됩니다.<ref name="mw-help-redirects">[https://www.mediawiki.org/wiki/Help:Redirects MediaWiki Help:Redirects]</ref>

예를 들어 [[smc]]라는 문서가 [[메카시티:ZERO]] 문서로 넘겨주는 문서라면, 사용자가 [[smc]]를 입력하거나 해당 링크를 클릭했을 때 최종적으로 [[메카시티:ZERO]] 문서가 표시됩니다.

==넘겨주기 문서란?==
넘겨주기 문서는 문서의 실제 내용 대신 다음과 같은 넘겨주기 명령을 담고 있는 문서입니다.

<nowiki>#REDIRECT [[대상 문서 이름]]</nowiki>

또는 한국어 미디어위키 환경에서는 다음과 같은 형식도 사용할 수 있습니다.

<nowiki>#넘겨주기 [[대상 문서 이름]]</nowiki>

넘겨주기 문서는 일반 문서처럼 문서 역사, 토론 문서, 편집 기능을 가질 수 있습니다. 다만 사용자가 일반적으로 문서 제목을 눌러 접속하면 넘겨받는 대상 문서가 표시됩니다.

==작동 원리==
A라는 문서가 B라는 문서로 넘겨주는 문서라고 가정하면, 사용자의 이동 흐름은 다음과 같이 이해할 수 있습니다.

(사용자) → (A 문서 요청) → (미디어위키가 A 문서의 넘겨주기 명령 확인) → (B 문서 표시)

중요한 점은, 일반적인 미디어위키 문서 넘겨주기는 단순히 웹 서버의 HTTP 301 또는 HTTP 302 리디렉션과 완전히 같은 개념이 아니라는 점입니다. 미디어위키는 넘겨주기 문서를 해석한 뒤 대상 문서를 표시하고, 문서 제목 아래에 “넘겨받음” 또는 “Redirected from”과 같은 안내 문구를 표시할 수 있습니다.<ref name="mw-help-redirects" />

대상 문서에서 넘겨주기 원본 문서를 직접 보고 싶다면 URL 끝에 다음과 같은 매개변수를 붙여 접속할 수 있습니다.

<nowiki>?redirect=no</nowiki>

예를 들어 다음과 같은 주소 형식입니다.

<nowiki>https://example.org/wiki/넘겨주기문서?redirect=no</nowiki>

이렇게 접속하면 대상 문서로 바로 넘어가지 않고, 넘겨주기 문서 자체를 확인하거나 편집할 수 있습니다.

==하드 넘겨주기와 소프트 넘겨주기==
미디어위키의 넘겨주기는 크게 하드 넘겨주기와 소프트 넘겨주기로 나누어 설명할 수 있습니다.<ref name="mw-help-redirects" />

===하드 넘겨주기===
하드 넘겨주기는 사용자가 넘겨주기 문서에 접속했을 때 대상 문서가 바로 표시되는 방식입니다. 일반적으로 문서 맨 앞에 다음과 같은 문법을 넣어 만듭니다.

<nowiki>#REDIRECT [[대상 문서 이름]]</nowiki>

또는

<nowiki>#넘겨주기 [[대상 문서 이름]]</nowiki>

이 문서에서 주로 설명하는 넘겨주기는 하드 넘겨주기입니다.

===소프트 넘겨주기===
소프트 넘겨주기는 사용자를 자동으로 이동시키지 않고, 현재 문서에 “이 문서로 이동하세요”와 같은 안내 링크를 보여주는 방식입니다. 보통 틀을 사용해 구현합니다.

소프트 넘겨주기는 다음과 같은 경우에 사용할 수 있습니다.

* 다른 위키나 외부 사이트로 안내해야 할 때
* 특수 문서처럼 하드 넘겨주기가 제한될 수 있는 곳으로 안내할 때
* 자동 이동보다 안내 문구를 보여주는 편이 적절할 때

미디어위키 설정에 따라 특수 문서나 다른 위키로의 하드 넘겨주기가 제한될 수 있으며, 이런 경우 소프트 넘겨주기처럼 처리될 수 있습니다.<ref name="mw-manual-redirects">[https://www.mediawiki.org/wiki/Manual:Redirects MediaWiki Manual:Redirects]</ref>

==301 리디렉션? 302 리디렉션?==
[[HTTP 상태 코드]]에서 페이지 이동과 관련해 자주 언급되는 코드는 [[HTTP 상태 코드#301 Moved Permanently|301]]과 [[HTTP 상태 코드#302 Found|302]]입니다. 자세한 내용은 [[HTTP 상태 코드/리디렉션]] 문서를 참고하세요.

{| class="wikitable"
! 상태 코드 !! 의미 !! 일반적인 용도
|-
| 301 Moved Permanently || 영구 이동 || 주소가 영구적으로 바뀌었을 때 사용합니다.
|-
| 302 Found || 임시 이동 || 요청한 자원이 임시로 다른 주소에 있을 때 사용합니다.
|}

301은 요청한 자원이 영구적으로 다른 URL로 이동했다는 뜻입니다. 브라우저는 새 주소로 다시 요청하고, 검색 엔진도 보통 새 주소를 더 중요한 주소로 취급합니다.<ref name="mdn-301">[https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301 MDN Web Docs: 301 Moved Permanently]</ref>

302는 요청한 자원이 임시로 다른 URL에 있다는 뜻입니다. 브라우저는 새 주소로 다시 요청하지만, 의미상 “원래 주소가 완전히 사라졌다”는 뜻은 아닙니다.<ref name="mdn-302">[https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/302 MDN Web Docs: 302 Found]</ref>

===문서 넘겨주기는 항상 302인가?===
결론부터 말하면, “미디어위키의 문서 넘겨주기”와 “HTTP 302 리디렉션”은 구분해야 합니다.

미디어위키의 일반 넘겨주기 문서는 문서 내용에 적힌 넘겨주기 명령을 미디어위키가 해석하여 대상 문서를 보여주는 기능입니다. 따라서 사용자가 개발자 도구에서 보는 HTTP 상태 코드는 접속한 URL, 짧은 URL 설정, 검색 기능, 특수 문서, 서버 설정, 캐시 서버, 확장 기능에 따라 달라질 수 있습니다.

미디어위키에는 PHP 코드에서 특정 URL로 HTTP 리디렉션을 보낼 때 쓰는 <code>OutputPage::redirect()</code> 기능이 있으며, 이 기능의 기본 응답 코드는 302입니다.<ref name="mw-outputpage">[https://www.mediawiki.org/wiki/Manual:OutputPage.php MediaWiki Manual:OutputPage.php]</ref> 그러나 이것은 “모든 넘겨주기 문서가 반드시 HTTP 302를 반환한다”는 뜻이 아닙니다.

따라서 개발자 도구에서 302가 보였다면 다음 중 어느 단계에서 발생했는지 확인해야 합니다.

* 검색창에서 정확한 문서명으로 이동하는 과정
* <code>Special:Search</code>에서 문서로 이동하는 과정
* 짧은 URL과 실제 <code>index.php</code> 주소 사이의 이동
* HTTP에서 HTTPS로 이동하는 서버 설정
* 대소문자나 표준 문서명으로 보정되는 과정
* 확장 기능이나 스킨에서 추가한 별도 리디렉션
* 실제 넘겨주기 문서 처리

==Web Sniffer로 확인하기==
[[Web Sniffer]]는 HTTP 요청 및 응답 헤더를 웹에서 확인할 수 있는 도구입니다. 예를 들어 [[smc]] 문서가 넘겨주기 문서인지 확인하고 싶다면 다음 주소를 입력할 수 있습니다.

[https://www.gaonwiki.com/w/Smc https://www.gaonwiki.com/w/Smc]

이 주소를 Web Sniffer에 입력했을 때 <b>HTTP Response Header</b> 문단에 <code>HTTP/1.1 200 OK</code>가 표시될 수 있습니다.

이 경우 200 OK가 표시된다고 해서 넘겨주기가 작동하지 않는다는 뜻은 아닙니다. 미디어위키가 넘겨주기 문서를 해석하여 대상 문서의 내용을 정상적으로 표시했기 때문에 최종 응답이 200으로 보일 수 있습니다.

[[파일:web_sniffer_smc문서_확인.png]]

===왜 개발자 도구와 결과가 다르게 보일 수 있는가?===
브라우저 개발자 도구에서는 한 번의 접속 과정에서 발생한 여러 요청이 모두 보입니다. 예를 들어 검색창에 <code>smc</code>를 입력하고 “보기”를 눌렀다면, 처음에는 다음과 비슷한 특수 문서 주소로 요청될 수 있습니다.

<nowiki>/w/index.php?title=특수:검색&search=smc&go=보기</nowiki>

그 다음 미디어위키가 해당 검색어와 일치하는 문서로 보내기 위해 다른 주소로 이동시킬 수 있습니다. 이 과정에서 302가 보일 수 있습니다.

즉, 개발자 도구에서 302가 보였다고 해서 그것이 반드시 “넘겨주기 문서 자체의 HTTP 응답”이라고 단정하면 안 됩니다. 302는 검색 이동, 특수 문서 이동, 표준 URL 보정 등 다른 단계에서 발생했을 수 있습니다.

[[File:whale_developer_tools_smc문서_확인.png]]

개발자 도구에서 확인할 때는 각 요청의 주소를 구분해야 합니다.

{| class="wikitable"
! 확인할 항목 !! 의미
|-
| Request URL || 실제로 브라우저가 요청한 주소입니다.
|-
| Status Code || 해당 요청에 대한 HTTP 응답 코드입니다.
|-
| Location 헤더 || 301, 302 등에서 이동할 대상 주소를 알려주는 헤더입니다.
|-
| 최종 문서 URL || 여러 번의 이동이 끝난 뒤 실제로 표시된 문서 주소입니다.
|}

==개발자 도구로 정확히 확인하는 방법==
브라우저 개발자 도구에서 넘겨주기 과정을 확인하려면 다음 순서로 진행하면 됩니다.

# 개발자 도구를 엽니다.
# “네트워크” 또는 “Network” 탭을 엽니다.
# “문서” 또는 “Doc” 요청만 필터링하면 보기 쉽습니다.
# “Preserve log” 또는 “로그 보존” 기능을 켭니다.
# 확인할 넘겨주기 문서 주소로 접속합니다.
# 가장 위의 요청부터 순서대로 Request URL, Status Code, Location 헤더를 확인합니다.

이때 가장 중요한 것은 “어떤 URL에서 어떤 URL로 이동했는가”입니다. 단순히 302가 보였다는 사실만으로는 넘겨주기 문서의 동작을 정확히 설명하기 어렵습니다.

==넘겨주기 문서 만드는 방법==
넘겨주기 문서는 다음 두 방식 중 하나를 사용하면 됩니다.

===REDIRECT 사용===
가장 널리 쓰이는 방식은 <code>#REDIRECT</code>입니다.

<nowiki>#REDIRECT [[넘겨줄 대상]]</nowiki>

예시는 다음과 같습니다.

<nowiki>#REDIRECT [[미디어위키]]</nowiki>

===넘겨주기 사용===
한국어 환경에서는 다음과 같은 형식도 사용할 수 있습니다.

<nowiki>#넘겨주기 [[대상 문서 이름]]</nowiki>

예시는 다음과 같습니다.

<nowiki>#넘겨주기 [[미디어위키]]</nowiki>

===문단으로 넘겨주기===
문서 전체가 아니라 특정 문단으로 넘겨줄 수도 있습니다.

<nowiki>#REDIRECT [[대상 문서#문단 이름]]</nowiki>

예시는 다음과 같습니다.

<nowiki>#REDIRECT [[HTTP 상태 코드#3xx 리디렉션]]</nowiki>

다만 문단 제목이 나중에 바뀌면 넘겨주기가 의도한 위치로 정확히 이동하지 않을 수 있습니다. 중요한 넘겨주기라면 문단 제목 변경 후에도 함께 점검하는 것이 좋습니다.

===이름공간을 포함한 넘겨주기===
일반 문서가 아닌 다른 이름공간으로 넘겨줄 수도 있습니다.

<nowiki>#REDIRECT [[도움말:위키 문법]]</nowiki>

<nowiki>#REDIRECT [[분류:미디어위키]]</nowiki>

<nowiki>#REDIRECT [[틀:안내]]</nowiki>

단, 파일, 특수 문서, 다른 위키로의 넘겨주기는 위키 설정에 따라 제한될 수 있습니다.

==작성할 때 주의할 점==
넘겨주기 명령은 문서의 맨 앞에 있어야 합니다. <code>#REDIRECT</code> 또는 <code>#넘겨주기</code> 앞에 일반 글자, 공백이 아닌 다른 내용, 틀, 분류, HTML 태그 등이 있으면 넘겨주기가 작동하지 않을 수 있습니다.<ref name="mw-help-redirects" />

올바른 예시는 다음과 같습니다.

<nowiki>#REDIRECT [[미디어위키]]</nowiki>

잘못된 예시는 다음과 같습니다.

<nowiki>이 문서는 미디어위키로 넘겨줍니다.
#REDIRECT [[미디어위키]]</nowiki>

위와 같이 넘겨주기 명령 앞에 문장이 있으면 넘겨주기가 작동하지 않을 수 있습니다.

분류를 넣어야 한다면 보통 넘겨주기 명령 아래에 넣습니다.

<nowiki>#REDIRECT [[미디어위키]]

[[분류:넘겨주기 문서]]</nowiki>

==기존 내용이 있는 문서를 넘겨주기로 바꿀 때==
기존 문서에 내용이 있는데 넘겨주기 문서로 바꾸면, 사용자는 더 이상 기존 내용을 바로 보지 않고 대상 문서로 이동하게 됩니다.

따라서 기존 문서를 넘겨주기로 바꾸기 전에는 다음을 확인하는 것이 좋습니다.

* 기존 내용이 대상 문서에 이미 포함되어 있는가?
* 기존 문서의 역사를 보존해야 하는가?
* 문서 병합이 필요한가?
* 토론 문서에 관련 논의가 있는가?
* 다른 문서에서 해당 문서를 많이 링크하고 있는가?
* 넘겨주기 처리보다 동음이의어 문서가 더 적절하지 않은가?

특히 내용이 많은 문서를 단순히 넘겨주기로 바꾸면 문서 정보가 사실상 숨겨지는 효과가 생길 수 있으므로 주의해야 합니다.

==문서 이동과 자동 넘겨주기==
미디어위키에서 문서 제목을 바꾸기 위해 “이동” 기능을 사용하면, 보통 이전 문서명에서 새 문서명으로 가는 넘겨주기 문서가 자동으로 만들어집니다.<ref name="mw-help-redirects" />

예를 들어 [[A]] 문서를 [[B]]로 이동하면, 기존의 [[A]] 문서는 [[B]]로 넘겨주는 문서가 됩니다.

다만 일부 권한을 가진 사용자는 이동할 때 넘겨주기를 남기지 않을 수도 있습니다. 미디어위키에서는 <code>suppressredirect</code> 권한을 가진 사용자가 문서를 이동하면서 넘겨주기 생성을 생략할 수 있습니다.<ref name="mw-help-redirects" />

==이중 넘겨주기==
이중 넘겨주기란 A 문서가 B 문서로 넘겨주고, B 문서가 다시 C 문서로 넘겨주는 상태를 말합니다.

A → B → C

미디어위키에서는 이중 넘겨주기가 문제를 일으킬 수 있습니다. 일반적으로 넘겨주기는 한 단계만 따라가는 것으로 처리되므로, A에서 C까지 자동으로 이어지지 않을 수 있습니다.<ref name="mw-help-redirects" />

올바른 처리 방식은 A를 직접 C로 넘겨주도록 고치는 것입니다.

A → C
B → C

이중 넘겨주기는 다음 특수 문서에서 확인할 수 있습니다.

[[특수:이중넘겨주기]]

또는 영어 인터페이스에서는 다음 특수 문서로 확인할 수 있습니다.

[[Special:DoubleRedirects]]

MediaWiki 1.44부터는 넘겨주기 대상이 다시 넘겨주기 문서인 경우 저장 시 경고가 표시됩니다.<ref name="mw-help-redirects" />

==끊긴 넘겨주기==
끊긴 넘겨주기란 넘겨주기 대상 문서가 존재하지 않는 상태를 말합니다.

예를 들어 A 문서가 다음과 같이 작성되어 있다고 가정합니다.

<nowiki>#REDIRECT [[존재하지 않는 문서]]</nowiki>

이때 대상 문서가 실제로 존재하지 않으면 넘겨주기가 정상적으로 작동하지 않습니다.

끊긴 넘겨주기는 다음 특수 문서에서 확인할 수 있습니다.

[[특수:끊긴넘겨주기]]

또는 영어 인터페이스에서는 다음 특수 문서로 확인할 수 있습니다.

[[Special:BrokenRedirects]]

MediaWiki 1.44부터는 존재하지 않는 문서로 넘겨주기를 저장하려 할 때 경고가 표시됩니다.<ref name="mw-help-redirects" />

==넘겨주기 문서를 직접 보는 방법==
넘겨주기 문서 자체를 직접 보려면 다음 방법을 사용할 수 있습니다.

첫째, 대상 문서 상단 또는 제목 아래에 표시되는 “넘겨옴” 안내 링크를 클릭합니다.

둘째, 주소 뒤에 다음 매개변수를 붙입니다.

<nowiki>?redirect=no</nowiki>

예시는 다음과 같습니다.

<nowiki>https://www.gaonwiki.com/w/Smc?redirect=no</nowiki>

셋째, 넘겨주기 문서의 편집 링크로 바로 접속합니다.

<nowiki>https://www.gaonwiki.com/w/index.php?title=Smc&action=edit</nowiki>

==넘겨주기를 사용하면 좋은 경우==
넘겨주기는 다음과 같은 경우에 유용합니다.

* 약어에서 정식 명칭으로 넘겨줄 때
* 영문 표기에서 한글 표기로 넘겨줄 때
* 한글 표기에서 영문 표기로 넘겨줄 때
* 띄어쓰기 차이가 있는 문서를 하나로 모을 때
* 대소문자 차이가 있는 문서를 하나로 모을 때
* 옛 문서명에서 새 문서명으로 안내할 때
* 자주 틀리는 표기에서 올바른 표기로 안내할 때
* 별칭, 통칭, 줄임말을 대표 문서로 연결할 때
* 문서 이동 후 기존 링크를 보존할 때

예시는 다음과 같습니다.

<nowiki>#REDIRECT [[미디어위키]]</nowiki>

<nowiki>#REDIRECT [[HTTP 상태 코드]]</nowiki>

<nowiki>#REDIRECT [[가온 위키]]</nowiki>

==넘겨주기보다 다른 방식이 나은 경우==
항상 넘겨주기가 정답은 아닙니다. 다음 경우에는 다른 방식이 더 적절할 수 있습니다.

{| class="wikitable"
! 상황 !! 권장 방식
|-
| 같은 이름이 여러 의미를 가질 때 || 동음이의어 문서 작성
|-
| 단순 안내만 필요할 때 || 소프트 넘겨주기 또는 안내 틀 사용
|-
| 기존 문서 내용이 독립적으로 중요할 때 || 문서 병합 또는 요약 문단 작성
|-
| 외부 사이트로 보내야 할 때 || 외부 링크 또는 소프트 넘겨주기 사용
|-
| 대상 문서가 아직 없을 때 || 먼저 대상 문서를 만들거나 끊긴 넘겨주기 여부 확인
|}

예를 들어 “Apple”이라는 제목이 회사, 과일, 음반사 등 여러 의미를 가질 수 있다면 하나의 문서로 넘겨주기보다 동음이의어 문서를 만드는 편이 더 적절할 수 있습니다.

==넘겨주기와 검색==
넘겨주기 문서는 검색 편의성을 높이는 데 도움이 됩니다. 사용자가 정확한 문서명을 모르더라도 약어, 별칭, 다른 표기법으로 검색했을 때 대표 문서에 도달할 수 있기 때문입니다.

다만 넘겨주기 문서를 너무 많이 만들면 관리가 어려워질 수 있습니다. 특히 의미가 모호한 넘겨주기, 잘못된 표기, 특정 관점이 반영된 넘겨주기는 문서 품질에 영향을 줄 수 있습니다.

따라서 넘겨주기 문서를 만들 때는 다음 기준을 고려하는 것이 좋습니다.

* 실제로 사용자가 검색할 가능성이 높은 표현인가?
* 대상 문서와 의미가 충분히 일치하는가?
* 다른 의미로 해석될 가능성은 없는가?
* 동음이의어 문서가 더 적절하지 않은가?
* 나중에 일반 문서로 독립할 가능성이 있는가?

==넘겨주기와 분류==
넘겨주기 문서도 분류에 넣을 수 있습니다. 보통 넘겨주기 명령 아래에 분류를 적습니다.

<syntaxhighlight lang="mediawiki">
<nowiki>#REDIRECT [[대상 문서]]

[[분류:넘겨주기 문서]]</nowiki>
</syntaxhighlight>

다만 위키마다 넘겨주기 문서를 분류하는 규칙이 다를 수 있으므로, 해당 위키의 편집 지침을 따르는 것이 좋습니다.

==넘겨주기와 틀==
틀 문서도 넘겨주기로 만들 수 있습니다. 예를 들어 [[틀:알림]]을 [[틀:안내]]로 넘겨주면, 기존에 <code><nowiki>{{알림}}</nowiki></code>을 사용한 문서가 계속 작동하도록 할 수 있습니다.

<syntaxhighlight lang="mediawiki">
<nowiki>#REDIRECT [[틀:안내]]</nowiki>
</syntaxhighlight>

미디어위키에서는 넘겨주기 문서를 틀처럼 끼워 넣을 경우 대상 문서가 대신 포함될 수 있습니다.<ref name="mw-help-redirects" /> 이 기능은 틀 이름을 바꾸거나 별칭을 만들 때 유용합니다.

==넘겨주기와 링크 표시==
미디어위키는 넘겨주기 문서로 향하는 내부 링크에 <code>mw-redirect</code> CSS 클래스를 붙일 수 있습니다.<ref name="mw-help-redirects" /> 이를 이용하면 스킨이나 사용자 CSS에서 넘겨주기 링크를 일반 링크와 다르게 표시할 수 있습니다.

예를 들어 넘겨주기 링크를 다른 색으로 표시하도록 사용자 CSS를 설정하면, 문서 정리 작업에서 어떤 링크가 넘겨주기 문서를 가리키는지 더 쉽게 확인할 수 있습니다.

==관리자와 개발자를 위한 참고==
미디어위키는 넘겨주기 정보를 내부적으로 <code>redirect</code> 테이블에 기록합니다.<ref name="mw-manual-redirects" />

개발자 또는 사이트 관리자는 다음 설정과 기능을 참고할 수 있습니다.

{| class="wikitable"
! 항목 !! 설명
|-
| <code>$wgDebugRedirects</code> || 실제로 이동하지 않고 이동할 위치를 표시하도록 하는 디버그 설정입니다.
|-
| <code>$wgDisableHardRedirects</code> || 특수 문서나 다른 위키로의 하드 넘겨주기 등을 제한하는 설정입니다.
|-
| <code>$wgInvalidRedirectTargets</code> || 넘겨주기 대상으로 허용하지 않을 대상을 지정하는 설정입니다.
|-
| <code>$wgFixDoubleRedirects</code> || 이중 넘겨주기를 자동으로 수정하는 작업과 관련된 설정입니다.
|-
| <code>**STATICREDIRECT**</code> || 특정 넘겨주기 문서가 자동 이중 넘겨주기 수정 대상이 되지 않도록 할 때 사용하는 매직 워드입니다.
|-
| <code>OutputPage::redirect()</code> || PHP 코드에서 특정 URL로 HTTP 리디렉션 응답을 보낼 때 사용하는 기능입니다.
|}

주의할 점은 <code>OutputPage::redirect()</code>의 기본 응답 코드가 302라는 사실과, 일반 문서 넘겨주기의 동작 방식이 반드시 동일한 의미는 아니라는 점입니다.<ref name="mw-outputpage" />

==여담==
MediaWiki 1.44부터는 이중 넘겨주기 또는 존재하지 않는 문서로의 넘겨주기를 저장하려 할 때 경고가 표시됩니다.<ref name="mw-help-redirects" />

==각주==
<references />



[[분류:미디어위키]]
[[분류:도움말]]
[[분류:위키 문법]]

미적분

2026-07-09T04:18:18Z

Gaon12: 문서 개선

__toc__

== 개요 ==
'''미적분'''(微積分)은 '''미분'''(微分)과 '''적분'''(積分)을 아울러 이르는 말로, 수학에서 [[함수]]의 순간적인 변화율과 누적된 변화량을 다루는 분야를 일컫는다. 영어로는 각각 '''differentiation'''(미분)과 '''integration'''(적분)이라 하며, 이 둘을 통틀어 '''calculus'''라고 부른다.

미적분은 [[고등학교]] 수학 교육과정에서 문과와 이과를 막론하고 가장 많은 학생들이 어려워하는 단원 중 하나로 악명이 높다. 그러나 정작 그 핵심 아이디어는 "아주 작은 변화를 무한히 쪼개서 살펴본다"는 것 하나뿐이며, 이 아이디어 하나가 물리학, 공학, 경제학, 통계학 등 사실상 모든 자연과학·사회과학 분야의 기초를 이루고 있다.

== 역사 ==
미적분의 발견자는 흔히 [[아이작 뉴턴]]과 [[고트프리트 라이프니츠]] 두 사람으로 알려져 있다. 두 사람은 거의 비슷한 시기(17세기 후반)에 독립적으로 미적분학의 체계를 완성했는데, 이 때문에 둘 사이에는 누가 먼저 미적분을 발견했는지를 둘러싼 오랜 우선권 분쟁이 있었다. 결과적으로 오늘날에는 두 사람 모두 미적분의 공동 발견자로 인정받고 있으며, 현재 널리 쓰이는 <math>\frac{dy}{dx}</math> 같은 표기법은 라이프니츠가 고안한 것이다.

물론 미적분의 아이디어 자체는 이 두 사람 이전에도 존재했다. 고대 그리스의 [[아르키메데스]]는 '''실진법'''(exhaustion method)을 이용해 원의 넓이나 포물선 아래의 넓이를 구했는데, 이는 오늘날의 적분과 본질적으로 같은 발상이다. 이후 17세기에 [[페르마]], [[카발리에리]] 등이 접선의 기울기를 구하는 방법이나 무한소를 이용한 넓이 계산법을 연구하면서 미적분학의 토대가 마련되었다.

== 상세 ==
<math>f(x)</math>를 x에 대해 미분하면 <math>f'(x)</math>로 나타내며, <math>f(x)</math>를 x에 대해 n번 미분한 함수는 <math>f^{(n)}(x)</math>로 나타낸다. 이를 '''라그랑주 표기법'''이라 하는데, 정작 고등학교 교육과정에서는 <math>f^{(n)}(x)</math> 표기를 잘 다루지 않는다.

또한 y를 x에 대해 미분한 함수는 <math>\frac{dy}{dx}</math>라고 표기하는데, 이를 '''라이프니츠 표기법'''이라 한다. 라이프니츠 표기법은 [[연쇄법칙]]을 다룰 때 마치 분수처럼 약분되는 듯한 직관을 주기 때문에 매우 유용하게 쓰인다.

이 밖에도 뉴턴이 고안한 <math>\dot{y}</math> 같은 '''뉴턴 표기법'''(주로 시간에 대한 미분, 즉 물리학에서 속도·가속도를 나타낼 때 사용), 오일러가 고안한 <math>Df(x)</math> 같은 '''오일러 표기법''' 등이 존재하지만, 한국 고등학교 교육과정에서는 거의 다루지 않는다.

어떤 함수를 미분한 함수는 그 함수의 '''도함수'''(導函數)라고 부른다. 반대로, 어떤 함수를 적분해서 나온 함수는 그 함수의 '''부정적분'''(원시함수)이라고 부른다.

== 미분 ==

=== 미분계수의 정의 ===
미분하는 것은 '''순간변화율'''을 구하는 것이다. 이는 [[중학교]]·고등학교에서 배우는 평균변화율의 극한으로 이해할 수 있다.

함수 <math>f(x)</math>의 구간 <math>[a, x]</math>에서의 평균변화율은 다음과 같다.
:<math>\frac{f(x)-f(a)}{x-a}</math>

이는 좌표평면 위의 두 점 <math>(a,f(a))</math>, <math>(x,f(x))</math>를 잇는 직선(할선)의 기울기를 의미한다. 여기서 x를 a에 한없이 가깝게 보내면, 이 할선은 점점 점 <math>(a,f(a))</math>에서의 '''접선'''에 가까워진다. 이 극한값을 '''x=a에서의 미분계수'''라 하고, 함수 <math>f(x)</math>가 모든 점에서 미분계수를 가질 때 그 미분계수들을 모아놓은 함수를 도함수 <math>f'(x)</math>라 한다.

*<math>f'(a)=\lim_{x \to a}\frac{f(x)-f(a)}{x-a}</math>: 좌표가 각각 <math>(x,f(x))</math>, <math>(a,f(a))</math>인 두 점을 잇는 직선의 기울기의, x가 a로 다가갈 때의 극한값. 즉 <math>x=a</math>에서의 접선의 기울기라는 뜻이다.
*<math>f'(a)=\lim_{h \to 0}\frac{f(a+h)-f(a)}{h}</math>: <math>x=a+h</math>로 치환하면 <math>h=x-a</math>이므로 위 식에서 곧바로 유도되는 동치인 표현이다. h가 0에 한없이 가까워진다는 것은 x가 a에 한없이 가까워진다는 것과 같은 의미이다.

두 표기법은 완전히 같은 대상을 가리키지만, 실전 문제풀이에서는 상황에 따라 편한 쪽을 골라 쓰면 된다. 참고로 함수 <math>f(x)</math>가 <math>x=a</math>에서 미분가능하려면 반드시 그 점에서 '''연속'''이어야 한다(단, 역은 성립하지 않는다. 대표적인 반례가 <math>f(x)=|x|</math>로, <math>x=0</math>에서 연속이지만 미분은 불가능하다).

=== 도함수의 성질 ===
{| class="wikitable"
|- style="background-color:#ffff00;"
! 성질 ! 공식
|-
| 상수배 || <math>\{cf(x)\}'=cf'(x)</math>
|-
| 합의 미분 || <math>\{f(x)+g(x)\}'=f'(x)+g'(x)</math>
|-
| 곱의 미분(곱셈법칙) || <math>\{f(x)g(x)\}'=f'(x)g(x)+f(x)g'(x)</math>
|-
| 몫의 미분(나눗셈법칙) || <math>\left\{\frac{f(x)}{g(x)}\right\}'=\frac{f'(x)g(x)-f(x)g'(x)}{\{g(x)\}^2}</math> (단, <math>g(x) \ne 0</math>)
|-
| 합성함수의 미분(연쇄법칙) || <math>\{f(g(x))\}'=f'(g(x))g'(x)</math>
|}

곱셈법칙은 정의에 따라 <math>f(x+h)g(x+h)-f(x)g(x)</math> 사이에 <math>f(x+h)g(x)</math>를 더하고 빼는 트릭으로 증명할 수 있으며, 연쇄법칙은 라이프니츠 표기법을 빌리면 <math>\frac{dy}{dx}=\frac{dy}{du}\cdot\frac{du}{dx}</math>처럼 마치 분수의 약분처럼 직관적으로 쓸 수 있어 매우 유용하다. 다만 엄밀한 증명에는 <math>\Delta u = 0</math>이 되는 경우를 별도로 처리해야 하는 등 주의가 필요하다.

=== 여러 가지 함수의 미분법 ===
f(x)를 x에 대해 미분할 때 기준.
{| class="wikitable"
|- style="background-color:#ffff00;"
! <math>f(x)</math> !! <math>f'(x)</math> !! 증명 및 비고
|-
| <math>c</math> (상수) || <math>0</math> || 상수함수는 변화가 없으므로 순간변화율도 항상 0이다.
|-
| <math>x^n</math> (n은 실수) || <math>nx^{n-1}</math> || 미분계수의 정의에 의해 <math>x^n</math>의 도함수는 <math>\lim_{x \to a}\frac{x^n-a^n}{x-a}</math>이다. 인수분해 공식 <math>x^n-a^n=(x-a)(x^{n-1}+x^{n-2}a+\cdots+xa^{n-2}+a^{n-1})</math>을 이용하면 <math>(x-a)</math>가 약분되어 <math>\lim_{x \to a}(x^{n-1}+x^{n-2}a+\cdots+a^{n-1})</math>이 남는다. 이 식에서 x를 a로 보내면 <math>a^{n-1}</math>항이 n개가 되므로 <math>na^{n-1}</math>, 즉 <math>nx^{n-1}</math>을 얻는다. n이 자연수가 아닌 실수인 경우에도 로그미분법 등을 이용해 같은 결과를 얻을 수 있다.
|-
| <math>e^x</math> || <math>e^x</math> || 자연상수 e는 애초에 "미분해도 자기 자신이 되는 지수함수의 밑"으로 정의될 만큼 미적분과 떼려야 뗄 수 없는 상수이다.
|-
| <math>a^x</math> (a>0, a≠1) || <math>a^x \ln a</math> || <math>a^x=e^{x\ln a}</math>로 바꾸고 연쇄법칙을 적용하면 얻을 수 있다. 원 문서에 있던 <math>a^x \ln x</math>는 틀린 공식이므로 주의. 밑이 자연상수 e일 때는 <math>\ln e=1</math>이므로 <math>e^x</math> 그대로 남는다.
|-
| <math>\ln x</math> || <math>\frac{1}{x}</math> || <math>y=\ln x</math>이면 <math>e^y=x</math>이므로 양변을 x에 대해 음함수 미분하면 <math>e^y \frac{dy}{dx}=1</math>, 즉 <math>\frac{dy}{dx}=\frac{1}{e^y}=\frac{1}{x}</math>이다.
|-
| <math>\log_a x</math> (a>0, a≠1) || <math>\frac{1}{x\ln a}</math> || 밑변환공식 <math>\log_a x=\frac{\ln x}{\ln a}</math>을 이용해 위 결과에서 바로 유도된다.
|-
| <math>\sin x</math> || <math>\cos x</math> || <math>\lim_{h \to 0}\frac{\sin(x+h)-\sin x}{h}</math>를 삼각함수의 덧셈정리로 전개하고, 극한 <math>\lim_{h\to0}\frac{\sin h}{h}=1</math>, <math>\lim_{h\to0}\frac{\cos h -1}{h}=0</math>을 이용하면 증명된다.
|-
| <math>\cos x</math> || <math>-\sin x</math> || <math>\sin x</math>의 증명과 같은 방식으로 유도되며, <math>\cos x=\sin\left(\frac{\pi}{2}-x\right)</math> 관계와 연쇄법칙을 이용해도 증명할 수 있다.
|-
| <math>\tan x</math> || <math>\sec^2 x = \frac{1}{\cos^2 x}</math> || <math>\tan x=\frac{\sin x}{\cos x}</math>이므로 몫의 미분법을 적용하면 얻을 수 있다.
|-
| <math>\cot x</math> || <math>-\csc^2 x</math> || <math>\tan x</math>와 마찬가지 방식으로 증명된다.
|-
| <math>\sec x</math> || <math>\sec x \tan x</math> || <math>\sec x = (\cos x)^{-1}</math>로 보고 연쇄법칙을 적용하면 얻을 수 있다.
|-
| <math>\csc x</math> || <math>-\csc x \cot x</math> || 위와 같은 방식으로 증명된다.
|}

== 적분 ==
미분이 순간변화율(기울기)을 구하는 것이라면, '''적분'''(積分)은 반대로 그 도함수로부터 원래 함수를 복원하거나, 곡선과 x축 사이의 넓이처럼 무한히 잘게 쪼갠 값을 다시 모두 더하는 연산이다. 즉 미분과 적분은 서로 역연산 관계에 있으며, 이 사실을 '''미적분학의 기본정리'''라고 한다.

=== 부정적분 ===
어떤 함수 <math>f(x)</math>를 미분해서 <math>F'(x)=f(x)</math>가 되는 함수 <math>F(x)</math>를 <math>f(x)</math>의 '''원시함수'''라 하고, 이를 구하는 것을 '''부정적분'''이라 하며 다음과 같이 나타낸다.
:<math>\int f(x)\,dx = F(x)+C</math>

여기서 C는 '''적분상수'''로, 상수를 미분하면 0이 되기 때문에 원시함수는 하나로 유일하게 정해지지 않고 상수 차이만큼 무한히 많이 존재한다. 이 적분상수 C를 빠뜨리는 것은 수능이나 내신에서 매우 흔한 실수 유형 중 하나이다.

=== 정적분 ===
'''정적분'''은 함수 <math>f(x)</math>와 x축, 그리고 두 직선 <math>x=a</math>, <math>x=b</math> 사이의 (부호 있는) 넓이를 구하는 연산으로, 구간 <math>[a,b]</math>를 n등분한 뒤 각 조각을 직사각형으로 근사하여 그 넓이의 합의 극한을 취하는 '''리만 합'''(Riemann sum)으로 정의된다.
:<math>\int_{a}^{b} f(x)\,dx = \lim_{n \to \infty} \sum_{k=1}^{n} f(x_k)\Delta x</math>

부정적분과 달리 정적분의 결과값은 함수가 아니라 하나의 '''실수'''라는 점이 가장 큰 차이이다.

=== 미적분학의 기본정리 ===
함수 <math>f(x)</math>가 구간에서 연속이고 <math>F(x)</math>가 <math>f(x)</math>의 한 원시함수일 때, 다음이 성립한다.
:<math>\int_{a}^{b} f(x)\,dx = F(b)-F(a)</math>

이 정리 덕분에 복잡한 리만 합의 극한을 직접 계산하지 않고도, 부정적분(원시함수)만 구하면 정적분 값을 손쉽게 계산할 수 있게 된다. 뉴턴과 라이프니츠가 독립적으로 이 정리에 도달했다는 사실이야말로 두 사람을 미적분의 공동 발견자로 부르는 핵심적인 이유이다.

== 활용 ==
* '''물리학''': 위치를 시간에 대해 미분하면 속도, 속도를 다시 미분하면 가속도가 된다. 반대로 가속도를 시간에 대해 적분하면 속도, 속도를 적분하면 위치를 구할 수 있다. [[뉴턴 역학]] 자체가 미적분 없이는 성립할 수 없는 학문이다.
* '''경제학''': 한계비용, 한계효용 등 '한계'(marginal)가 붙는 개념은 전부 미분 개념이며, 소비자잉여·생산자잉여 등은 정적분으로 계산한다.
* '''공학''': 신호처리, 제어이론, 전자기학 등 공학 전반에서 미분방정식의 형태로 필수적으로 사용된다.
* '''통계학''': 확률밀도함수를 적분하면 누적확률이 되며, 정규분포를 비롯한 대부분의 연속확률분포 이론이 적분에 기반한다.

== 여담 ==
* 미분과 적분 중에서는 미분이 상대적으로 기계적인 계산에 가까워 학생들이 먼저 익숙해지는 편이고, 적분은 피적분함수를 보고 어떤 치환이나 방법을 써야 할지 감을 잡아야 하는 경우가 많아 상대적으로 어렵게 느끼는 학생이 많다.
* "미적분을 포기한다"는 뜻의 '''미포자'''라는 신조어가 있을 정도로, 한국 고등학교 수학에서 심리적 장벽이 매우 높은 단원으로 꼽힌다.
* 대학수학능력시험에서는 선택과목 중 하나로 존재하며, 자연계열 상위권 대학에 진학하려는 이과 학생들은 사실상 필수로 선택하는 경우가 많다.

== 같이 보기 ==
* [[함수]]
* [[극한]]
* [[연속함수]]
* [[급수]]
* [[미분방정식]]
* [[테일러 급수]]
* [[아이작 뉴턴]]
* [[고트프리트 라이프니츠]]

라이믹스/매뉴얼/도메인 변경

2026-06-29T02:15:47Z

Gaon12: 순번 오류 수정

== 개요 ==
라이믹스는 [https://github.com/rhymix/rhymix/pull/728 멀티도메인]을 지원하므로 도메인을 처리하는 방법이 XE 1.x와 다릅니다. 아래의 순서를 따르면 대부분의 경우 DB나 설정 파일을 직접 수정할 필요가 없습니다.

변경 전 도메인이 <code>from.com</code>, 변경 후 도메인이 <code>to.com</code>이라고 가정합니다.

== 도메인 변경 전 ==

# <code>from.com</code>으로 접속하여 관리자 화면에서 "시스템 설정" 메뉴에 들어갑니다.
# "새 도메인 추가"를 클릭하고, <code>to.com</code>을 추가합니다. 모든 설정은 <code>from.com</code>과 동일하게 합니다.
# "시스템 설정" 화면으로 돌아와서 "등록되지 않은 도메인 처리" 옵션을 "메인 화면 표시"로 변경한 후 저장합니다. 원래 설정이 "메인 화면 표시"였다면 변경하지 않아도 됩니다.

== 도메인 변경 후 ==

# <code>to.com</code>으로 접속하여 관리자 화면에서 "시스템 설정" 메뉴에 들어갑니다.
# <code>to.com</code> 수정 화면으로 들어가서 "기본 도메인"을 선택한 후 저장합니다.
# <code>from.com</code>을 삭제합니다.
# "시스템 설정" 화면으로 돌아와서 "등록되지 않은 도메인 처리" 옵션을 원래대로 돌려놓습니다. 원래 설정이 "메인 화면 표시"였다면 변경하지 않아도 됩니다.

== 도메인 변경 전에 설정을 변경하지 못한 경우 ==

도메인 변경 전에 설정을 미리 바꿔 놓지 않으면 기존 도메인으로 계속 리다이렉트될 수 있습니다. 이 때는 DB에서 아래와 같은 쿼리를 실행하시기 바랍니다.

<syntaxhighlight lang="sql">
UPDATE rx_domains SET domain = 'to.com' WHERE domain = 'from.com';
</syntaxhighlight>

사용하시는 테이블 접두사(<code>rx_</code>)에 따라 적절히 응용하십시오.

쿼리 실행 후에는 <code>설치폴더/files/cache</code> 폴더의 모든 하위 폴더를 삭제하여 기존 도메인 정보가 캐시에 남지 않도록 해야 합니다.

== 설정 파일 ==

라이믹스는 XE 1.x와 달리 도메인 변경시 <code>db.config.php</code> 또는 <code>config.php</code> 파일에서 "기본 URL"을 직접 수정할 필요가 없고, 수정하더라도 의미가 없습니다.

기본 URL이라는 개념 자체를 사용하지 않습니다. 설정 파일에 남아 있는 URL은 XE 1.x 방식에 의존하는 일부 자료를 위한 호환성을 위한 것이며, 코어에서 참조하지 않습니다.

단, "등록되지 않은 도메인 처리" 옵션이 잘못되어 기존 도메인으로 계속 리다이렉트되는 경우 <code>files/config/config.php</code>에서 <code>unregistered_domain_action</code> 설정을 <code>display</code>로 바꾸어 주면 도움이 될 수 있습니다.

{{퍼온문서||||https://rhymix.org/manual/introduction/domain-change 라이믹스 메뉴얼 - 도메인 변경 문서(CC BY-SA 4.0)}}

[[분류:라이믹스]] [[분류:라이믹스/매뉴얼]]

페이팔 홀딩스 주식회사

2026-06-21T05:39:45Z

Gaon12: 문서 넘기기

#REDIRECT[[PayPal]]

PayPal

2026-06-21T05:38:57Z

Gaon12: 문서 내용 보강

[[파일:PayPal San Jose Headquarters.jpg|섬네일|300px|미국 캘리포니아주 산호세에 위치한 페이팔 본사]]

'''페이팔''' 혹은 '''페이팔 홀딩스 주식회사'''(영어: PayPal Holdings, Inc., [[나스닥]]: PYPL)는 미국 캘리포니아주 [[산호세]]에 본사를 둔 세계 최대의 온라인 결제 기업이다. 1998년 12월 [[맥스 레브친]], [[피터 틸]], [[루크 노섹]] 등이 설립한 보안 소프트웨어 회사 콘피니티(Confinity)에서 출발했으며, 2000년 [[일론 머스크]]가 설립한 온라인 금융 서비스 회사 엑스닷컴(X.com)과 합병하여 '페이팔'이라는 사명으로 재탄생했다. 2002년 [[이베이]]에 인수되어 자회사로 운영되다가, 2015년 다시 독립 법인으로 분사하여 나스닥에 상장되었다. 전 세계 약 200개 시장에서 4억 3,900만 개(2025년 말 기준)의 활성 계정을 보유하고 있으며, [[벤모]](Venmo), [[브레인트리]](Braintree), 줌(Xoom) 등 다수의 핀테크 브랜드를 자회사로 두고 있다.

== 개요 ==
{| class="wikitable" style="float:right; width:360px; font-size:90%; margin-left:15px;"
! colspan="2" style="background:#003087; color:white; text-align:center;" | 페이팔 홀딩스 주식회사<br>PayPal Holdings, Inc.
|-
! style="width:110px;" | 형태
| 공개회사([[나스닥]]: PYPL, [[S&P 500]] 구성종목)
|-
! 산업
| 핀테크 · 전자결제 · 디지털 지갑
|-
! 설립
| 1998년 12월 (전신 콘피니티)<br>2000년 3월 (엑스닷컴과 합병, 페이팔 출범)<br>2015년 7월 20일 (이베이로부터 분사, 현 법인 출범)
|-
! 창립자
| 맥스 레브친 · 피터 틸 · 루크 노섹 · 켄 하워리 · 유 판<br>(엑스닷컴 측: 일론 머스크 외)
|-
! 본사
| 미국 캘리포니아주 산호세
|-
! 사업 지역
| 전 세계 약 200개 시장
|-
! 대표이사 회장
| 데이비드 W. 도먼(David W. Dorman, 이사회 의장)
|-
! 대표이사 사장 겸 CEO
| 엔리케 로레스(Enrique Lores)<sup>(2026년 3월~)</sup>
|-
! 매출액
| 332억 7,200만 달러(2025 회계연도)
|-
! 영업이익
| 60억 6,500만 달러(2025 회계연도)
|-
! 순이익
| 52억 3,300만 달러(2025 회계연도)
|-
! 자산총액
| 801억 7,300만 달러(2025년 말)
|-
! 시가총액
| 약 407억 달러(2026년 6월 기준)
|-
! 직원 수
| 약 23,800명(2025년 말 기준)
|-
! 주요 자회사·브랜드
| 벤모, 브레인트리, 줌, 허니, 하이퍼월렛, 페이디, 아이제틀
|-
! 모기업
| 이베이(1998~2015, 현재는 무관)
|-
! 웹사이트
| [https://www.paypal.com www.paypal.com]
|}

페이팔은 흔히 '''핀테크의 원조''' 격으로 평가받는 기업으로, 이메일 주소만으로 개인 간 송금이 가능한 서비스를 일찍이 정착시키며 전자상거래 결제 시장의 표준을 만든 회사로 꼽힌다. 설립 초기 인력 다수가 이후 실리콘밸리의 주요 인물로 성장하여 이른바 '''[[페이팔 마피아]]'''(PayPal Mafia)라는 별칭으로 불리기도 한다. 2025년 기준 연간 결제 처리액(TPV, Total Payment Volume)은 1조 7,940억 달러에 달하며, 이는 전년 대비 7% 증가한 수치다.

== 역사 ==

=== 콘피니티와 엑스닷컴, 그리고 합병 (1998~2000) ===
페이팔의 시초는 1998년 12월 실리콘밸리에서 [[맥스 레브친]], [[피터 틸]], [[루크 노섹]]이 '필드링크'(Fieldlink)라는 이름으로 설립한 회사다. 이 회사는 곧 '''콘피니티'''(Confinity)로 사명을 바꾸고, 처음에는 PDA(개인 휴대 정보 단말기)인 팜파일럿(PalmPilot)용 암호화·보안 소프트웨어를 개발했다. 그러나 사업성이 낮다고 판단한 콘피니티는 이메일을 이용한 개인 간 송금 서비스로 사업 방향을 전환했고, 1999년 '페이팔'이라는 이름의 서비스를 정식으로 출시했다.

한편 이와는 별개로, [[일론 머스크]]는 1999년 3월 온라인 뱅킹을 표방한 회사 '''엑스닷컴'''(X.com)을 설립했다. 한국어 위키 문서를 비롯한 여러 매체에서 일론 머스크가 1998년 콘피니티(또는 '페이팔')의 공동 창립자였다고 서술하는 경우가 있으나, 이는 사실과 다소 차이가 있다. 머스크가 세운 회사는 콘피니티와는 별도의 법인인 엑스닷컴이었으며, 두 회사는 한때 같은 건물에서 사무실을 공유하며 이메일 결제 시장의 주도권을 놓고 치열하게 경쟁하던 '''경쟁사''' 관계였다.<ref>Confinity - Wikipedia, "Confinity merged with X.com, founded by Elon Musk, in March 2000."</ref> 두 회사의 신규 가입자 유치 경쟁이 격화되자, 2000년 3월 양사는 이른바 '적과의 동침'으로 불리는 동수(50대 50) 합병을 단행했다. 합병 직후 회사명은 한동안 '엑스닷컴'으로 유지되었으며, 머스크가 합병 법인의 CEO를 맡았다.

=== 페이팔로의 전환과 이베이 인수 (2000~2002) ===
합병 이후 회사 내부에서는 향후 사업 방향을 두고 갈등이 빚어졌다. 머스크는 종합 온라인 금융 서비스를, 콘피니티 출신 경영진은 이미 성공적으로 자리 잡은 '페이팔' 송금 서비스에 집중할 것을 주장했다. 결국 2000년 9월~10월 무렵 이사회는 머스크를 CEO직에서 물러나게 하고 피터 틸을 새 CEO로 선임했으며, 회사는 은행업 진출을 포기하고 페이팔 서비스에 전사적 역량을 집중하기로 결정했다. 이러한 전략 전환에 따라 2001년 회사명은 정식으로 '페이팔'로 변경되었다.

[[이베이]] 경매 사이트의 판매자와 구매자들은 종전까지 개인수표나 우편환 등으로 대금을 정산해야 했는데, 이메일과 비밀번호만으로 간편하고 신속하게 결제·송금할 수 있는 페이팔의 편의성이 입소문을 타면서 이베이 이용자 사이에서 빠르게 표준 결제 수단으로 자리 잡았다. 페이팔은 2002년 2월 나스닥에 상장했으나, 같은 해 10월 [[이베이]]가 약 15억 달러 규모의 주식 교환 방식으로 페이팔을 인수하면서 상장 8개월 만에 이베이의 완전자회사가 되었다.

=== 이베이 자회사 시절 (2002~2015) ===
이베이 산하에서 페이팔은 이베이 외부 가맹점으로 결제망을 빠르게 확장했다. 이 시기 [[벤모]](2013년 자회사 브레인트리를 통해 흡수), [[브레인트리]](2013년 인수), 국제송금 서비스 줌(Xoom, 2015년 인수 발표) 등 훗날 핵심 사업으로 성장하는 브랜드들을 잇따라 인수했다. 그러나 이베이 내부 사업부로 머물면서 독자적인 자본 배분과 신속한 의사결정에 제약이 있다는 지적이 행동주의 투자자들(칼 아이칸 등)을 중심으로 제기되었다.

=== 이베이로부터의 분사 (2015) ===
결국 이베이 이사회는 2014년 9월 페이팔을 별도 독립 상장기업으로 분사하기로 결정했고, 2015년 7월 20일 '''페이팔 홀딩스 주식회사'''로서 나스닥에 재상장되며 이베이로부터 완전히 분리되었다.<ref>PayPal Holdings, Inc. 8-K, "PayPal Celebrates Listing on Nasdaq and Completes Separation from eBay Inc.", 2015년 7월 20일.</ref> 분사 당시 CEO는 [[댄 슐먼]](Dan Schulman)이었으며, 분사 시점 활성 계정 수는 약 1억 6,200만 개였다.

=== 댄 슐먼 체제와 사업 확장 (2015~2023) ===
독립 법인 출범 이후 페이팔은 [[벤모]]의 송금·결제 기능 고도화, 모바일 간편결제, 가상자산(암호화폐) 매매 서비스(2020년 도입) 등으로 사업을 다각화했다. 2019년에는 쇼핑 쿠폰·캐시백 플랫폼 '''허니'''(Honey)를, 2020년에는 결제 데이터 분석 기업 '''하이퍼월렛'''을, 2021년에는 일본의 후불결제(BNPL) 기업 '''페이디'''(Paidy)와 스웨덴의 매장용 결제 단말기 업체 '''아이제틀'''(iZettle)을 인수했다. 코로나19 확산기 전자상거래 호황에 힘입어 주가가 급등했으나, 2021년 하반기 이후 경쟁 심화(애플페이, 빅테크 결제 서비스 등)와 거시경제 둔화로 주가가 큰 폭으로 조정받았다. 슐먼은 2023년 9월 CEO직에서 물러났다.

=== 알렉스 크리스 체제 (2023~2026) ===
2023년 9월, [[인튜이트]](Intuit) 출신의 알렉스 크리스(Alex Chriss)가 신임 대표이사 사장 겸 CEO로 취임했다. 크리스는 취임 후 '가격 대비 가치' 전략, 벤모의 본격적인 수익화, 후불결제(BNPL) 사업 확대, 통합 가맹점 플랫폼 '''페이팔 오픈'''(PayPal Open) 출범(2025년 2월), 간편 결제 솔루션 '''패스트레인'''(Fastlane)의 국제 확장, 광고 사업(PayPal Ads) 신설 등을 추진했다. 또한 2023년 8월에는 미국 달러 연동 스테이블코인 '''PYUSD'''를 출시해 결제 업계 최초로 대형 결제사가 자체 스테이블코인을 발행한 사례로 주목받았으며, 2025년에는 [[OpenAI]], 구글, 퍼플렉시티 등과 손잡고 인공지능 에이전트가 직접 결제를 수행하는 이른바 '''에이전틱 커머스'''(Agentic Commerce) 인프라 구축에 나섰다.

그러나 2024~2025년 사이 핵심 사업인 브랜드 체크아웃(소비자가 직접 페이팔 로고를 눌러 결제하는 방식) 부문의 성장 둔화가 계속되자 이사회의 실적 압박이 커졌다. 결국 2026년 2월 2일 이사회는 알렉스 크리스를 CEO직에서 전격 교체하기로 결정했다고 공시했으며, 크리스는 같은 날 이사직에서도 물러났다.<ref>PayPal Holdings, Inc. 8-K(2026년 2월 3일), "PayPal Appoints Enrique Lores as Chief Executive Officer and David W. Dorman as Independent Board Chair."</ref>

=== 엔리케 로레스 체제 출범 (2026~ ) ===
크리스의 사임에 따라 최고재무·운영책임자(CFOO)였던 제이미 밀러(Jamie Miller)가 임시 CEO를 맡았고, 이사회는 2019년부터 페이팔 이사회 멤버로 활동했고 2024년 7월부터는 이사회 의장을 지낸 [[HP]]의 전 CEO '''엔리케 로레스'''(Enrique Lores)를 신임 대표이사 사장 겸 CEO로 선임했다. 로레스는 2026년 3월 1일부로 정식 취임했으며, 이사회 의장직은 데이비드 W. 도먼(David W. Dorman)이 새로 맡았다. 로레스는 HP에서 30년간 근무하며 6년간 최고경영자를 역임한 경력을 갖고 있다.

체제 전환과 함께 페이팔은 조직 개편도 단행했다. 브레인트리, 중소상공인(SMB) 결제처리, 부가가치서비스(OVAS), 가상자산(PYUSD 포함) 사업을 하나로 통합한 '''결제서비스·크립토 사업부'''(Payment Services & Crypto Division)를 신설했으며, 이 과정에서 소비자 그룹을 이끌던 디에고 스코티(Diego Scotti)와 중소기업·금융서비스 그룹을 이끌던 미셸 길(Michelle Gill) 등 주요 임원들이 회사를 떠났다.<ref>PayPal Holdings, Inc. 8-K(2026년 6월), 조직 개편 발표 자료.</ref>

== 사업 영역 및 주요 서비스 ==

=== 페이팔(브랜드 체크아웃) ===
이메일이나 휴대전화 번호로 가입한 계정을 통해 온라인 쇼핑몰에서 신용카드·은행 계좌 정보를 매번 입력하지 않고도 결제할 수 있는 디지털 지갑 서비스다. 개인 간 송금(P2P), 환전, 청구서 결제 등의 부가 기능도 제공한다.

=== 벤모(Venmo) ===
미국 내 젊은 세대를 중심으로 널리 쓰이는 모바일 기반 개인 간 송금 서비스로, 소셜 피드 형태로 송금 내역을 공유하는 독특한 UX가 특징이다. 2024~2025년 사이 벤모 직불카드, 벤모를 통한 가맹점 결제(브랜드 체크아웃) 등으로 수익화가 본격화되었다.

=== 브레인트리(Braintree) ===
2013년 인수한 가맹점용 결제 게이트웨이·API 서비스로, [[우버]], [[에어비앤비]] 등 대형 플랫폼 기업들이 사용하는 백엔드 결제 인프라다. 2026년 조직 개편으로 신설된 '결제서비스·크립토 사업부'에 편입되었다.

=== 줌(Xoom) ===
국경 간 송금(해외 송금) 전문 서비스로, 가족 송금이나 해외 거주자의 본국 송금 수요를 겨냥한다.

=== 기타 인수 브랜드 ===
* '''허니(Honey)''': 온라인 쇼핑 시 자동으로 할인 쿠폰을 적용해 주는 브라우저 확장 프로그램(2019년 인수).
* '''하이퍼월렛(Hyperwallet)''': 플랫폼 기업이 다수의 판매자·프리랜서에게 대금을 정산해 주는 대량 지급 솔루션(2018년 인수).
* '''페이디(Paidy)''': 일본 시장의 후불결제(BNPL) 서비스(2021년 인수).
* '''아이제틀(iZettle/Zettle)''': 유럽 중심의 오프라인 매장용 카드 단말기·POS 솔루션(2018년 인수).

=== PYUSD와 에이전틱 커머스 ===
2023년 8월 출시된 PYUSD는 미국 달러에 1:1로 연동되는 스테이블코인으로, 발행은 [[팍소스]](Paxos)가 담당한다. 2025년 한 해 동안 유통량이 약 600% 증가했으며, AI 에이전트가 사람을 대신해 자동으로 결제를 수행하는 '에이전틱 커머스' 인프라의 정산 수단으로도 활용되고 있다. 페이팔은 자사 결제 API를 거대언어모델(LLM)이 직접 호출할 수 있도록 개방하고, [[OpenAI]] 등이 주도하는 '에이전틱 커머스 프로토콜'(Agentic Commerce Protocol, ACP) 표준화 작업에도 참여하고 있다.

=== 후불결제(BNPL) ===
'나중에 결제하기'(Pay in 4) 등 분할 후불결제 상품을 운영하며, 유럽 시장에서는 자체 신용을 활용한 BNPL 채권을 KKR 등 기관투자자에게 매각하는 자금조달 구조를 갖추고 있다.

== 지배구조 ==

=== 역대 최고경영자 ===
{| class="wikitable" style="text-align:center;"
! 대수 !! 이름 !! 재임 기간 !! 비고
|-
| 1 || 피터 틸(Peter Thiel) || 2000년~2002년 || 엑스닷컴-콘피니티 합병 직후 CEO 취임, 사명을 '페이팔'로 변경
|-
| 2 || (이베이 자회사 시기 다수 임원진 거쳐감) || 2002년~2015년 || 이베이 사업부장 체제
|-
| 3 || 댄 슐먼(Dan Schulman) || 2015년~2023년 9월 || 이베이 분사 후 초대 독립법인 CEO
|-
| 4 || 알렉스 크리스(Alex Chriss) || 2023년 9월~2026년 2월 || 인튜이트 출신, 벤모 수익화·PYUSD 출시 주도
|-
| - || 제이미 밀러(Jamie Miller) || 2026년 2월~2026년 3월 || 임시 CEO(CFOO 겸직)
|-
| 5 || 엔리케 로레스(Enrique Lores) || 2026년 3월~현재 || 전 HP 회장 겸 CEO, 페이팔 이사회 출신
|}

=== 이사회 ===
2026년 기준 이사회 의장은 데이비드 W. 도먼(David W. Dorman)이 맡고 있다.

== 재무 현황 ==
{| class="wikitable" style="text-align:right;"
! style="text-align:center;" | 회계연도 !! 순매출 !! 영업이익 !! 순이익 !! 결제처리액(TPV) !! 활성 계정 수
|-
| 2023 || - || - || - || - || 4억 2,650만 개
|-
| 2024 || 317억 9,700만 달러 || 53억 2,500만 달러 || 41억 4,700만 달러 || 1조 6,812억 달러 || 4억 3,400만 개
|-
| 2025 || 331억 7,200만 달러 || 60억 6,500만 달러 || 52억 3,300만 달러 || 1조 7,940억 달러 || 4억 3,900만 개
|}
<ref>PayPal Holdings, Inc. 8-K(2026년 2월 3일), "PayPal Reports Fourth Quarter and Full Year 2025 Results".</ref>

2025년 4분기 실적 발표 시점(2026년 2월) 회사는 2026년 비일반회계기준(Non-GAAP) 주당순이익이 전년 대비 보합 내지 소폭 감소할 것으로 전망했으며, 이는 금리 하락에 따른 고객예치금 이자 수익 감소와 소비자 경험 개선을 위한 투자 확대가 반영된 수치다. 2025년 11월에는 비일반회계기준 순이익의 10%를 목표 배당성향으로 하는 분기 배당(주당 0.14달러)을 처음으로 도입했다. 한편 주가는 2021년 7월 고점(주당 약 310달러) 대비 2026년 중반 기준 큰 폭으로 하락한 상태이며, 시가총액은 약 407억 달러 수준이다(2026년 6월 기준).<ref>MacroTrends, "PayPal Holdings Market Cap 2013-2026".</ref>

== 페이팔 마피아(PayPal Mafia) ==
초창기 콘피니티·엑스닷컴·페이팔에서 함께 일했던 임직원 중 다수가 이후 독립하여 실리콘밸리의 주요 빅테크·벤처캐피털 창업자 또는 핵심 인물로 성장했고, 언론은 이들을 '''페이팔 마피아'''라는 별칭으로 부른다. 대표적인 인물은 다음과 같다.

* [[일론 머스크]] - 엑스닷컴 창립자. 이후 [[테슬라]], [[스페이스X]], [[xAI]] 등 창업
* [[피터 틸]] - 콘피니티 공동창립자, 페이팔 초대 CEO. 이후 [[팰런티어 테크놀로지스]] 공동창업, [[페이스북]] 초기 투자자
* [[맥스 레브친]] - 콘피니티 공동창립자, 페이팔 CTO. 이후 후불결제 기업 [[어펌(기업)|어펌]](Affirm) 창업
* [[리드 호프먼]] - 페이팔 COO 출신. 이후 [[링크드인]] 공동창업
* [[채드 헐리]], [[스티브 첸]], [[자웨드 카림]] - 페이팔 출신 엔지니어들로 이후 [[유튜브]] 공동창업
* [[데이비드 색스]] - 페이팔 COO 출신. 이후 [[야머]](Yammer) 창업, 벤처캐피털리스트로 활동
* [[키스 라보이스]] - 벤처캐피털리스트, [[오픈도어]] 등 다수 스타트업 투자
* [[로엘로프 보타]] - 페이팔 CFO 출신. 이후 [[세쿼이아 캐피털]] 대표 역임

== 비판과 논란 ==

=== 계정 동결 관련 논란 ===
페이팔은 의심거래 탐지 알고리즘에 따라 사전 통보 없이 이용자 계정의 자금을 장기간 동결하는 경우가 잦다는 비판을 꾸준히 받아왔다. 2010년에는 위키리크스에 대한 기부금 결제를 차단해 논란이 되었고, 이에 반발한 해커 집단 어나니머스가 페이팔 등을 상대로 디도스 공격을 벌인 '오퍼레이션 페이백' 사건으로 이어지기도 했다. 2022년 캐나다 '자유 호송대'(Freedom Convoy) 시위 관련 모금 계좌를 동결한 사례 역시 결제 플랫폼의 자금 차단 권한을 둘러싼 논쟁을 촉발했다.

=== 표현의 자유·정책 관련 논란(2022년 AUP 사태) ===
2022년 10월 페이팔은 허위정보 유포 등으로 판단되는 행위를 한 계정에 최대 2,500달러의 벌금을 부과할 수 있다는 내용을 포함한 '이용자 행위 정책'(Acceptable Use Policy) 개정안을 발표했다. 전 페이팔 임원 데이비드 마커스를 비롯해 일론 머스크 등 다수 인사가 강하게 비판하자, 페이팔은 해당 조항이 '오류로 게시되었다'며 며칠 만에 철회했다.<ref>PayPal - Wikipedia, "In October 2022, PayPal published an update to its Acceptable Use Policy..."</ref>

=== 보안·사기 문제 ===
대형 결제 플랫폼이라는 특성상 피싱, 계정 탈취, 가짜 송장을 이용한 사기 등 각종 금융 사기의 표적이 되는 경우가 많아 정기적으로 보안 관련 논란이 제기된다.

== 같이 보기 ==
* [[이베이]]
* [[벤모]]
* [[브레인트리]]
* [[일론 머스크]]
* [[피터 틸]]
* [[핀테크]]
* [[스테이블코인]]

== 각주 ==
<references/>

== 외부 링크 ==
* {{공식 웹사이트|https://www.paypal.com}}
* [https://investor.pypl.com 페이팔 투자자 관계(IR) 페이지]
* [https://newsroom.paypal-corp.com 페이팔 뉴스룸]

[[분류:1998년 설립된 기업]]
[[분류:미국의 핀테크 기업]]
[[분류:나스닥 상장기업]]
[[분류:캘리포니아주의 기업]]
[[분류:산호세(캘리포니아주)의 기업]]
[[분류:전자결제]]
[[분류:이베이]]

노자와 마사코

2026-06-19T01:58:40Z

Gaon12: 문서 내용 보강

== 성우 ==
{{인물 정보
|성별 = 여
|이름 = 노자와 마사코
|이름/일어 = 野沢雅子
|이름/요미카타 = のざわまさこ
|이름/영어 = Masako Nozawa
|본명 = 츠카다 마사코
|본명/일어 = 塚田雅子
|본명/영어 = Masako Tsukada
|직업 = [[성우]], [[배우]], [[가수]]
|소속사 = [[아오니 프로덕션]]
|출생년 = 1936
|출생월 = 10
|출생일 = 25
|출생국가 = 일본
|출생지1 = 도쿄부
|출생지2 = 도쿄시 아라카와구 닛포리마치
|혈액형 = O
|신장 = 157cm
|발사이즈 =
|별명 = 마코상



|활동시작 = 1950년대
|활동종료 =
|장르 = [[애니메이션]], [[게임]], [[더빙]], [[나레이션]], [[라디오 드라마]]
|데뷔작품 =
|데뷔역 =



|배우활동 = {{활동/배우활동
|활동시작 = 1939년
|활동종료 =
|장르 = [[TV 드라마]], [[영화]], [[무대]]
|소속사 =
|데뷔작품 =
|데뷔역 =
}}
}}

'''노자와 마사코'''(野沢雅子, 본명 츠카다 마사코, 1936년 10월 25일 ~ )는 일본의 [[성우]], [[배우]], [[가수]]이다. [[도쿄부]] 도쿄시 아라카와구 닛포리마치, 현 [[도쿄도]] [[아라카와구]] 닛포리 출신이며, [[아오니 프로덕션]] 소속이다.<ref name="aoni">[https://www.aoni.co.jp/search/nozawa-masako.html 青二プロダクション - 野沢雅子 공식 프로필]</ref> 본명은 츠카다 마사코(塚田雅子)이며, 애칭은 마코상(マコさん). 남편은 성우 겸 배우였던 [[츠카다 마사아키]]로, 2014년에 사별했다.<ref>[https://www.oricon.co.jp/news/2033492/full/ ORICON NEWS - 声優の塚田正昭さん死去…74歳妻は声優・野沢雅子]</ref>

일본 성우사에서 초창기부터 활동한 인물 중 하나이며, 특히 '''소년 연기'''를 대표하는 성우로 손꼽힌다. 대표 배역으로는 《[[게게게의 키타로]]》의 [[키타로]]와 제6기의 [[눈알 아버지]], 《[[은하철도 999]]》의 [[호시노 테츠로]], 《[[드래곤볼]]》 시리즈의 [[손오공]], [[손오반]], [[손오천]], 《[[초근성 가에루]]》의 히로시, 《[[감바의 모험]]》의 감바, 《[[톰 소여의 모험]]》의 톰 소여, 《[[디지몬 테이머즈]]》의 [[기루몬]] 등이 있다.<ref name="jmaf">[https://j-mediaarts-festival.bunka.go.jp/award/single/nozawa-masako/index.html 文化庁メディア芸術祭 - 野沢雅子]</ref>

== 개요 ==
일본 애니메이션과 더빙 문화의 형성기부터 활동해 온 원로 성우이다. 1930년대 말 아역 배우로 연예 활동을 시작했고, 전후 라디오·무대·드라마·영화·외화 더빙을 거치며 성우 활동을 본격화했다. 이후 일본 TV 애니메이션 초창기부터 소년, 동물, 노인, 요괴, 인간 외 존재까지 폭넓게 연기하며 현재까지 활동을 이어오고 있다.

특히 노자와 마사코 하면 가장 먼저 떠오르는 배역은 《[[드래곤볼]]》 시리즈의 [[손오공]]이다. 1986년 TV 애니메이션 《드래곤볼》에서 손오공을 맡은 이후, 《드래곤볼 Z》, 《드래곤볼 GT》, 《드래곤볼 카이》, 《드래곤볼 슈퍼》, 극장판, 게임, 광고, 이벤트 영상, 그리고 2024년 방영된 《[[드래곤볼 DAIMA]]》에 이르기까지 장기간 동일 캐릭터를 맡았다.<ref>[https://dragonballdaima.com/character.html ドラゴンボールDAIMA 공식 사이트 - 캐릭터]</ref>

손오공뿐 아니라 손오공의 아들인 [[손오반]]과 [[손오천]], 손오공의 아버지 [[버독]], 손오공과 닮은 [[터레스]], [[오공 블랙]] 등 이른바 손씨 일가 및 관련 캐릭터 다수를 한 사람이 연기한다는 점으로도 유명하다. 같은 작품 안에서 성격과 연령대가 다른 여러 캐릭터를 동시에 맡으면서도 각각의 톤과 호흡을 구분하는 연기로 평가받는다.

== 특징 ==
=== 소년 연기의 대명사 ===
노자와 마사코의 가장 큰 특징은 소년 캐릭터 연기이다. 성인 여성 성우가 소년 캐릭터를 맡는 방식은 일본 애니메이션에서 일반적이지만, 그 흐름을 대중적으로 각인시킨 대표 인물 중 한 명으로 평가된다. 맑고 높은 음색에 강한 발성, 빠른 감정 전환, 과장된 만화적 표현과 자연스러운 생활 연기를 동시에 구사하는 것이 특징이다.

《[[게게게의 키타로]]》의 키타로, 《[[은하철도 999]]》의 호시노 테츠로, 《[[초근성 가에루]]》의 히로시, 《[[드래곤볼]]》의 손오공, 《[[디지몬 테이머즈]]》의 기루몬은 모두 소년 또는 소년성을 지닌 캐릭터이지만, 실제 연기 방향은 서로 다르다. 키타로는 차분하고 신비로운 분위기, 테츠로는 성장하는 소년의 절박함, 히로시는 장난스럽고 활달한 생활감, 손오공은 천진난만함과 전투광적 에너지, 기루몬은 동물적 순수함이 강조된다.

=== 《드래곤볼》 시리즈에서의 존재감 ===
노자와 마사코는 《드래곤볼》 시리즈에서 단순히 한 배역을 오래 맡은 수준을 넘어, 작품의 일본어 음성 정체성을 상징하는 인물에 가깝다. 손오공의 어린 시절부터 성인기, 부성, 전사로서의 광기, 순진함, 분노, 비장함을 모두 한 목소리 안에서 구축했다.

또한 같은 작품에서 손오공, 손오반, 손오천을 동시에 연기하는 것으로 유명하다. 손오공은 본능적이고 직선적인 활기, 손오반은 지적이고 내성적인 면, 손오천은 더 어린아이 같은 천진함을 중심으로 구분된다. 이 때문에 《드래곤볼》 팬덤에서는 노자와 마사코의 연기를 작품 자체와 분리해서 생각하기 어렵다는 평가가 많다.

=== 장기 활동과 상징성 ===
노자와 마사코는 일본 TV 애니메이션의 초창기부터 현재까지 이어지는 거의 전 세대를 관통하는 성우이다. 1960년대의 《[[철완 아톰]]》, 《[[게게게의 키타로]]》부터 1970년대의 《[[은하철도 999]]》, 1980년대의 《[[드래곤볼]]》, 2000년대의 《[[ONE PIECE]]》와 《[[디지몬 테이머즈]]》, 2010년대의 《[[드래곤볼 슈퍼]]》와 《게게게의 키타로》 제6기, 2020년대의 《[[드래곤볼 DAIMA]]》까지 이어진다.

2025년에는 일본 정부의 [[문화공로자]]로 선정되었다. 문부과학성의 2025년도 문화공로자 명단에는 본명 츠카다 마사코, 예명 노자와 마사코, 분야 성우로 기재되어 있다.<ref>[https://www.mext.go.jp/b_menu/houdou/2025/attach/1422025_00002.htm 文部科学省 - 令和7年度文化功労者]</ref> 성우라는 직업의 사회적 위상을 보여 주는 사례로도 자주 언급된다.

== 경력 ==
=== 아역 배우 시절 ===
어린 시절부터 아역 배우로 활동했다. 배우 활동은 1939년부터로 알려져 있으며, 무대와 영화, TV 드라마 등 실연 계열의 연기 경력을 먼저 쌓았다. 이후 외화 더빙과 라디오 드라마, 애니메이션 음성 연기를 거치며 성우 활동이 중심이 되었다.

=== 성우 활동의 본격화 ===
1960년대 일본 TV 애니메이션이 본격적으로 제작되기 시작하면서 여러 작품에 출연했다. 1963년 《[[철완 아톰]]》, 《늑대소년 켄》 등을 시작으로, 1968년 《[[게게게의 키타로]]》 제1기에서 키타로를 맡으며 대표적인 소년 주인공 성우로 자리매김했다.

1969년 설립된 [[아오니 프로덕션]]의 창설기와도 관련이 깊은 인물로 알려져 있으며, 현재도 아오니 프로덕션 소속으로 활동하고 있다.<ref name="jmaf" />

=== 1970년대와 1980년대 ===
1970년대에는 《[[초근성 가에루]]》의 히로시, 《[[감바의 모험]]》의 감바, 《[[은하철도 999]]》의 호시노 테츠로 등 주연급 캐릭터를 다수 맡았다. 이 시기 출연작들은 일본 애니메이션의 고전으로 꼽히는 작품이 많아, 노자와 마사코의 목소리는 여러 세대에게 익숙한 목소리가 되었다.

1980년대에는 《[[괴물군]]》의 괴물 타로, 《[[톰 소여의 모험]]》의 톰 소여, 《[[츠리키치 산페이]]》의 산페이, 그리고 1986년 《[[드래곤볼]]》의 손오공을 맡으며 대표 커리어가 확정되었다.

=== 《드래곤볼》 이후 ===
1986년부터 시작된 《드래곤볼》 시리즈는 노자와 마사코의 경력에서 가장 큰 비중을 차지하는 작품이다. 《드래곤볼 Z》에서는 손오공뿐 아니라 손오반, 버독, 손오천, 오천크스, 베지트 등 여러 캐릭터를 연기했고, 이후 《드래곤볼 GT》, 《드래곤볼 카이》, 《드래곤볼 슈퍼》, 《드래곤볼 DAIMA》까지 장기간 참여했다.

2017년에는 《드래곤볼》 게임 시리즈에서 손오공을 장기간 연기한 공로로 기네스 세계 기록 2개 부문에 인정되었다. 당시 기록은 하나의 비디오 게임 캐릭터를 가장 오랫동안 연기한 성우, 그리고 비디오 게임 성우로서 가장 오래 활동한 기간과 관련된 기록이었다.<ref>[https://www.guinnessworldrecords.jp/news/features/masako-nozawa-interview ギネス世界記録 - 特別インタビュー：野沢雅子]</ref><ref>[https://blog.ja.playstation.com/2017/02/01/20170201-dragonball/ PlayStation.Blog - 野沢雅子さんがギネス世界記録に認定]</ref>

=== 2020년대 이후 ===
2020년대에도 활발한 활동을 이어가고 있다. 《[[디지몬 어드벤처:]]》에서는 내레이션과 유키미보타몬을 맡았고, 《[[드래곤볼 DAIMA]]》에서는 손오공, 손오공 미니, 손오반, 손오천 등을 다시 연기했다. 2024년에는 아오니 프로덕션과 CoeFont의 AI 음성 프로젝트에 참여한 성우 중 한 명으로 발표되었다. 해당 프로젝트는 음성 비서, 로봇, 의료기기 등 비연기 영역의 다국어 AI 음성 제공을 목표로 하며, 애니메이션이나 더빙 같은 연기 영역에는 제공하지 않는다고 설명되었다.<ref>[https://prtimes.jp/main/html/rd/p/000000089.000078329.html PR TIMES - 青二プロダクションとCoeFont、AIを活用したグローバル戦略パートナーシップを締結]</ref>

2025년에는 문화공로자로 선정되며 성우계의 상징적 인물로 다시 주목받았다.<ref name="mext">[https://www.mext.go.jp/b_menu/activity/detail/2025/20251104_2.html 文部科学省 - 令和7年度文化功労者顕彰式]</ref>

== 대표 배역 ==
{| class="wikitable"
! 작품 !! 배역 !! 비고
|-
| [[게게게의 키타로]] || '''[[키타로]]''' || 제1기·제2기에서 키타로 역
|-
| [[게게게의 키타로]] 제6기 || [[눈알 아버지]] || 과거 키타로 역 성우가 아버지 역을 맡은 사례
|-
| [[은하철도 999]] || '''[[호시노 테츠로]]''' || 대표적인 소년 주인공 배역
|-
| [[드래곤볼]] 시리즈 || '''[[손오공]]''', '''[[손오반]]''', '''[[손오천]]''' 등 || 대표 배역. 손씨 일가와 관련 캐릭터 다수 담당
|-
| [[초근성 가에루]] || '''히로시''' || 1970년대 대표 주연 배역
|-
| [[감바의 모험]] || '''감바''' || 모험물 주인공
|-
| [[괴물군]] || '''괴물 타로''' || TV 아사히판
|-
| [[톰 소여의 모험]] || '''톰 소여''' || 세계명작극장 계열 대표 배역
|-
| [[디지몬 테이머즈]] || '''[[기루몬]]''', '''[[그라우몬]]''', '''[[메갈로그라우몬]]''', '''[[듀크몬]]''', 내레이션 || 디지몬 시리즈 대표 배역
|-
| [[ONE PIECE]] || Dr. 쿠레하 || 장수 애니메이션 출연 배역
|-
| [[도라에몽]] || '''도라에몽''' || 1973년판 제2대 도라에몽
|-
| [[아라이구마 라스칼]] || '''라스칼''' || 동물 연기 계열 대표 배역
|}

== 주요 수상 및 기록 ==
{| class="wikitable"
! 연도 !! 수상·기록 !! 비고
|-
| 2012년 || 제7회 [[성우 어워드]] 공로상 || 장기 활동과 성우계 공헌 인정
|-
| 2017년 || [[기네스 세계 기록]] 2개 부문 인정 || 《드래곤볼》 게임 시리즈의 손오공 장기 연기 관련<ref name="guinness">[https://www.guinnessworldrecords.jp/news/features/masako-nozawa-interview ギネス世界記録 - 特別インタビュー：野沢雅子]</ref>
|-
| 2017년 || 제26회 일본 영화 비평가 대상 애니메이션 부문 성우상 || 성우 활동 공로
|-
| 2018년 || 아동복지문화상 특별부문 || 장기간의 성우 활동을 통한 아동문화 기여<ref name="jmaf" />
|-
| 2021년 || 제24회 문화청 미디어예술제 공로상 || 성우 문화 창성기부터의 공헌 인정<ref name="jmaf" />
|-
| 2022년 || 제45회 일본 아카데미상 회장공로상 || 영화계 장기 공헌자 대상 특별상<ref>[https://www.japan-academy-prize.jp/prizes/45.html 第45回日本アカデミー賞 - 受賞結果]</ref>
|-
| 2023년|| 제71회 [[기쿠치 칸상]] || 성우로서 수상<ref>[https://news.mynavi.jp/article/20231011-2790263/ マイナビニュース - 第71回菊池寛賞]</ref>
|-
| 2024년 || 마이니치 예술상 특별상 || 장기 예술 활동 공로
|-
| 2025년 || [[문화공로자]] || 성우 분야 인물로 선정<ref name="mext" />
|}

== 성우로서의 활동 ==
{{안내|

* 같은 연도 안에서는 작품명을 기준으로 정렬했습니다.
* '''굵은 글씨'''는 주연 또는 문서상 대표 배역입니다.
* 장기 시리즈는 첫 출연 연도에 중심으로 적되, 이후 시리즈에서 같은 배역을 계속 맡은 경우 비고로 정리했습니다.
* 단역·게스트 배역은 확인 가능한 주요 사례 위주로 정리했습니다.
}}

=== TV 애니메이션 ===

* '''1963년'''
** [[늑대소년 켄]]
** [[철완 아톰]] / 유미인의 여왕의 아이, 국제전화국 로봇

* '''1965년'''
** [[귀신 Q타로]] / 오오하라 신이치[초대] {{덧|TBS판}}
** 돌핀 왕자 / 시로
** 우주 패트롤 호퍼{{이명|호퍼 우주코 쥰}} / 푸

* '''1966년'''
** [[마법사 사리]]{{이명|요술공주 샐리}} / 하나무라 톤키치, 칸타
** 유성가면 / 사프스 10호

* '''1967년'''
** 모험 가보텐섬 / '''가보'''

* '''1968년'''
** 거인의 별 / 야구 소년, 요네
** [[게게게의 키타로]] / '''[[키타로]]''' 등
** [[마법사 사리]]{{이명|요술공주 샐리}} / 만조
** 사부와 이치 체포조 / 오카미, 오시즈
** 사이보그 009 / 록 {{덧|1968년판}}

* '''1969년'''
** 곤충 이야기 고아 하치 / 분키치 등 {{덧|1969년판}}
** 맹렬 아타로 / 데코, 소년 및 여성 배역 다수
** 비밀의 아코쨩 / 톤코
** 어택 No.1 / 사이, 히가키 료코[2대째], 카와치 키누코
** 타이거 마스크 / 켄타, 소년 및 여성 배역 다수
** 하쿠숀 대마왕 / 스스무
** 해저소년 마린 / 화이티

* '''1970년'''
** 시골뜨기 대장 / '''카제다이 자에몬'''

* '''1971년'''
** [[게게게의 키타로]] 제2기 / '''[[키타로]]'''
** 내일의 죠 / 유리
** 신비한 메루모 / 하야토 등
** 아파치 야구군 / 거리의 아이들, 다이콘의 엄마, 어린 시절의 아바시리
** 천재 바카본 / B조, 불량배, 아이들, 어머니 역 다수

* '''1972년'''
** 떡갈나무 모크{{이명|피노키오의 모험}} / 플랑코
** 마법사 챠피 / 아라이 니헤이
** [[초근성 가에루]] / '''히로시'''

* '''1973년'''
** 과학닌자대 갓챠맨{{이명|독수리 5형제}} / 어린아이
** [[도라에몽]] / '''도라에몽'''[2대째] {{덧|1973년판}}
** 도로롱 엔마군 / '''엔마군'''
** 루팡 2세 / 선생님
** 모험 콜로보클 / 주먹밥
** 미라클 소녀 리미트쨩 / 토미씨
** 미크로이드 S / 미도로 마나부
** 산쥐 로키 척 / 야생쥐 다니
** 신조인간 캐샨 / 킴, 마루
** 완사군 / 코우타, 사부로, 토토
** 카라테 바보 일대 / 어머니, 소년 시절의 아스카 켄, 토시오
** 큐티 하니 / 스코피온 팬서

* '''1974년'''
** 과학닌자대 갓챠맨{{이명|독수리 5형제}} / 나카니시 세이지
** 마법소녀 메구쨩 / 사탄, 챠크
** 별의 아이 아폴론 / '''폴론'''
** 알프스 소녀 하이디 / 오르간을 연주하는 소년, 히엘
** 카리메로 / 부우타, 체시라

* '''1975년'''
** [[감바의 모험]] / '''감바'''
** 겟타 로보 G / 백골귀, 지충귀
** 꿀벌 마야의 모험 / 윌리
** 라 센느의 별 / 단톤
** 원조천재 바카본 / 간호사, 아빠의 엄마, 주부 등

* '''1976년'''
** 대공마룡 가이킹 / 톰
** 무당벌레의 노래 / 카제다이 자에몬
** 엄마 찾아 삼만리 / 루이지
** 초전자 로보 컴배틀러 V / 로펫트, 오레아나, 이치키 켄타 등
** 캔디 캔디 / 맥레거네 집의 아주머니
** 타임보칸 / 도우모스칸
** 폴의 미라클 대모험 / 산디
** 피코리노의 모험 / '''피코리노'''
** 허클베리의 모험 / '''허클베리 핀'''

* '''1977년'''
** 나는 텟페이 / '''우에스기 텟페이'''
** [[아라이구마 라스칼]]{{이명|너구리 라스칼}} / '''라스칼''', 그레타 선더랜드, 쥬디 미첼
** 애로우 엠브렘 그랑프리의 매 / 오우세 한고로, 타카야네 아주머니

* '''1978년'''
** 얏타맨 / 아라란
** [[은하철도 999]] / '''[[호시노 테츠로]]'''
** 잇큐상 / 야스타케
** 투장 다이모스 / 겐타

* '''1979년'''
** 과학닌자대 갓챠맨 F{{이명|독수리 오형제 F}} / 토니
** 루팡 3세 제2기 / 치코
** 베르사이유의 장미 / 음유시인의 아들
** 애니메이션 기행 마르코 폴로의 여행 / 샤오하이, 바디
** 터무니쥐 맹활약 / '''터무니쥐'''

* '''1980년'''
** [[괴물군]] / '''괴물 타로''' {{덧|TV 아사히판}}
** 메텔링크의 파랑새 치루치루 미치루의 모험여행 / 밀크의 요정
** 츠리키치 산페이 / '''산페이'''
** [[톰 소여의 모험]] / '''톰 소여'''
** 폿쨩 / 치비
** 한가한 숲의 동물 대작전 / 페터

* '''1981년'''
** 마잇칭구 마치코 선생님 / 켄타
** 명견 죠리 / 프리트
** 백수왕 고라이온 / 스즈이시 히로시, 노파 호네르바
** 시끌별 녀석들 / 킨타로
** 신 초근성 가에루 / '''히로시'''

* '''1982년'''
** 역전 한방맨 / 킨타로
** 태양의 아들 에스테반 / '''에스테반'''
** 프로골퍼 사루 / '''사루마루''' {{덧|스페셜판}}

* '''1983년'''
** 마법의 천사 크리미 마미 / 타치바나 네에서 일하는 할머니
** 은하표류 바이팜 / 켄츠 노톤, 클레어의 엄마
** 이가노 카바마루 / 마츠노 요시미, 소년 시절의 카바마루
** 이상한 나라의 앨리스 / 베니

* '''1984년'''
** 마법의 요정 페르샤 / 하나타레
** 명탐정 홈즈 / 마이클
** 칫군 탓군 / 엔도레

* '''1985년'''
** 헤이! 붐바 / '''붐바'''

* '''1986년'''
** [[드래곤볼]] / '''[[손오공]]'''
** 사랑소녀 폴리안나 이야기 / 파레 해링턴
** 오즈의 마법사 / 치프, 오즈마 공주

* '''1987년'''
** 가면의 닌자 아카카게 / 아오카게
** 도테라맨 / 소우지오니
** 안미츠 공주 / 우메보마루, 츠쿠네
** 애니메 80일간 세계일주 / 치코
** 울트라 B / 엄마

* '''1988년'''
** 날아라! 호빵맨 / 시츄 아주머니, 카메라 파치리군, 해적 로부스타 등
** 비리켄 / '''비리켄'''
** 싸워라! 라면맨 / 볶음밥

* '''1989년'''
** 곤충 이야기 고아 해치{{이명|곤충의 모험}} / 쿠마고로 등
** 대쉬! 욘쿠로 / '''히노마루 욘쿠로'''
** [[드래곤볼 Z]] / '''[[손오공]]''', '''[[손오반]]'''
** 비리켄 무엇이든 상회 / '''비리켄'''
** 푸른 블링크 / '''시키 카케루'''

* '''1990년'''
** [[드래곤볼 Z]] TV 스페셜 / '''[[버독]]''', 카카로트
** 매지컬☆타루루토군 / 야마비코 타로
** 정글 대제 제3기 / 기보
** 카라쿠리 검호전 무사시 로드 / '''무사시'''

* '''1991년'''
** [[드래곤볼 Z]] / 버독
** 불꽃의 투구아 닷지 단페이{{이명|피구왕 통키}} / '''코보토케 친넨'''
** 유령 홀리 / 마녀할멈, 카쿠조
** 작은 귀신 앗치 콧치 솟치 / 할머니

* '''1992년'''
** 엄지공주 이야기

* '''1993년'''
** [[드래곤볼 Z]] / '''[[손오천]]'''
** 드래곤볼 Z 절망에의 반항!! 남겨진 초전사 오공과 트랭크스 / '''미래 [[손오반]]'''

* '''1994년'''
** [[드래곤볼 Z]] / 오천크스
** 몬타나 존스 / 오렛타, 니콜
** 최근 폰타 / 폰타

* '''1995년'''
** [[드래곤볼 Z]] / 베지트

* '''1996년'''
** [[드래곤볼 GT]] / '''[[손오공]]''', '''[[손오반]]''', '''[[손오천]]''', 손오공 Jr.

* '''1997년'''
** 모쟈코 / 바비

* '''1998년'''
** 돌격! 빠빠라대 / 미즈시마 아키코, 산쵸스, X-하트
** 앨리스 SOS / 악마의 두목
** 요시모토 무치코 이야기 / 무치코 머신
** 은하표류 바이팜 13 / 켄츠 노톤

* '''1999년'''
** 닥터 슬럼프 / 손오공
** 더그 / '''더그'''
** 듀얼! 파라레 룬룬 이야기 / 난죠인 레이카

* '''2000년'''
** 긴다이치 소년의 사건부{{이명|소년탐정 김전일}} / 콘타 토모요
** 러브히나 / 우라시마 히나<ref>원작 만화에서는 우라시마 히나타라는 이름으로 등장했다.</ref>
** 방가방가 햄토리 / 햄스터 할머니, 로코쨩의 할머니

* '''2001년'''
** [[ONE PIECE]] / Dr. 쿠레하
** [[디지몬 테이머즈]] / '''[[기루몬]]''', '''[[그라우몬]]''', '''[[메갈로그라우몬]]''', '''[[듀크몬]]''', 내레이션
** 명탐정 코난 / 센겐 후루요
** 탐정소년 카게만 / 후쿠오

* '''2002년'''
** 록맨 에그제 / 테슬라{{이명|에레키텔 마마}}
** 왕도둑 JING / 마마 스타우트
** 폭투선언 다이간다 / 캐시

* '''2003년'''
** 고집쟁이☆페어리 미르모로 퐁! / 킨타
** 마법사에게 소중한 것 / 에노모토 무츠코
** 아스트로 보이 철완 아톰{{이명|우주소년 아톰}} / 원시인 소년
** 쿄고쿠 나츠히코 항간에 떠도는 100가지 이야기 / 뱌쿠안, 쿠로안

* '''2004년'''
** 두사람은 프리큐어 / 유키시로 사나에
** 마슈마로 통신 / 프람
** 쾌걸 조로리 / 공룡의 엄마
** 탐정학원 Q / 노파

* '''2005년'''
** DIGITAL MONSTER X-evolution / 듀크몬
** 눈의 여왕 / 할머니
** 두사람은 프리큐어 Max Heart / 유키시로 사나에
** 아쿠에와 갓친포 가득 / 크린
** 츠바사 크로니클 ~연대기~ / 괴어
** 포켓몬스터 어드밴스 제너레이션 / 마사무네

* '''2006년'''
** NARUTO -나루토- / 노파
** 결계사 / 하나노코우지 유메코
** 러브겟 CHU ~미라클 성우백서~ / 타케미야 미츠코 선생님
** 록맨 에그제 BEAST+ / 에레키텔 마마
** 성실하게 불성실한 쾌걸 조로리 / 이시시<ref>[[아이카와 리카코]]의 대역.</ref>
** 키라링☆레볼루션 / 키라리의 할머니
** 태엽 사무라이 / 경단집 할머니

* '''2007년'''
** 디지몬 세이버즈 / 듀크몬
** 일하는 키즈 마이햄스터조 / '''가우디'''
** 천보이문 아야카시 아야시 / 히지카타 토시조

* '''2008년'''
** 못케{{이명|샤먼 시스터즈}} / 네코마타
** 묘지의 키타로 / '''키타로'''
** 키쿠쨩과 늑대 / 늑대

* '''2009년'''
** [[드래곤볼 카이]] / '''[[손오공]]''', '''[[손오반]]''', 버독
** 마리&갈리 / 퀴리 부인
** 수호 캐릭터!! 두근 / 마루야마 하루키
** 크로스 게임 / 노모, 아사미 토키에 등

* '''2010년'''
** 꿈빛 파티시엘 / 프랑스 이사장
** 마리&갈리 ver.2.0 / 퀴리 부인

* '''2011년'''
** Dororon 엔마군 메~라메라 / 엔마의 아빠
** 루팡 3세 피의 각인 ~영원의 Mermaid~ / 토우도 쇼코
** 일상 / 예고 내레이션
** 케로로 중사 / 오라라

* '''2012년'''
** 명탐정 코난 / 와카마츠 세리카
** 탐험 드리랜드 / 보니

* '''2013년'''
** Dream 9 토리코 & 원피스 & 드래곤볼 Z 초콜라보 스페셜!! / 손오공, 손오반, 손오천

* '''2014년'''
** [[드래곤볼 카이]] 마인 부우 편 / 손오공, 손오반, 손오천 등

* '''2015년'''
** [[드래곤볼 슈퍼]] / '''손오공''', '''손오반''', '''손오천''', 오공 블랙 등<ref>[https://www.toei-anim.co.jp/tv/dragon_s/chara/ 東映アニメーション - ドラゴンボール超 캐릭터]</ref>
** 그것이 성우! / 본인

* '''2016년'''
** 나스 위치 코무기쨩 R / 튀어나온 괴인
** 간간 간코쨩 / 케로쨩, 가메상

* '''2017년'''
** 신격의 바하무트 VIRGIN SOUL / 용족 족장

* '''2018년'''
** 오버로드 II / 리그리트 베르스 카우라우
** [[게게게의 키타로]] 제6기 / [[눈알 아버지]]<ref>[https://www.toei-anim.co.jp/kitaro/season6/about/ 東映アニメーション - ゲゲゲの鬼太郎第6期 작품 소개]</ref>
** 호오즈키의 냉철 / 매지컬 마린
** 심야! 천재 바카본 / 노자와 마사코
** 사신짱 드롭킥 / 아서 버시벌
** 중간관리록 토네가와 / 자와 보이스

* '''2019년'''
** 듀얼 마스터즈! / 코피죠

* '''2020년'''
** 아사티르 미래의 옛날이야기 / 아스마
** [[디지몬 어드벤처:]] / 내레이션, 유키미보타몬
** 짱구는 못말려 / 진노스케

* '''2021년'''
** 노리모노맨 모빌랜드의 카쿤 / 엘리자베스

* '''2022년'''
** 더! 성실하게 불성실한 쾌걸 조로리 / 공룡 마마
** 5억 년 버튼 / 토니오, 라

* '''2023년'''
** 희망의 힘 ~어른 프리큐어 '23~ / 유키시로 사나에

* '''2024년'''
** 어리석은 천사는 악마와 춤춘다 / 조
** 괴이와 소녀와 행방불명 / 역무원
** 전대대실격 / 류진군
** [[드래곤볼 DAIMA]] / '''손오공''', '''손오공〈미니〉''', '''손오반''', '''손오천''', 오천크스<ref>[https://dragonballdaima.com/character.html ドラゴンボールDAIMA 공식 사이트 - 캐릭터]</ref>

* '''2025년'''
** 포켓몬스터 / 큰할머니
** SANDA / 테츠도메 토요

=== 극장 애니메이션 ===

* [[드래곤볼]] 극장판 시리즈 / 손오공, 손오반, 손오천, 버독 등
* [[은하철도 999]] 극장판 / 호시노 테츠로
* [[극장판 포켓몬스터 모두의 이야기]] / 히스이
* [[드래곤볼 슈퍼: 브로리]] / 손오공, 손오천, 버독
* [[날씨의 아이]] / 점쟁이 할머니
* [[드래곤볼 슈퍼: 슈퍼 히어로]] / 손오반, 손오공, 손오천
* [[키타로 탄생 게게게의 수수께끼]] / 눈알 아버지
* 극장판 나와 로보코 / 로보코 {{덧|쇼와 개그 만화 세계선}}

=== 게임 ===

* [[드래곤볼]] 게임 시리즈 / 손오공, 손오반, 손오천, 버독, 오공 블랙 등
** 1993년 《드래곤볼 Z 초무투전》부터 다수의 게임에서 손오공을 맡았다.
** 2017년, 이 장기 출연으로 기네스 세계 기록 2개 부문에 인정되었다.<ref name="guinness" />
* [[디지몬]] 게임 시리즈 / 기루몬, 듀크몬 등
* [[점프 포스]] / 손오공
* [[드래곤볼 Z 카카로트]] / 손오공 등
* 슈퍼로봇대전 시리즈 / 로펫트, 오레아나 등
* 마녀가미 - The Witch of Luludidea - / 이야기꾼, 앤서

=== 더빙 ===
아오니 프로덕션 공식 프로필에 따르면 외화 더빙에서도 활동했으며, 《구니스》, 《나 홀로 집에》 계열 작품, 《베이브》, 《포세이돈 어드벤처》, 《미트 페어런츠》 시리즈 등에서 배역을 맡은 기록이 있다.<ref name="aoni" />

=== 나레이션·기타 ===

* 《なるほど!ザ・ワールド》 / 내레이션
* 《THE 와이드》 / 내레이션
* 《과학 좋아 토요학당》 / 내레이션
* 《자와자와 숲의 간코쨩》 / 케로쨩, 가메쨩
* 영화 《SAND LAND》 예고편 / 내레이션
* 지역 방범·방재 안내 메시지 등 다수

== 인물 및 일화 ==
=== 마코상 ===
팬과 업계 관계자 사이에서는 마코상(マコさん)이라는 애칭으로 불린다. 일본 성우계의 대선배이지만, 각종 인터뷰나 이벤트에서는 활발하고 유쾌한 태도로 알려져 있다.

=== 무대 활동 ===
성우 활동뿐 아니라 무대 연기와 연출도 병행했다. 1991년에는 [[극단 문라이트]]를 세웠고, 주재자 겸 연출가로도 활동했다.<ref name="jmaf" />

=== AI 음성 프로젝트 참여 ===
2024년에는 [[아오니 프로덕션]]과 CoeFont의 파트너십에 따라 AI 음성 프로젝트 참여 성우 중 한 명으로 발표되었다. 발표 내용에 따르면 해당 프로젝트는 음성 비서, 로봇, 의료기기 등 안내·보조 음성 영역을 중심으로 하며, 애니메이션·더빙 등 연기 영역에는 제공하지 않는다고 설명되었다.<ref>[https://prtimes.jp/main/html/rd/p/000000089.000078329.html PR TIMES - 青二プロダクションとCoeFont、AIを活用したグローバル戦略パートナーシップを締結]</ref>

== 평가 ==
노자와 마사코는 일본 성우 문화의 형성기, TV 애니메이션의 성장기, 세계적 애니메이션 프랜차이즈의 확산기를 모두 경험한 인물이다. 특히 《드래곤볼》 시리즈를 통해 일본 국내를 넘어 해외 팬층에게도 강하게 인식된 성우이며, 손오공의 일본어 원판 음성은 작품의 정체성과 거의 같은 수준으로 받아들여진다.

또한 성우가 단순한 목소리 출연자가 아니라 하나의 캐릭터성과 작품 이미지를 장기간 구축할 수 있는 배우라는 점을 보여 준 대표 사례이기도 하다. 2025년 문화공로자 선정은 이러한 상징성을 공적으로 인정한 사례로 볼 수 있다.

== 주석 ==
<references />

== 관련 사이트 ==

* {{언어|일}} [https://www.aoni.co.jp/search/nozawa-masako.html 아오니 프로덕션 - 노자와 마사코 공식 프로필]
* {{언어|일}} [https://j-mediaarts-festival.bunka.go.jp/award/single/nozawa-masako/index.html 문화청 미디어예술제 - 노자와 마사코]
* {{언어|일}} [https://dragonballdaima.com/character.html 드래곤볼 DAIMA 공식 사이트 - 캐릭터]
* {{언어|일}} [https://www.guinnessworldrecords.jp/news/features/masako-nozawa-interview 기네스 세계 기록 - 노자와 마사코 특별 인터뷰]

[[분류:일본의 성우]]
[[분류:일본의 배우]]
[[분류:일본의 가수]]
[[분류:아오니 프로덕션]]
[[분류:1936년 출생]]
[[분류:도쿄도 출신]]
[[분류:문화공로자]]

비밀번호

2026-06-19T01:15:20Z

Gaon12: 문서 내용 보강

{{정보보안}}

== 개요 ==
'''비밀번호'''({{llang|en|password}})는 특정 [[계정]], [[시스템]], [[파일]], [[장치]], [[서비스]] 등에 접근하려는 사용자가 정당한 권한을 가지고 있음을 증명하기 위해 입력하는 문자열이다. 더 넓은 의미에서는 사람이 기억하거나 별도로 보관하고 있다가 인증 과정에서 제시하는 '''기억 기반 인증 정보'''를 가리킨다.

쉽게 말해, 비밀번호는 "이 계정의 주인이 나임을 증명하기 위해 내가 알고 있어야 하는 비밀 문장"이다. 현대의 디지털 환경에서는 [[운영체제]] 로그인, [[이메일]], [[인터넷 뱅킹]], [[SNS]], [[게임 계정]], [[클라우드 저장소]], [[사내 업무 시스템]], [[와이파이]], [[압축 파일]], [[암호화 지갑]] 등 거의 모든 곳에서 사용된다.

문제는 비밀번호가 너무 흔하게 쓰인다는 점이다. 사람이 기억해야 하는 계정은 점점 늘어나는데, 사람의 기억력은 그대로다. 그 결과 많은 사용자가 짧고 단순한 비밀번호를 쓰거나, 여러 사이트에서 같은 비밀번호를 재사용하거나, 비밀번호를 메모장·카카오톡 나에게 보내기·이메일 임시보관함 등에 저장하는 식으로 편의성을 택한다. 그리고 공격자는 바로 그 지점을 노린다.

비밀번호는 매우 오래된 인증 방식이지만, 아직도 가장 널리 쓰이는 인증 방식이다. 그래서 "비밀번호는 낡았다"는 말과 "비밀번호 관리는 여전히 중요하다"는 말은 동시에 참이다. 패스키, 생체 인증, 보안 키 같은 대체 수단이 보급되고 있지만, 현실의 수많은 서비스는 여전히 비밀번호를 기본 인증 수단으로 사용한다. 즉, 비밀번호는 당장 사라지지는 않을 것이며, 그렇기 때문에 제대로 이해하고 써야 한다.

== 명칭 ==
한국어에서는 보통 '''비밀번호'''라고 부른다. 문맥에 따라 다음 표현도 사용된다.

{| class="wikitable"
! 표현 !! 의미 !! 비고
|-
| 비밀번호 || 가장 일반적인 표현 || 웹사이트, 앱, 기기 잠금 등에서 사용
|-
| 암호 || 비밀번호와 비슷하게 쓰이나, 암호학의 암호와 혼동될 수 있음 || 일상에서는 "암호를 입력하세요"라고도 많이 표현
|-
| 패스워드 || 영어 password를 그대로 읽은 표현 || 기술 문서나 오래된 UI에서 자주 보임
|-
| 패스코드 || 숫자 위주의 짧은 잠금 코드 || 스마트폰 잠금, 2차 인증 코드 등에서 사용
|-
| PIN || 보통 숫자 기반 개인 식별 번호 || 카드, 스마트폰, 윈도우 로그인 등에서 사용
|-
| 패스프레이즈 || 여러 단어로 이루어진 긴 비밀번호 || 기억하기 쉽고 길게 만들 수 있음
|}

엄밀히 말하면 PIN, 패스프레이즈, 잠금 해제 코드, 계정 비밀번호는 서로 다른 맥락에서 쓰일 수 있다. 그러나 사용자가 "내가 알고 있어야 하는 비밀값"이라는 점에서는 같은 계열에 속한다.

== 특징 ==
비밀번호의 핵심 특징은 다음과 같다.

* '''비밀성''': 타인에게 알려지면 안 된다.
* '''기억 가능성''': 사용자가 입력할 수 있어야 한다.
* '''검증 가능성''': 시스템은 사용자가 입력한 값이 맞는지 확인할 수 있어야 한다.
* '''변경 가능성''': 유출되었거나 추측 가능성이 있으면 바꿀 수 있어야 한다.
* '''재사용 위험성''': 같은 비밀번호를 여러 곳에서 쓰면 한 곳의 유출이 다른 곳의 침해로 이어진다.
* '''인간 의존성''': 사용자의 기억, 습관, 주의력에 크게 의존한다.

비밀번호는 본질적으로 '''공유 비밀'''이다. 사용자와 서비스가 같은 비밀값을 기준으로 인증한다. 물론 제대로 된 서비스는 비밀번호 원문을 저장하지 않고, 해시 처리된 값만 저장해야 한다. 그러나 사용자가 입력하는 과정에서는 여전히 비밀값이 서비스에 전달된다. 이 점에서 비밀번호는 피싱, 키로깅, 데이터베이스 유출, 재사용 공격에 취약하다.

== 역사 ==
컴퓨터 분야에서 비밀번호는 초기 시분할 시스템과 함께 등장했다. 여러 사용자가 하나의 대형 컴퓨터를 함께 사용하던 시절, 각 사용자의 파일과 작업을 구분하고 보호하기 위해 로그인과 비밀번호가 필요해졌다.

대표적으로 MIT의 Compatible Time-Sharing System, 줄여서 CTSS는 컴퓨터 로그인에 비밀번호를 도입한 초기 사례로 알려져 있다.<ref name="ctss">[https://people.csail.mit.edu/saltzer/Multics/CTSS-Documents/CTSS_50th_anniversary_web_03.pdf Compatible Time-Sharing System 50th Anniversary Commemorative Overview]</ref> 당시의 비밀번호는 오늘날처럼 수십 개 사이트를 보호하기 위한 것이 아니라, 한 컴퓨터를 여러 사용자가 나누어 쓰는 환경에서 개인 파일과 사용 시간을 구분하기 위한 장치에 가까웠다.

이후 [[유닉스]] 계열 시스템에서는 비밀번호를 평문으로 저장하지 않고 해시 형태로 저장하는 방식이 도입되었다. 이는 비밀번호 원문을 그대로 저장했을 때 발생하는 치명적인 위험을 줄이기 위한 발전이었다. 다만 초기의 해시 방식은 오늘날 기준으로는 충분히 강력하지 않으며, 현대적인 시스템에서는 Argon2id, bcrypt, PBKDF2 같은 느린 비밀번호 해싱 알고리즘을 사용해야 한다.<ref name="owasp-storage">[https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html OWASP Password Storage Cheat Sheet]</ref>

인터넷이 대중화된 뒤에는 상황이 크게 바뀌었다. 사용자는 더 이상 한두 개의 시스템에만 비밀번호를 쓰지 않게 되었다. 이메일, 포털, 쇼핑몰, 은행, 게임, 커뮤니티, 회사 시스템, 클라우드, 모바일 앱마다 비밀번호가 필요해졌다. 이 시점부터 비밀번호 문제는 단순한 기술 문제가 아니라 '''인간의 기억력과 습관을 전제로 하는 보안 문제'''가 되었다.

== 작동 원리 ==
가장 단순한 비밀번호 인증 절차는 다음과 같다.

# 사용자가 아이디와 비밀번호를 입력한다.
# 서비스는 입력된 아이디에 해당하는 계정을 찾는다.
# 서비스는 입력된 비밀번호를 내부 방식으로 처리한다.
# 저장된 값과 비교한다.
# 일치하면 로그인에 성공하고, 일치하지 않으면 실패한다.

그러나 실제 보안 시스템에서는 비밀번호 원문을 그대로 저장하거나 비교하면 안 된다. 안전한 시스템은 대체로 다음과 같은 방식으로 동작한다.

# 사용자가 비밀번호를 설정한다.
# 서버는 비밀번호에 계정별 무작위 값인 솔트를 붙인다.
# 서버는 [[Argon2id]], [[bcrypt]], [[PBKDF2]] 같은 비밀번호 해싱 알고리즘으로 해시를 만든다.
# 서버는 비밀번호 원문이 아니라 해시 결과와 솔트, 알고리즘 설정값을 저장한다.
# 사용자가 로그인할 때 입력한 비밀번호에 같은 절차를 적용한다.
# 새로 계산한 해시와 저장된 해시가 일치하면 인증에 성공한다.

이때 핵심은 '''비밀번호 원문을 저장하지 않는 것'''이다. 비밀번호 원문을 저장한 서비스는 데이터베이스가 유출되는 순간 사용자 비밀번호 전체를 공격자에게 넘겨주는 것이나 다름없다. "관리자가 비밀번호를 알려줄 수 있다"는 서비스는 편리해 보일 수 있으나, 보안 관점에서는 매우 위험한 설계일 가능성이 높다. 정상적인 서비스라면 관리자가 사용자의 비밀번호 원문을 알 수 없어야 한다.

== 비밀번호의 강도 ==
비밀번호의 강도는 공격자가 해당 비밀번호를 맞히기 얼마나 어려운지에 따라 결정된다. 흔히 특수문자, 대문자, 숫자가 많으면 강한 비밀번호라고 생각하지만, 현대적인 기준에서는 '''길이''', '''무작위성''', '''고유성''', '''유출 여부'''가 더 중요하다.

=== 길이 ===
비밀번호는 길수록 일반적으로 강해진다. 가능한 경우 최소 12자 이상, 비밀번호만으로 로그인하는 중요한 계정은 15자 이상을 권장하는 기준이 널리 쓰인다. NIST SP 800-63B 최신판은 단일 인증 요소로 쓰이는 비밀번호에 대해 최소 15자를 요구하고, 다중 인증과 함께 쓰이는 비밀번호는 최소 8자를 요구한다.<ref name="nist-800-63b">[https://pages.nist.gov/800-63-4/sp800-63b.html NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management]</ref>

중요한 점은 "짧고 복잡한 비밀번호"보다 "길고 예측하기 어려운 비밀번호"가 더 낫다는 것이다. 예를 들어 다음과 같은 비밀번호는 겉보기에는 복잡해 보여도 실제로는 약하다.

* P@ssw0rd!
* Qwer1234!
* Summer2026!
* CompanyName2026!
* 이름+생일+특수문자 조합

이런 비밀번호는 공격자가 자주 시도하는 패턴에 가깝다. 대문자 하나, 숫자 몇 개, 느낌표 하나를 붙이는 방식은 이미 너무 흔하다. 공격자는 이런 습관을 알고 있다.

=== 무작위성 ===
무작위성은 비밀번호가 예측 가능한 규칙을 따르지 않는 정도를 말한다. 사람이 직접 만든 비밀번호는 대개 자신도 모르게 패턴을 따른다. 좋아하는 단어, 생일, 닉네임, 키보드 배열, 서비스 이름, 현재 연도, 느낌표 같은 요소가 들어간다.

반면 비밀번호 관리자가 생성한 무작위 비밀번호는 사람이 떠올리기 어려운 조합으로 만들어진다. 예를 들어 다음과 같은 형태다.

* 24자 이상의 무작위 문자열
* 대문자, 소문자, 숫자, 기호가 섞인 난수 기반 문자열
* 서비스마다 완전히 다른 값

무작위 비밀번호는 외우기 어렵지만, 비밀번호 관리자를 사용하면 외울 필요가 없다. 이것이 현대적인 비밀번호 관리의 핵심이다.

=== 고유성 ===
비밀번호 보안에서 가장 치명적인 습관 중 하나는 '''재사용'''이다. 아무리 강한 비밀번호라도 여러 사이트에서 같은 값을 쓰면 위험하다. 한 사이트가 털리면 공격자는 그 아이디와 비밀번호 조합을 다른 사이트에도 넣어 본다. 이것을 '''크리덴셜 스터핑'''이라고 한다.

예를 들어 A 쇼핑몰에서 사용한 이메일과 비밀번호가 유출되었다고 하자. 공격자는 같은 조합으로 이메일, SNS, 게임, 클라우드, 은행, 커뮤니티 로그인을 시도한다. 사용자가 같은 비밀번호를 재사용했다면 피해는 연쇄적으로 확대된다.

따라서 중요한 원칙은 간단하다.

* 계정마다 다른 비밀번호를 쓴다.
* 특히 이메일 계정, 금융 계정, 클라우드 계정, 개발자 계정은 절대 재사용하지 않는다.
* 기억하기 어렵다면 비밀번호 관리자를 쓴다.

=== 유출 여부 ===
아무리 길고 복잡한 비밀번호라도 이미 유출된 적이 있다면 사용하면 안 된다. 공격자는 과거 유출 데이터베이스를 바탕으로 로그인 시도를 자동화한다. NIST는 서비스가 새 비밀번호를 설정할 때 흔한 비밀번호, 예상 가능한 비밀번호, 이미 유출된 비밀번호 목록과 비교해 차단할 것을 요구한다.<ref name="nist-800-63b" />

즉, "내 비밀번호는 복잡하니까 괜찮다"가 아니라 "이미 유출된 적이 없는가"도 중요하다. 특히 유명한 약한 비밀번호에 숫자나 특수문자만 조금 붙인 형태는 피해야 한다.

== 좋은 비밀번호의 조건 ==
좋은 비밀번호는 다음 조건을 만족한다.

{| class="wikitable"
! 조건 !! 설명
|-
| 길다 || 짧은 비밀번호보다 추측과 대입 공격에 강하다.
|-
| 예측하기 어렵다 || 이름, 생일, 전화번호, 닉네임, 서비스명, 키보드 패턴을 쓰지 않는다.
|-
| 계정마다 다르다 || 한 사이트의 유출이 다른 사이트로 번지지 않게 한다.
|-
| 유출된 적이 없다 || 과거 유출 목록에 있는 비밀번호는 쓰지 않는다.
|-
| 관리 가능하다 || 사람이 무리해서 외우기보다 비밀번호 관리자를 활용한다.
|-
| 복구 수단도 안전하다 || 이메일, 휴대폰 번호, 보안 질문이 약하면 비밀번호가 강해도 뚫릴 수 있다.
|}

현실적인 권장 방식은 다음과 같다.

* 비밀번호 관리자를 사용한다.
* 각 계정마다 16자 이상 또는 20자 이상의 무작위 비밀번호를 생성한다.
* 이메일, 금융, 클라우드, 개발자 계정은 특히 길게 설정한다.
* 가능한 모든 중요한 계정에 다중 인증을 켠다.
* 패스키를 지원하는 서비스에서는 패스키 사용을 검토한다.

== 패스프레이즈 ==
'''패스프레이즈'''({{llang|en|passphrase}})는 여러 단어로 이루어진 긴 비밀번호를 말한다. 예를 들어 의미 없는 여러 단어를 조합하여 긴 문자열을 만드는 방식이다.

패스프레이즈의 장점은 길이를 쉽게 늘릴 수 있다는 점이다. 사람이 완전히 무작위인 24자 문자열을 외우기는 어렵지만, 여러 단어로 이루어진 문장은 비교적 기억하기 쉽다.

다만 패스프레이즈도 주의해야 한다. 유명한 문장, 노래 가사, 애니메이션 대사, 성경 구절, 명언, 인터넷 밈, 자기소개 문장처럼 이미 공개되어 있거나 추측 가능한 문장은 피해야 한다. "나는비밀번호를잊지않는다" 같은 문장은 길어 보이지만, 사람이 만든 문장이라 예측 가능성이 생긴다.

좋은 패스프레이즈는 다음 조건을 만족한다.

* 단어 선택이 무작위에 가깝다.
* 개인 정보와 관련이 없다.
* 유명 문구가 아니다.
* 충분히 길다.
* 서비스마다 다르다.

패스프레이즈는 비밀번호 관리자를 쓰기 어려운 환경에서 특히 유용하다. 예를 들어 비밀번호 관리자 자체의 마스터 비밀번호, 운영체제 로그인 비밀번호, 디스크 암호화 비밀번호처럼 직접 기억해야 하는 경우에 적합하다.

== 나쁜 비밀번호의 예 ==
다음 유형은 피해야 한다.

{| class="wikitable"
! 유형 !! 예시 !! 문제점
|-
| 너무 짧은 비밀번호 || 123456, 000000, 111111 || 자동화된 추측 공격에 매우 취약하다.
|-
| 키보드 배열 || qwerty, asdf1234, qazwsx || 공격자가 자주 시도하는 패턴이다.
|-
| 흔한 단어 || password, admin, iloveyou || 유출 목록과 사전 공격에 자주 포함된다.
|-
| 개인정보 || 이름+생일, 전화번호, 학번 || 주변인이나 유출된 개인정보로 추측 가능하다.
|-
| 서비스명 포함 || naver2026!, google123! || 공격자가 서비스명 기반 변형을 시도할 수 있다.
|-
| 연도만 바꾸는 방식 || Password2024!, Password2025!, Password2026! || 주기적 변경의 대표적인 실패 사례다.
|-
| 같은 비밀번호 재사용 || 모든 사이트에 같은 비밀번호 사용 || 한 곳이 털리면 다른 곳도 위험해진다.
|}

특히 "대문자 하나, 소문자 몇 개, 숫자 몇 개, 느낌표 하나" 형식은 더 이상 특별하지 않다. 많은 사용자가 같은 방식으로 비밀번호를 만들기 때문에 공격자도 그 패턴을 우선적으로 시도한다.

== 공격 방식 ==
비밀번호를 노리는 공격은 다양하다. 공격자는 반드시 영화처럼 멋진 화면을 띄우고 해킹하지 않는다. 실제로는 유출된 목록을 자동으로 대입하거나, 사용자가 스스로 입력하도록 속이거나, 이미 감염된 기기에서 입력값을 훔치는 식의 현실적인 공격이 많다.

=== 무차별 대입 공격 ===
'''무차별 대입 공격'''({{llang|en|brute-force attack}})은 가능한 모든 조합을 하나씩 시도하는 방식이다. 이론적으로는 모든 비밀번호를 언젠가 맞힐 수 있지만, 길고 복잡한 비밀번호는 가능한 조합이 너무 많아 현실적인 시간 안에 맞히기 어렵다.

다만 실제 공격은 순수한 무차별 대입만으로 이루어지지 않는다. 공격자는 흔한 비밀번호, 사전 단어, 유출된 비밀번호, 사람들의 변형 습관을 먼저 시도한다. 그래서 "문자 종류가 많다"보다 "예측 가능한 패턴을 피한다"가 중요하다.

=== 사전 공격 ===
'''사전 공격'''({{llang|en|dictionary attack}})은 사전에 있는 단어, 흔한 문구, 자주 쓰이는 비밀번호 목록을 이용해 시도하는 공격이다. password, qwerty, dragon, football 같은 흔한 단어는 물론, 한국어 이름, 아이돌 이름, 애니메이션 캐릭터 이름, 회사명, 지역명, 학교명도 공격 목록에 들어갈 수 있다.

사전 공격은 단어를 그대로 넣는 것에서 끝나지 않는다. 공격자는 다음과 같은 변형도 시도한다.

* 단어 뒤에 숫자 붙이기
* 첫 글자만 대문자로 바꾸기
* a를 @로, o를 0으로 바꾸기
* 끝에 느낌표 붙이기
* 현재 연도 붙이기
* 서비스 이름과 단어를 조합하기

따라서 "단어 하나를 살짝 변형한 비밀번호"는 안전하지 않다.

=== 크리덴셜 스터핑 ===
'''크리덴셜 스터핑'''({{llang|en|credential stuffing}})은 이미 유출된 아이디와 비밀번호 조합을 다른 서비스에 자동으로 넣어 보는 공격이다. 비밀번호 재사용이 위험한 가장 큰 이유다.

예를 들어 어떤 커뮤니티에서 이메일과 비밀번호가 유출되면, 공격자는 그 조합으로 쇼핑몰, 포털, 게임, 클라우드, 은행 등에 로그인을 시도한다. 사용자가 같은 비밀번호를 여러 곳에서 썼다면 공격은 성공한다.

이 공격을 막는 가장 좋은 방법은 다음과 같다.

* 서비스마다 다른 비밀번호 사용
* 비밀번호 관리자 사용
* 다중 인증 활성화
* 로그인 알림 확인
* 유출 의심 시 즉시 변경

=== 피싱 ===
'''피싱'''({{llang|en|phishing}})은 사용자를 속여 가짜 로그인 페이지에 비밀번호를 입력하게 만드는 공격이다. 비밀번호가 아무리 길고 복잡해도 사용자가 가짜 사이트에 직접 입력하면 공격자는 그대로 가져간다.

피싱은 다음 형태로 나타날 수 있다.

* 은행을 사칭한 문자
* 택배 배송 조회를 가장한 링크
* 계정 정지를 알리는 이메일
* 회사 보안 점검을 가장한 로그인 페이지
* 게임 아이템 지급을 미끼로 한 가짜 사이트
* 클라우드 문서 공유 알림을 가장한 로그인 페이지

피싱에 강해지려면 주소창의 도메인을 확인하고, 의심스러운 링크를 누르지 않으며, 중요한 계정에는 패스키나 보안 키 같은 피싱 저항 인증 수단을 쓰는 것이 좋다. NIST는 비밀번호가 피싱 저항 인증 수단이 아니라고 명시한다.<ref name="nist-800-63b" />

=== 키로깅 ===
'''키로깅'''({{llang|en|keylogging}})은 사용자가 키보드로 입력하는 내용을 훔치는 공격이다. 악성코드가 설치된 PC나 스마트폰에서는 사용자가 아무리 강한 비밀번호를 입력해도 그대로 탈취될 수 있다.

공용 PC, PC방, 감염된 기기, 출처 불명의 프로그램을 실행한 환경에서는 중요한 계정에 로그인하지 않는 것이 좋다. 특히 이메일, 금융, 클라우드, 개발자 계정은 신뢰할 수 없는 기기에서 로그인하지 않는 편이 안전하다.

=== 사회공학 ===
'''사회공학'''({{llang|en|social engineering}})은 기술적 취약점보다 사람의 심리와 실수를 이용하는 공격이다. 공격자는 사용자를 속여 비밀번호를 말하게 하거나, 복구 코드를 넘기게 하거나, 원격 제어 프로그램을 설치하게 만들 수 있다.

예를 들어 다음과 같은 말은 의심해야 한다.

* "보안 점검을 위해 비밀번호를 알려 달라."
* "본인 확인을 위해 인증번호를 불러 달라."
* "계정이 정지되었으니 아래 링크에서 로그인하라."
* "원격으로 도와줄 테니 프로그램을 설치하라."
* "회사 관리자이니 임시 비밀번호를 알려 달라."

정상적인 관리자, 은행, 공공기관, 보안 담당자는 사용자의 비밀번호 원문을 요구하지 않는다.

=== 데이터베이스 유출 ===
서비스 자체가 해킹되어 회원 정보 데이터베이스가 유출되는 경우도 있다. 이때 서비스가 비밀번호를 평문으로 저장했다면 피해는 치명적이다. 해시 처리를 했더라도 약한 알고리즘을 썼거나 솔트가 없거나 비용 인자가 낮으면 공격자가 오프라인에서 대량으로 추측할 수 있다.

따라서 사용자는 서비스마다 다른 비밀번호를 사용해야 하고, 개발자는 비밀번호를 안전하게 저장해야 한다.

== 비밀번호 관리자 ==
'''비밀번호 관리자'''({{llang|en|password manager}})는 여러 계정의 비밀번호를 암호화하여 저장하고, 필요할 때 자동 입력하거나 생성해 주는 도구다. 현대적인 비밀번호 관리에서 사실상 필수 도구에 가깝다.

CISA는 길고 무작위이며 고유한 비밀번호를 비밀번호 관리자로 생성하고, 다중 인증을 켤 것을 권고한다.<ref name="cisa-passwords">[https://www.cisa.gov/secure-our-world/use-strong-passwords CISA, Use Strong Passwords]</ref> NIST 역시 비밀번호 관리자와 자동 입력, 붙여넣기 사용을 허용해야 한다고 설명한다.<ref name="nist-800-63b" />

=== 장점 ===
비밀번호 관리자의 장점은 다음과 같다.

* 계정마다 다른 비밀번호를 쉽게 만들 수 있다.
* 20자 이상의 무작위 비밀번호를 현실적으로 사용할 수 있다.
* 사용자가 모든 비밀번호를 외울 필요가 없다.
* 피싱 사이트에서 자동 입력이 되지 않아 이상 징후를 알아차릴 수 있다.
* 유출된 비밀번호나 재사용 비밀번호를 점검할 수 있다.
* 가족, 팀, 회사 단위로 안전하게 공유할 수 있는 기능을 제공하기도 한다.

=== 단점과 주의점 ===
비밀번호 관리자는 강력한 도구지만, 만능은 아니다.

* 마스터 비밀번호가 약하면 위험하다.
* 마스터 비밀번호를 잊으면 복구가 어려울 수 있다.
* 기기가 악성코드에 감염되면 위험할 수 있다.
* 동기화 계정이 탈취되면 위험하다.
* 신뢰할 수 없는 비밀번호 관리자를 쓰면 오히려 위험하다.

따라서 비밀번호 관리자를 사용할 때는 다음을 지켜야 한다.

* 마스터 비밀번호는 길고 강한 패스프레이즈로 만든다.
* 비밀번호 관리자 계정에 다중 인증을 켠다.
* 복구 코드를 안전한 오프라인 장소에 보관한다.
* 운영체제와 브라우저를 최신 상태로 유지한다.
* 출처가 명확한 관리자를 사용한다.
* 공용 기기에서는 비밀번호 관리자에 로그인하지 않는다.

=== 브라우저 내장 비밀번호 관리자 ===
크롬, 엣지, 사파리, 파이어폭스 같은 브라우저는 자체 비밀번호 저장 기능을 제공한다. 운영체제와 연동되는 경우도 많아 편리하다. 일반 사용자에게는 브라우저 내장 비밀번호 관리자도 비밀번호 재사용보다 훨씬 낫다.

다만 전문 비밀번호 관리자는 다음과 같은 추가 장점을 제공할 수 있다.

* 다양한 브라우저와 운영체제 간 일관된 동기화
* 가족·조직 공유 기능
* 보안 감사 기능
* 고급 2차 인증 지원
* 별도 보안 정책 설정
* 긴급 접근 기능

개인 사용자는 브라우저 내장 기능으로 시작해도 좋지만, 계정이 많거나 중요 계정이 많다면 전용 비밀번호 관리자를 검토할 만하다.

== 다중 인증 ==
'''다중 인증'''({{llang|en|multi-factor authentication}}, MFA)은 비밀번호 외에 다른 인증 요소를 추가로 요구하는 방식이다.

인증 요소는 보통 다음 세 가지로 나뉜다.

{| class="wikitable"
! 요소 !! 의미 !! 예시
|-
| 지식 요소 || 사용자가 알고 있는 것 || 비밀번호, PIN
|-
| 소유 요소 || 사용자가 가지고 있는 것 || 휴대폰, 보안 키, OTP 기기
|-
| 생체 요소 || 사용자 신체 특성 || 지문, 얼굴, 홍채
|}

비밀번호만 쓰면 지식 요소 하나에 의존한다. 다중 인증을 켜면 공격자가 비밀번호를 알아내더라도 추가 요소가 필요해진다. 그래서 계정 탈취 가능성을 크게 줄일 수 있다.

=== 다중 인증의 종류 ===
대표적인 다중 인증 방식은 다음과 같다.

{| class="wikitable"
! 방식 !! 설명 !! 보안성
|-
| SMS 인증 || 문자로 인증번호를 받는 방식 || 없는 것보다는 낫지만 SIM 스와핑, 문자 탈취 위험이 있다.
|-
| 이메일 인증 || 이메일로 코드를 받는 방식 || 이메일 계정이 털리면 함께 위험해진다.
|-
| TOTP 앱 || 인증 앱에서 시간 기반 코드를 생성하는 방식 || 일반적으로 SMS보다 안전하다.
|-
| 푸시 인증 || 앱에서 로그인 승인 알림을 받는 방식 || 편리하지만 피로 공격에 주의해야 한다.
|-
| 하드웨어 보안 키 || USB, NFC, 블루투스 보안 키를 사용하는 방식 || 매우 강력하다.
|-
| 패스키 || 공개키 기반의 비밀번호 없는 로그인 방식 || 피싱 저항성이 강하다.
|}

=== 다중 인증도 완벽하지 않다 ===
다중 인증은 강력하지만, 모든 공격을 막는 마법은 아니다. SMS 인증은 번호 이동 사기나 SIM 스와핑에 취약할 수 있고, 푸시 인증은 사용자가 실수로 승인할 수 있다. TOTP 코드도 실시간 피싱 사이트에 입력하면 탈취될 수 있다.

따라서 중요한 계정에는 가능하면 다음 순서를 고려한다.

# 패스키 또는 하드웨어 보안 키
# 인증 앱 기반 TOTP
# 푸시 인증
# SMS 인증
# 이메일 인증

물론 어떤 다중 인증이든 비밀번호만 쓰는 것보다는 대체로 낫다. 다만 금융, 이메일, 클라우드, 개발자 계정처럼 중요한 계정은 피싱 저항성이 높은 방식을 우선하는 것이 좋다.

== 패스키와 비밀번호의 관계 ==
'''패스키'''({{llang|en|passkey}})는 비밀번호를 대체하기 위해 만들어진 공개키 기반 인증 방식이다. 사용자는 비밀번호를 입력하는 대신 기기의 잠금 해제 방식, 예컨대 지문, 얼굴 인식, PIN 등을 이용해 로그인한다.

패스키는 일반적인 비밀번호와 달리 서버에 비밀번호 원문이나 공유 비밀을 보내지 않는다. 서비스에는 공개키가 등록되고, 사용자의 기기에는 개인키가 보관된다. 로그인할 때는 개인키로 서명하고, 서비스는 공개키로 이를 검증한다. 이 구조 때문에 패스키는 피싱과 크리덴셜 스터핑에 강하다. FIDO Alliance는 패스키가 피싱, 크리덴셜 스터핑, 원격 공격을 줄이는 데 도움이 된다고 설명한다.<ref name="fido-passkeys">[https://fidoalliance.org/passkeys/ FIDO Alliance, Passkeys]</ref>

다만 패스키가 보급되었다고 해서 비밀번호 관리가 곧바로 사라지는 것은 아니다. 많은 서비스가 아직 비밀번호를 요구하고, 패스키를 쓰더라도 복구용 비밀번호나 이메일 계정이 남아 있는 경우가 많다. 따라서 패스키와 비밀번호는 한동안 공존할 가능성이 높다.

== 비밀번호 정책 ==
비밀번호 정책은 서비스가 사용자에게 요구하는 비밀번호 규칙이다. 과거에는 다음과 같은 정책이 흔했다.

* 최소 8자
* 대문자 포함
* 소문자 포함
* 숫자 포함
* 특수문자 포함
* 90일마다 변경
* 최근 사용한 비밀번호 재사용 금지
* 붙여넣기 금지

그러나 현대적인 보안 권고는 이런 방식의 일부를 비판한다. 특히 '''복잡도 강제'''와 '''주기적 변경 강제'''는 사용자를 괴롭히는 데 비해 보안 향상이 제한적일 수 있다. 사용자는 강제로 자주 바꾸라고 하면 Password2025!를 Password2026!으로 바꾸는 식의 예측 가능한 변경을 하기 쉽다.

NIST는 비밀번호에 대해 대문자·소문자·숫자·기호 조합 같은 추가 구성 규칙을 강제하지 말고, 주기적 변경도 요구하지 말라고 설명한다. 다만 유출 또는 침해 증거가 있으면 변경을 강제해야 한다.<ref name="nist-800-63b" />

=== 좋은 비밀번호 정책 ===
좋은 비밀번호 정책은 다음과 같다.

{| class="wikitable"
! 항목 !! 권장 방향
|-
| 최소 길이 || 비밀번호 단독 인증은 15자 이상, MFA와 함께 쓰는 경우도 최소 8자 이상
|-
| 최대 길이 || 최소 64자 이상 허용
|-
| 문자 허용 || 공백, 기호, 가능한 경우 유니코드 허용
|-
| 복잡도 규칙 || 대문자·숫자·특수문자 강제보다 길이와 유출 차단을 중시
|-
| 유출 비밀번호 차단 || 흔한 비밀번호, 유출 비밀번호, 서비스명 포함 비밀번호 차단
|-
| 주기적 변경 || 임의의 정기 변경은 강제하지 않음
|-
| 붙여넣기 || 비밀번호 관리자 사용을 위해 허용
|-
| 비밀번호 힌트 || 인증 전 접근 가능한 힌트는 금지
|-
| 보안 질문 || 비밀번호 선택 과정에서 지식 기반 보안 질문 사용 지양
|-
| 로그인 시도 제한 || 과도한 실패 시 속도 제한, 지연, 추가 검증 적용
|}

=== 나쁜 비밀번호 정책 ===
나쁜 비밀번호 정책의 예는 다음과 같다.

* 최대 12자까지만 허용한다.
* 특수문자를 일부만 허용한다.
* 공백을 허용하지 않는다.
* 붙여넣기를 막는다.
* 30일마다 무조건 바꾸게 한다.
* 비밀번호 힌트를 공개적으로 보여 준다.
* 보안 질문으로 "어머니의 성함은?" 같은 정보를 요구한다.
* 비밀번호 일부 글자만 입력하게 한다.
* 비밀번호를 평문 이메일로 보내 준다.
* 관리자가 사용자의 비밀번호를 확인할 수 있다.

특히 최대 길이가 지나치게 짧은 서비스는 문제가 있다. 사용자가 비밀번호 관리자로 만든 긴 무작위 비밀번호를 쓸 수 없게 만들기 때문이다.

== 비밀번호 저장 ==
개발자와 서비스 운영자에게 가장 중요한 원칙은 다음과 같다.

'''비밀번호를 평문으로 저장하지 말 것.'''

비밀번호는 암호화해서 복호화할 수 있게 저장하는 것도 적절하지 않다. 일반적으로 비밀번호는 복호화가 아니라 검증만 가능하면 된다. 따라서 비밀번호는 느린 단방향 해싱 알고리즘으로 처리해야 한다.

OWASP는 비밀번호를 평문으로 저장하지 말고 Argon2id, bcrypt, PBKDF2 같은 강한 느린 해싱 알고리즘으로 보호해야 하며, 각 비밀번호에는 고유한 솔트를 추가해야 한다고 권고한다.<ref name="owasp-storage" />

=== 해시와 암호화의 차이 ===
해시와 암호화는 다르다.

{| class="wikitable"
! 구분 !! 해시 !! 암호화
|-
| 목적 || 원본을 되돌리지 않고 검증 || 원본을 숨겼다가 필요 시 복원
|-
| 복호화 가능성 || 일반적으로 불가능해야 함 || 키가 있으면 가능
|-
| 비밀번호 저장에 적합한가 || 적합함 || 일반적으로 부적합
|-
| 예시 || Argon2id, bcrypt, PBKDF2 || AES, ChaCha20 등
|}

비밀번호 저장에는 복호화 가능한 암호화보다 단방향 해싱이 적합하다. 서비스는 사용자의 비밀번호를 다시 보여 줄 필요가 없기 때문이다. 사용자가 비밀번호를 잊으면 "찾기"가 아니라 "재설정"을 해야 한다.

=== 솔트 ===
'''솔트'''({{llang|en|salt}})는 각 비밀번호마다 추가되는 무작위 값이다. 솔트의 목적은 같은 비밀번호라도 서로 다른 해시 결과가 나오게 하는 것이다.

예를 들어 두 사용자가 같은 비밀번호를 사용하더라도 솔트가 다르면 저장된 해시는 달라진다. 이는 레인보우 테이블 같은 사전 계산 공격을 어렵게 만든다.

솔트는 비밀일 필요는 없지만, 계정마다 고유하고 충분히 무작위여야 한다. 같은 솔트를 모든 사용자에게 쓰는 것은 좋지 않다.

=== 페퍼 ===
'''페퍼'''({{llang|en|pepper}})는 솔트와 달리 서버 쪽에서 별도로 보관하는 비밀값이다. 데이터베이스만 유출된 경우 공격을 더 어렵게 만들기 위해 사용될 수 있다.

다만 페퍼는 운영 복잡성을 높인다. 키 관리, 회전, 백업, 장애 대응을 제대로 설계하지 않으면 오히려 문제가 생길 수 있다. 페퍼는 비밀번호 해싱을 대체하는 것이 아니라 보조 방어 수단으로 보아야 한다.

=== 느린 해싱 알고리즘 ===
비밀번호 저장에는 빠른 해시 함수가 아니라 느린 해싱 알고리즘이 필요하다. SHA-256, SHA-512 같은 일반 해시 함수는 빠르기 때문에 파일 무결성 확인에는 좋지만, 비밀번호 저장에는 적합하지 않다. 공격자도 빠르게 대량 추측을 할 수 있기 때문이다.

대표적인 비밀번호 해싱 알고리즘은 다음과 같다.

{| class="wikitable"
! 알고리즘 !! 특징 !! 비고
|-
| Argon2id || 메모리 사용량과 시간 비용을 조절할 수 있는 현대적 알고리즘 || 신규 시스템에서 우선 검토할 만함
|-
| bcrypt || 오랫동안 검증된 알고리즘 || 널리 지원되지만 입력 길이 제한 등에 주의 필요
|-
| PBKDF2 || 오래된 표준 기반 알고리즘 || 규제 환경에서 쓰이기도 하나 충분한 반복 횟수 필요
|-
| scrypt || 메모리 비용을 요구하는 알고리즘 || 일부 시스템에서 사용
|}

중요한 것은 알고리즘 이름만이 아니다. 비용 인자, 메모리 사용량, 반복 횟수, 라이브러리 구현, 마이그레이션 정책이 함께 중요하다.

== 개발자가 지켜야 할 원칙 ==
웹 서비스나 앱을 만드는 개발자는 다음 원칙을 지켜야 한다.

=== 입력과 전송 ===

* 로그인 페이지는 HTTPS를 사용한다.
* 비밀번호를 URL 쿼리 문자열에 넣지 않는다.
* 로그에 비밀번호를 남기지 않는다.
* 오류 추적 도구에 비밀번호가 전송되지 않게 한다.
* 비밀번호 입력란은 적절한 자동완성 속성을 사용한다.
* 사용자가 비밀번호 관리자를 쓸 수 있게 한다.
* 붙여넣기를 막지 않는다.
* 필요하면 비밀번호 표시 버튼을 제공하되, 기본값은 숨김으로 둔다.

=== 저장 ===

* 평문 저장 금지
* 단순 SHA-256 저장 금지
* 계정별 고유 솔트 사용
* Argon2id, bcrypt, PBKDF2 등 검증된 비밀번호 해싱 알고리즘 사용
* 비용 인자를 주기적으로 상향 검토
* 알고리즘과 비용 인자를 저장해 향후 마이그레이션 가능하게 설계
* 비밀번호 변경 시 기존 세션 처리 정책 마련
* 관리자도 사용자 비밀번호 원문을 볼 수 없게 설계

=== 인증 흐름 ===

* 로그인 실패 횟수에 대한 속도 제한 적용
* 단순 계정 잠금만으로 서비스 거부 공격이 발생하지 않게 설계
* 크리덴셜 스터핑 탐지
* 비정상 로그인 알림
* 새 기기 로그인 알림
* 민감 작업 시 재인증 요구
* 2차 인증 설정 지원
* 패스키 지원 검토

=== 비밀번호 재설정 ===
비밀번호 재설정은 로그인만큼 중요하다. 재설정 절차가 약하면 비밀번호가 아무리 강해도 소용없다.

좋은 비밀번호 재설정 정책은 다음과 같다.

* 재설정 링크는 충분히 긴 무작위 토큰을 사용한다.
* 재설정 토큰은 짧은 유효 기간을 가진다.
* 재설정 토큰은 한 번만 사용할 수 있어야 한다.
* 재설정 토큰도 안전하게 저장한다.
* 비밀번호 변경 후 사용자에게 알림을 보낸다.
* 이메일 계정 탈취를 고려해 민감 계정은 추가 검증을 요구한다.
* 보안 질문만으로 비밀번호를 재설정하지 않는다.

=== 오류 메시지 ===
로그인 실패 메시지는 공격자에게 불필요한 정보를 주지 않아야 한다.

나쁜 예:

* "존재하지 않는 아이디입니다."
* "비밀번호가 틀렸습니다."
* "이 이메일은 가입되어 있습니다."

좋은 예:

* "아이디 또는 비밀번호가 올바르지 않습니다."
* "입력한 정보로 로그인할 수 없습니다."

다만 사용성도 중요하다. 무조건 모든 정보를 숨기면 사용자가 문제를 해결하기 어렵다. 보안과 사용성 사이에서 적절한 균형이 필요하다.

== 사용자가 지켜야 할 원칙 ==
일반 사용자는 다음 원칙만 지켜도 대부분의 비밀번호 사고를 크게 줄일 수 있다.

# 비밀번호 관리자를 사용한다.
# 계정마다 다른 비밀번호를 쓴다.
# 중요한 계정은 16자 이상 또는 관리자가 생성한 긴 무작위 비밀번호를 쓴다.
# 이메일 계정은 최우선으로 보호한다.
# 다중 인증을 켠다.
# 패스키를 지원하면 사용을 검토한다.
# 공용 PC에서 중요한 계정에 로그인하지 않는다.
# 의심스러운 링크에서 로그인하지 않는다.
# 유출 알림을 받으면 즉시 비밀번호를 바꾼다.
# 복구 이메일과 전화번호도 안전하게 관리한다.

특히 이메일 계정은 모든 계정의 복구 허브가 되는 경우가 많다. 이메일이 털리면 다른 사이트의 비밀번호 재설정 링크를 공격자가 받을 수 있다. 따라서 이메일 계정은 매우 긴 고유 비밀번호와 강한 다중 인증을 적용해야 한다.

== 상황별 권장 설정 ==
=== 개인 사용자 ===
개인 사용자는 다음 구성을 권장한다.

* 비밀번호 관리자 사용
* 모든 계정에 고유 비밀번호 사용
* 이메일, 금융, 클라우드, SNS, 쇼핑몰 우선 점검
* 중요한 계정에 MFA 적용
* 패스키 지원 서비스에서는 패스키 등록
* 복구 코드 오프라인 보관
* 사용하지 않는 계정 삭제 또는 비밀번호 변경

=== 학생 ===
학생은 학교 계정, 이메일, 클라우드, LMS, 장학금·학사 시스템, 개발자 계정 등을 주의해야 한다.

* 학교 이메일 비밀번호 재사용 금지
* 과제용 GitHub 계정 보호
* 클라우드 드라이브 공유 권한 확인
* PC방이나 공용 컴퓨터에서 자동 로그인 금지
* 졸업 후에도 학교 이메일이 복구 수단으로 남아 있는지 확인

=== 직장인 ===
직장인은 개인 계정보다 회사 계정의 피해 파급력이 더 클 수 있다.

* 회사 계정과 개인 계정 비밀번호 분리
* 업무용 비밀번호를 개인 메신저에 저장하지 않기
* VPN, 메일, 그룹웨어, 클라우드 계정 MFA 적용
* 퇴사자 계정 비활성화 확인
* 공유 계정 사용 최소화
* 비밀번호 공유가 필요하면 조직용 비밀번호 관리자 사용

=== 개발자 ===
개발자는 일반 사용자보다 더 큰 권한을 가진 경우가 많다. GitHub, 클라우드 콘솔, 서버 SSH, 데이터베이스, 패키지 저장소 계정이 털리면 공급망 공격으로 이어질 수 있다.

* GitHub, GitLab, npm, PyPI, Docker Hub 계정 MFA 적용
* SSH 키에 패스프레이즈 설정
* API 키를 코드 저장소에 올리지 않기
* .env 파일 관리 주의
* 비밀번호와 토큰을 로그에 남기지 않기
* 개인 프로젝트와 회사 프로젝트의 계정·키 분리
* 클라우드 루트 계정은 별도 보호
* 장기 토큰보다 짧은 수명의 토큰 사용 검토

=== 관리자 ===
시스템 관리자는 사용자에게 무리한 규칙을 강제하기보다 실제 공격을 막는 정책을 설계해야 한다.

* 긴 비밀번호 허용
* 비밀번호 관리자 사용 허용
* 붙여넣기 허용
* 유출 비밀번호 차단
* MFA 적용
* 로그인 속도 제한
* 비정상 로그인 탐지
* 패스키·보안 키 지원
* 비밀번호 재설정 절차 강화
* 비밀번호 원문 접근 불가 구조 유지

== 비밀번호 변경 시점 ==
비밀번호는 무조건 자주 바꾸는 것이 능사가 아니다. 다음 상황에서는 반드시 바꾸는 것이 좋다.

* 서비스에서 유출 사고가 발생했다.
* 같은 비밀번호를 다른 사이트에서도 사용했다.
* 피싱 사이트에 입력했을 가능성이 있다.
* 공용 PC나 감염 의심 기기에서 로그인했다.
* 로그인 알림에 모르는 위치나 기기가 보인다.
* 가족, 친구, 동료에게 알려 준 적이 있다.
* 퇴사, 팀 이동, 외주 종료 등으로 공유 권한이 바뀌었다.
* 비밀번호가 너무 짧거나 흔한 패턴이다.

반대로 아무 이유 없이 30일 또는 90일마다 강제로 바꾸게 하면 사용자는 예측 가능한 변형을 만들 가능성이 높다. 그래서 최신 권고는 유출이나 침해 근거가 있을 때 변경을 요구하는 방향에 가깝다.<ref name="nist-800-63b" />

== 비밀번호 유출이 의심될 때 ==
비밀번호 유출이 의심되면 다음 순서로 대응한다.

# 해당 계정의 비밀번호를 즉시 변경한다.
# 같은 비밀번호를 사용한 다른 계정도 모두 변경한다.
# 이메일 계정의 로그인 기록을 확인한다.
# 계정 복구 이메일, 전화번호, 연결된 기기를 확인한다.
# 알 수 없는 세션을 로그아웃한다.
# 다중 인증을 켠다.
# 복구 코드를 새로 발급한다.
# 금융 계정이라면 거래 내역을 확인한다.
# 악성코드 감염 가능성이 있으면 기기를 점검한다.
# 중요한 자료가 있는 계정은 고객센터에 문의한다.

여기서 가장 중요한 것은 '''같은 비밀번호를 쓴 다른 계정까지 함께 바꾸는 것'''이다. 공격자는 한 계정만 노리지 않는다.

== 보안 질문 ==
보안 질문은 "어머니의 성함은?", "초등학교 이름은?", "첫 반려동물의 이름은?" 같은 질문에 답하게 하는 방식이다. 과거에는 비밀번호 복구 수단으로 많이 사용되었다.

그러나 보안 질문은 문제가 많다.

* 답이 공개 정보일 수 있다.
* 가족이나 지인이 알 수 있다.
* SNS에서 추정 가능하다.
* 사용자가 잊을 수 있다.
* 표기 방식이 달라질 수 있다.
* 공격자가 사회공학으로 알아낼 수 있다.

NIST는 비밀번호 선택 과정에서 지식 기반 인증이나 보안 질문을 요구하지 말라고 설명한다.<ref name="nist-800-63b" /> 보안 질문은 편리해 보이지만, 실제로는 약한 비밀번호 하나를 더 만드는 것과 비슷할 수 있다.

== 공용 기기에서의 비밀번호 ==
공용 기기에서는 중요한 계정 로그인을 피하는 것이 좋다. 불가피하게 사용해야 한다면 다음을 지킨다.

* 자동 로그인 체크 해제
* 비밀번호 저장 거부
* 사용 후 로그아웃
* 브라우저 기록과 쿠키 삭제
* 2차 인증 알림 확인
* 로그인 후 계정의 활성 세션 확인
* 가능하면 일회성 코드나 제한된 권한의 계정 사용

PC방, 학교 공용 PC, 도서관 PC, 회사 공용 장비는 키로거, 브라우저 확장 프로그램, 세션 탈취 위험이 있을 수 있다. 특히 관리자 권한이 없는 환경에서는 사용자가 보안 상태를 완전히 확인하기 어렵다.

== 모바일 기기와 비밀번호 ==
스마트폰은 비밀번호 관리의 중심이 되었다. 인증 앱, 패스키, SMS, 이메일, 비밀번호 관리자, 생체 인증이 모두 스마트폰에 몰려 있는 경우가 많다. 따라서 스마트폰 자체의 보안이 중요하다.

* 화면 잠금 설정
* 6자리 이상의 PIN 또는 강한 잠금 방식 사용
* 생체 인증 사용
* 운영체제 업데이트
* 출처 불명 APK 설치 금지
* 분실 시 원격 잠금과 초기화 설정
* 알림 내용 잠금화면 노출 제한
* SIM 스와핑 방지를 위한 통신사 보안 설정 확인

스마트폰 잠금 PIN이 너무 약하면, 비밀번호 관리자와 인증 앱까지 위험해질 수 있다. 000000, 123456, 생일, 전화번호 뒷자리 같은 값은 피해야 한다.

== 기업 환경에서의 비밀번호 ==
기업 환경에서는 개인의 실수 하나가 조직 전체의 사고로 이어질 수 있다. 따라서 기업은 단순히 "비밀번호를 복잡하게 하라"고 교육하는 수준을 넘어 구조적 대책을 마련해야 한다.

=== 권장 정책 ===

* SSO 도입
* MFA 의무화
* 관리자 계정 별도 관리
* 권한 최소화
* 퇴사자 계정 즉시 회수
* 공유 계정 최소화
* 조직용 비밀번호 관리자 제공
* 유출 비밀번호 탐지
* 크리덴셜 스터핑 방어
* 로그인 이상 징후 탐지
* 보안 키 또는 패스키 도입 검토
* 비밀번호 재설정 절차에 신원 확인 강화

=== 피해야 할 정책 ===

* 주기적 변경만 강제하고 MFA는 없는 정책
* 모든 직원에게 같은 초기 비밀번호 지급
* 부서 공유 계정을 장기간 사용
* 엑셀 파일에 비밀번호 목록 저장
* 메신저로 비밀번호 공유
* 퇴사자 계정 방치
* 관리자 계정과 일반 계정 동일 비밀번호 사용
* 장애 대응용 공용 최고권한 계정 상시 사용

기업 보안의 핵심은 "사용자가 완벽하게 행동할 것"을 기대하지 않는 것이다. 사용자가 실수해도 피해가 제한되도록 설계해야 한다.

== 비밀번호와 암호화 ==
비밀번호는 암호화와 관련이 깊지만, 같은 개념은 아니다.

비밀번호는 인증을 위한 비밀값이고, 암호화는 정보를 읽을 수 없게 변환하는 기술이다. 다만 비밀번호는 암호화 키를 보호하거나 생성하는 데 사용될 수 있다. 예를 들어 압축 파일 암호, 디스크 암호화 비밀번호, 암호화 지갑 시드 보호 비밀번호 등이 있다.

이 경우 비밀번호를 잊으면 복구가 불가능할 수 있다. 일반 웹사이트 비밀번호는 이메일로 재설정할 수 있지만, 로컬 암호화 파일이나 암호화폐 지갑은 서비스 운영자가 대신 복구해 줄 수 없는 경우가 많다.

따라서 암호화에 쓰이는 비밀번호는 다음 조건을 갖추어야 한다.

* 매우 길고 강해야 한다.
* 백업되어야 한다.
* 타인에게 노출되면 안 된다.
* 잊어버리면 어떤 일이 생기는지 이해해야 한다.
* 복구 문구와 함께 안전하게 보관해야 한다.

== 비밀번호와 생체 인증 ==
지문, 얼굴, 홍채 같은 생체 인증은 비밀번호보다 편리하다. 하지만 생체 인증은 보통 비밀번호를 완전히 대체한다기보다, 기기 내부의 비밀키나 저장된 인증 정보를 사용하기 위한 잠금 해제 수단으로 쓰인다.

생체 인증의 장점은 다음과 같다.

* 입력이 빠르다.
* 어깨너머 훔쳐보기에 강하다.
* 사용자가 외울 필요가 없다.
* 패스키와 결합하면 편리하고 강력하다.

단점도 있다.

* 유출되면 바꾸기 어렵다.
* 기기 성능과 센서 품질에 영향을 받는다.
* 법적·물리적 강제 상황에 대한 논의가 있다.
* 상처, 마스크, 조명, 습기 등 환경 영향을 받을 수 있다.

그래서 생체 인증을 쓰더라도 기기의 PIN이나 패스프레이즈는 강하게 설정해야 한다. 생체 인증 실패 시 PIN으로 풀 수 있다면, 실제 보안 수준은 결국 PIN에도 의존한다.

== 비밀번호에 대한 오해 ==
=== 특수문자를 넣으면 무조건 안전하다 ===
아니다. "Password1!"처럼 특수문자가 있어도 흔한 패턴이면 약하다. 특수문자 자체보다 길이, 무작위성, 고유성이 중요하다.

=== 자주 바꾸면 무조건 안전하다 ===
아니다. 유출이나 침해 근거가 있을 때 바꾸는 것은 중요하지만, 이유 없이 자주 바꾸게 하면 사용자가 예측 가능한 변형을 만들 가능성이 커진다.

=== 비밀번호 관리자는 위험하니 쓰면 안 된다 ===
비밀번호 관리자는 하나의 중요한 보관소가 되므로 신중히 써야 한다. 그러나 사람이 수십 개의 강한 고유 비밀번호를 외우는 것은 현실적으로 어렵다. 검증된 비밀번호 관리자를 강한 마스터 비밀번호와 MFA로 보호하는 편이 재사용보다 훨씬 낫다.

=== 2차 인증을 켰으니 비밀번호는 약해도 된다 ===
아니다. 다중 인증은 강력한 추가 방어선이지만, 약한 비밀번호를 정당화하지 않는다. 특히 SMS나 푸시 인증은 우회 가능성이 있으므로 기본 비밀번호도 강해야 한다.

=== 내 계정은 털릴 가치가 없다 ===
아니다. 공격자는 반드시 유명인이나 부자만 노리지 않는다. 일반 계정도 스팸 발송, 사기, 게임 아이템 탈취, 클라우드 자료 접근, 지인 대상 피싱, 다른 계정 복구에 악용될 수 있다.

=== 비밀번호를 종이에 적으면 무조건 나쁘다 ===
상황에 따라 다르다. 모니터에 붙여 두는 것은 위험하지만, 비밀번호 관리자 복구 코드나 마스터 패스프레이즈 힌트를 봉투에 넣어 금고에 보관하는 것은 합리적인 백업 전략일 수 있다. 온라인에 평문으로 저장하는 것보다 물리적으로 안전한 오프라인 보관이 나을 때도 있다.

== 실전 예시 ==
=== 매우 나쁜 예 ===

* 12345678
* qwer1234
* password
* 이름+생일
* 전화번호 뒷자리
* 회사명2026!
* 서비스명+느낌표

=== 그나마 나아 보이지만 여전히 위험한 예 ===

* P@ssw0rd2026!
* Seoul1234!
* MyName!1999
* Github!2026
* Dragon_Fire_01

이런 비밀번호는 복잡해 보이지만, 사람의 흔한 패턴을 따른다.

=== 좋은 방향 ===

* 비밀번호 관리자가 생성한 20자 이상의 무작위 비밀번호
* 계정마다 완전히 다른 비밀번호
* 직접 외워야 하는 경우에는 길고 무작위적인 패스프레이즈
* 중요한 계정에는 MFA 또는 패스키 사용

직접 외워야 하는 비밀번호라면, 여러 개의 무작위 단어를 조합한 긴 패스프레이즈가 현실적인 선택이 될 수 있다. 다만 유명 문장, 가사, 작품 대사, 자기소개 문장은 피해야 한다.

== 비밀번호 점검 체크리스트 ==
다음 항목에 하나라도 해당하면 비밀번호 관리 방식을 개선할 필요가 있다.

{| class="wikitable"
! 점검 항목 !! 위험도
|-
| 여러 사이트에서 같은 비밀번호를 쓴다 || 매우 높음
|-
| 이메일 계정 비밀번호를 다른 곳에서도 쓴다 || 매우 높음
|-
| 비밀번호가 10자 미만이다 || 높음
|-
| 이름, 생일, 전화번호가 들어간다 || 높음
|-
| 서비스 이름이 들어간다 || 높음
|-
| 매년 숫자만 바꾼다 || 높음
|-
| 비밀번호를 메모장 파일에 저장한다 || 높음
|-
| 비밀번호를 메신저에 보내 두었다 || 높음
|-
| MFA를 전혀 쓰지 않는다 || 중간 이상
|-
| 비밀번호 관리자를 쓰지 않는다 || 계정 수가 많을수록 위험
|-
| 복구 이메일이 오래된 계정이다 || 중간 이상
|-
| 로그인 알림을 확인하지 않는다 || 중간
|}

== 권장 우선순위 ==
비밀번호 보안을 한 번에 완벽하게 바꾸기는 어렵다. 다음 순서로 개선하면 현실적이다.

# 이메일 계정 비밀번호를 강하고 고유하게 바꾼다.
# 이메일 계정에 MFA를 켠다.
# 비밀번호 관리자를 설치한다.
# 금융, 클라우드, SNS, 쇼핑몰, 게임 계정 순서로 고유 비밀번호를 설정한다.
# 재사용된 비밀번호를 모두 제거한다.
# 중요한 계정에 MFA 또는 패스키를 켠다.
# 복구 이메일과 전화번호를 최신 상태로 정리한다.
# 사용하지 않는 계정을 삭제하거나 잠근다.
# 유출 알림과 로그인 알림을 확인한다.

이 순서에서 이메일 계정이 가장 앞에 오는 이유는 간단하다. 대부분의 계정 복구가 이메일을 통해 이루어지기 때문이다. 이메일이 털리면 다른 계정의 비밀번호 재설정도 공격자에게 넘어갈 수 있다.

== 관련 개념 ==
=== 인증 ===
'''인증'''은 사용자가 누구인지 확인하는 절차다. 비밀번호는 인증 수단 중 하나다.

=== 인가 ===
'''인가'''는 인증된 사용자가 무엇을 할 수 있는지 결정하는 절차다. 로그인에 성공했다고 해서 모든 권한을 가져서는 안 된다.

=== 세션 ===
'''세션'''은 로그인 후 사용자의 인증 상태를 유지하는 방식이다. 세션 쿠키가 탈취되면 비밀번호를 몰라도 로그인된 것처럼 행동할 수 있으므로 세션 보안도 중요하다.

=== 토큰 ===
'''토큰'''은 인증이나 API 접근에 사용되는 문자열이다. API 키, 액세스 토큰, 리프레시 토큰 등이 있다. 토큰은 비밀번호와 비슷하게 취급해야 하며, 코드 저장소나 로그에 노출되면 안 된다.

=== OTP ===
'''OTP'''는 일회용 비밀번호다. 한 번만 쓰거나 짧은 시간 동안만 유효하다. 비밀번호의 보조 수단으로 많이 사용된다.

=== 패스키 ===
'''패스키'''는 공개키 기반의 비밀번호 없는 인증 방식이다. 피싱 저항성이 강하고 사용성이 좋아 차세대 로그인 방식으로 주목받고 있다.

== 한계 ==
비밀번호의 근본적인 한계는 다음과 같다.

* 사용자가 기억해야 한다.
* 사용자가 속으면 직접 입력할 수 있다.
* 재사용되기 쉽다.
* 유출되면 다른 곳에도 악용될 수 있다.
* 서비스가 잘못 저장하면 대량 피해가 발생한다.
* 강한 비밀번호를 요구할수록 사용성이 나빠질 수 있다.
* 복구 절차가 약하면 우회될 수 있다.

따라서 현대 보안은 비밀번호 하나에 모든 것을 의존하지 않는 방향으로 가고 있다. 비밀번호 관리자, 다중 인증, 패스키, 보안 키, 이상 로그인 탐지, 세션 보호, 권한 최소화가 함께 필요하다.

== 결론 ==
비밀번호는 낡았지만 여전히 중요하다. 가장 안전한 방향은 "사람이 모든 비밀번호를 외우는 것"이 아니라, '''비밀번호 관리자를 사용하여 계정마다 길고 무작위인 고유 비밀번호를 만들고, 중요한 계정에는 다중 인증이나 패스키를 적용하는 것'''이다.

비밀번호 보안의 핵심은 복잡한 규칙을 억지로 외우는 것이 아니다. 핵심은 다음 네 가지다.

# 길게 만든다.
# 무작위로 만든다.
# 재사용하지 않는다.
# 혼자 쓰지 말고 MFA 또는 패스키와 함께 쓴다.

비밀번호는 자물쇠라기보다 열쇠에 가깝다. 같은 열쇠로 집, 차, 회사, 금고, 사물함을 모두 여는 사람은 없다. 디지털 세계에서도 마찬가지다. 계정마다 다른 열쇠를 쓰고, 중요한 문에는 보조 잠금장치를 더해야 한다.

== 같이 보기 ==

* [[인증]]
* [[다중 인증]]
* [[OTP]]
* [[패스키]]
* [[피싱]]
* [[사회공학]]
* [[암호화]]
* [[해시 함수]]
* [[정보보안]]
* [[계정 탈취]]
* [[크리덴셜 스터핑]]

== 각주 ==
<references />

[[분류:정보보안]]
[[분류:인증]]
[[분류:암호]]
[[분류:인터넷]]
[[분류:컴퓨터 보안]]

SemVer

2026-06-18T01:52:11Z

Gaon12: 문서 내용 보강

[[파일:SemanticVersioning.png|섬네일|유의적 버전의 기본 구조]]

== 개요 ==
'''유의적 버전''' 또는 '''시맨틱 버전'''({{llang|en|Semantic Versioning}}, '''SemVer''')은 [[소프트웨어]]의 [[버전]] 번호에 일정한 의미를 부여하여, 배포판 사이의 변경 범위와 [[하위 호환성]] 여부를 표현하는 버전 표기 규칙이다.<ref name="semver-ko">[https://semver.org/lang/ko/ 유의적 버전 2.0.0], Semantic Versioning 공식 한국어 문서.</ref>

기본 형식은 '''MAJOR.MINOR.PATCH'''이며, 한국어 공식 문서에서는 이를 각각 '''주 버전''', '''부 버전''', '''수 버전'''으로 번역한다.<ref name="semver-ko" /> 예를 들어 '''2.4.1'''이라는 버전은 주 버전이 2, 부 버전이 4, 수 버전이 1이라는 뜻이다.

유의적 버전의 목적은 단순히 버전을 보기 좋게 표시하는 것이 아니라, 버전 번호만으로도 어느 정도의 [[API]] 변경이 있었는지 알 수 있게 하는 데 있다. 일반적으로 주 버전이 바뀌면 기존 코드와 호환되지 않는 변경이 있었을 가능성이 높고, 부 버전이 바뀌면 기존 코드와 호환되는 기능 추가가 있었음을 뜻하며, 수 버전이 바뀌면 기존 코드와 호환되는 [[버그]] 수정이 있었음을 뜻한다.

다만 유의적 버전이 의미를 가지려면 해당 소프트웨어가 먼저 명확한 '''공개 API'''를 선언해야 한다.<ref name="semver-en">[https://semver.org/ Semantic Versioning 2.0.0], Semantic Versioning 공식 문서.</ref> 여기서 공개 API는 외부 사용자가 의존할 수 있는 함수, 클래스, 명령어, 설정 형식, 데이터 형식, 프로토콜, 문서화된 동작 등을 포함할 수 있다. 공개 API가 명확하지 않으면 어떤 변경이 호환성을 깨뜨리는 변경인지 판단하기 어렵다.

== 구성 ==
[[파일:Semantic-versioning.svg|섬네일|MAJOR.MINOR.PATCH 형식의 예시]]

유의적 버전은 기본적으로 주 버전, 부 버전, 수 버전의 세 부분으로 구성된다. 여기에 필요에 따라 선행 배포 버전과 빌드 메타데이터를 덧붙일 수 있다.

{| class="wikitable"
! 구성 요소 !! 형식상의 위치 !! 의미 !! 증가 또는 사용 조건
|-
| 주 버전 || MAJOR || 기존 공개 API와 호환되지 않는 변경 || 하위 호환성을 깨뜨리는 변경이 공개 API에 포함될 때 증가
|-
| 부 버전 || MINOR || 기존 공개 API와 호환되는 기능 추가 || 하위 호환성을 유지하면서 기능을 추가하거나 공개 API 일부를 폐기 예정으로 표시할 때 증가
|-
| 수 버전 || PATCH || 기존 공개 API와 호환되는 버그 수정 || 잘못된 동작을 고치되 공개 API 호환성을 유지할 때 증가
|-
| 선행 배포 버전 || -alpha, -beta.1, -rc.1 등 || 정식 배포 전 버전 || 아직 안정판이 아니거나 호환성 요구사항이 완전히 보장되지 않을 수 있음을 나타낼 때 사용
|-
| 빌드 메타데이터 || +build.1, +exp.sha 등 || 빌드 식별 정보 || 빌드 번호, 커밋 해시, 빌드 날짜 등 버전 우선순위에 영향을 주지 않는 정보를 표시할 때 사용
|}

== 형식 ==
유의적 버전의 일반적인 형식은 다음과 같다.

<syntaxhighlight lang="text">
MAJOR.MINOR.PATCH
MAJOR.MINOR.PATCH-PRERELEASE
MAJOR.MINOR.PATCH+BUILD
MAJOR.MINOR.PATCH-PRERELEASE+BUILD
</syntaxhighlight>

예시는 다음과 같다.

{| class="wikitable"
! 버전 !! 설명
|-
| 1.0.0 || 가장 기본적인 정식 버전 형식
|-
| 1.2.3 || 주 버전 1, 부 버전 2, 수 버전 3
|-
| 2.0.0 || 주 버전이 증가한 버전으로, 기존 공개 API와 호환되지 않는 변경이 포함되었을 수 있음
|-
| 1.4.0 || 부 버전이 증가한 버전으로, 기존 공개 API와 호환되는 기능 추가가 있었음을 뜻함
|-
| 1.4.1 || 수 버전이 증가한 버전으로, 기존 공개 API와 호환되는 버그 수정이 있었음을 뜻함
|-
| 2.3.7-beta.3 || 2.3.7 정식 배포 이전의 세 번째 베타 계열 선행 배포 버전
|-
| 1.0.0+20130313144700 || 빌드 메타데이터가 포함된 버전
|-
| 1.0.0-alpha+001 || 선행 배포 버전과 빌드 메타데이터가 모두 포함된 버전
|}

== 버전 증가 규칙 ==
=== 주 버전 ===
'''주 버전'''({{llang|en|major version}})은 기존 공개 API와 호환되지 않는 변경이 발생했을 때 증가한다. 예를 들어 함수 이름이 바뀌거나, 기존 매개변수의 의미가 달라지거나, 기존에 동작하던 사용 방식이 더 이상 지원되지 않는다면 주 버전을 올리는 것이 원칙이다.

주 버전이 증가하면 부 버전과 수 버전은 0으로 초기화한다. 예를 들어 '''1.8.5'''에서 호환되지 않는 변경이 발생했다면 다음 버전은 일반적으로 '''2.0.0'''이 된다.

[[파이썬]]의 [[파이썬 2]]와 [[파이썬 3]]의 관계는 주 버전 변화가 호환성에 큰 영향을 줄 수 있음을 보여 주는 대표적인 사례로 자주 언급된다. 파이썬 2에서 작성된 코드가 파이썬 3에서 그대로 동작하지 않는 경우가 많았기 때문에, 사용자는 주 버전 변화에 맞추어 코드를 수정해야 했다.

=== 부 버전 ===
'''부 버전'''({{llang|en|minor version}})은 기존 공개 API와 하위 호환성을 유지하면서 새로운 기능을 추가할 때 증가한다. 또한 공개 API의 일부를 앞으로 제거할 예정으로 표시하는 경우에도 부 버전을 올리는 것이 원칙이다.<ref name="semver-ko" />

부 버전이 증가하면 수 버전은 0으로 초기화한다. 예를 들어 '''1.4.3'''에서 하위 호환성을 유지하는 기능이 추가되었다면 다음 버전은 일반적으로 '''1.5.0'''이 된다.

부 버전 증가가 반드시 아무 위험도 없다는 뜻은 아니다. 새 기능이 기존 코드와 호환되도록 설계되었더라도, 실제 사용 환경에서는 의존성, 설정, 보안 정책, 폐기 예정 기능 등의 영향으로 추가 확인이 필요할 수 있다.

=== 수 버전 ===
'''수 버전'''({{llang|en|patch version}})은 기존 공개 API와 하위 호환성을 유지하면서 버그를 수정할 때 증가한다. 예를 들어 '''1.5.0'''에서 내부 오류를 수정했지만 공개 API의 사용 방식은 그대로 유지된다면 다음 버전은 일반적으로 '''1.5.1'''이 된다.

수 버전만 증가한 경우에는 보통 기존 코드를 수정할 필요가 없다. 다만 기존 코드가 버그에 의존하고 있었거나, 수정된 동작이 실제 운영 환경의 결과에 영향을 주는 경우에는 예외적으로 코드나 설정을 조정해야 할 수 있다.

== 초기 개발 버전과 1.0.0 ==
주 버전이 0인 '''0.y.z''' 형식은 초기 개발 단계를 나타낸다. 이 단계에서는 공개 API가 안정적이라고 간주되지 않으며, 언제든 호환되지 않는 변경이 발생할 수 있다.<ref name="semver-ko" />

'''1.0.0'''은 공개 API가 정의된 첫 안정판으로 볼 수 있다. 이후 버전 번호는 1.0.0에서 정의한 공개 API가 어떻게 바뀌는지에 따라 증가한다.

{| class="wikitable"
! 버전 범위 !! 일반적인 의미
|-
| 0.y.z || 초기 개발 단계. 공개 API가 안정적이라고 보기 어려움
|-
| 1.0.0 || 공개 API가 정의된 첫 안정판
|-
| 1.x.y 이상 || 정의된 공개 API를 기준으로 호환성 규칙을 적용하는 단계
|}

== 선행 배포 버전 ==
'''선행 배포 버전'''({{llang|en|pre-release version}})은 정식 배포 이전의 알파, 베타, 릴리스 후보 등을 표시할 때 사용한다. 수 버전 뒤에 붙임표(-)를 붙이고, 마침표(.)로 구분된 식별자를 덧붙인다.

예시는 다음과 같다.

{| class="wikitable"
! 선행 배포 버전 !! 일반적인 의미
|-
| 1.0.0-alpha || 초기 시험용 알파 버전
|-
| 1.0.0-alpha.1 || 첫 번째 알파 계열 세부 버전
|-
| 1.0.0-beta || 베타 버전
|-
| 1.0.0-beta.2 || 두 번째 베타 계열 세부 버전
|-
| 1.0.0-rc.1 || 첫 번째 릴리스 후보 버전
|}

선행 배포 버전은 같은 주·부·수 버전의 정식 버전보다 우선순위가 낮다. 예를 들어 '''2.3.7-beta.3'''은 '''2.3.7'''보다 낮은 버전으로 취급된다.

== 빌드 메타데이터 ==
'''빌드 메타데이터'''({{llang|en|build metadata}})는 더하기(+) 기호 뒤에 덧붙이는 부가 정보이다. 빌드 번호, 빌드 날짜, [[커밋 해시]], 빌드 환경 등을 표시하는 데 사용할 수 있다.

예시는 다음과 같다.

{| class="wikitable"
! 버전 !! 설명
|-
| 1.0.0+001 || 빌드 번호가 포함된 버전
|-
| 1.0.0+20130313144700 || 빌드 시각 또는 날짜 형식의 메타데이터가 포함된 버전
|-
| 1.0.0-beta+exp.sha.5114f85 || 선행 배포 버전과 빌드 메타데이터가 함께 포함된 버전
|}

빌드 메타데이터는 버전 우선순위 비교에서 무시된다. 따라서 주·부·수 버전과 선행 배포 버전이 같고 빌드 메타데이터만 다른 경우, 두 버전의 우선순위는 같다.

== 버전 우선순위 ==
유의적 버전에서는 버전의 우선순위를 비교할 때 주 버전, 부 버전, 수 버전, 선행 배포 버전 순서로 비교한다. 빌드 메타데이터는 우선순위 비교에 영향을 주지 않는다.

{| class="wikitable"
! 비교 예시 !! 결과 !! 이유
|-
| 1.0.0 < 2.0.0 || 참 || 주 버전 2가 주 버전 1보다 크기 때문
|-
| 2.0.0 < 2.1.0 || 참 || 부 버전 1이 부 버전 0보다 크기 때문
|-
| 2.1.0 < 2.1.1 || 참 || 수 버전 1이 수 버전 0보다 크기 때문
|-
| 1.0.0-alpha < 1.0.0 || 참 || 선행 배포 버전은 같은 버전의 정식 버전보다 낮기 때문
|-
| 1.0.0-alpha < 1.0.0-alpha.1 || 참 || 앞선 식별자가 같을 때 더 많은 선행 배포 식별자를 가진 쪽이 더 높게 비교될 수 있기 때문
|-
| 1.0.0+001 = 1.0.0+20130313144700 || 우선순위상 같음 || 빌드 메타데이터는 우선순위 비교에서 무시되기 때문
|}

공식 명세에서 제시하는 선행 배포 버전의 우선순위 예시는 다음과 같다.<ref name="semver-en" />

<syntaxhighlight lang="text">
1.0.0-alpha
< 1.0.0-alpha.1
< 1.0.0-alpha.beta
< 1.0.0-beta
< 1.0.0-beta.2
< 1.0.0-beta.11
< 1.0.0-rc.1
< 1.0.0
</syntaxhighlight>

== 장점 ==
유의적 버전의 장점은 다음과 같다.

* 버전 번호만 보아도 변경 범위를 대략적으로 파악할 수 있다.
* [[라이브러리]]나 [[패키지 관리자]]가 의존성 범위를 판단하기 쉽다.
* 하위 호환성 유지 여부를 사용자에게 명확하게 전달할 수 있다.
* 배포 정책을 문서화하기 쉬우며, 팀 내부와 외부 사용자 사이의 의사소통 비용을 줄일 수 있다.
* 자동 업데이트, 의존성 검사, 배포 자동화 도구와 함께 쓰기 쉽다.

== 한계와 주의점 ==
유의적 버전은 모든 문제를 자동으로 해결하는 규칙은 아니다. 다음과 같은 점에 주의해야 한다.

* 공개 API가 명확하게 정의되어 있지 않으면 버전 번호의 의미가 약해진다.
* 개발자가 규칙을 잘못 적용하면 버전 번호와 실제 변경 내용이 일치하지 않을 수 있다.
* 응용 프로그램의 사용자 인터페이스 변경, 데이터 파일 형식 변경, 운영 환경 변경 등은 API 변경과 다르게 판단될 수 있다.
* 보안 문제나 긴급 패치의 경우, 기존 정책과 별도의 배포 판단이 필요할 수 있다.
* 생태계마다 버전 범위 해석 방식이 다를 수 있으므로, 실제 의존성 지정 방식은 사용하는 패키지 관리자 문서를 함께 확인해야 한다.

== 예시 ==
=== 하위 호환되는 버그 수정 ===
기존 버전이 '''1.2.3'''이고, 공개 API는 그대로 유지하면서 내부 버그만 수정했다면 다음 버전은 일반적으로 다음과 같이 증가한다.

<syntaxhighlight lang="text">
1.2.3 -> 1.2.4
</syntaxhighlight>

=== 하위 호환되는 기능 추가 ===
기존 버전이 '''1.2.3'''이고, 기존 API와 호환되는 새 기능을 추가했다면 다음 버전은 일반적으로 다음과 같이 증가한다.

<syntaxhighlight lang="text">
1.2.3 -> 1.3.0
</syntaxhighlight>

=== 하위 호환되지 않는 변경 ===
기존 버전이 '''1.2.3'''이고, 공개 API의 사용 방식이 바뀌어 기존 코드가 수정 없이 동작하지 않을 수 있다면 다음 버전은 일반적으로 다음과 같이 증가한다.

<syntaxhighlight lang="text">
1.2.3 -> 2.0.0
</syntaxhighlight>

=== 정식 배포 전 버전 ===
'''2.0.0''' 정식 배포 전 테스트 버전을 배포하려면 다음과 같은 형식을 사용할 수 있다.

<syntaxhighlight lang="text">
2.0.0-alpha
2.0.0-beta.1
2.0.0-rc.1
</syntaxhighlight>

== 같이 보기 ==

* [[버전]]
* [[버전 관리]]
* [[소프트웨어 버전 작성]]
* [[하위 호환성]]
* [[API]]
* [[패키지 관리자]]
* [[의존성 지옥]]
* [[소프트웨어 배포]]
* [[파이썬]]

== 외부 링크 ==

* [https://semver.org/ Semantic Versioning 공식 사이트]
* [https://semver.org/lang/ko/ 유의적 버전 공식 한국어 문서]
* [https://semver.org/spec/v2.0.0.html Semantic Versioning 2.0.0 명세]

== 각주 ==
<references />

[[분류:버전 표기법]]
[[분류:소프트웨어 공학]]
[[분류:소프트웨어 배포]]

Llms.txt

2026-06-18T01:03:26Z

Gaon12: 시작

[[분류:인터넷 표준]][[분류:인공지능]][[분류:웹 기술]][[분류:생성형 AI]][[분류:GEO]]

== 개요 ==

'''llms.txt'''는 웹사이트 루트 디렉토리에 배치하는 [[마크다운]] 형식의 텍스트 파일로, 웹사이트 소유자가 [[대규모 언어 모델]](LLM)에게 자신의 사이트에서 어떤 콘텐츠가 중요한지, 어디에 있는지를 안내하기 위해 만들어진 '''비공식 표준'''이다. 파일 이름은 반드시 <code>llms.txt</code>이어야 하며, 도메인 루트(예: <code>https://example.com/llms.txt</code>)에 위치해야 한다.

한 줄로 요약하면 '''"AI를 위한 robots.txt"''' 정도로 이해하면 된다. [[검색엔진]]을 위한 [[robots.txt]]가 크롤러에게 어떤 페이지를 긁어가도 되는지 알려주는 파일이라면, llms.txt는 [[ChatGPT]], [[Claude]], [[Perplexity]] 같은 AI 어시스턴트에게 "우리 사이트에서 이 페이지들이 제일 중요해요"라고 알려주는 파일이다.

2024년 9월 3일, [[Answer.AI]]의 공동 창업자이자 [[fast.ai]]로 유명한 '''제레미 하워드(Jeremy Howard)'''가 처음 제안했으며, 공식 명세는 '''[https://llmstxt.org llmstxt.org]'''에서 관리된다. 현재(2026년 기준)는 [[W3C]], [[IETF]] 등의 공식 표준화 기구를 통해 채택된 정식 표준은 아니며, 커뮤니티 주도의 사실상 표준(de facto standard) 수준이다.

{{참고|비슷한 이름으로 혼동하기 쉬운 파일들이 있다. <code>llm.txt</code>(복수형 아님), <code>ai.txt</code>, <code>aillms.txt</code> 등은 llms.txt와 다른 파일이므로 주의할 것.}}

== 등장 배경 ==

=== AI와 웹의 충돌 ===

현대의 웹사이트는 사람이 보기 좋게 만들어져 있다. [[HTML]], [[CSS]], [[JavaScript]]가 뒤엉켜 있고, 광고 배너, 내비게이션 메뉴, 쿠키 동의창, 소셜 공유 버튼, 사이트맵 링크 등 '''실제 콘텐츠와 무관한 요소들'''이 페이지의 상당 부분을 차지한다. 사람은 이걸 눈으로 걸러낼 수 있지만, [[LLM]]은 그렇지 못하다.

[[대규모 언어 모델]]이 특정 웹페이지의 내용을 참고하여 답변을 생성할 때(일명 [[RAG|검색 증강 생성, RAG]]), 모델은 해당 페이지의 HTML 전체를 읽어야 한다. 이 과정에서 몇 가지 심각한 문제가 발생한다.

# '''노이즈 문제''' : 실제 필요한 정보가 HTML 태그, 광고, 메뉴, 푸터 등의 쓸모없는 텍스트에 묻혀버린다.
# '''컨텍스트 창 낭비''' : LLM의 [[컨텍스트 창|컨텍스트 윈도우(context window)]]는 유한하다. 쓸모없는 내용으로 공간을 낭비하면 정작 중요한 정보를 담을 공간이 줄어든다.
# '''탐색 불가 문제''' : 수천 페이지짜리 문서 사이트에서 AI가 어떤 페이지가 중요한지 알 방법이 없다. 사이트맵(sitemap.xml)은 모든 URL을 나열할 뿐, 어떤 페이지가 가장 중요한지 알려주지 않는다.
# '''JavaScript 렌더링 문제''' : SPA([[싱글 페이지 애플리케이션]]) 등 JS로 렌더링되는 콘텐츠는 AI 크롤러가 아예 읽지 못하는 경우가 많다.

=== 기존 표준의 한계 ===

{| class="wikitable"
|+ '''기존 웹 표준과 llms.txt의 비교'''
|-
! style="background:#3c5a9a;color:white;width:15%" | 파일
! style="background:#3c5a9a;color:white;width:20%" | 대상
! style="background:#3c5a9a;color:white;width:30%" | 역할
! style="background:#3c5a9a;color:white;width:35%" | 한계
|-
| <code>'''robots.txt'''</code>
| 검색엔진 크롤러
| 크롤링 허용/차단 URL 지정
| 어떤 페이지가 중요한지, 콘텐츠가 무엇인지 설명 불가
|-
| <code>'''sitemap.xml'''</code>
| 검색엔진
| 전체 URL 목록 제공
| 우선순위 정보가 제한적, 콘텐츠 맥락 없음
|-
| '''schema.org'''
| 검색엔진(구조화 데이터)
| 페이지 내 구조화 데이터 마크업
| 개별 페이지 단위, 사이트 전체 맥락 제공 불가
|-
| <code>'''llms.txt'''</code>
| AI 어시스턴트 / LLM
| 중요 페이지 큐레이션 + 사이트 설명
| 공식 표준 아님, AI 크롤러 지원 아직 초기 단계
|}

제레미 하워드는 이 문제를 인식하고, '''AI 시대에 맞는 새로운 웹 표준'''이 필요하다는 결론을 내렸다. 마치 1994년에 [[마르틴 코스터(Martijn Koster)]]가 검색엔진 크롤러를 위한 robots.txt를 만들었듯이, AI를 위한 유사한 파일이 필요하다는 것이었다.

=== 제안의 역사 ===

{| class="wikitable"
|+ '''llms.txt 주요 연혁'''
|-
! style="background:#3c5a9a;color:white;" | 날짜
! style="background:#3c5a9a;color:white;" | 사건
|-
| 2024년 9월 3일
| 제레미 하워드, llms.txt 표준 최초 제안. llmstxt.org 공개
|-
| 2024년 11월
| [[Mintlify]], 호스팅하는 모든 문서 사이트에 llms.txt 자동 생성 기능 롤아웃. 사실상 하룻밤 사이에 Anthropic, Cursor, Coinbase, Pinecone 등 수천 개 사이트가 llms.txt를 갖게 됨
|-
| 2024년 말
| Anthropic, Claude 문서에 llms.txt 도입. llms.txt 지원 공식 확인
|-
| 2025년 초
| Stripe, Cloudflare, Vercel, Supabase, Zapier, Hugging Face 등 주요 개발자 플랫폼 잇달아 도입
|-
| 2025년 7월
| Google의 게리 일스(Gary Illyes), llms.txt를 공식 지원하지 않는다고 확인. 존 뮬러(John Mueller)는 폐기된 키워드 메타 태그에 비유해 논란
|-
| 2025년 11월
| SE Ranking, 30만 도메인 분석 결과 발표. llms.txt 보유 여부와 AI 인용 상관관계 측정 불가 판정
|-
| 2026년 Q1
| 전체 도메인 기준 약 10% 수준 채택률 기록. 주류 SaaS, 퍼블리싱으로 확대
|-
| 2026년 5월 7일
| 크롬 라이트하우스(Lighthouse) 13.3, llms.txt 존재 여부를 감사(audit) 항목에 추가
|-
| 2026년 6월 (현재)
| 약 844,000개 이상 웹사이트 도입. IDE 에이전트(Cursor, Claude Code 등)에서 실질적 활용 증가세
|}

== 파일 형식 및 문법 ==

=== 기본 구조 ===

llms.txt는 '''[[마크다운(Markdown)]]''' 형식으로 작성되며, 구조는 다음과 같은 순서를 따른다. 마크다운을 선택한 이유는 LLM이 기본적으로 마크다운을 잘 이해하기 때문이며, 별도의 파서나 스키마 없이도 처리 가능하다.

<syntaxhighlight lang="markdown">
# 사이트 또는 프로젝트 이름

> 한두 문장의 블록 인용구 형식 요약문. 제3자 시점으로, 에이전트가 읽기 좋게 작성.

선택적 부연 설명 단락. 브랜드명이 모호하거나 카테고리 맥락이 필요한 경우 작성.

## 섹션 이름

- [페이지 제목](https://example.com/page): 해당 페이지에 무엇이 있는지, 에이전트가 왜 이 페이지를 가져가야 하는지 한 문장 설명.
- [다른 페이지](https://example.com/another): 설명.

## 또 다른 섹션

- [페이지 제목](https://example.com/page): 설명.

## Optional

- [우선순위 낮은 페이지](https://example.com/extra): 컨텍스트가 부족할 경우 에이전트가 건너뛰어도 되는 페이지.
</syntaxhighlight>

=== 각 요소 상세 설명 ===

==== H1 헤더 (필수) ====

<code># 사이트명</code>

파일에서 '''유일하게 필수적인 요소'''다. 브랜드명 또는 프로젝트명을 그대로 사용한다. H1은 파일 전체에서 딱 하나만 있어야 한다.

==== 블록 인용구 요약 (강력 권장) ====

<code>> 요약문</code>

한두 문장으로 사이트/프로젝트가 무엇인지, 누구를 위한 것인지 설명한다. '''제3자 시점'''으로 쓰는 것이 좋다("우리 회사는~"보다 "X는 Y를 위한 Z이다" 형태). 에이전트가 URL을 실제로 방문하지 않고도 이 설명만으로 브랜드를 이해할 수 있어야 한다.

==== 부연 설명 단락 (선택) ====

H1과 블록 인용구 이후에 일반 단락으로 추가 맥락을 제공할 수 있다. 브랜드명이 Stripe, Anthropic처럼 카테고리를 유추하기 어려운 경우에 특히 유용하다. Tesla나 Coca-Cola처럼 누구나 아는 브랜드는 생략해도 된다.

==== H2 섹션 (선택) ====

<code>== 섹션명 ==</code>

콘텐츠를 논리적 그룹으로 묶는 역할을 한다. 예를 들어 "Getting Started", "API Reference", "Pricing", "Tutorials" 등. 중요한 점은 '''내부 문서 구조가 아니라 에이전트가 어떤 질문을 할 때 이 섹션이 필요한가'''의 관점에서 섹션을 나눠야 한다는 것이다(Anthropic의 경우 문서가 파일 구조로 정리되어 있지 않고 개발자가 어떤 도움이 필요한지를 기준으로 H2를 구성한다).

==== 링크 목록 (선택) ====

<code>- [페이지 제목](URL): 한 줄 설명</code>

각 링크에는 반드시 '''한 줄 설명'''을 붙이는 것이 좋다. 설명은 구체적일수록 좋다. 에이전트는 실제로 URL을 방문하지 않고도 설명만으로 판단해야 하는 경우가 많기 때문이다.

* 나쁜 예: <code>- [요금제](https://example.com/pricing): 가격 정보</code>
* 좋은 예: <code>- [요금제](https://example.com/pricing): Starter ($500/월), Growth ($2,000/월), Enterprise (맞춤) 상세 비교</code>

==== Optional 섹션 ====

<code>## Optional</code>

이 섹션은 '''특별한 의미를 갖는 예약어'''이다. 컨텍스트가 부족할 때 에이전트가 건너뛰어도 무방한 보조 자료들을 여기에 넣는다.

=== 실제 예시 ===

==== Stripe의 llms.txt ====

<syntaxhighlight lang="markdown">
# Stripe

> Stripe is a technology company that provides financial infrastructure for
> businesses. Businesses of every size—from new startups to established public
> companies—use Stripe to accept payments online and in person, embed financial
> services, and create custom revenue models.

For complete documentation in a single file, see [Full Documentation](https://stripe.com/llms-full.txt).

## Payments

- [Stripe Payments](https://stripe.com/payments): Accept payments online and
in person globally with a payments solution built for any business.

## Billing

- [Stripe Billing](https://stripe.com/billing): Automate billing and revenue
management.

## Optional

- [Stripe Climate](https://stripe.com/climate): Help businesses contribute to
carbon removal.
</syntaxhighlight>

==== FastHTML (제레미 하워드의 정석 예시) ====

<syntaxhighlight lang="markdown">
# FastHTML

> FastHTML is a python library which brings together Starlette,
> Uvicorn, HTMX, and fastcore's `FT` "FastTags" into a library
> for creating server-rendered hypermedia applications.

## Docs

- [FastHTML quick start](https://docs.fastht.ml/path/quickstart.html.md): A brief overview of many FastHTML features
- [HTMX reference](https://docs.fastht.ml/ref/defining_xt_component.html.md): How to use HTMX with FastHTML
</syntaxhighlight>

== llms.txt와 llms-full.txt ==

=== 두 파일의 차이 ===

공식 명세는 사실상 두 가지 파일을 정의한다.

{| class="wikitable"
|+ '''llms.txt vs llms-full.txt 비교'''
|-
! style="background:#3c5a9a;color:white;width:20%" | 항목
! style="background:#3c5a9a;color:white;width:40%" | llms.txt
! style="background:#3c5a9a;color:white;width:40%" | llms-full.txt
|-
| '''역할'''
| 내비게이션 가이드 (큐레이션된 링크 목록)
| 모든 콘텐츠를 단일 파일로 통합
|-
| '''크기'''
| 수백~수천 토큰 (가볍다)
| 수만~수백만 토큰 (무겁다)
|-
| '''용도'''
| AI가 어떤 페이지를 가져갈지 판단하는 인덱스
| AI가 모든 내용을 한 번에 읽을 수 있는 전체 문서
|-
| '''링크 추종'''
| 에이전트가 링크를 따라가서 개별 페이지를 읽음
| 링크를 따라갈 필요 없이 이 파일만 읽으면 됨
|-
| '''실제 용량 예시'''
| Anthropic: 약 8,364 토큰
| Anthropic: 약 481,349 토큰
|-
| '''Cloudflare 예시'''
| 일반 크기
| 370만 토큰 (!)
|-
| '''권장 대상'''
| 모든 사이트
| SaaS, 개발자 도구, API 문서 사이트
|}

=== llms-full.txt 주의사항 ===

llms-full.txt는 강력하지만 양날의 검이다.

* '''장점''' : 에이전트가 링크를 일일이 방문하지 않아도 전체 내용을 파악 가능. 토큰 효율적인 일괄 수집(bulk ingestion)이 가능.
* '''단점''' : 경쟁사나 AI 크롤러에게 사이트의 전체 콘텐츠를 한 번에 제공하는 셈. 독점적인 정보나 프리미엄 콘텐츠가 포함될 경우 리스크가 있다.

때문에 전문가들 사이에서는 '''llms.txt(내비게이션 파일)만 공개하고, llms-full.txt는 신중하게 판단하라'''는 의견이 많다.

=== .md 확장자 규칙 ===

Mintlify와 Anthropic이 협력하여 추가된 관련 규칙으로, 기존 URL에 <code>.md</code>를 붙이면 해당 페이지의 마크다운 버전을 반환하는 규칙이 있다. 예를 들어 <code>https://docs.example.com/quickstart.md</code>에 접근하면 HTML이 아닌 마크다운 형식으로 콘텐츠가 반환된다. 이 기능은 llms.txt 링크와 함께 사용하면 AI 에이전트가 더욱 깨끗한 형태로 콘텐츠를 수집할 수 있다.

== robots.txt, sitemap.xml과의 관계 ==

=== 상호보완 관계 ===

llms.txt가 등장했다고 해서 기존 파일들을 대체하는 것은 아니다. 세 파일은 서로 다른 역할을 가지며 함께 쓰인다. 도서관에 비유하면:

* '''robots.txt''' = "이 서가는 일반인 출입 금지" (접근 제어)
* '''sitemap.xml''' = 도서관 전체 도서 목록 (발견성)
* '''llms.txt''' = 사서가 추천하는 필독 도서 목록 (큐레이션)

=== robots.txt와 AI 크롤러 ===

robots.txt는 AI 크롤러를 직접 제어할 수 있는 현실적인 도구다. llms.txt가 "무엇을 읽어주면 좋겠어"라는 긍정적 안내라면, robots.txt는 "여기는 들어오지 마"라는 직접적인 규칙이다. 2026년 기준 주요 AI 크롤러 유저 에이전트(User-Agent)와 역할은 다음과 같다.

{| class="wikitable"
|+ '''주요 AI 크롤러 User-Agent 목록 (2026년 기준)'''
|-
! style="background:#3c5a9a;color:white;" | User-Agent
! style="background:#3c5a9a;color:white;" | 회사
! style="background:#3c5a9a;color:white;" | 용도
|-
| <code>GPTBot</code>
| OpenAI
| 학습 데이터 수집
|-
| <code>OAI-SearchBot</code>
| OpenAI
| ChatGPT 검색/인용 인덱싱
|-
| <code>ChatGPT-User</code>
| OpenAI
| 사용자 요청 시 실시간 페이지 방문
|-
| <code>ClaudeBot</code>
| Anthropic
| 학습 데이터 수집
|-
| <code>Claude-SearchBot</code>
| Anthropic
| Claude 검색 결과 인덱싱
|-
| <code>Claude-User</code>
| Anthropic
| 사용자 요청 시 실시간 페이지 방문
|-
| <code>PerplexityBot</code>
| Perplexity
| 검색 및 인용 인덱싱
|-
| <code>Google-Extended</code>
| Google
| Gemini 학습 데이터 수집
|-
| <code>Applebot-Extended</code>
| Apple
| Apple Intelligence 관련
|}

{{참고|robots.txt에서 AI 학습 차단, AI 검색 인용 허용을 분리하는 일반적인 정책 패턴은 다음과 같다.
<syntaxhighlight lang="text">
# OpenAI - 검색 허용, 학습 차단
User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

# Anthropic - 검색 허용, 학습 차단
User-agent: Claude-SearchBot
Allow: /

User-agent: ClaudeBot
Disallow: /
</syntaxhighlight>
}}

== 주요 도입 사례 ==

=== 얼리 어답터 현황 ===

2026년 현재 llms.txt를 도입한 주요 기업들은 다음과 같다. 대부분이 개발자 도구나 API 문서를 제공하는 테크 기업들이다. 이는 이들의 타겟 사용자인 개발자들이 AI 코딩 어시스턴트를 많이 쓰기 때문에 정확한 문서 인용이 곧 제품 지원의 질과 직결되기 때문이다.

{| class="wikitable"
|+ '''주요 llms.txt 도입 기업 (2026년 6월 기준)'''
|-
! style="background:#3c5a9a;color:white;" | 기업
! style="background:#3c5a9a;color:white;" | 분야
! style="background:#3c5a9a;color:white;" | llms.txt 규모
! style="background:#3c5a9a;color:white;" | 비고
|-
| '''[[Anthropic]]'''
| AI 회사
| ~8,364 토큰 / llms-full.txt ~481,349 토큰
| Mintlify와 협력하여 파일 구조 표준 정립에 기여
|-
| '''[[Stripe]]'''
| 결제 인프라
| 중간 규모
| Optional 섹션에 Stripe Climate 배치, 우선순위 구조 모범 사례
|-
| '''[[Cloudflare]]'''
| CDN/네트워크 보안
| 제품별 분리 구성 / llms-full.txt ~370만 토큰
| 제품군별로 분리하여 에이전트가 관련 제품만 선택 가능
|-
| '''[[Vercel]]'''
| 클라우드 플랫폼
| llms-full.txt ~40만 단어
| 다중 제품(Next.js, AI SDK 등) 구조화의 모범 사례
|-
| '''[[Cursor]]'''
| AI 코드 에디터
| 중간 규모
| IDE 에이전트로서 llms.txt를 직접 읽는 소비자이자 생산자
|-
| '''[[Mintlify]]'''
| 문서 플랫폼
| -
| 호스팅 사이트 전체에 자동 생성 지원, 표준 보급의 1등 공신
|-
| '''[[Supabase]]'''
| 오픈소스 백엔드
| -
| -
|-
| '''[[Zapier]]'''
| 자동화 플랫폼
| -
| -
|-
| '''[[Hugging Face]]'''
| AI 모델 허브
| -
| -
|-
| '''[[NVIDIA]]'''
| 반도체/AI
| 기술문서 ~1,259 토큰 / 메인 사이트 ~252,607 토큰
| 기술 문서와 마케팅 사이트 분리
|-
| '''[[OpenAI]]'''
| AI 회사
| -
| 아이러니하게도 GPTBot 등을 운영하면서 자신의 docs에도 llms.txt 도입
|-
| '''[[Mastercard]]'''
| 금융
| -
| 금융 업계 내 드문 조기 도입 사례
|-
| '''[[Microsoft]] Teams SDK'''
| 개발자 도구
| -
| AI 코딩 에이전트 라우팅 레이어로 활용
|}

=== 업종별 도입률 (2026년 Q1 기준) ===

{| class="wikitable" style="width:70%"
|+ '''업종별 top-100 도메인 기준 llms.txt 도입률'''
|-
! style="background:#3c5a9a;color:white;" | 업종
! style="background:#3c5a9a;color:white;" | 도입률
|-
| 개발자 도구 / AI 기업
| 매우 높음 (60~80%+)
|-
| 사이버보안
| 높음
|-
| 블록체인 / Web3
| 높음
|-
| SaaS (개발자 대상)
| 높음 (50%+)
|-
| 주류 SaaS
| 중간 (확장 중)
|-
| 퍼블리싱 / 미디어
| 낮음~중간
|-
| 금융 서비스
| 낮음 (10% 미만)
|-
| 헬스케어
| 낮음 (10% 미만)
|-
| 법률
| 매우 낮음
|-
| 전체 평균
| 약 10~15%
|}

{{참고|금융, 헬스케어, 법률 분야의 낮은 도입률은 기술적 무지보다는 '''법적·컴플라이언스 우려''' 때문인 경우가 많다. 어떤 정보를 AI에게 "공식적으로" 안내할 것인가에 대한 법무팀의 검토가 필요하기 때문이다.}}

== AI 플랫폼별 지원 현황 ==

=== 지원 현황 요약 ===

llms.txt의 가장 큰 논란은 "실제로 AI가 이걸 읽냐"는 것이다. 솔직히 말하면, 2026년 현재 대부분의 주요 LLM 크롤러는 llms.txt를 '''의미 있는 수준으로 활용하지 않는다'''. 그럼에도 불구하고 도입이 늘어나는 이유는 뒤에서 설명한다.

{| class="wikitable"
|+ '''AI 플랫폼별 llms.txt 지원 현황 (2026년 6월 기준)'''
|-
! style="background:#3c5a9a;color:white;width:20%" | 플랫폼
! style="background:#3c5a9a;color:white;width:80%" | 현황
|-
| '''Anthropic (Claude)'''
| 공식 지원 확인. Claude Desktop, Claude.ai 모두 검색 워크플로우에서 llms.txt 지시사항을 따름. Perplexity와 함께 가장 명확한 지지 입장.
|-
| '''Perplexity'''
| 공식 지원 확인. 잘 구성된 llms.txt 사이트에서 인용률 소폭 상승 관찰됨.
|-
| '''OpenAI (ChatGPT)'''
| 공식 약속 없음. GPTBot이 가끔 llms.txt를 방문하는 것이 로그에서 관찰됨. OAI-SearchBot은 거의 방문 안 함.
|-
| '''Google (Gemini)'''
| '''공식 거부'''. 2025년 7월 Gary Illyes가 지원 계획 없음 확인. John Mueller는 "키워드 메타 태그랑 비슷하다"며 회의적 입장. 단, Google의 A2A(에이전트 간) 프로토콜에 실험적으로 언급됨.
|-
| '''Meta (Llama)'''
| 공식 약속 없음.
|-
| '''Mistral'''
| 공식 약속 없음.
|-
| '''Cursor / Windsurf / Claude Code / GitHub Copilot / Cline / Aider'''
| '''적극적으로 활용'''. IDE 에이전트들이 문서 사이트를 가리킬 때 llms.txt를 먼저 찾아 관련 페이지만 가져오는 방식으로 활용. 실질적 효과가 가장 명확한 영역.
|-
| '''MCP(Model Context Protocol) 서버'''
| llms.txt 기반으로 구축되는 경우 증가 중.
|}

=== IDE 에이전트에서의 실질적 활용 ===

대형 LLM 서비스들이 llms.txt를 소홀히 하는 것과 달리, '''Cursor, Windsurf, Claude Code, GitHub Copilot, Cline, Aider 같은 AI 코딩 에이전트들은 실질적으로 llms.txt를 활용'''한다. 동작 방식은 다음과 같다:

# 개발자가 에이전트에게 특정 라이브러리나 API를 사용하는 코드 작성 요청
# 에이전트가 해당 라이브러리/서비스의 도메인에서 <code>/llms.txt</code>와 <code>/llms-full.txt</code>를 먼저 확인
# llms.txt의 링크 목록을 보고 관련 문서 페이지만 선택적으로 방문
# 필요한 정보만 컨텍스트 창에 넣어 코드 생성

이 덕분에 IDE 에이전트의 컨텍스트 낭비가 줄고, 더 정확한 코드를 생성할 수 있다. Mintlify의 실험 결과, 잘 구조화된 llms.txt가 있는 문서는 에이전트 성능이 '''64% 더 정확, 39% 더 높은 탐색성, 절반의 토큰 사용, 1.5배 빠른 속도'''를 보였다.

== GEO(생성 엔진 최적화)와의 관계 ==

=== GEO란? ===

'''GEO(Generative Engine Optimization, 생성 엔진 최적화)'''는 [[SEO(검색 엔진 최적화)]]처럼, 이번에는 구글이 아니라 ChatGPT, Claude, Perplexity, Gemini 같은 AI 응답 엔진에서 자신의 브랜드/콘텐츠가 인용되도록 최적화하는 것을 말한다. llms.txt는 GEO의 핵심 도구 중 하나로 등장했다.

=== AI 트래픽의 급성장 ===

* 어도비(Adobe) 2026년 3월 보고서에 따르면, AI 참조 트래픽(AI가 링크를 제공하여 방문하는 트래픽)은 2026년 Q1에 전년 대비 '''393% 성장'''
* AI 참조 트래픽의 전환율이 일반 트래픽 대비 '''42% 높음''' (미국 리테일 기준)
* Yext 조사에 따르면 AI 인용의 86%가 브랜드가 직접 통제하는 소스에서 발생

=== "llms.txt가 AI 인용에 실제로 효과가 있냐" 논쟁 ===

이 질문에 대한 솔직한 답은 '''"별로 없다, 하지만 해놓는 게 낫다"'''이다.

SE Ranking이 2025년 11월 30만 개 도메인을 분석한 결과, llms.txt 보유 여부와 AI 모델에서의 인용 빈도 사이에 '''측정 가능한 상관관계가 없었다'''. 구글의 입장도 냉소적이다. 그러나:

* Anthropic과 Perplexity에서는 잘 구성된 llms.txt를 가진 사이트에서 '''약간의 인용률 향상'''이 관찰됨
* 콘텐츠가 방대하고 내비게이션이 복잡한 사이트일수록 llms.txt의 큐레이션 효과가 더 크게 나타남
* 구현 비용이 거의 0에 가깝고, 도입해서 손해볼 것이 없음
* IDE 에이전트에서의 실질적 효과는 이미 입증됨

Limy.ai가 5억 1,500만 건의 AI 봇 트래픽 이벤트를 분석한 결과, /llms.txt를 직접 방문한 크롤러는 '''408건에 불과'''했다. 통계적으로 무의미한 수준이다. 하지만 이것이 도입하지 말아야 한다는 뜻은 아니다.

{{참고|제레미 하워드의 말이 인상적이다: "2025년인데 콘텐츠의 99.9%가 여전히 인간을 위해 쓰여 있다. 곧 99.9%의 주의는 LLM의 주의가 될 것이다." 다소 과격한 예언이지만, AI 에이전트 시대를 향한 전략적 베팅으로서의 가치는 분명히 있다.}}

== 구현 방법 ==

=== 수동 작성 ===

마크다운 파일 하나를 만들고 <code>llms.txt</code>라는 이름으로 웹 서버 루트에 업로드하면 끝이다. 일반적으로 1~4시간 내로 완성 가능하다.

'''작성 순서:'''
# H1 헤더에 브랜드/사이트명 작성
# 블록 인용구에 한두 문장 요약 작성 (제3자 시점)
# 필요시 부연 설명 단락 추가
# H2 섹션을 나누어 중요 페이지들을 링크 목록으로 정리
# 각 링크마다 구체적인 한 줄 설명 추가
# 우선순위 낮은 페이지는 <code>## Optional</code> 섹션에 배치
# 도메인 루트에 업로드 (<code>/llms.txt</code>)

=== 자동 생성 도구 및 플랫폼 지원 ===

{| class="wikitable"
|+ '''llms.txt 자동 생성/지원 도구'''
|-
! style="background:#3c5a9a;color:white;" | 도구/플랫폼
! style="background:#3c5a9a;color:white;" | 방법
|-
| '''[[Mintlify]]'''
| 모든 호스팅 문서 사이트에 자동 생성. 별도 설정 불필요.
|-
| '''[[Yoast SEO]] (WordPress)'''
| WordPress 플러그인에서 자동 생성 지원
|-
| '''[[Webflow]]'''
| 루트 디렉토리에 직접 업로드 가능
|-
| '''[[Next.js]]'''
| 커뮤니티 플러그인 사용
|-
| '''[[Astro]]'''
| 빌트인 지원 또는 플러그인
|-
| '''llms.txt 생성기 웹사이트들'''
| URL 입력 시 AI가 자동으로 llms.txt 초안 생성해주는 서비스들 다수 존재
|}

=== 검증 도구 ===

* '''Chrome Lighthouse 13.3''' (2026년 5월 7일 출시): llms.txt 존재 여부를 기술 감사 항목에 추가
* 여러 온라인 llms.txt 검증기(validator) 서비스 존재
* 직접 <code>curl https://yourdomain.com/llms.txt</code>로 확인

=== 모니터링 ===

구현 후 효과를 추적하는 방법들:

* '''서버 액세스 로그''' : <code>/llms.txt</code>에 대한 AI 유저 에이전트 히트 추적 (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended, Applebot-Extended 등)
* '''허니팟 링크''' : 파일 내에 자동화 에이전트만 방문할 허위 URL을 심어두고 히트 여부 모니터링
* '''브랜드 모니터링 도구''' : Profound, Goodie, Otterly 등 GEO 특화 도구들이 AI 응답에서 브랜드 언급 모니터링

== 비판과 반론 ==

=== 회의적 시각 ===

llms.txt에 대한 비판적 시각들을 정리하면 다음과 같다.

; 구글의 냉소적 입장
: 구글의 Gary Illyes와 John Mueller 모두 llms.txt에 부정적이다. 특히 John Mueller의 "키워드 메타 태그와 비슷하다"는 비유는 많이 회자된다. 키워드 메타 태그는 1990년대에 SEO 스팸으로 인해 완전히 폐기된 전례가 있는 태그다. 그의 요지는 "사이트 소유자가 스스로 주장하는 메타데이터를 크롤러가 신뢰할 이유가 없다"는 것.
; 실제 효과 미측정
: SE Ranking의 30만 도메인 대규모 연구에서 llms.txt 보유와 AI 인용 상관관계를 측정하지 못했다. 현 시점에서 "llms.txt로 AI 검색 순위를 올릴 수 있다"는 마케팅 주장은 데이터로 뒷받침되지 않는다.
; 크롤러 무시
: Limy.ai의 5억 건 분석에서 /llms.txt를 실제로 읽은 주요 AI 크롤러는 통계적으로 무의미한 수준이었다.
; 공식 표준 아님
: W3C, IETF, ISO 등 어떤 공식 표준화 기구의 승인도 없는 커뮤니티 관행에 불과하다. 따라서 플랫폼마다 해석이 달라질 수 있다.

=== 옹호 측 반론 ===

; 구현 비용이 거의 0
: 1~4시간 정도면 작성 완료. 해서 손해볼 것이 없고, 향후 AI 플랫폼이 지원하기로 결정했을 때 이미 준비가 되어 있다는 이점이 있다. 오버피팅 없는 헤지(hedge)다.
; IDE 에이전트에서의 실질적 효과
: ChatGPT, Claude 등의 소비자 AI 서비스에서의 효과는 미미하더라도, 개발자들이 사용하는 Cursor, Claude Code 등 IDE 에이전트에서는 명확히 활용되고 있다.
; 2011년의 schema.org
: IndexLab 분석가들은 2011년 초기의 schema.org 구조화 데이터에 비유한다. 당시에도 "구글이 실제로 쓰지 않는다"는 회의론이 있었지만 결국 중요한 표준이 됐다.
; 콘텐츠 큐레이션 강제 효과
: llms.txt를 만드는 과정 자체가 "AI에게 무엇을 보여주고 싶은가"를 명확히 정리하는 계기가 된다. 파일이 읽히지 않더라도 내부 문서 전략 수립에 도움이 된다.
; B2A(Business-to-Agent) 시대 대비
: AI 에이전트가 사람 대신 웹을 탐색하는 B2A 패러다임이 도래하고 있다. llms.txt는 이 흐름에서 에이전트가 사이트를 효율적으로 탐색하도록 돕는 첫 번째 표준이다.

=== llms-full.txt의 잠재적 리스크 ===

전문가들이 llms-full.txt 공개에 신중해야 한다고 경고하는 이유들:

* 사이트 전체 콘텐츠를 경쟁사에게 한 번에 제공하는 셈
* 유료 프리미엄 콘텐츠가 의도치 않게 노출될 수 있음
* 저작권 콘텐츠의 무단 학습에 활용될 수 있음

== 미래 전망 ==

=== 표준화 가능성 ===

llms.txt는 커뮤니티 관행으로 시작했지만, IETF RFC나 W3C 표준으로 공식화될 가능성이 논의되고 있다. 공식화가 이루어지면 금융, 헬스케어, 법률 등 컴플라이언스에 민감한 업종의 도입을 크게 촉진할 것으로 보인다. 현재 llmstxt.org 명세는 Anthropic, Perplexity 및 다양한 오픈소스 기여자들의 참여로 커뮤니티 방식으로 관리되고 있다.

=== 유료 크롤링 경제학 ===

Cloudflare가 2025년 중반에 봇 결제 인프라를 발표하며 AI 크롤러가 콘텐츠에 대해 소액 결제를 하는 개념이 등장했다. 이 흐름이 발전하면 llms.txt 파일에 참조 URL들의 '''가격 메타데이터'''가 포함되어, 고가치 페이지 접근에 402 Payment Required 핸드셰이크가 이루어지는 시나리오도 상상해볼 수 있다.

=== 서명된 매니페스트 (Signed Manifests) ===

llms.txt 채택이 늘면서 사이트가 파일 안에 허위 정보를 넣는 유혹도 커진다. 이에 대응하기 위해 검증 가능하고 암호학적으로 서명된 llms.txt 매니페스트에 대한 논의가 진행 중이다.

=== AI 에이전트 시대와 B2A ===

Limy.ai는 이 현상을 '''B2A(Business-to-Agent)'''로 명명한다. 과거 B2C 기업들이 모바일 앱을 만들어야 했듯이, 2026년대에는 모든 브랜드가 AI 에이전트가 라우팅할 수 있는 인터페이스를 갖춰야 한다는 것이다. llms.txt는 그 첫 번째 공개 B2A 표준으로 기록될 가능성이 높다.

== 관련 용어 정리 ==

{| class="wikitable"
|+ '''llms.txt 관련 주요 용어'''
|-
! style="background:#3c5a9a;color:white;width:25%" | 용어
! style="background:#3c5a9a;color:white;width:75%" | 설명
|-
| '''GEO (Generative Engine Optimization)'''
| 생성 엔진 최적화. ChatGPT, Claude 등의 AI 답변에 자사 콘텐츠가 인용되도록 최적화하는 것. SEO의 AI 버전.
|-
| '''AEO (Answer Engine Optimization)'''
| 질문-답변 엔진 최적화. GEO와 유사하거나 상위 개념으로 사용되기도 함.
|-
| '''RAG (Retrieval-Augmented Generation)'''
| 검색 증강 생성. LLM이 답변 생성 시 외부 문서를 실시간으로 검색·참조하는 방식.
|-
| '''컨텍스트 창 (Context Window)'''
| LLM이 한 번에 처리할 수 있는 텍스트의 최대 길이. llms.txt는 이 공간을 효율적으로 쓰도록 돕는다.
|-
| '''B2A (Business-to-Agent)'''
| 기업이 인간 고객이 아닌 AI 에이전트를 대상으로 서비스를 설계하는 패러다임.
|-
| '''AI 크롤러 (AI Crawler)'''
| GPTBot, ClaudeBot 등 AI 학습 또는 검색을 위해 웹을 수집하는 봇.
|-
| '''llmstxt.org'''
| llms.txt 공식 명세 사이트. 제레미 하워드가 관리하며 커뮤니티 기여로 운영됨.
|-
| '''MCP (Model Context Protocol)'''
| Anthropic이 제안한 AI 모델과 외부 서비스 연결 표준. llms.txt와 함께 사용되는 경우 증가 중.
|-
| '''Mintlify'''
| 개발자 문서 플랫폼. llms.txt 대규모 보급의 1등 공신. Anthropic과 협력하여 .md 확장자 규칙을 명세에 기여.
|}

== 여담 ==

* llms.txt 파일의 이름은 반드시 '''복수형'''인 <code>llms.txt</code>여야 한다. <code>llm.txt</code>로 만들면 표준을 따르지 않는 것이다. 단순해 보이지만 놀랍게도 이 실수를 하는 사람들이 꽤 있다.

* 제레미 하워드가 최초 제안 시 든 비유가 명쾌하다: 복잡한 HTML로 가득 찬 웹사이트를 AI에게 주는 것은 마치 '''500페이지짜리 매뉴얼을 통째로 건네주는 것'''과 같고, llms.txt는 그 중에서 핵심만 추린 '''1페이지 요약본'''을 먼저 주는 것이다.

* Cloudflare의 llms-full.txt는 '''370만 토큰'''에 달한다. Vercel의 llms-full.txt는 "40만 단어짜리 소설"이라고 불리기도 했다. 토큰 비용 생각하면 AI 크롤러 입장에서 이걸 통째로 읽는 건... 꽤 부담스러운 일이다.

* Google이 llms.txt를 지원하지 않겠다고 밝힌 것과는 별개로, Google의 A2A(Agents-to-Agents) 프로토콜 문서에는 llms.txt가 '''실험적으로 언급'''되어 있다. "공식 지원은 없지만 그렇다고 무시하는 것도 아닌" 묘한 입장이다.

* 어떤 독일 디지털 에이전시(dev5310)는 2026년 2월 Cloudflare Workers로 정적 llms.txt를 배포하고 JSON-LD 구조화 데이터와 함께 Google Search Console에 제출한 결과, 3일 후 Google AI Mode가 해당 파일을 브랜드 쿼리의 '''1차 출처로 인용'''했다는 사례를 보고했다. Google이 공식으로는 지원 안 한다면서 실제로는 참고하고 있다는 증거로 자주 인용된다.

* [[Cursor]], [[Windsurf]] 등 AI IDE들이 llms.txt를 열심히 읽는다는 점에서, 아이러니하게도 AI가 AI를 위한 파일을 읽어 AI 답변의 품질을 높이는 구조가 형성된다.

* 파일의 공식 명세가 워낙 간단하다 보니, "명세를 다 읽는 데 5분도 안 걸린다"는 우스갯소리가 있다. 실제로 llmstxt.org의 전체 명세 문서는 정말 짧다.

* BuiltWith 기준 2025년 10월 25일 시점 844,000개 이상 웹사이트가 도입했음에도 불구하고, 어떤 주요 AI 플랫폼도 "우리가 llms.txt를 인용 신호로 사용한다"고 공식 발표를 하지 않은 상황이다. 마치 모두가 파티에는 갔는데 아무도 춤을 추지 않는 상황 같다.

== 관련 문서 ==

* [[robots.txt]]
* [[sitemap.xml]]
* [[검색 엔진 최적화|SEO (검색 엔진 최적화)]]
* [[생성 엔진 최적화|GEO (생성 엔진 최적화)]]
* [[대규모 언어 모델|LLM (대규모 언어 모델)]]
* [[검색 증강 생성|RAG (Retrieval-Augmented Generation)]]
* [[모델 컨텍스트 프로토콜|MCP (Model Context Protocol)]]
* [[Jeremy Howard]]
* [[Answer.AI]]
* [[Mintlify]]
* [[Anthropic]]

[[분류:인터넷 표준]]
[[분류:인공지능]]
[[분류:웹 표준]]
[[분류:생성형 AI]]
[[분류:SEO]]
[[분류:GEO]]

히키가야 하치만

2026-06-17T08:46:02Z

Gaon12:

== 캐릭터 ==
{{캐릭터 정보
|그림 = 역내청_킹치만_1기.jpg
|그림2 = 역내청_킹치만_2,3기.jpg
|성별 = 남
|이름 = 히키가야 하치만
|이름/일어 = 比企谷八幡
|이름/요미카타 = ひきがやはちまん
|이름/영어 = Hachiman Hikigaya
|이명 =
|이명/일어 =
|이명/영어 =



|속성 = 고등학생, 외톨이, 봉사부



|등장작품 = 역시 내 청춘 러브코메디는 잘못됐다.
|등장작품2 = 역시 내 청춘 러브코메디는 잘못됐다. 속
|등장작품3 = 역시 내 청춘 러브코메디는 잘못됐다. 완
|등장작품4 = 역시 내 청춘 러브코메디는 잘못됐다. 결
|CV = [[에구치 타쿠야]]
|종족 = 인간
|국적 = {{국기|일본}}
|연령 =
|신분 = [[소부고교]] 2학년 F반, [[봉사부]] 부원
|생일 = 8월 8일
|혈액형 = A형
|신장 =
|체중 =
|가슴 =
|허리 =
|엉덩이 =
|컵 =
|별명 = 힛키 (ヒッキー)<ref>[[유이가하마 유이]]가 주로 사용하는 애칭이다.</ref>
|특기 = 퀴즈, 수수께끼, 혼잣말, 상황 분석
|취미 = 독서, 혼자서 할 수 있는 활동
|거주지 =
|가족관계 = 부모님, 여동생 [[히키가야 코마치]]
|캐릭터송 = going going alone way!
|공식 인기투표 =



|국내명 = 히키가야 하치만
|등장작품/국내 = 역시 내 청춘 러브코메디는 잘못됐다.
|CV/국내 =
}}

'''히키가야 하치만'''(比企谷八幡)은 [[역시 내 청춘 러브코메디는 잘못됐다.]]의 주인공이다. [[소부고교]] 2학년 F반에 재학 중인 남학생으로, [[히라츠카 시즈카]]의 권유라는 이름의 강제 조치에 가까운 계기로 [[봉사부]]에 입부한다. 공식 소개에서는 학력, 운동신경, 외모가 모두 그럭저럭인 편이지만, 독특하게 비뚤어진 사고방식 때문에 주변과 거리를 두며 외톨이 생활을 이어 온 인물로 설명된다.<ref>[https://www.tbs.co.jp/anime/oregairu/character/chara01.html TV 애니메이션 「やはり俺の青春ラブコメはまちがっている。完」 공식 캐릭터 소개 - 比企谷八幡]</ref>

하치만은 작품의 서술과 갈등 해결을 이끄는 중심 인물이다. 겉으로는 냉소적이고 염세적인 태도를 보이며, 타인의 호의나 친절을 쉽게 믿지 않는다. 특히 누군가가 갑자기 상냥하게 대하면 벌게임, 장난, 계산된 행동이 숨어 있다고 의심하는 경향이 강하다. 이러한 성격은 어린 시절부터 반복된 인간관계의 실패와 외톨이 경험에서 비롯된 방어기제에 가깝다.

학교생활에서는 교우관계가 거의 없고, 같은 반 학생들에게 이름을 제대로 불리지 못하는 일도 잦다.<ref>작중에서 “히키타니”, “히키오” 등으로 잘못 불리는 경우가 있다.</ref> 그러나 단순히 능력이 없는 인물은 아니며, 관찰력과 언어 감각이 뛰어나고 국어를 비롯한 문과 과목에 강하다. 만화판 소개에서도 소부고교 2학년 F반 소속, 국어 성적 학년 3위라는 점이 언급된다.<ref>[https://www.sunday-webry.com/episode/2550912965415111689 『やはり俺の青春ラブコメはまちがっている。＠comic』 제1화 소개]</ref>

== 인물상 ==
하치만의 가장 큰 특징은 스스로를 외톨이로 규정하고, 인간관계에서 손해 보지 않기 위해 먼저 거리를 두는 태도이다. 그는 친구를 사귀지 못하는 것이 아니라 사귀지 않는 것이라고 자신을 설득하지만, 실제로는 타인에게 상처받는 일을 피하려는 성향이 강하다. 이러한 태도 때문에 교실에서는 말수가 적고, 집단 활동에서는 의도적으로 존재감을 낮춘다.

한편 그는 타인의 감정과 집단의 분위기를 읽는 능력이 뛰어나다. 다만 그 능력을 긍정적인 소통보다는 문제의 약점과 모순을 찾아내는 데 사용하는 경우가 많다. 봉사부에 들어온 의뢰를 해결할 때도 정공법보다는 갈등 구조 자체를 비틀거나, 자신의 평판을 희생하여 문제를 덮는 방식을 선택하곤 한다. 이 때문에 의뢰는 해결되더라도 [[유키노시타 유키노]], [[유이가하마 유이]], [[히라츠카 시즈카]] 등 주변 인물에게는 걱정과 반발을 산다.

하치만은 냉소적인 말투와 달리 완전히 무관심한 인물은 아니다. 오히려 자신이 상처받는 데 익숙하다는 이유로 타인의 상처를 대신 떠안으려는 면이 있으며, 이것이 작품 중반부 이후 주요 갈등으로 발전한다. 그의 자기희생은 겉보기에는 효율적인 해결책처럼 보이지만, 주변 사람들과의 관계를 왜곡하고 스스로를 고립시키는 원인이 되기도 한다.

== 외모 ==
외모 자체는 나쁜 편으로 묘사되지 않는다. 다만 눈빛이 탁하고 피곤해 보인다는 인상이 강해, [[히라츠카 시즈카]]를 비롯한 여러 인물에게 “눈이 썩었다”, “근성이 썩었다”는 식으로 평가받는다. 이러한 외모 묘사는 하치만의 냉소적인 태도, 낮은 자존감, 외톨이 기질을 시각적으로 드러내는 장치로 쓰인다.

== 능력과 성적 ==
하치만은 학교에서 특별히 부활동이나 교우관계에 힘을 쏟지 않기 때문에 공부에 투자하는 시간이 비교적 많다. 특히 국어와 국사 등 문과 과목에 강하며, 국어 성적은 학년 상위권이다. 반대로 수학 등 이과 과목에는 약한 모습을 보이고, 과거에는 낮은 점수를 받은 적도 있다.

상황 판단력도 뛰어나다. 하치만은 의뢰인과 주변 인물의 말보다 그들이 처한 관계, 집단 내 위치, 침묵하는 이유를 먼저 살핀다. 이 능력은 봉사부 활동에서 자주 빛을 발하지만, 지나치게 부정적인 전제를 깔고 판단하기 때문에 주변의 선의를 오해하는 원인이 되기도 한다.

== 봉사부에서의 활동 ==
봉사부에 입부한 뒤 하치만은 [[유키노시타 유키노]], [[유이가하마 유이]]와 함께 학생들의 의뢰를 맡게 된다. 초기에는 의뢰의 표면적인 목적보다 그 뒤에 있는 인간관계의 불편함을 파악하고, 이를 단번에 무너뜨리는 방식으로 문제를 해결한다. 이러한 해결법은 빠른 효과를 보이지만, 하치만 본인이 악역을 맡거나 비난을 감수하는 경우가 많다.

공식 소개에서도 하치만은 봉사부에 들어오는 의뢰에 대해 부정적인 가치관에서 비롯된 해결 방법을 보이며, 주변을 당황하게 하는 인물로 설명된다.<ref>[https://www.tbs.co.jp/anime/oregairu/character/chara01.html TV 애니메이션 「やはり俺の青春ラブコメはまちがっている。完」 공식 캐릭터 소개 - 比企谷八幡]</ref> 이 특징은 작품 전반의 갈등을 이끄는 핵심 요소이다.

== 작중 행적 ==
=== 입부 이전 ===
고등학교 입학식 날, 하치만은 우연히 도로로 뛰어든 개를 구하려다가 사고를 당해 입원한다. 그 결과 입학 초기에 반 친구들과 어울릴 기회를 놓치고, 고등학교에서도 외톨이로 지내게 된다. 다만 하치만 본인은 그 사고가 없었더라도 자신은 결국 외톨이가 되었을 것이라고 생각한다.

=== 봉사부 입부 ===
하치만은 “고교 생활을 되돌아보며”라는 주제로 쓴 작문에서 청춘과 리얼충을 냉소적으로 비판한다.<ref>원작에서는 “리얼충 폭발해라”에 가까운 표현이 쓰이며, 애니메이션에서는 “청춘을 즐기는 어리석은 자들, 부서져라”라는 취지로 변경되었다.</ref> 이 작문을 본 [[히라츠카 시즈카]]는 하치만의 비뚤어진 사고방식을 바로잡겠다는 명목으로 그를 [[봉사부]]에 데려간다. 이곳에서 하치만은 [[유키노시타 유키노]]와 처음으로 본격적으로 대립하고, 이후 [[유이가하마 유이]]가 합류하면서 봉사부의 기본 구도가 형성된다.

=== 학교 행사와 자기희생 ===
문화제, 체육제, 수학여행 등 여러 학교 행사에서 하치만은 집단 내부의 모순을 드러내는 방식으로 문제를 해결한다. 특히 누군가가 책임을 져야 하는 상황에서는 스스로 비난받는 위치에 서는 것을 주저하지 않는다. 그러나 이러한 방식은 당장의 문제를 정리할 수는 있어도, 그와 가까운 인물들에게 깊은 상처와 불신을 남긴다.

수학여행 이후 하치만은 자신이 원하던 것이 단순한 문제 해결이나 겉보기의 평화가 아니라, 거짓이나 자기기만으로 덮지 않는 관계라는 사실을 점차 의식하게 된다. 이 과정에서 그가 말하는 “진짜”는 작품 전체의 중요한 주제로 자리 잡는다.

=== 학생회와 크리스마스 행사 ===
[[잇시키 이로하]]와 관련된 학생회 선거, 크리스마스 합동 행사 등에서는 하치만의 문제 해결 방식이 더욱 분명하게 비판받는다. 그는 상황을 효율적으로 정리하려 하지만, 유키노와 유이에게는 그 방식이 관계를 유지하는 것이 아니라 관계를 포기하는 태도로 보인다. 이 시기부터 하치만은 타인과의 관계에서 자신이 무엇을 원하고 있는지 직접 말해야 하는 상황에 놓인다.

=== 프롬과 완결부 ===
작품 후반부의 프롬 계획에서는 [[유키노시타 유키노]]가 자신의 문제를 스스로 해결하려 하고, 하치만은 그 의뢰를 정면으로 마주하기 위해 별도의 계획을 세운다. 이 과정에서 하치만은 더 이상 자기희생만으로 문제를 처리할 수 없다는 사실을 받아들이고, 자신이 진정으로 원하는 관계를 말로 전하려 한다. 원작 본편은 제14권에서 완결되었으며, 이후 또 하나의 이야기인 [[역시 내 청춘 러브코메디는 잘못됐다. 결]]이 전개되었다.<ref>[https://shogakukan-comic.jp/news/21758 쇼가쿠칸, 『역시 내 청춘 러브코메디는 잘못됐다.』 제14권 완결 소식]</ref><ref>[https://shogakukan-comic.jp/book?isbn=9784094530315 쇼가쿠칸, 『역시 내 청춘 러브코메디는 잘못됐다. 결 1』 공식 도서 정보]</ref>

== 인간관계 ==
; [[유키노시타 유키노]]
: 봉사부에서 처음 만난 동급생이자, 하치만과 가장 자주 충돌하는 인물이다. 두 사람은 모두 고립된 위치에 있지만, 문제를 바라보는 방식과 자존심이 강해 초반에는 날카롭게 대립한다. 그러나 의뢰를 함께 해결하며 서로의 능력과 약점을 알아가고, 후반부에는 서로에게 거짓 없이 다가가는 관계로 변화한다.

; [[유이가하마 유이]]
: 하치만에게 “힛키”라는 별명을 붙인 인물이다. 밝고 사교적인 성격으로 하치만과 대조를 이루며, 봉사부의 분위기를 부드럽게 만드는 역할을 한다. 하치만은 유이의 친절을 처음에는 의심하지만, 시간이 지나며 그녀의 배려와 상냥함을 인정하게 된다.

; [[히라츠카 시즈카]]
: 하치만의 담임 교사이자, 그를 봉사부에 입부시킨 장본인이다. 하치만의 비뚤어진 사고방식을 꾸짖으면서도 그의 본질적인 선의를 알아보고, 필요할 때마다 조언을 건넨다. 하치만에게는 어른으로서 가장 직접적인 영향을 주는 인물 중 하나이다.

; [[히키가야 코마치]]
: 하치만의 여동생이다. 하치만이 가족 앞에서 비교적 솔직하게 행동하는 몇 안 되는 상대이며, 코마치는 오빠의 냉소적인 태도를 이해하면서도 사회성과 인간관계에 대해 자주 조언한다. 하치만은 코마치를 매우 아끼며, 시스터 콤플렉스에 가까운 모습을 보이기도 한다.

; [[잇시키 이로하]]
: 학생회 관련 사건을 계기로 하치만과 깊이 엮이는 후배이다. 겉으로는 계산적이고 능청스러운 태도를 보이지만, 하치만의 방식과 봉사부의 관계를 관찰하며 여러 차례 도움을 받는다. 하치만 역시 이로하의 의뢰를 통해 자신의 해결 방식과 관계 맺는 방식을 다시 생각하게 된다.

; [[하야마 하야토]]
: 반에서 중심적인 위치에 있는 인기 학생으로, 하치만과는 여러 면에서 대조되는 인물이다. 하야마는 집단의 조화를 중시하고, 하치만은 집단의 모순을 드러내는 방식으로 움직인다. 두 사람은 서로를 완전히 이해하지는 못하지만, 상대의 능력과 선택을 의식하는 관계이다.

; [[토츠카 사이카]]
: 하치만이 드물게 호의적으로 대하는 반 친구이다. 테니스부 소속이며, 상냥하고 순한 성격으로 하치만에게도 편견 없이 다가온다. 하치만은 토츠카의 외모와 태도에 과하게 흔들리는 모습을 보이며, 이는 작품의 개그 요소로 자주 활용된다.

; [[자이모쿠자 요시테루]]
: 하치만과 비슷하게 교실에서 겉도는 동급생이다. 중2병적인 언행이 강하며, 자신의 원고를 봉사부에 가져오는 의뢰를 통해 하치만과 엮인다. 하치만은 자이모쿠자를 귀찮아하면서도 완전히 외면하지는 않는다.

== 성격적 특징 ==
하치만은 자신을 낮게 평가하고, 타인과 가까워지는 일을 위험한 일로 여긴다. 그 때문에 먼저 냉소적인 농담을 던지거나, 관계의 가능성을 부정하는 방식으로 상처받을 여지를 줄이려 한다. 그러나 이런 태도는 동시에 주변 사람의 마음을 밀어내고, 자신이 원하는 관계를 스스로 부정하게 만드는 문제를 낳는다.

작품이 진행될수록 하치만은 단순히 외톨이로 남는 것이 아니라, 자신이 외면해 온 감정과 관계를 마주하게 된다. 그의 성장은 완전히 다른 사람이 되는 변화가 아니라, 비뚤어진 방식으로라도 지키고 싶었던 것을 스스로 인정하는 과정에 가깝다.

== 기타 ==

* 좋아하는 과목은 국어와 국사이며, 문과 과목에 강하다.
* 좋아하는 음식은 허니로스 땅콩과 말린 된장땅콩이다.
* 이미지 동물은 여우로 언급된다.
* 좌우명은 “밀어서 안 되면 포기하라”이다.
* 이름의 한자 “八幡”과 생일인 8월 8일은 모두 숫자 8을 연상시킨다.
* [[유이가하마 유이]]가 사용하는 “힛키” 외에도, 주변 인물들이 이름을 잘못 부르면서 “히키타니”, “히키오” 등으로 불리는 경우가 있다.
* 『[[역시 내 청춘 러브코메디는 잘못됐다. 결]]』에서도 봉사부 부원으로 등장하며, 쇼가쿠칸의 『결 2』 소개에서는 “성격이 비뚤어진 봉사부 부원”으로 소개된다.<ref>[https://gagagabunko.jp/lineup/202302.html 쇼가쿠칸 가가가문고, 『역시 내 청춘 러브코메디는 잘못됐다. 결 2』 소개]</ref>

== 주석 ==
<references />

[[분류:역시 내 청춘 러브코메디는 잘못됐다.]]
[[분류:역시 내 청춘 러브코메디는 잘못됐다.의 등장인물]]
[[분류:라이트 노벨의 남자 등장인물]]
[[분류:애니메이션의 남자 등장인물]]
[[분류:고등학생 캐릭터]]

히키가야 하치만

2026-06-17T08:38:47Z

Gaon12: 문서 내용 보강

== 캐릭터 ==
{{캐릭터 정보
|그림 = 역내청_킹치만_1기.jpg
|그림2 = 역내청_킹치만_2,3기.jpg
|성별 = 남
|이름 = 히키가야 하치만
|이름/일어 = 比企谷八幡
|이름/요미카타 = ひきがやはちまん
|이름/영어 = Hachiman Hikigaya
|이명 =
|이명/일어 =
|이명/영어 =



|속성 = 고등학생, 외톨이, 봉사부



|등장작품 = 역시 내 청춘 러브코메디는 잘못됐다.
|등장작품2 = 역시 내 청춘 러브코메디는 잘못됐다. 속
|등장작품3 = 역시 내 청춘 러브코메디는 잘못됐다. 완
|등장작품4 = 역시 내 청춘 러브코메디는 잘못됐다. 결
|CV = [[에구치 타쿠야]]
|종족 = 인간
|국적 = {{국기|일본}}
|연령 =
|신분 = [[소부고교]] 2학년 F반, [[봉사부]] 부원
|생일 = 8월 8일
|혈액형 = A형
|신장 =
|체중 =
|가슴 =
|허리 =
|엉덩이 =
|컵 =
|별명 = 힛키 (ヒッキー)<ref>[[유이가하마 유이]]가 주로 사용하는 애칭이다.</ref>
|특기 = 퀴즈, 수수께끼, 혼잣말, 상황 분석
|취미 = 독서, 혼자서 할 수 있는 활동
|거주지 =
|가족관계 = 부모님, 여동생 [[히키가야 코마치]]
|캐릭터송 = going going alone way!
|공식 인기투표 =



|국내명 = 히키가야 하치만
|등장작품/국내 = 역시 내 청춘 러브코메디는 잘못됐다.
|CV/국내 =
}}

'''히키가야 하치만'''(比企谷八幡)은 [[역시 내 청춘 러브코메디는 잘못됐다.]]의 주인공이다. [[소부고교]] 2학년 F반에 재학 중인 남학생으로, [[히라츠카 시즈카]]의 권유라는 이름의 강제 조치에 가까운 계기로 [[봉사부]]에 입부한다. 공식 소개에서는 학력, 운동신경, 외모가 모두 그럭저럭인 편이지만, 독특하게 비뚤어진 사고방식 때문에 주변과 거리를 두며 외톨이 생활을 이어 온 인물로 설명된다.<ref>[https://www.tbs.co.jp/anime/oregairu/character/chara01.html TV 애니메이션 「やはり俺の青春ラブコメはまちがっている。完」 공식 캐릭터 소개 - 比企谷八幡]</ref>

하치만은 작품의 서술과 갈등 해결을 이끄는 중심 인물이다. 겉으로는 냉소적이고 염세적인 태도를 보이며, 타인의 호의나 친절을 쉽게 믿지 않는다. 특히 누군가가 갑자기 상냥하게 대하면 벌게임, 장난, 계산된 행동이 숨어 있다고 의심하는 경향이 강하다. 이러한 성격은 어린 시절부터 반복된 인간관계의 실패와 외톨이 경험에서 비롯된 방어기제에 가깝다.

학교생활에서는 교우관계가 거의 없고, 같은 반 학생들에게 이름을 제대로 불리지 못하는 일도 잦다.<ref>작중에서 “히키타니”, “히키오” 등으로 잘못 불리는 경우가 있다.</ref> 그러나 단순히 능력이 없는 인물은 아니며, 관찰력과 언어 감각이 뛰어나고 국어를 비롯한 문과 과목에 강하다. 만화판 소개에서도 소부고교 2학년 F반 소속, 국어 성적 학년 3위라는 점이 언급된다.<ref>[https://www.sunday-webry.com/episode/2550912965415111689 『やはり俺の青春ラブコメはまちがっている。＠comic』 제1화 소개]</ref>

== 인물상 ==
하치만의 가장 큰 특징은 스스로를 외톨이로 규정하고, 인간관계에서 손해 보지 않기 위해 먼저 거리를 두는 태도이다. 그는 친구를 사귀지 못하는 것이 아니라 사귀지 않는 것이라고 자신을 설득하지만, 실제로는 타인에게 상처받는 일을 피하려는 성향이 강하다. 이러한 태도 때문에 교실에서는 말수가 적고, 집단 활동에서는 의도적으로 존재감을 낮춘다.

한편 그는 타인의 감정과 집단의 분위기를 읽는 능력이 뛰어나다. 다만 그 능력을 긍정적인 소통보다는 문제의 약점과 모순을 찾아내는 데 사용하는 경우가 많다. 봉사부에 들어온 의뢰를 해결할 때도 정공법보다는 갈등 구조 자체를 비틀거나, 자신의 평판을 희생하여 문제를 덮는 방식을 선택하곤 한다. 이 때문에 의뢰는 해결되더라도 [[유키노시타 유키노]], [[유이가하마 유이]], [[히라츠카 시즈카]] 등 주변 인물에게는 걱정과 반발을 산다.

하치만은 냉소적인 말투와 달리 완전히 무관심한 인물은 아니다. 오히려 자신이 상처받는 데 익숙하다는 이유로 타인의 상처를 대신 떠안으려는 면이 있으며, 이것이 작품 중반부 이후 주요 갈등으로 발전한다. 그의 자기희생은 겉보기에는 효율적인 해결책처럼 보이지만, 주변 사람들과의 관계를 왜곡하고 스스로를 고립시키는 원인이 되기도 한다.

== 외모 ==
외모 자체는 나쁜 편으로 묘사되지 않는다. 다만 눈빛이 탁하고 피곤해 보인다는 인상이 강해, [[히라츠카 시즈카]]를 비롯한 여러 인물에게 “눈이 썩었다”, “근성이 썩었다”는 식으로 평가받는다. 이러한 외모 묘사는 하치만의 냉소적인 태도, 낮은 자존감, 외톨이 기질을 시각적으로 드러내는 장치로 쓰인다.

== 능력과 성적 ==
하치만은 학교에서 특별히 부활동이나 교우관계에 힘을 쏟지 않기 때문에 공부에 투자하는 시간이 비교적 많다. 특히 국어와 국사 등 문과 과목에 강하며, 국어 성적은 학년 상위권이다. 반대로 수학 등 이과 과목에는 약한 모습을 보이고, 과거에는 낮은 점수를 받은 적도 있다.

상황 판단력도 뛰어나다. 하치만은 의뢰인과 주변 인물의 말보다 그들이 처한 관계, 집단 내 위치, 침묵하는 이유를 먼저 살핀다. 이 능력은 봉사부 활동에서 자주 빛을 발하지만, 지나치게 부정적인 전제를 깔고 판단하기 때문에 주변의 선의를 오해하는 원인이 되기도 한다.

== 봉사부에서의 활동 ==
봉사부에 입부한 뒤 하치만은 [[유키노시타 유키노]], [[유이가하마 유이]]와 함께 학생들의 의뢰를 맡게 된다. 초기에는 의뢰의 표면적인 목적보다 그 뒤에 있는 인간관계의 불편함을 파악하고, 이를 단번에 무너뜨리는 방식으로 문제를 해결한다. 이러한 해결법은 빠른 효과를 보이지만, 하치만 본인이 악역을 맡거나 비난을 감수하는 경우가 많다.

공식 소개에서도 하치만은 봉사부에 들어오는 의뢰에 대해 부정적인 가치관에서 비롯된 해결 방법을 보이며, 주변을 당황하게 하는 인물로 설명된다.<ref>[https://www.tbs.co.jp/anime/oregairu/character/chara01.html TV 애니메이션 「やはり俺の青春ラブコメはまちがっている。完」 공식 캐릭터 소개 - 比企谷八幡]</ref> 이 특징은 작품 전반의 갈등을 이끄는 핵심 요소이다.

== 작중 행적 ==
=== 입부 이전 ===
고등학교 입학식 날, 하치만은 우연히 도로로 뛰어든 개를 구하려다가 사고를 당해 입원한다. 그 결과 입학 초기에 반 친구들과 어울릴 기회를 놓치고, 고등학교에서도 외톨이로 지내게 된다. 다만 하치만 본인은 그 사고가 없었더라도 자신은 결국 외톨이가 되었을 것이라고 생각한다.

=== 봉사부 입부 ===
하치만은 “고교 생활을 되돌아보며”라는 주제로 쓴 작문에서 청춘과 리얼충을 냉소적으로 비판한다.<ref>원작에서는 “리얼충 폭발해라”에 가까운 표현이 쓰이며, 애니메이션에서는 “청춘을 즐기는 어리석은 자들, 부서져라”라는 취지로 변경되었다.</ref> 이 작문을 본 [[히라츠카 시즈카]]는 하치만의 비뚤어진 사고방식을 바로잡겠다는 명목으로 그를 [[봉사부]]에 데려간다. 이곳에서 하치만은 [[유키노시타 유키노]]와 처음으로 본격적으로 대립하고, 이후 [[유이가하마 유이]]가 합류하면서 봉사부의 기본 구도가 형성된다.

=== 학교 행사와 자기희생 ===
문화제, 체육제, 수학여행 등 여러 학교 행사에서 하치만은 집단 내부의 모순을 드러내는 방식으로 문제를 해결한다. 특히 누군가가 책임을 져야 하는 상황에서는 스스로 비난받는 위치에 서는 것을 주저하지 않는다. 그러나 이러한 방식은 당장의 문제를 정리할 수는 있어도, 그와 가까운 인물들에게 깊은 상처와 불신을 남긴다.

수학여행 이후 하치만은 자신이 원하던 것이 단순한 문제 해결이나 겉보기의 평화가 아니라, 거짓이나 자기기만으로 덮지 않는 관계라는 사실을 점차 의식하게 된다. 이 과정에서 그가 말하는 “진짜”는 작품 전체의 중요한 주제로 자리 잡는다.

=== 학생회와 크리스마스 행사 ===
[[잇시키 이로하]]와 관련된 학생회 선거, 크리스마스 합동 행사 등에서는 하치만의 문제 해결 방식이 더욱 분명하게 비판받는다. 그는 상황을 효율적으로 정리하려 하지만, 유키노와 유이에게는 그 방식이 관계를 유지하는 것이 아니라 관계를 포기하는 태도로 보인다. 이 시기부터 하치만은 타인과의 관계에서 자신이 무엇을 원하고 있는지 직접 말해야 하는 상황에 놓인다.

=== 프롬과 완결부 ===
작품 후반부의 프롬 계획에서는 [[유키노시타 유키노]]가 자신의 문제를 스스로 해결하려 하고, 하치만은 그 의뢰를 정면으로 마주하기 위해 별도의 계획을 세운다. 이 과정에서 하치만은 더 이상 자기희생만으로 문제를 처리할 수 없다는 사실을 받아들이고, 자신이 진정으로 원하는 관계를 말로 전하려 한다. 원작 본편은 제14권에서 완결되었으며, 이후 또 하나의 이야기인 [[역시 내 청춘 러브코메디는 잘못됐다. 결]]이 전개되었다.<ref>[https://shogakukan-comic.jp/news/21758 쇼가쿠칸, 『역시 내 청춘 러브코메디는 잘못됐다.』 제14권 완결 소식]</ref><ref>[https://shogakukan-comic.jp/book?isbn=9784094530315 쇼가쿠칸, 『역시 내 청춘 러브코메디는 잘못됐다. 결 1』 공식 도서 정보]</ref>

== 인간관계 ==
; [[유키노시타 유키노]]
: 봉사부에서 처음 만난 동급생이자, 하치만과 가장 자주 충돌하는 인물이다. 두 사람은 모두 고립된 위치에 있지만, 문제를 바라보는 방식과 자존심이 강해 초반에는 날카롭게 대립한다. 그러나 의뢰를 함께 해결하며 서로의 능력과 약점을 알아가고, 후반부에는 서로에게 거짓 없이 다가가는 관계로 변화한다.

; [[유이가하마 유이]]
: 하치만에게 “힛키”라는 별명을 붙인 인물이다. 밝고 사교적인 성격으로 하치만과 대조를 이루며, 봉사부의 분위기를 부드럽게 만드는 역할을 한다. 하치만은 유이의 친절을 처음에는 의심하지만, 시간이 지나며 그녀의 배려와 상냥함을 인정하게 된다.

; [[히라츠카 시즈카]]
: 하치만의 담임 교사이자, 그를 봉사부에 입부시킨 장본인이다. 하치만의 비뚤어진 사고방식을 꾸짖으면서도 그의 본질적인 선의를 알아보고, 필요할 때마다 조언을 건넨다. 하치만에게는 어른으로서 가장 직접적인 영향을 주는 인물 중 하나이다.

; [[히키가야 코마치]]
: 하치만의 여동생이다. 하치만이 가족 앞에서 비교적 솔직하게 행동하는 몇 안 되는 상대이며, 코마치는 오빠의 냉소적인 태도를 이해하면서도 사회성과 인간관계에 대해 자주 조언한다. 하치만은 코마치를 매우 아끼며, 시스터 콤플렉스에 가까운 모습을 보이기도 한다.

; [[잇시키 이로하]]
: 학생회 관련 사건을 계기로 하치만과 깊이 엮이는 후배이다. 겉으로는 계산적이고 능청스러운 태도를 보이지만, 하치만의 방식과 봉사부의 관계를 관찰하며 여러 차례 도움을 받는다. 하치만 역시 이로하의 의뢰를 통해 자신의 해결 방식과 관계 맺는 방식을 다시 생각하게 된다.

; [[하야마 하야토]]
: 반에서 중심적인 위치에 있는 인기 학생으로, 하치만과는 여러 면에서 대조되는 인물이다. 하야마는 집단의 조화를 중시하고, 하치만은 집단의 모순을 드러내는 방식으로 움직인다. 두 사람은 서로를 완전히 이해하지는 못하지만, 상대의 능력과 선택을 의식하는 관계이다.

; [[토츠카 사이카]]
: 하치만이 드물게 호의적으로 대하는 반 친구이다. 테니스부 소속이며, 상냥하고 순한 성격으로 하치만에게도 편견 없이 다가온다. 하치만은 토츠카의 외모와 태도에 과하게 흔들리는 모습을 보이며, 이는 작품의 개그 요소로 자주 활용된다.

; [[자이모쿠자 요시테루]]
: 하치만과 비슷하게 교실에서 겉도는 동급생이다. 중2병적인 언행이 강하며, 자신의 원고를 봉사부에 가져오는 의뢰를 통해 하치만과 엮인다. 하치만은 자이모쿠자를 귀찮아하면서도 완전히 외면하지는 않는다.

== 성격적 특징 ==
하치만은 자신을 낮게 평가하고, 타인과 가까워지는 일을 위험한 일로 여긴다. 그 때문에 먼저 냉소적인 농담을 던지거나, 관계의 가능성을 부정하는 방식으로 상처받을 여지를 줄이려 한다. 그러나 이런 태도는 동시에 주변 사람의 마음을 밀어내고, 자신이 원하는 관계를 스스로 부정하게 만드는 문제를 낳는다.

작품이 진행될수록 하치만은 단순히 외톨이로 남는 것이 아니라, 자신이 외면해 온 감정과 관계를 마주하게 된다. 그의 성장은 완전히 다른 사람이 되는 변화가 아니라, 비뚤어진 방식으로라도 지키고 싶었던 것을 스스로 인정하는 과정에 가깝다.

== 기타 ==

* 좋아하는 과목은 국어와 국사이며, 문과 과목에 강하다.
* 좋아하는 음식은 허니로스 땅콩과 말린 된장땅콩이다.
* 이미지 동물은 여우로 언급된다.
* 좌우명은 “밀어서 안 되면 포기하라”이다.
* 이름의 한자 “八幡”과 생일인 8월 8일은 모두 숫자 8을 연상시킨다.
* [[유이가하마 유이]]가 사용하는 “힛키” 외에도, 주변 인물들이 이름을 잘못 부르면서 “히키타니”, “히키오” 등으로 불리는 경우가 있다.
* 『[[역시 내 청춘 러브코메디는 잘못됐다. 결]]』에서도 봉사부 부원으로 등장하며, 쇼가쿠칸의 『결 2』 소개에서는 “성격이 비뚤어진 봉사부 부원”으로 소개된다.<ref>[https://gagagabunko.jp/lineup/202302.html 쇼가쿠칸 가가가문고, 『역시 내 청춘 러브코메디는 잘못됐다. 결 2』 소개]</ref>

== 주석 ==
<references />

[[분류:역시 내 청춘 러브코메디는 잘못됐다.의 등장인물]]
[[분류:라이트 노벨의 남자 등장인물]]
[[분류:애니메이션의 남자 등장인물]]
[[분류:고등학생 캐릭터]]