✏️ [Spring Boot] 다중 인프라스트럭처 도메인 모듈 분리를 위한 리팩토링

[psychology50]

내용 (한줄 요약)

다중 인프라에 의존성을 갖던 도메인 모듈의 분리

예상 독자

프로젝트 멀티 모듈에 관심이 있는 개발자 및 기획자

블로그 링크

https://jaeseo0519.tistory.com/426

[youngsu5582]

안녕하세요 재서님~
고수라는건 들어서 알고 있었는데 상당하네요..! 🙂

아직 멀티모듈이나 MSA 적인 접근을 깊게 학습은 해보지 못했습니다.
그래서, 제가 백엔드 개발자지만 심도있는 리뷰나 대화는 못할거 같네요. ( 죄송합니당🥲 )

글을 읽으며 느낀점으론 어려운 내용이지만 2번~3번 정도 읽으니 이해될 정도로 잘 작성한거 같아요.
( 왜 멀티 모듈을 이렇게 분리했는지, 접근했는지 )

우아한 형제들 기술 블로그 내용에서 많이 차용 됐다고 느꼈는데
단순 링크만 있는게 아닌 기술 블로그의 내용이나 이를 보면 도움이 된다는 가이드라인을 줘도 괜찮을거 같습니당.

추가로, 왜 의존성 방향을 이렇게 잡을 수밖에 없었는지는 다음 다음 내용에서 다룰 예정
라는 내용이 있어서 그냥 다음도 아니고 다음 다음 이므로 다음에 다룰 내용에 대해 글 마무리에 남겨둬도 되지 않을까 싶었습니다.

---

�백엔드 개발자 적으로 봤을 때 중간중간 현재의 구조가 선택된 설명도 있어서 좋은거 같았습니다.
( redis 가 단순 cache 가 아니라 분산 을 위해서도 사용한다는 내용, domain-repository 를 만들지 않는 이유 등 )

정말정말 완벽한 아키텍처라면 분산 부분과 캐시 부분을 분리해서 분산은 client 로 둘거 같긴한데 그건 너무 귀찮을거 같네요 ㅋㅋ 🥲

좋은 인사이트 감사합니당 🫡

[psychology50]

우아한 형제들 기술 블로그 내용에서 많이 차용 됐다고 느꼈는데 단순 링크만 있는게 아닌 기술 블로그의 내용이나 이를 보면 도움이 된다는 가이드라인을 줘도 괜찮을거 같습니당.

추가로, 왜 의존성 방향을 이렇게 잡을 수밖에 없었는지는 다음 다음 내용에서 다룰 예정 라는 내용이 있어서 그냥 다음도 아니고 다음 다음 이므로 다음에 다룰 내용에 대해 글 마무리에 남겨둬도 되지 않을까 싶었습니다.

�백엔드 개발자 적으로 봤을 때 중간중간 현재의 구조가 선택된 설명도 있어서 좋은거 같았습니다. ( redis 가 단순 cache 가 아니라 분산 을 위해서도 사용한다는 내용, domain-repository 를 만들지 않는 이유 등 )

I'm not specialist lol. 😂
I think a review doesn’t necessarily need to focus on technical content.
After all, that's not the main purpose of this blogging study, so you can approach it with a relaxed mindset.
For me, just receiving your review is more than satisfying. 🤗

As you mentioned earlier, I agree with opinion that pointing out what to reference in a technical blog would be helpful.
However, there's a reason I didn't do that.
this post was written with a specific premise:

• Readers who have already read the previous posts
  • 멀티 모듈화 고찰, 도메인 비즈니스 규칙과 멀티 모듈 아키텍처 설계

But now that I think about it, readers encountering this post for the first time might find it confusing. 😂
So I agree with your suggestion to briefly add some context for clarity.

"The reason I had no choice but to design dependency directions will be addressed in the chapter after next".
I included this sentence because, when I read blog posts, I tend to skim for the parts I need. Haha.
Do you think this might have interrupted the reading flow?
I'm curious how readers would perceive this kind of note.

