개발자 영어 제안 표현: How about으로 구현 의견 꺼내기

• 무엇을 바꿀지 먼저 정하기
• 구현 제안과 이유
• 상대의 질문에 따라 제안 조정
• 근거가 있는 PR 의견 연습

무엇을 바꿀지 먼저 정하기

아래 대화와 작업 결과는 학습용 가상 상황입니다. 문장을 사용할 때는 본인이 확인한 사실과 실제 일정으로 바꾸세요.

상품 검색 결과가 없을 때 화면에 아무 안내도 나오지 않는 상황입니다. 사용자는 로딩 중인지 결과가 없는지 구분하기 어렵습니다. 빈 결과 안내와 테스트를 추가하자는 PR 의견을 작성합니다. 실제 개선 효과를 측정한 상황은 아니므로, 사용자 행동이 얼마나 바뀐다고 수치를 만들지 않습니다.

한국어 발음은 소리 내어 읽기 위한 보조 표기입니다. 실제 영어의 소리와 강세를 완전히 나타내지는 못합니다.

구현 제안과 이유

How about adding a message when there are no results?

뜻: 결과가 없을 때 안내 문구를 추가하는 건 어떨까요?

발음: 하우 어바웃 애딩 어 메시지 웬 데어 아 노우 리절츠?

이 형태에서는 How about 뒤에 adding처럼 -ing 형태를 사용합니다.

That would help users tell whether the search has finished.

뜻: 그러면 사용자가 검색이 끝났는지 구분하는 데 도움이 될 것입니다.

발음: 댓 우드 헬프 유저즈 텔 웨더 더 서치 해즈 피니시드.

제안을 통해 기대하는 이유입니다. 이미 검증한 효과와는 구분합니다.

Could we also add a test for the empty state?

뜻: 결과가 없는 상태에 대한 테스트도 추가할 수 있을까요?

발음: 쿠드 위 올소 애드 어 테스트 포 디 엠프티 스테이트?

Could we 뒤에서는 add처럼 동사원형을 씁니다. 앞 문형의 -ing와 섞지 않습니다.

상대의 질문에 따라 제안 조정

동료

Should we add a Retry button too?

뜻: 재시도 버튼도 추가해야 할까요?

발음: 슈드 위 애드 어 리트라이 버튼 투?

개발자

This is an empty result, not a failed request. Let's keep the message simple.

뜻: 이것은 요청 실패가 아니라 결과가 없는 상태입니다. 안내 문구를 간단하게 유지합시다.

발음: 디스 이즈 언 엠프티 리절트, 낫 어 페일드 리퀘스트. 렛츠 킵 더 메시지 심플.

검색 성공 후 결과가 0개인 상태와 요청 실패를 구분한 가상 상황입니다. 실패 화면의 재시도 정책까지 정하는 문장은 아닙니다.

다른 상황에 적용: 폼 로직 분리

How about moving the shared validation logic into a custom hook?

뜻: 공통 입력값 검사 로직을 커스텀 훅으로 옮기는 건 어떨까요?

발음: 하우 어바웃 무빙 더 셰어드 밸리데이션 로직 인투 어 커스텀 훅?

Both forms use the same rules.

뜻: 두 폼이 같은 규칙을 사용합니다.

발음: 보쓰 폼즈 유즈 더 세임 룰즈.

위 예시는 상태나 다른 훅을 함께 다루는 공통 로직을 검토하는 상황입니다. 단순한 값 검사 함수까지 언제나 커스텀 훅으로 만들어야 한다는 뜻은 아닙니다. 이름만 보고 구조 변경을 권하지 말고, 어떤 중복을 줄일지 밝히세요.

다른 상황에 적용: 캐시 제안의 보류

How about caching the results for five minutes?

뜻: 결과를 5분 동안 캐시하는 건 어떨까요?

발음: 하우 어바웃 캐싱 더 리절츠 포 파이브 미니츠?

Let's confirm how fresh the data needs to be first.

뜻: 먼저 데이터가 얼마나 최신 상태여야 하는지 확인합시다.

발음: 렛츠 컨펌 하우 프레시 더 데이터 니즈 투 비 퍼스트.

5분은 이 대화의 검토 후보입니다. 모든 데이터에 적합한 캐시 시간이라는 뜻은 아닙니다. 제안을 받았다고 즉시 수락해야 하는 것은 아니며, 판단에 필요한 정보부터 요청할 수 있습니다.

근거가 있는 PR 의견 연습

폼 제출에 실패하면 사용자가 입력한 내용이 모두 지워집니다. 실패했을 때 입력값을 유지하자는 의견과, 다시 입력할 필요를 줄인다는 이유를 적으세요. 성공 후 폼 초기화까지 막자는 뜻이 되지 않게 조건을 넣습니다.

How about keeping the form values when submission fails?

Then users wouldn't have to enter everything again.

Could we add a test for that case?

다음 Day 9에서는 이런 제안을 받은 입장에서 동의하는 범위와 필요한 조건을 답합니다. 복습할 때는 제안 문장만 다시 읽지 말고, 왜 필요한지 한 문장으로 설명해 보세요.