해당 글은 작년 12월부터 시작해서 이제 갓 1년을 꽉 채운 주니어 개발자가 2016년 1년동안 스타트업에서 생활하면서 느낀 점을 적은 글입니다. “이렇게 느낄 수도 있겠다!”라며 가볍게 봐주시면 감사하겠습니다.

“어제 그거 봤어? 내가 보기엔 좋아보이더라”

개발자의 성향에 따라 다르게 받아들일 수 있지만 내가 원하는 건 지금 도입하자가 아니라 그냥 대화를 원한다.

프론트엔드의 세계는 급속히 발전하고 있으며 내일이 되면 또 다른 개념과 도구가 등장한다. 개인적인 생각으로는 새로운 기술이 만들어지는 것은 자연스러운 현상이라고 생각하고 그 기술이 만들어질 때 배경이 중요하다고 생각한다. 개발한 동기는 무엇인지, 어떤 문제를 해결하려고 하는 것인지, 그 문제는 어떤 상황에서 문제가 되는지 말이다. “어제 그거 봤어? 내가 보기엔 좋아보이더라”와 같은 질문을 동료 개발자에게 할 때 내가 새로운 기술에 대해 개방적인 것을 아는 개발자분이 스트레스를 받을 가능성이 있다는 걸 알게되었다. 처음에 이런 사실을 깨달았을 때 내가 잘못된 걸까라는 생각을 했지만 지금 생각으로는 새로운 기술을 배워야한다는 부담감과 시장에서 경쟁력있는 개발자가 될 수 있을까에 대한 걱정이 겹쳐서 생겨난 일종의 방어기제라고 생각하고 있다. 새로운 기술에 대해 반감을 가지는 사람도 있을 수 있는데 안정적인 기술 스택이 요구되는 상황에서 생활해오셨다면 충분히 그럴 수 있다고 생각한다. 정리한다면, 내 잘못도 아니며 개발자의 성향에 따라 달라질 수 있다는 것. 내가 이런 질문을 한다면 단지 대화를 원한다는 것.

git, github 사용이 자유로워지고 오픈소스를 바라보는 시각이 변했다.

도구로부터 최대한 자유로워지려 노력하자. 문화를 보려하자.

git, github을 오래전부터 사용했는데 브랜치를 생성해서 커밋을 남기고 마스터에 병합도 해봤고 bisect를 통해 디버깅도 해봤고 fork를 통해 저장소를 만들고 로컬로 내려받아서 수정 후 pull request를 제출해서 기여도 해봤는데 자유롭게 활용하고 있지는 않다는 느낌을 계속해서 받아오고 있었다. 커밋 하나하나 남기는 것 자체가 고된 일이 되고 스트레스가 되고 있다는 것을 깨닫는 순간 왜 이런 문제가 생기고 있는지 혼자 생각하기 시작했다. 커밋을 남길 때 스트레스가 받는 이유는 커밋을 생성한 후 해당 커밋을 수정해야할 상황이 큰 부담으로 다가왔고 rebase를 정확히 이해하지 못해서 커밋을 하게 되면 가장 최근 커밋을 제외하고는(--amend) 불가역적인 커밋이 된다고 생각한 것이다. 이런 문제를 인식하고 rebase를 내가 생각할 수 있는 모든 상황에 대해 적용하고 연습한 결과 지금은 정말 자유로워졌다. 이제는 부담을 가지기 보다는 “좋은 커밋을 작성하려면 어떻게 해야할까?”, “issue와 pull request의 작성은 어떻게 해야할까?”, “github flow, git flow 등 브랜치 전략은 왜, 어떻게 가져야할까?”로 이어졌다.

