• AI에게 코드를 작성하게 하기 시작한 사람
• 바이브 코딩 (Vibe Coding)에 관심이 있는 사람
• PR 리뷰 용어가 아직 조금 어렵게 느껴지는 사람
• 후배가 용어를 물어봤을 때 설명하기 곤란했던 적이 있는 사람

AI에게 코드를 작성하게 되면서, 코드를 쓰는 것보다 더 어려운 일이 있다는 것을 깨달았다.

그것은 바로, 무엇을 어떻게 고쳐주길 바라는지를 말로 표현하는 것이었다.

평소 업무를 하다 보면, 선배나 동료로부터 무심코 이런 말들이 날아온다.

「LGTM입니다」

「Approve」

「이건 DRY를 사용하는 게 좋겠어」

「이 PR, Draft로 올렸습니다」

최근에는 AI에게도 비슷한 말로 지시한다.

「DRY를 의식해서 구현해줘」

「KISS 원칙으로 심플하게 만들어줘」

「YAGNI이므로, 지금 필요한 기능만 만들어줘」

하지만 솔직히 말해서, 나는 이 말들을 모두 정확하게 설명할 수 있는 것은 아니었다.

의미를 대충 이해한 채, 분위기에 맞춰 고개만 끄덕이고 있었다.

그리고 AI에게,

이 구현을 DRY하게 만들어줘

라고 지시한 뒤,

「구체적으로 어떤 중복을 없애야 하나요?」

라고 질문을 받는다면, 제대로 대답할 자신도 없다.

그날을 대비하여, 여기에 기록한다.

업무나 PR에서 자주 듣지만, 막상 설명하려고 하면 조금 곤란한 엔지니어 용어를 의미, 사용 예시, AI 지시 예시와 함께 정리해 보았다.

엔지니어 용어를 사용하면 AI에게 의도를 전달하기 쉬워진다.

단, 용어를 한마디 덧붙이는 것만으로는 아직 지시가 모호하다.

AI에 대한 지시는 다음과 같은 형식을 갖추면 구체적이 된다.

원칙 : 무엇을 의식할 것인가
대상 : 어떤 코드·기능인가
조건 : 어떻게 해주길 원하는가
...

예를 들어, 단순히 「DRY하게」라고 말하는 대신,

기존의 검증 (Validation) 함수를 재사용해 주세요.
동일한 처리를 새로 중복 구현하지 마세요.
단, 공통화로 인해 코드가 복잡해지는 경우에는
...

라고 전달한다.

AI 지시를 5개 항목으로 분해하는 템플릿

LGTM은 Looks Good To Me의 약자다.

「내가 본 범위 내에서는 문제없어 보입니다」라는 의미로 사용된다.

LGTM입니다!

라고 코멘트가 달렸다면, 기본적으로는 긍정적인 리뷰다.

단, LGTM은 GitHub의 공식적인 승인(Approve) 조작이 아니다.

GitHub Docs에서 설명하는 리뷰 상태는 Comment, Approve, Request changes 세 가지이다. GitHub Docs: Pull Request의 리뷰

따라서 이 글에서는 LGTM을 「코멘트로서, 내가 본 범위에서는 문제없을 것 같다」라는 표현으로 취급한다.

팀에 따라서는 「Approve와 같은 의미」로 사용되기도 하므로, 최종적으로는 팀의 규칙을 확인하는 것이 안전하다.

한 차례 확인했습니다. LGTM입니다!

AI에게 단순히 「LGTM이라고 말하게」 하는 것이 아니라, 근거를 제시하도록 한다.

이 PR을 리뷰해 주세요.
LGTM이라고 단정하기 전에, 다음을 나누어서 제시해 주세요.
- 문제가 없어 보이는 점
...

Approve는 PR의 변경 내용을 승인하는 것이다.

GitHub의 리뷰에는 Comment, Approve, Request changes 세 가지 리뷰 상태가 있다. Comment는 승인도 수정 요구도 하지 않는 피드백, Approve는 변경 승인, Request changes는 머지(Merge) 전에 대응해야 할 수정 요구이다. GitHub Docs: Pull Request의 리뷰

• Comment: 코멘트하기
• Approve: 변경을 승인하기
• Request changes: 수정을 요청하기

즉,

• LGTM: 코멘트로서의 「좋아 보인다」
• Approve: GitHub상의 공식적인 승인

이라는 차이가 있다.

내용에 문제가 없어 보이므로 Approve하겠습니다.

AI에게 직접 Approve하게 하는 것이 아니라, Approve해도 좋을지 판단할 재료를 내놓게 한다.

이 PR을 Approve해도 좋을지 확인해 주세요.
- 머지를 중단해야 할 문제
- 가능하다면 고치고 싶은 문제
...

