아무래도 이번 회고 역시 개발자적인, 개발자스러운 회고라기 보다는^^.. 전반적으로 저의 상반기를 돌아보는 글이 되겠다요(이런저런 TMI 많다는 말!)

‼️‼️‼️ 스타트 ‼️‼️‼️

2025년 상반기 어땠나요?

한줄평 수직적이라기 보다는 수평적 성장, 다채롭게 살았다 🌈

이런저런..

• 나에 대한 고민과 생각이 많았다.(특히 진로면에서) 나와 더 친해지고 나를 더 잘 알게 되었다.
• 편안한 이너서클, 느슨한 연결들이 많이 생겼다. 관계적으로 풍요로운 근황!
• 재밌고 즐거운 일들이 많았다! 전반적으로 Positive 🌟

뭐하고 살았나 !!

일, 일, 일

클라우드 프로젝트에서 새로 맡은 API 개발 업무와 함께 할 게 정말 많았다. 처음이다 보니 정신없는 것도 컸고... API 개발 업무 외에도 기존 Admin/Database 유지보수 및 추가 업무도 함께 하니, 여러모로 더 정신없어서 올해부터 노션을 알차게 활용했다. 대충 이런 식으로!

여태껏 이런 미친 정리 광공으로 살아본 적이 없다. 다만 내가 맡은 모든 업무는 메인 피처를 맡아서 개발하기 보다는, 그때그때 필요한 Admin/DB와 API들을 개발하는 것이였기에, 한꺼번에 많은 요청들이 들어오기도 해서 현황 체크 겸 필요했다. Cloud 프로젝트 외에도 다른 프로젝트도 함께 진행됐기에 더더욱! 게다가 나는 어딘가에 적어두지 않으면 디테일을 잘 까먹는 편이라 이러한 작업들이 필수적이였다.

확실히 로우레벨 언어로 개발하니 재미있는 부분도 있었다. 뭐 이런거까지 신경써야되....??? 하는 것들을? 개발자가 다 해줘야 한다는 것ㅎㅎㅎㅎ Java나 파이썬 쓸 땐 몰랐다 얼마나 개발자들에게 쉽게 떠먹여주는 환경인지^^....

메모리 관련 트러블슈팅을 직접 할 수 있다는 것도 흥미로운 포인트였다. C를 다루면서 자연스럽게 컴퓨터 구조와 운영체제를 다시 공부해봐야겠다는 생각도 들었고.. 그래서 "컴퓨터 밑바닥의 비밀" 도서 스터디 신청도 했다!

글또

상반기 역시 많은 부분을 차지해서 빼놓을 수 없다. 편안한 이너서클, 느슨한 연결들은 대체로 글또에서 맺었기 때문에..! 최근 몇달간 글또를 언급한 횟수를 세보시오 하면....ㅋㅋㅋㅋ셀 수 없이 많을 것이다,,,,(먼산

글또는 공식적으로 3/31 부로 끝났지만, 잔열은 5월 중순?까지는 계속 갔던 거 같다. 상반기는 글또에서 만난 인연들과 즐겁게 보낸 기억이 대부분이다.

어떤 것들을 하고 살았냐면:

<커피챗/소모임> (기억에 남는 것들 위주)

[진로 관련]

• 일의철학-챗
• 호명사회-챗
• 삶의 지도 다시 쓰기

[독서 관련]

..는 제가 책을 좋아하기 때문에.. 예 다 제가 벌인 일입니다!

• 낮술낭독회 아마 5회?
• 교환 독서

<스터디>

• "컴퓨터 밑바닥의 비밀" 도서 스터디
• "프로그래머의 뇌" 도서 스터디
• 코딩테스트 스터디

<놀기> 당당하게 한칸 차지하고 쓰겠다🤓 - 잘 쉬고 놀았다 !!

• 망곰's 보석함 멤버들과 제주도 여행
• 고성 발산팸
• 서울 국제 도서전

등등... 뭐가 많은데 일단 이정도.

모임 기획 및 진행

낮술낭독회 & 일의 철학-챗

낮술낭독회는 올해 들어 5번인가 했고, 각자의 커리어적 기준에 대해 나누는 일의 철학챗도 마쳤다. 두번의 경험을 통해 느낀 건 한가지는 모임을 기획하는 일이 너무*3 재밌다는 점... 그리고 두번째는 퍼실리테이션이 쉽지는 않다는 점이다.

그전까지는 대체로 남들이 짜놓은 판에 뛰어들었다면, 올해 들어선 그 판을 벌인 당사자였기 때문이다. 기왕이면 참여자들이 만족스러운 경험을 하려면 어떻게 진행하는 게 좋을지, 나는 이 모임을 통해서 어떠한 가치를 전해주고 싶은지, 모임을 기획하는 과정에 고민이 많았다.

내가 추구하는 건 깊은 대화와 이를 통한 연결, 그리고 스스로의 속마음을 털어놓음으로써 편안할 수 있는 자리였기에 각자의 생각과 가치관을 나누고 경청하는 양질의 대화를 잔뜩 나눌 수 있었다.

아쉬운 점은 나의 퍼실리테이션 역량 흑흑 모두의 이야기를 공평하게 들으면서 필요할 때는 커트하고 스무스하게 넘어가는 등, 진행에 있어서 필요한 순발력이나 센스가 살짝 아쉬웠다. 다만 이건 경험의 영역 같으니... 더 하다보면 좋아지지 않을까? 싶기도

스터디 이것저것 !

아무래도 공통 관심사를 가진 집단이다 보니, 기술 스터디에 참여하기도, 스터디원을 모으기도 수월했다. 3월부터 "컴퓨터 밑바닥의 비밀", "프로그래머의 뇌" 도서 스터디에 참여하고, 최근에 코딩테스트 스터디를 막 끝냈다.

• 컴밑비 스터디: 다양한 분야의 개발자 동료들과 함께 해서 너무 좋았던 기억!! 프론트, 백이 다 섞여있어서 챕터 2의 코루틴이라던지 비동기 관련이라던지, 내게 생소한 개념들을 알아가고 넓혀가기도 좋았다. 역시 CS는 다 연결되어 있기에 무엇 하나 소홀하게 넘길 필요 없는 것 같다고 느꼈다. 학부 시절부터 배운 개념들이 연결되며 느껴지는 카타르시스는 내게 큰 재미기에..

• 프로그래머의 뇌: 프로그래머의 메타인지를 키우기에 좋았던 책! 교양서로 후루룩 읽기 괜찮다고 느꼈다. 글또에서 친한 다른 개발자 한분과 진행했는데 가볍게 매주 읽고 이야기 나누는 식으로 진행했다.

• 코딩테스트 스터디: 6월에 각성하고(ㅋㅋㅋㅋ) 직접 모집해서 운영한 스터디다. 매주 문제 4개를 지정해서 각자 풀고, 온라인 스터디 세션에 라이브 코딩을 진행했다. 함께 라이브 코테 푸는 것도 생소하지만 좋은 경험이였다. 스터디 외에도 개인적인 일들이 많아 운영에 백프로 힘쓰진 못해서 살짝 아쉽다..!🥲

나를 더 알아갈 수 있었던 반년

강점 검사 엠베서더

강점 검사 엠버서더로서(ㅋㅋㅋㅋ) 상당히 많은 글또 친구들에게 갤럽 강점 검사를 영업하고 살았다. 그렇게 다양한 강점들을 수집하다보니 상대적으로 내가 어떤 사람인가 보이는 것들도 있어서 흥미로웠다.

나의 TOP5 강점이다. 발상이 1위일 줄은 몰랐는데... 항목들을 보니 왜 내가 회사 업무에 그다지 흥미를 못 느낀건지도 알겠더라. 새로운 아이디어를 떠올리고 흥미로운 정보들을 모으고 주도적으로 실행하는 데서 동력을 크게 얻는 편인지라, 대체로 많은 것들이 수직적으로 진행되는 환경에서 느끼는 결핍이 있지 않았나 싶다.

삶의 지도 다시 쓰기

3월 즈음 자신이 살아온 궤적을 그려보면서 스스로에 대한 이해를 높이는 "삶의 지도"를 쓰며 어떠한 삶의 가치를 추구하는지 점검해볼 수 있었다. 글또를 지원하면서 처음 쓴 삶의 지도는 다소 짧고 추상적이였기에, 이번에 각 잡고 회고해보고 싶어 다시 쓰게 되었다.

결론적으로, 나는 다른 사람과의 연결과 유대를 중시하기에 사회 일원으로써 긍정적인 가치를 주는 사람이 되고자 한다.

돌고돌아 발산 좋아

2025년 반년이 지나 8월말의 내가 내린 결론: 나는 어쩔 수 없이 발산을 해야 하는 사람이다 발산하는 게 너무나도 자연스럽고 좋기에.

아마 작년 회고에서는 수렴을 무조건적인 선으로, 수렴을 못하는 것이 나의 문제이자 곧 내가 나아가야 할 방향으로 규정지었던 것 같다. (발산/수렴이란? 참고 👉 단어 자체가 주는 이미지에 주목하면 된다. 수렴이란 다른 곁가지 없이 하나의 목표를 향해 집중하는 유형, 발산이란 와항항 즐겁다!!! 하면서 이런저런 일들을 벌이는 유형을 일컫는다.)

올해도 역시 정신 차리고 보니 발산하고 있는 스스로를 보면서 그냥 발산이 체질인 사람이라고 인정하기로 했다. 하고싶은 일도 많고 궁금한 것도 많고 벌이고 싶은 것도 많은데 어쩌겠나.. 이게 나인것을.. 글또에서 만난 친구들도 매번 판을 벌여줘서 감사하다는 인사를 받고 처음에는 얼떨떨했다. 그러다가 문득 깨달은 건 세상 어느 곳에서나 판을 벌이는 사람이 필요하다는 것이고, 내가 그러한 역할을 할 수 있다는 것이다. 인정하니 편하다.

고로 앞으로도 마음껏 발산하고 살아야지.

📚✍️

2025년 상반기 발산의 큰 축, 독서와 글쓰기

1) 독서

음... 기술/비기술, 문학/비문학 할 것 없이 많이 읽었다. 프로 병렬 독서러기 때문에 중간에 읽다가 만 책들도 꽤 된다😇..(이건 세보진 않았다) 읽을수록 느끼는거지만 독서를 단순히 여가나 취미로 치부하기에는 이로부터 얻는 것들이 너무나도 많다. 앞으로도 시간나는대로 틈틈이 읽으며 나를 더 채워가고 싶다.

함께 자라기, 일의 철학, 긴긴밤, 호명사회, 창조적 행위, 2025년 젊은 작가상 수상작품집, 슬픔을 공부하는 슬픔, 불안한 완벽주의자를 위한 책, 작별하지 않는다, 자신의 존재에 대해 사과하지 말것, 불온한 검은 피, 자기 결정, 단순한 열정, 에디토리얼 라이팅, 면접의 질문들, 밤에 생긴 상처, 적산가옥의 유령, 에디토리얼 씽킹

혼자 읽기도 좋지만 같이 읽는다면?

글또...얘기는 끝난 줄 아셨죠? 통탄스럽게도 글또에서도 내가 좋아하는 걸 같이 하자고 끌어들이기를 많이 했다(ㅋㅋㅋㅋ)

인스타에서 우연히 "교환 독서"라는 형태의 독서 모임이 유행하는 걸 알게 되었다. 각자의 책을 돌려읽으며 마음대로 낙서하고 표시하며 읽는 형태의 모임이다. 보자마자 '나도 주변 지인들과 하고 싶억!!!!'하는 마음이 들어서 글또에서 친하고 편해진 사람들과 함께 진행했다. 나를 제외한 모두가 J였기에 다소 스무스하게 착착 진행됐다. 또 다른 형태의 유대감을 느끼기 좋다 매우 강추...

2) 글쓰기

5월부터 8월까지 전부터 존경하는 작가님의 글쓰기 수업을 듣게 되었다. 총 세 편의 에세이를 쓰고 합평하고 퇴고하는 식으로 진행되었다. 마지막 수업에서 작가님께서 내 글이 많이 발전했다고 칭찬해주셨는데, 그 말이 왜 그리 뿌듯한건지! 아마도 그만큼 글에 대한 애착을 가지고 임해서겠지.. 그렇게 세 편의 에세이가 모두 끝난 현 시점에서 드는 욕심은 "글을 더 잘 쓰고싶다"는 것이다. 앞으로도 나의 글을 더 발전시키기 위한 노력을 더 할 것 같다. 나름 인스타에서 부계정 만들어서 순간순간 떠오르는 짤막한 글들을 올리고 있는데, 앞으로도 생각날 때마다 올려야겠다.

나를 알아가는 건 즐겁다

이런저런 발산을 통해 크게 느꼈다. 독서를 하며 느끼는 다채로운 감정, 글을 쓰며 추상적인 것들을 실체화하기, 깊은 대화를 통한 연결 등, 역시나 올해도 생각지 못한 방향과 방식으로 발산하며 느낀 건 즐거움이다. 여느 썸이 그렇듯 나를 알아가는 것 역시 설레고 즐거운 일이 아닐 수 없다!

남은 2025년은 어떻게 보내고 싶나요?

아무래도 이렇게 이런저런 일들을 벌였으면 다른 덴 소홀할 수밖에 없다. 내게 있어서 그건 실제적인 이직 활동이다. 앞으로는 조금 더 이직 준비와 현재 참여 중인 오픈소스 컨트리뷰션 활동에 집중할 것 같다. 밸런스를 잘 잡고 실제적인 아웃풋을 낼 수 있는 2025년이 되기를!!🙏

읽게 된 계기

이 책이 왠지 아른거린 건 회사에서 API를 짜는 새로운 업무에 착수하면서 부터다. 기한 내로 낯선 코드를 참고해서 작성할 일이 많았기에, 주요 관심사는 "어떻게 하면 거대한 코드베이스를 효율적으로 리딩하고 이를 활용해 코딩할 것인가"였다.

취업하기 전에 학교 과제나 사이드 프로젝트 코딩할 땐 직접 제로부터 쌓아올리는 경우가 많았어서, 남이 짠 코드 리딩에 대한 고민을 크게 해보지 않았다.

회사에 입사하고부턴 거대한 코드베이스가 주어졌고 이를 파악하고 적절한 모듈들을 적절히 활용해서 코드를 작성하는 능력이 중요했다. 게다가 교환기라는 특수한 도메인을 다루기에 검색해도 뭐가 안 나오기에 주어진 리소스를 잘 활용해야 한다는 니즈가 컸다. (ex.2025년 근속한 아젓시들께 붙잡고 질문한다던지 .. 붙잡고 질문한다던지22.. 근데 이것도 한계가 있지🥹)~~

짧은 후기

프로그래머로써 코드를 읽고 작성하는 전반적인 단계에서의 메타인지를 키우기에 유익했던 책이다.

유익한 부분 가져가기

LTM 강화 연습

STM, LTM, 작업 기억 공간의 상호 보완

코드를 작성하고 읽는 과정에서 STM, LTM, 작업 기억 공간이 모두 동원되어 상호작용한다.

STM: 단기 기억 효율적으로 하고 있는가? 임시 저장소, 빠른데 용량 작은 캐시같은 것 LTM: 오랜 시간에 걸쳐 얻은 정보를 저장하는 장기 메모리

• LTM의 두가지 기제 : 1) 저장, 2) 인출
• 인출 강도의 문제일 수 있다

작업 기억 공간: 두뇌의 처리 능력, 실제 사고 과정이 이루어는 곳

이 중에서 개인적으로 LTM 강화의 필요성을 느꼈다.

