저라면 개인적으로 2안을 선택할 것 같습니다.

데이터 페칭 훅인 usePost는 Post 컴포넌트에서 분리가 가능해 보입니다. 만약 Post 컴포넌트를 다른 사용처에서 재사용 할 때 부모 컴포넌트에서 데이터를 이미 들고 있다면, username, comment, likeCount를 props로 주입해야 하는 경우가 생길 수 있겠다는 생각이 듭니다!

1. 컴포넌트 책임의 분리 관점

• 1안처럼 Post 컴포넌트 내부에서 usePost 훅을 사용하면 컴포넌트가 데이터 페칭과 표시 두 가지 책임을 모두 갖게 됩니다.
  단일 책임 원칙에 따르면 이러한 결합은 컴포넌트의 재사용성과 테스트 용이성을 저하시킬 수 있습니다.

2. 관심사의 분리

• Post 컴포넌트는 데이터를 어디서 가져오는지 알 필요가 없습니다. 단지 받은 데이터를 표시하는 역할만 하는게 맞다고 생각합니다.

3. OCP 준수를 위한 컴포넌트 설계

• OCP에 따르면, Post 컴포넌트는 데이터를 표시하는 기본 역할(닫힘)을 유지하면서도 다양한 데이터 소스나 컨텍스트에서 사용될 수 있도록(열림) 설계되어야 합니다.

이에 맞춰서 2안이 조금 더 유연한 사고 및 확장이 가능하다고 생각이 드네요!

저도 1안을 선호합니다.
위 글 "컴포넌트 책임/관심사" 내용을 보니 10년전 dan abramov 의 글Presentational and Container Components
이 떠오르네요.
(벌써 10년이나 됐다니.. 🤯)

react hook 이 나온뒤 dan abramov 는 아래 코멘트와 함께 글을 업데이트했습니다.

Update from 2019: I wrote this article a long time ago and my views have since evolved. In particular, I don’t suggest splitting your components like this anymore. If you find it natural in your codebase, this pattern can be handy. But I’ve seen it enforced without any necessity and with almost dogmatic fervor far too many times. The main reason I found it useful was because it let me separate complex stateful logic from other aspects of the component.Hooks let me do the same thing without an arbitrary division. This text is left intact for historical reasons but don’t take it too seriously.

2019 업데이트: 이 글은 오래전에 작성한 것이며, 그 이후 제 관점도 많이 바뀌었습니다. 특히, 이제는 컴포넌트를 이렇게 나누는 방식을 권장하지 않습니다. 만약 코드베이스에서 자연스럽게 느껴진다면 이 패턴이 유용할 수도 있지만, 불필요하게, 거의 독단적으로 강요되는 경우를 너무 많이 보았습니다. 이 방식을 유용하게 느낀 주된 이유는 복잡한 상태 로직을 컴포넌트의 다른 부분과 분리할 수 있었기 때문입니다. 하지만 Hooks를 사용하면 임의의 분리 없이도 같은 작업을 수행할 수 있습니다. 이 글은 역사적 이유로 그대로 남겨두었으니, 너무 진지하게 받아들이지 않으시길 바랍니다. (GPT 번역)

즉 Custom hook 으로 비즈니스 로직을 충분히 잘 분리하면 컴포넌트 하나에서 props 로 모두 내려주는것과 거의 동일하게 관심사가 분리된다고 생각해요

• Container component ~= Custom hook
• Presentational component ~=return 문 아래의 JSX

functionPost({ postId}:{postId:string}){const{ username, comment, likeCount}=usePost(postId);// <- Container component 의 역할// Presentational component 의 역할return(<div><h1>{username}</h1><p>{comment}</p><p>{likeCount}</p></div>);}

특히 swr, react-query 같은 data fetching, global state 역할을 어느정도 같이 할 수 있는 좋은 라이브러리를 많이 사용할 때에는 더욱 유용하다고 생각해요.

저는 배열을 순회하는 경우인지, 단일 컴포넌트를 렌더링하는 경우인지에 따라 데이터 전달 방식이 달라져야 한다고 생각합니다.

배열을 순회하는 경우에는, 데이터 페칭의 책임이 Posts(또는 PostList) 컴포넌트에 있다고 보기 때문에,
Post 목록을 렌더링할 때는 데이터를 prop으로 전달하는 방식을 선호합니다.

반면, Post 목록을 렌더링할 때 id만 전달하는 방식처럼 Post 컴포넌트 내부에서 데이터를 다시 가져오게 되면,
하나의 도메인 데이터에 대해 데이터 페칭용 hook과 id 기반으로 데이터를 추출하는 context hook 두 가지를 모두 관리해야 하므로,
오히려 복잡성이 증가할 수 있다고 생각합니다.

하지만 상세 페이지처럼 단일 컴포넌트를 렌더링하는 경우에는, id만 전달하고 내부에서 데이터를 조회하는 방식이 더 자연스럽게 느껴집니다. ( 해당 게시글 내의 댓글과 동일하게 생각합니다. )

약간React Server Component에서 Data Fetching을 어느 단계에서 해야 할 지 고민입니다랑 비슷한 고민으로 바라봤는데요!

저는 컴포넌트를 추상화하지 않아야 할 때, 즉부모 컴포넌트가 더 직접적인 제어권을 가져야 하는 상황 에서는 2안을 고려해볼 만하다고 생각해요.
ID만 전달하여 내부적으로 비즈니스 훅을 통해 데이터를 패칭하는 방식(1안)은 컴포넌트의 독립성을 높이지만, 코드를 읽는 사람이 데이터 흐름과 맥락을 파악하는 데 제약이 있다고 판단했어요.
예를 들어 여러 결합도가 있는 컴포넌트가 동일한 데이터를 다른 관점에서 표시하거나 조작해야 할 때 (하나의 데이터가 여러 View단을 거칠 때), 중앙에서 데이터를 관리하고 분배하는 것이 일관성을 유지하는 데 도움이 될 수도 있다는 생각은 듭니다.

다만 이 중앙에 배치하는 관점이@ysm-dev님이 언급해주셨듯이 훅이 도입된 이후로 컴포넌트 단위의 엄격한 Presentational-Container 패턴을 중시하지 않게 된 거 같아요. 컴포넌트 재사용성 관점에서 설계를 바라보는 경향을 데이터 패칭과 묶어서 바라보는 관점으로 바뀌어 가고 있다고 봅니다.

개인적으론 1번 방식을 선호합니다! 비즈니스 로직과 View 응집도를 부모단에서 관리하기보단 내부로 캡슐화 하는게 더 관리적인 측면에서 좋다고 느껴요. 2안을 사용한 컴포넌트를 수정한다면 어느 부모 컴포넌트까지 수정 범위에 들어가는지 판단하는 게 어려움을 느낀 적이 많았어요.

훅으로 관리하게 된다면 훨씬 수정하기에 쉬울 수 있습니다. 누구는 전역 상태로, 혹은 데이터 패칭을 묶어서 커스텀 훅을 만들어서 사용할 수도, 누구는 그냥 부모단에서 지역적인 Context 훅을 만들어 내려줄 수도 있구요. 어떤 방법을 쓰든 비즈니스 로직 자체가 훅에 묶여 관리되기에 이점이 있다 생각합니다.

다만 이제 구현할 당시의 유행하는 디자인 패턴도 어느 정도 영향이 있다 생각이 듭니다. 리액트의 자유분방함으로 인해 여러 패턴이 뜨고 지지만 또 몇 년 뒤엔 앵귤러처럼 엄격히 관심사를 분리하고 의존성을 주입하는 형태로 갈 수도 있으니까요!