SI 개발자 적응기 ④ | 비전공자 국비지원 과정 수료 후 | 입사 1년 2개월 차 | 일상 | 회사생활 및 느낀점

2022. 7. 2. 과거 유튜브에 업로드한 영상을 정리한 내용입니다.

회사생활

벌써 1년이라니

회사에 다닌 지도 벌써 1년 2개월이 되었다.
평소에는 크게 실감이 나지 않았는데,
“딩딩씨 회사 온 지 벌써 1년 넘었네!”라는 말을 들었던 날,
집에 가는 길에 여러 생각이 스쳐 지나갔다.

국비 학원에서 배운 지식이 전부였던 시절,
과연 회사에서 잘 버틸 수 있을까 걱정하며
학원 친구들과 밤늦게까지 이야기를 나누던 때도 떠올랐다.
“1년 버티면 기적이다”라며 반쯤 농담, 반쯤 진심으로
서로를 위로하던 순간들도 생각났다.

입사 첫 날, 선임님들께 돌아가며 인사드리고
떨리는 손으로 계약서에 서명하던 기억이 아직 또렷하다.

 

연봉 협상

드디어, 말로만 듣던 연봉 협상을 처음으로 하게 되었다.
이전 직장은 개발 직군이 아니었기 때문에
개발자의 연봉 인상률이 어느 정도인지 궁금했다.

주변 개발자 분들께 여쭤보니
신입 기준으로 보통 8~10% 정도 인상되는 경우가 많다고 하셨다.

=> 2025년에 내용 추가: 여태 주변에서 들은 바로는 동결인 회사도 꽤 있는듯하다,, 진짜 회바회인듯

보통은 12월쯤 연봉 협상을 하고
다음 해 연봉에 반영되는 경우가 많은데,
우리 회사는 4월에 협상을 진행했고
5월부터 인상분이 반영되었다.

실제로는 회사에서 미리 제시한 금액대로
계약을 진행하는 경우가 대부분이라
계약서에 연봉이 이미 적혀 있는 경우도 많다.
그래도 본인이 더 높은 금액을 원한다면
지난 1년 동안 어떤 일들을 했는지,
어떤 가치를 만들어냈는지 구체적으로 정리해서
협상에 나서는 것도 가능하다.

=> 2025년에 내용 추가: 자신있게 협상할 수 있는 인재가 되고 싶다^^!ㅋㅋㅋㅋㅋ

 

그동안의 회사생활을 돌아보며

1년 동안의 회사 생활을 돌아보며
기억에 남았던 순간들과 느낀 점들을 정리해보았다.

 

IT 회사, 그곳은 신세계

입사 전에 IT 회사에 대해 직접 들을 기회가 거의 없었기 때문에
“개발자는 어떤 분위기에서 일할까?” 하는 막연한 궁금증만 있었다.
그런 나에게 가장 인상 깊었던 건
생각보다 훨씬 자유로운 근무환경이었다.

전 직장(사무직&연구직)에서는
블라우스에 슬랙스를 맞춰 입는 정돈된 복장이 기본이었는데,
지금은 맨투맨, 트레이닝복, 체크 면바지까지
편한 옷들 위주로 출근하고 있다.

또 하나 신기했던 건 음악을 들으며 일해도 된다는 점이었다.
오전에 진행 상황을 공유하는 회의 1시간,
오후에 개발 이슈를 선임님들과 이야기하는 시간 1시간 정도를 제외하면
나머지는 대부분 혼자 개발에 집중하는 시간이다.
그날 해야 할 기능이 명확하고,
추가로 커뮤니케이션할 일이 없을 것 같을 때는
좋아하는 노래를 들으며 개발하곤 한다.

이렇게 혼자 집중해서 일할 수 있는 환경이
처음에는 정말 신세계처럼 느껴졌다.

 

개발자로 생활해보니: 장점

아직 경력이 길지는 않지만, 개발자로 1년 정도 생활해보니
이 일의 장점과 단점이 조금씩 보이기 시작했다.

첫 번째 장점은 앞에서 말한 것처럼
비교적 자유로운 근무환경이다.
복장, 음악, 업무 진행 방식 등에서
스스로 리듬을 만들 수 있는 부분이 많다.

두 번째는 프로젝트마다 새로운 느낌을 받을 수 있다는 점이다.
입사 후 지금까지 세 번째 프로젝트를 진행 중인데,
프로젝트마다 성격이 다르고 그때그때 맡게 되는 기능도 달라서
쉽게 지루해지지 않는다.

