기획과 개발 사이, 판단이 필요한 자리에서.
개념의 “왜·언제”를 중심으로 다룹니다. 코드까지 굳이 내려가진 않습니다.
글 — 최근에 쓴 것
전체 140편 →
시각장애인 고객도 전자동의를 할 수 있을까 — 체크해도 「선택 안 됨」으로 읽히던 화면의 스크린리더 접근성 점검
전자동의는 화면에서 체크하고 서명하면 끝날까요. 스크린리더로 듣는 시각장애인 고객에게는 체크한 항목이 「선택 안 됨」으로 읽힐 수 있습니다. 이미 한 번 손본 모바일 전자계약 화면을 접근성 트리로 다시 점검해 찾은 문제 4가지와, 서버 코드를 건드리지 않고 고친 방법을 정리합니다.
전자동의 기록 보관 방법 — ISMS-P 가 보는 항목과, '고객이 본 문구'까지 남기는 스냅샷 설계
개인정보 동의 기록은 무엇을, 언제까지, 어떤 형태로 남겨야 할까요. ISMS-P 인증기준 3.1.1 이 요구하는 기록 항목과 보존기간, 심사에서 보는 증거자료와 결함사례를 먼저 정리하고, 동의 결과만이 아니라 고객이 본 문구까지 남기는 스냅샷 방식을 실무 경험으로 풀어 봅니다.
본인인증과 전자서명 차이 — 문자 인증번호와 PASS·카카오 서명, 전자계약에서는 어디까지 될까
문자로 받은 6자리 인증번호와 PASS·네이버·카카오로 하는 전자서명은 무엇이 다를까요. 본인인증과 전자서명의 차이를 관련 법령으로 정리하고, 전자계약에서 본인인증으로 충분한 경우와 전자서명이 필요한 경우, 전자서명으로도 안 되는 경우를 예시로 나눴습니다. 어르신께 안내하는 방법도 함께 담았습니다.
AI가 고친 .js 파일만 CRLF 줄바꿈으로 바뀌는 이유 — BOM·LF가 깨지는 경우 실측 비교
BOM·LF 로 잘 있던 .js 파일이 AI 에게 한 줄 고쳐 달라고 한 뒤 CRLF 로 바뀌어 있었습니다. 범인은 AI 가 아니라 AI 가 파일을 쓴 경로였습니다. 같은 파일을 도구 13가지로 고쳐 보고, 실제 저장소에서 24개 파일이 뒤집힌 과정을 추적했습니다.
현업에서 기획 역할을 처음 맡으면 — 도구를 찾기 전에 정해야 할 업무 R&R 세 가지
현업팀에서 기획 역할을 새로 맡아 개발팀과 일하게 된 분에게 질문 일곱 개를 받았습니다. 히스토리 관리, 진척 트래킹, 요청 정리, R&R 기준… 하나하나는 다른 질문 같은데, 모아 놓고 보니 결국 같은 걸 묻고 있었습니다. 접수·판단·근거 세 가지와, 도구를 제일 나중에 골라야 하는 이유를 정리했습니다.
AI 시대, 현업의 기획과 요구사항정의서 그리고 개발의 기획은 어떻게 다른가
기획서는 현업만 쓰는 문서가 아닙니다. 현업의 기획은 마케팅·영업을 위한 것이고, 개발팀에는 구현을 위한 개발 기획이 따로 있습니다. AI 목업이 보편화되면서 생긴 '다 된 것 같다'는 체감 차이와, 세 문서를 가르는 R&R 다섯 단계를 정리했습니다.
회의 전 10분, 회의 후 10분 — AI로 준비하고 공유하는 회의록
회의록의 품질은 회의가 끝난 뒤가 아니라 시작하기 전에 갈립니다. 회의 전 10분에 AI에게 맥락을 먹이는 법, 회의 후 10분에 받는 사람별로 공유하는 법, 그리고 회의 중에 화가 났을 때 즉각 반응하지 않는 법까지 정리했습니다.
40줄을 다 읽어도 뭘 해달라는 건지 — 업무 이메일 에티켓, 보낼 때와 회신할 때
자료는 완벽한데 다 읽고 나면 '그래서 나한테 뭘'이 남는 메일이 있습니다. 요청은 목적부터 쓰고 배경은 뒤로, 회신이 늦어질 것 같으면 늦어진다는 말을 먼저 보내는 것 — 업무 이메일 에티켓을 보내는 쪽과 받는 쪽 양쪽에서 정리했습니다.