DD 님의 블로그

Openclaw의 os보안 테스트 코드에 Contribute함 (OpenSource Contribute)

m00n0107 — Sun, 8 Feb 2026 01:42:33 +0900

평소 오픈소스에 관심이 많아 관심있는 오픈소스들의 소스코드를 뜯어보고 내부 로직을 공부하는 것을 틈틈히 해왔다. 2025년에는 무조건 오픈소스의 contributor가 되리라. 라는 목표를 세웠지만 나의 시간투입이 부족해서 결국 PR한번 제대로 못넣어보고 2025년의 실패한 목표로 남겼다 ㅠㅠ 2026년에는 꼭 오픈소스에 기여하는 개발자가 되고싶다는 목표를 마음 속 깊은 곳에 담고 있었다.

그런 와중 최근 가장 핫해진 Openclaw를 접하게 되었는데, 기존의 Agent 시스템과 다르게 full Context를 온전하게 유지하면서 로컬 시스템의 executor로서 활용할 수 있다는 점에서 흥미로웠다. 각종 메시지 도구에 연동할 수 있을 뿐 아니라, 실제 권한을 부여해서 os shell, 파일 시스템의 read/write 권한까지 연동할 수 있어, 그저 질문을 주고 받는 챗봇이 아니라 진짜 '비서'로서 도움을 준다.

실제로 Openclaw가 출시되고 많은 사람들이 wow를 느꼈고, 로컬에서 Openclaw를 사용하기 위해 맥미니를 미친듯이 사대서 맥미니를 구하는게 힘들어졌다. (내 옆자리 개발자분도 Openclaw를 써보기위해서 화끈하게 m4 pro 48gb ram 맥미니를 지르셨다) 오픈소스가 이렇게 핫했던적이 있던가. 최근 04년생 한국 개발자가 개발한 OMO(oh-my-opencode)도 단시간에 엄청난 인기를 끌었지만, Openclaw는 하드웨어 판매에 일시적인 긍정적 외부효과를 줄 정도이니, 더더욱 관심이 안갈 수 없었다.

이렇게 재밌고 유용한 프로젝트인 Openclaw는 치명적인 문제가 있다. 바로 '보안 이슈'인데, 요약하자면 로컬 파일의 너무 많은 권한을 들고 있으면 Prompt Injection에 취약하다는 것이다. 자세히 읽어보진않았지만 여기저기서 실제로 개인정보 유출로 피해를 겪은 사례들을 많이 봤고, 여기저기서 업계 전문가들이 '절대 쓰지마라' 라고 하는 것도 여러번 봤다. 확실히 모든 실행 권한을 주는 것은 위험하다. 특히 민감한 환경변수나 key들을 제공하는 것은 한 번 유출되면 시스템 전체에 영향을 줄 수 있기 때문에 기업 차원에서는 더더욱 도입하기 어렵다.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

아무튼 다시 원래 이야기를 돌아와서 이렇게 말도 많고 탈도 많은 openclaw의 보안에는 어떤 이슈가 있고, openclaw의 개발 팀에서는 보안 대응을 위해 어떤 안전장치들을 마련해놨는지 훑어보고 기여하고싶어 주말에 시간을 내서 소스코드들을 claude code와 함께 분석했다.

첫번째 시도 : Issues 해결해줘

우선은 당장 github에 올라온 issue나 bug들을 해결하는 것을 첫번째 전략으로 삼았다. 최근에 올라온 다양한 issues 들을 살펴보았는데,,, 음 일단 올바른 접근 방식은 아니었다. 아무런 맥락없이 다른 사람이 발생한 버그를 단시간에 이해하려하니 어떤 내용인지도 잘 파악이 안돼고 당연하게도 해결할 수 없었다. 무작정 claude code한테 아무거나 이슈 들고와서 해결해. 라는 방식으로 시도도 해봤는데, 막 지 혼자 이것저것 핑퐁하더니 결국 아무것도 해내지 못했다. 정확히 말하면 뭔가 PR은 올렸지만, 별 이유도 알 수 없이 PR을 리뷰해주는 봇한테cancell됐다.

이후에도 여러개의 PR을 올렸었는데 리뷰는 커녕 CI 테스트부터 계속 막혔다. 특히 mac 환경이 계속 막혀있었는데, 다른 사용자들도 마찬가지로 너무 사용자가 많아 queue에 계속 걸렸다. 그래서 일단 이런 방식으로 무작정 PR만 난사하는건 좋은 방법은 아니라고 판단했다.

두번째 시도 : 클로드야, os별 보안감사 모듈 분석해줘

모든 소스코드를 읽고 openclaw의 보안 취약점이 어떤 것들이 있는지 뽑아내달라고 하면서 이것저것 핑퐁&deep dive하다보니, claude한테 의외의 답변을 들었다. "openclaw는 보안 대응이 잘 되어있고 보안감사 시스템이 완벽해요 !" 뭐 이런 내용이었다. 당연하게도 production에 실제로 활용되는 메인 로직 코드들에 보안 문제가 있을리는 없었다. 그 모든 로직들을 직접 살펴볼 수도 없고 내가 분석시킨 클로드 또한 omo의 ultrawork 모드로 빙글빙글 돌렸으니, opus 4.5를 일단 믿기로 했다.

그래서 차라리 보안 감사관련 테스트 코드를 더 뜯어보자 ! 라는 더 낮은 목표를 잡고, 전체적인 보안감사 시스템을 살펴보기 시작했다. openclaw는 os별로 보안 감사 코드와 테스트 코드들로 보안 감사가 모듈화되어 준비되어있었다. 그런데 이때 다른 os와 다르게 window 환경에서의 ACL(access control list)작업에서 테스트 스크립트가 없는 것을 발견했다(나말고 클로드가). 사실 테스트 코드를 추가하는 것 정도는 production에 의존성이 걸리는 것도 아니고, 잘 작동하기만한다면 merge하지 않을 이유가 없기 때문에 테스트 스크립트를 짜서 Pull request를 올렸다. 이미 mac에서는 올바르게 ACL test를 하는 테스트 코드들이 있었고, 윈도우 os에서 해야하는 ACL작업 또한 그에 맞춰 총 26개의 모듈 테스트 ts파일을 만들었다.

그 결과..

CI 하는 과정에서 뭔가 이슈가 있었는지 PR을 올린지 하루정도 뒤에 저렇게 comment가 달렸고, 확인한 내용을 즉각 수정해서 이것저것 다시 PR을 올렸다.

그렇게 또 하루정도가 지나고..

Openclaw의 메인테이너인 steipete가 main에 merge시켰다는 메일을 받았다 ! 아니근데.. 왜 rebase했지? 솔직히 큰 차이는 없지만 저렇게 rebase하면 PR의 author이 한 번 사라지기 때문에 내가 contributor로 안남는다는게 좀 마음에 안들었다. 물론 쟤나 나나 여러개 터미널 띄워놓고 열심히 토큰을 태워가며 Openclaw의 main branch에 코드를 반영하는 사람이지만 그래도 내가 시간 쓴 만큼 contributor로서 흔적을 남기고 싶었다.

그래서 혹시 나 Co-authored로 commit해줄 수 있어? 라고 약간 찌질하게 부탁했는데, 별 대답없이 그냥 해줬다,, ㅋㅋ

그리고 추가로 올렸던 PR중에 docs에서 plugin을 plugins라고 코드에 오타를 내서 404error를 띄우는 에러가 있었는데 그 PR도 merge해줬다.. 뭐 이건 사실 왜 틀려있는진 모르겠는데 클로드가 틀렸다니까 가서 보니 진짜 오타가 나있어서 그거 수정해주고 한 이틀 후 두번째 merge도 얼떨결에 해냈다.

이렇게 수정해달라는 comment왔는데 갑자기 1분 뒤에 쿨하게 그냥 자기가 알아서 수정해서 PR merge시켜줌...

그래서 결국 한 일주일만에 Openclaw PR #9308, #9335에 merge를 성공시키며 OpenClaw의 Contributor가 되었다 !

