Intro : 과연 개발자는 개발만 잘하면 장땡인가?

---

인턴십 사전교육으로 비즈니스관련 사전교육을 수강하였다.

처음에는 이렇게 생각했다.

“개발자가 문서화랑 코딩컨벤션 잘 지켜서 개발만 하면 되는거 아냐?? 뭐가 더 중요해??”

일을 해본 사람은 얼마나 우매한 소리를 하는 건지 알거다.

이전에 인턴도 해보고, 현직에서 몇 주 굴러본 경험으로는 비즈니스적인 부분을 아느냐 모르느냐는 천지차이라고 생각한다.

결국, 다 같이 일을 하는 거니까 말이다.

그렇다면 무엇을 어떻게 하는 게 개발자로서, 부사수로서, 사원으로서 일을 잘 하는 걸까?

TL;DR

---

목표 설정: 목표에는 반드시 기한을 설정하고, 역산을 통해 시간을 관리하자.

학습 즐기기: 계획이 틀어질 수 있으니 현재 학습을 즐기며 진행하자.

준비의 중요성: 기회는 준비된 자에게만 찾아오므로 항상 준비하자.

메뉴얼 숙지와 예의: 부서 내 전문성을 키우고, 예의를 갖춰 좋은 관계를 유지하자.

시간 관리와 인사: 미리 도착하고, 인사를 잘하여 좋은 첫인상을 남기자.

업무지시 이해와 실수 보고: 상사의 지시를 정확히 이해하고, 실수는 대안을 갖추어 솔직하게 보고하자.

질문과 문서화: 질문을 통해 명확히 이해하고, 문서화할 때는 요구사항을 정확히 파악하자.

목표, 그에 대한 역산

---

• 목표는 꼭 기한을 잡자
  • 안 그러면 흐지부지해지기 마련이다.
• 기한에 대한 역산을 추적하여 시간관리를 하자
  • (~6.20) 서비스 구현 완성
    • (~5.30) 중간 산출물 구현 완성
• 이건 내 생각 : 지금 하는 공부를 최대한 음미하는 게 어때?(계획은,, 틀어질 수 있으니 그냥 앞만 보고 열심히 달리자는 취지)
• 운이 와야 성공할 수 있지만, 운이 와도 준비가 안 되어있다면 놓친다.

좋은 부사수 되기

---

메뉴얼숙지와 매너는 기본

• 메뉴얼 숙지 → 부서 내에서 전문성 ⬆️ → ”좋은 팔로워“ 가 될 수 있다 (전문성이 높은 것은 좋은 팔로워의 조건 중 하나!!)
  • 메뉴얼들이나 문서들을 찾아 가장 잘 쓴 문서들을 흉내내보고 따라해보려고 하자.
  • “일하다보면 늘겠지” 하면 늘지 않는다. 의식적으로 노력해야 10년 동안 쌓인 노하우를 1년 안에 겨우 할 수 있다.
  • 최소 1,2년은 열심히 흉내내보며 고생하자.
• 좋은 매너 → 서로 우호적인 관계 ⬆️ → 좋은 네트워킹 → 언제든 든든한 지원군 → 일 잘 하네

  과연 나는 ~ 로서 어떤 매너, 어떤 에티켓을 지켜야할까?

  • 사람으로서
    • 사원으로서
      • 개발자로서
        • 막내 인턴으로서
    • 이건 내 생각 : 개발자 내에서는 전문성도 서로 우호적인 관계를 만들기 위한 충분조건, 따라서 전문성을 키우는 것 또한 서로 우호적인 관계를 ⬆️ 시키는 방법 중 하나

미리미리 다녀라

• 초반에는 2,30분 미리 도착해있자
  • 눈치도 챙기고
  • 출근길에 어떤 일이 생길지 모른다

인사를 열심히 하고 다녀라

