안녕하세요! 그로스로그 입니다!😊 🌱
브라우저가 몰래 넣는 옛 비밀번호, 확인 없이 보내고 끝나는 QoS 0. 시끄럽게 터지지 않아서 더 어려운 것들입니다.
5기 2회차는 큐레이션이 여섯 편이라 두 편으로 나눠 소개합니다. 먼저 세 편입니다.
01
📡 Eclipse Paho MQTT Python Client API
전병탁 님
MQTT 프로토콜을 이론부터 실습까지 한 편에 담은 글입니다. 탄생 배경, REST API와의 비교, 패킷 구조, QoS 3단계, 토픽 네이밍 원칙을 먼저 정리하고 실습 여섯 개를 실제로 돌립니다.
기본 Pub/Sub, QoS 레벨별 동작 비교, 다중 설비 동시 시뮬레이션, Retained Message, Will Message, 시계열 시각화까지. 코드와 실행 결과 로그가 나란히 붙어 있어요.
마지막 장이 장점 6 · 한계 4 · 도입 체크리스트 8개입니다. 제조 현장에 넣을 때 무엇을 확인해야 하는지로 끝맺습니다.
프로토콜 소개 글인데 "그래서 우리 현장에 넣을 수 있나"로 착지합니다.
조금 더 들어가 보면
MQTT를 설명하는 글은 대개 "가볍다"에서 시작합니다. 이 글은 왜 가벼워야 했는지부터 답니다.
제약이 먼저 있었고 설계가 따라 나왔다는 순서입니다. 그래서 고정 헤더가 최소 2바이트예요. HTTP 헤더가 수백~수천 바이트인 것과 비교하면 자릿수가 다릅니다.
⚖️ QoS — 신뢰성을 고르게 만든 설계
이 글에서 가장 값어치 있는 부분이 QoS입니다. 세 단계를 표로 갈라놨어요.
| QoS | 이름 | 동작 | 전달 보장 | 사용 시나리오 |
|---|---|---|---|---|
| 0 | At most once | Fire & Forget | ❌ 없음 | 온도 주기 데이터 (유실 허용) |
| 1 | At least once | PUBACK 확인 | ✅ 최소 1회 | 이상 알람, 공정 이벤트 |
| 2 | Exactly once | 4-way handshake | ✅ 정확히 1회 | 결제, 공정 레시피 변경 명령 |
QoS 0은 설계상 조용합니다. 보내고 끝이라 도착했는지 아무도 모릅니다. 그게 결함이 아니라 선택지예요. 온도를 1초마다 보내는데 한 건 빠진다고 큰일이 나진 않으니까요.
대신 알람은 다릅니다. 유실되면 아무도 모르는 채로 설비가 계속 돕니다. 그래서 QoS 1 이상이 필요하죠. 글이 QoS를 "성능 옵션"이 아니라 "무엇을 조용히 보내도 되는가에 대한 결정"으로 다룬 게 정확합니다.
🏷️ 토픽 설계 — REST URL과 같은 문제
토픽 네이밍을 다룬 대목도 실무적입니다.
{사이트}/{라인}/{설비ID}/{데이터타입}
fab1/line3/CVD001/sensor ← 정상 센서 주기 데이터
fab1/line3/CVD001/alarm ← 이상 알람 이벤트
fab1/line3/+/alarm ← line3 전체 설비 알람 (와일드카드 +)
fab1/# ← fab1 전체 (와일드카드 #)
금지 패턴까지 적었습니다 — /로 시작하면 빈 레벨이 생기고, 공백은 넣지 말고, $는 브로커 예약이며, 5레벨을 넘기지 말 것. 글이 붙인 한 줄이 이유를 요약합니다. "토픽은 REST URL 설계처럼 일관된 규칙이 없으면 운영 복잡도가 급격히 증가한다."
🏭 와일드카드가 수집 서버를 한 줄로 만든다
실습 3이 토픽 설계의 값어치를 눈으로 보여줍니다. 설비 세 대(CVD 챔버 · PVD 스퍼터 · 코팅 라인)가 각자 센서 데이터를 발행하는데, 수집 서버는 구독을 한 번만 겁니다.
[수집 서버] 연결 성공 → 와일드카드 구독: swe2026_jbt/fab1/#
그리고 로그가 이렇게 흐릅니다.
─── Round 3 ─── 📡 [센서] CVD001 | 온도=400.7°C | 압력=1.02 Torr 📡 [센서] PVD002 | 온도=275.5°C | 압력=0.556 Torr 📡 [센서] CTG003 | 온도=128.3°C | 압력=1.263 Torr 🚨 [알람] CVD001 | TEMP_HIGH_03 | 426.9°C (임계: 420°C)
설비가 열 대로 늘어도 수집 서버 코드는 그대로입니다. fab1/# 하나로 하위가 전부 딸려 오니까요. REST였다면 설비마다 엔드포인트를 알고 각각 폴링해야 합니다. 글이 앞에서 정리한 비교표의 한 줄이 여기서 실물이 됩니다 — 다대다 전달: REST 불가(1:1 요청-응답) / MQTT 가능(1:N, N:1, N:N).
알람이 임계 420°C에서 실제로 터진 것도 좋습니다. 시뮬레이션이지만 정상 데이터와 이벤트가 같은 파이프라인에서 다른 토픽으로 갈라지는 모습이 로그에 남았어요.
📝 원문에서는 이렇게 돌려봅니다
실습 4의 Retained Message가 이 글의 성격을 잘 보여줍니다. 개념 설명 대신 발행자를 끊고 나서 새 구독자를 붙입니다.
# retain=True → 브로커가 이 메시지를 저장, 이후 구독자에게 즉시 전달
pub4.publish(TOPIC_RETAIN, json.dumps(status_payload), qos=1, retain=True)
...
pub4.loop_stop(); pub4.disconnect() # 발행자를 먼저 끊는다
print('── 잠시 후 새 구독자 연결 (브로커 저장 메시지 수신 확인) ──')
그리고 수신 콜백에서 msg.retain 플래그를 찍어 실시간 메시지인지 저장분인지 구분합니다.
flag = '🗄️ [Retained]' if msg.retain else '📨 [실시간]'
실행 결과가 이렇게 나옵니다.
[신규 구독자] 🗄️ [Retained] 수신 설비: CVD001 | 상태: RUN | 레시피: LOGIC_90NM_V3 ✅ Retained Message 동작 확인 — 발행자 없이도 최신 상태 즉시 수신됨
발행자가 이미 끊긴 상태에서 새로 붙은 구독자가 최신 상태를 받았다는 게 로그 한 줄로 증명됩니다. 설명 열 줄보다 이 로그 한 줄이 강합니다.
Will Message도 같은 방식이에요. 클라이언트가 비정상 종료하면 브로커가 대신 발행하는 "유언 메시지"인데, 글은 이걸 "설비 에이전트가 예기치 않게 종료되면 운영자에게 즉시 알람"이라는 현장 용도로 바로 연결합니다.
🚧 한계를 네 개 적어둔 것
마지막 장의 한계 목록이 이 글을 소개 글에서 검토 자료로 바꿉니다.
· 브로커 단일 장애점 — 브로커가 죽으면 전체 데이터 흐름이 멈춥니다. 고가용성 클러스터링 필수
· 보안 기본 설정 취약 — 1883 포트는 평문입니다. 운영은 TLS(8883) + 인증
· 토픽 설계 복잡도 — 설비가 늘면 토픽 구조 관리가 어려워집니다
· 메시지 순서 미보장 — QoS 1 이상이어도 다중 구독자 간 순서는 보장되지 않습니다
마지막 항목이 특히 중요합니다. QoS를 올리면 다 해결될 것 같지만 순서는 별개라는 것. 이걸 모르고 설계하면 "전달은 됐는데 순서가 뒤집혀서" 생기는 버그를 나중에 만납니다.
체크리스트 여덟 개도 실물입니다. 브로커 이중화 · TLS 인증서 · 클라이언트 ID 충돌 방지(설비ID + MAC 조합) · 토픽 네이밍 문서화 · QoS 정책 수립(주기 센서 QoS 0, 알람 QoS 2) · Retained로 상태 관리 · Will을 모든 에이전트에 · 메시지 스키마 버전 관리.
큐레이터 노트
돌려보고 나서 도입 조건을 적은 글이라 뽑았습니다.
API 실습 글은 보통 "동작 확인 완료"로 끝납니다. 이 글은 실습 여섯 개를 다 돌린 다음 한계 네 개와 체크리스트 여덟 개를 붙였어요. 순서가 중요합니다. 해보기 전에 쓴 주의사항은 문서 요약이지만, 해보고 쓴 것은 경험이니까요.
실행 결과 로그를 그대로 남긴 것도 좋았습니다. DeprecationWarning: Callback API version 1 is deprecated 같은 경고까지 지우지 않고 붙였어요. 다듬으면 깔끔하겠지만, 그대로 두니 따라 하는 사람이 자기 화면과 대조할 수 있습니다.
마무리 문단의 관점도 인상적이었습니다.
프로토콜 하나를 배운 기록이 아니라 그 프로토콜이 어느 층을 떠받치는지를 아는 사람의 문장입니다. 이어서 "센서 임계값 초과 → MQTT 이벤트 → AI 분석 → 운영자 조치"라는 파이프라인을 그리는데, MQTT를 전달 도구가 아니라 이벤트 드리븐 아키텍처의 트리거로 놓는 시각이 이 회차의 다른 글들과도 이어집니다.
02
🔐 비밀번호 맞는데 로그인이 안 된다? - 쉽게 찾기 힘든 원인
강단 님
"비밀번호가 분명히 맞는데 로그인이 안 되는" 현상의 원인을 추적한 글입니다. 범인은 브라우저 비밀번호 관리자와 HTML
autocomplete 속성 누락이었어요.사용자가 당장 쓸 수 있는 우회법 세 가지와, 개발자가 넣어야 할 한 줄을 나눠서 정리했습니다.
autocomplete 값 치트시트도 표로 붙였고요.후반부가 이 글의 핵심입니다. 왜 이 버그는 쉽게 못 잡는가 — 디버깅 경로 여섯 개가 전부 막혀 있는 이유를 하나씩 짚습니다.
증상 목록으로 시작해서 "당신의 비밀번호가 틀린 게 아닙니다"로 넘어가는 도입이 좋습니다.
조금 더 들어가 보면
문제의 흐름이 단순합니다. 그런데 그 단순함이 함정이에요.
1. 사용자가 비밀번호를 old1234 → new5678로 변경한다
2. 브라우저 비밀번호 관리자는 변경 사실을 인지하지 못한다
3. 다음 로그인 때 브라우저가 old1234를 자동으로 채운다
4. 사용자는 "맞게 넣었는데?"라고 생각하지만 실제로는 옛 비밀번호가 전송된다
5. 로그인 실패
글이 4번 아래 붙인 한 줄이 이 버그의 성격을 정확히 짚습니다.
마스킹이 방어이면서 동시에 시야를 가립니다. 화면에 찍힌 점 여덟 개가 옛 비밀번호인지 새 비밀번호인지 구분할 방법이 없어요.
🏷️ 원인은 브라우저가 추측하고 있었다는 것
진짜 원인은 HTML autocomplete 속성입니다. 이 속성이 하는 일은 입력 필드가 자기 역할을 브라우저에게 알려주는 것이에요.
<!-- 로그인 폼: "이건 현재 비밀번호야" --> <input type="text" autocomplete="username" /> <input type="password" autocomplete="current-password" /> <!-- 비밀번호 변경 폼: "이건 새 비밀번호야" --> <input type="password" autocomplete="new-password" />
없으면 어떻게 되느냐 — 글의 표현이 정확합니다. 브라우저는 추측으로 동작합니다.
id="password"니까 비밀번호겠지, type="text"인데 비밀번호 필드 위에 있으니 아이디겠지... 이런 추측이 맞을 때도 있고 틀릴 때도 있다."특히 비밀번호 변경 폼에서 문제가 커집니다. new-password가 없으면 크롬은 새 비밀번호 칸을 로그인용으로 오인하고, 변경 후에도 업데이트를 제안하지 않습니다. 결과는 이렇게 됩니다 — "사용자의 브라우저에는 영원히 옛날 비밀번호가 저장되어 있게 된다."
🧯 지금 막힌 사람이 당장 할 수 있는 것
글이 친절한 지점이 여기입니다. 개발자용 해법과 사용자용 해법을 따로 적었어요. 코드를 고쳐도 이미 브라우저에 저장된 옛 비밀번호는 그대로 남아 있으니까요.
1. 직접 타이핑해서 로그인 — 자동완성된 내용을 전부 지우고 새 비밀번호를 손으로 칩니다. 크롬이 "비밀번호를 업데이트하시겠습니까?"라고 물으면 업데이트를 누릅니다
2. 저장된 비밀번호 직접 수정 — 주소창에 chrome://password-manager/passwords를 넣고 해당 사이트를 찾아 고칩니다
3. 삭제 후 재저장 — 저장된 항목을 지우고 새 비밀번호로 로그인한 뒤 다시 저장합니다
고객 문의로 들어왔을 때 그대로 안내할 수 있는 형태입니다. 원인을 찾은 사람이 고칠 사람과 지금 불편한 사람을 나눠서 답을 준 것이죠.
React 프로젝트라면 고치는 쪽은 정말 한 줄입니다.
// Before
<input type="password" value={password} onChange={handleChange} />
// After
<input type="password" value={password} onChange={handleChange}
autoComplete="current-password" />
🕵️ 왜 이 버그는 쉽게 못 잡는가
이 글에서 가장 값어치 있는 부분입니다. 디버깅 경로를 하나씩 막아 보여줘요.
| 디버깅 방법 | 왜 안 되는가 |
|---|---|
| API 로그 확인 | 서버는 "틀린 비밀번호"만 봅니다. 브라우저가 넣은 건지 사용자가 친 건지 구분 불가 |
| E2E 테스트 | Playwright·Cypress는 값을 직접 주입하므로 자동완성 동작과 무관 |
| 코드 리뷰 | autocomplete 누락을 지적하는 리뷰어가 거의 없음 |
| 린터·정적 분석 | ESLint, SonarQube 등에 관련 규칙이 없음 |
| AI 코드 리뷰 | 현재 어떤 AI 도구도 이 속성 누락을 경고하지 않음 |
| 사용자 리포트 | "내 브라우저 문제겠지"라고 생각하고 수동으로 우회함 |
여섯 개가 전부 막혀 있습니다. 자동화된 안전망이 하나도 안 걸리는 종류의 결함이에요.
E2E 테스트 항목이 특히 뼈아픕니다. 테스트를 잘 짜뒀어도 못 잡습니다. 테스트 도구는 값을 직접 주입하니까요. 브라우저가 자동완성으로 채우는 경로는 테스트가 지나가는 길이 아닙니다. "테스트가 통과했으니 괜찮다"가 성립하지 않는 구간이 여기 있습니다.
그럼 어떻게 찾았느냐 — 글이 적은 발견 계기가 이 글에서 가장 오래 남는 대목입니다.
코드를 본 게 아니라, 사용자의 행동을 본 것.
📝 원문에서는 이렇게 확인합니다
실제 프로젝트 점검 결과가 숫자로 붙어 있습니다. 운영 중인 관리자 페이지(React + TypeScript)를 전수 조사했더니 password 관련 입력 필드 16개 전부 autocomplete 속성이 없었습니다.
| 유형 | 개수 | 적용한 값 |
|---|---|---|
| 로그인 아이디 | 1 | username |
| 로그인 비밀번호 | 1 | current-password |
| 새 비밀번호 / 확인 | 10 | new-password |
| TOTP PIN | 1 | one-time-code |
| 민감값 마스킹 | 2 | off |
수정 시간 30분. 공통 입력 컴포넌트에 prop 하나 추가하고 사용처에 값을 전달한 게 전부였다고 합니다.
그리고 남의 프로젝트에서도 바로 돌려볼 수 있게 명령어를 하나 남겼습니다.
# 프로젝트에서 autocomplete 없는 password 필드 찾기 grep -rn 'type="password"' src/ | grep -v 'autocomplete'
큐레이터 노트
자동화가 하나도 안 잡아주는 결함을 다룬 글이라 뽑았습니다.
버그 해결기는 많지만 대개 "이렇게 고쳤다"로 끝납니다. 이 글은 "왜 여태 아무도 못 잡았는가"에 표 하나를 통째로 씁니다. 린터도, 정적 분석도, AI 코드 리뷰도, E2E 테스트도 안 걸린다는 걸 하나씩 확인한 목록이에요. 그 목록 덕분에 이 글은 버그 하나가 아니라 "우리 안전망에 뚫린 구멍의 모양"을 알려줍니다.
숫자가 붙어 있는 것도 좋았습니다. 필드 16개 전부 누락, 수정 30분. "많이 빠져 있었다"가 아니라 세어본 결과입니다.
마지막 관찰이 이 문제가 왜 흔한지를 설명합니다.
autocomplete는 2014년 HTML5부터 있던 속성이다. 10년 넘게 존재했지만, 대부분의 SPA 프로젝트에서 빠져 있다. 프레임워크 문서가 아니라 HTML spec에 있기 때문에, React/Vue만 공부한 개발자는 접할 기회가 없다."자료가 드문 영역이라기보다, 자료가 있는데 읽는 경로에서 벗어나 있는 영역입니다. 프레임워크로 입문한 사람이 늘수록 이런 구멍은 더 흔해질 거예요. 그래서 이 기록이 뒤에 오는 사람의 시간을 아낍니다.
03
🎭 4. Waiting fo(u)r Godot
이황수 님
사무엘 베케트의 희곡 「고도를 기다리며」에 빗대어 한 주를 정리한 성장일지입니다. 1막과 2막의 구조가 거의 같은 희곡처럼, 기출을 풀고 틀린 걸 체크하고 다음 날 또 푸는 반복을 그 구조에 겹쳐 놓았어요.
학교 특강(AI, Coder, and Developer) 정리가 절반을 차지합니다. AI와 윤리, 붉은 여왕의 역설, 트렌드를 논문으로 읽는 법까지.
토이 프로젝트 MarketRadar 개선기, 기사 시험 준비, Google Study Jam, 학교 시스템 버그 리포트가 이어집니다. 연재 4편째예요.
제목부터 말장난입니다. Waiting fo(u)r Godot — 4편이면서 고도를 기다린다는 뜻이죠.
조금 더 들어가 보면
이 글의 구조가 재미있습니다. 희곡의 형식을 자기 한 주에 그대로 대응시켰어요.
"이번 주가 딱 그런 느낌이었다."
성장일지에서 가장 쓰기 어려운 회차가 아무 일도 일어나지 않은 주입니다. 대개 건너뛰거나 억지로 뭔가를 만들어 씁니다. 이 글은 그 반복 자체를 형식으로 삼았어요.
🧭 특강에서 건진 것 — 변화의 목록
학교 특강 정리가 이 글의 중심입니다. 한 문장 요약을 이렇게 적었어요.
그리고 무엇이 달라졌는지를 목록으로 받아 적었습니다.
· 프로그램을 배우는 방법의 변화 (한 언어를 깊게 파고들던 방식에서)
· 개발 과정의 변화 (오타와의 전쟁)
· 코드 중심에서 자연어로의 변화
· 스탠드얼론 대화형 AI에서 역할 중심의 복합체(에이전트)로
· 소프트웨어 개발 생명주기 전 과정에서 가속되는 속도
· 높아진 생산성 vs 관리 복잡도의 증가
마지막 항목이 이 회차의 다른 글들과 곧장 이어집니다. 생산성이 오르면 관리할 것도 같이 늘어난다는 것. 강단 님 글의 "AI 코드 리뷰도 이 속성 누락을 경고하지 않는다"가 바로 그 관리 복잡도의 한 조각이죠.
⚖️ AI와 윤리 — 인용 하나가 남습니다
특강에서 윤리를 다룬 대목을 따로 떼어 적었습니다.
글쓴이가 이 대목을 "이채로웠다"고 표현한 게 정직합니다. 기술 특강에서 윤리에 지면을 할애하는 게 흔치 않으니까요. 그러면서 왜 필요한지를 덧붙입니다 — FOMO 때문에 속도에 신경 쓰다 보면 개발 윤리가 뒤로 밀린다는 이야기가 돌곤 한다고요.
🔴 붉은 여왕의 역설
특강에서 나온 개념 하나를 자기 언어로 늘려 씁니다.
거울나라에서는 모두가 일정한 속도로 멀어지기 때문에 제자리에 있으려면 그 속도로 뛰어야 하고, 앞으로 가려면 두 배로 뛰어야 합니다. 글은 여기에 커뮤니티에서 실제로 들은 말들을 붙여요 — "언제까지 열심히 해야 할까?", "노력이라는 말이 싫어서 SNS에서 그 단어를 뮤트했어."
그리고 자기 답을 냅니다. 결국은 수많은 정보를 입력하고 다시 출력할 수 있어야 하니, 최대한 기술로 그 스트레스를 줄이는 게 답이 아닐까라고요. 번아웃을 의지 문제로 두지 않고 처리량 문제로 옮긴 것이 이 글다운 대목입니다.
📰 트렌드는 논문으로
Q&A에서 나온 짧은 대화 하나도 실용적입니다.
A. 전 논문으로 트렌드를 읽어서요
여기에 자기 경험을 붙입니다. 특허와 논문 위주로 챙기면 "어지간한 기사보다 더 빠르게 트렌드를 파악할 수 있다"고요. 다만 한계도 같이 적습니다 — 노이즈 같은 논문이 섞여 있어 자체 필터링이 쉽지 않다는 것, 차라리 유료 리서치 보고서가 편할 때도 있다는 것.
📝 원문에서는 이렇게 남깁니다
토이 프로젝트 MarketRadar 개선 기록이 이 글에서 유일하게 숫자가 붙은 부분입니다.
한 문단에 다섯 가지 사건이 압축돼 있습니다. 그중 "변수명 하나 때문에 뉴스가 조용히 안 오는 버그"가 이 회차와 정확히 겹쳐요. 에러도 안 나고 화면도 멀쩡한데 결과만 비어 있는 종류의 실패입니다.
1분대 → 5초대라는 숫자도 좋습니다. "빨라졌다"가 아니라 잰 값이에요.
🎮 이름의 유래를 따라간 곁가지
제목이 「고도를 기다리며」에서 왔으니, 같은 이름의 게임 엔진 이야기로 한 번 새어 나갑니다. Godot 엔진이 그 희곡에서 이름을 딴 것이고, 유니티가 이용정책으로 흔들리던 때 대안으로 급부상했다는 것. Scene과 Node로 이어진 구조가 유니티와 비슷하고 GDScript는 파이썬을 닮았으며 C++·C#도 지원하고 무료라는 것. 최근 나온 게임 하나가 이 엔진으로 만들어졌다는 것까지요.
본론과 상관없는 곁가지인데, 이런 게 있어야 한 사람이 무엇에 반응하는지가 드러납니다. 정보만 남긴 글에는 없는 부분이에요.
학교 시스템 버그 리포트 이야기도 짧지만 남습니다. 제출한 폼의 데이터가 관리자 화면에 안 뜨는데 본인 쪽에서는 재현이 불가능한 상황이었어요. 그래서 간단한 양식을 만들어 전산팀 전달을 부탁하며 메일에 첨부했다고 합니다. 재현이 안 되니 못 고친다가 아니라, 재현 안 되는 상태 그대로 넘길 수 있게 정리한 것이죠.
큐레이터 노트
아무 일도 없던 주를 형식으로 쓴 글이라 뽑았습니다.
성장일지에서 제일 어려운 게 이런 회차입니다. 기출 풀고 채점하고 다음 날 또 푸는 게 전부인 주요. 이 글은 그 반복을 감추지 않고 1막과 2막이 거의 같은 희곡에 겹쳐 놓았습니다. 형식을 빌려 왔더니 반복이 결함이 아니라 내용이 됐어요.
특강을 요약이 아니라 재료로 쓴 것도 좋았습니다. 슬라이드 내용을 옮기는 데서 멈추지 않고, 붉은 여왕의 역설에는 커뮤니티에서 들은 말을 붙이고 자기 답을 냈어요. 트렌드를 논문으로 읽는다는 답에는 실제로 해본 경험과 그 한계를 같이 적었고요. 들은 것과 겪은 것이 구분되게 써 있습니다.
연재라는 점도 짚어두고 싶습니다. 제목이 매번 회차 번호를 담은 말장난이고, 5기 안에서 열 편까지 이어졌어요. 한 편만 보면 잡다한 기록이지만 모아 놓으면 한 사람이 반년 동안 무엇을 향해 갔는지가 드러납니다. 이 회차의 마지막 문장이 그 태도를 요약합니다.
💡 세 편을 겹쳐 읽으며
프로토콜 실습, 브라우저 버그, 성장 기록. 장르가 다 다른데 세 편이 같은 것을 무서워하고 있습니다.
조용히 틀리는 것
강단 님 글의 로그인 실패는 시끄럽게 실패하지만 원인은 조용합니다. 서버 로그에는 "틀린 비밀번호"만 남고, 그걸 누가 넣었는지는 어디에도 안 남아요.
전병탁 님 글의 QoS 0은 설계상 조용합니다. Fire & Forget이라 도착 여부를 아무도 확인하지 않습니다. 그래서 무엇을 QoS 0으로 보낼지가 곧 "무엇이 조용히 사라져도 괜찮은가"를 정하는 일이 됩니다.
이황수 님 글에는 그 표현이 그대로 나옵니다. 특강 전에 읽은 기사에 "AI 쓰레기 코드와 조용한 실패"가 있었고, 본인 프로젝트에서도 "변수명 하나 때문에 뉴스가 조용히 안 오는 버그"를 잡았어요.
시끄러운 실패는 알아서 신고를 합니다. 문제는 조용한 쪽입니다. 에러도 안 나고 테스트도 통과하는데 결과만 비어 있는 것들이요.
자동으로 해주는 것이 무엇을 추측하는지 알기
세 글 다 "알아서 해주는 층"을 한 번 열어봅니다.
브라우저는 알아서 비밀번호를 채워줍니다 — 속성이 없으면 추측으로요. 브로커는 알아서 메시지를 전달해줍니다 — QoS를 안 정하면 확인 없이요. AI는 알아서 코드를 짜줍니다 — push는 사람이 하는 거고요.
편의를 주는 층이 무엇을 가정하고 있는지 모르면, 그 가정이 틀린 날 원인을 찾을 수 없습니다. 세 글이 각자 그 가정을 명시적으로 만드는 방법을 하나씩 남겼어요. autocomplete 속성, QoS 레벨, 그리고 "push한 사람이 책임진다"는 원칙입니다.
안 잡히는 것을 잡을 장치를 직접 만든 것
세 번째 공통점은 결과물의 모양입니다. 셋 다 체크리스트나 명령어로 끝납니다.
강단 님은 grep 한 줄과 확인 항목 네 개를, 전병탁 님은 도입 체크리스트 여덟 개를 남겼습니다. 이황수 님은 재현이 안 되는 버그를 리포트 양식으로 만들어 전산팀에 넘겼고요.
막힌 걸 확인하고 나면 그다음에 할 일은 우회로를 만드는 것입니다. 린터가 안 잡아주면 grep을 짜고, 재현이 안 되면 양식을 만들고, 표준이 보장 안 해주면 체크리스트를 씁니다.
이번 회차에서 가져갈 것
1. type="password"가 있는 곳에 autocomplete이 있는지 지금 확인하기.
grep -rn 'type="password"' src/ | grep -v 'autocomplete' 한 줄이면 됩니다. 로그인은 current-password, 변경 폼은 new-password, OTP는 one-time-code, 비밀번호가 아닌데 마스킹만 하는 필드는 off입니다.
2. E2E 테스트가 통과해도 자동완성 경로는 안 지나간다.
테스트 도구는 값을 직접 주입하니까요. 테스트로 덮이지 않는 구간이 어디인지를 아는 것이 테스트 커버리지 숫자보다 중요할 때가 있습니다.
3. QoS는 성능 옵션이 아니라 "무엇이 사라져도 되는가"의 결정.
주기 센서는 0, 알람은 1 이상. 그리고 QoS를 올려도 순서는 보장되지 않는다는 걸 같이 기억해 두세요.
4. 상태는 Retained로, 종료는 Will로.
대시보드가 재시작해도 현재 상태를 즉시 받으려면 retained가 필요하고, 에이전트가 비정상 종료된 걸 알려면 Will이 필요합니다. 둘 다 "조용히 모르고 지나가는 것"을 막는 장치입니다.
5. 재현이 안 되는 버그는 재현 안 되는 채로 넘기기.
양식을 만들어 상황·기대·실제를 적어 전달하면 담당자가 자기 환경에서 확인할 수 있습니다. 재현될 때까지 붙잡고 있는 것보다 낫습니다.
6. 반복되는 주도 기록의 재료가 된다.
아무 일 없던 회차를 건너뛰면 연재가 끊기고, 나중에 돌아봤을 때 그 구간이 통째로 비어 있습니다. 반복을 형식으로 삼는 방법도 있습니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
좋은 글 남겨주신 전병탁 님, 강단 님, 이황수 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.