나는 지금 다르게 일 하고 있다 (부제: SI - 서비스 기업 이직기)

안녕하세요~!

비전공 프론트엔드 개발자 1년 회고를 썼던 기억이 엊그제같은데 벌써 해가 지났네요!

오늘은 근황이자 제 경험담을 살포시 공유하고 가려고 합니다...

---

글 소개

저는 비 전공 프론트엔드 개발자로, 일을 시작한지 1년 반 정도 되는 주니어 개발자입니다.

이 글은 중간 규모의 SI 기업에서 서비스 기업으로 옮긴 저의 경험담이며, 각 환경에 따라 제가 했던 성장의 노력 및 일 했던 방법을 적은 글입니다.

저의 경험과 생각에 의존해서 작성된 글이니 만큼, 철저히 개인적인 시각으로 봐주시면 감사하겠습니다.

제가 SI 기업이나 서비스 기업의 평균적인 무엇을 대변하지 못한다는 뜻이라고 보셔도 무방합니다.

나는 이렇게 일 하고 있었다

내가 다녔던 회사

첫 회사이자 이전 직장은 대기업의 1차 벤더로 일을 하는 SI 기업이자 동시에 자체 서비스를 운영하는 스타트업 이었습니다. 자체 서비스와 SI프로젝트를 같은 프로세스로 진행하려고 노력하는 회사인데, 지금 생각해도 외주라고 대충대충 하는 느낌은 없었습니다.

SI 기업을 많이 겪어본건 아니지만, 정말 많이 배웠고 같이 일 하는 동료들이 너무 좋은 분들이라 좋은 기억이 많이 남습니다. 기본적으로 처우에 비해(?) 열심히 하는 사람들이 많아서 회사가 정말 채용도 잘 하고 운도 있었다고 생각하는 곳입니다.

SI 기업에서 일을 잘 한다는 것

산출물의 퀄리티 > 코드 퀄리티

SI기업은 기본적으로 서비스를 제작하고, 클라이언트에게 요건에 맞게 납품을 하는게 가장 최 우선 목표입니다. 그러니 당연하게도 실 사용자 및 클라이언트에게 노출되는 산출물의 퀄리티가 압도적으로 중요합니다.

기본적으로 빡빡한 일정에 코드 퀄리티까지 맞추면서 프로젝트를 진행하기 어렵고, 나중에 유지보수를 저희가 한다고 하더라도 ‘나중에 해결할 시간이 생길거야..' 라는 마음으로 미루게 됩니다.

기본적으로 코드 퀄리티를 꼼꼼하게 봐주는 사람이 드물고(다들 이미 자기 일로 바쁩니다) 일정이 다가올수록 코드 퀄리티에 대해서는 점차 아무도 말을 하지 않게 됩니다.

즉, 일단 기능이 되게 하는 것이 미덕이자 실력이 됩니다.

그러나... 사실 코드가 이상하면 산출물이 좋기 어렵고 요건이 조금만 바뀌어도 소요되는 시간이 기하급수적으로 늘어납니다.

어떻게든 일정 지키기

정해진 일정을 지키지 못하면 정말 많은 사람들에게 피해를 주게 됩니다.

우리 회사 PM, 클라이언트, 협력사 등 많은 사람들의 이해관계가 섞여있어 일정은 매우매우 중요합니다.

특히 대기업 외주를 하는 경우 임원 등의 높은 사람들에게 시연도 해야하기 때문에... 우리 회사 내의 일정을 유동적으로 관리하면서 유연하게 대처하기가 정말 어렵습니다.

때문에 기본적으로 생산성을 위한 라이브러리 도입에 적극적이며, 해당 라이브러리의 구조를 뜯어보고 원리를 파악하기 보다는 공식문서를 보고 빠르게 익혀 실무에 활용할 수 있게 하는데 중점을 두게 됩니다.

생산성을 위한 라이브러리를 사용하는게 결코 나쁜건 아니지만, 추후 요건이 변경되거나 예상치 못한 버그가 생기면 결국 그 만큼 디버깅에 소요되는 시간이 늘어나게 되면서 일종의 기술부채 역할을 하게 됩니다.

커뮤니케이션

당연한 말이지만, 산출물이 정확하게 나오려면 요구사항에 대해 명확히 이해해야 합니다.

