Skip to content

소프트웨어 아키텍처 the hard parts sprint 6 - 김종필#629

Open
jongfeel wants to merge 7 commits intomainfrom
625-소프트웨어-아키텍처-the-hard-parts-sprint-6-chapter-13-14-15-총-77-페이지-2026-03-20

Hidden character warning

The head ref may contain hidden characters: "625-\uc18c\ud504\ud2b8\uc6e8\uc5b4-\uc544\ud0a4\ud14d\ucc98-the-hard-parts-sprint-6-chapter-13-14-15-\ucd1d-77-\ud398\uc774\uc9c0-2026-03-20"
Open

소프트웨어 아키텍처 the hard parts sprint 6 - 김종필#629
jongfeel wants to merge 7 commits intomainfrom
625-소프트웨어-아키텍처-the-hard-parts-sprint-6-chapter-13-14-15-총-77-페이지-2026-03-20

Conversation

@jongfeel
Copy link
Member

의외로 chapter 14 부분이 어렵게 느껴졌습니다.
아무래도 마이크로서비스에서 운영 분석 데이터를 어떻게 가져와서 보여주면 좋을지에 대한 경험이 없어서 그런 것 같기도 합니다.

거의 세 달에 가까운 기간인데, 이 책을 읽고 여섯 번의 모임을 가져서 토론을 하는게
큰 의미를 가지고 있다고 보고 싶습니다.
AI가 코드를 짜주는 걸 적극적으로 사용해야 하는 시기
그리고 조직의 인력 규모와 소통 구조에 따라 마이크로서비스와 모놀리스의 경계를 오갈 수 있다는 건
이 모임에서 얻을 수 있는 좋은 통찰력이 아닌가 생각합니다.

Close #625

@jongfeel jongfeel self-assigned this Mar 18, 2026
@jongfeel jongfeel added 2026 Software Architecture: The Hard Parts 소프트웨어 아키텍처: The Hard Parts, 분산 아키텍처를 위한 모던 트레이드오프 분석 labels Mar 18, 2026
@github-actions
Copy link

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

이 PR은 "소프트웨어 아키텍처 the hard parts" 스터디의 여섯 번째 스프린트 결과물로, Chapter 13, 14, 15에 대한 개인적인 요약과 후기를 추가합니다. 특히 Chapter 14의 분석 데이터 관리 부분이 어렵게 느껴졌다는 점과 AI 시대에도 소프트웨어 아키텍처의 중요성에 대한 깊은 성찰이 담겨 있습니다. 이는 스터디를 통해 얻은 통찰력을 공유하고, AI와 아키텍처의 관계에 대한 논의를 촉발하는 데 목적이 있습니다.

Highlights

  • Chapter 13: Contracts (계약): 느슨한 계약의 필요성에 대한 의문과 컨슈머 주도 계약에 대한 추가 설명의 필요성을 언급했습니다.
  • Chapter 14: Managing Analytical Data (분석 데이터 관리): 대용량 운영 데이터 분석의 역사와 분산 환경에서의 접근법을 다루며, DPQ(Data Processing Queue)를 별도의 분석 서비스로 이해하는 후기를 작성했습니다.
  • Chapter 15: Build Your Own Trade-Off Analysis (트레이드오프 분석 구축): 소프트웨어 아키텍트의 역할과 AI 시대에도 아키텍처 결정의 중요성에 대한 통찰을 공유하고, AI 코딩 시대에 소프트웨어 아키텍처의 필요성에 대한 논의 주제를 제시했습니다.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

소프트웨어 아키텍처 책의 13, 14, 15장에 대한 요약과 생각을 담은 마크다운 파일들을 추가해주셨네요. 내용에 대한 깊은 고민이 느껴집니다. 몇몇 문장의 가독성을 높이고, 일반적인 파일 형식 관례를 따르도록 몇 가지 제안을 드립니다.

jongfeel and others added 4 commits March 20, 2026 12:37
…l/Chapter13_Contracts.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…l/Chapter14_Managing_Analytical_Data.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…l/Chapter15_Build_Your_Own_Trade-Off_Analysis.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…l/Chapter15_Build_Your_Own_Trade-Off_Analysis.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Comment on lines +21 to +24
개발자가 직접 코딩하지 않아도 되는 AI 바이브 코딩이 가능한 시기에도 소프트웨어 아키텍처는 필요한가? 에 대한 의문입니다.