돌고돌아 공부의 근본은 변하지 않나..라는 생각을 한 챕터. 아무리 AI가 판치고 검색하기 쉬운 시대라지만, 결국은 내가 흡수한 내용을 잘 꺼내 활용하는 것이 관건이기에 - LTM을 강화하려는 노력을 계속해야겠다(=열공하잔 말)

이를 위해 인출 연습과 정교화를 적극적으로 활용해볼 수 있다.

• 인출 연습: 검색하기 이전에 능동적이고 의도적으로 기억하려 노력, 플래시카드를 사용해서 연습

• 정교화: 정보에 대해 능동적으로 생각하고 그것을 반추해보는 것

  • why? 기억은 네트워크 형태기 때문 (스키마)

참고

코딩 작업 시 인지 분석

LTM, STM, 작업 기억 공간을 배우고 이를 바탕으로 나의 인지를 크게 쪼개보고 싶었다. 회사 코드 볼 때 어려움을 겪는 포인트가 구체적으로 어떤건지 궁긍해서 데이터베이스 쪽 코드 작업할 때의 인지를 분석해보았다. 확실히 어떤 영역의 보충이 필요한건가, 스스로의 인지 과정이 구조화하니 좋단 생각이 들었다(메타인지의 힘-🌟)

프로그래밍 중 이루어지는 활동

검색 ⭐️

STM 활용, 노트테이킹 도움(검색 단계 적어두기)

이해 ⭐️

전사

LTM 활용 -> 생각해보니 확실히 부족한 C 문법에서 어려움을 겪음 (대표적으로 포인터 관련)

증가 ⭐️

검색, 이해, 전사가 합쳐진 활동

코드베이스나 언어가 생소한 경우라면 증가 작업이 어려울 수 있다

👉 거의 뭐 내가 힘들었던 포인트 공감받은 기분🥹 이 경우 여러개의 작은 작업으로 분할하면 좋다고 함

탐구

중단에 잘 대비하는 방법

• 정신 모델 저장 : 주석 활용해서 군데군데 정신 모델을 적어두는 게 도움된다

"주석문의 배후에 놓인 전반적인 아이디어는, 설계자의 마음속에는 있었지만 코드로 표현할 수 없었던 정보를 포착하는 것이다"

👉 코드만으로 설계자의 정신 모델을 따라갈 수 없다는 점에서 공감갔다. 10년이 훌쩍 넘어가는 사내 소스 코드 같은 경우, 맥락을 따라잡기 위해 주석으로 보충 설명되어 있을 때 도움됐다.

• 미래 기억 향상 : 미래의 TODO 적어두기

• 하위 목표 라벨 붙이기 : 문제를 어떤 작은 단계로 나누고 명시적으로 기록

회고

✍️ KEEP : 읽으면서 공감하고 이대로 꾸준히 가져갈 부분 TRY : 새롭게 알게 된 사실, 츄라이 해봐야겠다!👀

업무 중 많이 일어나는 활동에 ⭐️표를 해두었는데, 흐르듯이 하던 업무 활동을 이렇게 분해해서 보니 현재 어떤 부분은 잘하고 있는지, 부족한 부분은 뭔지 가시화할 수 있어 좋았다.

⬛️ KEEP

느낀 점: 업무에 있어서 뭐든 많이 적는 습관은 마이너스 될 게 하나 없다 !!

• STM 지원 위해 검색 중 중간중간 노트테이킹
• 코드베이스 & 언어가 생소 -> 여러 개의 작은 작업으로 분할
  • 도메인+언어가 생소하면 압도되기 쉬운데, divide & conquer 한다는 마음가짐으로 보다 작은 작업으로 분할해서 접근하는 게 도움됐다
    • 중단에 대비하는 측면에서도 굿
• 이해 과정에서 모르겠는 맥락(추론이 들어가는 부분)은 당시의 정신 모델 틈틈히 기록 (이렇게 적어두면 질문하기에도 좋다)

⬛️ TRY

LTM 강화하기 위한 학습 (10장 참고)

• 전사 과정에서 포인터 활용과 같은 C 문법은 인출해서 활용하는 과정에서 어려움 느낌.. 보충 학습 필요

코드베이스의 인지 차원 (CDCB)

이 부분을 인상깊게 본 건 특정 코드베이스를 객관적으로 평가하는 지표의 필요성을 느껴서다.

코드베이스에 관한 CDN (인지적 차원 표기) : 특정 차원이 무조건적으로 마이너스/플러스라기보단, 하나의 설계 기동으로 하나의 차원을 높이면 다른 차원이 낮아지는 트레이드 오프가 있다고 이해했다.

ex. 회사 코드 베이스 평가

• 오류 경향성 낮음 (아무래도 강타입 언어다보니)

반대로,

• 잠정성 낮음 : 프로그래밍 언어 자체의 엄격함으로 인해 코드를 사용해 생각을 표현하는 건 어려움
• 점도 높음 : 코드 변경 후 컴파일 및 테스트 실행에 시간 오래 소요
• 점진적 평가 차원 낮음 : 완료되거나 완벽하지 않은 코드 실행 불가
• 매핑 근접성 높음 (도메인 이해 필수적) 👉 초반 진입 장벽이 높은 이유가 되기도

차원이 활동에 미치는 영향을 고려

이러한 인지 차원이 주로 하는 프로그래밍 활동(검색, 이해, 전사, 증가, 탐구)과 어떠한 연관성이 있는가?

앞으로 프로그래밍 활동을 할 때, 어떤 점에서 어려움을 겪는지 이해할 수 있는 인지적 툴이 될 거 같다.

코드베이스가 유지되는 동안에는 코드베이스에 대해 일어날 가능성이 가장 높은 활동에 맞는 설계 기동이 필요할 수 있다

이 대목이 기억에 남는데, 특정 차원을 늘리는 방향으로 설계 기동을 가져갈 때, 주로 일어나는 활동을 고려해서 변경하는 게 맞다는 걸 배웠기 때문이다.

오래되고 안정적인 회사 코드베이스의 특성상, 검색 활동이 주로 일어나므로 낮은 오류 경향성과 높은 일관성을 지키는 방향으로 설계 기동을 가져가는 게 나은 방향일 수 있다고 느꼈다.

책에서 언급된 참고해볼만한 자료들

<<오픈소스 소프트웨어 아키텍처>> 에이미 브라운, 그레그 윌슨 <<500 Lines or Less>>, 마이클 디베르나도

코드가 어떻게 돌아가고, 메모리는 어떻게 구성되어 있으며, CPU는 무얼 하는지 등, 추상화를 한꺼풀씩 벗겨가며 로우레벨에서 뭐가 어떻게 동작하는지를 보여주는 책이다.

읽게 된 계기

컴공 전공하면서 나름 이 세계에 발을 들인지도 9년이 되었지만(이렇게 말하니까 뭔가 대단해보이지만..) 전체적인 그림을 아직 못 보고 있다는 답답함이 항상 서려 있었다🤔 컴퓨터 구조, 운영체제, 네트워크 등 CS 학습 자체는 재미있어 했기에 단편적인 지식들은 열심히 주입했다만.. 그래서 이게 전체적으로 어떻게 맞물려 돌아가는걸까? 하는 궁금증. 그러던 중 우연히 글또에서 스터디원 모집한다는 글을 보고 덥-썩 들어갈 수밖에!

추? 비추?

👍👍 강추!! 👍👍

저자가 워낙 비유를 잘 들어가며 스토리텔링을 맛깔나게 하기 때문에 비전공자도 쉽게 읽을 수 있지 않을까 싶다.

쭉 읽으면서 전체적인 그림을 그리기에 정말정말 좋다고 느꼈다 ... 현재는 CPU를 다루는 챕터 4를 읽고 있는데, 전에 배웠던 게 이거구나~ 반갑고 퍼즐 조각이 맞춰지는 기분 !!

👇👇 저자만의 유머 코드도 살짝 어이없고 웃기다 👇👇

이 글의 구성

🌱 전체적인 그림을 그려볼 겸 스스로 정리하는 글이라 구체적인 개념은 간단히 넘어갈 예정

🌷 관통하는 키워드를 하나 뽑자면 추상화다. "가상 메모리란 무엇인가?"와 같은 지엽적인 용어보다는 가상 메모리가 어떠한 문제를 해결하기 위해, 어떠한 맥락에서 나왔지?를 위주로 보기를 추천한다

1장

• 프로그래밍 언어
• 코드에서 실행 파일까지
  • 컴파일러
    • 링커 (보충 예정 👀)

2장

• 주요 개념 설명
  • 운영체제, 프로세스, 스레드, 코루틴
  • 콜백 함수, 동기/비동기, 블로킹/논블로킹 (보충 예정 👀)

추상화

개발자들은 컴퓨터의 비밀을 모조리 알아서 코딩할 수 있는 게 아니다.

천공카드 뚫던 조상님들부터 열심히 고민한 결과로, 우린 내부 구현을 몰라도 "활용"하는 데 이상 없다. 이 책이 핵심 테마로 가져가는 "추상화"는, 결국 잘 포장된 겉껍질을 하나씩 까보며 실제 구현을 살펴보는 과정이다.

추상화를 넘어선다는 건, 본질을 파고드는 질문들에서 출발한다:

머신 코드에서 어셈블리어로의 점프는 어떻게, 왜 일어났을까?

Operating System이 왜, 어떤 필요에서 만들어졌을까? 개발자가 이걸 다 관리하려면 무슨 일이 벌어지길래?

실제로 CPU가 할 수 있는 것은? 그러기 위해 어떠한 형태로 코드를 읽어들여서 프로세싱하는걸까? 그렇다면 메모리랑은 어떻게 협력하는걸까?

1장

고급 프로그래밍 언어

저수준 언어와 고수준 언어의 구분을 먼저 깔고 가자.

인간이 이해할 수 있는 고수준 언어는 추상적이라면, 기계가 이해할 수 있는 저수준 언어는 구체적이라는 차이점이 있다.

컴퓨터를 우리가 원하는 방식으로 동작시키기 위해 이러한 갭을 메워야 할 것이다. 이를 위해 코드는 어떻게 발전해왔을까?

저수준이 이해할 수 있는 구체적인 언어에서 일련의 규칙을 발견해 구문이 만들어진다. 여기서 재귀와 같은 수학적인 개념들이 합쳐져, 트리 형식으로 표현할 수가 있었고, 이는 구문 트리로 표현할 수 있다.

코드에서 실행 파일까지

우리가 입맛에 편하게 작성된 소스 코드는 컴퓨터가 이해할 수 없다.

저수준에서 이해하고 실행하기 위해서는 기계어 0과 1로 구성된 실행 파일이 나와야 하고, 여기서는 프로그래밍 언어로 작성된 소스 코드에서 하나의 실행 파일이 나오기까지의 과정을 다루고자 한다.

Step 1) 컴파일러

자, C/C++, Java와 같은 프로그래밍 언어로 짜여진 코드가 있다. 이를 컴퓨터가 씹고 맛보기 편한 형태의 기계어 코드로 변환하기 위해 어떠한 과정을 거칠까?

전체적인 플로우 요약:

코드 구문 분석 👉 구문 트리 만들기 👉 이를 기계 명령어로 번역 👉 CPU or 가상머신으로 👉 실행

여기서 컴파일러가 역할을 수행한다.

컴파일러는 고수준 언어를 저수준 언어로 번역하는 프로그램이다.

대충 어떤 일들을 하는지 보면: (그냥 이러한 일련의 과정을 통해서 최종적으로 기계어로 변환되는구나 보면 된다)

1. 토큰 추출 (어휘 분석, lexical analysis)

   소스 코드에서 토큰 추출

2. 구문 분석 👉 구문 트리 생성

   

3. 의미 분석 (semantic analysis)

   생성된 구문 트리에 이상이 없는지 검사

4. 중간 코드(Intermediate Representation Code) 생성 (뭔진 잘 모르겠고 이런 게 있다고 한다)

5. 최종 코드 생성

   중간 코드 -> 어셈블리어 코드 변환, 이를 기계 명령어로 변환

Step 2) 링커

컴파일러를 거치면 여러 개의 대상 파일이 생성되어, 링커는 이를 하나의 최종 실행 파일로 묶는 작업을 수행한다.

2장

핵심 추상화 개념. 운영체제, 프로세스, 스레드, 코루틴

프로세스 & 운영체제

프로그램 코드를 실행하는 CPU의 입장에서 보자. 이 친구는 프로세스니, 스레드니 모르고 그져 명령어 하날 가져와서 실행할 뿐이다(dispatch -> execute) 정확히는 PC 레지스터가 프로그램의 시작 주소를 가리키며 한줄씩 실행된다.

프로그램을 실행시키려면 프로그램을 직접 적재하는 등, 그 과정에서 처리해야 할 태스크가 많다.

하나의 코어에서 여러가지 프로그램을 실행시키기 위해서는 여러개의 프로그램 사이에서 빠르게 전환시켜야 하고, 이에 따라 실행 중인 프로그램을 "관리"해야 할 필요성이 생긴다. (->멀티태스킹)

그래서 나온 게 프로세스(process)다. 추상적으로 생각할 것 없이 실상은 프로그램 실행 상태를 저장하고 복구할 때 쓰는 구조체다.

✔️ 그렇다면 운영체제는?

프로그램 적재해주는 적재 도구, 멀티태스킹 실현해주는 프로세스 관리 도구 등, 개발자가 실행 중인 프로세스가 몇 개인지, CPU가 몇 개인지 신경 쓸 필요없이 작업할 수 있도록 background에서 지원해준다.

스레드

CPU 여러개가 동일한 프로세스의 기계 명령어를 실행하도록 하려면? PC 레지스터가 다른 함수를 가리키게 함으로써 새로운 실행 흐름을 형성할 수 있고, 이를 스레드라고 부른다.

다중 스레드 구조에 따라 메모리 구조는 어떻게 달라질까? 실행 흐름이 여러개 존재하는 만큼, 아마 스레드별 저장해야 할 context가 따로 있을 것이다. 결국 모든 스레드는 각자 자신만의 스택 영역을 가지게 된다.

제어가 어디 있는가?의 관점에서 스레드 vs. 코루틴

여기서 말하는 스레드는 커널 스레드로, 운영체제가 관장하는 것이다. 즉, 프로그래머가 그 생성과 스케쥴링에 관여할 수 없다.

운영체제에 의존하지 않고 직접 스레드를 구현하려면 코루틴을 통해 가능하다.

코루틴

이제 제어권이 개발자에게 넘어갔다. 이걸 왜 사용하는 것이며, 어떤 맥락에서 필요한걸까?

실질적으로 코루틴이 어디에 쓰이는지, 스터디 시간에 듣기로는 종종 싱글 스레드에서 흐름을 관리할 때 활용한다고 한다. (ex. IO 인터럽트 발생 시 어떻게 동작할지? 흐름 관장)

일반 함수와 다르게 이전에 마지막으로 실행된 위치를 알고 있어, 다시 실행될 때 이전에 일시중지된 지점에서 계속 실행이 가능한 특이한 함수다.

코루틴의 중요한 역할 중 하나는 개발자가 동기 방식으로 비동기 프로그래밍을 가능하게 한다는 것이다. (아마 이 말을 처음 듣는다면 대체 무슨 말인지 알아듣기 힘들 것이다. 다음 파트에서 계속 >.0)

이 글은 글또의 어느 커피챗 중독자 A양에 관한 이야기 입니다.

그녀는 대체 어쩌다가 이러한 삶을 살고 있을까요?

커피챗이 대체 뭐길래?

잠깐, 커피챗이란?

본래 커피챗(Coffee Chat)이란 커피를 마시며 가볍게 대화하는 자리로, 흔히 정보 공유를 위한 네트워킹 자리라는 의미로 통용됩니다.