사실 좀 짧게 요약했지만 중간에 이런저런 이슈들이 있었다. 내가 올린 CI 상에서 테스트가 서로 deadrock이 걸려서 혹시 캔슬해줄 수 있냐,, 라고 메인테이너한테 여러번 요청하기도하고 되게 쓸데없는 PR도 여러번 올리고 했는데, 요즘은 PR 을 올리는 즉시 AI 여러개가 달라붙어서 꼼꼼하게 리뷰를 하기 때문에 쉽지만은 않은 것 같다.

솔직히 내 PR은 서비스 관점에서는 엄청나게 유의미한 dependency가 걸려있는 스크립트도 아니기도하고, 그 자체로 critical한 변경은 아닐 수 있겠지만 어찌됐건 window의 ACL test는 openclaw 사용자 입장에서 당연히 보안상 중요한 문제긴하다. 특히나 icacls 출력 파싱, 상속 권한 처리, DENY 권한 필터링 등 실제 Window의 OS 환경을 고려해야하는 설계들은 거대한 맥락 속에서 AI가 코딩하다보면 놓칠 수도 있는 것들이다. 이전같았으면 사람 대 사람이 몇 주 동안 디스커션해야하는 것들이 이제는 당연하게 AI가 코딩하고, AI가 문제점 찾고, AI가 Commit후 PR올리면, AI가 리뷰하고 코멘트 주고, AI가 merge하는게 좀 신기하다. 하지만 이제는 이게 훨씬 더 당연한 시대인거고 이런 전체적인 워크플로우에 익숙해지는 AI-Native가 중요한 것 같다는 생각이 든다.

레브잇 Product Engineer 정규직 합격 후기

m00n0107 — Thu, 25 Dec 2025 16:27:53 +0900

지난 번에 이어 2025년 겨울 하반기 일 구하기 시리즈의 두번째 이야기다.

지난번 글에서 말했다시피 이번 구직은 '필수'가 아닌 '옵션' 중 하나라고 인식하고 있었기 때문에 설령 지원한 것들이 다 떨어진다고 하더라도 잘 돌아가고 있는 내 서비스를 운영하는 것+ 고도화하면서 사업을 확장시켜보리라 생각하고 있었다.

당근마켓, KT 나스미디어, 뤼튼, 레브잇에 지원을 했고, 최종적으로 레브잇에 합류하게 된 이야기를 해보려한다.

군대에 있던 시절 즐겨보던 EO채널에서 한 영상을 보고 충격에 빠진 일이 있었다.

https://www.youtube.com/watch?v=L2sNAQYLNbA

이때 당시 강재윤 대표가 EO채널에서 본인이 사업을 시작한 이야기부터 올웨이즈를 키워내는데 겪은 시행착오들을 풀어낸 인터뷰 영상인데, 그때 당시 나는 이 영상을 보고 큰 충격을 맞았다. 막연하게 '언젠간 창업하리' 라고 생각하는 나와 다르게 본인이 열망하는 것을 이뤄내기 위해 발로 뛰어다니고 스스로를 리스크로 몰아넣는 사람이 있고, 빠르게 성장하고 있구나. 라는 생각이 들었다. 특히나 벤치마킹 하는 방식, 갈망론 과 같은 강재윤 대표가 인터뷰에서 말했던 내용은 내 개인적인 가치관과도 완전히 일치했고, 나도 언젠가 성장해서 이 사람을 꼭 만나보고싶다고 생각해고 있었다.

그렇게 시간이 흘러 다시 현재로 돌아와서 어떤 회사에서 일해볼까 알아보던 중, 이전에 관심있었던 레브잇의 채용공고를 뒤져보기 시작했었다. 예전 유튜브 영상에서 봤을 때 이후로 레브잇은 꽤 많이 성장해있었고, 내가 맡아보고 싶었던 Problem Solver 직군의 인턴 공고가 있었다. 그래서 그날 바로 이력서를 넣었었다.

1차 서류합격, 2차 과제전형까지 합격했고, 3차로 최종면접까지도 괜찮게 봤던 것 같다. 생각보다 떨려서 긴장을 많이 하긴했지만 그래도 그럭저럭 만족스럽게 면접을 봤다.

그런데 그날 집에 가던 도중 혹시 Problem Solver 인턴 직군 말고 Product Engineer 정규직군으로 지원하실 생각이 있냐는 문자를 받았다. 솔직히 약간 당황스러웠고, 면접도 한 번 더 봐야했지만 어쨌든 레브잇에서는 Problem Solver나 Product Engineer나 같은 목표를 바라보고 일하는 큰 차이 없는 직군이라고 판단해서 그렇게 마지막 면접을 준비하게 되었다.

사실 마지막 면접은 기술 면접인지 인성 면접인지 따로 아는게 없어서 그냥 크게 준비하지않았다. 엔지니어 직군인 만큼 개발 관련한 질문을 할 것이고, 그냥 내가 아는 선에서 답변해야지. 억지로 모르는거 아는 척 하지말아야지 ~ 정도만 생각하고 회사에 방문했고, 면접은 내가 생각했던 것과 다르게 컬쳐핏 + 그냥 내가 해온 프로젝트? 관련 질문들만 들어왔다. 그래서 크게 긴장할 것 없이 면접을 봤고 꽤 잘봤던 것으로 기억한다.

이번에도 면접이 끝나고 집으로 돌아가는 길에 최종적으로 합격했다는 연락을 받았다.

그렇게 나는... 레브잇의 Product Engineer 정규직으로 합류하게 되었다.

2026년 상반기 개발자 인턴/신입 지원 후기

m00n0107 — Mon, 22 Dec 2025 00:40:28 +0900

2025년 12월 21일 약간 정들었던 KMAC의 인턴 계약 기간이 종료되고, 새로운 직장을 구하게 되었다. 12월 초 정도부터 새로운 직장을 구하기위해 서류들을 이곳저곳 넣기 시작했고, 후기를 남겨보려한다.

이번 겨울 방학은 정말 하고싶은 인턴 공고만 넣고, 억지스럽게 구하지않으려했다. 그동안 매 방학마다 인턴을 쉬지않고 했다보니, 내 서비스에 온전히 투자할 시간이 부족하기도했고, 운영하던 서비스 규모를 키우거나 새로운 서비스를 런칭할 수 있는 시간도 마련해보고싶어서 꼭 인턴을 하지 않아도 괜찮은 상황이었다. 그래서 쓸 수 있을만한 곳은 여러 곳 있었지만 추리고 추려서 4개의 인턴에 지원했다. 이 네 곳이 설령 다 떨어지더라도 괜찮다는 마인드여서 조금 가볍게 썼던 것 같다.

이번에 인턴을 한다면 이커머스 혹은 마케팅 분야의 소프트웨어 개발, 엔지니어 쪽 직무를 희망해서 그쪽 계열만 알아봤고, 결과적으로 4개 중 3개는 서류합, 1개는 서류탈 했고, 최종적으로는 한 곳에 얼떨결에 정규직으로 합류하게 되었다.

가장 첫번째 지원했던 곳은 KT 나스미디어의 데이터사이언티스트 직군이다.

요즘들어 디지털 마케팅 분야, 이커머스 분야에 관심이 생겨서 그 쪽 위주로 알아봤었는데, KT의 미디어 계열사인 나스미디어는 디지털 마케팅 분야에서 1위를 달리고 있는 회사이고 학교 현장실습연계도 가능해서 지원했다. 특히나 데이터 사이언티스트 직무는 내가 가장 실무를 많이 경험해본 분야이기도하고, KMAC에서 디지털 마케팅 관련 기업의 통계분석 프로젝트에 몸을 갈아넣어본 경험이 있기 때문에 다른 누구보다도 실력에는 자신이 있어서 지원했다.

1차 서류는 통과했지만 아쉽게도 이 회사는 면접일도 맞지않았고, 필수적으로 6개월을 근무해야했으며, 알고보니 나는 학교 실습으로 학점 인정을 받을 수 없다고 해서 면접에는 못간다고 답변드렸다(면접일과 시간대가 정해져있었고, 조정이 불가능하다는 답변을 받았다. 이때 당시 KMAC에서 일하는 중이었고, 휴가를 다 썼기 때문에 시간대를 맞출 수 없었다)

