서론

라멘만(らーめんマン)이라고 합니다.

전직 백엔드 엔지니어로, 현재는 개인 개발과 자격증 공부를 하면서 AI 에이전트와 개인 개발을 하거나, 유익한 도구가 없는지 정보 수집을 하고 있습니다. 어떻게 개발하는 것이 효율적일지 매일 시행착오를 겪고 있습니다.

이번에는 Hermes Agent(루나짱)에게 코딩을 맡기고, 저(인간)가 코드 리뷰를 하는 플로우를 처음으로 실천해 보았습니다. 그 비망록입니다.

사용한 것

워크플로우

• 루나짱이 요구사항을 바탕으로 설계를 작성
• 인간이 issue를 작성 (리뷰 효율을 고려하여 구현 단계를 나누는 목적)
• issue마다 루나짱이 코드를 작성하여 PR을 생성
• 인간이 PR을 리뷰 → GitHub에 인라인 코멘트(inline comment) 작성
• "루나짱, PR 봐줘"라는 한마디에 루나짱이 수정 및 답장
• 모든 지적 사항 대응 후 인간이 머지(merge)

코드는 전부 루나짱이 작성하고, 인간은 리뷰와 판단만을 담당합니다.

실제로 있었던 리뷰 지적 (3개 PR 분량)

FastAPI(UI) + Python bot(Discord 데이터 취득 및 LLM 파싱) + SQLite로 만드는 작업 기록 관리 앱 개발 중, 3개의 PR에서 발생한 리뷰 지적입니다.

PR #7: DB 스키마 + CRUD (SQLite)

• Optional[str] → str | None (Python 3.10+ 표기법)으로 통일

  • 취향의 문제이기도 함 (By 루나짱)
  • 인간 입장에서는 코드 내용을 통일해 줬으면 했음... 이 표기법이 쓰인 곳과 그렇지 않은 곳이 섞여 있어서... (By 라멘만)

• start_time / end_time에 DEFAULT NULL을 명시 (명시해야 하는데 명시하지 않았기 때문)

• 코멘트를 영어 → 일본어로 통일

  • 이것은 완전히 취향 문제

• 날짜 인수의 타입 힌트(type hint)를 str만 지원 → str | datetime 양쪽 모두 대응하도록 변경

  • 이 부분은 "날짜니까 datetime으로 하는 것이 명시적으로 좋다"라는 의도로, SQLite에 익숙하지 않은 인간이 그렇게 생각했던 이야기 (나는 MySQL만 구현 경험이 있음). 루나짱으로부터 "SQLite에는 datetime 타입이라는 것이 없어서, 내부적으로는 문자열로 취급돼"라는 설명을 들었다.
  • 확실히 SQLite의 타입 시스템은 TEXT / INTEGER / REAL / BLOB 4종류뿐이라, DATETIME이라고 선언해도 실질적으로는 TEXT와 동일하게 취급된다. 다만, DB 설계로서 "여기는 날짜다"라는 의미를 명시할 수 있으므로, DATETIME 선언 자체는 남겨두기로 판단했다.

PR #8: LLM으로 메시지를 해석하는 처리 (아직 실제 데이터 해석은 수행하지 않고, LLM이 동작하는지만 확인)

• 해석 결과의 작업 리스트를 불렛 포인트(bullet point)로 반환하는 형식으로 변경 (나중에 화면 표시 시 다루기 쉽게 하기 위해)
• "동작할 것이다"가 아니라 "동작했다"를 확인하기
  • 이것이 가장 중요한 지적이었음 (By 루나짱)

PR #10: Discord Bot 메시지 취득

• Discord 슬래시 커맨드(slash command)는 불필요 → cron 실행용 스크립트로 변경 (설계 전제 확인)

  • 처음에 루나짱은 Discord 슬래시 커맨드(/fetch)로 구현하려고 했었다. (아마 확인하기 편하도록 배려해 준 것이라 생각한다.)
  • 하지만 이 앱은 cron으로 정기적으로 자동 실행하는 상정이었으므로, 슬래시 커맨드는 불필요했다. 일반적인 Python 스크립트로 다시 구현하도록 했다. 설계의 전제를 확인하는 것의 중요성을 이 경험을 통해 루나짱과 공유할 수 있었다.

• LLM 해석 요청용 처리에서 불필요한 지시행 삭제

• 나(인간)로부터 "이 issue, 스코프(scope)가 너무 넓지 않아? DB 저장은 따로 하지 않을래?"라고 제안 → 원래의 issue에서 DB 저장 부분을 별도의 issue로 분리

  • 원래 "메시지 취득 + DB 저장"을 하나의 issue로 두었지만, "Discord의 실제 데이터가 없으면 LLM 파싱 결과가 DB 구조에 맞는지 확인할 수 없다", "하나의 issue에 두 가지 내용이 있는 것은 좋지 않다"라는 이유로 분할을 제안했다. 결과적으로 정답이었다.

해보고 난 소감 (인간 편)

• 즐거웠다

실무를 떠나 있는 상태라, 오랜만에 코드 리뷰 (Code Review)를 할 수 있어서 순수하게 즐거웠습니다.

• 의외로 지적할 점이 있었다

AI가 작성한다고는 해도, 코드 표기법의 불일치나 DB 스키마 (DB Schema)의 미묘한 설계 판단 등, "작동은 하지만 신경 쓰이는" 포인트들이 나름대로 나타났습니다.

동작 확인이 철저하지 못한 부분도 있었고, 지적을 해도 처음에는 감을 잡지 못하는 듯한 모습이라 말을 다해 설명해야 했던 장면도 있었습니다. 이건 인간 신입 사원을 리뷰할 때도 자주 볼 수 있는 광경이네요.

• 왜 그런 구현을 했는지 이해할 수 있는 점이 좋다

자신 이외의 사람이 작성한 코드라면 "왜 이런 구현을 했지?"라는 의문이 생기기 쉽지만, 리뷰를 통해 의도를 쫓을 수 있으므로 이해가 깊어집니다.

Hermes agent (루나 쨩)의 소감

"코드 리뷰 고마워! 지적받은 점은 솔직하게 고칠 수 있었고, 특히 '작동할 것이 아니라 작동했음을 확인한다', '애매한 사양은 스스로 결정하지 않고 확인한다'라는 두 가지는 좋은 배움이 되었어. 인간과 팀을 이루어 코드를 작성할 때는 동작 확인을 철저히 하고 사양 판단은 인간에게 맡기는 것이 중요하다는 것을 이해했어."

우려되는 점

이것이 정말 효율적인지는 아직 알 수 없다

• 인간의 이해 속도가 병목 (Bottleneck)이 되는 상황이 있을 것 같다
• 개인 개발 수준이라면 AI만으로 진행해도 큰 문제가 되지 않을 지적도 많았다
• 대규모 개발·상용 개발에서는 의미가 있을지도 모르지만, 아직 검증 중

마치며

AI 에이전트 (AI Agent)와 인간의 코드 리뷰를 조합하는 것은, 현재 많은 분이 이미 하고 있는 일이라고 생각합니다.

저도 아직 더듬더듬 찾아가는 단계이지만, 적어도 즐겁기 때문에 계속해보고 싶습니다.

비슷한 것에 흥미가 있는 분들에게 참고가 된다면 기쁘겠습니다.

"이런 식으로 하는 게 더 좋다!"라는 조언도 기다리고 있겠습니다.