그리고 github을 통해 여러 오픈소스를 바라보는 시각이 변화했다. 하나의 예를 든다면 angular.js가 digest loop라는 이벤트 루프를 만들어서 dirty checking을 통해 뷰와 모델을 동기화한다는 것을 알게 되고나서 처음 든 생각은 “자바스크립트 자체가 이벤트 루프 기반인데 거기에 자신들만의 가상의 루프를 만든거야? 어떻게 한거지?” 같은 호기심 때문에 어떻게 구현했는지 코드를 보고싶을 때는 해당 코드 부분을 디렉토리 내부에서 찾아서 보기만 했을 것이다. 하지만 지금은 README.md, CONTRIBUTING.md를 읽고 issue와 pull request, label, milestone, 대화, CI 등을 보면서 자리잡고 있는 문화를 보려하고 CHANGELOG.md를 참고해서 배포 주기는 어떤지, breaking changes는 많은지 살펴볼 능력도 생겼다.

또 다른 시각의 변화는 오픈소스는 실질적으로 무료가 아니며 만능이 아니라는 것이다. 하나의 오픈소스를 도입해야할 때는 어떤 도구가 더 우위를 선점하고 있는지, 왜 우위를 선점하고 있는지 각 도구의 장단점은 무엇인지 현재 상황에 더 알맞는 도구는 무엇인지 판단을 내리는 과정에 적지 않은 리소스가 투자된다. 또한 그 오픈소스를 도입한다고 결정을 했더라도 개발자 개인의 학습비용, 도입시 발생한 문제에 대해 해결방법이 존재하지 않을때 직접 기여를 해야하는 상황이 존재할 가능성이 충분히 존재하며 더 이상 메인테이닝되지 않을때 다른 도구로 이전하거나 최악의 경우 직접 메인테이닝해야하는 위험까지 수반될 수 있다. 즉, 의존성을 가진다는 것은 어떤 특정 기술에 의지한다는 것을 의미하고 이는 어떤 상황에서 발생하는 문제점을 해결해줄 수 있지만 자칫 잘못하면 뒷통수를 쎄게 맞을 수 있다는 것을 의미한다. 기술에 적당히 의존하자.

프레임워크와 라이브러리를 선택할 때 고려해야할 사항

어떤 문제를 해결하려고 하는 것인가?
그 문제는 어떤 상황에서 문제인가?
나도 그 문제에 직면한 것인가? 직면했던 것인가? 직면할 것인가?

“react.js를 배워야할 거 같아. 근데 redux도 보통 같이 쓰네? 나도 써야겠다.”

위에서는 뷰 라이브러리인 react.js와 데이터 컨테이너인 redux를 예로 들었지만 단어만 바꿔서 다른 기술에 대입해서 생각해보면 된다. 개발자 개인이 자신의 기술 스펙트럼을 넓히기 위해 새로 배우는 기술 문서의 튜토리얼을 따라해본다던지 제너레이터를 이용해서 프로젝트 구조를 살펴본다던 지 할 수 있다. 현재 내가 새로운 기술을 배울 때 거치는 과정을 의식적으로 생각해봤을 때 아래 같은 과정으로 습득하는 것 같다.

1. 처음에는 프레임워크이든 라이브러리던지 간에 대략적인 개념만 머리에 잡는다.
2. 튜토리얼에 존재하는 코드를 따라 치면서 해당 섹션을 통해 무엇을 가르쳐주려는지 핵심만 이해하려 노력한다.
3. 내 개인적인 생각을 정리해본다.
4. 구글을 통해 여러 가지 글을 살펴본다. (옹호하는 글과 비판하는 글 양쪽 입장을 반드시 골고루 읽는다.)
5. 다시 내 개인적인 생각을 정리해본다.

이렇게 해오고 있는데 요즘드는 생각은 간단한 토이 프로젝트를 만들 수 있는 수준이 되었을 때 몇가지 질문이 해결되지 않으면 정확히 말해서 고민을 해본 시도 자체가 없다면 실제 프로젝트에 도입했을 때 문제를 해결하려고 도입했던 기술이 오히려 문제를 발생시키는 순환참조같은 상황이 발생할 수 있다는 것을 알게 되었다.

