AI 코드의 안목을 기르는 90일 훈련: 선택 이유와 실패 기록 남기기

AI가 만든 구현 두 개를 보고 하나를 고르는 순간이 있다. 한쪽은 코드가 짧고 다른 쪽은 오류를 설명하기 쉽다. 지금의 요구에는 둘 다 맞아 보인다. 이때 내가 선택의 근거를 설명하지 못하면 다음 수정에서도 취향에 기대게 된다.

나는 안목을 결과물의 장단점을 근거로 구분하고 상황에 맞는 선택을 하는 능력으로 다루려 한다. 90일은 이 능력을 완성하는 기간이라는 뜻이 아니다. 관찰, 비교, 적용을 나눠 연습하고 무엇을 놓쳤는지 돌아보기 위해 정한 기간이다. 아직 수행 결과를 측정하지 않은 계획이며 연봉이나 생산성 증가를 약속하지 않는다.

훈련할 대상은 코드 길이보다 사용자의 작업이다

Google의 코드 리뷰 안내는 설계, 기능, 복잡성, 테스트, 이름과 문서 등을 살펴보도록 한다. 개인적인 스타일 선호와 실제 수정이 필요한 문제도 구분한다. 이 항목을 훈련의 출발점으로 삼되 조직의 기준을 내 프로젝트에 그대로 복사하지는 않겠다. Google 코드 리뷰 기준

블로그의 Recent 목록을 예로 들면 날짜 내림차순 정렬이 있어도 사용자가 원하는 최근 글이 안 보일 수 있다. 처음 작성한 날과 대표 글로 공개한 날이 다른 원고가 있기 때문이다. 이 문제에서 좋은 구현은 정렬 함수가 짧은 구현보다 날짜 의미를 구별하고 화면에서 오해를 줄이는 구현이다. 요구를 제대로 읽는 일도 코드 판단의 일부다.

훈련 주제는 내가 설명할 수 있는 작은 기능으로 제한한다. 입력 검증, 목록 정렬, 실패 메시지, 파일 저장 같은 주제다. 모르는 도메인에서 코드만 보고 정확도를 평가하면 잘못된 기준을 강화할 수 있다. 이해하지 못한 부분은 공부 과제로 남기고 자신 있게 채점하지 않는다.

결정 기록에는 요구, 대안, 선택 이유, 확인 방법을 쓴다. “확장성이 좋다”라고 적었다면 어떤 변경을 예상했고 어떤 부분이 덜 바뀌는지 설명한다. 그 변경이 실제로 필요하지 않다면 지금 비용을 더 쓰는 이유도 물어야 한다. 미래를 대비한다는 표현만으로 복잡한 구조를 정당화하지 않는다.

1~30일: 좋은 예시를 읽고 예상 동작을 적는다

첫 달에는 매일 새 도구를 설치하기보다 이미 쓰는 도구의 결정 하나를 자세히 보겠다. 파일을 저장하지 않고 닫을 때 무엇을 묻는지, 검색 결과가 없을 때 어떤 정보를 남기는지, 긴 작업 중에 상태를 어떻게 표시하는지 확인한다. 감상에는 실제 화면과 입력 조건을 함께 적는다.

코드 예시는 공식 저장소나 접근 허가를 받은 프로젝트에서 고른다. 함수 하나를 읽기 전에 입력과 예상 출력을 써보고 코드를 따라가며 비교한다. 에러 경로도 포함한다. AI 설명은 보조 자료로 쓰되 원본 코드와 다르면 어느 부분이 틀렸는지 직접 확인한다. 남의 코드와 이미지를 글로 옮길 때는 라이선스와 인용 범위를 지킨다.

첫 두 주의 결과물은 기능 다섯 개의 관찰 기록이다. 다음 두 주에는 관찰한 선택을 작은 테스트로 바꿔본다. 예를 들어 잘못된 날짜를 넣었을 때 목록이 멈추는지, 해당 항목만 제외하는지, 사용자가 이유를 알 수 있는지 확인한다. 예상과 실제가 다른 지점을 학습 노트의 중심에 둔다.

관찰 시간을 길게 잡을 필요는 없다. 하루 20분을 예산으로 제안한다. 코드를 찾는 데 대부분의 시간을 썼다면 다음 날에는 같은 파일을 이어 읽는다. 예시 열 개를 채우려고 이해하지 못한 코드까지 훑는 것보다 설명할 수 있는 예시 몇 개를 만드는 쪽을 택하겠다.

31~60일: 두 구현을 같은 조건에서 비교한다

두 번째 달에는 같은 요구를 해결하는 두 구현을 비교한다. AI에게 두 안을 만들게 해도 되지만 처음에는 어느 모델이 작성했는지 숨겨놓고 평가하겠다. 모델 이름이나 코드의 긴 설명에 끌려 평가하지 않으려는 장치다. 두 안에 서로 다른 요구를 주고 결과만 비교하지 않는다.