"I might divide the distribution part from the cache part, and then assign the distribution part to the client..."

This is a really interesting perspective, as I hadn’t thought about it that way!
However, since the caching itself is the literal purpose, I’ve been unsure whether it should belong to the domain module or remain in the infrastructure module.
And given that the scale of our project doesn’t require micro-level separation, I don’t plan to implement it right now.
Still, it’s an intriguing topic that could be fun to research further.

Thank you so much for the great feedback. :)

---

전 고수가 아닙니다. 😂
리뷰는 무리하게 기술적인 내용을 이야기해주지 않으셔도 된다고 생각해요.
애초에 이 블로그 스터디의 의의가 아님을 알고 있기에, 편한 마음으로 리뷰해주시면 될 거 같아요.
전 그저 리뷰를 받는 것만으로도 충분히 만족하고 있습니당. 🤗

말씀해주신 것처럼 기술 블로그의 어떤 점을 참고하는 지 알려주면 좀 더 도움이 될 거 같다고 생각이 드네요.
다만 제가 그렇게 하지 않았던 이유는 위 포스팅이 한 가지 전제를 두고 작성되었기 때문입니다.

• 이전에 작성한 두 포스팅을 읽었던 사람
  • 멀티 모듈화 고찰, 도메인 비즈니스 규칙과 멀티 모듈 아키텍처 설계

그러나 지금 생각해보면, 이 포스트를 처음 마주한 사람은 상당히 띠용스러울 수도 있겠다는 생각이 드네요. ㅎㅎ;
이 부분은 간략하게 나마 내용을 추가해두는 게 좋을 거 같다는 의견에 동의합니다.

왜 의존성 방향을 이렇게 잡을 수밖에 없었는지는 다음 다음 내용에서 다룰 예정 이 부분은 사실 제가 블로그 포스트를 볼 때, 필요한 부분만 빠르게 스캔하는 타입이라 적어놨어요. 허허.
읽는데 혹시 방해가 됐을까요??
실제로 읽는 사람 입장에서, 저런 포인트가 어떻게 받아들여질지 궁금하네요.

"분산 부분과 캐시 부분을 분리해서 분산은 client 로 둘거 같긴한데"

이 부분은 생각해보지 못 했던 관점이라 흥미롭네요.
다만 cache를 현재 domain에 두어야 할 지, 말 그대로 "캐싱" 자체의 목적 뿐이므로 infrastructure 모듈에 두어야 할 지 혼란스럽기도 하고,
프로젝트 규모가 그렇게 까지 세세하게 분리해야 할 정도는 아니라서 지금 당장 반영은 하지 않을 것 같습니다.
그래도 재밌는 관점인 거 같아서, 고민해보면 재밌을 거 같아요!

좋은 피드백 많이 주셔서 감사드립니다 :)

[youngsu5582]

넵 배려 감사합니다. 🫡

그러나 지금 생각해보면, 이 포스트를 처음 마주한 사람은 상당히 띠용스러울 수도 있겠다는 생각이 드네요. ㅎㅎ;

제가 생각한 부분도 이 부분입니다.
사람들이 무조건 내가 가리킨 방향대로 따라준다고 생각하기 어려운거 같아요. ( 애플리케이션 서비스든, 이력서든 모든게 )

그래서 명확하게 앞에서 명시(앞에 블로그를 안보면 어려움을 준다.) 를 해주거나 중간에 다시 간단한 설명 + 링크를 레퍼로 거는게 좋은거 같습니다.

왜 의존성 방향을 이렇게 잡을 수밖에 없었는지는 다음 다음 내용에서 다룰 예정 이 부분은 사실 제가 블로그 포스트를 볼 때, 필요한 부분만 빠르게 스캔하는 타입이라 적어놨어요. 허허.
읽는데 혹시 방해가 됐을까요??
실제로 읽는 사람 입장에서, 저런 포인트가 어떻게 받아들여질지 궁금하네요.

방해가 되진 않으나 그냥 다음 내용이 뭐길래 다음 다음일까? 나 시리즈의 방향성을 어떻게 이끌어 나가는거지? 에 대한 생각은 들었습니다.

