1년 차 엔지니어의 '학습 누락'을 AI 에이전트에게 관리하게 해 보았다

안녕하세요, 라쿠텐 그룹 주식회사(Rakuten Group, Inc.)의 하야시입니다.

이번에는 1년 차 엔지니어로서 느꼈던 'AI에 대한 의존과 학습의 정착'이라는 과제에 대해, Claude Code로 Skill 등을 사용하여 체계를 만들어 본 이야기를 쓰고자 합니다. 아직 시행착오를 겪는 중이라 불완전한 부분도 있지만, 참고가 된다면 기쁘겠습니다. 또한, '이렇게 하는 게 더 좋지 않을까' 하는 아이디어가 있다면 알려주시면 감사하겠습니다.

서론

신입으로서 첫 1년 동안, AI 활용은 팀 차원에서 크게 환영받고 있었지만, 한편으로는 활용이 아니라 의존이 되어가고 있는 것은 아닌가 하는 불안함을 느끼고 있었습니다.

앞으로의 AI 시대를 고려했을 때의 이상적인 모습은, 자신은 확실한 지식과 기술력을 가진 매니저(Manager)이고, AI는 부하 직원처럼 부릴 수 있는 존재인 상태라고 생각합니다. 하지만 지난 1년간의 AI와의 관계는 오히려 그 반대였으며, 극단적으로 말하면 'AI의 부하'와 같은 상태가 되기 쉬웠습니다.

이대로는 안 되겠다고 느껴, AI에 대한 의존을 줄이고 그날의 학습을 확실히 정착시키기 위한 체계를 만들기로 했습니다. 평소 업무를 되돌아보니 다음과 같은 두 가지 과제가 보였습니다.

과제 ①: AI에게 통째로 맡겨버림 (丸投げ)

구체적인 상황을 예로 들면 다음과 같았습니다.

구현 중, 에러 메시지를 스스로 해석하려 하지 않고 그대로 AI에 붙여넣는 경우가 있었습니다. AI가 원인을 특정해 주므로 문제는 해결되지만, '왜 그 에러가 발생했는지'를 스스로 생각하게 되지는 않습니다.

선배의 리뷰 코멘트도 마찬가지였습니다. "이 방식은 좋지 않다"라는 지적을 받았을 때, AI에게 "왜 좋지 않은지 알려줘"라고 물어보고, 돌아온 설명을 읽고 "그렇구나" 하고 끝내버리는 것입니다. 일주일 뒤에 똑같은 방식으로 코드를 작성하는 일도 있었습니다.

물어보면 바로 해결된다는 점은 AI의 편리함이기도 하지만, 이것만으로는 자신 안에 아무것도 쌓이지 않습니다.

과제 ②: 심화되지 않은 학습이 산재함

AI에 대한 의존과는 별개로, 일일 학습이 정착되지 않는 문제도 있었습니다.

프로젝트마다 수행한 일의 정리나 그날의 학습을 메모하고 있었지만, 복기(Review)가 불충분하거나 애초에 복기를 하지 못하는 경우도 있었습니다. 팀 내의 기술적인 이야기가 사내 커뮤니케이션 툴에 흘러가더라도, 읽지 못하고 묻혀버리는 일도 있었습니다. 그날 새롭게 접한 기술은 많았지만, '줍지 못한 지식'이 많은 상태였습니다.

커뮤니케이션 툴에서 흘러가 버린 정보를 포함하여, 그날 접한 지식을 한곳에 집약하고 학습을 최대화하는 체계가 필요했습니다.

해결 접근 방식: 그날의 기록을 집약하여 리포트로 만들기

위의 과제에 대해, 'AI에게 통째로 맡기는 것을 없애는 것'과 '그날의 학습을 정착시키는 것'을 목표로 체계를 만들었습니다.

과제 ①에 대해서는 다음 두 가지 점을 체계로 설계했습니다.

Claude Code와의 대화 속에서 의존하고 있는지를 탐지한다 [A-1]
하루의 마지막에 세션 이력을 분석하여 AI 의존도를 스코어(Score)화한다 [B]