역시 당연한 말이지만, 일정을 잘 지키려면 엉뚱한 기능을 구현하는 커뮤니케이션 삽질등으로 시간을 낭비하면 안 됩니다.

그리고 현실적으로, 구현이 어려워 자신의 능력 밖인 어려운 기능이 있다면 어떻게든 해보겠다고 끙끙 대면서 시간을 다 날리면 좋은 소리를 듣기는 어려울 것입니다.

요구사항에 대해 명확히 이해해서 같은 일을 두 번 하지 않게끔 하고, 능력 밖의 태스크가 할당되면 해당 사실을 빠르게 PM이나 상급자에게 전달해서 현실적인 타협안 또는 다른 팀원에게 도움을 요청하는게 미덕이 됩니다.

그 뿐만 아니라 때로는 협력사 혹은 클라이언트와 기능과 기술에 대해 소통을 해야 할 경우도 있으니 커뮤니케이션 능력은 매우매우매우 중요합니다.

당연하게도 위와 같은 능력들이 SI기업에서만 중요하거나 높게 평가받는 능력은 아니라고 생각합니다. 다만, 업무의 특성상 SI기업에서 조금 더 우선시 되는 역량이라고 생각합니다.

현실적인 문제들

코드 리뷰 없는 산출물 리뷰

SI기업에서는 리뷰 자체가 산출물을 위주로 이뤄집니다. 앞서 말했듯이 산출물이 제일 중요하기 때문입니다.

또한 코드를 리뷰하는데 시간을 할애할 수 있을 정도로 여유가 있는 개발자가 매우 드물었습니다.

산출물에 대한 리뷰는 PM, 기획자, 디자이너 등 비교적 많은 사람들이 할 수 있지만, 코드 리뷰는 일정 수준 이상의 수준을 가지고 있는 동료 개발자의 존재가 필수이기 때문입니다.

제가 일했던 환경이 시니어 개발자 혹은 동료 개발자들의 도움을 받을 수 없는 환경은 아니었습니다. 제가 도움을 요청할 때 마다 좋은 동료들이 기꺼이 시간을 내서 봐주고 조언도 받았지만, 그럼에도 깊이 있는 코드리뷰를 받기는 현실적으로 어려웠습니다.

내 일정 ≠ 내 일정

태스크를 받고 스스로 계획한 일정대로 일이 풀리지 않습니다. 앞서 말했듯이 이해관계자가 많기 때문에, 이해관계자들의 일정이나 상황에 따라 일정이 급변합니다.

특히 저는 프론트엔드 개발자로서 백엔드(협력사)가 일정이 밀리게 되면, 제가 아무리 병렬적으로 일을 하려고 노력해도 일정 부분 프론트엔드 일정도 밀리게 됩니다.

결국 외부 요인으로 인해 야근과 주말출근이 불가피한 상황이 생겼습니다.

협력사와 의사소통을 직접?

PM들의 개발지식이 있다고 하더라도, 실질적으로 구현부에 있어서 깊은 의사소통을 해야 할 경우에는 담당 기능을 개발하는 팀원이 직접 협력사 직원이랑 커뮤니케이션을 해야 할 경우가(드물지만) 있었습니다.

의사소통 결과에 대해 팀 내에서 공유를 해야 할 상황도 있기 때문에, 이해관계자가 많아지고 커뮤니케이션 채널이 분산 될수록 커뮤니케이션 비용이 늘어나게 됩니다.

특히 저같이 내향적인 사람들은 커뮤니케이션에 사용하는 에너지가 많기 때문에, 개발에 쓸 에너지도 부족한데 협력사와 진행하는 회의가 길어지면 그 날 하루는 녹초가 되었습니다.

성장하기 위해

끊임없이 고민하기

저는 이러한 환경에 굴복하고 하던 일만 하면서 익숙해지기가 너무 싫었습니다.

물론 산출물만 잘 나오면 그만이라고 생각하고 아무 생각 없이 하려면 할 수 있었지만, 훗날의 자신을 위해 더 좋은 구조를 찾기 위해 개인 시간을 활용해 공부했습니다.

주로 했던 공부 방식은

• 깃헙에서 리액트 관련 오픈소스 뜯어보기
• 리액트 관련 유명한 개발자 레포지토리 살펴보기
•  틈틈이&꾸준히 CS 공부하기

