보조기억장치

[멋쟁이사자처럼] 전국 대학 연합 아이디어톤 1등 수상 회고

hand-mk — Fri, 10 Apr 2026 18:15:17 +0900

1. 서론

필자는 취업을 하면서 부트캠프와 같은 교육 프로그램을 이수해본 적이 없다.

대신, 학부생 시절 '멋쟁이사자처럼' 이라는 전국 대학 연합 IT 학술 동아리에 들어가 2년동안 활동했다. '멋쟁이사자처럼' 소위 말하는 '멋사' 는 연단위로 기수를 진행하고 매년 동아리에 참여한 학교들에 아이디어톤, 해커톤 참가 기회가 주어진다.

필자는 11기, 12기 활동을 했고 이 중 12기 아이디어톤에서 운좋게 1등을 수상하였다..!

블로그를 이관하면서 수상 회고록을 다시 작성 해본다.

2. 본론

2.1. 기획

공모전 주제는 다음과 같았다.

"IT 기술을 활용하여 현대인의 건강 (wellness) 문제를 해결할 수 있는 아이디어를 제시하시오.”

'현대인의 건강(wellness)' 이라는 단어를 봤을 때 많은 팀들이 신체 건강과 관련된 내용을 많이 다룰거라고 예상했다. 때문에 수상을 위해서라면 단순 신체 건강이 아닌 정신 건강 문제를 해결해야 한다고 생각했다. 호기롭게 여러 논문과 기사들을 스크랩하기 시작했으나, 보통 다양한게 아니였다... 그렇게 기획이 산으로 가는 중 공모전 경험이 많은 동기가 '사회와 연관된 공모전에서는 정부 정책을 봐야 한다' 고 팁을 주었다.

실제로 2024 정부 정책 보고서를 확인해보니

AI 갈등 관리 플랫폼을 구축 해서 집단간 갈등을 완화하는 것이 2024 정부의 목표였다.

'AI 를 접목한 갈등을 완화할 수 있는 플랫폼'

을 만드는 것을 목표로 하고 해당 아이디어톤 주제와 어떻게 연관을 지어서 기획 의도를 설명할지가 관건이였다. 갈등과 현대인 건강과의 연관관계를 증명하면 우리의 서비스가 공모전 주제에 부합하게 되는 것이였다.

이 과정에 정말 많은 시간을 투자하였고, 당시 정권 대립이 고조 됐던 탓이라 핫 키워드였던 확증 편향 현상과 연관지어 갈등의 원인과 이로 인한 정신적인 스트레스가 현대 정신 건강을 해한다는 결론으로 이어졌다.

이러한 추론과 뒷받침하는 근거는 대학이나 연구소 논문을 출처로 두었고, 발표자료에 모두 기입하였다..!

2.2. 예선 2차

예선 1차는 본교 내에서 대표팀을 선출하는 것이였는데, 아슬아슬한 차이로 우리팀이 올라갔다.

예선 2차는 멋쟁이사자처럼 대학이 조별로 묶어준 대학들끼리 진행하는 방식이였다. 필자를 포함한 각 학교 대표들이 초대된 톡방에서 예선 2차 진행 방식에 대해 정했고, 오프라인으로 진행하기로 결정했다.

각 학교 대표 분들이 꼼꼼하게 준비해주시고 배려해주셔서 원활히 진행할 수 있었다.

결과적으로 우리 학교가 본선에 올라갈 수 있었다!

2.3. 본선

본선 장소는 멋쟁이사자처럼 본사 서울 종로구 청진동 246번지 디타워에서 진행됐다.

(본사가 꽤 이뻐서 사진 찍고 싶었는데.... 발표자는 맨 앞에 앉으라고 해서......ㅠ)

발표 순서는 제비뽑기로 발표자 한명씩 나와서 뽑았다...ㅎ

필자는 8번째 순서를 뽑았다..!

본사 오면서 지인들에게 연락을 많이 받았다.

많이 떨리냐는 질문을 많이 받았는데, 에이 뭐 1차 2차 예선 때 하던 것 처럼 하면 되는건데 왜 떨리냐. 라고 말을 했다.
발표 순서가 돼서 앞에 나가고 그 말을 한 걸 후회했다. 발표 직전까지 심장 bpm 이 120 이상 찍혀서 애플워치 알람이 한번 울렸고, 발표를 시작하고 나서부터는 별로 안떨렸다.

본선 발표 영상

영상엔 빠져 있지만 발표 후 심사 위원분들의 QnA 시간이 있다. 길진 않고 1-2개 정도 질문을 하신다.(안한 팀들도 있긴 했다.)

첫 번째 질문은 '감정 분석 기능은 어떻게 구현 했나요?' 라는 질문이였고 어느정도 생각 해 둔 답변이 있어서 나름 유연하게 답변했던 것 같다..

두 번째 질문은 '주요 타깃이 누구인가?' 에 대한 질문이였다.

개인적으로 두번째 질문이 제일 어려웠는데, 공공성을 띄는 서비스라 '이걸 타깃을 확정 지을 수 있나?' 라는 생각이 들었다. 그래서 답변은 '아직 잘 모르겠습니다..!' 라고 했지만, 지금와서 생각해보면 B2B 느낌으로 정부 부처를 대상으로 판다고 했다면 어땠을까라는 아쉬움이 든다..

모든 대학 발표를 마치고 잠깐의 쉬는 시간을 가졌다.

3등, 2등, 1등 순으로 발표가 진행됐는데, 2등까지 안나와서 올해도 떨어졌구나 하는 순간 우리 학교 이름이 1등 차례에 발표됐다..!

(놀라는 모습을 잘 담아주신 멋사 대학 관계자 분 감사합니다...)

부족한 실력에도 불구하고 좋은 평가를 받아서 너무 다행이다.

3. 결론

팀장을 맡아서 예선 탈락을 하면 어쩌나 라는 걱정도 많았다.

필자가 발표를 맡아서 이목이 집중됐지만 사실 팀원들이 부족한 부분을 묵묵히 채워나가줘서 이런 좋은 성과를 얻을 수 있었던 것 같다. 12기 우수 수료자로 선정 될 수 있었던 것도 이 프로젝트를 정성스럽게 준비한 결과라고 생각한다!

[AWS] AWS Certified Solutions Architect – Associate 자격증 취득 회고

hand-mk — Fri, 3 Apr 2026 17:00:07 +0900

1. 서론

최근 AWS SAA 자격증을 합격하였다 :)

필자는 글을 쓰고 있는 현재 SI 업계 개발자로 딱 1년째 일하고 있다. 부족한 실력에도 불구하고 인천국제공항 공사 발주 프로젝트를 2개 담당하고 있는데, 큰 문제 없이 수행하고 있어 감사하게도 긍정적인 평가를 받고 있다.

현재 회사 생활에서는 큰 부담이나 걱정이 없으나, 앞으로의 나의 기술적인 비전은 걱정되는건 사실이였다. SI 특성상 안정성을 추구하기 때문에 새로운 기술을 습득하기 어렵기 때문이다. 부족한 부분을 채워 나가보고자 2026 상반기 빅테크 채용공고들을 보았고, 많은 부분들이 부족하지만..ㅎ 크게 AI, 클라우드 경험과 영어 스펙이 부족하다고 느꼈다.

올해 첫 자격증으로는 클라우드를 공부해보고자 마음 먹었고 이를 준비하는 방법과 느낌점을 공유하고자 회고록을 작성해보고자 한다.

2. 본론

2.1. 왜 AWS SAA 였을까?

먼저 필자는 AWS, GCP, NCP 를 사이드 프로젝트 하면서 인스턴스 생성, 방화벽 설정 등 간단하게만 사용해본 경험이 있다. 그 중 AWS 가 가장 친밀하지 못했다.. 일단 개발 공부를 하면 'AWS 해킹썰' 하나씩은 갖고 있을거다. 본인도 마찬가지로 이유 없는 과금을 맞았던 경험이 있었고, 결국 어디서 돈이 새는지 못찾고 해당 계정을 비활성화 시켜둔 경험이 있다.

다시는 이런 바보같은 짓을 하고 싶지 않았고, 나 뿐만 아니라 모두에게 빈번하게 발생하는 일이라면 더더욱 많이 써보고 공부를 해야 하지 않을까라는 생각을 했다. (물론, 가고 싶은 회사들에서도 요구하는 역량이라는 것이 가장 크다)

좋은 기회로 개발자 지인 추천을 통해 AWS 한국사용자모임-AWSKRUG 에 들어갈 수 있었고, 타이밍이 좋게 여기서 AWS SAA 자격증 취득 스터디가 새로 생겼다. 실무에서 클라우드를 사용하지도 않아 노베이스인 내 입장에선 좋은 기회라고 생각이 들어 고민없이 스터디에 참여했다.

2.2. SAA 스터디 - AWSKRUG 자격증 소모임

AWSKRUG 자격증 소모임은 첫 오프라인 OT 를 제외하곤 모두 온라인으로 진행된다고 하여 직장인인 나에겐 더더욱 좋은 소모임이였다. 오프라인 OT 는 테헤란로에 있는 AWS Korea 본사에서 이뤄졌고, meetup.com 을 통해 신청 할 수 있었다.

엘리베이터 내리자마자 AWS 로고가 반겨주는데, 가슴이 웅장해진다..

입장할 때 출입증을 나눠준다. 사진으로 남기진 못했는데, 여러 다과가 준비돼 있었고 Nespresso 캡슐커피 & 머신이 있어 무한대로 먹을 수 있었다. 전반적인 스터디 일정을 30분 가량 설명해주시고 김선우 멘토님께서 '이런 느낌으로 나올꺼에요!' 일깨워주시기 위해 만드신 25문제 웹앱 모의고사를 풀어보는 시간도 가졌다.

나 제외하고 대략 30명 정도 오셨다. 재학생도 있긴 했지만 거의 대부분 직장 퇴근하고 오셔서 대단하다고 생각이 들었다.

오프라인 OT 이후 본격적인 자격증 스터디가 시작됐다.

자격증은 3월 내 취득을 목표로 준비했고, 김선우 멘토님께서 정적 페이지에 Lambda 기반 스터디 기록 웹을 배포해주셔서 여기에 공부한 내용을 기록했다.

2.3. 개인 학습 방법

소모임에서는 AWS SkillBuilder 를 먼저 공부해보고, 추가적인 내용은 외부 강의나 블로그를 참고하여 공부하는 것을 추천했다.

https://skillbuilder.aws/category/exam-prep/solutions-architect-associate-SAA-C03

AWS Skill Builder

skillbuilder.aws

여기에서 필터를 적용하여 무료 플랜 교육을 듣고, 문제를 풀어볼 수 있다.

본격적인 서비스 공부에 앞서 아래 링크에 있는 Official Practice Question Set: AWS Certified Solutions Architect - Associate 를 한번 풀어보는 걸 추천한다. SAA 시험과 유사하게 나오는데, 이 시험을 70% 이상 맞출 수 있으면 바로 시험 보러 간다고 될 수준이다.

https://skillbuilder.aws/learn/6NV91XYP1P/official-practice-question-set-aws-certified-solutions-architect--associate-saac03--/C4X6F66JQX

AWS Skill Builder

skillbuilder.aws

나의 결과는.... 처참했다..ㅎ

물론 오답을 정리하고 조오금은 나아졌지만, 솔직히 처음 풀 때 맞췄던 5문제도 제대로 알고 푼 건 아닌거 같다.

