정말 뛰어난 웹 개발자가 되려면 무엇이 필요할까요?
첫 프로그래밍 직장에 다니고 있다면, 쉽지 않다는 사실을 금방 깨달았을 겁니다.
코딩 튜토리얼을 보고, 프로그래밍 서적을 읽고, 포트폴리오 사이트를 만드는 것과는 별개로, 명세서에 맞춰 웹사이트를 구축하고 마감 기한을 지키며 무엇보다 상사와 클라이언트를 만족시켜야 하는 일은 전혀 다른 차원의 이야기입니다.
게다가 기술은 빠르게 변화하죠. 트렌드를 따라가지 못하면 곧 낡은 개발자가 되어버릴 것 같은 불안감도 듭니다.
하지만 여기 비밀 하나 알려드리죠. 두려워할 필요가 없습니다.
일을 계속하다 보면 경험이 쌓입니다. 코딩을 배웠던 것처럼, 직장에서 뛰어난 성과를 내는 법도 배울 수 있습니다.
좋은 웹 개발자가 되는 법을 배우는 것이 가능하고, 심지어 대체 불가능한 웹 개발자가 되는 것도 가능합니다. (물론 고용 안정을 보장할 수는 없지만, 제 말뜻은 아시겠죠.)
저는 정식 컴퓨터 과학 과목을 한 번도 들어본 적 없는 독학 웹 개발자입니다. 약 7년간 이 분야에서 일해왔고, 가파른 학습 곡선과 가면 증후군(impostor syndrome)과 씨름해왔습니다.
하지만 그 과정에서 소중한 경험과 기술도 많이 얻었습니다. 아마 여러분의 경험과 비슷한 부분이 있으실 겁니다.
제 첫 직장 이야기
주니어 웹 개발자로 첫 회사에 입사했을 때, 저는 세상을 다 가진 기분이었습니다.
그런데 솔직히 말하면, 처음 2년은 공포의 연속이었습니다.
매일 업무 중에 도저히 방법을 모르는 일을 해야 했고, 어디서부터 시작해야 할지조차 감이 잡히지 않았습니다.
스스로가 무능하다고 느끼는 순간이 많았습니다.
다행히 모든 일은 잘 풀렸습니다. 길을 잘 알려주는 후배를 아껴주는 상사와 동료들이 있었고, 어떻게든 마감 기한도 모두 지켰습니다.
시간이 지나면서 스트레스도 예전만큼 크지 않았습니다.
그리고 4~5년쯤 지나자 비로소 내 실력에 자신감이 생기기 시작했습니다. 5년이라는 시간이 아주 길게 느껴질 수 있습니다. 특히 이제 막 시작한 분들에게는 더욱 그렇죠.
하지만 이것만 기억하세요.
성공은 하룻밤에 오지 않습니다. 하지만 포기하지 않고 열심히 노력한 날들, 몇 주, 몇 달, 몇 년 끝에 반드시 찾아옵니다.
짧은 커리어 동안 많은 것을 배웠다고 생각하며, 그렇게 각고의 노력 끝에 현재 자리를 얻어낸 신입 웹 개발자들에게 도움이 되고 싶습니다.
군중 속에서 돋보이게 만들어줄 몇 가지 원칙이 있습니다. 이 원칙들을 실천하면 회사와 고객에게 진정한 자산이 될 수 있습니다.
아직 취업 전이라도 학습 과정에서 대부분의 원칙을 적용할 수 있습니다.
흔치 않은 수준 높은 웹 개발자가 되고 싶으신가요? 계속 읽어보세요!
1. 무언가를 완벽하게 익히는 것은 단거리 경주가 아니라 마라톤임을 이해하기
부트캠프나 대학을 졸업하고 바로 취업에 성공했다면 정말 축하할 일입니다! 다만 지금은 코딩 여정의 시작점에 불과하다는 점을 기억하세요.
웹 개발은 방대한 분야이며, 다른 모든 기술과 마찬가지로 진정으로 실력을 갖추는 데에는 오랜 시간이 걸립니다. 앞으로 갈 길이 멀고, 지금 이 순간에도 모르는 것이 산더미처럼 많습니다.
하지만 괜찮습니다! 당신은 초보자입니다. 지금 당장 모든 것의 전문가여야 한다는 기대는 없습니다.
제가 초등학교 5~6학년 때였습니다. 언니가 SAT(미국 대학 입시 표준화 시험) 준비를 시작했는데, 어린 동생인 저도 따라 해보고 싶어서 연습 문제를 풀어봤습니다.
당연히 결과는 처참했습니다. 한 문제도 맞히지 못했던 것 같습니다. 어린 나이에도 승부욕이 강했던 저는 만점을 받지 못했다고 화를 냈었죠.
여러분은 코딩 문제를 못 풀었다고 화를 내지 않으실 겁니다. 하지만 마찬가지로, 지금 이 순간 모든 것을 알아야 한다고 생각하지 마세요.
그건 비현실적일 뿐 아니라 엄청난 스트레스의 원인이 됩니다.
물론 웹 개발 실력을 키우고 싶은 마음은 가져야 합니다.
다만 자신의 성장 과정을 조망하는 넓은 시야를 유지하고, 현재 자신의 위치를 현실적으로 받아들이세요.
눈앞의 이 순간만이 아니라 커리어 전체의 장기적인 관점에서 생각하는 습관이 중요합니다.
2. 도움을 요청하기 전에 최대한 스스로 먼저 노력하기
초년 시절, 미지의 영역을 탐험해야 한다는 부담감은 상당한 불안을 안겨줬습니다. 모르는 문제를 반드시 해결해야 한다는 압박감을 느꼈습니다.
그런 상황에서 선택지는 두 가지였습니다. 상사에게 찾아가 "죄송한데, 이걸 어떻게 해야 할지 모르겠어요. 대신 해주실 수 있나요?"라고 말하는 것.
단기적으로는 부담이 덜겠지만, 장기적으로는 결코 좋지 않은 선택입니다. 해결책을 스스로 찾지 못하는 직원은 결국 다른 사람들의 시간을 빼앗게 되니까요.
다른 선택지는 최대한 스스로 조사를 해보는 것입니다. 그러다 보면 결국 제가 이해할 수 있는 한계점에 닿습니다.
그때 비로소 상사에게 가서 이렇게 말합니다. "죄송한데, 이 문제를 해결하지 못했어요. 지금까지 시도해본 방법들은 이렇고, 아마 이것과 관련이 있는 것 같은데요..."
차이가 보이시나요?
포기하고 남에게 일을 떠넘기는 대신, 최대한 스스로 노력했습니다.
그리고 도움을 요청할 때는 이미 스스로 노력한 흔적을 보여줬습니다.
스스로 조사하고 실험하는 과정은 새로운 개념을 독학하는 능력을 길러줍니다. 이는 두 가지 이득이 있습니다.
실무 중에 새로운 기술을 배우는 셈이니, 사실상 배우면서 돈을 받는 격입니다. 또한 스스로 해결할 수 있는 질문으로 상사나 동료의 시간을 뺏지 않습니다. 회사에 부담이 아니라 자산이 되는 거죠.
물론 반대편 극단도 있습니다. 도움을 요청하면 금방 답을 얻을 수 있는 문제에 며칠씩 매달리는 경우죠. 이 역시 문제에 너무 많은 시간을 소모하는 것이므로 바람직하지 않습니다.
어디까지 스스로 시도하고 언제 도움을 청할지는 본인이 판단해야 합니다. 하지만 경험을 쌓다 보면 적절한 균형점을 찾을 수 있을 겁니다.
3. 호기심을 유지하기
입사 초기에 자주 받았던 칭찬 중 하나는 정보를 스펀지처럼 흡수한다는 것이었습니다.
정확한 방법을 몰라도 일단 시도해볼 용기가 있었고, 사실 물건이 작동하는 원리가 정말 궁금했습니다.
사물이 작동하는 원리를 이해하고자 하는 갈증이야말로 모든 엔지니어의 핵심입니다. 그 갈증을 호기심으로 채우세요.
일을 처리하기 위해 그 호기심을 꺼버리지 마세요. '왜'를 이해하는 것은 무척 중요합니다.
무언가 하는 방법을 검색할 때, Stack Overflow 코드 조각에서 답을 발견했다고 거기서 멈추지 마세요.
급한 마감에 쫓기는 상황이 아니라면, 몇 분 더 시간을 들여 그 해결책이 내 코드와 어떻게 맞물리는지 살펴보세요.
예전에는 코드가 왜 작동하지 않았는지, 지금은 왜 작동하는지 이해하려고 노력하세요. 100% 다 이해하지 못해도 괜찮습니다. 개념만 잡으면 됩니다.
이번에 완전히 이해하지 못하더라도, 다음에 같은 문제를 만났을 때는 더 깊이 이해할 준비가 되어 있을 겁니다.
4. 항상 개선하기
이 원칙은 웹 개발뿐 아니라 삶의 모든 영역에 적용됩니다. 요리, 운전, 심지어 인간관계까지요.
뭔가 제대로 되지 않았다고 느껴지면, 한 걸음 물러나 상황을 조망하세요. 스스로에게 물어봅니다. 무엇이 일어나길 원했고, 왜 그렇게 되지 않았는가?
내 코드가 웹사이트를 망가뜨렸다면, 무슨 일이 있었는지, 앞으로 어떻게 하면 재발을 막을 수 있을까요?
동료에게 무언가를 설명하다가 다투게 됐다면, 그 상황에서 무슨 일이 있었나요? 오히려 감정을 악화시킨 발언은 없었는지 돌아보세요.
다음을 실천해보세요.
- 기대에 못 미친 상황을 돌아가며 분석하기
- 무슨 일이 있었는지 파악하기
- 다음에 같은 문제를 피할 수 있는 실행 가능한 방법 찾기
시간이 필요한 일이고, 때로는 모든 결정을 하나하나 돌아볼 여유가 없을 때도 있습니다.
하지만 실수와 갈등을 배움 없이 덮어버리기만 한다면, 같은 실수를 반복할 수밖에 없습니다.
쉽지 않은 일입니다. 부정적인 일이 지나가면 굳이 붙잡고 싶지 않은 게 사람의 본능이니까요.
'인생 디버깅'이라고 생각해보세요. 코드에서 똑같은 실수를 계속 반복한다면 상당히 비효율적이겠죠? 그만큼 배워야 할 것이 남아 있다는 뜻입니다.
작은 실수라도 좋으니, 자기 인식과 자기 개선의 조합을 꾸준히 연습하면 장기적으로 반드시 결실을 거둡니다.
5. 문제 해결 능력을 갈고닦기
웹 개발자의 업무 중 상당 부분은 문제 해결입니다. 새 코드를 작성하든 기존 코드를 디버깅하든, 궁극적인 목표는 원하는 대로 작동하게 만드는 것입니다.
그렇다면 코드 문제 해결 능력은 어떻게 기를 수 있을까요?
먼저, 그것이 정확히 무엇을 해야 하는지, 그리고 그 과정에 관련된 모든 요소가 무엇인지 파악해야 합니다. 그래야 문제가 어디서 발생하는지 찾아내고 수정할 수 있습니다.
고장난 램프 고치기
설명을 위해 작동하지 않는 램프를 고쳐야 한다고 가정해봅시다.
램프를 수리하려면 먼저 '정상 동작'이 무엇인지 정의해야 합니다. 이 경우라면, 스위치를 켜면 전구에 불이 들어오는 것이겠죠.
그렇게 되지 않는다면, 과정의 각 단계를 하나씩 점검하며 어디서 문제가 생기는지 확인하면 됩니다.
이런 목록을 만들 수 있습니다.
- 1단계: 집의 전기가 콘센트를 통해 공급된다. 집에 전기가 들어오는지, 콘센트가 정상 작동하는지 확인한다.
- 2단계: 램프가 콘센트에 연결되어 전기가 램프로 흐른다. 램프 플러그가 꽂혀 있는지 확인한다.
- 3단계: 전기가 램프의 전선과 스위치를 통과한다. 전선과 스위치가 모두 정상인지 확인한다.
- 4단계: 스위치를 켜면 전기가 전구에 도달해 불이 켜진다. 전구가 정상이고 깨지지 않았는지 확인한다.
각 단계를 하나씩 테스트하면, 소거법을 통해 문제의 원인을 좁혀가며 찾아낼 수 있습니다.
물론 코드에서 문제를 찾아 수정하는 일은 전구를 테스트하는 것보다 훨씬 복잡합니다. 하지만 과정은 동일합니다.
솔직히 말씀드리면, 코드 디버깅과 오류 해결은 지독하게 답답할 때가 많습니다. 특정 문제에 며칠, 심지어 몇 주씩 매달린 적도 있습니다. 웹 개발자의 일 중 가장 힘든 부분이죠.
하지만 반대로, 마침내 해결책을 찾아냈을 때의 그 기분은 정말 환상적입니다. 적어도 그 순간에는 만능이 된 듯한 느낌마저 듭니다. 그 환희야말로 웹 개발자라는 직업의 최고의 순간입니다.
비기술 역량을 간과하지 마세요
마지막 두 가지 팁은 지금까지의 주제와는 다소 결이 다릅니다. 전문 웹 개발자에게 필요하지만 코딩과는 전혀 상관없는 역량들이 있습니다.
소위 '사람 기술', 즉 소프트 스킬이라고 부르는 것들이죠.
우리는 코드와 함께 일하지만, 결국 사람과 함께 일합니다. 우리가 만드는 웹사이트와 앱은 사람을 위한 것이고, 어떤 직종이든 인간인 고객, 클라이언트, 동료와 함께 일하게 됩니다.
최고의 웹 개발자는 코딩만 잘하는 사람이 아닙니다. 큰 그림을 이해하고 사람들과 잘 협업하는 사람입니다.
개인적으로 이 마지막 두 원칙이 여러분을 동료들과 확실히 차별화해줄 것이라 믿습니다. 다른 종류의 복합적 사고를 요구하기 때문에 쉽게 마스터하기는 어렵습니다.
그리고 많은 웹 개발자들이 이런 비기술 역량을 키워야 할 필요성 자체를 간과합니다.
바로 여기서 여러분만의 독특한 가치를 만들어갈 수 있습니다.
6. 타인에 대한 공감 능력 키우기
공감이란 타인의 감정, 필요, 관점을 인식하고 이해하는 것입니다. 요컨대 상대방의 입장에 서서 생각하는 능력이죠.
남편과 다툴 때, 우리는 처음엔 서로 감정이 상한 채로 시작합니다. 나는 내가 100% 옳다고 느끼죠. 물론 현실에서는 절대 그럴 리 없습니다! 그래서 힘들고 아픈 대화라도 끝까지 나눕니다.
결국 대부분 단순한 오해였거나 누군가 컨디션이 안 좋았던 경우임을 깨닫고, 서로의 관점에서 상황을 바라보게 됩니다.
핵심은 누가 옳은가, 누가 논쟁에서 '이기는가'가 아닙니다. 상대를 공감하고 같은 페이지에 서는 것이 중요합니다.
마찬가지로 사람들과 함께 일하다 보면 갈등과 의견 차이는 필연적으로 생깁니다.
하지만 성급하게 결론 내리고 상대를 악마화하지 마세요. 상대가 한 말이나 행동은 대부분 개인적인 감정이 섞인 것이 아닙니다.
직접 대화를 나누며 상대의 입장을 알아보세요. 너무 바빠서 이메일 답장을 잊었을 수도 있고, 최악의 회의를 마치고 그 스트레스를 무심코 짧은 답장으로 표출했을 수도 있습니다.
상대를 의심하지 않고 선의로 보는 것을 넘어, 직장에서의 공감이란 동료의 업무량과 상황을 인지하고 존중하는 것까지 포함합니다.
동료가 마감을 앞두고 미친 듯이 일하고 있다면, 급하지 않은 별개의 문제로 그를 방해하지 마세요.
대신 일이 진정된 후에 잘 마쳤는지 안부를 묻는다면 아주 좋은 배려가 될 겁니다.
덧붙여 직장 에티켓에 대해 더 알고 싶다면 'Ask a Manager'라는 조언 블로그를 추천합니다. 직장에서 해야 할 일과 하지 말아야 할 일에 대한 유익한 정보가 가득합니다.
7. 반응하는 사람이 아니라 주도하는 사람이 되기
제 생각에 주도성(proactive)과 반응성(reactive)의 차이야말로 성공한 사람과 평범한 사람을 가르는 핵심 자질입니다.
반응형 직원은 시키는 일은 하지만 그 이상은 하지 않습니다. 문제가 생기면 고치기는 하지만, 재발을 막기 위해 미리 생각하지는 않습니다.
큰 그림이나 시스템의 상호 연결된 부분이 어떻게 함께 작동하는지 고민하지 않죠. 반응형 사람의 기본 마인드는 이렇습니다. "나에게 영향이 없다면 내 일이 아니다."
매우 단기적인 사고방식입니다. 나쁜 일을 하는 건 아니지만, 할 수 있었던 많은 가능성을 놓치고 있는 겁니다.
반면 주도형 직원은 맡은 일을 끝내고 하루를 마무리하지 않습니다. 일하는 과정에서 작은 개선도 함께 만들어갑니다.
문제가 생기면 무슨 일이 있었는지 분석하고 재발 방지를 위한 변화를 만듭니다. 업무 프로세스를 더 효율적으로 만드는 방법을 끊임없이 고민하죠.
요컨대 주도적인 사람은 미래를 개선하기 위해 현재를 살아갑니다.
큰 그림을 볼 줄 알고, 그것을 발전시키기 위해 기꺼이 노력을 기울입니다.
꽤 훌륭해 보이지 않나요?
주도성이라는 기술을 익히려면 시행착오와 많은 관찰이 필요합니다. 하지만 일단 감을 잡으면, 그 혜택은 삶의 다른 영역으로까지 번져나갑니다.
마치며
좋은 웹 개발자가 되는 팁들을 읽어주셔서 감사합니다! 신입 웹 개발자 여러분께 이 글이 조금이라도 도움이 되었기를 진심으로 바랍니다.
궁금한 점이나 하고 싶은 말이 있다면 아래 댓글로 편하게 남겨주세요.