같은 Dev 헬퍼를 다시 만들지 마세요: 대신 Browser Toolbelt를 구축하세요
Source: Dev.to
위에 제공된 텍스트를 번역하려면 실제 내용이 필요합니다. 번역을 원하는 전체 텍스트(마크다운 형식 포함)를 제공해 주시면, 요청하신 대로 한국어로 번역해 드리겠습니다.
상황
오랫동안 내 개발 생활은 다음과 같았습니다:
- 편집기를 연다.
- 문서를 연다.
- 그 주에 다섯 번째로 “online JSON formatter” 를 구글링한다.
- 어딘가에 있었던 작은 헬퍼 스크립트를 또 작성하지만, 찾지 못한다.
이 작업들은 모두 어려운 것이 아니었다:
- JSON을 포맷하거나 검증하기
- CSV ↔ JSON ↔ XML 변환
- 테스트 데이터 생성
- 시간대 변환
- 이상한 토큰이나 Base64 블롭 디코딩
하지만 그것들은 지속적이었다 – 천 개의 작은 헬퍼에 의한 죽음.
통찰
어느 순간 나는 내 문제는 실력이 아니라는 것을 깨달았다.
나는 모든 작은 작업을 일회성으로 취급했고, 반복 가능한 워크플로의 일부로 보지 않았다.
그래서 나는 영웅이 되려는 시도를 멈추고 브라우저 툴벨트를 만들었다.
“작업이 반복적이고, 기계적이며, 실수하기 쉬울 경우, 나는 새 스크립트로 해결하려 하지 않는다.”
지금 내가 따르는 규칙
도움이 필요할 때 나는 세 가지 질문을 한다:
- 이전에 해결한 적이 있나요?
- 이미 이를 수행하는 안정적인 도구가 있나요?
- 이것이 정말 저장소에 있어야 하나요?
답이 “아니오, 신뢰할 수 있는 도움이 필요하다”면, 나는 브라우저 툴벨트를 꺼낸다.
검색 기록에서 실제 벨트까지
이전
format json online
csv to json
utc to est converter
url decode online매 세션마다: 같은 검색, 약간씩 다른 사이트, 새로운 팝업과 레이아웃.
문제점
- 동작이 일관되지 않았다.
- 근육 기억을 만들 수 없었다.
이후
- 반복되는 작업당 하나의 도구를 선택한다.
- 그 도구를 “Dev Toolbelt” 폴더에 북마크한다.
- 매번 같은 도구를 사용한다.
폴더가 생기면 도구를 추가하고 정리하는 것이 자연스럽게 이루어진다.
핵심 카테고리 및 권장 도구
JSON (보통 마찰이 발생하는 부분)
- 포매터 / 검증기 – 페이로드를 실제로 읽을 수 있게.
- Diff 도구 – 두 JSON 블롭을 비교.
- 컨버터 – JSON ↔ CSV ↔ XML.
이를 다루는 방법
- IDE 포매터 (예: VS Code, IntelliJ)
jq같은 CLI 도구- 신뢰할 수 있는 온라인 포매터/컨버터 하나
핵심은 찾아다니는 것을 멈추고 매번 같은 몇 가지 도구만 사용하는 것입니다.
현실적인 테스트 데이터
나는 test@test.com와 John Doe 로 “테스트”하곤 했고, 실제 데이터가 모든 것을 깨뜨릴 때 놀라곤 했습니다.
이제 현실적인 테스트 데이터를 일급 도구로 다룹니다:
- 코드용 Faker 스타일 라이브러리
- CSV/JSON 목록용 간단한 생성기
- 재사용 가능한 공유 샘플 데이터셋
워크플로우: 생성 → 내보내기 → 가져오기 → 재사용.
테스트 데이터가 현실적일수록 이상한 프로덕션 버그가 적어집니다.
시간대 변환
시간대는 오후 전체를 잡아먹을 수 있습니다. 나는 다음을 혼합합니다:
- 언어 기능 및 라이브러리 (예:
moment,date-fns,pytz) - MDN 또는 공식 문서
- sanity check용 친절한 온라인 변환기 하나
이제는 머리로 시간대 계산을 시도하지 않습니다; 매번 같은 작은 도구 세트를 통해 처리합니다.
인코딩 / 해싱
하나의 장소에 다음을 보관합니다:
- Base64 인코드/디코드
- URL 인코드/디코드
- HTML 엔티티
- 빠른 해시 체크 (MD5, SHA‑1, SHA‑256)
표준 라이브러리나 openssl으로 대부분 수행할 수 있습니다.
특히 메인 머신을 떠나 있을 때 빠른 체크를 위해 익숙한 브라우저 도구를 갖는 것이 여전히 좋습니다.
브라우저 도구 사용 가이드라인
- 프로덕션 비밀 정보나 실시간 고객 데이터를 무작위 사이트에 절대 붙여넣지 마세요.
- 데이터를 브라우저 내에서 처리한다고 명시된 도구를 선호하세요 (서버 라운드‑트립 없음).
- 민감한 워크플로우의 경우 셀프‑호스팅 또는 사내 도구를 고려하세요.
사후 보고서에서 설명하기 곤란하다면, 공개 도구에 포함해서는 안 됩니다.
AI 도우미 – 보완, 대체가 아니라
좋은 점
- 일회성 스크립트 스케치
- 익숙하지 않은 API 탐색
- 혼란스러운 스택 트레이스 설명
완전한 대체가 아닌 이유
- AI는 자신감 있게 틀릴 수 있다.
- 구식이거나 보안에 취약한 패턴을 사용할 수 있다.
- 결과가 실행마다 달라질 수 있다.
작고 결정적인 툴벨트가 여전히 유리한 경우:
- 빠른 포맷 / 변환 / 검증 작업
- 팀과 공유할 수 있는 재현 가능한 워크플로우
- 데이터를 AI 시스템에 붙여넣을 수 없는 상황
내 접근법: 툴벨트 주변에 AI를 사용하고, 툴벨트를 대신 사용하지 않는다.
브라우저 툴벨트만으로는 부족할 때
- 작업은 CI 또는 매 deploy마다 실행되어야 합니다.
- 로직은 비즈니스 규칙에 특화되어 있습니다.
- 상태, 히스토리, 혹은 고성능 작업이 필요합니다.
그러한 문제들은 적절한 코드, 테스트, 그리고 리뷰가 필요합니다.
저에게 툴벨트는 무상태, 반복적, 기계적인 작업을 위한 것입니다.
시작하기 – 간단한 계획
- 가장 자주 겪는 불편한 점 다섯 가지를 적어보세요.
- 각 항목마다, 당신이 좋아하는 단일 도우미(온라인 또는 CLI)를 선택하세요.
- 브라우저에 “Dev Toolbelt” 북마크 폴더를 만드세요.
- 그 링크들을 추가하고 폴더를 고정해 쉽게 접근할 수 있게 하세요.
- 일주일 동안 새로운 도우미를 만들기 전에 툴벨트를 먼저 사용해 보세요.
선택적 추가 사항
- 브라우저에 맞춤 검색 키워드를 추가하세요.
- 항상 열어두는 “toolbelt” 탭을 고정하세요.
- 목록을 팀과 공유하고 제안을 받아보세요.
한 번에 삼십 개가 아니라 세 개의 확실한 도구부터 시작하세요. 같은 불편을 몇 번 겪어 본 뒤에만 도구를 추가하세요.
내가 겪은 흔한 실수
- 한 번에 “완벽한” 툴벨트를 만들려고 시도하기.
- 이미 존재하고 잘 작동하는 툴을 다시 구현하기.
- 모든 것을 다른 사람이 이해하지 못하는 개인적인 버그에 의존하게 만들기.
- 폴더에서 오래되었거나 고장 난 툴을 절대 정리하지 않기.
간단하게 유지하라: 이 툴이 실제 작업에서 신뢰성 있게 시간을 절약해 주는가? 그렇지 않다면, 버려라.
유지보수 – 분기별 정리
분기마다 나는 북마크 폴더에서 10분을 보냅니다:
- 더 이상 사용하지 않는 도구 제거 (또는 신뢰성이 떨어진 경우).
- 링크 업데이트 – 서비스가 URL이나 UI를 변경하면.
- 새로운 도우미 추가 – 새롭게 반복되는 문제점에 대비해서.
(원본 메모가 잘렸습니다: “Remove tools I no lo…”. 의도는 더 이상 필요하지 않은 도구를 제거하는 것이었습니다.)
추가 읽기
내 브라우저 툴벨트의 구체적이고 링크가 많은 버전에 궁금하시다면, 정식 포스트를 확인해 보세요:
Computer Programming Made Easier – CodersTool Blog
툴링을 즐기세요!
브라우저 툴벨트 간소화
느리거나 불안정하게 느껴지는 모든 것을 교체합니다.
지난 몇 달 동안 유용함이 입증된 도구를 한두 개 추가합니다.
그 작은 정리 작업이 툴벨트를 부풀어 오르지 않고 가볍게 유지합니다.
이렇게 해서 저는 무작위 탭과 일회성 도구에서 매달 몇 시간을 조용히 절약해 주는 작은 브라우저 툴벨트로 전환했습니다.
Your Turn
당신이 일상적인 개발 작업에서 없어서는 안 될 도구는 무엇인가요?
이와 같은 툴벨트를 가지고 계신가요, 아니면 모든 것이 검색 기록이나 오래된 레포에 숨겨져 있나요?
댓글에 필수 아이템을 공유해주세요—제 설정에 활용할 좋은 아이디어를 몇 개 훔쳐가고 싶어요.