위기감을 느껴 SkillBuilder 에 있는 강의들을 들어봤다. 솔직히 온프레미스 환경에서 일하고 있는 나에겐 어려웠다.

서비스에 대해 '이걸 어디에 쓰는지', '왜 쓰는지', 정리된 내용이 아니였고 '시험에서 이런 서비스들이 나오니 공부하세요.' 의 느낌이 강했다. 그래서 찾게 된게 가장 유명한 Udemy 강의다.

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/?srsltid=AfmBOoqhEgHDqlrLNx2a5sLzkztiVJgF9zXae8qZ8piVJDTypUi5BnsP

【한글자막】 AWS Certified Solutions Architect Associate시험합격! 2025

[2023년 3월]: AWS UI 변경 및 시험 내용 변경에 맞춰 강의 내용이 업데이트 되었습니다! (SAA-C03) <ul><li>AWS 초보도 학습할 수 있는 친절한 강의!<

www.udemy.com

사람들 후기가 많아 별 고민 없이 결제해서 퇴근하고 주중에 최소 2시간씩, 주말에는 4시간씩 들었다.

본 강의에서는 단순 AWS 서비스에 대해 줄줄줄 설명만 하는게 아니라 간단하게 실습하는 영상이 있다. 때문에, 나같이 온프레미스에서 개발을 하고 있고 클라우드에 대한 지식이 전무한 분들에게 매우 추천한다.

Udemy 강의를 전부 듣고, 이전보단 AWS 서비스들에 대해 넓게 이해할 수 있었지만 워낙 서비스들이 많았기에 시험을 패스할 수 있겠다란 확신이 없었다. 그래서 찾아보니 유명한 dump 문제 사이트를 찾을 수 있었다.

https://free-braindumps.com/amazon/free-saa-c03-braindumps/page-2

Free SAA-C03 Practice Questions & AI Tutor | Free-Braindumps.com

Hay! I’m your AI study assistant for the SAA-C03 exam. Ask me anything about the exam or the questions on this page, and I’ll break it down so it actually makes sense. You want it in a different language? Just say it.

free-braindumps.com

다른 분들은 600문제, 800 문제를 푸신 분들도 계셨는데, 애초에 준비기간이 3주였던 나로썬 100문제가 최선이였다.

확실히 문제들을 접해보니, 처음보는 서비스들이 꽤 있었고 오답을 정리하면서 부족한 지식들을 채워나갔다.

2.4. 시험 당일

필자는 SRTC 에서 시험을 봤다. 오전 9시가 시험 시작이라 8시 30분에 도착했는데, 보안 서약서 작성하고 희망하면 바로 시험 응시 할 수 있다고 해서 바로 시험장으로 들어갔다.

https://maps.app.goo.gl/b4KnUybt6RiX6R7y7

SRTC · TGL 402호 KR 서울특별시 강남구 봉은사로 303 경복빌딩 4F

★★★★☆ · 교육 테스트 서비스

www.google.com

시험장 내부는 독서실 같은 느낌이였고, 책상에 모니터가 보인다. 화면에 보이는 버튼을 누르면 시험에 응시할 수 있다. 오전 시험이라 사람들이 많이 없을 줄 알았는데, 생각보다 많이 있었다. 대략 15명정도..?

시험장에 대한 걱정이 많았는데, 깨끗하고 시험을 보기엔 모자람이 없는 공간이였다. 특히 시험 감독관님들이 친절하게 응대해 주셔서 맘편히 시험을 응시할 수 있었다.

2.5. 결과 발표

결과는 당일 저녁 8시쯤 나왔다.

사실, 시험 보고 나오면서 70%는 다시 봐야지... 생각하고 있었다. 15문제 정도 플래그를 걸어뒀는데 사실상 처음보는 서비스들이였다. 65문제 중에 15문제는 채점이 안되는 문제라고 해도 불안했다.

더군다나, 응시 후 5시간 이내로 메일로 결과 알려준다고 했는데 저녁 시간까지 안와서 '떨어졌구나..' 싶었다. 혹시나 하는 마음으로 https://cp.certmetrics.com/ 에 들어가서 확인해보니 합격 결과가 나와있었다.

749점으로 간당간당하긴 했다..

섹션별로 성적을 간략하게 보여주는데, 도메인 2에서 공부가 부족했던 것 같다. HA 관련 아키텍처를 좀 더 고민하고 공부해야겠다.

3. 결론

물론 자격증 취득이 목적이였긴 하지만, 강의 실습을 통해 왜 클라우드가 좋은지를 몸소 느꼈던 경험이였다. 로드밸런싱 실습을 할 때 버튼 딸깍으로 ALB 를 만들고, AMI, Auto-Scailing 이 적용된 EC2 인스턴스 여러개를 단 몇초만에 생성하여 물리적인 서버 없이 운영환경을 만들 수 있다는 점이 가장 큰 장점인 것 같다.

또한, AWS 에는 일반적으로 알고있는 EC2 서비스 외에 좋은 서비스가 너무 많다. 그런 서비스들이 운영 오버헤드를 줄임으로써 개발자가 오로지 프러덕팅에만 집중 할 수 있는게 또 하나의 장점인 것 같다. 이래서 AWS AWS 하는구나.... 서비스 운영 환경에 가서 내 지식을 토대로 기여해보고 싶은 생각이 더 확고해졌다..!

마지막으로 ALB 연습하다가 녹화한 영상으로 마무리..

[MCP] Claude + IntelliJ IDEA 2025.2.4 (Ultimate Edition) 연동

hand-mk — Mon, 23 Feb 2026 16:18:31 +0900

1. 서론

최근 MCP 가 개발 업계에서 매우 핫하다. 필자의 경우 Gemini 유료 구독 (3.1 Pro Model) 를 사용하여 개발을 했으나, 프롬프트에 단순히 입력하고 답변받는 구조에 지쳤다. 그래서 Claude 로 갈아타서 MCP 서버 구성을 진행해보고자 하였고 그 중 IntelliJ 연동을 첫번째로 진행하였다. 이에 관한 내용이다.

2. 본론

2.1. MCP 란?

`MCP(Model Context Protocol)` 는 AI 를 외부 시스템에 연결하기 위한 일종의 프로토콜이다. 우리가 흔히 얘기하던 HTTP 프로토콜과 같이 AI 를 다른 응용프로그램이나 서버에 연동하는 프로토콜이다.

MCP를 사용하면 Claude나 ChatGPT와 같은 AI 를 단순히 프롬프트를 웹에서 입력하고 답변 받는것이 아닌, 로컬에 있는 파일에 접근 가능하게끔 할 수 있어 일일이 복붙을 안해도 된다. 뿐만 아니라, 다른 서버에 연동 (ex. Slack, Gmail 등) 하여 업무를 시킬 수 도 있다.

더 자세한 내용은 공식문서를 확인하면 이해할 수 있다.

https://modelcontextprotocol.io/docs/getting-started/intro

What is the Model Context Protocol (MCP)? - Model Context Protocol

What is the Model Context Protocol (MCP)?

modelcontextprotocol.io

2.2. Claude Desktop 설치

https://claude.com/download

Download Claude | Claude

Download Claude for desktop and mobile. Access AI assistance natively on Mac, Windows, iOS, and Android across all your devices.

claude.com

공식 홈페이지에서 해당하는 OS 에 맞게 설치하면 된다.

2.3. IntelliJ Plugin MCP Server 설치

Claude 에서 IntelliJ 에 연동을 하려면 `MCP Server` 플러그인을 설치해야 한다.

IntelliJ 상에서 다음과 같이 입력해 Setting > Plugins 창을 연다.

# 윈도우
Ctrl + Alt + S

# 맥
Command +

상단에 MCP Server 를 입력하여 해당 플러그인을 설치한다.

해당 플러그인을 설치하면 Settings 왼쪽 탭에 MCP Server 가 생긴걸 확인할 수 있다.

`Enable MCP Server` 체크 > Clients Auto-Configuration 하위 Claude App `Auto-Configure` 클릭

하면 오른쪽에 초론색 체크표시가 뜬다. 이러면 사실상 연동이 끝이다.

이전 레거시 IntelliJ 의 경우 자동으로 claude_desktop_config.json 업데이트가 안된다고 알고있다.
해당 방법으로 되지 않을 경우, 수동으로 json 파일을 수정해줘야 한다.

2.4. MCP 연동 확인 방법

연동을 확인하는 방법은 `Claude Desktop` 앱 상에서 확인 가능하다.

왼쪽 하단 설정 > 커넥터 > 연동된 환경 확인 가능하다.

2.5. 연동안됨?

처음엔 상기 내용으로 했을 때 연동이 되지 않았다.

여러 글들을 보니, 왼쪽 하단 설정 > 개발자 > 구성 편집 을 눌러 ` claude_desktop_config.json` 을 확인해보라고 했다.

필자의 경우 애초에 AppData\Roaming\Claude 경로가 없다고 떴다.

종종 이런일이 발생할 수 있다고 한다. 이럴땐 그냥 삽질하지 말고 지웠다가 다시 설치하면 자동으로 해당 경로에 파일이 생성된다.

연동이 잘 되면, 실제로 설정 json 파일에 다음과 같이 자동으로 jetbrains mcpServers 설정이 들어가 있어야 한다.

이제 연동 잘 됐는지 실제로 프롬프트를 넣어보면 프로젝트를 읽어 분석하고 답변해주는걸 확인할 수 있다.

[비동기 이벤트 처리] Inotify + RabbitMQ를 활용한 실시간 파일 감지 및 비동기 처리 파이프라인 구축

hand-mk — Fri, 9 Jan 2026 17:06:56 +0900

1. 서론

회사에서 폐쇄망 운영 환경의 SI 사업에 투입됐다.

본 사업의 목표는 일 평균 10만건 데이터를 송수신 하는 인터페이스를 구축 및 고도화 하는 것이다. 보안상 상세하게 기재하진 못하지만 간단하게 운영환경을 기술하자면, 총 3대의 서버 (Rocky Linux 9.5) 가 구동된다. 물리적인 서버 3대가 있는 이유는 서버 이중화 와 예비 서버 용도이다. 이 3대 중 한 1대만 Active 상태를 유지하고 해당 서버를 통해 항공 데이터(.txt) 가 송수신된다.

데이터 양은 하루 평균 10만건이다. 또한, 데이터 종류가 8가지이고 데이터 종류별로 타깃 단위 시스템에 매핑해서 송수신 해야 하는데 이 단위 시스템 수만 118개이다.... ㄷㄷ 처음엔 막막했지만 다행히 이 중 15개 시스템에만 연계가 되게끔 인터페이스를 구현하면 된다는 얘기를 듣고 조금 괜찮아졌다.

개발이 마무리 된 시점에서 연계 시스템을 구축하면서 겪었던 문제와 고민했던 내용을 기록해보고자 블로그에 작성해보고자 한다.

2. 본론

데이터 양을 보고 예전 <GAGU> 사이드 플젝에서 채팅 기능 구현할 때 사용했던 `RabbitMQ` 를 무조건 사용해야겠다고 생각이 들었다. 문제는 '실시간으로 데이터를 어떻게 감지하냐' 였다. 실시간으로 데이터를 감지 하는 내용을 얘기 하기 전에 송수신 과정에서의 요구사항에 대해 이해가 필요할 것 같다.

