Skip to content

docs: 챕터 1, 2를 다듬어요. #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
azure-553 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: 챕터 1, 2를 다듬어요. #20

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 14 additions & 14 deletions docs/foundations/1-construction.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,9 +39,9 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';

## 📝 묶음 요약

1~4장은 "코딩을 시작하기 전에 무엇을 결정해야 하는가"를 네 각도로 조명하는 묶음이에요. 구현의 정의부터 비유, 사전 준비, 핵심 결정까지 따라가면, 2026년 FE 환경에서 무엇이 살아남고 무엇이 변형됐는지가 자연스럽게 드러나요.
1~4장은 "코딩을 시작하기 전에 무엇을 결정해야 하는가"를 네 관점에서 바라보는 묶음이에요. 구현의 정의부터 비유, 사전 준비, 핵심 결정까지 따라가면, 2026년 FE 환경에서 무엇이 살아남고 무엇이 변형됐는지 자연스럽게 드러나요.

- 1장 — "construction(구현)"은 AI가 코드를 대신 쓰는 시대에도 반드시 일어나는 활동이라 정의 자체는 유효해요.
- 1장 — "구현(Construction)"은 AI가 코드를 대신 쓰는 시대에도 반드시 일어나는 활동이라 정의 자체는 유효해요.
- 2장 — 소프트웨어를 다른 활동에 빗대는 사고법은 살아 있지만, McConnell의 건축·농사 비유는 FE의 반복 배포 환경과 잘 맞지 않아 새 비유가 필요해요.
- 3장 — "코딩 전 요구사항·아키텍처 점검"은 여전히 중요하지만, "100% 확정 후 시작"이 아니라 "불확실성 큰 부분부터 검증"으로 변형됐어요.
- 4장 — 언어·컨벤션·프레임워크를 의식적으로 고르라는 원칙은 TypeScript strict, 린터 룰, 프레임워크 선택이 프로젝트 운명을 가르는 FE에서 더 절실해요.
Expand All @@ -64,21 +64,21 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';

<Verdict
rating="🟢 생존"
rationale={`한 줄 근거: "construction은 소프트웨어 개발에서 유일하게 반드시 수행되는 활동이다"라는 정의는 AI가 코드를 생성하는 2026년에도 변하지 않아요 — 누가 쓰든, construction은 일어나요.`}
rationale={`한 줄 근거: "구현(Construction)은 소프트웨어 개발에서 유일하게 반드시 수행되는 활동이다"라는 정의는 AI가 코드를 생성하는 2026년에도 변하지 않아요 — 누가 쓰든, 구현(Construction)은 일어나요.`}
/>

### ✅ 체크리스트

- [ ] "construction"에 포함되는 활동(상세 설계, 코딩, 디버깅, 단위 테스트, 통합)이 팀 안에서 명확히 인식되고 있나요? "코딩만 construction"이라고 여기고 있지는 않나요?
- [ ] construction 외 활동(요구사항, 아키텍처, 프로젝트 관리)과의 경계를 팀원이 이해하고 있나요?
- [ ] "구현(Construction)"에 포함되는 활동(상세 설계, 코딩, 디버깅, 단위 테스트, 통합)이 팀 안에서 명확히 인식되고 있나요? "코딩만 construction"이라고 여기고 있지는 않나요?
- [ ] 구현(Construction) 외 활동(요구사항, 아키텍처, 프로젝트 관리)과의 경계를 팀원이 이해하고 있나요?

판정과 체크리스트가 정답은 아니에요. 같은 원칙을 뒤집어 보는 관점도 함께 담아둬요.

### 😈 Devil's Advocate

<DevilsAdvocate
author={`"Construction의 경계는 이미 흐려졌다"`}
argument={`"Construction의 경계는 이미 흐려졌다" — McConnell은 construction을 "상세 설계 + 코딩 + 디버깅 + 단위 테스트"로 정의하고, 요구사항이나 아키텍처와 구분한다. 깔끔한 분류지만, 2026년 FE 현실에서 이 경계는 흐릿하다. 컴포넌트를 만들면서 동시에 디자이너와 요구사항을 조율하고, PR을 올리면서 아키텍처를 바꾸고, 배포하면서 A/B 테스트로 요구사항을 검증한다. 활동들이 순차가 아니라 동시에 일어나는 환경에서, "construction은 여기서 시작하고 여기서 끝난다"는 구분이 실용적인 의미를 가지는지 질문할 수 있다. 오히려 "모든 활동이 construction 안에 녹아 있다"는 관점이 애자일 현실에 더 가까울 수 있다.`}
argument={`"Construction의 경계는 이미 흐려졌다" — McConnell은 구현(Construction)을 "상세 설계 + 코딩 + 디버깅 + 단위 테스트"로 정의하고, 요구사항이나 아키텍처와 구분한다. 깔끔한 분류지만, 2026년 FE 현실에서 이 경계는 흐릿하다. 컴포넌트를 만들면서 동시에 디자이너와 요구사항을 조율하고, PR을 올리면서 아키텍처를 바꾸고, 배포하면서 A/B 테스트로 요구사항을 검증한다. 활동들이 순차가 아니라 동시에 일어나는 환경에서, "구현(Construction)은 여기서 시작하고 여기서 끝난다"는 구분이 실용적인 의미를 가지는지 질문할 수 있다. 오히려 "모든 활동이 구현(Construction) 안에 녹아 있다"는 관점이 애자일 현실에 더 가까울 수 있다.`}
/>

