Claude를 PM·멘토로 삼아 독학으로 백엔드 개발을 시작한 이야기

주기: 이 기사는 AI(Claude)와 함께 작성했습니다. 체험·경험은 모두 필자 자신의 것입니다.

저는 SIer에서 시스템 엔지니어로 일하고 있습니다. 유지보수 프로젝트의 서브 리더로서 고객 협상이나 PJ(Project) 관리와 같은 PM(Project Manager)적인 업무를 담당해 왔습니다.

하지만 마음 한구석에는 계속 걸리는 것이 있었습니다.

"역시 엔지니어로서 무언가를 만들고 싶다. 코드를 쓰고 싶다."

코드를 작성할 기회가 거의 없고, 트러블슈팅(Troubleshooting)이나 Excel, PowerPoint로 문서를 만드는 업무에 익숙해지는 한편, "소프트웨어 엔지니어가 되고 싶다"는 마음은 점점 강해졌습니다.

그래서 마음을 다잡고, 가능한 날에는 매일 1시간씩 독학으로 백엔드(Backend) 개발 학습을 시작했습니다. 그 과정에서 AI를 PM이자 멘토(Mentor)로 활용하는 스타일을 시도해 보고 있기에, 그 이야기를 써보려 합니다.

• Java 24 / Spring Boot 4.0.5
• PostgreSQL 17.9
• IntelliJ IDEA Community
• Claude (Anthropic)

독학의 가장 큰 벽은 "무엇부터 손을 대야 할지 모르겠다"는 점이라고 생각합니다.

기술 서적을 읽어도, 튜토리얼(Tutorial)을 따라 해도, "그래서 실제로 무엇을 만들어야 하지?"라는 상황에 빠지기 쉽습니다. 실무 경험이 없기 때문에 어떤 태스크(Task)를 어떤 순서로 진행해야 하는지에 대한 감각이 없습니다.

지금까지 몇 번이나 "좋아, 오늘부터 프로그래밍을 하자!"라고 생각했다가 좌절했었는지...

그래서 Claude에게 상담했더니, WBS(Work Breakdown Structure)를 만들어 달라는 아이디어가 나왔습니다.

・도서 관리 앱 (포트폴리오용)
・Java / Spring Boot / PostgreSQL
・1일 1시간・주 5일 페이스
...

이 조건을 전달하자, 페이즈(Phase)별로 세부 태스크로 분해된 WBS가 나왔습니다. 또한 그에 이르게 된 실무적인 판단 배경까지 알려주었습니다.

WBS를 손에 넣었다면, 다음으로는 데일리 스탠드업(Daily Stand-up)을 제안받았습니다.

매일 3가지를 보고합니다.

• 어제 한 일
• 오늘 할 일
• 막혀 있는 부분

실무의 애자일(Agile) 개발과 똑같습니다. 처음에는 "AI에게 보고한다는 게 뭐지?"라고 생각했지만, 해보니 꽤 좋았습니다.

보고함으로써 자신의 이해를 언어화하는 훈련이 된다.

"Controller란 무엇인가", "왜 계층을 분리하는가", "왜 Repository를 인터페이스(Interface)로 만드는가" 등, 막연히 코드만 작성하고 있으면 지나쳐 버릴 개념들을 PM에게 설명하기 위해 자신의 언어로 정리해야 합니다.

이 점이 독학하는 데 있어 꽤 도움이 되었습니다.

처음에 이렇게 부탁했습니다.

코드는 스스로 찾아보며 작성하겠습니다. 정답을 알려주지 마세요. 제가 이해하고 있는지 확인하고 싶을 때는 PM으로서 심도 있게 질문해 주세요.

이것이 학습 효율에 좋은 영향을 주었습니다.

예를 들어, 다음과 같은 대화가 있었습니다.

나: @PutMapping 메서드를 만들었습니다.

Claude (PM): 코드를 보여주세요.

--코드를 붙여넣음--

Claude: 아깝습니다. PUT은 업데이트이므로, existingBook = book이라고 하면 어떤 일이 발생할까요?

나: ......아, 참조가 덮어씌워지기만 하고, id가 사라질지도?

Claude: 정답입니다. DB에서 가져온 객체의 각 필드를 세팅하는 것이 올바릅니다. 어떻게 수정하시겠습니까?

정답을 받지 않고 스스로 깨닫는 체험은 몇 번을 해도 기억에 남습니다. (이것은 지금까지 4년간의 SE 업무 경험을 통해 알고 있던 사실입니다.)

