기술 설계에서 커리어 설계로 — 취업가, 연구자, 창업가

how-to-design-a-program-from-scratch|6단계 설계 프로세스는 기술에만 쓰이는 게 아니다. 요구사항 → 도메인 → 구조 → 분해 → 데이터 → 검증은 문제 해결의 일반적 구조이며, 기술이든 연구든 사업이든 달라지는 건 각 단계에서 다루는 대상이다.

세 경로에서 같은 구조

| 단계 | 취업가 | 연구자 | 창업가 | |---|---|---|---| | 요구사항 | 팀의 과제, 스펙 | 연구 질문 | 시장의 문제 | | 도메인 | 담당 기술 + 서비스 맥락 | 관련 연구 전체 (Literature) | 기술 + 시장 + 사람 | | 구조 | 모듈 설계 | 방법론 (Methodology) | 사업 모델 | | 분해 | PR 단위 작업 쪼개기 | 실험 계획 | 분기별 실행 계획 | | 데이터 | DB, 마이그레이션 | 메트릭, 베이스라인 | 재무 계획, KPI | | 검증 | 테스트, 코드 리뷰 | 실험 결과, 논문 | 매출, 사용자 반응 |

취업가 — 깊이 + 맥락

한 분야의 구현을 담당하면서, 전체 서비스에서의 위치를 이해한다.

핵심 역량: "왜 이렇게 만들었는가"를 설명하는 능력. 구현만 하면 주니어. 설계 결정의 근거를 설명할 수 있으면 시니어.

주니어: "Layered Architecture로 만들었습니다"
시니어: "개인용이라 Local-First, 규모가 작아서 Layered면 충분,
        v2 동기화 대비해서 DB 접근은 Repository로 격리"

설계 프로세스는 업무 설계와 커리어 설계로 확장된다:

• 업무: 스펙 파악 → 기존 코드 이해 → 수정 범위 결정 → PR 분할 → 테스트
• 커리어: 시장 역량 파악 → 기술 지도 이해 → T자형 전략 → 분기별 계획 → 포트폴리오

연구자 — 깊이 + 새로움

한 분야를 극도로 깊이 이해한 뒤, "구멍"을 찾아 새로운 것을 만든다.

핵심 역량: "왜 이 질문이 중요한가"와 "왜 기존 방법으로 안 되는가"를 설명하는 능력.

연구계획서는 사실 설계 문서다:

• 요구사항 = Research Question
• 도메인 = Literature Review (개념의 지도)
• 구조 = Methodology (새로운 프레임워크 제안)
• 분해 = Experimental Design
• 데이터 = 태스크, 메트릭, 베이스라인
• 검증 = 예상 결과 + 평가 방법

깊이만: "DQN은 이렇고 PPO는 이렇습니다"
연구자: "둘 다 ___에서 한계가 있고, 그 이유는 ___이며,
        이를 해결하면 ___가 가능합니다"

창업가 — 넓이 + 연결

모든 영역을 "충분히" 이해하면서, 하나의 가치로 연결한다: 기술, 시장, 사람, 자금.

핵심 역량: "기술적으로 가능한 것"과 "시장이 원하는 것"의 교차점.

사업계획서도 같은 구조:

• 요구사항 = Problem (시장의 문제)
• 도메인 = Market Analysis (시장의 개념 지도)
• 구조 = Business Model (수익 흐름의 구조)
• 분해 = Execution Plan (분기별 마일스톤)
• 데이터 = Financial Plan (추적할 숫자)
• 검증 = KPI, 마일스톤 달성 여부

확장하는 방법

1단계: 기술의 설계 프로세스를 체화한다 (코드에서 반복 → 사고 습관 형성)

2단계: 같은 구조를 다른 영역에 적용한다

• 기술 설계서 → 연구계획서 (같은 구조)
• 요구사항 분석 → 시장 분석 (같은 사고)
• 아키텍처 선택 → 사업 모델 선택 (구조 선택)

3단계: 영역 간 연결을 만든다

• "이 기술이 어떤 문제를 푸는가?" (기술 → 시장)
• "이 연구가 어떤 제품이 되는가?" (연구 → 사업)
• "이 사업에 어떤 기술이 필요한가?" (사업 → 기술)

근본: 도구는 달라져도 "복잡한 문제를 구조화하는 능력"은 같다. 기술의 설계 프로세스를 체화한 사람은, 그 사고 구조를 연구에도, 사업에도, 커리어에도 적용할 수 있다.