솔직히 고백 하나 하겠습니다.
저도 주니어 시절엔 소위 '코딩 괴물'이 되고 싶었습니다.
복잡한 알고리즘을 척척 풀어내고, 남들은 들어본 적도 없는 최신 라이브러리로 프로젝트를 도배하는 모습.
그게 바로 압도적인 실력이라 믿었죠.
그런데 10년 넘게 이 바닥에서 구르며 깨진 후에야 알았습니다.
코드는 그저 거들 뿐이라는 걸요.
최근 구글에서 14년을 근무한 Addy Osmani가 남긴 회고를 읽는데, 머리를 한 대 얻어맞은 것 같더군요.
제가 수없이 삽질하며 배웠던 그 교훈들이 고스란히 적혀 있었거든요.
오늘 커피 한 잔 하면서 그 이야기를 좀 풀어볼까 합니다.
가장 먼저 뼈저리게 느낀 건 '문제 해결'에 대한 착각입니다.
신기술이 나오면 눈이 돌아가죠?
저도 그랬습니다.
GraphQL이 유행하면 굳이 필요 없는 프로젝트에 억지로 끼워 넣고, MSA가 뜬다 싶으면 멀쩡한 모놀리식 서버를 쪼개느라 밤을 샜습니다.
'어떤 기술을 쓸까?'가 먼저였고, '사용자가 뭘 불편해하지?'는 나중이었습니다.
결국 어떻게 됐냐고요?
기술적 만족감은 채웠을지 몰라도, 복잡도만 올라가고 유지보수는 지옥이 됐습니다.
진짜 고수들은 거꾸로 갑니다.
사용자의 고통(Pain Point)을 집요하게 파고듭니다.
티켓을 뒤지고, 로그를 분석하고, "왜?"를 다섯 번씩 물어보죠.
그렇게 문제의 핵심에 닿으면, 의외로 해결책은 심플합니다.
때로는 코드를 짜는 게 아니라, 그냥 프로세스를 바꾸는 게 정답일 때도 있습니다.
기억하세요.
최고의 코드는 당신이 작성할 필요가 없었던 코드입니다.
코드를 안 짜고 문제를 해결했다? 그게 진짜 에이스입니다.
두 번째는 '영리한 코드'의 함정입니다.
한 줄짜리 기가 막힌 정규식이나, 중첩된 삼항 연산자로 로직을 처리했을 때의 그 짜릿함.
"나 좀 천재인가?" 싶죠.
하지만 그 코드는 미래의 나, 혹은 내 자리에 앉게 될 동료에게 보내는 시한폭탄입니다.
새벽 3시에 장애가 터졌다고 상상해 보세요.
비몽사몽 한 상태로 코드를 열었는데, 과거의 내가 쓴 '영리한' 한 줄이 도저히 해석이 안 된다면?
그건 재앙입니다.
Addy Osmani도 말하더군요.
"명확함이 곧 시니어리티(Seniority)다. 영리함은 오버헤드일 뿐이다."
당신의 코드는 컴퓨터가 아니라 '사람'이 읽는 글입니다.
우아함보다는 초등학생도 이해할 수 있는 투박한 명확성을 선택하세요.
마지막으로, '팀워크'에 대한 오해입니다.
기술적 논쟁에서 이기는 게 중요하다고 생각했습니다.
회의실에서 내 논리가 상대방을 압도했을 때의 승리감, 그거 꽤 달콤하거든요.
하지만 논쟁에서는 이겼는데, 프로젝트는 산으로 가는 경험. 해보셨나요?
동료들의 마음을 얻지 못하면, 그 기술이 아무리 옳아도 실행 단계에서 온갖 저항에 부딪힙니다.
"이상한 버그가 있는데요?", "이거 구조가 너무 복잡한데요?" 하는 식으로 말이죠.
옳은 것(Being Right)보다 중요한 건 함께 정렬(Alignment)되는 것입니다.
혼자 100m를 9초에 뛰면 뭐 합니까. 팀원들은 아직 출발선에서 신발 끈 묶고 있는데.
대부분의 프로젝트가 느려지는 건 코딩 속도가 느려서가 아닙니다.
서로 다른 그림을 그리고 있어서입니다.
방향을 맞추고, 인터페이스를 합의하는 데 쓰는 시간은 낭비가 아닙니다. 가장 빠른 지름길입니다.
글을 쓰다 보니 부끄러운 제 과거가 스쳐 지나가네요.
우리는 엔지니어입니다.
코드를 생산하는 기계가 아니라, 기술을 도구 삼아 가치를 만들어내는 사람들이죠.
새로운 프레임워크 공부도 좋지만, 가끔은 모니터에서 눈을 떼고 옆자리의 동료를, 그리고 우리의 서비스를 쓰는 사용자를 바라보세요.
거기에 진짜 성장의 열쇠가 숨어 있을지도 모릅니다.
오늘도 레거시 코드와 씨름하느라 고생 많으셨습니다.
조금은 투박하더라도, 읽기 쉽고 친절한 코드를 남기는 하루가 되시길 바랍니다.