한편으로 "30분 동안 찾아보고 모르면 질문한다"라는 규칙도 세웠습니다. 계속 막혀 있는 것은 비효율적이므로 완급 조절을 하고 있습니다.

비밀번호를 소스 코드에 직접 쓰는 것은 위험하다는 것을 알고 있었지만, .env 파일을 어떻게 환경 변수(Environment Variable)로 읽어오는지 알 수 없었습니다.

IntelliJ에서는 EnvFile 플러그인을 설치하여 실행 구성(Run Configuration)에 .env 파일을 연결해야 합니다. 플러그인을 설치하는 것만으로는 작동하지 않는다는 점이 함정이었습니다.

public interface BookRepository extends JpaRepository<Book, Integer> {
}

"왜 내용을 쓰지 않는데 동작하는 거지?"라는 의문이 생겼습니다.

정답은 "Spring이 BookRepository의 구현 클래스(Implementation Class)를 기동 시에 자동으로 생성해 주기 때문"입니다. 인터페이스로 만듦으로써 Spring이 관리 하에 두고 구현을 주입(Injection)할 수 있게 됩니다.

이것은 Controller를 실제로 만들어서 @Autowired로 사용하기 시작했을 때, 조금 이미지가 잡혔습니다. 개념의 이해는 손을 움직인 후에 따라온다는 경험이었습니다.

(다만 이것은 아직 완전히 납득되지 않았기에 앞으로 진행하면서 이해를 깊게 하고 싶습니다..)

PostgreSQL의 테이블은 기본적으로 생성자(postgres 슈퍼유저)만이 액세스할 수 있습니다. 앱용 사용자에게는 명시적으로 권한 부여(GRANT)가 필요합니다.

GRANT SELECT, INSERT, UPDATE, DELETE ON books TO appuser;
GRANT USAGE, SELECT ON SEQUENCE books_id_seq TO appuser;

두 번째 줄의 SEQUENCE에 대한 권한을 잊으면, INSERT 시에 에러가 발생합니다. 이것도 실제로 500 에러가 발생해서 그 자리에서 배웠습니다.

현재는 P2(기본 CRUD API)가 완료되었고, P3(API 품질 향상)에 들어간 상태입니다.

향후 할 일:

• Service 클래스 도입
• 유효성 검사 (Validation, @Valid)
• 예외 처리 정비 (@RestControllerAdvice)
• 테스트 코드 (JUnit / Mockito)
• Docker화
• Spring Security (JWT 인증)
• GitHub Actions (CI/CD)

GitHub는 여기 있습니다 (현재 진행 중):

AI를 PM으로 삼는 장점

• 태스크가 명확해짐 (WBS가 있음)
• 진척 상황을 언어화하는 습관이 생김 (스탠드업)
• 막혔을 때 벽치기(Wall-hitting, 아이디어 브레인스토밍) 상대가 되어줌
• 코드 리뷰를 받을 수 있음
• "왜?"를 함께 고민해 줌

주의하고 있는 점

• 정답을 너무 많이 얻지 않기 (스스로 생각하는 시간을 확보함)
• 인터넷 정보원의 날짜를 반드시 확인하기 (정보로서 낡지 않았는지 확인함)
• "어찌어찌 동작했다"로 끝내지 않고, 구조를 이해한 뒤에 다음으로 넘어가기 (다만 처음부터 끝까지 하나씩 모두 이해하는 것은 무리이므로 너무 집착하지 않도록 함)

코드를 작성하지 않는 엔지니어로 몇 년을 보냈지만, 매일 1시간씩 AI와 함께 진행함으로써 좋은 학습을 할 수 있게 되었습니다.

아직 시작한 지 얼마 되지 않았지만, "막힘 → 조사 → 이해 → 다음"의 사이클이 즐거워지고 있습니다.

또한, 실제로 이 백엔드 학습을 통해 만든 포트폴리오에 대해서도 기사로 쓸 수 있으면 좋겠다고 생각하고 있습니다.

이번 기사가, 똑같이 "코드를 쓰고 싶지만 무엇부터 시작해야 할지 모르겠다", "단순히 코딩만 하는 것이 아니라, 제대로 이해하기 위해 AI를 사용하고 싶다"는 분들에게 참고가 된다면 기쁘겠습니다.

지금은 학습을 더욱 가속화하기 위해, Claude Code에도 비슷한 역할을 맡기며 진행하고 있습니다.
다음번에는 실제로 백엔드 학습을 통해 만든 포트폴리오에 대해서도 기사로 쓸 수 있으면 좋겠다고 생각합니다 (^^)