1. 리트리버 기본 개념

동작 흐름

사용자 질문 → Retriever → 관련 문서 → LLM → 답변 생성

핵심 역할

• 질문을 임베딩(벡터)으로 변환
• 벡터 스토어(FAISS, Chroma 등)에서 유사 문서 검색
• 검색 결과를 LLM에 전달

2. 리트리버의 유형

희소 리트리버 (Sparse) : 단어 기반, TF-IDF, BM25, 빠르고 직관적, 동의어 인식 약함

밀집 리트리버 (Dense)
: 의미 기반, DPR, SBERT, OpenAI Embedding, 의미 유사 문장 검색 가능

혼합형 (Hybrid)
: 두 방식을 결합, EnsembleRetriever, 키워드 + 의미 결합 검색

3.LangChain 리트리버 설정

retriever = vectorstore.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 5, "lambda_mult": 0.5}
)

search_type: 검색 전략 (similarity, mmr 등) search_kwargs: 검색 세부 설정 (k, threshold, 다양성 등) ConfigurableField: invoke 실행 시점에 동적으로 검색 전략 변경 가능

4. 문서 압축기 (Document Compressor)

검색된 문서를 요약하거나 필터링하여 LLM이 처리하기 쉽게 만드는 중간 필터입니다.

LLM 요약형 (LLMChainExtractor) : 질문 중심으로 요약

점수 기반 필터형 (ScoreThresholdDocumentCompressor) : 유사도 기준 문서 필터링

길이 제한형 (TokenClippingCompressor) : 토큰 수 초과 문서 자르기

혼합형 (DocumentCompressorPipeline) : 여러 압축기 조합

장점: 토큰 절감, 품질 향상 주의: 과도한 요약은 정보 손실 위험

5. 앙상블 리트리버 (Ensemble Retriever)

여러 리트리버를 조합해 각자의 장점을 살리는 방식입니다. 예: BM25(희소) + FAISS(밀집)

from langchain.retrievers import EnsembleRetriever

ensemble = EnsembleRetriever(
    retrievers=[bm25_retriever, faiss_retriever],
    weights=[0.4, 0.6]
)

결과는 정규화 후 가중 평균으로 결합 장점: 정확도 향상, 다양성 확보 단점: 속도와 비용 증가

6. 긴 문맥 재정렬 (Long Context Reordering)

검색된 문서들을 LLM이 이해하기 좋은 순서로 재배치합니다. 문맥, 시간, 중요도 기반으로 순서를 조정합니다.

유사도 재랭킹 : Cross-Encoder 등으로 점수 재계산 (ColBERT, MiniLM)

질문 중심 재배열 : 쿼리와 문서 연관성 재평가 (OpenAI, ReRank API)

LLM 기반 재정렬 : LLM이 직접 읽기 순서 판단 (LongContextReorderer)

LangChain에서는 transform_documents() 대신 compress_documents() 방식으로 통합되었습니다.

7. 부모 문서 리트리버 (Parent Document Retriever)

검색은 청크 단위로, 반환은 부모 문서 단위로 수행합니다.

구조

부모 문서 → Chunk 분할 → VectorStore 저장
검색 → 관련 Chunk 찾기 → 부모 문서 전체 반환

장점: 문맥 유지, 세부정보 보존 단점: 메모리 사용량 증가, 토큰 비용 증가

8. 다중 쿼리 리트리버 (Multi-Query Retriever)

사용자 질문을 여러 의미적 쿼리로 확장해 검색 범위를 넓히는 방식입니다.

예시: “Kafka offset 관리 방법?” → “Kafka consumer commit”, “offset 저장 위치”, “auto.commit 설정” 등으로 변환

장점: 표현 다양성 확보, Recall 향상 단점: LLM 호출 비용 증가

9. 다중 벡터 스토어 리트리버 (Multi-Vector Retriever)

하나의 문서를 여러 임베딩(원문, 요약, 제목 등)으로 저장하고 다양한 관점에서 검색 결과를 병합합니다.

작은 청크 방식 : 문서를 작은 단위로 임베딩

요약 임베딩 방식 : 문서의 요약을 임베딩

가설 쿼리(HyDE) : 질문의 가상 답변을 임베딩 후 검색

장점: 검색 정확도 향상 단점: 리소스 사용량 증가

결론

Sparse / Dense
기본 검색
속도 vs 의미

Hybrid / Ensemble
품질 향상
키워드 + 의미 결합

Parent / Multi-Query
문맥 강화
더 풍부한 정보

Multi-Vector / Compressor
효율화 중복 제거 · 요약

Reorderer
논리적 흐름 개선
LLM 최적화

요약

리트리버는 RAG 시스템에서 “검색의 품질”을 결정하는 핵심입니다. 하나의 리트리버로는 충분하지 않으며, 데이터 특성에 따라 여러 리트리버를 조합·압축·재정렬하는 것이 고품질 검색형 AI를 만드는 핵심 전략입니다.

React + Spring Boot + RDS → 미니 PC 홈서버

CI/CD, Nginx, HTTPS, DNS까지 직접 옮기며 겪은 시행착오와 설계 정리

1. 왜 홈서버로 이전했나

기존 서비스는 AWS 기반으로 구성되어 있었다.

• Frontend: React
• Backend: Spring Boot
• DB: RDS
• CI/CD: GitHub Actions

구성 자체는 안정적이었지만, 개인 프로젝트를 운영하기엔 비용과 복잡도가 점점 부담이 됐다.

그래서 목표를 이렇게 잡았다.

• 클라우드 의존도 최소화
• 운영은 최대한 단순하게
• 비용은 거의 0에 가깝게
• 그래도 실서비스 수준의 구조는 유지

결론은 미니 PC 홈서버로 이전이었다.

2. 전체 목표 아키텍처

이전 후의 목표 구조는 아래와 같았다.

• 미니 PC 1대
• Nginx (Reverse Proxy)
• React 정적 빌드 서빙
• Spring Boot 백엔드 (systemd)
• GitHub Actions self-hosted runner
• HTTPS (Let’s Encrypt)

핵심은 “한 대지만, 운영 서버처럼 쓰자”였다.

3. 디렉터리 구조 설계

여러 프로젝트를 올릴 것을 고려해 루트 디렉터리부터 명확히 설계했다.

/dadamda
 ├─ _shared
 │   └─ nginx
 │       └─ conf.d
 │
 └─ dadamda-web
     ├─ frontend
     │   └─ build
     └─ backend
         └─ app.jar

• /dadamda : 조직/서비스 루트
• _shared : 여러 프로젝트 공통 자원
• 프로젝트 단위로 완전히 분리

이 구조 덕분에:

• 배포 경로 고정
• CI/CD 단순화
• 나중에 프로젝트 추가도 쉬워졌다.

4. Nginx 설정과 프록시 구조

Nginx는 두 가지 역할만 하도록 제한했다.

1. React 정적 파일 서빙
2. /api 요청을 Spring Boot로 프록시

location / {
    try_files $uri /index.html;
}

location /api/ {
    proxy_pass http://127.0.0.1:8080/;
}

프론트와 백엔드를 하나의 도메인으로 묶으면서도, CORS나 인증 문제 없이 깔끔하게 동작했다.

5. Spring Boot 실행 방식

백엔드는 Docker 대신 systemd 서비스로 올렸다.

[Service]
User=godhkekf24
WorkingDirectory=/dadamda/dadamda-web/backend
ExecStart=/usr/bin/java -jar app.jar
Restart=always

이 방식을 선택한 이유는 단순하다.

• 빠르게 이전 및 검증
• 재부팅 시 자동 실행
• 로그는 journald로 관리
• 장애 시 자동 재시작

홈서버에서는 단순함이 곧 안정성이었다.

6. CI/CD 재구성

아직 작업하진 못했지만 기존 GitHub Actions를 그대로 유지하되, self-hosted runner를 미니 PC에 설치하려고 한다.

이 선택의 장점은 명확했다.

• GitHub Actions 비용 0원
• 빌드/배포 모두 로컬 자원 사용
• 외부 포트 오픈 불필요 (outbound only)

결과적으로 Jenkins 없이도 충분히 강력한 파이프라인을 만들 수 있을 것이다.

7. DNS: 가장 많이 막혔던 부분

이 구간이 이번 이전 작업에서 가장 시간을 많이 잡아먹은 부분이었다.

처음에는 단순히 DNS 전파 시간 문제라고 생각했다.

• A 레코드는 정상적으로 추가했고
• TTL도 낮게 설정했고
• 포트포워딩과 Nginx도 모두 준비된 상태였다.

그런데 몇 시간이 지나도, 하루가 지나도 DNS가 잡히지 않았다.

nslookup dadamda.site

결과는 계속 NXDOMAIN.

문제의 진짜 원인: DNS 권한(Authoritative) 불일치

