어려운 내용을 쉽게 풀어서 다시 설명하는 것도 좋을 수 있지만, 대부분 공식 문서로 설명이 충분한 경우가 많으며, 오히려 무수히 생산되는 수많은 글마다 약간씩 다른 설명 때문에 혼란이 초래될 수 있습니다. 하지만 한 가지 주의해야 할 점은 그 밖의 주변 기술을 설명하는데도 신경을 많이 써야 한다는 것입니다. 교과서적으로 특정 기술들에 대한 일반적이 설명을 IT 제품 정보 담는 문서가 아니라면, 직면한 특정 상황과 문제를 부각하여 어떤 노력과 기술로 해당 문제를 풀었는지 설명하는 편이 좋습니다. '전(轉)' 부분은 글 전반에 퍼져있습니다. '승(承)' 부분은 '기(起)'에서 제기된 문제를 해결하기 위한 핵심 아이디어/기술을 이어서 설명하되, 깊은 내용을 포함하는 것이 좋습니다.
현재의 AI의 활용과 미래에 대한 내 생각
흔히들 기술 검토 - 개발자 용어로는 해딩, 혹은 삽질이라 불리는 그것 - 라 불리는 내가 모르는 남이 만든 것을 어떻게 쓰는지 알아내는 과정은 개발의 실력과 무관하게(전혀 무관한 것은 아니지만) 참으로 괴로운 과정입니다. 개발은 스택오버플로우와 구글링으로 만든다고 하는데 그 스택오버플로우와 구글에 나오지 않는 에러가 내 화면에 뜨고 있다고 상상해 보세요. 게임도 하는 사람이 많아야 공략이 다양하게 나오는데 나 혼자 하고 있다면 나는 문제를 발견할 때마다 누군가 참고할 수 있는 것도 없이 혼자서 해야겠죠. 이렇듯 기술 스택이라고 하는 것은 그 자체로 좋은 것보다 여럿이서 함께 써줘야 하는 것이기에 커뮤니티와 지원이 굉장히 중요합니다. 개인적으로 좋아했던 RxJS에도 범용적이고 강력한 기술 스택이긴 하나, 이 라이브러리의 학습 비용의 허들이 높은 관계로 특수한 기술로 치부되고 응용 방식과 사용 방식이 달라서 스스로 더 어렵게 만들어 널리 퍼지지 못하는 기술 스택이 되기도 합니