다만 cache를 현재 domain에 두어야 할 지, 말 그대로 "캐싱" 자체의 목적 뿐이므로 infrastructure 모듈에 두어야 할 지 혼란스럽기도 하고,

저도 사실 cache 가 domain 인가? 에 대한 생각이 들어 질문하려고 했는데 기술 블로그에 위치한 이유를 보고 어느정도 납득은 했습니다.
트래픽이 증가할 때 차후 고려할 확정의 요소인거 같아요. ( 같은 레디스를 사용하는게 괜찮은가? 관점이 같은가? )

3개다 제 주관적인 의견입니당. 편하게 의견 더 남겨주셔도 좋습니당.
그리고, 보셨을거 같지만 위 기술 블로그와 비슷한 내용으로 [우아한테크세미나] 190829 우아한멀티모듈 by 우아한형제들 권용근님 영상도 있어서 남깁니다~ 🙂

[psychology50]

영어로 쓰면 시간이 너무 많이 소요돼서..한글로 ㅋㅋ

제가 생각한 부분도 이 부분입니다. 사람들이 무조건 내가 가리킨 방향대로 따라준다고 생각하기 어려운거 같아요. ( 애플리케이션 서비스든, 이력서든 모든게 )

그래서 명확하게 앞에서 명시(앞에 블로그를 안보면 어려움을 준다.) 를 해주거나 중간에 다시 간단한 설명 + 링크를 레퍼로 거는게 좋은거 같습니다.

한 가지 질문이 있어요!
제가 작성한 포스팅을 다시 읽어보니까, 하이퍼링크를 걸어두긴 했더라구요.
그래서 굳이 다시 설명하지 않은 건데 혹시 이걸 알고 계셨나요????

만약, 저기 하이퍼링크가 걸린 게 잘 안 보이는 거였다면 그 부분을 좀 더 명확히 표시하려고 하고,
내용이 부족한 거 같다고 하면 그 점을 보완하려고 여쭤봅니다. ㅎㅎ

저도 사실 cache 가 domain 인가? 에 대한 생각이 들어 질문하려고 했는데 기술 블로그에 위치한 이유를 보고 어느정도 납득은 했습니다. 트래픽이 증가할 때 차후 고려할 확정의 요소인거 같아요. ( 같은 레디스를 사용하는게 괜찮은가? 관점이 같은가? )

그쵸, 아무래도 지금 함부로 결정하기엔 오히려 더 부정적인 결과를 초래할 거 같아 일단 내버려뒀습니다.
cache면 무조건 infra로 분리하는 게 맞을 지, 전략에 따라 다르게 두어야 하는 게 맞을 지 앞으로 좀 더 고민해볼 숙제가 생겨서 즐겁네요.

혹시나 나름대로 깨닫는 게 있으면 공유드리도록 하겠습니다. 🤗

3개다 제 주관적인 의견입니당. 편하게 의견 더 남겨주셔도 좋습니당. 그리고, 보셨을거 같지만 위 기술 블로그와 비슷한 내용으로 [우아한테크세미나] 190829 우아한멀티모듈 by 우아한형제들 권용근님 영상도 있어서 남깁니다~ 🙂

영상 이미 봤던 거긴 한데, 당시에 인프콘 영상 두 개 보고 이거까지 보니 힘들어서 대충 봤던 거 같네요..ㅋㅋㅋㅋ
아무래도 다시 한 번 봐야겠습니다. 허허

[youngsu5582]

답변을 늦게 달았네용. 🥲 링크가 달려있는걸 보긴 했습니다만
이건 억까적인 요소긴 하나 이전에 대한 명확한 명시가 없으면 저는 내용에 포함된 모든 내용을 보지 않습니다.

제가 블로그 포스트를 볼 때, 필요한 부분만 빠르게 스캔하는 타입이라 적어놨어요. 허허.

이와 비슷하게 저는 하이퍼링크가 있어도 바로 그 내용을 보지 않는거 같아요.
( 기존 글을 보고 있는 컨텍스트가 벗어남 + 일반적으로 참고용 정보라고 생각 )

