Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며: 왜 2026년에도 영어 + 일본어인가

2026년 한국 개발자 시장은 두 갈래로 양극화되었습니다. 한쪽은 토스 · 쿠팡 · 라인 · 두나무처럼 사내 공용어가 사실상 영어인 회사, 다른 한쪽은 일본 메르카리 · 야후 · LINE · DeNA · 라쿠텐을 거점으로 한 영일 양국 커리어 트랙입니다. 둘 다 코드는 짤 줄 알아도 "PR 본문을 영어로 우아하게 적는다", "장애 대응 중에 일본인 시니어 매니저와 30초 안에 합의를 본다" 같은 마이크로 스킬에서 갈라집니다.

이 글은 21개 시나리오를 한 표로 펼쳐 한국어 의도 → 영어(formal + casual) → 일본어(敬語 + ビジネス砕け)를 비교합니다. 표현 자체보다 "톤 칼리브레이션" — 직설성을 줄이지 않으면서도 문화적 마찰을 줄이는 감각 — 을 잡는 것이 목표입니다.

1. 자기소개 - 온보딩 첫인사

새 회사 첫날 슬랙 #introductions 채널이나 첫 팀 미팅에서. 한국 개발자가 가장 자주 실수하는 부분은 "I'm new here" 같은 미안한 톤으로 시작하는 것. 글로벌 팀은 새 멤버를 자산으로 보지 부채로 보지 않습니다.

| --- | --- | --- | --- | --- |

| 처음 뵙겠습니다, 백엔드 엔지니어로 합류했습니다 | Hello team, I'm Youngju, joining as a backend engineer on the Payments squad. | Hey folks, Youngju here, new backend on Payments. Excited to be here! | はじめまして、本日付でPaymentsチームにバックエンドエンジニアとして入社しました金と申します。 | はじめまして、金です。今日からPaymentsでバックエンドやります、よろしくお願いします。 |

| 이전 회사에서 결제 시스템을 다뤘습니다 | Previously, I led the payment infrastructure team at company X for three years. | Last gig was leading payments infra at X for ~3 years. | 前職ではX社で決済基盤チームを3年間リードしておりました。 | 前は X で3年くらい決済の基盤やってました。 |

**한국 개발자가 자주 헷갈리는 포인트**: 영어로 "I hope I can contribute"는 자신 없어 보입니다. "I'm here to help us ship faster on Payments." 처럼 의도와 가치를 같이 말하는 편이 깔끔합니다.

2. 스탠드업 / 데일리

비동기 스탠드업(Slack 텍스트)이든 줌 라이브든, 핵심은 **Yesterday / Today / Blockers** 세 줄. 한국식 "어제 이러이러한 이슈가 있었는데 결국..." 같은 서사형은 길어집니다.

| --- | --- | --- | --- | --- |

**팁**: 영어권에서는 "Y / T / B" 약자가 광범위하게 쓰입니다. 일본에서는 "昨日 / 今日 / 障害" 또는 "やったこと / やること / 困りごと" 라는 표현이 자주 보입니다.

3. 코드 리뷰 - 변경 요청을 정중하게

가장 한국인 개발자가 톤을 잘못 잡기 쉬운 영역입니다. 한국어 직역으로 "This is wrong" 라고 적으면 글로벌 팀에서 공격적으로 읽힙니다. 반면 너무 부드러우면 정보가 사라집니다.

3.1 코멘트 prefix 규약 - nit, blocker, suggestion

| 표기 | 의미 | 한국어 늬앙스 | 사용 예 |

| --- | --- | --- | --- |

3.2 동사 강도 스펙트럼

영어 코드 리뷰에서 동사 하나가 톤을 가릅니다. 강도 순서대로:

| 약 → 강 | 동사/구문 | 한국어 늬앙스 |

| --- | --- | --- |

| 1 | `consider ...ing` | "한번 고려해보시는 건 어떨까요" |

| 2 | `it might be worth ...ing` | "...해볼 만한 가치가 있을 것 같아요" |

| 3 | `I'd suggest ...ing` | "...하시는 걸 추천합니다" |

| 4 | `we should ...` | "...하는 게 맞다고 봅니다" |