• 인사에 대해 좋은 글을 공유해주셨다. 인사를 열심히 하고 다녀야겠다. ㅎㅎ

  인사를 하지 않는 자는 성공하지 못 한다.

  인사는 존경의 의미이다. 존경하지 않는 자는 남을 존중하지 않는다. 남을 존중하지 않는다면 남들 사이에서 나의 위치를 모른다. 나의 위치를 모른다면 나의 실력을 모른다. 나의 실력을 모르는 자는 발전할 수 없다. 발전하지 않는 자는 경쟁의 세계에서 살아남을 수 없다.

상사와 일을 잘하는 법

---

상사는 리더일 수 있지만 결국 직장에서는 누군가의 부하, 즉 팔로워이기도 하다

업무지시

• 업무지시를 받을 때에는, 상사(상대방)가 처한 상황이나 의도를 잘 파악해야한다.
  • 우리는 예로부터 유럽과 미국과 달리 농경사회였다. 따라서 정착문화가 길들었다.
    • 상대방과 긴밀하고 오랜 관계를 형성하게 되었다.
    • 이에 따라 상대방의 상황을 고려하여 커뮤니케이션을 하는 문화가 형성되었다.
  • 이러한 문화가 한 회사에 정착하여 오랫동안 긴밀하게 일하는 예전 세대에도 깃들여졌다.
  • 최근에는 정착하는 문화보다, 여러 회사를 옮겨다니는 문화가 자리잡혔다.
    • 이에 따라 상황보다 텍스트 그 자체의 의미를 중요시하는 문화가 형성되었다.
  • 따라서 들리는 내용 뿐 아니라, 뒷배경과 그 상황에 대해서 집중하자.
    • 가령,,,
      • 이게 급한 일인지
      • 상급자가 이 안건에 대해서 더 윗상급자한테 보고해야하는 중요한 안건인지

실수를 보고하는 방법

• 실수를 보고하는 방법은 다음과 같다.
  1. 실수를 했다면 솔직하게 이야기하라 (← 이건 내 생각)
     1. 안 그래도 실수해서 믿음에 흠이 갔는데 거짓말이 들통나면 더 이상의 믿음은 없다.
  2. 실수 원인 / 대안들 / 대안들에 필요한 것을 ****챙겨서 보고하라.

     1. 대안을 윗사람한테 찾지마라

        eg.

        부사수 : “음,,,~~상황인데 어떻게 해야할까요 선배님 ㅠㅠ”

        사수 : “음,,,(ㅅㅂ 그걸 나보고 어쩌라고,,)”

  3. 타이밍을 잘 보아라 (==눈치를 챙겨라)

     1. 자주,수시로 보고하고

        → 사수가 ~잘 되고 있어? 라고 물어본다면 이미 늦었다

     2. 진척도에 따라 보고하자

        → step 별로 진행되는 업무인 경우 A step 이 끝났다면 B step 하기 전에 보고하자

질문을 잘 해라

못 알아듣니 마니 혼내더라도 해라. 질문은 잘못된 구현 되돌릴 수 있는 제일 빠른 방법이다.

1. 잘못 들은 음절이 있다면 질문해라
   1. ~ 처리해 → (음,,뭐라고 하셨지? 이거겠지?) 넵 ❌
   2. ~ 처리해 → (음,,,뭐라고 하셨지?) 혹시 ~ 수행하라고 말씀하신 게 맞을까요? ✅
2. 선택안이나 구조도를 제시하여 피드백의 범위를 줄여라
   1. 이 부분에 대해서 어떻게 할지 감이 안 잡혀요 ❌
   2. 대안A, 대안B가 있는데 대안A가 ~ 이유로 좋은 것 같습니다. 대안 A로 구현해볼까요? ✅
3. 예시나 사례가 있는지를 물어보아라.
   1. 혹시 이런 요구사항에 대해 비슷한 사례를 보신 게 있으실까요? ✅
4. 요구사항을 잘 정리하되, 검사 받지는 마라.
   1. A-Z 까지 정리하는 건 좋다.
   2. 하지만 검사 받는 것은 상사의 기분이 나쁘다. 아래와 같이 이해되기 떄문이다.
      1. “야~ 너 이렇게 말한 거 확인해! 너 나중에 딴 소리하기 없기야!”
      2. 오히려 일을 깔끔하게 하는 방법이기는 하나, 기분이 안 좋은 방법이긴하다
   3. 잘 정리하고, 정리한 부분에서 궁금한 부분을 최대한 압축해서 질문하는 게 좋다.