두번째 지원한 곳은 당근마켓의 머신러닝 엔지니어 직군이다.

여긴 가장 가고싶었던 기업 중 하난데 거의 마감일 근처에 공고를 발견해서 이력서를 너무 급하게 만들었었다. 그러다보니 놓친 이력들도 많고 포트폴리오 정리도 잘 못해서 제출했다.. 그래서 아쉬웠고, 네임벨류도 네임벨류인만큼 서류 합이 어렵지않을까 생각했다.

역시나 결과적으로 서류에서 떨어졌다. 아직 머신러닝 엔지니어로서 역량이 부족한 것과 더불어서 이력서를 조금 더 잘 정리했으면 붙을만하지 않았을까 하는 아쉬움이 있다.

세번째 지원한 곳은 뤼튼의 에이전트 개발자 직군이다.

당근마켓에서의 서류 탈락의 교훈을 얻고 뤼튼은 조금 더 서류를 보완했다. 아무래도 시간을 더 들이니까 확실히 서류가 더 보기 좋았고, 수시채용인만큼 조금 더 시간을 넉넉하게 갖고 지원했다. 사실 뤼튼은 내가 일해보고싶던 마케팅, 커머스 분야는 아니긴하지만 it계열에서 나름 핫한 회사이기도하고, 일했었던 지인의 이야기를 들었을 때 배울 점이 많아보였기 때문에 일해볼만하다고 생각했다. 특히 개발자 직군이기 때문에 기술적으로 경험할 것이 많을 것이라고 생각했다.

1차 서류는 합격했고, 2차 과제 전형도 쉽지않았지만 통과했다.

3차는 PT 면접이었는데, 2차 과제 전형을 발표 주제로 팀 리드에게 발표를 준비하는 것 + 실무진과의 대화를 통해 기술적 역량, 인성, 컬쳐핏 등을 확인하는 면접이었다. 시간은 촉박했지만 나름 열심히 준비해갔었고, 결과물도 마음에 들었었다.

면접은 약 1시간 가량 진행되었었고, 과제 PT 뿐 아니라 지금까지 해온 프로젝트에 대한 경험, 인턴 경험 등등 여러가지를 물어봤고, 예상 못했지만 기술 질문도 들어왔었다. 파이썬 문법에 관한 질문이었는데, 가물가물하지만 fast api에 대한 질문과 비동기 처리에 관한 질문이었던 것 같고, 답변은 잘 했던 것 같다.

그렇게 면접을 마치고, 최종적으로 탈락했다는 결과를 들었다. 사실 좀 이해가 잘 안됐었다. 면접을 잘 본 것 같은데 왜 떨어졌지? 싶었는데, 지금 생각해보면 이번에 지원한 Agent Developer 는 SI 식으로 RAG 관련 프로젝트에 투입되어 하는 포지션인데, 내가 너무 기획적 역량, 주도적 역량에 대해서 강조했다는 생각이 이제 와서 든다. 뭔가 조금 더 개발 쪽 Speciality를 강조했어야했는데, 그러지 못했던 것 같다. 프로젝트 관련 질문이나 경험 관련해서 기술적인 깊이를 강조하지 않았었는데 그게 패착인 듯하다.

그리고 마지막으로 지원했던 회사가 내가 최종적으로 합격해서 일하게된 회사인데,,

다음 편에 계속

로그인의 역설

m00n0107 — Mon, 8 Dec 2025 16:45:42 +0900

오늘은 서비스를 개발하고 배포해서 실제 사용자를 유치하는 과정에서 느낀 교훈에 대해서 풀어보려한다. 로그인 기능이 주는 역설에 대해서 회고해보면서 느꼈던 두번의 실패와 해결했던 방법에 대해서 적어보겠다.

1차 실패

처음 서비스를 기획할때는 메인 기능은 5-6가지가 있었다. 기능이 적지않다보니, DB 설계, 화면 구성, 최적화까지 꽤 시간이 걸렸었고, claude sonnet 4.5를 활용해서 약 일주일 정도 투자해서 개발했었는데 아무래도 클로드 특성상 아무것도 없는 초기엔 빠르게 개발하지만, 파일이 많아지고 기능이 복잡하면 놓치는 context들이 생기기 때문에 이 과정에서 생긴 오류나 버그를 고치느라 꽤 시간이 걸렸었다.

특히 로그인 기능이 있으면 개인화된 기능을 제공할 수 있다보니 코드를 덕지덕지 붙여서 여러가지 기능을 덧붙일 수 있었다. 나도 그 유혹에 참지못하고 썩 필요하지않은 기능들을 붙여버렸고, 이에 맞춰 디자인 수정 작업이 들어가니 조금씩 원래 계획했던 것에서 벗어나기 시작했다.

처음 기획한 개발 일정은 5일정도였지만 실제 개발하고나니 일주일이 훌쩍 지나있었다. 여기서 일단 제품 개발에 있어서 1차적인 실패를 느꼈다.

2차 실패

어찌저찌 개발한 이후 도메인을 따서 배포에 성공했다. 초기 마케팅으로는 지인들에게 뿌리기 + 커뮤니티 바이럴을 진행했다. 제품을 초기에 검증하고 PMF를 찾아가는 단계에서 마케팅에 비용을 쓰는 것은 적절하지 않다고 판단했기 때문이다.

그 결과 초기에는 유입 수, 노출 수, 고객의 정성적 반응은 나쁘지않았다.

홍보 이후 초기 유저 유입

거의 몇 시간만에 300명 정도가 내 웹사이트에 유입되었다. 이때까지만 해도 나름 좋은 반응이라고 생각했었다. 특히나 제일 처음 홍보했던 학교 커뮤니티에서 유저들의 댓글 반응이 좋았기 때문이다.

이후 유저 가입 수나 리텐션을 확인해보기 위해서 DB에 쿼리를 날렸는데 순간 당황했다.

내 예상과 달리 19명 정도 밖에 가입을 안했기 때문이다. 이러면 가입 전환률이 10퍼센트도 안된다는건데, 내가 예상했던 것과 너무 달랐다. 평소같았으면 PMF 찾는데 실패했다고 느꼈을텐데 고객 인터뷰의 반응이 너무 좋았었기 때문에 실제 지표와의 괴리가 좀 당황스러웠던 것 같다.

그래서 뭔가 다른 원인이 있을 것 같아, 실제 유저들 몇명을 꼽아서 인터뷰를 진행했다.

유저이탈이 발생할 수 있는 시나리오 10가지 정도를 정해놓고 유저와 인터뷰를 진행했는데 그 과정에서 유저들이 생각보다 '회원가입을 아주 많이 귀찮아한다' 라는 것을 알게되었다. 생각해보면 어떤 서비스인지도 정확하게 모르는데 회원가입하면서 이메일을 드러내고, 아이디를 정하고, 비밀번호 확인 과정을 거치는 것이 귀찮을 수도 있다는 생각이 들었다.

나는 내 서비스를 테스트하면서 당연하게도 admin 계정을 활용하기 때문에 로그인을 유저 경험 여정에서 제외하고 있었는데 정말 큰 오산이었다.

기능 간소화 이후 지표 재측정

이 교훈을 얻고난 뒤 제품의 1차 수정 과정을 거쳤다. 로그인 기능을 아예 없애면 유저에게 연속적인 서비스를 제공할 수 없었고, 지표 측정도 흐려질 것 같았다. 따라서 아예 없앨 순 없었고, 그 대신에 로그인을 하지않고도 기능을 일부 사용할 수 있도록했다. 이후에 로그인을 하면 더 많은 기능을 쓸 수 있다는 것을 하단에 배너 컴포넌트를 넣었고, 로그인을 했을 때와 하지 않았을 때의 차이가 명확히 느껴지도록 디테일한 부분들을 수정했다.

