2026년 8월 19일부터 21일까지 2박 3일간 진행한 경북대 × 전남대 Physical AI 경진대회에서 AWS DeepRacer 과제로 최우수상을 받았다.

결과만 적으면 “빠른 모델을 만들어 상을 받았다”로 끝날 수 있다. 하지만 이번 대회에서 더 오래 남기고 싶은 것은 가장 빠르다고 믿었던 모델이 실차에서 가장 먼저 실패했고, 그 실패를 해석하면서 전략을 완전히 바꾼 과정이다.

시뮬레이터에서 이론적으로 최적인 경로는 실제 차에서 최적이 아니었다. 실제 환경에서는 짧은 경로보다 카메라 지연을 흡수할 여유, 노면과 배터리 변화에 대한 안정성, 그리고 빠르게 반복할 수 있는 튜닝 방법이 더 중요했다.

한 번의 실험에 2시간 30분이 걸렸다

가장 큰 제약은 학습 시간이었다. 모델 하나를 학습하고 평가한 뒤 실차에서 확인할 때까지 약 2시간 30분이 필요했다. 하나의 모델을 만들고, 결과를 본 다음, 다시 조금 고치는 순차적인 방식으로는 하루에 몇 번밖에 실험할 수 없었다.

그래서 처음부터 가설을 넓게 벌렸다. 최적 궤적, 곡률 기반 감가속, 중앙선 추종, 조향 변화 억제처럼 성격이 다른 가설 10개를 세우고 약 50개 모델을 병렬로 검증했다. 그중 살아남은 후보 다섯 개만 추가 학습과 실차 테스트 대상으로 좁혔다.

서로 다른 실패 방식을 가진 모델을 동시에 확보했기 때문에, 한 접근이 실차에서 무너졌을 때 다른 가설로 바로 전환할 수 있었다.

첫 번째 승자는 좌표 기반 최적 경로였다

첫 접근은 절대 좌표를 이용한 레이싱 라인이었다. 트랙 구조가 이미 주어졌다면 차가 시행착오로 모든 길을 탐색하게 하는 것보다 이동거리가 짧고 코너 반경이 큰 경로를 먼저 계산해 주는 편이 효율적이라고 판단했다.

A to Z Speedway의 센터라인 웨이포인트를 바탕으로 계산한 경로는 길이가 16.635m에서 15.409m로 약 7.4% 짧아졌다. 목표 좌표와 목표 속도를 보상 함수에 넣어 그 경로에 가까울수록 높은 점수를 주었다.

가상 환경에서는 예상이 맞았다. 좌표와 목표 속도를 함께 사용한 모델은 탈선 없이 안정적으로 수렴했고, 훈련 과정에서는 6초대 기록까지 나왔다. 평가에서도 좌표 모델이 중앙선 기반 모델보다 빨랐다. 이때까지만 해도 최종 모델은 이미 정해졌다고 생각했다.

시뮬레이터 6초대 모델이 실차에서 이탈했다

실차 결과는 정반대였다. 좌표 기반 모델은 코너에서 계속 트랙 반대쪽으로 이탈했다. 반면 시뮬레이터 기록이 상대적으로 느렸던 중앙선 추종 모델은 실제 트랙을 안정적으로 완주했다.

처음에는 학습 시간이 부족했거나 조향각이 작아서라고 의심했다. 하지만 좌표 모델은 가상 평가에서 탈선이 없고 랩타임 편차도 작았다. 학습이 덜 된 정책이라면 시뮬레이터에서도 먼저 흔들렸어야 했다. 문제는 수렴 여부가 아니라 시뮬레이터와 현실 사이의 차이, 즉 Sim2Real 격차였다.

좌표 보상은 자동차가 현재 트랙의 어느 지점에 있는지 알아내고 안쪽 경로에 붙도록 요구한다. 하지만 카메라 한 대만 사용하는 모델이 가상 환경에서 그 위치를 구분하려면 배경과 텍스처 같은 시뮬레이터 고유 단서를 외우기 쉽다. 실제 트랙에는 그 단서가 없었다.

18cm의 여유와 100ms 동안의 20cm

계산된 최적 경로와 흰 선 사이의 최소 여유는 약 18cm였다. 지연이 없는 시뮬레이터에서는 충분해 보이는 거리였다.

하지만 자동차가 2.0m/s로 달릴 때 카메라 인식과 조향 사이에 100ms의 지연이 생기면, 판단이 반영되기 전까지 이미 20cm를 더 이동한다. 18cm의 여유보다 지연 중 이동거리가 더 길다. 코너 안쪽을 노린 정책이 늦게 꺾으면 바깥으로 밀려날 수밖에 없었다.

반면 센터라인의 여유는 약 44cm였다. 최단거리는 아니지만 지연과 오차를 흡수할 공간이 있었다.

이론적인 최적 경로는 지연이 없는 세계에서만 최적이었다.

좌표를 버리고 중앙선으로 돌아오다

최종 모델에서는 좌표를 한 줄도 사용하지 않았다. 트랙 폭 대비 중앙선에서 얼마나 벗어났는지와 조향이 얼마나 급격하게 변하는지만 보았다. 절대 위치 대신 카메라가 실차에서도 동일하게 관찰할 수 있는 상대적인 단서를 사용했다.

액션 공간도 실차 관측에 맞췄다. 코너를 더 잘 돌게 하려고 25도와 30도 조향을 시도했지만, 큰 조향각에서는 바퀴가 헛돌았고 직선에서도 좌우로 흔들렸다. 최종 조향은 ±20도로 제한하고 큰 조향에서는 속도를 낮추고 직진에서는 속도를 높였다.

더 많은 선택지를 주는 것이 항상 더 좋은 정책으로 이어지지는 않았다. 실제로 전이되는 입력과 차가 물리적으로 실행할 수 있는 행동만 남기는 것이 더 강했다.

학습 밖의 손잡이: 스로틀과 출발 위치

최종 후보가 정해진 뒤에는 재학습보다 빠르게 반복할 수 있는 변수를 찾았다. 스로틀 배율은 즉시 바꿀 수 있었고 한 번의 주행은 수십 초면 끝났다. 같은 모델에서 배율을 2% 단위로 올리며 이탈하지 않는 경계선을 찾았다.

장소를 옮기자 같은 배율에서도 실제 속도가 달라졌다. 노면 마찰과 배터리 상태가 바뀌면 이전 장소의 숫자를 그대로 재사용할 수 없었다. 그래서 최종 주행에서는 배율 하나로 전체 랩을 묶지 않았다. 직선에서는 75%, 코너 진입 전에는 62%로 낮추고, 코너를 통과하면 다시 75%로 올렸다. 출발 위치도 뒤로 옮겨 직선에서 가속할 거리를 확보했다.

학습이 병목일 때 성능을 올리는 방법이 반드시 추가 학습인 것은 아니었다. 모델 밖에서 초 단위로 반복할 수 있는 손잡이를 찾는 것이 더 높은 기대값을 만들었다.

최우수상, 그리고 다시 한다면

결국 좌표 기반 최단 경로가 아니라 중앙선 기반의 안정적인 모델을 선택했고, 실차에서 속도와 조향을 다시 맞춘 전략으로 최우수상을 받았다.

다시 한다면 다음 원칙을 가장 먼저 적용할 것이다.

1. 트랙 방향을 기본값에 맡기지 않고 학습 전에 확인한다.
2. 시뮬레이터 순위를 실차 순위로 해석하지 않는다.
3. 절대 좌표보다 실제 센서에서도 유지되는 상대적 단서를 우선한다.
4. 지연 × 속도보다 큰 여유폭을 확보한다.
5. 학습 시간이 병목이면 가설을 벌려 병렬로 검증한다.
6. 스로틀, 출발 위치, 구간 제어처럼 학습 밖에서 빠르게 반복할 변수를 찾는다.

이번 수상의 핵심은 처음부터 정답을 맞힌 것이 아니었다. 서로 다른 가설을 준비했고, 가장 유력한 가설이 현실에서 실패했을 때 그 이유를 수치로 설명한 뒤 다른 접근으로 전환할 수 있었던 점이었다.

실험 기록과 코드

보상 함수, 모델별 평가 결과, 실차 스로틀 튜닝 기록과 실패 원인은 아래 공개 저장소에 정리했다.

• GitHub: https://github.com/TaeHuiKKIM/deepracer-physical-ai

단순히 우승 모델의 코드만 남기기보다, 시뮬레이터에서 잘되던 접근이 왜 실차에서 실패했는지와 어떤 판단을 거쳐 최종 모델을 선택했는지를 함께 기록했다.

div 몇 개 줄였는데 화면 흔들림이 사라지고 첫 클릭도 빨라졌다. 개미 투자 게임을 다듬을 때 실제로 겪은 일이다.

처음에는 “HTML 노드가 많아서 느리다” 정도로 이해했다. 하지만 DOM 수만 세어서는 왜 레이아웃이 흔들렸고, 왜 첫 입력에 긴 작업이 생겼는지 설명할 수 없었다. HTML은 화면이 아니다. 브라우저가 HTML·CSS·JavaScript를 읽고, 여러 중간 구조를 거쳐 픽셀로 바꾸는 과정을 알아야 숫자의 의미가 보였다.

HTML이 픽셀이 되기까지

브라우저는 네트워크에서 받은 HTML을 파싱해 DOM을 만든다. CSS는 CSSOM이 되고, 둘을 바탕으로 실제로 그릴 요소를 추린 렌더 트리가 만들어진다. 이후 대략 다음 단계가 이어진다.

1. Style: 어떤 CSS 규칙이 어떤 노드에 적용되는지 계산한다.
2. Layout: 각 요소의 크기와 위치를 정한다.
3. Paint: 텍스트, 배경, 테두리처럼 무엇을 그릴지 기록한다.
4. Composite: 여러 레이어를 적절한 순서로 합성해 화면에 올린다.

이 흐름을 한 번만 수행하고 끝나는 것은 아니다. JavaScript가 class를 바꾸거나, 이미지 크기가 뒤늦게 결정되거나, 폰트가 교체되면 일부 단계가 다시 필요할 수 있다.

그래서 “DOM 한 개를 추가했다”는 말에는 비용이 하나만 들어 있지 않다. 그 노드가 스타일 계산 범위를 넓히는지, 주변 배치를 다시 계산하게 하는지, 넓은 영역을 다시 그리게 하는지에 따라 결과가 달라진다.

DOM 개수만 줄이면 빨라질까

노드가 많으면 스타일과 레이아웃 후보도 많아질 수 있으니 DOM 크기는 유용한 신호다. 다만 만능 점수는 아니다.

• 2,000개의 단순한 정적 노드와 200개의 복잡한 애니메이션 노드는 비용 구조가 다르다.
• transform으로 움직이는 요소와 레이아웃 속성을 계속 바꾸는 요소도 다르다.
• 보이지 않는 목록을 모두 렌더링하는 것과 화면 근처만 가상화하는 것은 노드 수 이상의 차이를 만든다.
• selector 구조, 이미지 크기, 폰트, JavaScript 실행 시간도 함께 봐야 한다.

DOM 개수는 원인 확정값이 아니라 “렌더링 경로를 더 살펴보라”는 계기판에 가깝다.

특히 CLS(Cumulative Layout Shift) 는 단순히 노드가 많다는 뜻이 아니다. 이미지나 광고의 공간을 미리 잡지 않았거나, 늦게 나타난 콘텐츠가 기존 요소를 밀어낼 때처럼 사용자가 예상하지 못한 위치 변경을 합산한 지표다. 노드가 적어도 큰 영역이 움직이면 CLS는 커질 수 있다.

내 프로젝트에서 확인한 렌더링 병목

개미 투자 게임의 v235 성능 기록에서는 로컬 Chromium의 정해진 시나리오 기준으로 다음 변화가 남아 있다.

이 숫자는 모든 기기와 모든 실행에서 보장되는 벤치마크가 아니다. 당시 로컬 환경에서 같은 흐름을 비교한 회귀 기록이다. 그래도 무엇을 함께 고쳤는지는 분명했다.

• 시작부터 만들 필요가 없는 UI를 늦게 생성했다.
• 처음 보이는 화면의 구조를 단순화했다.
• 나중에 나타나는 요소가 기존 배치를 밀지 않도록 공간과 표시 순서를 조정했다.
• 첫 클릭 안에 몰려 있던 초기화 작업을 준비 단계와 작은 단위로 나눴다.

DOM 1,110개를 지운 것만으로 CLS가 0이 된 것이 아니다. 필요한 시점에 필요한 구조만 만들고, 뒤늦게 생길 요소의 자리를 예측 가능하게 만든 것이 함께 작용했다.

이 경험 이후에는 Lighthouse 점수 하나보다 Performance 패널의 Main thread, Layout Shift 영역, 긴 task 내부의 call stack을 먼저 본다. 숫자가 나빠졌다면 “React라서”, “DOM이 많아서”라고 결론 내리기 전에 어느 단계가 오래 걸렸는지 좁히는 편이 정확했다.

렌더링 최적화에서 먼저 볼 순서

내가 다음 프로젝트에서 사용할 순서는 이렇다.

1. 사용자 시나리오를 고정한다

첫 진입, 첫 클릭, 목록 필터, 모달 열기처럼 느리다고 느낀 행동을 하나 고른다. 서로 다른 행동의 수치를 섞으면 개선 전후가 비교되지 않는다.

2. 메인 스레드에서 긴 작업을 찾는다

50ms를 넘는 task는 사용자 입력이나 다음 프레임을 오래 기다리게 할 수 있다. 그 안에서 스크립트 실행, 스타일, 레이아웃, 페인트 중 어디에 시간이 쓰였는지 본다.

3. 레이아웃 이동의 원인을 화면과 연결한다

Layout Shift 항목을 클릭해 실제로 움직인 요소를 찾는다. 이미지 width·height, 비동기 콘텐츠 자리, 웹폰트, 삽입되는 배너를 확인한다.

4. 구조를 바꾼 뒤 같은 시나리오로 다시 잰다

DOM 개수만 비교하지 않는다. 입력 응답, 긴 task, CLS, LCP를 함께 남기고 부작용도 기록한다.

직접 해볼 실습

아래처럼 높이가 없는 이미지와 늦게 삽입되는 배너를 가진 작은 페이지를 만든다.

<main>
  <h1>오늘의 상품</h1>
  <img src="large-product.jpg" alt="상품">
  <section id="list"></section>
</main>

1. Chrome DevTools Performance에서 새로고침을 기록한다.
2. Layout Shifts와 Main thread의 긴 task를 확인한다.
3. 이미지에 실제 비율과 맞는 width, height를 준다.
4. 1,000개 항목을 한 번에 넣는 버전과 50개만 넣는 버전을 비교한다.
5. DOM 수, CLS, scripting·layout 시간을 표로 남긴다.

목표는 무조건 좋은 점수를 만드는 것이 아니라, 어떤 코드 변경이 어떤 렌더링 단계를 바꿨는지 한 문장으로 설명하는 것이다.

공부하면서 확인할 질문

• DOM과 렌더 트리는 왜 같은 구조가 아닐까?
• display: none인 요소와 visibility: hidden인 요소는 렌더링 과정에서 어떻게 다를까?
• transform 애니메이션이 top·left 변경보다 유리할 수 있는 이유는 무엇일까?
• CLS가 0이어도 첫 클릭이 느릴 수 있는 이유는 무엇일까?
• 노드 수를 줄였는데 성능이 그대로라면 다음에는 어떤 기록을 볼까?

공식 참고자료

• MDN — Critical rendering path
• MDN — How browsers work
• web.dev — Optimize long tasks

• ADSP 취득
• 평균학점 4.21/4.3 달성
• 해달 해커톤 인기상 수상
• CODE-MEDI 해커톤 최우수상 수상
• 자료구조 / 자료구조응용 / 컴퓨터구조 / 운영체제 / 알고리즘 실습 / SW진로설계 / 프로그래밍기초 한번에 수강
• 각종 대회(모의투자 및 실전투자대회 4건 등) 및 세미나 참여
• 카카오테크캠퍼스 4기 Agentic AI 과정 합격 후 1학기 수료
• 개발 동아리, 사진 동아리, 과생활, 벌크업 등등.....

가장 어려운 과목들을 몰아듣고, 대외활동도 열심히 한만큼 정말 바쁜 1학기였다.

뿌듯하게 학기를 마치고 방학에 게임 제작, 각종 공모전 출전, 토이 프로젝트 등을 진행하면서 드는 생각을 적어본다.

요즘 가장 흔들리는 질문은 이것이다.

AI가 코드를 이렇게 잘 짜는데, 지금 언어와 자료구조를 공부하는 게 맞을까?

나도 AI에게 프로젝트를 맡겨 보면 놀랄 때가 많다. 화면을 만들고, 테스트를 추가하고, 배포 설정까지 이어 간다. 그러다 실행이 안 되는 한 줄을 만나면 더 크게 당황한다.

코드는 받았는데 왜 틀렸는지 설명하지 못하고, 어디까지 고쳐도 되는지 판단하지 못하면 속도는 빨라졌는데 실력은 남지 않는다.

그래서 내 결론은 “코딩을 덜 공부하자”가 아니다.

문법 암기의 비중은 줄이고, 코드를 판단하고 검증하고 운영하는 공부를 늘리자.

AI가 잘 짜 준 코드가 터졌을 때 남는 사람

AI가 정상 경로를 빠르게 만드는 능력은 이미 좋다. 하지만 실제 프로젝트에서는 이런 문제가 남는다.

• 같은 요청이 두 번 들어오면 결제가 두 번 되는가?
• localStorage가 중간에 깨지면 사용자의 저장은 복구되는가?
• 이미지가 12MB인데 화면이 뜨기만 하면 끝인가?
• 외부 문서 안의 prompt injection이 도구 호출로 이어지는가?
• 테스트는 통과하지만 요구사항 자체를 잘못 이해한 것은 아닌가?

이 질문은 “코드를 생성할 수 있나”보다 “시스템이 왜 이렇게 동작하나”에 가깝다.

운영체제, 네트워크, DB, 보안, 테스트를 알아야 AI가 만든 코드의 위험한 부분이 보인다. 컴퓨터 구조를 배우는 이유도 CPU 시험 문제를 맞히기 위해서만은 아니다. 캐시, 메모리 접근, 병렬성, ISA의 차이가 실제 성능과 런타임 선택으로 이어지는 지점을 보기 위해서다.

내가 쌓을 다섯 층

1층: Python으로 문제를 끝까지 푸는 힘

코딩테스트 언어는 Python으로 고정할 생각이다.

언어를 여러 개 얕게 돌기보다 아래 범위를 반복한다.

• list, dict, set, heap, deque
• 정렬, 이분 탐색, 누적 합, 투 포인터
• DFS/BFS, 최단 경로, union-find
• greedy와 dynamic programming
• 시간·공간 복잡도 설명

목표는 “문제를 많이 풀었다”가 아니라 풀이 뒤에 세 문장을 말할 수 있는 상태다.

왜 이 자료구조인가?
시간 복잡도는 얼마인가?
어떤 입력에서 깨지는가?