그렇기에 좀 더 명확한 명시나 설명을 말씀드렸습니다!

보지 않고 간단하게 설명을 통해 가능하다면 설명으로,
이 내용을 보고 이해하지 않으면 블로그 내용이 이해하기 어렵다면 링크에 대한 안내와 내용 정도..?
가 필요하다고 생각합니다.

p.s 특히, 어려운 내용의 연속일수록 이런 친절성은 필수적이라고 생각해용.
검색 엔진에 몇번째 글이 뜰지 예측하기 어려운데 시리즈로 묶거나 그 전 내용으로 유도를 하는게 중요한 거 같아서입니당. 🫡

이는 물론 제 개인적인 의견이니
가볍게 참고만 해주세용~

[psychology50]

아, 이게 아무래도 글을 작성할 때 "이 정도 토픽을 다루는 포스트를 찾아볼 정도면 기본은 다 알고 있는 사람들이겠지"라는 마인드가 기저 심리에 깔려있던 게 원인이 아닌가 싶네요 ㅎㅎ.

말씀하신 대로 간략하게 나마 안내를 하고, 더 자세히 이해하고 싶으면 링크를 타고 들어가도록 유도하는 게 더 좋을 거 같다고 생각이 드네요.

정말 좋은 피드백 감사드립니다!

[asuan99]

@psychology50
First of all, I think you wirte sentences neatly and help readers understand the content a lot through code and pictures, so I'll exclude these things like word or some suppliment from future reviews.

But, there is some interruptions in your post.
I felt like these breaks during previous review and I think I've found some reason why.

I think you have a habit of finishing sentence as a questions when introducing the motivations behind your content

Of course, the answer to question follows immediately, but there are stuctural transitions, such as moving to a different section. These transitions seems to dirupt the flow of the post.

It seems that readers may find it difficult to follow the flow of the content because they are prompted to think additionally while reading.

It's better to assume that the reader know less and write accordingly.
Of course, this doesn't mean that every piece of background knowledge needs to be explained in detail, but I hope to write in a way that eliminates the need for readers to make extra efforts to figure the flow of the post.

I recommand adding sentences like 'the answer to this question will be disscussed in [section/chapter]' to ensure the flow remains smooth and uninterrupted.

p.s A small tip regarding the color-coding in the first diagram: It's better to use darker colors to represent either the most important components (modules with many connections) or lower-level modules (those with less external exposure or higher hadware/database access).

---

우선, 글을 깔끔하게 잘 쓰시고, 코드나 그림을 통해서 보충 설명을 해주셔서, 이미 잘하고 계시니 이런 부분은 다음 리뷰부터는 지양하도록 하겠습니다.

하지만, 글에서 단절이 일어나는 느낌을 자주 받습니다.
이전 리뷰에서도 이렇게 흐름이 끊어지는 걸 느꼈는데, 그 이유를 조금 찾은 것 같네요.

제가 느끼기에는 재서님이 동기나 문제점을 설명할 때, 의문문으로 문장을 많이 끝내는 경향이 있는 것 같습니다.

물론, 의문에 대한 답이 바로 따라 나오지만, 다음 장으로 넘어간다 거나 하는 문제가 있어서 흐름을 끊어지게 하는 것 같네요.

독자가 글을 읽을 때 추가적인 생각을 하게 해서 내용의 흐름을 따라가기 어렵게 느껴지는 것 같습니다.

독자를 멍청하다고 생각하고 글을 써주는 게 좋겠네요. 물론 사전 지식 같은 부분까지 모두 상세히 설명할 필요는 없지만, 내 글의 흐름을 따라가기 위해 독자가 추가적으로 생각해서 흐름을 찾으려는 노력을 할 필요가 없게 글을 썼으면 하는 바람입니다.

개인적인 추천으로는 '이에 대한 부분은 2장에서 다룰 예정이다' 같은 문장을 추가해서 흐름을 유기적으로 표현하는 게 좋을 것 같습니다.

