테크 미팅 필수 영어 표현 완벽 가이드 — 스탠드업부터 장애 대응까지

1. What did you do yesterday? (어제 한 일)
2. What will you do today? (오늘 할 일)
3. Any blockers? (막히는 것)

[You]
"Yesterday, I wrapped up the database migration script and opened a PR
for it — PR #215. I also spent some time investigating the intermittent
timeout issue on the /users endpoint.

Today, I'm going to start working on the rate limiting feature. I'll
also need to address the review comments on PR #215.

One blocker — I need access to the staging Redis cluster to test the
rate limiter. Could someone from the infra team help me with that?"

[Team Lead]
"Thanks for the update. I'll ping the infra team on Slack right after
standup to get you that access."

"Carrying over from yesterday..." (어제에 이어서...)
"Just a quick heads-up..." (참고로 알려드리면...)
"I'll need to sync with [name] on this." ([이름]과 이 건에 대해 싱크해야 합니다.)
"I'll keep the team posted." (팀에 계속 공유하겠습니다.)
"That's it from my side." (제 쪽에서는 이상입니다.)

[승인할 때]
"LGTM! Clean implementation. Approved."
(코드가 좋습니다! 깔끔한 구현이네요. 승인합니다.)

[사소한 수정 제안]
"Nit: Could we rename this variable to something more descriptive,
like 'userSessionTimeout' instead of 'timeout'?"
(사소한 건데, 이 변수명을 'timeout' 대신 'userSessionTimeout'처럼
좀 더 설명적으로 바꿀 수 있을까요?)

[변경 요청]
"I'd suggest extracting this logic into a separate utility function.
It's used in three different places, so having a single source of
truth would reduce duplication."
(이 로직을 별도 유틸리티 함수로 추출하는 것을 제안합니다. 세 곳에서
사용되고 있어서 하나로 통합하면 중복이 줄어듭니다.)

[질문하기]
"Could you walk me through the reasoning behind using a recursive
approach here instead of iteration?"
(여기서 반복문 대신 재귀를 선택한 이유를 설명해 주실 수 있나요?)

[보안/성능 이슈 지적]
"This could be a potential SQL injection vulnerability. Let's use
parameterized queries instead of string concatenation."
(SQL 인젝션 취약점이 될 수 있습니다. 문자열 연결 대신
파라미터화된 쿼리를 사용합시다.)

"Thanks for the catch! Fixed in the latest commit."
(지적 감사합니다! 최신 커밋에서 수정했습니다.)

"Good point. I'll refactor this in a follow-up PR to keep
this one focused."
(좋은 지적입니다. 이 PR의 범위를 유지하기 위해 후속 PR에서
리팩토링하겠습니다.)

"I intentionally chose this approach because [reason].
What do you think?"
(이 접근법을 [이유] 때문에 의도적으로 선택했습니다. 어떻게 생각하세요?)

"Addressed all comments. PTAL at the updated version."
(모든 코멘트를 반영했습니다. 업데이트된 버전을 확인해 주세요.)

What went well? (잘된 점)
What didn't go well? (개선할 점)
What can we improve? (앞으로 어떻게 개선할까?)

[Facilitator]
"Let's start with what went well this sprint. Anyone want to kick
things off?"

[Developer A]
"I think our deployment process has really improved since we
introduced the automated rollback mechanism. We shipped three
releases this sprint with zero downtime."

[Developer B]
"On the flip side, I felt like we underestimated the complexity
of the payment integration. We ended up carrying over two stories
to the next sprint."

[Developer C]
"I agree. I think we should spend more time during planning to
break down complex stories. Maybe we could do a quick spike
before committing to estimates."

[Facilitator]
"Great suggestion. Let's capture that as an action item. Who wants
to own this?"

[Developer C]
"I can take the lead on proposing a spike process for the team."

[Facilitator]
"Perfect. Let's follow up on this in next sprint's planning session."

"One thing that worked really well was..." (정말 잘 됐던 건...)
"I noticed we struggled with..." (우리가 힘들어했던 부분은...)
"Going forward, I suggest we..." (앞으로는 ...하면 좋겠습니다.)
"Let's make this an action item." (이걸 액션 아이템으로 잡읍시다.)
"Can we follow up on last sprint's action items?" (지난 스프린트 액션 아이템 후속 확인할 수 있을까요?)
"I'd like to give a shout-out to [name] for..." ([이름]에게 ...에 대해 칭찬하고 싶습니다.)

[Presenter]
"...and that's how we reduced our p99 latency from 800ms to under
200ms by implementing connection pooling and query optimization.
I'm happy to take any questions."

[Audience Member 1]
"How did you handle the connection pool sizing? Did you run into
any issues with too many idle connections?"

[Presenter]
"Great question. We initially set the pool size to 50, but found
that was overkill for our traffic patterns. We ended up using a
dynamic sizing approach based on the HikariCP recommendations —
roughly 2x the number of CPU cores plus the number of disk
spindles. That brought us down to about 20 connections per
instance, which actually improved our throughput."

[Audience Member 2]
"Is this approach applicable to our microservices that use
connection-per-request patterns?"

[Presenter]
"That's a good point. For connection-per-request services, you'd
want to look at connection multiplexing instead. I can share some
resources on that after the talk."

