서론
지난 주에 AI와 커피챗을 하면서 어떤 방향으로 성장해왔는지 정리하는 시간을 가져보았다.
이번에는 어떤 방향으로 성장하고싶은지에 대한 성찰을 해보려고한다.
이번에도 Claude AI가 생성해준 질문들을 활용했습니다.
AI와 커피챗
취업 후 앞으로 어떤 개발자로 성장하고싶은가? 에 대한 물음에 답하는 시간을 가져보자.
❓ 현재 회사에서 1년 후의 본인의 모습을 어떻게 그리고 계신가요?
이제 입사한지 두 달 정도 되었는데, 그동안 정말 많은 것들을 배우고 경험했어요.
지금은 팀원분들께 질문을 많이 하는 입장이지만, 1년 후에는 제가 도움을 줄 수 있는 동료가 되어있으면 좋겠네요. 특히 제가 하고있는 업무를 잘 이해하고 이를 바탕으로 다른 팀원들의 문제를 같이 해소해줄 수 있는 모습이 되어있길 바래요.
이를 위해 입사하고나서 부터 꾸준히 업무일지를 작성하면서 놓치는 것 없이 기록/기억하려고 노력하고 있어요.
1년 후에는 분명히 제가 작성하는 문서가 팀에 더 많은 가치를 제공할것이라고 생각해요. 💪
❓ 기술적인 면에서 특별히 깊이 있게 발전시키고 싶은 영역이 있나요?
최근 코틀린 + 스프링 환경에서 프로젝트를 진행하면서 코드리뷰를 진행했던 적이 있었는데요. 이 과정에서 코루틴의 동작 구조에 대해 깊이있게 알지 못하는 상태라서 스스로가 많이 답답했던 경험이 있었어요.
(File changes가 단 1개인 작은 PR이였지만 궁금한건 못견뎌서 😅)
대략적인 내용은 다음과 같았어요
runBlocking {
val jobA = launch {
...
}
val jobB = launch {
...
}
joinAll(jobA, jobB)
}위와 같이 작성된 코드에서 runBlocking 스코프 내부에 있으니까 굳이 joinAll을 하지 않아도 되는거 아닌가? 라는 의문이 들었어요. 이 과정에서 코루틴의 경량 스레드가 어떤 원리로 동작하는지 알아야할 필요성을 느꼈고, runBlocking이 종료되어도 내부에서 도는 로직은 남아있을 수 있는건가? 와 같은 궁금증이 생겼어요.
엊그제 막 쌓인 따끈따끈한 기술부채라 해결해야하는 부분이지만 앞으로도 이런 이슈는 계속 나타날 수 있는 부분이라고 생각했어요. 이러한 문제 (궁금증)을 빠르게 이해하고 질 좋은 코드리뷰를 하기 위해서는 탄탄한 기반이 필요하다는것을 느꼈어요.
어떤 기술이든 표면적인 사용법을 넘어 그 작동 원리를 이해하는 것이 중요하다는걸 알고 있었지만 이번 기회에 다시한번 상기할 수 있었어요. 앞으로 CS 지식을 더욱 깊이 있게 공부하면서, 동시에 컨퍼런스나 기술 블로그를 통해 최신 동향도 놓치지 않으려고 합니다. 🔍
❓ 개발자로서의 장기적인 커리어 목표는 무엇인가요? (5년 후의 모습)
저는 제가 가진 경험과 지식을 다른 사람들과 나누고, 그들이 이를 통해 성장하는 모습을 볼 때 큰 성취감을 느낍니다. 우아한테크코스에서 크루들과 토론했던 시간, 교내 IT 동아리의 교육 담당 활동, 그리고 초록스터디와 같은 경험들을 통해 '교육'이라는 새로운 꿈을 발견하게 되었어요. 특히 최근 초록스터디의 프로젝트 과정은 이러한 저의 성향을 다시 한 번 확인하는 계기가 되었죠.
최근 AI의 발달로 개발 입문자들의 학습 곡선이 매우 가파르게 변화하고 있음을 실감하고 있어요. 과거 개발자들이 겪어야 했던 수많은 시행착오를 AI가 상당 부분 해소해주고 있기 때문이라고 생각해요. 이러한 변화는 앞으로의 교육 패러다임도 바꾸게 될거라는 생각을 했어요. 특히 교육자에게 요구되는 지식의 깊이와 폭이 더욱 확장되는 것 뿐만 아니라, 교육자로서 추구해야하는것이 단순한 지식 뿐만이 아니라 협업, 소프트스킬 등 다방면으로 확장될 것이라고 생각해요. 이런 변화를 따라가기 위해서는 일단 지금의 경험을 잘 쌓고, 기록을 해두면서 방향성으로 잘 나아가고 있는지 지속적으로 체크해봐야 할 것 같아요.
❓ 현재 업무 환경에서 배우고 싶거나 경험하고 싶은 것들이 있다면 무엇인가요?
현재 업무 환경은 한마디로 말하면 모르는게 너무많아~ 상태입니다 😅
물론 시간이 지날수록 익숙해지는 것들이 있지만, 저는 구성되어있는 구조를 단순히 복사/붙여넣기하는 개발자가 되고싶지는 않아서 익숙함을 계속 경계하면서 개발하고있어요.
그렇다보니 주어진 기한 내에 업무를 마쳐야하는 기본을 지키면서 두마리 토끼를 잡기는 어렵다는것이 체감되고있어요. 🫠 왜 실무에서 기술 부채가 쌓일 수 밖에 없는지 체감하고 있습니다 🍃
그럼에도 집중하고자 하는 부분은 크게 3가지가 있는 것 같아요.
- 비용절감? 커뮤니케이션 비용도 비용이다.
회사에서 프로젝트를 보면서 가장 처음 들었던 생각은 용어사전을 만들고싶다! 였어요.
일을 하면서 누군가는 DB 컬럼명으로 대화를 시도하고, 누군가는 기획서에 표현되어있는 이름으로 대화를 시도하고, 누군가는 자신이 작성한 변수명으로 대화를 시도하는 상황을 봤었어요. 같이 프로젝트를 진행하고있는 팀원들끼리는 무슨 말인지 바로 이해하고 업무를 수행하고있었지만, 신입사원인 제가 듣기에는 외계용어같이 느껴졌어요. 🫨
프로젝트 내에서는 같은 뜻을 공유하지만 다른 영단어로 적혀져있는 부분도 많았어요.
가령 예를 들어 비용이라는 변수명을 짓는다면 Cost, Purchase, Output 등등 여기저기 각자의 단어로 표현되고 있었던 부분도 찾아볼 수 있었죠.
타 팀과의 교류에서는 바운디드 컨텍스트에 대한 문제도 야기될거라고 생각해요.
이 부분은 전사 표준 용어를 정해두기보다는 팀별 용어사전을 구분하여 공통되는 용어를 비교해볼 수 있도록 구성해보면 좋아보이네요 🤔
아직 시도해보고싶어서 구상중인 단계라 자세하진 않지만 나중에 시도하게 되었을 때 다시 공유드려볼게요 🤗
- 도메인 주도 설계를 DDD라는 말 없이 설명하기
최근 부가세 관련 작업을 진행하면서 다양한 객체들에게 적절한 책임을 부여하는 방식으로 개발을 하고 있습니다. 이런 설계 과정에서 주변에서 주워들었던 DDD(도메인 주도 설계)와 비슷한 접근을 하고 있는게 아닐까? 라는 생각을 했어요. 하지만 아직 DDD에 대한 이해가 부족한 상태라 조심스럽기도 해요. 😅
DDD 관련 서적을 읽어보고 싶다는 생각이 자주 들지만, 한편으로는 망설이고 있는게 현실인 것 같아요. 아직 경험이 충분하지 않은 상태에서 DDD를 학습했을 때, 오히려 그 개념에 매몰되어 실질적으로 중요한 것들을 놓치게 되지 않을까 하는 우려가 있어서 그런 것 같아요.
당장의 DDD 책의 내용 보다는 지금 하고있는 부가세를 포함한 다양한 도메인에서 객체의 역할과 책임을 충분히 고민하고 경험해본 후에 DDD를 접근하는 것이 더 의미 있을 것 같다는 생각이 듭니다. 이러한 실무 경험이 쌓인 후에 DDD를 학습한다면, 더 깊이 있는 이해와 실제적인 적용이 가능할 것 같네요. 🤔
계속 도메인 주도 설계 이야기가 나와서 머쓱하긴 하지만 DDD가 개발분야에만 국한된 개념은 아니라는 것은 명심하고있어요. 💪
최범균님의 DDD 책은 집에 사두고 아직도 펴보지 않았어요
- 자나깨나 레이턴시!
저는 앱을 사용하면서 2초 이상 버벅이면 너무나 극심한 답답함을 느껴요. 특히 은행 앱들이 저에게 고구마를 100만개 심어놓는데 내가 만드는 서비스는 이렇지 않으면 좋겠다고 생각해요.
계속해서 성능과 효율을 생각하는 그런 개발도 해나가고 싶어요.
단 한줄짜리 PR이더라도 성능에 지장이 가는 부분이 없나? 하면서 고민하려고 노력중이에요
❓ 팀 내에서 어떤 역할을 하는 개발자로 성장하고 싶으신가요?
저는 동료들이 편안하게 찾아와서 도움을 요청할 수 있는 개발자가 되고 싶어요.
지난 글에서 언급했듯이, 저에게 있어 함께 성장하는 환경은 가장 중요한 가치로 여겨져요. 내가 동료들의 도움 요청을 받는다는 그 상황은 조직에서 신뢰받는 구성원으로 인정받고 있다는 의미라고 생각하기도 해요. 물론 그 덕분에 바쁘고 정신없을 때가 많아지겠지만 도움을 드리고 돌아오는 "감사합니다"라는 말 한마디에서 큰 힘을 얻기도 하고, 동료들의 성장에 기여할 수 있다는 점에서 큰 보람을 느끼고 있습니다. 🍀
❓ 개발 문화나 조직 문화 측면에서 기여하고 싶은 부분이 있나요?
보통은 자신이 대체 불가능한 사람이 되기를 원하겠지만 저는 대체가능한 인력이 되는것을 목표로 두고있어요.
물론 이 말을 한다고 배짱이 같은 삶을 원하는건 아니에요.
내가 하고있던 업무를 다른 사람이 이해하는데 문제없는 환경을 만들어두고 싶어요. 사내에서 부서이동이 일어났을 때를 생각해보면 좋을 것 같아요. 그때만큼은 처음 보는 코드와 문서가 많이 있을텐데 어떤 사람이 오더라도 빠르게 익숙해지고, 적응할 수 있는 환경을 만들고싶어요.
❓ 일과 삶의 균형을 어떻게 가져가고 싶으신가요?
평일에는 일에 몰입, 주말에는 삶에 몰입하는 균형을 가져가려고해요.
일할때는 일에 제대로 몰입하려고 노력하는 편이에요. 사내 슬랙 외의 연락은 사실 업무에 불필요한 내용이라고 생각해서 핸드폰 알림을 꺼두고 일하는 편이에요. (아이폰 방해금지모드 좋습니다 👍)
해야하는 일이 만족스럽지 않으면 야근을 해서라도 해야겠다는 생각이에요. 일을 잘 해낼수록 저 스스로의 성장에도 많은 도움이 되니까 일석이조라고 생각해요 🍀
번아웃을 경계하기 위해 주말에는 삶에 집중하고자하는 편이에요.
❓ 성장을 위해 현재 실천하고 있거나 계획 중인 구체적인 활동이 있나요?
저는 필요할 때 공부하는걸 좋아하는데 마침 사내 스터디에 참여할 수 있는 기회가 있어서 참여했어요! (제안해주신 회사 동료분께 무한감사 🙏)
스터디를 하면서 학습해온 내용을 발표하는게 아니라 책을 읽으면서 느낀점을 공유하고 잘 이해가 안갔던 부분을 공유하는 식으로 스터디가 진행되어가고있어요. 벌써 2회차가 진행되었는데 업무를 하면서 서로 어떤 부분을 고민하고있고, 어떤 스타일로 개발을 하는지 알 수 있어서 너무 재밌는 시간을 보내고있어요 🤗
개인 공부도 꾸준히 해야겠다는 생각은 하고있지만 평일에 업무 적응에 집중하다보니 집에오면 체력이 소진되어 개인 공부를 할 체력이...🥺 (졸업작품과 초록스터디도 큰 한몫을 했죠)
주말에 놀기만 했었는데 이 삶에도 조금 변화를 줘야겠다고 생각해서 토요일에는 공부하는 시간을 조금이라도 확보해두려고해요. 이 시간에는 개인의 성장을 위한 학습 혹은 블로깅을 하는 시간을 가질 수 있을 것 같아요 💪
❓ 주니어 개발자로서 겪는 어려움을 어떻게 극복해나가실 계획인가요?
주니어 개발자로서 겪는 어려움.. 사실 주어진 상황에서 최선을 다하다보면 괜찮아지겠지? 하고 크게 생각해보지 않았는데 겪고있는 어려움을 한번 나열해볼까요?
- 업무 우선순위
업무를 3~4개정도 처리하면서 리펙터링도 짬짬이 시간내서 하다보면 내가 뭘 하고있었더라..? 하는 상황이 자주 오는 것 같아요. 특히 개발하다가 동료가 말을 걸거나 했을 때 흐름이 끊기는건 일상 다반사죠
이 때 하고있던일을 까먹거나 우선순위를 놓칠 수 있는데 저는 기록으로 이를 해소하고있어요.
저는 출근해서 가장 먼저 사내 문서를 켜고 개인 스페이스에서 업무일지를 작성하고 일을 시작하는 편이에요.
어제 완료한 업무와 오늘 해야할 업무를 정리하고 하루 일과를 시작하죠 그런데 이것조차 까먹을 수 있으니 그 아래에 타임라인을 만들어서 아침, 점심, 저녁까지 진행상황을 계속해서 기록하고있어요. 이렇게 하다보니 제 개인의 역량을 파악할 수 있고, 막히는 포인트가 어디인지 파악하기도 용이해서 저의 문제점을 빠르게 인지하게 되는 것 같아요.
업무일지는 입사한 1월 6일부터 지금까지 계속 써오고있습니다 📝
자유로움을 위해 양식은 따로 두지는 않았어요
제목: 0월 0일 (0요일) 업무일지
내용:
**전날 완료한 업무**
- 000
**오늘 진행할 업무**
- 000
## 타임라인
- ...
- ...- 용어의 어려움
위에서 이야기했던 내용인데 팀 내에서 소통할 때 사용하고있는 용어들이 이해가 잘 안갈때가 많아서 팀원분들께 물어봐가면서 용어사전을 만들고있어요.
언젠가는 용어사전만 줘도 다 알아볼 수 있게 만들고싶어요
- 코드리뷰, 컨벤션
코드리뷰가 있긴 하지만 조금 더 활성화하고싶다는 생각이 들었어요.
빠르게 개발하고 배포해야하는 건에 대해서는 코드리뷰가 다소 아쉬운 퀄리티로 나올 수 있는 점은 이해하지만 그럼에도 코멘트 하나 이상은 달면 좋겠다는 생각이 들어요.
최근에는 시간이 허용하는 선에서 코드리뷰를 요청하는 동료분이 있으면 후다닥 PR에 들어가서 코멘트 하나라도 남기려고 노력하고있어요.
저희 팀 뿐만 아니라 다른 팀의 내용도 리뷰 하면서 서로의 업무를 이해할 수 있는 좋은 기회도 가져가고 있어요🍀
- 기술적 어려움
현재 회사에서 사용하고있는 기술 스택에서 낯선 기술들이 종종 등장하곤 하는데 주어진 환경에서 쓰던대로 쓰는것 말고, 더 잘 쓰고싶다는 생각이 들어요.
그러기 위해서는 학습이 필요한데 기술 부채만 잔뜩 쌓아둔 상태에요
Kafka, Spark, Kotlin이 현재 생각중인 큰 틀의 부채들이에요 🤔
이 부분은 주말에 할당하는 학습시간에 최대한 메꿔보려고해요
후기
이번에도 AI에게 내용을 요약해달라고 해봤다.
🌱 단기 목표 (1년)
👥 신뢰받는 동료로 성장
- 질문하는 입장에서 도움을 주는 입장으로 전환
- 업무일지를 통한 체계적인 지식 축적
- 팀에 실질적인 가치를 제공하는 구성원으로 성장
💻 기술적 깊이 확보
- CS 기반 지식 강화
- 코틀린, 스프링 등 현재 사용 중인 기술 스택의 깊이 있는 이해
- 성능과 효율성을 고려한 개발 능력 향상
🔄 업무 환경 개선 기여
- 용어사전 구축을 통한 커뮤니케이션 효율화
- 도메인 설계 경험 축적
- 코드 리뷰 문화 활성화
🚀 장기 목표 (5년)
📚 교육자로서의 성장
- 경험과 지식을 공유하는 멘토 역할
- AI 시대에 맞는 새로운 교육 방식 연구
- 기술뿐만 아니라 소프트 스킬까지 포함한 통합적 접근
⚖️ 지속 가능한 개발자
- 대체 가능한 인력이 되기 위한 문서화와 지식 공유
- 일과 삶의 균형 유지
- 꾸준한 자기 계발과 학습
✨ 현재 실천 중인 활동
- 📝 일일 업무일지 작성
- 👥 사내 스터디 참여
- 📚 토요일 학습 시간 확보
- 📖 용어사전 구축
- 💬 적극적인 코드 리뷰 참여정리된걸 보니 앞으로 해야할게 많구나... 라는게 느껴진다.
할일 없는것보다는 백배 천배는 나으니 오히려 좋다고 생각한다.
단기 목표 로드맵을 작성해달라고 요청해봤다.
🌱 3개월 차 (2024.01.06 ~ 2024.04.05)
• 업무 프로세스 완벽 적응
• 용어사전 V1 구축 및 팀 내 공유
• 코틀린 코루틴 심화 학습
• 사내 스터디 지속 참여
• 업무일지 작성 습관화
🌿 6개월 차 (2024.04.06 ~ 2024.07.05)
• 담당 업무 영역 독립적 수행
• 용어사전 개선 및 타팀 확장
• Kafka, Spark 기본 학습 완료
• CS 기초 지식 강화 시작
🌳 9개월 차 (2024.07.06 ~ 2024.10.05)
• 신규 입사자 멘토링 참여
• 도메인 설계 경험 축적
• 팀 내 기술 공유 세션 진행
• 분산 시스템 이해도 향상
🎄 1년 차 (2024.10.06 ~ 2025.01.05)
• 팀 생산성 향상을 위한 도구/프로세스 제안
• DDD 학습 및 실무 적용 시도
• 기술 블로그 글 작성 및 공유이정도면 준수한 것 같다. 아마 상황에 따라 추가되는 내용이 있을거 같지만, 위 타임라인을 기준으로 삼고 한번 적용해봐야겠다.
