2024 회고록 (2) - 개발 💻

3년이 지났다.

이제 슬슬 어떻게 돌아가는지 알 것 같다. 일을 받아서 하는 자세와 일이 되게 만드는 자세의 차이를 알게 되었다. 그걸 알면서도, 일이 되게 만드는 사람이 되려면 아직 갈 길이 먼 것 같다.

일하는 방식

• // @@ TODO: implement here.
  • 일단 코드부터 짜다가 많은걸 놓치게 되는 불상사를 예방할 수 있는 방법이다.
  • 내가 해야 할 일이 무엇인지, 어떻게 구현해야 하는지를 일단 TODO 로 적어보고, 이 TODO 를 하나씩 없애는 식으로 작업하는 습관을 들이고 있다.
  • 기존 로직 수정 작업이든, 새로운 로직을 짜는 작업이든 관계 없이 언제든 써먹는 방법이다. TDD 였나 예전에 읽었던 어떤 책에서는 당연히 이런 과정으로 코드를 짜야 한다고 말했던 것 같다.
    • (하지만 그걸 알면서도 습관화하는 데에 오래 걸렸다. 😇)
  • 그래서 작업 순서는 이렇게 된다.
    1. 요구사항 파악하기
    2. 코드 레벨에서 건드려야 할 부분에 TODO 붙여놓기
       1. 이 단계에서는 주석이 아닌 코드를 한 줄도 적지 않는다. 설령 단순한 오타 수정건이라도 @@ TODO: typo !!! 이런 식으로만 적어놓는다.
    3. TODO 하나씩 해결하기
    4. PR 올리기 전, 모든 TODO 가 해결되었는지 확인하기.
  • 앞에 골뱅이를 붙이는 이유는 팀원들이 적어놓은 TODO 와 구분하기 위해서다. 그러면 검색이 편하다.
• PR draft
  • 깃허브는 어쩜 이렇게 필요한 기능을 딱 넣어놓았을까? PR 올린 뒤에 커밋을 추가하면 그 사실이 온 팀원한테 전파되어서 신경쓰이곤 했다.
  • 올해부터 팀에서 PR draft 기능을 쓰게 되어서 마음이 편안-해졌다.

셀프 칭찬

• 안 되면 다른 거. 이것저것 벌려놓다가도….
  • 주변의 다른 사람들도 대부분 갖고 있는 능력이지만, 셀프 병렬 스레드를 잘 돌리는 것 같다. Context switching 이 많이 필요한 일이 아니라면..! (그런 일은 아직 좀 귀찮아서 각 잡고 시작하는 편이다. 근데 또 이런 일이 내 예상보다 빨리 끝나는 경우가 많았다.)
  • 하던 일 안 되면 잠깐 치워놓고 다른 일을 하다가 오면 해결되는 경우가 꽤 있었다. 무의식의 힘을 믿는 편이다.
• 새로운 아이디어
  • 이건 칭찬이면서 약간의 채찍도 들어가는데, 새로운 아이디어를 내는 능력은 확실히 갖고 있는 것 같다. 하지만 그 아이디어를 좀 더 발전시키고, 빈틈을 찾아내서 보완하는 능력을 좀 더 키워야겠단 생각이 종종 들었다.
• 소통, 수용
  • 리더님이나 기획자분들께 가끔 들은 얘기다. 일을 하면서 점점 느끼는 거지만 개발 업무 특성상 정해진 답이 없고 어디까지 해야 할지도 정해진 게 아무것도 없다. 주어진 서류를 다른 것과 비교해서 완벽하게 일치하도록 맞춰야 한다거나, 법률에 기반해서 판단해야 하는 일 같은 게 아니다. 결국 모든 게 합의로 이루어지는 분야다.
  • 그러다 보니 상대방의 의견을 어디까지 수용하고 내 의견을 어디까지 피력해야 할지를 잘 생각해서 움직여야 하는 것 같다. 그래도 아직까진 잘하고 있는 것 같다.

셀프 채찍

• 질문을 던지는 능력
  • 어떤 걸 하면서 본질을 놓치지 않아야 하는데. 내가 지금 이걸 하고 있는 게 맞나? 목적이 뭐였지? 라는 질문을 던지고 싶다고 22년도 회고 글에도 똑같이 적어놓은걸 발견했다. 반성반성….. 아직 멀었구나 !!!
  • 올해는 이걸 실천해 볼 타이밍인 것 같다.
• 큰 그림을 보는 능력
  • ‘내가 이걸 만든 그 다음에는 어떤 일이 일어날까?’ 를 생각하는 능력이 중요하다. 배포할 땐 어떤 일이 일어날 것이고 배포 후 평소에는 어떤 일이 일어날지, 이 일이 다른 누구에게 영향을 미칠지 생각하는 능력.
  • 한 방향만 보고 직진하는 성격이 일할 때도 종종 나오는 것 같다. 때로는 직진이 필요하지만 때로는 잠깐 멈춰서서 이런 질문도 던질 줄 아는 사람이 되고 싶다. 🙃
