1. 들어가며과거의 소프트웨어 배포는 거대한 전쟁이었습니다. 개발팀, 테스트팀, 운영팀이 모두 모여 밤을 새우며 서버에 코드를 올리고 에러가 나면 롤백(Rollback)하는 과정의 연속이었죠.하지만 지금의 넷플릭스(Netflix)나 구글(Google) 같은 빅테크 기업들은 하루에도 수천 번씩 코드를 배포합니다. 개발자가 퇴근 10분 전에 코드를 git push해도 아무도 불안해하지 않습니다. 코드가 자동으로 테스트를 거치고 서버에 안전하게 올라가기 때문입니다. 이 마법 같은 워크플로우를 가능하게 하는 핵심 개념이 바로 CI/CD(지속적 통합 및 지속적 배포)입니다.2026년 현재, 전 세계 90% 이상의 기업이 도입한 CI/CD는 단순한 트렌드를 넘어 개발자의 필수 생존 지식이 되었습니다. 이번 포스팅에..

1. 들어가며노션(Notion)은 현존하는 최고의 생산성 도구입니다. 하지만 너무 자유도가 높다 보니, 새 프로젝트를 시작할 때 빈 페이지를 마주하면 어디서부터 손을 대야 할지 막막해지는 경우가 많습니다."이번엔 다이어트 트래커를 만들어볼까?" >>> 데이터베이스 속성(Property) 고민 30분 >>> 뷰(View) 배치 30분 >>> 수식(Formula) 짜다가 1시간... 정작 본질적인 일은 시작도 못 하고, 노션 세팅에 주말을 다 날려버리는 현상을 업계에서는 "Notion Paralysis(노션 마비)"라고 부릅니다.기존의 'Notion AI' 역시 글쓰기나 요약을 도와줄 뿐, 이런 복잡한 워크스페이스 구조를 설계해 주지는 못합니다.이러한 문제를 해결하기 위해 제가 직접 개발하여 오픈소스로 공개..

1. 들어가며옵시디언(Obsidian)의 완벽한 로컬 데이터 주권과 강력한 지식 연결(Graph View), 그리고 노션(Notion)의 압도적인 데이터베이스와 협업 기능. 노트 앱을 적극적으로 활용하는 사용자라면 누구나 이 두 도구를 모두 사랑하면서도, 동시에 두 플랫폼 간의 데이터 파편화로 인해 큰 스트레스를 받아본 경험이 있을 것입니다.옵시디언에 글을 쓰고 노션으로 복사하면 서식이 깨지고, 노션에서 마크다운으로 내보내기(Export)를 하면 첨부파일이나 콜아웃(Callout) 같은 특수 블록이 유실됩니다. 시중에 나와 있는 동기화 도구들도 대부분 '단방향' 복사에 그치거나 충돌(Conflict) 상황에서 데이터를 조용히 날려버리는 치명적인 결함을 가지고 있었습니다.이러한 한계를 완벽하게 극복하기 위..

1. 들어가며: "왜 내 코드는 Push가 안 될까?"머신러닝 모델 가중치 파일(200MB), 게임 개발용 에셋 파일(500MB), 혹은 대용량 데이터셋(1GB). 프로젝트를 진행하다 보면 필연적으로 용량이 큰 파일을 다루게 됩니다. 기분 좋게 코딩을 마치고 git push를 날렸는데, 터미널에 아래와 같은 빨간색 에러 메시지가 뜬 적 있으신가요?remote: error: GH001: Large files detected. You may want to try Git Large File Storage.remote: error: File model.bin is 157.92 MB; this exceeds GitHub's file size limit of 100.00 MBGitHub은 성능 유지를 위해 100M..

1. 들어가며현대 소프트웨어 개발에서 "코드를 어떻게 짤 것인가"만큼 중요한 것은 "코드를 어떻게 안전하게 합칠 것인가"입니다. 수많은 개발자가 동시에 같은 프로젝트를 수정할 때, 서로의 작업을 방해하지 않으면서 최상의 코드 품질을 유지하는 방법이 바로 GitHub의 Pull Request(PR) 시스템입니다.PR은 내가 작업한 내용을 팀에게 정식으로 제안하고, 동료들의 검토(Review)를 거쳐 메인 코드베이스에 반영하는 일련의 소통 과정입니다. 이 과정을 제대로 이해하면 협업의 효율성이 극대화되고 디버깅 시간이 획기적으로 줄어듭니다.입문자부터 실무자까지 아우르는 GitHub Pull Request부터 Merge까지의 완벽 가이드를 정리해 보았습니다.2. 개요 및 정의 2-1. Pull Request ..