발주처에서 요구하는 송수신 과정은 다음과 같이 이루어 진다.

1. 시스템 내 FDS (File Delivery System) 에 송신 하고자 하는 파일 삽입 -> Gateway 의 /*/temp 디렉토리로 파일 전송

2. /temp 디렉토리에서 해당 데이터 바디 값이 MDD 를 준수하였는지 유효성 검증 후 /succ 또는 /fail 폴더로 이동

3. /succ 디렉토리로 들어오는 데이터만 연계 시스템으로 전송 (.txt 파일 생성)

º 보안상 문제로 System A, System B 로 정의
º System A 를 기준으로 송수신 정의됨

다행히 1번과 2번은 레거시 FDS 시스템에 종속적이여서 바꾸기 힘들다고 해서 /succ 파일에 들어오는 데이터만 문제없이 연계하면 되는 상황이였다.

필자가 이러한 요구사항을 구현하기 위한 시나리오는 다음과 같다.

1. 메시지 및 타깃 시스템별 데이터를 담는 Queue 생성

2. /*/succ 로 들어오는 데이터를 실시간으로 감지 (단, 중복으로 데이터를 감지하면 안됨)

3. 실시간으로 감지된 데이터를 정의된 라우팅 키로 Queue 에 삽입

4. Queue 에 적재된 데이터를 타깃 시스템에서 비동기로 처리

이 시나리오에서의 핵심은 실시간 감지였다..!

그래서 리눅스 환경과 호환이 잘 되는 디렉토리 이벤트 감지 서비스를 부지런히 찾아보았고, 이 과정에서 Polling 감지, Telegraf 사용, Inotify 커널 이벤트 라는 방법들을 직접 사용해보고 비교해보았다.

2.1. 신규 데이터 실시간 감지

2.1.1. polling (full-scan) - 성능 이슈 염려하여 기각

일단 가장 간단하게 '구현만' 할 수 있는 방법은 polling 방식이 있을 것 같았다.

주기적으로 `linux date(서버 현재 시각)`과 파일 생성시간을 비교하여 최신 일자일 경우 신규 데이터로 감지하는 것이다.

이렇게 되면 스케줄러로 주기적으로 현재 시간과 +- 오차 시간을 적용하여 비교 후 처리 할텐데, 예외 상황이 많을 것 같았다. 스케줄러가 동작하지 않거나 지연이 됐을 때 데이터가 누락되는 현상이 발생할 수 있고, polling 으로 불필요한 조회 연산을 지속적으로 호출하게끔 되어 해당 방법은 소거하였다.

2.1.2. Telegraf - Queue 삽입까지 너무 오래걸려서 기각

모니터링 시스템 구현 관련 라이브러리를 찾던 중 `Telegraf` + `Grafana` 조합을 많이들 사용한다는 것을 알게 되었고, 이 중 `Telegraf` 에 실시간 감지 기능이 내장돼 있다는 걸 확인했다.

`Telegraf`는 `InfluxData`에서 개발하였으며 데이터베이스나 서버의 데이터 (디렉토리도 가능) 를 수집하는 Agent 역할을 한다. Docker hub 에도 공식 이미지가 있고, `telegraf.conf` 라는 설정 파일로 Agent 를 조작하는 느낌이라 설정이 간편했다.

https://hub.docker.com/_/telegraf

telegraf - Official Image | Docker Hub

Quick reference Supported tags and respective Dockerfile links Quick reference (cont.) What is telegraf? Telegraf is an open source agent for collecting, processing, aggregating, and writing metrics. Based on a plugin system to enable developers in the com

hub.docker.com

테스트 용으로 해당 디렉토리에 새로 생성 + 이동 됐을 때 로그로 바디 값을 출력하는 설정을 주었다.

telegraf.conf

[agent]

# 데이터 수집 주기
interval = "10s" 

# 수집된 데이터 처리 주기
flush_interval = "10s"

[[inputs.tail]] # 파일 내용 추적 섹션

# 감시할 파일 경로
files = ["/watch-data/*.txt"]

# 파일 새로 생겼을 때 조작
from_beginning = true

# 파일 안에 있는 값 그대로 사용
data_format = "value"

# 데이터 타입 지정
data_type = "string"
name_override = "txtfile_monitor"

[[outputs.file]]

# 파일 바디 값 출력
files = ["stdout"]
data_format="json"

이후 Docker hub 에 기재돼 있는대로 container 구동을 하였다.

docker run -d --name telegraf
  -v {telegraf.conf 실제 경로}:/etc/telegraf/telegraf.conf:ro \
  -v {타겟 디렉토리 경로}:/watch-data \
  telegraf

테스트는 다음과 같이 진행했고, 데이터의 바디값이 정상적으로 출력됨을 확인했다.

1. 새로운 txt 생성

2. /test 폴더 mv 명령어로 이동

3. 로그 확인

이후 단순 출력하는 부분을 RabbitMQ Queue 로 삽입 되게끔 수정하여 테스트 했을 때, 정상적으로 삽입되어 원하는 기능을 테스트 해볼 수 있었다.

[agent]
interval = "10s"
flush_interval = "10s"
metric_batch_size = 1

[[inputs.tail]]
files = ["/watch-data/*.txt"]
from_beginning = true
data_format = "value"
data_type = "string"
name_override = "txtfile_monitor"

[[outputs.amqp]] # rabbitMQ 로 삽입
brokers = ["amqp://guest:guest@{서버 IP}:5672"]
data_format = "json"
exchange = "test.exchange"
exchange_type = "direct"
routing_key = "test.routing.key"
delivery_mode = "persistent"
exchange_durability = "durable"

다만 아쉬운건 이벤트 감지는 즉각적으로 일어나지만, Queue 까지 가기까지의 시간이 너무 오래 걸렸다.

단순히 데이터 1건을 이벤트 감지하고 Queue 에 삽입하는데 10초가 소요됐다.

이유는 `Telegraf` 가 `Node-exporter` 처럼 메트릭 수집 도구 용도로 만들어졌기 때문이다. 어떤 데이터가 들어오든 내부적으로 `Telegraf Metric` 이라는 타입의 데이터로 변환한다.

`데이터 읽기` -> `Telegraf Metric 변환` -> `버퍼에 저장` -> `Output 플러그인에서 다시 JSON으로 변환` -> `전송`

단순히 데이터를 감지하고 Queue 에 삽입하는 것이 아닌 앞단에 데이터 변환 과정이 있어 오래 걸린다고 한다..

이 과정을 커스텀 하는 것이 어려워 보였고, 만약 10만건이 동시에 몰렸을 때 수행된다고 한다면 병목현상이 발생할 것 같았다.

또 다른 문제는 Queue 에 보낼 때이다. '하나 보낼 때 오래걸리면, 대량을 묶어서 보내면 되지 않나?' 라고 생각이 들 수 있다.

`Telegraf` 는 효율성을 위해 기본적으로 데이터를 Batch 로 묶어 보낸다. 그래서 앞선 `Telegraf.conf` 에서 `metric_batch_size = 1` 로 설정을 할 수 있고 만약 전송 성능을 향상 시키려면 이 값을 높이면 된다.

만약 1000개를 한 배치로 보내는데 이 중 100번째 데이터가 문제가 있다고 하면 데이터 정합성 문제가 발생할 수 있겠다 싶었다.

이러 저러한 이유로 `Telegraf` 도 아쉽게 기각됐다.

2.1.3. Linux Inotify - 제일 적합

`Telegraf` 를 떠나보내고.. 지친 상태로 README.md 를 읽던 중 Telegraf 가 Linux-Inotify 기반으로 만들어진 것을 알게 됐다.

https://github.com/influxdata/telegraf/blob/master/plugins/inputs/tail/README.md

telegraf/plugins/inputs/tail/README.md at master · influxdata/telegraf

Agent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data. - influxdata/telegraf

github.com

(이래서 README.md 를 잘 읽어야.....)

이러한 이유로 Inotify 를 써보게 됐다.

`Inotify` 는 리눅스 커널에 내장된 파일 시스템 감시 서브시스템으로 별도의 설치가 필요 없지만, 이를 특정 디렉토리를 감시하게끔 커스텀하고 RabbitMQ 와 연동하기 위해선 `inotify-tools` 패키지를 써야 된다고 한다.

Linux 내장 기능이기 때문에, Docker 기본 이미지는 가벼운 Linux 이미지를 사용하였고 관련된 패키지들을 빌드할 때 설치하였다.

Dockerfile

# 1. Alpine Linux 기반
FROM alpine:3.18

# 2. inotify-tools, python3, pip 설치
RUN apk add --no-cache inotify-tools python3 py3-pip

# Python 전용 RabbitMQ 통신 프로토콜 라이브러리 패키지
RUN pip3 install pika --break-system-packages

# 이벤트 발생시 RabbitMQ Queue 삽입 로직
COPY publisher.py /publisher.py

# Inotify-tools 스크립트
COPY watch-and-publish.sh /watch-and-publish.sh
RUN chmod +x /watch-and-publish.sh

# 실행
CMD ["/watch-and-publish.sh"]

`Dockerfile` 에 있는 `/watch-and-publish.sh` 가 `inotify-tools` 를 사용해 특정 디렉토리에 신규 파일 생성 이벤트를 감지하는 스크립트고, `publisher.py` 가 Linux - RabbitMQ 서버 간 연동을 해주는 파이썬 코드다.

watch-and-publish.sh

#!/bin/sh

WATCH_DIR_INSIDE_CONTAINER=${WATCH_DIR:-"/data"}

echo ">>> File Watcher started."
echo ">>> Watching: $WATCH_DIR_INSIDE_CONTAINER"
echo ">>> Target RabbitMQ: $RMQ_HOST (AMQP)"

# WATCH_DIR_INSIDE_CONTAINER 를 관측해라
inotifywait -m -q -e close_write -e moved_to --format '%w%f' "$WATCH_DIR_INSIDE_CONTAINER" | \
python3 -u /publisher.py

여기에서 inotifywait이 특정 디렉토리를 관측하다가, 이동 이벤트를 감지하면 해당 파일 경로를 stdout 하고 파이프 구조를 통해 publisher.py 이 stdin으로 받는 구조다. 결국 python 에는 이벤트가 감지된 파일 경로가 들어간다.

publisher.py

import sys
import os
import pika
import json
import time
import select

# RabbitMQ 연결 설정
RMQ_HOST = os.environ.get('RMQ_HOST', 'localhost')
RMQ_PORT = int(os.environ.get('RMQ_PORT', 5672))
RMQ_USER = os.environ.get('RMQ_USER', 'guest')
RMQ_PASS = os.environ.get('RMQ_PASS', 'guest')
EXCHANGE = os.environ.get('RMQ_EXCHANGE', 'file.events')
ROUTING_KEY = os.environ.get('RMQ_ROUTING_KEY', 'file.new')

credentials = pika.PlainCredentials(RMQ_USER, RMQ_PASS)
parameters = pika.ConnectionParameters(host=RMQ_HOST, port=RMQ_PORT, credentials=credentials, heartbeat=60)

print(f">>> Python Publisher connecting to {RMQ_HOST}:{RMQ_PORT} (AMQP)...")

connection = None

