잔업이랑 공부하면서 자정이 넘어갔다.
매일 글 쓰는 게 쉬운 일은 아니라고 생각했지만... 😓
최근에는 API 개발 전 Mock 데이터를 만들면서 일을 어떻게 하면 편하게 할 수 있을지 생각하고 있다.
오늘보다 내일 더 효율적으로 일하기 위해 하는 공부들.
셸 스크립트나 json schema나 git 같은 것들을 예로 들 수 있겠다.
기술마다 배우는 계기가 다르다
생각해 보면 답답해서 공부하게 되는 기술들이 있다.
vi 명령어는 잘 모르지만 dd(한 줄 삭제), o(커서 바로 아랫줄에 삽입)는 안 쓰면 하도 불편해서 외웠다든지.
Mock 데이터에 필요한 파일 메타데이터를 손으로 만들다가 답답해서 셸 스크립트를 배웠다든지.
JSON 데이터를 일일이 손으로 고치다가 답답해서 JSON Schema를 사용하게 됐다든지... 다양한 예들이 있을 것 같다.
이런 기술들은 필요한 상황에 부딪치기 전에는 좀처럼 배울 생각을 하지 못하지만, 배우고 나면 꽤 요긴하게 쓸 수 있다.
반면 특별한 계기 없이 공부해도 생각의 범위를 넓혀주는 기술들이 있었던 것 같다.
<RESTful Web API>를 읽을 때는 자기 서술적인 JSON 스키마를 누가 이미 생각해 냈다는 게 놀라웠고(Collection+JSON은 정말 매력적인 것 같다)
<토비의 스프링>을 읽을 때는 단순하고 수동적인 코드를 결합해서 비즈니스 로직을 구성하게 해주는 스프링의 DI가 천재적이라고 생각했었다.
<Learn Git Branching>이라는 인터랙티브 튜토리얼을 통해서는 Git의 커밋이 불가역적인 것이 아니라 손쉽게 정리할 수 있는 대상이라는 것을 알게 되었다. Git을 "완전 편하다"고 생각하면서 쓰기 시작한 순간이었다.
타이밍을 잡기 위해서는
이런 헐거운 기준으로 무 자르듯 기술을 구분하려는 것은 아니다.
다만 어떤 기술은 몇 시간 동안 책을 펴놓고 진지하게 공부하는 게 어울리지 않을 수도 있다.
답답할 때 외우는 vi 명령어가 절실하게 느껴지는 것처럼, 기술마다 필요성을 느끼는 때가 따로 있는 것 같다.
그래서 기술 공부의 필요성을 자주 느끼려면,
직접 일을 하며 답답함을 느끼는 경험적 측면과,
주변에 좋은 책과 글을 권하고 공유하는 문화적 측면이 모두 중요하지 않을까 싶다.
또 마치 생산자가 소비자에게 지금까지 몰랐던 수요를 알게 해 상호작용을 이끌어 내는 것처럼...
지식을 전달하기에 앞서 그 지식의 필요성을 절절하게(?) 전달하는 것도 중요하지 않나 싶은 생각이 든다.
그런 글로 블로그를 채울 수 있다면 좋은 개발 블로그가 될 것 같다.
일 집중해서 하고 주말마다 책도 읽으며 그런 타이밍을 재 보아야겠다.
기술 배우는 타이밍이 곧 글쓰기의 타이밍이 되므로 😂