연초에 봤던 프론트엔드 면접 후기 2곳

회사 1 후기

어떤 분위기였나

• 실무형 질문 많음
• 운영 경험 중요하게 봄
• 병원 환경 특수성 질문 존재

면접 질문순서

1분자기소개

현재 팀 개발인원

• 팀장1 팀원4

회사에서 사용중인 언어, 라이브러리, 환경 등

• Swift, Kotlin, React-Native, Java, Spring Boot, JSP, FreeMarker, JavaScript, TypeScript, jQuery, React, Next, Nest, Express, Linux, Windows, Mac

온프레미스환경에서 운영장애생길 때 대처방법

• VPN, VDI, 리모트뷰, 쉘, 직접 방문 등 병원마다 접속 방식이 전부 달라서 상황마다 다르게 대응한다.
• 대부분은 브라우저 로그나 서버 로그를 먼저 확인한다.

하고있는 서비스

• 알림톡
• 병원앱
• 관리자 페이지
• 건강검진
• 제약 사전심사
• 등등

로그인 구성방법

• 서비스 성격에 따라 다르게 구성했다.
  - 알림톡은 단순 정보 확인 형태
  - 관리자 페이지는 JWT 기반 인증

레거시였던 자바&제이쿼리 고도화 작업을 어떤순서로 진행했는지

• 가장 먼저 기존 서비스가 정상 동작하는 것을 1차 목표로 잡았다.
• 이후 소스를 분석 & 병원 측과 기능 확인을 병행하면서 작업했다.
• 화면은 웹뷰 기반이었지만 최대한 네이티브 앱 같은 느낌이 나도록 신경 썼다.

고도화작업 인원분배는 어떻게 했는지

• 백1 프론트1 디자인1 기획자없음

고도화 진행중 레거시와 고도화가 혼재되어있을때 충돌은 어떻게 해결했는지

• 기존 JAR 기반 서비스는 기존 URL을 유지하고, 고도화 버전은 병원에서 발급받은 임시 URL로 병행 운영했다.
• 안정화 이후 기존 URL을 React 기반 서비스로 전환했다.

카카오 브라우저에서 디바이스간 이슈사항

• 디바이스 환경별 스타일 차이 정도는 있었지만 치명적인 문제는 거의 없었다고 답변하고 다만 외부 브라우저로 열렸을 때 스토리지 값이 유지되지 않아 흰 화면이 뜨는 경우는 가끔 있었다고 했다.

중간에서 커뮤니케이션한다는게 병원과 협의한다는 건지

• 단순 기술 작업만 한 게 아니라 일정 조율이나 부서 간 협의도 많이 했다고 설명. 팀원들이 힘들어할 때 중간에서 조율하기도 했고, 병원 측이나 타 부서와의 소통도 담당했다.

비전공자로서 개발할때 허들은 없었는지

• 본인 입사 후 2주뒤에 입사한 분이 어릴때부터 개발을 하신분이라 전팀장님한테 비교를 많이받았다. 그래서 퇴근하고서도 개인 공부에 엄청 시간투자를 많이했다.

신규개발시 공통 환경이라던지 기본구조 작업을 했다고 했는데 자세히 설명좀

• 전팀장이 근근이한테 온보딩하면서 업무준게있는데 갑자기 전팀장이 그만두게됐다.
• 이후 근근이가 한 개발을 운영으로 인계하는 과정에서 운영하는 분이 운영 못하겠다 해서 확인해보니까 근근이가 개발한 코드 네이밍과 구조가 팀 내부에서 사용하던 방식과 다르게되어있었다.
• 당시에는 명확한 코딩 가이드나 네이밍 컨벤션이 문서화되어 있지 않았기 때문에 발생한 문제라고 생각했다.
• 우선 운영에 직접적인 영향을 주지 않는 선에서 긴급 수정이 필요한 부분만 정리했고, 이후 팀원들과 협의하여 코딩 컨벤션을 정리하고, 컴포넌트 단위 명확화를 위해 스토리북을 도입했다.
• 이후 입사자는 코드 적응 속도가 확실히 빨라졌다.

스토리북 만드는 리소스도 꽤 들었을텐데

• 잠깐 프로젝트가 딜레이 된 시점이 마침 생겨서 그때 호다닥 작업했다.

멀티레포지토리인지 모노레포인지

• 멀티 레포지토리라고 답변했다. 병원마다 서버 환경이나 요구사항, 버전이 전부 달라서 모노레포로 운영하기는 어렵다고 설명했다.

