사실 나는 개발을 시작하면서 린트 설정의 중요성에 대해서 크게 느끼지 않고 개발을 해왔던 거 같다. 취준 전에는 그냥 멋 모르고 자동설정 되어 있는 린트 룰들을 써오고 취준 후에는 유지보수 하는 프로젝트들에 설정되어 있는 린트 룰들을 그렇게 중요하게 살펴보지 않고 로직 작성에 만 큰 관심이 있었던 것 같다.
이런 나에게, 1주차 때 멘토님의 발표는 나의 머리에 울림을 주었다.
"린트와 타입이 1차 하네스이다"
요즘 하도 하네스가 유행을 하여 그 수많은 md 파일을 잘 작성해서 컨트롤 하는게 하네스 인 줄 알았는데 린트와 타입이 1차 하네스 였다니..
1. 결정적이다.
사람 리뷰는 컨디션을 타고, ai 리뷰는 확률적
하지만 린터는 0.1초에 빠짐없이 잡는다.
2. 가장 싼 시점에 실행된다
수정비용 : 작성중 < 커밋 < 리뷰 < QA < 프로덕션
1차 하네스는 가장 싼 두 시점(작성중, 커밋) 에 박혀있다.
3. Ai 검증 루프의 기반이다.
ai 에이전트가 스스로 고치며 수렴하려면 '스스로 돌릴 수 있는 검사' 가 필요하다.
4. 사람의 주의력 예산을 지킨다.
기계가 잡을 걸 기계가 잡아줘야 사람의 리뷰 시간이 설계 질문에 쓰인다.
그 다음 멘토님은 사람 리뷰어의 눈을 여기 쓰라고 말씀하셨다.
1. 방어로직
이 입력이 null 이면? 네트워크가 끊기면? 두 번 연속 클릭하면?
2. 에러처리
에러가 사용자에게 어떻게 보이나? catch(e){}로 삼켜지고 있진 않나?
3. 데이터흐름
이 상태는 왜 여기 있나? 서버 데이터와 클라이언트 상태가 섞여 있진 않나?
4. 재사용
이미 있는 유틸/컴포넌트를 두고 새로 만들지 않았나? (AI 코드의 고질병)
5. 기계를 침묵시킨 자리
eslint-disable @ts-ignore as 의 이유를 묻는건 사람의 일
6. 없는 것
빠진 엣지 케이스, 빠진 테스트, 없는 코드는 어떤 도구도 지적해주지 않는다.
추가로 리뷰어는 이제 코드 컨벤션 보다는 유저, 사용자의 입장에서 이 코드가 어떻게 보일지를 신경써야 한다고 말씀하셨다. (에러, 입력 null등등)
그 다음 AGENTS.md , CLAUDE.md 파일에 팀 규칙을 적어 AI에게 주입하라고 한다.
작성원칙 - 짧게
각 줄마다 '이 줄을 지우면 AI가 실수하는가?'를 묻고, 아니면 지우기!
길어지면 AI도 안 읽는다.
밑에 부분은 내가 추가로 찾은 부분이다.
"이 프로젝트는 Next.js 14를 사용합니다"
=>
"App Router에서 use client를 빼먹으면 빌드 에러가 나지 않고 런타임에서 조용히 실패합니다"
"사람의 직관으로 AGENTS.md를 채우지 마라. 에이전트가 실제로 실수하는 지점을 관찰하고, 그 지점에 대한 정보만 담아라.
출처: https://goddaehee.tistory.com/534 [갓대희의 작은공간:티스토리]
요약하면 다음과 같다.

보통 요즘은 Next.js와 Vite가 제공해주는 프로젝트 생성 CLI를 써서
귀찮으면 기본 셋팅을 많이 쓰는 경우도 있을거 같다. 나도 사이드프로젝트나 가벼운 프로젝트들은 이런 eslint, typescript , prettier , husky 셋팅을 무시하고 바로 ai와 작업을 시작하는 케이스가 많았다.
ai 시대에 오히려 이런 기본셋팅과 기초가 더 중요하다는걸 배우며 1주차 회고를 맞힌다.