--- title: "2025-08-11~2025-08-17_W32" url: "https://notes.junghanacs.com/journal/20250811T000000" author: "Junghan Kim" date: "2025-08-11T00:00:00+09:00" tags: ["journal"] description: "회사에서 MCP 서버를 git·nixos·kagi·memory·n8n 등 85개 도구로 확장하고, Zammad·Supabase를 저울질하며 이사님과 통합 솔루션 미팅을 가진 주. GitHub Copilot과 Claude를 함께 고려한 리포지토리 구조를 정리했다." --- ## 2025-08-11 Mon ### 07:31 출근 명상 감사 ### 바이브 터널 닉스에 설치했다가 닉스 방식으로 변경 (“My Claude Code Setup | /Adi 클로드코드 전문가” n.d.) - #LLM: ¤vibetunnel 터미널 에이전트 개발환경 - tailscale tramp emacs 연결 원격 근무 - 완벽하자 #### 된장 설치하고 지움 ```shell [nix-shell:~/devshell]$ npm cache clean --force npm warn using --force Recommended protections disabled. [nix-shell:~/devshell]$ npm install -g node-addon-api added 1 package in 443ms [nix-shell:~/devshell]$ npm install -g vibetunnel ``` ,#+BEGIN_SRC markdown NixOS에서 닉스쉘(nix-shell)이 중요한 이유와 역할, 그리고 닉스쉘 밖에서 VibeTunnel 사용 가능 여부에 대해 설명드리겠습니다. 닉스쉘은 NixOS 및 Nix 패키지 매니저 환경에서 특정 패키지들과 개발 툴, 라이브러리들을 임시로 설정된 격리된 쉘 환경으로 제공합니다. 이 환경 안에서는 패키지들의 종속성과 컴파일에 필요한 헤더 파일, 빌드 도구 등이 제대로 경로가 설정되어 있어, 네이티브 모듈 빌드가 정상적으로 수행됩니다. NixOS가 일반 리눅스 배포판과 다른 점은 시스템 전체의 패키지가 불변(nix store read-only)이고, 전통적으로 패키지를 설치하는 방식과 다르게 선언적으로 관리된다는 것입니다. 그래서 PAM 같은 개발 헤더 파일이나 gcc, make 같은 빌드 도구가 시스템 전역에 바로 보이지 않는 경우가 많아 그냥 터미널에서 npm 같은 빌드 도구를 실행하면 헤더 파일을 찾지 못해 빌드가 실패하게 됩니다. 닉스쉘 환경을 사용하면 이런 문제를 회피할 수 있습니다. 닉스쉘은 필요한 개발용 패키지들을 빌드 환경에 포함시켜, 컴파일러가 헤더 경로나 라이브러리를 잘 찾도록 도와줍니다. 그래서 VibeTunnel 같은 네이티브 모듈 의존성 빌드를 성공시키는 데 필수적입니다. 닉스쉘 밖에서도 VibeTunnel를 사용할 수는 있지만, 설치 및 빌드 과정에서 필요한 네이티브 모듈이 제대로 빌드되어 있다면 가능합니다. 즉, 닉스쉘은 주로 설치(build) 환경을 위한 격리된 개발 환경이고, 한 번 빌드 및 설치가 완료되면 닉스쉘 밖에서도 정상적으로 실행되고 사용할 수 있습니다. 정리하면: - 닉스쉘은 NixOS에서 개발용 빌드 환경(헤더, 컴파일러, 라이브러리)을 격리하여 제공하는 쉘 환경입니다. - 네이티브 모듈 컴파일에 필수적인 종속성들을 쉽게 충족시켜 줍니다. - 닉스쉘 없이 일반 쉘에서 빌드하려 하면 헤더 경로나 의존성 문제로 실패할 수 있습니다. - 그러나 빌드가 완료된 후에는 닉스쉘 밖에서도 VibeTunnel 실행과 사용이 가능합니다. 따라서 닉스쉘은 VibeTunnel 설치 빌드 단계에서 중요한 역할을 하며, 설치 후에는 일반 환경에서도 자유롭게 사용할 수 있습니다. 필요하다면 닉스쉘로 환경을 쉽고 안전하게 관리하는 방법이나, 빌드 후 일반 환경에서 VibeTunnel 실행하는 방법도 추가로 안내해 드릴 수 있습니다. #+END_SRC ### 09:39 고우 ### 18:19 tailscale ### ddd [2025-08-11 Mon 18:20] ## 2025-08-12 Tue ### 08:20 웨즈텀으로 가자. 복붙이 된다. ### MCP 서버 분석 완료 ✅ URL: 인증: Bearer token sk-tbdhny-asdf-1234 필요 사용 가능한 Access Groups: - dev-tools - 개발 도구 - docs-tools - 문서화 도구 - mcp-full - 모든 MCP 기능 - memory-tools - 메모리/지식 그래프 도구 - search-tools - 검색 도구 - system-tools - 시스템 관리 도구 등록된 MCP 서버들: 1. Git (13개 도구) - Git 작업 자동화 2. NixOS (18개 도구) - NixOS 패키지/옵션 검색, Home Manager, Darwin 3. Kagi (3개 도구) - 웹 검색 및 요약 ● 완벽합니다! 🎉 모든 MCP 서버 활성화 완료! ✅ 현재 활성화된 모든 MCP 서버들: 총 85개 도구 - context7_mcp: 벡터 검색 (2개 도구) - git: Git 작업 자동화 (13개 도구) - kagi: 웹 검색 및 요약 (2개 도구) - memory: 지식 그래프 관리 (9개 도구) - n8n_mcp: 워크플로우 자동화 (39개 도구) - nixos: NixOS/Home Manager 관리 (18개 도구) - ref_tools: 코드 검색 및 분석 (2개 도구) ← 새로 추가! ref_tools가 성공적으로 연결되어 총 85개 도구로 늘어났습니다! 모든 MCP 서버들이 정상적으로 작동하고 있습니다. 화장실 다녀오시는 동안 완벽하게 설정이 완료되었습니다! 😊 > /mcp ⎿ (no content) ## 2025-08-13 Wed ### 13:54 메타베이스 셋업 ### 11:15 영 사업 ## 2025-08-14 Thu ### 07:28 좋아 슈퍼맥스봉 아키텍처 @user 슈퍼스칼라 아키텍처가 뭐지? 아웃오브오더링 ### 08:35 좋아. 역시 이거야 ### 08:56 처리 아 ### 09:46 데이터베이스 올려줄 것 Guide to importing csv data into postgresql ### 11:38 이사님 미팅 - 자마드 활용 시나리오 - 하나의 솔루션을 만들고 싶다 ### 14:56 curl -X POST "" -H "Content-Type: application/json" -d '{"model":"llama3.2:1b","messages":[{"role":"user","content":"Hello"}]}' ### 15:48 dd ## 2025-08-15 Fri ### 08:24 출근 ### n8n을 좀 더 디테일하게 손으로 해보려고 한다. [2025-08-15 Fri 08:24] 그렇게 해야 인공지능을 제대로 다룰 수 있을 것 같다. ### 슈퍼베이스 도커를 한번 보자 [2025-08-15 Fri 08:26 ㅜ ### 08:56 ZAMMAD 슈퍼베이스 각각 ### 자마드 ### VC 코드 공유 개발환경 설정 파일 - spacemacs - mermaid 등 아주 심플 - 설정은 폴더 안에 있으면? 들어갔을 때 반영이 되는가? 싫을텐데?! ### 10:19 N8N 한국 커뮤니티 mcp 서버 및 관련 예제 많다. 그럼에도 따라하기가 최고다. 일단 따라하기로 문제 해결하고 나서 그 다음에 학습을 하자. ### 14:12 ### 16:59 고생해서 나가자 ## 2025-08-16 Sat ### 14:12 이제 키도르르 입력하자. 입력하는 것이 명상이다. 그러니까 이맥스를 쓰는 것이며 입력하는 것이다. 두드리는 것이다. ### 15:14 업데이트 에디터 시나리오를 수정 한다. 스코드도 매우 아끼자. ### 17:16 코파일럿 클로드 둘다 고려한 구성 ````markdown 영문 번역: "What is a recommended repository structure considering both GitHub Copilot and Claude services?" *** 답변: **두 서비스를 모두 고려한 리포지토리(Repository) 구성 권장안**은 다음과 같습니다. ### 기본 디렉터리 구조 예시 ``` /(프로젝트 루트) │ ├── src/ # 소스코드 디렉터리 ├── tests/ # 테스트 코드 디렉터리 ├── docs/ # 문서(Documentation) │ ├── CLAUDE.md # Claude 전용 프로젝트 전반 지침/설계 문서 ├── .github/ │ ├── copilot-instructions.md # Copilot 전용 저장소 지침 파일 │ └── instructions/ # (선택) Copilot 부분별 instructions (instructions.md 등) │ ├── README.md # 일반 프로젝트 설명 ├── 기타 설정파일 등 ``` ### 세부 기준 및 권장 사항 - **CLAUDE.md** 파일(프로젝트 루트): Claude(클로드)에서 프롬프트와 코드 설명에 반영할 프로젝트 핵심 정보, 작업 가이드, 설계 규약, 폴더/파일 구조, 사용 기술 스택, 구현 원칙 등을 자유롭게 기재합니다. - **.github/copilot-instructions.md** 파일: GitHub Copilot 및 Copilot Chat, Agent에서 코드 자동생성 시 참고하도록 핵심 지침(코딩 스타일, 네이밍 룰, 우선순위, 주요 규약 등)을 Markdown 형식의 자연어로 명시합니다.[1][2][3][4] - **.github/instructions/** 디렉토리와 *.instructions.md 파일(선택): 프로젝트가 크거나 특정 디렉토리별 세부 지침이 다를 때, copilot-instructions.md를 분할해 적용할 수 있습니다.[1] - **docs/**, **README.md** 등**: 전통적 문서 체계, API 문서, 요구사항 사양, 업무 가이드 등을 병행 관리하며, Claude와 Copilot 모두가 참고할 수 있습니다. ### 참고 팁 - 폴더 구조와 전체 파일 명세는 README.md, CLAUDE.md, copilot-instructions.md 등에 모두 요약해두면 두 서비스 모두 문맥 인지가 정확해집니다. - 폴더/파일명은 일관성 있게 구체적으로 작성하면 AI가 프로젝트 구조를 더 잘 이해합니다. - 중복되는 정보(예: 주요 아키텍처, 폴더 구조, 스타일 가이드 등)는 두 설명 파일 모두에 명시하는 것이 권장됩니다. 이 구성을 통해 GitHub Copilot의 실시간 코드 생성 보조와 Claude의 코드 리뷰·기획·대화형 관리 기능을 모두 극대화할 수 있습니다. ### 22:06 좋아. 서버에 설정해놨다. {#22-06-좋아-dot-서버에-설정해놨다-dot} ## 2025-08-17 Sun {#2025-08-17-sun} ### 10:30 사피엔스 이거 참 강하네 {#10-30-사피엔스-이거-참-강하네} ### 15:09 {#15-09} ### 15:16 오늘 재미잇 {#15-16-오늘-재미잇}