프로필 사진
소하
bolt icon1.9k·2년 이상·
5.6k
·수정됨
공유

신입이 회사에서 살아남는 법

신입이 회사에 가서 알아야 할 것들


며칠 전에 취직을 한 것 같은데 벌써 근속 6개월차가 되었습니다.

시간이 정말 빠릅니다.

부족한 실력으로 과분한 회사에 들어가 진짜 온갖 일을 다 겪은 것 같습니다.

밤을 새보기도 하고(야근 없다고 했는데...), 칭찬도 받아보고, 혼도 나보고...


물론 그 경험은 연차가 몇 년 씩 되는 분에 비할바야 못되겠지만,

이제 막 취업을 했거나 할 예정인 분들께 도움이 될 까 싶은 마음과

스스로도 겪은 바를 토대로 같은 실수를 하지 않기 위해 여기에 글을 남겨 리마인드 하려고 합니다.


오키에 계신 선임분들께서도 이 글이 더욱 풍성해질 수 있도록 많은 피드백을 남겨주시면 감사하겠습니다.



1. 보고하라

See 가 아니고, Report 입니다.

신입은 무슨 업무를 수행하던 간에 항상 보고해야 합니다.


서로의 일이 바쁜 회사 특성 상

여러분의 사수 혹은 사수가 될 사람이 24시간 붙어서 감독해줄 수 없습니다.


이리 치이고 저리 치이다 보면 했던 지시를 잊어버리거나

또는 '알아서 해라' 이런 답이 날아오죠.


그런데 '알아서 해라' 라고 했다고 진짜 신입인 내가 '알아서' 해버리면 거의 100% 혼납니다. 

특히 운영중인 서비스와 관련된 작업에 있어서는 반드시 

내 선임자 이상의 권한을 가진 사람의 확인을 받고 허가가 떨어진 하에서만 실행에 옮기시기 바랍니다.


그저 책임을 떠넘기겠다는 얄팍한 생각이 아닙니다. 

혼자서 하는 프로젝트가 아닌 이상 내가 짠 코드는 운영의 차원을 넘어 다른 사람의 작업에까지 영향을 끼칠 수 있습니다. 아니, 끼칠겁니다.

그리고 그 코드로 인해 자신이 예기치 못한 더 큰 사고를 야기할 수 있으며, 이는 회사 인력 자원의 낭비로 직결됩니다.


다른 일도 해야하는데, 여기에 까지 시간을 뺏겼다, 이제 퇴근해야 하는데, 이 사람 때문에 사고가 발생해서 야근을 해야한다 

이런 생각을 하게 만드는 순간 회사에서 자신의 평판이 떨어질 겁니다.

그렇게 되고 싶지는 않으시죠?


그래서 보고해야 합니다.

어떠한 업무를 수행할 준비가 끝났으면

'제가 이러이러한 지시에 대해 해당 코드를 어떻게 수정하였으며,

허가해주시면 저러저러하게 조치하도록 하겠습니다.'

OK 사인이 떨어지면 그때 작업을 수행하시면 됩니다.


만약 일의 책임자가 본인 자신 뿐이거나 허가를 구할 사람이 없다면,

반드시 내 업무의 진행 상황과 변한 부분 등 스케줄 관리에 각별히 신경쓰시기 바랍니다.

예를 들면 이번에 오류가 생기면 롤백 시점은 어디고,

수정한 부분이 이 부분이니 여기부터 살펴보자 이런 것들이겠네요.


자신의 임의행동으로 인해 운영에 손해를 끼치는 것 보다,

한 번이라도 더 확인받고 검토해서 오류를 최소화하는 것이 훨씬 이득입니다.



2. 백업하라

백업의 중요성은 일해보신 분이라면 말씀 안드려도 아실겁니다.

특히 신입 시절에 멋모르고 실수를 자주하게 되는 부분이 바로 이 부분입니다.


퀴즈 한 번 내보겠습니다.

어떠한 클래스가 지금 서버에 올라가서 가동중인데, A라는 기능을 추가해서 올린다고 합시다.

선임자에게 보고를 마친 상태고, 이제 해당 기능이 추가된 클래스 파일을 서버에 반영하기만 하면 되는 상황입니다.


A라는 기능은 그 클래스에 추가되어, 로컬에서 테스트 해 본 결과 이상이 없는 상태입니다.

서버에서 기동중인 그 클래스 파일을 어떻게 처리하는게 옳을 것 같습니까?


1. 이전 클래스 파일은 더 이상 사용하지 않을 것이므로 그대로 덮어쓴다.

2. 이전에 사용하던 클래스 파일을 백업해 로컬에 저장해 두고 새로운 클래스 파일을 반영한다.


답이 너무 뻔하죠? 근데, 업무의 흐름과 그 중요성을 잘 모르는 상태에서

작업에 일단 들어가면 의외로 그냥 덮어쓰시는 분 많습니다.

(업무 경력 2년이 넘은 분도 반영할때 그냥 덮어썼다가 오류가 나서 혼나는 경우를 봤습니다.)


일이라는건 어떻게 될지 모르는 법입니다. 

테스트를 모두 통과해 반영하기만 하면 되는 상황에서 그냥 덮어쓰기로 반영을 해놨더니,

갑자기 고객의 마음이 바뀌어 아까 했던 지시를 없는 일로 해달라는 지시가 내려옵니다.


