1/ ChatGPT와 같은 여러 AI 도구를 사용할 때 대충 질문해도 그럴듯한 답변이 나와서, 스스로 AI 도구를 잘 사용한다고 착각했었습니다. 그러나 정말 잘 활용하는 분들을 접하면서 그 차이를 절감하게 되었습니다. 그로 인해 여러 질문 프레임워크도 공부하고, AI 도구들의 동작원리에 관한 책들을 참고하여 읽고 활용하고 있습니다. 이번에는 다른 전문가들이 일반 회사 업무에 AI도구를 어떻게 활용하는지에 관한 책이 나와서 휘리릭 읽었습니다. 

이 정도 활용법을 사람에게 배우려면 커피나 식사라도 대접하면서 옆에서 어떻게 활용하는 방법을 지켜봐야 하겠지만, 책으로 나와있으니 편안하게  시원한 바람을 쐬면서 읽을 수 있었습니다. 주말에 다 읽었네요.

 

2/ 이번에 읽은 책은 골든래빗에서 나온 '이게 되네? 챗GTP' 입니다.  일반 사무 환경에서 GPT를 활용하는 프롬프팅 사례를 체계적으로 소개하고 있는 점이 인상적이었습니다. 다양한 실무 예시를 통해 GPT로 업무 효율성을 올릴 수 있는 방법을  구체적으로 설명하고 있어, 실질적인 도움이 되었습니다.

 

3/ 특히 유익했던 부분은 시장 분석 과정을 거쳐 최종 워드 보고서를 작성하는 예제였습니다. 이 책에서는 마크다운 파일을 작성한 후 이를 워드 파일로 변환하는 방법을 상세히 소개하고 있습니다. 데이터를 다루는 경우 구글 앱 스크립트를 만들어 활용하는 방식도 소개하고 있습니다. 어떤 방식으로 질문해야 하는지, 어떤 프롬프트를 입력해야 하는지에 대한 구체적인 설명이 담겨 있어 유용했습니다. (이런 책은 프롬프트가 중요해서 따로 정리해서 공유하진 않는게 맞는 것 같습니다.)

 

4/ 또한, GPT를 통해 원하는 정보를 효과적으로 얻기 위하여 질문하는 방향에 대해서도 인사이트를 얻을 수 있었습니다. 추상화된 골격을 만든 후, 추가 질문을 통해 그 안의 빈틈을 채워 나가는 방식이 효과적이라는 점을 다시 한번 느낄 수 있었습니다. 단순히 명령을 내리는 방식이 아닌, 적절한 질문을 통해 GPT의 잠재력을 최대한 이끌어내는 방식이 좋았습니다.

분석중이라는 메시지를 클릭할 생각을 못했는데, 눌렀을 때 짠 하고 파이썬 코드가 나와서 살짝 놀랬습니다. 분석이 들어가면 결국 파이썬 코드를 작성해서 결과를 얻는 것 같군요.

 

5/ AI로 부터 고급 결과를 얻으려면 고급 질문을 해야 하며, 이를 위해서는 관련 기반 지식을 잘 알고 있어야 합니다. 또한 충분히 관련된 배경 지식을 갖추고 있어야지만 비로소 AI의 답변이 적절한지 평가할 수 있습니다. 이 책의 끝 부분에 소개된 예제를 통해 학습의 진정한 의미는 결국 좋은 질문을 던지기 위한 것이라는 점을  새삼 또 한 번 느꼈습니다.

 

이게 되네? 챗 GPT. 약간의 오탈자나 이상한 부분이 있어 출판사에 제보했는데 확인후 2쇄에 반영해 주신답니다. 전체적인 총평은 5점 만점에 4점 정도 줄 수 있는 실용서적입니다. 

 

같은 출판사에서 펴낸 치즈님의 <AI페어프로그래밍>은 코파일럿을 개발 업무에 활용하기 위한 입문 서적이었다면, 이 책은 일반 업무에 활용하는 방법을 재미있게 소개하고 있습니다. 일독을 권하고, 계속 적용해 보려는 시도가 중요할 것 같습니다.

 

 

 

반응형

프로그래밍의 규칙/한빛미디어

 

재미있게 읽었다. 최종 평점은 5점 만점에 4점.서커펀치사의 고민과 해결방안으로써의 규칙을 통해 더 나은 개발 방법을 되돌아볼 수 있는 계기가 되었다. 일종의 서커펀치 게임 개발사의 모범사례(Best Practice) 모음집인 셈이다. 번역은 나쁘지는 않았다. 군데군데 좀 더 매끄러운 표현이 떠오르긴 했지만, 맥락을 이해하지 못할 정도는 아니었다. 역자분이 게임 업계의 경험이 있었다면 더 좋지 않았을까 하고 생각했다. 아주 획기적인 발상의 전환을 제공해준다거나 새로운 고민을 던져 주지는 않지만, 생각의 파편을 정리해 가면서 나만의 생각, 팀만의 생각을 만들어 갈 수 있는 좋은 텍스트북이라 생각된다. 

 

어쩌다 보니 최근 읽은 책들이 코드 리팩토링에 관한 내용을 많이 다루고 있다. 반쯤 읽다가 이 책 때문에 멈춘 길벗의  <읽기쉬운 코드>도 비슷한 내용이 겹친다. 상호 보완되는 측면이 있는데... 개인적으로는 C++을 예제로 삼은 '프로그래밍의 규칙'이 C#을 예제로 삼은 '읽기쉬운 코드'에 비해 좀 더 많이 와 닿은 측면도 있다.(하지만 일부에서는 Modern C++ 이후 해결방안이 나왔는데도 불구하고 예전 방식이 소개되어서 살짝 아쉽긴 했다. 역주라도 달렸으면 좋았을텐데.. 예를 들어 c++에는 선택적 인수가 없다고 적혀있는데 C++17부터는  std::optional을 통해  인수가 '존재하지 않음'을 표시해 줄 수 있다.) 다시 '읽기 쉬운 코드'로 복귀해서 읽어볼 생각이다.

 

