머가필요해

스웨덴 S/W 아키텍트 Knut Sveidqvist(어떻게 발음해야할지 모르겠다 😅)가

Visio를 사용하다가 문제를 겪고선 Markdown 문서와 잘 어울리는 텍스트 기반 다이어그램 작성기를 2014년 11월에 만들었다.

Mermaid라는 이름은 당시에 그의 아이들이 보고 있던 디즈니 애니메이션에서 영감을 받았다고 한다.

실제 만든 제품과 전혀 연관성이 없는 이름이라니 ... ㅋㅋㅋ 🤣

Mermaid는 여러 사이트를 보유하고 있다.

① 공식 홈페이지

  - https://mermaid.js.org/

  - URL 주소에서도 보이지만, 기반은 Javascript이다.

  - 2019년도에는 JavaScript Open Source Award 수상도 했다(The Most Exciting Use of Technology).

  - 앞으로 오픈소스 공식 홈페이지는 아래로 오라고 한다.

    . https://mermaid.ai/open-source/

② Advanced Editor (Create with AI)

  - https://mermaid.ai/

  - 최근 트랜드에 맞춰 Mermaid도 AI 열차에 올라탔다.

  - Free 등급도 급한대로 쓸만하지만, 돈을 들여야 한다.

③ Live Editor

  - https://mermaid.live/

  - 웹에서 바로 결과를 확인해볼 수 있는 에디터도 있다.

  - 예전엔 여기가 메인이었지만, `② mermaid.ai` 사이트를 최근에 밀어주고 있다.

④ GitHub

  - https://github.com/mermaid-js/mermaid

  - 개인적으로 정보는 GitHub이 제일 많고 좋은 것 같다 !!!

사이트들은 충분히 살펴봤고,

이제는 실제 어떻게 작성하는지 알아보자.

⒜ Flowchart

  - GitHub README 파일에 너무나 잘 나와 있어서 해당 내용으로 대체 하겠다.

  - `flowchart LR`에 있는 `LR`은 left-right를 의미한다.

    . `LR` 말고 top-down으로 그리고 싶을 때에는 `TD`를 사용할 수 있다.

  - 연결선도 다양하게 표현할 수 있다.

    . --> : 화살표
    . --- : 실선
    . -.-> : 점선 화살표
    . ==> : 굵은 화살표

⒝ Sequence diagram

  - `loop` 같은 것이나 `Note`까지도 너무나 예쁘게 잘 지원해준다.

⒞ State diagram

  - Renderer가 한 번 업그레이드가 되어 `stateDiagram-v2`라고 명명해야 한다.

    . 그런데, 간단한 것만 사용해봐서 그런지 `stateDiagram`이라고 해도 차이를 잘 모르겠다.

그외에 Pie chart, Gant chart, Bar chart, Class Diagram 등은 물론

심지어 `User Journet diagram`도 있고, `Git graph`도 실험 버전으로 제공되고 있다.

GitHub Markdown에서 Mermaid 문법을 지원해주면서 Mermaid의 인기가 더 올라갔지만,

최근 AI에서 도식화를 시킬 때 Mermaid 문법으로 만들어 달라고 하면

너무나 예쁘게 잘 만들어주면서 더더욱 인기가 급상승하고 있다.

AI를 이용해서 문서화를 할 때에 Mermaid를 이용해 다양한 다이어그램과 차트를 그려주게 되면

구성원들 간에 오해를 줄일 수 있는 너무나 멋진 소통의 창구가 될 수 있다.

아! 참고로 GitHub에서 Mermaid를 표시하려면 아래와 같이 묶어 주면 된다.

그런데, 조금 이상하지 않은가?

뒤에 `;`를 붙였는데, 본래는 붙이지 않는 것이 표준이지만 줄바꿈을 명확히 하기 위해 붙이기도 한다.

여기까지 간단히 살펴봤다.

제목에 낚인 분도 계실 것 같다.