| 5 | `we need to ...` | "...해야 합니다" |

| 6 | `we must ...` / `this must be fixed before merge` | "반드시 ...해야 합니다 (머지 전)" |

3.3 시나리오 표

| --- | --- | --- | --- | --- |

| null 체크가 누락됐어요 | This function doesn't handle the null case — could you add a guard? | blocker: null case isn't handled, can you add a guard? | こちらの関数で null のケースが処理されていないように見えます。ガードを追加していただけますでしょうか。 | ここ null のケース落ちてる気がする、ガード入れて! |

3.4 한국 개발자가 피해야 할 단어

- `obviously` / `clearly` — "이건 명백히..." 한국어 직역. 영어에서는 "당신은 모르나본데" 톤.

- `just` — "그냥 ... 하시면 돼요". 사소해 보이게 만드는 부사. "Just use the helper" → "I'd use the helper here" 정도가 안전.

- `actually` — "사실은 ... 입니다". 상대를 정정하는 느낌. "It actually returns null" 보다 "It returns null in this case" 가 무난.

- `simply` — `just` 와 같은 함정.

- `should be easy to fix` — 작성자가 그렇게 못 고치고 있는데 압박이 됨.

4. PR 작성 - 제목, 본문, Conventional Commits

2026년 표준은 여전히 Conventional Commits. 제목 길이는 50자 이내, 본문은 **What / Why / How tested** 세 섹션이 안전한 디폴트.

4.1 제목 prefix 표

| Prefix | 용도 | 예시 |

| --- | --- | --- |

| `feat:` | 새로운 기능 | `feat(payment): add Apple Pay support` |

| `fix:` | 버그 수정 | `fix(auth): handle expired refresh token` |

| `refactor:` | 기능 변경 없는 리팩터 | `refactor(api): extract retry helper` |

| `perf:` | 성능 개선 | `perf(db): add index on user_id` |

| `docs:` | 문서만 | `docs(readme): clarify setup steps` |

| `test:` | 테스트 추가/수정 | `test(payment): cover Apple Pay path` |

| `chore:` | 빌드/툴링 | `chore(deps): bump next to 15.4` |

| `ci:` | CI 변경 | `ci: cache node_modules in pipeline` |

| `revert:` | 되돌리기 | `revert: feat(payment): add Apple Pay support` |

| `BREAKING CHANGE:` | 호환 깨짐 | 본문에 `BREAKING CHANGE: ...` 라인 추가 |

4.2 PR 본문 템플릿 표현

| --- | --- | --- | --- | --- |

| 호환 깨짐 표시 | BREAKING CHANGE: `payment.create()` now requires `currency`. | BREAKING CHANGE: `payment.create()` needs `currency` now. | 破壊的変更: `payment.create()` に `currency` が必須になります。 | 破壊的変更あり、`payment.create()` で `currency` 必須にした。 |

4.3 스코프(scope) 명명 팁

`feat(scope):` 의 스코프는 보통 폴더 이름이나 도메인 이름. `feat(api): ...`, `feat(web/payment): ...` 처럼 슬래시로 계층을 표현하는 컨벤션도 흔합니다.

5. 장애 대응 (Incident) - SEV1/SEV2 표현

장애 대응 채널에서는 **3초 룰** 이 있습니다 — 한 문장 안에 "무엇이 / 누가 / 언제부터" 를 담을 것. 한국어 화자가 자주 빠지는 함정은 "지금 보고 있습니다" 라고만 적고 책임 영역을 명시하지 않는 것.

5.1 SEV 등급 호칭

| 등급 | 의미 | 일본어 |

| --- | --- | --- |

| `SEV1` | 전체 서비스 다운, 매출 손실 | 重大障害 (じゅうだいしょうがい) |

| `SEV2` | 핵심 기능 부분 다운, 일부 사용자 영향 | 部分障害 |

| `SEV3` | 비핵심 기능 영향, 우회 가능 | 軽度障害 |

| `SEV4` | 내부 도구, 외부 영향 없음 | 内部障害 |

5.2 시나리오 표

| --- | --- | --- | --- | --- |