원인은 "시간"이 아니라 "권한" 문제였다.

도메인의 네임서버(NS)는 이미 AWS Route53로 위임된 상태였는데, 실제 A 레코드 설정은 가비아 DNS 관리 화면에서 하고 있었던 것이다.

즉 구조는 이랬다.

도메인 등록: 가비아
네임서버(NS): Route53
DNS 레코드 설정: 가비아 ❌

DNS 동작 원리를 기준으로 보면 이건 명확한 오류다.

네임서버가 Route53를 가리키고 있으면, DNS 레코드는 반드시 Route53 Hosted Zone에 존재해야 한다.

가비아에서 아무리 A 레코드를 추가해도, 전 세계 DNS 서버는 Route53에 질의하기 때문에 결과는 계속 "존재하지 않는 도메인"이 된다.

그래서 왜 하루가 지나도 안 됐나

이 상황에서는:

• DNS 전파를 아무리 기다려도 ❌
• TTL을 줄여도 ❌
• 포트포워딩을 다시 해도 ❌

절대 해결되지 않는다.

왜냐하면 DNS는 "기다리면 퍼지는 값"이 아니라, "권한 있는 서버에 존재해야만 조회되는 값" 이기 때문이다.

해결 방법

해결은 두 가지 중 하나였다.

1. 네임서버를 가비아 DNS로 되돌리거나
2. Route53에 Hosted Zone을 생성하고 A / CNAME 레코드를 Route53에서 직접 관리

나는 두 번째 방법을 선택했다.

• Route53 Public Hosted Zone 생성
• dadamda.site에 대한 A 레코드 추가
• 네임서버는 그대로 유지

그 순간부터:

nslookup dadamda.site 8.8.8.8

에서 즉시 IP가 반환되었고, Let’s Encrypt 인증서도 문제없이 발급됐다.

이 경험에서 얻은 교훈

DNS 문제의 절반은 "설정"이고, 나머지 절반은 "어디가 권한을 가지고 있는지"다.

"기다리면 된다"는 말은 권한이 올바를 때만 성립한다.

DNS가 안 잡힐 때는 항상 먼저 이 질문을 해야 한다.

• 지금 이 도메인의 authoritative DNS는 누구인가?
• 내가 레코드를 추가한 곳이, 정말 그 서버인가?

8. 공유기 포트포워딩과 관리자 페이지 이슈

80/443 포트포워딩을 설정한 뒤, 공인 IP로 접속하니 공유기 페이지 대신 서비스 화면이 나왔다.

처음엔 당황했지만, 이는 정상적인 동작이었다.

• 외부 요청은 미니 PC로 전달
• 공유기 관리자 페이지는 내부 IP + 별도 포트

오히려 보안적으로 더 안전한 상태였다.

9. 결과: 지금의 상태

현재 상태는 다음과 같다.

• 미니 PC 홈서버 운영 중
• React + Spring Boot 정상 서비스
• HTTPS 적용 완료

해야하는 작업

• CI/CD 자동 배포
• DB 이전

무엇보다 구조를 전부 이해하고 운영한다는 안정감이 가장 큰 수확이었다.

10. 마치며

이번 이전 작업은 단순한 서버 이동이 아니라,

• 네트워크
• DNS
• Linux
• 배포
• 운영

을 한 번에 복습하는 경험이었다.

클라우드가 편한 건 사실이지만, 직접 굴려본 홈서버 경험은 다른 차원의 이해를 준다.

비슷한 고민을 하고 있다면, 작은 프로젝트 하나라도 홈서버로 옮겨보는 걸 추천한다.

다음 글에서는

• CI/CD 자동 배포

• DB 이전

  도 정리해볼 예정이다.

넘어온 프로젝트의 웹 백엔드 부분을 담당하고 있는데 작업 관련 문서가 너무 없다. 코드 기반으로 AI를 통해 문서를 생성해서 전체 로직을 파악하고 문제가 되는 부분들의 코드를 집중적으로 확인하는 식으로 진행하고 있는데 코드의 의도가 명확하지 않은 부분들이 많다. 그리고 사실 단순한 기능인데 메서드의 깊이가 너무 깊다. 마지막으로 AI로 생성된 로직들에 대한 검증이 부족하다. 잘 만들어진 문서를 기반으로 생성된 코드는 꽤나 깔끔하다고 생각한다. 하지만 전체적인 설계 없이 특정 기능을 구현하기 위해서만 생성된 코드는 상당히 난해하고 의미를 파악하기 힘들어진다.

개발 처음 배울 때, '좋은 코드는 무엇인가'에 대한 고민을 했었는데 항상 결론짓지 못하였다. 하지만 좋지 않은 코드를 경험적으로 쌓아가면서 이것들을 회피하며 전체적으로 좋은 코드로 향해가고 있는 것 같다.

여러 잡생각들이 드는 한 주였지만 일단 눈 앞에 주어진 프로젝트가 있으니 모든 에너지를 해당 업무를 완수하는데에 집중하겠다.

연말에 잠시 중단되었던 RAG 스터디를 재개했다. 스터디원의 개인 프로젝트 발표 일정이 진행되었고, n8n을 이용해 급등주를 찾는 서비스를 구현해 설명해주셨다. 새로 알게 된 부분이 있었는데 주가 데이터를 그대로 llm에 전달하는 것이 아닌 주가 데이터를 이미지로 생성해서 llm에 전달하는 것이 더 높은 수준의 답변을 얻을 수 있다는 것이다. 이미지보다 데이터 자체가 더 정확하기 때문에 좋은 답변을 얻을 수 있다고 생각했는고 LLM에 해당 질문을 요청 했을 때에도 주가 예측, 추론에는 데이터가 더 유리하다고 하는데 이 부분에 대해서는 추가적인 학습과 경험이 더 필요하다.

26년 목표를 위해 어떤 행동들을 진행하고 있는지 주간 점검을 진행해보자.

2026년 목표

1. 알고리즘 학습
2. 개인 블로그 구축
3. 월급 외 수익 만들기
4. SAA, CKA
5. 회사 서비스 모니터링 시스템 구축 및 고도화

아무것도 진행하고 있는 것이 없다. 다음 주에는 회사 업무를 최대한 업무 시간에 정리해두고 알고리즘 학습과, SAA 학습을 진행해보려고 한다. 알고리즘은 문제를 보고 어떤 식으로 풀어야 할지 설계를 진행하고 LLM에 문제풀이를 요청해 여러 알고리즘을 빠르고 많이 접할 수 있도록 하려고 한다. SAA 학습은 이전에 봤던 블로그 문제풀이를 적극 활용하려고 한다.

짧은 시간이라도 업무 외에 개인 학습을 진행해야겠다고 생각이 들었다. 업무 시간 내에 최대한 많은 업무들을 진행하고 그 외에는 운동과 목표를 위한 학습을 꾸준히 진행해보자.

개발블로그에 무슨 소리인가 싶기도 하겠지만 그만큼 2025년은 운동에 몰입했던 해였다. 나는 고등학교 이후에 군대를 제외하면 운동을 전혀 하지않고 있었다. 방심한 순간에 말랐던 몸에 살이 붙기 시작했고 통통하다는 느낌까지 받게 되었다.

2024년 말에 친구의 조언에 러닝을 시작했고 재미를 붙여 하프 대회까지 나갔고 2026년에는 풀 마라톤까지 신청해놨다. 상반기에는 수영을 했고 하반기에는 웨이트를 했기 때문에 거의 쉬는 시간 전부를 운동에 투자했다고 봐도 무방하다. 운동을 하긴 해야지라고 생각하고 계속해서 미뤄왔기 때문에 이렇게 운동하는 것을 습관화 한 것 자체만으로도 올해 의미있게 보냈다고 생각을 한다.

개발적인 성장으로는 올해 여러 개발 모임들을 진행하면서 다양한 사람들을 만나고 동기부여를 얻은 해이다. 사실 기존에도 여러 모임에 속해있었는데 올해 특히 활발하게 세미나에 참여하고 스터디를 진행했다. 오산 개발자 방에서 카프카 스터디와 RAG 스터디를 진행하면서 각각 기술에 대한 개념 뿐만 아니라 관련된 컴퓨터 지식들을 서로 공유했다. 생소한 개념이 나올때마다 LLM을 활용해 개념을 확장하는 작업을 꾸준히 진행하였고 일부는 실습을 진행하면서 익숙해지려고 노력했다. 최근에 진행한 RAID개념 같은 경우가 그렇다.