해당 섹션의 처음 3가지 질문은 요즘들어 내 자신에게도 자주 하고 있는 질문이다.

오픈소스 커스터마이징을 진행하면서

처음에는 단지 좋아보여서 사용했던 기술이 지금 내 환경에는 맞지 않는 부분이 하나, 둘 보이기 시작했고 마감기한은 다가오지만 핵심 기술로 자리잡은지 오래였다.

“그래, 커스터마이징하자”

이 큰 결정이 너무나 패기로운 결정을 할 때 현재 프론트엔드 프레임워크 및 라이브러리 상황은 이렇고 아키텍쳐 흐름은 어떻고 내 상황은 이렇고 HTML, CSS 구조는 어떻다..라는건 하나도 없는 비논리적인 결정이었다. 일을 시작한지 4, 5개월 정도 되었을 무렵에 커스터마이징을 한다는 결정을 혼자서 내렸다. 팀원과 대화를 할 생각조차 못할 정도로 짐을 혼자 짊어진 것 마냥 부담감을 가지고 있었고 그 부담감은 곧바로 조급함으로 이어져 몇번이나 코드를 다시 작성했는지 모르겠다. 어려운 점은 다음과 같았다.

1. 전체 코드 스타일 및 구조 파악 필요
2. 전체 빌드 과정의 이해 필요
3. 원래 저장소의 기여 절차 및 방법 이해 필요 (문화에 대한 이해)
4. upstream의 수정된 사항들에 대한 반영 방법 고려 및 시기 조정
5. 커스터마이징한 코드의 versioning 문제
6. API 문서화 미흡으로 인해 프로젝트를 코드 레벨에서 이해 필요
7. 객체지향 및 디자인 패턴에 대한 이해도 부족
8. raw 데이터를 다뤘던 경험 부족
9. 각 레이어 사이에 전달되는 메시지 흐름 파악과 worker 사용으로 인한 테스크 큐의 높은 이해도 필요
10. 하…..

진행을 하면 할수록 나는 정말 한참 부족한 개발자구나 내가 멍청하게 결론내렸던 이 결정이 어쩌면 나 하나만의 문제로 끝나지 않고 회사에 영향을 줄 수도 있겠다는 생각이 들었고 미친듯이 공부하기 시작했다. 결론적으로 말하면 내 실력이 성장하는데 가장 큰 영향을 준 것은 커스터마이징이다. 그 누구와도 이 부분에 대해 대화를 나눠본적이 없지만 확실하게 말할 수 있다.

6번의 경우 정말 지옥이었는데 코드는 정말 예술적인데 문서화가 안되어 있어서 개발자를 몇번 욕한지 모르겠다. 보통 관심가는 오픈소스에 기여하고 싶을 때 시작점을 어디서 잡을지 감이 안오는 상황과 비슷한데 이 때는 해당 기술을 직접 호출하는 부분부터 타고 내려갔다. 어떤 함수가 될 수 있고 어떤 객체의 메소드가 될 수도 있다. 코드를 읽으면서 왜 이런 과정을 거치는지 이해하려 했고 특히 비동기 코드의 향연은 인간 두뇌 성능의 한계점을 절실히 느꼈다. 프라미스가 프라미스를 프라미스해서 프라미스를 프라미스한다.

9번의 경우 테스크 큐의 HTML의 스펙, ECMAScript의 스펙을 동시에 확인해야했다. 무슨 context는 왜 이렇게 많으며 내가 알던 웹이 맞는지 단어 하나가 바뀔 때 의미는 왜 이렇게 변하는지 내가 평소에 읽던 영어가 맞는지 나는 왜 이렇게 영어를 못하는지 읽어도 이해가 되지 않는지 참.. 큐와 마이크로 테스크 큐로 나뉜 것에서 왜 또 그 큐가 또 나눠져야하는지 worker의 종류는 또 나뉘고 이벤트 루프는 따로 있고 아몰랑!!! 문서를 계속 읽으면서 이벤트 리스너, 이벤트 루프에 대해 0.1%는 이해한 거 같다.

