머가필요해

스웨덴 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를 표시하려면 아래와 같이 묶어 주면 된다.

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

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

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

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를 수행할 수 있을 것이라 믿음이 생긴다.

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

Git을 이용해서 소스코드 버전 관리를 하며 개발을 한다고 하면서

branch와 code-review(pull-request)를 이야기하지 않으면 안될 것 같다.

[ Default Branch ]

Git을 처음 공부하면 기본적으로 main branch를 사용한다고 배울 것이다.

(master branch라고 하면 나이 많이 들었다고 인정하는 것이다 !!! 😅)

조금 더 공부하다보면 꼭 "main" 이름이 아니어도 된다는 것을 알 수 있다.

하지만, 그냥 "main"으로 정하는 것이 속편하다는 것도 알게된다.

그렇지만 GitHub을 사용한다면, `기본 브랜치(base branch)`를 변경하는 것이 상당히 쉽다.

그럼, 이렇게 설정한 default branch에는 바로 commit을 반영하지 못하고

반드시 Pull-Request를 통해서 approve 받은 내역만 merge가 되도록 설정을 해보자.

(오해는 하지 말아야 한다. 반드시 default branch에 대해서만 이렇게 할 수 있는 것은 아니다 !!!)

[ Branch protection rules ]

Repository의 Settings 메뉴 중 `Branches` 부분을 살펴보도록 하자.

기존 방식의 `Add classic branch protection rule` 항목이 아직도 보이지만,

현재 새로 힘을 주고 있는 rulesets 방식으로 살펴보도록 하자.

`Add branch ruleset` 버튼을 누르고 왼쪽 메뉴를 보면

`Rules` 항목으로 점프한 것을 볼 수 있을 것이다.

요즘 GitHub에서 Rules 부분으로 뭔가 다 모으고 있다.

`Rulesets` 항목이 여러가지인데,

지금 우리가 진행하는 항목은 `branch ruleset`이다.

Ruleset 이름은 편하게 지어주면 되고,

이렇게 만들어진 ruleset은 활성화 여부를 선택할 수 있다. (Enforcement status)

사용자들의 다양한 요구사항이 있어서인지

왠지 기존에 GitHub에서 잘 반영해주지 않던 Bypass와 같은 옵션도 추가가 되어 있다.

다음으로

어떤 branch에 지금 ruleset을 적용할 것인지 선택해보자.

pattern을 지원해주면서 정말 자유도가 확! 올라갔다.

지금은 그냐 default branch로 정하고 진행해보자.

한동안 살펴보지 않은 동안에, 정말 신기하고(?) 요상한 옵션들이 많이 생겼다. 공부 많이 해야할 것 같다😥

지금 중요한 옵션은 `Require a pull request before merging` 이다 !!!

다행히 예전(classic ?) 옵션들과 크게 바뀌지 않았다.

`Required approvals` 부분을 1 이상 값으로 넣어버리자 !!!

형상관리(소스코드 버전 관리)에서 가장 해로운 행위인 `force push` !!!

기본적으로 설정되어 있는 `Block force pushes` 옵션은 꼭 유지하자 !!!

이렇게 해서 만들게 되면 아래와 같이 Rulesets이 저장된다.

[ Practice ]

이렇게 적용하면 어떻게 되는지 살펴보자.

기존에 하듯이 commit 작성 후 `main` branch에 push를 하면 reject을 당한다.

코드리뷰(pull-request)를 받지 않은 commit을 집어넣으려고 하니 거절을 하는 것이다.

새로운 branch를 만들어서 그렇게 집어넣으면 이것은 잘 들어간다.

이렇게 되면 GitHub에서는 pull-request를 할거냐고 묻게 된다.

당연히 Pull-Request 생성하면 된다 !!

이렇게 만들어지면 앞에서 만든 Ruleset에 의해 제약이 걸리게 된다.

빨간 딱지들을 잘 봐야 한다.

리뷰를 반드시 받아야 하며(approve), 지금은 조건을 충족하지 못했기에 merge가 막혀있다 !!!

어?! 그런데, 어떻게 하지!?

나는 Pull-Request를 만든 사람이기에 approval을 할 수가 없다 😅

다른 누군가가 도와줘야 한다 😍

혼자서는 ... 코드리뷰를 동반한 S/W개발은 팀으로 해야하는 것이다 !!! ㅋ

혼자서라도 어떻게든 되도록 하고자 한다면,

`Required approvals` 값을 0으로 해야 한다.

AI Agent 세상에서 코드 리뷰의 필요성은 더욱 더 커졌다.

- 사람이 작성한 코드에 대한 AI 코드 리뷰

- AI가 작성한 코드에 대한 사람의 코드 리뷰

이러한 프로세스를 강제화 하고 자동화 하기 위한 기본 개발환경 설정을 살펴보았습니다.

최근 AI 에이전트를 이용하여 코딩 작업을 하면서

병렬로 동시에 여러 작업을 하는 경우에 유용한 기능으로 git worktree가 각광을 받고 있다.

git worktree가 어떤 기능을 제공해주는지

어떤 상황에서 필요로 하는지에 대해서 알아보고자 한다.

[ 준비 ]

실습을 해보기 위해서 저장소 하나를 clone 받아서 준비해보자.

[ 문제 상황 ]

feature-1 작업을 수행하기 위해 브랜치(branch)를 하나 생성해서 새로운 파일을 하나 만들었다고 해보자.

그런데, 갑자기 급하게 보안 이슈가 발생하여 hotfix 작업을 해야한다고 해보자.

feature-1 작업은 아직 진행 중이기에 commit까지 할 상황은 아니지만