추상화 되어있는 기능들을 잘 활용하는 것도 중요하겠지만 실제로 어떻게 동작하는지 인지하고 사용하는 것과 아닌 것과는 차이가 있다. 특히나 최근 AI를 활용한 개발이 늘어나면서 단순히 사용하거나 결과를 만들어 내는 것은 허들이 상당히 낮아졌다고 생각한다. 하지만 트래픽이 증가하거나 특정 이슈가 생겼을 때 원인을 분석해내는 능력은 추상화된 기술의 장단점을 아는 것으로는 부족하고 실제로 동작 과정을 인지하고 있는데에서 온다고 생각한다. 따라서 앞으로도 주요 기술들에 대한 학습을 진행하면서도 내부 동작에 집중해보려고 한다.

2026년 목표

1. 알고리즘 학습
2. 개인 블로그 구축
3. 월급 외 수익 만들기
4. SAA, CKA
5. 회사 서비스 모니터링 시스템 구축 및 고도화

먼저 알고리즘 학습이다. 구현보다는 알고리즘의 종류와 사용처 위주로 학습할 예정이고 실제 구현은 AI에 맡길 것이다. 단순 구현은 이제 AI가 더 꼼꼼하게 잘한다. 알고리즘 문제 상황별로 어떤 알고리즘을 사용하고 제한 조건을 어떤 방식으로 해결해나갈 것인지만 학습하여 짧은 시간 여러 케이스들을 다룰 것이다.

개인 블로그 구축은 하반기에 진행할 예정이다. 티스토리에서 현재 Velog를 이용하고 있지만 원하는 기능이 많지 않아 직접 수정할 수 있는 개인 블로그를 만들어 볼 생각이다.

3, 4, 5에 대한 내용은 구체적으로 언급하기 어렵다. SAA는 곧 응시 예정이고 CKA는 하반기를 목표로 공부하려고 한다. 회사 시스템을 언급하기 어려운데 부족하다고 생각하고 있고 효율적인 방식으로 변경한 뒤에 개선점을 블로그에 작성하려고 한다.

올 한해 업무를 많이 진행한 것 같은데 되돌아보면 기억이 잘 나지 않는다. 2026년 부터는 주간 회고를 통해 현재 위치를 꾸준히 확인하고 목표를 향해 정진하는 해를 만들어보려고 한다. 주간 회고는 매주 토요일 오전에 작성하려고 한다. 2026년 회고 글에는 더 풍성한 내용들이 들어있기를 기원한다.

RAID0 / RAID1 / RAID5 / RAID10 전체 성능 비교 분석

실험 환경

• HDD 4개 (SATA)
• Ubuntu(persistent live USB) + mdadm
• fio 벤치마크

테스트 종류:

• 순차 읽기 (1MB)
• 순차 쓰기 (1MB)
• 랜덤 읽기 (4K)
• 랜덤 쓰기 (4K)

순차 읽기 (Sequential Read) — 1MB block

데이터를 앞에서부터 뒤까지 순서대로 연속해서 읽는 작업이다. 디스크 헤드(특히 HDD)가 이동할 필요 없이 연속된 영역을 읽기 때문에 가장 빠른 성능이 나온다.

0MB → 1MB → 2MB → 3MB → …

케이스 정리

• 대용량 파일 읽기
• 영상 스트리밍
• 백업 데이터 읽기
• 로그 파일 연속 스캔
• OS 부팅 중 연속 파일 로딩

순차 쓰기 (Sequential Write) — 1MB block

데이터를 앞에서부터 뒤까지 연속된 공간에 순서대로 기록하는 작업이다.
순차 읽기와 마찬가지로 디스크 헤드가 크게 이동하지 않아 HDD에서도 높은 쓰기 성능을 낼 수 있다.

0MB ← 1MB ← 2MB ← 3MB ← …

다만 RAID 구조에 따라 쓰기 성능 차이가 크게 난다.
특히 RAID5는 패리티 계산 때문에 순차 쓰기가 매우 느릴 수 있다.

케이스 정리

• 대용량 로그 파일 기록
• 백업 파일 저장
• 영상 녹화(스트리밍 업로드)
• 대규모 ETL 파이프라인 쓰기
• 장기 보관용 아카이브 파일 생성

랜덤 읽기 (Random Read) — 4KB block

데이터를 임의(random) 위치에서 작은 단위(4KB) 로 읽는 작업이다.
HDD에서는 디스크 헤드가 다양한 위치로 이동해야 하기에 가장 느린 접근 패턴이다.

200MB → 12GB → 5MB → 340KB → …

랜덤 읽기는 OS와 데이터베이스에서 가장 자주 발생하며, RAID 구조에 따라 성능 차이가 크게 난다.
HDD 기반에서는 여러 디스크에 분산된 데이터를 병렬로 읽을 수 있는 RAID5가 상대적으로 이점이 있을 수 있다.

케이스 정리

• 데이터베이스 SELECT 쿼리
• 파일 시스템 메타데이터 읽기
• 작은 파일 다수 읽기
• 캐시 미스 발생 시 OS 페이지 읽기
• VM(가상머신) 스토리지 읽기

랜덤 쓰기 (Random Write) — 4KB block

임의의 위치에 작은 블록(4KB) 을 기록하는 작업이다.
디스크 헤드 이동 + RAID 패리티/미러 구조 때문에 RAID 종류에 따라 성능 차이가 매우 큰 영역이다.

3GB 위치 ← 450MB 위치 ← 12KB 위치 ← 77GB 위치 …

특히 RAID5는 패리티 연산으로 인해 랜덤 쓰기가 매우 느리고,
RAID10은 미러 구조 + 스트라이핑 덕분에 랜덤 쓰기 성능이 가장 뛰어나다.

케이스 정리

• 데이터베이스 INSERT / UPDATE
• 애플리케이션 로그 기록
• VM 디스크 이미지 랜덤 기록
• 파일 시스템 메타데이터 업데이트
• 캐시 파일 저장

📌 성능 요약표 (4가지 RAID 모두 포함)

1) 순차 읽기 성능 비교 (1MB)

1위: RAID0 (191 MiB/s) 최고 속도 스트라이핑 효과로 4개 디스크를 모두 활용

2위: RAID10 (189 MiB/s) RAID0와 거의 동일 2×2 미러이지만 스트라이핑으로 높은 대역폭

3위: RAID5 (144 MiB/s)
패리티 불필요한 읽기는 빠름

4위: RAID1 (26.6 MiB/s)
단일 디스크 수준

📌 해석 순차 읽기는 디스크 헤드가 한 방향으로 쭉 움직이기 때문에, 스트라이핑 구조(RAID0, RAID10)가 절대적으로 유리하다.

📌 의문점 Q. RAID0(4-striping)은 RAID10(2-striping + 2-mirroring)보다 대역폭이 2배 더 높으니까 그만큼의 성능을 보여줘야 하는 것 아닌가? A. 순차 I/O 병목은 디스크의 최대 처리량(SATA 인터페이스 병목)에 걸려 있기 때문에 실제 순차 I/O는 디스크 개수만큼 선형 증가하지 않는다. 디스크 2~3개만 써도 이미 최대 대역폭 근접한다. 만약 SSD를 사용하게 된다면 처리량 차이를 볼 수 있다.

2) 순차 쓰기 성능 비교 (1MB)

1위: RAID0 (185 MiB/s)
패리티 없음, 미러 없음 → 순수 스트라이핑

2위: RAID10 (182 MiB/s)
미러 쓰기 + 스트라이프 → RAID5보다 훨씬 유리

3위: RAID1 (67.6 MiB/s)
2개 디스크에 동일 데이터 기록

4위: RAID5 (13.1 MiB/s)
패리티 계산 병목 때문에 최악

📌 해석 RAID5는 쓰기 시 “패리티 연산 + 읽기 후 쓰기(read-modify-write)” 작업이 필요해 속도가 HDD 환경에서는 가장 낮게 나온다.

3) 랜덤 읽기 성능 비교 (4K)

1위: RAID5 (1864 IOPS) HDD 기준에서는 읽기가 매우 빠름 (패리티 필요 없음)

RAID10 (132 IOPS)
pair 당 1디스크 읽기 → HDD에서는 RAID5에 밀릴 수 있음

RAID0 (131 IOPS)
스트라이프이지만 헤드 seek 병목 동일

RAID1 (13 IOPS)
단일 디스크 수준

📌 해석 랜덤 읽기에서는 헤드가 여러 디스크에서 동시에 seek 할 수 있는 RAID5가 압도적이다. 패리티 연산이 필요 없는 read path이기 때문.

📌 의문점 Q. RAID5 값이 너무 높은 수치가 아닌가? 사실 RAID 0과 비슷할 것이라고 생각했다. W. 실제로는 RAID0 수치와 비슷해질수는 있지만 이렇게 압도적으로 높은 수치가 나오는 것은 이상수치이다. 테스트시에 direct 옵션을 주지 않아 캐시가 개입하여 더 높은 수치가 나오는 것으로 추측하고 있다.

4) 랜덤 쓰기 성능 비교 (4K)

1위: RAID10 (455 IOPS)
병렬 쓰기 효과 + 패리티 없음