확실히 로그인이 없이도 기능을 사용할 수 있으니 신규 유저 입장에서는 이 서비스에서 '회원가입하는데 드는 귀찮음을 감당할 정도로 유용한지'를 결정할 '시식 버전'을 줄 수 있었다. 이후 새로운 홍보채널을 통해 홍보를 진행했고, 그 결과

유입 지표를 캡쳐 못했는데, 400명 정도 유입시 80-90명 정도가 회원가입으로 전환되어, 5% -> 25% 정도로 지표 개선을 보였다. 홍보 이후 유저의 유입 반응은 비슷했지만 전환률이 높아졌고, 회원가입 이후 서비스를 지속적으로 이용하는 유저들의 재방문률이 높아졌다.

결론

이 경험을 통해 로그인 자체가 주는 이점도 많지만 자칫하다가는 Nice to Have의 함정에 빠질 수 있다는 것을 배웠다. 0 to 1을 만들면서 제품의 PMF를 검증하는 과정에서는 기능 고도화도 중요하지만 더 중요한 것은 초기 유저들의 리텐션을 얼마나 높일 수 있는가 인 것 같다. 기능보다 UX에 대한 고민을 더 중점적으로 해봐야겠다.

개발의 장벽이 낮아져서 기능 하나를 붙이고 떼고 하는게 너무 쉬워져서 이런 실수들이 생기는 것 같다. 원래 같았으면 기능 하나 추가하냐마냐도 신중하게 고려했는데, 이젠 그렇지않다보니 있으면 좋겠는데? 싶은 생각이 스멀스멀 올라오곤한다. 기술은 항상 수단이라는 것을 경계하자.

끗

[공모전 후기] KMAC 경영혁신 공모전 AI 부문 최우수상 수상

m00n0107 — Sun, 30 Nov 2025 01:32:37 +0900

오늘은 가장 최근에 받은 KMAC 경영혁신 공모전에 AI를 활용한 경영혁신 부문으로 참가하여 수상한 후기에 대해 남겨보려한다.

경영혁신 공모전은 한국능률협회컨설팅에서 주최하는 공모전으로 2009년부터 시작되어 현재까지 이어진 역사깊은 공모전이다. 처음에 이 공모전 게시글을 보고, 나는 현재 이 회사에서 인턴을 하고 있기 때문에 내부인으로 당연히 참가하지 못한다고 생각했다. 하지만 담당자님께 여쭤본 결과 주최는 한국능률협회컨설팅의 이름으로 하고 있지만 외부기관에서 위탁하여 심사하고 평가하고 있고, 내 이름, 나이, 대학 같은 인적사항 관련 정보를 보고서에 절대 기입할 수 없기 때문에 대학생 신분이기만 하면 모두가 참가 가능하다는 답변을 들었다. (하긴 이 회사 정직원도 아니고 들어온지 얼마 안된 인턴인데)

시상 규모도 컸고, 20팀이나 시상하니 그간 개인적으로 공부하고 연구했던 주제들을 활용하면 꽤 해볼만하다는 생각이 들었다.

1. 서류 심사

서류 심사 같은 경우에는 20장 이내의 보고서를 제출하는 형태였다. 보고서의 양식은 논문의 형태와 유사했기 때문에 논문처럼 쓰려고 노력했다. 내가 평소 관심있던 주제인 합성 데이터 쪽으로 보고서를 쓰려했고, 이 공모전에 참가하기 이전에 연구해본 것들을 토대로 옮기기 시작했다.

최종적으로 선정한 연구 보고서의 이름은 '합성 데이터를 활용한 디지털 마케팅 최적화 연구'이다. 여러가지 합성 데이터 모델을 활용해서 데이터의 품질을 비교 평가하고 합성 데이터를 활용해서 학습한 머신러닝 모델이 디지털 마케팅 분야 분석 환경에서의 문제(콜드스타트, 클래스 불균형 등)를 얼마나 개선할 수 있는지 정량적으로 실험하여 평가한 내용이다.

최근들어 합성데이터에 관심이 많아져서 합성 데이터 관련한 논문들을 시대순으로 쭉 나열해놓고 회사에서 남는 시간마다 읽어보곤 했었는데, 그때 공부한 것들이 연구에 도움이 많이 되었다. 특히 합성 데이터 모델들 중 많은 부분은 GAN 모델로부터 파생된 것들이 많아, GAN 모델에 대해서 좀 더 학습해볼 수 있었고, Diffusion 모델이나 Attention 등 메커니즘이 어떻게 활용되는지 등을 얕게나마 공부할 수 있었다.

(원래는 GAN 기반 모델을 써볼 일이 없었기 때문에 GAN 모델하면 그냥 생성자 판별자 나눠서 생성 평가 생성 평가 뭐 이런 정도로만 설명할 수 있었는데, 논문들을 읽어보며 Minimax Game 방식, 서로 노이즈를 주고 복원하는 과정들이 어떻게 적용되는지 등 모델의 발전 과정을 좀 더 깊게 볼 수 있었다. 솔직히 아직도 잘 이해가 안되는 부분들도 있지만, 시간 순으로 논문을 읽어보니 발전 과정에 대해서는 어느정도 고개를 끄덕일 수 있었다)

아무튼 이렇게 기존에 연구하던 것들을 바탕으로 한 일주일 정도 연구에 집중해서 실험을 진행하고 연구 보고서를 써서 제출했다. 그 결과 서류는 통과할 수 있었다.

2. 발표 평가

서류 평가 이후 발표 평가가 조금 당황스러웠다. 서류 심사 후 4~5일 정도 뒤에 바로 발표평가 날짜가 나왔는데, 15분 발표다보니 생각보다 발표 자료를 만들 시간이 없었던 것이다. 15분 발표면 최소 ppt가 25장 정도가 나와야하는데, 혼자 참가한 입장에서 그게 쉬운 일이 아니었다. 그래서 부리나케 발표 자료를 만들기 시작했고, 그래도 문서 작업들은 꽤 빠른 시간 안에 작업하는 편이라고 스스로 자부하기 때문에 당일날 아침 정도에는 발표 자료를 완성할 수 있었다.

그간 만들었던 발표 자료 중 가장 잘 만들었다고 생각함

발표 평가는 외부 평가기관에서 나오신 교수님 다섯 분 정도셨고, 전공은 데이터, AI, 경영, 산업공학 등 다양하셨다. 발표 시간이 짧지 않아서 대본을 외워서 하는건 어려웠고 대신 발표 자료 헤드메시지를 참고해서 매끄럽게 발표할 수 있도록 연습을 많이 했다. 발표는 큰 문제없이 잘 마쳤고, 질의 응답을 받기 시작했다.

발표 중간에 다들 나를 잘 안쳐다보시길래 망했구나.. 라고 생각했는데 평가는 의외로 엄청 좋았다. 다들 학부생 혼자 한 것에 대해서 긍정적으로 평가하셨고, 발표 주제나 실험 설계 등 거의 칭찬만 해주셨다. 그래서 사실 딱히 들어온 질문은 없었고, 나도 감사합니다 이외엔 답변드릴 것은 없었다.

그래서 아마 높은 순위를 받았을 것이라고 예상하고 결과를 기다렸다.

3. 결과

결과는 2주 뒤에 나왔고, 나는 아쉽게도 2등을 차지했다. 물론 2등도 너무 잘한거고 높은 경쟁률을 뚫은 것이지만, 내 발표 때 유독 심사위원 분들의 평가가 너무 좋았었고 이번 공모전의 내용은 나도 그간 했던 프로젝트 중 가장 만족했기 때문에 대상만을 노리고 있었다.

아무래도 연구와 관련된 경험이 길지않은만큼 아직 보완해야할 부분이 조금 있었던 것 같다. 그래도 최우수상 받아서 그간 노력이 보상받는 느낌이었다. 시상식은 아직 안했는데, 신라호텔에서 한다고 한다. 신라호텔을 살면서 한번도 가본적이 없는데 기대된다.

끗

개발만 할거면 사이드 프로젝트를 하는 의미가 없다

m00n0107 — Sun, 23 Nov 2025 15:25:34 +0900