글또에서는 이런저런 커피챗이 열리곤 합니다. 함께 모여 김장을 하는 김장챗부터(ㅋㅋㅋ) 여러 동민들이 모여 이야기 하는 동민챗 등, 흔히 생각하는 일대일 정보성 커피챗 외에도 다양한 사람들을 만날 수 있는 기회가 열려 있습니다.

이 글에서는 단순한 정보 공유를 넘어, 온·오프라인에서 이루어진 다양한 활동까지 포괄하는 넓은 의미로 사용했습니다.

그녀의 커피챗 목록

독자들의 귀에서 피가 나는 불상사를 방지하기 위해 41개를 일일이 나열하기 보다는 주요 카테고리로 묶어보았습니다. 2024년 10월부터 2월 말까지의 기록입니다.

[독서 모임]

• 낮술낭독회 4회
• "호명사회"챗 2회 (진행 중)
• "함께자라기"챗 1회
• 타 독서모임 1회

[회고 모임]

• 크리스마스 회고 모임
• 일의 철학 모임 ('일의 철학'이라는 서적을 읽고 각자의 커리어 기준들을 나누는 모임)

[백엔드 모임]

• 백엔드 인프라 반상회
• 백엔드 코어 채널 커피챗
• C/C++ 개발자 커피챗

[일대일 정보성 커피챗]

3회

[기타: 잘 놀았던 모임]

여러 소모임 채널에서 열린 모임들도 활발히 참여했습니다.

• 뮤직스타또 음감회
• 쓸모또 캠프파이어
• 다진마늴또
• 운동해또 요가챗

등등 ..

[기타: 벙개 모각글 n회]

달력에 없는 것도 있고 안 세보았다 !!

이 글을 쓰는 이유

지금까지 읽은 여러분, 수고 많으셨습니다.

지금까지 읽었을 때 '저 여성... 커피챗에 여간 미쳐있는 게 아니구나', 이런 인상 정돈 받았을 거 같아요.

"나 커피챗 많이 했다 !!!!!!!" 자랑하기 위해 글을 쓴 건 아닙니다.

지금부터 글또의 커피챗 문화에 깊이 연루될 수 있었던 주 요소에 대해 말씀드릴까 해요.

우연의 힘에 대하여

필연과는 달리 우연에는 이런 주술적 힘이 있다. 하나의 사랑이 잊히지 않는 사랑이 되기 위해서는 성 프란체스코의 어깨에 새들이 모여 앉듯 첫 순간부터 여러 우연이 합해져야만 한다. -"참을 수 없는 존재의 가벼움" 중-

아무 생각 없이 "놀러"간 자리에서 새로운 기회들을 마주하고 또 다른 경험과 깨달음들로 이어지곤 했습니다. 이로부터 커피챗의 커다란 장점은 단순 정보 얻기가 아닌, 수많은 우연들을 만나 새로운 기회로 연결되는 경험이라는 걸 느꼈습니다.

음감회에 나가면 음악만 함께 감상하고 끝날까요?

독서 모임에 나가면 책 이야기만 나누는 게 다일까요?

모각글에서는 다같이 시너지 내서 공부하는 데서 마칠까요?

지금부터 몇가지 사례들로 스스로 어떠한 기회들을 마주하고 그로부터 어떻게 새로운 경험들로 스스로를 확장할 수 있었는지 들려드리겠습니다.

음감회에서 C/C++ 커피챗, 그리고 로우레벨 소모임을 만들기까지

각자의 음악 취향을 다양하게 듣고 이야기를 나누는 음감회에서 어떻게 로우레벨 소모임을 만들기까지 이어졌는가?

우연히 음감회 끝나고 집 가는 길에 C 개발자인 S 님을 전에 모각글 커피챗에서 만나 알게 된 M 님으로부터 소개 받았습니다.

제가 몇 없는 C 개발자라서 S 님이 일대일 커피챗을 하자고 요청을 주셨고, 여기서 글또에 몇 없는 C/C++ 개발자들을 모아서 열어볼까?라는 아이디어로 이어져서 모집글을 올리게 되었습니다.

당시 커피챗에서 공통적으로 공감한 부분은 "로우레벨 종사자가 참고하고 활동할 수 있는 커뮤니티가 적다"는 점이였습니다. 이로부터 로우레벨 언어 종사자들이 다양하게 정보를 공유할 수 있는 공간이 있으면 좋겠다는 니즈를 조금이나마 해소하고 싶어 "로우레벨도 있또" 소모임을 만들게 되었습니다.

모각글로부터 책읽어또, 그리고 낮술낭독회 시작하기까지

책과 글 쓰기 모임의 공통 분모는 꽤 큰 거 같다는 예감에서 낮술낭독회를 열기로 결심하다

누구에게나 "처음"은 중요합니다.

처음 이수역에서 연 모각작에서 만난 글또 사람들과 "결이 비슷함"을 느끼고 편안하고 즐거운 시간을 보낸 기억이 남아 있습니다.

책 읽고 이야기 나누는 걸 좋아하지만, 이러한 취미를 공유할만한 또래 친구들이 없었습니다. 그렇게 갈증을 안고 있던 중, 모각작에서 책을 좋아하는 분들을 만나 "책 읽어또"라는 채널을 소개받아 또 다른 독서가들을 잔뜩 만날 수 있었습니다.

그렇게 글또에 머물면서 글을 쓰는 사람과 책 읽는 사람과의 공통 분모는 꽤나 크다는 느낌으로 이어졌고, 이는 곧 제가 은밀히 품고 있던 독서 모임인 "낮술 낭독회"를 시작하는 계기가 되었습니다.

약 2017년도부터 구독한 제 최애 유튜버인 '유즈'입니다. 지인들과 함께 낮술과 함께 각자의 책을 소개하고 각자에게 인상깊은 부분을 낭독하는 '낮술 낭독회'라는 기획에 바로 반했습니다. 애독가들이 잔뜩 있는 글또 사람들을 만나면서, 조용히 품고만 있던 아이디어를 실현시킬 수 있었습니다.

낮술낭독회에서 만난 인연들과 또 다른 독서모임 양산 중인 근황

'끼리끼리는 사이언스'라는 말이 있습니다. 비슷한 사람들은 비슷한 사람들을 알아보고 어울리게 된다는 말인데, 책을 좋아하는 사람들과 또 다른 독서 모임을 양산하게 되는 현상을 발견하고 이를 체감했습니다.

저는 책을 읽든 사람과 대화하든, 하나로 관통되는 이유에서 좋아합니다: 제 세계가 확장되는 느낌을 받거든요.

"나의 세계에서 살아간다"는 한계를 깨고 다른 세계를 간접적으로 맛볼 수 있다는 점에서 책과 대화를 좋아합니다. 그래서 이토록 독서 모임 중독일지도 모르겠네요.

책과 대화를 좋아하는 다른 글또 인연들을 만나 또 다른 독서 모임으로 이어지는 경험을 하면서, "기호"로 연결된 커뮤니티가 자연스럽게 형성되는 재미를 느꼈습니다. "호명사회"챗과 같은 경우, 송길영님의 강연을 흥미롭게 보고 올린 스토리에서 E님이 독서 모임을 제안해서 시작하게 됐습니다. 이와 같이 유사한 흥미와 관심사를 가진 사람들을 만나게 되니, 책과 대화를 통해 인사이트를 얻는 모임을 접할 기회가 더욱 많아졌습니다.

프로 발산러가 재정의한 커피챗이란

최근 글또에서는 하고 싶은 게 정말 많고 일을 잘 벌이는 사람을 일컬어 "발산러"라고 부릅니다. 자꾸 새로운 일을 벌이는 프로 발산러에게 커피챗이란 무엇인가 이번 기회에 재고해보았습니다.

정리해보니 크게 세가지 키워드가 맞물려 있는 걸 발견했습니다.

재미

제게 있어서 글또 커피챗의 가장 큰 1번은 "재미"입니다.

단순하게 말할께요 - 그냥 정말 웃깁니다. (궁서체)

글또 커뮤니티 내에서도 다채로운 드립의 향연이 펼쳐지는만큼, 오프라인에서도 마냥 웃길 때가 많습니다. 종종 글또 분들과 만날 때 웃다가 눈물 난 경험이 많았기에, 커피챗을 참여한만큼 일상적인 행복도가 컸습니다.

이러한 "재미"는 단순 쾌락적인 유희 뿐 아니라, 공통된 관심사를 주제로 실컷 이야기할 수 있는 장에서 느끼는 편안함과 즐거움도 큰 몫을 차지 합니다. 각각의 관심사와 필요에 따라 다양한 소모임이 있는만큼, 각자가 지닌 취향들을 다채롭게 찍어먹고 확장하는 데서 얻는 재미가 컸습니다. (ex. 그림을 좋아하는 채널에서 전시 모임 참여하기, 피크민또 채널에서 같이 특정 피크민을 잡으러 가기)

배움과 성장

글또 사람들을 가장 큰 공통점은 "성장"에 관심이 많다는 것입니다.

각자 oo를 어떻게 더 잘할 것인가? oo 능력을 어떻게 키울 것인가?에 관심이 많은만큼, 커리어적 관점에서 어떻게 더 성장할 것인가?라는 공통된 관심사로 이야기를 나눌 수 있다는 점이 가장 좋았습니다.

개인적으로 일에 관한 고민이 컸을 때, 프로페셔널리즘에 관한 책을 추천해달라는 글을 올린 적이 있습니다. 총 25권의 책을 추천 받으며, 이러한 커뮤니티에 속해 있어 감사하고 안도가 되었습니다.

연결과 공감

공통 관심사를 기반으로 연결되고 공감되는 경험은 지속할 수 있는 힘이 되어줍니다.

얼마 전 "호명사회"챗 멤버들에게 모임의 내용과 직접적으로 관계 없는 글귀와 시를 공유하고 나서 긴 감상문을 처음 받고 놀랐습니다. 이렇게 하나의 매개체로 각자의 생각을 끌고 와서 다양한 이야기로 확장되고 깊게 연결되는 경험을 할 수 있다는 점까지, 정리하고보니 저의 커피챗 중독증이 왠지 이해가 됩니다 ◠‿◠

결론

단순 "효율주의"나 "목적주의"로는 환원되지 않는, 알지 못한 우연적인 요소들이 뒤섞여 예상치 못하게 또 다른 재미나 의미로 연결됩니다.

처음에는 저도 커피챗은 "정보 알아가기", "함께 작업하기"와 같은 소정의 목적을 달성하기 위한 수단 정도로 생각했습니다. 그러나 경험하면 할수록 말로는 전달하기 힘든 함의가 숨어 있다는 걸 느꼈습니다.

막상 책 이야기 하자고 모인 독서 모임에서 책 이야기는 5%로 끝나고, 기억도 안 날만큼 이런저런 이야기들을 하며 새로운 인연들을 만나 이어질 수도 있습니다.

즐기자고 가볍게 만난 모임에서 멋지고 발전적인 사람을 보고 깊이 내재되어 있던 불만족이 꿈틀대고 나아가는 힘으로 작동할지도 모릅니다.

커피챗?🤔 굳이?🤔라고 생각하는 분들이 있다면

할 것도 많은데 굳이 커피챗? 만나서 굳이 왜 공부를? 이렇게 생각하는 분들도 간혹 있지 않을까 싶습니다.(먼 과거의 제가 그랬거든요)

단순 하나의 목적성에 가두고 생각지 않으셨으면 합니다.

오늘 예상치 못한 만남에서 어떠한 배움이나 깨달음으로 이어질까? 어떠한 새로운 기회들을 얻을까? 이러한 기회들은 또 나를 어디로 향하게 할까?

사실 아무도 모릅니다. 그런데 그 불확실성이 꼭 나쁘기만 할까요?

예측 불가하고 통제 불가능한 매일매일 속에서 파도를 타보셨으면 합니다. 혹시 압니까? 이 파도는 또 나를 어디로 데리고 갈까요?

1월 초중순부터 현재까지, 그리고 앞으로 몇달간 바빴고, 바쁘고, 바쁠 예정입니다. 정신없이 달려가는 와중에 현재의 어려움을 기록하고 이를 어떻게 타파하는 게 좋을지를 주제로 글을 써야겠다는 생각을 했습니다.

구성

최근 몇달간 느낀 현실적인 어려움들 👉 그래서 이 사태를 어떻게 헤쳐나가는 게 좋을까? (궁서체)

Target

나

저는 항상 제가 쓰고 싶은 글을 쓰는 듯 합니다. (본질적으로 제 니즈를 충족하고 저의 만족이 큰 글을 쓰려고 해요)

현재의 상황 분석과 이를 어떻게 해결하고 있는지, 그리고 앞으로 어떻게 나아가고 공부하는 게 좋을지 중간 스냅샷을 찍고자 합니다.

(저와 같은 우당탕탕) 저연차 개발자

글또에 올라오는 커뮤니티 글을 읽다가 가장 강하게 든 생각 한가지는, 모두가 불안하고 내가 잘하고 있는걸까? 걱정하고 있다는 점입니다.

이 글을 읽는 당신이 혼자가 아니라는 위로와 힘이 되기는 바라는 마음에서 끄적여봤습니다 💪

이 밖에 다양한 개발자들

이런저런 조언, 공감/위로, 실용적인 피드백 전부 환영합니다.

최근 몇달간 느낀 현실적인 어려움들

주요 문제 요약

1. 한꺼번에 들어오는 여러가지 업무 요청
2. 도메인 지식이 부족한 와중에 스펙 작성해야 한다(?!)
3. 번거롭고 비효율적인 작업들

한꺼번에 들어오는 여러가지 업무 요청

현재 진행 중인 프로젝트 A, B에서 맡고 있는 주요 업무 대분류입니다:

Project A (1) API 개발 (2) DB 및 Admin 애플리케이션 코드 작성

Project B (1) API 개발 (2) DB SQL 쿼리 작업

< 주요 문제 >

현재 프로젝트 A와 프로젝트 B가 함께 진행되고 있는 상황입니다. 1월부터 프로젝트 A와 B로부터 여러가지 업무가 생기고 요청들이 한꺼번에 들어오기 시작하면서 혼란한 몇주를 보냈습니다.

ex. A의 xx API 개발, A의 xx 기능 DB/Admin 코딩, 장기 프로젝트 B의 API spec 작성 등등등

< 처음에 든 감정과 내가 문제를 풀어간 방식 >

이러한 혼돈을 마주하며 처음 든 감정은 패닉 그 자체입니다.

• (난 이 업무를 처음 해보는데) 일정 산정..을 어떻게 하지 ???
• 쏟아지는 업무들 속에 우선순위가 어떻게 되지 ???

이러한 두가지 문제로 저는 어떠한 업무부터 처리하는 게 좋을지, 어떠한 프로젝트의 우선순위가 높은지 각 프로젝트의 PL과 팀장님과 함께 논의하고 나름대로 우선순위를 산정해서 작업하기 시작했습니다.

여러가지 요청과 테스크를 처리하기 위해 (프로세스 스케줄링이라는 약간의 컴퓨팅적 사고를 가미해서) "업무 큐"라는 저만의 템플릿을 만들어 개인적으로 관리 중입니다.

< 이에 따라오는 문제들 >

1. 프로젝트 여기저기 걸쳐져 있다보니, 한두가지 업무를 하더라도 따라오는 잔가지 질문들이 많습니다. 주요 테스크를 처리하는 와중에 들어오는 잔가지 요청 처리가 쉽지 않다고 느껴집니다.

👉 컨텍스트 스위칭의 어려움

2. 기술을 “잘” 쓰는데 집중할 시간없이, 우선 일정 내로 완성하기 위해 업무 쳐내기식으로 코딩하는데서 오는 스트레스

음 .. 이대로 가면 ... 휴먼 에러가 많을 수 밖에 없는데 ??? 이대로 괜찮나 ????

