22년 9월 ~ 12월 인턴을 마치고,
인턴을 진행했던 회사에서 23년 2월 6일 정규직으로 입사를 했다.
입사한지 1년이 된 시점에 지난 1년을 되돌아보고 앞으로는 어떻게 지낼지 생각해보기 위해 회고를 작성한다!
인턴을 했던 회사에 입사를 결정한 이유?
대학교 마지막 학기에 4개월동안 재직중인 회사에서 인턴을 진행했다.
인턴을 마치고나서 정규직 제안을 받았고 마지막 학기에 인턴을 하느라 제대로 취업준비를 해보지 않은 상태에서
입사를 할지, 취준을 해볼지 정말 고민을 많이했다.
물론 서비스의 도메인에도 관심이 있었고, 입사 전 생각해본 적은 없지만 saas 플랫폼이 겪는 챌린지 요소들도 재미있었다. 그리고 같이 일하는 팀원분들도 좋았다.
그런데 결정적인 이유는 감사하게도 인턴을 하며 동료분들께서 주신 나에대한 신뢰가 절망의 계곡을 극복하는 데에 도움이 될 수 있을 것 같다는 생각이었다.
대학생때 이미 뛰어난 친구들과 같이 개발 공부를 하고 프로젝트를 진행하며 내 개발 실력에 대해서 스스로 신뢰하지 못했고 자신감도 낮은 상태였다.
인턴기간 동안에도 잘 하고 있는가에 대해 계속 의심했는데, 이런 상태는 내가 공부하고 앞으로 나아가는 데에도 안좋은 영향을 준다고 생각했다. 짧은 기간이었지만 인턴을 마무리할 때 여러차례 미팅을 진행하며 팀에서 주신 긍정적인 피드백들을 받고 난 뒤에
팀에서 신뢰를 쌓으며 수행하는 업무들에 대해 피드백을 주고받을 수 있는 환경에서 일하면 개발 실력과 함께 자신감도 얻을 수 있겠다는 생각이 들어서 입사를 결정했다.
1년 동안 해낸 일
1) 업무에 적응하기
2) 문서화 호소인
3) 사내 독서 스터디
1년 동안 일하며 느낀 것
👩💻 취업 전에 막연히 상상하던 백엔드 개발자의 업무와 역할들을 알게되었다.
취업 전에 혼자 이런 생각을 한 적이 있다.
이미 개발이 완료되어서 시장에 릴리즈가 된 제품을 만드는 회사의 개발팀은 무슨일을 하지..?
신규 프로젝트가 아니더라도, 이미 (잘) 돌아가고있는 프로덕트의 유지보수 및 개선 업무는 생각보다 매우 큰..
어쩌면 업무의 거의 대부분을 차지한다는 것을 알게되었다.
- 기능을 개발할 당시에 고려하지 못했던 엣지 케이스가 운영 중에 발생하거나
- 프로덕트에 새로운 기능들을 붙이며 side-effect로 다른 부분에 영향을 주는 경우
- 트래픽이나 데이터의 양이 늘어나 초기의 스펙이 감당하지 못하는 경우
등 웹서비스에는 아주 많은 버그들이 있다는 것을 체감할 수 있었다.
그리고 역시 새로운 기능을 개발할 때보다 잘 몰랐던 서비스 부분들의 버그리포트에 대응하면서 서비스와도 많이 친해졌다.
그리고 운영상 필요한 데이터 추출, 변경되는 스펙에 따른 데이터 마이그레이션 등 비즈니스 로직 상에서는 벗어나 데이터를 다루는 업무들이나 버그상황에 대응을 하면서, 데이터 구조 설계를 할 때 더 신중히 다양한 상황들을 고려하게 된 것 같다.
그 외에도 모바일 앱이 있는 서비스라면 하위호환을 더욱 고민해야한다는 것, 기획 사항을 보고 현재 기술적으로 가능한 범위 내에서 조율 하는 커뮤니케이션을 하는 방법 등 지금 보면 당연하고 사소하지만 회사에서 일해보기 전에는 몰랐던 백엔드 개발자라는 직군이 하는 일들을 배우는 기간이었다고 생각한다!
🏃♀️ 빠르게 실패하고 빠르게 고친다는 것
프로덕트 개발을 할 때 발산한 모든 아이디어를 구현하느라 배포 날짜를 연기하는 것이 아니라,
<릴리즈를 위해 반드시 구현해야 하는 범위>에 집중해 빠르게 배포하고 고객과 시장의 니즈를 충족하는 방향을 점진적으로 찾아가는 과정을 경험해보게 되었다.
취업 전에도 애자일하게 일한다는 것, MVP를 뽑아내는 것, 빠르게 실패하고 빠르게 고치라는 것 등 소프트웨어 서비스를 성공적으로 이끌기 위해 빠른 호흡으로 짧은 테스트와 피드백 주기를 갖는 방식에 대해서는 익히 들어왔다.
그런데 대학생 때 2년동안 열심히 개발했지만 졸업할 때까지도 "완성"시키지 못한 프로젝트의 경험을 돌이켜보면 A라는 기능이 가져야하는 모든 세부 기능과 기획 사항 및 시나리오를 한번에 모두 구현해야만 기능으로써 배포할 수 있다는 생각을 가지고 기획하고 개발했던 것 같다. 그래서 그 많은 기능과 화면들을 모두 개발한 후에 서비스를 배포 하려고 하다가, 졸업때까지 정식 배포를 하지 못했다 ㅎㅎ
스타트업에서 짧은 호흡의 프로젝트들을 경험하면서, 범위를 끊어서 개발을 진행해나가는 과정과 MVP를 선정하는 과정들을 배울 수 있었다. 그리고 워킹하는 기능의 개선 기회는 빠르게 주어지지만 그렇지 않은 기능들은 개선의 기회도 오지 않을 수 있다는 것(그럼 거지같이 작성했던 코드도 리팩토링 할 기회가 주워지지 않는다..)을 깨달으며... 일부 범위라도 빠르게 시장에 선보이는 것의 중요성을 느끼기도 했다.
🐥 비개발 팀과의 커뮤니케이션
입사를 하고 아주 초기에는 개발팀이 아닌 팀원분들과의 소통을 어떻게 해야하는가의 고민을 많이 했던 것 같다.
버그 상황이 발생했고 그것을 해결하는 과정에서 문제 원인에 대해 설명할 때, 기술적으로 구현이 어려운 기획 사항에 대해 논의를 드릴 때 어떤 용어들을 사용하고 어느 정도의 깊이까지 이야기해야할까?가 가장 어려웠다.
내가 너무 기술적인 내용까지 설명하며(메모리가 어쩌고.. 트랜잭션이 어쩌고..) 비효율적인 커뮤니케이션을 할 때도 있었고, 다른 개발자분께서 기술적인 어려움에 대해 PM분께 설명하시다가 기획 사항이 기술적으로 구현하기 용이한 정도로 수정되는 것을 본 적도 있었다.
- 개발자가 편한 범위로 기획이 좁혀지거나 변경되지는 않도록 하기
- 고객사에 커뮤니케이션 하거나 유저 플로우를 그릴 때 PM/디자이너 입장에서 알아야하는 범위
- 문제 상황을 이해하기 위한 효율적인 커뮤니케이션
이런 요소들을 생각하며 소통하려고 노력하고 있지만, 여전히 어려운 것 같다.
💭 나는 모호한 상황을 즐기는 사람인가에 대한 고민
함께 자라기라는 책에서 학습이 빠른 팀의 팀원에 대해 이렇게 설명하는 부분이 있다.
- 단순 업무 수행 능력뿐만 아니라 얼마나 협력을 잘 하는지
- 새롭고 애매모호한 상황을 즐기는지
- 자기보다 높은 지위의 사람에게도 자신있게 의견을 제안할 수 있는지
여기에서 나는 특히 두번째의 <새롭고 애매모호한 상황을 즐기는가> 에서 고민이 많아졌다.
항상 명확한 답과 그 답으로 가는 길이 정해져있는 과목들만 공부해왔는데, 스타트업에 들어와 정답이 없는 문제들에 대해 고민하고
이것도 맞고 저것도 맞는 것 같은 상황에서 쪼랩인 내가 의사결정을 해야하는 상황들에 직면하면서 한창 스트레스를 많이 받고 있었다.
특히 이런 상황에 한명의 개발 팀원으로써 적절한 결정을 내리지 못하고 우왕좌왕하는 나를 보며 나 개발자랑 안맞는걸까..? 이런 생각들을 하던 차에 책을 읽고 고민이 많아진 것이다.
그러다가 유저 행동을 트래킹하는 로깅 데이터를 수집하는 기능 개발을 맡게되었다. 이 데이터를 어디에 활용할지 조차 정해지지 않은 상황에서 많은 논의를 거쳐 마침내 활용 방안을 정하고 데이터 설계를 명확히 하게 되었을 때, "아! 모호한 상황을 즐긴다는 것이, 모호한 상황을 점차 구체화 시켜가는 과정을 즐긴다는 의미도 되지 않을까?" 라는 생각이 들었고 속이 시원해졌다. 이 경험 덕분에 모호한 상황 자체는 힘들지만 그 상황을 여러 사람들과 논의하고 그때그때 적절한 의사결정을 하며 구체적인 상황으로 풀어나가는 과정의 즐거움을 알 수 있었다.
📍 선택과 집중
한동안, 2개 이상의 목적 조직에 소속된 상태로 기능 개발 + 버그 리포트 + 새로오신 개발팀원분들 이 상황들이 겹쳐 일이 몰린 기간이 있었다.
올해의 목표
- 테스트 코드 작성하기
- AWS SAA 자격증 취득
- 책 읽기
- 운동하기
- 기록하기
'Notation > 회고' 카테고리의 다른 글
| [인프콘 후기] INFCON 2024 (0) | 2024.08.03 |
|---|