스토리북 이나 컨벤션이 효과가 있었나

• 신규 입사자분들이 회사 코드 적응하는 데 확실히 도움이 됐다고 답변했다.

SI같은 느낌인가

• SI 성격은 있지만 유지보수도 대부분 직접 한다고 설명했다. 몇몇 외주를 제외하면 운영도 계속 담당한다고 답변했다.

리액트를 고도화 해본적이 있나

• 기존 자바 기반 네이티브 앱 구조를 점진적으로 개선하면서, 네이티브 영역은 최소화하고 UI 영역은 React 기반 웹뷰로 전환하는 작업을 주로 하고 있다. React 자체를 고도화한 경험은 없다.

느낀 점

• 운영 경험을 꽤 중요하게 보는 느낌
• 단순 React보다 “실제 운영 가능 여부”를 많이 물어봄

---

회사 2 후기

어떤 분위기였나

• 기술 질문 깊이가 더 깊었음
• CS + 운영 + 협업 같이 물어봄
• AI 활용 여부도 질문함

기억나는 질문들

1분 자기소개

지금 회사 이직사유

• 크게 두 가지 이유가 있다. 하나는 회사의 경영 방향이 제가 중요하게 생각하는 개발 가치와 점점 멀어졌다는 점이고, 다른 하나는 팀 운영 구조 변화로 인해 개발에 집중하기 어려운 환경이 되었다는 점이다.

좀더 자세하게 설명해줄 수 있나. 회사 관련

• 매출이 입사후로 계속 줄어들다보니 경영에서 단기적인 영업 성과를 더 중요하게 보기 시작했고, 기능 자체보다는 보여지는 부분 위주로 영업을 하려한다... 가장 큰 포인트는 '있는 기능이 아닌데 있는것처럼 포장'을 해서 디자인만 예쁘게하려는 기획을 하고있어서 빤스런 하려한다.

회사가 당장 그렇게 하라하면 어떡할거냐

• 그래서 지금 나가려고 알아보는거다. 만드는 입장으로서 중요하게 생각하는게 성취감과 정직함이라고 생각한다.

우리회사 서비스 써봤냐

• 홈페이지 사업 소개와 유튜브 영상은 확인했지만 실제 서비스 사용까지는 못했다.

지금 회사에서 하는 서비스가 자사서비스인가 아니면 모듈만 만들어서 거기에 설치하는 에이전시같은 사업인가

• 알림톡은 SI 성격이 강하고, 키오스크는 솔루션 느낌이다.
• 키오스크는 내부망에서만 동작하기 때문에 방문해서 직접 설치 진행한다.
• 모바일 서비스는 병원 서버에 배포하는데 방문/비방문 나뉘어져있고 SI 성격이지만 유지보수까지 담당한다고 답변했다.

본인이 진행한 프로젝트중 가장 잘했다 싶은 프로젝트

• 회사 1에서도 이야기했던 병원 고도화 프로젝트를 이야기. 기존 서비스에서 작동하던 기능들을 최대한 똑같이 유지하는 것을 우선 목표로 잡았고, 병원 측과 기능 확인을 병행하면서 작업했다. (이전 문서가 없어서 병원도 정확히 어떤기능인지 모름)
• 웹뷰 기반이지만 최대한 네이티브 앱 느낌이 나도록 신경 썼다고 답변했다.

리덕스 툴킷, 리액트쿼리같은거 여러가지 썼는데 어떻게 선택하고 쓰게된건지

• 입사 당시에는 Redux를 사용 중이었는데 보일러플레이트가 너무 많다고 느껴 RTK 도입을 제안했다고 설명했다. 팀장님이 새로운 기술 제안에 열려 있는 편이어서 비교적 자연스럽게 도입할 수 있었다.
• 이후 신규 인력이 React Query에 익숙했고, 프로젝트 특성상 서버 상태 관리에 더 적합하다고 판단해 팀장과 협의 후 React Query를 도입했다.
• 팀원, 프로젝트 성격에 따라 선택했다.

근데 전역을 사용할 일이 많이 없나요

• 알림톡처럼 단일 페이지 중심 서비스는 전역 상태가 거의 필요 없었다.
• 반면 제약 사전심사 프로젝트처럼 탭이 많고 폼 상태가 복잡한 경우에는 전역 관리가 필요했다.
• 프로젝트 복잡도에 따라 다르게 판단했다.

깃플로우는 어케하게됨

