이제 반 지났다...

리눅스에서 로그 파일의 1000번째 줄부터 2000번째 줄까지를 추출하여 별도 파일로 저장

a_mnesia — Fri, 5 Sep 2025 17:03:32 +0900

리눅스에서 로그 파일의 1000번째 줄부터 2000번째 줄까지를 추출하여 별도 파일로 저장

✅ 방법 1: sed 명령어 사용

sed -n '1000,2000p' /path/to/source.log > /path/to/output.log

구성설명

-n	출력 억제 (선택한 줄만 출력)
'1000,2000p'	1000번 줄부터 2000번 줄까지 출력
> output.log	결과를 별도 파일로 저장

✅ 방법 2: awk 명령어 사용

awk 'NR>=1000 && NR<=2000' /path/to/source.log > /path/to/output.log

NR: 현재 라인 번호
NR >= 1000 && NR <= 2000인 줄만 출력

awk는 필터링 조건을 더 추가하고 싶을 때 확장성이 좋습니다.

✅ 예제

sed -n '1000,2000p' /var/log/syslog > ~/logs/syslog_chunk.log

또는

awk 'NR>=1000 && NR<=2000' /var/log/syslog > ~/logs/syslog_chunk.log

참고: 추출 대상 줄 수 확인

전체 라인 수를 먼저 알고 싶다면:

wc -l /path/to/source.log

wc -l /path/to/source.log

추가 팁

파일에 헤더 라인이 있는 경우, 첫 줄을 유지하고 1000~2000줄을 추가하고 싶다면 다음과 같이 조합도 가능:

(head -n 1 /path/to/source.log && sed -n '1000,2000p' /path/to/source.log) > output_with_header.log

로그 파일에서 특정 문자열을 포함한 줄만 추출하거나, 압축된 로그(.gz 등)에서 직접 검색하는 방법

✅ 1. 특정 문자열 포함한 줄만 추출

grep 명령어 사용

grep "에러코드123" /path/to/logfile.log

옵션설명

"에러코드123"	찾고자 하는 문자열
/path/to/logfile.log	검색 대상 로그 파일 경로

여러 키워드 중 하나라도 포함된 줄 검색

grep -E "ERROR|FATAL|PANIC" logfile.log

-E는 extended regex 사용
|는 OR 조건

추출 결과를 별도 파일로 저장

grep "에러코드123" logfile.log > filtered.log

줄 번호도 함께 출력

grep -n "에러코드123" logfile.log

✅ 2. 압축된 로그(.gz)에서 직접 검색

zgrep 사용

zgrep "에러코드123" logfile.log.gz

zgrep은 gzip 파일에서 압축 해제 없이 직접 검색

여러 키워드 OR 검색 (zgrep -E)

zgrep -E "ERROR|FATAL|PANIC" logfile.log.gz

줄 번호까지 포함하고 싶다면

zcat logfile.log.gz | grep -n "에러코드123"

zcat으로 압축 해제 후 grep을 조합

1000~2000줄 사이에서 특정 문자열만 검색

sed -n '1000,2000p' logfile.log | grep "에러코드123"

또는 압축 파일이라면:

zcat logfile.log.gz | sed -n '1000,2000p' | grep "에러코드123"

정리

목적명령어 예시

일반 로그에서 문자열 검색	grep "문자열" logfile.log
압축 로그에서 문자열 검색	zgrep "문자열" logfile.log.gz
줄 번호 포함 검색	grep -n "문자열" logfile.log
특정 줄 범위에서 검색	`sed -n '1000,2000p' logfile
결과 저장	... > output.log

Linux에서 디렉토리나 파일을 최근 변경된 순서로 정렬하여 리스트

a_mnesia — Wed, 6 Aug 2025 17:01:19 +0900

Linux에서 디렉토리나 파일을 최근 변경된 순서로 정렬하여 리스트하고 싶다면, ls 명령어에 다음 옵션들을 조합해서 사용하면 됩니다:

가장 기본적인 명령어

ls -lt

옵션의미

-l	상세 목록(long format)
-t	최종 수정 시간(descending) 기준으로 정렬

결과는 최근에 수정된 파일이 가장 위에 표시됩니다.

디렉토리만 보고 싶다면?

ls -ltd */

*/는 현재 디렉토리 내의 하위 디렉토리만 대상으로 리스트업
-d는 디렉토리 자체에 대한 정보만 출력 (디렉토리 내부 내용 출력 방지)

수정 시간 말고 "변경 시간(ctime)" 기준 정렬하려면?

ls -ltc

-c: inode 변경 시간(change time) 기준 정렬
(예: 권한 변경, 소유자 변경 등도 포함)

서브 디렉토리 포함 전체 탐색하려면

find . -type f -printf "%T@ %Tc %p\n" | sort -n

항목설명

-type f	파일만 찾음
%T@	epoch 시간 출력 (정렬용)
%Tc	human-readable 시간
%p	파일 경로
sort -n	시간 오름차순 정렬

→ sort -nr로 바꾸면 최근 변경된 순으로 정렬됩니다.

전체 예시: 최근 변경된 디렉토리 Top 5

bash

복사편집

ls -ltd -- */ | head -n 5

find . -type f -printf "%T@ %Tc %p\n" | sort -n

요약 명령어 모음

목적명령어

전체 파일/디렉토리 변경순	ls -lt
디렉토리만 최근순	ls -ltd */
변경시간(ctime) 기준	ls -ltc
서브디렉토리 포함 전체 파일 변경순	`find . -type f -printf "%T@ %Tc %p\n"

