올코의 우당탕탕 공부하기

요즘 AI에 관심을 가지게 되면서 이런저런 툴들을 사용해보고 있는데요. 

그중에서도 매우 괜찮다고 느낀 Claude에 실시간 웹 검색과 강력한 추론 능력을 추가하는 방법을 알려드리겠습니다.

MCP 프로토콜을 활용한 Tavily + Think 조합으로 Claude를 더 똑똑하게 사용하는 방법입니다. 

MCP란?

MCP(Model Context Protocol)는 Anthropic이 개발한 오픈 프로토콜입니다.

AI와 외부 도구를 연결하는 표준 인터페이스입니다.

Claude는 2023년 12월까지의 정보만 알고 있습니다.

그래서 최신 정보에 답이 어렵고 복잡한 단계별 추론도 부족했습니다.

이런 부족한 부분을 보완하기 위해서 외부 도구와 연결해 최신 정보를 가져올 수 있도록 할 수 있습니다.

Tavily + Think + Claude 조합

이 조합의 역할을 살펴보겠습니다:

1. Tavily: 실시간 웹 검색과 콘텐츠 추출 MCP 서버입니다.
2. Think: Claude의 추론 능력을 강화하는 MCP 서버입니다.
3. Claude: 이 MCP 서버들과 연결되는 AI 비서입니다.

장점

• 최신 정보: Tavily로 뉴스, 날씨, 주가 등 실시간 정보를 검색합니다.
• 정확한 추론: Think로 복잡한 문제도 단계별로 접근합니다.
• 통합 서비스: 검색과 추론을 함께 활용합니다.
• 맞춤형 분석: 특정 주제 정보를 검색하고 분석합니다.

설치 튜토리얼

1. 준비물

• Claude Desktop 앱(최신 버전)
• Node.js
• Tavily API 키
• 터미널/명령 프롬프트

2. Tavily API 키 받기

1. Tavily 사이트에서 가입합니다.
2. 대시보드에서 API 키를 만듭니다.
3. 키를 복사해 보관합니다.

3. Tavily MCP 서버 설정

Claude Desktop 설정 파일을 엽니다.

Mac:

touch "$HOME/Library/Application Support/Claude/claude_desktop_config.json"
vi "$HOME/Library/Application Support/Claude/claude_desktop_config.json"

파일에 다음 내용을 추가합니다.