# pika 패키지로 RabbitMQ 연결
try:
    connection = pika.BlockingConnection(parameters)
    channel = connection.channel()
    
    channel.exchange_declare(exchange=EXCHANGE, exchange_type='direct', durable=True)
  
    channel.confirm_delivery()

    print(">>> Connection established. Waiting for input...")

    # stdin 으로 받은 파일명
    while True:
        rlist, _, _ = select.select([sys.stdin], [], [], 1.0)

        if rlist:
            
            line = sys.stdin.readline()
            if not line:
                break
			
            file_path = line.strip()
            if not file_path:
                continue
			
            # 파일을 직접 읽음
            try:
                with open(file_path, 'r', encoding='utf-8') as f:
                    content = f.read()
                
                # RabbitMQ 로 보낼 Payload 로 구성
                payload = {
                    "filePath": file_path,
                    "fileContent": content
                }
                body = json.dumps(payload)
				
                # 해당 라우팅 키로 전송
                channel.basic_publish(
                    exchange=EXCHANGE,
                    routing_key=ROUTING_KEY,
                    body=body,
                    properties=pika.BasicProperties(
                        delivery_mode=2,
                        content_type='application/json'
                    )
                )
                print(f"Sent: {file_path}")

            except Exception as e:
                print(f"Error processing file {file_path}: {e}", file=sys.stderr)
        else:
            connection.process_data_events()

except KeyboardInterrupt:
    print("Stopping...")
except Exception as e:
    print(f"Critical Connection Error: {e}", file=sys.stderr)
finally:
    if connection and connection.is_open:
        connection.close()

`publisher.py` 에서 stdin 으로 받은 파일명으로 직접 읽어서 해당 바디값을 페이로드로 Queue 에 삽입하는 구조다.

이렇게 스트립트들을 구성하고 docker container 로 구동시켰다.

그리고 발주처에서 제공한 파일들을 mv 명령어로 이동 됐을 때 Queue 에 정상적으로 삽입 되는 걸 확인 할 수 있었다..!

2.1.4. 부하 테스트 후 개선

앞서 기술했다시피 꽤 대량의 데이터가 송수신된다. 그렇기 때문에 부하테스트를 해보기로 했고, 발주처에서 정의한 부하 정도는 3천건이라고 얘기하긴 했지만 필자는 발주처에서 제공한 데이터 전부를 넣어보고 부하테스트를 진행하였다.

20781 건을 동시에 감시 디렉토리로 이동하는 테스트를 진행했고, 결과는 처참했다ㅋㅋㅋㅋㅋㅋ

초당 약 148건의 속도로 삽입됐는데 약 2분정도? 소요됐다. 근데 데이터는 2,465 건 누락됐다..ㅎ

지금은 웃으면서 쓰지만 당시에 매우 식은땀이 났다. 이대로 가면 중요한 항공 데이터를 내가 날려먹는 상황이 나온다는 생각에 AI 의 힘을 빌렸다.

AI 가 알려준 문제로는 크게 3가지였다.

1. 동기 ACK 대기: 데이터 하나 송신 후 제대로 갔는지 체크하는 대기 시간 발생하여 대량 전송 시 병목현상 발생

2. readLine(): readline()은 한 줄씩 시스템콜을 발생시켜 대량 입력 시 I/O 오버헤드가 큼.

3. max_queued_events: inotify 이벤트 큐에 적재할 수 있는 최대 이벤트 수가 기본 값으로 2만건 수용이 안됨.

이를 해결 하기 위해서 다음과 같은 개선 사항을 알려줬다.

1. 동기 ACK 대기 제거 (Publisher Confirm 비활성화)

pika 패키지의 confirm_delivery()는 메시지를 1건 보낼 때마다 RabbitMQ broker가 "잘 받았어"라고 응답(ACK)을 줄 때까지 기다리는 기능이다. 비유하자면 택배를 보내는데, 한 박스 보내고 → 상대방이 "받았습니다" 전화할 때까지 기다리고 → 다음 박스 보내고 → 또 전화 기다리고… 이걸 2만번 반복하는 셈이다.

# Before: 매 건마다 broker ACK를 동기적으로 기다림
channel.confirm_delivery()

# After: ACK 대기 없이 연속 전송 (fire-and-forget)
# channel.confirm_delivery()

이걸 끄면 택배를 쉬지 않고 연속으로 보내는 것과 같다. 대신 1000건마다 process_data_events()로 broker와 상태를 한번씩 확인하여 연결이 막히지 않게 했다. 참고로 confirm을 꺼도 TCP 연결 위에서 AMQP 프로토콜로 통신하기 때문에 메시지가 broker에 도달하는 것 자체는 보장된다.

2. readline() → os.read() 청크 단위 읽기

sys.stdin.readline()은 파이프에서 데이터를 한 줄씩 읽는다. 파일 경로가 2만건 들어오면 시스템콜이 2만번 발생한다.

# Before: readline() - 한 줄씩 읽기
# 파이프에 "file1\nfile2\nfile3\n..." 이 들어오면
#   1번째 시스템콜 → "file1\n" 획득
#   2번째 시스템콜 → "file2\n" 획득
#   3번째 시스템콜 → "file3\n" 획득
#   ... 2만번 반복

line = sys.stdin.readline()

# After: os.read() - 1MB를 한번에 읽기
# 파이프에 "file1\nfile2\nfile3\n..." 이 들어오면
#   1번째 시스템콜 → "file1\nfile2\nfile3\n...file800\n" 한번에 획득
#   직접 \n 기준으로 split해서 처리

chunk = os.read(sys.stdin.fileno(), 1024 * 1024)

마트에서 장바구니 없이 물건 하나 집고 계산하고, 다시 하나 집고 계산하는 것(readline)과, 카트에 한번에 담아서 한번에 계산하는 것(os.read)의 차이다. 시스템콜 횟수가 줄어드니 당연히 빨라진다.

3. max_queued_events 파라미터 변경

max_queued_events는 inotify 이벤트 큐에 적재할 수 있는 **최대 이벤트 수(건수)**다. 기본값은 16,384건인데, 2만건을 한번에 mv하면 이 큐가 넘쳐서 초과분 이벤트가 버려진다. 2,465건이 누락된 원인이 바로 이것이다.

# 기본값 확인
cat /proc/sys/fs/inotify/max_queued_events
# 16384

# 영구 적용 (reboot 후에도 유지)
echo "fs.inotify.max_queued_events = 49152" | sudo tee /etc/sysctl.d/99-inotify.conf
sudo sysctl -p /etc/sysctl.d/99-inotify.conf

이 설정은 호스트 커널 레벨 파라미터이므로, Docker 컨테이너 안이 아니라 호스트 서버에서 실행해야 한다. 컨테이너는 호스트 커널을 공유하기 때문에 호스트에서 변경하면 컨테이너에도 적용된다.

다시 테스트 해봤을 때 초당 2520건 삽입 되는 걸 확인 할 수 있었고, 데이터 누락없이 10초만에 모두 Queue 에 삽입 된 걸 볼 수 있었다. 대략 2분 -> 10초로 감소된 셈이다!

3. 마무리

누군가에겐 간단한 문제였을 수 있지만.. 처음 실시간 연계 파이프라인을 구축해보는 입장에서 꽤 어려웠고, 그만큼 많이 고민하면서 시스템 설계를 하였다. 이런 경험들이 쌓여서 다음 유사한 케이스에선 좀 더 삽질을 덜 해서 더욱 탄탄한 구조를 만들 수 있음 좋겠다!

[WSL] Windows 부팅 후 WSL 자동 구동

hand-mk — Mon, 5 Jan 2026 23:34:31 +0900

1. 서론

회사에서 폐쇄망 운영 환경의 SI 사업에 투입되게 되었다. 운영 환경에는 서버가 총 4대(Rocky-Linux 9.5 3대, Windows 11 pro 1대) 가 있고, 그 중 Windows 11 pro 서버는 모니터링 서버로 `SpringBoot + Thymeleaf` 웹, `PostgreSQL DB`, `RabbitMQ`, 그 외 기타 WAS 가 Docker Container 로 구동되고 있다.

환경 구축 및 배포 후 테스트를 정상적으로 마쳤다. 하지만 다음날 출근해보니 모든 서버가 죽어있었다.

확인해보니 `WSL` 상태가 Stopped 로 되어 있었다. 만약 서버를 재부팅할 경우 WSL 을 수동으로 켜주지 않는 이상 WSL 상에 있는 Docker Container 가 구동할 수 없는 문제가 발생한 것이였다. 물론 수동으로 하면 되지만, 개발자가 아닌 사용자 입장에서 번거로운 일이다. 'Windows 가 부팅 할 때 같이 켜지면 안되나?' 라는 의문으로 시작하여 해결한 내용을 기술하였다.

2. 본론

wsl 은 pc 가 꺼지면 자동으로 시작되지 않기 때문에 부팅 후 자동으로 실행하는 스크립트를 실행시켜야 한다.

힌트는 https://wikidocs.net/219903 에서 얻을 수 있었다.

다만, 필자의 경우 작업 스케줄러에 등록하는 방법은 성공하지 못했다. 해당 글에서 'vbs와 Windows 작업 스케줄러를 이용' 한 방법으론 성공하지 못했다고 한다. 필자의 경우 vbs (VB스크립트) 를 작성하여 `Windows 시작 프로그램` 에 등록하는 방법으로 성공하였다.

2.1. vbs 작성

VBS(Visual Basic Script) 는 Microsoft 가 만든 `Windows 운영체제 전용 자동화 스크립트` 이다. 리눅스에서의 `쉘 스크립트(.sh)` 와 비슷하다. 이 스크립트를 작성하여 시작프로그램으로 등록해두면 스크립트에 작성된 명령어를 실행한다.

윈도우 키 + `R` 을 눌러 `shell:startup (시작 프로그램 파일 탐색기)` 을 연다.

해당 폴더에 처음엔 txt 파일로 생성하여 WSL 구동 스크립트를 기입한다.

# Windows Script Host Shell 도구를 불러옴
Set WshShell = CreateObject("WScript.Shell")

# wsl 실행 명령을 실행하되, 0 을 붙여 백그라운드로 실행
# 이때 Ubuntu-22.04 은 실제 WSL 설치된 리눅스 배포판 명을 입력
WshShell.Run "wsl.exe -d Ubuntu-22.04", 0

# 메모리 해제
Set WshShell = Nothing

이후 `.txt` > `.vbs` 로 변경해준다.

이후 재부팅하여 테스트 해보면 자동으로 WSL 이 구동중인걸 확인할 수 있다.

[Docker] Windows 11 폐쇄망 환경 Docker 설치 (Docker Desktop x)

hand-mk — Sat, 3 Jan 2026 15:10:44 +0900

* OS: Windows 11 Pro (이지만, 자택에서 해보니 그냥 Windows 11 에서도 무방)
* WSL: v2.6.3.0
* containerd.io: v2.2.1-1
* docker-buildx-plugin: v0.30.1-1
* docker-ce: v29.1.3-1
* docker-ce-cli: v29.1.3-1
* docker-compose-plugin: v5.0.0-1

1. 서론

회사에서 폐쇄망 운영 환경의 SI 사업에 투입됐다. 운영 환경에서 총 4대의 서버 (Windows 11 Pro OS 1대, Rocky Linux 9.5 3대) 가 투입 되었고 각 서버에 필자가 개발한 소프트웨어를 프로세스로 띄워야 하는 상황이였다. 특히 Windows 11 에는 DB서버와 RabbitMQ 서버, 모니터링 웹서버를 띄워야 했다.