주 5문제를 기준으로 잡되, 새 문제 3개와 복습 2개로 나눈다. 틀린 문제는 코드만 저장하지 않고 실패 원인과 다시 볼 날짜를 GitHub Issue에 남긴다.

2층: 컴퓨터 구조·운영체제를 코드와 연결하기

이번에 배운 RISC, CISC, EPIC 글을 쓰는 이유도 같다. 개념을 외우는 데서 끝내지 않고 최신 CPU와 OS까지 연결해 보려고 한다.

• ISA와 microarchitecture 구분
• pipeline, branch prediction, cache locality
• process, thread, context switch
• virtual memory, page fault, mmap
• lock, race condition, atomicity
• file descriptor, socket, system call

작은 실험도 같이 한다.

• Python list 순회와 NumPy 연산의 차이 측정
• sequential access와 random access 비교
• thread와 process의 CPU-bound 차이
• 파일을 한 번에 읽기와 streaming 비교

개념 글 하나, 실험 코드 하나, 측정 결과 하나를 묶으면 면접에서도 “배웠다”보다 강한 증거가 된다.

3층: 백엔드와 데이터

AI 프로젝트도 결국 사용자의 요청, 상태, 권한, 실패를 다루는 서비스다.

Python 기반으로 다음 조합을 깊게 가져가려고 한다.

• FastAPI
• Pydantic
• pytest
• PostgreSQL과 SQL
• Redis의 캐시·rate limit·queue 사용
• Docker와 Linux 배포

CRUD만 만드는 데서 끝내지 않고 아래를 프로젝트마다 하나씩 증명한다.

• idempotency
• transaction
• index 전후 query plan
• pagination
• timeout과 retry
• migration과 rollback
• structured logging

4층: AI를 제품으로 만드는 능력

모델 API를 한 번 호출하는 것과 AI 시스템을 만드는 것은 다르다.

• RAG 검색 품질
• tool calling 계약
• eval dataset
• hallucination과 fallback
• token·latency·cost
• prompt injection과 권한
• deterministic path와 model path 분리

KB AI Challenge에서는 금융처럼 틀렸을 때 비용이 큰 도메인을 경험하고, 카카오테크캠퍼스 Agentic AI 과정에서는 도구 사용과 평가를 더 체계적으로 익히고 싶다.

모델 이름을 포트폴리오 전면에 쓰기보다 다음 숫자를 남길 것이다.

task success rate
tool-call accuracy
p50 / p95 latency
request당 token과 비용
fallback 발생률
위험 행동 차단 test 통과율

5층: 읽히는 증거 만들기

GitHub에 프로젝트가 많아도 채용 담당자가 무엇을 봐야 하는지 모르면 약하다.

그래서 README와 Velog의 역할을 나누려고 한다.

• README: 문제, 내 역할, 구조, 실행, 측정 결과
• docs: 의사결정, 트러블슈팅, 실험 기록
• Issue: 주간 학습 목표와 회고
• Velog: 한 가지 판단을 깊게 설명
• Demo: 3분 안에 핵심 흐름을 보여 줌

“기술을 사용했다”보다 “왜 선택했고 무엇이 바뀌었는가”를 남기는 게 목표다.

2026 하반기부터 1년 계획

2026 여름: KB AI Challenge

산출물 목표는 모델 결과만이 아니다.

• baseline과 개선 모델 비교
• 금융 안전 규칙
• prompt·dataset 버전
• offline eval
• 오류 사례 20개 이상 분류
• 데모와 3분 설명

Challenge가 끝나면 성과를 “참가” 한 줄로 끝내지 않고, 공개 가능한 설계와 실패 사례를 글 2편으로 남긴다.

2026 하반기: 카카오테크캠퍼스 Agentic AI + 종합설계

두 활동을 따로 놀게 하지 않을 생각이다.

Agentic AI에서 배운 tool calling, evaluation, security를 종합설계에 적용한다. 종합설계는 가능하면 연구실 또는 기업 연계 주제로 선택하고, 다음 중 하나를 분명히 잡는다.

• source-aware RAG
• 금융·의료처럼 규칙이 중요한 agent
• 온디바이스 또는 local-first AI
• agent observability와 eval

결과물은 논문 흉내보다 재현 가능한 실험이 우선이다.

가설 → baseline → 변경 → 측정 → 실패 분석

2026 겨울: 해외 인턴·해외 탐방

해외 경험도 “다녀왔다”보다 역할이 중요하다.

지원 전까지 영어 1분 자기소개, 프로젝트 3분 설명, 기술 질문 20개 답변을 준비한다. GitHub README 핵심 프로젝트 3개는 영문 요약을 붙인다.

교내 및 학과에서 지원하는 해외인턴 프로그램에 도전한다.

11월 초에는 경북대학교 대표 5명으로 선발되어 중국 청두의 여러 기관들을 탐방하는것이 계획되어있다.

2027 상반기: 인턴과 취업용 압축

프로젝트를 더 늘리는 대신 대표 3개를 고친다.

1. 금융 agent: 안전한 tool use와 eval
2. 종합설계: 연구·기업 문제와 측정
3. 제품 프로젝트: 실제 사용자 UX와 성능

각 프로젝트는 테스트, 배포, 문서, 장애 대응까지 갖춘 상태로 만든다.

자격증은 무엇을 준비할까

우선순위는 다음과 같다.

1. SQLD/ADSP: DB·SQL 기본기를 증명하면서 백엔드 공부와 직접 연결
2. 정보처리기사: 국내 대기업·공기업 지원 범위를 넓히는 안전장치
3. 토익 갱신 / 오픽 AL: 해외 인턴 지원 자격과 면접 준비를 위해 필요한 수준 확보

클라우드 자격증은 AWS 서비스를 실제 프로젝트에서 운영해 본 뒤 하나만 선택한다. 자격증 공부가 프로젝트의 Linux, Docker, 네트워크, DB 시간을 침범하면 미룬다.

스타트업·대기업 개발 직무가 우선이라면 자격증보다 코딩테스트, CS, 프로젝트 설명력이 앞선다. 공기업 가능성까지 열어 두고 싶을 때 정보처리기사와 영어가 보험 역할을 한다.

프로젝트를 평가하는 내 점수표

새 프로젝트를 시작하기 전 아래 질문에서 4개 이상 “예”가 아니면 보류한다.

• 실제 사용자가 겪는 문제가 있는가?
• 기존 내 프로젝트와 다른 기술적 난점이 있는가?
• 전후를 측정할 수 있는가?
• 테스트로 고정할 계약이 있는가?
• 공개 가능한 데모나 문서가 남는가?
• 면접에서 5분 이상 깊게 설명할 수 있는가?

AI 덕분에 프로젝트를 시작하는 비용은 낮아졌다. 그래서 더 중요한 것은 시작 개수가 아니라 완성 기준이다.

느낀 점

AI가 코드를 다 짜 준다는 말은 반은 맞다. 초안을 만드는 속도는 이미 사람이 따라가기 어렵다.

하지만 무엇을 만들지, 어떤 결과를 믿을지, 실패했을 때 어디까지 허용할지, 측정 없이 무엇을 주장하면 안 되는지는 여전히 사람의 몫이다.

내가 준비할 방향은 “AI보다 코드를 빨리 치는 사람”이 아니다.

AI가 만든 코드를 시스템 안에서 검증하고, 안전하게 연결하고, 결과를 숫자로 설명하는 사람.

앞으로 1년은 새 기술 이름을 수집하는 시기가 아니라 이 능력을 증거로 바꾸는 시기로 만들려고 한다.

처음 아이디어를 생각했을 때 가장 먼저 떠오른 기능은 자연어 송금이었다.

"딸에게 30만원 보내줘."

사용자가 계좌번호와 메뉴를 찾지 않아도 말로 송금할 수 있다면 편리할 것 같았다. 하지만 금융 서비스에서 편리함만 생각할 수는 없었다.

LLM은 같은 입력에도 결과가 달라질 수 있고, 잘못된 계좌나 금액을 추정할 수 있다. 프롬프트를 아무리 자세하게 작성해도 모델의 판단만으로 실제 돈을 움직이게 하는 것은 위험했다.

그래서 프로젝트의 기준을 다음 한 문장으로 정했다.

AI는 사용자의 말을 이해하고 설명하지만, 돈을 움직이는 결정은 사용자가 확인한 규칙과 서버 코드가 담당한다.

이번 글에서는 자연어를 이해하는 AI와 금융 실행을 통제하는 코드를 어떻게 분리했는지 정리하려고 한다.

1. LLM이 잘 판단하게 만드는 것만으로는 부족했다

처음에는 프롬프트에 금융 사기 사례와 주의사항을 많이 넣으면 모델이 위험한 송금을 잘 찾아낼 수 있을 것이라고 생각했다.

하지만 프로젝트를 구체화하면서 세 가지 문제가 보였다.

같은 입력에도 결과가 흔들릴 수 있다

LLM의 분류는 확률적이다. 정상 거래를 위험하다고 판단하거나, 위험 거래를 정상이라고 판단할 수 있다.

모델이 근거를 만들어낼 수 있다

사용자가 말하지 않은 관계나 목적을 추정하면 그럴듯하지만 사실과 다른 설명이 만들어질 수 있다.

모델 실패가 금융 실행 실패로 이어질 수 있다

공급자 장애, timeout, JSON 형식 오류가 발생했을 때 송금 제어까지 함께 멈추거나 잘못된 상태로 진행되면 안 된다.

그래서 LLM의 성능을 높이는 것과 별개로, 모델이 틀려도 위험한 실행이 일어나지 않는 구조가 필요했다.

2. AI, 규칙, 실행의 역할을 나누기

전체 흐름을 단순화하면 다음과 같다.

사용자 음성·텍스트
  → AI 또는 결정론 파서가 거래안을 구조화
  → 결정론 머니룰이 ALLOW / HELD / BLOCKED 판정
  → 필요한 확인 단계 진행
  → 통과한 거래에만 일회용 승인 토큰 발급
  → 서버가 토큰을 한 번 소비한 뒤 모의 송금 실행

각 구성요소의 역할을 명확하게 나누었다.

AI가 하는 일

• 사용자의 자연어에서 송금 의도와 슬롯 후보 찾기
• 자연어 규칙을 정해진 JSON 초안으로 변환
• 사용자에게 판정 이유와 다음 행동을 쉽게 설명
• 규칙을 만들 때 빠진 조건을 제안

AI가 하지 않는 일

• 규칙 자동 저장
• 송금 승인 토큰 발급
• 보류된 거래의 임의 해제
• 서버의 판정 덮어쓰기
• 실제 송금 실행

결정론 코드가 하는 일

• 사용자가 확인한 규칙과 신고계좌 검사
• ALLOW, HELD, BLOCKED 판정
• 확인 단계와 승인 가능 여부 결정
• 승인 토큰 검증·소비
• 판정 근거를 규칙 ID와 사람이 만든 문장으로 반환

AI가 만든 결과를 바로 실행하지 않고, 정해진 schema와 서버 규칙을 통과한 값만 다음 단계로 보낸다.

3. 위험 점수만으로 돈을 막지 않은 이유

처음에는 위험 점수가 높으면 송금을 차단하는 방식이 단순해 보였다.

하지만 위험 신호는 항상 사기를 의미하지 않는다.

• 처음 보내는 계좌
• 평소보다 큰 금액
• 여러 번 나누어 보내려는 요청
• 긴급하다는 표현

이런 신호는 정상 거래에서도 나타날 수 있다. AI의 위험 점수만으로 돈을 막으면 정상 사용자가 자신의 금융 거래를 할 수 없게 된다.

그래서 위험 신호는 확인 강도를 높이는 데 사용하고, 강제 중단은 사용자가 미리 만든 규칙이나 신고계좌처럼 명시적인 근거가 있을 때만 수행하도록 했다.

위험 신호
  → 질문과 사람 확인을 강화

사용자 규칙 위반 / 신고계좌
  → 실행 중단

모델이 사용자를 대신해 결정하는 것이 아니라, 사용자가 만든 안전 약속을 코드가 집행하는 구조다.

4. L0부터 L4까지 확인 단계를 나누기

모든 송금에 같은 수준의 마찰을 주면 정상 거래가 불편해진다. 반대로 모든 거래를 간단한 확인만으로 처리하면 위험 상황에서 충분한 보호가 되지 않는다.

그래서 거래 상황에 따라 확인 단계를 나누었다.

L1부터 L3는 AI가 돈을 차단하는 단계가 아니다. 필요한 확인 행동과 확인 주체를 강화하는 과정이다.

반면 L4는 사용자가 직접 정한 한도나 금지 수취인, 신고계좌처럼 명시적인 근거가 있기 때문에 승인 토큰 자체를 발급하지 않는다.

5. 프론트엔드의 완료 상태를 믿지 않기

화면에서 사용자가 확인 버튼을 눌렀다는 사실만으로 송금을 실행하면 안 된다.

프론트엔드 상태는 조작되거나 오래된 탭에 남아 있을 수 있다. 네트워크 재시도로 같은 요청이 두 번 전달될 수도 있다.

그래서 서버가 일회용 승인 토큰을 발급하고, 실행할 때 다음을 검사하도록 했다.

• 현재 거래와 연결된 토큰인가
• 필요한 질문과 사람 확인이 끝났는가
• 이미 사용된 토큰은 아닌가
• 규칙 판정이 바뀌지 않았는가

토큰은 서버가 한 번 소비한 뒤 다시 사용할 수 없다.

화면에서 "승인됨"
        ≠
서버가 실행해도 되는 거래

Agentic AI에서 중요한 것은 모델이 어떤 tool을 호출하는지뿐 아니라, tool이 실제로 실행될 수 있는 권한을 서버가 어떻게 통제하는지라는 생각이 들었다.

6. 공급자 장애를 숨기지 않는 실행 모드

외부 LLM 공급자를 사용하는 기능은 네트워크와 API 상태에 영향을 받는다.

데모에서 온라인 AI가 실패했는데 결정론 응답으로 조용히 바뀌면 겉으로는 정상처럼 보일 수 있다. 하지만 어떤 엔진이 실제로 동작했는지 알 수 없고, 온라인 AI를 검증했다는 주장도 할 수 없다.

그래서 실행 모드를 세 가지로 구분했다.

Offline

외부 LLM을 호출하지 않는다. 결정론 파서와 기본 안내로 전체 사용자 흐름을 재현한다.

Auto

온라인 tool calling을 먼저 시도한다. 실패하면 결정론 경로로 폴백하지만 실제 실패 원인과 사용된 엔진 상태를 기록한다.

Live

시작할 때 실제 공급자 연결을 확인한다. 연결이 실패하면 시작 또는 요청을 실패 상태로 표시하고 offline 응답으로 위장하지 않는다.

이렇게 나누니 API 키가 없는 환경에서도 핵심 흐름을 재현하면서, 온라인 AI가 실제로 연결되었다는 주장과 오프라인 데모를 구분할 수 있었다.

7. 기능 목록보다 평가 가능한 흐름 만들기

대회 준비를 하다 보면 새로운 모델과 기능을 계속 추가하고 싶어진다.

파인튜닝, embedding 기반 RAG, 서버 STT까지 모두 넣으면 기술적으로 더 화려해 보일 수 있다. 하지만 실제로 완료하지 못한 기능을 README에 구현된 것처럼 적는 것은 피하고 싶었다.

그래서 먼저 다음 흐름을 끝까지 연결하는 것을 목표로 잡았다.

음성 또는 텍스트 입력
  → 자연어 규칙을 정해진 규칙으로 변환
  → 사용자가 복창 확인 후 저장
  → 정상 송금은 일반 확인
  → 의심 거래는 추가 질문·사람 확인
  → 규칙 위반·신고계좌는 실행 중단
  → 보호자에게 최소정보 알림
  → 대시보드에서 판정 근거와 평가 수치 확인

그리고 골든셋으로 다음을 확인했다.

• 자연어 규칙이 정해진 schema로 변환되는가
• 정상 거래를 과도하게 막지 않는가
• 사기·규칙 위반 거래에서 필요한 개입이 발생하는가
• 같은 입력에 결정론 판정이 재현되는가
• 사례 검색이 필요한 근거를 상위 결과에서 찾는가

모델의 답변을 몇 번 눈으로 보는 것보다, 실패 유형을 정하고 같은 기준으로 반복 평가할 수 있는 구조가 더 중요했다.

8. 구현한 것과 준비만 한 것을 구분하기

현재 구현 범위를 정리하면서 표현을 특히 조심했다.

예를 들어 사례 검색은 현재 정해진 사례에서 관련 내용을 찾는 retrieval 중심 프로토타입이다. 검색 문서를 LLM에 넣어 새로운 답변을 생성하는 generation-grounded RAG까지 완성한 것은 아니다.

파인튜닝도 마찬가지다. 학습 코드와 설정, 소량의 SFT 데이터를 준비했지만 실제 GPU 학습과 학습 전후 성능 비교가 끝나지 않았다면 "파인튜닝 완료"라고 쓸 수 없다.

코드가 존재함
    ≠
학습·연결·평가가 완료됨

이 경계를 README와 기술 설명서에 명확하게 남기는 것이 결과물을 덜 화려하게 보이게 할 수는 있다. 그래도 다른 사람이 저장소를 보고 5분 안에 실제로 재현할 수 있는 범위를 정확하게 알려주는 편이 더 중요하다고 생각했다.

9. 이번 프로젝트에서 배운 점

이번 프로젝트를 시작하기 전에는 Agentic AI의 핵심을 tool을 많이 연결하고 모델이 스스로 판단하게 만드는 것이라고 생각했다.

지금은 권한의 경계를 설계하는 일이 더 중요하다고 생각한다.

LLM은 자연어에 강하지만 금융 실행 권한을 갖지 않는다.
결정론 코드는 예측 가능하지만 사용자 의도를 이해하지 못한다.
사용자는 최종 규칙과 중요한 거래를 확인한다.
서버는 그 확인이 실제 실행 조건을 만족하는지 검증한다.

각 구성요소가 잘하는 일을 맡고, 한 구성요소의 실패가 바로 금융 실행으로 이어지지 않도록 경계를 만드는 것이 이번 프로젝트의 핵심이었다.

이번 프로젝트의 KPT

Keep

• AI와 결정론 코드의 역할을 문서와 코드에서 함께 구분한 점
• 외부 API 키 없이도 전체 흐름을 재현할 수 있게 만든 점
• 기능을 추가하기 전에 골든셋과 완료 기준을 먼저 정한 점
• 구현하지 않은 범위를 미완료라고 명확하게 표시한 점

Problem

• 음성 인식과 실제 사용자 테스트가 아직 충분하지 않다.
• 합성 데이터 중심이라 실제 시니어 사용자의 표현을 모두 반영하지 못했다.
• 온라인 모델의 장애·회복 시나리오를 더 다양한 조건에서 검증할 필요가 있다.

Try