• 전에 다 나가버린사람들이 깃관리를 안하고있었고 남아있던 전팀장님이 새로 팀빌딩 하면서 깃플로우 하자해서 같이 이야기하다가 깃플로우로 하게됐다.

차트는 뭐뭐 썼는지

• 입사 초반에는 npm trends를 봤을 때 chart.js가 가장 많이 쓰이는것같아서 그걸 썼었다. 대부분 곡선이나 막대 간단한 차트만 보여주는거라 어려운차트가 필요없어서 그걸쓰다가 사전심사때는 차트가 조금 스크롤도필요하고 커스텀이 필요해져서 찾아보니 rechart.js가 커스텀이 좋다해서 그걸 쓰게됐다.
• 근데 사실 전팀장님 개발 철칙이 만들수있으면 굳이 라이브러리 쓰지마라고해서 범위 달력이나 몇 몇 차트는 직접 만들었다.

다국어 처리도 한것같은데 그건 어떻게 처리했는지

• 의존성을 최소화하기 위해 직접 구현되어있다.
• 브라우저의 userAgent (navigator.language인데 userAgent라고 잘못말함 샤갈ㅠ 디바이스랑 언어체크 붙여서 같이해서 순간 헷갈림) 값을 기반으로 언어를 분기하고, 병원에서 제공한 다국어 엑셀 데이터를 JSON으로 변환해 관리했다.

그러면 다국어를 번역하는 사람한테 엑셀같은거로 받나

• 그렇다. 모병원같은경우는 7개국어까지하는데 그경우 병원에서 ‘안녕하세요’에 맞는 부분의 각 언어별로 문서를 제공해준다

quill.js는 어디까지, 어쩌다 사용하게된건지

• 에디터 비교하면서 quill.js까지 선택하게된 히스토리(Toast UI, Wysiwyg...) 설명했다.
• 많이쓰지는 않고 에디터에 사진첨부, 글씨체, 굵기, 정렬, 색상 이정도까지만 옵션에 넣었다.

pg 구축은 어떤식으로 하는지, api로 하는지 모듈로 하는지

• pg 업체마다 다른데 어디는 자바 jsp밖에 없다하면 jsp를 저희는 프리마커를 쓰고있기때문에 프리마커템플릿엔진에 맞춰서 바꿔서 작업하고, 만약 js가 있다하면 js api쓸수있으면 거기다가 api 주고받는걸로 하는데 어디는 jsoup으로 해야한대서 그걸 사용하기도 하고 pg사마다 다 각각 다르다.

백엔드랑 api형식의 문서를 프론트에서 작성해보신건가요? 아니면 보통 그렇게 하시나요?

• 백엔드가 문서쓰는걸 안좋아해서 디자인보고 병원에서주는 프로시저|뷰 문서보고 명세서 작성해서 먼저 던져주는게 잦았다.

그럼 그대로 해주나요?

• 그럴때도 있고 추가하고싶은게있으면 추가하기도하고 일단 초안문서를 프론트에서 만들면 그때부터 백엔드랑 협의했다.

KIMS 시스템에서 응답받은 HTML 데이터를 파싱하여 화면에 동적으로 데이터 추가 <- 이걸 좀더 자세히 설명해달라

• KIMS 의약 정보 페이지에서 HTML 데이터를 받아온 뒤, 특정 div/class 기준으로 필요한 데이터를 추출해 화면 구조에 맞게 재가공했다고 설명했다.
• 기존 HTML 구조를 그대로 쓰기보다는 필요한 데이터만 다시 조립해서 사용했다고 답변했다.

lighthouse를 사용해서 성능 개선한게있다는데 자세히 설명해달라

• 처음에는 프론트 문제라고 생각했지만 실제로는 병원 네트워크 환경 영향이 컸다고 설명했다.
• 다만 분석 과정에서 MUI 번들 크기가 상당히 큰 것을 확인했고, 이후 프로젝트에서는 MUI를 사용하지않고 프로젝트를 템플릿화 + 기본 html태그를 사용한 스토리북 제작 하여 불필요한 사용을 줄이고 있다고 답변했다.

리액트-윈도우는 왜썼는지

• 초기에는 데이터 양을 예측하지 못해 단순 렌더링으로 구현했는데, 실제 운영 환경에서 데이터가 많아지면서 렉이 발생했다.
• 이후 화면에 필요한 요소만 렌더링하도록 react-window를 도입했다.

스토리북 도입을 주도했냐, 왜했냐

• ㄹㄹ이가 맘대로해놔서 1번회사 때 말한대로