Linux 명령어 (파일의 라인수, CSV파일 읽기 및 별도파일생성)

a_mnesia — Tue, 15 Jul 2025 13:05:19 +0900

Linux lsyncd log 파일 초기화

1. : > 연산자 사용 (내용만 비우고 파일 유지)

: > /var/log/lsyncd/lsyncd.log

파일 내용만 모두 지우고, 파일 자체는 그대로 유지됨
touch와 달리 변경시간은 갱신됨
프로세스가 계속해서 이 파일을 로그로 쓰는 경우에도 안전하게 사용 가능

2. truncate 명령 사용

truncate -s 0 /var/log/lsyncd/lsyncd.log

파일의 사이즈를 0으로 줄여 초기화함
동일하게 내용만 삭제, 권한/소유자/경로 그대로 유지

3. echo 명령 사용

echo "" > /var/log/lsyncd/lsyncd.log

빈 문자열을 덮어씌워 내용 삭제

주의사항

로그 파일을 삭제(rm)하고 새로 만드는 것은 서비스나 데몬이 파일 핸들 유지 중일 경우 로그 기록이 끊기는 문제가 발생할 수 있습니다.
따라서 파일 삭제보다는 내용만 비우는 방법이 안전합니다.

리눅스에서 각 파일의 line 수를 확인하는 방법

1. 단일 파일의 라인 수 확인

wc -l filename.txt

출력 예시:
123 filename.txt → 총 123줄

2. 현재 디렉토리의 모든 파일에 대한 라인 수 확인

wc -l *

각 파일의 라인 수와 파일명이 나열되고, 마지막에 전체 합계가 나옵니다.
디렉토리 포함시 에러 발생 가능성이 있으므로 텍스트 파일만 지정하려면:

wc -l *.txt

3. 하위 디렉토리 포함 모든 파일 라인 수 확인 (재귀적)

find . -type f -exec wc -l {} +

.: 현재 디렉토리부터
-type f: 파일만 검색
-exec wc -l {}: 각 파일에 대해 wc -l 실행

4. 결과를 정렬하여 출력 (라인 수 기준 내림차순)

find . -type f -exec wc -l {} + | sort -nr

5. 특정 확장자만 필터링 (예: .py)

find . -name "*.py" -type f -exec wc -l {} + | sort -nr

참고: 라인 수만 합산하려면

find . -type f -name "*.java" -exec cat {} + | wc -l

모든 .java 파일의 라인을 합쳐서 총 라인 수만 출력합니다.

find . -name "*.tpl.html" -type f -exec wc -l {} + | sort -nr
find . -name "*.tpl.html" -exec wc -l {} + | sort -nr

라인수만계산
find . -type f -name "*.tpl.html" -exec cat {} + | wc -l
find . -type f -name "*.tpl.html" -exec wc -l {} + | sort -nr

linux csv파일 상위 10개 라인만 조회하는 명령어

리눅스에서 **CSV 파일의 상위 10개 라인(행)**만 조회하려면, 일반적으로 head 명령어를 사용합니다.

기본 명령어

head -n 10 yourfile.csv

yourfile.csv 파일의 앞 10줄을 출력합니다.
-n 뒤에 원하는 숫자를 지정하면 해당 줄 수만큼 출력됩니다.

예시

head -n 10 customers.csv

→ customers.csv 파일의 1행(헤더 포함)부터 10행까지 보여줍니다.

✅ 헤더 제외 상위 10개 데이터만 보고 싶을 때

tail -n +2 yourfile.csv | head -n 10

tail -n +2: 2번째 줄부터 끝까지 출력 (즉, 헤더 제외)
그 후 head -n 10으로 상위 10줄을 자릅니다.

CSV 파일의 상위 10개 라인만 추출해서 새로운 파일로 저장

head 명령어 + 리디렉션 사용

bash

복사편집

head -n 10 original.csv > top10.csv

original.csv의 앞 10줄을 읽어서
top10.csv라는 새 파일에 저장합니다.
기존 파일이 있을 경우 덮어씌워집니다.

헤더 제외하고 상위 10개 데이터만 저장하려면

head -n 10 original.csv > top10.csv

2번째 줄부터 읽은 뒤 상위 10줄만 추출하여 저장
보통 데이터만 필요할 때 사용

헤더 포함 + 상위 10개 데이터 저장 (즉, 11줄: 헤더 + 10줄)

(head -n 1 original.csv && tail -n +2 original.csv | head -n 10) > top10_with_header.csv

head -n 1: 헤더 1줄 추출
tail -n +2 | head -n 10: 데이터 10줄 추출
전체를 ()로 묶고 >로 새로운 파일에 저장

