[IT 회사 생활] 초보 엔지니어에게 추천하고 싶은 일의 진행 방식

 본격적인 포스팅의 앞서 참고자료의 링크 내용을 번역했다는 점을 우선 밝힙니다. 의역과 오역이 있을 수 있습니다. 댓글로 지적해주시면 수정하겠습니다.

---

 선배 엔지니어에게 '얼마정도 진행됐습니까?'나 '왜 이 작업에 이만큼의 시간이 걸린건가요?'라고 듣는 경우가 있지 않나요? 또한, 작업 견적이나 업무 분할을 제대로 하지 않고, 코드를 쓰기 시작하는 경우도 있다고 생각한다.

 이로인해 결국 마음대로 코드를 쓰기 시작해 결국 거의 1부터 코드를 고치는 경험도 있을 것이라고 생각한다. 나의 경우는 업무 방식을 제대로 주입받았지만, 주의에 얘기를 들어보니 업무 방식을 어떻게 업무를 해야하는지 잘 모르는 사람들이 있는 것 같아 이 포스팅을 작성하게 됐다. 

 또한 엔지니어를 위해서 작성하였지만, 어떤 일에도 보편적으로 적용될 수 있다고 생각하기 때문에 참고하여 피드백 주시면 감사하겠다.

---

1. Compassion(상대에 대한 배려)를 가지고 일을 하자.

 초보 엔지니어는 왼쪽도 오른쪽도 모르는 것 투성이이다. 즉 기술적으로 능숙하지 않기 때문에 가능한 상대를 배려하고 업무를 추진하는 것이 중요하다. '배려한다는 것'은 소극적인 것이 아닌, 연장자에 대한 감사의 마음이나 부담을 주지 않도록 하는 마음을 가지고 작업을 하는 것이다.

 예를 들어, Pull Request가 났을 때 스스로 이상하다고 생각하는 코드에 무엇이든 보충 설명을 하지 않았다면 어떻게 될까? 당신이 생각하는 수준의 코드를 리뷰어는 틀림없이 파고들 것이므로 그전에 미리 Github의 코멘트로 보충해 놓는 것이 좋다. 작지만 이러한 것도 Compassion이다.

 또한 자신이 모르는 문제를 해결하고 있을 때에, 무엇을 모르겠는가를 자신이 스스로 정리하여 명확하게 하지 않으면, 선배에게 상담한 적이 있지 않나요? 질문을 받은 선배는 1부터 당신의 문제를 파악하지 않으면 안되므로, 꽤 시간이 빼앗겨버린다. 선배, 연장자의 시급은 저렴하지 않으므로 함부로 그 시간을 뺏지 않도록, 최소 자신이 해결이 가능한 부분까지는 해보고 (그래도 너무 고민하지는 않는 편이 좋지만) 질문을 하는 자세를 가지고 무엇이 모르겟는지, 어디까지 알겠는지를 명확하게 질문할 수 있도록 하는 것도 Compassion이다. 이것에 대해 뒤에서 더 설명하겠다.

---

2. 먼저 사양을 파악하자.

 업무를 받으면 먼저 사양서를 읽읍시다라고 말하면서도 비즈니스 측면의 사람과 직접 연락을 취해 확인하는 작업이 생길지도 모른다. 그래도 우리는 연장자로부터 설명받은 사양을 파악하면 우선은 OK이다.

 사양을 파악하는 경우,

- 목적

- use case(망라성)

- 필요한 기능

위주로 살펴보자.

---

3. 사양을 파악하면 업무 분해와 견적을 자세히한다.

 사양을 파악한 하자마자 코드를 작서아는 일을 하지 않도록 하자. 초보 엔지니어 중에 견적이나 설계를 하지 않고 돌진하여 결국 거의 1부터 다시 코드를 작성하는 경우도 종종 있다.

 그럼 어떻게 하는 것이 좋을까?

 먼저 업무 분해, 견적과 설계를 자세히하는 것이 중요하다. 설계의 경우 연장자나 선배 엔지니어가 큰 틀을 잡아주는 경우도 있으므로 여기서는 업무의 분산이나 견적에 대해서 말하도록 하겠다.

 예를 들어, Github의 issue내에 멘션을 붙여 아래와 같이 보고한다.

