현대화의 절반은 코딩이 아니라 ‘이해’다

thumbnail

현대화의 절반은 코딩이 아니라 ‘이해’다

“이거 바꿔도 되나요?”

질문은 짧았는데, 대답은 길어졌다. 아니, 정확히 말하면 대답이 나오지 않았다.

누군가는 “여기만 손대는 거잖아요”라고 했고, 누군가는 “저기서도 쓰는 것 같은데요”라고 했다.

그 사이에 시간은 갔다. 릴리스는 다가오고, 버그는 남아 있고, 팀장은 한 번 더 물었다. “그러면 오늘은 손대지 말자는 거죠?”

그 순간 알았다. 지금 우리를 멈추게 하는 건 난이도가 아니다. 확신의 부재다.

AI가 코드를 더 빨리 쓰게 만들어주는 시대에, 이게 더 자주 터진다. 새로 짓는 속도는 빨라졌는데, 기존이 뭘 하는지 모르면 그 속도가 오히려 사고를 키운다.

AWS가 COBOL 현대화 경험에서 강조한 것도 결국 같은 이야기로 읽혔다. ‘변환’이 아니라 ‘이해’가 먼저다. (참고자료)


이해가 없으면, 속도는 빚이다

현대화 프로젝트에서 속도가 빚이 되는 순간은 늘 비슷하다.

  • 바꿨는데, 어딘가가 조용히 달라진다
  • 테스트는 통과했는데, 한 달 뒤에 회계/정산/통계에서 숫자가 틀어진다
  • 원인을 찾으려면 사람들을 다시 불러야 한다(그때는 이미 기억이 휘발됐다)

이런 류의 문제는 “코드를 잘 짜면” 해결되지 않는다.

오히려 코드를 더 빨리 짜면 더 빨리 망가진다. 이해 없이 바꾸는 건, 빨리 뛰는 게 아니라 빨리 미끄러지는 거다.

그래서 나는 현대화에서 ‘코딩’을 작업의 앞에 두지 않는다. 이해를 만들어두면 코딩은 따라온다. 반대로 이해가 없으면, 코딩은 팀을 멈추게 하는 비용이 된다.


내가 먼저 만드는 문서 세 장(이게 없으면 안 건드린다)

의존성 지도 — “여기만 바꾸면 돼요?”에 답하는 종이

처음에는 코드가 아니라 호출 관계부터 본다. 함수 이름이 아니라 “이 경로가 저 경로를 부른다”는 사실.

지도는 거창할 필요가 없다. 박스와 화살표 몇 개면 된다.

중요한 건 ‘의심을 끝내는’ 힘이다. 누가 “여기만 바꾸면 돼요”라고 말할 때, 지도가 있으면 바로 확인할 수 있다.

없으면? 그 말은 믿음이 된다. 믿음으로 배포하면, 믿음만큼 깨진다.

이 지도를 만들다 보면 재미있는 일이 생긴다. 팀이 그동안 “원래 그렇지”로 넘겼던 우회로, 숨은 배치 작업, 오래된 파일 전송이 튀어나온다. 그게 진짜 시스템이다.

플랫폼 차이 메모 — 코드 밖에서 바뀌는 것들(숫자/시간/정렬)

현대화가 어려운 이유는 코드가 낡아서가 아니라, 코드 바깥이 바뀌어서다.

컴파일러 옵션 하나, 런타임의 숫자 처리 방식, 날짜/시간대, 반올림 규칙, 문자열 정렬.

이런 것들이 시스템의 ‘의도’를 조용히 바꾼다.

그래서 나는 “플랫폼 차이 메모”를 따로 만든다. 누가 봐도 지루한 문서인데, 사고가 날 때는 이 문서가 제일 먼저 열리게 된다.

재현이 안 되는 버그의 상당수가 여기서 끝난다. 코드가 아니라 환경의 차이였던 거다.

추적 가능한 스펙 — “그 말이 코드 어디에 박혀 있죠?”

마지막은 스펙이다. 그런데 내가 말하는 스펙은 ‘이상적인 요구사항’이 아니다.

“이 문장은 실제 코드의 어디에서 나왔는가”가 연결된 스펙이다.

예를 들어 “이자 계산은 월말 기준” 같은 한 문장을 적으면, 그 문장을 뒷받침하는 코드 위치(또는 데이터 흐름)가 같이 붙는다.

이걸 해두면, 논쟁이 줄어든다. 사람들은 원칙을 싸우기보다, 현실을 확인하게 된다.

AWS 글이 말하는 결정론적(결과를 다시 따라갈 수 있는) 접근이 바로 여기서 필요해진다. 현대화의 승패는 생성 능력이 아니라 ‘따라갈 수 있냐’에서 갈린다. (참고자료)


내가 “오늘은 손대지 말자”라고 말하는 순간

의존성 지도를 그려봤는데도 “여기만 바꾼다”가 여전히 믿음이면, 오늘은 안 민다. 플랫폼 차이 메모가 비어 있는데도 숫자/정산/통계가 걸린 변경이면, 지금은 밀지 않는다. 스펙 한 문장을 코드 위치로 연결할 수 없는데도 핵심 로직을 바꾸려 한다면, 지금은 밀지 않는다. 반대로 이 세 가지가 채워졌다면, 그때 AI를 써도 된다. 그 속도는 그때서야 팀 편이 된다.


참고자료

  • AWS ML Blog — Learnings from COBOL modernization in the real world
    • https://aws.amazon.com/blogs/machine-learning/learnings-from-cobol-modernization-in-the-real-world/

댓글