과제 ②에 대해서는 다음과 같은 체계를 생각했습니다.

Claude Code와의 대화 중, 제가 기술적인 질문을 했을 때 그에 대한 답변을 생성한 후, 조금 더 심화된 질문을 던지도록 한다 [A-2]
학습 내용을 dailyLearned.md에 제가 직접 쓰도록 하고, Claude Code가 리뷰한다 [A-3]
하루의 마지막에 그날의 진척 상황과 그에 대응하는 학습 내용을 리포트로 정리하고, 마지막에 복기하는 시간을 갖는다 [B]

위의 체계를 실현하기 위해, [A-*]에 대해서는 모든 세션 공통의 대화 규칙으로 정의하기 위해 ~/.claude/CLAUDE.md에 기술했습니다. [B]에 대해서는 별도로 두 개의 Skill을 생성했습니다.

A. 대화 규칙

대화 규칙은 ~/.claude/CLAUDE.md에 기술했습니다. 여기에 기술함으로써 글로벌하게 모든 세션에서 이 규칙이 적용되도록 했습니다.

A-1. 의존 탐지 규칙

코드 조사를 통째로 맡기는 경우(예: "〇〇 클래스의 CRUD를 전부 조사해줘" 등), Claude Code는 조사를 완료한 후 답을 직접 전달하는 대신, 먼저 읽어야 할 곳을 힌트로 제시합니다.

"
〇〇 클래스의 △△ 메서드를 보면 좋습니다. 어떤 구현이 되어 있을 것 같나요?"

제가 가설을 제시하면, 그것을 바탕으로 정오표나 보충 설명을 전달합니다. "정답을 주기 전에 스스로 생각할 기회를 만든다"으로써, 단순히 떠넘기는 것이 아니라 이해로 이어지게 하는 것이 목적입니다. 단, 긴급 대응이나 "서둘러"라고 명시한 경우, 처음 보는 코드베이스라 가설을 세울 수 있는 문맥이 없는 경우 등에는 이를 건너뛰고 직접 정답을 전달합니다.

A-2. 심화 질문 규칙

기술적인 개념이나 구조에 대해 질문하고 답변을 받은 후, Claude Code는 반드시 1~2개의 퀴즈를 냅니다.

"그럼, 〇〇과 △△의 차이점을 설명할 수 있나요?"

답변이 불완전할 경우에는 보충하여 재설명합니다. "그렇군요"로 끝내지 않고, 이해도를 확인하는 수고를 매번 더하는 구조입니다.

A-3. 학습 리뷰 규칙

dailyLearned.md에 대한 기록은 제가 주도합니다. Claude Code의 역할은 제가 작성한 내용을 읽고 "누락·오류·보충해야 할 점"을 지적하는 리뷰뿐입니다. AI가 자발적으로 작성하는 일은 기본적으로 없으며, 제가 "작성해 둬"라고 명시했을 때만 대필합니다.

B. 일일 리포트 생성 스킬

AI 독립도 스코어를 포함한 일일 리포트 (/daily-summary)

4월부터 /daily-summary라는 자체 제작 스킬을 만들어 사용하기 시작했습니다. 이 스킬은 아래의 정보들을 서브 에이전트(sub-agent)를 통해 병렬로 수집하고, Claude Code 안에서 통합하여 일일 리포트를 생성합니다.

[project-xxx]/progressMemo.md: 프로젝트별 디렉토리 하위에 생성하여 진행 상황 및 TODO를 기록하는 파일
memo/dailyLearned.md: 기술적·비즈니스적 학습 내용을 날짜별로 기록하는 파일
Claude Code의 세션 히스토리 (prompt-review를 참고하여 구현)
git의 커밋 히스토리 및 PR(Pull Request) 내용
브라우저 방문 기록
사내 커뮤니케이션 툴의 대화 기록

수집한 정보로부터 아래 항목을 포함한 리포트가 생성됩니다.

