텍스트·개발 도구를 “장면”으로 묶기

JSON 포맷터나 Diff는 각각 유용하지만, 실무에서는 한 문제를 풀기 위해 두세 도구를 잇는 경우가 많습니다. 아래는 기획·개발·채용 서류에서 반복되는 장면을 기준으로, Toolturi 텍스트·개발자 도구를 어떤 순서로 쓰면 시행착오가 줄어드는지 정리했습니다.

1. API·설정 JSON이 한 줄로 왔을 때

응답을 복사해 JSON 포맷터로 펼치면 키 누락·배열 길이를 눈으로 잡기 쉽습니다. 문법만 통과하고 스키마가 의심되면, 이전 성공 응답과 텍스트 Diff로 줄 단위 차이를 보세요. 배포용으로 줄여야 할 때는 같은 도구에서 minify하고, 커밋 전에는 다시 pretty로 리뷰하는 습관이 설정 사고를 줄입니다. 토큰이 보이면 공용 PC에서는 탭을 닫아 잔상을 남기지 마세요.

2. 자소서·소개란 분량 맞추기

사이트마다 “공백 포함/제외”, “글자/바이트” 기준이 다릅니다. 글자수·byte 카운터로 초안을 맞춘 뒤, 실제 제출 폼에 한 번 붙여 넣어 숫자가 같은지 확인하세요. 대소문자·줄바꿈만 손볼 때는 텍스트 변환기로 공백을 정리한 다음 다시 세면, 보이지 않는 공백 때문에 한도를 넘는 실수를 줄일 수 있습니다.

3. 계약·공지 문구 수정본 비교

워드에서 복사한 두 버전을 Diff에 넣기 전에 줄바꿈(CRLF/LF)을 맞춰 두지 않으면 전체가 변경된 것처럼 보입니다. 변환기로 줄바꿈을 통일한 뒤 Diff하면 “진짜 바뀐 조항”만 남습니다. 마크다운 초안을 웹에 올릴 때는 Markdown→HTML로 미리보기하고, 제목 단계가 사이트 템플릿과 겹치지 않는지 확인하세요.

4. 링크·임베드가 깨질 때

쿼리에 한글·공백을 넣을 때 URL 인코더는 전체 URL이 아니라 필요한 쿼리 값·경로 구성요소만, 그리고 한 번만 인코딩하는 것이 원칙입니다. 이미 `%EC…` 형태인데 다시 인코딩하면 이중 인코딩으로 404가 납니다. 데이터 URI나 간단한 임베드는 Base64로 만들 수 있지만, 이는 암호화가 아니므로 누구나 복원할 수 있습니다. 비밀값을 숨기는 용도로 쓰지 마세요. 로그에서 주문번호만 뽑을 패턴은 정규식 테스터로 정상 값뿐 아니라 빈 값·공백·잘못된 형식도 함께 검증합니다.

5. 파일·문자열 무결성 확인

배포 후 “받은 내용이 같은지” 보려면 해시 생성기로 SHA-256을 비교하세요. 문자열은 인코딩·줄바꿈·공백만 달라도 해시가 달라집니다. 비밀번호 저장용으로는 이 화면의 일반 해시를 쓰지 말고, salt와 Argon2·scrypt·bcrypt 같은 서버 전용 방식을 따르세요.