들어가기에 앞서
우연히 당근에서 인턴으로 일하시는 분의
라는 제목의 글을 보게 되었고 이에 대한 저의 생각정리와 그 생각에 대한 실천을 해보려고 합니다.
당근 개발자 인턴 성장기 글 리뷰
우선 쉬운 이해를 돕기 위해 위 글의 목차를 가져와 볼게요.
📝 꼼꼼할수록 빨라지는 개발 속도
- Todo 리스트 후다닥 만들기
- 그로 인한 문제들
- 테크 스펙 작성
🔎 사람을 믿지 말고 데이터로 검증하자
- 배포 이전 프로젝트 QA 검증
- 객관적인 감시자, 테스트코드
- 테스트 케이스 구체화, 시나리오 작성
- 모니터링
✨ 성장을 위한 원동력, 회고하기
- 장애 일지, 장애 회고
- 나만의 5 ways 를 만들기
- 파트 회고를 Good/Bad/Start/Stop 4가지 항목으로 작성
- 실수 반복을 피하기 위한 메모 작성
어떤가요 ? 대략적으로 글의 내용에 감이 오실까요 ?
그럼 아래에서 제가 블로그를 보고 느낀 생각들과 앞으로 나는 어떻게 해야할지 액션들을 작성해보도록 할게요.
📝 꼼꼼할수록 빨라지는 개발 속도
- 테크 스펙
블로그의 작성자님인 우디님께서 개발 프로젝트를 할당받고 일정을 혹여 맞추지 못할까봐 빠르게 To do 리스트를 작성하셨습니다. 하지만 이는 좋지 못한 선택이었음을 깨달았습니다. 그 이유는 무엇을 해야하는가에 대한 계획만 세우고 그 TO DO를 어떻게 구현할 것인가에 대한 고민이 부족 했다고 해요.
저는 이것을 알고리즘 문제를 풀때와 비슷하다고 느껴졌어요.
알고리즘 문제를 풀때에는 문제가 제시가 되어요.
그 문제를 보고서는 잠시 고민 후 바로 코드를 작성하는 사람이 있는가 하면 고민을 하고 엣지케이스를 작성한 뒤 sudo 코드를 먼저 작성한 뒤 본격적으로 코드를 작성하는 사람이 있어요.
물론 "00 방법이 정답이야!" 라는 건 없지만 알고리즘 문제를 풀때 저는 적당한 고민 뒤 코드를 작성하는 것이 많이 도움이 되었어요.
큰 개발 프로젝트라고 이 부분이 다를까? 라고 생각했어요. 알고리즘 문제들도 똑같이 해결하고자 하는 문제이며 그 크기와 해결 범위만 다르지 않을까 ? 라고 생각이 되었어요.
우디님께서는 이 포인트를 아래와 같이 정확하게 짚어주셨어요.
문제를 파악하고 해결방법을 찾아 나섰는데요. 이때 테스 스펙 문서와 미팅을 활용하셨어요.
스펙 문서를 작성할때에는 아래 템플릿을 통해 작성해보며 기능 개발 시작 전 동료들과 함께 구현 방향에 대해 고민해보는 시간을 가졌다고 해요.
이 테크 스펙 문서를 통해 동료들과 소통하며 전달하고자 하는 내용을 명확하게 함으로써 장점이 많을 거라 생각이 되었어요.
이 테크 스펙을 백분 활용하기 위해서는 많은 고민들과 명확한 목표의식이 있어야 한다고 생각해요.
위 템플릿을 자세히 보면
요약, 배경, 목표, 목표가 아닌것
위 4가지가 가장 먼저 선두에 있는 것을 알 수 있어요. 이러한 이유는 이 테크 스펙을 읽는 독자들의 쉬운 이해를 위해 작성되는 내용들이에요.
그리고 난 다음 개발을 위한 세부적인 모든 내용이 존재해요.
앞에 있는 4가지를 통해 "아 얘가 이러한 내용들을 목표로 개발하려고 하는구나, 그럼 이러한 고민들을 했을까? 어떤 부분들을 고려했을까?" 라는 생각을 세부적인 내용을 보기 전에 미리 할 수 있게 됩니다. 그래서 세부적인 내용을 보았을때에는 더욱 잘 이해가 되는 것을 기대할거에요.
세부적인 모든 내용에는 기술적, 엔지니어링적으로 어떻게 접근을 하고 고민을 하였는지 상세하게 목록화하여 적어요. 예를 들어 프로젝트가 서로 어떻게 상호작용하는지, 그림 혹은 다이어그램을 포함하여 작성하거나, 시퀀스 다이어그램 혹은 API 간의 데이터 흐름을 적어보아요.
혹은 로우레벨까지 다루고 있다면 HTTP 응답코드, JSON 요청 등 에러 명세까지 모두 다뤄져야 해요.
테크 스펙은 정말 잘 활용될 수 있다고 생각되요.
- 나의 생각을 정리할 수 있다.
- 동료들의 도움을 적극적으로 받을 수 있다.
하지만 너무 많은 시간을 문서화에 쏟게 되면 시간을 개발에 쏟지 못하기 때문에 그 깊이의 조절도 잘 해야한다고 생각해요.
그래서 저는 지금 수행하고 있는 프로젝트에 대해 테크 스펙을 작성해보고 팀원분들과 서로 소통하며 피드백을 받아보며 개선해나가려고 합니다.
🔎 사람을 믿지 말고 데이터로 검증하자
테스트 코드
이 파트에서는 배포를 하기 전 QA 과정이 필요한 이유와 관련하여 테스트 코드의 중요성에 대해 설명을 해주셨어요.
수십명의 개발자가 함께 협업한 코드에 기능을 디벨롭하여 추가한 뒤에는 필수적으로 테스트 코드를 통해 확인을 해야하며 이로써 얻을 수 있는 장점들은 정말로 많다는 사실을 알 고 있지만 다시 한 번 강조해주셨습니다.
테스트 코드를 작성할때 무작정 작성하는 것이 아닌 테스트 시나리오를 작성해보며 성공과 실패로 나누어 케이스를 구체화 하는 과정이 정말 중요하다고 설명하셨어요.
테스트 케이스를 구체화할때에는 비즈니스 로직과 관련하여 반례들을 적고 엣지 케이스에 대해서도 고민을 해봐야 해요. 예를 들어 time out 이나, 코드 내부적인 요인들에 대해서 말이에요.
모니터링
모니터링을 경험하며 어떻게 에러를 해결해 나가는지 알 수 있었어요.
먼저 예외에 대한 알림을 슬랙으로 받아보며 어떤 예외처리가 발생하였는지 즉각적으로 알 수 있었어요. 그리고 여러 모니터링 툴을 통해 운영되고 있는 소프트웨어가 어떤 부분에서 이상현상을 발생시키고 있는지 확인할 수 있었어요.
우디님의 에러 사항의 원인는 코루틴이었으며 timeout이 특정 부분에서 발생하여 자동으로 요청이 cancel 되지 않았고 리소스 점유율이 높아지는 현상이 발생했다고 해요.
이러한 부분을 파악하고 해결하기 위해서는 모니터링 도구를 잘 활용할 줄 알아야 하고 각 표시 사항들이 어떤것들을 의미하는지를 알아야 대처할 수 있다고 생각했어요.
✨ 성장을 위한 원동력, 회고하기
- 나만의 5 ways 를 만들기
- 파트 회고를 Good/Bad/Start/Stop 4가지 항목으로 작성
장애를 마주했을때 5ways를 통해 하나하나 되짚으며 장애 핵심 원인을 찾아가는 과정을 가졌어요.
여기서 5ways 를 통해 저만의 장애 원인을 찾고 팀원들과 공유해보며 정리하는 시간을 가져요.
그리고 파트 회고 시간을 통해 Good/Bad/Start/Stop 4가지 항목들을 작성해가며 팀워크를 높였다고 해요.
앞으로의 나의 액션은 ?
우디님께서 공유해주신 내용들을 바탕으로 저도 앞으로 위 3가지 사항들을 적용시켜보고 습득해보려고 합니다. (그러기 위해서는 많이 공부하고 .. 시간을 들여야겠지만요)
아주 간접적으로나마 대기업 인턴 개발자의 삶을 엿볼 수 있어서, 그리고 그 내용들을 적용시켜볼 수 있는 기회가 찾아온 것 같습니다.
앞으로 시간이 걸려도 명확한 목표와 꾸준히 앞으로 달려나가보겠습니다.
(4/5일 수정)
아래와 같이 테크 스펙을 작성하여 진행할 예정입니다.
