본문 바로가기
구축기술

안 쓰는 코드 2만 줄 지우기, 삭제 전에 실측부터 했습니다

AI로 만든 기능을 걷어낼 때 지우기 전에 잰 것, 이름만 믿다 죽을 뻔한 기능, 코드 먼저 DB 나중 순서, 뺀 절차를 복원 조건과 함께 남긴 이유를 시행착오 그대로 적었습니다.

만드는 데 쓴 시간보다 지우는 데 쓴 시간이 더 길었습니다. 그런데 그 시간이 아깝지 않았던 건, 지우기 전에 먼저 재 봤기 때문입니다.

이 글 3줄 요약

  • 한 번도 돌지 않은 새 엔진을 코드 2만 줄 걷어내면서, 지우기 전에 "몇 줄·몇 행·누가 쓰나"부터 실측했습니다.
  • 이름에 "새 엔진"이 붙었다고 통째로 지웠으면 포인트 화면과 유일한 안전 검사가 같이 죽을 뻔했습니다.
  • 뺀 절차는 지우지 않고 "실사용자가 1명이라도 생기면 되살린다"는 복원 조건과 함께 문서로 박제했습니다.

한 번도 돌지 않은 엔진이 2만 줄을 차지하고 있었습니다

저희가 만드는 장사레이더(자영업 매장용 AI 콘텐츠·동네 신호 서비스)에는 "근거 엔진"이라고 이름 붙인 새 부품이 있었습니다. 글감의 근거를 더 잘 모으겠다고 코딩 AI 도구와 함께 만든 것인데, 실제 서비스에서는 한 번도 돌지 않았습니다. 기존 엔진과 기능도 겹쳤고요. 그래서 이 새 엔진과 부속(신·구 전환 장치)을 코드와 DB(데이터베이스, 자료를 표 형태로 쌓아 두는 창고)에서 한 번에 걷어내기로 했습니다.

규모를 재 보니 생각보다 컸습니다. 통째로 지울 파일이 63개에 약 21,000줄, 일부만 잘라낼 곳이 24개 파일에 걸쳐 28지점, DB 표 6개와 자료형 4개, DB 함수 11개까지. 전체 코드의 약 25%가 사라지는 작업이었습니다. 나중에 집계해 보니 실제로는 23,622줄이 줄었습니다.

여기서 솔직한 고백 하나. 처음에는 '안 쓰는 거니까 폴더째 지우면 그만'이라고 가볍게 봤습니다. 만들 때는 그렇게 설계며 안전장치며 따졌으면서, 지울 때는 절차가 없었습니다. 그 생각이 틀어진 지점부터 적겠습니다.

조사서가 "몇 줄만"이라던 곳이 사실은 물려 있었습니다

먼저 조사서부터 만들었습니다. 코딩 AI 도구와 함께 어떤 파일을 지울지, 어디를 잘라낼지 목록을 뽑았는데 꽤 깔끔하게 나왔습니다. 그중 한 곳은 "이 몇 줄만 지우면 끝"이라고 되어 있었습니다.

그런데 그 몇 줄을 실제로 열어 보니, 기존 엔진의 새로고침 복원 기능에 물려 있었습니다. 화면을 새로고침해도 진행 상태가 살아 있게 해 주는 기능입니다. 조사서대로 지웠으면 새 엔진은 사라지고, 멀쩡히 쓰던 기존 기능이 같이 죽는 상황이었습니다.

왜 이런 일이 생겼을까요. 조사서는 "새 엔진 관련"이라는 이름 기준으로 묶였고, 그 묶음 안에 공용 부품이 섞여 있는지는 직접 열어 봐야만 알 수 있었습니다. 그래서 그때부터 규칙을 바꿨습니다. 지울 파일마다 그 파일을 불러 쓰는 곳을 전부 다시 찾고, 지울 DB 표는 실제 행 수를 셌습니다. 결과는 표 6개 중 5개가 0행, 나머지 1개도 이미 꺼져 있는 스위치 설정 2줄뿐. "이번에 잃는 데이터 = 설정 2줄"이라는 한 줄이 나오고 나서야 지울 자격이 생겼습니다.

이름만 믿었으면 살릴 기능이 죽었습니다

실측하면서 이름 함정이 줄줄이 나왔습니다.

이름에 "새 엔진"이 붙은 파일 안에, 포인트 관련 화면 여러 곳이 쓰는 기능이 들어 있었습니다. 이름에 "생성"이 들어간 설정값은 사실 신·구 공용이라, 지우면 온보딩(첫 가입 안내) 자동 검사가 깨집니다. 제일 아찔했던 건 "포인트 예약 테스트"라는 파일입니다. 이름만 보면 새 엔진용 같은데, 기존 엔진에서 포인트가 두 번 빠지지 않게 지키는 유일한 자동 검사가 그 안에 있었습니다. 통째로 지웠으면 포인트가 두 번 빠지는 사고를 잡아 줄 검사가 사라질 뻔했습니다. 이 파일은 지우지 않고 필요한 검사만 새 파일로 옮기는 쪽으로 계획을 고쳤습니다.