"Building on that..." (그것을 바탕으로...)
"To put this in perspective..." (이것을 맥락에 맞게 보면...)
"One thing worth noting is..." (주목할 점 하나는...)
"Let me zoom in on this part." (이 부분을 자세히 보겠습니다.)
"I'll circle back to this point later." (이 포인트는 나중에 다시 다루겠습니다.)
"As a quick aside..." (잠깐 덧붙이자면...)

[On-call Engineer - Slack #incident-channel]
"@channel SEV1 incident declared. The checkout service is returning
500 errors for approximately 30% of requests. I'm the Incident
Commander. Setting up a war room call now."

[Backend Engineer]
"I'm looking at the logs. Seeing a spike in connection timeouts
to the payments database starting at 14:32 UTC."

[Incident Commander]
"Thanks. Can you check if there were any recent deployments or
config changes around that time?"

[Backend Engineer]
"Confirmed — there was a config change pushed at 14:30 UTC that
reduced the connection pool size from 20 to 5. That's likely the
root cause."

[Incident Commander]
"Let's roll back that config change immediately. What's the ETA
on the rollback?"

[Backend Engineer]
"Rollback is in progress. ETA 3 minutes."

[Incident Commander]
"Copy that. I'll update the status page. @frontend-team, can you
confirm if you're seeing recovery on your end once the rollback
is complete?"

[3 minutes later]
[Backend Engineer]
"Rollback complete. Error rates are dropping. We're back to
normal levels."

[Incident Commander]
"Confirmed. Incident resolved at 14:50 UTC. Total impact duration:
18 minutes. I'll schedule a postmortem for tomorrow. Everyone
involved, please jot down your timelines."

"We're seeing elevated error rates on..." (...에서 에러 비율 상승이 보이고 있습니다.)
"I'm investigating the issue now." (현재 이슈를 조사 중입니다.)
"I don't know yet, but I'm looking into it." (아직 모르지만 확인 중입니다.)
"Let's not speculate — let's look at the data." (추측하지 말고 데이터를 봅시다.)
"Can we get eyes on this?" (누가 이거 좀 확인해 줄 수 있나요?)
"What's the blast radius?" (영향 범위가 어떻게 되나요?)
"Is this customer-facing?" (고객에게 영향이 가는 건가요?)
"Let's page the database on-call." (데이터베이스 당직 엔지니어를 호출합시다.)

"Can everyone see my screen?"
(제 화면 보이시나요?)

"You're on mute."
(음소거 상태입니다.)

"Sorry, I was on mute. Let me repeat that."
(죄송합니다, 음소거였네요. 다시 말씀드리겠습니다.)

"I'm having some connectivity issues. Let me turn off my video."
(연결 상태가 좋지 않아서 비디오를 끄겠습니다.)

"Can you hear me okay? My audio seems to be cutting out."
(제 소리 잘 들리시나요? 음성이 끊기는 것 같습니다.)

"Let me drop off and rejoin — I'm having technical difficulties."
(기술적 문제가 있어서 나갔다 다시 들어오겠습니다.)

"Sorry, go ahead — I didn't mean to interrupt."
(죄송합니다, 말씀하세요 — 끊을 의도는 아니었습니다.)

"I'd like to add something to what [name] just said."
([이름]이 방금 말한 것에 추가하고 싶은 게 있습니다.)

"Could you elaborate on that a bit more?"
(그 부분을 좀 더 설명해 주실 수 있나요?)

"Let me share my screen to show you what I mean."
(제가 의미하는 바를 보여드리기 위해 화면을 공유하겠습니다.)

"I'll drop the link in the chat."
(링크를 채팅에 올려놓겠습니다.)

"Does anyone have any questions before we move on?"
(넘어가기 전에 질문 있으신 분?)

"Let me quickly recap the action items."
(액션 아이템을 빠르게 정리하겠습니다.)

"I'll send out the meeting notes after this."
(미팅 노트를 이후에 보내드리겠습니다.)

"Same time next week works for everyone?"
(다음 주 같은 시간 괜찮으세요?)

"Thanks everyone. I'll give you five minutes back."
(감사합니다. 5분 일찍 끝내겠습니다.)

Hey team! I just opened PR #427 for the user notification
refactoring. It's a medium-sized change (~300 lines) that
introduces a new event-driven architecture for notifications.

Key changes:
- Replaced polling mechanism with WebSocket-based events
- Added retry logic with exponential backoff
- Updated unit tests for the notification service

Would appreciate a review when you get a chance. PTAL!
No rush — targeting merge by end of sprint.

Subject: [Postmortem] SEV1 - Checkout Service Outage (2026-03-08)

Hi team,

Summary:
On March 8, 2026, we experienced an 18-minute outage affecting
the checkout service. Approximately 30% of checkout requests
returned 500 errors between 14:32 and 14:50 UTC.

Root Cause:
A configuration change reduced the database connection pool
size from 20 to 5 connections, causing connection exhaustion
under normal traffic load.

Impact:
- Estimated 1,200 failed checkout attempts
- Revenue impact: ~$45,000

Timeline:
- 14:30 UTC: Config change deployed
- 14:32 UTC: Alerts fired for elevated 5xx rates
- 14:35 UTC: Incident declared, war room opened
- 14:42 UTC: Root cause identified
- 14:47 UTC: Rollback initiated
- 14:50 UTC: Service fully recovered

Action Items:
1. Add validation checks to config deployment pipeline
2. Implement connection pool size alerts
3. Update runbook for database connection issues

Postmortem meeting: March 10, 2026, 2:00 PM UTC

Best regards,
[Your Name]