한빛미디어

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

30%에 대한 이야기 입니다. 이 책에서 저자는 AI로 아무리 자동화를 한다고 해도 결국 30%는 인간이 개발 해야 한다고 말하고 있습니다. 물론 미래에는 그 비율이 줄어들 수도 있겠지만, 그게 0%가 되지 않을거라 단언합니다.

저자의 주장은 저도 상당히 공감하는 데요. 저도 비슷한 이야기를 꾸준히 해왔기 때문입니다.

​

전체 작업의 70%는 보통 정형화된 부분으로, 이미 확립된 개발 방식과 일반적인 프레임워크를 따릅니다. 해커뉴스의 어느 댓글 작성자가 지적하였듯 AI는 소프트웨어 개발 과정에서 반복적이고 기계적인 작업의 '우발적 복잡성'을 탁월하게 처리하지만, 문제 자체가 가진 복잡성을 파악하고 관리하는 '본질적 복잡성'을 처리하는 건 여전히 사람입니다. 프레드 브룩스의 표현을 빌지자면 AI는 개발 과정에서 발생하는 부수적인 어려움은 해결하지만, 본질적인 난관은 해결하지 못합니다.

본문 103 페이지

<프로그래머의 길 멘토에게 묻다>의 저자들은 "프레드 브룩스", "스티브 맥코넬", "켄트 벡"에 대해 "이들이 쓴 책에서 얻을 수 있는 방대한 지혜는 대역폭이 더 큰 정보로도 대신할 수 없다"라고 말했습니다. 프레드 브룩스는 IT 역사상 가장 통찰력있는 책인 <맨먼스 미신>을 썼는데요. 이 책은 무려 50년전에 출간된 책입니다. 1995년에 20주년 기념판이 나왔는데 여기엔 1986년에 프레드 브룩스가 발표한 논문인 <은총알은 없다>라는 논문이 포함되었습니다. <은총알은 없다>에서 브룩스는 소프트웨어 개발을 두가지 차원으로 분리했는데요. 그것이 바로 "본질적 복잡성"과 "우발적 복잡성" 입니다. ( 제가 읽었던 <맨먼스 미신> 번역본에서는 "본질적 작업(essential task)"와 "부차적 작업(accidental task)"이라 표현됩니다. )

본질적 복잡성은 소프트웨어 구조를 다루고 근원적인 문제를 해결해가는 부분이고 우발적 복잡성을 이를 구현해 나가는 부분입니다. 브룩스는 소프트웨어 개발 도구들은 모두 본질적 복잡성을 해결하기 위해 발전하는게 아니라 우발적 복잡성을 해결하기 위해 발전해 왔기 때문에 소프트웨어 개발이라는 끔찍한 문제를 한방에 해결할 수 있는 해결 방법은 나올 수 없다고 했습니다. 그래서 논문 제목이 "은총알은 없다"였죠. 늑대인간 괴물을 한방에 죽일 수 있는 은총알 같은 해결방법이 소프트웨어 개발에는 있을 수 없다는 것인데요. <바이브 코딩 너무 개발자 생존법>의 저자는 AI도구도 결국은 "우발적 복잡성"을 해소하는 도구일 뿐이라 설명하는 것입니다.

​

이를 무시하고 AI에 지나치게 의존하는 작업을 하다 보면, '모래성' 같은 소프트웨어가 될 거라고 말하는데요. 이런 모래성 구조는 '외부의 압력이 증가하면 쉽게 붕괴'하게 됩니다.

​

그래서, "AI를 당신을 대체할 존재가 아닌 인턴 정도로 여기세요"라고 주문하고 있습니다. 뭘 시키던 제대로 했는지 확인해야하고 개발자 의도에 따라서 소프트웨어 개발을 이끌어가야 한다고 "의도 중심 프로그래밍"이라 정의합니다.

1단계: 원하는 바를 설명합니다.

2단계: AI가 초기 코드를 제안합니다

3단계: 코드 리뷰와 테스트를 진행합니다.

4단계: 요청이나 코드를 개선합니다.

5단계: AI가 설루션을 개선합니다.

6단계: 필요한 만큼 반복합니다.

본문 43 페이지

문제 해결에 AI를 '페어 프로그래머'로 활용한다.

본문 105 페이지

페어 프로그래밍 또는 짝 프로그래밍은 두 사람이 함께 코딩을 하는 애자일의 실천법 중에 하나입니다. 로버트 C 마틴은 <소프트웨어 장인 정신 이야기>에서 짝 프로그래밍을 할 때 혼자 작업할 때보다 오히려 업무 효율이 증가된 실험 결과를 보여주고 있는데요. 두 사람이 따로 작업해서 일의 효율이 절반으로 줄어들 것이라는 예상할 수 있지만, 예상과는 다르게 15%정도만 줄었고, 결함을 15%적게 기능 구현에 필요한 코드도 15%줄여서 오히려 더 좋은 결과가 나왔다고 합니다.

짝 프로그래밍을 하면 '드라이버'와 '네비게이터'로 역할을 나눠서 작업하게 되는데요. 드라이버는 코딩을, 네비게이터는 소프트웨어의 구조와 같이 세세한 구현외에 부분을 보게 됩니다. 이 두가지 일은 우리 뇌가 다루는 방식이 다르기 때문에 코드로 세세한 부분을 구현하는 과정에서는 소프트웨어 구조를 보기 힘들고 소프트웨어 구조를 보고 지도를 보듯 그림을 만들어 가는 과정에서는 세세한 구현 부분을 보기 힘듭니다. 혼자서 코딩하다보면 이 두가지 일을 컨텍스트 스위칭하며 봐야 하기 때문에 놓치는 부분이 생기는 거죠. 그래서 결함도 늘고 코드도 장황하게 되는 것입니다. 짝 프로그래밍을 하면 이 두가지 차원의 일을 나눠서 할 수 있으니까 더 좋은 코드를 작성하게 되고요.

​

그럼 드라이버 일을 AI에게 맡기면 어떻게 될까요? 저자는 드라이버를 AI에게 맡기는 걸 말하고 있습니다. 그럼 사람은 소프트웨어 구조와 같은 "본질적 복잡성"을 더 고민할 수 있게 되는 것이죠. 물론, 현재 AI는 완벽한 드라이버 역할을 수행할 수는 없습니다. 앞으로 나아지겠죠.

​

이제, 변화된 AI 세상에서 개발자가 AI를 어떻게 사용해야 하는지 이해할 필요가 있는데요. 저자는 그 부분도 꼼꼼하게 다루고 있습니다. 프롬프트, 툴, 신뢰성, 윤리적 관점 그리고 최근 부상하고 있는 AI 에이전트로 개발하는 방식에 대해서도 어느 하나 놓치지 않고 모두 설명하고 있네요.

​

개발자 입장에서 요즘은 AI 활용에 대해 다양한 압박을 받게 되는 상황에 놓여 있습니다. 때문에 이를 위한 다양한 책들도 나와있는데요. 이 책은 방향성 부터 세세한 내용들까지 모두 공감 되어서, AI 활용에 대한 압박을 이겨내는데 크게 도움이 될만한 책인것 같습니다.