세 번째는 ‘해결의 기쁨’이다.
도저히 안 돌아가던 코드를 붙잡고 씨름하다가
원인을 찾아 해결했을 때, 말로 표현하기 어려운 희열이 있다.
아침에 살짝 기분이 가라앉아 있던 날이라도
하나 딱 해결하고 나면 그날 하루는 기분 좋게 마무리되는 경우가 많다.

 

개발자로 생활해보니: 단점

하지만, 앞에서 말한 장점들은
반대로 보면 그대로 단점이 되기도 한다.

프로젝트마다 새롭다는 것은 곧 매번 새로운 개념과 문제를 만난다는 뜻이기도 하다.
처음에는 비교적 단순한 기능을 구현하지만, 점점 이전에 해보지 않았던 기능들을
스스로 만들어야 하는 순간이 찾아온다.

새로운 기능을 도입할 때마다
그 과정에서 발생하는 문제를 해결해야 한다.
공식 문서를 보고, 검색을 하고,
그래도 안 되면 주변 개발자분들께 여쭤보며
기한 안에 어떻게든 기능을 완성해야 한다.

하지만 회사에서 누군가에게 계속 묻기만 할 수도 없어서
결국 빠르게 실력을 쌓아
“일단은 내가 먼저 최대한 해본다” 수준까지 올라가는 것이
가장 중요한 과제처럼 느껴진다.

또 다른 단점은, 기능이 끝내 해결되지 않을 때의 부담감이다.
맡은 기능은 일정 안에 구현해야 하는데
문제가 쉽게 풀리지 않으면 주말에도 머릿속에서 에러 로그가 떠나질 않는다.
“이건 내가 못한다고 해서 누가 대신 다 해주는 일이 아니다”라는 사실 때문에
심리적인 압박이 커지기도 한다.

그래도 정말 여러 방법을 다 써봤는데도
도저히 답이 보이지 않는다면 그때는 혼자 끌어안고 있기보다
솔직하게 도움을 요청하는 것이 더 중요하다는 걸 배웠다.

선임님께서 진행 상황을 물어보실 때
사실은 잘 안 되고 있지만, 그래도 어떻게든 되겠지라는 마음으로
무조건 “잘 되고 있습니다”라고만 말하는 것은
결국 나와 팀 모두에게 좋지 않다.

충분히 고민해 본 뒤에도 해결이 되지 않는다면
상황을 정확히 공유하고
언제든 도움을 요청할 수 있어야 한다.
(사실 이건 남에게 하는 말이기도 하지만 
가장 먼저 나 자신에게 하는 말이기도 하다.)

 

미리 알았더라면 더 좋았을 도구들

개발을 하다 보면
기존에 사용하던 도구가 불편하게 느껴질 때가 있다.
속도가 느리거나, UI가 불편하거나,
작업 동선이 자꾸 끊길 때가 그렇다.

처음에는 “그냥 이런 거겠지” 하고 쓰다가
나중에 다른 개발자 분들이 사용하는 도구를 보고
“이렇게 편한 게 있었어…?” 하는 순간을 맞이하게 된다.

예를 들어, SSH 접속은 예전에는 PuTTY를 많이 썼지만,
요즘은 MobaXterm 같은 통합 SSH 클라이언트를 많이 사용한다.​

데이터베이스 관리도 콘솔만 사용할 때보다
HeidiSQL 같은 GUI 툴을 활용하면
MySQL, MariaDB 등을 한 화면에서 관리하고
쿼리 실행이나 구조 편집을 직관적으로 할 수 있다.​

로컬 파일 검색 역시 기본 탐색기 검색 대신

Everything 같은 도구를 사용하면
파일 이름 기반 검색 속도가 매우 빨라진다.​

이런 도구들은 처음에는 사소해 보이지만
개발 속도와 피로도에 꽤 큰 차이를 만든다.
그래서 주변 개발자 분들께 “이럴 때 어떤 도구 쓰세요?”라고 한 번쯤 물어보거나,
검색을 통해 다른 사람들이 자주 쓰는 툴을
천천히 도입해 보는 것도 좋은 방법이라고 느꼈다.

 

SI 개발자의 하루는 어떻게 흘러갈까

국비 학원을 다니기 전에는
“학원에서 도대체 뭘 배우지?”가 궁금했다면,
지금은 많은 분들이 “SI 회사에 들어가면 하루 종일 뭔 일을 하지?”를
궁금해하시는 것 같다.

