Biome를 왜 도입했나
이날은 린터 선택에 대한 날이었다.
며칠 전에 Biome로 통합했는데, 써보니까 별로여서 ESLint랑 Prettier로 돌아왔다.
도구를 도입했다가 빼는 건 좀 부끄러운 일이지만 안 좋으면 빼는 게 맞다.
그리고 소설 생성 에이전트 구조도 설계했다.
며칠 전에 여러 프로젝트에서 ESLint랑 Prettier를 Biome로 통합했다.
이유는 단순했다.
의존성이 여섯 개에서 하나로 줄고 Rust 기반이라 빠르고 모노레포를 잘 지원한다고 했으니까. 근데 막상 써보니까
장점이 크지 않았다.
속도 차이가 별로 안 난다
가장 큰 기대는 속도였다.
Biome가 ESLint보다 훨씬 빠르다고 들었다.
근데 실제로 측정해보니까 20개 파일 수준에서는 차이가 무의미했다.
ESLint도 최근 버전에서 멀티스레드 린팅을 지원한다.
큰 파일에서는 27% 빨라졌다.
20개 파일에서는 Biome랑 ESLint 차이가 체감이 안 됐다.
“Biome가 빠르다”는 게 1000개 파일 이상에서나 의미가 있다.
20개 파일에서는 설정 복잡도랑 에디터 통합이 훨씬 중요하다.
에디터에서 자꾸 에러가 뜬다
더 큰 문제는 에디터 통합이었다.
터미널에서 돌리면 에러가 0개다.
근데 에디터에서는 자꾸 에러가 떴다.
이미 고친 코드에 에러가 뜨는 거다.
원인을 추적해보니 여러 가지가 겹쳤다.
전역 Biome랑 프로젝트 Biome 버전이 다를 수 있다.
에디터가 캐시를 들고 있을 수 있다.
에디터가 다른 설정 파일을 읽을 수 있다.
터미널에서는 깨끗한데 에디터에서 더럽게 보이면, 결국 린트를 안 믿게 된다.
“이게 진짜 에러인가, 에디터 착각인가”를 매번 판단해야 한다.
이건 비용이다.
ESLint로 롤백
그래서 ESLint랑 Prettier로 돌아왔다.
두 개 프로젝트에서 전부 롤백했다.
ESLint는 생태계가 성숙하다.
TypeScript 플러그인이 잘 되어 있고 규칙도 많다.
Prettier는 포맷팅 표준이다.
에디터 통합도 잘 되어 있다.
버전이 다르면 안 되지만 그런 문제는 거의 없다.
도입했던 Biome 설정을 지우고 ESLint 설정을 다시 만들었다.
타입 안전성 규칙, 임포트 순서, 포맷팅 규칙까지. 24개 파일이 바뀌었다.
전부 정상 동작을 확인했다.
도구를 도입했다가 빼는 건 부끄러운 일이 아니다
Biome를 도입했다가 빼는 건 좀 부끄러운 일처럼 보일 수 있다.
“충분히 조사 안 하고 도입했나” 같은 소리를 들을 수 있다.
근데 안 좋으면 빼는 게 맞다.
“도입했으니까 쓴다”는 더 나쁜 선택이다.
안 좋은 걸 계속 쓰면 비용이 계속 든다.
조사는 했다.
의존성이 줄고 빠르고 모노레포를 잘 지원한다고 들어서 도입했다.
근데 실제로 써보니까 에디터 통합이 안 좋았고 속도 차이도 미미했다.
그러면 빼는 게 맞다.
“실제로 써봐야 아는 것”이 있다.
소설 생성 에이전트 구조
린터 외에 소설 생성 프로젝트의 에이전트 구조도 설계했다.
핵심 문제는 긴 맥락의 연속성이다.
여러 에피소드에 걸쳐 캐릭터, 줄거리, 타임라인이 일관되어야 한다.
처음에는 3개 에이전트로 설계했다.
계획하는 에이전트, 씬을 쓰는 에이전트, 검증하는 에이전트. 백만 토큰 컨텍스트 모델을 쓰면 이전 에피소드 전체 텍스트를 한 번에 넣을 수 있다.
그러니까 요약 계층이 필요 없다고 생각했다.
근데 같은 날 오후에 설계가 바뀌었다.
요약 에이전트를 다시 넣었다.
요약이 없으면 여러 에피소드에 걸친 일관성이 깨진다.
순수하게 “전체 텍스트를 다
넣는다”는 접근은, 몇 에피소드까지는 되는데 길어지면 한계가 있다.
그래서 4개 에이전트로 정리했다.
계획, 작성, 요약, 검토. 요약은 5개 에피소드마다 아크 요약을 만들어서 장기 기억으로 쓴다.
검토 에이전트는 충돌이랑 누락을 찾아서 다음 계획 에이전트한테 피드백을 준다.
이 구조는 이후에 계속 진화했다. 4개에서 5개로, 그리고 나중에는 전혀 다른 방향으로 갈아없었다.
근래 이날 세운 뼈대는 “에이전트가 역할을 나눠서 협력한다”는 원칙이었다.
마무리
내가 이날 배운 핵심은 다음과 같다.
이날의 교훈은 두 가지다.
첫째, 도구는 실제로 써봐야 안다.
Biome는 좋은 도구다.
근데 내 상황에서는 안 맞았다.
속도 차이가 미미하고 에디터 통합이 안 좋았다.
이건 써보기 전에 알 수 없었다.
도입해보고 안 좋으면 빼는 게 맞다.
둘째, 설계는 진화한다.
소설 생성 에이전트를 처음에 3개로 설계했다가 같은 날 4개로 바꿨다.
“요약이 필요 없다”고 생각했는데, 몇 시간 만에 “필요하다”로 바뀌었다.
설계를 고정하지 말고 한계가 보이면 바로 수정해야 한다.