3년차 개발자 회고록 (+ 2023년 하반기 회고)

 

 

 

1. 시작하며

3년차 개발자 회고록 (상반기)

 

상반기 회고록 쓴 지가 벌써 6개월이나 지났다니. 나이 들수록 시간이 빨리 간다더니 진짜 맞는 말인가 보다.

이전에 기록했던 회고들을 쭉 훑어봤는데, 업무와 업무 외 개발활동 말고는 내 개인적인 생활이나 감정이 담겨있는 글이 없는 게 아쉬웠다. 회고록을 기록하기 시작했을 때 '개발자 회고록'이라는 타이틀을 붙여서인지 아니면 실제로 내 생활보단 일을 먼저 생각했기 때문이었는지는 모르겠다. 결론적으로는 이번 회고록은 하반기 회사에서의 회고와 개인 개발 회고를 작성하고, 23년에 대한 총회고까지 짧게나마 담아서 마무리하는 게 목표다.

 

 

---

 

 

2. 하반기 개발자 회고 - 회사 업무

작년과 올해 상반기에 이어 이번 하반기도 업무비중 퍼센트를 따져보았다.

 

• R&D 40% ( 전년 대비 10% ⬆️ ) / 신규기능개발 및 기능개선 40% ( 전년 동일  )
  • 아무래도 연차가 올라갈수록 같은 시간이 주어졌을 때 그 시간을 활용하는 밀도와 질이 높아진다고 생각이 든다.
    기능 개발이나 개선에 있어서도 '만드는 것' 그 자체에만 만족하기보다는 '지속가능한 구조와 코드와 기능을 만드는 것'에 더 의의를 두게 되었고, '더 사용성이 좋게' 만드는 것에 대해서도 고민을 많이 한다. 그러다 보니 자연스럽게 유지보수나 안정성, 사용성, 서버 통신 방식에서의 개선, 렌더링 과정 개선 등을 위한 고민을 많이 하며 R&D에 쓰는 비중이 작년보다는 높아졌다. 
• 개발문화 17% ( 전년 대비 2% ⬆️ )
  • 내 개인적인 회고를 봤을 때는 서비스와 제품의 개선에 초점을 과하게 맞추고 달려온 지난 3년에 비해 나아진 결과인 건 맞지만, 회사 전체적인 분위기는 아직 개발적인 효용성을 '잘', 혹은 '더' 생각할 수 있는 여유나 역량이나 상황이 모두에게 아직까지는 부족하다고 느낀다. 그래서 내가 할 수 있는 범위 내에서 다양한 방법으로 개발 문화 활성화에 힘쓰려고 했다. 
• 반복업무 3% ( 전년 대비 12% ⬇️ )



일단 생각나는 프로젝트들만 작성해보겠다.

 

---

 

1) Electron repository Bundler 적용 (vite)

 

하반기의 시작이었던 7월, 서비스를 사용하고 있는 고객사에서 PC 앱에 대한 문의가 유난히 많이 들어왔다.

한창 프론트엔드 영역의 최적화나 백엔드 작업을 주로 하고 있던 나에게 PC앱 자체, 즉 electron에 대한 수많은 문의는 개선욕구를 불러일으키는(?) 자극이 되었던 것 같기도 하다. 당시 우리 데스크탑용 앱 소스 (렌더러 프로세스/메인 프로세스 용 소스)는 번들링이 되어있지 않았었는데, 이 부분은 결국 용량과 보안적 측면에서 문제가 되어 번들링을 추진하게 되었다.

 

일단 우리가 모니터링에 사용하고 있던 sentry와의 호환성과 electron 과의 호환성 등 여러가지 측면을 고려했을 때 번들러는 vite로 선정했다. 번들링의 선작업이라고 볼 수 있는 모듈화를 목적으로 리팩토링을 시작했고, 모듈 간의 의존관계를 명확하게 나눠 번들링의 범위를 지정하는 방식으로 앱 빌드 방식을 변경하였다. 결과적으로 전후를 비교했을 때 앱의 용량과 초기 메모리 사용량 모두 개선되었고 보안적 이슈도 해결되었다. 

 

다만 아쉬운 점은 아직 고객사의 모든 앱에 적용하지 못했다는 점이다. 24년에는 꼭 적용해서 모두가 나은 사용성을 누렸으면 좋겠다.

 

---

 

2) 메인 페이지 프론트엔드 성능 최적화

 