진행 상황: 그날 완료한 태스크나 대응한 문제의 개요
TODO: 내일 이후의 태스크나 미완료된 태스크
학습: 그날 배운 기술적·비즈니스적 지식이나 스킬
AI 독립도 스코어: 그날 AI에 얼마나 의존했는지를 1~5로 수치화한 스코어

학습의 질을 높이기 위해, dailyLearned.md에 작성한 내용을 베이스로 하되, 그날의 진행 상황·TODO 및 각 프로젝트의 progressMemo.md와 연관 짓는 형태로 정리하도록 하고 있습니다. "무엇을 배웠는가"뿐만 아니라 "그 배움이 실제 업무의 어느 장면에서 나왔는가"가 세트로 기록되기 때문에, 추상적인 기술 메모가 아닌 문맥이 있는 회고가 됩니다. 또한, progressMemo.md를 참조함으로써 프로젝트 작업 중에 깨달은 기술적 학습이 dailyLearned.md에 기록되지 않았더라도, 놓친 부분을 리포트에서 찾아낼 수 있습니다. 비즈니스·업무 고유의 내용은 제외하고, 범용적인 기술 지식으로 남길 수 있는 것에 집중하여 보완되는 형태입니다.

나아가, 세션 히스토리를 분석하여 "그날 AI에 얼마나 의존했는가"를 1~5로 수치화한 AI 독립도 스코어가 출력됩니다. 스코어의 기준은 다음과 같습니다.

스코어	라벨	기준
1	전면 의존	에러나 현상을 그대로 AI에게 전달. "안 됩니다", "왜 그런가요"라고만 던짐
...

이 리포트를 매일 저녁에 생성하여 회고하는 시간을 가짐으로써, 그날의 학습 정착과 AI 의존도의 가시화를 도모하고 있습니다.

하루를 관리하는 에이전트 (/daily-agent)

/daily-summary를 통해 일일 리포트를 작성할 때, 각 progressMemo.md를 참조함과 동시에 저 자신의 TODO나 진행 상황도 Claude Code가 참조할 수 있게 하는 것이 더 의미 있는 리포트를 만들 수 있다고 생각하여, /daily-agent라는 TODO·진행 상황 관리용 에이전트도 만들었습니다.

~/ (홈 디렉토리)에 상주하는 리더 에이전트(leader agent)가 전체 TODO를 관리하고, 각 프로젝트 디렉토리에 워커 에이전트(worker agent)가 존재하는 구성입니다.

~/ ← 리더 에이전트 (/daily-agent)
│
├── ~/.config/daily-agent/todos.md ... 전체 TODO 일원 관리
...

각 프로젝트의 워커 에이전트(Worker Agent)가 태스크를 완료하거나 발견하면, 리더 에이전트(Leader Agent)의 todos.md로 집약됩니다. 프로젝트를 넘나드는 TODO의 전체상을 리더 에이전트가 항상 파악하고 있는 형태입니다.

/daily-agent는 하루 동안 리더 에이전트가 자율적으로 움직이는 스킬입니다. 한 번 실행하면 모든 TODO를 관리하며 저와 함께 나란히 달려줍니다. 구체적으로는 다음과 같은 흐름으로 하루를 관리합니다.

아침: 전날의 dailyLearned.md로부터 복습 퀴즈가 출제됩니다. 그 후, todos.md에서 전날의 TODO를 인계받아 오늘의 작업을 정리합니다.
11시·15시: 진척 확인 메시지가 자동으로 날아옵니다. 막히는 부분이 있다면 빠르게 대처할 수 있습니다.
저녁: 회고 대화를 나누고, 그날 배운 것을 dailyLearned.md에 기록합니다.

저녁 체크인(Check-in)이 끝나면 /daily-summary를 실행하여 그날의 기록을 리포트로 정리합니다. 다음과 같은 루프가 자연스럽게 돌아갑니다.

아침 브리핑
↓ 전날의 dailyLearned.md로부터 복습 퀴즈
↓ todos.md로부터 전날의 TODO를 인계
...

실제 리포트

