코딩이 막힐 때 어떻게 해야 하나요?
개발자 청춘 상담실 #8
* 책으로 출간되었습니다.
해당 브런치에 남김 글은 초고입니다. 완성된 작품은 해당 "오늘도, 우리는 코딩을 합니다."로 출간하였습니다!! 완성된 글을 종이책의 정감과 편안함으로 읽어보시길 바랍니다^^
감사합니다.!!
http://www.yes24.com/Product/Goods/100514084
안녕하세요. 개발자님!!
모든 개발자여, 야망을 가져라!
- 선다 피차이 (구글 CEO)
개발자에게 좋은 욕심은 발전을 만들어줍니다. 이런 욕망은 좀 더 나은 단계로 넘어가는 동기부여가 되기도 합니다. 좀 더 나은 개발자가 되기 위해 혹은 회사에서 필요한 인재가 되기 위해 갖는 마음은 욕심이라는 단어보다 야망(野望)이라는 단어와 좀 더 어울리는 거 같습니다. 윈스턴 처칠은 학교 성적은 꼴찌였지만 책에 대한 욕심이 많아서 지나칠 정도로 5~6시간씩 독서를 했습니다. 후에 그는 노벨 문학상을 받았고 영국의 총리가 되었습니다. 워렌버핏은 청소년기에 공부를 잘하지 못했지만 경제서적에 대한 욕심이 많았다고 합니다. 그는 버크셔 해서웨이의 최대 주주이자 세계적인 가치투자자가 되었습니다.
“회사가 실패하는 이유는 야망이 없기 때문이다. 벤처기업의 열정과 도전정신으로 회사를 운영해나갈 것이다.” 구글을 공동 창업한 래리페이지(Larry Page)가 경영에 복귀한 후 직원들에게 한 말입니다. 구글은 개발자에게 야망 가지라고 강조합니다. 이러한 야망은 지금도 구글이 발전하는데 큰 동력이 되고 있습니다. 위험을 감수하지 않고 성공을 쟁취할 수 없다는 사실을 가장 잘 이해하는 기업이 바로 구글입니다. 야망으로 태어난 기업도 구글입니다. 차고지에서 검색 사이트를 만들던 이 기업은 세계 모든 데이터를 정돈하는 데부터 우주여행까지 야망 가득 찬 행보를 향해가고 있습니다.
하지만 마음먹은 대로 되지 않는 건 누구나 느끼며 살아가는 고통입니다. 동료는 벌써 저만치 앞서 나가고 인정받고 있는 거 같은데 나는 아직도 반도 못하고 있으면 당연히 스스로에게도 화가 나기도 합니다. 하지만 사람은 누구나 가지고 있는 능력의 넓이가 모두 다릅니다. 스스로를 탓하지 말고 자존감이 낮아지지 않도록 실망하지 않았으면 좋겠습니다. 개발자님의 긍정적인 욕심을 응원합니다. 지금과 같은 야망으로 좋은 프로그램을 만드는 프로그래머가 되기를 기대합니다.
질문을 하세요
질문은 하나의 코딩 능력이고 개발자의 역량입니다. 혹시 풀리지 않는 지점에서 혼자 고민하고 앓으면서 해결하려고 지나치게 시간을 보내는 건 아닌지요? 모르는 부분인데 혹시 물어보지 않고 개발하고 있는 건 아닌지 조심스럽게 묻고 싶습니다. 봐도 봐도 모르면 문제를 해결 할 수 있는 선배나, 선생님에게 꼭 질문을 해야 합니다. 내비게이션이 길을 잃은 사람에게 현재 위치를 확인하고 다시 목적지로 걸어가게 해 주듯 코딩하면서 길을 잃었다면 코딩을 진로를 도와줄 내비게이션을 실행시켜야 합니다. 테슬라와 스페이스 X의 CEO인 일론 머스크는 이렇게 말합니다. "대개 질문을 찾는 일이 답을 찾는 일보다 더 어렵다. 만약 질문을 제대로 던질 수 있다면, 답 찾기는 식은 죽 먹기다." 일부 코딩 학교에서는 질문을 교육과정의 일부로 도입하기도 합니다. 이처럼 프로그래머에게 좋은 답을 얻기 위한 물음표는 좋은 실력을 쌓을 수 있는 스킬이 되었습니다.
2008년 만들어진 스택오버플로우(Stack Overflow)는개발자들의 프로그래머들 질문과 답변으로 이루어진 커뮤니케이션 사이트입니다. 해결하지 못한 난관을 사이트에 질문으로 올려두면 멋진 선배 개발자들이 명쾌한 답변을 달고 이를 질문자가 채택하는 방식입니다. 어려운 질문을 해결한 답변자에게는 명성이라는 포인트를 주어집니다. 이렇게 매겨진 사용자 평가 1위는 재직 중인 소프트웨어 엔지니어는 존 스킷(Jon Skeet)입니다. 구글에서 코딩의 관한 검색어는 상당수 스택 플로우로 연결될 정도로 질문과 답이 쌓인 노하우의 거대한 데이터베이스가 되었습니다. 해당 사이트를 보면 정말 개발자는 언제나 의문을 갖고 숙제를 해내가는 직업이란 걸 알 수 있습니다. 스택오버플로우 사이트를 사용할 때 몇 가지 지켜야 할 매너가 있습니다. 이 방법은 현업에서도 유의해야 할 질문 요령과 비슷합니다. 그중에 몇 개를 요약하여 어떤 질문이 효과적인지 알아봅니다.
"먼저 스스로 검색하고 해결해봐야 합니다." 만약 '1+1'이라는 더하기 문제를 어린아이가 묻는다면 기특하고 웃음이 저절로 납니다. 아이에게는 어려운 문제일 수 있으니깐요. 그런데 개발자가 이런 기초적인 질문을 한다면 즉 다시 말해 충분히 혼자 해결 가능한 것들을 묻는다면 사실 기분이 매우 나쁩니다. 간단한 구글링을 통해서도 해결 가능한 걸 묻는다는 건 본인이 순간적인 답답함을 못 이겨 답변자를 이용하는 것처럼 비치기 때문입니다. 질문하기 전에 충분히 도전해봤지는 생각해봐야 합니다.
"문제를 요약하여 제목으로 작성하기" 요약이 필요합니다. 명확하게 어떤 화면에서, 어느 소스에서, 몇 번째 줄이 어떤 문제를 일으키고 있는지 명확하게 설명할 수 있게 요약을 해야 합니다. 두괄식이란 결론을 먼저 말하고 그것을 여러 문장으로 서술해 나가는 글쓰기로 방식을 말합니다. 이는 보고서나 제안서를 쓸데 많이 사용하는 양식입니다. 읽는 이에게 글의 핵심과 논지의 흐름을 쉽게 알 수 있게 합니다. 질문도 이처럼 두괄식으로 해야 합니다. 그러기 위해서는 현재 문제에 대해 요약하여 제목으로 정할 수 있어야 합니다. 오프라인에서 직접 물을 때도 두괄식으로 먼저 정확한 문제를 이야기하고 도움을 요청해야 합니다.
"문제를 재현하도록 준비하기" 디버깅은 직접 눈으로 확인하고 수정하는 과정이 필요로 합니다. 유지보수에서도 특정 컴퓨터에서만 나는 오류가 갑장 잡기 어렵고 수정하기 애매합니다. 이처럼 나의 문제에 대해 정확한 도움이 필요하다면 오류를 재현할 수 있도록 준비하는 게 효과적입니다. 만약 도움을 받아야 하는 사람의 컴퓨터에서 똑같이 오류를 흉내내기 어려울 때가 있습니다. 이때는 화면을 캡처하여 이미지를 출력해가서 어떻게 문제가 생겼는지 재현하는 방법이 필요합니다. 이런 과정 없이 도움을 요청하면 답변자는 문제를 파악하기 위한 일부터 시작하게 됩니다. 그리고 개발자는 언제나 바쁩니다. 최대한 도움의 시간을 아낄 수 있도록 해줘야 합니다.
그래도 막힌다면
16시간 정도 흘렀던 거 같습니다. 출근하고 나서부터 밤 10시까지 오류를 수정했던 거 같습니다. 아침에 일찍 회사에 도착하니 팀장님에게 전화가 왔고 내일 오픈해야 할 프로젝트 작은 오류가 났고 이거만 해결해달라는 전화였습니다. 선배 개발자는 전부 파견이 나가 있던 바람에 도움을 요청할 손길도 없었고 결국 혼자 사무실에 앉아서 압박감으로 오류를 수정하려고 했지만 정말 어떤 방법을 써도 해결되지 않았습니다. 그렇게 자포자기하고 잠깐 근린공원을 산책하고 편의점에서 라면을 사 먹고 다시 자리에 앉았습니다. 밤 11시고 남은 시간은 1시간뿐이었습니다. 그런데 신기하게도 아주 사소하게 문법 철자가 틀린 게 눈에 들어왔고 키보드를 몇 번 두드리니 오류는 사라지고 매끄럽게 실행되는 사이트를 보면서 허탈한 한숨을 쉬던 기억이 납니다.
오랜 시간 해결되지 않는다면 잠시 덮고 생각을 환기시켜 보시길 바랍니다. 생각이 멈출 때 오히려 좋은 아이디어가 떠오를 수 있다고 합니다. 심리학에서는 이런 현상을 브루잉 효과 (Brewing effect)라고 합니다. 논리적 사고가 막다른 골목으로 들어설 때 잠시 멈춤으로 생각을 직감에 맡기는 방법입니다. 잠시 쉬거나 다른 일을 해보는 걸 추천합니다. 급한 게 아니라면 내일 다시 한번 맑은 정신으로 문제를 바라볼 때 새로운 시각이 열릴 것입니다.
혼자 앓지 마세요.
동료가 있습니다!!
참조자료
- 장원청, 『 심리학을 만나 행복해졌다 』, 김혜림, 미디어숲, p30
- https://stackoverflow.com/help/on-topic