• 시니어 사용자 과업 테스트와 음성 실패 사례 수집
• 정상 거래 오차단률과 개입 단계별 과업 성공률 측정
• 공급자 timeout·잘못된 tool arguments·재시도 상황을 자동 테스트로 고정
• 대회 이후 공개 가능한 평가 코드와 합성 데이터 정리

이 글은 2026 KB AI Challenge 제출 이후 공개 가능한 범위를 다시 확인하고 발행할 예정이다. 현재는 프로젝트의 설계 과정과 배운 점을 정리한 초안이다.

지난주까지는 사용자의 자연어 요청을 구조화하고 SQLite에 저장한 뒤 다시 조회·수정·삭제하는 흐름을 만들었다. 이번에는 저장된 정보를 검색해 답변의 근거로 사용하는 RAG를 학습했다.

처음에는 검색 함수 하나를 만들고 질문을 넣으면 알아서 관련 정보를 찾아주는 구조를 생각했다.

하지만 실제 데이터는 한 곳에 있지 않았다.

• 사용자가 미리 등록한 참고자료
• SQLite에 저장한 일정·할 일·알림
• 예전에 나눈 채팅 대화

세 데이터는 저장된 장소도 다르고 검색 방법도 달랐다. 같은 "기억 검색"이라고 부르더라도 하나의 함수로 뭉뚱그릴 수 없었다.

이번 글에서는 검색을 출처별 tool로 나누면서 알게 된 점과, 리뷰 피드백을 반영하며 audit log와 확정 데이터의 차이를 구분하게 된 과정을 정리하려고 한다.

1. RAG는 하나의 마법 함수가 아니었다

RAG를 처음 접했을 때는 문서를 embedding한 다음 질문과 비슷한 내용을 찾아 LLM에게 전달하는 한 가지 흐름만 생각했다.

이번 과제에서 다룬 나나의 기억은 세 갈래였다.

개인 참고자료 ── ChromaDB Vector Search ─┐
                                          │
저장된 일정 ─── SQLite 조건 검색 ─────────┼─→ Agent가 출처에 맞는 tool 선택
                                          │
과거 대화 ───── SQLite → ChromaDB Sync ───┘

각 출처에 다음 tool을 연결했다.

개인 참고자료

search_personal_references
  → PersonalReferenceStore
  → ChromaDB + OpenAI embedding

미리 추가해 둔 참고자료를 의미 기반으로 검색한다. 질문의 단어가 문서와 완전히 같지 않아도 embedding 거리를 이용해 관련 내용을 찾을 수 있다.

저장된 요청

search_saved_requests
  → AppSQLiteStore.search_saved_requests
  → SQLite 검색

일정·할 일·알림처럼 이미 구조화된 데이터는 SQLite에 저장되어 있다. 이 데이터는 제목, 날짜와 요청 종류처럼 명확한 필드가 있으므로 모든 것을 벡터로 만들기보다 기존 저장소의 검색 기능을 사용하는 편이 자연스러웠다.

과거 대화

search_conversation_messages
  → ConversationRAGStore.sync_from_sqlite
  → ChromaDB search

과거 대화 원문은 SQLite에 있지만 의미 기반으로 찾기 위해 검색 직전에 ChromaDB와 동기화한 후 벡터 검색을 실행한다.

처음에는 세 tool을 나누는 것이 코드만 늘리는 일처럼 보였다. 실제로 구현해 보니 출처별로 나누어야 어떤 데이터가 답변의 근거가 되었는지 설명할 수 있고, 저장소에 맞는 검색 방식을 선택할 수 있었다.

2. 같은 검색이어도 반환 계약이 달랐다

이번 과제에서는 tool마다 반환해야 하는 최상위 key가 정해져 있었다.

• 참고자료 검색: hits
• 저장 요청 검색: rows
• 대화 검색: hits, rows, context, rag_backend, sync

이전 주차에는 tool 결과를 ok, tool_name 같은 공통 껍데기로 감싸 사용했다. 이번 계약은 hits와 rows가 top-level에 있어야 했다.

처음에는 기존 껍데기를 모두 버리고 과제에서 요구한 key만 남겨야 하나 고민했다. 그렇게 하면 이전 tool들과 응답 모양이 완전히 달라져 일관성이 깨질 것 같았다.

그래서 계약이 요구하는 key는 반드시 최상위에 두고, 기존의 ok와 tool_name도 옆에 유지하는 방식으로 정리했다.

{
  "ok": true,
  "tool_name": "search_personal_references",
  "hits": [
    {
      "content": "...",
      "metadata": {
        "title": "...",
        "tags": ["..."]
      }
    }
  ]
}

참고자료 검색 결과도 store가 반환하는 모양과 tool 계약이 요구하는 모양이 달랐다. store는 title, tags를 hit의 최상위에 펼쳐 주었지만 tool 응답에서는 metadata 안에 들어가야 했다.

결국 store가 반환한 값을 그대로 노출하는 것이 아니라, tool이 외부에 제공하는 계약에 맞게 변환하는 계층이 필요했다.

3. 현재 대화를 과거 기억처럼 검색하지 않기

대화 RAG에서 가장 신경 쓴 부분은 현재 대화 제외였다.

사용자가 방금 한 말을 검색 대상으로 바로 포함하면, agent가 현재 입력을 과거의 기억처럼 다시 가져올 수 있다.

예를 들어 사용자가 다음과 같이 말한다고 가정한다.

"내일 병원 가는 거 기억해줘."

현재 대화를 제외하지 않으면 검색 결과에서 방금 입력한 문장이 "과거 대화에서 찾은 근거"처럼 나타날 수 있다. 기능상 결과가 비슷해 보여도 출처의 의미가 잘못된다.

그래서 conversation_id가 별도로 주어지지 않은 경우 current_session_scope()에서 현재 대화 ID를 가져와 exclude_conversation_id로 전달하도록 했다.

반면 tool을 독립적으로 직접 호출하는 DEFAULT_SESSION_SCOPE에서는 제외할 현재 대화가 없기 때문에 조건을 다르게 처리했다.

이 부분을 따라가면서 현재 대화, 과거 대화, tool 직접 실행이 서로 다른 실행 문맥이라는 것을 배웠다.

4. 검색 직전에 대화를 동기화하기

과거 대화 원문은 SQLite에 저장되고, 의미 검색은 ChromaDB가 담당한다.

두 저장소가 따로 존재하면 새로운 대화가 SQLite에는 있지만 벡터 저장소에는 아직 없는 상황이 생길 수 있다.

그래서 search_conversation_messages는 검색 직전에 sync_from_sqlite를 호출한다.

SQLite 대화
   ↓ lazy sync
ChromaDB
   ↓ vector search
검색 결과

동기화 결과에는 다음 정보가 포함됐다.

• upserted
• skipped
• deleted

스모크 테스트에서 이 값들이 실제로 바뀌는 것을 확인했다. 저장과 검색 사이에 동기화 과정이 있다는 것을 코드로만 읽는 것보다 결과 숫자로 보는 것이 훨씬 이해하기 쉬웠다.

다만 검색할 때마다 동기화하는 방식이 데이터가 커져도 효율적인지는 별개의 문제다. 지금은 과제 규모에서 정확한 결과를 만드는 데 집중했지만, 이후에는 이벤트 기반 동기화나 변경분만 반영하는 구조도 비교해 보고 싶다.

5. top_k를 tool에서만 제한하면 충분할까

제출 후 리뷰에서 내부 helper의 top_k 처리에 대한 피드백을 받았다.

실사용 경로에서는 tool이 top_k를 안전한 범위로 보정한 뒤 helper를 호출했다. 그래서 현재 동작만 보면 문제가 없어 보였다.

하지만 내부 helper인 search_conversation_message_rows를 다른 코드가 직접 호출하면 보정되지 않은 값이 그대로 저장소에 전달될 수 있었다.

현재 경로가 안전함
        ≠
함수 자체가 항상 안전함

그래서 helper에도 동일하게 safe_limit을 적용했다.

이 경험을 통해 안전장치를 호출하는 쪽 한 곳에만 둘지, 데이터를 실제로 사용하는 경계에도 둘지 생각하게 됐다. 재사용될 수 있는 내부 함수라면 함수 자체가 유효한 범위를 보장하는 편이 더 안전했다.

6. Audit Log와 확정 일정은 다른 데이터였다

이번 리뷰에서 가장 많이 배운 부분이다.

호환용 통합 검색인 search_nana_memory는 저장된 일정의 근거를 structured_requests에서 가져오고 있었다.

처음에는 사용자가 입력한 요청이 모두 들어 있으니 근거로 사용해도 된다고 생각했다. 하지만 store를 다시 따라가 보니 structured_requests는 요청이 들어올 때마다 쌓이는 원본 audit log에 가까웠다.

같은 일정을 여러 번 요청하거나 수정하면 다음 문제가 생길 수 있다.

• 같은 일정이 여러 행으로 중복됨
• 수정 전 값과 수정 후 값이 함께 검색됨
• 현재 확정된 일정이 무엇인지 판단하기 어려움

반면 schedules는 정규화된 확정 일정이다. 일정이 수정되면 최신 상태로 갱신되고, 현재 사용자에게 보여줘야 하는 값 하나가 유지된다.

structured_requests
  → 사용자가 어떤 요청을 보냈는지 추적하는 audit log

schedules
  → 현재 확정된 일정 상태

그래서 일정 검색 근거를 find_schedules로 변경했다.

두 테이블 모두 일정과 관련된 데이터를 갖고 있지만 목적은 달랐다. "데이터가 있다"는 이유만으로 검색 근거로 사용하지 않고, 어떤 질문에 답하기 위한 데이터인지 구분해야 했다.

7. 직접 확인한 것

이번 과제도 RAG와 ChromaDB가 익숙하지 않아 Claude Code의 도움을 많이 받았다.

대신 각 tool이 어느 저장소를 호출하고 어떤 형태로 결과를 돌려주는지는 직접 따라가려고 했다.

스모크 테스트에서는 다음을 확인했다.

• 참고자료 검색 결과에 top-level hits가 있는가
• 저장기록 검색 결과에 top-level rows가 있는가
• 대화 검색에 hits, rows, context, rag_backend, sync가 있는가
• 참고자료의 title, tags가 metadata 안에 있는가
• 현재 대화가 검색 결과에서 제외되는가
• top_k가 helper를 직접 호출해도 제한되는가
• 통합 검색의 일정 근거가 audit log가 아니라 확정 일정에서 나오는가

ChromaDB가 embedding을 만드는 내부 원리나 거리 함수에 대해서는 아직 모르는 부분이 많다. 현재는 distance가 작을수록 가까운 결과라는 정도와, 저장소·tool·응답 계약이 어떻게 연결되는지를 먼저 이해한 상태다.

8. 이번 주에 바뀐 RAG에 대한 생각

처음에는 RAG를 "문서를 벡터 DB에 넣고 검색하는 기술" 정도로 생각했다.

이번 과제를 마친 뒤에는 다음 요소를 함께 봐야 한다고 생각하게 됐다.

무엇을 검색하는가
어디에 저장되어 있는가
어떤 검색 방식이 맞는가
현재 문맥에서 제외할 데이터는 무엇인가
검색 결과를 어떤 계약으로 반환하는가
답변에 사용할 수 있는 최신 상태인가
출처를 설명할 수 있는가

검색 정확도만큼 중요한 것은 출처와 데이터의 역할을 구분하는 일이었다.

앞으로는 현재 대화 제외와 top_k 보정을 스모크 테스트가 아니라 단위 테스트로 고정해 보고 싶다. 또한 검색된 결과가 최종 답변에 실제로 어떻게 포함되는지 agent trace를 더 자세히 확인할 생각이다.

이번 학습의 KPT

Keep

• tool마다 실제로 호출하는 저장소를 따라가며 출처를 구분한 점
• 반환 JSON의 key를 스모크 테스트로 직접 확인한 점
• 리뷰 질문에 바로 답하지 않고 store를 다시 읽어 근거를 찾은 점

Problem

• embedding과 ChromaDB 내부 동작에 대한 이해가 아직 얕다.
• 호환용 통합 검색은 이전 trace가 없어 context 형식을 완전히 확신하기 어려웠다.
• 현재 대화 제외를 자동 테스트로 고정하지 못했다.

Try

• 현재 대화가 검색에서 빠지는지 fake store를 이용한 단위 테스트 작성
• 벡터 검색의 distance와 top_k 변화에 따른 결과 비교
• 검색 결과가 최종 답변의 어느 문장에 사용됐는지 trace로 확인
• SQLite와 ChromaDB 동기화 비용 측정

관련 학습 기록

• Week 08 — 구조화 결과 SQLite 저장/조회
• Week 09 — 출처별 RAG tool

처음 Agentic AI를 접했을 때는 LLM이 사용자의 말을 이해해서 일정을 알아서 저장해 주는 것이라고 단순하게 생각했다. 채팅창에서 "내일 오후 3시에 팀 회의 잡아줘"라고 말했을 때 자연스러운 답변이 돌아오면 기능이 잘 동작한다고 생각하기도 했다.

그런데 3주 동안 Tool Call, Structured Output, SQLite를 차례대로 붙여보니 실제 구조는 전혀 달랐다.

LLM은 일정을 직접 저장하지 않는다. 모델이 하는 일은 어떤 도구를 어떤 인자로 호출할지 결정하거나, 자연어를 프로그램이 읽을 수 있는 구조로 정리하는 것에 가깝다. 실제 실행과 저장은 우리가 작성한 코드와 데이터베이스가 담당한다.

사용자 자연어
  → LLM이 요청을 이해
  → Tool Call 또는 Structured Output 생성
  → Pydantic 스키마 검증
  → Python tool 실행
  → SQLite 저장
  → Tool Result를 모델에게 전달
  → 사용자에게 최종 답변

이번 글에서는 이 흐름을 직접 구현하면서 무엇을 배웠고, 어떤 부분에서 생각이 바뀌었는지 정리하려고 한다.

1. 모델의 답변과 실제 실행은 다른 일이었다

첫 주에는 LangChain의 @tool을 사용해 개인 일정 생성·조회·삭제 기능을 구현했다.

• personal_create_schedule
• personal_list_schedules
• personal_delete_schedule

사용자가 일정 생성을 요청하면 모델은 personal_create_schedule이라는 tool과 필요한 arguments를 만든다. 하지만 모델이 일정을 저장하는 것은 아니다. 실제 함수가 실행되어 저장소에 payload를 추가하고, 그 결과가 Tool Result로 다시 모델에게 전달된다.

처음에는 최종 답변만 자연스러우면 잘 동작한다고 생각했다. 하지만 Gradio의 trace JSON을 열어보니 답변과 실제 상태가 다를 수 있다는 것을 알게 됐다.

예를 들어 모델은 "일정을 저장했어요"라고 답할 수 있지만 다음과 같은 문제가 숨어 있을 수 있다.

• date가 잘못 계산됨
• attendees가 누락됨
• 다른 대화의 일정이 함께 조회됨
• 삭제 tool이 잘못된 schedule_id를 받음
• Tool Call은 만들어졌지만 저장소가 변경되지 않음

그래서 이후부터는 최종 답변보다 먼저 아래 세 가지를 확인하게 됐다.

1. 어떤 tool_name이 선택됐는가
2. 어떤 arguments가 전달됐는가
3. 저장소의 실제 결과가 어떻게 바뀌었는가

특히 일정이 대화마다 섞이지 않도록 현재 session 범위 안에서 생성·조회·삭제되게 처리하면서 scope가 왜 필요한지도 체감했다. 같은 저장소를 사용하더라도 어떤 사용자의 어느 대화에서 만들어진 데이터인지 구분하지 않으면, 기능은 동작해도 서비스로는 사용할 수 없기 때문이다.

2. 자연어를 바로 실행하지 않고 구조화하기

다음 주에는 자연어 요청을 바로 tool로 실행하기보다 StructuredRequest라는 정해진 스키마로 변환했다.

일정 요청에는 생각보다 많은 정보가 들어간다.

제목 / 날짜 / 시작 시간 / 참석자 / 요청 종류 / 개인 또는 그룹 일정

사람은 "다음 주 화요일 세 시에 민수랑 회의"라는 문장을 자연스럽게 이해하지만, 뒤쪽 코드가 이 문장을 그대로 처리하기는 어렵다. 표현이 조금만 달라져도 조건문이 계속 늘어날 수 있기 때문이다.

Pydantic 모델로 필드와 타입을 고정하면 뒤쪽 로직은 자연어 전체를 다시 해석하지 않고 정해진 값을 사용할 수 있다.

"다음 주 화요일 세 시에 민수랑 회의"

          ↓

kind: group_schedule
title: 회의
date: 2026-07-14
start_time: 15:00
members:
  - 민수

처음에는 JSON 모양으로만 나오면 충분하다고 생각했다. 실제로는 상대 날짜와 분류 경계가 문제였다.

상대 날짜는 기준일이 필요했다

"내일", "다음 주 화요일" 같은 말은 기준 날짜가 없으면 계산할 수 없다. 그래서 프롬프트에 base_date를 명확하게 전달하고, 기준일이 2026-07-08일 때 "다음 주 화요일"이 2026-07-14로 나오는지 직접 확인했다.

모델이 날짜를 잘 계산할 것이라고 믿는 것과, 기준을 주고 결과를 검증하는 것은 다른 일이었다.

참석자가 있는데도 개인 일정으로 분류됐다

참석자가 있는 일정인데도 결과의 kind가 가끔 개인 일정으로 나왔다. 모델이 먼저 선택한 tool 이름에 영향을 받아 그룹 일정을 개인 일정처럼 분류하는 경우가 있었다.

그래서 참석자가 한 명이라도 있으면 group_schedule로 판단하라는 규칙을 프롬프트에 추가했다. 수정 후에는 같은 시나리오를 세 번씩 실행해 결과가 흔들리지 않는지 확인했다.

한 번 성공한 결과는 모델의 안정성을 보장하지 않는다. 같은 입력을 반복해서 실행해 본 것이 이번 과제에서 가장 중요한 검증 중 하나였다.

Structured Output인데도 Extra data 오류가 났다

모델이 JSON 뒤에 "일정 잡았어요" 같은 문장을 붙이면 StructuredOutputValidationError("Extra data")가 발생했다.

처음에는 Structured Output을 사용했는데 왜 JSON 파싱 오류가 발생하는지 이해되지 않았다. 결국 구조화 데이터 뒤에 자연어가 추가되면서 스키마 검증을 방해한다는 것을 알게 됐다.

그래서 ToolStrategy(StructuredRequestBatch)를 사용해 구조화 결과를 tool call 인자로 받도록 바꾸었다. 이후 반복 실행에서 같은 오류가 발생하지 않는 것을 확인했다.

3. 저장과 영속성은 다른 문제였다

세 번째 주에는 구조화된 요청을 SQLite에 저장하고 다시 조회·수정·삭제하는 흐름을 붙였다.

1주차에는 일정이 메모리 저장소에 들어갔다. 앱을 켜둔 동안에는 잘 보였지만 프로세스를 다시 시작하거나 새 대화를 만들면 데이터가 사라질 수 있었다.