우리 엘론 머스크 형님의 Grok 하고 나도 햇갈려서 뭔가 이상해했었다.

Groq은 사실 H/W 업체로 봐야 한다.

  - https://groq.com/

보다 빠르고 낮은 가격에 인퍼런싱을 할 수 있는 LPU 업체인 것이다.

LPU가 뭐냐고?

`LLM Processing Unit`이라고, LLM 처리를 위한 칩이다.

  - https://groq.com/lpu-architecture

그 기술력을 인정 받아서 25년 12월, 200억 달러(약 30조)에 Nvidia에서 인수했다.

  - https://news.hada.io/topic?id=25318

  - https://www.cnbc.com/2025/12/24/nvidia-buying-ai-chip-startup-groq-for-about-20-billion-biggest-deal.html

그리고,

Groq은 자신들의 칩 성능을 증명하기 위해서 `오픈 웨이트 모델`들의 API를 제공하는 서비스를 했는데

저렴한 가격과 함께 좋은 성능을 보여 생각보다 꽤 괜찮은 인기를 얻고 있다.

다양한 모델들을 제공하고 있지는 않은데,

모델 자체의 다양성 보다는 다양한 용도에 걸쳐서 골고루 제공하고 있다.

Groq에 대해서는 그만 알아보고

API를 사용해보기 위해 회원 가입을 빠르게 해보자 !!!

  - https://console.groq.com/home

물론 공짜는 아니다 !!!

성능(속도)에 자신이 있기에 가장 앞에 TPS를 내세우고 있다.

  - https://groq.com/pricing

공짜가 아니라서 서운해하면 안된다.

Free Plan 에서도 꽤 쓸만큼 제공해준다.

  - https://console.groq.com/docs/rate-limits

각 필드가 어떤 의미인지 모르겠다고 ?!

그럴줄 알고 친절하게 다 설명해준다.

API를 사용하기 위해서는 당연히 Key를 발급 받아야 한다.

오른쪽 위 메뉴에서 `API Keys`를 클릭하자.

  - https://console.groq.com/home

`Create API Key`를 클릭하면 된다.

  - https://console.groq.com/keys

적당히 이름과 만료 기간을 정해주면 된다.

이렇게 생성한 Key 값을 잘 적어두자.

어떻게 사용할지 모를 때에는 공식 문서를 살펴봐야 한다.

  - https://console.groq.com/docs/overview

응?! 뭐지 Getting Start 동영상이 비공개 ????

하지만, 우리는 빠르게 `Quick Start`를 살펴보도록 하자.

  - https://console.groq.com/docs/quickstart

나는 uv를 사랑하기에 uv 방식으로 따라해봤다.

groq 패키지를 설치하자.

소스 코드는 `Quick Start`에 있는 것 그대로 해봤다.

아까 받아놓은 Key 값을 환경 변수로 설정하고

Python 실행하면 ... 꽤 빠르게 결과가 나온다.

대시보드를 보면 API를 얼마나 사용했는지 확인도 할 수 있다.

  - https://console.groq.com/dashboard/metrics

이것 저것 실험할 때 잘 사용해봐야겠다 !!!!

GitHub Actions에 대한 첫 이야기는 아래 글을 참고하면 된다.

  - https://www.whatwant.com/entry/GitHub-Actions-Quickstart

이번에 살펴볼 것은

Actions에서 자동화 하는 과정에서 Pull-Request의 comment를 작성하도록 할 수 있는 방법이다.

찾아본 결과 총 3가지의 방법이 있는 것 같아서 하나씩 알아보았다.

① actions/github-script

Actions의 YAML 파일 안에서 어느 정도의 프로그래밍을 할 수 있도록

JavaScript 형식으로 지원해주는 기능이다.

`analysys_result.txt` 파일의 내용을 comment로 반영하도록 작성한 것이다.

이거 하나를 위해 알아야할 것들은 많다.

