스크립트
00:00:00CLAUDE.md 파일을 아무리 수정해도 저품질 코드가 코드베이스로 유입되는 것을
00:00:05막을 수 없다는 사실이 드러났습니다. 온갖 코드가 슬그머니 스며들고
00:00:09때로는 에이전트가 규칙을 완전히 무시하기도 하죠. 다행히도 믿음직한 린터가
00:00:15구원투수로 나섭니다. anti-slop은 근거가 부족하고 신뢰도가 낮은
00:00:20TypeScript 및 JavaScript 패턴을 거부하는 Oxlint 규칙입니다. 이번 영상에서는 프로젝트에서 이를 활용해
00:00:30에이전트가 더 높은 품질의 코드를 작성하도록 돕는 방법을 살펴보겠습니다. anti-slop은 소스 단계에서
00:00:36저품질 코드를 잡아내는 린트 규칙 모음입니다. 이 저장소에는 연쇄 타입 단언, unknown 매개변수,
00:00:41unknown 반환 같은 문제를 감지하기 위한 다양한 규칙이 길게 나열되어 있습니다. 이 모든 규칙에
00:00:47동의하지 않으셔도 괜찮습니다. 핵심은 전부 다 사용하는 것이 아니라 팀의 표준에 맞는
00:00:53규칙만 엄선하는 것입니다. 린팅은 차단하고 싶은 코드를 확실하게 거부할 수 있는 훌륭한 방법으로,
00:00:59토큰을 절약하고 저품질 코드를 원천 차단할 수 있습니다. 반면 CLAUDE.md에 규칙을 적어두는 방식도
00:01:05효과가 있을 수 있지만 우회하기 쉽고 에이전트가 결국 규칙을 무시하는 경우가 종종 발생합니다.
00:01:11하지만 린팅은 대조적으로 더 빠르고 저렴하며 명백한 패턴을 감지하는 데 훨씬 효과적입니다. '토스라니,
00:01:16린터야 옛날부터 있었는데 뭐가 대수지?'라고 생각하실 수도 있습니다. 이 도구들은 단순히 오류를 보여주는 데
00:01:23그치지 않고, 오류가 발생한 이유와 해결 방법을 아주 훌륭하게 설명해 줍니다.
00:01:29이는 에이전트에게 매우 유용한 정보이며, 표준 TypeScript 오류에서 얻을 수 있는 알아보기 힘든
00:01:34잡동사니와는 비교도 안 되게 좋습니다. 그럼 데모로 넘어가서 실제로 어떻게 작동하는지 살펴보고,
00:01:40오픈소스 최신 도구 소식을 계속 받아보고 싶으시다면 Better Stack 채널 구독을 꼭 부탁드립니다.
00:01:45여기 anti-slop 패키지의 린트 규칙에서 비롯된 오류들을 일부러 포함시킨 파일이 있습니다.
00:01:50상단을 보면 타입 캐스팅을 두 번 한 것을 볼 수 있습니다. 먼저 unknown으로, 그다음에는 user로 캐스팅했죠.
00:01:55JSON API에서 응답을 받을 때 보통 이렇게 하곤 합니다. 하지만 이 경우 문제점이
00:01:59무엇이고 어떻게 해결해야 하는지 아주 상세한 오류 메시지가 표시됩니다.
00:02:05이 특정 오류의 경우 “이 단언 체인은 타입 증거를 유실합니다”라고 나옵니다. 실제로 그렇죠.
00:02:11해결책은 원래의 정밀한 타입을 유지하거나, 타입을 좁히기 전에 경계면에서 신뢰할 수 없는 입력을
00:02:18통과시키는 것입니다. Zod 같은 도구를 사용하여 계속 진행하기 전에 타입 안전성을 보장하는 방식이죠.
00:02:22이와 비슷한 예시를 또 볼 수 있습니다. JSON API에서 데이터를 반환할 때 그냥 그대로 반환하고 있는데요.
00:02:29하지만 JSON은 실제로 any 타입을 반환합니다. 여기서 함수는 unknown을 반환하고 있는데, 이 역시
00:02:36약간의 코드 냄새를 풍깁니다. 그래서 “이 함수는 호출자에게 unknown을 노출합니다.
00:02:41경계면에서 값을 전달하고 이름이 지정된 도메인 타입을 반환하세요”라고 안내합니다. 이제 Claude를 실행해서 이 모든 것을 어떻게 처리하는지 보겠습니다.
00:02:48“api 클라이언트의 모든 문제를 수정해 줘”라고 입력해 보겠습니다. 몇 분 동안 실행된 후 모든 문제가 수정된 것을
00:02:54확인할 수 있습니다. 여기서 작업 흐름은 package.json 내에서 린트를 호출하고,
00:03:00oxlint source를 실행한 다음, 이 경우 거의 모든 규칙이 포함된 린트 설정을 사용하는 것입니다.
00:03:06에이전트가 코드를 작성하고, 잠재적인 실수를 저지른 뒤, 린트를 실행해 오류를 인지하고 수정하는 과정을 거칩니다.
00:03:12이런 방식으로 프로덕션에 훨씬 더 높은 품질의 코드를 전달할 수 있습니다. 이 린트 규칙으로 잡아내는
00:03:18오류들이 당장 버그인 것은 아닙니다. 코드는 여전히 컴파일될 수 있지만, 진짜 버그가 도입되기 전에
00:03:24근거가 부족하고 품질이 낮은 코드를 조기에 잡아내는 것이 핵심입니다. 연쇄 캐스팅이 좋은 예시입니다.
00:03:30API에서 계정 정보를 가져올 때 응답을 내가 예상하는 형태로 캐스팅할 수 있습니다. 그 자체로는 버그가 아니며,
00:03:36컴파일도 잘 되고 이후의 모든 로직은 생성된 값이 날짜(date)라고 생각하게 됩니다. 하지만 JSON에는 날짜 타입이 없기 때문에
00:03:41실제로 돌아오는 것은 문자열입니다. 따라서 코드의 어느 부분이든 이를 날짜처럼 다루는 순간 버그가 발생하는 것입니다.
00:03:47원래라면 TypeScript가 이에 대해 경고할 기회가 있어야 하지만, 제가 캐스팅을 통해 증거를
00:03:51폐기해 버렸기 때문에 경고하지 못합니다. 이 패키지는 불과 지난주에 만들어졌으며, 러스트(Rust)로 작성된
00:03:59고성능 자바스크립트 도구 모음인 린터 패키지 oxc를 기반으로 작동합니다.
00:04:04이 린터는 ESLint보다 50~100배 더 빠르도록 벤치마킹되었습니다. 믿기 힘들 정도로 빠른 속도죠.
00:04:10저는 지난 몇 달 동안 모든 프로젝트에서 이 도구를 사용해 왔으며 솔직히 강력히 추천합니다.
00:04:15물론 온라인에서의 반응도 매우 뜨거웠으며, 일부 사용자는 예상보다 약간 더 많은 슬롭 오류를 마주하기도 했습니다.
00:04:20코드베이스를 깔끔하게 정리하고 싶다면 더보기란에 있는 GitHub 링크를 확인해 보세요.
00:04:24구독도 잊지 마세요. 시청해 주셔서 감사드리며, 다음 영상에서 뵙겠습니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기