처음에는 "리스트에 넣던 것을 DB에 넣으면 되는 것 아닌가"라고 생각했다. 직접 해보니 이번 주차의 핵심은 저장 방식보다 영속성이었다.

현재 대화에서 저장됨
        ≠
앱을 다시 켜거나 새 대화를 시작해도 남아 있음

구현한 주요 기능은 다음과 같다.

• 구조화 요청 저장
• 저장된 요청 목록·단건 조회
• 일정 수정
• 조건을 이용한 삭제
• 레거시 payload 정규화

입력 검증, 실행, 저장의 역할을 나누기

이번에는 @tool(args_schema=...) 방식도 사용했다.

처음에는 tool 함수 안에서 값을 다시 Pydantic 모델로 만들어 한 번 더 검증해야 마음이 놓일 것 같았다. 하지만 코드를 따라가면서 역할이 다음처럼 나뉜다는 것을 이해했다.

Pydantic schema  → 입력 검증
Tool             → 실행 흐름
SQLite store     → 저장과 조회

각 계층이 같은 검증을 반복하는 것이 아니라 자기 책임을 분명하게 갖는 구조였다.

조건 없는 삭제는 막았다

가장 신경 쓴 부분은 삭제였다.

id, 날짜, 제목처럼 삭제 대상을 좁히는 조건이 하나도 없는데 삭제 요청이 실행되면 저장된 일정이 전부 사라질 수 있다. 기능을 편하게 만드는 것보다 실수로 데이터를 통째로 지우지 못하게 만드는 것이 더 중요하다고 판단했다.

그래서 삭제 조건이 비어 있으면 아무것도 삭제하지 않도록 막았다.

이 경험을 통해 Agentic AI에서 안전장치는 모델에게 "조심해서 실행해"라고 말하는 것이 아니라, 위험한 동작이 코드 수준에서 실행되지 못하도록 만드는 것에 가깝다는 생각이 들었다.

4. 새 대화를 만들어 직접 검증하기

SQLite 코드가 있다고 영속성이 증명되는 것은 아니다. 실제로 저장하고 새로운 대화에서 다시 읽히는지 확인해야 했다.

먼저 agent에 다음 요청을 보냈다.

"내일 오전 10시에 개인 코칭 일정 저장해줘"

trace에서는 다음 순서로 tool이 호출됐다.

extract_schedule_request
  → save_structured_request
  → SQLite 저장

그다음 agent를 새로 만들어 새 대화처럼 시작했다.

"내가 저장한 일정 보여줘"

이전 대화에서 저장한 개인 코칭 일정이 그대로 조회되는 것을 확인했다. 단순히 DB 파일에 행이 생긴 것을 보는 것보다, 실제 사용자 흐름으로 저장과 조회가 연결되는 것을 확인했을 때 가장 뿌듯했다.

경계 조건도 함께 확인했다.

• 없는 id를 조회했을 때 row=None이 나오는가
• 조건 없는 삭제가 거부되는가
• None인 필드가 불필요하게 저장되지 않는가
• 저장 → 목록 → 단건 조회 → 수정 → 삭제 순서가 모두 이어지는가

5. AI를 사용하면서도 직접 확인하려고 한 것

이번 과제들은 아직 Python과 LangChain이 익숙하지 않아 Claude Code의 도움을 많이 받았다.

AI가 제안한 코드를 활용한 것 자체를 숨기기보다, 그 코드를 어느 수준까지 이해하고 검증했는지가 더 중요하다고 생각했다.

그래서 다음 부분은 직접 확인하려고 했다.

• 각 tool이 실제로 어떤 store 메서드를 부르는지 따라가기
• 반환 JSON과 trace의 key를 눈으로 확인하기
• 상대 날짜와 그룹 분류를 같은 입력으로 반복 실행하기
• 임시 DB에서 CRUD 흐름을 순서대로 실행하기
• agent를 새로 만들어 영속성을 사용자 흐름으로 검증하기

아직 Python 문법과 프레임워크 구조를 읽는 속도는 느리다. 다만 AI가 코드를 만들어주었다는 이유로 동작 원리를 건너뛰지 않고, 적어도 입력·실행·저장·결과가 어떻게 이어지는지는 설명할 수 있게 됐다.

6. 3주 동안 달라진 생각

처음에는 Agentic AI를 "대답을 잘하는 챗봇"에 가깝게 생각했다.

지금은 조금 다르게 보고 있다.

Agentic AI
= 자연어 이해
+ 구조화된 계약
+ 실제로 실행되는 코드
+ 저장소
+ 실패를 막는 안전장치
+ 결과를 확인하는 trace와 테스트

자연스러운 답변은 사용자 경험에 중요하지만, 실제 데이터를 다루는 서비스에서는 tool arguments와 저장 결과가 더 먼저 검증되어야 한다.

앞으로는 tool 하나를 처음부터 끝까지 AI 도움 없이 구현해 보고 싶다. 그리고 현재는 스모크 테스트로 확인한 경계 조건들을 단위 테스트로 고정해, 나중에 코드를 수정해도 같은 문제가 다시 생기지 않도록 만들 생각이다.

이번 학습의 KPT

Keep

• 최종 답변보다 tool arguments와 저장소 결과를 먼저 확인한 점
• 한 번 성공한 결과를 믿지 않고 같은 시나리오를 반복 실행한 점
• 지난 회고에서 정한 "작업 전 최신 main 반영"을 실제 습관으로 옮긴 점

Problem

• Python과 LangChain이 익숙하지 않아 AI가 작성한 코드를 이해하는 데 시간이 많이 걸렸다.
• Structured Output을 사용하면 항상 안정적인 결과가 나온다고 단순하게 생각했다.
• 스모크 테스트는 했지만 경계 조건을 자동으로 고정한 단위 테스트가 부족했다.

Try

• tool 하나를 처음부터 끝까지 직접 구현하기
• 조건 없는 삭제와 현재 세션 범위를 단위 테스트로 고정하기
• 저장 결과가 최종 답변의 근거로 사용되는 과정까지 trace로 확인하기

관련 학습 기록

• Week 06 — Agentic AI와 Tool Call
• Week 07 — 자연어를 구조화된 요청으로 변환하기
• Week 08 — 구조화 결과 SQLite 저장/조회

무휴학 편입 특성상 편입 직전의 집중도 있는 학습과 연속적인 편입 시험으로 너무 바빠서 한동안 벨로그를 작성하지 못했다.

그래서 지난 기간동안 어떤 성과를 냈는지 정리하고 넘어가려고 한다.

길고 길었던 편입 준비가 좋은 결과로 끝났고 새로운 학교에서는 백엔드와 더 깊이있는 코딩테스트 위주로 학습하면서 전공 공부에 매진할 생각이다.

앞으로는 배운 개념이나 이론 위주의 블로그 보다는 프로젝트나 학습하면서 느낀점들 위주로 작성해보려고 한다.

SQLD 취득

바쁜 와중에 데이터베이스설계와 데이터관리 수업을 듣고 SQL에 입문한 뒤 일주일 빠짝 공부해서 SQLD 취득에 성공했다.

어짜피 시험 범위였기에 미리 자격증을 따고 수월하게 A+를 받았다.

체육대전 농구 우승

경영학부의 에이스 선배들 덕분에 많이 뛰지도 않고 우승 트로피를 만졌다.

기여도 4%..? 경기 안뛸때는 벤치에서 응원 열심히 했다.

정작 열심히 한 배구는 예선 탈락했다는 사실..

교내 SW경진대회 장려상 수상

Python, C++ 라이브러리를 활용하는 고학년들의 경쟁속이었다.

C랑 자료구조 알고리즘 공부하면서 백준 골드를 달성한 김에 C언어로 용감하게 대회에 신청하였다.

C언어로 큐를 직접 구현해가면서 문제를 푼 사람은 나밖에 없었던 것 같다.

어짜피 편입 시험 범위니까 공부한다는 생각으로 출전했는데 필요한 자료구조를 직접 구현하며 절반 정도 풀고나니 시간이 부족해서 더 풀 수가 없었다.

그래도 장려상이라도 받았으니 만족스럽다.

경북대학교에서는 Java로 전향하여 백준 플레티넘과 각종 알고리즘 대회 수상을 목표로 나아가려고한다.

시흥실록지리지(로컬 창업 경진대회) 장려상 수상

정말 많은 시간을 할애했지만 아쉽게도 가장 낮은 상을 수상하였다.

한국공학대학교라 그런건지 공학 관련 창업 아이템들이 상을 휩쓸었고 바이럴 마케팅이 메인 주제였던 우리의 서비스는 열띤 발표에도 불구하고 교수님들을 끝내 설득하지 못했다.

그래도 담당 공무원과 인터뷰를 잡고 직접 진행해보고, 각종 전문가들에게 문의하면서 견적내고, 각종 활동에서 여러 멘토님들도 만나면서 인사이트가 많이 넓어진것 같다.

또한 최고급 호텔 스위트룸에서 밤새 프로젝트에 몰두해보기도 하고, 창업 전문가들, 교수님들, 기자들, 수많은 학우들 앞에서 여러 차례 발표해볼 수 있는 좋은 경험이었다.

각종 대회 출전 경험

창업 경진대회에 조원으로 참여하기도 하였고, 제주 공공데이터 활용 공모전에도 과감하게 출전하였으나 예선 탈락하였다.

JSP 쇼핑몰 프로젝트

GITHUB - MERCI JSP

JSP로 개발한 반응형 쇼핑몰 웹사이트 프로젝트이다.

상업적인 목적은 없으며 데이터베이스 연동 학습 목적으로 개발하였다.

https://wellbeingexpress.com

위 사이트의 메인 페이지 디자인을 참고하였으며 의류 이미지를 샘플 데이터로 사용하였다.

*구현한 기능 * 물품 관리 - 등록/수정/삭제 - 품목 별 리뷰 고객 관리 - 회원가입 / 계정 삭제 / 로그인(소셜) 및 비밀번호 변경 - 찾기 / 상품 찜 기능 / 주소지 저장 및 불러오기 (도로명주소 API) 주문 관리 - 결제 확인 및 주문 완료 변경 / 리뷰 등록-수정-삭제 주문 및 결제(장바구니 및 대행사 활용) - AJAX 활용하여 사용 편의성 향상 문의 관리 - QNA 등록 수정 삭제 물품 카테고리별 나열 및 검색 소개 페이지 및 수정 페이지

이외에도 디테일적인 부분들이 많고 결제는 대행사 테스트용 API를 활용했다.

2학년 수료 및 편입 시험 준비

평균 평점 4.41로 한국공학대학교 2학년을 수료하였고 방학 동안은 편입 시험 공부에 집중하였다.

레드 블랙 트리나 AVL 트리의 삭제 등 심화적인 부분까지 대비하였다.

처음엔 이해가 안갔는데 구현해본 코드를 외우고 설명할 정도까지 학습하고 나니까 이젠 쉽게 느껴진다.

C++도 학습하며 STL 라이브러리의 활용과 각종 자료구조를 사용하는 코드를 구현하는걸 타이핑이 아니라 연필로 써가며 무한 반복하였다.

*이산수학 / C / C++ / 자료구조 *등 출제범위가 광범위하기에 내가 아무리 공부해도 모르는게 나와버리면 어떡하지라는 불안감속에서 끊임없이 반복학습하였다.

시험 직전에는 더 이상 공부할게 없었다.

이렇게까지 했는데 내가 못 풀면 남들도 못 푸는 문제다 라는 생각이 들 정도로 대비되어있었다.

다행히 큰 이변 없이 각종 면접과 시험에서 좋은 결과를 냈고 토익 편입으로 갈수 있는 모든 학교에 합격하였다.

그중 IT 분야 강자인 경북대학교로 진학하게 되었다.

앞으로는 ?

Java로 코딩테스트를 학습하면서 객체지향언어에 익숙해질것이다.

동시에 Spring을 깊이있게 학습해 대기업 백엔드 직군에 적합한 인재가 되어보려고 한다.

이 과정에서 바이브 코딩이나 openclaw 등을 활용하며 나의 깊은 지식과 AI의 생산성을 융합시켜 각종 대회에도 진출할 생각이다.

무엇보다도 동아리나 대외활동에 적극 참여하며 같은 분야에 속한 열정적인 학우들과 함께 성장하고싶다.

코딩테스트 문제를 풀때 디버거를 잘 몰라서 printf와 같은 출력문을 반복문 사이사이에 넣어서 풀곤 했었다.

하지만 UNIX를 배우면서 Make Utility와 GCC 컴파일러에 대해 배우면서 GDB에 대해 배울 수 있었다.

이를 배우면서 흥미를 느껴 이에 대해 기록하고 앞으론 IDE에서도 디버거를 활용하려고한다.

디버거란 ?

printf를 코드 곳곳에 삽입하여 변수 값을 확인하는 방식은 간단하지만, 재귀와 같은 알고리즘이 쓰이면서 점점 복잡해지는 프로그램에서는 한계에 부딪힌다.

코드는 지저분해지고, 버그를 잡은 뒤에는 모든 printf를 다시 지워야 하는 번거로움도 존재한다.

GDB(GNU Debugger)는 리눅스(유닉스) 환경에서 이런 원시적인 방법을 대체하는 강력한 디버깅 도구이다.

프로그램을 특정 지점에서 멈추게 하고, 변수 값을 실시간으로 들여다보며, 코드를 한 줄씩 실행하는 등 프로그램의 내부를 정밀하게 분석할 수 있게 해준다.

디버깅 정보 포함하여 컴파일하기

GDB가 소스 코드의 내용을 제대로 인식하고 분석하려면, 컴파일할 때 디버깅 정보를 포함시켜야 한다. GCC 컴파일러에서 -g 옵션을 사용하면 된다.

# -g 옵션을 추가하여 컴파일한다.
gcc -g -o factorial factorial.c

-g 옵션 없이 컴파일된 실행 파일은 GDB로 분석할 수는 있지만, 소스 코드의 몇 번째 줄인지 추적하거나 변수명을 확인하는 등의 핵심 기능을 제대로 사용할 수 없다.

GDB를 사용하려면 -g 옵션을 꼭 사용해야한다.

버그가 있는 팩토리얼 프로그램

아래는 5의 팩토리얼(!5)을 계산하는 코드이지만 버그를 포함하고 있다.

5!는 120이어야 하지만, 이 프로그램은 잘못된 결과를 출력한다.

#include <stdio.h>

// n! (n 팩토리얼)을 계산하는 함수
int calculate_factorial(int n) {
    int result = 1;

    // 버그: i <= n 이 되어야 하지만 i < n 으로 되어있다.
    for (int i = 1; i < n; i++) {
        result = result * i;
    }
    return result;
}

int main(void) {
    int number = 5;
    int result = 0;

    result = calculate_factorial(number);

    printf("%d의 팩토리얼 결과: %d\n", number, result);

    return 0;
}

이 코드를 -g 옵션으로 컴파일하고 실행하면 5의 팩토리얼 결과: 24라는 오답이 나온다.

단계별 디버깅 과정

1) GDB 시작 터미널에 gdb 명령어와 함께 분석할 실행 파일명을 입력한다.

gdb ./factorial

GDB가 시작되면 (gdb) 프롬프트가 나타나며 명령어 입력을 기다린다.

2) 브레이크포인트(Breakpoint) 설정 브레이크포인트는 프로그램 실행 중 의도적으로 멈추고 싶은 지점을 설정하는 것이다.

가장 먼저 main 함수가 시작되는 지점에 설정해보자.

(gdb) break main
Breakpoint 1 at 0x1169: file factorial.c, line 15.

break [함수명] 또는 b [줄 번호] 형식으로 설정할 수 있다.

3) 프로그램 실행 run (축약형 r) 명령어로 프로그램을 실행한다.

프로그램은 실행되다가 이전에 설정한 브레이크포인트(main 함수)를 만나면 즉시 멈춘다.

(gdb) run
Starting program: /path/to/factorial

Breakpoint 1, main () at factorial.c:15
15        int number = 5;

이제 프로그램은 15번째 줄이 실행되기 직전에 멈춰있다.

4) 코드 한 줄씩 실행 : next next (축약형 n) 명령어는 현재 줄을 실행하고 바로 다음 줄에서 멈춘다.

main 함수의 코드를 한 줄씩 따라가 보겠다.

(gdb) next
16        int result = 0;
(gdb) next
18        result = calculate_factorial(number);

5) 변수 값 확인 : print print (축약형 p) 명령어는 현재 시점의 변수 값을 보여준다.

(gdb) print number
$1 = 5
(gdb) print result
$2 = 0

number 변수에는 5가, result 변수에는 0이 올바르게 들어가 있음을 확인했다.

6) 함수 내부로 들어가기: step 다음 실행할 18번 라인은 calculate_factorial 함수 호출이다.

이 함수의 내부 동작을 보고 싶다면 next 대신 step (축약형 s)을 사용한다.

step은 함수 호출을 만나면 그 함수 내부로 진입한다.

(gdb) step
calculate_factorial (n=5) at factorial.c:5
5        int result = 1;

calculate_factorial 함수 내부로 들어왔고, 파라미터 n에 5가 잘 전달된 것을 볼 수 있다.

7) 버그 추적 이제 for문 안에서 변수들이 어떻게 변하는지 next와 print로 추적해보자.

(gdb) next
8        for (int i = 1; i < n; i++) {
(gdb) next
9            result = result * i;
(gdb) print i
$3 = 1
(gdb) print result
$4 = 1
````next`를 반복하며 `i`와 `result`의 변화를 계속 관찰한다.

```gdb
# ... next를 계속 입력 ...

(gdb) next
9            result = result * i;
(gdb) p i
$7 = 4
(gdb) p result
$8 = 6
(gdb) next
8        for (int i = 1; i < n; i++) {
(gdb) p result
$9 = 24
(gdb) next
11        return result;

i가 4일 때 result는 6 * 4 = 24가 되었다.

그리고 i가 5가 되자 i < n (즉, 5 < 5) 조건이 거짓이 되어 루프를 빠져나왔다.

여기서 팩토리얼은 5까지 곱해야 하는데, i가 4일 때까지만 곱하고 루프가 종료되었음을 확인할 수 있다.

for문의 조건이 i < n이 아니라 i <= n이 되어야 한다.

8) 디버깅 종료 원인을 찾았으니 디버깅을 종료한다. quit (축약형 q) 명령어를 입력한다.

(gdb) quit
A debugging session is active.

    Inferior 1 [process 12345] will be killed.

Quit anyway? (y or n) y

GDB 핵심 명령어 정리

Windows의 Visual Studio 같은 통합 개발 환경(IDE)은 매우 편리하지만, 많은 개발 환경, 특히 서버는 그래픽 인터페이스(GUI)가 없는 터미널 기반의 리눅스로 운영된다.

따라서 터미널 환경에서 코드를 작성하고 컴파일하는 능력은 개발자의 기본 소양이다.

이번에 강의에서 UNIX를 다루게 되면서 처음엔 복사 붙여넣기도 제대로 못하고 Vim 모드에서 벗어나기도 힘들었다.

이처럼 윈도우에 익숙해진 나에게 어려운 점이 많아서 오래 기억하고 두고두고 볼 수 있도록 글을 써보려고한다.

Vim(vi) 편집기 사용법

Vim은 키보드만으로 모든 작업을 수행하는 터미널 기반의 강력한 텍스트 편집기이다.

최초의 유닉스용 화면 편집기이고 모든 유닉스/리눅스 시스템이 기본적으로 갖추고 있다.

Vim의 가장 큰 특징은 '모드(Mode)' 라는 개념이 있다는 것이다.

Vim의 3가지 모드

Vim을 효과적으로 사용하려면 아래 3가지 모드를 이해해야 한다.

1. 명령 모드 (Normal Mode) Vim을 실행했을 때의 기본 상태이다. 키를 입력하면 텍스트가 써지는 것이 아니라, 커서 이동, 내용 복사/붙여넣기, 삭제 등의 명령이 실행된다.

2. 입력 모드 (Insert Mode) 실제로 텍스트를 입력하고 코드를 작성할 수 있는 모드이다. 명령 모드에서 i, a, o 등의 키를 눌러 진입할 수 있다. 이 모드에서 나가려면 ESC 키를 누르면 된다.

3. 마지막 행 모드 (Command-Line Mode) 명령 모드에서 :(콜론) 키를 눌러 진입한다. 화면 맨 아래 줄에 명령어를 입력하여 파일 저장, 종료, 검색 등 강력한 기능을 수행한다.

Vim으로 hello.c 파일 작성하기

1) Vim 실행 및 파일 생성 vim혹은 vi 명령어 뒤에 생성할 파일명을 입력한다. 파일이 존재하면 열리고, 없으면 새로 생성된다.