주간 과제 하나에는 정상 입력, 경계 입력, 실패 입력을 함께 넣는다. 목록 정렬이라면 날짜가 같은 경우와 날짜가 없는 경우를 시험한다. 파일 저장이라면 이름 충돌과 권한 거부를 포함한다. 두 안을 실행하지 못했다면 문서 검토 결과라고 적고 동작을 검증했다고 쓰지 않는다.

비교문에는 내가 택한 안의 단점도 적는다. 오류를 사용자에게 상세히 보여주는 방식은 이해에 도움이 되지만 내부 경로나 비밀값을 노출할 위험이 있다. 설정 항목을 늘리면 다양한 작업을 지원하지만 문서와 테스트도 늘어난다. 좋은 선택은 조건에 따라 달라진다는 점을 구체적인 비용으로 기록한다.

평가자는 가능한 한 같은 기준표를 사용한다. 기준을 중간에 바꿨다면 이유와 적용한 날짜를 남긴다. 한 안이 마음에 든다는 이유로 그 안에 유리한 항목을 추가하면 비교가 아니다. 동료에게 검토를 부탁할 수 있으면 내 결론을 보여주기 전에 같은 입력과 요구를 제공하겠다.

주말에는 틀린 예측을 모은다. “이 변경은 테스트에 영향이 없겠다”라고 생각했는데 실패했다면 원인이 외부 상태인지 인터페이스 변경인지 살펴본다. 실수를 부끄러운 기록으로 치우지 않고 다음 주에 먼저 확인할 항목으로 바꾼다. 나중에 같은 실수를 덜 하는지가 훈련의 관찰 지표다.

61~90일: 실제 프로젝트의 작은 변경에 적용한다

세 번째 달에는 기존 시스템을 통째로 다시 만들지 않는다. 최근 불편했던 기능 하나를 골라 현재 동작, 원하는 동작, 바꾸지 않을 부분을 문서로 적는다. 다른 기능을 건드리지 않고 개선할 수 있는 범위를 정해야 선택의 결과를 비교하기 쉽다.

작업 전에 실패하는 테스트나 재현 절차를 준비한다. 구현 후에는 같은 절차로 개선 여부를 확인한다. 문서에 적은 요구가 코드와 다르면 문서를 지워 맞추지 않고 어떤 해석이 옳은지 다시 판단한다. 요구가 바뀌었다면 변경 이유를 별도로 남긴다.

AI에게 구현을 맡길 때는 완성 조건과 검사 명령을 전달한다. 테스트가 깨지면 기대값부터 바꾸지 말고 기존 계약을 확인하게 한다. 검토 범위도 명시한다. 기능을 추가하는 작업에 관계없는 이름 변경이나 전체 포맷 수정까지 섞이면 변경 이유를 추적하기 어려워진다.

마지막 주에는 90일 동안의 선택을 짧은 작업 규칙으로 정리하겠다. 날짜는 의미별로 구분한다, 쓰기 전에는 복구 범위를 확인한다, 빈 결과와 조회 실패를 구분한다 같은 규칙이다. 근거가 있는 사례를 연결하고 예외를 적는다. 특정 프레임워크 이름을 좋아한다는 취향과 작업에서 확인한 규칙을 구분한다.

Google의 리뷰 기준 문서는 완벽한 코드를 기다리는 대신 전반적인 코드 건강을 개선하는 변경을 다루는 관점을 설명한다. 작은 변경을 계속 검토하는 이 계획과 연결할 부분이다. 다만 기능·보안 결함까지 개인 취향으로 낮춰 보자는 뜻은 아니다. Google 리뷰 승인 기준

훈련이 밀렸을 때는 달력보다 남은 질문을 본다

90일 계획을 지켰다는 사실만으로 판단력이 좋아졌다고 평가하지 않겠다. 처음과 마지막에 같은 종류의 과제를 풀고 놓친 오류, 근거 없는 단정, 필요한 검토 시간을 비교한다. 코드가 익숙해진 효과를 줄이기 위해 같은 원리의 다른 예제도 함께 본다.

한 주를 쉬었다면 밀린 과제를 한꺼번에 만들 필요는 없다. 마지막으로 틀린 예측 하나를 다시 확인하고 그 주제를 이어간다. 관찰 기록이 쌓였어도 실제 선택에 사용하지 않는다면 기록 형식부터 줄인다. 내 작업에 연결되는 질문을 남기는 것이 목표다.

기존 원고의 “엔지니어 격차가 3배에서 10배가 됐다”거나 90일 뒤 격차를 닫는다는 표현은 근거가 없어 사용하지 않는다. 코드 생성 비율과 연봉 사이의 관계도 이 계획에서 증명하지 않는다. 내가 기대하는 결과는 다음 변경에서 선택 이유를 설명하고, 틀릴 수 있는 조건을 테스트로 남길 수 있는 상태다.

참고자료

• Google Engineering Practices: 코드 리뷰에서 확인할 항목
• Google Engineering Practices: 리뷰의 승인 기준