[SK플래닛] ASAC 빅데이터전문가 11기 | 31일차

31일차는 오전에는 Git 특강과 실습을 진행했고, 오후에는 AWS 기반 분석 자동화 흐름을 다룬 날이었다. Git은 단순히 팀 협업할 때만 쓰는 도구라고 생각하기 쉬운데, 이번에는 혼자 개발할 때도 변경 이력을 남기고 필요할 때 특정 시점으로 돌아가기 위해 필요하다는 점을 먼저 잡았다.

오후에는 S3 Tables / Iceberg 기반의 데이터, Athena SQL 실행, Bedrock 모델 호출, Markdown 보고서 생성 흐름을 봤다. 직접 분석 코드를 짜는 것에서 한 단계 더 나아가, 사용자의 질문을 받아 SQL을 실행하고 LLM으로 분석 보고서를 만드는 구조였다. 다만 이 과정에서도 LLM이 만든 SQL이나 해석 결과를 그대로 믿으면 안 되고, SQL 결과와 수치가 맞는지 확인해야 한다는 점이 중요했다.

1. Git은 GitHub가 아니라 버전 관리 도구였다

처음에 다시 잡은 개념은 Git과 GitHub의 차이였다. Git은 프로젝트의 변경 이력을 기록하는 분산 버전 관리 도구이고, GitHub는 Git 저장소를 원격으로 올리고 협업할 수 있게 해주는 호스팅 서비스다.

Git
= 버전 관리 도구

GitHub
= Git 저장소를 올려두는 원격 호스팅 서비스

예전에는 파일명을 최종, 진짜최종, 진짜진짜최종처럼 바꿔가며 관리했다면, Git은 파일의 변경 이력을 커밋 단위로 남긴다. 그래서 언제, 누가, 무엇을 바꿨는지 추적할 수 있고, 필요하면 이전 커밋으로 돌아갈 수 있다.

이 부분에서 Git이 협업용 도구이기도 하지만, 혼자 개발할 때도 필요하다는 말이 남았다. 프로젝트가 커지면 내가 언제 무엇을 바꿨는지도 헷갈리기 때문에, 초반부터 Git을 켜두고 작업하는 습관이 필요해 보였다.

2. Working Directory, Staging Area, Local Repository

Git 기초에서 가장 헷갈리기 쉬운 부분은 파일이 바로 커밋되는 것이 아니라는 점이었다. 파일을 수정하면 먼저 Working Directory에 변경사항이 생기고, git add를 하면 Staging Area에 올라간다. 그 다음 git commit을 해야 Local Repository에 이력이 저장된다.

Working Directory
→ 실제 파일을 수정하는 공간

Staging Area
→ 커밋할 파일을 준비하는 공간

Local Repository
→ 커밋이 저장되는 공간

실습에서는 lab1 폴더를 만들고, git init으로 저장소를 초기화한 뒤 README.md, index.js를 만들었다.

cd ~/git-labs/lab1

git init

echo "# My Project" > README.md
echo "console.log('hello');" > index.js

git status
git add .
git commit -m "feat: 프로젝트 초기 설정"

git log --oneline

이 흐름을 직접 해보니까 git status를 자주 확인해야 하는 이유가 보였다. 지금 파일이 추적되지 않은 상태인지, 스테이징된 상태인지, 커밋할 것이 없는 상태인지 계속 확인해야 실수를 줄일 수 있다.

3. commit 메시지는 나중에 보는 사람을 위한 기록이었다

커밋 메시지도 단순히 아무 말이나 적는 것이 아니었다. 수정, 작업중, fix처럼 적으면 나중에 이력을 봤을 때 무엇이 바뀌었는지 알기 어렵다. 그래서 Conventional Commits처럼 타입을 붙여 메시지를 쓰는 방식이 소개됐다.

feat: 로그인 API 연동 완료
fix: 회원가입 이메일 중복 검사 오류 수정
docs: README 설치 가이드 업데이트
refactor: UserService 메서드 분리

