함께 일한 기록

코드도 문서도 받지 못한 채로, 경우의 수를 준비해 갔습니다

상황

부산 도시철도 관제에서 협업처에서 CCTV 연동 코드도 문서도 받지 못했습니다. 카메라 주소만 넘어왔고, 저쪽 서버가 어떤 방식으로 서 있는지는 붙여 보기 전에는 알 수 없었습니다.

내가 한 일

답을 기다리는 대신 WebRTC 자체를 먼저 조사했습니다. RTSP를 브라우저로 가져오는 경로를 정리하고 '이렇게 구현했을 수도 있다'는 경우를 나열한 뒤, 각 경우에 맞는 연결 코드를 준비한 상태로 현장에 들어가 하나씩 대 봤습니다.

결과

현장에서 헤매지 않고 맞는 방식을 찾아 CCTV를 올렸고, 이후로도 현장에서 나오는 문제를 고치며 운영을 이어 갔습니다.

현장에서 고치고 그 자리에서 다시 올렸습니다

상황

지하철 폐쇄망 현장은 배포 직후에야 드러나는 실시간 버그와 데이터 오류가 있었습니다. 사무실에서는 재현되지 않았습니다.

내가 한 일

현장에 나가 직접 디버깅하고, 수정하고, 그 자리에서 재배포하는 사이클을 반복했습니다.

결과

이후 프로젝트에서는 개발 단계부터 실제 사용 환경에서 무엇이 깨질지를 먼저 따져 봅니다.

화면은 멀쩡한데 값만 틀린 버그를 화면 반영 전에 잡았습니다

상황

서버가 홀별 par에 null을 내려줬고, 앱은 방어적으로 0으로 보정했습니다. 크래시도 에러도 없이 모든 홀이 더블보기로 색칠되는, 잡기 어려운 종류의 오류였습니다.

내가 한 일

같은 응답을 런타임 스키마(앱이 실제로 깨지는가)와 엄격 스키마(서버가 문서대로 주는가)로 두 번 파싱하는 계약 테스트를 만들어 검출했습니다. 전달할 때 'null을 0으로 보정한 건 앱의 임시 조치일 뿐 정답이 아니다'까지 함께 적었습니다.

결과

증상이 없는 계약 위반을 사용자에게 도달하기 전에 잡는 경로가 생겼습니다. 실서버를 호출하는 테스트지만 자격증명이 없으면 skip하도록 해 서버 장애가 남의 커밋을 막지 않게 했습니다.

npm run test:api · shared/test/contract/strict.ts

응답 불일치를 필드 단위 표로 정리해 전달했습니다

상황

인증 실패가 BAD_VERIFY_CODE 하나로 내려와, 앱이 '재입력'과 '재발송' 중 무엇을 안내할지 판단할 수 없었습니다. 비슷한 응답 형태 불일치가 여기저기 흩어져 있었습니다.

내가 한 일

불일치 12건을 엔드포인트·필드·서버가 주는 값·기대값·앱 영향·우선순위(P0/P1) 표로 정리해 전달했습니다. 코드 3분리와 retryAfterSeconds 추가를 제안하되, 모두 하위 호환을 깨지 않는 형태로 설계해 수용 부담을 낮췄습니다.

결과

요청이 '고쳐 주세요'가 아니라 '무엇을·왜·언제까지'로 바뀌면서 우선순위 협의가 가능해졌습니다.

docs/api/backend-error-handling-request.md · verify-error-contract.md

프로젝트마다 다시 만들던 공통 컴포넌트를 모노레포로 걷어냈습니다

상황

다수의 관제 SI 프로젝트가 비슷한 컴포넌트를 각자 복사해 쓰고 있었습니다.

내가 한 일

공통 컴포넌트를 추출해 모노레포 구조의 디자인 시스템으로 재설계했습니다.

결과

