
현대화의 절반은 코딩이 아니라 ‘이해’다
“이거 바꿔도 되나요?”
질문은 짧았는데, 대답은 길어졌다. 아니, 정확히 말하면 대답이 나오지 않았다.
누군가는 “여기만 손대는 거잖아요”라고 했고, 누군가는 “저기서도 쓰는 것 같은데요”라고 했다.
그 사이에 시간은 갔다. 릴리스는 다가오고, 버그는 남아 있고, 팀장은 한 번 더 물었다. “그러면 오늘은 손대지 말자는 거죠?”
그 순간 알았다. 지금 우리를 멈추게 하는 건 난이도가 아니다. 확신의 부재다.
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/
댓글
댓글 쓰기