지난번 글에 이어 오늘은 내가 진행한 사이드 프로젝트를 출시 이후에 어떻게 홍보했는지에 대해서 느낀 점을 써보려한다.

웹서비스는 마케팅이 80%라고 할만큼 개발자에게 개발보다 마케팅이 더 어려울 수 있다. 실제로 나포함 내 주변 개발하시는 분들을 보면 github에 수많은 레포지토리를 파고 서비스를 만들어도 그게 실제로 사용자가 생겨서 수익이 나는걸 본 기억은 거의 없다.

나 역시 많은 사이드 프로젝트를 경험해보면서 중간에 포기한 것도 있고, 돌아가는 서비스를 만들어서 배포까지 해 본 경험이 있으나, 결국 사용자를 유치하는 것은 쉽지 않았다. 사용자가 없으면 당연하게도 수익이 나지않는다. 지난 번 글에서 말했듯이 올해 나의 목표는 '나의 제품으로 1원이라도 벌어보기'기 때문에 제품을 개발하는 것을 넘어서 이 제품으로 사용자를 유치하는 것을 목표로 했다.

물론 구글이나 메타 등 돈을 내고 유료 광고를 돌리면 사용자에게 노출시키는 것은 어려운 일이 아니다. 하지만 나처럼 돈이 없어도 사업화가 가능한 것이 소프트웨어 제품의 매력이기 때문에 무료로 홍보할 수 있는 방법을 고민하고 실행해봤다.

1. 지인 홍보

첫번째로 지인 홍보를 했다. 내 주변에 내 서비스를 이용할만한 사람들에게 내 서비스 링크를 보내주고 사용해달라고 했다. 물론 그래봤자 10명이 채 되지않는다. 하지만 소통이 가능한 이들에게 먼저 홍보하는 것이 생각보다 큰 장점이 있었다.

아무래도 지인들이기 때문에 제품에 대한 피드백이 구체적으로 온다. 이 과정에서 크리티컬한 오류를 수정하기도 했고, 내가 미처 몰랐던 유저들의 특성까지 알 수 있었다. 물론 지인들은 가장 착한 피드백을 주는 유저이기 때문에 내 제품의 문제점에 대해서 짚어줄 확률이 적지만 어찌됐든 가장 구체적으로 제품의 사용감을 들을 수 있고, 이들도 결국 바이럴 효과를 발생시켜줄 씨앗이 되어줄 수 있기 때문에 쑥스러움을 참고 최대한 많은 이들에게 홍보했다.

2. 커뮤니티 바이럴

커뮤니티는 내 제품의 타겟이 몰려있는 곳이라는 점과 이들의 체류시간이 길다는 점에서 내 제품을 노출시키는데 큰 장점이 있다. 내 서비스의 경우 대학생들이 타겟이 되기 때문에 학교 에브리타임에 올렸다. 게시 이후에 바로 잠들어서 반응을 확인 못했었는데 다음날 아침 일어나니 생각보다 반응이 뜨거웠다.

정말 뿌듯하고 짜릿했던 반응

사실 큰 기대는 안했는데 생각보다 좋아요가 많이 달려서 놀랐다. 올린지 하루도 채 되지않아 수많은 댓글들과 좋아요가 달렸고, 글을 저장해둘 수 있는 스크랩도 많이 생겼다. 커뮤니티 특성상 이렇게 급격하게 반응이 생기는 글들은 '실시간 인기 게시글', 'Hot 게시글' 등에 올라가게되는데, 이렇게 글이 더 유명해지면 더더욱 노출이 지속적으로 된다. 빠르게 묻힐 줄 알았던 홍보 글은 현재 시점으로 올린지 일주일이 지났는데도 아직도 실시간 인기글에 있다.

원래 모든 값이 0이었는데, 이틀만에 급증해서 신기했다.

그 결과는 빠르게 제품의 지표에도 반영되었다. 바이럴 이후 이틀만에 400명 정도가 유입되었고, 이 중 50명이 회원가입하고 꾸준하게 사용중이다. 수익은 아직 하루 1000원 미만의 미미한 정도지만 꾸준히 유입하는 사람들이 있으니, 마케팅을 더 시도해서 유입 인원을 더 늘려보려고한다.

제품에 따라 마케팅은 어디에 어떻게 하느냐가 어려운 문제같다. 나처럼 운이 좋아서 잠깐 뜨거운 반응이 있을 수는 있어도, 이게 언제 사그라들지 알 수 없다. 그렇기 때문에 더더욱 지속적으로 마케팅 방식에 대해서 고민해봐야하는 것 같다.

개발자들은 특히나 특정 기술, 서비스 개발, 최적화에만 집중하려는 경향이 본인도 모르게 있기 때문에 의도적으로 비즈니스적인 사고를 해야한다는 것을 스스로 상기시켜야한다고 생각한다. 나도 벌써부터 머리아프다.

끗

제품 개발에 대한 나의 생각

m00n0107 — Tue, 18 Nov 2025 13:24:05 +0900

2025년 새해에 내가 잡은 목표 중 하나는 '내 제품으로 수익 발생시키기'이다. 그게 10원이되든 100원이 되든 상관없이, 회사의 도움을 받지않고 자체적으로 발생할 수 있는 추가수입이 1원이라도 생긴다면 성공이다.

사실 올해 이미 각종 공모전 상금으로 운좋게도 대학생치고 꽤 큰 돈을 벌었었다. 하지만 이건 학업에 대한 성과와 운이지 '내 제품'에서 발생하는 것이 아니다. 단순히 돈이 아니라 돌아가는 비즈니스를 직접 만드는 것이 최종 목표다. 이 목표는 컨설팅 펌에서 일하면서 더욱 강해졌다.

컨설팅 펌에서의 경험

컨설팅 펌에서 고객사들을 대상으로 데이터를 분석해주고 소프트웨어를 만들어주고 전략적 인사이트를 뽑아주는 일에 기여했었다. 이 과정에서 실제 돈이 굴러가는 산업에서 인사이트를 뽑아준다는 것이 굉장히 유익하고 흥미로웠지만, 이 결과에 대한 책임을 내가 직접 지지 않는다는 점에서 아쉬운 점이 있었다. 결국 나는 인턴이기 때문에 정해진 기간이 지나면 회사를 떠나게되고 학교로 돌아가야했고, 그렇기 때문에 어느순간부터 컨설팅을 제한된 날짜에 수행해야하는 '과업'처럼 해결해나가는 스스로를 돌아보게 되었다. 이게 만약 내 제품이었다면 이렇게 결정할 수 있었을까? 실제 고객사에서는 이렇게 실행하는 것이 최선일까? 에 대한 더 치열한 고민이 필요할 것임을 스스로는 깨닫고 있었지만 행동은 그렇지 않았다.

어쨌든 컨설팅 역시 용역을 제공하는 서비스고, 고객사가 만족할만한 결과가 나오면 그 자체로 가치있는 것이라고 생각한다. 하지만 내 최종적인 커리어의 목표는 어떤 일에서건 0 to 1에 최종적인 책임을 질 수 있는 실무자가 되는 것이기 때문에 시간을 내서 내 제품을 만들어보자! 라는 결정을 하게 되었다.

나의 첫 제품 : 시험 문제 풀어주는 Agent

사실 이런 목표가 생기기 이전에 제품을 만들어본 경험이 있다. 작년 이맘때에 학교 전공 시험이 오픈북이라는 이야기를 듣고, 나 대신 문제를 대신 풀어줄 수 있는 Agent 툴을 만들어서 배포한 경험이 있다. 이때 당시에는 이걸 사이드 프로젝트라고 생각도 안했던 것 같은데, 내 주변 사람들이 이 툴을 써서 시험을 보겠다고 하니까 갑자기 부담감이 생겨서 성능을 높이기 위해 꽤 고생했던 기억이 있다.

이때가 처음으로 내가 만든 소프트웨어의 첫 배포다. 사실 엄밀히 말하면 패키지 파일을 실행 가이드와 함께 전달한 정도니까 배포는 아니지만 어쨌든 다른 사용자가 실제 사용할 것으로 고려해서 만든 서비스다.

