안녕하세요. 쿠킴입니다.
2023 상반기에 인턴 백엔드 개발자로 3개월 동안 일을 하였는데요.
어떻게 회사에 적응하고 기여하게 되었는지 되돌아보고 자유 형식으로 회고를 작성하였습니다.
글에 등장한 인물이나 상황은 실제가 아닌 가상의 이야기입니다.
목차
- 조급하지 않기
- 인사 잘하기
- 온보딩! 회사에 기여하는 첫 번째 방법
- 근무 일지 작성하기
- 데이터/아키텍처 뽀개기
- 스스로 개발 기여하기
- 첫 업무
- 피드백받기
- 언어는 중요하지 않다.
- 마치며
첫 출근
첫 출근을 하였습니다. 인사 담당자에게 간단히 회사 소개를 받고 함께 일할 팀원들과 인사를 합니다.
쿠킴: '안녕하세요.! 신입으로 입사한 쿠킴입니다. 잘 부탁드립니다.'
팀원들: '오 쿠킴! 안녕하세요 팀장 000입니다. 팀원 000이에요. 잘 부탁드려요~'
개인 자리에 앉았습니다. 책상엔 개발 장비와 웰컴키트가 있군요.! 마음이 설레기 시작합니다. (앗, 웰컴 키트가 없다고요? 어쩔 수 없죠.)
쿠킴: '팀장님 제가 무엇을 하면 될까요?'
팀장: '2~3주는 맘 편히 개발 환경 설정하시고 회사 적응하시면 됩니다. 궁금한 건 팀원들에게 편히 물어보세요~'
그렇게 개발 환경 설정과 회사에 적응을 시작합니다. 앗, 이것이 온보딩인가?!
조급하지 않기
입사 후 처음 2주, 아니 몇 달은 회사가 어떻게 돌아가는지 파악하게 됩니다. 당장 뭔가 기여하고 싶은 마음이 드는데요. 코드를 작성하고 PR도 보내고 싶은데, 온보딩하며 문서만 보고 개발환경만 설정하면 꽤 지루합니다. 스크럼 때 팀원들은 바쁘게 일한 것을 공유하지만 나만 매일 '온보딩'만 쓰면 어딘가 불안합니다. 하지만 괜찮습니다. 적응할 시간이 필요하니까요. 팀원들도 알고 있습니다. 제가 적응할 시간이 필요하다는 것을요.
인사 잘하기
팀원들: '쿠킴, 다른 팀들에게도 인사 잘하면 좋아요~ 개발팀이나 QA/DevOps/보안/기획/운영/경영/디자인 ... 팀 모두 상관없이요~'
인사만 잘해도 반은 먹고 들어간다고 하죠. 정말이더라고요.
첫 입사 후 당장이라도 뭔가 보여주고 싶은 마음에, 적응이 바쁘다는 핑계로, 또는 민망하고 부끄러워서 인사를 가끔 놓칠 때가 있는데요.
밝은 미소로 먼저 인사하는 건 어떤가요?!
인사는 협업의 시작이죠!
온보딩! 회사에 기여하는 첫 번째 방법
회사마다 온보딩 프로세스가 다릅니다. 온보딩이 잘 갖춰진 회사라면 좀 더 마음 편하고 빠르게 회사에 적응할 수 있습니다.
온보딩이 잘 안 되어있다고요? 아예 없다고요? 괜찮습니다.! 오히려 회사에 기여할 수 있는 아주 쉽고 빠른 방법이니까요.
온보딩에서 배울 것은 다양합니다.
회사 출입 사원증 발급부터, Wi-Fi 연결, 보안 문제, 회사 계정 발급, 권한 신청, 소프트웨어 구매, Slack, Jira 가입, 담당 서비스 이해, 아키텍처, 데이터, 배포 이해 등 등... 참 많습니다.
만약 사내에 온보딩 문서가 존재합니다.
해당 문서는 내가 입사한 날부터는 최신이 아닙니다. 언제든지 바뀌고 수정하고, 추가할 부분은 존재하죠. 온보딩 받으며 이런저런 부족한 점이나 개선할 점이 있다면 반드시 기록해 둡니다. 정리한 내용을 인사팀/팀원들에게 전달하거나, 수정 요청을 합니다.
만약 온보딩 자체가 존재하지 않습니다. 야생의 환경에서 자라야 한다고요? 앗! 최고의 기회를 만났군요.
온보딩 기간 동안 겪었던 일들을 문서화합니다. 다음 입사할 사람을 위해서 말이죠.
보통 온보딩 때 팀원들이 도와줍니다. 팀원들 개개인이 가지고 있는 회사 생활 꿀팁이 쏟아집니다.
좋습니다! 이것도 잊지 말고 문서에 추가해 보아요.
가장 중요한 것은, 문서화에 조급해하지 마세요.
한 번에 하려고 하지 마세요. 아니할 수 없습니다. 하루하루 배울 때마다 조금씩 개인 위키에 작성하고, 어느 정도 다듬은 후에 공개해도 됩니다.
쿠킴: '부족하지만 온보딩 문서를 내용을 작성해 보았습니다.'
팀원들: '오! 5! oh!'
근무 일지 작성하기
개인 근무 일지를 작성해 보는 것은 어떤가요?
저 같은 경우 첫 출근하여 하루의 근무 일지 양식을 작성하고 오늘의 Todo 작성 후 무엇을 잘했고 못했는지 체크를 했어요.!
근무 일지이자 일일 회고이죠.
근무 일지나 회고의 장점은 이미 알고 있을 거예요.
꼭 매일 작성하지 않아도 됩니다. 다만, 어느 정도 적정 시간마다 회고하는 것은 중요하더라고요.
1주일이나 한 달마다 회고하며 내가 이번에는 어떤 일을 했고, 무엇을 배웠고, 아쉬운 점과 개선할 점을 알 수 있습니다.
마치 문장의 마침표를 찍는 것처럼요. 마침표가 있어야 읽기 쉬운 글이 되지 않겠어요?
데이터/아키텍처 뽀개기
담당할 서비스의 데이터와 아키텍처를 이해하는 것은 매우 중요합니다. 서비스 전체를 이해하기 쉽기 때문이죠.
관련 문서를 모두 읽거나 팀원들에게 설명을 요청합니다.
그리고 스스로 이해합니다. 예를 들어 ERD를 분석하여 데이터 흐름이 어떻게 흐르는지 파악합니다. 스키마의 각 칼럼이 무엇이고 어떻게 저장되고 수정/삭제되는지 파악한다면 서비스가 보다 더 잘 보일 수 있습니다.!
저 같은 경우, API를 분석하며 ERD가 어떻게 조회/변경되는지 파악하고, ERD를 화이트보드에 작성할 수 있는 정도로 이해하였습니다.
스스로 잘 이해하고 있는지 팀원에게 설명하고 피드백받는 것도 좋습니다.!
시스템, 배포 아키텍처도 이해합니다. 봐도 잘 모르는 부분은 팀원에게 물어보거나, 개발하며 자연스럽게 배울 수 있으니 너무 부담 갖진 말아요.
스스로 개발 기여하기!
온보딩 문서와 프로젝트 코드 분석이 길어지고 있습니다. 언제 개발을 할 수 있을까요?
하지만 신규/인턴 입사자에게는 대안이 없는 경우를 제외하고 업무에 중요하고 Risk 한 일을 맡기지 않습니다.
그렇다면 어떻게 개발에 기여할 수 있을까요? Risk 하지 않고 사소하지만 중요하기도 한 업무를 스스로 찾아보아요!
case1. 문서화하기
로컬 개발 환경을 실행시키려 하는 데 뭔가 잘 안됩니다. 앗 왜 그렇지?
기회가 왔습니다. 로컬 개발 환경 실행시키는 문서를 수정해 볼까요?
case2. 로컬 개발환경 추가하기
앗, 로컬 개발 환경이 완전 로컬이 아니라 Dev 환경을 참조하고 있군요? 이번 기회에 완전히 로컬 개발 환경(Embedded, Docker)에서 실행시킬 수 있는 환경 구축이나 쉘 스크립트를 작성해 볼까요?
case3. API 문서 최신화하기
API 문서가 뭔가 잘못되어 있는 것을 발견했습니다.! 수정해 볼까요?!
case4. API 문제점 발견하기
API를 직접 요청하며 응답값을 확인 / 테스트를 해보고 있습니다. (prod 환경이 아닌 dev/qa 환경에서 테스트하세요.)
앗, 조회 API 요청에서 페이징 처리하는 데 size에 limit이 안 걸려있네요.! size=100000 하니까 실제 데이터가 100000개가 오네요!
앗, 조회 API 요청에 sort 파라미터가 막혀있지 않네요.! 누구나 정렬을 할 수 있어요.! 의도된 걸까요?!
앗, 존재하지 않는 ID로 요청했는데 정상적이라면 400 Bad Reqeust이 나와야 하지만 500 Internal Server error 에러가 발생하는군요!
case5. 단위 테스트 케이스 추가
이미 구현된 단위 테스트로 코드를 이해해보고 있습니다.
앗, 엣지 케이스가 빠진 거 같아요.! 추가해 볼까요?
case의 경우들로 개발에 기여를 시작할 수 있습니다. (case는 예 일 뿐입니다. 다른 case들도 많겠죠.!)
바로 수정하여 PR을 보낼 수도 있지만, 별도 이슈/티켓을 만들어 진행하거나 팀원들에게 문의를 해보세요.
쿠킴: '로컬 개발 환경을 구축해보았는데 어떠세요?'
쿠킴: 'API 분석 중에 문제점을 발견했는데 어떻게 진행하면 될까요?'
첫 업무
입사 후 한 달이 지나 드디어 이슈/티켓이 주어졌습니다.!
QA 이슈군요.! 어떤 작은 기능이 작동을 안 한다고 합니다.
업무를 맡게 된다면 컨텍스트 파악을 먼저 하세요.
이 일은 얼마나 급한가요?
기간은 언제까지인가요?
왜 이 문제가 발생했나요?
어떤 것을 해결해야 하나요?
혼자 할 수 있나요? 누구에게 도움을 요청해야 하나요?
비교적 간단한 쿼리 문제이군요.
코드를 수정해 봅니다.
문제 사항을 재현하여 테스트해봅니다.
문제가 없군요.!
PR을 보냅니다.
PR은 코드리뷰 해주는 사람이 편하게 이해할 수 있도록 작성합니다.
왜 이 일을 했고 어떤 문제가 있었고 어떻게 해결했는지 말이죠.
코드리뷰를 받고 수정합니다.
코드는 내가 아닙니다. 코드 리뷰에 상처받지 말아요.!
팀원의 리뷰 덕분에 오늘도 많이 배웠습니다.
QA Merge
와! 드디어 첫 머지가 되었어요!!!!
prod 반영 확인
시간이 지나 prod 배포가 되었습니다.
수정사항이 잘 적용되었을까요? 한 번 확인해 봐요
오.. prod에서도 문제없이 적용되었군요.
짝짝짝 축하드려요.! 운영 코드에 반영이 되었군요 🎉
피드백받기
팀장님이나 팀원에게 피드백을 요청하면 도움이 됩니다. 현재 내가 잘하고 있는지? 부족한 점은 어디가 있는지?
쿠킴: '팀장/팀원분들 제게 부족한 점이 있을까요? 피드백 부탁 드립니다.'
팀장: '쿠킴은 우선순위에 중요한 일보단 다른 부가적인 일을 먼저 하는 경향이 있어요. 고집 있는 것도 좋지만, 핵심을 보는 것이 중요해요.!'
팀원: '개발하기 전에 설계나 이슈/티켓에 깔린 컨텍스트를 제대로 이해하는 게 중요해요. 코딩 먼저 시작하면 불필요한 개발을 하게 되어요.'
팀원: '잘하고 있습니다.! 인턴이 아니라 중고 신입 같군요!'
덧)
피드백은 업무 하면서 중간중간받는 것이 좋습니다.
종종 혼자서 뚝딱뚝딱 연구하고 검색하고 해결하려는 마음이 들 때가 있습니다.
인턴/신입으로 입사해서 혼자서 뭔가 능력을 보여주고 싶은 마음이 가득하니까요. 🔥
하지만, 내 주변 팀원들(20년 시니어, 10년 시니어, 주니어, 2,1년 차... 등)은 이미 빠른 길을 알고 있을 수 있습니다.
혼자서 8시간 고민해서 구현하려고 하는 태도나 집념과 태도는 좋지만, 주변 팀원들에게 도움을 요청해 보는 것은 어떤가요?
잘못된 길로 가지 않고, 에너지를 올바른 곳에 집중해서 사용할 수 있습니다.
(사실 팀원들도 제가 뭘 하는지 궁금할 거예요. 피드백/질문을 한다면 일석이조 아니겠어요?)
쿠킴: '팀장님, ABC-123 이슈에 대해 문의드릴 게 있습니다. 제가 이해한 컨택스트는 00에 문제가 발생했고 00으로 해결하려고 하는데 맞을까요? 이게 맞다면 구현을 어떻게 하면 좋을까요? 현재 생각한 것은 A, B 정도 생각을 하고 있는데 더 좋은 방법이 있는지 궁금합니다. A, B 생각의 문제점도 파악이 잘 안 되기도 하고요.
팀장: '아, ABC-123 이슈는 그 컨택스트가 아니에요. 00 문제 때문이 아니라 000 문제 때문입니다. 근데 생각해 보니 꼭 코드 레벨에서 해결하지 않아도 되겠군요. 기획이나 운영에서 해결할 수 있는 문제 같아요. 다시 미팅을 잡아보죠.'
쿠킴: '구현을 하지 않아도 된다고요???! 🥹'
와 같이 말입니다.
혼자 끙끙하지 말고, 팀원들과 함께해요!
더덧) 팀원들의 집중 시간도 지켜줘야 해요. 언제 물어보는 게 편한지, 언제 물어보지 말아야 하는지(에어팟을 끼고 있다)를 사전에 정한다면 더 좋은 커뮤니케이션이 가능하겠네요.
언어는 중요하지 않다.
쿠킴: '팀장님, 자바 스프링이 하고 싶습니다. 🥲'
팀장: '쿠킴, 언어는 중요하지 않아요. 👀'
입사 전 Java/SpringBoot 를 사용했었지만 회사에서는 주로 Golang/Gin, 자체 프레임워크를 사용했고 Node.js 관련 업무도 하게 되었습니다. (Java 프로젝트도 있긴 했지만요.!)
처음엔 앗.. 내 업무는 이게 아닌 거 같은데? 란 생각도 들었지만 일을 하며 생각이 많이 바뀌게 되었습니다.
커리어 상 언어/프레임워크가 주는 어떤 방향/특징/전문성이란게 있을 수 있겠지만, 그보다는 어떤 문제를 풀고 해결하기 위한 의사결정, 아키텍처, 고민, 상황, 경험이 더 중요하다는 것을 느끼게 되었습니다.
예를 들어 구현 후 부하테스트, 배포 후 모니터링, 배포 프로세스, 장애 대처 방법(DB 커넥션 문제, 트래픽 증가, 인프라 문제,...),캐싱, 메시지 큐 사용, 재개발 방법, API 버저닝, 개발이 아닌 기획/디자인 관점으로 문제 돌리기 등 문제 해결 방법은 언어, 프레임워크와 상관이 없으니까요.
개인이 하고 싶은 일보다는 팀과 회사가 가지고 있는 문제를 해결하는 것이 중요하고, 팀/회사에 도움이 되는 일을 해야 한다는 생각도 가지게 되었어요.
마치며
인턴 백엔드 개발자로 3개월을 무사히 마치었습니다.
팀장님과 팀원들 덕분에 인턴임에도 불구하고 큰 개발 성과도 내게 되었죠.!
좋은 사람들과 함께 일할 수 있다는 것은 정말 큰 행운과 복이었습니다.
앞으로도 새로운 도전을 통해 더 나은 개발자로 성장하고, 팀과 회사에 좋은 영향력과 가치를 제공하고 싶습니다.
감사합니다.
회고 끝.
'📝 회고 > 🗓 23년 회고' 카테고리의 다른 글
| [회고] 2023년 상반기 회고 - 내가 무릎을 꿇었던 건... (4) | 2023.07.16 |
|---|---|
| [회고] 글쓰기 모임 '글또', 7기 회고와 8기 시작하며 (7) | 2023.02.11 |
댓글