안녕하세요, 실용주의개발입니다.
오늘은 실무경험이야기를 전달드리려고합니다. AI가 만든 PR을 리뷰하면서 요즘 실제로 하고 있는 고민을 정리하였습니다.
AI 에이전트에게 작업을 맡기면 관련 파일을 찾고, 구현하고, 테스트 코드까지 붙여서 꽤 큰 변경을 만들어 냅니다. 그런데 사람이 코드를 이해하는 속도는 거의 그대로입니다. 하루 8시간 안에 회의도 하고 기획 논의도 하고 개발도 해야 하는데, PR이 대여섯 개씩 쌓입니다.
그래서 저는 diff보다 먼저 이 작업을 만든 생각을 봅니다. 어떤 문제를 풀려고 했는지, 왜 이 구현 방법을 선택했는지, 무엇을 어떻게 검증했는지.
영상에서는 이런 내용을 다뤘습니다.
- AI 코딩 시대에 코드 리뷰가 병목이 되는 이유
- 코드보다 먼저 확인하는 작업의 논리와 검증 근거
- 좋은 PR에 반드시 있어야 할 5가지 (문제 / 접근 / 범위 / 검증 / 남은 위험)
- 위험도에 따라 리뷰 집중력을 배분하는 기준
- 리뷰어 역할의 변화, 버그를 찾는 사람에서 검증 근거를 확인하는 사람으로
- 신입·주니어 개발자가 지금 훈련해야 할 4가지
영상링크
강의와 이어지는 지점
이 영상은 결국 "AI가 만든 결과물을 어떻게 통제할 것인가"에 대한 이야기입니다.
리뷰 단계에서 증거를 요구하는 것도 방법이지만, 애초에 에이전트가 검증 가능한 결과물을 내도록 작업 환경을 설계하는 쪽이 근본적입니다. 강의에서 다루는 하네스 엔지니어링 4계층 중 피드백 계층이 정확히 이 문제를 다룹니다.
어떤 검증을 자동으로 돌릴지, 실패를 에이전트에게 어떻게 되돌려줄지, 무엇을 사람이 확인하도록 남길지를 설계하는 부분입니다. Hook을 활용해 커밋 전 검증을 강제하는 실습도 여기에 포함돼 있습니다.
영상에서 말한 "PR 본문에 검증 내용을 강제로 적게 한다"는 것도, 결국 사람 쪽 하네스를 하나 세우는 일입니다. 같은 원리를 도구와 제어 흐름 쪽으로 옮기면 에이전트 작업 자체의 품질이 올라갑니다.
영상 편하게 봐주시고 또 실용적인 소식으로 찾아뵙겠습니다.
추가적인 소식
요새 제가 어떻게하면 수강생 여러분께 도움이 될 만한 정보를 제공할 수 있을지 다방면으로 고민하고있습니다. 제가 아직 공개적으로 말씀을 드리진 않았지만 개발자로 일하고 계신분들, 개발자 지망생분들, 취준생분들에게 정말 도움이 될만한 컨텐츠 (당연히 수강생분들은 무료입니다) 를 제공하려고하니 소식 기다려주세요 🙏
그럼 오늘도 공부 화이팅입니다!!