회사 코드 컨벤션을 안 지키는 AI, 리뷰 프로세스로 길들이기

밤 늦은 시각, 한 참여자가 실무 고민을 조심스럽게 꺼냈다. "혹시 저는 제 회사에서 쓰는 코드 규칙들이 있는데 ,, 물론 회사 코드 자체가 그렇게 좋은 코드는 아니다만 뭔가 자꾸 추론을 깊게해도 회사 코드 규칙을 전혀 안지키고 코드 복잡도가 높게 작성을 하는데,, 혹시 이런것에 대해서 고민해보신 분들도 있을까요오..."라는 질문이었다. 코드 리뷰에서 "왜 이렇게 짰냐고 많이들 말씀하시죠 ㅠ"라는 지적을 자주 받는다는 실무 애로도 함께였다.

규칙을 정형화할지, 정보로 주입할지

먼저 나온 답은 자동화였다. "규칙이 단순 정형화 가능하다면 린팅이나 포매팅같은 강제 규격화 작업을 사용하시는게 좋을 것 같고"라는 제안에 이어 "설계 레벨이라면 어떤건지에 따라 생각해봐야 할 것 같긴 해요"라는 단서가 붙었다. 이 참여자는 이후에도 "그 규칙을 어기고 복잡도가 높아진 케이스에 따라 도입해볼 만한 해결책이 다를 것 같은데"라며 케이스별 접근을 강조했고, "정형화하기 어려운 규칙이라면 잘 된 코드/안 된 코드 예시를 같이 주거나, 자주 어기는 패턴을 명시해두는 것도 방법일 것 같고요."라고 구체화했다. 고민을 꺼낸 참여자는 "백엔드는 구현체에서 굳이 익셉션 처리를 너무 잦게 한다던지 ㅠ"라는 실제 사례를 덧붙이며 "이런걸 하나씩 다 정해서 한번에 알려주는게 좋겠군요,,!"라고 정리했다.

대화는 리뷰 데이터를 축적하는 방법으로 이어졌다. "리뷰하시다 보면 잘못된 케이스, 잘 된 케이스를 판단하게 되잖아요"라는 말과 함께 "잘 된 케이스는 저장만 해두고 잘못된 케이스는 그거랑 함께 어떻게 개선해야 하는지를 저장해두고" "어느 정도 틀이 잡힌다 싶으면 스킬이나 훅처럼 그 정보를 불러올 수 있는 형태로 AI에게 넘겨줄 수도 있어요"라는 구체적인 방법론이 제시됐다. 다른 참여자는 여기에 "code convention. adr. decision 딱 세개만 회사 코드들 두고 자유롭게 리포트 쓰라해서 지침에 넣으면 원하는 방향에 맞을것 같습니다"라고 보탰고, "신입사원 가르치듯 문서만들면 웬만해선 그런 룰에어긋나는 행동들은 안할 지능들은 된것같슴당"이라며 신입 온보딩에 비유했다. 또 다른 참여자는 "PR이랑 코드리뷰 긁어서 스킬 만들면 편할거에요"라는 실용적인 제안을 더했다.

토론의 결론에 가까운 조언은 억제가 아니라 주입이었다. "팁을 드리자면 AI의 행동을 억제하려고 하지 말고 AI가 회사 룰 알 수 있게 정보 주입, 다 끝난 작업물 자체를 리뷰 정도만 해도 좋을 것 같아요"라는 말과 함께 "행동을 억제하려고 들면 역효과나 성능 저하가 나기 쉬워서"라는 이유가 덧붙었다. 고민을 꺼낸 참여자는 "감사합니다.. ! 회사 코드를 스킬화 시키는 작업을 좀 해봐야겠어요"라며 대화를 마무리했다.

약 25분에 걸쳐 이어진 이 대화는 AI가 규칙을 어기는 문제를 금지 명령이 아니라 컨텍스트 설계의 문제로 재구성했다는 점에서 의미가 있다. 정형화 가능한 규칙은 린팅·CI로 강제하고, 정형화하기 어려운 관습은 좋은/나쁜 사례를 모아 스킬이나 훅으로 상시 주입하는 이중 구조가 이 방의 공통된 해법으로 수렴했다. 실무에서 회사 코드베이스를 AI에게 학습시키는 작업이 점점 문서화·스킬화 단계로 넘어가고 있다는 신호로 읽힌다.