저녁 체크인과 /daily-summary가 끝나면, 다음과 같은 리포트가 완성됩니다. 실제 리포트를 바탕으로 가상의 데이터를 사용하여 작성한 샘플이지만, 구성과 분위기는 그대로입니다.

일일 리포트 샘플 (2026-05-18)

진척 상황

TASK-101: 상품 검색 API의 페이지네이션(Pagination) 구현 완료. 오프셋(Offset) 방식에서 커서(Cursor) 방식으로의 이행 대응
TASK-102: 개발 환경에서의 DB 접속 에러 조사 완료. 커넥션 풀(Connection Pool)의 상한 설정이 원인임을 판명
TASK-103: 코드 리뷰 지적 사항 대응(3건) 완료. 트랜잭션 경계(Transaction Boundary) 재검토 및 에러 핸들링(Error Handling) 추가

TODO (내일 이후)

TASK-101: 스테이징 환경에서의 동작 확인
TASK-104: 배치(Batch) 처리의 타임아웃(Timeout) 설정 재검토 (담당 리뷰어에게 확인 필요)
TASK-105: Spring Boot 3.x 이행 조사 착수

범용 기술 학습 내용

커서 페이지네이션 (Cursor Pagination): 오프셋 방식은 대량 데이터에서 느려진다. 커서 방식은 "마지막으로 가져온 ID보다 큰 것을 가져온다"는 필터링을 통해 일정한 속도를 유지할 수 있다.
Spring @Transactional의 전파 설정 (Propagation Setting): 기본값은 REQUIRED (기존 트랜잭션에 참여). 독립된 트랜잭션이 필요하다면 REQUIRES_NEW를 사용한다. 단, 중첩될 경우 커넥션 풀을 2개 소비한다는 점에 주의.
HikariCP의 maximumPoolSize: 기본값 10. 동시 요청 수가 많을 경우 여기가 병목(Bottleneck)이 된다.

시스템 고유 이해 사항

상품 검색 API 사양: 재고가 0인 상품은 기본적으로 제외된다. include_out_of_stock=true 파라미터로 포함할 수 있다 (관리자 화면 용도).
배치 타임아웃 설정: 운영 환경은 30분, DEV는 5분. 개발 환경에서 테스트할 때는 설정을 일시적으로 변경해야 한다.

비즈니스·승인 플로우

리뷰 코멘트: 커서 페이지네이션 구현 시 정렬 순서가 복합 키(Composite Key)가 되는 경우에 대한 고려가 부족하다는 지적. 다음 PR에서 대응 예정.
팀 기술 공유: Gradle의 BOM (Bill of Materials)에 관한 공유. platform()으로 임포트하면 버전 관리를 일원화할 수 있다는 내용.

AI 독립도 점수

3 / 5 (협조적)

Claude가 본 강점

에러의 근본 원인까지 추적하는 자세: DB 접속 에러를 로그로부터 추적하여 커넥션 풀 설정까지 도달했다. 원인 특정까지 완결 지었다.
리뷰 지적 사항의 당일 대응: 3건의 지적 사항을 당일 중에 대응 및 수정. 피드백 루프(Feedback Loop)가 빠르다.

Claude가 본 이해 격차 (Understanding Gap)

복합 키의 커서 페이지네이션: 단일 컬럼의 커서는 이해했으나, 정렬 키가 여러 개가 되었을 경우의 구현 패턴은 아직 모호함.
@Transactional의 예외 핸들링 (Exception Handling): 체크 예외(Checked Exception)는 기본적으로 롤백(Rollback)되지 않는다. rollbackFor를 명시하지 않으면 빠지기 쉬운 함정이 있으나, 아직 몸으로 익히지는 못한 상태.

오늘 읽은 것 (관련도: 높음·중간만 포함)

커서 페이지ング (Cursor Paging) 설계

대량 데이터 페이지ング (Paging)에서 커서 방식이 유효한 이유와 복합 정렬 키 (Composite Sort Key)에 대한 대응 패턴을 조사.