엑셀 시트 정리할 때와 똑같습니다. "구버전"이라고 적힌 시트가 사실 다른 시트의 참조 원본인 경우, 다들 한 번쯤 겪어 보셨을 겁니다. 이름은 만든 날의 의도일 뿐, 지금 누가 쓰는지는 말해 주지 않습니다.

순서는 코드 먼저, DB 나중, 커밋은 하나

새 엔진 부품끼리 서로를 불러 쓰고 있어서, 조금씩 나눠 지우면 중간 상태마다 빌드(코드를 실행 가능한 프로그램으로 묶는 작업)가 깨졌습니다. 그래서 커밋(변경 묶음을 저장하는 단위) 1개로 통삭제하고, 일부만 되돌리는 건 금지로 정했습니다.

순서도 평소와 반대입니다. 기능을 더할 때는 보통 DB를 먼저 바꾸는데, 뺄 때는 코드에서 참조를 다 걷어내고 배포가 끝난 걸 확인한 다음에 DB 표를 지웁니다. 순서를 뒤집으면 돌고 있는 앱이 없는 표를 찾다가 오류를 냅니다. DB 삭제 직전에는 "진행 중인 작업 0건"을 한 줄로 확인했습니다.

그리고 빌드가 못 보는 흔적이 있습니다. 따옴표 안에 적힌 DB 표 이름이나 함수 이름은 빌드 검사가 확인하지 않습니다. 그래서 지운 표 6개·함수 11개·자료형 4개와 코드 이름을 전부 검색어로 묶어 "남은 흔적 0건"을 커밋 직전 조건으로 걸었습니다. 검색 도구는 못 찾으면 그냥 빈 화면을 보여 주기 때문에, 성공 판정은 "명령 종료 신호"가 아니라 "찾은 개수 0"으로 했습니다.

초록불이 못 잡는 건 사람 확인 목록으로

검사 6종을 모두 통과해도 놓칠 수 있는 위험이 3항목 나왔습니다. 새로고침하면 진행 상태가 사라지는 것, 옛 링크로 들어오면 가짜 안내 띠가 뜨고 매번 실패하는 것, 유일한 글감 생성기가 접힌 서랍 안에 숨어 버리는 것. 하나는 기존 자동 검사가 잡았지만 나머지 둘은 사람이 눌러 보는 것 말고는 방어가 없었습니다. 그래서 배포 후 사람 확인 시나리오 8개와 옛 링크 확인 1개를 따로 적었습니다.

옛 링크 얘기를 조금 더 하면, 링크를 만드는 쪽은 지워도 들어오는 옛 링크를 걸러 주는 문지기는 남겼습니다. 손님의 즐겨찾기와 검색 결과는 계속 옛 주소를 들고 오니까요.

저희가 실제로 낸 배포 사고도 있습니다. 검사 명령 뒤에 출력을 거르는 명령을 이어 붙여 둔 채로 성공 여부를 봤더니, 마지막 명령의 신호만 남아 깨진 빌드가 성공으로 보고됐습니다. 거기에 사이트 주소가 열리길래 배포가 됐다고 믿었는데, 열린 건 옛 버전이었고 "완료" 표시도 다른 버전 것을 본 거였습니다. 그 뒤로는 결과 신호를 먼저 저장하고 나서 출력을 자르고, 배포 목록에서 방금 올린 그 버전이 완료인지 대조합니다. 에러가 없다고 성공은 아니라는 걸 조용한 실패 글에서 한 번 적었는데, 또 당했습니다.

뺀 절차는 복원 조건과 함께 박제했습니다

계획서는 다른 회사 AI에게 반박 검수를 맡겨 반대 근거 8건을 받았습니다. 4건은 반영, 3건은 생략, 1건은 제가 결정하는 것으로 넘겼습니다. 보존할 사용자 데이터가 없다는 전제로 뺀 절차는 모두 5개입니다. 옛 화면 대기, DB 완전 복구 설계, 실제 DB 의존 관계 전수검사, 백업 파일, 그리고 DB 삭제 전후 확인 2회를 삭제 후 1회로 줄인 것.

