개발 배경: 어느 밤의 ‘아찔했던’ 순간
엔지니어로 일하다 보면 코드의 미세한 변경 사항이나 설정 파일의 차이를 확인하는 일은 숨 쉬듯 당연한 일과입니다.
어느 날 늦은 밤, 디버깅 작업에 몰두하던 저는 수만 줄에 달하는 두 개의 로그 파일을 비교하려 했습니다. 평소처럼 브라우저에서 ‘Diff 도구 온라인’을 검색했고, 가장 상단에 뜬 사이트를 열어 텍스트를 붙여넣으려던 바로 그 순간.
마우스를 움켜쥔 손이 멈췄고, 등줄기에 서늘한 식은땀이 흘렀습니다.
“잠깐, 지금 붙여넣으려는 이 로그에 고객의 이메일 주소나 인증 토큰이 포함되어 있지는 않나…?”
많은 온라인 도구들은 입력된 데이터를 일단 서버로 전송한 뒤, 그곳에서 차이 분석 알고리즘을 돌려 결과를 반환합니다. 악의가 없더라도 그 데이터가 서버 로그에 남거나 캐시될 가능성은 결코 제로가 아닙니다.
“편리하지만 무섭다.” 이 엔지니어 특유의 심리적 장벽을 기술의 힘으로 허물고 싶었습니다.
그것이 바로 **DevToolKits의 Diff 도구**를 개발하게 된 가장 큰 동기입니다.
기술적 도전: 브라우저에 ‘지능’을 채워 넣다
‘데이터를 단 한 걸음도 밖으로 내보내지 않는다’를 실현하려면, 통상 서버에서 수행하는 차이 계산의 모든 과정을 유저의 브라우저 안에서 완결시켜야 합니다.
1. 안정성과 ‘엔지니어의 눈’을 모두 잡기
차이 분석 알고리즘은 의외로 깊이가 있어서 직접 구현하면 예외 상황에서 버그가 발생하기 쉽습니다. 그래서 우리는 이미 검증된 jsdiff 라이브러리를 채택했습니다.
하지만 라이브러리를 그대로 가져다 쓰는 것만으로는 부족했습니다. 엔지니어가 보기에 ‘가독성 좋은’ Diff를 만들기 위해 줄바꿈 처리나 공백의 의미를 세밀하게 제어해야 했습니다.
import { diffLines } from 'diff';
// 줄바꿈을 단순한 문자가 아닌 행의 구분자로 확실하게 처리
// 직관적인 '행 기반' 비교를 구현하기 위한 설정
const changes = diffLines(oldText, newText, { newlineIsToken: false });이런 미세 조정을 반복한 끝에, 우리가 가장 신뢰하는 GitHub의 Pull Request와 같은 비교 경험을 브라우저상에서 재현해낼 수 있었습니다.
2. ‘덜어내는’ 디자인
개발 초기에는 화려한 기능을 많이 넣으려 했습니다. 하지만 결국 ‘입력하고, 바로 비교한다’라는 본질에 집중하기 위해 사고를 방해하지 않는 심플함으로 돌아왔습니다.
색상 선택 하나에도 공을 들였습니다. 장시간의 디버깅 작업으로 눈이 피로해지지 않도록 채도를 약간 낮춘 에메랄드(추가)와 로즈(삭제) 컬러를 사용했습니다. 화려함보다는 몇 시간을 계속 써도 부담 없는 ‘도구’로서의 질감을 소중히 여겼습니다.
‘서버 불신’에 대한 집념
이 도구를 개발하며 가장 고집했던 점은 **‘1바이트도 밖으로 새지 않게 하겠다’**는 것이었습니다.
네트워크를 거치지 않고 오직 메모리상에서만 완결되는 안심.
“데이터는 항상 내 손안에 있다.” 이 확신이 있기에 프로 개발자는 안심하고 업무에 집중할 수 있습니다. 그것이야말로 도구가 제공할 수 있는 최고의 사용자 경험(UX)이라고 믿습니다.
마치며
Diff 도구는 매우 심플해 보이지만, 그 이면에는 ‘엔지니어의 불안을 해소하고 싶다’는 저의 진심이 담겨 있습니다.
기밀성이 높은 파일의 비교나 운영 환경 배포 직전의 최종 체크.
여러분의 ‘안전한 도구함’ 중 하나로 이 도구가 쓰일 수 있다면 더할 나위 없이 기쁠 것 같습니다.