| 결제 API 에러율 급증 발견 | We're seeing elevated 5xx errors on `/payment/create` — opening SEV2. | seeing elevated 5xx on /payment/create, calling SEV2. | `/payment/create` で 5xx エラーが急増しております。SEV2 として対応開始します。 | /payment/create で 5xx 上がってる、SEV2 開ける。 |

5.3 "Blameless" 가 왜 중요한가

영어권 포스트모템에서 "blameless" 는 거의 종교적 키워드입니다. "Who broke prod?" → "What in our system made it possible to break prod?" 로 질문을 전환하는 약속. 일본에서도 メルカリ · クックパッド 가 이 문화를 들여오면서 "犯人探しをしない (범인 색출하지 않는다)" 라는 한국어보다 더 명시적인 표현이 자리잡았습니다.

6. 1on1 - 매니저와의 1대1

1on1 의 황금률은 "agenda 는 IC 가 가져온다" 입니다. 매니저가 의제를 꺼내는 1on1 은 사실상 status report 미팅. 한국식 "딱히 할 말은 없습니다" 는 1on1 의 가치를 0으로 만듭니다.

6.1 의제 카테고리

| 카테고리 | 의미 | 영어 표현 예 |

| --- | --- | --- |

| Career growth | 커리어 / 승진 | "I'd like to chat about my growth path to staff." |

| Feedback for me | 내가 받는 피드백 | "What's one thing I could be doing better?" |

| Feedback for you | 매니저에게 주는 피드백 | "I have some feedback for you, can I share?" |

| Project | 프로젝트 상황 | "Quick update on Payments v2 — we hit X." |

| Personal | 사적인 이슈 | "I'd like to share something personal." |

| Team dynamics | 팀 내 관계 | "I want to talk about the dynamic with X." |

6.2 시나리오 표

| --- | --- | --- | --- | --- |

7. 요구사항 미팅 - 모호함 해소

기획자/PM 과의 미팅에서 한국 개발자가 자주 하는 실수: "네 알겠습니다" 라고 답하고 미팅이 끝난 뒤 슬랙에서 다시 물어보는 패턴. 이건 영어권 / 일본에서도 비효율로 봅니다.

7.1 모호함 드러내기

| --- | --- | --- | --- | --- |

7.2 "Let's take this offline" 의 정확한 용법

화상 미팅 시대에 "offline" 은 "회의 밖에서" 라는 뜻입니다. "지금 이 주제는 여기서 풀기엔 길어요, 따로 시간을 잡읍시다" 라는 정중한 토픽 차단. 일본에서는 "別途調整" "別途お時間いただけますか" 가 같은 기능.

8. 데이터 분석 보고 - KPI, North Star, Lift

A/B 테스트 결과 발표나 분기 리뷰. 통계 용어를 영어로 정확히 쓰는 것이 신뢰의 기반입니다.

| 영어 용어 | 한국어 | 日本語 | 사용 예 |

| --- | --- | --- | --- |

8.1 발표 시나리오 표

| --- | --- | --- | --- | --- |

**한국 개발자 함정**: `significant` 와 `meaningful` 을 혼동하지 마세요. `significant` 는 통계 용어, `meaningful` 은 비즈니스 임팩트 의미. "0.1% lift was significant but not meaningful" 같은 문장이 가능합니다.

9. 휴가 / OOO - PTO, 育休, 有給

| --- | --- | --- | --- | --- |

**일본 문화 메모**: 일본에서는 有給(ゆうきゅう)이 "권리지만 모두가 쓰진 않는" 분위기가 아직 남아있습니다. 메르카리 같은 외자계 영향 회사는 PTO 를 적극 쓰지만, 전통 SIer 에서는 "申し訳ございません" 톤이 더 짙습니다.

10. 거절 - 우아하게 NO

한국 개발자에게 가장 어려운 영역. "I'll try" 는 영미권에서 사실상 "YES" 로 해석되고, "어렵습니다" 는 일본에서 "NO" 로 해석되는 등 문화 충돌이 큽니다.

| --- | --- | --- | --- | --- |

**ESL 팁**: 영어로 No 를 할 때는 거의 항상 **대안 또는 이유** 와 묶어 던지는 것이 안전. `No, but here's what I can do: ...`