그럼 그 작업하는분은 진짜로 컨벤션을 몰라서 그런거냐 본인의 확고한 뭔가가 있어서 그랬던거냐

• 개인 스타일이 강한 부분도 있었던 것 같다고 답변했다.
• 다만 당시에는 명확한 규칙 자체가 부족했던 것도 사실이라 이후 팀원들과 협의해 컨벤션을 정리했다고 설명했다.

컨벤션 생긴 이후로는 잘 따르냐

• 그도 노력중이다. 그리고 중간중간 팀원들이 이제 그의 커밋을 확인했다.

컨벤션 사실 모르면 물어보면서 해야하는거 아니냐

• 웃음

병원의 로그인서비스 어떻게 구축하는지

• 아까 회사1에서 말한대로

액세스토큰이랑 리프레시토큰 어떻게저장하는지

• 액세스 토큰은 Header 리프레시 토큰은 Cookie

리액트에서 키가 중요하다고 하는데 왜 그게 중요하냐, 키를 잘못쓰면 무슨문제가 생기냐

• 배열 렌더링 시 index를 key로 사용할 경우 순서 변경 시 문제가 생길 수 있다는 것은 알고 있어서 항상 고유한 값을 사용하려고 했다.
• 항상 데이터중에 프라이머리한걸로 쓰려고했다. 안된다고 들어서 한번도 쓴적이없다. 그 이유는 잘모르겠다 죄송하다.

React는 리스트를 렌더링할 때 `key` 값을 기준으로 어떤 요소가 변경됐는지 비교한다.

만약 index를 key로 사용하면:

- 리스트 순서가 변경되거나
- 중간 요소가 추가/삭제될 때

React가 기존 요소를 잘못 재사용할 수 있다.

그 결과:

- input 값이 꼬이거나
- 잘못된 컴포넌트가 유지되거나
- 불필요한 리렌더링이 발생할 수 있다.

그래서 가능하면 DB id 같은 고유한 값을 key로 사용하는 것이 좋다.

병원에서 운영할때 cors문제생기냐

• 대부분 병원 환경은 운영 서버에 바로 배포하는 구조였고, 프론트와 백엔드 도메인이 같은 경우가 많아서 CORS 문제가 거의 없었다고 설명했다.
• 포트 차이로 문제가 생기는 경우에는 nginx 프록시 설정으로 해결했다고 답변했다.

개발서버없으면 프론트하고 백엔드하고 어떻게 테스트하냐

• 기본적으로는 로컬 환경에서 각각 실행해 테스트했다.

한 노트북에서 두개 프로젝트 띄운다는거냐

• 그런 경우도 있었고, 상황에 따라 노트북을 따로 사용하기도 했다고 설명했다.
• 필요한 경우에는 백엔드에서 프론트 개발용 IP와 포트를 허용하는 방식으로 테스트했다고 답변했다.

개발서버가 없을수가 있냐

• 개인적으로는 개발 서버가 꼭 필요하다고 생각했다.
• 실제로 개발 서버와 병원 DB 환경을 따로 구성해 테스트하고 싶어 생산부 요청도 했지만 현실적으로 지원이 어려웠다.

그래서 테스트는 어떻게

• 테스트 환경이 부족했기 때문에 입사 이후에는 Postman이나 MSW 같은 도구 세팅을 더 철저하게 하려고 했다.
• 병원 운영 환경은 테스트 데이터조차 없는 경우가 있어서 더욱 중요하다고 느꼈다.

설치는 직접가서 빌드하냐

• 직접 병원에 방문해 작업하는 경우도 있었다.
• 주로 리눅스 환경의 서버가 많았다.
• 설치는 실물서버를 받아서 OS설치 - 서버 랙 작업부터 진행하는 경우도 있었고, 가상 서버 환경을 제공받아 Windows Server에 배포한 경험도 있다고 설명했다.

디바운스나 쓰로틀링에 대해서 어떻게 아냐 써봤냐

• 병원에서 번호표 발급이라는게 있는데 그거를 버튼을 막 엄청 눌러서 티켓팅 한다는걸 알게됐다.
• 그래서 그 이후론 버튼에 디바운스나 쓰로틀링 넣고있다

리플로우랑 리페인트 차이에 대해서 설명좀

• 설명 못함

# Reflow(Layout)

!요소의 크기나 위치가 변경되면서 브라우저가 전체 레이아웃을 다시 계산하는 과정이다.!