p.s. 처음 그림에서 보여주는 색상 표시에 대한 팁을 드리자면, 진한 색상을 우선적으로 중요한 부분(연결 고리가 많은 모듈) 또는 하위 레벨(외부에 노출이 적거나, 하드웨어에 접근이 많은 모듈)에 표시를 해주는 게 좋습니다.

[psychology50]

First of all, I think you wirte sentences neatly and help readers understand the content a lot through code and pictures, so I'll exclude these things like word or some suppliment from future reviews.

This improvement is thanks to your earlier feedback, so if I make any similar mistakes again, I’d appreciate you pointing them out!

I think you have a habit of finishing sentence as a questions when introducing the motivations behind your content

Of course, the answer to question follows immediately, but there are stuctural transitions, such as moving to a different section. These transitions seems to dirupt the flow of the post.

It seems that readers may find it difficult to follow the flow of the content because they are prompted to think additionally while reading.

It's better to assume that the reader know less and write accordingly. Of course, this doesn't mean that every piece of background knowledge needs to be explained in detail, but I hope to write in a way that eliminates the need for readers to make extra efforts to figure the flow of the post.

I recommand adding sentences like 'the answer to this question will be disscussed in [section/chapter]' to ensure the flow remains smooth and uninterrupted.

Actually, I intended that structure!
I wanted readers to think deeper because my posts might not always be entirely accurate.

Since my target audience already has some familiarity with these concepts, I hoped they’d question my content and engage in discussions.
(For introductory posts, I try to write in a more beginner-friendly way.)

After your feedback, though, I agree that providing a brief answer immediately after the question, followed by a pointer to the relevant section, might be better.

Here’s an example of what I plan to do now:

Is this approach correct?  

...

Technically, It's wrong because it's  

More details are discussed in `chapter 4-2`  

Would this improve the structure in your view?

p.s A small tip regarding the color-coding in the first diagram: It's better to use darker colors to represent either the most important components (modules with many connections) or lower-level modules (those with less external exposure or higher hadware/database access).

Sorry, I'm not sure I fully understood. 😅
Are you suggesting I use accent colors for important modules as a top priority and more neutral tones for less significant ones?

---

우선, 글을 깔끔하게 잘 쓰시고, 코드나 그림을 통해서 보충 설명을 해주셔서, 이미 잘하고 계시니 이런 부분은 다음 리뷰부터는 지양하도록 하겠습니다.

이것도 지난 리뷰 덕분에 개선될 수 있었던 부분이라, 혹시나 또 제가 실수를 범하면 말씀해주셨으면 합니다!

제가 느끼기에는 재서님이 동기나 문제점을 설명할 때, 의문문으로 문장을 많이 끝내는 경향이 있는 것 같습니다.

물론, 의문에 대한 답이 바로 따라 나오지만, 다음 장으로 넘어간다 거나 하는 문제가 있어서 흐름을 끊어지게 하는 것 같네요.

독자가 글을 읽을 때 추가적인 생각을 하게 해서 내용의 흐름을 따라가기 어렵게 느껴지는 것 같습니다.

독자를 멍청하다고 생각하고 글을 써주는 게 좋겠네요. 물론 사전 지식 같은 부분까지 모두 상세히 설명할 필요는 없지만, 내 글의 흐름을 따라가기 위해 독자가 추가적으로 생각해서 흐름을 찾으려는 노력을 할 필요가 없게 글을 썼으면 하는 바람입니다.

개인적인 추천으로는 '이에 대한 부분은 2장에서 다룰 예정이다' 같은 문장을 추가해서 흐름을 유기적으로 표현하는 게 좋을 것 같습니다.

사실 그걸 의도하긴 했습니다.
전 독자가 단순히 해답을 구하고 가는 것에 그치지 않고, 더 깊이 생각했으면 했습니다.
왜냐면 제가 봤을 때, 제 포스트는 정확하진 않다고 느꼈거든요. (언제나 틀릴 수 있다는 가능성을 둡니다.)
그리고 주 타겟층이 이미 이 개념에 어느정도 알고 있는 사람들이라서, 내용에 대한 의문이 드는 사람들과 토론을 바라고 이런 맥락 구성을 만들게 되었습니다.

