일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Java
- 코코테라스
- 판교퇴근길밋업
- 커스텀단축키
- 가발자 인사이드아웃
- 편한 즐겨찾기 편집
- 알고리즘 추천
- 기능 많은 브라우저
- JMeter
- 브라우저 단축키
- 오블완
- 소프트웨어 지표
- 코딩
- 초년생
- 스카이라인 열차
- ui 커스텀
- 자동화
- aws
- mac 화면분할
- 대규모 시스템 설계
- 알고리즘사이트
- 알고리즘
- 성능테스트
- 스프링부트
- 조가사키 해안
- spring boot
- 코드트리
- 알고리즘분류
- 알고리즘초보
- 프로그래밍
- Today
- Total
영감을 (inspire) 주고픈 개발 블로그
일의 본질 - 개발자로 회사에서 일을 한다는 것 본문
이 글은 일에 대한 내 생각을 에세이를 통해 적어 본 글이다.
어제 대학교 때 같이 공부하던 친구랑 오랜만에 만났다. 가장 최근 만난 게 코로나 전이었으니 3년은 넘은 것 같다. 그 친구는 이직을 한다고 했다. 나는 최근 주식과 경제 공부를 열심히 하고 있고 예전에 그 친구를 만났을 때 그 친구도 제테크를 관심있다고 한 기억이 있어서 제테크에 관한 이야기를 했다.
그런데 그 친구는 내가 예상한 방향과 전혀 다른 방향의 이야기를 했다.
제테크 공부는 필요하지만 지금은 일을 더 잘해서 연봉을 더 올리는데 집중하고 있다.
사회 초년생이라면 이게 우선시 해야하는 얘기인 건 맞다. 그러나 내가 알기론 그 친구는 연봉이 이미 억대가 넘었다.
그 친구는 3억 이상의 연봉을 바라보고 있었고 제태크로 벌게 되는 돈보다 내가 연봉을 올려서 버는 돈이 더 크게 될 테니 일에 더 집중한다고 했다.
내가 제테크를 공부하기 시작한 건 연봉은 상한선이 어느 정도 있구나란 느낌과 연봉의 상승에 따른 책임이 다르구나를 느꼈기 때문이다. (이건 회사마다 다를 수 있다.)
회사 일에 책임을 지는 것은 무엇이었을까? 그리고 나는 연봉 값을 하고 있는가란 생각이 문득 들었다.
그 친구는 회사에서 해결하고자 하는 일이 무엇인지 파악하고 해결하는 일에 초점을 맞춘다고 했다.
내가 그동안 가졌던 일하는 마인드가 너무 안 좋아졌다는 생각을 하게 되었다.
처음 개발자로 커리어를 시작한 팀은 일종의 AI 쇼룸을 만드는 일을 했다. 당시 AI에 대한 투자가 막 시작한 시점이었지만 우리 회사는 그 전보다 몇 년은 더 투자를 해왔었고 이제 "우리 이 정도 AI 기술을 갖추고 있고 AI로 문제를 해결할 수 있다" 는 것을 보여주고 싶어했다. 그러나 이런 비전은 구성원들한테 잘 전달되지 않은 것 같다.
당시 팀장은 어차피 AI가 주지 우리 서비스팀은 메인이 아니니 기술 공부하고 새로운 기술을 써보자고 했었다. 지금 돌이켜 생각해보면 그 분은 그 때부터 이직을 생각하고 있던 것 같다. 실제로 1년 정도 서비스 런칭을 하고 성공적으로 이직을 하셨다.
회사, 비즈니스 입장에서 어느 기술을 쓰던지 큰 상관이 없다. 문제를 인지하고 해결하는게 중요하다.
어느 정도 개발 능력과 기술에 대한 이해도, 그리고 회사 비즈니스에 대한 이해도와 코드와 아키텍처를 이해하게 되면 문제가 왜 생기는지 어떻게 하면 문제를 해결할 수 있는지 어떤 식이 더 좋게 서비스를 발전 시키는지 알게 되는 경우가 있다.
그런데 그러려면 남들을 설득하고 이해시키고 책임을 져야 한다. 처음에는 그런 시도를 해봤다. 돌이켜보면 섣부르기도 했다. 아직 코드 이해도도 높지 않았고 개발 실력도 그에 미치지 못했으니까. 그래서 그 당시 센터장한테 "시니어가 한 코드를 건들지 말라" 는 말도 들었다. 같이 일하는 사람부터 이해시키고 설득시켜는 게 일의 시작인데 그렇지 못 한게 큰 문제였지만 당시 나는 그 말에 큰 상처를 받았다. 그 이후 수동적으로 일을 받아드리고 시키는 일에 더 집중하게 되었던 것 같다. 그리고 지금 팀에서도 그런 마인드가 있던 것 같아 많이 반성하게 되었다.
계정의 인증과정에서 쉴드라는 새로운 보안 서비스를 적용하는 프로젝트를 진행 중이다. 내가 풀고 있는 문제는 쉴드 서비스가 잘 적용되고 있는지 어느 정도 효용성이 있는지를 보여주는 부분이다.
이 문제를 해결하기 위해 로그를 수집하고 대시보드를 정의해서 만들고 있다. 나는 일을 시작할 때 어떤 프로젝트인지 제대로 알지 못했다. 왜 만들어야하는지 모르고 그저 만들어보라고 해서 만들었을 뿐이었다. 어떤 로그를 받을 수 있는지도 로그의 양이 어느정도인지도 몰랐다. 그러다보니 이제와 데이터베이스 용량을 늘리고 지표를 다시 재정의하는 작업도 하게 되었다. 데이터 로그 플랫폼을 기술에만 집중했지 어떤 데이터를 다루게 되는지에 대해서는 무지했던 게 반성되었다.
이 작업을 제안한건 기획팀이 아닌 우리 팀이 팀장님이었다. 팀장님은 일을 능동적으로 바라보고 이 프로젝트를 성공시키려면 사람이다. 보안 서비스라면 기존의 인증 과정에서 불편을 줄 수 있는데 현재 상태를 파악할 수 있는 수단이 있어야하지 않을까라는 생각을 해서 역제의를 했던 것이다. 역제의다보니 기회의 도움도 받지 못했다. 그 당시 나도 프로젝트에 대해 더 알아보고 고민해봤어야 했다. 그리고 어떤 식으로 해결하면 좋을지를 제안해봤어야했다.
해결은 많이 해본 것 같다. 그런데 나는 회사에서 필요한 일을 정의할 수 있을까
생각이 많아지는 하루였다.
'개발 > 기획-개발 flow' 카테고리의 다른 글
KBO 야구 중계 서비스를 만들기 위한 도메인 이해와 아키텍처 설계 (4) | 2024.03.19 |
---|