< Action Point >

[Action] PCB(Process Control Block) 관리에 더 힘쓰기..!

• 이미 어느정도 꾸준히 기록하고 있지만, 꾸준히 힘써서 태스크 현황을 관리하고자 합니다
• 어디까지 고민해봤고, 어디까지 했다, 그래서 앞으로 TODO는 이러한 것들

[Action] 버그 줄이기

• 나름대로의 테스트 방식 고민 필요, memory leak 검사
• 일지 정리하면서 버그도 따로 관리하기

도메인 지식이 부족한 와중에 스펙 작성하고 있다(?!)

쓰고보니 웃긴 한 문장인 것 같지만 사실입니다. 현재 주요 업무인 A-1를 처리하는 데 가장 큰 문제기도 합니다.

< 배경 설명 >

1년 넘게 팀에서 일하면서 느낀 주요한 어려움은 제품의 historical context가 길고 방대한 와중에, 이를 학습하고 따라잡기 힘들다는 부분입니다. 수석님들이 가장 오래 다뤄오면서 히스토리를 가장 잘 알고 있기에, 그 분들의 지식에 의존해야 하는 측면이 큽니다.

이러한 Context 공유의 부재가 크지만, 개인으로써 어떻게 해결할 수 있는지 여전히 고민스럽고 막막한 부분이기도 합니다.

< 다시 문제로 돌아가서 >

현재 프로젝트의 작업 플로우상 API를 빠르게 개발하고 전달줘야 하는데, API 담당자인 제가 기능을 제일 모른다는 무서운 상황입니다.

'잘 모르는데 네이밍은 어떻게 지어야하는지? 어 그런데 내가 명세 작성자잖아❕'

파트장님과 팀장님께 문제를 말씀드렸을 때, "해당 기능 담당자들에게 물어보라"는 답변을 얻어서 최대한 물어보면서 일하고 있습니다. 현재 진행형으로 이러한 방식으로 업무를 처리하면서 느낀 점은, 결국 본질적인 큰 그림을 그리지 못하는 상황에서 오는 답답한 지점들이 많다는 점입니다.

장님이 코끼리 만지는 격으로 진행하고있다보니, 여기서 오는 비효율성이 크지 않나 스스로도 답답함을 느끼고 있는 상황입니다.

< Action >

완벽한 해결책은 아니지만, 지금 할 수 있는 건

• 기능 담당자들에게 꾸준히 질문하기 (현재 하고 있는 방법)
• 도메인 관련 내용을 체계적으로 정리해보기
• 비슷한 경험이 있는 사람들에게 피드백 구하기

정도로 보입니다.

현재 하고 있는 일에 있어서 가장 큰 Pain Point기에, 적극적으로 해결 방안을 모색해야겠습니다.

번거롭고 비효율적인 작업 프로세스

정보 확인의 번거로움

API를 개발하기 위해 관련 데이터와 메뉴를 찾아서 진행해야 합니다. 이 과정에서 매번 타고타고 코드를 확인해야 하는 상황이 반복됩니다.

예를 들어, API를 개발하기 위해 관련 데이터를 찾기 위한 과정을 그려보면 아래와 같습니다:

메인 사이트 관련 메뉴 확인 → 찍힌 Trace 보고 Admin 단 코드로 → Admin 데이터 관리 문서 일일이 매칭 → 해당 되는 데이터 확인

이런 방식으로 관련 메뉴와 데이터를 찾아보면서 오는 불편함이 커서, 이러한 귀찮은 플로우를 어떻게 편하게 만들 수 있을까?라는 고민을 주로 하고 있습니다.

서로의 상황을 잘 모른다, Context 공유 부족

각자 맡은 부분들이 다르고 각자의 작업을 하느라 바쁜만큼 서로서로 뭘 하는지 잘 모른채 진행되고 있습니다.

이로 인해 그만큼의 통신 비용이 더 들고, 제가 일할 때 인터럽션이 발생하기에 맥락을 더욱 적극적으로 공유해야겠다는 생각이 들었습니다.

👉 기능 Item 별 메타 데이터 정리하고 공유하기 - 자료를 만듭시다.

Outro

😵‍💫 내가 잘하고 있는걸까?? 이게 맞나?? 😵‍💫

개인적으로 각자 맡은 부분들을 개발하는 팀 문화상 주고받는 피드백이 활발하진 않습니다.

팀장님과 PL 님께 피드백을 직접 요청함으로써 조금 더 업무 진행을 최적화할 수 있는 방향을 고찰하고자 합니다.

중간 점검을 마치며,

얼마전 "함께 자라기"를 읽으며, 단순히 주어진 할일을 하는 A 작업을 넘어서 A 작업을 개선하는 B 작업을 신경쓰면 더욱 자랄 수 있다는 대목이 기억에 남습니다.

혼란스러운 순간이 많지만, 틈틈이 진행 상황 중간 점검하고 해결해야할 중요한 문제들을 돌아보면서 무사히 매듭지어야겠습니다.

살면서 만난 교육자 중 가장 기억에 남는 분을 뽑자면 우아한테크코스 프리코스 과정에서 만나 뵌 박재성 님이다. 박재성 님의 추천으로 책의 존재를 처음 알게 되었다. 한동안 잊고 있다가, 글또 알고리즘이란 게 따로 있는걸까? 싶을 정도로 글또에서 자주 보여서 집어들어 읽기 시작했다.

개발자와 왠지 거리가 멀어보이는 단어 "함께 자라기" - 그토록 많이 회자되는 이유는 무엇일까?

핵심 메세지

"함께"와 "자라기" 처음 들었을 때 이질적인 두 단어의 조합이다.

흔히 "성장"이라고 하면 고독하게 일이나 공부에 정진하는 모습이 떠오른다. 이 책의 저자는 정통으로 반박하며, "자라기"는 "함께"와 빠질 수 없다는 메세지를 전달한다.

함께 자라기와 애자일의 관계성

단순히 애자일의 "방법론"을 다루는 책은 아니다. 그보다는 애자일의 본질을 마음에 새기도록 가르치는 책이라고 느꼈다. 구체적인 방법론을 기대하고 집어들면 실망하지 않을까 싶다. "How"보다는 "Why"를 다루는 책에 가깝다. 그리고 그 Why는 "함께 자라기"와 연결된다.

그렇다고 "How"가 빠져 있지 않다. 현재 나의 환경에서는 개인적으로 2부 "함께"보다는 1부 "자라기"에서 배우고 적용할만한 포인트가 많다고 느꼈다. 개인적으로 느낀 게 많은 1부 "자라기" 파트 위주로 정리해보고자 한다.

나는 왜 학습이 어려울까 ?

정답이 존재하던 학창시절을 지나고 느낀 혼란

사실 성인이 되고 나서의 학습은 늘 어렵다고 느꼈다. 그 어려움의 뿌리는 무엇이였을까?

학습의 본의는 야생 학습에 가깝다

그렇다, 정리하자면 모호함, 불확실함에서 오는 게 크다. 학창 시절과 달리 기준도, 범위도, 순서도 없다. 세상에 널린 정보는 많은데 뭘 언제 어떻게 주워 먹으면 될지 아무도 안 알려준다. 종종 불안감이 언습한다; '나는 잘 공부하고 있는 것인까..?' 여기서 웃긴 건 이 학습의 채점자도 나라는 사실이다.

그렇다면 내가 학습이 어렵다고 느낀 본질적인 이유, 그 괴로움의 뿌리는 아마도 학창 시절의 명확히 O/X가 떨어지던 학습 패턴을 혼란하고 무질서한 현실의 학습에 적용하기 때문일 것이다. 존재하지 않는 틀을 가져와서 구겨 넣어 보면서 '아니 이게 왜 안 먹지?' 끙끙거리는 꼴이다.

이러한 학습의 야생적인 성격은 책에서 꾸준히 언급되면서, 스스로 안고 있던 고정관념을 깨뜨리고 방향성을 재고해보는 기회가 되었다.

자라기: 어떻게 자랄까?

의도적 수련이란

Q. 1만 시간만 채우면 나는 전문가가 되는가?

A. 핵심은 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련, 즉 의도적 수련이다.

어린 시절 잘못 심어진 신화 탑 10으로 뽑는 것 중 하나는: "뭐든 열심히, 부지런히 하면 된다"이다.

아니, 열심히 말고 "잘"해야 한다.

"잘"해야 한다는 건 무엇인가? 내가 일을 하는 목적을 확실히 하고 진행해야 한다는 말이다.

책에서 말하듯 공이 어디로 가는지 보지 않고 100개, 1000개의 공을 쳐봤자 크게 달라지는 것은 없다. "정확하게 퍼팅하는 연습"에는 그다지 큰 효력을 발휘하지 않는다는 말이다.

애자일 철학이 핵심 피드백을 짧은 주기로 얻는 것, 실수를 교정할 기회가 있는 것

자기계발은 복리로 돌아온다

해당 챕터에서는 저자가 중요한 힌트들을 잔뜩 던져주셔서 적어두고 주기적으로 봐야지 싶었다.

내가 평소에 투자하는 작업의 비용은 어떤 성격일까?

A 작업 : 원래 그 조직이 하기로 되어 있는 일 
B 작업 : A 작업을 개선, 제품을 만드는 사이클에서 시간과 품질을 개선
C 작업 : B 작업을 개선, 개선 사이클 자체의 시간과 품질을 개선

주로 하고 있는 건 A 작업이다. 아직 2년차 주니어로서 "해야 할 과제를 명확히 이해하고 이를 잘 수행하는 것"이 가장 중요하다고 생각이 들면서도.. A 작업을 개선하면 비용적으로 줄일 수 있는 게 많아지지 않을까? 싶었다. 평소의 불편함을 감지하고 A 작업을 개선하는 방법을 생각해봐야겠다.

❓ 나의 A 작업을 개선하려면

1. 어떻게 하면 더하기보다 곱하기를 할 수 있을 것인가
2. 어떻게 해야 곱하는 비율을 높일 수 있는가 or 이자 적용 주기를 짧게 할 수 있는가

자신이 이미 갖고 있는 것들을 잘 활용하라. 외부 물질을 체화하라.

내가 집중해야 할 부분이다. 강점 TOP 5 중 하나로 "수집"이 나오는만큼 호기심으로 외부 유입을 끊임없이 수집하는 건 잘해도, 이를 내 안에서 체화해서 표현하는 게 참 어렵다는 생각이 든다.

*Action Item *

🤔 내가 가진 지식들은? 나는 이걸 얼마나, 어떻게 활용하고 있지? 👉 꾸준히 일지 작성 & 회고하면서 리스트업하자 ! 단순 리스트업에서 그치지 말고 인사이트를 뽑아내자. 이러한 과정들을 블로그 포스팅과 포트폴리오로 남기자.

피드백을 자주 받아라.

(거를 게 하나 없어서 박제)

자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라

"결국 그는 어셈블리 언어에서도 우아한 춤을 출 수 있다"

워드 커닝햄의 일화가 인상깊다. 종종 불편한 환경을 탓하곤 했는데, 앞으로 우아한 춤까진 아니더라도, 중력을 줄여 보다 편안한 환경을 만들어나가는 노력을 해야겠다고 다짐했다.

의도적으로 수련하는 방법

자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있다는 겁니다.

! 뜨끔

침착하고 다음 페이지를 넘겨보자

제자리걸음에서 벗어나기

✍️ 이 부분은 스스로의 상태를 돌아보는데 활용하기 위해 자세히 메모해두려고 한다.

작업 난이도와 실력이 핵심이다. 이를 지속적으로 돌아보면서 조절하는 게 중요하다는 걸 배웠다. 자기가 지금 어떤 상태인지 살피고(=알아차림) 조치를 취하는 동적인 균형을 잡는 것이 중요하다(일신우일신)

Case 1) 지루함을 느끼는 경우

a1) 실력 낮추기

• 키보드로만 개발하려고 한다던지

👉 CLI에 익숙해지기 아무래도 리눅스 환경에서 개발하다보니, 마우스와 키보드를 오가는 내가 간지가 부족하다는 생각이 문득 들었다. 올해의 소소한 목표 중 하나는 VIM 에디터에 익숙해지고 이를 활용하여 개발해보기다🔥 나도 한번 춰보자 우아한 춤 !!

a2) 난이도 높이기

• 자기에게 요구되는 수준을 더 높게 여기는 것 (ex. 하루만에 개발할 거를 한시간 안에 !)
• 안 해도 되는 업무를 자신의 의지로 추가 (리팩토링, 자동화 테스트, 자신만의 도구/방법 개발)
• 이런 것들을 만들기 위해서는 자주 일어나는 반복 패턴을 파악하고 분석해야 하며, 부족한 시간에도 짬을 내어 도구를 고안하고 작성해야 함 👉 업무상의 불편과 비효율을 분석하고, 이를 경감시킬 방안 생각해볼 것

Case 2) 불안함을 느끼는 경우

b1) 난이도 낮추기

• 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전을 첫번째 목표로 삼는 것

👉 전에 인턴으로 처음 다뤄보는 유니티 개발할 때 이렇게 접근했던 기억이 난다. 돌아보니 난이도를 낮춰서 성공적으로 진행한 케이스다.

"GPS 기반 경로 시각화"를 위해 첫번째 스텝으로 하나의 점을 정확한 위치에 표현하기, 두번째 스텝으로 경로들을 스냅샷으로 찍어보기, 세번째 스텝으로 실시간으로 경로들을 찍는 식으로 진행했다.

b2) 실력 높이기

1. 사회적 접근: 나보다 뛰어난 전문가의 도움을 얻는 것 (ex. 짝 프로그래밍)
2. 도구적 접근: 다른 도구의 도움을 받는 것 (a-1와 반대)
3. 내관적 접근: 비슷한 일을 했던 경험을 머릿속에서 되살려본다

프로그래밍 언어 배우기의 달인

✍️ 역시 내게 필요하고 다 적용해볼만한 내용들이라 메모해두려고 한다

튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다 (👉 도전❕)

• 적극적 읽기
• 이 정도면 그 프로그램을 작성할 수 있겠다 → 읽기를 멈추고 코딩 시작

공부할 때 표준 라이브러리 소스코드를 읽는다

• 표준 라이브러리 = 가장 그 언어다운 코드들의 말뭉치 → 해당 언어의 결을 배우고 그걸 따른다

👉 최근 몇년 사이 상당히 여러 언어들을 경험해봤는데 확실히 언어마다 결이 다르다는 말이 와닿는다. 표준 라이브러리를 읽어볼 생각은 못했는데 이번 기회에 참고해야겠다.

*공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다 *

전문성을 효과적으로 뽑아내는 전문가가 되기

• 전문가가 구체적인 사건에 대해 말하도록 유도 👉 회사의 최모 수석님, 황모 수석님을 집중 공략해봐야겠다!

개발자에게 사회적 자본 쌓기란?

개발자의 가장 큰 스테레오 타입은 사람과 소통하지 않고 컴퓨터와 친하다는 이미지인데, 실상은 그렇지 않다. 책에서 언급하기를 뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쏟는다고 한다.

대학생 때 진행한 프로젝트 대부분은 편한 대학 동기들과 한 경우가 많아서, 사회적 자본을 크게 고려하지는 않았다.

목적 조직으로 모이게 된 회사라는 집단에서는 어떻게 커뮤니케이션을 잘 할 것인가?라는 고민을 종종 하는 것 같다. 그동안에는 "효율적으로 커뮤니케이션하기"에 조금 더 치중한 거 같아서, 신뢰 자본을 잘 쌓는 데 신경 써야겠다는 생각이 들었다.

어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요합니다

오죽 중요하면 거듭 강조하실까 싶다. 최근 일하면서 가장 느끼는 부분은 기술과 사람은 떨어지지 않는다는 점이기에, 전반적으로 공감되는 내용이였다. 백날 어떤 기술이 좋다고 외쳐도 사회적 맥락 속에서 실천되어야 한다는 점을 잊지 말자.

그 조직원들이 선생님을 좋아하나요?

ㄴ아파요.

Wrap Up

나는 어떤 개발자가 되고싶을까?

읽으면서 스스로에게 질문을 던지며 읽어볼 수 있어서 좋은 기회였다. 스스로를 돌아보는 기회가 되기도 했고.

최근 스스로에 대해 깨달은 점은 주변 사람들에게서 참 많이 배우고 자극 받는다는 사실이다. 또한, 누군갈 도와주고 기여할 때 큰 기쁨을 느낀다.

이러한 성향과 잘 맞는 이야기들이 적혀 있어서인지 읽으면서 종종 가슴이 벅차기도 하고, 그만큼 삶에 적용하고 싶어서 꼼꼼히 메모해가며 읽기도 했다.

비록 현 상황에서 적용해보기 어려운, 다소 이상적으로 보이는 부분들도 있었지만, 책에서 말하는 것들을 꼭 한번 경험해보고 싶다는 생각을 했다. 아마 5년 뒤의 내가 보면 또 다르게 느끼지 않을까 싶다. 그때의 나는 이러한 개발자에 가까워졌기를 바라며 글을 마쳐본다.

그래서 작성하면서도 회고의 목적에 대한 고민이 많았어요. 내가 회고를 쓰는 목적은 무엇일까, 왜 이런 이야기를 써내려가고 싶은걸까, 하고요.

고민 끝에 저의 회고는 "솔직한 자기 고백"이였으면 좋겠다는 결론을 내렸습니다. 그런 의미에서 현 시점의 제가 가장 쓰고 싶은 것, 가장 기록하고 싶은 걸 적어보고자 합니다.

개발자로서의 수치적인 기록이라기보다는, 저라는 사람이 한해를 돌아보고 느낀 소회를 적은 회고록입니다 ✍️

2024년의 키워드

올해 말의 저는 이상하리만치 연말 회고에 집착한 것 같습니다.

왜 그런가 생각해봤는데, 크게 두 가지로 귀결되더라고요.

알을 깨고 나온 한 해라서

2024년의 저와 2023년의 저는 전혀 다른 사람이 된 듯한 기분이 듭니다.

이전의 저는 세상에 부딪히지 않고 스스로를 마음대로 정의한 채 동굴 안에 움츠러 들어가 있었습니다. '나는 경험이 부족하니까', '나는 이런 걸 모르니까', '나는 이런 면이 없으니까'...

올해의 저는 이리저리 경험해보고 부딪혀보면서 이전에는 상상도 못한 제 모습을 많이 발견했습니다. 여전히 신기하고 낯설고 얼떨떨해요.

그렇게 얻은 올해의 커다란 교훈은 "나라는 사람은 관계와 맥락 속에서 존재한다"는 점입니다. 새로운 만남과 도전들에 뛰어든 덕분에, 저는 홀로 서는 존재가 아닌, 관계와 맥락 속에서 영향을 주고 받으며 변해가는 존재라는 사실을 뼛속 깊이 새길 수 있었습니다.

감정의 단차가 너무나도 컸기 때문

인사이드 아웃이라는 영화를 보셨나요?

주요 감정들이 컨트롤타워를 잡고, 특정 기억에 색깔이 입혀져 감정 구슬이 탄생합니다. 매일매일 여러가지 사건들을 겪으며 기쁨의 노란 구슬, 슬픔의 파란 구슬, 분노의 빨간 구슬과 같은 알록달록한 구슬들이 생산됩니다.

종종 저는 감사회고나 일기에서 감정 구슬로 그날의 감정을 표현하곤 합니다.

올해는 새파란 슬픔의 구슬과 샛노란 기쁨의 구슬이 극단적인 대조를 이룬 해라 특히 더 기억에 남았습니다. 커다란 슬픔을 경험한만큼 작은 기쁨을 더더욱 감사하게 맞이할 수 있었기에, 가득 찬 마음으로 한 해를 마무리 할 수 있었습니다.

이별

우습게도 헤어지는 날 깨달았습니다.

저는 상대방을 좋아하기보다는 이 사람을 통해 내가 원하는 이상을 보고 있었다고.

당시에는 외면하고 있었지만, 스스로 제가 바라던 개발자의 모습과는 거리가 멀었던 거 같습니다. 피아노와 베이스를 연주하고, 꾸준히 책 읽으면서 독서 모임에 출석하고, 친구들을 만나면서 하루하루를 바쁘게 보내고 있었지만, 앙꼬 빠진 찐빵 마냥 그토록 좋아하던 "개발"이 빠진 하루하루들을 보내고 있었기 때문입니다. 당시 직장에서도 제가 막연하게 상상하던 개발자와는 거리가 먼 나날들을 보내고 있어서 더더욱 그러한 빈 자리가 크게 느껴졌던 것 같습니다.

그래서인가 소개팅 첫날부터 급하게 이슈에 대응하겠다고 노트북 펼쳐든, 당시 제 눈에는 너무나도 개발자 같은 그 사람을 봤을 때 '우와... 찐-개발자같다'하면서 괜시리 더 안쓰럽고 마음이 갔던 거 같아요.

불과 몇개월 전, 오기와 열정과 간절함으로 똘똘 뭉쳐 있던 저를 투영해 보아서였을까요? 이상하리만치 빠르게 빠져들고 예상치 못하게 허무하게 관계가 끝났을 때, 생각보다 더 힘들고 곤두박질 치는 경험을 했습니다.

글또

2024년 들어서 가장 잘한 일 = 글또에 들어간 일

막연하게 "개발자들이 글쓰는 모임"으로 알고 들어갔다가, 정신 차려보니 다양한 일들을 벌이며 현재 누구보다 진심으로 활동하고 있습니다. 이제 막 3개월이 지났지만, 그 사이 배울 점이 많고 좋은 사람들을 잔뜩 만나면서 글또만의 따뜻함에 감화되었기 때문입니다. 덕분에 저도 긍정적인 경험과 감정을 선사하고 싶다는 생각이 들어 조금이라도 더 커뮤니티에 기여하고자 노력하고 있습니다.

< 벌인 일 list >

- 낮술낭독회: 낮술과 함께 각자 좋아하는 책들 이야기 하는 모임
- 로우레벨도 있또: C/C++, Linux 생태계 등 로우레벨에 관심 있는 사람들의 소모임
- 미룬이챌린지(운영진): 한 해의 끝에 미뤄둔 할일들을 집중적으로 처리하는 이벤트
- C/C++ 개발자 커피챗
- 이밖에 여러 모각글 벙개 급작스럽게 열기

이 중 가장 기억에 남는 건 처음으로 열어본 "낮술낭독회"입니다.

좋아하는 걸 이야기하는 사람에게서 보이는 특유의 반짝임을 좋아합니다. 그래서 각자 좋아하는 책을 들고와서 이야기하는 모임이 있으면 좋겠다 싶었어요. 처음인만큼 미숙하게 진행한 부분도 있었지만, 각자의 삶의 궤적에서 울림을 준 책에 대한 이야기를 들으며 제 상상보다 150%, 아니 200% 좋은 경험을 할 수 있었습니다.

< 활발하게 참여한 소모임 list >

- 쓸만한 10분 모각글또 (매일밤 9시 글 쓰는 모임)
- 피크민또 (피크민 하는 모임)
- 감사회고해또 (감사회고를 쓰는 모임)
- 책읽어또 (독서 인증하는 모임)
- 뮤직스타또 (음악 추천하는 모임)

이 중 가장 기억에 남는 건 쓸모또(=쓸만한 10분 모각글또)입니다.

리더분과 부리더분이 따뜻한 분들이셔서인지, 모임원들도 전부 서로 부둥부둥 응원해주는 분위기입니다. 쓸모또에서 종종 열린 오프라인 모임들도 좋았습니다. 함께 모닥불 앞에서 마시멜로우를 구워먹고 고기 구워먹고 슈톨렌 나눠먹으면서 소소하게 이야기 나누는 시간이 특히 기억에 남습니다.

쓸모또 멤버들로부터 영업 당해 몇달만에 다시 시작한 피크민또에서도, 귀여운 피크민들을 자랑하며 함께 꽃심고 버섯 전투 나가며 즐거운 기억들을 쌓고 있습니다.

감사회고해또에서는 하루 끝에 감사회고를 적으면서 하루하루 긍정적인 마음을 다져나갈 수 있었습니다.

글또의 여러가지 활동에서 얻는 활력과 따스함 덕분에, 순수한 기쁨으로 가득 찬 연말을 보낼 수 있었습니다.

독서

책을 많이 읽고 나면 강해졌다는 느낌이 들어요. 책을 바빠서 못 읽는 시기엔 사람이 희미해진달까, 좋은 상태가 아니라는 걸 스스로 느껴요. 책에 대한 허기가 져서 며칠동안 정신없이 책을 몰아서 읽으면, 어느순간 충전됐다, 강해졌다고 느낄 때가 있어요. 책을 읽지 않을 땐 자신이 부스러지고 있는 것 같은 느낌이 드는데 읽고 나면 부스러졌던 부분이 다시 모아지는 느낌이 있어요. -한강-

돌아보니 꽤나 많은 책들을 탐독 했습니다. 초반에는 독서 모임에 선정된 책들을 읽다가, 개인적으로 읽고 싶은 목록이 많아져서 여러가지를 찾아 읽었습니다.

< 2024의 Booklist >

마음 - 나쓰메소세키
드링킹 그 치명적 유혹 - 캐롤라인 냅
단한사람 - 최진영
스토너 - 존윌리엄스
홍학의 자리 - 정해연
천개의 파랑 - 천선란
어떤 나무들은 - 최승자(완X) 
불안의 서 - 페르난두 페소아(완X) 
당신은 나의 높이를 가지세요 - 신미나
아무도 모를 것이다 - 정보라
사랑할 때와 죽을 때 - 에리히 마리아 레마르크
가재가 노래하는 곳 - 델리아 오언스
삶은 왜 의미가 있는가 - 이한
프로젝트 헤일메리 - 앤디 위어
마지막 춤은 나와 함께 - 은희경
모순 - 양귀자
희랍어시간 - 한강
코스모스 - 칼 세이건 (완X) 
서있는 여자 - 박완서

시집, 산문집부터 소설까지, 다양한 범주의 문학 작품들을 읽었습니다. 꽤나 많은 책들을 읽었지만 정량적인 수치를 떠나서, 순수하게 읽는 즐거움에 빠질 수 있었습니다. 읽는 순간에는 잠시 다른 사람의 감정을 여실히 느끼고 인생을 살아보면서, 저도 몰랐던 저의 언어를 찾기도 하고 억눌렀던 감정의 버튼이 눌려 눈물이 주룩 나오기도 했습니다.

📚 기억에 남는 문장 중 하나 ("천개의 파랑" 중)

슬픔을 겪은 많은 사람들의 시간은 어떻게 흐르는 것일까. 사실은 모두 멈춰 있는 것이 아닐까. 그 시간들을 흐르게 하기 위해서는 도대체 무엇을 해야 할까. "그렇다면 아주 천천히 움직여야겠네요." 콜리가 보경을 향해 조금 더 몸을 틀었다. "멈춘 상태에서 빠르게 달리기 위해서는 순간적으로 많은 힘이 필요하니까요. 당신이 말했던 그리움을 이기는 방법과 같지 않을까요? 행복만이 그리움을 이길 수 있다고 했잖아요. 아주 느리게 하루의 행복을 쌓아가다 보면 현재의 시간이, 언젠가 멈춘 시간을 아주 천천히 흐르게 할 거예요."

상담

스스로를 객관적으로 돌아보고, 따뜻하게 포용할 수 있게 된 계기

우울과 불안으로 심적으로 힘든 시기가 있었습니다. 간헐적으로 심리 상담을 받으면서 얼마나 막연한 기준들로 스스로를 깎아내리고 단정짓고 있었는지, 한 발자국 떨어져서 저를 바라보는 터닝 포인트가 되었습니다. 스스로에게 많은 질문들을 던지면서, 저도 모르게 제 자신에게 잘못된 프레이밍을 하는 경우가 있다는 걸 알게 되었기 때문입니다.

틈틈이 기록한 상담 일지 중 일부

- 실제 사안을 대충 보고 자기자신을 작게 만드는 경향이 있다
- 직장 안에서 인정받고 존재 의미를 찾는 걸 중요하게 생각한다
- “성장"과 "발전”이 중요한 사람이다, 동시에 불안도와 완벽주의가 높다
  👉 가시화할 수 있는 작은 성취들을 쌓기를 추천

"고독해지기"을 권하는 듯한 사회 풍조지만, 다양한 경험들 속에서 사람들을 만나고 상담을 받으며 깨달은 건 사람은 절대로 온전히 홀로 설 수 없는 존재라는 것입니다. 개인적인 어려움 속에서 이러한 깨달음에 이르게 되며, 누군가 홀로 터널을 건너지 않도록 손을 잡아주고 힘이 되어주고 싶다는 소망으로 이어졌습니다.

나는 어떤 사람인가?

일련의 경험들을 통해 얻은 스스로에 대한 인사이트들

나누고 기여하는데서 커다란 행복을 느낀다. 사람들과 감정을 나누면서 얻는 에너지와 행복이 크다

• 결정적으로 글또 덕분에 알게 되었습니다. 그런 의미에서 앞으로도 글또에서 많은 일들을 벌이고 싶습니다~!
• 이전에 움츠러들어 있던 저와 달리, 외부로 표현하고 표출하는 사람, 밝고 긍정적인 영향력을 끼칠 수 있는 사람이 되기를 지향합니다.

생각보다 직관적+감정적+산발적이고, 불안도와 완벽주의가 높아 의식적으로, 차근차근 Divide & conquer 해야하는 사람이다

• 상담과 회사, 글또 덕분에 알게 되었습니다.
• 뭉뚱그려 사고하다가 불안에 압도 당하는 경우가 많다는 걸 알게 됐습니다.
• 더 나은 제가 되기 위해 논리적으로 쪼개고 차근차근 일을 처리하는 노력을 하고 있습니다(=잘게 쪼개서 수행하기)
• “로지컬씽킹”과 같은 책을 읽으며 논리적 사고방식을 배우고 삶에 적용해보고자 합니다.

성장과 배움이 중요한 사람이다

• 올해의 연애와 글또 덕분에 알게 되었습니다.
• (솔직하게) 2024는 개발자로서 공부가 부족했던 거 같아서, 더 진득하게 공부하고 더 성장하고 싶습니다.
• 고로 현 시점의 저는 목말라 있습니다

KPT 회고

2024년의 'Keep'

<업무>

- 질문 잘 하는 습관
- 일지 및 메모 쓰는 습관
- 노션 업무 큐 관리로 진행도 파악

<공부>

- C/C++ (포인터)
- 리눅스 
- 도커/쿠버네티스 (찍먹) 

<취미>

- 다독: 약 17 ~ 18권
- 다수의 독서 모임 
- 밴드 합주 및 공연 (건반)

<루틴>

- 일찍 일어나고 일찍 자는 루틴
- 킥복싱에 재미 붙여서 주 2~3회 꾸준히 운동
- 일기/감사회고 꾸준히 작성 

2024년의 'Problem'

• 장기적이고 가시적인 형태의 개발 학습 부족 (단편적으로 그때그때 필요에 의해 학습, 하나를 진득하게 하는 경험 부족)

• 일정의 우선순위 조절 (밸런스 X) 👉 악기, 독서 모임과 같은 부수적인 것들이 많아서 개발/글쓰기에 온전히 투자하기 힘듦

2025년의 'Try'

나는 어떤 사람인가? + 2024년의 Problem으로부터 도출된 2025년의 Try 목록입니다

어떠한 value들을 가지고 2025년을 보낼 것인가?

Divide & Conquer

• 나는 어떤 사람인가? item 2와 연관

• 목표를 잘게 쪼개서 구체적인 계획으로

  • 작업등대와 같은 생산성 스킬 적극 활용해보자 !

• "로지컬씽킹"을 읽고 삶에 적용할 수 있는 액션 아이템 도출하기

비우기, 덜어내기

• 비워내고 덜어내는 건 곧 스스로에게 중요한 우선순위가 무엇인지 나의 욕구를 돌아보고 재배치하는 과정. 즉, 본질에 집중하는 연습

• 현재 우선순위는 꾸준하고 가시적인 형태의 개발 학습 및 기록

• 독서 역시 최근의 우선순위를 반영해, MUST LIST를 우선적으로 읽는 것이 목표:

  • 함께 자라기 🌱
  • 로지컬씽킹 🧠
  • 소프트웨어장인 👩🏻‍💻
    • 머니북 💰

• 후순위인 밴드와 외부 독서 모임 포기

• “접속” 줄이기 : 인스타, 슬랙 등 (Forest 앱 켜고 언제 내가 폰을 무의식적으로 폰을 드는지 Tracking)

• 내면의 에너지레벨 꾸준히 들여다보고, 쉼이 필요할 때 쉼을 선택하기

가시적인 성과들로 과정 기록

• Core 개발 공부 타임 (약속 X, 온전히 내 시간)

  • 글또에 재미 들려서 자꾸 이런저런 모임에 참여하려 한다 👉 온전히 나의 Core time 설정, 주별 Habit Tracker 기록

• 단순 개발 서적 읽기(X) → Github에 따로 레포 파서 개발 서적 기록하기

  • 기술 서적 4권 목표

• 자격증 1개 따기

• 기록하기, 그게 뭐든

    - 업무 일지, 회의록 그때그때 정리
    - 이 경험/책 통해 내가 얻은 건? 인사이트 기록하기

(구체적으로 어떠한 학습을 할지 1월 내 차곡차곡 업데이트 예정)

회고라는 행위는 결국

나를 사랑하기 때문에, 내가 잘됐으면 해서, 내가 나를 가장 위하기 때문에 하는 게 아닐까

연말에 치열하게 한해를 돌아보고 행적들을 되짚어보고 나름대로의 의미를 부여하며 내린 결론입니다. 한편의 글로 쓰기까지도 참 힘들었네요.

마지막으로 제가 좋아하는 영화인 "에브리씽 에브리웨얼 올앳원스"의 대사를 끝으로 마무리 짓겠습니다. 그 모든 거절과 실망이 저를 이 순간으로 이끌었기에, 현 시점의 저는 나름대로 간절함과 포부가 큰 것 같습니다. 2024년의 저는 뭐든 뛰어들어보면서 진하게 경험하고 여러가지 극과 극의 감정들을 느끼고 성장했기에, 왠지 2025년의 저에게 신뢰가 가네요. 2024년을 긍정하고 마무리 지을 수 있어 참 다행입니다.

실무에서 포인터 다룰 때 느낀 어려움을 담았습니다

[유의] 기본적인 개념을 상세하게 다루진 않습니다 (포인터를 처음 접한 초급자에게 추천❌)

Pointer

C/C++의 대명사 "포인터"... 흔히들 컴퓨터공학과 전공생들은 포인터를 만나고 나서 전공에 대해 다시 생각해본다는 말이 나올 정도로 악명이 높다.

개념만 간단히 보고 넘어가자면

포인터란? 주소를 저장하는 변수다

int a = 42;
int *p = &a;   // int 포인터 p는 변수 a의 주소를 저장

printf("%p\n", p);   // a의 주소 출력
printf("%d\n", *p);  // p가 가리키는 값을 출력 (42)

주요 연산자

* (dereference): 가리키는 주소의 값(value) & (address-of): 변수의 주소값

사실 포인터를 다루기 위해서 이 정도가 우리가 알아야 할 개념의 전부다.

이번에 API를 개발할 때 포인터로 인해 고통 받으면서, 포인터를 잘 알고 활용한다는 건 뭘까?라는 근본적인 의문이 생겼다.

👇 최근 나에겐 이랬거든🫠..(현타)

다시 한번 말하자면, 포인터란 "주소를 저장하는 변수"다. 근본으로 돌아가서 한번 질문해보자:

주소를 왜 저장해야 할까? 그리고 C/C++은 포인터라는 개념을 왜 가지고 있는걸까?

Why Pointer?

🌟 효율적으로 메모리를 사용할 수 있다 🌟

✔️ Pass by Value vs. Pass by Reference

주소값을 주고받음으로써, 직접 데이터를 복사하지 않고도 접근 가능하다는 이점이 있다 (👉 Pass by Reference)

• Pass by Value: 독립적인 변수에 값 전달
• Pass by Reference: 같은 변수를 공유하는 것 (= Pass by Sharing)

✔️ 동적 메모리 관리

데이터 구조의 크기를 컴파일 시점에 알 수 없는 경우, 객체가 생성된 범위를 넘어 존재해야 하는 경우 등 동적 메모리를 사용해야 하는 다양한 시나리오가 있다.

포인터는 동적 메모리를 가리키고 관리하는 데 필수적인 도구다. 따라서 동적 메모리 관리에는 항상 포인터가 수반된다.

❔정적 메모리 vs. 동적 메모리

• 정적 메모리: 컴파일 타임에 크기가 고정되며, 스택(stack)이나 데이터(data) 영역에 저장
• 동적 메모리: 실행 중 필요에 따라 크기가 변할 수 있으며, 힙(heap)에서 관리

✔️ 연속된 메모리 블록 다루기 용이

포인터와 배열이 종종 함께 언급된다. 포인터를 사용하면 배열을 효율적으로 다룰 수 있기 때문인데, 이는 연속된 메모리 공간에 데이터가 할당된다는 배열의 특성과 관련이 깊다.

아래와 같이 arr[i]로 접근하는 대신, arr의 포인터를 얻어서 접근할 수 있다.

int arr[5] = {1, 2, 3, 4, 5};
int *p = arr;
for (int i = 0; i < 5; i++) {
    printf("%d\n", *(p + i));  // 포인터로 배열 접근
}

실무에서 포인터가 어려운 이유

최근 느낀 어려움을 기반으로 정리해봤습니다 (지극히 주관주의)

메모리 관리를 직접 해야 한다는 어려움

Java와 C/C++ 의 가장 큰 차이점 중 하나는 메모리를 개발자가 직접 관리하느냐의 여부다.

Java는 JVM 위에서 동작하기 때문에 메모리 관리가 자동화되어 있는 반면, C/C++은 기계 친화적인 언어로 더 높은 성능을 제공한다고 알려져 있다. 하지만 여기에는 중요한 전제가 하나 따른다고 본다: 개발자가 메모리를 제대로 관리할 수 있어야 한다는 점이다.

병아리 C/C++ 개발자인 나로서는 여전히 두려운 지점 중 하나기도 하다 😅 나..나는 과연 딴딴한 국밥 개발자인가? 아직 조금 흐물텅한 계란찜 정도 아닐까?..🐣

할당 시점과 해제 시점이 얼마나 떨어져있는가?

동적 메모리를 명시적으로 점유하고 해제해야 하기 때문에 어쩔 수 없이 비즈니스 로직과 메모리 점유/해제 로직이 혼재될 수 밖에 없다고 느꼈다.

예시로 회사에서 작업한 API 전체 삭제/일부 삭제를 처리하는 경우의 코드를 가져왔다. (사내 리소스에 맞게 적용한 메모리 malloc/free 코드가 있어 보안상의 문제로 일부 수정 및 pseudocode 표현)

• 삭제 수행