11. 사과 - 책임의 톤

영어 사과에서 `I'm sorry` 와 `I apologize` 의 무게가 다릅니다. 후자가 공식적. 일본어는 段階이 더 세밀합니다.

| --- | --- | --- | --- | --- |

**일본 사과 단계** (강도 순):

1. すみません - 가벼운 사과

2. ごめんなさい - 사적 관계

3. 申し訳ございません - 비즈니스 표준

4. 大変申し訳ございません - 더 무거운 사과

5. 誠に申し訳ございませんでした - 공식 사죄 (장애 알림 등)

12. 칭찬 - 칭찬 인플레이션 함정

영어권은 칭찬 인플레이션이 심해서 `Great work!` 가 거의 인사말 수준. 의미 있는 칭찬을 하려면 **구체성** 이 필요.

| --- | --- | --- | --- | --- |

12.1 한국식 "수고하셨습니다" 의 영어 / 일본어 매핑

- 한국어 "수고하셨습니다" 는 정확한 영어 1:1 매칭이 없습니다. 상황별 분기:

- 미팅 끝: `Thanks everyone!` / `Great session!`

- 퇴근: `Have a good evening!` / 일본어 `お疲れ様でした`

- 프로젝트 종료: `Great work shipping this!` / `Massive props to the team`

13. 이메일 - 인사 / 마무리

| --- | --- | --- | --- |

13.1 이메일 본문 표현

| 한국어 의도 | English | 日本語 |

| --- | --- | --- |

| 메일 잘 받았습니다 | I received your email — thank you. | メール拝受いたしました。 |

| 확인해보겠습니다 | I'll look into it and get back to you. | 確認のうえ、ご連絡差し上げます。 |

| 첨부 확인 부탁드립니다 | Please find attached ... | 添付ファイルをご確認ください。 |

| 회의 일정 잡고 싶습니다 | Could we find 30 min next week to discuss? | 来週中に 30 分ほどお打ち合わせのお時間をいただけますでしょうか。 |

| 답변이 늦어 죄송 | Apologies for the delayed reply. | ご返信が遅くなり申し訳ございません。 |

14. Slack / 메신저 약어 사전

2026년 글로벌 IT Slack 의 약어 표준은 거의 굳어졌습니다.

| 약어 | 풀이 | 한국어 늬앙스 | 일본어 |

| --- | --- | --- | --- |

| `FYI` | For Your Information | "참고로" | ご参考まで |

| `OOO` | Out Of Office | "휴가" | 不在 |

| `EOD` | End Of Day | "오늘 안에" | 本日中 |

| `EOW` | End Of Week | "이번 주 안에" | 今週中 |

| `WIP` | Work In Progress | "작업 중" | 作業中 |

| `MVP` | Minimum Viable Product | "최소 기능 제품" | MVP |

| `BTW` | By The Way | "참고로" | ところで |

14.1 이모지 문화

- `:eyes:` 👀 — "보고 있음, 응답 준비 중"

- `:pray:` 🙏 — 부탁 / 감사

- `:white_check_mark:` ✅ — 완료

- `:fire:` 🔥 — 시급, 또는 매우 좋음 (맥락 의존)

- `:rocket:` 🚀 — 배포 완료 / 출시

- `:bug:` 🐛 — 버그 보고

- `:facepalm:` 🤦 — 자조적 실수 인정

일본 Slack 문화에서는 `:bow:` (お辞儀) 이모지가 사과/감사 양쪽으로 광범위하게 쓰입니다.

15. 회의 진행 - 어젠다, 액션 아이템, 회의록

회의를 한국어로 진행할 줄 안다고 영어 미팅 진행이 자연스러운 건 아닙니다. 표현 키트가 필요합니다.

15.1 회의 진행 표현 표

| --- | --- | --- | --- |

15.2 Parking Lot 의 정확한 뜻

"Let's put that in the parking lot" 은 "지금 다루기엔 너무 큰 / 다른 주제라 따로 보관해두자" 라는 뜻. 일본어로는 "保留" 또는 "別途検討".

16. 인터뷰 - 시스템 디자인, Behavioral STAR