2위: RAID0 (453 IOPS)
패리티 없음 → 순수 스트라이핑

RAID5 (94 IOPS)
패리티 연산 때문에 낮은 편

RAID1 (45 IOPS)
미러 쓰기 때문에 디스크 head 움직임 증가

📌 해석 RAID10과 RAID0은 랜덤 쓰기에서도 압도적인 성능을 보인다. 특히 RAID10은 내구성 + 빠른 랜덤 쓰기를 동시에 갖는다는 점에서 DB, 트랜잭션 처리에 가장 적합하다.

결론

• RAID0는 가장 빠르지만 가장 위험하다.
• RAID5는 쓰기 병목이 크다.
• RAID1은 안정성 중심이다.
• RAID10이 전체적인 밸런스(성능+안정성) 측면에서 가장 우수하다.

그 얘기를 들으면서 문득, “레이드… 아, 저장소 디스크를 여러 개 묶어서 관리하는 그거!” 라고만 알고 있었지, 정작 각 RAID 방식이 어떤 원리로 동작하는지는 명확하게 이해하지 못하고 있었다는 걸 깨달았다.

그래서 오늘은 RAID 개념을 처음부터 다시 공부했고, 앞으로는 직접 RAID를 구성해보면서 각 방식이 제공하는 성능·안정성의 차이를 실제로 체감하며 정리해보려고 한다.

1. RAID(Redundant Array of Independent Disks)란?

RAID는 여러 개의 디스크 드라이브를 배열(Array) 형태로 묶어 스트라이핑(striping) 또는 미러링(mirroring) 방식으로 데이터를 운영하는 저장장치 구성 기술이다.

이를 통해 다음과 같은 이점이 있다:

• 성능 향상
• 장애 허용 능력(오류 내성) 향상
• 더 많은 저장 용량 확보
• 비용 효율적인 스토리지 구성

RAID는 서버나 스토리지 시스템에서 안정성과 성능을 높이기 위한 대표적 기술로 널리 사용된다.

2. RAID에서 사용되는 운영 방식

RAID는 크게 두 가지 기본 동작 방식을 조합하여 구성된다.

1. 스트라이핑(Striping)

데이터를 여러 블록으로 나누고 그 블록들을 여러 드라이브에 분산 저장하는 방식 성능 향상 목적 (읽기/쓰기 속도 증가)

2. 미러링(Mirroring)

동일한 데이터를 두 개 이상의 디스크에 복제하여 저장 장애 대응 목적

RAID는 위 두 방법을 어떻게 조합하느냐에 따라 서로 다른 RAID 레벨로 구분된다.

1) RAID 0

2개 이상의 디스크에 데이터를 번갈아 저장하여 최고의 성능을 낼 수 있다.

패리티가 없어 디스크 1개라도 고장나면 데이터 손실이 발생한다. 데이터를 여러 디스크에 저장하기 때문에 하나의 디스크라도 고장이 나면 프로그램을 실행할 수 없다.

SSD 캐시 등 속도만 필요한 경우에 제한적으로 사용한다.

2) RAID 1

동일한 데이터의 완전한 복제본을 저장하여 디스크 1개 고장 시에도 데이터 손실이 없다.

용량은 가장 작은 디스크 용량 기준으로 제한된다. 데이터를 두 번 써야 하므로 쓰기 성능은 RAID0보다 떨어진다. 비용이 높지만 안정성이 높다.

3) RAID 5

스트라이핑 + 패리티 1개 3개 이상의 디스크가 필요하다. 패리티는 항상 데이터가 있는 디스크와는 다른 디스크에 저장된다.

디스크 1개 고장 시 패리티 기반으로 데이터 복구 가능하다. 읽기 성능은 높고 용량 효율도 좋다. 하지만 쓰기 속도가 느리고 디스크 재구성(Rebuild) 시간이 길다.

패리티란? 패리티는 여러 데이터 조각을 XOR 연산으로 더해 놓은 값이다. 이 패리티만 있으면 디스크 1개가 고장 나도 그 데이터를 다시 만들어 낼 수 있다.

패리티 예시

RAID5 (3개의 디스크) Disk1: 데이터 A1 A2 A3 Disk2: 데이터 B1 B2 B3 Disk3: 패리티 P1 P2 P3 (A1+B1, A2+B2 … XOR)

Disk2가 고장 나면: B1 = A1 XOR P1 B2 = A2 XOR P2 B3 = A3 XOR P3

→ 계산으로 B를 다시 만들어서 RAID가 살아남음.

만약 패리티를 2개 만들어 놓으면 디스크가 2개가 고장나도 복구할 수 있다. (RAID 6) P 패리티: XOR 연산 사용 Q 패리티: 갈루아 필드(GF(2^8)) 연산 사용

쉽게 얘기하면 2개의 변수가 있는 문제는 2개의 방정식으로 풀 수 있는 원리와 같다.

리빌드(Rebuild)란? RAID 구성에서 고장난 디스크를 새 디스크로 교체한 후, 실종된 데이터를 다시 ‘재생성’해서 RAID를 정상 상태로 회복시키는 과정.

디스크가 하나 고장나면 RAID가 degraded(경고 상태)가 된다. 새 디스크를 꽂으면 RAID가 남은 디스크와 패리티 정보를 이용해 사라진 데이터를 다시 계산해서 새 디스크에 채워 넣는 작업을 진행하는데 이 과정을 “리빌드”라고 한다.

4) RAID 10 (1+0)

RAID 1(미러링) + RAID 0(스트라이핑) 결합하여 최소 4개의 디스크 필요하다. 짝수 개의 디스크만 추가 가능하다.

1단계: 디스크를 미러 쌍으로 구성 2단계: 각 미러링 쌍을 스트라이핑하여 논리 볼륨 생성

쓰기 성능이 매우 뛰어나며, 높은 안정성과 성능을 동시에 확보할 수 있다. 용량의 50%만 사용할 수 있어 비용이 높다.

3. RAID 사용 방법

RAID는 운영 방식에 따라 소프트웨어 RAID와 하드웨어 RAID 두 가지로 나뉜다.

소프트웨어 RAID 운영체제(OS)가 CPU를 사용하여 RAID를 관리한다.

리눅스는 RAID0, 1, 5, 6 등 대부분을 지원 윈도우도 RAID0, 1, 5 일부 지원

예: mdadm 기반 RAID 구성 → 일반 PC에서도 바로 구성 가능

하드웨어 RAID RAID를 지원하는 HBA(Host Bus Adapter) 카드나 RAID 컨트롤러가 관리한다. RoC(RAID on Chip) 기반으로 CPU 부하가 적다. RAID 레벨 지원 범위는 각 카드 사양에 따라 다르다.

서버/스토리지 전문 환경에서 주로 사용

RAID별 특성 정리

※ RAID는 백업의 대체제가 아니다는 점을 항상 명심해야 한다.

(출처: 삼성전자 데이터센터 Samsung_SSD_845DC_07_Redundant_Array_of_Independent_Disks_RAID.pdf)

보통 학습을 진행해도 실습을 진행해보지 않으면 금방 잊혀진다. 따라서 HDD 4대를 직접 데스크탑에 레이드 연결해보고 각각의 레이드 환경에 따라 성능과 리빌드 과정을 확인하는 작업을 진행하려고 한다. SATA HDD 4대를 주문해놨고 도착하면 차례로 실습한 후에 실습 결과를 포스팅하겠다.

앞으로 진행할 실습 계획

RAID0 구성 → 성능 측정 RAID1 구성 → 안정성 테스트 RAID5 구성 → 디스크 고장 시나리오 실험 RAID6 구성 → 2개 고장 대응 확인 RAID10 구성 → 미러링 + 스트라이핑 성능 비교 Hot Spare 구성 → 자동 복구 동작 확인

• fio로 성능 측정
• SMART로 디스크 상태 확인

마무리

단순히 일 때문에 참석했던 행사였지만, 오히려 개발과 관련된 새로운 키워드들을 얻게 되었고, 그 과정에서 다시 호기심이 살아나는 계기가 되었다. 다양한 개발자들을 만나 이야기 나누면서 기술뿐 아니라 사람과 경험을 통해 성장할 수 있음을 다시 느꼈다.

특히 RAID라는 주제를 접하게 되면서, 평소 깊게 다루지 않았던 스토리지 구조나 데이터 보호 방식에 대해 스스로 공부해보는 기회까지 이어졌다. 단순히 “디스크 여러 개 묶는 기술” 정도로 알던 RAID가, 성능, 안정성, 데이터 구조까지 연결된 깊이 있는 개념이라는 걸 배우면서 개발자로서 시야가 더 넓어진 느낌이다.

앞으로도 이렇게 예상치 못한 곳에서 새로운 지식을 얻고, 커뮤니티 활동을 통해 성장하는 경험을 계속 이어가고 싶다. 작은 호기심 하나가 또 어떤 배움을 만들어낼지 기대된다.

