일지 #2 깃 환경 초기화 / 로컬 저장소와 원격 저장소(GitHub) 연결하기 / LLM과 랭체인(LangChain) 개발
아침에 일어나자마자 부동산 책 읽다가 에이전트 공부한다.
우선 저번에 깃 설정이 조금 문제가 있었는지 git pull이 안먹어서 다시 초기화랑 환경설정을 진행하려고 한다.
# 깃 저장소 초기화
git init
위 코드를 터미널 또는 Git Bash 에 입력한 후 깃 환경설정을 진행한다.
환경설정은 글로벌(전역)이 아닌 로컬로 진행할 생각이다.
# 로컬 Git 환경설정하기
git config --local user.name "사용자_이름"
git config --local user.email "이메일_주소"
이제 원격저장소에 연결해줄 차례이다.
나는 특정 지역 저장소 (로컬 프로젝트)를 GitHub의 특정 레포지토리 하나에 접근하는 것을 원하므로 deploy key를 만들어서 SSH 연결을 진행할 예정이다.
# 원격 저장소에 deploy key로 SSH 연결하기
1. 이 저장소 전용 key 만들기
ssh-keygen -t ed25519 -C "키_설명" -f ~/.ssh/파일명
홈 디렉토리의 .ssh 폴더에 저장될 key 파일명과 해당 키에 대한 설명을 적으면 된다. 예시는 아래와 같다.
ssh-keygen -t ed25519 -C "ai-agent deploy key" -f ~/.ssh/ai-agent_deploy_key
해당 코드를 Git Bash에 입력해주면 암호를 묻는 두 항목이 나오는데 [Enter]를 2번 눌러 비워두면 키 암호를 물어보지 않는다.
나는 이게 편리할 것 같아서 모두 [Enter]를 눌러주었다.
2. 공개키 확인 후 GitHub에 등록
cat ~/.ssh/파일명.pubcat ~/.ssh/ai-agent_deploy_key
그럼 ssh-ed25519로 시작하는 출력값이 나올 텐데 ssh-ed25519 부터 시작하는 줄을 복사해둔다.
출력된 공개키를 해당 GitHub 저장소의 [Settings] → [Deploy keys] → [Add deploy key] 에 붙여넣고 [Allow write access]를 체크한다.
* 여기서 주의할 점은 프로필 [Settings]가 아니라 해당 레포지토리의 [Settings]에 등록하는 것이다!
[Settings] 페이지에서 스크롤을 내려보면 왼쪽 메뉴바에 [Deploy keys] 항목이 있다. 해당 메뉴로 들어가준다.
3. 새 로컬 저장소 폴더에서 키 지정
git config --local core.sshCommand "ssh -i ~/.ssh/키_파일명 -o IdentitiesOnly=yes"git config --local core.sshCommand "ssh -i ~/.ssh/ai-agent_deploy_key -o IdentitiesOnly=yes"
--local : 현재 로컬 저장소에만 적용
-i : 인증에 사용할 개인 키 지정
IdentitiesOnly=yes : SSH가 다른 키를 임의로 시도하는 것을 제한
실행 후 아무 메세지가 나오지 않아도 정상이다.
* --local can only be used inside a git repository 오류가 나오면, Git 저장소 폴더가 아니거나 아직 초기화하지 않은 상태다. 폴더 위치를 확인하고, 새로 초기화할 프로젝트라면 git init 후 다시 실행한다.
4. 설정 확인하기
git config --local --get core.sshCommand
이 코드를 입력했을 때, 방금 지정한 명령이 출력되면 설정된 것이다.
이제 GitHub 연결 주소를 확인해준다.
git remote -v
주소는 아래와 같은 SSH 형식이어야 한다.
git@github.com:소유자/저장소이름.git
그런데 나의 경우에는 SSH 형식으로 나오는 것이 아니라 HTTPS 주소가 나오는 것이다..!!
그런 경우에는 아래 코드를 실행해준다.
# 이미 origin이 있는데 HTTPS 주소가 출력되는 경우
git remote set-url origin git@github.com:소유자/저장소이름.git
이렇게 하고 다시 git remote -v 명령어로 SSH 형식인지 확인해주었을 때 나는 정상적으로 주소가 출력되었다.
5. 읽기 연결 테스트하기
git ls-remote origin
오류 없이 끝나면 읽기 연결은 된 것이다. 원격 저장소가 비어 있는 경우에는 출력이 나오지 않는다.
이후에 최초 접속 시 서버 확인 질문이 나오는데 GitHub 공식 SSH 지문을 확인한 뒤 승인해주면 된다~~!!!!
이제 본격적으로 LLM과 랭체인 개발을 진행해본다. (LLM의 API 키는 다 발급 받은 상태다)
이번 단계에서는 AI 에이전트 개발의 가장 기초적인 단계다.
먼저 OpenAI와 Entropic의 LLM API를 직접 호출하는 방법을 배우고, 이를 활용해 페르소나를 가진 챗봇을 만든다.
마지막으로 복잡한 AI 애플리케이션을 손쉽게 구축하도록 돕는 프레임워크인 랭체인(LangChain)의 핵심 개념을 학습한다.
# LLM API의 기초
책을 읽다보니 'Agent SDK' (Agent Software Development Kit) 라고 인공지능 모델이 단순한 대화형 챗봇을 넘어, 스스로 판단하고 도구를 사용해 복잡한 작업을 수행하는 AI 에이전트를 쉽게 개발할 수 있도록 돕는 소프트웨어 도구라는 것도 있다고 한다.
이것도 해보고 싶긴 한데 난 지금 입문 단계이므로 이건 나중에 해보기로 한다.
Agent SDK는 단순히 LLM API를 호출해 텍스트를 받는 것을 넘어, 상태 관리, 에이전트 루프, 툴(도구) 오케스트레이션, 세션 유지 등을 프레임워크 차원에서 지원한다고 한다.
참으로 흥미롭군...
LLM API를 사용하는 이유는 무엇일까?
LLM API는 대규모 언어 모델에 프롬프트와 파라미터를 주고 추론하게 하는 API 이다. 하지만 우리는 이미 클로드나 GPT 같은 LLM을 공식 앱이나 프로그램을 통해서 실행할 수 있다. 그런데 번거롭게 API를 사용해서 LLM으로 추론을 하여 답변을 받도록 하는 이유가 무엇일까?
그 이유는 바로 AI를 서비스에 적용하기 위해서이다. 우리가 만드는 서비스의 사용자가 직접 타이핑을 해서 LLM에 프롬프트를 입력하도록 할 수는 없기 때문이다. LLM API를 사용해야만 서비스에 적용할 수 있다.
비용 효율화나 최신 모델을 활용할 수 있다는 장점도 있지만, 비용 효율화보다는 LLM이 가지고 있는 능력과 기능의 최대치를 끌어내는 것이 목표라면 LLM API를 사용해야 한다.
# LLM API의 기본적인 사용법
LLM API를 사용하려면 모델의 특징을 잘 이해하고 사용하는 것이 중요하다. 일단 모델별 특징 정리만 해도 굉장히 많은 것을 알아야 하는데 우선 살펴볼 부분은 특징 및 비용과 관련된 부분이다.
각 LLM의 모델별 특징 및 가격은 아래의 URL들에서 확인할 수 있다.
- OpenAI :
https://openai.com/ko-KR/business/pricing/#api
https://developers.openai.com/api/docs/pricing
- Claude :
https://claude.com/ko/pricing#api
플랜 및 요금제 | Claude by Anthropic
문제 해결 방식에 맞는 Claude 플랜을 선택하세요. Free, Pro, Max, Team, Enterprise 및 개발자용 API 요금제를 제공합니다.
claude.com
https://platform.claude.com/docs/en/about-claude/pricing
Pricing
Learn about Anthropic's pricing structure for models and features
platform.claude.com
- Gemini :
https://ai.google.dev/gemini-api/docs?hl=ko
Gemini API | Google AI for Developers
Gemini API 문서 및 API 참조
ai.google.dev
모델 | Gemini API | Google AI for Developers
Google의 가장 강력한 AI 모델에 대해 알아보기
ai.google.dev
모델의 특징을 알아야 하는 이유는 단순히 비용 때문만이 아니다.
컨텍스트 윈도우 크기, 응답 속도, 특정 태스크에서의 정확도, 프롬프트 엔지니어링 방식 등이 모델마다 다르기 때문에, 이를 이해하는 것이 중요하다.
따라서 요구사항에 맞추어 모델을 구분하여 다르게 사용하는 것이 필요하다.
추론 모델의 경우에는 기존의 서버 API에 비하면 상당히 느리고 더 오랜 시간을 사용하지만 성능은 조금 더 좋다.
이제 다음은 각 LLM 별로 API 사용법을 다뤄볼 예정인데 오늘은 여기에서 마무리하고 이후의 내용들은 사용법 포스팅으로 묶는 것이 좋을 것 같다. (절대 하기 싫어서 그런거 아님;;;)
오늘은 여기에서 마무리~~! 끝~~!!!