물론 회사마다, 프로젝트마다 다르겠지만 내가 경험한 범위 안에서
신입 SI 개발자의 일을 크게 세 가지로 나눠보면 다음과 같다.

 

1.문서 작업

비율이 크진 않지만, 개발자도 문서 작업을 한다.
사업 시작 전에는 PM이 작성한 제안서에
기술적인 부분을 보완해서 넣기도 하고,

사업이 진행 중일 때는 운영자 매뉴얼, 사용자 매뉴얼,
요구사항 정의서 같은 산출물을 작성한다.

국비 학원에서 팀 프로젝트 할 때 작성하던 산출물과 구조나 목적은 비슷하지만,
실제 업무에서는 양도 많고
조금 더 세부적인 부분까지 신경 써야 한다는 차이가 있다.

 

2. 회의 참여 (요구사항 수렴)

다음은 고객과의 회의 참여다.
주로 PM이 고객을 응대하지만, 특정 기능을 담당하는 개발자가
해당 내용과 관련된 회의에 함께 참석하는 경우도 있다.

회의에서는 고객의 요구사항을 듣고, 현재 개발 진행 상황을 공유하고,
이슈나 변경 사항에 대해 논의한다.
회의 내용을 잘 기록해두면 나중에 개발할 때 기준점이 되기 때문에
처음에는 어렵더라도 천천히 메모 습관을 들여두는 게 도움이 된다.

 

3. 개발

그리고 가장 중요한 업무, 개발이다.

개발 업무는 개인적으로 다음 세 단계로 나눠 생각하고 있다.

1- 기존 프로젝트 분석
2- 기능 구현 전 준비(엑셀 시트 등 정리)
3- 실제 개발

먼저 기존 프로젝트 분석 단계에서는
작년에 진행했던 프로젝트 소스를 내려받아 전체 구조를 파악한다.
우리 회사는 한 해로 끝나는 프로젝트보다는
2차, 3차로 이어지는 장기 프로젝트가 많아서
기존 코드를 이해하는 과정이 꼭 필요하다.

모든 코드를 다 볼 수 있으면 좋겠지만
현실적으로는 양이 너무 많기 때문에
주로 메인 기능과 기본 게시판 기능부터 살펴본다.
메인 기능을 통해 새로 배우는 개념을 정리하고,
게시판 코드는 “이 프로젝트에서의 기본 패턴”을 파악하는 데에 많이 참고한다.

이와 함께 DB 설계안, 요구사항 정의서, 프로세스 정의서 같은 산출물과
PM이 공유하는 회의 기록도 꼼꼼히 읽어보려고 한다.
여기에 고객의 요청 사항이나 변경된 요구사항이 담겨 있기 때문이다.

그다음은 개발 전 준비 단계다.

꼭 필수는 아니지만 나는 정리를 해야 마음이 편해서
개인적으로 구글 스프레드시트로 프로젝트 관리를 하고 있다.

프로젝트 이름을 제목으로 적고,
WBS 세분화, 회의 기록, 개발 일지, 백업 기록, 참고자료
이렇게 다섯 개의 시트를 만들어 사용한다.

• WBS 세분화 시트에는 PM이 작성한 전체 WBS 중
  내가 맡은 부분만 따로 복사해서 붙여 넣고,
  기간과 작업 내용을 더 구체적으로 쪼개서 정리한다.
• 회의 기록 시트에는 매일 아침 회의에서 나온 주요 내용과
  별도로 요청받은 작업들을 적어두고, 완료 여부를 체크한다.
• 개발 일지 시트에는 하루 동안 어떤 작업을 했는지,
  추가로 공부가 필요한 부분이 무엇인지 기록한다.
• 백업 시트에는 언제 어떤 파일을 백업했는지 날자를 남겨둔다.
  (백업은 정말 생명이라고 생각한다.)
• 참고자료 시트에는 기능 개발 시 도움이 되었던 문서,
  블로그, 강의 링크 등을 나중에 다시 찾기 쉽도록 정리해 둔다.

이렇게 시트로 관리하면 수고스럽긴 하지만 꽤 뿌듯하고,
나중에 “내가 이 프로젝트에서 무슨 일을 했는지”를 한눈에 볼 수 있어서 좋다.

이 모든 준비가 끝나면 이제는 정말 코드를 작성하는 시간이다.
이 단계부터는 꾸준히, 그리고 끈기 있게
한 줄 한 줄 쌓아가는 수밖에 없다고 느끼고 있다.

 