이 에이전트는 방대한 분량의 전공책과 강의 자료를 RAG 구조로 학습시켜 언어 모델로 검색할 수 있는 서비스인데, 이때 당시에 전공책에 있던 그림과 표를 파싱하는데 굉장히 많은 실험을 했었다. 이전에 실습 정도로 langchain + FAISS vector DB로 RAG를 만들어본 경험이 있는데, 이 서비스를 만들때는 굉장히 많은 Chunking 전략과 vector DB를 실험해봤던 것 같다. 특히 전공 책의 표를 파싱하는 일이 가장 복잡했는데, 오랜 시간동안 연구해보며 차라리 그 시간에 공부를 했으면 A+을 받지않았을까 싶었다.

아무튼 결과적으로 시험을 치는데 유용하게 활용되었고, 시험 윤리상 더 사용하기는 어려울 것 같아 그냥 시험 공부 정도의 용도로 마무리지었다. 요즘도 가끔 쓰고 있긴한데, 아무래도 예전에 짠 코드다보니까 지금 보니 좀 개선할 수 있는 여지가 많이 보인다. 나포함 총 5명 정도의 사용자를 유치했고, 따로 돈을 벌려고 만든 서비스는 아니다보니 과금은 하지 않았다(애초에 CLI 환경에서 돌리다보니까 과금하기 애매했었고, 후배들한테 돈을 받을 생각도 없었음)

소프트웨어 제품을 만들어가는 과정에 대한 나의 생각

제품 개발로 수익화를 해보자는 목표를 가졌을 때 가장 중요하게 생각했던건, '빠른 속도'다. 아무리 좋은 아이디어여도 첫 술에 배부르긴 어려우니, 여러번의 제품 피벗팅과 수 많은 실험을 해볼텐데 일관된 규칙과 방법론이 없으면 중간에 포기하거나 놓치는 기회들이 많을 것이라고 생각했다. 그래서 최근 시작한 사이드 프로젝트들은 모두 일관된 규칙으로 제품을 찍어내고 있다.

내가 임의로 정한 규칙

조금 부끄럽긴하지만 최대한 간단하게 이렇게 정리해봤는데 큰 틀에서 보면 "프로토타입으로 검증 이후 사업화" 라는 매우 일반적인 제품 개발 방법론과 유사하다. 나는 특히나 개발에 있어서 프로토타입과 제품을 구분 짓는 가장 큰 요소 중 하나가 DB설계의 유무라고 생각한다. 소프트웨어 제품에서 DB가 있고 없고는 정말 큰 차이인데, DB가 생기고 로그인 기능이 생기면서부터 서비스가 가질 수 있는 기능들이 훨씬 정교해진다. 나도 처음에는 모든 제품을 완벽하게 만들어야한다고 생각했으나, 지금은 그렇게 생각하지않는다. 수익이 발생할만한 제품은 DB없이 표지만 만들어진 프로토타입만으로 충분히 검증 가능하다는 것이 일반론이다. (최근 나도 드디어 그걸 경험했다..!)

진행상황

0이 아닌 숫자가 찍혀있을 때 너무 놀라서 캡쳐해놨음

그래서 저렇게 위에 정해놓은 틀에 따라 기계처럼 제품들을 계속 찍어내고 있는데, 훨씬 더 과정이 정교해진 것 같다. 물론 아직 배울게 많기 때문에 완전한 확신은 없지만 일단 저 프로세스대로 웹 서비스를 만들고 있고, 1개는 진행중, 2개는 배포를 마쳤다. 아직 배포된지 일주일이 체 되지않았고, 마케팅이 이제 막 진행 중이라 효과는 더 봐야겠지만, 현재까지 0.38$ + 커피 한잔을 벌었다(물론 개발에 사용한 CI/CD 툴에 지불하는 돈이 있기 때문에 슈퍼 적자다 ㅠㅠ) 츄파츕스 하나도 못사먹는 돈이지만 어쨌든 자발적인 유입으로 수익을 만들어내봤다는 것에 의미를 두고 있다. 앞으로도 근근히 나의 제품 개발에 대한 소식을 올리려한다.

[인턴후기] KMAC 컨설팅 인턴 후기_업무 (1) 데이터 분석, 모델링, 리서치

m00n0107 — Thu, 13 Nov 2025 16:07:23 +0900

지난 글에 이어 KMAC의 인턴으로서 어떤 일을 했는지에 대해서 후기를 적어보려한다.

올해 6월말에 입사해서 이 글을 쓰는 시점인 11월까지 총 2개의 컨설팅 프로젝트와 1개의 사내 소프트웨어 상품 프로젝트에 참여했다. 다른 입사 동기들을 참고하면 보통 1개내지는 2개의 프로젝트에 참여하는 것으로 알고 있는데, 나는 어쩌다보니 시기상 3개의 프로젝트에 참가할 기회를 얻었다. 현재 참여하고 있는 프로젝트 중 끝난 것도 있고, 진행중인 것도 있기 때문에 프로젝트가 특정되지않도록 유의해서 후기를 써보려한다.

글이 길어질 것 같아서

(1) 데이터 분석, 모델링, 리서치 업무

(2) 사내 소프트웨어 상품 프로젝트 QA 업무

이렇게 나눠서 작성해보려한다.

1. 유통 플랫폼 D사 컨설팅

유통 플랫폼인 D사의 마케팅 데이터를 분석해서 최적화 컨설팅을 진행하는 프로젝트에 참여했다. 내가 맡은 파트는 통계 모델링 및 데이터 분석, PPT 제작이었다. 사실상 파트라고 나뉠 것 없이 거의 모든 과정에 참여했는데, 매달 1 or 2회 컨설팅 방문을 하다보니, KMAC에서 했던 프로젝트 중 가장 어렵지만 보람찬 프로젝트였다.

오전엔 코딩, 오후엔 PPT만 만듦..

구체적으로는 디지털 마케팅의 예산 최적화를 하기위해 광고의 효율을 분석하고 판매량을 예측하는 모델링 프로젝트였는데, 이 프로젝트가 정말 어려웠던 이유는 고객사 이사님이 해외 유명대학교에서 디지털 마케팅 분야에 교수로 재직중이신 박사님이었다는 것이다.

아무래도 이 분야의 전문가시다보니, 컨설팅 이후 요구하시는 추가 요구사항이나 분석력 등이 남다르셨다. 사실 이 주제에 대해서 한 평생 연구를 하셨으니, 우리보다 더 전문성이 있으셔서 이 분의 요건을 만족시키기가 어려웠다.

어떤 모델을 쓰려해도, 그 모델의 수식부터 왜 다른 모델이아니라 이 모델을 써야하는지, 이 실험의 결과가 왜 이렇게 나왔는지, 이런 방향으로 분석해보는 것이 더 낫진않은지 등 정말 완벽한 분석을 하지않으면 안되는 상황이었다.

그래서 정말 많은 공부와 준비가 필요했고, 이 과정에서 실력이 굉장히 많이 늘었다. 컨설팅 당시 활용했던 모델이나 분석 기법들은 내가 전국의 동년배(학사수준 ^^)중 가장 잘 이해하고 있다고 자신할 정도로 준비를 열심히 했었다.

프로젝트가 아직 완전히 끝난 것은 아니지만, 다사다난했던 과정과 달리 결과는 어느정도 수긍하시고 만족해하시는 것 같아서 다행이었다. 그동안 야근하고 새벽까지 코딩하던걸 생각하니, 더욱 뿌듯했다. 살면서 해당 분야의 박사에게 내 연구 및 실험 결과물을 리뷰받을 일이 몇번 있겠는가. 돌아보니 고생 많이 했지만 다시 돌아가도 참여할 것 같다.

2. OO 공공기관 데이터 분석 지원

공공기관과 협업해서 기관이 갖고 있는 내부 데이터를 활용해 데이터 분석을 지원하는 프로젝트에 데이터 분석 파트로 참여했었다. 당시 컨설팅한 기관이 규모가 상당히 큰 기관이었고 그만큼 데이터도 많았다.