GCash

a_mnesia — Wed, 18 Jun 2025 10:42:04 +0900

GCash는 필리핀 최대 모바일 지갑 서비스로, Globe Fintech Innovations, Inc. (브랜드명 Mynt)에 속해 있으며, 운영은 자회사인 G‑Xchange, Inc. (GXI)가 담당하고 있습니다 tribune.net.ph+15en.wikipedia.org+15new.gcash.com+15.

GCash: 회사 개요

서비스: 송금, 결제, 송금, 쇼핑, 투자, 보험 등 금융 기능 제공 datanyze.com+2new.gcash.com+2stlpartners.com+2
출시: 2004년 10월 cgaa.org+2en.wikipedia.org+2chrisgarin.com+2
가입자 수: 2023년 기준 약 8,100만명 사용 중 mynt.xyz

소유주 및 주요 주주 구조

GCash의 모회사 Mynt는 Globe Telecom 계열의 917Ventures가 설립하고, Ant Group(Alibaba 그룹 계열사), Ayala Corporation, 그리고 Globe Telecom이 공동 투자한 합작법인(JV) 구조입니다 growjo.com+15en.wikipedia.org+15reuters.com+15.

Globe Telecom: 통신업체이며, 917Ventures의 모회사
Ant Group: Alibaba 그룹 계열로, Alipay 운영사
Ayala Corporation: 필리핀 재계의 대표적인 대기업으로, Mynt 지분율은 약 13% (2024년 추가 투자 기준) marketech-apac.com+3business-news-asia.com+3reuters.com+3
Mitsubishi UFJ Financial Group (MUFG): 2024~2025년 중 8% 지분 추가 확보, Mynt의 가치를 약 50억 달러로 평가 stlpartners.com+15marketech-apac.com+15mb.com.ph+15

결론적으로 현재 주요 주주는 Globe Telecom (via 917Ventures), Ant Group, Ayala, 그리고 MUFG입니다.

요약 정리

회사명	Globe Fintech Innovations, Inc. (브랜드명: Mynt)
운영 서비스	G-Xchange, Inc. (GCash 서비스)
서비스 시작	2004년 10월
주요 주주	Globe Telecom (through 917Ventures), Ant Group, Ayala Corporation (~13%), MUFG (~8%)
Valuation	약 50억 달러 (2024)

update-ca-trust extract가 작동하지 않는 주요 원인

a_mnesia — Tue, 10 Jun 2025 09:45:09 +0900

1. 인증서 형식 오류 (PEM 형식 아님)

인증서 파일은 반드시 **PEM 형식 (Base64 인코딩)**이어야 하며, 다음과 같은 헤더가 포함되어야 합니다:

-----BEGIN CERTIFICATE-----
... (Base64 encoded content)
-----END CERTIFICATE-----

형식이 맞지 않으면 무시됩니다.

확인 방법:

cat /etc/pki/ca-trust/source/anchors/your-cert.crt.pem

2. 잘못된 경로에 파일을 넣음

유효한 경로는 다음 중 하나입니다:
- /etc/pki/ca-trust/source/anchors/ ✅ (권장)
- /etc/pki/ca-trust/source/blacklist/ ❌ (차단 리스트)
- /usr/share/pki/ca-trust-source/ (시스템 전역)
anchors 폴더 외 경로에 넣으면 적용되지 않습니다.

3. 파일 확장자가 .crt 또는 .pem이 아님

파일 확장자는 반드시 .crt, .pem, .cer 중 하나여야 하며, 그렇지 않으면 무시됩니다.

✔️ 권장 예:

your-cert.crt

4. 인증서 내용이 실제로 CA 인증서가 아님

개인 인증서(Client Cert)나 중간 인증서가 아닌 Root 또는 Intermediate CA 인증서여야 합니다.
openssl x509 -in cert.pem -text -noout 명령어로 Basic Constraints: CA:TRUE 여부를 확인하세요.

5. extract 실행 후 시스템에 적용 안 됨

update-ca-trust extract는 시스템 내 /etc/ssl/certs/ca-bundle.crt 등을 갱신하지만,
- 이를 사용하는 앱(OpenSSL, curl 등)만 영향을 받음
- Java는 전혀 영향을 받지 않습니다. (cacerts 별도 관리)

빠르게 점검하는 체크리스트

항목점검

.crt 파일이 PEM 형식인가요?	✅
파일에 -----BEGIN CERTIFICATE----- 헤더가 있나요?	✅
anchors 폴더에 위치했나요? (/etc/pki/ca-trust/source/anchors/)	✅
update-ca-trust extract를 실행했나요?	✅
openssl verify로 테스트해 봤나요?	✅

적용 여부 테스트

openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt your-target-cert.pem

이 명령어로 시스템에 반영되었는지 테스트할 수 있습니다.

/etc/pki/ca-trust/extracted/java/cacerts 에 update-ca-trust extract로 your-cert.cer를 등록하는 방법