`pull_request`가 처음 생성되거나 변경 사항이 있을 때 동작하도록 설정을 했고,

해야할 일을 수행하기 위해 필요한 permission도 정의를 해줬다.

`analysys_result.txt` 파일이 저장소에 있기 때문에

`Check out repository` 과정도 수행하게 했다.

파일이 없거나 여러 상황에 대해서 좀 처리하는 과정까지 포함해봤다.

사실 살펴보면 알겠지만, comment 자체를 반영하는 것은 간단하다.

② community action

자주 사용하거나 아니면 복잡한 기능들을 라이브러리 처럼 만들어서 서로 공유하기도 한다.

물론 GitHub에서 공식적으로 제공해주는 것들도 많다.

  - https://github.com/marketplace?type=actions

원하는 기능이 잘 만들어진 것을 선택하면 정말 간단하게 구현이 된다.

오늘 진행한 내용은 Codex의 도움을 많이 받았는데,

중간에 아래와 같은 에러가 발생했을 때에도 정말 간단하게 처리할 수 있었다.

github.com 환경에서 작업을 하니 링크를 그냥 던져버릴 수 있으니 정말 편했다.

회사에서도 이렇게 할 수 있으면 정말 좋을텐데 ...

③ GitHub CLI

Actions에서 사용하는 ubuntu 이미지에는 GitHub CLI 도구도 기본 설치되어 있다.

그러면 이것을 이용해서 간단하게 작업할 수 있다.

이렇게 Actions workflow 파일을 만들어서 적용시키면 comment를 잘 달아준다.

Action 수행된 결과도 확인해보면 많은 공부가 된다.

이렇게 알아보니 확실히 각각 장단점이 분명한 것 같다.

자유도가 높은 것은 action-script이고, 가장 간단한 것은 community action 가져다 사용하는 것이고,

local에서도 사용할 수 있는 일반적인 방식은 GitHub CLI이고 ... 그런 것 같다.

잘 이용해서 재미있는 것들을 만들어봐야겠다.

업무 효율화의 기본은 `자동화(automation)`이다.

S/W개발 과정에서의 자동화 요소는 자로 `빌드 자동화(Build Automation)`이고,

DevOps 관점에서 자주 언급되는 `CI(Continuous Integration)`라는 단어를

한글로 번역하면 `지속적 통합`이고, 이 역시 빌드와 관련이 되어있다.

그렇다보니 GitHub에서 제공하는 Actions를 `빌드 도구`라고만 생각하는 경우가 많다.

하지만, 사실 Actions는 빌드보다 훨씬 더 큰 의미의 `자동화 도구`이다!

  - https://github.com/features/actions

최근 AI Agent 만능 시대가 된 김에

이를 이용해서 뭔가 만들어보려고 하다가 GitHub-Actions를 이용해 자동화 도구를 만들어보자고 생각하게 되었다.

그래서, 기본부터 하나씩 확인해보려고 ... ^^

빠르게 변화하는 세상에서 가장 믿을만한 것은 공식 문서이다 !!!

  - https://docs.github.com/en/actions

여기에서는 `Quickstart for GitHub Actions`를 통해 빠르게 맛보기를 해보도록 하겠다.

공식 문서를 바탕으로 내 입맛대로 적당히 변형해서 살펴보겠다.

① 실습 저장소 만들기

Actions 실습을 하기 위한 저장소를 하나 준비하자.

GitHub-Actions 사용을 위해서는 public으로 설정해주어야 한다(그래야 Free runner 사용 가능!).

② 작업 공간(workspace) 준비

개인적인 취향으로 S/W개발 공부는 언제나 Ubuntu 환경에서 하고 있다.

여러분은 여러분 나름대로의 환경에서 진행해도 좋다.

③ workflow yaml 파일 작성

공식 가이드에 있는 workflow yaml 파일을 그냥 일단 반영해보자.

  - https://docs.github.com/ko/actions/get-started/quickstart

