안녕하세요! 그로스로그 입니다!😊 🌱
지금 당장 빠른 길과, 시간이 걸려도 남는 길. 셋 다 후자를 골랐고 그 이유를 적었습니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
6회차는 교육 이야기 두 편과 배포 이야기 한 편입니다. 앞의 둘은 나란히 읽으면 특히 재미있어요.
01
🎖️ 대한민국 초기 장교 교육과 개발자 교육에 대한 단상
박석희 님
장교 양성 교육의 역사를 통해 개발자 교육을 생각해본 글입니다. 황포군관학교, 프로이센 참모집단, 소련 붉은 군대, 그리고 대한민국 육사 8기와 11기를 지나갑니다.
관통하는 질문이 하나예요. "교육이 먼저냐, 역할이 먼저냐."
그리고 이 질문을 지금으로 가져옵니다. 부트캠프냐 컴퓨터과학과냐, AI에 기대어 바로 뛰어들 것이냐 기초부터 쌓을 것이냐. 글쓴이 본인의 선택과 그 이유로 끝납니다.
성장일지에서 보기 드문 종류의 글입니다. 코드가 한 줄도 없어요. 그런데 개발자 교육에 대한 글로 읽힙니다.
조금 더 들어가 보면
먼저 왜 군대 이야기로 시작하는지를 스스로 해명합니다.
부트캠프가 원래 군사 용어라는 지적이 정확합니다. 그리고 'All-hands on deck', 'War room' 같은 표현들도 그렇죠. 우리가 이미 군사 은유 안에서 개발 이야기를 하고 있다는 겁니다.
군과 교육과 개발이라는 세 영역을 모두 겪어본 시선이 이 조합을 만듭니다. 셋이 만나는 자리에 이 글이 있어요.
⏳ 6개월과 4년 — 역사가 보여준 두 경로
본론은 역사적 사례 비교입니다.
황포군관학교 이야기가 첫 사례예요.
18개월이 필요하다는데 6개월로 잘랐습니다. 급했으니까요. 그런데 결과가 흥미롭습니다.
6개월짜리 교육이 통했다는 겁니다. 글쓴이가 놀라움을 그대로 적어요. "고작 6개월의 교육으로 장교가 된 이들이 이러한 역사적 과업을 해냈다는 것이 놀랍다."
그다음 독일과 소련을 대조합니다. 이 부분이 글의 축이에요.
독일 — 나폴레옹에게 패한 뒤 장교 교육에 절치부심했습니다. 그 결과가 임무형 지휘예요. 상급자의 의도를 이해하고 현장에서 알아서 판단하는 방식입니다. 그리고 이 대목이 인상적이에요.
무기가 아니라 사람 집단이 경계 대상이었다는 겁니다. 그리고 실제로 그 집단은 살아남아 다음 전쟁의 핵심 인력이 됐고요.
소련 — 정반대였습니다.
대가가 컸지만 살아남은 사람은 강해졌다는 서술입니다. 미화하지 않으면서도 결과는 결과대로 적었어요.
그리고 축을 명시합니다.
"지금까지는"이라는 단서가 붙어 있습니다. 이 단서가 뒤에서 회수돼요.
🇰🇷 육사 8기와 11기
한국 사례로 오면 대비가 더 선명해집니다.
육사 8기 — 건국 후 입교한, 군 경력 없는 순수 민간인 청년들. 교육 기간은 3~6개월. 곧바로 소대장으로 6·25에 투입됐고, 휴전 무렵엔 대대장이 됐습니다. 글의 표현으로 "6·25 전쟁은 '8기생의 전쟁'"이었어요. 현장에서 교리를 배운 세대입니다.
육사 11기 — 최초의 4년제 생도. 웨스트포인트를 본떠 후방에서 차분히 제대로 교육받은 최초의 기수.
그리고 이렇게 잇습니다.
우리 업계에서 매일 오가는 논쟁이 그대로 겹쳐집니다.
🤖 AI가 이 저울을 흔든다
글의 현재 진단이 여기 있습니다.
그리고 비유로 정리합니다. "거칠게 비교하자면 육사 11기보다는 육사 8기 이전, 독일군 방식보단 소련군 방식이 대두되고 있다고 할까."
AI가 '역할 먼저' 쪽에 무게를 실었다는 관찰입니다. 실제로 팔란티어 같은 회사가 대학 대신 인턴으로 오라고 말하는 걸 근거로 들어요.
🧭 그런데 본인은 반대로 갔다
이 글에서 가장 좋았던 부분이 여기입니다. 시대의 흐름을 짚어놓고 자기는 그 반대를 택했다고 적어요.
그리고 무엇이 막연했는지를 정확히 짚습니다.
"코드는 나왔는데 내 것이 아니다"는 감각입니다. AI를 쓰는 사람이라면 한 번쯤 느꼈을 지점이에요.
그래서 결론이 이렇습니다.
"옛날의 정답"이라고 스스로 부르는 게 정직합니다. 자기 선택을 트렌드로 포장하지 않았어요.
⚖️ 그리고 판정은 현장에 맡긴다
마무리가 좋습니다.
어느 경로가 옳은지 판정하지 않고, 판정 기준만 세워둡니다.
그리고 마지막 문장.
자기 선택을 자기가 증명하겠다는 문장으로 끝납니다.
큐레이터 노트
자기 배경으로만 쓸 수 있는 글이라 뽑았습니다.
교육 논쟁은 어디에나 있습니다. "부트캠프 vs 전공" 이야기는 커뮤니티마다 몇 번씩 돌아요. 그런데 대개 자기 경로를 정당화하는 방향으로 갑니다.
이 글은 다릅니다. 역사 속 사례들을 먼저 늘어놓아요. 6개월 교육으로 큰 역할을 한 집단도 있고, 체계적 교육으로 최강이 된 집단도 있고, 준비 없이 던져져 큰 대가를 치른 집단도 있습니다. 한쪽 손을 들어주기 어려운 자료들이에요.
그리고 자기 선택을 "옛날의 정답"이라고 부릅니다. "무엇이 옳은 길인지는 모르겠다"고도 적고요. 결론을 내지 않은 게 이 글의 정직함입니다.
본인이 세 영역에 걸쳐 있다는 것도 이 글을 가능하게 했습니다. 장교로 교육받았고, 교육학을 전공했고, 지금 개발자가 되어가는 중이에요. 셋을 다 아는 사람만 볼 수 있는 겹침입니다.
성장일지에 이런 글이 올라오는 게 반가웠어요. 기술 정리만 기록이 아니라, 자기 자리를 생각해본 것도 기록입니다.
02
🎓 방송통신대 컴퓨터과학과 1학기 후기
신헌주 님
방송통신대학교 컴퓨터과학과에서 첫 학기를 마친 후기입니다. 마지막 기말고사를 치른 날 썼어요.
구성이 아주 실용적입니다. 입학 목적별로 추천/비추천을 나누고, 정보를 어디서 얻는지, 어떤 공부 방법을 썼는지, 그리고 과목별 후기까지.
그리고 비추천 항목을 정직하게 적었습니다. "첫 학기 이후 그만두는 사람들이 아주 많다"고요.
앞의 박석희 님 글과 나란히 놓으면 특히 재미있습니다. 같은 갈림길에서 같은 쪽을 고른 사람의 실제 기록이거든요.
조금 더 들어가 보면
먼저 왜 이 길을 골랐는지가 명확합니다.
부트캠프를 목적으로 걸러냈어요. 나쁘다는 게 아니라 용도가 다르다는 판단입니다.
그리고 독학도 검토합니다.
"그동안은 그렇게 했다" — 실제로 해봤다는 뜻입니다. 그리고 한계를 짚어요.
🗺️ "내가 무엇을 모르는지 알려준다"
이 한 문장이 이 글에서 가장 중요한 대목이라고 봤습니다.
검색과 AI로 하는 공부에는 구조적인 빈틈이 하나 있어요. 질문할 수 있는 것만 배우게 됩니다.
모르는 개념이 있으면 물어보고, 막히면 검색하죠. 그런데 존재 자체를 모르는 개념은 물어볼 수가 없습니다. 검색창에 넣을 단어가 없으니까요.
커리큘럼은 그 빈틈을 메웁니다. 내가 안 물어봐도 순서대로 들이밀거든요. 재미없어 보이는 단원도, 지금 당장 안 쓸 것 같은 내용도 목차에 들어 있습니다. 그리고 그 목차 자체가 "이 분야에 뭐가 있는지"의 지도가 됩니다.
글이 직접 겪은 예시도 나와요.
자기가 어디서 막히는지를 알게 된 겁니다. 혼자 공부했다면 애초에 그 단원 근처에 안 갔을 수도 있어요.
그리고 결과도 있습니다. "개론을 충분히 공부했다면 확실히 다른 과목들이 쉬워진다! 이후에 컴퓨터 구조 들을 때는 개론을 들어서 훨씬 쉽게 들었다."
🚫 비추천을 쓴 것
이 글이 특히 믿을 만한 이유는 말리는 대목이 있어서입니다.
그리고 숫자로 말합니다.
"매일 2시간을 낼 수 있는가"라는 아주 구체적인 자가진단을 줍니다. 막연한 "쉽지 않아요"보다 훨씬 유용해요.
그리고 자기 조건도 밝힙니다. "나는 지금 남들보다 비교적 시간이 많은 편이라 하루에 2~3개씩도 들었는데, 일반적으로 직장 병행하는 경우 하루 1개가 최선일 것 같다."
자기 페이스를 남에게 그대로 권하지 않았어요. 조건이 다르면 결과가 다르다는 걸 알고 씁니다.
🎯 목적별로 나눈 것
구성 자체가 배울 만합니다. 입학 목적을 넷으로 나눠요.
| 목적 | 판단 |
|---|---|
| 업계 종사자의 학위 취득 | 적합 — 졸업만 목표라면 어려울 것 없음, 저렴함 |
| 취업 전 학위 취득 | 모르겠다 — 본인이 업계 종사자가 아니라 판단 유보 |
| 그냥 배우고 싶어서 | 최고의 선택 — 본인이 여기 해당 |
| 목표가 없거나 시간이 없음 | 비추천 |
두 번째에서 "모르겠다"고 적은 게 눈에 띄었습니다.
모르는 걸 모른다고 쓰는 것 — 후기 글에서 드문 미덕입니다. 여기서 아는 척했으면 글 전체의 신뢰가 흔들렸을 거예요.
📚 실전 정보들
입학 후 정보 출처를 정리한 부분이 실질적입니다. 대학생활 길라잡이 → 공지사항 → 튜터 사이트 → 커뮤니티 순서로요.
커뮤니티에 대한 평가가 솔직해서 웃었습니다.
그런데 그럼에도 볼 이유 세 가지를 댑니다. 중고 교재 거래, 시험 후기(특히 기출이 없는 신설 과목), 그리고 공식 공지에 없는 디테일.
세 번째 예시가 아주 좋았어요.
이런 정보는 공식 문서에 안 나옵니다. 그리고 알고 모르고가 실제 점수를 가르죠. "공식 루트로 큰 그림, 커뮤니티로 디테일"이라는 정보 전략이 명확합니다.
📖 과목 후기가 구체적인 것
과목별 후기에서 강의 / 교재 / 시험을 나눠 적은 구성이 좋았습니다.
자료구조 강의 평이 특히 인상적이에요.
호불호가 갈린다는 걸 먼저 말하고 자기 취향을 밝힙니다. 그러면 읽는 사람이 자기에게 맞을지 가늠할 수 있어요.
교재 아쉬운 점도 번호를 매겨 정리했습니다. 연습 문제 없음, 워크북 없음, 뒤쪽 어려운 단원의 설명이 오히려 짧음, 중요한 개념(레드 블랙 트리)을 소개만 하고 넘어감. 좋았다고 하면서도 빠진 것을 짚었어요.
그리고 학점 전략도 계산이 붙어 있습니다.
"출석 수업을 가라"는 조언에 왜 그런지 계산이 붙어 있는 형태예요. 조언보다 계산이 오래갑니다.
큐레이터 노트
뒤에 올 사람을 정확히 겨냥한 글이라 뽑았습니다.
후기 글의 가치는 먼저 간 사람이 길을 표시해주는 데 있습니다. 이 글은 그걸 아주 성실히 해요. 목적별 판단, 시간 계산, 정보 출처, 과목별 특징, 시험 전략까지요.
추천만 하지 않은 것이 결정적입니다. "이런 경우는 비추천이다"라는 절이 따로 있고, "첫 학기 이후 그만두는 사람들이 아주 많다"고 적어요. 읽는 사람이 자기를 대입해볼 수 있게 만들었습니다.
종강 당일에 썼다는 시점도 좋았습니다. 학기가 끝나고 시간이 지나면 힘들었던 기억이 흐려지거든요. "꽤 일찍 시작한 것 같은데도 빡빡했다" 같은 문장은 방금 겪은 사람만 쓸 수 있습니다.
그리고 스터디 이야기가 나오는 게 반가웠어요.
온라인 대학의 가장 큰 난관이 혼자라는 것입니다. 커리큘럼은 학교가 주지만 같이 갈 사람은 안 주거든요. 그 자리를 스터디가 메웁니다.
03
☁️ SAM을 이용한 AWS Lambda 배포
사범기 님
AWS SAM(Serverless Application Model)으로 Lambda 함수를 배포하는 과정을 처음부터 끝까지 따라간 글입니다.
설치 →
sam init → 설정 파일 확인 → sam build → sam deploy 순서로 갑니다. 그리고 samconfig.toml과 template.yaml의 각 줄에 주석을 달아 무슨 뜻인지 설명해요.배포 실패 시 대처법도 붙어 있습니다. CloudFormation 스택을 지우고 다시.
앞머리에 이런 문장이 있습니다. "혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린 부분이 있으면 댓글을 남겨주세요." 태도가 먼저 보이는 글이에요.
조금 더 들어가 보면
먼저 SAM이 무엇을 해결하는지부터요.
Lambda 함수 하나를 띄우려면 실제로는 여러 개가 필요합니다. 함수 자체, 그걸 호출할 API Gateway, 함수가 다른 AWS 서비스를 쓸 IAM 역할, 코드를 올려둘 S3 버킷까지요.
AWS 콘솔에서 손으로 하면 클릭이 수십 번입니다. 그리고 더 큰 문제는 재현이 안 된다는 것.
· 개발 환경과 운영 환경을 똑같이 만들려면 같은 클릭을 반복해야 합니다
· 누가 뭘 바꿨는지 기록이 안 남습니다
· 새로 온 사람이 어떻게 구성돼 있는지 알 방법이 없어요
SAM은 이걸 파일로 적게 만듭니다.
📄 template.yaml — 구성을 글로 쓰기
글이 기본 템플릿을 통째로 실었는데, 읽어보면 구조가 명확합니다.
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello-world/
Handler: app.lambdaHandler
Runtime: nodejs22.x
Architectures:
- x86_64
Events:
HelloWorld:
Type: Api
Properties:
Path: /hello
Method: get
이게 콘솔에서 클릭했을 내용 전부입니다. 어떤 코드를, 어떤 런타임으로, 어떤 주소로 부를지요.
특히 Events 부분이 SAM의 편의를 잘 보여줍니다. Type: Api라고 한 줄 적으면 API Gateway가 알아서 만들어져요. 글이 인용한 주석에도 나옵니다. "ServerlessRestApi is an implicit API created out of Events key." 명시적으로 안 만들어도 암묵적으로 생성됩니다.
IAM 역할도 마찬가지예요. Outputs에 HelloWorldFunctionRole이 나오는데, 템플릿 어디에도 그걸 만든 적이 없습니다. SAM이 알아서 붙여줬어요.
⚙️ samconfig.toml — 배포 방식을 정하기
두 파일의 역할이 다르다는 걸 잘 나눠 설명했습니다. template.yaml은 무엇을 만들지, samconfig.toml은 어떻게 배포할지요.
글이 각 줄에 붙인 주석이 실질적입니다.
[default.build.parameters] cached = true # 빌드 시 변경 사항이 없다면 캐시된 결과를 재사용 합니다. parallel = true # 함수가 여러개 있을 때 병렬로 배포합니다. [default.deploy.parameters] capabilities = "CAPABILITY_IAM" # CloudFormation이 리소스를 생성하거나 수정할 수 있도록 허용합니다. confirm_changeset = true # CloudFormation 변경을 사용자에게 보여줍니다. resolve_s3 = true # S3 버킷을 자동으로 생성하거나 기존의 버킷을 재사용하도록 설정합니다.
confirm_changeset = true가 특히 중요한 설정입니다.
CloudFormation은 배포 전에 "무엇이 바뀔지" 목록을 먼저 만듭니다. 이걸 체인지셋이라고 해요. 이 옵션을 켜두면 그 목록을 보여주고 확인을 받은 뒤에 진행합니다.
왜 중요하냐면 — 템플릿을 잘못 고쳤을 때 "삭제(Delete)"가 목록에 뜨는 걸 볼 수 있기 때문입니다. 어떤 속성은 수정이 안 돼서 지웠다가 다시 만드는 방식으로 처리되는데, 그러면 그 사이에 서비스가 끊깁니다. 누르기 전에 볼 수 있는 게 안전장치예요.
capabilities = "CAPABILITY_IAM"도 짚어둘 만합니다. 이건 "권한을 만드는 것도 허용한다"는 명시적 동의예요. AWS가 이걸 따로 받는 이유는, 권한 생성이 위험할 수 있기 때문입니다. 실수로 과한 권한을 주는 템플릿을 무심코 배포하지 않게 하려는 장치죠.
🚑 실패했을 때
이 부분이 실전 경험에서 나온 대목입니다.
처음 배포가 실패하면 스택이 ROLLBACK_COMPLETE 상태로 남습니다. 그리고 이 상태에서는 다시 배포가 안 돼요. 고쳐서 다시 시도해도 계속 실패합니다.
처음 겪으면 원인을 찾기 아주 어려운 상황입니다. "코드를 고쳤는데 왜 여전히 안 되지?"가 되거든요. 답은 스택을 지우고 새로 만드는 것이고, 이 글이 그걸 알려줍니다.
🎯 마무리의 태도
글이 이렇게 끝납니다.
다음 단계를 예고하고, **처음의 인상이 어땠는지도 남겼어요.
그리고 방향이 자연스럽습니다. 콘솔 클릭 → SAM 템플릿 → GitHub Actions. 손으로 하던 걸 파일로 옮기고, 그 파일을 실행하는 것마저 자동으로 옮기는 순서예요.
큐레이터 노트
따라 할 수 있게 쓴 글이라 뽑았습니다.
배포 관련 글은 자기 환경을 안 밝히는 경우가 많습니다. 이 글은 첫 줄에 "제가 진행했던 방식은 Mac에서 진행하였습니다"라고 적어요. 그리고 설치 명령어도 Mac 기준이라고 표시합니다. 읽는 사람이 자기 환경과 대조할 수 있어요.
설정 파일에 주석을 단 것이 이 글의 가장 큰 값입니다. sam init을 돌리면 이 파일들이 자동으로 생깁니다. 그런데 뭐가 뭔지 모르는 채로 갖게 되죠. 이 글은 줄마다 뜻을 붙여놨어요. 자동 생성된 파일을 읽을 수 있게 만드는 작업입니다.
실패 케이스를 넣은 것도 좋았습니다. 성공 경로만 있는 튜토리얼은 한 번 막히면 거기서 끝이에요. ROLLBACK_COMPLETE 상태는 SAM을 처음 쓰면 거의 반드시 만나는 벽인데, 미리 알려줍니다.
참고한 글을 밝힌 것도 눈에 띄었어요. 마지막에 Ref로 다른 분의 글을 링크했습니다. 어디서 배웠는지 남기는 습관이 좋았습니다.
그리고 앞머리의 "틀린 부분이 있으면 댓글을 남겨주세요" — 완벽하지 않은 상태로 공개하는 태도입니다. 그래야 글이 나옵니다. 완벽해질 때까지 기다리면 대개 안 쓰게 되거든요.
💡 세 편을 겹쳐 읽으며
앞의 두 글은 대놓고 같은 주제입니다. 교육이 먼저냐, 현장이 먼저냐.
박석희 님은 역사에서 사례를 끌어옵니다. 6개월 교육으로 큰 역할을 한 집단, 4년 교육으로 최강이 된 집단, 준비 없이 던져져 큰 대가를 치른 집단. 그리고 AI가 저울을 '현장 먼저' 쪽으로 기울이고 있다고 진단해요. 그런데 본인은 반대로 갑니다. 이유는 하나예요. "AI에 종속되는 거지, 내가 문제를 해결하는 게 아니다."
신헌주 님은 같은 갈림길에서 같은 쪽을 골랐고, 한 학기를 지나 돌아봤습니다. 이유도 같은 계열이에요. "대학의 커리큘럼과 전공 서적이 내가 무엇을 모르는지 알려주어 좋았다."
두 문장이 사실 한 이야기입니다. AI든 검색이든, 내가 질문할 수 있는 것만 답해줍니다. 무엇을 물어야 할지 모르면 아무것도 못 얻어요. 커리큘럼은 내가 안 물어도 들이미는 목록이고, 그래서 지도가 됩니다.
그리고 사범기 님의 글이 이 축에 조용히 얹힙니다.
콘솔에서 클릭하면 지금 당장은 더 빠릅니다. 파일 문법을 배울 필요도 없고요. 그런데 다음에 다시 못 만듭니다. 뭘 눌렀는지 안 남으니까요. template.yaml은 시간이 더 걸리지만 읽을 수 있고, 고칠 수 있고, 다시 돌릴 수 있습니다.
세 번 다 같은 저울입니다. 지금 빠른 길과, 나중에 남는 길.
그런데 세 글 다 빠른 길을 부정하지 않아요.
박석희 님은 "무엇이 옳은 길인지는 모르겠다"고 하고, 판정을 현장에 맡깁니다. 신헌주 님은 목적이 다르면 다른 답이 맞다고 나눠 적어요. 사범기 님은 "처음에는 lambda가 불편하고 어렵다고 생각했지만"이라며 자기 출발점을 남깁니다.
자기 선택을 하되 남의 선택을 깎지 않는 것 — 세 글의 공통된 태도였습니다.
그리고 마지막으로, 세 글 다 기록을 남겼다는 사실 자체가 이 저울의 답 같기도 합니다. 지금 당장 빠른 건 안 쓰는 거예요. 남는 건 쓴 쪽이고요.
이번 회차에서 가져갈 것
1. "교육이 먼저냐, 역할이 먼저냐"는 오래된 질문이다.
6개월 교육으로 역사를 만든 집단도 있고, 준비 없이 던져져 큰 대가를 치른 집단도 있습니다. 한쪽이 늘 옳았던 적은 없어요.
2. AI가 저울을 기울이고 있다는 관찰.
범용 지식을 AI가 보조해주니 현장 경험 쪽 비중이 커졌다는 진단입니다. 다만 그 결과 "코드는 나왔는데 내 것이 아닌" 감각이 생기기도 합니다.
3. AI에 깊이 있게 물으려면 기본기가 필요하다.
막연히 시키면 막연한 게 나옵니다. 체계적인 지시를 내릴 수 있으려면 그 분야의 언어를 알아야 해요.
4. 검색과 AI는 '내가 물을 수 있는 것'만 답한다.
존재를 모르는 개념은 검색창에 넣을 수가 없습니다. 커리큘럼의 값은 여기 있어요 — 안 물어봐도 순서대로 들이밉니다.
5. 시간 계산을 먼저 해보기.
방통대 병행은 퇴근 후 매일 2시간이 기준선입니다. "쉽지 않다"보다 이 숫자가 훨씬 정확한 자가진단이에요.
6. 후기를 쓸 땐 비추천도 쓰기.
추천만 있는 글은 읽는 사람이 자기를 대입할 수 없습니다. 목적별로 나누고, 안 맞는 경우를 명시하면 훨씬 쓸모 있어요.
7. 공식 루트로 큰 그림, 커뮤니티로 디테일.
공지사항에 큰 정보는 다 있지만, "75분을 3과목에 자유롭게 분배할 수 있다" 같은 건 겪은 사람만 압니다.
8. 콘솔 클릭은 재현이 안 된다.
같은 환경을 다시 만들 수도, 누가 뭘 바꿨는지 볼 수도 없어요. template.yaml에 적으면 읽고 고치고 다시 돌릴 수 있습니다.
9. confirm_changeset = true를 켜두기.
배포 전에 무엇이 바뀔지 목록을 보여줍니다. 의도치 않은 "삭제"가 뜨는 걸 누르기 전에 볼 수 있어요.
10. 배포가 실패하면 스택 상태부터 확인.
ROLLBACK_COMPLETE로 남으면 고쳐도 재배포가 안 됩니다. 스택을 지우고 다시 시작해야 해요.
11. 완벽해질 때까지 기다리면 안 쓰게 된다.
"틀린 부분이 있으면 댓글을 남겨주세요"로 시작한 글이 결국 남습니다.
좋은 글 남겨주신 박석희 님, 신헌주 님, 사범기 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.