일본의 개발 프로세스

일본에서 취업을 준비하다 보면 개발 자체보다 그 전에 요구되는 문서와 절차가 훨씬 길고 복잡하다는 느낌을 받기 쉽다. 일본 기업은 업종과 규모에 따라 차이가 있지만, 대체로 기획 → 요구 정의 → 기본 설계 → 상세 설계 → 구현 → 테스트 → 릴리스/운용 순으로 물 흐르듯 내려가는 프로세스를 중시한다.

일본 SI/서비스 조직

• 上流工程（じょうりゅうこうてい, 상류 공정）: 기획, 요구 정의, 기본 설계처럼 고객과 사양을 합의하는 단계다. PM/컨설턴트/시스템 엔지니어(SE)가 중심이 된다.
• 下流工程（かりゅうこうてい, 하류 공정）: 상세 설계 이후의 구현, 테스트, 릴리스 단계다. 프로그래머(PG), 테스터, 운영 팀이 주도한다.
• 一次請け（いちじうけ, 1차도급） / 二次請け（にじうけ, 2차도급）: 발주사 바로 아래(1차), 그 아래(2차) 등 다단계 하청 구조가 흔해 문서와 승인 절차가 많다.

단계별 흐름과 핵심 산출물

1. 기획・企画（きかく）フェーズ

• 기업 내부의 企画書（きかくしょ, 기획서） 혹은 PoC 검토에서 시작한다.
• 경영진 승인(稟議（りんぎ, 품의）)을 받아야 다음 단계로 넘어가는 경우가 많다.
• 페르소나/시장조사 문서, 예상 비용 산출(概算見積もり（がいさんみつもり）)이 이 시점에 정리된다.

2. 요구 정의・要件定義（ようけんていぎ）

• 고객/사업부와 機能要件（きのうようけん, 기능요구사항）, 非機能要件（ひきのうようけん, 비기능요구사항）을 문서화한다.
• 산출물: 要件定義書（ようけんていぎしょ, 요구정의서）, 業務フロー図（ぎょうむフローず, 업무흐름도）, システム構成図（システムこうせいず, 시스템구성도）, RASIC(역할 분담표) 등이 대표적이다.
• 이 단계에서 승인 도장을 받아야 예산과 일정이 확정된다.

3. 기본 설계・基本設計（きほんせっけい）

• 요구사항을 화면/모듈/데이터 흐름 단위로 구체화한다.
• 산출물: 画面設計書（がめんせっけいしょ, 화면설계서）, API一覧（APIいちらん, API 목록）, ER図（ERず, ER도）, インタフェース仕様書（インタフェースしようしょ, 인터페이스 사양서）.
• 여기서 設計レビュー（せっけいレビュー, 설계리뷰）라는 품질 게이트를 통과해야 다음으로 이동한다.

4. 상세 설계・詳細設計（しょうさいせっけい）

• 클래스, 시퀀스, 상태 전이, 예외 처리까지 코드 레벨에 가까운 구체화를 한다.
• 산출물: プログラム設計書（プログラムせっけいしょ, 프로그램설계서）, テーブル定義書（テーブルていぎしょ, 테이블정의서）, バッチ仕様書（バッチしようしょ, 배치사양서）, テスト項目書（テストこうもくしょ, 테스트항목） 초안.
• 이 단계까지를 製造（せいぞう, 제조, 구현） 전에 끝내는 것이 특징이다.

5. 구현・製造（せいぞう）

• 상세 설계서를 기준으로 코드를 작성한다.
• 개발자는 レビュー記録（レビューきろく, 리뷰기록）을 남기고, バージョン管理計画（バージョンかんりけいかく, 버전관리계획）에 따라 병합한다.
• 외부 협력사일 경우 納品物（のうひんぶつ, 납품물, 산출물） 형식으로 소스와 문서를 함께 제출한다.

6. 테스트・試験工程（しけんこうてい）

• 단위 테스트・単体テスト（たんたいてすと）: 개발자가 작성하고 UT手順書（UTてじゅんしょ, UT절차서）/エビデンス를 남긴 뒤 서명(承認（しょうにん）)을 받는다.
• 결합 테스트・結合テスト（けつごうテスト）: 모듈/시스템 간 연계를 검증하고 I/F確認書（I/Fかくにんしょ, I/F확인서）를 활용한다.
• 종합 테스트・総合テスト（そうごうテスト）/システムテスト: 실제 운영 시나리오로 QA 팀이 검증한다.
• 사용자 테스트・受入テスト（うけいれテスト）: 발주사 측 담당자가 승인 도장을 찍어야 릴리스가 가능하다.