등등이 있었습니다.

지금 생각하면 구조등을 깊이있게 살펴보며 공부하지 못했던 것 같은데, 그럼에도 다른 사람의 코드를 보는 것 자체가 굉장히 많은 공부가 되었습니다. ‘저렇게 짤 수도 있구나' ‘더 좋은 방법이 있구나' 등을 많이 느꼈습니다.

시간배분의 노하우

최대한 외부 요인으로 인한 일정 꼬임이 발생하지 않도록, 일정 자체를 ‘외부의 영향을 받는 일정' - ‘영향을 받지 않는 일정' 으로 나눴습니다.

‘외부의 영향을 받는 일정'을, ‘영향을 받지 않는 일정'으로 만들기 위해서 여러가지 시도를 했습니다.

• Mock api 만들기
• 정의 가능한 인터페이스 최대한 미리 정의하기
• 다양한 기본 UI 컴포넌트 및 재 사용성을 고려해서 비슷한 업무의 생산성 올리기
• 변경 가능성이 높다고 생각되는 기능은 구조를 러프하게(다양한 변경에 대응할 수 있게끔) 잡아두기

이 중에서 특히 mock api 작업과 구조를 러프하게 잡아두는 방법은 추후 시간을 아끼는데 정말로 유용했습니다.좋은 설계가 개발자의 시간을 얼마나 줄여줄 수 있는지 몸으로 깨닫게 된 계기가 되었습니다.

반응형 의사소통

커뮤니케이션은 기본적으로 상대에 대한 이해가 없이는 오히려 비용이 크게 드는 일이라고 생각합니다.

저는 주로 아래와 같은 이해관계자들과 소통을 해야 했습니다.

• PM
• 기획자
• 클라이언트
• 협력사(백엔드)
• 동료 개발자

각 이해관계자들은 각 위치와 입장에서 가지고 있는 배경 지식, 알아야 하는 지식의 범위가 모두 달랐습니다.

만약 개발 지식이 부족한 PM에게 동료 개발자에게 하는 언어로 소통을 한다면, PM은 제가 하는 이야기를 이해하기 위해 두 번 세 번의 질문을 추가적으로 하게 됩니다. 차라리 처음 이야기를 할 때 상대방이 이해할 수 있는 수준으로 소통하게 된다면 추가적인 커뮤니케이션 비용을 아낄 수 있습니다.

반대로 동료 개발자에게 구현해야 할 기능을 추상적으로, 기획자에게 커뮤니케이션을 하듯이 비유와 은유를 사용해 하게 되면, 추후 전혀 다른 엉뚱한 기능을 구현하는 경우도 있었습니다.

이처럼 각 커뮤니케이션 대상에 따른 이해를 바탕으로 최적의 커뮤니케이션을 하는 게 결국 커뮤니케이션 비용을 줄일 수 있는 지름길이라는 것을 알게 되었습니다.

나는 이렇게 일 하게 되었다

내가 이직한 회사

기존 회사에 불만이 없지는 않았지만, 이직을 마음먹을 정도는 아니었습니다.

그러던 중, 우연히 한 서비스 기업에서 제 블로그를 보고 관심이 생겨 간단한 티타임을 갖고 싶다고 연락이 왔습니다. 개발팀과 이야기를 나눠보니 더 재미있게 일을 할 수 있을 것 같았고, 함께 일 하면서 더 큰 성장을 할 수 있을거라는 확신이 생겨 이직하게 되었습니다.

물론 처우도 훨씬 좋아졌습니다. 약 40%정도 인상이 있었네요

서비스 기업에서 중요한 것

구조에 대한 끊임없는 고민

서비스 기업은 아무래도 소프트웨어의 수명주기가 SI 프로젝트와는 달리 길다보니, 유지보수와 확장성이 더욱 중요하게 여겨졌습니다.

서비스 기업에서 일을 시작하면서 본격적으로 OOP에 대해 다시 공부하고, 더 나은 소프트웨어가 무엇인지 진지하게 고민하게 되었습니다. 신기하게도 ‘객체지향의 사실과 오해' 라는 책을 1년 전에 읽었는데, 그 때 뜬구름 잡는 듯 느껴졌던 이야기들이 지금 다시 읽으니 머릿속에서 코드로 변환되어서 읽히는 신기한 경험을 했습니다.

