개발 일지

6년차 개발자가 매번 검색하는 코드와 절대 안 까먹는 것들

stackD 2026. 7. 12. 18:00
반응형

 

외울수록 일을 못하는 영역이 있고, 외우지 않으면 시니어가 못 되는 영역이 따로 있습니다. 6년을 굴러보니 그 경계선이 보이기 시작했어요.

 

git reset 옵션은 6년차도 매일 검색합니다

솔직히 고백하자면 어제도 git reset --soft--mixed 차이를 검색했어요. tar -xvzf의 옵션 순서도 매번 헷갈리고, HTTP 409랑 422를 언제 써야 하는지도 잠깐 멈춥니다.

 

근데 이게 부끄러운 일은 아니에요. 스택 오버플로우(Stack Overflow)가 발표한 2024년 개발자 설문에서 응답자의 93%가 한 달에 여러 번 사이트를 방문한다고 합니다. 같은 설문에서 AI 도구를 쓰는 이유로 '생산성 향상'과 '학습 속도'가 70% 안팎으로 상위에 잡혔다는 결과도 있고요.

 

인지 부하 이론에서 자주 인용되는 작업기억 연구(Cowan, 2001)에 따르면 인간의 작업 기억은 평균 4 청크 정도만 효율적으로 처리한다고 합니다. 4 청크가 어느 정도냐면, 전화번호 뒷자리 4개를 동시에 머릿속에 굴리는 분량 정도예요. 그 이상은 외부 도구로 빼는 게 합리적인 선택이지요.

 

 

안 외워도 되는 휘발성 문법과 옵션 6가지

제가 6년 동안 외우기를 포기한 항목들입니다.

 

  1. git 옵션 (reset / revert / rebase -i 플래그)
  2. 정규표현식과 cron 표현식
  3. CSS flex, grid 세부 속성
  4. SQL JOIN 종류와 윈도우 함수 문법
  5. 셸 리다이렉션 2>&1 같은 디테일
  6. Date 포맷 문자열 (yyyy-MM-dd인지 YYYY-mm-DD인지)

 

이런 건 30초 검색으로 복구되는 정보예요. 머리에 넣어둬도 한 달만 안 쓰면 휘발됩니다. 깃허브 코파일럿(GitHub Copilot)이나 클로드(Claude) 같은 도구가 보일러플레이트를 대신 써주는 시대에는 암기 가치가 더 떨어졌다고 봅니다.

 

다만 한 가지 함정이 있어요. AI가 뽑아준 코드가 "거의 맞는" 상태로 나오는 경우가 많은데요, 그걸 검증할 개념이 없으면 그대로 프로덕션에 박혀버리거든요. 안 외워도 되는 건 문법이지, 개념이 아니라는 얘기입니다.

 

시니어 개발자가 꼭 외우는 개념 모델과 판단 기준

반대로 검색으로 절대 채워지지 않는 영역이 있습니다.

 

1. 개념 모델 (Why)

 

트랜잭션 격리 수준, CAP 이론, 이벤트 루프, 가비지 컬렉터 동작 방식 같은 것들이에요. 이건 문법이 아니라 "왜 이렇게 동작하는가"의 골격입니다. 검색으로 한 번 읽고 끝나는 게 아니라, 본인 머릿속에서 모델로 굴러가야 장애 상황에서 가설을 세울 수 있어요. 새벽 3시에 알람이 울려서 콘솔을 여는 순간, 검색창에서 격리 수준을 다시 읽고 있을 시간은 없거든요.

 

2. 판단 기준 (When/How)

 

인덱스를 언제 걸지, 캐시 전략으로 read-through 와 write-behind 중 무엇을 택할지, 어떤 작업을 비동기로 뺄지. 이런 결정은 검색해도 정답이 안 나옵니다. 본인 서비스의 트래픽 패턴과 데이터 특성을 머리로 굴려야 답이 나오는 영역이에요.

 

3. 시스템 직관과 도메인 지식

 

장애가 터졌을 때 어느 로그부터 볼지, 병목이 어디 있을 가능성이 높은지에 대한 감각이에요. 그리고 본인이 다루는 서비스의 비즈니스 로직과 레거시 코드의 위험 지점은 검색 결과에 절대 안 나옵니다.

 

특히 운영 장애 대응 절차와 보안 키 처리 방식은 검색에 의지하지 마시고 손으로 먼저 정리해두시는 게 좋아요. 새벽 3시에 슬랙 알람 울리는 순간 검색창부터 띄우는 본인 모습은 정말 보기 싫더라고요.

 

 

주니어 개발자 공부 우선순위와 검색 루틴 3가지

연차별로 외워야 할 영역이 바뀝니다. 주니어는 문법, 3년차는 프레임워크 패턴, 6년차는 시스템 설계와 도메인이지요. 이 순서가 뒤집히면 윗 단계가 모래성처럼 무너지는 경우가 많습니다.

 

검색 루틴에서 제가 굴리고 있는 세 가지를 적어둘게요.

 

  1. 공식 문서를 먼저 열기. 블로그 글은 버전 차이로 틀리는 경우가 많습니다.
  2. 같은 키워드를 두 번 이상 검색했다면 노션(Notion) 개념 노트에 옮기기.
  3. AI가 뽑아준 코드는 반드시 한 줄씩 읽고 의심하기. 이 단계가 빠지면 검증 능력이 안 자라요.

 

개인적으로는 노션에 "다시 검색하지 않기"라는 데이터베이스를 따로 두고 있어요. 같은 정규식을 세 번째 검색하는 순간이 보이면 거기 박아두고, 다음에는 노션 안에서만 검색합니다. 외부 검색 횟수가 한 달 단위로 줄어드는 게 눈에 보였어요.

 

 

주니어 시절 저에게 해주고 싶은 말

저는 2년차 때 정말 조급했어요. 시니어가 칠판에 슥슥 그리는 시퀀스 다이어그램을 보면서 "저 사람은 저걸 다 외우고 있구나"라고 착각했습니다. 한참 뒤에 같은 분 옆자리에 앉아 일하다가 알게 됐는데, 그 분도 flex-basis 기본값은 매번 검색하더라고요.

 

그 순간이 묘하게 위안이 됐어요. 차이는 외우는 양이 아니라 무엇을 외우고 무엇을 검색할지 가르는 기준에 있었다는 걸 그날 깨달았습니다. 휘발성 문법은 검색에 맡기고, 개념 모델은 노트로 굴리고, 도메인은 코드 리뷰로 몸에 새기는 그 분배가 시니어를 만들었던 거예요.

 

그 분 책상 위에 늘 펼쳐져 있던 데이터베이스 시스템 책 모서리가 까맣게 닳아있던 게 지금도 기억에 남습니다. 시니어가 외우고 있던 건 git 옵션이 아니라 그 책의 두께 같은 것이었어요.

 

반응형
LIST