단순히 web(Thymeleaf) 하나만 띄운다고 한다면 jdk 설치 파일과 jar 빌드 파일만 갖고 가면 되지만, 여러 설치 파일을 설치해야만 했고 그 과정에서 의존성 충돌이 많이 일어날 것 같아 Docker 가 필수라고 생각했다. 회사 선배들에게 물어보니, Linux 폐쇄망 환경에서의 Docker 설치 경험은 있으나 Windows 11 환경에서 Docker 를 사용해본 경험은 없다고 했다.. 그래서 '내가 한번 해봐?' 라는 생각으로 여러 시행착오 끝에 나만의 매뉴얼을 만들었다. 이에 대해 기술한 내용이다.

2. 본론

기본적으로 windows 에 docker engine 을 직접 구동하는 것은 불가능하다. 이러한 이유로 microsoft 는 wsl(windows subsystem for linux) 를 적극 권장한다.

다음은 wsl 을 구성하는 방법이다.

2.1. 리눅스 서브 시스템 활성화

꼭 cmd 관리자 모드로 실행해야 한다.

Microsoft WSL 2 공식문서에 따르면 WSL2를 설치하기 전에 `Linux용 Windows 하위 시스템`, `Virtual Machine Platform` 선택적 기능을 사용하도록 설정해야 한다.

https://learn.microsoft.com/ko-kr/windows/wsl/install-manual#step-1---enable-the-windows-subsystem-for-linux

이전 버전의 WSL에 대한 수동 설치 단계

wsl install 명령을 사용하는 대신 이전 버전의 Windows에 WSL을 수동으로 설치하는 단계별 지침입니다.

learn.microsoft.com

다음 명령어를 통해 활성화 해준다.

# 윈도우 서브시스템 활성화
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

# 가상머신 플랫폼 활성화
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

이후 변경사항을 적용하기 위해 꼭 재부팅이 필요하다.

2.2. WSL 2 설치

이전 windows 10 까지는 wsl_update_x64.msi legecy 를 설치하여 wsl 을 수동으로 설치할 수 있었으나, 최신 Windows 11 설정과 충돌이 나서 이런 문구가 뜰것이다.

`계속하려면 Linux용 Windows 하위 시스템 최신 버전으로 업데이트해야 합니다. 'wsl.exe --update'를 실행하여 업데이트할 수 있습니다. 자세한 내용은 https://aka.ms/wslinstall 참조하세요. Linux용 Windows 하위 시스템 설치하려면 아무 키나 누르세요. CTRL-C 누르거나 이 창을 닫아 취소하세요. 이 프롬프트는 60초 후 시간이 초과됩니다. 서버 이름이나 주소를 확인할 수 없습니다.`

이러한 문제를 해결하기 위해 microsoft 에서 최신 wsl 엔진 패키지를 배포하였다.

온라인 환경에서 아래 microsoft 공식 github 에서 wsl 설치 msixbundle 을 다운로드 한다.

https://github.com/microsoft/WSL

GitHub - microsoft/WSL: Windows Subsystem for Linux

Windows Subsystem for Linux. Contribute to microsoft/WSL development by creating an account on GitHub.

github.com

물론 wsl 빌드 파일을 포함하여 모든 설치 파일은 폐쇄망 환경에 cd나 usb 로 가져간다는 전제다.

이후 `powershell` 에서 wsl 설치 명령어를 호출한다.

Add-AppxPackage -Path "{msixbundle 실제 경로}"

`wsl -v` 하여 버전을 찍어봤을 때 정상적으로 출력되어야 한다.

2.3. Ubuntu 배포판 설치

온라인 환경에선 microsoft store 를 이용하면 되나, 오프라인 환경에서 설치하기 위해선 AppBundle 파일이 필요하다.

온라인 환경에서 microsoft 공식 wsl 문서에서 Ubuntu 22.04LTS 버전 다운로드 한다.

https://learn.microsoft.com/ko-kr/windows/wsl/install-manual#downloading-distributions

이전 버전의 WSL에 대한 수동 설치 단계

wsl install 명령을 사용하는 대신 이전 버전의 Windows에 WSL을 수동으로 설치하는 단계별 지침입니다.

learn.microsoft.com

이 `.AppxBundle` 을 `zip` 확장자로 변경하고 압축을 풀어야 한다.

압축을 푼 이후 해당 디렉토리에 들어가 `Ubuntu_2204.1.7.0_x64.appx` 를 다시 `zip` 확장자로 변경하여 압축을 풀어야 한다.

압축이 풀린 디렉토리에 들어가보면 `install.tar.gz` 파일이 있다. 이 압축 파일을 통해 Ubuntu 를 설치할 수 있다.

cmd 에서 install.tar.gz import 하는 명령어를 호출한다.

wsl --import Ubuntu-22.04 C:\WSL\Ubuntu2204 "{실제 install.tar.gz 경로}"

이후 정상적으로 설치 됐는지 확인한다.

# 설치된 wsl 버전 확인
wsl -l -v

이제 설치된 wsl (Ubuntu 환경) 에 Docker 를 설치하면 된다.

2.4. Docker engine 설치 및 구동

`docker desktop` 이 기업 라이센스가 생겨 1년에 1,000만달러 이상의 이익이 발생하는 경우 사용료를 지불해야 한다. 이러한 이유로 `docker engine` 설치 파일을 다운 받아 구동시켜야 한다. 필자의 경우 `docker desktop` 을 설치하면 안되는 상황이였다.
만약 자택이나 기업 라이센스에 걸리지 않을 경우 그냥 `docker desktop` 만 설치하면 매우 과정이 쉬워지니 이후 과정을 보지 않아도 된다.

docker 공식 문서에 따르면

https://docs.docker.com/engine/install/ubuntu/#install-from-a-package

Ubuntu

Jumpstart your client-side server applications with Docker Engine on Ubuntu. This guide details prerequisites and multiple methods to install Docker Engine on Ubuntu.

docs.docker.com

containerd.io__.deb
docker-ce__.deb
docker-ce-cli__.deb
docker-buildx-plugin__.deb
docker-compose-plugin__.deb

상기 5개의 파일을 https://download.docker.com/linux/ubuntu/dists/ 에서 다운받으면 된다고 한다.

Index of linux/ubuntu/dists/

download.docker.com

OS 별 이후 경로가 다르다. Ubuntu 의 경우 `/jammy/poll/stable/amd64/` 이다. 때문에 Docker engine 설치 공식문서에서 OS 별 경로를 잘 확인해야 한다.

이때 주의할 점은 레거시 버전도 존재하는데 버전을 어느정도는 맞춰서 설치해야 의존성 충돌이 발생하지 않는다. 필자의 경우 각 파일별 가장 최신 버전으로 맞춰 다운받았다.

이후 .deb 파일들이 있는 디렉토리 경로에서 cmd 를 열고 wsl 쉘을 열어 다음 명령어로 설치한다.

sudo dpkg -i *.deb

이후 docker 명령어를 실행해보면

`failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory` 라고 뜰 것이다.

이는 Docker engine 을 구동시키지 않았기 때문이다.

docker engine 을 구동하기 전, `systemctl` 에 등록하여 wsl 부팅시 자동으로 docker engine 이 켜지게끔 설정해야 한다.

`systemctl` 을 등록하려면 `systemd` 가 켜져있어야 하는데 wsl 은 켜져있지 않아 부팅시 켜져있게끔 설정해야 한다.

wsl 부팅시 설정을 하려면 wsl.conf 를 생성해야 한다.

cd /etc
sudo nano wsl.conf

nano 명령어로 열어 wsl 이 systemd 를 사용하게끔 지정해야 한다.

[boot]
systemd=true

이후 변경사항을 적용하기 위해 `wsl` 을 재부팅 하고 `docker` 가 자동으로 실행되게끔 `systemctl` 에 등록해야 한다.

exit # wsl 쉘에서
   
wsl --shutdown # 윈도우 cmd 에서

sudo systemctl start docker // 등록
sudo systemctl status docker // 등록 상태 확인

active 상태가 떠야 docker engine 이 정상적으로 구동되고 있다는것이다.

이제 docker 명령어가 정상적으로 호출된다.

3. 결론

폐쇄망 환경에서 windows 에 docker 를 설치하는 것은 흔치 않지만, 필자와 같은 국가사업에 투입되어 있는 분이라면 꼭 한번쯤은 경험해 봐야 하는 것 같다. 부디 필자의 경험이 부족하지만 좋은 레퍼런스가 되길 기원한다..!

[Ollama] Ollama 사용기 (2)

hand-mk — Thu, 1 Jan 2026 21:17:22 +0900

* 운영 서버 스펙: Cent OS7, RAM: 16GB, GPU X
* Python: v3.13
* Flask: 3.1.0
* Langchain: 0.3.25
* ollama: 0.4.8

1. 서론

이전 포스팅: https://hand-mk.tistory.com/19

[Ollama] Ollama 사용기 (1)

* OS: Windows 11 pro* RAM: 64GB* CPU: Intel(R) Core(TM) i7-14700* GPU: 내장 그래픽 1. 서론회사 백오피스 서비스 개발에서 항공 전문에 대한 AI 해석 및 요약 기능 구현 담당을 맡았다..!내 주전공은 데이터 사이

hand-mk.tistory.com

회사 백오피스 서비스 개발에서 항공 전문에 대한 AI 해석 및 요약 기능 구현 담당을 맡았다. 항공 전문을 AI 가 이해하기 쉽게 한국어로 해석하고 요약하는데 있어, 가장 어려운 점은 AI 가 항공 전문에서 사용하는 코드(ICAO 공항 코드, 날씨코드 등) 를 모른다는 것이다. 물론 OpenAPI 나 Gemini 클라우드 환경에서 전문넣고 해석해 달라고 하면 웹 전반을 RAG 화 하여 사용하기 때문에 성능이 괜찮지만, 본 AI 모델은 온프레미스 서버에 설치하고 사용해야 하기 때문에 어려움을 겪었다. 그래서 필자가 생각한 방법은 어느정도 해석에 필요한 핵심 단어들을 전처리하고 이를 Ollama 모델을 통해 문장화 시키는 방식이다.

어찌저찌 ICAO, 항공기상업무지침 pdf 등 디코딩 문서를 확인하여 파서 로직을 구현하여 이제 RESTful 하게 만드는 단계이다. 이에 대해 기술한 내용이다.

2. 본론

기본적으로 사용자 > `Python (Flask)` > `AI (Ollama)` > 의 파이프라인으로 구성하였다. Flask 에서 AI 요청 및 응답을 받기 위해선 Ollama 를 Docker Container 으로 구동시켜야 한다.

2.1. 운영 서버 Ollama Docker Container 구동

Docker Image 는 Docker Hub 공식 이미지를 사용하였다.

https://hub.docker.com/r/ollama/ollama

ollama/ollama - Docker Image

hub.docker.com

docker-compose.yml

services:
    ollama:
        volumes:
            - ollama:/root/.ollama
        ports:
            - 11434:11434
        container_name: ollama
        image: ollama/ollama
volumes:
    ollama:
        external: true
        name: ollama

2.2. Python 에서 Ollama 호출

ollama 는 python 과의 통합사용을 적극 장려하고 있어, 관련 패키지를 공유하고 있고 이에 대한 내용은 공식 organization 에서 확인 가능하다.