마라톤 신청 알람 서비스

먼저 주기적으로 마라톤 정보를 가져오는 크롤링 워크플로우 1개, 매일 아침 마라톤 참여 시작일을 판단하여 문자 또는 이메일을 날려주는 워크플로우 1개가 필요하다.

처음에는 일일이 마라톤 일정을 입력해 넣으려고 했지만 세상에는 생각보다 더 많은 마라톤 일정들이 존재했고 1인이 모두 관리하기에는 어려웠기 때문에 기존에 마라톤 일정을 제공하는 사이트를 크롤링해서 DB를 구성하기로 했다.

마라톤GO 라는 웹 사이트는 마라톤 일정을 등록 신청을 하고 검증을 통해 데이터로 밀어넣는 것 같아 꽤나 신뢰성 높은 사이트라고 판단했고, 해당 사이트에서 일정을 가져오기로 했다.

크롤링 워크 플로우

마라톤 일정이 자주 바뀌는 것도 아니고 해당 사이트에 부하를 자주 줄 필요도 없다고 생각하여 일주일에 한번 트리거할 수 있도록 설정했다. (요청 URL이 계속 변경되는 것 같은데 한 달에 한번정도 확인해서 URL 변경 후 직접 트리거 하는 방식으로 진행해도 좋을 것 같다.) 그리고 HTTP request 노드에서 응답을 받아오고 응답을 파싱하여 마라톤 일정 객체 리스트로 만들어주는 함수 노드를 두었다.

그 다음으로 만들어진 객체 리스트를 구글 시트에 넣는 노드로 마라톤 일정 DB 저장을 마무리했다. 다음 번에 자동 트리거 할 때 기존의 데이터와 중복된 데이터가 들어가는 것을 방지하기 위해 raceName을 unique값으로 지정했다.

최종적으로 크롤링으로 만들어진 마라톤 일정 DB 리스트 구글 시트는 다음과 같다. 554개의 마라톤 일정을 가져왔다.

이제 매일 아침 8시에 확인하여 당일 접수가 시작되는 마라톤을 추려 구독자에게 보내주는 워크 플로우를 만들어야 한다.

먼저 구독 신청은 구글폼으로 만들었다.

단순히 이메일과 지역 옵션만을 사용하여 신청을 간소화했다. 이제 해당 지역 필터를 적용하여 마라톤 리스트를 가져와 문자로 보내는 2번 워크플로우를 작성해보자.

매일 오전 8시에 자동 트리거하면 구독자와 마라톤 정보를 가져온다. 오늘 접수가 시작될 마라톤 정보만 추려 해당 지역을 구독하고 있는 구독자에게 보낼 이메일을 HTML 코드로 작성했다.

최종적으로 이메일을 보낸 모습은 다음과 같다.

사실 작업을 진행하면서 여러 어려움이 생길 것이라 생각해, 이를 정리하기 위해 블로그 작성을 시작했다. 그런데 막상 n8n을 사용해보니 UI도 직관적이고 지원하는 노드(툴)도 다양해서, 생각보다 훨씬 간단하게 서비스를 만들 수 있었다.

n8n을 몰랐을 때는 마라톤 알림 서비스를 구축하기 위해

• 크롤링을 위한 서비스 하나,
• SMTP 발송용 스프링 서비스 하나,
• Jenkins는 과하니 cron으로 트리거를 처리하는 방식 을 구성해야겠다고 생각했다.

하지만 n8n을 사용해보니 기존처럼 복잡하게 아키텍처를 나눌 필요 없이, 워크플로우 단위로 작은 서비스들을 손쉽게 만들어 연결할 수 있었다. 다양하고 사용자 친화적인 노드들을 활용해 필요한 기능을 조합만 하면 되기 때문에, 전체 개발 비용이 크게 줄어든다는 점이 인상적이었다.

또한 n8n은 여러 워크플로우 템플릿도 제공한다. 웹에서 필요한 템플릿을 찾아 그대로 복사해와 사용할 수 있어, 직접 구성하는 것이 어렵거나 귀찮은 사람들에게 특히 유용하다. 반복적인 업무를 자동화하고 싶은 사람들이라면, 이미 만들어진 템플릿을 활용해 일상의 루틴을 벗어나 더 중요한 작업에 시간을 써보는 것도 좋아보인다.

혹시나 마라톤 알림 서비스를 제공받아 볼 사람들은 다음 링크로 구글폼을 작성해두면 된다. 불가피한 사정으로 서비스가 말 없이 내려갈 수 있으니 감안하길 바란다.

마라톤 접수 알림 서비스 신청폼 (무료) https://forms.gle/gcp9nrsusfPNmc1w8

새로운 기술에 대해 전반적인 지식을 얻기 위해서는 LLM만한 것이 없다.

Q. n8n이 뭐야? 개념과 유스케이스를 포함해서 알려줘.

n8n은 오픈소스 자동화 플랫폼이다. Zapier, Make(구 Integromat) 같은 서비스와 비슷하지만 완전한 오픈소스이고 자체 호스팅이 가능하다는 점이 가장 큰 특징이다.

“코드 없이(또는 최소한의 코드로) 여러 서비스와 API를 연결해서 자동화 시나리오를 만드는 도구”

Zapier, Make같은 친구들을 한 번도 사용해본 적 없지만 n8n이 워낙 편안하고 범용성이 좋다고 하니까 n8n에 먼저 집중해보자.

n8n을 통해 다음과 같은 워크플로우를 최소한의 코드로 동작이 가능하다고 한다.

"메일 오면 → Slack 알림 보내기 → DB에 저장하기"

메일, 슬랙, DB까지? 호환성이 얼마나 좋은거야.

트리거와 노드로 이루어져 있다.

트리거

• Cron 시간마다
• Webhook 호출되면
• Slack 메시지 수신 시
• 파일 업로드되면
• 이메일 수신 시

노드

• HTTP Request
• MySQL
• MongoDB
• Slack
• Telegram
• GitHub
• Cron
• Function (JavaScript 코드 작성 가능)

이메일 수신 시? 최근에 싸피니티 대외협력팀에서 업무를 진행하고 있는데 메일 수신 여부를 확인해서 단톡방에 공유하는 것도 업무이다. 메일이 오면 메일 내용을 AI로 요약해서 카카오톡에 공유해주는 자동화가 가능할까 기대해본다.

추가로 n8n은 k8s처럼 nodemation의 축약어라고 한다.

개념은 간단하다. 실습을 진행해본다. t3.micro ec2 하나를 빌려서 도커를 설치하고 docker-compose.yml를 구성해서 올려봤다.

TLS는 추후에 적용하도록 하고 secure cookie를 사용하지 않도록 하여 진행했다.

아름답다. 오픈소스를 사용하다가 이렇게 UI가 제공되면 마음이 편안해지고 감사한 마음이 든다.

실습 내용은 다음과 같다.

1. 트리거가 될 Email Trigger(IMAP) 노드를 세팅하고,
2. HTML에서 내용을 뽑아내고 (함수),
3. LLM으로 요약하고,
4. 이스케이프 문자 정리하고 (함수),
5. 요약한 결과를 텔레그램 bot으로 메세지를 보낸다.

각각의 노드들을 연결할 때 앱비밀번호(google)나 토큰(telegram), key(llm) 등으로 credential로 추가해두고 연결하는 것을 제외하면 번거로운 작업이 크게 없었다.

node 이름을 통해 원하는 데이터들을 가져와서 다음 노드로 가공된 데이터를 넘긴다.

완성된 워크플로우를 active로 변경하고, 실제로 메일을 보내봤다.

메일을 나에게 보내고 빠른 시간 내에 텔레그램 메세지가 전달됐다.

나름 중요한 부분들을 잘 요약해서 보낸 것 같다. '\-' 처럼 문자열 처리가 잘못된 부분이 있었지만 혼자 사용하기에는 충분했다.

마지막으로 n8n으로 할 수 있는 여러 워크플로우 예제들을 리스팅하고 마무리하겠다.

📌** 1. 이메일 자동화(Email Automation)** ✔ 새 이메일 → AI 요약 → Slack/Telegram 알림 ✔ 이메일 첨부파일 자동 다운로드 → S3 업로드 ✔ 이메일 제목/본문 키워드로 자동 분류 및 라벨링 ✔ 특정 발신자 메일을 구글 시트에 자동 기록 ✔ 매일 아침 “지난 하루간 중요한 이메일 요약” 생성 ✔ Gmail → Notion 프로젝트 페이지로 자동 전송 ✔ 고객 문의 이메일 → 자동 티켓 생성(Jira/Asana 등)