/etc/pki/ca-trust/extracted/java/cacerts 경로에 인증서를 등록하려는 경우, 이는 Java용 Trust Store에 해당하는 시스템 CA 통합 결과 파일입니다. 이 파일은 직접 수정하는 것이 아니라, update-ca-trust extract 명령으로 자동 생성되며, 다음 절차에 따라야 등록이 성공합니다.

목적:

update-ca-trust extract 실행 시 **/etc/pki/ca-trust/extracted/java/cacerts**에
your-cert.cer 인증서가 포함되도록 만드는 절차

등록 절차 요약

1. 인증서를 PEM 형식으로 준비

# 확인: PEM 형식인지 체크
grep "BEGIN CERTIFICATE" your-cert.cer

2. anchors 폴더에 복사

sudo cp your-cert.cer /etc/pki/ca-trust/source/anchors/

⚠️ 반드시 .cer, .crt, .pem 확장자 중 하나여야 하고, PEM 형식이어야 합니다.

3. Trust Store 갱신

sudo update-ca-trust extract

이 명령은 /etc/ssl/certs/ca-bundle.crt와 함께 /etc/pki/ca-trust/extracted/java/cacerts도 함께 갱신합니다.

4. 등록 성공 여부 확인

grep -A 1 "BEGIN CERTIFICATE" /etc/pki/ca-trust/extracted/java/cacerts | less

또는, 파일 내부에 인증서 정보가 포함됐는지 openssl로 확인:

openssl x509 -in /etc/pki/ca-trust/extracted/java/cacerts -text -noout

(위 명령은 일부 시스템에서 오류 발생 가능 — 이 경우 단순 문자열 검색이 더 유효함)

인증서가 포함되지 않는 경우 주요 원인

원인설명

인증서 형식이 DER	openssl x509 -inform der로 확인 및 PEM 변환 필요
인증서에 CA:TRUE가 없음	루트 또는 중간 CA 인증서가 아닌 경우 무시됨
파일 위치 또는 확장자 오류	/anchors/가 아닌 위치거나 확장자가 비표준일 경우 무시됨

필요시 PEM 변환

openssl x509 -in your-cert.cer -inform der -out your-cert.pem -outform pem
sudo cp your-cert.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

결론

/etc/pki/ca-trust/extracted/java/cacerts는 수동 수정 대상이 아니며,
PEM 인증서를 anchors/에 넣고 update-ca-trust extract를 실행해야 반영됩니다.

DeFi에 대한 6가지 기본 질문

a_mnesia — Fri, 16 May 2025 21:06:47 +0900

1. 개인 금융(Personal Banking)에서 DeFi란 무엇인가요?

DeFi(탈중앙화 금융)는 개인에게 자신의 자산에 대한 직접적인 통제권과 허가 없이 이용할 수 있는 금융 서비스를 제공합니다.

개인은 다음과 같은 방식으로 DeFi를 활용할 수 있습니다:

DEX(탈중앙화 거래소)를 통한 비(非)수탁형 거래
- 중개기관 없이 직접 암호화폐를 거래할 수 있습니다.
대출 및 차입 프로토콜 참여로 수익 창출 및 담보 대출 이용
- 암호화폐를 예치해 이자를 얻거나, 담보를 제공하고 대출을 받을 수 있습니다.
스테이블코인 활용
- 결제 수단으로 사용하거나, 암호화폐 시장의 높은 변동성에 대비하기 위한 헤지(위험 회피) 수단으로 활용할 수 있습니다.

2. DeFi 은행의 예시는 무엇인가요?

DeFi 은행은 전통적인 의미의 은행은 아니지만, Aave, Compound, MakerDAO와 같은 DeFi 프로토콜들이 은행과 유사한 금융 서비스를 제공합니다.

이러한 프로토콜은 오픈소스와 비(非)수탁형(non-custodial) 플랫폼으로 운영되며, 스마트 계약에 의해 관리됩니다.

주요 제공 서비스는 다음과 같습니다:

대출 (Lending)
차입 (Borrowing)
스테이블코인 발행 (Stablecoin Issuance)

전통적인 금융기관 없이도 사용자가 직접 자산을 빌려주고 빌릴 수 있으며, 스테이블코인과 같은 디지털 자산을 발행하고 활용할 수 있도록 지원합니다.

3. 거래 은행(Transaction Banking)에서 DeFi란 무엇인가요?

DeFi(탈중앙화 금융)는 거래 은행 분야에서도 큰 변화를 일으키고 있습니다.

주요 변화 내용:

국경 간 결제의 간소화
- 복잡한 절차 없이 빠르고 효율적인 해외 송금이 가능합니다.
중개기관 의존도 감소
- 기존 은행, 결제 네트워크 등의 중개자가 필요하지 않으므로 비용과 시간이 절감됩니다.
스테이블코인 기반 결제 채널 활용
- USDC, USDT와 같은 스테이블코인을 사용해 가치 변동 위험 없이 결제할 수 있습니다.
Layer-2 확장 솔루션 활용 (예: Lightning Network)
- 비트코인 네트워크의 라이트닝 네트워크와 같은 Layer-2 솔루션을 사용하여 더 빠르고 저렴한 거래 처리가 가능합니다.
탈중앙화 결제 게이트웨이 도입
- 기업들은 탈중앙화된 결제 게이트웨이를 통해 암호화폐 결제를 직접 수락할 수 있으며, 이를 통해 결제 처리 비용을 절감하고 글로벌 고객에게 더 쉽게 접근할 수 있습니다.

