처음 개발 공부를 할 때 저는 오류를 해결하면 그걸로 충분하다고 생각했습니다. 하지만 같은 오류를 다시 만났을 때 원인도, 해결 방법도 기억나지 않아 처음부터 다시 검색해야 했습니다. 그때 문제를 푸는 것과 과정을 기록하는 것은 완전히 다르다는 걸 느꼈습니다. 오류 메시지, 원인 분석, 시도한 방법, 최종 해결 방법을 짧게라도 남겨두면 다음 문제를 훨씬 빠르게 해결할 수 있습니다. 저는 문제 해결 과정 정리가 단순한 메모가 아니라 개발자의 사고방식과 성장 과정을 보여주는 중요한 기록이라고 생각합니다.
문제 해결 과정이 개발자의 사고방식을 증명합니다
처음 개발 공부를 시작했을 때, 저는 오류 메시지가 뜨면 무조건 복사해서 검색부터 했습니다. 운 좋게 해결되면 바로 다음 진도로 달려갔고, 왜 그 방법이 통했는지는 신경 쓰지 않았습니다. 그게 얼마나 잘못된 습관인지는 한참 뒤에야 알았습니다. 문제 해결 과정을 정리하면 자연스럽게 오류 메시지(error message)를 읽는 습관이 생깁니다. 여기서 오류 메시지란 실행 환경이 어떤 문제를 감지했는지 알려주는 시스템의 진단 결과입니다. 예를 들어 module not found는 필요한 패키지가 설치되지 않았거나 경로가 잘못됐다는 뜻이고, port already in use는 해당 포트를 다른 프로세스가 이미 점유하고 있다는 뜻입니다. 처음엔 영어로 가득 찬 그 메시지가 겁났는데, 정리하다 보니 단서를 먼저 찾는 눈이 생겼습니다.
제가 직접 써봤는데, 기록을 시작하고 나서 문제 접근 방식이 달라졌습니다. 전에는 코드 전체를 의심했다면, 이제는 오류 메시지 확인 → 최근 변경 사항 검토 → 실행 환경과 버전 확인 → 로그 분석 순으로 좁혀갑니다. 이 흐름이 쌓이면 개발자의 논리적 사고방식(logical thinking)이 됩니다. 쉽게 말해 문제를 무작위로 건드리는 게 아니라 원인을 체계적으로 좁혀가는 능력입니다. 면접에서도 이게 결정적인 차이를 만들었습니다. “오류 해결 경험을 말해보세요”라는 질문에 기록이 없으면 막막해집니다. 하지만 정리된 기록이 있으면 문제 상황, 원인 분석, 시도한 방법, 해결 결과를 자연스럽게 말할 수 있습니다. 솔직히 이건 예상 밖이었습니다. 기록 하나가 면접 답변의 질을 이렇게 바꿔놓을 줄은 몰랐습니다.
오류 기록이 반복 실수를 막아줍니다
개발 공부에서 가장 아까운 시간은 이미 해결한 문제를 다시 검색하는 시간입니다. 제가 정확히 그랬습니다. 패키지 설치 후 모듈을 찾지 못하는 오류, Git 충돌, 환경 변수 누락으로 인한 서버 실행 실패. 이 문제들을 몇 번씩 반복해서 만났고, 매번 처음처럼 헤맸습니다. 환경 변수(environment variable)란 운영체제나 실행 환경에 저장된 설정 값으로, 애플리케이션이 실행될 때 참조하는 외부 구성 정보입니다. 쉽게 말해. env 파일에 담긴 API 키나 데이터베이스 접속 정보 같은 것들입니다. 배포 환경에서 이 파일이 빠지면 서버가 아예 실행되지 않는데, 저는 이 원인을 로그(log)에서 찾지 않고 코드만 뒤졌다가 한 시간을 날렸습니다. 로그란 시스템이 실행되는 동안 남기는 동작 기록으로, 문제 원인을 추적하는 가장 빠른 단서입니다.
그 이후로 오류 기록을 다음 구조로 남기기 시작했습니다.
- 문제 상황: 어떤 환경에서 무슨 오류가 발생했는지
- 원인 분석: 처음 의심한 원인과 실제 원인의 차이
- 시도한 방법: 실패한 시도까지 포함해서 기록
- 해결 방법: 최종 명령어 또는 설정 변경 내용
- 배운 점: 다음에 예방할 방법
제가 직접 써봤는데, 실패한 시도까지 남기는 게 처음엔 귀찮았습니다. 그런데 나중에 비슷한 오류를 만났을 때 “이건 이미 안 되는 방법”이라는 걸 바로 확인할 수 있어서 시간이 훨씬 줄었습니다. 기록의 힘이 이런 데 있었습니다. 스택 오버플로우 개발자 설문에 따르면, 개발자의 절반 이상이 디버깅에 하루 업무 시간의 35% 이상을 쓴다고 답했습니다. 오류 기록 하나가 그 시간을 줄이는 현실적인 방법입니다.
포트폴리오의 신뢰도를 높입니다
신입 개발자 포트폴리오를 처음 만들 때, 저는 화면 캡처와 기능 목록을 나열하는 게 전부인 줄 알았습니다. 그런데 직접 피드백을 받아보니 면접관이 궁금해하는 건 “이 기능이 작동하는가”가 아니라 “이 사람이 막혔을 때 어떻게 풀어냈는가”였습니다. 리드미(README)란 프로젝트의 목적, 사용 방법, 주요 기술 스택을 정리한 문서로, GitHub에 올라가는 프로젝트의 첫인상입니다. 쉽게 말해 프로젝트 소개서입니다. 여기에 트러블슈팅(troubleshooting) 섹션을 추가하면 포트폴리오의 밀도가 달라집니다. 트러블슈팅이란 문제 발생 원인을 진단하고 해결하는 과정을 체계적으로 정리한 것을 말합니다. 솔직히 이건 예상 밖이었습니다. “게시판 프로젝트를 만들었습니다”라고 쓰는 것보다 “게시글 목록 조회 속도가 느려 페이지네이션을 적용했고, 쿼리 구조를 수정해 응답 시간을 단축했습니다”라고 적었을 때 면접 분위기가 달라졌습니다. 제가 직접 경험한 차이입니다.
한국산업인력공단 NCS 직업기초능력 연구에 따르면, IT 분야 직무에서 '문제 해결 능력'은 핵심 직업 기초능력 중 하나로 꼽힙니다. 결국 포트폴리오에서 문제 해결 기록은 이 능력을 가장 직접적으로 보여주는 증거입니다. 처음에는 짧게라도, 오늘 만난 오류 하나, 원인 하나만 남기는 것부터 시작하면 됩니다. 문제를 해결한 것은 과거의 일이지만, 그 과정을 기록하면 미래의 자신에게 도구가 됩니다. 저는 앞으로도 오류를 만날 때마다 짧게라도 남기는 습관을 계속 이어갈 생각입니다. 기록이 쌓일수록 스스로의 성장 방식이 눈에 보이기 시작하기 때문입니다.