## Chapter 2. Metaphors for a Richer Understanding of Software Development
Expand All @@ -87,13 +87,13 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';

**메타포는 알고리즘이 아니라 휴리스틱이에요**: 메타포는 답을 찾는 방법을 알려주는 도구이지, 답 자체를 알려주는 지도가 아니에요. 소프트웨어 개발에서 메타포를 쓴다는 건 탐조등처럼 문제를 비춰보는 것이지, 정해진 경로를 따르는 게 아니에요.

**"코드 쓰기(Writing)" 메타포의 한계**: 소프트웨어 개발을 편지 쓰기처럼 보는 관점은 계획 없이 앉아서 쓰고 수정하면 된다고 암시하는데, 이 비유는 소프트웨어의 협업적 성격과 출시 이후 지속되는 유지보수 비용을 설명하지 못해요.
**"코드 작성" 메타포의 한계**: 소프트웨어 개발을 편지 쓰기처럼 보는 관점은 계획 없이 앉아서 쓰고 수정하면 된다고 암시하는데, 이 비유는 소프트웨어의 협업적 성격과 출시 이후 지속되는 유지보수 비용을 설명하지 못해요.

**시스템 성장(Accretion) 메타포**: 소프트웨어를 굴조개가 진주를 만들듯 작은 단위로 조금씩 쌓아가는 방식으로 보는 관점이에요. McConnell은 이 메타포가 증분 개발의 본질을 가장 정확하게 포착한다고 봤어요.
**시스템 성장 메타포**: 소프트웨어를 굴조개가 진주를 만들듯 작은 단위로 조금씩 쌓아가는 방식으로 보는 관점이에요. McConnell은 이 메타포가 증분 개발의 본질을 가장 정확하게 포착한다고 봤어요.

**소프트웨어 건축(Building Construction) 메타포**: 규모가 커질수록 계획과 설계의 중요성이 달라진다는 점을 건축 비유로 설명해요. 개집을 짓는 것과 마천루를 짓는 것은 접근 방식 자체가 달라지듯이, 소규모와 대규모 소프트웨어 프로젝트도 필요한 준비의 수준이 근본적으로 다르다고 했어요.
**소프트웨어 건축 메타포**: 규모가 커질수록 계획과 설계의 중요성이 달라진다는 점을 건축 비유로 설명해요. 개집을 짓는 것과 마천루를 짓는 것은 접근 방식 자체가 달라지듯이, 소규모와 대규모 소프트웨어 프로젝트도 필요한 준비의 수준이 근본적으로 다르다고 했어요.

**지적 도구상자(Intellectual Toolbox) 메타포**: 숙련된 개발자는 단일 방법론에 종속되지 않고 상황에 맞는 기법을 선택할 줄 알아야 한다고 했어요. 어떤 방법론을 100% 따르면 그 방법론의 렌즈로만 세상을 보게 되어 더 나은 선택지를 놓칠 수 있어요.
**지적 도구상자 메타포**: 숙련된 개발자는 단일 방법론에 종속되지 않고 상황에 맞는 기법을 선택할 줄 알아야 한다고 했어요. 어떤 방법론을 100% 따르면 그 방법론의 렌즈로만 세상을 보게 되어 더 나은 선택지를 놓칠 수 있어요.

<Verdict
rating="🟡 변형"
Expand Down Expand Up @@ -135,7 +135,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';

### ✅ 체크리스트