• 그러면서도 디테일을 챙기는 능력
  • 이게 참..!! 쉽지 않다. 특히 인프라쪽 작업은 설정값 한 끗 차이가 너무나도 큰 영향을 주기 때문에 조심해야 한다는 걸 알면서도 아직 부족한 것 같다.
  • 성격상 급하게 하는 건 맞지 않아서, 디테일을 챙기려면 역시 시간을 갖고 두고두고 다시 보는 수밖에 없는 건가 하는 생각도 좀 든다.

기술 성장 모임

4월부터 지금까지 사내 기술 성장 모임에 참여 중이다. 관심 있는 기술 주제를 골라잡아서 적게는 7-8명, 많게는 10명이 넘는 인원들이 모여 활동하는 프로그램인데, 이번 1월 회식을 마지막으로 해산하게 된다. 보통 끝나는 것에 미련을 두지 않는 편인데, 이건 끝나는 게 너무 아쉬울 정도로 알찬 시간을 보냈던 프로그램이다.

사람들

• 주니어, 중니어, 시니어 골고루 모여있으면서도 공통된 관심사가 있는 모임..! 주니어 입장에서는 이것저것 물어보고 배우기 딱 좋은 모임이었다.
• 언제든 이것저것 여쭤보면 열심히 대답해 주는 분들이 계셔서 더 편하게 질문을 할 수 있었다. (모르는 부분은 찾아서라도…! 감동.)
• 같이 모여서 업무 외적인 기술 이야기하는 것 자체가 재밌었고, 모인 사람들의 에너지가 좋았다. 최근 데이비드 호킨스 박사의 에너지 레벨 - “의식의 밝기” 라고 부른다 - 에 대해 알게 되었는데 우리 모임 분들은 대부분 꽤 높은 상태일 것 같다.
• 덕분에 개발적인 내용뿐만 아니라 삶에 도움이 되는 조언도 많이 주워 담았다. 😗

Kafka

• 사내 스터디를 이렇게 꼼꼼히 해본 건 처음이었다. 진행 방식은 지난 글에 적었던 ‘모두가 한 번씩 이야기하는 스터디 방식’을 썼는데 반응이 꽤 좋았다. 특히 카프카 사용 경험이 비슷한 사람들끼리 모이다보니 부담 없이 편하게 물음표 살인마가 되고 팀 내 사례 공유도 하면서 알차게 스터디 시간을 보낼 수 있었다.
  • 이 스터디를 하면서 **[Kafka] KRaft 모드에서 컨트롤러의 정체 파헤치기** 글을 적었다.
    • 이 글을 쓰면서 https://cwiki.apache.org/confluence/display/KAFKA/Index 이런 흥미로운 링크를 발견했다. 시간이 될 때마다 한 번씩 들어가서 구경하기 딱 좋은 페이지다.
• 그러면서도 해결되지 않은 질문을 깃허브 코멘트로 남겨놓았는데, 시니어 한 분이 답변을 달아주셔서 감동하기도 했다. 🥹
• 거의 반년이 넘는 시간동안 8명이 모여서 아주 많은 일을 할 수 있을 줄 알았다. 하지만 다들 본업이 있다 보니 처음 계획했던 아주 큰 그림까지는 달성하지 못했고 중간 그림까지는 할 수 있었다. ‘카프카 DR 구성과 모의 장애 테스트’였는데, 데이터 동시성과 일관성을 유지하면서도 성능을 해치지 않기 위해 어떤 걸 신경 써야 하는지 여러 가지 시나리오를 생각해 볼 수 있었다.
  • 직접 프로듀서, 컨슈머, 복제 애플리케이션에 무슨 일이 일어날 수 있을지 케이스를 나눠서 하나씩 그림을 그려보니 명확하게 정리되고 이해가 잘 되었다. 브루트포스 알고리즘은 이럴 때 통한다.

생각

개발자의 역할에 대해

좀 더 정확히 하자면, ‘애플리케이션 개발자의 역할에 대한’ 생각이다. 일을 하면서 과연 우리의 역할은 어디까지인지에 대한 기준을 세우고 싶어졌다. 여기서 애플리케이션 개발자라고 함은, 사용자 서비스에 대해 주어진 요구사항을 받아 그걸 실제 동작하는 서버로 구현해 내는 개발자라고 정의하고 싶다. 그러니까 high level 애플리케이션을 만드는 개발자인 것이다.

• 서비스 구현에 사용되는 특정 기술에 대해 깊이 탐구하는 것?
• 이미 나와 있는 기술을 종합하여 잘 써먹는 것?

