세라 🍀
안녕하세요. 저는 김세빈이자 세라입니다. 세라라는 닉네임의 시초를 말씀드리자면, 사실 세라라는 닉네임은 인턴시절부터 사용했던 닉네임이에요. 퇴근을 하면 김세빈으로, 출근을 하면 세라로 살아오면서 일할 때의 나와 노트북과 함께 하지 않는 나를 분리하려고 했어요.
하지만 개발하는 시간이 더 많아지고 이전보다 흥미의 크기가 커져가면서 생각이 조금 변했어요. 개발하는게 재미있기에, 몰랐던 부분을 공부하면서 알아가는게 재미있기에, 개발자 세라와 김세빈간의 경계가 허물어지고 하나가 되가는 중입니다 ㅎ_ㅎ.
짧은 자기소개였지만, 앞으로는 어떤 이름으로 불려도 괜찮을 만큼, 개발자이자 저 자신으로서 즐겁게 성장하고 싶습니다. ㅋ.ㅋ
레벨1을 지내며 했던 고민들 💬
왜 TEST코드를 곁들여 짜라하는 걸까, TDD가 실무에서 정말 의미가 있나?
이전 프로젝트를 해오면서 가장 먼저, 가장 쉽게 버려지는 영역이 테스트라고 생각했어요. 항상 기능 개발이 끝나고 나면, 숨 돌릴 새 없이 에러를 픽스하기 바빴고 리팩토링을 진행함과 동시에 새 기능이 추가되는 사이클을 많이 경험했던 것 같아요. 또, 테스트가 없어도 프로젝트는 잘 유지되고 버그 레포트도 들어오지 않으니 테스트를 짜기보단, 시간 날때 쉬자! 하는 생각을 많이 했습니다.
따라서 제가 생각했던 테스트는 다음과 같았어요. “기능 개발이 끝난 후에 진행하고, 그것도 시간이 남으면 진행한다.”, “프론트엔드는 사용자와 많이 맞닿아 있다보니, 화이트박스 테스트가 어렵고 모든 곳이 아닌 필요한 곳에만 테스트를 작성해야 한다.”
이런 생각을 가지고 있다보니 1주차부터 유닛 테스트를 도입하고, 2주차부터는 TDD를 적용해서 구현을 진행하는 것이 잘 와닿지는 않았던 것 같아요.
실무에서도 테스트를 작성하는지 궁금했기에 주변 분들에게도 많이 물어봤던것 같습니다. 그 중 가장 와닿았던 내용 중 하나는 다음과 같았어요. (샤라웃 동환님)
기능 추가할 때나 리팩토링할때 이전에 동작하던 기능이 잘 동작할거라고 확신할 수 없잖아요? 그럴때 미리 테스트 코드를 작성하고 리팩토링하면 조금이나마 안정성을 높이니까 심리적 부담도 덜어지는 것 같아요. 회귀 테스트는 모두 QA의 일이라고 생각한다면 사실 굳이...라고 생각할 수 있지만 오너십을 가지고 같이 일하는 마음으로 하면 좋을 것 같아요.
또 문서화 측면에서도 생각보다 큰 장점이라고 생각이 드는게 회사, 혹은 팀에 처음 합류하면 제품의 크기에 따라 다르겠지만 코드의 양에 압도될 때가 많잖아요? 저도 첫 회사 갔을때 그랬고요. 그 때 테스트 코드가 있으면 팀에 녹아드는 시간이 적게 드는 것 같아요.
테스트 코드가 존재하면 안정성이 높아지고, 개발자인 제가 리팩토링을 진행할 때도 하나의 함수 변경으로 인한 리팩토링 범위를 알 수 있었기에 dx가 향상된다고 생각했어요. 하지만, 누군가 저에게 너 테스트가 꼭 필요하다 생각해? 라고 물어본다면, 아직은 그 답을 찾아가는 과정이라고 답할 것 같습니다. ㅋ_ㅋ.. 아직 경험이 많이 부족하니깐요. 해당 고민은 아직 끝나지는 않았지만, 그래도 레벨1 경험을 통해 나아가고 있는 것 같아요.
왜 우테코는 class형으로 구현하기를 권할까?
프리코스 때부터 class형으로 구현하라는 요구가 계속 나왔어요. 그런데 리액트를 사용하게 되면 결국 함수형 컴포넌트를 주로 쓰게 되는데, 왜 굳이 class형을 강조할까? 하는 궁금증이 늘 따라다녔어요.
지금 돌아보면, 그 의도가 단순히 class냐 function이냐의 구현 방식에 있던 게 아니라, 객체지향 프로그래밍의 개념을 스스로 고민해보게 하려는 것이 아니었을까 하는 생각이 들었어요. "객체 간의 역할, 책임 분리, 메시지 전달 같은 것들을 고민하며 자연스럽게 OOP의 철학에 익숙해지도록 유도한 것은 아닐까?" 하는 생각이요.
아무래도 함수로 구현하는 것보다는 class를 사용하는 편이 “이 객체는 어떤 역할을 맡고, 어떤 상태를 가지며, 어떤 방식으로 다른 객체와 소통할까?” 같은 객체지향적인 사고를 훨씬 자연스럽게 이끌어내기 때문이 아닐까? 생각이 들었어요. 처음에는 그 이유를 잘 몰랐지만, 시간이 지나고 나서야 그 배려와 방향성을 이해하게 되었어요.
뒤늦게 그 의미를 깨닫고 나니, 객체지향에 대해 좀 더 깊이 공부하고 싶다는 마음이 들었고, 그래서 최근에 객체지향의 사실과 오해라는 책을 구매해서 읽기 시작했어요. 단순히 기술을 배우는 데 그치지 않고, 프로그래밍을 바라보는 관점과 사고 방식 자체를 확장해야 겠다!고 생각했습니다.
왜 매 미션마다 생각해보라고 하지?
레벨1 LMS에서는 거의 모든 주제에 생각해보기라는 소주제가 따라붙었어요. 처음에는 가볍게 읽고 넘기는 경우가 많았는데, 방학 때 이 질문들을 다시 들여다보며 새로운 시선을 얻게 되었어요.
단순히 “궁금한 걸 공부해보라”는 말이 아니라, 해당 개념에 대해 나만의 기준이나 원칙을 세워보라는 의미가 아닐까? 하는 시선이요. 레벨2에서는 이걸 좀 더 의식적으로 실천해보고 싶어서, 생각해보기를 함께 나누는 스터디를 만들었어요. 강제성을 주되, 각자의 시선을 공유할 수 있도록요!
레벨2 목표 🚀
사실 레벨1에서는 스스로가 만든 목표가 없었어요. 단순히 js에 대해 잘 학습하자라는 두루뭉술한 목표만 있었고, 외부에서 던져준 가이드밖에 없었습니다. 하지만, 레벨2에서는 해야할 일들을 잘 리스트업해서 지켜내 보려 합니다.
1. 하루/일주일 단위로 회고하기
단순히 기술적인 성장을 넘어, 저는 제 자신과 대화하는 시간이 부족했다는 걸 느꼈어요. 저는 외부 자극에 민감하고 감정 기복이 있는 편인데, 그런 제 모습을 인정하면서 스스로에게 질문을 던지기 시작했어요.
“나는 어떤 상황에서 예민해질까?”, “무엇을 했을 때 감정이 금방 가라앉을까?”, “내가 생각하는 좋은 개발자는 어떤 사람이지?”, “나는 어떤 장점을 가졌고, 그걸 말할 수 있는 근거가 있을까?”, “내가 지향하는 팀은 무엇을 하는 팀이고 어떤 모습일까?” 같은 질문들요.
예전에는 단순히 ‘나는 눈치가 빠르고, 조직 분위기를 잘 읽고 빠르게 적응하는 사람’이라고 생각했어요. 또, 실생활에서 불편함을 느끼면 이를 금방 문제로 인식하고 빠르게 행동으로 옮긴다는 점도 제 장점이라고 여겼어요.
하지만 요즘은 이런 생각들이 너무 추상적이라는 고민이 들었어요. 그래서 그 장점들을 좀 더 깊게 들여다보고, 구체적인 근거를 붙여보려 노력 중이에요. 따라서 다음과 같은 질문들에 대해 생각해보려 노력하고 있습니다.
- ‘빠르다’는 건 누구에 비해? 어떤 상황에서?
- ‘눈치가 빠르다’는 건 정말 나만의 강점일까, 아니면 착각일까?
- ‘문제를 해결한다’는 건 너무 보편적인 말 아닌가?
- 나는 정말 사용자가 많은 회사에 가고 싶은 걸까, 아니면 그 속에서 어떤 일을 하고 싶은 걸까?
- 혹시 그 회사에서 내가 원하지 않는 일을 하게 된다면, 난 만족할 수 있을까?
이런 질문들을 매일, 혹은 일주일 단위로 회고하면서 조금씩 나 자신을 더 명확하게 알아가고 있어요. 개발 실력 못지않게, 스스로를 돌아보고 정리하는 능력이 점점 더 중요하게 느껴지고 있답니다.
올해가 끝나기 전에 개발자 세라는 어떤 사람인지 꼭 글을 쓰고 마무리하려해요!
2. 잘 이끌고, 함께하기 좋은 사람
개발 동아리 회장을 6개월 맡고, 1년간 멘토 활동을 하면서 저는 리더 역할이 제게 잘 맞는다는 걸 자연스럽게 깨달았어요. 그 과정 속에서 “감사합니다”, “역시 세라”와 같은 표현을 들을 때마다, 말로 설명할 수 없는 뿌듯함과 따뜻함을 느꼈어요.
그 경험이 너무 좋았기에 이번 우테코에서는 스터디를 직접 기획하고, 이끄미 활동에도 자발적으로 신청했어요. 제가 가진 지식이나 기술을 나누는 것도 즐겁지만, 사람과 사람이 연결되는 과정 속에서 함께 성장하는 분위기를 만드는 일이 저에겐 더 큰 의미가 있다고 생각하기 때문이죵.
이런 활동을 하다 보면 종종 이런 질문을 듣곤 해요. “굳이? 귀찮지 않아?” 그럴 때마다 저는 이렇게 대답할 것 같아요. “누군가 겪고 있을 불편함을 대신 해결해준 거 아닌가? 그럼 난 그걸로 충분히 의미 있다고 생각해.”라고요.
예를 들면, 누군가 “우리도 티셔츠 있으면 좋겠다”는 말을 툭 던졌을 때, 저는 그 말 하나로 바로 티셔츠 디자인을 시작하고, 공지를 올리고, 주문을 받아 진행했어요. 이건 단순한 옷이 아니라, 우리가 ‘함께 소속되어 있다’는 감정을 느끼게 해주고 누군가의 작지만 진심 어린 바람을 실현시킨 순간이었다고 생각해요.
생각해보면, 개발도 마찬가지인 것 같아요. 사람들이 실생활에서 어떤 불편을 겪고 있을지 먼저 떠올리고, 보이지 않아도 좋을 그런 ‘굳이’ 같은 디테일들을 기꺼이 챙기고, 그걸 기꺼이 해내는 사람이 결국 세상을 조금씩 더 나은 방향으로 바꾸는 사람이 아닐까 생각합니다.
그리고 저는 그 순간들로부터 책임감을 느끼고, 누군가의 말 한마디가 제 삶의 원동력이 되곤 한답니다. 단순히 무언가를 ‘이끄는 사람’이라기보단, 함께할 수 있게 돕는 사람, 그리고 그 과정을 진심으로 좋아하는 사람이 되고 싶습니다! 따라서 이번 레벨에서도 함께하기 좋은 사람이 되기 위해 노력하려고 해요.
3. 나만의 공식 노트 만들기
그동안 저는 실제로 부딪히면서 배우는 방식이 가장 잘 맞는 공부 방법이라고 생각했어요. 리액트를 처음 배울 때도 일단 직접 만들어보고, 문제 상황을 마주한 뒤 “이걸 어떻게 해결하지?” 고민하면서 자연스럽게 학습해나갔던 것 같아요. 이런 경험 중심의 학습은 정말 큰 도움이 되었지만, 이번에는 조금 다른 방식으로 접근해보려 합니다!
공식 문서를 천천히 읽고, 그 속에서 스스로 기준을 정하며 정리하는 공부를 해보려 해요! 예를 들면, “나는 어떤 기준으로 컴포넌트를 분리하지?”, “어떤 상황에서 useEffect를 쓰는 게 적절할까?” 같은 질문에 나만의 원칙과 기준을 적어가며 공식 노트를 만들어보려고 합니다.
저만의 노트는 단순한 기록을 넘어, 앞으로 제가 선택하고 판단할 때 기준이 되어줄 나만의 개발 철학이 될 수 있지 않을까 기대하고 있어요. 이번 우테코에서는 이 공식 노트를 채워가며, 더 나다운 개발자로 성장해보고 싶습니다!
마치며, 초본은 저번주 주말에 완성했는데 쓰고 지우고를 반복하다 너무 늦게 올려버렸네요. 레벨2 화이팅..
역시 세라