미리 백업을 받아두었다면, 아까 올렸던 클래스의 이름을 바꾸던지 해서 무력화 시킨 다음,

백업해 둔 파일을 올리기만 하면 그만입니다. 몇 십초정도면 작업이 끝나죠.

그런데 백업받지 않았다면, 수정했던 코드로 찾아가 일일이 다시 주석처리를 하거나 삭제를 하고

프로젝트를 다시 빌드하여 새롭게 생성된 클래스 파일을 다시 반영해야겠죠.


일처리가 오래 걸릴 수 밖에 없습니다.


신입은 일을 그렇게 빨리 할 수 없습니다. 그렇게 할 수 있다면야 좋겠지만, 대부분 그렇지 않죠.

이런 식으로 쉽게 처리할 수 있는 일을 두 번, 세 번 일해서 처리하게 되면

가뜩이나 일 배우고 코드 흐름 깨우치기도 바쁜 마당인데

일처리까지 느리다는 인상을 심게 됩니다.

'그게 그렇게 오래 걸릴 일이야?', '아직 안 끝났어?'

재촉 아닌 재촉을 듣는 순간 머리는 하얘지고, 실수할 가능성은 높아집니다.

악순환이 이어지죠.


백업은 신입 입장에서 갖출 수 있는 최고의 문제 해결 대책이며,

피해를 최소화 할 수 있는 뛰어난 방패가 됩니다.



3. 의심하라

이건 코딩 태도에 관한 문제입니다. 

(사람을 의심하라는게 아닙니다;;)

내가 짠 코드가, 여러 요인으로부터 안전한지, 올바른 동작을 보장할 수 있는지를 끊임없이 의심해봐야 합니다.


자신이 짠 코드가 일단 표면적으로 제대로 실행된다고 해서 

이게 운영으로 넘어가 100% 예외없이 정상적으로 실행될지 안될지는 모르는 노릇입니다.

생각지도 못한 경우가 발생하거나 비정상적 입력값으로 인한 오작동이 발생할 수도 있어요.


간단한 예를 하나 들어봅시다.


```

어떠한 사용자가 어떠한 URL명령을 통해 DB에 insert 요청을 보냅니다.

요청이 실행되면, A라는 테이블에 사용자의 이름과 등록 시간이 insert 됩니다. 


그러나 해당 요청은 한 시간에 한 번 이상 시행되어서는 안됩니다.


그래서 이 요청이 들어오면, A라는 테이블에서 해당 사용자의 이름으로 가장 최근에 insert된 row의 정보를 불러옵니다.

불러온 로그의 정보 중 등록된 시간을 나타내는 컬럼의 값과, 현재 시간의 값을 비교하여

해당 시간의 차가 1시간 미만이라면 false. 즉 시행하지 않고, 그 이상이라면 true. 정상적으로 Insert 작업이 수행됩니다.

```


언뜻 보면 문제가 없어보입니다. 근데, 이건 치명적인 문제가 있습니다.

만약 10초 안에 찾으셨다면 최고입니다.

원인을 찾았을 뿐 아니라, 해결 방안까지 머릿속에 떠올랐다면 더할 나위가 없습니다.

한번 찾아보세요.



찾으셨나요?

다른 답도 있을 수 있겠지만, 가장 먼저 부상하게 될 치명적인 문제는 이겁니다.

바로 새롭게 등록한 사용자. 즉 A라는 테이블에 한 번도 등록한 적이 없는 사용자가 

해당 명령을 수행하려 할 경우, 테이블에서 정보를 찾을 수 없기 때문에

NullPointerException이 발생할거라는거죠.


주로 테스트되는 상황이 아닌,

새로운 어떤 환경에 대해 일어날 일에 대한 고찰이

충분히 이루어지지 않으면 쉽게 맞닥뜨리게 되는 상황이며,

특히 저와 같은 신입 입장에서 쉽사리 하게 되는 실수 중 하나입니다.


또한 세상을 둘러싼 한없이 깊은 정보의 바다에서 일어나는 일은 

우리가 생각하는 것 보다 훨씬 살벌하다는 것을 아셔야 합니다.


'개발자 도구'라는 것이 더 이상 '개발자' 에게만 국한된 도구가 아니게 됨으로써

개발의 세계에서는 이미 서로가 먹고 먹히는 지옥도가 펼쳐진 지 오래입니다.


6개월 남짓한 근속기간동안 멀쩡했던 서비스가 예기치 못한 상황,

그리고 그나마 젊은 저보다 더욱 젊은 친구들의 호기심에 기반한 단순한 공격으로 인해 

뒤집어지는 모습을 수 없이 목도했습니다.


상황을 파악하고, 더 나아가 그 상황을 장악하는 스킬은 

앞으로 개발자에게 있어 선택이 아닌 필수가 되어야 할 것입니다.



물론 현업에 있어 중요한 사항은 이것들 말고도 훨씬 많지만, 

제 개인적으로 가장 중요하다고 생각하는 3가지를 서술해 보았습니다.

글을 쓰고나서 보니 1, 2, 3번은 서로 독립적인 사항이 아니라,

모두 함께 고려되어야 할 사항인 듯 합니다.


앞으로 취직하실 분들이나, 취직한지 얼마 되지 않으신 분들,

그리고 개발을 한참 배우고 계신 분들께

이 내용이 조금이나마 도움이 되었으면 좋겠습니다. 

14
cat-footer