상반기에 '프론트엔드 성능 최적화'라는 책으로 스터디를 진행했었다. 아는 만큼 보인다고 했던가...  스터디 이후 우리 서비스를 분석해 보니 개선을 해야 하는 부분이 굉장히 많이 보였다. 개선할게 너무 많이 보여서 대체 어디서부터 시작해야 할까 고민하며 '프론트 레볼루션'이라는 나만의 프로젝트를 언젠간 추진하려고 개인 노션에 끄적이고 있던 찰나, 팀장님께서 인피니트 스크롤 개념을 적용해 보라는 과제를 주셨다.

 

딱 이때다 싶어 infinite scroll에 필요한 dom recycle 개념을 도입하면서, 동시에 기존에 생각했던 Total blocking time 에서의 문제점들을 같이 개선했다. 이때 불필요한 돔을 많이 정리하고 intersectionObserver를 활용해 재활용할 수 있는 부분은 재활용하도록 구조를 변경하며 데이터상태를 관리하는 구조가 필요해졌고, 특정 데이터를 바라보며 화면에 보이는 순간 그려지는 방식으로 구현했다. 

 

 

	domFindTime	Total blocking time
전	21.6ms	5201.4ms
후	5.2ms	376.4ms

 

 

작업 이후에는 무려 동일한 동작을 반복 했을때의 blocking time 이 14배 가까이 (5201ms -> 376ms) 개선되었고, cpu 차트에서의 병목도 대부분 사라졌다. 정리되기 전에는 메인 페이지에서 요소들을 그리는데 소요되는 비용이 갈수록 증가하는 현상이 있었다. 동일한 동작을 반복해도 작업 이전엔 돔이 쌓임에 따라 heap 메모리가 계속 누적되며 증가했었다면, 작업 이후엔 쌓인 돔이 해소되고 중간중간 정리되며 초기화되는 것도 확인할 수 있다.

 

 

그렇게 이 프로젝트는 시간관계상 약 2주만에 완료되었다. 하지만 개인적으로는 굉장히 찝찝하기도 하다. 물론 기존 구조에 비해 개선 이후 훨ㄹㄹㄹㄹㄹㄹㄹ씬 개선된 수치와 사용성을 느낄 수 있기 때문에 잘 된 것도 맞지만, 완전히 reflow, repaint로부터 자유로운 구조는 아니기 때문에 아직 개선 더 많은 개선이 필요하다고 생각한다. 또한 프론트엔드 단에서 현재 프레임워크를 사용하고 있지 않기 때문에 모듈화의 난이도가 높은 편인데, 그때그때 필요한 모듈만 들고 다닌다기보다는 미리 로딩을 해놓는 방식으로 구현된 기능이 많아 렌더링 속도에 악영향을 끼치는 중이다.

 

그런 부분까지 모두 고려해 완전히 성능최적화를 해내기에는 주어진 과제가 '스크롤 개선' 이었다보니 '최선'의 결과가 나오진 못한 것 같아서 아쉽다.

 

---

 

3) Redis 와 node 서버를 활용한 실시간 상태표시 개선

 

우리 서비스에는 '실시간 상태 표시'라는 기능이 있다. 말 그대로 사용자의 온라인/자리비움/오프라인 등의 상태를 보여주는 기능이다. 기존에는 이 부분이 RDB를 활용해서 구현이 되어있었는데, 너무 많은 사용자가 몰려 해당 기능에 대한 업데이트 동작이 너무 많이 발생하게 되면 특정 테이블을 타겟으로 동시간에 수만 번의 update와 read 가 발생하게 된다. 이렇게 되면 불필요하게 과도한 dead tuple 이 쌓이기도 하고, 그로 인해 너무 잦은 베큠이 동작하기도 하고, 데드락을 발생시키기도 하기 때문에 꼭 개선이 필요한 부분이었다.

 

접속 상태를 기존 rdb 에 저장하지 않고 redis에 저장하도록 개선하는 것이 이번 작업의 주목적이었으며, 관련 모든 로직을 was 서버의 api를 통해 rdb를 업데이트하는 방식에서 '클라이언트 - 상태소켓서버 - 레디스' 간의 통신으로 변경했다. 7월부터 10월까지 3개월 동안 사내에서 레디스 스터디를 개설해서 진행했던 덕에 레디스를 활용하는 것에서는 큰 어려움은 없었고, 기존에도 채팅도메인을 주로 담당해 왔기 때문에 실시간 서버작업도 큰 어려움은 없었다.

 

 

