AI DevEx Conference 리바이벌 공연 요약 및 감상

다음 이벤트에 참가했다.

AI 리뷰로 사람이 개입하지 않고 리뷰하는 기사를 게시했더니 찬반양론이었다.

원래 엔지니어들 사이에서 리뷰 대기 시간이 발생하는 것이 병목 현상(bottleneck)이었다.

제품 자체는 장애나 오류가 섞여 있어도 치명적이 되기 어려운 종류였다.

그 때문에 AI에게 맡겨도 문제가 없을 것 같다고 느꼈다.

AI에 맡긴 결과, PR 수가 5.5배로 늘었다.

하지만 리버트율(revert rate)은 줄었지만, 리버트 수는 4배로 늘었다.

AI 리뷰로 인해 장애도 발생했지만, 사람이 해도 장애가 나올 것 같은 느낌이었다.

구현(implementation) → 리뷰가 빨라진 만큼, 도착 전이나 요구사항 정의에 시간이 걸리게 되었다.

개발의 자동화가 진행되어 1주일에 PR이 1000개에 달할 것 같다.

PR 수가 인플레이션 되어 오면서, PR 수를 측정하는 의미가 없어지기 시작했다.

하지만 예산을 세울 경우, PR 수를 단가로 계산할 수 있다.

프롬프트 효율(prompt efficiency)을 보기 시작했다.

하나의 지시로 몇 개의 PR이 생성되도록 보았다.

한 번의 지시로 맡길 것이 되려면, 명확한 단위와 명확한 목표가 필요하다.

계획 작업의 내역은, 40%는 사전에 확인했어야 할 것, 40%는 사양이 정해져 있지 않았다는 것이었다.

만약 빠뜨린 것을 다음 계획에 반영해 나간다.

루프 엔지니어링(loop engineering)을 루틴화했다.

리뷰가 병목 현상이었는데, AI로 자동화했다.

릴리스도 AI가 자동화했다.

소수 팀을 늘리는 것 같은 생산성 향상을 목표로 했다.

그로 인해 의사결정이 빨라졌다.

같은 AI를 사용했는데, 왜 코드 품질이 다른지?

AI를 넣어도 생산성은 늘지 않았다.

리뷰가 늘어났다.

예시로는 FATController가 되어버렸다.

특히 주니어 멤버들에게 같은 지적을 하는 경우가 있었다.

Rules를 작성하여, AI의 코드 규약을 만들었다.

Rules를 만드는 방법으로는, 지금까지의 리뷰 내용을 조합하는 것이 좋다고 생각했다.

그로 인해 PR은 늘었지만, 리뷰 코멘트 수는 줄었다.