Actions workflow yaml 파일은 `.github/workflows`라는 디렉토리 밑에 위치해야 한다.

yaml 파일 이름은 확장자만 지키면 되고 자유롭게 해도 된다.

개인적인 취향으로 nano 에디터를 사용했다. (여러분은 여러분의 취향대로 ^^)

④ commit & push

지금은 고민할 때가 아니다 😁.

일단 commit, push 해버리자.

GitHub에 가서 잘 반영되었는지 확인해보자.

⑤ Actions 메뉴

놀랍게도 이렇게만 했는데도, 벌써 Actions가 실행되었다.

`Actions` 메뉴를 클릭하면 보안다 !!!

⑥ 실행 내역 확인

어떻게 실행되었는지 내역을 확인하고 싶으면 해당 부분을 클릭해주면 된다.

YAML 파일에 작성한 내용이 하나 하나 잘 실행된 것을 볼 수 있다.

여기까지가 실습 내용이고,

이제는 YAML 파일 내용과 실행 결과를 가지고 하나씩 비교하면서 익히면 된다.

각 항목이 실제 결과에 어떻게 나오는지 비교하면서 살펴보자 !!

실행 환경이 되는 docker image에 대해서는 조금 더 신경쓸 필요가 있다.

보통 ubuntu-latest 이미지를 많이 사용할텐데,

일반적인 환경이긴하지만 생각보다 상당히 무거운 환경이다.

이미 설치되어 있는 것들이 상당히 많아서 편할 수는 있지만,

사용하지 않는 것들도 엄청 많이 있는 상당히 무거운 환경이다.

좀더 가볍게 사용할 수 있는 이미지를 찾는 것도 중요하고,

설치되어 있는 도구들 목록을 잘 확인하고 버전 관리도 잘 살펴보는 것도 중요하다.

환경변수 처럼 사용되는 요소들도 한 번씩 살펴보면 좋다.

`actions/checkout@v5`같이 이미 만들어져서 제공되는 라이브러리들도 주의깊게 살펴보면 좋다.

여기에서 언급되지 않은 훨씬 더 많은 요소들이 있으니

하나씩 하나씩 차근 차근 공부해보자 !!!

GitHub Pull-Request 관련하여 뭔가 만들어보려고 하다보니

`코드리뷰`를 어떻게 하는 것이 효율적인 것인지에 대해서 알아보게 되었다.

그러다가 알게된 "코드리뷰 in 뱅크샐러드 개발 문화"라는 포스팅 !!!

왜 진작 알지 못했을까!? 라는 탄식이 나오게 하는 너무나 유용한 내용이었다.

  - https://blog.banksalad.com/tech/banksalad-code-review-culture/#커뮤니케이션-비용을-줄이기-위한-pn-룰

꼭, 반드시 원본글을 완독해보시기를 강력하게 추천을 드린다.

아래 포스팅은 내가 감동한 부분에 대한 이야기만 조금 남겨보도록 하겠다.

Communication: Sync vs. Async

회사에서 일을 하다보면 참으로 많은 인터럽트 상황이 발생하게 된다.

주로 발생하는 것은 메일, 메신저, 전화, 문자 그리고 직접적으로 찾아오는 사람 방문(대면) 등

`개발자의 몰입 비용`에 대해서도 한 번 정리해보고 싶긴 한데, 지금은 소통 방식에 대해서 집어보도록 하자.

소통하는 방식을 조금 다르게 분류해보면 `동기(sync)`와 `비동기(async)`으로 나누어 볼 수도 있다.

그 중에서 개인 업무 시간을 보장할 수 있는 소통 비용이 저렴한 방식은 `비동기 소통`이다.

개인의 업무 시간, 특히 집중을 깨뜨리지 않기 위해서는 `비동기 소통(async communication)`이 중요하다.

그래서, 뱅크샐러드에서도 기본적인 소통 방식을 `비동기 소통`을 하도록 권장하고 있고