https://github.com/ollama/ollama-python

GitHub - ollama/ollama-python: Ollama Python library

Ollama Python library. Contribute to ollama/ollama-python development by creating an account on GitHub.

github.com

Python 에서 Ollama 서버를 호출하고 제어하려면 `ollama`, `ollama-langchain` 패키지를 설치해야 한다.

pip install langchain-ollama

pip install ollama

이후 인스턴스를 생성하여 제어 및 호출이 가능하다.

from langchain_ollama import OllamaLLM

llm = OllamaLLM(model="exaone3.5:7.8b",
                base_url="http://ollama:11434" # 동일 Docker network 상에서 구동될 예정
)

공식문서 상에서는 ollama 패키지의 `chat` 을 통해 생성했다.

from ollama import chat
from ollama import ChatResponse

response: ChatResponse = chat(model='gemma3', messages=[
  {
    'role': 'user',
    'content': 'Why is the sky blue?',
  },
])
print(response['message']['content'])
# or access fields directly from the response object
print(response.message.content)

이 방법도 '가능' 하다. 하지만 프롬프트나 vectorDB 를 chain 형식으로 묶어 호출하지 못하고 직접 개발자가 구현해야 한다.

비행계획서 (FPL) 전문에 대한 질문 프롬프트를 다음과 같이 작성했을 때

FPL_TEMPLATE =  """
아래는 ICAO 비행계획서 최초 제출 시 전문에 들어간 정보야.
콜사인 : {aircraft_id},
비행 일자 : {flight_date},            
출발 공항 : {departure_airport},
출발 예정 시간 : {departure_time},
도착 공항 : {arrival_airport},
도착 예정 시간 : {arrival_time},
대체 공항 : {alternate_airport},
출발 공항 부터 도착 공항까지 소요 시간 : {duration_time},
비행 경로 : {flight_route},
비행 종류 : {flight_method}

'{flight_date}, {departure_airport}에서 {arrival_airport}으로 운행 예정인 {aircraft_id}편은 {flight_method}으로, 출발 예정 시각은 {departure_time}이고, 도착 예정 시각은 {arrival_time}이며, 비행 경로는 {flight_route}이고, 대체 공항은 {alternate_airport}로 지정 돼 있습니다.'
위 정보들만 전부 사용해서 최초 제출 비행 계획서를 위 예시대로 한국어로 한문장으로 요약해줘.
경로는 누락되면 안돼.
"""

`langchain` 을 사용할 경우 템플릿에 변수를 자동으로 넣은 다음, `|` 로 추가하여 응답을 요청하면 된다.

# 전문 전처리 함수
result = fpl_split(code)

summary_template = FPL_TEMPLATE
summary_kwargs = {
    "aircraft_id": result.get("aircraft_id", ""),
    "flight_date": result.get("flight_date", ""),
    "departure_airport": result.get("departure_airport", ""),
    "departure_time": result.get("departure_time", ""),
    "arrival_airport": result.get("arrival_airport", ""),
    "arrival_time": result.get("arrival_time", ""),
    "alternate_airport": result.get("alternate_airport", ""),
    "duration_time": result.get("duration", ""),
    "flight_route": result.get("flight_route", ""),
    "flight_method": result.get("flight_method", ""),
}

# 프롬프트에 자동으로 변수 기입
prompt = ChatPromptTemplate.from_template(
        summary_template
    )
    
chain = prompt | llm # 프롬프트 체이닝
response = chain.invoke(summary_kwargs)

만약 `chat` 으로 생성할 경우에는 변수를 직접 지정하고, 응답 결과에 대해서 포맷팅 또한 이후 전처리 과정을 추가해야 한다.

# 사용자가 직접 문자열을 조립해야 함
formatted_prompt = summary_template.format(
    aircraft_id=data['id'], 
    flight_route=data['route'],
    ... # 모든 변수를 일일이 나열
)
ollama.chat(messages=[{'role': 'user', 'content': formatted_prompt}])

# 이후 '네 요약해드리겠습니다.' 와 같은 불필요한 응답 값 전처리 해야함.

모델 인스턴스를 기반으로 전문 전처리 함수를 호출 > 해석에 필요한 전처리 함수로 AI 해석 및 요약 전체 코드이다.

def fpl_llm(code: str):
    print("[fpl_llm] model called!")

    content = fpl_extract_message(code)

    message_type = extract_message_type(content)

    print(f"[fpl_llm] message type : {message_type}")
	
    # 비행 계획서
    if message_type == "FPL":
        result = fpl_split(code)
        summary_template = FPL_TEMPLATE
        summary_kwargs = {
            "aircraft_id": result.get("aircraft_id", ""),
            "flight_date": result.get("flight_date", ""),
            "departure_airport": result.get("departure_airport", ""),
            "departure_time": result.get("departure_time", ""),
            "arrival_airport": result.get("arrival_airport", ""),
            "arrival_time": result.get("arrival_time", ""),
            "alternate_airport": result.get("alternate_airport", ""),
            "duration_time": result.get("duration", ""),
            "flight_route": result.get("flight_route", ""),
            "flight_method": result.get("flight_method", ""),
        }
        
    # 일정 변경 계획서    
    elif message_type == "CHG":
        result = chg_split(code)
        summary_template = CHG_TEMPLATE
        summary_kwargs = {
            "aircraft_id": result.get("aircraft_id", ""),
            "flight_date": result.get("flight_date", ""),
            "departure_airport": result.get("departure_airport", ""),
            "departure_time": result.get("departure_time", ""),
            "arrival_airport": result.get("arrival_airport", ""),
            "changed_callsign": result.get("changed_callsign", ""),
            "changed_flight_method": result.get("changed_flight_method", ""),
            "changed_flight_num": result.get("changed_flight_num", ""),
            "changed_flight_equip": result.get("changed_flight_equip", ""),
            "changed_dep_airport": result.get("changed_dep_airport", ""),
            "changed_dep_time": result.get("changed_dep_time", ""),
            "changed_route": result.get("changed_route", ""),
            "changed_alternative_airport": result.get("changed_alternative_airport", ""),
            "changed_arr_airport": result.get("changed_arr_airport", ""),
            "changed_arr_time": result.get("changed_arr_time", ""),
            "changed_dof": result.get("changed_dof", "")
        }
        
    # 지연 계획서    
    elif message_type == "DLA":
        result = dla_split(code)
        summary_template = DLA_TEMPLATE
        summary_kwargs = {
            "flight_date": result.get("flight_date", ""),
            "aircraft_id": result.get("aircraft_id", ""),
            "departure_airport": result.get("departure_airport", ""),
            "arrival_airport": result.get("arrival_airport", ""),
            "changed_time": result.get("changed_time", ""),
        }
    # 취소 계획서    
    elif message_type == "CNL":
        result = cnl_split(code)
        summary_template = CNL_TEMPLATE
        summary_kwargs = {
            "flight_date": result.get("flight_date", ""),
            "aircraft_id": result.get("aircraft_id", ""),
            "departure_airport": result.get("departure_airport", ""),
            "arrival_airport": result.get("arrival_airport", ""),
            "departure_time": result.get("departure_time", ""),
        }
        
    # 출발 계획서    
    elif message_type == "DEP":
        result = dep_split(code)
        summary_template = DEP_TEMPLATE
        summary_kwargs = {
            "flight_date": result.get("flight_date", ""),
            "aircraft_id": result.get("aircraft_id", ""),
            "departure_airport": result.get("departure_airport", ""),
            "arrival_airport": result.get("arrival_airport", ""),
            "departure_time": result.get("departure_time", ""),
        }
        
    # 도착 계획서    
    else:
        result = arr_split(code)
        summary_template = ARR_TEMPLATE
        summary_kwargs = {
            "aircraft_id": result.get("aircraft_id", ""),
            "departure_time": result.get("departure_time", ""),
            "departure_airport": result.get("departure_airport", ""),
            "arrival_airport": result.get("arrival_airport", ""),
            "arrive_time": result.get("arrive_time", ""),
        }

    print(f"[fpl_llm] result : {result}")

    prompt = ChatPromptTemplate.from_template(
        summary_template
    )

    chain = prompt | llm
    response = chain.invoke(summary_kwargs)
	
    # 응답 값 DB 저장
    try:
        orm = SessionLocal()
        new_fpl_rst = FplAiResult(code, response)
        orm.add(new_fpl_rst)
        orm.commit()
        print(f"[fpl_llm] saved result successfully!")
    except Exception as e:
        orm.rollback()
        print(f"[fpl_llm] fail to save result! cause : {str(e)}")
    finally:
        orm.close()

    return success_response(response)

이 `fpl_llm` 을 /fpl 엔드포인트에서 호출되게끔 flask 라우터를 설정하여 Ollama 를 호출 할 수 있게 하였다.

이하 항공 고시보 (Notam), 날씨 (Metar, Taf) 또한 동일한 파이프라인으로 구성하였다.

fpl_model = api.model('FplModel', {
    'fpl': fields.String(required=True, description='Fpl Contents'),
})
@api.route("/fpl")
class Fpl(Resource):
    @api.expect(fpl_model)
    def post(self):
        body = request.get_json()
        code = body.get("fpl")

        return fpl_llm(code)

배포 서버(CentOS 7) 기준 응답 테스트시 다음과 같이 속도가 나왔다. 회사 선배들을 대상으로 실제 단위 테스트에서 100개의 전문을 테스트 했을 때 약 65개의 응답에 대해 100% 해석 만족도가 있다고 답변했고, 나머지 응답에 대해서 약간의 이상치(한국어랑 영어 섞임)가 보였다.

[GIN] 2025/05/26 - 03:00:55 | 200 | 58.96749926s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/05/26 - 04:57:22 | 200 | 37.214435283s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/05/26 - 05:00:29 | 200 | 19.606718973s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/05/26 - 05:11:35 | 200 | 12.929574367s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/05/26 - 05:01:36 | 200 | 12.077014236s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/05/26 - 05:03:29 | 200 | 10.600447629s | 172.21.0.7 | POST "/api/generate"

김포공항 -> kim포공항이라고 답변

2.3. vectorDB 화

단위 테스트를 했더니 필자가 그냥 비슷한 전문을 계속 넣었을 때랑 부끄러울 정도로 응답 속도 차이가 많이 났다..! 중간에 뻗어버리는 경우도 생겼다. 무엇이 문제였을까 곰곰히 생각해보다가, 필자의 디코딩이 문제였지 않았나 생각이 들었다.

이전에는 ICAO 공항코드, 날씨(구름양, 강수량등) 코드와 같은 룩업 데이터를 txt 파일에 수집하였다. 이를 파싱시 line 으로 읽어 한국 라벨값을 찾는 방식이였다.

이전방식

airport_codes.txt (ICAO 공항코드) 약 5100개