새 SI가 시작될 때 UI를 처음부터 만들지 않아도 되는 출발선이 생겼습니다.

디자이너가 고칠 파일을 3개로 좁혔습니다

상황

로딩·에러·빈 상태 시안이 나올 때마다 화면 수만큼 고쳐야 하는 구조였습니다. 반영이 늦어지고 화면끼리 어긋났습니다.

내가 한 일

모든 화면을 QueryState로 감싸고 실제 모양은 LoadingState·ErrorState·EmptyState 세 파일에만 두었습니다. 이 교체 지점을 문서에 명시해 디자이너와 합의했습니다.

결과

시안이 오면 3개 파일만 고치면 전 화면에 반영됩니다. 화면별로 어긋날 여지가 사라졌습니다.

docs/app/07-error-handling.md — 디자이너 교체 지점

확정할 수 없는 건 추측으로 고치지 않고 선택지로 남겼습니다

상황

목록과 상세가 동반자 수를 다르게 계산했습니다. 서버 players에 본인이 포함되는지 문서에 명시가 없어 어느 쪽이 맞다고 단정할 수 없었습니다.

내가 한 일

코드를 건드리는 대신 선택지 3안과 각각의 비용, 결론을 내리는 데 필요한 최소 정보(실응답 한 건)를 문서로 남겼습니다. 계약 테스트에는 실패시키지 않는 [확인] 항목으로 심어 두고 관찰했습니다.

결과

잘못된 추측이 코드에 굳는 걸 막고, 판단에 필요한 정보를 가진 사람이 결정할 수 있게 넘겼습니다.

docs/features/12-players-display.md

필요한 산출물을 체크리스트로 먼저 정리해 건넸습니다

상황

앱 아이콘은 플랫폼마다 규칙이 다릅니다. iOS는 투명 배경이면 심사에서 거부되고, Android 적응형 아이콘은 전경·배경 레이어 분리와 중앙 66% 세이프존을 지켜야 합니다.

내가 한 일

필요한 산출물·크기·금지사항을 체크리스트로 정리해 먼저 전달했습니다. 스토어 등록용 피처 그래픽과 스크린샷도 같은 방식으로 요청 목록을 만들었습니다.

결과

재작업 없이 한 번에 받았습니다. 디자이너가 플랫폼 규칙을 찾아다닐 일이 없어졌습니다.

docs/app/06-app-icon.md — 디자이너 전달용 체크리스트

시안의 고정 px를 그대로 옮기지 않고 근거를 맞췄습니다

상황

디자인 기준폭은 375, 실기기는 아이폰 프로 393이었습니다. 고정 px를 그대로 옮기면 화면 폭 대비 글자가 작아 보입니다.

내가 한 일

폭 보정(393/375 ≈ 1.05)에 '실기기에서 한 단계 더 키우자'는 디자이너 판단을 더해 타입 스케일을 재정의했습니다. 런타임 폭 스케일은 대상 기기 폭 편차가 좁아 실익이 작다고 판단해 채택하지 않았고, 그 이유도 함께 남겼습니다.

결과

'시안대로 했는데 작아 보인다'는 왕복이 사라지고, 다음 시안부터는 같은 스케일 위에서 이야기하게 됐습니다.

docs/app/16-typography.md · 디자인 커밋 65건

배운 것이 저에게만 남지 않도록 팀에 옮겨 두었습니다

상황

인턴 시절, 배운 것이 개인 노트에만 쌓이고 팀에 남지 않는 게 아깝다고 느꼈습니다.

내가 한 일

Confluence에 기술 문서를 남기기 시작하고, 퇴근 후 동료들과 스터디를 열어 일일 학습 기록을 공유했습니다. 이후 부트캠프에서는 프리코스 학생 대상으로 프론트·백엔드 크로스 강의를 진행했습니다.

결과

스터디 3개를 팀장으로 맡아, 발표한 내용을 Wiki로 정리해 왔습니다.