DeFi는 거래 은행 분야에서 더 빠르고, 저렴하며, 투명한 결제 및 정산 환경을 제공함으로써, 기존 금융 인프라를 대체하거나 보완하는 역할을 하고 있습니다.

4. DeFi 뱅킹(DeFi Banking)이란 무엇이며, 전통적인 은행과 어떻게 다른가요?

DeFi 뱅킹은 중앙집중화되고 중개 기관에 의존하는 기존 금융 시스템에서 벗어나, 탈중앙화된 개인 간(Peer-to-Peer) 금융 모델로 전환하는 패러다임 변화를 의미합니다.

DeFi 뱅킹의 주요 특징:

블록체인 기술과 스마트 계약 활용
- 자동화된 계약으로 중개자 없이 거래가 이루어집니다.
중개 기관 불필요
- 은행, 결제 네트워크, 브로커 등의 역할을 스마트 계약과 프로토콜이 대신합니다.
투명성 향상
- 모든 거래 기록은 블록체인에 저장되어 누구나 검증할 수 있습니다.
접근성 확대
- 전통 금융 서비스에 접근하기 어려운 사람들도 인터넷과 암호화폐 지갑만 있으면 금융 서비스를 이용할 수 있습니다.
사용자 주도적 자산 관리
- 개인이 자신의 자산에 대한 완전한 통제권을 가집니다.

전통적인 은행과의 주요 차이점 비교

구분전통적인 은행DeFi 뱅킹

운영 주체	중앙 기관 (은행)	탈중앙화 네트워크
중개자 존재	있음 (필수)	없음 (스마트 계약)
투명성	제한적	완전한 공개
접근성	제한적 (계좌 필요)	누구나 참여 가능
자산 통제	은행이 관리	사용자가 직접 관리
비용 구조	수수료 및 서비스 요금	상대적으로 저렴

DeFi 뱅킹은 기존 금융 시스템의 복잡함과 비효율성을 제거하고, 사용자에게 더 많은 자율성과 투명성, 그리고 비용 절감 혜택을 제공하는 혁신적인 금융 모델입니다.

5. DeFi 은행을 전통 은행보다 사용하는 장점은 무엇인가요?

DeFi(탈중앙화 금융)는 사용자에게 다음과 같은 여러 가지 이점을 제공합니다:

1. 허가 없는 접근 (Permissionless Access)

별도의 계좌 개설, 신용 조회 등의 절차 없이 누구나 DeFi 서비스를 이용할 수 있습니다.
전 세계 어디에서나 인터넷과 암호화폐 지갑만 있으면 금융 서비스 이용이 가능합니다.

2. 높은 투명성과 감사 가능성 (Transparency and Auditability)

모든 거래 내역은 퍼블릭 블록체인에 기록되며, 누구나 이를 실시간으로 확인하고 검증할 수 있습니다.
금융 거래의 불투명성과 조작 가능성을 크게 줄일 수 있습니다.

3. 조합성과 상호운용성 (Composability and Interoperability)

서로 다른 DeFi 프로토콜 간에 연동이 가능하여,
새로운 금융 상품과 서비스를 자유롭게 조합하고 개발할 수 있습니다.
예: Aave에서 대출받고, Curve Finance로 유동성 제공, Compound로 이자 수익 창출.

4. 프로그래밍 가능성과 자동화 (Programmability and Automation)

스마트 계약을 통해 금융 계약을 자동으로 실행할 수 있어,
수동 개입 없이 효율적으로 거래가 처리됩니다.
예: 정해진 조건에 따라 자동 상환, 이자 지급 등이 가능.

5. 상대적으로 높은 수익률 (Potentially Higher Returns)

DeFi 대출 및 투자 프로토콜은 전통적인 예금 상품이나 투자 상품보다 더 높은 이자율과 수익률을 제공하는 경우가 많습니다.
이는 중개 기관이 없어, 수익이 직접 사용자에게 돌아가기 때문입니다.

DeFi 은행은 사용자가 더 쉽게 금융 서비스에 접근하고, 더 높은 수익을 얻으며, 거래의 투명성과 자산 통제력을 직접 확보할 수 있게 해주는 혁신적인 대안 금융 시스템입니다.

6. DeFi 뱅킹은 어떻게 작동하며, 어떤 기술이 사용되나요?

DeFi(탈중앙화 금융) 뱅킹은 다음과 같은 핵심 기술을 활용하여 운영됩니다:

1. 블록체인 (Blockchain)

블록체인은 분산 원장 기술로, 모든 거래 내역을 안전하고 투명하게 기록합니다.
데이터를 중앙 서버가 아닌 네트워크 참여자들이 공동으로 관리하며, 변경이나 위조가 어렵습니다.
주요 블록체인 플랫폼: 이더리움(Ethereum), Solana, Polygon 등