하지만 문제는 해당 기관이 갖고있는 데이터 중 쓰잘데기 없는 garbage 데이터가 너무 많았었다. 어떤 데이터를 활용할지 선별하는 작업이 작업 시간의 절반 이상을 차지했고, 막상 추리고나니 활용할 수 있는 데이터가 많지않았다.

열심히 분석함

제한된 데이터 안에서 분석을 진행하려하니 그게 생각보다 쉽지않았다. 특히 이 과업은 항상 마감일이 급했기 때문에 천천히 여러가지 요소를 분석해서 인사이트를 도출해야하는 데이터 분석 업무 특성상 쉽지않았고, 매순간 정신없이 진행됐던걸로 기억한다.

또한 기관의 담당자가 데이터에 대해서 잘 모른다는 점이 병목이었다. 데이터를 활용해서 분석하는 과업이긴하지만 공공기관 특성상 기술인력이 부족하기 때문에 내가 분석해서 인사이트를 뽑아내는 과정을 설명하기가 쉽지않았고, 그들이 실무를 진행하면서 생기는 인사이트와 실제 데이터가 주는 인사이트가 다를 경우, 이를 어떻게 해석해야하는지 전달하는 과정이 어려웠다.

이 프로젝트는 한 달 정도 짧게 진행되었기 때문에 짧고 굵었던 프로젝트로 기억에 남는다. 결국 제한된 시간 내에 기관 담당자 분들이 만족하시는 보고서를 만들어냈고, 프로젝트도 잘 마무리되었다.

느낀점

사실 이렇게 기업, 기관과 컨설팅 프로젝트를 진행하면서 느낀점은 코딩만큼 분석한 결과를 "실무자에게 정리해서 보여주는 것"이 쉽지않다고 느꼈다. 단순히 내가 분석하고 모델링하는 것이 끝이 아니라 이 결과물을 고객사에게 전달해야하며, 발표자료의 형태로 만들어야한다. 수많은 공모전에 참여하면서 PPT를 만드는건 정말 자신있다고 생각했는데, 이게 생각보다 그렇지않았다. 실제 기업의 전략을 결정하는 분석과 발표자료라고 생각하니 워딩 하나하나가 부담스러웠고, 그러한 권한이 온전히 나한테 주어졌기 때문에 더더욱 고민이 많이 필요했다.

비슷하게 느낀 또한가지는 내가 아무리 코드를 잘짜고 분석을 잘해도, 고객사는 내가 아는 지식과 다른 배경을 갖고 있을 수 있다는 점이다. 우리같은 컨설팅사에게 컨설팅을 맡기는 이유는 특히나 해당 기업에서 부족한 기술역량을 위탁한다는 의미도 있다. 그렇기 때문에 나 혼자 잘하는 것도 중요하지만, 고객사가 내가 진행했던 실험, 모델링 등을 다시 한 번 실증하고 돌려볼 수 있도록 자료를 정리하고 가이드라인을 만들어야했다. 나 혼자 코딩하는 일과 나의 모든 코딩 과정을 누군가와 공유한다는 것은 하늘과 땅 차이라는 것을 느꼈다.

[오픈소스 분석 5일차] Langchain에서 문서를 로드하고 처리하는 방식

m00n0107 — Fri, 7 Nov 2025 10:31:38 +0900

오늘은 langchain에서 core component 인 document, document_loaders에 대해서 뜯어보려한다.

langchain document

문서를 처리하는것은 langchain에서 핵심적인 컴포넌트이고 문서 처리 이후 변환하는 작업은 langchain만의 특장점이기도하다. 그래서 메모리에 효율적으로 로딩하고 파싱하는 특별한 방식이 있을 것 같아서 기대를 갖고 분석을 시작했다.

1. document_loaders는 문서를 로드하는 폴더

2. documents는 문서를 처리하는 폴더

로 보여진다.

1. document_loaders

document_loaders는 BaseLoader, BaseBlobParser라는 두가지 추상 클래스를 정의하고 있다.

class BaseLoader(ABC):  # noqa: B024
    """Interface for Document Loader.

    Implementations should implement the lazy-loading method using generators
    to avoid loading all Documents into memory at once.

    `load` is provided just for user convenience and should not be overridden.
    """

    # Sub-classes should not implement this method directly. Instead, they
    # should implement the lazy load method.
    
    
  ##이하 생략
  
  
class BaseBlobParser(ABC):
    """Abstract interface for blob parsers.

    A blob parser provides a way to parse raw data stored in a blob into one
    or more documents.

    The parser can be composed with blob loaders, making it easy to reuse
    a parser independent of how the blob was originally loaded.
    """

문서를 로딩하는 과정에서 기본적인 파일, API, DB같은 가벼운 문서와 PDF, 이미지 같은 무거운 문서를 나눠서 로딩하는데, langchain은 기본적으로 BaseLoader를 통해 lazy_load 메서드를 통해서 문서를 가져오며, BaseBlobParser를 통해 무거운 Blob 객체를 문서 객체로 변환하며 가져온다.

* Blob(Binary Large Object)

Blob이란 이진데이터를 의미하며 주로 PDF, 이미지 같은 크고 복잡한 비정형 데이터를 의미한다.

* 레이지로딩(Lazy Loading)

Lazy Loading이란 중요도가 떨어지거나 당장 필요하지않는 요소들의 로딩을 우선적으로 시행하지 않으면서 로딩의 퍼포먼스를 최적화하는 기술을 의미한다. 기존에는 모든 리소스를 한번에 로딩하는 방식을 사용하였으나, 메모리를 조금 더 효율적으로 사용하기 위해서 로딩의 우선순위를 정하는 것이다.

2. documents

documents는 문서를 처리하는 기능을 담고 있다. compressor와 transformers를 담고 있는데, compressor부터 살펴보자.

class BaseDocumentCompressor(BaseModel, ABC):
    """Base class for document compressors.

    This abstraction is primarily used for post-processing of retrieved documents.

    Documents matching a given query are first retrieved.

    Then the list of documents can be further processed.

    For example, one could re-rank the retrieved documents using an LLM.

    .. note::
        Users should favor using a RunnableLambda instead of sub-classing from this
        interface.

    """
    
    ##이하 생략

앞서 로딩한 문서를 압축하는 클래스이다. 구체적인 압축방법은 서브클래스에 정의되어있고, 압축과 동시에 비동기적으로 acompress_documents라는 메소드가 실행된다. 구현체를 볼 수 없으니, 왜 동기처리와 비동기처리가 동시에 실행되어야하는지는 잘 이해가 안된다.

아래는 transformers.py의 클래스이다.

class BaseDocumentTransformer(ABC):
    """Abstract base class for document transformation.

    A document transformation takes a sequence of Documents and returns a
    sequence of transformed Documents.

    Example:
        .. code-block:: python

            class EmbeddingsRedundantFilter(BaseDocumentTransformer, BaseModel):
                embeddings: Embeddings
                similarity_fn: Callable = cosine_similarity
                similarity_threshold: float = 0.95

                class Config:
                    arbitrary_types_allowed = True

                def transform_documents(
                    self, documents: Sequence[Document], **kwargs: Any
                ) -> Sequence[Document]:
                    stateful_documents = get_stateful_documents(documents)
                    embedded_documents = _get_embeddings_from_stateful_docs(
                        self.embeddings, stateful_documents
                    )
                    included_idxs = _filter_similar_embeddings(
                        embedded_documents,
                        self.similarity_fn,
                        self.similarity_threshold,
                    )
                    return [stateful_documents[i] for i in sorted(included_idxs)]

                async def atransform_documents(
                    self, documents: Sequence[Document], **kwargs: Any
                ) -> Sequence[Document]:
                    raise NotImplementedError

    """

여러 개의 문서를 받아서 필터링, 정렬, 요약, 임베딩 등 다양한 방식으로 변형시키는 클래스인데, 이 역시도 동기 방식과 비동기 방식이 동시에 수행되도록 되어있다.