그런데 지금 생각해보면, 대부분 빠른 정보 습득을 위해 오는 사람들이 대부분이라 무의미했을 거 같다는 생각이 들긴 하네요.
말씀하신 것처럼, 질문 바로 밑에 간략한 답을 적어두고, 다른 챕터에서 더 자세히 다룰 거라고 적어두는 게 나은 거 같아요.

이제부터, 다음과 같이 써보려고 합니다:

과연 이게 옳은 방식일까?

...

사실, 이것은 잘못된 방식이다.  
이유는 ~~~

더 자세한 내용은 `챕터 4-2`에서 다루겠다.  

리뷰어님이 보시기에 이런 구성이 좀 더 도움이 될 수 있을까요?

p.s. 처음 그림에서 보여주는 색상 표시에 대한 팁을 드리자면, 진한 색상을 우선적으로 중요한 부분(연결 고리가 많은 모듈) 또는 하위 레벨(외부에 노출이 적거나, 하드웨어에 접근이 많은 모듈)에 표시를 해주는 게 좋습니다.

정확히 이해하질 못했어요. 😅
중요한 모듈에 우선적으로 강조 색상을 주고, 이번 내용과 다소 무관한 부분에는 다른 색을 주라는 의미일까요?

[BangDori]

현재 프로젝트에 적용된 접근 방식의 문제점들을 명확히 인지한 후, 이를 리팩토링 전략에 따라 단계적으로 개선하는 과정이 매우 인상적이었습니다.

특히나 문제점들을 빨간 색상으로 처리해주신 덕분에 글을 읽는 독자들도 문제점들을 빠르게 인지할 수 있었고, Gradual Migration Plan에서 Migration Phase를 설정하고, 이번 마이그레이션의 목표를 명확히 정의하는 점은 저에게 큰 배움이 되었던 것 같습니다!

짱👍👍

---

글을 읽으면서 개인적으로 아쉬웠던 점이 한 가지 있었는데, Chapter 4와 5의 내용 전개 방식이 조금 아쉬웠던 것 같아요.

• Chapter 4: 전략 1, 2, 3을 차례로 소개.
• Chapter 5: 앞서 소개된 전략에 맞춰 순서대로 실행

현재 구조는 위와 같이 구성되어 있는데 다음과 같이 전략과 실행이 동시에 순차적으로 일어난다면 글을 읽기 조금 더 편했을 것 같아요.

• 전략 1 -> 실행
• 전략 2 -> 실행
• 전략 3 -> 실행

그리고 내용이 어렵다보니 제가 제시한 방향으로 내용이 구성된다면, 내용을 빠르게 이해하는데도 도움을 줄 것 같구요!

---

마지막으로 궁금한 점이 한가지 있습니다.

• Phase 1에서 기존 도메인 로직은 현상 유지. (비록 DDD를 어기더라도 감안한다)가 DDD 규칙을 어기더라도 Phase 2에서 점진적 마이그레이션을 통해 충분히 개선된다고 판단하여 이와 같이 작성하신 게 맞을까요?

[psychology50]

현재 구조는 위와 같이 구성되어 있는데 다음과 같이 전략과 실행이 동시에 순차적으로 일어난다면 글을 읽기 조금 더 편했을 것 같아요.

• 전략 1 -> 실행
• 전략 2 -> 실행
• 전략 3 -> 실행

제 공부 스타일이 큰 그림을 먼저 보고, 세부 규칙을 정하고, 실행으로 옮기는 주의라서 잘 안 맞을 수도 있다는 생각이 드네요.

사실 제 블로그는 "정보 공유"의 목적 보다는 "공부"를 위한 목적에 가깝기 때문입니다.
그냥 제가 공부하려고 포스팅 써놨는데, 너희도 보고 싶으면 봐~ 이런 느낌으로 쓰거든요.

전 블로그 포스트를 단순히 모든 작업이 끝나고 정리의 개념으로 사용하질 않다보니,
작업과 블로그 포스팅을 병행해서 진행합니다.