LECO: 아코루냐 공항
EKYT: 올보르 공항
EKAH: 오르후스 공항
BGAA: 아시아앗 공항
HAJM: 아바 세구드 공항
HADR: 아바 테나 데자즈마흐 일마 국제공항
OIAA: 아바단 공항
NGAB: 아바이앙 공항
UNAA: 아바칸 공항
CYXX: 애버츠퍼드 국제공항
DAOB: 압델하피드 부수프 부 체키프 공항
RKRR: 인천비행정보구역
WARA: 압둘 라흐만 살레 공항
HCMR: 압둘라히 유수프 국제공항
FTTC: 아베셰 공항
HTZA: 아베이드 아마니 카루메 국제공항
MUSC: 아벨 산타마리아 공항
NGTB: 아베마마 아톨 공항
EGPD: 애버딘 국제공항
KABR: 애버딘 지역 공항
OEAB: 아바 공항
KABI: 애빌린 지역 공항
MMCS: 아브라함 곤잘레스 국제 공항
KSPI: 에이브러햄 링컨 캐피털 공항
LIBP: 아브루초 공항
OMAA: 아부다비 국제공항
OIBA: 아부무사 공항
HEBL: 아부심벨 공항
KARA: 아카디아나 지역공항
SKAD: 아칸디 알시데스 페르난데스 공항
MMAA: 아카풀코 알바레스 국제공항
DGAA: 아크라 코토카 국제공항
WAHS: 아흐마드 야니 국제공항

def lookup_code(key, file):
    with open(file, encoding="UTF-8") as f:
        for line in f:
            if line.startswith(f"{key}:"):
                print(f"[lookup_code] found code! : {key}")
                return line.split(":", 1)[1].strip()
        print(f"[lookup_code] not found code! : {key}")
        return None

공항코드 일부분만 발취하였으나, 얼추 세어보니 전문 해석용 룩업 데이터가 모두 취합시 약 7만건 정도 됐다.

이들을 모두 vectorDB 화 하여, 전문 타입별로 해석시 임베딩 하는 방법으로 변경해 보았다.

공항 ICAO 코드 vectorDB화 (2분 46초 소요)

import os
from langchain_community.document_loaders import TextLoader
from langchain_core.documents import Document
from langchain_ollama import OllamaEmbeddings
from langchain_chroma import Chroma

def create_airport_vectordb():
    # 데이터 로드 (airport_codes.txt)
    file_path = "airport_codes.txt"
    documents = []
    
    with open(file_path, "r", encoding="UTF-8") as f:
        for line in f:
            if ":" in line:
                code, name = line.split(":", 1)
                # 텍스트는 공항 이름으로, 메타데이터에 코드를 저장
                doc = Document(
                    page_content=f"{code.strip()}: {name.strip()}",
                    metadata={"code": code.strip(), "name": name.strip()}
                )
                documents.append(doc)

    # 임베딩 모델 설정 (Ollama 사용)
    embeddings = OllamaEmbeddings(model="mxbai-embed-large")

    # VectorDB 생성 및 로컬 저장
    vector_db = Chroma.from_documents(
        documents=documents,
        embedding=embeddings,
        persist_directory="./airport_db" # 로컬 폴더에 DB 저장
    )
    print("Airport VectorDB 구축 완료!")
    return vector_db

기존의 라인으로 읽던 방식을 생성한 vectorDB 기반으로 데이터 값을 추론할 수 있게끔 하여, AI 에게 던져준다.

def lookup_airport(code):
    
    # 기존의 파일 읽기 방식(lookup_code)을 VectorDB 방식으로 대체 
    # VectorDB에서 유사도 기반 검색
    results = vector_db.similarity_search(code, k=1)
    
    if results:
        # 검색된 결과의 메타데이터에서 공항명을 반환
        return results[0].metadata["name"]
    
    return code # 못 찾으면 원래 코드라도 반환

테스트 했을 때 확실히 응답 속도에서 향상된 모습을 확인 할 수 있었다.

[GIN] 2025/06/25 - 14:22:15 | 200 | 15.423s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/06/25 - 14:25:42 | 200 | 12.112s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/06/25 - 14:30:08 | 200 | 9.876s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/06/25 - 14:35:12 | 200 | 8.543s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/06/25 - 14:42:55 | 200 | 7.210s | 172.21.0.7 | POST "/api/generate"
[GIN] 2025/06/25 - 14:50:33 | 200 | 6.836s | 172.21.0.7 | POST "/api/generate"

3. 아쉬운 점

첫번째 아쉬운 점은 파인튜닝을 못해본 것이다.

원래 LLM 모델을 로컬에 받아서 파인튜닝을 하고 싶었지만, 그렇게 하려면 {전문: 해석결과} 의 데이터셋이 필요하다. 이 데이터셋이 없을까? 없다... 왜냐면 전문을 한국어 자연어 문장으로 보는 경우가 생각보다 많지 않다.

보통은 이렇게 문단별로 중요 키워드의 값을 본다. 그래서 문장화 하기 위한 전처리 과정이 오래 걸려 파인튜닝을 못해본 것이 아쉽다.

두번째는 데이터가 많이 없다. 물론 전문은 맘만 먹으면 수집 모듈을 만들어서(한국 한정) DB 에 쌓아둘 수 있을 것 같다. 문제는 해석 한국어 라벨링 데이터이다. 항공 도메인은 보안상의 문제로 폐쇄적이여서 항적, 항로와 같은 특정 데이터는 구매해서 사용해야 한다. 그렇기 때문에 한국어로 해석을 한다? 문제를 풀고 답이 맞는지 검사를 해야 하는데 정답지가 부족하다.

다음에 또 AI 를 다룰 수 있는 기회가 생긴다면 그땐 더 딥하고 재밌는 튜닝을 해보고 싶다.

[GitLab] Windows 11 GitLab 연동

hand-mk — Thu, 1 Jan 2026 15:46:42 +0900

1. 서론

학부생 때는 `Github` 로만 프로젝트를 업로드하고 관리해서 몰랐는데, 실제 회사에 가보니 보안을 위해 GitLab 을 온프레미스 서버에 설치하여 사내망에서 관리하였다. 이를 위해 GitLab 연동이 필요했고, 온프레미스 환경 뿐 아니라 클라우드 GitLab 에서도 동일하게 적용 가능하여 `ssh key` 로 인증 및 연동하는 방법에 대해 기술한 내용이다.

2. 본론

2.1. SSH Key 생성

공개키 (Public Key) 와 개인키 (Private Key) 쌍을 생성해야 한다. 과거에는 윈도우에 기본 SSH 도구가 없어서 `Git Bash` 를 사용하곤 했으나 윈도우 10 이상부터는 그냥 PowerShell 에서도 `ssh-keygen` 명령어 사용이 가능하다.

ssh 키 값은 \Users\{사용자 명}\.ssh 경로에 생성된다. .pub 확장자 파일이 공개키, 없는것이 개인키이다.

2.2. 공개키 GitLab 등록

공개키를 메모장 or VSCode 로 열어 복사 후

GitLab 홈페이지 > Edit Profile

좌측 탭에 SSH KEY 클릭

`Add new key` 클릭하여 복사한 공개키 삽입

이제 로컬에서 GitLab 레포지토리를 클론할 수 있다.

2.3. GitLab 레포지토리 클론

프로젝트에 `Code` 버튼을 누르면 다음과 같은 박스가 뜨고, 이때 `Clone with SSH` 를 사용해야 한다.

원하는 디렉토리 경로 cmd 에서 다음과 같은 명령어를 호출한다.

git clone {복사한 SSH}

Key 등록 후 처음 Clone 시 다음과 같은 질문이 나올 수 있다. yes 로 환대해주면 된다.

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

모든 프로세스가 끝나면 정상적으로 Clone 이 되어 있다.

remote: Total 83 (delta 0), reused 0 (delta 0), pack-reused 83 (from 1)
Receiving objects: 100% (83/83), 11.53 MiB | 5.20 MiB/s, done.
Resolving deltas: 100% (4/4), done.

[Ollama] Ollama 사용기 (1)

hand-mk — Mon, 29 Dec 2025 17:26:19 +0900

* OS: Windows 11 pro
* RAM: 64GB
* CPU: Intel(R) Core(TM) i7-14700
* GPU: 내장 그래픽

1. 서론

회사 백오피스 서비스 개발에서 항공 전문에 대한 AI 해석 및 요약 기능 구현 담당을 맡았다..!

내 주전공은 데이터 사이언스이기는... 하나.. 주로 데이터 분석을 공부하였고, 모델을 만들어본건 랜덤 포레스트 같이 기본적인 알고리즘을 사용한 지도 학습 머신러닝 정도가 학부생 때 지식의 끝이다.. 멘토님께서 나를 너무 전적으로 신뢰하셔서 '이것도 먹어봐' 주셨으니 너무 감사한 일이지만 막막했다. 그러던 중 Ollama 를 발견하였고, 이를 활용해 요구사항을 충족하는데 성공했고 꽤 만족스러운 결과물이 나왔다. 이에 대해 기술한 내용이다.

2. 본론

상기 요구사항 캡쳐본을 보면 알다시피, 항공 전문을 해석하고 요약해야 한다.

선택지는 4가지가 있었고 2개월 내로 다른 기능들과 같이 구현하기 위해선 Ollama 가 적합하다고 판단했다.

1. OpenAI 와 같은 AI API 를 사용하여 해석 및 요약시키기. (제일쉬움, but 유료)

2. 항공 전문 해석 AI 찾아서 사용하기. (없거나 회사에서 오픈소스로 공유 안함)

3. 생성형 AI 모델을 받아 직접 파인튜닝하기. (지식 및 시간 부족)

4. Ollama 를 받아 전처리 후 요약 시키고 나온 데이터들을 기반으로 RAG 적용

2.1. Ollama 설치

직접 설치 파일을 받아서 설치 할 수도 있고,

https://ollama.com/download

Download Ollama on macOS

Download Ollama for macOS

ollama.com

Docker Image 를 받아 컨테이너로 구동시킬 수도 있다.

https://hub.docker.com/r/ollama/ollama

ollama/ollama - Docker Image

hub.docker.com

2.2. Ollama 모델

https://ollama.com/library

library

Browse Ollama's library of models.

ollama.com

Ollama 에 올라와 있는 모델을 Docker 이미지 받는것처럼 받아서 사용하는 형태이다. 모델을 설명하는 상세페이지에 들어가보면 스펙이 기재되어 있는데, 이때 size 는 해당 모델을 구동시키기 위해 최소로 요구하는 RAM 용량이다.

모델을 불러오고 사용하는 방법은 다음과 같다. Docker 사용 명령어와 유사하여 사용하기 편리하다.

# 모델 로컬 저장
ollama pull {모델명}

# 모델 구동
ollama run {모델명}

모델을 구동시키면, 우리가 흔히 GUI 로 AI 와 소통하던 모습을 CLI 에서 할 수 있다.

단순 호출 테스트 해본 모델은 총 4개 (phi4, lamma3, lamma4, exaone) 이다.

공통적으로 4개 모델 모두 클라우드 모델이 아닌 로컬에 설치된 모델이기 때문에, 답변 속도의 차이와 RAM 점유율의 차이만 있었을 뿐 해석 내용이 원문과 거의 일치하지 않았다.

특히 그당시 성능이 좋다던 llama 4 의 경우 RAM 점유율이 높아 64GB 을 사용하는 나의 개발 컴도 원문 하나를 넣으면 답변을 듣는데까지 1분이나 소요됐다.

어짜피 학습이 어렵고, 전처리를 기반으로 한 데이터로 해석하는 걸 요청할 꺼라면 한국어에 특화되고 가벼운 모델을 사용하는것이 적합해 보였다. 그래서 선택한 모델이 exaone3.5 이다. exaone3.5 는 LG 에서 llama 를 한국어 특화되게 만든 모델이다. 가동을 위한 최소 메모리도 8GB 이고, 디스크 용량도 4GB 정도 밖에 소모 되지 않아, 경량 모델이다. 해당 요구사항을 충족하기엔 충분한 스펙이라고 생각하였고 어짜피 추후에 RAG Vector DB 를 도입할 예정이라 이 모델을 선택하게 되었다.