if(전체 삭제)
{
    member_count = DB에서 전체 데이터 count;
    if (member_count != 0)
    {
        if ((ptr_xxx_member = 데이터 크기만큼 malloc != NULL_PTR)
        {
            ..삭제 로직..
            free (ptr_xxx_member);
        }
    }
}
else  // 일부 삭제
{
    if ((ptr_xxx_member = 데이터 크기만큼 malloc != NULL_PTR)
    {
        // 삭제 실패: fail 케이스 계산 
        for(i=0,fail_count=0; i<req->member_count; i++)
        {
            if(삭제 불가능할 때)
            {
                fail_member 데이터 저장;
                fail_count++;
            }
            else
            {
                ..삭제 로직..
            }
            free(req->data.member_list[i]);
        }
        free(req->data.member_list);
        free(ptr_xxx_member);
    }
}

데이터를 사용하고 난 뒤 메모리는 반드시 해제해야 한다.

하나의 scope 안에서 바로 해제하는 경우 직관적으로 눈에 잘 들어오고 간단하다.

그러나 할당하는 시점과 해제하는 시점이 떨어져 있는 경우 메모리 해제를 놓치기 쉽다.

아까와 같은 delete API 처리를 예시로 들자면,

1. request parsing
2. 비즈니스 로직 
3. response making

이렇게 크게 세가지 파트로 이루어져 있다.

이중에서 실제로 delete를 수행하는 del_xxx_group_member_response 함수에선 fail_data 메모리를 할당하고, response를 만들어 보내는 make_del_xxx_group_member_response 함수에서는 response 객체를 만든 후 메모리를 해제한다.

• 핵심 비즈니스 로직을 담은 del_xxx_group_member_response : fail_data 메모리 할당 및 사용

if ((ptr_xxx_member = 데이터 크기만큼 malloc != NULL_PTR)
{
    // 삭제 실패: fail 케이스 계산 
    for(i=0,fail_count=0; i<req->member_count; i++)
    {
        if(삭제 불가능할 때)
        {
            fail_member 데이터 저장;
            fail_count++;
        }
        else
        {
            ..삭제 로직..
        }
        free(req->data.member_list[i]);
    }
    free(req->data.member_list);
    free(ptr_xxx_member);
}

• 응답을 만들어 보내는 make_del_xxx_group_member_response : 데이터 사용 후 free

...
memberp = res->command_data.fail_data.member_list;
if(res->command_data.member_count)
{
    for(i=0; i<res->command_data.member_count; i++)
    {
        member = json_pack("{s:s,s:s}",
                    "data1", memberp[i]->data1,
                    "data2", memberp[i]->data2);

        json_array_append_new(member_list, member);

        free(res->command_data.fail_data.member_list[i]->data1);
        free(res->command_data.fail_data.member_list[i]->data2);
        free(res->command_data.fail_data.member_list[i]);
    }
    free(res->command_data.fail_data.member_list);
}

이렇듯 별개의 파일과 함수에서 메모리 할당과 해제가 이루어지는 경우, 메모리 해제하는 걸 놓치기 쉽기 때문에 유의하고 개발해야 한다.

이차원 배열과 이중 포인터의 혼동

JSON 객체를 다루기 위해 데이터를 담는 struct를 직접 손봐야 할 일이 있었다. 이차원 배열을 다루기 위해 이중 포인터를 활용했다.

struct data {
    int** lst;
}

막연하게 해당 데이터로 lst의 크기를 구할 수 있겠지~ 생각하고 초반에는 따로 사이즈 정보를 struct에 저장하지 않았다.

이중 포인터는 포인터의 포인터라, 주소값밖에 들어있지 않기에 이 데이터만 가지고 배열의 사이즈를 구하기란 불가능이다. 한-참 찾아보다가, 사이즈를 따로 저장할 수밖에 없다는 걸 깨닫고 다음과 같이 수정했다.

struct data {
    int size; // size 정보 개별적으로 저장
    int** lst;
}

왜 나는 막연하게 이중 포인터로 배열 사이즈를 도출할 수 있다고 생각했을까? 생각의 오류 지점을 따져보면, 이중 포인터와 이차원 배열을 혼동해서인 듯하다.

정리하자면 다음과 같은 차이가 있다:

<크기 정보의 접근성>

• 이차원 배열: 컴파일 시점에 크기가 결정되며, sizeof 연산자를 통해 전체 크기를 알 수 있다

• 이중 포인터: 동적으로 할당된 메모리를 가리키므로, 크기 정보를 별도로 관리해야 한다

실제로 이 데이터에 담긴 값이 뭘까?

🤔❔ 값이 들어가 있는걸까? 아니면 주소값이 들어가 있는걸까?

아직 명확하게 해결책을 제시하기는 어렵지만, 최근 겪은 어려움이라 간단히 언급하고자 한다.

실제 프로젝트의 코드를 분석하다 보면, 특정 변수나 데이터 구조가 실제 값을 저장하는지, 아니면 메모리 주소를 저장하는지 구분하기 어려운 상황이 의외로 자주 발생한다. 대규모 프로젝트에서 여러 파일과 함수를 오가며 코드를 읽다보면 혼동스러울 수 있다.

따라서 코딩할 때 현재 다루고 있는 데이터가 값을 직접 저장하는 변수인지, 아니면 다른 메모리 위치를 가리키는 포인터인지를 의식하는 것이 중요하다고 느꼈다.

글을 마무리하며

메모리 관리: 심화 탐구와 새로운 의문점

✍️ 미래의 나에게,

효과적인 C/C++ 메모리 관리 전략은 ??

C/C++ 개발을 더 해보면서 경험적인 노하우를 쌓아야 하는 부분..이라는 잠정적 결론을 내린 상태다. 일단 기록만 해두고, 차차 알아보는 걸 목표로 한다.

다른 언어들은 메모리 free 하는 시점을 어떻게 판단하는걸까?

그렇다면 알아서 메모리를 잡고 해제하는 Java나 파이썬은 어떻게 메모리를 관리하고 있는걸까? 궁금하다.. 이 부분도 차차 알아가고 싶다.

포인터의 신은 어디쯤이실까요?

최근 포인터와 싸우면서 늪에 허우적거리고 있을 때 회사 아저씨들을 붙잡고 징징댔다 어려움을 토로했다.

2년차: 수석님.. 포인터 어려워요.. 훌쩍
회사 아저씨들: 그 어느날.. 머리 속으로 번뜩!!하고 깨달음이 내려올거야
2년차: ???

과연 이게 언제쯤일지는 모르겠다만, 꾸준히 포인터와 많이 싸워보면서 차곡차곡 쌓인 경험들로부터 말미암아 그 어느날 포인터의 신이 내려오는 날이 오기를 바라며 글을 마쳐본다.

✨ 글또 10기 글쓰기 세미나 후 느낀 점 및 회고 ✨

조만간 인프런에서 성윤님의 풀버전 글쓰기 강의가 나온다고 하니 이를 참고해봐도 좋겠다

글쓰기의 어려움

성윤님이 언급한 글쓰기를 하며 느끼는 어려움 리스트 중, 나는 세가지에 해당하는 걸 발견했다.

• 글이 만족스럽지 않다
• 소재가 떠오르지 않는다
• 내가 글을 써도 될까?

❔글이 만족스럽지 않다

"글이 만족스럽지 않다"는 이 질문으로 귀결된다 👉 기술 블로그를 운영하는 이유

가려운 곳 시원하게 긁어주신 성윤님께 샤라웃을🫡 ..

❔소재가 떠오르지 않는다

그렇다.. 사실 이건 아직 fighting 중인 문제 🧐..

문득문득 스치듯 지나가는 건 많은데 .. 돌이켜봤을 때 잘 알지 못하는 부분/공부해야 할 부분에서 슬쩍 치고 지나가는 부분이라 쉽게쉽게 tmp 폴더에 넣었다가 삭제되는 것 같은 기분.. 지나치게 유동적이라서 막상 글쓰기에 도입하지 못한다.

여기서 힌트를 얻을 수는 있었는데, 실제로 적용해볼 필요가 있을 듯하다.

❔내가 글을 써도 될까?

성윤님 왈, "나의 기준 + 타인 의식"이 복합적으로 얽힌 문제라고 하셨다. 사실 이 부분은 생각지 못했는데.. 듣고 뼈맞았다.

이 부분은 인지한 것만으로도 얻은 게 많다고 생각한다. 죽이 되든 밥이 되든 일단 써보는 게 중요한 것이다.

기술 블로그를 운영하는 이유

근본으로 돌아가서 내가 기술 블로그를 운영하는 이유가 뭘까? 고민해볼 필요가 있었다.

나 같은 경우, 공부를 하며 인풋으로 들어오는 내용이 많은데, 이를 내 나름대로 정리해둘 필요성을 느껴서다.

이렇듯 글쓰기의 목적이 "자기자신"이라면, 결국 나 자신을 만족시키는 글을 쓰는 것이 중요하다. 그러므로 "내가 좋다고 생각하는 글은 무엇일까?"라는 질문으로 귀결된다.

스스로 기준을 적립하기 위해서는 기술 포스팅을 많이 접하고 읽어보는 게 중요하다. 최근들어 스스로 기술글에 대한 심리적 장벽이 높아져 있다는 사실을 깨달았다. 넥스트 스탭으로, 글또 내에서도, 외부에서도 다양한 기술 포스팅을 접하고 탐독하면서 많은 글들을 경험해볼 필요가 있다.

문제 톺아보기

'뜨끔'한 포인트: 원래 알던 내용이 아니라 글쓰기를 위한 공부를 한다.

✔️ 공부와 글쓰기를 한꺼번에 진행하려 하니, 단순 요약글이 된다.

항상 글을 작성하면서 겪은 이슈였다.

1주기 글인 리눅스 overview 글을 작성할 때, 2주차에 리눅스 강의를 한창 듣고 글을 쓰자는 계획을 세웠었다. 강의를 들을 땐, 전체적인 흐름을 캐치했다고 착각했으나, 실제로 내 나름대로 이를 정리하면서 쉽지 않다고 느꼈다.. 당시 글을 제출한 뒤 적어놓은 회고다 :

알 것 같은 느낌이랑 아는 거랑 다르다. 아는 거랑 설명할 수 있는 거랑은 또 다른 문제다. 나는 알 것 같은 느낌->설명하려는 오류를 범했다

공부와 글쓰기를 한꺼번에 진행하니, 아직 머릿속에서 완전히 정리되지 않아 전체적인 그림이 명확하게 그려지지 않은 채 글을 쓰면서, 자연스레 요약글이 되는 것이다.

이에 대해 성윤님이 제시한 Action Item은 다음과 같다:

👉 소재 창고와 공부 창고를 분리하자

• 내가 하고 있는 걸 기록하자, 왜 추가하고 싶은지도 간단히 적어놓자
• 잘 모르는 것은 글로 쓰지 않는다 (중요: 🌟🌟🌟)

여태까지 내 글쓰기를 돌아봤을 때, 한창 공부하면서 새로운 내용을 받아들일 때 머릿속 흥분도가 올라가 이런 엄청난 걸 ... 써봐야겠어 !!!!하는 급발진을 자주 범한다🤔 진정하고 평소에 소재거리를 꾸준히 쌓아두는 게 좋을 듯하다.

다양한 소재 후보

이전에는 막연하게 전문성 있는 기술글만 생각했었는데, 다양한 주제의 글을 작성해봐도 괜찮겠다 싶다.

• 디버깅 case
• 튜토리얼, A to Z 시리즈
• 회고글
• 새로운 도전기 (이직, 해외 등)
• 특정 영역에 대한 깨달음
• 행사 참여 후기
• 프로젝트 진행 글
• 번역
• 책, 논문 리뷰 등

현 시점 목표: 글쓰기 습관 형성

우선 글쓰기에 집중한다. 소재가 무엇이든 일단 써본다

✅ 두가지 Checkpoint

이 부분은 새로워서 메모해두고 스스로 관찰하면서 생각해봐야겠다. 한번도 스스로의 패턴을 돌아본 적은 없어서🤔

✔️ 나의 Trigger는 무엇인가?

언제 실행하는가? 어떤 환경, Context인가? 나만의 환경 알기

✔️ Implementation Intentaion (구현 의도)

목표에 도달하기 위해 언제, 어디서, 어떤 상황에서 어떻게 행동하겠다

if {상황} then {행동}

그래서 ! 어떻게 써야하는가?

📝 역시나 나를 위한 메모

글의 목표 설정: 예상 독자가 누구인가?

목차, 구조 잡기

• 가장 흔한 서론-본론-결론 또는 자신만의 글 구성 템플릿 만들기

내용을 구체적으로 작성해서 보강하기

• 각 부분에서 독자에게 할 이야기를 1줄로 말하면? (중요한 것 1개)
• 여기서 살을 붙이는 방식으로 글을 작성한다

Action Item

🧚‍♀️ 앞으로 어떻게 할것인가?

✔️ 기술글을 더 자주, 많이 접하기

[필수] 글또 아티클 읽기

• 같은 코어 내 글 4~5개
• 글또 큐레이션 글 5개 이상

[선택] 외부 아티클 읽기

• 우연히 접한 흥미로운 글들은 따로 스택에 모아둘 것(=toRead 창고)
• 지나가다가 제목만 보고 오오..하고 따로 저장 → 그러고 까먹는 패턴이 있기 때문 🫠

✔️ 소재 창고와 공부 창고의 분리

• 소재 창고 따로 만들기
• 하고 있는 걸 기록하자, 왜 추가하고 싶은지도 간단히 !

P.S. 앞으로의 개인적인 다짐

🌟 기술 아티클을 많이 읽으려는 이유

성윤님 왈 다른 사람들은 생각보다 자기가 쓴 아티클 많이 안 읽는다고, 너무 의식하고 걱정할 필요가 없다고 말해주셨다.

다른 맥락에서 이를 듣고 스스로 반성했던 게, 내가 글또 커뮤니티내 글들을 많이 안 읽고 있었기 때문이다.

커뮤니티에서 중요한 건 "연결성"이다. (글또라는 커뮤니티에 국한시키지 않더라도 개발자 커뮤니티 상에서 말이다) 누군가가 열심히 읽고 있다는 사실만으로, 누군가가 내 글로 인해 도움을 받았다는 사실만으로 힘이 나는 게 사람이다. 앞으로 조금씩 글또분들의 글들을 더 읽고 보다 적극적으로 리액션하면서 멀리서나마 응원이 전달하고 싶다.

🌟 내가 글을 써도 될까? ㅇㅇ된다.

스스로 기준이 높아서인지, 여러 멋진 개발자들과 나를 비교해서인지, 왠지 내 글을 보여주기 부끄럽다는 심리적 저항감이 있었던 것 같다.

개발자로서 내 흔적을 남기고 싶다는 소망이 있으면 뭐하나, 소극적으로 보여주려면?

일단 쓰자. 많이 쓰자. 쓰고 막 보여주자, 아무렴 어때.

ㅇㅖ? C로 HTTP API 코드를 작성한다고요? 🤷🏻‍♀️

그동안 Java/Spring으로 편하게 HTTP API 코드를 작성하던 나..

C/C++ base의 JSON 객체를 주고 받는 HTTP API 코드를 처음 접하고 든 충격을 전하고 싶어 노트북을 펼치게 되었다.

결론부터 말하자면, Java로 이러한 통신 코드를 작성하는 게 훨씬 단순하다는 점이고, 이 단순함은 JSON 객체를 다루는 편리함에서 와서 C/C++와 Java로 JSON 객체를 다룰 때 차이를 중점적으로 다루고자 한다.

[목표] JSON 객체 다룰 때 C/C++ vs. Java 주요 차이점 훑어보기

크게 두가지 측면에서 차이점을 비교해보자

1. 메모리 관리
2. 직렬화/역직렬화

✒️ Java의 Jackson 라이브러리, C의 Jansson 라이브러리 기준으로, 구체적인 사용법은 다루지 않는다

메모리 관리

C와 Java의 차이점을 하나 뽑자면, 동적 메모리를 다루는 방식에서의 차이가 가장 크다.

C/C++은 개발자가 직접 메모리를 관리하는 반면, Java는 JVM이 알아서 메모리 관리를 하므로 개발자가 신경쓰지 않아도 된다.

int* ptr = new int; // Allocates memory on the heap
*ptr = 10;

// Must manually deallocate to prevent memory leaks
delete ptr;

C에서 JSON 데이터를 다룰 때 역시 memory leak이 나지 않도록, 메모리 할당/해제를 직접적으로 해준다는 귀찮음이 따라온다.

Jansson 라이브러리의 기본 Json 구조는 json_t로, 데이터 타입과 reference count를 들고 있는 구조체다. 포인터를 써서 접근 및 변경하고, 사용 후에는 더 이상 사용하지 않는 json 객체를 반드시 명시적으로 free 하는 과정이 필요하다.(json_decref(): reference count--, 0이 될 시 memory free)

json_t *json = json_object();
// Use json...
json_decref(json);

Jansson 라이브러리 문서에는 서로가 서로의 레퍼런스를 잡아 memory free 할 수 없는 "Circular reference"를 주의하라고 명시했다. 예를 들어, 아래와 같은 상황이다:

json_t *obj1 = json_object();
json_t *obj2 = json_object();
json_object_set(obj1, "ref", obj2);
json_object_set(obj2, "ref", obj1);

이런 경우 결과적으로 서로가 서로의 레퍼런스를 잡고 있는 구조를 가지게 되어, decref 하더라도 free 될 수 없는 상황이 발생한다.

obj1 = {"ref": {"ref": obj1}}
obj2 = {"ref": {"ref": obj2}}

이렇듯 C/C++은 JSON 객체를 다룰 때, 메모리를 직접 다루기 때문에 오는 번거로움을 그대로 가져간다.

직렬화/역직렬화

직렬화/역직렬화란?

• 직렬화(Serialization): 객체 → Byte Stream
• 역직렬화(Deserialization): Byte Stream → 객체

객체지향에서 오는 장점 => 직렬화/역직렬화의 용이함

C는 절차지향적인 언어인 반면, Java는 객체지향적인 언어다. C++은 절차지향 base인 C에, 클래스를 도입함으로써 객체지향적인 특성을 가져왔다.

Java의 객체지향적인 성격이 JSON의 구조와 잘 어울린다. 클래스의 구조와 JSON의 구조가 상응이 잘되기 때문에, 클래스↔JSON 객체의 변환이 용이하다.

JSON 객체 다루기

Java의 Jackson 라이브러리가 제공하는 ObjectMapper를 통해 JSON ↔ Java 객체를 편리하게 변환할 수 있다.

import com.fasterxml.jackson.databind.ObjectMapper;

public class Person {
    private String name;
    private int age;

    // Getters and setters
    // ...

    public static void main(String[] args) throws Exception {
        ObjectMapper mapper = new ObjectMapper();

        // Serialization
        Person person = new Person();
        person.setName("Yooyoung");
        person.setAge(28);
        String json = mapper.writeValueAsString(person);
        System.out.println("Serialized JSON: " + json);

        // Deserialization
        Person deserializedPerson = mapper.readValue(json, Person.class);
        System.out.println("Deserialized name: " + deserializedPerson.getName());
        System.out.println("Deserialized age: " + deserializedPerson.getAge());
    }
}

같은 동작을 하는 코드를 C로 작성해보자.

명시적으로 struct와 포인터를 활용하여 JSON을 다뤄야 하는 불편함이 있다.

#include <stdio.h>
#include <string.h>
#include <jansson.h>

typedef struct {
    char name[50];
    int age;
} Person;

// Serialization function
char* serialize_person(Person* person) {
    json_t *root = json_object();
    json_object_set_new(root, "name", json_string(person->name));
    json_object_set_new(root, "age", json_integer(person->age));

    char *json_string = json_dumps(root, JSON_COMPACT);
    json_decref(root);
    return json_string;
}

// Deserialization function
void deserialize_person(const char* json_string, Person* person) {
    json_error_t error;
    json_t *root = json_loads(json_string, 0, &error);

    if (!root) {
        fprintf(stderr, "JSON parsing error: %s\n", error.text);
        return;
    }

    json_t *name = json_object_get(root, "name");
    json_t *age = json_object_get(root, "age");

    if (json_is_string(name)) {
        strncpy(person->name, json_string_value(name), sizeof(person->name) - 1);
        person->name[sizeof(person->name) - 1] = '\0';
    }

    if (json_is_integer(age)) {
        person->age = json_integer_value(age);
    }

    json_decref(root);
}

int main() {
    // Serialization
    Person person = {"Yooyoung Lee", 28};
    char *json = serialize_person(&person);
    printf("Serialized JSON: %s\n", json);

    // Deserialization
    Person deserialized_person;
    deserialize_person(json, &deserialized_person);
    printf("Deserialized name: %s\n", deserialized_person.name);
    printf("Deserialized age: %d\n", deserialized_person.age);

    // Clean up
    free(json);

    return 0;
}

<주요 차이점>

Java의 객체지향적인 성격으로 직관적으로 JSON와 Java Object 간 매핑이 용이하기 때문에 사용성 측면에서 편리하다.

반면 C/C++은 일일이 key, value를 명시하는 과정이 필요하며, 이로 인해 보일러플레이트 코드가 더 요구된다.

타입 체킹 및 에러 핸들링 C는 강 타입(strong typing)인 반면, JSON은 약 타입(loose typing)

✔️ 강 타입(strong typing)과 약 타입(loose typing)

C++: 구체적으로 명시된 타입

int age = 30;
std::string name = "John";

Json: 타입 명시 X

{
  "age": 30,
  "name": "John",
  "isStudent": true,
  "grades": [95, 87, 92]
}

이러면 C++에서 deserialize할 때(JSON -> C++), 해당 값에 적절한 타입을 결정해야 한다.

이로 인해 C++ JSON 라이브러리는 통상 타입 체킹 및 변환 함수, 타입 불일치에 대한 에러 핸들링 로직 등을 포함한다.

Java 역시 strong-typed 언어인데.. Java는 이 문제를 어떻게 해결한 것일까?

핵심 원리는 Java에 내장된 리플렉션이다.

리플렉션은 런타임에 동적으로 클래스의 정보를 알아내고 실행할 수 있는 것을 말한다.

• getter/setter 명시 없이도 필드 접근 가능
• 리플렉션을 이용해 타입 정보 쉽게 구할 수 있음

덕분에 구조체를 정의하여 일일이 매핑해야 하는 C/C++에 비해, Java는 그 수고로움이 덜어진다.

References

https://jansson.readthedocs.io/en/latest/apiref.html

https://blogs.oracle.com/javamagazine/post/java-json-serialization-jackson

https://stackoverflow.com/questions/17549906/c-json-serialization/34165367

✔️ 사내 리눅스 시스템/네트워크 프로그래밍 강의와 "Linux System Programming" 서적 1장을 참고해 전체적인 그림을 그릴 수 있도록 정리한 글입니다

왜 시스템 프로그래밍인가?

컴퓨터 시스템을 뜯어보면, 크게 유저 공간과 커널 공간으로 나눌 수 있습니다. 추상화된 형태로 시스템 콜을 활용하는, 쉽게 말해 유저 공간에서만 노는 애플리케이션 프로그래머가 시스템 프로그래밍을 알면 어떤 이점이 있을까? 의구심이 들 수 있겠네요.

그렇게 중요하다고 지겹게 듣는 운영체제, 컴퓨터 구조, 알고리즘 등등.. 다 유기적으로 연결되어 있어서 사실 시스템 레벨까지 이해하는 건 단순한 애플리케이션 구현을 넘어서 안정성 있는 소프트웨어를 설계할 수 있는 뼈와 근육이 되어줍니다.

리눅스 시스템 프로그래밍의 초석

• 시스템 콜
• C 라이브러리: glibc
• C 컴파일러: gcc

✔️ 시스템 콜을 활용해 유저 공간에서 운영체제에 특정 자원이나 서비스를 요청할 수 있다.

✔️ C 컴파일러와 라이브러리에 의해 커널이 시스템 콜 호출을 처리한다. 우리는 그 내막을 알 필요없이, 시스템 콜을 호출하면 그만이다.

Linux 시스템 프로그래밍의 주요 개념

파일 및 파일시스템

✔️ 리눅스는 "Everything-is-a-File" 철학을 따라서, 모든 걸 파일로 추상화해서 다룬다.

✔️ 파일을 다루기 위해선 파일 시스템의 인덱스인 File Descriptor(FD)가 필요하다.

✔️ 하나의 파일은 메타 정보 + 데이터을 기본 틀로 가지고 있어, inode(메타 정보) + data block(데이터)으로 구성된다.

✔️ 크게 세가지로 분류될 수 있다

1. 일반 파일
2. 디렉토리와 링크
3. 특수 파일

일반 파일

• inode + 데이터블록 구성

디렉토리와 링크

• inode + (특수한 형태의) 데이터블록 구성
• 디렉토리의 데이터블록에 filename 저장, inode와 filename 매핑

특수 파일

• inode로만 구성

• 디바이스 파일, 네임드 파이프, 유닉스 도메인 소켓이 이에 해당된다

  👉 디바이스 파일: 입출력 장치(예: 하드 드라이브, 프린터, 터미널 등)를 파일로 추상화, 리눅스에서는 /dev 디렉토리 아래에 위치 👉 네임드 파이프: 프로세스 간 통신(IPC) 방식 중 하나로, 두 개 이상의 프로세스가 데이터를 주고받을 수 있게 함 👉 유닉스 도메인 소켓: 동일한 시스템 내의 프로세스 간 통신(IPC)을 위한 소켓

파일 시스템이란?

✔️ 계층화된 파일 및 디렉토리 집합으로, 각 파일 시스템은 특정 네임스페이스에 "마운트"된다.

👉 마운트?(mount, unmount)
외부 장치의 파일 시스템을 특정 디렉터리(마운트 포인트)에 연결하여 OS가 접근 가능하게 만드는 과정

✔️ 데이터를 저장하기 위한 최소 단위 - 블럭

프로세스

프로세스란?

프로세스 vs. 프로그램

✔️ 프로세스는 "실행 중인 프로그램"으로, 파일 시스템 상에 있는 프로그램 파일을 커널로 가져와 가상 주소 공간을 만든다

가상 주소 공간, Virtual Address Space (VAS)

✔️ 프로세스 별 독립적으로 주어지는 가상 공간으로, 텍스트 섹션, 데이터 섹션, BSS 섹션으로 구분

스케쥴링

프로세스와 쓰레드

쓰레드는 흔히 프로세스 내에서 "최소한의 실행 단위"라고 하죠. 다만 이게 따로 구분되는 이유는요? 분명히 비슷한데.. 프로세스 내에서 실행되는 작업 단위가 왜 필요했을까요?

✔️ 쓰레드는 사실 프로세스와 함께 등장하지 않았다. ✔️ 실질적으로 큼직한 프로세스 한두개를 CPU에 스케쥴링 시킬 일이 많다. 프로세스 단위로 스케쥴링 시키기보다, 잘게 쪼개 스케쥴링 시키는 게 효율적이지 않을까?

Life Cycle

Child : fork() - exec() - exit()
Parent :            ..wait()..

• 부모 프로세스가 wait 하지 않아 자식 프로세스가 회수되지 않으면, 좀비 프로세스가 된다

User, Group, Permission

🧐 유닉스/리눅스 환경에서 접근 제어가 필요한 이유는?

1. 멀티 유저 환경
2. 자료가 여러 유저에 의해 공유될 수 있는 환경
3. 세부적인 접근 제어의 필요성 👉 Access Control List(ACL)

시스템 이해하기

✔️ 프로세스가 주체(Subject)가 되어, 객체(Object)로서 파일에게 ✔️ 주체는 Key를 가지고, 객체는 Lock을 가진다 ✔️ 해당 Key가 Lock과 맞으면 통과, 해당 권한 부여

• uid(user id), gid(group id)는 프로세스가 가진 열쇠로서, 프로세스 테이블에 기록된다.
• owner, group은 파일이 가진 자물쇠로서, inode에 기록된다.

1. uid —> owner : 맞으면 owner라는 권한 부여
2. gid —> group : 맞으면 group라는 권한 부여
3. 그게 아니면, other 권한 부여

• Permission bits로 권한 표기: Read/Write/Execute for owner, group, other(xxxxxxxxx)

Access Control List(ACL)

임의의 사용자/그룹에 대하여 추가적인 권한 설정을 설정하는 것이다.

예를 들어, 재무 팀장이 Owner(Read/Write 가능), 재무팀 그룹(Read), 그 외 접근 불가하지만 사장은 특별히 조회 가능한 경우가 있다.

Signal

✔️ 프로세스 입장에서 외부에서 느닷없이 날아온 짱돌과 같다. ✔️ 짱돌(시그널)이 날아와 전달됐을 때, 프로세스의 리액션은?

Generation (커널에서 발생)

1. 예외 발생 (ex. 나누기 0, seg fault)
2. 사용자 요청 (ex. kill 명령)

Delivery (프로세스의 반응)

1. 맞는다 (디폴트 동작)
2. 피한다, 무시한다
3. 잡는다 (=signal handling)

참여자이자 실천자의 관점으로

최근에 인상깊게 읽은 책, "삶은 왜 의미있는가"의 한 구절입니다.

참여자이자 실천자의 관점에서 우리가 확신을 갖고 확인할 수 있는 것은 추상적인 규정 '인생은 무의미하다.'(A)가 아니라, 구체적인 경험 '먹고, 자고, 느끼고, 계획하고, 노동하고, 사랑하고, 공부하고, 돌보고, 이야기하는 것.'(B)이다.

제 컨트롤타워의 리더는 "불안이" 입니다. 그만큼 어릴 때부터 인생의 의미 등 고민이 많은채 하루하루를 커왔는데요, 최근들이 이 책을 읽으며 중요한 교훈을 얻을 수 있었습니다.

참여자이자 실천자로서, 삶의 의미는 결국 제가 채워가는 시간들로부터 만들어간다는 점입니다. 책에서 소개한 사고 실험 중, "시간 제거 기계"라는 것이 있습니다. 평생 동안 주5일, 4~8시간동안 몸은 가만히 있지만 휴식을 취하지 않는 기계에 들어가는 것입니다.

이 사고실험을 통해, 시간 단위로 어떠한 가치를 추구할 수 있는가?의 관점에서 시간의 소중함을 재고할 수 있었습니다. 한번 지나간 시간은 되돌아오지 않고, 시간 제거 기계에서 가만히 있는 시간에 친구를 만나 맛있는 커피를 마시며 유대를 쌓을 기회, 혹은 유익한 강의를 들으며 스스로의 지평을 넓힐 수 있는 기회를 버리며 한 "선택"이기 때문입니다.

우리의 삶은 1분 1초라는 물감을 써서 그려 나가는 작품이다. 사용한 물감은 재활용할 수 없다. 우리가 어떤 행동을 10분 동안 하고 있다면, 우리는 그 경험과 우리가 가진 10분이라는 잠재력을 교환하기로 결정한 것이다.

결국 "나는 어떤 시간들로 삶을 채워가고 싶은가?"라는 본질적인 질문으로 귀결됩니다.

현재 저는 공부하고, 치열하게 회고하고, 꾸준하게 기록하는, 의미있는 시간들을 쌓고자 글또에 발을 디디게 되었습니다. 글또를 통해 2주에 한번씩 글을 작성하면서 글쓰기 습관을 다지고, 그 과정에서 배우고 경험하고 성장하는 저를 돌아볼 수 있기를 바래봅니다.

앞으로의 방향성 & Action Items

1. 좋은 글 쓰기

제가 생각하는 "좋은 글"이란 뭐냐고 물어보신다면, 사실 아직 잘 모르겠습니다. 모호한 완벽함을 좇으며 아무것도 안할 바에 일단 쓰고자 합니다. 꾸준히 작성하는 과정에서 저만의 좋은 글에 대한 기준이 만들어졌으면 합니다.

👉 일단 쓰고 고칠 것, 꾸준히 작성할 것

이전에도 블로그를 운영 했었는데요, 아쉬운 점은 단순 TIL(Today-I-Learned) 요약 정리식 글이 많았다는 점입니다. 제가 어떤 생각을 하고 어떤 코드를 작성하는지와 같은, 제 아이덴티티를 드러내지 않았기에 이번 기회를 통해 스스로를 드러내는 글들을 작성하고 싶습니다.

👉 수동적인 글이 아닌, 적극적으로 표현하고 나의 생각을 녹여낸 글 작성

✔️ Action Items

• 양적 측면: 패스없이 모든 글 작성하기
• 질적 측면: ✅ GPT를 활용한 셀프 피드백 ✅ 글또 피드백 모임 주최 or 참여

❔ 어떤 글을 쓸것인가?

✒️ 글 작성 가이드 참고해서 쓰고 싶은 글들을 정리해봤습니다

1. 회고(2024말, 글또 활동 끝나고)

2. Error/Bug/이슈 해결 방안

   • 어떻게 접근해서 해결했는가?

3. 번역

4. 책/논문 리뷰

단순한 정보 전달이 아니라, 제 경험과 생각을 담아 독자들이 저의 문제 해결 방식을 이해하고 공감할 수 있는 글을 쓰고자 합니다. 이를 통해 저만의 철학을 자연스럽게 드러내고 싶습니다.

물론.. 막상 뭘 쓰게 될지 모름 (밑밥깔기)

2. 커뮤니티 활동 참여

글또 OT에서 "따뜻함이 줄어드는 요즘 조금이나마 따뜻한 공간이 되길 바라고 있다는 리더님의 말씀이 뇌리에 맴돕니다. OT를 듣는 내내 주로 느낀 감정은 "따뜻함"이기에 이러한 커뮤니티의 일원이 되었다는 사실에 감사했습니다.

커뮤니티의 힘은 구성원들로부터 나오는만큼, 글또에 따뜻함을 더하고 긍정적인 에너지를 더할 수 있는 일원이 되고싶다는 생각이 듭니다.

“글을 작성하는 개발 직군분들이 모여서, 좋은 영향을 주고 서로 같이 자랄 수 있는 커뮤니티”라는 글또의 비전에 따라, 서로의 글을 통해 배우며 성장하고자 합니다. 소모임을 통해 다양한 주제들을 공유하며 재미를 더하고, 커피챗에서 현실적인 조언과 팁을 주고받아 서로에게 영감을 주고받고 싶습니다.

✔️ Action Items

• 주기적 커피챗: 한달에 한명씩 알아가기
• 적어도 2~3개의 소모임 참여, 매일 슬랙 확인 및 작은 이모지라도 반응하기

Self Reminder : 지원동기

✨ 6개월 뒤, 글또 끝나고 내가 보기 위해 남기는 초심 ✨

"내가 원하는 개발자의 삶을 그려가는 하루하루"를 지향하기에 루틴처럼 학습하고 기록하고자 합니다. 글또는 이러한 방향성과 일치하기 때문에 지원하게 되었습니다.
자신의 생각을 다듬어서 내놓는 글쓰기 창작 행위는 세상에 긍정적으로 기여할 수 있는, 유의미한 행위라고 생각합니다.
어릴 때부터 글을 읽고 쓰는 걸 즐겨했습니다. 자연스럽게 훗날 작가로서 글을 쓰고싶다는 포부가 생겼습니다. 글또를 통해 주춧돌로써 꾸준히 글을 쓰는 습관을 가져가고 싶습니다.
커뮤니티의 장점은, 잘 쓰여진 글들을 보면서 인사이트를 얻어 보다 좋은 글을 생산하고, 더 나아가 다른 사람들에게 긍정적인 영향을 주는 선순환을 경험할 수 있다는 점입니다. 이러한 좋은 에너지를 영양분으로 한층 더 성숙한 사람으로 나아갈 수 있을거라 생각합니다.
글또를 부스터로, 글쓰는 개발자로서, 또한 커뮤니티에 기여하는 사람으로서 한층 더 성장하기를 기대합니다.

얼마나 의미있는 시간들로 채워넣을지, 앞으로가 기대됩니다. 함께 나아가고 성장하며 스스로 부끄럽지 않은 6개월을 보내고자 합니다 🙌

어릴 때부터 잘하는 건 꿈꾸는 것 밖에 없었습니다.

돌이켜보면 제 학창시절은 마음 한 켠 현실에 대한 불만과 현실에 존재하지 않는 이상을 담아둔 채 자라오는 과정이었습니다.

이십대 중반이 돼서 “물고기는 존재하지 않는다”라는 서적과, “에브리씽 에브리웨어 올앳원스”라는 영화를 인상깊게 보고, 존재하지 않는 정답(저의 이상)을 설정하는 것의 무의미함을 깨달았습니다. 또한 심리 상담을 받으며 스스로에 대한 기준과 이상이 높고, 그만큼 현실에 만족하지 못해 오는 좌절과 불안이 크다는 사실을 알게 되었습니다.

지금의 저는 멀리 있는 미래를 바라보거나 지나간 과거에 미련을 두기보단 현재를 충실히 살아내는 방향으로 가고 있습니다. 사람들과 소통하고 독서하며 인식의 지평을 넓히고 다양한 감정들을 온전히 느끼고, 피아노 치고 독서모임에 참여하며 즐거운 여가 시간을 보내고, 운동을 하며 스스로의 몸과 마음을 가꾸며 하루하루를 살아내는데 최선을 다하고 있습니다.

직접 뛰어들어서 온전히 감각하고 스스로의 가치관과 취향을 쌓아가는 경험주의자, 제가 추구하는 제 모습이자 현주소의 저입니다.

내 인생의 흐름? 나도 모르겠다!

스스로 평가하기에 꽤나 예상할 수 없고 알 수 없는 궤적으로 살아왔습니다.

수능 국어를 못 봐서 이과로 정시 교차지원을 해서 컴퓨터공학과에 내려 앉았습니다. 의외로 Computer Science가 잘 맞고 재미있어, 즐겁게 공부하며 대학 시절을 보냈던 기억이 있습니다.

백엔드 개발자에 대한 확고한 꿈이 있어 약 일년반의 길고 어두운 취준 기간을 보냈습니다. 반전은, 생각하던 백엔드 개발자가 아닌 C/C++ 기반의 소프트웨어 개발자가 됐다는 사실입니다.

그래서 사실 제 인생을 하나의 책으로 친다면, 어느 챕터에 와있는지 잘 모르겠습니다. 생각보다 알 수 없는 타이밍과 변수들 속에서 현재까지의 감상은 “내 인생의 흐름 같은 거? 나도 잘 모르겠다!” 입니다.

다만 한가지 확실한 건, 저는 개발하는 과정이 즐겁고 스스로 그리는 개발자의 모습에 가까워지고자 노력한다는 점입니다. 제가 정의하는 개발이란, “문제를 논리적으로 풀어가는 과정” 입니다. 기술적인 트렌드에 빠싹한 제너럴리스트보다는, 하나의 기술을 깊이 있게 습득하고 활용하여 부딪히는 문제들을 논리적으로 풀어나가는 스페셜리스트를 추구합니다. 그리하여 꾸준히 관심 있는 분야를 학습하고 기록하는 사람이 되고자 합니다.