어느 한 단어에 꽂힌다는 것
하고 싶은 일을 다 하는 것이 행복이라 생각했고 돈을 많이 버는 것이 자유라고 생각했던 적이 있었다. 치열하면 건강을 잃는다고 생각했고 출근하고 퇴근하는 삶을 살면 평범한 삶이라 생각했다. 그런 삶을 살지 않으려고 발버둥 쳤던 것 같다.
서른의 삶을 마주하면서 어느 순간 부터는 그저 그런 평펌한 삶도 괜찮아 보였다. 나는 그게 강아지 때문인 것 같다. 좀 깨는 소리 같지만 진짜 그렇다. 어떤 생명을 책임진다는 것은 지킬 게 생긴다는 의미이다. 잃을 게 생긴다는 의미다. 특별하게 사는 일에 관심이 사라지고 내게 소중한 것들을 지키는 일에 관심이 생겼다. 그러다 보니 자연스럽게 평범한 삶을 살고 싶어졌다.
좀 다른 결의 삶을 살게 된 결정적인 계기는 워런 버핏 할아버지의 말 때문이었다. 한창 투자, 돈 벌기, 부자 이런 키워드에 관심이 있던 시절에 그 분은 제일 좋은 투자는 자기 자신이 어느 한 분야의 정점을 찍는 거라고 했다. 그게 그렇게 충격이었던 것 같다. 그 말 때문에 새로운 도전을 시작했다.
https://upcurvewave.tistory.com/626
그 '전문성' 키워드 때문에 나는 개발자가 되려고 결심했다.
공부의 시작
내가 생각한 개발자로서의 전문성 획득 첫 스텝은 대학교에 가서 학사 학위를 취득하는 것이었다. 그래서 방통대 컴퓨터과학과에 3학년으로 편입했다.
개발이 컴퓨터 소프트웨어로 돌아가는 어떤 프로그램이라고 할 때, 공부가 꼭 필요하지 않을 수도 있다. 왜냐면 그냥 만들면 되기 때문이다. 만드는 일에 있어서 우여곡절로 요구사항에 따라 돌아가게 되면, 어쨌든 그건 개발을 한 거니까.
그런데 공부를 하면 이런 이점들이 있다.
- 내가 뭘 만드는지 잘 알 수 있다.
- 내가 원하는 걸 그대로 구현할 수 있다.
- 나중에 고치려고 할 때 쉽게 고칠 수 있다.
- 다른 사람과 내가 만든 거를 갖고 얘기할 수 있다.
- 다른 사람이 만든 걸 보고 이해할 수 있다.
공부를 해야하는 이유에 대해 생각해보았는데, 한 가지 답은 시간을 아끼기 위해서가 아닐까 한다. 개발을 하면서 고민을 하게 되는 경우가 많다. 재밌는 건 내가 하는 고민들의 대부분은 이미 누군가가 이전에 했던 고민이라는 점이다. 그 사람들이 - 대체로 나보다 똑똑한 - 그걸 먼저 고민하고 잘 정리를 해 두었다. 그걸 배우는 게 공부라고 생각한다. 이것을 어떤 책의 표현을 빌리자면 '거인의 어깨에 올라서기' 정도가 아닐까. 만약 내가 이전 사람들이 고민하고 정리해둔 내용을 모른채 고민만 하다 보면 엉뚱한 데로 잘못 빠져서 시간을 허비한다거나 뻘소리를 한다거나 할 가능성이 높아질 것이다.
또 한 가지 이유는 더 나은 질문을 하기 위해서다. 비트겐슈타인은 '내 언어의 한계가 내 세상의 한계이다'라는 말을 했다. 공부는 새로운 언어를 배우고 새로운 개념을 배우는 일이다. 즉, 내 언어의 한계를 넓히는 일이다. 그러면 넓히면 뭐가 좋을까? 내 생각에는 보다 적절한 질문을 할 수 있다. 답을 말하는 것보다 질문을 잘하는 것이 중요하다고 생각하게 된 이유는 ChatGpt 때문이다. 기술이 발달할 수록 사람의 지적 역량을 가늠하는 척도 중에 하나는 AI 리터러시가 될 거라고 생각한다. 마치 영어 의사소통 능력처럼. 그 핵심 중에 하나가 질문하는 능력이 아닐까 한다. 그래서 더 나은 질문을 하고 싶어서 공부를 한다.
0년차 주니어
2023년 목표는 개발 커리어를 시작하는 거였다. 자세한 과정은 아래 글에서 다뤘다 .
그렇게 해서 백엔드 개발자 포지션으로 회사에 입사했고 0년차 주니어가 됐다.
국비 → 실무
처음 회사를 오고나서 가장 좋았던 점은 MSA 아키텍처를 직접 경험해볼 수 있다는 점이었다. 일 평균 160만 건 데이터에 대해서 서비스와 서비스 간의 다양한 통신이 이루어지는데 개인 프로젝트에서 하려면 실험정신이 투철해야 가능한 일들을 자연스럽게 경험할 수 있었다.
또 실제 운영되는 서비스냐 아니냐의 차이도 컸다. 작성한 코드가 운영 상황에서 어떻게 적용될지를 생각하게 되는 점도 큰 배울거리였다. 왜냐면 배포 장애나면 초단위로 손실이 쌓이니까 긴장감의 크기가 다르기 때문이다. 그 외에도 혼자 코드를 짤 때는 생각하기 겪기 힘든 다양한 많은 경험들을 할 수 있다.
코드를 문장으로 보는 개발자에서 코드가 사용되는 상황을 상상하는 개발자로 한단계 성장할 수 있는 것 같다.
우리 회사 같은 경우는 인프라 팀이 있긴 했지만 운영도 직접 개발자들의 몫이었다. 그래서 개발을 하고 운영을 함께 하는 ‘you build it, you run it’의 경험이 가능했다.
그 밖에, 함께 기술 이야기를 할 수 있는 사람들과 코드에 대해, 비즈니스 로직에 대해 이렇다 저렇다 논할 수 있는 것도 소중한 경험이다.
그렇다면 실무를 하기 전에 국비 교육 과정을 하면서 잘 배워두면 좋은 점들이 무엇일까. 다음과 같이 정리해보았다.
- 성실성 → 요즘은 유연근무제라서 출퇴근 시간이 자유롭긴 하지만 본질적으로 8시간 일해야 하는 것은 같다. 그런 의미에서 국비 과정에서 매일 지각하지 않고 성실하고 꾸준히 자기 할 일을 묵묵히 하는 것이 사실은 매우 중요한 연습이고 배움이 아닐까 한다.
- 좋은 코드에 대한 고민 → 사람을 위한 코드를 작성하는 법을 배웠으면 좋겠다.
- 커뮤니케이션 능력 → 나 스스로도 늘 부족하다 느끼는 부분이긴 하지만 협업에 있어서 정말 중요한 부분인 것 같다.
- 그 밖에… 알고리즘 실력 + 일정 관리 능력 + 잘 질문하는 능력 → 기본 알고리즘 실력은 필요하다고 생각한다. 단순한 비즈니스 로직이라도 어떤 프로세스를 진행한다는 점에서 알고리즘 문제와 실무의 본질은 동일하다. 일정 관리는 회사에서 살아 남으려면 필수이고… 무엇보다도 강조해보고 싶은 게 잘 질문하는 능력이다. 의사 소통 역량 관점에서 보아도, 상급자나 하급자나 할 것 없이 뭔가를 명령하거나 단언하는 사람 보다 질문하는 사람이 더 매력적이다. 개발자 역량과 성장에 있어서도 본인을 위해서도 중요하다.
내가 이것들을 갖춰서 썼다기 보다는 국비를 다시 한다면 집중해서 길러보고 싶은 역량인 것 같아서 써 보았다.
비즈니스 중심 vs 기술 중심
실무에서 개발을 하다 보면 좀 노가다를 한다는 생각이 들 때도 있다. 결국 개발자의 본질은 어떤 요구 사항을 받으면 그걸 만들어 주는 역할이라서 그런 것 같다. 그러니까 건축이라는 행위와 비교해서 생각해보자. 요구 사항에 대해서 설계하고 구상하고 디자인하는 철학적이고 추상적인 행위도 있지만 포크레인으로 땅을 파고 타일을 바르고 골격을 세우고 지붕 덮는, 그런 작업들은 정형화 되어 있는 부분도 있을 것이다. 개발자 역시 모든 코드를 창의적으로 치는 것이 아니라 특정 부분에서는 반복 작업들을 수행해야 한다.
그런 점에서 개발이 예술과 다른 점이다. 어떤 요구 사항에 대해 기간 이내에 결과물을 만들어 내는 것에 초점을 맞추어야 할 때가 있다는 것이다. 이를 가리켜서 비즈니스 중심의 개발이라고 정의했다.
개발자의 핵심 덕목은 기술력을 바탕으로 회사의 비즈니스 성장을 도와야하는 것이라 생각한다. 그런 의미에서 기술력 향상에 대한 노력은 개인이건 팀이건 필수적이다. 최신 기술을 끊임 없이 탐구하고 항상 더 나은 방식이 없을지 모색하는 것도 중요하다. 최신 기술이 중요한 이유는 이전의 기술이 가진 문제를 대체로 해결하기 때문이다. 그래서 현재 보다 더 좋은 기술력을 빠르게 습득하고 그런 공부를 통해 견고한 시스템을 만드는 데 기여해서 비즈니스 성장을 돕는 것이 개발자들의 숙제이다.
그런데 실무에서는 그런 이상만으로는 일하기 힘들 때가 있다. 기술 부채가 없는 완벽한 코드도 중요하지만 때로는 짧은 호흡의 요구 사항에 맞춰서 코드의 완성도를 타협해야 할 때도 있다. 왜냐면 비즈니스라는 것이 그렇기 때문이다. 항상 넉넉한 일정과 완벽한 지원이 이뤄지지 만은 않는다. 제한된 자원 속에서 어찌됐든 회사의 비즈니스가 돌아가는 데 집중해서 개발을 해야 할 수도 있다. 그래서 기술력 중심의 개발과 비즈니스 중심의 개발의 균형이 중요한 것 같다.
테스트 코드에 대해서
실무를 하면서 점점 더 중요성을 실감 하고 있는 것 하나를 꼽으라면 나는 테스트 코드 작성 능력을 꼽고 싶다. 작은 경험이지만 한 프로젝트에서 200개 가량의 테스트가 돌아가면서 초록색 체크가 쫘좌작 뜨는 것을 지켜보는 경험을 했다. 그때 느끼는 희열은 정말 크다. 그런데 어찌됐든 테스트 코드의 목적은 로직이 제대로 된다는 것을 보장 받기 위함이다.
코드를 다 작성했다면 기능이 의도한 대로 작동하고 있는지를 알아야 한다. 본인도 알아야 하고 주변의 동료들도 알아야 한다. 그걸 누가 보장해줄까? 테스트 코드다. 그래서 고품질의 테스트 코드를 작성하는 것이 프로덕션 코드를 작성하는 것 만큼 중요하다고 생각한다.
테스트 코드를 잘 쓰면 QA에서 발견될 법한 문제를 개발 과정에서 발견하기 쉬워진다. 거기서 그치는 게 아니라 언제라도 수정이 발생할 때, 테스트 코드를 통해 수정 사항의 영향도가 의도한 범위를 벗어나지는 않았는지, 이전 기능이 작동하지 않는지도 알 수 있다. 내가 쓴 코드가 안전함을 보장 받지 못한다면 내가 쓴 코드 때문에 막대한 손실이 발생할 수도 있는데 어떻게 자신 있게 운영 환경에 배포할 수 있을까.
최근에 테스트 코드 관련 글을 쓸 기회가 있었다. 왜 테스트 코드를 써야 하는지에 대해서 다음과 같이 정리해보았다.
걸음마 개발자는 무슨 생각을 할까
성장의 메커니즘
성장의 메커니즘을 생각해보았다. 어떻게 보면 당연한 흐름인 건데 그냥 생각이 나서 그려보았다.
안다는 것은 모른다는 것을 포함하는 개념이다. 언어의 확장이다. 그래서 성장한다는 것은 안다와 모른다의 바운더리가 넓어지는 것이라고, 생각했다.
성장의 기본 원리로 삼다를 꼽는다. 삼다는 다독, 다작, 다상량을 말하는데, 이 3가지가 어우러질 때 성장을 한다는 것이다. 그런데 삼다를 이루려면 반드시 충족되어야 하는 절대적인 조건이 있다. 그게 시간이다. 즉, 시간이 필요하다. 문제는 시간이란 게 제한된 자원이라는 것이다. 수명이 1000년이라면 대충 읽고 대충 살아도 한 300 살 쯤 될 때면 지구상의 왠만한 천재보다 똑똑할 것이다. 그래서 사람의 성장에서 정말 중요한 것 중 하나는 시간의 방정식을 어떻게 나에게 유리하게 작성하느냐가 아닐까 싶다.
늦은 출발 빠른 가속도
나의 경우에는 남들 보다 늦게 시작했다는 것에 대한 자각이 늘 있었다. 그래서 시간이 없다고 느꼈다. 여기서 시간이란 하루 24시간의 시간이 아니라, 내가 이 분야에서 어떤 지점을 돌파하기 까지 남아있는 제한 시간 같은 것을 의미한다. 그래서 삼다에서 우선순위를 다독으로 두었다. 많은 인풋이 중요하다고 생각했다. 어찌됐든 최대한 많이 보고, 노출되는 전략을 택했다. 일단 시간과 양에서 절대 조건을 채워 놓고 그 다음은 그 다음에 생각하자고.
새로운 기술을 습득하고 익히는 데에 있어서 절대적인 시간의 투입은 중요하다. 나이도 무시할 수 없어서 스무살 초반의 말랑 말랑한 머리와 지금의 두뇌 회전이 같은 퍼포먼스를 낼 거라고 생각해서도 안 된다. 그래서 국비 과정을 할 때는 정말 무엇이든 스펀지처럼 빨아들이려고 노력했던 것 같다. '잘하기 보다 자라기'를 목표로 했다. 이미 출발선에서 뒤쳐진 것은 어쩔 수 없다. 속도가 느린 것은 어쩔 수 없다. 하지만 가속도를 붙일 수는 있지 않을까. 당장의 빠른 속도보다 속도의 지속 탄력성, 성장 가속도를 위해 노력했던 것 같다. 그래서 뭐가 됐든 '매일' 하는 것에 초점을 두었다.
GPT '잘' 쓰는 개발자
ChatGpt를 나는 4월 말 즈음부터 알게 됐다. 학원에서 진행한 팀 프로젝트가 거의 끝날 무렵이었다. 돌이켜 보면 당시에는 사용법이 미숙했다.
지금은 정말 많은 부분에서 GPT의 도움을 받고 있다. 어느 순간부터 나는 인공지능을 잘 다루는 능력이 앞으로 개인의 역량에 큰 편차를 줄 것이라고 확신하게 됐다. 즉, 앞으로는 GPT를 잘 쓰는 사람과 GPT를 못 쓰는 사람, 이렇게 나뉠 것 같다고 생각했다. 개발자 뿐만이 아니라 모든 분야에서 말이다.
그러면서 개발자라는 직업의 방향성? 본질? 같은 것을 생각하게 됐다. 그러니까 흔히들 말하는 그런 질문이다. ‘개발자는 대체될까?’ AI 관련해서 심심찮게 잊을만하면 등장하는 논쟁이다. 누구든 견해야 있겠지만은 어떤 면에서는 답도 없는 질문이기도 하다.
이에 대해서 정답이 뭐다라는 것을 결론내리기 보다 나는 GPT를 잘 쓰기로 했다. 왜냐면 AI가 얼마나 발전하든, 결국 그걸 쓰는 사람이 나이면 되는 거니까. 그게 꼭 지금의 챗 GPT가 아닐 수도 있다. 몇 년 후에는 애플이 다른 스마트폰을 다 먹었듯, 어떤 다른 공룡 AI 기업이 등장할 지도 모를 일이다. 어찌됐든 나는 그 회사의 주식을 사면 되는 거고, 기술 문명이 가는 방향을 잘 따라가야겠다는 쪽으로 결론을 내렸다.
단순히 코드를 주고 받는 짝 프로그래밍은 이제 너무 익숙하다. 아키텍처 패턴, 성능의 좋고 나쁨, 유지보수성 등등 개발 관련된 모든 것들 중에 조금이라도 궁금한 게 생긴다거나 긴가민가 한게 있으면 일단 GPT와 대화를 나누면서 답을 찾는다. 매일 뭔가를 물어본다. GPT는 왠만하면 답을 잘하는데, 질문을 잘할 수록 답변 퀄리티가 말도 못하게 상승한다. 그래서 질문을 잘하려고 노력한다. 보다 적절한 질문을 하기 위해서 인터넷을 뒤지기도 한다. 뭔가 앞 뒤가 바뀐 것 같다. 이전에는 원하는 것을 찾기 위해서 검색을 할 텐데, 이제는 질문을 제대로 하기 위해서 검색을 한다. 나는 검색하는 인간 호모 서치쿠스의 시대가 저물고 있다는 것에 동의한다. 최소한 저무는 것은 아니더라도 다른 형태로 진화하고 있는 것 같다. 사실 방금 쓴 호모 서치쿠스라는 용어도 GPT 선질문 후검색으로 사용한 단어이다.
개발에 있어서 GPT는 정말 효율적인 짝이기도 하고 친절한 동료이기도 하고 선임이기도 하고 교수님이기도 하다. 개발 뿐만 아니라 비즈니스 도메인에 있어서도 많은 도움을 받는다.
두 가지 측면에서 나는 개발자들이 더욱 적극적으로 ChatGpt를 사용해야 한다고 생각한다.
- 생산성
- 학습성
위의 두 가지는 개인의 성장을 위해서 필요한 것이다. 생산성은 말할 것도 없다. 학습성은? 견해가 다를 수 있지만 나는 2000년대 검색의 시대에 들어서면서 인간의 지식이 폭발적으로 증가했듯이, AI 시대에서도 마찬가지로 이 신기술을 빠르게 받아들이고 잘 활용하는 사람이 지적 역량을 크게 강화시킬 수 있다고 생각한다.
다음은 시대적인 요구와 반 강제적인 의미에서 Gpt를 사용해야 하는 이유이다.
3. 도구의 사용
4. 막을 수 없음
한 20년 전쯤 가족 휴가를 가던 길을 생각해보면 항상 이런 장면이 떠오르곤 한다. 가는 길에 갑자기 차를 멈추고 아빠가 지도를 뒤져서 여기가 어딘지, 몇 번 국도인지 앞에 표지판은 없는지 살펴보곤 했다. 그런데 지금은 어떠한가. 네이버 지도를(혹은 비슷한 앱을) 사용하지 않는 사람이 있을까? 이젠 누구도 길을 외우지 않는다. 네비게이션이 가라는 대로 길을 간다고 해서 20년 전 지도를 뒤져서 길을 가는 사람 보다 지금의 인류가 멍청해졌다고 아무도 생각하지 않는다.
새로운 도구의 등장이란 그런 것이다. 결국 도구는 어떻게 사용하는 가의 문제이고 인간의 쓸모는 늘 도구를 사용하는 수준에 따라서 평가 받아왔다.
나는 어떤 개발자가 되어야 할까, 어떻게 해야 이 분야에 정점을 찍을까, 확실하게 답을 하지는 못하겠다. 하지만 내가 조금 더 성장하고, 전문성을 획득하는 데 있어서 AI가 도움이 많이 된다고 생각한다. 그래서 이 트렌드에 뒤쳐지지 않으면서 AI를 잘 활용하는 개발자가 되고 싶다는 생각을 한다.
삽질은 계속된다
끊임없이 배우고 답을 희구하는 여정... 이란 말을 내게 대입해 보자면, 말하자면 삽질을 계속한다는 것이다. 내년에는 어떤 삽질을 할까? 다음과 같이 주제를 나눠서 생각해보았다.
해결하고 싶은 문제
개발 관련해서 Dto를 자동으로 생성해주는 오픈소스 라이브러리를 만들어보고 싶다는 생각이 들었다. dto는 사실 entity에 의존적인 객체이다. dto의 종류도 다양하지만 어찌됐든 entity의 필드 데이터를 전달하는 것이 그 존재의 이유일 것이다. 그런데 매번 비슷한 dto를 계속 복붙해서 만드는 것이 좀 번거롭고 귀찮은 일이다. 그런데 이보다 더 큰 문제는 entity의 변환에 dto가 취약하다는 점이다.
예를 들어 Item이라는 엔티티에 대해 createDto, updateDto, searchDto 처럼 다양한 dto들이 존재하고, 또 response로 내보내기 위한 info 객체로서 itemInfo, itemResponse 등이 있을 수 있다. 처음 만들 때는 사실 조금 귀찮더라도 ctrl + c, v 만 잘하면 돼서 크게 문제가 없다. 문제는 item에서 특정 필드가 추가되거나 수정되거나 삭제되었을 때다. 이때 모든 dto를 찾아서 들어가서 변경 사항을 반영해주어야 한다. 이 문제를 자동화하고 싶다는 생각이 들었다.
만들어 보고 싶은 것
만들어 볼 거야 사실 많다. 만성 편두통 환자로서 두통 관리 앱을 만들어보고 싶다는 생각을 했다. 간단한 두통 일지 부터, 편두통 환자들의 앱 기반 커뮤니티, 그리고 병원 정보, 후기 등등...
또 하나는 반려동물 그림 그려주는 AI 기반의 서비스이다. 사진을 넣으면 알아서 괜찮은 그림으로 다양하게 그려주는 서비스를 만들어 보고 싶다.
그리고 빠질 수 없는 게 코인 관련 서비스인데, 기술적 지표를 적절히 잘 모니터링 해주고 알람까지 보내주는 괜찮은 서비스가 아직 많지 않은 것 같다. 있긴 있지만 좀 복잡하고 사용성이 떨어지는 것 같다고 생각했다. 커스터마이징이 매우 편하고 정말 쉽게 매매 전략을 안내해주는 그런 서비스가 필요하다.
배우고 싶은 것
프로그래밍 언어부터 이야기해보자면 코틀린이다. 자바와 스프링과 호환성이 매우 좋고 점점 늘어나는 추세 같다.
채용 시장에 파이썬, node 기반의 백엔드 포지션도 많은 것 같아서 이 언어들로도 백엔드 개발 실력을 갖추고 싶다는 생각이 들었다.
정말 배우고 싶은 것은 인공지능인데, 4학년 과목으로 인공지능 과목들이 남아 있어서 들을 예정이다. 학점 평점을 한 순간에 말아먹을 것 같아서 좀 두렵지만 이론적으로 꼭 도전해서 알아보고 싶은 지식들이다.
이루고 싶은 것
커리어 면에서 도약을 해보고 싶다. 이번 년의 목표는 '개발자 취업' 그 자체였다. 사실 그래서 시장에서의 내 가치 평가에 대해서 정말 무심했다. 그런데 6개월 정도 일하면서 더 나은 평가와 대우를 받고 싶다는 생각이 들었다. 또 기술적으로 더 다양하고 도전적인 환경에서 경험치를 쌓고 싶다는 욕심이 생겼다.
어떤 글을 본 적이 있다. 우아한 형제들의 한 팀에서는 테스트 코드가 천 몇개씩 돌아가서 테스트 코드 자체가 문서가 되고 실제 운영 환경에서의 안정적인 기둥 역할을 한다는 이야기였다. 나는 그것이 너무 멋지다고 생각했다.
진짜 목표
문제는 정말 시간이다. 생각 보다 회사에서 개발하는 데 시간이 오래 걸리는 것 같다. 업무에서 내가 맡은 부분에서의 완성도를 높이다 보면 어느새 일정에 쫓기고 있다. 그래서 야근이나 주말 출근이 필요할 때도 많다. 그렇다 하더라도 코드 품질에서 타협을 하고 싶지는 않다. 내가 메인테이너인 서비스에서 만큼은 90% 이상의 테스트 커버리지를 유지하고, 누가 와서 읽어도 술술 읽히고 유지 보수에 어려움을 갖지 않는, 고품질 코드 베이스를 가진 서비스로 내보내고 싶다. 그래서 그것이 일단 default 일상 목표이다.
두 번째는 방통대를 졸업해야 한다. 방통대 수업을 항상 시험 전에 몰아 듣는 경향이 있는데 이번 학기부터는 학기 초부터 꾸준히 잘 따라가는 것이 목표다.
세 번째는 운동. 시간과 함께 고질적인 문제다. 최소 주 2회는 헬스장에 가기.
덤으로 여력이 되면 프로그래머스 알고리즘 자격증도 따고 해커톤 같은 프로젝트 참여해서 성과도 내보고 싶다.
2023년 고생했다. 2024년도 달려보자~!
'회고' 카테고리의 다른 글
1년차 백엔드 개발자의 퇴사 회고 a.k.a 이직 후기 인트로 (3) | 2024.07.26 |
---|---|
항해 플러스 백엔드 5기 1~5주차 현실 100% 회고 (1+1=N) (2) | 2024.07.19 |
넥스트스텝 ATDD, 클린 코드 with Spring 8기 수료 회고 (1) | 2024.03.15 |
33살 문과 비전공자 국비지원 개발자 신입 취업 후기 (14) | 2023.12.29 |
서른 살, 돈이 벌고 싶다가 개발이 하고 싶어진 이야기 (2) | 2023.12.29 |