1. 들어가며개발자 여러 명이 하나의 프로젝트를 동시에 개발할 때, 각자의 코드가 서로 충돌하고 덮어씌워지는 대참사를 막기 위해 우리는 'Git(깃)'이라는 버전 관리 시스템을 사용합니다. 그리고 이 Git을 사용할 때, 메인 코드에서 가지(Branch)를 쳐서 각자 작업한 뒤 다시 합치는 과정을 거치게 됩니다.하지만 자유도가 너무 높은 Git 환경에서 아무런 규칙 없이 각자 마음대로 브랜치를 만들고 합치게 되면 어떻게 될까요? 프로젝트의 릴리스 일정이 꼬이고, 배포 중에 치명적인 버그가 터지는 등 걷잡을 수 없는 혼란에 빠지게 됩니다.그래서 등장한 것이 바로 '브랜치 전략(Branching Strategy)'입니다. 이는 "어떤 브랜치를 만들고, 언제 합치며, 언제 배포할 것인가"에 대한 팀 차원의 약..

1. 들어가며개발자가 코드를 다 짜고 나면 끝일까요? 아닙니다. 코드가 잘 돌아가는지 테스트(Test)해야 하고, 실행 파일로 빌드(Build)해야 하며, 실제 서비스 중인 서버에 올리는 배포(Deploy) 과정을 거쳐야 합니다. 과거에는 이 모든 과정을 개발자가 수동으로 처리해야 했지만, 이 반복적이고 지루한 작업을 자동으로 해주는 마법 같은 시스템이 등장했습니다. 바로 CI/CD(지속적 통합/지속적 배포)입니다.수많은 CI/CD 도구(Jenkins, Travis CI 등) 중에서도 2018년 출시 이후 전 세계 개발자들을 열광시키며 사실상 업계 표준으로 자리 잡은 서비스가 있습니다. 바로 'GitHub Actions(깃허브 액션)'입니다.GitHub Actions는 우리가 코드를 저장하는 GitHub..

1. 들어가며개발을 하다 보면 "우리 회사 사내 시스템에도 GitHub Copilot처럼 알아서 코드를 찾아주고, 깃허브(GitHub) 이슈를 요약해 주는 똑똑한 AI 비서가 있으면 얼마나 좋을까?"라는 생각을 한 번쯤 해보셨을 것입니다. 하지만 이런 '에이전트(Agent)' 시스템을 바닥부터 직접 만드는 것은 결코 쉬운 일이 아닙니다. 대화 맥락(Context)을 유지해야 하고, LLM이 외부 API(도구)를 적절히 호출하도록 라우팅해야 하며, 에러가 났을 때 스스로 복구하는 로직까지 전부 개발해야 하기 때문입니다.이러한 개발자들의 고충을 해결하기 위해 2026년 3월, 마이크로소프트와 깃허브는 엄청난 무기를 공개했습니다. 바로 'GitHub Copilot SDK'입니다. 이 SDK는 단순히 AI에게 ..

1. 들어가며개발 프로젝트를 진행하다 보면 최종.zip, 진짜_최종.zip, 이게_마지막_수정.zip과 같이 파일 이름으로 버전을 관리하다가 낭패를 본 경험이 한 번쯤 있을 것입니다. 여러 명의 개발자가 동시에 같은 파일을 수정하다가 코드가 덮어씌워지거나, 과거의 정상 작동하던 코드로 돌아갈 수 없게 되는 문제는 소프트웨어 개발의 고질적인 골칫거리였습니다.이러한 문제를 해결하기 위해 등장한 것이 바로 버전 관리 시스템(VCS, Version Control System)이며, 그중에서도 2000년대 IT 업계의 표준으로 자리 잡았던 전설적인 도구가 바로 SVN(Subversion)입니다.현재는 분산형 시스템인 Git이 대세가 되었지만, SVN은 특유의 직관성과 강력한 중앙 통제 능력 덕분에 여전히 대기업,..

1. 들어가며AI 모델이든, 웹 백엔드든, 혼자 개발하는 게 아니라면 Git으로 협업하는 건 대부분 아실겁니다.Github에서는 내 코드를 메인 브랜치에 합쳐달라고 "Pull"라고 요청해서 Pull Request (PR)라고 부르죠.GitLab은 용어가 좀 더 직관적입니다. "Merge"라고 요청해서 Merge Request (MR)라고 부릅니다. (본질은 100% 똑같습니다.)MR(PR)은 단순히 "코드 합치기"가 아닙니다."내가 이 작업을 왜 했는지(Issue), 어떻게 고쳤는지(Code Diff), 리뷰해 주세요(Review)"를 공식적으로 요청하는 '협업과 소통의 핵심 도구'입니다.이 포스팅에서 GitLab을 기준으로, Issue 확인부터 MR 생성, Code Review까지의 플로우를 A to ..