솔직히 말하자면: Claude Code를 위한 대부분의 '프롬프트 엔지니어링' 조언은 그냥 상식 수준의 기술을 포장한 것뿐임.

하하, 인정 😂 기술 업계의 절반은 일하는 곳마다 같은 걸 두고 다들 다른 용어를 쓴다는 걸 깨닫는 게 일이지.

메시지 구조는 특정 데이터 흐름에서의 스키마 같은 거고, 그걸 알려주는 온톨로지 같은 거지..

논리적 구성 요소는 마이크로서비스나 서비스 집합이 어떻게 작동하고, 어떤 결과물을 내기 위해 상호작용하는지를 보여주는 문서화된 요구사항 같은 거고.

나 스태프 엔지니어인데(내 회사 차리기 전까진 그랬음), 그런 표현 쓰는 사람 한 번도 못 봤음. 그냥 LLM이 지어낸 걸 사람들이 따라 하는 거 같은데 ㅋㅋ

ㅋㅋ 아니면 그냥 내가 멍청한 거거나. 기업 개발/IT 쪽 비개발자들 절대 무시하지 마라.

맞음, PO/BA 경험이 여기 아주 잘 적용될 거임. 모호한 목표를 명확한 요구사항, 제약 조건, 기대 결과로 바꾸는 법을 이미 알고 있으니까. 코딩 부분은 다를지 몰라도 소통 패턴은 기본적으로 똑같음.

정확함 😂 결국 '프롬프트 엔지니어링'은 사람들이 요구사항을 제대로 전달하는 법을 배우게끔 강제하는 것일지도 모르지.

맞음 ㅋㅋ '모델이랑 명확하게 대화하기'를 복잡한 방법론처럼 들리게 만들려는 유인이 분명히 있지. 20단계 워크플로우가 '좋은 맥락을 주고 원하는 걸 명확히 설명해라'보다 훨씬 있어 보이잖아.

그게 바로 내가 말하려던 경험이야. 이미 요구사항, 설계, 티켓, 검증 관점에서 생각하는 습관이 잡혀 있으면, 이런 '고급' 워크플로우들은 그냥 원래 자연스럽게 하던 일을 형식화해 놓은 것처럼 느껴지거든.

이게 기본적인 비즈니스 기술이라는 말은 맞음. 하지만 많은 사람이 비즈니스 환경에서 일해본 적이 없기 때문에, 이런 기술이 모두에게 상식인 건 아님.