{
  "mcpServers": {
    "tavily-mcp": {
      "command": "npx",
      "args": ["-y", "tavily-mcp@latest"],
      "env": {
        "TAVILY_API_KEY": "여기에_API_키_입력"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

4. Think MCP 서버 설정

위 설정 파일에 Think 서버도 추가합니다.

{
  "mcpServers": {
    "tavily-mcp": {
      // 기존 설정 유지
    },
    "think-tool": {
      "command": "npx",
      "args": ["-y", "@cgize/mcp-think-tool"],
      "type": "stdio",
      "pollingInterval": 30000,
      "startupTimeout": 30000,
      "restartOnFailure": true
    }
  }
}

전체 설정은 이렇게 됩니다.

{
  "mcpServers": {
    "tavily-mcp": {
      "command": "npx",
      "args": ["-y", "tavily-mcp@latest"],
      "env": {
        "TAVILY_API_KEY": "여기에_API_키_입력"
      },
      "disabled": false,
      "autoApprove": []
    },
    "think-tool": {
      "command": "npx",
      "args": ["-y", "@cgize/mcp-think-tool"],
      "type": "stdio",
      "pollingInterval": 30000,
      "startupTimeout": 30000,
      "restartOnFailure": true
    }
  }
}

5. 적용하기

1. 파일 저장
2. Claude Desktop을 재시작
3. 연결 상태를 확인

Mac 로그 확인

tail -n 20 -f ~/Library/Logs/Claude/mcp*.log

사용 예시

Tavily 검색 활용

단순한 최신 사실 검색도 클로드만을 사용할 수 있습니다.

• "오늘 뉴스 알려줘"
• "오늘 날씨 어때?"
• "AI 기술 트렌드 검색해줘"

Think 도구 활용

아래와 같이 복잡한 문제도 물어볼 수 있습니다.

• "Think 도구로 이 경영 전략 분석해줘: [문제]"
• "Think 도구로 이 수학 문제 풀어줘: [문제]"

두 도구 조합하기

아래와 같은 검색, 정리와 같은 복합 기능도 가능합니다.

• "비트코인 시세 검색하고 향후 전망 분석해줘"
• "수원 맛집 검색하고 내 취향에 맞는 곳 추천해줘"

활용 팁

1. 검색 최적화:
   • 짧고 명확한 검색어 사용
   • 특정 URL 분석은 "tavily-extract 도구로 [URL] 분석해줘"
2. Think 도구 활용:
   • 복잡한 문제는 단계별로 나누기
   • "단계별로 생각해줘" 요청하기
3. 업데이트:
   • MCP 서버 버전을 최신으로 유지하기

마치며

Tavily + Think + Claude 조합으로 더 스마트하게 Claude를 사용할 수 있었습니다. 

요즘처럼 정보가 많아 너무 많은 검색이 필요로 할 때 구글을 여러번 검색하는게 아닌, 한번의 검색으로 원하는 결과를 얻을 수 있는 부분이 저에겐 흥미로웠습니다. 

여러분의 경험과 다른 유용한 MCP 조합도 댓글로 공유해주세요.ᐟ

참고 자료

• Anthropic MCP 문서
• Tavily 문서
• Claude Desktop

개요

모든 파일을 add하여 stage 상태로 변경하고 -m 옵션을 이용해 커밋하여 불필요한 파일까지 커밋하는 경험이 자주 있었다.
이런 경우 불필요한 파일을 Staging Area에서 삭제하여 필요한 변경 내역만 커밋하는 방법을 정리하려 한다.

용어 정리

Git의 파일 상태 관리

Git은 init된 순간부터 디렉토리의 모든 파일을 아래의 상태들로 분류하여 관리한다.

• Tracked : 관리 대상 파일, 한번이라도 스냅샷에 포함되면 tracked 파일이 됨
  • Staged : 커밋으로 저장소에 기록할 상태
  • Unmodified : 마지막 스냅샷 이후로 변경이 없는 상태
  • Modified : 마지막 스냅샷으로부터 변경 내역이 있지만 staged되지 않은 상태
• Untracked : 관리 대상에 포함되지 않는 파일들

Staged 된 파일 삭제

먼저, 현재 상태를 살펴본다.
git status 명령어를 통해 아래와 같은 결과가 나왔을 때, -m 옵션과 함께 commit 하게 되면 Changed to be commit 에 있는 모든 파일이 커밋된다. 그런데 PracticeSpringJpaApplication.java 파일만 제외하고 커밋하고 싶다면 해당 파일을 staged 상태에서 없애주면 된다.

$ git status                                                 
On branch main
Changes to be committed:  # 변경 이후 staged에 올라간 상태
  (use "git restore --staged <file>..." to unstage)
        modified:   src/main/java/com/practicespringjpa/PracticeSpringJpaApplication.java
        new file:   src/test/java/com/practicespringjpa/chapter3/entity/Chap3MemberTest.java
        new file:   src/test/java/com/practicespringjpa/chapter3/repository/Chap3MemberJpaRepositoryTest.java
        new file:   src/test/java/com/practicespringjpa/chapter3/repository/Chap3MemberRepositoryTest.java
        deleted:    src/test/java/com/practicespringjpa/entity/MemberTest.java
        deleted:    src/test/java/com/practicespringjpa/repository/MemberJpaRepositoryTest.java
        deleted:    src/test/java/com/practicespringjpa/repository/MemberRepositoryTest.java

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/main/java/com/practicespringjpa/chapter4/

staged 상태에서 없애주기 위해 git reset HEAD -- path/to/file 명령어를 사용하면 된다.

아래와 같이 staged 상태에서 PracticeSpringJpaApplication.java 파일을 위 명령어로 삭제해주면 Modified 상태임을 표시하는 Changes not staged for commit: 파일 내역으로 옮겨진 것을 확인할 수 있다.

$ git reset HEAD -- src/main/java/com/practicespringjpa/PracticeSpringJpaApplication.java                                                  
Unstaged changes after reset:
M       src/main/java/com/practicespringjpa/PracticeSpringJpaApplication.java
$ git status                                                                                    
On branch main
Changes to be committed:   # 변경 이후 staged에 올라간 상태
  (use "git restore --staged <file>..." to unstage)
        new file:   src/test/java/com/practicespringjpa/chapter3/entity/Chap3MemberTest.java
        new file:   src/test/java/com/practicespringjpa/chapter3/repository/Chap3MemberJpaRepositoryTest.java
        new file:   src/test/java/com/practicespringjpa/chapter3/repository/Chap3MemberRepositoryTest.java
        deleted:    src/test/java/com/practicespringjpa/entity/MemberTest.java
        deleted:    src/test/java/com/practicespringjpa/repository/MemberJpaRepositoryTest.java
        deleted:    src/test/java/com/practicespringjpa/repository/MemberRepositoryTest.java

Changes not staged for commit:  # 변경은 있지만 staged에 올라가지 않은 상태 (Modified)
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/main/java/com/practicespringjpa/PracticeSpringJpaApplication.java

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/main/java/com/practicespringjpa/chapter4/

Github의 Black lives matter

심심해서 Github 공식 블로그를 구경하다가 10월을 기점으로 Github에서 Repository를 생성할 때 Default 브랜치명이 master에서 main으로 바뀐다는 글을 보았다. (github.blog/changelog/2020-10-01-the-default-branch-for-newly-created-repositories-is-now-main/)

Default 브랜치명을 굳이? 왜? 바꿀까 싶어 찾아보았다. 최근 미국에서는 Black lives matter 운동이 큰 이슈가 되고 있다. 이러한 움직임의 연장으로 미국의 IT업계에는 이전부터 논란이 된 master/slave, blacklist/whitelist 와 같은 언어적인 문제들을 개선하려는 움직임이 많아지고 있다고 한다. 그 중 Github도 이러한 사회의 흐름에 발맞춰 움직인 것 같다.

이미 존재하는 Repository의 Default branch를 임의로 모두 바꾸게 되면 사용자들에게 큰 파장을 일으킬 수 있다. 이러한 문제가 발생하지 않도록 우선 신규 Repository 생성시에만 Default 브랜치명이 main으로 생성되고, 기존 Repository는 연말까지 변경을 지원 할 예정이라고 한다.(github.com/github/renaming#later-this-year-seamless-move-for-existing-repositories-)

실제 사용에 어떤 영향을 미칠까?

• 삭제한 master 브랜치의 url을 main 브랜치로 redirect 지원
  eg) github.com/user_name/repository_name/blob/master/README.md -> github.com/user_name/repository_name/blob/main/README.md
• Github 페이지를 사용할 때 gh-pages 만 사용할 수 있었는데 이러한 제한이 없어짐
• user, organization, enterprize 단위로 Repository 생성시 자동 생성되는 Default branch 이름 설정이 가능해짐 

기존에 생성한 Repository의 Default branch를 변경하려면?

Step 1 - git branch 명령어 중 "-m / -M" 옵션을 사용하여 master 브랜치를 main 브랜치로 rename하고 remote 저장소에 push

$ git branch -help
usage: git branch [<options>] [-r | -a] [--merged | --no-merged]
   or: git branch [<options>] [-l] [-f] <branch-name> [<start-point>]
   or: git branch [<options>] [-r] (-d | -D) <branch-name>...
   or: git branch [<options>] (-m | -M) [<old-branch>] <new-branch>
   or: git branch [<options>] (-c | -C) [<old-branch>] <new-branch>
   or: git branch [<options>] [-r | -a] [--points-at]
   or: git branch [<options>] [-r | -a] [--format]

$ git branch -m master main
$ git push -u origin main

Step 2 - Github의 Repository 설정 변경

Step 3 - master 브랜치 삭제

사용하지 않는 브랜치는 지워주는게 좋다. 

github.com/user_name/repository_name/branches 에서 master 브랜치를 지워준다.

main이 아닌 다른 Default 브랜치명을 사용해야 한다면?

그렇다고 모든 신규 repository의 default 브랜치명을 main으로 강제하는 것은 아니다.
master 브랜치, 혹은 다른 이름의 default 브랜치를 계속해서 사용해야 한다면 github.com/settings/repositories 에서 아래의 빨간 박스가 되어 있는 main 대신 master 혹은 원하는 default 브랜치명으로 업데이트하면 새로운 repository를 생성해도 main으로 default 브랜치를 생성하지 않는다.

사담

미국의 IT업계에서 master/slave, blacklist/whitelist 등 일반적으로 사용되는 언어에 대해서 이미 논란이 있어 왔다는 것을 처음 알았다🤭
조지 플로이드 사건 이후 종종 기술 검색을 하거나 웹을 떠돌다보면 Reddit이 오렌지 로고에서 검정 로고로 변경한 것, 어떤 기술의 메인페이지에 Black lives matter 해시태그가 추가된 이미지가 있는다던지 등의 모습들이 보였는데 실제 내가 사용하는 영역까지 영향을 받는 것은 처음이라 인상깊었다.
다양한 인종이 있는 만큼 한국에서는 아무생각 없이 지나칠 부분에도 다양한 논의가 있고, 이를 개선한다는 것은 매우 좋은 것 같다. Black 뿐만 아니라 Asian에 대한 차별까지 관심이 확장되면 좋겠다🙃

참고

github.com/github/renaming

www.sedaily.com/NewsView/1Z567TI23H

 최근 공부한 내용을 Markdown문서로 정리하고 Github에 저장해서 정리하다보니 내용이 길어질 때 회사에서 사용하는 WIKI처럼 문서 상단에 링크가 걸린 목차를 만들고 싶어졌다.

TOC(Table Of Content)는 헤딩 태그를 기준으로 생성 되므로 문서 작성 시 TOC에 표기하고자 하는 문장들은 헤딩 태그로 명시 해 주어야 한다.

 헤딩 태그로 명시된 문장을 목차에 링크 걸기 위해서는 아래와 같은 포맷으로 작성 하면 된다. 이때 주의 할 점은 링크가 걸리는 텍스트의 띄어쓰기는 "-"로 명시해야 하거나 글자수+띄어쓰기 수 만큼의 "-"를 써준다. 하지만 명확하게 표기하기 위해 해당 문장을 그대로 쓰는 것을 추천한다 :)

[목차 텍스트1](#링크가-걸리는-텍스트1)
[목차 텍스트2](#------------)
...
# 링크가 걸리는 텍스트1
# 링크가 걸리는 텍스트2

 실제 작성한 예시와 결과는 아래와 같다.

## 목차

1. [깨끗한 코드](#1장.-깨끗한-코드)
2. [의미 있는 이름](#2장.-의미-있는-이름)

  

---

## 1장. 깨끗한 코드

### 보이스카우트 규칙

* 코드는 잘 짜기만 했을 때 끝나는 것이 아닌, 시간이 지나도 언제나 깨끗하게 유지해야 한다.
* 보이스카우트 규칙  
  ` 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.`

---

## 2장. 의미 있는 이름

### 의도를 분명히 밝혀라

이름을 지을 때 아래의 질문들을 고려해야 한다.

* 변수(혹은 함수나 클래스)의 존재 이유는?
* 수행 기능은?
* 사용 방법은?

  위의 예시와 같이 작성하였을 때 깃헙에 커밋을 해 보면 아래와 같이 목차에 있는 깨끗한 코드, 의미 있는 이름에 링크가 걸림을 알 수 있다. 그리고 링크가 걸린 문장에 커서를 가져가면 1장. 깨끗한 코드앞에 링크 표식이 보이는 것 처럼 링크 표식이 나타난다.

* 위의 내용을 직접 만들지 않도록 도와주는 사이트가 있다. 

https://ecotrust-canada.github.io/markdown-toc/

사이트에서 아래와 같이 직접 작성한 마크다운 문서를 빨간칸에 붙여넣으면 헤딩 태그를 기준으로 TOC(Table Of Content)를 생성 해 준다.

local에서 작업을 하고 서버에서 코드를 받아서 테스트를 하다가 수정사항이 생기면 양쪽에서 커밋을 마구잡이로 할 때도 있다.
아니면 자잘하게 놓친 한 두줄을 위해 커밋을 또 날리게 되는 경우들이 있다.
그러다보면 커밋 히스토리는 지저분해지기 쉽상.
이런 경우에 rebase를 사용해 커밋 히스토리를 정리할 수 있다.

local에서 작업하는 기준으로 remote에 commit 한 history를 정리하고 싶을 때

# n : 합치고 싶은 커밋의 갯수

$ git rebase -i HEAD~n

위의 명령어를 실행하면 아래와 같이 커밋을 수정할 수 있는 화면이 나온다.

나타난 커밋들 중에 합치고 싶은 커밋의 pick을 squash로 변경한다.

이 예제의 경우 aa8f244 커밋에 5e5dc41 커밋의 내용을 반영하고, 커밋을 합치기 위해 5e5dc41 커밋을 squash로 변경 해 준다.

변경을 완료하면 esc + :x

이제 커밋메세지를 새로 쓸 수 있는 화면이 나오게 된다.

지우고 싶은 커밋메세지의 앞에 # 을 붙여 주석처리를 해준다.

첫번째 커밋 메세지의 위치에 새로 쓰고자 하는 커밋메세지를 작성해주고 :x로 종료해준다.

Successfully rebased and updated ~ 로그가 나오게 되면 local에서 rebase가 잘 된 것!

이제 원격에 수정사항을 적용하기 위해 git push --force origin branchName 명령어를 사용한다.

이전 커밋에 히스토리를 합친 것이기 때문에 HEAD보다 현재의 커밋이 뒤에 있기 때문에 그냥 push하면 오류가 나므로 아래와 같이 --force 옵션을 붙여서 force push를 해준다.

--force 옵션을 붙이게 되면 local의 git 정보가 remote에 덮어씌워 지므로 조심해서 써야 한다.

git push --force origin 브랜치명

Git 로컬 정리

git init

- 저장소 생성

mkdir 폴더명

cd 폴더명

git init

-> 성공시 Initialized empty Git repository in /path/폴더명/.git

git status

- 저장소 상태를 확인

git에서 추적하지 않는 파일이 존재하는 경우

git add 파일명

- git이 파일을 추적하도록 추가

아무런 메세지가 없으면 성공적으로 추가된 것

git status 명령어를 실행하면 커밋해야 할 수정내역 확인 가능

git commit

- git에 수정내역을 추가

맨 첫줄에 커밋 메세지를 작성한 후 vim을 종료하면 커밋 완료([Esc]키를 누르고 :wq를 입력한 다음 [Enter]키를 눌러 저장 후 종료)

git commit -m “커밋 메세지”

- vim 진입 없이 메세지를 입력하여 커밋할 수 있음

git commit -a

- 저장소에 변경된 모든 파일을 커밋 (처음 생성된 파일X, 변경된 내역 O)

모든 변경내역을 commit 한 후 git status 명령어를 실행하면 아래와 같은 결과가 나옴

——————————————————————————————————————————

Git branch

기존 프로젝트에 영향을 끼치지 않고 새로운 기능을 추가/변경하여 테스트를 해야하는 경우

branch를 통해 기본 코드를 복사하여 추가적인 코딩을 하면 됨

git branch

현재 존재하는 브랜치 확인

 (현재 작업중인 브랜치 이름앞에는 *로 표시 됨)

git branch 브랜치명

- 브랜치 생성

git checkout 브랜치명

- 작업하고자 하는 브랜치로 이동하는 명령어

git checkout -b 브랜치명

- 브랜치를 만들면서 바로 체크아웃

브랜치에서 변경한 내역을 master에 병합

git checkout master

git merge 브랜치명

——————————————————————————————————————————

불필요한 파일 및 폴더 무시

touch .gitignore

- .gitignore라는 이름의 빈파일 생성

(touch 명령어는 파일의 타임스탬프를 변경하는 용도로 사용하거나 파일이 없는 경우 빈 파일을 만드는 명령어)

www.gitignore.io

위의 사이트에서 검색창에

현재 사용중인 운영체제, IDE, 프로그래밍 언어 이름

의 조건들을 입력하고 generate를 클릭하면 gitignore 파일을 생성해줌 -> .gitignore 파일에 복사하여 저장

——————————————————————————————————————————

충돌 방지

여러 브랜치의 같은 파일의 같은 행에 서로 다른 변경 사항이 있으면 merge 과정에서 충돌이 발생

-> 수작업으로 해결 해 줘야 함

——————————————————————————————————————————