2. 스마트 계약 (Smart Contracts)

스마트 계약은 자동으로 실행되는 디지털 계약입니다.
계약 조건이 충족되면 사람이 개입하지 않아도 자동으로 거래나 금융 계약이 실행됩니다.
이를 통해 중개 기관 없이 금융 서비스 제공이 가능하고, 운영 효율성을 높일 수 있습니다.
예시:
- 자동 대출 실행
- 이자 지급
- 담보 청산

3. 탈중앙화 거버넌스 (Decentralized Governance)

DeFi 생태계에서는 **DAO(Decentralized Autonomous Organization)**와 같은 거버넌스 메커니즘을 활용하여,
커뮤니티가 직접 프로토콜 개선과 정책 결정을 주도합니다.
거버넌스 토큰을 가진 사용자가 제안 및 투표를 통해 시스템 업그레이드나 주요 의사결정에 참여합니다.
예시 플랫폼: Uniswap DAO, MakerDAO, Aave Governance

DeFi 뱅킹은 블록체인과 스마트 계약을 기반으로, 탈중앙화된 방식으로 금융 서비스를 제공하며,
프로토콜의 운영과 개선은 커뮤니티 중심의 거버넌스 시스템을 통해 이루어집니다.

Linux Java TrustStore에서 오래된 인증서 예전 인증서 제거하는 방법

a_mnesia — Wed, 14 May 2025 08:34:50 +0900

Linux 시스템의 cacerts 파일은 Java 신뢰할 수 있는 인증서 저장소 (Java TrustStore) 입니다. 오래된 인증서를 제거하고 최신 인증서를 관리하는 것은 보안상 매우 중요합니다.

인증서 제거 절차

1. keytool 명령어 확인

Java TrustStore는 keytool로 관리합니다.
우선 keytool 경로와 Java 환경을 확인합니다.

which keytool
java -version

예시 TrustStore 경로:
/etc/alternatives/java_sdk/jre/lib/security/cacerts

2. 현재 저장된 인증서 목록 확인

sudo keytool -list -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -storepass changeit

기본 패스워드: changeit (변경했으면 해당 패스워드 사용)
주요 정보:
- 별칭 (Alias)
- 만료일
- 인증기관 정보

3. 제거할 인증서 결정

예전 인증서를 별칭(Alias) 기준으로 제거합니다.
목록에서 예전 인증서를 찾고 별칭을 메모해 두세요.

4. 인증서 삭제 명령어

sudo keytool -delete -alias <alias_name> -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -storepass changeit

<alias_name>: 삭제할 인증서의 별칭
예시:

sudo keytool -delete -alias old_cert -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -storepass changeit

5. 삭제 후 확인

sudo keytool -list -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -storepass changeit

삭제된 인증서가 목록에서 사라졌는지 반드시 확인하세요.

주의 사항

cacerts는 시스템 전역 Java 인증서 저장소입니다. 삭제 전 반드시 백업 하시기 바랍니다.

sudo cp /etc/alternatives/java_sdk/jre/lib/security/cacerts /etc/alternatives/java_sdk/jre/lib/security/cacerts.bak

패스워드를 변경했을 경우, changeit 대신 새 패스워드를 사용 하시기 바랍니다.
일부 시스템에서는 경로가 다를 수 있습니다. 확인 후 정확한 경로 사용 필요.

Excel에서 두 시분초(예, 010203)값의 차이를 초로 계산하기

a_mnesia — Mon, 28 Apr 2025 21:37:38 +0900

START_DT	START_TIME	END_DT	END_TIME
20250427	001003	20250427	001238
20250427	001003	20250427	001120
20250427	001003	20250427	001145
20250427	001500	20250427	005432

값중에서 START_TIME과 END_TIME의 차이를 초로 계산하는 방법

START_DT	START_TIME	END_DT	END_TIME	차이 (초)
20250427	001003	20250427	001238	155
20250427	001003	20250427	001120	77
20250427	001003	20250427	001145	102
20250427	001500	20250427	005432	2372

Excel 함수로 변환 공식

만약 A1 셀에 021320처럼 숫자 형태로 입력되어 있다고 가정할 때, 이를 초(second)로 변환하는 공식은 다음과 같습니다:

=INT(A1/10000)*3600 + INT(MOD(A1,10000)/100)*60 + MOD(A1,100)

설명

부분의미

INT(A1/10000)	시(hour) 추출
MOD(A1,10000)/100	분(minute) 추출
MOD(A1,100)	초(second) 추출
각각 시는 ×3600, 분은 ×60을 해서 모두 초로 변환 후 합산

두 값의 초 차이 구하는 공식

예를 들어,

A1 = 021320
B1 = 021428
이렇게 두 값이 있다고 하면, 두 값의 초 차이를 구하는 공식은:

=(INT(B1/10000)*3600 + INT(MOD(B1,10000)/100)*60 + MOD(B1,100)) 
- (INT(A1/10000)*3600 + INT(MOD(A1,10000)/100)*60 + MOD(A1,100))

결과

위 수식을 입력하면,
B1 - A1의 초 단위 차이가 바로 계산됩니다.

