개발자
저는 2년차 프론트엔드 개발자로, 스타트업에서 일하고 있는데요. 기능 개발 일정을 맞추느라 더 좋은 코드를 고민하거나 적용하지 못하고, 당장 돌아가는 코드를 짜기에 급급한 상황입니다. (기존 프론트엔드 소스코드 설계에 맞추느라 어쩔 수 없는 면도 있지만, 핑계라고 생각합니다) 그래서 그런건지는 모르겠지만 버그도 꽤나 많이 만들어내는 것 같구요. 최근에는 꽤나 심각한 버그를 만들어내서 잔소리도 좀 들었네요ㅜ 눈뜨고 잘때까지 회사에서 일만 하는데, 이렇게밖에 코드를 못짜는 제 자신이 너무 한심하고, 개발자를 관둬야 하나 등등 많은 생각이 듭니다. 어떻게 해야 점점 더 좋은 코드를 짜고, 제 자신의 건강도 지킬 수 있을까요?
답변 7
인기 답변
우선은 크게 걱정을 하지 않으셔도 될 것 같습니다. 아마 개발자로 일하는 대부분의 사람들이 비슷하게 느끼는 감정이라고 생각합니다. 그리고 질문자 님께서 현재 상황에 절망만 하고 있는게 아니라, 지금보다 더 나아지고 싶다는 말씀도 해주셨구요. 이런 점에서는 오히려 질문자 님을 칭찬해드리고 싶어요. 제가 보기에 진짜 문제는, 다니고 계신 팀의 개발 문화가 아닐까 싶습니다. 개발 일정을 맞추느라 돌아가는 코드를 짜는 상황이 핑계같다고 말씀해주셨는데, 이것은 어느 회사를 가더라도 비슷할 거에요. 일정이 맞추어져 있다면 코드 퀄리티 때문에 시간을 뺏기기보다는 일단 완성시키는 것이 더 우선이긴 합니다. 우리가 회사에서 코드를 짜는 이유는 "비즈니스의 성공을 위한 도구" 로써 존재하는 것이지, "더 좋은 코드를 짜기 위해" 존재하는 건 아니니까요. 그렇기 때문에 여기에 대해서는 너무 좌절하지 않으셔도 될 것 같습니다. 그런데 심각한 버그를 만들어서 잔소리를 들었다는 부분이 약간 속상하네요. 무조건적으로 책임을 묻지 말아야 한다는 건 아니지만, 개발에 대한 책임을 팀원들이 공통으로 나눠갖고 문제가 발생하지 않도록 함께 고민해보는, 그런 문화가 없어보인다는 느낌을 받았습니다. 혹시 팀 내에서 코드 리뷰를 하고 있나요? 프로젝트를 마무리하거나 발생한 사고를 처리하고 난 후에 회고를 진행하나요? 이런 경우라면, 팀의 개발 문화 자체가 성숙하지 않아 그런 것일 수도 있습니다. 한편으로 개발 일정에 맞춰 스펙을 급하게 쳐내야 하는 일이 잦은가요? 그렇게 크런치 모드로 일을 하고 난 후에, 코드를 다듬고 재정비할 시간을 주지 않나요? 오류가 발생하면 심각한 문제가 발생할 수 있는 코드에 테스트 코드를 짜서 붙일 시간마저 주지 않나요? 개발 팀의 요청에 따라 사소한 스펙은 다음 배포로 미룰 수 있을 정도의 커뮤니케이션이 가능한가요? 이런 경우라면, 회사의 비즈니스 모델 자체가 불안정하거나 사내에서 정치적인 이유로 개발 팀의 영향력이 부족한 것일 수도 있습니다. 만약 위의 조건이 문제라면, 질문자 님의 개인적인 노력만으로는 해결하기 어려운 문제일 수 있습니다. 질문자 님을 둘러싼 환경적인 요인이거든요. 그렇기 때문에 여건이 되신다면 더 나은 개발 문화를 가진 팀으로 이직을 고려해보는 선택지도 가능할 것 같습니다. 만약 그런 것 같진 않다는 생각이 든다면, 내적인 요인들을 바꾸기 위해 노력해볼 수 있을 것 같습니다. 현실적으로 지금 당장 무엇을 할 수 있을지를 생각해봤는데요. 우선은 다른 사람과의 기술적인 정보를 접하는 양 자체를 절대적으로 많이 늘려야 합니다. 개발 커뮤니티에 들어가는 것도 좋고, 개발 뉴스레터나 유튜브를 구독하는 것도 좋죠. 이렇게 커리어리를 둘러보며 많은 개발자 분들과 교류하는 것도 좋구요. 모든 정보를 100% 흡수하지는 못 하더라도, 넓고 얕게 정보를 파악하면서 전반적인 흐름을 따라가는 노력이 중요합니다. 두 번째로는 팀 내에서 같은 실수를 반복하지 않도록 하는 것입니다. 코드를 잘 못 짜는 것은 그럴 수 있지만, 같은 실수가 반복된다는 것은 단순히 실력의 문제가 아니라 신뢰의 문제와도 이어질 수 있거든요. 그렇기 때문에 이런 부분은 조금 더 주의를 기울이고, 이런 경험을 발판삼아 중요한 로직에는 테스트 코드를 붙여보는 시도도 가능할 것 같습니다. 세 번째로는 여유가 된다면 동료들에게 즐거움이나 유익함을 줄 수 있는 코드를 만들고 공유해보세요. 회사에서 개발자로 일하다보면 별의별것들을 다 자동화할 수 있습니다. 업무와 관계된 것이라면 PR 리뷰 리마인더를 만들어 볼 수도 있고, 업무 외적으로는 점심 메뉴를 추천해주는 봇을 만든다던지, 커피 내기(?)를 할 수 있는 봇을 만든다던지요. 그리고 팀원에게 소스 코드를 공유하면서 더 나아질 점이 있는지 한 번 물어보세요. 어쨌든 내가 만든 코드다보니 주인 의식도 있을 거고, 업무와 직접적인 연관이 없는 도메인의 코드다보니 기분 전환도 되구요. 소소하지만 이렇게 사용자(이자 함께 일하는 동료)로부터 피드백을 받다보면 코드의 퀄리티는 물론 코드를 다루는 태도나 확장에 대한 설계 습관이 지금보다 더 나아질 수 있을 것 같습니다.
익명
작성자
2023년 10월 20일
답변 달아주셔서 감사합니다. 어제오늘 여러번 읽으면서 많은 생각이 드는 글이었네요. 물어봐주신 부분에 대해서 저도 답변해드리고 싶은게 있어서 몇자 적자면, 1. 잔소리를 들은건 사실 제가 아니고 대표님 -> FE팀 이었습니다. 테스트코드나 센트리 같은걸 도입해서 사전에 예방하라는 잔소리를 들었습니다..! 저도 해당 기술 도입에 대해 긍정적이나, 해당 기술을 도입한다고 다른 기능 개발을 미룰 수 있는 건 또 아니라서.. 참 어려운 것 같습니다. 말씀하신 FE팀의 영향력 부족도 한몫 하는 것 같다는 생각도 듭니다. 2. 코드리뷰를 하고 있지만, 최소한으로 하고 있습니다! 회고는 스프린트 끝나고 술한잔 하는정도로, 시스템화 되어있지는 않아요. 적다보니 팀내 회고를 공식화 하자는 제안을 해봐야겠다는 생각도 듭니다.
익명
작성자
2023년 10월 20일
3. 개발 자체에 대한 고민으로는, 좋은 설계가 왜 중요한지 특정 설계 베이스로 한 코드를 계속 양산하다보니 뼈저리게 느끼는 것 같아요. 그래서 요즘은 OOP에 대해 좀 파보고 싶어서 자바를 공부하고 있기도 합니다. 프론트엔드 개발자이지만 자바 기반의 학습 자료들을 보면서 배우는게 많은 것 같습니다.
익명
작성자
2023년 10월 20일
다시 일하러 가봐야 해서 자세히 적지는 못했지만, 종윤님 답변에서 이것저것 생각해볼만한 게 많은 것 같아요. 다시 한 번 감사드립니다!
S
소시 FE개발자 • 2023년 10월 26일
2년차 FE입니다. 아래 답변도 읽어봤지만 이 답변이 가장 와닿네요. 코드리뷰를 제대로하지않고 정치적인 이유로 개발팀의 자리가 영향력이 적은 경우 코드를 짠이후/버그이후에 회고를 하지않음이 모여 개발문화가 총체적난국이 되는 경우를 스타트업에서 너무 많이봤습니다. 대기업의 안정적인 구조와 회사관계없이 기본이 되어야할 협업이 되지않는 회사가 많은 현실이 너무 쓰리네요. 이래서 본인들 역량관계없이 결국 알고리즘 알고리즘 하는거겠죠..
인기 답변
안녕하세요! 저도 스타트업에서 백엔드 개발을 하고있습니다! 저도 많이 부족하지만, 같은 스타트업에서 일을 하면서 과거의 제가 느꼈던 생각들을 똑같이 느끼고 계신 것 같아서 조금은 생각을 정리한 제가 어느정도 제 생각을 말씀드릴 수 있을 것 같아서 답변 드립니다! 작성자님의 회사 내부 상황을 정확히 알 순 없지만, 저희 팀을 예로 들면, 매일을 치열하게 피쳐들을 붙여나가고 있습니다. 그러다보면 기존 레거시들은 쌓여만 가고, 간단히 해결할 수 있을 거라 생각했던 피쳐들은 이전에 쌓아놨던 코드들로 인해 더 복잡한 방법으로 문제를 해결해야하는 경우가 다반수였던 것 같습니다. 하지만 스타트업에서의 상황은 매일매일 변하고, 미래에 어떠한 요구사항을 개발자들에게 요구할 지 예측하기 어렵기 때문에 그것들을 모두 만족할 수 있을만한 구조로 개발하기는 어렵다고 생각합니다. 얼마 전, 운이 좋게도 전 강남언니 CTO셨던 이규원 이사님과 Q&A를 할 수 있었던 기회가 있었는데, 기술 부채를 어떻게 해결 해야하냐는 다른 분의 질문에 이사님께서는 기술 부채를 왜 해결해야 하냐고 답변하시더라구요. 저는 그 부분이 굉장히 와닿았습니다. 서비스 하는 데에 문제가 없지만 그냥 그 코드가 밉게 보이는 것일 거라구요. 큰 기업일 경우라면 협업이 굉장히 중요하기에 다른 사람이 보기에도 좋은 코드를 짜는 것이 중요하다고 생각합니다만, 스타트업은 다르다고 생각합니다. 일정에 맞는 빠른 요구 사항 개발과 조금 더 꼼꼼하게 테스트하는 것이 좋을 것 같습니다. 다만 시간을 내셔서 사이드 프로젝트 등을 통해 생각하셨던 바람직한 구조나 개발 방식을 연습해보시는 것도 좋을 것 같습니다!
인기 답변
프론트엔드 개발자로서 자신에게 대한 자괴감을 느끼는 것은 일반적인 일이며, 성장 과정의 일부입니다. 아래에는 자기 자신에 대한 자괴감을 극복하는 데 도움이 될 수 있는 몇 가지 조언이 있습니다: ✅ 자기 자신을 비교하지 마세요: 주변의 다른 개발자들과 비교하지 마세요. 각자 자신의 고유한 학습 속도와 경험이 있으며, 모두가 어딘가에서 시작했습니다. ✅ 작은 성취를 기념하세요: 작은 목표와 성취를 설정하고 달성한 경우에는 축하하십시오. 작은 성공은 큰 성공으로 향하는 길에 중요한 부분입니다. ✅ 계획을 세우세요: 어떤 기술을 습득하고 싶다면 목표와 계획을 세우세요. 작은 단계로 학습하고 개선하세요. ✅ 멘토나 도움을 청하세요: 더 경험있는 개발자에게 조언을 구하고 도움을 청하세요. 프로페셔널 네트워크를 구축하는 것이 도움이 될 수 있습니다. ✅ 실수를 배우는 경험으로 여기세요: 프로그래밍에서는 실수가 발생하는 것이 정상입니다. 실수에서 배우고 성장하는 경험으로 여기세요. ✅ 자기 교육에 투자하세요: 프론트엔드 개발은 끊임없이 변화하므로 자기 교육에 투자하세요. 새로운 기술과 도구를 습득하고 새로운 프로젝트에 도전하세요. ✅ 자기 자신을 믿으세요: 자기 자신을 믿고 긍정적으로 생각하세요. 자신의 능력을 강조하고 성장할 수 있다고 믿는 것이 중요합니다. 자괴감은 모두가 가끔 경험하는 감정이며, 중요한 것은 그 감정을 극복하고 지속적으로 학습하며 성장하는 것입니다. 계속해서 노력하고 자신을 개선해 나가세요.
인기 답변
일단 먼저 당장 돌아가는 코드를 짜도 버그를 발생안시키는 코딩을 고민하셔야 좋을것 같습니다. 기존 소스에 맞추는건 유지보수 측면에서 어느정도 맞다고 생각하고 부분 리팩토링으로 점차적으로 본인이 생각하는 더 좋은 코드로 이끌어 나가야 될것 같습니다. 더 좋은 코드라는건 상황에 따라서 해석이 다릅니다. 개발자가 봤을때는 리팩토링 잘되여 있고 설계 원칙 잘 따르고 아키텍쳐 구성이 잘 되여있는 코드를 보면 좋은 코드라고 보시겠지만 운영자,회사오너 입장에서는 잘돌아가고,적당한 시기에 서비스를 런칭해서 수익화를 시킬수 있는 코드가 좋은 코드라고 볼수도 있습니다. 본인은 현재 오너가 생각하는 좋은 코드를 열심이 짜고 있으니 너무 자괴감 들지 마시고 어떻게 오너가 좋다고 생각하는 코드를 버그 없이 잘 짜드리는데 많이 고민하시고 어느정도 인정받은 뒤에 본인이 생각하는 잘 짜고 싶은 부분을 리팩토링하는것도 나쁘지 않다고 봅니다.개발은 단거리 달리기가 아니라 마라톤입니다.지속적으로 꾸준히 달리시고 힘내세요.
결국 코드리뷰가 중요해보입니다. 주니어개발자의 코드는 시니어 책임이기도 합니다. 정신없이 업무쳐내면 빨리 개발할 수 있는 것 같지만 실은 버그나 안좋은 구조의 코드로 기술부채를 누적시키는것이겠지요. 이걸 해결할 방법 중 하나가 코드리뷰니 자연스럽게 제안해보시길 ...
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
지금 가입하면 모든 질문의 답변을 볼 수 있어요!