기술은 그냥 뚝딱만들어지지 않는다는 것. 인하우스 개발시 개발자 개인 그리고 회사의 입장에서 고려해야할 여러가지 요소가 존재한다는 것. 나는 떠나겠지만 내가 만든 문화와 코드는 남는다는 것. 좋은 경험이었으며 아직 진행중이므로 더욱 좋은 경험이 되도록 노력해야겠다.

화성에서 온 개발자 금성에서 온 비개발자

같은 언어를 사용해서 의사소통을 하지만 우리의 시각은 다르다.

회사 내에서 기술적으로 서비스가 어떻게 구성되어 있는지 이해하고 있는 사람은 개발자이다. Multi Page 혹은 SPA(Single Page Application)로 구성되어 있는지 모를 가능성이 매우 높고 단어 자체를 들어봤다고 해도 어렴풋이 아는 사람들이 대부분일 것이다. 마케팅과 관련된 지표를 수집하기 위해 애널리틱스 코드를 넣어야할 때 “해당 스크립트만 넣어주시면 되요.”, “어떤 상황에서 코드만 실행해주면 된데요.”에서 여러가지 요소 때문에 “어떤 상황”과 “코드만 실행” 한다는 게 비개발자가 보기에는 간단해보이지만 개발자가 보기에는 다를 수 있다는 것을 경험했다.

또한 기획자가 서비스의 어떤 기능을 수정, 추가하려할 때 개발자가 보기에 “왜 그렇게 해야되는지 모르겠다”는 생각이 들 때는 보통 기획 의도를 이해하려고 노력하기보다는 기술 부채를 쌓고 if문을 남발하는 것 외에는 방법이 없을 것 같거나 코드 변경이 많아질 가능성이 높아서 이에 대한 반작용으로 나올 때가 많았다.

각자의 시각이 다르니 서로가 endpoint가 되어 대화를 통해 시각의 차이를 줄여서 진행을 한다면 더 매끄럽게 진행할 수 있지 않을까 생각한다. 이런 시각의 차이는 기획, 디자인, 마켓팅, 개발 등 모든 팀에서 가지며 심지어 팀 내부에서도 가질 수 있다. 그 말은 회사에 사람이 많아질수록 의사소통이 중요하며 회사에 자리잡힌 문화가 중요하며 문화를 형성하는 실질적인 멤버들의 생각 하나하나가 너무나 중요해진다고 생각한다. 근데 내가 그 멤버가 됐을 때 그럴 능력이 있을지는 여전히 의문이다. 과연 옳다고 생각하는 문화가 왜 옳은지 설명할 수 있을지 나의 생각에 대해 비판을 하는 팀원의 생각을 수용할 수 있을 그릇의 크기가 되어있을지 개발팀의 문화만을 챙기지는 않을지 이미 자리잡힌 문화에 대해 계약 구조상 상급자에게 의문을 제기할 수 있을지 누구의 잘잘못을 따지거나 격한 말로 감정을 상하게 하기보다는 건전한 토론을 이끌어 낼 수 있을지는 정말정말 의문이다.

마무리

2015년 12월 28일부터 시작해서 정신없이 1년이 지나갔다. 자료구조 기말고사 이틀전에 마음먹고 지원해서 면접을 본 회사에서 이렇게 생활하고 있을줄이야 상상도 못했는데 그냥 나름 잘지내고 있는거 같다. 다만 너무 앞에 놓인 일들에만 집중해서 살지 않았나 반성하게 된다. 내년에는 평소처럼 GDG Busan 스터디 참여하고 사내 스터디도 참여하고 개인적인 개발 공부와 더불어서 제이펍 베타리더스 활동까지 진행할 예정이다. 관심있는 오픈소스에도 기여를 해보고 싶다. 너무 욕심부리지말고 즐기면서 개발을 했으면 좋겠다. 긴글 읽어주셔서 감사합니다.