=> 초기 PoC/프로토타입은 아키텍처가 없어도 되거나 AI가 제시해주는 모놀리스 기반의 통합 백엔드 프론트로 해도 문제는 없을 거라 생각합니다.
이제 바이브 코딩을 하는 사용자가 소프트웨어 관련 지식을 얼마나 학습하고, 이를 프롬프트로 지시하여 더 나은 결과물을 만들려는 의지를 가졌는지에 따라 차이가 발생할 것입니다. 여기서 개발자가 살아남아야 하는 이유를 찾을 수 있습니다. 개발자의 경쟁력은 단순히 코드를 작성하는 것을 넘어, 서비스를 기획하고 동작하는 소프트웨어를 만드는 능력에서 나옵니다. 더 나아가, 소프트웨어/컴퓨터 공학 지식을 바탕으로 주어진 상황에 최적화된 아키텍처 특성을 갖춘 소프트웨어를 설계하고 구현하는 능력이 핵심 경쟁력이 될 것이라고 생각합니다.
Copy link
Collaborator

@TaeHyoungKwon TaeHyoungKwon Mar 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

저도 비슷한 생각 입니다 소프트웨어 아키텍쳐는 바이브코딩할 때도 필요하고, 중요할 거 같습니다

AI agent 사용으로, 각 개발자의 코드 구현의 역량이 상향평준화 되었기 때문에, 코드 구현 역량을 제외한 나머지에서 개발자 간 차이가 발생할 것이라고 예상이 되는데요

그래서, 기존에도 중요했던, CS 지식들이나 설계, 아키텍쳐 역량 등이 훨씬 더 중요하게 되지 않을까 생각됩니다

과거에는 코드 설계와 구현 / CS 지식 / 아키텍쳐 역량 요렇게 크게 1/3 씩 개발자에게 중요했다면, 이제 코드 설계와 구현 대신에, AI Agent 활용(토큰 효율화, 멀티 에이전트 활용, 컨텍스트 최적화 등) / CS 지식 /아키텍쳐 역량 요렇게 중요하지 않을까 생각됩니다

그런 의미에서, 분산환경에서의 소프트웨어 아키텍쳐 트레이드오프에 대한 내용을 다루는 요번 책은 아키텍쳐 역량을 기르는데 굉장히 좋은 책이였다고 생각하고, 두고두고 보면 좋을 거 같다는 생각이 들었습니다

Comment on lines +21 to +24
개발자가 직접 코딩하지 않아도 되는 AI 바이브 코딩이 가능한 시기에도 소프트웨어 아키텍처는 필요한가? 에 대한 의문입니다.

=> 초기 PoC/프로토타입은 아키텍처가 없어도 되거나 AI가 제시해주는 모놀리스 기반의 통합 백엔드 프론트로 해도 문제는 없을 거라 생각합니다.
이제 바이브 코딩을 하는 사용자가 소프트웨어 관련 지식을 얼마나 학습하고, 이를 프롬프트로 지시하여 더 나은 결과물을 만들려는 의지를 가졌는지에 따라 차이가 발생할 것입니다. 여기서 개발자가 살아남아야 하는 이유를 찾을 수 있습니다. 개발자의 경쟁력은 단순히 코드를 작성하는 것을 넘어, 서비스를 기획하고 동작하는 소프트웨어를 만드는 능력에서 나옵니다. 더 나아가, 소프트웨어/컴퓨터 공학 지식을 바탕으로 주어진 상황에 최적화된 아키텍처 특성을 갖춘 소프트웨어를 설계하고 구현하는 능력이 핵심 경쟁력이 될 것이라고 생각합니다.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

아직까지는 AI 는 단순히 생각한 결과를 코드로 옮겨주는 도구일 뿐이고 (물론 AI 발전하는 속도를 보면 근미래에는 또 어떻게 될지 모르겠지만요)

코드를 정리하고 구조를 최적화하는 건 아직도 인간의 몫이 아닌가 라는 생각을 합니다

코드 구현은 이미 따라잡혓을지 몰라도 (그래서인지 신입 채용은 점점 불바다가 되고 있죠) AI는 도메인 지식을 엄청나게 잘 알고 있는 3년차 개발자고 나는 아직 그들을 통솔하는 오케스트레이터다 라는 느낌이라

소프트웨어의 핵심 설계와도 같은 부분은 아직 인간의 뇌가 많이 필요할 것으로 봅니다 ..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

2026 Software Architecture: The Hard Parts 소프트웨어 아키텍처: The Hard Parts, 분산 아키텍처를 위한 모던 트레이드오프 분석

Projects

None yet

Development

Successfully merging this pull request may close these issues.

<소프트웨어 아키텍처 The Hard Parts> sprint 6, chapter 13, 14, 15 총 77 페이지, 2026-03-20

3 participants