Conaonda Wiki - 최근 바뀜 [ko]

미디어위키:D3.min.js

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:40 GMT

migrate: import legacy Wiki content to Vultr

미디어위키:Common.js

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:38 GMT

migrate: import legacy Wiki content to Vultr

새 문서

/* Conaonda Wiki - Main Page Dynamic Content */
/*
* 게시 위치: MediaWiki:Common.js (스킨 비의존).
* 링크는 mw.util.getUrl()로 생성한다. $wgArticlePath의 '$1' 치환을 JS에서
* 직접 하면 shell/ResourceLoader를 거치며 '$1'이 소실되는 문제가 있었으므로
* 문자열 치환을 쓰지 않는다. MediaWiki:Vector-2022.js의 구버전은 깨진 링크를
* 만들고 이 스크립트와 같은 DOM을 경쟁하므로 게시하지 않는다.
*/
mw.loader.using( 'mediawiki.util' ).then( function () {
function init() {
var title = mw.config.get( 'wgPageName' );
if ( title !== '대문' ) return;

var API = mw.config.get( 'wgScriptPath' ) + '/api.php';

function timeAgo( d ) {
var s = Math.floor( ( Date.now() - d.getTime() ) / 1000 );
if ( s < 60 ) return '방금 전';
if ( s < 3600 ) return Math.floor( s / 60 ) + '분 전';
if ( s < 86400 ) return Math.floor( s / 3600 ) + '시간 전';
if ( s < 604800 ) return Math.floor( s / 86400 ) + '일 전';
return d.toLocaleDateString( 'ko-KR' );
}

function esc( s ) { var e = document.createElement( 'span' ); e.textContent = s; return e.innerHTML; }

/* Feed 렌더러: 최근 활동/새 문서 공용. 대문 자기 자신은 제외한다. */
function renderFeed( rootId, entries, limit ) {
var root = document.getElementById( rootId );
if ( !root ) return;
var cs = entries.filter( function ( c ) { return c.title !== '대문'; } ).slice( 0, limit );
if ( !cs.length ) { root.innerHTML = '<div class="cx-empty">아직 기록이 없습니다.</div>'; return; }
var h = '<ul class="cx-feed">';
cs.forEach( function ( c ) {
var cls = c.type === 'new' ? 'cx-dot-new' : 'cx-dot-edit';
var t = new Date( c.timestamp );
var ago = timeAgo( t );
var href = mw.util.getUrl( c.title );
var diff = mw.util.getUrl( 'Special:Diff/' + c.revid );
h += '<li><span class="cx-dot ' + cls + '"></span>'
+ '<span class="cx-feed-main">'
+ '<span class="cx-feed-title"><a href="' + href + '">' + esc( c.title ) + '</a></span>'
+ ( c.comment ? '<span class="cx-feed-comment">' + esc( c.comment ) + '</span>' : '' )
+ '</span>'
+ '<span class="cx-feed-meta">' + ago + ' — ' + esc( c.user )
+ ' · <a href="' + diff + '">차이</a></span></li>';
} );
root.innerHTML = h + '</ul>';
}

var rcRoot = document.getElementById( 'cx-recent-root' );
if ( rcRoot ) {
var p = ['action=query','list=recentchanges','rclimit=12','rcprop=title|timestamp|user|type|comment|ids','rcshow=!bot','rctype=edit|new','rcnamespace=0','format=json','formatversion=2'].join( '&' );
fetch( API + '?' + p )
.then( function ( r ) { return r.json(); } )
.then( function ( d ) { renderFeed( 'cx-recent-root', ( d.query || {} ).recentchanges || [], 8 ); } )
.catch( function () { rcRoot.innerHTML = '<div class="cx-empty">활동 정보를 불러올 수 없습니다.</div>'; } );
}

var newRoot = document.getElementById( 'cx-new-root' );
if ( newRoot ) {
var np = ['action=query','list=recentchanges','rclimit=8','rcprop=title|timestamp|user|type|comment|ids','rcshow=!bot','rctype=new','rcnamespace=0','format=json','formatversion=2'].join( '&' );
fetch( API + '?' + np )
.then( function ( r ) { return r.json(); } )
.then( function ( d ) { renderFeed( 'cx-new-root', ( d.query || {} ).recentchanges || [], 5 ); } )
.catch( function () { newRoot.innerHTML = '<div class="cx-empty">새 문서 정보를 불러올 수 없습니다.</div>'; } );
}

var stRoot = document.getElementById( 'cx-stats-root' );
if ( stRoot ) {
Promise.all( [
fetch( API + '?action=query&meta=siteinfo&siprop=statistics&format=json&formatversion=2' ).then( function ( r ) { return r.json(); } ),
fetch( API + '?action=query&list=allcategories&aclimit=500&format=json&formatversion=2' ).then( function ( r ) { return r.json(); } )
] )
.then( function ( results ) {
var s = ( results[0].query || {} ).statistics || {};
var cats = ( ( results[1].query || {} ).allcategories || [] ).length;
stRoot.innerHTML = '<div class="cx-stats">'
+ '<div class="cx-stat"><div class="cx-stat-num">' + ( s.articles || 0 ) + '</div><div class="cx-stat-label">문서</div></div>'
+ '<div class="cx-stat"><div class="cx-stat-num">' + ( s.edits || 0 ) + '</div><div class="cx-stat-label">편집</div></div>'
+ '<div class="cx-stat"><div class="cx-stat-num">' + cats + '</div><div class="cx-stat-label">카테고리</div></div>'
+ '<div class="cx-stat"><div class="cx-stat-num">' + ( s.files || 0 ) + '</div><div class="cx-stat-label">파일</div></div>'
+ '</div>';
} )
.catch( function () { stRoot.innerHTML = ''; } );
}
}

if ( document.readyState === 'loading' ) {
document.addEventListener( 'DOMContentLoaded', init );
} else {
init();
}
} );

/* 자동 문서 생성 (AutoCreate.js) 로드: 텍스트 선택 → 초안 생성/승인 */
mw.loader.load( mw.config.get( 'wgScriptPath' ) + '/index.php?title=MediaWiki:AutoCreate.js&action=raw&ctype=text/javascript' );

/* ───────── Network Graph (interactive, vanilla JS) ───────── */
( function () {
if ( !window.mw || !mw.config ) return;
if ( mw.config.get( 'wgPageName' ) !== '대문' ) return;

var GRAPH_ROOT = document.getElementById( 'cx-graph-root' );
if ( !GRAPH_ROOT ) return;
if ( GRAPH_ROOT.getAttribute( 'data-cx-graph-inited' ) ) return;
GRAPH_ROOT.setAttribute( 'data-cx-graph-inited', '1' );

var API = mw.config.get( 'wgScriptPath' ) + '/api.php';
var pageLinks = {}; // title -> array of linked titles
var allTitles = new Set();

var prevContinueKeys = [];
function fetchAll( url, collect ) {
return fetch( url ).then( function ( r ) { return r.json(); } ).then( function ( data ) {
if ( data && data.query ) collect( data.query );
if ( data && data.continue ) {
var params = new URLSearchParams( data.continue );
var base = url.split( '?' )[0];
var qs = new URLSearchParams( url.split( '?' )[1] || '' );
qs.delete( 'continue' );
prevContinueKeys.forEach( function ( k ) { qs.delete( k ); } );
params.forEach( function ( v, k ) { qs.append( k, v ); } );
prevContinueKeys = Array.from( params.keys() );
return fetchAll( base + '?' + qs.toString(), collect );
}
} );
}

function collectQuery( query ) {
( query.pages || [] ).forEach( function ( page ) {
if ( !page.title || page.title === '대문' ) return;
allTitles.add( page.title );
var links = [];
( page.links || [] ).forEach( function ( l ) {
if ( l.title && l.ns === 0 && l.title !== '대문' ) links.push( l.title );
} );
pageLinks[ page.title ] = links;
} );
}

function buildData() {
var titles = Array.from( allTitles );
var index = {};
titles.forEach( function ( t, i ) { index[ t ] = i; } );

var edges = [];
var inCount = {};
titles.forEach( function ( t ) { inCount[ t ] = 0; } );
Object.keys( pageLinks ).forEach( function ( src ) {
pageLinks[ src ].forEach( function ( dst ) {
if ( index[ dst ] !== undefined ) {
inCount[ dst ]++;
edges.push( [ index[ src ], index[ dst ] ] );
}
} );
} );

var connected = new Set();
edges.forEach( function ( e ) { connected.add( e[0] ); connected.add( e[1] ); } );
var keptTitles = titles.filter( function ( t, i ) { return connected.has( i ); } );
if ( keptTitles.length < 3 ) {
GRAPH_ROOT.innerHTML = '<div class="cx-empty" style="padding:2em;text-align:center">아직 연결된 페이지가 충분하지 않습니다.</div>';
return;
}

var keptIndex = {};
keptTitles.forEach( function ( t, i ) { keptIndex[ t ] = i; } );
var keptEdges = edges
.filter( function ( e ) { return keptIndex[ titles[ e[0] ] ] !== undefined && keptIndex[ titles[ e[1] ] ] !== undefined; } )
.map( function ( e ) { return [ keptIndex[ titles[ e[0] ] ], keptIndex[ titles[ e[1] ] ] ]; } );

var maxIn = 1;
keptTitles.forEach( function ( t ) { maxIn = Math.max( maxIn, inCount[ t ] ); } );
initInteractiveGraph( keptTitles, keptEdges, inCount, maxIn );
}

function initInteractiveGraph( titles, edges, inCount, maxIn ) {
var W = GRAPH_ROOT.clientWidth || 860;
var H = 480;
var N = titles.length;

var pos = new Array( N );
var vel = new Array( N );
var rng = 1;
function rand() { rng = ( rng * 16807 ) % 2147483647; return ( rng - 1 ) / 2147483646; }
for ( var i = 0; i < N; i++ ) {
pos[ i ] = { x: W / 2 + ( rand() - 0.5 ) * W * 0.6, y: H / 2 + ( rand() - 0.5 ) * H * 0.6 };
vel[ i ] = { x: 0, y: 0 };
}

var REPULSION = 900, SPRING = 0.05, CENTER = 0.02, DAMPING = 0.85, REST_LEN = 90;
function stepSim( iters ) {
for ( var iter = 0; iter < iters; iter++ ) {
for ( var a = 0; a < N; a++ ) {
for ( var b = a + 1; b < N; b++ ) {
var dx = pos[ a ].x - pos[ b ].x, dy = pos[ a ].y - pos[ b ].y;
var dist = Math.sqrt( dx * dx + dy * dy ) || 1;
var force = REPULSION / ( dist * dist );
vel[ a ].x += ( dx / dist ) * force; vel[ a ].y += ( dy / dist ) * force;
vel[ b ].x -= ( dx / dist ) * force; vel[ b ].y -= ( dy / dist ) * force;
}
}
edges.forEach( function ( e ) {
var sa = pos[ e[0] ], sb = pos[ e[1] ];
var dx = sb.x - sa.x, dy = sb.y - sa.y;
var dist = Math.sqrt( dx * dx + dy * dy ) || 1;
var force = ( dist - REST_LEN ) * SPRING;
vel[ e[0] ].x += ( dx / dist ) * force; vel[ e[0] ].y += ( dy / dist ) * force;
vel[ e[1] ].x -= ( dx / dist ) * force; vel[ e[1] ].y -= ( dy / dist ) * force;
} );
for ( var c = 0; c < N; c++ ) {
vel[ c ].x += ( W / 2 - pos[ c ].x ) * CENTER;
vel[ c ].y += ( H / 2 - pos[ c ].y ) * CENTER;
}
for ( var m = 0; m < N; m++ ) {
vel[ m ].x *= DAMPING; vel[ m ].y *= DAMPING;
pos[ m ].x += vel[ m ].x; pos[ m ].y += vel[ m ].y;
pos[ m ].x = Math.max( 15, Math.min( W - 15, pos[ m ].x ) );
pos[ m ].y = Math.max( 15, Math.min( H - 15, pos[ m ].y ) );
}
}
}
stepSim( 220 );

// Adjacency for highlighting
var adj = [];
for ( var i = 0; i < N; i++ ) adj.push( {} );
var edgeNeighbors = new Array( edges.length );
edges.forEach( function ( e, ei ) {
adj[ e[0] ][ e[1] ] = true;
adj[ e[1] ][ e[0] ] = true;
edgeNeighbors[ ei ] = e;
} );

var nodeR = [], nodeColor = [];
titles.forEach( function ( t, i ) {
var ratio = ( inCount[ t ] || 0 ) / maxIn;
nodeR[ i ] = 6 + 10 * ratio;
nodeColor[ i ] = 'rgb(' + Math.round( 37 + ( 1 - ratio ) * 160 ) + ',' + Math.round( 99 + ( 1 - ratio ) * 80 ) + ',' + Math.round( 235 - ratio * 80 ) + ')';
} );

// Build DOM
GRAPH_ROOT.innerHTML = '';

var controls = document.createElement( 'div' );
controls.className = 'cx-graph-controls';
var search = document.createElement( 'input' );
search.type = 'text';
search.placeholder = '페이지 검색...';
search.className = 'cx-graph-search';
var legend = document.createElement( 'div' );
legend.className = 'cx-graph-legend';
legend.textContent = '크기/색 = 연결 수 · 드래그로 이동 · 휠 줌 · 배경 드래그로 이동';
controls.appendChild( search );
controls.appendChild( legend );
GRAPH_ROOT.appendChild( controls );

var svg = document.createElementNS( 'http://www.w3.org/2000/svg', 'svg' );
svg.setAttribute( 'viewBox', '0 0 ' + W + ' ' + H );
svg.setAttribute( 'preserveAspectRatio', 'xMidYMid meet' );
svg.setAttribute( 'class', 'cx-graph-svg' );
GRAPH_ROOT.appendChild( svg );

var content = document.createElementNS( 'http://www.w3.org/2000/svg', 'g' );
svg.appendChild( content );
var edgeLayer = document.createElementNS( 'http://www.w3.org/2000/svg', 'g' );
var nodeLayer = document.createElementNS( 'http://www.w3.org/2000/svg', 'g' );
content.appendChild( edgeLayer );
content.appendChild( nodeLayer );

var tooltip = document.createElement( 'div' );
tooltip.className = 'cx-graph-tooltip';
tooltip.style.opacity = '0';
GRAPH_ROOT.appendChild( tooltip );

// View transform (pan/zoom)
var view = { k: 1, tx: 0, ty: 0 };
function applyView() {
content.setAttribute( 'transform', 'translate(' + view.tx + ',' + view.ty + ') scale(' + view.k + ')' );
}

// Edge elements
var lineEls = edges.map( function ( e ) {
var line = document.createElementNS( 'http://www.w3.org/2000/svg', 'line' );
line.setAttribute( 'class', 'cx-graph-link' );
edgeLayer.appendChild( line );
return { line: line, e: e };
} );

// Node + label elements
var nodeEls = titles.map( function ( t, i ) {
var g = document.createElementNS( 'http://www.w3.org/2000/svg', 'g' );
g.setAttribute( 'class', 'cx-graph-node-group' );
var circle = document.createElementNS( 'http://www.w3.org/2000/svg', 'circle' );
circle.setAttribute( 'r', nodeR[ i ] );
circle.setAttribute( 'fill', nodeColor[ i ] );
circle.setAttribute( 'class', 'cx-graph-node' );
circle.style.cursor = 'pointer';
g.appendChild( circle );
var text = document.createElementNS( 'http://www.w3.org/2000/svg', 'text' );
text.setAttribute( 'text-anchor', 'middle' );
text.setAttribute( 'class', 'cx-graph-label' );
text.textContent = t.length > 18 ? t.slice( 0, 16 ) + '...' : t;
g.appendChild( text );
nodeLayer.appendChild( g );
return { g: g, circle: circle, text: text, i: i, title: t };
} );

function draw() {
lineEls.forEach( function ( o ) {
var e = o.e;
o.line.setAttribute( 'x1', pos[ e[0] ].x );
o.line.setAttribute( 'y1', pos[ e[0] ].y );
o.line.setAttribute( 'x2', pos[ e[1] ].x );
o.line.setAttribute( 'y2', pos[ e[1] ].y );
} );
nodeEls.forEach( function ( o ) {
o.g.setAttribute( 'transform', 'translate(' + pos[ o.i ].x + ',' + pos[ o.i ].y + ')' );
o.text.setAttribute( 'dy', -( nodeR[ o.i ] + 5 ) );
} );
}
draw();
applyView();

// Hover highlight
function setHighlight( i ) {
var active = i !== null && i >= 0;
lineEls.forEach( function ( o ) {
var e = o.e;
var conn = active && ( e[0] === i || e[1] === i );
o.line.setAttribute( 'class', 'cx-graph-link' + ( conn ? ' cx-graph-link-active' : '' ) );
} );
nodeEls.forEach( function ( o ) {
if ( i === null ) {
o.circle.setAttribute( 'class', 'cx-graph-node' );
o.text.style.opacity = '1';
return;
}
var conn = o.i === i || ( active && adj[ i ][ o.i ] );
o.circle.setAttribute( 'class', 'cx-graph-node' + ( conn ? ' cx-graph-node-active' : ' cx-graph-node-dim' ) );
o.text.style.opacity = conn ? '1' : '0.25';
} );
}
function showTooltip( title, i, ev ) {
tooltip.textContent = title + ' · 연결 ' + ( inCount[ title ] || 0 ) + '개';
tooltip.style.opacity = '1';
var rect = GRAPH_ROOT.getBoundingClientRect();
tooltip.style.left = ( ev.clientX - rect.left + 12 ) + 'px';
tooltip.style.top = ( ev.clientY - rect.top - 34 ) + 'px';
}
function hideTooltip() { tooltip.style.opacity = '0'; }

// Node drag + click. Pointer capture retargets pointermove/pointerup
// and the derived click event to the capture target, which would break
// node dragging and node click navigation. Use window-level listeners.
var dragging = null, dragMoved = false;
function clientToSvg( clientX, clientY ) {
var pt = svg.createSVGPoint ? svg.createSVGPoint() : null;
if ( pt && svg.getScreenCTM ) {
pt.x = clientX; pt.y = clientY;
var ctm = svg.getScreenCTM();
if ( ctm ) { var p = pt.matrixTransform( ctm.inverse() ); return { x: p.x, y: p.y }; }
}
var rect = svg.getBoundingClientRect();
return { x: clientX - rect.left, y: clientY - rect.top };
}
function onDragMove( ev ) {
if ( dragging === null ) return;
var w = clientToSvg( ev.clientX, ev.clientY );
var wx = ( w.x - view.tx ) / view.k;
var wy = ( w.y - view.ty ) / view.k;
var dx = wx - pos[ dragging ].x, dy = wy - pos[ dragging ].y;
if ( Math.abs( dx ) + Math.abs( dy ) > 3 ) dragMoved = true;
pos[ dragging ].x = Math.max( 15, Math.min( W - 15, wx ) );
pos[ dragging ].y = Math.max( 15, Math.min( H - 15, wy ) );
vel[ dragging ].x = 0; vel[ dragging ].y = 0;
stepSim( 4 );
draw();
}
function onDragEnd() {
if ( dragging === null ) return;
dragging = null;
window.removeEventListener( 'pointermove', onDragMove );
window.removeEventListener( 'pointerup', onDragEnd );
window.removeEventListener( 'pointercancel', onDragEnd );
}
function onNodePointerDown( ev, i ) {
if ( ev.button !== undefined && ev.button !== 0 ) return;
ev.preventDefault();
dragging = i;
dragMoved = false;
window.addEventListener( 'pointermove', onDragMove );
window.addEventListener( 'pointerup', onDragEnd );
window.addEventListener( 'pointercancel', onDragEnd );
}

nodeEls.forEach( function ( o ) {
o.g.addEventListener( 'pointerdown', function ( ev ) { onNodePointerDown( ev, o.i ); } );
o.g.addEventListener( 'pointermove', function ( ev ) {
if ( dragging !== null ) return;
showTooltip( o.title, o.i, ev );
setHighlight( o.i );
} );
o.g.addEventListener( 'pointerleave', function () {
if ( dragging === null ) { setHighlight( null ); hideTooltip(); }
} );
o.g.addEventListener( 'click', function () {
if ( !dragMoved ) window.location.href = mw.util.getUrl( o.title );
} );
} );
// Background pan
var panning = false, panStart = null;
svg.addEventListener( 'pointerdown', function ( ev ) {
if ( dragging !== null ) return;
if ( ev.button !== undefined && ev.button !== 0 ) return;
panning = true;
panStart = { x: ev.clientX, y: ev.clientY, tx: view.tx, ty: view.ty };
} );
svg.addEventListener( 'pointermove', function ( ev ) {
if ( dragging !== null ) return; // node drag handled on window
if ( panning && panStart ) {
view.tx = panStart.tx + ( ev.clientX - panStart.x );
view.ty = panStart.ty + ( ev.clientY - panStart.y );
applyView();
}
} );
svg.addEventListener( 'pointerup', function () { panning = false; panStart = null; } );
svg.addEventListener( 'pointerleave', function () { panning = false; panStart = null; } );
// Zoom (focal point precise even with viewBox letterboxing)
svg.addEventListener( 'wheel', function ( ev ) {
ev.preventDefault();
var w = clientToSvg( ev.clientX, ev.clientY );
var px = w.x, py = w.y;
var factor = ev.deltaY < 0 ? 1.15 : 0.87;
var newK = Math.max( 0.3, Math.min( 4, view.k * factor ) );
var ratio = newK / view.k;
view.tx = px - ( px - view.tx ) * ratio;
view.ty = py - ( py - view.ty ) * ratio;
view.k = newK;
applyView();
}, { passive: false } );
// Search
search.addEventListener( 'input', function () {
var q = search.value.trim().toLowerCase();
if ( !q ) { setHighlight( null ); return; }
var found = -1;
titles.forEach( function ( t, i ) {
if ( t.toLowerCase().indexOf( q ) === 0 && found === -1 ) found = i;
} );
if ( found === -1 ) {
titles.forEach( function ( t, i ) {
if ( t.toLowerCase().indexOf( q ) > -1 && found === -1 ) found = i;
} );
}
setHighlight( found );
if ( found > -1 ) {
view.k = Math.max( view.k, 1.4 );
view.tx = W / 2 - pos[ found ].x * view.k;
view.ty = H / 2 - pos[ found ].y * view.k;
applyView();
}
} );
}

var base = API + '?action=query&generator=allpages&gaplimit=50&gapnamespace=0&prop=links&pllimit=100&format=json&formatversion=2';
fetchAll( base, collectQuery )
.then( buildData )
.catch( function () {
GRAPH_ROOT.innerHTML = '<div class="cx-empty" style="padding:2em;text-align:center">그래프를 불러오지 못했습니다.</div>';
} );
} )();

미디어위키:Common.css

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:36 GMT

migrate: import legacy Wiki content to Vultr

새 문서

/* Conaonda Wiki - Main Page Styles */
/*
* 게시 위치: MediaWiki:Common.css (스킨 비의존).
* 기존 MediaWiki:Vector-2022.css의 스타일을 이식하고 카테고리 칩/피드
* 레이아웃을 추가했다. Vector-2022.css는 라이브 위키에서 삭제한다.
*/

/* Reset within #cx-main */
#cx-main, #cx-main * { box-sizing: border-box; }
#cx-main {
max-width: 880px; margin: 0 auto; padding: 0 1em 2em;
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Noto Sans KR", sans-serif;
color: #1a1a1a;
}

/* Hero */
.cx-hero {
text-align: center; padding: 2.4em 0 1.6em;
background: linear-gradient(135deg, #0f172a 0%, #1e3a5f 100%);
color: #fff; border-radius: 12px; margin-bottom: 1.6em;
}
.cx-hero-badge {
display: inline-block; font-size: 0.7em; letter-spacing: 0.3em;
background: rgba(255,255,255,0.12); border: 1px solid rgba(255,255,255,0.25);
border-radius: 20px; padding: 3px 14px; margin-bottom: 0.8em; font-weight: 600;
color: #fff;
}
.cx-hero-title {
/* Vector 스킨의 h1 색상 규칙(color-emphasized)이 상속을 덮어쓰므로 명시 지정 */
margin: 0; font-size: 2em; font-weight: 700; color: #fff;
text-shadow: 0 1px 3px rgba(0,0,0,0.35);
}
.cx-hero-sub { margin: 0.5em 0 0; font-size: 1em; opacity: 0.88; color: #fff; }

/* Topic Cards */
.cx-topics {
display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
gap: 12px; margin-bottom: 1.6em;
}
.cx-card {
background: #f8fafc; border: 1px solid #e2e8f0; border-radius: 10px;
padding: 1.1em 1em; transition: box-shadow 0.15s;
}
.cx-card:hover { box-shadow: 0 2px 12px rgba(0,0,0,0.07); }
.cx-card-icon { font-size: 1.5em; margin-bottom: 0.3em; }
.cx-card h3 { margin: 0 0 0.3em; font-size: 1.05em; }
.cx-card h3 a { text-decoration: none; color: #2563eb; }
.cx-card h3 a:hover { text-decoration: underline; }
.cx-card p { margin: 0; font-size: 0.88em; color: #475569; line-height: 1.45; }

/* Sections */
.cx-section { margin-bottom: 1.4em; }
.cx-section-title {
font-size: 1.05em; font-weight: 600; color: #1e3a5f;
border-bottom: 2px solid #1e3a5f; padding-bottom: 4px; margin-bottom: 10px;
}

/* Category Chips */
.cx-chips { display: flex; flex-wrap: wrap; gap: 8px; }
.cx-chips a {
display: inline-block; padding: 5px 12px; border-radius: 999px;
background: #eef2ff; border: 1px solid #c7d2fe; color: #3730a3;
text-decoration: none; font-size: 0.86em; transition: background 0.15s;
}
.cx-chips a:hover { background: #e0e7ff; }

/* Recent Feed */
.cx-feed { list-style: none; padding: 0; margin: 0; }
.cx-feed li {
display: flex; align-items: center; gap: 10px;
padding: 7px 0; border-bottom: 1px solid #f1f5f9; font-size: 0.92em;
}
.cx-feed li:last-child { border-bottom: none; }
.cx-dot { width: 9px; height: 9px; border-radius: 50%; flex-shrink: 0; }
.cx-dot-new { background: #16a34a; }
.cx-dot-edit { background: #2563eb; }
.cx-feed-main { display: flex; flex-direction: column; min-width: 0; }
.cx-feed-title a { text-decoration: none; color: #1a1a1a; font-weight: 500; }
.cx-feed-title a:hover { color: #2563eb; }
.cx-feed-comment {
color: #64748b; font-size: 0.84em; overflow: hidden;
text-overflow: ellipsis; white-space: nowrap; max-width: 520px;
}
.cx-feed-meta {
color: #94a3b8; font-size: 0.85em; margin-left: auto;
white-space: nowrap; flex-shrink: 0;
}
.cx-feed-meta a { color: #2563eb; text-decoration: none; }
.cx-feed-meta a:hover { text-decoration: underline; }
.cx-empty { color: #94a3b8; font-style: italic; padding: 0.6em 0; }
.cx-spinner { text-align: center; padding: 1.6em; color: #94a3b8; }

/* Stats */
.cx-stats {
display: flex; gap: 16px; flex-wrap: wrap;
background: #f1f5f9; border-radius: 10px; padding: 1em 1.2em; margin-bottom: 1.4em;
}
.cx-stat { text-align: center; flex: 1; min-width: 80px; }
.cx-stat-num { font-size: 1.5em; font-weight: 700; color: #1e3a5f; }
.cx-stat-label { font-size: 0.78em; color: #64748b; margin-top: 2px; }

/* Quick Nav */
.cx-quicknav { display: flex; flex-wrap: wrap; gap: 8px; }
.cx-quicknav a {
display: inline-block; padding: 6px 14px; border-radius: 8px;
background: #f1f5f9; color: #334155; text-decoration: none;
font-size: 0.88em; transition: background 0.15s;
}
.cx-quicknav a:hover { background: #e2e8f0; }

/* Network Graph */
#cx-graph-root {
position: relative;
width: 100%;
border: 1px solid #e2e8f0;
border-radius: 10px;
background: #f8fafc;
overflow: hidden;
min-height: 480px;
}
#cx-graph-root svg {
display: block;
width: 100%;
height: 480px;
touch-action: none;
}
#cx-graph-root .cx-spinner {
position: absolute;
inset: 0;
display: flex;
align-items: center;
justify-content: center;
}
.cx-graph-node:hover {
cursor: pointer;
stroke: #2563eb;
stroke-width: 3px;
}
.cx-graph-link {
stroke: #cbd5e1;
stroke-opacity: 0.6;
stroke-width: 1.2px;
}
.cx-graph-label {
font-size: 11px;
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Noto Sans KR", sans-serif;
fill: #334155;
pointer-events: none;
}
.cx-graph-tooltip {
position: absolute;
background: #1e293b;
color: #fff;
padding: 4px 10px;
border-radius: 6px;
font-size: 12px;
pointer-events: none;
white-space: nowrap;
z-index: 10;
}

/* Interactive graph controls */
.cx-graph-controls {
display: flex;
align-items: center;
gap: 10px;
padding: 8px 10px;
border-bottom: 1px solid #e2e8f0;
background: #fff;
}
.cx-graph-search {
flex: 0 0 auto;
width: 170px;
padding: 5px 10px;
border: 1px solid #cbd5e1;
border-radius: 6px;
font-size: 13px;
font-family: inherit;
}
.cx-graph-search:focus {
outline: none;
border-color: #2563eb;
box-shadow: 0 0 0 2px rgba(37, 99, 235, 0.15);
}
.cx-graph-legend {
font-size: 12px;
color: #64748b;
}
.cx-graph-node-dim {
opacity: 0.15;
}
.cx-graph-node-active {
stroke: #2563eb;
stroke-width: 3px;
}
.cx-graph-link-active {
stroke: #2563eb;
stroke-opacity: 0.9;
stroke-width: 2px;
}
#cx-graph-root {
min-height: 540px;
}

미디어위키:AutoCreate.js

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:35 GMT

migrate: import legacy Wiki content to Vultr

새 문서

/* Conaonda Wiki - 텍스트 선택 자동 문서 생성 (MediaWiki:AutoCreate.js) */
/*
* 위키 페이지에서 텍스트를 선택하면 X(트위터) 모바일처럼 플로팅 메뉴가
* 나타난다. '페이지 자동 생성'을 누르면 Worker(/api/generate)가 OpenCode Zen으로
* 위키텍스트 초안을 생성하고, 'Conaonda Wiki:초안/<키워드>' 문서로 저장한다.
* '승인 · 본문으로 이동' 버튼으로 본문 문서로 이동(history 보존)할 수 있다.
* 로그인 사용자만 동작한다.
*/
( function () {
if ( !window.mw || !mw.config ) return;
if ( !mw.config.get( 'wgUserName' ) ) return;
if ( !mw.loader || !mw.loader.using ) return;
mw.loader.using( 'mediawiki.util' ).then( function () { start(); } );

function start() {
var API = mw.config.get( 'wgScriptPath' ) + '/api.php';
var MAX_TITLE = 60;

/* ---------- DOM helpers ---------- */
function el( tag, className, text ) {
var node = document.createElement( tag );
if ( className ) node.className = className;
if ( text !== undefined ) node.textContent = text;
return node;
}
function css( node, props ) {
for ( var key in props ) node.style[key] = props[key];
}

var MENU_STYLE = {
position: 'fixed', zIndex: 99999, background: '#fff', color: '#202122',
border: '1px solid #a2a9b1', borderRadius: '4px',
boxShadow: '0 2px 8px rgba(0,0,0,.25)', padding: '4px 0',
fontFamily: 'inherit', fontSize: '13px', minWidth: '160px'
};
var ITEM_STYLE = { padding: '7px 14px', cursor: 'pointer', whiteSpace: 'nowrap' };
var OVERLAY_STYLE = {
position: 'fixed', top: '0', left: '0', width: '100%', height: '100%',
background: 'rgba(0,0,0,.45)', zIndex: 100000,
display: 'flex', alignItems: 'center', justifyContent: 'center'
};
var PANEL_STYLE = {
background: '#fff', color: '#202122', borderRadius: '6px', padding: '20px 24px',
maxWidth: '440px', width: 'calc(100% - 48px)',
boxShadow: '0 4px 16px rgba(0,0,0,.3)', fontSize: '14px', lineHeight: '1.6'
};

var menuEl = null;
var overlayEl = null;

/* ---------- 선택 감지와 플로팅 메뉴 ---------- */
function isEditable( node ) {
while ( node && node.nodeType === 1 ) {
var tag = node.tagName.toLowerCase();
if ( tag === 'input' || tag === 'textarea' || node.isContentEditable ) return true;
node = node.parentNode;
}
return false;
}

function selectionInfo() {
var sel = window.getSelection();
if ( !sel || sel.isCollapsed || !sel.rangeCount ) return null;
if ( isEditable( sel.anchorNode ) || isEditable( sel.focusNode ) ) return null;
var text = sel.toString().replace( /\s+/g, ' ' ).trim();
if ( text.length < 2 || text.length > MAX_TITLE ) return null;
return { text: text, rect: sel.getRangeAt( 0 ).getBoundingClientRect() };
}

function hideMenu() {
if ( menuEl ) { menuEl.remove(); menuEl = null; }
}

function showMenu( info ) {
hideMenu();
menuEl = el( 'div', 'cx-gen-menu' );
css( menuEl, MENU_STYLE );
var item = el( 'div', 'cx-gen-item', '⚡ 페이지 자동 생성' );
css( item, ITEM_STYLE );
item.addEventListener( 'mouseenter', function () { item.style.background = '#eaf3ff'; } );
item.addEventListener( 'mouseleave', function () { item.style.background = ''; } );
item.addEventListener( 'click', function ( e ) {
e.preventDefault();
e.stopPropagation();
var keep = info.text;
hideMenu();
startGenerate( keep );
} );
menuEl.appendChild( item );
document.body.appendChild( menuEl );
var x = info.rect.left;
var y = ( info.rect.bottom || info.rect.top ) + 6;
var width = menuEl.offsetWidth;
var height = menuEl.offsetHeight;
if ( x + width > window.innerWidth - 8 ) x = Math.max( 8, window.innerWidth - width - 8 );
if ( y + height > window.innerHeight - 8 ) y = Math.max( 8, ( info.rect.top || info.rect.bottom ) - height - 6 );
menuEl.style.left = Math.max( 8, x ) + 'px';
menuEl.style.top = Math.max( 8, y ) + 'px';
}

function onSelection() {
var info = selectionInfo();
if ( !info ) { hideMenu(); return; }
showMenu( info );
}

document.addEventListener( 'mouseup', onSelection );
document.addEventListener( 'touchend', function () { setTimeout( onSelection, 0 ); } );
document.addEventListener( 'scroll', hideMenu, true );
window.addEventListener( 'resize', hideMenu );
document.addEventListener( 'mousedown', function ( e ) {
if ( menuEl && !menuEl.contains( e.target ) ) hideMenu();
} );

/* ---------- 오버레이/결과 UI ---------- */
function hideOverlay() {
if ( overlayEl ) { overlayEl.remove(); overlayEl = null; }
}

function showOverlay( inner ) {
hideOverlay();
overlayEl = el( 'div', 'cx-gen-overlay' );
css( overlayEl, OVERLAY_STYLE );
var panel = el( 'div', 'cx-gen-panel' );
css( panel, PANEL_STYLE );
panel.appendChild( inner );
overlayEl.appendChild( panel );
document.body.appendChild( overlayEl );
}

function styleButton( button, primary ) {
css( button, {
border: primary ? '1px solid #36c' : '1px solid #a2a9b1',
background: primary ? '#36c' : '#f8f9fa', color: primary ? '#fff' : '#202122',
borderRadius: '2px', padding: '6px 14px', cursor: 'pointer', fontSize: '13px'
} );
}

function showGenerating( title ) {
var box = el( 'div' );
var spinner = el( 'div', 'cx-gen-spinner', '⏳' );
css( spinner, { fontSize: '28px', textAlign: 'center', marginBottom: '10px' } );
var msg = el( 'div', null, '「' + title + '」 문서를 생성하는 중입니다...' );
css( msg, { textAlign: 'center', fontWeight: '600' } );
var sub = el( 'div', null, '완료되면 초안을 확인하거나 승인할 수 있습니다.' );
css( sub, { textAlign: 'center', color: '#72777d', fontSize: '12px', marginTop: '6px' } );
box.appendChild( spinner );
box.appendChild( msg );
box.appendChild( sub );
showOverlay( box );
}

function showError( message ) {
var box = el( 'div' );
var msg = el( 'div', null, '❌ ' + message );
css( msg, { color: '#b32424', fontWeight: '600', marginBottom: '14px' } );
var close = el( 'button', null, '닫기' );
styleButton( close, false );
close.addEventListener( 'click', hideOverlay );
box.appendChild( msg );
box.appendChild( close );
showOverlay( box );
}

function showExists( urlOrTitle ) {
var box = el( 'div' );
var msg = el( 'div', null, '이미 작성된 문서입니다.' );
css( msg, { fontWeight: '700', marginBottom: '14px' } );
var open = el( 'button', null, '문서 열기' );
styleButton( open, true );
open.addEventListener( 'click', function () {
location.href = /^https?:/.test( urlOrTitle ) ? urlOrTitle : mw.util.getUrl( urlOrTitle );
} );
var close = el( 'button', null, '닫기' );
styleButton( close, false );
close.addEventListener( 'click', hideOverlay );
box.appendChild( msg );
box.appendChild( open );
box.appendChild( close );
showOverlay( box );
}

function showResult( info ) {
var box = el( 'div' );
var head = el( 'div', null, '✅ 초안이 생성되었습니다.' );
css( head, { fontWeight: '700', marginBottom: '6px' } );
var sub = el( 'div', null, '「' + info.title + '」 초안: ' + info.draftTitle );
css( sub, { color: '#54595d', fontSize: '12px', marginBottom: '16px', wordBreak: 'break-all' } );
var row = el( 'div' );
css( row, { display: 'flex', gap: '8px', flexWrap: 'wrap' } );
var draftBtn = el( 'button', null, '초안 보기' );
styleButton( draftBtn, false );
draftBtn.addEventListener( 'click', function () { location.href = mw.util.getUrl( info.draftTitle ); } );
var approveBtn = el( 'button', null, '승인 · 본문으로 이동' );
styleButton( approveBtn, true );
approveBtn.addEventListener( 'click', function () { approve( info ); } );
var close = el( 'button', null, '닫기' );
styleButton( close, false );
close.addEventListener( 'click', hideOverlay );
row.appendChild( draftBtn );
row.appendChild( approveBtn );
row.appendChild( close );
box.appendChild( head );
box.appendChild( sub );
box.appendChild( row );
showOverlay( box );
}

function showApproved( title ) {
var box = el( 'div' );
var msg = el( 'div', null, '✅ 「' + title + '」 문서로 게시되었습니다.' );
css( msg, { fontWeight: '700', marginBottom: '14px' } );
var open = el( 'button', null, '문서 열기' );
styleButton( open, true );
open.addEventListener( 'click', function () { location.href = mw.util.getUrl( title ); } );
var close = el( 'button', null, '닫기' );
styleButton( close, false );
close.addEventListener( 'click', hideOverlay );
box.appendChild( msg );
box.appendChild( open );
box.appendChild( close );
showOverlay( box );
}

/* ---------- API 호출 ---------- */
function getToken( type ) {
return fetch( API + '?action=query&meta=tokens&type=' + type + '&format=json&formatversion=2' )
.then( function ( r ) { return r.json(); } )
.then( function ( d ) {
var token = d.query && d.query.tokens && d.query.tokens[ type + 'token' ];
if ( !token ) throw new Error( '인증 토큰을 받지 못했습니다.' );
return token;
} );
}

function createDraft( info ) {
return getToken( 'csrf' ).then( function ( token ) {
var body = new URLSearchParams();
body.set( 'action', 'edit' );
body.set( 'title', info.draftTitle );
body.set( 'text', info.wikitext );
body.set( 'token', token );
body.set( 'summary', '자동 생성 초안 (AI)' );
body.set( 'watchlist', 'nochange' );
body.set( 'format', 'json' );
body.set( 'formatversion', '2' );
return fetch( API + '?action=edit&format=json&formatversion=2', {
method: 'POST',
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
body: body
} ).then( function ( r ) { return r.json(); } );
} ).then( function ( d ) {
if ( d.error ) throw new Error( d.error.info || d.error.code );
if ( !d.edit || d.edit.result !== 'Success' ) throw new Error( '초안 저장에 실패했습니다.' );
return info;
} );
}

function approve( info ) {
var box = el( 'div', null, '본문 문서로 이동하는 중...' );
css( box, { fontWeight: '600' } );
showOverlay( box );
getToken( 'csrf' ).then( function ( token ) {
var body = new URLSearchParams();
body.set( 'action', 'move' );
body.set( 'from', info.draftTitle );
body.set( 'to', info.title );
body.set( 'token', token );
body.set( 'reason', '자동 생성 초안 승인' );
body.set( 'suppressredirect', '1' );
body.set( 'format', 'json' );
body.set( 'formatversion', '2' );
return fetch( API + '?action=move&format=json&formatversion=2', {
method: 'POST',
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
body: body
} ).then( function ( r ) { return r.json(); } );
} ).then( function ( d ) {
if ( d.error ) throw new Error( d.error.info || d.error.code );
if ( !d.move || d.move.from !== info.draftTitle ) throw new Error( '이동 결과를 확인할 수 없습니다.' );
showApproved( info.title );
} ).catch( function ( e ) {
showError( '승인 실패: ' + ( e.message || '알 수 없는 오류' ) );
} );
}

function startGenerate( title ) {
showGenerating( title );
fetch( '/api/generate', {
method: 'POST',
headers: { 'Content-Type': 'application/json', 'X-Auto-Create': '1' },
body: JSON.stringify( { title: title } )
} ).then( function ( r ) {
return r.json().then( function ( j ) { return { status: r.status, body: j }; } );
} ).then( function ( res ) {
if ( res.status === 200 && res.body.ok ) return createDraft( res.body );
if ( res.status === 401 ) throw new Error( '로그인이 필요합니다.' );
if ( res.status === 409 ) { showExists( res.body.url || res.body.title ); return null; }
if ( res.status === 429 ) throw new Error( '요청이 너무 잦습니다. 잠시 후 다시 시도하세요.' );
if ( res.status === 400 ) throw new Error( '사용할 수 없는 제목입니다.' );
if ( res.status === 503 ) throw new Error( '자동 생성 기능이 아직 설정되지 않았습니다.' );
throw new Error( '생성에 실패했습니다. (' + res.status + ')' );
} ).then( function ( info ) {
if ( info ) showResult( info );
} ).catch( function ( e ) {
showError( e.message || '알 수 없는 오류입니다.' );
} );
}
}
} )();

허깅페이스

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:34 GMT

migrate: import legacy Wiki content to Vultr

새 문서

#넘겨주기 [[Hugging Face]]

하네스 엔지니어링

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:33 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''하네스 엔지니어링'''(harness engineering)은 언어 모델 주변의 실행 환경을 설계하고 구축하는 공학 분야이다. 모델이 사용하는 도구, 문맥, 메모리, 출력 처리와 안전장치를 포함하는 하네스(harness)를 만드는 작업을 가리킨다.

== 개요 ==
[[프롬프트 엔지니어링]]이 텍스트 입력이라는 단일 채널로 모델과 소통한다면, 하네스 엔지니어링은 모델이 외부 세계와 상호작용하는 모든 경로를 설계한다. 모델을 두뇌에 비유하면 하네스는 감각 기관과 몸에 해당한다.

에이전트 공학 문헌에서 하네스라는 용어는 모델을 둘러싼 환경·도구·문맥을 총칭하는 말로 사용된다. 에이전트 시스템의 성능은 모델의 능력만큼 하네스의 설계에 의해 결정되므로, LLM 애플리케이션 개발의 중심적인 작업이 되었다.

== 핵심 개념 ==

=== 문맥 관리 ===
모델의 컨텍스트 윈도우는 유한하므로, 무엇을 넣고 무엇을 빼는지가 성능을 결정한다. 대표적인 방법은 다음과 같다.
* 검색 증강 생성(RAG): 필요한 정보를 검색해 프롬프트에 주입한다.
* 대화 요약과 압축: 긴 대화를 요약해 문맥을 유지한다.
* 문맥 선별: 관련도가 낮은 내용을 버리고 중요한 정보를 보존한다.

=== 도구 정의와 호출 ===
하네스의 핵심 요소는 도구(tool)이다. 도구는 함수 호출(function calling) 형태로 모델에 노출되며, 모델이 생성한 호출을 하네스가 실행하고 그 결과를 다시 모델에 돌려준다. 파일 읽기, 웹 검색, API 호출, 데이터베이스 질의 등이 도구로 감싸진다.

=== 출력 처리 ===
모델 출력을 그대로 사용하지 않고 구조를 검증하고 변환한다. JSON 스키마 검증, 형식 오류 시 재시도, 출력 분류와 필터링 등이 포함된다.

=== 메모리 ===
대화 간 정보를 저장하고 꺼내 쓰는 장기 메모리와, 현재 작업의 상태를 유지하는 단기 메모리를 구분해 설계한다.

=== 가드레일 ===
입력과 출력에 대한 안전 규칙, 민감 정보 필터, 토큰·비용 제한 등을 하네스에 배치한다.

== 설계 원칙 ==
* 문맥은 자원이다: 컨텍스트 윈도우를 효율적으로 사용하도록 설계한다.
* 실패를 예상한다: 도구 호출 실패, 형식 오류, 비정상 출력을 처리하는 경로를 만든다.
* 관측 가능하게 만든다: 입력·출력·도구 호출을 기록해 문제를 진단할 수 있게 한다.

== 관련 공학 분야 ==
하네스는 프롬프트를 포함하는 상위 계층이다. [[프롬프트 엔지니어링]]으로 해결되지 않는 정보·도구·상태 문제는 하네스에서 다룬다. 하네스 위에서 반복 실행을 설계하는 것이 [[루프 엔지니어링]], 여러 실행 경로를 조율하는 것이 [[그래프 엔지니어링]]이다.

== 함께 보기 ==
* [[프롬프트 엔지니어링]]
* [[루프 엔지니어링]]
* [[그래프 엔지니어링]]
* [[LLMOps]]

== 출처 ==
* [https://www.anthropic.com/engineering/building-effective-agents Anthropic: Building Effective Agents]
* [https://openai.com/index/a-practical-guide-to-building-agents/ OpenAI: A Practical Guide to Building Agents]
* [https://platform.openai.com/docs/guides/function-calling OpenAI 함수 호출 문서]

[[분류:AI 엔지니어링]]

피처 스토어

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:32 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''피처 스토어'''는 머신 러닝에서 모델 학습과 추론에 사용하는 피처(feature)를 저장·관리·제공하는 중앙 저장소이다. 데이터 과학자와 엔지니어가 정제된 재사용 가능한 피처를 공통 인터페이스로 사용할 수 있게 하며, 학습 환경과 운영 환경 사이의 일관성을 보장한다.

== 역할 ==
피처 스토어는 배치·실시간 파이프라인을 모두 지원하며, 피처 버전 관리, 메타데이터 관리, 접근 제어 등을 제공한다. 이를 통해 재현성을 높이고 데이터 누수(data leakage)를 줄이며 팀 간 협업을 돕는다. 학습-서빙 불일치(training-serving skew) 문제를 해결하는 대표적인 방법이기도 하다.

대표적인 오픈소스 구현으로 Feast가 있다.

== 함께 보기 ==

* [[ML 파이프라인]]
* [[MLOps]]

== 출처 ==

* [https://en.wikipedia.org/wiki/Feature_store 위키백과: Feature store]
* [https://feast.dev/ Feast 공식 사이트]

[[분류:머신 러닝]]
[[분류:데이터 엔지니어링]]

프롬프트 엔지니어링

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:31 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''프롬프트 엔지니어링'''(prompt engineering)은 대규모 언어 모델에 입력하는 프롬프트(지시문)를 설계하고 개선하여 원하는 출력을 얻는 실무이다. 모델의 파라미터를 변경하지 않고 텍스트 입력만으로 모델의 동작을 제어한다는 점에서, LLM 애플리케이션 개발의 가장 기본적인 계층에 해당한다.

== 개요 ==
프롬프트는 모델에게 주어지는 역할, 지시, 문맥, 예시, 출력 형식을 담은 텍스트이다. 프롬프트 엔지니어링은 이 텍스트를 작성하고, 평가하고, 수정하는 반복 과정이다. 모델 출력은 확률적이므로, 프롬프트의 효과는 개별 체감이 아니라 평가 데이터셋을 통한 측정으로 판단해야 한다.

프롬프트만으로 해결할 수 있는 문제에는 한계가 있다. 모델이 알지 못하는 정보, 실시간 정보, 외부 시스템과의 상호작용, 여러 단계의 검증이 필요한 작업은 프롬프트만으로는 부족하며, [[하네스 엔지니어링]]이나 [[루프 엔지니어링]]의 영역으로 넘어간다.

== 핵심 개념 ==

=== 프롬프트의 구성 요소 ===
* 지시(instruction): 모델이 수행할 작업을 명확하게 설명한다.
* 문맥(context): 작업에 필요한 배경 정보를 제공한다.
* 예시(few-shot): 입력-출력 쌍을 제시해 원하는 패턴을 보여준다.
* 출력 형식: JSON, 표, 목록 등 출력의 구조를 지정한다.
* 제약 조건: 길이, 언어, 금지 사항 등 출력의 경계를 정한다.

=== 주요 기법 ===
* 역할 부여(role prompting): 전문가 역할을 부여해 관점과 표현을 조정한다.
* 사고 사슬(Chain-of-Thought): 중간 추론 단계를 유도해 복잡한 문제의 정확도를 높인다.
* 자기 일관성(Self-Consistency): 여러 번 추론하게 한 뒤 다수결로 최종 답을 고른다.
* 출력 구조화: JSON 스키마나 마크다운 형식을 지정해 후처리와 연동을 쉽게 한다.
* 단계적 분해: 작업을 작은 단계로 나누어 각 단계를 별도로 지시한다.

=== 프롬프트 평가와 버전 관리 ===
프롬프트는 코드처럼 버전 관리하고 평가해야 한다. 입력-기대 출력 쌍을 모은 평가 세트를 만들어 프롬프트 변경 전후의 성능을 비교하고, 회귀(regression)를 막는다. LLM 애플리케이션에서 프롬프트의 관리와 평가는 [[LLMOps]]의 일부로 다루어진다.

== 한계와 고려사항 ==
* 프롬프트는 모델의 지식과 능력 범위를 넘어설 수 없다.
* 프롬프트에 민감한 모델은 문구의 작은 변화에도 출력이 크게 달라질 수 있다.
* 긴 프롬프트는 토큰 비용과 지연 시간을 늘린다.
* 프롬프트만으로 외부 데이터를 넣고 도구를 호출하는 것은 어려우며, [[하네스 엔지니어링]]의 영역이다.

== 함께 보기 ==
* [[하네스 엔지니어링]] — 프롬프트를 포함한 모델 주변 환경 전체를 설계한다.
* [[루프 엔지니어링]] — 반복 실행 구조를 설계한다.
* [[그래프 엔지니어링]] — 여러 실행 경로를 조율한다.
* [[LLMOps]]

== 출처 ==
* [https://platform.openai.com/docs/guides/prompt-engineering OpenAI 프롬프트 엔지니어링 가이드]
* [https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview Anthropic 프롬프트 엔지니어링 문서]
* [https://arxiv.org/abs/2201.11903 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (Wei et al., 2022)]
* [https://arxiv.org/abs/2203.11171 Self-Consistency Improves Chain of Thought Reasoning (Wang et al., 2022)]
* [https://www.promptingguide.ai/ Prompt Engineering Guide]

[[분류:머신 러닝]]
[[분류:AI 엔지니어링]]

트랜스포머

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:30 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''트랜스포머'''(transformer)는 어텐션(attention) 메커니즘을 중심으로 하는 인공신경망 구조이다. 2017년 논문 "Attention Is All You Need"에서 제안되었으며, 이후 대규모 언어 모델(LLM)을 비롯한 많은 최신 모델의 표준 기반이 되었다.

== 개요 ==
[[순환 신경망]]은 시퀀스를 순서대로 처리해야 해서 병렬화가 어렵고, 먼 거리의 정보를 전달하는 데 한계가 있었다. 트랜스포머는 순환 구조 없이 어텐션만으로 시퀀스 내 모든 위치 간의 관계를 직접 계산한다. 위치 간 의존성 계산이 병렬로 이루어지므로 대규모 데이터로 효율적으로 학습할 수 있다.

원래 기계 번역을 위한 인코더-디코더 구조로 제안되었지만, 이후 인코더 전용 구조(BERT 계열)와 디코더 전용 구조(GPT 계열)로 나뉘어 발전했다. 디코더 전용 트랜스포머는 대규모 언어 모델의 표준 구조가 되었으며, [[Llama.cpp]]나 [[GGUF]] 같은 로컬 추론 생태계도 이 구조를 기반으로 한다.

== 핵심 개념 ==

=== 어텐션 ===
어텐션은 입력 시퀀스의 각 위치가 다른 위치의 정보를 얼마나 참고할지 가중치로 표현하는 메커니즘이다. 각 위치는 쿼리(query), 키(key), 값(value) 벡터를 만들고, 쿼리와 키의 유사도에 따라 값의 가중합을 계산한다.

=== 셀프 어텐션 ===
셀프 어텐션은 시퀀스 내부의 위치들 사이에서 수행되는 어텐션이다. 각 토큰이 문장 안의 다른 토큰들과의 관계를 직접 학습할 수 있으며, 멀리 떨어진 토큰 사이의 의존성도 한 단계에 포착할 수 있다.

=== 멀티헤드 어텐션 ===
여러 개의 어텐션을 병렬로 수행하여 서로 다른 관점의 관계를 학습한다. 각 헤드는 서로 다른 표현 공간에서 의존성을 포착하며, 그 결과를 합쳐 다음 계층으로 전달한다.

=== 위치 인코딩 ===
어텐션 자체에는 순서 정보가 없으므로, 각 위치에 순서를 나타내는 위치 인코딩을 더해 시퀀스의 순서를 모델에 알려준다.

=== 계층 구성 ===
트랜스포머 계층은 어텐션과 피드포워드 계층으로 구성되며, 각 부분에 잔차 연결과 층 정규화를 사용한다. 디코더는 미래 토큰을 보지 못하게 하는 인과적 마스크를 적용해 자기회귀(autoregressive) 생성에 맞춘다.

== 변형과 활용 ==
* GPT 계열: 디코더 전용 구조로, 다음 토큰을 예측하는 방식으로 학습된 생성 모델. 대규모 언어 모델의 기반.
* BERT 계열: 인코더 전용 구조로, 문장 표현을 학습하는 데 사용된다.
* 비전 트랜스포머(ViT): 이미지를 패치로 나누어 트랜스포머에 입력하는 구조로, [[컨볼루션 신경망]] 기반 비전 모델을 대체하는 추세.
* 멀티모달: 이미지, 음성, 텍스트를 함께 다루는 모델에도 널리 사용된다.

== 함께 보기 ==
* [[다층 퍼셉트론]]
* [[순환 신경망]]
* [[컨볼루션 신경망]]
* [[Llama.cpp]]
* [[LLMOps]]

== 출처 ==
* [https://arxiv.org/abs/1706.03762 Attention Is All You Need (Vaswani et al., 2017)]
* [https://en.wikipedia.org/wiki/Transformer_(deep_learning_architecture) 위키백과: Transformer]
* [https://arxiv.org/abs/1810.04805 BERT: Pre-training of Deep Bidirectional Transformers (Devlin et al., 2018)]
* [https://arxiv.org/abs/2005.14165 An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale (Dosovitskiy et al., 2020)]

[[분류:인공신경망]]
[[분류:머신 러닝]]

컨볼루션 신경망

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:30 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''컨볼루션 신경망'''(convolutional neural network, CNN)은 합성곱(컨볼루션) 연산을 기반으로 하는 인공신경망 구조이다. 주로 이미지처럼 격자 구조를 가진 데이터를 처리하는 데 사용된다.

== 개요 ==
이미지는 픽셀이 2차원 격자로 배열된 구조적 데이터이다. 완전연결 계층만으로 이미지를 처리하면 가중치 수가 폭증한다. CNN은 합성곱 연산으로 지역적인 특징을 추출하고 가중치를 공유하여 파라미터 수를 크게 줄인다. 1998년 LeNet-5가 문서 인식에 사용되었고, 2012년 AlexNet이 ImageNet 대회에서 압도적인 성능을 보이면서 딥러닝 붐을 이끌었다.

== 핵심 개념 ==

=== 합성곱 계층 ===
합성곱 계층은 작은 필터(커널)를 입력 위에 슬라이딩하며 각 위치에서 내적을 계산해 특징 맵(feature map)을 만든다. 필터는 지역 수용 영역(local receptive field)의 패턴(모서리, 질감 등)을 감지하며, 전체 위치에 같은 가중치를 적용하는 가중치 공유를 통해 파라미터 수를 줄인다.

=== 패딩과 스트라이드 ===
패딩(padding)은 입력 가장자리에 0을 채워 특징 맵의 크기를 조절하고, 스트라이드(stride)는 필터가 이동하는 간격을 정한다. 두 요소는 특징 맵의 공간 크기를 결정한다.

=== 풀링 계층 ===
풀링은 지역의 대표값을 뽑아 공간 크기를 줄인다. 최대 풀링(max pooling)이 대표적이며, 위치 변화에 대한 강건성을 높이고 연산량을 줄인다.

=== 분류 계층 ===
여러 합성곱·풀링 계층을 거친 특징은 1차원으로 평탄화되어 완전연결 계층에서 최종 분류·회귀에 사용된다. 계층 사이에는 ReLU 같은 활성화 함수가 적용된다.

== 대표 구조 ==
* LeNet-5: 초기 CNN 구조.
* AlexNet: 대규모 이미지 분류에서 CNN을 각광받게 한 구조.
* VGG: 작은 필터를 깊게 쌓은 구조.
* ResNet: 잔차 연결(residual connection)로 깊은 신경망 학습을 가능하게 한 구조.
* GoogLeNet(Inception): 여러 크기의 필터를 병렬로 사용하는 구조.

== 활용과 발전 ==
CNN은 이미지 분류, [[객체 탐지]], 의미론적 분할 등 컴퓨터 비전 전반에 사용된다. 이후 이미지를 패치 단위로 나누어 [[트랜스포머]]에 입력하는 비전 트랜스포머(ViT)가 등장하면서, 비전 분야에서도 어텐션 기반 구조가 보편화되었다.

== 한계 ==
CNN은 지역적 패턴 추출에 강하지만, 멀리 떨어진 위치 사이의 의존성을 다루기 어렵다. 시계열이나 문장 같은 순차 데이터는 [[순환 신경망]]이나 [[트랜스포머]]가 더 적합하다.

== 함께 보기 ==
* [[다층 퍼셉트론]]
* [[순환 신경망]]
* [[트랜스포머]]

== 출처 ==
* [https://en.wikipedia.org/wiki/Convolutional_neural_network 위키백과: Convolutional neural network]
* [http://yann.lecun.com/exdb/publis/pdf/lecun-01a.pdf Gradient-Based Learning Applied to Document Recognition (LeCun et al., 1998)]
* [https://proceedings.neurips.cc/paper/2012/hash/c399862d3b9d6b76c8436e924a68c45b-Abstract.html ImageNet Classification with Deep Convolutional Neural Networks (Krizhevsky et al., 2012)]
* [https://arxiv.org/abs/1512.03385 Deep Residual Learning for Image Recognition (He et al., 2015)]

[[분류:인공신경망]]
[[분류:머신 러닝]]

최근 GitHub Star 연구 주제

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:28 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''최근 GitHub Star 연구 주제'''는 2026년 8월 16일에 확인한 GitHub Star 저장소를 기술 주제별 위키 문서로 연결한 탐색 목록이다. 단순한 즐겨찾기 나열이 아니라 각 저장소가 다루는 문제, 핵심 구조, 적용 가능성과 한계를 다시 찾기 쉽게 정리하는 것이 목적이다.

== 선정 기준 ==
스냅샷 시점에는 인증된 사용자의 Star 목록을 <code>per_page=30&sort=created&direction=desc</code>로 조회했다. 공개 여부를 확인한 뒤 공개 저장소만 대상으로 삼고, 그 밖의 항목에 관한 존재 수·이름·내용·메타데이터는 기록하지 않았다. 반환 목록에서 처음 나타난 공개 저장소 20개를 선정해 소유자·이름과 주제 문서만 표시한다.

GitHub REST API 공식 설명상 <code>sort=created</code>는 Star를 누른 시각을 기준으로 정렬하고 <code>direction=desc</code>는 최신순을 뜻한다. 이번 응답 표현에는 항목별 <code>starred_at</code> 값이 없어 개별 시각은 기록할 수 없었으므로, 아래 목록은 해당 요청에서 공개 항목의 상대 순서만 보존했다. 이 순서는 저장소의 생성일·최종 커밋일·인기도 순서를 뜻하지 않는다.

== AI 에이전트와 생성형 미디어 ==
{| class="wikitable"
! 순번 !! 연구 주제 !! 원본 저장소
|-
| 1 || [[AI 에이전트 UI 디자인 가드레일]] || [https://github.com/pbakaus/impeccable pbakaus/impeccable]
|-
| 2 || [[SRT 기반 화이트보드 애니메이션]] || [https://github.com/geeklee/srt-whiteboard-animation geeklee/srt-whiteboard-animation]
|-
| 3 || [[저사양 GPU 생성형 미디어 워크스테이션]] || [https://github.com/deepbeepmeep/Wan2GP deepbeepmeep/Wan2GP]
|-
| 4 || [[초저 VRAM LLM 추론]] || [https://github.com/lyogavin/airllm lyogavin/airllm]
|-
| 5 || [[에이전트 전용 브라우저]] || [https://github.com/browseros-ai/BrowserOS browseros-ai/BrowserOS]
|-
| 6 || [[에이전트 기반 비디오 편집]] || [https://github.com/diffusionstudio/editor diffusionstudio/editor]
|-
| 7 || [[멀티모달 에이전트 플러그인]] || [https://github.com/QwenLM/Qwen-MM-Plugins QwenLM/Qwen-MM-Plugins]
|}

== 디자인, 인터페이스와 3D ==
{| class="wikitable"
! 순번 !! 연구 주제 !! 원본 저장소
|-
| 8 || [[에디토리얼 다이어그램]] || [https://github.com/cathrynlavery/diagram-design cathrynlavery/diagram-design]
|-
| 9 || [[Qt 도킹 UI]] || [https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System githubuser0xFFFF/Qt-Advanced-Docking-System]
|-
| 10 || [[COG 웹 가시화]] || [https://github.com/conaonda/COGnito conaonda/COGnito]
|-
| 11 || [[AI 코딩 에이전트 작업 원칙]] || [https://github.com/multica-ai/andrej-karpathy-skills multica-ai/andrej-karpathy-skills]
|-
| 12 || [[고충실도 3D 시뮬레이션]] || [https://github.com/o3de/o3de o3de/o3de]
|}

== 컴퓨터 비전과 영상 정합 ==
{| class="wikitable"
! 순번 !! 연구 주제 !! 원본 저장소
|-
| 13 || [[Detector-Free 로컬 특징 정합]] || [https://github.com/zju3dv/LoFTR zju3dv/LoFTR]
|-
| 14 || [[Quality-Aware 템플릿 매칭]] || [https://github.com/cplusx/QATM cplusx/QATM]
|-
| 15 || [[Coarse-to-Fine 템플릿 매칭]] || [https://github.com/zhirui-gao/Deep-Template-Matching zhirui-gao/Deep-Template-Matching]
|}

== 개발 환경, 데이터와 과학 계산 ==
{| class="wikitable"
! 순번 !! 연구 주제 !! 원본 저장소
|-
| 16 || [[Python 개발 환경 베스트 프랙티스]] || [https://github.com/realpython/python-guide realpython/python-guide]
|-
| 17 || [[C++ 선언형 데이터 처리]] || [https://github.com/jeb2239/CINQ jeb2239/CINQ]
|-
| 18 || [[.NET 머신 러닝 프레임워크]] || [https://github.com/accord-net/framework accord-net/framework]
|-
| 19 || [[OpenGL 경량 GUI]] || [https://github.com/wjakob/nanogui wjakob/nanogui]
|-
| 20 || [[웨이블릿 변환]] || [https://github.com/rafat/wavelib rafat/wavelib]
|}

== 방법론 ==
# 인증된 사용자의 Star 저장소 목록을 <code>per_page=30&sort=created&direction=desc</code>로 GitHub REST API에 요청했다.
# 응답 배열의 순서를 유지하면서 공개 여부를 판별했다.
# 공개 저장소만 선별하고, 그 밖의 항목에 관한 정보는 기록하지 않았다.
# 남은 공개 항목 가운데 앞의 20개를 대상으로 저장소 README, 공식 문서, 원 논문 등 공개된 1차 출처를 확인했다.
# 저장소 이름을 그대로 페이지 제목으로 복사하지 않고, 다시 탐색하기 쉬운 한국어 기술 주제로 정규화했다.
# 각 문서는 정의, 개요, 핵심 구조와 작동 방식, 활용, 한계 및 주의점, 관련 문서와 출처를 같은 틀로 작성했다.

== 범위와 한계 ==
이 목록은 한 시점의 개인 Star 선택을 보여 주며 GitHub 전체의 인기 순위나 기술 분야의 대표 표본이 아니다. Star는 관심 표시일 뿐 실제 사용, 품질 보증, 보안 검토 또는 채택 결정을 의미하지 않는다. 저장소는 이후 이름, 공개 상태, 라이선스, 유지보수 상태와 내용이 바뀔 수 있다. 특히 보관되었거나 유지보수 전용인 프로젝트는 현재 상태를 각 주제 문서에서 따로 밝힌다.

API가 최신 Star 우선의 상대 순서를 제공했지만 응답 표현에 항목별 Star 시각이 없었기 때문에 “며칠 전에 추가했다” 같은 절대 시간 주장은 하지 않는다. 목록을 갱신할 때는 새 스냅샷 날짜와 선정 수를 다시 기록하고 기존 판본과 구분해야 한다. 기술 설명은 공식 공개 자료를 우선하지만 실제 성능과 호환성은 사용자의 데이터와 환경에서 별도 재현해야 한다.

== 함께 보기 ==
* [[하네스 엔지니어링]]
* [[비전 언어 모델]]
* [[객체 탐지]]
* [[MLOps]]

== 출처 ==
* [https://docs.github.com/en/rest/activity/starring?apiVersion=2022-11-28#list-repositories-starred-by-the-authenticated-user GitHub REST API: List repositories starred by the authenticated user]
* [https://api.github.com/user/starred?per_page=30&sort=created&direction=desc GitHub API 조회 URL] — 인증 없이 열면 동일한 개인 응답을 재현할 수 없다.
* 각 항목 옆의 GitHub 공식 저장소 링크와 개별 주제 문서의 출처 절을 함께 참조한다.

[[분류:GitHub Star 연구]]
[[분류:GitHub]]
[[분류:연구 목록]]

초저 VRAM LLM 추론

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:27 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''초저 VRAM LLM 추론'''은 거대한 언어 모델 전체를 GPU에 상주시킬 대신 계층이나 전문가 단위로 순차 적재해 작은 그래픽 메모리에서도 출력을 계산하는 실행 방식이다.

== 개요 ==

[https://github.com/lyogavin/airllm lyogavin/airllm]은 모델을 계층별 조각으로 분해하고 추론 시 한 번에 한 계층만 GPU에 올리는 방식으로 전체 모델 크기와 필요한 VRAM의 결합을 약화한다. README는 70B 모델을 단일 4GB GPU에서 양자화·증류·가지치기 없이 실행할 수 있다고 설명한다. 405B Llama 3.1은 8GB, DeepSeek-V3 671B는 약 12GB라는 예시도 제시한다. 이는 AirLLM 프로젝트가 공개한 실행 가능성 수치이며 처리량이나 대화 지연을 보장하는 독립 벤치마크는 아니다.

이 접근의 목적은 큰 모델을 빠르게 서비스하는 것보다, 보유한 GPU의 VRAM 때문에 모델을 아예 불러오지 못하는 장벽을 낮추는 데 있다. 모델 전체가 디스크와 시스템 메모리·GPU 사이를 오가므로 저장 공간과 입출력 성능이 중요해진다. AirLLM은 [[Hugging Face]] 모델 ID나 로컬 경로를 <code>AutoModel.from_pretrained</code>에 넘기는 인터페이스를 제공해 일반적인 Transformers 사용 방식과 비슷하게 접근하도록 한다.

== 핵심 구조/작동 방식 ==

=== 계층별 스트리밍 ===

처음 모델을 사용할 때 원본 가중치를 계층 단위로 분해해 저장한다. 생성 과정에서는 현재 계산에 필요한 계층만 GPU에 유지하고 다음 계층으로 교체한다. README의 표현대로 필요한 VRAM은 전체 파라미터 수보다 가장 큰 계층의 크기에 더 크게 좌우된다. <code>layer_shards_saving_path</code>로 분해된 모델의 저장 위치를 지정할 수 있고, 저장 공간이 부족하면 <code>delete_original</code>로 원본을 지우고 변환본만 남기는 선택지도 있다.

<code>prefetching</code>은 다음 계층을 미리 읽어 현재 계산과 모델 적재를 겹친다. README는 이 기능을 기본으로 켜며, 당시 AirLLMLlama2 구현에서 지원한다고 명시한다. 2023년 업데이트에 기록된 10% 개선은 프로젝트가 측정한 특정 시점의 결과이므로 현재 모델과 장치에 그대로 적용되는 숫자로 보면 안 된다.

=== 선택적 압축과 MoE ===

기본 경로는 양자화 없이도 계층 스트리밍을 사용하지만, 디스크 읽기가 병목일 때 <code>compression='4bit'</code> 또는 <code>'8bit'</code>로 블록 단위 가중치 압축을 선택할 수 있다. README는 이 방식이 적재할 데이터 양을 줄여 최대 3배 속도 향상과 무시할 만한 정확도 손실을 낼 수 있다고 주장한다. 이 역시 연결된 논문과 프로젝트 평가에 근거한 수치이며 모델별 검증이 필요하다.

희소 Mixture-of-Experts 모델에서는 매 토큰이 선택한 전문가만 스트리밍하는 경로를 사용한다. 2026년 7월 README는 Kimi K3 2.8T 모델을 RTX 6000 Ada 한 장에서 종단 간 3.72GB VRAM으로 측정했다고 기록한다. 동시에 <code>compressed-tensors</code>, <code>flash-attn</code>, CUDA 12 계열 [[PyTorch]], 특정 Transformers 4.56.x 같은 버전 조건을 명시한다. “4GB 미만”이라는 결과보다 이처럼 엄격한 소프트웨어 조건을 함께 읽어야 한다.

=== 실행 인터페이스 ===

설치는 <code>pip install airllm</code>로 시작하고, <code>AutoModel</code>이 모델 유형을 자동 판별한다. 토크나이저로 입력을 만든 뒤 <code>generate</code>를 호출하고 결과 토큰을 디코딩하는 흐름은 일반 Transformers 코드와 유사하다. 설정에는 프로파일링, 계층 조각 경로, 게이트 모델용 [[Hugging Face]] 토큰, 프리페치와 원본 삭제가 포함된다. macOS에서는 Apple Silicon, MLX와 [[PyTorch]]를 요구하며 같은 Python 인터페이스를 사용한다.

== 활용 ==

연구자는 로컬에서 70B 이상 모델의 기능 호환성을 확인하거나, 낮은 빈도의 배치 추론과 모델별 출력 비교를 수행할 수 있다. 대형 모델을 한 번에 GPU에 올릴 수 없는 개인 PC에서는 작은 샘플과 짧은 생성을 먼저 시험하는 탐색 도구가 된다. [[저사양 GPU 생성형 미디어 워크스테이션]]이 이미지·영상 모델의 실행 범위를 넓히는 것과 마찬가지로, AirLLM은 언어 모델의 “적재 가능성”을 넓힌다. 로컬 에이전트 실험에서는 [[에이전트 전용 브라우저]]나 [[멀티모달 에이전트 플러그인]]이 호출할 추론 백엔드 후보가 될 수 있지만, 대화형 응답성을 실제 장치에서 따로 측정해야 한다.

== 한계 및 주의점 ==

낮은 VRAM은 낮은 총자원 사용량과 같은 뜻이 아니다. README는 첫 실행의 계층 분해가 디스크를 많이 쓰며, <code>MetadataIncompleteBuffer</code> 오류의 흔한 원인으로 저장 공간 부족을 든다. 큰 모델 원본과 변환본을 동시에 유지하면 여유 공간이 더 필요하고, 계층마다 디스크에서 읽는 구조에서는 저장장치 속도가 전체 지연에 직접 영향을 준다. 압축을 쓰지 않는 실행 가능성 주장과 4·8비트 압축을 사용한 속도 주장을 섞어 비교해서도 안 된다.

지원 모델이 넓다는 README 설명에도 원격 모델 코드, 토크나이저, FlashAttention, CUDA와 Transformers 버전이 충돌할 수 있다. 게이트 모델은 별도 [[Hugging Face]] 토큰과 사용 승인이 필요하다. 표의 VRAM 수치는 프롬프트 길이, 생성 길이, 캐시 설정과 하드웨어가 다른 환경의 상한을 대신하지 않는다. 2026년 8월 16일 기준 프로젝트 수치를 재현하려면 모델 리비전, AirLLM 버전, 의존성, 장치, 입력과 측정 방법을 함께 기록해야 한다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[저사양 GPU 생성형 미디어 워크스테이션]]
* [[멀티모달 에이전트 플러그인]]
* [[에이전트 전용 브라우저]]

== 출처 ==

* [https://github.com/lyogavin/airllm lyogavin/airllm README] — 계층 스트리밍, 모델별 VRAM 수치, 압축, 설치와 FAQ. 2026년 8월 16일 확인.
* [https://github.com/lyogavin/airllm/tree/main/air_llm/examples AirLLM 공식 예제] — 저장소가 제공하는 모델별 노트북과 실행 예시. 2026년 8월 16일 확인.

[[분류:대규모 언어 모델]]
[[분류:로컬 인공지능]]
[[분류:모델 추론]]
[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

저사양 GPU 생성형 미디어 워크스테이션

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:26 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''저사양 GPU 생성형 미디어 워크스테이션'''은 제한된 VRAM과 다양한 세대의 소비자 GPU에서 이미지·영상·음성 생성 모델을 설치하고 운용하기 위한 통합 실행 환경이다.

== 개요 ==

[https://github.com/deepbeepmeep/Wan2GP deepbeepmeep/Wan2GP]의 현재 제품명인 WanGP는 영상, 이미지, 오디오와 음성 합성 모델을 한 웹 인터페이스에서 다루는 오픈 소스 응용 프로그램이다. README는 Wan 2.1/2.2, LTX 계열, Hunyuan Video, Qwen Image, Flux, Qwen3 TTS 등 여러 계열을 예로 들며, 일부 모델은 6GB VRAM부터 실행할 수 있다고 밝힌다. 이 수치는 모든 모델과 출력 조건에 적용되는 최소 사양이 아니라 프로젝트가 선택한 모델과 설정에 대해 제시한 주장이다.

“워크스테이션”이라는 관점에서 중요한 점은 단일 생성 버튼보다 설치, 모델 선택, 체크포인트와 [[LoRA]] 관리, 입력 전처리, 작업 대기열, 결과 재사용, 후처리와 자동화가 한곳에 모인다는 것이다. 최신 고성능 GPU뿐 아니라 GTX 10 계열, RTX 20 계열 이후 NVIDIA 카드와 여러 AMD RDNA 세대를 위한 설치 경로도 문서화한다. 실제 지원 범위는 운영체제, [[PyTorch]]·CUDA 또는 AMD 소프트웨어 조합과 모델별 커널 요구 사항에 따라 달라진다.

== 핵심 구조/작동 방식 ==

=== 모델과 메모리 선택 ===

WanGP는 하드웨어 아키텍처에 맞는 모델 파일을 내려받고, int8, fp8, [[GGUF]], NVFP4, Nunchaku 등 여러 양자화 체크포인트 형식을 선택할 수 있게 한다. 모델에 따라 VRAM 우선 또는 시스템 RAM 우선 설정, 양자화된 텍스트 인코더와 VAE, 캐시 또는 단계 건너뛰기, [[LoRA]] 가속 프로필 같은 선택지를 제공한다. 이 기능은 하나의 보편적 메모리 기법이 아니라 각 모델 통합에 맞춘 선택지 집합이다. 따라서 같은 “저 VRAM” 설정이라도 처리 시간, 시스템 RAM, 품질과 호환성의 교환 관계가 다르다.

2026년 8월 16일 확인한 README는 [[MINIMA|MiniMa]]x H3 예시에서 5초 124프레임에 5~6GB, 832×480 15초에 8~9GB VRAM이라는 프로젝트 측 수치를 제시한다. 또 선택적 캐시, sparse attention, W4A8 체크포인트와 저메모리 VAE를 설명하면서, 일부 가속 조합은 동작이나 세부 품질을 줄일 수 있어 같은 시드로 비교하라고 권한다. 이런 수치는 버전, 모델 변형, 프레임 수, 해상도와 하드웨어에 종속되므로 독립적인 범용 벤치마크로 해석하면 안 된다.

=== 제작 인터페이스 ===

브라우저 UI에서는 생성 결과 갤러리, 설정 재사용과 템플릿 공유, 모델별 프롬프트 향상, [[LoRA]]와 사용자 체크포인트, 생성 대기열을 관리한다. 마스크 편집, 배경 제거, 자세·깊이·광류 추출, 화자 분리, 배경 소음이나 노래 제거 같은 입력 준비 도구도 포함한다. 공간·시간 업샘플링, 사운드트랙 생성, 음성 교체와 미디어 재다중화는 생성 뒤 후처리를 맡는다. Gallery Browser, Motion Designer, 모델 관리자와 커뮤니티 플러그인은 기본 UI를 확장한다.

=== 자동화 경로 ===

저장한 대기열은 웹 UI 없이 명령행에서 처리할 수 있고, WanGP API를 통해 다른 응용 프로그램이 생성 기능을 호출할 수 있다. README의 2026년 6월 변경 사항은 MCP 서버와 에이전트 스킬, 사용 가능한 모델과 기능을 조회하는 발견 기능을 소개한다. 오프라인 에이전트 Deepy는 생성 작업뿐 아니라 전사, 영상 분할과 색상 프레임 생성 같은 반복 작업을 조율한다. 이는 [[멀티모달 에이전트 플러그인]]이나 별도의 제작 에이전트가 로컬 생성 도구를 찾고 호출하는 연결점이 된다.

== 활용 ==

개인 제작자는 한 대의 PC에서 텍스트-이미지, 이미지-영상, 음성·음악 생성과 업샘플링을 시험하고 결과와 설정을 갤러리에서 다시 쓸 수 있다. 여러 작업을 대기열로 저장해 야간에 일괄 실행하거나, headless 모드로 반복 실험을 자동화할 수도 있다. 자체 앱을 만드는 경우 API 또는 MCP를 이용해 프롬프트와 입력 파일을 보내고, 결과를 [[에이전트 기반 비디오 편집]]이나 [[SRT 기반 화이트보드 애니메이션]]의 후속 공정에 전달할 수 있다. 다른 앱의 디렉터리에 저장된 [[LoRA]]를 재사용하는 기능은 대용량 자산의 중복 관리를 줄일 수 있다.

== 한계 및 주의점 ==

VRAM이 적게 든다는 설명은 저장 공간, 시스템 RAM, 다운로드 시간과 생성 시간을 없애지 않는다. README도 모델별로 최소 추론 단계, 양자화 형식, GPU 세대와 커널 조건을 구분하며, 고해상도·장시간 영상은 낮은 해상도로 생성한 뒤 업샘플링하는 현실적 대안을 제시한다. 브라우저가 GPU 메모리를 점유하는 경우 GPU 가속을 끈 별도 Chrome 실행 스크립트로 1~5GB를 확보할 수 있다는 설명도 프로젝트 측 팁이며 시스템마다 효과가 다를 수 있다.

설치 스크립트는 Python, [[PyTorch]], CUDA와 가속 커널을 함께 다루므로 기존에 안정적인 환경과 분리해 시험하는 편이 좋다. NVIDIA와 AMD, 구형 GTX와 최신 RTX의 설치 절차를 섞으면 안 되며 공식 설치 문서의 조합을 따라야 한다. 커뮤니티 플러그인과 외부 체크포인트는 본체와 별도로 출처, 라이선스, 모델 카드, 입력 데이터 정책을 확인해야 한다. README의 모델 목록과 성능 수치는 업데이트가 매우 잦으므로 버전과 확인 날짜를 기록해야 재현할 수 있다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[초저 VRAM LLM 추론]]
* [[에이전트 기반 비디오 편집]]
* [[멀티모달 에이전트 플러그인]]

== 출처 ==

* [https://github.com/deepbeepmeep/Wan2GP deepbeepmeep/Wan2GP README] — 지원 모델, 저 VRAM 주장, UI·대기열·API·MCP와 설치 개요. 2026년 8월 16일 확인.
* [https://github.com/deepbeepmeep/Wan2GP/blob/main/docs/INSTALLATION.md WanGP 공식 설치 문서] — GPU 세대별 환경 안내. 2026년 8월 16일 확인.
* [https://github.com/deepbeepmeep/Wan2GP/blob/main/docs/MODELS.md WanGP 공식 모델 문서] — 모델별 기능 안내. 2026년 8월 16일 확인.

[[분류:생성형 인공지능]]
[[분류:로컬 인공지능]]
[[분류:멀티미디어]]
[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

웨이블릿 변환

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:25 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''웨이블릿 변환'''은 신호를 위치 또는 시간과 스케일이 다른 짧은 파형 성분으로 분해하여 국소적인 변화와 주파수 구조를 함께 분석하는 수학적 도구이다. [https://github.com/rafat/wavelib wavelib]은 1차원·2차원 이산 웨이블릿 변환과 1차원 연속 웨이블릿 변환 등을 구현한 C 라이브러리이다.

== 개요 ==
푸리에 변환은 신호 전체에 걸친 주파수 성분을 보는 데 강하지만, 짧은 충격이나 경계가 어느 위치에서 발생했는지는 직접 드러내기 어렵다. 웨이블릿은 이동하고 늘이거나 줄인 기저 파형으로 신호를 비교해 위치와 스케일별 계수를 만든다. 큰 스케일은 완만한 추세를, 작은 스케일은 급격한 변화와 세부를 나타내는 식으로 다중 해상도 표현을 구성할 수 있다.

wavelib은 DWT·IDWT, SWT·ISWT, MODWT·IMODWT의 1차원 및 2차원 구현, 웨이블릿 패킷 트리, 최적 기저 DWPT, CWT와 근사적인 역 CWT를 제공한다. 저장소는 CMake 빌드 파일, 헤더와 소스, 시험 및 단위 시험, PDF 문서와 위키를 포함한다. 라이선스는 BSD 3-Clause이다. C API이므로 C++ 애플리케이션이나 다른 언어의 네이티브 바인딩에서 사용할 수 있지만 자료형, 버퍼 수명과 길이 조건을 호출자가 관리해야 한다.

== 핵심 구조/작동 방식 ==
DWT는 저역 통과와 고역 통과 필터로 근사 계수와 세부 계수를 만들고 다운샘플링한다. 이 과정을 근사 성분에 반복하면 해상도가 단계적으로 낮아지는 피라미드를 얻는다. 역변환 IDWT는 업샘플링과 합성 필터로 계수를 다시 결합한다. wavelib의 DWT와 2차원 DWT는 암시적 신호 확장과 업·다운샘플링을 사용하며 주기적 경계와 대칭 경계 옵션을 제공한다. 일반적인 경우 빠른 직접 구현을 쓰고 선택적으로 FFT 기반 구현을 사용할 수 있다.

SWT는 각 단계에서 다운샘플링하지 않는 정지 웨이블릿 변환이다. 입력 위치가 조금 이동할 때 계수 위치가 크게 달라지는 문제를 줄이는 대신 계수 수와 계산량이 증가한다. 공식 README에 따르면 wavelib의 SWT는 분해 수준을 J라 할 때 신호 길이가 2의 J제곱의 배수여야 한다. 다른 길이의 신호에는 MODWT를 검토할 수 있다.

MODWT는 최대 중첩 이산 웨이블릿 변환으로 역시 다운샘플링하지 않는 표현을 만든다. wavelib 구현은 임의 길이 신호를 처리하지만 Daubechies, Symlets, Coiflets 같은 직교 웨이블릿만 사용할 수 있다고 README가 제한한다. 어떤 변환을 선택할지는 이동 불변성, 메모리, 입력 길이와 웨이블릿 종류를 함께 고려해야 한다. 2차원 변환에서는 행과 열 방향 필터링으로 영상의 수평·수직·대각 세부 성분을 분리한다.

웨이블릿 패킷은 근사 분기뿐 아니라 세부 분기도 계속 나눈다. <code>WTREE</code>는 모든 노드의 계수를 보존하는 완전 다운샘플링 웨이블릿 트리여서 중복이 크며, 공식 문서는 압축과 잡음 제거에 권장하지 않는다. <code>DWPT</code>와 역변환은 엔트로피 기준으로 보존할 계수를 정해 비중복 결과를 만들며 출력 길이는 입력과 같은 차수이다. 이는 주파수 대역을 더 유연하게 나누고 데이터에 맞는 기저를 고르는 데 활용할 수 있다.

CWT는 스케일을 촘촘히 변화시키며 계수를 계산해 시간-스케일 지도를 만든다. wavelib의 CWT는 Torrence와 Compo가 제공한 연속 웨이블릿 소프트웨어의 C 변환을 바탕으로 하며 수정 사항을 포함한다. 일반화한 역변환도 제공하지만 README는 이를 근사 복원이라고 명시한다. CWT 결과는 국소 주기나 순간 이벤트를 시각화하기 좋지만 DWT보다 중복과 계산 비용이 크다.

== 활용 ==
잡음 제거에서는 작은 세부 계수를 임곗값 처리하고 역변환하여 원 신호를 복원한다. 압축에서는 에너지가 일부 계수에 모이는 성질을 이용해 중요 계수만 보존한다. 진동·음향·생체 신호에서는 짧은 이상과 시간에 따른 주파수 변화를 찾고, 영상에서는 다중 해상도 특징, 경계와 질감 분석에 사용할 수 있다. 센서 이상 탐지에서는 원 신호뿐 아니라 스케일별 에너지와 통계량을 머신 러닝 특징으로 만들 수 있다.

[[COG 웹 가시화]]와 결합하면 대형 영상 타일의 다중 해상도 분석 결과를 별도 밴드나 오버레이로 제공할 수 있다. [[Detector-Free 로컬 특징 정합]]이나 [[Coarse-to-Fine 템플릿 매칭]]의 입력 전처리·특징 분석에 웨이블릿을 시험할 수도 있지만, 이들 공식 모델이 wavelib을 사용한다는 뜻은 아니다. [[OpenGL 경량 GUI]]는 웨이블릿 종류, 경계 모드, 분해 수준과 임곗값을 실시간으로 바꾸는 데모를 만드는 선택지가 된다.

== 한계 및 주의점 ==
결과는 웨이블릿 계열, 분해 수준, 경계 확장, 계수 정규화와 임곗값에 민감하다. 같은 DWT라는 이름만으로 다른 라이브러리와 계수의 부호, 순서, 크기가 같다고 가정하면 안 된다. 짧은 신호에서는 경계 효과가 전체 계수의 상당 부분을 차지할 수 있다. 실제 적용에서는 알려진 시험 벡터로 정방향·역방향 오차와 에너지 보존을 확인하고, 경계 근처 결과를 따로 해석해야 한다.

SWT의 길이 제약과 MODWT의 직교 웨이블릿 제한을 입력 검사 없이 넘기면 잘못된 설정이나 실패로 이어질 수 있다. WTREE는 높은 중복 때문에 압축·잡음 제거에 부적합하다고 공식 README가 경고한다. CWT 역변환은 근사적이므로 완전 복원이 필요한 저장 형식으로 취급해서는 안 된다. 2차원 대형 영상과 다단 비다운샘플링 변환은 메모리 사용량이 커지므로 타일 경계의 겹침과 작업 버퍼를 설계해야 한다.

C 라이브러리를 서비스나 플러그인에 넣을 때는 배열 길이, 할당·해제 주체, 스레드 안전성, 오류 반환, 정밀도와 빌드 옵션을 래퍼에서 명확히 한다. 저장소의 예제와 단위 시험을 그대로 통과시키는 것과 목표 데이터에서 과학적으로 타당한 결과를 얻는 것은 별개이다. 신호 처리 파라미터는 도메인 전문가와 함께 검증하고, 잡음 제거가 실제 이상 신호까지 없애지 않는지 원본과 비교해야 한다.

== 함께 보기 ==
* [[최근 GitHub Star 연구 주제]]
* [[COG 웹 가시화]]
* [[Coarse-to-Fine 템플릿 매칭]]
* [[OpenGL 경량 GUI]]

== 출처 ==
* [https://github.com/rafat/wavelib rafat/wavelib 공식 저장소]
* [https://github.com/rafat/wavelib/wiki wavelib 공식 위키]
* [https://github.com/rafat/wavelib/blob/master/wavelib-doc.pdf wavelib 공식 PDF 문서]

[[분류:GitHub Star 연구]]
[[분류:신호 처리]]
[[분류:영상 처리]]
[[분류:웨이블릿]]

온디바이스 에이전트

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:24 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''온디바이스 에이전트'''는 계획, 추론, 도구 호출과 여러 단계 작업 수행을 클라우드 모델에 전적으로 의존하지 않고 사용자 장치나 엣지 컴퓨터에서 실행하는 AI 에이전트 구조다. [[Liquid AI]]의 [[LFM2.5]]-2.6B는 이러한 용도를 직접 겨냥한 소형 agentic model의 한 사례다.

== 개요 ==

일반적인 온디바이스 LLM은 텍스트 생성 자체가 목표인 경우가 많지만, 에이전트는 외부 기능을 호출해 실제 작업을 수행해야 한다. 따라서 모델의 크기와 생성 속도뿐 아니라 function calling 정확도, 긴 컨텍스트 처리, 여러 호출 사이의 상태 유지, 실패 복구와 권한 제어가 중요하다.

[[Liquid AI]]는 [[LFM2.5]]-2.6B를 네이티브 tool calling과 128K 컨텍스트를 갖춘 온디바이스 에이전트 모델로 소개한다. 공식 예제는 소비자 하드웨어에서 모델을 실행하고 Hermes Agent 같은 하네스와 결합해 파일, 검색, 애플리케이션 기능 등 로컬 도구를 호출하는 구성을 보여준다. 이 접근은 네트워크 연결이 끊겨도 일정 수준의 자동화를 유지할 수 있다는 점에서 클라우드 에이전트와 구별된다.

== 작동 방식 ==

온디바이스 에이전트의 기본 루프는 사용자 요청을 해석하고, 필요한 도구와 인자를 결정하며, 도구 실행 결과를 다시 모델 입력에 넣어 다음 행동을 결정하는 방식이다. 모델은 모든 업무 기능을 자체 파라미터로 기억할 필요가 없고 로컬 애플리케이션의 API나 함수 호출 인터페이스를 통해 기능을 확장한다.

엣지 환경에서는 이 구조에 별도의 정책 계층이 필요하다. 파일 삭제, 장비 제어, 네트워크 송신처럼 영향이 큰 작업은 사용자 승인 또는 명시적 권한 검사가 필요하고, 센서·카메라 입력을 사용하는 경우에는 VLM과 결합해 관찰-판단-행동 루프를 구성할 수 있다. 이러한 형태는 단순 챗봇보다 로봇·차량·산업 장비·현장 분석 단말에 더 가깝다.

== 활용 ==

대표적인 활용은 오프라인 개인 비서, 현장 정비 지원, 로컬 파일·문서 자동화, 차량 내 음성 에이전트, 로봇 행동 계획, 보안이 중요한 폐쇄망 업무 시스템이다. 지리정보나 영상 분석 소프트웨어에서는 사용자가 자연어로 목표를 입력하면 에이전트가 검색, 영상 열기, 좌표 조회, 분석 알고리즘 실행과 결과 정리를 순차적으로 호출하는 방식으로 구현할 수 있다.

작은 모델을 모든 추론에 사용하지 않고, 빠르고 반복적인 도구 선택은 로컬 모델에 맡기고 복잡한 판단만 더 큰 모델로 승격하는 계층형 에이전트 구조도 가능하다. 이는 응답 지연과 클라우드 비용을 줄이는 동시에 네트워크 장애 시 기본 기능을 유지하는 방법이 된다.

== 한계 및 주의점 ==

온디바이스라는 이유만으로 안전성이 높아지는 것은 아니다. 잘못된 tool call은 로컬 데이터나 장비에 즉시 영향을 줄 수 있으므로 도구 스키마 검증, 최소 권한, 실행 전 승인, 감사 로그가 중요하다. 작은 모델은 복잡한 계획에서 오류율이 높아질 수 있으며 긴 컨텍스트 지원 길이와 실제 안정적인 작업 길이는 동일하지 않다. 모델 벤치마크와 별도로 실제 업무 시나리오의 성공률을 측정해야 한다.

== 함께 보기 ==

* [[Liquid AI]]
* [[Liquid Foundation Model]]
* [[LEAP]]
* [[LFM2.5]]

== 출처 ==

* [https://www.liquid.ai/blog/lfm2-5-2-6b Liquid AI LFM2.5-2.6B 발표] — 온디바이스 agentic workload, tool calling과 성능 설명. 2026년 8월 18일 확인.
* [https://docs.liquid.ai/lfm/models/lfm25-2.6b LFM2.5-2.6B 공식 문서] — 모델 사양과 agent harness 연동. 2026년 8월 18일 확인.
* [https://docs.liquid.ai/examples/agent-harnesses Liquid AI agent harness 예제] — 로컬 에이전트 실행 방식. 2026년 8월 18일 확인.

[[분류:AI 에이전트]]
[[분류:온디바이스 인공지능]]
[[분류:엣지 인공지능]]

에이전트 전용 브라우저

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:23 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''에이전트 전용 브라우저'''는 사람이 쓰는 주 브라우저와 분리된 실행 공간에서 AI 에이전트가 로그인 상태의 웹 작업을 수행하고, 사용자가 진행 상황과 기록을 감독하도록 설계한 브라우저이다.

== 개요 ==

[https://github.com/browseros-ai/BrowserOS browseros-ai/BrowserOS] 저장소에는 서로 다른 두 제품이 함께 있다. BrowserOS neo는 AI 에이전트가 조작하는 보조 브라우저이고, BrowserOS는 사람이 일상적으로 사용하면서 새 탭의 내장 에이전트에게 일을 맡기는 Chromium 포크이다. “에이전트 전용 브라우저”라는 제목은 전자인 BrowserOS neo의 구분을 가리킨다. README는 neo가 Chrome 대체품이 아니라 Chrome 옆에서 에이전트 작업만 맡는 두 번째 브라우저라고 명시한다.

일반적인 headless 자동화가 깨끗한 새 프로필을 띄우는 것과 달리, neo는 Chrome에서 로그인, 북마크와 확장을 가져오고 세션 사이에 상태를 유지하는 흐름을 제시한다. Claude Code, Codex, Cursor 등 MCP를 지원하는 에이전트가 연결해 로그인된 웹사이트의 과업을 실행한다. 여러 에이전트는 각자 탭에서 병렬로 움직이며 사용자는 새 탭 대시보드에서 진행 상황을 보거나 저장된 세션을 나중에 재생할 수 있다.

== 핵심 구조/작동 방식 ==

=== 브라우저와 에이전트 플랫폼 ===

저장소는 Chromium 포크와 에이전트 플랫폼의 모노레포로 구성된다. 브라우저 쪽에는 Chromium 패치, 빌드 도구, 리소스와 서명 자산이 있고, 에이전트 쪽에는 MCP 엔드포인트와 JSON API를 제공하는 Rust 백엔드, 새 탭 대시보드 확장, 온보딩, Bun 기반 MCP 서버와 에이전트 루프, Go CLI가 있다. Chrome DevTools Protocol 형식 바인딩은 브라우저 조작 계층을 지원한다.

neo를 설치하면 기존 Chrome 데이터를 한 번에 가져오는 단계와 로컬 에이전트를 찾고 연결하는 단계가 이어진다. 연결된 에이전트는 웹 사용에 맞춘 MCP 도구로 과업을 보내고 각 세션을 독립 탭에서 실행한다. README는 macOS와 Windows용 neo 설치 파일을 제공하며, 사람이 쓰는 BrowserOS는 macOS·Windows·Linux를 지원한다고 구분한다.

=== 감독과 감사 기록 ===

대시보드는 현재 어느 에이전트가 어느 사이트에서 어떤 작업을 하는지와 진행 상태를 보여준다. 각 세션은 단계별 행동 타임라인과 탐색 가능한 영상 형태로 로컬 디스크에 저장된다. 문제가 생겼을 때 단순 성공·실패 로그만 보는 것이 아니라 어느 화면에서 무엇을 눌렀는지 되돌려 볼 수 있는 구조다. 사람은 실행 중 작업을 관찰하고, 완료 후에는 재생 기록으로 결과와 과정을 감사할 수 있다.

README는 세션, 스크린샷과 기록이 <code>~/.browserclaw/</code> 아래에 있고 업로드되지 않는다고 설명한다. 연결·해제, 버전과 운영체제 같은 익명 제품 사용 이벤트는 기본 정책에 포함되지만 URL, 페이지 내용, 프롬프트, 도구 결과와 스크린샷은 보내지 않으며 설정에서 끌 수 있다고 밝힌다. 이 내용은 프로젝트가 공개한 정책 설명이므로 실제 배포 버전의 설정과 네트워크 동작을 함께 확인해야 한다.

=== 사람용 BrowserOS와의 차이 ===

같은 저장소의 BrowserOS는 사람이 직접 탐색하는 브라우저에 에이전트를 넣은 제품이다. 20개 이상의 기본 도구와 40개 이상의 앱 통합, 페이지 요약·클릭 흐름·데이터 추출·예약 작업, MCP 서버 모드와 로컬 [[Ollama]]·LM Studio 연결을 README가 소개한다. neo가 외부 에이전트를 위한 작업장이라면 BrowserOS는 사람의 주 브라우징과 보조 에이전트를 한 화면에 결합한다. 두 제품의 역할을 섞지 않는 것이 설치와 보안 경계를 설계할 때 중요하다.

== 활용 ==

로그인이 필요한 반복 업무가 주요 대상이다. README는 소셜 미디어 게시와 참여 지표 수집, 받은편지함 정리와 구독 해지, CRM 갱신, 비용 처리, 내부 도구의 보고서 추출을 예로 든다. 여러 독립 과업을 각 탭에 병렬로 맡기고 대시보드에서 감독할 수 있다. [[AI 에이전트 UI 디자인 가드레일]]을 사용하는 개발 에이전트가 실제 웹 화면을 검사하거나, [[멀티모달 에이전트 플러그인]]이 이미지·문서를 이해한 결과를 로그인된 서비스에 입력하는 연결도 가능하다. 단, 외부 서비스의 허용 범위와 자동화 정책을 먼저 확인해야 한다.

== 한계 및 주의점 ==

로그인 상태를 가져오는 장점은 곧 높은 권한이라는 뜻이다. 이메일 삭제, 게시, 결제나 CRM 수정처럼 되돌리기 어려운 동작에는 사이트·계정별 권한 분리, 미리보기, 사람 승인과 결과 검증이 필요하다. 재생 영상과 스크린샷도 인증 정보나 개인 데이터를 포함할 수 있으므로 로컬 저장 디렉터리의 접근 권한, 보존 기간과 백업 범위를 정해야 한다.

README의 “다른 방식보다 토큰을 훨씬 적게 쓴다”는 설명에는 같은 페이지에서 재현 가능한 비교 조건과 수치가 제시되지 않으므로 프로젝트 측 주장으로만 다뤄야 한다. 로컬 실행이 웹서비스로 데이터가 전혀 나가지 않는다는 뜻도 아니다. 에이전트가 선택한 모델 공급자와 접속한 사이트에는 요청이 전송된다. 2026년 8월 16일 확인 시 README는 neo의 macOS·Windows 설치 파일을 제시하지만 공식 문서는 Linux 절차도 안내하므로, 실제 지원 범위는 해당 버전의 배포 파일과 설치 가이드를 함께 확인해야 한다. Chromium 포크 자체를 빌드하려면 README상 약 100GB의 디스크가 필요하다. 두 제품은 AGPL-3.0이지만 저장소의 외부 서비스와 확장에는 각자의 조건이 있을 수 있다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[AI 에이전트 UI 디자인 가드레일]]
* [[멀티모달 에이전트 플러그인]]
* [[에이전트 기반 비디오 편집]]

== 출처 ==

* [https://github.com/browseros-ai/BrowserOS browseros-ai/BrowserOS README] — neo와 사람용 BrowserOS의 기능, 플랫폼, 구조와 개인정보 설명. 2026년 8월 16일 확인.
* [https://docs.browseros.com/neo BrowserOS neo 공식 문서] — README가 연결하는 설치, MCP, 대시보드와 감사·재생 문서. 2026년 8월 16일 확인.
* [https://docs.browseros.com/neo/privacy BrowserOS neo 개인정보 문서] — 로컬 데이터와 사용 이벤트 정책. 2026년 8월 16일 확인.

[[분류:인공지능 에이전트]]
[[분류:웹 브라우저]]
[[분류:웹 자동화]]
[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

에이전트 기반 비디오 편집

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:22 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''에이전트 기반 비디오 편집'''은 AI 에이전트가 영상·음성을 분석하고 명령행과 코드로 타임라인을 구성하되, 결과를 사람이 일반 편집 화면에서 이어서 수정할 수 있게 하는 제작 방식이다.

== 개요 ==

[https://github.com/diffusionstudio/editor diffusionstudio/editor]의 Diffusion Studio는 에이전트를 위해 설계된 오픈 소스 비디오 편집기이다. 데스크톱 앱과 <code>dapi</code> 명령행 인터페이스를 함께 제공하며, 에이전트는 촬영본을 보고 듣는 분석 도구로 내용을 파악하고 타임라인을 자른다. 에이전트가 만든 결과는 완전한 편집 인터페이스에서 열리므로 사람이 타임라인, 요소와 자산을 그대로 이어서 다듬을 수 있다.

프로젝트가 대상으로 드는 작업은 원본 촬영본을 완성본으로 만드는 편집, 설명 영상·홍보 영상·타이틀 같은 모션 그래픽, 이미지·영상·음성 생성 자산의 합성, 긴 영상의 하이라이트 클립과 세로형 재구성, 장면 검색·요약·타임스탬프 인용을 포함한 영상 이해이다. 핵심은 자연어 요청을 한 번 실행하는 데 그치지 않고, 분석 결과와 편집 상태를 프로그램과 사람 모두가 접근할 수 있는 문서 구조로 남기는 데 있다.

== 핵심 구조/작동 방식 ==

=== 미디어를 보는 도구 ===

에이전트는 사람이 영상을 재생하는 대신 목적별 검사 명령을 조합한다. <code>dapi media probe</code>는 컨테이너와 코덱 메타데이터를, <code>grab</code>은 지정 시점 프레임을 PNG로, <code>filmstrip</code>은 여러 프레임의 격자를 만든다. <code>waveform</code>은 오디오 파형과 무음 구간을, <code>transcribe</code>는 단어 단위 시간이 포함된 전사를 제공한다. <code>listen</code>은 멀티모달 모델에 특정 구간의 발화를 묻고, <code>node capture</code>는 현재 캔버스를 캡처한다. 이 도구들을 통해 에이전트는 장면과 대사의 근거를 타임코드에 연결할 수 있다.

=== 코드로 만든 편집 문서 ===

컴포지션은 SolidJS 모듈로 작성한다. <code>dapi mount</code>가 JSX를 컴파일해 각 요소를 편집 문서의 노드로 렌더링하고, 같은 컴포지션을 다시 마운트하면 웹페이지를 다시 읽듯 해당 구조를 제자리에서 재구축한다. <code><For></code>, <code><Show></code> 같은 Solid 제어 흐름과 npm 패키지를 사용할 수 있다. 이미지·영상 생성은 <code>generate.image</code>, <code>generate.video</code> 같은 값으로 선언되고 마운트 시 만들어져 타임라인에 합성된다.

마운트가 만든 텍스트, 영상과 도형은 납작한 최종 영상으로만 남지 않고 편집 가능한 일급 노드로 유지된다. 따라서 에이전트가 코드로 반복 구조와 타이밍을 만들고, 사람은 UI에서 특정 제목의 위치나 컷 길이를 수정할 수 있다. 이는 코드 생성의 반복 가능성과 전통 편집기의 세밀한 수정을 연결하는 장치다.

=== 명령행 편집 루프 ===

가장 짧은 루프는 <code>dapi open</code>으로 앱이나 프로젝트를 열고, <code>dapi mount</code>로 컴포지션을 올린 뒤, <code>dapi node render</code>로 장면을 파일에 인코딩하는 세 단계이다. 실제 작업에서는 <code>context</code>로 장면·재생 위치·서체를 확인하고, <code>node</code> 하위 명령으로 트리 검색·패치·삽입·복사·삭제·캡처·렌더링을 수행한다. <code>asset</code>은 미디어 라이브러리, <code>project</code>·<code>folder</code>·<code>selection</code>은 문서 범위를 제어한다. 단일 결과는 JSON, 목록은 JSON Lines, 오류는 표준 오류와 종료 코드 1을 사용해 에이전트와 스크립트가 파이프로 연결하기 쉽게 한다.

== 활용 ==

폴더의 촬영본을 분석해 유튜브 영상의 초벌 컷을 만들고, 읽기 쉬운 자막과 도입부 그래픽을 추가한 뒤 사람이 마무리할 수 있다. 긴 인터뷰에서는 전사와 파형으로 핵심 30초를 찾아 세로형 소셜 영상으로 재구성할 수 있다. 브랜드 색·서체·타이밍을 코드 상수와 컴포넌트로 고정하면 반복되는 홍보 영상도 재생산하기 쉽다. [[SRT 기반 화이트보드 애니메이션]]의 장면 MP4, [[저사양 GPU 생성형 미디어 워크스테이션]]의 생성 영상·음성, [[멀티모달 에이전트 플러그인]]의 분석 결과를 한 타임라인으로 모으는 후속 공정에도 활용할 수 있다.

== 한계 및 주의점 ==

자동 전사, 프레임 표본과 멀티모달 질의는 전체 영상을 사람이 연속 시청한 것과 같지 않다. 중요한 컷이 filmstrip 표본 사이에 있거나, 발화자·음악·효과음의 맥락을 잘못 해석할 수 있으므로 최종 재생 검수가 필요하다. 에이전트가 타임라인을 구성해도 이야기의 리듬, 사실성, 초상·음원 권리와 브랜드 승인 책임이 사라지지 않는다.

2026년 8월 16일 확인한 README의 직접 다운로드는 macOS Apple Silicon 빌드를 가리킨다. 저장소에서 개발하려면 Node 20 이상과 npm이 필요하고, 웹 또는 Electron 데스크톱 환경을 별도로 설정한다. 생성 자산은 선택 가능한 모델·계정과 실행 환경에 의존할 수 있으므로 프로젝트를 다시 열었을 때 같은 결과가 필요한 경우 원본 자산과 버전, 프롬프트를 보존해야 한다. 코드 본체는 MPL-2.0이지만 <code>apps/desktop/assets</code>의 브랜드 자산은 그 라이선스에 포함되지 않는다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[SRT 기반 화이트보드 애니메이션]]
* [[저사양 GPU 생성형 미디어 워크스테이션]]
* [[멀티모달 에이전트 플러그인]]

== 출처 ==

* [https://github.com/diffusionstudio/editor diffusionstudio/editor README] — 에이전트 편집 흐름, 미디어 검사, JSX 컴포지션과 CLI 구조. 2026년 8월 16일 확인.
* [https://github.com/diffusionstudio/editor/blob/main/reference/README.md Diffusion Studio CLI 공식 참조] — README가 연결하는 명령별 옵션과 출력 문서. 2026년 8월 16일 확인.
* [https://github.com/diffusionstudio/editor/blob/main/reference/jsx/README.md Diffusion Studio JSX 공식 참조] — 구성 요소, 타이밍과 생성 자산 문서. 2026년 8월 16일 확인.

[[분류:영상 편집]]
[[분류:인공지능 에이전트]]
[[분류:생성형 인공지능]]
[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

에디토리얼 다이어그램

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:21 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''에디토리얼 다이어그램'''은 단순히 상자와 화살표를 배치하는 것을 넘어, 독자가 무엇을 먼저 보고 어떤 관계를 이해해야 하는지까지 편집 관점에서 설계한 설명용 시각 자료이다. 이 문서는 공개 프로젝트 [https://github.com/cathrynlavery/diagram-design cathrynlavery/diagram-design]가 제시하는 방식에 초점을 맞춘다.

== 개요 ==

에디토리얼 다이어그램은 정보의 양을 최대화하기보다 메시지의 우선순위, 시선의 흐름, 매체에 맞는 글자 크기와 밀도를 조정한다. 같은 시스템 구조라도 엔지니어용 문서, 경영진용 슬라이드, 웹 기사에 필요한 설명 수준은 다르다. 따라서 좋은 결과를 얻으려면 그릴 대상만이 아니라 독자, 출력 크기, 전달할 핵심 한두 가지를 먼저 정해야 한다.

diagram-design은 이러한 판단을 AI 코딩 에이전트가 반복해서 수행하도록 만든 MIT 라이선스의 공개 에이전트 스킬이다. 2026년 8월 16일 확인한 README 본문은 아키텍처, 흐름도, 시퀀스, 상태 머신, ER 모델, 타임라인, 스윔레인, 사분면, 트리, 레이어, 루프, 각종 차트 등 27개 시각 유형을 설명한다. 각 유형은 최소형 밝은 테마, 최소형 어두운 테마, 전체 에디토리얼형의 세 정적 변형을 제공하며 기본 산출물은 HTML 안의 SVG이다. Claude Code, Codex, Pi용 설치 경로와 명령 템플릿도 저장소에 포함되어 있다.

이 프로젝트의 설계 철학은 삭제와 강조의 절제에 가깝다. README는 모든 노드가 존재 이유를 가져야 하고, 강조색은 독자가 먼저 봐야 할 한두 요소에 한정하며, 낮은 시각 밀도를 목표로 삼는다고 설명한다. 이는 자동 생성 다이어그램에서 흔한 과도한 상자, 균일한 강조, 불필요한 장식 문제를 줄이려는 규칙이다.

== 핵심 구조/작동 방식 ==

작업은 대체로 다음 순서로 진행한다.

# '''의미와 독자 결정''': 요청을 바로 도형으로 바꾸지 않고, 보여 줄 관계가 구조인지 순서인지 상태 변화인지 비교인지 먼저 분류한다. 행동 설명이 중요하면 큐, 병목, 정책 추적, 보안 경계 같은 의미 패턴을 고른 뒤 가장 가까운 시각 유형을 선택한다.
# '''출력 제약 결정''': HTML·SVG·PNG 가운데 형식을 정하고, 문서 인라인·와이드 문서·16:9 슬라이드·소셜 카드·인쇄물 등 목적 크기를 고른다. <code>faithful</code>, <code>balanced</code>, <code>simplified</code> 세 상세도는 원본 노드의 보존 범위를 달리하며, <code>engineer</code>, <code>mixed</code>, <code>executive</code> 독자 설정은 표현을 바꾼다.
# '''브랜드 토큰 적용''': 배경, 본문, 보조 글자, 강조색, 링크색과 제목·본문·코드 글꼴을 의미 역할로 저장한다. 프로젝트는 웹사이트에서 후보 색상과 글꼴을 추출하고 변경안을 보여 주는 온보딩 절차를 제공한다. 본문색과 배경색은 작은 다이어그램 글자에서도 WCAG AA 대비를 충족하는지 검사한다.
# '''접근 가능한 SVG 생성''': 각 SVG에 <code>role="img"</code>, 연결된 <code><title></code>과 <code><desc></code>를 두고 장식 아이콘은 보조기술에서 숨긴다. 애니메이션은 기본적으로 끄며, 필요할 때만 <code>reveal</code>, <code>step</code>, <code>loop</code> 모드를 사용한다. 감소된 움직임 설정에서는 완성된 정적 프레임을 표시한다.
# '''검증과 내보내기''': HTML을 브라우저에서 확인한 뒤 SVG를 추출하거나 Playwright로 PNG를 래스터화한다. draw.io나 Mermaid를 가져올 때에는 구성요소, 관계, 그룹, 방향을 보존하되 원본 좌표·색·글꼴을 그대로 답습하지 않는다. 축약하거나 제거한 요소는 충실도 기록으로 남긴다.

저장소 구조도 점진적 공개를 따른다. 중심 <code>SKILL.md</code>가 먼저 행동과 유형 선택을 안내하고, 실제 요청에 필요한 유형별 참조, 의미 패턴, 애니메이션, 가져오기·내보내기 명세만 추가로 읽는다. 모든 유형의 긴 지침을 한꺼번에 문맥에 넣지 않는 방식이다.

== 활용 ==

에디토리얼 다이어그램은 소프트웨어 아키텍처와 데이터 흐름, 사용자 여정, 조직 책임, 제품 로드맵, 보안 정책, 비교 차트에 적합하다. [[AI 코딩 에이전트 작업 원칙]]과 결합하면 에이전트가 먼저 목적과 성공 기준을 명시한 뒤 결과를 렌더링하고 검증하도록 만들 수 있다. [[Qt 도킹 UI]]처럼 구성요소가 많거나 [[고충실도 3D 시뮬레이션]]처럼 여러 하위 시스템이 연결되는 주제를 설명할 때에도 관계의 층위를 줄여 보여 주는 데 유용하다.

기존 Mermaid 또는 draw.io 자료를 블로그, 발표자료, 인쇄물에 맞춰 다시 그리는 용도로도 활용할 수 있다. 같은 원본을 기술 독자용과 의사결정자용으로 나누어 표현하되 무엇을 합치고 생략했는지 기록하면, 보기 좋은 그림과 내용의 추적 가능성을 함께 확보할 수 있다.

== 한계 및 주의점 ==

다이어그램은 언제나 최선의 표현 형식은 아니다. 항목 목록, 정확한 값 비교, 간단한 전후 비교는 표나 문장이 더 명확할 수 있다. 시각적으로 정돈된 결과가 기술적 정확성을 보증하지도 않으므로, 구성요소 이름·연결 방향·수치·범례는 원자료와 별도로 검증해야 한다.

웹사이트 기반 브랜드 추출은 후보를 만드는 절차이지 공식 브랜드 승인 절차가 아니다. 동적으로 로드되는 글꼴, 다크 모드 토큰, 지역별 페이지가 누락될 수 있으며 외부 글꼴 사용 조건도 확인해야 한다. PNG 내보내기에는 Playwright와 브라우저 설치가 필요하고, 전체 에디토리얼 레이아웃과 SVG만 내보낸 결과의 범위가 다르다.

2026년 8월 16일 기준 저장소 소개 문구는 29개 유형이라고 표시하지만 README 본문과 갤러리 설명은 27개라고 적어 수량이 일치하지 않는다. 유형 수나 설치 명령은 빠르게 바뀔 수 있으므로 실제 설치 버전의 <code>SKILL.md</code>와 갤러리를 기준으로 확인해야 한다. 또한 AI가 만든 HTML을 배포하기 전에는 임의 스크립트, 외부 자원, 접근성, 보안 정책을 프로젝트 환경에서 다시 점검해야 한다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[AI 코딩 에이전트 작업 원칙]]
* [[Qt 도킹 UI]]
* [[고충실도 3D 시뮬레이션]]

== 출처 ==

* [https://github.com/cathrynlavery/diagram-design Diagram Design 공개 저장소 및 README] — 프로젝트 기능, 구조, 설치, 라이선스. 2026년 8월 16일 확인.
* [https://cathrynlavery.github.io/diagram-design/ Diagram Design 공식 갤러리] — 유형과 테마 예시. 2026년 8월 16일 확인.
* [https://github.com/cathrynlavery/diagram-design/blob/main/skills/diagram-design/references/output-spec.md 공식 출력 명세] — 형식, 크기, 상세도, 독자 설정. 2026년 8월 16일 확인.
* [https://github.com/cathrynlavery/diagram-design/blob/main/skills/diagram-design/references/animation.md 공식 애니메이션 명세] — 정적 기본값과 접근 가능한 움직임 규칙. 2026년 8월 16일 확인.

[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

실험 추적

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:19 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''실험 추적'''(experiment tracking)은 머신 러닝 실험의 하이퍼파라미터, 메트릭, 아티팩트(모델 파일·그래프 등)를 기록하고 비교하는 실무이다. [[MLOps]]에서 모델 개발의 재현성과 비교 가능성을 확보하는 기초 단계이다.

== 역할 ==
실험마다 설정·결과·실행 환경을 기록하면 어떤 설정이 어떤 성능을 냈는지 체계적으로 비교할 수 있고, 과거 실험을 재현할 수 있다. 대규모 모델 개발에서는 실험 수가 많아지므로 자동 기록과 대시보드 비교가 중요하다.

대표적인 도구로는 [[MLflow]] Tracking, Weights & Biases(W&B) 등이 있다.

== 함께 보기 ==

* [[MLOps]]
* [[모델 레지스트리]]

== 출처 ==

* [https://mlflow.org/docs/latest/tracking.html MLflow Tracking 문서]
* [https://wandb.ai/ Weights & Biases 공식 사이트]

[[분류:머신 러닝]]

순환 신경망

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:18 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''순환 신경망'''(recurrent neural network, RNN)은 시계열, 문장 같은 순차 데이터를 처리하기 위한 인공신경망 구조이다. 은닉 상태(hidden state)를 유지하며 이전 시점의 정보를 다음 시점으로 전달한다.

== 개요 ==
순차 데이터는 각 항목이 앞뒤 항목과 의미적으로 연결되어 있다. RNN은 시점(time step)마다 입력을 처리하면서 은닉 상태에 이전 정보를 축적하고, 이를 다음 시점의 계산에 사용한다. 모든 시점이 같은 가중치를 공유하므로 시퀀스 길이가 달라져도 파라미터 수는 변하지 않는다. 시퀀스 전체를 다루는 구조로는 인코더-디코더(시퀀스-시퀀스) 모델이 널리 사용되었다.

== 핵심 개념 ==

=== 은닉 상태와 순환 연결 ===
은닉 상태는 현재 시점까지의 정보를 요약한 벡터이다. 각 시점에서 이전 은닉 상태와 현재 입력을 결합해 새 은닉 상태를 만들고, 필요하면 출력을 계산한다. 이 순환 연결이 RNN과 일반 신경망의 차이이다.

=== 양방향 RNN ===
양방향 RNN은 순방향과 역방향으로 각각 처리한 은닉 상태를 결합하여, 각 위치가 이후의 정보도 참고할 수 있게 한다.

=== 시간 역전파 ===
RNN은 시간 방향으로 펼친 계산 그래프에 오차역전파를 적용한다(backpropagation through time, BPTT). 시퀀스가 길수록 기울기가 여러 단계를 거쳐 전파된다.

=== 장기 의존성 문제 ===
시퀀스가 길어지면 기울기가 점점 작아지거나(소실) 커지는(폭주) 현상이 발생해 먼 과거의 정보를 학습하기 어렵다. 이 문제를 완화하기 위해 게이트 구조를 가진 변형이 등장했다.

== LSTM과 GRU ==
* LSTM(long short-term memory): 입력, 망각, 출력 게이트를 사용해 정보를 선택적으로 저장·삭제한다. 1997년 Hochreiter와 Schmidhuber가 제안했다.
* GRU(gated recurrent unit): 게이트 수를 줄인 간소화된 구조로, LSTM에 버금가는 성능을 보이며 계산량이 적다.

== 활용과 현재 ==
RNN 계열은 언어 모델, 기계 번역, 음성 인식 등 순차 데이터 문제에 널리 사용되었다. 이후 [[트랜스포머]]가 등장하면서 대부분의 분야에서 어텐션 기반 구조로 대체되었다. 트랜스포머는 순차 처리가 아닌 병렬 처리가 가능하고 장거리 의존성을 더 잘 포착한다.

== 함께 보기 ==
* [[다층 퍼셉트론]]
* [[트랜스포머]]
* [[컨볼루션 신경망]]

== 출처 ==
* [https://en.wikipedia.org/wiki/Recurrent_neural_network 위키백과: Recurrent neural network]
* [https://www.bioinf.jku.at/publications/older/2604.pdf Long Short-Term Memory (Hochreiter & Schmidhuber, 1997)]
* [https://arxiv.org/abs/1406.1078 Learning Phrase Representations using RNN Encoder-Decoder (Cho et al., 2014)]
* [https://arxiv.org/abs/1409.3215 Sequence to Sequence Learning with Neural Networks (Sutskever et al., 2014)]

[[분류:인공신경망]]
[[분류:머신 러닝]]

비전 언어 모델

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:17 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''비전 언어 모델'''(Vision-Language Model, VLM)은 이미지와 텍스트를 함께 처리할 수 있도록 설계된 머신 러닝 모델이다. 이미지 이해, 텍스트-이미지 상호 연관, 시각적 질의응답(VQA) 등의 과제를 수행할 수 있다.

== 개요 ==
기존의 컴퓨터 비전은 이미지 분류와 같이 텍스트를 다루지 않는 경우가 많았다. 비전 언어 모델은 이미지 인코더와 텍스트 모델을 결합하여 두 모달을 함께 이해하며, 이미지와 언어의 상호 작용이 필요한 과제에서 사용된다. 최근 거대 언어 모델의 발전을 기반으로 많은 VLM이 생성형 및 이해 기능을 함께 제공하고 있다.

== 주요 모델 ==

* CLIP — 이미지와 텍스트를 공통 임베딩 공간으로 매핑
* [[Florence-2]] — 프롬프트 기반 통합 비전 모델
* LLaVA — 비전 인코더와 대형 언어 모델을 결합한 VLM
* BLIP / BLIP-2 — 이미지 캡셔닝 및 VQA 용 모델
* GPT-4V — 상용 홝식 모델의 비전 기능

== 활용 분야 ==

=== 이미지 캡셔닝 및 주석 ===
이미지의 내용을 자동으로 설명하고 메타데이터를 생성하는 데 사용된다.

=== 시각적 질의응답(VQA) ===
이미지에 대한 질문에 답하는 기능으로, 문서 이해, 교육, 상품 안내 등에 활용된다.

=== 텍스트 기반 이미지 검색 ===
대규모 이미지 컴라이러리에서 내용 기반 검색을 제공한다.

=== 로보틱스 및 자율주행 ===
시각 인식과 언어 이해가 함께 필요한 제어로직에 활용된다.

== 함께 보기 ==

* [[Florence-2]] — 프롬프트 기반 통합 비전 모델
* [[트랜스포머]] — 많은 VLM의 기반 아키텍처
* [[객체 탐지]] — 비전 모델이 수행하는 주요 태스크

== 출처 ==

* [https://openai.com/research/clip CLIP (OpenAI)]
* [https://llava-vl.github.io/ LLaVA 프로젝트]

[[분류:비전 언어 모델]]
[[분류:머신 러닝]]

모델 서빙

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:17 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''모델 서빙'''은 학습된 머신 러닝 모델을 애플리케이션에서 사용할 수 있도록 API나 배치 작업의 형태로 제공하는 과정이다. [[MLOps]]에서 모델을 운영 환경에 배포하는 핵심 단계이다.

== 방식 ==

* 실시간 서빙: 낮은 지연 시간으로 개별 요청에 예측을 반환 (REST·gRPC API)
* 배치 서빙: 대량 데이터를 주기적으로 처리
* 엣지·로컬 서빙: 모바일·임베디드·개인 하드웨어에서 실행

추론 성능을 위해 양자화·배칭·캐싱 같은 최적화가 사용되며, [[GGUF]]·[[llama.cpp]] 같은 로컬 추론 스택도 서빙 방식의 하나로 볼 수 있다. GPU 서버 기반 서빙에는 TensorRT, Triton Inference Server 등이 널리 쓰인다.

== 함께 보기 ==

* [[MLOps]]
* [[모델 레지스트리]]
* [[모델 모니터링]]

== 출처 ==

* [https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/index.html Triton Inference Server 문서]

[[분류:머신 러닝]]

모델 모니터링

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:16 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''모델 모니터링'''은 운영 중인 머신 러닝 모델의 성능과 상태를 지속적으로 관찰하는 실무이다. [[MLOps]]에서 모델이 배포된 뒤에도 품질을 유지하기 위한 핵심 과정이다.

== 감시 항목 ==

* 예측 품질: 정확도·오류율 등 업무 지표
* 데이터 드리프트: 입력 데이터 분포의 변화
* 개념 드리프트: 입력-출력 관계의 변화
* 시스템 지표: 지연 시간, 처리량, 가용성

드리프트나 품질 저하가 감지되면 재학습 트리거, 롤백, 알림 등의 대응이 이뤄진다.

== 함께 보기 ==

* [[MLOps]]
* [[모델 서빙]]

== 출처 ==

* [https://en.wikipedia.org/wiki/MLOps 위키백과: MLOps]
* [https://www.evidentlyai.com/mlopswiki Evidently: MLOps Wiki]

[[분류:머신 러닝]]

모델 레지스트리

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:15 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''모델 레지스트리'''는 학습된 머신 러닝 모델의 버전과 메타데이터, 배포 상태를 중앙에서 관리하는 저장소이다. [[MLOps]] 환경에서 모델을 재현·비교·배포하기 위한 기준점 역할을 한다.

== 기능 ==

* 모델 버전 관리와 이력 추적
* 스테이징(후보·승인·프로덕션) 상태 관리
* 모델 카드 등 메타데이터·문서 기록
* 배포 이력과 롤백 지원
* [[실험 추적]]·[[모델 서빙]]과의 연계

대표적인 구현으로는 [[MLflow]] Model Registry가 있다.

== 함께 보기 ==

* [[MLOps]]
* [[실험 추적]]
* [[모델 서빙]]

== 출처 ==

* [https://mlflow.org/docs/latest/model-registry.html MLflow Model Registry 문서]

[[분류:머신 러닝]]

멀티모달 에이전트 플러그인

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:14 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''멀티모달 에이전트 플러그인'''은 에이전트가 이미지·영상·음성·문서·3차원 자료를 읽거나 생성·편집하도록, 작업 지침인 스킬과 선택적 실행 도구인 MCP 서버를 함께 배포하는 확장 단위이다.

== 개요 ==

[https://github.com/QwenLM/Qwen-MM-Plugins QwenLM/Qwen-MM-Plugins]는 Qwen 모델의 멀티모달 기능과 로컬 미디어 도구를 여러 에이전트 실행 환경에서 쓰게 하는 플러그인 모음이다. 저장소는 “어떤 에이전트 하네스도 멀티모달 네이티브로 만든다”는 목표를 내세우며, 기능을 <code>qwen-mm-plugins-<capability></code>라는 독립 단위로 설치한다. 각 기능 단위는 에이전트가 언제 어떻게 사용할지 설명하는 스킬과, 필요한 경우 실제 처리를 수행하는 MCP 서버를 결합한다.

핵심 의미는 하나의 거대한 플러그인이 모든 권한과 의존성을 요구하지 않는다는 데 있다. 로컬 파일 읽기만 필요하면 API 키 없는 <code>core</code>를 설치하고, Qwen의 클라우드 비전·음성 기능이 필요할 때만 <code>api</code>와 DashScope 구성을 추가할 수 있다. 검색, 장시간 영상 기억, 영상 편집, Blender, FreeCAD와 교육용 설명 제작도 각각 별도 기능과 요구 사항을 가진다. 릴리스 기능은 독립적인 불변 태그를 사용한다고 README가 설명한다.

== 핵심 구조/작동 방식 ==

=== 스킬과 MCP의 분담 ===

스킬은 사용자의 자연어 요청과 파일 문맥을 읽고 어떤 도구를 호출할지 안내한다. MCP 서버는 이미지 디코딩, 프레임 추출, OCR, 검색, 생성이나 응용 프로그램 제어처럼 실행이 필요한 기능을 제공한다. 설치된 기능 뒤에 <code>@report.pdf</code>와 함께 “3쪽을 요약하고 표를 추출해 달라”고 요청하거나, <code>@meeting.mp4</code>에 화자·타임스탬프가 포함된 전사를 요구하면 스킬이 관련 MCP 도구를 고르는 방식이다. <code>core</code>는 동적 해상도로 미디어를 읽으므로 보통 사용자가 먼저 수동 축소할 필요가 없다고 README가 밝힌다.

가이드 설치기는 Claude Code, Codex, Qoder, OpenClaw, Qwen Code와 Gemini CLI를 지원하고 각 하네스의 기본 설치 명령을 사용한다. 공통 설정은 <code>~/.qwen-mm-plugins/config</code>에 둔다. DeepSeek Harness, Hermes Agent, opencode, pi와 QwenPaw는 별도 수동 설치 문서를 제공한다. 기능 업데이트는 이미 설치된 하네스와 기능 범위에 대해 수행할 수 있고, 로컬 체크아웃, 롤백, Windows/WSL2와 수동 스킬·MCP 구성은 공식 설치 문서에서 다룬다.

=== 기능 단위 ===

* <code>core</code>: 이미지와 영상을 읽고 문서, 코드, 데이터, 3차원 파일 등을 시각화한다. API 키는 필요 없지만 오디오·영상에는 ffmpeg가, 형식에 따라 별도 응용 프로그램이 필요하다.
* <code>api</code>: Qwen VL·Omni 기반 비전, OCR, grounding, 음성 인식, 분할과 오디오·영상 이해를 제공한다. DashScope와 로컬 미디어 처리를 위한 ffmpeg가 필요하다.
* <code>search</code>: 웹 검색, 페이지 추출과 역이미지 검색을 제공한다. Serper, Exa 또는 Tavily 키가 필요하고 이미지 검색은 Serper를 요구한다.
* <code>video-memory</code>: 긴 영상 질의를 위한 계층적 기억을 구축한다. 빌드에 DashScope, ffmpeg와 ffprobe가 필요하다.
* <code>video-edit</code>: 이미지·영상·음성 생성과 편집 흐름을 제공한다. DashScope, ffmpeg, 전체 편집에는 Node와 Chromium이 필요하다.
* <code>blender</code>와 <code>freecad</code>: 각각 모델링·텍스처·조명·렌더링, 파라메트릭 CAD·STEP/STL·FEM 작업을 맡는다. 해당 데스크톱 프로그램과 headless Linux의 Xvfb가 필요하며 FreeCAD FEM에는 CalculiX가 추가된다.
* <code>edu-agent</code>: 중국어 수학·과학 설명 영상과 상호작용 페이지를 만든다. 기본은 스킬 전용이고 Node·Chromium·ffmpeg를 사용하며, 내레이션 영상에는 DashScope가 필요하다.

=== 의존성과 설정 ===

<code>uv</code>가 제공하는 <code>uvx</code>는 Python 의존성을 필요할 때 설치한다. 로컬 <code>core</code> 도구는 API 키가 없지만 클라우드와 검색 기능은 각 공급자의 자격 증명을 요구한다. 영상, 문서, 브라우저, Blender와 FreeCAD 흐름에는 시스템 프로그램이 추가될 수 있다. 설치기의 Configure와 Verify 동작으로 자격 증명을 넣고 의존성을 점검할 수 있다.

== 활용 ==

문서와 영상이 섞인 조사에서는 PDF 표를 추출하고 회의 영상을 전사한 뒤, 긴 영상 기억을 만들어 시간 근거가 있는 질의응답을 수행할 수 있다. 사진의 위치를 추정하고 웹에서 검증하거나, 이미지 내용을 바탕으로 [[에이전트 전용 브라우저]]에서 후속 조사를 하는 흐름도 가능하다. <code>video-edit</code>는 생성 자산을 [[에이전트 기반 비디오 편집]] 또는 [[SRT 기반 화이트보드 애니메이션]]에 넘기는 전처리 도구가 될 수 있다. Blender와 FreeCAD 기능은 멀티모달 에이전트의 범위를 미디어 이해에서 3차원 제작과 공학 파일로 확장한다.

== 한계 및 주의점 ==

“플러그인 설치”만으로 모든 기능이 로컬에서 무료로 실행되는 것은 아니다. DashScope를 요구하는 기능, 별도 검색 API 키가 필요한 기능, 대형 데스크톱 프로그램과 브라우저를 요구하는 기능을 구분해야 한다. 파일 형식마다 필요한 응용 프로그램이 다르고 headless 환경에서는 Xvfb 같은 추가 계층이 필요하다. 설치 전 필요한 기능만 선택하면 권한, 비용과 장애 범위를 줄일 수 있다.

README의 한 줄 설치 명령은 원격 셸 스크립트를 실행한다. 재현성과 공급망 검토가 중요한 환경에서는 공식 설치 문서의 로컬 체크아웃·불변 태그·롤백 경로를 확인하고, 스크립트와 릴리스 버전을 검토한 뒤 적용해야 한다. 클라우드 기능에 문서·음성·영상을 넘길 때는 해당 공급자의 데이터 처리 조건과 조직 정책을 별도로 확인해야 한다. 기능 목록과 하네스 지원은 빠르게 변할 수 있으므로 여기의 요구 사항은 2026년 8월 16일 확인한 README 기준이다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[에이전트 전용 브라우저]]
* [[에이전트 기반 비디오 편집]]
* [[SRT 기반 화이트보드 애니메이션]]

== 출처 ==

* [https://github.com/QwenLM/Qwen-MM-Plugins QwenLM/Qwen-MM-Plugins README] — 아키텍처, 기능 목록, 하네스, 의존성과 예시. 2026년 8월 16일 확인.
* [https://github.com/QwenLM/Qwen-MM-Plugins/blob/main/docs/en/installation.md Qwen-MM-Plugins 공식 설치 문서] — 로컬 설치, 롤백, 의존성과 Windows/WSL2 안내. 2026년 8월 16일 확인.
* [https://github.com/QwenLM/Qwen-MM-Plugins/blob/main/docs/en/configuration.md Qwen-MM-Plugins 공식 설정 문서] — 기능별 자격 증명과 설정 참조. 2026년 8월 16일 확인.

[[분류:멀티모달 인공지능]]
[[분류:인공지능 에이전트]]
[[분류:플러그인]]
[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

루프 엔지니어링

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:13 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''루프 엔지니어링'''(loop engineering)은 에이전트가 목표를 달성할 때까지 계획·실행·관찰을 반복하는 제어 루프를 설계하는 공학 분야이다. 단일 호출로 끝나는 챗봇과 달리, 에이전트는 스스로 다음 행동을 결정하고 그 결과를 다시 입력으로 삼아 반복한다.

== 개요 ==
"에이전트는 루프다"라는 표현처럼, 에이전트 시스템의 본질은 모델 호출과 도구 실행을 잇는 반복 구조에 있다. 루프 엔지니어링은 이 반복 구조를 어떻게 시작하고, 언제 멈추고, 실패에 어떻게 대응할지 설계하는 작업이다.

대표적인 루프 패턴으로 ReAct(Reasoning + Acting)가 있다. 모델이 추론한 뒤 행동(도구 호출)을 하고, 관찰 결과를 바탕으로 다시 추론하는 과정을 반복한다.

== 루프의 구조 ==
전형적인 에이전트 루프는 다음 단계로 이루어진다.

# 목표와 상태 초기화
# 추론·계획: 다음 행동을 결정한다.
# 실행: 도구 호출 등 행동을 수행한다.
# 관찰: 결과를 상태에 반영한다.
# 종료 판정: 완료 여부를 확인하고, 미완료면 2단계로 돌아간다.

== 설계 요소 ==

=== 종료 조건 ===
루프가 언제 끝날지를 결정한다. 명시적 종료 신호, 최대 반복 횟수, 시간·비용 예산, 목표 달성 판정 기준 등이 사용된다. 종료 조건이 없으면 무한 루프나 비용 폭주가 발생할 수 있다.

=== 실패 처리와 재시도 ===
도구 호출 오류, 형식 오류, 잘못된 결과에 대한 복구 경로를 설계한다. 재시도 횟수 제한, 대체 도구 사용, 사람에게 요청을 넘기는 등의 전략이 있다.

=== 자기 반성 ===
Reflexion 같은 기법은 작업 결과를 모델 스스로 검토하게 하여 실패 원인을 기록하고, 다음 시도에서 이를 반영하도록 한다.

=== 상태 관리 ===
반복 사이에 유지해야 하는 정보(수행 중인 작업, 누적 결과, 문맥)를 정의하고 관리한다.

=== 평가 루프 ===
에이전트의 성능을 벤치마크 작업으로 반복 평가하고 회귀를 감지하는 루프를 구축한다.

== 한계와 고려사항 ==
* 무한 루프와 비용 폭주를 막기 위한 예산과 가드가 필요하다.
* 반복할수록 문맥이 커져 컨텍스트 윈도우를 초과할 수 있다. [[하네스 엔지니어링]]의 문맥 관리와 함께 설계해야 한다.
* 단일 루프로 표현하기 어려운 병렬 작업, 사람 개입, 분기 흐름은 [[그래프 엔지니어링]]의 영역이다.

== 함께 보기 ==
* [[하네스 엔지니어링]]
* [[그래프 엔지니어링]]
* [[프롬프트 엔지니어링]]

== 출처 ==
* [https://arxiv.org/abs/2210.03629 ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)]
* [https://arxiv.org/abs/2303.11366 Reflexion: Language Agents with Verbal Reinforcement Learning (Shinn et al., 2023)]
* [https://simonwillison.net/2024/Dec/18/agents-are-a-loop/ Simon Willison: Agents are a loop]
* [https://www.anthropic.com/engineering/building-effective-agents Anthropic: Building Effective Agents]

[[분류:AI 엔지니어링]]

데이터 버전 관리

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:12 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''데이터 버전 관리'''는 머신 러닝 학습에 사용하는 데이터셋의 버전과 계보(lineage)를 관리하는 실무이다. 코드뿐 아니라 데이터까지 버전을 고정해야 실험을 재현할 수 있다.

== 역할 ==
데이터셋 변경 이력을 기록하고, 어떤 데이터로 어떤 모델이 학습되었는지 추적할 수 있게 한다. 대규모 데이터는 파일 단위 버전 관리가 어려우므로 콘텐츠 해시 기반 저장과 원격 저장소 연동이 사용된다.

대표적인 도구로는 DVC(Data Version Control)와 [[Hugging Face]] Datasets가 있다.

== 함께 보기 ==

* [[ML 파이프라인]]
* [[MLOps]]

== 출처 ==

* [https://dvc.org/ DVC 공식 사이트]
* [https://huggingface.co/docs/datasets/ Hugging Face Datasets 문서]

[[분류:데이터 엔지니어링]]

대문

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:11 GMT

migrate: import legacy Wiki content to Vultr

@@ 1번째 줄: / 1번째 줄: @@
-<strong>미디어위키가 설치되었습니다.</strong>
+__NOTOC__ __NOEDITSECTION__
-[https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents 사용자 가이드]에서 위키 소프트웨어에 대한 정보를 얻을 수 있습니다.
+<!-- Topic Cards -->
-== 시작하기 ==
+<!-- Category Browse -->
-* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings 설정 목록]
+<div class="cx-section">
-* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ 미디어위키 FAQ]
+<div class="cx-section-title">주제별 둘러보기</div>
-* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ 미디어위키 릴리스 메일링 리스트]
+<div class="cx-chips">
-* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources 내 언어로 미디어위키 지역화]
+[[:분류:머신 러닝|머신 러닝]]
-* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam 당신의 위키에서 스팸에 대처하는 법을 배우세요]
+[[:분류:데이터 엔지니어링|데이터 엔지니어링]]

다층 퍼셉트론

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:10 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''다층 퍼셉트론'''(multilayer perceptron, MLP)은 여러 개의 완전연결 계층을 쌓아 만든 인공신경망 구조이다. 딥러닝의 가장 기본적인 구조로, 다른 신경망 구조들의 공통 기반이 된다.

== 개요 ==
단층 퍼셉트론은 입력을 선형 결합한 뒤 판정하는 구조로, 선형으로 나뉘는 문제만 풀 수 있었다. 은닉층을 추가하고 비선형 활성화 함수를 사용한 다층 구조는 XOR 문제를 포함한 비선형 분류를 가능하게 했다. 1986년 오차역전파(backpropagation) 알고리즘이 제안되면서 은닉층의 가중치를 학습할 수 있게 되었고, 이후 딥러닝의 기반이 되었다.

== 핵심 개념 ==

=== 완전연결 계층 ===
완전연결 계층은 이전 계층의 모든 뉴런이 다음 계층의 모든 뉴런과 연결되는 구조이다. 각 연결에는 가중치가 있고, 계층에는 편향(bias)이 더해진다. 입력 차원이 클수록 가중치 수가 급격히 늘어나는 것이 특징이다.

=== 활성화 함수 ===
활성화 함수는 뉴런의 출력에 비선형성을 부여한다. 대표적으로 ReLU, 시그모이드(sigmoid), tanh가 있으며, 활성화 함수가 없으면 계층을 아무리 쌓아도 선형 변환과 같아진다.

=== 오차역전파 ===
오차역전파는 손실 함수의 기울기를 출력 계층에서 입력 계층 방향으로 전파하여 각 가중치의 기울기를 계산하고, 경사하강법으로 가중치를 갱신하는 학습 방법이다.

=== 손실 함수와 경사하강법 ===
모델의 출력과 정답 사이의 차이를 손실 함수로 계산하고, 그 기울기를 따라 가중치를 반복적으로 갱신한다. 분류에는 교차 엔트로피, 회귀에는 평균 제곱 오차가 자주 사용된다.

== 구조적 특징과 한계 ==
MLP는 구조가 단순하고 범용적이어서 테이블 형태의 정형 데이터에 강하다. 보편 근사 정리(universal approximation theorem)에 따르면 충분한 크기의 단일 은닉층으로도 다양한 연속 함수를 근사할 수 있다.

다만 입력을 1차원 벡터로 평탄화해야 하므로, 이미지나 시퀀스처럼 구조를 가진 입력에서는 파라미터가 폭증하고 위치·순서 정보를 활용하기 어렵다. 이러한 한계를 개선하기 위해 [[컨볼루션 신경망]], [[순환 신경망]], [[트랜스포머]]가 등장했다.

== 함께 보기 ==
* [[컨볼루션 신경망]]
* [[순환 신경망]]
* [[트랜스포머]]

== 출처 ==
* [https://en.wikipedia.org/wiki/Multilayer_perceptron 위키백과: Multilayer perceptron]
* [https://www.nature.com/articles/323533a0 Learning representations by back-propagating errors (Rumelhart et al., 1986)]
* [https://en.wikipedia.org/wiki/Universal_approximation_theorem 위키백과: Universal approximation theorem]

[[분류:인공신경망]]
[[분류:머신 러닝]]

그래프 엔지니어링

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:08 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''그래프 엔지니어링'''(graph engineering)은 여러 LLM 호출·도구·사람 개입을 노드로, 실행 흐름을 간선으로 표현하여 복잡한 에이전트 워크플로우를 설계·구축하는 공학 분야이다. 단일 루프를 넘어 분기, 병렬, 재시도, 인간 승인을 포함한 흐름을 다룬다.

== 개요 ==
모든 작업이 단일 루프에 맞는 것은 아니다. 검색과 작성을 병렬로 수행하거나, 중간에 사람의 승인이 필요하거나, 입력에 따라 다른 처리 경로를 타야 하는 경우가 있다. 그래프 엔지니어링은 이런 흐름을 상태 그래프(state graph)로 모델링한다.

LangGraph 등 그래프 기반 오케스트레이션 프레임워크는 노드와 간선으로 워크플로우를 표현하고, 노드 간에 공유되는 상태를 관리한다. 결정적인 워크플로우에서부터 입력마다 경로가 달라지는 동적 에이전트까지, 어느 정도의 자유도를 줄지가 설계의 핵심 선택지가 된다.

== 그래프의 구성 요소 ==

=== 노드 ===
* LLM 호출: 프롬프트를 실행하는 노드.
* 도구 실행: 검색, 파일, API 등 외부 작업을 수행하는 노드.
* 조건 분기: 상태를 검사해 다음 경로를 정하는 노드.
* 사람 개입: 승인·수정을 기다리는 노드.
* 서브그래프: 다른 그래프를 노드처럼 호출하는 중첩 구조.

=== 간선 ===
* 순차 흐름: 노드를 순서대로 연결한다.
* 조건부 라우팅: 상태에 따라 다른 노드로 보낸다.
* 병렬 분기: 여러 노드를 동시에 실행하고 결과를 모은다.
* 사이클: 재시도·반복을 위해 이전 노드로 돌아간다.

=== 상태 ===
그래프의 노드들은 공유 상태를 통해 정보를 주고받는다. 실행 중인 작업, 누적된 메시지, 중간 결과 등이 상태로 관리된다.

== 설계 패턴 ==

=== 조건부 라우팅 ===
라우터 노드가 입력을 분류해 서로 다른 처리 경로로 보낸다. 예를 들어 질문 유형에 따라 검색, 계산, 일반 응답 경로로 나눌 수 있다.

=== 병렬 처리 ===
독립적인 작업을 여러 노드로 나누어 동시에 실행하고(팬아웃), 결과를 하나로 모은다(팬인).

=== 인간 개입 지점 ===
중요한 결정이나 위험한 행동 앞에 사람의 승인을 요구하는 노드를 배치한다.

=== 다중 에이전트 조율 ===
전문화된 에이전트들을 그래프로 연결한다. 오케스트레이터-워커 구조처럼 관리 에이전트가 작업을 나누어 워커 에이전트에 맡기고 결과를 취합하는 방식이 대표적이다.

== 루프와의 관계 ==
단일 에이전트 루프는 그래프의 특수한 경우로 볼 수 있다. 그래프 엔지니어링은 루프를 포함해 더 일반적인 흐름을 다루며, [[루프 엔지니어링]]에서 다루는 종료 조건, 실패 처리, 상태 관리의 원칙이 그래프에서도 동일하게 적용된다.

== 한계와 고려사항 ==
* 그래프가 커질수록 상태 설계와 디버깅이 어려워진다.
* 병렬 실행은 비용과 지연 시간을 늘릴 수 있다.
* 과도하게 복잡한 그래프는 유지보수가 어려우므로, 필요한 수준의 자유도만 도입하는 것이 중요하다.

== 함께 보기 ==
* [[루프 엔지니어링]]
* [[하네스 엔지니어링]]
* [[프롬프트 엔지니어링]]

== 출처 ==
* [https://github.com/langchain-ai/langgraph LangGraph 공식 저장소]
* [https://langchain-ai.github.io/langgraph/ LangGraph 공식 문서]
* [https://www.anthropic.com/engineering/building-effective-agents Anthropic: Building Effective Agents]
* [https://www.anthropic.com/engineering/built-multi-agent-research-system Anthropic: How we built our multi-agent research system]

[[분류:AI 엔지니어링]]

고충실도 3D 시뮬레이션

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:07 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''고충실도 3D 시뮬레이션'''은 실제 환경의 시각, 물리, 시간, 센서, 상호작용을 목적에 필요한 수준으로 재현하고 그 오차를 측정할 수 있게 만든 실시간 또는 준실시간 시뮬레이션이다. 이 문서는 공개 엔진 [https://github.com/o3de/o3de Open 3D Engine](O3DE)을 대표 사례로 다룬다.

== 개요 ==

“고충실도”는 사진처럼 보이는 그래픽만을 뜻하지 않는다. 로봇 센서 시험이라면 카메라·라이다의 위치와 시간 동기, 물체의 재질과 가림, 차량 동역학, 좌표계가 더 중요할 수 있다. 훈련 시뮬레이션에서는 충돌과 네트워크 지연, 사용자 입력, 시나리오 재현성이 핵심일 수 있다. 따라서 충실도는 사용 목적, 허용 오차, 검증 데이터와 함께 정의해야 한다.

O3DE는 실시간 크로스플랫폼 3D 엔진으로, 공식 README는 AAA 게임, 영화 품질 3D 세계, 고충실도 시뮬레이션을 비용이나 상업적 의무 없이 만들 수 있다고 소개한다. 2026년 8월 16일 확인한 공개 저장소는 보관 처리되지 않은 상태이며, 코드와 자동화 테스트, 편집기, Gems, 에셋, CMake 구성과 Python 도구를 포함한다. 저장소에는 Apache 2.0과 MIT 라이선스 문서가 있고, Git LFS로 큰 바이너리 파일을 관리한다.

공식 기능 문서는 O3DE를 필요한 기능만 고를 수 있는 모듈식 엔진으로 설명한다. 렌더링, 물리, 네트워크, 애니메이션, 스크립팅, 에셋 처리, 로보틱스 같은 시스템은 주로 Gem이라는 모듈로 제공된다. 프로젝트는 표준 Gem을 선택하거나 자체 Gem으로 기능을 확장·교체할 수 있다.

== 핵심 구조/작동 방식 ==

=== 모듈과 장면 ===

O3DE 프로젝트는 엔티티와 컴포넌트로 장면의 동작을 구성한다. 재사용할 복합 엔티티는 Prefab으로 묶을 수 있으며, 속성·컴포넌트·계층을 사람이 읽을 수 있는 텍스트 형식으로 저장해 버전 관리와 병합에 활용한다. Gem은 표준 인터페이스와 에셋을 가진 라이브러리 단위로, 프로젝트에 필요한 렌더링·물리·센서·도구 기능을 선택적으로 추가한다. 빌드와 의존성, 테스트, 코드 생성에는 CMake를 사용한다.

=== 렌더링과 에셋 ===

Atom은 크로스플랫폼, 모듈식, 데이터 중심, 다중 스레드 물리 기반 렌더러이다. 공식 문서는 Forward+와 Deferred 경로, DirectX 12·Vulkan·Metal, 전역 조명, MSAA·SSAO·SSR, 하드웨어 가속 광선 추적, 사용자 정의 렌더 패스를 설명한다. 통합 Asset Processor는 표준 형식의 원본을 실행용 에셋으로 변환하고, 비동기 로딩과 GPU 스트리밍을 지원한다. 같은 시나리오라도 재질, 조명, 카메라 노출과 후처리 설정이 달라지면 센서 입력이 변하므로 설정을 데이터로 고정해야 한다.

=== 물리와 시간 ===

O3DE는 NVIDIA PhysX를 통해 정적·동적 강체, 관절, 중력·바람 같은 힘, 겹침 검사, 트리거, shape cast와 raycast를 제공한다. Cloth와 TressFX는 천, 머리카락·털의 물리 반응을 담당한다. 로보틱스 문서에는 ROS 2, 시뮬레이션 시간, GNSS·라이다 센서, 차량 동역학과 지리참조 관련 Gem이 안내되어 있다. 물리 시간 간격, 서브스텝, 충돌 메시, 난수 시드와 센서 샘플 주기를 명시해야 반복 시험의 의미가 생긴다.

=== 실행 로직과 네트워크 ===

런타임 로직은 C++, 시각적 노드 도구인 Script Canvas, Lua를 함께 사용할 수 있다. Python 3는 편집기 확장과 에셋 전·후처리 자동화에 사용한다. 네트워킹 Gem은 TCP·UDP 전송 추상화, 암호화·압축, 지연·지터·순서 변경·손실 시뮬레이터, 엔티티 복제, 전용 서버와 로컬 예측·서버 권위 조정을 제공한다. 분산 시뮬레이션에서는 화면 품질뿐 아니라 상태 동기와 지연 모델도 충실도의 일부이다.

== 활용 ==

O3DE 기반 시뮬레이션은 로봇과 자율주행 센서 시험, 산업 설비의 디지털 트윈, 국방·재난 훈련, 합성 영상 데이터 생성, 다중 사용자 3D 환경, 게임 제작에 활용할 수 있다. [[COG 웹 가시화]]에서 다루는 지형·원격탐사 자료를 오프라인 가공해 3D 지형과 배경 데이터로 연결하거나, 지리참조 Gem으로 로컬 장면과 지리 좌표의 관계를 관리할 수 있다.

저작 도구의 복잡한 패널 구성은 [[Qt 도킹 UI]]와 연결되는 주제이다. 실제 O3DE 편집 도구도 Qt UX 라이브러리에 접근하는 Python 확장을 지원한다. 시스템 설계와 검증 범위는 [[에디토리얼 다이어그램]]으로 렌더링·물리·센서·네트워크·기준 데이터의 관계를 분리해 표현할 수 있다.

== 한계 및 주의점 ==

엔진 기능이 많다는 사실만으로 특정 목적의 고충실도가 입증되지는 않는다. 카메라 렌더링은 실제 렌즈 왜곡, 노이즈, 노출, 모션 블러를 자동으로 정확히 재현하지 않으며, 일반 물리 파라미터가 특정 차량·재질의 측정값과 일치한다고 볼 수 없다. 실제 장비 또는 공인 데이터와 비교해 위치, 시간, 영상, 힘, 센서 오차를 정량 검증해야 한다.

실시간성, 해상도, 물리 정확도, 장면 규모는 서로 비용을 교환한다. 광선 추적, 고해상도 에셋, 많은 동적 객체와 센서를 동시에 사용하면 GPU 메모리와 CPU 시간이 크게 늘 수 있다. 하드웨어·드라이버·그래픽 API에 따라 결과와 성능이 달라질 수 있고, 부동소수점과 병렬 실행 때문에 완전한 결정론이 어려울 수 있다. 회귀 시험에는 고정된 엔진 버전, 에셋 해시, 설정, 장비, 난수 시드와 허용 오차가 필요하다.

소스 빌드는 대규모이며 Git LFS, 지원 컴파일러, CMake, 제3자 패키지 캐시가 필요하다. 공식 README의 예제 도구 버전은 최신 지원표보다 오래될 수 있으므로 시스템 요구사항 문서를 우선해야 한다. 엔진의 Apache·MIT 라이선스와 별개로 선택한 Gem, SDK, 미들웨어, 에셋에는 서로 다른 배포 조건이 있을 수 있어 제품에 포함된 구성요소별 라이선스를 확인해야 한다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[Qt 도킹 UI]]
* [[COG 웹 가시화]]
* [[에디토리얼 다이어그램]]

== 출처 ==

* [https://github.com/o3de/o3de O3DE 공개 저장소 및 README] — 프로젝트 범위, 소스 빌드, 로드맵, 라이선스. 2026년 8월 16일 확인.
* [https://docs.o3de.org/docs/welcome-guide/features-intro/ O3DE 공식 기능 소개] — Gems, Atom, 물리, 네트워크, 에셋, Prefab과 도구. 2026년 8월 16일 확인.
* [https://docs.o3de.org/docs/user-guide/interactivity/robotics/ O3DE 공식 로보틱스 문서] — ROS 2 기반 시뮬레이션 구조와 시간. 2026년 8월 16일 확인.
* [https://docs.o3de.org/docs/user-guide/gems/reference/robotics/ros2/ O3DE ROS 2 Gem 공식 참조] — 센서와 지리참조 구성요소. 2026년 8월 16일 확인.

[[분류:C++ 소프트웨어]]
[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

객체 탐지

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:05 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''객체 탐지'''(Object Detection)는 이미지 속에서 객체의 위치를 바운딩 박스로 표시하고 클래스를 분류하는 컴퓨터 비전 과제이다. 물체 인식, 자율주행, 사진 키워딩 등 다양한 상위 응용의 기초 기능이다.

== 개요 ==
객체 탐지는 분류(classification)와 위치 회귀(regression)를 동시에 수행하는 과제로, 이미지 내 여러 객체의 클래스와 바운딩 박스를 예측한다. 객체 탐지 모델의 성능은 보통 COCO 데이터셋의 mAP(동급 평균 정확도)로 평가된다.

== 관련 태스크 ==

* 영역 분할(segmentation) — 픽셀 단위로 객체 경계 정의
* 인스터니스 탐지(instance segmentation) — 개체 별 영역 분할
* 키포인트 감지(keypoint detection) — 사람의 관절 위치 감지
* 그라운딩(grounding) — 텍스트 지시어와 영역 매핑

== 주요 기법 ==

=== 이단 감지기 ===
R-CNN 계열이 대표적이며, 영역 제안(proposal)을 생성하고 각 영역을 분류하는 방식이다. 정확도가 높지만 보통 속도가 느리다.

=== 1단 감지기 ===
YOLO 계열과 SSD가 대표적이며, 이미지를 그리드로 나누어 한 번의 전파에서 박스와 클래스를 예측한다. 실시간 응용에 적합하다.

=== Transformer 기반 ===
DETR(DEtection TRansformer)는 앱채 가이드 없이 [[트랜스포머]]와 세트 기반 예측을 사용한다. 최근 모델은 모든 태스크를 통합하여 처리하는 경향이며, [[Florence-2]]와 같은 [[비전 언어 모델]]도 객체 탐지를 수행할 수 있다.

== 함께 보기 ==

* [[Florence-2]] — 객체 탐지를 포함한 통합 비전 모델
* [[비전 언어 모델]] — 텍스트와 이미지를 함께 처리하는 모델 분류
* [[트랜스포머]] — DETR 등 최신 탐지 기법의 기반

== 출처 ==

* [https://github.com/AlexeyAB/darknet YOLO (Darknet)]
* [https://github.com/facebookresearch/detr DETR GitHub]
* [https://cocodataset.org/ COCO 데이터셋]

[[분류:컴퓨터 비전]]
[[분류:머신 러닝]]

XoFTR

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:03 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''XoFTR'''(Cross-modal Feature Matching Transformer)는 visible image와 thermal infrared image 사이의 cross-modal, cross-view local feature matching을 직접 목표로 한 detector-free matcher다.

== 개요 ==

CVPR 2024 Image Matching Workshop에서 공개되었다. LoFTR 계열 구조를 기반으로 masked image modeling pre-training과 pseudo-thermal augmentation을 도입하고 scale 차이를 보정하는 refinement를 결합한다. 공식 저장소는 METU-VisTIR 데이터와 pretrained weight를 제공하며 Apache-2.0 라이선스를 표시한다.

== 핵심 구조 ==

Keypoint detector와 descriptor를 독립 구성하기보다 두 영상 feature map의 관계를 transformer에서 직접 추론한다. coarse match 뒤 sub-pixel refinement를 적용한다. Visible↔TIR에 최적화된 학습 경험은 EO↔IR에서 직접적인 장점이 될 수 있다.

== 활용 ==

주야간 감시, 항공·드론 EO/IR payload alignment, thermal map overlay, 다중 센서 표적 추적 전 registration에 활용할 수 있다. [[RoMa]], [[MINIMA]]와 함께 두어 센서 특화 학습의 효과를 비교한다.

== 한계 및 주의점 ==

Visible-TIR 성능이 SAR, 지도, depth까지 자동으로 확장되지는 않는다. 입력 해상도와 scale 변화, GPU memory, checkpoint별 성능을 측정해야 한다. 폐쇄망 배포를 위해 weight 로컬 패키징과 [[PyTorch]]·CUDA dependency도 확인한다.

== 함께 보기 ==
* [[Cross-Modal Image Matching 기술 지도]]
* [[MINIMA]]
* [[EfficientLoFTR]]
* [[Cross-Modal Matching 벤치마크]]

== 출처 ==
* [https://github.com/OnderT/XoFTR XoFTR 공식 GitHub]
* [https://openaccess.thecvf.com/content/CVPR2024W/IMW/html/Tuzcuoglu_XoFTR_Cross-modal_Feature_Matching_Transformer_CVPRW_2024_paper.html CVPRW 2024]
* [https://arxiv.org/abs/2404.09692 arXiv]

[[분류:Cross-Modal Image Matching]]
[[분류:Thermal Imaging]]

Whisper.cpp

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:02 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''whisper.cpp'''는 OpenAI의 음성 인식 모델 Whisper를 C/C++로 포팅한 오픈소스 프로젝트이다. [[Georgi Gerganov]]가 2022년 9월에 시작했으며, [[Ggml]] 기반으로 CPU에서 고성능 추론을 목표로 한다.

== 개요 ==
whisper.cpp는 OpenAI의 Whisper 모델을 C/C++로 재구현한 것이다. GPU 없이도 CPU에서 음성 인식 추론을 실행할 수 있으며, Metal·CUDA 등 백엔드도 지원한다. [[ggml]]의 양자화를 활용해 메모리 사용량을 줄일 수 있다. [[ggml]]의 첫 대규모 응용 중 하나로, 이후 [[llama.cpp]]로 이어지는 로컬 추론 프로젝트들의 기반이 되었다.

== 함께 보기 ==

* [[Ggml]] — 기반 텐서 라이브러리
* [[Ggml-org]] — 프로젝트를 관리하는 GitHub 조직
* [[llama.cpp]] — 같은 개발자가 만든 대표 프로젝트

== 출처 ==

* [https://github.com/ggml-org/whisper.cpp whisper.cpp 공식 저장소]
* [https://ggerganov.com/ Georgi Gerganov 개인 홈페이지]

[[분류:머신 러닝]]
[[분류:C++ 소프트웨어]]
[[분류:오픈 소스]]

WebNN

Admina7ec671ac513 — Thu, 20 Aug 2026 04:19:00 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''WebNN'''은 웹 브라우저에서 신경망 추론을 하드웨어 가속하기 위한 W3C 표준 API이다. 웹 페이지에서 실행되는 AI 애플리케이션이 GPU, NPU 등 기밀 장치의 성능을 활용할 수 있도록 하는 웹 표준을 지향한다.

== 개요 ==
WebNN은 W3C Machine Learning Working Group에서 구성 중인 표준으로, 2019년경 추진이 시작되었다. 기존의 WebGL은 세이더 기반으로 이미지 처리에 최적화되어 있어 머신 러닝 연산에는 부적합한 부분이 있었다. WebNN은 신경망 연산자에 특화된 인터페이스를 제공하여 추론 성능을 끞어올리고, 다양한 하드웨어 가속을 추상화한다.

== 주요 특징 ==

=== 하드웨어 추상화 ===
각 브라우저의 백엔드를 통해 GPU, NPU, CPU 등 이용 가능한 하드웨어를 추상화한다. Edge에서는 [[DirectML]], Chrome에서는 CoreML, oneDNN 등이 백엔드로 사용된다.

=== 연산자 집합 ===
Conv, Pool, Gemm, BatchNormalization 등 다양한 신경망 연산자를 제공하며, 이를 조합하여 추론 그래프를 구성할 수 있다.

=== 종료-대에드 실행 ===
학습 단계 대신 추론 단계의 데이터 흐름에 최적화되어 있어 로적 애플리케이션에 적합하다.

== 생태계 ==

=== ONNX 생태계와의 연계 ===
[[ONNX Runtime]]의 실행 공급자로 WebNN이 제공되어, [[ONNX]] 형식의 모델을 웹 브라우저에서 실행할 수 있다.

=== 브라우저 지원 ===
Microsoft Edge, Google Chrome 등 Chromium 기반 브라우저와 Firefox, Safari에서 구현 및 표준화 노력이 진행 중이다.

== 함께 보기 ==

* [[ONNX]] — 웹 브라우저에서 실행할 모델 형식
* [[ONNX Runtime]] — WebNN을 실행 공급자로 사용하는 추론 엔진
* [[DirectML]] — Windows 브라우저의 하드웨어 백엔드

== 출처 ==

* [https://www.w3.org/TR/webnn/ W3C WebNN 명세]
* [https://webmachinelearning.github.io/webnn/ WebNN 구현 프로젝트]

[[분류:웹 기술]]
[[분류:머신 러닝]]

Stable Diffusion

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:59 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''Stable Diffusion'''은 Stability AI가 2022년 공개한 딥러닝 기반 텍스트-이미지 생성 모델이다. 잠재 확산 모델(Latent Diffusion Model)을 기반으로 하며, 텍스트 프롬프트를 입력받아 고품질 이미지를 생성한다.

== 개요 ==
Stable Diffusion은 CompVis 그룹과 Stability AI가 공동 개발하였으며, 오픈소스로 공개되어 누구나 자유롭게 사용하고 수정하며 배포할 수 있다. 기존 확산 모델이 픽셀 공간에서 작동하는 것과 달리, VAE(오토인코더)로 압축된 잠재 공간에서 확산 과정을 수행하여 메모리 사용량과 연산 시간을 크게 줄였다.

== 기술적 특징 ==

=== 잠재 확산(Latent Diffusion) ===
원본 이미지 대신 VAE로 인코딩된 저차원 잠재 표현에서 확산 및 역확산 과정을 수행한다. 이를 통해 소비자급 GPU에서도 고해상도 이미지 생성이 가능하다.

=== 조건부 생성 ===
CLIP 텍스트 인코더를 통해 프롬프트를 조건 신호로 변환하여 텍스트 기반 이미지 생성을 지원한다. 또한 이미지-이미지 변환(img2img), 인페이팅(inpainting), 아웃페이팅(outpainting) 등 다양한 조건부 생성 방식을 제공한다.

=== 파인튜닝 생태계 ===
[[LoRA]], Dreambooth, Textual Inversion 등 다양한 파인튜닝 기법을 통해 특정 스타일, 캐릭터, 객체에 특화된 모델을 만들 수 있다. 이로 인해 [[CivitAI]] 등 커뮤니티 기반의 방대한 모델 생태계가 형성되었다.

== 주요 버전 ==

* SD 1.x — 초기 공개 버전, 512x512 해상도
* SD 2.x — 개선된 CLIP 인코더와 해상도 지원
* SDXL — 1024x1024 기본 해상도, 이중 텍스트 인코더
* SD3 — DiT(Transformer) 아키텍처 도입, 다중 모드 지원

== 주요 도구 ==

* [[ComfyUI]] — 노드 기반 워크플로우 인터페이스
* AUTOMATIC1111 WebUI — 널리 사용되는 통합 웹 인터페이스
* Diffusers — [[허깡페이스]]의 공식 파이썬 라이브러리

== 함께 보기 ==

* [[ComfyUI]] — Stable Diffusion을 포함한 이미지 생성 모델의 노드 기반 인터페이스
* [[허깡페이스]] — 모델 허브 및 Diffusers 라이브러리
* [[GGUF]] — 양자화된 모델 배포 형식

== 출처 ==

* [https://github.com/Stability-AI/stablediffusion Stable Diffusion GitHub]
* [https://stability.ai/ Stability AI 공식 웹사이트]
* [https://huggingface.co/docs/diffusers Diffusers 문서]

[[분류:이미지 생성]]
[[분류:딥러닝 모델]]

SRT 기반 화이트보드 애니메이션

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:57 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''SRT 기반 화이트보드 애니메이션'''은 자막의 시간과 서사 순서를 장면·그림 요소·필기 궤적에 연결해, 선이 그려지고 색이 채워지는 과정을 MP4로 만드는 제작 방식이다.

== 개요 ==

[https://github.com/geeklee/srt-whiteboard-animation geeklee/srt-whiteboard-animation]은 SRT 자막을 따뜻한 종이 바탕의 손그림 설명 영상으로 변환하는 에이전트 스킬이다. 단순히 완성 이미지를 마스크로 한 번에 드러내는 대신, 자막에 나타난 사건 순서대로 화면 영역을 배치하고 각 영역 안에서 선을 연속적으로 그린 뒤 제한된 색을 더한다. 지식 설명, 이야기형 내레이션, 강의 자막, 짧은 영상 문안을 시각화하는 용도를 목표로 한다.

이 프로젝트가 강조하는 원칙은 “자막 구동”과 “단계별 확인”이다. 장면 분할, 선화, 주석, 영역·방향 검사, 최종 렌더링 사이에 사람의 확인 지점을 둔다. 따라서 초기에 잘못 잡은 분할이나 그림 구성을 끝까지 렌더링하는 비용을 줄이고, 내레이션이 말하는 대상과 실제로 그려지는 대상의 순서를 맞출 수 있다.

== 핵심 구조/작동 방식 ==

=== 자막에서 장면으로 ===

<code>parse_srt.py</code>는 SRT를 읽어 장면 분할안을 만든다. README는 한 장면의 권장 길이를 25~35초로 제시하며, 기본 예시는 목표 30초와 최소·최대 범위를 함께 넘긴다. 각 장면은 한 가지 핵심 의미를 표현하도록 명확한 스토리보드와 그림 전략을 먼저 정한다. 시간만 일정하게 자르는 것이 아니라 등장 대상, 행동, 반응과 결과가 자연스럽게 이어지는지 확인하는 단계가 필요하다.

=== 선화와 의미 주석 ===

장면별 PNG와 같은 이름의 <code>.annotation.json</code>이 한 쌍을 이룬다. 주석에는 캔버스 크기, 장면 근거, 지속 시간과 요소 목록이 들어간다. 각 요소는 <code>sequence</code>, 연결 자막인 <code>subtitle</code>, 서사 역할인 <code>narrativeRole</code>, 픽셀 단위 <code>region</code>, 노출 시작 시점과 지속 시간을 담은 <code>reveal</code>, 손의 시작·끝과 완화 방식을 담은 <code>handPath</code>를 가진다. 권장 순서는 배경 설정, 핵심 인물이나 사물, 행동·변화, 반응·결과이다.

서로 겹치는 대상은 먼저 그릴 요소의 <code>protectedRegions</code>에 나중에 보여야 할 범위를 기록한다. 이 보호 영역이 없으면 뒷순서 대상의 선이나 색이 마스크 경계에서 일찍 드러날 수 있다. <code>direction</code>과 <code>handPath</code>는 미리보기의 사각형 대리 표현에 쓰이고, 최종 영상의 실제 필기는 스트리밍 렌더러가 생성한다.

=== 미리보기와 렌더링 ===

브라우저의 <code>assets/preview.html</code>에서 장면 폴더를 열면 영역, 순서, 시점과 자막 연결을 편집할 수 있다. <code>render_annotation_preview.py</code>는 영역 검사 이미지를 만든다. 확정된 장면은 <code>render_stream_whiteboard.py</code>가 먼저 <code>ink</code> 선을 놓고 뒤이어 <code>color</code>를 채우는 방식으로 MP4를 만든다. 선 경로에는 격자 방식과, 선화가 충분히 깨끗할 때 선택할 수 있는 skeleton 방식이 있다. 여러 장면은 <code>merge_scenes.py</code>로 순서대로 합친다.

시각 규격은 <code>#F5EBD7</code> 계열의 따뜻한 미색 종이, 짙은 회색 스케치 선, 소량의 빨강·주황·파랑 포인트를 권한다. 장면 안 문자·라벨, 사진 같은 질감, 3차원 효과와 복잡한 배경은 피하고 여백을 확보한다. 이 제한은 여러 장면의 스타일을 유지하고 필기 과정이 읽히도록 하기 위한 프로젝트의 명시적 규칙이다.

== 활용 ==

강의 녹음에서 얻은 SRT를 짧은 주제 단위로 나누고, 각 주제의 핵심 개념을 한 장면으로 설명할 수 있다. 이야기형 자막에서는 인물·물건·행동·주변 반응을 <code>sequence</code>로 배치해 내레이션과 시선을 함께 이동시킬 수 있다. 여러 장면을 따로 승인하고 렌더링하므로, 한 장면만 다시 그리거나 시점을 수정한 뒤 전체 영상을 재결합하는 작업에도 적합하다. 완성 MP4를 [[에이전트 기반 비디오 편집]]의 타임라인에 넣어 음성, 음악, 제목과 결합하는 후속 흐름도 구성할 수 있다.

== 한계 및 주의점 ==

좋은 SRT가 곧 좋은 스토리보드를 보장하지 않는다. 한 자막 안에 여러 사건이 있거나 대명사가 많으면 사람의 의미 확인과 재분할이 필요하다. 캔버스 크기와 원본 이미지가 다르거나 영역 좌표가 화면 밖이면 마스크와 손 위치가 어긋난다. 첫 프레임에 선이 미리 보이지 않는지, 중간 프레임에서 미시작 영역이 노출되지 않는지, 마지막 완성 화면이 최소 0.5초 유지되는지 장면별로 검사해야 한다.

이 저장소는 범용 비선형 편집기보다 특정 손그림 양식과 승인 흐름에 집중한다. 사진 기반 영상, 장면 내 많은 텍스트, 복잡한 카메라 움직임에는 그대로 적용하기 어렵다. 첫 실행 때 프로젝트의 <code>prepare_env.py</code>로 독립 Python 환경을 준비하고, 출력한 전용 인터프리터를 후속 렌더링에 사용해야 한다. 저장소의 스크립트와 예시가 바뀔 수 있으므로 주석 형식과 명령 옵션은 사용 시점 README와 <code>SKILL.md</code>를 다시 확인해야 한다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[에이전트 기반 비디오 편집]]
* [[멀티모달 에이전트 플러그인]]
* [[저사양 GPU 생성형 미디어 워크스테이션]]

== 출처 ==

* [https://github.com/geeklee/srt-whiteboard-animation geeklee/srt-whiteboard-animation README] — 전체 제작 흐름, 주석 형식, 명령과 품질 점검표. 2026년 8월 16일 확인.
* [https://github.com/geeklee/srt-whiteboard-animation/blob/main/SKILL.md srt-whiteboard-animation SKILL.md] — 저장소가 제공하는 공식 스킬 지침. 2026년 8월 16일 확인.

[[분류:영상 제작]]
[[분류:자막]]
[[분류:인공지능 에이전트]]
[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

RoMa

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:55 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''RoMa'''(Robust Dense Feature Matching)는 두 영상 사이의 pixel-dense correspondence와 각 대응의 certainty를 추정하는 dense image matcher다. 자연영상 기반 범용 matcher이지만 강한 표현을 사용해 cross-modal 원격탐사에서도 우선 시험할 가치가 있는 후보다.

== 개요 ==

RoMa는 CVPR 2024에 발표되었다. DINOv2의 frozen pretrained feature가 제공하는 의미적 강건성과 정밀 위치 결정을 위한 ConvNet fine feature를 결합한다. feature pyramid와 transformer match decoder, certainty estimation을 함께 사용한다. 공식 구현 Parskatt/RoMa는 MIT 라이선스를 명시한다.

== 핵심 구조 ==

Sparse keypoint를 먼저 검출하는 전통적 파이프라인과 달리 영상의 넓은 영역에서 dense warp를 추정한다. 질감이 약하거나 대응점이 한 영역에 몰리는 원격탐사 데이터에서 coverage 확보에 유리할 수 있다. 반대로 고해상도 전체 영상을 그대로 입력하면 메모리와 시간이 커져 pyramid, tiling, coarse-to-fine 전략이 필요하다.

2026년에는 SAR와 optical을 공통 modality로 변환한 뒤 RoMa를 사용하는 연구도 등장해 범용 matcher를 cross-modal pipeline의 후단으로 활용하는 방향을 보여 준다.

== 활용 ==

초기 PoC에서는 primary dense matcher로 두고 [[MINIMA]]-RoMa와 비교하기 좋다. 동일 전처리와 geometric verification을 적용해 inlier ratio, pixel/meter error, coverage, runtime, peak VRAM을 비교하면 multimodal pretraining의 이득을 분리할 수 있다.

== 한계 및 주의점 ==

RoMa 원 논문은 EO↔SAR 상용 정합을 직접 보증하지 않는다. DINO 계열 backbone과 checkpoint 조건, CUDA 의존성도 제품 실사 대상이다. dense output은 많은 후보를 주지만 오매칭도 늘 수 있어 robust estimation이 필수다.

== 함께 보기 ==
* [[Cross-Modal Image Matching 기술 지도]]
* [[MINIMA]]
* [[MatchAnything]]
* [[Cross-Modal Matching 기하 검증]]

== 출처 ==
* [https://github.com/Parskatt/RoMa RoMa 공식 GitHub]
* [https://arxiv.org/abs/2305.15404 RoMa 논문]
* [https://arxiv.org/abs/2602.12515 SAR·Optical 공통 modality 변환 연구]

[[분류:Cross-Modal Image Matching]]
[[분류:Feature Matching]]

RIFT

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:55 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''RIFT'''(Radiation-variation Insensitive Feature Transform)는 비선형 방사 차이가 큰 multimodal image matching을 위해 설계된 handcrafted feature method다. 학습 weight에 의존하지 않아 폐쇄망·재현성·fallback 관점에서 가치가 있다.

== 개요 ==

Intensity나 gradient가 modality 변화에 민감하다는 문제에서 출발한다. feature detection에는 phase congruency를 사용하고 log-Gabor convolution sequence로 Maximum Index Map(MIM)을 만들어 descriptor를 구성한다. 원 논문은 optical↔optical, infrared↔optical, SAR↔optical, depth↔optical, map↔optical, day↔night을 평가했다.

== 핵심 구조 ==

Phase congruency는 밝기 크기보다 여러 주파수 성분의 위상 정렬을 이용해 구조를 찾으므로 radiation change에 상대적으로 강하다. MIM은 gradient direction 대신 log-Gabor response의 최대 index 패턴을 사용한다. 이후 rotation invariance와 속도를 개선한 RIFT2도 공개됐다.

== 활용 ==

GPU가 없거나 model weight 반입이 어려운 폐쇄망, neural matcher가 실패하는 장면에서 fallback으로 적합하다. primary matcher의 inlier 수나 coverage가 기준 이하일 때 RIFT/RIFT2를 재시도하는 이중 구조가 실용적이다.

== 한계 및 주의점 ==

고해상도 대형 영상에서 handcrafted 계산이 반드시 빠른 것은 아니다. 공식 MATLAB 구현의 license.txt, MATLAB runtime 여부, Python/C++ 재구현의 출처를 구분해 관리해야 한다.

== 함께 보기 ==
* [[Cross-Modal Image Matching 기술 지도]]
* [[Cross-Modal Matching 기하 검증]]
* [[Cross-Modal Matching 벤치마크]]
* [[Modality-Invariant Image Matching]]

== 출처 ==
* [https://github.com/LJY-RS/RIFT-multimodal-image-matching RIFT 공식 구현]
* [https://github.com/LJY-RS/RIFT2-multimodal-matching-rotation RIFT2]
* [https://arxiv.org/abs/1804.09493 RIFT 논문]

[[분류:Cross-Modal Image Matching]]
[[분류:Remote Sensing Registration]]

Quality-Aware 템플릿 매칭

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:54 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''Quality-Aware 템플릿 매칭'''은 검색 영상과 템플릿의 패치가 얼마나 비슷한지만 보지 않고, 그 대응이 다른 후보와 비교해 얼마나 구별되는지도 점수에 반영하는 정합 방식이다. [https://github.com/cplusx/QATM cplusx/QATM]은 CVPR 2019 논문 QATM(Quality-Aware Template Matching)의 공식 공개 구현이다.

== 개요 ==

템플릿 매칭은 작은 기준 영상이 큰 검색 영상의 어느 위치에 나타나는지 찾는다. 단순 상관이나 특징 유사도는 배경의 반복 무늬도 높은 점수를 줄 수 있다. 예를 들어 템플릿의 모서리 패치가 검색 영상의 유일한 위치와 강하게 대응하면 유용하지만, 잔디·벽돌·창문처럼 비슷한 패치가 수십 곳에 나타나면 각 대응은 덜 확실하다. QATM에서 “품질”은 영상의 선명도 같은 일반 품질이 아니라 대응 쌍의 구별 가능성 또는 고유성에 가깝다.

QATM은 검색 영상과 템플릿의 특징 집합 전체에서 각 후보의 상대 순위를 부드러운 확률로 계산한다. 검색 패치가 특정 템플릿 패치를 얼마나 선택하는지와, 템플릿 패치가 특정 검색 패치를 얼마나 선택하는지를 양방향으로 평가한다. 일대일 대응은 높게, 일대다·다대일·다대다처럼 반복되는 패턴은 낮게 만든다. 모든 연산이 미분 가능하고 배치 처리에 맞도록 구성되어 독립 템플릿 매처뿐 아니라 신경망 안의 학습 가능한 층으로 넣을 수 있다는 것이 논문의 핵심 주장이다.

2026년 8월 16일 확인한 공개 저장소에는 Keras 기반 <code>QATM</code> 층, 정규화 층, 단일 예제와 OTB 데이터셋 실행 노트북이 있다. README는 실험 환경으로 Keras 2.2.4, TensorFlow 1.9.0, OpenCV 4.0.0을 제시하고 [[PyTorch]] 외부 구현을 링크한다. 공식 코드는 공개되어 있지만 라이선스는 학술·비상업적 용도로 제한하며, 상업적 사용에는 별도 유료 라이선스가 필요하다고 명시한다. 따라서 일반적인 허용형 오픈소스와 동일하게 취급해서는 안 된다.

== 핵심 구조/작동 방식 ==

=== 특징 추출과 유사도 ===

템플릿과 검색 영상을 같은 특징 추출기에 넣어 공간 특징 맵을 만든다. 원 논문과 예제는 사전학습 CNN의 깊은 특징을 이용하지만 QATM의 핵심은 특정 백본보다 두 특징 집합의 모든 후보 유사도를 품질 점수로 바꾸는 층에 있다. 각 템플릿 위치와 검색 위치의 특징을 정규화하고 유사도 텐서를 구성하면, 한 축은 템플릿 패치, 다른 축은 검색 패치를 나타낸다.

=== 양방향 soft-ranking ===

유사도 텐서에 두 방향의 softmax를 적용한다. 하나는 주어진 검색 패치가 템플릿의 어느 패치와 대응하는지, 다른 하나는 주어진 템플릿 패치가 검색 영상의 어느 위치와 대응하는지를 나타낸다. 공개 <code>models.py</code> 구현은 각각 학습 가능한 계수로 softmax의 날카로움을 조정하고, 두 신뢰도의 곱에 제곱근을 취해 대칭적인 confidence를 만든다. 이후 각 기준 위치에서 가장 높은 대응을 선택해 공간 점수 맵을 반환한다.

이 구조 때문에 같은 모양이 여러 곳에 반복되면 어느 한 후보에 확률이 집중되지 않고 점수가 분산된다. 반대로 양쪽에서 서로를 거의 유일하게 선택하는 패치는 높은 점수를 얻는다. README의 이상적 사례 표도 일대일, 일대다, 다대일, 다대다 순으로 대응 품질이 낮아지는 의도를 보여 준다. 최종 위치는 이 품질 맵을 템플릿 크기와 축척 조건에 맞게 집계하고 최대 응답 또는 후보 상자를 찾는 후처리로 구한다.

=== 학습 가능한 층 ===

softmax 계수와 앞단 특징 추출기를 손실 함수와 함께 학습할 수 있어 QATM을 더 큰 DNN에 포함할 수 있다. 다만 저장소의 노트북은 2019년 당시 프레임워크를 기준으로 하므로, 최신 TensorFlow·Keras로 옮길 때에는 텐서 축, <code>top_k</code>, 가중치 직렬화, 전처리와 출력 크기를 검증해야 한다.

== 활용 ==

공식 자료는 고전적 템플릿 매칭과 이미지-대-GPS 정합, 즉 질의 영상을 참조 파노라마 안에서 찾는 사례를 제시한다. 이 밖에도 로고·부품·문서 조각 탐색, 고정된 외형의 물체 위치 확인, 영상 추적의 초기 후보 평가처럼 소수 템플릿으로 검색할 때 적용할 수 있다. 배경 반복 패턴이 높은 단순 유사도를 만드는 상황에서 양방향 고유성 점수가 특히 의미가 있다.

[[Detector-Free 로컬 특징 정합]]과는 출력 목적이 다르다. QATM은 하나의 템플릿 위치와 품질 맵을 구하는 데 초점을 두고, LoFTR는 두 영상 사이의 다수 점 대응을 구해 호모그래피나 카메라 자세를 추정한다. [[COG 웹 가시화]] 환경에서는 작은 지표물 템플릿의 후보를 검색한 뒤 지리 좌표로 변환해 표시하거나, 여러 시기의 정사영상에서 후보 점수를 비교할 수 있다. 단, 원 연구가 원격탐사 다중센서 정확도를 보증하는 것은 아니다.

== 한계 및 주의점 ==

QATM은 반복성을 점수화하지만 큰 회전, 축척 변화, 원근 변화, 비강체 변형을 자동으로 해결하지 않는다. 이를 다루려면 여러 축척·각도에서 검색하거나 변환에 강한 특징과 후보 생성기를 결합해야 한다. 템플릿이 너무 작거나 배경과 비슷하면 고유성 자체가 부족하고, 가림이 심하면 템플릿 전체 점수 집계가 불안정할 수 있다. 임계값은 데이터별 검증 세트에서 정해야 한다.

모든 템플릿 위치와 검색 위치의 유사도 텐서는 해상도가 커질수록 메모리와 연산이 빠르게 증가한다. 고해상도 항공·위성 영상은 전체 영상을 한 번에 처리하기보다 영상 피라미드, 후보 영역, 타일과 중첩 병합을 사용해야 한다. 서로 다른 타일의 soft-ranking 집합이 달라지면 점수의 절대값도 달라질 수 있으므로 타일 간 보정과 경계 검사가 필요하다.

공식 구현의 TensorFlow 1.9와 Keras 2.2.4는 현재 환경과 큰 차이가 있다. 가장 중요한 법적 제한은 공개 LICENSE가 학술·비상업적 사용만 허용한다는 점이다. 상업 제품, 유료 서비스, 고객 납품에 사용하기 전에는 USC의 상업 라이선스를 확인해야 하며, 링크된 제3자 [[PyTorch]] 구현은 별도의 라이선스를 가진다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[Detector-Free 로컬 특징 정합]]
* [[COG 웹 가시화]]
* [[고충실도 3D 시뮬레이션]]

== 출처 ==

* [https://github.com/cplusx/QATM QATM 공식 공개 저장소 및 README] — 방법 개요, 이상적 점수, 응용, 의존성. 2026년 8월 16일 확인.
* [https://github.com/cplusx/QATM/blob/master/models.py QATM 공식 Keras 층 구현] — 양방향 softmax와 confidence 계산. 2026년 8월 16일 확인.
* [https://github.com/cplusx/QATM/blob/master/LICENSE QATM 공식 라이선스] — 학술·비상업적 사용 제한과 상업 라이선스 연락처. 2026년 8월 16일 확인.
* [https://openaccess.thecvf.com/content_CVPR_2019/html/Cheng_QATM_Quality-Aware_Template_Matching_for_Deep_Learning_CVPR_2019_paper.html CVPR 2019 공식 논문 페이지] — 알고리즘과 평가. 2026년 8월 16일 확인.

[[분류:컴퓨터 비전]]
[[분류:머신 러닝]]
[[분류:GitHub Star 연구]]

Qt 도킹 UI

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:54 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''Qt 도킹 UI'''는 도구 창, 편집기, 속성 패널, 로그 창 같은 여러 작업 패널을 사용자가 탭으로 묶고, 분할하고, 떼어 내고, 다시 결합할 수 있게 만든 Qt 데스크톱 사용자 인터페이스 패턴이다. 이 문서는 공개 C++ 라이브러리 [https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System Qt Advanced Docking System](ADS)을 중심 사례로 다룬다.

== 개요 ==

복잡한 데스크톱 응용프로그램은 하나의 고정 화면보다 작업에 따라 바꿀 수 있는 작업공간이 필요하다. 영상 분석자는 지도와 영상, 히스토그램, 레이어, 메타데이터를 동시에 보고 싶을 수 있고, 3D 편집자는 뷰포트, 장면 트리, 속성, 콘솔을 서로 다른 모니터에 배치할 수 있다. 도킹 UI는 각 기능을 독립 패널로 만들고 사용자의 화면 크기와 역할에 맞춰 재구성하게 한다.

Qt 자체에도 <code>QDockWidget</code>이 있지만 ADS는 Visual Studio와 같은 IDE에 가까운 도킹 경험을 목표로 한다. 2026년 8월 16일 확인한 공개 저장소 README는 메인 창의 모든 경계와 각 도크 영역에 도킹, 부동 창 내부에 다시 도킹, 탭 그룹 전체 이동, 레이아웃 관점(perspective) 저장, 자동 숨김, 취소 가능한 드래그, 동적 도크 삭제를 지원한다고 설명한다. Qt 5와 Qt 6을 지원하고 PyQt5·PyQt6·PySide6용 파이썬 바인딩도 안내한다.

README의 최신 주요 항목은 릴리스 5.0으로, 전체 다크 모드와 네이티브 Wayland 도킹 지원을 강조한다. 저장소는 LGPL-2.1 라이선스로 공개되어 있다. 실제 제품에 포함할 때에는 동적·정적 링크 방식, 수정한 라이브러리의 제공 의무 등 LGPL 조건을 프로젝트 배포 구조와 함께 검토해야 한다.

== 핵심 구조/작동 방식 ==

ADS의 중심은 <code>CDockManager</code>이다. <code>QMainWindow</code>에 관리자를 만들고, 응용프로그램별 <code>QWidget</code>을 <code>CDockWidget</code>의 내용으로 넣은 뒤 원하는 도킹 영역에 추가한다. <code>CDockAreaWidget</code>은 여러 도크 위젯을 탭으로 묶는 영역이고, 분할 경계에는 Qt의 <code>QSplitter</code>가 사용된다. 부동 컨테이너도 도크 영역을 가질 수 있어 메인 창과 유사한 방식으로 패널을 다시 분할하거나 탭으로 결합한다.

기본 동작은 다음과 같다.

# 응용프로그램이 패널의 제목, 내용 위젯, 닫기·삭제 정책, 허용 영역을 구성한다.
# 사용자가 탭이나 제목 표시줄을 끌면 시스템은 즉시 원래 패널을 제거하지 않고 드래그 미리보기와 놓기 오버레이를 표시한다.
# 마우스를 놓을 때 선택된 영역에 실제 레이아웃 변경을 적용한다. 놓기 전에는 Escape 키로 취소할 수 있다.
# 같은 영역의 탭은 하나의 그룹으로 이동할 수 있고, 화면 가장자리의 사이드바에 고정하면 자동 숨김 패널이 된다.
# 현재 도크 집합과 배치를 직렬화해 저장하고 복원할 수 있다. 이름 붙인 perspective를 여러 개 두면 분석, 편집, 검토 같은 작업 모드 사이를 빠르게 전환할 수 있다.

분할기 크기 변경은 불투명 방식과 지연 방식 중 고를 수 있다. 불투명 방식은 드래그 중 내용을 계속 다시 그려 즉각적이지만, 무거운 OpenGL·영상 위젯에서는 깜박임이나 부하가 생길 수 있다. 지연 방식은 마우스를 놓을 때 최종 크기를 적용한다. 표시·숨김 명령은 각 도크의 <code>toggleViewAction()</code>을 메뉴나 도구 모음에 연결하는 방식으로 제공할 수 있다.

== 활용 ==

도킹 UI는 IDE, GIS, 원격탐사 영상 분석기, 과학 시각화, 산업 검사, 디버거, 3D 저작 도구처럼 기능 패널이 많은 응용프로그램에 적합하다. [[COG 웹 가시화]] 기능을 데스크톱 셸에 포함한다면 지도, 밴드 조정, 좌표, 다운로드 상태를 별도 도크로 나눌 수 있다. [[고충실도 3D 시뮬레이션]] 저작 환경에서는 뷰포트, 엔티티 트리, 물리 속성, 성능 프로파일러를 역할별 perspective로 구성할 수 있다.

고정된 하나의 배치를 모든 사용자에게 강요하지 않는다는 점도 장점이다. 단일 모니터에서는 자동 숨김으로 공간을 확보하고, 다중 모니터에서는 부동 창을 분리할 수 있다. 저장된 작업공간을 사용자 설정 또는 프로젝트 설정으로 관리하면 특정 검토 절차를 재현하기 쉬워진다.

== 한계 및 주의점 ==

자유도가 높을수록 사용자가 패널을 잃어버리거나 지나치게 복잡한 배치를 만들 수 있다. 기본 배치 복원, 필수 패널 표시 메뉴, 레이아웃 버전 관리와 손상 시 대체값이 필요하다. 모든 패널을 도킹 가능하게 만드는 것도 바람직하지 않다. 짧은 확인 대화상자나 단일 작업 흐름은 고정 레이아웃이 더 명확할 수 있다.

운영체제의 창 시스템 차이도 중요하다. 공식 README에 따르면 Wayland는 클라이언트가 최상위 창의 화면 좌표를 직접 정하거나 전역 커서 위치를 조회하는 것을 제한한다. Qt 6.6.3부터 관련 도킹을 지원하지만, 부동 창 장식, 드래그 방식, 항상 위 동작, 저장 위치 복원은 Windows·X11과 다를 수 있다. macOS는 컴파일 가능하다고 보고되었으나 프로젝트 작성자가 직접 충분히 시험한 환경은 아니라고 명시한다.

무거운 렌더링 위젯을 이동·리사이즈하면 GPU 컨텍스트, 고해상도 화면 배율, 포커스, 키보드 단축키 문제가 나타날 수 있다. 대상 OS와 다중 모니터, 화면 배율, 절전·복귀, 레이아웃 업그레이드를 실제 장비에서 시험해야 한다. 또한 ADS가 지원하는 Qt 버전과 Python 패키지의 배포 주기는 같지 않을 수 있으므로 각 바인딩의 버전 호환성을 별도로 확인한다.

== 함께 보기 ==

* [[최근 GitHub Star 연구 주제]]
* [[COG 웹 가시화]]
* [[고충실도 3D 시뮬레이션]]
* [[에디토리얼 다이어그램]]

== 출처 ==

* [https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System Qt Advanced Docking System 공개 저장소 및 README] — 기능, 지원 환경, 예제, LGPL-2.1 라이선스. 2026년 8월 16일 확인.
* [https://githubuser0xffff.github.io/Qt-Advanced-Docking-System/ Qt Advanced Docking System 공식 문서] — 구성요소, 레이아웃 저장, 자동 숨김과 설정. 2026년 8월 16일 확인.
* [https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System/blob/master/README.md 공식 README 원문] — 릴리스 5.0, Wayland 제약, Qt·Python 지원. 2026년 8월 16일 확인.

[[분류:C++ 소프트웨어]]
[[분류:오픈 소스]]
[[분류:GitHub Star 연구]]

Python 개발 환경 베스트 프랙티스

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:53 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''Python 개발 환경 베스트 프랙티스'''는 Python 프로젝트의 인터프리터, 의존성, 디렉터리 구조, 코드 품질, 시험과 문서를 재현 가능하고 협업하기 쉬운 형태로 관리하는 원칙의 집합이다. 이 문서는 [https://github.com/realpython/python-guide realpython/python-guide]와 그 공개판인 ''The Hitchhiker's Guide to Python''을 중심으로 정리한다.

== 개요 ==
python-guide는 실행 프레임워크가 아니라 설치, 구성, 일상적인 Python 사용에 관한 의견 지향적 안내서이다. 초보자와 숙련 개발자 모두를 대상으로 운영체제별 설치, 패키지 관리, 가상 환경, 프로젝트 구조, 코드 스타일, 테스트, 문서화, 배포 도구와 목적별 라이브러리를 폭넓게 다룬다. 핵심 가치는 특정 명령 하나보다 개발자의 컴퓨터, CI, 배포 환경에서 같은 프로젝트를 다시 만들 수 있도록 경계를 명확히 하는 데 있다.

저장소 README는 이 안내서가 진행 중이며 많은 작업이 남아 있다고 명시한다. 문서 안에는 Python 2.7, 오래된 배포 도구, 과거의 패키징 관행을 설명하는 부분도 공존한다. 따라서 내용을 변하지 않는 표준으로 받아들이기보다 프로젝트 구조를 점검하는 체크리스트로 활용하고, 구체적인 도구와 명령은 현재 Python 및 PyPA 공식 문서와 대조해야 한다.

== 핵심 구조/작동 방식 ==
첫 번째 층은 인터프리터와 패키지 설치 도구이다. 개발을 시작하기 전에 셸에서 Python과 pip의 실제 버전 및 경로를 확인한다. 운영체제의 시스템 Python에 모든 패키지를 섞어 넣지 않고 프로젝트별 가상 환경을 사용하면 서로 다른 프로젝트가 요구하는 버전을 격리할 수 있다. 안내서는 Pipenv와 virtualenv를 설명하며, Python 3.3부터 표준 라이브러리에 venv가 포함되었다는 점도 기록한다.

두 번째 층은 의존성 명세이다. 필요한 패키지와 버전을 사람이 다시 설치할 수 있는 파일로 남기고, 개발·시험·문서 생성에 필요한 항목도 저장소에서 찾을 수 있게 한다. 안내서의 예시는 Pipfile이나 requirements.txt를 사용하며, 고정된 환경을 다시 설치하는 흐름을 보여 준다. 중요한 원칙은 가상 환경 디렉터리 자체를 버전 관리하지 않고 선언 파일과 설치 절차를 관리하는 것이다. 애플리케이션, 재사용 라이브러리, 데이터 과학 실험은 배포 방식이 다르므로 잠금 전략도 목적에 맞춰야 한다.

세 번째 층은 저장소와 모듈의 구조이다. 가이드의 예시 저장소는 README, LICENSE, 패키지 코드, 의존성 파일, docs, tests를 서로 구분한다. 모듈과 함수는 역할별로 묶고 데이터 흐름과 의존성이 드러나게 한다. 순환 의존, 숨은 결합, 과도한 전역 상태, 긴 절차 코드, 의미 없이 잘게 나눈 클래스는 유지보수를 어렵게 하는 징후이다. 모듈 이름은 짧고 소문자로 두며, <code>import *</code>보다 출처가 드러나는 명시적 import를 사용하라는 방향을 제시한다.

네 번째 층은 자동 검증이다. 코드 스타일은 팀이 읽는 비용을 줄이는 공통 규칙이며, 테스트는 변경이 기존 동작을 깨뜨렸는지 확인하는 실행 가능한 명세이다. 작은 시험은 단일 파일에서 시작할 수 있지만 규모가 커지면 tests 디렉터리로 분리한다. 테스트는 구현 세부보다 공개 동작과 경계 조건을 검증하고, CI에서 깨끗한 환경을 다시 만들어 실행하는 것이 좋다. README에는 시작 방법을, docs에는 사용법과 API 설명을, 라이선스 파일에는 재사용 조건을 명확히 둔다.

이 구조를 실제 작업 순서로 바꾸면 인터프리터 버전 결정, 격리 환경 생성, 의존성 선언, 패키지와 테스트 분리, 정적 검사 및 테스트 자동화, 문서와 배포 절차 기록이 된다. 새 구성원이 저장소를 복제한 뒤 문서화된 명령만으로 같은 결과를 얻는지를 확인하면 환경의 재현성을 현실적으로 점검할 수 있다. [[AI 코딩 에이전트 작업 원칙]]을 적용할 때도 이 명시적인 구조가 에이전트의 작업 범위와 검증 명령을 분명하게 만든다.

== 활용 ==
웹 서비스에서는 개발·시험·운영 의존성을 분리하고 CI와 컨테이너가 같은 설치 명세를 사용하도록 할 수 있다. 데이터 분석에서는 노트북만 남기지 않고 입력 데이터 조건, 환경 파일, 재실행 스크립트, 결과 검증을 함께 관리한다. 배포 라이브러리는 공개 API, 최소 런타임 의존성, 패키지 메타데이터와 호환 버전을 명확히 해야 한다. 교육용 프로젝트에서는 가상 환경, 명시적 import, 단위 테스트, README부터 단계적으로 적용할 수 있다.

또한 [[C++ 선언형 데이터 처리]]나 [[.NET 머신 러닝 프레임워크]] 같은 다른 언어의 라이브러리를 Python 바인딩 또는 외부 프로세스로 연결할 때도 환경 경계가 중요하다. 네이티브 확장에는 컴파일러, ABI, 운영체제 라이브러리까지 재현 조건에 포함된다. 이때 Python 패키지 버전만 고정했다고 전체 실행 환경이 재현되는 것은 아니다.

== 한계 및 주의점 ==
python-guide는 스스로 의견 지향적이며 개발 중인 문서라고 밝힌다. 예제 중 <code>setup.py</code>, Python 2 지원, 특정 도구 추천은 작성 시기의 생태계를 반영할 수 있으므로 새 프로젝트의 유일한 근거로 삼아서는 안 된다. 2026년 현재 사용할 Python 버전과 패키징 형식은 공식 Python·PyPA 문서를 우선 확인하고, 조직의 보안 및 배포 정책에 맞춰 선택해야 한다.

버전 고정은 재현성을 높이지만 보안 수정과 호환성 갱신을 자동으로 해결하지 않는다. 잠금 파일을 주기적으로 갱신하고 취약점 검사와 회귀 테스트를 함께 운영해야 한다. 비밀키와 실제 환경 변수 값은 저장소에 넣지 않고 예시 이름과 주입 방법만 문서화한다. 가상 환경은 Python 패키지를 격리할 뿐 데이터베이스, GPU 드라이버, 시스템 라이브러리까지 격리하지 않으므로 필요한 외부 조건을 별도로 기록해야 한다.

== 함께 보기 ==
* [[최근 GitHub Star 연구 주제]]
* [[AI 코딩 에이전트 작업 원칙]]
* [[C++ 선언형 데이터 처리]]
* [[.NET 머신 러닝 프레임워크]]

== 출처 ==
* [https://github.com/realpython/python-guide realpython/python-guide 공식 저장소]
* [https://docs.python-guide.org/ The Hitchhiker's Guide to Python 공식 공개 문서]
* [https://docs.python-guide.org/dev/virtualenvs/ Pipenv & Virtual Environments]
* [https://docs.python-guide.org/writing/structure/ Structuring Your Project]
* [https://docs.python-guide.org/writing/tests/ Testing Your Code]
* [https://docs.python.org/3/library/venv.html Python 공식 <code>venv</code> 문서]
* [https://packaging.python.org/ Python Packaging User Guide]

[[분류:GitHub Star 연구]]
[[분류:Python]]
[[분류:소프트웨어 개발]]
[[분류:개발 환경]]

PyTorch

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:53 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''PyTorch'''는 Facebook(Meta)이 개발한 오픈소스 딥러닝 프레임워크이다. 동적 계산 그래프와 자동 미분(autograd)을 기반으로 하며, 연구와 생산 모두에서 널리 사용되는 대표 딥러닝 프레임워크와 틀을 걷게 되었다.

== 개요 ==
PyTorch는 2016년 공개 이후 2018년 1.0 버전을 기저으로 안정적인 생태계를 구축했다. Lua 기반의 Torch의 후속으로 Python API를 제공하며, 머신 러닝 연구의 사실상 표준으로 자리잡았다. CUDA 가속을 기본으로 지원하며 세분화된 테스터, 자동 미분, 배처 출력 등의 기능을 제공한다.

== 주요 기능 ==

=== 동적 계산 그래프 ===
실행 시점에 계산 그래프를 구성하는 동적 방식으로, 조건문와 반복문이 자연스럽게 작동한다. 이로 인해 실험적인 모델 개발과 디버깅이 쉽다.

=== 자동 미분(autograd) ===
텐서 연산 시 백프로퍼레스 공간이 자동으로 구성되어, 변화량의 계산이 자동으로 수행된다. 드로피 출이 없이 경사도 계산과 가중치 갱신이 가능하다.

=== torch.onnx.export ===
[[ONNX]]로 모델을 내보내는 기능으로, 추론 단계에서 다양한 프레임워크와 하드웨어에서 모델을 사용할 수 있게 해 준다. [[ONNX]] 및 [[ONNX Runtime]] 생태계의 중심 적 사용 시나리오다.

=== torch.compile 및 TorchScript ===
모델 추론 성능 최적화를 위한 역할 기능으로, 그래프 함성화, 연산 함성화, 멀티 GPU 배치 등을 지원한다.

== 생태계 ==

=== 라이브러리 ===
[[Hugging Face]] Transformers의 대부분 모델이 PyTorch 기반으로 제공된다. [[ComfyUI]], [[Stable Diffusion]] 등 이미지 생성 생태계도 PyTorch 위에서 동작한다.

=== 파인튜닝 기술 ===
[[LoRA]] 등의 파인튜닝 기법이 PyTorch 기반 생태계에서 많이 사용된다.

== 함께 보기 ==

* [[ONNX]] — PyTorch 모델을 내보내는 표준 형식
* [[허깡페이스]] — PyTorch 기반 모델 허브
* [[ComfyUI]] — PyTorch 위에서 동작하는 이미지 생성 도구
* [[LoRA]] — PyTorch 생태계의 파인튜닝 기법

== 출처 ==

* [https://pytorch.org/ PyTorch 공식 웹사이트]
* [https://github.com/pytorch/pytorch GitHub: pytorch/pytorch]

[[분류:딥러닝 프레임워크]]
[[분류:오픈소스 소프트웨어]]

OpenGL 경량 GUI

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:52 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''OpenGL 경량 GUI'''는 렌더링 애플리케이션의 기존 그래픽 문맥 안에 버튼, 슬라이더, 텍스트 상자, 창과 레이아웃 같은 조작 요소를 비교적 작은 의존성과 코드로 추가하는 사용자 인터페이스 방식이다. [https://github.com/wjakob/nanogui NanoGUI]는 OpenGL 3.x 이상을 대상으로 하는 크로스 플랫폼 위젯 라이브러리이다.

== 개요 ==
NanoGUI는 대규모 데스크톱 애플리케이션 프레임워크 전체를 제공하기보다, 시각화·렌더러·연구 데모에 필요한 위젯과 이벤트 처리를 OpenGL 화면에 결합하는 데 초점을 둔다. 자동 레이아웃, 여러 위젯, 상태를 가진 C++11 람다 콜백, Apple 기기의 Retina 렌더링을 지원한다고 README가 설명한다. pybind11로 기능 전반의 Python 바인딩도 제공한다.

'''2026년 8월 16일 확인 기준''', 공식 README는 이 저장소가 '''maintenance-only mode'''라고 명시한다. 또한 Metal, GLES, WebAssembly 지원 등을 포함해 크게 현대화하고 리팩터링한 새 버전을 별도 저장소로 안내한다. 그러므로 기존 NanoGUI는 안정된 구형 OpenGL 코드나 기존 프로젝트를 유지하는 후보로 보고, 신규 프로젝트는 새 버전과 요구 플랫폼을 함께 비교해야 한다.

== 핵심 구조/작동 방식 ==
하위 계층은 역할별 라이브러리로 나뉜다. GLFW가 창, OpenGL 문맥과 입력 이벤트를 크로스 플랫폼으로 처리한다. GLAD는 OpenGL 3.x 이상의 함수 로딩을 맡고, Eigen은 벡터 같은 기본 수학 자료형에 쓰인다. NanoVG는 2차원 도형과 텍스트를 그린다. NanoGUI는 이 기반 위에 위젯 트리, 이벤트 전달, 레이아웃 계산, 상태 변경과 콜백을 추가해 하나의 GUI 툴킷으로 만든다.

화면은 <code>Screen</code>을 바탕으로 창과 자식 <code>Widget</code>을 계층적으로 붙이는 구조이다. 컨테이너에 <code>BoxLayout</code> 같은 레이아웃을 지정하면 방향, 정렬, 여백과 간격에 따라 자식의 위치가 계산된다. 버튼은 <code>setCallback</code>에 C++11 람다를 등록해 클릭 동작을 연결한다. 슬라이더의 값 변경 콜백에서 텍스트 상자의 값을 바꾸는 식으로 위젯 간 상태를 동기화할 수 있다.

기본 위젯을 직접 조합하는 방식 외에 <code>FormHelper</code>가 있다. 이 편의 계층은 창과 그룹을 만들고 bool, 정수, 실수, 문자열, 열거형, 색상 같은 C++ 변수에 편집 컨트롤을 연결한다. 디버그 파라미터, 재질 값, 카메라 설정처럼 실행 중에 조절할 변수가 많은 연구용 렌더러에서 짧은 코드로 제어판을 만들 수 있다. <code>performLayout</code>, 창 중앙 정렬, 화면 표시와 이벤트 루프는 렌더링 초기화 흐름에 맞춰 호출한다.

빌드는 CMake를 사용한다. README는 의존 서브모듈까지 받도록 <code>git clone --recursive</code>로 복제한 뒤 Makefile 또는 Visual Studio 프로젝트를 생성하는 절차를 제시한다. Linux에서는 X11과 Mesa 관련 개발 패키지가 필요하고 Python 바인딩에는 Python 개발 헤더가 추가로 필요하다. 공식 설명상 macOS의 Clang, Linux의 GCC 또는 Clang, Windows의 Visual Studio 2015 이상에서 동작하며 C++11 지원 컴파일러를 요구한다. 이 목록은 README의 지원 설명이지 최신 조합 전체의 검증표는 아니다.

== 활용 ==
OpenGL 기반 과학 시각화에서 등치면 임곗값, 색상 범위, 카메라나 조명 값을 실시간 조절하는 패널을 붙일 수 있다. 경로 추적기와 3D 엔진 데모에서는 재질과 샘플 수를 바꾸고 렌더링 결과를 즉시 비교할 수 있다. 영상 처리 도구에서는 필터 파라미터와 중간 결과 표시를 한 창에 구성할 수 있다. Python 바인딩은 C++ 렌더링 코어를 유지하면서 실험 제어를 Python으로 작성할 때 유용하다.

[[Qt 도킹 UI]]는 메뉴, 도킹 창, 문서 모델과 복잡한 데스크톱 기능이 필요한 경우의 대안이고, NanoGUI는 렌더링 화면에 작은 제어면을 얹는 경우에 더 가깝다. [[고충실도 3D 시뮬레이션]] 같은 엔진은 자체 편집기와 UI 계층을 가지므로 NanoGUI를 추가하기 전에 이벤트 루프와 렌더 패스가 충돌하지 않는지 검토해야 한다. [[웨이블릿 변환]] 데모에서는 신호, 분해 수준과 웨이블릿 선택을 조절하는 교육용 인터페이스로 활용할 수 있다.

== 한계 및 주의점 ==
유지보수 전용 상태는 새 기능과 플랫폼 대응이 기존 저장소에 적극적으로 추가되지 않을 수 있음을 뜻한다. 원본 README가 Metal, GLES, WebAssembly를 새 버전의 특징으로 별도 안내하므로 기존 버전에 해당 기능이 있다고 가정하면 안 된다. 모바일·웹·Apple의 비 OpenGL 그래픽 경로가 필수라면 새 버전 또는 다른 GUI 계층을 평가해야 한다.

서브모듈 의존성은 복제 누락과 버전 불일치의 원인이 될 수 있다. 프로젝트가 이미 GLFW, GLAD, Eigen, NanoVG의 다른 버전을 사용한다면 중복 심볼, 빌드 옵션, OpenGL 문맥 소유권을 정리해야 한다. HiDPI 배율, 글꼴, 한글 입력기, 접근성, 키보드 탐색, 클립보드 같은 제품 수준 기능은 목표 운영체제에서 직접 검증해야 한다. 경량이라는 설명이 모든 기능이나 바이너리 크기에 대한 보증은 아니다.

NanoGUI 자체는 BSD 계열 라이선스를 사용하지만 아이콘용 Entypo+ 글꼴은 CC BY-SA 4.0이라고 README가 밝힌다. 상용 배포에서는 코드 라이선스뿐 아니라 글꼴의 저작자 표시와 배포 조건을 따로 검토해야 한다. GUI 콜백에서 무거운 계산을 직접 실행하면 이벤트와 렌더링이 멈출 수 있으므로 작업 스레드, 상태 전달과 OpenGL 문맥 접근을 명확히 분리한다.

== 함께 보기 ==
* [[최근 GitHub Star 연구 주제]]
* [[Qt 도킹 UI]]
* [[고충실도 3D 시뮬레이션]]
* [[웨이블릿 변환]]

== 출처 ==
* [https://github.com/wjakob/nanogui wjakob/nanogui 공식 저장소]
* [https://nanogui.readthedocs.io/ NanoGUI 공식 문서]
* [https://github.com/mitsuba-renderer/nanogui NanoGUI 현대화 버전 공식 저장소]

[[분류:GitHub Star 연구]]
[[분류:OpenGL]]
[[분류:GUI]]
[[분류:C++]]

Ollama

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:51 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''Ollama'''는 로컬 컴퓨터에서 대규모 언어 모델을 실행·관리하기 위한 오픈소스 플랫폼이다. 2023년 Jeffrey Morgan과 Michael Chiang이 만들었으며, [[llama.cpp]]를 기반으로 동작한다.

== 개요 ==
Ollama는 명령줄 인터페이스와 네이티브 GUI, 로컬 REST API를 제공한다. 모델을 간단한 명령으로 내려받아 실행할 수 있고, 모델 관리 기능을 갖추고 있다. [[GGUF]] 형식의 모델을 지원하며, 코딩 어시스턴트 등 다른 애플리케이션과 통합할 수 있다.

== 함께 보기 ==

* [[llama.cpp]] — Ollama의 기반 엔진
* [[GGUF]] — Ollama가 지원하는 모델 형식

== 출처 ==

* [https://ollama.com/ Ollama 공식 사이트]
* [https://en.wikipedia.org/wiki/Ollama 위키백과: Ollama]

[[분류:머신 러닝]]
[[분류:오픈 소스]]

ONNX Runtime

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:51 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''[[ONNX]] Runtime'''은 [[ONNX]](Open Neural Network Exchange) 형식으로 저장된 머신 러닝 모델을 실행하는 고성능 추론 엔진이다. Microsoft가 주도하여 개발하며, 다양한 하드웨어 가속기와 실행 공급자를 통해 크로스 플랫폼 추론을 지원한다.

== 개요 ==
[[ONNX]] Runtime은 2018년 첫 공개 이후 PyTorch, TensorFlow 등 주요 프레임워크에서 내보낸 [[ONNX]] 모델을 실행하는 사실상의 표준 추론 엔진으로 자리잡았다. 학습보다는 추론에 특화되어 있으며, CPU뿐 아니라 GPU, NPU, FPGA 등 다양한 하드웨어에서 최적화된 실행을 제공한다.

== 실행 공급자(Execution Provider) ==
[[ONNX]] Runtime의 핵심 설계 요소로, 실행 공급자(EP)를 교체함으로써 동일한 모델을 서로 다른 하드웨어에서 실행할 수 있다.

* CPU — 기본 실행 공급자, Intel MKL-ML 최적화 포함
* CUDA — NVIDIA GPU 가속
* [[DirectML]] — Windows의 모든 DirectX 12 GPU에서 가속
* TensorRT — NVIDIA GPU 고성능 추론
* OpenVINO — Intel CPU/GPU/iGPU/NPU
* CoreML — Apple Silicon (macOS/iOS)
* QNN — Qualcomm NPU
* WebNN — 웹 브라우저 기반 추론

== 활용 사례 ==

=== 로컬 AI ===
[[llama.cpp]]와 [[올라마]] 등이 [[ONNX]] 모델을 지원하며, [[ONNX]] Runtime을 통해 다양한 하드웨어 가속을 활용한다. 특히 [[Stable Diffusion]]의 [[ONNX]] 변환 모델을 [[ONNX]] Runtime + [[DirectML]] 조합으로 AMD GPU에서 실행하는 방식이 널리 쓰인다.

=== 엣지 및 모바일 ===
[[ONNX]] Runtime Mobile 패키지는 Android/iOS 환경에서 경량화된 추론을 지원하며, Qualcomm QNN, Apple CoreML 등 모바일 특화 실행 공급자와 통합된다.

== 함께 보기 ==

* [[DirectML]] — Windows GPU 실행 공급자
* [[llama.cpp]] — [[ONNX]] 모델을 지원하는 LLM 추론 도구
* [[Stable Diffusion]] — [[ONNX]] Runtime으로 가속 가능한 이미지 생성 모델

== 출처 ==

* [https://onnxruntime.ai/ ONNX Runtime 공식 웹사이트]
* [https://github.com/microsoft/onnxruntime GitHub: microsoft/onnxruntime]

[[분류:머신 러닝]]
[[분류:마이크로소프트]]
[[분류:추론 엔진]]

ONNX

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:50 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''ONNX'''('''O'''pen '''N'''eural '''N'''etwork E'''x'''change)는 프레임워크 간 머신 러닝 모델 교환을 위한 개방형 표준 형식이다. 2017년 Microsoft와 Meta(헤스빅)가 공동 발표하였으며, 학습한 모델을 프레임워크와 하드웨어에 관계없이 실행할 수 있는 중립적 표현으로 변환해 준다.

== 개요 ==
ONNX는 각 프레임워크가 자신의 맞춤 표현으로 모델을 저장하며 서로 호환성이 없는 문제를 해결하기 위해 등장하였다. 예를 들어 [[PyTorch]]에서 학습한 모델을 ONNX로 내보낸 후 [[ONNX Runtime]]이나 [[DirectML]] 등에서 실행할 수 있다. ONNX는 두드라이브로 구성되며, 머신 러닝 프레임워크와 하드웨어 생태계의 교통 표준으로 발전했다.

== 형식 구조 ==

=== 그래프 기반 표현 ===
ONNX 모델은 노드(Operators)와 텐서(Tensors)로 구성된 가시홝 그래프로 표현된다. 각 노드는 인공 신경망의 연산자(Conv, MatMul, ReLU 등)를 의미하고, 초기화자(Initializer)를 통해 파라미터를 포함시킬 수 있다.

=== 연산자 집합(OpSet) ===
모델이 사용하는 연산자의 스페코와 버전이 동시에 기록되어 장부화 및 호환성이 유지된다. 새 연산자가 추가되면 OpSet 버전이 올라가며, 획사성을 위해 버전 호환을 유지한다.

=== 메타데이터 ===
모델의 이름, 작성자, 회사변환 정보, 인코더 정보 등의 메타데이터를 포함할 수 있다.

== 생태계 ==

=== 모델 변환 도구 ===
[[PyTorch]]의 torch.onnx.export와 TensorFlow의 tf2onnx, Keras의 onnx2keras 등이 대표적인 변환 도구이다.

=== 실행 엔진 ===
[[ONNX Runtime]]이 가장 대표적이며, 그 외에 ONNX.js, WebDNN 등이 있다. [[WebNN]]은 ONNX 모델을 웹 브라우저에서 실행할 수 있도록 한다.

=== 모델 허브 ===
ONNX Model Zoo를 통해 다양한 사전 학습 모델을 ONNX 형식으로 배포한다.

== 함께 보기 ==

* [[ONNX Runtime]] — ONNX 모델을 실행하는 표준 추론 엔진
* [[PyTorch]] — ONNX로 내보내는 대표 프레임워크
* [[DirectML]] — ONNX 모델을 GPU로 가속하는 실행 공급자
* [[WebNN]] — 웹 브라우저에서의 신경망 추론 표준

== 출처 ==

* [https://onnx.ai/ ONNX 공식 웹사이트]
* [https://github.com/onnx/onnx GitHub: onnx/onnx]

[[분류:머신 러닝]]
[[분류:모델 형식]]

Modality-Invariant Image Matching

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:49 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''Modality-Invariant Image Matching'''은 서로 다른 센서의 표현 차이보다 공통된 공간 구조와 의미를 강조하는 feature를 학습하거나 설계해 correspondence를 찾는 접근이다. 최근 cross-modal matcher를 관통하는 핵심 키워드다.

== 개요 ==

EO, SAR, thermal, map은 같은 대상도 서로 다른 물리·기호 체계로 표현한다. modality-specific variation을 줄이고 geometry-preserving representation을 만드는 것이 중요하다. [[RIFT]]의 phase congruency, [[MINIMA]]의 synthetic multimodal training, [[MatchAnything]]의 large-scale pretraining, [[MIFTr]]의 modality-invariant transformer가 서로 다른 구현 예다.

== 핵심 구조 ==

대표 전략은 구조적 handcrafted signal, semantic foundation feature, synthetic modality generation, text·semantic prior 주입으로 나눌 수 있다. 2026년에는 optical↔SAR를 shared modality로 변환해 [[RoMa]]를 적용하거나 text semantic prior를 쓰는 TAR 연구도 등장했다.

== 활용 ==

EO↔SAR, EO↔IR, EO↔Map, EO↔Drone을 모두 지원하는 제품에서 센서별 모델 수를 줄이는 방향으로 활용할 수 있다. retrieval 단계에서 공통 embedding으로 후보 영역을 좁힌 뒤 dense matcher를 적용하는 coarse-to-fine pipeline도 가능하다.

== 한계 및 주의점 ==

Invariance가 너무 강하면 pixel-level localization에 필요한 고주파 세부 정보까지 잃을 수 있다. coarse semantic matching과 fine geometric refinement를 분리하고 실제 GSD 기반 meter error로 최종 검증해야 한다.

== 함께 보기 ==
* [[Cross-Modal Image Matching 기술 지도]]
* [[MINIMA]]
* [[MatchAnything]]
* [[MIFTr]]

== 출처 ==
* [https://openaccess.thecvf.com/content/CVPR2025/html/Ren_MINIMA_Modality_Invariant_Image_Matching_CVPR_2025_paper.html MINIMA]
* [https://arxiv.org/abs/2501.07556 MatchAnything]
* [https://arxiv.org/abs/2602.12515 Shared modality SAR·Optical matching]
* [https://arxiv.org/abs/2605.12064 TAR]

[[분류:Cross-Modal Image Matching]]
[[분류:Multimodal Learning]]

MatchAnything

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:48 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''MatchAnything'''은 대규모 synthetic cross-modal pretraining을 통해 하나의 matcher가 다양한 unseen modality 조합에 일반화하도록 만드는 2025년 연구다. Universal cross-modality matching을 직접 목표로 한다.

== 개요 ==

정확한 correspondence label을 가진 다양한 센서 조합 데이터가 부족하다는 문제를 synthetic cross-modal signal로 해결하려 한다. 논문은 하나의 weight로 8개가 넘는 unseen cross-modality registration task에 일반화하는 결과를 보고한다.

공식 zju3dv/MatchAnything 저장소는 pretrained model을 [[Hugging Face]]로 제공하지만 2026년 8월 확인 시 저장소 화면에서 명시적 코드 라이선스가 뚜렷하게 표시되지 않는다. 성능 후보와 상용 후보를 분리해 취급해야 한다.

== 핵심 구조 ==

Architecture보다 pretraining distribution 확장이 핵심이다. 다양한 modality appearance를 만들어도 동일 위치의 geometric correspondence를 유지해 supervision을 대규모로 확보한다. [[MINIMA]]와 철학적으로 유사하다.

== 활용 ==

EO↔SAR, EO↔IR, map↔photo 등 여러 입력 조합을 한 엔진으로 처리하고 싶을 때 연구 가치가 높다. [[EfficientLoFTR]] baseline과 비교하면 cross-modal pretraining의 이득을 분리할 수 있다.

== 한계 및 주의점 ==

공개 weight 다운로드 가능 여부는 상업적 재배포 권리와 다르다. 코드 라이선스, model card, training data와 synthetic generation pipeline을 각각 확인해야 한다.

== 함께 보기 ==
* [[Cross-Modal Image Matching 기술 지도]]
* [[MINIMA]]
* [[EfficientLoFTR]]
* [[Modality-Invariant Image Matching]]

== 출처 ==
* [https://github.com/zju3dv/MatchAnything MatchAnything 공식 GitHub]
* [https://arxiv.org/abs/2501.07556 MatchAnything 논문]

[[분류:Cross-Modal Image Matching]]
[[분류:Multimodal Learning]]

MapGlue

Admina7ec671ac513 — Thu, 20 Aug 2026 04:18:47 GMT

migrate: import legacy Wiki content to Vultr

새 문서

'''MapGlue'''는 multimodal remote sensing image matching을 직접 겨냥한 2025년 프레임워크다. 함께 제안된 MapData는 전자지도와 visible image의 대규모 정렬 쌍을 제공해 map↔EO 문제를 주요 학습·평가 대상으로 만든다.

== 개요 ==

MapData는 전 세계 233개 sampling point에서 수집된 원본 고해상도 자료를 정제해 121,781개의 512×512 electronic map–visible pair를 구성했다고 논문이 보고한다. MapGlue는 semantic context와 dual graph-guided interaction을 이용해 modality-invariant feature를 강화한다.

공식 저장소는 FastMapGlue TorchScript weight와 demo를 제공한다. 그러나 2026년 8월 현재 공개 화면에서 명시적 LICENSE 항목이 확인되지 않아 상용 통합 전 사용 조건을 별도 확인해야 한다.

== 핵심 구조 ==

지도는 도로, 건물, 수계 등을 기호로 표현하므로 pixel intensity보다 semantic structure가 중요하다. MapGlue는 global-to-local interaction과 graph-guided mechanism으로 이런 구조적 대응을 강화한다.

== 활용 ==

EO↔Map 지오로컬라이제이션, GPS-denied navigation, 위성·드론 영상의 지도 기반 초기 위치 추정에 유용하다. FastMapGlue의 TorchScript 형태는 패키징과 runtime benchmark 가치가 있다.

== 한계 및 주의점 ==

MapData 중심 학습이 SAR나 thermal로 얼마나 일반화하는지는 자체 데이터로 확인해야 한다. dataset 공개 범위와 라이선스도 모델과 별도로 실사한다.

== 함께 보기 ==
* [[Cross-Modal Image Matching 기술 지도]]
* [[Modality-Invariant Image Matching]]
* [[Cross-Modal Matching 벤치마크]]
* [[MIFTr]]

== 출처 ==
* [https://github.com/PeihaoWu/MapGlue MapGlue 공식 GitHub]
* [https://arxiv.org/abs/2503.16185 MapGlue 논문]

[[분류:Cross-Modal Image Matching]]
[[분류:Remote Sensing Registration]]