□ task A 1h □ task B 2h □ task C 2h □ task D 1.5h   └ task D-1 1h   └ task D-2 0.5h □ task E 1h

 처음의 우리쪽에서 더욱 자세하게 적는 것이 좋다고 생각한다. 또한 미경험의 분야에 어느정도 시간이 걸릴지 모르는 것우는 어느정도 시간이 걸릴지 검토도 할 수 없는 부분이므로, 1시간은 조사하는 시간으로 하고 싶다고 적어두는 것도 좋다고 생각한다.

 업무 분해와 견적을 하는 목적은 주로 아래의 세 가지라고 생각한다.

1. 아웃풋의 큰 틀과 틀린점이 없는지를 견줘보기 위해
2. 미리 리스크를 확인하여 불명확한 요소를 잡아내기 위해
3. 견적을 내는 것으로 실제의 작업 시간의을 파악하고, PDCA를 돌기 위해

---

4. PDCA 사이클을 돌려 견적과의 차이를 줄여간다.

 잠깐, 설명에서 벗어나서 왜 PDCA를 돌리는지에 대해서 설명한다. 견적을 내는 것으로 실제의 작업 시간과의 차이를 파악하고, PDCA를 돌리는 것은 (바로 위의 업무 분해와 견적의 목적을 참고) 일보에도 issue의 내든 어디에도 좋으므로, 구체적으로 지연된 원인을 자세히 작성하여 이것을 연장자, 선배에게 보여주는 형식으로 피드백을 받자.

 구체적이지 않고 대략적으로 적는 것은 NG이다. 예를 들어 근성으로 철야로 무엇인가를 하도록 해보겠다던가 더욱 의식 높이지 않으면 안 된다와 같이 애매한 표현이 아닌 구체적으로 적어야한다.

 왜 이렇게 까지 하는 것인가하면, 결국 지연된 원인을 잘 모르면 같은 미스를 반복하기 때문이다. 그러므로, 매일 매일 개선해 나가는 것이 중요하다. 

---

5. 불확정한 요소가 있는 경우 미리 구글링하여 해결, 해결하지 못한 경우는 연장자에게 상담하자.

 견적을 내면 대부분은 불확정적인 요소가 있기 마련이다. 따라서 불확정적인 요소가 생기면 어디가 불명확한지 잡는 작업을 해두자. 이러한 불확정한 부분이 병목 현상이 되는 부분(후술)이기 때문에 문제가 무엇인지, 만들고 싶은 것(최종 목표)이 무엇인지를 명확히 하여 구글링으로 해결하자. 그러기 위해 실장면에 불안 등이 있다면 선배나 연장자에게 상담을 하자. 

 또한 상담할 때에 대한 이야기인데, 알기 어려운 질문을 하는 경우고 있으므로 포맷을 정해 질문을 하는 것을 추천한다. 나의 경우 아래와 같은 포맷을 사용한다.

## 질문 (質問) // 질문의 내용 작성 ## 배경 (背景) // 그 배경을 작성 ## 목적 (目的) // 목적(하고 싶은 것)을 작성 ## 해당 개소(該当箇所) // 코드 중 해당하는 개소가 있다면 작성

 

---

6. 병목 현상이 될 부분부터 코드를 작성해나가자.

 견적서를 완료하였고, 어느 정도 불확정한 부분도 잡았다. 그럼 이제 무슨 작업부터 진행하는 것이 좋을까? 답은 시간이 걸릴 것은 같은, '병목 현상이 되는 부분'이다. 그러므로 견적서 단계에서 가장 시간이 걸릴 것 같은 중요하다고 생각하는 부분을 우선하여 진행하면 OK이다.

 이 작업의 우선순위를 다르면, (병목현상이 예상되는 부분이 아닌 쉬운 부분부터 한다면) 마감시간이 가까워지면 가까워질수록 숨통을 짓누르게 될 것이다. 

---

7. 1시간~ 1시간 30분마다 연장자에게 진척(진행된 정도)을 보고하자.

 이것도 보고-연락-상담의 이야기이지만, 1시간~1시간 30분 정도의 작은 단위로 진행 상황을 보고하는 것을 추전한다. 어느정도의 시간마다에 진척을 보여주는 쪽이 연장자의 확인 수고를 덜어주고, 앞서 세운 자신의 작업의 견적과의 차이를 알 수 있으므로 PDCA를 돌리는 것이 쉬워진다. 