7. 릴리스・運用保守（うんようほしゅ）

• リリース判定会議（リリースはんていかいぎ, 릴리즈 판정회의）에서 품질/리스크를 최종 점검한다.
• 릴리스 후 運用設計書（うんようせっけいしょ, 운영설계서）, 監視設計（かんしせっけい, 감시설계）, 障害対応フロー（しょうがいたいおうフロー, 장애대응플로우）를 공유한다.
• 이후에는 定例報告（ていれいほうこく, 정기보고）, 障害報告書（しょうがいほうこくしょ, 장애보고서） 작성 문화가 있다.

자주 등장하는 문서와 승인 흐름

• 稟議（りんぎ, 품의）: 내부 결재 라우팅이다. 담당 → 팀장 → 부장 → 임원 순으로 도장(押印（おういん）)이나 전자 승인을 거친다.
• 議事録（ぎじろく, 의사록）: 회의 후 즉시 공유하는 회의록이다. 책임 소재를 명확히 하기 위한 필수 문서다.
• 成果物チェックリスト（せいかぶつチェックリスト, 성과물체크리스트）: 각 단계별 산출물이 모두 준비됐는지 체크하는 표다.
• 品質ゲート（ひんしつゲート, 품질게이트）: 각 단계의 리뷰/승인을 통과해야 다음 단계로 갈 수 있는 구조다. 품질 관리부(QA)가 별도로 존재하기도 한다.

왜 문서가 이렇게 많은가?

• 다층 하청 구조: 발주사의 요구가 3~4차 업체까지 내려가도 정보가 손실되지 않도록 문서를 강조한다.
• 합의 문화・合意形成（ごういけいせい）: 다양한 이해관계자와 사전에 의견을 맞추는 根回し（ねまわし, 사전교섭） 문화 때문에 문서 초안 공유 → 피드백 → 승인 프로세스가 반복된다.
• 감사/보증 요구: 금융, 공공 도메인은 ISO/JIS 감사 대응을 위해 프로세스 증적이 필요하다.

알아두면 좋은 것들

• 報連相（ほうれんそう, 보고,연락,상담）: 보고・연락・상담을 자주 하고, 문서/챗 기록으로 남기면 신뢰도가 올라간다.
• 용어 세트 외우기: 上流工程（じょうりゅうこうてい, 상류공정）, 要件（ようけん, 요구사항）, 課題（かだい, 과제）, 懸念（けねん, 우려, 걱정）, 対応策（たいおうさく, 대응책）처럼 회의에서 반드시 나오는 단어를 미리 익혀두자.
• 테스트 증적 준비: 테스트 실행 화면 캡처, 로그 파일, 체크리스트에 確認者（かくにんしゃ, 확인자） 서명을 남기는 문화에 익숙해지면 좋다.
• 결정 구조 파악: 실무 담당자 외에 승인권자(決裁者（けっさいしゃ）)가 누구인지 이해하고, 리뷰 일정을 여유 있게 잡아야 한다.
• 애자일 팀 예외: 스타트업/웹서비스 기업은 스크럼을 쓰기도 하지만, 여전히 리포트・문서 포맷은 유지되는 경우가 많다.

빠르게 체크할 일본어 표현 모음

• 要件ヒアリング（ようけんヒアリング）: 요구사항 인터뷰
• 課題管理表（かだいかんりひょう）: 이슈/리스크 목록
• 仕様調整（しようちょうせい）: 사양 조정/협의
• 影響範囲（えいきょうはんい）: 영향 범위
• 改修（かいしゅう）: 수정/개선 작업
• 暫定対応（ざんていたいおう） / 恒久対応（こうきゅうたいおう）: 임시 대응 / 영구 대응
• 棚卸し（たなおろし）: 현황 정리
• 引き継ぎ（ひきつぎ）: 인수인계
• 保守契約（ほしゅけいやく）: 유지보수 계약

마무리

일본 개발 업계는 절차와 문서화를 통해 리스크를 줄이고, 발주사와 수주사가 서로 책임 범위를 명확히 하는 데 초점을 둔다. 이 구조를 이해하고 적절한 용어와 산출물을 준비할 수 있다면, 면접에서도 “일본식 개발 플로우를 이해하고 있다”는 점을 어필할 수 있고, 입사 후에도 팀에 빠르게 적응하는 데 도움이 된다.