일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 프로젝트설정
- n poem
- Java
- cannot import name
- 객체비교
- 토이프로젝트
- 쿼리셋합치기
- API문서화
- GraphQL
- Spring
- Npoem
- 함수형프로그래밍
- 컨트리뷰팅
- bean-validator
- circular dependency
- IOC
- bulk_create
- django
- DI
- 주니어개발자
- resilience4j
- 상속모델
- 운영체제
- 2차원배열 정렬
- 마이크로서비스패턴
- 좋은코드란
- SpringBoot
- Not Null constraint failed
- circuitbreaker
- 일급함수
- Today
- Total
코딩 하는 가든
[생각 정리] 학생 개발자의 6개월 개발 인턴 회고 본문
지난 6개월을 돌아보며...
본인은 컴퓨터 공학부의 4학년 학부생으로 이번 1학기를 인턴으로 대체하여 개발을 해왔습니다. 소셜 커뮤니티를 운영하는 스타트업의 백엔드 개발 포지션으로 근무를 하였으며 Django, DRF를 기반으로 한 서비스 API 제작부터 클라우드 서비스를 활용한 운영, 컨테이너 배포까지 다양한 경험을 해보았습니다. 학부 과정만으로는 접하기 힘든 기술들을 많이 접해볼 수 있는 좋은 기회였기도 하고 6개월은 이 모든 걸 익히기엔 부족한 시간이라 아쉬움이 남기도 합니다. 지난 6개월을 돌이켜보며 느꼈던 점을 간략히 적어보고자 합니다.
성장은 가진 권한의 크기 만큼
(스타트업 인턴의 장점)
제가 있던 곳은 저를 포함해 3명의 백엔드 개발자가 있었습니다. 한때는 두 명이서 백엔드 개발을 할 때도 있었습니다. 당시는 하필 리뉴얼 프로젝트를 통해 서비스를 전반적으로 갈아엎고 난 뒤였습니다. 요구사항은 물밀듯 쏟아져 나왔고 저는 수개월 짜리 인턴이었지만 그에 비해 큰 기능의 구현과 그에 따른 의사 결정을 해야 했습니다. 다이렉트로 기획팀과 소통을 하며 새로운 기능 개발 및 기능 개선을 수행하기도 하였습니다. 물론 완전히 혼자 결정한 것은 아니었고 최종 결정은 매주 있던 개발 회의에서 사내 모든 개발자들이 모여 (4명 정도이지만...) 최종 컨펌을 받았습니다. 이 과정에서 더 좋은 방향으로 나아갈 수 있는 가이드를 해주신 훌륭한 사수분이 있었다는 것도 큰 행운이었습니다. 제가 잘못된 결정을 하더라도 ' 이 방법은 ~~ 하지만 ~~ 단점이 있고, 다른 방법은 그것을 어떻게 해결할 수 있다.'라는 어떤 의사의 문제점과 대안을 잘 설명해 주셨고, 이런 과정 속에서 '어떤 방향으로 설계를 해야 더 좋은 설계일까?'라는 고민을 수도 없이 할 수 있었습니다. 이런 스스로 하는 고민의 시간들이 모두 성장의 밑거름이 될 수 있던 것 같습니다. 이런 경험은 아마 운 좋게도 제가 있던 곳이 개발 문화가 잘 갖추어진 스타트업이었기 때문에 했던 것일지도 모르겠습니다.
또한 프로덕트의 소스코드를 바로 직접 들여다볼 수 있다는 것도 큰 장점이었습니다. 어떤 분야든 가장 빠르게 익힐 수 있는 방법은 실제 업무를 경험해 보는 것이라고 생각합니다. 하지만 아마 대부분의 큰 기업들은 보안상의 이슈로 실제 소스코드를 인턴에게 공개하지 않는 곳도 많을 것입니다. 저는 업무를 하며 실제 완성된 서비스의 코드를 다룰 수 있었으며, 운영하는 인프라의 구성까지 모두 알 수 있었고 이렇게 습득한 지식이 저의 성장에 큰 도움이 되었다고 생각합니다.
위의 경험은 아마 제가 꾸준히 학교를 다녔다면 해보지 못했을 경험들이었을 것입니다.
가장 좋은 테스트 도구는 나 자신
(개인적으로 느꼈던 것)
코드 한 줄을 추가 하더라도 그 코드에 대해서는 내가 가장 잘 알고 있어야 합니다. 해당 코드의 (1)성능과 (2)동작 원리는 물론이고 (3)확장성에 대한 고려뿐만 아니라 (4)해당 코드를 추가함으로써 발생할 수 있는 사이드 이펙트까지 제어를 할 줄 알아야 합니다. 실제로 제가 변경한 코드 한 줄 때문에 서버가 터져버린 적이 있었습니다. ( 변명을 해보자면 지금은 테스트 코드가 있지만 5개월 전만 해도 테스트 코드가 없었던 상황...) 물론 테스트 코드가 있었더라면 어느 정도 방지할 수 있는 상황이었지만 내 코드에서 위 언급한 네 가지를 확실하게 설명할 수 없다면 한번 더 의심해봐야 할 코드라고 생각합니다. 개발에 있어 테스트는 신뢰할 수 있는 서비스를 만들기 위한 기본 중의 기본입니다. 물론 테스트 코드라는 좋은 도구가 있지만 이 테스트 코드는 나의 생각(코드)의 신뢰성을 높여주기 위한 도구이지 완벽한 코드의 보장은 아니라고 생각합니다. 특히나 위에 언급한 1, 3번은 테스트 코드(유닛 테스트에서,,,)로 검증할 수 없으며 상황에 따라 1번, 성능에 의해서는 크리티컬 한 이슈가 발생할 수도 있습니다. 따라서 코드를 작성하기 전, 테스트를 돌리기 전 스스로의 충분한 검증이 있어야 합니다.
기본기를 탄탄히
(개인적으로 아쉬웠던 것)
회사에 대한 아쉬움이 아니라 근무 기간 동안 스스로에 대해 아쉬웠던 것에 대한 글입니다.
개발 회의 시간에 개발자들과 개발자에게 가장 중요한 것이 무엇인가에 대한 토론을 한 적이 있었습니다. 소통, 클린 코드 등 여러 의견이 나오던 중 듣고 계시던 리드 개발자 분이 '당연히 나올 줄 알았는데 꾸준한 학습이 안 나와서 놀랐다'라고 하셨습니다. 사실 꾸준히 스스로 공부를 해오긴 했지만 '학습'이라는 단어가 팀에서 가장 개발을 잘하는 분의 입에서 나왔다는 게 다시 한번 제 자신을 돌아보게 했습니다.
사실 이 주제는 제가 했던 약간은 잘못된(?) 학습법에 대한 회고입니다. 저는 인턴 근무를 시작하며 막상 서비스를 만드는 것이 재미있다 보니 프레임워크나 기타 라이브러리에 대한 위주의 공부를 했었습니다. 저는 회사에서는 Django를 이용해 개발해 왔지만 추후 Spring 개발이 하고 싶었기 때문에 퇴근 후 간간히 Spring 공부를 해왔습니다. 혼자 SpringBoot로 원하는 API를 만들어 왔고 graphql 같은 재미있는 기술이 있으면 적용해 보고는 했습니다.
저는 포트폴리오를 위한 기술 공부에 급급한 나머지 그보다 더 중요한 CS지식이나 언어 그 자체에 대한 공부를 등한시 보았던 것 같습니다. 하지만 이러한 기술 중심의 학습법은 어딘가 엉성하고 빈틈 투성이었습니다. 얼마 전 우연히 java 기본에 대한 질문을 받았고 잘 대답을 하지 못했습니다.. ( 변명 ) 그것의 개념 자체를 몰랐던 건 아니지만 용어가 생각이 안 나서 대답을 못했습니다.. ) 당연한 말이지만 어떤 개념에 대해 내가 이것을 다른 사람에게 설명할 수 없다면 완전히 아는 것이 아니라고 생각합니다. 프레임워크나 업무 전반에 대한 대답은 충분히 할 수 있지만 기본에 대한 답변을 못했다는 것에 부끄러움을 느꼈습니다.
특히나 저 같은 주니어 시절에는 기초가 굉장히 중요합니다. 어딘가의 면접에 가더라도 주니어에게는 기본기에 대한 질문을 가장 많이 할 것입니다. 어찌 보면 저는, 학생이지만 실무를 한다고, 기본은 할 줄 안다는 자만심이 생겼던 것 일지도 모르겠습니다. 그래서 저는 지난 인턴 회사에서의 연장 제의를 거절하고 이번 4학년의 여름 방학을 지금껏 배워왔던 cs지식과 언어 기본을 복습하며 부족한 부분을 메워 나갈 생각입니다. 이번 여름이 지나면 제가 어딘가 엉성한 주니어 개발자가 아니라 기본은 할 줄 아는 주니어 개발자가 돼 있기를 바라며 글을 마칩니다.
'주저리주저리' 카테고리의 다른 글
코알못이 개발자가 되기 까지 - (3) (9) | 2020.12.29 |
---|---|
코알못이 개발자가 되기 까지 - (2) (2) | 2020.12.29 |
코알못이 개발자가 되기 까지 - (1) (17) | 2020.12.29 |
[생각 정리] 좋은 코드란 (2) | 2020.04.22 |
블로그를 시작하며... (1) | 2020.03.09 |