뺀 건 지운 게 아니라 접어 둔 겁니다. "실사용자가 1명이라도 생기면 대기 절차 복원"처럼 되살릴 조건을 같이 적어 뒀습니다. 오픈 뒤에 같은 작업을 할 때 처음부터 다시 고민하지 않으려고요. 사라진 자동 검사 자리도 돌지 않는 빈 껍데기 테스트로 채우지 않고 "감시 공백" 한 줄로 기록해 다음 숙제로 넘겼습니다. 손님이 생긴 뒤에도 '깨지면 그때 가서 손보기'로 절차를 빼는 건 다른 얘기입니다. 이번 생략은 잃을 데이터가 없어서만 가능했습니다.

현장 인사이트

만들 때 안전장치를 따지는 사장님은 많은데, 지울 때 절차를 따지는 분은 드뭅니다. 지우는 것도 변경이고, 변경은 잴 수 있을 때만 안전합니다.

오늘 바로 해 볼 것

꼭 코드가 아니어도 됩니다. 안 쓰는 자동응답 문구, 오래된 엑셀 시트, 켜 둔 채 잊은 자동화 봇도 같은 순서로 걷어내시면 됩니다.

  1. 지울 대상을 쓰는 곳과 그 안의 실제 데이터 양을 먼저 셉니다. "잃는 것" 목록이 한 줄로 나와야 다음으로 갑니다.
  2. 이름이 헷갈리는 건 열어 봅니다. 살릴 기능이 섞여 있으면 그 부분만 떼어 옮깁니다.
  3. 코드 먼저, DB 나중. 배포가 끝난 버전인지 목록에서 대조한 뒤에 표를 지웁니다.
  4. 지운 이름을 전부 검색해 0건을 확인합니다.
  5. 검사가 못 잡는 위험은 사람이 눌러 볼 목록으로 적습니다.
  6. 뺀 절차는 되살릴 조건과 함께 문서에 남깁니다.

코딩 AI 도구에 시킬 때는 "지워 줘" 대신 조사부터 시키세요. 이렇게 붙여 넣으시면 됩니다.

아래 기능을 지우려고 합니다. 바로 지우지 말고, 조사만 해서 표로 보고해 주세요.

1. 지울 대상: [기능 이름 / 파일 / DB 표 이름]
2. 이 대상을 불러 쓰는 곳을 전부 찾아 파일별로 적어 주세요. 이름에 "새 기능"이 붙은 파일이라도 안에 다른 기능이 섞여 있으면 따로 표시해 주세요.
3. 지울 DB 표가 있으면 각 표의 현재 행 수를 실제로 세어 적어 주세요. 추정은 금지입니다.
4. 지우면 사라지는 자동 검사 목록과, 그 검사가 지키던 기능을 적어 주세요.
5. 빌드와 검사가 통과해도 사람이 직접 눌러 봐야 알 수 있는 위험을 따로 적어 주세요.
6. 보고가 끝나면 멈추고 제 승인을 기다려 주세요.

삭제가 끝난 뒤에는 이 한 줄을 추가로 보냅니다.

지운 표·함수·자료형·파일 이름을 전부 검색어로 묶어 코드 전체를 검색해 주세요. 성공 기준은 "검색 결과 0건"입니다. 명령이 끝났다는 신호가 아니라 찾은 개수를 숫자로 보고해 주세요.

지우는 게 만드는 것보다 어렵게 느껴지신다면, 그게 정상입니다. 어떤 걸 걷어내야 할지부터 같이 재 보고 싶으시면 편하게 문의 주세요.

무료 상담 신청하기 →

자주 묻는 질문

AI로 만든 기능을 지울 때 왜 바로 지우면 안 되나요?

이름만 보고 지우면 그 파일 안에 섞여 있던 다른 기능까지 같이 사라집니다. 지우기 전에 그 파일을 쓰는 곳과 DB 표의 실제 행 수를 재서 '잃는 것' 목록부터 만드는 편이 안전합니다.

코드와 DB 중 무엇을 먼저 지워야 하나요?

삭제는 코드 먼저, DB 나중입니다. 코드에서 참조를 다 빼고 새 버전 배포가 끝난 것을 확인한 뒤에 DB 표를 지워야, 돌고 있는 앱이 없는 표를 찾다 오류를 내는 일을 막습니다.

빌드와 테스트가 통과하면 안심해도 되나요?

아닙니다. 빌드 검사는 따옴표 안에 적힌 표 이름이나 함수 이름을 보지 못합니다. 지운 이름을 전부 검색해 남은 흔적 0건을 확인하고, 초록불이 못 잡는 위험은 사람이 직접 눌러 보는 확인 목록으로 따로 남겨야 합니다.

코딩을 모르는 사장님도 이 절차가 필요한가요?

네. 안 쓰는 엑셀 시트나 자동응답 문구를 정리할 때도 같습니다. 지우기 전에 누가 쓰는지 세고, 뺀 절차는 되살릴 조건과 함께 적어 두면 나중에 같은 고민을 반복하지 않습니다.

관련 글