차례를 다시 보니 순서대로 읽어도 되지만,  문제에 대한 이해 및 (저자의) 개선 방법, 코드 리뷰와 코드 문서화, 디버깅, 개발자의 편향성과 극복 방안으로 나눠서 읽어볼 수 있겠다. 물론 겹치는 영역도 많고, 임의로 내가 구분해 본 것이니, 참조만 하시고~.

문제를 바라보는 관점 규칙 1 최대한 단순하게, 그러나 너무 단순하지 않게
규칙 4 일반화에는 세 가지 사례가 필요하다
규칙 5 첫 번째 최적화 교훈: 최적화하지 말라
규칙 8 실행되지 않는 코드는 작동하지 않는다
규칙 10 복잡성을 격리하라
규칙 14 네 가지 맛의 코드
규칙 16 코드가 아닌 결과에서부터 작업하라
규칙 17 더 쉽게 해결되는 큰 문제도 더러 있다
코드 리뷰와 문서화 규칙 3 좋은 이름은 최고의 문서다
규칙 6 코드 리뷰의 세 가지 장점
규칙 9 요약 가능한 코드를 작성하라
규칙 12 큰 팀에는 강력한 컨벤션이 필요하다
규칙 18 코드가 스스로 이야기하게 하라
디버깅 규칙 2 버그는 전염된다
규칙 7 실패 케이스를 제거하라
규칙 13 산사태를 일으킨 조약돌을 찾으라
규칙 15 잡초를 뽑으라
규칙 19 평행 재작업
개발자의 편향성 규칙 11 두 배 좋은가
규칙 20 계산하라
규칙 21 때로는 못질을 해야 한다

 

 

내용들 하나하나가 재미있는 생각거리를 던져주었는데, 에필로그의 한 문단이 와 닿았다.

 

코드를 어떻게 작성할 지에 대한 아이디어를 정리했다면 팀은 훨씬 더 효율적으로 일할 수 있을 것... 규칙은 여러분의 논의를 구조적으로 만들어 주며, 코드를 어떻게 작성할 지에 관한 합의에 이르는 프레임워크를 제공할 수있다.
....
여러분이 하는 일이 서커펀치의 프로젝트와 성격이 많이 다르다면 어떤 규칙은 잘 맞지 않을 수 있다. 그렇다면 규칙을 따르지 마라. 교리가 아니라 유용한 규칙일 뿐이다. 하지만 수용하기 어렵더라도 규칙이 잘 맞을 가능성이 있다.

 

맞는 말이다. 모두 각각의 상황과 문제가 있으니, 최적의 답을 찾아가는 과정은 달라질 수 있다. 하지만 자신에게 불편함을 무의식적으로 피하는 개인들, 특히 개발자들의 편향을 인지하고, 그에 따라 유용성을 판단하여 수용 여부를 결정해야 한다.

대체로 저자의 주장에 공감하는 편인데. 특히 '너무 엄격하게 문제의 정의에 갇히지 말고, 오히려 문제를 단순화하면 솔루션을 단순화할 수 있다'거나 '코드에 기교를 부릴 수록 컴파일러는 우리가 의도하는 바를 알아내기 어렵다' 등의 문구에는 적극적으로 찬성할 수 밖에 없었다.

 

이 책은 팀의 문화를 만들어 가고 싶은 중니어 이상의 개발자 또는 팀장이라면 비판적인 시선을 가지고 읽어보면 좋은 내용이 많다. 

 

최근 한빛에서 나오는 몇몇 책들이 손에 쥐기 쉬운 크기로 나오는데, 개인적으로 마음에 든다. (Tidy First도 이 크기)

 

밑줄 친 문구들이 꽤 있지만, 몇개만 넘겨가면서 소개하면 다음과 같다.

  • 미래의 자신은 타인과 다를 바 없다.
  • 세상 모든 일이 그렇듯이 최고의 결과는 균형에서 비롯된다.... 불확실성에 대한 반응으로 자기 자신에게 편안한 결정을 내린다면 앞으로도 매번 같은 선택을 할 위험이 있다.
  • 로그 파일은 단순히 어떤 일이 있었는지만 기록하는 것이 아니라 해당 문제를 재현하는데 필요한 모든 데이터를 ㄷ담고 있어야 한다.
  • (훌륭한 프로그래머는 쉬운 문제든 어려운 문제든 쉽게 푼다.) 단순한 솔루션을 유지하는 스펙트럼이 얼마나 더 넓은가로 프로그래머의 수준을 평가할 수 있다. 훌륭한 프로그래머의 핵심 역량은 어려워 보이는 문제를 올바른 관점에서 바라보면 사실은 쉽다는 사실을 인식하는 능력이다.
  • 프로그래머는 대개 문제를 프로그래밍으로 해결하려는 편향이 있으나, 프로그래밍이 모든 문제의 올바른 해결책인 것은 아니다.
  • 대부분의 프로그래머는 장기적 이점보다 단기적 비용을 우선시하는 경향이 있고, 그래서 나중에 후회하는 경우가 많다. 올바른 문제 해결책을 알고있지만 작업량 때문에 주저하고 있다면 용기를 내서 작업을 진행하자.

 

반응형

+ Recent posts