첫 회사, 1년 동안 배우고 느낀 점들
엘리스그룹의 프론트엔드 개발자로 첫 경력을 쌓아나가게 되었다.
최근 1년 2개월의 경력을 끝으로 퇴사하였다.
회사 다니느라 너무 바빠서 글 1년동안 하나도 못 썼다.(핑계다)
기술적인 부분 외에 배우고 느낀 점들을 정리해보려고 한다.
지금부터 적는 내용들은 바쁘고 정신 없는 스타트업에서는 비슷하게 적용될 것 같다.
1. 실무 개발 = 이데아를 찾는 과정
그간 회사에서 짠 코드의 대부분은 다 짜고 난 후, 혹은 짜다가도 이런 생각이 든다.
"아 훨씬 잘 짤 수 있을 것 같은데..."
평소 작문에 흥미가 있는 나는 처음에 멋있는 글을 쓰고 싶다는 생각을 했었다.
그렇지만 멋있는 글을 쓰는 것보다 더 어려운 것은 쉽게 읽히는 글을 쓰는 것이었다.
👉 기습 책 추천 내가 생각한 인생이 아니야. 저자 류시화
유지보수에 용이한 코드, 확장성 및 Readability가 뛰어난 코드, 구조가 잘 설계된 코드 등등 항상 지키고 행하고 싶은 원칙들은 많다.
코드도 글과 같이 쉽게 읽히는 코드가 위 원칙들을 만족하는 경우가 많은 것 같다.
그렇지만 코드를 짜다보면 이는 생각처럼 잘 되지 않는다.
실무에서 이를 방해하는 요소가 크게 세 가지가 있다고 보았다.
- 복잡한 요구사항
- 레거시 코드 (= 기술 부채)
- 촉박한 마감기한
당연하게도 코딩을 할 때 온전히 코드에만 집중하기는 어려웠다. 결국 회사에서 짜는 대부분의 코드는 복잡한 비즈니스를 프로그래밍 언어로 빠르게 풀어나가는 과정이고, 그 과정에서 나는 수많은 타협을 하게 된다.
위 세 가지에 대해 하나하나 설명하지 않아도 대부분 감이 올 것이라고 생각하여 적지 않겠다..
아무튼 실무에서의 개발은 이런 험난함 속에서도 최적의 코드를 찾아나가는 과정이라는 것을 느꼈다.
특히 기한이 빡빡할 때는... 시작부터 잘못 짰다고 느낄 때가 있어도 뒤엎지 못하고 다시 또 부채로 쌓이는 경우가 많았던 것 같다. 꼭 전체적인 구조부터 잘 잡아나가자.
세 줄 요약
1. 바쁘고 정신 없을 때 코드 짜기 힘들다
2. 그냥 몸에 체화시키고 계속 의식하며 개발해야한다.
2. 초반 구조를 잘 잡자. 기술 부채는... 2. 도메인
나는 교육 도메인에 관심이 있었다.
한 때 꿈이 선생님이기도 했었고, 코딩 과외를 1년 정도 한 경험도 있었기 때문에 교육 도메인은 재미있을 것이라고 기대했다.
그러나 기업 대상으로 하는 코딩 교육, 디지털 교과서 등 교육 플랫폼을 만드는 일은 내가 생각하던 교육과는 달랐다.
내가 관심 있었던 부분은 실제 교육을 하는 교육자의 입장이었지, 교육자와 학습자를 이어주는 플랫폼이 아니라는 것을 깨달았다.
추가로 나는 유저 혹은 서비스와 좀 더 맞닿아있는 개발을 하고 싶다는 걸 알게되었다. 사실 회사를 다니면서도 내가 직접 유저가 되어 서비스를 사용하는 일이 적었고, 배포 이후에도 유저의 반응을 확인하기가 어려웠다.
결국 개발을 꾸준히 하게 만드는 원동력은 성취감이었는데, 1년 동안 내가 이런 서비스를 만들었다! 라는 데에서 오는 성취감은 적었고 이게 큰 퇴직 사유가 되기도 했다.
이직을 처음 마음 먹은 2월 즈음에는 아무 회사나 적당히 괜찮아 보이면 지원하곤 했는데, 최근에는 정말 관심이 가게되는 곳을 위주로 지원하였다.
다행히 그 중 가장 마음에 들었던 곳에 합격하게 되어 곧 출근 예정이다. 야호~
세 줄 요약
1. 교육 도메인 내 스타일 아니다
2. 내가 만들어낸 것이 효과가 있던 없던 그 정도를 아는 것 자체가 중요하다.
임팩트가 있었다면 성취감을 얻고, 없었다면 절치부심하게 된다. (아님 말고)
3. 취업했다. 야호~3. 효율적인 커뮤니케이션을 못하게 하는건 능력보단 상황
이미 인터넷에 널린 좋은 커뮤니케이션의 예시가 많지만, 나도 한 번 적어보련다.
한 번에 할 수 있는 말을 여러 핑퐁에 나누어 하게되는 경우를 지양하고, 같이 알아야하는 사람이 있다면 잘 전달하기 등만 지켜도 중간은 가지 않을까?
~ 비효율적인 예 ~
000 디자이너님, 이 부분 디자인 스펙 개발 코스트가 커서 수정하여도 괜찮을까요?
"네, 어떤 식으로 수정할까요?"
원형 버튼은 디자인 시스템에 커스텀해야하는 부분이 많아서, 대신 기존의 토글 버튼으로 수정하면 좋을 것 같아요.
"네, 그러면 그렇게 수정하시죠! 피그마에도 수정해둘게요."
~ 몇 시간 혹은 며칠 후 ~
@기획자 님 여기서 논의되었습니다!
"음 그런데 토글 버튼은 사용성 측면에서 ~~"
...~ 개선해본 예 ~
000 디자이너님, 이 부분 디자인 스펙 커스텀할 부분이 많아보여서요,
원형 버튼 대신 디자인 시스템의 토글 버튼으로 수정하여도 문제 없을까요?
cc. @기획자님 @동료 프론트엔드 개발자
...일부만 보여주는 예시긴 하지만, 내가 생각하는 어느정도의 기본이 담겨있다고 생각한다.
바쁘고 정신없는 상황에서 특히 중요하게 생각하는 요소들을 정리해보자면
- 멘션 하나에 질문 / 요구사항 / 그로 인한 효과 등을 적어 비효율적인 코스트 없애기
➡️ 글로 설명하기 힘들면 그냥 찾아가서 여쭤보고 이후 글로 다시 정리해두는 것도 좋은 것 같다. - 서로 이해하고 있는 부분이 명확히 일치하는지 확인
➡️ 가끔 이해한 것 같아도 서로 다른 방향을 바라보고 있을 때가 많다. - 작업에 관련된 사람들이 모두 최신의 정보를 알 수 있도록 신경쓰기
➡️ 최고는 처음에 딱 정하고 안 변하는 것이지만..그러기는 쉽지 않으니
세줄 요약
1. 개발이나 커뮤니케이션이나 한 걸 다시 하는게 최악의 코스트이다.
2. 커뮤니케이션으로 중간을 못 가는 경우가 연차 불구하고 많다.
능력이 안된다기보다 상황 혹은 태도가 문제인 것 같다.
3. 나도 여전히 잘 못하지만 최소한 고치려고 한다. 이게 제일 중요하다고 생각한다.적다보니 스타트업 절망편처럼 적은 감이 없잖아 있는데, 결국 나도 사람인지라 좋았던 점보다는 아쉬웠던 점들이 더 남는 것 같다. 그럼에도 불구하고 그 아쉬웠던 점들 덕분에 나는 훨씬 성장할 수 있었다 like 나를 죽이지 못하는 고통은 나를 더욱 강하게 만들뿐. 좋은 점들은 배우고, 아쉬운 점은 스스로 개선해나가면 된다 like Deep Learning.
적고 싶은 것들이 더 많았던 거 같은데 기억이 안나서 일단 줄인다.
생각나면 추가로 적어야지
1년 동안 힘들고 지칠 때도 많았지만, 성장하고 즐거웠던 기억들도 정말 많이 남아있다. 특히 부족한 나에게 많은 것들을 가르쳐준 프로덕트 팀 동료들에게 무한 감사하다.
Thank you
