다시, 소프트웨어 엔지니어 (AI 시대에도 결코 대체되지 않을 개발자의 기본 역량과 생존법)

AI가 코드를 빠르게 만들어 주는 시대가 되면서 개발자의 역할이 오히려 더 헷갈리기 쉬워졌다. 예전에는 코드를 직접 많이 쓰는 능력이 중심이었다면, 이제는 어떤 문제를 풀어야 하는지 정의하고, 생성된 코드를 검토하고, 오래 유지될 수 있는 구조로 다듬는 역량이 더 중요해졌다. 『다시, 소프트웨어 엔지니어』를 고른 이유도 여기에 있다. 이 책은 개발자를 단순히 “코딩하는 사람”이 아니라, 소프트웨어를 안정적으로 설계하고 운영하는 사람으로 다시 보게 만든다. 가장 먼저 남는 메시지는 소프트웨어 엔지니어링이 코드 작성보다 넓은 일이라는 점이다. 좋은 코드는 갑자기 생기지 않는다. 요구사항을 이해하고, 변경 가능성을 예상하고, 팀이 함께 읽고 고칠 수 있는 형태로 구조를 잡는 과정이 필요하다. AI가 초안을 만들어 줄 수는 있지만, 그 코드가 실제 서비스의 맥락에 맞는지 판단하는 일은 여전히 개발자의 몫이다. 이 책은 그 판단력을 키우기 위해 아키텍처, 리팩토링, 테스트, 배포 같은 기본기를 다시 점검하게 한다. 특히 리팩토링과 테스트를 다루는 관점이 실무적으로 와닿았다. 많은 프로젝트에서 기술 부채는 한 번에 생기지 않는다. 급한 일정 속에서 작은 예외를 허용하고, 테스트 없이 수정하고, 책임이 애매한 코드를 방치하는 일이 반복되면서 시스템이 점점 다루기 어려워진다. 그래서 리팩토링은 예쁜 코드를 만들기 위한 취미가 아니라, 앞으로의 변경 비용을 낮추기 위한 투자에 가깝다. 테스트도 마찬가지다. 테스트는 버그를 찾는 장치이기도 하지만, 코드를 자신 있게 바꿀 수 있게 해주는 안전망이다. 또 하나 생각하게 된 부분은 도구를 선택하는 태도다. 개발자는 새로운 프레임워크나 AI 도구를 빠르게 받아들여야 하지만, 유행을 그대로 따라가는 것만으로는 부족하다. 지금 해결하려는 문제가 무엇인지, 팀의 역량과 운영 환경에 맞는지, 나중에 유지보수할 수 있는지를 같이 봐야 한다. 결국 좋은 엔지니어는 도구를 많이 아는 사람이 아니라, 문제에 맞는 선택을 설명할 수 있는 사람이라는 생각이 들었다. 이 책을 읽고 나서 실무에서 바로 적용하고 싶은 것은 세 가지다. 첫째, AI가 만든 코드라도 설계 의도와 실패 가능성을 먼저 검토하기. 둘째, 기능 구현이 끝났다는 기준에 테스트와 운영 가능성을 포함하기. 셋째, 리팩토링을 미뤄도 되는 일이 아니라 제품 속도를 지키는 일로 보기. 개발자의 기본기는 시대가 바뀌어도 사라지지 않는다. 오히려 AI 시대에는 그 기본기가 더 선명한 차이를 만든다.