neozest : neo+zest

출판사마다 고유의 특색이 있는데, 책만은 소프트웨어 개발 주기 전반에서 알아두어야할 지식에 관련된 책을 잘 출간한다는 개인적인 느낌이 있다. 지난번에 봤던 <AI프로젝트 성공을 위한 체크리스트>와 <개발자 온보딩 가이드>가 그랬다.

이번에 읽은 책은 <다시, 소프트웨어 엔지니어>인데, 너무 큰 기대를 해서일까.. 좋은 책이기는 하지만, 그렇다고 막 감동적이진 않았다. 아무래도 비슷한 류의 책들을 많이 읽었기 때문인 것 같다. 이 책을 읽으면서 계속 들었던 생각인데... <실용주의 프로그래머>를 소프트웨어 개발주기(SDLC)에 맞춰 좀 더 상세히 풀어쓴 느낌이었다. 그래도 개인적으로는 실용주의 프로그래머가 더 좋았다. :)

그냥 이 책이나 실용주의 프로그래머, 개발자 온보딩 가이드 중 한 권을 읽으면 될 것 같다.

• 만드는 애플리케이션이 어떤 문제를 해결하는지, 맥락과 제약조건은 무엇인지, 관련된 문제들은 무엇인지 등 문제 영역을 충분히 생각하는데 시간을 들이자. 
• 엔지니어는 현실적이고 무자비할정도로 실용적이어야 한다. 확장성은 중요하지만, 모든 애플리케이션이 인터넷 트래픽의 3분의 1을 감당해야 하는 것은 아니다.
• 실천법의 가치와 목적을 잊어서는 안된다. 만약 절차만을 형식적으로 따른다면 기대했던 이점을 얻지 못할 가능성이 높다.
• 목표는 최선의 해결책을 찾는 것이지 그것으로 개인의 가지 가치를 가늠하는 것이 아니다.
• 좋은 코드 작성은 지속적인 학습 과정이다. 지름길은 없다. 개발자로서 성장하고 싶다면 코드를 작성해야 한다.
• 다이어그램은 다른 사람들에게 무언가를 전달하는 것을 돕는게 핵심이다.
• 품질은 1회성 행위가 아니라 꾸준한 실천임을 잊지 말자.
• 문제는 반드시 일어나겠지만, 핵심 질문은 그 문제의 가시성을 어떻게 확보할 것인가이다.
• 소프트웨어 엔지니어로서 개발하게 될 가장 중요한 기술중 하나는 코드에 미치는 영향을 따져 근거있는 결정을 내리는 방법이다.
• 효율적인 데이터 접근이란 단순히 빠른 질의를 말하는 것이 아니라 애플리케이션의 전체 데이터 수명 주기를 이해하는 것
• 과거의 경험이 복잡한 상황을 헤쳐나가는데 도움이 되겠지만, 모든 애플리케이션은 저마다 다르다.
• 아키텍처에는 비판적 사고가 필요하다. 아키텍트는 주어진 프로젝트의 핵심 품질 속성을 파악하고 설계가 그 요구사항을 충족하게 만든다.
• 좋은 아키텍트는 프로젝트 기한을 지키면서도 할수 있는 최선의 결정을 내린다.
• 모놀리스는 유지보수가 불가능하다고 종종 비난받지만, 문제는 잘못 구조화된 시스템에 있지 전개 구성 방식에 있지 않다.
• 주의력은 귀한 자원이며 마냥 늘릴 수가 없다. 낭비하지 말자. 모든 것을 읽거나 보거나 들을 수는 없다. 선택해야만 한다.
• 배운 기술에는 각각 유효기간이 있다.개발자 언어를 사업의 언어로 번역하는 것은 연습이 필요한 중요한 기술이다. 청중을 파악하고 그에 맞게 메시지를 조정해야 한다
• 소프트웨어의 사업적 가치를 이해하고 명확히 하는 것도 중요
• 필요한 시간을 들이면 결국 전체 소요시간은 줄어든다.
• 자카르 직조기가 만들어지자 자신들이 알던 방식의 기술이 사라질 것으로 많은 사람들이 예측했다. 그러나 숙련된 장인들은 패턴 디자이너, 기계 운전자, 섬유 엔지니어로 거듭났다. 가장 크게 성공한 직공들은 전통 기술과 새로운 기술을 모두 이해한 이들이었다.
• (AI를 활용하여) 상투적 코드 작성에서 절약된 시간으로, 이제 중요한 전략적 결정들에 집중할수 있다. 

