아이패스, 이거 진짜 실무에서 쓸 만한 건가요

결이 다르긴 함ㅋㅋ 자동완성이 '다음 토큰' 찍어주는 거면 아이패스는 '작업 단위'로 굴러가는 느낌임

블로그가 다 비슷한 이유가 있음. 실제로 그 정도임ㅋㅋ

출처 있음?

오 이건 몰랐네

팀에 도입해봤는데 코드리뷰 시간이 확 줄진 않았고 리뷰어가 지적할 거리가 좀 달라졌어요. 스타일 지적은 사라지고 대신 '이 로직 왜 이렇게 짰냐'는 질문이 늘었음. 총량은 비슷하거나 오히려 늘었을지도. 학습곡선도 은근 있고요.

그거 옛날 얘기 아님? 요즘 버전은 컨텍스트 관리 방식이 달라져서 그런 실패 케이스 많이 줄었던데

한 가지 팁 드리면, 잘하는 작업이랑 못하는 작업을 빨리 구분하는 게 중요합니다. 보일러플레이트, 테스트 fixture, 로그 파싱 스크립트, 낯선 라이브러리 API 예제 뽑기 — 이런 건 진짜 잘함. 반대로 동시성 제어나 트랜잭션 경계 잡는 설계, 사내 도메인 규칙이 얽힌 로직은 물어볼수록 그럴듯한 헛소리가 나와요. 저는 전자만 쓰고 후자는 손으로 합니다. 그 선을 긋는 데 걸린 시간이 두어 달이었네요.

실무에서 확실히 줄어든 건 세 가지였어요. 첫째, 낯선 레거시 코드 처음 열었을 때 구조 파악하는 시간. 예전엔 파일 서른 개 열어놓고 콜스택 따라가면서 반나절 날렸는데, 이제 진입점 물어보고 흐름 요약 받은 다음에 검증만 하면 됨. 둘째, 테스트 코드 뼈대. 케이스 나열은 제가 하고 코드는 걔가 뽑는 식. 셋째, 사소한 리팩터링 — 변수명 정리나 중복 제거 같은 건 진짜 몇 분 단위로 줄었습니다. 다만 요약을 믿고 그대로 머지했다가 한 번 크게 데인 적 있어서, 지금은 '설명은 참고, 코드는 내가 읽는다' 원칙으로 씁니다.

글쎄요, 저는 두 달 쓰고 접었습니다. 컨텍스트가 길어지면 앞에서 정한 컨벤션을 조용히 까먹고, 그럴듯한데 존재하지 않는 메서드를 만들어서 컴파일 에러로 잡아주는 게 아니라 오히려 제가 그거 맞는 줄 알고 한참 헤맸어요. '줄여줬다'는 얘기만 많은데, 되돌리는 시간까지 계산한 사람이 몇 명이나 될까요. 구체적으로 어떤 작업에서 몇 시간 줄었는지 수치로 말해주는 분 있으면 듣고 싶네요.