AI가 쓴 코드 다들 어떻게 리뷰하고 계신가요?

📌 자유게시판
1

요즘 AI를 가지고 작업을 거의 하고 있는데..
다들 AI가 만든 코드에 대한 리뷰는 어떻게 하고 계신가요?

AI가 작성한 코드가 너무 많으면 최종 동작 단으로만 확인하고 push하는 분들이 좀 계신 것 같아요..
그래서 코드를 보면.. 이미 있는 기능에 대한 append 코드들도 있고.. ㅠㅠ
push하신 분은 잘 동작하니까 올리신 것 같은데.. 중복 기능이라 참..

아무튼 그래서 저희는 AI가 코드에 대한 리뷰를 할 수 있게 파이프라인을 만들어 두었는데
이게 웃긴게 AI가 리뷰하면 방어코드를 작성하라고 하고 그것에 대한 리뷰를 또 부탁하면
그 방어코드에 대한 방어코드를 작성하라고하고.. ㅋㅋㅋㅋㅋㅋ 이런 동작에 대해서 열심히 튜닝하고 있습니다.

저는 AI가 너무 큰 코드를 작성하기 전에 짧게 짧게 기능을 나누어서 내가 설계에 대해서 모르는게 없을 때까지 물어보고 지나가려고 노력하고 있습니다.

여러분들의 팀에선 어떻게 하고 계신가요?

3개의 좋아요
2

저도 바이브 코딩을 적극적으로 활용하고 있어서 경험을 조금 나누자면,
AI가 코드를 수정했을 때는 해당 단위의 모든 소스코드를 아이체크로 꼼꼼히 훑어봅니다. 100% 완벽하게 파악할 수는 없지만, AI가 방향성을 완전히 잃고 수정을 가하는 경우가 있기 때문입니다. 예전에는 이런 상황을 대부분 AI의 할루시네이션 문제로 보았지만, 요즘은 요청이 구체적이지 않아 발생하는 경우가 더 많다고 생각합니다. 그래서 저는 항상 세심하게 확인하는 편입니다.

바이브 코딩을 통해 다른 개발자와 협업할 때는, AI가 프로젝트 전체 코드에 대한 수정 권한을 가지지 않도록 합니다. 대신 적절한 인터페이스나 필수 정책을 설정해 그 범위를 벗어나지 않게 조정합니다. 테스트 역시 그 인터페이스나 정책에 따라 수행하도록 하고요. 방어 코드나 fallback 코드는 정책적으로 AI가 작성하지 못하게 지시합니다. 기능 구현의 한계로 인해 방어 코드나 fallback 코드가 반드시 필요한 경우에는 사람이 직접 작성하도록 합니다. 이런 부분까지 AI에게 맡기면 코드가 정말 난잡해지거든요.

4개의 좋아요
3

제가 생각하기에는 학습 코드 샘플이 좋지 못했던 것 같습니다.

뭐랄까 90년대의 절차식 코드로 짜는 경우가 대부분이라, 방어 코드가 끝도 없이 남발되는 것 같습니다.

제가 느끼는 “90년대의 절차식 코드” 스멜은 객체의 속성을 기본 형식으로 선언하는 것이 대표적입니다. 예를 들어, 아래의 요구에,

날짜 단위의 "기간"을 나타내는 값 자료형을 만들어줘

지피티가 생성한 코드입니다.

public struct DateRange
{
    public DateTime Start { get; }
    public DateTime End { get; }

    public DateRange(DateTime start, DateTime end)
    {
        if (end < start)
            throw new ArgumentException("종료일은 시작일보다 빠를 수 없습니다.");

        Start = start;
        End = end;
    }

    public TimeSpan Duration => End - Start;
}

추가적인 문제는 차치 하더라도, 바로 보이는 직접적인 문제는:

  • 생성자에서 예외 투척
  • 날짜 단위 문맥에서 TimeSpan 이 뭔 의미가 있나?

시스템의 커널인 도메인 설계가 이 모냥이면 여기에 의존하는 외부 레이어들에서 얼마나 많은 방어 코드가 들어갈 지 상상도 안됩니다.

그래서, 가급적 아래의 사항은 수작업으로 하는 편입니다.

  • 도메인 모델 설계
  • 시스템 유스 케이스 정의
  • 엔티티 모델 Configuration

물론 AI 와 주거니 받거니 오손도손…

여기에 기반한 아래의 노가다들은 거의 AI에게 던지는 편입니다.

  • 유닛 테스트 코드
  • CRUD 뷰
  • API 엔드 포인트
  • 유스케이스 핸들러 (예시로 한 두 개는 작성해 줌)
  • 스키마 변경 시, 기존 Row 처리를 위한 SQL

도메인 모델들에 대한 테스트 코드가 모두 작성되었기 때문에, 외부 레이어는 도메인 모델을 전적으로 신뢰할 수 있어, 방어 코드가 필요한 일은 거의 없는 것 같습니다.

결과적으로, “도메인 설계” 에 대부분의 시간이 할당되는데, 이게 또 AI의 도움을 받다 보니, 선택지가 많아져 오히려 시간이 많이 걸리는 것이 단점이라면 단점입니다.

3개의 좋아요