예상치 못한 복병이 있었는데, 바로 부하테스트였다. 신규 인프라 구조이다 보니 부하테스트를 반드시 진행했어야 하는데, 그 부분을 간과하고 시간에 쫓겨 바로 내부 오픈을 진행해서 결국엔 신규 서버에 부하가 왔다. 다행히 사용자들은 쓰지 않는 내부 테스트 서버였지만, 그래도 문제가 되었던 만큼 부하테스트를 꼭 제대로 진행해서 다음부터는 같은 일이 반복되지 않게 해야겠다는 경각심이 들었다.

 

---

 

4) node.js 서버 부하테스트

 

나는 주로 node.js 서버를 위한 부하테스트를 진행했고 socket io 를 활용한 기능들에서 필요성이 제기되었기 때문에 artillary라는 도구를 활용하여 부하테스트를 진행했다. 목푯값을 세팅하고, 테스트환경을 세팅하고, 시나리오를 작성해서 결과를 공유하면 되는 일이기에 크게 어렵지 않게 결과를 도출할 수 있어 큰 어려움은 없었다.

 

사실 부하테스트를 진행하면서 느낀 점은 따로있다.

 

부하테스트를 진행하는 데에는 정말 많은 필요조건이 있다. 일단 테스트를 진행할 수 있는 운영과 비슷한 조건의 서버 구성 및 데이터와, 목표치와, 시나리오와 이 모든 것을 원활히 진행하기 위한 유관부서의 적극성 혹은 상급자의 협조 등등.

개인적으로 부하테스트는 그냥 '했다'라는 말로 개발요청자에게 안정감을 주기 위해 끝내는 것이 아니라고 생각했다. 테스트 결과 어느 환경에서 어느 수준까지 버틸 수 있으며, 이것을 통해 어느 범위까지가 우리가 예상 가능한 범위이고 앞으로 어떤 시점이 오면 그때는 예상외의 현상이 일어날 테니 어느 지점을 개선을 해야 할지 등 작업자로 하여금 수많은 인사이트를 줄 수 있어야 성공적인 부하테스트라고 생각했다. 이건 철저히 '개발자'인 나의 주관적인 의견이기도 해서, 수많은 회의를 통해 우리 조직에 맞고 다양한 부서들의 니즈를 충족시키는 방향의 부하테스트 프로세스를 만들어가길 희망했고 그 초석을 다지고자 했다.

 

 

 

"PM의 입장에서의 부하테스트 결과와 개발자 입장에서의 부하테스트 결과는 달라야 한다."라는 방향으로 결과 공유 양식을 샘플로 나눠서 작성해서 공유하기도 하고, 시나리오를 관리하고 히스토리를 쌓기 위한 방법, 샘플 데이터를 많은 시간을 들이지 않고도 생성하는 방법 등을 연구하고 조사해서 공유했다. 부서별 R&R 도 회의를 통해 도출되었고, 이제 실천만 하는 단계에 이르렀다. 

 

하지만 내가 상급자들을 잘 설득하지 못해서인지, 유관부서에서의 필요성 인지가 부족했던 탓인지, 실천할 개발자들의 시간적 리소스가 부족했던 탓인지는 모르겠으나 결국 잘 정착되지 않았다고 느껴진다. 너무 복잡하고 어려운 개념을 한 번에 정석적으로 도입하려고 했던 것 같기도 하다. 또한 그렇게 공을 들인 과정을 실천하는 와중에 '왜 이렇게 오래 걸려요? 다 만들어놨는데 왜 오픈 못하고 있는 거예요?'라는 식의 압박이나, 자세한 프로젝트의 과정을 모르는 누군가가 '그거 아직도 개발 중이에요?'라는 식의 말들을 툭툭 뱉게 되면 그 호흡에 맞춰가려다가 흐지부지 넘어가게 되는 게 현실이기도 하다. 사실 '아마존 웹 서비스 부하 테스트 입문'이라는 책을 통해서 실무에서 흔히 일어난다고 들었던 예상했던 상황이라 잘 넘어갈 수 있을 거라 생각했지만, 막상 회사원입장인 개발자는 그렇지가 않았다..! 

 

이런 상황을 어떻게 헤쳐나가야 하는지는 아직도 미지수다.

솔직히 회고록을 쓰고 있는 이 상황에서도 이 문제는 해결되지 않았고 고민 중인 부분이라, 끝맺음을 명확히 못할 것 같으니 일단 푸념만 하고 넘어가겠다!

 

---

 

5) 채팅 전송정책 고도화

 

 

기존의 채팅 기능은 보내는 과정에서 네트워크 환경으로 인해 발생할 수 있는 유실을 고려하지 않았었다. 받는 쪽에서 '못 받은 채팅'이 있는지를 확인해서 갱신하는 방어 로직은 약 1~2년 전에 개발된 게 있었다. 하지만 채팅을 주고받을 수 있는 상황인지 아닌지를 보내는 사용자가 판단할 수 없게 만들어진 채팅을 사용한다면, 사용자가 느끼는 부자연스러움은 더 크고 '이건 무조건 유실이다!'라고 생각할 수밖에 없다. 이 부분은 '유실 오류 문의'로 이어지곤 했는데, 서비스 사용자가 늘어나며 더욱 많은 문의가 오는 상황이라 개선을 추진했다.

 

 

 

 

사용자들이 채팅과 관련해서 전송이 안되거나 수신이 안되었다고 느끼는 대부분의 케이스는 네트워크 불안정으로 인해 정상적으로 전달되지 않은 케이스라고 볼 수 있다. '네트워크 불안정' 속에 담긴 의미는 사실 어마어마하게 다양하고 많기 때문에, 케이스를 크게 '전송 시점', '입장 시점' 2가지로 나눠 세분화해서 정책 자체를 고도화하여 '임시메시지'라는 기능을 제안했다. 사용자는 일단 화면에 그려진 값에 대해서는 '입력이 되었다'라고 인지하는 반면, 실제 기능은 그렇게 들어맞지 않기 때문에 만약의 상황을 위한 조치와도 같은 기능이다. 물론 개발단에서의 보완도 많이 들어갔지만, 사용성 측면에서도 오류를 적게 느끼려면 임시메시지가 필요하다고 느껴 제안했고 기획/디자인/퍼블에 거쳐 기능으로 탄생하게 되었다.

 

---

 

3. 하반기 개발자 회고  - 개발문화

이제 겨우 3년 차주니어가 뭘 회사 개발 문화까지 고민하냐라고 할 수도 있겠지만은, 적어도 이 회사에서는 선배 개발자분들은 10명 내로 계시고, 오히려 뒤로 들어온 개발자들이 약 30명이나 되기 때문에 조금이라도 먼저 들어온 사람의 범위에 속한다는 것에 책임감을 갖고 좋은 길을 닦아 놓고 싶다는 생각이 많이 들었었다.

'성숙한 개발문화가 갖춰지고 있는 조직'이라는 타이틀을 언젠가는 다른 팀원들이 자연스럽게 느낄 수 있게 하려고 다방면의 시도를 해 보았던 한 해였다.

 

 

1) 제1회 Developer's Meetup 개최!

이전 회고록에서도 밝혔듯, 사내에서 개발팀 문화 활성화를 위해 선정되는 CA (Culture Agency) 로서의 역할을 맡고 있다. 그 역할은 좀 친근한 이미지와 가상의 캐릭터처럼 느껴지면 좋을 것 같다고 생각해서 '플로끼'라는 토끼 캐릭터의 탈을 쓰고 활동하고 있다. 하반기의 첫 활동은 상반기를 리뷰하고 팀워크를 다질 수 있는 시간을 가지는 것으로 스타트를 끊었다.

 

사실 처음에는 '다 같이 모여서 회고해 보면 좋지 않을까요?'라는 제안으로 가볍게 시작했었다. 하지만 입사 이래로 3년이 넘는 시간 동안 사내 개발자가 모두 모이는 행사가 생각해 보니 무려 처음이었고, 그 행사를 내가 기획하고 운영하고 어쩌다 보니 진행자까지 맡게 되었다. 

 

 

 

하지만 connecting dots라는 말이 괜히 있는 말이 아니었나 보다. 이전 직장에서 교육을 하며 수도 없이 마이크를 잡았었는데, 몇 년 만에 마이크를 잡으니 긴장은 금방 풀리고 막상 재밌고 신나서 잘 마무리할 수 있었던 것 같다. 발표세션에서도 다른 개발자 분들과 CTO 님이 발표를 열심히 준비해 주셨고, 마지막 롤링페이퍼 때도 다들 너무나도 적극적으로 응원의 메시지를 남겨주었다. 개최 사실을 알게 된 경영지원팀 측에서도 점심 및 로비 사용에 적극 협조해 주셨고, 마침 지나가시던 대표님까지 붙잡아 즉석에서 '개발팀에게 한마디' 자리도 만들었다.

 

이래저래 나를 포함한 모두에게 신선한 시간이었고, 소통이 적었던 타 개발팀과도 교류할 수 있는 자리가 되었다는 피드백을 들어서 결과적으로는 성공적이었던 첫 번째 밋업이었다고 생각한다.

 

 

 

---

 

 

2) IT 동아 개발인터뷰

그러던 중에 개발팀에서 언론 인터뷰를 할 수 있는 기회가 주어졌다. 우연한 기회로 부랴부랴 준비했지만, 지금까지 서비스 개발을 위해 혹은 조직문화를 위해 모두가 노력했던 과정들을 소개할 수 있는 자리여서 감사하고 즐거운 경험이었다. 

 

https://www.donga.com/news/It/article/all/20230811/120667478/1

협업 툴 '플로우' 개발 팀 "누구보다 잘 쓰고, 이를 토대로 만듭니다"

 

그리고 사진... 정말 잘 찍어주셨다.ㅎㅎ 

 

 

---

 

3) 코드리뷰 툴 도입

바로 직전 포스팅에서 다뤘던 내용인 코드리뷰! 회고록에서는 자세한 내용은 생략한다.

https://todayscoding.tistory.com/67

효과적인 코드 리뷰를 향한 여정 (ft. aws codecommit, space)

 

---

 

4) 스크럼 문화 정착하기

 

올해 초, 새로운 팀이 꾸려지고 나서 리딩을 맡게 되었을 때 가장 걱정했던 것이 공유문화였다. 개인적으로 나는 개발적인 성장이나 업무 습득, 프로젝트 추진역량 등 모든 회사 내의 퍼포먼스는 팀에서부터 비롯된다고 생각하는 엄청난 팀중심의 사고방식을 가지고 있기 때문에, 혹여 나의 잘못된 리드로 인해 팀 퍼포먼스가 떨어지면 어쩌나 노심초사하는 1년이기도 했다. 

 

그래서 30분 내외로 아주 짧게 그 전날 각자의 코드에 대한 고민이나 프로젝트에 대한 진행상황 등을 공유해서 서로 의견을 나누는 자리를 만들었다. 매일매일 진행할 필요가 없는 경우에는 2~3일에 한 번씩 하기도 하고 1주일에 한번 하기도 하며 유동적으로 진행했다. 그 덕에 마지막 팀 회고 때는 팀 내에서 1명만 알고 있는 일은 없고 대리 임무 수행이 원활했다고 느낄 정도로 공유가 잘된 것 같다는 팀원들의 피드백을 들을 수 있었다. 사실 이 문화가 잘 정착될 수 있었던 건 적극적으로 참여해 준 팀원들의 몫이 크다. 내년에도 잘 유지되길!

 

 

---

 

5) 레디스 스터디

하반기에는 레디스 스터디를 진행했다. 개인적으로는 nosql 에 대한 공부를 책으로 진득하게 진행한 건 처음이어서 굉장히 많이 배웠고, 마침 하반기에 레디스를 적용해 볼 수 있는 기능과제를 받아 적용할 수 있어 좋았다. 바쁘신 와중에 열심히 참여해 주신 스터디원들에게도 무한감사!

 

 

 

---

 

 

6) 사내 커피챗 문화 만들기

지금 회고록을 쓰는 이 시점에도 회사에서 모집 중이다. 바로 사내 커피챗! 회사의 성장이 매우 빠르고 조직의 변화도 많다 보니, 생각보다 개인의 고민을 공유하지 못하고 일에만 매몰되는 경우들이 많다고 느껴졌다. 주위를 둘러보면 혼자 낑낑대거나 번아웃이 온 동료들도 많아 보여, 나에겐 매우매우매우 힐링이었던 글또의 커피챗 문화를 회사에 가져와보았다. (글또 운영진분들과 참여자분들과 함께 커피챗을 해주신 모든 분들과 성윤님께 무한한 감사를!!) 

 

'책'이라는 소재를 통해 고민을 나누고 소통할 수 있는 자리를 만들어보았는데, 생각보다 빠르게 지원자들이 몰려 다행이었다. 실제 커피챗을 한 뒤에도 내가 그랬던 것처럼 우리 회사 사람들도 힐링받았으면 좋겠다! 

 

---

 

4. 2023 일상회고

드디어 일상회고! 좀 더 가벼운 마음으로 끄적끄적 써보자.

 

요가 & 다이어트

올해 초에는 무려 아침 7시마다 요가를 다녔다. 처음에는 '나 아침형 인간이었던가?'라는 합리적 의심을 할 정도로 아침이 상쾌했지만, 아무래도 업무 특성상 야근이 많고 밤 11시 12시가 다 되어 퇴근한 적도 많다 보니 오랫동안 지속하기 어려웠다. 대신 요즘엔 가끔 집에서 홈트영상을 보면서 요가를 하기도 하는데, 확실히 뻐근한 몸을 풀기에는 최고다! 하반기에는 마사지를 받으면서 다이어트 식단을 했는데, 피로도 풀리고 몸도 가벼워지니 확실히 일상에 활기가 생긴 것 같다. 24년은 좀 더 운동량을 늘리자.

 

 

전세 반환 소송

정말 두말하면 입 아플 정도로 머리 아프게 했던 사건이다. 자취방을 빼려던 올해 초쯤이었던가. 문득 등기부등본을 내려보니 이게 웬걸. 낯선 한 줄이 추가되어 있었다. :) 사건의 전말을 말하기엔 구구절절해질 것 같으니 결론만 적어두자면 그 집주인 자식은 지금 의정부 교도소에 가 있고 나는 소송을 준비 중에 있다. 내 돈 내놔!!!!!!!!!! 24년엔 반드시 돌려받는다.................. 후

 

 

결혼

회고록에 적을까 말까 고민했지만, 절대 빼먹을 수 없는 내 인생의 가장 큰 전환점이자 사건! 결혼식을 12월에 올렸다. 바쁘고 정신없는 동안에 주말마다 '신랑님~ 신부님~'이라는 낯선 호칭 들으며 눈코 뜰 새 없이 돌아다니며 준비했던 올 해였다. 음.. 뭔가 회고록에 개인사를 적는 게 정말 익숙지가 않다. 그냥 사진으로 퉁치자!

 

 

가족, 친구, 인간관계

결혼 준비를 하며 올 해는 정말 많은 나의 친구들과 지인들과 친적들과 더불어, 현 남편의 지인들까지 정말 많은 사람들을 만났다. 솔직히 내가 이렇게 복이 많은 사람이었나 싶을 정도로 주위에 좋은 분들과 감사한 분들이 너무 많다는 게 느껴져서 황홀했던 적도 많다. 하다못해 웨딩촬영을 하다 만난 분들과 플래너님과 본식 당일에 만난 사진기사님 마저 너무 좋으신 분 들 이어서 정말 이게 무슨 행운의 연속인가 싶을 정도로 감사했다. 반대로 나는 과연 좋은 지인이자 친구이자 가족이자 스쳐 지나가더라도 좋은 사람인지 반성하게 되는 계기이기도 했다. (아닌 것 같다..) 바쁘다는 핑계는 성인이 되고 나서 10년 동안 항상 했던 것 같은데, 이제 그만 바쁜 사람 되고 좀 더 주위 사람들에게 따듯한 사람이 되고 싶다. 

 

 

---

 

5. 마치며

회고록을 쓰고 나니 나름 많은 일들을 해내왔지만, 사실 23년은 정말 많은 사건 사고도 있었지만 업무적으로도 방황이 컸던 3년 차의 시기여서 개인적으로 멘탈이 너무 약해졌던 1년이었다. 항상 하고 있는 모든 것과 마주한 모든 상황에 '이게 맞나?'라는 의심이 들고 '에라 모르겠다'라고 생각이 드는 많은 순간들을 애써 정신줄 부여잡고 겨우겨우 마무리지었던 적도 많다.

 

그 원인이 지금 생각해 보면 조급함 때문이라는 생각이 든다. 하지만 아직까지는 그 조급함을 어떻게 해소해야 하는지는 고민이 된다. 좀 더 내려놓는 연습을 해야 하는 건지, 아니면 내 성장을 위한 추진동력으로 사용해야하는건지, 아니면 그 조급함 자체를 적재적소에 활용할 수 있는 판단력을 길러야하는건지, 업무가 아닌 개인적인 시간에 해소해야 해야하는건지 모르겠다. 갑자기 뜬금없이 개발자 인생에 사춘기가 온 것 같기도 한데... 주위에 많이 물어보고 다른 개발자분들도 많이 만나보고 조언도 얻어서 잘 이겨내 보자.