지금까지 작업한 내용은 계속 보관을 하고 싶다고 하면 어떻게 해야할까?

[ 솔루션 #1 - new branch ]

그냥 다른 브랜치(branch)로 이동하면 되는 것 아닐까?

잠시 main 브랜치로 이동을 해보면 알겠지만,

feature-1 브랜치에서 작업하던 내용이 그대로 딸려온다.

여기에서 hot-fix-1 브랜치를 새로만들어도 마찬가지이다.

즉, 전에 작업하던 것을 잠시 치워놓고 다른 일을 할 수 있는 상황은 아니라는 것이다.

[ 솔루션 #2 - stash ]

이럴 때 가장 먼저 생각나는 방법은 `git stash` 명령어일 것이다(git 공부를 했다면 '이어야 한다'! ^^).

임시 보관이라는 말이 딱 어울리는 명령어이다.

변경 사항들을 모두 stash 명령어를 통해 따로 저장해놓으면,

현재 working directory는 깨끗해지게 된다.

`-u` 옵션은 추적하지 않는(untracked) 파일도 모두 stash 저장하라는 것이고,

`-m` 옵션은 stash 저장할 때 메모를 하도록 하기 위해 사용하는 것이다(여러 stash 저장 목록 구분을 위해).

이제 급한 hot-fix 업무를 처리한 후에

다시 돌아와서 전에 작업하던 내역을 불러와 계속 이어서 작업을 하면 되는 것이다.

그런데,

이렇게 좋은 stash 기능도 원하는 상황에 따라서는 충분하지 않을 수도 있다.

[ `새로운` 문제 상황 ]

`git stash` 기능이 정말 유용하긴 하지만,

만약 한 번에 하나의 작업이 아니라 동시에 여러 작업을 해야 한다고 하면 어떻게 해야할까?

앞서 말한 AI 에이전트가 동시에 여러 기능을 개발하도록 하고 싶은 경우,

여러 디렉토리에 각각 git clone 받아서 개발하도록 하면 될까?

그런데, 서로 개발 중인 내용을 주고 받는 것도 해야한다고 하면?

`stash`가 아니라 새로운 기능이 필요하다 !!!

[ 솔루션 #3 - worktree ]

현재 상태를 먼저 점검해보고, worktree를 사용해보자.

feature-1 브랜치에서 기존 파일 수정도 하고, 새로운 파일을 생성도 하던 중

긴급히 hot-fix를 진행해야 하는 상황에서 worktree를 사용하면 된다.

'git worktree add {디렉토리 경로} -b {새 브랜치 이름}` 형태로 사용하면 된다.

지정한 디렉토리 경로에 새로운 작업 공간을 마련하게 되기에

현재 디렉터리 하위 보다는 상위 경로로 지정해주는 것을 권장한다.

기존 branch를 사용할 때에는 `-b` 옵션을 사용하지 않아도 되지만

새로운 branch를 생성하도록 할 때에 `-b` 옵션을 사용하면 된다.

그런데, 여러 디렉토리에 각각 clone 받은 것과 어떤 차이가 있을까?

아래 예시를 자세히 살펴보자.

worktree로 생성된 hot-fix-1 작업 공간에서 새로운 작업을 하고 commit까지 했다.

`git log`를 통해서 당연히 새로운 commit까지 이력이 확인 된다.

그런데, 기존 디렉토리로 돌아가서 `git log`를 했는데 새로운 이력이 여기에서도 그대로 나온다.

그렇다!

worktree로 연결되어 있는 작업 공간끼리는 서로 공유 된다.

`git stash`로 잠시 저장해 놓은 이력들도 서로 공유하면서 이용할 수 있다.

삭제는 `git worktree remove {경로}` 명령어를 사용하면 된다.

AI 에이전트에서 이를 어떻게 활용하면 좋을지에 대해서는

각 AI 에이전트에 대해서 실습하면서 공부해보도록 하겠다.

저장소를 만든 후에 이름을 바꾸고 싶은 경우에 대해서 알아보자.

이번에도 저장소의 Settings 메뉴를 선택하면 된다.

제일 앞에 이름을 변경할 수 있는 부분이 보인다.

변경 후에 "Rename" 버튼만 누르면 된다.

끝났다 !!!

너무나 간단하다 !!!

GitHub에서 저장소 이름을 변경한다는 것은

저장소의 URL도 같이 변경된다는 것을 의미한다.

그러면, 저장소 이름을 변경하기 전에 이미 clone을 받은 사람은 어떻게 할까?

URL이 바뀌었기에 push, pull, fetch 등의 작업을 할 때 주소를 못찾게 된다 !

그렇기에 변경된 URL을 알려줘야만 한다.

바뀐 주소만 넣어주면 끝 !!! 😅

저장소를 생성했으면 삭제하는 방법도 알아보자.

삭제하고자 하는 저장소의 메뉴 중에서 Settings를 선택해보자.

제일 밑에 위치하고 있는 Delete this repository 부분을 찾으면 된다.

저장소를 삭제하면 복구가 안되기 때문에 뭔가 단계(절차)가 많다.

정말 삭제할 것이냐고 묻는다.

삭제하게 되면 어떤 일이 벌어지는 것인지 정말 이해하고 있냐고 묻는다.

그래도, 한 번 더 확인을 위해 번거롭지만 직접 저장소 이름을 타이핑하도록 하고 있다.

개인마다 상황이 다르겠지만, Passkey를 등록해놓은 경우 Passkey를 또 확인하고 있다.

이렇게 힘든 과정을 거쳐야지만 비로소 repository가 삭제 된다.

힘들다 !!! 😅