1. 어떻게 해당 기업에서 일하게 되었는가
나는 22년도에 약 8개월 동안 중소기업에서 프론트엔드 개발자로 일한 적이 있다. 학교에서 진행하는 현장실습 프로그램이 있는데 지원을 하게 되었고 운이 좋게 합격되어 일하게 되었다.
2. 들어가기 전 느낀 점
처음에 합격했을 때는 무척이나 기뻤다. 그냥 이력서 경험사항에 한 줄 채울 수 있게 되었구나 라는 생각에 기뻤던 것 같다. 인턴으로 일하는 것이기 때문에 내가 코드를 짤 일은 없겠지? 라는 생각으로 들어가게 되었는데 알고보니 기업의 모든 개발자가 나와 같은 대학생들이었고, 그렇기 때문에 나도 내가 맡은 바를 다 해야했다. 그 당시 리액트에 대한 경험이 전무했던 코드 한줄 짜는 것도 어려웠지만 내가 맡은 바를 다해야했기 때문에 밤새서 공부하며 코드를 짰었던 것 같다.
3. 8개월 동안 느낀 점
초반 3개월 동안의 성장은 매우 컸던 것 같다. 코드 한 줄 못치던 내가 스스로 코드를 칠 수 있게 되었다는 것이 가장 큰 성장이라고 할 수 있다. 하지만 되돌아 보았을 때 아쉬운 것이 너무 많다.
1) 사수가 없다는 것
우리는 모두 대학생으로 이루어져있었기 때문에 어떤 식으로 코드를 짜야 더 깔끔하고 가독성이 있게 짤 수 있는 지 고민이 많았다. 우리 모두 코드 질 개선을 위해 코드 리뷰를 하고 기술 스터디도 진행해 보았지만, 조금 더 경력있는 개발자가 회사에 있거나 경력자가 짜놓은 코드가 있었다면 우리가 고민이 많을 때 '이런식으로 짜면 안된다.' 라든지 '이런식으로 짜면 좋을 것 같다'라든지 알려줄 수 있었을텐데 라는 아쉬움이 든다.
2) 컨벤션을 정확히 정하지 않았는 것
우리 나름의 컨벤션을 정하기 위해 노력을 했지만 완전히 준수하지는 못한 것 같다. 코딩 컨벤션에 대해 문서로 정리를 해놓고 그 문서를 따랐으면 조금 더 통일성있게 코드를 짤 수 있었을 것 같다. 특히 당시에는 eslint의 존재를 아예 몰랐고, node 버전도 맞춰야한다는 사실을 몰랐다.
3) 문서화를 하지 못한 점
개발을 하면서 굉장히 많은 어려움을 겪었는데 그 점에 대해서 문서화를 아예 하지 못했던 점이 아쉽다. 그저 주어진 마감기한에 맞춰 개발을 하는데 급급하여 문서화를 하지 못해 현재 남아있는 것이 그 당시 코드 밖에 없다. 조금만 시간 내서 블로그에 작성했다면 나에게 큰 자산이 되었을 텐데 굉장히 아쉽다.
4) 코드를 칠 줄 알게 되니 더 이상으로 공부하지 않게된 것
말 그대로다. 코드를 칠 줄 알게 되어 기고만장해져서 더 이상 공부를 하지 않게 되었다. 더러운 스파게티 코드를 짜고서도 돌아가니깐 됐겠지라는 생각을 갖게 되었다. 더 이상 유지보수나
4. 여러 직무 팀원들과 소통할 때 나만의 꿀팁
8개월 간 일하며 되돌아 보았을 때 아쉬운 점도 많았지만, 나만의 강점은 여러 직무의 팀원들과 소통해 본 경험이 있다는 것이다. 나는 백엔드/프론트엔드 개발자, 디자이너와 모두 일해 본 경험이 있고 그 과정 속에서 얻은 것이 있다.
1) 백엔드 팀원과 작업할 때
일단 백엔드 팀원과 소통할 때는 api 통신에 문제가 생겼을 때 얘기를 많이 하는 것 같다. 처음 내가 예상한 것과 같이 응답이 오지 않을 때 내 코드에는 문제가 없는데? 이건 백프로 백엔드 문제다라고 생각할 때가 많았다. 그래서 내 문제인지 백엔드의 문제인지 확인하지 않고 바로 백엔드 팀원에게 가서 이 api에 문제가 있는 것 같다라고 말할 때가 많았다. 어쩌면 이렇게 말할 수 있었던 이유는 우리는 모두 대학생 개발자이고 정말 친했기 때문에 가능했을지도 모른다.
- 만약에 api가 안될 때 내가 제대로 요청 코드를 작성했는지 확인을 해야한다. 토큰이 필요한 api라면 토큰이 제대로 들어갔는지, request body에 데이터가 제대로 들어갔는지, api 주소는 제대로 입력했는지 등에 대해 확실하게 확인을 해야한다. 특히 오타를 주의해야한다. 백엔드요청을 보낼 때는 카멜케이스로 보내야하는데 케밥케이스로 보냈다든지
API 스펙을 잘 봐야한다는 것을 명심하자 - 개발자 도구에
Network Tab을 확인하는 것이 좋다. console로 찍는 것보다 Network Tab을 열어서 Header나 body에 필요한 것이 잘 들어갔는지 확인해야한다. - 정말 다 확인했는데도 안될 때는
이거 안되는데요?이렇게 말하지 말아야한다.설명을 잘하는 것도 굉장히 중요하다.나는 말을 잘 못하는 편이라서 처음에 팀원들과 말할 때 내 얘기를 못알아듣겠다는 경우가 종종 있었다. 그래서 팀원분께 가기전에어떤 API가 안되고, 이런식으로 요청을 보냈고, 이런식으로 응답이 왔다. 이런식으로 해결해봤는데도 안된다.라는 것을 정갈하게 정리해서 말씀드려야한다는 것을 알게 되었고 그런식으로 말씀 드렸을 때 문제 해결 속도가 높아졌다.
2) 프론트엔드 팀원과 작업할 때
프론트엔드 팀원과 작업할 때 중요한 것은 많은 것이 있지만 깃과 깃허브를 잘 쓰는 것이 굉장히 중요한 것 같다.
- commit message 상세하게 쓰기
- 푸쉬하기 전에 pull 받기
merge conflict나면 conflict난 당사자와 꼭 같이 해결하기 (내 마음대로 코드를 지워버리면 절대 안된다)- 자주 push하고 pull 받기 등이 있다. (자주 push하고 pull받는 것만으로 충돌횟수를 줄일 수 있다)
3) 디자이너와 작업할 때
마지막으로 디자이너와 작업할 때이다.
- 첫번째는
하드코딩을 하지 말자이다. 디자이너님이 주신 시안대로 글씨 크기를 맞췄는데 글씨 크기가 전체적으로 작은 것 같다고 2px씩 키워달라고 요구를 받은 적이 있었다. 그런데 내가 글씨 크기를 변수로 빼지 않고 하드 코딩해서 모든 font size를 찾아 수정해야 했던 적이 있었다. 그래서하드 코딩하지 않고CSS 변수로 꼭 빼서 코딩하는 것을 추천한다. - 두 번째로
내 마음대로 디자인을 상상하지 말자라는 것이다. 예를 들면 소셜네트워크 웹사이트를 만든다고 치면 웹사이트에 글이 없을 때는 어떤 식으로 디자인 될 지 디자인 시안에 없다면 디자이너님에게 직접 여쭤봐야한다. 내 마음대로 이런식으로 코딩하면 되겠지라고 생각하고 코딩했다가 싹 다 엎어야 했던 적이 있다.
이상으로 글을 마치며 작년에 다녔던 회사에서 느꼈던 점을 올해들어서야 쓰게 되었다. 조금 더 빨리 썼으면 더 많은 기억을 살려 잘 쓸 수 있었을 까 하는 아쉬움이 들지만 늦기전에 써보았다.
추후에 내가 다른 회사에 취업하여 읽어보면 팀원들과 더 좋은 서비스를 만들 수 있지 않을까 싶다.
