주말에 클린코드 책을 다시 처음부터 끝까지 읽었다. 대부분 내용이 Java 코드 예제이거나 시대가 지나며 불필요해진 내용도 있어, 적당히 건너뛰며 읽었더니 금방 읽었다. AI에 집중하는 시대에 갑자기 클린코드라니, 앞뒤가 맞지 않다고 느낄 수도 있을 것 같다. 하지만, 나는 아래와 같은 이유로 클린코드를 다시 한번 읽어야 한다고 생각했다.
AI의 한계
요즘 틈만 나면 AI를 어떻게 하면 더 잘 사용할 수 있을지를 연구했다. 실무, 사이드 프로젝트에서 다양한 시도를 해보고 다른 사람들은 어떻게 활용하는지 유튜브나 강연을 심심할 때마다 찾아봤다.
그러면서 AI가 잘하는 상황과 못하는 상황을 구분할 수 있게 되었다. 이는 생산성 향상에 많은 도움이 되었다.
AI를 이제 막 사용해 본 지 얼마 되지 않은 단계의 사람이라면 작은 결과물만 보고 AI를 찬양하는 경우가 많다. 사람의 특성답게 경험을 부풀려서 느끼고, 딸깍하면 모든 문제를 해결할 수 있을 것만 같은 감정을 느낀다. 하지만, AI를 어느 정도 사용해 본 사람들이라면 생각보다 만만치 않다는 것을 알고 있을 것이다.
우리가 가장 접하기 쉬운 유튜브나 AI를 이용한 강의를 보면 대다수가 1차원적인 product나 feature 단위에서 파워풀한 모습을 보여준다. 하지만, 복잡한 것은 시키지 않는다. 왜냐하면 항상 의도대로 동작하지 않기 때문이다.
실제로 우리가 다루는 대다수의 서비스들은 복잡도가 높다. 이렇게 복잡도가 높은 서비스에서 “AI가 알아서 다 해주겠지”라는 생각으로 무분별하게 사용해 버리면, 유지보수가 굉장히 어려운 ‘요구한 기능만 어떻게든 돌아가는’ 1회성 코드가 탄생해 버린다.
명확한 가이드라인을 작성할수록 의도한 결과에 가까운 품질이 나온다. 그럼에도 가독성이나 유지보수성, 최적화 측면에서는 아쉬움이 남는 것이 현실인 것 같다.
클린코드
그렇다고 AI를 사용하지 않을 수는 없다. AI를 이용해서 생산성 향상이 되는 것은 사실이기 때문이다.
그래서 나는 아키텍처 설계 같은 큰 틀은 내가 담당하고 AI를 국소적으로 이용하면서 추후 유지보수를 위해 다시 다듬는 작업을 하고 있다. 다시 클린코드 책을 보니 AI를 더 잘 사용하는 방법과도 긴밀한 관계가 있다는 생각이 들었다.
예를 들어, 한 파일은 가능한 작게 만들어야 한다. 가능한 작다는 뜻은 관심사가 명확히 분리되어 있을 가능성이 높은 코드임을 암시한다. 파일을 잘 나누었다면 AI에게 내가 의도한 프롬프트를 전달할 때 더 명확하게 읽어야 할 컨텍스트만 읽게 해서 토큰 소비를 줄일 수 있고, 결과적으로 속도나 답변 퀄리티를 향상시킬 수 있게 된다.
미래
미래에는 알고리즘이나 요구사항에 따른 기능 하나를 구현하는 코딩테스트보다는 AI에게 프롬프트를 어떻게 전달하고 다듬는 과정을 거쳐서 원하는 결과물을 얻는지를 더 보지 않을까 싶다.
근데 나는 세상의 문제나 사용자의 편의성을 해결하고 싶어서 개발자가 된 것도 있지만 직접 생각하고 코드로 풀어내서 해결했을 때 희열을 느끼는 것을 좋아했는데 가끔 AI가 너무 잘할 때 좋으면서도 조금 아쉽게 느껴지기도 한다
하지만, 그만큼 생산성이 올라갔기 때문에 AI가 잘하는 분야는 AI에게 맡기고, 나에게 강점이 있기도 하고 AI가 잘 못하는 분야인 UX적인 부분 같은 걸 신경 쓰면서 롱런할 수 있는 좋은 제품을 만드는 기쁨을 누려야겠다.