직장인으로 사회에 첫 발을 내딛고 9개월. 그간 적다면 적고 많다면 많은 일들이 있었다. 첫 3개월은 적응하기 바빠서, 그 다음 3개월은 나름 일이 좀 익숙해졌다고 회사 생활에서 오는 스트레스로 인한 무기력감에 젖어서, 그리고 지금까지의 또 3개월은 뭔가 달라져야한다는 걸 알면서도 익숙함을 벗어나야한다는 공포에 어영부영 보내버렸다.

아침 운동도 시작했고, 야근도 줄었으니 "달라질 나"의 첫 걸음으로 회사든, 스터디든 실패한 경험담을 남겨보고 싶어졌다. 사실은 이직하려고 생각하니 실패 극복담(트러블 슈팅)이 필요할 것 같은데(?) 생각 나는 게 없어 시작하는 것도 있다🙄 전형적인 P인간인 내가 주기적으로 글을 쓰기는 어렵겠지만 실패담이라면 생길 때마다 쓰면 되니 부담스럽지도 않고! 게다가 트위터에서 당근마켓 기획자 분이 블로그에 실패담을 사내에서 공유했던 경험을 쓰신 걸 봤는데, 용기내어 실패담을 공유했을 때 긍정적인 경험으로 뒤집어 받아들일 수 있었다는 내용이 인상적이었다. 마침 글을 쓰는 오늘 회사에서 사고를 쳤기 때문에ㅎㅎㅎㅎ 오답노트 성격으로 글을 쓰며 같은 실수를 반복하지 않기 위해 장기 기억으로 남겨본다.

오늘의 실패

▸에러가 자바스크립트 코드에서만 발생할 거라 예단함.

실패 원인

사실 나는 개발에 자신이 없다. 당연하다. "회사 생활한 시간 = 내가 개발한 시간"이니까. 퍼블리싱 과정으로 국비학원에서 시작해서 본격적으로 개발을 해야겠다고 결정한 지 2개월만에 취업했다. 토이 프로젝트는 사실상 퍼블리싱 정도만 한 셈이다. 회사에서도 주업무가 퍼블리싱이기에 날 뽑았고, 프론트 개발자로 발전할 기회를 준다는 이해관계가 맞아서 나도 입사했다. 그런데 회사에 다니며 개발자 가 되는 건 그닥 쉽지 않았다. 아무리 그래도 그 정도 기초도 없냐는 식으로 생각하는 기색이 역력한 팀장, 퍼블리싱은 잘하지만 그래도 넌 개발자는 아니라고 무의식 중에 생각하는 팀원들, 아무리 스터디를 해도 주어지지 않는 프론트 개발 업무 등이 겹쳐 너무 쉽게 취업했다는 생각마저 들었다. 그래서 자바스크립트 공부도 더 열심히 하고 나도 할 수 있다고 어필하다보니 에러가 발생하면 당연히 자바스크립트 코드 문제일 거라고 생각했다.

그래서 프론트 개발하는 것 본인이 도와줄테니까 해보겠느냐고 선뜻 손을 내밀어줬던 팀원 덕에 처음으로 프론트 개발에 참여했던 페이지 중 검색 부분에서 에러가 났다고 했을 때, 심장도 철렁했지만 여러 생각이 들었다. 그 전에도 유독 내 IDE에서 팀원이 작업한 페이지의 자바스크립트 함수가 날아간 적이 이미 몇 번 있었기에 더더욱 아찔했다. 도대체 어디가 잘못된 건지 머리를 굴렸다. 아무리 생각해도 자바스크립트 코드 외에는 에러날 부분이 없었다.

'자바스크립트 코드는 건드린 게 없는데? 내 로컬 환경에서는 또 되네? 크롬 시크릿 창으로 여니까 또 안되잖아? 쿠키나 캐시가 브라우저에 남았나보다. 그렇다고 DB 문제도 아닌 것 같고, 도대체 뭐가 문제야?????'

문제점 확인