예시:
- width/height 변경
- margin 변경
- font-size 변경
- DOM 추가/삭제

=> 비용이 크다.

---

# Repaint

!레이아웃 변화 없이 색상이나 스타일만 다시 그리는 과정이다.!

예시:
- background-color 변경
- color 변경
- visibility 변경

=> Reflow보다 상대적으로 비용이 적다.

---

# Reflow가 발생하면 보통 Repaint도 같이 발생한다.
그래서 애니메이션 작업 시에는:

- width/height 대신
- transform, opacity 같은 속성을 사용하는 것이 성능상 유리하다.

병원 관리자 페이지면 엄청 복잡할텐데

• EMR 수준은 아니어서 생각보다 복잡한 시스템은 아니었다.
• 대부분 조회 형태 작업이 많았고, 그중에서는 제약 사전심사 프로젝트가 가장 복잡했다.

사전심사때는 폼관리어케했냐

• 기능 단위로 컴포넌트를 분리했다고 설명했다.
• 예를 들면:
  • 약국/환자 정보 입력
  • 상병 코드
  • 의약품명 등

으로 나눠 관리했다.

• 개인적으로 props drilling이 깊어지기 시작하면 전역 상태로 관리하는 편이라, 당시에는 상태 관리를 조금 더 철저하게 가져가려고 했다고 설명했다.

https://naver.com입력했을때 화면에 뿌려지기까지과정

• 브라우저에서 URL 입력 → DNS 조회 → IP 확인 → 해당 서버 요청 → HTML/CSS/JS 응답 → 필요한 경우 추가 API 요청 → 브라우저 렌더링

http 3.0 에 대해서 설명좀

• 블록체인 관련해서 이야기 있었떤정도로만 알고있고 자세히모름

HTTP/3?
HTTP/3는 기존 HTTP/1.1, HTTP/2처럼 웹에서 클라이언트와 서버가 데이터를 주고받기 위한
HTTP 프로토콜의 최신 주요 버전.

가장 큰 차이는 기존 HTTP/1.1과 HTTP/2가 TCP 기반으로 동작했던 것과 달리,
HTTP/3는 UDP 기반의 QUIC 프로토콜 위에서 동작한다는 점.

  
---구조 비교
기존:
HTTP -> TCP -> IP

HTTP/3:
HTTP/3 -> QUIC(UDP 기반) -> IP
---

사용이유?
이전 버전에서 HOL Blocking(Head Of Line Blocking):
  TCP 기반 통신에서 하나의 패킷이 손실되면 뒤 요청들도 같이 대기하는 문제
가 발생했었다. 

QUIC은 스트림 단위로 데이터를 처리해 하나의 요청이 늦어져도 다른 요청까지 전부 막히는 현상을 줄여준다.
그래서 연결 속도가 더 빠르고 모바일 네트워크 환경에 강하고 지연 시간이 줄어드는 장점이 있다.

따라서 QUIC(HTTP/3에서 사용하는 통신 프로토콜)을 사용하면 연결 설정 시간이 줄어들고, 
여러 요청을 동시에 처리할 때 하나의 요청 지연이 다른 요청까지 막는 문제를 줄일 수 있음.

추가특징
- UDP 기반
- TLS 암호화 기본 내장
- 연결 재수립 속도가 빠름
- HTTP/3 핵심 기술

 

배포할때 백엔드랑 프론트 같이 배포해야할때 어케함

• 쉘 두개 켜고 백엔드가 대부분 가벼워서 더 빨리되니까 프론트 스크립트 하고 백엔드 스크립트 해서 배포했는데 아직까지 문제없었다.

그런거 말고 무중단해야하면

• PM2. 빌드한후에 pm2 restart(reload라 말해야하는데;) 로 했다

궁금해서 찾아본 다른 대안

- Nginx Reverse Proxy + Blue-Green 배포
새 버전을 다른 포트나 다른 서버에 먼저 띄운 뒤, Nginx upstream을 새 버전으로 바꾸는 방식

예시)
- 기존 버전: 3000번 포트
- 새 버전: 3001번 포트
- 새 버전 헬스체크
- Nginx가 바라보는 포트를 3001로 변경
- 문제 생기면 다시 3000으로 롤백

- Docker 기반 배포 -> 아마 이 방식을 원하셨던것 같음
Docker 이미지를 새로 빌드하고 새 컨테이너를 띄운 뒤, 정상 확인 후 기존 컨테이너를 내리는 방식.
규모가 커지면 Docker Compose, Kubernetes, Blue-Green, Rolling Update 같은 방식으로 확장.