면접 영어는 별도의 sub-genre. 자기 회사 면접관이 될 수도, 다른 회사를 받을 수도 있는 양방향 표현.

16.1 시스템 디자인 표현

| 한국어 의도 | English (formal) | English (casual) |

| --- | --- | --- |

| 요구사항 정리하겠습니다 | Let me clarify the requirements first. | Let me get the reqs straight first. |

| 처리량 / 응답시간 | What's the expected throughput and latency budget? | What's the QPS and latency target? |

| 일관성 vs 가용성 | We'd trade strong consistency for availability here. | Eventual consistency works here. |

| 핵심 컴포넌트 그리기 | I'll sketch the high-level components first. | Let me box-and-arrow this. |

| 트레이드오프 | The trade-off is X vs Y — I'd lean toward Y because ... | Trade-off: X vs Y, I'd pick Y because ... |

16.2 Behavioral - STAR 방식

`STAR` = Situation / Task / Action / Result.

| 한국어 의도 | English 예 |

| --- | --- |

| 상황 설명 | "Last year my team was facing a 30% error rate spike during checkout. (Situation)" |

| 내 책임 | "As tech lead, I owned both the triage and the long-term fix. (Task)" |

| 무엇을 했는가 | "I led a war room, ran a binary-search rollback, and identified a Redis key collision. (Action)" |

| 결과 | "Error rate dropped to 0.2% within 4 hours, and we shipped a postmortem with three preventative actions. (Result)" |

**한국 개발자 함정**: behavioral 질문에 "팀이 모두 협력해서 해결했습니다" 라는 한국식 겸손 답변을 하면 평가가 어렵습니다. **I** 를 정확히 써야 합니다. "I led ... while the team supported with ..." 식 구조.

17. 거버넌스 - RFC / ADR 본문 표현

큰 기술 결정 문서. 표현 자체보다 **섹션 구성 키워드** 가 표준입니다.

17.1 RFC 섹션 표준 어휘

| 섹션 | 영어 | 日本語 |

| --- | --- | --- |

| 동기 | Motivation | 動機 / 背景 |

| 목표 | Goals | 目的 |

| 비-목표 (제외 사항) | Non-goals | 非目標 / スコープ外 |

| 제안 | Proposal | 提案 |

| 대안 검토 | Alternatives considered | 検討した代替案 |

| 트레이드오프 | Trade-offs | トレードオフ |

| 미해결 질문 | Open questions | 未解決の論点 |

| 결정 | Decision | 決定事項 |

| 결과 | Consequences | 結果 |

17.2 표현 표

| 한국어 의도 | English |

| --- | --- |

| 제안하고자 합니다 | I'd like to propose adopting X for use case Y. |

| 비-목표는 명시합니다 | Non-goals: we're not addressing X in this RFC. |

| 다음 질문은 열려있습니다 | Open question: how do we migrate the legacy data? |

| 결정 시한은 | Decision deadline: end of week. |

| 대안 A 검토했지만 거부 | Alternative A was considered but rejected because of X. |

18. 포스트모템 - 5 Whys, Lessons Learned

장애 후 24~72시간 안에 작성되는 문서. 표현이 거의 종교 의식 수준으로 표준화되어 있습니다.

18.1 핵심 어휘

| 영어 | 한국어 | 日本語 |

| --- | --- | --- |

| Blameless postmortem | 비난 없는 포스트모템 | ブレームレス・ポストモーテム |

| Timeline | 타임라인 | タイムライン |

| Root cause | 근본 원인 | 根本原因 |

| Contributing factors | 기여 요인들 | 寄与要因 |

| 5 Whys | 다섯 번의 왜 | なぜなぜ分析 |

| Lessons learned | 배운 점 | 教訓 |

| Action items | 액션 아이템 | アクションアイテム |

| Detection time (TTD) | 탐지까지 시간 | 検知までの時間 |

| Mitigation time (TTM) | 완화까지 시간 | 緩和までの時間 |

| Recovery time (TTR) | 복구까지 시간 | 復旧までの時間 |

18.2 표현 표

| 한국어 의도 | English |

| --- | --- |

| 책임 추궁 안 합니다 | This is a blameless postmortem — we focus on systems, not people. |