📌 2. Slack / Teams 업무 자동화 ✔ 장애 알람 → Slack 메시지 + 담당자 자동 Mentions ✔ 영업 CRM → Slack 실시간 리드 알림 ✔ 특정 키워드 포함 메시지 감지 → GPT 응답 자동 생성 ✔ 회사 일정 Google Calendar → Slack 주간 알림 ✔ Jenkins/배포 완료 → Slack에 릴리즈 노트 자동 발송

📌 3. 개발자/DevOps 자동화 ✔ GitHub Issue 생성 → 자동 Slack 알림 ✔ GitHub Pull Request → 변경 사항 GPT 요약 ✔ AWS CloudWatch 경보 → Telegram/Slack 알림 ✔ 특정 서버 CPU/RAM 폭주 감지 → 자동 재부팅 ✔ S3에 새로운 로그 생성 → ETL 자동 처리 ✔ DockerHub 새 이미지 태깅 → 자동 배포 트리거

📌 4. 데이터 처리 & ETL 자동화 ✔ 매시간 REST API 데이터 요청 → MongoDB/MySQL 저장 ✔ 웹페이지 크롤링 → 데이터 정제 → 구글 시트 업데이트 ✔ 데이터 CSV 파일 → 자동 파싱 → DB 삽입 ✔ ChatGPT 기반 “데이터 요약/분석” 자동 처리 ✔ PDF → 텍스트 변환 → 핵심 요약 자동 생성 ✔ Notion → ElasticSearch 인덱싱 자동화

📌 5. AI 기반 자동화 (LLM Workflow) ✔ 긴 문서 업로드 → GPT 요약 → Slack 전송 ✔ 고객 리뷰 자동 분류(AI Sentiment Analysis) ✔ 문의 이메일 → GPT 자동 답변 초안 생성 ✔ 정기 리포트 자동 생성(보고서, 회의록, 요약문) ✔ OCR로 이미지에서 텍스트 추출 → GPT 정리 ✔ 블로그 자동 포스팅(AI 글 생성 → Wordpress API 업로드)

📌 6. SNS/마케팅 자동화(Social & Marketing) ✔ RSS/뉴스 자동 수집 → 요약 → 텔레그램 뉴스봇 ✔ 인스타그램 게시물 자동 업로드(사진+문구) ✔ 트위터 Mentions 모니터링 → Slack 알림 ✔ 유튜브 새 영상 업로드 감지 → SNS 자동 공유 ✔ 쇼핑몰 주문/문의 데이터 자동 처리 ✔ 네이버 카페/블로그 업데이트 알림봇

📌 7. 조직/내부 운영 자동화 ✔ 직원 휴가(Annual Leave) 신청 → Slack 승인 플로우 ✔ 구글 캘린더 일정 → 팀별 요약 리포트 ✔ Expense 지출증빙 첨부 → 자동 구글 드라이브 정리 ✔ 주간 회의록 자동 생성(음성 → 텍스트 → 요약) ✔ 매출/현황 데이터 정리 → 매일 아침 요약 리포트 발송

📌 8. 자동 리포트/모니터링 ✔ 매일 매출 요약 → 엑셀 생성 → 이메일 발송 ✔ 재고 수량 임계점 도달 시 → 자동 알림 ✔ 크롤링으로 가격 변동 체크 → 급등락 알림 ✔ 서버 로그 읽고 오류 감지 → 알람 발송 ✔ 회사 포털에서 데이터 스크랩 → 주간 리포트 생성

📌 9. 외부 API 연동(Integration) ✔ 카카오 비즈메시지 자동 전송 ✔ 네이버 톡톡 챗봇 응답 자동화 ✔ CRM/ERP/HR 시스템 간 동기화 ✔ Telegram → ChatGPT → 응답 자동 생성 봇 ✔ GPT로 PDF 분석 → Notion 페이지 자동 생성

📌 10. 개인/일상 자동화 ✔ 메일로 오는 영수증 → 자동 정리/카테고리화 ✔ 운동 기록 자동 정리(Apple Health → Google Sheet) ✔ 집안 IoT 자동화 (모닝루틴: 조명/알림/뉴스) ✔ 환율 변동 알림 ✔ 블로그/포트폴리오 자동 업데이트 ✔ 주식/코인 시세 모니터링 → 급등락 감지

전혀 n8n에 대해 모르는 사람도 금방 워크플로우 하나를 제작할 정도로 매우 간편하고 사용자 친화적인 툴이었다. 추후에 n8n을 이용해 생활이나 개발 환경을 개선해보고 후기를 작성하려고 한다.

최근 상위 저장소의 prod 브랜치와 dev 브랜치가 각각 다른 submodule 커밋을 가리키고 있었는데, 머지하는 순간 submodule 충돌이 발생했습니다. 단순히 git status만 보면 “서브모듈 충돌”이라는 메시지로 끝이라 처음엔 왜 그런지 이해하기 어려웠습니다.

2. submodule이란?

submodule은 Git 저장소 안에 또 다른 Git 저장소를 넣는 기능입니다. 일반 파일 처럼 복사해오는 것이 아니라 특정 커밋 해시를 가리키는 포인터를 저장합니다. 그렇기 때문에 공통 모듈을 여러 프로젝트에서 동일하게 재사용할 수 있습니다.

하지만 브랜치별로 submodule이 다른 커밋을 가리킬 때, 머지를 하면 충돌이 발생할 수 있습니다. 예를 들어 상위 저장소의 prod브랜치는 submodule의 prod브랜치를 가리키고 상위 저장소의 dev브랜치는 submodule의 dev브랜치를 가리키고 있는데 각각 다른 커밋을 갖고 있는 두 브랜치 사이에 머지를 하려고 하면 충돌이 발생합니다.

3. .gitattributes로 해결

.gitattributes는 Git이 파일을 다룰 방식을 정의하는 역할을 합니다. 특히 submodule 충돌이 날 때 유용합니다. 예를 들어,

common_module merge=ours

위와 같이 설정하면, common_module submodule에서 머지 충돌이 발생했을 때 현재 브랜치의 버전(ours)을 자동으로 선택하게 됩니다.

또 다른 예시는 diff 설정입니다.

*.md diff=markdown
*.png binary

마크다운 파일은 markdown diff를 사용하라는 뜻이고, png 파일은 binary이니까 diff 하지 말라는 뜻입니다. markdown diff를 사용하게 되면 마크다운 문서를 단순히 줄 단위로만 보는 게 아니라, 마크다운 전용 diff드라이버를 적용할 수 있습니다. 제목, 리스트, 링크 등 마크다운 문법 요소를 인식해서 더 의미 있는 비교를 제공합니다.

다시 문제 상황으로 돌아와서 브랜치 A/B가 서로 다른 submodule 커밋을 가리켜서 충돌이 날 때, .gitattributes로 정책 반영해주면 됩니다. 브랜치 A/B에 각각 .gitattributes파일을 수정 및 커밋시켜주고 머지를 다시 시도하면 정책이 반영되어 머지를 하더라도 각각의 브랜치가 가리키는 submodule로 정리됩니다.

4. .gitignore으로는 해결할 수 없을까?

.gitignore은 말 그대로 Git이 추적하지 않도록 설정하는 파일입니다. 예를 들어,

common_module

위와 같이 .gitignore파일을 작성했다면 “아예 추적하지 않는다”는 의미라 Git이 submodule 버전을 관리하지 않습니다. 충돌은 피할 수 있지만, 팀원마다 submodule 버전이 달라져 빌드나 테스트가 엉킬 수 있습니다. 반면 .gitattributes는 추적은 하되, 충돌 시 어떻게 해석할지 정의하기 때문에 일관성을 유지하면서 충돌을 자동으로 해결할 수 있습니다.

5. 마무리

정리하면,

• submodule은 공통 모듈을 일괄 관리할 수 있어 유용하지만,
• 브랜치마다 다른 커밋을 가리킬 때는 머지 충돌을 일으키기 쉽습니다.
• .gitattributes를 활용해 충돌 처리 정책을 정의하면 이러한 문제를 근본적으로 해결할 수 있습니다.

사실 이 문제는 꽤 오래 겪고 있었지만, 그동안은 당장 눈앞의 충돌만 해결하느라 근본적인 방법을 찾지 못했습니다. 이번 경험을 통해 새로운 문제 상황이 생겼을 때는 먼저 원인과 근본 해결 방법을 확인하고 빠르게 반영하는 습관이 중요하다는 걸 다시 한번 깨닫게 되었습니다.

"MQ 대신 Kafka만 써도 되지 않을까?"
"Kafka가 MQ를 완전히 대체할 수 있을까?"

MQ로도 로그 수집 되지 않나요?

Kafka는 로그 수집 시스템에 자주 사용됩니다.
그런데 이런 의문이 들 수 있습니다.

"어차피 중앙에서 로그를 수집할 거면 MQ로도 충분하지 않나?"