langchain이 document를 처리하는 코드를 분석해보았는데, 내가 지금 잘 분석하고 있는건지 약간 의문이 생겼다. 현재 보고 있는 langchain_core에서의 코드들은 구현체가아니라 추상 클래스만 정의해놓은 전체 아키텍처인 것 같은데, 실제 구현체를 봐야하는 것 아닌가? langchain 오픈소스에는 너무 많은 폴더와 파일이 있다보니 실제 구현체가 어디있는지 찾기가 쉽지않다. 아니면 원래 오픈소스에서 실제 구현 로직은 제공을 안하는건가? 아무튼 전체적인 구조에 대해서는 감을 잡아가는데, 세부적인 분석을 해보려면 조금 더 자리를 잘 잡고 봐야할 것 같다.

[오픈소스 분석 4일차] LangChain이 API를 관리하는 소스 코드 분석

m00n0107 — Tue, 4 Nov 2025 02:00:14 +0900

지난번엔 langchain의 공식 문서를 어느정도 훑어보았고, 이제는 본격적으로 코드에 대해서 뜯어보려한다. 우선 langchain의 폴더 구성은 이렇게 되어있다.

langchain과 같은 큰 규모의 생태계를 가진 코드를 분석하는게 생각보다 막막함을 코드를 fork 뜨자마자 느꼈다. 수많은 파일들이 각각 어떤 역할을 하는지 파악하는게 쉬운 일이 아니었다. 이전 이동욱 개발자님의 오픈소스 분석 방법에 관한 글을 보면, 전체적인 아키텍처를 먼저 파악하고 디테일을 보는 것이 우선이라고 하셨으니, 전체적인 아키텍처가 어떻게 구성되어있는지 파악하기 위해 노력했다.

오픈 소스 분석 방법 | 개발자 이동욱

오픈 소스 분석 방법 머리속 한켠에는 오픈 소스 활동을 다시 하고 싶다는 생각을 가지고 있지만, 바쁘다는 핑계로 미뤄왔다. 우연히 어떤 블로그에서 오픈 소스 분석 방법 이라는 글을 읽고나

dongwooklee96.github.io

그래서 우선 공식문서와 readme, md 파일들을 꼼꼼히 읽어보면서 전체적인 아키텍처 구조를 파악하고 핵심 파일들이 모여있는 libs/core/langchain_core/ 의 코드들을 보면서 다시 bottom to top 방식으로 읽어보려했다. 너무 고민이 길어지는 것 같아 일단 무작정 아무거나 들어가서 읽어본 결과 내가 분석하려는 langchian의 핵심 기능들 소스 코드는 lib의 langchain_core에 모여있음을 알게되었고, 이곳의 폴더를 하나하나 열어보며 구성을 파악해보았다.

langchain_core의 __init__.py 파일을 보면

"""``langchain-core`` defines the base abstractions for the LangChain ecosystem.

The interfaces for core components like chat models, LLMs, vector stores, retrievers,
and more are defined here. The universal invocation protocol (Runnables) along with
a syntax for combining components (LangChain Expression Language) are also defined here.

**No third-party integrations are defined here.** The dependencies are kept purposefully
very lightweight.
"""

이렇게 나와있다. 즉 langchain-core에서 langchain의 핵심 요소인 chat model, llm, vector store, retriever 등 핵심 기능들이 구현되어있는데, 각각의 요소들이 어떻게 정의되는지에 대해서 나와있는듯하다. langchain의 기능들이 어떻게 구성되어있는지 분석해보고싶었으니, 주소를 잘 잡은 것 같다.

langchain_core

내부 폴더를 열어보니 역시나 이렇게 langchain_core 에 각 기능들의 구현체들이 있는데 가장 먼저 보이는 _api 폴더를 읽어봤다.

langchain_core/_api

_api 폴더는 총 5개의 코드 파일로 구성되어있는데, 이들은 langchain의 API 관리 시스템으로 모든 API 도구들을 관리하는 모듈인 것으로 파악했다. __init__.py는 폴더 내 모듈을 패키지로 인식되기 위한 파일일테니 건너뛰도록하고, 이제 본격적으로 각각 코드들을 뜯어보도록하자.

1. beta_decorator.py, deprecation.py (경고 출력 데코레이터)

beta_decorator.py는 langchain에서 일부 기능들을 beta decorator를 붙여서 경고하는 기능을 갖고있다. 아래의 class 이름만봐도 langchain 사용자에게 warning을 제공하는 기능임을 알 수 있다.

class LangChainBetaWarning(DeprecationWarning):
    """A class for issuing beta warnings for LangChain users."""

전체 코드는 200줄 가까이 되어서 전부 옮길 수는 없지만, 읽어보면 '베타 기능'으로 클래스를 지정하면 경고가 붙도록 설계되어있다. 즉, 베타 기능을 외부에서 호출하려할때는 경고 문구가 만들어지도록 하는 기능이다. 또한 주석을 보면 matplotlib의 deprecation 시스템을 참고해서 설계했다고한다.

2. internal.py (경고 출력시 내부코드, 외부코드 판별)

import inspect


def is_caller_internal(depth: int = 2) -> bool:
    """Return whether the caller at `depth` of this function is internal."""
    try:
        frame = inspect.currentframe()
    except AttributeError:
        return False
    if frame is None:
        return False
    try:
        for _ in range(depth):
            frame = frame.f_back
            if frame is None:
                return False
        # Directly access the module name from the frame's global variables
        module_globals = frame.f_globals
        caller_module_name = module_globals.get("__name__", "")
        return caller_module_name.startswith("langchain")
    finally:
        del frame

internal.py는 함수를 호출한 코드가 langchain 내부의 코드인지, 사용자의 코드인지 판별하는 코드이다. 판별하는 방식은 간단한데, frame 객체를 가져와서 이름 앞에 "langchain"이 붙는지 확인하는 방식이다. 위에서 decorator로 경고를 표시할 때 langchain 함수 내부 호출일 경우에는 경고할 필요가 없기 때문에 이를 판별할 수 있는 코드를 삽입한 것이다.

3. path.py (경로 지정)

import os
from pathlib import Path
from typing import Optional, Union

HERE = Path(__file__).parent

# Get directory of langchain package
PACKAGE_DIR = HERE.parent
SEPARATOR = os.sep


def get_relative_path(
    file: Union[Path, str], *, relative_to: Path = PACKAGE_DIR
) -> str:
    """Get the path of the file as a relative path to the package directory.

    Args:
        file: The file path to convert.
        relative_to: The base path to make the file path relative to.

    Returns:
        The relative path as a string.
    """
    if isinstance(file, str):
        file = Path(file)
    return str(file.relative_to(relative_to))


def as_import_path(
    file: Union[Path, str],
    *,
    suffix: Optional[str] = None,
    relative_to: Path = PACKAGE_DIR,
) -> str:
    """Path of the file as a LangChain import exclude langchain top namespace.

    Args:
        file: The file path to convert.
        suffix: An optional suffix to append to the import path.
        relative_to: The base path to make the file path relative to.

    Returns:
        The import path as a string.
    """
    if isinstance(file, str):
        file = Path(file)
    path = get_relative_path(file, relative_to=relative_to)
    if file.is_file():
        path = path[: -len(file.suffix)]
    import_path = path.replace(SEPARATOR, ".")
    if suffix:
        import_path += "." + suffix
    return import_path

마지막으로 path.py는 api의 경로를 지정해주는 유틸리티를 모아놓은 코드이다. 파일 경로를 상대 경로로 지정해주는 get_relative_path 함수가 있고, python import 경로로 지정해주는 as_import_path 함수가 있다. 모듈 경로를 자동으로 추적할 수 있게끔 만들어주는 용도인듯하다.

langchain에서 api를 관리하는 코드들을 읽어보았는데, 잘 정리된 코드의 의미를 해석해보는 재미가 있다. 시간을 좀 더 넉넉하게 두고 천천히 뜯어보면 더 좋겠지만, 시간상 이정도로 마무리하려한다.