| 근본 원인 | Root cause: a race condition in the connection pool when traffic exceeded 5k QPS. |

| 왜 늦게 발견됐는지 | Our alert thresholds were tuned for the old traffic baseline and didn't trip. |

| 액션 아이템 | Action 1: Add SLO-based alerts. Owner: @alice. Due: end of next sprint. |

19. 퇴사 / 이직 - Graceful Exit

| --- | --- | --- | --- | --- |

**문화 메모**: 일본에서는 2주 전 통보가 표준이 아니라 1~3개월 전 통보가 표준. 한국은 1개월, 미국은 2주가 표준. 글로벌 팀 옮길 때 가장 큰 마찰점.

20. 협상 - 승진, 연봉, 보상

매니저와의 협상 미팅에서. 한국식 "그냥 알아서 좀 잘 해주세요" 는 영어/일본어 양쪽에서 통하지 않습니다.

20.1 표현 표

| --- | --- | --- | --- | --- |

**용어 메모**: **TC** = Total Compensation (총 보상). 베이스 + 보너스 + 주식. 영미권 IT 협상에서 거의 모든 숫자는 TC 기준입니다.

21. 글로벌 미팅 매너 - 시차, 액센트, 반복 요청

| --- | --- | --- | --- |

21.1 액센트 / ESL 매너

- 영어 비원어민과의 미팅에서 "I didn't understand" 는 자신의 부족함을 표명. "Could you clarify?" 가 상대 책임으로 균형.

- 일본어 미팅에서는 "もう一度お願いします" 가 가장 무난.

- 글로벌 팀에서는 음성 인식 자막(Zoom AI Companion, Otter, Granola) 이 2026 표준. 미팅 시작 시 "I have captions on" 한 마디로 거부감 없이 사용.

22. 한국 개발 커뮤니티 사례 - 영문화 모범

22.1 토스 영문화

토스는 2023년부터 글로벌 팀 확대에 맞춰 사내 문서 / 슬랙을 영어로 전환하는 작업을 진행했습니다. 핵심 자산:

- **토스 기술 블로그 영문판** ([toss.tech](https://toss.tech/)) - 한국어 원문과 영문 번역을 병행 게시.

- 디자인 시스템 문서 영문화.

- 글로벌 채용 페이지에서 영어 직무 기술서 표준화.

배울 점: 영문화는 "번역" 이 아니라 "재구조화". 한국어 문서를 그대로 옮기면 어색하므로, 영문 기준 문장 길이/문단 구성을 다시 잡습니다.

22.2 카카오 / 라인 영어 학습

카카오는 사내 영어 학습 프로그램 (1on1 영어 코칭, 영문 PR 작성 워크숍) 을 운영합니다. 라인은 도쿄 본사와의 일상 협업으로 일본어 + 영어 이중 공용어 환경.

22.3 한국어 IT 영어 자산 추천

- [한영번역 가이드](https://github.com/translate-kr/style-guide) - 한국 번역가들이 유지하는 IT 문서 번역 스타일 가이드.

- 책: "개발자를 위한 영어" (한빛미디어).

- 책: "직장인 영어회화 무작정 따라하기" (길벗).

- [Stack Overflow 영문 답변 검색법](https://stackoverflow.com/) - 영어 기술 표현의 자연스러운 용례를 보기 가장 좋은 곳.

23. 일본 개발 커뮤니티 사례 - 카타카나 IT 용어 매핑

23.1 메르카리 영어 공식어

메르카리는 2018년부터 사내 공용어를 영어로 지정했습니다. 그 영향으로:

- **エンジニアブログ** ([mercan.mercari.com](https://mercan.mercari.com/), [engineering.mercari.com](https://engineering.mercari.com/)) - 영문/일문 병행.

- 외국인 엔지니어 비율 50% 이상.

- 미팅은 영어, 슬랙도 영어가 디폴트.

도쿄 거점이지만 글로벌 회사 톤. 한국 개발자가 일본 진출하려면 메르카리는 영어 베이스로 들어갈 수 있는 채널.

23.2 IT カタカナ 용어 핵심 매핑

| 영어 | 한국어 | カタカナ |

| --- | --- | --- |

| Deploy | 배포 | デプロイ |

| Rollback | 롤백 | ロールバック |

| Code review | 코드 리뷰 | コードレビュー |

| Pull request | PR | プルリクエスト / プルリク |

| Merge | 머지 | マージ |

| Refactor | 리팩터링 | リファクタリング |

| Repository | 저장소 | リポジトリ |

| Branch | 브랜치 | ブランチ |

| Commit | 커밋 | コミット |

| Issue | 이슈 | イシュー / 課題 |

| Sprint | 스프린트 | スプリント |

| Retro | 회고 | レトロ / ふりかえり |

| Standup | 스탠드업 | スタンドアップ / 朝会(あさかい) |

| 1on1 | 1대1 | ワンオンワン |

| Onboarding | 온보딩 | オンボーディング |

| Tech lead | 테크 리드 | テックリード / TL |

**팁**: 일본 IT 현장에서 영어 그대로 쓰는 케이스가 점점 늘고 있지만, 시니어/SIer 환경에서는 한자 표현 (障害 = incident, 復旧 = recovery) 이 더 신뢰감을 줍니다. 두 톤을 자유롭게 오가는 것이 베스트.

23.3 일본 개발 커뮤니티

- [Qiita](https://qiita.com/) - 일본 최대 개발자 블로그 플랫폼.

- [Zenn](https://zenn.dev/) - 모던 일본 개발자 커뮤니티.

- 책: [WEB+DB PRESS](https://gihyo.jp/magazine/wdpress) (휴간했지만 백넘버 가치 큼).

- LINE / DeNA / Yahoo Japan 엔지니어링 블로그.

24. ESL 톤 칼리브레이션 - "덜 직설적 ≠ 덜 효과적"

한국 개발자에게 영어 톤 조정은 처음엔 비효율적으로 느껴집니다. "왜 이렇게 빙빙 둘러서 말해야 하지?" 하지만 데이터로 보면 정중한 형태도 빠릅니다:

- **공격적 코드 리뷰** → 작성자 방어 모드 → 댓글 왕복 5~10회 → 머지 지연 2일

- **정중한 코드 리뷰** → 작성자 수긍 → 댓글 1~2회 → 머지 지연 4시간

핵심 원리:

1. **사람이 아니라 코드를 비판** - `You did X wrong` → `This line does X, which leads to Y`

2. **궁금증으로 시작** - `Why is this here?` 보다 `Curious about the reasoning here — could you walk me through?`

3. **자기 한계 인정** - `I might be missing context, but ...` 한 줄로 상대가 방어 모드를 안 켭니다.

4. **선택지 제공** - `must do X` 보다 `we could do X or Y; I'd lean toward X because Z`.

5. **빠른 인정** - 상대가 좋은 지적을 하면 `Good point` / `Fair` 한 마디.

24.1 한국 개발자 안티패턴 단어 모음

| 피해야 할 단어 | 왜 위험한가 | 대체 표현 |

| --- | --- | --- |

| `obviously` | "당신은 모른다" 톤 | (생략하거나) `as you might know` |

| `simply` / `just` | 사소화, 압박 | (대부분 생략 가능) |

| `actually` | 정정 톤 | `in this case` |

| `should be easy` | 압박 | `if it's feasible` |

| `why don't you ...` | 명령형 | `would it be possible to ...` |

| `you need to ...` | 명령형 | `we'd benefit from ...ing` |

| `I think you misunderstood` | 공격 | `I might not have explained well — let me try again` |

25. 마무리 - 다음 90일 학습 계획

표현을 외우는 것보다 **실전 노출** 이 빠릅니다.

25.1 90일 플랜

| 주차 | 영어 | 일본어 |

| --- | --- | --- |

| 1~2주 | 자신의 마지막 PR 영문 본문 다시 쓰기 | 메르카리 엔지니어링 블로그 1편 정독 |

| 3~4주 | 코드 리뷰 영어 코멘트 5개 작성 | Qiita 일본어 글 1편 작성 시도 |

| 5~6주 | 영어 회의록 작성 1회 | LINE 엔지니어링 일본어 블로그 정독 |

| 7~8주 | RFC / ADR 영어 1편 초안 | 일본어 RFC 1편 정독 |

| 9~10주 | 외부 영어 컨퍼런스 발표 시청 + shadowing | 일본어 컨퍼런스 (Builderscon 등) 시청 |

| 11~12주 | 영어 1on1 시뮬레이션 | 일본어 1on1 시뮬레이션 |

25.2 도구 추천

- **DeepL** ([deepl.com](https://www.deepl.com/)) - 한국어 → 영어/일본어 자연스러움 1위.

- **Grammarly** ([grammarly.com](https://www.grammarly.com/)) - 영어 톤 칼리브레이션.

- **Granola** ([granola.ai](https://www.granola.ai/)) - 미팅 자막 + 요약.

- **HeyGen / Otter** - 영어 발음 / 영어 미팅 노트.

참고 자료

1. [Google's Engineering Practices documentation - Code Review](https://google.github.io/eng-practices/review/)

2. [Conventional Commits specification](https://www.conventionalcommits.org/)

3. [The Pragmatic Engineer Newsletter](https://newsletter.pragmaticengineer.com/) - 글로벌 개발자 문화 사례.

4. [Atlassian Incident Management handbook](https://www.atlassian.com/incident-management)

5. [GitLab Handbook - Communication](https://handbook.gitlab.com/handbook/communication/) - 전체 회사가 비동기 영어로 일하는 사례.

6. [Lara Hogan - Resilient Management](https://larahogan.me/) - 1on1, 피드백, 매니저 표현의 표준.

7. [Stripe Press](https://press.stripe.com/) - 영문 비즈니스 글쓰기 모범.

8. [DEI - Mercari Engineering Blog](https://engineering.mercari.com/) - 일본 영문화 사례 1차 자료.

9. [LINE Engineering](https://engineering.linecorp.com/) - 일본/한국 이중 언어 사례.

10. [토스 tech](https://toss.tech/) - 한국어/영어 병행 블로그.

11. [Qiita](https://qiita.com/) - 일본어 개발자 글의 표준 톤.

12. [Zenn](https://zenn.dev/) - 모던 일본 개발자 커뮤니티.

13. [Etsy Code as Craft - Debriefing facilitation guide](https://www.etsy.com/codeascraft/blameless-postmortems/) - blameless 포스트모템 원조.

14. [Google SRE Book - Postmortem Culture](https://sre.google/sre-book/postmortem-culture/)

15. [Increment Magazine - On-Call issue](https://increment.com/on-call/)

16. [SmartHR Tech Blog](https://tech.smarthr.jp/) - 일본어 개발자 글쓰기 표준 톤.

17. [Cookpad Engineering](https://techlife.cookpad.com/) - 일본 IT 영문화 사례.

18. [Common English Mistakes by Korean Speakers - Engoo Blog](https://engoo.com/blog/category/all-tips/) - ESL 한국어 화자 함정.

19. [Daniel Stenberg - Working in Open Source](https://daniel.haxx.se/blog/) - PR / 이슈 영어 표현의 정수.

20. [Will Larson - Staff Engineer book](https://staffeng.com/) - 시니어 이상 개발자의 영어 표현/RFC 문화.

21. [The Manager's Path - Camille Fournier](https://www.oreilly.com/library/view/the-managers-path/9781491973882/) - 1on1 표현 모음.

22. [Crucial Conversations book](https://cruciallearning.com/crucial-conversations-book/) - 어려운 대화의 영어 표현.

23. [한빛미디어 - 개발자를 위한 영어](https://www.hanbit.co.kr/) - 한국어 학습자 대상 IT 영어 가이드.

24. [Engineering Effectiveness - Spotify R&D](https://engineering.atspotify.com/) - 영어 표현 + 엔지니어링 문화.

마지막으로: 한국 개발자에게 가장 중요한 깨달음은 "영어 / 일본어는 부족해도 일을 잘 한다는 신호를 줄 수 있다" 는 것입니다. 표현을 외우는 것보다 **자기 일의 임팩트를 정확히 옮기는 능력** 이 더 큰 자산이라는 점, 잊지 마세요.