맞습니다. MQ도 로그 수집에 사용 가능합니다.
각 서비스가 메시지를 큐로 보내고, 중앙 로그 서버가 소비하면 됩니다.

하지만 Kafka는 다음과 같은 이유로 더 적합합니다.

Kafka가 로그 수집에 더 적합한 이유

1. 고성능 / 수평 확장

• Kafka는 파티션 기반 구조로 소비자 수를 늘려 수평 확장이 쉬움
• MQ는 수직 확장 위주, 소비자 수에 제한 있음

2. 여러 소비자가 같은 메시지를 읽을 수 있음

• MQ는 메시지를 1번 소비하면 삭제됨
• Kafka는 Consumer Group마다 오프셋을 따로 관리함 → 여러 소비자가 동일 메시지 처리 가능

3. 메시지를 오래 저장하고 다시 읽을 수 있음

• Kafka는 디스크에 메시지를 일정 기간 저장 가능 (기본 7일, 설정 가능)
• 장애 발생 시 과거 메시지를 다시 읽어 재처리 가능

그렇다면 Kafka로 MQ를 전부 대체해도 될까?

기술적으로는 대부분 대체 가능하지만, 무조건 Kafka가 더 나은 건 아닙니다.

Kafka가 오버스펙이 되는 상황도 있습니다.

Kafka로 대체 가능한 MQ 용도

Kafka로 대체하기 어려운 MQ 용도

결론

Kafka는 단순한 MQ가 아닙니다.
대용량 스트리밍 처리와 이벤트 중심 아키텍처에 특화된 플랫폼입니다.

Kafka는 MQ를 대체할 수 있지만,
항상 Kafka가 더 좋은 선택은 아닙니다.

이 글은 GPT와 공부한 내용을 바탕으로 정리했습니다.

이러한 에러 발생 패턴을 통해, 문제의 원인은 A 서버 자체 또는 공통으로 사용하는 네트워크 통신 로직에 있을 것이라고 판단했습니다. 그리고 실제로 원인을 찾아보니 TLS 설정 문제였습니다.

🔐 TLS란 무엇인가?

TLS(Transport Layer Security) 는 인터넷 환경에서 데이터를 안전하게 주고받기 위해 사용하는 암호화 통신 프로토콜입니다. 우리가 흔히 사용하는 HTTPS는 바로 이 TLS 위에서 작동하는 HTTP 프로토콜이라고 보시면 됩니다.

TLS의 핵심 역할: 암호화: 데이터를 제3자가 볼 수 없도록 보호 무결성: 데이터가 전송 중에 변경되지 않았는지 확인 인증: 통신하는 상대방이 신뢰할 수 있는지 검증 (주로 인증서를 통해)

❓ 모든 요청에 TLS 설정이 필요한가? 모든 요청이 TLS 설정을 요구하지는 않습니다. 하지만 중요한 기준은 바로 요청이 HTTPS를 사용하는지 여부입니다.

요청 방식 TLS 필요 여부 설명 HTTP ❌ 필요 없음 암호화되지 않은 평문 통신 HTTPS ✅ 반드시 필요 TLS를 사용한 보안 통신

즉, HTTPS로 통신하는 모든 요청에는 TLS 설정이 필요하며, 서버와 클라이언트는 서로 호환되는 TLS 버전 및 Cipher suite를 지원해야 합니다.

🧪 문제 상황 정리

이번 케이스에서 A 서버는 B 서버뿐 아니라 C, D 서버에도 요청을 보내고 있었고, 이들 모두 AWS Load Balancer(LB)를 통해 구성되어 있었습니다.

A 서버의 요청 흐름:

A 서버 → AWS Load Balancer → B, C, D 서버

이때 요청 중 일부만 javax.net.ssl.SSLException 에러가 발생했고, 그 이유는 바로 AWS Load Balancer의 TLS 설정(Security policy)과 A 서버의 TLS 설정이 맞지 않았기 때문이었습니다.

🔍 원인 분석

AWS에서는 Load Balancer에 대해 Security policy라는 설정 항목을 제공합니다. 이 설정을 통해 허용할 TLS 버전과 Cipher suite를 제한할 수 있습니다.

최근 서버를 재구성하면서, 이전과 다른 Security policy인 ELBSecurityPolicy-TLS13-1-2-Res-2021-06을 적용했는데, 이 정책은 TLS 1.2 이상과 특정 암호화 방식만을 허용합니다.

하지만 A 서버는 기본 설정으로 TLS 요청을 보냈기 때문에 TLS설정이 무작위로 설정되었고 그 중 일부 요청들이 협상 과정에서 실패하여 SSLException이 발생한 것이었습니다.

🛠 해결 방법

문제를 해결하기 위해 A 서버에서 명시적으로 TLS 버전과 Cipher suite를 지정했습니다. 이렇게 하면 Load Balancer와 TLS 협상 과정에서 호환 문제 없이 통신이 가능해집니다.

✅ 참고: Java에서는 SSLContext, SSLSocketFactory, HttpClient.Builder, RestTemplate 등을 통해 TLS 설정을 직접 지정할 수 있습니다.

✅ 정리

• HTTPS 통신을 사용하는 경우, 항상 TLS 설정이 필요합니다.
• 서버와 클라이언트 간 TLS 협상이 실패하면 javax.net.ssl.SSLException이 발생할 수 있습니다.
• 중간에 AWS Load Balancer 같은 인프라가 있다면, Security policy 설정이 통신에 영향을 줄 수 있습니다.
• 명시적인 TLS 설정을 통해 안정적인 통신을 구성하는 것이 중요합니다.

티스토리 블로그 링크 https://godhkekf24.tistory.com/

on:
  schedule:
    - cron: '0 15 * * 1-5'

하지만 실제로 돌아간 시간은 17분이 지난 후에 진행되었다.

나뿐만 아니라 여러 사람들이 같은 문제를 겪고 있었다. https://github.com/orgs/community/discussions/52477

공식문서를 참고해보니 이 기능은 00분으로 설정해놓으면 다른 액션과 겹쳐 딜레이 될 수 있다는 주의사항이 나와있었다. 대부분의 스케줄이 00분에 시작하는 것이 많기 때문에 모든 요청들이 발생하면 큐에 담아 두고 나름의 우선 순위에 따라 처리되는 것 같았다. 요청이 몰리면 심지어는 jobs들이 날아갈 수 있다고 한다.

만약 정확한 시점에 액션을 돌려야 한다면 개인 서버를 구축하는 것이 안전해보이고 firebase의 cloud function을 이용하는 개발자도 있었다.

GitHub Actions을 써야하나 Jenkins를 써야하나 기준이 모호할 때가 있었는데 이로서 하나의 기준을 더 만들 수 있었던 좋은 계기가 되었다.

앞으로도 많이 개발하고 많이 막히고 올바르게 해결해가며 성장해나가고 싶다.

구현 기능

1. 평일 자정이 되면 팀원들의 레포지토리를 확인하고 새로운 커밋 유무를 확인하여 오늘 알고리즘 문제를 풀었는지 확인한다.
2. 커밋 유무를 날짜별로 정리해, README 파일에 작성하고 새로운 커밋을 진행한다.
3. 커밋하지 않은 팀원들에게는 이메일로 알람을 보낸다.

1번 기능 구현

먼저 특정 레포지토리에서 커밋 이력을 가져올 수 있는 지 확인해본다.

커밋 - GitHub Docs

GitHub Actions 공식 문서에서 List commits 를 가져올 수 있는 API를 제공해주는 것을 확인했다.

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/OWNER/REPO/commits

예제 응답

