[회고] 3년차 개발자가 되며

2024년을 돌아보며

2024년은 제 인생에서 중요한 전환점이 된 해라고 생각합니다.

행동과 선택에 대한 기준을 명확히 정립할 수 있는, 프로그래머로서, 사회의 한 직장인으로서, 그리고 한 개인으로서 성장할 수 있는 기회를 어쩌다보니 많이 얻었습니다.

특히 “무엇을 할 것인가”와 함께 “왜 그것을 하는가”에 대한 질문을 끊임없이 던졌던 시간이었습니다. 이 과정에서 배운 점들을 기록하고, 나아갈 방향을 정리하려 합니다.

기억에 남는 Lesson & Learn

올해는 여러 기술적, 문화적 실험을 통해 개인적, 조직적 성장을 이뤄내기 위한 시도했습니다. 특히 리더십과 자동화 라는 두 가지 키워드를 중요하게 생각했습니다.

리더십과 팀워크

우선 결론부터 말하자면, 리더십에 대한 제 생각은 다음과 같습니다.

• 리더십의 본질은 단순히 자신의 일을 잘하는 사람이 아니라, 팀이 더 잘 일할 수 있도록 돕는 역할을 해야한다는 점 입니다. 즉 리더란 조직에서 근본적으로 서포터에 가까운 사람이라고 생각합니다.

또한 앞으로 리더십 포지션을 맡아야한다고 할 때, 다음과 같은 행동 원칙 세웠습니다.

• 구성원들에게 재미와 동기를 줄 수 있는 환경을 조성한다. 재미는 선택권을 위임하고 책임을 온전히 가져가는 문화(DRI)에서 온다

• 실패 비용을 줄이는 조직을 만든다. 이를 달성하기 위해 리더는 영향도를 최소화하는 선에서 자동화를 하거나 또는 적절한 문화를 만든다

• "내가 좋다고 생각해서" 가 아니라 구체적인 Pain Point를 해결하기 위해 행동한다

• 잘못된 결정보다 나쁜 것은 결정을 미루는 것이다. 잘못된 결정을 내려도 Lesson & Learn만 확실하면 된다

그리고 "리더는 서포터이다." 라는 생각이 자동화를 잘 해야한다는 생각으로 자연스럽게 이어졌습니다.

자동화와 설득

현재 조직에서 Pain Point를 적극적으로 찾아서 자동화를 도입했습니다. 대표적으로 OpenAPI 기반 Mock 서버 자동 생성 기능, Pull Request Checker, Electron App 빌드 및 Github Release 프로세스 자동화가 있습니다.

위의 자동화는 현재 겪는 또는 예상되는 Pain Point를 기반으로 제작했지만, 그 과정에서 많은 시행착오가 있었습니다.

바로 자동화의 이점만 부각시켜서 생각했다는 점이었습니다.

자동화 그 자체는 생산성과 효율성을 높이는 데 매우 중요한 도구입니다. 하지만 무조건적인 자동화는 구성원의 공감을 얻기 어렵고, 때로는 신뢰를 떨어뜨릴 수 있다는 것을 배웠습니다. 왜냐면 공감대가 생긴 사람이 같은 조직이더라도 아주 극소수 일 수 있기 때문입니다.

따라서 왜 필요한가를 명확히 하고, 데이터를 바탕으로 설득해야만 자동화에 대한 명분과 설득이 생깁니다.

그래서 지금 당장 Pain Point를 발견했다고 해서 자동화를 도입하기 보다는, 우선 영향도가 적고 당장 도움이되는 자동화를 우선적으로 도입하고, 지표나 숫자를 통해 근거가 명확할 경우 자동화를 도입해야한다는 Learn이 있었습니다.

리펙토링 원칙과 기술 선택

나눌 수 없을 때 까지 나누고, 본질을 이해하며 조합하기

어떤 코드가 비지니스에 대응하기 좋았는지 고민했고 그 답을 찾았습니다. 바로 원칙을 가지고 나눌 수 없을 때 까지 나누고 조합해서 사용하는 코드 가 좋았습니다.

같은 맥락으로 함수형 프로그래밍, Radix UI를 기반으로한 Shadcn UI를 좋아하는 이유라고 생각합니다.

함수형 프로그래밍은 순수함수를 나눌 수 없는 원자로, Radix UI는 기능을 원자로 삼았습니다. 그리고 원자들을 조합해가며 기능을 만들어갑니다.

이런 원칙에 기반했기 때문에, 어떤 형태나 기능도 자유롭게 변경이 가능합니다. 따라서 빠르게 실행이 가능하고 실패하더라도 다시 돌아올 수 있는 환경을 만들 수 있다고 생각합니다.

그래서 코드 리뷰나 무언가를 설계할 때 나눌 수 없는 단위를 생각해서 설계하게 되었고, 어떤 것이든 빠르고 견고하게 만드는 방법을 터특하게 되었습니다.

API의 본질을 이해하기

REST API, GraphQL, gRPC 같은 기술은 결국 리소스를 어떻게 정리하고 전달할 것인가 라는 동일한 문제를 해결하기 위한 도구입니다.