Draft PR은 아직 리뷰 준비가 되지 않은 PR이다. GitHub에서는 Draft 상태 동안에는 머지할 수 없으며, 코드 오너(Code Owner)에게 리뷰 요청도 자동으로 이루어지지 않는다. 중간 과정의 공유나 구현 방침에 대한 상담에 사용할 수 있다. GitHub Docs: Pull request

이 PR, 아직 Draft 상태인데 방침만 봐주실 수 있나요?

WIP라는 말도 마찬가지로 「작업 중」이라는 의미로 사용된다.

이 PR은 Draft입니다.
완성된 코드를 한꺼번에 작성하는 것이 아니라,
먼저 다음 사항을 정리해 주세요.
...

DRY는 Don't Repeat Yourself의 약자이다.

동일한 처리나 지식을 여러 곳에 중복시키지 않는 사고방식이다. DRY의 배경과 의도는 Andy Hunt와 Dave Thomas의 저서 『The Pragmatic Programmer』의 해설에서도 확인할 수 있다. Don't Repeat Yourself - The Pragmatic Programmer

단,

"비슷한 코드를 발견하면 무엇이든 공통화한다"

라는 의미는 아니다.

이 처리, 다른 곳에도 비슷한 코드가 있습니다.
DRY하게 만들 수 있겠네요.

기존의 공통 함수를 확인하고,
동일한 처리를 새로 중복 구현하지 마세요.
공통화를 통해 가독성이 떨어진다면 무리하게 합치지 말고,
...

KISS는 일반적으로 "Keep It Simple, Stupid"의 약자로 알려져 있으며, 가능한 한 심플한 설계나 구현을 하자는 사고방식이다.

소프트웨어에서는 요구사항을 충족하는 범위 내에서 복잡성을 늘리지 않고, 이해·검증·유지보수하기 쉬운 구조를 선택하는 지침으로 사용할 수 있다. A Review of the New AVIRIS Data Processing System - JPL

KISS라는 말의 배경은 항공기 설계자 Kelly Johnson의 격언으로 공식 자료에 기록되어 있다. Kelly Johnson: Architect of Air - Lockheed Martin

그렇게까지 복잡하게 만들지 않아도 될 것 같으니, KISS하게 갑시다.

기존 구성을 크게 변경하지 말고,
불필요한 추상화나 새로운 라이브러리를 추가하지 마세요.
이번 요구사항을 충족하는 가장 심플한 구현을 제안해 주세요.

YAGNI는 You Aren't Gonna Need It의 약자이다.

"나중에 사용할지도 모르니까"라는 이유만으로, 지금 필요하지 않은 기능을 만들지 않는 사고방식이다. 필요할 때 구현한다는 사고방식은 Ron Jeffries 본인의 해설에서도 확인할 수 있다. You're NOT gonna need it! - Ron Jeffries

Martin Fowler도 YAGNI를 XP의 Simple Design과 관련된 사고방식으로 설명하고 있다. Yagni - Martin Fowler

그 기능은 아직 요구사항에 없으므로, YAGNI 원칙에 따라 이번에는 넣지 않아도 괜찮습니다.

이 PR을 종합적으로 리뷰해 주세요.
PR의 목적:
[무엇을 실현하기 위한 변경인가]
...

이번에 소개한 말들은 단순한 지식이 아니다.

AI에게 코드를 작성하게 할 때의 지시가 되며, PR을 리뷰할 때의 판단 기준이 되기도 한다.

그저 "DRY하게", "KISS하게"라고 말하는 것만으로는 AI에게도 사람에게도 의도가 전달되기 어렵다.

용어에 더해,

• 무엇을 대상으로 하는지
• 무엇을 피해야 하는지
• 어디까지 해야 하는지
• 무엇을 확인해주길 바라는지

까지 전달하는 것이 중요하다.

AI에게 코드를 작성하게 하는 시대이기에 더욱, 말의 의미를 이해하고 있는 것이 이전보다 중요해지고 있는 것일지도 모른다.

업무에 익숙해진 분들에게.

후배로부터,

"LGTM과 Approve는 무엇이 다른가요?"

"DRY는 무슨 뜻인가요?"

"YAGNI는 무엇을 만들지 말라는 건가요?"

라고 질문을 받았을 때, 당신은 즉시 설명할 수 있는가?

그리고 AI에게,

"DRY하게 구현해줘"

라고 지시했을 때, 무엇을 DRY하게 만들 것인지까지 설명할 수 있는가?

알고 있다고 생각하는 말일수록 설명하기는 어렵다.

이 기록이 미래의 자신에게 도움이 된다면 좋겠다.

여러분의 현장에서 사용되고 있는, 설명하기 어려운 엔지니어 용어가 있다면 꼭 댓글로 알려주세요.