brunch

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 승돌 Aug 19. 2021

개발자가 왜 눈치 봐야 할까?

승돌 쓰다

개발자로 일하다 보면, 가끔 이런 일들을 왜 해야 하는지 왜 이 기술을 써야 하는 것인지 이해가 가지 않을 때가 있다.

내가 짧게 느끼는 회사는 결국 정치가 어느 정도 들어간다.

팀 내에든 부서 내에든 사내 정치가 어느 정도는 있기 마련이고, 그 안에 있는 서비스든 프로덕트든 결국, 그 정치의 희생양이 되기도?! 영향을 받기도 한다.

왜, 어떤 문제 정의 이전부터 기술을 먼저 셋업 하는가?

가끔 이해가 안 된다. 그럼에도 불구하고, 해야 한다. 회사는 그렇다. 내가 하고 싶은 일만 내가 쓰고자 하는 기술을 쓰게끔 하는 곳은 드물다.

왜 그렇게 하는지 새내기 개발자나 경력직 개발자는 이해가 안 될 수 있다.

하지만?! 생각보다 많은 회사, 팀에서 그렇게 돌아가는 경우가 있다. 그렇다고, 바꾸고자 하지만 바꾸기 어려운 이유는 일단, 서비스가 되고 있는 것들은 교체하기가 어렵다. (그래서 서비스 나갈 때는 1-2년, 2-3년은 교체 어렵구나 하고 잘 설계해야 한다.)

교체라는 건 거시적인 관점의 흐름인데 이 흐름은 바꾸기가 정말 어렵다. 미시적인 관점의 코드나 유지보수성 업무는 당연히 수용 가능하다. 그것도 안되면, 문제가 심각한 걸로…

결정권자가 특정 기술만 좋아하는 것도 생각보다 문제가 된다.

본인이 쓰던 기술이나, 선호하는 기술만을 가지고 방향을 정하는 것은 문제가 있다.

이게 결국 앞선 기술을 먼저 셋업 하는 문제의 원인이 되기도 한다.

내 생각에는 나도 그렇고, 결국 적당함이 중요하다. 일단 어떤 문제를 해결하는데 요구사항보다 오버 엔지니어링이더라도 해야 한다면, 하는 게 맞다.

일단 파트 리더, 팀장, 부서장들의 결정 권한이 어느 정도 레벨마다 영역이 있는데 이에 대해서 권한을 가진 자가 이 방향으로 가야 한다면, 그게 무엇이든 정답이다.

그런데, 단! 한 번이나 혹은 여러 번 언급을 해줄 필요는 있다.

상황상, 지금 요구사항 혹은 스펙보다 오버 엔지니어링의 방향이다. 혹은 그 반대이다.라는 의견을 어필하는 건 중요하다.

결국, 내가 인지하고, 업무를 하느냐?! 아니냐?! 이 부분은 중요한 포인트라고 생각한다.

만 5년간 일을 해오고 있으나, 늘 내 생각대로 개발할 수 있지 않다. 개발의 영역은 그게 무엇이든 언제나 커뮤니케이션으로 시작하여, 커뮤니케이션으로 끝이 난다.

그리고, 그 주기가 반복되고 그게 결국 개발자의 숙명이라고 생각한다.

오랜만에 글을 쓰는데, 좋은 이야기는 아닌 개발자 삶에 관한 이야기를 쓴 것 같다. 물론, 이게 회사마다, 혹은 개인마다 해당 되지 않는 이야기일 수 있으나, 나에게는 좋은 발자취가 되지 않을까? 하는 생각으로 글을 썼다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari