[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-27-postgresql-daegyu-seongneung-indekseu-vacuum-chueogjihwa":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":24,"related_articles":35},"d5000000-0000-0000-0000-000000000127","a0000000-0000-0000-0000-000000000055","Deep EVM #27: PostgreSQL 대규모 성능 — 인덱스, VACUUM, 쿼리 최적화","deep-evm-27-postgresql-daegyu-seongneung-indekseu-vacuum-chueogjihwa","부분 인덱스, 시계열 BRIN, autovacuum 튜닝, EXPLAIN ANALYZE 해석, 일반적인 안티 패턴으로 PostgreSQL 성능을 마스터합니다.","## PostgreSQL 성능의 기초\n\n대규모 PostgreSQL 데이터베이스를 운영할 때 가장 중요한 세 가지 영역은 인덱스 전략, VACUUM 관리, 쿼리 최적화입니다. 이 세 가지를 올바르게 조합하면 수백만 행의 테이블에서도 밀리초 단위의 쿼리 응답을 유지할 수 있습니다.\n\n## 인덱스 전략\n\n### B-Tree: 기본이자 최강\n\nB-Tree 인덱스는 PostgreSQL의 기본 인덱스 유형이며, 대부분의 워크로드에 최적입니다:\n\n```sql\n-- 기본 B-Tree 인덱스\nCREATE INDEX idx_transactions_block ON transactions (block_number);\n\n-- 복합 인덱스: 왼쪽에서 오른쪽으로 선택도 높은 순서\nCREATE INDEX idx_transactions_addr_block\n    ON transactions (from_addr, block_number DESC);\n```\n\n복합 인덱스 설계의 핵심 규칙:\n- 등호 조건 열을 먼저, 범위 조건 열을 나중에\n- 선택도가 높은 열을 먼저\n- 정렬 순서를 쿼리의 ORDER BY와 일치시키기\n\n### 부분 인덱스: 필요한 것만 인덱싱\n\n전체 테이블의 작은 부분만 자주 쿼리된다면, 부분 인덱스가 극적인 공간과 성능 개선을 제공합니다:\n\n```sql\n-- 최근 미확인 트랜잭션만 인덱싱\nCREATE INDEX idx_pending_tx\n    ON transactions (created_at)\n    WHERE status = 'pending';\n\n-- 고가치 전송만 인덱싱\nCREATE INDEX idx_high_value_transfers\n    ON transactions (block_number, from_addr)\n    WHERE value > 1000000000000000000;  -- > 1 ETH\n```\n\n부분 인덱스는 행의 5% 미만이 조건을 충족할 때 특히 효과적입니다. 인덱스 크기가 95% 줄어들고, 삽입\u002F업데이트 시 인덱스 유지 비용도 감소합니다.\n\n### BRIN: 시계열 데이터의 비밀 무기\n\nBlock Range INdex(BRIN)는 물리적으로 정렬된 데이터에 적합합니다:\n\n```sql\nCREATE INDEX idx_transactions_block_brin\n    ON transactions USING brin (block_number)\n    WITH (pages_per_range = 128);\n```\n\nBRIN vs B-Tree 비교:\n\n| 특성 | B-Tree | BRIN |\n|------|--------|------|\n| 인덱스 크기 (1억 행) | 2.1 GB | 5 MB |\n| INSERT 오버헤드 | 높음 | 매우 낮음 |\n| 포인트 쿼리 | O(log N) | O(범위 스캔) |\n| 범위 쿼리 | 우수 | 우수 (정렬된 데이터) |\n\nBRIN은 시계열 데이터에서 B-Tree 대비 400배 작은 인덱스를 제공하면서, 범위 쿼리에서는 비슷한 성능을 유지합니다.\n\n### GIN: JSONB와 배열 검색\n\nGIN 인덱스는 JSONB, 배열, 전문 검색에 사용됩니다:\n\n```sql\n-- JSONB 키 검색\nCREATE INDEX idx_events_data ON events USING gin (data);\n\n-- 특정 경로만 인덱싱 (더 효율적)\nCREATE INDEX idx_events_type\n    ON events USING gin ((data -> 'type'));\n```\n\n## VACUUM 관리\n\nPostgreSQL의 MVCC 모델은 업데이트\u002F삭제된 행을 즉시 제거하지 않습니다. 대신 \"데드 튜플\"로 남겨두고, VACUUM이 정리합니다.\n\n### autovacuum 튜닝\n\n기본 autovacuum 설정은 대규모 테이블에 불충분합니다:\n\n```sql\n-- 테이블별 autovacuum 설정\nALTER TABLE transactions SET (\n    autovacuum_vacuum_scale_factor = 0.01,     -- 기본 0.2 -> 0.01\n    autovacuum_vacuum_threshold = 10000,        -- 기본 50\n    autovacuum_analyze_scale_factor = 0.005,    -- 기본 0.1\n    autovacuum_vacuum_cost_delay = 2            -- 기본 2ms -> 더 공격적\n);\n```\n\n1억 행 테이블에서:\n- 기본: 2천만 행이 변경되어야 VACUUM 트리거\n- 튜닝 후: 100만 행 변경 시 트리거\n\n### VACUUM 모니터링\n\n```sql\n-- 데드 튜플 모니터링\nSELECT\n    relname,\n    n_live_tup,\n    n_dead_tup,\n    ROUND(n_dead_tup::numeric \u002F NULLIF(n_live_tup, 0) * 100, 2) AS dead_pct,\n    last_vacuum,\n    last_autovacuum\nFROM pg_stat_user_tables\nWHERE n_dead_tup > 10000\nORDER BY n_dead_tup DESC;\n```\n\n데드 튜플 비율이 10%를 초과하면 VACUUM이 뒤처지고 있으며, autovacuum 설정을 더 공격적으로 조정해야 합니다.\n\n## EXPLAIN ANALYZE 읽기\n\nEXPLAIN ANALYZE는 쿼리 최적화의 가장 강력한 도구입니다:\n\n```sql\nEXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)\nSELECT * FROM transactions\nWHERE from_addr = '\\x1234...'\n  AND block_number > 19000000\nORDER BY block_number DESC\nLIMIT 50;\n```\n\n출력에서 주의할 핵심 지표:\n\n- **actual time**: 실제 실행 시간 (첫 행..마지막 행)\n- **rows**: 예상 행 vs 실제 행 (큰 차이 = 오래된 통계)\n- **Buffers**: shared hit (캐시) vs shared read (디스크)\n- **Sort Method**: quicksort(메모리) vs external merge(디스크)\n\n### 일반적인 안티 패턴\n\n```sql\n-- 안티 패턴 1: SELECT * (필요 없는 열까지 로드)\n-- 나쁨:\nSELECT * FROM transactions WHERE block_number = 19000000;\n-- 좋음:\nSELECT tx_hash, from_addr, value FROM transactions WHERE block_number = 19000000;\n\n-- 안티 패턴 2: 함수 래핑으로 인덱스 무효화\n-- 나쁨 (인덱스 사용 불가):\nSELECT * FROM events WHERE LOWER(event_type) = 'transfer';\n-- 좋음 (표현식 인덱스 사용):\nCREATE INDEX idx_events_type_lower ON events (LOWER(event_type));\n\n-- 안티 패턴 3: OFFSET 페이지네이션\n-- 나쁨 (OFFSET 1000000은 백만 행을 스캔 후 폐기):\nSELECT * FROM transactions ORDER BY id OFFSET 1000000 LIMIT 50;\n-- 좋음 (커서 기반 페이지네이션):\nSELECT * FROM transactions WHERE id > 1000000 ORDER BY id LIMIT 50;\n```\n\n## 커넥션 풀링\n\nPostgreSQL은 커넥션당 프로세스를 포크합니다. 커넥션이 100개를 넘으면 메모리와 컨텍스트 스위칭 오버헤드가 심각해집니다:\n\n```ini\n# PgBouncer 구성\n[pgbouncer]\npool_mode = transaction\nmax_client_conn = 1000\ndefault_pool_size = 20\nmin_pool_size = 5\nreserve_pool_size = 5\nserver_idle_timeout = 300\n```\n\nPgBouncer를 사용하면 1000개의 애플리케이션 커넥션을 20개의 실제 PostgreSQL 커넥션으로 다중화할 수 있습니다.\n\n## 쿼리 통계 모니터링\n\n```sql\n-- pg_stat_statements 활성화\nCREATE EXTENSION IF NOT EXISTS pg_stat_statements;\n\n-- 가장 느린 쿼리 상위 10개\nSELECT\n    LEFT(query, 100) AS query_preview,\n    calls,\n    ROUND(total_exec_time::numeric \u002F 1000, 2) AS total_sec,\n    ROUND(mean_exec_time::numeric, 2) AS avg_ms,\n    ROUND(stddev_exec_time::numeric, 2) AS stddev_ms,\n    rows\nFROM pg_stat_statements\nORDER BY mean_exec_time DESC\nLIMIT 10;\n```\n\n## 결론\n\nPostgreSQL 대규모 성능은 세 개의 기둥 위에 서 있습니다: 올바른 인덱스 전략(B-Tree, 부분 인덱스, BRIN, GIN), 공격적인 VACUUM 관리(autovacuum 튜닝, 데드 튜플 모니터링), 지능적인 쿼리 설계(EXPLAIN ANALYZE, 안티 패턴 회피). 이 세 가지를 체계적으로 접근하면, 수억 행의 테이블에서도 밀리초 단위의 응답 시간을 유지할 수 있습니다.","\u003Ch2 id=\"postgresql\">PostgreSQL 성능의 기초\u003C\u002Fh2>\n\u003Cp>대규모 PostgreSQL 데이터베이스를 운영할 때 가장 중요한 세 가지 영역은 인덱스 전략, VACUUM 관리, 쿼리 최적화입니다. 이 세 가지를 올바르게 조합하면 수백만 행의 테이블에서도 밀리초 단위의 쿼리 응답을 유지할 수 있습니다.\u003C\u002Fp>\n\u003Ch2 id=\"\">인덱스 전략\u003C\u002Fh2>\n\u003Ch3>B-Tree: 기본이자 최강\u003C\u002Fh3>\n\u003Cp>B-Tree 인덱스는 PostgreSQL의 기본 인덱스 유형이며, 대부분의 워크로드에 최적입니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- 기본 B-Tree 인덱스\nCREATE INDEX idx_transactions_block ON transactions (block_number);\n\n-- 복합 인덱스: 왼쪽에서 오른쪽으로 선택도 높은 순서\nCREATE INDEX idx_transactions_addr_block\n    ON transactions (from_addr, block_number DESC);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>복합 인덱스 설계의 핵심 규칙:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>등호 조건 열을 먼저, 범위 조건 열을 나중에\u003C\u002Fli>\n\u003Cli>선택도가 높은 열을 먼저\u003C\u002Fli>\n\u003Cli>정렬 순서를 쿼리의 ORDER BY와 일치시키기\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>부분 인덱스: 필요한 것만 인덱싱\u003C\u002Fh3>\n\u003Cp>전체 테이블의 작은 부분만 자주 쿼리된다면, 부분 인덱스가 극적인 공간과 성능 개선을 제공합니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- 최근 미확인 트랜잭션만 인덱싱\nCREATE INDEX idx_pending_tx\n    ON transactions (created_at)\n    WHERE status = 'pending';\n\n-- 고가치 전송만 인덱싱\nCREATE INDEX idx_high_value_transfers\n    ON transactions (block_number, from_addr)\n    WHERE value > 1000000000000000000;  -- > 1 ETH\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>부분 인덱스는 행의 5% 미만이 조건을 충족할 때 특히 효과적입니다. 인덱스 크기가 95% 줄어들고, 삽입\u002F업데이트 시 인덱스 유지 비용도 감소합니다.\u003C\u002Fp>\n\u003Ch3>BRIN: 시계열 데이터의 비밀 무기\u003C\u002Fh3>\n\u003Cp>Block Range INdex(BRIN)는 물리적으로 정렬된 데이터에 적합합니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE INDEX idx_transactions_block_brin\n    ON transactions USING brin (block_number)\n    WITH (pages_per_range = 128);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>BRIN vs B-Tree 비교:\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>특성\u003C\u002Fth>\u003Cth>B-Tree\u003C\u002Fth>\u003Cth>BRIN\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>인덱스 크기 (1억 행)\u003C\u002Ftd>\u003Ctd>2.1 GB\u003C\u002Ftd>\u003Ctd>5 MB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>INSERT 오버헤드\u003C\u002Ftd>\u003Ctd>높음\u003C\u002Ftd>\u003Ctd>매우 낮음\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>포인트 쿼리\u003C\u002Ftd>\u003Ctd>O(log N)\u003C\u002Ftd>\u003Ctd>O(범위 스캔)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>범위 쿼리\u003C\u002Ftd>\u003Ctd>우수\u003C\u002Ftd>\u003Ctd>우수 (정렬된 데이터)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>BRIN은 시계열 데이터에서 B-Tree 대비 400배 작은 인덱스를 제공하면서, 범위 쿼리에서는 비슷한 성능을 유지합니다.\u003C\u002Fp>\n\u003Ch3>GIN: JSONB와 배열 검색\u003C\u002Fh3>\n\u003Cp>GIN 인덱스는 JSONB, 배열, 전문 검색에 사용됩니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- JSONB 키 검색\nCREATE INDEX idx_events_data ON events USING gin (data);\n\n-- 특정 경로만 인덱싱 (더 효율적)\nCREATE INDEX idx_events_type\n    ON events USING gin ((data -> 'type'));\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"vacuum\">VACUUM 관리\u003C\u002Fh2>\n\u003Cp>PostgreSQL의 MVCC 모델은 업데이트\u002F삭제된 행을 즉시 제거하지 않습니다. 대신 “데드 튜플“로 남겨두고, VACUUM이 정리합니다.\u003C\u002Fp>\n\u003Ch3>autovacuum 튜닝\u003C\u002Fh3>\n\u003Cp>기본 autovacuum 설정은 대규모 테이블에 불충분합니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- 테이블별 autovacuum 설정\nALTER TABLE transactions SET (\n    autovacuum_vacuum_scale_factor = 0.01,     -- 기본 0.2 -> 0.01\n    autovacuum_vacuum_threshold = 10000,        -- 기본 50\n    autovacuum_analyze_scale_factor = 0.005,    -- 기본 0.1\n    autovacuum_vacuum_cost_delay = 2            -- 기본 2ms -> 더 공격적\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>1억 행 테이블에서:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>기본: 2천만 행이 변경되어야 VACUUM 트리거\u003C\u002Fli>\n\u003Cli>튜닝 후: 100만 행 변경 시 트리거\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>VACUUM 모니터링\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- 데드 튜플 모니터링\nSELECT\n    relname,\n    n_live_tup,\n    n_dead_tup,\n    ROUND(n_dead_tup::numeric \u002F NULLIF(n_live_tup, 0) * 100, 2) AS dead_pct,\n    last_vacuum,\n    last_autovacuum\nFROM pg_stat_user_tables\nWHERE n_dead_tup > 10000\nORDER BY n_dead_tup DESC;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>데드 튜플 비율이 10%를 초과하면 VACUUM이 뒤처지고 있으며, autovacuum 설정을 더 공격적으로 조정해야 합니다.\u003C\u002Fp>\n\u003Ch2 id=\"explain-analyze\">EXPLAIN ANALYZE 읽기\u003C\u002Fh2>\n\u003Cp>EXPLAIN ANALYZE는 쿼리 최적화의 가장 강력한 도구입니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)\nSELECT * FROM transactions\nWHERE from_addr = '\\x1234...'\n  AND block_number > 19000000\nORDER BY block_number DESC\nLIMIT 50;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>출력에서 주의할 핵심 지표:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>actual time\u003C\u002Fstrong>: 실제 실행 시간 (첫 행..마지막 행)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>rows\u003C\u002Fstrong>: 예상 행 vs 실제 행 (큰 차이 = 오래된 통계)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Buffers\u003C\u002Fstrong>: shared hit (캐시) vs shared read (디스크)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sort Method\u003C\u002Fstrong>: quicksort(메모리) vs external merge(디스크)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>일반적인 안티 패턴\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- 안티 패턴 1: SELECT * (필요 없는 열까지 로드)\n-- 나쁨:\nSELECT * FROM transactions WHERE block_number = 19000000;\n-- 좋음:\nSELECT tx_hash, from_addr, value FROM transactions WHERE block_number = 19000000;\n\n-- 안티 패턴 2: 함수 래핑으로 인덱스 무효화\n-- 나쁨 (인덱스 사용 불가):\nSELECT * FROM events WHERE LOWER(event_type) = 'transfer';\n-- 좋음 (표현식 인덱스 사용):\nCREATE INDEX idx_events_type_lower ON events (LOWER(event_type));\n\n-- 안티 패턴 3: OFFSET 페이지네이션\n-- 나쁨 (OFFSET 1000000은 백만 행을 스캔 후 폐기):\nSELECT * FROM transactions ORDER BY id OFFSET 1000000 LIMIT 50;\n-- 좋음 (커서 기반 페이지네이션):\nSELECT * FROM transactions WHERE id > 1000000 ORDER BY id LIMIT 50;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"\">커넥션 풀링\u003C\u002Fh2>\n\u003Cp>PostgreSQL은 커넥션당 프로세스를 포크합니다. 커넥션이 100개를 넘으면 메모리와 컨텍스트 스위칭 오버헤드가 심각해집니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-ini\"># PgBouncer 구성\n[pgbouncer]\npool_mode = transaction\nmax_client_conn = 1000\ndefault_pool_size = 20\nmin_pool_size = 5\nreserve_pool_size = 5\nserver_idle_timeout = 300\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>PgBouncer를 사용하면 1000개의 애플리케이션 커넥션을 20개의 실제 PostgreSQL 커넥션으로 다중화할 수 있습니다.\u003C\u002Fp>\n\u003Ch2 id=\"\">쿼리 통계 모니터링\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- pg_stat_statements 활성화\nCREATE EXTENSION IF NOT EXISTS pg_stat_statements;\n\n-- 가장 느린 쿼리 상위 10개\nSELECT\n    LEFT(query, 100) AS query_preview,\n    calls,\n    ROUND(total_exec_time::numeric \u002F 1000, 2) AS total_sec,\n    ROUND(mean_exec_time::numeric, 2) AS avg_ms,\n    ROUND(stddev_exec_time::numeric, 2) AS stddev_ms,\n    rows\nFROM pg_stat_statements\nORDER BY mean_exec_time DESC\nLIMIT 10;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"\">결론\u003C\u002Fh2>\n\u003Cp>PostgreSQL 대규모 성능은 세 개의 기둥 위에 서 있습니다: 올바른 인덱스 전략(B-Tree, 부분 인덱스, BRIN, GIN), 공격적인 VACUUM 관리(autovacuum 튜닝, 데드 튜플 모니터링), 지능적인 쿼리 설계(EXPLAIN ANALYZE, 안티 패턴 회피). 이 세 가지를 체계적으로 접근하면, 수억 행의 테이블에서도 밀리초 단위의 응답 시간을 유지할 수 있습니다.\u003C\u002Fp>\n","ko","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:28.309343Z","PostgreSQL 대규모 성능 — 인덱스, VACUUM, 쿼리 최적화","부분 인덱스, 시계열 BRIN, autovacuum 튜닝, EXPLAIN ANALYZE 해석, 일반적인 안티 패턴으로 PostgreSQL 성능 마스터.","PostgreSQL 성능 최적화",null,"index, follow",[22,27,31],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000022","Performance","performance",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000005","PostgreSQL","postgresql",[36,43,49],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":41,"published_at":42},"d0000000-0000-0000-0000-000000000674","2026년, Bali가 동남아시아의 임팩트 테크 허브가 되고 있는 이유","bali-2026-dongnamasia-impaekteu-tekeu-heobeu-iyu","Bali는 동남아시아 스타트업 생태계에서 16위를 차지하고 있습니다. Web3 빌더, AI 지속가능성 스타트업, 에코 여행 테크 기업이 집중되면서, 이 섬은 지역 임팩트 테크의 수도로 자리매김하고 있습니다.","엔지니어링","2026-03-28T10:44:49.294484Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":41,"published_at":48},"d0000000-0000-0000-0000-000000000673","ASEAN 데이터 보호 패치워크: 개발자를 위한 컴플라이언스 체크리스트","asean-deiteo-boho-paechiwokeu-gaebaljaleul-wihan-keompeullaieonseuchekeuriseuteu","7개 ASEAN 국가가 포괄적인 데이터 보호법을 시행하고 있으며, 각각 다른 동의 모델, 현지화 요건, 벌칙 구조를 가지고 있습니다. 다중 국가 애플리케이션을 구축하는 개발자를 위한 실용적인 컴플라이언스 체크리스트입니다.","2026-03-28T10:44:49.286400Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":41,"published_at":54},"d0000000-0000-0000-0000-000000000672","Indonesia 290억 달러 디지털 전환: 소프트웨어 기업을 위한 기회","indonesia-290eok-dallleo-dijiteol-jeonhwan-sopeuteuweo-gieopui-gihoe","Indonesia IT 서비스 시장은 2026년 290.3억 달러에 달할 것으로 예상되며, 이는 2025년 243.7억 달러에서 증가한 수치입니다. 클라우드 인프라, AI, 전자상거래, 데이터센터가 동남아시아에서 가장 빠른 성장을 주도하고 있습니다.","2026-03-28T10:44:49.265609Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":19,"linkedin":19,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]