그 연장선에서 코드리뷰 도구로 GitHub Pull-Request를 선택했다고 한다.

나도 회사에서 업무할 때

PR을 떠나 개발자들이 더 잘 집중할 수 있도록 `비동기 방식의 소통`을 기본 정책으로 하는 것에 대해 많이 고민해봐야겠다.

작은 PR(Pull-Request)

코드 리뷰를 할 때에 매번 언급되면 `작은 PR`.

누구나 알고있지만 누구나 잘 지키기 어려운 ... 항상 있는 숙제 같은 느낌의 정책이다.

나도 회사에서 이를 지켜보려고 하지만 정말 쉽지 않다.

그러다가 저 블로그 포스팅에서 얻은 힌트 ~~~ !!!

예외를 명시적으로 두자 !!!

Initial Commit, Test Code 등 큰 덩치로 들어오는 경우에 대해

공식적으로 예외 규칙을 두게 되면 좀 더 자연스럽에 PR을 운영할 수 있을 것 같다.

1,000 line 이후의 작은 PR을 유지하면 리뷰 병목을 해소할 수 있다.

`Low Context` Communication

`Low Context`는 번역될 때 다양하게 표현된다.

  - 저 문맥

  - 저 맥락

  - 저 배경

어떻게 번역되더라도 사실 잘 와닿지는 않는다.

Low가 있다는 것은 반대로 High도 있다는 것인데,

`High Context`는 조금 돌려말하는 것을 의미하고 `Low Context`는 직설적으로 표현하는 것을 의미한다고 한다.

`Code Review`를 요청할 때에는 `Low Context`로 설명을 해줘야 한다는 것이다.

상대방이 `이 정도는 알거야`라고 생각하지도 말고, 애둘러 표현하거나 추상적으로 표현하지도 말고

그냥 정확하게, 직설적으로, 최대한 구체적으로 표현(소통)하는 것이 효과적이다.

파트원들에게 꼭 하고 싶은 중요한 rule인 것 같다.

`Pn` 룰

개인적으로 가장 감동을 받은 정책이다.

처음 본 것도 아니고, 모르던 것도 아니고, 안해본 것도 아닌데 그럼에도 신선했다 !!!

P1: 꼭 반영해주세요 (Request changes)
  - 중대한 코드 수정이 반드시 필요하다고 판단되는 경우. 합리적인 의견을 통해 리뷰어 설득 필요

P2: 적극적으로 고려해주세요 (Request changes)
  - 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장

P3: 웬만하면 반영해 주세요 (Comment)
  - 수용할 수 없는 상황이라면 이유 설명 또는 향후 반영 계획 명시

P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
  - 무시 가능. 고민 추천

P5: 그냥 사소한 의견입니다 (Approve)
  - 아무런 의견을 달지 않고 무시해도 괜찮음

뱅크샐러드에서는 단지 PR에만 사용하는 것이 아니라

Slack 대화할 때 또는 평상시에도 Prefix로 자연스럽게(문화) 사용하고 있단다.

우와!!!!

부서에 꼭 반드시! 빠르게! 적용하고 싶은 rule 이다.

`D-n` 룰

`Pn 룰`만큼은 아니지만, 그래도 너무나 좋은 정책이라고 여겨지는 rule이다.

D-0 (ASAP)
  - 긴급한 수정사항으로 바로 리뷰해 주세요.
  - 앱의 오류로 인해 장애가 발생하거나, 빌드가 되지 않는 등 긴급 이슈가 발생할 때 사용합니다.

D-N (Within N days)
  - “Working Day 기준으로 N일 이내에 리뷰해 주세요”
  - 일반적으로 D-2 태그를 많이 사용하며, 중요도가 낮거나 일정이 여유 있는 경우 D-3 ~ D-5 를 사용

우와 ... 얼마나 명확한 소통 방식인가 !!!