Spring Boot 트랜잭션 관리 (Transaction Management)

@Transactional의 전파 설정 (Propagation Setting)과 체크 예외 (Checked Exception) · 비체크 예외 (Unchecked Exception)의 롤백 (Rollback) 동작 차이를 확인.

※ 4건 (사내 Wiki · 무관한 기사)은 관련도가 낮아 제외

특히 「AI 독립도 스코어」와 「Claude가 바라본 이해 격차 (Understanding Gap)」라는 두 섹션이 과제 ①에 대한 직접적인 해답이 되고 있습니다.

AI 독립도 스코어는 세션 이력을 분석하여 「그날 얼마나 스스로 생각했는가」를 수치화한 것입니다. 스코어가 낮은 날은 「AI에게 통째로 맡겨버린 날」임을 자각할 수 있습니다.

이해 격차는 세션 이력으로부터 「자신이 이해하지 못하고 있는 것 같은 부분」을 매일 추출해 주는 섹션입니다. 지식의 빈틈이 가시화되면 다음에 무엇을 조사해야 할지가 명확해집니다.

시도해 보니 어떻게 변했는가

가장 변한 점은 「오늘 얼마나 AI에 의존했는가」가 매일 수치로 보이게 되었다는 것입니다.

이전에는 AI를 사용하여 해결한 것에 대해, 스스로 해결하고 이해했다고 착각하는 경우가 자주 있었습니다. 지금은 리포트를 보면 그날의 학습 · 진척 · AI 의존도를 한눈에 확인할 수 있습니다. AI 독립도 스코어가 낮은 날이 계속될 때는 다음 날 스스로 생각하는 시간을 의식적으로 늘리려고 노력하고 있습니다.

또한, 세션 이력 분석을 통해 「Claude가 바라본 이해 격차」로서 자신이 어디에서 막혔는지, 어떤 개념이 모호한 상태로 남아 있었는지가 매일 가시화됩니다. 스스로는 알아채기 어려운 능력의 빈틈이 AI의 관점에서 정리되어 나오는 것은 매우 유용합니다.

학습의 정착 측면에서도 변화가 있었습니다. 저녁 체크인(Check-in) 시에 배운 내용을 dailyLearned.md에 직접 써 내려가는 작업이 있으며, 다음 날 아침에는 그 내용이 퀴즈로 출제됩니다. 「과연 그렇구나」 하고 넘어가며 끝낼 수 없는 구조로 되어 있어, 이해가 얕은 상태로 다음 단계로 넘어가는 일이 줄었습니다.

이러한 변화가 쌓이면서 AI를 대하는 방식이 조금씩 변하고 있다는 실감이 듭니다.

요약

지난 1년간 AI와 함께 일하면서 신경 쓰였던 것은 「AI에 너무 의존해서 나 자신의 기술력이 오르지 않는 것은 아닐까」 하는 불안함이었습니다.

대화 규칙 [A-*]는 AI와의 상호작용 속에서 생각하는 습관을 기르기 위한 장치입니다. 일일 리포트와 에이전트 [B]는 그날의 학습을 기록 · 가시화하여 정착시키기 위한 장치입니다. 둘 다 「AI를 사용하면서도 AI에 대한 의존을 줄인다」는 구조로 되어 있습니다.

이전에는 에러가 발생하면 바로 AI에게 던져버렸지만, 지금은 일단 스스로 가설을 세운 뒤에 질문하게 되었습니다. 모르는 것이 있으면 일단 AI에게 던져서 알려달라고 하고 이해했다고 착각하곤 했지만, 지금은 사람(AI)에게 전달할 수 있을 때까지 스스로 소화하게 되었습니다. 아직 사용하기 시작한 지 얼마 되지 않아 극적인 변화라고 단정 지을 수는 없지만, 「AI의 부하」였던 상태에서 조금씩 「AI를 잘 활용하는 매니저」에 가까워지고 있다는 느낌이 듭니다. 비슷한 고민을 가진 분들에게 조금이나마 참고가 된다면 기쁘겠습니다.