0. 목표

: 일반인의 관점과 개발자 관점 분리

더보기

1단계 (단기 목표): Student to Developer

  • 일반인 관점 → 개발자 관점 전환 → 개발자 업무 이해 → 포트폴리오 준비로 연결

간단한 질문 하나로 확인해 보겠습니다.

 

    Q. "개발자가 되려면 무엇을 해야 하나요?" 

 

이 질문을 받으면 대부분의 학생들은 반사적으로 이렇게 대답합니다.

 

    A. "C, Java, Python.. 문법과 이론 공부부터 해야죠" 

 

이는 매우 자연스러운 답변이지만, 동시에 철저히 '학생'의 관점에서 나온 답변입니다.

과연 현업 개발자들도 똑같이 대답할까요?

 

바로 이 지점이 수많은 개발자 지망생이 잘못된 방향으로 노력하게 만드는 모든 문제의 출발점입니다.

 

따라서 우리는 오늘,

이 착각을 바로잡기 위해 '일반인의 관점'과 '개발자의 관점'을 명확하게 구분하는 것부터 시작할 것입니다.

 

 

목표

    1. 일반인 관점
      • (3) 프로그램이 있을 때
        1. 프로그램을 특별한 기술이나 전문 지식의 결과물로 인식하지 않고,
          일상에서 자연스럽게 사용하는 도구로 명확히 인지합입니다.
        2. 현실에서 이미 매일 사용하는 프로그램들을 예시로 떠올려봅니다.

      • (1) 프로그램이 없을 때
        1. 다음으로, 이 프로그램들이 존재하지 않는 상황을 상상해 봅니다.
          "만약 이 앱이 내일 당장 사라진다면?"

    2. 개발자자 관점
      • (2) 개발자의 업무
        1. 자, 이제 여러분은 이 불편함을 해결해야 하는 사람이 되었습니다.
          프로그램이 없던 세상에서, 그 역할을 대신할 무언가를 만들어야 한다면...
          • 누가 이 불편함을 가장 먼저 느낄까요?
          • 그 불편함을 해결하기 위해 무엇을 고민할까요?
          • 그리고 그것을 어떻게 구체적인 형태로 만들까요?
        2. 이 질문들에 답을 내리는 과정,
          바로 그것이 진짜 개발자의 업무가 시작되는 출발점입니다

 

예시 1. 출석 프로그램

: 생각 정리(Thinking)

더보기
(좌) QR 출입명부, (우)HRD 출석

 

[우리는 지금]

스마트폰 앱을 켜고 QR코드를 화면에 띄운 뒤,

강의실 입구의 리더기에 갖다 대거나 신호 범위에서 버튼을 누르기만 하면 "삐빅" 소리와 함께 1초 만에 출석이 완료됩니다.

 

[만약 출석 프로그램이 없다면?]

수업 시작 전, 수십 명의 수강생이 종이 출석부 앞에 길게 줄을 서서 자신의 이름을 찾아 일일이 서명을 해야 하거나,

책임자가 시간을 쪼개어 한 명씩 이름을 부르고 대답을 기다리며 수기로 체크해야 하는 번거로움이 생깁니다.

└─  출석 프로그램을 만드는 개발자 업무를 하려면 어떻게 해야 할까요?

더보기

먼저, 우리가 방금 머릿속으로 '출석 프로그램'을 만들기 위해 상상했던 단계들을 정리해 봅시다.

 

 

[상상해 본 개발 단계: 기획과 설계]

  1. 데이터 정의 (누구인가?):
    • "우선 우리 반 수강생 명단(이름, 전화번호)이 어딘가에 적혀 있어야겠네."
  2. 입력 방식 (어떻게 확인할까?):
    • "종이에 쓰는 건 귀찮으니까, 핸드폰 QR코드를 카메라로 찍어서 확인하게 하자."
  3. 규칙 설정 (로직):
    • "찍힌 시간이 9시 00분 이전이면 '출석', 9시 10분 이후면 '지각'으로 처리하자."
    • "만약 우리 반 학생이 아니면 '등록되지 않은 사용자입니다'라고 알려주자."
  4. 결과 저장 (출력):
    • "확인된 결과는 종이 대신 엑셀이나 데이터베이스에 자동으로 차곡차곡 쌓이게 하자."

 

[핵심 결론]

 

Q. 이 과정에서 프로그래밍 언어가 사용되었나요?

 

A. "아니요, 단 한 줄도 사용되지 않았습니다."

 

이것이 바로 개발의 본질이지 개발 업무의 시작점입니다.