장애났을때 프론트는 사실 할수있는게 없을텐데 장애조치를 위해서 할 수 있는 최선 뭐가있냐

• 마침 백엔드분이 지금 휴가중이라서 이번에 배포 시 오류나서 수정해야 하는 백엔드코드들을 확인해서 수정했다.

아 풀스택이구나. 질문의도를 바꾼다. 백엔드 장애 대비해서 뭔가 프론트에서 처리하고 있냐

• 사람이 만드는 시스템이다 보니 프론트와 백엔드 모두 실수할 수 있다고 생각해서
  • 값이 없는 경우
  • 응답 키가 달라진 경우
  • API 응답이 비정상인 경우 등

을 고려해 에러 처리를 최대한 추가하려고 했다.

• 사용자에게 단순 빨간 에러 화면을 보여주기보다는, 안내 페이지나 예외 처리 화면으로 유도하려고 노력했다.

첫번째 회사를 오래다녔는데 이제 두번째 회사를 선택하면서 어떤스타일이고 어떤회사를 가야겠다 라는게 있는지

• 개인적으로는 기획자가 있는 회사에 가보고 싶다. 이전 회사에서는 기획 역할까지 개발팀이 함께 하는 경우가 많았기 때문에, 역할이 조금 더 명확하게 분리된 환경도 경험해보고 싶다.
• 추가로 AI 관련 학과에 진학 예정이라(방통대) 회사 안에서 자연스럽게 AI 관련 업무나 흐름을 접할 수 있는 환경에도 관심이 있다.

우리스타트업이라 돈없을수도 있고 당장 돈이없는상황은 아니지만 스타트업이라는게 어떻게될지모르는데

• 지금 우리회사도 어떻게 될지 모른다

AI머신러닝 하는 분들이 있긴한데 그 업무를 직접적으로 하는건 아니고 그분의 모델들을 호출하는거라 실망하시는거아니냐

• 그 제가 직접 그 코드를 보거나 한다는게 아닌건 알고 있다. 다만 같은 회사니까 어느정도만 주고받는걸 볼 수 있을거라는 생각만 한다. 나는 웹 직무라는거 알고있다.

기술적 갈등이나 의사갈등이 있을때 협의하려고 했지만 안되는 경우도있다. 그럴땐 어떻게하냐

• 개인적으로는 감정이 드러나는 순간 협의가 어려워진다고 생각한다. 그래서 상대방이 감정적으로 나오더라도 최대한 감정을 드러내지 않으려고 하고, 기술 자료나 근거를 중심으로 이야기하려고 한다.
• 정말 끝까지 해결되지 않는 경우에는 일단 방향을 맞춰 진행하고, 이후 결과를 통해 다시 논의하는 편이다.

근데 만약 상대방이 잘못생각한게아니고 본인이 잘못생각한거였어서 문제안생기면

• 그럼 아 그게맞구나 앞으로 그렇게 하면되는구나 생각하고 만다.

팀장님 언급이 좀 잇었는데 본인이 생각하는 팀의 리더는 어떤사람이어야 한다고 생각하냐

• 모든 의견을 다 수용할 필요는 없지만, 방향을 정리해주고 왜 그 방향이 맞는지 설명해줄 수 있는 사람이 좋은 리더라고 생각한다.

업무가 힘들다는 기준이 사람마다 다른데

• 일 없을때 힘들다

AI툴 어떻게 사용중이냐

- 회사에서는 지피티 사줘서 지피티쓰고 gemini cli같이쓰고있따
- 집에서는 커서쓰고있다

바이브코딩하냐

• (생각 개많았음 바이브코딩하면 안좋게볼까봐 ㅠ) 집에서는 커서 단위별로 해달라고하면 공식문서보다 잘알려줘서 커서로 학습대신하는데 회사에서는 커서 위험하다 생각해서 안씀
  • >> 지금은 바이브코딩없이 못사는 나

왜

• 잠깐 지나면 막 쌓이는게 그 중간에 혹시나 확인 못하고 넘어가게될까봐

우린 바이브코딩좋아함 우리 ai개많이씀 클로드 비싸서 안쓸꺼면 코덱스라도 꼭 써보셈

- 녜

느낀 점

• “왜 그렇게 선택했는지”를 엄청 중요하게 봄
• 모르는 건 솔직하게 말하는 게 낫다고 느낌

 

 

 

 

 

 

 

 

 

다음엔 과제했던거 후기 남겨야딩