[
  {
    "url": "https://api.github.com/repos/octocat/Hello-World/commits/6dcb09b5b57875f334f61aebed695e2e4193db5e",
    "sha": "6dcb09b5b57875f334f61aebed695e2e4193db5e",
    "node_id": "MDY6Q29tbWl0NmRjYjA5YjViNTc4NzVmMzM0ZjYxYWViZWQ2OTVlMmU0MTkzZGI1ZQ==",
    "html_url": "https://github.com/octocat/Hello-World/commit/6dcb09b5b57875f334f61aebed695e2e4193db5e",
    "comments_url": "https://api.github.com/repos/octocat/Hello-World/commits/6dcb09b5b57875f334f61aebed695e2e4193db5e/comments",
    "commit": {
      "url": "https://api.github.com/repos/octocat/Hello-World/git/commits/6dcb09b5b57875f334f61aebed695e2e4193db5e",
      "author": {
        "name": "Monalisa Octocat",
        "email": "support@github.com",
        "date": "2011-04-14T16:00:49Z"
      },
      "committer": {
        "name": "Monalisa Octocat",
        "email": "support@github.com",
        "date": "2011-04-14T16:00:49Z"
      },
      "message": "Fix all the bugs",
      "tree": {
        "url": "https://api.github.com/repos/octocat/Hello-World/tree/6dcb09b5b57875f334f61aebed695e2e4193db5e",
        "sha": "6dcb09b5b57875f334f61aebed695e2e4193db5e"
      },
      "comment_count": 0,
      "verification": {
        "verified": false,
        "reason": "unsigned",
        "signature": null,
        "payload": null
      }
    },
    "author": {
      "login": "octocat",
      "id": 1,
      "node_id": "MDQ6VXNlcjE=",
      "avatar_url": "https://github.com/images/error/octocat_happy.gif",
      "gravatar_id": "",
      "url": "https://api.github.com/users/octocat",
      "html_url": "https://github.com/octocat",
      "followers_url": "https://api.github.com/users/octocat/followers",
      "following_url": "https://api.github.com/users/octocat/following{/other_user}",
      "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
      "subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
      "organizations_url": "https://api.github.com/users/octocat/orgs",
      "repos_url": "https://api.github.com/users/octocat/repos",
      "events_url": "https://api.github.com/users/octocat/events{/privacy}",
      "received_events_url": "https://api.github.com/users/octocat/received_events",
      "type": "User",
      "site_admin": false
    },
    "committer": {
      "login": "octocat",
      "id": 1,
      "node_id": "MDQ6VXNlcjE=",
      "avatar_url": "https://github.com/images/error/octocat_happy.gif",
      "gravatar_id": "",
      "url": "https://api.github.com/users/octocat",
      "html_url": "https://github.com/octocat",
      "followers_url": "https://api.github.com/users/octocat/followers",
      "following_url": "https://api.github.com/users/octocat/following{/other_user}",
      "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
      "subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
      "organizations_url": "https://api.github.com/users/octocat/orgs",
      "repos_url": "https://api.github.com/users/octocat/repos",
      "events_url": "https://api.github.com/users/octocat/events{/privacy}",
      "received_events_url": "https://api.github.com/users/octocat/received_events",
      "type": "User",
      "site_admin": false
    },
    "parents": [
      {
        "url": "https://api.github.com/repos/octocat/Hello-World/commits/6dcb09b5b57875f334f61aebed695e2e4193db5e",
        "sha": "6dcb09b5b57875f334f61aebed695e2e4193db5e"
      }
    ]
  }
]

해당 API는 본인 GITHUB 토큰만 있으면 어떤 레포지토리든지 확인 가능했다.

해당 API를 요청하고 가장 최근에 올라온 커밋의 날짜를 확인해 전 날 올라온 커밋인지 체크한다. 예를 들면 1월 24일 0시에 액션이 돌아간다면 1월 23일 0시부터 1월 24일 0시까지 확인한다.

확인 결과는 README.md 파일에 날짜 별로 업데이트 해두려고 한다.

그리고 결과들을 추후에 활용할 수 있도록 history.json 파일에 인원 별로 날짜별 커밋 유무를 업데이트 해놓으려고 한다.

README.md 파일은 추후에 다시 꾸미는 것으로 하고 매일매일 커밋 여부 확인하는 MVP 기능만 먼저 만들겠다.

[
    {
        "name": "smilejune",
        "repo": "daily-problem-solving/daily-ps"
    },
    {
        "name": "2522001",
        "repo": "daily-problem-solving/252"
    },
    {
        "name": "harin1212",
        "repo": "daily-problem-solving/algo"
    }
]

각각의 레포지토리 리스트를 json 파일로 저장해두고 리스트에 추가, 변경이 발생 시 간편하게 바꿀 수 있도록 유도했다.

객체를 다루게 되면서 파이썬으로 작성할까 고민했지만 리눅스 상에서 반복문, 조건문을 연습하는 셈 치고 그대로 밀고 나가기로 했다.

#!/usr/bin/bash

cat $0

count=$(cat users.json | jq '. | length')

for((i = 0; i < $count; i++)); do
    curl -L \
    -H "Accept: application/vnd.github+json" \
    -H "Authorization: Bearer ${{secrets.TOKEN_GITHUB}}" \
    -H "X-GitHub-Api-Version: 2022-11-28" \
    https://api.github.com/repos/daily-problem-solving/252/commits
done

해당 스크립트를 실행하려고 하는데 for문을 인식하지 못하는 문제가 있었다.

최상단에 선언된 #!/bin/sh 을 #!/bin/bash 로 변경해주었고, 현재는 #!/usr/bin/bash로 변경해봤지만 해결하지 못했다.

GitHub Actions runner 에서 기본으로 bash를 사용하고 있기 때문에 쉘 스크립트를 따로 만들어주지 않고 yml파일에 바로 작성하기로 했다.

name: algo commit autocheck

on:
  schedule:
    - cron: '0 15 * * 2-6'

  workflow_dispatch:

jobs:
  check-commit:
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@v4

      - name: check commit 
        run: |
          count=$(cat users.json | jq '. | length')
          for ((i = 0; i < count; i++)); do
            cat users.json | jq -r ".[0].name" >> README.md
            repo=$(cat users.json | jq -r ".[$i].repo")

            latest_date=$(curl -L \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer ${{ secrets.TOKEN_GITHUB }}" \
            -H "X-GitHub-Api-Version: 2022-11-28" \
            https://api.github.com/repos/$repo/commits | jq -r ".[0].commit.committer.date")
          done

          cat README.md

on:
  schedule:
    - cron: '0 15 * * 1-5'

먼저 월요일 자정부터 금요일 자정까지 확인 해야하기 때문에 해당 액션은 UTC기준 월요일 15시 - 금요일 15시에 각각 돌아가면 된다.

시간은 00:00시 부터 24:00시 사이인지 확인해야 하기 때문에 UTC 기준으로는 전날 15:00 부터 당일 15:00시 사이에 있는지 확인하며 된다.

타임 스탬프는 복잡하기 때문에 epoch time으로 사이 값에 있는지 확인해준다.

중간 코드

name: algo commit autocheck

on:
  schedule:
    - cron: '0 15 * * 1-5'

  workflow_dispatch:

jobs:
  check-commit:
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@v4

      - name: check commit 
        run: |
          count=$(cat users.json | jq '. | length')
          date -u -I >> temp.txt
          for ((i = 0; i < count; i++)); do
            cat users.json | jq -r ".[$i].name" >> temp.txt
            repo=$(cat users.json | jq -r ".[$i].repo")

            latest_date=$(curl -L \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer ${{ secrets.TOKEN_GITHUB }}" \
            -H "X-GitHub-Api-Version: 2022-11-28" \
            https://api.github.com/repos/$repo/commits | jq -r ".[0].commit.committer.date")

            latest_date_epoch=$(date -d "$latest_date" +%s)
            start_date_epoch=$(date -d "yesterday 15:00" +%s)
            end_date_epoch=$(date -d "today 15:00" +%s)

            if [[ $latest_date_epoch -ge $start_date_epoch && $latest_date_epoch -le $end_date_epoch ]]; then
              echo "Y" >> temp.txt
            else
              echo "N" >> temp.txt
            fi
          done

          cat temp.txt >> README.md

정상적으로 나오는 것을 확인했고 이후에는 변경된 README.md 파일을 반영하기 위해 커밋, 푸시가 가능한 actions를 찾아서 적용했다.

아래는 최종 코드이다.

name: algo commit autocheck

on:
  schedule:
    - cron: '0 15 * * 1-5'

  workflow_dispatch:

permissions: write-all

jobs:
  check-commit:
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@v4

      - name: check commit 
        run: |
          count=$(cat users.json | jq '. | length')
          date -u -I >> temp.txt
          for ((i = 0; i < count; i++)); do
            cat users.json | jq -r ".[$i].name" >> temp.txt
            repo=$(cat users.json | jq -r ".[$i].repo")

            latest_date=$(curl -L \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer ${{ secrets.TOKEN_GITHUB }}" \
            -H "X-GitHub-Api-Version: 2022-11-28" \
            https://api.github.com/repos/$repo/commits | jq -r ".[0].commit.committer.date")

            latest_date_epoch=$(date -d "$latest_date" +%s)
            start_date_epoch=$(date -d "yesterday 15:00" +%s)
            end_date_epoch=$(date -d "today 15:00" +%s)

            if [[ $latest_date_epoch -ge $start_date_epoch && $latest_date_epoch -le $end_date_epoch ]]; then
              echo "Y" >> temp.txt
            else
              echo "N" >> temp.txt
            fi
            echo " / " >> temp.txt
          done

          cat temp.txt >> README.md
          rm -rf temp.txt
          echo "<br>" >> README.md
      - name: Commit & Push changes
        uses: actions-js/push@master
        with:
          github_token: ${{ secrets.TOKEN_GITHUB }}

commit, push가 안되는 문제도 있었지만 permissions를 추가적으로 적용하면서 해결했다.

액션 테스트

추후에 이메일 기능과 json으로 데이터를 저장하는 기능을 구현할 예정이다.