vi hello.c

실행하면 비어있는 화면이 나타나며, 현재는 명령 모드 상태이다.

2) 입력 모드로 전환 코드를 작성하기 위해 키보드에서 i 키를 누른다. 화면 하단에 -- 끼워넣기 -- 혹은 -- INSERT -- 라는 문구가 나타나면 입력 모드로 전환된 것이다.

3) 코드 작성 이제 자유롭게 C 코드를 작성할 수 있다.

#include <stdio.h>

int main(void)
{
    printf("Hello, World!! \n");
    return 0;
}

4) 저장 및 종료 코드 작성을 마쳤다면, 파일을 저장하고 Vim을 종료해야 한다.

1. ESC 키를 눌러 명령 모드로 돌아간다. (-- INSERT -- 문구가 사라진다.)

2. :(콜론)을 입력하여 마지막 행 모드로 전환한다.

3. 원하는 명령어를 입력하고 Enter를 누른다.

   :w : (Write) 현재 파일을 저장한다. :q : (Quit) Vim을 종료한다. (저장되지 않은 변경 사항이 있으면 오류가 발생한다.) :wq : 파일을 저장하고 종료한다. (가장 일반적으로 사용) :q! : 변경 사항을 저장하지 않고 강제로 종료한다.

이제 터미널에 ls 명령어를 입력하면 hello.c 파일이 생성된 것을 확인할 수 있다.

GCC 컴파일러 사용법

GCC(GNU Compiler Collection)는 C, C++, Objective-C 등 다양한 언어를 컴파일할 수 있는 컴파일러 모음이며, 리눅스 환경의 표준 C 컴파일러이다. 컴파일이란 우리가 작성한 C언어 소스 코드(.c 파일)를 컴퓨터가 이해하고 실행할 수 있는 기계어 파일(실행 파일)로 변환하는 과정을 말한다.

GCC로 hello.c 컴파일 및 실행하기

1) 기본 컴파일 gcc 명령어 뒤에 컴파일할 소스 파일명을 입력한다.

gcc hello.c

컴파일 과정에서 오류가 없다면 아무런 메시지 없이 명령어 입력이 끝난다. ls 명령어로 확인해 보면 a.out이라는 파일이 새로 생성된 것을 볼 수 있다. 이 a.out이 바로 실행 파일이다.

2) 프로그램 실행 리눅스 터미널에서 현재 디렉터리에 있는 실행 파일을 실행하려면 파일명 앞에 ./를 붙여야 한다.

./a.out

실행 결과:

Hello, World!

3) 원하는 이름으로 실행 파일 생성 (-o 옵션) a.out이라는 기본 이름 대신 원하는 이름으로 실행 파일을 만들고 싶을 때는 -o (output) 옵션을 사용한다.

#사용법: gcc -o [생성할 실행 파일명] [소스 파일명]
gcc -o hello hello.c

ls 명령어로 확인하면 a.out 대신 hello라는 이름의 실행 파일이 생성된 것을 볼 수 있다. 실행 방법은 동일하다.

