소프트웨어 엔지니어로서 나의 최고의 조언

Source: Dev.to

Introduction

저는 이전에 신입(주니어) 소프트웨어 엔지니어로서의 경험을 글로 써서 일상 업무에서 얻은 하이라이트와 교훈을 공유했습니다. 그 이후로 저는 다양한 책임을 맡게 되었고, 그때는 깨닫지 못했던 것을 배우게 되었습니다.

저는 1년 반 전에 이 직장을 시작했습니다. 팀의 모든 사람들은 훨씬 더 경험이 풍부했고, 저는 사이버 보안 스타트업에서 처음으로 직업을 갖게 되었습니다. 환경은 빠르게 움직였으며, 저는 거의 알지 못하던 도메인을 이해해야 했습니다.

시간이 지나면서 저는 그 도메인의 기본을 배웠습니다. C#과 .NET에 익숙했기 때문에 처음에는 신비롭게 느껴졌던 개념들을 동료들에게 물어볼 여유가 있었습니다.

스타트업에서는 코드가 끊임없이 준비되고 배포됩니다. 대기업처럼 변화가 느린 경우와는 다릅니다. 큰 기능을 구현할 때는 시니어들이 아키텍트와 이해관계자와 함께 아키텍처를 논의합니다. 저는 그 회의에 들어가서 듣기만 하려고 스스로를 밀어붙였고, 그것이 제 성장의 전환점이 되었습니다.

Don’t just ask “What should I do?”

이것이 제가 드리는 최고의 조언입니다. 진심으로 들어 주세요.

논의 중에 Product Requirements Document와 디자인 목업이 제시되고 있었습니다. 최선의 해결책을 몰랐지만, 저는 그 기능의 큰 부분을 맡고 싶었습니다. 팀에 접근해 해당 기능을 소유하고, 우선순위가 높지 않았기 때문에 탐색할 시간이 있었습니다.

가능한 해결책을 조사하고, 종이에 아이디어를 스케치하고, FigJam으로 간단한 흐름을 만들었습니다. 해결책을 정한 뒤 팀에 제안했습니다. 승인을 받고 구현을 시작했으며, 기능은 성공했습니다. 몇 가지 사소한 버그가 나타났지만 쉽게 해결했습니다.

다른 기능에서도 같은 과정을 반복했습니다: 문제에 대해 브레인스토밍을 하고, 해결책을 문서화한 뒤 아이디어를 제안했습니다. “What should I do?” 혹은 “What should I work on?” 대신에 저는 다음과 같이 물었습니다:

• How would I solve this?
• What works and what doesn’t?
• What are the trade‑offs of this approach versus another?

돌이켜보면, 초기 해결책 초안 작성부터 프로덕션까지 전체 기능을 소유한 것이 제 성장과 학습에 가장 큰 도움이 되었습니다.

Moral of the story

레벨업을 원한다면 단순히 작업을 수행하는 데 그치지 마세요. 질문하고, 탐구하고, 문제를 해결하는 방법을 고민하세요. “What should I work on?” 대신 “How can I solve this?” 라고 물을 때, 새로운 아이디어와 접근법에 마음을 열게 됩니다. 여러 옵션을 보고 최선의 선택을 할 수 있는 문제 해결자가 됩니다.

이 경험이 여러분에게 조금이라도 도움이 되길 바랍니다.

읽어 주셔서 감사합니다.