예를 들어, 리팩토링을 위해 개념과 설계를 우선 포스트로 작성해두고, 이를 기반으로 진행을 해보는 거죠.
그러다가 실패가 나면, 초기 설계 내용을 지우지 않고 시행 착오 기록을 작성합니다.

개인적으로 전 언제나 "큰 그림"을 우선 볼 수 있어야 한다고 생각하는 편이라, 취향 차이에서 비롯한 문제인 거 같기도 해요.

혹시 어떻게 생각하시나요??
솔직한 의견이 궁금합니다.

그리고 내용이 어렵다보니 제가 제시한 방향으로 내용이 구성된다면, 내용을 빠르게 이해하는데도 도움을 줄 것 같구요!

마지막으로 궁금한 점이 한가지 있습니다.

• Phase 1에서 기존 도메인 로직은 현상 유지. (비록 DDD를 어기더라도 감안한다)가 DDD 규칙을 어기더라도 Phase 2에서 점진적 마이그레이션을 통해 충분히 개선된다고 판단하여 이와 같이 작성하신 게 맞을까요?

넵, 이번 작업은 새로운 기능을 위한 구조적 개선이므로, 기존 기능에 최대한 영향을 주지 않는 범위 내에서 작업해야 합니다.
그래서 DDD 원칙을 어길 수밖에 없지만, 어차피 추후 개선 가능한 부분인 점도 있고 지금 한 번에 작업할 수 없는 양이라서 보류하는 겁니다.

[BangDori]

@psychology50

글을 작성하는 이유가 정보 공유가 아닌 학습이라면 재서님의 의견에 대해 전적으로 동의합니다.

하지만 실행 전략을 한 번에 작성하는 방식은 글을 읽는 사람에게는 정보의 과부하를 줄 수 있고, 글의 맥락을 쫓아가지 못하게 할 수도 있어요. 그렇기 때문에 만약 글의 목적이 학습뿐만 아니라 정보 �공유가 조금이라도 포함된다면, 실행 전략을 순차적으로 설명하면서 이 전략을 통해 어떤 개선이 이루어졌는지를 단계별로 보여주는 게 더 좋을 것 같아요. 이렇게 하면 독자들이 각 단계를 따라가며 재서님의 생각을 읽을 수 있게 될 것이고, 글의 응집성도 높아지게 될 것 같아요.

특히, 독자가 계속 위아래로 스크롤하며 앞부분을 참조하지 않아도 되는 방식이라 가독성 면에서도 큰 도움이 될 것 같아요! 😊

만약 이러한 방법이 재서님의 스타일에 맞지 않는다면, 실행 전략과 이행간의 연결고리를 만들어 주는 것도 좋을 것 같아요

[psychology50]

그렇기 때문에 만약 글의 목적이 학습뿐만 아니라 정보 �공유가 조금이라도 포함된다면, 실행 전략을 순차적으로 설명하면서 이 전략을 통해 어떤 개선이 이루어졌는지를 단계별로 보여주는 게 더 좋을 것 같아요. 이렇게 하면 독자들이 각 단계를 따라가며 재서님의 생각을 읽을 수 있게 될 것이고, 글의 응집성도 높아지게 될 것 같아요.

만약 이러한 방법이 재서님의 스타일에 맞지 않는다면, 실행 전략과 이행간의 연결고리를 만들어 주는 것도 좋을 것 같아요

되도록 읽는 사람이 편하도록 연결 고리를 맺는 것은 고민해보면 좋을 것 같긴 하나,
아무래도 우선순위가 타인 보다는 미래에 다시 읽을 저에게 있다 보니 구조 자체를 수정하긴 힘들 거 같습니다. ㅠㅠ

전부터 맥락이 끊어진다는 느낌을 받고 있다는 피드백이 있어서,
아마 이 부분을 개선하면 조금 나아질 수 있을 거 같은데,
신경 쓰면서 포스팅 해보도록 하겠습니다.

좋은 리뷰 감사드려용. :)