./hello```
**실행 결과:**

Hello, World!

Vim 모드별 핵심 명령어 정리

교수님께서도 처음에는 익숙하지 않을 수 있다고 적어놓고 쓰다보면 외워진다고 하셨다.

근데 평소엔 다른 IDE에서 개발하는 나에게는 실습때마다 도저히 안외워져서 정리해보겠다.

Vim을 처음 사용할 때 다른 것은 잊어버리더라도 아래 4가지만 기억하면 기본적인 문서 작성이 가능하다.

hello.c 컴파일에서 사용한 필수 명령어

명령 모드 (Normal Mode) 명령어

Vim의 기본 모드로, 키보드 입력이 명령으로 인식된다. ESC 키를 누르면 언제나 명령 모드로 돌아온다.

커서 이동

편집 (수정 및 삭제)

복사 & 붙여넣기 (Yank & Put)

실행 취소 및 반복

입력 모드 (Insert Mode) 진입 및 탈출 명령어

마지막 행 모드 (Command-Line Mode) 명령어

명령 모드에서 :(콜론)을 입력하여 진입한다. 화면 하단에 명령어를 입력하여 파일 제어, 검색, 설정 변경 등을 수행한다.

파일 제어

검색 및 치환

에디터 설정

한번에 다 외울수는 없겠지만 실습때나 Vi 편집기를 사용할때 켜놓고 최대한 기능을 많이 써보며 IDE를 쓸때만큼 편리하게 쓸 수 있도록 여러 명령어들에 익숙해져야겠다.

사용할줄 아는 수준에서 더 나아가 여러 명령어들이 익숙해져 나중에는 VIM 모드가 더 편할 정도의 수준이 되어서 마우스 없이 나의 생각을 그 즉시 키보드로 빠르게 칠 수 있는 수준의 개발자가 되고싶다.

전공 공부를 병행하면서 꾸준히 코딩테스트 문제를 풀다보니 목표 중 하나였던 백준 골드를 달성하게 되었다.

실버를 달성까지 며칠밖에 안 걸렸어서 골드도 금방 달성할 수 있을 줄 알았지만 그건 내 기본기가 있기 때문이었다.

실버 문제부터는 스택, 큐, 트리, 그래프와 같은 자료구조나 BFS, DFS, DP와 같은 고급 알고리즘이 조금씩 사용되어 한 문제 한 문제 성장하면서 풀어야했기에 시간이 훨씬 오래 걸렸다.

티어를 올리기에 집중하기보단 C언어를 통해 문제에 필요한 자료구조들을 직접 구현해보면서 삽질도 해보고 시간을 많이 썼던 것 같다.

또한 문제를 풀때마다 GitHub에 코드들을 커밋했다.

시간이 너무 오래 걸리기도하고 풀이법이 잘 떠오르지도 않아 초반에는 내가 너무 못하는건 아닌가 걱정도 되었다.

하지만 무작위의 실버 수준의 문제들을 풀어낼 수준이 된다면 웬만한 기업의 코딩테스트는 뚫을 수 있다고 해서 걱정이 좀 줄어들었다.

이 정도면 C를 통한 삽질은 충분히 해봤다고 생각한다.

앞으로는 C++의 구현된 자료구조도 활용해보고 Java를 깊게파며 Spring 프레임워크를 활용한 백엔드 공부도 병행하면서 자료구조나 알고리즘의 구현보다는 활용하는 방법을 위주로 코딩테스트를 준비할 것이다.

이 템포라면 졸업할때쯤엔 플레티넘도 달성하고 부트캠프나 각종 기업의 코딩테스트는 가뿐히 넘을 수 있을 수준이 될 것이라고 생각한다.

TOEIC 925점 달성

RC가 문제라고 생각하고 RC를 보완하고자 ETS 기출문제 3권을 풀어보며 ETS만의 오답을 거르고 정답을 고르는 논리를 이해하고자 노력했다.

또한 어휘와 문법이 부족하다고 생각해 어휘와 문법을 깊게 학습했다.

예를들면 due라는 단어는 to와 함께 ~로인한 이라는 뜻으로 알고있었는데 비즈니스 영어인 토익에서는 membership due = 회비 처럼 생각지도 못한 뜻으로 쓰이는 어휘들의 여러 쓰임들과 여러 뜻을 학습하려고 노력했다.

이뿐만아니라 PART 5, 6 위주로 문법을 처음부터 정리하고 엄청 많은 문제를 풀어보았다.

하지만 100문제 타임어택 독해 시험인 토익의 특성상 RC 성적이 그렇게 드라마틱하게 오르진 않았다.

RC 성적을 400점대에서 안정적인 430-440점대를 만드는데는 성공했지만 더 올리기는 어려웠다.

그래서 LC에 집중하여 LC 만점을 받기위해 노력했고 그 결과 목표와 가까운 925점에 달성하는데에 성공했다.

경영학과 컴퓨터공학을 복수전공하며 공부하다보면 영문 원서로 수업하기도하고, 개인 프로젝트를 하다 생기는 오류나 궁금한점들을 찾아보다보면 양질의 자료들이 영어로 되어있는 경우가 많다.

이뿐만 아니라 요즘 미국주식에도 관심이 많은데 어닝콜을 보더라도 영어는 필수적이다.

LLM이나 파파고로 동시 번역도 가능한 요즘 시대에 영어 실력이 개발자가 되는데에 필수적인건 아니지만 영어를 잘하는 개발자가 여러 측면에서 유리하고 개발 분야뿐 아니라 앞으로 살아가면서도 더 빠르게 성장하는데에 꼭 필요한 능력이라고 생각한다.

졸업을 앞두고 오픽을 준비해서 가장 높은 성적인 AL도 받아보고싶다.

2학기 목표

• 오래 기억하고 싶은 내용 VELOG 꾸준히 작성

• 인스타 키워서 양질의 의류 더 협찬 받기

• 데이터 관리 강의 활용 - SQLD 취득하기

• 시흥시 지역문제 경진대회 수상해서 해외연수 경험해보기

• 제주시 데이터 활용 공모전 참가해보기

• 독서 및 투자 공부

• 운동 및 절주

• 자료구조 알고리즘 보완 -> PCCP 취득 및 교내 SW 경진대회 수상

• 웹프로젝트응용 수업 활용 - 운영중인 웹사이트 보완 및 유지보수

분할 정복 알고리즘(Divide and conquer algorithm)은 그대로 해결할 수 없는 문제를 작은 문제로 분할하여 문제를 해결하는 방법이다.

대표적인 예로는 퀵 정렬이나 합병 정렬과 이진 탐색 등이 있다.

분할 정복 설계

1) Divide

원래 문제가 분할하여 비슷한 유형의 더 작은 하위 문제로 분할이 가능할 때 까지 나눈다.

2) Conquer

각 하위 문제를 재귀적으로 해결한다. 하위 문제의 규모가 나눌 수 없는 단위가 되면 탈출 조건을 설정하고 해결한다.

3) Combine

Conquer한 문제들을 통합하여 원래 문제의 답을 얻어 해결한다.

2630 - 색종이 만들기

백준 - 2630 : 색종이 만들기

문제

코드

#include <stdio.h>

int paper[128][128], zero, one;

int search(int x, int y, int n){
    int count = 0;
    for(int i=x; i<x+n; i++){
        for(int j=y; j<y+n; j++){
            if(paper[i][j]==1) count++; 
        }
    }
    if(count == n * n) one++;
    else if(count == 0) zero++;
    else{
        search(x, y, n/2);
        search(x, y+n/2, n/2);
        search(x+n/2, y, n/2);
        search(x+n/2, y+n/2, n/2);
    }
}

int main(void){
    int n;
    scanf("%d", &n);
    for(int i=0; i<n; i++){
        for(int j=0; j<n; j++){
            scanf("%d", &paper[i][j]);
        }
    }
    search(0, 0, n);
    printf("%d\n%d", zero, one);
}

2차원 배열을 활용했고, 1개의 정사각형을 1, 2, 3, 4사분면으로 나누어 조건이 만족될때마다 count를 높여가며 재귀적으로 문제를 풀었다.

이때 count와 n을 비교한 값을 종료 조건으로 설정하고 n/2으로 절반씩 줄여나가는 방법을 사용했다.

같은 원리로 Z라는 문제를 접근했는데 시간 초과 문제가 생겼다.

1074 - Z

백준 - 1074 : Z

문제

코드

#include <stdio.h>

int count = 0; // 전역변수 초기화
int r, c;

int search(int x, int y, int n) { 
    if (n == 1) {
        if (x == r && y == c) {
            return 1; // 찾았을 때 1 반환
        }
    } else {
        int half = n / 2;

        // 1사분면
        if (r < x + half && c < y + half) {
            return search(x, y, half);
        } else {
            count += half * half;
        }

        // 2사분면
        if (r < x + half && c >= y + half) {
            return search(x, y + half, half);
        } else {
            count += half * half;
        }

        // 3사분면
        if (r >= x + half && c < y + half) {
            return search(x + half, y, half);
        } else {
            count += half * half;
        }

        // 4사분면
        if (r >= x + half && c >= y + half) {
            return search(x + half, y + half, half);
        } else {
            count += half * half;
        }
        return 0;
    }
}

int main() {
    int n;
    scanf("%d %d %d", &n, &r, &c);

    int size = 1 << n; // 2^n 계산하기 위한 비트연산

    search(0, 0, size); // 좌표 0, 0 부터 탐색

    printf("%d\n", count);
    return 0;
}

처음엔 색종이 만들기 문제와 같이 모든 사분면을 조사해보며 함수가 호출 될때마다 count를 증가시키는 방식을 사용했다.

예제까지는 잘 실행됐지만 2의 지수꼴로 조사해야하는 범위가 늘어날수록 시간이 기하 급수적으로 늘어나다보니 시간 초과 문제가 생겼다.

그래서 이를 해결하고자 각 사분면을 하나하나 조사하는게 아닌 count+=n*n을 통해 시간을 엄청나게 줄일 수 있었다.

이렇게 분할 정복에다가 조사하지 않아도 되는 부분을 n*n과 같은 방법으로 넘기는 방법까지 더해지니 2의 지수꼴과 같이 규모가 커짐에 따라 얼마나 크게 실행 속도의 차이를 만들어 내는지 느낄 수 있었다.

이런 알고리즘과 자료구조를 기반으로 효율적으로 구현한 코드 하나하나가 적은 비용으로 효과적으로 운영할 수 있는 서비스의 기반이 되는 것이다.

시프트 연산자(<< / >>)를 활용한 지수 계산

시프트 연산은 좌항에 있는 피연산자를 우항에 있는 수만큼 비트 자리 이동하는 연산을 수행한다.

<< 는 왼쪽 쉬프트 연산자이고 >> 는 오른쪽 쉬프트 연산자이다.

왼쪽 쉬프트 연산을 하면 좌항에 있는 피연산자의 값이 우항에 있는 수만큼 왼쪽으로 자리 이동하고 빈 자리는 0으로 채우게 된다.

이 특성을 이용한다면 2의 거듭제곱을 Z 문제의 코드처럼 쉽게 구할 수 있다.

    printf("%u\n", num1 << 1);    //   2: 0000 0010: 2
    printf("%u\n", num1 << 2);    //   4: 0000 0100: 2^2
    printf("%u\n", num1 << 3);    //   8: 0000 1000: 2^3
    printf("%u\n", num1 << 4);    //  16: 0001 0000: 2^4
    printf("%u\n", num1 << 5);    //  32: 0010 0000: 2^5
    printf("%u\n", num1 << 6);    //  64: 0100 0000: 2^6
    printf("%u\n", num1 << 7);    // 128: 1000 0000: 2^7

재귀 알고리즘 문제를 풀다가 답안을 제출했는데 자꾸 오답처리가 되었다.

알고리즘에도 문제가 없고 내 컴파일러에서는 실행결과에도 아무런 문제가 없었다.

그래서 다른 사람들의 코드와 비교하다가 이유를 찾았다.

오답 코드

#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>
#include <string.h>

int recursion(const char *s, int l, int r, int *count) {
  (*count)++;
  if (l >= r)
    return 1;
  else if (s[l] != s[r])
    return 0;
  else
    return recursion(s, l + 1, r - 1, count);
}

int isPalindrome(const char *s, int *count) {
  return recursion(s, 0, strlen(s) - 1, count);
}

int main() {
  int num, count, temp;
  char s[1002];
  scanf("%d", &num);
  while (num--) {
    count = 0;
    scanf("%s", s);
    printf("%d %d\n", isPalindrome(s, &count), count);
  }
  return 0;
}

정답 코드
#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>
#include <string.h>

int recursion(const char *s, int l, int r, int *count) {
  (*count)++;
  if (l >= r)
    return 1;
  else if (s[l] != s[r])
    return 0;
  else
    return recursion(s, l + 1, r - 1, count);
}

int isPalindrome(const char *s, int *count) {
  return recursion(s, 0, strlen(s) - 1, count);
}

int main() {
  int num, count, temp;
  char s[1002];
  scanf("%d", &num);
  while (num--) {
    count = 0;
    scanf("%s", s);
    temp = isPalindrome(s, &count);
    printf("%d %d\n", temp, count);
  }
  return 0;
}

오류 부분
    printf("%d %d\n", isPalindrome(s, &count), count);


수정 후    
    temp = isPalindrome(s, &count);
    printf("%d %d\n", temp, count);

결론부터 말하자면, 채점 서버의 컴파일러가 함수 인자를 처리하는 순서가 사용자의 로컬 환경과 달랐기 때문에 발생한 오류였다.

함수의 인자 평가 순서

C 언어 표준에서는 함수에 여러 개의 인자(argument)를 전달할 때, 컴파일러가 그 인자들의 값을 어떤 순서로 계산(평가)할지에 대해 정해두지 않았다.

즉, 아래와 같은 코드가 있을 때, *printf("%d %d\n", isPalindrome(s, &count), count); * 컴파일러는 두 가지 방식 중 아무거나 선택할 수 있다.

1. 인자를 오른쪽에서 왼쪽으로 평가 (많은 C 컴파일러의 일반적인 방식)

1. printf의 두 번째 인자인 count를 먼저 평가한다.
2. 그 다음, 첫 번째 인자인 isPalindrome(s, &count)를 평가한다.
3. isPalindrome 함수가 실행되면서 내부의 recursion이 호출되고, count의 값이 (예를 들어) 3으로 변경된다. 함수는 팰린드롬 여부에 따라 1 또는 0을 반환한다.
4. printf 함수는 최종적으로 (2)번 단계에서 반환된 값과 (1)번 단계에서 미리 계산해 둔 count의 값(0)을 가지고 출력한다.
5. 결과: 1 0 (오답)

2. 인자를 왼쪽에서 오른쪽으로 평가

1. printf의 첫 번째 인자인 isPalindrome(s, &count)를 먼저 평가한다.
2. 함수가 실행되면서 count의 값이 3으로 변경되고, 함수는 1 또는 0을 반환한다.
3. 그 다음, 두 번째 인자인 count를 평가한다. 이 시점에서 count의 값은 (2)번 단계에서 변경된 3이다다.
4. printf 함수는 (1)번 단계의 반환값과 (3)번 단계에서 계산된 count의 값(3)을 가지고 출력한다.
5. 결과: 1 3 (정답)

백준의 채점 서버의 컴파일러는 방식 1처럼 동작했고, 나의 컴파일러는 방식 2처럼 동작해서 생긴 오류였다.

이처럼 컴파일러나 환경에 따라 결과가 달라질 수 있는 코드는 정의되지 않은 동작(Undefined Behavior)에 의존하는 코드라고 부르며, 프로그래밍 시 반드시 피해야 한다.

temp 변수를 사용한 순서 보장

temp 변수를 사용한 코드는 왜 항상 올바르게 동작할까 ?

temp = isPalindrome(s, &count);       // 1번 라인
printf("%d %d\n", temp, count);      // 2번 라인

C 언어에서 세미콜론(;)은 "시퀀스 포인트(Sequence Point)" 역할을 한다.

시퀀스 포인트는 이전 라인에서 발생한 모든 계산과 부수 효과(side effect)가 다음 라인으로 넘어가기 전에 반드시 완료됨을 보장한다.

1. 1번 라인 실행: isPalindrome(s, &count)가 호출됩니다. 이 함수의 실행이 완전히 끝날 때까지 프로그램은 다음으로 넘어가지 않는다.
   • 이 과정에서 count의 값은 최종값(예: 3)으로 업데이트된다.
   • isPalindrome의 반환값은 temp 변수에 저장된다.
2. 시퀀스 포인트(;): 1번 라인의 모든 동작(count 값 변경 포함)이 완료되었음을 보장한다.
3. 2번 라인 실행: printf가 호출된다.
   • 이 시점에는 temp와 count의 값이 이미 모두 확정된 상태이다.
   • printf의 인자 평가 순서가 어떻게 되든 상관없이, 이미 계산이 끝난 temp의 값과 count의 최종값을 가져와 출력하므로 항상 올바른 결과가 나온다.

앞으론 세미콜론(시퀀스 포인트)을 통해 연산의 순서를 명확하게 강제하는 등 C의 동작과정을 더 이해하고 어떤 컴파일러 환경에서도 동일한 결과를 보장하는 코드를 작성해야겠다.

백준 - 후위 표기식

문제 내용

C에는 스택 라이브러리가 없기 때문에 구현하여 사용해야한다.

그래서 스택을 구현한 김에 더 깊게 이해하고자 스택 문제를 여러 개 풀고 있다.

후위 표기식(Postfix Notation)이란?

우리는 1+2+3 처럼 숫자(피연산자)와 숫자 사이에 연산자(+)를 넣어서 식을 표현하는데

이를 중위 표기식(Infix Notation)이라고 한다.

후위 표기식(Postfix Notation)은 연산자가 피연산자의 뒤에 온다.

1 + 2 + 3 (Infix)

1 2 + 3 + (Postfix)

컴퓨터가 후위 표기식을 사용하는 이유

후위 표기식은 앞에서부터 뒤로 가면서 연산자가 보이면 앞의 두 숫자를 피연산자로 계산하면 된다.

중위 표기식 1+2×3의 경우 후위 표기식으론 123×+이다.

앞에서부터 차례로 읽다가 연산자인 ×가 발견되었을 때 앞에 있는 2개의 피연산자 2 3를 대상으로 2×3=6을 실행한다.

그 뒤의 연산자인 +가 발견되었을 때 앞에 있는 2개의 피연산자 1 6을 대상으로 1+6=7을 실행한다.

컴퓨터는 후위 표기식을 사용하는데, 이런 후위 표기식을 컴퓨터가 사용하는 근본적인 이유는

괄호도 필요없고 연산자 우선 순위를 고려할 필요도 없기 때문이다.

후위 표기식과 스택

이러한 방식의 후위 표기식을 만들거나 후위 표기식을 중위 표기식으로 만들때 스택(Stack) 구조가 사용된다.

간단한 예를 들면 아까처럼 123x+을 중위 표기식으로 사용할때 1/2/3을 스택에 담고 x를 만나면

pop() x pop() 후 연산한 값을 push()한다면 스택에는 1/6이 들어가 있을 것이다.

이 예시는 후위 표기식을 중위 표기식으로 만드는 과정이었고, 이 문제는 반대로 중위 표기식을 후위 표기식으로 만드는 문제이다.

중위 표기식 -> 후위 표기식

먼저 코드를 작성하기 전 4가지 규칙을 찾았다.

1. 피연산자는 출력한다.

2. '('를 만난다면 push한다.

3. ')'를 만난다면 '('가 나올때까지 pop을 진행하고 그 사이의 연산자들을 출력한다.

4. 연산자를 만난다면 push하지만 이때 peek의 우선순위가 연산자의 우선순위보다 크거나 같다면 우선순위가 더 작아질때까지 pop 후 출력하고 연산자를 push한다.

이 조건을 잘 신경쓴다면 문제없이 코드를 구현할 수 있다.

코드

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_STACK_SIZE 100

typedef char element;

typedef struct{
  element data[MAX_STACK_SIZE];
  int top; 
}StackType;

void init_stack(StackType *s){
  s->top = -1;
}

int is_empty(StackType *s){
  return(s->top == -1);
}

int is_full(StackType *s){
  return(s->top == MAX_STACK_SIZE-1);
}

void push(StackType *s, element item){
  if(is_full(s)){
    return;
  }
  s->data[++(s->top)] = item;
}

element pop(StackType *s){
  if(is_empty(s)){
    return 0;
  }
  return s->data[(s->top)--];
}

int priority(char c){
  if(c == '(' || c==')')
    return 0; //'()'은 연산에 참가 안하고 따로 처리하므로 후순위로 둠
  else if(c == '+' || c == '-') 
    return 1;
  else if(c == '*' || c == '/')
    return 2;
}

int main(void){
  char input[100] = {0,};
  scanf("%s", input);
  StackType s;
  char temp;
  init_stack(&s);
  for(int i=0; i<strlen(input); i++){
    int ch = input[i];
    switch(ch){
      case '+': case '-' : case '*' : case '/':
        while(!is_empty(&s) && priority(s.data[s.top])>=priority(ch)){ 
        //스택에 있는 연산자의 우선순위가 더 크거나 같으면 출력
          printf("%c", pop(&s));
        }
        push(&s, ch);
        break;

      case '(': 
        push(&s, ch);
        break;

      case ')':
        temp = pop(&s);
        while(temp !='('){
          printf("%c", temp);
          temp = pop(&s);
        }
        break;

      default : //피연산자인 경우
        printf("%c", ch);
        break;
    }
  }
  while(!is_empty(&s)){ //남은 연산자 출력
    printf("%c", pop(&s));
  }
}

백준 - 스택 수열

문제 내용

C에는 스택 라이브러리가 없기 때문에 구현하여 사용해야한다.

그래서 이왕 스택을 구현한 김에 더 깊게 이해하고자 스택 문제를 여러개 풀고 있다.

아마 예시 입출력이 없었다면 아직도 문제를 이해하지 못했을 것이다.

쉽게 설명하자면 1부터 오름차순으로 스택에 push 할 수 있고 pop을 통해 입력된 수열을 만들 수 있는지 체크하고 만들 수 있다면 push와 pop의 과정들을 출력하는 문제이다.

세가지 조건을 나누어서 해결했다.

우선 peek라고도 불리는 stack[top] 값과 temp(입력값)을 비교했다.

1. stack[top]값이 더 큰 경우 "NO" 출력 후 프로그램 종료

2. temp값이 더 큰 경우 stack[top]과 temp가 같아질때까지 push 후 같아지면 pop 진행

3. 두 값이 같은 경우 pop 진행

이 세 가지 경우로 나누어 코드를 짰다.

코드

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_STACK_SIZE 100

typedef char element;

typedef struct{
  element data[MAX_STACK_SIZE];
  int top; 
}StackType;

void init_stack(StackType *s){
  s->top = -1;
}

int is_empty(StackType *s){
  return(s->top == -1);
}

int is_full(StackType *s){
  return(s->top == MAX_STACK_SIZE-1);
}

void push(StackType *s, element item){
  if(is_full(s)){
    return;
  }
  s->data[++(s->top)] = item;
}

element pop(StackType *s){
  if(is_empty(s)){
    return 0;
  }
  return s->data[(s->top)--];
}

int priority(char c){
  if(c == '(' || c==')')
    return 0; //'()'은 연산에 참가 안하고 따로 처리하므로 후순위로 둠
  else if(c == '+' || c == '-') 
    return 1;
  else if(c == '*' || c == '/')
    return 2;
}

int main(void){
  char input[100] = {0,};
  scanf("%s", input);
  StackType s;
  char temp;
  init_stack(&s);
  for(int i=0; i<strlen(input); i++){
    int ch = input[i];
    switch(ch){
      case '+': case '-' : case '*' : case '/':
        while(!is_empty(&s) && priority(s.data[s.top])>=priority(ch)){
          printf("%c", pop(&s));
        }
        push(&s, ch);
        break;

      case '(':
        push(&s, ch);
        break;

      case ')':
        temp = pop(&s);
        while(temp !='('){
          printf("%c", temp);
          temp = pop(&s);
        }
        break;

      default : //피연산자인 경우
        printf("%c", ch);
        break;
    }
  }
  while(!is_empty(&s)){
    printf("%c", pop(&s));
  }
}

비즈니스 로직을 JSP에서 분리했더라도, 데이터베이스 연결(JDBC) 코드가 서블릿이나 JSP에 직접 포함되어 있다면 심각한 문제를 야기한다.

// 서블릿이나 JSP 파일 내부 - 좋지 않은 예시
Connection conn = null;
PreparedStatement pstmt = null;
ResultSet rs = null;

try {
    // 1. 드라이버 로딩
    Class.forName("oracle.jdbc.driver.OracleDriver");
    // 2. 커넥션 생성
    conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "user", "pass");
    // 3. SQL 작성 및 실행
    String sql = "SELECT * FROM member WHERE id = ?";
    pstmt = conn.prepareStatement(sql);
    pstmt.setString(1, request.getParameter("id"));
    rs = pstmt.executeQuery();
    // 4. 결과 처리...
    // 이 모든 코드가 DB 작업이 필요한 모든 파일에 중복되어 삽입된다.
} catch(Exception e) {
    // 예외 처리
} finally {
    // 5. 자원 해제 (매번 반복)
    if(rs != null) rs.close();
    if(pstmt != null) pstmt.close();
    if(conn != null) conn.close();
}

이러한 구조는 코드의 중복이 극심하고, DB 정보(URL, ID, PW)가 변경되면 관련된 모든 파일을 수정해야 하는 유지보수 재앙을 초래한다.

또한, 매 요청마다 DB 커넥션을 생성하고 해제하는 과정은 시스템에 엄청난 부하를 주어 성능 저하의 주범이 된다.

해결책으로 DAO(Data Access Object) 패턴을 도입하여 데이터 로직을 분리하고, 커넥션 풀(Connection Pool)을 함께 사용하여 시스템의 효율을 극대화해야 한다.

DAO 패턴

DAO는 데이터베이스에 접근하고 처리하는 로직(CRUD: Create, Read, Update, Delete)을 별도의 클래스로 완전히 분리하여 캡슐화하는 디자인 패턴이다.

이는 '관심사의 분리(Separation of Concerns)' 원칙을 충실히 따르는 방법이다.

서블릿이나 다른 서비스 클래스들은 복잡한 JDBC 코드나 SQL 문을 전혀 알 필요가 없다.

그저 DAO 객체에게 "회원 정보 저장", "ID가 'user1'인 회원 정보 조회" 와 같이 의미 있는 기능 단위로 요청만 하면 된다.

DTO, VO 그리고 자바빈(JavaBean)

DTO (Data Transfer Object) / VO (Value Object) 계층 간(Controller-Service-DAO) 데이터를 전달하기 위한 목적으로 만들어진 객체이다. 예를 들면 MemberDTO는 회원 한 명의 정보를 온전히 담아 운반하는 '데이터 상자' 역할을 한다.

자바빈 (JavaBean) 앞서 다뤘던 자바빈은 특정 규칙을 따르는 자바 클래스를 지칭하는 기술 규약이다. 1. private 접근 제한자로 필드를 선언한다. 2. public 접근자로 getter/setter 메서드를 가진다. 3. 인자 없는 기본 생성자(default constructor)를 가진다.

하지만 여기서 DTO는 자바빈 규약에 따라 만드는 것이 일반적이다.

즉, MemberDTO는 '데이터 전달'이라는 역할(패턴)을 수행하며, 그 구현은 자바빈(기술 규약)을 따른다.

따라서 "DTO는 자바빈이다"라고 말할 수 있다.

JSP에서 <jsp:useBean> 액션 태그가 DTO 객체를 쉽게 다룰 수 있는 것도 DTO가 자바빈 규약을 따르기 때문이다.

DAO (Data Access Object)

실제 DB 작업을 수행하는 객체이다.

모든 JDBC 코드는 DAO 클래스 내부에만 존재한다.

// MemberDAO.java 의 예시
public class MemberDAO {
    // ... Connection Pool을 통해 Connection을 얻어오는 로직 ...

    public int insertMember(MemberDTO dto) {
        Connection conn = null;
        PreparedStatement pstmt = null;
        String sql = "INSERT INTO member (id, password, name, email) VALUES (?, ?, ?, ?)";
        int result = 0;
        try {
            conn = getConnection(); // 커넥션 풀에서 하나 빌려오기
            pstmt = conn.prepareStatement(sql);
            pstmt.setString(1, dto.getId());
            pstmt.setString(2, dto.getPassword());
            pstmt.setString(3, dto.getName());
            pstmt.setString(4, dto.getEmail());
            result = pstmt.executeUpdate();
        } catch (SQLException e) {
            e.printStackTrace();
        } finally {
            close(pstmt, conn); // 자원 반납
        }
        return result;
    }
    // getMember(id), updateMember(dto), deleteMember(id) 등 다른 메서드들...
}

커넥션 풀(Connection Pool)

데이터베이스 커넥션을 맺고 끊는 작업은 네트워크 통신, 사용자 인증, 세션 설정 등이 포함된, 시스템에 상당한 부하를 주는 고비용 작업이다.

매 요청마다 이 작업을 반복하는 것은 극심한 성능 저하를 유발한다.

커넥션 풀은 이 문제를 해결하기 위해 미리 일정 개수의 DB 커넥션을 생성하여 '풀(Pool)'이라는 저장 공간에 보관해두고, 필요할 때마다 빌려 쓰고 반납하는 기법이다.

동작 원리:

1. WAS 시작 웹 애플리케이션 서버(EX:Tomcat)가 시작될 때, context.xml에 설정된 정보를 읽어 지정된 개수만큼 커넥션을 미리 생성하여 풀에 저장한다.

2. DAO의 요청 MemberDAO가 DB 작업이 필요하면, DriverManager.getConnection()을 직접 호출하는 대신, WAS가 제공하는 JNDI(Java Naming and Directory Interface) 서비스를 통해 커넥션 풀을 찾는다.

3. 대여(Borrow) JNDI를 통해 찾은 커넥션 풀(DataSource 객체)에게 dataSource.getConnection()을 호출하여 커넥션을 요청한다. 풀은 유휴 상태의 커넥션 하나를 빌려준다.

4. 작업 수행 DAO는 빌린 커넥션을 사용하여 SQL 작업을 수행한다.

5. 반납(Return) 작업이 끝나면 connection.close()를 호출한다. 커넥션 풀을 통해 얻은 커넥션은 이 때 실제로 닫히는 것이 아니라, 풀에 반납되어 '대기' 상태로 돌아간다.

6. 재사용 다른 요청이 들어오면, 풀에 대기 중인 커넥션을 다시 빌려주어 커넥션 생성 비용 없이 즉시 DB 작업을 시작할 수 있다.

Tomcat context.xml 설정 예시 META-INF/context.xml 파일에 다음과 같이 DB 정보를 설정한다.

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <Resource name="jdbc/OracleDB" auth="Container"
              type="javax.sql.DataSource"
              driverClassName="oracle.jdbc.driver.OracleDriver"
              url="jdbc:oracle:thin:@localhost:1521:XE"
              username="myuser"
              password="mypassword"
              maxTotal="20"   <!-- 최대 커넥션 개수 -->
              maxIdle="10"    <!-- 유휴 상태로 유지할 최대 커넥션 개수 -->
              maxWaitMillis="5000" /> <!-- 커넥션을 기다리는 최대 시간(ms) -->
</Context>

커넥션 풀 사용 코드 (DAO 내부)

// DAO에서 커넥션을 얻어오는 메서드
private Connection getConnection() {
    Connection conn = null;
    try {
        Context initContext = new InitialContext();
        // context.xml 에 설정한 "jdbc/OracleDB" 이름을 찾아 DataSource 객체를 얻어온다.
        DataSource ds = (DataSource) initContext.lookup("java:/comp/env/jdbc/OracleDB");
        conn = ds.getConnection(); // DataSource를 통해 풀에서 커넥션을 대여한다.
    } catch (Exception e) {
        e.printStackTrace();
    }
    return conn;
}

DAO 패턴과 커넥션 풀의 조합은 현대적인 웹 애플리케이션 구축의 표준적인 방법이다.

회원가입 및 로그인 기능 구현

JSP/Servlet 기반 MVC 패턴을 사용하여 회원가입 및 로그인 기능을 구현하는 코드이다.

DB 테이블

데이터베이스에 회원 정보를 저장할 member 테이블을 생성한다.

-- member 테이블 생성 SQL
CREATE TABLE member (
    id VARCHAR2(20) PRIMARY KEY,
    password VARCHAR2(20) NOT NULL,
    name VARCHAR2(30) NOT NULL,
    email VARCHAR2(50),
    regdate DATE DEFAULT SYSDATE
);

Model (데이터 및 로직 처리)

Member.java (DTO)

회원 정보를 담아 계층 간에 전달하는 객체. 자바빈 규약에 따라 작성한다.

// Member.java
package com.example.model;

import java.io.Serializable;
import java.sql.Date;

public class Member implements Serializable {
    private static final long serialVersionUID = 1L;

    // 필드 (DB 컬럼과 일치)
    private String id;
    private String password;
    private String name;
    private String email;
    private Date regdate;

    // 기본 생성자
    public Member() {
    }

    // Getter and Setter
    public String getId() { return id; }
    public void setId(String id) { this.id = id; }
    public String getPassword() { return password; }
    public void setPassword(String password) { this.password = password; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }
    public Date getRegdate() { return regdate; }
    public void setRegdate(Date regdate) { this.regdate = regdate; }
}

MemberDAO.java (DAO)

실제 데이터베이스에 접근하여 CRUD 작업을 수행하는 객체.

커넥션 풀을 사용한다.

// MemberDAO.java
package com.example.model;

import java.sql.*;
import javax.naming.*;
import javax.sql.*;

public class MemberDAO {

    private DataSource dataSource;

    // 생성자에서 커넥션 풀(DataSource)을 찾아 초기화
    public MemberDAO() {
        try {
            Context context = new InitialContext();
            dataSource = (DataSource) context.lookup("java:comp/env/jdbc/OracleDB");
        } catch (NamingException e) {
            e.printStackTrace();
        }
    }

    // 회원가입 (Create)
    public int join(Member member) {
        Connection conn = null;
        PreparedStatement pstmt = null;
        int result = 0;
        String sql = "INSERT INTO member (id, password, name, email) VALUES (?, ?, ?, ?)";

        try {
            conn = dataSource.getConnection();
            pstmt = conn.prepareStatement(sql);
            pstmt.setString(1, member.getId());
            pstmt.setString(2, member.getPassword());
            pstmt.setString(3, member.getName());
            pstmt.setString(4, member.getEmail());
            result = pstmt.executeUpdate(); // 성공 시 1 반환
        } catch (SQLException e) {
            e.printStackTrace();
        } finally {
            try {
                if (pstmt != null) pstmt.close();
                if (conn != null) conn.close(); // 커넥션을 풀에 반납
            } catch (SQLException e) {}
        }
        return result;
    }

    // 로그인 인증 (Read)
    public int loginCheck(String id, String password) {
        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        int result = -1; // -1: 에러, 0: 비밀번호 불일치, 1: 성공
        String sql = "SELECT password FROM member WHERE id = ?";

        try {
            conn = dataSource.getConnection();
            pstmt = conn.prepareStatement(sql);
            pstmt.setString(1, id);
            rs = pstmt.executeQuery();

            if (rs.next()) { // 아이디가 존재할 경우
                if (rs.getString("password").equals(password)) {
                    result = 1; // 로그인 성공
                } else {
                    result = 0; // 비밀번호 불일치
                }
            } else {
                result = -1; // 아이디 존재 안함
            }
        } catch (SQLException e) {
            e.printStackTrace();
        } finally {
            try {
                if (rs != null) rs.close();
                if (pstmt != null) pstmt.close();
                if (conn != null) conn.close();
            } catch (SQLException e) {}
        }
        return result;
    }
}

View (사용자 인터페이스)

join.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>회원가입</title>
</head>
<body>
    <h2>회원가입</h2>
    <form action="join.do" method="post">
        <label for="id">아이디:</label><br>
        <input type="text" id="id" name="id" required><br><br>
        <label for="password">비밀번호:</label><br>
        <input type="password" id="password" name="password" required><br><br>
        <label for="name">이름:</label><br>
        <input type="text" id="name" name="name" required><br><br>
        <label for="email">이메일:</label><br>
        <input type="email" id="email" name="email"><br><br>
        <input type="submit" value="가입하기">
    </form>
</body>
</html>

login.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>로그인</title>
</head>
<body>
    <h2>로그인</h2>
    <form action="login.do" method="post">
        <label for="id">아이디:</label><br>
        <input type="text" id="id" name="id" required><br><br>
        <label for="password">비밀번호:</label><br>
        <input type="password" id="password" name="password" required><br><br>
        <input type="submit" value="로그인">
    </form>
    <br>
    <%-- 로그인 실패 시 에러 메시지 출력 --%>
    <%
        String error = (String) request.getAttribute("error");
        if (error != null) {
    %>
        <p style="color: red;"><%= error %></p>
    <%
        }
    %>
    <a href="join.jsp">회원가입</a>
</body>
</html>

main.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%
    // 페이지 상단에서 세션 검사
    String userId = (String) session.getAttribute("userId");
    if (userId == null) { // 세션에 로그인 정보가 없으면
        response.sendRedirect("login.jsp"); // 로그인 페이지로 강제 이동
        return; // 현재 페이지의 나머지 코드 실행 중단
    }
%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>메인 페이지</title>
</head>
<body>
    <h1><%= userId %>님, 환영합니다!</h1>
    <p>성공적으로 로그인되었습니다.</p>
    <a href="logout.do">로그아웃</a>
</body>
</html>

Controller (요청 처리 및 흐름 제어)

JoinServlet.java

// JoinServlet.java
package com.example.controller;

import java.io.IOException;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;

import com.example.model.Member;
import com.example.model.MemberDAO;

@WebServlet("/join.do")
public class JoinServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 1. 파라미터 인코딩 설정
        request.setCharacterEncoding("UTF-8");

        // 2. 파라미터 추출 및 Member 객체 생성
        Member member = new Member();
        member.setId(request.getParameter("id"));
        member.setPassword(request.getParameter("password"));
        member.setName(request.getParameter("name"));
        member.setEmail(request.getParameter("email"));

        // 3. DAO를 통해 DB에 회원 정보 저장
        MemberDAO dao = new MemberDAO();
        int result = dao.join(member);

        // 4. 결과에 따른 페이지 이동
        if (result == 1) { // 회원가입 성공
            response.sendRedirect("login.jsp");
        } else { // 회원가입 실패
            // 실제로는 에러 페이지로 보내거나 알림을 띄우는 것이 좋음
            response.sendRedirect("join.jsp");
        }
    }
}

LoginServlet.java

// LoginServlet.java
package com.example.controller;

import java.io.IOException;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;

import com.example.model.MemberDAO;

@WebServlet("/login.do")
public class LoginServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 1. 파라미터 추출
        String id = request.getParameter("id");
        String password = request.getParameter("password");

        // 2. DAO를 통해 인증 시도
        MemberDAO dao = new MemberDAO();
        int result = dao.loginCheck(id, password);

        // 3. 결과에 따른 처리
        if (result == 1) { // 로그인 성공
            // 세션 생성 및 사용자 정보 저장
            HttpSession session = request.getSession();
            session.setAttribute("userId", id);
            response.sendRedirect("main.jsp");
        } else { // 로그인 실패
            // 에러 메시지를 request에 저장
            request.setAttribute("error", "아이디 또는 비밀번호가 올바르지 않습니다.");
            // 포워드를 통해 login.jsp로 이동하여 에러 메시지 출력
            RequestDispatcher dispatcher = request.getRequestDispatcher("login.jsp");
            dispatcher.forward(request, response);
        }
    }
}

LogoutServlet.java

// LogoutServlet.java
package com.example.controller;

import java.io.IOException;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;

@WebServlet("/logout.do")
public class LogoutServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 1. 세션 가져오기 (없으면 null 반환)
        HttpSession session = request.getSession(false);

        // 2. 세션이 존재하면 무효화
        if (session != null) {
            session.invalidate();
        }

        // 3. 로그인 페이지로 리다이렉트
        response.sendRedirect("login.jsp");
    }
}

이처럼 JSP/Servlet 기반 MVC 웹 애플리케이션에서는 각 구성 요소가 명확한 역할을 수행한다.

요청은 컨트롤러(서블릿)가 받아서 흐름을 제어한다. 데이터 처리와 비즈니스 로직은 모델(DAO, DTO)이 담당한다. 화면 표시는 뷰(JSP)가 담당한다.

이러한 역할 분담은 코드의 재사용성을 높이고 유지보수를 용이하게 만든다.

특히** HTML나 JSP 폼(form)**에서 넘어온 많은 파라미터를 처리하는 코드는 순식간에 지저분해지고 관리가 어렵다.

<%
    // 스크립틀릿을 사용한 지저분한 코드의 예
    request.setCharacterEncoding("UTF-8");
    String id = request.getParameter("id");
    String password = request.getParameter("password");
    String name = request.getParameter("name");
    String email = request.getParameter("email");

    // 넘어온 파라미터마다 객체를 생성하고 setter를 호출해야 한다.
    Person p = new Person(); 
    p.setId(id);
    p.setPassword(password);
    p.setName(name);
    p.setEmail(email);
%>

JSP의 본래 목적인 '화면 표현(View)'에 집중하기 위해, 이러한 자바 로직 코드를 분리할 필요가 있다.

이때 JSP 액션 태그(Action Tag) 중 하나인 <jsp:useBean>이 강력한 해결책이 되어준다.

자바빈(JavaBean)이란 ?

<jsp:useBean>을 사용하려면, 데이터를 담을 자바 객체가 특정 규칙을 따라야 한다.

이러한 객체를 자바빈(JavaBean)이라고 부른다.

자바빈의 규칙

1. 클래스는 public으로 선언되어야 한다.
2. 멤버 변수(프로퍼티)는 private으로 선언하여 외부 접근을 막는다.
3. 각 멤버 변수에 접근할 수 있는 public 접근자인 getter/setter 메서드가 있어야 한다.
4. 인자(매개변수)가 없는 기본 생성자가 반드시 있어야 한다.

EX: Person.java

package com.example.bean; // 패키지 경로

// 1. public 클래스
public class Person {

    // 2. private 멤버 변수
    private String id;
    private String name;

    // 4. 기본 생성자
    public Person() {
    }

    // 3. public Getter/Setter 메서드
    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

ECLIPSE에서 Getter Setter 쉽게 설정하는 법

<jsp:useBean>이란?

<jsp:useBean>은 JSP 페이지에서 사용할 자바빈(JavaBean) 객체를 선언, 생성, 관리해주는 액션 태그이다.

스크립틀릿의 복잡한 코드를 아래와 같이 간결한 태그 몇 줄로 완벽하게 대체할 수 있다.

<jsp:useBean> 자바빈 객체를 생성하거나, 지정된 scope에 이미 객체가 존재하면 그 객체를 가져온다.

<jsp:setProperty> useBean으로 준비된 객체의 필드(프로퍼티)에 값을 자동으로 설정한다.

<jsp:getProperty> 객체 필드의 값을 가져와 화면에 출력한다.

useBean 사용 예 (Before & After)

personAction.jsp

Before: 스크립틀릿 사용

<%@ page import="com.example.bean.Person" %>
<%
    request.setCharacterEncoding("UTF-8");

    Person p = new Person(); // 직접 객체 생성
    p.setId(request.getParameter("id")); // 파라미터 하나하나 직접 설정
    p.setName(request.getParameter("name"));
%>
아이디: <%= p.getId() %> <br>
이름: <%= p.getName() %>

After: <jsp:useBean> 액션 태그 사용

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<% request.setCharacterEncoding("UTF-8"); %>

<%-- 1. Person 객체를 request 영역에서 찾거나, 없으면 새로 생성하여 'p'라는 이름으로 사용 --%>
<jsp:useBean id="p" class="com.example.bean.Person" scope="request" />

<%-- 2. p 객체의 프로퍼티(id, name)에 요청 파라미터 값을 자동으로 설정 --%>
<jsp:setProperty name="p" property="*" />

아이디: <jsp:getProperty name="p" property="id" /> <br>
이름: <jsp:getProperty name="p" property="name" />

액션 태그 자세히 보기

<jsp:useBean id="p" class="com.example.bean.Person" scope="request" />

id: JSP 페이지 내에서 사용할 객체의 변수 이름(p)을 지정한다.

class: 사용할 자바빈의 전체 클래스 경로(패키지 포함)를 지정한다.

scope: 객체가 저장되고 유지될 메모리 영역을 지정한다. (page, request, session, application 중 선택)
<jsp:setProperty name="p" property="*" />

name: 값을 설정할 자바빈 객체의 id를 지정한다. (useBean의 id와 일치)

property="*"** 요청 파라미터의 이름과 자바빈의 프로퍼티(멤버 변수) 이름이 일치하는 모든 항목에 대해, 해당 setter 메서드(setId(), setName() 등)를 자동으로 호출하여 값을 설정해준다.

왜 <jsp:useBean>을 사용해야 할까?

<jsp:useBean> 액션 태그를 사용하면 JSP 페이지에서 데이터 처리 로직(Java 코드)을 거의 완벽하게 제거할 수 있다.

이를 통해 몇가지 이점을 얻는다.

1. 가독성 및 유지보수성 향상: HTML과 유사한 태그로 로직을 처리하므로 코드가 훨씬 깔끔하고 이해하기 쉬워집니다.
2. 역할 분리: JSP는 화면을 그리는 역할에, 자바빈은 데이터를 담는 역할에 집중할 수 있어 웹 애플리케이션의 구조가 명확해집니다.
3. 생산성 증가: property="*" 속성 하나로 수많은 request.getParameter()와 setter 호출 코드를 대체하여 개발 시간을 단축시킵니다.

이때 <jsp:getProperty>보다 훨씬 직관적이고 간결하게 객체의 값을 출력하는 방법이 있다.

바로 표현 언어(Expression Language, EL)를 사용하는 것이다.

{p.id}와 같은 형태로 값을 가져오는 방법이 바로 EL의 기본 문법이다.

표현 언어(EL)란?

EL은 JSP 2.0부터 기본으로 포함된 기능으로, JSP 페이지에서 데이터에 더 쉽게 접근하기 위해 만들어진 언어이다.

$ 기호와 중괄호 {}를 사용하여 표현한다. (예: ${표현식})

EL을 사용하면 <jsp:getProperty>나 스크립틀릿 표현식(<%= ... %>) 없이도 자바빈의 프로퍼티, 컬렉션, 배열 등의 값에 간단하게 접근할 수 있다.

EL을 사용한 개선 방법

Before: <jsp:getProperty> 사용

아이디: <jsp:getProperty name="p" property="id" /> <br>
이름: <jsp:getProperty name="p" property="name" />

After: 표현 언어(EL) 사용

아이디: ${p.id} <br>
이름: ${p.name}

코드가 훨씬 간결하고 직관적으로 변한 것을 바로 확인할 수 있다.

또 자바스크립트에서 객체 속성에 접근하는 것과 유사하여 JS를 접해봤다면 이해하기도 쉽다.

EL의 동작원리

1. 객체 저장 <jsp:useBean id="p" ... scope="request" /> 태그는 Person 객체를 생성하여 request라는 메모리 영역(scope)에 p라는 이름으로 저장한다.

2. 객체 검색 EL 표현식 ${p.id}가 실행되면, JSP 컨테이너는 다음 순서로 p라는 이름의 객체(Attribute)를 자동으로 찾는다. page 영역 -> request 영역 -> session 영역 ->application 영역

3. Getter 호출 request 영역에서 p 객체를 찾으면, EL은 p.id 부분을 해석하여 p.getId() 메서드를 자동으로 호출하고 그 반환값을 해당 위치에 출력한다.

최종 완성 코드 (useBean + setProperty + EL)

이 세 가지를 조합하면 가장 이상적이고 현대적인 JSP 코드가 완성된다.

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<% request.setCharacterEncoding("UTF-8"); %>

<%-- 1. useBean으로 Person 객체를 request 영역에 준비 --%>
<jsp:useBean id="p" class="com.example.bean.Person" scope="request" />

<%-- 2. setProperty로 폼 파라미터 값을 객체에 자동으로 채우기 --%>
<jsp:setProperty name="p" property="*" />

<h3>회원 정보 (EL 사용으로 깔끔해진 코드)</h3>
<ul>
    <li>아이디: ${p.id}</li>
    <li>이름: ${p.name}</li>
</ul>

쿠키(Cookie)

HTTP 프로토콜은 '상태가 없는(Stateless)' 특징을 가진다.

이는 서버가 각 요청을 독립적인 것으로 취급하여 이전 요청을 기억하지 못함을 의미한다.

"방금 로그인한 사용자가 누구인지" 알 수 없는 것이다.

이 문제를 해결하기 위해, 서버는 브라우저에 작은 정보를 남겨두는데 이것이 바로 쿠키(Cookie)다.

쿠키는 서버가 사용자의 브라우저(클라이언트)에 저장하는 작은 텍스트 조각이다.

브라우저는 서버에 요청을 보낼 때마다 이 쿠키를 함께 전송하여, 서버가 사용자를 식별할 수 있도록 돕는다.

쿠키의 주요 역할

상태 관리 사용자의 로그인 상태를 유지(자동로그인)한다. 비로그인 상태의 장바구니를 관리한다.

사용자 추적 사용자의 방문 기록이나 행동 패턴을 분석하는 데 사용된다.

개인화 "오늘 하루 이 창을 열지 않음" 팝업, 언어 설정 등 사용자 맞춤형 경험을 제공한다.

JSP 쿠키 객체(Cookie) 활용법

JSP에서 쿠키를 다루는 방법은 매우 간단하다.

1. 쿠키 생성 및 전송 response 내장 객체를 사용한다.

<%
    // 1. "userId"라는 이름에 "guest"라는 값을 가진 쿠키 객체 생성
    Cookie cookie = new Cookie("userId", "guest");

    // 2. 쿠키 유효기간 설정 (초 단위, 여기서는 24시간)
    cookie.setMaxAge(60 * 60 * 24);

    // 3. response 객체에 쿠키를 추가하여 클라이언트로 전송
    response.addCookie(cookie);
%>

2. 쿠키 읽기 request 내장 객체를 사용한다. 브라우저는 여러 쿠키를 가질 수 있으므로 배열 형태로 받아온다.

<%
    // 1. request로부터 모든 쿠키를 배열로 가져온다.
    Cookie[] cookies = request.getCookies();
    String userId = "";

    if (cookies != null) {
        // 2. 쿠키 배열을 순회하며 원하는 이름의 쿠키를 찾는다.
        for (Cookie c : cookies) {
            if (c.getName().equals("userId")) {
                userId = c.getValue();
                break; // 찾았으면 반복 종료
            }
        }
    }
%>
<p>현재 사용자 ID는 <%= userId %> 입니다.</p>

3. 쿠키 삭제 쿠키를 직접 삭제하는 메서드는 없다. 대신, 유효기간을 0으로 설정하여 브라우저가 즉시 삭제하도록 유도할 수 있다.

<%
    Cookie cookie = new Cookie("userId", ""); // 값은 비워도 무방하다.
    cookie.setMaxAge(0); // 유효기간을 0으로 설정
    response.addCookie(cookie);
%>

쿠키는 클라이언트 측에 데이터를 저장하는 간단하고 유용한 방법이다.

하지만 보안에 민감한 정보나 큰 데이터를 저장하기에는 적합하지 않다.

이러한 단점을 보완하기 위해 서버 측 저장 방식인 세션을 사용한다.

세션(Session)

쿠키는 브라우저에 저장되어 보안에 취약하고 저장 데이터의 양도 제한적이다.

로그인 정보나 장바구니처럼 중요하고 복잡한 정보는 세션(Session)을 이용해 처리해야 한다.

세션은 쿠키와 달리 데이터를 서버 쪽에 저장하는 방식이다.

서버는 각 클라이언트를 위한 고유한 저장 공간(세션)을 만들고, 클라이언트에게는 그 공간에 접근할 수 있는 '열쇠(ID)'만 쿠키 형태로 전달한다.

클라이언트는 요청 시마다 이 열쇠를 함께 보내고, 서버는 열쇠를 보고 맞는 세션 저장소의 데이터를 사용한다.

세션의 동작 원리

1. 최초 접속 클라이언트가 서버에 처음 접속하면, 서버는 고유한 세션 ID를 생성한다.

2. 세션 저장소 생성 서버 메모리에 해당 세션 ID와 연결되는 저장 공간을 만든다.

3. 세션 ID 전송 서버는 생성한 세션 ID를 클라이언트 브라우저에 쿠키(보통 JSESSIONID 이름) 형태로 저장시킨다.

4. 재접속 클라이언트가 다시 요청하면, 브라우저는 자동으로 세션 ID 쿠키를 함께 보낸다.

5. 세션 데이터 활용 서버는 전달받은 세션 ID를 통해 서버에 저장된 해당 클라이언트의 데이터를 찾아 사용한다.

JSP 세션(session) 내장 객체 활용법

JSP는 세션을 편리하게 다루도록 session이라는 내장 객체를 기본으로 제공한다.

1. 세션에 값 저장하기 setAttribute("이름", 값) 메서드를 사용한다. 값으로는 모든 종류의 객체(Object)를 저장할 수 있다.

<%
    String userId = "testuser";
    // "loginId" 라는 이름으로 userId 변수의 값을 세션에 저장
    session.setAttribute("loginId", userId);
%>

2. 세션에서 값 불러오기 getAttribute("이름") 메서드를 사용한다. 반환 타입이 Object이므로, 원래 타입으로 형 변환(Casting)이 필요하다.

<%
    // "loginId" 라는 이름의 세션 값을 가져온다.
    Object value = session.getAttribute("loginId");
    String loginId = "";
    if (value != null) {
        loginId = (String) value;
    }
%>
<p>현재 로그인한 아이디: <%= loginId %></p>

3. 세션에서 특정 값 삭제하기 removeAttribute("이름") 메서드를 사용한다.

<%
    // "loginId" 세션만 삭제
    session.removeAttribute("loginId");
%>

4. 세션 전체 무효화 (로그아웃) invalidate() 메서드를 사용한다. 해당 클라이언트의 세션 저장소 전체가 서버에서 삭제된다.

<%
    // 세션을 완전히 종료시킨다 (로그아웃 시 사용).
    session.invalidate();
%>

Java로 웹 개발을 시작하면 가장 먼저 JSP(JavaServer Pages)와 서블릿(Servlet)을 만나게 된다.

서블릿 (Servlet) 서블릿은 순수 자바(Java) 코드이다. 서블릿은 사용자의 요청을 처리하고, 비즈니스 로직을 실행하며, 데이터를 제어하는 역할을 수행한다.

JSP (JavaServer Pages) JSP는 HTML 코드 안에 자바 코드를 삽입하여 사용한다. JSP는 사용자에게 최종적으로 보여질 화면의 구조와 내용을 담는다.

서블릿의 한계

초기 웹 개발에서는 서블릿만으로 모든 것을 처리했다.

out.println("<html><body><h1>안녕하세요</h1></body></html>");

위의 코드처럼 자바만을 이용해 한 줄 한 줄 HTML을 문자열로 출력하는 것은 비효율적이었다.

디자인을 조금만 변경해도 자바 코드를 다시 컴파일해야 하는 번거로움도 있었다.

이처럼 서블릿은 로직 처리에는 강력하지만, 화면을 구성하는 표현(Presentation)에는 매우 취약한 구조를 가졌다.

JSP : HTML 문서에 자바를 심다

이러한 불편을 해결하기 위해 JSP가 등장했다.

JSP는 반대로 HTML을 기본 구조로 삼고, 필요한 부분에만 자바 코드를 넣어 동적으로 데이터를 처리할 수 있도록 했다.

이로써 디자이너는 자바를 몰라도 HTML 구조를 쉽게 수정하고, 개발자는 필요한 부분에만 로직을 추가하는 역할 분담이 가능해졌다.

MVC 패턴

MVC 패턴 및 JSP 프로젝트 구조

결론적으로 현대 웹 개발은 이 둘을 함께 사용하는 MVC(Model-View-Controller) 패턴으로 정착되었다.

Controller(컨트롤러) : 서블릿 사용자의 모든 요청을 가장 먼저 받는다. 필요한 비즈니스 로직을 처리하고 데이터를 가공한다. 그 결과를 어떤 JSP에게 보여줄지 결정하여 전달한다.

View(뷰) : JSP 컨트롤러(서블릿)로부터 전달받은 데이터를 화면에 그리는 역할에만 집중한다.

Model(모델) 데이터 그 자체나 데이터를 처리하는 자바 클래스(JavaBean, DTO, DAO 등)를 의미한다.

흐름 사용자 요청 → 서블릿이 받아서 처리 → 결과를 JSP에 전달 → JSP가 화면을 그려서 사용자에게 응답

JSP 핵심 문법 요약

나도 그랬듯이 초보자들은 프로젝트를 시작할 때, 모든 코드를 파일 하나에 다 넣으려고 한다.

하지만 JSP를 예로 들었을때 HTML, CSS, JavaScript, 자바 로직, 데이터베이스 연결 코드까지 한 파일에 뒤섞이면 처음에는 빠르게 결과물이 나오는 것처럼 보인다.

하지만 프로젝트가 조금만 커져도, 그 코드는 누구도 손대고 싶지 않은 '스파게티 코드'가 되어버린다.

잘못된 프로젝트 구조는 유지보수를 악몽으로 만들고, 팀원과의 협업을 불가능하게 한다.

프로젝트에서 왜 구조가 중요한지, 그리고 가장 표준적으로 사용되는 MVC 패턴을 기반으로 어떻게 깔끔한 구조를 만들 수 있는지 설명하겠다.

왜 프로젝트 구조가 중요한가?

역할 분담 디자이너는 화면(View)에, 개발자는 로직(Controller, Model)에 집중할 수 있게 한다.

유지보수성 "로그인 로직을 수정해야지" 라고 생각했을 때, LoginServlet.java와 MemberDAO.java만 보면 되도록 만들어준다. 수많은 JSP 파일을 뒤질 필요가 없다.

재사용성 잘 만들어진 데이터베이스 처리 로직(MemberDAO)은 회원 정보가 필요한 어떤 페이지에서든 재사용할 수 있다.

협업 효율성 모든 팀원이 파일이 어디에 위치하고 어떤 역할을 하는지 예측할 수 있어, 코드 충돌을 줄이고 개발 속도를 높인다.

JSP 프로젝트의 표준 구조: MVC 패턴

JSP/Servlet 웹 애플리케이션의 구조를 잡는 가장 표준적인 방법은 MVC 패턴이다. 이 패턴은 프로젝트를 세 가지 역할로 명확하게 나눈다.

Model 데이터 그 자체(DTO/VO)와 데이터를 처리하는 비즈니스 로직(Service, DAO). 순수 자바 클래스로 구성된다.

View 사용자에게 보여지는 화면. JSP 파일이 이 역할을 전담한다.

Controller 사용자의 요청을 받고, 모델과 뷰를 연결하는 중재자. 서블릿(Servlet)이 이 역할을 맡는다.

예시: 기본적인 MVC 프로젝트 폴더 구조

이클립스의 'Dynamic Web Project' 기준으로, 다음과 같은 구조를 따르는 것이 일반적이다.

my-web-project/
├── src/main/java/          # 순수 자바 코드가 위치하는 곳 (Model, Controller)
│   └── com/example/
│       ├── controller/     # 1. Controller (서블릿)
│       │   ├── LoginServlet.java
│       │   └── JoinServlet.java
│       ├── model/          # 2. Model (데이터 관련 클래스)
│       │   ├── dao/        #    - DAO (Data Access Object)
│       │   │   └── MemberDAO.java
│       │   └── dto/        #    - DTO (Data Transfer Object)
│       │       └── MemberDTO.java
│       └── util/           # 3. 유틸리티 클래스
│           └── DBManager.java  (DB 커넥션 풀 관리 등)
│
├── src/main/webapp/        # 웹 콘텐츠가 위치하는 곳 (View)
│   ├── WEB-INF/
│   │   ├── web.xml         #    - 서블릿 매핑 등 웹 애플리케이션 설정 파일
│   │   └── lib/            #    - 외부 라이브러리 (ex: ojdbc.jar)
│   ├── member/             # 기능별로 폴더를 나누면 좋음
│   │   ├── login.jsp
│   │   └── join.jsp
│   ├── main.jsp
│   ├── index.jsp
│   └── css/
│       └── style.css
│
└── pom.xml                 # (Maven 프로젝트인 경우) 의존성 관리 파일

각 폴더의 역할

1. src/main/java 백엔드 로직의 핵심 controller 패키지 사용자의 모든 HTTP 요청(GET, POST)을 가장 먼저 받는 서블릿들이 위치한다. 서블릿은 요청을 분석해서 어떤 모델을 사용할지, 어떤 뷰를 보여줄지 결정하는 '교통경찰' 역할을 한다.

   model.dao 패키지 MemberDAO처럼 데이터베이스에 직접 접근하여 INSERT, SELECT, UPDATE, DELETE (CRUD) 로직을 전담하는 클래스들이 모여있다.

   model.dto 패키지 MemberDTO처럼 데이터베이스 테이블의 정보를 행(Row) 단위로 담기 위한 객체(JavaBean)들이 위치한다. 계층 간 데이터 전송을 위한 '데이터 그릇'이다.

2. src/main/webapp

사용자의 눈에 보이는 모든 것 내가 앞으로 공유할 코드들과 나의 Github에 있는 코드들은 교수님께 배운대로 모두 경로를 WebContents 바꿔놨다.

이클립스 기준으로 프로젝트 생성시에 경로를 바꿀 수 있다.

이 폴더 아래의 파일들은 URL을 통해 직접 접근이 가능하다. (단, WEB-INF 폴더 제외)

.jsp 파일 (View) 컨트롤러(서블릿)로부터 전달받은 데이터를 화면에 동적으로 그리는 역할을 한다. 자바 로직은 최소화하고, 화면 표시에만 집중해야 한다.

css, js, images 폴더 정적인 리소스 파일들을 위치시킨다.

3. WEB-INF

보안이 필요한 핵심 설정 공간 이 폴더 안의 파일들은 클라이언트가 URL로 직접 요청할 수 없어 보안에 유리하다.

web.xml 배포 서술자(Deployment Descriptor)라고 부른다. 어떤 URL 요청을 어떤 서블릿으로 연결할지(서블릿 매핑), 필터, 리스너 등 웹 애플리케이션의 핵심 설정을 정의한다.

lib jdbc.jar 같은 외부 라이브러리(JAR 파일)를 위치시키는 곳이다.

파일이 함께 동작하는 방식 (로그인 과정 예시)

1. 사용자 요청 사용자는 login.jsp에서 아이디와 비밀번호를 입력하고 '로그인' 버튼을 누른다. 폼의 action은 /login을 가리킨다.

2. Controller (서블릿) 처리 web.xml에 /login 요청을 처리하도록 매핑된 LoginServlet이 요청을 가로챈다.

   LoginServlet은 request.getParameter()로 사용자가 입력한 아이디와 비밀번호를 받는다.

   MemberDAO 객체를 생성하고, dao.loginCheck(id, pw) 메서드를 호출하여 DB에 해당 사용자가 있는지 확인한다.

3. Model (DAO, DTO) 작업: MemberDAO는 커넥션 풀에서 DB 커넥션을 얻어와 SELECT 쿼리를 실행한다.

   결과가 있다면 로그인 성공, 없으면 실패로 판단하고 그 결과를 LoginServlet에 반환한다.

4. View (JSP)로 전달 및 표시:

   로그인 성공 시: LoginServlet은 session.setAttribute("userId", id)로 세션에 로그인 정보를 기록한 뒤, response.sendRedirect("main.jsp")를 통해 메인 페이지로 사용자를 보낸다.

   로그인 실패 시: 에러 메시지를 request에 담아 RequestDispatcher를 이용해 다시 login.jsp로 포워딩한다. login.jsp는 전달받은 에러 메시지를 화면에 표시한다.

이처럼 역할에 따라 프로젝트 구조를 명확히 나누는 것은 선택이 아닌 필수이다.

MVC 패턴은 복잡한 웹 애플리케이션을 여러 개발자가 협업하여 만들고, 오랫동안 안정적으로 유지보수할 수 있게 하는 가장 검증되고 안정적인 방법이다.

실무에서 쓰이는 개념들을 하나하나 익힐수록 개인 프로젝트도 관리가 편해지고 뭔가 효율적이고 깔끔한 코딩을 하게되는 것 같다.

최종_보고서.hwp 진짜최종_보고서.hwp 진짜진짜최종_수정본_보고서.hwp 교수님께_보낼파일_최종.hwp

우리는 모두 파일의 버전을 관리하느라 고통받아 본 경험이 있다.

개발 프로젝트는 수십, 수백, 수만 개의 파일로 이루어져 있고, 수많은 사람이 동시에 작업한다.

위와 같은 방식으로 파일 버전을 관리하며 이메일로 파일을 주고받기엔 한계가 있다.

이때 사용하는 도구가 바로 Git과 GitHub이다.

Git & GitHub, 무엇이 다른가?

가장 먼저 이 둘의 관계를 명확히 해야 한다.

Git은 '도구'이고, GitHub는 그 도구를 활용하는 '서비스'이다.

Git (소프트웨어): 버전 관리 '소프트웨어(도구)'

내 컴퓨터에 설치하여 코드의 변경 이력을 사진 찍듯이 저장하고, 언제든 과거로 돌아갈 수 있는 타임머신 역할을 한다.

인터넷 없이도 내 컴퓨터에서 모든 버전 관리가 가능하다.

GitHub (웹 서비스): Git으로 관리하는 프로젝트를 올려두는 '웹 호스팅 서비스'

Git이라는 도구만으로는 힘든 백업, 공유, 협업을 가능하게 해준다.

왜 반드시 함께 사용해야 하는가?

1. 완벽한 버전 관리 (Git) + 안전한 클라우드 백업 (GitHub) Git으로 내 코드의 모든 변경사항을 기록하고, GitHub에 올려두면 내 컴퓨터가 고장 나도 코드는 안전하다.
2. 체계적인 개인 프로젝트 관리 (Git) + 훌륭한 공개 포트폴리오 (GitHub) Git으로 내 프로젝트를 관리하고 GitHub에 꾸준히 올리는 것은, "나는 이렇게 코딩하고 성장해왔다"를 보여주는 가장 확실한 이력서가 된다.
3. 강력한 독립 작업 (Git Branch) + 체계적인 팀 협업 (GitHub Pull Request) Git의 브랜치 기능으로 내 작업을 독립적으로 수행하고, GitHub의 Pull Request 기능으로 팀원들에게 코드 리뷰를 요청하며 안전하게 코드를 병합할 수 있다.

기초 사용법

1. 최초 설정 (컴퓨터에 딱 한 번만)

Git을 설치한 후, 커밋에 기록될 내 정보를 설정한다.

Git Bash를 설치하고 다음을 입력한다.

이때 복사와 붙여넣기는 ctrl + c ctrl + v 대신 ctrl + insert shift + insert로 사용한다.

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

2. 로컬 프로젝트 생성 및 GitHub에 올리기

1단계: 내 컴퓨터에서 Git 관리 시작

# 프로젝트 폴더를 만들고 이동
mkdir my-project
cd my-project

# 이 폴더를 Git으로 관리 시작!
git init

아니면 vscode에서 터미널 창에서 bash를 선택하거나 프로젝트 폴터에서 우클릭 후 이 경로에서 bash 실행하기를 통해 생략할 수 있다.

2단계: 코드 수정 및 로컬에 버전 저장 (add & commit)

# 변경된 모든 파일을 스테이징(장바구니에 담기)
git add .

# 장바구니에 담긴 내용을 하나의 버전으로 저장(커밋)
git commit -m "Initial commit: Add README.md"

3단계: GitHub 원격 저장소 생성 및 연결

1. GitHub에 로그인하여 New repository 버튼으로 새로운 저장소를 만든다.

2. 생성된 저장소의 URL(예: https://github.com/YourName/my-project.git)을 복사한다.

3. 내 컴퓨터 터미널에서 아래 명령어로 로컬 저장소와 원격 저장소를 연결한다.

# 원격 저장소 주소를 'origin'이라는 이름으로 추가
git remote add origin https://github.com/YourName/my-project.git

# 로컬의 main 브랜치를 원격 저장소(origin)로 업로드(push)
git push -u origin main

이제 my-project는 내 컴퓨터와 GitHub 양쪽에 모두 존재하며 서로 연결되었다.

3. 협업의 기본 사이클: Pull → Branch → Commit → Push → Pull Request

팀 프로젝트에 참여할 때의 일반적인 작업 흐름이다.

1단계: 작업 시작 전, 항상 최신 코드로 동기화

다른 팀원이 수정했을지 모르는 최신 코드를 원격 저장소에서 내 컴퓨터로 가져온다.

git pull origin main

2단계: 나만의 작업 공간(브랜치) 만들기

main 브랜치를 직접 건드리지 않고, 새로운 기능을 개발하기 위한 독립된 브랜치를 만든다.

# 'feature/login' 이라는 브랜치를 만들고 그곳으로 이동
git checkout -b feature/login

3단계: 기능 개발 및 커밋

이제 feature/login 브랜치에서 마음껏 코드를 수정하고, add와 commit으로 작업 단위를 저장한다.

# (열심히 코딩...)
git add .
git commit -m "Feat: Implement user login logic"

4단계: 내 브랜치를 원격 저장소에 업로드

내가 만든 feature/login 브랜치를 팀원들이 볼 수 있도록 GitHub에 올린다.

git push origin feature/login

5단계: Pull Request(PR) 생성

가장 중요한 협업 과정이다.

1. GitHub 사이트로 이동하면 "feature/login 브랜치에 변경사항이 있으니 Pull Request를 생성할래요?" 라는 초록색 버튼이 보인다.
2. 버튼을 눌러 내가 작업한 내용과 리뷰를 요청하는 메시지를 작성하고 PR을 생성한다.
3. 이제 팀원들은 내 코드를 보고 의견을 남길 수 있다. 리뷰가 끝나고 승인이 나면, 관리자가 Merge 버튼을 눌러 내 코드를 main 브랜치에 안전하게 합친다.

Git과 GitHub는 더 이상 선택이 아닌 필수라고 한다.

협업할때 뿐만 아니라 개인 프로젝트를 할때도 버전을 효율적으로 관리하고 포트폴리오로도 활용하기 위해 Git이 중요한 것 같다.

이전에 진행하였던 나의 프로젝트도 GitHub에 업로드해서 수정사항들을 더 체계적으로 관리하고 새로운 업데이트가 생겼을때 bash를 이용해 더욱 편하게 관리할 수 있을 것이다.

앞으론 터미널의 claude code와 Mcp를 활용해보며 교수님이 학기중에 수도 없이 말씀하신 바이브 코딩 능력을 길러봐야겠다.