커밋은 단순 저장이 아니라 변경 이력이다. 그래서 커밋 메시지는 현재의 나보다 나중에 이 코드를 다시 볼 사람에게 더 중요할 수 있다. 이 부분은 기술 블로그 글 제목을 쓰는 것과도 비슷하게 느껴졌다. 짧지만 무엇이 바뀌었는지 드러나야 한다.

4. Branch와 merge, rebase는 이력을 다루는 방식이 달랐다

브랜치는 원래 코드와 독립적으로 기능을 개발할 수 있게 해주는 흐름이었다. 실습에서는 feat/login 브랜치를 만들어 로그인 기능을 추가하고, 다시 main으로 돌아와 병합했다.

git checkout -b feat/login

echo "function login() {}" >> index.js
git add index.js
git commit -m "feat: 로그인 함수 추가"

git checkout main
git merge feat/login

merge와 rebase의 차이도 봤다. merge는 브랜치의 이력을 그대로 보존하면서 합치는 방식이고, rebase는 브랜치 커밋을 대상 브랜치 뒤로 재배치해 선형 이력을 만드는 방식이다.

merge
= 이력 보존
= 공유 브랜치에서 안전

rebase
= 이력 정리
= PR 전 로컬 이력 정리에 적합
= 공유 브랜치에서는 주의

처음에는 rebase가 더 깔끔하니 항상 좋은 것처럼 보였는데, 공유된 브랜치에서 rebase를 하면 팀원들의 이력과 꼬일 수 있다는 점이 중요했다. 이력은 예쁘게 만드는 것도 중요하지만, 협업 상황에서는 안전한 방식이 먼저였다.

5. conflict는 Git이 판단을 멈춘 상태였다

충돌은 같은 파일의 같은 줄을 두 브랜치에서 서로 다르게 수정했을 때 발생했다. Git이 어느 쪽을 선택해야 할지 모르기 때문에 개발자에게 직접 판단을 맡기는 상황이었다.

<<<<<<< HEAD
version=1.5
=======
version=2.0
>>>>>>> branch-a

충돌 마커를 보면 위쪽은 현재 브랜치 내용이고, 아래쪽은 병합하려는 브랜치 내용이다. 해결할 때는 마커를 지우고 원하는 내용만 남긴 뒤 다시 git add, git commit을 해야 했다.

git status

# 파일 직접 수정 후
git add config.txt
git commit

이 부분에서 Git이 자동으로 모든 걸 해결해주는 도구는 아니라는 점이 보였다. 단순한 파일 이동이나 다른 줄 수정은 자동 병합할 수 있지만, 같은 줄을 다르게 바꾼 경우에는 결국 사람이 판단해야 했다.

6. reset, revert, stash는 되돌리는 목적이 달랐다

오전 실습에서는 작업을 되돌리는 여러 방법도 다뤘다. reset은 HEAD를 과거 커밋으로 옮기면서 이력을 지우는 방식이고, revert는 기존 커밋을 지우지 않고 그 내용을 취소하는 새 커밋을 추가하는 방식이었다.

reset
= 이력을 지운다
= push 전 로컬 정리에 적합

revert
= 이력을 추가한다
= 이미 공유된 브랜치에서 안전

reset도 세 가지 모드가 있었다.

--soft
= 커밋만 취소, staging 유지

--mixed
= 커밋과 staging 취소, 파일은 유지

--hard
= 커밋, staging, 파일 변경까지 되돌림

• -hard는 가장 위험하지만, 실수했더라도 reflog로 복구할 수 있다는 점도 같이 봤다. 그래도 공유 브랜치에서는 reset보다 revert를 쓰는 것이 안전하다는 점이 더 중요하게 남았다.

stash는 커밋하지 않은 작업을 잠시 보관하는 기능이었다. 아직 커밋하기 애매한 작업 중인데 급하게 브랜치를 바꿔야 할 때 사용할 수 있다.

git stash push -m "WIP: new feature 작업 중"

git stash list

git stash pop

pop은 꺼내면서 stash 목록에서 제거하고, apply는 꺼내도 목록에 남겨둔다. 이 차이는 여러 환경에 같은 변경사항을 적용해야 할 때 중요할 것 같다.