방금 여러분은 C언어, 파이썬, 자바 같은 어려운 영어를 단 한 글자도 쓰지 않고,

'출석 프로그램'의 핵심 구조를 완벽하게 설계했습니다.

 

여러분이 사용한 도구는 프로그래밍 언어가 아니라,

  • 1. 사람의 언어 (한글)
  • 2. 문제 해결을 위한 논리 (생각)
  • 3. 상식 (업무 이해) 이 세 가지뿐입니다.

소프트웨어 개발은 '영어 타자 치기(Coding)'로 시작하는 것이 아니라,

'생각 정리(Thinking)'로 시작됩니다.

 

코딩은 여러분이 방금 한국어로 정리한 이 생각들을,

그저 컴퓨터가 알아들을 수 있게 '번역'하는 나중의 작업일 뿐입니다.

 

예시 2. 키오스크와 간편결제

: 정리하는 사람

더보기
식당 주문 키오스크 & QR 주문과 결제

 

[우리는 지금]

식당에 들어가서 직원과 말 한마디 섞지 않고도,

커다란 화면(키오스크)에서 메뉴 사진을 보며 옵션을 선택하고 카드를 꽂아 결제까지 마칩니다.

내 주문 번호가 화면에 뜨면 음식을 가져옵니다.

 

[만약 키오스크와 간편결제 프로그램이 없다면?]

점심시간마다 계산대 앞에 긴 줄을 서야 하고, 바쁜 점원에게 복잡한 메뉴 옵션을 목청 높여 설명해야 합니다. 

주문이 제대로 들어갔는지 불안해하며, 언제 내 음식이 나올지 모른 채 하염없이 주방 쪽만 바라보며 기다려야 합니다.

└─  키오스크 프로그램을 만드는 개발자 업무를 하려면 어떻게 해야 할까요?

더보기

먼저, 우리가 방금 머릿속으로 '키오스크 프로그램'을 만들기 위해 상상했던 단계들을 정리해 봅시다.

 

 

[상상해 본 개발 단계: 기획과 설계]

  1. 메뉴 보여주기 (정보 표시):
    • "손님이 오면 화면에 우리 가게 메뉴 사진과 가격표를 쫙 보여주자."
  2. 선택 및 옵션 (입력 및 조건):
    • "손님이 '아메리카노'를 누르면, 그냥 넘어가지 말고 **'따뜻한 거? 차가운 거?'**를 한 번 더 물어보게 하자."
  3. 금액 계산 (연산):
    • "만약 '샷 추가' 버튼을 누르면, 원래 가격에 +500원을 더해서 보여주자."
  4. 주문 전달 (데이터 전송):
    • "결제가 성공하면, 주방에 있는 프린터기로 '아이스 아메리카노 한 잔'이라고 종이를 출력해 주자."
  5. 번호표 발급 (결과 출력):
    • "손님한테는 '대기번호 7번'이 적힌 영수증을 뽑아주자."

Q. 이 과정에서 프로그래밍 언어가 사용되었나요?

 

A. "아니요, 역시 하나도 사용되지 않았습니다."

 

우리는 방금 복잡해 보이는 '무인 주문 시스템'의 핵심 기능을

우리의 상식과 말(언어)로 완벽하게 설계했습니다.

 

개발자란, 키보드를 두드리기 전에

이렇게 머릿속으로 '일의 순서(주문 → 옵션 → 계산 → 전달)'를 정리하는 사람입니다.

 

코딩은 그 생각을 컴퓨터에게 전달하기 위해 나중에 하는 작업일 뿐입니다.

 

예시 3. 모바일 신분증

: 기술적 해결책을 선택하는 사람

더보기
모바일 주민등록증

 

[우리는 지금]

지갑을 집에 두고 나왔더라도 당황하지 않습니다.

스마트폰 잠금을 풀고 앱을 실행하여 본인 인증만 거치면, 화면에 뜨는 디지털 신분증으로 나를 증명할 수 있습니다.

 

[만약 모바일 신분증 프로그램이 없다면?]

외출할 때마다 반드시 두툼한 실물 지갑과 플라스틱 신분증을 챙겼는지 확인해야 합니다. 

깜빡하고 신분증을 두고 온 날에는 관공서 업무나 성인 인증이 필요한 서비스를 전혀 이용할 수 없어 

다시 집으로 돌아가야 하는 낭패를 겪습니다.

└─  모바일 신분증 프로그램을 만드는 개발자 업무를 하려면 어떻게 해야 할까요?

더보기

단순히 기능을 만드는 것을 넘어, 어떤 기술을 선택해야 문제가 해결될지 끊임없이 고민하고 결정해야 합니다.

 

 

