개발자 영어 선택지 제안 표현: 기술 대안 2개로 정리하기

• 모호한 메시지 재현
• 결정이 멈추는 원인
• 결정 가능한 메시지 구조
• 상황별 영어 표현
• 두 선택지로 줄이면 안 되는 경우
• 보내기 전 검증
• 10분 연습
• 같이 읽으면 좋은 글
• 공식 출처와 결론

모호한 메시지 재현

다음 문장은 문법적으로 틀리지는 않지만 의사결정에 필요한 정보가 없습니다. 승인자는 REST와 GraphQL의 일반론을 다시 묻게 되고, 작성자는 답을 기다리며 구현을 멈춥니다.

We can use REST or GraphQL. Which option do you prefer?

무엇을 언제까지 결정해야 하는지, 고정된 제약은 무엇인지, 두 안의 비용과 위험은 어떻게 다른지, 작성자는 어느 쪽을 왜 추천하는지가 빠졌습니다. ‘선호’를 묻는 질문은 기준 없는 취향 투표가 되기 쉽습니다.

Google의 Technical Writing One 요약은 독자를 정의하고, 구체적인 동사와 일관된 용어를 쓰며, 문장마다 하나의 생각에 집중하라고 안내합니다. 선택지 메시지도 같은 원칙으로 독자와 필요한 행동을 먼저 분명히 해야 합니다.

결정이 멈추는 원인

원인	모호한 표현	고칠 정보
결정 맥락 없음	We need to choose an API.	이번 결정이 막고 있는 작업과 필요한 시점
제약 없음	A is modern.	고정된 일정, 호환성, 인력, 성능·운영 요구
비교 축 불일치	A is fast. B is familiar.	두 안 모두 일정·비용·위험·확장성 같은 축으로 비교
추천 없음	Either one is fine.	현재 증거로 선호하는 안, 이유, 확신 수준
행동 요청 없음	Thoughts?	결정권자, 답할 질문, 필요한 답변 시점
거짓 양자택일	We only have A or B.	다른 실행 가능한 안, 현행 유지, 추가 조사 필요 여부

‘항상 선택지는 두 개만 제시해야 한다’거나 ‘세 개부터 판단이 급격히 느려진다’고 단정할 근거는 없습니다. 후보가 이미 두 개로 좁혀졌을 때 A/B 형식이 읽기 쉬울 수 있지만, 탐색 단계에서 중요한 대안을 숨기면 더 빠른 메시지가 아니라 잘못된 결정이 됩니다.

결정 가능한 메시지 구조

메시지를 맥락과 제약, 비교 가능한 선택지, 추천, 명시적 질문 순서로 씁니다. Google의 문체 지침과 Microsoft의 간결한 문장 지침처럼 간단하고 직접적인 단어, 구체적인 동사, 일관된 용어를 사용하세요.

1. 맥락과 고정 제약을 한두 문장으로 시작한다

We need to choose the API approach today so the mobile team can start on Monday.
The Friday release date is fixed, and the current team has production experience with REST.

‘왜 지금’과 ‘무엇이 고정됐는지’를 구분합니다. 일정이 정말 고정인지, 단지 선호인지도 확인하세요. 확실하지 않은 가정은 사실처럼 쓰지 말고 Based on what we know today처럼 시점을 표시합니다.

2. 두 안을 같은 축과 평행한 문장으로 비교한다

Option A — Extend the existing REST API.
Benefit: We can reuse authentication and monitoring.
Trade-off: The mobile client may need two requests for this screen.

Option B — Add a GraphQL endpoint.
Benefit: The client can request the screen data in one query.
Trade-off: We must add authorization rules, monitoring, and team training before release.

장점과 단점을 꾸미는 형용사보다 실제 영향으로 씁니다. simple, clean, better만으로는 비교할 수 없습니다. 구현 기간, 기존 기능 재사용, 실패 범위, 운영 책임처럼 확인 가능한 정보를 넣고 아직 측정하지 않은 값은 예상이라고 표시합니다.

3. 추천과 이유, 확신 수준을 밝힌다

I recommend Option A for this release because it meets the fixed date and reuses our current controls.
My confidence is medium because we have not measured the extra request on a slow network.
If that test misses our performance budget, I will revisit Option B.