뱅크샐러드에서는 Prefix 방식이 아니라 Tag 방식으로 활용하고 있단다.

그렇게 어렵지도 않고, 복잡하지도 않은 `리뷰 정책`인데,

제대로 정착만 된다고 하면 정말 상당히 꽤 효율적으로 pull-request를 수행할 수 있을 것이라 믿음이 생긴다.

간단히 요약해보았는데, 관심이 있으신 분은 원본 글을 꼭 찾아가서 읽어보시기 바랍니다!!!

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

귀여운 토깽이와 함께하는 "5분 제미나이" !!!

어떻게 하다보니 지난 달에도 제미나이였는데 이번 달에도 제미나이를 공부하게 되었다. ㅋ

- [한빛] "누구나 아는 나만 모르는 제미나이", 이제는 나도 아는 제미나이?

"누구나 아는 나만 모르는 제미나이" 책이 입문서라고 한다면,

"5분 제미나이" 책은 기본서 정도로 볼 수 있을 것 같다.

2권의 책 모두 S/W개발자만 위한 것이 아니고, 모두를 위한 책이다.

그리고, 정말 성의 충만한(?) 책이기도 하다.

동영상 강의 및 프롬프트를 포함해서 다양한 자료를 제공해주고 있다.

엑셀 파일도 그냥 시트 하나가 아니라 여러 개의 시트로 많은 것을 공유해준다.

목차를 보면 이 책의 특징을 더 확실하게 알 수 있다.

간단한 설명(워밍업) 후 다양한 실습을 통해 익히는 방식이다 ^^

모든 실습을 다 따라해보는 것이 좋지만 바쁜 사람들을 위해

수행 결과를 미리 살펴보고 마음에 드는 것만 선택해서 실습해볼 수도 있다.

이 책에서 여러 실습들이 블로그나 인스타그램 포스팅하는 것들인데,

개인적으로 AI를 이용해 이런 컨텐츠를 작성하는 것을 좋아하지 않는다.

'죽은 인터넷 이론(Dead Internet Theory)'에서 말하는 것과 같이

인터넷 컨텐츠와 소통의 대부분이 AI에 의해 자동 생성된 것이라면 ... 우리는 왜 ... 

사람이 작성한 것에 대한 편집 정도라면 괜찮겠지만 ... (할말하않)

개인적인 의견이다 !!!

그 외에 회의록을 정리한다던지, 보고서를 작성하는 것 등에 대한 실습은

실제 업무에서도 사용할 때 많은 도움이 되었다.

텍스트도 재미있지만,

특히 Nano Banana를 이용한 이미지 생성이 정말 재미있다.

책의 실습 내용을 살짝 변경해서 아래와 같은 이미지도 만들어 보았다.

책 표지의 앞뒤가 조금 어색하긴 하지만, 그래도 재미있는 결과를 만들어주었다.

손가락도 어색하지 않게 만들어주는 것을 보니 이제는 AI를 이용한 이미지 생성이 정말 대단한 수준까지 올라온 것 같다.

Canvas 기능도 ChatGPT 때 해보고 안해봤는데,

코딩이 아니라 자료 조사를 위해 사용해보니 재미있었다.

한 번만에도 꽤 쓸만한 결과를 보여주었다.

Canvas 특징을 살려서 추가 수정을 해봤는데, 역시나 잘 해주었다.

그런데, 사실 방금 해본 내용은 `Deep Research` 기능을 이용하는 것이 더 좋을 것 같다 ^^

...

이렇게 하나씩 따라가다보면 어느덧 구글에서 나온 다양한 AI 도구들에 모두 익숙해질 수 있을 것 같다 !!!

AI를 이용해서 글도 쓰고, 보고서도 쓰고, 홍보용 이미지도 만들고, 이것 저것 해보고 싶은 분들에게

강력하게 추천하는 책이다 !!!

오늘은 재미있는 컨텐츠로 포스팅 !!!

