혼자 개발한 AI 챗봇에서 마주친 기술부채들

도입

사이드 프로젝트를 혼자 진행하다 보면 기능을 붙이는 데 집중하느라 구조를 되돌아볼 시간을 따로 내기 어렵습니다. 이번에 AlterAI 소개 글을 준비하면서 코드베이스를 다시 훑어봤는데, 그동안 쌓인 흔적들이 꽤 눈에 띄었습니다. 잘한 결정도 있었고, 지금 보면 아쉬운 부분도 있었습니다. 이번 글에서는 그중 몇 가지를 정리해보려고 합니다.

발견한 기술부채 1: 빌드 설정이 따로 노는 문제

먼저 빌드 설정 쪽입니다. 버전 정보를 한 곳에 모아두는 파일을 따로 두었는데, 정작 실제 앱 모듈의 빌드 설정은 그 값을 참조하지 않고 다른 값을 직접 써놓은 상태였습니다. 버전을 한 곳에서 관리하겠다고 만들어둔 파일이 어느 순간부터 실제 빌드에 반영되지 않는 장식으로 남아있었던 셈입니다. 기능 추가에 집중하다 보면 이런 설정 파일은 뒷전으로 밀리기 쉽다는 걸 새삼 느꼈습니다.

발견한 기술부채 2: 죽은 코드

두 번째는 죽은 코드입니다. 다른 AI 모델 제공자를 통해서도 채팅을 붙일 수 있게 하려고 만들어둔 요청/응답 모델이 남아있었는데, 실제로 이걸 호출하는 코드는 어디에도 연결되어 있지 않았습니다. 아마 한창 확장을 고민하던 시기에 뼈대만 만들어두고, 우선순위가 바뀌면서 그대로 멈춘 것으로 보입니다. 껍데기만 남은 코드가 계속 빌드에 포함되어 있었다는 걸 뒤늦게 알게 됐습니다.

발견한 기술부채 3: 라이브러리 혼용

세 번째는 라이브러리 혼용입니다. JSON 직렬화 라이브러리를 하나로 통일하려고 했던 흔적은 있는데, 실제로는 두 라이브러리의 애너테이션이 같은 클래스에 동시에 붙어있는 곳이 여러 곳 있었습니다. 상태 관리에 쓰는 공통 타입도 마찬가지로, 화면 대부분은 한 가지 타입을 쓰는데 특정 화면 하나만 다른 모듈에서 가져온 타입을 쓰고 있었습니다. 리팩터링을 하다가 절반만 끝내고 넘어간 것인지, 아니면 의도적으로 남겨둔 것인지는 지금 코드만 봐서는 정확히 기억이 나지 않습니다.

그래도 잘 버틴 결정

반대로 시간이 지나도 잘 버틴 결정도 있었습니다. 데이터베이스 스키마를 바꿀 때마다 마이그레이션 단계를 하나씩 쌓아가는 방식을 고수했는데, 덕분에 강제로 데이터를 초기화하는 방식을 한 번도 쓰지 않고 여러 차례의 구조 변경을 버텨왔습니다. 당장은 번거로워도 마이그레이션을 매번 챙겨둔 게, 나중에 보니 가장 잘한 선택 중 하나였습니다.

왜 이렇게 됐을까

이런 것들이 왜 쌓였는지 생각해보면, 혼자 만드는 프로젝트라서 그런 부분이 큰 것 같습니다. 기능이 하나씩 아쉬운 채로 굴러가더라도 당장 눈에 보이는 문제가 없으면 넘어가게 되고, 리뷰해줄 사람이 없다 보니 반쯤 끝난 리팩터링이 그대로 남는 경우가 잦았습니다. 팀으로 개발했다면 코드 리뷰 과정에서 한 번은 걸렸을 법한 것들이, 혼자 개발하다 보니 계속 넘어간 셈입니다. 반대로 마이그레이션처럼 규칙이 명확하고 매번 같은 방식으로 반복하는 작업은, 혼자 하더라도 흔들리지 않고 지킬 수 있었던 것 같습니다.

마무리

앞으로는 새 기능을 붙이기 전에 이런 부분들을 먼저 정리하려고 합니다. 특히 죽은 코드는 남겨둔다고 딱히 이득이 없는데도 지우는 걸 계속 미루고 있었다는 걸 이번에 다시 깨달았습니다. 다음에는 이번에 정리한 것들을 실제로 어떻게 고쳤는지, 그 과정에서 또 뭘 배웠는지 이어서 써보려고 합니다.

---

[핵심요약] 혼자 개발한 사이드 프로젝트에서 마주친 기술부채 회고