추천은 책임 있는 판단을 돕지만 결론을 숨겨서 확정하는 장치가 아닙니다. 추천 근거, 불확실성, 판단을 바꿀 조건을 같이 적으면 상대가 동의하거나 반박할 지점이 분명해집니다.

4. 결정 질문, 담당자와 시점을 닫는 문장에 넣는다

Alex, can you approve Option A by 3 p.m. today?
If the priority is fewer client requests rather than the Friday date, please choose Option B instead.

Which option do you prefer?만 쓰기보다 승인할 안과 우선할 기준을 묻습니다. 상대가 결정권자가 아니라면 Who owns this decision?으로 담당자를 확인하고, 답변 시점은 실제 업무 의존성과 시간대를 함께 적습니다.

복사해 쓰는 전체 템플릿

Context: We need to decide [decision] by [time] because [dependency].
Constraint: [fixed requirement]. [uncertain assumption, if any].

Option A — [action]
Benefit: [impact measured on the shared criterion].
Trade-off: [cost or risk on the same criterion].

Option B — [action]
Benefit: [impact measured on the shared criterion].
Trade-off: [cost or risk on the same criterion].

Recommendation: I recommend [A/B] because [evidence].
Confidence: [high/medium/low] because [known uncertainty].
Decision: [owner], can you approve [A/B] by [time]?
Reopen condition: We will revisit this if [new evidence or threshold].

상황별 영어 표현

목적	권장 표현	사용 기준
범위를 두 안으로 고정	We have two practical options under the current constraints.	실행 가능한 후보가 실제로 두 개일 때
장단점 비교	Option A gets us X, but it adds Y. Option B gets us Z, but it adds W.	두 문장을 같은 구조와 비교 축으로 맞출 때
추천	I recommend Option B because it reduces the migration risk.	근거가 있는 현재 판단을 밝힐 때
불확실성	Based on what we know today, I recommend Option A.	새 정보에 따라 판단이 바뀔 수 있을 때
고정 제약	If Friday is fixed, Option A is the safer path.	조건이 사실인지 상대가 확인할 수 있게 할 때
우선순위 질문	Which trade-off should we prioritize: delivery time or migration cost?	취향보다 결정 기준을 확인할 때
정보 요청	Before we choose, I need the expected traffic and rollback requirements.	증거가 부족해 선택을 미뤄야 할 때
결정권 확인	Who owns this decision, and when do they need the recommendation?	승인자와 기한이 불명확할 때

either A or B는 두 항목 사이에서 쓰고 A와 B의 문법 구조를 평행하게 맞추세요. Google의 공식 단어 사용 지침도 either를 일반적으로 두 항목 사이에 쓰며 평행 구조를 유지하라고 안내합니다. 세 개 이상을 나열하거나 숨겨진 선택지가 있을 때 두 안뿐인 것처럼 보이게 쓰지 않습니다.

두 선택지로 줄이면 안 되는 경우

상황	왜 A/B로 닫으면 안 되는가	대신 할 말
문제 탐색 초기	요구사항과 후보가 아직 발견 중임	We are still identifying viable options. I will return with a shortlist after…
핵심 정보 부족	비용·보안·트래픽 같은 결정 변수가 없음	Before we choose, I need…
고위험·되돌리기 어려운 결정	두 안 외의 완화책과 독립 검토가 필요할 수 있음	We should add a risk review and a rollback option before approval.
현행 유지가 실행 가능	Do nothing 또는 단계적 변경이 빠져 거짓 양자택일이 됨	Option C is to keep the current system until…
세 개 이상의 유효한 후보	두 개로 숨기면 중요한 장단점이 사라짐	We have three viable options. I recommend eliminating C because…
결정권자가 아님	선호를 물어도 승인이 완료되지 않음	Who owns the decision, and what evidence do they need?

선택지가 많다고 무조건 모두 같은 깊이로 설명할 필요는 없습니다. 먼저 합격 기준으로 탈락시킬 후보를 근거와 함께 표시하고, 남은 안만 자세히 비교하세요. 그러나 후보를 제외한 이유와 다시 검토할 조건은 기록해야 합니다.

