회고

회고를 시작하며

매일 기록은 남겼다.
팀 회의에서 나온 결정, 기술적으로 붙잡고 씨름했던 문제, 동료와의 대화에서 튀어나온 인사이트, 작은 기능 실험의 성패, 그리고 여러 번의 시행착오까지 꽤 많은 것을 쌓아두었다.
그런데 정작 글로 정리해 한 호흡에 남길 시간은 거의 없었다.

지금은 시간이 난 건 아니지만, 돌아보는 습관이 필요하다는 걸 절실히 알게 됐다.
기록이 있어도 그것을 문장으로 다듬지 않으면, 변화는 체감되더라도 선명하게 남지 않는다.

내가 바꾼 시선

한때 나는 창업을 어렵고 위험한 선택으로만 보았다.
아이디어가 있어도 실현할 능력이 부족하다는 생각과, 실패했을 때의 두려움이 더 크게 느껴졌다.

하지만 인턴십에서 만난 팀의 방식은 달랐다.
팀에 계셨던 엔지니어 분들은 더 이상 프론트엔드 구현자에 머무르지 않고, Product Engineer로 일하고 계셨다. 그 과정을 옆에서 지켜보며 문제를 넓게 보고, 결과와 가치를 함께 묶어 생각하는 시야를 배울 수 있었다.

프로덕트 엔지니어는 똑같이 코드를 쓰지만, 시선이 다르다.
컴포넌트와 로직을 만드는 사람에서, 문제의 본질과 사용자 반응을 연결하는 사람으로 이동한다는 뜻이다.
그리고 이 이동이 창업관을 바꿨다.

실험이 만든 성장 루틴

생각해보면 과거와 지금의 취업/창업 환경은 분명 다르다.
몇 년 전만 해도 창업은 많은 사람에게 “큰 결심”이었다.
대형 팀, 많은 자본, 오랜 시간의 준비라는 조건이 너무 거대해 보였다.

지금은 AI와 도구 생태계 덕분에 초기 진입 장벽이 낮아졌고, 아이디어를 검증하는 속도도 훨씬 빨라졌다.
모든 걸 완벽하게 준비할 필요가 없다.
짧은 실험과 빠른 피드백으로 방향을 잡아 가면 된다.

취업 시장에서도 변화가 뚜렷했다. 단순히 스펙을 채우는 방식이 아니라, 스스로 실험하고 배운 흔적을 가진 사람을 더 찾는다.
실패 경험이 남는 것이 아니라, 실패를 다뤄낸 방식이 남는다.
성공보다 중요한 건 거기에 담긴 학습의 질이다.

팀 문화로 익힌 방식

당근 팀 동료들을 보면 창업 경험이 있거나, 적어도 ‘언젠간 해볼 거다’는 마음을 가진 사람들을 많이 만났다.
그 분위기는 나에게 자극이면서도 안도감이었다.

도전은 더 이상 ‘대단한 사람의 영역’이 아니었다.
작은 실험도, 실패한 시도도, 방향 전환도 모두 하나의 작업 프로세스였다.

나는 동아리 후배들을 만날 때면 예전처럼 조심스럽게 못 박아 두지 않는다.
“해야 한다”가 아니라 “해보라”에 가까운 말을 더 많이 한다.
내가 얻은 결론이 간단하다.

• 시도는 언제나 완벽하지 않아도 된다.
• 다만 기록 없이 흘려보내면 안 된다.
• 배운 바를 다음 판단으로 옮기는 과정이 중요하다.

팀에서 배운 구현 방식

팀에는 아주 꼼꼼하고 섬세한 동료들이 많았고,
그 성향이 내 성장에도 큰 기준이 됐다.
인턴십 이전부터 나는 동료들에게 항상 같은 말을 했다.

• PR에는 고민이 다 담겨야 한다.
• 셀프리뷰에는 왜 이 코드를 이렇게 썼는지가 보여야 한다.

나는 그 기준을 지키려 노력했지만, 팀의 실제 운영 방식은 이 철학을 더 현실적인 프로세스로 정리해줬다.
가장 단순하면서도 핵심적인 메시지는 이랬다.
기능 구현은 “한 번에 완성”하는 작업이 아니라, 루틴화되는 프로세스여야 한다는 것.

우리가 필요로 한 건 결국 서로를 신뢰할 수 있는 환경이었다.
이상적으로는 리뷰가 많아야 할수록 좋은 게 아니라,
리뷰를 하면서도 서로 신뢰를 쌓아가며 반복적인 동작을 줄이는 방향이 되어야 했다.

그래서 팀은 “코드를 작성하기 전 싱크가 핵심”이라고 강조했다.
내가 가장 잘 기억하는 문장은 이랬다.

코드를 작성하기 전에는 가장 어렵고, 코드를 작성할 때는 가장 쉽게 느껴져야 한다.

구체적으로는 이 순서였다.
먼저 피처 스펙을 명확히 정리해 사전 합의하고,
그다음 Tech Spec을 써서 구현 방식과 사용자 경험 체크리스트로 엣지케이스를 점검한다.
스펙이 머릿속을 정리해주면, 코드 작성은 훨씬 자연스러워졌다.

PR 본문도 프로세스의 일부다.
작업 내용, 스크린샷, 동작 영상까지 담으면
리뷰어가 “기능은 맞는지”는 빨리 판단하고,
그 뒤로 코드 레벨의 디테일만 집중해서 보게 된다.