5. 상사가 바쁘다면 질문할 게 있다는 티를 내라.
   1. “바빠보이시는데 혹시 질문드려도 될까요?” 라며 한 번 찾아가자.

E-Mail 쓰는 방법

---

• 제목 구조

  [목적] ${내용}-${version}-${date}

  eg) [확인요청] 에러리스트 첨부-ver01-2024.01.23

• 내용 구조
  • 우선 인사와 함께 소속,이름을 밝히자

    안녕하십니까. 백엔드팀 신입 인턴 임지훈 사원입니다.

  • 용건 요약을 서두에 하여 독자를 배려하자.

    에러리스트 확인 관련하여 에러리스트 markdown 파일 첨부드립니다.

  • 이후 세밀한 내용을 서술하자.

    ~ 에러는 ~ 로직에 대해서 ~ 발생하였습니다. ~ 관련해서 확인부탁드립니다.

    또한 blah blah~~~

문서화 잘 하기

---

문서작성 컨벤션이 있다면 “반드시” 해당 컨벤션을 따르자!

없다면 아래 가이드라인을 적극 활용하자.

• 문서화는 다음 프로세스를 통해 진행된다.
  • 요구사항 도출 → 문서 작성 → 보고 및 제출
  • “요구사항 도출” 파트가 가장 중요하다!!!
    • 무엇을 시키는지를 정확히 알아야한다.

요구사항 도출

• “왜 시키는가?” 를 고려하자. (상급자의 상황과 나의 컨텍스트를 고민해보자)
• 질문을 적극적으로 하여 어떤 지시사항인지 정확히 파악하자.
• 마감기한이 언제인지를 숙지하자.
• 요구사항들을 정리/나열한 뒤, 각각의 우선순위가 어떻게 되는지 정리하자.

문서화 구조

• 전체적으로는 아래 구조를 따른다.

  문제/상황 → 원인 → 방안들 → 한계점 및 근거 → 선택안 → 향후계획

• 개발문서 타입에 따라 구조를 달리한다.
  • if Issue해결기

    문제 → 원인 → 대안 → 근거 → 구현과정 → 추가 개선 및 결과

  • if 구현기

    상황/목표 → 근본적인 설계 → 대안 → 근거 → 구현과정 → 추가 개선 및 결과

대안 및 아이디어 도출기

---

• GUI 를 통해 대안들이나 아이디어들을 도식화하여 정리한다. (강사님은 git mind 를 추천, 나는 drawio 사용 중)
• 5WHY 를 통해 대안을 세운다.

  5WHY 란??

  : 5번 정도의 문제에 대한 원인을 트리구조로 분석, 근본적인 원인을 찾는다.

  eg) ResourceNotFoundException 이 발생하였다. (문제)

  → 왜? : 요청값에 대한 아이템을 찾을 수 없다.

  → 왜? : 요청값에 대한 아이템이 없다.

  → 왜? : 요청값이 잘못 되었다.

  → 왜? : 잘못된 요청값이 Service 와 Infra layer 까지 입력되었다.

  → 왜? : Presentation Layer 에서 요청값 검증을 하지 않았다.

• MECE 를 통해 대안들을 분리한다.

  MECE 란??

  : 각 변인 간 독립적이여야하고 (Mutually Exclusive),

  모든 변인이 누락없이 정리되어야한다.(Collectively Exclusive)

회의안 잘 쓰기

---

회의안 컨벤션이 있다면 “반드시” 해당 컨벤션을 따르자!

없다면 아래 가이드라인을 적극 활용하자.

• 전체적으로는 아래 구조를 따른다.

  Done : 결정된 사안

  • Service Layer 에서는 Interface 를 무조건 만들기로 하였음

  Will Do : 예정된 사안

  • Docker Config 값에 관련되어 의논 예정 (~2025.03.01)

  TBD(To Be Determined) : 미정

  • Redis Replica 관련된 회의 요망