AI 코딩 툴을 사용할 때의 나의 원칙

지난 글에서는 어떤 AI 코딩 툴을 어떻게 쓰는지 공유했었습니다. 이번에는 툴을 계속 사용하면서 머리 속에 쌓인 원칙들을 적어보았습니다. 항상 이러한 생각들을 하며 툴을 사용해야 좀 더 체계적으로, 생산적인 방향으로 일이 진행되는 것 같습니다.

사분면 (Quadrants)

현재 하고 있는 일이 4개의 사분면 중 어디에 있는지 생각한다.

* 사분면 1 - 높은 임팩트 존 (High Impact Zone)
* 사분면 2 - 위험한 존 (High Danger Zone)
* 사분면 3 - 재미 있는 바이브 코딩 구역 (Full Fun Vibe Coding Zone)
* 사분면 4 - 약간 진지한 바이브 코딩 구역 ("Parents at the party" Vibe Coding Zone)

사분면 1 - 높은 임팩트 존 (언어숙련도 높음; 코드 중요도 높음)

여기서는 LLM으로 가장 큰 임팩트를 만들 수 있지만, 가장 조심해야 하는 구역.

이 코드가 프로덕션에서 실행될 것이라는 걸 잊지 말자. 좀 더 코드에 엄격하자. 기본적인 유닛 테스트와 통합 테스트를 고려하자. 여기서 생산적이면 내 메인 업무를 잘하는 것으로 이어질 수 있기에 잘 활용하되 항상 신중하게 생각하자.

사분면 2 - 위험한 존 (언어숙련도 낮음; 코드 중요도 높음)

여기서는 너무 자주 머물지 말자.

코드 리뷰를 도와줄 수 있는 인내심 있는 동료가 있다면 다행이다. 하지만 아무 이해 없이 큰 사이즈의 LLM 생성 코드를 리뷰로 맡기면 동료가 불쾌해하고 나에 대한 신뢰를 잃을 위험이 있다는 걸 잊지말자. 최소한 중간 수준의 숙련도를 얻어서 사분면 1에 최대한 가깝게 가는 방향을 모색하자.

사분면 3 - 재미 있는 바이브 코딩 구역 (언어숙련도 낮음; 코드 중요도 낮음)

여기는 무슨 일이 일어나고 있는지 전혀 모르는 상태지만, 결과를 보는 재미가 가장 많다. 최소한 원하는 출력이 무엇인지(예: UI, 데이터 시각화)는 확실하게 해야 프롬트 잘 써 결과를 얻어낼 수 있다. 코드를 제대로 이해하지 못하기 때문에 프롬프팅에 시간을 많이 낭비할 수도 있다. 그냥 바이브에 손가락을 맡기자.

사분면 4 - 약간 진지한 바이브 코딩 구역 (언어숙련도 높음; 코드 중요도 낮음)

여기도 꽤 생산적일 수 있지만 완전히 바이브 코딩은 아님. 약간 진지한 "파티에 온 부모"라고 했던 이유는 생성된 코드를 여전히 부모처럼 관리하고 이해하면서 보게 되기 때문. 아이들을 훈육하면서도 파티 바이브를 즐기고 싶어하는 부모 느낌이랄까.

LLM과 인턴

AI 코딩 도구를 전문가가 아닌 인턴처럼 대한다.

• 때로는 세밀하게 관리해야 하자. 어떤 파일과 과거 Changelist을 읽어야 작업을 할 수 있는지 구체적으로 알려준다.
• 지루하더라도 좀 해야 할 작업이 명확하게 일을 주자.
• 작업을 더 작은 덩어리로 나누자.
• 코드를 신뢰하지 말자. 의심의 눈으로 코드를 읽자.
• 코멘트나 변경하는 로직의 근거도 읽어보자.
• 때로는 LLM의 사고가 이상한 토끼 굴에 빠질 수 있다는 걸 받아들이자.
• 때로는 나보다 뛰어나고 창의적인 해결책을 만들어낼 수 있다는 걸 받아들이자.
  

Git을 효과적으로 사용하기

• 모든 코드를 작은 덩어리의 Changelist으로 분리하자.
• 리뷰를 해서 문제가 없는 부분을 잘게 나누어 커밋한다. 이렇게 하면 무슨 일이 일어나고 있는지 정리하는 데 도움이 되고, 뭐가 잘못되면 롤백하기도 쉽다.
• 일부 IDE는 LLM 결과를 내가 먼저 accept해야 하는 작은 조각으로 보여주는 UX를 가지고 있는데, 이 기능을 꼭 사용하자.
• LLM 툴 사용 안하더라도 평소에 이렇게 하자.
  
  

에너지 레벨 확인하기

• 때로는 그냥 일이 잘 안 될 때, 이해가 안되는 에러 메시지를 고치기 위해 LLM에게 계속 생성하고 "좀 잘 고쳐봐" 같이 바보 같은 프롬프팅하는 안 좋은 습관에 빠지고는 하는데, 이러한 건 LLM이 아니라 내가 토끼 굴에 빠진거다.
• 나의 에너지 레벨이 낮을 때 마치 인스타 릴즈나 유튜브 쇼츠를 아무 생각 없이 스크롤 (doom scrolling)을 하고 싶은 것과 같은 이치기에, 빨리 내가 이러한 상태에 왔다는 것을 인지하자.
• 차라리 컴퓨터를 닫고 쉬자. 커피나 차 한잔을 마시러 가고, 산책하고, 운동하러 가자. 아니면 그냥 내일 하자.
• 그리고 에너지 레벨이 돌아오면, AI 코딩 도구 없이 실제로 코드/에러 메시지를 직접 읽어보자. 때로는 답이 바로 거기에 있다.

동료들에게 말해야 하나 말아야 하나

동료들이 트리플 모니터 셋업에 AI 에이전트로 코드를 작성하는 모습을 볼 때 부끄러워해야 할지 자랑스러워해야 할지 아직 모르겠다. 한 번은 매니저가 "멋지네"라고 한마디 했는데, 진심인건지 아니면 그 때 내 코드에 대한 신뢰가 약간이라도 떨어진 건지 모르겠다만..

• 어쨌든 내 코드와 그 결과에 책임은 나한테 있다는 것을 까먹지 말자. 사람들은 내가 어떻게 거기에 도달했는지에 대해 점점 덜 신경 쓸 것이다. 결과가 좋기만 하면.
• 내가 내 인턴을 고용하더라도 그들이 만드는 결과에 나도 일부분 (아님 대부분) 책임이 있지만, LLM의 경우, 작업이 내 이름으로 나오기에 100% 내 책임이다.
• 그러니깐 좀 더 내 작업에 책임감과 자부심을 가지고, LLM 생성 코드를 꼼꼼히 리뷰를 하자. 이 책임을 동료들의 코드 리뷰어에만 전가하지 말자.

저는 앞으로는 LLM 코딩 도구를 잘 사용하는 것이 생산적인 엔지니어가 되는 데 굉장히 중요한 부분이 될 것이라고 확신합니다.

하지만 이를 위해서는 먼저 제가 좋은 엔지니어가 되어야 한다는 것을 깨달았습니다.

그렇지 않으면 LLM도 나도 엉성한 결과를 만들에 낼 것이고, 이는 결국 내 커리어뿐만 아니라 팀의 제품에도 큰 리스크가 됩니다.

제 자신한테 적용하고 있는 원칙들이 여러분들께 참고가 되었으면 좋겠네요.