추가 팁

결과를 분:초 형식으로 보고 싶으면 =TEXT(초값/86400,"[mm]:ss") 형식으로 변환할 수도 있습니다.
예를 들어 위 공식 결과가 68초라면,
=TEXT(68/86400,"[mm]:ss") 로 01:08처럼 표시할 수 있습니다.

결과를 시:분:초 (hh:mm:ss) 형식으로 변환

엑셀에서는 시간 = 초 / 86400 을 하면 시간 형식으로 바꿀 수 있습니다.
(하루 = 24시간 × 60분 × 60초 = 86400초)

=TEXT(
   ((INT(B1/10000)*3600 + INT(MOD(B1,10000)/100)*60 + MOD(B1,100)) 
   - (INT(A1/10000)*3600 + INT(MOD(A1,10000)/100)*60 + MOD(A1,100))) / 86400,
   "hh:mm:ss"
)

결과 예시

위 식을 적용하면 668초 → 00:11:08 로 출력됩니다.

추가 팁

TEXT(..., "hh:mm:ss")로 표시 형식을 지정하지 않으면 엑셀이 소수로 인식할 수 있으므로 반드시 TEXT로 감싸거나, 셀 서식을 **사용자 지정 → hh:mm:ss**로 설정하세요.

HTTP Request Smuggling (요청 스머글링)이란?

a_mnesia — Mon, 28 Apr 2025 12:32:35 +0900

HTTP Request Smuggling (요청 스머글링)이란?

**HTTP 요청 스머글링(HTTP Request Smuggling, HRS)**이란,
**프론트엔드 서버(리버스 프록시, 로드 밸런서 등)**와 백엔드 서버(애플리케이션 서버) 간
HTTP 요청 해석 차이점을 악용하여 요청을 변조하거나 몰래 끼워 넣는 공격 기법을 의미합니다.

간단히 말하면,

"앞단 서버는 하나의 요청이라 생각했지만, 뒷단 서버는 두 개 이상의 요청으로 인식하여
공격자가 숨겨둔 악의적 요청이 몰래 처리되는 것"
이라고 할 수 있습니다.

어떻게 발생하는가?

HTTP 요청 본문의 길이를 명시하는 Content-Length 헤더와
요청을 여러 개로 구분하는 Transfer-Encoding: chunked 헤더의 해석 차이를 이용합니다.

프론트 서버와 백엔드 서버가 서로 다르게 이 두 헤더를 해석하면,
공격자가 숨긴 두 번째 요청이 정상 요청에 끼워 넣어져 처리될 수 있습니다.

예시 흐름

POST / HTTP/1.1
Host: example.com
Content-Length: 50
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: example.com

프론트 서버는 Content-Length를 기준으로 해석하여 요청 완료라 판단하지만,
백엔드 서버는 Transfer-Encoding을 기준으로 해석하여 뒤의 숨은 GET 요청을 별개로 처리할 수 있습니다.

주요 공격 결과

공격 효과설명

요청 가로채기	다른 사용자의 요청을 탈취할 수 있습니다.
세션 하이재킹	세션 토큰 탈취 가능.
캐시 포이즈닝	잘못된 응답을 캐시하여 불특정 다수에게 악성 응답을 제공할 수 있습니다.
비인가 요청 전송	관리자 페이지 접근, CSRF 보조 공격 등.

방어 및 대응 방법

대응 방법세부 설명

단일 길이 기준 강제화	Content-Length 또는 Transfer-Encoding 중 하나만 허용.
HTTP 요청 일관성 검사	서버 간 동일한 해석 기준 유지 (엄격한 RFC 준수).
최신 웹서버/프록시 업데이트	nginx, Apache, HAProxy 등의 보안 패치 적용.
WAF 규칙 강화	WAF(Web Application Firewall)에서 의심 요청 차단.
input validation 강화	HTTP 요청 헤더와 바디를 철저히 검증.

덧붙여

HTTP Request Smuggling은 2005년에 처음 발견되었으나,
2020년대 이후 클라우드 환경, API Gateway, Reverse Proxy 사용 증가로 인해 다시 부각되었습니다.
특히 Android 앱에서도 백엔드와 통신할 때 리버스 프록시를 거치는 경우, 서버 측 대응이 매우 중요합니다.

추가로

Android App 관점에서 HTTP Request Smuggling 대응 가이드

1. 앱 내부 네트워크 통신 라이브러리 설정 강화

Android 앱은 보통 OkHttp, Retrofit, HttpURLConnection 등을 통하여 서버와 통신합니다.
이를 사용하는 경우, 기본 설정만으로는 일부 우회 시도가 가능할 수도 있으므로, 아래를 꼭 지켜야 합니다.

OkHttp / Retrofit 대응

HTTP/1.1 또는 HTTP/2 명시적 사용 (HTTP/0.9, HTTP/1.0은 지원 차단)
Transfer-Encoding: chunked 사용 최소화
Content-Length 헤더의 일관성 확보 (명시적 지정 권장)