- [ ] 코딩 시작 전에 "이 기능이 풀려는 문제가 무엇인가?"가 한 문장으로 정의되어 있나요? (problem definition)
- [ ] 코딩 시작 전에 "이 기능이 풀려는 문제가 무엇인가?"에 대해 한 문장으로 정의되어 있나요? (problem definition)
- [ ] 요구사항이 변경될 때 변경 비용을 인식하고 있나요? — "나중에 바꾸면 되지"로 넘기지 않고, 변경의 영향 범위를 먼저 파악하나요?
- [ ] 프로젝트 성격(반복적 vs 순차적)에 맞는 수준의 사전 준비를 하고 있나요? — MVP에 과도한 설계 문서를 쓰거나, 핵심 시스템에 설계 없이 바로 코딩하고 있지는 않나요?
- [ ] 아키텍처 결정(상태 관리 방식, API 레이어, 렌더링 전략)이 코딩 전에 합의되어 있나요?
Expand All @@ -155,7 +155,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';

**언어 선택이 생산성과 품질에 영향을 준다**: 익숙한 언어로 작업하는 프로그래머는 낯선 언어를 쓰는 경우보다 약 30% 더 생산적이고, 고수준 언어는 저수준 언어 대비 5~15배의 생산성·품질 향상 효과가 있어요.

**언어는 사고를 제약한다**: 프로그래밍 언어가 제공하는 어휘가 개발자가 표현할 수 있는 생각의 범위를 결정하며, 언어에 의해 제약받는 "언어 안에서 프로그래밍"이 아니라 언어를 도구로 쓰는 "언어를 향해 프로그래밍"을 지향해야 해요.
**언어는 사고를 제약한다**: 프로그래밍 언어가 제공하는 어휘가 개발자가 표현할 수 있는 생각의 범위를 결정하며, 언어에 의해 제약받는 "언어 안에서 프로그래밍"이 아니라 언어를 도구로 쓰는 "언어를 향한 프로그래밍"을 지향해야 해요.

**컨벤션은 구현 시작 전에 확정해야 한다**: 변수명, 클래스명, 루틴명, 포매팅, 주석 등의 코딩 컨벤션은 코드가 작성된 이후에 소급 적용하기가 거의 불가능하기 때문에, 구현에 들어가기 전에 팀 전체가 합의해야 해요.

Expand All @@ -174,7 +174,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
- 관련 ESLint: [`@typescript-eslint/no-explicit-any`](https://typescript-eslint.io/rules/no-explicit-any/)
- 관련 tsconfig: [`strict`](https://www.typescriptlang.org/tsconfig/#strict)
- [ ] 프레임워크(Next.js, Remix 등)를 의식적으로 선택했나요, 아니면 "다들 쓰니까"로 선택했나요?
- [ ] "언어 속으로 프로그래밍"하고 있나요? — TypeScript의 타입 시스템, React의 선언적 모델을 적극 활용하나요, 아니면 JavaScript 습관을 TypeScript 위에 얹고 있나요?
- [ ] "언어 안에서 프로그래밍"하고 있나요? — TypeScript의 타입 시스템, React의 선언적 모델을 적극 활용하나요, 아니면 JavaScript 습관을 TypeScript 위에 얹고 있나요?
- [ ] 팀의 코딩 컨벤션(네이밍, 파일 구조, import 순서 등)이 합의되어 있고, 자동 검사되나요?
- 관련 ESLint: [`@typescript-eslint/naming-convention`](https://typescript-eslint.io/rules/naming-convention/)
- 보조 ESLint: [`import/order`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/order.md)
Expand All @@ -197,7 +197,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
<MemberOpinion
author="Alice"
emoji="🐻"
opinion={`지금 요구사항을 정확히 해결하면서도 다음 변경에 무너지지 않는 코드를 만드는 것. 미래에 변경사항이 생겼을 때 쉽게 확장할 수 있는 구조를 만들되, 단순히 "확장 가능하게"가 아니라 현재 필요한 만큼만 적절히 추상화하는 균형 감각이 중요함. 설계와 구현은 섞여 있는 활동.
opinion={`지금 요구사항을 정확히 해결하면서도 다음 변경에 무너지지 않는 코드를 만드는 것. 미래에 변경사항이 생겼을 때 쉽게 확장할 수 있는 구조를 만들되, 단순히 "확장 가능하게"가 아니라 현재 필요한 만큼만 적절히 추상화하는 균형 감각이 중요함. 설계와 구현은 섞여 있는 활동임.

현업 경험: 어드민 MVP를 만들 때 기획자 없이 직접 기획·설계·구현을 모두 맡았는데, 코드 작성 시간보다 "이 기능이 사용자에게 어떤 흐름으로 보여야 하는가"를 정리하는 시간이 더 길었음.`}
experience=""
Expand Down
Loading