느낀점 - 1년을 돌아보며

고객 요구사항 변동과 개선

고객 요구사항을 듣고, 그에 맞춰 개발을 진행하는 과정은
생각보다 훨씬 까다롭다는 걸 몸소 느꼈다.
처음에는 “요구사항 정의서대로만 만들면 되겠지”라고 생각했는데
중간에 추가 요구사항이 생기거나,
이미 만들어둔 UI와 주요 기능을 수정해야 하는 경우가 꽤 많았다.

이런 상황이 반복되는 이유는 크게 두 가지였다.

첫째, 고객사의 내부 정책이 자주 바뀐다.
정책이 변경되면 현재 개발 중인 시스템에도
계속해서 그 내용을 반영해야 한다.

둘째, 완성본을 보고 나서야 사용자 입장에서 불편한 점이 보이기 때문이다.
고객은 디자이너나 개발자가 아니기 때문에
“어떤 기능이 필요하다”는 요구는 말할 수 있지만
사용성까지 고려해 가장 좋은 구현 방식을
처음부터 정확히 제시하기는 어렵다.

그래서 실제 화면과 기능을 보고 난 뒤에야
“여기는 이렇게 바꾸면 좋겠어요”,
“이 기능이 하나 더 있었으면 좋겠어요”
같은 피드백이 자연스럽게 나온다.

개발자 입장에서는 처음부터 수정 없이 한 번에 개발이 되면 가장 좋지만,
현실은 그렇지 않다는 걸 인정하게 된다.
그래서 비슷한 기능을 다른 프로젝트에서 구현해 본 경험이 있다면
처음부터 여러 가지 안을 제시해 보고
사용성과 유지보수성을 함께 고려해서 방향을 잡는 게 가장 효율적이라는 생각을 했다.

 

새로운 기술을 도입하기 어려운 이유와 개발자의 자율성

작년에 회사에서
“이제 React를 배워서 앞으로는 React로 프로젝트를 해보는 게 어떨까”
라는 이야기가 나왔던 적이 있었다.
하지만 여러 논의 끝에 결국
기존에 사용하던 AngularJS로 계속 진행하기로 결정되었다.

그때 느꼈던 건 “기술 하나 바꾸는 일이 생각보다 훨씬 어렵구나” 하는 점과,
“개발자가 원하는 기술 스택을 어느 정도까지

자율적으로 선택할 수 있을까?” 하는 의문이었다.

만약 내가 이미 React를 잘 알고 있는 개발자라서
“내년 2차년도부터는 이 프로젝트를 React로 새로 구성해보면 어떨까요?”
라고 제안한다면, 과연 그대로 적용될 수 있을까?

결론만 말하면, 불가능한 일은 아니지만
대부분의 경우 안정적인 기존 방식을 택하게 된다.

그 이유를 조금 나눠보면 이렇다.

1. 시간 문제
   정해진 기한 안에 프로젝트를 완성해야 하기 때문에
   기존 코드를 새로운 프레임워크로 전환하는 데
   추가로 드는 시간 부담이 크다.
2. 안정성 테스트
   기존 라이브러리와 새 프레임워크가 충돌할 수도 있고,
   원래 잘 되던 기능이 새 환경에서 갑자기 문제를 일으킬 수도 있다.
   이 모든 것을 검증하기 위해서는 추가적인 테스트 시간이 필수다.
3. 여러 명이 함께 개발한다는 점
   팀에는 다양한 경험과 실력을 가진 개발자들이 있고,
   새로운 기술에 적응하는 속도도 모두 다르다.
   어떤 사람에겐 익숙한 기술이 다른 사람에게는 완전히 처음일 수 있다.
   이 간극 때문에 변화에 부담을 느끼는 경우도 많다.

이런 이유들 때문에 “새로운 걸 배워서 바로 실무에 적용해보고 싶다”는 마음과
“현재 프로젝트를 안정적으로 유지해야 한다”는 현실 사이의 간극을 항상 의식하게 된다.

 

계획을 전부 수정해야 했던 이유

올해 초 세웠던 계획을 떠올리면
지금은 조금 민망해질 정도로 방대했다.
계획 영상까지 올려놓은 상태라 지우기도 아깝고,
“언젠가는 하겠지…” 하는 희망을 담아서 일단 남겨두고 있다.