즉 전달하려는 데이터를 리소스 위주로 설계하거나, ID 기반으로 잘 정렬한다면 REST API나 GraphQL이나 gRPC 모두 비슷한 형태를 띄게 됩니다. 다만 각 기술의 다른 점은, 리소스를 더 잘 표현하는 기능이 들어갔냐의 유무 차이입니다.

특히 REST API < gRPC < GraphQL 순으로 갈 수록 리소스를 더 잘 표현할 수 있는 규약이 있었고, 같은 GraphQL이더라도 apollo를 쓰느냐 relay를 쓰느냐에 따라 더 강력한 규약이 존재했습니다. 그리고 반대로 규약이 적을 수록 더 큰 범용성 을 가졌습니다.(물론 상용 기준으로 그렇다는 이야기 입니다. REST API는 강력한 제약을 가지고 있어요)

하지만 너무 많은 문맥과 상황을 존중하는 기술이 때로는 문제가 된다는 점을 발견했습니다. 왜냐하면 그런 존중이 때론 너무 많은 지역 방언을 만들어내게 되고, 결국 의사소통 비용을 증가시켰습니다. 예를 들면 Post지만 Put처럼 동작하는 API라던가, 파라미터를 분기내어 한 함수가 Get 또는 Post처럼 동작하는 gRPC method가 있을 것 같습니다.

이런 문제점들이 새로운 기능을 추가할 때 큰 비용으로 다가오는 경우를 많이 목격했습니다. 비록 우리는 비지니스를 해서 본질적으로 가치를 창출해야하는 사람들입니다. 따라서 GraphQL 진형의 Relay와 같이 강력하게 원칙을 지키는 프레임워크가 단기적인 관점에서는 비지니스를 해칠 수 있지만, 장기적인 관점에서 빠르게 변경가능하기 때문에 장기적 성장에 유리하다고 생각하게 되었습니다.

즉 무조건 빨리 만드는 것보다 원칙을 고수하는게 중요할 때가 있다고 생각합니다.

Lesson & Learn의 중요성

많은 조직들이 실행에 대한 결과를 분석하고 배우는 과정을 소홀히 한다는 점을 발견했습니다.

비니지스는 필연적으로 실패를 경험하기 때문에, 결국 비니지스를 성공시키려면 빠르게 실행해서 피드백을 통해 개선하는게 더 중요합니다.

다만 이런 피드백을 받는 과정이 대체로 대기업일 수록 보수적이고 느리다는 것 입니다. 따라서 한 번의 결정에 대한 비용이 너무 커져서 피드백을 받기도 전에 프로젝트가 실패하거나, 지금 당장은 성공적으로 실행이 되었다고 하더라고 피드백의 중요성을 무시해서 장기적으로 비지니스에 실패하게 됩니다.

따라서 조직을 가능한 작고 팀워크가 잘되는 인원들로 구성하는게 중요하다고 생각했습니다. 그런 조직일 수록 Lesson & Learn을 하기 쉽고 의사소통 비용이 줄어들어 실패에 대한 비용을 최소화하고 회복탄력성을 가질 수 있기 때문입니다.

비니지스 마인드의 필요성

비니지스는 단순히 돈을 버는 것이 아닙니다.

가장 중요한 질문은 “사회가 필요로하는 가치를 제공하는가” 입니다.

혁신적인 회사들은 근본적으로, 소수만 누리던 가치를 보편화하여 더 많은 대중에게 가치를 전달합니다. 이를 달성하기 위해 대량생산을 통해 가격을 낮추거나 기술 혁신을 통해 누구나 쓸 수 있게 만듭니다.

그리고 사용자에게 가치를 제공한다면 돈은 자연스럽게 따라옵니다. 따라서 “어떻게 이익을 얻을까”보다는 “어떻게 더 줄 수 있을까” 를 고민해야 합니다.

나아가 이는 회사에서 돈을 받으며 팀으로 활동하는 직장인도 마찬가지라 생각합니다. 동료와 팀에게 어떤 가치, 편의를 더 줄 수 있을까를 고민해야한다고 생각합니다.

2025 목표

위의 Lesson & Learn을 통해 다음과 같은 목표를 세웠습니다

1. 비즈니스 경험 쌓기

직접 비즈니스를 경험하면서 비즈니스 마인드를 가진 개발자로 성장하고 싶습니다. 이를 통해 더 나은 합의점을 제안하고, 좋은 사회의 한 구성원이 되고 싶어요.

2. 사회적으로 긍정적인 가치를 주는 프로젝트에 기여하기

단순한 기술적 성취를 넘어, 긍정적인 영향을 미치는 제품과 서비스에 기여하려고 합니다.

마무리하며

올해는 제 개인적, 직업적 철학을 다지는 한 해였습니다.

그 중에서도 가장 큰 깨달음은 아래의 문구였던 것 같습니다.

“돈을 쫓지 말고, 어떤 가치를 줄 수 있는지 생각해라”

어떤 것을 받을지 생각하지 말고, 어떤걸 줄 수 있을지 고민하는 것.

개발자로써, 또 동료로서 가장 중요한 마음가짐이라고 생각합니다.