결론부터 말하면 이렇습니다.
- 방치돼 있던 옛 프로젝트를 되살렸습니다.
- AI한테 통째로 맡기지 않고 한 단계씩 직접 파악했습니다. 그래야 나중에 제가 못 고치는 사태를 피하니까요.
- 순서는 하나입니다. 코드부터 열지 말고 바깥에서 안으로. 아래 그림 한 장에 다 있습니다.
솔직히 귀찮으면 그냥 AI한테 다 던지고 살려내라고 하셔도 됩니다. 그게 더 빠를 수도 있어요. 대신 그렇게 되살린 코드는 온전히 본인 책임입니다. 나중에 어디서 터지든 저는 모릅니다. 그래도 굳이 제 손으로 판 이유가 궁금하시면 그때부터 아래를 읽어 주세요.
로컬 폴더를 정리하다 오래된 프로젝트 하나를 발견했습니다. 마지막으로 연 게 언제였는지도 기억나지 않았습니다. 폴더 이름만 봐서는 뭘 하려던 건지도 잘 떠오르지 않아서 일단 열어 봤습니다. 그리고 한동안 화면을 멍하니 봤습니다. 분명 제가 짠 코드인데 여기가 어디고 이게 뭘 하는 건지 하나도 기억나지 않더군요. 솔직히 이걸 정말 내가 짰나 싶은 부분도 절반은 됐습니다. 방치된 코드 앞에서는 과거의 저도 남이나 다름없었습니다.
앞서 말했듯 이런 건 그냥 통째로 맡겨서 되살릴 수도 있습니다. 저도 되살리면서 도움을 좀 받았고요. 그런데 저는 통째로 던지지는 않았습니다. 파악을 건너뛰면 당장은 돌아가더라도 나중에 문제가 터졌을 때 정작 제가 손을 못 대기 때문입니다. 이해하지 못한 코드는 결국 저한테도 남의 코드나 마찬가지니까요. 특히 오래 굴릴 프로젝트라면 되살리는 것보다 앞으로 제가 계속 고치고 키울 수 있느냐가 더 중요했습니다.
코드부터 열지 않습니다
거창한 방법론은 아닙니다. 그냥 제가 낯선 코드를 만나면 밟는 순서 정도입니다. 딱 한 가지 원칙만 지킵니다. 바깥에서 안으로 들어가는 겁니다. 죽은 코드를 열자마자 아무 파일이나 붙잡으면 길을 잃습니다. 그래서 큰 지도를 먼저 그린 다음에 안쪽으로 좁혀 들어갑니다.
먼저 리드미나 의존성 파일 그리고 폴더 트리를 한 겹만 펼쳐 봅니다. 이때는 코드를 거의 읽지 않습니다. 이게 대충 뭐 하는 프로젝트이고 무엇으로 만들어졌는지 지도만 그리는 단계입니다.
지도를 그렸으면 진입점을 찾습니다. 화면 목록이랑 API 목록이 사실상 이 프로젝트의 목차입니다. 이것만 훑어도 규모가 어느 정도인지 무엇을 하는 프로젝트인지 감이 옵니다.
그다음에는 딱 한 줄기만 끝까지 따라가 봅니다. 전부 읽으려고 하면 오히려 지칩니다. 대신 화면 하나를 골라서 이게 어떤 API를 부르고 그 API가 무슨 로직이랑 데이터를 건드리는지 입구부터 출구까지 쫓아가 봅니다. 하나만 제대로 관통하고 나면 나머지는 대부분 비슷한 패턴이라 갑자기 술술 읽히기 시작합니다.
핵심 데이터 모델도 꼭 봅니다. 엔티티나 타입 정의를 보면 이 앱을 이루는 명사들이 보입니다. 데이터 구조가 뼈대라서 이걸 잡고 나면 절반은 파악한 셈이 됩니다.
이제 왜 멈췄는지를 찾습니다. 마지막 커밋 메시지를 보고 안 끝난 TODO를 뒤지고 실행했을 때 튀어나오는 에러를 살핍니다. 이 미완성 지점이 곧 제가 다시 시작해야 할 자리이기 때문입니다.
마지막으로 작게 굴려 봅니다. 일단 로컬에서 띄워 보는데 안 뜨면 왜 안 뜨는지가 오히려 첫 실마리가 됩니다. 그리고 아주 작은 걸 하나만 고쳐서 반영되는지 확인합니다. 그제야 죽어 있던 프로젝트가 손안에서 다시 움직이는 감이 옵니다.
각 단계에서 AI는 분명 큰 도움이 됐습니다. 폴더 구조를 요약하거나 흐름을 따라가는 걸 훨씬 빠르게 해줬으니까요. 다만 순서를 정하고 어디를 팔지 고르고 그 설명이 맞는지 확인하는 건 제가 했습니다. 적어도 저에게는 그렇게 해야 파악이 머리에 남았습니다.
사실 남의 코드도 똑같습니다
쓰다 보니 느낀 건데 이건 제 죽은 프로젝트에만 쓰는 방법이 아니었습니다. 회사에서 레거시를 넘겨받았을 때도 그랬고 입사 첫날 처음 보는 코드 앞에 앉았을 때도 마찬가지였습니다. 낯선 코드를 읽는 건 결국 다 같은 일이었습니다.
다만 대상이 남의 코드로 바뀌면 몇 가지가 달라집니다. 제 프로젝트는 희미하게라도 기억이 남아 있지만 남의 코드는 그게 없습니다. 그래서 깃 기록이나 커밋 메시지를 뒤져서 그때 무슨 생각으로 이렇게 짰는지를 되짚어야 합니다. 그리고 이유를 모르겠는 이상한 코드가 있어도 함부로 지우지 않습니다. 대개 그 이상함에는 이유가 있고 그 이유를 모른 채 걷어내면 꼭 사고가 나기 때문입니다.
마무리
결국 파악은 누가 대신 해줄 수 없는, 제가 해야 하는 일이었습니다. 그리고 그걸 직접 한 덕분에 오히려 그다음이 편해졌습니다. 다시 말하지만 이게 정답은 아닙니다. 급하면 통째로 맡기는 것도 방법이고요. 다만 저는 이 블로그도 그렇게 한 줄씩 되살려서 지금 여기에 이렇게 올리고 있습니다.