본문 바로가기

IT & 비즈니스20

버그 리포트를 재현 가능하게 쓰는 법: 개발자가 다시 확인할 수 있는 기록 만들기 저는 처음 버그 리포트를 작성할 때 문제가 발생했다는 사실만 전달하면 충분하다고 생각했습니다. 그래서 제목에는 화면 이름과 오류 내용을 짧게 적고, 본문에는 재현이 잘 되지 않는다는 문장만 남기곤 했습니다. 하지만 개발자가 같은 현상을 확인하지 못하면 수정 작업은 멈추고, 결국 저에게 추가 질문이 돌아왔습니다. 그때부터 버그 리포트는 불편함을 알리는 메모가 아니라, 다른 사람이 같은 상황에 들어갈 수 있도록 길을 안내하는 기록이라는 생각으로 작성하기 시작했습니다.재현 가능성이 리포트의 품질을 좌우한다제가 생각하는 재현 가능한 리포트의 핵심은 읽는 사람이 작성자의 기억이나 추측에 의존하지 않아도 되는 상태입니다. 어떤 메뉴를 열었는지, 어떤 값을 입력했는지, 버튼을 몇 번 눌렀는지, 그 직후 무엇이 보였는.. 2026. 10. 2.
깃 되돌리기 마스터: 실수에서 안전하게 복구하기 되돌리기 전에 먼저 현재 상태를 기록하기저는 깃을 처음 사용할 때 실수를 고치는 일보다 실수를 숨기려는 마음이 더 위험하다는 사실을 늦게 배웠습니다. 파일을 잘못 수정한 뒤 곧바로 여러 명령어를 연달아 입력하면 무엇이 사라졌는지 확인하기가 어려워집니다. 그래서 지금은 문제가 생기면 먼저 git status와 git log --oneline --decorate -5를 실행합니다. 현재 브랜치, 커밋 위치, 아직 커밋하지 않은 파일을 눈으로 확인한 뒤에야 다음 명령을 선택합니다. 화면에 나온 내용을 복사해 별도 메모장에 남기는 습관도 생겼습니다.작업 중인 파일이 많을 때는 되돌리기 전에 임시 커밋을 남기거나 패치 파일을 만들어 둡니다. 예를 들어 수정 내용을 잠시 보관해야 한다면 git diff > befo.. 2026. 9. 29.
구글 클라우드 콘솔에서 내가 처음 헤맨 권한 설정 제가 GCP를 처음 만진 때는 2024년 3월, 해외 고객용 예약 서비스의 로그가 하루 2억 건을 넘기면서부터였다. 당시에는 사내 PostgreSQL 서버 한 대와 주기적으로 실행하는 배치 작업으로 버텼는데, 오전 9시마다 리포트가 늦어지고 운영팀의 조회가 서비스 화면까지 느리게 만들었다. 저는 클라우드로 옮기면 문제가 곧바로 사라질 거라 생각했지만, 첫 이전 작업부터 틀렸다. 운영 데이터베이스를 통째로 BigQuery에 복사하고 모든 쿼리를 그대로 옮겼더니 비용은 늘고 화면 응답은 오히려 불안정해졌다. 그 경험 이후 저는 GCP를 ‘서버를 빌리는 장소’가 아니라, 업무 흐름을 다시 설계하는 도구로 보기 시작했다.1. BigQuery를 붙이면 조회가 빨라질 줄 알았던 착각처음에는 1.8TB짜리 주문 테이.. 2026. 9. 8.
온디바이스 모델을 노트북에서 켜 보다 메모리에서 멈춘 실험 저는 2025년 3월부터 작은 온라인 쇼핑몰의 상품 등록과 고객 문의를 AI로 줄여 보려 했다. 처음에는 텍스트 상품 설명만 넣으면 상세 페이지가 알아서 완성될 거라 기대했지만, 결과는 어색한 문장과 틀린 규격 정보의 연속이었다. 특히 500g 제품을 5kg으로 바꿔 쓰는 오류가 세 번이나 발생해 고객에게 수정 안내를 보냈다. 그때 저는 AI의 성능보다 제가 어떤 자료를 넣고, 어디까지 확인할지 정하는 과정이 더 큰 차이를 만든다는 사실을 배웠다.제가 멀티모달 AI를 제대로 써 본 계기는 2025년 6월 거래처에서 받은 PDF 카탈로그였다. 기존에는 표를 직접 복사해 엑셀에 옮겼고, 42쪽 자료를 처리하는 데 반나절이 걸렸다. 이미지와 표를 함께 읽는 도구에 카탈로그를 넣은 뒤에는 20분 만에 초안이 나.. 2026. 9. 8.
브라우저에 계산을 옮기다가 빌드 도구에서 멈춘 시도 1. 브라우저에서 처음 만난 Wasm의 현실저는 2024년 3월, 브라우저에서 이미지 배경 제거 기능을 빠르게 만들고 싶어 WebAssembly를 처음 붙였다. 당시에는 C++로 작성된 기존 이미지 처리 코드를 그대로 웹에 옮기면 자바스크립트보다 훨씬 빨라질 거라 기대했다. 하지만 첫 결과는 기대와 달랐다. 4MB짜리 Wasm 파일을 내려받고 초기화하는 데 제 노트북 크롬에서 약 1.8초가 걸렸고, 작은 이미지 한 장만 처리할 때는 오히려 순수 자바스크립트 코드가 더 빨랐다. 연산 시간만 보고 기술을 선택하면 안 된다는 사실을 그때 체감했다.제가 처음 놓친 부분은 자바스크립트와 Wasm 사이의 데이터 복사였다. 이미지 픽셀 배열을 자바스크립트에서 Wasm 선형 메모리로 옮기고, 처리가 끝난 뒤 다시 꺼내.. 2026. 9. 8.
AI 초안을 고치느라 처음부터 쓰는 것보다 늦어진 날 ㄴ1. AI를 쓰면 시간이 줄어들 거라는 착각저는 2025년 3월부터 생성형 AI를 업무에 본격적으로 넣기 시작했다. 처음에는 주간 업무 보고서를 통째로 맡기면 3시간 걸리던 작업이 10분 안에 끝날 거라고 생각했다. 실제로는 첫 주에 작성한 결과물을 거의 전부 다시 고쳤다. AI가 만든 문장은 그럴듯했지만 제가 진행하지 않은 회의 내용이 섞였고, 지난주 수치를 이번 주 수치처럼 표현한 부분도 발견됐다. 당시 저는 AI의 문제라고만 생각했지만, 나중에 보니 자료를 제대로 주지 않은 제 지시가 더 큰 원인이었다. 그 뒤로는 AI를 ‘대신 작성하는 직원’이 아니라 ‘초안을 빠르게 만드는 보조자’로 바라보기 시작했다.2. 제가 실패하면서 바꾼 프롬프트 작성법처음 사용한 요청문은 “이번 주 업무를 보고서로 작성.. 2026. 9. 7.