이게 맞나, 저게 맞나 — 개발하면서 매번 마주치는 선택들

최근 며칠 동안 서버에 올려둔 것들을 하나씩 손봤다. 디스코드 TTS 봇을 고치고, 안 쓰는 봇들을 정리하고, 꽉 찬 디스크를 비우고, 이 블로그를 새로 열었다.

그러면서 계속 같은 질문이 따라왔다. 내가 만든 이 구조가 정말 맞는 걸까, 아니면 그냥 당장 돌아가게만 만든 임시방편일까?

정답을 알려주는 튜토리얼은 많은데, 정작 실제로 손을 움직일 때 마주치는 건 정답이 아니라 선택지다. 그 선택지들을 몇 개 적어 둔다.

1. 라이브러리에 기댈 것인가, 직접 만들 것인가

TTS 봇이 어느 날부터 말을 잘 안 했다. 봇은 멀쩡히 켜져 있고 로그에도 에러가 없었다. 파고들어 보니 음성을 만들어 주던 라이브러리가 서비스 쪽 변경 때문에 조용히 실패하고 있었고, 코드는 그 실패를 그냥 삼키고 다음 메시지로 넘어가고 있었다.

• 라이브러리를 쓰는 쪽: 몇 줄이면 끝난다. 대신 그 라이브러리가 멈추면 나도 같이 멈춘다. 최신 버전으로 올려도 똑같이 안 됐다.
• 직접 만드는 쪽: 원리를 이해하게 되고 통제권이 생긴다. 대신 남이 이미 풀어 둔 문제를 내가 다시 풀어야 한다.

결국 고른 건 그 중간이었다. 더 활발하게 관리되는 다른 구현체로 갈아타고, 그게 실패하면 다른 TTS로 넘어가는 대체 경로를 붙였다. 그리고 실패하면 반드시 로그를 남기게 했다.

배운 건 이거다. 라이브러리를 쓰는 건 잘못이 아니다. 실패했을 때 아무도 모르게 되는 구조가 잘못이다.

2. 빨리 돌아가게 할 것인가, 제대로 만들 것인가

고친 TTS가 이번엔 "약간 렉이 있다"는 말을 들었다. 재 보니 문장 하나 읽을 때마다 프로그램을 새로 띄우고 있었고, 그중 절반 이상이 그냥 프로그램이 켜지는 시간이었다. 게다가 앞 문장을 읽는 동안 다음 문장은 아무 준비도 안 하고 있었다.

• 빨리 붙이는 쪽: 처음 고칠 땐 이게 맞았다. 일단 소리가 나야 했으니까.
• 제대로 만드는 쪽: 음성 생성기를 계속 켜 두고, 메시지가 들어오는 순간 미리 만들어 두게 바꿨다. 문장당 1.6초 걸리던 게 0.6초대로 줄었다.

돌아보면 두 번 손댄 게 낭비는 아니었다. 첫 번째는 "되게 만들기", 두 번째는 "잘 되게 만들기"였다. 처음부터 완벽하게 하려 했으면 아마 원인을 찾기도 전에 지쳤을 거다. 다만 임시방편을 임시방편이라고 알고 있는 것, 그게 중요하다.

3. 편하게 할 것인가, 안전하게 할 것인가

블로그를 만들 때 가장 먼저 한 고민이 이거였다. 관리자 페이지에서 로그인하고 글 쓰는 흔한 방식은 편하다. 대신 로그인이 있다는 건 뚫을 문이 있다는 뜻이고, 그 문을 지키는 일은 계속된다.

그래서 반대로 갔다. 로그인도, 관리자 페이지도, 자바스크립트도 없는 정적 사이트. 글은 마크다운으로 쓰고, 서버에 직접 넣으면 페이지가 만들어진다. 지킬 문이 애초에 없다.

그런데 이 과정에서 웃긴 일도 있었다. 글을 올리느라 서버에 짧은 시간 동안 여러 번 접속했더니, 서버의 무차별 접속 차단기가 나를 공격자로 판단하고 막아 버렸다. 내가 세운 보안에 내가 갇힌 셈이다.

여기서 선택지가 또 생겼다. 내 IP를 예외로 넣으면 편하다. 하지만 그건 결국 벽에 구멍을 하나 뚫는 일이다. 결국 고른 건 접속하는 방식을 바꾸는 것이었다. 글 하나 올릴 때 서버에 한 번만 접속하도록 업로드 방식을 고쳤다.

편의와 안전은 늘 반대편에 있는 것처럼 보이지만, 가끔은 불편함의 원인을 고치면 둘 다 얻을 수 있다.

4. 남길 것인가, 지울 것인가

서버 디스크가 거의 꽉 차 있었다. 열어 보니 대부분이 예전에 통째로 옮겨 둔 백업이었다. 다 지우면 편하지만, 그 안에 뭐가 들었는지 확실히 모르는 채로 지우는 건 겁이 났다.

그래서 기준을 하나 세웠다. 다시 만들 수 있는 것부터 지운다. 패키지 폴더, 빌드 결과물, 캐시 같은 것들은 원본 코드만 있으면 언제든 다시 생긴다. 그것만으로 20GB 넘게 비었다. 원본이 하나뿐일지도 모르는 것들은 일단 남겨 뒀다.

지우기 전에 목록을 먼저 뽑아서 눈으로 확인한 것도 컸다. "아마 괜찮겠지"로 지운 건 하나도 없다.

나만의 판단 기준

이것저것 고민하다 보니 몇 가지 기준이 생겼다.

• 지금 단계에 맞는 선택인가. 빨리 확인해 보는 단계인지, 오래 돌릴 서비스인지에 따라 정답이 바뀐다.
• 실패했을 때 알 수 있는가. 어떤 선택을 하든, 망가졌을 때 조용히 망가지면 안 된다.
• 되돌릴 수 있는가. 백업을 남기고, 지우기 전에 목록을 보고, 바꾸기 전에 원래 파일을 복사해 둔다. 되돌릴 수 있으면 과감해질 수 있다.
• 임시방편이면 임시방편이라고 적어 둔다. 나중의 내가 속지 않게.

마치며

완벽한 정답은 없었다. 매번 그 상황에서 가장 덜 나쁜 선택을 고르고, 그 결과를 지켜보고, 아니다 싶으면 다시 고쳤다.

정답 없는 개발 판에서 매번 "이게 맞나?"를 고민하는 것 자체가 성장하고 있다는 증거가 아닐까. 오늘도 코드를 고치며 조금 더 나은 타협점을 찾아간다.