자동화 스크립트를 하나 만들 때마다 작업 스케줄러 창을 열고, “작업 만들기”를 누르고, 이름 적고, 트리거 탭으로 가서 시각을 정하고, 동작 탭에서 실행 파일과 인수와 시작 위치를 채우고, 조건 탭에서 전원 옵션을 끄고… 이 과정이 마우스 클릭 스무 번쯤 됩니다. 한 번이면 참을 만한데, PC를 새로 세팅하거나 스크립트 경로가 바뀌면 처음부터 다시입니다. 무엇보다 어떻게 등록했는지가 아무 … 더 읽기
기능 개발을 한창 하고 있는데 “결제 페이지에서 500 떨어진다”는 연락이 옵니다. 지금 작업 트리에는 반쯤 고친 파일이 여덟 개쯤 열려 있습니다. 커밋하기엔 아직 동작하지 않고, 버리기엔 아깝습니다. 그래서 git stash로 밀어 넣고, 브랜치를 옮기고, 의존성을 다시 깔고, 고치고, 돌아와서 stash pop을 하고, 충돌을 풉니다. 이 왕복 한 번에 보통 10~15분이 날아갑니다. 하루에 두 번만 끼어들어도 … 더 읽기
하루에 git status를 몇 번이나 칠까요. 세어 보면 30~50번은 됩니다. 한 번에 2초씩 잡아도 하루 100초, 한 달이면 40분이 넘습니다. 여기에 cd ~/projects/회사서비스/backend 같은 긴 경로 이동, docker compose -f docker-compose.dev.yml up -d처럼 옵션이 줄줄이 붙는 명령까지 더하면 더 커집니다. 오타로 다시 치는 시간은 뺀 계산입니다. 셸 alias 설정은 이 반복을 두세 글자로 줄이는 가장 … 더 읽기
엑셀에서 열 이름 40개를 복사해 왔는데, 각 줄을 따옴표로 감싸고 뒤에 쉼표를 붙여야 하는 상황을 떠올려 보세요. 한 줄에 5초씩만 걸려도 200초, 게다가 중간에 한 줄을 빼먹으면 문법 오류를 찾느라 더 걸립니다. 같은 작업을 VS Code 멀티커서로 하면 단축키 세 번에 15초면 끝납니다. 이번 글에서는 커서를 여러 개 만드는 방법부터, 줄 끝에 한 번에 커서를 … 더 읽기
자동화 스크립트를 하나둘 만들다 보면 어느 순간 코드 여기저기에 API 키가 흩어집니다. 노션 토큰, 구글 서비스 계정 키, 텔레그램 봇 토큰, 데이터베이스 비밀번호까지요. 처음에는 “나 혼자 쓰는 스크립트니까 괜찮겠지” 싶지만, 깃허브에 백업하려는 순간 문제가 됩니다. 실제로 공개 저장소에 올라간 키는 자동 스캐너에 몇 분 안에 발견됩니다. 유료 API 키라면 요금이 청구되고, 클라우드 키라면 계정 자체가 … 더 읽기
이슈함을 열었더니 제목은 “안 돼요”, 본문은 “로그인이 안 됩니다” 한 줄. 어떤 브라우저인지, 어떤 계정인지, 언제부터인지 되묻고 답을 기다리는 데만 하루가 갑니다. 재현 정보를 받아내는 왕복 두 번이면 실제 수정에 30분이면 될 버그가 이틀짜리 티켓이 됩니다. 깃허브 템플릿 활용법은 이 왕복을 없애는 가장 값싼 방법입니다. 파일 몇 개를 저장소에 커밋해 두면, 이슈를 여는 사람이 필요한 … 더 읽기
터미널을 하루에 몇 번 여는지 세어보면 대개 수십 번입니다. 그런데 기본 상태의 Windows Terminal은 프롬프트에 전체 경로만 길게 찍혀 있고, 지금 어느 git 브랜치에 있는지는 알려주지 않습니다. 그래서 브랜치를 확인하려고 git status를 한 번 더 치고, 어제 쓴 긴 명령이 기억나지 않아 히스토리를 위로 스무 번 넘깁니다. 한 번에 5초씩만 잡아도 하루 서른 번이면 2분 … 더 읽기
프로젝트 폴더에서 특정 문자열이 어디에 쓰였는지 찾느라 탐색기 검색창을 열고 몇 분씩 기다려 본 적이 있을 겁니다. 로그 파일을 메모장으로 열었다가 멈춰버린 적도요. 이런 작은 대기 시간은 하루에 열 번만 반복돼도 20~30분이 됩니다. 한 달이면 열 시간이 넘습니다. 터미널 생산성 도구는 이 대기 시간을 거의 0에 가깝게 줄여주는 명령줄 프로그램들입니다. 이 글에서는 설치 한 줄로 … 더 읽기
풀 리퀘스트를 열 때마다 똑같은 지적이 달립니다. 들여쓰기가 안 맞는다, print가 남아 있다, 함수 이름이 규칙과 다르다. 리뷰어는 매번 같은 말을 적고, 작성자는 매번 같은 수정을 합니다. PR 하나에 이런 왕복이 두 번씩만 생겨도 20~30분이 사라지고, 일주일에 다섯 건이면 두 시간이 넘습니다. 코드리뷰 체크리스트는 이 반복을 줄이는 가장 값싼 도구입니다. 이 글에서는 바로 복사해 쓸 … 더 읽기
버그가 하나 터져서 git blame으로 범인을 찾았습니다. 해당 줄을 마지막으로 건드린 커밋이 나왔는데, 메시지가 “수정”입니다. 그 앞 커밋은 “ㅇㅇ”, 그 앞은 “asdf”. 결국 diff를 한 줄씩 읽어가며 6개월 전의 내가 무슨 생각이었는지 추측하게 됩니다. git 커밋 컨벤션은 이 추측 시간을 없애기 위한 약속입니다. 이 글에서는 좋은 커밋 메시지의 기준, 실무에서 가장 많이 쓰는 Conventional Commits … 더 읽기