선배님들의 경험과 조언을 듣고싶습니다

🎓 모두의 Q&A
1

안녕하세요! 지금은 C# 독학 중인 초급개발자입니다. (만 28세)

간단하게 제가 지금까지 상황과 스스로 인식한 문제를 말씀드리면서 천천히 풀어보겠습니다. ㅎㅎ

25살에 첫 회사를 입사했지만, 개발자를 채용한다는 것과 별개로 완전 다른 업무를 하는 회사였습니다. 그래도 첫 회사이니 악으로 깡으로 2년을 버텼습니다.(왜 그랬는지 모르겠네요)

환승으로 두번째 회사로 입사했습니다. 이 회사는 1인 개발로 저렴한 단가로 개발/유지보수 해주는 회사였습니다. 물론 규모가 큰 프로젝트는 없고 다른 개발자와 협업을 할일 도 없습니다. (언어는 VBA, VB)
하지만 두번째 회사에서는 사수가 없어 독학으로 어찌저찌 개발을 이어 나갔습니다. (1인 개발에 막 공부를 시작해 스파게티/외계인 코드가 난무…) 어쨋든 여기까지도 2년을 다녔습니다.

현재는 개발 회사가 아닌 회사에 와서 전 회사에서 공부했던 지식을 바탕으로 회사에서 사용할 서버 관리와 자체 ERP프로그램을 제작중입니다. (C# winform, wfp ) 물론 개발 회사가 아니다 보니 사수와 활용할 개발 모듈은 없습니다. 개발 관련 직원도 저 말곤 없어서 처음부터 시작한다는 생각으로 다시 C# 공부를 시작했습니다. 어쨋든 결과는 가독성과 유지보수성은 낮지만 큰 문제없이 개발을 이어가고는 있습니다. 여기서도 2년째 다니는 중인데 문득 앞으로의 제 개발 능력에 위기감을 느껴 급하게 자격증(정처기) 공부해서 취득하고 다른 자격증도 공부중입니다.

하지만 혼자만이 느끼는 답답함을 느낍니다. 프로그램 뼈대가 부실하다고 해야 하나… 경험이 없다고 해야하나… 실무에서 개발하는 탄탄한 개발 방식에 대해 배우고 싶기도하고 배워야할 부족한 점이 너무 많아습니다. ㅎㅎ 그렇다고 현재 회사는 제가 개인적으로 도움을 많이 받고 있어 당장 나갈 수 없습니다. (개발회사에 들어가서 배우는게 제일 좋겠죠 하지만 당장은 현실적으로 불가)

물론 지금도 계속해서 혼자 공부를 닥치는대로 보고 있긴 하나 방향이 없이 하는 것 보단 지금 부족해서 원하는 것을 배우는게 재미도 있고 좋을 것 같아 선배님들께 여쭤봅니다! 보면 도움이 되는 공부/인강이나 어떤 형태의 조언이든 상관없습니다. 도움 주시면 감사하겠습니다!

두서가 없어 이해하기 어려울 것 같아 예를 들어 부족하다는 느끼는 부분을 예를 들겠습니다…

  1. 프로그램 최신 설계방식 (뼈대라고 해야하나)
  1. 프로그램안에 SQL 구문이 있음 → DB서버에 SQL구문을 저장 ID로 호출 (이렇게 하고싶음)
  1. 대용량 DB 관리와 SQL 심화(지금은 JOIN만 주구장창 쓰지 다른건 활용할 일이 없습니다. 데이터가 많은 경우엔 너무 느리더라구요… 너무 느려서 필요하면 프로그램 내부에서 Linq를 사용하기도 합니다.)
  1. 여러 타 기계와의 연동 경험 부족(이건 계속 해보면 되겠지만 당장에 필요한 팩스기/인터넷 전화 같은 기기와 연동하고 싶은데 어렵네요.)
  1. 프로그램 보안 정책(해킹대비)

놀랍게도 더 많지만 대충 이렇게나 부족한 게 많습니다. 제 상황에서 조금이나마 더 나은 개발자가 되기 위해 앞으로도 더 노력하겠습니다!

4 Likes
2

부족한 제 경험에 빗대어 보면,

말씀하신 부분을 모두 혼자하기엔 제품의 디테일이 떨어지고 번아웃이 오게 될 것입니다.

일정에 우선순위를 두고 자기 컨디션은 자기가 관리해야하며, 이직시에도 일만하다가 내 코드가 남지 않는 사례가 발생하지 않도록 일과 별도로 커리어를 준비하거나, 업무에 커리어를 녹여내야합니다.

  1. 프로그램 최신 설계방식 (뼈대라고 해야하나)

프로그램 최신 설계방식이라는 것은 존재하지 않고, 그런 게 있다고 한들 도메인마다 적용할 수 있는 것은 아닙니다. 여러 대기업이 사용하는 아키텍쳐는 그 대기업 수준이거나 곧 그런 수준이 될 곳에서 적용이 가능한 게 일반적입니다. 대학교에서 배우는 OOP 이론도 적용하지 않고 약간의 고민과 생각도 없이 로직에 집중해서 개발하는 곳도 있을 것이고, 여러 소프트 웨어적으로 저명한 패턴들을 이용해서 고급 추상화가 된 소스코드도 있을 것입니다.

그런 추상화라는 것도 결국 사람들의 필요성에 의해서 나오게 됩니다. 필요가 없는 곳에서는 나오지 않는 거죠. 적은 인원으로 개발할 때도 비지니스가 커질 것을 예상해서 추상화를 어느정도 하고 들어가기는 하겠지만 초고급 추상화를 하는 것은 적은 인원으로 개발할 때 신경써야할 것이 많아서 휴먼에러를 발생시키기도 합니다.

지금 질문하시는 이유가 커리어패스 때문이시라면, 기본적인 객체지향이론이나, 정보처리기사 필기에 나왔던 내용들을 심화해서 공부해보시고 코드로 구현해보셔도 충분하다고 생각합니다. 제 경험상 결국 거기서부터 시작하기 때문입니다. 정처기가 필요가 없다고 하시는 분들은 정처기에 나와있는대로 개발을 안하시는 분들일거고, 정처기가 괜찮은 경험이었다고 하시는 분들은 정처기에 나와있는 대로 개발을 하셨을 것입니다. 그리고 그 정처기의 이론은 정통 이론과 맞닿아 있습니다.

  1. 프로그램안에 SQL 구문이 있음 → DB서버에 SQL구문을 저장 ID로 호출 (이렇게 하고싶음)

이것도 관리 방식의 차이입니다. DB 서버에 SQL 구문을 저장하신다는 게 3-Tier를 말씀하시는건지, Stored Processor를 말씀하시는 건지 모르겠지만, 방식이라는 것은 나쁜 방식은 없고 상황에 적합한 방식만 존재합니다. 따라서 원하시는 방향으로 하시면서 최대한 본인의 유지보수 시간이 적게 들 수 있는 방식으로 개발하시면 좋을 것 같습니다.

  1. 대용량 DB 관리와 SQL 심화(지금은 JOIN만 주구장창 쓰지 다른건 활용할 일이 없습니다. 데이터가 많은 경우엔 너무 느리더라구요… 너무 느려서 필요하면 프로그램 내부에서 Linq를 사용하기도 합니다.)

DB의 성능에 관해서는 인덱싱과 정규화 2가지를 많이 고민합니다. 그 두 가지 밖에 없기도 합니다. stackoverflow에 보면 몇 억건의 row를 update 쳐야한다는 내용도 있습니다. 그만큼 DB가 가진 힘은 Indexing에 따라 성능이 다르고 Column 갯수에 따라 Table I/O 속도도 달라지기 때문에 정답이 없고 이 두 가지를 고려 해야하는 상황만 존재합니다.

정확한 내용은 모르기에 저도 더이상의 답변은 어렵네요…

  1. 여러 타 기계와의 연동 경험 부족(이건 계속 해보면 되겠지만 당장에 필요한 팩스기/인터넷 전화 같은 기기와 연동하고 싶은데 어렵네요.)

이쪽은 저도 안해봐서 모르겠습니다.

  1. 프로그램 보안 정책(해킹대비)

이것도 생각하시는 수준에 따라 무궁무진하게 할 수 있습니다. 트레이드 오프인 것입니다.

서비스의 품질을 생각하신다면, 이런 것을 고민하지마시고 전문업체에게 돈을 지불하고 보안서비스를 받으시면 됩니다. 당장 되기도 하죠. 문제가 발생했을 때 책임소재가 업체에 있습니다.

나의 커리어패스를 생각하신다면, 보안에 관한 지식을 장기간에 걸쳐서 습득하셔야 합니다. 당장 서비스에 적용하기 어렵고, 초보자인만큼 헛점도 생길 것입니다. 문제가 발생했을 때 책임 소재도 나한테 발생하지요.

이런 문제도 역시 두 가지 중에 어떤 쪽으로 가중치를 선택해야하는 상황만 존재합니다.

전체적으로 커리어 패스에 초점을 맞춘 질문들이었다면, 여러 개발 커뮤니티를 지속적으로 눈팅하는 것, 개발자들의 네트워킹 축제에 나가서 얼굴을 비추고 직접 선배들의 경험을 들을 것 등의 방법이 있을 수 있겠습니다.

소프트웨어의 역사는 길고, 시간이 지남에 따라 레퍼런스는 쌓여만 갑니다.

당연히도 평범한 후발주자는 이 레퍼런스를 모두 완벽히 알수 없습니다. 너무나 많기 때문이죠. 지금도 어디선가 레퍼런스는 쌓이고 있습니다.

여기서 내가 어느정도 알지, 내가 하고싶은 게 뭔지…정보가 이제는 너무나 차고 넘치는 시대에 방향만 선택하는 일만 남았습니다.

변하지 않는 것은, 내 주변에 계속해서 좋은 사람들, 나와 방향이 맞는 사람들, 소통비용이 적게드는 사람들을 커리어와 함께 시간을 누적하면서 계속 쌓아가는 것일 겁니다.

낙심하지 마시고 붙잡고 계시면 언젠가 기회는 올 것이고, 지금 이렇게 글을 올리신 것도 넓게보면 하나의 기회가 아닐까 생각합니다.

7 Likes
3

1번에 대해서만 말씀드리자면 구조설계가 잘되어 있는 타인의 코드를 보는것이 첫번째입니다.
예전에 일했던 한 회사의 경우 초기 멤버들이 전부 c#을 갓 배운 상태에서 개발을 시작했더라구요.
구조는 말할것도 없이 유지보수성, 가독성, 네이밍룰 등등 전부 엉망이었는데 더 큰 문제가 다들 초보이다보니 나쁜코드를 서로 공유하고 재사용하면서 더 나쁜 코드가 생산되는 악순환 구조가 반복되고있었습니다.
그런데 더더 큰 문제가 자기들이 지금 짜는 코드가 문제가 있다는걸 인식을 못하고 있는것이었습니다.
처음 개발한때 잘 짜여진 좋은 코드를 학습했으면 이후에도 선순환 구조가 되었을거같더군요.
좋은 사수나 레거시 자료가 있으면 좋은데 그게 안된다면 오픈소스를 분석하는것도 좋을거같습니다.

3 Likes
4

선배님은 아니지만 저도 작성자 분과 유사한 이유로 마치 제가 잘하고 있는지 항상 불확실함을 가졌었고 현재도 계속해서 개발 경력을 쌓아가고 있습니다. 다만, 과거보다는 훨씬 스스로에 대한 확신을 가질 수 있게 도움을 주었던 개발 그 자체보다는 다른 경험들을 한번 공유 해봅니다.

  • 사수가 없다면 책이나 해외 Ebook으로 극복해보는 것은 어떤가요? 운이 좋아서 좋은 사수를 만나 성장하는 사람도 있겠지만 저는 사수를 찾을 수 없어서 혼자 문서나 책으로 해결해 나갔던 것 같습니다. 확실히 사수가 있으면 지름길이 되겠지만 대부분의 개발자들 개개인이 겪는 문제에 대한 해답을 알려줄 사수는 현실에 없는게 일반적이라고 생각합니다. "결국은 내가 해결해야한다"는 생각을 가지고 나아가야할 것 같아요. 그러면서 성장도 많이 하는 것 같아요. 추가로, 좋은 기회가 있다면 비슷한 연차분들과 토이프로젝트나 밋업을 자주하는 것도 도움이 많이 되는 것 같아요.

  • 다양한 사업군, 도메인을 접할 수 있으면 인사이트가 늘어날 수도 있습니다. 규모에 의한 경험(대기업과 초기 스타트업, 어느정도 자리잡아가는 중소기업)과 B2C, B2B, 연구프로젝트, SI 등등 모두 경험하는건 현실성이 없지만 각 분야에 있는 분들과 자주 커피챗을 해보거나 네트워킹을 하다보면 각각의 개발자들이 중요시하는 것들이 다름을 알 수 있었던 것 같아요. 커뮤니케이션, 도메인 지식, 주도적인 프로젝트 진행, 코드 퀄리티, 개발 속도, 데이터 중심 사고 등등 관점이 기술 그 자체 이상으로 다양했고 겪다보면 자신이 어떤 길을 걸어야할지 판단되고 두려움이 걷어지고 확신을 더 가질 수 있었던 것 같아요.

자신이 이런 고민을 한다는 것 자체만으로 잘하고 있는 것 일 수도 있습니다. :grinning: 좋은 협업을 경험할 수 있는 회사를 찾아보는 것도 좋은 방향일 수 있겠네요!

4 Likes
5

저도 초보지만 제 얘기를 해보자면
제 전 직장이 20년 정도된 정말 작은 회사였고 시니어 개발자도 없었고 저 포함 신입 개발자가 3명이었습니다.
svn을 사용하다 신규 프로젝트에서 git을 사용했고 프로젝트 아키텍처는 항상 View-Controller-Repository였습니다.
그 누구도 이 아키텍처외에 뭐가 있는지 몰랐습니다.
단위 테스트따윈 개나 줘버리고 프로젝트 규모가 커질때마다 항상 처음부터 다시 짜고 싶다는 생각을 했었습니다.
정말 엔터프라이즈급 프로젝트는 어떻게 설계를 할까 궁금했었죠.
결국 성장이 멈춰서 뛰쳐 나왔었네요.

저는 성장이 멈춘 주니어 개발자가 성장을 하는법은 이론적인 부분을 자신의 코드에 어떻게 잘 스며들게 작성해야 되는지 알아가야 한다 생각합니다.

검색을 통해 쉽게 적용할 수 있는 라이브러리나 프레임워크의 API같은것은 생각보다 덜 중요합니다.

“동작만 하는 코드는 누구나 짭니다. 최소한의 인력으로 생산성을 최대화 할 수 있는 코드를 남기세요”
아키텍처는 사실 프로젝트마다 다 다르겠지만
헥사고날 아키텍처, 클린 아키텍처, DDD, CQRS 같은것을 공부해보세요.
혹시 단위 테스트를 안해보셨다면 꼭 공부하세요.
프로젝트 버그에대한 안전망 역할을 하며 (프로젝트)지속성장에 큰 도움이 될것입니다.

ADO.NET 쓰시는건가요?
Legacy 프로젝트 아닌이상 요즘은 거의 EFCore같은 ORM 많이씁니다.

DBA가 되고싶으신가요? 아니면 소프트웨어 개발자가 되고싶은건가요?
열심히 DB 공부했다가 이직할 회사에 DBA가 있다면 어떻게 하실건가요?
시간이 남아돌지 않는다면 둘 중 하나만 택하면 좋을거 같습니다.

너무 많은 것을 알려고 하지 마세요.
시간은 한정적일테고, 어떤 개발자가 되고 싶은지 그것에 focus를 맞춰보세요.

2 Likes