---

8. 구두(口頭), Slack, Github Issue를 잘 구분해 사용하도록 하자.

 구두, Slack을 잘 사용하는 것은 연장자에의 부담을 최대한 주지 않는 선에서 의문을 해소할 수 있다. 어느정도 조사해도 잘 모르겠는 경우, 먼저 Slack에 질문, Slack에서 해소되지 않을 것 같고 시간이 걸릴 것 같은 것은 구두로 질문하는 것이 좋다고 생각한다.

 또한 Slack은 바로 로그가 흐르는 형태이므로 플로우형의 정보를, 제대로 기록으로써 남기고 싶다고 생각되는 정적인 정보는 Github Issue에 멘션을 붙여 질문하는 것이 좋다.

---

9. 구현에 대한 고민은 구두(口頭)로 상담 혹은 WIP으로 Pull Request를 내어 연장자에게 도움을 요청하자.

 이것도 보고-연락-상담의 이야기이다. 고민되는 경우 구두로도 좋으니 상담하자. 혹은 WIP에 Pull Request를 내어 코드 레벨에의 상담이 쉽게 이루어지도록 할 수 있다.

---

10. 상사에게 멘션된 경우 가능한한 빠르게 답장하자.

※ 정말 필요한 때에만 멘션을 보낸다는 전제하에

※ 중급자~상급자 엔지니어에게는 해당되지 않는 내용

 Slack에서 멘션이 날라 온 경우 가능한한 빠르게 답장하는 것이 좋다. 반응이 빨라야 커뮤니케이션하기 좋기 때문이다. 물론 작업에 집중하고 있어 빠르게 답장하지 못하는 경우도 있다고 생각하는데 이 경우는 '지금은 바로 답장 못드립니다.(今すぐ返事できないです)'라는 한 마디 답변이라도 괜찮다.

---

11. 복수의 선택지가 있는 경우, 메리트, 디메리트를 붙여 어느쪽이 좋은지를 상담, 제안하자.

 기능을 구현하고 있으면 이것도 좋지만 저것도 좋지 않을까, 어느쪽이 더 좋을까라는 고민을 마주하게 되는 경우가 종종 있다. 이 경우에는 경험이 풍부한 상사에게 '왜 이쪽을 채용하지 않았어요?'라고 질문을 받을지도 모른다.

 따라서 선택에 대한 옵션을 붙여 상담하도록 하자.

## 질문 // A와 B어느쪽이 좋은가?(C가 있는 경우 C도 추가하여 작성) ## 채용 // 결론을 먼저 작성 ## A // 선택지 작성 ### 메리트 ### 디메리트 ## B ### 메리트 ### 디메리트

 자연스럽게 결론부터 말하게 되므로, 아직 익숙하지 않다면 위의 포맷을 사용하자.

---

12. Pull Request를 낼 때는 확인하길 원하는 사람에게 멘션을 보내기 & 어디를 확인받길 원하는지 미리 명기해두기

 작업을 완료했다면(혹은 WIP으로 냈다면) 확인받길 원하는 것을 Pull Request에 기록, 확인하길 바라는 사람에게 리뷰요청을 보내자.

 자신이 없는 곳이나 특히 확인받길 원하는 곳을 정리해서 Pull Request에 적어두면 리뷰나 확인이 쉽다.

---

13. 한 번 리뷰받은 내용에 대해 스스로 체크 항목을 만들어, 같은 지적을 받지 않도록

Pull Request를 내면 많은 양의 리뷰가 반환되어 올 것이다.

예를 들어,

- 명칭을 잘 모르겠음.

- 이러면 CSS는 DRY에 쓰도록.

- N+1문제 발생하고 있음.

와 같이 구체적인 리뷰가 말이다.

 그럼 다음에 같은 실수를 하지 않도록 스프레드 시트에 스스로 체크 항목을 만들어 매번 과거에 리뷰 받은 내용을 클리어하고 있는지 확인하는 하자. 하나 하나 확인하는 것이 수고로울지 몰라도, 리뷰에서 같은 지적을 받지 않도록 스스로 구조를 만들어 놓는 것이 좋다.

---

참고자료

https://qiita.com/soyanchu/items/d1cb9785fc211941a009