하지만 현실적으로는 그 계획들을 거의 전부 수정해야 하는 상황이 되었다.
그 이유는 2월부터 지금까지의 업무 환경이
생각했던 것보다 훨씬 빠르게, 크게 바뀌었기 때문이다.

2월까지는 업무와 개인 공부를 나름 무리 없이 병행할 수 있었다.
인프런 강의도 듣고, “앞으로 이 계획들을 하나씩 지켜가면 되겠다”라는
설렘이 컸던 시기였다. 

그런데 3월부터 상황이 급격히 달라졌다.

새로운 프로젝트에 들어가면서
이전과는 비교할 수 없을 정도로 난이도와 업무량이 높아졌다.

대용량 데이터를 다루는 업무가 시작되었고,
100GB가 넘는 실험 데이터 파일을
받는 데만 몇 시간이 걸린다든지,
새로운 툴을 학습해 프로젝트에 적용해야 한다든지,
데이터를 파싱해 통계 파일을 만들고
그걸 다시 효율적으로 DB에 넣어야 하는 등
처음 겪는 일들이 대부분이었다.

아무리 시간을 쏟아도 공부가 따라가지 않는 느낌이 들었고,
기한을 맞추지 못해 구현 일자가 일주일씩 밀리는 상황도 생겼다.

4~5월에는 ‘집-회사-집-회사’만 반복되는 삶이었다.
그래도 그 과정에서 작년의 나로서는 상상도 못 했던 개념들을 몸으로 익히게 되었다.

(Bulk insert, 우선순위 큐와 시간복잡도 등 자료구조/알고리즘, 스토리지 마운트 등등..)

모르는 단어 투성이였던 개념들이 조금씩 익숙해지면서
“그래도 예전보다는 조금은 개발자 같아지고 있나…?” 하는 뿌듯함도 느껴졌다.

6월쯤에는 “올해는 일단 업무를 먼저 잘 해내자”라는 결론에 이르렀다.

유튜브에서 보는 많은 개발자들은
주로 스타트업이나 대기업에 계신 분들이었고,
인프런 강의도 React, JPA, 파이썬 등
내가 실무에서 사용하는 기술과는
조금 다른 스택 위주인 경우가 많았다.

“나도 저 흐름을 따라가려면 이것도 배우고, 저것도 배워야 하나?”
하는 생각이 들었지만,

지금 내게 가장 필요한 건 ‘새로운 기술’이 아니라
‘지금 하고 있는 업무를 더 잘하기 위한 공부’라는 걸 조금 늦게 깨달았다.

그래서 요즘은 효율적인 코드와 설계에 집중하려고 한다.

• 효율적인 코드: Effective Java, Clean Code
• 디자인 패턴: JAVA 언어로 배우는 디자인 패턴 입문

이런 책들을 조금씩 읽으면서 “새로운 걸 더 많이”가 아니라
“지금 쓰는 언어와 도구를 더 깊게” 라는 방향으로 공부를 바꾸고 있다.

처음 세웠던 큰 계획들을 올해 안에 다 실천하지 못하게 되어 아쉽지만,
현실적으로 올해 말까지는 업무가 더 바빠질 예정이라
지금은 욕심을 조금 내려놓고 눈앞의 업무와 연관된 공부부터 차근차근 해보려고 한다.

언젠가 예전에 세웠던 계획들을 천천히 다시 꺼내 하나씩 시도할 수 있게 된다면,
그때는 또 영상과 글로 차근차근 나눠보려고 한다.

 

마무리

국비학원에 다닐 때는 “너무 힘들다”는 이야기가 대부분이었는데,
이제는 조금씩 “개발자로서의 일상”에 대한 이야기들이 더 많아진 것 같다.

구독자가 어느새 1400명을 넘었다는 소식을 듣고
“이게 맞나?” 싶을 정도로 놀랐다.
이 채널이 이제는 내 자랑거리 중 하나가 되어버렸다.

내용만 보면 그저 신입 개발자의 소소한 일상 기록일 뿐인데
그럼에도 불구하고 구독해주시고,

댓글로 힘이 되는 말을 남겨주시는 분들께 항상 진심으로 감사드린다.

바쁘지만, 그래도 즐겁게, 가끔은 힘들어도 버티면서
조금씩 앞으로 나아가 보려고 한다.

이 글을 읽고 계신 여러분도 다가오는 한 달,
각자의 자리에서 모두 파이팅하시길 바란다.
함께 오래오래 개발자로 살아남아 보자!