한 프로젝트에 연관된 동료 개발자들이 아무래도 SI 시절보다 많아지다 보니, 협업에 있어 고려해야 할 점이 많아졌습니다.

PR을 통해 코드 리뷰를 진행하고, 모든 코멘트가 resolve 되어야 해당 브랜치가 머지 가능한 절차가 있었기 때문에, 코드 리뷰를 하는 동료 개발자가 읽기 좋게 가독성도 신경써야 했고, 특히나 컴포넌트 이름(변수명)은 해당 컴포넌트가 해석되는 컨텍스트, 할 수 있는 일과 해야 하는 일을 함축적으로 담고 있는 아주 중요한 것이며, 때문에 매우 신중하게 정해야 한다는 것을 깨달았습니다.

수준 높은 동료들의 코드 리뷰를 받으면서 구조와 설계, 인터페이스에 대해서 전혀 다른 시각을 갖게 된 계기가 되었습니다. (지금도 매 PR 마다 크게 배우고 있습니다)

꼼꼼함과 집요함

입사한지 얼마 되지 않아, 사용하고 있는 라이브러리 중 하나가 원인인 이슈가 발견되었습니다.

버전 업데이트를 통해 손쉽게 문제 해결이 가능했는데, 이 때 해당 라이브러리의 패치기록을 보고 소스코드 내의 변화까지 한 줄 한 줄 비교해서 영향도를 확인하는 모습을 보고 매우 놀랐습니다. 당연한 것일수 있겠지만 기존 기업에서는 아무도 이렇게 하는 사람이 없었는데, 프로젝트에 영향을 줄 수 있는 요소들에 대해서 정말 꼼꼼하게 검증한다는 생각이 들었습니다.

뿐만 아니라, 버그 등의 이슈가 생겼다면 문제의 원인을 끝까지 파고들어서 파악하고, 재발 방지를 확실하게 하는 경우가 많았습니다. 단순히 ‘안 되네? 이렇게 하면 되니까 이렇게 하자’가 아니라, 문제 해결 이후에도 ‘그건 왜 안 되었던 걸까' 에 대해 끝까지 알아내고 동료들과 공유하는 방식이었습니다.

역시 커뮤니케이션

커뮤니케이션은 SI 기업, 서비스 기업과 무관하게 개발자에게 가장 중요한 능력 중 하나라는걸 다시 한 번 깨달았습니다. 다만 소통에 있어서 고려해야 할 점이 조금 달랐습니다.

서비스 기업의 경우에는 SI 기업보다는 동료 개발자와 소통을 할 일이 더욱 잦았기 때문에 확실한 워딩이 매우 중요했습니다. 같은 개발자여도 기본적인 지식이나 환경에 대한 차이가 있기 때문에, 사소한 단어의 차이에도 전혀 다른 이해를 하는 경우가 생겼습니다.

그리고 코드 리뷰를 통해 좋은 피드백을 주는 능력과, 동료의 피드백을 이성적으로 수용하는 능력이 필요했습니다.

기존 회사에서 1년동안 받은 코드 피드백의 양보다 이직 후 1달간 받은 코드 피드백이 퀄리티도 높고 양도 더 많았는데, 개인적으로는 돈 주고도 못 살 정말 값진 경험이라는 생각이 들어 동료들에게 정말 감사했습니다.

테스트는 사치일까?

테스트 코드 비용에 대한 고민

개인적으로 테스트와 테스트 코드에 관심이 많아 이전 회사에서도 공부해서 도입해 본 경험이 있었습니다.

회사에서 아무도 테스트 코드를 작성해 본 사람이 없다보니, 어떻게 해야 하는지 잘 몰라 맨 땅에 헤딩 하듯이 작성했던 기억이 납니다. 유닛테스트는 엄두도 못 내고, 정말 중요한 비즈니스 로직에 대해 검증할 수 있는 플로우별 테스트 코드를 작성했습니다.

하지만 테스트 코드 작성에 드는 시간과 비용에 비해 테스트 코드로 얻을 수 있는 효용이 얼마나 되는지에 대해 의구심이 항상 있었습니다. 테스트 코드 작성이 너무 어려웠고 그 때문에 시간이 오래 걸렸기 때문입니다.

하지만 사실 테스트 코드 작성이 어려운 이유는, 테스트 대상이 되는 코드 자체에 문제가 있었기 때문이었습니다.

가성비 있는 테스트 코드

서비스 기업, 특히나 테스트 코드를 제대로 고민해서 작성하려는 기업에 와보니, 테스트 코드와 테스트는 서비스 기업에서는 결코 사치가 아니었습니다. 테스트를 작성하면서 기존 코드의 문제점을 알 수 있었을 뿐만 아니라, 테스트가 불가능한 어려운 코드는 좋은 코드가 아니라는 원칙하에 컴포넌트간의 역할과 책임에 대해 좀 더 깊이 이해하게 되었습니다.

일을 시작하기 전에 테스트 describe를 통해 명세를 명확히 정의하고 시작할 수 있어 작업의 모호함이 줄어들었고, 무엇보다 테스트를 잘 짜 놓으니 리팩토링 및 기능 변경시에 두려움이 없어지게 되었습니다.

리팩토링을 진행하고 영향도를 체크하는데 부담이 적어지니, 검증에 필요한 시간이 줄어들면서 자연스럽게 개발 속도도 빨라지게 되었습니다.

앞으로도 성장하기 위해

끊임없는 공부

이전 회사에서 ‘끊임없는 고민’을 통해 성장했다면, 지금 회사에서는 ‘끊임없는 공부'를 해야 한다는 생각이 듭니다.

물론 스스로 하는 고민은 앞으로도 계속 중요하지만, 결국 누군가가 더 깊은 고민을 통해 체득한 선험적인 지식은 그 양과 질이 스스로의 고민보다 뛰어나기 마련입니다.

즉, 책을 많이 읽겠다는 다짐입니다.

기존에 개발 서적을 잘 읽지 않았던 이유중 하나는 읽어도 뜬구름 잡는 추상적인 말로 느껴지면서 소화가 어려웠기 때문인데, 얼마 전 개발 서적들을 읽으면서 이제는 어느 정도 소화가 가능하겠다는 확신이 생겼습니다.

사놓고 미뤄두던 서적들, 그리고 프론트엔드 팀에서 추천하는 서적들을 읽으면서 최대한 제 것으로 소화해 보려고 합니다.

동료들과 자극 주고받기

이전 회사에서도 좋은 동료분들이 많았지만, 지금 회사에서는 정말 수준 높은 동료들이 양질의 피드백을 아낌없이 주는 덕분에 개발자로 성장하는데 그 어느때보다 가속이 붙은 기분입니다.

개발팀에서 주기적으로 진행하는 세미나 역시 양질의 퀄리티로 진행이 되고 있어 들으면서도 배우는 부분이 많고, 제 스스로도 세미나를 준비하는 과정에서 배우는 것도 정말 많습니다.

이렇게 좋은 자극을 통해 성장하게 되니 자연스럽게 저도 동료들에게 좋은 자극을 줄 수 있는, 서로 성장하는 관계가 되고 싶은 생각이 듭니다. 또 이러한 생각 덕분에 개인 시간에 공부를 더욱 열심히 할 수 있게 되었습니다.

앞으로도 동료들에게 부끄럽지 않은 개발자가 되기 위해 꾸준히 노력하려고 합니다.

마치며

경험담을 적으려고 시작했던 글이, 뭔가 막연한 다짐으로 마무리되는 것 같습니다.

짧은 제 경험에 비추어 볼 때, 첫 취직을 하시는 분들이 SI 기업이라고 무작정 두려워하거나 경원시 하지 않아도 된다고 생각합니다. 저는 서비스 기업으로 이직 후 매우 만족하고 있지만, 이전 직장에서 열심히 하지 않았다면 지금 회사에 오기 힘들었을 것이라고 생각합니다. 실제로 이직 후 온보딩 프로젝트를 하고 피드백을 받으면서, 이전 직장에서의 노력이 결코 헛되지 않았다는 사실을 깨닫고 매우 기뻤습니다.

제가 했던 방법이나 경험이 결코 정답은 아니지만, 이 글을 읽는 분들 중에서 제 글을 읽고 작은 아이디어나 약간의 자극이라도 얻는다면 정말 뿌듯할 것 같습니다.