val client = OkHttpClient.Builder()
    .protocols(listOf(Protocol.HTTP_1_1, Protocol.HTTP_2))
    .build()

Interceptor 추가로 비정상 요청 방어

class HeaderValidationInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val headers = request.headers

        // 의심스러운 헤더 검증
        if (headers.names().any { it.equals("Transfer-Encoding", ignoreCase = true) }
            && headers.names().any { it.equals("Content-Length", ignoreCase = true) }) {
            throw IOException("Invalid HTTP headers detected: Smuggling risk.")
        }

        return chain.proceed(request)
    }
}

// 적용 예시
val safeClient = OkHttpClient.Builder()
    .addInterceptor(HeaderValidationInterceptor())
    .build()

2. 서버와 통신 시 HTTPS 강제 사용

반드시 HTTPS 통신만 허용할 것.
앱의 network_security_config.xml을 설정하여 **Cleartext Traffic(HTTP)**을 차단할 것.

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

AndroidManifest.xml에도 반영

<application
    android:networkSecurityConfig="@xml/network_security_config"
    android:usesCleartextTraffic="false">

3. 서버 측 검증 동시 강화

비록 앱에서 요청을 조심하더라도,
**서버(백엔드)**가 최종적으로 요청을 검증하고 해석하므로 서버단에서도 반드시 다음을 해야 합니다 :

서버 측 조치설명

Proxy, LB 업데이트	nginx, HAProxy 등을 최신 버전으로 유지.
Content-Length/Transfer-Encoding 혼용 차단	둘 중 하나만 허용하거나, 둘 모두 존재할 경우 요청 거부.
Request size 제한	요청 본문 크기에 상한 설정 (예: 8KB 제한).
경계 테스트 수행	BurpSuite, OWASP ZAP 등으로 Smuggling 테스트.

4. 취약점 대응 주기적 점검

앱과 서버 모두 대상으로 OWASP ASVS 4.0 기준을 활용하여 정기 점검을 수행할 것.
OWASP HTTP Request Smuggling Cheat Sheet를 참조하여 공격 패턴 업데이트 및 방어할 것.

HTTP Request Smuggling Cheat Sheet (OWASP)

맺음말

"애초에 요청이 올바르게 구성되도록 하고, 서버가 의심스러운 요청을 철벽같이 막아내는 것이
HTTP Request Smuggling을 완전히 차단하는 길"입니다.

Android 앱에서도 '안전한 요청 생성'은 매우 중요하니,
앱 단에서부터 안전한 통신을 기본으로 삼고, 서버와의 협력 체계를 단단히 다지는 것이 필수라 할수 있습니다.

jQuery 1.4에서 jQuery 3.5 이상으로 업그레이드 Plan

a_mnesia — Tue, 22 Apr 2025 10:04:59 +0900

jQuery 1.4에서 jQuery 3.5(또는 3.x 최신 버전)로 업그레이드하는 데 소요되는 시간은 웹 애플리케이션의 규모, jQuery 의존도, 사용자 정의 코드의 복잡도에 따라 달라집니다. 다음은 일반적인 상황에서의 추정과 주요 고려사항입니다.

예상 소요 시간

업무 범위작업 항목예상 소요 시간

사전 분석 및 계획	사용 중인 jQuery 기능 목록화, 호환성 확인	0.5 ~ 1일
라이브러리 교체 및 기본 테스트	jQuery 3.5로 교체, Migrate 플러그인 적용	0.5일
기능 점검 및 수정	비호환 API, deprecated 기능 수정 (예: .bind(), .size(), .live() 등)	1 ~ 3일
UI/UX 테스트	주요 브라우저 및 기기 호환성 점검	1 ~ 2일
최종 배포 및 리그레션 테스트	CI/CD 배포 및 회귀 테스트	0.5 ~ 1일

총 예상 기간: 약 3 ~ 7일 (기준: 중간 규모 단일 SPA 또는 jQuery 위주의 레거시 웹사이트 기준)

주요 고려사항

1. jQuery Migrate 플러그인 도입

jquery-migrate-3.4.1.js를 먼저 삽입하여 deprecated 기능을 경고로 확인
콘솔 로그에서 호환성 경고를 통해 수정 대상 API 파악 가능

2. 대체 API 매핑

제거된 기능대체 방법

.size()	.length
.bind() / .unbind()	.on() / .off()
.live()	.on() (동적 요소에 대한 이벤트 바인딩 시 주의)
.toggle() (2개 이상의 함수 인자)	커스텀 함수로 대체 필요

3. jQuery 플러그인 호환성

사용하는 타사 플러그인이 jQuery 3.x와 호환되는지 확인
오래된 플러그인은 최신 버전이나 다른 대안으로 교체 필요

팁

가능한 경우 jQuery 제거를 고려해도 좋습니다 (예: Vue, React, vanilla JS 대체).
다수의 페이지에 공통으로 로딩되는 경우, 점진적 전환(모듈 단위)보다는 전면 교체가 효율적일 수 있습니다.
레거시 시스템에서는 jQuery 1.x 코드 스타일이 많이 섞여 있어 예상보다 수정량이 많을 수 있습니다.