그리고 거기서 끝나지 않는다.
한 줄 한 줄에 의미를 부여하고, 배포 후 모니터링까지 루틴으로 가져가는 흐름이
팀 생산성을 끌어올리는 실제 동력이라는 걸 같이 봤다.
이 경험은 “좋은 코드”의 기준을 품질 하나로 설명하지 않고,
과정까지 포함한 신뢰의 기준으로 확장해줬다.

그 신뢰는 루틴에서 시작됐다. 아침에 출근하자마자 linear를 최신화해 두는 것이 기본이었다.
그건 단순히 업무 체크처럼 보이지만, 팀원들이 내가 한 일을 어디서부터 어디까지 했는지 믿을 수 있게 만들어 주는 신호였다.
결국 이건 코드 실력보다 먼저 ‘함께 일할 수 있는 신뢰’라는 사회적 기초를 세우는 행동이었다.

이런 맥락에서 팀에서는 극적으로 공감되는 말이 하나 있었다.

개발은 극 F 성향이거나, 극 T 성향이어야 잘 할 수 있다.

처음엔 과장된 말처럼 느껴졌지만, 들을수록 맞는 구도였다.
극 F 성향은 동료의 불편함을 줄이는 쪽으로 사고한다.
어떤 가독성이 가장 편한지, 어떤 Slack 알림이 과한지 덜한지,
배포 후 비개발 직군이 한눈에 상황을 파악할 수 있게 어떤 정보를 담아야 하는지까지 고민한다.
실제로 나는 PR 제목을 더 많이 고민하게 됐다.
한눈에 기능과 영향이 보이는 문장을 쓰려고 노력했고, 배포 알림에도 필요한 스크린샷을 붙여 맥락을 채우려 했다.

극 T 성향은 반대로 효율에 집중한다. 더 빠르게, 더 적은 비용으로 더 정확히 만들 방법을 끊임없이 찾는 쪽이다.
내가 배운 건 이 둘의 충돌이 아니라, 보완이 필요하다는 점이다.
팀에서 ‘친절함’이 뭘 뜻하는지 기준을 다시 세웠고,
그래서 내가 성장한 건 코드 레벨만이 아니라, 팀 전체를 움직이게 하는 의사소통 레벨이었다.

아침이 기다려지는 날들의 기준

이전에 말한 실험과 속도의 리듬은 결국 일상에도 그대로 옮겨왔다.
아침형 인간인지 아닌지는 이제 중요한 분류가 아니라,
내가 아침을 기다리는 삶을 살고 있는지가 더 중요해졌다.
매일 조금이라도 설레고 도전하고 싶은 마음이 생겼기 때문이다.

전에는 개발이 곧 정답처럼 느껴졌다.
내일은 어떤 문제를 어떻게 해결할지, 어떤 개선을 할지에 대한 생각으로 잠이 깨어나곤 했다.
그래서 아침이 좋다는 게 아니라, 개발이 내 하루의 시작점을 당겼다고 보는 게 맞다.

그런데 그 시선도 또 바뀌었다.
한때는 깊이 파고드는 지적 과정 자체를 성취로 착각했고,
그래서 그 과정에서 스스로 만족하는 쪽이 강했다.
인턴십을 지나며 깨달은 건 달랐다.
행복은 머리로 입증하는 데서 오는 게 아니라,
팀원들에게 내가 맡을 수 있는 방식으로 가치를 주고, 매일 떠오르는 아이디어로 실제로 무언가를 개선해가는 데서 생긴다는 점이었다.
그 순간의 인정이 비로소 오래 남는 성취로 다가왔다.

개발이 재밌다는 건 여전히 같다. 다만 내가 말한 “왜 여전히 개발을 좋아하나”의 의미가 바뀌었을 뿐이다.
과거의 나는 아이디어는 많았지만, AI를 활용한 개발엔 거부감이 있었다.
공학이기보다, 코드는 내게 예술처럼 완성되어야 하는 대상처럼 느껴졌고,
AI가 만든 코드를 보면 신뢰하기보다 과정을 통제할 수 없다는 불편함이 컸다.

그런데 당근알바 팀은 다르게 움직였다.
한국에서 AI 활용이 가장 적극적인 조직 중 하나였고, 실제로 내가 그 문화를 피부로 배웠다.
특히 팀에서 자주 반복되던 이야기는 이랬다.
‘철저한 규칙 아래에서 사람이 코드를 일일이 적는 일이 없어져야 한다’는 말이었다.
규칙과 설계를 먼저 세우고, 사람은 AI가 코드를 작성해도 되는 방향으로 사고를 바꾸는 것.
나는 그 주장에 점점 동의하게 됐다.

이제는 AI를 단순한 보조 도구로 쓰는 수준이 아니라,
남들이 덜 쓰는 방식으로 효율을 극대화하는 데 쓰고 있다.
주니어라서 더더욱 다뤄야 할 건 코딩 기교보다,
AI가 반응할 수 있게 만드는 내 지식의 체계였다.

그래서 더 이상 “실현 못 할 아이디어가 있다”는 느낌이 덜했다.
도전은 점점 자연스러워졌고, 3D 모델링·영상 작업처럼 이전엔 멀게만 느꼈던 것들도 시도해 보게 됐다.
지금의 나는 왜 아침이 기다려지는지 알겠다.
개발이 재밌어서가 아니라, 여러 영역에서 아이디어를 움직이는 과정이
나를 매일 아침 설레게 만들기 때문이다.