정말 물음표 백만 개를 띄우고 자바스크립트 부분을 열심히 이전 버전과 DIFF했다. 이번에 신규 기능을 만들며 새 버전을 Dev 버전과 Live 버전으로 배포했기에 더욱 아찔했다. 다행히 라이브 환경이라고 해도 제품 출시를 위해 내부에서 쓰는 베타테스트 버전에 가까운 데다가 내부 사정으로 테스트도 중지한 상태라 큰 사고는 아니었지만... 또 일어나지 않으리라는 보장이 없기에 에러가 났을 법한 부분을 정말 열심히 뒤졌다. 근데도 못 찾았다. 한참을 씨름하고 있는데 에러를 공유했던 팀원이 와서 말했다.

"아무래도 HTML form 태그랑 button 태그 type 문제인 것 같아."

말을 듣고 나니 생각났다. 급하게 제품 첫번째 버전을 준비하다보니 부트스트랩 컴포넌트들로 떡칠된 HTML 구조를 웹 표준을 준수하도록 수정해야겠단 생각에 검색 영역의 부모 태그를 form 태그로, 버튼 태그 타입을 submit 으로 바꾸고 뿌듯해하던 나 자신이 말이다. 머리를 한 대 맞은 것처럼 종소리가 띵- 골을 울렸다. 그랬다, 나는 "프론트 개발자가 HTML을 경시하면 안돼!"하면서도 나조차도 단편적으로만 이해하고 있었던 거다. 입술은 미처 그 부분은 확인하지 못해 미안하다, 그걸 찾은 당신 정말 대단하다 하면서도 머릿속으로는 아차 싶었다. 자만했구나.

해결

결국 그 부분은 에러를 찾았던 팀원이 마침 그 페이지에서 다른 부분을 개발하던 중이라 고쳐서 다시 배포하기로 했다. 웹 표준에 맞게 form 태그나 버튼 타입을 수정하고 싶으면 관련 함수도 수정해서 차후에 테스트해보기로 하고 일단락을 지었지만 당연히 찜찜했다. 바로 에러와 관련된 부분을 검색했다.

아무래도 저렇게 수정하기 전에도 검색을 해봤던 게 틀림없었다. TCP School 예제를 보고 이렇게 하면 되겠다고 생각했을 것이다(아마도). 분명 form 태그 내부에 있는 내용을 submit 버튼을 통해 서버로 전송하고 페이지가 reload되는 걸 알았음에도 당장 내 브랜치 내용이 반영되어 배포될 일이 없으니 서버로 전송하는 부분에 대한 처리는 나중에 해야겠다고 안이하게 넘겼다. 그러고는 새 기능 개발할 때는 이 부분은 또 까맣게 잊은 거다. 이런 생각으로 사고친 게 짧은 시간 내에 벌써 두번째다😣 저번에도 이런 일 다시 만들지 말아야지, 해놓고 오답노트 안 쓰니 그대로 잊어버렸다. 안 잊을 거라 오만했던 나를 믿은 내 불찰이지, 에휴.

이번에는 오답노트로 확실하게 자기반성을 했으니 어떻게 하면 이런 실수를 줄일 수 있을지 고민할 차례다. 우선, 기능별 이슈로 브랜치 관리를 하는 방법이 있다. 이슈 생성하고 코드 리뷰 진행하고 원격 저장소 브랜치가 너무 늘어나 팀장이 따로 언급하기 전에는 그냥 레이아웃 관련된 이슈는 하나로 통일하고 자잘한 수정사항 처리를 해야겠다고 귀찮음에 한 판단이 계속해서 화를 부른다는 걸 깨달았다. 당장 내일 가서 팀장에게 원격 저장소 브랜치 관리 문제부터 의논하고, 아무리 자잘한 레이아웃 수정사항이라도 이슈별로 브랜치 파고 해결되면 삭제하는 걸로 문제 해결을 시작해야겠다. 여기에 노션이나, 슬랙을 활용해서 아직 기능 개발이 덜 된 부분을 남겨놓는 것도 방법일 것 같다. 그럼 나중에 브랜치 병합 후 배포 시에 그 부분만 확인해보면 되니까! 이 두 가지가 완벽한 해결책일지는 모르겠지만 시도해봐야겠다.

한 줄 회고

신입에게 학을 뗀 이모가 그랬다. 신입이 6개월 지나면 다시 처음부터 가르쳐야된다고. 미안해, 이모. 그게 나였어. 중요한 건 메모하는 습관, 이건 꼭 들이자.