[상상해 본 개발 단계: 기획과 설계]

 

  1. 본인 확인 방법 선택 (보안 기술 선정):
    • "아무나 앱을 켜면 안 되는데, 어떤 기술을 쓸까? 비밀번호? 패턴?"
    • 개발자의 선택: "보안성과 편리함을 동시에 잡기 위해 '생체 인식(지문/Face ID)' 기술을 도입하자."
  2. 화면 보여주기 (UI 시각화 전략):
    • "정보를 그냥 텍스트로만 나열해서 보여줄까?"
    • 개발자의 선택: "아니, 사용자가 '진짜 신분증'이라고 느껴야 해. 실제 플라스틱 주민등록증과 똑같은 디자인으로 만들어서 익숙함을 주자."
  3. 가짜 방지 대책 (위변조 방지 기술 구현):
    • "가장 큰 문제는 누군가 화면을 **'캡처(스크린샷)'**해서 악용하는 거야. 이걸 어떻게 막지?"
    • 개발자의 선택: "정지된 사진이 아니라는 걸 증명해야 해. 화면 배경에 **'움직이는 홀로그램 마크'**를 넣거나, '30초마다 모양이 바뀌는 QR코드' 기술을 적용해서 캡처된 사진은 쓸모없게 만들자."

Q. 이 과정에서 프로그래밍 언어가 사용되었나요?

 

A. "아니요, 역시 하나도 사용되지 않았습니다."

 

하지만 우리는 방금 아주 중요한 '엔지니어링(설계)' 과정을 거쳤습니다.

 

개발자란, 단순히 코드를 적는 사람이 아니라,

"캡처를 악용할 위험이 있다"는 문제를 예측하고,

이를 막기 위해 "움직이는 애니메이션 기술을 쓰자"라고 기술적 해결책을 선택하고 결정하는 사람입니다.

 

이 '선택과 결정'이 바로 훌륭한 개발자와 평범한 코더를 나누는 기준이 됩니다.

프로그래밍 문법은 개발자가 선택한 이 해결책(움직이는 마크, 지문 인식 등)을 구현하기 위한 마지막 도구일 뿐입니다.

 

예시 4. 금융 앱

: 조금 더 복잡한 상황을 알아봅시다.

더보기
은행 업무의 편리화

 

[우리는 지금]

새벽 2시든 주말이든 상관없이, 침대에 누워서 스마트폰 앱을 켜고 지문 한 번만 찍으면

통장 잔액을 확인하고 친구에게 돈을 보낼 수 있습니다.

 

[만약 금융 앱 프로그램이 없다면?]

간단한 송금 업무 하나를 처리하기 위해 평일 은행 영업시간(오전 9시~오후 4시)에 맞춰 시간을 내야 합니다. 

은행까지 이동해서 번호표를 뽑고 한참을 기다린 뒤, 종이 전표에 계좌번호와 금액을 적어서 창구 직원에게 건네야 비로소 송금이 완료됩니다.

└─  금융 앱 을 만드는 개발자 업무를 하려면 어떻게 해야 할까요?

더보기

은행 업무 프로그램으로 만들려면 어떤 단계가 필요할지 상상해 봅시다.

 

[상상해 본 개발 단계: 기획과 설계]

 

여기서 '개발자 A(코딩만 아는 사람)'과 '개발자 B(현실 업무를 파악한 사람)'의 차이가 극명하게 갈립니다.

  1. 신원 확인 (금융 실명제법 파악)
    • 개발자 A (코딩 중심):
      • "로그인했으면 그냥 보내주면 되지. 귀찮게 뭘 또 물어봐?"
      • ➡️ 결과: 보이스피싱범이 해킹한 아이디로 돈을 다 빼가도 막을 수 없습니다.
    • 개발자 B (현실 파악 중심):
      • "현실의 은행 창구에서도 신분증 없이는 송금이 안 돼. 앱에서도 '전자 서명(지문/비밀번호)'이나 '점유 인증'을 통해 본인이 확실한지 법적 효력이 있는 인증 단계를 거쳐야 해."
  2. 거래의 안전장치 (트랜잭션의 이해)
    • 개발자 A (코딩 중심):
      • "내 통장에서 돈을 뺐고(A단계), 친구 통장에 넣으려는 순간(B단계)... 어? 갑자기 서버가 꺼졌네?"
      • ➡️ 결과: 내 돈은 사라졌는데 친구는 돈을 못 받은 상태로 기록이 남아버립니다. (최악의 금융 사고)
    • 개발자 B (현실 파악 중심):
      • "은행 업무의 핵심은 '모 아니면 도(All or Nothing)'야. 친구 통장에 입금 확인 도장이 찍힐 때까지, 내 통장에서 뺀 돈은 '대기 상태'로 둬야 해. 만약 중간에 에러가 나면? 모든 과정을 없던 일로 되돌리는(Rollback) 기능을 무조건 설계해야 해."

 

