약 6분 읽기
안녕하세요. RPA 엔지니어 황민입니다. 오늘은 좀 특별한 경험을 공유하려고 해요. 바로 소스 코드 없이 레거시 시스템의 .NET 4.5 DLL을 분석했던 이야기입니다. 특히, 이 과정에서 AI의 도움을 얼마나 받았고, 또 어떤 한계가 있었는지 솔직하게 말씀드리려고 합니다.
얼마 전, 한 제조업 고객사에서 RPA 프로젝트를 진행하게 되었습니다. 기존 시스템이 워낙 오래되어 소스 코드가 거의 남아있지 않은 상황이었죠. 게다가 핵심 로직이 담긴 .NET 4.5 기반의 DLL 파일만 덜렁 남겨져 있었습니다. 저희 RPA 개발팀에게는 마치 암호 같은 존재였죠. 이 DLL을 분석해서 RPA 연동 지점을 찾아내고, 자동화 프로세스를 설계해야 했으니까요.
난관에 부딪히다: 소스 없는 DLL의 압박
일반적으로 RPA 개발 시에는 대상 시스템의 API를 활용하거나, GUI 자동화를 통해 연동합니다. 하지만 이 경우에는 API 문서도 없고, GUI 자체도 복잡한 레거시 시스템이었어요. 남은 건 오직 DLL 파일뿐. DLL을 열어봐야 겨우 함수 이름 정도만 확인할 수 있을 뿐, 각 함수의 구체적인 동작 방식이나 파라미터, 반환값 등은 알 길이 없었습니다. 마치 설명서 없이 조립해야 하는 복잡한 기계 같았죠.
처음에는 디컴파일러 툴을 이용해 DLL 내부를 들여다보려고 했습니다. dnSpy 같은 툴이 강력하긴 하지만, .NET 4.5 버전의 DLL은 어느 정도 디컴파일이 가능해도, 실제 동작 로직을 완벽하게 파악하기에는 한계가 있었습니다. 코드의 가독성이 떨어지고, 최적화된 코드는 분석이 더 어렵거든요. 마치 퍼즐 조각만 잔뜩 있는데, 어떤 그림을 맞춰야 할지 모르는 상황과 같았습니다. 밤새도록 씨름해도 진전이 더디기만 했어요.
AI, 과연 구세주가 될 수 있을까?
이런 상황에서 자연스럽게 AI의 도움을 떠올리게 되었습니다. 최근 개발자들 사이에서 AI 코딩 도우미가 큰 인기를 얻고 있잖아요? 저도 개인 서버 운영이나 n8n 워크플로우 구축 등 다양한 방면에서 AI를 활용하고 있는데, 이번에도 AI가 이 난제를 풀어줄 수 있을지 기대를 안고 시도해봤습니다.
제가 사용해본 AI는 Claude Code였습니다. 일단, DLL 파일 자체를 직접 업로드해서 분석해달라고 요청할 수는 없었습니다. AI 모델은 코드나 텍스트를 기반으로 학습하고 분석하기 때문이죠. 그래서 저는 다른 방법을 사용했습니다. 앞서 언급했던 디컴파일러 툴로 추출한 DLL의 함수 목록과, 몇 가지 추측되는 동작 방식에 대한 제 생각을 텍스트로 정리해서 Claude Code에 입력했습니다.
예를 들어, “이 함수 이름은 ‘CalculateInterest’인데, 아마 이자 계산 로직과 관련이 있을 것 같습니다. 입력 파라미터로는 원금과 이자율이 들어갈 것으로 예상됩니다.” 와 같은 형태로요. 그리고 Claude Code에게 “이 함수가 어떤 역할을 할 가능성이 높을까요? 예상되는 입력과 출력은 무엇일까요?” 라고 질문을 던졌습니다.
Claude Code의 활약: 예상치 못한 통찰력
놀랍게도 Claude Code는 제가 제공한 단편적인 정보들을 바탕으로 꽤 정확한 추론을 내놓았습니다. 제가 생각지도 못했던 함수의 역할이나, 잠재적인 오류 가능성까지 짚어주더군요. 특히, 저는 특정 함수가 ‘데이터 조회’ 역할을 할 것이라고 예상했는데, Claude Code는 해당 함수가 ‘데이터 조회’뿐만 아니라 ‘데이터 업데이트’까지 수행할 가능성이 있다고 제안했습니다. 이 부분은 제가 놓쳤던 부분이었는데, 실제 시스템 동작을 확인해보니 Claude Code의 예측이 맞았습니다. 정말 짜릿했죠!
또한, 여러 함수들의 호출 관계를 추측하고, 이를 바탕으로 전체적인 로직의 흐름을 그려보는 데에도 큰 도움을 받았습니다. 마치 경험 많은 선배 개발자가 옆에서 코드 리뷰를 해주는 듯한 느낌이었어요. 제가 작성한 분석 내용을 바탕으로, 더 효율적인 분석 방향이나 추가적으로 확인해야 할 부분을 제안해주기도 했습니다.
AI의 한계: 결국 사람의 경험과 직관이 중요
하지만 AI가 모든 것을 해결해주지는 못했습니다. Claude Code가 제시하는 정보들은 어디까지나 ‘가능성’과 ‘추측’의 영역이었습니다. 최종적인 판단은 결국 제 몫이었죠. AI가 제시한 여러 가설들을 검증하기 위해 실제 시스템에 테스트 코드를 삽입하거나, 디버깅을 통해 동작을 직접 확인하는 과정이 필수적이었습니다.
특히, 레거시 시스템은 예상치 못한 예외 처리나 숨겨진 로직이 존재하는 경우가 많습니다. AI는 이러한 미묘한 부분까지 파악하기에는 한계가 있었습니다. 예를 들어, 특정 조건에서만 발생하는 버그나, 외부 시스템과의 복잡한 연동 로직 등은 AI가 스스로 파악하기 어렵더군요. 이런 부분은 결국 현업 담당자의 인터뷰나, 수많은 테스트를 통해 직접 경험하고 파악해야 했습니다.
또한, AI는 ‘왜’ 그렇게 동작하는지에 대한 근본적인 이유보다는, 주어진 정보를 바탕으로 ‘어떻게’ 동작할지를 예측하는 데 더 능숙했습니다. 시스템의 아키텍처 설계나, 과거 개발자의 의도를 파악하는 데에는 역시 사람의 경험과 직관이 중요했습니다.
결론: AI는 강력한 조력자, 하지만 대체자는 아니다
결론적으로, Claude Code와 같은 AI 도구는 레거시 DLL 역공학 과정에서 매우 강력한 조력자가 될 수 있었습니다. 소스 코드 없이 막막했던 분석 작업에 새로운 가능성을 열어주었고, 시간과 노력을 절약하는 데 큰 기여를 했습니다. 특히, 제가 놓칠 수 있었던 부분을 짚어주고, 분석 방향을 제시해주는 점은 매우 인상 깊었습니다.
하지만 AI가 사람의 역할을 완전히 대체할 수는 없습니다. AI는 어디까지나 도구일 뿐, 최종적인 판단과 문제 해결은 결국 사람의 경험, 직관, 그리고 끊임없는 검증 과정을 통해 이루어져야 합니다. 특히, 복잡하고 오래된 레거시 시스템일수록 더욱 그렇습니다.
이번 경험을 통해 저는 AI와 함께 일하는 미래가 더욱 기대됩니다. AI의 도움을 받아 더욱 효율적으로 일하면서도, 결국 인간만이 가진 통찰력과 경험을 바탕으로 더 나은 결과물을 만들어낼 수 있을 것이라고 믿습니다. 여러분도 혹시 비슷한 경험이 있으시다면 댓글로 공유해주세요!
맞벌이 부부로서 ISA 계좌로 ETF 자동 투자를 하고, 홈 IoT 구축에도 관심을 기울이고 있는 저의 이야기가 여러분께도 작은 인사이트가 되었기를 바랍니다. 다음에도 흥미로운 IT 이야기로 돌아오겠습니다.
감사합니다.
황민 드림