2.3. LLM 엔진 메모리 관리 전략 + 캐싱 메커니즘

호출 테스트 해보다가 특이한 점을 발견했다.

docker image 로 띄운 ollama container 로그를 찍어보면 응답을 하는데까지 걸린 시간들을 표출해준다.

비교적 길게 소요된 응답은 '첫번째 호출' 이고 비교적 짧게 소요된 응답은 'n번째 호출' 이다. 즉, 여러번 호출할 수록 응답 속도가 빨라진다.

가장 처음 실행할 때 시간이 오래 걸리는 이유는 모델 가중치(Weights)를 디스크에서 RAM으로 올리는 과정 때문이다. 처음 호출하게 되면 다음과 같은 과정을 거치게 된다.

Ollama는 사용자의 요청이 들어오면 비로소 ~/.ollama/models에 있는 수 GB의 GGUF 파일 (모델의 수십억 개 파라미터가 저장되는 공간) 을 읽는다.
GGUF 파일 (전체 모델 데이터) 를 RAM에 상주시킨다.
- 매번 호출때마다 Disk 에서 가져오면 속도가 너무 느림.
신경망 그래프를 구성(이전 대화 및 프롬프트 기억 공간 미리 RAM 확보).

n번째 호출에선 신경망 그래프 구성 중 생성된 KV Cache (이전 대화 및 프롬프트 기억 공간) 와 앞선 RAM 할당으로 인해 응답 식속도가 현저히 줄게 되는 것이다. 다만, 항상 RAM 에 할당 해두면 리소스를 너무 많이 먹기 때문에 5분 동안만 RAM 에 할당한다.

그렇기 때문에 실제 운영 또는 사용 시 리소스 여유가 있다면 항상 상주하게 하거나, polling 방식으로 RAM 에 불러와야 한다.

3. 참고자료

ollama: https://ollama.com/library

ollama 메모리 관리 전략: https://ollama.com/blog/multimodal-models

[Python] KoNLPy 자연어 형태소 분석

hand-mk — Mon, 29 Dec 2025 14:38:11 +0900

* Python: v3.13
* 개발 환경 OS: Windows 11 Pro
* 운영 환경 OS: CentOS 7

1. 서론

회사 백오피스 서비스 개발에서 뉴스기사 크롤링 모듈 개발을 담당 하였다. 이와 연관지어 대시보드 페이지에 수집한 기사들의 키워드를 워드클라우드로 표출해야 하는 요구사항이 있다. 요구사항을 충족하기 위해선 뉴스 기사의 단어 빈도수를 분석하고 빈도수 기준 워드클라우드를 표출해야 한다. 자연어 문장에서 단어를 추출하는 로직을 직접 구현하는 것은 생각보다 복잡한 일이다. 한국어의 모든 조사, 부사 등을 갖고 있어야 하고 문장의 모든 배치 케이스를 적용해야 한다. 하지만 Python 에는 이를 직접 구현하지 않고 단어만 이쁘게 추출해주는 패키지 KoNLPy 가 존재한다. 이에 대해 기술한 내용이다.

2. 본론

KoNLPy는 한국어 정보처리를 위한 파이썬 패키지이다. 해당 패키지를 통해 한국어 자연어 문장에서 문장 또는 단어를 추출할 수 있다.

다음은 공식문서의 예시이다.

>>> from konlpy.tag import Kkma
>>> from konlpy.utils import pprint
>>> kkma = Kkma()
>>> pprint(kkma.sentences(u'네, 안녕하세요. 반갑습니다.'))
[네, 안녕하세요..,
 반갑습니다.]
>>> pprint(kkma.nouns(u'질문이나 건의사항은 깃헙 이슈 트래커에 남겨주세요.'))
[질문,
 건의,
 건의사항,
 사항,
 깃헙,
 이슈,
 트래커]
>>> pprint(kkma.pos(u'오류보고는 실행환경, 에러메세지와함께 설명을 최대한상세히!^^'))
[(오류, NNG),
 (보고, NNG),
 (는, JX),
 (실행, NNG),
 (환경, NNG),
 (,, SP),
 (에러, NNG),
 (메세지, NNG),
 (와, JKM),
 (함께, MAG),
 (설명, NNG),
 (을, JKO),
 (최대한, NNG),
 (상세히, MAG),
 (!, SF),
 (^^, EMO)]

2.1. 패키지 설치

필자의 경우 개발환경 OS 는 Windows 11 pro, 운영환경 OS 는 CentOS 7 이다.

공식문서에 기재되어 있다시피, Windows 환경에서는 로컬에 JDK 1.7 이상이 설치되어 있어야 한다. KoNLPy는 독자적인 형태소 분석 알고리즘을 파이썬으로 직접 구현한 것이 아니다. 이미 Java 로 아주 잘 만들어진 기존의 형태소 분석기들을 파이썬에서 편하게 쓸 수 있도록 묶어 놓은 Wrapper 라이브러리 이다. 즉, KoNLPy 를 구동시키려면 JVM 이 있어야 한다.

2.1.1. JDK 설치 및 환경변수 설정

필자의 경우 Oracle jdk 17 을 설치하였다.

https://www.oracle.com/java/technologies/javase/jdk17-archive-downloads.html

Java Archive Downloads - Java SE 17.0.12 and earlier

WARNING: Older versions of the JDK are provided to help developers debug issues in older systems. They are not updated with the latest security patches and are not recommended for use in production. For production use Oracle recommends downloading the late

www.oracle.com

아마 JDK 를 직접 설치 해야 하는 경우는 Windows 환경에서만 적용되기 때문에, 밑에 Windows x64 Installer 를 다운 받는다.

해당 exe 파일을 실행시켜 jdk 를 설치한다. 설치 중 설치 경로를 변경 할 수 있지만 보통 "C:\Program Files\" 에 설치한다.

이후 jdk 환경 변수를 지정해야 한다. windows 검색 > 시스템 환경 변수 편집 을 연다.

시스템 속성 > 고급 탭 > 하단 환경변수 버튼 클릭

시스템 변수 새로 만들기

JAVA_HOME 변수에 변수 값은 실제 다운받은 jdk 경로를 기입해야 한다.

이후 시스템 변수 중 Path 를 찾아 편집 버튼을 클릭

아래 두 경로를 추가

이후 제대로 적용 됐는지 확인을 위해 cmd 에서 java version 을 찍어본다. 정상적으로 출력되면 문제없다.

만약 Python 프로젝트 실행시 다음과 같은 에러 문구가 발생하면 java 환경변수를 잘못 지정했거나, 적용이 안된것이다.

jpype._jvmfinder.JVMNotFoundException: No JVM shared library file (jvm.dll) found. Try setting up the JAVA_HOME environment variable properly.

환경 변수 지정 후 IDE 를 껐다 키거나, 시스템 재부팅 하여 변경사항을 적용해야 정상적으로 작동한다.

2.1.2. jpype 설치

앞서 기술했던 것처럼 KoNLPy 는 JVM 을 기반으로 구동된다. 그렇기 때문에 Python 에서 JVM 이 동작할 수 있게끔 해야 한다.

이를 가능하게 해주는 것이 jpype 이다.

Jpype는 Python 프로세스 내에 JVM(Java Virtual Machine)을 임베딩하여 파이썬이 자바 라이브러리를 직접 호출할 수 있게 해주는 Bridge 역할의 라이브러리이다. 실제로 KoNLPy 에서도 설치를 권장하고 있다.

명령어를 통해 JPype 를 설치 할 수도 있으나, 간혹 Windows 환경에서 실패하는 경우가 있다.

pip install JPype1

실패하는 경우 직접 릴리즈 패키징 파일을 github 에서 다운받을 수도 있다.

https://github.com/cgohlke/win_arm64-wheels/releases/tag/v2025.7.7

Release v2025.7.7 · cgohlke/win_arm64-wheels

Experimental Wheels for Python for Windows on ARM64 Notes 140 packages for Python 3.13 for Windows on ARM64 Updates the v2025.3.31 release Wheels Binary wheels for the following packages for Pyth...

github.com

필자의 경우 Python v3.13 을 사용하기 때문에, jpype1-1.5.2-cp313-cp313-win_amd64 을 다운받았다.

로컬에 해당 파일을 직접 다운받았다고 하면 꼭 pip 로 설치과정이 필요하다.

pip install jpype1-1.5.2-cp313-cp313-win_amd64.whl

이제 KoNLPy 를 사용할 사전 준비가 끝났다.

2.2. 모듈 선택

일전에 기술했다시피, KoNLPy 은 여러 형태소 분석기(Hannanum, Kkma, Komoran, Mecab, Okt) 들을 한데 모아둔 패키지이다.

공식문서를 보면 각 모듈별 처리 성능을 기재해 두었고, 본인에게 필요한 모듈을 인스턴스하여 사용하면 된다.

속도로만 봤을 때, Mecab 이 좀 더 성능이 좋아보이긴 하나, 자연어에 대한 형태소 분석 정확도에선 Okt 가 더 좋아보였다.

이러한 이유로 필자는 Okt 를 사용하였다.

2.3. 사용 방법

KoNLPy 공문서에서 친절하게 워드 클라우드에 대한 예제도 있어 어렵지 않게 구현이 가능하다.

https://konlpy.org/ko/latest/examples/wordcloud/

예제에선 Hannanum 을 사용하였으나, 필자의 Okt 로 인스턴스를 생성하면 다음과 같다.

# 인스턴스 생성
okt = Okt()

명사를 추출하고 싶을 때 nouns 함수를 호출하면 된다.

# 명사만 추출
noun_results = okt.nouns(contents)

명사만 추출함에도 불구하고 길이 1짜리 조사들이나, 불용 목록으로 기재되지 않아 걸러지지 않는 단어들이 있다.

곳
며
점
선
더
층
내
칼
위
명
개

이를 위해, 불용어 리스트를 추가하였고 추출한 명사들 중 해당 불용어 리스트에 있는 단어는 제거하는 전처리 과정을 추가했다.

https://gist.github.com/spikeekips/40eea22ef4a89f629abd87eed535ac6a

Korean Stopwords

Korean Stopwords. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

 # 불용어 및 길이 1개인 조사 제거
final_results = [n for n in noun_results if n not in STOPWORDS and len(n) > 1]

결국 단어의 빈도수를 구하고, chart js 의 워드클라우드를 생성하기 위해선 {key: value} 형태로 데이터를 던져줘야 한다.

불용어 처리까지 끝난 단어 리스트에 Pandas 라이브러리를 사용하여 한 단어당 빈도수를 구하고 상위 100개만 추출하였다.

words_frequency = pd.Series(final_results).value_counts().head(100)

형태소 빈도수 분석 결과 값을 그대로 chart js 워드클라우드를 사용하여 띄우면 다음과 같이 표출된다.

3. 참고자료

KoNLPy: https://konlpy.org/ko/latest/

Java 환경변수: https://languagestory.tistory.com/11

불용어 리스트: https://gist.github.com/spikeekips/40eea22ef4a89f629abd87eed535ac6a

chat js 워드클라우드: https://www.sgratzl.com/chartjs-chart-wordcloud/examples/