회사에 와서 보이는 지식이 있다

얼마 전에 기술 배우는 타이밍이 있다는 내용의 글을 쓴 적이 있는데, 그 내용의 연장선상에서 이 글을 쓰게 될 것 같다.

기술 배우는 타이밍에는 외부 환경이 큰 영향을 미친다.

이 때문에 학생 때 중요하게 느껴지는 지식과 회사에 와서 중요하게 느껴지는 지식이 많이 달라지는 것 같다.

특히나 회사에서 일하지 않았다면 그 가치를 체감하기 어려운 지식들이 있다.

오늘은 이런 지식들에 대해서 생각나는 대로 언급해 보려고 한다.

밖에서 안 보이는 것들이 있다

지금 다니는 회사에서는 운영 경험이 없는 상황에서 새로운 서비스를 만드는 (천재일우의) 기회를 얻었지만,

반대로 기존 서비스에 대한 운영 경험이 없다보니 자꾸 놓치는 부분이 생기곤 한다.

가령 로그 분석은 지금도 프로세스가 머릿속에 명확하게 서지 않는 부분 중 하나다.

"무엇을 로깅해야 하는가?"

"로그를 검색하고 저장하기 위해 Elasticsearch 등의 DB를 사용하는 이유는 무엇인가?"

"로그 분석을 통해 어떤 일을 할 수 있으며, 어떤 가치를 창출할 수 있는가?"

같은 질문에 대해서 아직 답을 알지 못하는 상태다.

운영 경험이 쌓이면 알 수 있을까.

아키텍처도 그런 부분 중 하나인 것 같다.

"하루 16만 건의 요청이 들어오는 서비스에서는 어떤 아키텍처를 사용해야 하는가?"

"어떠한 작업에서 Worker를 쓰면 성능이 높아지는가?"

"이 상황에서 DB 샤딩은 어떤 기준으로 해야 하는가?"

같은 질문에 대해서 어떻게 답할 수 있을까?

인프라도 그렇다.

AWS만 해도 기껏해야 EC2, RDS, Lambda, CodeDeploy 정도만 존재의 사실을 알고 있었는데

VPC, IAM, Kinesis, CloudWatch 같은 서비스가 갑자기 매우 중요하게 느껴지기 시작한다.

써놓고 보니까 거의 다네.

교보문고죠? 여기부터 여기까지 주세요

일은 같이 해야 한다

혼자 작성한 코드를 혼자 배포하고 혼자 운영했다면 협업 도구를 사용하지 않았겠지만,

회사에서는 협업을 위해서 사용하는 도구가 다 따로 있다.

지금 다니는 회사에서는 Jira를 통해 이슈를 등록·관리하고, 진행 상황을 서로에게 알리고 있다.

이 Jira는 사실 모두가 어려워하는 느낌이 있지만,

서로 업무 현황을 알리고 해야 할 일을 분배하는 데에는 분명 효율적인 부분이 있다.

git flow 등 협업 방식이나 Jenkins 등 배포에 관련된 도구도 중요하다.

특히 내 경우 개인 프로젝트를 할 때는 별도 서버를 띄우는 부담이 있는 Jenkins보다는 Travis CI를 사용했었는데,

이 둘의 느낌이 상당히 다른 것 같았다.

또 그냥 커뮤니케이션 능력도 중요하다.

"개발자는 다른 직업보다 커뮤니케이션에 대한 부담이 덜하지 않아?"라고 누가 물어본다면 "아니다"라고 대답할 것 같다.

기획 파트와 소통하며 정책에 대해 이해하고, 디자인 파트와 소통하며 시안에 대해 이해하고,

API 설계 같은 작업을 맡는다면 클라이언트 개발자와도 매우 빈번하게 얘기해야 한다.

방금 일어난 회의, 대화에 따라 내가 개발해야 하는 범위가 급변하기도 하고,

커뮤니케이션이 원활하지 않으면 엉뚱한 곳에 노력을 쏟는 일이 일어나기도 한다.

미리 배울 수는 없을까

문제는 이런 지식들이 다 실무에서는 중요한 지식들이라는 것이다.

그래서 신입으로 들어와서 동료 개발자들과의 커뮤니케이션에 참여하다 보면,

분명 이것저것 공부했는데 내가 너무 준비를 덜했나 싶은 생각을 하게 되는 것 같다.

입사 전에 이런 지식들을 미리 배울 수 있는 방법은 없었을까?

혹은 이런 지식들의 가치나 필요성을 와닿게 전달받고 전달할 수 있는 방법은 없는 걸까.

어떻게 하면 필요한 지식들을 효과적인 방법으로 배우고 전달할 수 있을지 생각해 보고 있다.

이런저런 생각이 많아지는 하루다 🤔