Q. 이 과정에서 가장 중요한 능력은 무엇인가요?


A. "코딩 실력이 아니라, '은행이 어떻게 돌아가는지 (현실의 업무 규칙, Domain Knowledge)'를 아는 것입니다."


아무리 파이썬과 자바 문법을 완벽하게 외우고 있어도,

'도메인 지식(은행 업무 규칙)'이 없으면 그 개발자는 시한폭탄을 만드는 것과 같습니다.

개발자란, 키보드 앞에 앉기 전에,
현실의 업무(비즈니스)가 어떤 규칙으로 돌아가는지 배우고(Learn),
그 규칙에서 발생할 수 있는 문제점(사고)을 예측하며,
그것을 예방하는 안전한 구조를 설계하는 사람입니다.

우리가 '문법'보다 '현실 파악'을 먼저 해야 하는 이유가 바로 여기에 있습니다.

현실을 모르면 코드는 아무런 쓸모가 없기 때문입니다.

 

예시 5. 문서 프로그램

: 문서 프로그램이 없다면?

더보기

워드, 한글, 엑셀, 파워포인트, 메모장 등등

 

[우리는 지금]

컴퓨터 화면에 글자를 입력하고, 틀리면 백스페이스 키로 지우고 다시 씁니다. 작성한 내용은 파일로 저장해 이메일로 즉시 전송하거나 프린터로 깨끗하게 출력합니다. 복잡한 계산도 수식 한 번이면 자동으로 해결됩니다.

 

[만약 문서 프로그램이 없다면?]

모든 보고서와 과제를 손으로 직접 써야 합니다. 

글씨를 틀리면 수정테이프를 덕지덕지 바르거나 종이를 찢고 처음부터 다시 써야 합니다. 

수많은 데이터를 정리할 때는 계산기를 옆에 두고 밤새 두드리며 수기로 표를 채워야 하는 고된 노동을 해야 합니다.

 

요약 및 결론 

더보기

[관점의 전환이 곧 취업 전략이다]

 

여러분이 '사용자'에서 '개발자'로 시각을 바꾸는 순간, 준비해야 할 포트폴리오의 방향성도 완전히 달라집니다.

 

 

[이것을 포트폴리오에 어떻게 담을까?]

 

기업은 '문법을 외운 학생'이 아니라 '문제를 해결하는 개발자'를 원합니다.

따라서 여러분의 포트폴리오는 다음과 같이 바뀌어야 합니다.

 

❌ 탈락하는 포트폴리오 (학생 관점)

 

  • 저는 C언어와 자바 문법을 배웠습니다. 열심히 코드를 짰습니다.
    (→ 소스코드 첨부 끝)
  • 문제점: 결과물(코드)만 있고, 왜 그렇게 짰는지에 대한 생각(과정)이 없음.

 

 

⭕ 합격하는 포트폴리오 (개발자 관점)

 

  • 저는 [현실의 문제]를 발견했습니다.
  • 이를 해결하기 위해 [이런 논리]로 설계를 먼저 했고,
  • 안전한 거래를 위해 [금융 규칙]을 적용하여
  • 최종적으로 코드로 구현했습니다."

 

 

 

[준비 가이드] 

  • 개발자를 목표로 한다면
    개발자의 업무 방식과 업무 흐름이 그대로 포트폴리오에 담겨야 할 내용입니다\

  • 문법 암기부터 시작하는 것이 아니라,
    앞으로 프로젝트를 할 때, 코드만 보여주지 말고 다음 3가지를 반드시 문서로 남기세요.
    1. 기획서: 어떤 불편함을 해결하려고 했는가? (일상의 불편함을 관찰하고)
    2. 분석: 해결 과정을 말과 글로 정리하며
    3. 설계: 어떤 순서로 동작하는지 그림으로 그렸는가?
    4. 기술 선정 이유: 왜 이 기술을 썼는가? (기술적 선택의 근거)

"코드는 거들 뿐, 여러분의 '생각하는 과정'을 보여주는 것이 취업의 지름길입니다."

  1.  

 

Next. 1.2 개발자의 업무

: 이제 개발자의 관점으로 생각해봅시다.

 

티스토리툴바