팀원들에게 AI 코딩 도구 활용법을 알려주고 싶은데, 마땅한 책이 없었습니다. 프롬프트 작성법을 다룬 책은 많고, AI 동작원리를 설명하는 책도 많은데, 정작 "개발자가 일상 업무에서 어떻게 쓸 것인가"를 다룬 책은 찾기 어려웠습니다. 그러다 발견한 책이 <개발자를 위한 생성형 AI 활용 가이드>(길벗, 핫토리 유우키 저)입니다.

한마디로 요약하면 챗팅 형태의 AI 활용을 고민하는 개발자라면 읽어보는 것이 좋겠습니다. 또한 팀 전체의 AI 코딩 활용을 고민하는 관리자에게도 유용합니다. Neo의 평점은 별 네 개. 일본서 특유의 느낌이 있습니다. 앞에서 읽었던 <바이브코딩 너머 개발자 생존법>은 전체 프로세스를 중심에 놓고 이야기를 풀어가는 반면, <개발자를 위한 생성형AI 활용 가이드>는 지금 당장 써먹을 수 있는 활용방안을 배경지식과 함께 정리해 소개합니다.

이 책의 장점은 개발자 관점에서 코딩 AI를 제대로 활용하기 위해 알아야할 것을 모두 모아두었다는 점입니다. 앞부분에서는 AI가 소프트웨어 개발 프로세스를 어떻게 바꾸고 있는지를 소개하면서 개발과정에서 프롬프트를 작성하는 방법을 자세히 소개합니다. 이 과정에서 단순히 프롬프트 작성만 알려주는 것이 아니라 개발 업무의 특성은 이러한데 생성형 AI는 이렇게 동작하니까 프롬프트를 이렇게 활용해 보세요라는 내용이 많은 것이 마음에 들었습니다.(예: BUD프레임워크를 활용한 코드 최적화. BUD 프레임워크: Bottleneck, Unnecessary, Duplicated )

또한 AI와의 협업을 전제로 코드 구성요소의 역할 변경도 생각해 볼 거리인 것 같습니다. 예를 들어 저자는 AI가 해석할 수 없는 부분이나 토큰을 낭비할 수 있는 부분에 초점을 맞춰 주석을 작성하는 것이 효과적이라고 이야기합니다. 또한 의도 전달에 치우쳐 너무 많은 맥락을 제공하여 혼선이 유발될 수 있으니 적절한 수준을 유지하라는 조언도 도움이 되었습니다. 결국 AI와의 협업을 바탕에 깔고 어떻게 하면 우리의 의도를 잘 전달하여 AI에게 일을 시킬까에 대한 저자의 고민과 나름의 해결방안이 정리되어 있습니다.  

7장과 9장의 내용은 코딩 AI를 팀 개발 프로세스에 어떻게 녹여내고, 그 효과나 성과를 어떻게 측정할 것인지에 대해 고민하는 팀장들에게 몇 가지 키워드를 알려주는 내용이 들어 있습니다.(Four Keys, SPACE 프레임워크등, 짤막하게 소개가 되어 있습니다.) 그리고 어떤 식으로 팀에 도입해야 하는지에 대한 저자의 생각도 살짝 엿들을 수 있습니다.

책 읽으면서 몇가지 밑줄 친 부분은 다음과 같습니다.

프롬프팅 기법에만 집착하면 본질적인 문제 해결 능력이라는 관점을 잃어버릴 수 있습니다.(p.38)

프롬프트를 작성할 때 가장 중요한 것은 AI에 원하는 답을 자신이 이해하고 있어야 한다는 것입니다. 완벽한 답을 알지 못하더라도, 문제해결의 접근 방식을 파악하고, AI의 도움 없이도 해결책을 도출할 수 있는 상태가 이상적입니다.(p.92)

예측할 수 있고 신뢰성이 높은 코드를 생성하려면 개발자는 이러한 언어의 특성을 이해하고 있어야 하며, AI에 적절한 프롬프트를 제공하는 것이 중요합니다.(p.168)

AI에 모든 것을 맡기거나 제대로 활용하지 않고 반복적으로 AI에만 요구하기 보다는 필요한 부분에서는 인간의 판단을 개입시키는 것이 AI를 활용한 코드 개선의 핵심입니다. (p.187)

AI는 아이디어를 발산하는데는 능하지만, 수렴시키는 것은 서툽니다. 수렴에는 의사결정이 따르고, 책임이 수반됩니다. 언제나 최종적으로 책임을 지는 것은 인간입니다.(p.231)

조직의 경쟁력을 높이기 위해서는 '사람에게 의존하는 AI 활용'수준을 넘어서야 합니다. 이러한 문제를 해결하려면 조직 자체의 구조와 방식을 재검토해야 하고, 뛰어난 개인과 팀의 지식을 AI가 제대로 활용할 수 있는 환경을 만드는 것이 경쟁력향상의 핵심입니다. (p.281)