라이브러리를 갖다 쓰기만 하는 것 같아 불안한 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-10-22

"내가 짠 코드는 남이 만든 라이브러리를 이어 붙인 것에 불과하지 않을까."

2년 차 백엔드 개발자 한 분이 멘토링 첫 주차에 털어놓은 고백입니다. 스프링 부트로 의존성을 추가하고 어노테이션 몇 개를 달면 주문 API가 돌아갑니다. 코드는 정상 작동하지만, 정작 본인이 무엇을 만들었는지는 알지 못해 마음이 무겁다고 했습니다.

왜 이런 불안이 생길까요? 라이브러리를 가져다 쓰는 행위 자체는 결코 잘못이 아닙니다. 현업에서 모든 것을 바닥부터 직접 만드는 개발자는 없습니다. 진짜 문제는 라이브러리를 조립했다는 사실이 아니라, 내부 흐름을 블랙박스로 남겨둔 채 넘어가기 때문입니다.

어노테이션 뒤에 숨은 비용을 계산하지 못합니다

멘토링을 진행하면서 이력서에 JPA나 Redis를 화려하게 적어낸 분들을 200명 넘게 만났습니다. 어노테이션 한 줄로 트랜잭션을 걸고 분산 락을 적용했다고 적혀 있습니다.

하지만 "동일한 트랜잭션 안에서 외부 결제 API 호출이 지연되거나 실패하면 DB 커넥션 풀은 어떻게 되는가"라고 물으면 열 명 중 아홉 명은 답을 잇지 못합니다. 라이브러리가 문제를 대신 해결해주는 동안, 그 기술이 내부에서 치르고 있는 자원 비용을 들여다보지 않은 결과입니다. 편리함의 대가를 모르면 장애가 났을 때 한 줄의 에러 로그 앞에서도 얼어붙게 됩니다.

문제가 생겼을 때 내부 코드를 열어보지 않습니다

3년 차 멘티 한 분은 오픈소스 배치 라이브러리를 쓰다가 대용량 처리 환경에서 메모리 누수를 겪었습니다. 그 개발자가 가장 먼저 한 행동은 커뮤니티 검색과 블로그를 뒤지며 누군가 올려둔 패치 코드를 찾아 헤매는 일이었습니다.

라이브러리는 건드릴 수 없는 성역이 아닙니다. 인텔리제이에서 클릭 한 번이면 라이브러리 내부 클래스와 메서드가 그대로 열립니다. 결국 그 멘티와 저희가 함께 라이브러리 내부 코드를 디버거로 추적해 버퍼 해제 누락 지점을 찾아냈고, 이슈는 반나절 만에 해결되었습니다. 라이브러리를 단순 소비자로만 대하는 사람과 내부 구현을 읽는 도구로 대하는 사람의 격차는 여기서 벌어집니다.

기준 없는 채택은 부채를 만듭니다

"남들이 다 쓰니까", "깃허브 별점이 가장 높아서" 라이브러리를 고르는 습관도 불안의 뿌리입니다. 명확한 도입 기준이 없으니 기술을 왜 써야 하는지 기술면접관 앞에서도 설득하지 못합니다.

기술의 장점만 보고 단점과 제약 사항을 저울질하지 않는 선택은 반드시 기술 부채로 돌아옵니다. 라이브러리를 쓴다는 것은 그 라이브러리가 내린 아키텍처 철학을 내 프로젝트 안으로 끌어안는 일입니다. 그 철학을 이해하지 못하면 시스템은 점점 개발자의 통제를 벗어납니다.

라이브러리를 많이 안다고 좋은 개발자가 되는 것은 아닙니다. 바닥부터 모든 걸 혼자 짜야 실력자인 것도 아닙니다. 라이브러리가 덮어준 추상화의 껍질을 벗겨내고, 그 안에서 벌어지는 데이터 흐름을 끝까지 장악할 때 비로소 내 코드가 됩니다. 도구를 빌려 쓰되, 도구의 주인이 되십시오.