본부 개발자 앞에서 Claude Code를 발표했다

어제 본부 개발자 대상으로 Claude Code 발표를 했다. 나 포함 세 명이 나눠서 진행했는데, 앞쪽은 왜 Claude Code를 골랐는지, 에이전트 코딩이 지금 어디까지 왔는지, 하네스 엔지니어링이 뭔지를 다뤘고, 내 파트는 실제 사용 사례였다.

발표를 준비하면서 제일 많이 생각한 건 사례 자체보다 "이걸 어떤 톤으로 말해야 하나"였다. 본부 인원들이 AI에게 코드를 맡기는 걸 어떻게 바라보는지 모른다. 긍정적일 수도 있고, 불안하게 볼 수도 있다. 그래서 발표 톤을 잡을 때 나름 신경 쓴 지점이 있다.

개발

집에서는 코드를 100% AI에게 맡기고 있다. 혼자 하는 작업이니 부담이 없다. 공부하거나 외부에 공개할 때만 코드를 직접 본다.

실무는 다르다. 잘못된 코드가 올라가면 내가 책임져야 한다. 그래서 발표에서는 이 차이를 일부러 강조했다.

AI에게 코드를 맡기되, 방치하지 않는다. 커밋 전에 diff를 꼼꼼하게 보고, 변수명이나 함수명이 스타일에 안 맞으면 바로 개입해서 바꾼다. 코드 구조가 마음에 안 들면 거침없이 방향을 틀게 한다.

처음부터 큰 일을 맡긴 건 아니다. 한 달 반 전쯤, 작은 개발 작업부터 시작했다. 괜찮겠다 싶으면 범위를 넓혔고, 지금은 대형 콘텐츠 개발까지 진행 중이다.

발표를 준비하면서 이 흐름을 돌아보니, 결국 감각의 문제였다. AI에게 코드를 맡긴다는 건 "코딩을 안 한다"가 아니라 "코딩의 형태가 바뀐다"에 가까웠다. 직접 타이핑하는 대신 방향을 잡아주고, 결과를 판별하고, 개입 시점을 고른다. 그게 지금 내가 느끼는 에이전트 코딩이다.

이슈트래킹

이슈 하나가 지라에 올라오면, 보통 백트레이스 같은 수집 사이트에 가서 관련 로그를 직접 찾는다. 필터 걸고, 검색하고, 유사 사례 비교하고. 시간이 꽤 든다.

이걸 스킬로 만들었다. 지라에 올라온 정보를 복붙하면 Claude가 내용을 파악하고 필터를 결정해서 CLI로 수집 사이트를 조회한다. 유사 사례까지 같이 보고해준다. URL이든 이슈 본문이든 붙여넣고 기다리면 끝이다.

이 사례를 발표에 넣은 건, 작업이 병렬로 돌아간다는 점 때문이다. 내가 다른 일을 하고 있는 동안 Claude가 이슈를 파고 있다. 이슈 파악을 위해 하던 일을 멈출 필요가 없다.

코드를 맡기는 사례만 보여주면 "코딩 대신 해주는 도구"라는 인상에 머물 수 있다. 코딩 바깥에서도 에이전트가 시간을 벌어준다는 걸 같이 보여주고 싶었다.

기획서를 작업 체크리스트로

나는 원래 개발할 때 기획서를 읽으면서 직접 체크리스트를 만든다. 뭘 구현해야 하는지, 어떤 순서로 갈지를 정리해두고 하나씩 지우는 식이다.

이걸 Claude에게 넘겨봤다.

처음 만든 버전(v1)은 기획서를 그냥 던져서 체크리스트를 뽑게 했다. 결과가 나쁘진 않았다. 오히려 내가 수작업으로 만들 때보다 항목이 3배 가까이 나왔다. 꼼꼼한 건 맞는데, 누락도 있었다.

v2에서는 기획서를 바로 체크리스트로 바꾸지 않고, 원문을 먼저 분해하고 그룹화하는 단계를 넣었다. 체크리스트가 v1보다 2배쯤 더 촘촘해졌다. 대신 새로운 문제가 생겼다. 기획서에서 명확히 정해지지 않은 회색영역을 Claude가 판단하지 못했다. "이것도 해야 하나?" 싶은 항목이 잔뜩 생겨서 리스트가 불필요하게 길어졌다.

발표 범위에는 안 들어갔지만, 오늘 v3를 만들었다. 기획서를 분석하기 전에 나한테 먼저 인터뷰를 한다. 회색영역에 대해 "이건 넣을 건가요, 뺄 건가요"를 물어보고, 그 답을 기반으로 체크리스트를 만든다.

체크리스트는 마크다운 파일로 나온다. 개발할 때는 Claude와 이 파일을 같이 보면서 "오늘은 이거 만들자" 하는 식으로 진행한다.

한계는 있다. 기획서와 실제 코드 상황은 다르다. 기획서에서는 깔끔하게 분리된 기능이 코드에서는 서로 엮여 있을 수 있고, 기획서에 없는 기술적 제약이 있을 수도 있다. 체크리스트만 믿고 개발하면 안 된다.

LSP

실 프로젝트를 대상으로 LSP가 얼마나 효율적인지 직접 테스트해본 사례도 넣었다. 이건 이전에 글로 정리해둔 게 있다.

궁금하면 여기에 자세히 썼다: Claude Code의 LSP는 토큰을 줄여줄까

"남들이 좋다고 하니까 쓴다"가 아니라 직접 검증해보는 태도를 보여주고 싶었다. 도구가 실제로 어떤 차이를 만드는지는 직접 돌려봐야 안다.

insights

Claude Code에는 /insights라는 명령어가 있다. 그동안의 대화를 분석해서 사용 패턴을 요약하고 평가해준다.

내 사용 사례를 정리해서 보여주기 좋았고, 본부 인원들이 직접 돌려봤으면 하는 마음도 있었다. Claude Code를 쓰기 시작하면 자기 나름의 패턴이 생기는데, insights를 돌려보면 그게 어떤 모양인지 한눈에 보인다. 자기 사용 방식을 돌아보는 데 꽤 쓸만하다.

발표를 준비하고 나서

발표 준비가 나한테도 정리가 됐다. 평소에 그냥 쓰고 있던 걸 남한테 설명하려고 꺼내놓으니까, 내가 왜 이렇게 쓰고 있는지가 선명해졌다.

에이전트한테 일을 맡기는 건, 처음부터 크게 믿고 시작한 게 아니었다. 작은 일부터 맡기면서 감을 잡았고, 지금도 맡기고 나서 확인하는 루프는 빠지지 않는다. 그게 없으면 실무에서는 못 쓴다.

발표가 끝나고 메신저로 Claude Code 설정법을 물어보는 사람이 몇 있었다. 직접 깔아서 써보겠다는 뜻이니까, 일단은 전달이 된 것 같다.