이 둘 중에서 고르라면 나는 후자를 고르고 싶다. 특정 기술에 대해 깊게 아는 것도 물론 필요하다. 퀄리티 있는 서비스를 만들기 위해서는 중요한 일이다. 하지만 우리의 역할은 연구가 아니다. 우리는 서비스 개발자다. 결국에는 서비스를 만들어야 한다. 그러기 위해서 어떤 선택지가 있는지 파악하고 장단점을 비교해서 최선을 선택하는게 우리의 몫이 아닐까?

그렇다고 또 전자의 역할이 필요 없는 것도 아니다. 😇 결국에는 두 마리 토끼 모두 잡아야 하지만 둘 중 굳이 고르라면 후자를 선택할 뿐..! 올해에는 공식 문서 읽기 프로젝트를 다시 되살려야겠다.

조급해지지 않기

총 3편으로 나눠서 번역한 ‘40년차 프로그래머’를 읽으면서 깨달은게 있다. 원문은 The Forty-Year Programmer 다.

바로, 조급해지지 않아도 된다는 것이다. 갑자기 연금복권에 당첨되는 특별한 이벤트가 생기지 않는 이상 계속 개발자로 일을 할 것 같다. (연금복권에 당첨되더라도 취미 삼아 개발자로 일을 할지도 모르겠다. 사람은 어떤 형태로든 노동해야 한다.) 그렇다면 죽기 전까지… 아니 적어도 앞으로 3-40년 동안은 코딩하면서 살게 될 텐데 벌써 모든 걸 알려고 하지 않아도 된다는 내용이 있었다. 그리고 알 수도 없다.^^ 언젠가 다 알게 된다. 이 말을 보고 나도 모르게 가졌던 욕심을 좀 내려놓을 수 있게 되었다.

마침, 비슷한 시기에 리더님과 면담을 하면서 내가 좀 더 잘할 수 있는 곳에 에너지를 쏟아보는 게 어떻겠냐는 조언을 들었고 이걸 PR 리뷰에 적용해 봤다. 그전까지는 ‘우리 팀에 올라오는 모든 PR 을 다 살펴보겠어!’ 라는 상당히 용감한 마음가짐을 갖고 있었고 실제로 그렇게 할 수 있었다. 팀 인원이 나까지 3명뿐이었기 때문이다. 하지만 서비스가 고도화되고 팀 인원이 늘어나면서 물리적인 시간이 부족해서 그렇게 하기가 어려워지기 시작했고 은연중에 압박감을 느끼고 있었던 것 같다. 이제는 그러지 않기로 했다.

그저 재밌는 걸 할 뿐… 난 아직도 설계 단계가 제일 재밌다.

40년차 프로그래머 글을 읽으면서 또 한 가지 깨달은 점은 ‘어떤 방향으로 나아갈 지 모르겠다면 내가 하면서 재미를 느끼는 일 쪽으로 가면 되겠구나’ 였다. 그전까지는 프로그래머의 삶이 하나의 마라톤이라고 생각했다. ‘난 아키텍트가 될 거야!’ 같은 목표를 정해야 할 것만 같고, 열심히 공부해서 그 정한 목표만을 향해 나아가야 할 것 같은 생각을 하고 있었다. (왜인지는 잘 모르겠다. 처음부터 그냥 그랬다. 다른 개발자들처럼 성장에 대한 욕구가 많은 것 같기도 하다.) 하지만 그게 아니라, 하루하루 기록을 쌓아가는 일기에 가깝다는 구절이 가장 인상 깊었다.

난 아직도 설계 단계가 제일 재밌다. 2022년 회고 글에도 썼던 내용이다. 친구들이 나는 참 한결같은 사람이라고 하는데 2025년과 그 후에도 바뀔지는 지켜봐야 알 것 같다. 아마 변하지 않을 것 같다.

TODO

2025년에는 이런 부분에 집중하고 싶다.

• 틀릴 수 있다는 생각, 좀 더 나은 방향이 있을거란 생각
  • 내가 했던 작업을 되돌아보는 시간을 가져보자. 작년부터 했던 일인데 올해에는 더 열심히 해야겠다.
  • 리더님도 하시는데 내가 이 생각을 안 한다고..? 감히..???
• 좀 더 큰 그림을 보자. 좀 더 상상하자.
  • 내가 적은 코드가 어떤 결과를 낳게 될 지 생각해보고 배포날에 무슨 이벤트가 터질 수 있는지 상상해보고 그 뒤까지 예측해보자.
• 좀 더 침착하게 해보자. 여유를 가지면서도 기민하게 움직이자.
  • 쉽지 않은 일이 되겠지만 그만큼 내게 꼭 필요한 자세인 것 같다.
  • 평소엔 안 그러면서 이상하게 일만 잡으면 급해지는 것 같다. (왤까?)
• 굳이 친절하자.
  • 굳이? 라는 생각이 든다면 그냥! 하자.
• 공식 문서 읽기 프로젝트를 되살려보자. 별 일이 없다면 요가 강사 과정 코스가 끝나는 5월부터 해보고 싶다.