GPT, Gemini, Opus, Sonnet, Grok, DeepSeek 중에 누가 제일 똑똑할까?

아니, 누가 돈을 제일 잘 벌까?

아니, 아니, 누가 게임을 제일 잘 할까?

그 호기심에 대한 답까지는 아니지만,

살짝 엿볼 수 있는 재미있는 사이트가 있다.

LLM Holdem

- https://llmholdem.com/

LLM 끼리 둘러 앉아서 홀덤을 하고 있다 !!!

현재 순위를 한 번 살펴보면, GPT 5.2가 제일 잘 하고 있다.

- https://llmholdem.com/leaderboard

지켜보기만 하는 것은 재미가 없으니,

직접 `Create Room`을 해서 Join을 해보자.

나랑 상대할 LLM을 고를 수도 있다.

나쁜 것들!

나를 탕진시키고 지들끼리 게임을 하고 있다니 ... ㅠㅠ

대출 받아서 다시 참여할까? 하다가 ... 어?! 지들끼리 짜고 하는 거 아냐? 라는 생각이 ... ㅋㅋ

재미로 살펴보자 ^^

혼자 개발하면 외롭다.

특히, 코드 리뷰를 받고 싶은데 내 마음 같은 사람 만나기도 어렵고 ...

우리의 구글님은 이런 외로운 개발자를 위해서

공짜로 Gemini를 제공해주신다 !!! 경배하라 !!!

의외로 모르시는 분들이 많은데,

GitHub.com 왼쪽 메뉴를 살펴보면 `Marketplace`가 있다.

- https://github.com/ 

Marketplace에서는 여러 유형의 상품(?)을 제공해주고 있는데, `Apps` 항목을 살펴보자.

좀 더 편하게 살펴보기 위해 `AI Assisted` 카테고리를 선택하면 `Gemini Code Assist`를 발견할 수 있다.

오해를 줄이기 위해서는 `Gemini Code Assist for GitHub`이라고 해야할 것 같은데...

- https://github.com/marketplace/gemini-code-assist 

생각보다 설치 수가 좀 적어서 깜짝 놀랐다 !!

GitHub PR(Pull-Request)과 관련된 몇 가지 명령어를 제공해주고 있다.

우리의 구글님은 이런 아름다운 기능을 `Free`로 제공해주고 계신다 !! 경배하라 !!

하지만, 나중에는 십일조라도 받아가시겠지!? ^^

지금은 Free Tier 이지만,

나중에 얼마든지 십일조를 걷어가기 위해 `결제 정보`는 요구하고 있다.

개인 계정을 기준으로 설치할 수도 있고, Organization 단위로 설치할 수도 있다.

화끈하게 All repositorues를 선택해도 좋지만,

처음에는 조심스럽게(소심하게?) `Only select repositories`를 선택해보자.

이제서야 `Gemini Code Assis for GitHub`라고 자백하는구나 !!

우리의 구글님께 모든 권한을 바칩니다 !!! 

개인 계정 또는 Organization을 선택해야 한다.

리뷰의 정도를 선택할 수 있는 것 같은데, 일단은 Medium !

이 정도의 설정만 해주면 된다.

지정한 Repository의 Settings를 보면 잘 설치되어 있는 것을 확인할 수 있다.

이렇게 해놓은 상태에서, PR을 신규로 올리면 자동으로 코드 리뷰를 진행해준다.

그리고, 직접 명령을 내릴 수도 있다.

이렇게 명령을 내리면, gemini가 지켜보는 이모지가 등장한다 !! 귀엽다 !!

그렇게 시간이 좀 지나면, Gemini가 리뷰를 준다.

Summary는 기다림 없이 바로 이루어진다.

리소스 할당에 따라 지켜보는 이모지가 선택적으로 나오는 것일까?

코멘트 중간에 Gemini 홍보(광고? 안내? 공지?)도 들어있다.

무료인데 안쓸 이유는 없을 것 같다 !! 고고씽 !!