보내기 전 검증

1. 독자: 받는 사람이 결정권자이거나 결정권자에게 전달할 책임이 분명한가?
2. 행동: 첫 두 문장만 읽어도 무엇을 언제까지 결정해야 하는지 알 수 있는가?
3. 제약: 사실, 가정, 선호와 고정 조건을 구분했는가?
4. 완전성: 현행 유지와 추가 후보를 검토한 뒤 실제로 두 안만 남았는가?
5. 평행성: A와 B를 같은 문법 구조와 일정·비용·위험 같은 공통 축으로 비교했는가?
6. 근거: ‘빠르다’, ‘쉽다’, ‘좋다’를 측정값이나 구체적 영향으로 바꿨는가?
7. 판단: 추천, 이유, 확신 수준과 판단을 바꿀 조건이 있는가?
8. 마감: 결정 질문에 담당자, 답변 시점, 시간대가 있는가?
9. 읽기: 한 문장에 한 핵심 생각을 두고 용어를 일관되게 썼는가?

검증은 문장 교정만이 아닙니다. 동료에게 메시지를 보여 주고 ‘무엇을 결정해야 하나요?’, ‘두 안의 핵심 차이는 무엇인가요?’, ‘작성자는 무엇을 추천하나요?’, ‘언제 누구에게 답해야 하나요?’를 물어보세요. 네 답이 메시지에 바로 표시되지 않으면 정보를 보강합니다.

10분 연습

1. 최근 Slack, 이메일 또는 이슈에서 Thoughts?로 끝난 기술 질문 하나를 고릅니다.
2. 결정, 의존 작업, 고정 제약, 가정과 답변 시점을 한 줄씩 적습니다.
3. 현행 유지를 포함해 가능한 후보를 펼친 뒤 합격 기준으로 제외합니다.
4. 남은 두 안을 같은 세 가지 축으로 비교합니다.
5. 추천, 근거, 확신 수준, 재검토 조건과 승인 질문을 붙입니다.
6. 소리 내어 읽고 긴 문장을 나눈 뒤 동료에게 네 가지 검증 질문을 합니다.

Before: We can cache this or optimize the query. Thoughts?

After: We need to reduce the report response time before Thursday's load test.
Option A adds a 10-minute cache; it is faster to ship, but data can be 10 minutes old.
Option B optimizes the query; it keeps fresh data, but the estimate is two extra days.
I recommend A for the test if 10-minute staleness is acceptable.
Mina, can you confirm that trade-off by 2 p.m. KST today?

같이 읽으면 좋은 글

• 개발자 영어 제안 표현 연습 — 추천과 다음 행동을 짧게 전달하는 연습
• 개발자 영어 위험·반대 의견 표현 연습 — 위험과 이견을 공격적이지 않게 밝히는 연습
• 개발자 영어 요구사항 확인 표현 연습 — 선택 전에 부족한 정보를 질문하는 연습

공식 출처와 결론

• Google Technical Writing One 요약
• Google 개발자 문서 단어 사용 지침
• Google 개발자 문서 문체 지침
• Microsoft Writing Style Guide: 간단한 단어와 간결한 문장

판단 1: 실제 후보가 두 개로 좁혀졌는지 먼저 확인합니다. 아니라면 A/B 형식을 강제하지 않습니다.

판단 2: 두 안은 같은 기준과 평행한 문장으로 비교하고, 장단점을 구체적인 영향과 증거로 적습니다.

판단 3: 추천, 불확실성, 재검토 조건, 결정권자와 답변 시점이 있어야 메시지가 행동으로 이어집니다.

다음 행동 체크리스트: 지금 보낼 기술 질문 하나에서 Thoughts?를 지우고, 맥락 한 문장, 고정 제약 한 문장, 비교 가능한 A/B, 근거가 있는 추천, 담당자와 시점이 있는 질문으로 다시 작성하세요.

변경 기록: 2026년 7월 19일, ‘항상 두 선택지’라는 과도한 규칙을 제거하고 재현·원인·수정 템플릿·예외·동료 검증·공식 문체 근거와 실행 가능한 결론을 보강했습니다.