7. cherry-pick은 필요한 커밋만 가져오는 방식이었다

cherry-pick은 다른 브랜치의 특정 커밋만 현재 브랜치로 가져오는 기능이었다. 브랜치 전체를 merge하지 않고, 필요한 수정 하나만 가져올 수 있다는 점이 특징이었다.

git cherry-pick <commit_hash>

예를 들어 feat/api 브랜치에 여러 커밋이 있는데, 그중 버그픽스 커밋 하나만 main에 반영하고 싶을 때 사용할 수 있다. 다만 cherry-pick은 커밋을 복사하는 것이기 때문에 원본 커밋과 새 커밋의 해시는 달라진다.

이 기능은 편리하지만 남용하면 이력이 복잡해질 수 있다. 그래서 급한 핫픽스나 릴리즈 브랜치에 특정 커밋만 가져와야 할 때처럼 목적이 분명할 때 쓰는 게 좋아 보였다.

8. 오후에는 Athena와 Bedrock을 연결한 Skill 흐름을 봤다

오후에는 Git과는 다른 방향으로, AWS 기반 분석 자동화 흐름을 봤다. 핵심은 nemotron_kr.personas_new 같은 인구통계성 데이터를 대상으로, 사용자의 질문을 받아 SQL을 만들고 Athena로 실행한 뒤, Bedrock 모델이 인사이트를 생성해 Markdown 보고서로 출력하는 구조였다.

흐름은 대략 이렇게 정리됐다.

사용자 질문
→ 분석 차원 파악
→ SQL 템플릿 선택
→ Athena 실행
→ Bedrock으로 인사이트 생성
→ Markdown 보고서 출력

Skill 파일에서는 generate_report(user_question) 한 번으로 이 과정을 자동화하는 형태가 정리되어 있었다. 단, 중요한 제한도 있었다. Opus처럼 비싼 모델 호출은 금지되어 있었고, Sonnet이나 Haiku 모델을 사용해야 했다. 또 Athena workgroup은 student로 고정하고, LLM이 만든 SQL은 실행 전에 사람이 확인해야 한다는 조건도 있었다.

주의할 점

1. 비싼 모델 호출 금지
2. Athena workgroup은 student 사용
3. max_tokens 제한 확인
4. SQL 결과와 보고서 수치 일치 여부 검증
5. LLM이 만든 SQL은 사람이 확인

이 부분은 “AI가 보고서를 자동으로 만들어준다”보다 “AI가 중간 과정을 도와주지만, 실행 SQL과 수치 검증은 사람이 책임져야 한다”는 쪽으로 이해했다.

마무리

31일차는 오전과 오후의 주제가 달랐지만, 둘 다 “도구를 제대로 쓰려면 흐름을 알아야 한다”는 공통점이 있었다. Git은 단순히 명령어를 외우는 것이 아니라 Working Directory, Staging Area, Local Repository, Remote Repository 사이에서 변경사항이 어떻게 이동하는지 이해해야 했다. 그래야 branch, merge, reset, revert, stash, cherry-pick이 어떤 상황에서 필요한지 구분할 수 있었다.

오후의 AWS Skill 흐름도 마찬가지였다. 겉으로는 질문을 넣으면 보고서가 나오는 구조처럼 보이지만, 실제로는 SQL 템플릿 선택, Athena 실행, Bedrock 호출, Markdown 렌더링이 연결되어 있었다. 특히 LLM이 생성한 결과를 그대로 믿는 것이 아니라, SQL 결과와 보고서 수치가 맞는지 검증해야 한다는 점이 중요했다.

Git은 코드 이력을 안전하게 다루는 도구였고, AWS Skill은 분석 과정을 자동화하는 구조였다. 둘 다 편리하지만, 내부 흐름을 모르면 문제가 생겼을 때 어디서 틀어졌는지 찾기 어렵겠다는 생각이 들었다.

---

31일차는 Git으로 코드 변경 이력을 관리하는 흐름과, AWS 기반 Skill로 분석 보고서를 자동화하는 흐름을 함께 보면서 도구의 내부 단계를 이해해야 한다는 점을 확인한 날이었다.